[Rd] list2env() is broken

[Simon Urbanek]

On Oct 29, 2010, at 4:56 PM, Henrik Bengtsson wrote:

> On Fri, Oct 29, 2010 at 10:53 AM, Hervé Pagès <hpages at fhcrc.org> wrote:
>> Hi,
>> 
>> On 10/29/2010 12:17 AM, Prof Brian Ripley wrote:
>>> 
>>> I have no idea what 'timeout' means, but that *should* take an
>>> extraordinarily long time (it is at least quadratic in the input
>>> length). This is the point of hashing -- you *need* hash=TRUE, and you
>>> should probably also set 'size' in new.env.
>> 
>> I can see that this has just been changed and now list2env() decides
>> to use hash=TRUE for me (when length(x) > 100). Sounds reasonable since
>> I *need* it.
>> Also the man page didn't mention anything about the purpose of
>> hash=TRUE (now it does, thanks), it was just saying "see new.env"
>> but the man page for new.env() doesn't say much either (in particular
>> it doesn't say anything about the quadratic behavior when hash=FALSE).
>> 
>>> 
>>> There was an obvious missing PROTECT in this function.
>> 
>> Thanks for catching and fixing this.
>> 
>>> 
>>> I do wonder if you are yet familiar with the debugging tools described
>>> in 'Writing R Extensions' -- please do use them before reporting.
>> 
>> Please note that I've tried to put as much details as possible in the
>> last 10 bug reports or so that I've made (most of the time even
>> suggesting solutions). Sometimes I don't have time to debug or to come
>> with a solution but I think it's still worth reporting the problem,
>> especially when it's a crash. Also AFAIK the posting guide says nothing
>> about me having to use the debugging tools or come up with a solution
>> before I report a problem.
> 
> I second this; it is better to share potential issues than being
> silent about them; others might observe the same thing and pitch in.
> 

That part yes, but I think Herve took it the wrong way - no one is asking people for solutions as they are very often wrong and may be leading away form the real cause. What is more important are precise facts. I think Brian's point was that reports should have enough details to be useful and Herve's "timeout on Linux, crash on Mac and Windows" is so vague and uninformative (timeout of what? when? crash where?) that it's essentially useless (the example was not - which I think was the only reason someone looked at it). If you have a crash, it's good idea to include a crash report. Also there is no such thing as "timeout" in this context - Herve meant probably hanging R which you should look at by attaching a debugger to get a backtrace to see where it is (on Mac you get an automatic backtrace if you force-quite the app which makes it easier). I think Herve is experienced enough to know better ;).

Cheers,
Simon


> I also agree that everyone should try to troubleshoot as much as
> possible to minimize the efforts required by anyone trying to solve
> the problem.  It's a fine balance, it's a pain as a maintainer having
> to do the last bit of troubleshooting just to find out in the end that
> it was an error by the user/report, but we have to accept some false
> positives in order to catch more true positives.  As often done on
> this list, FPs are accepted but when a user keep reporting many of
> them, it is made clear to them that he/she needs to do more
> troubleshooting before reporting.  It seems to work in most cases.
> 
> We need to embrace testers and reports on potential issues without
> requiring them to provide the actually fixes or even understanding the
> code.
> 

Yes, exactly and 

> /Henrik
> /Henrik
> 
>> 
>> Thanks again for the fix,
>> H.
>> 
>>> 
>>> On Thu, 28 Oct 2010, Hervé Pagès wrote:
>>> 
>>>> Hi,
>>>> 
>>>> The following code produces different kinds of problems depending
>>>> on which platform you run it:
>>>> 
>>>> x <- as.list(1:200000)
>>>> names(x) <- paste("A", 1:200000, sep="")
>>>> e <- list2env(x)
>>>> 
>>>> Timeout on Linux, crash on Mac and Windows, with R 2.12.0 and
>>>> current R devel.
>>>> 
>>>> The "multi-assign" mode (i.e. when the 'envir' arg is supplied)
>>>> doesn't seem to have this problem.
>>>> 
>>>> Cheers,
>>>> H.
>>>> 
>>>> --
>>>> Hervé Pagès
>>>> 
>>>> Program in Computational Biology
>>>> Division of Public Health Sciences
>>>> Fred Hutchinson Cancer Research Center
>>>> 1100 Fairview Ave. N, M2-B876
>>>> P.O. Box 19024
>>>> Seattle, WA 98109-1024
>>>> 
>>>> E-mail: hpages at fhcrc.org
>>>> Phone: (206) 667-5791
>>>> Fax: (206) 667-1319
>>>> 
>>>> ______________________________________________
>>>> R-devel at r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>> 
>>> 
>> 
>> 
>> --
>> Hervé Pagès
>> 
>> Program in Computational Biology
>> Division of Public Health Sciences
>> Fred Hutchinson Cancer Research Center
>> 1100 Fairview Ave. N, M2-B876
>> P.O. Box 19024
>> Seattle, WA 98109-1024
>> 
>> E-mail: hpages at fhcrc.org
>> Phone:  (206) 667-5791
>> Fax:    (206) 667-1319
>> 
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> 
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
>