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
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-us...@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
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,
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-us...@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-us...@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)
BEGIN {} question
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
--
If I had a dime every time I didn't know
what was going on, I'd be like, "Why is
everyone giving me all these dimes?"
=begin comment as replacement for =begin data
Hi,
I was trying to find a way to have data stored in the program script
itself a la perl5 __DATA__. Perl6 has the =data pod structures to do
that. But after a first test I got an error using $=data saying that it
was not yet implemented. But, as the saying goes, there's more than one
way to do it!
First I still wanted to use the '=begin data' and '=end data' pod
statements to store data and just search through the pod data myself.
The problem I found however was that the newline characters were removed
from the text. This is inconvenient. Looking at other pod thingies I saw
that the pod comment was very usable in that everything was left as it
was typed in. I've developed a small sub which makes use of comment
blocks and interprets them as a data block.
E.g.
=begin comment :!comment :type
# test van data
foo 1
# second line
bar 2
=end comment
# get and use the data
my Str $foo-data = get-data('fooData');
for $foo-data.lines -> $line {
say "Data line: $line";
}
# Program returns;
#Data line: foo 1
#Data line: bar 2
A few things to mention here;
1) :!comment is checked by the sub so it must be there. It is also a
sign to the reader that this block is not used to show comments.
2) :fooData is the key to use to search for data. More than one data
block is then possible and other (real) comments are not processed.
3) The sub is filtering out empty lines and comment lines (starting with
'#').
The sub is shown below;
sub get-data ( Str:D $content-key --> Str ) {
my Str $content;
# search through the pod structure
for @$=pod -> $pd {
# search for 1) pod comment block, 2) :!comment and 3) the users key
if $pd ~~ Pod::Block::Comment and
!$pd.config and
$pd.config eq $content-key {
$content = $pd.contents[0];
last;
}
}
# remove comments
$content ~~ s:g/\s* '#' .*? $$//;
# remove empty lines
$content ~~ s:g/^^ \s* $$//;
$content ~~ s:g/\n\n+/\n/;
$content ~~ s:g/^\n+//;
$content ~~ s:g/\n+$//;
$content
}
You can get this program from a gist at github here;
https://gist.github.com/MARTIMM/516b3ade0500428cedc28ae86fad6a1b
Hopefully anyone can profit from this code,
cheers,
Marcel
[SPAM:##] [perl #130505] [LTA] double SORRY (BEGIN (1, 2)[*-1])
Tests in https://github.com/perl6/roast/commit/79dff96fc9f383616dd192ef016725395323887b and https://github.com/perl6/roast/commit/82d3a883a52af23c8a67e46b88b313b3cf20b18d On 2018-03-10 06:26:00, jan-olof.hen...@bredband.net wrote: > On Wed, 04 Jan 2017 15:02:45 -0800, alex.jakime...@gmail.com wrote: > > Code: > > BEGIN (1, 2)[*-1] > > > > Result: > > ===SORRY!=== Error while compiling > > An exception occurred while evaluating a BEGIN > > at :1 > > Exception details: > > ===SORRY!=== Error while compiling > > Cannot invoke this object (REPR: Null; VMNull) > > at : > > > > > > Once is enough, especially given that it says “at : ” which is not > > useful. > > > Fixed with commit > https://github.com/rakudo/rakudo/commit/7c1f0b416d37415bb25a3a6974aaa3635f5d1225
[perl #130505] [LTA] double SORRY (BEGIN (1, 2)[*-1])
On Wed, 04 Jan 2017 15:02:45 -0800, alex.jakime...@gmail.com wrote: > Code: > BEGIN (1, 2)[*-1] > > Result: > ===SORRY!=== Error while compiling > An exception occurred while evaluating a BEGIN > at :1 > Exception details: > ===SORRY!=== Error while compiling > Cannot invoke this object (REPR: Null; VMNull) > at : > > > Once is enough, especially given that it says “at : ” which is not useful. Fixed with commit https://github.com/rakudo/rakudo/commit/7c1f0b416d37415bb25a3a6974aaa3635f5d1225
[perl #123776] Binding a variable at BEGIN time doesn't stick aruond for runtime
On Tue, 30 Jan 2018 19:03:13 -0800, c...@zoffix.com wrote:
> On Tue, 30 Jan 2018 15:08:38 -0800, c...@zoffix.com wrote:
> > On Fri, 01 Dec 2017 12:09:05 -0800, alex.jakime...@gmail.com wrote:
> > > Still reproducible (2017.11, HEAD(5929887)), but is supposed to
> > > work?
> >
> > Don't see any reason why that'd be questionable.
> >
> > > On 2015-02-09 17:43:52, rayd...@cyberuniverses.com wrote:
> > > > m: my $a; BEGIN { $a := 1; say $a; }; say $a;
> > > > rakudo-{parrot,moar} 0cb22e: OUTPUT«1(Any)»
> > > >
> > > > m: my $a; BEGIN { $a = 1; say $a; }; say $a; # works with
> > > > assignment
> > > > rakudo-{parrot,moar} 0cb22e: OUTPUT«11»
> >
> >
> > Another manifestation of the same bug:
> >
> > m: BEGIN { my $a1 := 42; say $a1; }
> > rakudo-moar deffe54b8: OUTPUT: «42»
> > m: BEGIN { my $a1 = 42; say $a1; }
> > rakudo-moar deffe54b8: OUTPUT: «42»
> > m: BEGIN my $a1 = 42; say $a1;
> > rakudo-moar deffe54b8: OUTPUT: «42»
> > m: BEGIN my $a1 := 42; say $a1;
> > rakudo-moar deffe54b8: OUTPUT: «(Mu)»
>
>
>
> Tracked this to Perl6::World.compile_in_context but leaving it there,
> as it's getting too hard.
> Need to gain a few levels first.
>
> The comment in the method reads:
># Create outer lexical contexts with all symbols visible. Maybe
># we can be a bit smarter here some day. But for now we just make a
># single frame and copy all the visible things into it.
>
> So I imagine the binding gets made to this faked out block and never
> propagates back to the source where all the lexicals were copied from.
More comments: https://irclog.perlgeek.de/perl6/2018-02-02#i_15769787
15:11 jnthn Zoffix: Yeah. Lexpads are immutable, and when we compile a
BEGIN we obviously haven't finished the outer block yet, so we have to fake
something up. But what? Containers are cloned from a "prototype", and the fake
lexpad contains the static container. Thus what's actually happening is that on
entry to the scope post-compilation, the Scalar is cloned complete with the
value set in the prototype.
15:12 Of course, binding doesn't have that level of indirection so
there's no way it can work.
15:12 We should perhaps detect it at compile time and say it can't
work. Or...we could try diffing the scope after each BEGIN block and trying to
somehow propagate bindings.
[perl #123776] Binding a variable at BEGIN time doesn't stick aruond for runtime
On Tue, 30 Jan 2018 15:08:38 -0800, c...@zoffix.com wrote:
> On Fri, 01 Dec 2017 12:09:05 -0800, alex.jakime...@gmail.com wrote:
> > Still reproducible (2017.11, HEAD(5929887)), but is supposed to work?
>
> Don't see any reason why that'd be questionable.
>
> > On 2015-02-09 17:43:52, rayd...@cyberuniverses.com wrote:
> > > m: my $a; BEGIN { $a := 1; say $a; }; say $a;
> > > rakudo-{parrot,moar} 0cb22e: OUTPUT«1(Any)»
> > >
> > > m: my $a; BEGIN { $a = 1; say $a; }; say $a; # works with assignment
> > > rakudo-{parrot,moar} 0cb22e: OUTPUT«11»
>
>
> Another manifestation of the same bug:
>
> m: BEGIN { my $a1 := 42; say $a1; }
> rakudo-moar deffe54b8: OUTPUT: «42»
> m: BEGIN { my $a1 = 42; say $a1; }
> rakudo-moar deffe54b8: OUTPUT: «42»
> m: BEGIN my $a1 = 42; say $a1;
> rakudo-moar deffe54b8: OUTPUT: «42»
> m: BEGIN my $a1 := 42; say $a1;
> rakudo-moar deffe54b8: OUTPUT: «(Mu)»
Tracked this to Perl6::World.compile_in_context but leaving it there, as it's
getting too hard.
Need to gain a few levels first.
The comment in the method reads:
# Create outer lexical contexts with all symbols visible. Maybe
# we can be a bit smarter here some day. But for now we just make a
# single frame and copy all the visible things into it.
So I imagine the binding gets made to this faked out block and never propagates
back to the source where all the lexicals were copied from.
[perl #123776] Binding a variable at BEGIN time doesn't stick aruond for runtime
On Tue, 30 Jan 2018 15:08:38 -0800, c...@zoffix.com wrote:
> On Fri, 01 Dec 2017 12:09:05 -0800, alex.jakime...@gmail.com wrote:
> > Still reproducible (2017.11, HEAD(5929887)), but is supposed to work?
>
> Don't see any reason why that'd be questionable.
>
> > On 2015-02-09 17:43:52, rayd...@cyberuniverses.com wrote:
> > > m: my $a; BEGIN { $a := 1; say $a; }; say $a;
> > > rakudo-{parrot,moar} 0cb22e: OUTPUT«1(Any)»
> > >
> > > m: my $a; BEGIN { $a = 1; say $a; }; say $a; # works with assignment
> > > rakudo-{parrot,moar} 0cb22e: OUTPUT«11»
>
>
> Another manifestation of the same bug:
>
> m: BEGIN { my $a1 := 42; say $a1; }
> rakudo-moar deffe54b8: OUTPUT: «42»
> m: BEGIN { my $a1 = 42; say $a1; }
> rakudo-moar deffe54b8: OUTPUT: «42»
> m: BEGIN my $a1 = 42; say $a1;
> rakudo-moar deffe54b8: OUTPUT: «42»
> m: BEGIN my $a1 := 42; say $a1;
> rakudo-moar deffe54b8: OUTPUT: «(Mu)»
Tracked this to Perl6::World.compile_in_context but leaving it there, as it's
getting too hard.
Need to gain a few levels first.
The comment in the method reads:
# Create outer lexical contexts with all symbols visible. Maybe
# we can be a bit smarter here some day. But for now we just make a
# single frame and copy all the visible things into it.
So I imagine the binding gets made to this faked out block and never propagates
back to the source where all the lexicals were copied from.
[perl #123776] [@LARRY] Binding a variable at BEGIN time doesn't stick aruond for runtime
On Fri, 01 Dec 2017 12:09:05 -0800, alex.jakime...@gmail.com wrote:
> Still reproducible (2017.11, HEAD(5929887)), but is supposed to work?
Don't see any reason why that'd be questionable.
> On 2015-02-09 17:43:52, rayd...@cyberuniverses.com wrote:
> > m: my $a; BEGIN { $a := 1; say $a; }; say $a;
> > rakudo-{parrot,moar} 0cb22e: OUTPUT«1(Any)»
> >
> > m: my $a; BEGIN { $a = 1; say $a; }; say $a; # works with assignment
> > rakudo-{parrot,moar} 0cb22e: OUTPUT«11»
Another manifestation of the same bug:
m: BEGIN { my $a1 := 42; say $a1; }
rakudo-moar deffe54b8: OUTPUT: «42»
m: BEGIN { my $a1 = 42; say $a1; }
rakudo-moar deffe54b8: OUTPUT: «42»
m: BEGIN my $a1 = 42; say $a1;
rakudo-moar deffe54b8: OUTPUT: «42»
m: BEGIN my $a1 := 42; say $a1;
rakudo-moar deffe54b8: OUTPUT: «(Mu)»
[perl #123776] [@LARRY] Binding a variable at BEGIN time doesn't stick aruond for runtime
On Fri, 01 Dec 2017 12:09:05 -0800, alex.jakime...@gmail.com wrote:
> Still reproducible (2017.11, HEAD(5929887)), but is supposed to work?
Don't see any reason why that'd be questionable.
> On 2015-02-09 17:43:52, rayd...@cyberuniverses.com wrote:
> > m: my $a; BEGIN { $a := 1; say $a; }; say $a;
> > rakudo-{parrot,moar} 0cb22e: OUTPUT«1(Any)»
> >
> > m: my $a; BEGIN { $a = 1; say $a; }; say $a; # works with assignment
> > rakudo-{parrot,moar} 0cb22e: OUTPUT«11»
Another manifestation of the same bug:
m: BEGIN { my $a1 := 42; say $a1; }
rakudo-moar deffe54b8: OUTPUT: «42»
m: BEGIN { my $a1 = 42; say $a1; }
rakudo-moar deffe54b8: OUTPUT: «42»
m: BEGIN my $a1 = 42; say $a1;
rakudo-moar deffe54b8: OUTPUT: «42»
m: BEGIN my $a1 := 42; say $a1;
rakudo-moar deffe54b8: OUTPUT: «(Mu)»
[perl #132650] [POD]=begin comment/=end comment blocks ought to nest
# New Ticket Created by Tom Browder
# Please include the string: [perl #132650]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=132650 >
Given this nqp code:
=begin comment
some code
...
=begin comment
some more code
...
=end comment
some more code
..l
=end comment
Trying to execute it fails with a msg saying roughly “found a begin comment
before an end comment.”
Re: [perl #122838] [BUG] BEGIN GLOBAL:: assignment does not work in Rakudo
If you normally create a class, the entry in GLOBAL:: is decontainerized:
$ 6 'class Test {}; use nqp; dd nqp::iscont(GLOBAL::)’
0
However, if you just assign to a key in GLOBAL::, the result *is* containerized:
$ 6 'BEGIN GLOBAL:: = class { }; use nqp; dd nqp::iscont(GLOBAL::)’
1
So maybe you should just bind to the key in GLOBAL:: ?
$ 6 'BEGIN GLOBAL:: := class { }; dd Test.new'
.new
Now, perhaps this can be fixed by having a nqp::decont() somewhere deep in the
bowels for every reference to something in GLOBAL:: . But I fear that, even
if it only a little bit of overhead, it’s overhead we don’t need.
An alternate option would be to create a Stash.ASSIGN-KEY that would not create
a container, but instead would bind. But that also feels a bit too magical to
me.
So I think we should mark this ticket as “DIHWIDT”, and point to the workaround
of binding.
> On 3 Dec 2017, at 11:23, Aleks-Daniel Jakimenko-Aleksejev via RT
> wrote:
>
> As of today (2017.11,HEAD(e5b660e)) it prints this:
>
> Cannot call method 'new' on a null object
> in block at -e line 1
>
> Which is arguably reasonable, but I guess it's not good enough.
>
> On 2014-09-24 04:03:12, masak wrote:
>> m: BEGIN GLOBAL:: = class { }; Test.new;
>> rakudo-moar 682e03: OUTPUT«===SORRY!===Object of type
>> in QAST::WVal, but not in SC»
>> nine: looks like a bug.
>> masak: any idea how I can create a class with a fully qualified
>> name from an EVAL that's deep in some other namespace?
>> masak: as in Inline::Perl5::Perl6PackageCreator::create runs an
>> EVAL that should create a class called Foo::Bar::Baz.
>> nine: EVAL "class Foo::Bar::Baz {}" doesn't cut it ?
>> alternately EVAL "class Foo { class Bar { class Baz {}}}' ?
>> or actually, maybe both?
>> lizmat: nope, that creates
>> Inline::Perl5::Perl6PackageCreator::Foo::Bar::Baz (what a handy name
>> ;)
>> m: BEGIN GLOBAL:: := class { }; Test.new;
>> rakudo-moar 682e03: ( no output )
>> ah, := works, while = does not
>> nine: Does class GLOBAL::Foo::Bar::Baz { } not do it?
>> jnthn: no, the GLOBAL:: is pretty much ignored
>> ah
>> Maybe that wants fixing
>> But afer dinner
>> * masak submits rakudobug
>> jnthn: according to S10, GLOBAL:: should do it though
>> nine: That's my feeling too
Re: [perl #122838] [BUG] BEGIN GLOBAL:: assignment does not work in Rakudo
If you normally create a class, the entry in GLOBAL:: is decontainerized:
$ 6 'class Test {}; use nqp; dd nqp::iscont(GLOBAL::)’
0
However, if you just assign to a key in GLOBAL::, the result *is* containerized:
$ 6 'BEGIN GLOBAL:: = class { }; use nqp; dd nqp::iscont(GLOBAL::)’
1
So maybe you should just bind to the key in GLOBAL:: ?
$ 6 'BEGIN GLOBAL:: := class { }; dd Test.new'
.new
Now, perhaps this can be fixed by having a nqp::decont() somewhere deep in the
bowels for every reference to something in GLOBAL:: . But I fear that, even
if it only a little bit of overhead, it’s overhead we don’t need.
An alternate option would be to create a Stash.ASSIGN-KEY that would not create
a container, but instead would bind. But that also feels a bit too magical to
me.
So I think we should mark this ticket as “DIHWIDT”, and point to the workaround
of binding.
> On 3 Dec 2017, at 11:23, Aleks-Daniel Jakimenko-Aleksejev via RT
> wrote:
>
> As of today (2017.11,HEAD(e5b660e)) it prints this:
>
> Cannot call method 'new' on a null object
> in block at -e line 1
>
> Which is arguably reasonable, but I guess it's not good enough.
>
> On 2014-09-24 04:03:12, masak wrote:
>> m: BEGIN GLOBAL:: = class { }; Test.new;
>> rakudo-moar 682e03: OUTPUT«===SORRY!===Object of type
>> in QAST::WVal, but not in SC»
>> nine: looks like a bug.
>> masak: any idea how I can create a class with a fully qualified
>> name from an EVAL that's deep in some other namespace?
>> masak: as in Inline::Perl5::Perl6PackageCreator::create runs an
>> EVAL that should create a class called Foo::Bar::Baz.
>> nine: EVAL "class Foo::Bar::Baz {}" doesn't cut it ?
>> alternately EVAL "class Foo { class Bar { class Baz {}}}' ?
>> or actually, maybe both?
>> lizmat: nope, that creates
>> Inline::Perl5::Perl6PackageCreator::Foo::Bar::Baz (what a handy name
>> ;)
>> m: BEGIN GLOBAL:: := class { }; Test.new;
>> rakudo-moar 682e03: ( no output )
>> ah, := works, while = does not
>> nine: Does class GLOBAL::Foo::Bar::Baz { } not do it?
>> jnthn: no, the GLOBAL:: is pretty much ignored
>> ah
>> Maybe that wants fixing
>> But afer dinner
>> * masak submits rakudobug
>> jnthn: according to S10, GLOBAL:: should do it though
>> nine: That's my feeling too
[perl #122838] [BUG] BEGIN GLOBAL:: assignment does not work in Rakudo
As of today (2017.11,HEAD(e5b660e)) it prints this:
Cannot call method 'new' on a null object
in block at -e line 1
Which is arguably reasonable, but I guess it's not good enough.
On 2014-09-24 04:03:12, masak wrote:
> m: BEGIN GLOBAL:: = class { }; Test.new;
> rakudo-moar 682e03: OUTPUT«===SORRY!===Object of type
> in QAST::WVal, but not in SC»
> nine: looks like a bug.
> masak: any idea how I can create a class with a fully qualified
> name from an EVAL that's deep in some other namespace?
> masak: as in Inline::Perl5::Perl6PackageCreator::create runs an
> EVAL that should create a class called Foo::Bar::Baz.
> nine: EVAL "class Foo::Bar::Baz {}" doesn't cut it ?
> alternately EVAL "class Foo { class Bar { class Baz {}}}' ?
> or actually, maybe both?
> lizmat: nope, that creates
> Inline::Perl5::Perl6PackageCreator::Foo::Bar::Baz (what a handy name
> ;)
> m: BEGIN GLOBAL:: := class { }; Test.new;
> rakudo-moar 682e03: ( no output )
> ah, := works, while = does not
> nine: Does class GLOBAL::Foo::Bar::Baz { } not do it?
> jnthn: no, the GLOBAL:: is pretty much ignored
> ah
> Maybe that wants fixing
> But afer dinner
> * masak submits rakudobug
> jnthn: according to S10, GLOBAL:: should do it though
> nine: That's my feeling too
[perl #123776] [BUG] Binding a variable at BEGIN time doesn't stick aruond for runtime
Still reproducible (2017.11, HEAD(5929887)), but is supposed to work?
On 2015-02-09 17:43:52, rayd...@cyberuniverses.com wrote:
> m: my $a; BEGIN { $a := 1; say $a; }; say $a;
> rakudo-{parrot,moar} 0cb22e: OUTPUT«1(Any)»
>
> m: my $a; BEGIN { $a = 1; say $a; }; say $a; # works with assignment
> rakudo-{parrot,moar} 0cb22e: OUTPUT«11»
[perl #132377] [BUG][POD] tables inside =begin/=end comment pairs cause exception
On Mon, 30 Oct 2017 09:16:23 -0700, tbrowder wrote: > On Mon, 30 Oct 2017 08:21:04 -0700, tbrowder wrote: > > On Mon, Oct 30, 2017 at 09:53 Elizabeth Mattijsen wrote: > > > > > A —ll-exception stacktrace would be useful in such a case :-) > > > > > > WILCO! $ cat prob.p6 use v6; # an empty table =begin comment =begin table a b c =end table =end comment to duplicate: $ perl6 --ll-exception --doc=Text prob.p6 version: $ perl6 -v This is Rakudo version 2017.09-201-gfa8fe84 built on MoarVM version 2017.09.1-553-ga4fef0b implementing Perl 6.c.
[perl #132377] [BUG][POD] tables inside =begin/=end comment pairs cause exception
On Mon, 30 Oct 2017 08:21:04 -0700, tbrowder wrote: > On Mon, Oct 30, 2017 at 09:53 Elizabeth Mattijsen wrote: > > > A —ll-exception stacktrace would be useful in such a case :-) > > > WILCO! Expected "=end comment" to terminate "=begin comment"; found "=end table" instead. at SETTING::src/core/Exception.pm:57 (/usr/local/rakudo.d/share/perl6/runtime/CORE.setting.moarvm:throw) from src/Perl6/World.nqp:4630 (/usr/local/rakudo.d/share/nqp/lib/Perl6/World.moarvm:throw) from src/Perl6/Grammar.nqp:272 (/usr/local/rakudo.d/share/nqp/lib/Perl6/Grammar.moarvm:typed_panic) from src/Perl6/Grammar.nqp:910 (/usr/local/rakudo.d/share/nqp/lib/Perl6/Grammar.moarvm:pod_block:sym) from gen/moar/stage2/QRegex.nqp:1721 (/usr/local/rakudo.d/share/nqp/lib/QRegex.moarvm:!protoregex) from :1 (/usr/local/rakudo.d/share/nqp/lib/Perl6/Grammar.moarvm:pod_block) from :1 (/usr/local/rakudo.d/share/nqp/lib/Perl6/Grammar.moarvm:pod_content_toplevel) from :1 (/usr/local/rakudo.d/share/nqp/lib/Perl6/Grammar.moarvm:unv) from :1 (/usr/local/rakudo.d/share/nqp/lib/Perl6/Grammar.moarvm:_ws) from src/Perl6/Grammar.nqp:630 (/usr/local/rakudo.d/share/nqp/lib/Perl6/Grammar.moarvm:ws) from src/Perl6/Grammar.nqp:1237 (/usr/local/rakudo.d/share/nqp/lib/Perl6/Grammar.moarvm:statementlist) from gen/moar/stage2/NQPHLL.nqp:1105 (/usr/local/rakudo.d/share/nqp/lib/NQPHLL.moarvm:LANG) from src/Perl6/Grammar.nqp:1676 (/usr/local/rakudo.d/share/nqp/lib/Perl6/Grammar.moarvm:FOREIGN_LANG) from src/Perl6/Grammar.nqp:1201 (/usr/local/rakudo.d/share/nqp/lib/Perl6/Grammar.moarvm:comp_unit) from src/Perl6/Grammar.nqp:508 (/usr/local/rakudo.d/share/nqp/lib/Perl6/Grammar.moarvm:TOP) from gen/moar/stage2/QRegex.nqp:2330 (/usr/local/rakudo.d/share/nqp/lib/QRegex.moarvm:parse) from gen/moar/stage2/NQPHLL.nqp:1864 (/usr/local/rakudo.d/share/nqp/lib/NQPHLL.moarvm:parse) from gen/moar/stage2/NQPHLL.nqp:1780 (/usr/local/rakudo.d/share/nqp/lib/NQPHLL.moarvm:execute_stage) from gen/moar/stage2/NQPHLL.nqp:1813 (/usr/local/rakudo.d/share/nqp/lib/NQPHLL.moarvm:run) from gen/moar/stage2/NQPHLL.nqp:1816 (/usr/local/rakudo.d/share/nqp/lib/NQPHLL.moarvm:) from gen/moar/stage2/NQPHLL.nqp:1802 (/usr/local/rakudo.d/share/nqp/lib/NQPHLL.moarvm:compile) from gen/moar/stage2/NQPHLL.nqp:1511 (/usr/local/rakudo.d/share/nqp/lib/NQPHLL.moarvm:eval) from gen/moar/stage2/NQPHLL.nqp:1757 (/usr/local/rakudo.d/share/nqp/lib/NQPHLL.moarvm:evalfiles) from gen/moar/stage2/NQPHLL.nqp:1682 (/usr/local/rakudo.d/share/nqp/lib/NQPHLL.moarvm:command_eval) from src/Perl6/Compiler.nqp:42 (/usr/local/rakudo.d/share/nqp/lib/Perl6/Compiler.moarvm:command_eval) from gen/moar/stage2/NQPHLL.nqp:1617 (/usr/local/rakudo.d/share/nqp/lib/NQPHLL.moarvm:command_line) from gen/moar/main.nqp:47 (/usr/local/rakudo.d/share/perl6/runtime/perl6.moarvm:MAIN) from gen/moar/main.nqp:38 (/usr/local/rakudo.d/share/perl6/runtime/perl6.moarvm:) from :1 (/usr/local/rakudo.d/share/perl6/runtime/perl6.moarvm:) from :1 (/usr/local/rakudo.d/share/perl6/runtime/perl6.moarvm:) prob.p6 Description: Binary data
Re: [perl #132377] [BUG][POD] tables inside =begin/=end comment pairs cause exception
On Mon, Oct 30, 2017 at 09:53 Elizabeth Mattijsen wrote: > A —ll-exception stacktrace would be useful in such a case :-) WILCO!
Re: [perl #132377] [BUG][POD] tables inside =begin/=end comment pairs cause exception
On Mon, Oct 30, 2017 at 09:53 Elizabeth Mattijsen wrote: > A —ll-exception stacktrace would be useful in such a case :-) WILCO!
Re: [perl #132377] [BUG][POD] tables inside =begin/=end comment pairs cause exception
A —ll-exception stacktrace would be useful in such a case :-) > On 30 Oct 2017, at 15:24, Tom Browder (via RT) > wrote: > > # New Ticket Created by Tom Browder > # Please include the string: [perl #132377] > # in the subject line of all future correspondence about this issue. > # https://rt.perl.org/Ticket/Display.html?id=132377 > > > > The following pod causes an exception > > =begin comment > =begin table > a | b | c > =end table > =end comment > > If the =begin/=end table lines are indented by one space the exception is > not thrown
Re: [perl #132377] [BUG][POD] tables inside =begin/=end comment pairs cause exception
A —ll-exception stacktrace would be useful in such a case :-) > On 30 Oct 2017, at 15:24, Tom Browder (via RT) > wrote: > > # New Ticket Created by Tom Browder > # Please include the string: [perl #132377] > # in the subject line of all future correspondence about this issue. > # https://rt.perl.org/Ticket/Display.html?id=132377 > > > > The following pod causes an exception > > =begin comment > =begin table > a | b | c > =end table > =end comment > > If the =begin/=end table lines are indented by one space the exception is > not thrown
[perl #132377] [BUG][POD] tables inside =begin/=end comment pairs cause exception
# New Ticket Created by Tom Browder # Please include the string: [perl #132377] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=132377 > The following pod causes an exception =begin comment =begin table a | b | c =end table =end comment If the =begin/=end table lines are indented by one space the exception is not thrown
[perl #122789] [BUG] `.subst` does not work inside BEGIN block ($/ is set too late)
Fix: https://github.com/rakudo/rakudo/commit/a62b221a8048238edaa1f6e62070b42ed8bd5cd3 Test: https://github.com/perl6/roast/commit/9585230c26
[perl #122789] [BUG] `.subst` does not work inside BEGIN block ($/ is set too late)
Fix: https://github.com/rakudo/rakudo/commit/a62b221a8048238edaa1f6e62070b42ed8bd5cd3 Test: https://github.com/perl6/roast/commit/9585230c26
[perl #129247] [CONC][BUG] Wait on a Supply after begin tap is hanging
On Thu, 13 Jul 2017 16:49:00 -0700, ug...@cpan.org wrote: > Resolved in: https://github.com/rakudo/rakudo/commit/32b72cd > > Tests: https://github.com/perl6/roast/commit/927b026 Bug fixed and tests added, closing issue.
[perl #129247] [CONC][BUG] Wait on a Supply after begin tap is hanging
Resolved in: https://github.com/rakudo/rakudo/commit/32b72cd Tests: https://github.com/perl6/roast/commit/927b026
[perl #130505] [LTA] double SORRY (BEGIN (1, 2)[*-1])
# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev # Please include the string: [perl #130505] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=130505 > Code: BEGIN (1, 2)[*-1] Result: ===SORRY!=== Error while compiling An exception occurred while evaluating a BEGIN at :1 Exception details: ===SORRY!=== Error while compiling Cannot invoke this object (REPR: Null; VMNull) at : Once is enough, especially given that it says “at : ” which is not useful.
[perl #130389] [BUG] constant with BEGIN block triggers QAST::Block with cuid 4 has not appeared
# New Ticket Created by Zoffix Znet
# Please include the string: [perl #130389]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=130389 >
m: constant HNY = BEGIN DateTime.new(year => .year + (1 if .month <=
6)).utc given DateTime.now.utc; dd HNY
rakudo-moar 660b0b: OUTPUT«===SORRY!===QAST::Block with cuid 4 has
not appeared»
m: constant HNY = BEGIN { DateTime.new(year => .year + (1 if .month
<= 6)).utc given DateTime.now.utc }; dd HNY
rakudo-moar 660b0b: OUTPUT«===SORRY!===QAST::Block with cuid 4 has
not appeared»
m: constant $HNY = BEGIN { DateTime.new(year => .year + (1 if .month
<= 6)).utc given DateTime.now.utc }; dd HNY
rakudo-moar 660b0b: OUTPUT«===SORRY!=== Error while compiling
Undeclared name:HNY used at line 1»
m: constant $HNY = BEGIN { DateTime.new(year => .year + (1 if .month
<= 6)).utc given DateTime.now.utc }; dd $HNY
rakudo-moar 660b0b: OUTPUT«===SORRY!===QAST::Block with cuid 4 has
not appeared»
[perl #129247] [BUG] Wait on a Supply after begin tap is hanging
# New Ticket Created by Pierre VIGIER
# Please include the string: [perl #129247]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=129247 >
Hi,
i stumbled a across a strange behaviour when playing with Supplier, i tried to
gulf it down, starting from the documentation of supply. The following code,
taken from the documentation and slightly modified is working as expected:
my $s = Supplier.new;
my $l = $s.Supply();
start {
sleep 1;
$s.emit(1);
$s.emit(2);
$s.done;
}
$l.wait;
say "done";
If i tap the $l variable to display the value that are supplied by the
supplier, it then hangs indefinitely:
my $s = Supplier.new;
my $l = $s.Supply();
$l.tap( -> $v { say "got : $v" } );
start {
sleep 1;
$s.emit(1);
$s.emit(2);
$s.done;
}
$l.wait;
say "done";
Pierre
[perl #129247] [BUG] Wait on a Supply after begin tap is hanging
On Sun Sep 11 07:01:11 2016, pierre.vig...@gmail.com wrote:
> Hi,
>
> i stumbled a across a strange behaviour when playing with Supplier, i
> tried to gulf it down, starting from the documentation of supply. The
> following code, taken from the documentation and slightly modified is
> working as expected:
>
> my $s = Supplier.new;
> my $l = $s.Supply();
> start {
> sleep 1;
> $s.emit(1);
> $s.emit(2);
> $s.done;
> }
> $l.wait;
> say "done";
>
> If i tap the $l variable to display the value that are supplied by the
> supplier, it then hangs indefinitely:
>
> my $s = Supplier.new;
> my $l = $s.Supply();
> $l.tap( -> $v { say "got : $v" } );
> start {
> sleep 1;
> $s.emit(1);
> $s.emit(2);
> $s.done;
> }
> $l.wait;
> say "done";
>
> Pierre
I tried to debug this, but ultimately failed, as I'm getting spectest failures.
There are actually three issues:
1) Supply.sanitize uses a per-instance $!finished attribute and when the first
tap gets closed, no more taps get closed. This is what causes the OP bug.
2) Supply.wait calls Supply.Promise that opens a new tap that keeps/breaks the
Promise on done/quit. However, if this is done on-already finished Supply, that
Promise will never complete, causing in a hang in .wait. This is what causes
the bug if we golf OP's code to get rid of the start {}.
3) To me, it looks like there's a race condition with regards to $!finished,
since one tap can be setting it to `1`, while another is mid-checking it. Not
sure if it matters.
Below is my attempt at fixing it that fixes issues #1 and #2 (where .wait on a
finished supply returns a Nil), however, this has failures in
t/spec/S17-supply/basic.t because I'm not returning a Tap, I think.
I've also no idea why the created supplies go through the .serialize ->
.sanitize chain where both methods look nearly identical. I'm leaving this for
someone more knowledgeable to finish.
--8<-
diff --git a/src/core/Supply.pm b/src/core/Supply.pm
index d91c3b8..f0fa251 100644
--- a/src/core/Supply.pm
+++ b/src/core/Supply.pm
@@ -197,6 +197,7 @@ my class Supply {
method tap(&emit, &done, &quit) {
my int $cleaned-up = 0;
+return if $!finished;
my $source-tap = $!source.tap(
-> \value{
emit(value) unless $!finished;
@@ -204,16 +205,16 @@ my class Supply {
done => -> {
unless $!finished {
$!finished = 1;
-done();
self!cleanup($cleaned-up, $source-tap);
}
+done();
},
quit => -> $ex {
unless $!finished {
$!finished = 1;
-quit($ex);
self!cleanup($cleaned-up, $source-tap);
}
+quit($ex);
});
Tap.new({ self!cleanup($cleaned-up, $source-tap) })
}
@@ -610,10 +611,11 @@ my class Supply {
my $p = Promise.new;
my $v = $p.vow;
my $final := Nil;
-my $t = self.tap:
+my $t = self.tap(
-> \val { $final := val },
done => { $v.keep($final) },
-quit => -> \ex { $v.break(ex) };
+quit => -> \ex { $v.break(ex) },
+) or $v.keep(Nil);
$p
}
--8<-
[perl #127538] BEGIN require Test <&ok>;
On Sat Feb 13 16:21:50 2016, lloyd.fo...@gmail.com wrote:
> BEGIN require Test <&ok>;
>
> Lexical with name '&ok' does not exist in this frame
Note that this works:
> BEGIN { require Test "&ok"}
(Test)
--
Will "Coke" Coleda
Re: [perl #128984] Feature request (wontfix?): perl -c executes BEGIN and CHECK blocks
Thank you for the clarification. That means that at the moment, most files (i.e. the ones written in OO) will have a have errors without a BEGIN block (i.e. the use of self). As 'perl6 -c' being for now the *only* way to check the syntax of a code file, the security concerns should not be easily disregarded. In the best case, users will have to jump through loops to have the functionality enabled 'at their own risk', in the worst case people will blame Perl 6 for stupid/dangerous done to their environment while "reading a code file with their editor". I am just thinking out loud, but could a different restricted core binary with only a subset of the code provide the necessary parsing capabilities? An alternative could be external tools implementing the parsing/linting of code (maybe something using DrForr's future Perl6::Tidy?), but in that case we would risk to have something playing catch-up to new Perl 6 releases. C. On Fri, Aug 19, 2016 at 1:25 AM, Brandon Allbery via RT < perl6-bugs-follo...@perl.org> wrote: > On Thu, Aug 18, 2016 at 6:18 PM, Claudio wrote: > > > Taking Brandon's answer in considiration, does this mean that no perl6 > > code could be parsed as correct without (implicit) BEGIN blocks or that > it > > will only work in -let's say- 99% of the time (file without a begin > block)? > > > I did say "while this is less true for perl 6 code in the wild" --- in perl > 5, disabling BEGIN blocks means losing all "use" directives. But for perl > 6, you still have to worry about classes not being defined properly because > their definitions are run (!) at compile time. > > -- > brandon s allbery kf8nh sine nomine > associates > allber...@gmail.com > ballb...@sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > >
Re: [perl #128984] Feature request (wontfix?): perl -c executes BEGIN and CHECK blocks
On Thu, Aug 18, 2016 at 6:18 PM, Claudio wrote: > Taking Brandon's answer in considiration, does this mean that no perl6 > code could be parsed as correct without (implicit) BEGIN blocks or that it > will only work in -let's say- 99% of the time (file without a begin block)? I did say "while this is less true for perl 6 code in the wild" --- in perl 5, disabling BEGIN blocks means losing all "use" directives. But for perl 6, you still have to worry about classes not being defined properly because their definitions are run (!) at compile time. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #128984] Feature request (wontfix?): perl -c executes BEGIN and CHECK blocks
On Thu, Aug 18, 2016 at 6:21 PM, Patrick R. Michaud via RT <
perl6-bugs-follo...@perl.org> wrote:
> On Thu, Aug 18, 2016 at 10:38:57AM -0400, Brandon Allbery wrote:
> > On Thu, Aug 18, 2016 at 9:13 AM, Claudio
> > wrote:
> >
> > > Tools like vim-syntastic and atom use 'perl6-c' (the only valid linter
> for
> > > now) to report syntax errors. Because "perl6 -c" executes code (BEGIN
> and
> > > CHECK blocks as documented), this is a security concern for external
> code.
> >
> > The problem is that you probably can't parse the code successfully if you
> > can't run BEGIN blocks. While this is currently less true of perl 6 code
> in
> > the wild, it's actually even worse in potential than perl 5's ability to
> > mutate its parser because a module can implement entire new languages.
>
> Also, many things in Perl 6 get executed at BEGIN time even if they're
> not explicitly in a BEGIN block. Constant and class declarations come
> to mind, but I'm sure there are more.
>
> For example:
>
> $ cat xyz.p6
> use v6;
>
> say "1: mainline";
> constant $a = say "2: constant";
> BEGIN { say "3: BEGIN"; }
>
> $ ./perl6 xyz.p6
> 2: constant
> 3: BEGIN
> 1: mainline
>
> Patrick,
Taking Brandon's answer in considiration, does this mean that no perl6 code
could be parsed as correct without (implicit) BEGIN blocks or that it will
only work in -let's say- 99% of the time (file without a begin block)?
C.
Re: [perl #128984] Feature request (wontfix?): perl -c executes BEGIN and CHECK blocks
On Thu, Aug 18, 2016 at 10:38:57AM -0400, Brandon Allbery wrote:
> On Thu, Aug 18, 2016 at 9:13 AM, Claudio
> wrote:
>
> > Tools like vim-syntastic and atom use 'perl6-c' (the only valid linter for
> > now) to report syntax errors. Because "perl6 -c" executes code (BEGIN and
> > CHECK blocks as documented), this is a security concern for external code.
>
> The problem is that you probably can't parse the code successfully if you
> can't run BEGIN blocks. While this is currently less true of perl 6 code in
> the wild, it's actually even worse in potential than perl 5's ability to
> mutate its parser because a module can implement entire new languages.
Also, many things in Perl 6 get executed at BEGIN time even if they're
not explicitly in a BEGIN block. Constant and class declarations come
to mind, but I'm sure there are more.
For example:
$ cat xyz.p6
use v6;
say "1: mainline";
constant $a = say "2: constant";
BEGIN { say "3: BEGIN"; }
$ ./perl6 xyz.p6
2: constant
3: BEGIN
1: mainline
Pm
Re: [perl #128984] Feature request (wontfix?): perl -c executes BEGIN and CHECK blocks
On Thu, Aug 18, 2016 at 9:13 AM, Claudio wrote: > Tools like vim-syntastic and atom use 'perl6-c' (the only valid linter for > now) to report syntax errors. Because "perl6 -c" executes code (BEGIN and > CHECK blocks as documented), this is a security concern for external code. The problem is that you probably can't parse the code successfully if you can't run BEGIN blocks. While this is currently less true of perl 6 code in the wild, it's actually even worse in potential than perl 5's ability to mutate its parser because a module can implement entire new languages. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
[perl #128984] Feature request (wontfix?): perl -c executes BEGIN and CHECK blocks
# New Ticket Created by Claudio # Please include the string: [perl #128984] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=128984 > Hi, This is more of a post-it note than a real feature request, but here it goes (related with #128983) Tools like vim-syntastic and atom use 'perl6-c' (the only valid linter for now) to report syntax errors. Because "perl6 -c" executes code (BEGIN and CHECK blocks as documented), this is a security concern for external code. Because of this, the perl 5 (perl -c) and perl 6 syntax checkers are disabled by default and must be explicitly enabled by the user. C.
Re: [perl #126264] LTA error message for keywords like "eval" or "begin" in lower case
Fixed with 1728139 , tests needed, MasterDuke17++ for actual code.
> On 05 Oct 2015, at 08:18, quester (via RT)
> wrote:
>
> # New Ticket Created by quester
> # Please include the string: [perl #126264]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=126264 >
>
>
> If you absent-mindedly type in keywords that should be capitalized in lower
> case, the compiler will not suggest the correct upper case form. For example:
>
> $ perl6
>> say EVAL "2+2";
> 4
>> say eval "2+2";
> ===SORRY!=== Error while compiling
> Undeclared routine:
> eval used at line 1. Did you mean 'val'?
>
>> BEGIN {say pi}
> 3.14159265358979
>> begin {say pi}
> ===SORRY!=== Error while compiling
> Undeclared routine:
>begin used at line 1
>
>>
>
>
> Best regards,
> quester
[perl #127538] BEGIN require Test <&ok>;
# New Ticket Created by Lloyd Fournier # Please include the string: [perl #127538] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=127538 > BEGIN require Test <&ok>; Lexical with name '&ok' does not exist in this frame
Re: [perl #127192] [BUG] Producing output in BEGIN blocks errors out precompilation
(and now I see that hoelz re-opened the ticket)
On Thu, Jan 7, 2016 at 5:03 AM Lloyd Fournier wrote:
> see:
>
> https://rt.perl.org/Public/Bug/Display.html?id=127086
>
> IMHO even if it's a WONTFIX atm we should still have at least one ticket
> open to address this.
>
> LL
>
> On Thu, Jan 7, 2016 at 4:22 AM Zoffix Znet
> wrote:
>
>> # New Ticket Created by Zoffix Znet
>> # Please include the string: [perl #127192]
>> # in the subject line of all future correspondence about this issue.
>> # https://rt.perl.org/Ticket/Display.html?id=127192 >
>>
>>
>> See evaluated code below and the error it produces (Constraint type check
>> failed for parameter '$precomp-id'). This does not appear if the `say`
>> statement is removed. I also tried using `put`, producing the same error.
>>
>>
>> $ cat Foo.pm6
>> class Foo {
>> BEGIN { say 42 };
>> }
>> $ perl6 -I. -e 'use Foo'
>> ===SORRY!===
>> Constraint type check failed for parameter '$precomp-id'
>> $ perl6 -I. -e 'use Foo'
>> ===SORRY!===
>> Failed to open file
>> /tmp/tmp.9290Wjs0ef/.precomp/01577C41E8B9AB77E8C1E6F68F5D1DA5A4F04EE9.1452007419.50358/6E/6E428ABBFD62CCF8C57C45F9E4329CB0A420A920.deps:
>> no such file or directory
>> $ perl6 -I. -e 'use Foo'
>>
>
Re: [perl #127192] [BUG] Producing output in BEGIN blocks errors out precompilation
see:
https://rt.perl.org/Public/Bug/Display.html?id=127086
IMHO even if it's a WONTFIX atm we should still have at least one ticket
open to address this.
LL
On Thu, Jan 7, 2016 at 4:22 AM Zoffix Znet
wrote:
> # New Ticket Created by Zoffix Znet
> # Please include the string: [perl #127192]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=127192 >
>
>
> See evaluated code below and the error it produces (Constraint type check
> failed for parameter '$precomp-id'). This does not appear if the `say`
> statement is removed. I also tried using `put`, producing the same error.
>
>
> $ cat Foo.pm6
> class Foo {
> BEGIN { say 42 };
> }
> $ perl6 -I. -e 'use Foo'
> ===SORRY!===
> Constraint type check failed for parameter '$precomp-id'
> $ perl6 -I. -e 'use Foo'
> ===SORRY!===
> Failed to open file
> /tmp/tmp.9290Wjs0ef/.precomp/01577C41E8B9AB77E8C1E6F68F5D1DA5A4F04EE9.1452007419.50358/6E/6E428ABBFD62CCF8C57C45F9E4329CB0A420A920.deps:
> no such file or directory
> $ perl6 -I. -e 'use Foo'
>
[perl #127192] [BUG] Producing output in BEGIN blocks errors out precompilation
# New Ticket Created by Zoffix Znet
# Please include the string: [perl #127192]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=127192 >
See evaluated code below and the error it produces (Constraint type check
failed for parameter '$precomp-id'). This does not appear if the `say`
statement is removed. I also tried using `put`, producing the same error.
$ cat Foo.pm6
class Foo {
BEGIN { say 42 };
}
$ perl6 -I. -e 'use Foo'
===SORRY!===
Constraint type check failed for parameter '$precomp-id'
$ perl6 -I. -e 'use Foo'
===SORRY!===
Failed to open file
/tmp/tmp.9290Wjs0ef/.precomp/01577C41E8B9AB77E8C1E6F68F5D1DA5A4F04EE9.1452007419.50358/6E/6E428ABBFD62CCF8C57C45F9E4329CB0A420A920.deps:
no such file or directory
$ perl6 -I. -e 'use Foo'
Re: [perl #127086] Calling subroutines from CORE fails in BEGIN blocks in loaded modules
I have had this happen too. I think it's actually doing anything that writes to stdout during compile time rather than calling CORE but I could be wrong. On Thu, 31 Dec 2015 at 1:26 AM, Rob Hoelz wrote: > # New Ticket Created by Rob Hoelz > # Please include the string: [perl #127086] > # in the subject line of all future correspondence about this issue. > # https://rt.perl.org/Ticket/Display.html?id=127086 > > > > For example, in test.pl: > > > use TestModule; > > in TestModule.pm: > > > BEGIN say 'hi'; > > If we run test.pl, we get the following failure: > > ===SORRY!=== > Constraint type check failed for parameter '$precomp-id' > > The commit that introduces the problem is 54e0577 on Rakudo. >
[perl #127086] Calling subroutines from CORE fails in BEGIN blocks in loaded modules
# New Ticket Created by Rob Hoelz # Please include the string: [perl #127086] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=127086 > For example, in test.pl: > use TestModule; in TestModule.pm: > BEGIN say 'hi'; If we run test.pl, we get the following failure: ===SORRY!=== Constraint type check failed for parameter '$precomp-id' The commit that introduces the problem is 54e0577 on Rakudo.
[perl #127034] precomp - BEGIN inside EXPORT::DEFAULT cannot invoke this object
# New Ticket Created by Lloyd Fournier
# Please include the string: [perl #127034]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=127034 >
#lib/beginprecomp.pm
my package EXPORT::DEFAULT {
BEGIN {
OUR::{'&foo'} = sub (|) { say "foo" }
}
}
perl6 -Ilib -e 'use beginprecomp; foo'
#!>Cannot invoke this object
[perl #126630] LTA error message with nested SORRY: BEGIN { &?ROUTINE.name }
# New Ticket Created by Alex Jakimenko
# Please include the string: [perl #126630]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=126630 >
Code:
sub test { BEGIN { &?ROUTINE.name } }
Result:
===SORRY!=== Error while compiling /home/alex/perl6test/./test3.pl
An exception occurred while evaluating a BEGIN
at /home/alex/perl6test/./test3.pl:2
Exception details:
===SORRY!=== Error while compiling
Cannot call method 'name' on a null object
at :
Whoops! It seems like it errored out while producing the error message.
That's so cool!
I don't think that someone will stumble upon this particular code ever, but
perhaps there are other times when it could break like this?
Interestingly, we can keep adding BEGIN blocks and we will be getting
different funny messages:
sub test {
BEGIN { BEGIN { &?ROUTINE.name; } }
}
Result:
===SORRY!=== Error while compiling /home/alex/perl6test/./test3.pl
An exception occurred while evaluating a BEGIN
at /home/alex/perl6test/./test3.pl:3
Exception details:
===SORRY!=== Error while compiling
ctxcode needs an MVMContext
at :
Or even more:
sub test {
BEGIN { BEGIN { BEGIN { &?ROUTINE.name; } } }
}
Result:
===SORRY!=== Error while compiling /home/alex/perl6test/./test3.pl
An exception occurred while evaluating a BEGIN
at /home/alex/perl6test/./test3.pl:3
Exception details:
===SORRY!=== Error while compiling
ctxouter needs an MVMContext
at :
Maybe somebody could find a way to make it more brutal? :)
[perl #126264] LTA error message for keywords like "eval" or "begin" in lower case
# New Ticket Created by quester
# Please include the string: [perl #126264]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=126264 >
If you absent-mindedly type in keywords that should be capitalized in lower
case, the compiler will not suggest the correct upper case form. For example:
$ perl6
> say EVAL "2+2";
4
> say eval "2+2";
===SORRY!=== Error while compiling
Undeclared routine:
eval used at line 1. Did you mean 'val'?
> BEGIN {say pi}
3.14159265358979
> begin {say pi}
===SORRY!=== Error while compiling
Undeclared routine:
begin used at line 1
>
Best regards,
quester
[perl #123777] [BUG] List assignment in a BEGIN block causes a crash at runtime
This works on the 'glr' branch:
$ perl6-m -e 'my @a; BEGIN { @a = 42; }; say @a;'
[42]
The test in S04-phasers/begin.t was unfudged with commit
https://github.com/perl6/roast/commit/b8a19c981c. I'm closing this ticket as
'resolved'.
[perl #123308] [BUG] dir '/' results begin with 2 slashes
I added a test to S32-io/dir.t with commit https://github.com/perl6/roast/commit/29d41333b2. I'm closing this ticket as 'resolved'.
[perl #123777] [BUG] List assignment in a BEGIN block causes a crash at runtime
# New Ticket Created by
# Please include the string: [perl #123777]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=123777 >
r: my @a; BEGIN { @a = 1; }; say @a;
rakudo-moar 0cb22e: OUTPUT«This type does not support elems in method REIFY
at src/gen/m-CORE.setting:9891 in method REIFY at
src/gen/m-CORE.setting:10357 in method reify at src/gen/m-CORE.setting:8942
in block at src/gen/m-CORE.setting:8967 in method reify at s…»
..rakudo-parrot 0cb22e: OUTPUT«This type does not support elems in method
REIFY at gen/parrot/CORE.setting:9828 in method REIFY at
gen/parrot/CORE.setting:10301 in method reify at
gen/parrot/CORE.setting:8940 in block at gen/parrot/CORE.setting:8927 in
method reif…»
r: my @a; BEGIN { @a = 1; say @a; }; say @a; # works if you reify in the BEGIN
block
rakudo-{parrot,moar} 0cb22e: OUTPUT«11»
r: my %a; BEGIN { %a = 1 => 1 }; say %a; # works on hashes
rakudo-{parrot,moar} 0cb22e: OUTPUT«1 => 1»
[perl #123776] [BUG] Binding a variable at BEGIN time doesn't stick aruond for runtime
# New Ticket Created by
# Please include the string: [perl #123776]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=123776 >
m: my $a; BEGIN { $a := 1; say $a; }; say $a;
rakudo-{parrot,moar} 0cb22e: OUTPUT«1(Any)»
m: my $a; BEGIN { $a = 1; say $a; }; say $a; # works with assignment
rakudo-{parrot,moar} 0cb22e: OUTPUT«11»
[perl #123308] [BUG] dir '/' results begin with 2 slashes
This was fixed by lizmat++ with commit https://github.com/rakudo/rakudo/commit/482cc32e89 $ perl6 -e 'say dir "/"' "/.snap".IO "/dev".IO "/tmp".IO ... But I wonder if the following test would work on Windows also: $ PERL6LIB=lib ./perl6 -e 'use Test; my $res = dir "/"; ok $res !~~ m/ "/" ** 2 /, "dir \"/\" results do not begin with two slashes"' ok 1 - dir "/" results do not begin with two slashes
[perl #123308] [BUG] dir '/' results begin with 2 slashes
# New Ticket Created by # Please include the string: [perl #123308] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=123308 > perl6 -e 'say dir "/"' gives "//opt".IO "//home".IO ... Haven't noticed doubling slashes in any situations besides '/' so far This is perl6 version 2014.11-30-gac27d2f built on MoarVM version 2014.11-45-ge1016ad
[perl #102478] [BUG] Attributes can't be declared inside of a BEGIN eval in Rakudo
All of this looks good now (results are identical on Moar, Parrot and JVM):
$ perl6 -e 'has $.x'
===SORRY!=== Error while compiling -e
You cannot declare attribute '$.x' here; maybe you'd like a class or a role?
at -e:1
--> has $.x⏏
expecting any of:
scoped declarator
constraint
$ perl6 -e 'class A { BEGIN EVAL q[has $.x] }; say A.new(x => 3).x'
3
$ perl6-m -e 'class A { EVAL q[has $.x] }; say A.new(x => 3).x'
No such method 'x' for invocant of type 'A'
in block at -e:1
I added tests to S12-attributes/undeclared.t and S12-attributes/class.t with
commit https://github.com/perl6/roast/commit/7f8180122c
I'm closing this ticket now.
[perl #111766] [BUG] Lexical lookup doesn't work properly from an END block to a surrounding BEGIN block in Rakudo
This works now (output is identical on Moar, Parrot and JVM):
$ perl6 -e 'my $a = 42; END { say $a }'
42
$ perl6 -e 'BEGIN { my $a = 42; END { say $a } }'
42
I added two tests to S04-phasers/end.t with commit
https://github.com/perl6/roast/commit/958f3520e7
I'm closing this ticket now.
[perl #119749] [BUG] Null PMC access when looping over SomeEnum.enums in a blockless BEGIN in Rakudo
There is still a Null PMC access on Parrot. On Moar and JVM it runs fine:
$ perl6-p -e 'enum A (a=>3); BEGIN for A.enums { }'
===SORRY!===
Null PMC access in get_bool()
$ perl6-m -e 'enum A (a=>3); BEGIN for A.enums { }; say "alive"'
alive
$ perl6-j -e 'enum A (a=>3); BEGIN for A.enums { }; say "alive"'
alive
I added a test (fudged 'skip' for Parrot) to S04-phasers/begin.t with commit
https://github.com/perl6/roast/commit/489ebb2e46.
[perl #115502] [BUG] 'try' at BEGIN time hangs in Rakudo
This does no longer hang.
$ perl6-m -e 'BEGIN { try 0 }; say "alive"'
alive
$ perl6-p -e 'BEGIN { try 0 }; say "alive"'
alive
$ perl6-j -e 'BEGIN { try 0 }; say "alive"'
alive
I added a test to S04-phasers/begin.t with the following commit:
https://github.com/perl6/roast/commit/05bf75e3b6
[perl #122838] [BUG] BEGIN GLOBAL:: assignment does not work in Rakudo
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #122838]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=122838 >
m: BEGIN GLOBAL:: = class { }; Test.new;
rakudo-moar 682e03: OUTPUT«===SORRY!===Object of type
in QAST::WVal, but not in SC»
nine: looks like a bug.
masak: any idea how I can create a class with a fully qualified
name from an EVAL that's deep in some other namespace?
masak: as in Inline::Perl5::Perl6PackageCreator::create runs an
EVAL that should create a class called Foo::Bar::Baz.
nine: EVAL "class Foo::Bar::Baz {}" doesn't cut it ?
alternately EVAL "class Foo { class Bar { class Baz {}}}' ?
or actually, maybe both?
lizmat: nope, that creates
Inline::Perl5::Perl6PackageCreator::Foo::Bar::Baz (what a handy name
;)
m: BEGIN GLOBAL:: := class { }; Test.new;
rakudo-moar 682e03: ( no output )
ah, := works, while = does not
nine: Does class GLOBAL::Foo::Bar::Baz { } not do it?
jnthn: no, the GLOBAL:: is pretty much ignored
ah
Maybe that wants fixing
But afer dinner
* masak submits rakudobug
jnthn: according to S10, GLOBAL:: should do it though
nine: That's my feeling too
[perl #122789] substitutation does not seem to work properly in BEGIN
# New Ticket Created by equinox
# Please include the string: [perl #122789]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=122789 >
Hi all,
I found this
12:55:39] [jaffa4] m: BEGIN {my $p =
'D:\m\p6\guiultimate\lib\\GUI\Upp.pm6'; say $p.subst(/(.+)\\.+$/,{$0});}
[12:55:40] [+camelia] rakudo-moar 3fae8d: OUTPUT«»
[12:55:47] [jaffa4] m: {my $p = 'D:\m\p6\guiultimate\lib\\GUI\Upp.pm6';
say $p.subst(/(.+)\\.+$/,{$0});}
[12:55:48] [+camelia] rakudo-moar 3fae8d:
OUTPUT«D:\m\p6\guiultimate\lib\GUI»
[12:56:03] [jaffa4] bug!!!
Jaffa4
[perl #122631] =begin finish needs a roast test, and it causes the parser to take forever
# New Ticket Created by Rob Hoelz # Please include the string: [perl #122631] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=122631 > =begin finish makes the parser seemingly entire an infinite loop. Thanks to Ovid++ for reporting.
[perl #102478] [BUG] Attributes can't be declared inside of a BEGIN eval in Rakudo
On Sat Oct 29 13:09:29 2011, masak wrote:
> nom: class A { eval 'has $.x' }; say A.new(x => 3).x
> nom 9c6aed: OUTPUT«===SORRY!===A cannot have attributes at
> line 1, near ""»
> nom: class A { BEGIN eval 'has $.x' }; say A.new(x => 3).x
> nom 9c6aed: OUTPUT«===SORRY!===A cannot have attributes at
> line 1, near ""»
> why not?
> moritz: Probably that eval doesn't know it's in a class
> definition or some such
> moritz: e.g. it's treated like a little bit of mainline
> moritz: I guess you can argue that the BEGIN case there should work
> jnthn: but the error message knows that it's in A
> moritz: no, the error message is busted
> The first case should certainly not work
> The second one...maybe.
> So the question is...
> In eval, what do we treat as the current package?
> masak: The "A" in the error messsage is not referring to the clas A
> Call it B in the code to see :)
> jnthn: aha, it's an article ;)
> nom: class B { BEGIN eval 'has $.x' }
> nom 9c6aed: OUTPUT«===SORRY!===A cannot have attributes at
> line 1, near ""»
> See the double space? :)
> It doesn't know what sort of thing it is in :)
> nom: has $.x
> nom 9c6aed: OUTPUT«===SORRY!===A cannot have attributes at
> line 1, near ""»
> Right. :)
> eval is doing the wrong kind of thing about current package.
> * masak submits rakudobug
> Yeah, we should probably make that one work.
> I'm in the middle of re-doing the repr API at the moment
> though, so won't get to that for a day or two.
Behavior has changed a bit.
This now gives an awesome error and can be closed with tests:
03:16 < [Coke]> nom: has $.x
03:17 <+camelia> rakudo-parrot e8cea1, rakudo-jvm e8cea1, rakudo-moar e8cea1:
OUTPUT«===SORRY!=== Error while compiling /tmp/tmpfileYou
cannot declare attribute '$.x' here; maybe you'd like a class
or a role?at /tmp/tmpfile:1--> has $.x⏏ …»
However, the examples from earlier now give errors about non-rakudo objects, or
methods we weren't asking about, e.g.:
03:16 < [Coke]> nom: class A { BEGIN EVAL 'has $.x' }; say A.new(x => 3).x
03:16 <+camelia> rakudo-jvm e8cea1: OUTPUT«(timeout)»
03:16 <+camelia> ..rakudo-parrot e8cea1: OUTPUT«===SORRY!===No such method
'name' for invocant of type 'NQPMu'»
03:16 <+camelia> ..rakudo-moar e8cea1: OUTPUT«===SORRY!===Cannot find method
'name'»
--
Will "Coke" Coleda
[perl #119749] [BUG] Null PMC access when looping over SomeEnum.enums in a blockless BEGIN in Rakudo
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #119749]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org:443/rt3/Ticket/Display.html?id=119749 >
is it ok for this to crash?
r: enum A (a=>3,b=>10,c=>1); class B { BEGIN for
A.enums.kv -> $k, $v { our $k ::= $v }; }; say B.b
rakudo 69c3cc: OUTPUT«===SORRY!===Null PMC access in get_bool()»
certainly not in this way
poor_soul: certainly not ok.
* masak submits rakudobug
"Null PMC access" is always a bug, IIRC
overwriting B::k with each enum value in turn doesn't sound too useful
i was trying to find a way to declare constants in a class
based on a enum
poor_soul: Does declaring the enum in the class not do it? :)
jnthn: it does only partially, since if i want to use it,
i need to put the name of the enum
r: class A { enum B ; method m() { say e } }; A.m
rakudo 69c3cc: OUTPUT«e»
r: class A { enum B ; method m() { say +e } }; A.m
rakudo 69c3cc: OUTPUT«2»
r: enum A (a=>3); class B { BEGIN for A.enums {} } # golf'd
rakudo 69c3cc: OUTPUT«===SORRY!===Null PMC access in get_bool()»
ooh, in fact...
r: enum A (a=>3); BEGIN for A.enums {}
rakudo 69c3cc: OUTPUT«===SORRY!===Null PMC access in get_bool()»
Short names seem to work to me.
r: enum A (a=>3); BEGIN A.enums
rakudo 69c3cc: ( no output )
r: enum A (a=>3); BEGIN A.enums.perl.say
rakudo 69c3cc: OUTPUT«("a" => 3).hash»
r: enum A (a=>3); BEGIN { for A.enums { }; 1 }
rakudo 69c3cc: ( no output )
r: enum A (a=>3); BEGIN { for A.enums { } }
rakudo 69c3cc: ( no output )
r: enum A (a=>3); BEGIN for A.enums { }
rakudo 69c3cc: OUTPUT«===SORRY!===Null PMC access in get_bool()»
wow...you need the blockless form to trigger it.
[perl6/specs] 2d47c8: Match vars begin at $0 in Perl 6
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 2d47c89bbb86aa80e42bdc991b04aa3bbca1640f https://github.com/perl6/specs/commit/2d47c89bbb86aa80e42bdc991b04aa3bbca1640f Author: Alex Moquin Date: 2013-08-08 (Thu, 08 Aug 2013) Changed paths: M S28-special-names.pod Log Message: --- Match vars begin at $0 in Perl 6 Commit: ac105c28ca590c622491ae2204cc370d9bff https://github.com/perl6/specs/commit/ac105c28ca590c622491ae2204cc370d9bff Author: Brent Laabs Date: 2013-08-08 (Thu, 08 Aug 2013) Changed paths: M S28-special-names.pod Log Message: --- Merge pull request #59 from Mouq/matchvars Match vars begin at $0 in Perl 6 Looks good to me :) Compare: https://github.com/perl6/specs/compare/a888b089ab07...ac105c28ca59
[perl #119109] [NYI] 'will begin' doesn't bind the variable to $_ in Rakudo
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #119109]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org:443/rt3/Ticket/Display.html?id=119109 >
S04:1454 states "These have the advantage of passing the
variable in question into the closure as its topic"
I wonder what that would mean for cases such as
my @a will begin { say $_.WHAT } # Array ?
r: my @a; BEGIN { say @a.WHAT }
rakudo 4a608a: OUTPUT«(Array)»
* masak nods
r: my @a; $_ := @a; say $_.WHAT # more like this, I guess
rakudo 4a608a: OUTPUT«(Array)»
r: my @a will begin { say $_.WHAT } # Array ?
rakudo 4a608a: OUTPUT«(Mu)»
I don't see why it shouldn't be (Array)
* masak submits rakudobug
masak: don't bother, it's NYI
one of the blockers I'm banging my head against
ok, submitting as [NYI] instead of [BUG] :)
The last two evaluations should both print '(Array)'.
[perl #81502] BEGIN time error messages lack line numbers
On Fri Dec 31 09:02:30 2010, moritz wrote:
> moritz@jacq:~/p6/rakudo>./perl6 -e 'BEGIN { a() }'
> ===SORRY!===
> Could not find sub &a
> moritz@jacq:~/p6/rakudo>./perl6 -e 'a()'
> Could not find sub &a
> in main program body at line 1
>
> Any code run at BEGIN time lacks a stack trace, which is rather annoying.
Behavior has changed slightly, but is still broken:
$ perl6 -e 'BEGIN { a() }'
===SORRY!===
Could not find sub &a
$ perl6 -e 'a()'
===SORRY!===
Undeclared routine:
a used at line 1
--
Will "Coke" Coleda
[perl #101440] [BUG] Closures created inside BEGIN blocks see the wrong outer lexpad in Rakudo
masak (>>), coke (>):
> > nom: my $c; my $name; BEGIN { $c = { say "OH HAI $name" } };
> > $name = "masak"; $c()
> > nom ea25f3: OUTPUT«Use of uninitialized value in string
> > contextOH HAI »
> > I'd expect the above to say "OH HAI masak".
> > are my expectations too high? :)
> > masak: Seems reasonableish... :)
> > * masak submits rakudobug
>
> I would expect $name to be undefined at BEGIN time, which would make
> this behavior correct.
>
> Can you explain your POV here?
Yes. $name is indeed undefined (or Any) at BEGIN time, but we're not
calling it at BEGIN time.
The order of things is this:
1. Parse declarations of $c and $name. These are in scope for the rest
of the program, and there's only one runtime environment with these
variables in it -- the mainline one.
2. Parse BEGIN block. Since it's a BEGIN block, the assignment to $c
happens immediately, at compile time.
3. Parse the rest of the program. Parsing completes.
4. Switch from compile time to runtime.
5. Make the assignment to $name.
6. Make the invocation $c().
7. Now inside the Block assigned to $c. In order to print the string,
look up $name, which (there being only one, the one in the mainline
code) should now have the assigned value "masak". Print it.
Something goes wrong in step 7, since the value looked up for $name
comes up as Any, not "masak". The thing that goes wrong is that the
compile-time value for $name is found, not the run-time value.
The real cause/problem actually happens in step 2, when the block
assigned to $c gets incarnated (=given a runtime representation with a
runtime environment and its lexical bindings). It should get incarnated
to eventually make the lookup finding "masak" in $name. Whereas it
currently behaves, even when called from runtime, like it's still BEGIN
time and $name is still unassigned.
Or maybe the error is in fact at step 4, because at step 2 when can't do
much better than we already do, since we're not at runtime yet, and
there's no runtime environment with a runtime $name to incarnate into
yet. So maybe at step 4 we need to "upgrade" the Block to have a runtime
environment.
Or maybe it's unrealistic/slow/impossible to thus upgrade all Blocks
during the transition from compile time to runtime, and the best we can
do is simply to upgrade them ALAP, when called, at step 6. I don't know
enough about the internals to know which one is the best solution.
Hope that helps.
Re: [perl #101440] [BUG] Closures created inside BEGIN blocks see the wrong outer lexpad in Rakudo
On Sat, May 11, 2013 at 7:10 AM, Will Coleda via RT <
perl6-bugs-follo...@perl.org> wrote:
> On Sun Oct 16 03:56:13 2011, masak wrote:
> > nom: my $c; my $name; BEGIN { $c = { say "OH HAI $name" } };
> > $name = "masak"; $c()
> > nom ea25f3: OUTPUT«Use of uninitialized value in string
> > contextOH HAI »
> > I'd expect the above to say "OH HAI masak".
> > are my expectations too high? :)
> > masak: Seems reasonableish... :)
> > * masak submits rakudobug
>
> I would expect $name to be undefined at BEGIN time, which would make this
> behavior correct.
>
> Can you explain your POV here?
>
But $name is declared at BEGIN time and defined at $c() time.
Observe Perl 5:
$ perl -E 'my $c; my $name; BEGIN { $c = sub { say "OH HAI $name" } };
$name = "masak"; $c->()'
OH HAI masak
$
If I drop the $c(), I get no warning, so the interpolation of $name is
not happening at BEGIN time.
So ... the block is not closing as expected over $name? It's trying to
interpolate something other than the declared $name?
Eirik
[perl #101440] [BUG] Closures created inside BEGIN blocks see the wrong outer lexpad in Rakudo
On Sun Oct 16 03:56:13 2011, masak wrote:
> nom: my $c; my $name; BEGIN { $c = { say "OH HAI $name" } };
> $name = "masak"; $c()
> nom ea25f3: OUTPUT«Use of uninitialized value in string
> contextOH HAI »
> I'd expect the above to say "OH HAI masak".
> are my expectations too high? :)
> masak: Seems reasonableish... :)
> * masak submits rakudobug
I would expect $name to be undefined at BEGIN time, which would make this
behavior correct.
Can you explain your POV here?
--
Will "Coke" Coleda
[perl #115502] [BUG] 'try' at BEGIN time hangs in Rakudo
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #115502]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org:443/rt3/Ticket/Display.html?id=115502 >
r: macro marco { try 0 }; marco
rakudo 6859fb: OUTPUT«(timeout)»
masak: ^^
* masak submits rakudobug
r: BEGIN { try 0 }; say "alive"
rakudo 6859fb: OUTPUT«(timeout)»
seems it has nothing to do with macros, just 'try' at BEGIN time.
oh
[perl #115374] [BUG] Spurious error when printing return value of DOC BEGIN block in Rakudo
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #115374]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org:443/rt3/Ticket/Display.html?id=115374 >
r: say DOC BEGIN { 4 };
rakudo b86628: OUTPUT«===SORRY!===Method 'flat' not found
for invocant of class 'NQPMu'»
* masak submits rakudobug
[perl #115134] [BUG] BEGIN { eval "..." } Confuses Rakudo
# New Ticket Created by Edwin Steiner
# Please include the string: [perl #115134]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org:443/rt3/Ticket/Display.html?id=115134 >
eval inside a BEGIN block seems to confuse rakudo:
$ ./perl6 -e 'BEGIN { eval "0" }
say "alive"'
===SORRY!===
Confused
at -e:1
With a semicolon, the confusion goes away:
$ ./perl6 -e 'BEGIN { eval "0" };
say "alive"'
alive
Also without the eval there is no confusion:
$ ./perl6 -e 'BEGIN { say "0" }
say "alive"'
0
alive
This is independent from using -e or a file:
$ cat test.pl
BEGIN { eval '0' }
say 'alive'
$ ./perl6 test.pl
===SORRY!===
Confused
at test.pl:1
$ ./perl6 --version
This is perl6 version 2012.09.1-5-g3d31af9 built on parrot 4.4.0 revision
RELEASE_4_4_0
[perl #113956] [BUG] Things that are not SixModelObjects leak out of BEGIN blocks which end with a require in Rakudo
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #113956]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org:443/rt3/Ticket/Display.html?id=113956 >
r: BEGIN { require Test }
rakudo 16db64: OUTPUT«===SORRY!===Can only use
nqp_set_sc_for_object with a SixModelObject»
r: BEGIN { require Test;1 }
rakudo 16db64: ( no output )
masak may file a Rakudo bug about it too ;)
* masak submits rakudobug
[perl #111766] [BUG] Lexical lookup doesn't work properly from an END block to a surrounding BEGIN block in Rakudo
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #111766]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org:443/rt3/Ticket/Display.html?id=111766 >
nom: BEGIN { my $a = 42; END { say $a } }
rakudo fee891: OUTPUT«Any()»
* masak submits rakudobug
nom: my $a = 42; END { say $a }
rakudo fee891: OUTPUT«42»
both should work, IMNSHO.
[perl #102478] [BUG] Attributes can't be declared inside of a BEGIN eval in Rakudo
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #102478]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org:443/rt3/Ticket/Display.html?id=102478 >
nom: class A { eval 'has $.x' }; say A.new(x => 3).x
nom 9c6aed: OUTPUT«===SORRY!===A cannot have attributes at
line 1, near ""»
nom: class A { BEGIN eval 'has $.x' }; say A.new(x => 3).x
nom 9c6aed: OUTPUT«===SORRY!===A cannot have attributes at
line 1, near ""»
why not?
moritz: Probably that eval doesn't know it's in a class
definition or some such
moritz: e.g. it's treated like a little bit of mainline
moritz: I guess you can argue that the BEGIN case there should work
jnthn: but the error message knows that it's in A
moritz: no, the error message is busted
The first case should certainly not work
The second one...maybe.
So the question is...
In eval, what do we treat as the current package?
masak: The "A" in the error messsage is not referring to the clas A
Call it B in the code to see :)
jnthn: aha, it's an article ;)
nom: class B { BEGIN eval 'has $.x' }
nom 9c6aed: OUTPUT«===SORRY!===A cannot have attributes at
line 1, near ""»
See the double space? :)
It doesn't know what sort of thing it is in :)
nom: has $.x
nom 9c6aed: OUTPUT«===SORRY!===A cannot have attributes at
line 1, near ""»
Right. :)
eval is doing the wrong kind of thing about current package.
* masak submits rakudobug
Yeah, we should probably make that one work.
I'm in the middle of re-doing the repr API at the moment
though, so won't get to that for a day or two.
[perl #101440] [BUG] Closures created inside BEGIN blocks see the wrong outer lexpad in Rakudo
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #101440]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org:443/rt3/Ticket/Display.html?id=101440 >
nom: my $c; my $name; BEGIN { $c = { say "OH HAI $name" } };
$name = "masak"; $c()
nom ea25f3: OUTPUT«Use of uninitialized value in string
contextOH HAI »
I'd expect the above to say "OH HAI masak".
are my expectations too high? :)
masak: Seems reasonableish... :)
* masak submits rakudobug
