| IRC logs at
Set by AlexDaniel on 12 June 2018.
00:28 ggoebel_ left 01:44 travis-ci joined
travis-ci MoarVM build failed. Nicholas Clark 'oops if MVM_fixed_size_alloc() is called for a size of 0 bytes. 01:44
01:44 travis-ci left
Geth ¦ MoarVM: coke self-unassigned Error!!! 02:15
nwc10 good *, #moarvm 05:09
06:53 patrickb joined
patrickb o/ 06:57
nwc10 \o 06:58
patrickb I'd like to merge and the respective Rakudo PR soonish to give it at least a little exposure before the upcoming release. Any objections? 07:01
07:16 patrickb left 08:19 domidumont joined 08:40 zakharyas joined 09:12 sena_kun joined 09:35 zakharyas left, zakharyas joined 13:03 zakharyas left 13:14 squashable6 left 13:15 squashable6 joined 13:30 domidumont left 14:01 domidumont joined 14:07 domidumont left 14:11 domidumont joined 14:15 zakharyas joined 14:28 domidumont left 14:29 domidumont joined 14:40 domidumont left 15:09 domidumont joined 15:34 domidumont left
Geth MoarVM/hash-bits-in-metadata: 21798ee146 | (Nicholas Clark)++ | 2 files
Fix some errors in the previous explanatory comments, and add even more.

  (Even more explanatory comments, that is. Not errors. I hope.)
16:19 sena_kun left 16:20 sena_kun joined
lizmat :-) 17:11
[Coke] HA 17:14
18:02 zakharyas left 18:21 patrickb joined
nine Looks like mixins are still an issue 18:45
lizmat :( 18:46
nine I think...its about parametric types used as parameters for a mixin.
When processing the param interns table, we deserialize the involved types (including those used as parameters). 18:47
When we find an existing matching parametrization, we replace the parametrization's slot in the serialization context with what we found, so when deserializing in the future, we find what we want.
But...when we don't find one, we leave it as it is. 18:48
My hypothesis is that this unique parametric still references the un-interned object for its parameters, even if we later found that parameter as its own entry in the param interns table and replaced it in the SC
19:12 sena_kun left
Geth MoarVM: dc50edddc3 | (Nicholas Clark)++ | build/
For the pthread_setname_np probe, use an auto char array instead of malloc.

There's no requirement from the API of pthread_setname_np to pass in a pointer from `malloc`. However, as the probe had been implemented, it would fail under an ASAN build, thus would incorrectly assume that pthread_setname_np was not available. because ASAN defaults to leak checking on exit, the leak checking is aggressive and sets a non-zero exit code on leaks, and `malloc` without `free` is a leak.
Hence use a char array, and avoid `malloc`. This way the probe also passes under ASAN, and we get to test the relevant runtime code with ASAN too.
20:06 zakharyas joined
timotimo wow 20:13
good catch
nwc10 it's *kind* of easy because it's been spewing colourful warnings at me for some weeks 20:24
I'd just been busy with everything else. And now things have calmed down enough to get to *that*
timotimo d'oh :)
nwc10 (next, we have, lots of warnings from on platforms-that-are-not-x86_64 - eg because char is signed, because long is not 64 bits, etc) 20:25
(big endian failures)
(spectest that appear to be failing only because I have MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 set)
and no promises if/when I ever get to these
nine Oh, the parametrization issue is actually a bit worse: during resolve_param_intern we load a parameter that is a P6opaque with a not-yet-interned parametric in one of its attributes. That's the pointer that will keep pointing at a non-interned parametric 20:26
nwc10 however, right now I probably *should* get to bed because the evil alarm clock announces "good morning" rather sooner thnna I would like
nine nwc10: it always does...
nwc10 nine: it's going to take more than coffee?
nine might take some actual branes... 20:27
nwc10 school starts at 07:45 and my daughter is nowhere near as efficient as I am at getting out of the house in the morning as I am
(or was, until the "office" became the cellar) 20:28
[Coke] "out of the house"? Luxury.
nwc10 yes, quite. I got to the post office today
you're supposed to *take* the feed line and say something. So that I can reply that the purpose of the trip was to mail my tax return. :-/ 20:30
(Because it was, and it's done now. At least, I have a tracking code and I now get to see whether it arrives)
Geth MoarVM: 882dbf04a6 | (Patrick Böker)++ | 4 files
Add a function to fix up the STD IO handles

This is in preparation for a Rakudo fix that will make sure Rakudo won't silently die if the STD handles are used on Windows in
  "windows"-subsystem executables. (`rakudow.exe`, `rakuw.exe` and
MoarVM: 4b06df1a61 | (Patrick Böker)++ (committed using GitHub Web editor) | 4 files
Merge pull request #1361 from patrickbkr/subsys-win-no-die-on-stdout

Add a function to fix up the STD IO handles
nine My ideas so far are to * take a snapshot of the SC's root objects and root stable tables before resolve_param_interns and restore that afterwards (modulo the modifications we want to do as part of interning) or * introduce a flag to deserialization preventing it from writing to those tables in the first place 20:53
20:53 zakharyas left
nine I think the flag would be easier but of course, there could be unanticipated side effects, e.g. if the same object would be requested twice for the same parametric, we'd actually end up with two different objects 20:54
But first...bed...
20:57 patrickb left
[Coke] nwc10: so sorry, I was off stage. :) 20:58
22:40 linkable6 left, evalable6 left 22:41 linkable6 joined 22:43 evalable6 joined 23:33 nebuchadnezzar left 23:34 nebuchadnezzar joined