My favorites | Sign in
Project Home Downloads Wiki Issues Source
Details: Show all Hide all

Older

  • Nov 03, 2011
    issue 103 (Rput failed in a loop) commented on by Michael....@gmail.com   -   A note for future development: Either 1. Submit bug report to StatCon and get IStatConnector_SetSymbol to evaluate expressions. 2. Replace Rput() with a fortran function that formalises the workaround above, e.g. function RputFIXED(var,val) result(ok) !... declare variables ok = RPut("temp",val) ! first dump the data in R ok = Reval(trim(var)//"=temp") ! evaluate any expression in var and assign temp to it end function
    A note for future development: Either 1. Submit bug report to StatCon and get IStatConnector_SetSymbol to evaluate expressions. 2. Replace Rput() with a fortran function that formalises the workaround above, e.g. function RputFIXED(var,val) result(ok) !... declare variables ok = RPut("temp",val) ! first dump the data in R ok = Reval(trim(var)//"=temp") ! evaluate any expression in var and assign temp to it end function
  • Nov 03, 2011
    issue 103 (Rput failed in a loop) Labels changed by Michael....@gmail.com   -   Thanks for this. The fail is not to do with the loop in Fortran. It is an issue with IStatConnector_SetSymbol which does not evaluate the string param[i] ... which would become param[1] on the first iteration but somehow manages to create a new variable called "param[i]". It assigns the value to this new variable. The setting routine takes a literal approach to the variable name. There are several workarounds for this. The key is to not use Rput to assign a value to something in R that requires evaluation, i.e. the "[i]" part. 1. Create the whole array in Fortran and tranfer it in one hit. 2. Pass the data: Rput("temp",par) and then assign it within R: Reval("param[i]=temp")
    Labels: Priority-minor Priority-Major
    Thanks for this. The fail is not to do with the loop in Fortran. It is an issue with IStatConnector_SetSymbol which does not evaluate the string param[i] ... which would become param[1] on the first iteration but somehow manages to create a new variable called "param[i]". It assigns the value to this new variable. The setting routine takes a literal approach to the variable name. There are several workarounds for this. The key is to not use Rput to assign a value to something in R that requires evaluation, i.e. the "[i]" part. 1. Create the whole array in Fortran and tranfer it in one hit. 2. Pass the data: Rput("temp",par) and then assign it within R: Reval("param[i]=temp")
    Labels: Priority-minor Priority-Major
  • Nov 03, 2011
    issue 104 (can't compile test_rfortran_cvf ) Owner changed by Michael....@gmail.com   -   I have downloaded the latest version and installed it under XP. The version of R isn't an issue as this is a straight Fortran issue. I was able to get it to compile using CVF6.6B. 1. Within CVF, can you please go to Project - Settings - Fortran and then select "Ignore Warnings" under warning level. I think you have it set to "Warnings treated as Errors" - hence it is not building for you. 2. If that does not fix it, can you please check under Help - About Developer Studio and tell me if you are also using CVF version 6.6B. It could be that 6.6A or 6.6C have issues. As a separate matter, I see you have provided a dump of the test program. Can you please check the file D:\RFortran\simple test programs\_RputRgetRevalRcall_IVF_unitTests\RputRgetRevalRcall_unitTest_resultsSummary.txt This will tell you whether the interface with R is working. All of the tests should read "PASS".
    Owner:
    I have downloaded the latest version and installed it under XP. The version of R isn't an issue as this is a straight Fortran issue. I was able to get it to compile using CVF6.6B. 1. Within CVF, can you please go to Project - Settings - Fortran and then select "Ignore Warnings" under warning level. I think you have it set to "Warnings treated as Errors" - hence it is not building for you. 2. If that does not fix it, can you please check under Help - About Developer Studio and tell me if you are also using CVF version 6.6B. It could be that 6.6A or 6.6C have issues. As a separate matter, I see you have provided a dump of the test program. Can you please check the file D:\RFortran\simple test programs\_RputRgetRevalRcall_IVF_unitTests\RputRgetRevalRcall_unitTest_resultsSummary.txt This will tell you whether the interface with R is working. All of the tests should read "PASS".
    Owner:
  • Nov 02, 2011
    issue 104 (can't compile test_rfortran_cvf ) reported by zzq...@163.com   -   *** What steps will reproduce the problem? 1.I compiled test_rfotran_cf according to the tutorial but failed. 2.Error: An array-valued argument is required in this context. [SUM] character(len = sum(real_len(r)) + size(r) +2) :: ch !< the string to be returned 3.361 error(s), 2 warning(s) *** On which Windows operating system? winxp *** What Fortran compiler (name and version number) are you using? cvf6.6 *** What version of R are you using? r2.13.1 *** Run the simple test program, "RFortran\Simple Test Programs\_RputRgetRe valRcall_IVF_unitTests\RputRgetRevalRcall_IVF_unitTests.exe" and provide a copy of the RFortran.log file (located in the same folder) Debug : All messages being written to log file (if no path - written to current executable directory): RFortran.log Debug : Using msg_db: RFORTRAN, located at D:\RFortran\settings\RFortran_MsgDB.csv Debug : Current executable directory: D:\RFortran\Simple Test Programs\_RputRgetRevalRcall_IVF_unitTests\ Debug : RFORTRAN_PATH: D:\RFortran Debug : RFortran Settings File: D:\RFortran\settings\RFortran.set Comment : RFortran is auto-opening R, and will wait 10.0000000000000 secs for R to initialise. To change wait time set wait4RDef in RFortran.set file OR set dummy argument wait4RIn when calling Rinit Debug : RGuiPath: C:\Program Files\R\R-2.13.1\bin\i386\Rgui.exe Debug : RGuiVisible: T *** If there were installer errors - please provide of the output from the installer window(s) *** If there were build errors - please provide a copy of the build output from IVF/CVF see the attachment *** If you have a coding solution to this defect please include the file (or preferably a svn patch) as an attachment *** Please provide any additional information below.
    *** What steps will reproduce the problem? 1.I compiled test_rfotran_cf according to the tutorial but failed. 2.Error: An array-valued argument is required in this context. [SUM] character(len = sum(real_len(r)) + size(r) +2) :: ch !< the string to be returned 3.361 error(s), 2 warning(s) *** On which Windows operating system? winxp *** What Fortran compiler (name and version number) are you using? cvf6.6 *** What version of R are you using? r2.13.1 *** Run the simple test program, "RFortran\Simple Test Programs\_RputRgetRe valRcall_IVF_unitTests\RputRgetRevalRcall_IVF_unitTests.exe" and provide a copy of the RFortran.log file (located in the same folder) Debug : All messages being written to log file (if no path - written to current executable directory): RFortran.log Debug : Using msg_db: RFORTRAN, located at D:\RFortran\settings\RFortran_MsgDB.csv Debug : Current executable directory: D:\RFortran\Simple Test Programs\_RputRgetRevalRcall_IVF_unitTests\ Debug : RFORTRAN_PATH: D:\RFortran Debug : RFortran Settings File: D:\RFortran\settings\RFortran.set Comment : RFortran is auto-opening R, and will wait 10.0000000000000 secs for R to initialise. To change wait time set wait4RDef in RFortran.set file OR set dummy argument wait4RIn when calling Rinit Debug : RGuiPath: C:\Program Files\R\R-2.13.1\bin\i386\Rgui.exe Debug : RGuiVisible: T *** If there were installer errors - please provide of the output from the installer window(s) *** If there were build errors - please provide a copy of the build output from IVF/CVF see the attachment *** If you have a coding solution to this defect please include the file (or preferably a svn patch) as an attachment *** Please provide any additional information below.
  • Aug 03, 2011
    issue 103 (Rput failed in a loop) reported by j...@civeng.adelaide.edu.au   -   *** What steps will reproduce the problem? 1. construct a loop 2. pass an value to the entry of an array defined in R 3. *** What is the expected output? an array contains values which are passed from fortran within each loop *** What do you see instead? 0 values *** What version of RFortran are you using? RFortran Library v3.0.0 - 14 Feb 2011 *** On which Windows operating system? Windows 7 *** What Fortran compiler (name and version number) are you using? Intel *** What version of R are you using? R version 2.12.1 *** Run the simple test program, "RFortran\Simple Test Programs\_RputRgetRe valRcall_IVF_unitTests\RputRgetRevalRcall_IVF_unitTests.exe" and provide a copy of the RFortran.log file (located in the same folder) *** If there were installer errors - please provide of the output from the installer window(s) *** If there were build errors - please provide a copy of the build output from IVF/CVF *** If you have a coding solution to this defect please include the file (or preferably a svn patch) as an attachment *** Please provide any additional information below.
    *** What steps will reproduce the problem? 1. construct a loop 2. pass an value to the entry of an array defined in R 3. *** What is the expected output? an array contains values which are passed from fortran within each loop *** What do you see instead? 0 values *** What version of RFortran are you using? RFortran Library v3.0.0 - 14 Feb 2011 *** On which Windows operating system? Windows 7 *** What Fortran compiler (name and version number) are you using? Intel *** What version of R are you using? R version 2.12.1 *** Run the simple test program, "RFortran\Simple Test Programs\_RputRgetRe valRcall_IVF_unitTests\RputRgetRevalRcall_IVF_unitTests.exe" and provide a copy of the RFortran.log file (located in the same folder) *** If there were installer errors - please provide of the output from the installer window(s) *** If there were build errors - please provide a copy of the build output from IVF/CVF *** If you have a coding solution to this defect please include the file (or preferably a svn patch) as an attachment *** Please provide any additional information below.
  • Aug 03, 2011
    r701 (Removed statconnDCOM.latest.exe from repository and updated ...) committed by mark.th...@gmail.com   -   Removed statconnDCOM.latest.exe from repository and updated RFortran_README.txt file instructions
    Removed statconnDCOM.latest.exe from repository and updated RFortran_README.txt file instructions
  • Jul 17, 2011
    issue 102 (Rename procedure 'message' in MUtilsLib, eg, to 'MUtils_writ...) reported by dmitri.k...@gmail.com   -   *** Please provide a description of the enhancement you are requesting. The name 'message' used for one of the core procedures in MUtilsLib is too vague. It also clashes unnecessarily with the local variable name 'message' which is used throughout DMSL. I really recommend this be fixed for clarity and to avoid potentially difficult-to-debug bugs due to name clashes (especially if they interact with some compiler errors). I would suggest something like 'MUtils_writeMessage', or at least 'writeMessage', or something more specific along these lines.. cheers, d
    *** Please provide a description of the enhancement you are requesting. The name 'message' used for one of the core procedures in MUtilsLib is too vague. It also clashes unnecessarily with the local variable name 'message' which is used throughout DMSL. I really recommend this be fixed for clarity and to avoid potentially difficult-to-debug bugs due to name clashes (especially if they interact with some compiler errors). I would suggest something like 'MUtils_writeMessage', or at least 'writeMessage', or something more specific along these lines.. cheers, d
  • Jul 17, 2011
    issue 101 (Replace 'initialised' with 'RFortran_isInitialised' to avoid...) reported by dmitri.k...@gmail.com   -   *** Description In RFortran r700, the name of the variable indicating the initialisation status of RFortran is too bloody vague: 'initialised' could refer to many, many things ... Please change it to something more informative, I suggest 'RFortran_isInitialised'. cheers, d
    *** Description In RFortran r700, the name of the variable indicating the initialisation status of RFortran is too bloody vague: 'initialised' could refer to many, many things ... Please change it to something more informative, I suggest 'RFortran_isInitialised'. cheers, d
  • Jul 17, 2011
    issue 96 (RFortran utility to erase (clear) variables in R) commented on by dmitri.k...@gmail.com   -   RFortran r700 adds the utility function 'RFortran_clearVars' to 'RFortran_RFuncs' designed by D for this purpose. I recommend in the next release of RFortran this function be generalized to handle scalar arguments, and be added to the core function module. This ensures it is possible to use RFortran without adding any R code into the Fortran code (Rput -> execute scripts via Rcall -> Rget -> Rclear). cheers, d
    RFortran r700 adds the utility function 'RFortran_clearVars' to 'RFortran_RFuncs' designed by D for this purpose. I recommend in the next release of RFortran this function be generalized to handle scalar arguments, and be added to the core function module. This ensures it is possible to use RFortran without adding any R code into the Fortran code (Rput -> execute scripts via Rcall -> Rget -> Rclear). cheers, d
  • Jul 17, 2011
    r700 (Callaghan 1. Added utility 'RFortran_clearVars' to 'RFortra...) committed by dmitri.k...@gmail.com   -   Callaghan 1. Added utility 'RFortran_clearVars' to 'RFortran_Rfuncs' to delete R variables (partially addressing RFortran ticket #96). Further Recommendations: a) I recommend this utility should be renamed to 'Rclear' and be added to the list of core functions at the level of Rput/Rget/Reval/Rcall. This way RFortran maximally separates the R and Fortran languages (see RFortran ticket #96). b) For generality, it should also be overloaded to support clearing a single name (in which case the 'varname' argument should be a scalar character)
    Callaghan 1. Added utility 'RFortran_clearVars' to 'RFortran_Rfuncs' to delete R variables (partially addressing RFortran ticket #96). Further Recommendations: a) I recommend this utility should be renamed to 'Rclear' and be added to the list of core functions at the level of Rput/Rget/Reval/Rcall. This way RFortran maximally separates the R and Fortran languages (see RFortran ticket #96). b) For generality, it should also be overloaded to support clearing a single name (in which case the 'varname' argument should be a scalar character)
  • Jul 17, 2011
    r699 (Callaghan 1. Added 'VTune' folders to ignore list) committed by dmitri.k...@gmail.com   -   Callaghan 1. Added 'VTune' folders to ignore list
    Callaghan 1. Added 'VTune' folders to ignore list
  • Jul 12, 2011
    issue 98 (Reval fails to execute multiple R statements within same com...) commented on by dmitri.k...@gmail.com   -   Hi Mark, In response to your earlier query: yes, it appears that R allows the delimiter ";" (which normally separates multiple statements on the same line) within some expressions (ie, outside strings). This certainly seems confusing to me, and perhaps error-prone, but thats what R seems to allow. Eg, see line 671 of RPlotLibrary in BATEA. Unless I misread something, you can see the ";" inside a single R statement. cheers, d
    Hi Mark, In response to your earlier query: yes, it appears that R allows the delimiter ";" (which normally separates multiple statements on the same line) within some expressions (ie, outside strings). This certainly seems confusing to me, and perhaps error-prone, but thats what R seems to allow. Eg, see line 671 of RPlotLibrary in BATEA. Unless I misread something, you can see the ";" inside a single R statement. cheers, d
  • Jul 01, 2011
    issue 93 (RFortran hard-crashes when an invalid filename is provided (...) Status changed by mark.th...@gmail.com   -   Implemented in r101 of MUtilslib. The branch\ver-3.0.x now links to this revision of MUtilslib and hence this issue is resolved.
    Status: Fixed
    Implemented in r101 of MUtilslib. The branch\ver-3.0.x now links to this revision of MUtilslib and hence this issue is resolved.
    Status: Fixed
  • Jul 01, 2011
    r698 (updated branches/ver-3.0.x to r101 of MUtilsLib to include D...) committed by mark.th...@gmail.com   -   updated branches/ver-3.0.x to r101 of MUtilsLib to include D's patch for handling bad log file
    updated branches/ver-3.0.x to r101 of MUtilsLib to include D's patch for handling bad log file
  • Jul 01, 2011
    r697 (Updated to r101 of MUtilslib) committed by mark.th...@gmail.com   -   Updated to r101 of MUtilslib
    Updated to r101 of MUtilslib
  • Jul 01, 2011
    r696 (Merged D's changes from branch 3.0.x to trunk. Currently unt...) committed by mark.th...@gmail.com   -   Merged D's changes from branch 3.0.x to trunk. Currently untested - I am trusting D!
    Merged D's changes from branch 3.0.x to trunk. Currently untested - I am trusting D!
  • Jul 01, 2011
    r695 (Added items to ignore list) committed by mark.th...@gmail.com   -   Added items to ignore list
    Added items to ignore list
  • Jul 01, 2011
    r694 (Added externals directory with copies of dependencies (rcom/...) committed by mark.th...@gmail.com   -   Added externals directory with copies of dependencies (rcom/rscproxy/r and statconn)
    Added externals directory with copies of dependencies (rcom/rscproxy/r and statconn)
  • Jul 01, 2011
    r693 (Minor edits to RFortran_files.F90) committed by mark.th...@gmail.com   -   Minor edits to RFortran_files.F90
    Minor edits to RFortran_files.F90
  • Jul 01, 2011
    r692 (added r scripts to ease installation. Only in development st...) committed by mark.th...@gmail.com   -   added r scripts to ease installation. Only in development stage. Need refinement
    added r scripts to ease installation. Only in development stage. Need refinement
  • Jul 01, 2011
    r691 (Updates to the RFortran_README.txt file- Still needs work Mi...) committed by mark.th...@gmail.com   -   Updates to the RFortran_README.txt file- Still needs work Minor changes to the UnitTesting
    Updates to the RFortran_README.txt file- Still needs work Minor changes to the UnitTesting
  • Jul 01, 2011
    issue 94 (Utility program to check installation of RFortran) Status changed by mark.th...@gmail.com   -   D, This already exists: See http://code.google.com/p/rfortran/wiki/GettingStarted for more information and so there is no need to develop one Mark
    Status: WontFix
    D, This already exists: See http://code.google.com/p/rfortran/wiki/GettingStarted for more information and so there is no need to develop one Mark
    Status: WontFix
  • Jun 22, 2011
    issue 100 (remove redundant TRIM()) reported by dmitri.k...@gmail.com   -   On line 171 of MUtilsLib_MessageLog.f90 (r690): if (present(file) .and. .NOT. msg_log%append) msg_log%file = TRIM(file) the TRIM() is redundant, and has no effect on the result of the operation (other than probably slowing down as it creates a string copy). The line can be shortened to: if (present(file) .and. .NOT. msg_log%append) msg_log%file = file cheers, d
    On line 171 of MUtilsLib_MessageLog.f90 (r690): if (present(file) .and. .NOT. msg_log%append) msg_log%file = TRIM(file) the TRIM() is redundant, and has no effect on the result of the operation (other than probably slowing down as it creates a string copy). The line can be shortened to: if (present(file) .and. .NOT. msg_log%append) msg_log%file = file cheers, d
  • Jun 22, 2011
    issue 87 (drastic slowdown in Rxxx between v092 and v2.1.2, 100x loss ...) commented on by dmitri.k...@gmail.com   -   Mark, Just a reminder to have a look at this. I am increasingly using RFortran within BATEA, which now supports writing models, distributions and transformation in R/Matlab. In fact soon Guillaume will be experimenting with different input error models, and it would be great if he could to that in R (to keep away from the Fortran core). However in order for this to be practical, RFortran needs to be restored to its previous speed (100 x). cheers, d
    Mark, Just a reminder to have a look at this. I am increasingly using RFortran within BATEA, which now supports writing models, distributions and transformation in R/Matlab. In fact soon Guillaume will be experimenting with different input error models, and it would be great if he could to that in R (to keep away from the Fortran core). However in order for this to be practical, RFortran needs to be restored to its previous speed (100 x). cheers, d
  • Jun 22, 2011
    issue 99 (Replace unit 6 with 'screenUnit') reported by dmitri.k...@gmail.com   -   *** Problem description Throughout the current RFortran / Mutils, there is a lot of reliance on unit 6 being the screen. However this is not guaranteed by the standard. As such it is a rather unsightly hardcoding.. I therefore recommend that 6 be replaced by the parameter 'screenUnit' from kinds_dmsl_kit. This would also be more self-documenting. *** What version of RFortran are you using? 3.0.x r690
    *** Problem description Throughout the current RFortran / Mutils, there is a lot of reliance on unit 6 being the screen. However this is not guaranteed by the standard. As such it is a rather unsightly hardcoding.. I therefore recommend that 6 be replaced by the parameter 'screenUnit' from kinds_dmsl_kit. This would also be more self-documenting. *** What version of RFortran are you using? 3.0.x r690
  • Jun 22, 2011
    issue 93 (RFortran hard-crashes when an invalid filename is provided (...) changed by dmitri.k...@gmail.com   -   Hi Mark, See attached a patch to MUTILSLIB that fixes this problem, d-style. The problem is that an error in opening a log file, well, cannot really be written to a log file .. Hence my solution is to return 'err' and 'message', like in all DMSL prox. The calling proc should then check if err==EXIT_SUCCESS, and take action accordingly. I made them optional, which means that your existing code will still compile (but will not have access to the improved functionality). NB: This patch is needed for BATEA / DMSL r419+. cheers, d
    Cc:
    Labels: Priority-critical Priority-major
    Hi Mark, See attached a patch to MUTILSLIB that fixes this problem, d-style. The problem is that an error in opening a log file, well, cannot really be written to a log file .. Hence my solution is to return 'err' and 'message', like in all DMSL prox. The calling proc should then check if err==EXIT_SUCCESS, and take action accordingly. I made them optional, which means that your existing code will still compile (but will not have access to the improved functionality). NB: This patch is needed for BATEA / DMSL r419+. cheers, d
    Cc:
    Labels: Priority-critical Priority-major
  • Jun 18, 2011
    r690 (London Paddington 1. Added Vtune folder to 'ignore' list) committed by dmitri.k...@gmail.com   -   London Paddington 1. Added Vtune folder to 'ignore' list
    London Paddington 1. Added Vtune folder to 'ignore' list
  • Jun 18, 2011
    r689 (London Paddington 1. Corrected malevolent misspelling in glo...) committed by dmitri.k...@gmail.com   -   London Paddington 1. Corrected malevolent misspelling in global vars
    London Paddington 1. Corrected malevolent misspelling in global vars
  • Jun 16, 2011
    r688 (Trier Wolfsberg 1. Enhancements to enable: a) Detection of d...) committed by dmitri.k...@gmail.com   -   Trier Wolfsberg 1. Enhancements to enable: a) Detection of dummy vs real RFortran b) Ability to execute multiple R commands within single statement in Reval (separated by ";;") See also BATEAU_DK tickets #109 and #110, and RFortran ticket #98 This revision is needed for DMSL r402+ and BATEA r209+ Changes are backwards compatible
    Trier Wolfsberg 1. Enhancements to enable: a) Detection of dummy vs real RFortran b) Ability to execute multiple R commands within single statement in Reval (separated by ";;") See also BATEAU_DK tickets #109 and #110, and RFortran ticket #98 This revision is needed for DMSL r402+ and BATEA r209+ Changes are backwards compatible
  • Jun 15, 2011
    issue 98 (Reval fails to execute multiple R statements within same com...) commented on by dmitri.k...@gmail.com   -   Hi Mark, Since some legitimate R statements use the ";" inside (rather than as a separator), I modified the code to expect ";;" as a separator. Slightly less convenient but seems to work fine. The instructions and new code are below. Also see the related BATEAU_DK ticket #109 for some further details. In the file 'RFortran_Rput_Rget_Reval_Rcall.F90', do the following (i) rename the function 'Reval' to 'Reval_eng' (ii) paste the following code after the function 'Reval_eng' !start{\DK}--------------------------------------- !---------------------------------------------------- function Reval(command,forceSingle)result(err) ! Purpose: Reval that handles multiple R statements within a single argument. ! Programmer: Dmitri Kavetski ! Kreated: 13 June 2011 AD, EMPA Accomo ! Comments: ! 1. Following R conventions, multiple statements must be separated by ";", ! However, to avoid spurious parsing, a ";;" is used. use utilities_dmsl_kit,only:quickif,parseStringIntoVector implicit none ! dummies character(*),intent(in)::command logical(mlk),intent(in),optional::forceSingle integer(mik)::err ! locals integer(mik)::n,i character(len(command)),pointer::cmdv(:) character(len_DMSLjmsg)::msg logical(mlk),parameter::forceSingleDef=.false. character(*),parameter::delim=";;" ! Start procedure here if(quickif(forceSingle,forceSingleDef))then err=Reval_eng(command) else call parseStringIntoVector(string=command,delim=delim,& array=cmdv,err=err,message=msg) if(err/=EXIT_SUCCESS)return n=size(cmdv) do i=1,n err=Reval_eng(trim(cmdv(i))) if(err/=EXIT_SUCCESS)exit enddo endif ! End procedure here endfunction Reval !end{\DK}-----------------------------------------
    Hi Mark, Since some legitimate R statements use the ";" inside (rather than as a separator), I modified the code to expect ";;" as a separator. Slightly less convenient but seems to work fine. The instructions and new code are below. Also see the related BATEAU_DK ticket #109 for some further details. In the file 'RFortran_Rput_Rget_Reval_Rcall.F90', do the following (i) rename the function 'Reval' to 'Reval_eng' (ii) paste the following code after the function 'Reval_eng' !start{\DK}--------------------------------------- !---------------------------------------------------- function Reval(command,forceSingle)result(err) ! Purpose: Reval that handles multiple R statements within a single argument. ! Programmer: Dmitri Kavetski ! Kreated: 13 June 2011 AD, EMPA Accomo ! Comments: ! 1. Following R conventions, multiple statements must be separated by ";", ! However, to avoid spurious parsing, a ";;" is used. use utilities_dmsl_kit,only:quickif,parseStringIntoVector implicit none ! dummies character(*),intent(in)::command logical(mlk),intent(in),optional::forceSingle integer(mik)::err ! locals integer(mik)::n,i character(len(command)),pointer::cmdv(:) character(len_DMSLjmsg)::msg logical(mlk),parameter::forceSingleDef=.false. character(*),parameter::delim=";;" ! Start procedure here if(quickif(forceSingle,forceSingleDef))then err=Reval_eng(command) else call parseStringIntoVector(string=command,delim=delim,& array=cmdv,err=err,message=msg) if(err/=EXIT_SUCCESS)return n=size(cmdv) do i=1,n err=Reval_eng(trim(cmdv(i))) if(err/=EXIT_SUCCESS)exit enddo endif ! End procedure here endfunction Reval !end{\DK}-----------------------------------------
  • Jun 13, 2011
    issue 94 (Utility program to check installation of RFortran) commented on by dmitri.k...@gmail.com   -   Mark, See subroutine 'checkExtCon' in DMSL module 'EXTGATE_dmsl_kit' for an implementation that tests connections to R, Matlab and a few other goodies. Perhaps you can use it as a basis for your routine, or somehow unify them. Would be good to move towards unified external connectors, rather than remember all the various peculiarities for RFortran, MATFortran, etc cheers, d
    Mark, See subroutine 'checkExtCon' in DMSL module 'EXTGATE_dmsl_kit' for an implementation that tests connections to R, Matlab and a few other goodies. Perhaps you can use it as a basis for your routine, or somehow unify them. Would be good to move towards unified external connectors, rather than remember all the various peculiarities for RFortran, MATFortran, etc cheers, d
  • Jun 13, 2011
    issue 98 (Reval fails to execute multiple R statements within same com...) commented on by dmitri.k...@gmail.com   -   See solution below. to use it, rename the old 'Reval' to 'Reval_engine' and paste the following right after. It resolves the issue in the ticket. !---------------------------------------------------- function Reval(command)result(err) ! Purpose: Reval that handles multiple R statements within a single argument. ! Programmer: Dmitri Kavetski ! Kreated: 13 June 2011 AD, EMPA Accomo ! Comments: ! 1. Following R conventions, multiple statements must be separated by ";". use utilities_dmsl_kit,only:parseStringIntoVector implicit none ! dummies character(*),intent(in)::command integer(mik)::err ! locals integer(mik)::n,i character(len(command)),pointer::cmdv(:) character(len_DMSLjmsg)::msg ! Start procedure here call parseStringIntoVector(string=command,delim=";",& array=cmdv,err=err,message=msg) n=size(cmdv) do i=1,n err=Reval_eng(trim(cmdv(i))) if(err/=EXIT_SUCCESS)exit enddo ! End procedure here endfunction Reval
    See solution below. to use it, rename the old 'Reval' to 'Reval_engine' and paste the following right after. It resolves the issue in the ticket. !---------------------------------------------------- function Reval(command)result(err) ! Purpose: Reval that handles multiple R statements within a single argument. ! Programmer: Dmitri Kavetski ! Kreated: 13 June 2011 AD, EMPA Accomo ! Comments: ! 1. Following R conventions, multiple statements must be separated by ";". use utilities_dmsl_kit,only:parseStringIntoVector implicit none ! dummies character(*),intent(in)::command integer(mik)::err ! locals integer(mik)::n,i character(len(command)),pointer::cmdv(:) character(len_DMSLjmsg)::msg ! Start procedure here call parseStringIntoVector(string=command,delim=";",& array=cmdv,err=err,message=msg) n=size(cmdv) do i=1,n err=Reval_eng(trim(cmdv(i))) if(err/=EXIT_SUCCESS)exit enddo ! End procedure here endfunction Reval
  • Jun 13, 2011
    issue 98 (Reval fails to execute multiple R statements within same com...) reported by dmitri.k...@gmail.com   -   *** What steps will reproduce the problem? Hi, It appears that Reval cannot be used to execute more than a single R command per call? Eg, the single command needed to be executed in R via RFortran is as below (note that it consists of two R statements separated by ;): cmd="a=5; b=7" This executes correctly when pasted directly into R. However, when the same command is executed via RFortran, using Reval(cmd), it does NOT work. There is no error reported by Reval (err=0), but it only executes the first statement (a=5), but not the second (b=7). I did about some debugging with no obvious leads... Can it be confirmed that Reval cant handle more than a single R statement? I think I saw some examples with multiple statements? If Rval only works for the first statement, an RFortran wrapper should be created that parses multiple R statements into a vector and loops through them, since a single R-command with several statements is a scenario needed to be supported in BATEA, etc. There is a DMSL parsing routine that can help here.. cheers, d *** What version of RFortran are you using? r628 *** On which Windows operating system? Win XP *** What Fortran compiler (name and version number) are you using? IVF 11.0 *** What version of R are you using? R 2.11.1 *** If you have a coding solution to this defect please include a svn patch as an attachment *** Please provide any additional information below.
    *** What steps will reproduce the problem? Hi, It appears that Reval cannot be used to execute more than a single R command per call? Eg, the single command needed to be executed in R via RFortran is as below (note that it consists of two R statements separated by ;): cmd="a=5; b=7" This executes correctly when pasted directly into R. However, when the same command is executed via RFortran, using Reval(cmd), it does NOT work. There is no error reported by Reval (err=0), but it only executes the first statement (a=5), but not the second (b=7). I did about some debugging with no obvious leads... Can it be confirmed that Reval cant handle more than a single R statement? I think I saw some examples with multiple statements? If Rval only works for the first statement, an RFortran wrapper should be created that parses multiple R statements into a vector and loops through them, since a single R-command with several statements is a scenario needed to be supported in BATEA, etc. There is a DMSL parsing routine that can help here.. cheers, d *** What version of RFortran are you using? r628 *** On which Windows operating system? Win XP *** What Fortran compiler (name and version number) are you using? IVF 11.0 *** What version of R are you using? R 2.11.1 *** If you have a coding solution to this defect please include a svn patch as an attachment *** Please provide any additional information below.
  • Jun 13, 2011
    issue 97 (strategy to avoid multiple RFortran-based procedures from in...) Status changed by mark.th...@gmail.com   -   Yes, I can see this is going to be a problem in the longer term. As an interim solution, I would recommend using status="new" in the Rput command, or set the RFortran global variable, statusDef = "new" This checks if an Rput command is going to overwrite an existing R variable and returns an error. At least then an error is returned if a variable is going to be overwritten. In the longer term R has a feature called an "environment", where an R variable can be defined in a an environment and does not interact with other variables in a different environment. The R scoping rules are hard to follow however - see http://cran.r-project.org/doc/contrib/Fox-Companion/appendix-scope.pdf An Rcall command could first setup its own environment, perform its calculations return the values and somehow close the environment. Something to look at in longer term
    Status: Accepted
    Yes, I can see this is going to be a problem in the longer term. As an interim solution, I would recommend using status="new" in the Rput command, or set the RFortran global variable, statusDef = "new" This checks if an Rput command is going to overwrite an existing R variable and returns an error. At least then an error is returned if a variable is going to be overwritten. In the longer term R has a feature called an "environment", where an R variable can be defined in a an environment and does not interact with other variables in a different environment. The R scoping rules are hard to follow however - see http://cran.r-project.org/doc/contrib/Fox-Companion/appendix-scope.pdf An Rcall command could first setup its own environment, perform its calculations return the values and somehow close the environment. Something to look at in longer term
    Status: Accepted
  • Jun 13, 2011
    issue 97 (strategy to avoid multiple RFortran-based procedures from in...) reported by dmitri.k...@gmail.com   -   Hi Mark, I am using RFortran increasingly for various things, and what is becoming clear is that some good general strategy is needed to handle cases where multiple routines using RFortran may be creating variables with the same name. When the whole code is developed by the same person this could be avoided to some extent (though not very naturally). However, whenever RFortran is used to create various plugins into a general framework such as BATEA, and these plugins (models, etc) are contributed by multiple people, namespace clashes become almost impossible to avoid. This may completely break to program, if procedure A inadvertently uses the same R variable name as procedure B, and can change its value, etc. This is not an easy question, and is not just an RFortran issue, but I think should be thought about, and some good strategies (and maybe code) developed and recommended. The problem is that at the moment when calling R functions via RFortran we have to create a global R variable, which could clash with many others. I had a look and Rcall doesnt really mitigate this (it just shortens the code). For example, a possible convention would be to append "_xxx" to variable names defined within procedure "xxx", and always require procedures to remove their global variables created just as arguments for R. I am not sure if this covers all situations, but worth having a careful think about. cheers, d
    Hi Mark, I am using RFortran increasingly for various things, and what is becoming clear is that some good general strategy is needed to handle cases where multiple routines using RFortran may be creating variables with the same name. When the whole code is developed by the same person this could be avoided to some extent (though not very naturally). However, whenever RFortran is used to create various plugins into a general framework such as BATEA, and these plugins (models, etc) are contributed by multiple people, namespace clashes become almost impossible to avoid. This may completely break to program, if procedure A inadvertently uses the same R variable name as procedure B, and can change its value, etc. This is not an easy question, and is not just an RFortran issue, but I think should be thought about, and some good strategies (and maybe code) developed and recommended. The problem is that at the moment when calling R functions via RFortran we have to create a global R variable, which could clash with many others. I had a look and Rcall doesnt really mitigate this (it just shortens the code). For example, a possible convention would be to append "_xxx" to variable names defined within procedure "xxx", and always require procedures to remove their global variables created just as arguments for R. I am not sure if this covers all situations, but worth having a careful think about. cheers, d
  • Jun 13, 2011
    issue 96 (RFortran utility to erase (clear) variables in R) commented on by dmitri.k...@gmail.com   -   Hi Mark, Yes, but the question is do you want to have a mixture of R and Fortran throughout the code, or try to wrap them so that the Rputs etc are kept (lagely) separate. My own preference is for the latter, especially for common tasks. d
    Hi Mark, Yes, but the question is do you want to have a mixture of R and Fortran throughout the code, or try to wrap them so that the Rputs etc are kept (lagely) separate. My own preference is for the latter, especially for common tasks. d
  • Jun 11, 2011
    issue 96 (RFortran utility to erase (clear) variables in R) commented on by mark.th...@gmail.com   -   This is good idea, However it could also be achieved without a seperate Fortran function, using a single Rcall function: Case 1: Specific vars ok=Rcall(vars=(/Rput("varname",varname)/),cmd=(/"rm(list=varname)","rm(varname)"/)) Case 2: All vars ok=Reval('rm(list=ls())') Mark
    This is good idea, However it could also be achieved without a seperate Fortran function, using a single Rcall function: Case 1: Specific vars ok=Rcall(vars=(/Rput("varname",varname)/),cmd=(/"rm(list=varname)","rm(varname)"/)) Case 2: All vars ok=Reval('rm(list=ls())') Mark
  • Jun 11, 2011
    issue 96 (RFortran utility to erase (clear) variables in R) reported by dmitri.k...@gmail.com   -   *** Please provide a description of the enhancement you are requesting. It would be very useful to have an RFortran utility to erase variables from R. For example, when cleaning up the name space. This is especially needed when several Fortran subroutines may create several R variables with the same name. In this case, as well as in general, a routine must cleanup after itself, otherwise things can get v messy. The code below illustrates the DMSL routine. However it should really migrate somewhere into RFortran. *** If you have a coding solution to this enhancement please include the file (or preferably a svn patch) as an attachment !---------------------------------------------------- subroutine rfortranClearVars(varname,err,message) ! Purpose: Removes variables named 'varname' from the R environment. ! --- ! Programmer: Dmitri Kavetski ! Kreated: 12 June 2011 AD, EMPA Accomo ! --- ! Performance ! IN: ! OUT: ! Comments: use utilities_dmsl_kit,only:quickConcat use rfortran,only:Reval implicit none ! dummies character(*),intent(in),optional::varname(:) integer(mik),intent(out)::err character(*),intent(out)::message ! locals character(*),parameter::procnam="rfortranClearVars" character(len_DMSLpath)::rmList ! Start procedure here if(present(varname))then rmList=quickConcat(string=varname,sep=",",trimString=.true.,innerOnly=.true.) err=Reval("rm("//trim(rmList)//")") else err=Reval("rm(list=ls())") endif if(err/=0)then message="f-"//procnam//"/extError[Reval/cmd]/checkRFortranlog" err=100; return endif ! End procedure here endsubroutine rfortranClearVars !----------------------------------------------------
    *** Please provide a description of the enhancement you are requesting. It would be very useful to have an RFortran utility to erase variables from R. For example, when cleaning up the name space. This is especially needed when several Fortran subroutines may create several R variables with the same name. In this case, as well as in general, a routine must cleanup after itself, otherwise things can get v messy. The code below illustrates the DMSL routine. However it should really migrate somewhere into RFortran. *** If you have a coding solution to this enhancement please include the file (or preferably a svn patch) as an attachment !---------------------------------------------------- subroutine rfortranClearVars(varname,err,message) ! Purpose: Removes variables named 'varname' from the R environment. ! --- ! Programmer: Dmitri Kavetski ! Kreated: 12 June 2011 AD, EMPA Accomo ! --- ! Performance ! IN: ! OUT: ! Comments: use utilities_dmsl_kit,only:quickConcat use rfortran,only:Reval implicit none ! dummies character(*),intent(in),optional::varname(:) integer(mik),intent(out)::err character(*),intent(out)::message ! locals character(*),parameter::procnam="rfortranClearVars" character(len_DMSLpath)::rmList ! Start procedure here if(present(varname))then rmList=quickConcat(string=varname,sep=",",trimString=.true.,innerOnly=.true.) err=Reval("rm("//trim(rmList)//")") else err=Reval("rm(list=ls())") endif if(err/=0)then message="f-"//procnam//"/extError[Reval/cmd]/checkRFortranlog" err=100; return endif ! End procedure here endsubroutine rfortranClearVars !----------------------------------------------------
  • Jun 08, 2011
    issue 95 (Add 'RFortran_enabled' global variable to RFortran) reported by dmitri.k...@gmail.com   -   *** Please provide a description of the enhancement you are requesting. For developers with multiple configurations of plugins (such as RFortran) within a software (eg, BATEA), it is often needed to figure out what is enabled and what is not. For example, if the software was built with RFortran or with a dummy. Therefore, can you please add the following parameter to the RFortran_globalvars module, somewhere right after the version name is defined: logical(mlk),parameter::RFortran_enabled=.true. For the dummy RFortran, the following value should be set logical(mlk),parameter::RFortran_enabled=.false. This allows easily determining with a simple IF statement whether the real or dummy RFortran has been linked to any application, and take action accordingly. In DMSL, I am adopting the same approach with MATFortran_enabled, etc. Would be good to standardize this across the various libraries.
    *** Please provide a description of the enhancement you are requesting. For developers with multiple configurations of plugins (such as RFortran) within a software (eg, BATEA), it is often needed to figure out what is enabled and what is not. For example, if the software was built with RFortran or with a dummy. Therefore, can you please add the following parameter to the RFortran_globalvars module, somewhere right after the version name is defined: logical(mlk),parameter::RFortran_enabled=.true. For the dummy RFortran, the following value should be set logical(mlk),parameter::RFortran_enabled=.false. This allows easily determining with a simple IF statement whether the real or dummy RFortran has been linked to any application, and take action accordingly. In DMSL, I am adopting the same approach with MATFortran_enabled, etc. Would be good to standardize this across the various libraries.
  • Jun 07, 2011
    issue 94 (Utility program to check installation of RFortran) changed by mark.th...@gmail.com   -   This utility is already under development and will be included in the next release of RFortran v3.1
    Status: Started
    Labels: Milestone-Release3.1
    This utility is already under development and will be included in the next release of RFortran v3.1
    Status: Started
    Labels: Milestone-Release3.1
  • Jun 07, 2011
    issue 94 (Utility program to check installation of RFortran) reported by dmitri.k...@gmail.com   -   *** Please provide a description of the enhancement you are requesting. Since the installation and configuration of RFortran requires several steps, including those requiring administrator priviliges, it is not always easy to attribute run problems to code problems or installation problems, especially with new operating systems, compiler versions, etc, I recommend that a utility EXE file be provided that does some basic RFortran operations (init, and maybe send/receive some values) and reports success/failure. Since this file is compiled, there is no chance for user compilation/usage error etc, and hence it can be used as a check of the installation. *** If you have a coding solution to this enhancement please include the file (or preferably a svn patch) as an attachment
    *** Please provide a description of the enhancement you are requesting. Since the installation and configuration of RFortran requires several steps, including those requiring administrator priviliges, it is not always easy to attribute run problems to code problems or installation problems, especially with new operating systems, compiler versions, etc, I recommend that a utility EXE file be provided that does some basic RFortran operations (init, and maybe send/receive some values) and reports success/failure. Since this file is compiled, there is no chance for user compilation/usage error etc, and hence it can be used as a check of the installation. *** If you have a coding solution to this enhancement please include the file (or preferably a svn patch) as an attachment
  • Jun 05, 2011
    issue 93 (RFortran hard-crashes when an invalid filename is provided (...) commented on by mark.th...@gmail.com   -   Michael, Any chance you could take a look at what's causing this? It may be in Mutilslibs I'm a bit swamped this week. Mark
    Michael, Any chance you could take a look at what's causing this? It may be in Mutilslibs I'm a bit swamped this week. Mark
  • Jun 01, 2011
    issue 93 (RFortran hard-crashes when an invalid filename is provided (...) reported by dmitri.k...@gmail.com   -   *** What steps will reproduce the problem? Attempt to run RFortran with a log file name that contains special characters such as &, *, etc *** What is the expected output? As this usage is not allowed, an error message from RFortran is expected. *** What do you see instead? Hard crash somewhere in the log utilities procedures (on the OPEN statement). *** What version of RFortran are you using? revision 628 *** If you have a coding solution to this defect please include the file (or preferably a svn patch) as an attachment Proposed solution: The OPEN statements in RFortran need to be supplemented with IOSTAT checking, and appropriate error handling. Otherwise RFortran crashes, which can be difficult to debug especially to a general user. This needs to be done throughout, reporting any errors in a consistent way. cheers, d
    *** What steps will reproduce the problem? Attempt to run RFortran with a log file name that contains special characters such as &, *, etc *** What is the expected output? As this usage is not allowed, an error message from RFortran is expected. *** What do you see instead? Hard crash somewhere in the log utilities procedures (on the OPEN statement). *** What version of RFortran are you using? revision 628 *** If you have a coding solution to this defect please include the file (or preferably a svn patch) as an attachment Proposed solution: The OPEN statements in RFortran need to be supplemented with IOSTAT checking, and appropriate error handling. Otherwise RFortran crashes, which can be difficult to debug especially to a general user. This needs to be done throughout, reporting any errors in a consistent way. cheers, d
  • Mar 07, 2011
    r687 (minor update to comment) committed by gongjin...@gmail.com   -   minor update to comment
    minor update to comment
  • Mar 07, 2011
    r687 (minor update to comment) committed by gongjin...@gmail.com   -   minor update to comment
    minor update to comment
  • Mar 06, 2011
    issue 92 (Stand-alone installer for RFortran) commented on by mark.th...@gmail.com   -   To-do: Change installer options: (a) Selecting source code, only installs source code (b) All system setting/modifications (e.g. installing COM server, RFORTRAN_PATH etc) are undertaken by single option in the installer - this will also enable non-source users (e.g. BATEA) users to install RCOM connection without having to install RFortran Note: in NSIS the /x switch in the FILES command exclude certain files For this options need to install a subset of
    To-do: Change installer options: (a) Selecting source code, only installs source code (b) All system setting/modifications (e.g. installing COM server, RFORTRAN_PATH etc) are undertaken by single option in the installer - this will also enable non-source users (e.g. BATEA) users to install RCOM connection without having to install RFortran Note: in NSIS the /x switch in the FILES command exclude certain files For this options need to install a subset of
  • Mar 06, 2011
    issue 92 (Stand-alone installer for RFortran) commented on by mark.th...@gmail.com   -   To-do: Change installer options: (a) Selecting source code, only installs source code (b) All system setting/modifications (e.g. installing COM server, RFORTRAN_PATH etc) are undertaken by single option in the installer - this will also enable non-source users (e.g. BATEA) users to install RCOM connection without having to install RFortran Note: in NSIS the /x switch in the FILES command exclude certain files For this options need to install a subset of
    To-do: Change installer options: (a) Selecting source code, only installs source code (b) All system setting/modifications (e.g. installing COM server, RFORTRAN_PATH etc) are undertaken by single option in the installer - this will also enable non-source users (e.g. BATEA) users to install RCOM connection without having to install RFortran Note: in NSIS the /x switch in the FILES command exclude certain files For this options need to install a subset of
  • Mar 06, 2011
    issue 92 (Stand-alone installer for RFortran) reported by mark.th...@gmail.com   -   *** Please provide a description of the enhancement you are requesting. Stand-alone (internet independent) version of the RFortran installer suitable for installations at workshops etc.
    *** Please provide a description of the enhancement you are requesting. Stand-alone (internet independent) version of the RFortran installer suitable for installations at workshops etc.
  • Mar 06, 2011
    issue 92 (Stand-alone installer for RFortran) reported by mark.th...@gmail.com   -   *** Please provide a description of the enhancement you are requesting. Stand-alone (internet independent) version of the RFortran installer suitable for installations at workshops etc.
    *** Please provide a description of the enhancement you are requesting. Stand-alone (internet independent) version of the RFortran installer suitable for installations at workshops etc.
  • Mar 04, 2011
    r686 (Minor fixes/Updates to RputRgetRevalRcall_unittestPlatform f...) committed by mark.th...@gmail.com   -   Minor fixes/Updates to RputRgetRevalRcall_unittestPlatform files
    Minor fixes/Updates to RputRgetRevalRcall_unittestPlatform files
 
Powered by Google Project Hosting