Geth rakudo/reproducible_RegexCaptures: 159c82e2f2 | (Timo Paulssen)++ | src/Perl6/bootstrap.c/BOOTSTRAP.nqp
Make CORE.c setting build reproducibly

The last thing missing was the array of capture names getting a different order depending on hash randomization, thus breaking reproducibility.		 00:14
rakudo: timo++ created pull request #6005:
Make CORE.c setting build reproducibly		 00:15
00:49 vrurg joined, vrurg_ left 00:52 guifa left 02:07 vrurg_ joined 02:10 vrurg left 02:59 vrurg joined 03:04 nativecallable6_ joined 03:05 shareable6__ joined, greppable6__ joined, benchable6__ joined 03:07 vrurg_ left, benchable6 left, greppable6 left, shareable6 left, nativecallable6 left, apogee_ntv left, apogee_ntv joined 03:32 librasteve_ left 05:14 melezhik joined 05:36 lizmat left 05:56 JimmyZhuo joined
JimmyZhuo hello, looks like nqp lost some git tags 05:57
for now, it has 2025.04
E:\OpenSource\MoarVM\install/bin/nqp-m.exe version 2025.04-1-g68eb3a190 is outdated, 2025.10-1-gea336280d expected. 05:59
Voldenet I can see 2025.10 in here github.com/Raku/nqp/tags 06:04
JimmyZhuo thanks , I use git pull --tags and now works 06:07
looks like VERSION is not updated, still is 2025.04 06:18
Voldenet it is, it's even tagged 2025.10: github.com/Raku/nqp/commit/b242f7e...f3ef2150bb 06:19
try doing clean pull
erm, clone
JimmyZhuo thanks very much, looks I has some problem with GFW , and it's ok now 06:23
07:24 melezhik left 08:04 melezhik joined
Geth rakudo: zhuomingliang++ created pull request #6007:
Add RakuAST Optimizer		 08:36
08:40 JimmyZhuo left
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
10:33 lizmat joined
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
15:24 Guest5968 joined 15:52 vrurg_ joined 15:56 vrurg left 15:59 librasteve_ joined
ab5tract that sounds reasonable to me 16:27
16:39 Guest5968 left
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
18:24 melezhik_ joined
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
18:30 melezhik_ left 18:35 melezhik_ joined 18:41 melezhik_ left, melezhik_ joined 18:46 melezhik_ left, melezhik_ joined 18:49 librasteve_ left 18:56 melezhik_ left 19:23 melezhik_ joined 19:39 melezhik_ left 19:42 vrurg joined, vrurg_ left 19:48 melezhik_ joined 19:51 melezhik_ left 19:54 melezhik_ joined 19:55 melezhik_ left 20:04 melezhik_ joined
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
20:43 melezhik_ left 21:12 melezhik_ joined 21:14 melezhik_ left 21:30 melezhik_ joined 21:35 melezhik_ left, melezhik_ joined 21:40 Voldenet left 21:41 Voldenet joined 21:44 melezhik_ left 21:45 melezhik_ joined 21:50 melezhik_ left 22:04 melezhik_ joined 22:06 melezhik_ left 22:20 melezhik_ joined 22:23 melezhik_ left 22:24 melezhik left 22:28 melezhik_ joined 22:33 melezhik_ left, melezhik_ joined 22:37 melezhik_ left 22:43 melezhik_ joined 22:45 melezhik_ left 22:59 melezhik_ joined 23:01 melezhik_ left 23:14 melezhik_ joined 23:17 melezhik_ left 23:31 melezhik_ joined 23:38 melezhik_ left 23:44 melezhik_ joined 23:48 melezhik_ left

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!