Aristos Queue

Attached modified VI is saved in LV 2018.

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.

On 1/10/2020 at 11:15 AM, hooovahh said:

the designator I've seen most commonly used is Current Gen (CG).

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

On 1/9/2020 at 12:24 PM, Darin said:

A double, with or without units is a perfectly acceptable input for a timestamp format string.

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).

3 hours ago, DTaylor said:

Do you have any stories of ambitious/controversial proposals that never had a chance?

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. 

17 minutes ago, DTaylor said:

!!! Is there anywhere we can read about specifics?

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.

11 minutes ago, DTaylor said:

Finally!

!!! Is there anywhere we can read about specifics?

You've given us priority #0 and #2, are you unable to share #1?

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.

22 hours ago, DTaylor said:

What's number one?

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

14 hours ago, smithd said:

Lol. Sorry for sidetracking, but I tried to get it [NXG] to even open and it crashes on my machine.

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.

20 hours ago, Mefistotelis said:

How cute - NI is protecting some values stored in memory at runtime by XOR'ing them with seed which depends on the VMA.

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

21 hours ago, MarkCG said:

should we add Network Shared Variables to this list of left hand scissor features as well?

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. 

8 minutes ago, Mads said:

I think that is a very old fashioned way of thinking. 

It is also a secure way of thinking. 

12 hours ago, ShaunR said:

Yes. It's a distinction without a difference.  GregSands found it, the community investigated it and malleable VIs were the productionisation of it.

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.

On 11/18/2019 at 12:02 PM, ShaunR said:

Yeah. but it worked n 2009 

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

2 hours ago, Neil Pate said:

As a lefty, don't even get me started on can openers.

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. 🙂

1 hour ago, ShaunR said:

Seems VIMs can no longer be used in polymorphic VIs either.

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.

On 11/16/2019 at 8:15 PM, Aristos Queue said:

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

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. 

1 hour ago, drjdpowell said:

I've now getting the buffer wire to be unbroken when the Data input is unwired, by making the default Data an "undefined type" (a class call "Undefined Type").  I added a case that is unbroken when Data is this "undefined" type, which it is when the User has not wired that input.  The error message the User gets in this case is just the one for a required input not being wired, which is much less confusing than a broken "Buffer" wire and an additional error  message about type mismatch.

 

AQ, what do you think about an actual "undefined type type in LabVIEW and/or NXG?  One thing that could be useful for NXG is a undefined type in a cluster constant, which defines teh name of the item without the type, and allows the type to adapt to that supplied by the first Bundle-by-Name.  This would avoid some of my concerns about clusters in NXG.

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.

14 hours ago, drjdpowell said:

I'm favouring just freeze the name, as that is simplest for the User to understand, given that it is difficult to diagnose, let alone fix, any problem if the name adaption goes wrong.

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.)

17 hours ago, drjdpowell said:

DVRs can be used, but not created or destroyed, inside an inline VI.  Not clear to me why that is.  

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

On 11/16/2019 at 3:50 AM, drjdpowell said:

Question for AQ: I'm trying to use "Unbundle by name" to access the elements of the cluster (the buffer array and the index integers).   This works, but if the User accidently connects a cluster without the right-named elements, the unbundles can get scrambled, and not properly reset to the right names when a proper Buffer cluster is attached.   

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. 🙂

22 hours ago, ShaunR said:

Never mind. It seems that you cannot have DVRs inside VIMs any more.

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.