Jump to content

1D Array to String not compiling correctly


Recommended Posts

Oh man that looks like a painful thing to debug and isolate.  And an even bigger pain to convince NI that there is an issue when someone in the support call will just have a goal of getting your code working.  I haven't seen anything in 2020 like this yet.  I have seen code that application builder says is broken, I go and run the VI it isn't broken, and then the build can continue. It is related in that it seems to be a compiler issue.

Link to comment

This happened on a virtual machine that only had LabVIEW 2020 installed. VIPM was always configured to mass compile VIs after package installation. If this happened even when packages were being mass compiled, what else is lurking under the hood waiting to be found?

I want to assume that had I built an EXE in this state, this problem would have gone away.

Link to comment
  • 4 months later...
17 hours ago, Jim Kring said:

 

The current implementation of 1D Array to String uses an EOL constant (image.png.1dba7d18251686936279887d5ce96355.png) to build a regular expression -- the EOL is platform dependent (it's CRLF "\r\n" on Windows and LF "\n" on Linux and Mac).

LabVIEW for Mac OS Classic used actually a "\r" character for this, since the old MacOS for some reason was using yet another EOL indicator.

Quote

A More Robust Implementation (work-around)

Looking at that 1D Array to String code, I don't really love how it's building the regular expression using an EOL constant.

I think that a more robust solution would just build the regular expression as "[\r\n]+$" (one or more Carriage Return or Line Feed characters at the end of the string).

image.png.4819762dcd810c33bb896dea5fa56403.png

This would be platform independent and not suffer from the compiler bug we're discussing here.

This is strictly speaking not equivalent to the originally intended implementation since this would remove multiple empty lines at the end while the original one only removed one EOL. However the Array to Spreadsheet String function should not produce empty lines (except maybe if you enter a string array of n * 0 elements) but that does not apply for this 1D array use case.

Link to comment
2 hours ago, Rolf Kalbermatter said:

This is strictly speaking not equivalent to the originally intended implementation since this would remove multiple empty lines at the end while the original one only removed one EOL. However the Array to Spreadsheet String function should not produce empty lines (except maybe if you enter a string array of n * 0 elements) but that does not apply for this 1D array use case.

You're right, Rolf. I can see some situations where my proposed "fix" would fail -- if the last element(s) of the Array of Strings intentionally contains EOL characters at the end  ["\t", "\r", "\n"]

image.png.2e0a73d1e25790bb71a62f83048a61ae.png

Now, looking at the "1D String Array to Delimited String.vi" that got added to LabVIEW (I'm not sure which version), we see it has a similar implementation (although it doesn't use Match Pattern and simply removes the calculated length of the EOL at the end of the string).

I wonder if this VI suffers from the same constant folding compiler bug reported in this thread (I'm going to do some testing).

 

image.png.4f1a1129fece3c6abd254eb66bcd9801.png

This all makes me wonder if we should be creating the delimited string in a more low-level way (instead of relying on the Array to Spreadsheet String function, which adds the EOL at the end).

Here's a simple solution:

image.png.7b5f70bdacb026658c590a4843a81239.png

 

And, here's a potentially more performant solution for larger strings:

image.png.9c758cdc9caee40be36df812afe217b7.png

Thoughts about the best approach here?

 

Link to comment

We've figured out more information.

The problem seems to go away if you turn ON "Separate compiled code from source file" for 1D Array to String

Meaning: the problem occurs when the compiled code is saved in the VI source file.

It would seam that LabVIEW is not correctly determining when it needs to recompile/save the VI when switching between RT and Windows.

Link to comment

OK, here's a game plan I think will work to fix the issue, yet without changing the behavior of the code.

Since LV2009 (the version of LabVIEW the package is currently developed in) doesn't have the "Separate compiled code" feature), we'll implement a work-around by creating a special subVI to get the EOL that is not affected by the bug (Note: ignore the fact that the screenshot shows this VI open in LV2020).

We'll do this by calling the Array to Spreadsheet string function with empty string inputs. It appears from testing that this does not get constant folded (or at least is not impacted by the bug). And, we'll cache this value for performance on subsequent calls. It'll all be packaged into a tidy little sub-VI, so that it's obvious what we're doing and why.

image.png.f83b8c9aa9f3d49b44dc81564b9f8645.png

I've released this as version 4.1.2.18.

Moving forward, we'll upgrade the sources for this package to LV2013 and mark all the VIs for "Separate from compiled code".  We would have done that sooner, but there was a build issue in 2013, due to the fact that NI introduced a VI called "Trim Whitespace.vi" that shares the same filename and thus collides with the OpenG VI (in source code form before it's name mangled in the build process). But, that's a different story (and I think we can work around it during the build process)...

  • Like 1
Link to comment
  • 4 months later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

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