Aristos Queue

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.

Major differences: One was an off-the-cuff prototype that frequently crashed, couldn't nest properly, had no well-defined recompile semantics (so you couldn't trust that if you made a change the callers saw it), and didn't integrate with any of the rest of LabVIEW features except by accident (and, in the case of polyVIs, that accidental interaction was a bug). The other is an actual feature. I don't think we retained any of the original code. Comparing them, especially in the context of complaining about loss of functionality, spreads disinformation to anyone who doesn't know the background history. If you meant it as a joke, you forgot your </joke> tags. I did not find your semantic antics amusing.

Malleable VIs didn't exist in 2009. They were new in 2017.

Funny thing... most people use winding can openers wrong, even when they're designed for the correct hand. The intended use of the winding can openers is to open the outside of the can, not the inner edge. If used the intended way, there are way fewer problems with the cans. The usability of can openers is a fascinating metaphor all on its own. 🙂 https://www.insider.com/right-way-to-use-a-can-opener-2018-8

Lately, I've been using a phrase "oh, that's a left-handed scissors feature." I've found it to be a useful concept, so I'm posting it here to the LV community generally. When software engineers create software, we aim to create software that is usable by our customers. To use the colloquialism: the software should delight the user. We sometimes miss. But just because the software isn't designed as the user expects does not mean that it wasn't designed somehow. Often, I find myself fighting my tools (Visual Studio, Perforce, web browser, operating system, etc.) because it just isn't doing what I expect, and I'm constantly working around some issue. I've realized that sometimes, if I stop and think about how the software is designed, I can use the system the way it was intended, not the way I want to use it. I'm still not happy, but I'm working a lot less and hurting less. I've begun referring to such designs as "left-handed scissors". Sure, 90% of humans are right-handed, and, since there's only one pair of scissors, the scissors should have been designed to be right-handed. Or the system should let you configure left-or-right. Something should be different! But it isn't different. So as a user, I have a choice -- to hold the scissors in my right hand and try cutting or to hold the scissors in my left-hand and try cutting. I can fight the system and stress my hands and make the software work, damnit, using my right-hand, or I can use the left-hand. Using my left hand, I'm still having to work harder than I'd like, but at least the edges aren't digging into my fingers. There are features in LabVIEW that are left-handed scissors. We -- LabVIEW R&D -- should have done something different. You know that; we know that (now). But the decision was made, and there hasn't been developer bandwidth to fix it. And it sucks. But it can suck a lot or it can suck a little, depending upon whether or not you acknowledge that it was designed for the wrong hand. Packed project libraries are left-handed scissors. XControls are left-handed scissors. There's others, but those are the two big ones that I most commonly have to help customers with. Both are great features if you use them as intended. But no one wants to use them as intended... we all want to use them in ways that they just don't want to be used. They can do the job that we want them to do, just not in the way we want them to do it. In the case of XControls, you have less pain if you just accept the frustrating event model that they're predicated on. In the case of packed project libraries, you have less pain if you just accept the limitations of their dependency paths and design build specs accordingly. I'm not going into either of those statements in this post... I and others have talked about both in various other forums. My point here is to coin a phrase that I've found useful. And if you hear me talking about left-handed scissors, now you know my intended meaning. 🙂

Malleable VIs never could go in a poly VI. It's been that way since they were introduced in LV 2017. That's by design: they conflict with the rules of polyVIs for deciding which instance to use. Poly VIs need a fixed list of connector panes.

Those two primitives were explicitly tagged to be blocked... none of the people involved are still at NI. The comment says, essentially, “These boded crash sometimes when inlined,” with no useful detail, no steps to reproduce. I’ll look into it some more, but I have no clue what the issues could be.

We have an undefined type. Create an output tunnel from Your Favorite Structure node and don't wire the inside. You'll get a void wire, which is distinct from a broken wire. Void is also the type of a wire output from a subVI call node when you delete the terminal from the subVI's connector pane. Void wires don't have a control/indicator, and most poly nodes won't adapt to void (deliberately), so the VIM instances cannot adapt to void type. Void is probably not what you're looking for. Something like empty cluster is what you're looking for, but VIMs deliberately cannot have that type in their conpane, and it contradicts a key principle of VIMs: the conpane shows the user the intended usage, and by having one required working base case, we avoid many of the ambiguous interpretation issues of C++ templates. The code has to be semantically valid for at least one set of types. Having a terminal whose type is "undefined" doesn't tell the user the kind of data that they should be wiring to that terminal. I see your problem. I don't see a solution at the moment. An undefined type seems fundamentally flawed to me.

I’m pretty sure that’s the easiest to implement, so I’m liking your opinion. (Trying to be non-biased, I do think that’s the better option from usability. If I pick a name in a template, it’s because I expect the provided thing to use that name. It is consistent with the class method behavior, but for cluster fields.)

I have no idea why that limitation exists. I’ll ask on Monday.

Huh. I never considered that case. Everything is behaving as designed... but that’s clearly not desirable. So far, no node has custom type prop behavior when inside a VIM other than the adaptive class method calls. You’re suggesting (I think rightly) that "(un)bundle by name" nodes need to adapt different inside VIMs than in VIs. I’d have to teach the bundle by name nodes to have deeper history than they currently have so they always compute from original configuration instead of latest configuration. Or... would it be better to just freeze the named bundle nodes inside VIMs so they always look for the exact name? There’s some risk with either solution to break existing VIMs, but the current model seems mostly useless. What option sounds best? One of the two options is waaaaay easier to implement, and I’m trying not to let that sway me. 🙂

DVRs in VIMs works just fine (just double checked). It has worked since the feature released, still works in 2019. I have no idea what you’re talking about.