Aristos Queue

Place any new items in a separate map and then merge them after the loop finishes.

35 minutes ago, Raf73 said:

Hope one day NI will release a slightly more decent control customize editor. The current one is still a real pain..

NI already did: it is called LabVIEW NXG. NI created NXG specifically to address weaknesses in LabVIEW 20xx UI layer. The LabVIEW 20xx editor is antiquated, but its C++ code is very hard to modify. Given that NI's focus for user interfaces is almost entirely in NXG, there is very slim chance of further developments ever in the LabVIEW 20xx control editor. I cannot say "no, never" just as I never promise "yes" on future functionality even when I'm actively working on it, but I will say that it would take significant user encouragement for NI to fund the 20xx control editor ahead of other 20xx priorities, and I don't expect that to happen.

On 5/5/2020 at 6:36 PM, JKSH said:

Does that mean a LabVIEW map converts the data to/from variants behind the scenes, even though the datatype is fixed at edit-time?

No. That's not what I said at all. 

On 6/4/2019 at 8:10 PM, Dataflow_G said:

You may be seeing the sorting overhead of maps (and sets). AFAIK variant attributes are unsorted,

Nope. Variant attributes and maps use the same — identical — underlying data structure. For reasons I don’t grasp, the C++ compiler adds a couple extra instructions in the maps case only when the keys are strings that aren’t in the variant attributes. Still, the conversion time to/from variant for the value tends to dominate for any real application. 

On 5/2/2020 at 9:05 AM, pawhan11 said:

 If they deliver more fundamental things that are pain in CG like problems with relative build paths, unicode, sealed classes, packed libraries linkage, building of multiple layers of libraries without killing labview, out of the box support for source control systems & diff/merge operations... 

Of your six items, NXG addresses three of them and has improved support for a fourth. The source code control stuff is still in flight -- not sure when the target is for delivery [again, not my department]. Sealed classes is so far down the priority list, it's not even in the backlog I bet. I couldn't get traction for that in LV20xx. 

On 5/2/2020 at 2:47 PM, Neil Pate said:

Why is a feature like this removed? Sure, it is not a great thing to use this to actually run my application, but why removed it? Hide it away somewhere if you are worried it is going to be abused.

It wasn't removed from NXG. It has not yet been added. There are a sizable number of customers who lobby LV 20xx to remove it entirely, and others who want it left just as prominent as it is today. You can see one place where that discussion has been playing out: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Hide-Run-Continuously-by-default/idi-p/1521886

NXG hasn't decided how to handle it yet, so they haven't added it. It's in the ToDo backlog to add it somewhere.

21 hours ago, Neil Pate said:

Also, as a leftie my right hand hovers on the arrow keys when programming, so nowhere near the left hand side of the keyboard.

Darren has acknowledged he is not the right person to develop a left-hand set of shortcuts. If you put together a list of shortcuts for yourself that work better for left hand, contact him... he's happy to promote them. You can swap out the QD shortcuts if you have a better set. 

17 hours ago, Michael Aivaliotis said:

It would be great to have a project menu item, goto parent interface:

16 hours ago, Mike Le said:

How would this work if a class has multiple interfaces? Maybe instead of a right-click menu option, some kind of visualizer that only shows the class's interfaces?

 

Wouldn’t be “Go To...” it would be in the project item’s Find menu with Find>>Callers. Like all of those, Find>>Parent Interfaces would jump directly if there was only one and pull up a results list if multiple. 
 

We had it on the proposed task list and cut it out of this release. It goes in the iteration bin to compete with other priorities. 

16 hours ago, Michael Aivaliotis said:

Why can't we get this class relationship view inside the project tree? It seems useful.

The project tree is an all-files view. Not every file is a member of a class. There are VIs in libraries, loose VIs, non-LabVIEW files (like readme.txt). We talked about a class view in project back at start of LVOOP project and repeatedly since then, and we repeatedly decided the project window was the wrong place for that. That is the reason the LabVIEW Class Hierarchy window exists. 
 

For a better view overall, checkout OpenGDS or NI-GDS toolkits (although neither is updated for interfaces at this time).

I added notes on follow-up questions and getting the video recording to the original post above. 

On 4/30/2020 at 8:06 AM, Jordan Kuehn said:

I'm shocked that one isn't already available.

Note above where I quoted another NI engineer about the complexity of answering that question given the variations of Pis available. We (NI) does not own one of every possible Pi. We are able to give the tech specs of what is supported, but the model numbers are not so straightforward in their mapping. Therefore, the table will have to be crowd sourced over time.

If you're shocked that the community has not built it yet, well, LV2020 CE only dropped on Tuesday. 🙂

3 hours ago, Mads said:

"For every existing customer you lose, you have to recruit 3 new ones just to make up for the loss". 

Most of the existing customers surveyed like NXG. They just don't like how limited it is at this time. I, for example, really want to be able to use NXG. It has so many nice things. It just ain't ready for me yet. But it will be. And in the meantime, LV 20xx continues to be a thing. Used interfaces yet? 🙂

The Pi Zero is apparently a particularly complex case to figure out :
I had to look it up. The PiZero uses a broadcom chip that is Arm11 era. But the same page also has links to Arm9 and even Arm7. So I believe the Zero uses an Arm11 or less which is V6 architecture.

29 minutes ago, Jordan Kuehn said:

Does that mean the toolkit is compatible with any ARM V7 Pi?

I went to ask. 🙂 Answer:

Yes. ARM V7 Pi or greater. The ARM standard is very hard to keep straight. Various vendors add their own suffix and number to indicate something they extended. I believe the correct statement is that we require that it have ARM architecture of ARMv7 or greater, as shown on the Wikipedia page. There will likely be some corner case that makes it harder to describe. As an example of confusion, the ARM8 is actually an ARMv4, the ARM11 is a V6, the Cortex M3 is a V7, etc.

2 minutes ago, LogMAN said:

. I want to support the effort, but sending out one-way tickets is very frustrating

 

https://forums.ni.com/t5/NI-Software-Technology-Preview/ct-p/techpreview

On 4/27/2020 at 3:52 PM, Neil Pate said:

What was fundamentally wrong with the Project Window in Current Gen?

If you do not already have your own personal list of "Wow, NI really missed the mark here" bullet points, well, it makes me happy that we made at least one customer happy with that design. That makes me happy because I thought the count was zero. I'm not being sarcastic. The project window was a good first attempt, but it quickly showed problems, and we've never fixed those. But if it works for you, I'm not going to try to convince you otherwise.

57 minutes ago, Neil Pate said:

I am seriously surprised scripting support (or interfaces) are given higher priority to fixing the GUI.

A) GUI isn't higher or lower priority than those language features. There are multiple teams working on NXG.

B) The GUI generally is not seen as particularly broken. The particular UI for classes is (in my opinion) cumbersome but functional. The priority was getting classes working. There will be UI improvements over time. Honestly, NXG team has more credibility with that than I do in LV20xx. The "new class" experience in LV20xx has been terrible for how long? And we only got it fixed in LV 2020? NXG has shown a far better track record for releasing a language feature and then improving the UI later when they have more usage data about what features people are actually using and how.

I am NOT saying you should be using LV NXG right now. In my personal opinion, NXG is still a long way from full-app users moving from 20xx to NXG. But there are a reasonable number of users for whom NXG is sufficiently complete TODAY that they do develop in it. Various people at NI will give you different time estimates for when all LV users should move over. That variance in estimates is not unexpected for a product of NXG size and complexity.

As I have said before: The NXG vector direction is good, but vector magnitude is still developing.

1 hour ago, Neil Pate said:

is there a single medium or large application developedfrom scratch in NXG or even converted from CG NI can showcase to us to put our fears at rest?

I know there are several that have ported, and I thought NXG had shared details of at least one large customer app with the community, but I'm not sure... I don't recall what I've seen in customer presentations vs internal presentations. You'd have to talk to someone customer-facing in NXG to get specifics. There are multiple forums on ni.com for these questions.

4 hours ago, crossrulz said:

Will this be recorded?  I will attempt to attend, but have appointment that will likely cover the first half.

The plan is to record it. Lots of new technology involved in this, so fingers crossed.

17 hours ago, JKSH said:

The event title is currently "Intro to G Interfaces in LabView 2020" (I peeked at the event on Microsoft Teams)

Had IT team fix that. Thanks.

2 hours ago, Neil Pate said:

hooovahh, we have been giving feedback for > 5 years. Nobody with any authority to direct change seems to be interested.

The directions have changed rather radically on many points in response to user feedback. The new component system is completely redesigned twice from customer feedback, and that's another thing I definitely wish LV20xx could backport. They dropped work on interfaces to prioritize scripting because of overwhelming feedback that the scripting tools were higher priority for getting work done in NXG. (Interfaces help some large apps... scripting helped almost every developer either directly or in the tools written for others.)

I am not on the NXG team, and yet I can point to decision after decision made directly from customer feedback.

8 hours ago, LogMAN said:

but why use the same file extension?

Because the refactoring is so much better. I would make this change in a heartbeat in LV 20xx if I could do it without breaking compatibility.

I would differentiate the icons in the project tree, which NXG chooses not to do. Take a look at LV 2020*... interfaces and classes use the same file extension, and it is way better for refactoring hierarchies. BUT we use distinct icons in the project tree and various other places. You can read the details of this decision in the document I published yesterday about interfaces. I even go into detail about where we deliberately do NOT differentiate for end users.

* LV2020 Community Edition became available yesterday. Commercial edition will be later in May... we prioritized the CE release for all the quarantined engineers at home.

3 hours ago, LogMAN said:

Actually, the thing they call "G Type" serves as a strict typedef, but it is really just a class that doesn't inherit from gObject (it inherits from Void).

I'm not sure where you get that. The execution engine is the same engine that LabVIEW 20xx uses. Classes and typedefs are the same things that they've always been. The limitation of gtypes being inside classes is one I've complained about personally... it is entirely a limitation of the UI, not the underlying nature of the entities involved. Yes, both .ctl and .lvclass use the same .gtype file extension. That makes refactoring G code to change between the two a lot simpler. But what the files represent? That hasn't changed. There are still 25 fundamental LabVIEW types, of which LabVIEW class is one (NXG doesn't have sets or maps yet, which bring the total to 27), and a typedef can host any of them (except void).

20 hours ago, smithd said:

based on my own anecdotal experience it seems like the thing holding labview back is less the UI of the editor

I'm genuinely curious if there is data out there which justifies the things nxg is focusing on.

Without going into anything NI confidential, yes, NI has lost significant sales opportunities because the old fashioned UI of LabVIEW 20xx does not appeal to the next generation of engineers and scientists. Redesigning the UI from the ground up was the primary mission of NXG -- incremental adjustments were considered and rejected early on. NXG's design is very much driven by data from sources such as user testing, customer feedback, and sales numbers. Any issues NXG has had getting off the ground with customers are less from going in the wrong direction and more from having so many parts that have to move in the same direction for it to work. As more parts have come into alignment, the user base is starting to pick up.

On 2/5/2020 at 9:27 PM, Aristos Queue said:

I've put the freezing of the bundle/unbundle nodes (including those on the In-Place Element node) into LV 2020.

This IS fixed in LV 2020, but it got left out of the Upgrade Notes*.

I have posted details here:

https://forums.ni.com/t5/LabVIEW/LV-2020-Upgrade-Note-Altered-rules-for-named-Bundle-and-Unbundle/td-p/4035624

The fix is very healthy for most apps, but we did find one internal-to-NI app that was dependent on the dumb-luck-that-it-sometimes-works behavior. We had to fix that one up by using the Coerce To Value primitive to set a name of the element in the caller. But going forward, such antics should not be necessary... the adaptation rules of named bundle/unbundle are now well-defined.

* My mistake -- apparently my tech writers cannot read my mind; I actually have to hit Submit on bug reports, not just leave them in Draft. *chagrin*