On 8 July 2012 08:59, Robert Bradshaw <rober...@gmail.com> wrote: > On Fri, Jul 6, 2012 at 2:33 AM, mark florisson > <markflorisso...@gmail.com> wrote: >> On 6 July 2012 03:34, Dag Sverre Seljebotn <d.s.seljeb...@astro.uio.no> >> wrote: >>> >>> >>> mark florisson <markflorisso...@gmail.com> wrote: >>> >>>>On 5 July 2012 21:46, Dag Sverre Seljebotn <d.s.seljeb...@astro.uio.no> >>>>wrote: >>>>> >>>>> >>>>> mark florisson <markflorisso...@gmail.com> wrote: >>>>> >>>>>>On 3 July 2012 20:15, Robert Bradshaw <rober...@gmail.com> wrote: >>>>>>> On Tue, Jul 3, 2012 at 11:43 AM, Dag Sverre Seljebotn >>>>>>> <d.s.seljeb...@astro.uio.no> wrote: >>>>>>>> On 07/03/2012 08:23 PM, Robert Bradshaw wrote: >>>>>>>>> >>>>>>>>> On Tue, Jul 3, 2012 at 11:11 AM, Stefan >>>>Behnel<stefan...@behnel.de> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Robert Bradshaw, 03.07.2012 19:58: >>>>>>>>>>> >>>>>>>>>>> On Tue, Jul 3, 2012 at 9:38 AM, Stefan Behnel wrote: >>>>>>>>>>>> >>>>>>>>>>>> Dag Sverre Seljebotn, 03.07.2012 18:11: >>>>>>>>>>>>> >>>>>>>>>>>>> On 07/03/2012 09:14 AM, Stefan Behnel wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> I don't know what happens if a C++ exception is not being >>>>>>caught, but >>>>>>>>>>>>>> I >>>>>>>>>>>>>> guess it would simply crash the application. That's a bit >>>>more >>>>>>>>>>>>>> visible than >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Yep. >>>>>>>>>>>>> >>>>>>>>>>>>>> just printing a warning when a Python exception is being >>>>>>ignored due >>>>>>>>>>>>>> to a >>>>>>>>>>>>>> missing declaration. It's really unfortunate that our >>>>>>documentation >>>>>>>>>>>>>> didn't >>>>>>>>>>>>>> even mention the need for this, because it's not immediately >>>>>>obvious >>>>>>>>>>>>>> that >>>>>>>>>>>>>> Cython won't handle errors in "new", and testing for memory >>>>>>errors >>>>>>>>>>>>>> isn't >>>>>>>>>>>>>> quite what people commonly do in their test suites. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Apart from that, I agree, users have to take care to >>>>properly >>>>>>declare >>>>>>>>>>>>>> the >>>>>>>>>>>>>> API they are using. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Is there any time you do NOT want a "catch (...) {}" block? I >>>>>>can't >>>>>>>>>>>>> see a >>>>>>>>>>>>> C++ exception propagating to Python-land doing anything >>>>useful >>>>>>ever. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> That would have been my intuition, too. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> If it's actually embedded, with the main driver in C++, one >>>>might >>>>>>want >>>>>>>>>>> it to propagate up. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> But what kind of a propagation would that be? On the way out, it >>>>>>could >>>>>>>>>> induce anything, from side effects to resource leaks to crashes, >>>>>>>>>> depending >>>>>>>>>> on what the state of the surrounding code is. It would leave the >>>>>>whole >>>>>>>>>> system in an unpredictable state. I cannot imagine anyone really >>>>>>wanting >>>>>>>>>> this. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> So shouldn't we just make --cplus turn *all* external >>>>functions >>>>>>and >>>>>>>>>>>>> methods >>>>>>>>>>>>> (whether C-like or C++-like) into "except +"? (Or keep >>>>except+ >>>>>>for >>>>>>>>>>>>> manual >>>>>>>>>>>>> translation, but always have a catch(...)". >>>>>>>>>>>>> >>>>>>>>>>>>> Performance overhead is the only reason I can think of to not >>>>>>do this, >>>>>>>>>>>>> although IIRC C++ catch blocks are only dealt with during >>>>stack >>>>>>>>>>>>> unwinds and >>>>>>>>>>>>> doesn't cost anything/much (?) when they're not triggered. >>>>>>>>>>>>> >>>>>>>>>>>>> "except -1" should then actually mean both; "except + except >>>>>>-1". So >>>>>>>>>>>>> it's >>>>>>>>>>>>> more a question of just adding catch(...) *everywhere*, than >>>>>>making >>>>>>>>>>>>> "except >>>>>>>>>>>>> +" the default. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I have no idea if there is a performance impact, but if there >>>>>>isn't, >>>>>>>>>>>> always >>>>>>>>>>>> catching all exceptions sounds like a reasonable thing to do. >>>>>>After >>>>>>>>>>>> all, we >>>>>>>>>>>> have no support for catching C++ exceptions on user side. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This is a bit like following every C call with "except *" >>>>(though >>>>>>the >>>>>>>>>>> performance ratios are unclear). It just seems a lot to wrap >>>>>>every >>>>>>>>>>> single line of a non-trivial C++ using function with try..catch >>>>>>>>>>> blocks. >>>>>>>> >>>>>>>> >>>>>>>> It seems "a lot" of just what exactly? Generated code? Binary >>>>size? >>>>>>Time >>>>>>>> spent in GCC parser? >>>>>>> >>>>>>> All of the above. And we should take a look at the runtime overhead >>>>>>> (which is hopefully nil, but who knows.) >>>>>>> >>>>>>>> Though I guess one might want to try to pull out the try-catch to >>>>at >>>>>>least >>>>>>>> only one per code line rather than one per SimpleCallNode. >>>>>>> >>>>>>> Or even higher, if possible. It's still a lot. >>>>>> >>>>>>Why would you have to do that? Can't you just insert a try/catch per >>>>>>try/except or try/finally block, or if absent, the function body. >>>>That >>>>>>will still work with the way temporaries are cleaned up. (It should >>>>>>also be implemented for parallel/prange sections). >>>>> >>>>> One disadvantage is that you don't get source code line for the .pyx >>>>file in the stack trace. Which is often exactly the information you are >>>>looking for (even worse, since C++ stack isn't in the stack trace, the >>>>lineno for what seems like the ' ultimate cause' is not there). Having >>>>to surround statements with try/except just to pinpoint which one is >>>>raising the exception would be incredibly irritating. >>>>> >>>>> Dag >>>> >>>>Oh yeah, good point. Maybe we could use these zero-cost exceptions for >>>>cdef functions in Cython though, instead of error checks (if it >>>>appears to make any significant difference). Basically instead of the >>>>'error' argument in CEP 526. It'd need version that ABI as well... >>>> >>> >>> Wait, one can just do >>> >>> lineno = 25; >>> a() >>> linono = 27; >>> b() >>> >>> And wrap the block with a try catch. >> >> Heh, I just had the same idea before going to bed yesterday :) But it >> means the common case (no exception) will get some overhead. That can >> probably be afforded since normal error checking branches anyway. >> Maybe it's worth investigating how many instructions try/catch blocks >> generate and seeing whether a) it's (significantly) better than >> branching and b) whether a try/catch block can be afforded per >> subexpression/lineno. > > For sure some performance testing needs to be done to move this > significantly forward. > >>> I'm not sure if I like C++ exceptions internally in Cython myself. It would >>> mean that C-compiled Cython modules would not be able to call C++-compiled >>> Cython modules, which I think would create a lot of headache. And I think >>> we want to keep the ability to compile with a C compiler if you don't call >>> C++ code... >> >> I don't know how often people mix the two. It's probably not worth >> making a directive either... Are there any platforms where installing >> a C++ compiler is more of a hassle than a C compiler? E.g. Theano >> depends on a C++ compiler (and a lot more as well). > > Are you implying, for example, that one would have to re-compile NumPy > with a C++ compiler if you wanted to use any C++ extension modules? > I'd rather avoid this.
No, you can still freely mix any extension modules, it's just that when you cimport stuff from other Cython modules, they have to be ABI compatible. If C++ is part of the ABI due to how exceptions are propagated and handled, then those modules need to be compiled both with C++ (or neither, to get the other semantics with slower (to be verified) error checks). >> The cool thing about it would be that as you said earlier in the >> thread, you could at the very least do one try/catch per line number, >> so you wouldn't need N branches for N subexpressions that can fail. >> >>> Dag >>> >>>>>> >>>>>>>> "except *" only has a point when calling functions using the >>>>CPython >>>>>>API, >>>>>>>> but most external C functions are pure C, not >>>>>>CPython-API-using-functions. >>>>>>>> OTOH, all external C++ functions are C++ :-) >>>>>>> >>>>>>> Fair point. >>>>>>> >>>>>>>> (Also, if we wrote Cython from scratch now I'm pretty sure the >>>>>>"except *" >>>>>>>> defaults would be a tad different.) >>>>>>> >>>>>>> For sure. >>>>>>> >>>>>>>>>> But if users are correct about their declarations, we'd end up >>>>>>with the >>>>>>>>>> same thing. I think it's worth a try. >>>>>>>>> >>>>>>>>> >>>>>>>>> Most C++ code (that I've ever run into) doesn't use exceptions, >>>>>>>>> because exception handling is so broken in C++ anyways. >>>>>>>> >>>>>>>> >>>>>>>> Except for the fact that any code touching "new" could be raising >>>>>>>> exceptions? That propagates. >>>>>>> >>>>>>> I would guess most of the time people don't bother catching these >>>>and >>>>>>> let the program die, as there's often no sane recovery (the same as >>>>>>> MemoryErrors in Python, though I guess C++ is less often used from >>>>an >>>>>>> event loop). >>>>>>> >>>>>>>> There is a lot of C++ code out there using exceptions. I'd guess >>>>>>that both >>>>>>>> mathematical code and Google-written code is unlike most C++ code >>>>>>out there >>>>>>>> :-) Many C++ programmers go on and on about RAII and auto_ptrs and >>>>>>so on, >>>>>>>> and that doesn't have much point unless you throw an exception now >>>>>>and then >>>>>>>> (OK, there's the occasional return statement where it matters >>>>well). >>>>>>> >>>>>>> True, I've seen a small subset of the C++ code that's out there. >>>>>>Maybe >>>>>>> numerical computations use it a lot? >>>>>>> >>>>>>> +1 to making catch-everywhere a directive at least. Lets see what >>>>the >>>>>>> impact is before we decide to make it the default. >>>>>>> >>>>>>> - Robert >>>>>>> _______________________________________________ >>>>>>> cython-devel mailing list >>>>>>> cython-devel@python.org >>>>>>> http://mail.python.org/mailman/listinfo/cython-devel >>>>>>_______________________________________________ >>>>>>cython-devel mailing list >>>>>>cython-devel@python.org >>>>>>http://mail.python.org/mailman/listinfo/cython-devel >>>>> >>>>> -- >>>>> Sent from my Android phone with K-9 Mail. Please excuse my brevity. >>>>> _______________________________________________ >>>>> cython-devel mailing list >>>>> cython-devel@python.org >>>>> http://mail.python.org/mailman/listinfo/cython-devel >>>>_______________________________________________ >>>>cython-devel mailing list >>>>cython-devel@python.org >>>>http://mail.python.org/mailman/listinfo/cython-devel >>> >>> -- >>> Sent from my Android phone with K-9 Mail. Please excuse my brevity. >>> _______________________________________________ >>> cython-devel mailing list >>> cython-devel@python.org >>> http://mail.python.org/mailman/listinfo/cython-devel >> _______________________________________________ >> cython-devel mailing list >> cython-devel@python.org >> http://mail.python.org/mailman/listinfo/cython-devel > _______________________________________________ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel