[Rd] more help with 'inline' package
To anyone who can help, I am running R on Windows, and have recently discovered Oleg Skylar's amazing new package "inline," but I am having a difficult time operating it on Windows.Looking at some e-mail messages that were exchanged in May, it seems as if Duncan Murdoch had a similar experience, and attached an appropriate patch.But how does this patch work?Where do I download it, and once it is downloaded, should the examples in the "inline" package work? Any help would be greatly appreciated. Carsten Botts __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] readchar() bug or feature? was Re: Clarification for readChar man page
On 14/06/2007 5:05 PM, Jeffrey Horner wrote:
> Jeffrey Horner wrote:
>> Duncan Murdoch wrote:
>>> On 6/14/2007 10:49 AM, Jeffrey Horner wrote:
Hi,
Here's a patch to the readChar manual page (R-trunk as of today) that
better clarifies readChar's return value.
>>> Your update is not right. For example:
>>>
>>> x <- as.raw(32:96)
>>> readChar(x, nchars=rep(2,100))
>>>
>>> This returns a character vector of length 100, of which the first 32
>>> elements have 2 chars, the next one has 1, and the rest are "".
>>>
>>> So the length of nchars really does affect the length of the value.
>>>
>>> Now, I haven't looked at the code, but it's possible we could delete the
>>> "(which might be less than \code{length(nchars)})" remark, and if not,
>>> it would be useful to explain the situations in which the return value
>>> could be shorter than the nchars vector.
>> Well, this is rather a misunderstanding on my part; I completely forgot
>> about vectorization. The manual page makes sense to me now.
>>
>> But the situation about the return value possibly being less than
>> length(nchars) isn't clear. Consider a 101 byte text file in a
>> non-multibyte character locale:
>>
>> f <- tempfile()
>> writeChar(paste(rep(seq(0,9),10),collapse=''),con=f)
>>
>> and calling readChar() to read 100 bytes with length(nchar)=10:
>>
>> > readChar(f,nchar=rep(10,10))
>> [1] "0123456789" "0123456789" "0123456789" "0123456789" "0123456789"
>> [6] "0123456789" "0123456789" "0123456789" "0123456789" "0123456789"
>>
>> and readChar() reading the entire file with length(nchar)=11:
>>
>> > readChar(f,nchar=rep(10,11))
>> [1] "0123456789" "0123456789" "0123456789" "0123456789" "0123456789"
>> [6] "0123456789" "0123456789" "0123456789" "0123456789" "0123456789"
>> [11] "\0"
>>
>> but the following two outputs are confusing. readchar() with
>> length(nchar)>=12 returns a character vector length 12:
>>
>> > readChar(f,nchar=rep(10,12))
>> [1] "0123456789" "0123456789" "0123456789" "0123456789" "0123456789"
>> [6] "0123456789" "0123456789" "0123456789" "0123456789" "0123456789"
>> [11] "\0" ""
>> > readChar(f,nchar=rep(10,13))
>> [1] "0123456789" "0123456789" "0123456789" "0123456789" "0123456789"
>> [6] "0123456789" "0123456789" "0123456789" "0123456789" "0123456789"
>> [11] "\0" ""
>>
>> It seems that the first time EOF is encountered on a read operation, an
>> empty string is returned, but on subsequent reads nothing is returned.
>> Is this intended behavior?
>
> I believe this is an off-by-1 bug in do_readchar(). The following fix to
> R-trunk v41946 causes the above readchar() calls to cap the returned
> vector length at 11:
>
> Index: src/main/connections.c
> ===
> --- src/main/connections.c (revision 41946)
> +++ src/main/connections.c (working copy)
> @@ -3286,7 +3286,7 @@
> if(!con->open(con)) error(_("cannot open the connection"));
> }
> PROTECT(ans = allocVector(STRSXP, n));
> -for(i = 0, m = i+1; i < n; i++) {
> +for(i = 0, m = 0; i < n; i++) {
> len = INTEGER(nchars)[i];
> if(len == NA_INTEGER || len < 0)
> error(_("invalid value for '%s'"), "nchar");
>
>
> Jeff
>
Thanks for working this out. I think your patch is right, but there's
another bug: raw vectors are handled differently than connections.
I'll fix both problems, but I'll do it in R-devel, not R-patched: I
think we were consistent with the documentation before, so the bug is
not extremely serious, and it's getting too close to the release of
2.5.1 to make this change there (since someone may have depended on the
previous behaviour).
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug in R environments? Was: [BioC] 'recursive default argument' error...
Thanks for the slow example. The issue is more specifically pertinent to
lazyloading of environments than I had realized. Because interrupts are
only checked for every 100 eval() calls, the chances that you will check
one during a standard lazyload call are low (but not zero). However, when
you lazyload an environment, it calls the unserialize hook function which
is an interpreted function containing a for loop over entries in the
environment. So lazyloading of a sizeable environment is vulnerable to
interruption to a much higher degree than other objects.
Luke Tierney and I have been discussing possible strategies. It seems too
close to 2.5.1 for a comprehensive solution there, but palliative measures
may be possible. Meanwhile, take care in interrupting
On Tue, 12 Jun 2007, Seth Falcon wrote:
> Prof Brian Ripley <[EMAIL PROTECTED]> writes:
>
>> On Tue, 12 Jun 2007, Oleg Sklyar wrote:
>>
>>> Dear developers,
>>>
>>> has anyone experienced the problem described below? Is it a bug in
>>> handling interrupts in R?
>>
>> I am not sure where you think the 'bug' is in: cf your subject line.
>> My guess is that the package is using environments in a vulnerable
>> way.
>
> The issue at hand is, I believe, the same as that discussed here:
>
> http://thread.gmane.org/gmane.comp.lang.r.devel/8103/focus=8104
>
>> I cannot reproduce your example on my system: I was able to interrupt but
>> repeating the as.list worked.
>
> Try with a larger environment. I can reproduce this with a recent
> R-devel using the GO package:
>
>> library(GO)
>> GOTERM
>^C
>> GOTERM
>Error: recursive default argument reference
>
>> What I suspect may have happened is that
>> you have interrupted lazy loading. From the code
>>
>> if(PRSEEN(e))
>> errorcall(R_GlobalContext->call,
>>_("recursive default argument reference"));
>> SET_PRSEEN(e, 1);
>> val = eval(PRCODE(e), PRENV(e));
>> SET_PRSEEN(e, 0);
>>
>> so you will get this message from a promise whose evaluation was
>> incomplete. I can see several ways around that, but most have runtime
>> costs or back-compatibility issues. (Changing the message may help.)
>>
>> It looks like rae230a has been implemented to use lazy-loading on whole
>> environments (the 'source' is already a lazyload database, so it's not
>> transparent). Lazy-loading was intended for members of environments.
>>
>> Also, does this happen in R-devel? There lazy-loading is considerably
>> faster and closer to an atomic operation.
>>
>> All guesswork on something I cannot reproduce, of course.
>
> Good guesses. Yes, _all_ Bioconductor annotation data packages
> currently store each identifier mapping in a separate environment. So
> the package environment contains environments. The lazy loading db is
> important at runtime when users may only need to access one or two of
> the environments. We generate the lazy-loading dbs by hand so that
> users installing from source do not have to repeat the process
> themselves. Since the environments are large, it is possible to use
> the packages on a system that does not have enough memory to
> "properly" install them.
>
> + seth
>
>
--
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, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
