Val Brown

My opinion: 1984 > Animal Farm > Brave New World

I haven't read Catch-22.

Interesting, because (I believe that) all three were written in Great Britian. The human condition is universal, I guess.

Yes they were, as was Lord of the Rings and the Hobbit, to name another few popular titles. Notes From the Underground is quite stark -- but a classic -- and I think the "easy read" that really got to me recently, it would be: "The War After Armageddon".

One interesting aspect of hygiene is it is not necessarily a compounded property. In other words, it is entirely possible for me to construct a hygienic code block in G using parts that are not hygienic. I'm not yet sure how useful that is... it's another way to look at programming I'll have to think about.

And vice versa so I think this is really a question of scope or scale of definition. Seems kind of like counting dancing angels on pinheads....

Not really the modern NI template for M/S, but completely reasonable. I don't go back to LV5 so I'll presume that releasing the queue did not interrupt the dequeue/preview in those days with an error.

I've done this, and I hate dislike it. It effectively takes an event based processing node and turns it into a polling mechanism. Why have two asynchronous operators in one loop? One of them is necessarily polled to keep the loop going (either by the master to notify "run" or timed out to indicate "don't stop.) This is debatable, but I've taken to releasing the queue to destroy loops. I feel like it offers a more efficient operation. I usually toss a comment in the loop that the error is the exit condition.

Sorry I did the quote then somehow didn't quite add the comment.....maybe somebody can clean it up. I can't seem to find the edit option.

In any event, you have the history reversed -- and it IS about history. The point is that was the ONLY way to do it way back when (at least AFAIK) and so it remains in some legacy code but another reason is that one just might want to trap "error" -- even if it's because of releasing the queue -- and not exit all of the parallel loops but perform some other kind of "recovery" operation.

Definitions:

Master/slave - NI's template implementation.

Incorrect. This only works if you have ONE dequeue place. If you were to try this with multiple "slave" loops it would immediately break down. A queue (even size one) will not perform identically to a notifier.

So I'll ask my original question again:

Does anyone use the master/slave template pattern? You MUST use a notifier as the transport. You MUST have atleast 2 slave loops. You must RELY on lossy transmission (ie its a better solution than a lossless transport.) If that's not the case I won't be satisfied as it is just a different way to solve a problem that could be done using a different, better, pattern.

~Jon

I have used that exact template to terminate parallel loops. In the past -- before Event Structures (and some other tricks...) that was the only way to guarantee shut down of parallel loops that received inputs from queues as well. It's a solution that goes WAY BACK to LV5 or so...

How? I'm interested in hearing the options...

Yes so am I. That's why I said may....

Yes I guess Evil AQ can be snarky....

So again, from my perspective LV is a pure dataflow language but may be purely hygienic.

ooops I meant may NOT be purely hygienic.....

So, if I've followed ALL of this, what we come down to is:

LV is a pure dataflow language with an implementation of references that is inherently dataflow and not raw pointers.

Obvious when you "read the manual" and such but that option is TRAINED OUT by traditional CS approaches based on text-based "jump anywhere" languages that allow for raw pointers and, thereby, leave the programmer with the mess of memory management, ah, I MEANT to say: with all of the options of deciding how to manage memory everywhere still available to you, along with the responsibility for actually doing ALL of that. In other words, coming from a traditional "jump anywhere" architecture being ASSUMED, LV can seem quite "limited". Recognizing what it actually IS, LV is an inherently elegant implementation of dataflow.

Hmmmm, maybe I should ask Evil AQ about all of that......

Now that kind of skinnable, thim UI sounds very interesting. Any examples you can post?

dont agree, what if you have already passed CLAD before, however it is expired. Do you need to do it again before taking the CLD? Considering you are still active in the field and using LabVIEW everyday. I think it is just Money craving

I don't LIKE it -- being in the same situation -- but it makes perfect sense to me and, as has been pointed out, there isn't a whole lot of money involved for NI in the process. Certifying others is a very time-staff expense operation, esp to set up initially but also to maintain, let alone extend, over time.

Val Brown

I'm really surprised that you were able to use the CIN in 2010. When I open it, I get a broken error with the reason that CIN is no longer valid.

Not only in 2010, but also in 2011. I suspect that, if you had migrated the code version by version as I suggested, then you wouldn't have gotten the broken arrow but I guess it probably also does depend on the particular CIN. In any event it was good that you got ahold of the original developer(s) and they were able to resolve the issue for you.

This is very cool - both the code as last posted but also the overall process of review demonstrated in this thread.. I'm looking forward to (now) having more time (and energy) to participate in these kinds of discussions. Kudos to all involved!

This is an example , IMHO, of a unique situation that entails a purely local solution - what I would call a pipeline filter from my Unix days. The OP's original suggestions should definitely NOT be included in OpenG, but the idea of throwing an error on this condition should be.

I'm unaware of any specific, inherent limitation in either 2010 or 2011 re: the use of CINs. In fact, I have a legacy project that uses one CIN and I've had no problems at all with it in 2010 and 2011. I suspect that the problem is more connected to how you are referencing the resources needed by the CIN.

FWIW, if you can, I'd suggest migrating that CIN -- called in some test program -- through each of the intervening LV releases. Perhaps that might help resolve the problem or, at least, highlight more clearly where the error is really coming from.

Ah so what do you use then to generate them?

From my perspective, again, this would be an example of "doing it right" -- even if it involves some work now (cf Ton's comments above) it still would be the most consistent and comprehensive way to organize OpenQ. But then again I don't have years of legacy code using OpenG so I'm certainly not down in the trenches on this one.

Do you an AES key generator in native LV?

Just wanted to chime in that I support the move. It should be all at once with a bump in the version number. Given the nature of the change, does it justify a "major" version increment?

I would think most definitely.

Yes definitely it's a major release with a significant change like this -- which is being handled very well IMHO given all that you've said.

Sure, you can't see it update in this case, but is still allocated memory e.g. to give you the option to cut and paste the data etc...

Yes, but Why? I mean, I can see why FP controls that change their appearance need a copy of their data, but if the control doesn't change appearance why does the FP control need any data at all (other than type information obviously !) ? Actually that might be an interesting idea for debugging dynamic dispatch calls - if the FP controls and inducators changed appearance depending on the runtime type of object they were being passed. Then there'd be a good reason to pay for getting a copy of the data....

And I suspect -- but COULD be wrong -- that this is because iLV is "really" byval (meaning dataflow optimized) and not byref, so inplaceness counts in many, many ways...

,,,I think it would be easier for end users and OpenG developers if all packages are rolled out at once (like we did for v4.0).

I think so too, FWIW.

I'm all for doing things right..

Good, then the short answer is: yes. Doing things right from the beginning (or as soon as possible for retroactive situations) ALWAYS pays off in the long run. If not then we all ought to just be jusing shifts and FGVs, typedef clusters....

Yes, please, move it. IMHO, user.lib should be for *user* developed code, not add-ons, which is what OpenG really is.

...If OpenG were in the add-ons directory, I wouldn't have to touch it except when an actual update was available.

Precisely so. And then, if for some reason you (a user) did make a "local" modification to some underlying OpenG VI, you would put the modified code into user.lib, leaving the original OpenG untouched in vi.lib.

I'm currently trying to upload binary data from LabVIEW into a Filemaker 11 Container field via ODBC and I'm getting nowhere. I wondered if you were able to do this? I can upload non-binary fields fine.

In the past I was never able to get it to function correctly via ODBC to serve as a replacement for MS Access so I'm very interested to hear how this turns out.

This all sounds like a very good plan.

I agree. This is one of the best decisions that NI has made in re: to the LV workspace and it's one that IMHO should have already been made when those tools were originally released.

You obviously understand binary?

As do you -- so the ten of you get it and it's obvious that you're right handed when you count that many items..... :lol: