[perl #132016] Supply.merge and signals ( signal(SIGTERM).merge(signal(SIGINT)) )
# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
# Please include the string: [perl #132016]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=132016 >
Command:
# run it and then send SIGINT (e.g. with Ctrl+C)
perl6 -e 'react whenever signal(SIGINT).merge(signal(SIGTERM)) { say ‘hey!’;
exit 0 }'
Result:
hey!
Command:
# run it and then send SIGINT (e.g. with Ctrl+C)
perl6 -e 'react whenever signal(SIGTERM).merge(signal(SIGINT)) { say ‘hey!’;
exit 0 }'
Result:
Unhandled exception in code scheduled on thread 10
Cannot resolve caller postcircumfix:<[ ]>(Mu, Int); none of these signatures
match:
(\SELF, Any:U $type, |c is raw)
(\SELF, int $pos)
(\SELF, int $pos, Mu \assignee)
(\SELF, int $pos, Mu :$BIND! is raw)
(\SELF, int $pos, :$delete!, *%other)
(\SELF, int $pos, :$exists!, *%other)
(\SELF, int $pos, :$kv!, *%other)
(\SELF, int $pos, :$p!, *%other)
(\SELF, int $pos, :$k!, *%other)
(\SELF, int $pos, :$v!, *%other)
(\SELF, Int:D $pos)
(\SELF, Int:D $pos, Mu \assignee)
(\SELF, Int:D $pos, Mu :$BIND! is raw)
(\SELF, Int:D $pos, :$delete!, *%other)
(\SELF, Int:D $pos, :$exists!, *%other)
(\SELF, Int:D $pos, :$kv!, *%other)
(\SELF, Int:D $pos, :$p!, *%other)
(\SELF, Int:D $pos, :$k!, *%other)
(\SELF, Int:D $pos, :$v!, *%other)
(\SELF, Any:D \pos)
(\SELF, Any:D \pos, Mu \assignee)
(\SELF, Any:D \pos, Mu :$BIND! is raw)
(\SELF, Any:D \pos, :$delete!, *%other)
(\SELF, Any:D \pos, :$exists!, *%other)
(\SELF, Any:D \pos, :$kv!, *%other)
(\SELF, Any:D \pos, :$p!, *%other)
(\SELF, Any:D \pos, :$k!, *%other)
(\SELF, Any:D \pos, :$v!, *%other)
(\SELF, Iterable:D \pos)
(\SELF, Iterable:D \pos, Mu \val)
(\SELF, Iterable:D \pos, :$BIND!)
(\SELF, Iterable:D \pos, :$delete!, *%other)
(\SELF, Iterable:D \pos, :$exists!, *%other)
(\SELF, Iterable:D \pos, :$kv!, *%other)
(\SELF, Iterable:D \pos, :$p!, *%other)
(\SELF, Iterable:D \pos, :$k!, *%other)
(\SELF, Iterable:D \pos, :$v!, *%other)
(\SELF, Callable:D $block)
(\SELF, Callable:D $block, Mu \assignee)
(\SELF, Callable:D $block, :$BIND!)
(\SELF, Callable:D $block, :$delete!, *%other)
(\SELF, Callable:D $block, :$exists!, *%other)
(\SELF, Callable:D $block, :$kv!, *%other)
(\SELF, Callable:D $block, :$p!, *%other)
(\SELF, Callable:D $block, :$k!, *%other)
(\SELF, Callable:D $block, :$v!, *%other)
(\SELF, Whatever:D)
(\SELF, Whatever:D, Mu \assignee)
(\SELF, Whatever:D, :$BIND!)
(\SELF, Whatever:D, :$delete!, *%other)
(\SELF, Whatever:D, :$exists!, *%other)
(\SELF, Whatever:D, :$kv!, *%other)
(\SELF, Whatever:D, :$p!, *%other)
(\SELF, Whatever:D, :$k!, *%other)
(\SELF, Whatever:D, :$v!, *%other)
(\SELF, HyperWhatever:D, *%adv)
(\SELF, HyperWhatever:D, Mu \assignee)
(\SELF, :$BIND!)
(\SELF, :$delete!, *%other)
(\SELF, :$exists!, *%other)
(\SELF, :$kv!, *%other)
(\SELF, :$p!, *%other)
(\SELF, :$k!, *%other)
(\SELF, :$v!, *%other)
(\SELF, *%other)
I think there's something wrong.
[perl #123015] [RFC] methods for accessing binary data in Buf objects
On Mon, 20 Oct 2014 07:01:07 -0700, moritz wrote: > On Mon Oct 20 06:54:16 2014, abraxxa wrote: > > As discussed on IRC mainly with moritz I'd need a way to get the > > number of bytes, not elements, of a Buf object so it can be looped > > and > > each byte accessed with $buf.[$idx]. > > I'm requiring this in DBDish::Oracle for passing UTF-16 encoded > > values > > and their byte-length to the OCI C library using NativeCall. > > Another use case: cryptography, which typically works on the byte > level, even for multi-byte encodings. A lot of time has passed and we have has the first part for quite some time. $ perl6 -e '.bytes.say for buf8.new(1,2,3), buf16.new(1,2,3), buf32.new(1,2,3), buf64.new(1,2,3)' 3 6 12 24 ...which is both specced and already tested. Also as a Container type you get .of: $ perl6 -e '.of.say for Buf[int8].new(1,2,3), Buf[uint16].new(1,2,3), Buf[int32], Buf[uint64]' (int8) (uint16) (int32) (uint64) ...and the native types can be nativesizeof'd $ perl6 -e 'use NativeCall; nativesizeof(.of).say for Buf[int8].new(1,2,3), Buf[uint16].new(1,2,3), Buf[int32], Buf[uint64]' 1 2 4 8 Also there are ways to finagle the second need with NativeCall: $ perl6 -e 'use NativeCall; my $b16 = buf16.new(1,2,3); my $b8 = nativecast(CArray[uint8], $b16); $b8[^6].say' (1 0 2 0 3 0) ...though internally this relies on some GC manipulations and the details on exactly if/when it becomes fragile aren't documented. Granted a lot more could be done to make this, and endianness conversions easier, e.g. safe and optimized indexing adverbs like buf32.new(1,2)[^8]:swab8 might be nice, as well as having types that carry their endianness information around with them, but I think that falls in the 6.d-and-later design discussion category rather than RT. So I'd vote to 'resolve' this ticket, and maybe if the next person who picks it up agrees, they should do so.
[perl #130520] [RFC] Deprecate `flatmap`
A lot of discussion drifted to this ticket for some reason: https://github.com/perl6/doc/issues/1428 Let's get ourselves back here. On 2017-07-31 14:40:50, c...@zoffix.com wrote: > > But do you really think I'm wrong > > Nope. I agree it should be tossed. > > There's one test in 6.c-errata that merely tests its nodality. > > I'd say deprecate it in 6.d and toss it in 6.e. I listed that on the > 6.d's TODO: https://github.com/perl6/6.d- > prep/commit/2cc614bde4bc5c69884a63c3ba972dfa680b312c
[perl #132012] Numeric values of signals are wrong (say +SIGUSR1)
We now have a note in the docs about this. When fixed, change the docs accordingly (*maybe* saying that versions before X are known to have a bug). https://github.com/perl6/doc/commit/39e3efc08d See IRC discussion: https://irclog.perlgeek.de/perl6/2017-09-01#i_15103501 On 2017-09-01 03:33:34, alex.jakime...@gmail.com wrote: > Code: > say +SIGUSR1 > > Result: > 30 > > > However, on my system SIGUSR1 is *not* 30 (it is 10). I guess rakudo > should try harder to find proper values of the system it runs on. > > See this doc issue: https://github.com/perl6/doc/issues/1474
[perl #132015] [LTA] Backtraces for errors in EVAL print nonexistent paths (‘foo’.EVAL)
# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev # Please include the string: [perl #132015] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=132015 > Code: ‘foo’.EVAL Result: ===SORRY!=== Error while compiling /home/alex/EVAL_0 Undeclared routine: foo used at line 1 There's no /home/alex/EVAL_0 and hopefully it does not do it through a temp file, therefore it should not talk about paths that don't exist.
Re: [perl #131997] New Rakudo Star Bug
>>> > On 1 Sep 2017, at 13:55, Will Coleda via RT > wrote: > > On Wed, 30 Aug 2017 09:15:53 -0700, stephen.john@gmail.com wrote: >> This is Rakudo version 2017.04.3 built on MoarVM version 2017.04-53- >> g66c6dda >> implementing Perl 6.c. >> >> As mentioned on IRC #perl6 today 16:50. >> Apologies if this is down to newbie error - please do let me know if >> (& where) I messed up! > > In future, please send files as attachments, makes it easier to test the code. >>>ok - soz > > Please specify what the behavior you expected is, and what the behavior you > see is. >>>rakudo* hangs > > The subject of "New Rakudo Star Bug" implies that this used to work > differently in a previous version. Is that the case? Do you have a version of > rakudo in which this worked differently? >>>no - I mean that this is a new bug report as opposed to updating an existing >>>bug report > > -- > Will "Coke" Coleda
Re: [perl #131997] New Rakudo Star Bug
>>> > On 1 Sep 2017, at 13:55, Will Coleda via RT > wrote: > > On Wed, 30 Aug 2017 09:15:53 -0700, stephen.john@gmail.com wrote: >> This is Rakudo version 2017.04.3 built on MoarVM version 2017.04-53- >> g66c6dda >> implementing Perl 6.c. >> >> As mentioned on IRC #perl6 today 16:50. >> Apologies if this is down to newbie error - please do let me know if >> (& where) I messed up! > > In future, please send files as attachments, makes it easier to test the code. >>>ok - soz > > Please specify what the behavior you expected is, and what the behavior you > see is. >>>rakudo* hangs > > The subject of "New Rakudo Star Bug" implies that this used to work > differently in a previous version. Is that the case? Do you have a version of > rakudo in which this worked differently? >>>no - I mean that this is a new bug report as opposed to updating an existing >>>bug report > > -- > Will "Coke" Coleda
[perl #131003] [SEGV] Heap corruption when using Gumbo
https://irclog.perlgeek.de/perl6-dev/2017-09-01#i_15102810
On 2017-07-31 08:27:09, alex.jakime...@gmail.com wrote:
> FWIW, still happens after all changes during this month.
>
> On 2017-07-22 16:21:30, alex.jakime...@gmail.com wrote:
> > I bisected it to
> >
>
https://github.com/rakudo/rakudo/commit/40a953f5d9f5c661d8cf9b043643002d348a2000
> >
> > On earlier rakudo versions it seems to be working fine. I haven't
> > seen
> > it crash
> > once on anything earlier, but it is *very* slow on rakudos that old,
> > so it's
> > hard to tell.
> >
> > nqp changes:
> >
> > https://github.com/perl6/nqp/compare/2016.03-50-g512c9a1...2016.03-
> > 57-
> > gbdb13a2
> >
> > moar changes:
> > https://github.com/MoarVM/MoarVM/compare/2016.03-84-
> > g4afd7b6...2016.03-104-g10d3971
> >
> > On 2017-05-13 17:00:08, alex.jakime...@gmail.com wrote:
> > > FWIW the problem is still there and is reproducible with the
> > > provided
> > > snippet
> > > (just in case somebody is wondering if the issue went away by
> > > itself
> > > after
> > > these months).
> > >
> > > On 2017-04-04 06:46:20, scoli...@gmail.com wrote:
> > > > Le Wed, 15 Mar 2017 17:12:00 -0700, alex.jakime...@gmail.com a
> > > > écrit
> > > > :
> > > > > I am getting errors like:
> > > > > MoarVM panic: Heap corruption detected: pointer 0x7f9a96a5e588
> > > > > to
> > > > > past
> > > > > fromspace
> > > > > MoarVM panic: Internal error: zeroed target thread ID in work
> > > > > pass
> > > > >
> > > > > Even though it happens when I'm using Gumbo module, my best
> > > > > guess
> > > > > is
> > > > > that it is not its fault.
> > > > >
> > > > > Does not crash that fast with ｢perl6 --optimize=0 …｣, but
> > > > > crashes
> > > > > anyway (you may want to bump up “^100” a little bit for this).
> > > > >
> > > > > Anyway, the code to replicate the issue is shown below. If it
> > > > > gets
> > > > > mangled for some reason, here is a mirror:
> > > > > https://gist.github.com/AlexDaniel/ac7a4d4c49ec8d23e546529976dda67f
> > > > >
> > > > > #!/usr/bin/env perl6
> > > > >
> > > > > use Gumbo;
> > > > > constant URL = ‘https://perl6.org/community/’;
> > > > >
> > > > > my $response = run(:out, ‘curl’, ‘-s’, URL).out.slurp-rest;
> > > > > for ^100 {
> > > > > .say for parse-html($response).root.elements(:TAG,
> > > > > :RECURSE);
> > > > > }
> > > > >
> > > > > say ‘should've crashed before reaching this’;
> > > >
> > > > I was not able to reproduce it on a 32bit Virtual Machine (debian
> > > > stable)
> > > > Using 2016.11 rakudo and the latest from git.
> > > > Maybe it can be related to how struct size are determined by
> > > > MoarVM.
> > > >
[perl #132003] grammar cannot parse from Blob/Buf
# New Ticket Created by Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯
# Please include the string: [perl #132003]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=132003 >
› perl6 -v
This is Rakudo version 2017.07 built on MoarVM version 2017.07
implementing Perl 6.c.
› cat calc.pl
use v6;
grammar Calculator {
token TOP { [ | ] }
rule add { '+' }
rule sub { '-' }
token num { \d+ }
}
say Calculator.parse('2 + 3');
say Calculator.parse(Blob.new([50,32,43,32,51])); # '2 + 3'
› perl6 calc.pl
｢2 + 3｣
add => ｢2 + 3｣
num => ｢2｣
num => ｢3｣
Cannot use a Buf as a string, but you called the Str method on it
in block at calc.pl line 9
It appears grammars only accept strings, but I also want to parse
non-text input, e.g. binary file formats.
[perl #132004] infinite loop with grammar
# New Ticket Created by Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯
# Please include the string: [perl #132004]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=132004 >
› perl6 -v
This is Rakudo version 2017.07 built on MoarVM version 2017.07
implementing Perl 6.c.
› cat flail.pl
use v6;
grammar Flail {
rule TOP { }
rule B { 'x' 'y' | }
rule A { '' | 'x' 'z' }
rule C { 'w' | 'v' }
}
Flail.parse('x z x y').say;
Flail.parse('v w w w w w w').say;
› perl6 flail.pl
｢x z x y｣
B => ｢x z x y｣
A => ｢x z ｣
^C
The execution simply goes into infinite loop with the second input.
This is the least awesome failure mode.
Compare with Pegex and Regexp::Grammars, which emit a recursion
warning/error. Compare with Antlr4, where the grammar is effectively a
compile time error. Compare with Eyapp and Marpa, which can consume
this grammar and set of inputs without any problem.
I realise that the parser cannot be simply changed since it also parses
Perl6 source code. But since it is now shown that the parser is not a
general parser able to consume arbitrary valid CFG, then at least the
documentation must mention somewhere
* what the name/classification of the underlying technology/algorithm
of the parser is and
* what its shortcomings are (with examples)
so that a user can make an informed decision.
[perl #132014] [REGEX] Some Zero-Width assertion appear to not work in
# New Ticket Created by Zoffix Znet # Please include the string: [perl #132014] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=132014 > IRC: https://irclog.perlgeek.de/perl6/2017-09-01#i_15101726 If `^` or `«` is used in `` the match fails: 15:13 ab6tractm: say "What::Root::Thing" ~~ / .*/; say "What::Root::Thing" ~~ / .*/ 15:13 camelia rakudo-moar 909688: OUTPUT: «Nil??Thing??» 15:23 m: say ".zXXXYzYYY" ~~ / .../ 15:23 camelia rakudo-moar 909688: OUTPUT: «Nil?» Even though, `<|w>` and `` in `` as well as `$` in `` do work: 15:23 m: say ".zXXXYzYYY" ~~ / z> .../ 15:23 camelia rakudo-moar 909688: OUTPUT: «?XXX??» 15:23 Zoffix m: say ".zXXXYzYYY" ~~ / z> .../ 15:23 camelia rakudo-moar 909688: OUTPUT: «?YYY??» 15:17 m: say "XXXzYYYz" ~~ /... / 15:17 camelia rakudo-moar 909688: OUTPUT: «?XXX?? before => ???» 15:17 Zoffix m: say "XXXzYYYz" ~~ /... / 15:17 camelia rakudo-moar 909688: OUTPUT: «?YYY?? before => ???»
[perl #131996] `unhandled Failure detected in DESTROY` on `require`
On Wed, 30 Aug 2017 06:44:51 -0700, alexander.kiryu...@gmail.com wrote:
> This one is tough.
>
> http://colabti.org/irclogger/irclogger_log/perl6?date=2017-08-30#l469
> - the
> original conversation with Zoffix.
>
> https://github.com/croservices/cro/commit/11aac95b9ef94a1db43521a72ebd323f6281c202
> - this commit introduces TemplateLoader that has
> > require ::{$_};
> line.
>
> It works, but occasionally throws:
>
> ```
> WARNING: unhandled Failure detected in DESTROY. If you meant to ignore
> it,
> you can mark it as handled by calling .Bool, .so, .not, or .defined
> methods. The Failure was:
> No such symbol 'Cro::Tools::Template::ZeroMQWorkerService'
> in sub get-available-templates at
> /home/koto/Work/cro/cro/lib/Cro/Tools/TemplateLocator.pm6
> (Cro::Tools::TemplateLocator) line 31
> in sub MAIN at /home/koto/Work/cro/cro/lib/Cro/Tools/CLI.pm6
> (Cro::Tools::CLI) line 115
> in block at bin/cro line 1
> ```
>
> So there are basically two problems here:
> 1)This package really exists with a correct name and everything(see
> below).
> Yet it throws.
> 2)Even if it isn't, it should throw, then be caught by catch block,
> etc.
>
> How to reproduce:
> 1) zef install cro # To get all the dependencies.
> 2) git clone https://github.com/croservices/cro.git
> 3) cd cro
> 4) git reset --hard fb251c594c3ed04cd9a16c1b045f4380abb40549 # To
> reset a
> workaround
> 5) perl6 -Ilib bin/cro stub http my-test-service ./my-test-service
> :secure;
> # A couple of times, it's good to write it like
> 6) (opt) perl6 -Ilib bin/cro stub http my-test-service ./my-test-
> service
> :secure; rm -rf my_test_service/ # to remove the directory immediately
> for
> easier multi-try.
>
> Maybe not for the first time, but this occurs maybe for every 3 times,
> or
> 10 times in a row - based on your luck.
>
> Anything, especially golfing is appreciated. Or better name(especially
> this).
>
> > perl6 --version
> > This is Rakudo version 2017.08-28-gd8958fc37 built on MoarVM version
> 2017.08.1-19-g151a2563
I think you would find that if you guaranteed the program to run long and
hard enough to reach a GC DESTROY it would happen 100% of the time. Also IIRC
there's some flag to tell rakudo to always use the GC to clean up before
process exit.
Personally I have always disagreed with the idea that we should warn when
Failures get thrown away and destroyed, as merely creating a Failure object does
not mean a Failure has been experienced -- it just means you have a Failure you
can
throw at the user at an appropriate time. If the user never steps on the
land-mine you planted, then that means they were not interested in using
the part of your module that was unhappy, so no harm done.
So really I'd kick this over to [SPEC], but that is just my personal preference.
On a practical level, as a workaround, the originating module would have to
stop preparing Failure objects before it finds a way to place them directly
under the user's foot.
[perl #130528] missing interpolation in postcircumfix error message
On Sat, 07 Jan 2017 11:33:55 -0800, gfldex wrote:
> sub postcircumfix:«> <»($a){}; loop (my $i=0;$i>10;$i++) {};
>
> # OUTPUT«===SORRY!=== Error while compiling Unable to parse
> expression in postcircumfix:sym«> <»; couldn't find final $stopper at
> :1--> rcumfix:«> <»($a){}; loop (my $i=0;$i>10⏏;$i++) {};
> expecting any of:s…»
>
> # `final $stopper` should say `<`
>From the perspective of the guts behind it, this behavior is correct,
as vars in rx "do not interpolate" and the rx engine resolves them
later when needed. In a situation where you were using these guts and
passed them a terminator in a variable, you'd want the error message
to tell you what variable you passed it in with.
However, since the particular case here is used as an example in S05, and
it is only the way rakudo chose to use those guts internally that causes this
deviation, it was worth bodging around.
Fix committed in rakudo 909688953.
Tests commited in roast 2cef80a32.
Closing.
[perl #131997] New Rakudo Star Bug
On Wed, 30 Aug 2017 09:15:53 -0700, stephen.john@gmail.com wrote: > This is Rakudo version 2017.04.3 built on MoarVM version 2017.04-53- > g66c6dda > implementing Perl 6.c. > > As mentioned on IRC #perl6 today 16:50. > Apologies if this is down to newbie error - please do let me know if > (& where) I messed up! In future, please send files as attachments, makes it easier to test the code. Please specify what the behavior you expected is, and what the behavior you see is. The subject of "New Rakudo Star Bug" implies that this used to work differently in a previous version. Is that the case? Do you have a version of rakudo in which this worked differently? -- Will "Coke" Coleda
[perl #131997] New Rakudo Star Bug
On Wed, 30 Aug 2017 09:15:53 -0700, stephen.john@gmail.com wrote: > This is Rakudo version 2017.04.3 built on MoarVM version 2017.04-53- > g66c6dda > implementing Perl 6.c. > > As mentioned on IRC #perl6 today 16:50. > Apologies if this is down to newbie error - please do let me know if > (& where) I messed up! In future, please send files as attachments, makes it easier to test the code. Please specify what the behavior you expected is, and what the behavior you see is. The subject of "New Rakudo Star Bug" implies that this used to work differently in a previous version. Is that the case? Do you have a version of rakudo in which this worked differently? -- Will "Coke" Coleda
[perl #132012] Numeric values of signals are wrong (say +SIGUSR1)
# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev # Please include the string: [perl #132012] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=132012 > Code: say +SIGUSR1 Result: 30 However, on my system SIGUSR1 is *not* 30 (it is 10). I guess rakudo should try harder to find proper values of the system it runs on. See this doc issue: https://github.com/perl6/doc/issues/1474
