On Sun, Apr 20, 2008 at 12:42 PM, Duncan Temple Lang <
duncan@wald.ucdavis.edu> 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 <r-ml@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@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]]

