[Rcppoctave-user] Apple Blues

[Dominick Samperi]

Well, I convinced myself (I could be wrong) that the problem is not related
to R or Rcpp,
and I did not test RcppOctave. As you suggest, termination protocol may
need to be
tested...


On Fri, Nov 1, 2013 at 4:11 AM, Renaud Gaujoux <
renaud at mancala.cbio.uct.ac.za> wrote:

> What type of R installation did you test this procedure with?
> Ideally this would work with the plain CRAN binary, modulo adapting
> ~/.R/Makevars.
>
>
> As you probably know, the last line of embedded.cc (attached)
>> is very important. Without it there is still a memory error!
>>
>>
>>
> I checked Octave source and clean_up_and_exit is a simple wrapper to
> do_octave_atexit, which I call directly to skip the call to exit, which
> would otherwise terminate the R session as well:
>
> [from
> http://hg.savannah.gnu.org/hgweb/octave/file/eff3d78367f0/src/toplev.cc#l667
> ]
>
> void clean_up_and_exit (int retval)
> {
>   do_octave_atexit ();
>   if (octave_exit)
>     (*octave_exit) (retval == EOF ? 0 : retval);
> }
>
> Note that I actually don't know how to effectively terminate the Octave
> session. Don't know if this even possible since it currently runs in the
> same thread as R (that's at least my understanding). So even after cleaning
> up with do_octave_atexit(), we can still send commands to Octave which
> responds fine, except if errors occurs and then a segfault sometimes come
> up suggesting some thing is in a bad state. Anyway, this is not really a
> big issue.
>
> library(RcppOctave)
> o_runif(1)
> octave_end()
> o_runif(1)
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcppoctave-user/attachments/20131101/3874d2b9/attachment.html>