SCRIPTING IS AVAILABLE

[i2dx]

QUOTE (Aristos Queue @ May 30 2009, 06:26 PM)

I had very little to do with it other than saying, "Yes I think its a good idea" when asked.

uhm, I read your initial post somewhat in a way that YOU were lobbying

and YES, I know it's dangerous. But fire is dangerous, too - but can you imagine a BBQ without it? And if you don't believe me, you are invited to come down to Ft. Myers Beach, then I'll show you . Finally I am now again able to waste lots of hours to automate a programming task which could be done with templates much quicker - or, just to express this in a more positive way: I can quit my WoW account and start developing tools again

QUOTE (Aristos Queue @ May 30 2009, 06:26 PM)

Our primary goal is serving non-programmers in some key domains. We are trying to balance power vs security, and making it a separate install serves that balance nicely.

I think NI / LV has left this track a long time ago. With each release LV has become more and more powerful and has become more and more a "technical purpose high level programming language". Just to prove that: nobody who is serious with LV would ever admit that she/he makes usage of express VIs

cheers,

CB

[peteski]

QUOTE (i2dx @ May 30 2009, 07:38 PM)

Just to prove that: nobody who is serious with LV would ever admit that she/he makes usage of express VIs

cheers,

CB

Express Vi's? Express VI's?!?! We don't need no $^!&*!&% Express VI's!!!

REAL LabVIEW programmers start with a blank VI... and previous to that has deleted or hidden ALL Express VI pallets...

Or at least refuses to acknowledge their presence on the palette!!

Mind you, in all honesty, I haven't touched scripting yet... is the time now?

-Pete Liiva

[PeterB]

I can't see the light .... I'm not as excited as everyone else seems about the possibilities of scripting yet and I've been an enthusiastic LabVIEW for 15 years now.

How many text based programmers write code that writes its own code (let alone salivate over the thought of being able to do so) ? Perhaps they take the idea for granted and have never put their imagination to work.

Certainly LabVIEW is now one step closer to being able to do what C++ can, but I'm not yet sold on the idea.

What are folks really intending to do now with scripting that has such value ? You can talk about what you plan to do, but if you never allocate time to implement the idea then scripting isn't really all that valuable to you after all. Enough talk, how about you show me your really useful creations ! (I'll accept Auto wiring scripted tools only if they produce a similar wow factor to the BD cleanup feature !)

I bet C++ could write a faster Hello World Program than LabVIEW could.

Its OK if I don't get too excited over scripting.

regards

Peter

QUOTE (hooovahh @ May 30 2009, 08:01 AM)

<charming music>

Say you have a generic DAQ system which needs inputs and outputs.

There's a script for that.

And say you want to make your programming life easier by adding tools which automate wiring up controls and indicators.

There's a script for that.

And say you just want to impress your friends, by writing the fastest 'hello world' program in existance.

There's even a script for that.

There's a script for just about any thing.

Only on LabVIEW

</charming music>

[ShaunR]

QUOTE (Val Brown @ May 30 2009, 10:21 PM)

Why do you think it's so horrific? It makes a great deal of sense to me -- for what THAT's worth -- and it is an honest reflection of the nature of NIs products and orientation.

Because it is the programmers that argue in budget meetings to maintain the SSP's. Programmers that buy the latest versions to take advantage of new technologies (do you really think non-programmers would write OOP labview?). And it is programmers that non-programmers rely on to help them understand Labview (like this board). It is also programmers that NI rely on to beta test, so they can take advantage of a "Free" resource" and to be considered a second priority I (quite frankly) find insulting. This is typical "Microsoft Mentality". Most non-programmers only use Labview if it is already there and rarely get past modifying an example to achieve a specific result. That sentiment belongs 10 years in the past and QA should know better than to state it even if he thinks it.

QUOTE (PeterB @ May 31 2009, 06:54 AM)

I can't see the light

.... I'm not as excited as everyone else seems about the possibilities of scripting yet and I've been an enthusiastic LabVIEW for 15 years now.

How many text based programmers write code that writes its own code (let alone salivate over the thought of being able to do so) ? Perhaps they take the idea for granted and have never put their imagination to work.

Certainly LabVIEW is now one step closer to being able to do what C++ can, but I'm not yet sold on the idea.

What are folks

really

intending to do now with scripting that has such value ? You can talk about what you plan to do, but if you never allocate time to implement the idea then scripting isn't really all that valuable to you after all. Enough talk, how about you show me your really useful creations ! (I'll accept Auto wiring scripted tools only if they produce a similar wow factor to the BD cleanup feature !)

I bet C++ could write a faster Hello World Program than LabVIEW could.

Its OK if I don't get too excited over scripting.

regards

Peter

I kind of agree. Scripting only has value within the tool chain. You can't use it for in your distributions so there is no commercial value added other than tools for programmers (and I've been using Labview so long now, I don't really need anything that Labview doesn't provide). I don't see much benefit for anything I do, that a VI in the pallet set to "Place Vi Contents" can do more easily and in less time. Admittedly there are "cool" things like the voice control etc. But I view those as "finding a purpose to fit the feature" . If we could create our own controls at run time using scripting, then this would be a boon. But as it stands, no commercial value, no interest.

[Val Brown]

QUOTE (ShaunR @ May 31 2009, 02:57 AM)

Because it is the programmers that argue in budget meetings to maintain the SSP's. Programmers that buy the latest versions to take advantage of new technologies (do you really think non-programmers would write OOP labview?). And it is programmers that non-programmers rely on to help them understand Labview (like this board). It is also programmers that NI rely on to beta test, so they can take advantage of a "Free" resource" and to be considered a second priority I (quite frankly) find insulting. This is typical "Microsoft Mentality". Most non-programmers only use Labview if it is already there and rarely get past modifying an example to achieve a specific result. That sentiment belongs 10 years in the past and QA should know better than to state it even if he thinks it.

I kind of agree. Scripting only has value within the tool chain. You can't use it for in your distributions so there is no commercial value added other than tools for programmers (and I've been using Labview so long now, I don't really need anything that Labview doesn't provide). I don't see much benefit for anything I do, that a VI in the pallet set to "Place Vi Contents" can do more easily and in less time. Admittedly there are "cool" things like the voice control etc. But I view those as "finding a purpose to fit the feature" . If we could create our own controls at run time using scripting, then this would be a boon. But as it stands, no commercial value, no interest.

I don't want to start a flame war here, not do I want to hijack this thread, but IMO you are completely offbase with this comment and thinking. I have NO degree in CS. I have no "official" programming/programmer's background. I have been on SSP since 98 -- for several years for both Mac and Windows versions. And I only program for my own project even though I have been asked repeatedly to program for others. And I KNOW I'm not the only "non-programmer" in the NI world but I also know that I've put NI through its paces in terms of number of CARs issued, etc over the years.

In contrast to your comment about "typical Microsoft..." I would say that you perspective is "typical OOPs: meaning Object Oriented Programmers 'stuff'". Let it go man. Look at the BIG picture -- which is the basis on which NI has not only survived but thrived by NOT primarily catering to nor orienting itself to "Programmers".

OK end of rant and end of comments on this perspective.

[crelf]

QUOTE (peteski @ May 30 2009, 09:36 PM)

REAL LabVIEW programmers start with a blank VI...

Real LabVIEW programmers start with templates in their reuse libraries

QUOTE (PeterB @ May 31 2009, 01:54 AM)

What are folks

really

intending to do now with scripting that has such value ? You can talk about what you plan to do, but if you never allocate time to implement the idea then scripting isn't really all that valuable to you after all.

I think it's because scripting is reall two things: the ability to create code on the fly (ok, not really many use cases for this, but they do exist) and exposure of previously private methods and properties on existing LabVIEW nodes, and it's the latter that I think will be more useful to most people. The create-stuff-programmatically part has be useful to me in the past (in fact, there's a few things I've done with it that I simply wouldn't have been able to do without it, and we certainly wouldn't have been able to complete a project or two), but you're absolutely right: it's not so much in my day-to-day architectures. The exposure of previous private methods and properties, on the other hand, is more common.

Not that you need me to say it, but you're completely right: Its OK if you don't get too excited over scripting.

[David Wisti]

There are quite a few good use cases for scripting. I once had to create a enum constant with over 500 elements. Using the Edit Items... dialog box would have taken forever. The 500 enum values were already in a text file. Using VI scripting I opened the text file and created the enum.

QUOTE (PeterB @ May 31 2009, 01:54 AM)

What are folks really intending to do now with scripting that has such value ? You can talk about what you plan to do, but if you never allocate time to implement the idea then scripting isn't really all that valuable to you after all. Enough talk, how about you show me your really useful creations ! (I'll accept Auto wiring scripted tools only if they produce a similar wow factor to the BD cleanup feature !)

[i2dx]

QUOTE (crelf @ Jun 1 2009, 05:21 PM)

Real LabVIEW programmers start with templates in their reuse libraries

ACK!

But now I can go further: generate a new VI from a Template VI and automatically adapt it with scripting to my "project needs", which will in fact reduce my template jungle and I can create my new templates more generally

[PaulG.]

QUOTE (David Wisti @ Jun 1 2009, 11:54 AM)

... Using VI scripting I opened the text file and created the enum.

I do that all the time without scripting. Read the file, load the string values into a text ring, then replace the text ring with the enum. Or did I miss something?

[David Wisti]

Great idea, didn't know you could do that. I guess you could call that pseudo-scripting. With VI scripting being available since 7.1 it never dawned on me to try a text ring.

QUOTE (PaulG. @ Jun 1 2009, 12:16 PM)

I do that all the time without scripting. Read the file, load the string values into a text ring, then replace the text ring with the enum. Or did I miss something?

[Phillip Brooks]

QUOTE (PaulG. @ Jun 1 2009, 12:16 PM)

I do that all the time without scripting. Read the file, load the string values into a text ring, then replace the text ring with the enum. Or did I miss something?

I've done that for years too! I showed that trick to somebody once and he hit his head on the desk.... repeatedly... VERY HARD!

That said, a right-click that could convert a c enum declaration string (constant on BD) to a LV enum constant would be nice...

[Yair]

QUOTE (Phillip Brooks @ Jun 1 2009, 08:49 PM)

That said, a right-click that could convert a c enum declaration string (constant on BD) to a LV enum constant would be nice...

Once JKI's RCF comes out, you should be able to easily do this (or suggest it to Jim, maybe they'll do it for you )

[jzoller]

Code generation is nice... but (somewhat) supported modification of the developer environment by the end users is why I'm excited.

Joe Z.

[Yair]

QUOTE (crelf @ Jun 1 2009, 06:21 PM)

I think it's because scripting is reall two things: ...exposure of previously private methods and properties on existing LabVIEW nodes

Strictly speaking, that's not scripting. It's private functionality. I haven't looked at the license NI released yet, but it definitely won't include all private properties and methods NI has. Many of them will continue to stay private.

I agree with Peter that most people don't actually need scripting (defined as "code able to read, edit and create other code") most of the time. Unless you're actively working on writing a tool which will handle LabVIEW code (like JKI's RCF), you will rarely need it. I think most people are excited for one of three reasons:

1. Most people are probably excited just because of the hype. It was hidden. Then it was locked. There were many discussions. Now it's easily accessible. As people will calm down, they will understand that they don't actually need it.

2. Some people actually need it for their own tools or will now be able to use stuff based on scripting that other people release. Thus, they're happy even if there is no HUGE direct gain. This covers most of the userbase and is a very good reason to be happy. I fall into that category.

3. Others might see this as an important point in the NI-community relationship. The community pushed, NI eventually listened. This becomes another step on the road NI has been taking.

[LAVA 1.0 Content]

QUOTE (PaulG. @ Jun 1 2009, 06:16 PM)

I do that all the time without scripting. Read the file, load the string values into a text ring, then replace the text ring with the enum. Or did I miss something?

Is it a http://forums.lavag.org/Variant-To-Control-file89.html' target="_blank">typedef?

Ton

[crelf]

QUOTE (Yair @ Jun 1 2009, 02:23 PM)

Strictly speaking, that's not scripting. It's private functionality.

True - and that's the important distinction I was trying to make. Most people refer to the combination od scripting and private functionality as "scripting", and I was trying to point out that, while they're delivered in the same package, they're not the same thing.

[Mark Balla]

QUOTE (PeterB @ May 31 2009, 12:54 AM)

I can't see the light .... I'm not as excited as everyone else seems about the possibilities of scripting yet and I've been an enthusiastic LabVIEW for 15 years now.

What are folks really intending to do now with scripting that has such value ? You can talk about what you plan to do, but if you never allocate time to implement the idea then scripting isn't really all that valuable to you after all.

Enough talk, how about you show me your really useful creations ! (I'll accept Auto wiring scripted tools only if they produce a similar wow factor to the BD cleanup feature !)

I have a fairly useful time saving creation that uses scripting found Here.

I've also created a few Screen Cast videos here and here showing how it works.

[PaulG.]

QUOTE (Ton @ Jun 1 2009, 02:32 PM)

Is it a typedef?

Ton

I don't think so - or I don't remember ever trying it that way. I usually wait until I get my enum before I convert it to a typedef.

QUOTE (hooovahh @ May 29 2009, 05:01 PM)

<charming music>

Say you have a generic DAQ system which needs inputs and outputs.

There's a script for that.

And say you want to make your programming life easier by adding tools which automate wiring up controls and indicators.

There's a script for that.

And say you just want to impress your friends, by writing the fastest 'hello world' program in existance.

There's even a script for that.

There's a script for just about any thing.

Only on LabVIEW

</charming music>

I think that is the one thing that makes me the most nervous about scripting. To hell with the fear of losing my job. Today it's cute little "hello world" vi's that write themselves. Tomorrow it's Skynet.

[ShaunR]

QUOTE (PaulG. @ Jun 1 2009, 05:16 PM)

I do that all the time without scripting. Read the file, load the string values into a text ring, then replace the text ring with the enum. Or did I miss something?

This also works with DAQ tasks .

[PeterB]

QUOTE (mballa @ Jun 2 2009, 05:46 AM)

I have a fairly useful time saving creation that uses scripting found Here.

I've also created a few Screen Cast videos here

and here showing how it works.

Thanks for those examples Mark. Your sub-vi re-wire-er is a good example that you would clearly make use of. I'm sure it would come in handy in my toolbox too. If I was to write something like that perhaps it would take me at least 3-4 days and my initial thoughts are that I wouldn't recoup the time spent creating it with the time saved in using it. So while it is a 'nice to have' tool, I would only use it if somebody else (NI included) provided it for me.

regards

Peter

QUOTE (crelf @ Jun 2 2009, 02:21 AM)

I think it's because scripting is reall two things: the ability to create code on the fly (ok, not really many use cases for this, but they do exist) and exposure of previously private methods and properties on existing LabVIEW nodes, and it's the latter that I think will be more useful to most people. The create-stuff-programmatically part has be useful to me in the past (in fact, there's a few things I've done with it that I simply wouldn't have been able to do without it, and we certainly wouldn't have been able to complete a project or two), but you're absolutely right: it's not so much in my day-to-day architectures. The exposure of previous private methods and properties, on the other hand, is more common.

Not that you need me to say it, but you're completely right: Its OK if you don't get too excited over scripting.

Thanks for your ideas Chris. I look forward to discovering what private methods and properties NI might have exposed.

cheers

Peter

QUOTE (Yair @ Jun 2 2009, 05:23 AM)

Strictly speaking, that's not scripting. It's private functionality. I haven't looked at the license NI released yet, but it definitely won't include all private properties and methods NI has. Many of them will continue to stay private.

I agree with Peter that most people don't actually need scripting (defined as "code able to read, edit and create other code") most of the time. Unless you're actively working on writing a tool which will handle LabVIEW code (like JKI's RCF), you will rarely need it. I think most people are excited for one of three reasons:

1. Most people are probably excited just because of the hype. It was hidden. Then it was locked. There were many discussions. Now it's easily accessible. As people will calm down, they will understand that they don't actually need it.

2. Some people actually need it for their own tools or will now be able to use stuff based on scripting that other people release. Thus, they're happy even if there is no HUGE direct gain. This covers most of the userbase and is a very good reason to be happy. I fall into that category.

3. Others might see this as an important point in the NI-community relationship. The community pushed, NI eventually listened. This becomes another step on the road NI has been taking.

Thanks Yair,

I think that is a good summary.

regards

Peter

[LAVA 1.0 Content]

QUOTE (Aristos Queue @ May 29 2009, 06:50 PM)

http://decibel.ni.com/content/docs/DOC-4973#cf

After years of lobbying, National Instruments has now released scripting as a tool that our users are allowed to use. The Windows license and support files are now available for download from the above link. Mac and Linux download will be posted next week.

For those who are wondering, "What do we need to download on Mac/Linux since there's no licensing required?" ... there's a .zip file of useful information and instructions that will be posted.

Thanks a lot- But why you didn't included your help files? :question:

[Darren]

My first blog post on scripting:

LabVIEW Scripting Tip #1: The Power of Traverse

-D

[asbo]

QUOTE (Darren @ Jun 3 2009, 06:08 PM)

My first blog post on scripting:

Weekly Scripting Nuggets ... ?

[Darren]

QUOTE (asbo @ Jun 3 2009, 07:43 PM)

Weekly Scripting Nuggets ... ?

Heh, maybe. We'll see what my time availability looks like in the coming weeks. Don't forget I have to come up with Weekly Normal Nuggets, too. And I should probably figure out here pretty soon what I'm going to present at NI Week.

-D

[Jim Kring]

QUOTE (Darren @ Jun 3 2009, 07:17 PM)

And I should probably figure out here pretty soon what I'm going to present at NI Week.

I vote for a presentation on scripting :thumbup: