OK, I made some progress in my hobby project and now it
displays a graph of its results. I put a READ(*,'(a)') statement
at the end so my graphs wouldn't go away when the
program terminates.
After considerable effort I found out how to write a *.ppm
file and how to get gimp.exe to convert all of my *.ppm
files (which most software can't read) to *.png.
Then I wrote a *.bat file that permits me to run a bunch
of scenarios. Since I didn't want to have to change focus
to the CMD.exe window and hit <ENTER> for every run
of the program, I had it detect when it was running in batch
mode and skip the READ(*,'(a)') statement because the
graphs would be available in *.png form anyway.
However, this caused a problem because the last and of
course most important *.ppm doesn't complete writing
before its thread closes,
so I don't get that *.ppm file.
I tried putting a FLUSH(iunit) statement before the
CLOSE(iunit) statement, but still no joy. How am I
supposed to tell the thread to wait for the *.ppm file
to get properly written and saved before returning?
James Van Buskirk <not_valid@comcast.net> schrieb:
OK, I made some progress in my hobby project and now it
displays a graph of its results. I put a READ(*,'(a)') statement
at the end so my graphs wouldn't go away when the
program terminates.
After considerable effort I found out how to write a *.ppm
file and how to get gimp.exe to convert all of my *.ppm
files (which most software can't read) to *.png.
You can also use the pngtopng command from netpbm, which
is a bit more lightweight than gimp :-)
Then I wrote a *.bat file that permits me to run a bunch
of scenarios. Since I didn't want to have to change focus
to the CMD.exe window and hit <ENTER> for every run
of the program, I had it detect when it was running in batch
mode and skip the READ(*,'(a)') statement because the
graphs would be available in *.png form anyway.
However, this caused a problem because the last and of
course most important *.ppm doesn't complete writing
before its thread closes,
Do you do different threads in a main program? If
so, how? OpenMP? Coarrays? pthreads? Windows
threads?
Or did you just mean program?
so I don't get that *.ppm file.
I tried putting a FLUSH(iunit) statement before the
CLOSE(iunit) statement, but still no joy. How am I
supposed to tell the thread to wait for the *.ppm file
to get properly written and saved before returning?
This is very hard to answer without knowing exactly what
you did, what system (I presume Windows), and what
thread model and what compiler you used.
James Van Buskirk <not_valid@comcast.net> schrieb:
"Thomas Koenig" wrote in message news:tkqben$38a5n$1@newsreader4.netcologne.de...
James Van Buskirk <not_valid@comcast.net> schrieb:
After considerable effort I found out how to write a *.ppm
file and how to get gimp.exe to convert all of my *.ppm
files (which most software can't read) to *.png.
You can also use the pngtopng command from netpbm, which
is a bit more lightweight than gimp :-)
Well, I installed gimp for a previous project and its licensing arrangements seemed satisfactory. It's a bitch to use it in
batch mode, though.
That is what netpbm is for.
You could just do
CALL EXECUTE_COMMAND_LINE ("pngtopng yourfile.ppm > yourfile.png")
from your Fortran program, this should work. It might open a
cmd window, though.
"Thomas Koenig" wrote in message news:tkqben$38a5n$1@newsreader4.netcologne.de...
James Van Buskirk <not_valid@comcast.net> schrieb:
OK, I made some progress in my hobby project and now it
displays a graph of its results. I put a READ(*,'(a)') statement
at the end so my graphs wouldn't go away when the
program terminates.
After considerable effort I found out how to write a *.ppm
file and how to get gimp.exe to convert all of my *.ppm
files (which most software can't read) to *.png.
You can also use the pngtopng command from netpbm, which
is a bit more lightweight than gimp :-)
Well, I installed gimp for a previous project and its licensing
arrangements seemed satisfactory. It's a bitch to use it in
batch mode, though.
What would have been really cool
would have been a printer driver that had the option to
print to file with *.png being one of the accessible formats.
Then I could have rendered to the file like I have rendered
to printer previously. However, Windows doesn't come with
such goodies: Microsoft XPS Document Writer seems to be
able to embed a PNG in a *.oxps file, but I couldn't figure
out how to extract it from there. There are drivers out
there on the web that can print to *.png, but using them
would mean the my program wouldn't be self-contained.
Then I wrote a *.bat file that permits me to run a bunch
of scenarios. Since I didn't want to have to change focus
to the CMD.exe window and hit <ENTER> for every run
of the program, I had it detect when it was running in batch
mode and skip the READ(*,'(a)') statement because the
graphs would be available in *.png form anyway.
However, this caused a problem because the last and of
course most important *.ppm doesn't complete writing
before its thread closes,
Do you do different threads in a main program? If
so, how? OpenMP? Coarrays? pthreads? Windows
threads?
Or did you just mean program?
No, Windows threads with _beginthreadex() and the
whole 9 yards.
I tried putting a WaitForSingleObject
call before program termination, but it had no effect.
Seemingly the thread (and my *.ppm file) were already
long gone by that time.
so I don't get that *.ppm file.
I tried putting a FLUSH(iunit) statement before the
CLOSE(iunit) statement, but still no joy. How am I
supposed to tell the thread to wait for the *.ppm file
to get properly written and saved before returning?
This is very hard to answer without knowing exactly what
you did, what system (I presume Windows), and what
thread model and what compiler you used.
D:\gfortran\james>gfortran -v
As you can see, the compiler is using win32 threads rather than posix. I
had
difficulties early on so I downloaded this compiler although I am not sure
if
it is necessary to use the win32 threads gfortran compiler if you are making threads via the Win32 API.
The program is kinda long: win.f90=33 kB, gl.f90=41 kB, xygraph.f90 = 58 kB and even my calculational engine is 47 kB. It definitely needs Windows to work and the ifort-compiled version just hangs without any output.
Thus, it wouldn't do much good to post the code because nobody would
have the time, energy, and ability to investigate it.
On Sun, 13 Nov 2022 11:24:21 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:
James Van Buskirk <not_valid@comcast.net> schrieb:
"Thomas Koenig" wrote in message
news:tkqben$38a5n$1@newsreader4.netcologne.de...
James Van Buskirk <not_valid@comcast.net> schrieb:
After considerable effort I found out how to write a *.ppm
file and how to get gimp.exe to convert all of my *.ppm
files (which most software can't read) to *.png.
You can also use the pngtopng command from netpbm, which
is a bit more lightweight than gimp :-)
Well, I installed gimp for a previous project and its licensing
arrangements seemed satisfactory. It's a bitch to use it in
batch mode, though.
That is what netpbm is for.
You could just do
CALL EXECUTE_COMMAND_LINE ("pngtopng yourfile.ppm > yourfile.png")
from your Fortran program, this should work. It might open a
cmd window, though.
Is there a pngtopng programme ? Do you mean pnmtopng perhaps ?
If you are using threads, you will probably need -frecursive
to make sure that all variables are on the stack.
If your thread exited (how did you do that?) it might
have cleaned up after itself in some way, and left
the runtime in an inconsistent state.
The least you probably have to do is to make sure that any I/O
library calls are only executed on a single thread, by putting
the Windows equivalent of "omp critical" around it.
If it's a hobby project, maybe you want to completely rewrite it in gtk-fortran :-)
"Thomas Koenig" wrote in message news:tkqk55$38e2i$1@newsreader4.netcologne.de...
If you are using threads, you will probably need -frecursive
to make sure that all variables are on the stack.
No, I explicitly declare all my procedures as recursive.
If your thread exited (how did you do that?) it might
have cleaned up after itself in some way, and left
the runtime in an inconsistent state.
I think that's inconsistent with the symptoms in that
if the calling program is stalled waiting for input the
data is not lost.
so as a workaround but I have other stuff I have to mess
with in the immediate future.
The least you probably have to do is to make sure that any I/O
library calls are only executed on a single thread, by putting
the Windows equivalent of "omp critical" around it.
In earlier testing this was no problem, just somewhat
difficult to interpret output. When the failure occurs only
the failing thread is performing I/O.
If it's a hobby project, maybe you want to completely rewrite it in
gtk-fortran :-)
There are problems with that project I have mentioned
long ago, and it's not really a Windows thing. Can you
create an OpenGK render context in gtk-fortran, for
example?
OK, I made some progress in my hobby project and now it
displays a graph of its results. I put a READ(*,'(a)') statement
at the end so my graphs wouldn't go away when the
program terminates.
After considerable effort I found out how to write a *.ppm
file and how to get gimp.exe to convert all of my *.ppm
files (which most software can't read) to *.png.
Then I wrote a *.bat file that permits me to run a bunch
of scenarios. Since I didn't want to have to change focus
to the CMD.exe window and hit <ENTER> for every run
of the program, I had it detect when it was running in batch
mode and skip the READ(*,'(a)') statement because the
graphs would be available in *.png form anyway.
However, this caused a problem because the last and of
course most important *.ppm doesn't complete writing
before its thread closes, so I don't get that *.ppm file.
I tried putting a FLUSH(iunit) statement before the
CLOSE(iunit) statement, but still no joy. How am I
supposed to tell the thread to wait for the *.ppm file
to get properly written and saved before returning?
No direct help for the issues you describe that someone has
not mentioned already, but if you are just writing Poskanzer
pixelmaps from a batch problem I would mention a few other
possibilities
It sounds like you using a lot of MSWIndows-specific
components, threaded, and so on. On the other hand you
seem to be creating a P6 file at a low level. If you have an
internal array representing a pixel map you might consider
writing GIF; I have used
https://fortranwiki.org/fortran/show/writegif
which is in Fortran and so can be very portable with
no dependencies.
I am a fan of Netpbm+ for batch use, and have generated
low-level P6 graphics quite a bit (even have a hopefully
portable module just for that); see
https://github.com/urbanjost/M_pixel and
https://github.com/urbanjost/M_draw
for example. That approach can work very well for
simple projects where longevity and portability matter;
particularly with batch-generated graphics (I have programs
that have been on dozens of OSes and are decades old still
running taking that approach) but it is not the way to go
for high-level event-driven threaded codes or for most
high-level graphics. So not quite sure such a low-level
approach is of any use; but thought I would mention it
as you are mentioning P6 files (again, have used them for
years with great success).
On 11/13/2022 2:46 AM, James Van Buskirk wrote:
OK, I made some progress in my hobby project and now it
displays a graph of its results. I put a READ(*,'(a)') statement
at the end so my graphs wouldn't go away when the
program terminates.
After considerable effort I found out how to write a *.ppm
file and how to get gimp.exe to convert all of my *.ppm
files (which most software can't read) to *.png.
Then I wrote a *.bat file that permits me to run a bunch
of scenarios. Since I didn't want to have to change focus
to the CMD.exe window and hit <ENTER> for every run
of the program, I had it detect when it was running in batch
mode and skip the READ(*,'(a)') statement because the
graphs would be available in *.png form anyway.
However, this caused a problem because the last and of
course most important *.ppm doesn't complete writing
before its thread closes, so I don't get that *.ppm file.
I tried putting a FLUSH(iunit) statement before the
CLOSE(iunit) statement, but still no joy. How am I
supposed to tell the thread to wait for the *.ppm file
to get properly written and saved before returning?
I sometimes use a shared memory buffer to communication with separate processes or threads. Example of the win32 api for this is here:
https://www.fortranlib.com/ShareBufferWin32.f90
You can make it virtually any size you want. I sometimes use various
flags (wait, kill, etc.) to synchronize with hardware or software.
OK, I made some progress in my hobby project and now it
displays a graph of its results. I put a READ(*,'(a)') statement
at the end so my graphs wouldn't go away when the
program terminates.
After considerable effort I found out how to write a *.ppm
file and how to get gimp.exe to convert all of my *.ppm
files (which most software can't read) to *.png.
Then I wrote a *.bat file that permits me to run a bunch
of scenarios. Since I didn't want to have to change focus
to the CMD.exe window and hit <ENTER> for every run
of the program, I had it detect when it was running in batch
mode and skip the READ(*,'(a)') statement because the
graphs would be available in *.png form anyway.
However, this caused a problem because the last and of
course most important *.ppm doesn't complete writing
before its thread closes, so I don't get that *.ppm file.
I tried putting a FLUSH(iunit) statement before the
CLOSE(iunit) statement, but still no joy. How am I
supposed to tell the thread to wait for the *.ppm file
to get properly written and saved before returning?
James Van Buskirk wrote:
However, this caused a problem because the last and of
course most important *.ppm doesn't complete writing
before its thread closes, so I don't get that *.ppm file.
I tried putting a FLUSH(iunit) statement before the
CLOSE(iunit) statement, but still no joy. How am I
supposed to tell the thread to wait for the *.ppm file
to get properly written and saved before returning?
Have you tried a WAIT or SLEEP function to provide the required delay
of a small faction of a second, as judged by experience?
I sometimes use a shared memory buffer to communication with separate processes or threads. Example of the win32 api for this is here:
https://www.fortranlib.com/ShareBufferWin32.f90
You can make it virtually any size you want. I sometimes use various
flags (wait, kill, etc.) to synchronize with hardware or software.
"David Jones" wrote in message news:tkr3gq$nkk$1@gioia.aioe.org...
James Van Buskirk wrote:
However, this caused a problem because the last and of
course most important *.ppm doesn't complete writing
before its thread closes, so I don't get that *.ppm file.
I tried putting a FLUSH(iunit) statement before the
CLOSE(iunit) statement, but still no joy. How am I
supposed to tell the thread to wait for the *.ppm file
to get properly written and saved before returning?
Have you tried a WAIT or SLEEP function to provide the required
delay of a small faction of a second, as judged by experience?
Yeah, that's the first thing I plan to try when I get the
resources (time and energy) to struggle with this problem
again. It might need to be a couple of seconds, but the
overall program takes a couple of minutes to run at
parameters near to what currently makes it crash by
flying too close to the sun.
"Gary Scott" wrote in message news:tkrjfj$1h7po$1@dont-email.me...
I sometimes use a shared memory buffer to communication with separate
processes or threads. Example of the win32 api for this is here:
https://www.fortranlib.com/ShareBufferWin32.f90
You can make it virtually any size you want. I sometimes use various
flags (wait, kill, etc.) to synchronize with hardware or software.
I seems that your solution would be to create a shared buffer that
the dying thread would allocate and fill with data in its last gasp
and then the main program would write the data to file.
I think that might work but I was hoping for a solution that
preserved the current division of labor.
No, Windows threads with _beginthreadex() and the
whole 9 yards. I tried putting a WaitForSingleObject
call before program termination, but it had no effect.
Seemingly the thread (and my *.ppm file) were already
long gone by that time.
On 11/13/2022 6:12 PM, Gary Scott wrote:Of course you have to be careful with some forms as they will truncate
On 11/13/2022 2:42 PM, James Van Buskirk wrote:Another possibility that I sometimes use is shared file access. On
"Gary Scott" wrote in message news:tkrjfj$1h7po$1@dont-email.me...I don't think the division of labor would need to change, just use one
I sometimes use a shared memory buffer to communication with
separate processes or threads. Example of the win32 api for this is
here:
https://www.fortranlib.com/ShareBufferWin32.f90
You can make it virtually any size you want. I sometimes use
various flags (wait, kill, etc.) to synchronize with hardware or
software.
I seems that your solution would be to create a shared buffer that
the dying thread would allocate and fill with data in its last gasp
and then the main program would write the data to file.
I think that might work but I was hoping for a solution that
preserved the current division of labor.
or two shared variables (in the swap file) to communicate between the
threads and synchronize as needed. Maybe when the thread is done, it
sets a shared flag when it completes or it waits until the main sets a
flag to allow the thread to continue/process. Better than an
arbitrary wait/delay.
windows, I'll reserve usually a header at the beginning of the file
(usually direct access, but it works with stream and other forms as
well). The header may contain a flag to indicate the availability state
for reading or writing by other processes (or threads). In my
application, I also implemented record locks in each record (and
timestamps at beginning and end of record and check sums, etc.). It
seems completely reliable. I've never had a data corruption in decades
and billions of read/writes, knock on wood :)
SHARE
'DENYRW'
'DENYWR'
'DENYRD'
'DENYNONE'
File locking
'DENYWR'
Note: The default differs under certain conditions (see SHARE Specifier). Other notes:
'DENYWR': on Linux* and macOS systems, the default depends only on the
FORM setting.
'DENYRD': applies to Windows.
SHARED
No value
File sharing allowed
Linux* and macOS: SHARED
Windows: Not shared
On 11/13/2022 2:42 PM, James Van Buskirk wrote:Another possibility that I sometimes use is shared file access. On
"Gary Scott" wrote in message news:tkrjfj$1h7po$1@dont-email.me...I don't think the division of labor would need to change, just use one
I sometimes use a shared memory buffer to communication with separate
processes or threads. Example of the win32 api for this is here:
https://www.fortranlib.com/ShareBufferWin32.f90
You can make it virtually any size you want. I sometimes use various
flags (wait, kill, etc.) to synchronize with hardware or software.
I seems that your solution would be to create a shared buffer that
the dying thread would allocate and fill with data in its last gasp
and then the main program would write the data to file.
I think that might work but I was hoping for a solution that
preserved the current division of labor.
or two shared variables (in the swap file) to communicate between the
threads and synchronize as needed. Maybe when the thread is done, it
sets a shared flag when it completes or it waits until the main sets a
flag to allow the thread to continue/process. Better than an arbitrary wait/delay.
Fortran asynchronous I/O has a WAIT statement such that you can
wait for the operation to be done. For READ, you can't look at the data until after the WAIT. For WRITE, you can't reuse the output buffer until after WAIT.
A possible (flexible on time?) strategy might be to interactively try
to open-for-exclusive-read the file once you have closed it, with a
WAIT or SLEEP between tries. THIs mighrt ensure the system thinks the
file properly exists before you close the program.
seemed to work consistently and I don't want to spend too much
time on this problem. What happens if you can open for exclusive
read and then the writing process decides that now is the time to
open the file for writing?
"gah4" wrote in message news:10f6e9a0-658b-41db-b500-cf1474588555n@googlegroups.com...
Fortran asynchronous I/O has a WAIT statement such that you can
wait for the operation to be done. For READ, you can't look at the data
until after the WAIT. For WRITE, you can't reuse the output buffer until
after WAIT.
I didn't realize that the committee had sneaked asynchronous I/O in
there. Unfortunately, as Thomas Koenig said, it doesn't work in
gfortran on Windows.
"David Jones" wrote in message news:tkr3gq$nkk$1...@gioia.aioe.org...RE: Tips on downloading a github package ...
James Van Buskirk wrote:
However, this caused a problem because the last and of
course most important *.ppm doesn't complete writing
before its thread closes, so I don't get that *.ppm file.
I tried putting a FLUSH(iunit) statement before the
CLOSE(iunit) statement, but still no joy. How am I
supposed to tell the thread to wait for the *.ppm file
to get properly written and saved before returning?
Have you tried a WAIT or SLEEP function to provide the required delayYeah, that's the first thing I plan to try when I get the
of a small faction of a second, as judged by experience?
resources (time and energy) to struggle with this problem
again. It might need to be a couple of seconds, but the
overall program takes a couple of minutes to run at
parameters near to what currently makes it crash by
flying too close to the sun.
"David Jones" wrote in message news:tkr3gq$nkk$1@gioia.aioe.org...
James Van Buskirk wrote:
However, this caused a problem because the last and of
course most important *.ppm doesn't complete writing
before its thread closes, so I don't get that *.ppm file.
I tried putting a FLUSH(iunit) statement before the
CLOSE(iunit) statement, but still no joy. How am I
supposed to tell the thread to wait for the *.ppm file
to get properly written and saved before returning?
Have you tried a WAIT or SLEEP function to provide the required delay
of a small faction of a second, as judged by experience?
Yeah, that's the first thing I plan to try when I get the
resources (time and energy) to struggle with this problem
again.
"Thomas Koenig" wrote in message news:tktvdu$3amf6$1@newsreader4.netcologne.de...
James Van Buskirk <not_valid@comcast.net> schrieb:
"David Jones" wrote in message news:tkr3gq$nkk$1@gioia.aioe.org...
James Van Buskirk wrote:
However, this caused a problem because the last and of
course most important *.ppm doesn't complete writing
before its thread closes, so I don't get that *.ppm file.
I tried putting a FLUSH(iunit) statement before the
CLOSE(iunit) statement, but still no joy. How am I
supposed to tell the thread to wait for the *.ppm file
to get properly written and saved before returning?
Have you tried a WAIT or SLEEP function to provide the required delay
of a small faction of a second, as judged by experience?
Yeah, that's the first thing I plan to try when I get the
resources (time and energy) to struggle with this problem
again.
Another possibility: Have the writing thread open the file under
another name, and upon completion, rename it to the final name
(using the non-standard RENAME function or subroutine).
The other thread can then INQUIRE for the existence of
the file in a loop, possibly with a SLEEP thrown in.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 159 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 98:04:22 |
| Calls: | 3,209 |
| Files: | 10,563 |
| Messages: | 3,009,574 |