lizmat Files=1306, Tests=111232, 212 wallclock secs (28.67 usr 8.13 sys + 2995.42 cusr 271.41 csys = 3303.63 CPU) 09:40
lizmat sanity check: the difference between a native `num` and a Num is the boxing, nothing else, right ? 10:42
MasterDuke that's my understanding 10:44
nine Looks like rakudo requires $*SCHEDULER to support the undocumented queue method 11:43
jnthn Yes, which must return something of repr ConcBlockingQueue 12:05
nine Shouldn't this be added to Scheduler then? 12:06
Even our very own CurrentThreadScheduler seems to be somewhat useless due to the missing .queue 12:07
jnthn Probably, though I also wonder if there's any way to satisfy the requirement without resorting to nqp::shift on the queue... 12:08
So we probably need to provide an impl of that REPR that can be used also
nine Btw. am I the only one who gets a feeling of... I don't know, emptyness? after making a breakthrough in or finishing a large chunk of work? 12:09
Geth_ rakudo: f987cdb0ba | (Elizabeth Mattijsen)++ | src/core.c/Num.pm6
Make Num.Rat about 25% faster

  - using more nqp::ops
  - moving lexicals out of a hot loop
This also makes `now` about 25% faster, as most of its creation effort is spent in converting nqp::time_n to a Rat. Addresses R#3620 somewhat.
linkable6 R#3620 [open]: github.com/rakudo/rakudo/issues/3620 Speed up Instant/now by optimizing for recent times
lizmat nine: I think that is quite common. I remember that vividly from having done the final exam at high school :-) 12:13
lizmat we don't have pre-compilation for scripts, do we? www.reddit.com/r/rakulang/comments...ed_script/ 12:51
jnthn No 12:54
Thus the "put things into a module" pattern
lizmat right
[Coke] Is there a technical blocker for adding that? Might we do it eventually? 12:57
jnthn I think it'd be possible 13:03
nine IIRC pmurias++ got pretty far on that 13:08
MasterDuke i think he had a list of failing spectests somewhere 13:16
[Coke] wonder if there's a ticket for that. 13:25
lizmat yeah, running the spectest with scripts pre-compiled was an interesting excercise
Xliff m: my $vol = 1; constant VOLUME_STEPS = 2; $vol = ($vol + $vs).round * VOLUME_STEPS / VOLUME_STEPS; 14:19
camelia 5===SORRY!5=== Error while compiling <tmp>
Variable '$vs' is not declared
at <tmp>:1
------> 3nstant VOLUME_STEPS = 2; $vol = ($vol + 7⏏5$vs).round * VOLUME_STEPS / VOLUME_STEPS
Xliff m: my ($vol, $vs) = 1 xx 2; constant VOLUME_STEPS = 2; $vol = ($vol + $vs).round * VOLUME_STEPS / VOLUME_STEPS;
camelia ( no output )
Xliff Why is the line I just pasted giving me "Unrecognized regex metacharacter ; (must be quoted to match literally)" 14:22
MasterDuke Xliff: don't think you just pasted anything? did it start with a '/'? might have been interpreted as an IRC command 14:26
[Coke] ... you have more code you're not showing, I assume?
I tried the last line with VOLUME_STEPS that I see here and it runs.
(just like camelia does.)
lizmat notable6: weekly 17:24
notable6 lizmat, 7 notes: gist.github.com/05397a8f97d90fc149...46f3909f56
pmurias [Coke]: re precompilation for script as far as I remember for rakudo.js it mostly took working around for things we relied on the rakudo executable to set up 17:44
[Coke]: but it's something that is fairly important 17:45
lizmat notable6: weekly reset 18:47
notable6 lizmat, Moved existing notes to “weekly_2020-04-13T18:47:48Z”
Geth_ rakudo: usev6++ created pull request #3623:
Add missing label support for some loop constructs
19:21
lizmat and another Rakudo Weekly News hits the Net: rakudoweekly.blog/2020/04/13/2020-...-surprise/ 19:25
Geth_ roast: usev6++ created pull request #635:
Test usage of labels within nested loops
20:39
bartolin_ lizmat: while looking at the support for labels in 'from-loop' I've noticed this line: github.com/rakudo/rakudo/blob/f987....pm6#L250. (I wondered whether this might need a tweak wrt labels, too) 20:45
But: isn't Slip.from-loop() wrong? If I'm not mistaken there is only Seq.from-loop() 20:46
do you have an idea for code that would trigger this elsif branch?
lizmat m: Slip.form-loop
camelia No such method 'form-loop' for invocant of type 'Slip'
in block <unit> at <tmp> line 1
lizmat m: Slip.from-loop 20:47
camelia No such method 'from-loop' for invocant of type 'Slip'
in block <unit> at <tmp> line 1
lizmat which implies that path is never taken
bartolin_ yeah, that's what I thought, too. tests needed ;)
should I open an issue? (I'll call it a day soon-ish ...) 20:48
lizmat yes, please make an issue
lizmat seeing that that code has been in there since Sep 2015, I'm pretty sure we can just take it out 20:49
as there has been no test breakage and no ecosystem breakage because of it
bartolin_ github.com/rakudo/rakudo/issues/3624 ## for the Slip.from-loop thing 20:59
lizmat bartolin_++ 21:00
bartolin_ the last days were an interesting excursion into unknown territory (Actions.nqp and Rakudo::Iterator). Unfortunately, I didn't find the source of the 'labeled next without loop construct' on the JVM backend I originally went out to fix. But it should be easier to find with the things I've learned. 21:09
ggoebel regarding precompilation of scripts... here is a link to the gsoc self-contained executable project summary: yakshavingcream.blogspot.com/2019/...view.html. They got as far as getting a basic script using a module to work. Which basically bundled the bytecode into the elf executable 21:21
Any idea how much startup time savings there could be with precompiled scripts? 21:23
Geth_ rakudo: 3aaca26a52 | (Elizabeth Mattijsen)++ | src/core.c/array_slice.pm6
Remove dead code

Probably fixes R#3624. This code was sitting there from before Christmas and did not cause any problems in core tests, roast or ecosystem tests.
21:24
linkable6 R#3624 [open]: github.com/rakudo/rakudo/issues/3624 Call to non-existing method Slip.from-loop in src/core.c/array_slice.pm6
lizmat ggoebel: completely depends on the size of the script 21:25
to give you an idea, parsing the complete setting takes about 64 seconds on my machine 21:26
yet, startup of raku is about 120 msecs 21:27
$ wc gen/moar/CORE.c.setting
70296 209498 2416876 gen/moar/CORE.c.setting
adjust for the size of your script :-) leaving that as an exercise to the reader 21:28
ggoebel pamplemouse was the handle of the gsoc coder 21:29
lizmat jnthn: would you know a piece of code with which I could test the behaviour of affinity / general worker threads ? 21:30
jnthn: I wonder if it is just a matter of tuning my $affinity-add-thresholds := nqp::list_i(0, 1, 5, 10, 20, 50, 100); 21:35
ggoebel script size is one factor... the number of modules and time it takes to load them (precompiled or not) is another. Is there enough overhead in loading precompiled modules, that would make bundling them in a self-contained executable a significant startup time win? Certainly someday someone will write something in Raku with as many module dependencies as Perl's Moose. 21:44
MasterDuke ggoebel: Xliff would be someone to talk to. their modules are quite large and have some large dependencies 21:46
timotimo i hope a rakuAST based approach to regex creation will make the MQTT module a bunch faster 22:14
MasterDuke think compiling rakudo itself will get much faster? 22:17
timotimo not necessarily 22:18
if the RakuAST is indeed more compact than the equivalent QAST, we'll save some time on garbage collection 22:19
MasterDuke i haven't been able to actually profile compiling CORE.c for probably over a year now 22:22
i didn't have enough ram for a while, but now it's just the problem with the profile not ending 22:24
hm, but there's some GC log that can be turned on, could it be used to figure out how much time is spend on gc? 22:25
timotimo telemeh can be used for that 22:26
it's a little bit of work tho 22:27
i wonder if the gc entries in the profiler can become unwiedily big during core.c compilation
since we really only append into a list during recording, it might be a good idea to zstd compress data at certain points 22:28
the MVMProfileGC entries are only 80 bytes, but for every type that got tossed out during that run there's also a 24 byte entry 22:34
jnthn lizmat: Create a Cro web application that just has some "hello world" handler (just the `cro stub` or Comma project for a Cro web app will do), then use `ab` to throw requests at it (something like `ab -n 10000 -c 100 localhost:20000/`) 22:49
Or replace `ab` with your preferred tool 22:50
timotimo i'm writing a small debug helper function for you MasterDuke 23:01
MasterDuke cool 23:02
timotimo i don't have enough free ram to compile a core setting with profiling right now 23:04
maybe i want to measure the call graph as well 23:05
MasterDuke i'm off to bed, look forward to trying it tomorrow 23:26
timotimo MasterDuke: just pushed a branch to moarvm 23:30
it's gc_measurement_debughelper
anyway, it does look like the GC entry list is an order of magnitude smaller than the call graph 23:42
hm, if there were a measurement for which nodes haven't been touched in a while, entire pieces of the call graph could be frozen into a zstd-compressed blob and unfrozen for read-out 23:45