Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
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.
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
lizmat And yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2021/08/16/2021-...cumbering/ 14:12
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