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 <[EMAIL PROTECTED]>: > -----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 <[EMAIL PROTECTED]> > 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@r-project.org mailing list > |> https://stat.ethz.ch/mailman/listinfo/r-devel > |> > | > | [[alternative HTML version deleted]] > | > | > | > | ------------------------------------------------------------------------ > | > | ______________________________________________ > | R-devel@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@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 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
