Maurice:
Strange. doing the same on DJGPP (W98se DOS box) with gpc 20041218 based on gcc 3.2.3 behaves as expected.
Hmm. I don't understand why it would be an issue on a Sun!
All is done manually with suitable tools to binary visualize the true content of files, no shell scripts or functions which could be too intelligent (I have bash, no tcsh) and hide something "unimportant", for example no linefeed or ^Z (a DOS nicety on text files) added at the end.
The script demonstrated in three ways that the files had zero length.
A side comment: to make it work I needed to compile with gpc add the --transparent-file-name option to gpc (otherwise the filenames are asked at the beginning of the execution) Why did you not need it ?
You are right. I use a script, gpcc, which uses that option.
The files are definitely empty - there is no need for me to clear them inside the Pascal program. The script uses `echo -n ""` to make them and three different standard unix tools (ls, wc, file) say they contain zero bytes. The results were in the initial report.
I have just discovered something else. Using the *same* code and the *same* input files:
gpc 20040516, based on gcc-3.3.3 fails (says empty files are not eof after reset).
but the older
GNU Pascal version 2.1 (20020510), based on gcc-2.95.2 19991024 (release). works! (says empty files are eof after reset)
Thus the behavior of GPC has changed between these two.
From my viewpoint this is an extremly serious bug because so many of
my programs use the eof test. What's happening is that I'm slowly updating programs and so I didn't notice it until now. I spent all night the other day trying to figure a way to replace eof with something that worked (using eof but is still standard) but failed. If I have to use the p2c converter to work with my programs, I will be forced to abandon GPC, just as I was converting all programs to function smoothly with it ... :-( This is now true for one program.
I hope that this can be solved!
Regards,
Tom
Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Molecular Information Theory Group Frederick, Maryland 21702-1201 toms@ncifcrf.gov permanent email: toms@alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/
Tom Schneider wrote:
gpc 20040516, based on gcc-3.3.3 fails (says empty files are not eof after reset).
but the older
GNU Pascal version 2.1 (20020510), based on gcc-2.95.2 19991024 (release). works! (says empty files are eof after reset)
Thus the behavior of GPC has changed between these two.
From my viewpoint this is an extremly serious bug because so many of
my programs use the eof test. What's happening is that I'm slowly updating programs and so I didn't notice it until now. I spent all night the other day trying to figure a way to replace eof with something that worked (using eof but is still standard) but failed. If I have to use the p2c converter to work with my programs, I will be forced to abandon GPC, just as I was converting all programs to function smoothly with it ... :-( This is now true for one program.
I hope that this can be solved!
Regards,
Tom
I think going to p2c will isolate your fine work.
http://www.lecb.ncifcrf.gov/~toms/software.html
Many of the features turbo pascal introduced, that "vanilla" pascal lacked, are part of Ada95 and also include object types. Conformant arrays are a GPC addition to pascal. Your important work invites these updates.
Rick.
Rick Engebretson wrote:
Many of the features turbo pascal introduced, that "vanilla" pascal lacked, are part of Ada95
I don't know Ada very well, but I doubt that. Especially the TP features are often characterized by type-unsafeness and similar issues. Since Ada's main goal is to be strongly typed and safe at runtime, I can't really imagine they added things such as unchecked type-casts, "absolute" variables, assembler statements and machine code inlines, low-level memory access (FillChar, Move), misusing constants as variables, confusion between pointers and arrays and sometimes single elements and arrays etc., to name just some of the most problematic ones.
Conformant arrays are a GPC addition to pascal.
Not at all. Conformant arrays are a feature of both Pascal standards (ISO 7185 and 10206) at "level 1". Some other compilers don't implement them, though.
Frank
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Feb 1, 2005, at 1:59 PM, Frank Heckenbach wrote:
issues. Since Ada's main goal is to be strongly typed and safe at runtime, I can't really imagine they added things such as unchecked type-casts, "absolute" variables, assembler statements and machine code inlines, low-level memory access (FillChar, Move), misusing constants as variables, confusion between pointers and arrays and sometimes single elements and arrays etc., to name just some of the most problematic ones.
Correct, those are not features of Ada. Ada *does* have features like AND THEN and OR ELSE (like GPC's AND_THEN, OR_ELSE), and a number of really cool features that are not even part of GPC to my knowledge. Then again, GPC has some things (like SETs) which Ada does not...
Ada has the notion of a "range", which is a sequence of values with a starting point and an ending point. In other words, a range could be 1..5, 'a'..'z', etc., but it cannot contain disjoint values as can one of Pascal's SETs -- ['A', '5'..'7'] cannot be reproduced easily in Ada.
However, you can do some interesting things with the ranges:
for i in 1..5 loop -- standard Ada for loop header
for i in Integer'Range -- another way to look at it, hmm...
Ada *does* have type casts, but they are neither 'unchecked' nor arbitrary. Additionally, you can't even directly perform mathematical operations between integers and reals without casting them. Ada is very picky, but it certainly does make it much more difficult to accidentally leave many kinds of "stupid" bugs in your code. Off-by-one is still possible, obviously (although Ada can even catch some instances of this, where types are well-defined and the off-by-one results in a range check exception), and some other things...
Ada also supports exceptions, and a somewhat strict variation on inheritance using extensible records:
type oldRec is record oldField : Integer; end record;
type newRec is new oldRec with record newField : Integer; end record;
(newRec will have two fields: oldField and newField).
Disclaimer: I did not run the above code through an Ada compiler, so it is quite possible there were some errors in that code... but I'm sure it's pretty close.
- ----------------------------------------------------------- Frank D. Engel, Jr. fde101@fjrhome.net
$ ln -s /usr/share/kjvbible /usr/manual $ true | cat /usr/manual | grep "John 3:16" John 3:16 For God so loved the world, that he gave his only begotten Son, that whosoever believeth in him should not perish, but have everlasting life. $
___________________________________________________________ $0 Web Hosting with up to 120MB web space, 1000 MB Transfer 10 Personalized POP and Web E-mail Accounts, and much more. Signup at www.doteasy.com
Frank D. Engel, Jr. wrote:
Correct, those are not features of Ada. Ada *does* have features like AND THEN and OR ELSE (like GPC's AND_THEN, OR_ELSE),
But these are not Turbo Pascal features, but Extended Pascal.
and a number of really cool features that are not even part of GPC to my knowledge.
Probably.
Ada *does* have type casts, but they are neither 'unchecked' nor arbitrary.
I thought so. So they're not quite like TP's type casts.
Ada also supports exceptions, and a somewhat strict variation on inheritance using extensible records:
type oldRec is record oldField : Integer; end record;
type newRec is new oldRec with record newField : Integer; end record;
(newRec will have two fields: oldField and newField).
OK, that's quite similar to TP's objects (without the methods).
Frank
Frank Heckenbach wrote:
Rick Engebretson wrote:
Many of the features turbo pascal introduced, that "vanilla" pascal lacked, are part of Ada95
I don't know Ada very well, but I doubt that. Especially the TP features are often characterized by type-unsafeness and similar issues. Since Ada's main goal is to be strongly typed and safe at runtime, I can't really imagine they added things such as unchecked type-casts, "absolute" variables, assembler statements and machine code inlines, low-level memory access (FillChar, Move), misusing constants as variables, confusion between pointers and arrays and sometimes single elements and arrays etc., to name just some of the most problematic ones.
Conformant arrays are a GPC addition to pascal.
Not at all. Conformant arrays are a feature of both Pascal standards (ISO 7185 and 10206) at "level 1". Some other compilers don't implement them, though.
Frank
I don't believe Ada was ever intended as a general purpose, commercial, programming language. But the pascal syntax, and the evolution of new capabilities closely resembles the dos pc product "turbopascal." That was all I was trying to say.
Further, before GPC, pascal conformant arrays were not available to me AFAIK.
Rick.
On 1 Feb 2005 at 20:56, Rick Engebretson wrote:
I don't believe Ada was ever intended as a general purpose, commercial, programming language.
From the "Rationale for the Ada Programming Language:"
"Ada is a modern programming language suitable for those application areas which benefit from the discipline of organized development, that is, Software Engineering; it is a general purpose language with special applicability to real-time and embedded systems."
and:
"Although Ada was originally designed to provide a single flexible yet portable language for real-time embedded systems to meet the needs of the US DoD, its domain of application has expanded to include many other areas, such as large-scale information systems, distributed systems, scientific computation, and systems programming. Furthermore, its user base has expanded to include all major defense agencies of the Western world, the whole of the aerospace community and increasingly many areas in civil and private sectors such as telecommunications, process control and monitoring systems. Indeed, the expansion in the civil sector is such that civil applications now generate the dominant revenues of many vendors."
Reference:
http://www.adaic.org/standards/95rat/RAThtml/rat95-p1-1.html
-- Dave
J. David Bryan wrote:
On 1 Feb 2005 at 20:56, Rick Engebretson wrote:
I don't believe Ada was ever intended as a general purpose, commercial, programming language.
From the "Rationale for the Ada Programming Language:"
"Ada is a modern programming language suitable for those application areas which benefit from the discipline of organized development, that is, Software Engineering; it is a general purpose language with special applicability to real-time and embedded systems."
and:
"Although Ada was originally designed to provide a single flexible yet portable language for real-time embedded systems to meet the needs of the US DoD, its domain of application has expanded to include many other areas, such as large-scale information systems, distributed systems, scientific computation, and systems programming. Furthermore, its user base has expanded to include all major defense agencies of the Western world, the whole of the aerospace community and increasingly many areas in civil and private sectors such as telecommunications, process control and monitoring systems. Indeed, the expansion in the civil sector is such that civil applications now generate the dominant revenues of many vendors."
Reference:
http://www.adaic.org/standards/95rat/RAThtml/rat95-p1-1.html
-- Dave
Please include the full context of my earlier comments, or don't quote me at all.
Perhaps missile guidance systems will indeed soon be available at Wal-Mart. But I knew some of the originators here in Minnesota, and I know that was not their intent. Rick.
On 2 Feb 2005 at 15:29, Rick Engebretson wrote:
Please include the full context of my earlier comments, or don't quote me at all.
The entire text of your comment in the message I quoted was:
I don't believe Ada was ever intended as a general purpose, commercial, programming language. But the pascal syntax, and the evolution of new capabilities closely resembles the dos pc product "turbopascal." That was all I was trying to say.
Further, before GPC, pascal conformant arrays were not available to me AFAIK.
Rick.
I was only addressing your mistaken belief in the first sentence. I had no comment on your other statements.
Perhaps missile guidance systems will indeed soon be available at Wal-Mart.
Undoubtedly.
But I knew some of the originators here in Minnesota, and I know that was not their intent.
Odd that it's stated in the Rationale then.
-- Dave
J. David Bryan wrote:
On 2 Feb 2005 at 15:29, Rick Engebretson wrote:
Please include the full context of my earlier comments, or don't quote me at all.
The entire text of your comment in the message I quoted was:
I don't believe Ada was ever intended as a general purpose, commercial, programming language. But the pascal syntax, and the evolution of new capabilities closely resembles the dos pc product "turbopascal." That was all I was trying to say.
Further, before GPC, pascal conformant arrays were not available to me AFAIK.
Rick.
I was only addressing your mistaken belief in the first sentence. I had no comment on your other statements.
Perhaps missile guidance systems will indeed soon be available at Wal-Mart.
Undoubtedly.
But I knew some of the originators here in Minnesota, and I know that was not their intent.
Odd that it's stated in the Rationale then.
-- Dave
If I recall, I started two threads on the GPC mail list.
The first thread was to suggest IWidgets to provide GPC users a versatile IDE.
The second thread was to ask for some supervision of OpenGL bindings to GPC.
In between I encouraged the National Cancer Institute to stick with GPC.
If you are interested in working with IWidgets to set up an IDE for GPC, I will be delighted to work with you.
If you are interested in creating bindings for OpenGL to GPC, I will be delighted to work with you.
Otherwise: SEGMENTATION FAULT .
Rick.
On 1 Feb 2005 at 19:59, Frank Heckenbach wrote:
...I can't really imagine they added things such as unchecked type-casts...
Yes. See "Unchecked Type Conversions":
http://www.adaic.org/standards/95lrm/html/RM-13-9.html
..."absolute" variables...
Yes. See "Operational and Representation Attributes" (specifically, the "Address" attribute in paragraph 11):
http://www.adaic.org/standards/95lrm/html/RM-13-3.html
...assembler statements and machine code inlines...
Yes. See "Machine Code Insertions":
http://www.adaic.org/standards/95lrm/html/RM-13-8.html
...low-level memory access (FillChar, Move)...
No, although one could write such a procedure with the above.
...misusing constants as variables...
No.
...confusion between pointers and arrays and sometimes single elements and arrays...
No.
-- Dave
Tom Schneider a écrit:
Maurice:
Strange. doing the same on DJGPP (W98se DOS box) with gpc 20041218 based on gcc 3.2.3 behaves as expected.
Hmm. I don't understand why it would be an issue on a Sun!
Neither I. But we do such cross-check on a different system each time an user reports a bug, to try to see if it is truly a gpc bug, or some other problem due to peculiarities of the user's system (or gpc version).
All is done manually with suitable tools to binary visualize the true content of files, no shell scripts or functions which could be too intelligent (I have bash, no tcsh) and hide something "unimportant", for example no linefeed or ^Z (a DOS nicety on text files) added at the end.
The script demonstrated in three ways that the files had zero length.
Still please do the cross check. I have no Sun at hand do do it, and may be nobody in this list has exactly the same system. I know nothing on the inners of the Sun file system, whether it stores somewhere the fact that this is a binary or a text file, if the file length is obtained by looking truly to the file content, or to some information on the length stored somewhere outside of the file, etc. In DOS systems when running scandisk, you find sometimes an error message like "file length as reported by the system is different from the true file length"
Maurice
-
Frank D. Engel, Jr. -
Frank Heckenbach -
J. David Bryan -
Maurice Lombardi -
Rick Engebretson -
Tom Schneider