LapDog - an open source mid-level api for LVOOP

[Daklu]

It's no secret I've been a bit frustrated by Labview's lack of a mid-level api for object oriented programming. .Net and Java have extensive support classes for operations with objects, such as data structures, several kinds of collections, and standard behaviors that can be customized through interfaces. In Labview we have to create our own support classes, which often results in recreating and customizing them for each new project.

I've been slowly building up design ideas and a code base for various OOP supporting components, such as an interface framework and collection classes, with the idea of releasing them into the open source community. (Privately I've been referring to them collectively as "LapDog." Why? No idea... it was the first thing that popped into my head.) This is, however, a very slow process for one person who also has the usual work and family commitments, and to be honest, there are aspects of making code ready for public consumption that I'm just not very good at.

I don't want LapDog to be a large api that is the Labview equivalent of the .Net framework. I'd prefer to create smaller independent components that provide useful functionality with enough flexibility that the object-oriented developer can extend it to solve their unique problem. This will allow the developer to include only that functionality they need in their project. I anticipate most components will consist of less than a dozen classes. Collections, data structures, and interfaces would likely be the first things we work on. (Primarily because I already have code for those things.)

This is just an initial query to see how much need there is for a mid-level api and determine if it's worth my time to set up a public portal for the LapDog source code. If you are interested, please answer the following questions:

1. Would you be interested in using LapDog in your projects?

2. Are you able to help develop, maintain, and support LapDog?

If you answer yes to Q.2, please also answer these questions:

3. How much time on average do you think you could spend on this project? (I'm not asking for a commitment, just an estimate.)

4. Given your time constraints and level of knowledge, which role(s) do you think you can fill?

Consultant -

I don't really have time to help out with dev work but I'm an experienced OO programmer (in any language) and I'd be happy to answer questions or discuss design decisions as my time allows.

Architect

- I have a working understanding of many of the standard OO design patterns (in any language) and have implemented (or tried to implement) some of them in Labview. I can generally make myself available to respond to issues that will arise when my designs are being implemented and will remain engaged during the entire dev process.

Developer -

I may not (or may) have much experience with object oriented programming in Labview, but I've been programming for several years, I'm comfortable writing Labview code, and I keep my block diagrams tidy.

Tools

- I love messing around with scripting and vi server calls! Creating an api for other developers requires different tools than application code; I'd rather work on that than write boring old regular code. Did I mention I love scripting?

Documentation & Examples

- I recognize good examples and clear explanations are critical to making an api usable. I can put together sample projects that show end users how to use the components in their own projects to solve various problems.

Beta Tester

- I can't help out with dev work much, but give me a beta component occasionally and I'll happily try to implement something with it and give you feedback on how easy it is to use and any problems I ran into.

Graphics

- I'm an endangered species among engineers... I have artistic talent! I love creating vi and palette icons, glyphs, animations, etc. I make the most out of the icon editor, but sometimes I'll use a vector graphics program to get the look I'm after. In a pinch I can design a pretty dang good user interface too.

These are my initial ideas of different tasks that need to be done to ensure LapDog is a high quality api. I'm under no illusion that lines will be forming to fill these roles, but I do need to have an idea of how many of these tasks can be covered before I'm willing to embark on this journey.

[Yair]

First, I would recommend that you check if you can get this into OpenG. They already have a development process in place, as well as a distribution mechanism.

Second, I would say that I would use it (at least if it's polished enough), but I'm not sure what "it" is exactly. Can you provide an example of potential components and how using such a component would work (e.g. I install the interface API and that gives me a palette with some common interface functionality and a wizard in the Tools menu for generating the VIs with the interface code for my clases).

Third, I would say I would contribute, but unfortunately I doubt I would be able to hold up to that claim.

[Ton Plomp]

This sounds very interesting, but I agree with Yair, try to get in contact with Tomi Maila, who has written several OpenG Class templates, how do these two match up?

Or am I totally missing your point?

I would love to contribute, but I doubt I will have the time to provide quality code. However keep us posted.

A good documentation resource would be the LabVIEW wiki.

Ton

[GoGators]

It's no secret I've been a bit frustrated by Labview's lack of a mid-level api for object oriented programming.

I find the lack of certain basic structures to be annoying too.

I'd prefer to create smaller independent components that provide useful functionality with enough flexibility that the object-oriented developer can extend it to solve their unique problem.

Ideally each pattern should be easy to digest in under 10 minutes. More complex ones should be allowed later on though.

1. Would you be interested in using LapDog in your projects?

Yes.

2. Are you able to help develop, maintain, and support LapDog?

Yes

3. How much time on average do you think you could spend on this project?

3-5 hours a week. More if the class lines up with a current project.

4. Given your time constraints and level of knowledge, which role(s) do you think you can fill?

Consultant/Developer. I'm not cocky enough yet to say Architect.

[Daklu]

Good idea about OpenG. I'll post over on their forums and see how well my ideas fit in with their goals.

Second, I would say that I would use it, but I'm not sure what "it" is exactly.

This sounds very interesting, but I agree with Yair, try to get in contact with Tomi Maila, who has written several OpenG Class templates, how do these two match up?

I'm not that familiar with the OpenG Class templates so my impressions might be completely wrong. Whereas OGCT implements templates for users to create different kinds of classes, LapDog is more geared around components that allow OO developers to do more with the classes they create. Some components, like the different collections, would be accessed through the palette. Others, like the interface framework, would probably have some palette parts and some wizard parts.

One of my key goals is for each component to provide at least a minimum amount of functionality "out of the box" while making it easy for api users to extend the component's functionality via inheritance or composition. For example, the List Collection component might be initially distributed with two implementation classes available: a basic array and a buffered array. If the api user wants to use a binary tree for their collection all they have to do is derive a child that implements the tree from one of the existing implementations and wire that into the List:Create method.

I find the lack of certain basic structures to be annoying too.... 3-5 hours a week. More if the class lines up with a current project.

So, uh... should I read anything into these comments? Where do you *ahem* suggest we start?

Ideally each pattern should be easy to digest in under 10 minutes.

Yeah, assuming the user has some understanding of the purpose of the component. I'd be hard pressed to explain what Interfaces are, how to create new Interfaces, and how to use Interfaces in less than 10 minutes.

[jgcode]

This is just an initial query to see how much need there is for a mid-level api and determine if it's worth my time to set up a public portal for the LapDog source code.

Ok this sounds really exciting...

This is because I am trying to release packages now that contain reusable class that I can use in my projects.

I am I seeing massive performance increments (not CPUs stuff - I mean in respect to my time in rolling out a project).

There is a lot of work setting things up, but the payback can be huge.

So I can see this as really beneficial to the community.

No point reinventing the wheel - lets get together.

As soon as I read this I thought OpenG too.

I think anything that can improve LabVIEW is a good thing, and who knows down the track they may get natively implemented like some OpenG functions have in the past.

I think OpenG would have the credibility and the backbone to roll this out, so definitely look there first (IMHO too)

Here is a list of things I am working on at the moment:

(I have decided to start with 2009 for this, there is just so much more I can do there then say 8.2, so I don't see the point)

Data Class (objects that have LV datatypes with get and set methods so I can send/store/manipulate data as objects)

Circular Buffer (stores generic LV Object, but I make wrappers for common Data Classes (E.g 1D DBL) so I don't have to convert in my code)

Counter

Error Logger

Timers

Window (Front Panel) Settings

File IO Manager (creates a file with a header so file versioning is easy, extend to implement e.g. a config file to manage sections and reading/writing)

File IO Interface

Various UI Effect

Making a plugin Run Time Menu, that is also linked to buttons (e.g. enable button enable RTM item, turn button On, check RTM item; select an enum value, check one item in a list in a RTM submenu etc..)

Now, none of these maybe of interest, but that is just some stuff I am up too.

I like LVClasses so I am down for pretty much anything.

PS - What is with the name?

[MikaelH]

Sure, I'm interested in helping out.

The problem is always to be able to create something that have enough flexibility and doesn't become too big for people to add to their projects.

I can help out in Architecting, Developing and Tooling areas.

I have a function in GDS to add design patterns to existing classes and I can see this is a similar function.

If I understand it right, one user scenario could be that I like to create a Database class.

I then use a tool, to create this Database framework.

If this example I called the Framework “ .LabVIEW “

Cheers,

Mikael

[K-node]

OK, Daklu, count me in. I wish these mid-level components were around months ago. I expect that I can give 4+ hours a week, perhaps more depending on how I can integrate the effort with my current projects. I have OO experience, so I can do some development, examples and documentation. Architecting is a possibility, but I am not good at UML type presentations.

Is anyone going to NI Week? Perhaps it would be beneficial to meet. I have not made any arrangements - including begging for money from my management - but I might consider this. I would also have to see if I can grab some other resources (conference call, webex, etc.) if this is of interest - though that does not always work well with international schedules.

-kugr

[PaulL]

Daklu,

I, too, am very interested in learning more about what you are trying to do. Before I sign on, I'd like to know a bit more about your vision for this. (I don't have much time to work on things outside my current project, but if the dividends from common development were significant then I could justify putting some effort into this.)

By the way, I like certain things about OpenG but one thing I personally am not so fond of is that using a simple function (take Filter 1D Array, for example) usually fills up my dependencies...user.lib with many functions, and this information is not structured. That may not be much of an issue for the project under discussion since presumably everything would exist in classes, so that the dependencies would have class library structures, but I decided to mention this because in practice this (and a couple unavoidable issues with OpenG--no guarantee of forward compatibility, for instance) troubles me enough that I almost never use OpenG methods in my own projects (though I realize many developers do this quite successfully!). On the other hand, I think OpenG offers an existing popular distribution mechanism. I wonder if there might even be an option to sell the resulting IP to NI for implementation in the core LabVIEW libraries....

Paul

[Daklu]

I had a brief exchange with Jim and it sounds like LapDog doesn't quite fit in with the intent of OpenG. OpenG is focused on low level functions, not a mid level api. If we want to move forward with this we'll be doing it from scratch. We'll have to set up a repository and forums online, define our goals, figure out processes, map out a code plan, etc. I appreciate the excitement (I'm excited too) but I just want it to be clear that this is not a small undertaking.

Jon and Mikael both raised very good points. Here are some thoughts that hopefully further explain my intended direction:

• LapDog is targeted at intermediate and advanced LVOOP developers. Obviously anyone can use it, but documentation and supporting tools will assume some level of OOP knowledge.
• LapDog prioritizes developer productivity over execution effeciency. Additional execution overhead is inevitable when inserting new abstraction layers. We will attempt to minimize the overhead but accept that as a tradeoff for improved productivity.
• LapDog emphasizes flexibility. Often users will not simply drop a package class into a project and use it as is (unless their needs are very simple); they will use the package as a foundation to create classes that, through inheritance or composition, work the way the user needs it to work. (I anticipate the bridge pattern and dependency injection will be used a lot.)
• LapDog strives for package independence. If I want to use the Bag package in my project, I don't need to install any other packages to make it work.

[Edit - I'll create a class diagram of how I expect the Bag package to work. Hopefully that will help clarify my idea.]

Jon and Mikael, I like the ideas you are proposing. We should move specific discussions into a project forum. Sourceforge seems to be the default choice for online hosting. Is there any reason not to use it?

PS - What is with the name?

Here's the entire thought process I went through... it took about 1.3 seconds.

"Huh... I really should have a name for these APIs I'm developing. Labview Object-Oriented API... LOOAPI? Ugh... Labview API for Object Oriented Programmers? LAPIOOP? Object Based API for Labview? Rats, these words are terrible for trying to make acronyms. Labview Api for Programming Applications? Lapa? *sigh.*

"Java's Swing is an easy to remember name for an api. I don't think that's an acronym for anything. Why should I restrict myself to an acronym? I wonder what other names I can come up with? What was I thinking of? Lapa... Lapi... Lap... our stupid cat likes to sit on my lap. The thing weighs a ton and gets hair all over me too. Sure wish we could get rid of it. A dog would be nice. I miss my golden retriever. He was a good dog. He liked to climb on my lap too and he weighed way more than our stupid cat. That's okay, he was a dog. Heh... he thought he was a lapdog. Hey... 'LapDog' is easy enough. I think I'll use that."

That said, I'm not married to the name. (The more I use it the more I like it and we are considering moving in together.) I'm open to a good alternative if you can think of one quickly--we need to settle on a name before creating a repository. "LapDance" is certainly memorable and I can think of several interesting ideas for icons, but I'll have to reject that one as not work-friendly.

Is anyone going to NI Week?

I am not. As a contractor I don't have anyone to pay my way so not only do I have to foot the entire bill, but I also lose any money I would have earned during that time. That's a pretty big hit for a working stiff.

I wonder if there might even be an option to sell the resulting IP to NI for implementation in the core LabVIEW libraries....

Nope. This will be open source software probably licensed under the LGPL. If NI wanted to take it and incorporate it as part of Labview I'd support them. Then I get the functionality I want and I don't have to support the code anymore!

[PaulL]

Nope. This will be open source software probably licensed under the LGPL. If NI wanted to take it and incorporate it as part of Labview I'd support them. Then I get the functionality I want and I don't have to support the code anymore!

That's really what I was getting at. I'd like to ensure that maintenance for forward compatibility occurs. (Some pieces may not need future changes, but I am guessing some will.) Sounds good.

[Daklu]

I'd like to ensure that maintenance for forward compatibility occurs.

My crystal ball isn't good enough to guarantee forward compatibility maintenance will occur. With the right licensing the best I can do is guarantee that forward compatibility maintenance will be able to occur.

[MikaelH]

Is anyone going to NI Week?

I'll be there

I am not.

Sorry to here, it would be nice to meet you, some other time then :-)

[Daklu]

FYI - I set up a SourceForge project last night. If you're interested in participating create a SourceForge account, then go here and click "send a request to join this project."

Thanks.

[Jeffrey Habets]

I like the Idea! This is something that has always been on my mind to do internally, but time never permits. Making it a group effort is a good idea.

I'll be happy to throw in my where-ever I can, as time permits.

I'll be at NIWeek this year btw.

[Phillip Brooks]

Here's the entire thought process I went through... it took about 1.3 seconds.

"Huh... I really should have a name for these APIs I'm developing. Labview Object-Oriented API... LOOAPI? Ugh... Labview API for Object Oriented Programmers? LAPIOOP? Object Based API for Labview? Rats, these words are terrible for trying to make acronyms. Labview Api for Programming Applications? Lapa? *sigh.*

"Java's Swing is an easy to remember name for an api. I don't think that's an acronym for anything. Why should I restrict myself to an acronym? I wonder what other names I can come up with? What was I thinking of? Lapa... Lapi... Lap... our stupid cat likes to sit on my lap. The thing weighs a ton and gets hair all over me too. Sure wish we could get rid of it. A dog would be nice. I miss my golden retriever. He was a good dog. He liked to climb on my lap too and he weighed way more than our stupid cat. That's okay, he was a dog. Heh... he thought he was a lapdog. Hey... 'LapDog' is easy enough. I think I'll use that."

Much simpler than LVOOPIVIVILAVA!

[Daklu]

FYI - Jon (jgcode) has graciously volunteered to help out with project administration. There seems to be a problem with SF's email in that requests to join the project are bouncing back to the sender. If you are having this problem send either Jon or I a private message with your SF user name and we can add you manually.

Much simpler than LVOOPIVIVILAVA!

*Phew* I almost went with that one too... I would've had to cancel the whole project.

[rogeri]

Hi guys, good initiative with LapDog..

1. Would you be interested in using LapDog in your projects?

Yes!

2. Are you able to help develop, maintain, and support LapDog?

Yes!

If you answer yes to Q.2, please also answer these questions:

3. How much time on average do you think you could spend on this project? (I'm not asking for a commitment, just an estimate.)

about 4h/week

4. Given your time constraints and level of knowledge, which role(s) do you think you can fill?

Consultant/Architect/Examples.

I already got some ~30 classes ready to be scrutinized. They range from refoop base classes, threading, iostreams, control systems, event handlers, state machine, and example implementation projects. The code is quite clean, except for some rough example code. Everything 100% is native LV 2009 - without any dependency to extra addons, package managers or refoop tool suites. The code runs on production machines, so it's quite reliable and has little overhead.

I would like to contribute it all and sign up. I guess we are going GPL with this?

Any idea on how to manage the namespaces/packages/folders so that we can avoid namespace clashes? projectname.subproject.lapdog.org?

/Roger

[jgcode]

Hi guys, good initiative with LapDog..

1. Would you be interested in using LapDog in your projects?

Yes!

2. Are you able to help develop, maintain, and support LapDog?

Yes!

If you answer yes to Q.2, please also answer these questions:

3. How much time on average do you think you could spend on this project? (I'm not asking for a commitment, just an estimate.)

about 4h/week

4. Given your time constraints and level of knowledge, which role(s) do you think you can fill?

Consultant/Architect/Examples.

I already got some ~30 classes ready to be scrutinized. They range from refoop base classes, threading, iostreams, control systems, event handlers, state machine, and example implementation projects. The code is quite clean, except for some rough example code. Everything 100% is native LV 2009 - without any dependency to extra addons, package managers or refoop tool suites. The code runs on production machines, so it's quite reliable and has little overhead.

I would like to contribute it all and sign up. I guess we are going GPL with this?

Any idea on how to manage the namespaces/packages/folders so that we can avoid namespace clashes? projectname.subproject.lapdog.org?

/Roger

Hi Roger

That sounds great. You can start by signed up at SourceForge (see Daklu posts above).

With respect to namespacing, I have been encapsulating all releases in a Top Level Library that gets renamed during the distribution e.g. so "StateDisplay.lvlib" source would be release as "StateDisplay_company_lib_state_display.lvlib" (following VIPM namespacing syntax).

This has worked out great for all my releases with respect to namespacing and upgrading etc... except I am having some issues with the palette I have not yet been able to resolve.

Cheers

-JG

[Daklu]

I would like to contribute it all and sign up. I guess we are going GPL with this?

Glad to have you aboard. Licensing will almost certainly be LGPL to make it as easy as possible for anyone (students, test engineers, commercial integrators, National Instruments(?)) to include it in their own software.

Any idea on how to manage the namespaces/packages/folders so that we can avoid namespace clashes? projectname.subproject.lapdog.org?

Nope, not yet. This project is still brand new so we have a lot of things to work out before we are able to release anything.

[jgcode]

Nope, not yet. This project is still brand new so we have a lot of things to work out before we are able to release anything.

Just to clarify: I just posted above an example of what I currently do - only.

Cheers

-JG

[Yair]

Licensing will almost certainly be LGPL to make it as easy as possible for anyone (students, test engineers, commercial integrators, National Instruments(?)) to include it in their own software.

I believe BSD is a lot more convenient, because it doesn't require anything from the user. If memory serves, LGPL requires that you dynamically link to the code so that the end user can replace it (which is probably meaningless with this type of code, since at least parts of it are going to be modified by each user). If memory serves, that was the reason OpenG moved away from it and if the search here was reasonable, I could probably find the old discussion about it.

[Daklu]

Thanks Yair. Now that you mention it I do recall some discussions about OpenG licensing and BSD.

(See, you're already contributing! )

[jcarmody]

 

[...] I could probably find the old discussion about it.

Here are two:

http://lavag.org/top...dpost__p__25408

http://lavag.org/top...iew-vi-library/

The first one sounds more like what you had in mind. 

[Daklu]

For those who have joined the project, I have set up a repository location for uploading code you are willing to donate. In the submissions folder, create a folder with your user name. Create a sub folder with a descriptive name for each module and put your code there. When we start integrating a module into the LapDog api we'll copy it over to our main dev branch. Link

Jon and I are working on getting a decent forum in place for LapDog developers so we don't load down the Lava forums with our stuff. Neither of us have worked with SF so there is a bit of a learning curve.