[Rd] Embedding, core dumps, etc.

[A.J. Rossini]

I'm going to recode the sequence in C tommorow (I'm in Seattle right
now, not Basel, so it's late).

if it dumps core under C, it's Lisp, and if it doesn't, it's most likely R.

I'll report back when I get access to the internet tommorow (I'll be
in Iowa, but not sure when I'll get the laptop connected again).

On 4/19/06, A.J. Rossini <blindglobe at gmail.com> wrote:
> It doesn't seem to help.  I suspect it is more related to signal
> handling changes than the stack.  Note that I dropped that from the
> subject line for my email which started this thread, but I agree, I
> didn't mention signal handing.
>
> On 4/19/06, Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote:
> > Tony,
> >
> > It is possible to turn stack checking off by setting R_CStackLimit = -1 in
> > the embedding application: it works for me, so can you please try it?
> >
> > Brian
> >
> > On Wed, 19 Apr 2006, A.J. Rossini wrote:
> >
> > > Well, nothing has changed in the issues that I brought up earlier,
> > > except that I can confirm core dumps in non-threaded lisps as well
> > > (CLISP), using svn version 37840 (this morning, Seattle time) for
> > > R-2-3-patches.   I've not tried Thomas' suggested fixes, as I'm
> > > hesistant to go down the road of fixing R in such a way that would
> > > require constant patching.
> > >
> > > (so for those counting, neither CLISP, CMUCL, nor SBCL can embed
> > > R-2-3-patches using CFFI on (2 distros of) i386 Linux; all abort and
> > > offer to dump core nearly instantly after initialization).   All work
> > > with R-2-2-patches.
> > >
> > > For me, this is a serious bug.   I suppose other people can define it
> > > in other ways, using terms such as "feature" or "documented".  For
> > > various reasons (see the last bug report I submitted for details), I'm
> > > not going to submit to R-bugs, since by definition, it isn't an R-bug.
> > >
> > > best,
> > > -tony
> > >
> > > blindglobe at gmail.com
> > > Muttenz, Switzerland.
> > > "Commit early,commit often, and commit in a repository from which we
> > > can easily roll-back your mistakes" (AJR, 4Jan05).
> > >
> > > ______________________________________________
> > > R-devel at r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/r-devel
> > >
> > >
> >
> > --
> > Brian D. Ripley,                  ripley at stats.ox.ac.uk
> > Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
> > University of Oxford,             Tel:  +44 1865 272861 (self)
> > 1 South Parks Road,                     +44 1865 272866 (PA)
> > Oxford OX1 3TG, UK                Fax:  +44 1865 272595
> >
>
>
> --
> best,
> -tony
>
> blindglobe at gmail.com
> Muttenz, Switzerland.
> "Commit early,commit often, and commit in a repository from which we can easily
> roll-back your mistakes" (AJR, 4Jan05).
>


--
best,
-tony

blindglobe at gmail.com
Muttenz, Switzerland.
"Commit early,commit often, and commit in a repository from which we can easily
roll-back your mistakes" (AJR, 4Jan05).