These are chat archives for dropbox/pyston

2nd
Aug 2015
Kevin Modzelewski
@kmod
Aug 02 2015 03:21
right now, running into it for capi-style exception handling
where we want to do something like
o = f1();
if (o) // non-exception case
    o = f2(o)
Sun
@Daetalus
Aug 02 2015 03:25

My local repo build failed from 12 hours ago. Even I use official master branch. I deleted my local branch and clong it again. I am solving it. But could anyone give any tips?
Here is the error message:

  LLVM requires C++11 support but the '-std=c++11' flag isn't supported.

But I use clang-3.4 and gcc-4.8.4, I don't know why report this message.

Travis Hance
@tjhance
Aug 02 2015 03:32
If you're just going to throw an exception you don't need to merge the paths
Kevin Modzelewski
@kmod
Aug 02 2015 05:15
well not if we use capi-exceptions :)
which are "thrown" by setting some exception-related data and then returning NULL
so if we see that NULL was returned by one of the functions we call, we should usually skip the next thing
Travis Hance
@tjhance
Aug 02 2015 05:16
yeah so right now I’m trying to figure out how to pass arguments to the secondary slow path, it seems a bit annoying if there are more than 6 args (as is the case with the callattr situation)
Kevin Modzelewski
@kmod
Aug 02 2015 05:16
@Daetalus not sure about that error -- did you try running make llvm_up from inside ~/pyston?
Travis Hance
@tjhance
Aug 02 2015 05:16
since in that case you have to use the stack locations
and right now we don’t touch those at all
I guess I could just push more stack space
so I don’t have to overwrite the original args passed in on the stack
actually that seems pretty reasonable
Travis Hance
@tjhance
Aug 02 2015 05:21
@kmod regarding the capi-exceptions, dont’ you just return immediately if you see NULL? so you still have no need to to merge back in
speaking of forking, it would make sense if instead of trying to restore args before each ordinary guard jump, the jump went to some path which then restores the args and then jumps to the actual call
man, our current architecture sux for this:\
a project like this could force us to factor out all the really stateful stuff though to make it more manageable
Sun
@Daetalus
Aug 02 2015 06:31
@kmod already execute make llvm_up
Sun
@Daetalus
Aug 02 2015 18:40

@kmod , do you mind to make a fresh build? The error took me a whole day...I get around it by copy the build folder from my 2nd repository(I delete the build folder in my 1st repository).

I try it a lot. Include delete everything then clone again. I also checked the system software compability and version. Nothing work. The pyston configuration always failed(Include fresh build).

Kevin Modzelewski
@kmod
Aug 02 2015 19:06
oh wow you are right, I just did a fresh build and got the -std=c++11 error
will take a look
Sun
@Daetalus
Aug 02 2015 19:09
:smile:
Kevin Modzelewski
@kmod
Aug 02 2015 19:11
interesting, looks like this is pgo related
Kevin Modzelewski
@kmod
Aug 02 2015 19:17
ok, just pushed something, let me know if it helps
Sun
@Daetalus
Aug 02 2015 19:18
Ok
Thanks!
Kevin Modzelewski
@kmod
Aug 02 2015 19:18
@tjhance yeah I guess right now all exceptions get propagated out of the rewrite
it feels a bit bad to have the inner operations have to know how their exceptions will get handled
but I'll try to think of some temporary api where you just say "hey handle this exception" and then it will currently just jump to the end of the rewrite