headers
Luigi Ballabio | 1 Feb 2006 10:01
Picon

Re: [Swig-user] Re: SWIG-1.3.28 release candidate

On 1/31/06, William S Fulton <wsf <at> fultondesigns.co.uk> wrote:
> > Luigi Ballabio wrote:
> >> I still have an %ignore-related issue, but it's more of a corner case
> >> and I had notified William already.
> >>
> > Is this a 1.3.28 issue or an older one?
> >
>
> This occurred in earlier versions, so it isn't a new issue.

Right.

> BTW Luigi until I get around to fixing this, you can workaround the problem by
> adding in:
>
> %ignore Foo::Bar;
>
> then the enum will be wrapped as a plain int.

Ok, I'll try that.

> I can't decide whether the
> correct approach should be an unknown type (SWIGTYPE_p_Bar) or as it
> does it with the %ignore, that is an unnamed enum.

Yet another possibility is to export a minimal SWIGTYPE_p_Foo and add
the enum to it as if Foo weren't ignored.

> This is all bordering
> on wrapping nested types/classes, which as everyone knows, isn't really
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bob Marinier | 1 Feb 2006 16:26
Picon
Favicon

Re: Re: [Swig-user] SWIG-1.3.28 release candidate

Ok, the following .i file crashes SWIG for me:

%module test
namespace sml {
class Agent ;
}
%extend sml::Agent {}

I reduced this to the absolute minimum, so this doesn't look like it 
does anything, but of course there's more to the real code.  It looks 
like SWIG doesn't like forward declarations in namespaces.  I'm running 
SWIG like this:

swig.exe -c++ -tcl test.i

This is on a Windows XP machine using the pre-built Windows binaries for 
1.3.28rc1.  This works with 1.3.27 (although of course this example 
generates warnings).

Bob

Marcelo Matus wrote:
> here we will need a little more help, does it swig crashes with a seg 
> fault?
>
> if that is the case, could you produce a traceback?
>
> also, the best way to fix this is try to set a small example.i file
> that reproduces the error, so, we can debug it over here. Just try
> to trim you interface into a still working (I mean, crashing) case.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Marcelo Matus | 1 Feb 2006 16:31
Picon

Re: Re: [Swig-user] SWIG-1.3.28 release candidate

It seems to be working here with swig-CVS, but I already fixed another 
class forward issue...

$ swig -c++ -tcl8   test.i
test.i:6: Warning(303): %extend defined for an undeclared class sml::Agent.

since you never compiled swig on Windows, we will probably need to wait for
1.3.28-rc2 to see if the problem is solved for you too.... or you can 
try to
have some fun installing swig-CVS.

Marcelo

Bob Marinier wrote:

> Ok, the following .i file crashes SWIG for me:
>
> %module test
> namespace sml {
> class Agent ;
> }
> %extend sml::Agent {}
>
> I reduced this to the absolute minimum, so this doesn't look like it 
> does anything, but of course there's more to the real code.  It looks 
> like SWIG doesn't like forward declarations in namespaces.  I'm 
> running SWIG like this:
>
> swig.exe -c++ -tcl test.i
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bob Marinier | 1 Feb 2006 16:39
Picon
Favicon

Re: Re: [Swig-user] SWIG-1.3.28 release candidate

That's the same warning I get with 1.3.27 for this example, so it's 
probably fixed then.  I'll let you know if I still have problems when 
rc2 comes out.

Thanks,
Bob

Marcelo Matus wrote:
> It seems to be working here with swig-CVS, but I already fixed another 
> class forward issue...
>
> $ swig -c++ -tcl8   test.i
> test.i:6: Warning(303): %extend defined for an undeclared class 
> sml::Agent.
>
> since you never compiled swig on Windows, we will probably need to 
> wait for
> 1.3.28-rc2 to see if the problem is solved for you too.... or you can 
> try to
> have some fun installing swig-CVS.
>
> Marcelo
>
>
>
>
> Bob Marinier wrote:
>
>> Ok, the following .i file crashes SWIG for me:
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marcelo Matus | 2 Feb 2006 06:18
Picon

Re: [Swig-user] Re: SWIG-1.3.28 release candidate

It is fine, unexepected, but fine. What is happening is that the 'out' 
typemap of a named vector typemap
now returns a wrapper object when possible instead of a python copy, for 
example:

  %template(vector_int) vector<int>;

  std::vector<int> data () const;

used to return a python native vector, which is very expensive. I forgot 
to add the flag
to keep the old behavior, but I will added now. Anyway, you probably 
want to do this too:

  
namespace {
  %std_comp_methods(vector<int>);

 %template(vector_int) vector<int>;

 ...
}

That will add the 'comparison methods' (==, <=, >= !=, etc) to std::vector<int>,
then you can compare

     a = gclass.data()
     if a != ((1+5j), (2+5j), (3+5j), (4+5j), (5+5j)): 
          ....
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marcelo Matus | 2 Feb 2006 07:30
Picon

Re: [Swig-user] Re: SWIG-1.3.28 release candidate

Ok, it works as before, if you want to test the extra native feature, 
add to your interface:

namespace std {
 %std_comp_methods(vector<int>);
 %std_comp_methods(vector<double>);
  ...
}

and use

  swig -extranative ...

Adding the %std_comp_methods is also a good idea even if you don't use 
the -extranative
option.

Marcelo

Eric Blossom wrote:

>Hi,
>
>I've tried SWIG-1.3.28rc1 on GNU Radio (gnuradio-core), and it triggers a bunch of
>failures in our test code.  FWIW, our code has been working fine with SWIG
>1.3.{23,24,25,27}.   We use it to generate Python bindings.
>
>Here are a couple of examples:
>
>======================================================================
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marcelo Matus | 2 Feb 2006 09:36
Picon

Re: [Swig-user] Re: [Swig-devel] SWIG-1.3.28 release candidate

Ok, last news on subversion 1.3.0 + swig 1.3.28:

- Python works fine, passes all the tests.
- Ruby passes almost all the tests, four or so fails
- Perl keeps showing a strange error when loading SVN::Core, which is 
not swig generated:

Failed 1/1 tests, 0.00% okay
../../../../../subversion/bindings/swig/perl/native/t/8lock............Use 
of uninitialized value in string eq at

/home/mmatus/srcs/subversion-1.3.0/subversion/bindings/swig/perl/native/blib/lib/SVN/Core.pm 
line 410.
        (in cleanup) Undefined subroutine &SVN::Pool::apr_pool_destroy 
called at

/home/mmatus/srcs/subversion-1.3.0/subversion/bindings/swig/perl/native/blib/lib/SVN/Core.pm 
line 417.
Can't use an undefined value as a SCALAR reference at

/home/mmatus/srcs/subversion-1.3.0/subversion/bindings/swig/perl/native/blib/lib/SVN/Core.pm 
line 376.
        (in cleanup) Undefined subroutine &SVN::Pool::apr_pool_destroy 
called at

/home/mmatus/srcs/subversion-1.3.0/subversion/bindings/swig/perl/native/blib/lib/SVN/Core.pm 
line 417.
Compilation failed in require at 
../../../../../subversion/bindings/swig/perl/native/t/8lock.t line 6.
# Looks like your test died before it could output anything.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jason Stewart | 2 Feb 2006 12:05
Picon
Gravatar

Re: [Swig-user] Re: SWIG-1.3.28 release candidate

Hey,

On 2/2/06, Marcelo Matus <mmatus <at> acms.arizona.edu> wrote:
> - Perl keeps showing a strange error when loading SVN::Core, which is
> not swig generated:
>
> Failed 1/1 tests, 0.00% okay
> ../../../../../subversion/bindings/swig/perl/native/t/8lock............Use
> of uninitialized value in string eq at
> /home/mmatus/srcs/subversion-1.3.0/subversion/bindings/swig/perl/native/blib/lib/SVN/Core.pm
> line 410.
>         (in cleanup) Undefined subroutine &SVN::Pool::apr_pool_destroy
> called at
> /home/mmatus/srcs/subversion-1.3.0/subversion/bindings/swig/perl/native/blib/lib/SVN/Core.pm
> line 417.
> Can't use an undefined value as a SCALAR reference at
> /home/mmatus/srcs/subversion-1.3.0/subversion/bindings/swig/perl/native/blib/lib/SVN/Core.pm
> line 376.
>
> Any subversion/perl guru around?

Well the cleanup code is having trouble after there was an error. It
looks like the first error was in Core.pm line 376 - I don't have the
code with me, so I'd need to see it to figure out more than that.

Cheers, jas.

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Peacock | 2 Feb 2006 15:09

Re: [Swig-user] Re: [Swig-devel] SWIG-1.3.28 release candidate

Marcelo Matus wrote:
> Failed 1/1 tests, 0.00% okay
> ../../../../../subversion/bindings/swig/perl/native/t/8lock............Use
> of uninitialized value in string eq at
> /home/mmatus/srcs/subversion-1.3.0/subversion/bindings/swig/perl/native/blib/lib/SVN/Core.pm
> line 410.
>        (in cleanup) Undefined subroutine &SVN::Pool::apr_pool_destroy
> called at
> /home/mmatus/srcs/subversion-1.3.0/subversion/bindings/swig/perl/native/blib/lib/SVN/Core.pm
> line 417.

Install the new Perl bindings then rerun the tests.  The Perl bindings can get
into a state that during testing the previously installed compiled XS files are
loaded, not the new in-process lib files.  This may be what you are seeing...

HTH

John

--

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
Permalink | Reply | 0 comments |
headers
Marcelo Matus | 2 Feb 2006 18:19
Picon

Re: [Swig-user] SWIG-1.3.28 release candidate

Did you try the last CVS version?, it seems it is solved now.

Bill Spotz wrote:

> I have noticed a bug with docstrings for python.  If I have the  
> following interface file:
>
> %module(docstring="Documentation") Example
>
> The resulting python proxy file looks like
>
> import _Example
> "Documentation"
>
> Since the documentation string does not appear first in the file, it  
> does not populate the __doc__ attribute of the module.
>
> On Jan 29, 2006, at 4:25 PM, William S Fulton wrote:
>
>> A release candidate for SWIG-1.3.28 is online at
>>
>>    http://www.swig.org/swig-1.3.28rc1.tar.gz (Unix source)
>>    http://www.swig.org/swigwin-1.3.28rc1.zip (Windows)
>>
>> This release contains many internal changes and improvements. As  
>> much testing as possible of the release candidate would be  
>> appreciated. Assuming no disasters we aim to make the official  
>> release in 10 days or so.
>>
>> William
(Continue reading)

Permalink | Reply | 11 comments |

Gmane