Aristos Queue

This is not really true. I mean, it's kind of true, insofar as LV executes assembly level instructions, not byte code. But it is also misleading. LabVIEW doesn't ever get to a deep call stack. Suppose you have one program where Alpha VI calls Beta VI calls Gamma VI calls Delta VI and a second program which is just Omega VI. Now you run both and record the deepest call stack that any thread other than the UI thread ever achieves. What you'll find is that both programs have the same maximum stack depth. That's because all VIs are compiled into separate "chunks" of code. When a VI starts running, the address of any chunk that doesn't need upstream inputs is put into the execution queue. Then the execution threads start dequeuing and running each chunk. When a thread finishes a chunk, part of that execution will decrement the "fire count" of downstream chunks. When one of those downstream chunk's fire count hits zero, it gets enqueued. The call stack is never deeper than is needed to do "dequeue, call the dequeued address"... about depth 10 (there's some start up functions at the entry point of every exec thread).

A programming language exists in any Turing complete environment. Magic:The Gathering has now published enough cards to become Turing complete. You can watch such a computer be executed by a well-formed program. People might not like programming in any given language. That's fine -- every language has its tradeoffs, and the ones we've chosen for G might not be a given person's cup of tea. But to claim G isn't a language is factually false. G has the facility to express all known models of computation. QED.

This might vary by operating system, but I think you're correct. I have only once had reason to drill that deep into the draw manager layer of LabVIEW's C++ code. But the whole point of deferring updates is to avoid flicker, so it would make sense that LV would aggregate into a single rectangle and render that as a single block... if it tries to do all the small rectangles, that's probably (my educated guess) the same flicker that would've occurred if defer never happened.

A call to a static dispatch VI will always invoke that exact VI. A call to a dynamic dispatch VI may invoke that VI or any VI of the same name of a descendant class. Exactly which VI will be called is decided at call time based on the type of the object that is on the wire going to the dynamic dispatch input terminal. A dynamic dispatch VI is equivalent to a virtual function in C++, C#, or JAVA (and other text languages).

For anyone else interested in how far this bug goes, I got this from one of my coworkers: From my research it affects all processors based on the Zen 2 architecture (AMD processors that started being released in July of last year). AMD claimed that they dropped support in Zen 1 for fma4 instruction set, and the illegal instruction causing the crash is part of that set. The first series Ryzen processors sound like they may still work, but I didn't have access to any to verify one way or the other.

The MKL problem is in the wild? I thought that was something that was only affecting LV 2020 (now in beta) because we were updating to the latest MKL. The bug isn't on my team's plate... I just sit near the people who are handwringing a lot about it. If that's in the wild affecting already shipping MKL versions, then, yeah, that could be it. I still don't know how the node is rolling back to its last known good resolve path... I can't find that path stored anywhere... but if we assume it is binary encoded *somewhere* in the node's saved attributes, then this makes plausible sense. Workaround is to a) get a new CPU or b) wait until LV issues a new version where we do whatever we are doing to avoid calling certain CPU instructions (I'm unclear what the planned solution looks like).

I have no idea what other DLLs that one calls. This is really weird.

Weirdly, yes, it does make sense. This is what would happen if the DLL was corrupt and couldn't load. The DLL is found on disk, but it could not load. I don't know exactly how the node is getting the build machine's path, but that would be the path it had the last time it resolved successfully, so I'm betting it is encoded in there somewhere and being used as a fallback location. Has someone been rewriting your DLL on disk? Can you try copying that DLL from a clean installation?

Is this desktop LV or target LV? What is the actual path on disk to that Mean.vi?

Is there anything you can think of that has been done special to this machine? Did you get someone from NI to send you a custom patch that has never been generally released? Like, I'm seriously grasping at straws here... we grep'd the binary of Mean.vi -- that path does not appear anywhere in the shipping copy. So somehow you have a copy of Mean.vi that is not the one that is installed by an installer. I would say "it's a fluke" except for that post earlier that someone else had this happen to their LV2017! Now I have a real mystery.

@NeilPate : please run the attached VI on your misbehaving Mean.vi and tell me what path it shows. Read path to analysis lib.vi

Here's what should be happening... The path saved inside Mean.vi is (should be) a symbolic path to the analysis library. The exact thing saved should be <resource>:\lvanlys.* which you would see if you use the private Application method. (Actually, you'll see the "*" replaced by "dll" because the method does that small bit of platform-OS interpretation of the path.) That symbolic path gets interpreted when the VI loads into memory. That means that... ...if you open up the Mean.vi and open the configuration dialog of the Call Library Node, you should see an absolute path that leads to the lvanalys.* on your machine. ...if you move the VI out of vi.lib and to some other location on disk, you should still see the same absolute path. ...if you open that VI with a different copy of LabVIEW, you should see the path of that other LabVIEW's analysis library. But given what you're seeing... It seems like whatever the absolute path is being saved is not being saved as a symbolic path. "e:\builds\penguin\labview\branches\2019\dev\dist64\resource\lvanalys.*" is the directory on the build machine where the installer is created. I don't know of any way for this edit to be made, but clearly, it is happening. It seems impossible that we could be making this mistake everywhere... we would have lots of customers complaining about an inability to build apps. Heck, the VI would be broken in the editor! Very strange.

Nothing looks broken to me in LV 2019. I've attached my 64-bit LabVIEW 2019 Mean.vi... does it work for you? I tried several different ways of moving the files around without any problems. Mean (DBL).vi

Figured someone over here might be interested... over the weekend, I built a new right-click menu item plugin for editing set controls and constants. The UI is bad, but it works; if anyone wants to work on the UI, you're welcome to do so. Building a map editor would follow the same pattern as the set editor. https://forums.ni.com/t5/LabVIEW-Shortcut-Menu-Plug-Ins/Edit-A-Set-Value-llb/ta-p/4020190

The New Data Value Ref and Delete Data Value Ref nodes will be able to be in inline VIs (and thus malleable VIs) in LV 2020.