JackDunaway

Referring to the screenshot where `libstringtools.dylib` is greyed and disabled when the LabVIEW dialog filters only files of type "Shared Libraries". When the filter is changed to "All Documents" (i.e., any filetype), the shared library becomes un-greyed. This was worded poorly, making it sound like the bug is in OS X. In this dialogue, LabVIEW apparently only considers `.framework` filetypes as being a "Shared Library", but not `.dylib` filetypes.

Does a Channel Wire fall within your definition of "dataflow"?

For clarity: are you saying that Channel Wires (this is the official name and a much better name; my usage of `async wire` is I believe what it used to be called until being replaced by the better name Channel Wire) are not `dataflow`, and considering them as such conflates concepts to a point of confusion?

It appears that in LV2015 LabVIEW does not populate the drop-down with exported functions, but "everything works" if you manually set it up. In other words, you can type or paste into the `Function name` box on the configuration window and the code executes as expected -- you just miss the UI affordance of that cozy feeling seeing the drop-down arrow go from disabled to enabled once pointing to the library, and the type-ahead autofill for function names. Additionally, `*.dylib` is not recognized as the shared library type on OS X.

Now with async wires, it's important we more clearly define our historical usage of the word "dataflow" to mean "synchronous dataflow", also acknowledging "asynchronous dataflow" is a better way to describe we've historically called "breaking dataflow". The undecorated word "dataflow" just means that data moves, either temporally or spatially. Synchronous and asynchronous dataflow are desirable for different reasons at different layers. Async wires are a huge opportunity to explore innovation on procedural logic at the functional/diagram level (this syntax at systems/application layer right now is less interesting). I would recommend checking out an awesome example AQ posted on: https://decibel.ni.com/content/docs/DOC-42942

True. Unless something has changed for LV2015, you can request a copy from your sales contact, and they will ship you a DVD. (Yes. A DVD. For a Mac.) Word on the street, this might be changing to USB drive soon? (Which is also kinda jokey, unless there's a USB-C option as well!!) The licensing technology is basically a pinky swear. One thing that's totally awesome is how fast it installs.

Yep. This would help begin to bring parity with other languages' Generics (or Templates) abilities (the most concise read explaining this is Rust Generics annotated with Trait Bounds. If the word Trait muddies the waters here... just replace that with `Datatype, but totally super-awesomer`) Additionally, I've built just enough XNodes (8-10 or so) to be of the opinion that VIM's are a little too underpowered to be considered over XNodes for the framework/middleware layers and below, but miiight be useful at the one-off application layer (extrapolating here, not based on battle scars and victories), where "saving development time" knob is tuned a bit higher, and "most elegant/usable syntax imaginable" is a bit lower. To make a more familiar analogy on the LabVIEW Front Panel -- at the application layer, I would plop a subpanel and insert a VI long before considering creating an XControl, because making XControls takes marginally more time and introduces finitely more risk/liability. On the other hand, middleware/framework functionality to be reused many times warrants investment into more polish to provide that rich experience and in the words of Professor Steve Watts "Fewer WTF's". That's all -- just jumping in to mention that the concepts of XNodes and VIM's "look a lot alike", but I don't feel are competing technologies, since their merits are tuned for different layers of the software stack. And comparing XNodes and VIMs in LabVIEW to Generics of other languages -- VIMs fall short in capability, but XNodes can go far beyond the basic value proposition of a Generic function to enrich your DevX and IDE. (Let's save the conversations for how XNodes could be drastically improved for another day and another thread )

It appears `<vi.lib>:\resource\lvstring.rsc` has not been updated since sometime before LV2014, so for that reason it's not a great "central source of truth" for discovering Abilities. Instead, here's a list that's perhaps a bit more updated, parking here so it's indexed by search engines. This list was generated by simply searching the <labview> directory for all files of type `.xnode`, then using XPath queries to extract all `NI.XItem.Name` abilities. It appears that many of these "correct" names map closely to the stale `lvstring.rsc` names -- for example, it appears that what used to be called "GetImage" is now just called "Image". One important one you'll need: "UpdateState*" is now "UpdateStateWithRef" AdaptToInputs AugmentSelf AutotoolRegions Bounds BuildMenu BuildMenu3 BuildMenu4 BuildMenu5 BuildMenuRuntime BuildPopup CanAcceptDataDrag CheckRefeeChange Compare Compare2 Copy DataDrag DisplayName DoubleClick DoubleClickRuntime ExportStrings GenerateCode GetDataForDrag GetDisplayName2 GetDisplayName3 GetErrors3 GetTerms3 GetTerms4 GrowInfo Help HelpMap Image ImportStrings Initialize L10n ListErrors ListErrors2 Message MessageWithoutEffect ModifyCode OnFontChange OnTextChange OperateClick RefeeChanged ReplaceSelf RespondToDrop SelectMenu SelectMenu3 SelectMenu4 SelectMenu5 SelectMenuRuntime SelectPopup Size SpecifyInsertTerm State Terms Terms2 ToBackgroundForeground UpdateState UpdateStateWithRef Additionally, here's the superset of properties used by shipping XNodes (yes, the top "blank" is declared in many shipping XNodes; I think this is just a cosmetic bug, and not meaningful): Name="" Type="Bool" Name="NI.LV.All.SourceOnly" Type="Bool" Name="NI.Lib.ContainingLib" Type="Str" Name="NI.Lib.ContainingLibPath" Type="Str" Name="NI.Lib.DefaultMenu" Type="Str" Name="NI.Lib.Description" Type="Str" Name="NI.Lib.HelpPath" Type="Str" Name="NI.Lib.HelpTag" Type="Str" Name="NI.Lib.Icon" Type="Bin" Name="NI.Lib.Lic.Feature" Type="Str" Name="NI.Lib.LocalName" Type="Str" Name="NI.Lib.Locked" Type="Str" Name="NI.Lib.SourceVersion" Type="Int" Name="NI.Lib.SynchronizeMNU" Type="Bool" Name="NI.Lib.Version" Type="Str" Name="NI.SortType" Type="Int" Name="NI.XClass.Flags" Type="Int" Name="NI.XClass.Loc.Name" Type="Str" Name="NI.XClass.Name" Type="Str" Name="NI.XItem.ClassId" Type="Str" Name="NI.XItem.DeclaredLeakProof" Type="Bool" Name="NI.XItem.Express" Type="Bool" Name="NI.XItem.InitialDropImage" Type="Bin" Name="NI.XItem.InitialDropSize" Type="Bin" Name="NI.XItem.Name" Type="Str" Name="NI.XItem.StyleName" Type="Str" Name="NI.XItem.SupportsFatalErrorOut" Type="Bool" Name="NI.XNode.GCChaining" Type="Bool" Name="NI.XNode.LazyLoad" Type="Bool" Name="NI_IconEditor" Type="Str"

Can bypass this detail too:

I hear your sentiment, but want to at least commend the continued investment by NI into more XNode capability/stability over the past several years. But yes, they remain hard to develop and opaque and under-powered and quirky and rude to LVClass types, but hooovahh's efforts here will help some of these issues :-) Here, Generics could be a lighter-weight syntax to accomplish the same thing (where XNodes are currently the only reliable implementation of Generics in LabVIEW), but XNodes can do *way* cooler things in the IDE than just type propagation and define function signatures. But totally agree with the sentiment that replacing PolyVIs is keen and high-value with C++esque Templates

`YourExample::Get All Block Data.vi` == `lvrt::REdLoadResFile()`

Protip: attend Challenge the Champions in the Tech Theatre during the Block Diagram party on Tuesday nite -- there, you will find dozens of people headed to the BBQ. I'll email the moderator of that event to make an announcement to help facilitate BBQ-goers find each other in order to share cabs or walk together in droves. See you there!

Unless something has changed since LV2010, determining whether the BD exists in the RTE will be hard: http://labviewwiki.org/Loading_vis It appears that `Metrics: Block Diagram Loaded` "works" in the RTE, but it is hard to test since it is hard to load the BD (as per above link) Have you tried exported LVRTE function `REdLoadResFile()`? That might not be so flaky as the naïve approach to examining the bits. Good luck!

True. Yes. Quick battle story. I was dismayed on a project mid-2014 to realize the root of an inexplicable bug was due to thread exhaustion, which would have been costly to refactor (as in, "let's move this big chunk of the application from LabVIEW to another language"). The failure mode was terrible to debug -- any part of the system could arbitrarily fail at any time! I was delighted to find that manually editing `LabVIEW.ini` to increase values beyond the arbitrary limit of 20 threads per executionsystem/priority imposed by `threadconfig.vi` actually worked! Said another way: "As a LabVIEW developer, you don't have to worry about threads*... until you do... and you will, given sufficient non-trivial applications." * `threads` is interchangeable with `memory allocation` here False... to my knowledge and testing.

Searching `site:ni.com 313508` leads to: https://forums.ni.com/t5/LabVIEW/Process-freezes-for-a-few-seconds/td-p/2309090 Does your application have a similar number of parallel "actors"? (the original post in the thread above mentions 52 parallel "actors) What does CPU usage do during this pause? If you have a lot of parallel loops, and if CPU drops to near-zero during these "pauses", you might be exhausting the thread pool per execution system in LabVIEW. If this sounds like the case, try bumping the thread count higher than 20 (the default). To do this, use `threadconfig.vi` which will then create 25 or so entries in your `LabVIEW.ini` file, then manually edit those numbers using a text editor to be higher (e.g., 50).

+1. Steve Wozniak is credited for saying "Never trust a computer you can't throw out a window"

Likely; mine was, and it appears @hooovahh's was also. One patch for backwards compatibility is to dynamically dispatch via CBR a version saved in LV for <2012 and another for >=2013.

Both, pal! But in LV13.0bxx era, I asked the same question, and the unofficially-reworded response was "yep; we [NI] changed this because previous to this change the AppRef was leaking; just keep it open til you've done what you need to do with the newly-created VIRef, then `Close Reference` on the AppRef and it'll work like it used to, just less-leaky". I've used that guidance for 2yrs now with success; your independently-discovered `*Edit` is the correct way to use this method now.

I spent more time in cross-platform C than LabVIEW in 2014. My respect and awe for LabVIEW was previously naïve and fanboy-ish, and is now tempered with scars inflicted by kernel-level resource management. Will report back in 2016 on how my 2015 view of LabVIEW was naïve. (eyeballing Rust)

Eyeballing your code, the leak could still exist, but not for the reason initially considered that Rolf explains. Below, demonstration how the dtor conditionally destroys only when no error is input (and an unrelated but additional digression from POLA, returning no error destroying an already-destroyed object). The fix at the app-code layer would be to ensure dtor executes unconditionally (by guaranteeing no error flow in), then merging output errors with upstream.

Lisa, welcome to LAVA! +1 for posting the announcement here. To all who have never joined the LabVIEW Beta -- this private forum Lisa mentions used for Beta discussion is an excellent resource for the latest in-depth LabVIEW topics. LabVIEW R&D historically has been active and responsive on this forum, and it's your opportunity to influence the product while there's still a little churn remaining before release.

Step 1: clear your compiled object cache. Same result? Or do you get a "VI Failed to Compile" error after this action? An issue was reported in 2012 for conditional-autoindexed composite types (e.g., LVClasses) in parallel For Loops. Although not mentioned in your original post, is this a Parallel For Loop or not? And is the datatype primitive (integer/bool/string) or composite (LVClass/typedef)?

Search Liskov substitution principle (abbreviated LSP in OO circles). Your #1 choice above is a violation of LSP, and therefore probably not a good idea. --- Using your case study of a signal generator configuration, let's consider our design dilemma centers around the ConPane of "Configure Signal Generator.vi", which is intended to be an abstract method of parent "Signal Generator.lvclass" marked as "Must Override" for implementation by all subclasses. As you point out, this method requires different arguments (input parameters) that are specific to the subclass. This dilemma has at least 3 resolutions that are correct: Use dynamic typing rather that static typing for input/output arguments. JSON is a good choice in 2014 that provides both strong typing and dynamic typing (as opposed to weak typing and static typing). XML is your second choice. INI is a suboptimal choice. Your Own Clever Protocol (YOCP) is a significantly suboptimal choice. LvVariant... exists as a choice (with editorial value judgement reserved at this time). Use dependency injection (DI) and/or constructor injection (constructor is sometimes abbreviated ctor). But! If the constructed object you are injecting can have purely by-val semantics with no by-ref or active object requirements, this could be a code smell. Specifically, since it represents an "OO purist" idiom of circumventing dynamic typing, which represents far less syntax and bloat. (Plus, joke's still on you! You've just deferred and complicated the exact same problem, abstracting the problem of concrete input parameters to the Configuration class constructors rather than implementation methods. Said another way -- object configuration is probably not best solved with DI in LabVIEW.) Acknowledge that "Configure Signal Generator.vi" is an inappropriate abstract method of the supertype, but should instead be reserved as concrete methods of subclasses that "look and feel like they ought to conform to an inheritance relationship but just don't because they don't really IRL and i accept this". There are more incorrect resolutions. Here are some obvious ones where I have tried and failed: Bloat the superclass with subtype-specific methods. Why is this wrong? This violates LSP, enables (encourages?) incorrect usage of subclasses, and throws run-time errors rather than compile-time errors. Bloat ancestor methods with descendent-specific parameters (input and output). Why is this wrong? This violates LSP, enables (encourages?) incorrect usage of subclasses, and throws run-time errors rather than compile-time errors. Inject Signal Generator Configuration.lvclass into the Signal Generator.lvclass "ctor" method (LabVIEW does not have canonical object constructors, hence air quotes around "ctor"). Why is this wrong? I was once excited to have "discovered" this solution, and gleefully coding the Configuration classes, only to realize, on completion of this dual hierarchy of redundancy, the exact same problem existed with the ctors of the Configuration classes. Use #1 or #2 "correct" solution above, when I should have chosen #3. After doing this many times, I realized eventually LVOOP might not contain sufficiently-expressive constructs to represent object models of my application domains. Mixins (or traits), available in modern OO languages, might be a solution, and a construct we could consider rooting for in LVOOP. YMMV! Hope this helps. All bolded terms are searchable.

Justin, thanks for the Win8.1 walkthru; indeed it's a little different than my screenshots from Win7. One thing -- can you provide another walkthru on where you found that "Restart" button on Win8.1? Bonus points for avoiding the word "gesture". ( )

No worries! It's TOTALLY buried in the Windows settings: First, from Control Panel, search for "Region and Language", then click on "Change Keyboards" That brings up this window. If you see in your VM what we see below -- only a single "(Apple)" locale -- it's likely your keyboard shortcuts are not working in LabVIEW: To solve the problem, "Add" a new keyboard, selecting the US keyboard and setting it as the default. Be sure to relaunch LabVIEW if it was open!