-
Posts
3,183 -
Joined
-
Last visited
-
Days Won
204
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by Aristos Queue
-
-
I tried to puzzle it out from your text description, but I couldn't get a good grasp on the situation. If you can post VIs, that would help a lot.
-
- Popular Post
- Popular Post
Kudos to someone named Miha who created The Flea's Knees font and posted it in her blog for all the world to use.
In this font, all the alphanumeric characters in the plain roman face are no more than 4 pixels wide, yet surprisingly readable. Then she gives us italic, bold and bold italic forms! The font takes advantage of subpixel coloration. There's no font file that you can install to type in this font (because it is a full-color font, the normal type interfaces don't work right), but perhaps someone will want to extend the icon editor to allow typing in this font. Here's the finalized images from Miha:
-
3
-
No go. You need a *constant* value, something that can be set once and only once in the entire run of the app. It cannot take *any* inputs and its only output is the class value. All of this is conception only -- since we started deploying on RT, as I said, I'm not sure that the centralized bottleneck exists that would let us make this work. It's messy even to think about.I like the sound of this feature being integrated.
However, it would not help if your constructor required inputs???
Thinking out loud...
- Would it be possible to flag a method VI as a constructor and somehow check that there are no constants on the BD (sounds tricky)
- What about when you drag and drop the class/control onto a BD it could automatically drop the flagged constructor VI instead?
There is one option that hasn't been discussed in this thread: Suppose my parent class has a field "Color" and a "Get Color.vi" and a "Set Color.vi" both of which are dynamic dispatch. The parent class implementation of Get and Set just returns the color field or sets it (respectively). The child class has a boolean field "Has been set?". It overrides "Set Color.vi" to set the boolean to True and then calls the parent version to set the field. The "Get Color.vi" override checks 'has been set?'... if it is True, it calls the parent to retrieve the value. If the value is false, it returns its own local constant value.
This avoids the need for a constructor, it makes block diagram constants and controls behave exactly as requested in the original post. It is more effort than a programmer might wish to deal with.
-
The feature requested in the original post does not exist in LabVIEW. We've talked about some sort of specially tagged VI that runs once when the class is reserved to set the default value that will be used for the rest of that run (and which every control/constant that is using the default default value would therefore use), but it hasn't ever been implemented. Since there is no central copy of the default value on RT systems, that would be hard to implement there.
-
One question remains though why aren’t we allow to do this?
There are four "interesting" cases of a class containing itself in its private data cluster. The cluster could contain...
- ... the class cube directly [this is functionally identical to the class cube inside a nested cluster]
- ... the parent class cube directly with the default value set to an instance of the child class
- ... the class cube in an array
- ... the class cube in a refnum (DVR, Queue, Notifier, Datalog, User Event, User Event Registration)
If we're talking about direct inclusion (case #1), Daklu got the answer right in his post above. The same infinite allocation that he describes would happen in use case #2.
So cases 1 & 2 are off the table permanently as "logically impossible to ever implement" (unless LV ever introduced a lazy evaluation language syntax which would be a very different programming model than anything that exists today -- I mention the possibility only so that someone doesn't say something like, "If it is impossible, how does Lisp or Haskell do it?")
For case #3, if the array is non-empty, you have the same problem as 1 & 2, but if the default value of the array is empty, it would be fine. Case 4 never has to allocate the actual data of the class (it just allocates space for a reference cookie, a cookie whose default value is always Not A Refnum), so it should work. That, I think, is the heart of Mikael's question: Why doesn't this work in LabVIEW?
What we found is that we could get some significant performance boosts during load, notably dynamic loading into an already running hierarchy, if a class hierarchy has no circular dependencies (meaning it does not reference itself, including indirectly). There's a lot of work to identify which class can instantiate and reserve first. If all the references are changed out for parent class references, users can still write all the functionality (albeit with a slightly modified syntax than they would generally try first) and LV could simplify the load and reserve algorithm considerably. I looked through various lists of recursive data structures. The most common that I saw were composition patterns, such as is in the Graphics shipping example in LV, where Collection inherits from Graphic and includes an array of Graphic. Those are unchanged because they are already including their parents, not themselves. The other class was the linked lists, trees, and graphs. Honestly, I expected most of these to be written once by someone who was an expert in LVOOP and then most users would just use them as libraries. That expectation was predicated on other features of LabVIEW existing which have not come to fruition. Even so, it appears (based on AE reports and my looking at user code when I get a chance to visit customers) that very few LV users ever attempt to build anything recursive, much less a recursive data structure, so I wager most of those who attempt it are people who are power LV users who generally know about LAVA and will post questions (like Mikael's) and find these answers.
Even better, define a parent class that is not recursive with dynamic dispatch methods for anything that would be recursive, then define a child class that overrides all the necessary VIs. That way you avoid the downcast. As of LV 2010, dyn dispatch is faster than downcast (although the compiler team is working on some new optimizations for future LV versions that may change the balance of power here).Not true. You can implement the composition pattern. It is perfectly legal for an object to contain instances of itself at runtime. You just can't define a class with a self-reference. Use LVObject as a container and do the downcasting as part of the accessor methods.
The <labview>\examples\LVOOP\Graphics\Graphics.lvproj has an example of the composition pattern.
-
1
-
I really do have to put my money together, bite the bullet, and actually buy one of the Austin Utilikilts that I've been eyeing the last couple years.Pants.
Sometimes they're a good thing.
-
More of a message passing interface between a server and client, but either one of those parties may essentially implement an events registration mechanism on top of the message passing interface (i.e., I pass you a message that says "next time X happens, let me know." When X happens, you send me a message to that effect.)"Listener framework" == Observable/Observer?To give you a clue how similar what I've been assembling is to yours, the name of my project file is "Actor Objects.lvproj". :-)
PS: You clearly have a larger monitor than I do. All the VIs are saved just barely on the screen.
-
I'm afraid a lot of us will have to miss Jim's presentation in order to catch flights at the airport.- LabVIEW Object-Oriented Programming Design Patterns for Large Systems - Thu 1:00 PM
-
This is exactly what we have thus far. The extra complexity is entirely hidden within the subVI that does the launching, so it doesn't have to be repeated each time.Alpha creates a temporary sync object to pass to Beta (usually a notifier to hold the final sync object reference), starts up Beta, then blocks on the temporary notifier. Beta starts, creates the permanent object which it owns, and signals Alpha using the temporary object, then continues on its way. Meanwhile, Alpha receives the permanent object reference, takes note of it, and continues on it's way, passing signals as appropriate.
In general, we might be ok if Beta misses some signals, but the key signal to Shutdown is one we cannot afford to miss and that's the one most likely to be missed without this set up.
-
Yes I think i will use an occurence with the OpenG wait with a timeout of 1000 ms, that should do the trick. I am reluctant to give the destroy to the child process since I don't have control over it, and the event registration is created in the main process, and I am a fan of the 'destroy what you create' philosphy.
Then let me suggest that the wrong process is creating the event refnum. ;-)
This is a problem that I ran into with a listener framework I've been working on lately. Alpha.VI dynamically launches Beta.vi and then gives Beta.vi a queue refnum so Beta can receive messages from Alpha. We had to turn that around -- Alpha launches Beta and then Beta creates the queue and gives the refnum to Alpha. That way the lifetime of the queue is the same as Beta, not Alpha.
In your case, it sounds like the correct behavior is for your consumer to create an event refnum and give it to the sender. That way the consumer can dispose the refnum after it handles the event and "destroy what you create" policy is preserved.
-
1
-
-
Man, I hope Todd (the judge) picks my questions to use for the Challenge this year. I submitted a couple really cool (IMHO) ideas.<-- member of LabVIEW R&DFor those who weren't there last year, the challenge I submitted was to write a VI that failed at least 10 of the VI Analyzer style tests. It was quite amusing watching programmers have to fight their own tendencies to write good code -- one person kept reflexively fixing the style problem and had to keep putting it back as he worked. :-)
I don't sleep that week. Hanging out with Norm and attempting to leech some of his infinite energy is sometimes useful strategy. I've also attempted simultaneous physical manifestations in multiple locations... that works, but the reintegration is a real pain. Reading blogs later for the sessions you miss works better.How much time to guys you make outside of sessions to see everything else (floor expos etc...)?-
2
-
-
Ok... you cannot have two VIs in memory of the same name, so the manifest VI cannot have the same name in all the LLBs.
Option 1: What if the manifest VI has the same name as the LLB but with the extension swapped out? That gives you a consistent way to find the manifest VI every time and no risk of collision in memory because each LLB in your directory has to be uniquely named.
Option 2: Name the manifest VI the same thing every time, but put it in a library that is uniquely named and put the library also in the LLB. I hate this option because it piles hacks upon hacks, generating a second useless file to work around the limitations of the first.
-
Well... it's a hack, but...
You could add a stand-alone .vi file -- one that isn't a member of the class and has a blank panel and diagram -- to the LLB and then put a VI Tag on that VI that has all the info you want to include. Load just that VI and read its tag data to get the info about the class packaged inside the .llb.
It's the best idea I've got this morning.
-
Yes, it can be done, but it isn't really a good solution. Why? Because access to a singleton object *must* have some sort of thread protection around it -- that's the entire point.I know it's a older thread but I came across it when researching the Singleton object. My problem with all the implementations of singleton is that I encountered so far is that they also rely non-reentrant VIs to achieve single instance. Is there a good way to implement this using all reentrant VIs.
If you make it reentrant, then you introduce the need for some sort of single-allocation storage. That moves you to one of these two solutions:
1. a global VI AND use of the Semaphore palette to protect all accesses to that global VI
2. an internally allocated Data Value Reference, which works as long as you only have one top level VI referring to the singleton because otherwise you run into lifetime management issues.
Since singleton access really has to be serialized anyway, it's easiest to just use the non-reentrant VIs. You get zero advantage out of making something reentrant when it has to serialize its access anyway.
-
Getting to the class by the Name property works, whereas the Path property returns a blank when the class is not saved and the Open VI Reference for the Control returns the error 1004
The name mashing is still the same as it is still similar to the previous thread.
I guess it only matters if you are reading the class off disk and not in memory, then it would be saved anyway so use the Path.
Just noticed this... actually, you would *always* use the Name and never the Path. Why? Because the class name will include its fully qualified name. If the class happens to be a member of a library, it's qualified name is X.lvlib:Y.lvclass, and you need that full qualification when you build X.lvlib:Y.lvclass:Y.ctl or else Open VI Reference by name won't work (or will give you a completely different CTL if there happens to be a plain Y.lvclass in memory at the same time). -
Ticket purchased.
-
You don't have a mechanism to do this, and if you find one, it's a bug that should be fixed. The class' data is private. If the class does not provide a mechanism for you to get at all of its fields, you do not have any way to get at all of its fields. This is by design.But I don't know how to get the whole attribute cluster.Some folks have figured out ways to take the flattened string for some known cases and manipulate that directly. That's a hack that can be made to work, but there are limitations to that approach.
The Read All Attribute VIs mechanism that you mention at the start is the right, good and correct way of doing this.
-
At least. :-) Fourteen would be about the fastest we could roll them, and most of what you'd see in 14 months are the ideas that are at the top of the list already, the ones that already have high kudos. 26 is a better guess if these get voted up.Nice, but I guess it will take at least 14 month until we'll see any of these features in LV :-) -
I've reviewed all of the 1140 ideas currently on the LV Idea Exchange. I've picked out 24 ideas that have fewer than 100 Kudos that I think are good ideas that, for whatever reason, have been overlooked by the community. If you have been daunted by the sheer number of ideas, here's a reduced set for you to take a look at and consider kudos'ing. Taking a few minutes to review them might just help your LV experience in the future:
-
1
-
-
At the moment this is true... ideally that would not be true. A class is a library and should be able to contain other classes. There's a technical difficulty we have in LV (dumb design on our part) that keeps that from happening. My hope is that this can be overcome in a couple years when we finish a larger refactoring effort.Everything in parenthesis must be a library, and everything not in parenthesis must be a class.
Yeah, I didn't comment on that earlier. Tst on the NI forums summed up the problem nicely:I pulled a Homer with the earlier suggestion of using a tree view to show namespacing. The inheritance dialog box already uses a tree view to show the inheritance hierarchy.So far, I don't remember placing classes inside .lvlibs, so I can't really comment on this, but I think that if you do it nested it will be confusing, because you're combining the inheritance hierarchy and the ownership hierarchy in the same tree. -
I'm guessing this is because the classes aren't smart enough to know (or maybe simply can't know) that the parent's fully qualified name was changed
This is by design.
As far as the child classes are concerned, if they inherited from "A.lvclass" and when they load into memory they find "X.lvlib:A.lvclass", well, that's not their parent. You're asking kindergarteners to go home with strangers who happen to share Mommy's name. Won't someone think of the children?! :-)
If you change the parent's name while the children are in memory, then they'll know about the name change and not load broken. In other words, parents should bring the kids with them to the Justice of the Peace when they get their names changed, so we avoid these socially awkward scenes in the grocery store with the child screaming, "You're not my mother!"
:-)
Bingo. Absolutely correct. Unfortunately, that trick is not on the roadmap at this time.Come to think of it, I don't think your use case *can* be addressed without decoupling libraries and namespaces.
When you changed the parent's name, did you do File >> Save All on all the children? Or did you exit without saving the children?What I don't understand is that everything is already in memory so why aren't the parent links automatically updated to reflect the new namespace without using the workaround?-
1
-
-
I think that's fine. I hope classes not in .lvlibs appear before or after, not intermingled, though.
Nope... they'd be part of the alphabetization if I had the lone vote. That's actually kind of key -- you'd look it up by its qualified name. Otherwise things get messy -- would you want all the 2 level names before all the three level names?
A.lvclass
B.lvclass
Z.lvclass
X.lvlib:C.lvclass
Y.lvlib:D.lvclass
X.lvlib:A.lvlib:E.lvclass
X.lvlib:Z.lvlib:F.lvclass
Y.lvlib:Z.lvlib:G.lvclass
That's mighty strange. This is the order I'd want them in:
A.lvclass
B.lvclass
X.lvlib:A.lvlib:E.lvclass
X.lvlib:C.lvclass
X.lvlib:Z.lvlib:F.lvclass
Y.lvlib:D.lvclass
Y.lvlib:Z.lvlib:G.lvclass
Z.lvclass
-
Do you have a personal preference over which display method would be ultimately advantageous - or are you happy from a user perspective of the current implementation?
Personally? I would prefer the fully qualified name be displayed, as in "X.lvlib:Y.lvclass" and alphabatize the list by the entire string. The dialog is as it is today from feedback from various and sundry when it was created X years ago, where X is receeding further into the depths of memory.
-
Haha! I was thinking this exact same thing when I posted up the Idea - but I wasn't game enough to write it
Kudos for balls!
Yeah, that's the sort of "option" that ultimately makes things less usable -- most people toggle it once if ever, it clutters the screen, taking real estate away from other elements, and it opens a source of bugs for a rarely tested code path. Every usability guide you'll ever read will condem this sort of option, and if you doubt, you can run the usability studies to confirm it. Data presentation in a dialog should be something you commit do and do, not something you waffle over. Even if a few customers find the result less optimal than another option would have been, the net is still more usable than introduction of the option.
-
1
-
New Cluster "Constant"
in LabVIEW General
Posted
"The Gravitational Constant is a variable in my equation."
Variable does not mean necessarily changeable. It can mean just value. A cluster is a collection of values. Those values might not change. If they don't change, they are constants.