[perl #129812] [JVM][OPTIMIZER] `is rw` candidates get called even if a non-rw argument is passed
This now works on the JVM backend, too. Fixed with https://github.com/rakudo/rakudo/commit/12d4514a3d I'm closing this ticket as 'resolved'.
[perl #129812] [JVM][OPTIMIZER] `is rw` candidates get called even if a non-rw argument is passed
This is still a problem on the JVM backend. I tried a second time to find the
underlying problem and arrived at the same conclusion: There seems to be
something wrong in 'analyze_dispatch'. When running the given code
multi foo ($) {"right" }; multi foo ($ is rw) {"wrong"}; say foo "42"
'analyze_dispatch' returns the second sub with $MD_CT_DECIDED. This (wrong)
result is taken for real on the JVM backend, whereas on MoarVM it isn't really
used in this case -- cmp.
https://github.com/rakudo/rakudo/blob/4df02facd0/src/Perl6/Optimizer.nqp#L3109-L3113
I didn't grasp all the details, but the problem might be related to the fact
that 'sort_dispatchees_internal' returns an array with five results: [2nd_sub,
Mu, 1st_sub, Mu, Mu]. The second sub comes first, because it is narrower than
the first sub. The Mu at index 1 seems to indicate the end of a tied group.
This leads to 'analyze_dispatch' looking at the second sub first, not detecting
a problem there (due to the missing check for a literal being passed in) and
returning this sub after seeing the Mu.
I still think my patch from 2017 makes sense. With this patch,
'analyze_dispatch' rejects the second sub, notices that it didn't analyze all
candidates and returns $MD_CT_NOT_SURE. But it would be even better if
'analyze_dispatch' dispatches to the first sub with $MD_CT_DECIDED.
[perl #132784] [BUILD] make install fail on termux/Android 6.0.1
I suggest check out below links:
https://github.com/mickael-kerjean/filestash/issues/61
https://github.com/termux/termux-packages/issues/307
Good luck,
On Mon, 29 Jan 2018 13:24:45 -0800, myforumem...@arcor.de wrote:
> Device: Onyx Boox Max2, Android 6.0.1, cpu rk3288
> termux is a prefixed linux, device is not rooted
> make install fails for both rakudo-star-2017.10 and rakudo-2017.12
>
> Using a cross-compiled MoarVM it's possible to make nqp and rakudo,
> but make install hangs, after that install dir usr/share/perl6 has
> some precomp
> binaries, whatever that is.
>
> $ make install
> mkdir -p -- /data/data/com.termux/files/usr/bin
> mkdir -p -- /data/data/com.termux/files/usr/share/nqp/lib/Perl6
> /data/data/com.termux/files/usr/bin/moar --libpath="blib"
> --libpath="/data/data/com.termux/files/usr/share/nqp/lib"
> --libpath="/data/data/com.termux/files/usr/share/nqp/lib" perl6.moarvm
> --nqp-lib=blib -e "for @*ARGS.head(*-1) { given (@*ARGS[*-1] ~ '/' ~
> .IO.basename.Str) { say 'rm -f ' ~ .Str; .IO.unlink if .IO.e } }"
> blib/Perl6/ModuleLoader.moarvm blib/Perl6/World.moarvm
> blib/Perl6/Grammar.moarvm blib/Perl6/Ops.moarvm
> blib/Perl6/Actions.moarvm blib/Perl6/Optimizer.moarvm
> blib/Perl6/Pod.moarvm blib/Perl6/Compiler.moarvm
> blib/Perl6/Metamodel.moarvm blib/Perl6/BOOTSTRAP.moarvm
> blib/Perl6/DebugPod.moarvm
> //data/data/com.termux/files/usr/share/nqp/lib/Perl6
> rm -f
> //data/data/com.termux/files/usr/share/nqp/lib/Perl6/ModuleLoader.moarvm
> rm -f
> //data/data/com.termux/files/usr/share/nqp/lib/Perl6/World.moarvm
> rm -f
> //data/data/com.termux/files/usr/share/nqp/lib/Perl6/Grammar.moarvm
> rm -f //data/data/com.termux/files/usr/share/nqp/lib/Perl6/Ops.moarvm
> rm -f
> //data/data/com.termux/files/usr/share/nqp/lib/Perl6/Actions.moarvm
> rm -f
> //data/data/com.termux/files/usr/share/nqp/lib/Perl6/Optimizer.moarvm
> rm -f //data/data/com.termux/files/usr/share/nqp/lib/Perl6/Pod.moarvm
> rm -f
> //data/data/com.termux/files/usr/share/nqp/lib/Perl6/Compiler.moarvm
> rm -f
> //data/data/com.termux/files/usr/share/nqp/lib/Perl6/Metamodel.moarvm
> rm -f
> //data/data/com.termux/files/usr/share/nqp/lib/Perl6/BOOTSTRAP.moarvm
> rm -f
> //data/data/com.termux/files/usr/share/nqp/lib/Perl6/DebugPod.moarvm
> cp -- blib/Perl6/ModuleLoader.moarvm blib/Perl6/World.moarvm
> blib/Perl6/Grammar.moarvm blib/Perl6/Ops.moarvm
> blib/Perl6/Actions.moarvm blib/Perl6/Optimizer.moarvm
> blib/Perl6/Pod.moarvm blib/Perl6/Compiler.moarvm
> blib/Perl6/Metamodel.moarvm blib/Perl6/BOOTSTRAP.moarvm
> blib/Perl6/DebugPod.moarvm
> /data/data/com.termux/files/usr/share/nqp/lib/Perl6
> mkdir -p -- /data/data/com.termux/files/usr/share/perl6/lib
> mkdir -p -- /data/data/com.termux/files/usr/share/perl6/runtime
> /data/data/com.termux/files/usr/bin/moar --libpath="blib"
> --libpath="/data/data/com.termux/files/usr/share/nqp/lib"
> --libpath="/data/data/com.termux/files/usr/share/nqp/lib" perl6.moarvm
> --nqp-lib=blib -e "for @*ARGS.head(*-1) { given (@*ARGS[*-1] ~ '/' ~
> .IO.basename.Str) { say 'rm -f ' ~ .Str; .IO.unlink if .IO.e } }"
> CORE.setting.moarvm CORE.d.setting.moarvm RESTRICTED.setting.moarvm
> /data/data/com.termux/files/usr/share/perl6/runtime
> rm -f
> /data/data/com.termux/files/usr/share/perl6/runtime/CORE.setting.moarvm
> rm -f
> /data/data/com.termux/files/usr/share/perl6/runtime/CORE.d.setting.moarvm
> rm -f
> /data/data/com.termux/files/usr/share/perl6/runtime/RESTRICTED.setting.moarvm
> /data/data/com.termux/files/usr/bin/moar --libpath="blib"
> --libpath="/data/data/com.termux/files/usr/share/nqp/lib"
> --libpath="/data/data/com.termux/files/usr/share/nqp/lib" perl6.moarvm
> --nqp-lib=blib -e "for @*ARGS.head(*-1) { given (@*ARGS[*-1] ~ '/' ~
> .IO.basename.Str) { say 'rm -f ' ~ .Str; .IO.unlink if .IO.e } }"
> perl6.moarvm perl6-debug.moarvm
> /data/data/com.termux/files/usr/share/perl6/runtime
> rm -f /data/data/com.termux/files/usr/share/perl6/runtime/perl6.moarvm
> rm -f /data/data/com.termux/files/usr/share/perl6/runtime/perl6-
> debug.moarvm
> cp -- CORE.setting.moarvm CORE.d.setting.moarvm
> RESTRICTED.setting.moarvm
> /data/data/com.termux/files/usr/share/perl6/runtime
> cp -- perl6.moarvm perl6-debug.moarvm
> /data/data/com.termux/files/usr/share/perl6/runtime
> mkdir -p -- /data/data/com.termux/files/usr/share/perl6/runtime/dynext
> cp -- dynext/libperl6_ops_moar.so
> /data/data/com.termux/files/usr/share/perl6/runtime/dynext
> ./perl6-m tools/build/upgrade-repository.pl
> /data/data/com.termux/files/usr/share/perl6
> ./perl6-m tools/build/upgrade-repository.pl
> /data/data/com.termux/files/usr/share/perl6/vendor
> ./perl6-m tools/build/upgrade-repository.pl
> /data/data/com.termux/files/usr/share/perl6/site
> ./perl6-m tools/build/install-core-dist.pl
> /data/data/com.termux/files/usr/share/perl6
> ^Cmake: *** [Makefile:635: m-install] Interrupt
--
Matt Zand
https://coding-bootcamps.com/
https://myhsts.org/
https://dcwebmakers.com/
[perl #76930] [STAR] [BUILD] space in prefix path
Using spaces in prefix path should work now. There was some serious revamp of the build system during the last couple of months. I didn't have all the details, but some relevant pull requests for Rakudo have probably been: * https://github.com/rakudo/rakudo/pull/2693 * https://github.com/rakudo/rakudo/pull/3031 Also: $ cd ~/perl6/tmp/dir\ with\ space/ $ mkdir perl6 $ git clone https://github.com/rakudo/rakudo.git $ cd rakudo $ perl Configure.pl --backends=moar --gen-nqp --gen-moar --prefix ~/perl6/tmp/dir\ with\ space/perl6 && make install $ ~/perl6/tmp/dir\ with\ space/perl6/bin/perl6 -e 'say 42' 42 I'm closing this ticket as 'resolved'.
[perl #127483] [BUG] use lib 'lib' and perl6 -Ilib behave differently
On Sun, 31 Jul 2016 19:14:19 -0700, c...@zoffix.com wrote: > Can't reproduce the issue. > > Are you able to try again with the latest Rakudo, please? Since there was no update on this ticket, I'm closing (rejecting) it now. I'm pretty sure we'd have more bug reports if this would be an issue with current rakudo versions.
[perl #130572] Parenthesized `for` loop is eager, even with `lazy` keyword
Back in 2017 jnthn++ already added a test for lazy for loops with https://github.com/perl6/roast/commit/3659ede149. Since the evaluations in this ticket also take the type into considerations, I've added a new test to S32-list/seq.t with https://github.com/perl6/roast/commit/207171b5ee I'm closing this ticket as 'resolved'.
[perl #127536] [BUG] UNIT:: dies horribly if used at compile time
I've added a test to S02-names/pseudo-6e.t with https://github.com/perl6/roast/commit/73d867501c I'm closing this ticket as 'resolved'.
[perl #124915] Roast rakudo skip/todo test:./S02-names/pseudo.t line:36 reason: 'various issues, skipping all for now'
The skip directive has been removed (at least for v6.e) with commit https://github.com/perl6/roast/commit/04c7d09341 (see also https://github.com/perl6/roast/commit/2913fbe564 for v6.c and v6.d). I'm closing this ticket as 'rejected', since there wasn't added any additional information.
[perl #124860] [NYI] [UNI] [JVM] Roast rakudo skip/todo test:./S05-mass/properties-general.t line:163 reason: No 'Lr' property defined
These tests have been adjusted with https://github.com/perl6/roast/commit/551a7ffd7b I'm closing this ticket as 'resolved'.
[perl #124838] [JVM] Roast rakudo skip/todo test:./S29-conversions/ord_and_chr.t line:168 reason: 'high character name lookup'
This test works with more recent Java version, cmp. https://github.com/perl6/roast/commit/b5c4ed2345 I'm closing this ticket as 'resolved'.
[perl #124669] Roast rakudo skip/todo test:./S06-other/main-usage.t line:190 reason: '[NYI]'
This test works now, cmp. https://github.com/perl6/roast/commit/472bc003f0 I'm closing this ticket as 'resolved'.
[perl #124517] Roast rakudo skip/todo test:./S03-metaops/eager-hyper.t line:35 reason: 'hyper prefix [NYI] entirely, I guess'
The test in question works now, cmp. https://github.com/perl6/roast/commit/bba5083af5. I'm closing this ticket as 'resolved'.
[perl #124675] Roast rakudo skip/todo test:./S16-io/quoting-syntax.t line:42 reason: Unsupported use of /s
Test has been removed with https://github.com/perl6/roast/commit/1a88ef7e03. I'm closing this ticket as 'rejected'.
[perl #124674] Roast rakudo skip/todo test:./S16-io/quoting-syntax.t line:32 reason: two terms in a row
Test has been removed with https://github.com/perl6/roast/commit/1a88ef7e03. I'm closing this ticket as 'rejected'.
[perl #124673] Roast rakudo skip/todo test:./S16-io/quoting-syntax.t line:18 reason: undeclared routine / urecognized adverb
Test has been removed with https://github.com/perl6/roast/commit/1a88ef7e03. I'm closing this ticket as 'rejected'.
[perl #124672] Roast rakudo skip/todo test:./S16-io/quoting-syntax.t line:8 reason: two terms in a row / unrecognized adverb
Test has been removed with https://github.com/perl6/roast/commit/1a88ef7e03. I'm closing this ticket as 'rejected'.
[perl #127536] [BUG] UNIT:: dies horribly if used at compile time
On Thu, 21 Jul 2016 19:43:35 -0700, c...@zoffix.com wrote:
> Still present in Rakudo version 2016.07.1-28-gd789da1 built on MoarVM
> version 2016.07-3-gc01472d
>
> Interestingly, this doesn't happen on camelia running the same commit.
>
> zoffix@VirtualBox:~/CPANPRC/rakudo$ ./perl6-m -e 'BEGIN { UNIT; Nil }'
> ===SORRY!=== Error while compiling -e
> An exception occurred while evaluating a BEGIN
> at -e:1
> Exception details:
> ===SORRY!=== Error while compiling
> ctxlexpad needs an MVMContext
> at :
Fixed with commit
https://github.com/rakudo/rakudo/commit/1c7d15d73d6e06ab0e2660f64436ab447e90c581
testneeded
[perl #126945] [BUG] outer frame does not match expected static frame
On Thu, 17 Dec 2015 03:37:17 -0800, lloyd.fo...@gmail.com wrote:
> should have mentioned:
>
> When invoking cuid_1_1450351791.17598 '', provided outer frame
> 0x7fbeb3c409b0 (cuid_3_1450351791.17598 '') does not match expected
> static frame 0x7fbeb3c40ad0 (cuid_2_1450351791.17598 '')
> in block at -e:1
>
> and that if you replace the () with 'do' it doesn't happen.
>
> On Thu, Dec 17, 2015 at 10:35 PM perl6 via RT
> wrote:
>
> > Greetings,
> >
> > This message has been automatically generated in response to the
> > creation of a trouble ticket regarding:
> > "outer frame does not match expected static frame",
> > a summary of which appears below.
> >
> > There is no need to reply to this message right now. Your ticket has been
> > assigned an ID of [perl #126945].
> >
> > Please include the string:
> >
> > [perl #126945]
> >
> > in the subject line of all future correspondence about this issue. To do
> > so,
> > you may reply to this message.
> >
> > Thank you,
> > perl6-bugs-follo...@perl.org
> >
> > -
> > perl6 -e '{ berp => "lerp", ( with "herp" { $_ => "derp" } ) }'
> >
> > This is Rakudo version 2015.11-593-g33ac495 built on MoarVM version
> > 2015.11-55-g49f10b9 implementing Perl 6.b.
> >
> >
Fixed with commit
https://github.com/rakudo/rakudo/commit/31c8fda2878d091f54247f034fba3f63b0942e75
testneeded
[perl #130444] [REGRESSION] Hash value constraints are no longer working (Hash[Int].new(‘abc’ => 20..50))
On Mon, 13 May 2019 10:28:25 -0700, jan-olof.hen...@bredband.net wrote:
> On Thu, 29 Dec 2016 13:26:17 -0800, alex.jakime...@gmail.com wrote:
> > Code:
> > say Hash[Int].new(‘abc’ => 20..50)
> >
> >
> > Result (2015.12):
> > Type check failed in binding $x; expected Int but got Range
> > in block at /tmp/CRJOhWZaTS line 1
> > «exit code = 1»
> >
> >
> > Result (HEAD):
> > {abc => 20..50}
> >
> >
> > It should complain that it got a Range instead of an Int.
> >
> > Bisectable points to
> > https://github.com/rakudo/rakudo/commit/b2e57f697fad1617951561ff928e6d981b323386
>
> Fixed with commit
> https://github.com/rakudo/rakudo/commit/9acbf000418cd716f532008a5a1704cccf684eae
>
> testneeded
Turns out that this issue is the same as R#2348 which was fixed we the above
commit.
Tests were added to roast with https://github.com/perl6/roast/commit/28301d7c5d
closing
[perl #130444] [REGRESSION] Hash value constraints are no longer working (Hash[Int].new(‘abc’ => 20..50))
On Thu, 29 Dec 2016 13:26:17 -0800, alex.jakime...@gmail.com wrote:
> Code:
> say Hash[Int].new(‘abc’ => 20..50)
>
>
> Result (2015.12):
> Type check failed in binding $x; expected Int but got Range
> in block at /tmp/CRJOhWZaTS line 1
> «exit code = 1»
>
>
> Result (HEAD):
> {abc => 20..50}
>
>
> It should complain that it got a Range instead of an Int.
>
> Bisectable points to
> https://github.com/rakudo/rakudo/commit/b2e57f697fad1617951561ff928e6d981b323386
Fixed with commit
https://github.com/rakudo/rakudo/commit/9acbf000418cd716f532008a5a1704cccf684eae
testneeded
[perl #131089] Different parsing of combined colonpairs
On Sun, 02 Apr 2017 07:48:11 -0700, alex.jakime...@gmail.com wrote:
> I wonder, is it a dup of RT #124553 and RT #125353 ?
>
> On 2017-04-02 04:50:15, c...@zoffix.com wrote:
> > If joined colonpairs are after a position arg, only the first
> > colonpair gets registered:
> >
> > m: -> *@_, *%_ { dd [@_, %_] }("/", :r:w:d:x)
> > rakudo-moar 1b9d53: OUTPUT: «[["/"], {:r}]»
> >
> > But if they're first in line, then all do:
> >
> > m: -> *@_, *%_ { dd [@_, %_] }(:r:w:d:x, "/")
> > rakudo-moar 1b9d53: OUTPUT: «[["/"], {:d, :r, :w, :x}]»
> >
> > When in a [], only first one is obtained as well:
> > m: dd [:r:w:d:x]
> > rakudo-moar 1b9d53: OUTPUT: «[:r]»
> >
> > And when in a {}, all are obtained, but only the first one gets value
> > True (related?)
> > m: dd {:r:w:d:x}
> > rakudo-moar 1b9d53: OUTPUT: «Hash % = {:d(1), :r, :w(1),
> > :x(1)}»
The examples given by Zoffix above seems to have been fixed by
https://github.com/rakudo/rakudo/commit/91359141fb7501636b073ccaf6fb6598dc273bec
[perl #130069] [BUG] Unknown QAST error when creating List of Pairs
On Thu, 04 May 2017 17:36:32 -0700, c...@zoffix.com wrote: > On Thu, 10 Nov 2016 21:03:43 -0800, joshu...@gmail.com wrote: > > Normally Rakudo is happy for you to omit comma when declaring pairs > > with > > the `:key(value)` syntax, however I found that it does not like this > > syntax > > is Rat's are used as the value, like this: > > > > > (:this(3.5) :that(5.3)) > > Unknown QAST node type NQPMu > > > > I took a stab at this one, but giving up for now. > > Things discovered: > - It's the second `:that(5.3)` that is the thing causing the issue > - To repro the issue, instead of a Rat you can use a constant, e.g. > `:that(pi)` > - ASTs: > - Working version has: QAST::WVal(Rat) :statement_id > 5.3 > - Broken version has: QAST::Want (looks like it's missing > stuff inside of it, which is what gives the error) > - --target=parse: > - Working version has EXPR => - 0: colonpair: (first) - 1: > colonpair: (second) > - Broken version has EXPR => - 0: colonpair: (first) - > fake_infix: - OPER: - colonpair: (second) > > So looks like the Actions for `statement` token needs to rake through > `fake_infix` capture and generate proper colonpair instead of empty > QAST::Want. > > I gave up at that point, but hopefully my digging will be helpful to > someone :) Fixed with commit https://github.com/rakudo/rakudo/commit/91359141fb7501636b073ccaf6fb6598dc273bec testneeded
[perl #130572] Parenthesized `for` loop is eager, even with `lazy` keyword
On Sun, 12 May 2019 07:36:16 -0700, jan-olof.hen...@bredband.net wrote: > On Sat, 26 Aug 2017 05:15:41 -0700, sml...@gmail.com wrote: > > This bug is still present in > > > > Rakudo version 2017.08-8-g753c9a5ea built on MoarVM version > > 2017.08.1- > > 19-g151a2563 > > implementing Perl 6.c > > As per commit > https://github.com/rakudo/rakudo/commit/cf1673d9c20e82aad6291a8aa123c46e177edf34 > the second case now works as intended. As for the first case, see https://colabti.org/irclogger/irclogger_log/perl6-dev?date=2019-05-12#l48 should be set to testneeded
[perl #130572] Parenthesized `for` loop is eager, even with `lazy` keyword
On Sat, 26 Aug 2017 05:15:41 -0700, sml...@gmail.com wrote: > This bug is still present in > > Rakudo version 2017.08-8-g753c9a5ea built on MoarVM version 2017.08.1- > 19-g151a2563 > implementing Perl 6.c As per commit https://github.com/rakudo/rakudo/commit/cf1673d9c20e82aad6291a8aa123c46e177edf34 the second case now works as intended.
[perl #131395] [BUG] Cross meta operator on empty list complains "This type (Scalar) does not support elems"
On Sat, 30 Sep 2017 12:40:59 -0700, sml...@gmail.com wrote: > On Mon, 29 May 2017 11:36:49 -0700, c...@zoffix.com wrote: > > On Mon, 29 May 2017 10:02:27 -0700, thunderg...@comcast.net wrote: > > > Using a cross meta operator on an empty list complains "This type > > > (Scalar) does not support elems". > > > > > > say (1,2).elems; say ().elems; say (1,2) X (); > > > > > > yields "20This type (Scalar) does not support elems" > > > > > > Seems to work correctly with arrays instead of lists. > > > > > > say [1,2].elems; say [].elems; say [1,2] X []; > > > > > > > > > Linux Mint 17.2 > > > > > > > perl6 -v > > > > This is Rakudo version 2017.05 built on MoarVM version 2017.05 > > > implementing Perl 6.c. > > > > > > Thank you for the report. lizmat++ fixed the issue. > > > > Fix: https://github.com/rakudo/rakudo/commit/9494cbd3b9 > > Test: https://github.com/perl6/roast/commit/0faf3c354f > > Re-opening, because it hasn't been fixed for the Xop case yet: > > ➜ say () X+ (1, 2); > This type (Scalar) does not support elems > > ➜ say (1,2) X~ (); > This type (Scalar) does not support elems > > ➜ say () X=> (); > This type (Scalar) does not support elems > > Bisectable¹ blames a commit² from January. > > > --- > [1] > https://gist.github.com/Whateverable/f1b3066f1e2c45df7ab5e0aa7aeee3a7 > [2] https://github.com/rakudo/rakudo/commit/a26f51361 > > --- > This is Rakudo version 2017.09-142-ga89add0bf built on MoarVM version > 2017.09.1-49-gb3dd812a > implementing Perl 6.c. Fixed with commit https://github.com/rakudo/rakudo/commit/6c93fde85da027748bddd7cf75e295ed70ce3b05 Roast tests added with https://github.com/perl6/roast/commit/7d47580eb83fbf7c315e21411422fbc547f96399 Closing
[perl #132585] [REGRESSION] nested parameterized type names are truncated
On Fri, 15 Dec 2017 01:18:46 -0800, d...@zwell.net wrote: > The output of a hash of hashes of ints looks my Hash[Int] %nested- > type; > %nested-type.WHAT.say; # output: (Hash[Hash) > > The type should be shown as: (Hash[Hash[Int]]) > > AlexDaniel did a bisect and found this was caused by: > https://github.com/rakudo/rakudo/commit/1ed284e2953382744b02058a2ec548658d744786 Fixed with commit https://github.com/rakudo/rakudo/commit/ce08683fbf7dac2a1a37bf50fe336819f946c0c0 The above commit fixed the duplicate bug R#1606 to which tests where added in S02-names-vars/names.t Closing
[perl #128047] [IO] Rakudo may crash if you use get() when -n is used (perl6 -ne 'say get' <<< 'hello')
On Tue, 21 Feb 2017 11:05:15 -0800, c...@zoffix.com wrote: > On Sun, 01 May 2016 04:12:34 -0700, alex.jakime...@gmail.com wrote: > > This bug report is somewhat related to > > https://rt.perl.org/Ticket/Display.html?id=128046 > > > > get() crashes with a weird error if the stream has ended. > > > > Command: > > perl6 -ne 'get' <<< $'hello\nworld\ntest' > > > > Result: > > world > > Nil > > readline requires an object with REPR MVMOSHandle > > in block at -e line 1 > > > > But it works if the number of lines is even. > > > > Command: > > perl6 -ne 'get' <<< $'hello\nworld' > > > > Result: > > world > > > > > > It should not crash. > > lines() appears to have a similar affliction, though I don't see any > difference if the number of lines is even. > > $ cat foo.txt > a > b > c > > $ perl6 -ne '@ = lines' foo.txt > readline requires an object with REPR MVMOSHandle > in block at -e line 1 > > > $ perl6 -ne 'lines.eager' foo.txt > readline requires an object with REPR MVMOSHandle > in block at -e line 1 > > Behavior has changed, the examples above now fail with: Cannot do 'get' on a handle in binary mode
[perl #131813] Segfault with --profile
On Sun, 04 Feb 2018 02:40:44 -0800, alex.jakime...@gmail.com wrote: > Actually, I've been trying to reproduce it on the said revision with > --profile, > --ll-exception and whatnot, and I can't. I think this is an issue on > OS X and > therefore should be confirmed (and tested) on OS X also. > > On 2018-01-06 12:59:07, jan-olof.hen...@bredband.net wrote: > > On Fri, 28 Jul 2017 15:52:53 -0700, timo wrote: > > > It could be that the commit i just pushed to moarvm fixes this, > > > please > > > verify (the code doesn't crash with the patch) > > > > Seems to work properly: > > > > dogbert@dogbert-VirtualBox ~/repos/rakudo $ ./perl6 -v > > This is Rakudo version 2017.12-124-g6a6470f9d built on MoarVM version > > 2017.12-20-g57103408 > > implementing Perl 6.c. > > dogbert@dogbert-VirtualBox ~/repos/rakudo $ ./perl6 --profile -e 'my > > @a = (^1)>>.Str' > > Writing profiler output to profile-1515272304.87249.html > > dogbert@dogbert-VirtualBox ~/repos/rakudo $ ./perl6 --profile -e 'my > > @a = (^25000)>>.Str' > > Writing profiler output to profile-1515272310.68317.html > > dogbert@dogbert-VirtualBox ~/repos/rakudo $ Tested by Lizmat on OS X, see https://colabti.org/irclogger/irclogger_log/perl6-dev?date=2019-05-11#l61
[perl #131666] NativeCall MoarVM panic
Can confirm this is still current behaviour with Rakudo 2019. I have came
across exactly the same issue and found this ticket. I've noticed, If I change
the example to catch exceptions. It then runs:
sub start-element($, $elem, $attr)
{
say "open $elem".indent($depth * 4);
say $attr.elems;
++$depth;
CATCH { default { warn "whoops: $_" } }
}
Produces:
open calendar
whoops: Don't know how many elements a C array returned from a library
in block at /tmp/tst.p6 line 27
open advent
whoops: Don't know how many elements a C array returned from a library
in block at /tmp/tst.p6 line 27
...etc
Underlying issue seems to be that any uncaught exception in a NativeCall Perl
callback currently results in a unfriendly NativeCall MoarVM panic. The
exception itself is lost.
On Tue, 27 Jun 2017 05:59:08 -0700, vladimir.ma...@oracle.com wrote:
> I took the NativeCall sample from here:
>
> https://perl6advent.wordpress.com/2015/12/21/day-21-nativecall-backs-
> and-beyond-c/
>
>
> use NativeCall;
>
> sub XML_SetElementHandler(OpaquePointer $parser,
> (OpaquePointer, Str, CArray[Str]),
>(OpaquePointer, Str))
> is native('expat') { ... }
>
> sub XML_ParserCreate(Str --> OpaquePointer) is
> native('expat') { ... }
> sub XML_ParserFree(OpaquePointer) is
> native('expat') { ... }
> sub XML_Parse(OpaquePointer, Buf, int32, int32 --> int32) is
> native('expat') { ... }
>
> my $xml = q:to/XML/;
>
>
>
>
>
> XML
>
> my $depth = 0;
>
> sub start-element($, $elem, $attr)
> {
> say "open $elem".indent($depth * 4);
> ++$depth;
> }
>
> sub end-element($, $elem)
> {
> --$depth;
> say "close $elem".indent($depth * 4);
> }
>
> my $parser = XML_ParserCreate('UTF-8');
> XML_SetElementHandler($parser, , );
>
> my $buf = $xml.encode('UTF-8');
> XML_Parse($parser, $buf, $buf.elems, 1);
>
> XML_ParserFree($parser);
>
>
>
> All works fine, unless I try to use the $attr in start-element
>
> sub start-element($, $elem, $attr)
> {
> say "open $elem".indent($depth * 4);
> say $attr.elems;
> ++$depth;
> }
>
>
> The program then terminates with:
>
> MoarVM panic: Internal error: Unwound entire stack and missed handler
>
>
> I have seen that on Solaris, but Linux has the same issue. In both
> cases
> custom build perl6 using 'rakudobrew build moar' so I suppose latest
> git revision.
>
> Thank you
[perl #126894] [BUILD] Cannot create Debian package with current rakudo-star build system
Le Fri, 26 Apr 2019 08:28:23 -0700, n...@detonation.org a écrit : > I'm quite sure all the issues in that ticket have been resolved. Yes. We managed to create separate Debian packages for moar, nqp and rakudo. We are also creating package for individual Perl6 modules, but we're still for from providing all the packages found in rakudo-star. I'm sorry that I forgot about this bug I opened a while ago. Thanks for taking care of it. All the best Dod
[perl #131167] [JVM] Newly-added NQP test for catching exceptions fails on JVM
I have committed https://github.com/perl6/nqp/commit/59d7a8869c and this test passes now. As far as I understand, the right handler was missed when moving to the outside, because unwind_check sets the outer handler to 0 by default if no outer handler is passed. We do the latter now. I'm closing this ticket as 'resolved'.
[perl #124571] [TODO] statement prefix 'lazy', currently works like 'do'
As jmerelo++ pointed out [1] the statement prefix 'lazy' has been fixed back in 2015 with https://github.com/rakudo/rakudo/commit/d043961414. It no longer shares the implementation with 'do'. The tests that are fudged with this ticket don't work, though. The test file S04-statements/lazy.t is not part of Rakudo's t/spectest.data. [1] https://github.com/perl6/roast/issues/528
[perl #130761] [OPTIMIZER] An if-block confuses &?ROUTINE to point at the wrong outer routine
On Thu, 04 Apr 2019 22:59:38 -0700, barto...@gmx.de wrote: > I'm going to unfudge the test in S02-magicals/sub.t for rakudo.jvm. For the record: https://github.com/perl6/roast/commit/aaf7ad02fc
[perl #124742] [JVM] - "\x[E0100]".codes != 1
On Thu, 04 Apr 2019 23:09:43 -0700, barto...@gmx.de wrote: > I'm going to unfudge the test in S32-str/length.t and close this ticket. For the record: https://github.com/perl6/roast/commit/aaf7ad02fc
[perl #124692] [JVM] Roast rakudo skip/todo test:./S32-str/substr.t line:43 reason: 'java.nio.charset.MalformedInputException'
On Thu, 04 Apr 2019 23:15:25 -0700, barto...@gmx.de wrote: > I'm going to change two skipped tests to 'todo'. For the record: https://github.com/perl6/roast/commit/aaf7ad02fc
[perl #130761] [OPTIMIZER] An if-block confuses &?ROUTINE to point at the wrong outer routine
Just for the record: This seems to work on the JVM backend:
$ ./perl6-j --optimize=3 -e 'sub f() { sub g() { if True { return
&?ROUTINE.name } } }; say f()()'
g
I'm going to unfudge the test in S02-magicals/sub.t for rakudo.jvm.
[perl #131970] LTA error handling: shouldnt the Failure convert into an Exception
As a result for https://github.com/rakudo/rakudo/issues/2764 with fix in https://github.com/rakudo/rakudo/commit/c9110654bd5e9dffc163627f13b896b25dff0679 I think this can be closed.
[perl #132668] [NATIVECALL][SEGV][SEVERE] OpenSSL PEM_write_bio_RSAPrivateKey
The problem is the PEM_write_bio_RSAPrivateKey signature used in the NativeCall declaration, it missed five arguments. >From the manual: int PEM_write_bio_RSAPrivateKey(BIO *bp, RSA *x, const EVP_CIPHER *enc, unsigned char *kstr, int klen, pem_password_cb *cb, void *u); So when called it received random values. My modernized example attached that succeds. nativessl.p6 Description: Binary data
[perl #132668] [NATIVECALL][SEGV][SEVERE] OpenSSL PEM_write_bio_RSAPrivateKey
OK, so that's not an issue in Rakudo then. Closed. On 2019-03-05 11:16:41, sortiz wrote: > The problem is the PEM_write_bio_RSAPrivateKey signature used in the > NativeCall declaration, it missed five arguments. > > From the manual: > > int PEM_write_bio_RSAPrivateKey(BIO *bp, RSA *x, const EVP_CIPHER > *enc, > unsigned char *kstr, int > klen, > pem_password_cb *cb, void > *u); > > So when called it received random values. > > My modernized example attached that succeds.
[perl #130442] [REGRESSION] [LTA] redo without a loop no longer prints the line number, also claims it is a compile-time error (redo)
Moved to https://github.com/rakudo/rakudo/issues/2725 On 2016-12-29 14:43:03, alex.jakime...@gmail.com wrote: > Of course, same thing with “next” and “last” (is there anything else?) > > On 2016-12-29 09:13:24, alex.jakime...@gmail.com wrote: > > Code: > > say 42; redo > > > > > > Result (2015.12,2016.05): > > 42 > > redo without loop construct > > in block at /tmp/rQ_1K_fvaD line 1 > > > > > > Result (2016.06,HEAD): > > 42 > > ===SORRY!=== > > redo without loop construct > > > > > > It should print the line number and it should not say “===SORRY!===” > > because it is not a compile-time error. > > > > Bisectable gives a list of commits that could have caused this: > > e609822f01b82608b1b1c869032c95e9641172ce > > 615d30c39eba318f7449b94bbbd0295e2fd75387 > > 8beb87b415014254412409d56378afb3ed5f14d9 > > 05170e0c14969663c816ee1c5aaa019d70938247 > > 899e0fd4c1ce51bc492666ffc69627c502f657f7 > > e5443765d4bce0697c6191dd2b17db3044e027ab > > fcd0093b43614ce91caeb8c23e2bbcff68d54f72 > > 04929feeb06fa851d77ef5efa6be35248301f88c > > 7ee6578ce99aae069349c283012ae7e45dfd75ec > > 519e76487ddd1546b319bfbd47661beac2417d61
[perl #131297] [PERF][REGEX] `|@a` is apparently-equivalent to just `@a` but is 70x slower
Closing, explanation here: https://github.com/rakudo/rakudo/issues/2708
On 2017-05-12 07:52:34, c...@zoffix.com wrote:
> https://irclog.perlgeek.de/perl6-dev/2017-05-12#i_14572067
>
> 14:49 m: my @a = 1..12; for ('a' x 100 ~ " -- Jan-12-2017")
> xx 100 { when /'-- ' |@a '-' \d**2 '-' \d**4 / { } }; say now - INIT
> now
> 14:49 camelia rakudo-moar 94c4e7: OUTPUT: «4.269762»
> 14:49 Zoffix m: my @a = 1..12; for ('a' x 100 ~ " -- Jan-12-2017")
> xx 100 { when /'-- ' ||@a '-' \d**2 '-' \d**4 / { } }; say now - INIT
> now
> 14:49 camelia rakudo-moar 94c4e7: OUTPUT: «0.3336069»
> 14:49 Zoffix m: my @a = 1..12; for ('a' x 100 ~ " -- Jan-12-2017")
> xx 100 { when /'-- ' @a '-' \d**2 '-' \d**4 / { } }; say now - INIT
> now
> 14:49 camelia rakudo-moar 94c4e7: OUTPUT: «0.0607072»
> 14:49 Zoffix m: say 4.269762/0.0607072
> 14:49 camelia rakudo-moar 94c4e7: OUTPUT: «70.3337001»
> 14:49 Zoffix apparently-equivalent but 70x slower
> 14:50 timotimo well well, we still have a lot of
> opportunities to improve these things
[perl #125690] [BUG] Rakudo has stopped matching a regex, related to | vs. ||
Ticket moved to https://github.com/rakudo/rakudo/issues/2697
On 2015-09-25 14:06:27, duff wrote:
> On Sat Jul 25 12:03:18 2015, moritz wrote:
> > This script here:
> >
> > # BEGIN SCRIPT
> > my grammar PgTokenizer {
> > token double_quote_normal { <-[\\"]>+ }
> > token double_quote_escape { [\\ . ]+ }
> > token double_quote {
> > \"
> > [
> > | <.double_quote_normal>
> > | <.double_quote_escape>
> > ]*
> > \"
> > }
> > token single_quote_normal { <-['\\]>+ }
> > token single_quote_escape { [ \'\' || \\ . ]+ }
> > token single_quote {
> > \'
> > [
> > | <.single_quote_normal>
> > | <.single_quote_escape>
> > ]*
> > \'
> > }
> > token placeholder { '?' }
> > token normal { <-[?"']>+ }
> >
> > token TOP {
> > ^
> > (
> > |
> > |
> > |
> > |
> > )*
> > $
> > }
> > }
> >
> > say PgTokenizer.parse(q['a\.b''cd?', "\"?", ?])
> > # END SCRIPT
> >
> > use to match successfully (and presumably did with 2015.06, otherwise
> > we'd have had rakudo star test failures), but doesn't match anymore
> > with
> > rakudo 2015.07.
> >
> > If one changes the || to | in single_quote_escape, it matches again.
> >
> > I think this is a bug, because the two alternatives are mutually
> > exclusive, and thus | vs || shouldn't matter.
> >
>
> For someone who has time to actually fix this in case I don't get to
> it:
>
> I bisected rakudo and got
>
https://github.com/rakudo/rakudo/commit/d3785097e46b45eb51e1039c2e3f725dbdcfdf7b
> as the commit that introduced the change. Since this just bumps the
> NQP version, further bisection of nqp showed that
> https://github.com/perl6/nqp/commit/583419120b0ec9a3c2fef1a61e2993526fbebcd5
> was the real culprit.
>
> that's all I've got for now.
>
>
> -Scott (PerlJam/perlpilot)
Re: [perl #133791] perl 6 parser bugging out on a comment thinking it is a real var
A missing string never got flagged though. When I comment out the
line I call the C line everything worked.
I submitted this as a bug since being the worse kind of exploiter
I love seeing things like this. I'd go gung ho at using
this for malicious activities if I was a hacker.
"Concentrationism"
On 1/25/19 1:20 PM, Aleks-Daniel Jakimenko-Aleksejev via RT wrote:
> Usually this happens when you have an unclosed string somewhere earlier in
> your
> code.
>
> That is:
>
> say "foo; ← oops! Forgot the closing "
>
> # $a ← we think that this is a comment, but actually it's part of the string
> above!
> On 2019-01-23 01:27:08, warren.mu...@gmail.com wrote:
>> Hello:
>>
>> I ran into this while setting up a post test for json
>> in bailador. While compiling it flags the commented
>> line at the end as bad when the fail should be on the
>> check of request.body[0].
>>
>> It happened with the latest rakudo built from scratch
>> as of Jan 23rd 2019 as well as rakudo-star 2018.10.
>>
>> Linux Mint system, 64 bit.
>>
>>
>>
>>
>> # --->perl6 t1.pl6
>> # ===SORRY!=== Error while compiling
>> /home/userx/p6d/tests/latester/t1.pl6
>> # Variable '%bb' is not declared
>> # at /home/userx/p6d/tests/latester/t1.pl6:97
>> # --> #pukes here #say ⏏%bb{"name"};
>>
>> # code snippet that causes the parser to think
>> # the commented code below is not commented
>> if request.body[0] == "{" { say "JSON"} else {say "NOTJSON"};
>>
>> # #my %bb = from-json(request.body);
>> #
>> # this one pukes
>> #pukes here #say %bb{"name"};
>
Re: [perl #133791] perl 6 parser bugging out on a comment thinking it is a real var
Oh, for me I just moved on to a proper bit of code.
I filed the bug for the perfection of the parser so
it's less exploitable. :)
"I code therefore I am!"
On 1/26/19 8:17 PM, Timo Paulssen via RT wrote:
> I believe the problem comes from `"{"` which actually starts an
> interpolated code block containing a string immediately. That's also why
> it doesn't complain about the "else" being in an odd place; it's also
> inside the string!
>
> So here's an equivalent piece of code that shows what's wrong:
>
> if request.body[0] == "" ~ do { qq⟨{ say "JSON"} else {say "NOTJSON"};
> # my %bb = 1234 => 99;
> (and here comes the closing quote for the qq that was missing in the original
> code: ⟩
>
> Simplifying a tiny bit more:
>
> if request.body[0] == "" ~ (say "JSON") ~ " else " ~ (say "NOTJSON") ~ ";
> # my %bb = 1234 => 99;
> again no closing double-quotes
>
> Does that help?
>
> On 25/01/2019 07:20, Aleks-Daniel Jakimenko-Aleksejev via RT wrote:
>> Usually this happens when you have an unclosed string somewhere earlier in
>> your
>> code.
>>
>> That is:
>>
>> say "foo; ← oops! Forgot the closing "
>>
>> # $a ← we think that this is a comment, but actually it's part of the string
>> above!
>> On 2019-01-23 01:27:08, warren.mu...@gmail.com wrote:
>>> Hello:
>>>
>>> I ran into this while setting up a post test for json
>>> in bailador. While compiling it flags the commented
>>> line at the end as bad when the fail should be on the
>>> check of request.body[0].
>>>
>>> It happened with the latest rakudo built from scratch
>>> as of Jan 23rd 2019 as well as rakudo-star 2018.10.
>>>
>>> Linux Mint system, 64 bit.
>>>
>>>
>>>
>>>
>>> # --->perl6 t1.pl6
>>> # ===SORRY!=== Error while compiling
>>> /home/userx/p6d/tests/latester/t1.pl6
>>> # Variable '%bb' is not declared
>>> # at /home/userx/p6d/tests/latester/t1.pl6:97
>>> # --> #pukes here #say ⏏%bb{"name"};
>>>
>>> # code snippet that causes the parser to think
>>> # the commented code below is not commented
>>> if request.body[0] == "{" { say "JSON"} else {say "NOTJSON"};
>>>
>>> # #my %bb = from-json(request.body);
>>> #
>>> # this one pukes
>>> #pukes here #say %bb{"name"};
>
Re: [perl #133791] perl 6 parser bugging out on a comment thinking it is a real var
I believe the problem comes from `"{"` which actually starts an
interpolated code block containing a string immediately. That's also why
it doesn't complain about the "else" being in an odd place; it's also
inside the string!
So here's an equivalent piece of code that shows what's wrong:
if request.body[0] == "" ~ do { qq⟨{ say "JSON"} else {say "NOTJSON"};
# my %bb = 1234 => 99;
(and here comes the closing quote for the qq that was missing in the original
code: ⟩
Simplifying a tiny bit more:
if request.body[0] == "" ~ (say "JSON") ~ " else " ~ (say "NOTJSON") ~ ";
# my %bb = 1234 => 99;
again no closing double-quotes
Does that help?
On 25/01/2019 07:20, Aleks-Daniel Jakimenko-Aleksejev via RT wrote:
> Usually this happens when you have an unclosed string somewhere earlier in
> your
> code.
>
> That is:
>
> say "foo; ← oops! Forgot the closing "
>
> # $a ← we think that this is a comment, but actually it's part of the string
> above!
> On 2019-01-23 01:27:08, warren.mu...@gmail.com wrote:
>> Hello:
>>
>> I ran into this while setting up a post test for json
>> in bailador. While compiling it flags the commented
>> line at the end as bad when the fail should be on the
>> check of request.body[0].
>>
>> It happened with the latest rakudo built from scratch
>> as of Jan 23rd 2019 as well as rakudo-star 2018.10.
>>
>> Linux Mint system, 64 bit.
>>
>>
>>
>>
>> # --->perl6 t1.pl6
>> # ===SORRY!=== Error while compiling
>> /home/userx/p6d/tests/latester/t1.pl6
>> # Variable '%bb' is not declared
>> # at /home/userx/p6d/tests/latester/t1.pl6:97
>> # --> #pukes here #say ⏏%bb{"name"};
>>
>> # code snippet that causes the parser to think
>> # the commented code below is not commented
>> if request.body[0] == "{" { say "JSON"} else {say "NOTJSON"};
>>
>> # #my %bb = from-json(request.body);
>> #
>> # this one pukes
>> #pukes here #say %bb{"name"};
[perl #133791] perl 6 parser bugging out on a comment thinking it is a real var
Usually this happens when you have an unclosed string somewhere earlier in your
code.
That is:
say "foo; ← oops! Forgot the closing "
# $a ← we think that this is a comment, but actually it's part of the string
above!
On 2019-01-23 01:27:08, warren.mu...@gmail.com wrote:
> Hello:
>
> I ran into this while setting up a post test for json
> in bailador. While compiling it flags the commented
> line at the end as bad when the fail should be on the
> check of request.body[0].
>
> It happened with the latest rakudo built from scratch
> as of Jan 23rd 2019 as well as rakudo-star 2018.10.
>
> Linux Mint system, 64 bit.
>
>
>
>
> # --->perl6 t1.pl6
> # ===SORRY!=== Error while compiling
> /home/userx/p6d/tests/latester/t1.pl6
> # Variable '%bb' is not declared
> # at /home/userx/p6d/tests/latester/t1.pl6:97
> # --> #pukes here #say ⏏%bb{"name"};
>
> # code snippet that causes the parser to think
> # the commented code below is not commented
> if request.body[0] == "{" { say "JSON"} else {say "NOTJSON"};
>
> # #my %bb = from-json(request.body);
> #
> # this one pukes
> #pukes here #say %bb{"name"};
[perl #75592] [LTA] Long running unclosed quotes trigger unhelpful message
I'm slightly confused by this ticket… isn't it resolved now? Nowadays you get
an error message like this:
Unable to parse expression in single quotes; couldn't find final "'"
(corresponding starter was at line 2)
So while it blows up at the end of the file, it still mentions where the quote
started. Sooo… fixed? I'm struggling to understand what these code samples were
supposed to demonstrate.
On 2010-06-07 14:23:47, cognominal wrote:
> I am probably a lousy programmer but I hit again and again that
> unhelpful message.
>
> How to reproduce :
>
> eval "{\n\n\n\n\'}"
>
> Unable to parse blockoid, couldn't find final '}' at line 1
>
> Note that the opening quotes are many lines below the start of the
> blockoid and there may be many statements between them.
> So the line number in the error is unhelpful.
>
> In the simplest case, the quote rules fails because the end of the
> file has been reached. I don't see the need
> to backtrack and to fail the blockoid.
>
> In more complicated cases, the quote rule reduces but it eats way more
> characters than the programmer intended
> inluding '}' chars that should terminate blockoids. The result is
> triggering the same message or some others. I don't know if there is a
> way to detect the true problem instead of emitting spurious messages.
> Probably we should indicate the
> reduced quotes involving many lines as suspicious when failing to
> reduce a blockoid. They are bad style anyway because
> heredocs are the preferred style for many lines quoted stuff. But
> heredocs are not implemented yet.
>
>
>
>
>
[perl #133791] perl 6 parser bugging out on a comment thinking it is a real var
# New Ticket Created by Warren W. Music Jr.
# Please include the string: [perl #133791]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=133791 >
Hello:
I ran into this while setting up a post test for json
in bailador. While compiling it flags the commented
line at the end as bad when the fail should be on the
check of request.body[0].
It happened with the latest rakudo built from scratch
as of Jan 23rd 2019 as well as rakudo-star 2018.10.
Linux Mint system, 64 bit.
# --->perl6 t1.pl6
# ===SORRY!=== Error while compiling
/home/userx/p6d/tests/latester/t1.pl6
# Variable '%bb' is not declared
# at /home/userx/p6d/tests/latester/t1.pl6:97
# --> #pukes here #say ⏏%bb{"name"};
# code snippet that causes the parser to think
# the commented code below is not commented
if request.body[0] == "{" { say "JSON"} else {say "NOTJSON"};
# #my %bb = from-json(request.body);
#
# this one pukes
#pukes here #say %bb{"name"};
[perl #133772] stringification of regex with variables
# New Ticket Created by Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯
# Please include the string: [perl #133772]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=133772 >
rpm -qi rakudo | rg Version
Version : 2018.12
my Str $s = 'abc';
my @l = $s.comb.map(-> $g { /$g/ });
# time passes
@l.perl.say
Expect:
[/a/, /b/, /c/]
Got:
[/$g/, /$g/, /$g/]
The generated regexes do work, they just display wrong/useless. At the time I
inspect the data structure, $g had been assigned multiple times with varying
values and is long already out of scope.
Re: [perl #133762] Quanthashes should be parameterizable
Fixed for Bag/BagHash with https://github.com/rakudo/rakudo/commit/fe38bdba62 Fixed for Mix/MixHash with https://github.com/rakudo/rakudo/commit/bcc8054a4d > On 13 Jan 2019, at 22:03, Elizabeth Mattijsen via RT > wrote: > > Fixed for Set/SetHash with https://github.com/rakudo/rakudo/commit/4bb5c33c72 > >> On 10 Jan 2019, at 18:22, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 (via RT) >> wrote: >> >> # New Ticket Created by Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 >> # Please include the string: [perl #133762] >> # in the subject line of all future correspondence about this issue. >> # https://rt.perl.org/Ticket/Display.html?id=133762 > >> >> >> › rpm -qi rakudo | rg Version >> Version : 2018.12 >> >> subset Foo of Str where .chars > 0; >> my SetHash of Foo %f; >> %f.elems.say; >> >> SetHash cannot be parameterized >> >> subset Foo of Str where .chars > 0; >> subset Foo-SetHash of SetHash where $_ ~~ Foo; >> my Foo-SetHash $f; >> $f.elems.say; >> >> Invocant of method 'elems' must be an object instance of type 'Setty', not >> a type object of type 'Foo-SetHash'. Did you forget a '.new'? >> >> subset Foo of Str where .chars > 0; >> subset Foo-SetHash of SetHash where $_ ~~ Foo; >> my $f = Foo-SetHash.new; >> $f.elems.say; >> >> You cannot create an instance of this type (Foo-SetHash)
Re: [perl #133762] Quanthashes should be parameterizable
Fixed for Set/SetHash with https://github.com/rakudo/rakudo/commit/4bb5c33c72 > On 10 Jan 2019, at 18:22, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 (via RT) > wrote: > > # New Ticket Created by Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 > # Please include the string: [perl #133762] > # in the subject line of all future correspondence about this issue. > # https://rt.perl.org/Ticket/Display.html?id=133762 > > > > › rpm -qi rakudo | rg Version > Version : 2018.12 > > subset Foo of Str where .chars > 0; > my SetHash of Foo %f; > %f.elems.say; > >SetHash cannot be parameterized > > subset Foo of Str where .chars > 0; > subset Foo-SetHash of SetHash where $_ ~~ Foo; > my Foo-SetHash $f; > $f.elems.say; > >Invocant of method 'elems' must be an object instance of type 'Setty', not > a type object of type 'Foo-SetHash'. Did you forget a '.new'? > > subset Foo of Str where .chars > 0; > subset Foo-SetHash of SetHash where $_ ~~ Foo; > my $f = Foo-SetHash.new; > $f.elems.say; > >You cannot create an instance of this type (Foo-SetHash)
[perl #133762] Quanthashes should be parameterizable
# New Ticket Created by Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 # Please include the string: [perl #133762] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=133762 > › rpm -qi rakudo | rg Version Version : 2018.12 subset Foo of Str where .chars > 0; my SetHash of Foo %f; %f.elems.say; SetHash cannot be parameterized subset Foo of Str where .chars > 0; subset Foo-SetHash of SetHash where $_ ~~ Foo; my Foo-SetHash $f; $f.elems.say; Invocant of method 'elems' must be an object instance of type 'Setty', not a type object of type 'Foo-SetHash'. Did you forget a '.new'? subset Foo of Str where .chars > 0; subset Foo-SetHash of SetHash where $_ ~~ Foo; my $f = Foo-SetHash.new; $f.elems.say; You cannot create an instance of this type (Foo-SetHash)
[perl #131696] [LTA] internal error for invalid native type in "is native"
Tests in https://github.com/rakudo/rakudo/blob/bfe2ad63f8ea17cbc11e836b7fcb1c8f35515cbd/t/04-nativecall/18-routine-sig-sanity.t#L95
[perl #132214] [LHF] `need` with version silently fails
On Tue, 03 Oct 2017 08:34:39 -0700, c...@zoffix.com wrote: > If you `use` a v6.d, it causes language switch and will also complain > if the version is too high. > The same doesn't happen with `need`. It should probably fail in these > cases, and `` should > be just removed from the grammar[^1]. > > 15:26 m: need v6.c > 15:26 camelia rakudo-moar f946bd: ( no output ) > 15:27 Zoffix m: need v6.e > 15:27 camelia rakudo-moar f946bd: ( no output ) > 15:32 Zoffix m: need v6.d; say $*PERL.version > 15:32 camelia rakudo-moar f946bd: OUTPUT: «v6.c» > > [1] > https://github.com/rakudo/rakudo/blob/f946bd35dca39af97983ec95d4da7fdd0416b73d/src/Perl6/Grammar.nqp#L1548 This appears to be fixed now: m: need v6.d rakudo-moar e7e91ecfb: OUTPUT: «===SORRY!=== Error while compiling In case of using pragma, use "use" instead (e.g., "use v6;", "use v6.c;").at :1--> need v6.d⏏»
[perl #132214] [LHF] `need` with version silently fails
On Tue, 03 Oct 2017 08:34:39 -0700, c...@zoffix.com wrote: > If you `use` a v6.d, it causes language switch and will also complain > if the version is too high. > The same doesn't happen with `need`. It should probably fail in these > cases, and `` should > be just removed from the grammar[^1]. > > 15:26 m: need v6.c > 15:26 camelia rakudo-moar f946bd: ( no output ) > 15:27 Zoffix m: need v6.e > 15:27 camelia rakudo-moar f946bd: ( no output ) > 15:32 Zoffix m: need v6.d; say $*PERL.version > 15:32 camelia rakudo-moar f946bd: OUTPUT: «v6.c» > > [1] > https://github.com/rakudo/rakudo/blob/f946bd35dca39af97983ec95d4da7fdd0416b73d/src/Perl6/Grammar.nqp#L1548 This appears to be fixed now: m: need v6.d rakudo-moar e7e91ecfb: OUTPUT: «===SORRY!=== Error while compiling In case of using pragma, use "use" instead (e.g., "use v6;", "use v6.c;").at :1--> need v6.d⏏»
Re: [perl #133541] Grammer bug vs
Actually, if you change it to .*| -- this will work as you
expect. It's a bug that your version doesn't work, of course. It does
seem to involve tangentially, but it is unrelated to underscore.
On Mon, Oct 1, 2018 at 6:17 PM Vijayvithal via RT <
perl6-bugs-follo...@perl.org> wrote:
> This issue surfaces because of the token TOP line. If instead of
> | only ruport was used the testcase works for both cases.
> So it is quite
> possible that the bug is elsewhere but shows up as a difference between
> alpha and alnum.
>
> Regards
> Vijay
>
>
> On Fri, Sep 28, 2018 at 07:18:49AM -0700, Patrick R. Michaud via RT wrote:
> > The issue doesn't seem to be the underscore, because I get the same
> result even when converting the underscore into a letter ('b'):
> >
> > $ cat gentb.p6
> > grammar G0 {
> > token TOP {|.*}
> > regex rport { }
> > rule ruport { }
> > #token type {+}
> > token type {+}
> > }
> >
> > grammar G1 {
> > token TOP {|.*}
> > regex rport { }
> > rule ruport { }
> > token type {+}
> > #token type {+}
> > }
> > my $str="scbin bar";
> > say "=== Example==";
> > say G0.parse($str);
> > say "=== Example==";
> > say G1.parse($str);
> >
> > $ perl6 gentb.p6
> > === Example==
> > Nil
> > === Example==
> > ｢scbin bar｣
> > ruport => ｢scbin｣
> > type => ｢scbin｣
> >alpha => ｢s｣
> >alpha => ｢c｣
> >alpha => ｢b｣
> >alpha => ｢i｣
> >alpha => ｢n｣
> > $
> >
> >
> > On Fri, Sep 28, 2018 at 02:26:41AM -0700, Brent Laabs wrote:
> > > Are you sure about that? Underscore has been part of the specs
> (synopses)
> > > for for at least 10 years, probably longer.
> > >
> > > > "_" ~~ //
> > > ｢_｣
> > > alpha => ｢_｣
> > >
> > > On Thu, Sep 27, 2018 at 7:52 PM Brandon Allbery
> wrote:
> > >
> > > > "_" is not an alphabetic character. It's allowed in "alnum" because
> that
> > > > is by intent what is \w in other regex implementations, which
> includes "_".
> > > >
> > > > On Thu, Sep 27, 2018 at 10:47 PM Vijayvithal <
> perl6-bugs-follo...@perl.org>
> > > > wrote:
> > > >
> > > >> # New Ticket Created by Vijayvithal
> > > >> # Please include the string: [perl #133541]
> > > >> # in the subject line of all future correspondence about this issue.
> > > >> # https://rt.perl.org/Ticket/Display.html?id=133541 >
> > > >>
> > > >>
> > > >> In the attached code, the only difference between the Grammars G0
> and G1
> > > >> is the defination of token 'type' it is defined as in one
> case
> > > >> and as in another.
> > > >>
> > > >> Since the string being matched is 'sc_in' both the alpha and alnum
> > > >> tokens should have captured it. But we see the following result on
> > > >> execution
> > > >>
> > > >> === Example==
> > > >> Nil
> > > >> === Example==
> > > >> ｢sc_in bar｣
> > > >> ruport => ｢sc_in｣
> > > >> type => ｢sc_in｣
> > > >> alpha => ｢s｣
> > > >> alpha => ｢c｣
> > > >> alpha => ｢_｣
> > > >> alpha => ｢i｣
> > > >> alpha => ｢n｣
> > > >>
> > > >>
> > > >> Perl Version is
> > > >>
> > > >> This is Rakudo Star version 2018.06 built on MoarVM version 2018.06
> > > >> implementing Perl 6.c.
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Vijayvithal
> > > >> Dyumnin Semiconductors
> > > >>
> > > >
> > > >
> > > > --
> > > > brandon s allbery kf8nh
> > > > allber...@gmail.com
> > > >
> >
>
> --
> Vijayvithal
> Dyumnin Semiconductors
>
>
Re: [perl #133541] Grammer bug vs
This issue surfaces because of the token TOP line. If instead of
| only ruport was used the testcase works for both cases. So it
is quite
possible that the bug is elsewhere but shows up as a difference between
alpha and alnum.
Regards
Vijay
On Fri, Sep 28, 2018 at 07:18:49AM -0700, Patrick R. Michaud via RT wrote:
> The issue doesn't seem to be the underscore, because I get the same result
> even when converting the underscore into a letter ('b'):
>
> $ cat gentb.p6
> grammar G0 {
> token TOP {|.*}
> regex rport { }
> rule ruport { }
> #token type {+}
> token type {+}
> }
>
> grammar G1 {
> token TOP {|.*}
> regex rport { }
> rule ruport { }
> token type {+}
> #token type {+}
> }
> my $str="scbin bar";
> say "=== Example==";
> say G0.parse($str);
> say "=== Example==";
> say G1.parse($str);
>
> $ perl6 gentb.p6
> === Example==
> Nil
> === Example==
> ｢scbin bar｣
> ruport => ｢scbin｣
> type => ｢scbin｣
>alpha => ｢s｣
>alpha => ｢c｣
>alpha => ｢b｣
>alpha => ｢i｣
>alpha => ｢n｣
> $
>
>
> On Fri, Sep 28, 2018 at 02:26:41AM -0700, Brent Laabs wrote:
> > Are you sure about that? Underscore has been part of the specs (synopses)
> > for for at least 10 years, probably longer.
> >
> > > "_" ~~ //
> > ｢_｣
> > alpha => ｢_｣
> >
> > On Thu, Sep 27, 2018 at 7:52 PM Brandon Allbery wrote:
> >
> > > "_" is not an alphabetic character. It's allowed in "alnum" because that
> > > is by intent what is \w in other regex implementations, which includes
> > > "_".
> > >
> > > On Thu, Sep 27, 2018 at 10:47 PM Vijayvithal
> > >
> > > wrote:
> > >
> > >> # New Ticket Created by Vijayvithal
> > >> # Please include the string: [perl #133541]
> > >> # in the subject line of all future correspondence about this issue.
> > >> # https://rt.perl.org/Ticket/Display.html?id=133541 >
> > >>
> > >>
> > >> In the attached code, the only difference between the Grammars G0 and G1
> > >> is the defination of token 'type' it is defined as in one case
> > >> and as in another.
> > >>
> > >> Since the string being matched is 'sc_in' both the alpha and alnum
> > >> tokens should have captured it. But we see the following result on
> > >> execution
> > >>
> > >> === Example==
> > >> Nil
> > >> === Example==
> > >> ｢sc_in bar｣
> > >> ruport => ｢sc_in｣
> > >> type => ｢sc_in｣
> > >> alpha => ｢s｣
> > >> alpha => ｢c｣
> > >> alpha => ｢_｣
> > >> alpha => ｢i｣
> > >> alpha => ｢n｣
> > >>
> > >>
> > >> Perl Version is
> > >>
> > >> This is Rakudo Star version 2018.06 built on MoarVM version 2018.06
> > >> implementing Perl 6.c.
> > >>
> > >>
> > >>
> > >> --
> > >> Vijayvithal
> > >> Dyumnin Semiconductors
> > >>
> > >
> > >
> > > --
> > > brandon s allbery kf8nh
> > > allber...@gmail.com
> > >
>
--
Vijayvithal
Dyumnin Semiconductors
signature.asc
Description: PGP signature
Re: [perl #133541] Grammer bug vs
This is in conflict with the documentation at https://docs.perl6.org/language/regexes which states Alphabetic characters including _ And \w. plus In my example. '_' matches the alpha regex. As per specifications, Everything that matches alpha should match alnum. Which in the given example does not.On Sep 28, 2018 8:22 AM, Brandon Allbery via RT wrote: > > "_" is not an alphabetic character. It's allowed in "alnum" because that is > by intent what is \w in other regex implementations, which includes "_". > > On Thu, Sep 27, 2018 at 10:47 PM Vijayvithal > wrote: > > > # New Ticket Created by Vijayvithal > > # Please include the string: [perl #133541] > > # in the subject line of all future correspondence about this issue. > > # https://rt.perl.org/Ticket/Display.html?id=133541 > > > > > > > In the attached code, the only difference between the Grammars G0 and G1 > > is the defination of token 'type' it is defined as in one case > > and as in another. > > > > Since the string being matched is 'sc_in' both the alpha and alnum > > tokens should have captured it. But we see the following result on > > execution > > > > === Example== > > Nil > > === Example== > > ｢sc_in bar｣ > > ruport => ｢sc_in｣ > > type => ｢sc_in｣ > > alpha => ｢s｣ > > alpha => ｢c｣ > > alpha => ｢_｣ > > alpha => ｢i｣ > > alpha => ｢n｣ > > > > > > Perl Version is > > > > This is Rakudo Star version 2018.06 built on MoarVM version 2018.06 > > implementing Perl 6.c. > > > > > > > > -- > > Vijayvithal > > Dyumnin Semiconductors > > > > > -- > brandon s allbery kf8nh > allber...@gmail.com >
Re: [perl #133541] Grammer bug vs
Golfs to just the top grammar, which is the only one that returns Nil.
grammar Alnum1 {
token TOP {|.*}
}
grammar AlnumReversed {
token TOP {.*|}
}
grammar Alpha1 {
token TOP {|.*}
}
my $rx = rx/^ [|.*] $/;
my $str="n~";
.say for "=== ==",
Alnum1.parse($str),
"=== (reversed) ===",
AlnumReversed.parse($str),
"=== ==",
Alpha1.parse($str),
"=== Regex ==",
$str ~~ $rx;
On Fri, Sep 28, 2018 at 7:19 AM Patrick R. Michaud via RT <
perl6-bugs-follo...@perl.org> wrote:
> The issue doesn't seem to be the underscore, because I get the same result
> even when converting the underscore into a letter ('b'):
>
> $ cat gentb.p6
> grammar G0 {
> token TOP {|.*}
> regex rport { }
> rule ruport { }
> #token type {+}
> token type {+}
> }
>
> grammar G1 {
> token TOP {|.*}
> regex rport { }
> rule ruport { }
> token type {+}
> #token type {+}
> }
> my $str="scbin bar";
> say "=== Example==";
> say G0.parse($str);
> say "=== Example==";
> say G1.parse($str);
>
> $ perl6 gentb.p6
> === Example==
> Nil
> === Example==
> ｢scbin bar｣
> ruport => ｢scbin｣
> type => ｢scbin｣
>alpha => ｢s｣
>alpha => ｢c｣
>alpha => ｢b｣
>alpha => ｢i｣
>alpha => ｢n｣
> $
>
>
> On Fri, Sep 28, 2018 at 02:26:41AM -0700, Brent Laabs wrote:
> > Are you sure about that? Underscore has been part of the specs
> (synopses)
> > for for at least 10 years, probably longer.
> >
> > > "_" ~~ //
> > ｢_｣
> > alpha => ｢_｣
> >
> > On Thu, Sep 27, 2018 at 7:52 PM Brandon Allbery
> wrote:
> >
> > > "_" is not an alphabetic character. It's allowed in "alnum" because
> that
> > > is by intent what is \w in other regex implementations, which includes
> "_".
> > >
> > > On Thu, Sep 27, 2018 at 10:47 PM Vijayvithal <
> perl6-bugs-follo...@perl.org>
> > > wrote:
> > >
> > >> # New Ticket Created by Vijayvithal
> > >> # Please include the string: [perl #133541]
> > >> # in the subject line of all future correspondence about this issue.
> > >> # https://rt.perl.org/Ticket/Display.html?id=133541 >
> > >>
> > >>
> > >> In the attached code, the only difference between the Grammars G0 and
> G1
> > >> is the defination of token 'type' it is defined as in one case
> > >> and as in another.
> > >>
> > >> Since the string being matched is 'sc_in' both the alpha and alnum
> > >> tokens should have captured it. But we see the following result on
> > >> execution
> > >>
> > >> === Example==
> > >> Nil
> > >> === Example==
> > >> ｢sc_in bar｣
> > >> ruport => ｢sc_in｣
> > >> type => ｢sc_in｣
> > >> alpha => ｢s｣
> > >> alpha => ｢c｣
> > >> alpha => ｢_｣
> > >> alpha => ｢i｣
> > >> alpha => ｢n｣
> > >>
> > >>
> > >> Perl Version is
> > >>
> > >> This is Rakudo Star version 2018.06 built on MoarVM version 2018.06
> > >> implementing Perl 6.c.
> > >>
> > >>
> > >>
> > >> --
> > >> Vijayvithal
> > >> Dyumnin Semiconductors
> > >>
> > >
> > >
> > > --
> > > brandon s allbery kf8nh
> > > allber...@gmail.com
> > >
>
>
Re: [perl #133541] Grammer bug vs
The issue doesn't seem to be the underscore, because I get the same result even
when converting the underscore into a letter ('b'):
$ cat gentb.p6
grammar G0 {
token TOP {|.*}
regex rport { }
rule ruport { }
#token type {+}
token type {+}
}
grammar G1 {
token TOP {|.*}
regex rport { }
rule ruport { }
token type {+}
#token type {+}
}
my $str="scbin bar";
say "=== Example==";
say G0.parse($str);
say "=== Example==";
say G1.parse($str);
$ perl6 gentb.p6
=== Example==
Nil
=== Example==
｢scbin bar｣
ruport => ｢scbin｣
type => ｢scbin｣
alpha => ｢s｣
alpha => ｢c｣
alpha => ｢b｣
alpha => ｢i｣
alpha => ｢n｣
$
On Fri, Sep 28, 2018 at 02:26:41AM -0700, Brent Laabs wrote:
> Are you sure about that? Underscore has been part of the specs (synopses)
> for for at least 10 years, probably longer.
>
> > "_" ~~ //
> ｢_｣
> alpha => ｢_｣
>
> On Thu, Sep 27, 2018 at 7:52 PM Brandon Allbery wrote:
>
> > "_" is not an alphabetic character. It's allowed in "alnum" because that
> > is by intent what is \w in other regex implementations, which includes "_".
> >
> > On Thu, Sep 27, 2018 at 10:47 PM Vijayvithal
> > wrote:
> >
> >> # New Ticket Created by Vijayvithal
> >> # Please include the string: [perl #133541]
> >> # in the subject line of all future correspondence about this issue.
> >> # https://rt.perl.org/Ticket/Display.html?id=133541 >
> >>
> >>
> >> In the attached code, the only difference between the Grammars G0 and G1
> >> is the defination of token 'type' it is defined as in one case
> >> and as in another.
> >>
> >> Since the string being matched is 'sc_in' both the alpha and alnum
> >> tokens should have captured it. But we see the following result on
> >> execution
> >>
> >> === Example==
> >> Nil
> >> === Example==
> >> ｢sc_in bar｣
> >> ruport => ｢sc_in｣
> >> type => ｢sc_in｣
> >> alpha => ｢s｣
> >> alpha => ｢c｣
> >> alpha => ｢_｣
> >> alpha => ｢i｣
> >> alpha => ｢n｣
> >>
> >>
> >> Perl Version is
> >>
> >> This is Rakudo Star version 2018.06 built on MoarVM version 2018.06
> >> implementing Perl 6.c.
> >>
> >>
> >>
> >> --
> >> Vijayvithal
> >> Dyumnin Semiconductors
> >>
> >
> >
> > --
> > brandon s allbery kf8nh
> > allber...@gmail.com
> >
Re: [perl #133541] Grammer bug vs
Are you sure about that? Underscore has been part of the specs (synopses) for for at least 10 years, probably longer. > "_" ~~ // ｢_｣ alpha => ｢_｣ On Thu, Sep 27, 2018 at 7:52 PM Brandon Allbery wrote: > "_" is not an alphabetic character. It's allowed in "alnum" because that > is by intent what is \w in other regex implementations, which includes "_". > > On Thu, Sep 27, 2018 at 10:47 PM Vijayvithal > wrote: > >> # New Ticket Created by Vijayvithal >> # Please include the string: [perl #133541] >> # in the subject line of all future correspondence about this issue. >> # https://rt.perl.org/Ticket/Display.html?id=133541 > >> >> >> In the attached code, the only difference between the Grammars G0 and G1 >> is the defination of token 'type' it is defined as in one case >> and as in another. >> >> Since the string being matched is 'sc_in' both the alpha and alnum >> tokens should have captured it. But we see the following result on >> execution >> >> === Example== >> Nil >> === Example== >> ｢sc_in bar｣ >> ruport => ｢sc_in｣ >> type => ｢sc_in｣ >> alpha => ｢s｣ >> alpha => ｢c｣ >> alpha => ｢_｣ >> alpha => ｢i｣ >> alpha => ｢n｣ >> >> >> Perl Version is >> >> This is Rakudo Star version 2018.06 built on MoarVM version 2018.06 >> implementing Perl 6.c. >> >> >> >> -- >> Vijayvithal >> Dyumnin Semiconductors >> > > > -- > brandon s allbery kf8nh > allber...@gmail.com >
Re: [perl #133541] Grammer bug vs
"_" is not an alphabetic character. It's allowed in "alnum" because that is by intent what is \w in other regex implementations, which includes "_". On Thu, Sep 27, 2018 at 10:47 PM Vijayvithal wrote: > # New Ticket Created by Vijayvithal > # Please include the string: [perl #133541] > # in the subject line of all future correspondence about this issue. > # https://rt.perl.org/Ticket/Display.html?id=133541 > > > > In the attached code, the only difference between the Grammars G0 and G1 > is the defination of token 'type' it is defined as in one case > and as in another. > > Since the string being matched is 'sc_in' both the alpha and alnum > tokens should have captured it. But we see the following result on > execution > > === Example== > Nil > === Example== > ｢sc_in bar｣ > ruport => ｢sc_in｣ > type => ｢sc_in｣ > alpha => ｢s｣ > alpha => ｢c｣ > alpha => ｢_｣ > alpha => ｢i｣ > alpha => ｢n｣ > > > Perl Version is > > This is Rakudo Star version 2018.06 built on MoarVM version 2018.06 > implementing Perl 6.c. > > > > -- > Vijayvithal > Dyumnin Semiconductors > -- brandon s allbery kf8nh allber...@gmail.com
[perl #133541] Grammer bug vs
# New Ticket Created by Vijayvithal
# Please include the string: [perl #133541]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=133541 >
In the attached code, the only difference between the Grammars G0 and G1
is the defination of token 'type' it is defined as in one case
and as in another.
Since the string being matched is 'sc_in' both the alpha and alnum
tokens should have captured it. But we see the following result on
execution
=== Example==
Nil
=== Example==
｢sc_in bar｣
ruport => ｢sc_in｣
type => ｢sc_in｣
alpha => ｢s｣
alpha => ｢c｣
alpha => ｢_｣
alpha => ｢i｣
alpha => ｢n｣
Perl Version is
This is Rakudo Star version 2018.06 built on MoarVM version 2018.06
implementing Perl 6.c.
--
Vijayvithal
Dyumnin Semiconductors
grammar G0 {
token TOP {|.*}
regex rport { }
rule ruport { }
#token type {+}
token type {+}
}
grammar G1 {
token TOP {|.*}
regex rport { }
rule ruport { }
token type {+}
#token type {+}
}
my $str="sc_in bar";
say "=== Example==";
say G0.parse($str);
say "=== Example==";
say G1.parse($str);
signature.asc
Description: PGP signature
[perl #127933] [REPL] int# bug
On Sun, 28 Aug 2016 09:40:51 -0700, barto...@gmx.de wrote: > Just a note: This seems to be a specific problem with Moar: > > $ ./perl6-j > [...] > > my int8 $i = 0x78; > 120 > > my int8 $j = 0x78; > 120 > > > > I'm going to tag this ticket with [MoarVM]. Or should the ticket be > moved to the Github repo for MoarVM? Closing as the ticket now moved to GitHub: https://github.com/rakudo/rakudo/issues/2284
[perl #127933] [REPL] int# bug
On Sun, 28 Aug 2016 09:40:51 -0700, barto...@gmx.de wrote: > Just a note: This seems to be a specific problem with Moar: > > $ ./perl6-j > [...] > > my int8 $i = 0x78; > 120 > > my int8 $j = 0x78; > 120 > > > > I'm going to tag this ticket with [MoarVM]. Or should the ticket be > moved to the Github repo for MoarVM? Closing as the ticket now moved to GitHub: https://github.com/rakudo/rakudo/issues/2284
[perl #131099] [LTA] is assoc('list') gives "MVMArray: Can't pop from an empty array"
> On Tue, 04 Apr 2017 11:05:05 -0700, c...@zoffix.com wrote: > This is partially fixed now for `is equiv` with > https://github.com/rakudo/rakudo/commit/f9f0883c6c and > https://github.com/perl6/roast/commit/75f42755ec FYI: with 6.d prep going on, I reverted[^1] that test for now Don't want to spec the test's behaviour until this ticket and behaviour in related tickets[^2] are entirely resolved/specced [1] https://github.com/perl6/roast/commit/b9c2a956e1dbfe39603 [2] RT#132713, RT#132710, RT#132711, maybe more https://rt.perl.org/Public/Bug/Display.html?id=132713 https://rt.perl.org/Public/Bug/Display.html?id=132710 https://rt.perl.org/Public/Bug/Display.html?id=132711
[perl #131099] [LTA] is assoc('list') gives "MVMArray: Can't pop from an empty array"
> On Tue, 04 Apr 2017 11:05:05 -0700, c...@zoffix.com wrote: > This is partially fixed now for `is equiv` with > https://github.com/rakudo/rakudo/commit/f9f0883c6c and > https://github.com/perl6/roast/commit/75f42755ec FYI: with 6.d prep going on, I reverted[^1] that test for now Don't want to spec the test's behaviour until this ticket and behaviour in related tickets[^2] are entirely resolved/specced [1] https://github.com/perl6/roast/commit/b9c2a956e1dbfe39603 [2] RT#132713, RT#132710, RT#132711, maybe more https://rt.perl.org/Public/Bug/Display.html?id=132713 https://rt.perl.org/Public/Bug/Display.html?id=132710 https://rt.perl.org/Public/Bug/Display.html?id=132711
[perl #131003] [SEVERE][SEGV] Heap corruption when using Gumbo
I patched Gumbo to no longer create an XML tree but just a bunch of hashes, yet the error remains. So it's clearly not the XML module causing the issue but some NativeCall Gumbo thing. Gumbo makes heavy use of structs and nested structs. I guess the latter could be worth having a look as that's something that probably hasn't seen much use yet.
[perl #131919] [RFC] Returning Failure from failed P6-level .parse
On Mon, 21 Aug 2017 07:38:56 -0700, alex.jakime...@gmail.com wrote:
> It was removed completely for 2017.08 release.
>
> Rakudo commit:
> https://github.com/rakudo/rakudo/commit/465d91abdfda038cb7feda35f7966be4ec39acf3
> Discussion: https://irclog.perlgeek.de/perl6-dev/2017-08-21#i_15048995
> On 2017-08-19 15:31:01, alex.jakime...@gmail.com wrote:
> > I had to revert one of the nqp commits related to .parse:
> > https://github.com/perl6/nqp/commit/d4d77b66c46c57de800b147df61fe486b4486acd
> >
> > Here's a ticket for the module that was affected by the change:
> > https://github.com/p6-css/CSS-Module-p6/issues/10
> >
> > Most certainly we want this change back ASAP, but it had to be
> > reverted for the
> > release.
> >
> > ♥
> >
> > On 2017-08-19 05:36:36, alex.jakime...@gmail.com wrote:
> > > The change was moved to v6.d in this commit:
> > >
> >
> https://github.com/rakudo/rakudo/commit/d2278b471cb0bd691dc7a1235fbcb9318ff5d61f
> > >
> > > On 2017-08-17 08:50:48, alex.jakime...@gmail.com wrote:
> > > > See this commit:
> > > >
> > >
> >
> https://github.com/rakudo/rakudo/commit/9501edae4f73a970e3270e3b0336a7b3045d3329
> > > >
> > > > These roast commits:
> > > > *
> > > >
> > >
> >
> https://github.com/perl6/roast/commit/1fb68c4b7a7c975f26fc81ad79f000958d1b4afd
> > > > *
> > > >
> > >
> >
> https://github.com/perl6/roast/commit/b53616f8e67f9b19366008b3abf55400a3d6cd2b
> > > >
> > > > And this justification:
> > > > * https://irclog.perlgeek.de/perl6-dev/2017-08-16#i_15021994
> > > >
> > > > This blog post noticing the breakage due to the change:
> > > > * https://gfldex.wordpress.com/2017/08/17/parsing-nothing/
> > > >
> > > > And these thoughts about postponing it to v6.d:
> > > > * https://irclog.perlgeek.de/perl6-dev/2017-08-17#i_15032160
> > > >
> > > >
> > > > I am confident that we will not be able to process this change
> > > > and
> > > > all
> > > > potential breakage associated with it in ≈3 days before the
> > > > release,
> > > > so the revert is coming.
> > > >
> > > > Personally, I don't mind rereverting it afterwards for inclusion
> > > > in
> > > > 2017.09, assuming we make sure to fix all modules that were
> > > > relying
> > > > on
> > > > Nils being returned. However, I do see the point for postponing
> > > > it
> > > > till v6.d.
> > > >
> > > >
> > > > So should we feel adventurous and push this change as early as we
> > > > can
> > > > (in 2017.09, aftear at least one month)? Or is it better to be
> > > > safe
> > > > and wait for v6.d? Please discuss.
I've had a chance to golf this (somewhat) from CSS::Module. The following fails
to parse if I revert
https://github.com/perl6/nqp/commit/d4d77b66c46c57de800b147df61fe486b4486acd
grammar Tst {
rule local {:i('local')'(' [ \'\' ] ')'}
rule declaration-list { * }
rule declarations {
'{' '}'
}
rule test-prop { (src) ':' +% ',' }
}
say Tst.parse('{ src: local(\'Gentium\') }', :rule )
Re: [perl #131599] [RFC] Allow a Callable for `is default` that will generate default values
FWIW, with:
http://modules.perl6.org/dist/Hash::Restricted:cpan:ELIZABETH
one can restrict access to a hash to a certain set of keys:
use Hash::Restricted;
my %h is restricted = a => 42, b => 666; # restrict to keys at initialization
my %h is restricted; # restrict to keys a, b, c
> On 18 Jul 2018, at 17:32, Alastair Douglas via RT
> wrote:
>
> On Mon, 19 Jun 2017 09:30:41 -0700, brad wrote:
>> The way Moose in Perl 5 works around this is to give it a subroutine
>
>> there currently isn't as far as I know, a way to do what you intended.
>
> I'd like this feature as well. I was in IRC asking about whether we could
> restrict a hash in the same way python does, such that %hash
> dies.
>
> It was noted that one can do
>
> my %h is default(Failure.new);
>
> This would put a Failure in anything that didn't exist, which would detonate
> whenever accessed. Presumably, this would be the same Failure each time, but
> that's probably OK.
>
> It means there is no way of generating a default based on access. I think
> that would look something like:
>
> my %h is default(-> $key { Failure.new("$key not provided") });
>
> But then how would it know to run the Callable to generate the default,
> rather than simply providing the Callable as the default? I have no answer
> for that.
[perl #131599] [RFC] Allow a Callable for `is default` that will generate default values
On Mon, 19 Jun 2017 09:30:41 -0700, brad wrote:
> The way Moose in Perl 5 works around this is to give it a subroutine
> there currently isn't as far as I know, a way to do what you intended.
I'd like this feature as well. I was in IRC asking about whether we could
restrict a hash in the same way python does, such that %hash
dies.
It was noted that one can do
my %h is default(Failure.new);
This would put a Failure in anything that didn't exist, which would detonate
whenever accessed. Presumably, this would be the same Failure each time, but
that's probably OK.
It means there is no way of generating a default based on access. I think that
would look something like:
my %h is default(-> $key { Failure.new("$key not provided") });
But then how would it know to run the Callable to generate the default, rather
than simply providing the Callable as the default? I have no answer for that.
[perl #133082] [LTA] precedence error !%foo:exists
Another user opened the same ticket on our primary tracker, so I'll close this one in favour of that one:https://github.com/rakudo/rakudo/issues/2098
Re: [perl #128154] [BUG] Cannot use qqx in rakudo star on windows7
I'm not sure. Probably your idea of warning about detected encoding is better. S On Thu, 12 Jul 2018 at 09:58, Kamil Kułaga via RT wrote: > > Will it work fine for utf-16 users? > On Wed, Jul 11, 2018 at 11:16 AM Steve Mynott via RT > wrote: > > > > Maybe the Windows port of rakudo should set this automatically on startup? > > On Wed, 11 Jul 2018 at 10:08, Kamil Kułaga via RT > > wrote: > > > > > > I found resolution. It looks like it is problem windows locale issue than > > > perl itself. > > > > > > Running command > > > > > > chcp utf8 > > > > > > Makes work just fine. Default is 852. I'm very supprised because I use > > > unicode encoding all the the time and never had such issue. For me it > > > would be better to detect if codepage is set to 852 and warn user that > > > perl6 may not work well. Shall we close it or leave defect for future > > > improvement? > > > > > > > > -- > > Steve Mynott > > cv25519/ECF8B611205B447E091246AF959E3D6197190DD5 > > > > > -- > Pozdrawiam > > Kamil Kułaga -- Steve Mynott cv25519/ECF8B611205B447E091246AF959E3D6197190DD5
Re: [perl #128154] [BUG] Cannot use qqx in rakudo star on windows7
Will it work fine for utf-16 users? On Wed, Jul 11, 2018 at 11:16 AM Steve Mynott via RT wrote: > > Maybe the Windows port of rakudo should set this automatically on startup? > On Wed, 11 Jul 2018 at 10:08, Kamil Kułaga via RT > wrote: > > > > I found resolution. It looks like it is problem windows locale issue than > > perl itself. > > > > Running command > > > > chcp utf8 > > > > Makes work just fine. Default is 852. I'm very supprised because I use > > unicode encoding all the the time and never had such issue. For me it would > > be better to detect if codepage is set to 852 and warn user that perl6 may > > not work well. Shall we close it or leave defect for future improvement? > > > > -- > Steve Mynott > cv25519/ECF8B611205B447E091246AF959E3D6197190DD5 > -- Pozdrawiam Kamil Kułaga
Re: [perl #128154] [BUG] Cannot use qqx in rakudo star on windows7
Maybe the Windows port of rakudo should set this automatically on startup? On Wed, 11 Jul 2018 at 10:08, Kamil Kułaga via RT wrote: > > I found resolution. It looks like it is problem windows locale issue than > perl itself. > > Running command > > chcp utf8 > > Makes work just fine. Default is 852. I'm very supprised because I use > unicode encoding all the the time and never had such issue. For me it would > be better to detect if codepage is set to 852 and warn user that perl6 may > not work well. Shall we close it or leave defect for future improvement? -- Steve Mynott cv25519/ECF8B611205B447E091246AF959E3D6197190DD5
[perl #128154] [BUG] Cannot use qqx in rakudo star on windows7
I found resolution. It looks like it is problem windows locale issue than perl itself. Running command chcp utf8 Makes work just fine. Default is 852. I'm very supprised because I use unicode encoding all the the time and never had such issue. For me it would be better to detect if codepage is set to 852 and warn user that perl6 may not work well. Shall we close it or leave defect for future improvement?
[perl #133300] missing symbol name in error for &::() lookup failure
# New Ticket Created by Brandon Allbery
# Please include the string: [perl #133300]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=133300 >
[25 00:11:06] What is wrong with this one:
`&::($RunSpecific)();` No such symbol ''
[25 00:11:45] I don't see me using any single quotes
[25 00:13:23] it's an empty string, with the single quotes part
of the error message to set off the symbol it's looking for?
[25 00:15:11] hm, actually it says that for any not found
symbol, so that may be showing a bug
[25 00:15:57] m: my $RunSpecific = 'glup'; say
&::($RunSpecific)();
[25 00:15:58] rakudo-moar e9351cbaa: OUTPUT: «No such symbol ''
[25 00:15:58]in block at line 1
[25 00:15:58] 
[25 00:15:58] »
[25 00:15:59] m: sub glup { 1 }; my $RunSpecific = 'glup'; say
&::($RunSpecific)();
[25 00:16:00] rakudo-moar e9351cbaa: OUTPUT: «1
[25 00:16:00] »
[perl #129197] [BUG][IO] "Invalid free()" when passing the output of one Proc to the input of another
On Sun, 04 Sep 2016 11:35:06 -0700, ddgr...@gmail.com wrote:
> When running the below code, using a moar built with --debug
> valgrind --trace-children=yes ~/Source/perl6/install/bin/perl6 -e 'for
> ^1000 { my $proc = run(:out, :bin, ‘tar’, ‘cf’, ‘-’, ‘--absolute-
> names’, ‘--’, "417d97ddcffcb4404aba396509bd06d0cf81f013-texas"); say
> "$_: created tar"; run(:in($proc.out), :bin, ‘lzop’, ‘-f’, ‘-q’, "-o",
> "4-texas.lzop"); say "$_: ran lzop"; }'
>
> ==29941== Invalid free() / delete / delete[] / realloc()
> ==29941==at 0x4C2AD90: free (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==29941==by 0x4FC6C43: MVM_free (alloc.h:29)
> ==29941==by 0x4FC6C43: do_close (syncpipe.c:37)
> ==29941==by 0x4FC6C43: closefh (syncpipe.c:52)
> ==29941==by 0x4FC388A: MVM_io_close (io.c:28)
> ==29941==by 0x4F8F2E0: MVM_interp_run (interp.c:4361)
> ==29941==by 0x50526F8: MVM_vm_run_file (moar.c:304)
> ==29941==by 0x400ED3: main (main.c:191)
> ==29941== Address 0xffefffd40 is on thread 1's stack
> ==29941==
> ==29941== Conditional jump or move depends on uninitialised value(s)
> ==29941==at 0x4FB7B58: MVM_intcache_get (intcache.c:40)
> ==29941==by 0x4F85C65: MVM_args_slurpy_positional (args.c:574)
> ==29941==by 0x4F9B6DB: MVM_interp_run (interp.c:1046)
> ==29941==by 0x50526F8: MVM_vm_run_file (moar.c:304)
> ==29941==by 0x400ED3: main (main.c:191)
> ==29941==
> ==29941== Conditional jump or move depends on uninitialised value(s)
> ==29941==at 0x4FEB3C0: set_int (P6bigint.c:73)
> ==29941==by 0x4F85E31: MVM_args_slurpy_positional (args.c:574)
> ==29941==by 0x4F9B6DB: MVM_interp_run (interp.c:1046)
> ==29941==by 0x50526F8: MVM_vm_run_file (moar.c:304)
> ==29941==by 0x400ED3: main (main.c:191)
> ==29941==
> ==29941== Conditional jump or move depends on uninitialised value(s)
> ==29941==at 0x4FB7B58: MVM_intcache_get (intcache.c:40)
> ==29941==by 0x4F842C8: MVM_args_get_pos_obj (args.c:297)
> ==29941==by 0x4F913C3: MVM_interp_run (interp.c:917)
> ==29941==by 0x50526F8: MVM_vm_run_file (moar.c:304)
> ==29941==by 0x400ED3: main (main.c:191)
> ==29941==
> ==29941== Conditional jump or move depends on uninitialised value(s)
> ==29941==at 0x4FEB3C0: set_int (P6bigint.c:73)
> ==29941==by 0x4F8434C: MVM_args_get_pos_obj (args.c:297)
> ==29941==by 0x4F913C3: MVM_interp_run (interp.c:917)
> ==29941==by 0x50526F8: MVM_vm_run_file (moar.c:304)
> ==29941==by 0x400ED3: main (main.c:191)
> ==29941==
> ==29941== Conditional jump or move depends on uninitialised value(s)
> ==29941==at 0x5048E0C: MVM_bigint_cmp (bigintops.c:479)
> ==29941==by 0x4F94259: MVM_interp_run (interp.c:3275)
> ==29941==by 0x50526F8: MVM_vm_run_file (moar.c:304)
> ==29941==by 0x400ED3: main (main.c:191)
> ==29941==
> ==29941== Conditional jump or move depends on uninitialised value(s)
> ==29941==at 0x4F94EDE: MVM_interp_run (interp.c:2858)
> ==29941==by 0x50526F8: MVM_vm_run_file (moar.c:304)
> ==29941==by 0x400ED3: main (main.c:191)
> ==29941==
> ==29941== Use of uninitialised value of size 8
> ==29941==at 0x4F94EE4: MVM_interp_run (interp.c:2858)
> ==29941==by 0x50526F8: MVM_vm_run_file (moar.c:304)
> ==29941==by 0x400ED3: main (main.c:191)
> ==29941==
> ==29941== Use of uninitialised value of size 8
> ==29941==at 0x4F94EEE: MVM_interp_run (interp.c:2858)
> ==29941==by 0x50526F8: MVM_vm_run_file (moar.c:304)
> ==29941==by 0x400ED3: main (main.c:191)
> ==29941==
> ==29941== Conditional jump or move depends on uninitialised value(s)
> ==29941==at 0x4FAEA0A: MVM_is_null (MVMNull.h:11)
> ==29941==by 0x4FAEA0A: MVM_coerce_istrue (coerce.c:31)
> ==29941==by 0x4F9BCF0: MVM_interp_run (interp.c:242)
> ==29941==by 0x50526F8: MVM_vm_run_file (moar.c:304)
> ==29941==by 0x400ED3: main (main.c:191)
> ==29941==
> ==29941== Conditional jump or move depends on uninitialised value(s)
> ==29941==at 0x4FAEA1D: MVM_is_null (MVMNull.h:11)
> ==29941==by 0x4FAEA1D: MVM_coerce_istrue (coerce.c:31)
> ==29941==by 0x4F9BCF0: MVM_interp_run (interp.c:242)
> ==29941==by 0x50526F8: MVM_vm_run_file (moar.c:304)
> ==29941==by 0x400ED3: main (main.c:191)
> ==29941==
> ==29941== Use of uninitialised value of size 8
> ==29941==at 0x4FAEA1F: MVM_coerce_istrue (coerce.c:32)
> ==29941==by 0x4F9BCF0: MVM_interp_run (interp.c:242)
> ==29941==by 0x50526F8: MVM_vm_run_file (moar.c:304)
> ==29941==by 0x400ED3: main (main.c:191)
> ==29941==
> ==29941== Use of uninitialised value of size 8
> ==29941==at 0x4FAEBB2: MVM_coerce_istrue (coerce.c:65)
> ==29941==by 0x4F9BCF0: MVM_interp_run (interp.c:242)
> ==29941==by 0x50526F8: MVM_vm_run_file (moar.c:304)
> ==29941==by 0x400ED3: main (main.c:191)
> ==29941==
> ==29941== Use of uninitialised value of size 8
> ==29941==at 0x4FDFAE0: MVM_p6opaque_real_data (P6opaque.h:108)
> ==29941==by 0x4FDFAE0: get_int
[perl #125908] [BUG] duplicate triggers of .act when using parallel greps on an IO::Notification.watch_path supply
On Tue, 03 Nov 2015 08:54:16 -0800, root+bitc...@retupmoca.com wrote:
> On Wed Aug 26 08:19:35 2015, mura...@pair.com wrote:
> > When two greps are used in parallel on one supply produced by
> > IO::Notification.watch_path, greps that match are triggered twice.
> > Run
> > the following code, then in the same directory `touch watchfile`.
> > Note
> > that I'm also using unique to filter things, as touching a file
> > produces
> > a number of FileChanged events.
> >
> > my $paths = IO::Notification.watch_path('.')\
> > .grep(*.event.isa(FileChangeEvent::FileChanged))\
> > .unique(:as(*.path), :expires(5))\
> > .map(*.path);
> >
> > my $watch = $paths.grep(* ~~ /watchfile/)\
> > .act(-> $x {
> > say "got file change: " ~ $x.perl;
> > });
> >
> > my $never = $paths.grep(* ~~ /shouldneverexecute/)\
> > .act(-> $x {
> > say "should never execute: " ~ $x.perl;
> > });
> >
> > sleep;
> >
> > Output:
> >
> > got file change: "watchfile"
> > got file change: "watchfile"
> >
> > The expected output should be only a single line, not two. I also
> > noticed that each additional grep I add to the supply yields an
> > additional line of the same output.
> >
> > I tried this with a plain supply and could not reproduce the problem:
> >
> > my $s = Supply.new();
> >
> > my $watch = $s.grep(* ~~ /1/)\
> > .act(-> $x {
> > say "got one";
> > });
> >
> > my $never = $s.grep(* ~~ /shouldneverexecute/)\
> > .act(-> $x {
> > say "should never execute";
> > });
> >
> > $s.emit(1);
> > $s.emit(2);
> >
> > sleep;
> >
> > This outputs "got one" a single time, as expected.
> >
> > Perl6 version info: 2015.07.1-161-gf7cfe9d built on MoarVM version
> > 2015.07-57-gec051f5
>
> I think this is a bug in Supply.unique:
>
> 22:38 retupmoca m: my $s = Supply.new; my $s2 =
> $s.unique(:as({$_}), :expires(5)); $s2.act({say $_}); $s.emit(1);
> $s2.act({ say $_ * 2}); $s.emit(2); # re: #125908
> 22:38 camelia rakudo-moar 273e89: OUTPUT«12424»
> 22:38 retupmoca looks like a bug in unique?
$ perl6 -v
This is Rakudo version 2018.06-24-gc441d8d built on MoarVM version 2018.06
implementing Perl 6.c.
tried the original code example and it now only produces one event, i.e.
got file change: "watchfile"
It was suspected that the real problem was a bug in Supply.unique, and the
given example seems to confirm that. However, a lot of water have flowed under
the bridges since then and it seems as if the problem in 'unique' has been
fixed.
I tried the following:
perl6 -e 'my $x = Supplier.new; my $s = $x.Supply; my $s2 =
$s.unique(:as({$_}), :expires(5)); $s2.act({say $_}); $x.emit(1); $s2.act({ say
$_ * 2}); $x.emit(2);'
1
2
4
Had to rewrite the example since the api for supplies has changed since the
original bug report.
Should possibly be marked as TESTNEEDED
[perl #114276] [BUG] Cannot return junctions from .classify blocks in Rakudo
On Tue, 20 Oct 2015 23:06:02 -0700, barto...@gmx.de wrote:
> Current failure mode:
>
> $ perl6-m -e 'say (1, 2).classify: -> $x { 1|2 }'
> P6opaque: no such attribute '$!reified'
> in block at -e:1
>
> $ perl6-m --version
> This is perl6 version 2015.09-431-g5d83db3 built on MoarVM version
> 2015.09-79-gee9fc2b
Things have changed yet again:
$ perl6-m -e 'say (1, 2).classify: -> $x { 1|2 }'
{1 => [1 2], 2 => [1 2]}
$ perl6-m -v
This is Rakudo version 2018.06-24-gc441d8d built on MoarVM version 2018.06
implementing Perl 6.c.
[perl #133016] Wrong set difference of Bag and List
On Thu, 12 Apr 2018 07:21:53 -0700, elizabeth wrote: > Fixed with 344a64e987 , tests needed > > > On 24 Mar 2018, at 15:01, Aleks-Daniel Jakimenko-Aleksejev via RT > > wrote: > > > > FWIW bisectable points to (2017-06-25) > > https://github.com/rakudo/rakudo/commit/a2133dbc6a00d1f87bb0644c829591144381d736 > > > > ( before that it was giving bag(a, b) or bag(b, a) ) > > > > On 2018-03-24 01:43:59, elizabeth wrote: > >> That does indeed look wrong to me, investigating > >> > >>> On 23 Mar 2018, at 15:04, Nick Wellnhofer (via RT) >>> follo...@perl.org> wrote: > >>> > >>> # New Ticket Created by Nick Wellnhofer > >>> # Please include the string: [perl #133016] > >>> # in the subject line of all future correspondence about this > >>> issue. > >>> # https://rt.perl.org/Ticket/Display.html?id=133016 > > >>> > >>> > >>> I get an unexpected result when subtracting a List from a Bag with > >>> the set > >>> difference operator (-). Subtracting Bags from Lists or Bags works > >>> fine, as > >>> does the baggy addition operator: > >>> > >>> say bag() (+) bag(); # Bag(a(3), b) > >>> say bag() (+) ; # Bag(a(3), b) > >>> say (+) bag(); # Bag(a(3), b) > >>> > >>> say bag() (-) bag(); # Bag(a, b) > >>> say bag() (-) ; # Bag(a(2), b) seems wrong > >>> say (-) bag(); # Bag(a, b) > >>> > >>> Only tested online on tio.run > >>> > >>> Rakudo version 2017.12 built on MoarVM version 2017.12 > >>> implementing Perl 6.c. > >>> > >>> and code-golf.io: > >>> > >>> Rakudo version 2018.03 built on MoarVM version 2018.03 > >>> implementing Perl 6.c > >>> > >>> Nick Test added in Roast commit https://github.com/perl6/roast/commit/2288d4a3c543d72f822164dad529066ed055a0aa
[perl #131392] [@LARRY] Remove magic $/ shortcuts %() and @()
Further discussion on https://github.com/rakudo/rakudo/issues/1946 On 2017-05-28 21:20:08, c...@zoffix.com wrote: > On Sun, 28 May 2017 18:18:14 -0700, raiph wrote: > > If there hasn't been significant adoption of these tokens in extant > > code then I'd personally +1 deprecation of them in v6.d in favor of > > `%$/` and `@$/`. > > +1. Even knowing $() was special, it didn't occur to me %() and @() > could be special too. While $() saves some typing, the %() vs %$/ are > no win IMO. > > I listed removal as a proposal in 6.d doc: > https://github.com/perl6/specs/blob/master/v6d.pod > > Renaming this ticket to @LARRY/6.d RFC
[perl #116595] [BUG] Nesting wrapping roles bind 'callsame' to the wrong recipient in Rakudo
On Wed, 30 Jan 2013 07:17:38 -0800, masak wrote:
> rn: role F[$n] { method x { callsame; callsame until $.v % $n }
> }; class S { has $.v is rw = 1; method x { ++$.v } }; my $s = S.new; for
> ^3 { $s.x; say $s.v; $s = $s but F[$s.v] }
> niecza v24-18-gaf64300: OUTPUT«235»
> ..rakudo b3fc32: OUTPUT«(timeout)23»
> jnthn: this is as short as I'm able to golf it.
> jnthn: the problem happens in the 'callsame' in the 'until' loop,
> and the .x method in the S object never gets triggered. or rather, it
> gets triggered in Niecza, but it gets waylaid in Rakudo.
Unchanged behavior in 2018.05-55-g95aa77c94
--
Will "Coke" Coleda
[perl #116595] [BUG] Nesting wrapping roles bind 'callsame' to the wrong recipient in Rakudo
On Wed, 30 Jan 2013 07:17:38 -0800, masak wrote:
> rn: role F[$n] { method x { callsame; callsame until $.v % $n }
> }; class S { has $.v is rw = 1; method x { ++$.v } }; my $s = S.new; for
> ^3 { $s.x; say $s.v; $s = $s but F[$s.v] }
> niecza v24-18-gaf64300: OUTPUT«235»
> ..rakudo b3fc32: OUTPUT«(timeout)23»
> jnthn: this is as short as I'm able to golf it.
> jnthn: the problem happens in the 'callsame' in the 'until' loop,
> and the .x method in the S object never gets triggered. or rather, it
> gets triggered in Niecza, but it gets waylaid in Rakudo.
Unchanged behavior in 2018.05-55-g95aa77c94
--
Will "Coke" Coleda
[perl #124998] [BUG] Type of $¢ is Any instead of Cursor
On Wed, 27 Jul 2016 12:29:11 -0700, coke wrote:
> Here's the test:
>
> my $c;
> ok 'abc' ~~ /.{ $c = $¢ }/, 'current match state';
> #?rakudo todo 'Type of $¢ is Any instead of Cursor - RT #124998'
> is $c.WHAT, Cursor.WHAT,'got right type';
>
> This might be a faulty test, however:
>
> 19:28 < [Coke]> m: my $c; 'abc' ~~ /.{ say $¢.WHAT }/ ;
> 19:28 < camelia> rakudo-moar f0abe8: OUTPUT«Nil»
>
> If the $¢ assignment in there is Nil, then $c is *going* to default to Any.
This appears to be fixed; there's a test in roast (which I've re-added the RT #
to), closing ticket.
--
Will "Coke" Coleda
[perl #124998] [BUG] Type of $¢ is Any instead of Cursor
On Wed, 27 Jul 2016 12:29:11 -0700, coke wrote:
> Here's the test:
>
> my $c;
> ok 'abc' ~~ /.{ $c = $¢ }/, 'current match state';
> #?rakudo todo 'Type of $¢ is Any instead of Cursor - RT #124998'
> is $c.WHAT, Cursor.WHAT,'got right type';
>
> This might be a faulty test, however:
>
> 19:28 < [Coke]> m: my $c; 'abc' ~~ /.{ say $¢.WHAT }/ ;
> 19:28 < camelia> rakudo-moar f0abe8: OUTPUT«Nil»
>
> If the $¢ assignment in there is Nil, then $c is *going* to default to Any.
This appears to be fixed; there's a test in roast (which I've re-added the RT #
to), closing ticket.
--
Will "Coke" Coleda
[perl #132980] Coercion type apparently does not check the actual type of the coerced value
Re-opening this, as there's a much more common case where a typecheck of the
coercion result would be desired and that's when coercion results in a Failure:
m: multi sub foo(Int() $) { }; foo Inf
rakudo-moar 5a6ff4073: ( no output )
[perl #132980] Coercion type apparently does not check the actual type of the coerced value
Re-opening this, as there's a much more common case where a typecheck of the
coercion result would be desired and that's when coercion results in a Failure:
m: multi sub foo(Int() $) { }; foo Inf
rakudo-moar 5a6ff4073: ( no output )
[perl #133246] Possible bug in Perl 6 OO
# New Ticket Created by Richard A Hogaboom
# Please include the string: [perl #133246]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=133246 >
Attached is an executable file that demos a possible Perl 6 OO bug if
attributes and method names are the same. This includes some compile
time errors and an infinite loop.
--
Richard A Hogaboom
16 Alprilla Farm Road
Hopkinton, MA 01748-1922
richard.hogab...@gmail.com
www.linkedin.com/in/richardhogaboom/
https://plus.google.com/+RichardHogaboom
https://github.com/rahogaboom
M508-330-3775
# Richard Hogaboom
# richard.hogab...@gmail.com
# Fedora 28
# Perl 6 2018.04
# uname -a
# Linux new-host-3 4.16.12-300.fc28.x86_64 #1 SMP Fri May 25 21:13:28 UTC 2018
x86_64 x86_64 x86_64 GNU/Linux
# in Perl 6 OO if you have in a class an attribute name and a method name that
are the same,
# some errors may result or not - including compile time errors and an infinite
loop. just
# comment in the various examples one by one to run them individually.
use v6;
=begin pod
# EXAMPLE 1
# this works
class Address {
has $.var is rw;
}
my $addr = Address.new;
$addr.var = 'VAR';
say $addr.var;
=end pod
=begin pod
# EXAMPLE 2
# this works
class Address {
has $.var is rw;
multi method var() {
return $!var;
}
multi method var(Str $v) {
$!var = $v;
}
}
my $addr = Address.new;
$addr.var('VAR');
say $addr.var();
=end pod
=begin pod
# EXAMPLE 3
# adding a method of the same name as the attribute gives:
# Cannot modify an immutable Str (Nil)
# in block at t.p6 line 66
class Address {
has $.var is rw;
method var() {
}
}
my $addr = Address.new;
$addr.var = 'VAR';
say $addr.var;
# is there a general prohibition on having an attribute and an explicit method
of the same name?
=end pod
=begin pod
# EXAMPLE 4
# adding a return statement in the var() method gives a hang.
# using top shows the moar process at 100% CPU.
class Address {
has $.var is rw;
method var() {
return $.var;
}
}
my $addr = Address.new;
$addr.var = 'VAR';
say $addr.var;
# why does just adding a return statement eliminate the compile error? and hang?
# either this should not compile or a run time error should occur, not an
infinite loop.
# adding 'multi' to 'method var() {' above does not help.
=end pod
=begin pod
# EXAMPLE 5
# changing only $.var to $!var in the var() method gives:
# Cannot assign to a readonly variable or a value
# in block at t.p6 line 109
class Address {
has $.var is rw;
method var() {
return $!var;
}
}
my $addr = Address.new;
$addr.var = 'VAR';
say $addr.var;
# this eliminates the infinite loop , but returns to the previous readonly
variable msg.
=end pod
# all this seems a caution against using the same name as an attribute and
explicit method name,
# but shouldn't there be some type of prohibition/warning?
[perl #133246] Possible bug in Perl 6 OO
On Sat, 09 Jun 2018 05:33:04 -0700, c...@zoffix.com wrote:
> when
> using implicit return:
>
>
> method var1() is rw { return$!var }
> method var2() { return-rw $!var }
Correction, that should be:
method var1() is rw { $!var }
method var2() { return-rw $!var }
[perl #133246] Possible bug in Perl 6 OO
On Sat, 09 Jun 2018 05:33:04 -0700, c...@zoffix.com wrote:
> when
> using implicit return:
>
>
> method var1() is rw { return$!var }
> method var2() { return-rw $!var }
Correction, that should be:
method var1() is rw { $!var }
method var2() { return-rw $!var }
[perl #133246] Possible bug in Perl 6 OO
On Mon, 04 Jun 2018 07:31:40 -0700, richard.hogab...@gmail.com wrote:
> Attached is an executable file that demos a possible Perl 6 OO bug if
> attributes and method names are the same. This includes some compile
> time errors and an infinite loop.
>
Thanks for the report, but there's no bug here.
The `has $.foo` attribute syntax is just a shorthand for writing `has $!foo;
method foo { $!foo }`.
In other words, the compiler auto-generated an accessor method for you.
When you use `$.foo` syntax inside a method, it's a shorthand for `self.foo`;
in other words, it's a
method call.
If you define a method with the same name as the attribute, then it signals to
the compiler that you chose
to take care of accessor method yourself.
Also, to return a writeable container, you need to either use `return-rw`
instead of plain `return` when
using explicit return, or apply the `is rw` trait to the method, when using
implicit return:
method var1() is rw { return$!var }
method var2() { return-rw $!var }
With that knowledge, you can see why the failing examples fail:
* EXAMPLE 3: You defined a method with the same name as attribute, so it'll
function as the accessor. The body
of that method is empty, so it returns `Nil` and hence the error
about trying to assign to `Nil`
* EXAMPLE 4: Again, you defined your own accessor, but now you're also using
`$.var` syntax inside, so the method
infiniloops calling itself over and over. Hence the hang.
* EXAMPLE 5: You've used `return` instead of `return-rw`, so only a readonly
value is returned instead of a
writable container. Hence the error
> but shouldn't there be some type of prohibition/warning?
No, as it's perfectly fine to declare your own accessors. Of course, writing
`has $.foo` instead of `has $!foo` is
pointless, in that case, but it serves as a hint to the programmer that it's a
public attribute, so I don't think
warning about that is appropriate.
[perl #133246] Possible bug in Perl 6 OO
On Mon, 04 Jun 2018 07:31:40 -0700, richard.hogab...@gmail.com wrote:
> Attached is an executable file that demos a possible Perl 6 OO bug if
> attributes and method names are the same. This includes some compile
> time errors and an infinite loop.
>
Thanks for the report, but there's no bug here.
The `has $.foo` attribute syntax is just a shorthand for writing `has $!foo;
method foo { $!foo }`.
In other words, the compiler auto-generated an accessor method for you.
When you use `$.foo` syntax inside a method, it's a shorthand for `self.foo`;
in other words, it's a
method call.
If you define a method with the same name as the attribute, then it signals to
the compiler that you chose
to take care of accessor method yourself.
Also, to return a writeable container, you need to either use `return-rw`
instead of plain `return` when
using explicit return, or apply the `is rw` trait to the method, when using
implicit return:
method var1() is rw { return$!var }
method var2() { return-rw $!var }
With that knowledge, you can see why the failing examples fail:
* EXAMPLE 3: You defined a method with the same name as attribute, so it'll
function as the accessor. The body
of that method is empty, so it returns `Nil` and hence the error
about trying to assign to `Nil`
* EXAMPLE 4: Again, you defined your own accessor, but now you're also using
`$.var` syntax inside, so the method
infiniloops calling itself over and over. Hence the hang.
* EXAMPLE 5: You've used `return` instead of `return-rw`, so only a readonly
value is returned instead of a
writable container. Hence the error
> but shouldn't there be some type of prohibition/warning?
No, as it's perfectly fine to declare your own accessors. Of course, writing
`has $.foo` instead of `has $!foo` is
pointless, in that case, but it serves as a hint to the programmer that it's a
public attribute, so I don't think
warning about that is appropriate.
[perl #133268] MoarVM with empty CONTROL {}
On Fri, 08 Jun 2018 15:24:32 -0700, alex.jakime...@gmail.com wrote:
> Golf:
>
> CONTROL {}; warn 42
>
> On 2018-06-08 15:11:08, comdog wrote:
> > While running this program I get a MoarVM panic:
> >
> > 2 + 2 = 4
> > 'two' is not numeric
> > MoarVM panic: Trying to unwind over wrong handler
> >
> > The program:
> >
> > sub add-two-things ( $first, $second ) {
> > CATCH {
> > when X::Str::Numeric {
> > fail q/One of the arguments wasn't a number/
> > }
> > }
> >
> > for $first, $second {
> > warn "'$_' is not numeric" unless val($_) ~~ Numeric;
> > }
> >
> > return $first + $second;
> > }
> >
> > my @items = < 2 2 3 two nine ten 1 37 0 0 >;
> >
> > for @items -> $first, $second {
> > CONTROL {}
> > my $sum = add-two-things( $first, $second );
> >
> > put $sum.defined ??
> > "$first + $second = $sum" !!
> > "You can't add $first and $second";
> > }
> >
This is a dupe of https://github.com/MoarVM/MoarVM/issues/572 (also filed in
Rakudo's repo: https://github.com/rakudo/rakudo/issues/1605 )
Closing this ticket in favour of those Issues.
[perl #133268] MoarVM with empty CONTROL {}
On Fri, 08 Jun 2018 15:24:32 -0700, alex.jakime...@gmail.com wrote:
> Golf:
>
> CONTROL {}; warn 42
>
> On 2018-06-08 15:11:08, comdog wrote:
> > While running this program I get a MoarVM panic:
> >
> > 2 + 2 = 4
> > 'two' is not numeric
> > MoarVM panic: Trying to unwind over wrong handler
> >
> > The program:
> >
> > sub add-two-things ( $first, $second ) {
> > CATCH {
> > when X::Str::Numeric {
> > fail q/One of the arguments wasn't a number/
> > }
> > }
> >
> > for $first, $second {
> > warn "'$_' is not numeric" unless val($_) ~~ Numeric;
> > }
> >
> > return $first + $second;
> > }
> >
> > my @items = < 2 2 3 two nine ten 1 37 0 0 >;
> >
> > for @items -> $first, $second {
> > CONTROL {}
> > my $sum = add-two-things( $first, $second );
> >
> > put $sum.defined ??
> > "$first + $second = $sum" !!
> > "You can't add $first and $second";
> > }
> >
This is a dupe of https://github.com/MoarVM/MoarVM/issues/572 (also filed in
Rakudo's repo: https://github.com/rakudo/rakudo/issues/1605 )
Closing this ticket in favour of those Issues.
[perl #133268] MoarVM with empty CONTROL {}
Golf:
CONTROL {}; warn 42
On 2018-06-08 15:11:08, comdog wrote:
> While running this program I get a MoarVM panic:
>
> 2 + 2 = 4
> 'two' is not numeric
> MoarVM panic: Trying to unwind over wrong handler
>
> The program:
>
> sub add-two-things ( $first, $second ) {
> CATCH {
> when X::Str::Numeric {
> fail q/One of the arguments wasn't a number/
> }
> }
>
> for $first, $second {
> warn "'$_' is not numeric" unless val($_) ~~ Numeric;
> }
>
> return $first + $second;
> }
>
> my @items = < 2 2 3 two nine ten 1 37 0 0 >;
>
> for @items -> $first, $second {
> CONTROL {}
> my $sum = add-two-things( $first, $second );
>
> put $sum.defined ??
> "$first + $second = $sum" !!
> "You can't add $first and $second";
> }
>
[perl #126531] [JVM] throwing X::AdHoc "Cannot assign to a readonly variable or a value" instead of X::Parameter::RW
After https://github.com/rakudo/rakudo/commit/704b893c6a the last tests fudged with this ticket are passing. I'm closing this ticket as 'resolved'.
[perl #127143] Different Behaviour With/Without Commas in Sub/Method Calls and slipped hashes
On Mon, 21 May 2018 09:13:15 -0700, b...@abrij.org wrote: > Note if we fix | to use fake infix adverbs, then we create the problem > that |(1,1),(2,2),:f :g will be 1,1,:g,(2,2),:f. ...sorry that might be OK due to the "first pair in term position"... but |(1,1),(2,2),1 :g will be 1,1,:g,(2,2),1.
[perl #127143] Different Behaviour With/Without Commas in Sub/Method Calls and slipped hashes
Without the comma, the colonpair is in infix position, which means it applies to the prefix unary | operator. So whether this should be an error or "work" depends on what we can teach the | operator to do with fake_infix adverbs it is passed. Note if we fix | to use fake infix adverbs, then we create the problem that |(1,1),(2,2),:f :g will be 1,1,:g,(2,2),:f. It might be best to teach | to throw when it is handed such things. There are several other operators that will find themselves in the same situation... especially we have other tickets about = which gets tricky due to the difference between list and scalar assignment.
[perl #130774] [BUG] Rational.REDUCE-ME has a data race
Data race is now fixed (in a post release branch): Rakudo fix: https://github.com/rakudo/rakudo/commit/6dd20588b6dfb75a121e2207df5f8c89aad3e1ef Test: https://github.com/perl6/roast/commit/1d10e9dc12
