LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Darin's Weakly Nugget - 01/04/11

Solved!
Go to solution
Space for one more VI on the String palette? I have always thought it would be cool if fixed VIs in vi.lib were available as a patch for earlier versions, as possible. A small token for those of us not always on the bleeding edge of LV versions.
0 Kudos
Message 11 of 25
(3,979 Views)

I'll consider your request for even more stuff as tacit approval of my change.  😛

 

Changes to the palettes require the approval of the palette committee (seriously).  So that's a little beyond the scope of the time I have to devote to this issue.  🙂

 

As for the VI patch idea, you may be able to drum up support for that on the idea exchange...

0 Kudos
Message 12 of 25
(3,975 Views)

Darren, I have not done any benchmarking, but you might want to investigate the following:

 

 

  • The "array subset" causes an unecessary buffer allocation. You might as well operate on the original array using an adjusted index inside the loop.
  • If there are more than two "selects" feeding off the same boolean, I usually use a case structure.
Here's a quick draft, make sure if operates correctly (maybe we need a +1 or -1 somewhere, but I think it's OK)

 

0 Kudos
Message 13 of 25
(3,972 Views)

 


@Darren wrote:

I'll consider your request for even more stuff as tacit approval of my change.  😛

 

Changes to the palettes require the approval of the palette committee (seriously).  So that's a little beyond the scope of the time I have to devote to this issue.  🙂


 

You have the I-am-reading-this-on-my-iPhone-but-know-who-wrote-it seal of approval.  I am fairly confident that you got it right which is by far my biggest concern.  If altenbach's mods speed it up, all the better.  

 

Why do I have zero surprise that there is a palette committee, I was hoping you had either reached 'pallete czar' status, or that they would occasionally leave you alone with the release code.

0 Kudos
Message 14 of 25
(3,943 Views)

Darin.K wrote:

What I also like is that there are multiple layers of coolness with this one.  If you look at the BD, you will see that they use Match Regular Expression_Execute.vi.  As I mention in my Regex Helper example, this is the business end of the Match Regular Expression XNode, and I often find the array outputs more useful than the individual submatches.  I also really like its partner which returns the offsets.


Two years later stumbling across this thread again with new eyes, truly discovering "for the first time" Match Regular Expression_Execute.vi and its ability return submatches as an array is pure gold. Thanks again, Darin.

 

Orthogonal to your original post, but still likely of interest to those reading this topic (and incidentally, unashamedly bumping a legendary thread) -- why does Match Regular Expression_Execute.vi return more submatches than expected in the array?

 

In the snippet below, the arrays return two and four submatches, when I would expect zero and one submatch respectively:

 

RegexSubmatchesSnippet.png

 

Screen Shot 2013-01-05 at 12.54.42 PM.png

Message 15 of 25
(3,650 Views)

I can only infer the source of the bug since I can not see the actual code, but the pattern is very consistent:  It seems the number of submatches being produced is equal to the length of the offset array.  This is wrong on two levels, each submatch is two elements in the offset array (begin,end) and the first two elements are for the whole match.

 

That is why I usually stick with offsets and find the submatches myself, or know beforehand how many I expect from the regex (not flexible). Or the program-around-the-bug method of setting the new length to (len/2)-1 (yuk).

Message 16 of 25
(3,623 Views)

First, that VI is really meant to be an internal VI used for the implementation of the Match Regular Expression function (the one you can drop from the palette). I didn't intend for people to call it directly. If you want an official version that is on the palette then maybe you should create an Idea Exchange entry for it. I'll vote for it.

 

As for why it returns extra entries, that is indeed a bug that went unnoticed because of the way it is used in the Match Regular Expression function. My excuse is that I was an intern when I wrote it. 🙂

 

I created CAR# 385272 for this issue. I can't say when it will be fixed.

Message 17 of 25
(3,576 Views)

@AdamKemp wrote:

First, that VI is really meant to be an internal VI used for the implementation of the Match Regular Expression function (the one you can drop from the palette). I didn't intend for people to call it directly. If you want an official version that is on the palette then maybe you should create an Idea Exchange entry for it. I'll vote for it.


Great idea! This function would be a rockstar addition to the String palette. Though, my love affair with Match Regular Expression would be extinguished by this new hottie.

Message 18 of 25
(3,554 Views)

@JackDunaway wrote:
Orthogonal to your original post, but still likely of interest to those reading this topic (and incidentally, unashamedly bumping a legendary thread) -- why does Match Regular Expression_Execute.vi return more submatches than expected in the array?

This issue is fixed in the latest LV 2013 beta. I believe it is reasonable to expect that it will be fixed in the LV 2013 release.

 

Message 19 of 25
(3,473 Views)

CAR 385272 discussed in this thread has been fixed in LabVIEW 2013. For a more complete list of bugs fixed in LabVIEW 2013, check the LabVIEW 2013 Bug Fixes. You can download an evaluation copy of LabVIEW 2013 at http://www.ni.com/trylabview/ or if you have an earlier version of LabVIEW installed and an active SSP subscription, you will be able to download the latest version of LabVIEW through NI Update Service.

 

Jeff Peacock

 

Product Support Engineer | LabVIEW R&D | National Instruments

Message 20 of 25
(3,397 Views)