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

Antonio, Fabio Di Narzo antonio.fabio at gmail.com
Sat Apr 19 20:04:45 CEST 2008


Hi.
I also have looked for a SWIG-R module in the recent past.
However, since my use case was small enough, and given the
experimental state in which I  found the current R module
implementation, I gave up, and coded the bindings manually.

By the way, a tool like SWIG is extremely useful, as tnx to it one
should be able maintain R bindings to whatever C libraries with very
little mainteinance and documentation costs. And this in turn would
open a lot of existing C code to useRs.

Unfortunatly It's too late for it, but seems like a GSoC idea on this
topic would have been quite interesting...

Bests,
Antonio.

2008/4/19, Duncan Temple Lang <duncan at wald.ucdavis.edu>:
> -----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
>
>  ~  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.
>
>  ~  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.
>
>
>  ~ 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
>  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.
>
>  ~  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-----
>
>  ______________________________________________
>  R-devel at r-project.org mailing list
>  https://stat.ethz.ch/mailman/listinfo/r-devel
>


-- 
Antonio, Fabio Di Narzo
Ph.D. student at
Department of Statistical Sciences
University of Bologna, Italy


More information about the R-devel mailing list