github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
Geth MoarVM: 47892d379c | (Stefan Seifert)++ | 7 files
Avoid signedness issues by using MVMuint8 in stream decoder

char may be signed or unsigned depending on compiler and architecture.
09:46
MoarVM: eb3d981d75 | (Stefan Seifert)++ | 2 files
Do not rely on signedness of char in (gb2312|gb18030)_decode

char may be signed or unsigned depending on compiler and architecture. Use MVMuint8 internally instead. Fixes compiler warnings on ARM.
nine With this we consistently use MVMuint8 internally in string processing (encoding and decoding) while we continue to use char * in interfaces. 09:48
We were already rather close to that anyway. 09:49
dogbert17 nine++ 10:06
and the failing tests now passes on the RPi 4, yay 10:09
nine If nothing else comes off this work, at least I've learned a lot about C in this endeavour :) 10:22
dogbert17 nine: are you done with the cleanup or do you intend to fix even more stuff? 10:40
nine Well for now I'm finally working of fixing my NativeCall screwup. 10:42
dogbert17 the one you mentioned the other day
nine yep 10:43
nine I think I'll add a flag to the NativeCall repr, so the higher layer can indicate whether it's safe to serialize the lib_name. And a similar flag to Distribution::Resource. That way CompUnit::Repository::Staging can prevent the build path from getting serialized. 10:51
The cost is having to go through the generic NativeCall wrapper during the BUILD with the Staging repo and during the first call of a native sub of a module loaded from a package. 10:53
Initially I thought I thought I could get away with being able to serialize a different lib name than the one used for setup. But a module installed into the Staging repo may get used (and one of its native subs called) during the build of another module in the same repo. In that case it would'nt find its library. 10:56
dogbert17 nine: wrt the warnings you fixed. Is it your intention to keep the 'extra' compiler options which shows them all or will they be removed now? 12:23
nine Oh keeping those was very much the point of fixing the existing violations 12:30
dogbert17 the reason for asking is that the gcc (8.3.0) on the RPi 4 enables -Wunused-variable which in turn leads to a mass of warnings 12:33
I guess that the gcc devs changes what the 'extra' options does from time to time 12:34
nine -Wunused-variable seems to be included in -Wall already, which is why I fixed a host of them: github.com/MoarVM/MoarVM/commit/75...02b9fb6c25 12:36
Don't know why your gcc would show additional ones though. Could be that they are in code paths that only get compiled on ARM? 12:37
dogbert17 aha, so perhaps it's an RPi specific problem, What happens is that the same warning is printed like 100 times, more specifically this one: 12:38
src/core/interp.h: In function ‘MVM_BC_get_N64’:
src/core/interp.h:119:27: warning: unused variable ‘where’ [-Wunused-variable]
const MVMuint8 *const where = cur_op + offset;
Geth MoarVM: be5f206c85 | (Stefan Seifert)++ | src/gc/collect.c
Remove bogus debug assertion in the GC's process_worklist

The assertion checks if a pointer the GC encountered hasn't already been updated to the object's new location. It was added in the early days and the author nwc10 doesn't seem to remember the reason behind it.
In the case in which the assertion would fail, the pointer would just get ... (5 more lines)
nine dogbert17: ah, of course. The variable is used in code depending on MVM_CAN_UNALIGNED_NUM64 which x86 does but ARM doesn't
So moving it down a line will fix the warnings
Sames is true for MVM_BC_get_I64 12:40
dogbert17 it doesn't complain about the last one though 12:41
nine still true
dogbert17 let me give it a try 12:43
yes, that change led to a massive improvement 12:46
among the ones that are left I see something I missed yesterday 12:47
src/strings/ascii.c: In function ‘MVM_string_ascii_decode’:
src/strings/ascii.c:18:27: warning: comparison is always true due to limited range of data type [-Wtype-limits]
else if (ascii[i] >= 0) {
nine Oh, and I missed that file today. MVM_string_ascii_decode should really use an MVMuint8 internally, like here: github.com/MoarVM/MoarVM/blob/mast...atin1.c#L8 12:51
dogbert17 perhaps I should fix that so that you can concentrate on the Nativecall stuff 12:54
nine would be nice :) 12:55
dogbert17 :)
Geth MoarVM: dogbert17++ created pull request #1219:
Move incorrectly placed variable declaration which causes a lot of wa…
13:18
dogbert17 There's one of them. I only changed MVM_BC_get_N64 as MVM_BC_get_I64 looks legit to me, i.e. 'where' is used in both branches there 13:19
nine Oh, right! 13:20
Geth MoarVM: 4924390c76 | (Jan-Olof Hendig)++ | src/core/interp.h
Move incorrectly placed variable declaration which causes a lot of warnings on ARM

MVM_CAN_UNALIGNED_NUM64 is not used by ARM, it is on x86 though, which in turn leads to gcc outputting a bucketload of unused-variable warnings on ARM based systems like e.g. the RPi.
13:21
MoarVM: 47a0beb6d6 | niner++ (committed using GitHub Web editor) | src/core/interp.h
Merge pull request #1219 from dogbert17/fix-warnings-on-ARM

Move incorrectly placed variable declaration which causes a lot of wa…
MasterDuke these are the warnings i currently see when building moarvm with gcc gist.github.com/MasterDuke17/71f16...7c94a0051b 13:33
nine MasterDuke: well....fix them? :) 13:38
MasterDuke heh, i probably will give it a go later. i also see some when building nqp and rakudo (mostly in the runner code), will ping patzim about them 13:41
Geth MoarVM: 610e05fa0f | (Stefan Seifert)++ | 2 files
Give upper layers a way to veto serializing a NativeCall's lib_name

There are cases where we actually don't want the library's path to get serialized into the bytecode file, e.g. when building a module into a Staging repository for packaging. Give the upper layer a way to make us aware of that by having them set the "serialize_lib_name" attribute on the native callsite.
14:04
dogbert17 MasterDuke: btw, there's a possibility that M#1093 has been fixed. Have you had the chance to try it on your system? 15:01
synopsebot M#1093 [open]: github.com/MoarVM/MoarVM/issues/1093 SEGV when using Proc::Async
dogbert17 hmm, I just got two SEGV's while running a spectest 15:22
dogbert17 tries to repro ... 15:33
nine Did you get core dumps? 15:36
dogbert17 I did, but the first one was overwritten by the second and that one looked messed up 15:39
besides, I suspect that I didn't have debug info on 15:40
nine systemd is really great in these cases. I get all my core dumps compressed and named after the executable + timestamp in /var/lib/systemd/coredumps 15:41
dogbert17 do you have to do anything specific in order to get that behavior
fwiw, the failing files were t/spec/S07-hyperrace/for.t and t/spec/S32-io/io-cathandle.rakudo.moar 15:44
nine I didn't do anything. May be openSUSE'd defaults. man systemd-coredump should be a good start
dogbert17 will check 15:45
dogbert17 also, t/spec/S16-io/watch.t is flapping 16:25
lizmat dogbert17: on what OS 16:26
?
dogbert17 Linux 16:27
lizmat ok, then I have no idea
MacOS sometimes gets sluggish in delivering events when under load
dogbert17 it seems to be the same for me, running a spectest in the background makes the error appear rather quickly 16:36
it always claims to have missed one of the 10 events it is looking for
interesting, one of the test files, i.e. t/spec/S29-os/system.t, can actually trigger a core dump without any tests failing 16:54