matlab unit tests fail #32
Comments
|
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 |
|
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:
|
|
For python, the current setup is that if any libraries are missing |
|
Sounds good. Does the following make sense for Python via a finer-grained additional function?
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 |
|
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:
|
|
And now it showed up....weird. Anyway, you get the idea... |
|
Yes, an The Let's try to avoid premature generalization. I think the 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 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 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:
The text was updated successfully, but these errors were encountered: