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).
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 conne
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,
>
By `documentation' do you mean `comments in the file'? If so, this is too
minor to change whilst R 2.3.0 is in code freeze, but has been changed for
R-devel.
If not, please can we have a more precise indication of where you are
refering to?
On Tue, 18 Apr 2006, [EMAIL PROTECTED] wrote:
> In
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
Peter Ruckdeschel <[EMAIL PROTECTED]> writes:
> Summing up the discussions in this thread, I have built a package
> 'startupmsg' available (in a first version) for the moment at
>
> http://www.uni-bayreuth.de/departments/math/org/mathe7/R-devel/startupmsg_0.1.tar.gz
>
> (see documentation within)
This is related to this FAQ:
http://stat.cmu.edu/R/CRAN/doc/FAQ/R-FAQ.html#Why-doesn_0027t-R-think-these-numbers-are-equal_003f
What you can do is create the sequence of integers from 6155 to 6200
rather than using floats and then divide by 100 in your subsequent
calculation. Until the point you
Another thing to notice (rather than, it would seem, assume), is that
using round() doesn't do any "better":
### without rounding
> print(seq(61.55, 61.59, by=.01) , digits=22)
[1] 61.547 61.555 61.570 61.578
[5] 61.586
### with roundi
On 4/18/2006 7:02 PM, Peter Ruckdeschel wrote:
> Hi R-devels,
>
> would it be possible to enhance either promptPackage()
> or the default indexing mechanism for packages
> so that -- if it exists -- (the contents of) file
> -package.Rd is sorted first in
>
> * the .dvi / .pdf documentation fi
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 fi
Hi R-devels,
would it be possible to enhance either promptPackage()
or the default indexing mechanism for packages
so that -- if it exists -- (the contents of) file
-package.Rd is sorted first in
* the .dvi / .pdf documentation file
* the .chm documentation file
* the package 00index.htm
Summing up the discussions in this thread, I have built a package
'startupmsg' available (in a first version) for the moment at
http://www.uni-bayreuth.de/departments/math/org/mathe7/R-devel/startupmsg_0.1.tar.gz
(see documentation within)
In particular, I took up suggestions from Seth Falcon's
In src/main/gram.y, the documentation for R_ParseVector has a wrong
signature:
SEXP R_ParseVector(TextBuffer *text, int n, ParseStatus *status)
should be
SEXP R_ParseVector(SEXP text, int n, ParseStatus *status)
In addition, the two occurrences of "IOBuffer" in the documentation
should be repla
> The seq-command produces unnescessary inaccurate results, which can be
> extremely
> annoying. I absolutely do not see the nescessity of numerical garbage
> to appear in the following simple case. E.g. try this:
> > seq ( 61.55 , 62.00 , by=0.01 ) - round ( seq ( 61.55 , 62.00 , by=0.01 ) ,
>
Thanks to all who replied. I will try par(mar=).
David
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
On 4/18/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Full_Name: Johannes Prix
> Version: 2.1.1
> OS: WinXP, SuSE Linux
> Submission from: (NULL) (137.208.41.195)
>
>
>
> The seq-command produces unnescessary inaccurate results, which can be
> extremely
> annoying. I absolutely do not see th
Full_Name: Johannes Prix
Version: 2.1.1
OS: WinXP, SuSE Linux
Submission from: (NULL) (137.208.41.195)
The seq-command produces unnescessary inaccurate results, which can be extremely
annoying. I absolutely do not see the nescessity of numerical garbage to appear
in the following simple case.
[EMAIL PROTECTED] writes:
> xyplot is in the contributed package lattice, so this the wrong place to
> report.
>
> In any case, whoever needs to look at this (in this case, the package
> maintainer) needs a reproducible example.
Also, check whether the name "df" matters. It could be a search o
xyplot is in the contributed package lattice, so this the wrong place to
report.
In any case, whoever needs to look at this (in this case, the package
maintainer) needs a reproducible example.
On Tue, 18 Apr 2006, [EMAIL PROTECTED] wrote:
> Full_Name: Katell Hamon
> Version: 2.2.1
> OS: window
Full_Name: Katell Hamon
Version: 2.2.1
OS: windows
Submission from: (NULL) (130.226.135.149)
I have a problem in :
xyplot(df[,v] ~ df$year ,
[]
)
the error is "Error in df[, v] : object is not subsettable"
but this used to run
>> Sorry, I wasn't aware, .c files would be scrubbed. Testcase available for=20
>> download here:
>> http://rkward.sourceforge.net/temp/threadEmbed.c
It's not the file extension nor the real content that counts;
rather it's the (MIME) 'content-type' which matters:
You can well have text attachme
On Tue, 18 Apr 2006, Berwin A Turlach wrote:
> G'day David,
>
>> "DA" == David Allen <[EMAIL PROTECTED]> writes:
>
>DA> When a graph is saved as PostScript, the bounding box is often
>DA> too big. A consequence is that when the graph is included in
>DA> a LaTeX document, the spaci
22 matches
Mail list logo
