Jump to content

Val Brown

Members
  • Posts

    754
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by Val Brown

  1. 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...
  2. Yes so am I. That's why I said may....
  3. 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.....
  4. 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......
  5. Now that kind of skinnable, thim UI sounds very interesting. Any examples you can post?
  6. 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.
  7. 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.
  8. 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.
  9. Ah so what do you use then to generate them?
  10. Do you an AES key generator in native LV?
  11. 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...
  12. 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.
  13. 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.
  14. 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:
  15. Definitely. And no matter what else, do NOT keep it under THAT hat. Sartorial Splendor just brimming over.
  16. My point exactly -- and why have to keep ALL of that detail in your head? If you're developing code for others all day long then, that could be a time saver, of course, but you then have to keep a lot of details in your head. Yes, that's probably true. And they might even have been WordStar fans...... Seriously though, it's a brilliant tool Darren it just doesn't (yet??) fit into the way that I work but, thinking about the cert exams.....hmmmm.
  17. Yes, this is an aspect of the kinds of confusion raised by thinking this is "wrong" behavior and should be "handled in the background" by the structure itself instead of explicit programming actions on the part of the programmer.
  18. FWIW I'm with you on that because I prefer to use the pallets. It's a consistent interface and I don't need to keep a lot of stuff in my head. Why do that when the resource is right there, just a click or so away? But that's me. I also only use a track pad -- never a mouse.
  19. Posted Today, 02:41 PM Val Brown, on 09 August 2011 - 03:26 AM, said: An event is an event and, while each event will have a timestamp, none are polled but all are received -- regardless of the action taken by the structure. Exactly! Val Brown, on 09 August 2011 - 03:26 AM, said: An unregistered event is STILL an event -- and can't NOT be an event. I agree with that, as long as I can change it to: Val Brown misquoted by crelf said: (Hey! I did NOT say that the damn IDE did) An unhandled event is STILL an event -- and can't NOT be an event. My comments begin here: I think what you might mean -- to be precisely accurate linguistically -- is that an event is STILL an event -- and can't not be an event. AND a REGISTERED event is not JUST an event. It is an event that has an additional component (viz the "registration") and should, therefore, expect some additional response, such as to be received by some event handler in a way that doesn't just get "lost in cyber hell" if the programmer falls asleep at the wheel. Yes, I understand that argument and it's the basis for a great architectural discussion -- one that already happened about 30 years ago in some circles, but that's another story for another time (if you're not already yawning....). Now regardless of that history, it is exactly that extension that I object to -- because an event is an event. Even registering an event shouldn't have an influence on the event per se, nor it's overall construct unless it's an object and being an object becomes an intrinsic attribute of an event; or else the default IDE behavior should be to populate a case SOMEWHERE that explicitly receives that (now) registered event and forces an error if not explicitly handled by the programmer. Now the argument could be made that the event handler could have some other facility for handling registering events that do not have an explicitly declared interface; and essentially that is what is being argued here by those saying "isn't this a bug?". And perhaps that is an attribute that even should be integral to a well designed IDE but I'm not so sure about that -- at the conceptual level. And, yes, all of these various ideas would make life easier in some ways. So, in the end, it's frequently expediency that prevails.I just think that the philosophical issue -- history aside -- remains important, regardless of how it is answered in a particular IDE like LV. OK, back off the soap box and time for more beer...ah actually single malt. FWIW as a user I say: NI make it easy for us. At another level though I think these various changes are a problem waiting to happen down the line because they break (OK bend) the purity of the IDE at the abstract level.
  20. The hot flow to where no one has gone before.... Slogan the Next Generation (and gender neutral)
  21. The deeper we go, the better it gets...
  22. Venting the frustrations and hopes of all users....
  23. These shouldn't remain unregistered but acted upon....definitively!
  24. I'm coming to this discussion after NI Week and having listened to the topic reverberating off the walls post Stephen's session. FWIW, I think those who think this is a bug or "should be changed anyway" are confusing the concept of timeout with the concept of "Default (Case)". Timing out the Event structure is not a guaranteed method to "catch" any and all unspecified events and why should it be, esp if a timeout is given to constrain it. An event is an event and, while each event will have a timestamp, none are polled but all are received -- regardless of the action taken by the structure. It's up to the programmer to "clean up the mess" he/she creates in registering the event. An unregistered event is STILL an event -- and can't NOT be an event. It's just not a very wisely programmed event: like an uncaught setjmp() back in the REALLY old days always "set your gets before you get sets into your code".... Ok so that's just two cents worth from a non CLA who is, in many ways, really old school so this is text and not in cool graphics.
  25. I understand that point, however, IMO this wasn't a "bug fix". There are new features, and several are really outstanding. There are speed improvements (most notably for FPGA but nonetheless elsewhere as well), and functional extensions re: how the Project works to support builds, etc. As I say, one can always find things to complain about but FWIW I'm very happy. Then again a lot of people in the NI community do see me as being just a bit odd. In any event, now it's time for maybe or .....
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.