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.
00:06 AlexDaniel left 00:08 AlexDaniel joined, p6bannerbot sets mode: +v AlexDaniel
[Coke] Yes. still need to act on my end, apologies. 00:09
MasterDuke timotimo: heh, i just got back to my computer, found it in gdb at a breakpoint, and couldn't remembered why that was
00:10 MasterDuke_ joined, p6bannerbot sets mode: +v MasterDuke_ 00:13 MasterDuke left 00:14 MasterDuke_ is now known as MasterDuke, MasterDuke left, MasterDuke joined, herbert.freenode.net sets mode: +v MasterDuke, p6bannerbot sets mode: +v MasterDuke 00:15 lizmat left
MasterDuke timotimo: do you remember why you were suggesting gdb? i assume it was something to do with my `Cannot invoke this object (REPR: P6opaque; NQPMu)` error 00:18
timotimo right 00:19
to hopefully figure out where the null came from
MasterDuke ah, that would be helpful
i tried dumping bytecode, that just caused an error in gdb 00:22
timotimo ugh, yeah 00:23
it's sometimes rather hard to get calling code from inside gdb to work; there's a fiddlyness that i have not a clue how to figure out properly
you can write python code that uses the gdb python API to do some cool stuff, but ... when i wrote the "heap analyzer" it was surprisingly slow 00:24
and using the API correctly is also very fiddly
MasterDuke hm, anything i can just print out that'll be helpful? 00:25
timotimo hmm
well, it'd be awesome if we could use the debugserver stuff from inside gdb
but i'm not sure if we can "stop some threads but not others" in gdb? 00:26
MasterDuke timotimo: like this? sourceware.org/gdb/onlinedocs/gdb/N...dStop-Mode 00:27
timotimo whoa
amazing 00:28
OK, but there's a little problem - easy to solve, but a stumbling block none-the-less
MasterDuke oh? 00:29
timotimo well, the debugserver won't touch a thread that hasn't reported itself as successfully interrupted
which it won't when gdb interrupts it
but i think it's enough to just write the tc's gc_status (or what it's called) to the right value
so maybe this is even a way to go! 00:30
MasterDuke cool. what do i need to do? 00:31
timotimo one sec 00:33
MasterDuke sure 00:34
timotimo going through the debugserver signaling and state management code 00:35
that was a bit hairy to get right already in the first place ;)
and now it's been months
so normally the debugserver sets the gc_status to have the MVMSuspendState_SUSPEND_REQUEST 00:36
that causes the "check if we should gc" and "mark thread blocked" pieces of code to react to that suspend request
and we call MVM_gc_mark_thread_blocked, possibly just to set the right values? 00:37
OK, then the gc_status has to be set to MVMGCStatus_UNABLE | MVMSuspendState_SUSPENDED 00:38
when that's set, the debugserver will dare do stuff
but if you continue running the thread that has these values set, it will probably get quite a bit confused
whether you connect to the debugservre before or after doesn't matter, i don't think 00:39
MasterDuke sadly i'm going to need a refresher on how to use the debugserver 00:41
timotimo github.com/edumentab/p6-app-moarvm-debug - part of the beta use instructions should help you 00:42
i might go to bed rather soon
though you can skip steps 7 through 9
MasterDuke ok, so gdb the build command with a --debug-port and --debug-suspend added> 00:45
?
timotimo right
MasterDuke run until my nqp::asec breakpoint, then what? 00:46
timotimo right, only that thread is stopped now? 00:47
oh, this is breaking during building rakudo?
in that case you'll want to have a separate perl6 so you can run the debugger client
MasterDuke i have a system perl6 00:48
timotimo good 00:49
you'll want to have App::MoarVM::Debugger installed 00:50
er
App::MoarVM::Debug
important to know that most commands take an argument for which thread to apply to 00:56
but you can use "assume thread X" to no longer have to write those out
that makes things nicer usually
"all lex THREADNUM" is a good thing to start
oh
what i haven't been considering
the debugserver doesn't do locals, and in nqp code, a whole lot of things are lowered to locals 00:57
things being lexicals
MasterDuke `===SORRY!=== Missing serialize REPR function for REPR VMException (BOOTException)`, maybe my system perl6 is too old? 00:58
timotimo oh, you may have to disable tests in zef when trying to install the debugger or its library
MasterDuke 2018.03 00:59
i didn't actually install anything, just running with a bunch of -I
timotimo oh, i think that ought to work
do you have Terminal::ANSIColor, too?
perhaps the conditional loading of that is b0rken
MasterDuke ah, that fixed it 01:04
`Connecting to MoarVM remote on localhost port 9999 success!`
timotimo filed an issue
MasterDuke hm, but my gdb session doesn't seem to be doing anything 01:05
timotimo "help" is a good command to try in the repl
right, there is no integration between the debugserver and gdb
MasterDuke well, i mean it doesn't seem to have actually started building rakudo 01:06
timotimo oh, haha 01:07
MasterDuke oh, do i need to send a `resume` or something like that from the debug server?
timotimo --debug-suspend means it starts suspended
so you'll ... yes
sorry about that
MasterDuke heh, now it's going
though the debug server printed a "False" 01:08
timotimo probably meaningless debug prints left over 01:11
yes, indeed, it prints out the return value of $remote.resume
which is a "did it work" response
github.com/MoarVM/MoarVM/blob/mast...rotocol.md - since the moar-remote isn't a terribly thick layer on top of the debug protocol, this document could help you get an intuition of what you can do 01:12
you'll only need to look at the Message Types section
there's two env vars that'll let you get a lot more verbosity out of the debugserver on the moarvm side of things, MDS_PROTOCOL and MDS_NETWORK, MDS stands for Moar Debug Spam 01:13
the network one is very spammy and not very useful
i'll head to bed; i hope you can figure something out
MasterDuke do the thread numbers in the debug server map to the thread numbers gdb says?
timotimo umm
i think they map to something inside the tc or maybe the thread object 01:14
MasterDuke ah, ok
timotimo check debugserver.c 's function send_thread_info
right, i can see that the id it sends belongs to the MVMThread object 01:15
which you can reach from the tc, too
tc->thread_object
no
tc->thread_obj
good night, good luck! 01:16
MasterDuke thanks, later... 01:21
timotimo: i got distracted and didn't get to do much debugging, but this seems to say that `$op` is fine 03:23
Frame 1 - optimize_for_range (gen/moar/Perl6-Optimizer.nqp:2278) - handle: 86 03:24
55 Perl6::Optimizer self concrete
88 QAST::Op $callee concrete
89 QAST::Op $op concrete
hm, well maybe it can be concrete and an NQPMu at the same time... 03:25
timotimo: some info about 89 gist.github.com/MasterDuke17/91c58...5994973fc6 03:29
04:22 MasterDuke left 05:53 [Tux] left 06:07 [Tux] joined, p6bannerbot sets mode: +v [Tux] 06:20 patrickb joined, p6bannerbot sets mode: +v patrickb, brrt joined 06:21 p6bannerbot sets mode: +v brrt 06:44 jsimonet left 07:47 lizmat joined 07:48 p6bannerbot sets mode: +v lizmat
lizmat Files=1251, Tests=76080, 340 wallclock secs (15.69 usr 5.46 sys + 2389.12 cusr 229.34 csys = 2639.61 CPU) 07:48
brrt \o 07:57
08:28 Ven` joined 08:29 p6bannerbot sets mode: +v Ven` 08:30 robertle joined 08:31 p6bannerbot sets mode: +v robertle 08:40 Ven` left 08:42 Ven` joined 08:43 p6bannerbot sets mode: +v Ven`
|Tux| MoarVM oops: Unsupported unsigned cast 8 -> 4 08:55
Rakudo version 2018.08-84-g78bebc7ae - MoarVM version 2018.08-47-g891d5c02e
csv-parser22.018 - 22.405
csv-test-xs-200.424 - 0.444
test8.630 - 8.990
test-t2.085 - 2.164
test-t --race0.897 - 0.922
test-t-2036.587 - 37.303
test-t-20 --race11.923 - 12.378
08:58
Those unsupported casts are all in Inline::Perl5. I however have to make a remark there. It might not be new 08:59
brrt oh, huh, that's weird 09:00
|Tux| I upgraded my openSUSE from 42.3 to 15.0 (their versioning schedule sucks), and installed a complete new perl-5.28.0
brrt Tux, that's fairly sure my fault
|Tux| Biggest change from previous perl (5.26.2) is that I now built it with -Duseshrplib
brrt |Tux| fix coming up... 09:08
|Tux| :) 09:12
|Tux| is already relieved that the timings didn't go awry after the system update 09:13
brrt we may want a version bump after this version 09:14
09:15 yoleaux left 09:26 brrt left 09:36 Ven` left 09:41 brrt joined 09:42 p6bannerbot sets mode: +v brrt
Geth nqp: 02214c556f | (Zoffix Znet)++ | tools/build/MOAR_REVISION
[MoarVM Bump] Brings 11 commits

MoarVM bump brought: github.com/MoarVM/MoarVM/compare/2...7-g8c6088d 8c6088d [JIT] Be more strict about what is or isn't a reference 5fcef04 Merge remote-tracking branch 'jstuder/exprjit_09_05_18' 722f093 [JIT] Add down-cast operations to cast_unsigned_load_addr 985bf64 Fix error in objprimunsigned template ... (7 more lines)
10:30
¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...7-g8c6088d
rakudo: 0a2d8321cc | (Zoffix Znet)++ | tools/build/NQP_REVISION
[NQP Bump] Brings 2 commits

NQP bump brought: github.com/perl6/nqp/compare/2018....9-g02214c5 02214c5 [MoarVM Bump] Brings 11 commits ae3f01a [js] Partial shiftjs support
MoarVM bump brought: github.com/MoarVM/MoarVM/compare/2...7-g8c6088d ... (11 more lines)
¦ rakudo: version bump brought these changes: github.com/perl6/nqp/compare/2018....9-g02214c5
11:10 yoleaux joined 11:11 p6bannerbot sets mode: +v yoleaux
Geth roast: 1baf86664e | (Zoffix Znet)++ | S03-operators/div.t
[v6.d REVIEW] Test actual return type of `div`

Orig: github.com/perl6/roast/commit/7cf152404
11:17
roast: 3631536b36 | (Zoffix Znet)++ | S03-operators/div.t
[v6.d REVIEW] Precisify div tests

  - Test actual return values for Rats
  - Fully test returned failures and .handle them to avoid warnings
11:27
11:43 Ven` joined 11:44 p6bannerbot sets mode: +v Ven` 11:51 ZzZombo left 12:03 brrt left
Geth nqp: a880396e09 | (Paweł Murias)++ | src/vm/js/nqp-runtime/dbcs-codec.js
[js] Support replacing/throw exception when decoding/encoding windows-932
12:06
nqp: f652b66c65 | (Paweł Murias)++ | t/nqp/082-decode.t
Test encoding windows-932
12:12 ZzZombo joined, p6bannerbot sets mode: +v ZzZombo
lizmat and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2018/09/11/...of-damian/ 12:19
12:45 brrt joined 12:46 p6bannerbot sets mode: +v brrt 13:19 lucasb joined 13:20 p6bannerbot sets mode: +v lucasb 13:38 Ven` left 13:39 pmurias joined, p6bannerbot sets mode: +v pmurias 13:40 brrt left 13:50 Ven` joined, p6bannerbot sets mode: +v Ven`
AlexDaniel lizmat+++ 14:41
timotimo lizmat++ 14:45
jdv79 lizmat++ # very nice 14:52
14:53 undersightable6 left, undersightable6 joined, ChanServ sets mode: +v undersightable6 14:54 p6bannerbot sets mode: +v undersightable6 14:56 cognominal-p6 joined 14:57 p6bannerbot sets mode: +v cognominal-p6
releasable6 Next release in ≈4 days and ≈3 hours. 1 blocker. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 15:00
15:10 cognominal-p6 left, cognominal-p6 joined 15:11 p6bannerbot sets mode: +v cognominal-p6 15:12 lizmat left 15:13 lizmat joined 15:14 p6bannerbot sets mode: +v lizmat 15:30 patrickb left
Geth rakudo: d970c2b336 | (Elizabeth Mattijsen)++ | src/core/Range.pm6
Fix Range.reverse.count-only
15:57
AlexDaniel greppable6: \.fc 16:01
greppable6 AlexDaniel, 16 lines, 9 modules: gist.github.com/9a3d18ad34eb89b198...25bb4e6a85
16:02 brrt joined 16:03 p6bannerbot sets mode: +v brrt 16:28 travis-ci joined, p6bannerbot sets mode: +v travis-ci
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Fix Range.reverse.count-only' 16:28
travis-ci.org/rakudo/rakudo/builds/427272200 github.com/rakudo/rakudo/compare/0...70c2b336b4
16:28 travis-ci left 16:31 Ven` left 16:38 lucasb left 17:13 Zoffix joined, p6bannerbot sets mode: +v Zoffix
Zoffix lizmat: what do fixes like d970c2b336 fix? I wanted to write a test, but can't repro broken behaviour 17:14
c: HEAD~10,d970c2b336b with ^10 .reverse.iterator { .pull-one xx 10; say .count-only }
committable6 Zoffix, ¦HEAD~10,d970c2b: «0␤»
Zoffix That's with the assumption that R#2075 is to be resolved that .count/bool-only are illegal to call after receiving IterationEnd 17:15
synopsebot R#2075 [open]: github.com/rakudo/rakudo/issues/2075 [6.d review][@LARRY] Meaning of `.bool-only`/`.count-only` after receiving IterationEnd ?
Zoffix Ah 17:16
lizmat: nevermind. It needs to be 11 pulls, not 10, even with R#2075 resolved that way :)
And then I see the bug
well, the bug I wanted to cover
17:17 Zoffix left 17:22 Zoffix joined, p6bannerbot sets mode: +v Zoffix
Zoffix Oh, wait no, at 11 pulls you get IterationEnd, and calling .count-bool is illegal 17:22
Well, illegal if we resolve 2075 that way, I mean 17:24
lizmat: is there a benefit to allowing count-only/bool-only after pulling IterationEnd? I see the downside: the cost of all those extra operations. 17:26
c: HEAD~10 ^10 .reverse.skip(10).elems.say
committable6 Zoffix, ¦HEAD~10: «0␤»
Zoffix s: ^10 .reverse.skip(10), 'iterator', \()
SourceBaby Zoffix, Sauce is at github.com/rakudo/rakudo/blob/d970...eq.pm6#L18
Zoffix s: ^10 .reverse.skip(10).iterator, 'count-only', \() 17:27
SourceBaby Zoffix, Sauce is at github.com/rakudo/rakudo/blob/d970...e.pm6#L192
Zoffix c: HEAD~100 my $i := ^10 .reverse.iterator; $i.pull-one xx 11; Seq.new($i).skip(-5).iterator.elems.say 17:30
committable6 Zoffix, ¦HEAD~100: «1␤»
Zoffix c: HEAD~100 ^10 .reverse.skip(11).skip(-5).elems.say 17:32
committable6 Zoffix, ¦HEAD~100: «0␤»
Zoffix Well, penultimate one is almost a bug (when written right, it gives -1), but you could make an argument that making a new Seq from an exhausted iterator is illegal.
And R#2075 can be rephrased: "Exhauster of the iterator must ensure the iterator is not given for consumtion to anything else" 17:34
synopsebot R#2075 [open]: github.com/rakudo/rakudo/issues/2075 [6.d review][@LARRY] Meaning of `.bool-only`/`.count-only` after receiving IterationEnd ?
Zoffix And making a new seq, calls to .bool-only/.count-only, all fall under that category
And we don't have to do extra work in these methods to keep track of whether the iterator has been exhausted
Geth roast: d4a2e89304 | (Zoffix Znet)++ | packages/Test/Util.pm6
Remove after-IterationEnd iter opt tests

Don't put contested behaviour into propspec. Removing until R#2075 github.com/rakudo/rakudo/issues/2075 is resolved
17:46
synopsebot R#2075 [open]: github.com/rakudo/rakudo/issues/2075 [6.d review][@LARRY] Meaning of `.bool-only`/`.count-only` after receiving IterationEnd ?
roast: zoffixznet++ created pull request #470:
Cover more iterator opt tests
17:48
17:48 brrt left
Geth roast: 09f561314f | (Zoffix Znet)++ | MISC/bug-coverage.t
Cover more iterator opt tests

Covers bugs fixed by
  github.com/rakudo/rakudo/commit/64ddacab8f
  github.com/rakudo/rakudo/commit/9738dfbf21
  github.com/rakudo/rakudo/commit/d1e80dfe28
  github.com/rakudo/rakudo/commit/9ff1736761
Merge blocked by R#2075 github.com/rakudo/rakudo/issues/2075 as some of the opt methods return incorrect values after IterationEnd
17:48
roast: c1c3453746 | (Zoffix Znet)++ (committed using GitHub Web editor) | MISC/bug-coverage.t
Merge pull request #470 from perl6/moaaar-iterator-cover

Cover more iterator opt tests
AlexDaniel well, good news is that I'm working on Toaster upgrade 17:51
and bonus good (or bad?) news is that it requires some refactoring of Whateverable 17:52
wow Whateverable codebase turned into quite some shite over the time 17:53
for those wondering what and why, I want it to automatically run bisectable across all 1000+ modules so that I wouldn't have to 17:56
Zoffix 0.o 17:57
AlexDaniel++
Geth roast: 3d88f34a26 | (Zoffix Znet)++ | MISC/bug-coverage.t
Cover more iterator opts

For iterators fixed in commits in this range:
  github.com/rakudo/rakudo/compare/0...336b43dc25
17:59
Zoffix lizmat++ # weekly 18:02
18:03 Zoffix left
Geth rakudo: f5ebad98a1 | (Elizabeth Mattijsen)++ | src/core/metaops.pm6
Remove Predictiveness on 2 iterators

They appear to warrant further inspection for which I do not have the energy at the moment. Since this is just removing a optimization for probably very few real-life cases, I think this is fine for now.
18:45
lizmat So I just came up with the following idea: create a LazyIterator role that has a "method is-lazy(--> True) { }" 18:47
that would allow us to use typechecking to see if an iterator is lazy or not 18:48
including MMD
18:54 pmurias left 19:00 ggoebel_ left
b2gills I think that LazyIterator is good, as long as .is-lazy() is tested in the default case. 19:10
lizmat b2gills: such as ? 19:12
b2gills multi sub foo (LazyIterator) {…}; multi sub foo (Iterator $_){ if .is-lazy() {…} else {…} } 19:13
lizmat ah, ok 19:14
19:14 ggoebel_ joined 19:15 p6bannerbot sets mode: +v ggoebel_
lizmat FWIW, we would have to make sure that LazyIterator's "is-lazy" cannot be overridden by the consuming class 19:15
role Foo { method bar is unoverridable { } }; class A does Foo { method bar {} } # boom at compile time 19:16
b2gills Until `is unoverridable` exists, it could be internal only, or we could just say "don't do that" 19:17
Perhaps I should have said something when .count-only() was added, because I had the idea then about PredictiveIterator (though I didn't have a good name for it) 19:19
lizmat wish you had, then :-) 19:20
19:39 Ven` joined 19:40 p6bannerbot sets mode: +v Ven` 19:44 Ven` left 20:12 ggoebel_ left 20:27 ggoebel_ joined 20:28 p6bannerbot sets mode: +v ggoebel_
Geth rakudo: 57f89278e9 | (Elizabeth Mattijsen)++ | src/Perl6/World.nqp
Generalize "use isms" handling, add 'use isms <C++>'

Also allow "use isms" to (de-)activate all known isms. This does
  *not* yet actually de-activate the "new Foo" logic: this appears to
be a bit more troublesome.
21:54
21:55 Ven` joined 21:56 p6bannerbot sets mode: +v Ven` 21:59 Ven` left
lizmat sleep& 22:00
22:01 Ven` joined, p6bannerbot sets mode: +v Ven` 22:05 Ven` left 23:11 lizmat left