00:22 hungrydonkey left 00:59 MasterDuke left 01:13 softmoth left 02:03 softmoth joined 02:25 softmoth_ joined 02:27 softmoth left 04:49 coverable6 left, bisectable6 left, unicodable6 left, quotable6 left, reportable6 left, evalable6 left, releasable6 left, nativecallable6 left, shareable6 left, sourceable6 left, squashable6 left, greppable6 left, linkable6 left, committable6 left, notable6 left, bloatable6 left, statisfiable6 left, benchable6 left, tellable6 left 04:50 greppable6 joined, unicodable6 joined, notable6 joined, statisfiable6 joined, benchable6 joined, linkable6 joined 04:51 evalable6 joined, tellable6 joined 04:52 bisectable6 joined, releasable6 joined, committable6 joined, bloatable6 joined, reportable6 joined, quotable6 joined, nativecallable6 joined, squashable6 joined, sourceable6 joined, shareable6 joined, coverable6 joined 05:02 softmoth__ joined, softmoth__ is now known as softmoth 05:05 softmoth_ left 05:45 softmoth left 06:14 hungrydonkey joined 07:15 MasterDuke joined 07:38 sena_kun joined 08:39 Altai-man_ joined 08:42 sena_kun left 09:06 hungrydonkey left 09:10 hungrydonkey joined 09:21 [TuxCM] joined
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
10:40 sena_kun joined
lizmat sanity check: the difference between a native `num` and a Num is the boxing, nothing else, right ? 10:42
10:42 Altai-man_ left 10:43 hungryd83 joined
MasterDuke that's my understanding 10:44
10:47 hungrydonkey left 11:35 hungryd83 left, hungrydonkey joined
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
12:39 Altai-man_ joined 12:42 sena_kun left
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 )
14:20 lucasb joined
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.)
14:41 sena_kun joined 14:42 Altai-man_ left 14:43 hungryd85 joined, hungrydonkey left 14:51 MasterDuke left 15:06 hungryd85 left 15:08 hungrydonkey joined 15:10 [TuxCM] left 15:22 [TuxCM] joined 15:32 MasterDuke joined 15:39 softmoth joined 16:27 hungrydonkey left 16:39 Altai-man_ joined 16:42 sena_kun left 16:52 softmoth left, softmoth joined 16:55 softmoth left 17:03 softmoth joined
lizmat notable6: weekly 17:24
notable6 lizmat, 7 notes: gist.github.com/05397a8f97d90fc149...46f3909f56
17:43 pmurias joined
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
18:28 pmurias left 18:40 sena_kun joined 18:42 Altai-man_ left
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
19:27 pmurias joined 19:35 softmoth left
Geth_ roast: usev6++ created pull request #635:
Test usage of labels within nested loops		 20:39
20:39 Altai-man_ joined 20:42 sena_kun left
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
20:48 MasterDuke left
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
20:54 Kaeipi left, Kaeipi joined
bartolin_ github.com/rakudo/rakudo/issues/3624 ## for the Slip.from-loop thing 20:59
lizmat bartolin_++ 21:00
21:01 MasterDuke joined
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
21:15 ggoebel joined
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
21:29 Altai-man_ left
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
22:00 lucasb left
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
22:45 cognominal joined 22:46 cognomin_ left
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
23:12 ggoebel_ joined, ggoebel left 23:19 ggoebel_ left
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
23:55 softmoth joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!