XYplorer Beta Club

Posted: **18 Mar 2015 16:56**

irresistible

Posted: **19 Mar 2015 16:47**

Thanks Don!

This one might not be so easy...

It would be nice if releaseglobals accepted a second parameter to make it possible to remove variables with names matching a specified pattern.

With this scripts could perform better cleanup of dereferenced variables. For example:

Code: Select all

$permPrefix = '$P_LAYOUT_';

// Create perm vars for the layout options
foreach ($opt, setlayout(), ',') {
  $var = $permPrefix . GetToken($opt, 1, '=');
  perm *$var = GetToken($opt, 2, '=');
}

// do stuff with them.

// Cleanup.
releaseglobals 2, $permPrefix . '*';

This is much better than the alternatives of:
1) Keeping track of all variables created in the foreach loop within a separate permanent variable.
Not terrible but not very elegant either. Your first instinct is to create a list of names then loop over it, but you're often better off creating a script of unset $var; commands so that you can clean it up in a single call. Plus you have one more variable that needs cleaned.

2) In this particular instance I could essentially repeat the creation loop for destruction.
This is a bunch more code and is not reliable if run from a different version of XY than the creation since the options available from setlayout may have changed.

Code: Select all

    + SC releaseglobals enhanced: The new parameter 'pattern' makes it
      possible to release only those variables with specific names:
      Syntax: releaseglobals [flags=3], [pattern=*]
        pattern: Name pattern of variables to release.
                 Supports wildcards, but does not surround non-wildcard
                 containing patterns automatically.
                 (ie 'FOO' is not treated as '*FOO*')
                 Defaults to '*' to match all.
      Examples:
        // These are all equivalent &
        // release all global & permanent variables
        releaseglobals;
        releaseglobals , '*';
        releaseglobals 3, '*';

        // Release all global & permanent variables containing 'FOO':
        releaseglobals , '*FOO*';

        // Release permanent variables starting with '$P_FOO_':
        releaseglobals 2, '$P_FOO_*';

        // Release all global variables ending with '_OLD':
        releaseglobals 1, '*_OLD';

If only I could provide the code as well...

Posted: **20 Mar 2015 01:33**

Oh - now I'm a bit mixed up

There is ReleaseGlobals (currently for *all* Globals / Perms), and there is UnSet, for explicit names.
Doesn't UnSet with explicit names do what ReleaseGlobals does for all Globals?

So, if Don would expand UnSet for generic names,
Unset $P_FOO_*;
would do what you want? Or is there a difference?

1) if OK: I'd say +1
2) syntax of UnSet shows that the variable name "is a variable", i.e. unquoted
3) at least for this generic form ($name*) I'd have some use. I'd not need the "more flexible" forms like *FOO*

Posted: **23 Mar 2015 11:57**

Currently, when running multiple commands as part of a script, status bar reflects only the time taken to execute the latest command. I would like to see some kind of "encapsulation" switch that would show the total time taken to perform the task end to end.

Case in point: I have a CTB that runs a report dump of my external drives. I am not particularly interested in how long each dump takes -- since the status bar info is constantly changing -- but the total time taken is a figure that I would like to see at the end.

Posted: **23 Mar 2015 13:26**

zer0 wrote:Currently, when running multiple commands as part of a script, status bar reflects only the time taken to execute the latest command. I would like to see some kind of "encapsulation" switch that would show the total time taken to perform the task end to end.

Case in point: I have a CTB that runs a report dump of my external drives. I am not particularly interested in how long each dump takes -- since the status bar info is constantly changing -- but the total time taken is a figure that I would like to see at the end.

You can do yourself:

Code: Select all

   $time0 = <date yyyy-mm-dd hh:mm:ss.fff>;
 ... commands you want to measure
   $time1 = <date yyyy-mm-dd hh:mm:ss.fff>;
   $timed1 = DateDifF($time0, $time1, 'ms'); // calculate time in msec

Posted: **23 Mar 2015 13:36**

I'd recommend using:

Code: Select all

   $time0 = now('msecs');
 ... commands you want to measure
   $time1 = now('msecs');
   $timed1 = $time1 - $time0;

If only because DateDiff doesn't always act as one might expect.

Posted: **23 Mar 2015 15:21**

Thanks chaps. I know that timing at the start and end is a workaround, but I was hoping for a more logical change, such prefixing a block of code with an identifier that specifies how its execution time should be displayed.

Posted: **23 Mar 2015 15:26**

zer0 wrote:Thanks chaps. I know that timing at the start and end is a workaround, but I was hoping for a more logical change, such prefixing a block of code with an identifier that specifies how its execution time should be displayed.

What's the actual code that is causing multiple updates to the status bar?

Posted: **23 Mar 2015 15:37**

TheQwerty wrote:
zer0 wrote:Thanks chaps. I know that timing at the start and end is a workaround, but I was hoping for a more logical change, such prefixing a block of code with an identifier that specifies how its execution time should be displayed.
What's the actual code that is causing multiple updates to the status bar?

Several sequential folderreport() with dump switch. It shows traversal of the file system of each location and then finishes with how long it took. Therefore, the only data I really get is how long it took to do a report on the last place in the list.

Posted: **23 Mar 2015 16:01**

zer0 wrote:Several sequential folderreport() with dump switch. It shows traversal of the file system of each location and then finishes with how long it took. Therefore, the only data I really get is how long it took to do a report on the last place in the list.

I don't think it's going to be easy for Don to just add a command to collate the status bar updates into a single update to show the total time, because it is code called by folderreport that is updating the status bar and not the code actually executing the script commands.

What if the folderreport accepted a list of folders instead of just a single one and then reported on the total time taken? Would that be agreeable or are your calls to folderreport different enough that this could not work?

Posted: **23 Mar 2015 17:09**

TheQwerty wrote:What if the folderreport accepted a list of folders instead of just a single one and then reported on the total time taken? Would that be agreeable or are your calls to folderreport different enough that this could not work?

Well, each folderreport is for a different drive and writes a report into a text file that's named according to the location being reported on. If respective pairs of "folder" and "outputfile" can be maintained then

If not then

Posted: **23 Mar 2015 20:50**

TheQwerty wrote:I'd recommend using:
Code: Select all
   $time0 = now('msecs');
 ... commands you want to measure
   $time1 = now('msecs');
   $timed1 = $time1 - $time0;
If only because DateDiff doesn't always act as one might expect.

If I got it right DateDiff() could show a difference of 1ms on my example?

But: all expressions you used are much cleaner than in my example!

It seems to show 2 points:
1) I shouldn't just use the first solution I find

2) if I can get a result by function [here: now()] I should prefer it in stead of using of a <...> variable

[Point 2 we had short ago with <get ...> and get(...)

]

Now() being able to directly return msec (no DateDiff needed!) is cream on the cake

My problem: too many functions and variables, and not enough scripting to know them all

(No: I do not want to miss them!

)

(Enough emoticons, I think.)

Posted: **21 Apr 2015 10:48**

While doing this (http://www.xyplorer.com/xyfc/viewtopic.php?f=7&t=13822), I missed the absence of the null.

Can you introduce a null value that evaluates to true emptiness and not just an empty string?

Because ::$c = Null; getpathcomponent(<curpath>,$c,); is not the same as ::$c = '';/*or set $c;*/ getpathcomponent(<curpath>,$c,);

Posted: **21 Apr 2015 11:07**

No, I don't see a way to do that.

Posted: **21 Apr 2015 11:58**

SammaySarkar wrote:While doing this (http://www.xyplorer.com/xyfc/viewtopic.php?f=7&t=13822), I missed the absence of the null.

Can you introduce a null value that evaluates to true emptiness and not just an empty string?

Because ::$c = Null; getpathcomponent(<curpath>,$c,); is not the same as ::$c = '';/*or set $c;*/ getpathcomponent(<curpath>,$c,);

Beg your pardon, but: $c=Null; is wrong syntax, it must be $c='Null';

Though I'm not convinced it does what you want it to?
(Sure: $c='Null'; is not $c=""; - but what should it be??)

And I think it's not really neccessary as long as you can express the meaning of a non-specified operand by supplying the default value for this operand:

Code: Select all

 $a = func('');   // func uses ''
 $a = func();       // func uses 'dflt'
 $a = func('dflt');   // func uses 'dflt'
 $a = func('dings');   // func uses 'dings'

Function func( $p='dflt') {Echo $p;}

For GetPathComponent(): 2nd operand omitted = 2nd operand = 'path'.

XYplorer Beta Club

Minor scripting related wishes (a generic thread)

Re: Minor scripting related wishes (a generic thread)

Re: Minor scripting related wishes (a generic thread)

Re: Minor scripting related wishes (a generic thread)

Re: Minor scripting related wishes (a generic thread)

Re: Minor scripting related wishes (a generic thread)

Re: Minor scripting related wishes (a generic thread)

Re: Minor scripting related wishes (a generic thread)

Re: Minor scripting related wishes (a generic thread)

Re: Minor scripting related wishes (a generic thread)

Re: Minor scripting related wishes (a generic thread)

Re: Minor scripting related wishes (a generic thread)

Re: Minor scripting related wishes (a generic thread)

Re: Minor scripting related wishes (a generic thread)

Re: Minor scripting related wishes (a generic thread)

Re: Minor scripting related wishes (a generic thread)