🦋 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.
00:08 reportable6 left
ugexe MasterDuke: I think your issue might be closer to github.com/rakudo/rakudo/issues/1920 00:48
the first example isn't golfed much but its the same result with just one module 00:49
01:03 [Coke]_ joined, [Coke] left 01:08 reportable6 joined 02:03 squashable6 left 02:17 frost joined 02:52 [Coke] joined 02:53 [Coke]_ left 03:03 frost left 03:06 squashable6 joined 04:32 unicodable6 left, statisfiable6 left, greppable6 left, benchable6 left, nativecallable6 left, tellable6 left, quotable6 left, shareable6 left, coverable6 left, notable6 left, bisectable6 left, bloatable6 left, sourceable6 left, releasable6 left, committable6 left, evalable6 left, squashable6 left, linkable6 left, reportable6 left, nativecallable6 joined 04:33 reportable6 joined, committable6 joined 04:34 notable6 joined, releasable6 joined, sourceable6 joined, squashable6 joined, statisfiable6 joined, greppable6 joined, bisectable6 joined, coverable6 joined 05:38 AlexDaniel left 05:39 nine left, statisfiable6 left, sourceable6 left, ugexe left, eof left, [Coke] left, djinni` left, moon-child left, sivoais left, coverable6 left, squashable6 left, notable6 left, committable6 left, reportable6 left, CIAvash left, JRaspass left, jdv left, masak left, Voldenet left, samcv left, tonyo left, bartolin_ left, gfldex left, jjatria left, rypervenche left, Util left, samebchase left, qorg11 left, lizmat left, tbrowder left, [Tux] left, leont left, kawaii_ left, rba left, codesections left 05:42 andinus` left 05:43 andinus joined 05:47 andinus left 05:50 Geth left, MasterDuke left, Altai-man left, nebuchadnezzar left 05:52 Kaiepi left, vrurg left, japhb left, discord-raku-bot left, kjp left, timo left, maettu left, ilogger2 left, camelia left, zostay left 05:53 camelia left, nebuchadnezzar joined, Altai-man joined, MasterDuke joined, Geth joined, [Coke]_ joined, quotable6 joined, linkable6 joined, bloatable6 joined, unicodable6 joined, coverable6 joined, statisfiable6 joined, squashable6 joined, sourceable6 joined, notable6 joined, committable6 joined, reportable6 joined, qorg11 joined, CIAvash joined, AlexDaniel joined, ugexe joined, rypervenche joined, nine joined, [Tux] joined, samcv joined, Voldenet joined, lizmat joined, Util joined, djinni` joined, tonyo joined, bartolin_ joined, gfldex joined, moon-child joined, leont joined, kawaii_ joined, rba joined, codesections joined, sivoais joined, eof joined, masak joined, jdv joined, JRaspass joined, samebchase joined, jjatria joined, tbrowder joined 05:54 Kaiepi joined, vrurg joined, japhb joined, discord-raku-bot joined, kjp joined, timo joined, maettu joined, ilogger2 joined, camelia joined, zostay joined 05:55 SmokeMachine joined, patrickb joined, lucs joined, TempIRCLogger__ joined, dogbert17 joined, sjn joined, RakuIRCLogger joined, nativecallable6 joined, releasable6 joined, greppable6 joined, bisectable6 joined, nebuchadnezzar joined, Altai-man joined, MasterDuke joined, Geth joined, [Coke]_ joined, quotable6 joined, linkable6 joined, bloatable6 joined, unicodable6 joined, coverable6 joined, statisfiable6 joined, squashable6 joined, sourceable6 joined, notable6 joined, committable6 joined, reportable6 joined, qorg11 joined, CIAvash joined, AlexDaniel joined, ugexe joined, rypervenche joined, nine joined, [Tux] joined, samcv joined, Voldenet joined, lizmat joined, Util joined, djinni` joined, tonyo joined, bartolin_ joined, gfldex joined, moon-child joined, leont joined, kawaii_ joined, rba joined, codesections joined, sivoais joined, eof joined, masak joined, jdv joined, JRaspass joined, samebchase joined, jjatria joined, tbrowder joined, camelia joined, zostay joined 06:07 reportable6 left 06:08 reportable6 joined 06:13 linkable6 left 06:26 qorg11 left 06:27 qorg11 joined 06:33 evalable6 joined, shareable6 joined 06:34 tellable6 joined, benchable6 joined 07:32 squashable6 left 07:33 squashable6 joined
Geth nqp: 585e85b860 | (Stefan Seifert)++ | src/vm/moar/QAST/QASTCompilerMAST.nqp
Fix generated attribute accessors treating all native ints as signed

Now that bootstrapping issues are behind us, we can safely switch to the correct behaviour.		 07:46
rakudo: 8bba2aec43 | (Stefan Seifert)++ | tools/templates/NQP_REVISION
Bump NQP to get fix for accessors for unsigned native ints
 07:47
nine Seems to fix several TODOs :) 07:48
08:07 frost joined
Geth rakudo: 4e1a772147 | (Stefan Seifert)++ | src/Perl6/World.nqp
Fix "No registered operation handler for 'iseq_u'"

Regression caused by a38bebecf8b1f125e8408c2a6d0a2e19d47545dd There is no iseq_u, so we have to use iseq_i instead. Whether that's correct depends on whether one expects iseq_i to compare abstract values
  (i.e. -1 != 255) or to implicitly coerce (-1 == 255).		 08:22
lizmat Files=1351, Tests=117097, 288 wallclock secs (35.49 usr 9.87 sys + 4024.22 cusr 332.78 csys = 4402.36 CPU) 08:55
Geth roast: b1349ef6eb | (Stefan Seifert)++ | 3 files
Un-todo some now passing tests
09:16 frost left 09:23 [Tux] left 09:24 [Tux] joined 09:44 squashable6 left 09:51 frost61 joined
Geth nqp: f1bc85e708 | (Stefan Seifert)++ | tools/templates/MOAR_REVISION
Bump MoarVM to get an uint fix
 10:05
rakudo: d743ebfd02 | (Stefan Seifert)++ | tools/templates/NQP_REVISION
Bump NQP to get an uint fix on MoarVM
 10:06
10:09 squashable6 joined 10:13 linkable6 joined 10:43 frost61 left
Geth rakudo: c92833f350 | (Stefan Seifert)++ | 2 files
Fix NativeCall wrongly expecting signed integer for size_t rw args
 10:43
rakudo: 3445513858 | (Elizabeth Mattijsen)++ | src/core.c/Date.pm6
Don't assume "year" as unit

In response to #4756. Since we generally ignore any unexpected named arguments on method calls, this seems to be the most compatible solution.		 11:00
lizmat
.oO( it's been a while I did so many core setting compiles in a morning! )
11:01 linkable6 left 11:43 sena_kun joined 12:02 linkable6 joined 12:07 reportable6 left 12:12 frost joined
Geth nqp: e4e3e9feed | (Stefan Seifert)++ | 3 files
New (at|bind)pos[23n]d_u and multidimref_u ops
 12:14
lizmat ooo!
Geth rakudo: 8777e9237a | (Stefan Seifert)++ | 3 files
Use proper unsigned ops for accessing multidim uint arrays
 12:25
12:30 sena_kun left 12:33 sena_kun joined 12:45 frost left
nine jdv: I'd appreciate a new Blin run. I think I've fixed all different failure modes, but testing every single failed module individually is kinda tedious. The list should now also be short enough to fit into a ticket. 13:02
vrurg: PDF suffers from multiple issues. Among them "get_boxed_ref could not unbox for the representation 'P6bigint' of type Scalar" which can be fixed by:
my subset UInt of Int where {
- nqp::not_i(nqp::isconcrete($_)) || nqp::isge_I($_,0)
+ nqp::not_i(nqp::isconcrete($_)) || nqp::isge_I(nqp::decont($_),0
vrurg: IIRC you did some more work on subsets and smartmatch? 13:03
lizmat nine: shouldn't the decont also apply to the isconcrete($_) ?? 13:07
nine lizmat: indeed. But I think the where block should be called with a deconted value in the first place. At least it seems to have been previously. 13:11
lizmat ah, that would make sense... :-)
Geth rakudo: e4a4a92f1e | (Stefan Seifert)++ | src/core.c/array_multislice.pm6
Fix "container does not reference a native integer" in multi slice

We can now get IntLexRef as well as UIntLexRef. The latter doesn't unbox directly to int, so we have to put the value into a Scalar first.		 13:14
13:26 [Coke]_ is now known as [Coke] 13:56 discord-raku-bot left 13:57 discord-raku-bot joined 14:05 discord-raku-bot left, discord-raku-bot joined 14:24 sena_kun left
vrurg nine: Sorry, don't really follow you. First of all, I don't know how exactly and where PDF fails. 14:24
14:25 sena_kun joined
vrurg nine: But you actually reminded me that we now have a new primspec. Does 4 stands for uint? 14:36
[Coke] is that different from the thing that just got changed to 400? 15:06
15:09 reportable6 joined
vrurg [Coke]: It's BUILDPLAN codes which got changed because of a new primspec. 15:40
The codes now remind be about BASIC times... :) 15:41
16:03 Kaipi joined 16:06 Kaiepi left
nine vrurg: uint is 10 16:37
Geth rakudo: 7cb214671c | (Stefan Seifert)++ | 2 files
Fix "container does not reference a native integer" with mixed int/uint multidim array indexes

Giving arguments their own scalar containers triggers a decont from any native reference containers passed for indexes. We can then unbox to a native int regardless of whether the original value was an int or uint.		 17:14
nine vrurg: to reproduce run PDF's t/00-helloworld.t on current rakudo. You will get a test failure due to # P6opaque: get_boxed_ref could not unbox for the representation 'P6bigint' of type Scalar 17:16
18:06 reportable6 left 18:24 sena_kun left
vrurg nine: I just thought that if it's as simple as you suggested you can do it on your own. :) 18:45
Ok, I'll check if it helps later today. 18:46
nine vrurg: thing is, I don't think my fix is correct. Feels like a workaround for a missing decontainerization in the smartmatch dispatcher 19:03
19:10 Merfont joined 19:13 Kaipi left
jdv nine: ok, cool. but maybe i should wait a bit sounds like? 19:21
Geth nqp/lizmat-race-on-QAST-Node: 54a0a27c0f | (Elizabeth Mattijsen)++ | src/QAST/Node.nqp
Fix race when checking for global uniques

As inferred from a stack trace from code that was doing EVAL inside of a hyper:
MoarVM oops: MVM_str_hash_fetch_nocheck called with a stale hashtable pointer
   at gen/moar/stage2/QASTNode.nqp:249 (.../install/share/nqp/lib/QASTNode.moarvm:unique)
... (6 more lines)		 19:35
nqp: lizmat++ created pull request #760:
Fix race when checking for global uniques
MasterDuke nqp: my %h := nqp::hash("a", 1, "b", 3); my $a := "c"; my $b := ++%h{$a}; say($b); say(%h{$a}) 19:56
camelia 1
1
lizmat indeed 19:57
what I'm more worried about is what happens if one thread adds something to the %global-uniques hash, and the other thread updates over it and removes it
MasterDuke well, it looks like that hash is never deleted from, if that's what you mean 20:00
lizmat well, that's what I would expect 20:05
I mean that thread A clones an empty hash and adds "foo" to it, while thread B also clones the empty hash and add "bar" to it
the one who binds back the last, will lose the addition of the other thread 20:06
nine If that's an issue, you really need a lock. Or go the full compare and swap in a loop route 20:07
lizmat well, yes
but I'm totally unclear what the real meaning is of that hash 20:08
ugexe i think the behavior your witnessed suggests that your concern is also possible though
lizmat nine: but you agree there's a race condition there, when called as a class method, right ?
ugexe like even if we don't know what its meaning is, we know multiple threads can enter the critical area 20:09
lizmat I mean, perhaps some crashes can be explained by values being lost
even without it crashing
nine With my %uniques; absolutely
Shared state is the bane of all threaded code
MasterDuke it's for creating unique node names, e.g., github.com/Raku/nqp/blob/master/sr...r.nqp#L103 20:10
lizmat ahh, so lost updates *would* mess up things considerabley 20:12
nine I'd just add a lock there 20:13
lizmat feels that would be pretty bad for compilation performance
MasterDuke we could also just switch to generating random names, e.g., `return $prefix ~ '_' ~ nqp::sha1($prefix ~ nqp::time)` 20:14
nine No, no, no, no, no, no, no
lizmat: feelings are one thing. Measurements are useful
lizmat ok, so maybe we just need a separate method for each key
and then use an atomic integer increment ? 20:15
that would also safe on a few lookups 20:16
hmmm.. looks like that would be quite a number of methods
nine First, I'd just add that lock and have a look if that makes any measurable difference at all. 20:17
20:19 evalable6 left, linkable6 left
lizmat nine: and how do you do that in NQP 20:19
?
MasterDuke there's an NQPLock
nine github.com/Raku/nqp/blob/master/sr...ck.nqp#L43
And github.com/Raku/nqp/blob/master/sr...ck.nqp#L51 20:20
lizmat ok, will rewrite using lock
MasterDuke in an entire rakudo build+install, that method is called 97.5k times. 41756 __lowered_lex, 25943 __lowered_param_, 16637 __lowered_param_decont_, 3557 assign_cont, 2294 buildall_tmp_, 859 how_invocant, ... 20:22
lizmat MasterDuke: so is that a lot? I have no feel for these numbers :-) 20:23
ugexe i think the saying goes locks aren't slow, lock contention is slow 20:24
MasterDuke dunno. but since we don't usually compile with multiple threads, the lock probably won't be contended for that much
lizmat right, ok
vrurg Wish we had atomics in NQP. They'd be of some advantage over locks in such simple cases. 20:26
Wish we had atomics in NQP. They'd be of some advantage over locks in such simple cases. 20:27
Geth nqp/lizmat-race-on-QAST-Node: 056961ad5c | (Elizabeth Mattijsen)++ | src/QAST/Node.nqp
Rework using locks, nine++, ugexe++ MasterDuke++
lizmat nine like that ?
Geth nqp/lizmat-race-on-QAST-Node: fd2aad4d4f | (Elizabeth Mattijsen)++ | src/QAST/Node.nqp
Make use of autovivification, MasterDuke++
 20:31
nine lizmat: yep
lizmat ok, I'll merge and bump for better bisectability 20:32
Geth nqp: f23b6aca69 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/QAST/Node.nqp
Fix race when checking for global uniques (#760)

As inferred from a stack trace from code that was doing EVAL inside of a hyper:
MoarVM oops: MVM_str_hash_fetch_nocheck called with a stale hashtable pointer
   at gen/moar/stage2/QASTNode.nqp:249
With pointers by ugexe++, MasterDuke++ and nine++		 20:33
20:36 Altai-man left
MasterDuke didn't notice a rakudo build taking any longer 20:37
lizmat well, there's only ever 1 hash lookup now instead of 2 20:38
that should be helpful :-)
20:39 sena_kun joined
nine lose some, gain some ;) 20:43
Geth rakudo: 26215f20c1 | (Vadim Belman)++ | src/core.c/Int.pm6
Fix UInt where block trying to unbox a Scalar

  `nqp::isconcrete` doesn't need deconting, BTW.
nine vrurg: but why does that where block suddenly need the decont? It has never been necessary before 20:44
vrurg nine: Hm, it's a good question. I thought something has changed about the unboxing op. Now I see your point. 20:46
MasterDuke spectest seems about the same too
ugexe github.com/rakudo/rakudo/blob/7cb2...e.pm6#L317 -- should this have a `try`? If multiple threads try to load the same module then they would be trying to rename the same file. only one would succeed at renaming, but technically that should be sufficient. however currently it throws an exception when the rename
fails
lizmat spectest feels a bit slower to me
but we'll now tomorrow 20:47
nine ugexe: I wonder if it were better to pick a random file extension instead of .tmp, so those threads or processes wouldn't try to move the same file in the first place. 20:48
Geth rakudo: f47d95e032 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
f47d95e032 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
lizmat *know
vrurg nine: I don't decont the topic in the smartmatch optimizations. If it's been done before it was rather accidental as it was never specced.
nine lizmat: about those locks. IIRC you can estimate around a 100 CPU cycles for acquiring a lock. At 1 GHz taking 100k locks (like in the entire rakudo build+install) should therefor cost about 0.01s 20:50
vrurg m: my $v = 4; say $v.VAR ~~ Scalar
camelia True
vrurg m: my $v := 4; say $v.VAR ~~ Scalar
camelia False
nine vrurg: from that issue I presume that smartmatch did decont before 20:51
vrurg nine: So far, there is no fallout from this change. And I like that the matching against scalar works now. 20:52
nine vrurg: with this patch to PDF itself: gist.github.com/niner/2567d43baa26...73f836df7c you should get down to the last remaining issue, which looks smartmatchy to me
lizmat afk& 20:58
vrurg nine: Going to look into it. BTW, even though ~~ was deconting, the `where` block was working until somebody would report UInt.ACCEPTS or UInt.^accepts_type failure. 20:59
So, we'd end up with the same issue anyway. 21:00
I wonder if it makes sense to spec the .VAR ~~ Scalar behavior... 21:02
21:11 camelia left, zostay left, vrurg left, japhb left, kjp left, timo left, maettu left, ilogger2 left, sena_kun left, Geth left, MasterDuke left, nebuchadnezzar left, AlexDaniel left, nine left, Merfont left, squashable6 left, benchable6 left, shareable6 left, qorg11 left, bloatable6 left, unicodable6 left, statisfiable6 left, sourceable6 left, ugexe left, eof left, discord-raku-bot left, djinni` left, moon-child left, sivoais left, [Tux] left, coverable6 left, notable6 left, committable6 left, CIAvash left, JRaspass left, jdv left, masak left, Voldenet left, samcv left, tonyo left, bartolin_ left, gfldex left, jjatria left, rypervenche left, Util left, samebchase left, [Coke] left, quotable6 left, lizmat left, tbrowder left, leont left, kawaii_ left, rba left, codesections left 21:12 RakuIRCLogger left, sjn left, TempIRCLogger__ left, dogbert17 left, lucs left, patrickb left, SmokeMachine left, sena_kun left, Geth left, MasterDuke left, nebuchadnezzar left, AlexDaniel left, nine left, Merfont left, squashable6 left, benchable6 left, shareable6 left, qorg11 left, bloatable6 left, unicodable6 left, statisfiable6 left, sourceable6 left, ugexe left, eof left, discord-raku-bot left, djinni` left, moon-child left, sivoais left, [Tux] left, coverable6 left, notable6 left, committable6 left, CIAvash left, JRaspass left, jdv left, masak left, Voldenet left, samcv left, tonyo left, bartolin_ left, gfldex left, jjatria left, rypervenche left, Util left, samebchase left, [Coke] left, quotable6 left, lizmat left, tbrowder left, leont left, kawaii_ left, rba left, codesections left 21:14 gfldex joined, bartolin_ joined, tonyo joined, samcv joined, ilogger2 joined, maettu joined, timo joined, kjp joined, japhb joined, vrurg joined, nine joined, AlexDaniel joined, codesections joined, rba joined, kawaii_ joined, leont joined, masak joined, jdv joined, moon-child joined, djinni` joined, discord-raku-bot joined, discord-raku-bot left, discord-raku-bot joined, Merfont joined, squashable6 joined, benchable6 joined, shareable6 joined, qorg11 joined, bloatable6 joined, unicodable6 joined, statisfiable6 joined, sourceable6 joined, ugexe joined, eof joined 21:15 jjatria joined, camelia joined, zostay joined, AlexDaniel left, rypervenche joined, Util joined, samebchase joined 21:19 evalable6 joined
ugexe Serialization Error: Unimplemented case of read_ref 21:27
havent seen that one yet
Invalid dependencies table index encountered (index 32) 21:29
21:45 CIAvash joined
ugexe I wonder if ".{now}.{$*PID}.{$*THREAD.id}.tmp" is sufficient 22:16
vrurg ugexe: Thread ID I'd consider unreliable. 22:19
moon-child sufficient for what? (Sorry, may have missed context due to netsplit)
22:19 MasterDuke left
ugexe for a given Instant 22:19
for generating a unique temp file name 22:20
moon-child oh, make a random string and retry it until you succeed
vrurg But nqp::objectid($*THREAD) could be better.
ugexe that wont work in this case
the random string and retry 22:21
thats not thread safe
moon-child why not?
vrurg moon-child: the filesystem may change after the check. 22:22
moon-child dynamic bindings are thread-local no?
vrurg What could be miore reliable is open(:create-only) and retry on failure.
ugexe i'm not sure thats an option in the code 22:23
moon-child vrurg: what's the difference between that and what I said?
vrurg ugexe: open? why?
moon-child: you just mentioned a string only. :) 22:24
ugexe github.com/rakudo/rakudo/blob/7cb2...#L311-L317
self!file calls self!dir which involves a lock 22:25
moon-child vrurg: ok, maybe not super clear :P that was what I meant though 22:26
ugexe which is just to say its not as easy as just having the handle in that spot due to ^
vrurg ugexe: then objectid of $*THREAD would work. Thread ID can be shared, but $*THREAD is always unique per-thread. 22:28
ugexe right, in this specific case i don't think $*THREAD.id would change. but yeah objectid is better 22:29
vrurg I don't think either, but a custom scheduler might have different opinion on this. 22:30
Perhaps it worth to spec $*THREAD uniqueness to ensure correct behavior of any possible 3rd party scheduler. 22:32
Geth rakudo: ef4abcc780 | (Vadim Belman)++ | src/vm/moar/dispatchers.nqp
Use nqp::istype for nominalizable smartmatch

It is used to shortcut to `.^accepts_type`, but `nqp::istype` could do more than falling back to this method.		 22:45
22:52 AlexDaniel joined 22:58 MasterDuke joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!