Misc Scripting Stuff

[jacky]

Couple of quick things :

1. you know how you added the line on the popup when there's a problem in a script? Would be nice to add at least the script's name/label, cause when that occurs from a script file with a few sub/load's, well then "line 3" don't really mean much, since there are so many of them!

2. One thing I find rather annoying regarding how statusbar works right now, consider this script:

Code: Select all

  new "foobar", file;
  status "file created";

In my view, it should first create a file "foobar" and then shows a message in statusbar that says "file created", and that's it. This kind of things can very useful to do something and then provide feedback, which is why I put the status call after (in case the command's action does affect the statusbar, directly or through Auto-Refresh), yet at the moment it "doesn't work".

What I mean is, the "file created" is indeed shown on statusbar, but right after it goes away being replaced by the file's name. At first I thought it was due to AR, and in a script of mine I do disable AR at first only so that status messages are shown after file creation/timestamping and it does work on that case, but even if I Suspend AR before running the script above, it doesn't changes a thing : the "file created" message goes away at the end of script execution!

Might be linked to the current item being changed or something, I don't know, but if that thing could be "fixed", it would be great, IMHO.

[graham]

at last i can understand this Most times your bug finding skills are amazing!

Enough flattery, I use the statusbar alot, just old habit of reporting steps, and maybe a scripting command to pause nnnn may be an answer here so that any results from XY get done first. It can be very confusing as it stands.

[admin]

1. location in script popup: difficult; I'd rather do a better info box later. For now I remove that "Line #" because indeed it's rather misleading most of the time.

2. status: yes, I could fix that one.

[jacky]

1. location in script popup: difficult; I'd rather do a better info box later. For now I remove that "Line #" because indeed it's rather misleading most of the time.

hmm.. is it, really? Because if I had a "?" before some command in the middle of a script, or use step, then it says the name/label of the script (Script _scriptName), so (I assumed) it is already known, and you could just add that before the line number, no?

2. status: yes, I could fix that one.

Yep, thanks!

[admin]

1. location in script popup: difficult; I'd rather do a better info box later. For now I remove that "Line #" because indeed it's rather misleading most of the time.

hmm.. is it, really? Because if I had a "?" before some command in the middle of a script, or use step, then it says the name/label of the script (Script _scriptName), so (I assumed) it is already known, and you could just add that before the line number, no?

But the Line Number is relative to the script, not to the file (which can contain many scripts). So "Line 1" could refer to line 17 in the XYS file. That would be confusing. I nowhere keep track of the actual line number of a script command in the file because it's totally irrelevant for the logic.

PS: okay I can skip the line number and simply show "File" (if any) and "Command". That's good.

[jacky]

But the Line Number is relative to the script, not to the file (which can contain many scripts). So "Line 1" could refer to line 17 in the XYS file. That would be confusing. I nowhere keep track of the actual line number of a script command in the file because it's totally irrelevant for the logic.

PS: okay I can skip the line number and simply show "File" (if any) and "Command". That's good.

Well yeah, but - at least in my mind - it would be even better and make sense to say "Line 17 @ Script _someScript". Sure it's not line 17 of the actual script file, but as long as that is clear it's a sure way to know what line is the one.

Because giving the command line, well (a) there could be more than one line of the same in a script file, and (b) it's might not be that easy to locate. On the other hand, Line 17 of "_someScript" in MyScript.xys is : it means that if line 42 of MyScript.xys is "_someScript" then 42+17=59, so line 59 in the XYS file is the one I'm after.

It's not a number that doesn't mean nothing, it does in relation to the script name/label, and since you can't/shouldn't have two scripts sharing one, that's, to me, a pretty good way to identify any given line.

I know it's not much, but since all the info are already know to you, why not show them? For "large" XYS containing many scripts, it might be quite useful to have an actual (even if indirect) line number...

[TheQwerty]

I somehow missed this discussion, so here's my two cents probably far too late.

Why not just display a slightly modified version of the stepping dialog?
Then you get the details about the sub-script the error occurred in, the line that caused the error, and the context of that line.

[admin]

I somehow missed this discussion, so here's my two cents probably far too late.

Why not just display a slightly modified version of the stepping dialog?
Then you get the details about the sub-script the error occurred in, the line that caused the error, and the context of that line.

Yes, yes, yes. I kind of had this in my back-head (uh?) but was not ready to get it into the cerebral production zone short before publication of 7.60.

[TheQwerty]

I somehow missed this discussion, so here's my two cents probably far too late.

Why not just display a slightly modified version of the stepping dialog?
Then you get the details about the sub-script the error occurred in, the line that caused the error, and the context of that line.

Yes, yes, yes. I kind of had this in my back-head (uh?) but was not ready to get it into the cerebral production zone short before publication of 7.60.

Yep, completely understandable. Was just surprised it hadn't been mentioned that that dialog is pretty near perfect for this.

[jacky]

Little thing maybe, but in a few scripts I do use the clipboard as "temporary holder" since we have no global vars, and I do wish that I could use copytext without having any feedback on statusbar, because it's most of the times completely useless anyway (i.e. don't mean nothing), and it removes my own (and meaningful ) status messages.

I usually put a status after a copytext, but it's really not the same, so if it was possible to have a quick extra option or something not to have statusbar feedback, that'd be nice Would also be nice when using the "To Clipboard" commands, and BTW what would be even better is a way to use those directly into a variable, not using the clipboard at all ! I'm guessing I'm asking for that getinfo you mentioned not long ago...

[admin]

Little thing maybe, but in a few scripts I do use the clipboard as "temporary holder" since we have no global vars, and I do wish that I could use copytext without having any feedback on statusbar, because it's most of the times completely useless anyway (i.e. don't mean nothing), and it removes my own (and meaningful ) status messages.

I usually put a status after a copytext, but it's really not the same, so if it was possible to have a quick extra option or something not to have statusbar feedback, that'd be nice Would also be nice when using the "To Clipboard" commands, and BTW what would be even better is a way to use those directly into a variable, not using the clipboard at all ! I'm guessing I'm asking for that getinfo you mentioned not long ago...

Difficult.

I'd rather add global vars. Any idea about how global and long-living you want them? (Sorry for simply asking stupid questions but I have not much time for scripting so I rather ask the expert... ).

[PeterH]

To your questions - my point of view:

- "how global"? I'd say for use in current XY. (Do you know what I mean?)
- "live how long"? From definition till end of XY. (Or, maybe, till explicitely "undefined" or "freed".)

I think main usage is to store some value for reference in another / a later script - so global var should keep it's value from script to script.
But if you need a value for days and over YX-sessions, I think you should save it to an .ini file.

But: how to define a var as global? By a global command?

Code: Select all

$a = 'one';
globalv $a, $b;  // defines list of varnames as global
$a = 'two';

hoops - we lost the first value?

Other version:

Code: Select all

$a = 'one';
globalput $a; // copies value of local $a to global $a
... now we can use (local) $a as we want. But:
globalget $a; // copies value of global to local $a,
 // but doesn't destroy value of global $a
globaldrop $a; // frees global var $a

Each command should allow a list of variables.

[jacky]

Difficult.

You mean copytext without feedback, and/or getinfo ? Cause the later would still be a nice useful addition...

I'd rather add global vars. Any idea about how global and long-living you want them? (Sorry for simply asking stupid questions but I have not much time for scripting so I rather ask the expert... ).

But yeah, sure, global vars would be great, and no need for copytext then! (and I vote for global vars first over getinfo, absolutely)

As for global vars, I'm not sure exactly what the options would be, or how it would work, but seems to me a global var should be "available" to all scripts from the current batch execution and live until the whole thing is over, so in that department it would be much like how setting(p) work now.

I guess it should it work as in PHP, so everything works like today and all variables are restricted to the current script only, and a new command "global" would be added, which could be used much like in PHP, to make a var global, so we get its value from any previous declaration if any, and changing its value will have impact on other scripts, according that they too made this variable global of course.

I was thinking maybe global vars should only be available to scripts within the current/same "source" (e.g. script file, ...), so when one script loads another script file, there would be two sets of global vars, one per "source". But at the same time, "fully global" variables could be useful as well...

If both were possible (e.g. with an optional param for global or a prefix to the var name), then that'd be my choice, obviously. If only one could be done, then "fully global" vars are more common & better, so I'd vote for that.

[PeterH]

I was thinking maybe global vars should only be available to scripts within the current/same "source" (e.g. script file, ...), so when one script loads another script file, there would be two sets of global vars, one per "source". But at the same time, "fully global" variables could be useful as well...

I think global vars shared over several independent scripts are essential. But there could be a modifier on defining a global var, requesting to free it at the end of the "current" script?

And another thing: for debugging the need for a command to display all names (and maybe values) of all currently defined global variables...

[TheQwerty]

I'd say global vars should live for the instance of XY.

Off hand I can think of 3 ways that I wouldn't find too bad to work with..

In no particular order:
1) We have $var already, so let's say those are local variables, but let's add a new prefix character that signifies a variable is global. Thus we could have $var = local and say &var = global.

2) Adapt Set() to have an additional argument to make the supplied variable global, but we'd need a decent way to use this without having to do Set($var, $var, g);

3) Add Global(var1, .., varN); to make the supplied vars global. Set() and UnSet() would still work on the vars, so to kill a global var you'd have to UnSet() it.