🦋 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:03 discord-raku-bot left, discord-raku-bot joined 00:07 reportable6 left
Geth roast: 774722cfe8 | (Elizabeth Mattijsen)++ | 2 files
UnTODO now passing tests, nine++ for uint work!
 00:13
lizmat and with that. /me calls it a night
00:15 Geth left 00:16 Geth joined 01:09 reportable6 joined 01:59 linkable6 joined 03:37 linkable6 left, evalable6 left 03:39 linkable6 joined 03:40 evalable6 joined 04:30 frost joined 05:09 Altai-man joined 05:11 sena_kun left 05:49 frost left 06:07 reportable6 left 07:07 linkable6 left, evalable6 left 07:08 reportable6 joined 07:10 linkable6 joined 08:08 evalable6 joined
Geth rakudo: a64c2f55f9 | (Stefan Seifert)++ | src/core.c/Buf.pm6
Fix "This container does not reference a native integer" in Blob/Buf

When initializing a Buf or Blob from a non-iterable holding uints, we errored as STORE pushes into the Buf/Blob and there's no push_u yet.		 08:10
rakudo: fee9e822e5 | (Stefan Seifert)++ | lib/NativeCall/Types.rakumod
Fix CArray treating all native integers as signed
nine I've tried to implement push_u instead of the workaround in github.com/rakudo/rakudo/commit/a64c2f55f9 but to utilize it I'd have to push Buf's and Blob's STORE candidates into the Signed/Unsigned roles and that causes ambiguous dispatch. 09:22
I guess that'll remain something for after my vacation 09:23
bartolin_ r: use nqp; my $seen := nqp::hash; say nqp::existskey($seen,(my int $key = 0))
camelia 0
Can't open perl script "/home/camelia/rakudo-j-inst/bin/eval-client.pl": No such file or directory
bartolin_ hmm, rakudo-j complains about "This container does not reference a native string"
m: use nqp; my $seen := nqp::hash; say nqp::existskey($seen,(my $key = 0)) 09:24
camelia This type cannot unbox to a native string: P6opaque, Int
in block <unit> at <tmp> line 1
bartolin_ ^^ similar to that error
nine The error looks correct to me? 09:25
bartolin_ this causes some spectest failures for .repeated on native int arrays. The error seems reasonable to me since nqp::existskey wants a str as its second argument
right -- but the code from github.com/rakudo/rakudo/commit/36...007e32a943 uses this construct 09:26
^^ lizmat
nine Oh, that's new code then
bartolin_ (e.g. 'multi method repeated')
yes 09:27
the usage of nqp::bindkey in 'multi method repeated(intarray:D:)' also looks a bit strange, since it wants a str as its second argument, too. But that one seems to work somehow. 09:30
m: use nqp; my $seen := nqp::hash; nqp::bindkey($seen,(my int $key = 42),1) ## this version blows up on the jvm backend, too 09:31
camelia ( no output )
bartolin_ m: use nqp; my $seen := nqp::hash; nqp::bindkey($seen,(my Int $key = 42),1)
camelia This type cannot unbox to a native string: P6opaque, Int
in block <unit> at <tmp> line 1
bartolin_ nine: btw, the only uint related error I saw was in rakudo's t/04-nativecall/15-rw-args.t (Native call expected argument that references a native integer, but got org.raku.nqp.sixmodel.reprs.NativeRefInstanceIntLex@5155dc15) 09:36
do you perhaps remember if you saw that one, too?
not important, I'm just curious 09:37
nine No, I didn't. For me NativeCall tests were passing at the time I pushed the JVM fixes. Is that a regression since then?
bartolin_ I think so, yes (I didn't see that one last week).
MasterDuke i just saw: t/04-nativecall/05-arrays.t  TODO passed:   39 09:38
bartolin_ but again, it's nothing that should worry you too much -- esp. not if you are going to vacation ...
maybe I have a chance to look at it. but good to know that you didn't see it. (Could even be related to me running on FreeBSD.) 09:39
nine MasterDuke: yes, that's a nice side effect of commit fee9e822e513a914ef1a8204e9926ea8aff8efa3 09:40
MasterDuke cool beans
09:40 linkable6 left
bartolin_ and again thanks for porting the uint stuff to the jvm backend. I don't think I would have been able to do that. 09:41
nine Thing is, the Java code is actually nicer to work with than C. I just wish it were a little faster to compile and that I'd have the same level of tooling as for C. jdb is....rather basic 09:42
But at least on the 5950X, stage parse is down to ~70s, which makes it somewhat bearable :) 09:43
I don't even want to know how long it compiles on my 6 years old laptop :D 09:44
bartolin_ 70s -- wow 09:45
on the VM I run my stuff it's usually more around 200s :/ 09:46
nine That's horrible
I wonder how fast it is on the M1 Mac. I'd guess its memory bandwith could be quite helpful 09:47
moon-child but, no jit 09:49
nine Not even the JVM? 09:50
moon-child oh, right. Got my wires crossed 09:52
MasterDuke i once tried to profile the jvm build, but i've never actually profiled anything java before (and am pretty out of date with my java dev tools experience) and didn't quite succeed 09:53
but maybe there's some low-hanging fruit for someone to pick up 09:54
nine Tools make a lot of difference 09:58
10:41 linkable6 joined
lizmat bartolin_: on MoarVM you can transparently use natives as keys in nqp::hashes 10:44
apparently, you cannot on JVM
bartolin_: there are other places in the core that use this afaik, these native functions are *not* the only place I think 10:47
bartolin_: I guess I could put in a "nqp::coerce_is" for the int -> str case 10:48
but apparently "nqp::coerce_ns" does not exists on the JVM backend?
nine Could be that the QAST compiler does this automatically on MoarVM
lizmat bartolin_: just let me know how you want me to proceed on this 10:49
nine Oh, coercion from uint to str is NYI on JVM. Missed that 10:50
lizmat nine: you mean there is a coerce_uis on MoarVM ?
or coerce_us ?
nine there is 10:51
lizmat then ops_markdown needs updating :-)
*ops.markdown 10:52
anything else there that needs updating?
nine since June 2018
lizmat I assume moar only 10:53
Geth nqp: 42712dd8a2 | (Elizabeth Mattijsen)++ | docs/ops.markdown
Add docs for coerce_iu, coerce_us, coerce_ui
 10:59
bartolin_ lizmat: I have to think about this a bit. I'd say it's not a critical problem for now. If native numbers are coerced to strings automatically on MoarVM, then may it's possible to do that on the JVM as well. 11:03
lizmat ok, I'll await your guidance on that subject then
11:26 nine left 11:27 nine joined 12:08 reportable6 left
Geth roast: usev6++ created pull request #786:
Tweak some uint tests		 12:08
lizmat bartolin_: is a fundge a sort of non fungible fudge ? :-) 12:09
bartolin_ I ... did some stupid typo again? 12:14
ah, now I see it. ;) will fix and force push 12:15
done. (And it was not an original typo this time, but a copied one.) 12:20
lizmat aah? ok... I thought in this days of NFTs I thought it was a nice typo :-) 12:22
bartolin_ but you're right -- it was my own invention after all :) 12:26
12:41 frost joined 13:10 frost left 13:11 reportable6 joined 13:28 frost joined 13:48 discord-raku-bot left 13:51 discord-raku-bot joined 14:29 frost left
dogbert11 m: my $l = "start = 94 ; end = 96 ; sum = 55"; if (my ($s, $e, $sum) = $l ~~ m:P5/^start = (\d+) ; end = (\d+) ; sum = (-?\d+)$/.list) {say $sum} 14:41
camelia (Any)
dogbert11 this seems broken
should return 55 14:42
14:45 frost joined
dogbert11 bisect: my $l = "start = 94 ; end = 96 ; sum = 55"; if (my ($s, $e, $sum) = $l ~~ m:P5/^start = (\d+) ; end = (\d+) ; sum = (-?\d+)$/.list) {say $sum} 14:45
bisectable6 dogbert11, Will bisect the whole range automagically because no endpoints were provided, hang tight
dogbert11, Output on all releases: gist.github.com/d38d571e88275f8251...724f62f48d 14:46
dogbert11, Bisecting by output (old=2021.12 new=fee9e82) because on both starting points the exit code is 0
dogbert11, bisect log: gist.github.com/e93219e0cb5018520b...e9f95ec859
dogbert11, (2021-12-27) github.com/rakudo/rakudo/commit/6b...697a9f72da
dogbert11, Output on all releases and bisected commits: gist.github.com/9e357ed38aed5dc5d1...c2216f728a
dogbert11 looks like something for vrurg
15:25 frost left 16:25 evalable6 left, linkable6 left, linkable6 joined 17:26 evalable6 joined 18:08 reportable6 left 18:33 dogbert11 left 18:34 dogbert11 joined
bartolin_ lizmat: I created an issue for the problem with nqp::existskey we discussed earlier today: github.com/rakudo/rakudo/issues/4732. I didn't find time to look why this happens. Maybe it makes sense to add a special case for the JVM backend to the 'repeated' methods -- at least for now. 19:05
Geth ¦ rakudo: lizmat self-assigned [JVM] Error when trying to assign to variable typed as native int and use the result of the expression directly as key for nqp::hash github.com/rakudo/rakudo/issues/4732 19:06
bartolin_ but maybe someone else has a better idea ...
19:11 reportable6 joined
Geth roast: b28a53b19e | (Christian Bartolomäus)++ | S11-compunit/compunit-dependencyspecification.t
[JVM] Unfudge now-passing test

It started to pass around 2022-01-08, but I don't know what change made it pass.		 19:11
19:12 timo joined
Geth rakudo: nwc10++ created pull request #4733:
Remove dead code from MoarVM and JVM extops		 19:37
bartolin_ nine: btw, the error I see with 'make test' on the JVM backend (happening in github.com/rakudo/rakudo/blob/fee9...rgs.t#L58) seems to trigger this code: github.com/Raku/nqp/blob/42712dd8a...L569-L571. That looks plausible to me, because only iscont_i is checked there. So NativeCallOps probably needs
some more adjustment.
oops, that is exactly the same error that Nicholas++ mentioned in his PR a few seconds ago!? 19:39
MasterDuke i think we need moarvm+nqp bumps 19:56
Geth nqp: cf5b93884c | (Daniel Green)++ | tools/templates/MOAR_REVISION
Bump MoarVM for CArray fix
 20:23
rakudo: acc093c18b | (Daniel Green)++ | tools/templates/NQP_REVISION
Bump NQP for CArray fix
20:31 nebuchadnezzar left, nebuchadnezzar joined
vrurg dogbert11: have you opened an issue on that? 20:41
lizmat Files=1351, Tests=117094, 289 wallclock secs (34.64 usr 9.39 sys + 4013.11 cusr 322.42 csys = 4379.56 CPU) 20:45
(forgot to post that this morning) 20:46
20:53 discord-raku-bot left 20:54 discord-raku-bot joined
Geth rakudo: ac009507a2 | (Elizabeth Mattijsen)++ | t/04-nativecall/05-arrays.t
UnTODO a now passing test
 20:56
21:54 evalable6 left, linkable6 left 21:56 linkable6 joined
dogbert11 vrurg: no, but I can fix that 22:01
vrurg dogbert11: No, it's not a bug. 22:02
Remember that method call has tighter precedence. 22:03
So, you got not a regex smartmatch but a list smartmatch. m: produces a list of Match objects too. But smartmatch knows it is a regex case and doesn't mangle with it. When you add a method call over m: you get a list match which has different semantics. 22:04
japhb Welp, the build failures are slowly moving later in my big module list. Current failure on Rakudo HEAD is for the Digest module: gist.github.com/japhb/68dded3c8576...fee0c2ff79 22:27
nine: ^^
MasterDuke i was happy not to have a QAST::WVal as my first child, but maybe that's just me... 22:43
22:48 sena_kun joined 22:49 Altai-man 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!