SourceForge.net | 2 Feb 16:29 2010
Picon
Picon

[ swig-Bugs-2944675 ] Mismatching between class name and other type

Bugs item #2944675, was opened at 2010-02-02 16:29
Message generated for change (Tracker Item Submitted) made by sloriot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2944675&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Sébastien Loriot (sloriot)
Assigned to: Nobody/Anonymous (nobody)
Summary: Mismatching between class name and other type

Initial Comment:
Hello,

Using the file attached:

struct A{};

template <class T>
struct B{  typedef A C; };

template <class T>
struct C{
(Continue reading)

SourceForge.net | 2 Feb 16:34 2010
Picon
Picon

[ swig-Bugs-2944675 ] Mismatching between class name and other type

Bugs item #2944675, was opened at 2010-02-02 16:29
Message generated for change (Comment added) made by sloriot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2944675&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Sébastien Loriot (sloriot)
Assigned to: Nobody/Anonymous (nobody)
Summary: Mismatching between class name and other type

Initial Comment:
Hello,

Using the file attached:

struct A{};

template <class T>
struct B{  typedef A C; };

template <class T>
struct C{
(Continue reading)

Robert Stone | 2 Feb 20:09 2010
Picon
Picon

perl5 directors

	Support for directors in perl5 on my branch
(https://swig.svn.sourceforge.net/svnroot/swig/branches/talby-perl5-improvements)
is at a point where testcases are passing.  There are still memory
leaks, ugly code, and likely undiscovered functional bugs, but I believe
it worth some experimentation by others.

	The main change to the surfaced Perl interface is that static
member functions are now handled as perl class methods and as thus are
called with class_name->method() syntax instead of the previous
class_name::method() syntax.  This change was necessary once directors
came into the picture because the latter syntax does not consider
inheritance.

{
	package A;
	sub meth { 1 }
}
{
	package B;
	use base 'A';
}
print B->meth(), "\n"; # prints "1"
print B::meth(), "\n"; # emits undefined subroutine error

	Otherwise, I would expect that existing code would generally
continue to work with the new wrappers as long as they don't dive too
deeply under the shadow implementation since it has been completely
reimplemented (perl side tie() calls eliminated).

	I'll be building more tests and deepening existing tests in the
(Continue reading)

William S Fulton | 3 Feb 08:21 2010
Picon

Plan for swig-2.0 - license changes

I'd like the next release of SWIG to be version 2.0. Version 2 was 
always hoped to be the one with nested class support. That is an elusive 
dream right now. The main reason for bumping the version number is a 
change of license. However, as a consolation, the slightly improved 
nested class support I've posted about previously will go into 2.0.

The license change has been put together in conjunction with the 
Software Freedom Conservancy and many thanks must go to them for all the 
time and advice they have given in getting together this plan. There are 
two areas of change in the license.

The first is the generated code. Currently it is unclear as to what the 
obligations / restrictions are on the generated code. The new license 
clears this up so that SWIG does not add any restrictions to the code 
being generated. This means that the user can distribute the generated 
code under a license of their choice, or obligation (if the code they 
are wrapping requires obligations). The license for the generated code 
will be:

You may copy, modify, distribute, and make derivative works based on
this software, in source code or object code form, without
restriction.  When you distribute the software to others, you may do
so according to the terms of your choice.  This software is offered as
is, without warranty of any kind.

The examples shipped with SWIG and everything in the Lib directory will 
also be licensed under the above terms.

The second area for change is to apply GPL version 3 to the SWIG source 
code.
(Continue reading)

William S Fulton | 3 Feb 08:27 2010
Picon

Re: perl5 directors

Robert Stone wrote:
>     Support for directors in perl5 on my branch
> (https://swig.svn.sourceforge.net/svnroot/swig/branches/talby-perl5-improvements)
> is at a point where testcases are passing.  There are still memory
> leaks, ugly code, and likely undiscovered functional bugs, but I believe
> it worth some experimentation by others.
>
>     The main change to the surfaced Perl interface is that static
> member functions are now handled as perl class methods and as thus are
> called with class_name->method() syntax instead of the previous
> class_name::method() syntax.  This change was necessary once directors
> came into the picture because the latter syntax does not consider
> inheritance.
>
> {
>     package A;
>     sub meth { 1 }
> }
> {
>     package B;
>     use base 'A';
> }
> print B->meth(), "\n"; # prints "1"
> print B::meth(), "\n"; # emits undefined subroutine error
>
>     Otherwise, I would expect that existing code would generally
> continue to work with the new wrappers as long as they don't dive too
> deeply under the shadow implementation since it has been completely
> reimplemented (perl side tie() calls eliminated).
>
(Continue reading)

William S Fulton | 3 Feb 08:34 2010
Picon

Re: Plan for swig-2.0 - license changes

William S Fulton wrote:

Bah, one minor correction to the license.
> You may copy, modify, distribute, and make derivative works based on
> this software, in source code or object code form, without
> restriction.  When you distribute the software to others, you may do
Above should read:
restriction.  If you distribute the software to others, you may do

> so according to the terms of your choice.  This software is offered as
> is, without warranty of any kind.
> 

William

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
SourceForge.net | 3 Feb 13:08 2010
Picon
Picon

[ swig-Bugs-2945209 ] kwarg class names renamed before template wrapping

Bugs item #2945209, was opened at 2010-02-03 12:08
Message generated for change (Tracker Item Submitted) made by barrycohen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2945209&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: Barry Cohen (barrycohen)
Assigned to: Olly Betts (olly)
Summary: kwarg class names renamed before template wrapping

Initial Comment:
Hi

This applies to SWIG 1.3.40 and was not present in previous releases.  The problem relates to the new way in
which kwargs are renamed in PHP.

An example file is attached, but is easily demonstrated:

%module example

%{
  template <class T> class Array { };
(Continue reading)

Robert Stone | 3 Feb 19:07 2010
Picon
Picon

Re: perl5 directors

Hi William,

	Sadly, even non-director object lifetimes are not in a good
place on the branch.  I've been trying to solve the whole thing at once,
and getting somewhat overwhelmed I guess.  If it's a worthwhile
intermediate step to recover non-director object lifetimes as they
existed on trunk, that should be quick to work out.

	So that's the bad news, but the good news is that I feel pretty
confident that no other changes to how Perl interfaces with wrappers
will be necessary.  I would like to add some enhancements later
(surfacing constants in a way perl can understand that they're eligible
for constant propagation, for example), but everything of that nature
should be easy to add as opt-in features.

	Thanks very much for all your help so far.

                                                -Robert

On Wed, Feb 03, 2010 at 07:27:34AM +0000, William S Fulton wrote:
>
> This progress is great news. As static methods are not backwards  
> compatible, it would be good to get this into version 2.0.0 as a big  
> version number change is a good opportunity to make these kind of 
> changes.
>
> The object lifetime and ownership is hard to get right for directors and  
> that can be improved over time. If you think that there will not be any  
> non-director usage changes in the future and the object lifetime of  
> non-directors is okay, then consider merging to trunk for 2.0.0.
(Continue reading)

SourceForge.net | 4 Feb 17:53 2010
Picon
Picon

[ swig-Bugs-2946032 ] LUA - trivial but serious mistake in SWIG_Lua_typename; (tp)

Bugs item #2946032, was opened at 2010-02-04 17:53
Message generated for change (Tracker Item Submitted) made by inscii
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2946032&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: lua
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Sennie Soon (inscii)
Assigned to: Mark Gossage (mgossage)
Summary: LUA - trivial but serious mistake in SWIG_Lua_typename; (tp)

Initial Comment:
SWIG_Lua_typename has a tp field, and is checked with lua_isuserdata as such, but consequently it
disregards the tp value and substitutes 1 in the next lua_touserdata call; giving incorrect results with
everything where tp != 1

code:
SWIGRUNTIME const char *SWIG_Lua_typename(lua_State *L, int tp)
{
  swig_lua_userdata* usr;
  if (lua_isuserdata(L,tp))
  {
    usr=(swig_lua_userdata*)lua_touserdata(L,1);  /* get data */ // BUG: <- 1 here should be tp!
(Continue reading)

SourceForge.net | 5 Feb 16:29 2010
Picon
Picon

[ swig-Bugs-2946599 ] MACRO replacement failed when template used

Bugs item #2946599, was opened at 2010-02-05 16:29
Message generated for change (Tracker Item Submitted) made by sloriot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2946599&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: preprocessor
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Sébastien Loriot (sloriot)
Assigned to: Nobody/Anonymous (nobody)
Summary: MACRO replacement failed when template used

Initial Comment:
Hello,

If I have :
#define MYMACRO (A,B)  ....

and I use it like this:
MYMACRO(A,B<A,C>)
then I have this error message
Error: Macro 'MYMACRO' expects 2 arguments

SWIG Version 1.3.40
(Continue reading)


Gmane