search

hodgesse1 / rfortran

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

RFortran patches for DMSL #53

Closed GoogleCodeExporter closed 8 years ago

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

The current release of RFortran (1.0.0) is not compatible with DMSL 5.04.000.

I attach 3 patches necessary for RFortran to achieve this compatibility

1) Enhanced handling of COM channels in Rinit an Rclose
2) Link to the new DMSL module intercom (formerly filepaths)
3) Minor change to messageLog

Please include these patches - or equivalent functionality - in the next
release of RFortran.

d

Original issue reported on code.google.com by dmitri.k...@gmail.com on 18 Oct 2009 at 11:44

GoogleCodeExporter commented 8 years ago 
D,

There are no patches attached to this issue. Please provide these patches to 
implement 
these changes.

Cheers,
Mark

Original comment by mark.th...@gmail.com on 19 Oct 2009 at 9:48

GoogleCodeExporter commented 8 years ago 
Test upload of attached file

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

Attachments:

GoogleCodeExporter commented 8 years ago 
Upload of D's changes by Mark

Original comment by mark.th...@gmail.com on 19 Oct 2009 at 11:25

Attachments:

GoogleCodeExporter commented 8 years ago 
M,

Indeed the fix for the multi-COM issue is relatively simple. Nonetheless it 
needs a
bit of extra thought and the current patch is not the perfect solution, even 
though
it does overcome a major issue.

My current experience (subsequent to the patch) suggests that it may actually be
necessary to call Rinit internally by RFortran routines if they happen to fail
because the COM channel may have already been closed by somebody else (the flag 
is
helpful but not 100% guarantee because some programs may close COM internally). 
Given
this it could be worth separating the Ropen from the COM-open stuff - and you 
will
see in xsystem that now I have generic COM-open/close wrappers. This somewhat 
affects
the general way RFortran (and other auxiliary progs) operates, but should be ok.

In these circumstances setting the path programatically is the cleanest way to 
have
things working - otherwise every call to RFortran functions will require extra 
args etc.

You can grab the intercom file from DMSL_SRC.

Original comment by dmitri.k...@gmail.com on 19 Oct 2009 at 11:43

Attachments:

GoogleCodeExporter commented 8 years ago 
D,

Hmmmm-this is challenging and the documentation on COMINITIALISE is quite 
limited. 

Is it safe to say there are two issues

(1) When Rinit is called and then another COM-user (e.g MATFORTRAN) 
inadvertently 
closes the COM channel and then a RFortran function fails because the COM 
channel is 
closed.

(2) Another COM-user (e.g MATFORTRAN) has already open the COM channel and 
Rinit is 
called then this produces an error because Rinit is trying to inititialise a 
COM 
channel that is already open. 

For (1) I don't see how this patch would fix things as it would require that 
Rinit is 
called before every RFortran function call, to check whether the COM channel is 
initialised. There is a check_initialised function in Fortran which is invoked 
everytime a RFortran function is called. This may have to be enhance to check 
whether 
the COM channel is open or not. 

For (2) - it seems there may be a return value for COMINITIALISE when a COM 
library 
is already initialised on a thread. See:

http://www.canaimasoft.com/f90vb/OnlineManuals/Reference/TH_94.htm

Could this be used instead of the triedCom/openedCOM flags in RFortran - i.e. 
RFortran could call COMINTIALISE and if the return value is S_OK or S_FALSE 
that it 
does not report an error, and continues. This would need to be tested of course.

Cheers,
Mark

Original comment by mark.th...@gmail.com on 19 Oct 2009 at 12:09

GoogleCodeExporter commented 8 years ago 
Yes, those are the issues.

Indeed the patch only works if other applications such as MATFortran are 
cooperative
and handle the COM channel transparently. MATFortran does, but CAV and IAV do 
not.
For these guys I made wrappers that modify openedCOM, so that the patch (and the
openedCOM logic) works.

Sigmaplot does not behave very nicely on the COM channel, and so far I havent 
got a
clean way of handling it.

The explicit query to the COM channel is of course ideal but I wasnt aware of 
it.
Certainly the documentation for COMinitialise is crap. There really just needs 
to be
a isCOMopen-type inquiry function.

Therefore in MATFortran I actually try to open the COM when a command fails when
openedCOM is true. I should probably also do the reverse and try to ignore a 
failure
to open COM because it may already be open.

A bit messy for sure.

Original comment by dmitri.k...@gmail.com on 19 Oct 2009 at 12:25

GoogleCodeExporter commented 8 years ago 
Included in v2.0.0 release

Original comment by mark.th...@gmail.com on 19 Feb 2010 at 5:21

GoogleCodeExporter commented 8 years ago

Original comment by mark.th...@gmail.com on 16 Apr 2010 at 6:07