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

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Soeren Sonnenburg-15
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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: swig 1.3.35 & R - is the R wrapper still maintained and of interest?

Michael Lawrence
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 <[hidden email]> 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
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
        [[alternative HTML version deleted]]


______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: swig 1.3.35 & R - is the R wrapper still maintained and of interest?

Duncan Temple Lang
-----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 <[hidden email]> 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
|>
|> ______________________________________________
|> [hidden email] mailing list
|> https://stat.ethz.ch/mailman/listinfo/r-devel
|>
|
| [[alternative HTML version deleted]]
|
|
|
| ------------------------------------------------------------------------
|
| ______________________________________________
| [hidden email] 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-----

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: swig 1.3.35 & R - is the R wrapper still maintained and of interest?

Antonio, Fabio Di Narzo
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 <[hidden email]>:

> -----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 <[hidden email]> 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
>  |>
>  |> ______________________________________________
>  |> [hidden email] mailing list
>  |> https://stat.ethz.ch/mailman/listinfo/r-devel
>  |>
>  |
>  |       [[alternative HTML version deleted]]
>  |
>  |
>  |
>  | ------------------------------------------------------------------------
>  |
>  | ______________________________________________
>  | [hidden email] 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-----
>
>  ______________________________________________
>  [hidden email] 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
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: swig 1.3.35 & R - is the R wrapper still maintained and of interest?

Soeren Sonnenburg-15
In reply to this post by Duncan Temple Lang
On Sun, 2008-04-20 at 05:44 +1200, Duncan Temple Lang wrote:

> -----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

Just to do some advertising on this. Using swig you basically
automagically get your C function directly available in R. And using
typemaps you get things like

compute_foo(double* vec, int len);

immediately wrapped to R and you may call it via

compute_foo(c(1.1, 2.2, 3.3))

same for matrices, returning things and for object oriented stuff even
slots!!

For the shogun project this means: I for free can support an R, octave
and python port only by writing the typemaps once for each language! And
hey I've written these typemaps already so you could immediately use
this without messing with the R C interface at all.

So this is of incredible help and I really think that this should be
worked on further.

> ~  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.

Was this with R 2.7 and pasting things? Because it strangely doesn't
crash when I do R < script.R

> ~  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.

Well I guess this could easily be changed if you post on the swig-devel
mailinglist with some short explanation. Also swig's svn-trunk is
publicly available and as no one seems to maintain the R port your
patches will stay current :) Anyway now that this port is in swig, I
suggest to maintain it there - things can only improve...

> ~ 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

Well I would be and I have everything inside of shogun ready (all
typemaps, build system etc).

> 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.

I would very much hope that we can fix up SWIG & R, with the compile fix
for R2.7 to begin with. I would not want to invest time in another
solution than swig, simply because swig is very widespread and well
maintained for at least python & octave. However while I can contribute
isolated test cases with as much debugging information as needed I am
unable to do the fixes to the swig-R core.

I will certainly ASAP try out patches and I could write some examples...

Soeren

> ~  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 <[hidden email]> 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
> |>
> |> ______________________________________________
> |> [hidden email] mailing list
> |> https://stat.ethz.ch/mailman/listinfo/r-devel
> |>
> |
> | [[alternative HTML version deleted]]
> |
> |
> |
> | ------------------------------------------------------------------------
> |
> | ______________________________________________
> | [hidden email] 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-----
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: swig 1.3.35 & R - is the R wrapper still maintained and of interest?

Dirk Eddelbuettel
In reply to this post by Duncan Temple Lang

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.

| ~  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 <[hidden email]> 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
| |>
| |> ______________________________________________
| |> [hidden email] mailing list
| |> https://stat.ethz.ch/mailman/listinfo/r-devel
| |>
| |
| | [[alternative HTML version deleted]]
| |
| |
| |
| | ------------------------------------------------------------------------
| |
| | ______________________________________________
| | [hidden email] 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-----
|
| ______________________________________________
| [hidden email] mailing list
| https://stat.ethz.ch/mailman/listinfo/r-devel

--
Three out of two people have difficulties with fractions.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: swig 1.3.35 & R - is the R wrapper still maintained and of interest?

Michael Lawrence
On Sat, Apr 19, 2008 at 1:41 PM, Dirk Eddelbuettel <[hidden email]> 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 <[hidden email]>
> 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
> | |>
> | |> ______________________________________________
> | |> [hidden email] mailing list
> | |> https://stat.ethz.ch/mailman/listinfo/r-devel
> | |>
> | |
> | |     [[alternative HTML version deleted]]
> | |
> | |
> | |
> | |
> ------------------------------------------------------------------------
> | |
> | | ______________________________________________
> | | [hidden email] 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-----
> |
> | ______________________________________________
> | [hidden email] mailing list
> | https://stat.ethz.ch/mailman/listinfo/r-devel
>
> --
> Three out of two people have difficulties with fractions.
>
        [[alternative HTML version deleted]]


______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: swig 1.3.35 & R - is the R wrapper still maintained and of interest?

Duncan Temple Lang
In reply to this post by Dirk Eddelbuettel
-----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.

|
| | 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 <[hidden email]> 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
| | |>
| | |> ______________________________________________
| | |> [hidden email] mailing list
| | |> https://stat.ethz.ch/mailman/listinfo/r-devel
| | |>
| | |
| | | [[alternative HTML version deleted]]
| | |
| | |
| | |
| | | ------------------------------------------------------------------------
| | |
| | | ______________________________________________
| | | [hidden email] 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-----
| |
| | ______________________________________________
| | [hidden email] 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-----

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: swig 1.3.35 & R - is the R wrapper still maintained and of interest?

Michael Lawrence
On Sun, Apr 20, 2008 at 12:42 PM, Duncan Temple Lang <
[hidden email]> 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 <[hidden email]>
> 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
> | | |>
> | | |> ______________________________________________
> | | |> [hidden email] mailing list
> | | |> https://stat.ethz.ch/mailman/listinfo/r-devel
> | | |>
> | | |
> | | |   [[alternative HTML version deleted]]
> | | |
> | | |
> | | |
> | | |
> ------------------------------------------------------------------------
> | | |
> | | | ______________________________________________
> | | | [hidden email] 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-----
> | |
> | | ______________________________________________
> | | [hidden email] 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-----
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
        [[alternative HTML version deleted]]


______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel