On Sat, Apr 19, 2008 at 1:41 PM, Dirk Eddelbuettel <[EMAIL PROTECTED]> wrote:
> > Duncan, > > On 20 April 2008 at 05:44, Duncan Temple Lang wrote: > | ~ 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 > > AFAICT it is a classic chicken and egg problem. > > "Something" exists, but is not exactly mature, been used mostly just for a > very large and rapidly changing codebase (ie Quantlib, which should > stabilise > after the 1.0 release 'real soon now') with moderate success and hence > doesn't get off the ground for more. > > | such tools? Do we not have a need for them, or are we not aware of > them, ...? > | or > > My conjecture is that it would take off rather forcefully if only there > were > one or two use cases for moderately-sized well-known libraries, providing > both use cases and usage templates. > This may be somewhat off-topic but: My personal interests have led me away from SWIG-generated bindings, because SWIG does not incorporate the OOP semantics of GObject-based libraries. A large number of C libraries (at least for GUIs and visualization) are implemented around GObject these days, so it's an unfortunate limitation. The GObject introspection project ( http://live.gnome.org/GObjectIntrospection) is really starting to come together. Their IDL, while GObject-focused, will be able to express interfaces to non-GObject-based libraries as well, so it's somewhat of a superset of SWIG. The IDL is XML-based and can be autogenerated from C source using a real C parser (gcc-based). They also finally caught on to my suggestion of embedding memory management, parameter directions, etc in in-line comments (via gtk-doc), which should go a long way towards stream-lining things, even in non-GObject libraries that use gtk-doc like Cairo. The VAPI format from the Vala project (http://live.gnome.org/Vala) is easily hand-edited in C#-ish syntax and will be convertible to the IDL. There are a large number of languages that have some sort of binding to GObject-based libraries (http://www.gtk.org/language-bindings.html), including R of course, and I expect many of them will converge on using the GObject introspection stuff as their input. Anyway, I am not debating the general utility of a SWIG-R connection; just explaining things from my perspective. Michael > | ~ 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 > > I think that is not true. Joe Wang had me CCed on a few email he had with > the > Swig maintainers. He either has or had write access to the Swig repo, and > that seems to make sense as he was, afaik, the only one showing up there. > Or > did you ever offer your code for inclusion there? > > But all that is spilled milk now. Soeren has an _actual_ issue _right > now_ > so what can we do to get a proven tool (ie Swig) working and integrated > with > R for him to get his work done and R and Shogun integrated ? > > | 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 > > Sure, that is very well for you as a research project, but Swig is there, > is > rather mature, understood and widel y used -- just not as much with R as > it > could be. IMHO we'd better off focussing on getting Swig working. > > | 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. > > There is definitely interest. Eg from the Quantlib angle, a few people > expressed interest a few months ago to revive the R/Quantlib integration > via > Swig but nothing much has come of it yet. We're all too busy it seems. > > Dirk > > | ~ 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 > > -- > Three out of two people have difficulties with fractions. > [[alternative HTML version deleted]]
______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
