I have an issue I can't solve regarding AHK. My code:
begin()
begin() {
Global Input
Gui, Add, Edit, vInput gInputChanged
}
InputChanged() {
MsgBox, Your input is %Input%
}
Simple enough, eh? However when InputChanged() is triggered the variable Input is never correct (it is always null).
Refer to Function Variables and Scope
Example:
Input := "Hello" ; Our Variable Defined outside of our Function
begin() ; Call the function passing no Variables
begin() {
Global Input
MsgBox, Global! Input = %Input%
InputChangedLocally(Input) ; Pass the Input variable which is 'Hello'
}
InputChangedLocally(Input) {
Input .= " World!" ; Change Local variable
MsgBox, Changed Locally %Input%
OnlyGlobalInput()
}
OnlyGlobalInput() {
Global Input
; Notice it is not 'Hello World!' even though we changed it above!
MsgBox, Global! Input = %Input%
InputNotPassedOrGlobal()
}
InputNotPassedOrGlobal() {
MsgBox, Your input is %Input% ; Blank as we never accessed any thing!
}
got the same problem, not figure out why this happen yet, but can use this workround
ControlGetText, TestCode2, Edit1,A
to get the input value
Related
The will phaser trait examples show this code:
our $h will enter { .rememberit() } will undo { .forgetit() };
Which is either misunderstood or simply not a real use case. If it's misunderstood, I would say it enters the block with it's assigned a variable. If it's not a real use case, it calls a method on an undefined variable. This is what seems to happen:
our &doing-good will enter {
say( "running" );
if Backtrace.new.grep: { .subname ~~ /bad/ } {
fail("Not authorized to call this");
}
};
This is simply run when the definition is made, that is, when what exactly is entered? The MAIN scope?
This is probably the documentation fault. It's very likely that phaser traits can't really be applied to variables, but above, when it's actually a block, it's not really run; the "phaser" is run when something that's totally independent of the variable definition of value happens, at least in this case. Any idea?
The "phaser traits" as you call them, will be run at the same time as other phasers of the same name.
The will trait on a variable basically sets up phasers in its surrounding scope, with the variable passed as the only positional parameter. So
my $h will enter { dd $_ };
is functionally equivalent to:
my $h;
ENTER { dd $h }
In your example:
our &doing-good will enter { ... }
you are defining a variable &doing-good that will be passed to the block that is specified. In your example, I do not see that variable getting initialized, so the block will receive a Callable type object (because that is what &doing-good will contain if it is not initialized).
My understanding is that the will trait is exactly the same as a the matching phaser – with the single difference that it has access to the variable as its topic. Thus the will enter and the ENTER below are very similar, and both execute when the containing scope is entered.
ENTER { note "ENTER phaser with topic $_.VAR.WHAT.raku()" }
my $a will enter { note "will enter with topic $_.VAR.WHAT.raku()"; $_ = 42 };
note 'main';
note "\$a: $a";
which prints:
ENTER phaser with topic Scalar
will enter with topic Scalar
main
$a: 42
Put differently, there's not a distinct "enter" phase that occurs for the variable; it's just referencing the ENTER phase of the containing scope.
I'm trying to do something like this
$SIG{ALRM} = sub {
print $line_number_when_alarm_went_off;
};
alarm 10;
# rest of the script
I'm using ALRM as an example, I will end up using a different signal to kill from the outside to trigger it. Is there a neat way of doing this sort of operation?
I have some slow scripts and sometimes I would like to send them a signal to know where the code is at that moment.
I want to make this as unobtrusive as possible so I could package it and add it to legacy code.
You can use caller in list context to get the package, file and line number of the place that the current sub got called from.
$SIG{ALRM} = sub {
my ($pkg, $file, $line) = caller;
CORE::say $line;
die;
};
alarm 2;
while (1) {
1;
}
This will output 11 (if I counted correctly, in my file it's 1740, and the $SIG line is 1730.
It also works with other signal handlers, like warn.
$SIG{__WARN__} = sub {
my ($pkg, $file, $line) = caller;
CORE::say $line;
};
warn 'foo';
This will output 7
Note that your code has a syntax error. You are assigning a hash reference as a signal handler, not a sub reference!
I see the following code in Perl 6:
await do for #files -> $file {
start {
#do something ... }
}
which runs in async mode.
Why does the above code need do? What is the purpose of do in Perl 6? Could someone please explain the above code in detail?
Also is there are an option to write something like this:
for #files -> $file {
start {
#do something ... }
}
and await after the code for the promises to be fulfilled?
The purpose of do
The for keyword can be used in two different ways:
1) As a stand-alone block statement:
for 1..5 { say $_ }
2) As a statement modifier appended to the end of a statement:
say $_ for 1..5;
When the bare for keyword is encountered in the middle of a larger statement, it is interpreted as that second form.
If you want to use the block form inside a larger statement (e.g. as the argument to the await function), you have to prefix it with do to tell the parser that you're starting a block statement here, and want its return value.
More generally, do makes sure that what follows it is parsed using the same rules it would be parsed as if it were its own statement, and causes it to provide a return value. It thus allows us to use any statement as an expression inside a larger statement. do if, do while, etc. all work the same way.
Explanation of your code
The code you showed...
await do for #files -> $file {
start {
#do somthing ... }
}
...does the following:
It loops of over the array #files.
For each iteration, it uses the start keyword to schedule an asynchronous task, which presumably does something with the current element $file. (The $*SCHEDULER variable decides how the task is actually started; by default it uses a simple thread pool scheduler.)
Each invocation of start immediately returns a Promise that will be updated when the asynchronous task has completed.
The do for collects a sequence of all the return values of the loop body (i.e. the promises).
The await function accepts this sequence as its argument, and waits until all the promises have completed.
How to "await after the code"
Not entirely sure what you mean here.
If you want to remember the promises but not await them just jet, simply store them in an array:
my #promises = do for #files -> $file {
start {
#do something ... }
}
#other code ...
await #promises;
There is no convenience functionality for awaiting all scheduled/running tasks. You always have to keep track of the promises.
I can call the gist method on the say built-in function:
&say.gist
sub say (| is raw) { #`(Sub|54790064) ... }
Why can't I call gist on while?
&while.gist
===SORRY!=== Error while compiling <unknown file>
Undeclared routine:
while used at line 1
Obviously while isn't a "routine" but say is. But I thought that all of the built-ins in Perl 6 were really functions that we could redefine.
I thought that all of the built-ins in Perl 6 were really functions that we could redefine.
while is not a routine or macro, but part of the syntax, defined in Perl6's grammar.
If you wanted to redefine it, you would have to create your own slang, which currently involves black magic.
For some reason I have yet to figure out, it only works when done in a module (otherwise, %*LANG seems not to be defined).
Let's call the module froop.pm6:
use nqp;
sub EXPORT {
nqp::bindkey(%*LANG, 'MAIN', nqp::atkey(%*LANG, 'MAIN').^mixin(role {
rule statement_control:sym<while> {
[$<sym>=froop{
$/.hash<sym>.^mixin: role {
method Str { 'while' }
}
}|$<sym>=until]<.kok> {}
<xblock>
}
}));
once Map.new
}
This replaces the while keyword (in statement position) with froop, eg
use froop;
my $i = 0;
froop $i < 5 { say $i++ }
I have a function that could be used in CLI or web application, that being said, there is a little difference in the process; for example: if I'm using this function for CLI it'll use a text progress bar, but that doesn't make sense if I'm using this function for a web application.
The function is basically a loop; so what i'm looking for is a way to make this function flexible by making it possible to pass code as an argument so that it'll be executed at the end of each loop cycle. So if I'm using this function in CLI; i'll pass a progress incremental function to advance the progress bar, and so on.
My current solution is to pass a progress bar object instance, which I think isn't a proper solution; because it doesn't seem flexible for the long run.
A demonstration example of what I'm already doing:
function myFunction($progressBar = null)
{
for($i = 0; $i......)
{
//Do stuff
....
//finally...
if(!empty($progressBar))
$progressBar->advance();
}
}
So, if I want to add another function at the end of the loop, I'll have to pass it as an argument and call it manually later; but as I said, it just doesn't seem right.
I'm thinking of using a callback function(an anonymous function being passed to myFunction) But what is a proper way of doing that; should I just make each callback function as an individual argument? or, to make it even more flexible, should I be grouping all callback functions in an array(if that's possible).
Yes, you can use callbacks for this.
function myFunction($progressBar = null, callable $callback = null)
{
for($i = 0; $i......)
{
//Do stuff
....
//finally...
if(!empty($progressBar))
$progressBar->advance();
}
if ($callback){ //Execute the callback if it is passed as a parameter
$callback();
}
}
Also, you can specify parameters for an anonymous function:
Example: you want to echo something at some point.
myFunction($progressBar) ; //No need yet
myFunction($progressBar, function($result){ echo $result ; }) ; //Now you want to execute it
So, handle it in an appropriate way:
if ($callback){ //Execute the callback if it is passed as a parameter
$callback("All is fine"); //Execute the callback and pass a parameter
}
Array of callbacks also may be useful in this case like:
$callbacks = array(
"onStart" => function(){ echo "started" ; },
"onEnd" => function(){ echo "ended" ; }
) ;
function myFunc($progressBar = null, $callbacks){
if (isset($callbacks["onStart"]) && is_callable($callbacks["onStart"])){
$callbacks["onStart"]() ;//Execute on start.
}
//Execute your code
if (isset($callbacks["onEnd"]) && is_callable($callbacks["onEnd"])){
$callbacks["onEnd"]() ;//Execute on end.
}
}