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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > > > > > > > > [EMAIL PROTECTED] > > > > Muttenz, Switzerland. > > > > "Commit early,commit often, and commit in a repository from which we > > > > can easily roll-back your mistakes" (AJR, 4Jan05). > > > > > > > > ______________________________________________ > > > > R-devel@r-project.org mailing list > > > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > > > > > > > > > > > -- > > > Brian D. Ripley, [EMAIL PROTECTED] > > > 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 > > > > [EMAIL PROTECTED] > > Muttenz, Switzerland. > > "Commit early,commit often, and commit in a repository from which we can > > easily > > roll-back your mistakes" (AJR, 4Jan05). > > > > > -- > best, > -tony > > [EMAIL PROTECTED] > Muttenz, Switzerland. > "Commit early,commit often, and commit in a repository from which we can > easily > roll-back your mistakes" (AJR, 4Jan05). > -- best, -tony [EMAIL PROTECTED] Muttenz, Switzerland. "Commit early,commit often, and commit in a repository from which we can easily roll-back your mistakes" (AJR, 4Jan05). ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel