Perl 6 language and compiler development | Logs at colabti.org/irclogger/irclogger_log/perl6-dev | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
Set by Zoffix on 27 July 2018.
vrurg Where can I find info on how natives are handled internally? Trying to trace down a bug with uint and can't trace things down to MoarVM functions. 00:15
MasterDuke vrurg: a lot of the uint functionality is currently handled by the int functions (part of the reason for a lot of the uint bugs) 00:48
but what do you mean by handled? 00:49
vrurg MasterDuke: I mean pretty much everything. Any info would be useful.
In particular, I'm trying to find out why assigning a value with signature bit set (like 128) to uint results in the same value – but negative (-128). For now can't even determine wether it happens upon assignment or upon reading. 00:51
MasterDuke well, any of the nqp::*_(i|n|s) ops operate on natives
vrurg But none of them are involved in this case. R#2354 – it's about attrref 00:52
MasterDuke i believe in that case it's kind of both. i.e., 64bits are being passed around, if you interpret them an unsigned you get one value, if you interpret them as signed (which most moarvm functions do) you get a different value 00:53
i had a branch in moarvm where i tried to add uint support to a bunch of stuff, but it was a while ago and i got over my head 00:54
let me see if i can find it, its commits should show you some of the relevant places to look
vrurg MasterDuke: thanks! Might be helpful. Though if it requires some major overhaul of MoarVM – I'd better pass it over to somebody else. I'm not ready for this level yet. 00:56
MasterDuke hm, github.com/MasterDuke17/MoarVM/com...re_missing is the only thing i found that seems immediately relevant, but i thought i had done more. oh well, maybe not... 00:57
vrurg Ok, new ops are needed, as I see from your commits... 00:59
MasterDuke well, i wouldn't take my work there as gospel truth 01:00
vrurg I have to go now. Will check it out more close tomorrow.
MasterDuke good luck
vrurg MasterDuke: I just think you were right. I don't see how _i can handle unsigneds correctly. 01:01
MasterDuke: thanks!
o/
02:40 lucasb left 04:05 sortiz joined 04:09 ExtraCrispy left 05:13 Kaiepi left 05:15 Kaiepi joined 06:26 robertle left 07:45 ExtraCrispy joined 08:09 robertle joined 09:07 lizmat left 09:34 vrurg left
Geth nqp/master: 6 commits pushed by (Paweł Murias)++ 09:55
10:10 lizmat joined 10:58 lizmat left 11:02 lucasb joined
|Tux| Rakudo version 2019.03-32-g33e2d7f4c - MoarVM version 2019.03-11-g7ae6684f4
csv-ip5xs0.744 - 0.767
csv-ip5xs-206.116 - 6.149
csv-parser23.097 - 23.513
csv-test-xs-200.438 - 0.441
test7.736 - 8.260
test-t1.822 - 1.854
test-t --race0.868 - 0.872
test-t-2031.940 - 32.164
test-t-20 --race9.657 - 9.801
11:08
11:09 lizmat joined
sortiz lizmat: Can you take a look to github.com/rakudo/rakudo/issues/2764 11:11
11:12 lizmat left 11:17 lizmat joined
lucasb hello 11:18
m: dd Failure.new; say 'ok'
camelia Failure.new(exception => X::AdHoc.new(payload => "Failed"), backtrace => Backtrace.new)
ok
lizmat sortiz lucasb
yoleaux 14 Mar 2019 14:48Z <|Tux|> lizmat: github.com/Tux/CSV/issues/13 ← any ideas?
lizmat will look at R#2764 11:19
lucasb m: dd Failure.new.new; say 'ok' # Failure:D as invocant 11:21
camelia Failure.new(exception => X::AdHoc.new(payload => "Failed"), backtrace => Backtrace.new)
ok
sortiz m: (+"a").new.perl.say; say "ok"
camelia Failure.new(exception => X::AdHoc.new(payload => "Failed"), backtrace => Backtrace.new)
ok
11:23 Guest4810 left 11:25 Guest4810 joined
sortiz Found that while researching for open Failure related tickets. 11:25
lizmat spectesting fix now 11:28
sortiz Thank you! 11:29
m: Failure(+"a").perl.say; # Another corner case. 11:33
camelia Invocant of method 'CALL-ME' must be an object instance of type 'Failure', not a type object of type 'Failure'. Did you forget a '.new'?
in block <unit> at <tmp> line 1
Geth rakudo: c9110654bd | (Elizabeth Mattijsen)++ | src/core/Failure.pm6
Make sure creating a Failure from a Failure object throws

Fixes R#2764, sortiz++ for the spot
11:57
lizmat sortiz: ^^ 12:00
must be offline for a bit again&
12:04 lizmat left, lizmat_ joined 12:13 lizmat_ left 12:19 lizmat joined 13:21 vrurg joined 13:25 AlexDani` joined 13:29 AlexDaniel left 13:43 AlexDani` is now known as AlexDaniel, sortiz left 13:45 AlexDaniel left 13:46 AlexDaniel joined 14:08 MasterDuke left 14:12 Guest4810 left 14:19 Guest77544 joined 14:21 pmurias joined
pmurias m: use nqp;say nqp::getattr(nqp::decont(1.FatRat),Rat,"\$!numerator")' 14:21
yoleaux 14 Mar 2019 21:07Z <MasterDuke> pmurias: output from my kubuntu box (on my default-int branch if it matters) gist.github.com/MasterDuke17/ba12f...4e1593e9bd
camelia 5===SORRY!5=== Error while compiling <tmp>
Two terms in a row
at <tmp>:1
------> 3qp::decont(1.FatRat),Rat,"\$!numerator")7⏏5'
expecting any of:
infix
infix stopper
postfix
statement end
pmurias jnthn: ^^^ why does that nqp::getattr work on moar?
j: say(123)
camelia 123 14:22
pmurias j: use nqp;say nqp::getattr(nqp::decont(1.FatRat),Rat,"\$!numerator")'
camelia 5===SORRY!5=== Error while compiling <tmp>
Two terms in a row
at <tmp>:1
------> 3qp::decont(1.FatRat),Rat,"\$!numerator")7⏏5'
expecting any of:
infix
infix stopper
postfix
statement end
pmurias m: use nqp;say nqp::getattr(nqp::decont(1.FatRat),Rat,"\$!numerator")
camelia 1
pmurias j: use nqp;say nqp::getattr(nqp::decont(1.FatRat),Rat,"\$!numerator")
camelia java.lang.RuntimeException: No such attribute '$!numerator' for this object
in block <unit> at <tmp> line 1
pmurias jnthn: this causes as a problem on the js backend (as well as on the jvm but that doesn't seem like something that should work at all) 14:23
jnthn pmurias: Probably because there's that slot optimization where we access attributes by index, and Moar doesn't bother to be strict about it (it does just enough for memory safety but nothing more)
pmurias: Any code doing that is wrong and should be changed.
lizmat m: use nqp;say nqp::getattr(nqp::decont(1.FatRat),Rat,"\$!numerator") 14:25
camelia 1
lizmat m: use nqp;say nqp::getattr(nqp::decont(1.FatRat),Rat,"\$!numerator")'
camelia 5===SORRY!5=== Error while compiling <tmp>
Two terms in a row
at <tmp>:1
------> 3qp::decont(1.FatRat),Rat,"\$!numerator")7⏏5'
expecting any of:
infix
infix stopper
postfix
statement end
pmurias the trailing ' was a typo
lizmat there was a trailing ' in pmurias' code
ack 14:26
pmurias lizmat: but the problem is that a FatRat is not a Rat
lizmat news.perlfoundation.org/2019/03/feb...rl-6-.html
jnthn It's possible, given we have spesh and the like, that the optimization in question is no longer very valurable
lizmat pmurias: indeed, they're just both doing the Rational role 14:27
pmurias jnthn: other thing is that we have a bunch of nqp lowlevel objects that are special cased during serialization, should all backends forcing serialization of them as regular objects (by putting them into a serialization context) 14:29
14:37 Kaiepi left, Kaiepi joined 14:38 Kaypie joined, Kaiepi left
pmurias lizmat: how do we want to fix that? add accessor methods back in or duplicate code with both a Rat version and accessor one? 14:46
if we duplicate code I would add both a multi with Rat and a multi with Rational, which would duplicate a fair bit of lines 14:53
lizmat pmurias: or put that in a role that could be mixd in ? 14:57
jnthn Can it not go in Rational? (disclaimer: didn't look at the code :)) 14:59
lizmat fwiw, I'm not sure what methods would need to be added? 15:02
15:03 pmurias left
jnthn Hmm, t/spec/S32-str/utf8-c8.t seems to have a compile error in it 15:08
15:09 pmurias joined 15:12 lizmat_ joined
lizmat_ wow 15:12
15:15 lizmat left
jnthn Currently testing out some branches over moar/nqp/rakudo to merge, and that one failed spectest...but it seems not due to the branches :) 15:15
Geth roast: f090aa6d36 | (Elizabeth Mattijsen)++ | S32-str/utf8-c8.t
Remove mystery closing brace that broke compilation
lizmat_ jnthn: ^^
does that help?
jnthn Probably :)
Thanks
(Was gonna look at it, but was checking into if the branches cause a regression in one benchmark) 15:16
15:17 Guest77544 left, lizmat_ is now known as lizmat
jnthn Hm, no, it's same-ish on HEAD without the branches. Hmm. 15:17
I'm sure it used to be better
lizmat class ListFailure is Failure does Iterable { method iterator { self.exception.throw } } # interesting idea by leont 15:21
to be returned by those cases where an Iterable is returned, and we want to return a Failure
#2650 15:22
jnthn Is doing that to iterator in Failure problematic?
lizmat yes
jnthn OK, why?
lizmat hmm... maybe I misunderstood the question, could you rephrase ?
jnthn m: sub foo() { fail "bar" }; dd foo().iterator 15:23
camelia Rakudo::Iterator::ReifiedListIterator.new
jnthn If Failure got the method iterator that is proposed for ListFailure, does it break spectests? Ecosystem? 15:24
lizmat ah... ok,. interesting... lemme check
pmurias lizmat: github.com/rakudo/rakudo/blob/mast...t.pm6#L331 - the multi signature uses Rational while the method body has a nqp::getattr with Rat 15:32
jnthn: the copy & pasted & modified code could go into Rational 15:33
jnthn Oh, that should just be using the accessors 15:34
If it's going to constrain on Rational
Not getattr etc.
lizmat the initial idea about that was to make them faster 15:35
jnthn Yeah but it also makes them wronger
lizmat but using accessors now wouldn't make that much difference, would it ?
jnthn No
They'll be inlined
lizmat ok, cool...
pmurias: am about to go out, so if you beat me to it, that's fine
otherwise I'll de-nqp those ops tonight 15:36
jnthn Hmm, Geth? :)
pmurias lizmat: I'll handle that ;)
jnthn I just merged some opts I'd been holding back until post-release, anyways
lizmat jnthn: re adding Failure.iterator: minor breakage in S03-operators/minmax related to Failure vs thrown exception 15:38
jnthn: so that seems a sensible solution
jnthn Does it fix the issue being discussed? :) 15:40
lizmat m: dd Failure.new.min 15:41
camelia Failure.new(exception => X::AdHoc.new(payload => "Failed"), backtrace => Backtrace.new)
lizmat with the new code, that throws
$ 6 'dd Failure.new.min'
Failed
so yes, I think it solves the issue being discussed
jnthn Hm, maybe throwing in .iterator is too eager, and we should be returning self there, so that it's the .pull-one that fails 15:42
uh, throws
Or something along those lines
Seems we can find a solution that doesn't make us introduce another new type, though.
lizmat but then it would throw because there is no Failure.pull-one ? 15:43
jnthn Hmm, yeah 15:44
lizmat hmm... seems to work just fine 15:46
I guess the FALLBACK ?
jnthn Perhaps
lizmat yeah, looks like
jnthn But does it still blow up somewhere in the cases we wish it to?
lizmat $ 6 'sub foo() { fail }; for foo() { dd $_ }' 15:47
Failed
yup, I'd say
jnthn Nice
lizmat m: sub foo() { fail }; for foo() { dd $_ }
camelia Failure.new(exception => X::AdHoc.new(payload => "Failed"), backtrace => Backtrace.new)
lizmat need to go out now... will commit later tonight and fix the tests 15:48
16:11 robertle left
Geth rakudo: c21054de65 | (Paweł Murias)++ | src/core/Rat.pm6
Fix use of nqp::getattr with sometimes wrong class
16:43
16:55 pmurias left
Geth rakudo: 29878d8239 | (Jonathan Worthington)++ | src/vm/moar/ops/container.c
Produce simpler spesh op for decont
17:25
17:34 ExtraCrispy left, ExtraCrispy joined
Geth rakudo: 23fca8f6fb | (Elizabeth Mattijsen)++ | src/core/Failure.pm6
Make a Failure throw when it is used as something Iterable

Fixes R#2650. Makes .iterator throw immediately. There was some discussion on #perl6-dev on whether or not to have .iterator just return self, rather than throwing. But that would just delay the throwing until the FALLBACK of Failure would catch the "pull-one", which felt as just wasting extra cycles.
... (5 more lines)
18:29
bartolin oh, the nqp::getattr for Rat turned out to be a bug. I've asked about it a while ago, but didn't fully understand whether it was wrong (or what exactly): colabti.org/irclogger/irclogger_lo...01-28#l806 18:30
pmurias++ # fixing it
lizmat yeah, those opts where done assuming that FatRat ~~ Rat was True 18:31
before I had a complete appreciation of the Rational role
bartolin re-reads today's discussion -- hoping to understand the issue better 18:33
timotimo bartolin: your nickname sounds vaguely like a musical instrument :D 18:34
bartolin does it? I've never had that association :) 18:35
timotimo well, it took a while for me, too. and also i'm just now playing on my keyboard 18:38
bartolin feels a bit 're-motivated' to look at the jvm backend again (by pmurias's commit) 18:42
or do you consider the jvm backend dead by now?
lizmat bisectable6: dd "a".subst( /(.)/, "b$0b") 18:45
bisectable6 lizmat, Bisecting by output (old=2015.12 new=23fca8f) because on both starting points the exit code is 0
lizmat hmmm.. that never worked ?
bisectable6 lizmat, bisect log: gist.github.com/728d1ae1e195960218...06aafe0afc
lizmat, (2016-09-01) github.com/rakudo/rakudo/commit/63...6892a7df4f
lizmat m: dd "a".subst( /(.)/, "b$0b") 18:46
camelia Use of Nil in string context
in block <unit> at <tmp> line 1
"bb"
nine_ bartolin: having a working JVM backend can only help 18:47
18:47 Kaypie is now known as Kaiepi
lizmat m: my $a = "Å"; $a ~~ s:s/(.)/b$0b/; dd $a # huh ?? 18:47
camelia Str $a = "b̊Åb̊"
lizmat feels like a bug to me 18:48
AlexDaniel 6c: dd "a".subst( /(.)/, "b$0b") 18:50
lizmat bisectable6
bisectable6: my $a = "Å"; $a ~~ s:s/(.)/b$0b/; dd $a
bisectable6 lizmat, On both starting points (old=2015.12 new=23fca8f) the exit code is 0 and the output is identical as well
lizmat, Output on both points: «Str $a = "b̊Åb̊"␤»
committable6 AlexDaniel, gist.github.com/18e0678ae6f583a098...67a7407e97
lizmat been there like forever then
Geth roast: 75132b836b | (Elizabeth Mattijsen)++ | S03-operators/minmax.t
Trying to iterate a Failure now throws immediately

In response to R#2650
19:01
bartolin in the past I've tried to keep 'make spectest' on the jvm backend as clean as possible. For (new) test failures, that I wasn't able to fix, I added backend specific fudges to roast -- generating a lot of noise. As far as I understood Zoffix++ wasn't keen on all those commits. Do you have (strong?) opinions about such fudges? 19:06
bartolin wonders how pmurias handles this for the js backend 19:07
19:58 committable6 left, reportable6 left, shareable6 left, greppable6 left, evalable6 left, releasable6 left 19:59 committable6 joined, ChanServ sets mode: +v committable6, greppable6 joined 20:00 releasable6 joined, ChanServ sets mode: +v releasable6, shareable6 joined, ChanServ sets mode: +v shareable6 20:01 reportable6 joined 20:02 evalable6 joined, ChanServ sets mode: +v evalable6 20:29 AlexDaniel left, AlexDaniel joined 20:38 AlexDaniel left 20:55 Euph0ria joined 20:56 Euph0ria left 21:12 pmurias joined 21:58 leont joined
jnthn bartolin: I've no objections to fudges going in to roast, fwiw 22:47
leont Failures do the weirdest things 23:18
m: use Test; my @foo = (Failure.new("")); @foo[0]; try { @foo[0] }; dd $1; 23:19
camelia Nil
leont m: use Test; my @foo = (Failure.new("")); @foo[0]; try { @foo[0] }; dd $!;
camelia X::AdHoc $! = X::AdHoc.new(payload => "")
leont @foo[0] is fine outside the try, but throws inside of it??? 23:20
I can't explain this 23:22
jnthn Side point: the parens around the Failure don't change anything 23:26
But the answer is that `use fatal` is in effect inside of a try 23:27
try { foo } is really like { use fatal; CATCH { default { $! = $_ } }; foo }() 23:28
leont I see 23:32
That does explain why lives-ok fails when throws-ok also fails. 23:33
(on the same coderef) 23:34
I'm not entirely sure which behavior is desirable, but I'm pretty sure consistency is 23:40
23:57 sortiz joined