[perl #123452] [BUG] Grammar fails unexpectedly and then succeeds when Grammar::Tracer is imported in Rakudo
TimToady_: ooc, do you agree that tracing a grammar breaks LTM matching? https://github.com/jnthn/grammar-debugger/issues/13#issuecomment-229940842 The solution, for whoever fancies implementing it, is probably to mix a role into the tracing closure that we hand back. Where said role has the methods like !NFA or whatever on it and forwards them to the underlying code-ref (That of the original rule) Since the reason for the problem is, afaict, that the closure we return instead of the method lacks the NFA OTOH, we could switch the NFA resolution to use lookup instead of find_method since it's after the original declarator Then Grammar::Tracer will just work and everyone won't have to re-solve the same problem if doing similar things. In fact that's probably the better way, and then Grammar::Tracer will Just Work again. So let's do it that way :) Then it'll freely fix other modules like Grammar::Debugger and Grammar::Profiler too I suspect. * masak adds this insight to the RT ticket jnthn: um, where would the solution reside? in Rakudo, or in Grammar::Tracer? masak: NQP
[perl #126827] [BUG] Class declaration from one module not visible if another module is loaded after it with a very similar class declaration in Rakudo
masak: if 87288285f6f398ec7cba0900312ced4b580d79ed is to blame, it may just be an older precompilation issue that surfaced because we precompile everything that's too slow to run away now... masak: to find that out, it would help if you could test with a version before 3b943782768260d4422933f4e2e71be40429c570 with manual precompilation how do I do manual precompilation? masak: perl6 --target=mbc --output Foo.moarvm Foo.pm nine: do I need to put the Foo.moarvm anywhere in particular for it to be picked up? masak: the old implementation just looked alongside the .pm6 file ... good news! it works on the commit before, with manual precompilation \o/ so it's *not* an ancient error surfacing only now good! which means I should keep investigating 8728828... masak: why is that good news? Now I have to fix it ;) nine: hm. I may have spoken too soon. nine: I just went one commit back, not to before 3b943782 nine: trying from that one. nine: ok, now it's conclusive. building off 3b943782^, with modules precompiled, everything works fine. * masak adds this to the ticket
[perl #126827] [BUG] Class declaration from one module not visible if another module is loaded after it with a very similar class declaration in Rakudo
masak: I still doubt it's actually 8728828 that's to blame. Between 3b943782 and 8728828 there's a lot of refactoring, especially some changes touching the handling of global merging. Might be a good idea to bisect that (with manual precompilation in every step) nine: will do. [...] nine: the results are in. a bisect of 3b943782^..87288285f, with precompilation at every step, turned up 87288285f as the first bad commit.
[perl #125595] [LHF] LTA error message with malformed loops
alex ():
Code:
loop (my $i = 0; $i = 5; $i++;) { say }
Result:
===SORRY!=== Error while compiling ./test.pl
Missing block
at ./test.pl:2
-- loop (my $i = 0; $i = 5; $i++⏏;) { say }
Interesting failure mode.
That semicolon looks unnecessary but harmless to me. (It's of the
statement-ending kind, not the statement-separating kind that Perl usually
uses.) I wonder if it couldn't be possible to parse it correctly, but warn
about useless semicolon.
As a further data point, Perl 5 also parsefails on the corresponding code:
$ perl -Mstrict -wE'for (my $i = 0; $i 10; $i++;) { say $i }'
syntax error at -e line 1, near ++;
Execution of -e aborted due to compilation errors.
[perl #109322] [BUG] Lexical weirdness from blocks inside re-entrant subs in Rakudo
A bit late to the game, but...
masak here's a shorter version:
masak m: my $y = 1; sub foo($x) { $y-- foo(z); { say $x } }; foo(x)
camelia rakudo-moar d179b4: OUTPUT«zz»
masak again, should say zx
* masak adds the example to RT #109322
[perl #125289] [BUG] Array with pair written with the value implicitly True, [:a], won't evaluate (or .perl) properly in Rakudo
Fixed (37e2c9), spectested (c2effba). Resolving ticket.
[perl #125242] .perl method fails on hashes with type-constrained keys
lizmat () This appears fixed with 869306336fadd85320bfc1 Resolving ticket.
[perl #62086] ~ in regexes shouldn't cause thrown exceptions
On Mon May 11 05:26:45 2015, pmichaud wrote: After discussion with jnthn at OSDC.no, here's what we propose: In the regex engine, the default FAILGOAL behavior should be to simply fail/backtrack. This would be the default behavior for (rakudo) Cursor as well. Grammars that wish to have the generate-an-exception behavior can override FAILGOAL to do so. The HLL::Grammar class (in NQP) will do this, meaning that Rakudo's grammar will still inherit/retain the throw-an-exception behavior. Part of our reasoning (which may be faulty) for this approach is that it's relatively easy to override FAILGOAL in a grammar but harder to do so for regexes that aren't in a grammar. In the latter case (regex), it's more likely that you want simple backtracking rather than the throw an error message, so that should be the default. This sounds very sane. +1
[perl #125101] Newline before = breaking parse
labster (): It sounds like this is intentional behavior. Indeed. Rejecting ticket.
[perl #116370] [BUG] a macro with $_ as an argument doesn't work in a statement_mod 'for' loop in Rakudo
bartolin (): But back in 2013 the output was «456». I'd say «456» is the correct output. There's nothing to suggest to me that it should get stuck on 4. So either this ticket should be closed (because the original problem is now gone) and another one opened with the new problem, or this one should be renamed and re-purposed.
[perl #124317] Possible type signature bug
masak I should probably start by looking at the RT queue masak notably #124321 jnthn Calling .^make_pun is surely wrong jnthn It'll create one every time jnthn .^inheritalize gets the pun jnthn Though maybe we should have a .^pun that does similar, and make inheritalize delegate to it. masak ok, so that was easy. the problem is in... NativeCall, then? FROGGS yes * masak adds this to the ticket * masak tries to reproduce the original problem, and also to make it go away with .^inheritalize masak ...yep, and yep. masak - typed.^make_pun; masak + typed.^inheritalize; masak fixes it. vendethiel .oO( he's taking away our puns! ) masak vendethiel: but note in the backlog that there's the possibility of adding a .^pun meta-method
[perl #124317] Possible type signature bug
Fixed and tested as of 1c916bc. Resolving ticket.
[perl #117853] [BUG] can't assign here documents to constants
jnthn masak: I think https://rt.perl.org/Ticket/Display.html?id=117853 can get a test (if there isnt' already one) and be closed now? masak jnthn: yep. was gonna add that to the ticket. * masak adds it now
[perl #124191] [BUG] For loop fails to CATCH exception on 208th iteration in Rakudo
masak ():
masak Tux says something recent caused the above failure. I'd really
appreciate it if someone wanted bisect (maybe a month back or so).
I did a bisect, which revealed a number of things. All of the findings below
can be reproduced by the following commands:
$ git clone g...@github.com:rakudo/rakudo
$ cd rakudo
$ git checkout SHA-1 to check out
$ perl Configure.pl --gen-moar --gen-nqp --backends=moar
$ make
$ make install
$ install/bin/perl6 -e 'my $dots = 0; class C is Exception { method message
{ $dots } }; for ^20_000 { { die C.new; CATCH { default {} } }; print .;
$dots++ }'
First off, here's the offending commit. Its parent runs all the way
undisturbed, but this commit dies after 28 iterations:
commit a398910b4a6a1bdd42cd5a3cc33d8dfad0e3501f
Author: jnthn jn...@jnthn.net
Date: Thu Jul 31 00:32:56 2014 +0200
Better handling of sink.
On MoarVM, this leads to a smaller QAST trees and much better code
generation. On JVM and Parrot, we get the first advantage, and we
could improve their code-gen in the future too. Note the Parrot bit
of this is untested due to being unable to build NQP Parrot on Win32
at present; the JVM patch worked right off, though, and there's very
little reason fro the Parrot one not to. Testing welcome.
src/Perl6/Actions.nqp | 29 ++---
src/vm/jvm/Perl6/Ops.nqp| 27 +++
src/vm/moar/Perl6/Ops.nqp | 38 ++
src/vm/parrot/Perl6/Ops.nqp | 27 +++
4 files changed, 94 insertions(+), 27 deletions(-)
What's interesting is that the commit is not an NQP/Moar bump, it's just the
addition of a new op. So chances are the commit uncovered an error that was
already present.
I tried reverting this commit on Rakudo HEAD (c86f75), and the resulting commit
doesn't have the bug. I pushed the result to the branch 'revert-bho-sink' on
Github, in case someone wants to merge this into 'nom'. (Which is my
recommendation.) I haven't spectested the new commit.
Next up, the following commit changes the number of iterations from 28 to 32:
commit a1a236067b805961e742e1b51fa2ffbc274f90c4
Author: jnthn jn...@jnthn.net
Date: Sat Aug 2 01:29:16 2014 +0200
Get latest NQP and MoarVM improvements.
tools/build/NQP_REVISION | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
This commit pulls in the following NQP commits (reverse chronological order):
183e611 Use new MoarVM static block lexicals support.
9268ba7 Bump to latest MoarVM, with many improvements.
c3f29b6 Bring test in line with behavior change.
aa8a615 Small optimizations to .symbol.
And that 9267ba7 bump commit pulls in the following Moar commits:
f25affb MAST nodes can be identified by exact type.
e64c5eb Read in static lexicals.
c0984eb Write static lex values; read but don't apply them
ac33547 Update MAST::Frame to hold static lex values.
9ba5d15 No longer need to support Parrot cross-compiler.
c65b2a6 Spec static lexical values table in bytecode.
cdda218 Switch on lazy frame deserialization.
0098c0c Preparations for lazy frame deserialization.
0043778 Split out part of frame deserialization.
985cd8b Bump minimum bytecode version to 2.
49f19ca Tweak spesh log run count.
8df127a Merge remote-tracking branch 'origin/split_get_use_facts'
b57061e Ensure OSR-triggered optimize is used next invoke.
f55e682 De-virtualize serialization write functions.
6da5b90 De-virtualize read_var_int.
9a3a96d Bump minimum serialization format version.
e92aa36 De-virtualize most reader functions.
b6a9cad Fix an uninitialized variable bug.
be8cfdf fix teh build
9d377a3 split get_facts and use_facts from get_and_use_facts.
Beyond noting that there are several spesh-related changes in there, I don't
find anything particular in that list that stands out as a suspect.
Later on, another bump commit changes the number of iterations from 32 to 207:
commit dd131050268bc63044868689df487fcc47e841de
Author: jnthn jn...@jnthn.net
Date: Thu Mar 26 22:59:35 2015 +0100
Bump NQP_REVISION to get latest MoarVM.
This brings both lazy deserialization and tuning of the spesh/JIT
thresholds, both improving startup time.
The commit pulls in only one NQP commit, which in turn pulls in these Moar
commits:
a752064 Bump OSR theshold also.
e2e908b Tweak dynamic optimization thresholds.
b5d57ae mark existspos as pure
5ef6456 Merge pull request #192 from fperrad/ar
bba0d8c Configure: add an option --ar
375f647 Merge pull request #191 from fperrad/patch-2
7955cee fix for ARMv5
01be8e3 First steps to handling bit-packed arrays.
74c1982 Fix a possible buffer-overrun in existspos.
0c95c4b Add type codes for bit-packed array sizes.
aa450df Re-enable lazy deserialization.
b26111b fix thinko
a938e5d Add a README explaining how to macport
cc1dc8b more macport updates;
226db54 Whoops. use checksums from correct version!
6d8f3f1 updates for new release.
This one is
[perl #124191] [BUG] For loop fails to CATCH exception on 208th iteration in Rakudo
masak so, I just removed
https://github.com/rakudo/rakudo/blob/nom/src/vm/moar/Perl6/Ops.nqp#L460
locally; RT #124191 is still present afterwards :/
synopsebot Link: https://rt.perl.org/rt3//Public/Bug/Display.html?id=124191
masak so it's something deeper, then.
dalek rakudo/nom: ee7a375 | jnthn++ | src/vm/moar/Perl6/Ops.nqp:
dalek rakudo/nom: Remove dupe register free; masak++.
dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/ee7a3752d9
masak oh, jnthn++ beat me to it.
masak was still spectesting.
masak jnthn: RT #124191 is still at large, even after that remove.
masak jnthn: so there is *something* wrong with that code.
jnthn masak: That may fix *something*, but given the generated code works
before dynamic optimization kicks in, it's fairly clear we're looking for a
problem there.
masak jnthn: if you can't see it immediately, I'd recommend rolling back the
original commit that created that op.
jnthn masak: Nope, wrong approach.
masak if you say so.
masak we have a bug in the nom branch right now, and a way to make it go away
until we learn what's going on.
jnthn masak: It's pretty obvious from what we know that the commit in
question generates valid code.
masak jnthn: ah, so you're saying we should look at how it's
optimized/speshed instead?
masak I agree with that, I just don't see why we wouldn't remove the source
of the bug in the meantime. creating a more stable nom branch.
jnthn masak: Yes; presumably setting MVM_SPESH_DISABLE=1 makes it go away
* masak tries
masak jnthn: yes, setting MVM_SPESH_DISABLE=1 makes it go away.
jnthn masak: Right, so that narrows down where we're looking quite
significantly.
masak jnthn: not gonna argue with you about reverting the commit -- if you
prefer that it stay, it stays. but how do we find the optimize/spesh bug?
jnthn masak: Well, looking at the spesh log for one
jnthn masak: Though we might try disabling other bits to narrow it further
masak jnthn: I don't have the skills to do that at present. hoping that
someone else finds the tuits to do that.
jnthn masak: There's more env vars
jnthn masak: If you moar --help they're there
jnthn masak: Seems that they do help too...
jnthn masak: Setting MVM_SPESH_INLINE_DISABLE=1 also makes it go away
jnthn masak: Meaning that we can blame it on inlining busting...something.
jnthn masak: Further, you don't need a custom exception type for it
masak wow.
masak so I could've golfed it further?
masak fancy that :)
jnthn masak: Yeah, Exception.new
masak m: for ^207 { die Exception.new(); CATCH { default {} } }
camelia rakudo-moar d24f30: ( no output )
masak m: for ^208 { die Exception.new(); CATCH { default {} } }
camelia rakudo-moar d24f30: OUTPUT« in block at /tmp/ZLP2WH1C3n:1»
masak jnthn++
jnthn masak: I've a feeling it is a much more general issue.
* masak adds the conversation so far to the ticket
[perl #124190] [BUG] Promise::Vow can be constructed from the outside to change the status of a Promise in Rakudo
Fixed in fb991b and spectested in 4f7877. Resolving ticket.
[perl #116212] [BUG] 'Hash of Hash' line causes REPL to segfault in Rakudo
On Sat Jan 24 13:52:59 2015, barto...@gmx.de wrote:
As a status update: I don't get a segfault in the REPL with a current
rakudo (tested on moar, parrot and jvm).
The error message has changed slightly:
More exactly, the segfault is now gone.
masak m: class Foo { has Hash of Hash $.foo = {} }; Foo.new
camelia rakudo-moar 6e182d: OUTPUT«Type check failed in assignment to
'$!foo'; expected 'Hash[Hash]' but got 'Hash' [...]
* masak resolves #116212
[perl #102652] [BUG] Rakudo recommends a different syntax for do...for loops and then that syntax doesn't work
bri (): So this might be a closeable ticket now? Yes, I would say so. Good work. Resolving.
[perl #62086] ~ in regexes shouldn't cause thrown exceptions
masak as an author of grammars, I still find it annoying and difficult that
grammars generally fail, that is, return a failing match -- *unless* you use
the `~` combinator, in which case they nqp::die with an exception that can't be
properly caught using a CATCH.
masak in effect, that gives grammars three possible outcomes: success,
failure, or death-because-of-failgoal.
masak oh, I've kvetched about that before, it seems:
https://rt.perl.org/Ticket/Display.html?id=62086
jnthn masak: Why can't it be caught with a CATCH?
jnthn masak: Also, you're free to override FAILGOAL...
masak I don't rightly know why it can't be. I'm having trouble reproducing
the error in golfed code.
masak m: grammar G { regex TOP { a ~ c foo }; regex foo { b } }; say
?G.parse(abbc); CATCH { when X::AdHoc { say caught } }
camelia rakudo-moar 20aa85: OUTPUT«caught»
masak ok, here I *could* catch it. weird.
jnthn In all the cases we use it for in the Perl 6 grammar, it'd be useless
if it didn't throw, fwiw.
* masak adds that to the ticket
jnthn Of course, I guess we could have a default FAILGOAL that just fails and
override it with one that throws.
masak if all outcomes of a grammar return a failed Match object *except* for
FAILGOAL, then I'd like there to be a good theoretical explanation for FAILGOAL
behaving differently.
masak and not just we need to convey an error message here, so throwing an
exception feels right
jnthn panic is another example
masak categorically, it's still just a failed match. it feels like with the
current setup, we're committing a category error.
masak or rather, what precise thing is it that makes a parse failure so
severe that it promotes from falsy to die?
masak right now, from what I can see, the need to attach an error message.
jnthn That, and also wanting to give up at that point because there's no sane
way to proceed and you'd never want something further up to try another path.
masak oh, right. control flow.
masak still, a use case I mention in earlier parts of that ticket is I just
want to parse something in order to find out whether it's valid or not. having
to deal with three-valued logic in that case is just... cruft.
jnthn Then don't use ~
masak I suppose.
[perl #123581] Infinite lists match [] signature
jnthn m: (1..*).Capture.perl.say
camelia rakudo-moar 6a3fc3: OUTPUT«Capture.new(hash = {excludes-max =
Bool::False, excludes-min = Bool::False, min = 1, max = Inf})»
jnthn ah
jnthn m: (my @a = 1..*).Capture.perl.say
camelia rakudo-moar 6a3fc3: OUTPUT«Capture.new()»
jnthn That's a golf.
* masak adds that to the ticket
jnthn I think the conservative thing to do is to refuse to coerce an infinite
thing to a Capture.
jnthn That lets us revisit/liberalize in the future
[perl #123452] [BUG] Grammar fails unexpectedly and then succeeds when Grammar::Tracer is imported in Rakudo
TimToady masak: no, it makes the grammar behave wrong, it turns out
TimToady in parsing B\n, it matches the right side of x under LTM, and eats
the newline that TOP needs to progress, so the next match fails to progress
because $$ doesn't match
TimToady put a {} before the second \s* and it matches, because then it ties
under LTM and works left-to-right instead
TimToady or change the 2nd \s* to a \h* and it works
TimToady so this turns out to be a bug in the tracer, I think
TimToady unless TOP should be backtracking to the left side of x, hmm
TimToady maybe it's a not-backtracking-into-subrule bug as well
TimToady I guess the token declarator for x is committing the match of the
LTM in the alternation
TimToady if you change it to 'regex', it parses
TimToady so arguably that's correct behavior in rejecting the parse under
'token'
TimToady anything that subverts LTM would tend to make it do || semantics, so
I'm guessing the tracer is subverting LTM somehow; does it work by inserting {}
nodes?
TimToady if so, we need to teach LTM to ignore those nodes
TimToady or insert 'em as !{stuff; 0} instead, which LTM already ignores
* TimToady delegates the problem to anyone who will delegate it to someone else
who is not TimToady :)
TimToady masak: another way to fix your proggie is to change your [';' | $$]
to match [';' | $$ | ^^] instead
TimToady but anyway, the bug report is at least partly right... .oO(It is
a comfort not to be mistaken on all points. --Gandalf)
masak TimToady: I added your comments to
https://rt.perl.org/Ticket/Display.html?id=123452
[perl #123452] [BUG] Grammar fails unexpectedly and then succeeds when Grammar::Tracer is imported in Rakudo
masak I need to digest those comments, though. I don't understand where the
grammar eats the newline that TOP needs to progress.
masak and, oh yes, I also noticed that changing 'token x' to 'regex x' made
the bug go away. that's one thing I failed to include.
masak ...but anyway. even not following all the details, I know it's wrong
that Grammar::Tracer heisenbugs the parse. :)
masak if it turns out the problem is *all* in Grammar::Tracer, I'll happily
re-file this as a Github issue.
TimToady masak: the x rule matches a token of B\n and commits to that, but
it must match only 'B' to allow the newline to match in TOP
TimToady it commits to B\n because that's the longesst token
masak why would the x rule ever match a \n after the B?
TimToady and it matches that because everything at the end is optional,
including the ()
TimToady \s*
TimToady that's why changing \s* to \h* makes it work
masak oh, it goes into the *right* alternation...
masak I see.
TimToady or changing '()'* to '()'+
masak right.
TimToady or putting {} before the \s*
masak the ungolfed grammar is 108 lines. but you just provided some clues for
how to fix it. thanks. :)
moritz whitespace. Still not a solved problem.
jnthn masak: I highly suspect Grammar::Tracer is doing something wrong. Note
that when it was written, LTM was...rathre less advanced...than it is now.
masak yes, I think it's been established now that the problem is purely in
Grammar::Tracer.
jnthn OK
jnthn Then feel free to file a tikkit.
* masak does
Rejecting this ticket, as the problem seems to be entirely in Grammar::Tracer,
not in Rakudo.
See https://github.com/jnthn/grammar-debugger/issues/13 for the ticket opened
in Grammar::Tracer.
[perl #123116] [BUG] Weird error for code parameters with subsignatures in Rakudo
masak (): I am not 100% sure the `block (Dog -- Bool)` form should work, or is by spec. The `block:(Dog -- Bool)` form comes from S06:1675. TimToady at one point we required a : because of the ambiguity with sublists of parameters, but we already have a whitespace dep with @foo[3,3] vs @foo [$x,$y,$z], so having one for () is probably not terrible * masak adds TimToady's comment to the ticket
[perl #123060] [BUG] `$++` statements in routines sometimes give the anonymous variable `my` scoping, sometimes `state` scoping in Rakudo
TimToady as for $ = 'A', currently that's equivalent to (state $) = 'A', since the $ doesn't actually parse as a declarator, but is promoted to a declaration in the actions TimToady maybe we can fix that somehow TimToady could also argue that it should be restricted to integers * TimToady loves to argue so much that he often ends up arguing both sides. :) * TimToady would've made a bad lawyer... :)
[perl #122983] [BUG] spurt busted in Rakudo
Ah, yes. Rebuilding enough things, it works now. FROGGS (): I almost want to tag the bug as invalid :o) Done.
[perl #118067] [BUG] Null PMC access when calling .new on a subclass with a proto overriding the regular .new in Rakudo
On Thu Oct 16 00:10:27 2014, barto...@gmx.de wrote:
Just an update: There is no longer a Null PMC access error, but Rakudo
complains about no matching signature:
$ perl6-m -e 'class A is Any { proto method new($) {*} }; A.new(now)'
Cannot call 'new'; none of these signatures match:
in block unit at -e:1
$ perl6-p -e 'class A is Any { proto method new($) {*} }; A.new(now)'
Cannot call 'new'; none of these signatures match:
in any at gen/parrot/BOOTSTRAP.nqp:1223
in method new at -e:1
in block unit at -e:1
$ perl6-j -e 'class A is Any { proto method new($) {*} }; A.new(now)'
Cannot call 'new'; none of these signatures match:
in any at gen/jvm/BOOTSTRAP.nqp:1216
in block unit at -e:1
First off, resolving ticket because the Null PMC access is gone, and that's
what was reported.
Secondly, I think the above behavior is right. The error message comes from
correctly finding and dispatching on the declared proto, and then correctly
complaining that no declared multi (of which, as it happens, there are none)
matches.
[perl #118581] [BUG] Segfault for a signature match with a native type and an 'as' cast in Rakudo
Resolving this ticket because Rakudo no longer segfaults. See [perl #122990] for the unexpected behavior it revealed underneath.
[perl #99658] sequence operator '...' timeout
bartolin ():
Actually I don't think S03 says that '1,3,5 ... 8' should act as
'1,3,5 ... *'
As I understand it '1,3,5 ... 8' gives an infinite list with all even
numbers. '1,3,5 ... *' also gives an infinite list with all even
numbers -- but this one is lazy.
So there is a difference in behaviour: When assigning to an array with
'my @odd = 1,3,5 ... 8;' all elements of the sequence have to be
computed and smart matched agains '8'. This match never results in
True and therefore we get a timeout, finally. In the other case ('my
@odd = 1,3,5 ... *') the sequence has no limit (quote from S03) and
the assignment can be lazy e.g. the values don't have to be computed
and smart matched against something.
I think this reasoning is sound, and whereas it would be awesome if we could
always read the mind of the user and not get stuck in infinite loops trying to
compute infinite sequences -- the place we are is kind of a local minimum and
has an internal consistency.
That is, we could perhaps do better in the future, and not hang on this one.
But it's not clear to me how to do that without making the current model more
complex for relatively little gain.
Rejecting ticket.
[perl #117773] [BUG] KeyBag accepts non-UInt values in Rakudo
bartolin (): That looks reasonable to me. Is the ticket closable with tests? Yes, I think so.
[perl #122983] [BUG] spurt busted in Rakudo
masak I found the error message that spurt emits. it's in Moar. https://github.com/MoarVM/MoarVM/blob/256554b8a23cb226e374b4dd57e8af668d2654c1/src/io/syncfile.c#L89 masak FROGGS++ has since made that error not happen: https://github.com/MoarVM/MoarVM/commit/03ac9a70f6dee026ab264767a59ab76379049bee masak so it's possible that the simplest way to unbreak spurt would be to make Rakudo depend on a newer Moar.
[perl #113988] [BUG] Null PMC access when doing .fmt on the return value from .reals
Christian (): So maybe instead of closing this ticket we should change the subject of this ticket to 'LTA error message when .sprintf is called with more directives than arguments (numeric)'? No need to keep it open for that, methinks. There's already https://rt.perl.org/Ticket/Display.html?id=122907 ([BUG] LTA error when sprintf %d directive doesn't find a corresponding argument in Rakudo) to cover that case. Resolving ticket.
[perl #116016] [BUG] The rule to match routines/symbols is overriding the rule to match versions, because of LTM
pmichaud std: say v2013.4.5
camelia std fc92e1e: OUTPUT«===SORRY!===Confused at /tmp/W0MHCqFo4M line
1:-- say v2013.⏏4.5 [...]
pmichaud aha
lizmat :-)
pmichaud looks like STD and Rakudo agree here about multi-digit version
numbers
masak I recognize this failure mode.
masak we've encountered it before
pmichaud it's a longest-token-matching issue
masak (not just earlier today)
masak I bet there is an RT ticket with it somewhere
* masak goes hunting for it
pmichaud I suspect that v123.10 ends up with v123 as identifier over
'v1'
masak *nod*
pmichaud because the grammar rule is
pmichaud token version:symv {
pmichaud 'v' ?before \d :: vnum +% '.' '+'?
pmichaud }
pmichaud which means LTM stops at the ::
masak https://rt.perl.org/Ticket/Display.html?id=116016
masak is that one related?
masak it's from 2012
pmichaud yes, it looks exactly the same
* masak merges the two tickets
pmichaud I wonder why we need the ?before \d :: part
pmichaud well, ?before \d is guarding against v*.3.4 as a version
identifier
pmichaud I wonder what happens if we get rid of the '::'
FROGGS and the :: commits to that token, no?
FROGGS so it won't try other rules, at least in theory
pmichaud no
pmichaud :: commits to an alternation
[perl #122904] a wrong regex in UsingPerl6-draft.pdf
On Sat Oct 04 06:09:57 2014, songwen...@linuxdeepin.com wrote: Page 99 If you quantify a capture, the corresponding entry in the match object is a list of other match objects: right regex is m/(\w+)+ % [\,\s*] \s* 'and' \s* (\w+)/ Fixed, thanks! https://github.com/perl6/book/commit/0f87d071038243fe8225d9281b2e301dff79a021 Resolving ticket.
[perl #85750] Test failures on OpenBSD
bartolin masak: S03-operators/arith.t mentions http://mathworld.wolfram.com/Indeterminate.html, as I understand it this argues in favour of 1 ** Inf == NaN masak bartolin: sure, I'm already concinced that *math* makes the argument for 1 ** Inf == NaN. masak but IEEE 754 deviates from math in some places where it finds doing so convenient in a computing environment. masak for example, 0 ** 0 masak m: say 0 ** 0 camelia rakudo-moar d60a8f: OUTPUT«1» masak m: say Inf ** 0 camelia rakudo-moar d60a8f: OUTPUT«1» bartolin ok, just wanted to note the link masak bartolin: yes -- thank you. masak bartolin: adding to ticket.
[perl #122746] [BUG] Stringification of AST parameter not captured properly in postfix macro in Rakudo
masak ():
masak m: macro postfix:!!($o) { quasi { die Null check failed for
, $o.Str unless defined {{{$o}}}; {{{$o}}} } }; say 42!!; my
$cookies; my $food = $cookies!!
16:18 +camelia rakudo-moar 51ddd5: OUTPUT«42Null check failed for 
in any [...]»
masak so close.
* masak submits rakudobug
masak (it should capture the string '$cookies' in $o.Str, IMO)
masak that is, the error message shoulda been 'Null check failed for
$cookies'
This works now, thanks for moritz++.
$ cat RT-122746-code
macro postfix:!!($o) {
quasi {
die Null check failed for , $o.Str
unless defined {{{$o}}};
{{{$o}}}
}
}
say 42!!;
my $cookies;
my $food = $cookies!!
masak@siddharta ~/mine/macro-grant $ perl6 RT-122746-code
42
Null check failed for $cookies
in any at RT-122746-code:3
in block unit at RT-122746-code:12
Marking ticket as testneeded.
[perl #122882] [BUG] Symmetric set difference (^) doesn't right-associate or chain in Rakudo
lizmat $ 6 'say a network (^) b network (^) a network' lizmat set(b) lizmat #122882 can be marked as TEST NEEDED :-) Marked as testneeded.
[perl #122882] [BUG] Symmetric set difference (^) doesn't right-associate or chain in Rakudo
pmichaud see my response to RT #122882 :) pmichaud mainly, infix:(^) should list associate pmichaud imo, jet plane (^) network lag (^) plane network should result in jet lag pmichaud more to the point, a network (^) b network (^) a network should result in b and not b network, which is hard to do if (^) is left-assoc masak pmichaud: I agree. that rhymes with infix:^^ semantics, too. pmichaud exactly. masak pmichaud++ pmichaud anyway, the problem is the way infix:(^) is implemented in src/core/set_operators.pm
[perl #85750] Test failures on OpenBSD
masak p6: say 1 ** Inf # [RT #85750]
camelia niecza: OUTPUT«Cannot open assembly './run/Niecza.exe': No such file
or directory.»
camelia ..rakudo-jvm d60a8f: OUTPUT«Can't call method syswrite on an
undefined value at /home/p6eval/jvm-rakudo/eval-client.pl line 32.»
camelia ..rakudo-{parrot,moar} d60a8f: OUTPUT«1»
masak the RT ticket says there are tests expecting this to be 1, but it's NaN
on some systems.
masak I was curious to find out what IEEE 754 stands on the matter.
masak haven't found out yet.
masak my *expectations* of these regions of arithmetic, of the concepts
1/Inf/NaN, and of IEEE 754, though, tell me that either 1 or NaN are acceptable
answers, but I don't know which. I'm pretty sure IEEE 754 has an opinion, and
unless there's a really good reason to deviate, we shouldn't.
masak it's easy to argue for either:
masak (it should be 1) -- because 1 ** $anything is 1
masak (it should be NaN) -- because there's an inherent conflict between 1 **
$anything being 1 and $at_least_1 ** Inf being Inf, and so rather than resolve
that, the sysstem has to give NaN.
masak this could be more formally argued using limits, but my hand-wavy
argument shows the way, approximately.
masak fwiw, Python (both 2 and 3) has 1 ** Inf as 1.
https://gist.github.com/masak/675fbe68a6474a94b722
masak it doesn't have a reified symbol for Inf, hence the workaround with
1e3000.
masak http://steve.hollasch.net/cgindex/coding/ieeefloat.html lists a number
of Special operations, which is something like I was looking for. pow(1, Inf)
-- or anything involving pow -- is notably absent.
masak ditto http://users.tkk.fi/jhi/infnan.html
[perl #122679] White space breaks feed syntax == with grep and map - bogus statement
Kevin ():
I was playing with Game::Crypt
\o/
and ran into the following problem.
Compile crashes with a Bogus statement error. It seems that the
insertion of a newline breaks the compile. I don't think this is perlsh
behaviour!
The following code reproduces it:
use v6;
sub foo($bar) {
$bar
== grep { / Cat / } == map { substr(1) } # compiles
}
sub baz($bar) {
$bar
== grep { / Cat / }
== map { substr(1) } # does not compile
}
This is expected behavior -- the '}' after '/ Cat /' ends the statement, by
S04's =head1 Statement-ending blocks.
I agree that many people will fall into this trap -- and that this is one of
the very few cases when the rule seems to work against users' expectations --
but inserting a special case that makes this an exception to the S04 rule would
set a bad precedent and break one-pass parsing. *Maaaybe* it'd be a good idea
to have a prefix: == detect this case and tell people what to do.
For people who do want that code layout, unspace at the end of the line (`grep
{ / Cat / } \`) makes it work, as the `}` is now no longer last on the line.
Rejecting ticket.
[perl #122654] [BUG] Operator starting with a bang (!) and having a Unicode character in it not recognized by Rakudo
Heh; just in case someone takes a close look at that error message and is
terribly confused... here's the correctly pasted one:
masak m: multi infix:«≃» { $^l lt $^r }; multi infix:«!≃» { not($^l ≃ $^r) };
say foo !≃ bar
camelia rakudo-moar d8c834: OUTPUT«===SORRY!=== Error while compiling
/tmp/weCLGmom3MCannot negate ≃ because it is not iffy enoughat
/tmp/weCLGmom3M:1-- ix:«!≃» { not($^l ≃ $^r) }; say foo !≃⏏ bar»
That's better. Nothing to see here, move along.
[perl #77334] [BUG] For loops don't decontainerize in Rakudo, and maybe they should
[Coke] rant: old tickets with maybe or either std or rakudo is wrong
masak [Coke]: if I'm to blame for either std or rakudo is wrong tickets,
send them to me and I'll take action on them.
masak I'm pretty sure I don't file maybe tickets :)
[Coke] masak: RT #77334
synopsebot Link: https://rt.perl.org/rt3//Public/Bug/Display.html?id=77334
* masak looks
[Coke] that maybe ticket is from 4 years ago.
masak oh, we talked about that one the other day.
masak the question we should ask on that one is what use case are we making
impossible by having `for` loops decontainerize?
masak actually, two more questions.
masak which way is least surprize? (pretty sure it's doing the decont)
masak which way shoots us in the fewest amount of feet wrt performance?
(pretty sure it's the decont)
masak in other words, if we can't think of a use case for Q1, then there's no
maybe there.
masak [Coke]: good enough? :)
* masak adds this to the ticket
[Coke] please update the subject to indicate the choice.
masak [Coke]: well, we haven't quite failed to think of a use case yet...
[Coke] so it is still a maybe? arglebargle.
masak m: sub foo { my $s; (+($s += $_) for 1..3) }; say foo() # [Coke]:
here's the result if we decont.
camelia rakudo-moar 9a6644: OUTPUT«1 3 6»
masak [Coke]: do you agree that it's a less surprising result?
[Coke] masak: surprising or no, I want tickets of the form this code
generates result A when it should generate result B. not we're not sure
what's the right answer here...
[Coke] because that kind of ticket stays open for 4 years.
masak *nod*
masak ok, I'll remove the maybe, simply because I haven't seen and can't
think of a use case that's more important than not letting [Coke] down.
masak anyone from the future who knows of such a use case, take note: I
consider uprooting my decision to be valid to the extent there's a use case to
motivate it.
masak that may include but is not limited to someone who tries to implement
this and notices that the correct implementation fails some (hard to dispute)
previously passing spectest.
[perl #77334] [BUG] For loops fail to decontainerize in Rakudo
masak n: sub foo { my $s = 0; ($s += $_ for 1..3) }; say foo()
camelia niecza v24-109-g48a8de3: OUTPUT«1 3 6»
masak this is a data point, too. Niecza decontainerizes.
[perl #83622] [BUG] Rakudo says NaN === NaN is False
masak (), coke (): TimToady rakudo: say NaN === NaN p6eval rakudo a37640: OUTPUT«Bool::False» TimToady that one could be true, since it's asking a non-numeric question [...] Fixed in a82c407. I just want to add, for completion, that discussion on #perl6 mentioned that there are different not-a-number values. Presumably NaN is only one of these, and it's possible through some computation paths to get other not-a-number values that aren't triple-equal to NaN. *Or* Perl 6 complete hides this difference and calls *all* not-a-number values NaN, so that NaN is actually a kind of representative for all not-a-number values, and if you want to be more specific than that, you have to create your own values and give them the appropriate behavior. Ticket is still resolved, but the above considerations may be of interest for someone who revisits this issue in the future.
[perl #65172] .ord() does not work on graphemes
lelf Is \w defined as alnum on purpose? moritz yes lelf It is not in perl5 moritz no? lelf With the very good reason that it matches combining chars for example lelf m: say 'xyz̧p' ~~ /\w+/ camelia rakudo-moar 4cad54: OUTPUT«｢xyz｣» moritz those are meant to be deal with at grapheme level in p6 jnthn Right; that's a lack of NFG... masak oh, so the above's a bug? jnthn masak: Well, it's an NFG is NYI... masak do we have NFG is NYI in RT? moritz masak: we have masak moritz: thank you. jnthn If not, we should have one, but I suspect we do... jnthn And I'd include this as an example in it. * masak gets on it jnthn So we have that ticket a source to mine for test cases :)
[perl #122011] FIRST and LAST behave inconsistently (and annoyingly)
Commit 1bb76a6 in roast adds a test (in S04-phasers/in-loop.t) for the expectation expressed in this ticket: that LAST not fire if the loop doesn't have iterations.
[perl #121909] [LHF] Numeric shift + misbehaving on parrot - Dates broken
masak p: my $d = Date.new(:year(2012), :day(1), :month(12)); say ++$d camelia rakudo-parrot 166bf3: OUTPUT«2012-12-02» masak seems https://rt.perl.org/Public/Bug/Display.html?id=121909 is fixed? gtodd masak: https://rt.perl.org/Public/Bug/Display.html?id=121909 doesn't error for me * masak resolves ticket
[perl #121249] [BUG] Configure.pl not giving enough hints about what options to use when building with MoarVM as the backend
dalek nqp: 1658541 | jnthn++ | Configure.pl: dalek nqp: Give a hint about --gen-moar when no moar is found dalek nqp: review: https://github.com/perl6/nqp/commit/16585410c9 jnthn masak: Hopefully 1658541 helps a little masak jnthn++ masak ok, resolving the rakudobug.
[perl #121147] The last bug
masak [Coke] masak: if none of them have RT #121147 right, what's the right way to have it? masak [Coke]: sorry, left that out. masak [Coke]: Here\n masak [Coke]: with the rationale that FIRST runs before any iteration, the say gets printed, and then 'last' quits the loop. masak [Coke]: rakudo-moar seems to entirely ignore the FIRST. rakudo-parrot and rakudo-jvm run the FIRST, but ignore the 'last'. * masak adds this to the ticket
[perl #119999] [BUG] LTA internal Parrot error when doing '::{}' in Rakudo
moritz current instr.: 'variable_components' pc 26971 (src/gen/perl6- symboltable.pir:10438) (src/Perl6/World.nqp:1858) moritz if you run it with --ll-exception * masak adds that to the ticket masak moritz++
[perl #119919] LTA Error Message for operator declaration with []
lue (): The infix:[...] form of declaration should at least have a better error message. Not just that. S02, S03, S06, and S12 contain examples of this syntax. So at the upper end this should actually be allowed, not just have a better error message. Of course, arbitrary values inside the [] only make sense if they're known at compile-time (constants, for example). Care will need to be taken; tests will need to be written. On the caller side, even runtime values are fine; see S12:444 for an example.
[perl #98954] [BUG] Nested indexing semantics changed from Beijing to nom in Rakudo
On Mon Sep 12 15:04:09 2011, masak wrote:
masak b: my @a = [1], [2], [3]; say (map { @a[1 - $_][0] }, 0 ..
3).perl
p6eval b 1b7dd1: OUTPUT«(2, 1, Any, Any)»
masak nom: my @a = [1], [2], [3]; say (map { @a[1 - $_][0] }, 0 ..
3).perl
p6eval nom 08ef94: OUTPUT«(2, 1).list»
* masak submits rakudobug
tadzik here we go again
masak tadzik: this change in semantics causes connect-4 to give the
first player the win on the first move.
tadzik masak: serious business
masak tadzik: seems connect-4's winning condition relied on being
able to do negative indexing.
masak tadzik: I have no trouble believing that this isn't
spectested.
masak and I have no horse in this race. I'll gladly rewrite that
part of connect-4 if need be.
masak but until there's a verdict, it goes into RT.
masak niecza: my @a = [1], [2], [3]; say (map { @a[1 - $_][0] }, 0
.. 3).perl
p6eval niecza v9-23-g1a8efca: OUTPUT«(2, 1, Any, Any).list»
[23:52]
masak there'a another data point, I guess.
jnthn nom: my @a = [1], [2], [3]; say (map { say @a[1 - $_][0].WHAT;
@a[1 - $_][0] }, 0 .. 3).perl
p6eval nom 08ef94: OUTPUT«Int()Int()NilNil(2, 1).list»
jnthn nom: say (map { Nil }, 0 .. 3).perl
p6eval nom 08ef94: OUTPUT«().list»
jnthn masak: There's the underlying thing.
masak jnthn: I suspected that.
masak jnthn: why Nil and not Any?
jnthn masak: I can believe that's actually correct. But I'm not
quite sure if the Nil you got before is wrong.
jnthn masak: That is, it's not map's fault..but @a[1 - $_][0]
returning Nil may be wrong.
masak aye.
masak I know.
jnthn Well, so that golfs if. :)
Does the spec say that one should get Nil in this case? I was fine
with getting Any. Note also that Niecza agrees.
These days, it fails.
masak rn: my @a = [1], [2], [3]; say (map { @a[1 - $_][0] }, 0 ..
3).perl
camelia niecza v24-95-ga6d4c5f: OUTPUT«(2, 1, Any, Any).list»
camelia ..rakudo 69c3cc: OUTPUT«(2, 1, Failure.new(exception =
X::AdHoc.new(payload = Cannot use negative index -1 on Array)),
Failure.new(exception = X::AdHoc.new(payload = Cannot use negative
index -2 on Array))).list»
* masak amends RT #98954
Which is arguably more correct than silently truncating the result list.
(But still different from both Beijing and Niecza.)
[perl #111734] [BUG] Can't locally redefine True in Rakudo
masak (): Nope, not fixed: masak r: constant True = Yeah, well, you know, that's just, like, your opinion, man.; say True camelia rakudo b2072f: OUTPUT«True» * masak adds to https://rt.perl.org/rt3/Public/Bug/Display.html? id=111734 This now appears to be fixed: masak r: constant True = yeah, well, you know, that's just, like, your opinion, man; say True camelia rakudo e1f255: OUTPUT«yeah, well, you know, that's just, like, your opinion, man» masak \o/ * masak adds that to https://rt.perl.org/rt3//Public/Bug/Display.html? id=111734
[perl #114014] ord.Cool outputs LTA error
masak moritz: what error message would I have expected? the one STD gave at the end of the original message. masak Unsupported use of bare 'ord'; in Perl 6 please use .ord if you meant $_, or use an explicit invocant or argument * masak adds that to the ticket
[perl #109874] BUG: should match: grammar A { rule TOP { ^ } }; say A.parse(' ')
masak r: grammar G { token TOP { ^foo$ }; rule foo { foo } }; say ?
G.parse( foo)
camelia rakudo 96776b: OUTPUT«True»
masak r: grammar G { token TOP { ^foo$ }; rule foo {foo } }; say ?
G.parse( foo)
camelia rakudo 96776b: OUTPUT«False»
masak I thought rules ignored initial whitespace...
moritz masak: it's fascinating how rakudo still parses so well, being
built on Perl 6 rules... :-)
masak heh.
* masak does a search through RT first
masak here is some discussion in a rejected ticket:
https://rt.perl.org/rt3/Ticket/Display.html?id=75668
masak ah -- here: https://rt.perl.org/rt3/Ticket/Display.html?
id=109874
masak let's just add today's discussion to that one.
[perl #118737] [BUG] Match object loses its inner match if $rx regex inclusion syntax is used in Rakudo
TimToady the problem with /($re)/ is that the is still going to
throw away the captured material inside because it doesn't start with
alpha
jnthn oh!
TimToady r: my $re = rx {.(.).}; say 'abc' ~~ /$0=$re/
camelia rakudo ce8b5f: OUTPUT«｢abc｣ 0 = ｢abc｣ 0 = ｢b｣»
masak \o/
masak TimToady: so the rakudobug is a dud?
TimToady /($re)/ is behaving correctly
* masak marks the rakudobug 'rejected'
[perl #118601] [BUG] sprintf %d loses digits in Rakudo
nwc10 rn: say sprintf %d %d, 301281685344656640, 301281685344656669 camelia niecza v24-81-g6672fa2: OUTPUT«301281685344656640 301281685344656669» camelia ..rakudo d02067: OUTPUT«-1202938624 -1202938595» nwc10 masak: I think that your bug title for RT #118601 is incorrect, but we seem to have two related bugs here masak nwc10: oh! indeed. * masak adds this information to the ticket nwc10 that one looks like truncation to 32 bits
[perl #64928] The undefinedness of optional arguments and typed attributes in Rakudo
On Tue Apr 21 06:35:05 2009, masak wrote:
masak but... I just want a nice way to see if the hash was passed or
not.
[...]
moritz_ the problem is that we're doing in-band communication
moritz_ instead of asking the hash parameter if it was defined, we
should ask the capture if that hash was given
masak aye.
moritz_ especially since objects can respond with False to .defined
at will anyway
frettled the way you put it, it seems like there is a
straight-forward way of doing so, and that would be good.
frettled Conceptually, that's much cleaner than asking the variable.
masak lizmat: yes, for a long time I also wanted a way to introspect
the Capture.
masak lizmat: thing is, the Capture is caller-side, and when you want
to do the introspection, you're callee-side.
jnthn You already can keep a capture around if you want to look at it.
jnthn sub foo(|c, :$a, :$b) { c.exists('a') }
masak oh, troo.
masak so, there we go.
masak feature already in the language. :) case closed. :)
masak I guess we can close the RT ticket, too.
pmichaud's WHENCE solution is still not in place, but I don't see why
that should keep us from resolving the ticket.
So, resolving ticket.
[perl #111734] [BUG] Can't locally redefine True in Rakudo
On Sun Jun 09 08:00:22 2013, jn...@jnthn.net wrote: On Tue Mar 13 13:35:18 2012, masak wrote: masak nom: constant True = 42; say True p6eval rakudo fee891: OUTPUT«True» masak hm. benabik r: constant True = 42; say +True p6eval rakudo fee891: OUTPUT«1» benabik Huh * masak submits rakudobug masak good rakudobug day today ;) benabik Oh, I was thinking it was an enum not getting numified. blah. jnthn Great, not being able to change the truth is a bug :P TimToady the opposite of OUTER truth is INNER truth... :P Fixed: constant True = 42; say True Tagging testneeded. Nope, not fixed: masak r: constant True = Yeah, well, you know, that's just, like, your opinion, man.; say True camelia rakudo b2072f: OUTPUT«True» * masak adds to https://rt.perl.org/rt3/Public/Bug/Display.html? id=111734
[perl #114760] [BUG] Minus thirteen billion years ago becomes minus 115 million years ago in DateTime.new in Rakudo
masak (), coke (): masak r: say Date.new(-13_000_000_000, 1, 1) p6eval rakudo cc1858: OUTPUT«-115098112-01-01» masak o.O masak I suppose -115098112 above is a bug? masak r: say -13_000_000_000 p6eval rakudo cc1858: OUTPUT«-130» * masak submits rakudobug This seems consistent with trying to use a value that is too big for an Int (which $.year is); are you arguing that this should throw an error, that an Int $.year should autopromote to something else, or that $.year should be declared as something else? Either of those three would solve the real issue here, which (IMO) is that something different comes out than was put in. Generally, it's not nice to destroy user data without at least giving a warning that significant digits were lost. I have no opinion in which of the three methods is preferable, though. Maybe this, too, should be a spec issue.
[perl #118227] [BUG] hyper-adding does not respect hash typedness in Rakudo
Liz ():
Feels like this in essence is the same as .clone not being able to
clone a typed hash.
Yes, at least for some of the simpler cases.
After I submitted the ticket, this relevant discussion took place:
masak pmichaud: hm. question is, if I %h1 + $h2, and the hashes
are typed with different constraints, what the result ends up being.
same question for +, really.
masak (typed hashes and hyperoperators! yay, I found a new corner
case!)
pmichaud masak: yes, that's a legitimate question.
masak pmichaud: I guess the type-theoretical answer is that in one
case you'll get the join of the types, and in the other case you'll get
the meet of the types :P
pmichaud masak: I'm thinking the practical answer may be DIHWIDT for a
while :)
To make this concrete, consider this code:
class Left {}
class Right {}
class Both is Left is Right {}
my $l = Left.new;
my $r = Right.new;
my $b = Both.new;
my %l{Left} = $l = 1, $b = 1;
my %r{Right} = $r = 1, $b = 1;
say (%l + $r).elems;# 1, because intersection (S03:4377)
say (%l + $r).elems;# 3, because union
say (%l + $r){$b}; # 2. 1 from each operand
So far so good, but if the hyper-op result of a typed hash is to be a
typed hash, then what are the *types* of the + and + results
above? Again, the type-theoretical answer seems to be this:
(%l + $r) has keytype (Left Right)
(%l + $r) has keytype (Left | Right)
We've distanced ourselves from thinking in terms of junctional types
like that. But that seems to be what falls out of this. I'm not sure if
that's good or not. For example, would (Left Right) be completely
compatible with Both? I doubt it.
Wishing I had more ideas how to create solid semantics for this corner
case.
[perl #118179] FIRST doesn't see lexicals from surrounding block
coke ():
I expected it to mean the FIRST time a block is executed.
My workaround was to use a lexical to track if it was the first time
through the loop or not;
will stick with that.
masak [Coke]: doesn't START do exactly what you wanted from FIRST?
masak r: for 1..10 { my $a = 3; START { say $a } }
camelia rakudo 0e206e: OUTPUT«3»
* masak adds this to #118179
[perl #112276] [TODO] Implement 0-arg slurp in Rakudo
On Tue May 21 00:22:55 2013, labster wrote: On Tue Nov 20 18:56:50 2012, coke wrote: On Thu Apr 05 05:44:37 2012, masak wrote: moritz p6: say $*IN.slurp.comb(/e/).elems p6eval rakudo 4373f0, niecza v15-6-gefda208: OUTPUT«88» masak r: say slurp.comb(/e/).elems Both of these now say 88. Closable with tests. Added tests to slurp.t (and moved it in the process) here: https://github.com/perl6/roast/commit/3fe5dba0f2 Excellent. Resolving.
[perl #101440] [BUG] Closures created inside BEGIN blocks see the wrong outer lexpad in Rakudo
masak (), coke ():
masak nom: my $c; my $name; BEGIN { $c = { say OH HAI $name } };
$name = masak; $c()
p6eval nom ea25f3: OUTPUT«Use of uninitialized value in string
contextOH HAI »
masak I'd expect the above to say OH HAI masak.
masak are my expectations too high? :)
jnthn masak: Seems reasonableish... :)
* masak submits rakudobug
I would expect $name to be undefined at BEGIN time, which would make
this behavior correct.
Can you explain your POV here?
Yes. $name is indeed undefined (or Any) at BEGIN time, but we're not
calling it at BEGIN time.
The order of things is this:
1. Parse declarations of $c and $name. These are in scope for the rest
of the program, and there's only one runtime environment with these
variables in it -- the mainline one.
2. Parse BEGIN block. Since it's a BEGIN block, the assignment to $c
happens immediately, at compile time.
3. Parse the rest of the program. Parsing completes.
4. Switch from compile time to runtime.
5. Make the assignment to $name.
6. Make the invocation $c().
7. Now inside the Block assigned to $c. In order to print the string,
look up $name, which (there being only one, the one in the mainline
code) should now have the assigned value masak. Print it.
Something goes wrong in step 7, since the value looked up for $name
comes up as Any, not masak. The thing that goes wrong is that the
compile-time value for $name is found, not the run-time value.
The real cause/problem actually happens in step 2, when the block
assigned to $c gets incarnated (=given a runtime representation with a
runtime environment and its lexical bindings). It should get incarnated
to eventually make the lookup finding masak in $name. Whereas it
currently behaves, even when called from runtime, like it's still BEGIN
time and $name is still unassigned.
Or maybe the error is in fact at step 4, because at step 2 when can't do
much better than we already do, since we're not at runtime yet, and
there's no runtime environment with a runtime $name to incarnate into
yet. So maybe at step 4 we need to upgrade the Block to have a runtime
environment.
Or maybe it's unrealistic/slow/impossible to thus upgrade all Blocks
during the transition from compile time to runtime, and the best we can
do is simply to upgrade them ALAP, when called, at step 6. I don't know
enough about the internals to know which one is the best solution.
Hope that helps.
[perl #117935] [BUG] Sending named parameter ;p with value 0 to .postfix:{ } should yield the value and not the pair in Rakudo
lizmat actually, the :p(0) also applies to :delete and :exists
lizmat rn: my %a; %aa=1; say %aa:delete(0); say %a
camelia rakudo 2a04f2: OUTPUT«1().hash»
camelia ..niecza v24-50-gba63d9a: OUTPUT«1{}»
jnthn lizmat: Correct.
* masak adds that to the ticket
[perl #78316] [BUG] Weird error when doing .perl on .^attributes in Rakudo
On Wed Feb 01 06:28:26 2012, coke wrote:
On Sun Oct 10 16:05:36 2010, masak wrote:
masak rakudo: class Car { has @.wheels }; say Car.^attributes
p6eval rakudo 5bdbd4: OUTPUT«@!wheels»
masak rakudo: class Car { has @.wheels }; say Car.^attributes.perl
p6eval rakudo 5bdbd4: OUTPUT«Method 'attributes' not found for
invocant of class '' in 'Mu::attribs' at line 1216:CORE.setting
in
'Mu::perl' at line 1225:CORE.setting in main program body at line
1»
masak o.O
* masak submits rakudobug
New output:
09:27 [Coke] rakudo: class Car { has @.wheels }; say
Car.^attributes.perl
#RT 78316
09:27 +p6eval rakudo ce5cca: OUTPUT«(Attribute.new(),)»
Good enough?
Most definitely; it doesn't produce an error any more. Resolving ticket.
[perl #117951] [BUG] $%*ENV doesn't work in Rakudo, dies with a deprecation warning about $%
FROGGS masak: please link that patch too: https://github.com/sorear/niecza/commit/1d127e411e masak FROGGS: oh, will do. FROGGS thanks
[perl #111518] [BUG] Regex engine doesn't publish match variables early enough in some cases in Rakudo
TimToady rn: say 1001110011 ~~ /^ (.+) $0+ @([\~] $0.comb)? $ /
camelia niecza v24-48-g1d127e4: OUTPUT«｢1001110011｣ 0 = ｢10011｣»
camelia ..rakudo bfd850: OUTPUT«No such method 'comb' for invocant of
type 'Any' in regex at /tmp/OHj0MG5jaw:1 in method ACCEPTS at
src/gen/CORE.setting:10370 in method ACCEPTS at
src/gen/CORE.setting:683 in block at /tmp/OHj0MG5jaw:1»
* TimToady thinks rakudo is running the innards of @() too soon
* masak submits TimToady's rakudobug
jnthn TimToady, masak: I doubt it's about too early so much as $/
not being up to date enough.
TimToady (btw, that's a short implementatoin of *$0 there...)
TimToady probably not very speedy, but still
jnthn To test that hypothesis, but a {} before the @(...)
TimToady rn: say 1110111011 ~~ /^ (.+) $0+ {} @([\~] $0.comb)? $ /
camelia rakudo bfd850, niecza v24-48-g1d127e4: OUTPUT«｢1110111011｣ 0
= ｢1110｣»
jnthn Yup, it's that.
TimToady huh
jnthn masak: There's already an RT ticket about $/ stuff.
jnthn masak: So may want to add it (or ref it)
jnthn TimToady: I think it's just that @foo only used to interpolate
and not have the chance to run code.
masak jnthn: ok, gotcha.
jnthn TimToady: In Rakudo, Match is constructed from the stack of
captures Cursor collects.
TimToady then how does the first $0 work, if $/ is delayed?
jnthn TimToady: iirc, $0 is parsed explicitly as a back-reference and
handled separately.
masak jnthn: can't find such an RT ticket.
jnthn masak: I think the title of the ticked used the word published
and match variables, maybe not $/
TimToady well, the main point of reversing the meaning of $foo in
regex was so that $0 could be treated like a normal variable, and vice
versa...
jnthn TimToady: May still be performant to treat them separately.
jnthn TimToady: Certainly is in the Rakudo engine, anyway.
TimToady :)
masak found the RT ticket. jnthn++ :)
* masak adds today's musings
[perl #117933] [BUG] Something is going wrong with infix:mod on a 64-bit boundary with big integers in Rakudo
colomon rn: say 2804985923338703271682399481743033703427656749129565173066 mod 256 camelia rakudo fe7049: OUTPUT«36902553666127019859637446314758035961162» camelia ..niecza v24-42-g69a3432: OUTPUT«74» colomon and there's your bug masak colomon++ colomon rn: say 2804985923338703271682399481743033703427656749129565173066 % 256 camelia rakudo fe7049, niecza v24-42-g69a3432: OUTPUT«74» * masak includes colomon's find in the RT ticket
[perl #113988] [BUG] Null PMC access when doing .fmt on the return value from .reals
coke: Lists's .fmt is using the full format on each value in the list, so you get the same effect with: 3.fmt(%d %d); Null PMC access in get_integer() So it's a dupe of https://rt.perl.org/rt3/Ticket/Display.html? id=106594, really. I could merge them; any objections?
[perl #117307] [BUG] Sequences with strings and a Code stopping condition go backwards in Rakudo
Pm ():
S03 has:
For functions deduced when there is only one value on the left,
the final value is used to determine whether *.succ or *.pred is
more appropriate. The two values are compared with Ccmp to
determine the direction of the progression.
Rakudo evaluates C perl cmp { ... }as COrder::Decrease,
therefore it's using the .pred/decreasing progression.
Aye. That's clearly to spec.
So, one of the following:
a) infix:cmp should produce a different result for Str vs Code
(if so, what?),
infix:cmp is consistent the way it is, but it's a consistency that
surprises people. (Basically, comparing across incompatible is
impossible.) Adding an exception for Str vs Code feels wrong, and is the
opposite of what infix:cmp would need to be saner.
b) infix:... should assume .succ if the final value is a Code
object,
This alternative makes sense to me. It's similar to how infix:...
assumes .succ in this case: 'perl ... *'
c) Rakudo is correct, or
No. :)
d) Some other spec clarification or change needs to be made.
I'm very satisfied with how the sequence spec has turned out. It's
stable and in some kind of sweet spot. I don't imagine it needs an
overhaul of any kind, actually. But the way this particular case worked
surprised me as a user.
[perl #117217] [BUG] '...' and '???' forms of stub code escape 'try' statement in Rakudo
jnthn ??? should warn. jnthn ... should fail jnthn The fail leaks out of the try jnthn er, or either way the fail is in sink context jnthn a fail in sink context throws. jnthn ??? is correct in Rakudo jnthn ... is debatable there; I think the current spec says that try sinks everything inside of it, in which case it shoulda sunk, failed inside the try, and been quiet. * masak adds jnthn's comments to the ticket TimToady try only sinks the inside if the outside is sunk, otherwise it's eager jnthn TimToady: oh... jnthn masak: So seems it's just try ... that is in question in Rakudo, not ??? :) masak nod. masak I'll change the bug title too. TimToady S04:1000 jnthn *nod*
[perl #117171] [BUG] [WEIRD] Internal Parrot error when doing this thing in Rakudo
diakopter it's not an internal parrot error; it's the stringification
of the pseudo-stash
* masak adds this to the ticket
jnthn r: say ::.Str
p6eval rakudo 1c9939: OUTPUT«GLOBALish 7 EXPORT11 $?PACKAGE
15 ::?PACKAGE 19 $_ 23 $/ 27 $! 39 $=pod43 !UNIT_MARKER
51»
masak if it's just a stash, shouldn't it just return Any?
jnthn r: ::('wtf')
p6eval rakudo 1c9939: OUTPUT«No such symbol 'wtf'current instr.:
'throw' pc 334686 (src/gen/CORE.setting.pir:150131)
(src/gen/CORE.setting:9331)called from Sub 'sink' pc 366805
(src/gen/CORE.setting.pir:162984) (src/gen/CORE.setting:10563)called
from Sub 'MAIN' pc 381 (src/gen/perl6.pir:146…
jnthn masak: ::(...) != ::...
jnthn r: ::wtf
p6eval rakudo 1c9939: ( no output )
masak oh.
jnthn ::(...) is the thing that goes interpolating
masak ok, not a bug, then.
* masak unsubmits that one
[perl #117113] [BUG] Bogus error about 'outside of any Routine' when returning in sink context from inside of a for loop in a routine in Rakudo
masak r: sub x { return 5 for 1 }; say x
p6eval rakudo 8ea992: OUTPUT«Attempt to return outside of any Routine
[...]
masak no, it's not sink context.
* masak adds to the ticket
masak should I unassign moritz? :)
masak better not. something tells me that even if this isn't directly
related to sink context, maybe it's indirectly related.
[perl #117113] [BUG] Bogus error about 'outside of any Routine' when returning from inside of a for loop in a routine in Rakudo
not_gerd r: sub x { sink return 5 for 1 }; say x
p6eval rakudo 8ea992: OUTPUT«5»
not_gerd looks like sink context to me
not_gerd I believe it's caused by the fact that rakudo doesn't do
lexotic binding of the return to the sub
not_gerd that's bitten me with gather/take as well
* masak adds this to the ticket
[perl #117109] [BUG] .pick doesn't flatten in Rakudo
masak rn: say (0 1 xx 5).roll p6eval rakudo 8ea992, niecza v24-33-gfc6d5fd: OUTPUT«0 1» masak hm. jnthn Well, I'll do the usual thing with flattening related tickets: wait for pmichaud++ to comment on the ticket ;) jnthn I suspect this one should do what you expect though. masak but Rakudo and Niecza agree on .roll -- that makes me uncertain about .pick masak because I always saw .pick() and .roll() as equivalent in semantics. jnthn *nod* masak fwiw, my stance is that both .pick and .roll should select items without regard for those pesky nested () thingies in my lists :) masak but I have a feeling that if it were completely up to me, those pesky nested () thingies would not be there at all...
[perl #116695] [BUG] Wrong array length when Mu elements and delete interact in Rakudo
tadzik don't know about nqp, but on JVM we keep a constant value in
QRPA which says how many elements are there
tadzik it probably needs to be updated when we set Mu somewhere
moritz the problem is that if you delete an element that's not the
last, it set to Mu
moritz because we don't have an offchannel way to store an array
element as deleted
pmurias no
moritz no?
tadzik we have to settle of something: do we count the number of
defined elements in the array, or do we count the longest streak of
elements?
pmurias the problem is that if you delete the last element all the
undefined elements before it get deletedf
moritz r: my @a = a b c d; @a.delete(2); say @a.perl
p6eval rakudo 4fb07b: OUTPUT«Array.new(a, b, Any, d)»
moritz tadzik: or do we simply keep the count separate, and don't do
any magic
moritz pmurias: I'm (nearly) sure there's a spectest that requires
that
pmurias r: class Foo {};my $foo = [0,1,2,3,4];say $foo.elems;$foo[4] =
Foo;$foo[3] = Foo;say $foo.elems;$foo.delete(4);say $foo.elems;
p6eval rakudo 4fb07b: OUTPUT«553»
pmurias moritz: it seems to be a bug in the code
moritz fwiw I agree that's undesirable
moritz but I can't quite imagine that it happened without any
intention
* masak adds this to the ticket
pmurias the spec seems to hold an distinction between elements that
aren't in an array and those that are set to an undefined value
[perl #116595] [BUG] Nesting wrapping roles bind 'callsame' to the wrong recipient in Rakudo
masak 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] }
p6eval niecza v24-18-gaf64300: OUTPUT«235»
p6eval ..rakudo b3fc32: OUTPUT«(timeout)23»
masak jnthn: this is as short as I'm able to golf it.
masak 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.
[perl #116521] [BUG] 'state' is seriously broken in Rakudo
On Wed Jan 23 02:35:53 2013, masak wrote:
I'm not one to use it's broken as a bug ticket description -- I
think it's bad style. But this is the exception that proves the rule:
somehow state not only isn't doing what it says on the tin, but it
breaks parsing, too.
masak nr: sub f { say ++state $ ; }; f; f; f
p6eval rakudo a26956: OUTPUT«111»
p6eval ..niecza v24-18-gaf64300: OUTPUT«123»
* masak submits rakuobug
masak what's worse:
masak nr: sub f { say ++(state $ = 0); }; f; f; f
p6eval rakudo a26956: OUTPUT«===SORRY!===Error while compiling
block : Error while compiling op call: Error while compiling block :
Error while compiling block f: Error while compiling op p6typecheckrv:
Error while compiling op lexotic: Error while compiling op p6decontrv:
Error while compili…
p6eval ..niecza v24-18-gaf64300: OUTPUT«123»
Niecza has it right both times.
jnthn masak: odd bug. wonder if it relates to my fixing the over-
sharing bug.
jnthn If so, it means we're missing some test coverage...
* jnthn is surprised we'd be missing it for anon state vars
masak jnthn: when did you fix? I'd like to bisect.
jnthn Not sure, recently
jnthn It was the bug when my @ and a later my @ would share the value
* masak goes looking
masak
https://github.com/rakudo/rakudo/commit/bd9bc6ff017a78783a039282ae9e36f9
74af3d8a
masak jnthn: confirmed #1: in bd9bc6f^, 'state' works.
masak jnthn: confirmed #2: in bd9bc6f, 'state' is b0rken.
* masak adds this to the RT ticket
[perl #70297] [BUG] No explicit ^D and no newline after ^D in the REPL in Rakudo
On Sat Oct 01 15:16:23 2011, masak wrote: On Sat Oct 01 04:22:04 2011, moritz wrote: Now a EOF (Ctrl+D) is answered with a newline, and the REPL exits. Closing without spectests, because the REPL isn't specced. As the original submitter, I'm reopening the ticket because only one of the two expected behaviours is observed. The newline is there, but not the ^D. ...and now, in 2013, we have neither ^D nor newline.
[perl #116280] [BUG] NaN, Inf, -Inf aren't padded with spaces in sprintf in Rakudo
On Tue Jan 08 11:40:37 2013, FROGGS.de wrote: This would mean to bring over 500 lines of C code to nqp/rakudo. Is that an absolute claim? What about wrappers? And this would mean that it doesn't get faster. Is it worth it? In my mind, correctness trumps speed. The current behavior seems obviously wrong to me. As a user, I was concerned about correctness, not speed. Hence the bug report.
[perl #116314] [BUG] 'for' loops in phasers in 'for' loops don't run in Rakudo
moritz masak: fwiw https://rt.perl.org/rt3/Ticket/Display.html? id=116314 is about the phasers not being put in sink context properly masak moritz: show me your reasons for believing this. moritz masak: for loops are lazy, and only run in eager or sink context moritz masak: so if normal statements are run, but for loops aren't, sink context is missing * masak adds this to the ticket
[perl #116220] [BUG] Can't talk about roles with unimplemented methods in Rakudo
doy also: its not just stringification methods, it seems that calling
any method at all on a role with required methods is broken
doy r: role Foo { method bar {...} }; say Foo.^name
p6eval rakudo c8de2e: OUTPUT«Method 'bar' must be implemented by Foo
because it is required by a role [...]
masak :/
masak r: role Foo { method bar {} }; say Foo.^name
p6eval rakudo c8de2e: OUTPUT«Foo»
* masak adds that to the ticket
[perl #113904] [BUG] Null PMC Access when blocks get the wrong $_ sometimes in Rakudo
zjmarlow r: my $line; for one two three .values - $line { if True
{ .say } }
p6eval rakudo bf472b: OUTPUT«Null PMC access [...]
masak huh.
masak we may have this in RT already, actually.
masak r: for 1 - $ { if 1 { .say } }
p6eval rakudo bf472b: OUTPUT«Null PMC access [...]
masak yes, here: https://rt.perl.org/rt3/Ticket/Display.html?id=113904
masak though this particular case has an 'if', not a 'when'.
masak r: $_ = 42; .say
p6eval rakudo bf472b: OUTPUT«42»
masak r: $_ = 42; for 1 { .say }
p6eval rakudo bf472b: OUTPUT«1»
masak r: $_ = 42; for 1 { if 1 { .say } }
p6eval rakudo bf472b: OUTPUT«1»
masak r: $_ = 42; for 1 - $p { .say }
p6eval rakudo bf472b: OUTPUT«42»
masak r: $_ = 42; for 1 - $p { if 1 { .say } }
p6eval rakudo bf472b: OUTPUT«Null PMC access [...]
masak this one illustrates it fairly well. I'll paste it into the
ticket.
[perl #79116] [BUG] Non-associative operators mistakingly allowed in reduction meta-op
On Fri Nov 12 07:37:03 2010, Solomon wrote: rakudo: say [leg] a b c p6eval: rakudo d85964: OUTPUT«-1» ...but... Any infix operator (except for non-associating operators) can be surrounded by square brackets in term position to create a list operator that reduces using that operation... [S03] p6eval rakudo bf472b: OUTPUT«Increase» FROGGS is that right? two years ago you got -1 [Coke] FROGGS: -1 is to Increase like 1 is to True FROGGS hmmm FROGGS so its still wrong [Coke] it's a builtin enum for comparisons that I think only rakudo implements yet. FROGGS I dont understand what I should get instead by reading https://rt.perl.org/rt3/Ticket/Display.html?id=79116 [Coke] r: say +Increase p6eval rakudo bf472b: OUTPUT«-1» [Coke] that ticket was opened by colomon; have him tell you the expected output. [Coke] (or, better, write a test) [Coke] n: say [leg] a b c p6eval niecza v22-33-gda13155: OUTPUT«===SORRY!===Cannot reduce with leg because structural infix operators are diffy and not chaining [...] [Coke] r: say [leg] a q e p6eval rakudo bf472b: OUTPUT«Increase» masak oh! maybe leg is non-associating. masak that might be what the ticket is hinting at. masak it certainly doesn't say it outright. [Coke] I think maybe leg isn't supposed to be amenable to meta-ing in that fashion, perhaps. [Coke] er, what masak said. :) [Coke] std: say [leg] a q e p6eval std d38bbd0: OUTPUT«===SORRY!===Cannot reduce with leg because structural infix operators are diffy and not chaining [...] [Coke] so, I think std and n have what the ticket is looking for here. masak S03 agrees; infix:leg is non-associating. masak [Coke]: *nod* * masak adds this to the ticket
[perl #72696] [BUG] Defining two different enumerations with the same enum value should result in ambiguity in Rakudo; doesn't
On Thu Nov 15 05:16:59 2012, bbkr wrote: 2012.10 - still broken (should fail on redeclaration) bbkr_ rakudo: enum A a b c; enum B a b c; say c.perl p6eval rakudo c82d10: OUTPUT«B::c» Just for the record; no, it shouldn't fail on redeclaration (despite STD's error message). The spec says that the a, b, and c slots become poisoned and can't be used as-is anymore. They have to be specified as A::a etc.
[perl #115740] bare '=pod' does not count as abbreviated block
On Thu Nov 15 05:14:34 2012, pawel.pab...@implix.com wrote: Rakudo 2012.10 bbkr_ r: =pod p6evalrakudo c82d10: OUTPUT«===SORRY!===Preceding context expects a term, but found infix = insteadat /tmp/eqe30h6iti:1» bbkr_ std: =pod p6evalstd 04216b1: OUTPUT«ok 00:00 40m» bbkr_ which one is incorrect? should bare =pod (without closing =end tag) be allowed? masak I don't think STD does any Pod parsing. bbkr_ then it's LTA rakudo message, right? masak possibly. * bbkr_ reports masak I'd like to hear what tadzik has to say about it. masak the above should count as abbreviated block syntax, I think. as far as I see, it shouldn't need an ending delimiter, because abbreviated blocks auto-close. moritz it's the missing newline, not p6eval ;-) masak r: =pod p6eval rakudo c82d10: ( no output ) masak so, no bug. * masak rejects ticket
[perl #115506] [BUG] Bad failure mode when macro returns AST.new in Rakudo
coke ():
I was unable to test this:
#RT #115506
eval_lives_ok
macro pathological { AST.new }; pathological();,
macro returning AST.new doesn't blow up;
fails with:
prove -v -e t/fudgeandrun t/spec/S06-macros/errors.tt/spec/S06-
macros/errors.t ..
1..1
not ok 1 - macro returning AST.new doesn't blow up
# Error: Missing block
# Looks like you failed 1 tests of 1
Double-quoted strings interpolate {} blocks. So I don't think the
first argument to eval_lives_ok means what you think it means. I've done
the same thinko myself a number of times.
[perl #115712] [BUG] When somebody sets up it the BOM, all our base are not belong to Rakudo
On Tue Nov 13 04:29:08 2012, masak wrote: masak I wonder why we shouldn't simply strip the BOM in Rakudo if we find it. The grammar now ignores BOM at the start of a compilation unit. Spectest added. Resolving ticket.
[perl #115608] [BUG] Cannot call a routine using 'foo' syntax when a module 'foo' is declared in Rakudo
jnthn module foo; sub foo() { say OH HAI }; foo; foo()
jnthn In this one, foo() parses as a coercion.
masak jnthn: oh!
* masak adds that to the appropriate rakudobug
jnthn Anyway, it's right it doesn't call the sub. Just an LTA error I
guess...though I ain't immediately sure what to do with it...
[perl #115506] [BUG] Bad failure mode when macro returns AST.new in Rakudo
On Sat Oct 27 10:45:32 2012, masak wrote:
diakopter r: macro marco { AST.new }; marco
p6eval rakudo 6859fb: OUTPUT«===SORRY!===Error while compiling
block : Error while compiling op call: Error while compiling block :
Error while compiling block : Unknown QAST node type Any»
diakopter :
masak diakopter: fair point.
* masak submits rakudobug
Fixed as of 026880:
$ nom -e 'macro pathological { AST.new }; pathological(); say alive'
alive
Tagging testneeded.
[perl #101296] [BUG] Null PMC access when accessing type object belonging to an outer role from within an inner class in Rakudo
coke (): Is this sufficient to close the ticket? I would say so; the Null PMC access is gone. Resolving ticket.
[perl #75756] [BUG] Str.uc knows that the letter ß upper-cases as SS, case-insensitive regexes don't in Rakudo
On Sat Oct 20 18:17:19 2012, coke wrote: On Tue Jun 15 02:16:28 2010, masak wrote: sorear How does case insensitive matching work in perl 6? sorear e.g. ß ~~ m:i/SS/ masak sorear: that's the syntax, so I assume you're asking about the semantics. masak oh wait, that example is tricky :) masak I would be surprised if Perl 6 is spec'd to handle that. sorear yes. semantics, and dark corners thereof sorear yes, S05 says exactly nothing on the subject sorear other than ignores case distinctions moritz_ rakudo: say ß ~~ /:i SS/ p6eval rakudo cfbeb5: OUTPUT«» moritz_ rakudo: say uc ß p6eval rakudo cfbeb5: OUTPUT«SS» masak o.O masak German is strange. moritz_ it sure is. moritz_ masak: want to submit a bug report about inconsistency? * masak submits rakudobug Behavior changed: ß ~~ m:i/SS/ #failed match say uc ß ß Closable? Well, the *inconsistency* seems to be gone... but by pushing the semantics in (what I consider to be) the wrong direction. I.e. now instead of one of two things behaving the wrong way, both do.
[perl #74182] [TODO] Rakudo doesn't understand - pointy blocks
On Fri Apr 09 08:47:41 2010, masak wrote:
masak std: if 1 - $x {}
p6eval std 30351: OUTPUT«ok 00:01 107m»
masak rakudo: if 1 - $x {}
p6eval rakudo 4c94d7: OUTPUT«Missing block at line 11, near [...]
jnthn fejl
* masak submits rakudobug
moritz_ rakudo: - $x { }
p6eval rakudo 4c94d7: OUTPUT«Confused at line 11, near - $x { }
[...]ra
moritz_ even easier
moritz_ rw lambda NYI
masak I'll phrase the ticket accordingly.
Now implemented.
masak rakudo: - $x { }
p6eval rakudo 2fca74: ( no output )
jnthn says there are spectests. Resolving ticket.
[perl #115272] [BUG] Totally legit thing inside ... quotes deemed un-legit by Rakudo
masak rn: say 'm'\'n' p6eval rakudo 8a07b8: OUTPUT«'m'\'n'» p6eval ..niecza v22-13-g0d2a99e: OUTPUT«'m''n'» masak rn: say 'm'\'n' p6eval niecza v22-13-g0d2a99e: OUTPUT«===SORRY!===Preceding context expects a term, but found infix instead [...] Parse failed» p6eval ..rakudo 8a07b8: OUTPUT«'m''n'» * masak decides to include these discrepancies, also reported by diakopter++, in the bug report They seem relevant. The one who fixes the original bug may decide to relate somehow to the above two discrepancies as well.
[perl #115278] [BUG] Class B deriving from stubbed-and-then-defined class A doesn't have a .new method, nor a .gist method in Rakudo
moritz I don't think you should be able to inherit from a class that's
only stubbed
moritz the proper way is to stub the subclass
masak I agree that the problem we're seeing here stems from deriving
from the stubbed class.
masak I'm not yet convinced it shouldn't be allowed.
masak oh, TimToady++ has a fix in the backlog:
masak r: class A is Any { ... }; class B is A { has A $.foo }; class A
{ has B $.bar }; say A.new.bar
p6eval rakudo 8a07b8: OUTPUT«B()»
* masak includes this in the ticket
[perl #114708] [BUG] LTA message when splicing into string
spider-mario ():
sub test($x) {quasi {$x}}
Result:
Error while compiling block : Error while compiling op call: Error
while
compiling block : Error while compiling block test: Error while
compiling
block : Error while compiling block : Unknown QAST node type
QAST::Unquote
Ah, well spotted. Yes, this is a QAST::Unquote node surviving past its
time in the compilation process. Fixing the error means figuring out why
it does.
[perl #114440] [BUG] 4 eqv 4.0 yields False in Rakudo
TimToady it is a nieczabug, not a rakudobug, since === and eqv can only match if the types are the same * masak rejects the rakudobug * masak submits nieczue
[perl #114276] [BUG] Cannot return junctions from .classify blocks in Rakudo
On Tue Aug 07 03:36:11 2012, moritz wrote: What behavior do you expect? I can only fix it if I know what it should look like after the fix :-) The immediate expectation is for the error Cannot assign to a readonly variable or a value not to occur. That's the observable -- sorry for being less-than-clear on that. :) Then again, I see the problem in deciding what should happen. The conservative thing would be to have .classify barf on junctions as keys. Or -- if it makes sense -- have the junction be stringified and use the string as the key.
[perl #78276] [BUG] Null PMC access when calling a multi sub with a parameter narrowed by a subtype that does a regex match in Rakudo
masak r: sub detect(Str $foo where { /O/ }) {}; detect O
p6eval rakudo 34e8d4: OUTPUT«No such method 'match' for invocant of
type 'Any' [...]
jnthn Oh...is that a sink context oopsie?
masak r: subset Ostring of Str where { /O/ }; say O ~~ Ostring
p6eval rakudo 34e8d4: OUTPUT«No such method 'match' for invocant of
type 'Any' [...]
masak seems so.
jnthn Not surprising given we don't really do sink context properly
yet.
jnthn A curious place for it to fall out though
* masak updates the ticket
masak r: say O ~~ { /O/ }
p6eval rakudo 34e8d4: OUTPUT«»
moritz I guess the problem is that at the point where the regex is
evaluated in boolean context, $_ isn't bound to 'O'
[perl #95514] [BUG] Bogus error message about not enough positional parameter when role method calls another after a role method delegation in Rakudo
On Sun May 27 20:48:46 2012, coke wrote:
On Sun Jul 24 07:11:16 2011, masak wrote:
masak rakudo: role R { method foo { self.bar(42) }; method bar($x)
{
say OH HAI } }; class C does R { method foo { self.R::foo } };
C.new.foo
p6eval rakudo 922500: OUTPUT«OH HAI»
masak rakudo: role R { method bar($x) {}; method foo {
self.bar(42)
} }; class C does R { method foo { self.R::foo } }; C.new.foo
p6eval rakudo 922500: OUTPUT«Not enough positional parameters
passed; got 1 but expected 2 in 'bar' at line 22:/tmp/N060_2D3In
in
'C::foo' at line 22:/tmp/N060_2D3In in main program body at line
22:/tmp/N060_2D3In»
* masak submits rakudobug
masak only the order of the method declarations in the role
differs.
masak rakudo: role R { method bar($x) { say OH HAI }; method foo
{
self.bar(42) } }; R.new.foo
p6eval rakudo 922500: OUTPUT«OH HAI»
masak and it seems that, somehow, the role method delegation is
necessary to trigger it.
The second variant no longer errors. If you put a say $x in the bar
method, it's printed out.
masak r: role R { method bar($x) { say $x }; method foo { self.bar(42)
} }; class C does R { method foo { self.R::foo } }; C.new.foo
p6eval rakudo 0eea68: OUTPUT«42»
Confirmed.
Closable?
When it has tests, yes. Marking testneeded.
