Re: [Discuss-gnuradio] SWIG, current gr-howto structure and exception specifiers
On Tue, Jun 5, 2012 at 2:58 PM, Martin Braun wrote: > On Sun, Jun 03, 2012 at 10:22:14AM -0400, Tom Rondeau wrote: >> On the other hand, I thought all standard exceptions were passed >> properly through SWIG to Python already. I was under the impression >> that if you're header file declares that it throws, then you can catch >> it in Python. If that's not the case, then we should try to figure out >> an easy way to handle that. > > Hi Tom and rest, > > so, I didn't do my research properly (partly): Exceptions *are* caught by > SWIG, *but* they always end up as RuntimeErrors, regardless of what the > exception type was in C++. > > So, for future reference: > If you throw a std::invalid_argument in a block constructor, it ends > up as a RuntimeError in Python. If you hand-edit the SWIG file and add > an exception specifier, it ends up as a ValueError, which I think is the > better behaviour, and it would be great if SWIG did this automatically. > > But frankly, I don't think this is that big a deal, I'll just catch > RuntimeErrors instead of ValueErrors. Or edit .i-files. > > There's just no "clean" way to do this, because you'd either have to > specify the exceptions in the header (which is deprecated C++), write a > .i (redundant) or lose the exception type. > > MB Yeah, I remember looking at this a while ago (since there is still an error where FreeBSD treats one particular exception incorrectly). There are a few exceptions that are handled by SWIG, but mostly the C++ ones just get smashed into one or maybe two different exceptions in Python. I'm of the opinion that I agree that it's not a big deal. An exception might now be technically incorrect, but I think we can translate as needed. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SWIG, current gr-howto structure and exception specifiers
On Sun, Jun 03, 2012 at 10:22:14AM -0400, Tom Rondeau wrote: > On the other hand, I thought all standard exceptions were passed > properly through SWIG to Python already. I was under the impression > that if you're header file declares that it throws, then you can catch > it in Python. If that's not the case, then we should try to figure out > an easy way to handle that. Hi Tom and rest, so, I didn't do my research properly (partly): Exceptions *are* caught by SWIG, *but* they always end up as RuntimeErrors, regardless of what the exception type was in C++. So, for future reference: If you throw a std::invalid_argument in a block constructor, it ends up as a RuntimeError in Python. If you hand-edit the SWIG file and add an exception specifier, it ends up as a ValueError, which I think is the better behaviour, and it would be great if SWIG did this automatically. But frankly, I don't think this is that big a deal, I'll just catch RuntimeErrors instead of ValueErrors. Or edit .i-files. There's just no "clean" way to do this, because you'd either have to specify the exceptions in the header (which is deprecated C++), write a .i (redundant) or lose the exception type. MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SWIG, current gr-howto structure and exception specifiers
On Fri, May 11, 2012 at 7:03 AM, Martin Braun wrote: > In the current state of gr-howto (which is also used in gr_modtool), the > SWIG stuff is done pretty intelligently by using the header files as > .i-files, which means there is no need to write a SWIG header for every > block. > > One advantage of this was the possibility to add stuff in the .i-file > which weren't in the .h-file; specifically, exception specifiers. > > Example (from gr-specest, specest_welch.i): > > GR_SWIG_BLOCK_MAGIC(specest,welch); > > specest_welch_sptr > specest_make_welch(unsigned fft_len, int overlap, int ma_len, bool fft_shift, > const std::vector &window) > throw(std::invalid_argument); > > // And so on . > > > If I don't declare the exception specifier, I can't catch the exception > in Python. If I simply include specest_welch.h in specest_swig.i, I need > to add the specifiers in the C++-code, which is not very popular (and I > think not future-compatible, and gcc doesn't handle that well). > > Here's my question: is there a cool way to have SWIG know about the > exceptions without having to write a .i-file for every block that uses > exceptions? Can I 'tag' the source code in a way that gcc doesn't care, > but SWIG does? > > Thanks for any nice ideas! > > MB Marin, With the restructuring of the code and implementation style in the up-coming version 3.7, we are moving in the same direction of just including .h files in the component's main swig .i file. For a very large majority of cases, there is no need for extra code in the .i file, so this reduces duplication and simplifies a lot. For those cases where a developer needs to add SWIG-specific things to an interface file, you can always edit it by hand and include everything required to make it work. I'm not practiced enough in SWIG to know this off the top of my head, but I should think that you could just include the header file and overwrite a specific case as needed. On the other hand, I thought all standard exceptions were passed properly through SWIG to Python already. I was under the impression that if you're header file declares that it throws, then you can catch it in Python. If that's not the case, then we should try to figure out an easy way to handle that. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] SWIG, current gr-howto structure and exception specifiers
In the current state of gr-howto (which is also used in gr_modtool), the SWIG stuff is done pretty intelligently by using the header files as .i-files, which means there is no need to write a SWIG header for every block. One advantage of this was the possibility to add stuff in the .i-file which weren't in the .h-file; specifically, exception specifiers. Example (from gr-specest, specest_welch.i): GR_SWIG_BLOCK_MAGIC(specest,welch); specest_welch_sptr specest_make_welch(unsigned fft_len, int overlap, int ma_len, bool fft_shift, const std::vector &window) throw(std::invalid_argument); // And so on . If I don't declare the exception specifier, I can't catch the exception in Python. If I simply include specest_welch.h in specest_swig.i, I need to add the specifiers in the C++-code, which is not very popular (and I think not future-compatible, and gcc doesn't handle that well). Here's my question: is there a cool way to have SWIG know about the exceptions without having to write a .i-file for every block that uses exceptions? Can I 'tag' the source code in a way that gcc doesn't care, but SWIG does? Thanks for any nice ideas! MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpDqILuMvNVS.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
