Geth roast: ddf48cf167 | (Zoffix Znet)++ | S03-operators/bit.t
Fudge some more bitshift proptests

RT#125466 rt.perl.org/Ticket/Display.html?id=125466
A few were already fudged for the same reason, but our native shift ops were commented out, so we never exercised the ones I'm fudging.
Our native-int bitshift ops perform overflow, while Int bitshift ops just keep going without any limit. The current proptests expect native candidates to produce Int values.		 00:12
synopsebot RT#125466 [open]: rt.perl.org/Ticket/Display.html?id=125466 [MATH][@LARRY] bitwise shift is inconsistent on int
rakudo: 29fdb75a30 | (Zoffix Znet)++ | src/core/Buf.pm6
HLLize items before testing for type in Buf

Fixes RT#125466: rt.perl.org/Ticket/Display.html?id=125466
Otherwise, `Buf.new: nqp::bitshift_i(1, 1)` ends up as a BOOTInt, fails the typecheck, and fails creation of the Buf.		 00:14
rakudo: 3d73597556 | (Zoffix Znet)++ | src/core/Int.pm6
Uncomment native bit shift candidates

All the things in RT#125466 [^1] are now fixed[^2], as far as I can tell, so unfudge these routines that were fudged as part of the workaround for that ticket.
  [1] rt.perl.org/Ticket/Display.html?id=125466
  [2] github.com/rakudo/rakudo/commit/29fdb75a30		 00:16
jnthn .tell AlexDaniel zstd 0.5.1, lrzip 0.621 00:17
yoleaux jnthn: I'll pass your message to AlexDaniel.
jnthn 'night o/
Geth roast: 32ac651062 | (Zoffix Znet)++ | S32-container/buf.t
Test native int ops with Buf creation

RT#128655: rt.perl.org/Ticket/Display.html?id=128655 Rakudo fix: github.com/rakudo/rakudo/commit/29fdb75a30
   github.com/rakudo/rakudo/commit/3d73597556		 00:22
synopsebot RT#128655 [open]: rt.perl.org/Ticket/Display.html?id=128655 [OPTIMIZER] Mixup in candidates through optimizer
Geth nqp: 90d9814c68 | (Zoffix Znet)++ | tools/build/MOAR_REVISION
[MoarVM Bump] Brings 6 commits

MoarVM bump brought: github.com/MoarVM/MoarVM/compare/2...7-g760b091 760b091 Fix for gigantic and wrong spesh time in profiles 6952c69 delete left-over line breaking compilation ffd7522 remove debugging output from profiler runs d7f4387 Enable box_i and box_s templates bfccd35 Bindlex needs a write barrier 9233d85 fix copy-pasto and re-enable bindattr_* optimizations		 00:33
Ā¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...7-g760b091
rakudo: a5a6c7786b | (Zoffix Znet)++ | tools/build/NQP_REVISION
[NQP Bump] Brings 4 commits

NQP bump brought: github.com/perl6/nqp/compare/2018....2-g90d9814 90d9814 [MoarVM Bump] Brings 6 commits 41b2f05 remove stray debug output from sql profile output bd2a8ac Note that filenofh doesn't really work on the JVM ef12d28 [JVM] Fix readfh with stdin ... (8 more lines)
Ā¦ rakudo: version bump brought these changes: github.com/perl6/nqp/compare/2018....2-g90d9814
travis-ci NQP build failed. Zoffix Znet '[MoarVM Bump] Brings 6 commits 00:57
travis-ci.org/perl6/nqp/builds/349090768 github.com/perl6/nqp/compare/41b2f...d9814c68a2
Rakudo build passed. Zoffix Znet 'HLLize items before testing for type in Buf 01:14
travis-ci.org/rakudo/rakudo/builds/349087163 github.com/rakudo/rakudo/compare/b...fdb75a3032
Rakudo build passed. Zoffix Znet '[NQP Bump] Brings 4 commits 01:42
travis-ci.org/rakudo/rakudo/builds/349090787 github.com/rakudo/rakudo/compare/3...a6c7786be5 01:43
Geth roast: 3972a53881 | usev6++ | S32-list/grep.t
[JVM] Skip newly added test
 06:56
samcv hmm did something change recently? my module is now failing tests as of 10 hours ago by CRON 07:45
on travis
Type check failed for return value; expected List but got Seq
travis-ci.org/samcv/URL-Find/build...tification
[Tux] Rakudo version 2018.02.1-118-ga5a6c7786 - MoarVM version 2018.02-27-g760b0913e
csv-ip5xs0.825 - 0.845
csv-ip5xs-207.766 - 7.791
csv-parser37.755 - 40.150
csv-test-xs-200.436 - 0.515
test9.261 - 9.493
test-t2.534 - 2.628
test-t --race1.100 - 1.176
test-t-2047.466 - 48.543
test-t-20 --race16.698 - 17.726
 07:48
samcv cron is set to run every 7 days and it was fine 7 days ago 07:50
Zoffix .tell samcv yes, .comb returns a Seq, not a List: github.com/samcv/URL-Find/blob/mas...nd.pm6#L32 It used to return a .Seq for all cases except for .comb(Regex:D), which was recently fixed 11:25
yoleaux Zoffix: I'll pass your message to samcv.
samcv .tell Zoffix thanks. just wanted to make sure it was not a regression 11:35
yoleaux 11:25Z <Zoffix> samcv: yes, .comb returns a Seq, not a List: github.com/samcv/URL-Find/blob/mas...nd.pm6#L32 It used to return a .Seq for all cases except for .comb(Regex:D), which was recently fixed
samcv: I'll pass your message to Zoffix.
samcv i'm going to just call .list on the result so that my function continues to return a List and make sure it works on past and new rakudo 11:37
Zoffix samcv: they may as well use .List instead. It's yet unclear whether .list will continue converting a Seq to a List 11:39
yoleaux 11:35Z <samcv> Zoffix: thanks. just wanted to make sure it was not a regression
Zoffix s/they/then/;
samcv ok thanks
Zoffix releasable6: status
releasable6 Zoffix, Next release in 12 days and ā‰ˆ7 hours. Blockers: github.com/rakudo/rakudo/issues?q=...%9A%A0%22. Changelog for this release was not started yet
Zoffix, Details: gist.github.com/bbf041ee51c1be4870...4e30c66ff5
Zoffix kicks off a toaster run to catch all the other .comb(Regex)s sooner 11:40
AlexDaniel Zoffix++
samcv that makes more sense to me, but i'd always seen people using .list and there are other methods maybe that are lowercase. or maybe i'm thinking subs
anyway i am off to bed
Zoffix could also use a p6lert during release, so those that use p6lert script get notified before upgrading.
samcv: .list would return the Array for Arrays and List for Lists and generally convert to List only non-Positionals, which Seq isn't so it make sense for .list to convert Seq to a List.... However, &list inconsistent in this and doesn't do the same. And trying to fix that has ramifications for slurpries IIRC R#1355 and R#1344 11:43
synopsebot R#1355 [open]: github.com/rakudo/rakudo/issues/1355 +@a/+a slurpies produce inconsistent results
R#1344 [open]: github.com/rakudo/rakudo/issues/1344 [@LARRY] What is a "list"?
Zoffix So depending on how those tickets are resolved, there's a chance that Seq.list would return a Seq
jnthn I'm pretty sure .list should not return a Seq, and I don't think it makes much sense for the sub form to do so, fwiw 11:44
Zoffix Agreed
pmurias github.com/rakudo/rakudo/blob/mast...P.nqp#L631 - if we have something like multi foo(:$a, :$b = $a*2) {} how is the scope of default_value supposed to be set correctly when doing a trial bind? 11:56
Zoffix: be aware that there is some on purpose incorrect code in the optimizer that treat and int and a constant as 2 ints 11:59
(when choosing a multi variants)
jnthn heh..."on purpose incorrect" 12:00
(If it didn't do that, `$a + 2` for a native int could never do a native addition, without having to write `$a + my int $ = 2` 12:01
Which nobody will (or will want to) write 12:02
I'd guess the default value closure is handled like where ones
lizmat Files=1236, Tests=76246, 315 wallclock secs (14.74 usr 5.30 sys + 2166.03 cusr 212.60 csys = 2398.67 CPU) 12:03
Zoffix pmurias: what do you mean? (I mean, why did you address that comment to me?)
pmurias Zoffix: I saw your question to TimToady 12:04
jnthn: thanks, where uses p6capturelexwhere I'll try using that with default values too 12:06
jnthn pmurias: Yeah, that's the one. I'm guessing it's not doing that at the moment, and we got away with it on MoarVM 'cus of signature lowering? 12:08
pmurias or maybe autoclosing magic
Zoffix: nqp::bitshift_r(..., ...) can't switch to an Int because it's something that always returns native ints 12:10
Zoffix You're taking my question too literally. It doesn't concern implementation of ops, but language behaviour. 12:21
(for those not seen my yesterdays question: how to resolve inconsistentcy between native int bit shift operators (that overflow) and Int candidates (that keep on trucking), especially given that due to autoboxing it can be hard to predict when you'd get which candidate; with my attempts yesterday erroneously getting the Int candidates with `my int @a = 42; @a[0] +>= -67; or something along those lines) 12:30
Geth roast: bf3f347e11 | (Zoffix Znet)++ | S32-io/io-path.t
Spec IO::Path.parent(Int)

Rakudo impl: github.com/rakudo/rakudo/commit/7b...dddcfc1190		 13:22
roast: 1b39fb200c | (Zoffix Znet)++ | S32-io/io-path.t
Spec IO::Path.parent(Int) with negative Ints
 13:24
rakudo/js: 6 commits pushed by pmurias++ 13:47
Zoffix It's a bad sign that after a successful toast of 2018.02, the toast on master doesn't look like it wants to proceed at all :} 14:18
Apparently just got stuck right after this point: github.com/zoffixznet/perl6-Toaste...er.pm6#L57 14:19
Zoffix tries re-starting it
k, running now 14:26
We still have the rakudoCI VM nine++ set up for us. We could shove a continuous toaster there. It might take ages, but I 14:27
'll take a couple runs a week over nothing any day
Kaiepi PufferBot, test 15:04
PufferBot [openbsd] Building Rakudo...
[openbsd] Build failed. 15:05
Kaiepi make: don't know how to make src/core/core_prologue.pm (prerequisite of: CORE.setting.moarvm)
Zoffix heh
Kaiepi should probably make it print build errors while it still can't build like this
Zoffix Kaiepi: a missing perl Configure.pl perhaps? That error sounds like it's not picking up recent change that changed .pm to .p6
*to .pm6
Kaiepi ah 15:06
Zoffix perl Configure.pl --gen-moar --gen-nqp --backends=moar; or something along those lines
Kaiepi there we go 15:14
Zoffix PufferBot: test 15:15
PufferBot [openbsd] Building Rakudo...
[openbsd] Build failed.
Kaiepi whoops
make: don't know how to make m-clean (prerequisite of: clean)
heh
PufferBot, test 15:16
PufferBot [openbsd] Building Rakudo...
[openbsd] Build failed.
Kaiepi bah i'll test it in another channel and bring it back once it's working
lizmat notable6: weekly 15:52
notable6 lizmat, 1 note: 2018-03-04T23:25:47Z <timotimo>: timo's first tpf grant report blog post wakelift.de/2018/03/05/delays-and-delights/
AlexDaniel reportable6: 2018-02-26T00:00:00Z 2018-03-05T00:00:00Z 15:53
reportable6 AlexDaniel, OK, working on it! This may take up to 40 seconds
Kaiepi PufferBot, test
PufferBot [openbsd] Building Rakudo...
reportable6 AlexDaniel, gist.github.com/98ecb58a1bae66e176...ba77844026 15:54
AlexDaniel removes spamā€¦
reportable6: 2018-02-26T00:00:00Z 2018-03-05T00:00:00Z 15:55
reportable6 AlexDaniel, OK, working on it! This may take up to 40 seconds
PufferBot [openbsd] Compiling successful! Testing...
AlexDaniel reportable6: 2018-02-26T00:00:00Z 2018-03-05T00:00:00Z
reportable6 AlexDaniel, OK, working on it! This may take up to 40 seconds
AlexDaniel Kaiepi: that's pretty cool! 15:56
Kaiepi thanks :)
AlexDaniel notable6: release Try using PufferBot ā€“ ā€œPufferBot, testā€
notable6 AlexDaniel, Noted!
PufferBot [openbsd] Tests passed!
reportable6 AlexDaniel, gist.github.com/6d582b213cbe5d5d19...b02d8c02ba
Kaiepi Zoffix, --gen-moar --moar-option=--has-libffi did the trick
AlexDaniel reportable6: 2018-02-01T00:00:00Z 2018-03-01T00:00:00Z 15:57
reportable6 AlexDaniel, OK, working on it! This may take up to 40 seconds
AlexDaniel xD
reportable6: 2018-02-01T00:00:00Z 2018-03-01T00:00:00Z
reportable6 AlexDaniel, OK, working on it! This may take up to 40 seconds
AlexDaniel, gist.github.com/cb867b9743412f7bdb...b67b63753a 15:58
AlexDaniel reportable6: 2018-02-01T00:00:00Z 2018-03-01T00:00:00Z 15:59
reportable6 AlexDaniel, OK, working on it! This may take up to 40 seconds
AlexDaniel xD
reportable6: 2018-02-01T00:00:00Z 2018-03-01T00:00:00Z
reportable6 AlexDaniel, OK, working on it! This may take up to 40 seconds
AlexDaniel, gist.github.com/94ce789ebbbe52866a...3b4d262ee4 16:00
timotimo AlexDaniel: wanna do it in whateverable, though? :D
AlexDaniel timotimo: wanna fix a SEGV though? :P :P
lizmat: fwiw everything added to github.com/rakudo/rakudo/wiki/Ticket-updates 16:01
timotimo i can have a quick look 16:02
AlexDaniel timotimo: Follow the steps here: github.com/perl6/whateverable/wiki/Installation
lizmat timotimo: fwiw, doing a profile on 'say (^Inf).hyper.grep( *.is-prime )[1000]' segfaults for me without anything written 16:03
AlexDaniel timotimo: except the last one (sake debug:unicodable), instead just run: t/evalable.t
timotimo: evalable will die with signal 11 (SEGV) half way through its tests
Zoffix bisect: say (^Inf).hyper.grep( *.is-prime )[1000]
timotimo lizmat: strange, you're right. i tried it with the json_fast race test 16:04
bisectable6 Zoffix, Bisecting by exit signal (old=2015.12 new=a5a6c77). Old exit signal: 1 (SIGHUP)
lizmat Zoffix: it only segfaults when trying to write the report
Zoffix Ah, profile. There's also M#813
synopsebot M#813 [open]: github.com/MoarVM/MoarVM/issues/813 SEGV when attempting to --profile-stage=optimize the
lizmat I was reading wakelift.de/2018/03/05/delays-and-delights/ and wanted to check things out :-) 16:05
bisectable6 Zoffix, bisect log: gist.github.com/87334f54dc07034352...5608fdfc8f
Zoffix, (2017-10-16) github.com/rakudo/rakudo/commit/23...06bf507c55
timotimo you're right to hold me accountable for what i claimed in the post
it looks a little like memory corruption, tbh. more than half the time i get const_iX NYI", but the crashing code is just const_s called with a extremely high string index, and const_s is just next to the ones that would NYI 16:11
huh, i can clearly see that the const_s instruction with the bogus gigantic string index is in the CORE.setting.moarvm file; maybe the instruction pointer got off the rails? 16:23
lizmat well, if that's the case, it may actually be a MoarVM issue instead of a profiler issue ? 16:24
timotimo could be
though it'd probably have been a profiler issue inside the moarvm codebase either way 16:25
lizmat timotimo: wrt " it'll spend a majority of its time sleeping in between ticks. This shows up very prominently in the Routines list"
I've replaced the sleep() in the scheduler thread by an nqp::sleep()
so that should not show up by itself at all anymore
timotimo ah, nice 16:27
but the including sub will probably take sleep's place :)
so, uh, what i'm wondering is: why is it even running thread 4 any more in the first place?
if i sleep 0.05 after the code you pasted the profile gets written without trouble 16:29
lizmat interesting
lemme double check
timotimo: indeed
timotimo so the other thread is continuing past the run time of the main program - which is not a big surprise - and that somehow gets very unhappy while the profiler is dumping its data 16:30
lizmat timotimo: the profile states that is-prime is called 8192 times 16:31
that is incorrect, and it feels oddly powered of 2 16:32
the threadpool scheduler taking 20% of CPU, feels like a lot 16:33
timotimo adding a breakpoint to MVM_bigint_is_prime i do get more than a few thousand calls 16:35
how many should it be? 16:36
i see it called 8187 times, oddly enough 16:37
perhaps is_prime has special cases for very low numbers built in?
Zoffix s: 42, 'is-prime', \() 16:38
SourceBaby Zoffix, Sauce is at github.com/rakudo/rakudo/blob/a5a6...t.pm6#L140
timotimo or maybe i just set the breakpoint a tiny bit too late
oh, probably because it segfaulted early-ish 16:39
dogbert17 timotimo: when valgrinding lizmat's example I sometimes get an invalid read here: github.com/MoarVM/MoarVM/blob/mast...hll.c#L178
lizmat timotimo: actually, the 8192 possibly makes sense, since it *is* a multiple of 64, which is the batch size
Zoffix m: ^Inf .grep(*.is-prime)[1000].say
camelia 5===SORRY!5=== Error while compiling <tmp>
Missing infix inside []
at <tmp>:1
------> 3^Inf .grep(*.is-prime)[7ā051000].say
expecting any of:
bracketed infix
infix
infix stopper
Zoffix m: (^Inf).grep(*.is-prime)[1000].say
camelia 7927 16:40
timotimo wow, that's a tiny batch size
lizmat it's the default
timotimo ok, not every job is as fast as is_prime
lizmat indeed...
timotimo i imagine the ThreadPoolScheduler time you see is from waiting for jobs to come in 16:41
Zoffix On my 2-core box, I get 8012 calls 16:42
m: say 7927+64*2
camelia 8055
Zoffix m: say 7927+64
camelia 7991
Zoffix shrugs
timotimo i suppose it comes down to how early it can cut off the other active jobs when the slice says "i've got enough now, thanks"
Zoffix Ah
Ah yeah, if I add `await Promise.in(2)` before the end, I get 8192 calls 16:43
I was measuring with `perl6 -e '(^Inf).hyper.grep({say "called"; .is-prime})[1000]; await Promise.in(2)' | wc -l` BTW
m: say 7927+64*4
camelia 8183
Zoffix ZofBot: close enough! 16:44
ZofBot Zoffix, (when choosing a multi variants)
timotimo what's with the extremely deep recursion between ThreadPoolScheduler.pm:232 and ThreadPoolScheduler.pm:60? 16:46
oh, continuations
wow, that is disgusting. is this real? 16:47
jnthn timotimo: Wonder if it's got a frame leak situation a tad like gather/take once had... 16:49
timotimo i hope it's only an artifact of how the profiler handles continuations, which i haven't looked into at all yet
but damn, this call graph is *deep*
jnthn oh, that is also very possible
timotimo i can't even zoom out far enough in chrome to get a good overview of the thing
jnthn I hope it's that :) 16:50
timotimo hack.p6c.org/~timo/very_deep_recurs...om_TPS.png 16:51
that's the generals hape
to the left of that one is a similar one, but it's extremely flat instead of a steep incline 16:52
if the stack actually reflects the call graph, we should be able to get very big stack traces from inside the thing that's mapped by the hyper seq, right? 16:54
m: say Backtrace.new.full 16:55
camelia in code at SETTING::src/core/Backtrace.pm6 line 85
in method new at SETTING::src/core/Backtrace.pm6 line 85
in block <unit> at <tmp> line 1
timotimo m: (^Inf).hyper.grep({ Backtrace.new.full.say if rand < 0.001; .is-prime})[1000];
camelia in code at SETTING::src/core/Backtrace.pm6 line 85
in method new at SETTING::src/core/Backtrace.pm6 line 85
in block at <tmp> line 1
in block at SETTING::src/core/Rakudo/Internals/HyperRaceSharedImpl.pm6 line 15
in block at SETTIā€¦
timotimo yeah, i see it on the stack trace, too 16:56
270, 232, 238, 60, 238, 60, 238, 60, 238, 60, ...
and then Promise.pm6 line 249, HyperPipeline.pm6 lines 69, 71, 72
jdv79 so cancelling a promise is not something that will ever be possible? 17:42
in the forking world i can always kill a kid. it can be useful. 17:43
for instance, i fire off a bunch of tasks that are related but are wholly unnecessary if one fails. so if 1 fails i want to just drop the others on the floor. 17:45
timotimo we'll at some point have a mechanism to cause an exception in another thread to happen 17:47
jdv79 wouldn't i want that on the promise - not hte thread? 18:07
for example a promise may not have been scheduled before i want to abort it 18:08
lizmat jdv79: I assume you mean a Promise.in / Promise.at, right ?
a Promise object by itself doesn't know anything about threads or anything, right ? 18:09
timotimo right, the promise returned by Start would have to have a "kill" method mixed in or something similar 18:25
the reason why a thread would have to have an exception delivered to it is because these tasks are run by a ThreadPoolScheduler and any cooperation with outside code would have to be in the user's code 18:26
so by passing an exception to the thread that's currently running the task you're interested in, it'd unwind the stack up to an exception handler that belongs to the thread pool scheduler itself 18:27
so it can handle all the necessary work
jdv79 would it be enough to just give the vow back to usercode to it could call break? i'm just guessing. 18:31
timotimo no, that'll only cause an exception when the task is finished because it'll try to keep a promise that's already been broken 18:32
but at that point you win nothing from it aborting
jdv79 but this kill method would attempt to unsched a task that has yet to be run or just mark it to throw when scheduled? 18:34
timotimo i imagine the kill method would be invoked on the $*SCHEDULER which could then decide how to proceed; either the task hasn't been taken yet, then it has to prevent it from being taken in the future - that's not possible with just the Channel it uses, so there'd have to be something extra - and if it has already been taken it would have to force the Thread that is currently working on that task to throw an 18:36
exception the next time it is in there
the underlying mechanism for exception passing would be that at the same place it looks to see if a GC run should be started it'll realize it's supposed to throw an exception and do that 18:37
but if we're not careful, a whole lot more operations than so far would be able to throw exceptions, which requires extra care from the jit 18:38
TimToady waves at all you hard workers from KāŹ»anapali 18:59
yoleaux 3 Mar 2018 06:24Z <Zoffix> TimToady: a proposal for some tweaks to Rationals to fix a number of bugs including the issue of some Rats being >64-bit denominators, if you wanted to review: github.com/rakudo/rakudo/blob/mast...tionals.md
00:11Z <Zoffix> TimToady: what's your opinion, should `use nqp; dd nqp::bitshiftr_i(-9223372036854775808, -64)` overflow and return -9223372036854775808 or switch to an Int instead -170141183460469231731687303715884105728? Right now we have this inconsistency between Int and int candidates, but I'm leaning towards: people might wants overflowing stuff
00:40Z <Zoffix> TimToady: I changed my leaning; I think both HLL and native should behave the same as autoboxing makes stuff too unpredictable as can be seen here: irclog.perlgeek.de/perl6/2018-03-05#i_15883977 19:00
TimToady thinks people who are writing crypto codes want ways to keep everything native, if we make it default the other way 19:01
jdv79 timotimo: sounds cool 19:04
TimToady on Rats, if we automatically graduate Rats to FatRats, what's the point of the distinction, which is there specifically to avoid performance degradation? 19:05
Zoffix TimToady: they'd upgrade to FatRat only on literals and Rat.new. All other operations will remain downgrading them to a Num. The logic is: if someone creates an original object by giving us an $x amount of precision, we keep it all 19:10
and in val too (will make FatRatStr)
TimToady okay, I didn't get that from the doc, but maybe my eyes are still crossed
Zoffix m: say 1.111111111111111111111 19:11
camelia 1.111111111111111111111
Zoffix hm, on my box on 2018.01 that prints 1.11111111111111111604544 19:12
m: say 1.111111111111111111111111111111111111111111111
camelia 1.11111111111111110716365146799944341182708740234
TimToady with your proposal, can we have a literal that rounds to Rat when used as a Rat, but has FatRat precision when used with a FatRat? 19:13
Zoffix There we go. Basically, right now ^ we create Rat objects with denominators larger than 64bits (the same is with `<42/24> Rat literals, <42/24 > RatStrs, and with Rat.new). And only such cases would get promoted to FatRat.
TimToady: used as a Rat how?
TimToady or does adding precision on the literals suddenly throw the user into FatRat-land? 19:14
Zoffix Suddenly throw FatRat land. 4.9999999999999999999 <= Rat; 4.99999999999999999999 <= FatRat. Logic being: $user gave us this much precision, thus assume they want to keep it all.
Also: <499999999999999999999/100000000000000000000> == FatRat; 499999999999999999999/100000000000000000000 == Num 19:16
And Rat.new: 499999999999999999999, 100000000000000000000 == FatRat
ZofBot: FartRat
ZofBot Zoffix, When people die they are sometimes put into coffins, which means that they donā€™t mix with the earth for a very long time until the wood of the coffin rots
TimToady might want to think about dying on that by default, and requiring a use fatrat or so to turn it on
well, the powers-that-be are attempting to drag me off sightseeing, so I'd better keep the peace... 19:17
Zoffix I considered that, but feels like that's creating more unpredictability thatn making a FatRat instead: github.com/rakudo/rakudo/blob/mast...#reasoning 19:18
Like would this throw? Rat.new: 48112959837032048697, 48112959837082048697
Or this? Rat.new: 680564733841876926926749214863536422912, 1361129467683753853853498429727072845824
The first one would actually throw, that's a 64+bit denominator, but the second one won't because after reduction the denominator is <64bit 19:19
TimToady but this still feels wrongish to me; I want to be able to put a value of Ļ€ or e into the setting that is allomorphic on Rat or FatRat 19:20
forcing it to FatRat seems to defeat that
Zoffix So we're talking about a possible MaybeRat type? A non-infectious FatRat?
TimToady well, that's what the Str part of RatStr was supposed to be 19:21
Zoffix OK. I'll reevaluate that proposal in terms of making RatStr a non-infectious FatRat. 19:22
by end of weekend and see if anything bad comes out from that
dogbert17 does the profiler work correctly with nqp programs? 19:23
tried profiling Zoffix prime program and the results are: Interpreted Frames 95.65% (1254), Specialized Frames 1.6% (21), JIT-Compiled Frames 2.75% (36) 19:25
the numbers for Specializes and JITted frames feels a bit low, is that to be expected? 19:27
Zoffix dogbert17: how many frames are there for timo's HLL version? Maybe it's ignoring all the NQP ops and those 1254 interpreted frames might be "out of 12000000000 frames" actually used by the HLL program 19:40
dogbert17 where's timos code then 19:41
lizmat notable6: weekly 19:42
notable6 lizmat, 1 note: 2018-03-04T23:25:47Z <timotimo>: timo's first tpf grant report blog post wakelift.de/2018/03/05/delays-and-delights/
Zoffix dogbert17: I think it's this file. And the comments on this file say how to get the missing program; or you can just copy the primes list from my program and paste it into that one instead github.com/perl6/perl6-examples/co...#r27920150 19:44
dogbert17 Zoffix: cool
Zoffix: the profile failed: const_n32 NYI in sub calc_S at scratch.pl6 line 32 20:03
Zoffix No idea what that's from 20:04
(well, MVM_OP_const_n32, but where in the program that's for *shrug*) 20:07
dogbert17 timotimo probably knows 20:08
Geth roast: 9ba8d28315 | usev6++ | 2 files
[JVM] Unfudge passing tests for eof on stdin

Fixed with github.com/perl6/nqp/commit/ef12d28506 Compare RT #131393.		 20:13
synopsebot RT#131393 [new]: rt.perl.org/Ticket/Display.html?id=131393 [JVM] When reading from stdin, eof is not respected
Geth rakudo: 90303c1e3e | usev6++ | t/spectest.data
Revert "Don't run S19-command-line/repl.t on JVM"

This reverts commit f0eb2450284be7cfa7606c3394e9befbff39406b.
Running S19-command-line/repl.t doesn't hang anymore.		 20:16
lizmat notable6: reset weekly 20:32
notable6 lizmat, Noted!
lizmat notable6: weekly reset
notable6 lizmat, Noted!
lizmat notable6: help
notable6 lizmat, Like this: notable6: weekly rakudo is now 10x faster # See wiki for more examples: github.com/perl6/whateverable/wiki/Notable
AlexDaniel hahaha
Zoffix notable6: reset help 20:33
notable6 Zoffix, Noted!
Zoffix notable6: help
notable6 Zoffix, Like this: notable6: weekly rakudo is now 10x faster # See wiki for more examples: github.com/perl6/whateverable/wiki/Notable
lizmat notable6: clear weekly
notable6 lizmat, Moved existing notes to ā€œweekly_2018-03-05T20:33:06Zā€
AlexDaniel slaps notable6 # stupid bot
Zoffix notable6: clear help
notable6 Zoffix, No notes for ā€œhelpā€
Zoffix heh
AlexDaniel notable6: reset
notable6 AlexDaniel, 2 notes: 2018-03-05T20:32:27Z <lizmat>: weekly ; 2018-03-05T20:33:01Z <Zoffix>: help
lizmat and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2018/03/05/...atic-perl/ 20:36
Zoffix wooo 20:40
hehe neat. Went looking for a quote to post in a place and found one by Larry: www.brainyquote.com/quotes/larry_wall_141510 20:43
"The three chief virtues of a programmer are: Laziness, Impatience and Hubris."ā€”Larry Wall
oh wow, there's a whole bunch of them on that site: www.brainyquote.com/authors/larry_wall 20:44
timotimo dogbert17: we never generate that opcode so far, so something else is going wrong 20:46
Zoffix lizmat++ # good weekly 20:48
jnthn Aww, the week I write two new modules, there's not a new modules section in the weekly :P 20:58
lizmat jnthn: there hasn't been a new modules section for several months now 20:59
jnthn Aww :)
lizmat before, it was easy to do a diff on the ecosystem
now, with uploads to CPAN, it's not so easy anymore :-(
jnthn ah, makes sense
I did tweet my talk slides from Brno also; maybe something for next week :-) 21:01
lizmat jnthn: ah, good point: I guess someone forgot to retweet those on the Perl 6 News feed :-(
i guess I need to "follow" you as well, then 21:02
but for now, I'm going to take an early night
jnthn :)
Nice weekly, anyways
lizmat++
Rest well
travis-ci Rakudo build failed. usev6 'Revert "Don't run S19-command-line/repl.t on JVM" 21:06
travis-ci.org/rakudo/rakudo/builds/349485971 github.com/rakudo/rakudo/compare/a...303c1e3ec9
timotimo anyway, yeah, the stack keeps growing; i slashed the probability of writing the stacktrace by 10 and made it run until 100_000 instead of 1000 primes are found 21:53
Zoffix dogbert17: so I got to the box that had *my* HLL version of that program: gist.github.com/zoffixznet/eff8a1d...4d980667e8 with 15 iterations (instead of 24), the HLL version has 192738 total frames, 37779 interpreted, while nqp version has 1152 total frames with 1103 interpreted. So my hypothesis was true: despite nqp version having majority frames non-JITed, it just has a lot fewer 22:40
frames to begin with
dogbert17: tho I would've hoped pure-NQP version would be faster than perl 5, not 86% slower, so I'm hoping there are some ops there that aren't JITTED :) 23:00

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!