From hpages at fhcrc.org  Sat Oct 30 00:59:09 2010
From: hpages at fhcrc.org (=?ISO-8859-1?Q?Herv=E9_Pag=E8s?=)
Date: Fri, 29 Oct 2010 15:59:09 -0700
Subject: [Rd] list2env() is broken
In-Reply-To: <7C129F9F-79DA-4D7D-B974-88F8A6F06CAA@r-project.org>
References: <4CCA613D.3050802@fhcrc.org>	<alpine.LFD.2.00.1010290812150.1613@gannet.stats.ox.ac.uk>	<4CCB0A28.2040407@fhcrc.org>	<AANLkTimdwwXrinn5tfcfR2z2Aaai2-p-R5SMzw8WohJB@mail.gmail.com>
	<7C129F9F-79DA-4D7D-B974-88F8A6F06CAA@r-project.org>
Message-ID: <4CCB51BD.7090700@fhcrc.org>

Hi Simon,

On 10/29/2010 02:57 PM, Simon Urbanek wrote:
>
> 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 ;).
>

I think my report was as useful as it can be. Useful in the sense that
someone could actually use it to reproduce the problem and come up with
a fix. See: the fix was made less than 2 hours after I reported the
problem. Much faster than any of the other bugs/problems I've reported
on this list in the past 2 or 3 months.

So again, thanks for the prompt fix and useful improvements to the
function!

And sorry for using the term "timeout" in the inappropriate context.
Was 11 pm when I reported the problem last night and I was trying
to understand why this package times out on our build system:

 
http://bioconductor.org/checkResults/2.8/bioc-LATEST/CoCiteStats/lamb2-checksrc.html

Ah, and about the traceback. Well it was not that useful so that's why
I didn't include it:

 >   x <- as.list(1:200000)
 >   names(x) <- paste("A", 1:200000, sep="")
 >   e <- list2env(x)

  *** caught bus error ***
address 0x18, cause 'non-existent physical address'

Traceback:
  1: list2env(x)

Also I don't see that it is a requirement in the posting guide
(but I do agree that a traceback is generally a must).

Cheers,
H.


> 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
>>
>>
>
> ______________________________________________
> 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



[Rd] list2env() is broken
=?ISO-8859-1?Q?Herv=E9_Pag=E8s?=