00:03 patrickb left 00:13 colomon left 00:29 sena_kun left 01:49 colomon joined 01:51 colomon left 02:23 colomon joined 02:51 Kaiepi left 02:53 Kaiepi joined, Kaiepi left 02:54 Kaiepi joined 02:55 Kaiepi left 02:56 Kaiepi joined 03:10 Kaiepi left 03:11 Kaiepi joined 06:30 Kaiepi left 06:37 Kaiepi joined, Kaiepi left 06:38 Kaiepi joined 06:39 Kaiepi left 06:40 discord61 joined, Kaiepi joined, discord6 left, discord61 is now known as discord6 06:55 discord6 left, discord6 joined 07:13 Kaiepi left 08:07 Kaiepi joined 09:16 Kaiepi left 09:22 Kaiepi joined
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.
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
10:50 sena_kun joined
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
11:02 sena_kun left 11:16 sena_kun joined 11:58 MasterDuke left
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 :)
13:02 sena_kun left 13:17 sena_kun joined, sena_kun left
Geth 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.
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…
13:30 MasterDuke joined
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
13:52 domidumont joined
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:09 sena_kun joined 14:52 domidumont left
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
15:02 sena_kun left 15:13 domidumont joined 15:18 sena_kun joined
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
15:52 patrickb joined
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
17:00 sena_kun left 17:11 discord6 left, AlexDaniel left, vrurg left, jjatria left, moon-child left, jnthn left, timotimo left, nwc10 left, patrickb left, colomon left, Geth left, robertle left, nebuchadnezzar left, unicodable6 left, committable6 left, kawaii left, Kaiepi left, samcv left, japhb left, mst left, leedo left, TimToady left, moritz left, avar left, Ulti left, jpf1 left, domidumont left, quotable6 left, bloatable6 left, benchable6 left, coverable6 left, reportable6 left, greppable6 left, nativecallable6 left, statisfiable6 left, shareable6 left, squashable6 left, tellable6 left, rba left, synopsebot left, mtj_ left, eater left, krunen left, MasterDuke left, lizmat left, releasable6 left, notable6 left, bisectable6 left, evalable6 left, DrEeevil left, ZzZombo left, AlexDaniel` left, BinGOs left, ChanServ left 17:12 patrickb joined, domidumont joined, MasterDuke joined, Kaiepi joined, discord6 joined, colomon joined, AlexDaniel joined, ZzZombo joined, Geth joined, lizmat joined, vrurg joined, robertle joined, quotable6 joined, releasable6 joined, notable6 joined, unicodable6 joined, bloatable6 joined, committable6 joined, benchable6 joined, coverable6 joined, bisectable6 joined, reportable6 joined, nativecallable6 joined, greppable6 joined, statisfiable6 joined, shareable6 joined, squashable6 joined, jjatria joined, AlexDaniel` joined, moon-child joined, nebuchadnezzar joined, samcv joined, tellable6 joined, japhb joined, evalable6 joined, mst joined, jnthn joined, camelia joined, harrow joined, dogbert17 joined, bartolin joined, Util joined, chansen_ joined, nine joined, tadzik joined, hoelzro joined, tobs joined, niven.freenode.net sets mode: +o mst, klapperl joined, timotimo joined, nwc10 joined, mtj_ joined, leedo joined, eater joined, avar joined, kawaii joined, TimToady joined, Ulti joined, jpf1 joined, krunen joined, moritz joined, ChanServ joined, BinGOs joined, DrEeevil joined, synopsebot joined, rba joined, niven.freenode.net sets mode: +o ChanServ 17:15 sena_kun joined 17:40 AlexDaniel left 17:41 AlexDaniel joined, AlexDaniel left, AlexDaniel joined 18:11 zakharyas joined 18:57 lucasb joined 19:00 sena_kun left 19:17 sena_kun joined 20:05 zakharyas left 21:01 sena_kun left 21:05 zakharyas joined 21:10 domidumont left 21:11 zakharyas left 21:16 sena_kun joined 23:01 sena_kun left 23:18 sena_kun joined