[Rd] swig 1.3.35 & R - is the R wrapper still maintained and of interest?

Sat Apr 19 22:07:44 CEST 2008

On Sun, 2008-04-20 at 05:44 +1200, Duncan Temple Lang wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> Hi Michael and Soeren
> 
> ~  I've waited to see if there would be posts from others, but am
> a little surprised to see only your two.  It would seem people aren't
> using SWIG for R and I wonder why this community hasn't used or wanted
> such tools?  Do we not have a need for them, or are we not aware of them, ...?
> or

Just to do some advertising on this. Using swig you basically
automagically get your C function directly available in R. And using
typemaps you get things like

compute_foo(double* vec, int len);

immediately wrapped to R and you may call it via

compute_foo(c(1.1, 2.2, 3.3)) 

same for matrices, returning things and for object oriented stuff even
slots!!

For the shogun project this means: I for free can support an R, octave
and python port only by writing the typemaps once for each language! And
hey I've written these typemaps already so you could immediately use
this without messing with the R C interface at all.

So this is of incredible help and I really think that this should be
worked on further. 

> ~  So what to do?  Firstly, I don't get that crash on load on my Linux
> box.  So we would have to investigate further, but at least it does work
> somewhere.  And such extreme failures are actually less worrying than the
> potential lack of functionality in the bindings.

Was this with R 2.7 and pasting things? Because it strangely doesn't
crash when I do R < script.R

> ~  Soeren has already been in touch with me and indeed the
> code in the SWIG distribution comes origially from the RSWIG source on the
> omegahat repository. Unfortunately, the person who took that code
> and put into the SWIG distribution did by himself and didn't seem
> to want to work together to improve it add get it beyond the experimental state
> it was in.  Futher, he apparently listed me as the contributor,
> but haven't communicated at all with the SWIG developers and so I do not have
> access to the SWIG repository and cannot change the code.
> So we have a little bit of a problem that might have been better dealt with if
> code had continued to be developed outside of SWIG by the R community.

Well I guess this could easily be changed if you post on the swig-devel
mailinglist with some short explanation. Also swig's svn-trunk is
publicly available and as no one seems to maintain the R port your
patches will stay current :) Anyway now that this port is in swig, I
suggest to maintain it there - things can only improve...

> ~ If there is nobody interested in using SWIG in R, then there is little point
> in fixing it.  I have been working on an alternative way to generate bindings using

Well I would be and I have everything inside of shogun ready (all
typemaps, build system etc). 

> output from GCC (gcc & g++) and exploring how the bindings should work
> generally.  Most of the ideas I think would be able to go back into SWIG
> and that _might_ be an easier tool for people to use who don't want more control
> over the code generation or to do analysis on the code itself.
> But if nobody other than the two of us is interested in using a general interface code
> generation mechanism, then perhaps we shouldn't waste too much time on such
> general resources.  However, I think it is of value and I think
> we can fix up the SWIG module with a little collaboration.

I would very much hope that we can fix up SWIG & R, with the compile fix
for R2.7 to begin with. I would not want to invest time in another
solution than swig, simply because swig is very widespread and well
maintained for at least python & octave. However while I can contribute
isolated test cases with as much debugging information as needed I am
unable to do the fixes to the swig-R core.

I will certainly ASAP try out patches and I could write some examples...

Soeren

> ~  D.
> 
> 
> Michael Lawrence wrote:
> | I am not sure what is included with swig, but have you seen this?
> |
> | http://www.omegahat.org/RSWIG/
> |
> | I'm not sure if it's actively maintained, but at the very least it might
> | help in your efforts at getting an R swig driver working.
> |
> | Michael
> |
> | On Fri, Apr 18, 2008 at 3:49 AM, Soeren Sonnenburg <r-ml at nn7.de> wrote:
> |
> |> Dear all,
> |>
> |> I was trying to use the R swig wrapper with R 2.7 and shogun
> |> ( http://www.shogun-toolbox.org ) but it fails completely, as in doesn't
> |> even compile and even after patching then though compiling - crashes...
> |>
> |> So I asked on swig-users/swig-devel CC'ing the potential R maintainer
> |> but I never received a reply. I now wonder if anyone here could help or
> |> would be willing to maintain R+swig.
> |>
> |> The compile fix for R 2.7 is here
> |>
> |> http://article.gmane.org/gmane.comp.programming.swig/12697
> |>
> |> and the crash I am now that it compiles see is
> |>
> |> #0  0xb804e201 in _dl_debug_state () from /lib/ld-linux.so.2
> |> #1  0xb8051608 in dl_open_worker () from /lib/ld-linux.so.2
> |> #2  0xb804d5d6 in _dl_catch_error () from /lib/ld-linux.so.2
> |> #3  0xb8050f5e in _dl_open () from /lib/ld-linux.so.2
> |> #4  0xb74c3c19 in dlopen_doit () from /lib/i686/cmov/libdl.so.2
> |> #5  0xb804d5d6 in _dl_catch_error () from /lib/ld-linux.so.2
> |> #6  0xb74c42bc in _dlerror_run () from /lib/i686/cmov/libdl.so.2
> |> #7  0xb74c3b51 in dlopen@@GLIBC_2.1 () from /lib/i686/cmov/libdl.so.2
> |> #8  0xb7efd036 in loadLibrary (path=0xbfa5650c
> |> "/home/sonne/Documents/work/fml/repositories/shogun/trunk/src/features/Features.so",
> |> asLocal=1, now=1, search=0x9a81f20 "") at dynload.c:92
> |> #9  0xb7d6efb3 in AddDLL (path=0xbfa5650c
> |> "/home/sonne/Documents/work/fml/repositories/shogun/trunk/src/features/Features.so",
> |> asLocal=1, now=1, DLLsearchpath=0x9a81f20 "") at Rdynload.c:543
> |> #10 0xb7d6f657 in do_dynload (call=0x9e23998, op=0x9a91e44,
> |> args=0xa60d5e0, env=0xa60d650) at Rdynload.c:904
> |> #11 0xb7e43dba in do_internal (call=0x9e239d0, op=0x9a8798c,
> |> args=0xa60d5e0, env=0xa60d650) at names.c:1129
> |> #12 0xb7e0df21 in Rf_eval (e=0x9e239d0, rho=0xa60d650) at eval.c:463
> |> #13 0xb7e11a3c in Rf_applyClosure (call=0xa60d74c, op=0x9e23a94,
> |> arglist=0xa60d6dc, rho=0x9a9a720, suppliedenv=0x9a9a73c) at eval.c:669
> |> #14 0xb7e0de19 in Rf_eval (e=0xa60d74c, rho=0x9a9a720) at eval.c:507
> |> #15 0xb7e31a00 in Rf_ReplIteration (rho=0x9a9a720, savestack=0,
> |> browselevel=0, state=0xbfa589a8) at main.c:257
> |> #16 0xb7e31ddc in run_Rmainloop () at main.c:306
> |> #17 0xb7e31e1c in Rf_mainloop () at main.c:974
> |> #18 0x08048776 in main (ac=1, av=0xb805b668) at Rmain.c:35
> |> #19 0xb7be8450 in __libc_start_main () from /lib/i686/cmov/libc.so.6
> |> #20 0x08048691 in _start ()
> |>
> |> To reproduce
> |>
> |> ï»¿wget http://nn7.de/debugging/shogun-0.6.1+svn2882.tar.bz2
> |> tar xjf shogun-0.6.1+svn2882.tar.bz2
> |> cd shogun-0.6.1+svn2882/src
> |> ./configure --interface=R-modular
> |> make
> |>
> |> (wait a few minutes)
> |>
> |> R
> |> dyn.load('features/Features.so')
> |> #source("features/Features.R") # not even necessary.
> |>
> |> Note that shogun works for both python and octave nicely...
> |>
> |> ï»¿So the question for me is, will this be better maintained in the future
> |> or should I stop investing time on getting R supported?
> |>
> |> Desperate,
> |> Soeren
> |>
> |> ______________________________________________
> |> R-devel at r-project.org mailing list
> |> https://stat.ethz.ch/mailman/listinfo/r-devel
> |>
> |
> | 	[[alternative HTML version deleted]]
> |
> |
> |
> | ------------------------------------------------------------------------
> |
> | ______________________________________________
> | R-devel at r-project.org mailing list
> | https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFICi9m9p/Jzwa2QP4RAv6qAJ9Ov/0ZrzXxQutS86fk/VgdH09G3wCdG2v5
> p/XgqF2ZakrmJzZtHSb7ZLY=
> =RPiM
> -----END PGP SIGNATURE-----
> 