Ideas for Implementing a better codding challenge.

[Mike Ashe]

Well, I'm not near a computer with LV at the moment, but I believe LV does have an "exposed" scripting Application class method for doing this (something along the lines of GenerateCCode).

I haven't actually tried it, but it's probably what the PDA module (and LV embedded?) uses and I don't know how good its C is. Also, it doesn't generate a VI back from the C code.

Yes, LabVIEW Embedded creates C code that you then invoke the tool chain on for the target processor. The interesting part is trying to go in the other direction.

[LAVA 1.0 Content]

Coming late in the thread again

[Aristos Queue]

I forgot to mention an idea I had and today's post to this thread reminded me...

Everyone talks about keeping the project small. Suppose the challenge was this:

Some LAVA zealot creates a simple app that does XYZ. The challenge is simply to add a feature to the app. Any feature. This way a person can bite off as much or as little as they choose. Competition is judged on best feature added. The general framework already exists, so there's less of the "blank diagram syndrome". Maybe there's a cool bit of UI that another programmer could convert to an XControl. Maybe the program needs a faster core algorithm. The options are wider for what could be worked on and there's less of a "this is the right answer and if you haven't gotten to this point then you aren't done" which tends to make for long hours of programming to hit a specified target.

We could start with any of several items in the Code Repositiory.

This would take us away from algorithmic challenges -- which depend heavily on programming experience and moments of eureka to solve -- and moves us towards expansion of LabVIEW -- which anyone might be able to contribute to from the parts of LV that they happen to know.

[LAVA 1.0 Content]

This would take us away from algorithmic challenges -- which depend heavily on programming experience and moments of eureka to solve -- and moves us towards expansion of LabVIEW -- which anyone might be able to contribute to from the parts of LV that they happen to know.

I love that idea ! Take advantage of eachone's particular ability(ies) :thumbup:

... and it sticks to short duration challenge, which I could participate to

[JDave]

Everyone talks about keeping the project small. Suppose the challenge was this:

Some LAVA zealot creates a simple app that does XYZ. The challenge is simply to add a feature to the app. Any feature. This way a person can bite off as much or as little as they choose. Competition is judged on best feature added.

I really like the idea :thumbup: since it gives you the option of putting in little time or a lot of time depending on your situation and interest. It might make it a bit more difficult to judge entries, however. Those who did a little would have a hard time held up against someone who put in a lot of time. But what an app you could end up with!!! Definitely a different strategy for building an open source program...

I was thinking it would be nice to have two parts of the Coding Challenge. One that is of necessarily short duration and one that is open ended like previous challenges.

David

[Yair]

Another interesting way to convert a VI to text might be to recursively traverse a diagram and convert it to XML. I believe that XML is supposed to allow for nested data and for unexpected types, so the result might be interesting.

Of course, interpreting the XML might be a bit more complicated than creating it.

[Jim Kring]

Another interesting way to convert a VI to text might be to recursively traverse a diagram and convert it to XML. I believe that XML is supposed to allow for nested data and for unexpected types, so the result might be interesting.

Of course, interpreting the XML might be a bit more complicated than creating it.

If we could represent VIs as XML, then we wouldn't need LabVIEW to create/edit VIs

[crelf]

If we could represent VIs as XML...

That's a cool dream I've had for a while - an open VI definition - we can use scripting to build VIs on the fly. We'd need to really strictly define the structure, and would need NI's help to make sure that we don't miss anything. It sounds like a lot of work though...

[Yair]

If we could represent VIs as XML, then we wouldn't need LabVIEW to create/edit VIs

I'm fairly sure that you can use XML to represent almost anything, but you would need an editor.

An open source G would probably benefit from the code saved as XML, but this would probably be relatively inefficient.

In any case, as Chris said, to convert an LV diagram to XML, you need code for every class and that's a lot of work.

[crelf]

I'm fairly sure that you can use XML to represent almost anything, but you would need an editor.

LabVIEW can be your editor. You just need an import/export utility that (using scripting) builds/unbuilds (is that a word?) between XML and VIs - it wouldn't be difficult, just time consuming.

[Jim Kring]

LabVIEW can be your editor. You just need an import/export utility that (using scripting) builds/unbuilds (is that a word?) between XML and VIs - it wouldn't be difficult, just time consuming.

Sounds like a good coding challenge to me.

I'm fairly sure that you can use XML to represent almost anything, but you would need an editor.

An open source G would probably benefit from the code saved as XML, but this would probably be relatively inefficient.

In any case, as Chris said, to convert an LV diagram to XML, you need code for every class and that's a lot of work.

> I'm fairly sure that you can use XML to represent almost anything, but you would need an editor.

As Chris said, we already have a G editor: it's called LabVIEW.

> In any case, as Chris said, to convert an LV diagram to XML, you need code for every class and that's a lot of work.

As with most things it's good to take small steps. Just take a subset of G, define an XML schema, and build the import/export tools.

I've also toyed around with the idea of building a dataflow execution system (G engine), written in LabVIEW -- I know it can be done. :thumbup:

[crelf]

I'm fairly sure that you can use XML to represent almost anything, but you would need an editor.

As Chris said, we already have a G editor: it's called LabVIEW.

You're absolutely right that I'm right

I've also toyed around with the idea of building a dataflow execution system (G engine), written in LabVIEW -- I know it can be done.

Would such a system break the LabVIEW license agreement?

[Jim Kring]

You're absolutely right that I'm right

That's right.

Would such a system break the LabVIEW license agreement?

Not any more. Take a look at my blog posting titled NISLA July-05 - The end of the beginning. NISLA - August 2001 (circa LabVIEW 6.1) stated that you could not build "general purpose tools" using LabVIEW. NISLA - April 2003 (circa LabVIEW 7.0) changed to state that an authorized application was solely determined by NI. Finally, NISLA - July 2005 (circa LabVIEW 8.0) authorizes all applications which are developed using a licensed version of LabVIEW. :thumbup:

[crelf]

Not any more. Take a look at my blog posting titled NISLA July-05 - The end of the beginning. NISLA - August 2001 (circa LabVIEW 6.1)

Ahhh - now I remember the conversation fondly

[Yair]

Sounds like a good coding challenge to me.

And we've come full circle back to Michael's suggestion. Yes!

...what would it take ...to create code that converts a VI to a text representation and back? ...

Let's call it the LAVA Super Grand Challenge.

You're absolutely right that I'm right

That's right.

I'm getting a feeling that something is wrong here, but I can't put my finget on it.

[crelf]

...what would it take ...to create code that converts a VI to a text representation and back? ...

Let's call it the LAVA Super Grand Challenge.

I call it the LAVA Grand Unified Theory...

[Ton Plomp]

I think I go with Aristos Idea (the XML idea reminded me of this)

For instance Jimi's Class Iconizer could be expanded with XControls, lvlibs, projects and even just hierarchies. It could be merged with other LAVA CR Icon editors.

For me, I'm thinking about expanding my XControl Hierarchical Property creator with a Method creation.

Maybe a LAVA toolbar is an option, I have some things already done (more than 4 months back now so I'll have to dig)

Ton

[Mark Balla]

I forgot to mention an idea I had and today's post to this thread reminded me...

Everyone talks about keeping the project small. Suppose the challenge was this:

Some LAVA zealot creates a simple app that does XYZ. The challenge is simply to add a feature to the app. Any feature. This way a person can bite off as much or as little as they choose. Competition is judged on best feature added. The general framework already exists, so there's less of the "blank diagram syndrome". Maybe there's a cool bit of UI that another programmer could convert to an XControl. Maybe the program needs a faster core algorithm. The options are wider for what could be worked on and there's less of a "this is the right answer and if you haven't gotten to this point then you aren't done" which tends to make for long hours of programming to hit a specified target.

We could start with any of several items in the Code Repositiory.

This would take us away from algorithmic challenges -- which depend heavily on programming experience and moments of eureka to solve -- and moves us towards expansion of LabVIEW -- which anyone might be able to contribute to from the parts of LV that they happen to know.

I think this is a great Idea. Thanks Aristos your my hero (again).

I've been looking for a way to reduce the complexity while increasing participation and I'm willing to give this Idea a shot.

I'll start a new thread to discuss.

[Tomi Maila]

Hi guys,

I've an idea for next coding challege. The idea would be to use LabVIEW to write a utility for PC fan speed automatic configurable control and temperature monitoring. As the hardware support part would be too complicated for coding challenge, the utility could interface with SpeedFan DLL that takes care of the hardware layer. SpeedFan also includes a GUI but I think you guys can easily make a better one using LabVIEW.

If this coding challenge produces a nice and usable LabVIEW application for fan speed control, this application could also promote LabVIEW as a general purpose programming tool among other users.

Tomi

[Ton Plomp]

My idea (inspired by Falkpl) is a Decoration XControl.

With the following data-type:

QUOTE

-BOUNDS <Height, Width>

-POSITION<Left, Top>

-COLOR<FG, BG> A color array would be nice but will be harder to keep compatable. 32 bit color with alpha blend would be very nice but this is a different can of worms.

-SIZE<W, H>

-VISIBLE?

-LABEL: this is never shown but allows for referencing decoration directly without keeping track of indexes.

-POLYLINE: array of points (X,Y) from origin for defining the vector graphic (provide an editor tool), this will accuratly scale decorations with size changes of the bounding rectangle.

-PATTERN: 2d array of texture to fill polygon with

-BLEND: if pattern is not used, allow for blend from color A to color B allong a specoified vector ie (red to white allong the unit vector 1,1 provides a Red phase out from the upper left corner to the lower right)

-ROTATION: 0-360 (int%360) rotates image about center by specified degrees.

-TRANSPARANCY- 0-100% allows for blending and object overlap.

And methods:

-DD_POINT - inserts a point into the polyline at a specified index

-REMOVE_POINT -removes a point into the polyline at a specified index

I am willing to setup a template XControl to fullfill these options which could be expanded on will.

Ton

[jbrohan]

QUOTE(bsvingen @ Oct 23 2006, 08:44 PM)

What would be more interresting, and also a lot easier and faster, is to write a compiler that makes VIs out of a textual language. Then you are free to make the language syntax and style anyway you like, without the restriction that it has to be a textual representation of the VI.

Now This is really interesting. But I look at it from 180 deg the other way! I work a little with php and HTML and miss my icons. I wrote a few little tools to generate decoding arrays and so on. However a clean interface which generates and uploads php script from inside the LavVIEW environment would be really useful and 'spread the word'. Imagine generating php SQL statements from inside LabVIEW icons and avoiding a misplaced quotation mark, or tangled order ot names and avalues.

The ideas about teams of people working together on a competitive entry would add to the fun.

Best Wishes

John

[Sparkette]

Last summer, I caught a cod that was longer than 4 yards. Do I win the codding challenge?

/sarcasm