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.
[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
pmurias //e/exit 13:18
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
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
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?
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
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!
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
AlexDaniel rakudo in debian is currently stuck at 2018.12 anyway 16:34
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
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.
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
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
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

Powered by Cro and the Raku® Programming Language.

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

Thank you!