I've been looking around.
storeEval does not exist anymore.
Commands 'runScript' & 'executeScript' seem to replace it.
However, the syntax proposed in many posts javascript{script here} is not accepted: it refuses the first {. Same for the variables with the storeVars['foo'] which seems to be replaced by ${foo}.
Trying any javascript expression (even very simple) with both commands gets me a message 'Failed: missing ) after argument list'.
For instance: | run Script | "aString" + ${previouslyStoredVar} | outputVar |
(note: the syntax of the command seems to be 'runScript', but appears as 'run script' in the IDE window).
I tried adding a return(expression), putting brackets around the expression, enclosing ${previouslyStoredVar} in double quotes, trying with an even simpler expression, and everything I could think of, but with always the same error message.
What is it I am doing wrong? It must be obvious but I can't figure it out!
Many thanks,
E.
My bad: just tried with 'return ${price_string}.substr(0, 5)' and it works. Have to find out why the other commands were not working. I'll dig and report!
OK, the pb remain but is quite different from my exepectation. The exact same expression and the same context works in a second test, but fails in the first test (with the missing parenthesis message). Seems to be a bug in the IDE then, or a corruption of some sort of the Selenium script...
Related
In my previous questions here on stack we determined my command should run like this.
(& C:\Gyb\Gyb.exe --email $DestinationGYB --action restore --local-folder $GYBFolder --label-restored $GYBLabel --service-account)
The problem with this is if I run that same command in a command prompt I would see a bunch of status information.
When I run the command as above all I see in VSCode is it ran that line and its waiting. How can I make it show me like the command prompt without opening a new window?
here is GYB
https://github.com/jay0lee/got-your-back
Remove the parentheses () around your command if you want to see the output at the same time. Otherwise, this behavior is expected and is not unique to the VSCode terminal.
The group-expression operator () is used to control the order of which code is executed in PowerShell. Expressions are evaluated like order of operations (re: PEMDAS) in Mathematics, the inner-most parentheses get evaluated first. You can also use the group-expression operator to invoke a property or method from the returned expression in the group.
The problem is, group-expressions don't output to the parent level directly, that only happens when the group-expression is done executing. So when you have something that can run for several minutes or even hours like gyb.exe, you don't see that output until the command exits and execution continues.
Contrast this to running outside of the group-expression; as STDOUT is written to the success stream the success stream is immediately written to console as it comes. There is no additional mechanism you are proxying your output through.
Note: You will experience nearly the same behavior with the sub-expression operator $() as well, although do not conflate sub-expressions and group-expressions as they serve different purposes. Here is a link to the official explanation of theGrouping Operator ( ), the Subexpression Operator `$( ) is explained immediately below it.
I'm sure I must be missing something really basic but I've been revisiting Powershell of late to get up to speed with 7.1 and can't seem to get it to tell me where an error is thrown, either in VSCode or ISE.
In the above from VSCode (same report in ISE) the error isn't on that line, it's a couple of levels deeper in a function called by CompareFiles, but it always seems to report the caller of the caller of the code which has failed, rather than the actual failing line.
I've searched here, there and everywhere and found lots of clever tweaks and debugging ideas which I could add but I don't understand why it doesn't just give me the failing line here, rather than a line a level or two up in the call stack. It's as if the CompareFiles function has some kind of pragma that says "Dont record debugging info for me or anything I call" but it hasn't (and that probably doesn't exist anyway!).
I can't help feeling I've just not set some obvious debug setting, or set one incorrectly while I've been tinkering.
If it makes a difference, I'm calling a PS module from a PS Script, the module is loaded fine from the PSPath via Import-Module, and the line being reported is in the module, as is the actual failing line (both are in the same module), so it's not some problem where it's only debugging the script and not the module.
Both the script and the module have the below at the top;
Set-StrictMode -Version Latest
$ErrorActionPreference = "Stop"
As I say, I get an identical error when I use the ISE so it's not a VSCode setting.
Debugging line by line works fine, so I can step through to find the failing line but surely it should just pop up and tell me.
[Later] I should not it's not just this error, it's been like that for days with all sorts of runtime errors with this and other scripts.
Silly me - I simply removed..
$ErrorActionPreference = "Stop"
..from the script and the module, this was essentially implementing the imaginary pragma I mentioned. I removed it and now get the failing error line.
I probably only need it at one of the two levels if anywhere but error handling works just fine without it, so have removed it everywhere, perhaps I'll look into what it does properly at some point.
Serves me right for adding something blindly because it sounded good, i.e. "Sure, I want it to stop when there's an error, why wouldn't I ? - I'll add that statement then" and not re-testing or looking further into it.
I'm trying to write a custom problem matcher for VS Code. My matcher matches nothing, even though testing the regular expressions on the output seem to work. I'm not even sure VS Code loads my problem matcher, let alone see which regular expression matches and which isn't.
Is there a way to debug a problem matcher? I'm basically stuck with no way to move forward.
This is an old question, but I found this site super helpful:
https://regex101.com/
It allows you to debug regular expressions. You can put an example line of compiler output and try your matcher against it.
One issue I had to figure out is that the VS Code expression is stored in a JSON file, so it has extra escape characters that should be removed if you're using the regex somewhere else.
Environment: Linux CentOS 7 #HPC
Interface: command interface, no GUI
My PERL scripts have a logic error. It does not go through in a "foreach" loop. I use debugger command below:
perl -d /scripts_location/perlscripts.pl
However, it is run step by step. My scripts have almost thousand lines. Here is my questions:
How to debug my scripts from specific line?
How to figure out the loop cannot be run? And why the loop cannot be run?
Is there any resource to show debugger skills in a whole process?
I searched online. Most of them explain the commands. But few introduce the debug from the very beginning. I mean that first a simple program is given, set breakpoint or other label in the program, check output or trace error, and so on. After viewing websites, I am unable to know how to start debugging using PERL debugger. I used to debugging my program using output at specific lines to check the output is correct or not. However, current logic error cannot be figured out in this way.
Any further suggestion and help would be highly appreciated.
After starting the debugger, you can tell it to continue until it reaches a given line, e.g.
c 124
To figure out why a foreach loop isn't entered, check the loop's list before entering it. You can tell the debugger to evaluate the expression like this:
x #values
if the loop is something like foreach my $value (#values). It will probably tell you
empty array
To discover why the array is emtpy, you can try to "watch" the array
w #values
and then run the script with r. It will stop once any watched value changes.
Use h to view the help.
I'm new to scripting Minitab 17 and have run into a snag that I can't find any documentation for, including an error message that brings up no hits on Google. All I want to do is generate macros that perform simple nonlinear regressions automatically, all of which execute just fine in the GUI or through Session Commmands. If I follow the directions on p. 10 of the Minitab Macros documentation and copy the commands I've successfully run from the
Project Manager/History folder, copy them into a .MAC file and surround them with GMACRO and ENDMACRO commands, I end up with the code below:
GMACRO
NLinear;
Response 'MyColumn1';
Continuous 'MyOtherColumn2';
Parameter "Theta1" 0.5;
Parameter "Theta2" 0.2;
Expectation Theta1 * ln (MyOtherColumn2 - Theta2 );
NoDefault;
TMethod;
TStarting;
TConstraints;
TEquation;
TParameters;
TSummary;
TPredictions.
ENDMACRO
The code between the MACRO statements runs OK from the GUI or as a Session Command. When I run the resulting macro file from the session prompt in Minitab, however, I invariably receive the following error: "Arguments not allowed in all global macro mode." I also receive syntax errors for every column that includes quote marks, even though that is standard session window syntax; I can eliminate these by substituting the column heading from my open worksheet, such as "C1", but can't get past the other error.
I'm obviously using some kind of incorrect syntax element(s) but can't pin them down - does anyone have any ideas? There are plenty of instructional materials on Minitab macros on the Web, but I haven't yet encountered any that deal with either this particular error or that delve much into how to execute ordinary Minitab tests of this kind. My goal is merely to write batch files that will do all my nonlinear regressions on off-hours etc. Thanks in advance.
Re-read pages 10-11 of http://support.minitab.com/en-us/minitab/18/macros-help/#page10.
The line after GMACRO should be the name of the macro, not a command.
Also, note that in a global macro the column names in 'single quotes' must exist in the active worksheet.
the better way to learn Minitab macro is to do the job by the menu and then to go to the SESSION WINDOW and to look at how Minitab uses the function.
Do your Nonlinear Regression with your data and then in the SESSION WINDOW (first icon of the Project Manager bar) you will see the code. After that it is more easy to do macro.
In this case I think about an issue I had sometimes: I don't know why but sometimes I had to switch the regional setting ('.' instead of ',' for numeric values) or to write ',' instead of ';' in the macro.
You can try this.