Aristos Queue

That is better. I'll fix it.

Attached modified VI is saved in LV 2018. I reordered the TSS frames to move integers and fixed point earlier in the list. Then I added Cast Base Units nodes to the floating and complex cases. And I added an Assert Type Match node to the timestamp case. Please let me know if you see further issues. If not, I'll include this in LV 2020. Scalar To String.vim

Well, thanks for the education. Clearly, I should've know about the double-to-timestamp behavior... the change was during my era.

I am authorized to use “LabVIEW 20xx” if I absolutely must differentiate... which I generally feel I must do for any sane discussion. 😉

Say what?! Why in the heck is that a thing?! Since I really don’t want to dig into the C++ code to find the answer, does anyone know what it means to interpret a double as a timestamp? As for the units thing... I didn’t even test that VI with units. Didn’t think of it as a test case. I’ll investigate both and make lv 2020 either send units to default (by fixing timestamp) or to double (by fixing the assert) or to their own case (if I can find a way to distinguish).

There’s three that come to mind. No one but me liked my Recursion structure node as an alternative (improvement, in my opinion) over just allowing a VI to call itself as a subVI. I took a rather radical position that recursion should have a compiler-provable base case as part of its declaration, and that raw function recursion, though critical in math, is not healthy in a programming environment because compilers cannot really prove (in most cases) that it doesn’t blow up the stack. But every other language just has recursion... my structure node was too different. I had a really bad design for sets and maps back in 2001 that I pushed hard for: a complete by-reference design that I’d worked out. That one got me a lecture from Jeff K that rings in my ears to this day on the value of by-value. There was a good-natured-but-insistent afternoon of all the senior devs basically taking turns showing all the really bad architectures my API enabled until I finally got the point. 🙂 Eighteen years later, I lead the effort to put the by-value API in. I have a bunch of NXG designs that were too radical to gain traction. Most notable of those was formalizing the error propagation and handling to wipe error wires out of most diagrams. I and two other researchers worked on that for almost a year, and we were really excited by the design, but the shipping timetable didn’t allow us to do it... so they implemented the same error cluster. We were told that we could do it later, but now it would be a breaking diagram change... bigger hurdles. Unlikely to happen now. There’s more. Those are the ones that come to mind easily.

https://ni.com/beta And there's a CLA Summit presentation from September that I gave that is videotaped and archived somewhere in the CLA forum... I don't have that link handy at the moment.

Unwilling, not unable. I'm proposing it as a research vein over the next couple weeks. If The Powers tell me there's zero chance, I won't even bother getting into it ... it's a brainstorming rabbit hole that I think has benefit, but few others agree with me, even among customers. If I get a go ahead for it, I'll probably be discussing it at the CLA Summit in September.

Well, it isn't interfaces... those are at "priority zero... in beta... conditions look good for launch in T-minus 4.5 months."

NXG is not my area of concern at this time. I can see it approaching in the rear view mirror, but my job is to hold the accelerator down on the current product as long as possible... NXG is a much larger dev team... they'll overtake my team eventually... but today isn't that day. 🙂

a) TLS support would be a library, not a language feature. b) I wouldn't expect to have anything to do with such a project... networking protocol code is a long way from my areas of both knowledge and interest. c) Your timing is impeccable. Status changed to In Development (should've been set that way six months ago... we missed it in the list): https://forums.ni.com/t5/LabVIEW-Idea-Exchange/SSL-TLS-Support/idi-p/3314187

A first-class, baked-in, messaging framework of some sort is on my personal roadmap. I have multiple design documents, use cases, customer feedback, etc. It is priority number two on my list of future language advancements that I want to work on. But I have yet to convince NI that it is a priority. So, for now, the Actor Framework remains my team's best effort -- through the support in the project tree and the documentation tools -- to create a messaging system with minimal diversion into syntax. It is a mixed bag of a success. It has inspired several other similar frameworks, each with its own tradeoffs. Even if I were to convince The Powers That Be, such effort would almost certainly be directed to LabVIEW NXG, not LabVIEW 20xx -- arguing for 20xx is an even harder argument to win. I would recommend continuing to refine the various frameworks for the foreseeable future. That's my personal opinion from the trenches. If something better is important to you, please use various customer channels to communicate your desire to NI. The Powers listen better to customers directly than to me saying things on behalf of customers.

Code from an older time when people thought such security was meaningful. There's some ROT13 password "encryption", if you look hard enough.

No. Those were built exactly to customer spec and do exactly what they promise to do. The fact that they’re a horrible idea doesn’t make them left-hand scissors. There isn’t a better design for shared variables that would make them safer or more practical. Shared variables are more like the 1950s kids’ science kits that shipped with pieces of actual uranium to play with.

It is also a secure way of thinking.