I was playing around with RxScala and Subject in scala worksheet. But something weird happened.
as we can see, subscription c also get numbers and output them. After that, I find subscription c is var not val. So, I change the declare. And get following
This one is correct. So, I copy those code to a main function and run it. It is interesting that the output is same with the second picture whether c is val or not.
Why those happend? Program runing in worksheet is different from those after compiling even with the same code?
Related
I'm writing a little program in scala that would simulate a doctors practice. One of the requirements is that a user can set consultations with a doctor. I have implemented a solution that gives you the consultation object if you succeed and also prints a message saying that the action was successful.
This is where a little "bug" (more a minor but annoying inconveniece) appears. When I tell my scala worksheet to make a new variable like so:
var consultation: Consultation = patient.makeConsultation(x, y, z)
Well this works perfectly BUT the message that it should print is printed at the top of the output window and not at the point in the worksheet were the variable is actually created. Does anyone know a solution for this?
Thanks in advance.
This is not a bug but the expected behaviour. The println in your makeConsultation function is a side-effect which has nothing to do with the creation of Consultation.
You can use Scala's type system (check Option or Try) to represent that makeConsultation could fail.
I want to compile my app using matlab-compiler it does so, but with issues...
It says there are some functions that are not licensed for compilation.
The problem is that I haven't used those functions (one of them is fimath.m) in my app.
I think these functions are used inside some of my functions which I don't know.
My question is how to find out which one of my functions are using those functions in order to remove them or replace them with other functions.
There are more than 50 functions in my app and it's not possible to check them one by one.
For every returned "unlicensed" function you can execute the following command,
dbstop in <function name> % without the <>
and afterwards run your code normally for several typical inputs/cases. If it stops at one of these breakpoints, look at the call stack (using either dbstack or the Editor tab of the MATLAB GUI), and identify the entry point from your own code.
If none of the breakpoints is ever hit, it could mean that these functions are referred-to inside the code, but some logic is preventing their execution (turning them, practically, to "unreachable code"). In this case, you will likely need to remove these references manually. To know where from, using information from the link posted by VTodorov you can list the dependencies of each file using
[fList,pList] = matlab.codetools.requiredFilesAndProducts('myFun.m');
which can be called on the output of dir (after some minor conversion). It could be useful to use the toponly flag.
I'm using the current version of the TypeSafe Scala/eclipse IDE. I have an object (which I called PositionObj to give it a unique name). PositionObj contains a main method. Yet when I try Run as > Scala application I get a pop-up message saying:
PositionObj needs to be an 'object' (it is currently a 'class').
In fact it's not a class, and there is no class with that name. Any thoughts about why this is happening and how I can get around it?
Here is the relevant code.
object PositionObj { ...
def main(args: Array[String] = Array[String]()): Unit = {
// This is just to see if anything happens.
println(position(3).p1Rqmts.keys.head)
}
...
Thanks.
Based on your answered-to code, try removing the default argument, since this might be creating a different code signature
I should have done this before, but now I notice that there is a compiler error message that says that the compiler couldn't handle the code because it was too big for a method. That's consistent with my experience with the problem. When I comment out a large table of data, everything works fine. So I'm now convinced that the problem was simply that the program was organized in a way that pieces of it were too large to be handled by the compiler.
I got around the problem by chopping my data table into multiple parts and including each one in a separate object. That worked even though all the objects were then included in the overall program. It was not the size of the program overall; it was the size of large chunks.
The compiler error message was somewhat misleading in that it said the problem was that a method was too large. In fact, my data table was a val in an object and not within a method. But as I said, chopping it up into separate objects and combing them with software solved the problem.
Let us say that I have a Matlab function and I change its signature (i.e. add parameter). As Matlab does not 'compile' is there an easy way to determine which other functions do not use the right signature (i.e. submits the additional parameter). I do not want to determine this at runtime (i.e. get an error message) or have to do text searches. Hope this makes sense. Any feedback would be very much appreciated. Many thanks.
If I understand you correctly, you want to change a function's signature and find all functions/scripts/classes that call it in the "old" way, and change it to the "new" way.
You also indicated you don't want to do it at runtime, or do text searches, but there is no way to detect "incorrect" calls at "parse-time", so I'm afraid these demands leave no option at all to detect old function calls...
What I would do in that case is temporarily add a few lines to the new function:
function myFunc(param1, param2, newParam) % <-- the NEW signature
if nargin == 2
clc, error('old call detected.'); end
and then run the main script/function/whatever in which this function resides. You'll get one error for each time something calls the function incorrectly, along with the error stack in the Matlab command window.
It is then a matter of clicking on the link in the bottom of the error stack, correct the function call, and repeat from the top until no more errors occur.
Don't forget to remove these lines when you're done, or better, replace the word error with warning just to capture anything that was missed.
Better yet: if you're on linux, a text search would be a matter of
$ grep -l 'myFunc(.*,.*); *.m'
which will list all the files having the "incorrect" call. That's not too difficult I'd say...You can probably do a similar thing with the standard windows search, but I can't test that right now.
This is more or less what the dependency report was invented for. Using that tool, you can find what functions/scripts call your altered function. Then it is just a question of manually inspecting every occurrence.
However, I'd advise to make your changes to the function signature such that backwards compatibility is maintained. You can do so by specifying default values for new parameters and/or issuing a warning in those scenarios. That way, your code will run, and you will get run-time hints of deprecated code (which is more or less a necessary evil in interpreted/dynamic languages).
For many dynamic languages (and MATLAB specifically) it is generally impossible to fully inspect the code without the interpreter executing the code. Just imagine the following piece of code:
x = magic(10);
In general, you'd say that the magic function is called. However, magic could map to a totally different function. This could be done in ways that are invisible to a static analysis tool (such as the dependency report): e.g. eval('magic = 1:100;');.
The only way is to go through your whole code base, either inspecting every occurrence manually (which can be found easily with a text search) or by running a test that fully covers your code base.
edit:
There is however a way to access intermediate outputs of the MATLAB parser. This can be accessed using the undocumented and unsupported mtree function (which can be called like this: t = mtree(file, '-file'); for every file in your code base). Using the resulting structure you might be able to find calls with a certain amount of parameters.
I have a method which takes a data structure and writes to an OutputStream. I'd like to write a unit test which ensures that the output of that function for a given input doesn't change unexpectedly.
I think I have the test structured the right way, using JUnit Theories. My #DataPoints are pairs of identifiers and example data structures, and I have an #Theory that the output from the method will be identical to a file checked in to version control that I fetch using getResourceAsStream using the identifier.
The painful part, however, is generating those files in the first place. My current very ugly solution is a boolean constant called WRITE_TEST_OUTPUT, which is usually false. When I want to regenerate the output files (either because I've changed the list of #DataPoints or the desired behaviour of the method has changed) I set this constant to true, and there's a test which when this is true runs the function again to write the current output files to a directory in /tmp. It then asserts that the constant is false, so I don't accidentally check in a version in which the constant is true.
It's very convenient to have the generation pretend to be a test so I can run it from within Eclipse, but it seems like a horrible kludge. This seems like the sort of thing people must do all the time - what kind of solutions have other people found?
What I'd probably do is detect the file's existence rather than use an externally modified constant. So you'd have something like
public void testMethodOutput() {
if (new File(expectedOutput).exists()) {
// check method output against file
} else {
// generate expected output from current behaviour; test passes automatically
// (saves output to the expected-output file)
}
}
When you want to update the expected output, delete the file, run tests, commit the new version to version control. No source change necessary.
It seems a little strange that the correct output is determined by looking at what a given version of the program does, rather than something you yourself set up (what if that version has a subtle bug?). Possibly that's a hint that your test is too coarse-grained, and that in turn might hint that your method is itself too coarse-grained. (Test smells are nearly always design smells.)