X___

Playing around with it. It looks like, as for X and Q controls, compound controls need to be bundled up into a cluster. As a result, the facade is rigid, in the sense that when dropping an instance of the Y control, I cannot adjust the components of the control (or the whole control itself for that matter) unless I modify the definition of the control itself. This is fine for a "one of" control, but somewhat of an issue for something intend to be generic. As an example, I was trying to try out the package with a simple string with visibility checkbox. Once dropped on a FP, neither the checkbox nor the string can be resized. This type of ability (or lack thereof) is one of the things which immediately cooled my enthusiasm for the X and Q controls. I may be missing something though.

Online shopping for this product is currently unavailable?

I wouldn't use a language which is based on a lot of inaccessible C++ code for mission critical software... like driving a space rocket, for instance. I have encountered a lot of "corner cases" in the math routines which had probably some trivial algorithmic flaws at their core, but this was not possible to detect (let alone correct) until I drove the code in the ground, so to speak. One more reason to open the belly of the beast.

That may explain things then. I am not a channel wire convert, use VIM occasionally and have stayed clear from classes (and thus interfaces). Which I guess excludes me from the conversation? Some dialogs are obviously LabVIEW-built, and have aged pretty badly. The GSW is a recent example of accelerated obsolescence. But as far as I know, the universal answer to requests and suggestions has been: "NI has other priorities and limited resources". How could it be otherwise indeed? Maybe, just maybe, tapping in a free multiplier of resources could change things? It is not that there are only negative examples out there of open source programming language development... But I'd understand that a scalded cat fears cold water.

Sure, why not rewrite Linux or Android in LabVIEW too... 🙂 XControls are not standard LV objects. Can't put them in array, they have all kinds of limitations, and while I understand that they were created at great cost and with the best intentions, they essentially failed (I think I have developed one and concluded that this was not worth the effort - in large part because of the impossibility to array them). I'd say pessimism seems warranted after the failure of NXG and the complete lack of a clear roadmap (this is what I was referring to with the term quixotic - with a typo). I have since cut NI some slack and understood that little guys like me are of no monetary values to them. Fair enough and in any case, this is not the type of programming language I can publish code in since it is hieroglyphics to most. And even that at some point will have no value, as we will just tell Alexa the general features we need in our software, maybe draw a GUI mock-up and a DL network will generate the code...

There is a problem right there (in the flash light story), but who is really surprised about it? Of course there would be a cost to open sourcing the code: cleaning it up and documenting it as the team fixes things up in the upcoming releases is something that would be expected from a pro team anyway. They wouldn't have to accept any and all contributing candidate, and they wouldn't have to commit any and all contributions. But they might get some good feedback from dedicated believers (see e.g. https://openjdk.java.net/contribute/). At worse none, but that in itself might be a good indicator for management to take a hard look at LV's relevance. They could spin-off improvements to control/indicator modifications to the community and focus on the things that matter most to their core business. You'd be surprised how focused debuggers would be at squishing those pesky bugs of yore... not mentioning expanding the capabilities of LV. There is no guarantee that LV would eventually rule the world (I don't think anyone of us has ever had this dream). But maybe it would give it a chance to not look hopelessly outdated. The real obstacle seems to be the "NI culture". I have no idea what it is, but the recent past has painted it has rather quitoxic if not readily toxic.

This is material for the Ph D thesis on the NXG fiasco I was fearing (in another related thread on this forum) would never be written... and is now lost to the microcosm of LabVIEW Champions (I understand knuckleheads like us were not intended to be privy to this juicy stuff) It seems that one way to give a future (or definitely burry any hopes for LabVIEW at the sight of the quagmire) would be to open source it.

Maybe that is relevant: https://www.cmlviz.com/recent-development/2020/10/29/NATI/national-instruments---announced-workforce-reduction-plan-intended-to-accelerate-its-growth-strategy-and-further-optimize-operations-cost-structure Another variant: https://www.honestaustin.com/2020/10/30/mass-layoffs-at-national-instruments-remedy/ ("Thursday, he said that sales staff and administrative staff would be most affected", so maybe unrelated to NXG's demise after all...) And from the top dog's mouth: https://www.reddit.com/r/Austin/comments/jkyid6/ni_is_laying_off_9_of_its_global_workforce/

Isn't this serious stuff though? Most of us may have had disagreements with NI on some of the paths they had chosen to go down to, and were lamenting the crawling pace of their progress, but at least we all agreed that the current LV IDE/UI development toolset was outdated. The official statement (by two top brasses, not a mere webmaster) is not particularly crystal clear as to what is forthcoming. Coming right after the Green New Deal campaign and in the midst of the pandemic, it might just as well be a forewarning of major "reorganization" within NI... The surprise expressed by AQ in a different thread would seem to support this hypothesis. At least it gives me something to speak about in my next "how do we use LabVIEW in the lab" intro session...

Can't say that the rationale for the decision is put particularly convincingly... We'll have to wait for the dust to settle to really figure out what this corporate double-speak means. Do they even know themselves?

I have been using Parallels for a long time. It works but it also hurts (more on this below). As far as subscription vs none, there used to be limitations to the one-of version in terms of number of cores and max RAM (this might have changed, but I don't think so). This is a problem when you have a multicore machine and you end up limited to only a few. There are some additional perks coming with the subscription version (including updates, and a la LabVIEW, the corresponding bug fixes). Be warned that their support is nowhere close to NI's, which is a problem when something fails badly (and it will, potentially). Thus, do not upgrade to the newest version until after careful monitoring of their forums, as my experience has been that it can sometimes completely fail and corrupt your VM. Which brings me to the most important advice (independently of the upgrade step): do not save critical data - e.g. VIs- as part of you VM (unless you want to backup a multi GB blob every day as part of your Time Machine routing - the VM comes as a humongous file that you will probably want to exclude from your backup routine and only save every now and then - typically before an upgrade), but instead, take advantage of the ability to share data between your VM and the Mac. This way, if your VM becomes corrupted, it's just a matter of getting an old copy of it (with only the system and apps, which typically don't change that often or can be easily updated if needed). Your data files will have been on the mac side of things all along and unaffected by the Parallels fiasco. It has happened to me several times. As usual, YMMV. As a note, I am not sure this is the best time to switch to a Mac, with the Apple silicon transition, which will at best emulate Intel CPUs, and as far as I know, Parallels adjustment to this is still in the work. I am personally switching to a Thinkpad... and in the long term, Python 🙂

A word of caution (seriously): before you send people in space on a device simulated/tested with LabVIEW, keep in mind that a non-negligible fraction (I am not saying a large fraction, but one bug can be enough) of its algorithms/numerical codes are buggy and since they are closed source (for the most part), the only way to figure out is to run into inconsistencies or unexpected results. This takes a OCD scientific mind to discover, the hard way. Especially in the "uncommon" regimes, those which Dr Murphy likes to invoke at the worst time... As users, we've done our best to let NI know, but at best it has taken years for actual bugs to be fixed, when they have been fixed... Maybe time to check those X_Bug_Report tagged posts on forums.ni.com... Have fun.

Gotcha. That is problematic.

NI recommends to force recompile (mass compile) after each update.

LabVIEW itself would be highly suspicious, according to these criteria. But wait...

What's the idea? It doesn't know which package I have installed for what version and therefore cannot tell me whether a new version is available and I should check out. 19 pages of listing instead of the compact window I can easily filter and check out at a glance...

Once the HTML is generated with the provided VIs on the source computer (json files, PNGs and some txt description files plus the boilerplate JS installed with FINALE), that HTML hierarchy can be uploaded on a website (e.g Github). The only thing that is needed is a http server (which is launched by the command http://127.0.0.1:8081 on a local computer in the current FINALE distribution) serving the webpages and running the different js scripts. That could be done by cloud servers at minimal cost. This could be provided together with the source code in repositories for those who don't have access to LV. While LV is not a text language, a well-designed LV code should be roughly decipherable by a non LV expert, especially when implementing an algorithm (UI and code mechanics is another matter). This would go a long ways toward establishing LV as an acceptable programming language for scientific applications. Currently it is not, because most scientists using Matlab, python, C, etc. can't even look at the code. Here is an example of how this looks like: Note that vi.lib and other pre-installed VIs are not accessible and I don't see the conpane of the other VIs...

That's working well enough. Now we need to convince github and other repository cloud storage solutions to run this on their servers...

The binary-no preview nature of LabVIEW code is obviously a problem.

Note that the discussion was not about whether or not LabVIEW is on its way to dominate the landscape, but where it is discussed (both are certainly related).

Are you seeing things between the lines? LV is not present among the first 50 listed... In case that helps shedding some more light on reality, here is yet another recent list essentially saying that LV is nowhere to be seen on Github or Stack Overflow: https://redmonk.com/sogrady/2020/07/27/language-rankings-6-20/ and I am not talking about the list itself, but the graph shown here: doesn't list LV, as far as I can tell. Now I am sure that if you limited this kind of analysis to NI's website or LAVAG, LV would hit top of the list in both cases...

https://www.tiobe.com/tiobe-index/ LabVIEW dropped below 50... Might it be that its rank follows its average user age?

That's the only thing I had noticed... as overdue (although of no use to me).

That looks insidious indeed. It definitely doesn't work this way in 2019 SP1. This is the kind of mental note (close LV and restart to clear up memory) I would certainly forget every now and then. I am refraining from upgrading without pressing reasons, since chances are I will lose access to support for old NI hardware I haven't replaced yet (by non-NI ones, of course!). I realized too late I should have stuck to 2018 SP1 for hardware reasons (and as I described recently in the thread you linked to, because of a newly introduced project explorer bug among others). 2020 seems to be one of those years we will try our best to forget about ASAP...

CAR# 1096546 was submitted for this bug