github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
nine .tell robertle yes, writeuint is an integral part of every compilation. There's no way around it if you want to generate bytecode. Which makes your result all the more baffling. 07:17
yoleaux nine: I'll pass your message to robertle.
robertle morning 07:46
yoleaux 07:17Z <nine> robertle: yes, writeuint is an integral part of every compilation. There's no way around it if you want to generate bytecode. Which makes your result all the more baffling.
robertle yes, I was stupid yesterday evening. I thought re-running "make" in nqp was enough, but apparently I need to re-run Configure.pl as well. anyway, on s390 OP(writeuint) always goes through the byte-swapping branch, never through the else branch 07:48
yet I still get the "Bytecode stream version too high"
xlat Hi, I'm trying to build nqp+moqrvm to test stackoverflow.com/questions/536915...ted-result 08:05
Moarvm has compiled fine, but nqp / gmake command failed with: MoarVM op 'writeint' is unknown as a core or extension op 08:06
any idea how to fix that ? 08:07
nwc10 Hi xlat. Sorry, I don't know, and I don't even have a good idea where to start. 08:54
I suspect that the silence means that no-one awake feels confident to suggest what to do next
xlat I've tryed to regress nqp of some commits, but it was too old for the vm i think; 08:59
maybe I've done something wrong; after build MVM; I've copied moar.exe, moard.dll and libmoar.dll.a in c:\rakudo\bin. 09:02
then tryed perl6 and got p6captureouters second arg must be MVMCode at src/Perl6/World.nqp:3965 (C:\rakudo\share\nqp\lib/Perl6/World.moarvm:resolve) ... 09:03
so I decided to build nqp from source
with: perl Configure.pl --backends=moar --prefix=c:\rakudo & gmake 09:04
And I got the nqp build error with writeint
robertle xlat: does your nqp commit roughly match the moar one? they need to be in-sync-ish 09:14
xlat nqp is b4de55eda64a03f72656336457bcd059194fb0a1, moarvm is 0d5f389c35b9b287f5af063ea00b02e10d3bc026 09:27
how to check for them to be in-sync-ish ? 09:28
jnthn If you grab Rakudo and `perl Configure.pl --gen-moar` or some such then it'll build a compatible MoarVM and NQP automatically for you with matching versions. 09:41
(Pass --prefix to tell it where to put the install)
xlat the trick is that I want to build a patch moarvm 09:45
jnthn It does a MoarVM git checkout, so you can still do that once you get a working build. Just make your changes and `make install` in MoarVM afterwards. 09:47
xlat s/patch/patched/
ok, I'll try it 09:48
xlat thank you all; that's worked fine now 10:36
Geth MoarVM: xlat++ created pull request #1018:
keep end of string bytes \x0000		 10:55
xlat So I fill github.com/MoarVM/MoarVM/issues/1017 and PR mentionned above 10:56
Geth MoarVM: lizmat assigned to niner Issue nqp::readnum appears to ignore size flag github.com/MoarVM/MoarVM/issues/1020
35ea958185 | (Stefan Seifert)++ | src/core/interp.c

We were detecting the neccessity of switching correctly but also need to differentiate on the target endianness.		 12:31
nine OMG I finally got the powerpc VM to boot and successfully compiled MoarVM 19:37
brrt \o/ 19:38
nine++
nine And it's indeed massively faster than the mips VM. Taking just about a minute to compile interp.c 19:43
brrt how'd you get a powerpc vm? 19:47
nine Third is the charm. After the Debian and openSUSE failures I managed to install Ubuntu. That however told me at the end of the installation that it won't install a boot loader. Today I managed to extract the initrd and kernel from the VM image and boot those directly 19:48
brrt fuu 19:49
nine And I did get past the "Bytecode stream version too high" error, but it's weird. 19:54
Well actually it's my code that doesn't make any sense at all. 19:56
This code will always write in big endian when the target endianness differs from the native one: github.com/MoarVM/MoarVM/blob/mast...rp.c#L5412 19:57
Which satisfies the tests I wrote but is bound to fail when the target is little and the native one is big :) 19:58
nine Yep, looks much better. Except for labels being broken 20:11
nine robertle: this is it! 20:30
robertle awesome, will give it a go in one sec! 20:37
any specific commits, or just the tip of master of both? 20:40
nine master
travis-ci MoarVM build errored. Stefan Seifert 'Fix bytestream ops always converting to big endian if a switch is necessary 20:48
travis-ci.org/MoarVM/MoarVM/builds/466688783 github.com/MoarVM/MoarVM/compare/0...ea958185e2
robertle moar g35ea95818 and nqp gf8e87c58c, works like a charm! awesome stuff! 20:51
Geth MoarVM: 437d5b0105 | (Stefan Seifert)++ | 2 files
Fix big endian (read|write)u?int of < qword on big endian systems

When not memcpying a full qword, we need to index into the source or target 64 bit value to get the interesting part on big endian systems. On little endian systems, smaller words are naturally aligned at the lowest address.		 21:28
nine This commit fixes the test failure of moar/13-writeint.t on big endian systems. 21:29
lizmat nine: stable enough for a bump?
m: dd blob8.new(255).read-int8(0) # nine: does this fix this? 21:30
camelia 255
travis-ci MoarVM build errored. Stefan Seifert 'Fix big endian (read|write)u?int of < qword on big endian systems 21:43
travis-ci.org/MoarVM/MoarVM/builds/466712571 github.com/MoarVM/MoarVM/compare/3...7d5b0105bc

Powered by Cro and the Raku® Programming Language.

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

Thank you!