[CR] LV muParser

[Porter]

This works for me on ubuntu 20.04, gcc9.4.0, LV2022: lv_muparser-2.1.0.3.vip

[Antoine Chalons]

it's working for me

good job!

[ensegre]

WFM as well

[Porter]

The release is now updated on github. I will send it off to vipm after a bit more testing.

If you are curious about how I compiled libmuParser for windows and ubuntu, and the modification that I made, here are my notes: muParser Build Notes.pdf

On an unrelated topic; is it worth uploading the latest versions of projects on the LAVA CR? Each project now has a copy on github, vipm, and LAVA

- vipm is the most convenient for distribution
- github is most convenient for source version control and issue tracking
- LAVA is most convenient for discussion

[Porter]

Does anyone want to take a whack at MacOS support?

[AndyS]

As I wrote in an earlier post I'm missing bit-operations and some more. Since I had some time left, I downloaded the latest LabView-muParser code and added the missing functions:
 

• ~ Binary-Not (flip all bits)
• & Binary And
• | Binary Or
• |^ Binary XOr
• << Bit-Shift left
• >> Bit-Shift right
• % Modulo Operator (also for floating point values)
• Support of values given as hex (0x1A2c) and binary (0b101101)

My question to you Porter: Are you interested in integrating it into your project? Then everybody could use it. The modifications are only in one file (muParserDLL.cpp).

Edited July 28, 2023 by AndyS

[Porter]

I'd be happy to take a look. Please share the code with me.

It would be important to prepare a comprehensive list of test cases to validate the each new operation and make sure that existing operation are not changed.

The test cases that I have been using are here: LV-muParser/Testing/eqTestCases_mupExpr.csv at master · rfporter/LV-muParser · GitHub

Edited July 31, 2023 by Porter

[AndyS]

Did you get the C file by PM? Sorry to ask but the WebUI behaviour is a bit strange here.

[Porter]

Got it. Thanks. Do you mind if I post it here?

[Andy75]

sure, you can 🙂

[Porter]

Here it is.

muParserDLL.cpp

[AndyS]

Hello Ryan,

I found another problem but I'm asking myself if I'm doing something wrong ...

I created a small EXE file, using the mu-parser. For testing it just calculates the result of "3 * 25".

The problem now is that the EXE does not find the libmuparser-x64-lv.dll. I manually created a data-sub-folder and copied the DLL into it but it did not help. So currently I don't know where the DLL has be located for an EXE-File.
Then I modified your "mupLibPath.vi" in a manner that it searches the DLL in the support folder of the EXE and now it works.

So for me the question is: Is there a bug and the muparser was never used within an EXE file? (I cannot imagine) or does it need to be located somewhere else than in the support folder.

Thanks for your answer!

And by the way: the author of the muparser project has fixed the issue with the missing priority parameter. I hope for an official release soon.

[Porter]

The dll should be in the same folder as the exe in order to be found automatically. 

[Andy75]

OK, thank you for the hint. I'll try it on Monday. Since my experiance it is unusual to place a DLL beside to the exe file and not within the support folder of the application. Is there a special reason why you did it this way?

[Rolf Kalbermatter]

3 hours ago, Andy75 said:

OK, thank you for the hint. I'll try it on Monday. Since my experiance it is unusual to place a DLL beside to the exe file and not within the support folder of the application. Is there a special reason why you did it this way?

It’s actually how Microsoft wants DLLs distributed with an application unless it is installed directly into the system (or GAC for .Net assemblies). For DLLs that get directly referenced by LabVIEW VIs it is not important as the application builder adjusts the path to whatever relative directory you told it to move the DLL but for other DLLs that LabVIEW and/or the application builder doesn’t know about it is important to place the DLL in a standard Windows searched location.

Edited August 26, 2023 by Rolf Kalbermatter

[AndyS]

On 8/26/2023 at 11:31 PM, Rolf Kalbermatter said:

It’s actually how Microsoft wants DLLs distributed with an application unless it is installed directly into the system (or GAC for .Net assemblies). For DLLs that get directly referenced by LabVIEW VIs it is not important as the application builder adjusts the path to whatever relative directory you told it to move the DLL but for other DLLs that LabVIEW and/or the application builder doesn’t know about it is important to place the DLL in a standard Windows searched location.

Thanks for you explanation. It's working now when I moved the DLL beside the EXE 😀
Nevertheless I'm not really happy with this solution, because all the other DLLs are within the support folder (.\data) of my application. I know (or at least I haven't found out something different) that it is not possible to figure out the support folder by a LabVIEW function. From that point I understand why the muparser-DLL must be located beside the exe.

to @Porter: Do you think it could make sense to modify the mupLibPath.vi to give the user the chance to define where the DLL is located? I was thinking about adding a functional global that keeps the latest path value. By default it would be the path as it is used currently. The problem here is that it conflicts with the re-intrant and inline configuration of the VI. Appended you'll find a quick hack - just as an idea.
 

mupLibPath.vi

Edited August 28, 2023 by AndyS

[Porter]

On 8/30/2017 at 11:52 PM, Porter said:

I also prefer the statically linked dll because I can imagine that no one will remember to include the correct DLL or even know where to find the DLL when they build their exe.

However, since this library is under development, I think that it is wise to stick with the in-lined mupLibPath vi for now.

When we get closer to V1.0 perhaps it will be worth putting in the extra effort to setup a conditional disable structure around each CLN.

This is going back a while. We are at V2.x already. But this fell off of the list of priorities.

It would allow the application builder to pickup the DLL automatically (and drop it in a support dir).

I will need to add conditional disable structures around all muparser DLL calls in mupLib.lvlib

[AndyS]

8 hours ago, Porter said:

I will need to add conditional disable structures around all muparser DLL calls in mupLib.lvlib

uh ... that's a lot of work and because you're supporting different platforms and each time the binary (DLL, lib, etc) have another name you'll need several cases.
Why don't you add an exported DLL function that delivers the path to the DLL itself. You could call this once (by using a static link within a conditional disable structure) but then it should be sufficient with the dynamically linked calls without wrapping them into a conditional disable structure.

[Porter]

I prefer not to add any overhead to each call by having to retrieve the path to dll. If I recall correctly, when it was not a path constant wired to the CLFN (eg. a shift register instead) there was some overhead added to each call.

It will be a bunch of busy of work, but I think that the API is mature enough now that it is worth the effort. I think its about 12 VIs, 4 cases each.

[AndyS]

ok 🙂 👍

[Porter]

Give this a try: lv_muparser-2.2.0.4.vip

It worked with LV2020 x32 and x64, Windows.

In Linux I had to manually copy the .so file to libmuparser-lv.dll. Permission issues with the installer of course. I think that Labview needs to be run as root during the install but my community edition was activated under my user account. After doing that manual copy it worked fine though.

All CLFNs are statically linked to "<resource>\libmuparser-lv.dll"

Edited August 29, 2023 by Porter

[Rolf Kalbermatter]

2 hours ago, Porter said:

Give this a try: lv_muparser-2.2.0.4.vip

It worked with LV2020 x32 and x64, Windows.

In Linux I had to manually copy the .so file to libmuparser-lv.dll. Permission issues with the installer of course. I think that Labview needs to be run as root during the install but my community edition was activated under my user account. After doing that manual copy it worked fine though.

All CLFNs are statically linked to "<resource>\libmuparser-lv.dll"

If you make that libmuparser-lv.* you can leave the default file ending for the shared libraries. .dll for Windows, .so for Linux and .framework or .dylib for Mac OS.

And you don’t rename the default name of libraries under Linux but typically create a symlink with whatever non-versioned name you need.

Edited August 29, 2023 by Rolf Kalbermatter

[AndyS]

I also checked the new VIP and unfortunately it does not work as (I) expected.

Running from the code is fine but when I created an EXE I was wondering why the application builder still did not create a .\data folder. The EXE itself was also not executable (broken arrow). I figured out that you must copy the DLL manually into the same folder as the EXE is. Then runs successfully.

Then I played around because I never experienced that a hard linked DLL was not copied to the support folder by the application builder. The solution was, that the original DLL must not be located in the LabVIEW resource folder but in the project folder of your source code => C:\Program Files\National Instruments\LabVIEW 2020\vi.lib\LAVA\muParser
After I moved it to the new location and updated the DLL nodes, the application builder created the .\data folder, copied the DLL into it and the EXE file was running.

[Porter]

I tried the .\libmuparser-x*-lv.* trick for the CLFN path but when I build a VIPM package, it converts it to libmuparser-x32-lv.dll because I am building on LV 32-bit, Windows. So then the VIs are broken on 64 bit and Linux. If I can preserve the wildcards in the CLFN path it would be ideal.

Here is my latest attempt. Statically linking to libmuparser-lv.dll but located in the vi.lib next to mupLib.lvlib: lv_muparser-2.2.0.6.vip

[Rolf Kalbermatter]

3 hours ago, Porter said:

I tried the .\libmuparser-x*-lv.* trick for the CLFN path but when I build a VIPM package, it converts it to libmuparser-x32-lv.dll because I am building on LV 32-bit, Windows. So then the VIs are broken on 64 bit and Linux. If I can preserve the wildcards in the CLFN path it would be ideal.

Here is my latest attempt. Statically linking to libmuparser-lv.dll but located in the vi.lib next to mupLib.lvlib: lv_muparser-2.2.0.6.vip

A star before the file ending is translated to 32 resp 64, a star for the file ending is translated to the respective platform specific shared library file ending.

Is your shared library name different between bitnesses? Otherwise you do not need a star at all before the file ending.