search

hodgesse1 / rfortran

Automatically exported from code.google.com/p/rfortran
0 stars 0 forks source link

Unexpected change in behaviour of R/RFortran after R upgrade 2.11.1 -> 2.14.2 #105

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
*** What steps will reproduce the problem?

1. Run an RFortran-based BATEA functionality (say, posterior diagnostics - 
builtin or BAD) using a link to R 2.11.1

2. Run the same sequence of steps using a link to R 2.14.2. This can be 
accomplished by adjusting the Rpath and Rname in the FPF file.

*** What is the expected output?

Since I did not change any Rfortran settings, I expected to see R 2.14.2 behave 
in the same way as R 2.11.1. However, the following was noted / reproduced 
several times:

1. R 2.11.1 would visibly start as a console, statConn would flash, some black 
command prompts would flash, R would do the calcs/plots, and when finished just 
sit there. Closing it down removed RGui.exe from the Windows process list (in 
Task Manager).

2. R 2.14.2 would not visibly start. statConn and the command prompts would 
still flash. Results would be generated correctly. However, since no R console 
is open, it cannot be closed. The Task Manager shows 2 x R.exe and 1 x 
Rterm.exe. This number was obtained when running the prototype 
BATEA+DMSL+BAD+RFortran combo. The 3 processes seemed to be part of the same 
process tree (all got killed by "kill process tree")

*** What version of RFortran are you using?

RFortran r700 from branch 3.x.

*** On which Windows operating system?

On Windows XP 32-bit - The best Windoz to date!

*** What Fortran compiler (name and version number) are you using?

The same behaviour was reproduced using apps built with Intel 11.0 and CVF 6.6 
compilers.

*** What version of R are you using?

As indicated above: comparing 2.11.1 with 2.14.2

*** Please provide any additional information below.

It seems that maybe some kind of "invisible" switch is ON in R 2.14.2. However 
I am not sufficiently familiar with R to really comment on this. The "terminal" 
R being fired up could be an indication of something?

It would be good to understand whats going on to avoid confusion. Also, Mark T 
has indicated that R.exe's remaining running in Windows background could pose 
problems when RFortran tries to hook up with an R instance.

Note that no interference was observed in the runs here - the fact that R.exe 
was already in the background simply meant the application completed faster 
(and still correctly it seems).

One of the inconveniences of the invisible mode is the inability to use the R 
console when stepping-through/debugging RFortran-based code. Ie it is not 
possible to see exactly was is being sent to R, etc.

I think understanding what the heck is going on and how to control it would be 
useful.

cheers,
d

Original issue reported on code.google.com by dmitri.k...@gmail.com on 17 Mar 2012 at 1:59

GoogleCodeExporter commented 8 years ago 
D, 

I have noticed this in recent versions of RFortran+BATEA+R.
I thought somewhere in BATEA you had switch the invisibleRgui to .true.

Instead, it looks like they have changed the behaviour of R, in the more recent 
versions, since I have not changed RFortran. 
This kind of things are tricky to track down and will take sometime to 
investigate.    

Prelim testing has shown, if you manually open Rgui.exe prior to running BATEA, 
BATEA will link to the version you have opened manually, and you can see the 
console etc. 

I suggest this to be used as a workaround until this issue is fully 
investigated, most likely during semester break.

Original comment by mark.th...@gmail.com on 19 Mar 2012 at 12:07