00:02 reportable6 left 00:03 reportable6 joined 01:03 committable6 left, statisfiable6 left, greppable6 left, notable6 left, quotable6 left, releasable6 left, sourceable6 left, coverable6 left, linkable6 left, squashable6 left, reportable6 left, bloatable6 left, tellable6 left, bisectable6 left, evalable6 left, benchable6 left, unicodable6 left, shareable6 left, nativecallable6 left, committable6 joined, tellable6 joined 01:04 bisectable6 joined, bloatable6 joined, unicodable6 joined, statisfiable6 joined, nativecallable6 joined 01:05 evalable6 joined, quotable6 joined, greppable6 joined, linkable6 joined 01:06 reportable6 joined 01:14 frost joined
japhb nine: FYI, installing Inline::Perl5 on a 32-bit RaspberryPi OS install, there are a lot of warnings, almost all of which are "cast to pointer from integer of different size [-Wint-to-pointer-cast], from (perl6_callbacks*) casts. 01:26
There are a couple other things, but that's most of the noise.
02:04 sourceable6 joined, notable6 joined 02:05 releasable6 joined, benchable6 joined 03:04 coverable6 joined 03:05 shareable6 joined 04:05 squashable6 joined 04:42 coverable6 left, reportable6 left, nativecallable6 left, MasterDuke left, Altai-man left, jdv left, jnthnwrthngtn left, timo left 04:43 coverable6 joined, reportable6 joined, nativecallable6 joined, MasterDuke joined, Altai-man joined, jdv joined, jnthnwrthngtn joined, timo joined 04:44 shareable6 left, leedo left, kjp_ left, leont left 04:45 shareable6 joined, leedo joined, kjp_ joined, leont joined 04:46 AlexDaniel left, psydroid left 04:48 [Coke] left, nine left, [Coke] joined, nine joined 04:50 Voldenet left, gfldex left, rba left, Voldenet joined, rba joined, gfldex joined 04:54 ugexe left, ugexe joined 05:16 AlexDaniel joined 06:02 reportable6 left 06:04 psydroid joined 06:05 reportable6 joined
nine japhb: that's odd. According to perlguts, those casts should be correct: "Perl uses a special typedef IV which is a simple signed integer type that is guaranteed to be large enough to hold a pointer (as well as an integer)." 07:02
japhb: does it tell you what the actual sizes both sides of the casts are? 07:05
japhb nine: Gah, looks like it disappeared from my scrollback. Now expanding scrollback and forcing a reinstall .... 07:23
*Jeopardy! theme music ...* 07:25
As a side note while I wait, so far I'm finding the RPi4 with a 32-bit OS is around 5-6x slower running Rakudo than my x64 laptop. Not as bad as I feared, but certainly enough to make slow stuff REALLY slow. 07:28
WTH? Completely silent install this time ...?
Is there something that wouldn't necessarily rebuild if reinstalled with `zef install Inline::Perl5 --force-install`? 07:29
nine Do you install with zef? That may have cached the build directory so the previously compiled library may still be there
japhb Hmmm, lemme try nuking that
nine Easiest way is git clone github.com/niner/Inline-Perl5.git ; cd Inline-Perl5 ; rakudo configure.pl6 ; make 07:30
japhb OK, I'll try that after this run (I just nuked ~/.zef/store/Inline-Perl5-0.54.tar.gz, and reran the zef install) 07:31
Yup, nuking that zef store dir worked.
No, it doesn't say what the actual types/sizes mismatched were for the declare_cbs macro warnings. One thing I do notice is that one of the rare wornings is in p5_call_gv_two_args, it's a format string error -- but the exact mismatch there might say something. Gimme a sec. 07:34
warning: format '%d' expects argument of type 'int', but argument 3 has type 'I32' {aka 'long int'} [-Wformat=] 07:35
Sounds like int is short on this build?
Is there a way to get more detail from gcc's warnings? (If it matters, it appears to be gcc 8.3.0) 07:37
`perl -V` shows intsize=4 longsize=4 ptrsize=4 but ivtype='long long' 07:40
(and thus ivsize=8)
Hmmm ... use64bitint=define use64bitall=undef 07:41
I guess this could mean that the mismatch is that IV is larger than *. IV is guaranteed to be large enough, but not necessarily the *same* size, from that perlguts bit you quoted. 07:49
japhb heads off to the land of nod ... & 07:50
nine japhb: ok, that means that the code is actually correct, indeed. But only in practice, since I know that these IVs will only ever hold pointers, so the upper 32 bits will be 0 and we can safely ignore them. 07:55
I do have a fix for the format string warnings at least 07:56
09:00 quotable6 left, bisectable6 left, committable6 left, benchable6 left, linkable6 left, evalable6 left, bloatable6 left, greppable6 left, unicodable6 left, notable6 left, tellable6 left, squashable6 left, statisfiable6 left, sourceable6 left, releasable6 left, shareable6 left, reportable6 left, nativecallable6 left, coverable6 left 09:01 quotable6 joined, bisectable6 joined, bloatable6 joined, squashable6 joined 09:02 statisfiable6 joined, tellable6 joined, greppable6 joined, coverable6 joined 09:03 reportable6 joined, committable6 joined 10:00 sourceable6 joined 10:02 unicodable6 joined 10:03 shareable6 joined, nativecallable6 joined 11:01 notable6 joined 11:36 sena_kun joined 12:00 releasable6 joined 12:02 benchable6 joined, evalable6 joined, reportable6 left 13:02 linkable6 joined 13:11 frost left 14:04 reportable6 joined
lizmat And yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2021/08/16/2021-...cumbering/ 14:12
14:45 discord-raku-bot left, discord-raku-bot joined 14:47 discord-raku-bot left 14:48 discord-raku-bot joined 15:01 discord-raku-bot left, discord-raku-bot joined, TempIRCLogger left 15:02 TempIRCLogger joined 16:12 njm joined 18:02 reportable6 left 18:25 vrurg left 18:28 sena_kun left 18:29 vrurg joined 18:30 njm left
nine For the new-disp implementation of nqp::hllize: dispatchers are cached at the callsite. The callsite will never change its language, so we don't need to guard on that. Types won't change their language either, so a guard on type (which we're gonna need anyway) will implicitly guard on the object's language as well. 19:09
The tricky bit seems to be actually finding out the language at the callsite. 19:31
MasterDuke i assume 6.c and 6.d are the same languages? 19:32
nine Yes, but Raku and NQP are not
Ah, it may not be that hard after all. The nqp::hllize op will desugar into an nqp::dispatch('lang-hllize', $obj); This op will be part of the same frame, i.e. MVM_hll_current will give us the target HLL. 19:57
We can then statically delegate to the registered hllize dispatcher for that HLL.
The dispatch program we create during this process will run in a different frame, but that doesn't matter, since the target language is kinda statically compiled into this dispatch program anyway. 19:58
Ok, the lang-hllize dispatcher implementation in C compiles. That means I'm almost done, right? :D 20:16
The desugar and registration of the HLL's hllization dispatcher work as well and a test in NQP with funnylang works as intended. 20:38
So, a good start for today :)
MasterDuke nice 21:03
21:04 reportable6 joined 23:36 evalable6 left, linkable6 left