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<hpa...@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: hpa...@fhcrc.org
Phone: (206) 667-5791
Fax: (206) 667-1319

______________________________________________
R-devel@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: hpa...@fhcrc.org
Phone:  (206) 667-5791
Fax:    (206) 667-1319

______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel



______________________________________________
R-devel@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: hpa...@fhcrc.org
Phone:  (206) 667-5791
Fax:    (206) 667-1319

______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Reply via email to