🦋 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: ... | log inspection situation still under development | For MoarVM see #moarvm
Set by lizmat on 22 May 2021.
vrurg .tell nine I have located the problem and it is about serialization, after all. nqp::atomicbindattr breaks it. I have updated github.com/rakudo/rakudo/pull/4917, so you could check out Stash.merge-symbols method if you wish. 02:40
tellable6 vrurg, I'll pass your message to nine
lizmat Files=1353, Tests=117195, 293 wallclock secs (36.06 usr 10.16 sys + 4075.68 cusr 342.00 csys = 4463.90 CPU) 07:43
lizmat hmmm... this is getting... weird 09:58
this morning github.com/rakudo/rakudo/pull/4919 wouldn't compile for me
"New type Block for List is not a mixin type"
the fix to get it to compile again? add an empty line somewhere in src/core.c/io_operators 09:59
Geth rakudo/lizmat-simplify-stdhandle-setup: 5d2ace5a17 | (Elizabeth Mattijsen)++ | src/core.c/io_operators.pm6
Lose unnnecessary IO::ArgFiles stub
10:16
gfldex I just had a marketing idea: Raku doesn't reinvent the wheel. We just take all the wheel of other languages, so that your program can't possibly fall over. Like this: upload.wikimedia.org/wikipedia/com...acycle.jpg 10:48
lizmat hmmm... not sure that's sending the right message :-) 10:50
gfldex I couldn't fine a more modern picture yet, but will keep looking. 10:51
I do believe it's a nice gag to start a talk or lecture.
nine vrurg: can you please test this patch? gist.github.com/niner/f1f523c4b146...be067c4496 12:03
tellable6 hey nine, you have a message: gist.github.com/3857bad75524f92132...63174a58f7
gfldex Joking aside, with slangs our goals align with the Rights-To-Repair-movement. So a capable Rakoon could achieve something like this: img.izismile.com/img/img12/2019051...640_06.jpg 13:16
vrurg nine: gives a weird error. Left a comment on the gist. 13:19
Ah, ok, you forgot a block. 13:20
vrurg nine: make test, make spectest are now good with nqp::atomicbindattr in merge-symbols. Thanks! 13:28
Voldenet "right to repair" aligns with anything that's open source though 13:34
Voldenet maybe not anything because of patent trolls, but you get the idea 13:35
vrurg nine: with the patch my test script is passing more than 3600 times in a row without a failure. Never seen that many repetitions before! 18:04
nine vrurg: wooohoo Ö= 19:09
:)
vrurg is now waiting for NQP bump. 19:11
BTW, stopped at 4460 repetitions. It rather means that require and stash in general are now thread safe in at least the tested scenario. 19:12
nine: it looks like casattr_o would need the same patch too. 19:18
nine Probably other ops as well. I didn't do a comprehensive check. Just wanted to test this idea first 19:19
lizmat vrurg: please continue your work on CURFS: will rework my branch on top of your work 19:27
well, actually not a branch yet, just some code in git stash :-) 19:28
vrurg lizmat: I'm basically done. For the moment just wanna check out some details, but otherwise I don't see any more races in it.
lizmat cool! 19:29
vrurg The one thing which worries me at the moment is: could it be that $spec in method need and $file.Str in method load would be the same? 19:34
lizmat and still intended to be different ? 19:38
I guess that could be fixed by adding using the WHICH of the CompUnit::DependencySpecification ? 19:40
s/adding// 19:41
vrurg No, to be the same. The point is that `need` currently installs a Promise when there is a concurrent request for the same spec. If it can be the same then load must also install/respect Promises. 19:42
Geth rakudo/lizmat-simplify-stdhandle-setup: 219bbea6b7 | (Elizabeth Mattijsen)++ | src/core.c/io_operators.pm6
Hopefully fix the weird segfault on the JVM
20:03
lizmat vrurg : I guess :-) 20:18
vrurg lizmat: "Guess it can", or "guess it can't"? :) 20:19
japhb m: enum It < can't can >; dd my \Guess = can|can't; 20:32
camelia any(It::can, It::can't)
japhb That's interesting. I wasn't expecting dd to not show the name of a sigilless 20:33
vrurg japhb: they're actually symbols. 20:44
japhb Interesting. I guess I never looked behind the curtain on that one. 20:45
Does snap into the mental model better though.
vrurg Think of it as a key in symbol table which is bound directly to the value. No container mediator which can tell you its name. 20:46
So, basically, dd gets the plain junction.
japhb Yeah, makes sense to me. 20:50
lizmat vrurg: it can 21:58
vrurg lizmat: ok, thanks. 22:11