Re: BEGIN {} question
Richard,
That is a nice summary of some differences among various Callables.
Rob
On Tue, Aug 30, 2022 at 09:34:01PM +0100, Richard Hainsworth wrote:
> Hi Todd,
>
> Long time no see.
>
> Re your 'keeper'. There is a reason why things are called the way they are
> in Raku (aka Perl6). BEGIN is NOT a special subroutine.
>
> BEGIN is a phaser. And it introduces a block. Blocks are not subroutines
> (subs). Even though blocks and subs (and methods and callables) are code
> related things, a sub can take a signature, but a block cannot. You can pass
> arguments to a block using pointy syntax, eg -> $x, %y { ... }, which is
> why it is possible to do things like 'for %some-hash.kv -> $key, $value {
> }'. The 'for' takes a block, which can be pointy. 'for' does not take a
> special subroutine.
>
> But a sub can have a parameter list, eg., 'sub (Int $b where *>= 10) { say
> %b }; ' The 'where' bit means that the compiler will put in checks that $b
> is always greater-equal to 10. So subs are far far more than blocks.
>
> Also you cannot return from a block, but you can return from a sub.
>
> So, by putting in your keeper that BEGIN is a special subroutine, you are
> ignoring a whole world of Raku goodness, as well as making it difficult for
> yourself to understand other phasers.
>
> And talking of phasers, there are some really useful ones, like FIRST and
> LAST, that are in loops. So if you want something to happen first time in a
> loop, put it in FIRST { }.
>
> Also I see you are on the compile time whine again. When perl6 first became
> available as 'pugs', it did take FOREVER. Then as more of perl6 became
> implemented as rakudo, startup times became slower.
>
> Things changed when modules were precompiled. I really do not understand
> what you are talking about when you say you don't think precompile is useful
> everywhere.
>
> For example, when I write something that is called from the command line
> (for example in my raku-collection-raku-documentation distribution), I have
> a one-liner raku program 'RakuDoc' that just says 'use Collection::RakuDoc'.
>
> EVERYTHING else is in the module Collection::RakuDoc, all the MAIN
> subroutines, and stuff. That then only gets compiled once. So, the first
> time RakuDoc is called from the command line, there is a startup delay
> because the whole module is compiled. Every other time RakuDoc is called,
> its really so fast I don't notice a problem. Only the *one* line is compiled
> each time the program is called. All the rest is in precompiled form.
>
> Same with my Extractor program, which is in the raku-extraction module. This
> is a GUI program that takes the rakudoc (aka POD6) files and converts them
> into markdown. For example, I write the README's for my github repos as
> README.rakudoc, then use Extractor to turn it into a README.md. The result
> is far better because the rakudoc renderer I use (from my pod-render
> distribution) automatically collects all the headers and puts them into a
> Table of Contents. If you've tried to do a TOC in markdown, you know what a
> hassle it is.
>
> But Extractor is a GTK::Simple program. And GTK::Simple takes forever to
> precompile. But once done, I don't notice any startup time.
>
> And I change my software quite a lot, so every time I change something, yes,
> startup is slow the first time, but not the next time. Surely, you use a
> piece of software more than once.
>
> Compared to the OLD days, rakudo programs react like lightning. Design your
> software properly, and you wont - as a human - notice much of a delay.
>
> I think the startup complaint (not the compile time for something) has been
> effectively relegated to the days when rakudo was young. So whilst in the
> past I truly sympathised with your rants about compile times, I am now quite
> confused and I find sympathy hard to come by.
>
> Since you continue for ever to complain about 'compile' time issues, rather
> than startup times, I wonder whether the programs you write are massive
> monolithic lines of code with thousands of lines, much like most standard
> software when FORTRAN or COBOL were the high level languages, or whether you
> design things to make each section more manageable.
>
> If the programs you write to be run from the command line are thousands of
> lines long, then yes!! you will suffer!!! from long startup times
> because the program is re-compiled EVERY time. However, if you redesign the
> code, putting things into classes, roles, subroutines, and Raku-y goody
> things, you can push stuff into modules, and reduce your calling program to
> a single line.
>
> When you change your software, do you change every part of it every time? Or
> do you change some client related interface part? Put the interface part
> into one module, and the other more stable functionality into other modules.
> Then when you change the interface part, you dont change the other modules.
> They have already been compiled. So the firs
Re: BEGIN {} question
On 9/4/22 04:23, Ralph Mellor wrote:
On Sun, Sep 4, 2022 at 5:07 AM ToddAndMargo via perl6-users
wrote:
For the fun of it, I placed a "booboo;"
Interesting!
You might like to think of `BEGIN` as a signal to the "compiler":
"Please do more than just "compile" this code. Please also run it,
right now, before "compiling" any more code.".
Thus, when the "compiler" "compiles" the code below it will also "run"
enough of it to display "But this does".
say "This doesn't appear";
BEGIN {
say "Nor this";
booboo;
BEGIN say "But this does";
}}^%^& no matter what nonsense is here or below:
BEGIN !& }}!!%^&
The "compiler" will then display "===SORRY!===" as it gets to the end
of the first outer `BEGIN` and realizes `booboo` hasn't been post declared
(so hasn't been declared at all).
At that point the "compiler" has already compiled `say "Nor this";` but it
does not run it. This is so despite that `say` having appeared in a `BEGIN`.
That's because the lack of a `booboo` declaration in that outer `BEGIN`
block is considered so important that the "compiler" immediately gives up
doing anything more whatsoever -- so no more compilation *or* running.
Once you understand it's just the "compiler" going sequentially through
the source code, doing what the code tells it to do, and recognizing that
code like `say 42` is telling the "compiler" to display `42` when that line
of code is supposed to run, and recognizing that `BEGIN say 42` tells
the "compiler" that the time when that code is supposed to run is ASAP,
it'll hopefully all seem as simple and nice as it in fact is.
I've "scare-quoted" "compiler", "compiles", and "run" in the above because:
* The Rakudo "compiler" is actually a combined compiler+runner
* In Raku, "compiles" includes "running" code that "runs" at "compile-time"
* "run" means executing code, but that can happen during "compilation"
(Perl has a similar scheme -- it has a similar `BEGIN` construct.)
(In theory, Raku code that's already been compiled ahead of time, and all
that's left is to run it, should significantly outperform Perl. In
practice, getting
to the point that this is generally true is a work in progress.)
--
raiph
Hi Raiph,
Awesomely well written! What a treat! Thank you!
Are you a technical writer?
The BEGIN gets me around the slow start up of Raku
programs. I use it for a splash screen (zenity).
And if I do turn over a program to a customer that
start up speed is an issue, a splash screen will
get me around them thinking the flubbed the double
click and clicking multiple more times and, if
running Windows, crashing their computers. Not
to mention taking FOREVER for seven copies of
the program to start up.
A good test for BENIN and error after that would be
to insert some Perl 5 code:
BEGIN {
} /\\\/\/\\/\/\\
Aught to do it.
(That was an Perl 5 joke. No one trying
figuring it out. It is just nonsense.)
-T
--
~~
Computers are like air conditioners.
They malfunction when you open windows
~~
Re: BEGIN {} question
On Sun, Sep 4, 2022 at 5:07 AM ToddAndMargo via perl6-users
wrote:
>
> For the fun of it, I placed a "booboo;"
>
> Interesting!
You might like to think of `BEGIN` as a signal to the "compiler":
"Please do more than just "compile" this code. Please also run it,
right now, before "compiling" any more code.".
Thus, when the "compiler" "compiles" the code below it will also "run"
enough of it to display "But this does".
say "This doesn't appear";
BEGIN {
say "Nor this";
booboo;
BEGIN say "But this does";
}}^%^& no matter what nonsense is here or below:
BEGIN !& }}!!%^&
The "compiler" will then display "===SORRY!===" as it gets to the end
of the first outer `BEGIN` and realizes `booboo` hasn't been post declared
(so hasn't been declared at all).
At that point the "compiler" has already compiled `say "Nor this";` but it
does not run it. This is so despite that `say` having appeared in a `BEGIN`.
That's because the lack of a `booboo` declaration in that outer `BEGIN`
block is considered so important that the "compiler" immediately gives up
doing anything more whatsoever -- so no more compilation *or* running.
Once you understand it's just the "compiler" going sequentially through
the source code, doing what the code tells it to do, and recognizing that
code like `say 42` is telling the "compiler" to display `42` when that line
of code is supposed to run, and recognizing that `BEGIN say 42` tells
the "compiler" that the time when that code is supposed to run is ASAP,
it'll hopefully all seem as simple and nice as it in fact is.
I've "scare-quoted" "compiler", "compiles", and "run" in the above because:
* The Rakudo "compiler" is actually a combined compiler+runner
* In Raku, "compiles" includes "running" code that "runs" at "compile-time"
* "run" means executing code, but that can happen during "compilation"
(Perl has a similar scheme -- it has a similar `BEGIN` construct.)
(In theory, Raku code that's already been compiled ahead of time, and all
that's left is to run it, should significantly outperform Perl. In
practice, getting
to the point that this is generally true is a work in progress.)
--
raiph
Re: BEGIN {} question
On 9/2/22 18:14, ToddAndMargo via perl6-users wrote:
On 9/2/22 13:52, ToddAndMargo via perl6-users wrote:
On 9/2/22 00:13, ToddAndMargo via perl6-users wrote:
Found something interesting
$ raku -c GetUpdates.pl6
Syntax OK
Will execute the BEGIN {}, not just
syntax check it.
The guys on the chat line said this is normal
as `BEGIN` runs a compile time
Hi All,
Thinking about it, I thought I did not bring
enough attention to the `-c` switch in the
above command line. This runs a SYNTAX check
and stops at that. It does not run the program.
I use the `-c` option extensively to debug my
typos before debugging my programs.
When I found BEGIN actually running when all
I wanted was a syntax check, I was perplexed.
My understanding was that -c only checked my
syntax, including my BEGIN block.
This is why I asked on the chat line. Bug
or suppose to be? And the answer is that
is just turned out that way. And that is
fine with me.
:-)
-T
Hi All,
For the fun of it, I placed a "booboo;"
in the BEGIN block to see what the syntax
checker would do:
$ raku -c GetUpdates.pl6
===SORRY!=== Error while compiling /home/linuxutil/GetUpdates.pl6
Undeclared routine:
booboo used at line 28
Caught it. No BEGIN pop up
Then I moved the booboo to the end of the
program
$ raku -c GetUpdates.pl6
===SORRY!=== Error while compiling /home/linuxutil/GetUpdates.pl6
Undeclared routine:
booboo used at line 11664
Caught it. And I also got the BEGIN's pop up.
Interesting!
:-)
-T
--
~~
Computers are like air conditioners.
They malfunction when you open windows
~~
Re: BEGIN {} question
On 9/2/22 13:52, ToddAndMargo via perl6-users wrote:
On 9/2/22 00:13, ToddAndMargo via perl6-users wrote:
Found something interesting
$ raku -c GetUpdates.pl6
Syntax OK
Will execute the BEGIN {}, not just
syntax check it.
The guys on the chat line said this is normal
as `BEGIN` runs a compile time
Hi All,
Thinking about it, I thought I did not bring
enough attention to the `-c` switch in the
above command line. This runs a SYNTAX check
and stops at that. It does not run the program.
I use the `-c` option extensively to debug my
typos before debugging my programs.
When I found BEGIN actually running when all
I wanted was a syntax check, I was perplexed.
My understanding was that -c only checked my
syntax, including my BEGIN block.
This is why I asked on the chat line. Bug
or suppose to be? And the answer is that
is just turned out that way. And that is
fine with me.
:-)
-T
Re: BEGIN {} question
> On 2 Sep 2022, at 22:52, ToddAndMargo via perl6-users
> wrote:
>
> On 9/2/22 00:13, ToddAndMargo via perl6-users wrote:
>> Found something interesting
>> $ raku -c GetUpdates.pl6
>> Syntax OK
>> Will execute the BEGIN {}, not just
>> syntax check it.
>
> The guys on the chat line said this is normal
> as `BEGIN` runs a compile time
How short *is* your memory?
> From: Elizabeth Mattijsen
> Subject: Re: BEGIN {} question
> Date: 29 August 2022 at 09:44:30 CEST
> To: ToddAndMargo via perl6-users
>
>> Question, would BEGIN go at the top or the bottom
>> of my code? Seems the compiler would hit it first
>> at the top, but I do not know if it makes a full
>> pass of everything before firing off the BEGIN.
>
> BEGIN runs at *compile* time.
>
> This means that anything before the BEGIN statement in the code, is compiled
> and known and can be referenced in the BEGIN block.
>
> Anything *after* the BEGIN statement is still unknown to the compiler and can
> therefore *not* be referenced.
>
>
> Liz
Re: BEGIN {} question
On 9/2/22 00:13, ToddAndMargo via perl6-users wrote:
Found something interesting
$ raku -c GetUpdates.pl6
Syntax OK
Will execute the BEGIN {}, not just
syntax check it.
The guys on the chat line said this is normal
as `BEGIN` runs a compile time
--
~~
Computers are like air conditioners.
They malfunction when you open windows
~~
Re: BEGIN {} question
Found something interesting
$ raku -c GetUpdates.pl6
Syntax OK
Will execute the BEGIN {}, not just
syntax check it.
Re: BEGIN {} question
On 9/1/22 20:16, Andinus via perl6-users wrote: ToddAndMargo via perl6-users @ 2022-09-01 10:30 -07: On 9/1/22 00:45, Richard Hainsworth wrote: Treat the regexes as data for a program. Compile the program once. Run the regexes as often as you need. Please elucidate. That could save me boat loads of time. You could take the regex string from an environment variable or read from a file. The program is compiled only once and you can test regexes without re-compilation. Thanks Richard, this is going to save me a lot of time. There are probably over 600 regex's in the program in question. Am I missing something?
Re: BEGIN {} question
ToddAndMargo via perl6-users @ 2022-09-01 10:30 -07: > On 9/1/22 00:45, Richard Hainsworth wrote: >> Treat the regexes as data for a program. Compile the program once. >> Run the regexes as often as you need. > > Please elucidate. That could save me boat loads > of time. You could take the regex string from an environment variable or read from a file. The program is compiled only once and you can test regexes without re-compilation. Thanks Richard, this is going to save me a lot of time. signature.asc Description: PGP signature
Re: BEGIN {} question
On 9/1/22 00:45, Richard Hainsworth wrote: Raku and Perl are two different languages in the same family. They evolved with different targets, perl to react quickly to internet requests, Raku to be a better programming language. This may not be the take the actual developers have, but it's what I think happened. So the thing you designed for Perl will be faster because it fits the pattern. But it's not the best way for Raku. Even though stage parse will get significantly faster over time because Raku was designed to be optimisable, I think Perl will always be faster. Hi Richard, I do not think I have been clean enough in my intentions. I have two goals: long and short term. My short term goal, which I have expounded on at length, is to assist me with a program for my business where I have to constantly keep up with it and have to do a lot recompiling. .precomp is not helpful in that instance. My long term goal is future programs (as I get better at this stuff and if I EVER have a chance to learn GLADE). What I am after is NOT a race between Perl 5 and Perl 6 (Raku) or any other programming language. I really do not care if Perl 5 compiles 300 times faster. I care what the customer's "perception" of what the start time is. Ten microseconds or two seconds, the users can't tell them apart. Ten or twenty seconds and users think something is wrong and start several more instances of the program. This is the "professionally embarrassing" part I have written about. I constantly have to tell users (of non Perl 6) programs to just wait or you will continue to crash things. A widows work around is to have them start slow to start programs by right clicking on the icon and left clicking on "Open". That way they know they did not flub the double click. Think of it this way. An NVMe drive is about eight times faster that a mechanical drive. Do the user's programs run any faster once loaded from either drive? Unless they are doing substantial (YUGE) continuing writes and reads from their drive, no they do not run any faster. But! They load substantially faster, giving the user the impression of a fast, snappy program. This colors the rest of the user's experience. And they don't start five instances of the program thinking they flubbed the double click. So I DO NOT CARE if Perl 6 is slower to compiler AS LONG as the user/customer does not think something is wrong. One or two seconds is just fine with me. I am not after microseconds. -T
Re: BEGIN {} question
On 9/1/22 00:45, Richard Hainsworth wrote: Work with Raku rather than expect it to be the same as Perl. Oh I intent too! I program in Top Down. Perl 5's subroutines are a nightmare. I ADORE Perl 6's subroutines. By saying above / below, this indicates a linear view of code at the same time. Please elucidate! Can you show me an example of FIRST and LAST There are some in the documentation https://docs.raku.org/syntax/FIRST syntax FIRST Documentation for syntax FIRST assembled from the following types: language documentation Phasers From Phasers (Phasers) Phasers FIRST FIRST Runs at loop initialization, before c. Which brings me back to my on going criticism of the documentation. It is a "refresher" for those that already know what they are doing and do not need it. Can you point me to a good beginner's reference? Treat the regexes as data for a program. Compile the program once. Run the regexes as often as you need. Please elucidate. That could save me boat loads of time.
Re: BEGIN {} question
On Wed, 31 Aug 2022, 00:59 ToddAndMargo via perl6-users, < perl6-users@perl.org> wrote: > On 8/30/22 13:34, Richard Hainsworth wrote: > > Hi Todd, > > > > > Since you continue for ever to complain about 'compile' time issues, > > "Stage parce" is specifically what I am whining about > > > rather than startup times, I wonder whether the programs you write are > > massive monolithic lines of code with thousands of lines, much like most > > standard software when FORTRAN or COBOL were the high level languages, > > or whether you design things to make each section more manageable. > > > $ raku -c --stagestats GetUpdates.pl6 > Stage start : 0.000 > Stage parse : 17.851 > Stage syntaxcheck: Syntax OK > > Perl 5 does it over 300 times faster on the code I ported > Raku and Perl are two different languages in the same family. They evolved with different targets, perl to react quickly to internet requests, Raku to be a better programming language. This may not be the take the actual developers have, but it's what I think happened. So the thing you designed for Perl will be faster because it fits the pattern. But it's not the best way for Raku. Even though stage parse will get significantly faster over time because Raku was designed to be optimisable, I think Perl will always be faster. Having said that Raku is still better because it separates out things that should be separate. So you may need to change the way you handle your task. Work with Raku rather than expect it to be the same as Perl. > > > > > If the programs you write to be run from the command line are thousands > > of lines long, then yes!! you will suffer!!! from long startup times Think about the difference between start up and parsing. Move as much stuff away from parsing as possible. > > because the program is re-compiled EVERY time. However, if you redesign > > > Hi Richard, > > Long time no talk to you either. Don't be a stranger. > (If you like, I can always "whine" about compile times > to get your attention, if you like. Chuckle.) > > Thank you. That letter took a lot of work! > > How does this sound? > No. I think you are missing the explicit difference being made in Raku, which differs from all other languages I know (explicit since one could argue C preprocessing does the Sam) between compile time and run time. Raku explicitly allows you to specify compile time actions in the program itself. By saying above / below, this indicates a linear view of code at the same time. This distinction will become even greater when the new Macros are incorporated. That's the next version of Raku. > > BEGIN is a special block of code called a "phaser" > that runs at compile time. It will see any code > above it, such as variables and imported modules, > but not below it. > > Snip > > Can you show me an example of FIRST and LAST > > There are some in the documentation > > > Where .precomp does not work for me is my software > updates program. This is a behemoth program (imports > six of my custom modules too) that goes out and checks > for software updates that I support at my customer > sites. it is about 70 programs. > Change the way you do this to be more compliant with the realities of Raku. You may find in the refactoring process that your old way is probably subject to bit rot. > > To do this open the web site with firefox. Then I > use their developer's tools to examine the page's > source code. I find the fragment I am looking > for and regex them to extract them. > > In the process, I goof the regex/s "A LOT". Not > to mention having to chase down hidden character > that do not appear in Firefox's page source. > And download that are different on a web browser > than with curl. > > I do have a function that allows me to only run that > one web site's extraction, so I do not have to go > through all 70 of them. > > So, I have to recompile the code maybe up to 20 times > depending on the difficulty of the web site. The > L-O-N-G delays drives me nuts. > Treat the regexes as data for a program. Compile the program once. Run the regexes as often as you need. > > Snip. > > Speaking of BEGIN, is this Raku's "parallel > processing" method? Does Raku have a way to > spawn parallel processes and have them talk to > each other? > > -T > > Concurrency is a major change that Raku does differently. But it bursts my > head. Because concurrency is hard! > > > > > > > >
Re: BEGIN {} question
On 8/30/22 13:34, Richard Hainsworth wrote:
Hi Todd,
Long time no see.
Re your 'keeper'. There is a reason why things are called the way they
are in Raku (aka Perl6). BEGIN is NOT a special subroutine.
BEGIN is a phaser. And it introduces a block. Blocks are not subroutines
(subs). Even though blocks and subs (and methods and callables) are code
related things, a sub can take a signature, but a block cannot. You can
pass arguments to a block using pointy syntax, eg -> $x, %y { ... },
which is why it is possible to do things like 'for %some-hash.kv ->
$key, $value { }'. The 'for' takes a block, which can be pointy.
'for' does not take a special subroutine.
But a sub can have a parameter list, eg., 'sub (Int $b where *>= 10) {
say %b }; ' The 'where' bit means that the compiler will put in checks
that $b is always greater-equal to 10. So subs are far far more than
blocks.
Also you cannot return from a block, but you can return from a sub.
So, by putting in your keeper that BEGIN is a special subroutine, you
are ignoring a whole world of Raku goodness, as well as making it
difficult for yourself to understand other phasers.
And talking of phasers, there are some really useful ones, like FIRST
and LAST, that are in loops. So if you want something to happen first
time in a loop, put it in FIRST { }.
Also I see you are on the compile time whine again. When perl6 first
became available as 'pugs', it did take FOREVER. Then as more of perl6
became implemented as rakudo, startup times became slower.
Things changed when modules were precompiled. I really do not understand
what you are talking about when you say you don't think precompile is
useful everywhere.
For example, when I write something that is called from the command line
(for example in my raku-collection-raku-documentation distribution), I
have a one-liner raku program 'RakuDoc' that just says 'use
Collection::RakuDoc'.
EVERYTHING else is in the module Collection::RakuDoc, all the MAIN
subroutines, and stuff. That then only gets compiled once. So, the first
time RakuDoc is called from the command line, there is a startup delay
because the whole module is compiled. Every other time RakuDoc is
called, its really so fast I don't notice a problem. Only the *one* line
is compiled each time the program is called. All the rest is in
precompiled form.
Same with my Extractor program, which is in the raku-extraction module.
This is a GUI program that takes the rakudoc (aka POD6) files and
converts them into markdown. For example, I write the README's for my
github repos as README.rakudoc, then use Extractor to turn it into a
README.md. The result is far better because the rakudoc renderer I use
(from my pod-render distribution) automatically collects all the headers
and puts them into a Table of Contents. If you've tried to do a TOC in
markdown, you know what a hassle it is.
But Extractor is a GTK::Simple program. And GTK::Simple takes forever to
precompile. But once done, I don't notice any startup time.
And I change my software quite a lot, so every time I change something,
yes, startup is slow the first time, but not the next time. Surely, you
use a piece of software more than once.
Compared to the OLD days,
Last week ? Chuckle.
rakudo programs react like lightning. Design
your software properly, and you wont - as a human - notice much of a delay.
I think the startup complaint (not the compile time for something) has
been effectively relegated to the days when rakudo was young. So whilst
in the past I truly sympathised with your rants about compile times, I
am now quite confused and I find sympathy hard to come by.
Since you continue for ever to complain about 'compile' time issues,
"Stage parce" is specifically what I am whining about
rather than startup times, I wonder whether the programs you write are
massive monolithic lines of code with thousands of lines, much like most
standard software when FORTRAN or COBOL were the high level languages,
or whether you design things to make each section more manageable.
$ raku -c --stagestats GetUpdates.pl6
Stage start : 0.000
Stage parse : 17.851
Stage syntaxcheck: Syntax OK
Perl 5 does it over 300 times faster on the code I ported
If the programs you write to be run from the command line are thousands
of lines long, then yes!! you will suffer!!! from long startup times
because the program is re-compiled EVERY time. However, if you redesign
the code, putting things into classes, roles, subroutines, and Raku-y
goody things, you can push stuff into modules, and reduce your calling
program to a single line.
When you change your software, do you change every part of it every
time? Or do you change some client related interface part? Put the
interface part into one module, and the other more stable functionality
into other modules. Then when you change the interface part, you dont
change the other modules. They
Re: BEGIN {} question
Hi Todd,
Long time no see.
Re your 'keeper'. There is a reason why things are called the way they
are in Raku (aka Perl6). BEGIN is NOT a special subroutine.
BEGIN is a phaser. And it introduces a block. Blocks are not subroutines
(subs). Even though blocks and subs (and methods and callables) are code
related things, a sub can take a signature, but a block cannot. You can
pass arguments to a block using pointy syntax, eg -> $x, %y { ... },
which is why it is possible to do things like 'for %some-hash.kv ->
$key, $value { }'. The 'for' takes a block, which can be pointy.
'for' does not take a special subroutine.
But a sub can have a parameter list, eg., 'sub (Int $b where *>= 10) {
say %b }; ' The 'where' bit means that the compiler will put in checks
that $b is always greater-equal to 10. So subs are far far more than blocks.
Also you cannot return from a block, but you can return from a sub.
So, by putting in your keeper that BEGIN is a special subroutine, you
are ignoring a whole world of Raku goodness, as well as making it
difficult for yourself to understand other phasers.
And talking of phasers, there are some really useful ones, like FIRST
and LAST, that are in loops. So if you want something to happen first
time in a loop, put it in FIRST { }.
Also I see you are on the compile time whine again. When perl6 first
became available as 'pugs', it did take FOREVER. Then as more of perl6
became implemented as rakudo, startup times became slower.
Things changed when modules were precompiled. I really do not understand
what you are talking about when you say you don't think precompile is
useful everywhere.
For example, when I write something that is called from the command line
(for example in my raku-collection-raku-documentation distribution), I
have a one-liner raku program 'RakuDoc' that just says 'use
Collection::RakuDoc'.
EVERYTHING else is in the module Collection::RakuDoc, all the MAIN
subroutines, and stuff. That then only gets compiled once. So, the first
time RakuDoc is called from the command line, there is a startup delay
because the whole module is compiled. Every other time RakuDoc is
called, its really so fast I don't notice a problem. Only the *one* line
is compiled each time the program is called. All the rest is in
precompiled form.
Same with my Extractor program, which is in the raku-extraction module.
This is a GUI program that takes the rakudoc (aka POD6) files and
converts them into markdown. For example, I write the README's for my
github repos as README.rakudoc, then use Extractor to turn it into a
README.md. The result is far better because the rakudoc renderer I use
(from my pod-render distribution) automatically collects all the headers
and puts them into a Table of Contents. If you've tried to do a TOC in
markdown, you know what a hassle it is.
But Extractor is a GTK::Simple program. And GTK::Simple takes forever to
precompile. But once done, I don't notice any startup time.
And I change my software quite a lot, so every time I change something,
yes, startup is slow the first time, but not the next time. Surely, you
use a piece of software more than once.
Compared to the OLD days, rakudo programs react like lightning. Design
your software properly, and you wont - as a human - notice much of a delay.
I think the startup complaint (not the compile time for something) has
been effectively relegated to the days when rakudo was young. So whilst
in the past I truly sympathised with your rants about compile times, I
am now quite confused and I find sympathy hard to come by.
Since you continue for ever to complain about 'compile' time issues,
rather than startup times, I wonder whether the programs you write are
massive monolithic lines of code with thousands of lines, much like most
standard software when FORTRAN or COBOL were the high level languages,
or whether you design things to make each section more manageable.
If the programs you write to be run from the command line are thousands
of lines long, then yes!! you will suffer!!! from long startup times
because the program is re-compiled EVERY time. However, if you redesign
the code, putting things into classes, roles, subroutines, and Raku-y
goody things, you can push stuff into modules, and reduce your calling
program to a single line.
When you change your software, do you change every part of it every
time? Or do you change some client related interface part? Put the
interface part into one module, and the other more stable functionality
into other modules. Then when you change the interface part, you dont
change the other modules. They have already been compiled. So the first
time you start up your program, only the section you have changed gets
recompiled, not the entire monolith.
By the way, I assume that you understand the Raku meaning of 'module',
as opposed to a 'distribution'. When I write a large piece of software,
I m
Re: BEGIN {} question
On 8/28/22 15:58, ToddAndMargo via perl6-users wrote:
Hi All,
I am thinking of using
BEGIN {}
to fire up a splash screen (libnotify).
Question: is what happens between the brackets
isolated from the rest of the code? If I set
variable values or declare variables, are they
wiped out, etc.?
Many thanks,
-T
My keeper on BEGIN. That you for all the help
and tips!
Perl6: BEGIN {}
BEGIN is a special subroutine that runs at compile time.
It will see any code above it, such as variables and
imported modules, but not below it.
The idea is to run something at the start of compile before
the rest of compile completes. A splash screen for example.
Perl 6's compile can take a very long time and users may not
realize it started and restart it several times.
Note that a space is required between `BEGIN and the `{}`
BEGIN {
# Splash Screen
( my $ProgramName = $?FILE ) ~~ s|.*"/"||;
my Str $NotifyStr = "\nStarting $ProgramName\n";
my Str $Icon = "/home/linuxutil/Images/Info.png";
my Str $Title = "$ProgramName Splash Screen";
my Str $Timeout = "8"; # zenity = seconds
# Note: zenity seems to not detach when run without a shell
shell "zenity --info --title \"$Title\" --text \"$NotifyStr\"
--width=220 --timeout=$Timeout &";
}
Re: BEGIN {} question
On 8/29/22 13:03, ToddAndMargo via perl6-users wrote:
On 8/28/22 15:58, ToddAndMargo via perl6-users wrote:
Hi All,
I am thinking of using
BEGIN {}
to fire up a splash screen (libnotify).
Question: is what happens between the brackets
isolated from the rest of the code? If I set
variable values or declare variables, are they
wiped out, etc.?
Many thanks,
-T
Follow up:
Thank you all for the help!
My splash screen pops up whilst the
rest of the program compiles.
Here is my BEGIN code. If you are
wondering why all the variables when
I could just write it in the run line,
it is becasue the names of the variables
and the comments next to them tell me what
the parameters of notify-send are and
how to use them. Much easier to maintain.
#!/usr/bin/env perl6
use RunNoShellLib :RunNoShell, :RunNoShellCode, :RunNoShellErr;
BEGIN {
# Splash Screen
( my $ProgramName = $?FILE ) ~~ s|.*"/"||;
my Str $NotifyStr = "\nStarting $ProgramName\n";
my Str $Icon = "/home/linuxutil/Images/Info.png";
my Str $Title = "$ProgramName Splash Screen";
my Str $Timeout = "8000"; # milliseconds
RunNoShell( "notify-send -u normal -t \"$Timeout\" -i \"$Icon\"
\"$Title\" \"$NotifyStr\"" );
}
:-)
Love Raku!
-T
I changed my BEGIN a bit. Send-notify open on the right under the last
notification.
Zenity allow me to open up right in the middle to the
screen.
And I had to switch from run to shell to get zenity
to detach. Otherwise the compiler stops until
zenity returns
BEGIN {
# Splash Screen
( my $ProgramName = $?FILE ) ~~ s|.*"/"||;
my Str $NotifyStr = "\nStarting $ProgramName\n";
my Str $Icon = "/home/linuxutil/Images/Info.png";
my Str $Title = "$ProgramName Splash Screen";
# my Str $Timeout = "8000"; # notify-send = milliseconds
my Str $Timeout = "8"; # zenity = seconds
# Note: zenity seems to not detach when run without a shell
# RunNoShell( "zenity --info --title \"$Title\" --text
\"$NotifyStr\" --width=220 --timeout=$Timeout" );
shell "zenity --info --title \"$Title\" --text \"$NotifyStr\"
--width=220 --timeout=$Timeout &";
}
--
~~
Computers are like air conditioners.
They malfunction when you open windows
~~
Re: BEGIN {} question
On 8/28/22 15:58, ToddAndMargo via perl6-users wrote:
Hi All,
I am thinking of using
BEGIN {}
to fire up a splash screen (libnotify).
Question: is what happens between the brackets
isolated from the rest of the code? If I set
variable values or declare variables, are they
wiped out, etc.?
Many thanks,
-T
Follow up:
Thank you all for the help!
My splash screen pops up whilst the
rest of the program compiles.
Here is my BEGIN code. If you are
wondering why all the variables when
I could just write it in the run line,
it is becasue the names of the variables
and the comments next to them tell me what
the parameters of notify-send are and
how to use them. Much easier to maintain.
#!/usr/bin/env perl6
use RunNoShellLib :RunNoShell, :RunNoShellCode, :RunNoShellErr;
BEGIN {
# Splash Screen
( my $ProgramName = $?FILE ) ~~ s|.*"/"||;
my Str $NotifyStr = "\nStarting $ProgramName\n";
my Str $Icon = "/home/linuxutil/Images/Info.png";
my Str $Title = "$ProgramName Splash Screen";
my Str $Timeout = "8000"; # milliseconds
RunNoShell( "notify-send -u normal -t \"$Timeout\" -i \"$Icon\"
\"$Title\" \"$NotifyStr\"" );
}
:-)
Love Raku!
-T
Re: BEGIN {} question
On 8/29/22 10:45, Tom Browder wrote: On Mon, Aug 29, 2022 at 12:31 PM ToddAndMargo via perl6-users wrote: On 8/29/22 08:41, Tom Browder wrote: ... And I think you may be surprised how much speedup you may get by using the precompiled-module "trick" for most of your 11,000-line program. ... Hi Tom, The .precomp workaround was never in question! But there are tines when it is impractical. ... So lots and lots of compiling that .precomp does not help me with. ... More information that you wanted. Sorry. No reason to apologize, Todd. I had forgotten how much you were actually doing with your Raku code--a textbook example for sure! But I apologize for my impatient replies. :-) Blessings, -Tom Hi Tom, You are a force of nature. I always love your replies. I was in no way offended. :-) I got long winded because a lot of folks keep telling me about the .precomp workaround. I did not want them to think I was summarily disregarding their advice (including you). I wanted to expound on why it is not always practicle. -T
Re: BEGIN {} question
On Mon, Aug 29, 2022 at 12:31 PM ToddAndMargo via perl6-users wrote: > On 8/29/22 08:41, Tom Browder wrote: ... > > And I think you may be surprised how much speedup you may get by using > > the precompiled-module "trick" for most of your 11,000-line program. ... > Hi Tom, > The .precomp workaround was never in question! > But there are tines when it is impractical. ... > So lots and lots of compiling that .precomp does not > help me with. ... > More information that you wanted. Sorry. No reason to apologize, Todd. I had forgotten how much you were actually doing with your Raku code--a textbook example for sure! But I apologize for my impatient replies. :-) Blessings, -Tom
Re: BEGIN {} question
On 8/29/22 08:41, Tom Browder wrote: On Mon, Aug 29, 2022 at 10:29 AM ToddAndMargo via perl6-users mailto:perl6-users@perl.org>> wrote: ... > Does the compiler make a full pass through > the code before firing off the BEGIN routine NO. And I think you may be surprised how much speedup you may get by using the precompiled-module "trick" for most of your 11,000-line program. -Tom Hi Tom, The .precomp workaround was never in question! But there are tines when it is impractical. Most of the programs I have written for customers run in the background (rakuw) or at night when no one cares how long they take to start. Other programs are to remove mistakes from barcode data when routed to a bar code program. The customer inputs data into their Point of Sale software that freaks out the bar code printing program, so I correct it on the fly. It is a lot easier than going through their entire database and having the remote `'` for feet and `"` for inches in a CSV file sent to the barcode program (comma-separated value). Not to mention it is impossible to get the users to stop making those mistakes I also have written my own Dynamic DNS (Domain Name Server) work around for folks that I have installed RDP (remote Desktop Protocol) on and that are using floating WAN (Wide Area Network) addresses. But it is pretty simple and starts quick enough. Now for where .precomp is not practical. It is those projects were the saying "the software is never finished" applies. Where I am loath to start/recommend projects that the customer expects a reasonable response time to start. So far, I have been lucky. For those programs that do not require a lot of maintenance, the .precomp work around is reasonable. Primarily where the response time drives me INSANE is my software updates program. This program goes out and checks for new updates for programs I support. If a new one exists, it downloads. I carry these programs with me to customer sites on a read only flash drive so as to not transfer viruses between customers. So far it is about 70 programs. Because Web Developers are always working on their sites, I am constantly having to figure out what is wrong. "The software is never finished". So .precomp does not help. What I have done though is to configure the program such that if I put the sub name of the target program on the run line, my program will only run that section rather that waiting 5 minutes to go through them all. And if my program finds something on the run line it, it also triggers my extensive debugging. And it does take a lot of iterations to debug my regex's. And the wait time (17 seconds) drives me NUTS. Sometimes, the "source" code on Firefox's development tools dos not show hidden character in their pages and that creates a nightmare too. I spurt the web page to a file and then see what the heck is wrong. I am getting pretty good at it though. "Git" and "Brave" (Browser) are interesting to download from. So lots and lots of compiling that .precomp does not help me with. More information that your wanted. Sorry. -T
Re: BEGIN {} question
On Mon, Aug 29, 2022 at 10:29 AM ToddAndMargo via perl6-users < perl6-users@perl.org> wrote: ... > Does the compiler make a full pass through > the code before firing off the BEGIN routine NO. And I think you may be surprised how much speedup you may get by using the precompiled-module "trick" for most of your 11,000-line program. -Tom
Re: BEGIN {} question
On 8/29/22 00:44, Elizabeth Mattijsen wrote: Question, would BEGIN go at the top or the bottom of my code? Seems the compiler would hit it first at the top, but I do not know if it makes a full pass of everything before firing off the BEGIN. BEGIN runs at *compile* time. This means that anything before the BEGIN statement in the code, is compiled and known and can be referenced in the BEGIN block. Anything *after* the BEGIN statement is still unknown to the compiler and can therefore *not* be referenced. Liz Hi Liz, Excellent explanation. Thank you! Does the compiler make a full pass through the code before firing off the BEGIN routine or does it fire it off as soon as it finds it? -T
Re: BEGIN {} question
> Question, would BEGIN go at the top or the bottom > of my code? Seems the compiler would hit it first > at the top, but I do not know if it makes a full > pass of everything before firing off the BEGIN. BEGIN runs at *compile* time. This means that anything before the BEGIN statement in the code, is compiled and known and can be referenced in the BEGIN block. Anything *after* the BEGIN statement is still unknown to the compiler and can therefore *not* be referenced. Liz
Re: BEGIN {} question
On 8/28/22 19:11, Bruce Gray wrote:
On Aug 28, 2022, at 5:58 PM, ToddAndMargo via perl6-users
wrote:
Hi All,
I am thinking of using
BEGIN {}
to fire up a splash screen (libnotify).
Question: is what happens between the brackets
isolated from the rest of the code? If I set
variable values or declare variables, are they
wiped out, etc.?
Many thanks,
-T
BEGIN blocks create a lexical scope, because they are *blocks*, so any
variables that you declare within the block don't exist outside the block.
Variables that you define in the lexical scope *surrounding* the BEGIN block
can have their values set inside the BEGIN block, and those values will be
retained after BEGIN ends.
my $a_var;
sub do_something ( ) {
say "did something! By the way: ", (:$a_var), ' inside a sub called from
the BEGIN block, because the var is shared between them (same lexical scope).';
}
BEGIN {
$a_var = 42;
my $b_var = 11;
say "a_var is $a_var within the BEGIN block";
say "b_var is $b_var within the BEGIN block";
do_something();
}
say "a_var is still $a_var outside the BEGIN block";
# say "b_var is still $b_var outside the BEGIN block"; # Commented out, because
illegal!
Output:
a_var is 42 within the BEGIN block
b_var is 11 within the BEGIN block
did something! By the way: a_var => 42 inside a sub called from the BEGIN
block, because the var is shared between them (same lexical scope).
a_var is still 42 outside the BEGIN block
Hi Bruce,
Thank you! I understand now.
I was channeling my old Modula2 days, where
everything had a BEGIN and an END. I did not
realize BEGIN was a "name". A special name
of a subroutine that would run before compile
was complete.
I am now thinking of firing off a call to libnotify
with a delayed close out time to simulate a splash
screen.
Question, would BEGIN go at the top or the bottom
of my code? Seems the compiler would hit it first
at the top, but I do not know if it makes a full
pass of everything before firing off the BEGIN.
-T
Re: BEGIN {} question
> On Aug 28, 2022, at 5:58 PM, ToddAndMargo via perl6-users
> wrote:
>
> Hi All,
>
> I am thinking of using
>
> BEGIN {}
>
> to fire up a splash screen (libnotify).
>
> Question: is what happens between the brackets
> isolated from the rest of the code? If I set
> variable values or declare variables, are they
> wiped out, etc.?
>
> Many thanks,
> -T
BEGIN blocks create a lexical scope, because they are *blocks*, so any
variables that you declare within the block don't exist outside the block.
Variables that you define in the lexical scope *surrounding* the BEGIN block
can have their values set inside the BEGIN block, and those values will be
retained after BEGIN ends.
my $a_var;
sub do_something ( ) {
say "did something! By the way: ", (:$a_var), ' inside a sub called from
the BEGIN block, because the var is shared between them (same lexical scope).';
}
BEGIN {
$a_var = 42;
my $b_var = 11;
say "a_var is $a_var within the BEGIN block";
say "b_var is $b_var within the BEGIN block";
do_something();
}
say "a_var is still $a_var outside the BEGIN block";
# say "b_var is still $b_var outside the BEGIN block"; # Commented out, because
illegal!
Output:
a_var is 42 within the BEGIN block
b_var is 11 within the BEGIN block
did something! By the way: a_var => 42 inside a sub called from the BEGIN
block, because the var is shared between them (same lexical scope).
a_var is still 42 outside the BEGIN block
--
Hope this helps,
Bruce Gray (Util of PerlMonks)
