Leaderboard

1. Place a control refnum 2. Right-click, Select VI Server Class, Generic, GObject, Control, Pixmap 3. Now it's a "Pixmap Refnum". Right-click again, Show Control 4. Drag the control out. Unfortunately, I first noticed this control in the VI Scripting style ring, where it was labeled as "warning: dangerous" or something like that. But the class isn't marked private, and it can be placed in the manner I described without any kind of warning, so maybe that warning is obsolete and it's been fixed? Then it would probably be in the palette, I guess, but I'm curious to hear what NI has to say. Maybe it's a bug that it can be placed that easily without generating any warnings. :p

I agree. Ben works on making a language safe for references. I work on making a language without references. Our goals are the same: a world where data can be trusted.

I don't care what version of .NET is required. All .NET is banned from my projects and some of my hair has grown back as a result I too have products in 2013 and have found it relatively stable. It was my next choice if I were to be dragged kicking and screaming from 2009 Anyone else prefer an earlier version than 2013?

It works great for me, if you right click and select: "FatBits", it becomes a bit bigger and could be a good tool to create a 32x32 icon (That's the only size it supports). There are no Property/Invoke nodes for this control, and Value change event don't seems to work 😞

Well in playing around with the control I crashed LabVIEW so I'd say this was something that shouldn't be messed with, but pretty neat and something I didn't know existed.

Rebar will take yet another cue from Rust in the C interop case. Rust has the notion of an unsafe context, which can be either an entire function or a block within a function, and within which you can do certain actions that would be not be permitted otherwise, like using raw pointers or calling any kind of external code. The language basically says, "At this point you assert that you know what you're doing; I will still enforce some rules, but it's up to you to ensure that this C DLL isn't going to violate data safety." (You can read more about unsafe Rust here.) Once interop with arbitrary C DLLs becomes important, I'd expect to add a similar kind of unsafe context--probably a special structure that marks off the unsafe area from the rest of the surrounding code--plus the ability to use calls targeting NXG's Shared Library Interface (SLI) document. That way, you can pass pointers into C functions without performing extra data copies, as long as you pinky-swear that you know what you're doing. 😀

I encourage Ben not to worry too much about the interoperability with G and focus on getting the new language stabilized within itself -- a graphical notation for a safe reference system has value even if it only talks to itself... it can become an ecosystem just as G did. Now, obviously it has *more* value if it can talk to other languages, just as G has gained that ability over time. But that doesn't have to be up-front. Once the Rebar memory management is well-defined, creating the rules for interop should be relatively straightforward. I'd be far more concerned about Rebar cutting a corner to accommodate G than about making the interface seamless. The whole point of building an absolutely provable system is that it is provable -- any shortcuts and the whole attempt loses its value. Interop between Rebar and G will come in time.

This is a very good question, and while I will try to answer, at the moment I have mostly a hazy vision that I have not fully worked out the details of. My priority is and has been to elaborate a good design for the core of Rebar, then create enough of an implementation of it that you can do some useful things in it and can see a path towards other useful things. How much the design and implementation of Rebar/VI interop gets worked out will depend very much on how much demand there is for it. A VI calling a Rebar function should look about the same as calling a subVI. A Rebar function's signature will contain information equivalent to the inplaceness information computed by the VI compiler for a VI, so the VI compiler will know when it need to copy the data that it sends to Rebar. Similarly, a Rebar function should be able to call a VI; the Rebar compiler may need to dig out inplaceness information for the VI that is normally invisible to the user. One difference in this direction would be that Rebar should be explicit that it is obtaining a specific clone of the VI and calling that, which it might wrap up into a closure-like object. So then the question is what kind of data you can pass back and forth between Rebar and VI. The rules here are that Rebar cannot pass any raw values to VI that VI will not guarantee the invariants of. Specifically: Rebar can't pass its own references, or anything containing its references to VI, since VI won't do lifetime checking. Rebar can't pass values that have destructors, because VI isn't guaranteed to call them when appropriate. For any types that Rebar cannot pass raw to VI, it must wrap them in refnums. This amounts to having a reference-counted shared object between Rebar and VI, so there are still some Rebar types that wouldn't qualify, but it should be enough to allow the most interesting Rebar-created values to VI and have the runtime maintain their invariants. In this way, you could define a TCP connection type, a file handle type, an IMAQ image type, or whatever you want in Rebar, and provide an API for it back to VI with refnums. This would have the nice result of allowing you to re-implement many parts of the LabVIEW runtime in Rebar. That's about as far as I've got on interoperability. Obviously the devil is very much in the details here, and often creating an interop system between two different languages is way harder than designing each one in isolation. Like I said above, though, none of this matters much unless Rebar is interesting enough that people want to use the two side-by-side.

I think it's important to distinguish between what the language semantics are and what the compiled code and runtime actually do. For an initialized shift register on a loop, its value for a particular execution of that loop is only accessible during and immediately after the loop; the language does not let you get that value at any other point, and the value will be overwritten when it is initialized on the next loop execution. (NB: I'm not talking about individual iterations of the loop, but the execution of the loop over all iterations.) The compiled VI does store the shift register value in its dataspace, so yes, that value will be retained in the dataspace between loop executions, but from the language's perspective this doesn't matter because it's inaccessible. The language does not require the value to be retained or its allocation to be reused between loop executions; that's an optimization that the runtime provides. I'm not sure if we're agreeing or disagreeing here. My claim is that the way LabVIEW does dataflow--meaning wires carry immutable values that can be used in any number of concurrent places downstream--means that refnums are probably the best way of referencing objects that is available to LabVIEW. (I'm not enough of a theoretician to prove that reference systems with better properties aren't possible, but I do trust that if there were a better way, somebody smart around here would have discovered it in the last 30 years or so. However, another hint in this direction is the fact that channel wires have properties that approach what I'm proposing with Rebar, and channel wires are fundamentally different from normal wires.) If you want a reference system with better properties, I believe you must fundamentally change the way LabVIEW does dataflow. And so, to your next point: Yes, this is a new type of VI, or a new Model of Computation, or a new set of compiler rules, or whatever you want to call it--though I'd prefer you just call it a function, to distinguish it from what a VI is, which is more than a function. Importantly, it is not merely an extension of VIs, because it works differently enough that I do not think it should be mixed with G on the same diagram. Interoperating with VIs is a different story, and I think there is an interesting set of possibilities there. But I'm not sure I understand your question, "is there way to expand that more broadly?" I think to make life simpler for the compiler, you have to change the language, like I said above--maybe that answers it? Also, rather than "relying on the user to manage lifetimes," I would state it as "providing a set of safe and complete rules for lifetimes and guiding the user into writing code that follows the rules."

A note on the discussion about LabVIEW refunms, such as Queues and the like. These are "owned" by the Top-level VI that created them, and are cleaned up when that Top-level VI goes idles. This could be the whole App, but async-called VIs are all their own "Top Level", so if your app is made up of many async called VIs ("modules", "actors" or whatever) then refnums have a quite reasonable defined lifetime, the lifetime of the creating module/actor/async-thing. This behaviour is reliable; I know because I routinely rely on it to trigger automatic shutdown of async running things when their callers stop for any reason.

You should kudo this then: Means to register a DVR-cleanup callback for use when DVR released when VI goes idle. This would allow DVRs to wrap all dll pointers, with proper cleanup regardless of how the VI stops.

Firewall. Surely needs to be opened for the 5 relevant services on system 1, maybe on 2 too, I'm never sure; it is always so tedious to do. I wish someone had conocted a handy script for doing that automatically on every new LV installation.

Thanks for the plug. But I would only recommend it if TLS is required since (as far as I'm aware) it is the only one that supports it.

Note: JSONtext is now on the LabVIEW Tools network.