Leaderboard

This package will be available for download through VIPM in a few days and contains a small mod to the 4.1.0.8 release: [MOD] 3421698 - Message Digest Polymorphic VI should show instance icons

Unless it's a reference - and even then it's still a *copy* of the reference

Crafty! I approve.

I don't disagree with you, but perhaps we're getting ahead of ourselves with that mental compilation. What a branch in a wire means, literally, is that the same piece of data needs to go to two places. What's the simplest way of accomplishing this? Copy the data. In reality, LabVIEW will optimize as much as possible of this copying, but fundamentally every wire branch should be viewed as copying data.

Hi there, I recently wished the OpenG "Get Cluster Element by Name" would work on OO wires... I looked a bit deeper into this, found out that OO wires unsurprisingly aren't mere clusters but that their flattened form is documented in the LV wiki. So I began to write a VI that parses the flattened OO data and returns the contained data clusters. Here is it: Admittedly, I felt a little bit dirty when writing this code :-) Looking for another solution I stumbled upon the LV XML primitives. As mentioned before, these can be used to do much the same, with some limitations. I was only interested in readonly access of basic data types, so it worked for me: I never used these methods in production code, however. candidus

How about this?

That has got to be among the most subtle settings I've (n)ever seen! I thought it might be new, but it was there in LV 8.6 as well! I am very dissapointed in myself for missing that So, we can use the native Format into String and Scan from String functions with a single format specifier string to create and convert a timestamp to an ISO-8601 UTC compliant string. Please excuse me now while I search eBay for a slightly used tantō...

I made a list recently of nodes that ought to accept/output an array of bytes instead of strings: Flatten to String (should be to bytes) and unflatten, FTP, TCP, Bluetooth, IrDA, VISA, String to Byte Array, and Byte Array to String There are a lot of other nodes that need to be changed to accept an encoding input, handle encodings in them (like the HTTP VIs). But the important thing, as mje pointed out, is that it is broken less than ideal. Want to write an app to help you learn Kanji? What about one that supports Hebrew? And Arabic? What about an app that loads Greek data files? All of these can be done, but require an intense amount of research and development into encodings that you shouldn't need to know, some unsupported INI tokens, and potentially changing the locale on your machine. Right now it's not a high priority, but it's something that we're mindful of. If we help our customers stop interchanging strings and data, that will help the LabVIEW community as a whole understand the differences between text and data.

You say that because new executables are released every 6 months, that this would deter the hackers. But then you mention the license generating hacks. And these surely change with every version of LabVIEW released (likely every 6 months). I would be surprised if there didn't exist a license generator for all versions of LabVIEW. I also don't know what techniques the hackers use to create license generators, but from your explanation it sounds like alot of work went into figuring out how to modify this one version of LabVIEW to open VIs with passwords. I guess the point of this post is that I believe someone out there has the ability to open VIs with passwords, in all versions of LabVIEW. I haven't seen it, but this post leads me to believe that. If I did find some page on the internet that explains how to hack all versions of LabVIEW, I'm not sure I would post it. Even this thread makes me nervous. Are we spreading the word on hacking LabVIEW, by just talking about it? However not talking about it may give the false sense of security, thinking that LabVIEW is secure when protecting source code. EDIT: It seems rightfully so, that the page at StackOverflow has been removed.

The scan from string does support UTC by specifying a ^ in the format string If I use %^<%Y-%m-%dT%H:%M:%S%3uZ>T if UTC or %<%Y-%m-%dT%H:%M:%S%3uZ>T if not UTC in your example I think it works as expected. /J

I would argue it is broke. Not being able to natively handle some of the more modern encodings at best leaves LabVIEW's string processing capabilities as a quaint relic of its history. Multi-byte encodings such as UTF-8 are becoming very common. I know I've processed plenty of XML "blindly" hoping there are no multi-byte characters in there for my LabVIEW code to mangle... Strings are not simple byte arrays. In their simplest form, they might be bytes, but still have an encoding attached to them. I completely agree with making the distinction between arbitrary byte arrays and strings. In the case of communication primitives, I'd say they should be polymorphic, allowing either. While I don't expect LabVIEW to overhaul it's string capabilties overnight, I do expect it will happen eventually, and a requisite to this would be making sure the distinction between string and byte data is consistent in the existing language.

I had the same weird thing with the dialog disappearing - my solution was to throw together this little VI to recursively set the property on all VIs in a folder - it's a little quick and dirty but does the trick Mark as Source Only.vi

In my experience the terms "reference" and "pointer" are often used interchangably. How are you differentiating the terms? They both essentially do the same thing--they refer to a location in memory that contains either the data of interest or the next memory location in the chain. Having parallel wires refer to the same piece of memory is done all the time with refnums, be it named queues, events, fp controls, etc, so it's obviously possible. Branching a DVR results in two parallel wires referring to the same piece of memory. Is this a limitation of dataflow languages in general or specific to Labview's implementation. Obviously there are still aspects of dataflow I don't fully understand. Data on the parallel by-value wire has to exist somewhere in memory. It don't get why a pointer to that memory location would not be meaningful. It would violate the principle of data flow, but there are lots of things within Labview that do that already. --------- Many Hours Later ----------- I had to look at this for a long time. When I first read it I envisioned all sorts of weird schemes under the hood that used the upstream prim to modify a value after it has been sent downstream. Here's a summary of the conversation I had with your alter-ego, Evil AQ (pronounced "evil-ack"), in my head. Evil AQ explained a lot of things to me, but I question his accuracy... you know, what with him being a figment of my imagination and all. (Note: My conversations with Evil AQ tend to be rather caustic.) Me: "Huh? The prim that created the value is what actually performs operations on the value downstream? That implies that rather than the data being passed around between prims, the data remains with the orignating prim and downstream prims are passed to it. How... odd. That seems kind of like functional programming. I thought you used C++ under the hood." Evil AQ: "No you dolt. That wasn't a comment about perpetually persistent primitives. Look, when have you ever seen a value on a wire change? Me: "I see it all the time. Wire an integer through an increment function inside a while loop. The value on the wire changes with each iteration." EAQ: "Let me rephrase... when have you ever seen a value on a wire change without that section of code executing again? Me: "Well, the value on the wire has changed after going through the increment node." EAQ: "Uh uh. That's a different wire. Another rephrase... when have you ever seen a value on any single wire, defined as all branches starting at the source terminal and ending at each destination terminal, change without that section of code executing again? Me: "Never. Duh." EAQ: "It's good to know you're not a complete maroon. This would be tougher to explain if I were restricted to finger paints and monosyllabic words." Me: "Monobillasic... monosymbolic... monosy... what?" EAQ: "Never mind. What would happen if you had a raw pointer to a value on a wire?" Me: "I could have Interfaces!" EAQ: "Slow down there Flash. Think about this for a minute. What would happen to the value on the wire?" Me: "Ohhhh... it would change." EAQ: "Very good. You pumping a full 100 Watts through that brain or is your dimmer switch turned up a little too high?" Me: "What about control refnums? They change values." EAQ: "There's a reason they're called 'control' refnums. They refer to controls, not wires. Control values can change. Wire values cannot." Me: "Oh. Right. Well queues can change the values of items that exist somewhere in memory. What about them?" EAQ: "Yes, but they are changing the value of an item the queue refnum refers to. They are not changing the value of the queue refnum itself, which is what actually exists on the wire." Me: "I see. But in reality by-val wires don't contain the data itself, do they? If they did memory allocations would take place at the moment the wire branches and I've know that's not right." EAQ: "Correct, wires do not contain the actual data." Me: "It actually refers to data that resides elsewhere in memory, right?" EAQ: "Sort of correct. Wires don't refer to a piece of data so much as they refer to a specific terminal on VIs and primitives. A terminal** is essentially something that can define the values of a piece of data, such as a control, indicator, constant, etc. and includes input and output terminals to prims." (**Evil AQ didn't know the correct terminology for this so he used the word 'terminal.' Luckily I knew what he meant.) Me: "So shouldn't it be possible to create a refnum that simply refers to the same memory location that a wire does? Ha!" EAQ: "Well yes, but it won't work in the way you're thinking. Try looking at it this way... by val data exists only in terminals. Wires are simply a graphical representation of how the terminals are mapped to each other. Ostensibly every time data "flows" across a wire a data copy is made and placed in the memory location that represents the destination terminal. While in principle you could have a refnum that refers to the same data the wire 'refers' to, effectively it would be just like a value property node for one of the terminals. (It doesn't matter which one, since they all contain the same data values.) That scheme would consume LOTS of memory, so the Labview compiler is smart enough reuse memory when it can. For example, since all the terminals a wire connects to must contain the same data values after executing, the memory locations that are represented by the terminals are actually pointers that refer to a single piece of data. Sometimes the memory location of that data can be reused by other terminals further downstream. Sometimes it can't. Ironically, obtaining a reference to that memory location is one way to guarantee it can not be reused." Me: "Really?" EAQ: "Well yeah. You're referencing the value in the terminal, which doesn't change until that section of code executes again. If downstream operations change the value a new copy must be made to avoid corrupting the old copy, which you have a reference to." Me: "I get it now. Thanks Evil AQ. You're the greatest." EAQ: "You sound like my mother. Now beat it punk, I'm trying to sleep." So did Evil AQ do a decent job of explaining things to me?