|
🦋 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 |
12:25 | ||
| File-Temp/main: 3ffce36b98 | (Elizabeth Mattijsen)++ | 2 files Oops, fix META6.json |
12:27 | ||
| File-Temp/main: 73522bdef5 | (Elizabeth Mattijsen)++ | 8 files Modernize test-file extensions |
12:30 | ||
| File-Temp/main: d16758f71a | (Elizabeth Mattijsen)++ | 3 files 0.0.11 |
12:33 | ||
| 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. |
12:55 | ||
| 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) |
12:56 | ||
| 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. |
12:59 | ||
|
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
|
|||