Grokbase Groups R r-devel April 2006
FAQ
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).

Search Discussions

  • Prof Brian Ripley at Apr 19, 2006 at 6:08 am
    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
  • A.J. Rossini at Apr 19, 2006 at 6:20 am
    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 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).
  • A.J. Rossini at Apr 19, 2006 at 6:25 am
    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 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 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).
  • A.J. Rossini at Apr 19, 2006 at 6:28 am
    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 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 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 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).

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupr-devel @
categoriesr
postedApr 18, '06 at 11:11p
activeApr 19, '06 at 6:28a
posts5
users2
websiter-project.org
irc#r

2 users in discussion

A.J. Rossini: 4 posts Prof Brian Ripley: 1 post

People

Translate

site design / logo © 2022 Grokbase