According to FPL:
I think this program is a better example of what the problem is. It is not as artificial as the prior one, and can be executed without gdb so that one can see the problem may lie somewhere else that in debugging informations.
program loop2(input, output); var i, j : integer;
begin j:=0; repeat for i:=0 to 10 do if (i div 2)=0 then begin write('*'); j:=j+1; end; writeln; until j=10; end.
Do you agree the output should be a rectangular array of 5 stars by ten,
No. For each run of the `repeat' loop, only one star (for i = 0) is printed.
Perhaps you mean `if i mod 2 = 0'?
Well, what *I* get when running the output code is
... correct. ;-)
Also, I have (in the other program) some file of text type ever opened, and I have noticed in applying your advice that GPC complains it cannot write on the default output device (the screen) because of my opened file. Just a writeln('*') and *not* a writeln(f, '*') wille make it say
?GPC runtime error: File is not open for writing (#9)
This sounds strange and *maybe* indicates a bug. How did you open the file?
The following should work:
Assign ( MyFile, 'filename.txt' ); rewrite ( MyFile ); writeln ( 'Hello?' ); writeln ( MyFile, 'Hello!' ); close ( MyFile );
Greetings,
Peter
?GPC runtime error: File is not open for writing (#9)
This sounds strange and *maybe* indicates a bug. How did you open the file?
readln(nom_de_fichier); writeln; assign(f, nom_de_fichier);
The following should work:
Assign ( MyFile, 'filename.txt' ); rewrite ( MyFile ); writeln ( 'Hello?' ); writeln ( MyFile, 'Hello!' ); close ( MyFile );
Well, I do read in the file, when GPC exists nothing still has been written in it.
I use readln(f, string) (file of type text), and also a read of the content character per character. I use GPC eof and eoln, I close the file and when, It is after the file has been closed, I submit a
write(Ilargeur_pattern);
?GPC runtime error: File is not open for writing (#9)
Program exited with code 01.
I have tested Antoine's suppression of (input, output) but it does not change anything (and I took advantage of his relating story to take one more coffee too).
Cheers.
F.P.L
According to FPL:
readln(nom_de_fichier); writeln; assign(f, nom_de_fichier);
What about `rewrite'? (See my example.)
The following should work:
Assign ( MyFile, 'filename.txt' ); rewrite ( MyFile ); writeln ( 'Hello?' ); writeln ( MyFile, 'Hello!' ); close ( MyFile );
Peter
Peter Gerwinski wrote:
According to FPL:
readln(nom_de_fichier); writeln; assign(f, nom_de_fichier);
What about `rewrite'? (See my example.)
Do you mean one should also use rewrite for reading file? Rewrite is supposed to serve only as a prior request to *writing* into file, isn't it? and reset for reading. Well, whatever you mean, I have used rewrite instead of reset, and the end is the same, exit with code one.
What's bothering me is that gdb does not affect correct values to variables when tracing trough the programm. Without changing one's value, gdb will report, now the good value, now an another one, so I have tried inserting writeln(the_variable) to see what happens, and it results in this GPC error. Meanwhile, good new, it is, as you said, only in reporting debugging information that GPC may fails, because, yes, when putting the breakpoint far away, everything works as expected. The actual problem (if one forgett those error of writting files) is that gdb does behave strangely with some part of GPC code. I say some part because I use intensively gdb and for the very greatest part, it works fine.
Cheers.
According to FPL:
Do you mean one should also use rewrite for reading file?
As I have understood your problem, you wanted to write to the file and got an error message "file is not open for writing".
Perhaps `update ( MyFile )' is what you need: Open an existing file for read and write access.
[...] Meanwhile, good new, it is, as you said, only in reporting debugging information that GPC may fails, because, yes, when putting the breakpoint far away, everything works as expected. The actual problem (if one forgett those error of writting files) is that gdb does behave strangely with some part of GPC code. I say some part because I use intensively gdb and for the very greatest part, it works fine.
One problem is that noone in the GPC developing team is familiar enough with GDB to really find out what is wrong in GPC. Any help welcome!
Peter
-
FPL -
Peter Gerwinski