Mixed language programming Tcl/Tk and Fortran (Windows)
Gustav Ivanovic
programming using tcl/tk and fortran.
I have been working for sometime in an engineering dept in a big
company. Recently the IT policy of the company has changed and we have
now Windows XP without any administrator privilege therefore we do not
have anymore the possibility to install any GUI programming tool like
visual basic.
By chance, I stumbled on comp.lang.tcl and found that tcl and tk is
the solution to our difficulty to develop GUI without having
administrator privilege on our XP work station.
Until now our programs run on Unix servers and the GUI is built on PC
using MS visual basic. We are used to have our fortran program
input/output as files. input and output files are sent or fetched from
Unix computers using ftp or rcp. The programs on Unix servers are
triggered by rexec or rsh. Briefly, all communication between Unix and
XP is done via files (instead of sockets) to keep the architecture
simple.
We have now very fast PC and we started to migrate our fortran apps to
PC using Compaq Visual Fortran 6 compiler (CVF is the only development
tool officially "approved" by our bloody IT dept.). All fortran
programs run OK in this PC environment, now the problem is to build
the GUI because we have lost the possibility to write in VB.
Since all communication with our fortran programs is done by file, the
port to PC is quite straight forward. The last experiment we have done
is to build DLLs for our fortran and to plug it into GUI built in Tcl
and Tk with the help of ffidl. Tclkit allows us to work without any
installation whatsoever on our XP computers.
We have now left the old Unix server and work almost exclusively on
our XP workstation. Only the basic engineering database remains on
Unix servers (a kind of vault).
I put some examples here after to give an illustration of how we
transfer information from Tcl/Tk GUI to fortran dll. The only transfer
from fortran to Tcl/Tk we managed to do is by return of integer or
real function (see snippets).
FORTRAN PART (Compaq Visual Fortran)
=========================================
module tcl
contains
integer function integervar(n)
!DEC$ ATTRIBUTES DLLEXPORT, ALIAS: 'integervar', STDCALL
::integervar
integervar = n * n
end function integervar
real function realvar(x)
!DEC$ ATTRIBUTES DLLEXPORT, ALIAS: 'realvar', STDCALL ::realvar
realvar = x * x
end function realvar
subroutine stringvar(length,line)
!DEC$ ATTRIBUTES DLLEXPORT, ALIAS: 'stringvar', STDCALL
::stringvar
!DEC$ ATTRIBUTES REFERENCE ::line
character(len=length) :: line
integer ::length,fileunit
fileunit=1
open(fileunit,file=line)
write(fileunit,'(A)') line
close(fileunit)
end subroutine stringvar
end module tcl
END OF FORTRAN
TCL/TK script (with ffidl05.dll)
=========================================
load ../ffidl05
ffidl::callout RunFortranint {int} int [ffidl::symbol testcvf.dll
integervar]
ffidl::callout RunFortranstr {int pointer-utf8} int [ffidl::symbol
testcvf.dll stringvar]
ffidl::callout RunFortranfloat {float} float [ffidl::symbol
testcvf.dll realvar]
set buffer ABCDE
puts $buffer
puts [RunFortranint 12]
puts [RunFortranstr [string length $buffer] $buffer]
puts [RunFortranfloat 2.5]
END OF TCL/TK script
Interesting links:
Brooks Moses
> I would like to share my first experience of mixed language
> programming using tcl/tk and fortran.
Thanks! I've saved a copy of your post for future reference, if I need
to do something like this in the future.
- Brooks
--
Remove "-usenet" from my address to reply; the bmoses-usenet address
is currently disabled due to an overload of W32.Gibe-F worm emails.
Michael Schlenker
> I put some examples here after to give an illustration of how we
> transfer information from Tcl/Tk GUI to fortran dll. The only transfer
> from fortran to Tcl/Tk we managed to do is by return of integer or
> real function (see snippets).
>
Maybe this helps for other types, putting fortran and Tcl together:
http://wiki.tcl.tk/3359
Michael
Gustav Ivanovic
When you use tclkit, there is nothing to install just copy the .exe
file and there you go !
We tried first to make GUI with Compaq Visual Fortran, but discovered
that it was a pain. Tcl/Tk is much easier. The fact that we have built
many korn shell scripts (ksh) on Unix helps us a lot to understand
tclsh and wish (Tcl/Tk).
The features offered by Tcl/Tk are quite interesting. I started only
four months ago and I am fully satisfied by this incredible scripting
language. For instance, I was quite amazed by ffidl plugin that allows
me to call fortran DLLs from a tcl script (YES, it is a SCRIPT).
lin...@pbm.com (Greg Lindahl) wrote in message news:<3f6f5e15$1...@news.meer.net>...
[...]
> If the languages you used before were Basic and
> Fortran, it might be cheaper to use a Fortran GUI tool than a Tcl/TK GUI
> tool.
>
> -- greg
Arjen Markus
>
> I would like to share my first experience of mixed language
> programming using tcl/tk and fortran.
>
> We have now left the old Unix server and work almost exclusively on
> our XP workstation. Only the basic engineering database remains on
> Unix servers (a kind of vault).
>
> I put some examples here after to give an illustration of how we
> transfer information from Tcl/Tk GUI to fortran dll. The only transfer
> from fortran to Tcl/Tk we managed to do is by return of integer or
> real function (see snippets).
>
Nice work.
You may be interested in some of my experiments (see
<http://wiki.tcl.tk/2?fortran
for instance). I have built (based on work by others :) libraries to
call
Fortran routines from Tcl and vice versa. (The main problem: make time
to consolidate this stuff :()
Regards,
Arjen
Brian Elmegaard
> By chance, I stumbled on comp.lang.tcl and found that tcl and tk is
> the solution to our difficulty to develop GUI without having
> administrator privilege on our XP work station.
I did a survey on this some time ago. I found that tcl with its
limited number of variable types (1) didn't feel right. But, many
different (portable scripting) languages, e.g., perl, python (my
favourite), ruby, scheme, have been extended to use tk as one possible
GUI toolkit.
The intention with this post is mainly to let you know that there are
many languages available that can be used for your task. (Not that I
am that experienced in GUI programming)
I found GUI toolkits: What are your options? (Cameron Laird and
Kathryn Soraiz) and Choosing a Scripting Language (Sunworld Online)
very interesting to read, but as fas as I can see they are available
Sunworld anymore :-(
Perhaps doing as Cameron here writes may be the solution:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=utf-8&safe=off&threadm=wk1ygbrlh6.fsf%40mail.afm.dtu.dk&rnum=1&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3Dutf-8%26safe%3Doff%26q%3Dcameron%2Blaird%2Bauthor%253Aelmegaard%26btnG%3DGoogle%2BSearch
Interesting link:
http://www.itworld.com/AppDev/4061/swol-0202-regex/
But, tk is not that windows-native-like. For python the wxwindows GUI
toolkit is available as wxpython for making portable applications.
http://www.wxpython.org/
tk in different languages:
http://www.python.org/topics/tkinter/
http://httpd.chello.nl/k.vangelder/ruby/learntk/
http://www.perltk.org/
http://kaolin.unice.fr/STk/
And the reason for choosing python for is the readability of the
language:
x=1
print x
for n in 1,2,'foo',2.0:
print x
It's OO and lots of other fancy stuff, by coming from fortran I found
it much more easy to learn, than tcl, perl,...
Dlls are easily made and read with different compilers. My experience
is with Salford.
An example from Salford:
subroutine increment(i)
integer i
i = i + 1
end
is made into a dll.
and called from python:
from ctypes import *
# load dll
inc = windll.LoadLibrary("t.dll")
# Initiate c-variable for the dll
n=c_int(1)
# Call the dll one
inc.INCREMENT(byref(n))
print "The integer is now: %d" % n.value
# And a few times more:
for i in range(5):
inc.INCREMENT(byref(n))
print "The square of the integer is now: %d" % n.value**2
which outputs:
The integer is now: 2
The square of the integer is now: 9
The square of the integer is now: 16
The square of the integer is now: 25
The square of the integer is now: 36
The square of the integer is now: 49
Best regards,
--
Brian (remove the sport for mail)
http://www.et.dtu.dk/staff/be
Cameron Laird
Brian Elmegaard <br...@rk-speed-rugby.dk> wrote:
.
.
.
>I found GUI toolkits: What are your options? (Cameron Laird and
>Kathryn Soraiz) and Choosing a Scripting Language (Sunworld Online)
>very interesting to read, but as fas as I can see they are available
>Sunworld anymore :-(
>Perhaps doing as Cameron here writes may be the solution:
>http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=utf-8&safe=off&threadm=wk1ygbrlh6.fsf%40mail.afm.dtu.dk&rnum=1&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3Dutf-8%26safe%3Doff%26q%3Dcameron%2Blaird%2Bauthor%253Aelmegaard%26btnG%3DGoogle%2BSearch
>
>Interesting link:
>http://www.itworld.com/AppDev/4061/swol-0202-regex/
.
.
While SunWorld Online is defunct, I'm slowly making progress
in providing permanent URLs for all the content we published
there. <URL: http://regularexpressions.com/ > points to these
results. PLEASE let me know if there's a particular piece
you're searching; with a little motivation, I often can find
a version that I can make public.
--
Cameron Laird <Cam...@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://phaseit.net/claird/home.html
Gustav Ivanovic
it gave me an idea: instead of using pipes, files can be used. I think
it will be extremely easy to pass values from tcl to fortran and vice
versa using ffidl and files. It won't be efficient of course, but the
whole system will be easily maintainable.
The basic assumptions are:
1. Tcl/Tk part will be only for GUIs and launching scripts
2. the number crunching part will be done by fortran DLLs.
Therefore a relatively slow transfer using files is negligible
compared to time the HUMAN uses to enter the necessary data and the
number crunching time in fortran.
When I will have finished to write examples based on this idea I'll
post the outcome here.
Arjen Markus <arjen....@wldelft.nl> wrote in message news:<3F714D39...@wldelft.nl>...
Chang Li
"Gustav Ivanovic" <gustav_...@yahoo.com> wrote in message
news:c4855309.03092...@posting.google.com...
> The basic assumptions are:
> 1. Tcl/Tk part will be only for GUIs and launching scripts
> 2. the number crunching part will be done by fortran DLLs.
>
Is it good to run two processes: one for GUI and another for Fortran
computing?
> Therefore a relatively slow transfer using files is negligible
> compared to time the HUMAN uses to enter the necessary data and the
> number crunching time in fortran.
>
Chang
Arjen Markus
I have experimented with that set-up myself: no problem.
In general: a GUI will not send too much stuff to a computational
component,
but perhaps the results are huge (for graphical presentation). In that
case,
use binary files.
The big issue is that some Fortran compilers do not do support flushing
the
output files. That has been the major problem that I have encountered.
But if you use two different processes, you have a very loose connection
between two entirely different pieces of your system, so independent
development and maintenance is much easier.
Regards,
Arjen
Greg Chien
> I have experimented with that set-up myself: no problem.
> In general: a GUI will not send too much stuff to a
> computational component, but perhaps the results are huge
> (for graphical presentation). In that case, use binary files.
As long as the GUI refrains from controlling the computational component
while the latter is running. However, with the increase of computing
power (and sometimes being influenced by interactive games), the users
tend to expect faster turn-around and, ultimately, interactive control of
the computation processes.
> The big issue is that some Fortran compilers do not do support
> flushing the output files. That has been the major problem that
> I have encountered.
<Sarcasm>
Perhaps, Giles can teach you how to solve the problem, or design the
system correctly. ;-)
</Sarcasm>
> But if you use two different processes, you have a very loose
> connection between two entirely different pieces of your system,
> so independent development and maintenance is much easier.
Loosely coupled, I agree. Easier? Well, you will need to work alone or
have a highly disciplined team in order to synchronize the changes between
the two. I've seen too often that when the GUI is done, it is obsolescent
due to underlying requirement changes/enhancements in the computational
module. The other problem is code duplication in Fortran routines and GUI
component built in different languages/tools. Both of them need "read and
validate" routines to fetch input data and guard against errors and the
functions are generally overlapped. If the GUI and the computation
routines are developed in the same language system, or with a well
thought-out scheme (hint, hint :-) the input data have already been in the
memory before the Fortran DLLs are called. The "read and validate"
routines will be in only one place, which is much easier to develop and
maintain.
--
Best Regards,
Greg Chien
e-mail: remove n.o.S.p.a.m.
http://protodesign-inc.com
Chang Li
"Greg Chien" <gch...@n.o.S.p.a.m.protodesign-inc.com> wrote in message
news:X2Ycb.588719$o%2.269607@sccrnsc02...
> "Arjen Markus" wrote
> > I have experimented with that set-up myself: no problem.
> > In general: a GUI will not send too much stuff to a
> > computational component, but perhaps the results are huge
> > (for graphical presentation). In that case, use binary files.
Our MMF (Memmory Mapping File) package on Windows may help. Look at
http://www.neatware.com/myrmecox/studio/ex_mmf.html
Two processes can share a common data in memory.
When there are only one writer and multiple readers
the synchronization will be easier.
>
> > But if you use two different processes, you have a very loose
> > connection between two entirely different pieces of your system,
> > so independent development and maintenance is much easier.
>
> Loosely coupled, I agree. Easier? Well, you will need to work alone or
> have a highly disciplined team in order to synchronize the changes between
> the two. I've seen too often that when the GUI is done, it is obsolescent
> due to underlying requirement changes/enhancements in the computational
> module.
The shared data must be defined to follow a common protocol.
>The other problem is code duplication in Fortran routines and GUI
> component built in different languages/tools. Both of them need "read and
> validate" routines to fetch input data and guard against errors and the
> functions are generally overlapped. If the GUI and the computation
> routines are developed in the same language system, or with a well
> thought-out scheme (hint, hint :-) the input data have already been in the
> memory before the Fortran DLLs are called. The "read and validate"
> routines will be in only one place, which is much easier to develop and
> maintain.
Guess MMF can help solve this problem. It worked on shared memory.
The read and validate routines may still needed but in a public Tcl library.
Tcl is the wrap on both processes.
Chang
Greg Chien
> "Greg Chien" wrote
> > I've seen too often that when the GUI is done, it is obsolescent
> > due to underlying requirement changes/enhancements in the
> > computational module.
>
> The shared data must be defined to follow a common protocol.
Common protocol is certainly needed. However, it's easier said than done
and people tend to trivialize it. For example, a new version may have a
double precision floating point field that is changed from an integer in
an earlier version; an array is needed and was a scalar before; three more
fields have to be added and one should be deleted, etc. A good version
evolution/control mechanism in GUI and computational components and
between them is needed.
> > If the GUI and the computation routines are developed in
> > the same language system, or with a well thought-out
> > scheme (hint, hint :-) the input data have already been in
> > the memory before the Fortran DLLs are called.
>
> Guess MMF can help solve this problem. It worked on shared
> memory. The read and validate routines may still needed but
> in a public Tcl library. Tcl is the wrap on both processes.
I think I should have said that the input data have already been in the
memory, *parsed*, *validated*, and *ready-to-use* before the Fortran DLLs
are called. Using a file, whether it is disc or memory based, still
requires the computational component to do all the chores in a different
language. To ask simply, can one use Tcl to write Fortran user defined
types into the memory-mapped files so that the computational routines can
use them "as is" (and vice versa)? I found the C-interop in F2k3 a very
encouraging standard to solve this problem. Do you have Tcl/Fortran
interop in this level and quality? Perhaps, one will be forced to do
Tcl/C/Fortran mixed in the future (in the context of directly using the
memory, not external files)?
Chang Li
> "Chang Li" wrote
> > "Greg Chien" wrote
> > > I've seen too often that when the GUI is done, it is obsolescent
> > > due to underlying requirement changes/enhancements in the
> > > computational module.
> >
> > The shared data must be defined to follow a common protocol.
>
> Common protocol is certainly needed. However, it's easier said than done
> and people tend to trivialize it. For example, a new version may have a
> double precision floating point field that is changed from an integer in
> an earlier version; an array is needed and was a scalar before; three more
> fields have to be added and one should be deleted, etc. A good version
> evolution/control mechanism in GUI and computational components and
> between them is needed.
That is the design problem. When output format of program is not fixed the
GUI program has to changed in any cases.
>
> > > If the GUI and the computation routines are developed in
> > > the same language system, or with a well thought-out
> > > scheme (hint, hint :-) the input data have already been in
> > > the memory before the Fortran DLLs are called.
> >
> > Guess MMF can help solve this problem. It worked on shared
> > memory. The read and validate routines may still needed but
> > in a public Tcl library. Tcl is the wrap on both processes.
>
> I think I should have said that the input data have already been in the
> memory, *parsed*, *validated*, and *ready-to-use* before the Fortran DLLs
> are called. Using a file, whether it is disc or memory based, still
> requires the computational component to do all the chores in a different
> language. To ask simply, can one use Tcl to write Fortran user defined
> types into the memory-mapped files so that the computational routines can
> use them "as is" (and vice versa)? I found the C-interop in F2k3 a very
> encouraging standard to solve this problem. Do you have Tcl/Fortran
> interop in this level and quality? Perhaps, one will be forced to do
> Tcl/C/Fortran mixed in the future (in the context of directly using the
> memory, not external files)?
>
The idea is to use shared memory rather than file or pipe for process
communication. Fortran process can write the data to that shared
memory, Tcl GUI process can read the data and present it. The shared
memory is used as normal array. Do not know if Fortran support MMF.
But C can do that. So (Fortran + C) process and Tcl process can
share a memory for communication. The C code provides APIs for
Fortran to use the MMF. I agree that Tcl wrap on Fortran may be not
the best solution. If Fortran supports MMF C is unnecessary.
IN general, two MMF objects are required for Fortran/Tcl program.
One MMF for Fortran read and Tcl write, another MMF for Fortran
write and Tcl read. This model greatly simplify the synchronization.
However windows message communication between processes is
weak. It is stupid to find windows title rather than pid to send
message.
Chang
Richard Maine
> I would like to share my first experience of mixed language
> programming using tcl/tk and fortran.
I'll note that an approach I'm fond of for tcl/tk+fortran is to
use expect. The thing I really like about that is that it allows
your number-crunching program to have zero gui-related code. You
can still write the number crunching program as a portable text-based
program that will run anywhere.
The gui is basically a separate thing that "knows" how to run the
text-based program. Thus you can work in either world.
This was particularly attractive to me in adding a gui front end
for an existing program. I did not have to force all users to go
with the gui (though many of them pretty quickly converted). I
didn't even have to make a new release of the program.
It isn't the best approach for everything, but it is one of the
options.
Alas, expect has "issues" with Windows and none of the current
solutions are fully adequate. So that's currently a negative.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
Greg Chien
> Fortran process can write the data to that shared memory, Tcl GUI
> process can read the data and present it.
If we can execute the GUI (built in C, for example) and the Fortran
component in the same process space (perhaps, in a computation/worker
thread), fetching and updating data do not require interprocess
communication (IPC) or external file at all. All the GUI has to do is to
package the data and pass pointers to the Fortran routines. Going across
the process boundary is much less efficient, no matter what mechanism is
used. Besides, there is no "standard library" that does IPC in Fortran,
whereas the upcoming F2k3 does have pointer dereferencing between Fortran
and C. In short, when the GUI is in C, the IPC and external file issues
are moot.
> IN general, two MMF objects are required for Fortran/Tcl program.
> One MMF for Fortran read and Tcl write, another MMF for Fortran
> write and Tcl read. This model greatly simplify the synchronization.
No, you just let data go in and out between the two programs. To
synchronize them you still need locking mechanisms such as semaphore,
mutex, etc.
Chang Li
> "Chang Li" wrote
> > Fortran process can write the data to that shared memory, Tcl GUI
> > process can read the data and present it.
>
> If we can execute the GUI (built in C, for example) and the Fortran
> component in the same process space (perhaps, in a computation/worker
> thread), fetching and updating data do not require interprocess
> communication (IPC) or external file at all. All the GUI has to do is to
> package the data and pass pointers to the Fortran routines. Going across
> the process boundary is much less efficient, no matter what mechanism is
> used. Besides, there is no "standard library" that does IPC in Fortran,
> whereas the upcoming F2k3 does have pointer dereferencing between Fortran
> and C. In short, when the GUI is in C, the IPC and external file issues
> are moot.
The GUI is in Tk not in C. C is only used to implement the APIs.
>
> > IN general, two MMF objects are required for Fortran/Tcl program.
> > One MMF for Fortran read and Tcl write, another MMF for Fortran
> > write and Tcl read. This model greatly simplify the synchronization.
>
> No, you just let data go in and out between the two programs. To
> synchronize them you still need locking mechanisms such as semaphore,
> mutex, etc.
No lock needed if there is only one writer and multiple readers.
Chang
Chang Li
"Richard Maine" <nos...@see.signature> wrote in message
news:ue3cejd...@altair.dfrc.nasa.gov...
> gustav_...@yahoo.com (Gustav Ivanovic) writes:
>
> > I would like to share my first experience of mixed language
> > programming using tcl/tk and fortran.
>
> I'll note that an approach I'm fond of for tcl/tk+fortran is to
> use expect. The thing I really like about that is that it allows
> your number-crunching program to have zero gui-related code. You
> can still write the number crunching program as a portable text-based
> program that will run anywhere.
>
> The gui is basically a separate thing that "knows" how to run the
> text-based program. Thus you can work in either world.
>
How do you handle large amount of text data such as 100MB by Expect?
Chang
Richard Maine
> "Richard Maine" <nos...@see.signature> wrote in message
> news:ue3cejd...@altair.dfrc.nasa.gov...
> > I'll note that an approach I'm fond of for tcl/tk+fortran is to
> > use expect. The thing I really like about that is that it allows
> > your number-crunching program to have zero gui-related code. You
> > can still write the number crunching program as a portable text-based
> > program that will run anywhere.
> >
> > The gui is basically a separate thing that "knows" how to run the
> > text-based program. Thus you can work in either world.
>
> How do you handle large amount of text data such as 100MB by Expect?
Unless you are talking about a game or some other heavily graphical
application, large amounts of data don't go through a gui. It doesn't
even make sense for 100 mb of text data to go through a gui as far as
I can tell. Graphics data I could see (pun not intended); a human
can look at 100mb of graphics data from an application. But how is
a human supposed to be involved in 100mb of text data?
Certainly guis are used to control programs that manipulate large amounts
of data, but that is not at all the same thing as routing that data through
the gui.
In the scenario I described, the gui front-end that "knows" how to run
the program is "seeing" the same text that a human would have seen
running it. The program does not tend to throw 100mb of text at the
human. And the program even more certainly doesn't expect the human to
type in 100 mb of text.
For large quantities of data like that, you use data paths other than
the text-based terminal-like interaction on which expect is based. You
may well use expect to *CONTROL* the large amounts of data, but not
to feed those large amounts through. Indeed, the programs I was referring to
do tend to involve data from and to various files other than the gui.
At least one of these parts even involves a plot; again, the gui is used to
control the plot, but not to actually do the plotting. (When plottingm
three separate programs end up involved - the number crunching program,
the separate gui front end using expect and tcl/tk, and the plotting
program, which has been passed data and commands via separate files.)
--
Richard Maine
email: my last name at domain
domain: isomedia dot com
Chang Li
"Richard Maine" <nos...@see.signature> wrote in message
> "Chang Li" <cha...@neatware.com> writes:
> > How do you handle large amount of text data such as 100MB by Expect?
>
> Unless you are talking about a game or some other heavily graphical
> application, large amounts of data don't go through a gui. It doesn't
> even make sense for 100 mb of text data to go through a gui as far as
> I can tell. Graphics data I could see (pun not intended); a human
> can look at 100mb of graphics data from an application. But how is
> a human supposed to be involved in 100mb of text data?
>
A model file could be a text file generated by computer. It can be very
large. And you can expect a large XML file. Although it may be human
being readable it needs computer processing.
> Certainly guis are used to control programs that manipulate large amounts
> of data, but that is not at all the same thing as routing that data
through
> the gui.
>
> In the scenario I described, the gui front-end that "knows" how to run
> the program is "seeing" the same text that a human would have seen
> running it. The program does not tend to throw 100mb of text at the
> human. And the program even more certainly doesn't expect the human to
> type in 100 mb of text.
>
> For large quantities of data like that, you use data paths other than
> the text-based terminal-like interaction on which expect is based. You
> may well use expect to *CONTROL* the large amounts of data, but not
> to feed those large amounts through. Indeed, the programs I was referring
to
> do tend to involve data from and to various files other than the gui.
> At least one of these parts even involves a plot; again, the gui is used
to
> control the plot, but not to actually do the plotting. (When plottingm
> three separate programs end up involved - the number crunching program,
> the separate gui front end using expect and tcl/tk, and the plotting
> program, which has been passed data and commands via separate files.)
>
Expect should be limited to talk short phrases. But the large data
processing
by file is poor in performance.
Chang
Arjen Markus
>
> "Arjen Markus" wrote
> > I have experimented with that set-up myself: no problem.
> > In general: a GUI will not send too much stuff to a
> > computational component, but perhaps the results are huge
> > (for graphical presentation). In that case, use binary files.
>
> As long as the GUI refrains from controlling the computational component
> while the latter is running. However, with the increase of computing
> power (and sometimes being influenced by interactive games), the users
> tend to expect faster turn-around and, ultimately, interactive control of
> the computation processes.
:) I was thinking of the big programs we run here - they run for hours
on end,
and the main feedback _to_ the user is via "online visualisation".
But I agree, there are many many more possible scenarios. To counter
your
hint, why not write an article for the Fortran Forum on these issues? :D
>
> > The big issue is that some Fortran compilers do not do support
> > flushing the output files. That has been the major problem that
> > I have encountered.
>
> <Sarcasm>
> Perhaps, Giles can teach you how to solve the problem, or design the
> system correctly. ;-)
> </Sarcasm>
>
Sorry, the sarcasm is lost on me - I must have missed one or more
discussions
(or parts of some I did read)
> > But if you use two different processes, you have a very loose
> > connection between two entirely different pieces of your system,
> > so independent development and maintenance is much easier.
>
> Loosely coupled, I agree. Easier? Well, you will need to work alone or
> have a highly disciplined team in order to synchronize the changes between
> the two. I've seen too often that when the GUI is done, it is obsolescent
> due to underlying requirement changes/enhancements in the computational
> module. The other problem is code duplication in Fortran routines and GUI
> component built in different languages/tools. Both of them need "read and
> validate" routines to fetch input data and guard against errors and the
> functions are generally overlapped. If the GUI and the computation
> routines are developed in the same language system, or with a well
> thought-out scheme (hint, hint :-) the input data have already been in the
Re hint, hint: see above
> memory before the Fortran DLLs are called. The "read and validate"
> routines will be in only one place, which is much easier to develop and
> maintain.
>
It is a very interesting subject, with lots of aspects! Boy, I wish
there
was more time in a day, as I would love to write or read about that!
Regards,
Arjen
Richard Maine
> "Richard Maine" <nos...@see.signature> wrote in message
> news:m21xu0k...@vega.dsl.att.net...
> > "Chang Li" <cha...@neatware.com> writes:
>
> > > How do you handle large amount of text data such as 100MB by Expect?
> >
> > Unless you are talking about a game or some other heavily graphical
> > application, large amounts of data don't go through a gui. It doesn't
> > even make sense for 100 mb of text data to go through a gui as far as
> > I can tell. Graphics data I could see (pun not intended); a human
> > can look at 100mb of graphics data from an application. But how is
> > a human supposed to be involved in 100mb of text data?
>
> A model file could be a text file generated by computer. It can be very
> large. And you can expect a large XML file. Although it may be human
> being readable it needs computer processing.
Yes. This seems to be a nonsequitur to me. I think we must be
talking about something entirely different. Yes, it would need
computer processing. However, I don't see what this has to do with
the gui. This is a fine example of the kind of thing I was referring
to in my next para (cited below).
> > Certainly guis are used to control programs that manipulate large amounts
> > of data, but that is not at all the same thing as routing that data
> > through the gui.
To re state in other words my answer to your question
> > > How do you handle large amount of text data such as 100MB by Expect?
I would say not to do that. I don't think expect is an appropriate
tool for such a thing. I do think expect is one of several plausible
tools for creating gui wrappers for programs. If your gui wrapper is
trying to parse 100mb files, then you aren't designing it the way I
would.
James Giles
> "Arjen Markus" wrote
>> The big issue is that some Fortran compilers do not do support
>> flushing the output files. That has been the major problem that
>> I have encountered.
>
> <Sarcasm>
> Perhaps, Giles can teach you how to solve the problem, or design the
> system correctly. ;-)
> </Sarcasm>
Yes, and I did so in a previous thread. Not only that, I proposed an
alternative language feature which correctly flushes buffers when
necessary (on those poorly designed systems which require it).
It would be a much better candidate for standardization than FLUSH.
Evidently, opposing features that are frequently the cause of serious
error is an appropriate target of sarcasm. While promoting such
features is filled with virtue.
--
J. Giles
Greg Chien
> Yes, and I did so in a previous thread. Not only that, I proposed an
> alternative language feature which correctly flushes buffers when
> necessary (on those poorly designed systems which require it).
> It would be a much better candidate for standardization than FLUSH.
I must have missed your proposal. Could you please provide a link?
> Evidently, opposing features that are frequently the cause of serious
> error is an appropriate target of sarcasm. While promoting such
> features is filled with virtue.
Unfortunately (or fortunately ;-), we are not living in Utopia.
James Giles
> "James Giles" wrote
>> Yes, and I did so in a previous thread. Not only that, I proposed an
>> alternative language feature which correctly flushes buffers when
>> necessary (on those poorly designed systems which require it).
>> It would be a much better candidate for standardization than FLUSH.
>
I don't feel like digging through google. The proposal is to add a line
in the standard that all WRITE statements always implicitly flush as
their last operation. Also, an OPEN statement option to request that
such automatic flushes not be performed on particular files (where
the user of the application would then be responsible to guarantee that
no timing or buffering delays are relevant for that file).
That is the only rule that's objectively correct and portable for using
flush: it must be performed immediately after *all* writes. Any other
choice is error prone (and in a non-portable, often unreproducible
way).
>> Evidently, opposing features that are frequently the cause of serious
>> error is an appropriate target of sarcasm. While promoting such
>> features is filled with virtue.
>
> Unfortunately (or fortunately ;-), we are not living in Utopia.
I neve claimed we were. I do think, however, that we should promote
things that are improvements. And that it's counterproductive to promote
things that aren't.
--
J. Giles
Greg Chien
> Greg Chien wrote:
> > As long as the GUI refrains from controlling the computational
> > component while the latter is running. However, with the increase
> > of computing power (and sometimes being influenced by interactive
> > games), the users tend to expect faster turn-around and,
> > ultimately, interactive control of the computation processes.
>
> :) I was thinking of the big programs we run here - they run for
> hours on end, and the main feedback _to_ the user is via "online
> visualisation".
Do you mean "post-processing" after the computation is all done?
> But I agree, there are many many more possible scenarios. To
> counter your hint, why not write an article for the Fortran Forum
> on these issues? :D
My first attempt can be found in:
http://www.compaq.com/fortran/visual/vfn09/page2.html
Be warned that it uses Cray pointers to fetch the data objects packaged by
the GUI program written in C/C++ (the memory management part is in C,
making it easier to communicate with Fortran and others). This is the
main reason why I am advocating C-Interop in F2k3 so that the programming
interface can conform to the standard. That'll be the time to write one
for Fortran Forum :-)
> Sorry, the sarcasm is lost on me - I must have missed one or
> more discussions (or parts of some I did read)
Giles has followed up in this thread. For the historical arguments on
FLUSH, you can search google news group with "Giles Fortran Flush."
Arjen Markus
>
> "Arjen Markus" wrote
> > Greg Chien wrote:
> > > As long as the GUI refrains from controlling the computational
> > > component while the latter is running. However, with the increase
> > > of computing power (and sometimes being influenced by interactive
> > > games), the users tend to expect faster turn-around and,
> > > ultimately, interactive control of the computation processes.
> >
> > :) I was thinking of the big programs we run here - they run for
> > hours on end, and the main feedback _to_ the user is via "online
> > visualisation".
>
> Do you mean "post-processing" after the computation is all done?
That is one way. The other is to display the results of intermediate
steps rightaway, while the calculation is in progress.
>
> > But I agree, there are many many more possible scenarios. To
> > counter your hint, why not write an article for the Fortran Forum
> > on these issues? :D
>
> My first attempt can be found in:
> http://www.compaq.com/fortran/visual/vfn09/page2.html
>
Got that. I think I have seen it before ...
> > Sorry, the sarcasm is lost on me - I must have missed one or
> > more discussions (or parts of some I did read)
>
> Giles has followed up in this thread. For the historical arguments on
> FLUSH, you can search google news group with "Giles Fortran Flush."
>
>
Ah, I had missed that, but now I see the proposal. I would vote "yes"
to that (not being able to foresee all consequences, though, but it
seems straightforward and it transfers the burden from the programmer
to the computer).
Regards,
Arjen