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). ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
