Re: [Rd] list2env() is broken

[Prof Brian Ripley]

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.


There was an obvious missing PROTECT in this function.

I do wonder if you are yet familiar with the debugging tools described 
in 'Writing R Extensions' -- please do use them before reporting.


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:20)
 names(x) <- paste("A", 1:20, 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



--
Brian D. Ripley,  rip...@stats.ox.ac.uk
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

Re: [Rd] Scripting SVG with R

[Michael Lawrence]

Lots of interesting responses to this, but I would add that the qtbase
package allows for interesting hybrid applications between the
web/javascript and R. Qt includes a WebKit port, which is integrated with
the QtScript module,  a javascript implementation.  With qtbase, one could
hypothetically embed WebKit within R and expose R objects (extending
QObject) to the Javascript context. Thus, one can call R through Javascript,
in a running R session. You can also modify the Javascript code in the page,
making it possible to integrate R with any page off the web.

See:
http://qt.nokia.com/qt-in-use/files/pdf/qt-features-for-hybrid-web-native-application-development

I haven't actually tested all of that with qtbase, but it should work in
theory. Embedding widgets (with R callbacks) into web pages definitely
works.

There is also the QtSvg module, which parses and outputs SVG.

Michael

On Wed, Oct 13, 2010 at 8:30 AM, Wolfgang Huber  wrote:

>
> Since now many browsers support (ECMA/Java-)scripted SVG, I am wondering
> whether there are already any examples of inserting R code into SVG
> documents (or a Javascript canvas?) either directly, or perhaps more likely
> through a JavaScript layer, to dynamically generate graphics or make them
> interactive?
>
> I am aware of the excellent packages gridSVG and SVGAnnotation, which
> facilitate making R-generated SVG plots more interesting either at
> construction time or by postprocessing; the above question is about
> employing R at viewing time.
>
> Best wishes
>
> Wolfgang Huber
> EMBL
> http://www.embl.de/research/units/genome_biology/huber
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

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

Re: [Rd] Reference Classes: Generalizing Reference Class Generator objects?

[John Chambers]

Good diagnoses.

This thread brought up a point or two that needed some fixes to the 
documentation and code.  They should be in r-devel and 2.12 patched 
(from rev. 53471).


Briefly:

- Initialization methods should take account of future subclasses to 
your class by including and passing on the ... argument, so that 
additional fields can be specified.  Discussed briefly now in the 
$new(...) section of ?ReferenceClasses.


- The InitFields() method is fine but was an early kludge when 
callSuper() didn't work for initialize().  To allow for the case that 
your class has a superclass with an initialize() method, use the 
callSuper() approach.  There is an example now in the documentation.


John

On 10/28/10 10:55 AM, Jon Clayden wrote:

?ReferenceClasses says "Reference methods can not themselves be
generic functions; if you want additional function-based method
dispatch, write a separate generic function and call that from the
method". So I think you'd need to take that approach in your
"initialize" method.

Hope this helps,
Jon


On 28 October 2010 18:25, Daniel Lee  wrote:

Thank you. Your example really clarifies what the $initialize(...) function
is supposed to do.

Do you know if there is a straightforward way to dispatch the $new(...)
method based on the signature of the arguments? I am thinking along the
lines of S4 methods with valid signatures.

Thanks again for the example.


On 10/28/2010 12:12 PM, Jon Clayden wrote:


Sorry - you don't need to assign the value of initFields(). I was
going to do it in two lines but then realised one was enough... :)

TestClass<- setRefClass ("TestClass",
fields = list (text = "character"),
methods = list (
initialize = function (text) {
initFields(text=paste(text,"\n")) },
print = function ()  { cat(text) } )
)

All the best,
Jon


On 28 October 2010 15:13, Daniel Leewrote:


Is it possible to override the $new(...) in the reference class
generator? I
have tried adding a "new" method to the methods of the class, but that is
obviously not correct. I have also tried adding it to the class
generator,
but the class generator still uses the default constructor.

As a simple example, this is the current interface:
TestClass<- setRefClass ("TestClass",
fields = list (text = "character"),
methods = list (
print = function ()  {cat(text)})
)
test<- TestClass$new (text="Hello World")
test$print()

I would like to override $new(...) to be something like (add a "\n" to
the
end of the input, no need to specify input fields):
TestClass$methods (new = function (text) {
text<- paste (text, "\n")
methods:::new (def, text=text)
})

The constructor would then be:
test<- TestClass$new ("Hello World")

This is a subtle, but useful change. I have also tried adding to
TestClass a
method $newInstance(text), but that was not successful. If this is not
possible, could we consider augmenting the Reference Class interface to
include constructors?

__
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

Re: [Rd] list2env() is broken

[Hervé Pagès]

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.

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:20)
names(x) <- paste("A", 1:20, 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

Re: [Rd] Reference Classes: Generalizing Reference Class Generator objects?

[Vitalie S.]

John Chambers  writes:

> Good diagnoses.
>
> This thread brought up a point or two that needed some fixes to the 
> documentation and code.  They should be in
> r-devel and 2.12 patched (from rev. 53471).
>
> Briefly:
>
> - Initialization methods should take account of future subclasses to your 
> class by including and passing on the
> ... argument, so that additional fields can be specified.  Discussed briefly 
> now in the $new(...) section of
> ?ReferenceClasses.
>
> - The InitFields() method is fine but was an early kludge when callSuper() 
> didn't work for initialize().  To allow
> for the case that your class has a superclass with an initialize() method, 
> use the callSuper() approach.  There is
> an example now in the documentation.

What about, extending the generator class in general? Looking at the source I
can infer that there is little that can be done about it (except rewriting the
setRefClass function itself). Does that mean that the refObjectGenerator class 
is
not supposed to be extended?

Also, tangentially related to above, why generator objects in the first place?
It might have been implemented as S4 class with the slot "def" to hold the
representation of refClasses. No additional generators would hang around,
extension of generators would be easier and departure from S4 would be minimal.

The only reason I could think off, is the inability to write ref style methods
for it. But, I must be definitely missing something here.

Thanks,
Vitalie.
>
> On 10/28/10 10:55 AM, Jon Clayden wrote:
>> ?ReferenceClasses says "Reference methods can not themselves be
>> generic functions; if you want additional function-based method
>> dispatch, write a separate generic function and call that from the
>> method". So I think you'd need to take that approach in your
>> "initialize" method.
>>
>> Hope this helps,
>> Jon
>>
>>
>> On 28 October 2010 18:25, Daniel Lee  wrote:
>>> Thank you. Your example really clarifies what the $initialize(...) function
>>> is supposed to do.
>>>
>>> Do you know if there is a straightforward way to dispatch the $new(...)
>>> method based on the signature of the arguments? I am thinking along the
>>> lines of S4 methods with valid signatures.
>>>
>>> Thanks again for the example.
>>>
>>>
>>> On 10/28/2010 12:12 PM, Jon Clayden wrote:

 Sorry - you don't need to assign the value of initFields(). I was
 going to do it in two lines but then realised one was enough... :)

 TestClass<- setRefClass ("TestClass",
 fields = list (text = "character"),
 methods = list (
 initialize = function (text) {
 initFields(text=paste(text,"\n")) },
 print = function ()  { cat(text) } )
 )

 All the best,
 Jon


 On 28 October 2010 15:13, Daniel Leewrote:
>
> Is it possible to override the $new(...) in the reference class
> generator? I
> have tried adding a "new" method to the methods of the class, but that is
> obviously not correct. I have also tried adding it to the class
> generator,
> but the class generator still uses the default constructor.
>
> As a simple example, this is the current interface:
> TestClass<- setRefClass ("TestClass",
> fields = list (text = "character"),
> methods = list (
> print = function ()  {cat(text)})
> )
> test<- TestClass$new (text="Hello World")
> test$print()
>
> I would like to override $new(...) to be something like (add a "\n" to
> the
> end of the input, no need to specify input fields):
> TestClass$methods (new = function (text) {
> text<- paste (text, "\n")
> methods:::new (def, text=text)
> })
>
> The constructor would then be:
> test<- TestClass$new ("Hello World")
>
> This is a subtle, but useful change. I have also tried adding to
> TestClass a
> method $newInstance(text), but that was not successful. If this is not
> possible, could we consider augmenting the Reference Class interface to
> include constructors?
>
> __
> 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

Re: [Rd] list2env() is broken

[Henrik Bengtsson]

On Fri, Oct 29, 2010 at 10:53 AM, Hervé Pagès  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.

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.

/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:20)
>>> names(x) <- paste("A", 1:20, 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

Re: [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  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:20)
 names(x) <- paste("A", 1:20, 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/ma

Re: [Rd] list2env() is broken

[Hervé Pagès]

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  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:20)
>   names(x) <- paste("A", 1:20, 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:20)
names(x)<- paste("A", 1:20, 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,