
styrum
Members-
Content Count
33 -
Joined
-
Last visited
Community Reputation
1About styrum
-
Rank
More Active
LabVIEW Information
-
Version
LabVIEW 2016
-
Since
1999
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
-
styrum started following Can we build custom type files into EXE?
-
A nasty caveat with "Preserve disk hierarchy" is that you can end up with too long of a resulting path string for some files in the build which is still not too long in the source. There is an apparent limit on the path length (in terms of total number of characters including the file name, not number of folders levels) after which LabVIEW (Windows) refuses to open a file with such a "too long" path (this can happen with unzipping a deeply nested archive into a too deep folder of too by the way). The limit can manifest itself even at a build stage (Error 6). But it is worse when it happens wh
-
As I suspected, the short answer is: no, we can't. This was confirmed to me by a known expert in LabVIEW application building and deployment Matthias Baudot from Studiobods. Merci beaucoup, Matthias! Here is his answer: Unfortunately, it is not possible to embed custom files inside the executable when building a LabVIEW application. Only “code” files in the point of view of the LabVIEW Run-Time Engine can go inside the executable. Other “support” files must go in a separate location on disk. Therefore, it is not possible to do what you want. However, you could configure your exe buil
-
I have an additional (custom) project item(file) type defined and a primary project provider for it, complete with its own icon/glyph and a dedicated editor for editing such files. Such files contain just some additional info about the class as a plain XML/JSON text but have a custom file name extension. I manage to store such files within class libraries in the project (.lvclass files are just XML text too) as yet another type of class files (in addition to .lvclass,.ctl,.vi). Just like in the case with class method VIs in classes inheriting from one another, there can exist this new type of
-
Object-Oriented Programming — The Trillion Dollar Disaster
styrum replied to styrum's topic in Object-Oriented Programming
Much longer "nail to the coffin" 😜 of THAT KIND of OOP (written 5 years earlier than the subject rant/"opinion"). Or an entire box of nails rather. And even interfaces introduced in 2020 don't help LVOOP considering all those "nails". Even if you don't read the whole thing, notice the same conclusions (recommendations of alternatives) in the end regarding the paradigms and languages to use instead: actor model (Erlang) and/or functional programming (Haskel, Closure). Again, it was written in 2014. Also notice that some comments above are too similar to "No True Scotsman..."😜 h -
Object-Oriented Programming — The Trillion Dollar Disaster
styrum replied to styrum's topic in Object-Oriented Programming
Exactly! To implement an actor in LabVIEW one doesn't need LVOOP! Quite a few "asynchronously communicating modules" producer-consumer design patterns, developed by different people independently from each other including my LabHSM and EDQSM show that very clearly. After all, LVOOP didn't even exist when mine were developed. One can get away with just a cluster in a shift register to access any the data from any action case, but, OK, lets instead make an instance of a "regular" (LVOOP) class and make each action case just call a corresponding method of that class. It will look a little cleaner -
Object-Oriented Programming — The Trillion Dollar Disaster
styrum replied to styrum's topic in Object-Oriented Programming
Quite a lively 😀 discussion on Slashdot: https://developers.slashdot.org/story/19/07/22/0426201/is-object-oriented-programming-a-trillion-dollar-disaster -
Object-Oriented Programming — The Trillion Dollar Disaster
styrum replied to styrum's topic in Object-Oriented Programming
I think it is important what exactly we call "OO code". If objects are not simply "dead" combinations of data and methods, but rather have their own "life"/"process", exchange messages with the user, "environment", and other objects the way actors do, react to events, I am all for such "OO code". The "regular/"passive"/"C++/Java/C# style" objects indeed have a very limited use and I agree that the attempts to build large applications using only them by constructing and utilizing complicated inheritance hierarchies and design patterns can lead to a disaster. -
Object-Oriented Programming — The Trillion Dollar Disaster
styrum replied to styrum's topic in Object-Oriented Programming
😂He knew what was coming: " I expect some sort of reaction from the defenders of OOP. They will say that this article is full of inaccuracies. Some might even start calling names. They might even call me a “junior” developer with no real-world OOP experience. Some might say that my assumptions are erroneous, and examples are useless. Whatever. " I think we all still can benefit from a more substantive discussion of his particular points rather than from accusations of "not understanding", let alone "calling names" and insults. A "straw man" demagogic trick is no good either. Th -
Some food for thought: https://medium.com/better-programming/object-oriented-programming-the-trillion-dollar-disaster-92a4b666c7c7 Note that LVOOP is indeed the "C++, Java and C# variety of OOP" too, and is taught the same way, complete with "cats and dogs", all the same "Gang of Four" design patterns, S.O.L.I.D (https://scotch.io/bar-talk/s-o-l-i-d-the-first-five-principles-of-object-oriented-design), etc. " The bitter truth is that OOP fails at the only task it was intended to address. It looks good on paper — we have clean hierarchies of animals, dogs, humans, etc. However, i
-
Yes, checking the watchdog queue takes a lot of time (if not most of) in each sender iteration. Please check out a "sequential version" in the latest posts or try putting a Disable structure around those Preview Queue Element nodes in the sender VIs (you will have to stop everything with the stop button on the toolbar of the Main then).
-
Ok, OK, my bad, I left Debugging enabled. This is not a commercial app. This is is just some "food for thought", and something to play with, which you would otherwise not have the time to put together yourself. But now you can find some time (much less) to play with it. The goal was to get people to play with it, find flaws, "unfairness", etc. So I am glad that happened so quickly. Here is a version that has debugging disabled plus a "sequential" flavor of the whole thing. Some disclaimers right away: 1. Yes, I deliberately do not count the iterations completed by sender loops but no