search

hodgesse1 / rfortran

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

Direct programmatic modificaton of paths in RFortran #47

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
*** Please provide a description of the enhancement you are requesting.

Ability to programatically set the paths to R and RFortran without using
settings files and without modifying the call to Rinit, etc.

Provides extra flexibility, with immediate simplifications of code
development within BATEA/DMSL contexts.

This essentially requires access to the paths stored in a module and may
require slightly closer integration with DMSL (including another module,
eg, filepaths, into miniDMSL). See current implementation by D.

Original issue reported on code.google.com by dmitri.k...@gmail.com on 14 Sep 2009 at 1:27

Attachments:

GoogleCodeExporter commented 8 years ago 
D,

I did a diff on the RFortran_Rinit_RClose.f90 and the only changes I could see 
were to the calls 
to COMINITIALIZE and COMUNINTIALISE, both are now make use of the openedCOM 
logical, stored in 
filepaths_dmsl_kit.f90. This logical needs to be in miniDMSL so that non-DMSL 
users have access to 
it. 

The paths to R and RFortran are stored in RFortran_GlobalPaths.f90, hence 
BATEA/DMSL can simply 
modify the values in RFortran_GlobalPaths.f90, RFortran_path and RGuiPathDef - 
but then Rinit 
would need to have an extra argument so that is automatically uses these 
defaults - instead of the 
settings file.  

This ability to set them programmatically, would best be in addition to current 
capabilities -  
setting them via settings files and modifying the call to Rinit - since this 
capability is 
required for other nonBATEA/DMSL users of RFortran.  

But before further discussions on possible solutions - I need to better 
understand the advantages 
of setting these programmatically, as it is not immediately clear to me of the 
code 
simplifications, since in general Rinit is only needed to be called once by the 
users application.   
But this may not be the case in anymore due to these COM channel issues.

Probably - this discussion is best done in person. I'll talk to you this week 
at Uni about it D.

Cheers,
Mark

Original comment by mark.th...@gmail.com on 19 Oct 2009 at 10:44

GoogleCodeExporter commented 8 years ago 
D,

Please elaborate on what you require here.

Mark

Original comment by mark.th...@gmail.com on 4 Mar 2010 at 3:19

GoogleCodeExporter commented 8 years ago 
This issue was closed by revision r477.

Original comment by mark.th...@gmail.com on 5 Mar 2010 at 5:41