headers
derrick | 3 May 2010 18:33

repository branch for fortran77 bindings

I'm working on a set of Fortran 77 bindings for SWIG. What 
is the process was for getting a branch in the source code 
repository so I can check in code as I get stuff working?

Thanks,
dsk

------------------------------------------------------------------------------
Permalink | Reply | 6 comments |
headers
Will Nolan | 3 May 2010 20:49

Re: std::string and R bug

> Changes should be made against trunk which will form the basis of the
> next release (2.0.0). Can you make the change so that older versions of
> R still work?

It looks like in Lib/r/rrun.swg there is code that checks the R version from the R header files:

#if R_VERSION >= R_Version(2,6,0)
#define VMAXTYPE void *
#else
#define VMAXTYPE char *
#endif

Is it possible to do the same check within std_string.i?  If so, then the same version check could 
be used to include or not include both the new code in std_string.i, as well as remove or not remove
the old code in rfragments.swg.

The only issue I can think of is that I don't have an older copy of R that I can do any regression testing
against.  Given that it's just a case of including or not including code, it theoretically shouldn't
break for < 2.6.0 R but it would be best to check.

What do you think is the best course of action here?

Thanks,
Will

------------------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
William S Fulton | 4 May 2010 01:00
Picon
Favicon
Gravatar

Re: Regression found wrt. typemaps (testcase attached)

Torsten Landschoff wrote:
> Hi all,
>
> I am still trying to build wxPython with current SWIG. The next wall
> I ran into is an approach used by wxPython to temporarily mask typemaps.
> It's illustrated in the attached test case. Basically, there are some
> typemaps defined in includes like
>
> %typemap(in) SomeType* {
>     ...
> }
>
> which are later disabled by using
>
> %typemap(in) SomeType*;
>
> in the hope that this disables the specific type map installed before and
> falls back to the more general handling available before.
>
> With current SWIG, this generates invalid wrapper (C++) code.
> It seems that the closest you can get with current SWIG is by using
>
> %typemap(in) SomeType* = SWIGTYPE*;
>
> This is not as modular however, since there may be some more specific
> typemap above SWIGTYPE* which would become visible again with the first
> approach but not with the second.
>
> Using the attached testcase, I bisected the problem and found that this
> behaviour was first disabled in revision 11838 on SWIGs trunk. This was
(Continue reading)

Permalink | Reply | 0 comments |
headers
Will Nolan | 4 May 2010 02:33

Re: memory leak in SWIG_AsPtr_std_string?

William Fulton wrote:
> Your analysis looks correct except the leak is probably only in R. I
> think you should base the solution on one of the other UTL language's
> implementation of SWIG_AsCharPtrAndSize, eg in perlstrings.swg and
> pystrings.swg.
> 
> Try the attached patch and if it solves the problem, I'll commit it.

Looks like the patch alone doesn't do the trick, although I think your changes are correct (and a
better solution than mine).  The code that was generated in my *_wrap.cpp file still had the old pre-patch
code in it
(and thus the leak, verified with valgrind), despite my having applied the patch.
Here's an svn diff that matches the patch contents, just as a sanity check on my part:

[will <at> sfl-dev01 r]$ svn diff rfragments.swg
Index: rfragments.swg
===================================================================
--- rfragments.swg      (revision 12008)
+++ rfragments.swg      (working copy)
 <at>  <at>  -122,7 +122,7  <at>  <at> 
 SWIG_AsCharPtrAndSize(SEXP obj, char** cptr, size_t* psize, int *alloc)
 {
   if (cptr && Rf_isString(obj)) {
-    const char *cstr = CHAR(STRING_ELT(obj, 0));
+    char *cstr = %const_cast(CHAR(STRING_ELT(obj, 0)), char *);
     int len = strlen(cstr);

     if (alloc) {
 <at>  <at>  -130,9 +130,7  <at>  <at> 
         *cptr = %new_copy_array(cstr, len + 1, char);
(Continue reading)

Permalink | Reply | 2 comments |
headers
Will Nolan | 4 May 2010 03:20

new features for R code

I implemented the following features for the R code generation part of SWIG:

- %typemap(newfree) keyword -- was previously not implemented
- Garbage collection -- code is inserted at the end of all R constructor methods to set reg.finalizer (see
??reg.finalizer in R) for the object instance that was just created, where the finalizer method called is
actually the delete_<class> for the class in question.

%typemap(newfree) was tested with a free function that returned a char * allocated by the callee, and
setting %newobject for the function in question.  Looking at the generated wrapper code confirmed that
the newfree code was correctly inserted.

Garbage collection was tested with a short program that repeatedly assigned a new object to a reference,
and then assigned NULL to that reference in a while(1) loop.  Pre-fix this code would result in resident
(RES) usage in top increasing steadily.  Post-fix the resident memory usage does not increase.  As a
further test, a simple C++ object was wrapped and the constructor/destructor implemented to do printf's
of "new" and "delete".  Within R, object construction correctly results in "new" being printed. 
Assigning NULL to a reference correctly results in "delete" being printed.
Furthermore, assigning references to other references does the right thing (i.e. the constructor is not
called, and the destructor is only
called when all references are set to NULL).  This was tested using the gc() call to force garbage collection.

The attached patch has the code changes to Modules/r.cxx.  The documentation probably should be updated as
well to reflect that garbage collection now works (it currently says it doesn't).  Please let me know the
best way to proceed with both.

Thanks,
Will


(Continue reading)






Permalink
| Reply
| 1 comment  
| 



  

  

  





headers


William S Fulton
 | 
5 May 2010 07:06






Picon

Favicon

Gravatar





Re: memory leak in SWIG_AsPtr_std_string?


Will Nolan wrote:
> William Fulton wrote:
>> Your analysis looks correct except the leak is probably only in R. I
>> think you should base the solution on one of the other UTL language's
>> implementation of SWIG_AsCharPtrAndSize, eg in perlstrings.swg and
>> pystrings.swg.
>>
>> Try the attached patch and if it solves the problem, I'll commit it.
> 
> Looks like the patch alone doesn't do the trick, although I think your changes are correct (and a
> better solution than mine).  The code that was generated in my *_wrap.cpp file still had the old pre-patch
code in it
> (and thus the leak, verified with valgrind), despite my having applied the patch.
> Here's an svn diff that matches the patch contents, just as a sanity check on my part:
> 
> [will <at> sfl-dev01 r]$ svn diff rfragments.swg
> Index: rfragments.swg
> ===================================================================
> --- rfragments.swg      (revision 12008)
> +++ rfragments.swg      (working copy)
>  <at>  <at>  -122,7 +122,7  <at>  <at> 
>  SWIG_AsCharPtrAndSize(SEXP obj, char** cptr, size_t* psize, int *alloc)
>  {
>    if (cptr && Rf_isString(obj)) {
> -    const char *cstr = CHAR(STRING_ELT(obj, 0));
> +    char *cstr = %const_cast(CHAR(STRING_ELT(obj, 0)), char *);
>      int len = strlen(cstr);
>  
>      if (alloc) {
>  <at>  <at>  -130,9 +130,7  <at>  <at> 

(Continue reading)






Permalink
| Reply
| 1 comment  
| 



  

  

  





headers


William S Fulton
 | 
5 May 2010 07:33






Picon

Favicon

Gravatar





Re: repository branch for fortran77 bindings


derrick wrote:
> I'm working on a set of Fortran 77 bindings for SWIG. What 
> is the process was for getting a branch in the source code 
> repository so I can check in code as I get stuff working?
> 
Please read http://www.swig.org/Doc1.3/Extending.html and follow up with 
what is required. I'll get you write access and set up a branch for you 
before the full the set of prerequisites are met, provided you have a 
fairly decent patch of your current work. The patch must at the absolute 
minimum follow the coding style guidelines.

You showed some interest in working on the C bindings. Has that now 
changed to Fortran?

William

------------------------------------------------------------------------------






Permalink
| Reply
| 5 comments  
| 



  

  

  





headers


William S Fulton
 | 
5 May 2010 07:46






Picon

Favicon

Gravatar





Re: new features for R code


Will Nolan wrote:
> I implemented the following features for the R code generation part of SWIG:
> 
> - %typemap(newfree) keyword -- was previously not implemented
> - Garbage collection -- code is inserted at the end of all R constructor methods to set reg.finalizer (see
??reg.finalizer in R) for the object instance that was just created, where the finalizer method called is
actually the delete_<class> for the class in question.
> 
> %typemap(newfree) was tested with a free function that returned a char * allocated by the callee, and
setting %newobject for the function in question.  Looking at the generated wrapper code confirmed that
the newfree code was correctly inserted.
> 
> Garbage collection was tested with a short program that repeatedly assigned a new object to a reference,
and then assigned NULL to that reference in a while(1) loop.  Pre-fix this code would result in resident
(RES) usage in top increasing steadily.  Post-fix the resident memory usage does not increase.  As a
further test, a simple C++ object was wrapped and the constructor/destructor implemented to do printf's
of "new" and "delete".  Within R, object construction correctly results in "new" being printed. 
Assigning NULL to a reference correctly results in "delete" being printed.
> Furthermore, assigning references to other references does the right thing (i.e. the constructor is not
called, and the destructor is only
> called when all references are set to NULL).  This was tested using the gc() call to force garbage collection.
> 
> The attached patch has the code changes to Modules/r.cxx.  The documentation probably should be updated
as well to reflect that garbage collection now works (it currently says it doesn't).  Please let me know the
best way to proceed with both.
> 
Will, patches ideally need to be accompanied by a testcase testing the 
fix. Can you read about the test-suite (in the svn version of 
Extending.html) and supply runtime tests to the test-suite with your 
patches? Anything which improves the R test-suite will be most welcome, 

(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


William S Fulton
 | 
5 May 2010 07:55






Picon

Favicon

Gravatar





Final call for swig-2.0.0


I have now come to a point where I have committed all the changes I 
wanted to put in swig-2.0.0. If anyone else wants to put anything else 
into this version please speak up now, otherwise, I'm going to start 
testing on different platforms for release. I'll also try and do a bit 
more documentation tidying up and maybe take another look through the 
bug tracker for any simple fixes.

Robert, are your Perl changes ready for merging into 2.0.0?

William

------------------------------------------------------------------------------






Permalink
| Reply
| 15 comments  
| 



  

  

  





headers


William S Fulton
 | 
5 May 2010 07:57






Picon

Favicon

Gravatar





Re: repository branch for fortran77 bindings


William S Fulton wrote:
> derrick wrote:
>> I'm working on a set of Fortran 77 bindings for SWIG. What is the 
>> process was for getting a branch in the source code repository so I 
>> can check in code as I get stuff working?
>>
> Please read http://www.swig.org/Doc1.3/Extending.html 
Actually, this version is quite out of date. Please read Extending.html 
in svn trunk.

William

------------------------------------------------------------------------------






Permalink
| Reply
| 4 comments  
| 



  

  

  

  


  





    



Gmane