| 4 Nov 2025 | |||
| Voldenet | try doing clean pull | 06:19 | |
| erm, clone | |||
| JimmyZhuo | thanks very much, looks I has some problem with GFW , and it's ok now | 06:23 | |
| Geth | rakudo: zhuomingliang++ created pull request #6007: Add RakuAST Optimizer |
08:36 | |
| melezhik | o/ | 10:28 | |
| Hit an interesting issue when testing zef in another brownie round - brw.sparrowhub.io/file_view/pensive...exe%3E.log | 10:29 | ||
| Cc ugexe | |||
| Also looks like if we run zef install Foo in several parallel threads on the same container AND we use standard zef path ( no ZEF_INSTALL_TO) I don’t see “already installed” errors from zef , at least so far | 10:33 | ||
| Cc ab5tract | |||
| lizmat | timo: I've come to the conclusion that OO::Monitors.clone issue is actually deeper | 12:21 | |
| and could be fixed by making an nqp::clone() on an object with ReentrantMutex REPR do a nqp::new() | 12:22 | ||
| the alternative would be re-implement Mu.clone in OO::Monitors, but that wouldn't fix any of the other cases (think Method::Protected) | 12:23 | ||
| rakkable: eco-provides Lock.new --and=$! | 12:32 | ||
| rakkable | lizmat, Running: eco-provides Lock.new --and=$!, please be patient! | ||
| lizmat, Found 51 lines in 41 files (38 distributions): | |||
| lizmat, gist.github.com/d6cdb4f0ca07944a4e...30bcca9433 | |||
| lizmat | so that's quite a few dists that have a Lock attribute, that cannot be .clone d currently | ||
| m: class A { has int $.a = 42 }; dd A.new.clone(a => 666) # meh | 12:55 | ||
| camelia | Died with X::Assignment::RO in block <unit> at <tmp> line 1 |
||
| lizmat | github.com/rakudo/rakudo/issues/6008 | 13:59 | |
| timo | i'm not sure just doing an nqp::new on any lock attribute when cloning is a good idea | 14:56 | |
| it may be more useful to have something in the core that makes writing a custom clone method implementation more convenient, or something that makes the behaviour of the builtin clone method customizable by the class in question | 14:58 | ||
| ab5tract | that sounds reasonable to me | 16:27 | |
| timo | deep cloning is also a thing people are often interested in, but it's a rather hairy topic with many easily overlooked details i think? | 16:58 | |
| ab5tract | would cloning a lock clone it's locked-ness? | 17:05 | |
| ugexe | depends on the sequencing of the inherit race condition | 17:57 | |
| lizmat | now, if Mu.clone would have a way to indicate the attributes *not* to clone | 18:20 | |
| OTOH, what *does* it mean if we clone a monitor: should they share the lock? | 18:21 | ||
| ab5tract: in my book, it would, yes | 18:22 | ||
| but that's keeping the OO::Monitors semantics in the back of my head | |||
| melezhik_ | zero "already installed" errors, if not use ZEF_INSTALL_TO var and if run many zef install Foo in parallel | 18:25 | |
| cc ab5tract: | |||
| root@fa5b368a1dcc:/app# grep "already install" ~/.brownie/versions/2025.10/*.log | wc -l | |||
| 0 | |||
| Geth | rakudo/main: 78a43bc20d | (Elizabeth Mattijsen)++ | src/core.c/Mu.rakumod Allow native attributes can be twiddled with .clone Before this, trying to twiddle a native attribute with .clone, would die. As described in #6008 Also streamlined the .clone logic into separate "twiddling" and "non-twiddling" private methods, which makes it go up to 10% faster. |
20:05 | |
| roast: 11505482f4 | (Elizabeth Mattijsen)++ | S12-attributes/clone.t Add test for native attribute twiddling with .clone See also github.com/rakudo/rakudo/issues/6008 |
20:13 | ||
| jubilatious1_98524 | "would cloning a lock clone it's locked-ness?" Great question! | 20:21 | |
| 5 Nov 2025 | |||
| timo | if a cloned monitor would inherit its lockedness from the original, and you return a clone of a monitor from one of its methods, there is no way to unlock that monitor, since unlocking happens when control flow leaves the outer-most of its methods, but there is no thread of execution in the new monitor at all | 00:10 | |
| Geth | rakudo: zhuomingliang++ created pull request #6009: Fix some bugs |
00:54 | |