Val Brown

QUOTE (Ton @ Sep 7 2008, 11:05 PM) I think you might be meaning to say "Not Invented Here or by NI".

QUOTE (PaulG. @ Sep 3 2008, 11:02 AM) Re: your above post -- do you mean that you upgraded to 8.5.1 and that didn't make any difference?

QUOTE (hfettig @ Sep 3 2008, 04:28 AM) I also agree that it would be a great feature to add to LV. Has this been submitted directly to LV? I know that SOMEONE (or several someones) here on LAVA just might work for NI and could see that the suggestion goes to the right place, but I also think someone posted a link FOR that "right place" that the rest of us could use for just this purpose. Anybody know what that link was?

QUOTE (Omar Mussa @ Sep 2 2008, 09:17 AM) Thanks for making that clarification re: licensing and FWIW I think that's a great way to do it.

QUOTE (Ton @ Sep 1 2008, 11:59 AM) I think all of these ideas are right on target. I also like the idea of extending the graphical nature of the Project by allowing for icons for items. A conditional build/edit build feature would be nice: eg if the build breaks, open up the "offending" VI, dependancy or whatever (even dynamically called VIs) pointing to the "problem" much like happens when searching the items in Error View.

QUOTE (jlokanis @ Aug 31 2008, 03:46 PM) Yes, it is but it's a wrapper that's being maintained by a company, not just "some folks" who might, or might not, get around to it when something happens, and goes wrong. I'm much more interested in reliability and maintainability than speed -- for THAT part of what I do -- as I've got those functions all arranged to happen "off line" in non-time critical ways. I don't remember off the top how it was resolved. I really have to look back over my archived code to find out how because what I remember is that I submitted the SR, interacted with the AE, got workarounds/solutions and applied them. It was a while ago at this point and I just no longer keep all of those details in my head any longer. Whatever the workaround/solution was, I no longer had the problems with variants with the DCT.

QUOTE (Yair @ Aug 30 2008, 11:39 AM) I guess I'm still a bit confused about what you're saying. What I understood from you was that you prefer open source because you "can fix it yourself" as opposed to relying on NI and that you were reporting on experiences that you knew about where others -- or you?? -- had encountered problems that NI couldn't resolve and, therefore, you prefer open source. That doesn't make much sense to me as, unless it's a primitive (which is uneditable for everyone), you can always "fix it yourself" in LV or ask others in the community for what they've done to fix, work around, etc whatever you encounter. In any event, in the end, we're all dependent on what NI provides -- certainly in the case of primitives -- and the rest we can always "fix" or adapt ourselves if it's in a VI. If it's a primitive (not something that can be edited directly in LV) then we're all equally "stuck" with whatever NI does regardless of our commitments to open source. If it's anything else, we can modify it, again whether we're committed to open source or not. After all, there was a time when there wasn't a three button dialog and even now that there is one, there's a thread here using that for a coding challenge to improve it. Before the NI version came out I found it a real nightmare to use the third party workarounds that I found. Each was different and didn't play well with the others. At least with the NI version we now have a shared version that is "official" and standard. Having been through the early Unix and C wars (never mind Pascal, etc), I really don't want to have to continue to play the "keep up with all the versions" game. I do understand that for others that's a perfectly wonderful way to go and the VIPM package in particular seems like a great platform for just that purpose. For me, it's overkill and itself another interface that I would have to learn and maintain. So my perspective may very well be unique here but I do think it's valid, at least for me and perhaps others in my situation. Yes, I had the exact same problem with variants and the DCT, while moving some of my code through the transition to 8x.

QUOTE (Yair @ Aug 29 2008, 04:44 AM) M experience has been precisely the opposite of you, and certainly so in re: to the DB Toolkit. Working with an AE (I'm on platinum support) we resolved the issue. I addressed it again with the advent of 8.5 and issue with Vista. With some third party tools I was told by the developer, essentially "what you see is what you get". I don't use captions so I have no experience with them. Yes, the release schedules NOW are pretty predictable -- I've been using LV since v4x so that has improved over the years -- but the support has been and continues to be good and, ultimately, definitive. My experience with open source groups -- of various products -- has been far, far less supportive. I know that's probably blasphemous here but that's how it is. QUOTE (jed @ Aug 29 2008, 09:40 AM) Did anyone else get hit a few years ago when the installation of VISA overwrote the serial setup VI that came with the base package? It killed a TON of my code... Yes, I did AND I got the workaround from an AE, which has been working in my code since then. It STILL works with 8.6 even though I had thought it was "killed" with an earlier 8x release. I've now, finally, moved on to replace that code but not because it doesn't work -- it STILL works, just as it was written for LV 5x. I've replaced it because I know have some new drivers for some older devices (came from the manufacturer of those devices) so it was time to move on. BTW, I believe that the fix to maintain the legacy serial i/o functions is described in a thread here on LAVA, if that info would be useful at this time.

QUOTE (Jim Kring @ Aug 28 2008, 07:34 PM) Hi Jim, Perhaps I should clarify a bit more what I mean by "native LV". Yes, I use VIs but I use VIs -- as far as possible -- that either I have created or that come for NI directly in their official releases. This way I know that, if there is some problem at some point with a VI no longer working as expected, NI will address it. So I use the Database Connectivity Toolkit instead of just using ADO/DAO or LabSQL, etc because I know, if the functionality isn't there with an update of LV or for whatever reason, it will be addressed. In the past I've made use of several "suites" that were made available by others -- some open source some not -- and then there was a problem when LV updates and the suite from a third party wasn't updated, etc. I'm still working with zlib and the blowfish implementation of encrypt/decrypt because, at that time, it was the most accessible tool available; however, now it's a bit of an albatross. I'd like to get rid of it but probably won't do much about it until after my current pending distro release. val I should also add that I've been a bit put-off in the past by all of the confusion around copyright and such as it applies to different third party and/or open source products. Since I distribute a built EXE to end users and I want to be consistent, clear and legal in my use of various tools, it's been a bit challenging to figure out how to include ALL of the various different, and sometimes conflicting, copyright notices needed if using 3rd party additions.

QUOTE (jlokanis @ Aug 28 2008, 06:25 PM) OK, thanks for the clarification. I'll look at it now. I don't use OpenG -- NOT because I don't think it's good. As I've said elsewhere, it's a wonderful set of tools which I have also recommended to others. It's just that, in my environment, I need to stay with as much native LV as possible. val

QUOTE (Omar Mussa @ Aug 28 2008, 03:32 PM) No, actually I meant the Code Repository example from the top of this thread: viz, DEMO_XML_File_Read.zip ( 136.39K ) Does that "it" use an OpenG or is it only native LV?

QUOTE (jlokanis @ Aug 25 2008, 04:05 PM) Does this make use of any OpenG code or is it all native LV?

QUOTE (TobyD @ Aug 27 2008, 04:16 PM) I disable it and wire through Error in and Error out clusters manually.

QUOTE (Darren @ Aug 27 2008, 11:37 AM) OK, now that sounds useful.

QUOTE (rolfk @ Aug 25 2008, 11:42 PM) Precisely. Fusion is getting pretty good but it still has some limitations when it comes to i/o and drivers.

QUOTE (rolfk @ Aug 25 2008, 11:30 PM) Yes, I would agree with this. I haven't investigated v8.6 but there were considerable problems with early release versions of 8 that I did try. And, yes, the biggest problem were i/o and driver related.

QUOTE (Norm Kirchner @ Aug 25 2008, 12:50 PM) Yes, I understand that, however, he's also a Mac user and wants to have all of the same functionality in the Mac version as in the Windows version (and yes the other platforms as well). At this point, I'm not holding my breath. :headbang:

QUOTE (Yair @ Aug 25 2008, 10:41 AM) It is my understanding as well FWIW that NI stopped the reference to "G" because of copyright infringement concerns, however those were generated/recognized within NI.

QUOTE (Ton @ Aug 23 2008, 01:06 AM) Hence, it's a "warning" about something potentially not being 100% in alignment with the overall code or purpose of the code.

QUOTE (jcarmody @ Aug 23 2008, 02:43 AM) Yes, that's clear. And at the risk of further inflaming the discussion, these kinds of issues are really "religious identity" issues. They are never decided based on rational inquiry but on the basis of the lived commitments of those who engage in the discussions/arguments. Those who grew up in the "house of holy text-based" programming will continue to see that kind of programming environment as what's "real and true" and will validate the rest of their experience based on that history. Seen from that perspective it is almost inevitable that LV will be seen as being a "toy", only good for "tests and measurements", only good for "laboratories" or whatever other rationalization can be "hung on" the LV IDE. The ability to integrate virtually any other text-based language, the ability to code in a consistent manner across deployed environments, the ability to not HAVE TO acquire numerous third party libraries to "link in", etc, etc will all be dismissed, if they are even acknowledged. Add in the fact of how easy it is for someone to actually program in LV -- esp those who have NO background in CS -- and you've got all the ingredients for a "religious war" over who is the "real" programmer" and what is a "real" programming language. Yes, I agree that from a pure CS perspective, LV is not a complete language. G is not entirely written in G, etc. Yes, of course, those are valid points and perhaps at some point in the future that will change. NI will choose to devote the considerable resources it would take to implement ALL of G/LV in G itself. But, even if that were to happen, it would make NO difference to the religious identity issue. If anything, it would only serve to intensify it because it would take away one of the seemingly "rational" reasons to say that LV isn't "complete". Yes, NI could potentially make a difference by renaming the language but that's just another version of the same identity issue. BASIC never was "basic" -- it never way "All Purpose". It had limitations and, when it become "Visual" it was still not "All Purpose". Now people refer to it as VB and don't even consider those nuances -- esp those who "grew up" in that environment and are now committed to it simply by virtue of their lived history of use of it. LabVIEW could simply become known as "LV" (perhaps for "Less Verbiage"??) but those renaming issues STILL won't address the core issue. It's all about what programmers "grew up" with and what they were educated to believe that "real" programmers do, and what a "real" programming language is. LV subverts most of that and does it in a way that allows non-CSers to literally "compete" with the end products produced by CSers. That's the final and fundamental aspect of the "religious identity" issue. LV by its very nature, ease of use, and general abilities, seems to "take away" and/or "diminish" the uniqueness of having a CS background. It isn't arcane but intuitive -- unless you've been taught to believe that malloc() etc is "intuitive". It's easy to use -- I taught my 8 year old to program in it and she could produce -- back then -- running programs after very simple instruction. And all of that makes LV appear to be a serious threat to those who have lived commitments to their hard earned identities as "real text-based programmers". OK, end of rant and now it's time for me to step of that soapbox...

QUOTE (Tom Bress @ Aug 21 2008, 08:46 AM) I favor this approach as well. In prior versions (LV 5 maybe 6) there were rumors of extra overhead when using this kind of process instead of sequence structures but I don't think the overhead of a sub-vi call is an issue any longer.

QUOTE (Ton @ Aug 19 2008, 10:14 AM) That would be phenomenally helpful to get this started.

QUOTE (Neville D @ Aug 19 2008, 10:30 AM) Thanks for posting that. I think it's clearest to actually provide the specific response/answer when it's known.

QUOTE (Omar Mussa @ Aug 19 2008, 08:23 AM) Thanks for all of the tips. I'm wondering about whether it would be useful to have a SVN forum on LAVA? A lot of LAVA members seem to use it and, one "gateway" for info about SVN might be a real encouragement and support to those of us who have yet "jumped in" or who have and hit their head on the bottom of the pool.

QUOTE (Neville D @ Aug 19 2008, 08:11 AM) And that key would be?