🦋 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.
lizmat M1 Files=1353, Tests=116312, 192 wallclock secs (16.31 usr 4.17 sys + 1125.45 cusr 60.03 csys = 1205.96 CPU) 09:02
SmokeMachine Hi! why don't we have weak references as in Java's sense of weak reference of not disallowing the reference to be gced? 10:39
I have asked that before but I don't really remember the answer... but lizmat's tweet made m eask about that once again... 10:41
SmokeMachine this one: twitter.com/liztormato/status/1536...9huyjEa6BA 10:49
that would be cool for, for example, having a set of currently used objects. If it's not being used anymore, the original ref goes out of scope, some time before it's GCed and then stop existing inside the Set. Without that all the objs inside the Set would exist for ever... 10:52
(By Set I do not mean the class Set, but some kind of WeakSet) 10:54
japhb SmokeMachine: You can get a similar effect with a factory (that stores the new object ID), objects with a DESTROY method (that removes the old object ID), and having the set contain object IDs instead of pointers. 11:10
SmokeMachine japhb: but that's not quite the same, is it? if I get .keys, it won't that the objects, for example... 11:19
another usage could be having 2 objs having reference to each other, right? 11:21
japhb SmokeMachine: The reference loop problem is fixed by having a full GC (which can correctly account for unreachable loops and dispose of them), as opposed to reference counting which does indeed have that failure mode (and is why perl5 needs weak refs, for instance). 12:03
SmokeMachine japhb: yes... I just realised that... but that's not the case if I want to collect one of the objs even if the other still exist. 12:06
japhb SmokeMachine: Hmmmm. What's your actual use case? I feel like we've wandered into XY question territory ... or perhaps I'm just not seeing the actual problem. 12:14
nine same here 12:33
SmokeMachine A good usage example (in my mind) would be this: irclogs.raku.org/raku/2020-10-12.html#14:11 12:34
a cache for Red's objects 12:35
that would allow the objects to be GCed 12:36
nine SmokeMachine: you can still have the "per request" cache without weak refs. Your caching layer just needs to know the concept of a request or session or lifecycle or whatever you want to call it at that layer. And a bit of API so the user is able to tell the cache that this session is done and the cache can be flushed. 12:40
SmokeMachine nine: on that case it would, probably, use even more memory if there are several sessions in parallel, right? 12:42
and Red isn't always used where there is a "request" concept...
nine Even in Tau Station there are 2 different kinds of cache life cycle. So the request or session lifecycle one would be strictly optional 12:46
If an object can be in use by different sessions, you wouldn't need more memory with parallel sessions.
[Tux] Rakudo v2022.06-17-gf2546b446 (v6.d) on MoarVM 2022.06-1-ged7e1a51b
csv-ip5xs0.831 - 0.855
csv-ip5xs-205.165 - 5.520
csv-parser3.538 - 3.551
csv-test-xs-200.412 - 0.455
test6.578 - 6.670
test-t1.470 - 1.510
test-t --race0.857 - 0.879
test-t-2021.071 - 23.975
test-t-20 --race6.494 - 6.766
15:42
Geth rakudo/rakuast: 5 commits pushed by (Stefan Seifert)++ 15:46
Geth DBIish/oracle-blob-read: 572fb66487 | (Vadim Belman)++ | 3 files
Implement reading of BLOBs

No writing yet.
A blob is returned as a `Supply` emitting `Buf` instances. I.e. for a row in hash format sending the actual BLOB data into a file would be:
   react whenever %row<BLOB_COL> {
   $file.write($_);
   }
23:44
DBIish: vrurg++ created pull request #231:
Implement reading of BLOBs