Justin Goeres

QUOTE(Gary Rubin @ Jun 19 2007, 11:57 AM) Welcome to the wonderful, wacky world of regular expressions. ^ means "whatever matches this regular expression has to be located at the beginning of the string" . means "match any character" + means "match whatever is before this, 1 or more times" (it works just like the http://zone.ni.com/reference/en-XX/help/371361B-01/glang/match_pattern/' target="_blank">Match Pattern function.) So ^.+ literally means "match any number of characters (but at least one), located at the beginning of a string." Practically, if I'm not mistaken it will match anything except an empty string. The result is that the suggested search will find all the Description fields that are non-empty. I think you could probably get by with just .+ as well. I don't think the ^ really adds anything in this case. The dialog doesn't exactly make it clear that the suggested settings will search Tips and not just Descriptions, but they do.

That's bad dataflow. Lots of race conditions. I would refactor it and add some semaphores. Possibly queues, also.

QUOTE(h1voltage @ Jun 18 2007, 02:03 PM) ImageMagick, which you can access using the LVOOP ImageMagick Interface library in the Code Repository reads & writes (& scales, etc.) SVG data, although I had to update to the latest version (6.3.4-Q16) to get SVG handling to work (I'm not the only one): http://forums.lavag.org/index.php?act=attach&type=post&id=6145 However, that just gets it into a picture contol (or a file of a different format). I'm not sure that helps you real directly. EDIT: The screenshot shows a "-resize 750" on the block diagram, but the front panel shows a "-resize 500". That's because the two screenshots aren't from the same run :headbang:

Bringing just a minor point over from this thread... QUOTE(crelf @ Jun 18 2007, 09:38 AM) Really? I wonder why... I can tell you that I was told that a few years ago by one of the developers of MAME. At the time, MAME was considering (actually, in the process of) moving to the GPL. But then this dev took a job with Microsoft (they bought his employer) and the license change got killed because his new employment contract specifically forbade him from having any contact with GPL software in source code form. He also said he was not the only person inside Microsoft subject to those restrictions. Whether or not that sort of thing was practically enforceable was up for debate, but he certainly wouldnt've been able to contribute to MAME anymore, which would've been a disaster. Basically, what it amounted to (he surmised) was that Microsoft was paranoid about being accused of misappropriating GPL software into their products. Sort of the "1% Doctrine" of software licensing . This was about 4 or 5 years ago now. I don't know whether it's still true.

QUOTE(Eugen Graf @ May 7 2007, 11:43 PM) I regularly do something like this, but the term I use for them is observers. I have a hunch that Publish/Subscribe and Observer may have very distinct meanings in software design, and I'm not completely sure my term is strictly correct -- if someone has semantic arguments to make either way I'd be all ears. I frequently use a variant queue, although it depends on the context. If all my observers to a particular resource will be getting the same type of data, I would typically define the queue for that data (and typedef the data). But in a general sense, the variant queue works fine. I've hacked up a little example (in LV80) that illustrates basically what I do. This example has a simple "Publish!" button and an associated DBL value that is published to any of 3 registered observers. Each observer can be registered and unregistered with buttons on the UI. Good Luck! Justin http://forums.lavag.org/index.php?act=attach&type=post&id=5777 http://forums.lavag.org/index.php?act=attach&type=post&id=5775 http://forums.lavag.org/index.php?act=attach&type=post&id=5776

I'm looking for a tool to facilitate some online collaboration. Specifically, I'm looking for a virtual whiteboard. Something I can use while I'm on the phone to engineers/customers/whoever at a remote site that we can use to all doodle on the same canvas. Built-in chat is not required. That's what Skype/IM/the phone are for. Browser-based software is highly preferred over something the users have to download and install. Useful tools include freehand/line/basic shape drawing, arrows, and text annotations. Being able to upload existing images and PDFs would be very good. Ability to save/export the whiteboard and (preferably) reload it later is good (partially covered by the previous bullet). Cross-platform is good, but not strictly required. Cheap is OK. Free as in beer is good. Free as in speech is better. The only thing I've found so far that seems to hit those bullets pretty well is Vyew, but I haven't tried it. It seems to be free right now, but they mention moving to a pay model for a "premium" level service in the future. Has anyone tried Vyew? What do you think of it? What else is out there? As a final note, does virtual whiteboarding software even work? I mean, there's no real substitute for standing around a physical whiteboard and screaming at each other, but do virtual whiteboards come close enough? If not, what do you use instead? EDIT: I signed up for a Vyew account to play around and it looks like they've already implemented some of their "premium" level stuff. The free version still seems fairly accessible, at least for fairly simple tasks.

Whew, thanks. And since that's plugin specific instead of site-specific, it fixes the entire Internet! :thumbup:

Did the video auto-play for everyone else? It's kind ofprogressively more annoying when it plays every time a page containing it loads (e.g. on the front page, on the thread page, and now on the reply page). Apropos as that may be given that it's a Dilbert video ... As a side note, in order to find it the first time I had to play whack-a-mole in a forest of new Firefox tabs I'd just opened. There was kind of an "aha" moment as I scanned through them trying to figure out which site could possibly have the video embedde... oh yeah, it's probably LAVA. ARGH. I clicked "Preview Post" and it played again. Unsurprising, and ironic. And now it's going to do it again when I click "Add Reply."

God Bless Coyote Ugly.

And now you know about the rocky on-again/off-again relationship I have with documentation

As a follow-up to this, here's an example of a 32-bit (RGBa) PNG image: on a LabVIEW (8.2) front panel (1) as a decoration, and (2) loaded into a Picture Control. As you can see, the decoration handles the alpha channel just fine. But the picture control appears to be thresholding it to a single transparency bit.

Yes, but that's outside the 8 bits of space in the color map for the icons. Icon transparency is done by masking the 8-bit icon with (the envelope of) the 1-bit icon if I recall correctly. What I was talking about is full RGBa 32-bit color. That's 8 bits of alpha instead of just 1 like the "T" gives us now. Not that there aren't a lot of other things I'd like to see fixed/added in LabVIEW before that, of couse! EDIT: Before someone else points it out, if I'm not mistaken we do have full RGBa color on PNGs when we use them as decorations. I don't have time to test out exactly where else we might or might not have that, but that's at least one place.

Aha! That's it, then (plus 5 colors??). Thanks! It depends on where the limitation is being enforced. If it's actually the _editor_ that's doing the color substition, then maybe such a thing would be possible. But if the substitution is happening when LabVIEW itself stores the icon bitmap, then I think we'd probably always be at its mercy. Perhaps someday NI will just give us support for glorious 24-bit (no, make it 32-bits with an alpha channel!) icons for our VIs.... :thumbup: .

Ben, I noticed similar things (and actually, 0 and 255 are multiples of 51 also ) when I decomposed PJM's and my colormaps into their RGB values. Every valid channel value is some multiple of 17. This is slightly, but not entirely, surprising because 255 / 17 = 15 (which is hex 0xF). It's basically the equivalent of taking a 24-bit colorspace (8 bits per channel) and dropping the least 4 significant bits for each channel to get down to a 12-bit (4096) colorspace, then dropping a few more colors to get down to 8-bits-worth (255) in total. I have a hunch that the 8-bit colorspace LabVIEW is using might be some kind of very standard one, but I don't know enough about this kind of thing to just come out and claim that . And then for icons they're just using a further subset of it. FYI, the 16-color and B&W icon versions in the Icon Editor impose their own restrictions on the colors you can choose, as well. 16-color is (of course) a subset of the 256-color, and it's particularly humorous to use the color picker while editing a Black & White Icon (does anybody even do that anymore???).

Thanks! I checked the RGB values of your color map against what I'd generated. Your map matches what I'd found, but you indeed have extra colors (a total of 256). It appears from a quick comparison that the extra colors come from: (1) A few extra shades of grey. (2) The same few extra shades of each "pure" channel (e.g. RGB (136,0,0) -- a darkish red). However, if you actually try to locate any of those colors in the Icon Editor color picker, you can't find them! Additionally, if you manually enter the RGB values into the color picker fields, the Icon Editor substitutes a different color to the one you picked! (It looks like it picks the closest one it can find.) This leads me to believe that your palette is the "correct" one, but that for some reason LabVIEW is restricting us to the smaller set of colors 221 colors I originally found. I even checked this programmatically. I created a rectange of (136,0,0) and set a target VI's icon to that (via property node). When I open the VI's icon in the Icon Editor, however, the rectangle's color isn't (136,0,0), it's (153,0,0)! It's all kind of weird. EDIT: Here are the colors that you have in your map, but that you can't actually use in VI icons: (Note that the last 5 elements of the last row are black and shouldn't really be there. They're just an artifact of reshaping the array so it's prettier. There are 35 extra colors total.)

I've been scrubbing over the color picker in the LabVIEW Icon Editor and have noticed something. When you use the color picker in the Icon Editor, even though your monitor displays a ton of colors, LabVIEW restricts what you can pick. Along the "greys" bar at the top, there are actually only 11 unique RGB values you're allowed to get at. They are: Grey RGBs (0,0,0) (17,17,17) (51,51,51) (68,68,68) (102,102,102) (119,119,119) (153,153,153) (170,170,170) (204,204,204) (221,221,221) (255,255,255) Likewise, in the "muted" & "saturated" areas (stealing my terminology from Christina), my manual scrubbing so far indicates that you're limited to any combination of the following hues: Saturated & Muted RGBs R: 0/51/102/153/204/255 G: 0/51/102/153/204/255 B: 0/51/102/153/204/255 If we calculate all the possible RGB colors we can select from these, we get 63 = 216. Adding in the grey shades that weren't already duplicated in that calculation, we get a total color palette of 216 + 5 = 221 valid LabVIEW VI Icon colors. This raises a question: Are these all the colors we can use in LabVIEW VI icons, or are there 34 more that I'm missing? The motivation for the question is that I'm trying to dither some images for use in LabVIEW icons using an external tool, and I want to do it right (LabVIEW's color substition is rather lacking). EDIT: I generated a colormap of all 221 colors described above, as a PNG. Each color is a block (and black is duplicated a few times), but it's all in there. Just in case anyone besides me finds it useful: 1x1: 3x3:

File Name: ImageMagick Batch Image Converter VI File Submitter: justin.goeres File Submitted: 27 Nov 2006 File Updated: 12 Dec 2006 File Category: Machine Vision and Imaging ImageMagick Batch Image Conversion Tool V1.0.1 Copyright

(If you're not using a LabVIEW-generated XML file) I've had a pretty good experience using the LabXML toolkit. I had to move some files around to get it working (it didn't want to find a couple libs or dlls, as I recall), but once I got past that I found it fairly easy to use. I use it to translate the XML output of my bug tracker to generate nice-looking plaintext release notes.

It might be an image bitmap. Anybody care to convert those ASCII values to an 8-bit picture control and see what colors we get?

Back in v7.1.1, I used to be able to create a reference to the Cursor Legend (an Array, as it happens) by right-clicking on the Cursor Legend of a Waveform Graph on the front panel: However, if I save the code above (in 7.1.1) and open it in 8.0.1 or 8.2, the reference constant I created disappears and the code (rather obviously) breaks! See below: The general question this raises is how can I programmatically control the properties of the Cursor Legend (now "Cursor Palette," I guess) in LV8.2? I've scoured the property tree and either I'm missing it or it's gone. Am I just blind? I've also attached the VI file shown above, so you can play along at home. Open in 7.1.1 and it's all kosher. Open in 8.x and it's bad joss. Justin Download File:post-2992-1163018529.vi

I wasn't sure where to drop this topic (Hardware >> Macintosh, or is it Windows-related? ), so apologies if it's in the wrong spot.... I saw this thread about running LabVIEW on the new Intel-based MacBooks, but I have a different question. Has anyone booted Windows on these machines and tried to run Windows LabVIEW? There are basically two ways to boot Windows on the MacBooks. One is to dual-boot, and the other is to run a virtualization solution (like something from Parallels). I'm imagining that LabVIEW itself might run fine in at least one of those scenarios (as long as Windows is happy, which reports indicate it is), but I'd be more concerned about NI-DAQ. Any experiences? Any hypotheses? Any brave souls want to give me a bag of money to buy a MacBook with so I can carry out this daring expriment... for the good of the community and all? Justin

Since LabVIEW source code is binary by nature (rather than text-based), I think the only way a quine makes sense is if you generate the code into the development environment (e.g. via Scripting). Another idea would be to actually write the binary representation of the VI to disk. I think that would still qualify. The trick, however, is that a true quine can't require access to its own source code to do its magic. I.e. a LabVIEW quine should run correctly even if its block diagram has been removed. Exactly. Just because an idea or tool can be used maliciously, that's no reason for everyone to run away from it. Malicious code is a fact of life in every other language, and humanity still limps along in spite of it. I suppose some day we'll all wake up and find someone screaming on LAVA about their whole project tree being ruined, and that will suck. But one could argue that having proofs of concept floating around would allow the LabVIEW world to prepare itself for that. Justin

You're orbiting around the concept of a LabVIEW quine. I've been meaning to raise the same idea in this forum for a few weeks, but I wanted to play around with VI scripting a bit more seriously before bringing it up. Quines are mostly an academic exercise (unless you're Evil... :ninja:), but they're really fascinating from that point of view. I'd love to see a quine done in LabVIEW. More importantly, I'd love to see lots of different quines done by different LabVIEWers. Care to share the code? Justin

I've used the PCRE library for years in lots of contexts (including in LabVIEW back before 8.0). Based on that experience the attached code looks like a bug to me. The regex ^$ should match a string that has nothing (the affirmative kind of nothing ) anchored to both the beginning and end of the subject, i.e. the null string. But the LabVIEW Match Regular Expression function returns a match offset of -1. It seems to me it should return 0. Maybe the -1 match offset is technically correct (because the subject string is length 0), but even if that's the case it seems like Match Regular Expression should return some indication that it matched successfully. I really liked how the old PCRE LabVIEW returned a boolean for "Matched?" instead of just the match offset... EDIT: OK, here's what I'm talking about. This is the same subject and the same regex, but the old PCRE library returns a successful match, and also returns the proper (strictly speaking) null string in the substrings array.

I would like to further note that anything involving eating and recursion is just sick.