[CR] LV muParser

[AndyS]

@Porter - do you see a chance to integrate the binary-extensions and the precedence bugfix into the new version?

[Porter]

Yes. Looks like your fix was added to release v2.3.5 of muparser.

I will rebuild the dlls and prepare another release for testing.

[Porter]

On 8/30/2023 at 8:06 PM, Rolf Kalbermatter said:

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

The shared libraries were named libmuparser-x##-lv.XX

Where ## is bitness and XX is file extension. So libmuparser-x*-lv.* worked wonderfully on the development version of the code.

Unfortunately as soon as I build vipm package, the *s get replaced with 32 and dll. So when I open the vis on x64 labview, they are pointing to the wrong dll.

My solution is link the CLFNs to libmuparser-lv.dll and have a post-install vi copy the appropriate version of the shared library to that filename. I know it looks weird to see a dll in linux, but it doesn't seem to break anything. 

[Rolf Kalbermatter]

5 hours ago, Porter said:

Unfortunately as soon as I build vipm package, the *s get replaced with 32 and dll. So when I open the vis on x64 labview, they are pointing to the wrong dll.

My solution is link the CLFNs to libmuparser-lv.dll and have a post-install vi copy the appropriate version of the shared library to that filename. I know it looks weird to see a dll in linux, but it doesn't seem to break anything. 

I would consider that a bug in VIPM. It should not rename the DLL and linkage name in the VI in this case or at least offer an option to disable-that. But your solution with the Post Install works and is what I always do. VIPM always lacked a few features to properly handle 32-bit and 64-bit binaries. I haven’t checked in the latest version but there was no way to distinguish files to be only installed for 32-bit or 64-bit only and even if the latest version would support that I’m hesitant to use it as VIPM tends to create packages that won’t be installable by older versions of it.

Edited September 3, 2023 by Rolf Kalbermatter

[Porter]

Here is the latest build with bitwise operators implemented: lv_muparser-2.3.0.1.vip

I didn't manage to cross-compile for linux 32-bit. So only linux 64-bit gets the new operators for now.

Here is the muParser source code (modified): muparser-2.3.5.zip

Note that I changed the operator precedence to match that of C as described here: https://www.geeksforgeeks.org/operator-precedence-and-associativity-in-c/

[predovicbrown]

On 9/3/2023 at 9:54 AM, Porter said:

Yes. Looks like your fix was added to release v2.3.5 of muparser.

I will rebuild the dlls and prepare another release for testing.

Thanks for this

[AndyS]

4 hours ago, Porter said:

Here is the latest build with bitwise operators implemented: lv_muparser-2.3.0.1.vip

I installed it and all tests have been successful! Great! Thank you!! 🙂

The only I'd like to remark is, that LabVIEW was searching for the DLL when I placed a muparser VI for the first time. After a while the dll was found the reference updated. LabVIEW did not search again.

[Porter]

2 hours ago, AndyS said:

The only I'd like to remark is, that LabVIEW was searching for the DLL when I placed a muparser VI for the first time. After a while the dll was found the reference updated. LabVIEW did not search again.

What is the path to your vi.lib? Are you using labview 64-bit?

[AndyS]

32 minutes ago, Porter said:

What is the path to your vi.lib? Are you using labview 64-bit?

C:\Program Files\National Instruments\LabVIEW 2020\vi.lib

Yes, LabVIEW64.

I have added another VI search path in my LabVIEW paths configuration. This is probably the reason why it took a while until it found the DLL.

[Porter]

I finally got the 32-bit shared object built on Linux. After 3 hours of fiddling I simply re-installed gcc-multilib and it just worked. 😡

I have pushed the changes to github. After testing, this will be v3.0.0 because I expect the static linking to be a breaking change in some instances.

The next step is to compile a large list of test cases to confirm that the new operators are behaving as expected under as many corner cases as we can think of.

[AndyS]

Sounds great! Thank you for your work!!!

[Porter]

I have uploaded the new release to vipm.io

We are now at release v3.0.0 since this is a breaking change.

I also started some documentation: LV-muParser User Guide.pdf

[AndyS]

Great work - thank you! I already installed it and testing will be done implicitly in the next weeks and months.

[AndyS]

Two questions:
1) I defined a formula with a missing variable (see picture). I expected an error but I got a NaN as result. I can live with this but is it really as expected?
(Remark: I did not test it with the old package version, so I don't know if the behaviour has been changed with the update)

 

2) Error codes:
The Error code range of 5000 + x is used by many user VIs. Would it be possible to have an additional input in the Construct.vi that allows to define the error code offset? (5000 as default)
 

[Porter]

1) That is indeed the expected behavior. Variable values must be explicitly specified. Their default value is NaN. Note that you are defining x,y,Z as constants in the above example.

2) I was using 5000 range because this package is not NI Tools Network certified and therefore I have no reserved an error range to target. If there is a better starting number, I am open to suggestions. I would not propagate an error code offset input all the way to the top level though. Best to just pick a range and stick with it. But I do understand that 5000 is commonly used at the top level of user applications.

[AndyS]

1) sorry, you're right. They are constants from the view of the muparser 🙂

2) My thought with the optional input was to give every user the ability to shift the error codes into a range that best fits to his project or application.
Alternatively there could be an additional VI that configures a (functional)global with this offset value. This would avoid the additional input of the Construct.vi and it would be sufficient to configure it once per application run ... if the input itself is what you don't like.

The NI documentation says that the free ranges are -8999 to -8000, 5000 to 9999 and 500.000 to 599.999. I don't know which one is the best.

https://www.ni.com/docs/en-US/bundle/labview-api-ref/page/errors/error-codes-and-messages.html

Edited October 12, 2023 by AndyS

[Porter]

Seems like the 500 000+ range would be a good place for these standard but non-NI certified error codes to go.

I will make another release that will be focused on improved error handling/reporting. I can see a few VIs that should be touched up in this regard.

[anthony82]

On 9/3/2023 at 9:54 AM, Porter said:

Yes. Looks like your fix was added to release v2.3.5 of muparser.

I will rebuild the dlls and prepare another release for testing.

Ya, thanks for this

[Porter]

Done. New error code offset is 515000.

I also compiled muParser for cRIO RT Linux. You need to manually copy the .so file to /usr/local/lib/ on the cRIO then run ldconfig.

Linux 32-bit support has been axed. There is no 32-bit LabVIEW for linux since 2016 if I'm not mistaken.

 

[Rolf Kalbermatter]

7 hours ago, Porter said:

Linux 32-bit support has been axed. There is no 32-bit LabVIEW for linux since 2016 if I'm not mistaken.

I was just recently trying to find out where the cutoff point is. In my memory 2016 was the version that stopped with 32-bit support. But looking on the NI download page it claims that 2016 and 2017 are both 32-bit and 64-bit.

But that download page is riddled with inconsistencies.

For 2017 SP1 for Linux you can download a Full and Pro installer which are only 64-bit. Oddly enough the Full installer is larger than the Pro.

The 2017 SP1 Runtime installer claims to support both 32-bit and 64-bit!

For 2017 and 2016 only the Runtime installer is downloadable plus a Patch installer for the 2017 non-SP1 IDE, supposedly because they had no License Manager integration before 2017 SP1 on non-Windows platforms. Here too it claims the installer has 32-bit and 64-bit support.

So if the information on that download page is somewhat accurate, the latest version for Linux that was still supporting 32-bit installation was 2017. 2017 SP1 was apparently only 64-bit.

Of course it could also be that the download page is just indicating trash. It's not the only thing on that page that seems inconsistent.

Edited November 17, 2023 by Rolf Kalbermatter

[Porter]

Thanks Rolf for the thorough analysis.

I axed support because cross compiling for 32-bit Linux was another hassle, and I suspect that nobody will ever need it. I also noticed that the produced .so was 3MB which seems to be abnormally large and I don't have time to figure out how to get the size back down to a reasonable 300-500kB.

[AndyS]

Hello and happy New Year! 🥳

Today I upgraded via VIPM from V3.0.0.3 to 3.1.1.3 and I was wondering why my application was not executable any more on LabVIEW 64Bit but still on LV 32Bit.

I figured out the the DLL files for 32Bit and 64Bit are binary identical. Adding the DLL from the LV64 manually to a DLL node I got this error:

So the VIPM installs the 32Bit DLL where the 64Bit DLL should be.

Edited January 8 by AndyS

[Porter]

Thanks for bringing this to my attention. Not sure why the dlls and so files were stripped out of the source distribution's always included list.

This is now fixed in v3.1.2.1