00:46 Ven joined 01:06 colomon joined 01:10 tokuhiro_ joined 01:35 flussence joined, ilmari joined 01:38 flaviusb joined 01:47 Ven joined 02:54 Ven joined 03:06 tokuhiro_ joined 04:00 Ven joined 05:03 Ven joined 05:43 japhb joined 05:49 japhb joined 06:04 Ven joined
nwc10 good *, #moarvm 07:04
07:11 ilmari_ joined 07:14 Hotkeys_ joined 07:16 domidumont joined 07:18 domidumont joined 07:19 domidumont joined 07:21 domidumont joined 07:22 brrt joined
nwc10 brrt: thanks for figuring out what needing tweaking to fix timotimo's JIT stuff. 07:30
brrt yw :-)
i had no idea that jit-on-mingw was so broken, by the way 07:32
luckily mingw comes with gdb
i can hardly imagine this to be anything but a configuration error of some kind
there shouldn't really be ABI differences...
07:47 FROGGS joined 08:05 zakharyas joined
brrt oh, i know how to solve the broken-expression problem 08:32
i need to revive a somewhat-old idea, the spesh iterator 08:34
rather than demanding the expression tree builder always consumes a full basic block, it can simply consume a part, then return, then continue 08:40
after the appropriate labelling is done
09:14 Ven joined
jnthn moarning, #moarvm 09:19
brrt++ # JIT fixes 09:20
brrt moarning jnthn 09:24
oh, jnthn, i have a supsicion i want to run by you 09:27
on x64-mingw, during setting compilation, we crash in an invalid longjmp 09:28
how.. does that even happen?
it doesn't happen in vs2013, at least
jnthn o.O 09:29
The only place we longjmp that I'm aware of is to the interpreter
On exceptions
brrt hmm
google has some answers it seems
lists.llvm.org/pipermail/llvm-dev/2...84888.html
jnthn I could imagine mingw and vs2013 result in us using a different longjmp implementaiton 09:30
jnthn looks
brrt ok, we can do that... 09:31
msdn.microsoft.com/en-us/library/f...2147217396 is the article
msdn.microsoft.com/en-us/library/w...85%29.aspx is the API call 09:32
jnthn But wait, it works under MSVC?
brrt oh, we can totally manage that 09:33
it hasn't failed yet
jnthn Oh. :-)
So we're getting away with things? :) 09:34
brrt but at any rate, i think this is indeed a longjmp-implementation-difference
yes
09:35 cygx joined
cygx o/ 09:35
brrt \o cygx
we may have the reason for the JIT-on-mingw not working
cygx Mmingw apparently also provides a ms_longjmp function
brrt aha
cygx * MinGW
brrt and the difference is?
cygx no idea yet, I just saw it in their header - from the name I'd guess this exposes the MS libs implementation instead of their custom one 09:36
but that's just a guess, might be something totally different 09:37
cygx goes googling
brrt hmmm 09:38
brrt has to go afk
see you later
cygx ~~ 09:39
09:51 domidumont joined
cygx google has failed me, and if you try to call ms_longjmp, moarvm fails to link 09:52
so no idea what that function is supposed to do...
10:13 domidumont joined 10:19 Ven joined
cygx brrt: cf gcc.gnu.org/ml/gcc/2011-10/msg00257.html 10:25
according to the follow-up, it's supposed to be _setjmp3, but youll have to link against msvcrt to get that symbol
in my quick test, just doing a #define setjmp(BUF) _setjmpex((BUF), NULL) at the top of interp.c already works 10:26
psch github.com/MoarVM/MoarVM/pull/296 10:31
nqp and Rakudo both test clear with that
dalek arVM: b370dd9 | peschwa++ | src/core/interp.c:
Check if the *next* outer is null.

Otherwise there's cases where we do go one too far and SEGV after the while.		 10:48
arVM: 41d9376 | jnthn++ | src/core/interp.c:
Merge pull request #296 from peschwa/master

Check if the *next* outer is null.
11:21 Ven joined
cygx jnthn: brrt: putting gist.github.com/cygx/aae672dcb8eb8a5ed0c5 at a convenient location (interp.c, moar.h, a custom platform header...) makes the JIT on MinGW happy 11:27
JimmyZ oh, would be nice to have a src/platform/setjmp.h then 11:34
:)
jnthn I'm tied up with a hairy args flattening refactor/bug fix for now, so if somebody else wants to take care of that, please do :) 11:36
cygx jnthn: I'm guessing brrt will take a look at that later 11:37
there's no rush
it has been broken for ages, I can wait another day or two ;)
timotimo take a long look, don't just jmp to conclusions 11:39
cygx jnthn: when you have some time, could you also take a look at github.com/MoarVM/MoarVM/issues/295 to decide on an approach (assuming my analysis is correct)? 11:44
jnthn cygx: There alreayd is a mechanism for "release this mutex on exception", which we use in the I/O code. 11:49
*already 11:50
cygx even better
looks like MVM_tc_set_ex_release_mutex? 11:52
that would be my idea about keeping a list of mutexes to be release, except that list is length 1 ;) 11:53
jnthn :) 11:54
Yeah, I figured it'll be easy to refactor to a list later if needed.
But YAGNI
cygx github.com/MoarVM/MoarVM/pull/297 12:07
dalek arVM: f9611b4 | cygx++ | src/core/loadbytecode.c:
release mutex in MVM_load_bytecode on exception
 12:16
arVM: 7f1f840 | (Jimmy Zhuo)++ | src/core/loadbytecode.c:
Merge pull request #297 from cygx/loadbc-mutex

release mutex in MVM_load_bytecode on exception
timotimo do you think we've ever deadlocked on this problem cygx just fixed? 12:17
jnthn Not sure
I think there was some report of a deadlock involving threads and require that may be related
JimmyZ as long as culri branch got merged ? :P 12:19
cygx note that it would have only triggered if mapping the file fails, which doesn't happen all that often if you check for file existence beforehand during path resolution 12:20
timotimo ah
fair enough
jnthn Still work fixing :) 12:21
timotimo agreed
cygx I stumbled upon it because nine wanted to know if it's safe to just try to nqp::loadbytecode and proceed if it fails
12:24 Ven joined
jnthn lunch & 12:31
12:44 flaviusb joined 13:27 Ven joined
jnthn bah, of all the tests to regress... 13:58
sub foo(:$) { }; foo |{ '' => 42 }
That's the only spectest my refactor has bust. What on earth...
nwc10 m: say 42.why
camelia rakudo-moar b18ada: OUTPUT«Method 'why' not found for invocant of class 'Int'␤ in block <unit> at /tmp/kY6T9fkFWL:1␤␤»
nwc10 there's a special case on 42, isn't there? 13:59
jnthn m: say 42.WHY
camelia rakudo-moar b18ada: OUTPUT«(Any)␤»
JimmyZ m: 42.WHAT 14:06
camelia ( no output )
JimmyZ m: say 42.WHAT
camelia rakudo-moar b18ada: OUTPUT«(Int)␤»
nwc10 m: say 17.WHAT
camelia rakudo-moar b18ada: OUTPUT«(Int)␤»
dalek arVM/callsite-memory-leak: d976477 | hoelzro++ | src/ (4 files):
Restore "Track whether or not a capture owns its callsite"

This reverts commit 9befd69353643bff3a529aa5bea8101cd574fa29.		 14:11
arVM/callsite-memory-leak: 5c9262d | hoelzro++ | src/core/args.c:
Just check arg_flags to know whether or not to get rid of them

One, arg_flags should know best. Two, checking the callsite object is checking an object we don't own, and may be invalid by this point in the program.
MoarVM/callsite-memory-leak: 88d0067 | hoelzro++ | src/core/args. (2 files):
MoarVM/callsite-memory-leak: HAve MVM_args_proc_to_callsite tell the caller if the a new owner is needed
jnthn Wow, it appears that test may have passed for entirely the wrong reason
Or rather, I may have fixed a bug that exposed another 14:12
moritz two bugs that canceled out each other? 14:13
jnthn Indeed 14:15
FROGGS that's not whirlpool, that's waterbed style programming 14:21
jnthn Phew, I think I might be done with the refactor that'll in turn let me fix a bug. 14:42
15:22 brrt joined
brrt cygx: that seems like a plausible thing to do 15:24
i.. think we may still have to call the register function thingy
i'm not sure about that, at alll 15:26
cygx brrt: only if you want to support C++ exception handling 15:27
brrt hmm
we may want to do that, anyway
seems like something where we probably are going to need it at some time 15:28
cygx brrt: note that MinGW doesn't necessarily use MSVC structured exceptions 15:30
brrt my professional opinion (worth nothing since i'm not a professional) is that compiler-specific exception handling is a pretty stupid thing 15:31
15:35 tokuhiro_ joined
timotimo we're already courageous enough to re-implement name mangling for a bunch of compilers to get cpp class method invocation and such 15:37
so why not also somehow make exceptions work %)
brrt yeah, i kind of agree with that 15:40
timotimo we'll stand out from the competition by being a bit more insane than they are 15:43
cygx anyway, for now I'd be happy if someone stuck the code from my gist in an appropriate place 15:44
once you do generate proper unwind information, you can adjust the NULLs as appropriate
brrt yes, i'm thinking about that appropriate place :-)
timotimo i don't even know what gist we're talking about :S 15:45
cygx timotimo: gist.github.com/cygx/aae672dcb8eb8a5ed0c5 15:46
timotimo ah, that!
dalek arVM/even-moar-jit: a6bb471 | brrt++ | / (6 files):
Add spesh iterator and replace JitGraphBuilder

Sometimes, although not always, we want the expresion tree builder to consume part of a basic block, rather than all of it; this happens for example when there is an OSR label in the middle of a BB.		 15:48
brrt lemmelook
i think src/platform/setjmp.h is a good spot, yes 15:49
15:54 kjs_ joined
brrt is now testing 15:57
hoelzro good moarning #moarvm! 15:58
dalek arVM: 79865be | jnthn++ | src/core/ (9 files):
Refactor handling of named flattening args.

They now count as part of the named arguments section of a callsite, and can appear between named args. This will allow us to take order into account when arguments are flattened in, then overridden with another value of the same name.		 15:59
arVM: af3b12e | jnthn++ | src/core/args.c:
Let later named args override earlier ones.

Including those that are flattened in, though an NQP code-gen patch is needed to enable this to happen also.
brrt good * hoelzro 16:00
hoelzro o/ brrt
brrt cygx++ fix seems to work well
cygx brrt: only until you use NativeCall to call some C++ code that accepts a callback that throws an exception ;) 16:02
brrt wel, that will happen someday 16:03
tests don't run very cleanly though
cygx brrt: yes, teh NativeCall tests (as well as one other) are known to fail 16:04
brrt ok
cygx (at leat known to me and mr_ron, at the very least)
brrt i see why, no-such-file-or-directory issues
i'm... not going to bother with that today
dalek arVM: dc266cb | brrt++ | / (3 files):
Override setjmp to two-argument version on mingw64

This fixes a corrupt longjmp in JIT context on windows when using mingw. cygx++ for the fix.		 16:07
brrt *phew* 16:08
i wouldn't mind hearing it sooner next time :-)
cygx brrt++
brrt: hearing about the failure? 16:12
brrt yes :-) 16:13
cygx well, I've been popping in every 1/4 year or so and mentioned that CORE.setting still does not compile on MinGW
brrt i don't like delivering broken things
well, i'm sorry i've missed it :-)
it's no offense meant, of course. just that i was surprised i hadn't known for so long
brrt is pleasantly surprised with qemu-under-boxes 16:16
hoelzro if anyone has a moment, could someone sanity check github.com/MoarVM/MoarVM/commit/5c...ebfd8c5bd? especially jnthn and diakopter, since they have done a lot in that area of the code 16:19
jnthn hoelzro: afaik, arg_flags is only set up if we flattened 16:22
hoelzro that's what I'm hoping for
I didn't know if that comment is out of date or not
jnthn It's possible in the past that we didn't NULL arg_flags
And so you checked if we'd flattened to know if arg_flags was worth looking at or a junk pointer
And that's why we did the extra check 16:23
Now we certainly do NULL it, which seems less fragile
hoelzro ah ha
so that should be safe now?
jnthn Yes
dalek arVM: 1278211 | brrt++ | build/auto.pm:
Make MinGW dyncall compile workaround official

Apparantly mingw sometimes thinks it has to compile dyncall as C++, which causes compile strictness errors. Overruling this with the C compiler fixes that. mr_ron++ for fix		 16:24
hoelzro \o/ 16:25
I'll fix that typo and merge post-work, then!
JimmyZ jnthn++ # hard arg flatten bug ! 16:33
jnthn Yes, that was quite some effort...
timotimo that goes into the weekly! :) 16:34
jnthn Particularly after getting up earlier than usual this morning to see $wife off on her travels. :)
ilmari jnthn, nwc10: github.com/MoarVM/MoarVM/pull/298 in case you didn't notice 16:35
jnthn ilmari: I did, will look soon; thanks! 16:36
ilmari fixes the encode replacement buffer overflow (except for utf16, which has no buffer resizing logic atm)
jnthn: btw, those functions are a mess of MVMuint32, MVMuint64 and size_t for various string lengths 16:37
16:39 Ven joined
jnthn afk for a bit 17:13
17:27 kjs_ joined 17:37 tokuhiro_ joined 17:41 Ven joined 18:06 muraiki joined
muraiki if I'm looking for the source for nqp.chmod, would it be this? github.com/perl6/nqp/blob/3f2ad11b....nqp#L1889 18:06
timotimo are you really interested in the parrot implementation? 18:07
muraiki oh darn
I am in the wrong place
lol
timotimo if not, you'll have to look under the moarvm repository
muraiki I wanted the moarvm one :)
timotimo you can find "chmod" in src/core/interp.c to figure out what the implementation function is called
likely something like src/io/file_ops.c, just a guess
muraiki ah, libuv handles it 18:08
timotimo yeah, we use libuv for more than we should :P 18:09
muraiki I'm trying to figure out how I got back the error "did not attempt chmod"
timotimo o_o
muraiki yeah, it's really bizarre. that string doesn't show up in rakudo or moarvm, so I'm trying to figure out where it came from 18:10
18:21 FROGGS joined 18:43 Ven joined
jnthn Odd, it's not in the libuv sources either, so far as I can tell 18:43
muraiki unfortunately I only have that error as part of a log file from many days back, so I don't really know what conditions brought it about. but it did occur multiple times 18:48
jnthn What OS? 18:49
muraiki ah man I'm an idiot
this is what happens when you go back to code many months after writing it... I created that error string
jnthn hah! :)
muraiki sorry for wasting your guys' time
jnthn np :) 18:50
nwc10 jnthn: ASAN still tolarates you :-) 18:52
jnthn :)
Always a relief 18:53
hoelzro I was just thinking about what timotimo and I were talking about last week, trying to detect valgrind or ASAN and implying --full-cleanup if that's the case 18:54
that seems weird in retrospect, but I'm wondering if using --debug with Configure should imply --full-cleanup 18:55
since chances are if you're using valgrind or ASAN, you'll be using --debug to get more legible stack traces
dalek arVM: 95629d0 | (Dagfinn Ilmari Mannsåker)++ | src/strings/ (4 files):
Remove pointless arguments in encoding convenience functions

Passing -1/NULL achieves the same result more efficiently and clearly.		 19:00
arVM: d0e4cca | FROGGS++ | src/strings/ (4 files):
Merge pull request #299 from ilmari/remove-pointless-encode-args

Remove pointless arguments in encoding convenience functions
19:05 tokuhiro_ joined 19:29 vendethiel joined 19:39 muraiki left 19:44 Ven joined 19:52 Ven joined
dalek arVM: f31c25c | (Dagfinn Ilmari Mannsåker)++ | src/strings/ (5 files):
Fix buffer overflow when replacement length > output buffer size
 20:06
arVM: 52d6e08 | jnthn++ | src/strings/ (5 files):
Merge pull request #298 from ilmari/fix-replace-overflow

Fix buffer overflow when replacement length > output buffer size
20:12 Ven joined, flussence joined 20:15 domidumont joined 20:21 Peter_R joined 20:22 Ven joined 20:37 dalek joined 20:39 psch joined 20:40 [Coke] joined 20:45 kjs_ joined 20:48 brrt joined 20:52 Ven joined 21:06 kjs_ joined 21:07 Ven_ joined, tokuhiro_ joined 21:16 kjs_ joined 21:25 Ven joined 21:30 synbot6 joined 21:53 Ven joined 22:53 nebuchad` joined 23:01 stmuk_ joined 23:05 harrow` joined 23:07 kjs_ joined 23:09 ShimmerFairy joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!