AlexDaniel if anybody knows about some serious issue, please don't hesitate to tell me about it :) 00:44
Geth nqp/profiler_new_spesh_semantics: 0a8693b683 | (Timo Paulssen)++ | src/vm/moar/HLL/Backend.nqp
put gc sequence number in gcs table
 00:55
nqp/profiler_new_spesh_semantics: 90d6b697ea | (Timo Paulssen)++ | src/vm/moar/HLL/Backend.nqp
remove accidentally left-over line
nqp/profiler_new_spesh_semantics: c1261f6438 | (Timo Paulssen)++ | src/vm/moar/profiler/template.html
teach old html frontend a bit about multiple threads

still missing: call graph for the rest of the threads, GC tab ought to display a bit of information about all the other participants (if applicable), and there's a bug causing incredible amounts of promoted bytes in the GC list.
Also, a decision on whether "inclusive" time is allowed to go past 100% or if everything should be scaled down to "total cpu time".
Zoffix Reminder that there's a proposal for nailing shut the holes in the spec for type constraints on constants: github.com/rakudo/rakudo/blob/mast...-constants 01:57
Gon'a start implementing it like in a week maybe
AlexDaniel Zoffix: I looked through it and it makes sense. I was kinda hoping that the proposal would make “my Numeric constant @foo” do something useful, so that's somewhat a bummer… but it doesn't work right now anyway so that's ok 02:55
hmm… actually I was thinking about something like constant Numeric @foo ?
but that expectation is probably wrong :)
🤷
Zoffix m: constant Numeric is export(foo => my Str constant x is export("ehehehe" => "/ahaha".IO.e) = "meows") = 42; say Numeric 02:58
AlexDaniel Zoffix: right, it'd have to decide what it was after the fact…
camelia 42
Zoffix that's a lot of stuff before `=` for it to decide about :)
AlexDaniel I see :) 02:59
well, the way I had it in my mind would make it die on ⏏export, because that's definitely a numeric constant named “is” :D 03:01
.oO( goddamn sigilless things )
Zoffix greppable6: my\s+\S+\s+constant 03:03
greppable6 Zoffix, 7 lines, 6 modules: gist.github.com/29444ba3abec40f823...f8c03a928f
Zoffix We actually have been parsing it that way for ages, but the parsed stuff ain't hooked up to anything
I mean in the `my Type constant foo` 03:04
m: my int32 constant LC_ALL = "so much int, so wow"; say LC_ALL
camelia so much int, so wow
AlexDaniel yea, and I guess my stupid question was asked before :P
Zoffix Yeah, 10 days ago: github.com/rakudo/rakudo/issues/15...-364393338 03:05
AlexDaniel heh
oh, github.com/rakudo/rakudo/issues/1541 should be closed I think 03:06
Zoffix closed 03:07
(tests already exists that cover yesterday's bug in MoarVM)
AlexDaniel it says that the r-j is still failing on that test though, but the commit message claims that the reason is different 03:09
okay then
who can edit rakudo.org/how-to-get-rakudo/ ?
because RT#132877 seems to be a LHF as long as you have access to edit that page… 03:10
synopsebot RT#132877 [new]: rt.perl.org/Ticket/Display.html?id=132877 Confusing link to 'zef'
AlexDaniel reportable6: 2018-02-12T00:00:00Z 2018-02-19T00:00:00Z 03:11
reportable6 AlexDaniel, OK, working on it! This may take up to 40 seconds
AlexDaniel, gist.github.com/a23d46247a4aed8a42...e96e69485b 03:12
AlexDaniel weekly: reportable: gist.github.com/a23d46247a4aed8a42...e96e69485b 03:14
notable6 AlexDaniel, Noted!
AlexDaniel weekly:
notable6 AlexDaniel, 1 note: 2018-02-19T03:14:40Z <AlexDaniel>: reportable: gist.github.com/a23d46247a4aed8a42...e96e69485b
AlexDaniel propdump: C℃℉ 03:15
unicodable6 AlexDaniel, gist.github.com/00ef9a5359fcd3ffa6...1a93bba0bb
AlexDaniel Zoffix: regarding your last tweet, both ℃ and ℉ have “East_Asian_Width” property set to A (Amiguous), so the editor (or the font) doesn't really have any specific way to render it… 03:18
it's really sad :)
but you also seem to have a font issue and these chars are rendered neither as fullwidth or halfwidth 03:19
Geth roast: a066ace2dc | usev6++ | 2 files
[JVM] Remove (most) fudges for R#1541
 06:46
synopsebot R#1541 [closed]: github.com/rakudo/rakudo/issues/1541 [IO][JVM] [JVM] IO::Handle.eof always reports true for zero-size and /proc files
[Tux] Rakudo version 2018.01-209-gf74890550 - MoarVM version 2018.01-97-g22d2db5e0
csv-ip5xs0.821 - 0.836
csv-ip5xs-207.531 - 7.765
csv-parser12.333 - 12.551
csv-test-xs-200.452 - 0.460
test9.418 - 9.434
test-t2.641 - 2.651
test-t --race1.106 - 1.109
test-t-2047.140 - 47.591
test-t-20 --race16.466 - 16.594
 08:02
Zoffix hm, updated to latest and greatest rakudo couple of days ago on perl6.party and now Linode emailed me "Your Linode, leliana, has exceeded the notification threshold (90) for CPU Usage by averaging 108.4% for the last 2 hours." 16:17
htop says buggable is to blame 16:18
and it's not even connected no more :o
k, maybe the high CPU use was due to it just trying to reconnect in a loop 16:19
AlexDaniel yeah, I doubt there's any issue, but I can upgrade rakudo for whateverables 16:48
bisectable6: uptime
bisectable6 AlexDaniel, No! It wasn't me! It was the one-armed man! Backtrace: gist.github.com/02ccaa67babb649eda...0dd98152e4 16:49
AlexDaniel uhh… that's a precomp issue I think 16:50
so nvm that, I've seen that before
bisectable6: uptime 16:52
bisectable6 AlexDaniel, 13 seconds, 194.136719MiB maxrss. This is Rakudo version 2018.01-209-gf74890550 built on MoarVM version 2018.01-97-g22d2db5e0 implementing Perl 6.c.
Zoffix bisectable6: uptime 17:11
bisectable6 Zoffix, 19 minutes and 35 seconds, 222.136719MiB maxrss. This is Rakudo version 2018.01-209-gf74890550 built on MoarVM version 2018.01-97-g22d2db5e0 implementing Perl 6.c.
Zoffix bisectable6: uptime 17:12
bisectable6 Zoffix, 20 minutes and 36 seconds, 233.9375MiB maxrss. This is Rakudo version 2018.01-209-gf74890550 built on MoarVM version 2018.01-97-g22d2db5e0 implementing Perl 6.c.
AlexDaniel ehhh… 17:13
Zoffix hah
So it lasted for 4 bisects :)
AlexDaniel This was reported in November, by the way: github.com/rakudo/rakudo/issues/1259 17:14
Zoffix committable6: uptime 17:15
committable6 Zoffix, 22 minutes and 48 seconds, 192.566406MiB maxrss. This is Rakudo version 2018.01-209-gf74890550 built on MoarVM version 2018.01-97-g22d2db5e0 implementing Perl 6.c.
Zoffix c: HEAD Numeric.new + 0
AlexDaniel according to tests only bisectable6 does that
committable6 Zoffix, ¦HEAD(f748905): «WARNINGS for /tmp/7cWlIWVDYZ:␤«timed out after 10 seconds» «exit signal = SIGKILL (9)»»
Zoffix committable6: uptime
committable6 Zoffix, 23 minutes and 32 seconds, 193.664063MiB maxrss. This is Rakudo version 2018.01-209-gf74890550 built on MoarVM version 2018.01-97-g22d2db5e0 implementing Perl 6.c.
Zoffix neat
AlexDaniel c: all say 42 17:16
committable6 AlexDaniel, ¦all (49 commits): «42␤»
AlexDaniel, ¦all (49 commits): «42␤» 17:17
AlexDaniel committable6: uptime
committable6 AlexDaniel, 25 minutes and 18 seconds, 220.609375MiB maxrss. This is Rakudo version 2018.01-209-gf74890550 built on MoarVM version 2018.01-97-g22d2db5e0 implementing Perl 6.c.
timotimo hm, the uptime message could include stats on what it's been doing since it was last started 17:20
dogbert17 m: my @z = (^3).map: {$_}; my $x = { :a(1) :b(@z) } 17:29
camelia ===SORRY!===
Unknown QAST node type NQPMu
dogbert17 m: react { Supply.interval(1).tap: -> { .say } } 17:33
camelia ( no output )
dogbert17 m: react { Supply.interval(1).tap: -> { .say } }
camelia ( no output )
Zoffix The last one makes sense, it's not whenevering anything, so react exits right away 17:35
And the first one is part of RT#127023 17:36
synopsebot RT#127023 [new]: rt.perl.org/Ticket/Display.html?id=127023 [BOOTSTRAP] error message “Unknown QAST node type NQPMu” ( (:w :h<1>) )
Zoffix m: react { Supply.interval(1).tap: -> { .say } }; say "buh-bye"
camelia buh-bye
Unhandled exception in code scheduled on thread 4
Zoffix :o
m: react { Supply.interval(1).tap: -> { .say } }; say "buh-bye"
camelia Unhandled exception in code scheduled on thread 4
buh-bye
Zoffix Guessing the "expected 0 args but got 1"
AlexDaniel that seems to be correct also
Zoffix m: react { Supply.interval(1).tap: { .say } }; say "buh-bye" 17:37
camelia 0
buh-bye
Zoffix yup
AlexDaniel hm… but why can't it print the backtrace or something?
Zoffix I'm guessing same reason why Proc::Async.stdout/err.tap can't 17:41
Remember, jnthn++ said it's better to use react instead for that reason
AlexDaniel m: start react { whenever Supply.interval(1) -> { .say } }; sleep 2; say 42 17:43
camelia 42
AlexDaniel huh…
dogbert17 Zoffix: didn't you fix RT #126423 recently? 17:44
synopsebot RT#126423 [open]: rt.perl.org/Ticket/Display.html?id=126423 [BUG] `if` block with slurpy parameter does not receive argument
dogbert17 is looking at old RT's 17:45
also the react thingy is RT #127098 17:46
synopsebot RT#127098 [new]: rt.perl.org/Ticket/Display.html?id=127098 [BUG] Unhandled exception in code scheduled on thread 4
dogbert17 m: if 42 -> *@a { say @a } # seems to work now 17:47
camelia [42]
Zoffix dogbert17: yeah, but it was a differnt ticket
dogbert17 so two for the price of one then :-) 17:48
Zoffix: ok, so you fixed RT #105872 with commit github.com/rakudo/rakudo/commit/ef1d22f4c1 17:56
synopsebot RT#105872 [resolved]: rt.perl.org/Ticket/Display.html?id=105872 [BUG] 42, 44, 22 -> *@a { say @a.perl }
dogbert17 I'll close 126423 then 17:58
AlexDaniel dogbert17: I think this is more accurate: [ef1d22f4][dfb6d951][59556c70][4b7113fa][00af9ce2] 17:59
dogbert17 I wrote down the commits mentioned by Zoffix in 105872 18:01
AlexDaniel: unless you decide to reopen it I guess it can be added to the changelog for 2018.02 18:03
AlexDaniel that's exactly from the changelog :) 18:04
dogbert17 :-) 18:06
Geth rakudo: f1b7cc4d99 | usev6++ | 2 files
[JVM] Avoid NullPointerException in nqp::clone

Some discussion here: irclog.perlgeek.de/perl6-dev/2018-...i_15831894		 18:44
roast: 27cccfd284 | usev6++ | 2 files
[JVM] Fudge some failing tests
 19:24
lizmat notable6: weekly 21:03
notable6 lizmat, 1 note: 2018-02-19T03:14:40Z <AlexDaniel>: reportable: gist.github.com/a23d46247a4aed8a42...e96e69485b
lizmat .tell Zoffix re twitter.com/zoffix/status/96378954...54976?s=20 , afaik subst-mutate was originally implemented by TimToady in a time when there was no Nil yet. the exact reasoning for subst-mutate, apart from optimization purposes, is also unclear to me 22:03
yoleaux lizmat: I'll pass your message to Zoffix.
dogbert17 bisect: await do for ^1000 -> $i { start { "A".match: /(“A”) { say "BOOM: $i) ", $0 if not $0 }/ } } 22:26
bisectable6 dogbert17, On both starting points (old=2015.12 new=f1b7cc4) the exit code is 0 and the output is identical as well
dogbert17, Output on both points: «»
pmurias lizmat: how is subst-mutate faster?
lizmat well, 22:29
subst can be faster because the object is guaranteed to be immutable
if .subst would provide a left value, you could not make that assumption 22:30
(is what I remember from a similar discussion many years ago :-)
pmurias what is a left value? 22:33
subst-mutate seems useful for something like if $msg.subst-mutate(/excellent/, 'double plus good') { warn "Obsolete vocabulary detected" } 22:36
lizmat a left value is something you can assign to
my $a; # left value 22:37
42; # not a left value
pmurias ahh an lvalue ;) 22:38
lizmat: I think it was subst/subst-rw in that discussion 22:41
lizmat ah, hmmm... 22:45
jnthn Hm, wasn't part of the reason for substr-mutate to have something to compile s/// into?
I may be confusing that with adding S/// so we had an operator form of .subst though
Though I guess the symmetry is kinda nice 22:46
lizmat clearly is not recovered enough to take part in technical discussions 22:47
pmurias yeah, subst-mutate looks very strongly like something that carries over the Perl 5 idiom over 22:48
g'night & 22:49
Zoffix . 23:03
yoleaux 22:03Z <lizmat> Zoffix: re twitter.com/zoffix/status/96378954...54976?s=20 , afaik subst-mutate was originally implemented by TimToady in a time when there was no Nil yet. the exact reasoning for subst-mutate, apart from optimization purposes, is also unclear to me
lizmat Zoffix: please also see discussion with pmurias just now
Zoffix lizmat: but .subst would not provide an lvalue; that's .='s job
lizmat "/me clearly is not recovered enough to take part in technical discussions" 23:04
Zoffix And IIRC s/// doesn't even use .subst-mutate; it uses .match and !APPLY-MATCHES or sometyhing
Yeah, .match github.com/rakudo/rakudo/blob/mast....nqp#L8346 and Str!APPLY-MATCHES github.com/rakudo/rakudo/blob/mast....nqp#L8383 23:06
Geth rakudo/post-release: 4e5c908d4d | (Zoffix Znet)++ (committed using GitHub Web editor) | src/core/Str.pm
Add comment Str!APPLY-MATCHES is used...

  ...by stuff outside the class		 23:09
lizmat And another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2018/02/19/...6ya-giris/ 23:29
Zoffix lizmat++ # good weekly 23:36
.ask jnthn are Exceptions resumable? I seem to recall a conversation that they weren't (only control exceptions were) and something about removing .resumable method or something). Currently Exception.resume is documented as putting control back to place throwage; wonder if that's accurate: docs.perl6.org/type/Exception#method_resume 23:51
yoleaux Zoffix: I'll pass your message to jnthn.
jnthn Zoffix: They may be. 23:52
yoleaux 23:51Z <Zoffix> jnthn: are Exceptions resumable? I seem to recall a conversation that they weren't (only control exceptions were) and something about removing .resumable method or something). Currently Exception.resume is documented as putting control back to place throwage; wonder if that's accurate: docs.perl6.org/type/Exception#method_resume
jnthn Zoffix: Any exception you throw yourself with die will be.
Zoffix: For obvious reasons, those thrown from the guts when it gets into an "impossible to continue" situation cannot be
And even then, not all exceptions you can resume make sense to do so (e.g. you might well just resume only to run straight into a more guts-y exception because the initial one was guarding something) 23:53
Zoffix m: sub foo { 0 or die; say "meow" }; try foo; bar $!; sub bar { $^v.resume }
camelia This exception is not resumable
in sub bar at <tmp> line 1
in block <unit> at <tmp> line 1
jnthn That error is a tad off 23:54
Zoffix m: die; say "meow"; CATCH { default { .resume } }
camelia meow
jnthn You *must* resume inside of the CATCH or CONTROL handler
Outside of that, it's too late
We may be able to distinguish those cases and give different errors cheaply. 23:55
(e.g. "You can no longer reusme this exception")
Zoffix Filed as github.com/rakudo/rakudo/issues/1544
jnthn Thanks
I mean, it's not wrong in that the exception is - by that point - not resumable. But it'd be nice to see if we can give a hint when it once would have been. 23:56
fwiw, the reason for the limitation is that CATCH handlers run in the dynamic scope of the exception and *then* the stack is unwound
So a resume is just "don't unwind" 23:57

Powered by Cro and the Raku® Programming Language.

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

Thank you!