[ swig-Bugs-1863647 ] Multiple modules leads to unhandled exception

Bugs item #1863647, was opened at 2008-01-03 23:25
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=1863647&group_id=1645

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: code generation (general)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ben Webb (benwebb)
Assigned to: Nobody/Anonymous (nobody)
Summary: Multiple modules leads to unhandled exception

Initial Comment:
When using methods from multiple methods, Python crashes with "terminate called after throwing an 
instance of 'swig::stop_iteration'". Here is a simple example:

module1.i:
%module module1
%include "std_vector.i"
%template(vectori) std::vector<int>;

module2.i:
%module module2
%include "std_vector.i"

[ swig-Bugs-1863647 ] Multiple modules leads to unhandled exception

Bugs item #1863647, was opened at 2008-01-03 18:25
Message generated for change (Comment added) made by jlcherry
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=1863647&group_id=1645

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: code generation (general)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ben Webb (benwebb)
Assigned to: Nobody/Anonymous (nobody)
Summary: Multiple modules leads to unhandled exception

Initial Comment:
When using methods from multiple methods, Python crashes with "terminate called after throwing an 
instance of 'swig::stop_iteration'". Here is a simple example:

module1.i:
%module module1
%include "std_vector.i"
%template(vectori) std::vector<int>;

module2.i:
%module module2
%include "std_vector.i"

[ swig-Bugs-1863647 ] Multiple modules leads to unhandled exception

Bugs item #1863647, was opened at 2008-01-03 23:25
Message generated for change (Comment added) made by benwebb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=1863647&group_id=1645

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: code generation (general)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ben Webb (benwebb)
Assigned to: Nobody/Anonymous (nobody)
Summary: Multiple modules leads to unhandled exception

Initial Comment:
When using methods from multiple methods, Python crashes with "terminate called after throwing an 
instance of 'swig::stop_iteration'". Here is a simple example:

module1.i:
%module module1
%include "std_vector.i"
%template(vectori) std::vector<int>;

module2.i:
%module module2
%include "std_vector.i"

[ swig-Bugs-1864275 ] stl.i PySequence_Cont uses assign(...) incorrectly

Bugs item #1864275, was opened at 2008-01-04 19:05
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=1864275&group_id=1645

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: python
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Scott (ses4j)
Assigned to: Nobody/Anonymous (nobody)
Summary: stl.i PySequence_Cont uses assign(...) incorrectly

Initial Comment:
In pycontainer.swg (about line 680) in the fragment StdSequenceTraits, there is an issue/bug that causes
problems when SWIGging some complicated types.

fragment StdSequenceTraits has the line seq->assign(pyseq.begin(), pyseq.end()).  I recommend not
using assign ever and using the SWIG_STD_NOASSIGN_STL part always instead, and changing the insert()
call to:

seq->insert(seq->end(), (value_type) ((*it).operator value_type()));

instead.

Python: some way to avoid discarding qualifiers?

swig currently generates a lot of casts from (const char *) to (char *).
This is only necessary for older versions of Python; newer versions use
the "const" keyword appropriately. For example, the (char *) in the
following line is no longer necessary for Python >= 2.5:

data->newraw = PyObject_GetAttrString(data->klass, (char *)"__new__");

Would it be possible to have some way to disable these casts? They
generate a lot of spurious warnings for those of us that use some more
pedantic compiler warnings (such as -Wcast-qual for gcc) and make the
code harder to read. 

Cheers,

Jelmer

--

-- 
Jelmer Vernooij <jelmer <at> samba.org> - http://samba.org/~jelmer/
Jabber: jelmer <at> jabber.fsfe.org

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: Python: some way to avoid discarding qualifiers?

Jelmer Vernooij <jelmer <at> samba.org> writes:

> 
> swig currently generates a lot of casts from (const char *) to (char *).
> This is only necessary for older versions of Python; newer versions use
> the "const" keyword appropriately. For example, the (char *) in the
> following line is no longer necessary for Python >= 2.5:
> 
> data->newraw = PyObject_GetAttrString(data->klass, (char *)"__new__");
> 
> Would it be possible to have some way to disable these casts? They
> generate a lot of spurious warnings for those of us that use some more
> pedantic compiler warnings (such as -Wcast-qual for gcc) and make the
> code harder to read. 
> 

I guess they could be replaced by a macro that would do nothing if python >= 2.5
or provide the cast otherwise. The code would then look something like:

data->newraw = PyObject_GetAttrString(data->klass, SWIG_CHAR_CAST"__new__");

where SWIG_CHAR_CAST would be one of the following depending on which python.h
is being compiled with:

#define SWIG_CHAR_CAST (char *)
#define SWIG_CHAR_CAST

It isn't much more readable, in fact it is less readable, but it will get rid of
your warnings. The code that SWIG generates is largely independent of the
version of Python being targeted. There are some SWIG Python module specific

[ swig-Bugs-1867350 ] [php5] Some SWIG errors should be PHP exceptions

Bugs item #1867350, was opened at 2008-01-09 02:15
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=1867350&group_id=1645

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: php
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Olly Betts (olly)
Assigned to: Olly Betts (olly)
Summary: [php5] Some SWIG errors should be PHP exceptions

Initial Comment:
If the user passes parameters to a wrapped function which don't match those expected by any overridden
form, then a PHP fatal error is issued, which can't be caught.  This makes it harder to build a robust
application, and it's hard to debug what the problem really is.

PHP5 supports exceptions, so these errors could be thrown as PHP exceptions instead, which would be a
better approach I think.

We should consider what to do with other errors in the SWIG bindings.

PHP4 doesn't support exceptions, but the last PHP4 release has now happened, and security support ends on
2008-08-08, so PHP4 support will be irrelevant soon.

Re: Python: some way to avoid discarding qualifiers?

Am Montag, den 07.01.2008, 09:37 +0000 schrieb William S Fulton:
> Jelmer Vernooij <jelmer <at> samba.org> writes: 
> > swig currently generates a lot of casts from (const char *) to (char *).
> > This is only necessary for older versions of Python; newer versions use
> > the "const" keyword appropriately. For example, the (char *) in the
> > following line is no longer necessary for Python >= 2.5:
> > 
> > data->newraw = PyObject_GetAttrString(data->klass, (char *)"__new__");
> > 
> > Would it be possible to have some way to disable these casts? They
> > generate a lot of spurious warnings for those of us that use some more
> > pedantic compiler warnings (such as -Wcast-qual for gcc) and make the
> > code harder to read. 
> > 
> 
> I guess they could be replaced by a macro that would do nothing if python >= 2.5
> or provide the cast otherwise. The code would then look something like:
> 
> data->newraw = PyObject_GetAttrString(data->klass, SWIG_CHAR_CAST"__new__");
> 
> where SWIG_CHAR_CAST would be one of the following depending on which python.h
> is being compiled with:
> 
> #define SWIG_CHAR_CAST (char *)
> #define SWIG_CHAR_CAST
> 
> It isn't much more readable, in fact it is less readable, but it will get rid of
> your warnings. The code that SWIG generates is largely independent of the
> version of Python being targeted. There are some SWIG Python module specific
> flags, like -modern, which would ideally be used. However this is not

Re: Python: some way to avoid discarding qualifiers?

On 2008-01-10, Jelmer Vernooij <jelmer <at> samba.org> wrote:
> I'd rather avoid that if possible, defines indeed make the code less
> readable and we do have to read the code when debugging the
> SWIG-generated code.

While readable generated code is certainly useful, I think there are
higher priorities.  As the boilerplate comment at the top already says:

    "This file is not intended to be easily readable"

> Ideally I would like to just push all of the complexity for this into
> SWIG and make the -modern flag take care of not emitting these casts.
> Why specifically is this not technically possible at the moment ? I
> would be happy to provide patches, if possible.

Because -modern currently requires Python 2.2 or newer, and only Python
2.5 doesn't need these casts (older versions generate warnings with
recent versions of GCC).  I don't think it makes sense to add a
"-moremodern" option just for this - SWIG already has bafflingly many
options (particularly for Python), and more options means more
combinations which won't be regularly tested and so will bitrot.

Also, "--moremodern" would go against the general SWIG aim of producing
code which works with as many versions of the targetted tool as
feasible.

I think right now a macro is your best option.  Either as William
describes, or one which wraps PyObject_GetAttrString() and inserts
the cast when required - e.g.:

Re: Python: some way to avoid discarding qualifiers?

Am Donnerstag, den 10.01.2008, 18:18 +0000 schrieb Olly Betts:
> On 2008-01-10, Jelmer Vernooij <jelmer <at> samba.org> wrote:
> > I'd rather avoid that if possible, defines indeed make the code less
> > readable and we do have to read the code when debugging the
> > SWIG-generated code.
> While readable generated code is certainly useful, I think there are
> higher priorities.  As the boilerplate comment at the top already says:
> 
>     "This file is not intended to be easily readable"
And I think that's wrong; it should be. Writing SWIG files, you often
have to read this file to fix problems. Running a debugger on Python
with SWIG modules loaded, also means having to read this source code.
This is also one of the main things that scares people away from SWIG,
because to be able to debug the generated code, you have to have some
idea of what the structure of the generated file is.

> > Ideally I would like to just push all of the complexity for this into
> > SWIG and make the -modern flag take care of not emitting these casts.
> > Why specifically is this not technically possible at the moment ? I
> > would be happy to provide patches, if possible.
> Because -modern currently requires Python 2.2 or newer, and only Python
> 2.5 doesn't need these casts (older versions generate warnings with
> recent versions of GCC).  I don't think it makes sense to add a
> "-moremodern" option just for this - SWIG already has bafflingly many
> options (particularly for Python), and more options means more
> combinations which won't be regularly tested and so will bitrot.
> 
> Also, "--moremodern" would go against the general SWIG aim of producing
> code which works with as many versions of the targetted tool as
> feasible.