|
🦋 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. |
|||||||||||||||||||||||||||||||||||||||
|
00:08
reportable6 left
00:10
reportable6 joined
00:34
Kaiepi left,
Kaipei joined
00:47
frost joined
01:47
reportable6 left,
notable6 left,
statisfiable6 left,
bisectable6 left,
nativecallable6 left,
bloatable6 left,
tellable6 left,
greppable6 left,
committable6 left,
coverable6 left,
releasable6 left,
unicodable6 left,
shareable6 left,
quotable6 left,
sourceable6 left,
benchable6 left,
linkable6 left,
evalable6 left,
unicodable6 joined
01:48
tellable6 joined,
sourceable6 joined,
releasable6 joined,
committable6 joined,
coverable6 joined,
nativecallable6 joined,
linkable6 joined,
reportable6 joined,
shareable6 joined,
bloatable6 joined
01:49
greppable6 joined,
benchable6 joined,
statisfiable6 joined,
bisectable6 joined
01:50
quotable6 joined,
notable6 joined,
evalable6 joined
02:50
evalable6 left,
linkable6 left
02:51
linkable6 joined
02:52
evalable6 joined
03:15
[Coke] left
03:17
[Coke] joined
05:09
committable6 left,
statisfiable6 left,
nativecallable6 left,
bloatable6 left,
unicodable6 left,
tellable6 left,
reportable6 left,
shareable6 left,
sourceable6 left,
releasable6 left,
quotable6 left,
benchable6 left,
evalable6 left,
greppable6 left,
linkable6 left,
bisectable6 left,
coverable6 left,
notable6 left,
committable6 joined,
bisectable6 joined,
nativecallable6 joined
05:10
shareable6 joined,
greppable6 joined,
bloatable6 joined,
sourceable6 joined,
evalable6 joined,
unicodable6 joined,
notable6 joined
05:11
tellable6 joined,
releasable6 joined,
linkable6 joined,
benchable6 joined
05:12
quotable6 joined,
statisfiable6 joined,
coverable6 joined,
reportable6 joined
05:22
Xliff left
06:08
reportable6 left
06:09
reportable6 joined
06:52
frost left
07:22
[Coke] left
07:28
[Coke] joined
08:24
frost joined
|
|||||||||||||||||||||||||||||||||||||||
| 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 | |||||||||||||||||||||||||||||||||||||
|
09:04
frost left
09:33
lizmat_ joined,
RakuIRCLogger left,
Geth__ joined
09:35
Geth left,
lizmat left,
lizmat_ is now known as lizmat,
Geth__ left
09:36
Geth joined
|
|||||||||||||||||||||||||||||||||||||||
| 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 | ||||||||||||||||||||||||||||||||||||||
|
10:48
frost joined
|
|||||||||||||||||||||||||||||||||||||||
| 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 | ||||||||||||||||||||||||||||||||||||||
|
11:06
frost left
|
|||||||||||||||||||||||||||||||||||||||
| 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 | |||||||||||||||||||||||||||||||||||||
|
11:13
frost joined
|
|||||||||||||||||||||||||||||||||||||||
| 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 | ||||||||||||||||||||||||||||||||||||||
|
11:25
frost left
11:36
frost joined
11:58
frost left,
frost joined
|
|||||||||||||||||||||||||||||||||||||||
| 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 | |||||||||||||||||||||||||||||||||||||
|
12:08
reportable6 left
12:11
reportable6 joined
|
|||||||||||||||||||||||||||||||||||||||
| 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 | |||||||||||||||||||||||||||||||||||||
|
12:17
frost left
12:25
frost joined
|
|||||||||||||||||||||||||||||||||||||||
| 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. | |||||||||||||||||||||||||||||||||||||||
|
13:00
frost left
13:42
frost joined
14:06
frost left
|
|||||||||||||||||||||||||||||||||||||||
| [Tux] |
|
15:42 | |||||||||||||||||||||||||||||||||||||
| Geth | rakudo/rakuast: 5 commits pushed by (Stefan Seifert)++ | 15:46 | |||||||||||||||||||||||||||||||||||||
|
15:59
linkable6 left,
evalable6 left
16:00
evalable6 joined
16:02
linkable6 joined
18:07
reportable6 left
18:08
vrurg joined,
vrurg_ left
18:09
reportable6 joined
20:10
jjatria left,
JRaspass left,
jjatria joined,
JRaspass joined
20:50
jjatria left,
JRaspass left,
jjatria joined,
JRaspass joined
22:19
evalable6 left,
linkable6 left
22:20
evalable6 joined
22:21
linkable6 joined
22:26
[Tux] left
22:47
JRaspass left,
jjatria left
22:49
jjatria joined,
JRaspass joined
23:05
Altai-man joined
23:07
sena_kun left
23:39
eof left
|
|||||||||||||||||||||||||||||||||||||||
| 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 |
|||||||||||||||||||||||||||||||||||||||
|
23:48
summerisle joined
23:57
[Tux] joined
|
|||||||||||||||||||||||||||||||||||||||