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:13 epony left 00:28 epony joined 00:32 fake_space_whale left 01:00 lizmat joined, lizmat left 03:03 vrurg left 04:54 statisfiable6 left, greppable6 left, nativecallable6 left, unicodable6 left, bloatable6 left, notable6 left, undersightable6 left, squashable6 left, releasable6 left, committable6 left, evalable6 left, shareable6 left, bisectable6 left, coverable6 left, quotable6 left, reportable6 left, benchable6 left, greppable6 joined, reportable6 joined, nativecallable6 joined, committable6 joined 04:55 benchable6 joined, evalable6 joined, releasable6 joined, bisectable6 joined, ChanServ sets mode: +v bisectable6 04:56 unicodable6 joined, ChanServ sets mode: +v unicodable6, coverable6 joined 04:57 undersightable6 joined, ChanServ sets mode: +v undersightable6, statisfiable6 joined, notable6 joined, quotable6 joined, ChanServ sets mode: +v quotable6 04:58 bloatable6 joined, squashable6 joined 04:59 shareable6 joined 05:22 robertle left 06:52 ufobat__ joined 06:55 ufobat_ left 07:20 epony left 07:26 Geth joined 07:27 epony joined 07:52 [TuxCM] left 07:57 lizmat joined 08:12 [TuxCM] joined 08:20 robertle joined 08:32 fake_space_whale joined 09:19 lizmat_ joined
[TuxCM] Rakudo version 2019.03.1-236-g9ce179292 - MoarVM version 2019.03-99-g2e9df2ad8
csv-ip5xs0.686 - 0.719
csv-ip5xs-205.811 - 6.119
csv-parser21.902 - 22.447
csv-test-xs-200.429 - 0.431
test7.387 - 7.553
test-t1.638 - 1.654
test-t --race0.757 - 0.778
test-t-2028.124 - 28.233
test-t-20 --race8.769 - 9.037
 09:20
09:22 lizmat left 09:27 lizmat_ is now known as lizmat 10:25 pmurias joined 11:06 pmurias left 11:19 lizmat left 11:43 pmurias joined 12:08 lizmat joined 12:51 pmurias left 12:53 pmurias joined 12:54 lucasb joined
pmurias //e/exit 13:18
13:18 pmurias left 13:23 vrurg joined
lizmat I was thinking on making a module that would parse a spesh-log and allow for some object oriented introspection of it 13:23
does such a thing already exist? timotimo jnthn brrt ^^^ 13:24
jnthn No, though also that format wasn't really designed with easy parsing in mind :)
Though it's relatively regular 13:25
Just any parser will be fragile as we add new things to it 13:26
lizmat that's why I was thinking of adding it to the "lib" directory 13:29
so we can keep it inn sync, similar to Telemetry
jnthn I'd be more inclined to have a way to request it in a sensible format :)
lizmat in the long run, I'd agree 13:30
jnthn I did discuss that with timotimo recently; was thinking of a profiler option where the hottest code gets its specializations dumped too
lizmat I was thinking of something like "snapper", which would by default dump all of the nqp::ops that didn't get JITted after the program has run 13:31
jnthn (I want that, of course, to be able to get them included alongside the code in Comma, and potentially for some analyses to suggest how to improve performance :)) 13:33
13:33 squashable6 left 13:35 AlexDani` joined
jnthn It occurs to me that we could, if we had a structured form of the data, even then expose an op where you can query the specializations 13:36
For a given code objet
c 13:37
13:37 squashable6 joined, ChanServ sets mode: +v squashable6 13:41 AlexDani` is now known as AlexDaniel, AlexDaniel left, AlexDaniel joined
AlexDaniel kawaii: what's the situation with the release? I'm out of the loop 13:45
kawaii AlexDaniel: I've notified the MoarVM guys and awaiting a release from them. 13:46
AlexDaniel releasable6: status 13:47
releasable6 AlexDaniel, Next release will happen when it's ready. 4 blockers. 61 out of 236 commits logged (āš  51 warnings)
AlexDaniel, Details: gist.github.com/85b139dca0c79365eb...c289fd9c60
kawaii I didn't want to keep annoying them though.
AlexDaniel kawaii: what about github.com/rakudo/rakudo/issues/2856 ?
lizmat AlexDaniel: nine is looking at that afaik... 13:48
kawaii So I'm waiting on both a MoarVM release and a fix for 2856 currently. 13:49
AlexDaniel are we positive that 2856 is not a Moar issue?
kawaii Looks like it could be actually. 13:50
jnthn It's not
AlexDaniel ok
jnthn It's almost certainly due to my change to fix a BUILDALL performance issue, whereby constructing an object with no attributes was inexplicably slower :)
I was about to settle down to fix it 10 minutes ago, then got stolen to look at an urgent $dayjob project issue 13:51
lizmat meanwhile, I've removed the BLOCKER tag, as nine doesn't consider it a blocker for release anymore
jnthn I suspect it'll be a single line of code to fix, just need some spare moments to figure out which line :)
kawaii If it's a trivial fix then I don't mind waiting for it alongside the Moar release. 13:52
jnthn I hope $urgent-thing will not take me long, so I should get to it soon.
AlexDaniel lizmat: maybe you can check 2758? Looks like a non-issue if nobody else is complaining, maybe it's already fixed or something? 13:53
kawaii Good luck with $urgent-thing
lizmat AlexDaniel: looking 13:56
ugexe if i try to --profile zef it works unless i use sqlite e.g. --profile-filename=demo.sql 14:20
MoarVM panic: Internal error: zeroed target thread ID in work pass
sqlite profile *does* work if i do MVM_JIT_DISABLE=1 14:34
moarperf, when given the sqlite file or not, just shows a blank page. the only hint is `[ERROR] 403 /js/main.js - ::1` 14:39
jnthn ugexe: Haven't worked on moarperf, but at a guess, main.js would be generated by some kind of frontend build 14:46
Maybe that failed somehow?
14:46 hankache joined
ugexe jnthn: yeah thats it 14:47
segfaults generating the flame graph, (or whatever is after it) 14:53
timotimo yeah, did "npm run build" succeed? 15:03
ugexe yeah i got past that. now im trying to view the data in moarperf, but it just says 'Hold on...'. I can click through to whatever the second tab is (Routines?), but clicking back to Overview segfaults 15:06
gist.github.com/ugexe/814d52de9693...b84f1131cf
timotimo huh. i wonder what's up with that; you could remove the flame graph part of moarperf 15:07
oh, but the flamegraph succeeded
it isn't even big
ugexe [OK] 200 /flamegraph-for/0 - ::1
Segmentation fault: 11
so its not always the closed socket thing it complains about in the gist either 15:08
timotimo did you try getting a backtrace with gdb? 15:10
15:12 robertle left
ugexe no gdb on latest osx 15:13
or rather you can get it, but it doesnt work
timotimo oh crap 15:14
lldb at least?
ugexe perl6-lldm-m just does the initial output from lldb/gdb and never runs the script 15:20
gist.github.com/ugexe/0621096386c4...9047ac1c76 15:21
timotimo maybe it doesn't understand the "run" command? 15:25
i mean the "when you start, immediately run" commandline flag 15:26
i've gotta head out now, sorry!
15:32 hankache left 15:37 lizmat left 15:39 lizmat joined 15:43 hankache joined
hankache hello #perl6 15:49
can someone have a look at this issue: github.com/rakudo/rakudo/issues/2782 15:51
<3
lizmat bisectable6: class A { has $.a; }; class B { has $.b }; class C is B is A { }; say C.new(:a(1), :b(2)) 15:54
bisectable6 lizmat, Bisecting by output (old=2015.12 new=cb691da) because on both starting points the exit code is 0
lizmat, bisect log: gist.github.com/2bf89d7b2cc83eecd9...0360f36043 15:55
lizmat, (2017-10-07) github.com/rakudo/rakudo/commit/16...81067d3f8c
jnthn Oops :) 15:56
yoleaux 15:20Z <guifa> jnthn: sadly I ended up having to go with the custom associative class (re GH question). I managed to find a way to do the backtracking to work well enough to warn my users though the calling file check isnā€™t the prettiest (one liner, but still). But itā€™s actually given me some cool other ideas for instantiating some other class objects along the way so itā€™s not for naught
jnthn Hm, but that still doesn't answer much
AlexDaniel hmm almost 10000 gists on whateverable account 15:57
jnthn Does it even need MI I wonder... 15:58
AlexDaniel I'll be slapped for that eventuallyā€¦
jnthn "# Take the first "super"class's BUILDALLPLAN if possible" - the code below that is wrong 15:59
Pushed a fix for github.com/rakudo/rakudo/issues/2856 in case anything else would be broken by it 16:02
hankache: Testing a fix for that issue
hankache jnthn++ 16:03
jnthn The fix works, just need spectest to finish before I push 16:04
m: use Test; class A { has $.a; }; class B { has $.b }; class C is B is A { }; given C.new(:a(1), :b(2)) { is .a, 1, "Initialization of attributes in multiple inheritance works (1)"; is .b, 2, "Initializatino of attributes in multiple inheritance works (2)"; } 16:05
evalable6 (exit code 1) not ok 1 - Initialization of attributes in multiple inheritance works (1)
# ā€¦
jnthn, Full output: gist.github.com/9c6df881dd249a31d3...81ed8be84c
jnthn hankache: Pushed fix, along with a spectest to cover it :) 16:09
hankache jnthn <3 16:10
nine ugexe: github.com/rakudo/rakudo/commit/50...0674e963b1 16:21
Good thing the release did not actually happen before the PTS 16:22
16:24 vrurg left 16:25 vrurg joined, vrurg left 16:29 vrurg joined, fake_space_whale left
AlexDaniel rakudo in debian is currently stuck at 2018.12 anyway 16:34
16:37 hankache left, travis-ci joined
travis-ci Rakudo build errored. Jonathan Worthington 'Merge pull request #2858 from patzim/moar-option-doc 16:37
travis-ci.org/rakudo/rakudo/builds/525013693 github.com/rakudo/rakudo/compare/c...2dc965b97e
16:37 travis-ci left, hankache joined
timotimo i'm back; ugexe, did lldb give you anything? 16:43
ugexe changing `lldb $DIR/perl6-m -- "$@"` to `lldb -o run $DIR/perl6-m -- "$@"` makes it run 16:50
and naturally it doesn't segfault when using lldb
timotimo ah, of course :( 16:51
i know that feeling
ugexe gist.github.com/ugexe/94d6061dcb2f...0440cd993d (this is related to generating the profile) 17:00
subsequent runs worked (mind you I mentioned earlier i couldnt run that without doing MVM_JIT_DISABLE=1
timotimo ah dang 17:01
ugexe that command seems to always segfault if i delete .precomp first 17:04
timotimo which one? the one that gives "profiler lost sequence" otherwise? 17:06
ugexe yeah. but i only got that "profiler lost sequence" once 17:07
after that it ran
(it wasnt precompiling during that "profiler los sequence" fwiw)
gist.github.com/ugexe/6c246e488490...4e887cfeb7 17:08
i just got profiler lost sequence again
but it didnt dump a stack trace like the previous one
timotimo "profiler lost sequence" happens when it leaves more frames than it entered, iirc 17:09
ugexe oh wait
that error *is* different
MoarVM panic: Profiler lost sequence in continuation control
additional "in continuation control" 17:10
AlexDaniel jnthn: github.com/perl6/problem-solving/issues/18 is an interesting one. Is it about the language or is it about the compiler? 17:23
ugexe given `-lwc` what if you want a multi MAIN(:$lwc) 17:26
means you cant have `multi MAIN(:$lwc, :$l, :$w, :$c) 17:27
that is inconsistent with a normal subroutine. inconsistent behavior like that should go in external modules.
17:37 [TuxCM] left 17:39 lizmat left 18:01 [TuxCM] joined 18:03 hankache left 18:05 hankache joined
bartolin_ since Geth isn't here: I've just committed github.com/rakudo/rakudo/commit/07b4f74381 as a workaround for the JVM backend 18:19
18:47 robertle joined 19:17 hankache left
jnthn AlexDaniel: Well, about language in the sense that it's about how MAIN's signatures are interpreted as command line arguments 19:38
AlexDaniel: Trouble is, I'm not sure one semantics for mapping those can please everybody.
AlexDaniel: Like, if I'm building something in Perl 6, I just use whatever is made easy by the way MAIN's argument handling works :) 19:39
AlexDaniel jnthn: wellā€¦ the broken ones we have right now only please those who'd be fine with any semanticsā€¦ 19:40
jnthn But if folks are wanting a matching implementation of something that already exists and need to match its interface, as the person originally opening that issue does, then it's trickier...
AlexDaniel: The other general design principle was that we were meant to 1) transform command line arguments to a Capture, 2) let multi-dispatch take care of the rest 19:41
Rather than going and looking through all the signatures and doing ad-hoc matching up of stuff
AlexDaniel hm
jnthn So for -lwc you'd have to make a policy that -abc always becomes (:a, :b, :c), for example 19:42
And so could never match a sub MAIN(:$abc) { } 19:43
AlexDaniel that sounds about right, actually. There are tools that do that, but I'm not sure if that's the norm 19:44
jnthn Whereas today it does
But if we change *that*, then anyone who wants the -foo ==> :foo style will be disappointed :)
And as ugexe++ points out, if you try and do too much magic then you create ambiguous cases 19:45
So what we maybe want is 1) refined default semantics for arguments ==> capture, 2) a way to load a module that that replaces that arguments ==> capture transform for different schemes 19:46
Maybe shipping one or two alternatives that we feel are common 19:47
I'd quite like to retain the "first you transform, then you dispatch" approach, though. In that folks have a hope fo debugging it: at least they can get hold of the Capture and see which side is misbehaving :) 19:48
19:52 Kaypie joined, Kaiepi left
nine +1 for transform, then dispatch 20:15
jnthn: is it OK for a DESTROY submethod to create a new reference to the to-be destroyed object, thereby resurrecting it? 20:19
timotimo yes
nine \o/
timotimo the semantics you get are "DESTROY will only be called once"
so if your finalizer resurrects the object, it will not become finalized again
nine oh
That's unfortunate 20:20
timotimo spawn a new object that hangs off of the object with its own DESTROY :)
then you can pass the "got destroyed" message "back up", while the original object is being kept alive only by the sentinel object
nine That....could work. But also sounds quite expensive
timotimo how often do you expect this object to die? :D 20:21
nine Think of a Perl 6 subclass of a Perl 5 object. It consists of a P5 object and a matching P6 object. At any time the only reference to the combined thing may be in P5 code or P6 code. What I need the magic in the destructor for is to check if the counter part is still alive and abort destruction. 20:23
If the object in question is just passed around a lot, the destructor could run quite often 20:24
timotimo resurrection won't push the object back to the nursery 20:25
so it'll be until the next full collection before the object would be considered dead again
oh, you mean the newly created object i was refering to
... have a pool of objects that do nothing but wait until they go to the old generation, at which point they may be used :D 20:26
nine Of course if you have a better idea for cutting this circle, I'm all ears :)
timotimo i do not :| 20:27
nine Actually, a third object may be the solution. 20:28
We declar the P6 part of the whole to be the master. It's life time decides the life time of both. The P5 side of the program will only see yet another P5 object that encapsulates the P6 object (which wraps the P5 object core). 20:29
Seems like even after removing the build-date, there's one more reproducibility issue left. 20:32
This one's only affecting rakudo, not nqp 20:33
SC deps seem to be in a different order for one 20:43
21:11 lizmat joined 22:20 lizmat left 23:47 MasterDuke left 23:53 lucasb left

Powered by Cro and the RakuĀ® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!