mje

I suspect it's array based, but who's to say? I'd toss that under the "all other implementation details are equal" part. While considering a queue I was focusing only on push/pop scalar operations at the ends of the buffer otherwise there are pretty big differences between the implementations.

Queue vs DVR shouldn't make much difference if all other implementation details are equivalent since both use the same underlying synchronization method. That said the synchronization will prevent either method from being as peformant as a native array implementation if access speed is a concern.

I'm fully on board with not wanting to check flags to see if an input is valid. I dislike the idea of relying on a compiler to decide if it can throw away dead code paths since I have no feedback on what the compiler does-- it's too opaque. It also creates a weird pseudo dependency inversion (not having a CS backround I'm unaware of a name for what I'm thinking). If I rely on the compiler I can't benchmark a VI without considering the context of how that VI is called. I also can't see a way to resolve this when you consider dynamically loaded VIs. What happens if after analyzing all the statically linked callers to a VI the compiler decides some chunks of code can be discarded and not computed. Then I load a VI which wasn't part of the original application which requires the discarded code. Clearly some alternate implementation needs to exist that either has the fallback unoptimized VI or the compiler has to create a multitude of implementations for different optimization paths (b l o a t). Regardless, debugging what's going on would be fantastiaclly difficult if all of this is hidden under the hood of the black-box compiler. Similar issues creep up when you consider executable distributions of libraries. How can I create optimized versions of a library if I'm unaware of the contexts from which it will be called? Relying on the compiler then requires my library to be distributed as source code such that the consuming application can make the optimizations. Maybe I don't want to do that? TL;DR: I've had the initial reaction of wishing I could be aware of unwired inputs before, but when I think about it I ultimately go down the path of VI (not object) polymorphism because I believe it to be a better solution. VI polymorphism allows me to clearly define implementations with varying input parameters and the execution path is fully resolved at compile time. It also allows me to clearly define multiple implementations which can be executed by other VIs which may have dynamic linkage. While the grammar of using a polymorphic VI isn't quite what you're after, I believe functionally the existing language is already there.

Indeed. I also believe the .NET interface exposes the window object (which is the global javascript scope) along with the contained document object. Well it did back in the MFC days... .NET wasn't really a thing last time I did something like this. Using the python server would also allow me to create some sync objects in that scope to push data through application boundaries. Would still need to poll though. Either way, this seems like a lot of work. I'm doubtful I'll have enough of a time budget to explore such a thing given how little reuse something like this would see.

I mean I can't contact any remote server. Keeping everything on the localhost, directly manipulating the hosted document-- that's all fine. "Web" technologies aren't off limits, I just can't generate network traffic. If the application pokes the outside world it can't be used by some of our customers.

Agreed, until the stale nature of the NI platform changes I don't see considering it for serious UI work any time soon. I need an entirely offline solution, and although the main draw of plotly is the online sharing aspect, it still has rather capable offline code. For all I know the rendering may be handled by a more appropriate lower level library that I can use directly. I just haven't had the time to peel back that onion yet. Kudos for the recommendations, Shaun.

Are there any plotly experts out there that have had experience integrating it into LabVIEW which would care to lend an ear? I've dabbled with it for a day or two and am convinced it can provide some solid data visualization options that overcomes a lot of the limitations the native rendering tools in LabVIEW burden us with. As I see it there's two paths to getting plotly data rendered in a LabVIEW application: Use Python to leverage plotly's offline capabilities to render static images and dump them in into a picture control. While this would produce visualization beyond LabVIEW's current capacity with relative ease, I'm skeptical I can get enough data out of plotly for this to work since I'd be expected to provide context sensitive data based on cursor position and clickable data points. Host an HTML context in LabVIEW and dump everything into plotly.js. This would be a significant amount of work to get data in and out of the hosted context but I've done so in the past. I frankly see this as a very ugly option. Has anyone looked into plotly or other alternative rendering libraries? I also looked at the Advanced Plotting Toolkit but it seems to also lack an obvious way to extract context from the resulting images-- I need to translate cursor location to data points. I also can't bang a fast enough render time out of it to be useful. -m

I've had to tweak some ping/timeout settings for a build manager I wrote. My VI Server refnums were going stale because the foreign application instances would be so busy making an exe they wouldn't reliably service VI Server requests for long periods of time. I'm pretty sure I ended up putting a timeout on the order of an hour or two, so I think it is possible to tweak with this stuff. I can't remember how, if you can't find anything I can try to dust the code off early next week.

Let's not get carried away, I doubt the lack of inplaceness was the limiting factor for most use cases, which probably has to do with the issue not seeing much daylight. Don't get me wrong, I've run across a few situations where copies were performance killers (which is how the idea exchange post originated) but they've been few and far between. These include working with nested structures or where the attributes are just plain big. Most of the time the copies are small and there are other operations on the retrieved values that take far more time. That said, the syntax alone is useful so I'll likely end up abusing the IPE a lot for this even if it's not needed. The extra nanoseconds saved in otherwise slow code will be incidental.

Fantastic! Some of us have been waiting for this for a while. VASTLY is not an overstatement.

I admittedly haven't touched C++/C# in over a decade beyond some very minor dabbling. When embedded became a focus for me two years ago, I went to C. As weird as it sounds, I use a lot of object oriented design in my C code. There's no wizardry to object oriented design-- you don't need special language syntax to do it. Having dedicated grammar helps a lot, but it's not like interfaces, encapsulation, or inheritance aren't possible without built in object oriented constructs. Most of my C code is fully encapsulated, my state machines are usually interface based, and I even have the occasional sprinkles of inheritance in there where it's just too darn useful to ignore. Honestly, the only thing I miss about C++ is the verbosity that becomes necessary in C when you start dealing with functions to support types (methods). Having to explicitly pass the type into each function is awfully repetitive, but it doesn't change anything functionally.

Fantastic, thanks jacobson. Shaun, the issue was a subroutine VI can't call inline VIs unless those VIs were also set as subroutine priority. The priority of an inline subVI should make no difference (nor should the execution system for that matter). Since there's a CAR that describes this, it would be a bug so there's no worry. If it had not been a bug there would be some serious ramifications.

Hi gang, it's been a while. I'm trying to squeeze performance out of one of my consumer loops which is being outpaced by it's producer and came across this little ditty: Full error text: Subroutine priority VI cannot call a non-subroutine priority subVI. The rub here is all the SubVIs called are inline accessor methods, but LabVIEW won't have any of it since they're not explicitly given the subroutine priority. The errors clear if I assign the inline VIs to subroutine priority. Is this intended? TL;DR: It would seem the inline code preserves its priority setting independent of the caller. Or it's a bug. I get that inline code doesn't quite act the same as if you'd dropped the same code onto the calling diagram. There's an implicit context at play, as if you had slapped a single frame sequence structure around your code. If I have an inline VI that simply rotates an array for example and call it from another VI we effectively get: The sequence frame must be implicitly added to preserve order of execution (I'm not implying an actual sequence frame is added, this is just how to visualize what's happening). What I don't expect is for the sequence frame to have it's own execution priority. I'll argue an inline VI should be usable in any context since the code contained becomes part of the calling context and should inherit the relevant context properties (priority, preferred execution system). I'm even more alarmed that the inline code may preserve the preferred execution system. If I use an inline VI which has a different execution setting, am I at risk of introducing unexpected context switches in my code? This would contradict the very reason to make a VI inline to begin with!

That's fantastic! Jon seems to have done a great job.

If you don't have control over the file format you may be out of luck and just have to write the whole new file. Since you mentioned memory, have you tried writing the new header, then copying the rest of the file in chunks rather than one operation?

It definitely happens before code execution. I can't say with certainty exactly when it happens either (and indeed it's academic to this discussion) but if you peer down into the bowls of xcontrols, recall there's an event structure in there that magically gets signaled from a VI that isn't running. Something tells me that this registration is happening when the VI gets reserved, and execution/starting doesn't have anything to do with it.

Glad I asked then, it was a genuine curiosity... I'm platform locked to Windows so I've never been sure how that is handled (other than under the hood paths aren't a simple string). Sorry I can't help with the Mac testing.

Out of curiosity, does storing a path as a string present platform problems? That is if I store "foo\bar.txt" in Windows, are the underlying primitives smart enough to change it to "foo/bar.txt" on a mac?

Yes, this works. It does however also mean the graph doesn't behave well as font settings are changed. But LabVIEW in general is pretty pathetic at scaling with font settings so it's not like that behavior is out of place.

Cool. I'm most interested in how people find interacting with LabVIEW via a touch interface. I do a lot of hack-ish UI work in some of my applications which I wouldn't expect to translate too well, but I'd hope the native stuff would be pretty straightforward?

Not that I'm aware of, although that sounds like an excellent idea.

At the risk of derailing, the specificity of the event registration refnum has never caused me issue directly since they can be combined via a cluster before hooking up to an event structure. What causes more problems passing those damned registration refnums through a connector pane. Make a change to an event encapsulated within that refnum and there can be a cascade of manual updates that need to be made, there's no way to properly typedef one of those magic refnums unlike say, a data value reference. Anyways, back on topic, I have hopes these macros will help in dealing with advanced event based APIs as well.

I have nothing constructive to add other than... Wow.

This is fantastic, I had no idea there was an API for these dialogs.

Yeah, the NativeWindow property is just so damn useful. Can't say I've used the others.