|
github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today Set by moderator on 1 September 2013. |
|||
|
01:34
FROGGS_ joined
|
|||
| JimmyZ | .tell FROGGS it's known for ..\\moarvm nqp.moarvm doesn't work on 32 bit | 02:12 | |
| yoleaux | JimmyZ: I'll pass your message to FROGGS. | ||
|
02:45
foo_bar_baz joined
05:12
foo_bar_baz joined
06:44
not_gerd joined
|
|||
| not_gerd | o/ | 06:44 | |
| yoleaux | 7 Sep 2013 23:11Z <diakopter> not_gerd: what's the difference between typing nmake moarvm.dll and doing Configure.pl --shared | ||
| not_gerd | diakopter: if you don't use --shared, -fPIC won't be added to CFLAGS on linux | 06:45 | |
| on windows, that doesn't matter (the loader takes care of dlls) and apparently, macos always compiles position-independently | 06:46 | ||
|
06:46
foo_bar_baz joined
|
|||
| not_gerd | making shared/static a build-time instead of a configure-time option is a pain because we have 2 black box 3rdparty libs (libatomic_ops, dyncall) and as we want to support nmake,can only use basic inference rules | 06:48 | |
| I know how to work around those limitations (move 3rdparty libs after building, have separate output directories for shared and static object files, let Configure.pl generate explicit rules instead of using a catch-all inference rule) | 06:50 | ||
| but it's a pain | |||
| FROGGS | JimmyZ: yeah, that is why I wanted to test this on win xp too | 07:02 | |
| yoleaux | 02:12Z <JimmyZ> FROGGS: it's known for ..\\moarvm nqp.moarvm doesn't work on 32 bit | ||
| diakopter | . | 07:33 | |
| not_gerd | diakopter: see irclog.perlgeek.de/moarvm/2013-09-08#i_7556706 about --shared | ||
| diakopter | heh it's on my screen | 07:34 | |
| 1 inch away | |||
| is the shared lib make target disabled on linux? | |||
| (or does it reinvoke configure with --shared and then reinvoke make) | 07:35 | ||
| lolol | |||
| not_gerd | no, I don't remember adding anything fancy like that ;) | 07:36 | |
| you can do `make reconfig ADDCONFIG=--shared`, though | |||
|
07:53
eternaleye joined
12:15
benabik joined
12:37
benabik joined
|
|||
| FROGGS | okay, I have a ubuntu 32bit and windows xp 32 bit with moarvm now | 15:27 | |
| the ubuntu work fine (except the known failures), the winxp dies silently for every test as it seems | 15:28 | ||
|
15:49
benabik joined
|
|||
| diakopter | . | 16:45 | |
| moritz: I still have today to push nfg? | 16:47 | ||
| jnthn | It'll be pushed by Christmas? :P | 16:48 | |
| diakopter | moritz: I'm in a physics talk by non-quietfanatic son of TimToady | 16:56 | |
| "about" 25 constants in the standard model | 16:57 | ||
| (some of them are slightly less constant?) | 16:59 | ||
| moritz | diakopter: you can push nfg whenever you want, but the later you do, the less likely it becomes that I'll find tuits for hacking | 17:06 | |
| FROGGS | is there anything I could do atm? I feel a bit lost because I am unable to fix the outer-frame-bug and I dont know what else is todo | 17:09 | |
| jnthn | Hunt down the 32-bit Windows failure? | 17:10 | |
| FROGGS | yeah, I guess should use the visual studio debugger, oder is there a gdb for windows? | 17:16 | |
| ohh, there is | 17:18 | ||
| s/oder/or/ | |||
| jnthn | Yeah, the VS one is NICE though )) | ||
| diakopter | maybe bisect the 32bit | ||
| FROGGS | diakopter: yeah, good idea | 17:19 | |
| jnthn: I have to create a VS project for this, right? | |||
| jnthn | No | 17:20 | |
| FROGGS | I'm not that used to that though | ||
| diakopter | i'll get vs to you soon | ||
| FROGGS | ahh, okay | ||
| jnthn | devenv moarvm.exe | ||
| FROGGS | diakopter: no hurry, I have everything atm | ||
| k | |||
| jnthn | and then set working dir and args and hit run | ||
| diakopter | (right-click executable... properties) | 17:24 | |
| FROGGS | I dont have devenv | 17:25 | |
| diakopter | soon | 17:29 | |
| jnthn | lol I blaught: 6guts.wordpress.com/2013/09/08/a-mo...ss-update/ | 18:15 | |
| FROGGS | \\o/ | 18:16 | |
| lizmat | jnthn++ | 18:18 | |
| jnthn | dinner & | 18:19 | |
| woolfy | jnthn++ (even I understand what you wrote) | 18:51 | |
| moritz | jnthn++ # blag | 19:20 | |
| dalek | arVM: f50dfa1 | (Tobias Leich)++ | / (9 files): added nqp::rethrow, t/nqp/44 only misses resume |
19:58 | |
| jnthn | hm, resume will need some care :) | 20:12 | |
| FROGGS | yeah, I thinking about that right now... | 20:13 | |
| I trying to mimik what the jvm backend does | |||
| jnthn | I think it does some trick involving the JVM exceptions... | 20:14 | |
| FROGGS | I need to invoke the frame of the exception somehow at the position after the exception.... right? | 20:20 | |
| jnthn | You basically need the nqp::throw to "return" | 20:22 | |
| FROGGS | ahh, yes | ||
| jnthn | And to unwind the frames to get you back to there | 20:23 | |
| We alrady correctly run handlers on le "stack top", to the degree we have a stack :) | |||
| So in a way it's largely *not* doing stuff. | |||
| (that is, not unwinding) | 20:24 | ||
| Apart from you need to unwind any handler related frames :) | |||
| FROGGS | hmmmm | 20:30 | |
| void MVM_exception_resume(MVMThreadContext *tc, MVMObject *ex_obj) { | 21:27 | ||
| MVMException *ex = (MVMException *)ex_obj; | |||
| unwind_to_frame(tc, ex->body.origin); | |||
| // *tc->interp_cur_op = *tc->interp_bytecode_start + ? | |||
| jnthn: is this the correct approach? | |||
| ohh, you said not unwinding | 21:28 | ||
| diakopter | well does it save the frames in unwinding? | ||
| er, something takes a reference to the innermost one? | |||
| you'll want to throw that one back | 21:29 | ||
| on the interp | |||
| afk a while & | |||
| jnthn | FROGGS: You need to unwind back to the place where the exception was thrown. | 21:30 | |
| FROGGS: It's the unwind to where the handler is you need to not do. :) | 21:31 | ||
| FROGGS | jnthn: I thought this would be ex->body.origin | ||
| wut? | |||
| jnthn | I think that's what ex->body.origin holds, yeah | ||
| diakopter | unwind?? | ||
| ununwind you mean? | |||
| jnthn | Well, normally what happens when you have an exception handler is... | ||
| 1) Find he handler | 21:32 | ||
| 2) Run the block | |||
| 3) Unwind to the frame where we found the handler | |||
| A resume happens during step 2, and it means that we don't want to do 3 | |||
| Because we want to end up back in the location that threw the exception. | |||
| *but* the handler may make calls, and the nqp::resume could be several frames away from the point we started running the handler block. | 21:33 | ||
| So we need to unwind *those* frames. | |||
| FROGGS | I see | ||
| diakopter | why need to "unwind"? | ||
| just let gc get them? | |||
| jnthn | diakopter: Frames are refcounted for one :) | 21:34 | |
| diakopter: But also we'll need to - when we implement it - run any LEAVE handlers too... | |||
| diakopter | oh, bleh. | ||
| jnthn | We should be able to re-use the existing unwind logic. | 21:35 | |
| It's just a different destination. | |||
| 'night | 21:56 | ||
|
22:12
_ilbot joined
|
|||
| moderator | github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today | ||
|
22:19
moritz joined,
jnthn joined,
FROGGS joined,
harrow joined,
ChanServ joined,
pmichaud joined,
`patch` joined,
_sri joined,
arnsholt joined,
ingy joined,
patspam joined,
flussence joined,
timotimo joined,
gshank joined,
JimmyZ joined,
PerlJam joined,
Util joined,
BinGOs joined,
sorear joined,
diakopter joined,
yoleaux joined,
woolfy joined,
colomon joined,
dalek joined,
tadzik joined,
ggoebel joined,
rblackwe joined,
lizmat joined,
cognominal__ joined,
Ulti joined,
eternaleye joined,
[Coke]_ joined,
masak_ joined,
tokuhirom joined,
benabik joined
|
|||
| FROGGS | .tell jnthn I think I got something, it does not resume though :/, it dies as if it does not find the handler in the second run: gist.github.com/FROGGS/d006980f3c95b53364ca | 22:28 | |
| yoleaux | FROGGS: I'll pass your message to jnthn. | ||
| FROGGS | ossum | 22:29 | |