github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
07:45 sena_kun joined 07:57 Altai-man joined 07:59 sena_kun left
nwc10 good *, #moarvm 08:57
09:09 linkable6 left, evalable6 left 09:10 evalable6 joined 09:11 linkable6 joined 09:48 Voldenet left 09:54 Voldenet joined, Voldenet left, Voldenet joined
nwc10 [Coke]: what does the 6th line of the Makefile `install` target look like on OS X? 10:20
ie, lines 5 and 6 on Linux are:
$(RM_F) "$(DESTDIR)$(LIBDIR)/libmoar.so"
$(CP) libmoar.so "$(DESTDIR)$(LIBDIR)"
I'm wondering if that line on OS X is actaully expanding to
$(CP) libmoar.dylib libmoar.dylib "$(DESTDIR)$(LIBDIR)" 10:21
The other question I currently have is... 10:22
on OS X, if one runs Configure.pl with either --toolchain or --compiler or both set, are there any combinations which actually *work*? Or do even sensible options cause the build to break? 10:23
my guess is that any attempt to set --toolchain will cause the shared library in the Makefile to be libmoar.so which will break stuff 10:26
oh, but setting --compiler=clang (or --compiler=cc) will probably work (and I guess --compiler=gcc will work if there is a gcc) 10:29
10:49 Voldenet left 10:55 Voldenet joined, Voldenet left, Voldenet joined 11:54 brrt joined
brrt happy new year #moarvm 11:54
may your cars ever be followed by their cdrs 11:55
11:58 sena_kun joined 11:59 Altai-man left 12:19 brrt left
nine Darn....there's an nqp::exit that skips --full-cleanup 12:32
I think reappropriating this to do a clean shutdown instead of directly calling exit() is OK. 12:40
Well, well...made it though a full rakudo build with no ASAN warnings or errord :) 12:56
13:19 evalable6 left, linkable6 left 13:20 linkable6 joined 13:21 evalable6 joined
MasterDuke nice 13:54
Geth MoarVM/asan_fixes: 5 commits pushed by (Stefan Seifert)++ 14:57
nine Geth, that's just a rebase...
Geth MoarVM/asan_fixes: 06637032fb | (Stefan Seifert)++ | src/io/procops.c
Don't leak name of called program in MVM_proc_spawn_async
 15:01
MoarVM/asan_fixes: f14ed4f7d8 | (Stefan Seifert)++ | src/io/procops.c
Fix leak of async process data from MVM_proc_spawn_async
 15:31
nine Again, real memory leaks that will affect normal programs
15:35 sena_kun left 15:37 sena_kun joined 15:39 sena_kun left 15:41 sena_kun joined 15:57 Altai-man joined 15:59 sena_kun left 16:21 Altai-man left 16:24 sena_kun joined 16:45 patrickb joined 16:51 patrickb left 17:25 patrickb joined 17:48 patrickb left 17:49 patrickb joined
nine Holy asynchronicity batman! Properly shutting down the uv event loop is a quite intricate dance. Most of all because even the call to close the handle to the event loops wakeup signal is ansynchronous and requires the event loop to still run to get processed. 17:51
Geth MoarVM/asan_fixes: a841ecedc9 | (Stefan Seifert)++ | src/io/procops.c
Fix leak of STDOUT and STDERR handles of pipes
 17:53
nwc10 this seems totally reasonable. I mean, async is good, so clearly the more async the better. Seems to be an induction proof. :-)
who needs sanity, anyway?
and as I might have said previously, when reading some of this stuff (*not* libuv, but soemthing emulating parts of its API), I found it much easier to read with s/asychnronous/smurf/g 17:54
as it made about the same amount of actual sense
without making me annoyed.
nine Of course, uv_loop_close just returns an error code (which we of course ignored) if there's still an active handle. 17:57
18:40 zakharyas joined 18:44 sena_kun left
dogbert17 nine: might your latest commit have fixed github.com/Raku/old-issue-tracker/issues/4420 ? 18:53
nine don't think so 19:16
dogbert17 darn 19:32
19:38 leont joined 20:43 sena_kun joined 22:14 sena_kun left, sena_kun joined 22:21 sena_kun left 22:22 sena_kun joined 22:28 sena_kun left 22:41 zakharyas left

Powered by Cro and the Raku® Programming Language.

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

Thank you!