[CR] LV muParser

[Porter]

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.

[Porter]

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

[Porter]

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

[ensegre]

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.

[ensegre]

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 January 9, 2018 by ensegre

[Porter]

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.

[Porter]

Error details as cluster: lv_muparser-1.1.1.2.vip

[ensegre]

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?

[Porter]

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

Just pushed changes to github now.

Edited January 9, 2018 by Porter

[burd]

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 February 22, 2018 by burd

[ensegre]

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.

[burd]

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!

 

 

[burd]

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

[Porter]

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

[burd]

23 minutes ago, Porter said:

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

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!

helcio_lib_folder_utilities-1.0.0.6.vip

[Porter]

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 February 22, 2018 by Porter

[burd]

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 February 24, 2018 by burd

[ensegre]

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.

[Porter]

I thought that it would be nice to extend the muParser library's functionality to include automatic CVT tag lookup. This means that if you input an expression that contains CVT tag names as variables, their values will automatically be substituted during eval.

This new CVT expression parser IS AN expression parser. So I tried to make a child of the mupExpr class. Who's silly idea was it to pass this class by reference?! LabVIEW doesn't support dynamic dispatch on class DVRs.

So I've re-worked the mupExpr Class to wrap only the muparser handle (hParser) in a DVR. This gives a similar protection as wrapping the class in a DVR but allows us to pass the class by value instead.

If anyone objects to this change, please shout out now before I commit changes to github.

The code is attached, with an example: NICVT Expression Test.vi

You need to install NI Current Value Table v.3.3.0 before opening the project.

NICVTExpr.zip

[Rolf Kalbermatter]

On 2/24/2018 at 11:39 PM, ensegre said:

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.

The solution to this is usually to cache the path in a shift register (or feedback node) once it has been evaluated and skip new evaluation when the path is valid.

[Andy75]

Hello!

Today I discovered the LV-muParser while I was searching for a way to perform bitwise operations (and, or, xor, shift left/right, not) on a term given es string (e.g. "1 & 3" = 2).
I really like this pice of code because it's much easier to use in comparison to the NI formular parser. Unfortunatelly it seams not to support the bit-operations like I need and the muParser lib it's using is also a couple of years old.

My question: Do you plan to update your package in the near future and would it be possible to add support for the bit operators? ... or is it already possible for me to add them manually?

Thanks in advance.

Andreas

[Porter]

The muparser library should definitely be updated. I had modified the muparser library to add the : character as a valid variable name character because my variable names often include colons.

To add bitwise operations like "2&3 = 2", either you would need to create a wrapper that adds these functions to muparser, or just modify the original source code like I did for the : character. I'm not sure how much work this would be. The labview code wouldn't change at all, except for specifying a new version of the muparser dll.

[Porter]

It seems that everything is passed as float. Bitwise should be performed on integers. So maybe muparser isn't the best solution.

They do mention that shift left/right can be added though: https://beltoforion.de/en/muparser/customizing_muparser.php

But maybe GPower Expression Parser has exactly what you need: https://www.vipm.io/package/gpower_lib_exprparser/

 

 

 

Edited August 3, 2022 by Porter

[Andy75]

Yes, you're right. The GPower Expression Parser could be the better solution from a technical perspective ... but 949$ for a few bit-operations ... ?

The customizing capability was also what I have seen and thought about. The "easiest" would be to think about which operators are useful and often required and add them right into the C-DLL - personally I currently only need the bit-operators. The cooler and more flexible solution would be to define the call-back functions in LabVIEW - but I have never done this ...

By the way: Calculation performance has priority C for me.

Edited August 3, 2022 by Andy75

[Rolf Kalbermatter]

4 hours ago, Andy75 said:

Yes, you're right. The GPower Expression Parser could be the better solution from a technical perspective ... but 949$ for a few bit-operations ... ?

The customizing capability was also what I have seen and thought about. The "easiest" would be to think about which operators are useful and often required and add them right into the C-DLL - personally I currently only need the bit-operators. The cooler and more flexible solution would be to define the call-back functions in LabVIEW - but I have never done this ...

By the way: Calculation performance has priority C for me.

You may want to try with this library. No guarantees about its proper operation. It's a quickly hacked together version from this library that I posted earlier. It's not really tested for the extra bitwise operators and there is no provision for correct left and right association of these operators, so it might require explicit bracketing to work as expected unlike in other languages and formula parsers that tend to follow the mathematical and/or C style conventions.

LabVIEW 2018 for now.

ExprEval.zip

Edited August 3, 2022 by Rolf Kalbermatter