On Sun, Apr 20, 2008 at 12:42 PM, Duncan Temple Lang < [EMAIL PROTECTED]> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Dirk Eddelbuettel 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. > > I concur fully. And while it is reasonable for people to wait until there > are good examples and a > working tool, it would be helpful if people would express a sense of > interest for such potential > projects. We have built too many "good" things that people haven't used, > and it would be > good to evaluate this before committing too much time into them. In the > case of something like > interface generators, the idea is well known, so people could express an > interest in the concept > without too much learning being necessary. > Indeed, I recall in 2001 asking why people hadn't cried out for SWIG > facilities for R > and I got at least one blank look :-) > > > > | > | | 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. > > I'm working on that for wxWidgets and Qt at the moment. > And I have some for smaller codebases. > > | > | | ~ 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? > > Well, we are talking about different things. I know Joe had SWIG svn > access. > I didn't get the opportunity to discuss how to include my code as Joe > included > it before I was ready to make it public in that way given its experimental > nature. > Adding it implies some sense of maintenance obligation, potential back > compatability, > etc. and that is why it is not particularly helpful to take a project > somebody is actively working > on and make decisions about it without that person's approval. It is > "water under the bridge", > but helpful to learn from. > > | > | 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 ? > > One "issue" whether Soeren or anyone else needs the R interface > "immediately" or whether this would be just a nice thing to have. > Again, chicken and egg, but given the limited amount of time available > of people who know how to do this "properly", whether a stop-gap solution > or whether we can do it properly over a period of time. > > It is complex to create the general mechanism for SWIG code generation > that covers C and C++ > and handles important aspects. I _might_ be able to get to it > in late summer, but I cannot guarantee it. Once I finish the approach that > leverages > GCC, then I should have at least all the issues resolved with how I think > the mapping > should generate the code. That should simplify implementing the map in > Perl. > > I would be very keen to chat with people who are interested in helping or > have > examples to try out and are willing to withstand the volatility of > development > versions. > > > > > | > | | 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, > ~ Thanks! > | 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. > > I have little doubt that it would be nice to have the RSWIG mechanism > functional. > SWIG is excellent. That's why I did the work back in 2005. > However, SWIG does not do everything that we would like it to do, or > necessarily do it properly. > We can make things "easier" and better and that is why Michael (Lawrence) > and I are exploring > other approaches. And there is not likely to be one single > all-encompassing answer. > > And the claim that it is it well understood requires some qualification. > There are not many people > who know more than the basics > of the SWIG-specific language used to customize and control the code > generation. > And as for widely used - so is MS Windows* :-) > And the idea that "because something is mature and understood and widely > used" > is a very worrying attitude that I am seeing more and more with R. Yes, we > need usable, > useful things. But we have to continue to innovate or fall further and > further behind. > I agree; there needs to be a balance. I'm just wondering though, further behind what? Our potential? Or are there competitors out there? > | > | | 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 > | > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFIC5yw9p/Jzwa2QP4RAtSXAJ9NXtnyFkAly6s9d2UAGabWQUVx8QCffoeb > /pQzTiM3t5h6sEif5pz8yOg= > =nh0D > -----END PGP SIGNATURE----- > > ______________________________________________ > 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
