hang on use of ESC in R 2.6.2

Hi,

I notice with R 2.6.2 on a powerpc and on a MacBook Pro that if I  
hit ESC to
annul running a line in the GUI, input hangs with the spinning beach  
ball
for an indefinite period of time.  I haven't tried to see how long  
it will
hang, but
it is at least several minutes too long.  Checking Force Quit  
indicates that
R is not responding.

On the power pc, w/ Tiger (but the same thing happens on my Intel  
Mac w/
Leopard)
sessionInfo()
R version 2.6.2 (2008-02-08)
powerpc-apple-darwin8.10.1

locale:
en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base


Thanks.

best,

Ken


-- 
Ken Knoblauch
Inserm U846
Institut Cellule Souche et Cerveau
D?partement Neurosciences Int?gratives
18 avenue du Doyen L?pine
69500 Bron
France
tel: +33 (0)4 72 91 34 77
fax: +33 (0)4 72 91 34 61
portable: +33 (0)6 84 10 64 10
http://www.sbri.fr

If R is stuck in a long computation in C code that doesn't call
R_ProcessEvents, we're helpless. There is no way to stop that code
until it finishes. Even if you press <Esc> it may not help (just give
you the beachball), because the event of you pressing <Esc> must first
be processed so it can fire,

 desire so to find out what R is doing.
To do so, start a Terminal (in parallel to your unresponsive R) and
type:
gdb
attach R

That should get you into the R process that is spinning. Now you can
issue
bt
to see where it really is. Very likely it will be somewhere is the
package performing the computation. But if it's not, then we want to
know.

Anyway, I suspect that this is not really something we can do much
about (in the current GUI). The new GUI 2.0 is running R in a separate
thread, so it is always responsive despite R being busy, hence we can
deal better with unresponsive R there.

Cheers,
Simon

On Feb 10, 2008, at 10:53 AM, Ken Knoblauch wrote:

Hi,

I notice with R 2.6.2 on a powerpc and on a MacBook Pro that if I
hit ESC to
annul running a line in the GUI, input hangs with the spinning beach
ball
for an indefinite period of time.  I haven't tried to see how long
it will
hang, but
it is at least several minutes too long.  Checking Force Quit
indicates that
R is not responding.

On the power pc, w/ Tiger (but the same thing happens on my Intel
Mac w/
Leopard)
sessionInfo()
R version 2.6.2 (2008-02-08)
powerpc-apple-darwin8.10.1

locale:
en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base


Thanks.

best,

Ken

[I have replied privately, but here is the relevant part of the
response for the list:]

If R is stuck in a long computation in C code

[I have replied privately, but here is the relevant part of the
response for the list:]

If R is stuck in a long computation in C code that doesn't call
R_ProcessEvents, we're helpless. There is no way to stop that code
until it finishes. Even if you press <Esc> it may not help (just give
you the beachball), because the event of you pressing <Esc> must first
be processed so it can fire, but if R is already somewhere in a C
code, so it will never get processed, hence the beachball (on OS X the
beachball means that the application doesn't process events for some
time).

Now, you can debug this if you desire so to find out what R is doing.
To do so, start a Terminal (in parallel to your unresponsive R) and
type:
gdb
attach R

That should get you into the R process that is spinning. Now you can
issue
bt
to see where it really is. Very likely it will be somewhere is the
package performing the computation. But if it's not, then we want to
know.

Anyway, I suspect that this is not really something we can do much
about (in the current GUI). The new GUI 2.0 is running R in a separate
thread, so it is always responsive despite R being busy, hence we can
deal better with unresponsive R there.

Cheers,
Simon

On Feb 10, 2008, at 10:53 AM, Ken Knoblauch wrote:

Hi,

I notice with R 2.6.2 on a powerpc and on a MacBook Pro that if I
hit ESC to
annul running a line in the GUI, input hangs with the spinning beach
ball
for an indefinite period of time.  I haven't tried to see how long
it will
hang, but
it is at least several minutes too long.  Checking Force Quit
indicates that
R is not responding.

On the power pc, w/ Tiger (but the same thing happens on my Intel
Mac w/
Leopard)
sessionInfo()
R version 2.6.2 (2008-02-08)
powerpc-apple-darwin8.10.1

locale:
en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base


Thanks.

best,

Ken


--
Ken Knoblauch
Inserm U846
Institut Cellule Souche et Cerveau
D?partement Neurosciences Int?gratives
18 avenue du Doyen L?pine
69500 Bron
France
tel: +33 (0)4 72 91 34 77
fax: +33 (0)4 72 91 34 61
portable: +33 (0)6 84 10 64 10
http://www.sbri.fr

Will it be possible for ESS to do the same?  I guess this is more  
general
than Mac, but it seems worth asking here at this point.
John Maindonald

[I have replied privately, but here is the relevant part of the
response for the list:]

If R is stuck in a long computation in C code that doesn't call
R_ProcessEvents, we're helpless. There is no way to stop that code
until it finishes. Even if you press <Esc> it may not help (just give
you the beachball), because the event of you pressing <Esc> must  
first
be processed so it can fire, but if R is already somewhere in a C
code, so it will never get processed, hence the beachball (on OS X  
the
beachball means that the application doesn't process events for some
time).

Now, you can debug this if you desire so to find out what R is doing.
To do so, start a Terminal (in parallel to your unresponsive R) and
type:
gdb
attach R

That should get you into the R process that is spinning. Now you can
issue
bt
to see where it really is. Very likely it will be somewhere is the
package performing the computation. But if it's not, then we want to
know.

Anyway, I suspect that this is not really something we can do much
about (in the current GUI). The new GUI 2.0 is running R in a  
separate
thread, so it is always responsive despite R being busy, hence we can
deal better with unresponsive R there.

Cheers,
Simon

On Feb 10, 2008, at 10:53 AM, Ken Knoblauch wrote:

Hi,

I notice with R 2.6.2 on a powerpc and on a MacBook Pro that if I
hit ESC to
annul running a line in the GUI, input hangs with the spinning beach
ball
for an indefinite period of time.  I haven't tried to see how long
it will
hang, but
it is at least several minutes too long.  Checking Force Quit
indicates that
R is not responding.

On the power pc, w/ Tiger (but the same thing happens on my Intel
Mac w/
Leopard)
sessionInfo()
R version 2.6.2 (2008-02-08)
powerpc-apple-darwin8.10.1

locale:
en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base


Thanks.

best,

Ken


--
Ken Knoblauch
Inserm U846
Institut Cellule Souche et Cerveau
D?partement Neurosciences Int?gratives
18 avenue du Doyen L?pine
69500 Bron
France
tel: +33 (0)4 72 91 34 77
fax: +33 (0)4 72 91 34 61
portable: +33 (0)6 84 10 64 10
http://www.sbri.fr

If R is stuck in a long computation in C code that doesn't call
R_ProcessEvents, we're helpless. There is no way to stop that code
until it finishes. Even if you press <Esc> it may not help (just give
you the beachball), because the event of you pressing <Esc> must  
first
be processed so it can fire,

Command :

rnorm(10000)
then I press <Esc>

reproduced the problem. It's not link to the computational time.

Best regards, C.

~~

Mac Intel - OS 10.5.1 / 10.5.2

sessionInfo()

R version 2.6.2 (2008-02-08)
i386-apple-darwin8.10.1

locale:
fr_FR.UTF-8/fr_FR.UTF-8/fr_FR.UTF-8/C/fr_FR.UTF-8/fr_FR.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

desire so to find out what R is doing.
To do so, start a Terminal (in parallel to your unresponsive R) and
type:
gdb
attach R

That should get you into the R process that is spinning. Now you can
issue
bt
to see where it really is. Very likely it will be somewhere is the
package performing the computation. But if it's not, then we want to
know.

Anyway, I suspect that this is not really something we can do much
about (in the current GUI). The new GUI 2.0 is running R in a  
separate
thread, so it is always responsive despite R being busy, hence we can
deal better with unresponsive R there.

Cheers,
Simon

On Feb 10, 2008, at 10:53 AM, Ken Knoblauch wrote:

Hi,

I notice with R 2.6.2 on a powerpc and on a MacBook Pro that if I
hit ESC to
annul running a line in the GUI, input hangs with the spinning beach
ball
for an indefinite period of time.  I haven't tried to see how long
it will
hang, but
it is at least several minutes too long.  Checking Force Quit
indicates that
R is not responding.

On the power pc, w/ Tiger (but the same thing happens on my Intel
Mac w/
Leopard)
sessionInfo()
R version 2.6.2 (2008-02-08)
powerpc-apple-darwin8.10.1

locale:
en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base


Thanks.

best,

Ken

Will it be possible for ESS to do the same?  I guess this is more  
general
than Mac, but it seems worth asking here at this point.
John Maindonald

[I have replied privately, but here is the relevant part of the
response for the list:]

If R is stuck in a long computation in C code that doesn't call
R_ProcessEvents, we're helpless. There is no way to stop that code
until it finishes. Even if you press <Esc> it may not help (just give
you the beachball), because the event of you pressing <Esc> must  
first
be processed so it can fire, but if R is already somewhere in a C
code, so it will never get processed, hence the beachball (on OS X  
the
beachball means that the application doesn't process events for some
time).

Now, you can debug this if you desire so to find out what R is doing.
To do so, start a Terminal (in parallel to your unresponsive R) and
type:
gdb
attach R

That should get you into the R process that is spinning. Now you can
issue
bt
to see where it really is. Very likely it will be somewhere is the
package performing the computation. But if it's not, then we want to
know.

Anyway, I suspect that this is not really something we can do much
about (in the current GUI). The new GUI 2.0 is running R in a  
separate
thread, so it is always responsive despite R being busy, hence we can
deal better with unresponsive R there.

Cheers,
Simon

On Feb 10, 2008, at 10:53 AM, Ken Knoblauch wrote:

Hi,

I notice with R 2.6.2 on a powerpc and on a MacBook Pro that if I
hit ESC to
annul running a line in the GUI, input hangs with the spinning beach
ball
for an indefinite period of time.  I haven't tried to see how long
it will
hang, but
it is at least several minutes too long.  Checking Force Quit
indicates that
R is not responding.

On the power pc, w/ Tiger (but the same thing happens on my Intel
Mac w/
Leopard)
sessionInfo()
R version 2.6.2 (2008-02-08)
powerpc-apple-darwin8.10.1

locale:
en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base


Thanks.

best,

Ken


--
Ken Knoblauch
Inserm U846
Institut Cellule Souche et Cerveau
D?partement Neurosciences Int?gratives
18 avenue du Doyen L?pine
69500 Bron
France
tel: +33 (0)4 72 91 34 77
fax: +33 (0)4 72 91 34 61
portable: +33 (0)6 84 10 64 10
http://www.sbri.fr

[I have replied privately, but here is the relevant part of the
response for the list:]

If R is stuck in a long computation in C code that doesn't call
R_ProcessEvents, we're helpless. There is no way to stop that code
until it finishes. Even if you press <Esc> it may not help (just give
you the beachball), because the event of you pressing <Esc> must first
be processed so it can fire, but if R is already somewhere in a C
code, so it will never get processed, hence the beachball (on OS X the
beachball means that the application doesn't process events for some
time).

Now, you can debug this if you desire so to find out what R is doing.
To do so, start a Terminal (in parallel to your unresponsive R) and
type:
gdb
attach R

That should get you into the R process that is spinning. Now you can
issue
bt
to see where it really is. Very likely it will be somewhere is the
package performing the computation. But if it's not, then we want to
know.

Anyway, I suspect that this is not really something we can do much
about (in the current GUI). The new GUI 2.0 is running R in a separate
thread, so it is always responsive despite R being busy, hence we can
deal better with unresponsive R there.

Cheers,
Simon


On Feb 10, 2008, at 10:53 AM, Ken Knoblauch wrote:

Hi,

I notice with R 2.6.2 on a powerpc and on a MacBook Pro that if I
hit ESC to
annul running a line in the GUI, input hangs with the spinning beach
ball
for an indefinite period of time.  I haven't tried to see how long
it will
hang, but
it is at least several minutes too long.  Checking Force Quit
indicates that
R is not responding.

On the power pc, w/ Tiger (but the same thing happens on my Intel
Mac w/
Leopard)
sessionInfo()
R version 2.6.2 (2008-02-08)
powerpc-apple-darwin8.10.1

locale:
en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base


Thanks.

best,

Ken


--
Ken Knoblauch
Inserm U846
Institut Cellule Souche et Cerveau
D?partement Neurosciences Int?gratives
18 avenue du Doyen L?pine
69500 Bron
France
tel: +33 (0)4 72 91 34 77
fax: +33 (0)4 72 91 34 61
portable: +33 (0)6 84 10 64 10
http://www.sbri.fr

rnorm(10000)
then I press <Esc>

Charles,

thanks a lot for the example. I have now fixed this issue in the
current GUI. Please download and test the updated GUI tomorrow from
http://r.research.att.com/

Thanks,
Simon


On Feb 12, 2008, at 10:43 AM, Charles Hebert wrote:

If R is stuck in a long computation in C code that doesn't call
R_ProcessEvents, we're helpless. There is no way to stop that code
until it finishes. Even if you press <Esc> it may not help (just  
give
you the beachball), because the event of you pressing <Esc> must
first
be processed so it can fire,

Command :

rnorm(10000)
then I press <Esc>

reproduced the problem. It's not link to the computational time.

Best regards, C.

~~

Mac Intel - OS 10.5.1 / 10.5.2

sessionInfo()

R version 2.6.2 (2008-02-08)
i386-apple-darwin8.10.1

locale:
fr_FR.UTF-8/fr_FR.UTF-8/fr_FR.UTF-8/C/fr_FR.UTF-8/fr_FR.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

desire so to find out what R is doing.
To do so, start a Terminal (in parallel to your unresponsive R) and
type:
gdb
attach R

That should get you into the R process that is spinning. Now you can
issue
bt
to see where it really is. Very likely it will be somewhere is the
package performing the computation. But if it's not, then we want to
know.

Anyway, I suspect that this is not really something we can do much
about (in the current GUI). The new GUI 2.0 is running R in a
separate
thread, so it is always responsive despite R being busy, hence we  
can
deal better with unresponsive R there.

Cheers,
Simon

On Feb 10, 2008, at 10:53 AM, Ken Knoblauch wrote:

Hi,

I notice with R 2.6.2 on a powerpc and on a MacBook Pro that if I
hit ESC to
annul running a line in the GUI, input hangs with the spinning  
beach
ball
for an indefinite period of time.  I haven't tried to see how long
it will
hang, but
it is at least several minutes too long.  Checking Force Quit
indicates that
R is not responding.

On the power pc, w/ Tiger (but the same thing happens on my Intel
Mac w/
Leopard)
sessionInfo()
R version 2.6.2 (2008-02-08)
powerpc-apple-darwin8.10.1

locale:
en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods    
base


Thanks.

best,

Ken

Simon

I downloaded the  nightly builded R-GUI as you mentioned
and i still hangs when I try
the example of Charles

rnorm(10000)
then I press <Esc>

Is there any solution about this problem?

Regards

Christoph