Mathscript 2009 Problems and Feedback

[geirove]

Hello,

It is evident that being able to debug Textual code in LV 2009 is powerful. My company is developing a system that computes estimated curing time for Hollow Slab Concret. Mathscript is *potentially* very powerful in these math intensive applications.

However, I have encountered quite a few rough edges in the current implementation.

Running LV 2009 with the F3 upgrade, but not the service Pack 1 release. (Can it be installed after the F3 upgrade, should the F3 upgrade also be installed after the Service Pack 1 release ?) under Windows XP service pack 2.

Here are some of the problems I have encountered afer just a few days use of ms: 

1) Mathscript Window terminates LV  (with no message !) for no appearant reason every now and then

2) The script pane in the Mathscript Window remembers the last "saved to" file even after executing "file new"

     "Save" will then accidently overwrite the last save .m file instead of asking for a new file !

3) Subfunctions are not recognized in user defined mathscript function: I have checked and double checked the syntax to no avail.

4)  When you double click a .m file in the Project Explorer, it brings up an editor. However, editing the .m file  in this editor leads to the script not being executable: If Iopen the file in a Text Editor, some Package(** ** ) text is added at the top.

5) Probably not a bug, but a **big** let down: It is NOT possible to debug user defined .m files !

    Why don't the debugger simply (:-) ) wrap the .m file in a Mathscript Node while that can be debugge?

When will we have debug features of custom .m files: After all, that is what text based programming is all about: Functions calling functions!

[GrantM]

Hello Geir,

Thank you for some great MathScript feedback.  As for your question about 2009f3 versus 2009 SP1, the 2009 SP1 update will include all the fixes in 2009f3.  To respond to your feedback:

1) I have not observed the MathScript window terminating LabVIEW.  If you could provide information about how to reproduce this, it would be great.  Step-by-step instructions would be best, but if it's not always reproducible, then a description of what you're doing would also help (e.g. editing and running a large text file, viewing a graph of a large dataset, copying previous commands from the history window, etc.)

2) We are making improvements to the MathScript Window for the 2010 release.  I will file a bug report for this issue so we can try to address it.

3) Subfunctions indeed seem to be broken in 2009, but only in the MathScript Window.  This has been fixed in SP1 of MathScript.

4) Double-clicking a .m file in the Project Explorer will launch whatever editor is configured on your system for .m files.  Try verifying that the editor used when you double-click is applicable for editing textual files.

5) Debugging .m files is indeed an issue we are aware of.  However, I don't know when we will provide this functionality.

Grant M.
Senior Software Engineer | LabVIEW MathScript | National Instruments

[geirove]

---

GrantM wrote:
Hello Geir,

Thank you for some great MathScript feedback.  As for your question about 2009f3 versus 2009 SP1, the 2009 SP1 update will include all the fixes in 2009f3.  To respond to your feedback:

1) I have not observed the MathScript window terminating LabVIEW.  If you could provide information about how to reproduce this, it would be great.  Step-by-step instructions would be best, but if it's not always reproducible, then a description of what you're doing would also help (e.g. editing and running a large text file, viewing a graph of a large dataset, copying previous commands from the history window, etc.)

2) We are making improvements to the MathScript Window for the 2010 release.  I will file a bug report for this issue so we can try to address it.

3) Subfunctions indeed seem to be broken in 2009, but only in the MathScript Window.  This has been fixed in SP1 of MathScript.

4) Double-clicking a .m file in the Project Explorer will launch whatever editor is configured on your system for .m files.  Try verifying that the editor used when you double-click is applicable for editing textual files.

5) Debugging .m files is indeed an issue we are aware of.  However, I don't know when we will provide this functionality.
Grant M.
Senior Software Engineer | LabVIEW MathScript | National Instruments

---

Hello Grant,

Thanks! A kudos or two in this kudos driven environment would be nice when providing helpful feedback 🙂

I do not know how to reproduce the MathScrpt Window crash. It happens only when the MS Window is open, I have executed a function, and then change the function in an external editor that I use (TextPad).

Double clicking .m files: My fault: I have another program that was registered for .m files that opened it in an editor: I thought this was a LV MS editor !

Great that the subfunction bug is fixed !

I have another MS bug for you: Setting the MS Search Path does not work as expected:

I have created the attached user .m files for logging purposes:

I execute log_clear at the begining of a program, and log_write(message) when I want to log messages.

I keep an editor open on the log file: The editor refreshes whenever the log file changes.

If I want to disable  logging, I have no-op versions in a sub folder of the original log_clear and log_write files.

To disable  logging, I simply point my MS Search Path for my target (My Computer) to the folder with the no-op versions that do nothing!

This works well, apart from the following MS Problems and Bugs

Bug: Even though I add MS Search Path to the folder with the no-op versions of the log file before the path to the versions that do write, MS Script Nodes continue to call the original version. I removed the path to the logging version, and only added path to the folder that has the no-op versions: MS continues to use the versions of log_write and log_clear that operates on files.

In short: It seems like MS caches the versions some place, and don't care about the search path. 

MS Problem: Exteremely slow File Writes: The logging wold be great, but the file writes with only a few bytes of text is extremely slow !

Lastly: I do hope debugging user .m files finds its way into 2010 version !

[geirove]

Hello,

Updates on the Search Path Bug:

This is for LV 2009 with the F3 patch installed. Haven't had time to install SP 1 yet.

To reiterate: I have two versions of the log_clear and log_write scripts placed in folders like this:

Folder:

\mathscript\                       contains log_clear and log_write that does the actual job

Folder:

\mathscript\no-op_log\      contains log_clear and log_write that does nothing !

In the ** mathscript window **,  I have added search paths as follows:

\mathscript\  

\mathscript\no-op_log\

When this is the case and I call log_write('message') , a message is written to the log as expected.

If I change the order of the search path as follows:

\mathscript\no-op_log\

\mathscript\  

log_write('message')  does nothing as expected.

So, for the mathscript window, the search path settings works as expected!

However, with the "My Computer" Target in the Project Explorer, this does NOT work !

When LV has linked a version of e.g. the no-op version of the log_write m file to a VI, it is stubborn and keeps this reference even though the search path indicates that it is the other version that should be used.

I had to physically rename  the folder no-op_log to get LV to link in the version on the  \mathscript\  folder again.

Can NI please acknowledge that this bug is recorded and will be fixed ?

Message Edited by geirove on 02-18-2010 06:57 AM

[geirove]

Update,

Search Path bug is unfortunately still present in LV 2009 SP 1 Release!

[geirove]

Hello NI,

Grant, where did you go?

Would be nice to get a Time Schedule for fixing the Mathscript bugs! One my projects are actively using it, and it is a great add on, but unfortunately many rough edges !

I have discovered more problems, but before using time presenting them, I need to know that someone is listening !!

So, hello, where did you go?

[GrantM]

Hello Geir,

The behavior you see regarding to linking to the .m files is by design.  Let me explain.  LabVIEW MathScript has two operating modes for performance.  The MathScript Window and any MathScript node containing yellow warning glyphs operate in a slower performance mode.  The reason they are slower is they have to do a lot of work at run-time in order to determine which function to call.  This includes searching the search path and is why you see the behavior you expect.

In a MathScript node without a warning glyph, we can do all the analysis at compile time and achieve much greater run-time performance.  In order to understand why we chose different behavior for the node, think of your .m file like a subVI.  When LabVIEW searches for a subVI, it first looks in memory.  You cannot have two subVIs with the same name in memory at the same time.  The same is true for .m files.  Thus, when your search path is set to find the actual logging files first (and because your node does not have a warning glyph), we query the MathScript search path to find the .m files.  We find them in the regular directory.  Now, if you change the search path order with the node still in memory, MathScript will continue to use the .m file it previously found (just like a subVI).

So, again, why did we choose this behavior?  The real issue is sharing your VIs with colleagues or even moving them around on your system.  It would be annoying if every time you sent some VIs to a co-worker, he would have to set the MathScript search path on his system before being able to run the VI.  So, MathScript will remember the location of any .m files it used.  This way, the VI can open and run on a co-worker's system without any effort.  If MathScript cannot find a .m file where it remembers it to be, then it will try searching for it again.  This explains why you can get the expected behavior after you rename the no-op directory.

You can still get the behavior you describe in the node by using a function that causes a warning glyph.  For example, add a line to the top of your MathScript node that sets the path to the no-op directory:
path('path/to/no-op', path)
Comment out this path line when you wish to use the actual logging functions.  The caveat is that the MathScript node will run much slower with a warning glyph.  A much faster solution would be to use LabVIEW to control the logging.  Since you may have many nodes, pass around a LabVIEW boolean to each VI and input it to the MathScript node.  If your boolean is called msLog, simply construct your logging statements as follows:
if msLog
   log_write(message);
end
This way, you can control the logging at your top-level VI with a single value.

As for a timeline to fix the bugs, it is difficult to say definitively when they will be fixed.  I have not observed the problem with the MathScript window terminating LabVIEW.  We will investigate it.  For the script editor saving issue, we hope to fix this for the 2010 release.  The subfunction problem is fixed in 2009 SP1.  Debugging .m files is not currently on the roadmap for the 2010 release, so I don't know when that functionality will be added.  Finally, the search path issue is not a bug as outlined above.

We are listening, so any further MathScript feedback will definitely be heard by us developers!

Grant M.
Senior Software Engineer | LabVIEW MathScript | National Instruments

[geirove]

My Answers inline:

 

---

GrantM wrote:
Hello Geir,

The behavior you see regarding to linking to the .m files is by design.  Let me explain.  LabVIEW MathScript has two operating modes for performance.  The MathScript Window and any MathScript node containing yellow warning glyphs operate in a slower performance mode.  The reason they are slower is they have to do a lot of work at run-time in order to determine which function to call.  This includes searching the search path and is why you see the behavior you expect.

May be by design, but there are several problems with it:

a) First of all, why have identical Search Path setups in the MS Window and in the Target when they do not behave in the same way?

b) I can see that LV links in the compiled .m files, but it does this in a very unfriendly way:

   -  The m files are obviously cached and stored in folder

      C:\Documents and Settings\<user name>\My Documents\LabVIEW Data\MathScriptVIs

      And has cryptic names like: MCStatic_151068744_1d73eb65f1eb41ded9f64955179aaf47.vi

      This is simply umanagable, because the very same names pop up in the Project Explorer's Dependencies list:

      So, if some .m files are missing (because of a search path change) , the cryptic names pop up in there !

      How do you resolve these dependencies? A user has no idea what it is !

     After a change of Search Paths, I ended up with a broken project, and was unable to ever recover whatever I set the search path to!

 

In a MathScript node without a warning glyph, we can do all the analysis at compile time and achieve much greater run-time performance.  In order to understand why we chose different behavior for the node, think of your .m file like a subVI.  When LabVIEW searches for a subVI, it first looks in memory.  You cannot have two subVIs with the same name in memory at the same time.  The same is true for .m files.  Thus, when your search path is set to find the actual logging files first (and because your node does not have a warning glyph), we query the MathScript search path to find the .m files.  We find them in the regular directory.  Now, if you change the search path order with the node still in memory, MathScript will continue to use the .m file it previously found (just like a subVI).

So, again, why did we choose this behavior?  The real issue is sharing your VIs with colleagues or even moving them around on your system.  It would be annoying if every time you sent some VIs to a co-worker, he would have to set the MathScript search path on his system before being able to run the VI.  So, MathScript will remember the location of any .m files it used.  This way, the VI can open and run on a co-worker's system without any effort.  If MathScript cannot find a .m file where it remembers it to be, then it will try searching for it again.  This explains why you can get the expected behavior after you rename the no-op directory.

 

See Comments  above

 

You can still get the behavior you describe in the node by using a function that causes a warning glyph.  For example, add a line to the top of your MathScript node that sets the path to the no-op directory:
path('path/to/no-op', path)
Comment out this path line when you wish to use the actual logging functions.  The caveat is that the MathScript node will run much slower with a warning glyph.  A much faster solution would be to use LabVIEW to control the logging.  Since you may have many nodes, pass around a LabVIEW boolean to each VI and input it to the MathScript node.  If your boolean is called msLog, simply construct your logging statements as follows:
if msLog
   log_write(message);
end
This way, you can control the logging at your top-level VI with a single value.

 

NO, I cannot use LV to control the loggin: I am doing the logging directly from my .m files: 

I have one VI that calls a feew .m files that again call other .m files: Since this is all formulas, it is better done in .m than in a VI. 

As for a timeline to fix the bugs, it is difficult to say definitively when they will be fixed.  I have not observed the problem with the MathScript window terminating LabVIEW.  We will investigate it. 

 

I keep a text editor open on my .m files: I terminate my project, and change .m files and then restart again and test the result of the change. First of all, LV is very very slow when doing this: Please look into getting the compile cycle faster.

I have stopped changing my search path, and since I have done this, I haven't seen LV quit or crash. But if you play around with changing the Search path LV will simply disappear from the screen every no and then Windows 3.0 style...

 

For the script editor saving issue, we hope to fix this for the 2010 release.  The subfunction problem is fixed in 2009 SP1. 

What about the extremely slow writes to text files from mathscript? Any chance of getting this faster?

As it is now, I cannot use it for logging, it is way to slow!

Please come up with a simple Global Console to write to, like most Text based programming dev tools have.

Debugging .m files is not currently on the roadmap for the 2010 release, so I don't know when that functionality will be added.  Finally, the search path issue is not a bug as outlined above.

For true Textual Programming support, NI needs to add debugging of .m files!

 

We are listening, so any further MathScript feedback will definitely be heard by us developers!

Thanks a lot for this, I am working with MS every day now, so I will report my finidings.

 

Grant M.
Senior Software Engineer | LabVIEW MathScript | National Instruments

---

[geirove]

Hello

I have designed a couple of programming languages myself, and have a few ideas regarding the cryptic named VIs compiled from the .m files:

I understand their names have to be unique. But instead of using cryptic names, why not use names generated like this:

<m_filename>_<relative path>

where <relative path>  is the path to the .m file linked in according to the search path, assuming the search path must be realtive to the project root.

The relative path can be encoded with characters that are legal in filename.

I prefer to put the.m filename first, since this is what the user can relate to.

This way, even missing  .m files can be understood when reported in the Dependencies list.

ALso, the compiled .m files can be easily located in the directory where they are compiled if the need arises !

Another approach is of course to keep the cryptic names, but  map these to real .m file names in the Dependencies list: This should have been done in the first place !

Just my 2 cents.