Aristos Queue

QUOTE(Clicker @ Aug 9 2007, 06:51 PM)

Here is what I am seeing. Any suggestions or ideas on how to recover from such a mess would be appreciated.

Your .lvclass file is corrupt; more specifically, the .ctl file inside the .lvclass file is corrupt, but it amounts to the same thing. I don't know how it got to be corrupt (that blahblahblah.cpp message would be useful in ascertaining that).

QUOTE(Clicker @ Aug 10 2007, 12:25 AM)

Far far more likely is that something is wrong with the original 8.2 file format and the now corrected 8.5 file format is having trouble interpreting it. There is one known issue along those lines (I put in special code to recognize the corrupt 8.2 files and fix them, but you may have found another form of the corruption). Or it could be as you say, a corruption of 8.5 itself.

I'm playing with the files a bit to see if I can get some more info.

Here's one that was specifically requested by LAVA users:

In Tools>>Options>>Front Panel, you'll now find an option for "Connector pane terminals default to Required." This makes it so that any new input connections (except the error code cluster) that you put on the conpane -- either by explicit use of the front panel wiring tool or using Create SubVI -- will default to Required instead of Recommended. The default is FALSE so as to maintain consistency with past LVs; I expect that most of you experienced users will decide to enable it.

At the LAVA BBQ on Tuesday night, I offered as one of the door prizes a copy of my deck of cards:

http://forums.lavag.org/index.php?act=attach&type=post&id=6583

For those unfamiliar with tarot cards, read here. In short, a tarot deck is a deck of 88 cards that first appeared in the middle ages in Europe used in fortune telling. Each of the cards is symbolic of some aspect of life, and by random pulling of cards from the deck, so the story goes, one may intuit answers to questions.

The PMTDftGP brings the power of card reading to the everyday software release manager.

• Not sure whether a given feature will be well received by customers? Consult the deck!
  
• Need to know when the release party should be scheduled? Consult the deck!
  
• Deciding which programmer to fire during cutbacks? Consult the deck!
  

The deck is designed with a graphical, dataflow interface that G programmers will find immediately intuitive. The 22 cards of the Major Arcana have been redesigned to depict the phases of a programmer's enlightenment. The Minor Arcana come in four suits of 14 cards each -- Wires (R&D), Nodes (Sales&Marketing), Structures (IT&Manufacturing), and Controls (Users). Included in the deck is a nifty instruction card for doing a basic reading from the deck, though the deck is fully compatible with all known ANSI standard tarot layouts.

The images for the individual cards may be downloaded here.

If you would like to print your own deck, then follow these instructions:

1. Visit www.plaincards.com and purchase 1 set of their blank tarot card pages.
   
2. Download the card images formatted for printing on 8.5x11 pages from here. The cards are layed out to be printed on the cardstock purchased from plaincards.com.
   
3. Print the cards using your favorite color printer, or visit Kinko's. Be aware that Kinko's will only print from .pdf formats, so you'll have to convert the .png files over (Mac computers can do this easily by opening the .png files in Preview and then saving as .pdf). Also, make sure you remind the Kinko's staff that the images are 8.5x11 and DO NOT scale the images to fit the printer margins. Failure to do this will waste the very valuable cardstock and make you want to kick a Kinko's employee in the shins.
   
4. Optionally, spray the plaincards after printing with the spray laminate also available from plaincards.com to make the cards easier to handle and harder to stain.
   

Here are three cards as a sample of the deck:

http://forums.lavag.org/index.php?act=attach&type=post&id=6584http://forums.lavag.org/index.php?act=attach&type=post&id=6587http://forums.lavag.org/index.php?act=attach&type=post&id=6585

Oh, and I almost forgot the one I'm busy recommending to all LabVIEW programmers who are interested in OO:

The Object-Oriented Thought Process

by Matt Weisfeld

QUOTE(jzoller @ Aug 8 2007, 08:29 PM)

What software-related books have you folks been reading? (No fair answering with a book that bears your name )

These are arranged in the order that I recommend all software engineers read them. Especially "Close to the Machine". This excellent book teaches a programmer to be aware of the real world impacts of their software.

Close to the Machine: Technophilia and Its Discontents

by Ellen Ullman

Goedel, Escher, Bach

by Douglas R. Hofstadter

The Cukoo's Egg

by Cliff Stoll

"Alice In Wonderland" & "Alice Through The Lookingglass"

by Lewis Carroll

Nexus: Small Worlds and the Groundbreaking Theory of Networks

by Mark Buchanan

Earlier this year I posted stuff about the LV2OO-style global on this site. For my NI Week presentation, that demo has been substantially revised. The VIs are available here:

http://forums.ni.com/ni/board/message?boar...=264064#M264064

QUOTE(Ben @ Aug 7 2007, 01:51 PM)

Concidering who asked that question, I had to stop and double check myself.

Ah. Now I see. I focused on the logic of the "not and" because that was completely different than the gate sequence I would've chosen, so I thought the bug you were seeing was there. I didn't even check the "off by one" problem.

Ben:

What am I missing? The two diagrams look functionally the same to my eye.

QUOTE(Val Brown @ Aug 7 2007, 10:25 AM)

Absolutely -- it's a really cool, intuitive and easy to use feature.

Caveat: It works great for pure VI projects. It has issues when libraries (.lvlib, .xctl, .lvclass or .lvsc) get involved. It can identify the conflicts, but the untangling is much more manual. The tools will become more robust as time goes by.

PS: .lvsc is the new file extension for the LV State Charts, introduced in this morning's keynotes. Some folks would also include .xnode in the list, but I don't include imaginary files in my list. :-)

Strict timing always requires the real-time operating system. You simply cannot guarantee timing using MS Windows or any of the desktop operating systems. You can get very close by turning off screen savers, virus checking, file caching, and a host of other aspects of the system, but you'll never get to the point of zero interrupts in your time-critical thread.

You should talk to your area NI sales person to get a good handle on exactly which LV version is the one for your needs. They're the most qualified to differentiate the different tools.

QUOTE(Val Brown @ Aug 7 2007, 03:12 AM)

already transitioned my 8.2.1 project to LV 8.5. It was an interesting process -- which gave me a great introduction to the "Resolve Conflicts" feature of the new Project interface deployed in 8.5.

Just to be clear to everyone... if you haven't used LV8.5, you might get the impression from this post that there's some sort of great Migration Phase to transition from 8.2 to 8.5. There isn't. But LV8.5 has strengthened the ability of the project to make sure that you're loading the VIs you intend to be loading -- an attempt to fix the ancient curse of Cross Linked VIs. It works pretty well, but when you first load your project in 8.5, if you've got lots of VIs on your disk that are the same file name and multiple of them are referenced from within your project, the project now has a series of tools, including "Resolve Conflicts dialog", to give you tight control over exactly which ones should be part of the project and associated with what caller VIs.

QUOTE(Tomi Maila @ Aug 6 2007, 03:03 PM)

Is it always the rookie that files all the bug reports?

This is like Supreme Court Justice Stephen Bryer... in an interview, he said he had been the newest justice for 12 years, and the newest justice is the one who has to answer the door if anyone knocks while the judges are debating. 12 years of answering the door!

QUOTE(eaolson @ Aug 3 2007, 05:06 PM)

See, answers like this are why I bother to ask questions. I had been thinking of the refactor reason myself, but using it for range checking makes it go from "handy" to "damn useful." To be honest, I'm surprised that subVIs don't enforce the Data Range criteria for front panel controls for this very reason.

There's a good reason for this but I can't remember it right now. It made sense when it was explained to me long long ago.

QUOTE

Spin off, fork, merge... you name it, we've probably had a reason to do it. The Mindstorms NXT was a fork of the entire source base at one point, for example. It does make versioning and VI mutation rather interesting sometimes. I honestly don't know how many forks/revisions are in development at the moment.

QUOTE(Omar Mussa @ Aug 3 2007, 04:00 PM)

This is the age of information

So did you 'fix the glitch' (ie remove it completely) or decide to make it work despite your arguments for accessors (which btw, will ultimately need to unbundle and bundle data from a class wire)?

I fixed the bug that made insert of a Bundle node not find the right terminal for the LVClass. In a future LV version, Bundle will insert correctly when you are on a member VI of the LV class. We're not ever going to have public or protected data on my watch.

QUOTE(eaolson @ Aug 3 2007, 03:33 PM)

I'll admit my ignorance and confess I've never understood these benefits. If you're talking about get() and set() methods working on a private data member, I don't see any significant benefit of doing things that way compared to just using a public data member. You lose both data encapsulation and data protection.

I assume these benefits exist, I just don't understand what they are. Visual C++ went so far as to add the property keyword which sort of automates the creation of a data object along with its get and set accessors.

Advantages of a write accessor:

1) Suppose that you have a cluster that has a wrong value in it. Where did that wrong value get set? You search your entire LV hierarchy for all the bundle/bundle by name nodes, set a conditional custom probe on each one, and run until you find which one is the problem. Compare that with you open the only VI that is ever used to bundle new values into the cluster, set a single conditional probe, and run until you find the problem.

2) A given field of a cluster is supposed to always have a value in some range. Everytime a VI bundles a new value into the cluster, you have to remember to put the range checking code down. Compare that with only a single VI able to bundle new data in, it becomes easy to enforce range checking on values.

Advantages of a read accessor:

1) Suppose you have a cluster of data about a person. One of the fields is "age". Your program works great. But the next year you realize that you have to update your entire database to add one to everyone's age. You realize that you were silly to store "age" as a numeric. You change to store a Timestamp and whenever someone asks for age, you subtract from the current date. If you have a raw cluster, you now have to visit every point in the code where they were directly unbundling "age" and change it to call a subVI that unbundles Timestamp and does the subtraction. Had you had an accessor in the first place, you wouldn't have to revise any of the code except the accessor VI.

These are the big three: debug, range check, and refactoring. There are other smaller advantages. The debug advantage is so pervasive as to warrant using accessors for all data that will be accessed outside the class itself (and sometimes it pays to use the accesssor method even on VIs that are inside the class).

QUOTE

Yessssssss.... who wants to be Igor? Submit resumes at NI Week!

QUOTE(Omar Mussa @ Aug 3 2007, 03:41 PM)

LV 8.5 hasn't been out for a full day yet, but I already get to post this:

This is known and already fixed in a future version of LabVIEW. *sigh*

Users: Recursion? In LV8.5? Did he really say that?

Me: Yep.

Users: This isn't some VI Server hocus pocus is it?

Me: Nope.

Users: This is honest-to-goodness-subVI-on-its-own-block-diagram recursion, right?

Me: Yep.

Users: What's the catch?

Me: Well, you've got to use LVclasses to get it. Mwuhahaha!

Details? Check out LV8.5, and look at

examples\lvoop\Recursion\Demo Recursion.vi

Ah. I feel better. I've been wanting to announce that for many months now.

Eventually someone will ask why non-LVClass VIs can't have recursion. The answer is, they can, and someday they will. But LVClasses were already positioned to take advantage of some of the early refactoring work needed to make recursion possible. For now, I like to think of recursion as bait, to draw users into trying LVClasses who wouldn't otherwise. :-)

QUOTE(Omar Mussa @ Aug 3 2007, 03:06 PM)

I just installed LV 8.5 evaluation and it looks like you can now 'find' dynamic dispatched VIs as expected now -- both from the traditional 'Find All Instances' and the new project 'Find Callers'.

Oh. Hey! Look at that! 8.5 is available.

(I never know when that's going to happen... R&D hands over the final CD to a figure in shadowy darkness who disappears into the night, and sometime after that everything goes live.)

In that case...

Perhaps you should check out the new "Cluster, Class & Variant" palette on the block diagram. ;-)

QUOTE(Omar Mussa @ Aug 2 2007, 08:01 PM)

1) If you right click on a class wire and select insert, the context menu you see shows '[class name] Pallete' (grayed out) and 'All VIs ...' --

I expect to see the cluster pallette so I can insert a bundle or unbundle by name (assuming I'm in a class method). If I navigate to the bundle/unbundle by name function, LabVIEW miswires the inputs and I have to manually reconnect them. This is really a bad behavior from a class developer perspective.

We created classes to be able to generate new LV datatypes. One of those requirements is that the new datatype be able to look like a new type and not specifically a LabVIEW class. So the popup palette for a LV class is completely definable through its Properties page. We didn't add a default palette. This is a decision that has been both praised and damned and may be revisited in the future. One of the issues is "Should you show the App Control palette (with the To More Specific prim) or the Cluster palette (with the bundle/unbundle)?" We'll talk about this topic more when we get to your point #5.

QUOTE

Sorry... this is correct behavior and is not subject to review. Create a protected accessor VI to give children access to parent data. All the arguments for why there is no public data apply to why there is no protected data. There are so many programming benefits to channeling access to data through accessors that any weakening of that wall is going to take a pretty compelling use case, which no one has yet proposed. We will be making it substantially easier to create such accessor VIs in upcoming LV versions.

QUOTE

A definite weakness. Something that is on the "must be fixed soon" list.

QUOTE

CAR'd for bug fixing.

QUOTE

Yes. There should. (*yells over shoulder* Hey, rest of LV R&D, you see, at least one user agrees with me!! ).

Let me highlight part of your quote again:

QUOTE

I *sooooo* agree. :-) I have been told that to be a first class citizen, a feature has to have users first. There's a chicken/egg problem here, but I have been slowly assembling a chicken from spare parts. Continuing this odd analogy, perhaps I should start giving out certificates to early adopters. "Congratulations, you're part of the LabVOOP Chicken!"

QUOTE

Congratulations, you've just identified some, but not nearly all, of the major usability issues with LV classes. I will now dance happily since none of these are *functionality* issues. Functionality for the 8.2 release. Usability comes next. There's only so many hours in the day to work classes into all of LV's nooks and crannies. :-)

QUOTE(bbean @ Aug 3 2007, 10:06 AM)

http://forums.lavag.org/index.php?act=attach&type=post&id=6526''>http://forums.lavag.org/index.php?act=attach&type=post&id=6526'>http://forums.lavag.org/index.php?act=attach&type=post&id=6526

I keep getting this error and even if I delete the file it mentions. It doesn't get fixed. Also I don't even think I have a "controls" pallete in the user.lib directory. :headbang:

Just a guess, but I would try launching the paletted editor, going to the controls palette, and deleteing the subpalette that references this file.

QUOTE(zoogies @ Jun 25 2007, 04:05 PM)

But I just wanted to gather you guys' insight; maybe there's some awe-inspiring new feature in LV8.2 that should jump out at me?

I didn't spend six years developing LabVIEW classes so that you guys could stay at LV7.1.

Yes, LV classes should jump out at you as awe inspiring. Unfortunately, it's hard to sell them as awe inspiring (an ongoing problem I'm working on).

If you're doing any substantial desktop development (classes don't yet go to the various target platforms) then classes:

1) ... help write more organized VIs

2) ... help make VIs that are easier to debug

3) ... help write VIs that are easer to extend with new features

4) ... help write VIs that are easier to hand off to the next developer

5) ... help write VIs that are easier to reuse

The folks who've heard my sales pitch in person know that I mean every one of those claims. Not everyone believes me, but the number of converts is growing.

Stability? Yes, there were seven ugly bugs in LV8.2 that are fixed with the 8.2.1 patch. There are still some glitches in LV8.2.1, but it just keeps getting better. I can't promise that LabVIEW classes are the way of the future for LabVIEW development, but they will be if I can convince enough people to try them and to realize the power and potential.

This was reported to R&D (CAR 4C1A37J1) for further investigation.

QUOTE(dsaunders @ Aug 2 2007, 10:52 AM)

The popup is 'part' of the control that is on that VI front panel. No matter how it is implemented it should not state that you left the VI's front panel. This is new behavior with LV 8.2 as well.

The drop box can actually over hang the edge and/or bottom of the window (and it can over hang the top of the window in the case of a very large drop menu). That's why it is implemented as a separate window -- it is actually a different window. You have left the front panel any time you are over these components. You get a VI Window Leave because the operating system has a VI Window Leave.

I am very surprised to hear that this is new in 8.2. Very surprised because the implementation of the rings/enums has been this (again, to the best of my knowledge) for as long as there have been rings and enums. I would expect this behavior to go back to 6.1 (the introduction of the event structure). The fact that it doesn't replicate says to me that someone fixed a bug. Probably we weren't detecting other cases where we had left the window, leading to various bugs in other VI use cases (such as someone implementing custom popup menus or somesuch by creating temporary windows).

QUOTE(Ben @ Aug 2 2007, 10:22 AM)

This only support my theory that LV FP object are getting converted over to XControls.

No. What it should support is a theory that drop boxes are implemented as hovering windows -- just as they are in every other app environment that I know of. The VI Mouse Leave event is correct in that respect ... the mouse is now over a different window. I believe you'll get the same thing with popup menus.

QUOTE(Ben @ Aug 2 2007, 10:22 AM)

I think we have. When XControls were new in 8.0, there were zero in the palettes and (to the best of my knowledge) that was because none of NIs controls were XControls. I think that remains true for all the core LabVIEW controls. XControls have started showing up in some of the modules and toolkits, but all the ones I've seen are wide open (no password protection).

I don't see a CAR number. Has someone reported this to NI?

QUOTE(PaulG. @ Jul 31 2007, 03:48 PM)

The most common reason to make sure a VI is NEVER reentrant is in a functional global where you store data in uninitialized shift registers.

At the risk of confusing everyone, I do have many functional globals that are reentrant. That's how I can create separate databases -- the core VI is reentrant and contains the uninitalized shift registers. Then I create a series of wrapper VIs that are not reentrant that will be my entry points. Each wrapper VI is thus a single shift register database.