🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
09:20 sena_kun joined
Geth raku-File-Temp/master: 5 commits pushed by (Tom Browder)++ 11:34
File-Temp/main: ea1f2f57d2 | (Elizabeth Mattijsen)++ | 4 files
Final check for zef:community-modules release
File-Temp/main: 3ffce36b98 | (Elizabeth Mattijsen)++ | 2 files
Oops, fix META6.json
File-Temp/main: 73522bdef5 | (Elizabeth Mattijsen)++ | 8 files
Modernize test-file extensions
File-Temp/main: d16758f71a | (Elizabeth Mattijsen)++ | 3 files
rakudo/main: 2ce4b655c5 | (Elizabeth Mattijsen)++ | 7 files
Revert "Create the ProtoInfo class"

It's going take much longer to fix core setting breakage than expected, so remove this for now and put it in a branch later on. This means that for now, Routine objects remainn way more bulky memory-wise than they could be.
This reverts commit 4751e6fee63cb4a2844d95daca62586577e041be.
rakudo/liz-ProtoInfo: f52dc71db6 | (Elizabeth Mattijsen)++ | 7 files
Create the ProtoInfo class

This class will contain the proto / dispatcher logic that is now part of the Routine object. In the near future, the Routine
  $!dispatcher attribute will contain 3 possible values:
  - NQPMu to indicate the Routine is an "only"
  - a Callable of the dispatcher to indicate it is a "multi"
... (5 more lines)
rakudo/liz-ProtoInfo: acb48f0920 | (Elizabeth Mattijsen)++ | 7 files
Work in progress on integration of ProtoInfo class

The problem is that at the first use of "is rw" on a Routine in the setting, the dispatch fails. However, at that early in the setting, basically nothing works yet, so debugging becomes *very* hard. After spending 2 days on this, I decided to leave this work in a branch for the time being, until more clarity is obtained.
13:59 kjp left 14:13 kjp joined
vrurg There is an idea that circulates in my mind for some time now. Rakudo pays big performance penalty by allocating a Scalar for each non-bound variable. Yet, many of them a purely read-only and don't require a container. Is it possible to implement COW-like semantics by vivifying a Scalar on demand? 18:55
japhb vrurg: What do you propose for the method of detecting a write? (I can think of a couple, but it's not clear to me what the relative performance gain or hit would be.) 21:34
vrurg japhb: Best if supported by VM with some help from dispatchers, perhaps. But that's as much I can think up for now. I'm sure there will be gain because when there is something like `for ^1000000 { my $cached_value = $obj.get_something($_); ... }` and the $cached_value is RO only then allocating 1000000 scalars with following GC run over them is most definitely a cost we pay for nothing. 22:36
As far as I understand, it's a subset of tasks Jonathan's work on PEA was intended to resolve. 22:38
23:52 sena_kun left