LabVIEW
Match Pattern Special Characters Confusion
Solved!
@rolfk wrote:
wiebe@CARYA wrote:
@bienieck wrote:
I switched to Match Pattern for simple patterns after watching some presentation from Darren N. Allegedly this function is more efficient.
For the CPU: probably.
For the programmer: not always.
A huge performance difference is caused by the difference in resulting string: Match Pattern returns SubStrings, Match Regular Expression returns Strings... Seems to me Match Regular Expression (an XNode) could be changed so it returns SubStrings too...
Not likely. That would probably require the entire algorithme being implemented in the LabVIEW manager layer, not imported as an external code source from another, non-LabVIEW aware project (PCRE). But reimplementation of the PCRE package in the LabVIEW C manager is extremely unlikely. Not only would it be an immense effort, with likely a lot of incompatible corner cases to the original PCRE quasi standard, but it would also make it extremely awkward to back port any PCRE improvements into that code. The C code dealing with subarrays has to be fully aware of the LabVIEW data type model and that is not something you can force push into any existing code.
The PCRE dll returns indices.
As it is, these indices are used to copy from the original string so SubStrings won't be used (the substrings are build into an array and indexed later on):
It would be easy to prevent this and make the XNode return substrings to the original string.
The code would look silly, but the XNode would return SubStrings for capturing group results.
Search LabVIEW like a graph! 
wiebe@CARYA wrote:
@rolfk wrote:
wiebe@CARYA wrote:
@bienieck wrote:
I switched to Match Pattern for simple patterns after watching some presentation from Darren N. Allegedly this function is more efficient.
For the CPU: probably.
For the programmer: not always.
A huge performance difference is caused by the difference in resulting string: Match Pattern returns SubStrings, Match Regular Expression returns Strings... Seems to me Match Regular Expression (an XNode) could be changed so it returns SubStrings too...
Not likely. That would probably require the entire algorithme being implemented in the LabVIEW manager layer, not imported as an external code source from another, non-LabVIEW aware project (PCRE). But reimplementation of the PCRE package in the LabVIEW C manager is extremely unlikely. Not only would it be an immense effort, with likely a lot of incompatible corner cases to the original PCRE quasi standard, but it would also make it extremely awkward to back port any PCRE improvements into that code. The C code dealing with subarrays has to be fully aware of the LabVIEW data type model and that is not something you can force push into any existing code.
The PCRE dll returns indices.
As it is, these indices are used to copy from the original string so SubStrings won't be used (the substrings are build into an array and indexed later on):
It would be easy to prevent this and make the XNode return substrings to the original string.
There is AFAIK no functionality to create substrings on the diagram. There isn't even exported (accessible through the Call Library Node or in an external DLL) C manager functionality to do that. It's all deep in the various C++ core DLLs that are not accessible from the diagram or a LabVIEW DLL. So, "easy" is a very relative term. And it's not as easy as adding a new node to the palettes "Create Substring", which is anything but easy in itself (which is why the PCRE is an XNode and not a built in function. XNodes are a pain in the ass to create but adding a new node in LabVIEW requires a project proposal of an entirely different type of scope.
Also nodes accepting substrings as parameters, need to have according flags on the relevant connectors, something which I believe is only possible on build in nodes, not subVIs, which Xnodes ultimately are too. If a connector doesn't have that flag, the LabVIEW compiler will promote any substring or subarray to a real string or array before calling that node.
Basically, allowing to use substrings for something like the PCRE node would require a lot of work, either adding new functionality to support substrings and arrays on diagram level (a huge undertaking and very unlikely) or converting the PCRE node into a built in node (slightly more likely).
@DavidBoyd wrote:
I feel that it's also worth noting that Match Pattern is completely agnostic about embedded null chars, whereas Match Regular Expression will totally choke on inputs which contain nulls, since it's a C string implementation.
If memory serves, you may get compile time error if the pattern string is a BD constant containing a null, but other than that, null char problems are reported at runtime.
Dave
Seems to work fine in LV24 64 bit:
returns "a", as expected.
returns "abc\00\00", as expected.
Same with a control as input...
Same with a capturing group (e.g. "(a.*)$").
I wander if this is a (recent) fix or if there are specific situations where it fails.
@rolfk wrote:
wiebe@CARYA wrote:
@rolfk wrote:
wiebe@CARYA wrote:
@bienieck wrote:
I switched to Match Pattern for simple patterns after watching some presentation from Darren N. Allegedly this function is more efficient.
For the CPU: probably.
For the programmer: not always.
A huge performance difference is caused by the difference in resulting string: Match Pattern returns SubStrings, Match Regular Expression returns Strings... Seems to me Match Regular Expression (an XNode) could be changed so it returns SubStrings too...
Not likely. That would probably require the entire algorithme being implemented in the LabVIEW manager layer, not imported as an external code source from another, non-LabVIEW aware project (PCRE). But reimplementation of the PCRE package in the LabVIEW C manager is extremely unlikely. Not only would it be an immense effort, with likely a lot of incompatible corner cases to the original PCRE quasi standard, but it would also make it extremely awkward to back port any PCRE improvements into that code. The C code dealing with subarrays has to be fully aware of the LabVIEW data type model and that is not something you can force push into any existing code.
The PCRE dll returns indices.
As it is, these indices are used to copy from the original string so SubStrings won't be used (the substrings are build into an array and indexed later on):
It would be easy to prevent this and make the XNode return substrings to the original string.
There is AFAIK no functionality to create substrings on the diagram.
Get String Subset always returns a substring.
If an XNode (or .vim or inlined VI) uses Get String Subset there won't be string copies.
Same for subarrays. It works well and is easy.
*******EDIT***********
Here's an example of a .vim, that does something similar to MRE.
LV24, 64 bit.
A slow implementation (as MRE works currently)
A faster implementation (as MRE could easily be made into):
Tested like this:
Slow.vi: 4.25 sec.
Faster.vi: 2.05 sec.
But in this test, LV needs the results of String 3 and String 4, so those will still be copied from their SubStrings to normal Strings.
If those outputs aren't connected
a) the Faster.vim will remove the String Subsets, in Slow.vim that's not possible.
b) the two substrings won't need to be copied.
Testing like this:
Slow.vi: 4.25 sec.
Faster.vi: 2 msec.
