Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-11-16

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:46 Ven joined #moarvm
01:06 colomon joined #moarvm
01:10 tokuhiro_ joined #moarvm
01:35 flussence joined #moarvm
01:35 ilmari joined #moarvm
01:38 flaviusb joined #moarvm
01:47 Ven joined #moarvm
02:54 Ven joined #moarvm
03:06 tokuhiro_ joined #moarvm
04:00 Ven joined #moarvm
05:03 Ven joined #moarvm
05:43 japhb joined #moarvm
05:49 japhb joined #moarvm
06:04 Ven joined #moarvm
07:04 nwc10 good *, #moarvm
07:11 ilmari_ joined #moarvm
07:14 Hotkeys_ joined #moarvm
07:16 domidumont joined #moarvm
07:18 domidumont joined #moarvm
07:19 domidumont joined #moarvm
07:21 domidumont joined #moarvm
07:22 brrt joined #moarvm
07:30 nwc10 brrt: thanks for figuring out what needing tweaking to fix timotimo's JIT stuff.
07:30 brrt yw :-)
07:32 brrt i had no idea that jit-on-mingw was so broken, by the way
07:32 brrt luckily mingw comes with gdb
07:32 brrt i can hardly imagine this to be anything but a configuration error of some kind
07:32 brrt there shouldn't really be ABI differences...
07:47 FROGGS joined #moarvm
08:05 zakharyas joined #moarvm
08:32 brrt oh, i know how to solve the broken-expression problem
08:34 brrt i need to revive a somewhat-old idea, the spesh iterator
08:40 brrt 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 brrt after the appropriate labelling is done
09:14 Ven joined #moarvm
09:19 jnthn moarning, #moarvm
09:20 jnthn brrt++ # JIT fixes
09:24 brrt moarning jnthn
09:27 brrt oh, jnthn, i have a supsicion i want to run by you
09:28 brrt on x64-mingw, during setting compilation, we crash in an invalid longjmp
09:28 brrt how.. does that even happen?
09:28 brrt it doesn't happen in vs2013, at least
09:29 jnthn o.O
09:29 jnthn The only place we longjmp that I'm aware of is to the interpreter
09:29 jnthn On exceptions
09:29 brrt hmm
09:29 brrt google has some answers it seems
09:29 brrt http://lists.llvm.org/pipermail/llvm-dev/2015-April/084888.html
09:30 jnthn I could imagine mingw and vs2013 result in us using a different longjmp implementaiton
09:30 * jnthn looks
09:31 brrt ok, we can do that...
09:31 brrt https://msdn.microsoft.com/en-us/library/ft9x1kdx.aspx?f=255&MSPPError=-2147217396 is the article
09:32 brrt https://msdn.microsoft.com/en-us/library/windows/desktop/ms680595%28v=vs.85%29.aspx is the API call
09:32 jnthn But wait, it works under MSVC?
09:33 brrt oh, we can totally manage that
09:33 brrt it hasn't failed yet
09:33 jnthn Oh. :-)
09:34 jnthn So we're getting away with things? :)
09:34 brrt but at any rate, i think this is indeed a longjmp-implementation-difference
09:34 brrt yes
09:35 cygx joined #moarvm
09:35 cygx o/
09:35 brrt \o cygx
09:35 brrt we may have the reason for the JIT-on-mingw not working
09:35 cygx Mmingw apparently also provides a ms_longjmp function
09:35 brrt aha
09:35 cygx * MinGW
09:35 brrt and the difference is?
09:36 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:37 cygx but that's just a guess, might be something totally different
09:37 * cygx goes googling
09:38 brrt hmmm
09:38 * brrt has to go afk
09:38 brrt see you later
09:39 cygx ~~
09:51 domidumont joined #moarvm
09:52 cygx google has failed me, and if you try to call ms_longjmp, moarvm fails to link
09:52 cygx so no idea what that function is supposed to do...
10:13 domidumont joined #moarvm
10:19 Ven joined #moarvm
10:25 cygx brrt: cf https://gcc.gnu.org/ml/gcc/2011-10/msg00257.html
10:25 cygx according to the follow-up, it's supposed to be _setjmp3, but youll have to link against msvcrt to get that symbol
10:26 cygx in my quick test, just doing a #define setjmp(BUF) _setjmpex((BUF), NULL) at the top of interp.c already works
10:31 psch https://github.com/MoarVM/MoarVM/pull/296
10:31 psch nqp and Rakudo both test clear with that
10:48 dalek MoarVM: b370dd9 | peschwa++ | src/core/interp.c:
10:48 dalek MoarVM: Check if the *next* outer is null.
10:48 dalek MoarVM:
10:48 dalek MoarVM: Otherwise there's cases where we do go one too far and SEGV after the while.
10:48 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/b370dd921d
10:48 dalek MoarVM: 41d9376 | jnthn++ | src/core/interp.c:
10:48 dalek MoarVM: Merge pull request #296 from peschwa/master
10:48 dalek MoarVM:
10:48 dalek MoarVM: Check if the *next* outer is null.
10:48 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/41d93762f8
11:21 Ven joined #moarvm
11:27 cygx jnthn: brrt: putting https://gist.github.com/cygx/aae672dcb8eb8a5ed0c5 at a convenient location (interp.c, moar.h, a custom platform header...) makes the JIT on MinGW happy
11:34 JimmyZ oh, would be nice to have a src/platform/setjmp.h then
11:34 JimmyZ :)
11:36 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:37 cygx jnthn: I'm guessing brrt will take a look at that later
11:37 cygx there's no rush
11:37 cygx it has been broken for ages, I can wait another day or two ;)
11:39 timotimo take a long look, don't just jmp to conclusions
11:44 cygx jnthn: when you have some time, could you also take a look at https://github.com/MoarVM/MoarVM/issues/295 to decide on an approach (assuming my analysis is correct)?
11:49 jnthn cygx: There alreayd is a mechanism for "release this mutex on exception", which we use in the I/O code.
11:50 jnthn *already
11:50 cygx even better
11:52 cygx looks like MVM_tc_set_ex_release_mutex?
11:53 cygx that would be my idea about keeping a list of mutexes to be release, except that list is length 1 ;)
11:54 jnthn :)
11:54 jnthn Yeah, I figured it'll be easy to refactor to a list later if needed.
11:54 jnthn But YAGNI
12:07 cygx https://github.com/MoarVM/MoarVM/pull/297
12:16 dalek MoarVM: f9611b4 | cygx++ | src/core/loadbytecode.c:
12:16 dalek MoarVM: release mutex in MVM_load_bytecode on exception
12:16 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f9611b48c1
12:16 dalek MoarVM: 7f1f840 | (Jimmy Zhuo)++ | src/core/loadbytecode.c:
12:16 dalek MoarVM: Merge pull request #297 from cygx/loadbc-mutex
12:16 dalek MoarVM:
12:16 dalek MoarVM: release mutex in MVM_load_bytecode on exception
12:16 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/7f1f8408f7
12:17 timotimo do you think we've ever deadlocked on this problem cygx just fixed?
12:17 jnthn Not sure
12:17 jnthn I think there was some report of a deadlock involving threads and require that may be related
12:19 JimmyZ as long as culri branch got merged ? :P
12:20 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
12:20 timotimo fair enough
12:21 jnthn Still work fixing :)
12:21 timotimo agreed
12:21 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 #moarvm
12:31 jnthn lunch &
12:44 flaviusb joined #moarvm
13:27 Ven joined #moarvm
13:58 jnthn bah, of all the tests to regress...
13:58 jnthn sub foo(:$) { }; foo |{ '' => 42 }
13:58 jnthn That's the only spectest my refactor has bust. What on earth...
13:58 nwc10 m: say 42.why
13:58 camelia rakudo-moar b18ada: OUTPUT«Method 'why' not found for invocant of class 'Int'␤  in block <unit> at /tmp/kY6T9fkFWL:1␤␤»
13:59 nwc10 there's a special case on 42, isn't there?
13:59 jnthn m: say 42.WHY
13:59 camelia rakudo-moar b18ada: OUTPUT«(Any)␤»
14:06 JimmyZ m: 42.WHAT
14:06 camelia rakudo-moar b18ada: ( no output )
14:06 JimmyZ m: say 42.WHAT
14:06 camelia rakudo-moar b18ada: OUTPUT«(Int)␤»
14:06 nwc10 m: say 17.WHAT
14:06 camelia rakudo-moar b18ada: OUTPUT«(Int)␤»
14:11 dalek MoarVM/callsite-memory-leak: d976477 | hoelzro++ | src/ (4 files):
14:11 dalek MoarVM/callsite-memory-leak: Restore "Track whether or not a capture owns its callsite"
14:11 dalek MoarVM/callsite-memory-leak:
14:11 dalek MoarVM/callsite-memory-leak: This reverts commit 9befd69353643bff3a529aa5bea8101cd574fa29.
14:11 dalek MoarVM/callsite-memory-leak: review: https://github.com/MoarVM/MoarVM/commit/d976477f05
14:11 dalek MoarVM/callsite-memory-leak: 5c9262d | hoelzro++ | src/core/args.c:
14:11 dalek MoarVM/callsite-memory-leak: Just check arg_flags to know whether or not to get rid of them
14:11 dalek MoarVM/callsite-memory-leak:
14:11 dalek MoarVM/callsite-memory-leak: One, arg_flags should know best.  Two, checking the callsite
14:11 dalek MoarVM/callsite-memory-leak: object is checking an object we don't own, and may be invalid by
14:11 dalek MoarVM/callsite-memory-leak: this point in the program.
14:11 dalek MoarVM/callsite-memory-leak: review: https://github.com/MoarVM/MoarVM/commit/5c9262d008
14:11 dalek MoarVM/callsite-memory-leak: 88d0067 | hoelzro++ | src/core/args. (2 files):
14:11 dalek MoarVM/callsite-memory-leak: HAve MVM_args_proc_to_callsite tell the caller if the a new owner is needed
14:11 jnthn Wow, it appears that test may have passed for entirely the wrong reason
14:12 jnthn Or rather, I may have fixed a bug that exposed another
14:13 moritz two bugs that canceled out each other?
14:15 jnthn Indeed
14:21 FROGGS that's not whirlpool, that's waterbed style programming
14:42 jnthn Phew, I think I might be done with the refactor that'll in turn let me fix a bug.
15:22 brrt joined #moarvm
15:24 brrt cygx: that seems like a plausible thing to do
15:24 brrt i.. think we may still have to call the register function thingy
15:26 brrt i'm not sure about that, at alll
15:27 cygx brrt: only if you want to support C++ exception handling
15:27 brrt hmm
15:27 brrt we may want to do that, anyway
15:28 brrt seems like something where we probably are going to need it at some time
15:30 cygx brrt: note that MinGW doesn't necessarily use MSVC structured exceptions
15:31 brrt my professional opinion (worth nothing since i'm not a professional) is that compiler-specific exception handling is a pretty stupid thing
15:35 tokuhiro_ joined #moarvm
15:37 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 timotimo so why not also somehow make exceptions work %)
15:40 brrt yeah, i kind of agree with that
15:43 timotimo we'll stand out from the competition by being a bit more insane than they are
15:44 cygx anyway, for now I'd be happy if someone stuck the code from my gist in an appropriate place
15:44 cygx once you do generate proper unwind information, you can adjust the NULLs as appropriate
15:44 brrt yes, i'm thinking about that appropriate place :-)
15:45 timotimo i don't even know what gist we're talking about :S
15:46 cygx timotimo: https://gist.github.com/cygx/aae672dcb8eb8a5ed0c5
15:46 timotimo ah, that!
15:48 dalek MoarVM/even-moar-jit: a6bb471 | brrt++ | / (6 files):
15:48 dalek MoarVM/even-moar-jit: Add spesh iterator and replace JitGraphBuilder
15:48 dalek MoarVM/even-moar-jit:
15:48 dalek MoarVM/even-moar-jit: Sometimes, although not always, we want the expresion tree builder
15:48 dalek MoarVM/even-moar-jit: to consume part of a basic block, rather than all of it; this
15:48 dalek MoarVM/even-moar-jit: happens for example when there is an OSR label in the middle
15:48 dalek MoarVM/even-moar-jit: of a BB.
15:48 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/a6bb4710c9
15:48 brrt lemmelook
15:49 brrt i think src/platform/setjmp.h is a good spot, yes
15:54 kjs_ joined #moarvm
15:57 * brrt is now testing
15:58 hoelzro good moarning #moarvm!
15:59 dalek MoarVM: 79865be | jnthn++ | src/core/ (9 files):
15:59 dalek MoarVM: Refactor handling of named flattening args.
15:59 dalek MoarVM:
15:59 dalek MoarVM: They now count as part of the named arguments section of a callsite,
15:59 dalek MoarVM: and can appear between named args. This will allow us to take order
15:59 dalek MoarVM: into account when arguments are flattened in, then overridden with
15:59 dalek MoarVM: another value of the same name.
15:59 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/79865be1f3
15:59 dalek MoarVM: af3b12e | jnthn++ | src/core/args.c:
15:59 dalek MoarVM: Let later named args override earlier ones.
15:59 dalek MoarVM:
15:59 dalek MoarVM: Including those that are flattened in, though an NQP code-gen patch
15:59 dalek MoarVM: is needed to enable this to happen also.
15:59 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/af3b12ecbe
16:00 brrt good * hoelzro
16:00 hoelzro o/ brrt
16:00 brrt cygx++ fix seems to work well
16:02 cygx brrt: only until you use NativeCall to call some C++ code that accepts a callback that throws an exception ;)
16:03 brrt wel, that will happen someday
16:03 brrt tests don't run very cleanly though
16:04 cygx brrt: yes, teh NativeCall tests (as well as one other) are known to fail
16:04 brrt ok
16:04 cygx (at leat known to me and mr_ron, at the very least)
16:04 brrt i see why, no-such-file-or-directory issues
16:04 brrt i'm... not going to bother with that today
16:07 dalek MoarVM: dc266cb | brrt++ | / (3 files):
16:07 dalek MoarVM: Override setjmp to two-argument version on mingw64
16:07 dalek MoarVM:
16:07 dalek MoarVM: This fixes a corrupt longjmp in JIT context on windows when using
16:07 dalek MoarVM: mingw. cygx++ for the fix.
16:07 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/dc266cb09b
16:08 brrt *phew*
16:08 brrt i wouldn't mind hearing it sooner next time :-)
16:08 cygx brrt++
16:12 cygx brrt: hearing about the failure?
16:13 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
16:13 brrt i don't like delivering broken things
16:13 brrt well, i'm sorry i've missed it :-)
16:13 brrt it's no offense meant, of course. just that i was surprised i hadn't known for so long
16:16 * brrt is pleasantly surprised with qemu-under-boxes
16:19 hoelzro if anyone has a moment, could someone sanity check https://github.com/MoarVM/MoarVM/commit/5c9262d008dd5bb21b666b85b662b1aebfd8c5bd? especially jnthn and diakopter, since they have done a lot in that area of the code
16:22 jnthn hoelzro: afaik, arg_flags is only set up if we flattened
16:22 hoelzro that's what I'm hoping for
16:22 hoelzro I didn't know if that comment is out of date or not
16:22 jnthn It's possible in the past that we didn't NULL arg_flags
16:22 jnthn And so you checked if we'd flattened to know if arg_flags was worth looking at or a junk pointer
16:23 jnthn And that's why we did the extra check
16:23 jnthn Now we certainly do NULL it, which seems less fragile
16:23 hoelzro ah ha
16:23 hoelzro so that should be safe now?
16:23 jnthn Yes
16:24 dalek MoarVM: 1278211 | brrt++ | build/auto.pm:
16:24 dalek MoarVM: Make MinGW dyncall compile workaround official
16:24 dalek MoarVM:
16:24 dalek MoarVM: Apparantly mingw sometimes thinks it has to compile dyncall as
16:24 dalek MoarVM: C++, which causes compile strictness errors. Overruling this with
16:24 dalek MoarVM: the C compiler fixes that. mr_ron++ for fix
16:24 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/1278211390
16:25 hoelzro \o/
16:25 hoelzro I'll fix that typo and merge post-work, then!
16:33 JimmyZ jnthn++ # hard arg flatten bug !
16:33 jnthn Yes, that was quite some effort...
16:34 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. :)
16:35 ilmari jnthn, nwc10: https://github.com/MoarVM/MoarVM/pull/298 in case you didn't notice
16:36 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)
16:37 ilmari jnthn: btw, those functions are a mess of MVMuint32, MVMuint64 and size_t for various string lengths
16:39 Ven joined #moarvm
17:13 * jnthn afk for a bit
17:27 kjs_ joined #moarvm
17:37 tokuhiro_ joined #moarvm
17:41 Ven joined #moarvm
18:06 muraiki joined #moarvm
18:06 muraiki if I'm looking for the source for nqp.chmod, would it be this? https://github.com/perl6/nqp/blob/3f2ad11b4d64e50d2fdf6a493655496ad1d42804/src/vm/parrot/QAST/Operations.nqp#L1889
18:07 timotimo are you really interested in the parrot implementation?
18:07 muraiki oh darn
18:07 muraiki I am in the wrong place
18:07 muraiki lol
18:07 timotimo if not, you'll have to look under the moarvm repository
18:07 muraiki I wanted the moarvm one :)
18:07 timotimo you can find "chmod" in src/core/interp.c to figure out what the implementation function is called
18:07 timotimo likely something like src/io/file_ops.c, just a guess
18:08 muraiki ah, libuv handles it
18:09 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"
18:09 timotimo o_o
18:10 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:21 FROGGS joined #moarvm
18:43 Ven joined #moarvm
18:43 jnthn Odd, it's not in the libuv sources either, so far as I can tell
18:48 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:49 jnthn What OS?
18:49 muraiki ah man I'm an idiot
18:49 muraiki this is what happens when you go back to code many months after writing it... I created that error string
18:49 jnthn hah! :)
18:49 muraiki sorry for wasting your guys' time
18:50 jnthn np :)
18:52 nwc10 jnthn: ASAN still tolarates you :-)
18:52 jnthn :)
18:53 jnthn Always a relief
18:54 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:55 hoelzro that seems weird in retrospect, but I'm wondering if using --debug with Configure should imply --full-cleanup
18:55 hoelzro since chances are if you're using valgrind or ASAN, you'll be using --debug to get more legible stack traces
19:00 dalek MoarVM: 95629d0 | (Dagfinn Ilmari Mannsåker)++ | src/strings/ (4 files):
19:00 dalek MoarVM: Remove pointless arguments in encoding convenience functions
19:00 dalek MoarVM:
19:00 dalek MoarVM: Passing -1/NULL achieves the same result more efficiently and clearly.
19:00 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/95629d0208
19:00 dalek MoarVM: d0e4cca | FROGGS++ | src/strings/ (4 files):
19:00 dalek MoarVM: Merge pull request #299 from ilmari/remove-pointless-encode-args
19:01 dalek MoarVM:
19:01 dalek MoarVM: Remove pointless arguments in encoding convenience functions
19:01 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d0e4cca70a
19:05 tokuhiro_ joined #moarvm
19:29 vendethiel joined #moarvm
19:39 muraiki left #moarvm
19:44 Ven joined #moarvm
19:52 Ven joined #moarvm
20:06 dalek MoarVM: f31c25c | (Dagfinn Ilmari Mannsåker)++ | src/strings/ (5 files):
20:06 dalek MoarVM: Fix buffer overflow when replacement length > output buffer size
20:06 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f31c25c684
20:06 dalek MoarVM: 52d6e08 | jnthn++ | src/strings/ (5 files):
20:06 dalek MoarVM: Merge pull request #298 from ilmari/fix-replace-overflow
20:06 dalek MoarVM:
20:06 dalek MoarVM: Fix buffer overflow when replacement length > output buffer size
20:06 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/52d6e084da
20:12 Ven joined #moarvm
20:12 flussence joined #moarvm
20:15 domidumont joined #moarvm
20:21 Peter_R joined #moarvm
20:22 Ven joined #moarvm
20:37 dalek joined #moarvm
20:39 psch joined #moarvm
20:40 [Coke] joined #moarvm
20:45 kjs_ joined #moarvm
20:48 brrt joined #moarvm
20:52 Ven joined #moarvm
21:06 kjs_ joined #moarvm
21:07 Ven_ joined #moarvm
21:07 tokuhiro_ joined #moarvm
21:16 kjs_ joined #moarvm
21:25 Ven joined #moarvm
21:30 synbot6 joined #moarvm
21:53 Ven joined #moarvm
22:53 nebuchad` joined #moarvm
23:01 stmuk_ joined #moarvm
23:05 harrow` joined #moarvm
23:07 kjs_ joined #moarvm
23:09 ShimmerFairy joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary