github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
Geth MoarVM: MasterDuke17++ created pull request #1312:
Fix some possible double frees		 07:42
dogbert17 o/ 14:16
Geth MoarVM: 28dc282b99 | (Jan-Olof Hendig)++ | src/spesh/optimize.c
Add missing concreteness check

The missing check led to a noticable performance regression.
  [Tux]++ for spotting.		 14:43
MoarVM: 3256f14509 | dogbert17++ (committed using GitHub Web editor) | src/spesh/optimize.c
Update optimize.c
MoarVM: ba34447cd9 | (Jimmy Zhuo)++ (committed using GitHub Web editor) | src/spesh/optimize.c
Merge pull request #1311 from dogbert17/fix-perf-regression

Add missing concreteness check
bartolin_ I'm no longer able to build MoarVM on FreeBSD (11). It seems to be a problem with the new libuv version. The error happens in step 'linking moar': ./libmoar.so: undefined reference to `uv__process_title_cleanup' 17:08
timotimo are you building with system libuv or the subrepo one? if so, which commit is checked out locally for you? 17:11
bartolin_ I've removed the system libuv (to be sure), so it should be the subrepo one. I'm on b9fa480ad1. 17:12
timotimo i've got e45f1ec38db882f8dc17b51f51a6684027034609 which is tag: v1.35.0 17:14
linkable6 (2020-03-11) github.com/libuv/libuv/commit/e45f1ec38d 2020.03.12, Version 1.35.0 (Stable)
timotimo timo@schmand ~/p/m/3/libuv ((v1.35.0))> git show b9fa480ad1 17:15
linkable6 (2020-06-12) github.com/MoarVM/MoarVM/commit/b9fa480ad1 Merge pull request #1302 from dogbert17/update-libuv-2-v1.38.0
timotimo fatal: ambiguous argument 'b9fa480ad1': unknown revision or path not in the working tree.
oh that's a moarvm commit
can you check "git show" inside of 3rdparty/libuv?
bartolin_ yes, sorry I misunderstood. Its 1ab9ea3790378f9f25c4e78e9e2b511c75f9c9ed (tag v1.38.0) 17:16
linkable6 (2020-05-17) github.com/libuv/libuv/commit/1ab9ea3790 2020.05.18, Version 1.38.0 (Stable)
timotimo haha, oops, does that mean i'm out of date
bartolin_ there was this update the other day: github.com/MoarVM/MoarVM/commit/b9...75b23660e7
yepp
dogbert17 hides 17:17
timotimo all i see mentioning the title_cleanup is a pull request that's not yet merged 17:18
dogbert17 bartolin: perhaps your problems are related to this commit github.com/libuv/libuv/commit/72fe...ae4da5706c 17:30
I'm no expert on build systems but could it be that we need to make some changes to MoarVM/build/Makefile.in given that uv__process_title_cleanup was moved in the above commit 17:32
bartolin_ is looking 17:34
dogbert17 eyes github.com/MoarVM/MoarVM/blob/mast...le.in#L480 17:35
bartolin_ I'll try to include bsd-proctitle 17:36
dogbert17 bartolin: if it works do you think it should be added to the other bsd's as well, e.g. NetBSD? 17:38
bartolin_ \o/ that makes the error go away. And yes, looks like we need it for others, too.
I'll try to build Rakudo first. dogbert17++
Geth MoarVM: usev6++ created pull request #1313:
Fix build on FreeBSD		 18:05
bartolin_ spectest is still running, but everything looks good so far. I'm not totally sure my changes are good (esp. for OpenBSD and NetBSD), but I suspect the builds on those OSes are failing right now, too 18:07
hmm, I've got two failing tests: github.com/Raku/roast/blob/master/...#L467-L469 Looks like the backtrace has 5 instead of 4 elems. That test passed the last time I tried (2020-06-08). 18:33
MasterDuke yeah, same here 18:36
bartolin_ ok, thanks! 18:37
lizmat yeah... I've no idea what changed there... I also couldn't get it bisected :-( 18:51
Geth MoarVM: 20a2a9114c | (Christian Bartolomäus)++ | build/Makefile.in
Introduce UV_BSD to avoid duplication in Makefile
 19:31
MoarVM: 06f041fb08 | (Christian Bartolomäus)++ | build/Makefile.in
Fix build an FreeBSD

  ... and other BSD as well, hopefully. The build failed in
step 'linking moar', because of:
   ./libmoar.so: undefined reference to 'uv__process_title_cleanup'
  dogbert17++ pointed to the changes in
  github.com/libuv/libuv/commit/72fe3543fe and that we
probably have to adjust our Makefile.
MoarVM: e1de261825 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | build/Makefile.in
Merge pull request #1313 from usev6/bsd_proctitle

Fix build on FreeBSD
dogbert17 bartolin_++ 19:36
dogbert17 doesn't see the errors in S32-exceptions/misc.t 19:37
lizmat on HEAD ? 19:39
which OS?
timotimo i swear i've read "proctitle" as "projectile" at least five times today 19:42
lizmat MasterDuke: JSON::Fast is still borked, but I assume you know that 19:54
MasterDuke lizmat: github.com/MoarVM/MoarVM/pull/1312 fixes it for me, if someone wants to give that a once over before merging 19:55
lizmat and magically the backtrace tests pass again
yeah, I felt uncomfortable merging that one :-) 19:56
Geth MoarVM: 8eb5523231 | (Daniel Green)++ | 9 files
Fix some possible double frees

These were introduced by github.com/MoarVM/MoarVM/pull/1291 in an attempt to not leak data that had been alloced before a throw. However, in some cases the alloced storage had already been attached to GC-managed objects, so if the throw was caught and GC cleaned up the parent object, the storage was freed twice. Fix by only attaching the alloced storage to the parent object after the throw might have happened, so it can be safely freed before the throw.		 20:00
MoarVM: 02c8cf777d | (Jonathan Worthington)++ (committed using GitHub Web editor) | 9 files
Merge pull request #1312 from MasterDuke17/fix_some_possible_double_frees

Fix some possible double frees
MasterDuke lizmat, sena_kun: ^^^ afk for a bit, but after a bump json::fast should be good 20:04
lizmat sena_kun: did you start Blin already ? 20:05
sena_kun Yes.
Should I stop?
lizmat ok, then I'll hold off bumping :-)
no... we know this issue, so if JSON::Fast comes up... we'll know what it its
*is
or do you prefer getting that fix in as well for the Blin run ? 20:06
MasterDuke it might well have caused problems elsewhere, i'd recommend running with it in 20:07
sena_kun has stopped blin 20:09
lizmat ok, will start bumping then
sena_kun lizmat, thanks.
lizmat sena_kun: bumped 20:28
sena_kun started again, thanks
lizmat MasterDuke: sadly this doesn't fix JSON::Fast 20:29
well, it fixes the panic, but now that test fails
sena_kun tries to bisect it 20:30
lizmat oops, false alarm 20:32
it's another test that fails
sena_kun just ran blin and went afk 20:33
lizmat and it's a TODO test
so JSON::Fast should be ok again

Powered by Cro and the Raku® Programming Language.

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

Thank you!