Val Brown

I wasn't aware that inheritance per se was "anti-dataflow". I do understand that byref implementations could be seen that way in certain use cases, or as an overall model for organizing OO within a dataflow environment/language, by I really don't get how byval implementations inherently are anti-dataflow. Am I missing something?

This is precisely what I want to hear.

Right, me too. I'm President of the company and Chief Software Architect but we only produce one system (two versions of that) and I don't consult for anyone else on LV. But thanks for the compliment.

I found the course to be good but I agree that the most important value of the course is the contact it provides you with knowledgeable users and instructors who can help by providing their expertise and experience. My disclaimer is that I currently have no LV certifications because my company is basically me, I don't need to present qualifications re: my programming to others for vetting (because I don't consult on LV). But I have been using LV since 98. So I've seen a lot of versions....

FWIW, simpler is generally better IME and reuse of code -- or original code "ideas" -- as far as possible is also good. Simply moving to a byref implementation doesn't necessarily seem better to me but I'm sure others here would have a better sense of the utility and details of doing that. I'd follow up on the simple idea of: Use the refs for dynamic dispatch and do the HTML collation/correction/printing down in the dirt. It's an old unix scheme....

As you all might guess, I see this a bit differently -- given that we're all functioning in LV which is byval in its exposed interface. The idea that the byref construct is "better" comes IMO from a history of having learned it first (generally in a CS program) and then assuming that the optimal way to program is to follow that paradigm and that would include the necessity of being the MemMan god, instead of just knowing how it operates for you in a certain well implemented byval environment like LV. So you have two broad choices: 1. try to force LV to be as byre-like as possible (which is the basis for a number of these suggestions, like the virtual parent) 2. accept and use the native tools and this would mean esp, release the need to believe that you can optimize memory management IFF you were allowed to be god. If you adopt the second course then creating the refnum and checking for a null refnum is IMO the way to go. It's simple, direct, is inline with the paradigm and it works, esp because you can count on the native MemMan god of LV to do its job. Just my two cents worth.

Well damn, I hope this isn't the Peter principle writ large.... Seriously AQ, I guess that congratulations are in order but I didn't actually hear you say that you're really looking forward to this change, or that you even especially wanted it so I guess the jury is out on some of that but still and FWIW -- congratulations! :beer_mug: Now for the really serious aspect of this. Who will be "filling your shoes"? The obvious answer is: No one, because no one can no matter how good they are. So let me rephrase that: who in your opinion is the "goto guy" now (bearing in mind that guy is a metro term so not gender specific)? Who can LAVA and the rest of the LV world count on for the "real story" and for a strong and clear advocate for users, esp knowledgeable and experienced users? It's a real question and I shudder to think what it means if there isn't a really clear, good answer. In any event I know that you'll bring your enormous talents and dedication to your new responsibilities and we'll all benefit from that -- as we always have. And many, many, many thanks for all the wonderful contributions you made to this forum and, of course, to LB itself over the years.

Yeah, jargon can always get in the way. Like Shaw said: "England and America are two countries separated by a common language." Thanks for the confirmation of that and my (I think I got it) understanding.

Actually it's a "standard" install which includes installing the Guest appropriate VMTools so nothing unusual to support hardware (e.g. USB) under Windows as a guest in VMWare Fusion. I know others who use Parallels which I used to use until I became REALLY annoyed with their "licensing" process. So I switched to Fusion and have been a happy camper ever since. So.....back to the OP's question: What flavor of Linux have you been using to support LV? In particular has anyone used unbent?

Yes, the latest VMWare Fusion (4.1 I believe) actually does a pretty fair job with direct hardware calls for W7. I have a driver for a USB device with a double enumeration that I wrote with the LV wizard and it works pretty well -- at least for initial development work. Since we deploy on native W7 systems I do final testing on those but for development work, Fusion does the job and lets me have a single laptop to carry around.

Right, understood about the direct hardware calls. I already do Windows development work using VMWare Fusion, so I know how that goes and am not using NI DAQ (rather my own hardware) nor vision.

I'm wondering what flavors of Linux others have chosen to use to support LV. In particular I will want to also support running Linus under VMWare Fusion, so would esp like input for others who had done that specifically. Thanks in advance for your replies. val

So if I'm following this, jgcode you would "approve" of FGVs as an accessor but not as a wrapper, whereas others are OK with using FGVs as wrappers, using either a (large) typedef cluster for the inputs and outputs, in that sense turning the FGV into an "accessor" if you will to a collection of methods, properties, etc.

But we're still back to the same fundamental point: why do you really want to check for such "equivalence"? I know and understand that some people "clearly want to" as you point out but that does beg the question IMO. Isn't there at least one better way to architect so that checking for such equivalence isn't needed?

The same could be said about real globals, goto, getjmp() and setjmp(). Of course somewhere, "under the hood", pointers are used but the whole point IMHO is to specifically NOT exposed that, not make someone have to know the intricacies of optimizing for particular compilers, specific memory management, etc, etc because the G language handles that part of the "indoor plumbing" in a sane, predictable way -- if you actually let it do so. And when it doesn't, then it's time for a CAR...

If I'm not mistaken here it seems that you think that the fundamental representation is byref rather than byval and I suspect that it is by val. This is, at least potentially, another reason for AQ's prior response...

What exactly are you thinking "the limitations of a sub vi" actually are in this kind of architecture?

It's an intriguing extension of what copyright law always had been: viz, that explicit statements were needed in order for claimed infringement to be enforced after it was determined that it may have happened. It's interesting if true.

I don't believe that a forum needs to so inform particular persons. Once material is posted, unless it is specifically marked as protected in some way, it is de facto, no longer protected. If a license hold (or equivalent) of some protected code posts such code, then that person is liable for that and any subsequent non-authorized use of the code. At least that's what I understand about it.

Understood re: the BD size issue but, of course, the possibility is to simply place a sub there, of the older code and so named, so that the size of the icon for the sub isn't larger than the final code of the deployed design. It depends on the purpose of the documentation but having the ability of backtrack and compare previous incarnations without having to back up a revision or two can be helpful, esp when new versions of LV are released.

I've been using this kind of architecture in LV now for about 12 years and have found, as I have introduced the Event Structure over time, that it can pose a problem depending on how it's used. If you use the Event Structure to queue a message to execute state machines and have the actual "action" done in those state machines, if works much better. In general the Event Structure rides the UI thread and depending on what processes are called during the prior event, the UI can very definitely hang, With simple architectures it might work but my product uses over 1,600 VIs that I crafted, and then all of the calls to vi.lib, etc that I didn't craft, so it's rather large, and convoluted intentionally to hide the IP. So ShaunR is IMHO right on target with his suggestions to you.

FWIW, in general I agree with what AQ posted. If you are trying to make your code as clear as possible (for ongoing maintenance, inheritability for others, etc) then definitely run the VIs through a buddy review and document -- in some fashion -- what the buddy had to ask about. It's best IMHO to use as much graphics as possible, rather than just descriptive text, and this would include colored boxes around code sections, arrows, perhaps even a flowchart of the processes involved. It is also a best practice IMHO to include the previous attempts at resolving the requirements using the diagram disable structure. It's the single best way to document (really record for reuse and understanding) the work that was done. Of course all of this presupposes that "ease of access" by others is the primary requirement of your development process's documentation procedures. If on the other hand it is critically important to protect potentially exposed IP then it is equally important to obscure and obfuscate the code as much as possible. Hmmm perhaps someone can come up with a da Vinci like "mirror writing" or "inverse graphics" symbology....

Yes exactly the points I was going to raise as well, thanks ShauR. I would also add that essentially what you're saying is: byref is inherently "better" than byval and this is one situation that you have put forward to illustrate that point. I disagree on the priority given by many to byref esp in the LV environment and that for a number of reasons. The most important is that by val is the native "core" of LVOOP and there are a number of reasons for that are best explained, if I remember correctly, in a series of notes by AQ and perhaps the white paper as well -- for those who are interested in pursuing that. Having used FGVs for now almost 12 years, I find them a very robust way to implement, as ShaunR indicates, objects and not so much singletons, although that has become the default case for many. For years that was just about the only way to do that or anything like it that in LV. And, yes "god functions" are a problem, uh perhaps I should say, however they are instantiated. Being a class doesn't guarantee lack of god elevation. If on the other hand you want to "cast" FGVs as CBR substitutes then, yes, you'll create some interesting entanglements. But doesn't that get back to the issue (at least potentially) of prioritization of byref constructs? So as is the case with many LV constructs, if you don't like them, then don't use them. Just bear in mind that it isn't accurate to say that they are inherently dangerous or especially prone to idol worship.....

I'm wondering if you can say at least a little bit more about this comment and the general idea that FGVs "...always end up..." as god instantiations, and I gather you mean some form of pantheism or polytheism. FWIW it seems to me that it's not FGVs that are being talked about in that light; rather, it's the misuse of them based on misunderstanding how, when and why to consider using them. I agree with that comment because it does seem like overkill and over reliance on text-based descriptions rather than making use of the easy to read, multi-language accessibility of the native LV symbols. I mean what is one supposed to do: put simultaneous translations into Spanish, French, German, Hebrew, Russian, Chinese (old style and new style)....along with the presumed English language standard? Isn't LV intended to be international? Aren't the primitives much more language independent? It's not a burden to learn to navigate easily through non-text but clear diagrams. That's one of the many reasons that we use graphic representations of output data instead of just long text-based descriptions of those datasets.

I have been using TSVN for a while and have found it very helpful. Currently I need to do an export of the repo log and that export needs to take the form of an ASCII dump of rev num, date, author, comment such that I can do some re-formatting and send it off as a report. I can't find any good references about how to actually do this. Anyone have any good suggestions? Time is of the essence here. Thanks in advance, val