Open stanleybak opened 8 years ago
I have not tested the unit tests on 2016a, only on 2014b. The multiple matlab instances starting is due to the library usage (I had this fixed before but I broke it when refactoring into the MatlabBridge). It may be due to calling the jars multiple times throughout the tests and a new instance gets spawned each time.
For the error, you are probably missing a toolbox, probably the symbolic math one.
We have the required ones in the readme / repos overview here: https://github.com/ttj/hyst#matlab-toolboxes
It seems I forgot to merge my branch back in, so I'll try to find some time to create a pull request this week (we did this when we set up the HSCC 2016 repeatability package).
We should probably think about a general way to handle these types of failing tests when dependencies are missing (maybe however you've been handling the Python ones since we're probably calling things in a similar way?).
Additionally, we should think about a test / check we can run to check on all dependencies, so users can understand what functionality is there or not.
Having all the tests pass is great, but we've got it set up now in a way that what one user sees will differ from others based on the dependencies available.
The way it works with python is that hasPython()
returns false if any of the libraries are missing. This is done by trying to open a python process and import all the required libraries. Maybe hasMatlab()
could do something similar? It would also be a good place to report which toolbox is missing.
Yes, that sounds good. Eventually we may want to refactor to parameterize by libraries, versions (maybe), etc., as how does it currently work if ONE library is missing? E.g., for Matlab, the order reduction pass relies on it, as does the SpaceEx-to-Stateflow translator, but they require different libraries, so one could work while the other may be broken. Something like:
hasPython(libraryName)
or have hasPython()
return a list of missing libraries or something; strings would probably be fine (there are APIs using strings for the Matlab libraries, including version numbers, etc.)
For python, the current setup is that if any libraries are missing hasPython()
returns false. This may be pessimistic, but it's easier to manage. For matlab, since the toolboxes cost money, maybe it makes more sense to have something more fine-grained, although it will be more complex code for you to write and test.
Sounds good. Does the following make sense for Python via a finer-grained additional function?
hasPython(bool detailed)
returns a list of strings with the missing dependency name (could think about versions too if you're checking this)
hasPython()
returns false if any dependency is missing by checking if hasPython
returns a string of length >= 1
We can then do the same for Matlab.
Also, should we go ahead refactor this at this point to make a generic bridge as well? We will soon add a Mathematica interface for Andrew's work.
We could create a generic bridge interface / abstract class with things like checkDependencies
, etc., and then have the specific bridges implement these. I would think this will make it easier to maintain into the future (like we did with the printers at some point after we had a couple).
Hmmm, my last comment seemed to get dropped somehow and it was unfortunately rather long.
Should we go ahead and refactor and add a generic interface / abstract class for bridges? Andrew will soon add a Mathematica bridge.
Likewise, we could do the following for finer-grained error messages, etc. for users. Have a:
hasDependency(bool detailed)
that returns a list of strings with missing dependencies (and possibly versions if important)
hasDependency()
returns false if the list of dependencies missing is greater than 0 length
And now it showed up....weird. Anyway, you get the idea...
Yes, an ExternalBridge
generic class might be a good idea.
The hasDependency(bool detailed)
you proposed would check for all toolboxes / libraries? Would there be a way to query for individual ones (do we want to have this ability?)?
Let's try to avoid premature generalization. I think the hasAllDependencies()
or, equivalently, check()
methods are necessary, which return true/false and can be used to skip unit tests where dependencies are not met.
The strategy I've taken with python is that you can't use the bridge unless you have all dependencies. If you try to, you get an AutomatonExportException
with a message that describes the missing library.
The alternative is either we explicitly state whenever using the bridge which libraries are needed (may lead to errors by the coder missing some required libraries), or we try to run the code, and if it fails the error message may be hard to figure out (since, for example, it may be a matlab error).
I think the easiest to code is just don't let people use the bridge unless you have all dependencies. Maybe we could add a -force
flag or something that will try to use the bridge anyway, but then we wouldn't make guarantees about having nice error messages if things fail.
If there are exotic matlab toolboxes, maybe we just have two matlab bridges at that point, one for the standard set, and one for the exotic ones? Hmm, that doesn't seem very clean either though...
I finally got a computer with matlab on it so I could run the unit tests. It's R2016a, not sure if that matters.
When I run the unit tests, several instances of matlab open (four). Also, there are errors. Here's the console output:
In addition, in one of the matlab windows: