Val Brown

The VIs are recompiled by 2011 and that is why they need to be reverted separately instead of just being opened in 2010.

And exactly what is the download link?

....just joking. Thanks for the link. I've been waiting for it.

...so they're a good target for your lobbying efforts.

They'll be the ones with targets painted on the back of their t-shirts......

I knew it!

Mais ce n'est pas the case pour tout le monde ici. Certains d'entre nous sont juste un peu hors de la practique.

即使是位中國

Did I miss the announcement as to when this will happen and how to do a download?

Brief diversion...

Do you mind if I ask what environment you work in that requires you to obfuscate your code?

Yes, you can ask, of course.

I'm a single developer, having founded my own company with my partner -- who is my wife -- and we have developed and distribute a completely unique application that has required not only specialized knowledge in order to be developed, but specialized knowledge across a number of domains. Aside from the You can check out our website for further info and i'm happy to discuss it further here as well: www.zengar.com.

Competitors have already tried to claim that their product does what our does -- and failed -- but several have mounted concerted effrorts to reverse engineer our code -- and failed.

I'm not a developer for hire and I doubt that I ever will do that. If I did -- esp if I headed up a large multi-person team -- then there would be different concerns that would drive this bus. But in our situation, security of the code is critically important. Obfuscation and such are fundamental components of insuring that our code, ideas and unique application remain ours alone.

With the supposed performance issue not being demonstratable under typical worst case scenarios I have kind of lost my one big CON to throw against it. so it might just have to be a lot of smaller CONs now which will support my/our bias against the architecture.

Yes this was essentially the point I was making in my initial reply. There may be many reasons to not prefer -- or even use -- this architecture but claiming that there are objective measures supporting that -- when there aren't -- is a bit of problem.

Val, being harder to follow the code is definitely a CON as it needs to be easy for beginners to understand and anybody to maintain. I gather that the main reason it is hard to follow if the use of Global Variables which aren't strictly necessary to use for this architecture.

Not in my case in fact, it specifically is essentially a requirement that no "beginner" can come in and understand my proprietary code. It is one of the few real safeguards I have available to me. And the obfuscation has nothing to do with Global Variables, which I simply do NOT use (even though there are use cases in which they are serviceable). Global assertions (eg "X is NEVER a good idea") are just another application of Global Variables and generally carry with them all of the attendant sorts of issues such references bring...

"Action Engine" is another term for a Functional Global Variable or FGV.

Every thing is a problem in some context and everything is also a resource in another. The "difficulty in maintaining" such code can be an advantage when you are trying to make it as difficult as possible for someone to reverse engineer your code -- and that has always been a critical consideration for me. Now, I'm saying that support or oppose the use of the specific pattern being discussed. But I am emphasizing that it may be accurate to say that it is "objectively" problematic.

I do understand what you're saying but, if you're looking for objective measure to validate your BIAS, and the objective data does NOT support your BIAS, then is it possible that this is just a BIAS?

Now don't get me wrong. I'm not saying that there are reasons to prefer the other approaches but to claim that there are objective measure to validate your preference -- when there apparently aren't -- puts you in a far, far weaker position.

What are the real reasons you oppose that approach? You may have already posted your thinking and I missed it but, if you're looking for objective validation, I think you may be out of luck.

"...I had hoped it would be more down in the hundreds of Hz (i.e. a total of hundreds of state changes per second across the entire application) which is more of a realistic use case for a large application"

DId you really HOPE for a lower rate choking the UI thread or was it the assumption that a lower rate WOULD choke the UI thread that originally drove your concerns about the alternative architecture? Maybe I'm missing something here but this sounds like a good outcome for most LV users.

Norm,

FWIW, I'd like to hear about this as well as (kudos to JKI for all the wonderful work, truly!) I really don't want to have to deal with OpenG or VIPM, if it's possible; and I really liked what I heard during NI Week.

Have a great vacation! And I hope to see you i Austin again this year.

val

So did I miss all the details about when, and where...I do know who.

I maybe wrong about this but I think part of the challenge may be that you're using LV2009 sp1 and not 2010 sp1. I had several build related pbs (no pb with pb btw) in 2009 that were related to porting code that had its origins way back in 5(!) but which has been updated through each subsequent release. In the end the shift to 2010 sp1 finally resolved the problems but it was a real challenge to sort out because the "errors" weren't actually errors in 8.6. The became errors in 2009 because -- IMHO -- non one at NI thought to test legacy project builds to detect the kinds of errors that could pop-up. And, no I don't use classes, DVRs or anything really "exotic". Still pretty much old school LV.

Actually multi-developer projects work quite well with LabVIEW -- graphical IDE only -- as does version control. It just seems like your company is rather text-based in its orientation. And FWIW I seriously doubt that there will ever be a competitor to LabVIEW that has all of its functionality AND adds in a text-based version. It's taken over 20 years to get LV to the state it's in and, as you've seen, there's really no incentive or good reason for a text-based version to be developed by NI. I simply don't see it happening that any other company would invest the requisite person-hours to develop what NI has done.

Again FWIW my suggestion would be to ask others how they manage multi-developer, multi-site projects and specifically how requirements and validation processes are handled. There is a real wealth of experience and knowledge here.

Electrical circuit design can use either schematic or HDL. They are equivalent representations of the same thing. The designer can choose the best solution. Why does G have to be graphical only?

I guess I'm wondering why you want to use a text-based representation instead of the graphical IDE of LabVIEW?

In Fusion use Preferences/Keyboard and Mouse to set the shortcuts how you like. You might also want to use Fusion/Preferences/General and Gaming: Auto-Detec mouse for games.

I think the bottom line is that this is a question of perspective. Yes, in the end (or is it the beginning?) ALL computer operations are based on polling, and can't not be.

I don't agree. Like most CPUs, 80x86 chips have interrupt handlers, which relieves the CPU of any need to poll the I/O input. If the interrupt line does not change state, none of the instructions cascading from that I/O change are ever executed. The ability to execute those instructions based on a hardware signal is built into the CPU instruction set. I guess you could call that "hardware polling", but it doesn't consume any of the CPU time, which is what we are trying to conserve when we try not to use software polling.

You make my point: it IS polling but your perspective is that, if the polling doesn't consume CPU time then it doesn't "count" as polling. For me it's far simpler: it IS polling. And the real issue here - again - is one of perspective: viz, where do you stand when you look at these phenomena and what "counts" of doesn't. But in the end it is fundamentally polling of SOMETHING, SOMEWHERE and can't not be.

I think the bottom line is that this is a question of perspective. Yes, in the end (or is it the beginning?) ALL computer operations are based on polling, and can't not be. But from the perspective of certain "levels" of abstraction, it appears that real "events" are happening without ANY polling. It just depends on which perspective you want to adopt for the purpose of the discussion. It's kind of like discussing the differences and similarities of absolute and relative boddhicitta but, then again, I also have a background in philosophy, both Western and Eastern.

They definitely "get" that the VI was skipped and then, presumably use default values or previously stored values if they include something like FGV code.

What do you think should happen instead?

How do you not see that as dataflow? I'm a bit confused.

....

Sour grapes? Yeah, probably a bit. Disillusioned with the certification process? Oh yeah. Disappointed that I won't be able to attend the architectural summit next year? Definitely. That's been my entire motivation for pursuing certification. Oh well, life goes on...

I am sorry that you didn't pass. I do agree that, for me, the primary (if not ONLY) motivation for pursuing CLA would be to attend the conference. But yes life goes on and I'm sure that, if you want to, you will pass at a later point. For me, I doubt that I will pursue that. At this point I'd far rather put my "extra" time into golf but, then again, I am in a rather unique situation. And I am sure that for most LV users -- esp developer/consultants -- the CLA is definitely worthwhile.

And, um, Darren I'm glad to see that your comment means that some form of "undo after Save" is coming, hmmmm, sometime around NI Wekk 2001 I guess. Nice!

SVN will allow a local repo as well.