LAVA 1.0 Content

Another Massachusetts resident added to the list! Welcome Tom, and congratulations on the little one, very cute :thumbup: Also, congratulations on your assimiliation into the Borg, Bob!

I'll share my limited experience: NI has a Mathscript forum at http://forums.ni.com/ni/board?board.id=MathScript that has some qood answers about what you can and can't do. The multithreading and parallelism questions would likely be answered quickly by the Mathscript team if posted there. File I/O and UI Mathscript functions are limited or missing; you will need to use LabVIEW to source the input data and present the results. (your interest in Matlab volumetric plotting may be an issue) Again, I think you would get a good answer from the NI forum on that. (edit: This applies to runtime more than the development environment.) I was warned that Mathscript Nodes that exceed several dozen lines will not perform well. The suggestion was to break the scripts into separate nodes and wire then together.

I don't think there is space on the market for an open source copy of LabVIEW with all the same functionality. However there could be space for a graphical general purpose programming language that would be designed from a different perspective. If I would design a graphical programming language now, I would design it so that it compiles to one of existing virtual machine formats such as Java Virtual Machine (Java) or Common Language Runtime (Microsoft .NET) or multiple of them. This means that one doesn't need to provide multi platform support as such support is provided by the virtual machine runtime environment. These virtual machines also exist for many embedded environments so the hardware compatibility for the execution environment would be decent from the beginning. I would also make the graphical programming language compatible with major languages compiling to the same virtual machine environment so that one can call existing library functions from the graphical programming language and vice versa. Such a design means that one can concentrate on the design of core language features as existing library functions and widget libraries can be directly utilized. I would take advantage of the research results on programming language design, so the core language would be much more expressive and more flexible than LabVIEW. This means that once the core language functionality is ready, one can develope new features and new libraries for the language in a more powerful way that what NI needs to do with LabVIEW features. I would propably write the required interactive graphical development environment (IDE) with Eclipse Rich Client Platform. There are plenty of widgets and libraries for Eclipse RCP application development which makes the development of the IDE much faster and easier as one doesn't have to start from beginning. From the above perspective building a new graphical programming language would be much less laborous than designing a new graphical programming language from same stand points from where NI has developed LabVIEW. I think from these perspectives a group of around ten people can build something that would be a powerful graphical programming language and a development environment in a few years. The level of hardware integration that LabVIEW provides is inaccessible unless there is a real-time virtual machine that would run on a large number of different devices and to which the graphical language could be compiled.

Here ya go :2cents: , but I don't think it will help much That is actually alfa's office. If you ask me how I got the photo with the screen content, I'll have to kill you :ninja:

Absolutely beautifull little baby F

In general I am never looking forward to upgrade my OS when the one I have gives satisfaction but I read in the papers that Vista is getting close to MacOS X (which IMO is a good idea) so I'll looking over microsoft fan's shoulder when they upgrade... just in case From a professionnal viewpoint, this decision is not mine... the IT doesn't seem to be willing to push us to vista too fast, I guess anyway we would need a serious upgrade in terms of CPU, RAM, GPU, etc... + for some reason Vista's price almost doubles when crossing the ocean... WHY ?

Why not to make the copyright to fade away in a few seconds after application start similar to last zero of 8.20 fading away... Perhaps someone writer an Xcontrol that does this :-D

That text was copied verbatim from the Intermediate I Guide I mentioned (page 10-4). I tried to put it in quotes but it might not have been obvious enough. I'll try and edit that... anyway, the statement points to the License Agreement, which I assume lists the true requiments... IANAL. A quick search of the NI web site for "about box" returned this link to the 8.2 help. It has the same text I keyed in from last year's Intermediate I workbook re: placing a copyright on the front panel . The front panel requirement is not mentioned in the SLA. This is confusing... The SLA does not seem to make any differentiation between internal and commercial (resale) type use. I would guess that it's best to put it in if in doubt. Who knows what will happen to your software and hardware in the business world today... Your test equipment and software might be sold or sent off to a contract manufacturer, and you suddenly get to travel to far away places ( plus work long hours, eat too many burgers and drive smelly rental cars). Ah, the good old days...

I don't think so. I think it's more about look/feel/functionality of NI controls and indicators (charts, graphs, tables (yuck)) and such. By including NI, you are not so much giving NI rights to your code as you are protecting NI's look/feel/functionality; otherwise someone might buy your software, then duplicate the waveform chart functionality and sell it on the cheap; or maybe it would show up as a "Visual Studio for Vista" feature Also, I found my Intermediate I CD, and there was a simple About VI. I think it's OK to share this; or is it copyrighted? :headbang: Download File:post-949-1169750981.vi

Taken from the Intermediate I Successful Deployment Practices workbook: For the latest requirements, see Section 12 of the SLA at http://www.ni.com/pdf/legal/us/software_li...e_agreement.pdf Thanks for reminding me of this! :thumbup:

I contacted the project leader and expressed my interest in the project and a possible interest in also participating the project. I was initially welcomed. Then I sent a reply email to the project leader with multiple questions tyrying to determine what is the mission of the project and how they are trying to accomblish the mission. I wanted to know where they stand before I'd be ready to commit to the project in any way and there was absolutely no information about the project in the sourceforge.net project web page. I was answered that I should not ask about the feasibility of the project and I was asked not to contact them anymore. They told me they are a group of friends and the project is their free-time hobby. Apparently I won't be part of the project. However, if anybody is interested in setting up an academic or commercial research project on modern general purpose visual programming languages with me, send me a personal message jimi

I noticed that I never get it when working on VIs that are on my local drive but tt really doesn't look like a timeout error. When I open a VI, if I move a wire and save, I SOMETIMES get the generic file I/O error, and if I cancel the save and do other changes to my VI and try to save it again it can work without error... I haven't been able to find a way to reproduce the error without any doubt but on the other hand I get the error VERY often (at least 50 times a day !). Does anyone know if NI has an "official position" about this error ??

As far as I've understood LGPL also requires that the user of your application must be able to modify the LGPL part of your application and still be able to use that modified part with your application. I think it is this requirement which makes it hard to use LGPL licensed stuff in your application.

The wii video reminds me this thread on NI forum : http://forums.ni.com/ni/board/message?boar...=186214#M186214

Well... apparently NI built up a team to make up these movies... See this blog : http://viroadshow.blogspot.com/

I remember smelling marmite long ago when I was working in England, I was living with a familly with 2 little girls who couldn't imagine a lunch without Marmite, so evey morning, while I was having my salted butter toasts they were preparing Marmite-sandwiches... What a smell !! Back in France I tried to find Marmite... for fun, I wanted to put Marmite my sister's pot of Nutella :laugh: Unfortunately, it appears very hard to find such a smelly stuff in France (cheese appart of course ).

To avoid cross posting, see my answer here.

I quote i2dx from Tree Control thread to avoid cross posting. Creative Commons is not one license but rather 11 different licenses. None of these Creative Commons licenses have been certified by the Open Source Initiative as open source license. If I've understood correctly, these licenses are not GPL/LGPL compatible meaning that one cannot use components licensed under Creative Commons in any GPL/LGPL licensed project. Code licensed under the BSD license can be used in a project licensed under any combination of the five BSD, EPL, GPL, LGPL or MPL or under a proprietary or a commercial license. Code licensed under the EPL/MPL/GPL/LGPL multi icense can be used in a project licensed under any combination of the four EPL, GPL, LGPL or MPL or under a proprietary or a commercial license. Direct derivatives of the EPL/MPL/GPL/LGPL licensed work must still remain under open source license but such components can be used as part of proprietarily licensed software. jimi

No need for oopses... I saw it the first time also.

Hi, I'd like to propose addition of a new forum "Patent Watch" to the list of LAVA forums. This could be a place where LAVA users could post short descriptions of NI and LabVIEW related patents and patent applications and links to the applications themselves. This forum could work as a place for peer reviewing NI and LabVIEW related patents and patent applications. The forum would also function as a way to get information about new forthcoming LabVIEW features. What do you think? Would you be interested in such a new forum? jimi

I like this new software quality certification...

No it doesn't. It doesn't have the option of EPL/GPL/LGPL/MPL multi-license (all of them together on one line). In addition code repository has the option of selecting LGLP alone which I think should not be used as a license option for LabVIEW code but only as a member of multi-license so that LGPL projects could use the submitted code.

Yes :thumbup:

Sounds good! A few comments: The VIs should not be read-only, LabVIEW needs to be able to recompile the VIs when you upgrade to newer version of LabVIEW and occasionally when there is something weird going on in your project. Ability to add custom icons would be super! The LGPL license is viral in LabVIEW, meaning that if I use your library in my application it forces my application to ship under LGPL license. Could you consider licensing your package under EPL/MLP/GPL/LGPL multi-license. See thread Open Source Licensing of LabVIEW Packages for more information. jimi

Hi, I'd like to raise a question about licensing LabVIEW open source packages. Open source community conventionally uses GNU Lesser General Public License (LGPL) or BSD license to license libraries. Applications are conventionally licensed under GNU General Public License (GPL) or BSD license. GPL is a viral license. If you use GPL licensed components in your software, you software must be licensed under GPL as well. LGPL is intended to be less viral; if you use an LGPL library in your application, your application can still ship under any license. However if you modify the library itself, you must ship the modified library under LGPL. There is an additional restriction is LGPL that an application that uses a library licensed under LGPL must allow user to dynamically upgrade the library to a newer version of the library. BSD is less restrictive, works based on BSD licensed material may be released under a proprietary license. In LabVIEW libraries LGPL becomes as viral and as restrictive as GPL because LabVIEW doesn't have the concept of dynamic link libraries and users cannot therefore dynamically upgrade the library to a newer version. So if one uses a LabVIEW library under GPL license in a LabVIEW application it forces the application to be shipped under LGPL license. So LGPL contamines any LabVIEW application or package that uses the any material under LGPL. Therefore I strongly recommend that nobody uses LGPL in any LabVIEW open source material. Having read trough a number of different open source licenses, I think that Eclipse Public License (EPL) is a very good license for open source LabVIEW libraries and packages. It allows applications using libraries licensed under EPL to ship with proprietary license. The downside of EPL is that it's not compatible GPL/LGPL so if a GPL/LGPL compatibility is wanted, then multi-licensing similar to what Mozilla foundation uses is needed. Mozilla uses MPL/GPL/LGPL tri-licensing (MPL stands for Mozilla Public License). Recommendations To conclude I give the following recommendations for the open source developers of the LabVIEW community. If you don't require that modifications to your library always must ship under open source license, then use BSD license. Many OpenG packages currently ship under BSD license. If you require that any modifications to your library ship under open source license, then use EPL/GPL/LGPL/MPL multi license meaning that the user of the package may select any combination of the four licenses. EDIT: If the LAVA community agrees with these recommendations, could we add these recommendations to the instructions of the code repository. If someone tries to submit a library to code repository under a license other than BSD-style license or the above mentioned multi license, I think the LAVA admin accepting the code should send a personal message suggesting (but not requiring) change of licensing scheme. It would be even easier if there would be a pull-down menu in the code repository submission form where one could select either 1) BSD license or 2) EPL/GPL/LGPL/MPL multi license or 3) Other, specify.