[Rd] Embedding, core dumps, etc.

[A.J. Rossini]

I should also make it clear -- while I reported non-fatal stack errors
in the first thread, I'm not seeing them any more, just the core dump.

On 4/19/06, A.J. Rossini <blindglobe at gmail.com> wrote:
> 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).
>


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