jgcode

I did however realize that the red X on the property node vi was because I had made it a private function.

Cool, yep, its meant to do that.

I will try it without compiling, but will probably do it tonight.

Cool, I will try to fire up 2011 later on and check too.

Thanks for your feedback Jim

- Each VI could clearly state which package it belongs to and how it is licensed (e.g. "This VI is a member of the OpenG Array Tools 4.1 package and is licensed under the BSD license. Please see the VI description and VI Package description for more information."). This gives the average user some kind of breadcrumb that they can use to figure out the license details.

Would it have to include the version? I know that would be good but it would require updating every VI in every release.

If it was just "OpenG Array Tools" as a Tag that would be better?

- It's helpful to have the VI name in the license agreement somewhere, to give the user an indication of where the VI came from, if it's name is changed in order to make a derivative work. For example, sometimes I'll rename an OpenG VI and make some tweaks to it. It's helpful to be able to see the original VI name and version information, so that if I want to contribute my changes back into OpenG (or pull new changes from OpenG into my derivative work), then I can.

Do you think this is something that the developer editing the VI can document and maintain when they make changes to the VI?

Cheers

-JG

"The front panel window must include a National Instruments copyright notice. "

That must be a joke. How many of you do that? I could always find a place for it in an about window (although I do not see what NI should be doing there in our app regardless of the fact that it was developed in LV), but on the front panel in one of our commercial apps, no way.

No, the context of the quote is an 'About Screen' or similar (check the link).

I know that CC is often used by photographs (Flickr give an easy way to add any CC contract to your pictures). Could it be used for software, I don't know. Anyway they've done a great job to help to understand what you can do or not. in addition to the 3 layer approach, they have translate text in a lot of different langages and it's really helpful to avoid misunderstanding

Yes I am unsure if it is meant to be used or is used on software too?

I have been exposed to it through web-based design etc... and I know its used for assets (e.g. images as you mentioned).

I have read CC support the new-BSD etc.. for software, so this still leaves me confused.

I have seen it pop up with respect to LabVIEW, if you check out Jack Dunaway's CognoscentUI (I highly recommend checking it out regardless) you will see the CC BY used (under the Disclaimer section at the bottom of the thread).

If there is language benefits there are well, then we should discuss more.

Can anyone else comment on CC license with respect to LabVIEW?

Today, I will be discussing a few features of this Team LAVA initiative and demonstrating using a VIPM package that has already been released on the LVTN and published through LAVA. Yes! Of course we tested the process before releasing it to the Community!...

View the full article

I am going to go ahead and lock this topic.

I am leaning towards jaegen regarding the excessive use of strings (e.g. use non-contiguous memory allocations) on RT and whether it is an issue.

However, if anyone in the future thinks otherwise, and wants to post, please do and we can also integrate the code

I am really impressed by the outcome of this process.

I think the community has put together a very nice piece of code:

This VI will be in the upcoming String Package release.

Also look out for the next review!

Thank you very much for taking part.

Cheers

-JG

I agree with the simplification trend.

Perhaps it would be nice to add examples about how to reference Openg in an application and in a toolkit ?

These examples would be much more comprehensive than "legal" text contain in Software License Agreement. A link could be displayed at the end of the OpenG package installation ?

Olivier

Thanks for your reply Olivier.

If abstracting the process helps others understand it than I am all for it - so that is something we can definitely look at.

It is something the Creative Commons license do with their Three Layer approach.

They have three layers so you see this and can understand it without having to digest this - although it's there to cover the legal side (the third layer is machine readable for search engines).

Recompiling in 2011 worked. The only vi with a Red X now is the property node which is a broken vi because I don't have the class going into it(setup for place vi contents).

That's cool.

Did you test just opening the <LabVIEW 2011 code in LabVIEW 2011 without compiling in LabVIEW 2011 first?

What was the result?

Cheers

-JG

Copyright, trademarks - all this legal stuff gets tricky! Here is a documented experience from a LabVIEW development company that had to change their brand names due to a conflict. Licenses can get complicated too. Did you know that any application you create in LabVIEW requires a copyright notice regarding NI?

Note The front panel window must include a National Instruments copyright notice. Refer to the National Instruments Software License Agreement located on the LabVIEW DVD or CD for more information about the requirements for any About dialog box you create for a LabVIEW application

Essentially I want to make it easier for users and to lessen confusion (if any) when using OpenG. So, I want to start by talking about the OpenG licenses. There has been some questions raised about how to license applications that make use of OpenG libraries (e.g. here). See here for an example of referencing OpenG in an application.

I started to review the OpenG license and other licenses and see if we can do anything better or to make it easier for developers? Please join me in discussing this with any feedback, comments and improvements you may have. As it stands, we use the newBSD license aka the BSD-3-Clause license. Which is really good as is supported by the Open Source Initiative unlike the Original-BSD aka the BSD-4-Clause license. I have been looking at the Simplified-BSD aka the BSD-2-Clause license (which is also supported by the Open Source Initiative) and even Creative Common licenses.

I think the newBSD is a good choice - what do you think?

My next question is can the copyright in the license of the VI simply reference OpenG. By that I mean does each author have to appear in the license of each VI? This is by no means wishing to offend any authors, but this would simplify the copyright documentation. This would increase maintainability for the OpenG developer.

And it would also standardise it. For example if there was a change to the license type in the future, you could not simply cut and paste a new one as each VI has different authors, so each license is different. We could still manage authors at the package level. And we could add authors to the VI Description. This would increase visibility because the LabVIEW Context Help would show that information.

If a change as the above was ok, then referencing the use of OpenG in an application would be pretty simple too. If you add new VIs, remove VIs and authors change over the course of the project or releases, that copyright would not change - exactly the same as referencing National Instruments. This would increase maintainability for the End User.

I am thinking that just referencing OpenG won't fly for the authors though (and fair enough) so I will also propose that the license is standardized to reference OpenG and we separate authors out into the VI Description under a Tag which would become searchable (more on that later) then I will create a tool that parses that information and outputs it to a text file and have an API where that file can be read in and the End User can then format the information in any way they wish to to include it in their license file.

As an OpenG Developer this tool would help keep the new Package License Files up to date as well (this feature was introduced into VIPM 2010).

I came up on this idea on my own, but Google has proved that someone else has thought of it, but no one has implemented it. The only other place I have seen Tags used is in Quick Drop (have I mentioned I love Quick Drop?) anyways we can analyse that implementation but I would like OpenG to define the standard for Tags in the VI Properties because I see this is also handy, not only for OpenG code but any re-use code used in an application, now or in the future, that an End User wants to reference in their application. Just run a tool (script) over the code and information is output to a file.

As per moving the Authors to the VI Description, I also propose that the Name and Description is removed from the license as it is redundant information and means extra maintainability/work. I also propose that the license is moved to the BD to preserve FP space, and use a window of set size (to standardise it) and add the following notice (or similar) on the FP (bottom left hand corner).

The current license would change from this...

Get Data Name.vi

 

Returns the name of the data wired on input.

 

Please visit http://www.OpenG.org to learn about the Open Source LabVIEW software movement.

 

NOTICE -- YOU MUST LEAVE THIS NOTICE IN PLACE.  PER THE TERMS OF THE LICENSE BELOW, YOU MAY SUBLICENSE THIS SOFTWARE IN ANY WAY THAT DOES NOT CONFLICT WITH THIS LICENSE.

 

### BSD License (http://www.opensource.org/licenses/bsd-license.php) Begin ###

 

Copyright (c) 2002, Jean-Pierre Drolet <drolet_jp@hotmail.com>

Copyright (c) 2002-2006, Jim Kring <jim@jimkring.com>

 

All rights reserved.

 

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

 

    * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

    * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

    * Neither the name of SciWare, James Kring, Inc., nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

 

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

 

### BSD License End ###[/Code]

...to this:

[size=4][b]Thoughts?[/b][/size]

[size=4]Cheers[/size]

[size=4]-JG[/size]

Team LAVA officially welcomes UI Tools to the mix!

Top LAVA-CR author François Normandin (aka the man in the kilt) who has a total of 16,951 file downloads, and counting, will be releasing his awesome UI Tools...

View the full article

The child constructor may or may not (often not) have the same creation requirements on the parent class data fields.

That's cool. Oppositely, I find it handy most of the time as the constructor has data inputs for parent data that I just wire in when calling it in the child.

I am going to check this out more (since I report the original issue and filed the CAR).

(Just thinking out aloud)... ...@mje, I know your code is installed in LV 2011 - but is your code compiled in LV 2011 in the images above?

Cheers

-JG

I am sure AQ has commented on this before?

If not he has now

Thanks AQ for clearing that up.

Hey, JG,

yep, i've searched through the examples. I didn't find any one using Counter Write NSamp.

I am just taking a stab (from memory - it has been a while) but have you tried to setup the Write VI before the Start VI?

I.e. put data into the buffer that it uses as output before you start the task.

Then you monitor the Task to see if it has finished (or something similar).

Cheers

-JG

The LabVIEW Tools Network (LVTN) is really cool. It’s kinda like the App Store but for LabVIEW. So, what does publishing to the LVTN mean? Well as a Developer it means:

End users can easily find, browse, buy and download your code all in the one spot on NI's website or through using the...

View the full article

It was fixed? I still get them on several of my palettes.

Well that's what it says...

Hi deepsilence

Have you had a look through any of the example VIs that ship with LabVIEW?

Cheers

-JG

Yes, I have seen it before - you can read more about this issue here, here and here.

The CAR was #185059 and was fixed in LabVIEW 2011.

Cheers

-JG

I found this link here?

...Every bit counts ...lol

What about using the Inline functionality?

Hi Claude

Thanks for the feedback.

Unfortunately, the OpenG codebase is in LabVIEW 2009.

Inlining was not exposed until LabVIEW 2010.

This is something we could discuss when we upgrade in the future, except for in this case the Execution Priority would be ignored, and that is responsible for the speed enhancements (along with some brilliant coding from the LAVA guys)!

Cheers

-JG

Dear LAVA Community

Today I am very excited to announce a new initiative starting on LAVA. LAVA has created a publishing avenue for LAVA developers on the LabVIEW Tools Network (LVTN).

During concept development the code name of this project was Team LAVA (hence where the blog name...

View the full article

It's when you are in the Full Editor that you cannot see the history.

I was curious about buffer allocations for the reversed array too. One of the things I tried was to force sequencing of the two case structures, rather than having them run in parallel, but nothing I did had any effect on the speed, even with a very long test string.

I think is due to the subroutine priority setting - the loops must not be able to run in parallel, therefore the VI is as currently as fast as we can make it (it acts the same as if those loops were run serially).

Therefore, if memory is an issue, I challenge anyone out there to optimise it but retain speed

I should have said it doesn't make sense to me. I do think it is a stylistic difference more than a practical difference.

Typically I accomplish that by simply creating protected accessors and let the child class developer be responsible for correct implementation. They can use the accessors in Child.Create to set up the parent data. (Lots of times I want more control over the parent data than I would get from a public creator method.) If there's a lot of code that would require duplication in each child class sometimes I'll create a protected Initialize method that wraps it up for convenience.

I build creator methods for all my classes similar to what JG does... ...I call them "creators" as opposed to "constructors" to maintain differentiation.

But wouldn't you want to reuse your parent constructors in your child constructors (most of the time)?

Having that Class Input allows that.

I was referring to basics versus the example this topic started with (so a "101" course, though not necessarily a class). The class jgcode linked to would be a good introduction.

I prefixed my statement with "guessing" to cover me in case I was wrong - I guess it worked!