|
🦋 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:00
reportable6 left
00:02
reportable6 joined
00:51
squashable6 left
00:52
squashable6 joined
03:23
linkable6 left,
evalable6 left,
linkable6 joined
03:25
evalable6 joined
04:25
sourceable6 left,
linkable6 left,
reportable6 left,
committable6 left,
nativecallable6 left,
greppable6 left,
tellable6 left,
statisfiable6 left,
benchable6 left,
bisectable6 left,
evalable6 left,
squashable6 left,
releasable6 left,
shareable6 left,
statisfiable6 joined,
benchable6 joined,
greppable6 joined
04:26
sourceable6 joined,
reportable6 joined,
shareable6 joined,
tellable6 joined,
linkable6 joined
04:27
bisectable6 joined,
releasable6 joined,
nativecallable6 joined,
committable6 joined
04:28
squashable6 joined,
evalable6 joined
05:55
ilogger2 left,
ilogger2 joined
06:00
reportable6 left
06:01
reportable6 joined
06:53
ab5tract joined
09:58
linkable6 left,
evalable6 left
09:59
evalable6 joined
10:00
linkable6 joined
12:00
reportable6 left
12:03
reportable6 joined
12:14
ab5tract left
|
|||
| Geth | rakudo/main: 2a331f1f89 | (Elizabeth Mattijsen)++ | src/Raku/ast/operator-properties.rakumod RakuAST: several fixes / additions / removals |
13:16 | |
|
13:34
jgaz joined
14:06
ab5tract joined
14:10
ab5tract left
14:11
ab5tract joined
14:35
ab5tract left
15:52
hythm joined
17:05
codesections joined
18:00
reportable6 left,
reportable6 joined
18:57
ab5tract joined
|
|||
| Geth | roast: 3368e594d6 | (Elizabeth Mattijsen)++ | S32-list/grep-k.t Mark test as skip for now It breaks compilation with RakuAST, and since this returns bogus results with the legacy grammar anyway, it seems safe to mark this as "skip", at least for now. |
19:09 | |
|
19:27
ab5tract left
|
|||
| vrurg | We have a huge hole in handling concurrent module loading. There is a race, likely related to modifying stashes, which with nearly 100% probablity results in SIGSEGV. :( | 20:26 | |
| ugexe | github.com/rakudo/rakudo/issues/1920 | 20:28 | |
| vrurg | Perhaps, that's it. My case is table. It dies at line 5230 in Perl6/World.nqp, in nqp::existskey. The exact location in MoarVM is always P6opaque.c, 1541 because del is NULL. | 20:36 | |
| tonyo | why not just implemenet ugexe's code? | ||
| on that issue | |||
| ugexe | i'm not sure that really solves it generally. like you could do a load module workflow outside of e.g. $*REPO.need for instance | 20:39 | |
| it might be possible to have such a lock somewhere else to work more generally though | 20:40 | ||
| vrurg | I just hope that the lock wouldn't block loading other modules why one is precompiling. Because the entire point for me is to be able to precompile and analyze at the same time. | 20:42 | |
| Yet, the only 100% valid solution would be a thread-safe Stash. | |||
| ugexe | yeah hopefully the lock could go around the stash or serialization or wahtever is causing it | 20:43 | |
| vrurg | I believe that the cause is in merging globals. As far as I remember it's the only location where a stash gets written into. | 20:44 | |
| BTW, interesting fact is that for me it dies while looking up X::Attribute::Required – i.e. it looks like its the CORE stash which gets broken. | 20:46 | ||
| Enclosing the entire `if` starting at line 622 of CURI into `$!lock.protect` doesn't help. Likely because there is a call to `.resolve` made in the other thread. Out of curiousity, I'd try to lock protect the .resolve and see if it works. But that's as much I can do for now. | 21:20 | ||
| ugexe | that isn't generalized enough either | 21:22 | |
| i can just do CompUnit::Repository::Installation.new(...).need(...) without interacting with $*REPO at all | |||
| vrurg | Yes, protecting .resolve doesn't make difference. I'm done with it for today. | 21:46 | |
| japhb | .oO( Well I guess that answers my question from this weekend about whether it's safe yet to parallelize "plugin" (runtime loaded module) loading in MUGS ... ) |
||
| vrurg | Unfortunately, this makes a lot of code unsafe when 3rd party modules are used. Because sometimes they use dynamic loading. | 21:48 | |
| ugexe | yep | ||
|
22:09
codesections left
22:12
dogbert17 joined
22:15
dogbert11 left
22:55
jjatria left,
jjatria joined
|
|||