Jump to content
News about the LabVIEW Wiki! Read more... ×

Recommended Posts

2 hours ago, ensegre said:

While designing an interface which should highlight syntax errors in typed formulas, I realize that I miss a VI returning directly the strings of mupGetExpr() and mupGetErrorToken() together with the number mupGetErrorPos() [when applicable], instead of tediously parsing them from the full error message. Do you envision adding it to the toolbox? I may have a go at getting them from the encapsulated form, it later

I will package this up in a mupGetLastError.vi which will return:
- Error Code
- Error Token
- Error Position
- Error Message

I will also make a mupGetExpr.vi for completeness. But mupExpr class already keeps a copy of the expression (accessible via Expression property).

mupExpr will get a top-level VI named Get_Last_Error.vi that will just call mupGetLastError.vi.

Share this post


Link to post
Share on other sites

Also looks like mupExpr Construct.vi would require Error Token and Error Position outputs.

Share this post


Link to post
Share on other sites

Give this a try: lv_muparser-1.1.1.1.vip

Get_Last_Error.vi in mupExpr is not very useful. The expression is parsed and validated in Construct.vi. Therefore I chose to add "error pos" and "error token" outputs to Construct.vi

Share this post


Link to post
Share on other sites
6 minutes ago, Porter said:

Give this a try: lv_muparser-1.1.1.1.vip

Get_Last_Error.vi in mupExpr is not very useful. The expression is parsed and validated in Construct.vi. Therefore I chose to add "error pos" and "error token" outputs to Construct.vi

wow that was fast. I'll evaluate tomorrow how it fits in my current project.

I agree that syntax errors can result only where expressions are defined and hence there may little reason for an a posteriori VI. Though, muparser allows decoupling it so it may be an argument in favor of it, but no need of overdoing.

Something I could suggest is to group all the outputs of GetLastError in a cluster for compactness.

I was also considering to include these as attributes of the muExpr class (ref), but I realized that your choice was to generate an empty class in case of error during construct, so that wouldn't apply.

Share this post


Link to post
Share on other sites

This is what I'd propose (cluster output). Backsaved for LV2015.

mupGetLastError.vi

Construct.vi

Get_Last_Error.vi

Now it occurs to me that only the first parsing error in a (multi) expression is reported; I could think at cases where I would like to see all errors in long expressions at once (when not ambiguous), but I think this is not contemplated in muparser. For example, I don't think you can merge different expressions parsed separately into a single muparser instance.

Edited by ensegre

Share this post


Link to post
Share on other sites
9 hours ago, ensegre said:

Now it occurs to me that only the first parsing error in a (multi) expression is reported; I could think at cases where I would like to see all errors in long expressions at once (when not ambiguous), but I think this is not contemplated in muparser. For example, I don't think you can merge different expressions parsed separately into a single muparser instance.

You could parse the multi-expression as a csv string then use mupSetExpr and mupGetExprVars on each expression. Once all expressions have been validated, you can put the multi-expression back into mupSetExpr. This can all be added to mupExpr Construct but I think that it is too inefficient and most of the time, the first error is good enough.

Share this post


Link to post
Share on other sites

thx. And agree with the very limited value of piecewise parsing just for checking.

Btw, I see, you don't keep in sync github, forum and CR entry page. Never mind... Am I the only freak of this toolbox?:rolleyes:

Share this post


Link to post
Share on other sites

I figured that I'd let you take it for a spin before making the next commit.

Just pushed changes to github now.

Edited by Porter

Share this post


Link to post
Share on other sites

I am having trouble when I building an executable that contains muparser Vis. The reference to it is getting deleted (Error 1556; LabVIEW:  The reference is invalid. This error might occur because the reference has been deleted.) even though the  application works fine in development mode.

Do I have to copy any DLL to the Data folder of the executable?

I am using labview 2017;

thanks

Edited by burd

Share this post


Link to post
Share on other sites

Did you add libmuparser-xxx-lv.dll to the project, and specified it in the Source Files/Always Included section of the build spec? Since the dll is called dynamically (see previous discussions), it is not automatically detected as dependency.

Share this post


Link to post
Share on other sites
7 hours ago, ensegre said:

Did you add libmuparser-xxx-lv.dll to the project, and specified it in the Source Files/Always Included section of the build spec? Since the dll is called dynamically (see previous discussions), it is not automatically detected as dependency.

No, I did not do that. I will try!

Thank you so much for the information!

muParser is a great library, I was very sad that I would have to give it up, but now I am happy again!

 

 

Share this post


Link to post
Share on other sites
9 hours ago, ensegre said:

Did you add libmuparser-xxx-lv.dll to the project, and specified it in the Source Files/Always Included section of the build spec? Since the dll is called dynamically (see previous discussions), it is not automatically detected as dependency.

I added the libmuparser-x32-lv.dll to the project and then specified it in the source files/always included section in the build spec (see figure below). However I continue getting Error when I run the executable file. I am getting Error 7, file not found coming from muParser Vis (see below);

Any idea of what I could do to fix this?

 

Thanks

ice_screenshot_20180222-101328.png

ice_screenshot_20180222-094439.png

Share this post


Link to post
Share on other sites

Make sure that the libmuparser-xxx-lv.dll is put in the same directory as the executable.

3.PNG

Share this post


Link to post
Share on other sites
23 minutes ago, Porter said:

Make sure that the libmuparser-xxx-lv.dll is put in the same directory as the executable.

3.PNG

I figured out where the error was coming from,

The mupLibPath.vi is unable to find the correct location of the  libmuparser-xxx-lv.dll if it is not in the same directory as the executable. I fixed it by adding something more generic that will try to find recursively the .dll file within the folders of the project, so I do not have to worry about placing the .dll together with the executable (see picture). If someone likes the idea and want to use it, I put the VIP file that will allow to look recursively for files. I hope that this might be useful for someone,

thank you for the help!

muparser find dll.png

helcio_lib_folder_utilities-1.0.0.6.vip

Share this post


Link to post
Share on other sites

I use a constant relative path for performance reasons. When I tried to do anything fancy with the path in mupLibPath, there was too much of a performance hit.

Edited by Porter

Share this post


Link to post
Share on other sites
On 2/22/2018 at 1:46 PM, Porter said:

I use a constant relative path for performance reasons. When I tried to do anything fancy with the path in mupLibPath, there was too much of a performance hit.

Porter,

Wouldn't the performance hit only be limited to the time period during the creation of the muParser if you use the solution which recursively look for the libmuparser-x32-lv.dll ?

I believe that it should not exist  performance hit after the creation of the muParser in the above case.

I would imagine that after the creation of the reference it won't be necessary to look again for the libmuparser-x32-lv.dll if one keeps the reference to the muParser opened.

Do you agree?

 

 

Edited by burd

Share this post


Link to post
Share on other sites
5 hours ago, burd said:

I would imagine that after the creation of the reference it won't be necessary to look again for the libmuparser-x32-lv.dll if one keeps the reference to the muParser opened.

Some discussion about performance of various path computations is at pages 1-2 of this thread.

The dll needs to be called at every evaluation, by its known path, not just at construction. Maybe it would be conceivable to carry the path to the dll on the muparser reference wire, but I'm not sure it would be too logical.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

By using this site, you agree to our Terms of Use.