Gpc

gpc@gnu.de

5400 discussions

boolean functions as conditions
by Artur Kornilowicz 17 Sep '04

17 Sep '04

Hello, I think gpc does not work properly when one gives a boolean function as a condition in repeat until loop. Please find an example below. I tested it on 2 different machines working under Linux and Darwin. When you change repeat until F1(a,b); by repeat x := F1(a,b); until x; in procedure F2, then it works. Greetings Artur program tester; function F1(a,b : string):boolean; begin writeln('F1(',a,',',b,')',length(a),' ',length(b)); F1:=true; end; procedure F2(a,b : string); begin // writeln('F2(',a,',',b,')',length(a),' ',length(b)); //not necessary //when you add above, below works repeat until F1(a,b); //incorrect result repeat until F1('3','3'); //correct result //not necessary end; var c: string; //not necessary begin c:='1'; //not necessary repeat until F1(c,c); //correct result //not necessary F2('2','2'); end. Remarks: a) to have smaller example you can delete all lines with comment "not necessary" at the end of the line. b) when F1 and F2 have only one parameter they seem to work. Outputs: Mac, Darwin Version: gpc 20030830, based on gcc-3.3.2 F1(2,1)1 1 F1(2,)1 1 // why the second printing is empty? F1(2,1)1 1 Intel, Linux gpc 20040516, based on gcc-3.3.1 artur@alioth:~> ./a.out F1(1,1)1 1 Segmentation fault artur@alioth:~>

4 3

Re: GPC: daily digest V1 #541
by Tom Schneider 13 Sep '04

13 Sep '04

Frank Heckenbach wrote: > It may be natural for some. I actually prefer it the way it is, i.e. > I prefer to use the same spelling (capitalization) throughout. So if > you or someone else implements the other way (which is indeed more > work), it should at least be optional. What you prefer is not representative of what others prefer. Testing for case matching is already optional, given that there is a flag. > BTW, calling it a bug is a bit strange, anyway. In Pascal, even > occurrences of an identifier referring to the same declaration can > have different capitalizations; the same applies to different > declarations (e.g., local vs. global) as well. Therefore, all this > is an optional warning, not an error. It is not a Pascal bug in the sense that the program will still compile correctly since Pascal accepts any capitalization. However, it is a bug in GPC in the sense that the compiler treats the variables inconsistently. FUnCtiOnaLLy iT dOEs nOt MATteR, but for consistency it does. Frank Heckenbach wrote: > Waldek Hebisch wrote: > > I belive that capitalization is meaningfull for people. > I don't really. In natural language, capitalization is used as a > help in reading (used differently in different languages), but it > does not carry meaning itself (e.g., a text written in all-caps > still has the same meaning). It carries meaning to PEOPLE but not to the compiler (for the purpose of creating a binary). Especially in German it means that the word is either the beginning of a sentence or a noun, right? Are there cases in German - I bet you could find or make some! - where the meaning of the sentence changes dramatically if you were to change the case of a noun? This was discussed earlier, here's an example http://www.gnu-pascal.de/crystal/gpc/en/mail7664.html where in 2003 (!) Russell Whitaker wrote: > Irregardless of either Case Checking or Warning messages, I would like > to see the compiler output identifiers exactly as they appear in the > offending source line. As it is now the compiler outputs 'Gothere' when > the source could have been either 'gotHere' or 'goThere'. > (bad pun intended). Got Here is quite different from Go There! So the capitalization within a single identifier name CAN carry meaning. A person wanting to use both of these would be FLABerGASted that they could not. (Sorry about that, it just apPEARed and now you've got me going!). > - Short identifiers such as `x' vs. `X'. These names are not > actually meaningful anyway. No. X could represent Xavier, Y could be Yanni. > Tom Schneider wrote: > http://www.lecb.ncifcrf.gov/~toms/delila/module.html > ftp://ftp.ncifcrf.gov/pub/delila/moddef A point I forgot to mention is that, of course, using the module program I transfer chunks of text between programs. The current rules force me to have a single way of capitalization. FOR EXAMPLE. I am a molecular biologist, so the letters A, C, G and T have great significance. In some programs I might want to capitalize these to fit the convention in molecular biology. But in another piece of the code I may decide that 'c' is to be the name of a character read in. These would be distinct uses with different scopes. But the GPC compiler demands that I use the same rule for both. Essentially that means that I should forget about capitalization entirely or have my arm twisted every once in a while. Irrelevant warnings that I can't get rid of make it MUCH more difficult to locate the important warnings! The difficulty came up when I was preparing my 200-some programs for other people. When they compile the code they will trip over EVERY unnecessary warning. They will write me email every time, wondering what is wrong. I just got some! I would have to tell them not to worry about that. But in case there is a REAL problem, I have to check every time ... Worse, if one of my students decides to write code, I have to worry about what they have done in modules that I'm NOT working on. Suppose I ask them to write a procedure for me and they pick a "non-standard" capitalization that doesn't match something I'm doing? Or suppose I want to use a sorting routine from someone else? I should be able to plug their procedure or function into my program and have it run without warnings. Saying that I should use external files is NOT A SOLUTION because there is no standard that all compliers use for reading such files and if I used that approach, I would have to keep modifying code to switch compilers. I (and you now) already have the system-independent module transfer mechanism so there is no reason to go back to system-dependency. (GPC is essentially a system dependency since there are other compilers that exist. But, by the way, I'm going for using GPC as my main compiler now thanks to all of you folks and because the Sun Pascal compiler has been dropped.) Tom Verhoeff wrote: > I recently recompiled a project containing some seven thousand lines > of Pascal code distributed over some twenty units. A couple of years > ago when it was last compiled, gpc didn't have the identifier-case > checking feature. During the recent recompile, I was overwhelmed with > casing complaints. Some of them were legitimate: same variable referred > to by different casings. And I changed the source accordingly. But many > warnings were completely unexpected for me, and unwarranted. This is similar to what happened to me. I just upgraded from the 1999 version of GPC to 2004 and suddenly had hundreds of WARnings. (Using capitals in varIouS odd ways in a sentence could be an art form to create double MEANings.) Waldek Hebisch wrote: > 3) Many tools are easier to use as case sensitive ones (simple example > is global regex search&replace) Yes. This is why the GPC convention of capitalizing the first letter of an identifier when giving errors or warnings is painful. One can't use the capitalization. Indeed, the error/warning should always be using the current capitalization string! (This is a separate issue from the scope problem, but it also trips me up repeatedly since I like to use cut and paste to do searches in vi/vim.) > > The compiler already keeps track of scope for each variable. So > > keeping one copy of an identifier just (apparently) reveals > > Again: The warning is about *identifiers* (including keywords > actually), not about *declarations* (and it doesn't claim > otherwise). Fine. Any constant, type, variable, procedure, function name ... Frank Heckenbach wrote: > > that the > > GPC code is not efficient. > > Not really. This way, the capitalization can be checked right after > a word (identifier or keyword) is recognized. When doing it after > distinguishing between keywords and various kinds of declarations, > there would be more places to add the checks. You of course know the compiler guts and I don't. But what you are saying implies that the mechanisms for capitalization checking and scope checking are separated. In that sense the compiler appears not to be efficient. Frank Heckenbach wrote: > > In other words, the warning code could > > (should!) use the code already used for tracking the scope. > > As I said, I prefer to check the capitalization of identifiers. If > you prefer to check the capitalization of declarations, go ahead and > implement it (optionally). It's free software. But please contact > Waldek before about the details to avoid conflicts with his > qualified identifier changes. It's a matter of doing it right. I am not the best person to do this as I have not written the code in the first place. Frank Heckenbach wrote: > Because I don't see a "case sensitive interpretation" of Pascal > code. > > There may be other Pascal compilers which are case-sensitive, which > is obviously non-standard. Our general attitude to non-standard > compilers is to be at best backwards-compatible, which this warning > surely makes it. If there were (theoretically) a compiler that understood case with scope correctly, then this current design would not be compatible. Frank Heckenbach wrote: > > I recently recompiled a project containing some seven thousand lines > > of Pascal code distributed over some twenty units. A couple of years > > ago when it was last compiled, gpc didn't have the identifier-case > > checking feature. During the recent recompile, I was overwhelmed with > > casing complaints. Some of them were legitimate: same variable referred > > to by different casings. > > Again, Pascal isn't concerned with the capitalization of identifiers > referring to the same declaration any more than it is with that of > identifiers referring to different declarations. If you consider one > thing more "legitimate" than the other, that's your opinion, but > please don't state it as a fact. No, he means that some of the warnings were appropriate and some were not, according to the scope of the variable. The inappropriate ones get in the way of finding the legitimate ones. Frank Heckenbach wrote: > Well, I was about to write "these comparisons go too far" before I > read this paragraph, but now it's really too much! Emotions in a > Pascal program, eh? ;-) EMOTIONS ARE USED IN TEXT! (SorryForYelling.) Haven't you ever embedded something like that into your code? Frank Heckenbach wrote: > Let's stick to Pascal based arguments, perhaps? This is NOT a "Pascal" issue. It is a GPC issue. I think that we all agre that in the language Pascal itself, case is not relevant. The issue here is about programmers and what happens when they attempt to use capitalization to help them understand AND DOCUMENT the code better. If the capitalization does not follow the scope rules of the identifiers, then the programmer will OFTEN have trouble. Frank Heckenbach wrote: > > You forgot: > > - NamesConsistingOfMultipleWords (most frequent in my experience) > True. But using different concatenations resulting in the same > identifier (such as `FooBar' and `FoobAr' -- I know there are real > examples of this, I just don't have them in mind right now) is There's the case I mentioned above: http://www.gnu-pascal.de/crystal/gpc/en/mail7664.html Frank Heckenbach wrote: > asking for trouble in a case-insensitive language. In C, you can do > this and get away with it. In Pascal, sooner or later, you might use > those names in the same scope and get a conflict. No. If they are within the same scope, then there SHOULD be a conflict. Frank Heckenbach wrote: > So even here, I > prefer the current behaviour which warns me as soon as possible and > lets me choose another name for one of the things. No, that forces one to have a uniform capitalization scheme across the program. Then, for me and my students, we must have one across my lab. If I send you procedures, then you must follow OUR scheme. So ultimateLy, to avoId conflicTs, yOu muSt follOw oUr capitalizatiOn scheMe, whiCh, In thIs sentenCe, Is To capitaliZe tHe secoNd To laSt charactEr Of eveRy woRd ;-0. Frank Heckenbach wrote: > > - conventions like: > > globals capitalized, locals lowercase > > or > > agregates capitalized, scalars lowercase > > IMHO these are archaic conventions, coming from languages such as C > (where there's only one global and one local level, in contrast to > Pascal which has arbitrarily many levels, and a local variable of > level 1 can behave like a global variable, seen from a routine at > level 2, etc.), and assembler (where there's a general difference > between aggregates and scalars). So I don't care much for such > conventions. That misses the point. Within a chunk of code it may be appropriate to use a particular convention. The code that I was working on that started this discussion uses a series of X and Y variables to create a color density plotting program: http://www.lecb.ncifcrf.gov/~toms/delila/denplo.html using: cat denplo.p |\ wordlist |\ egrep 'X|Y' |\ sort |\ uniq |\ fmt |\ cat I got the variables: SymbolSizeX SymbolSizeY X XDisplayIntervals XDisplaySubIntervals XaxisLabel Xbin Xbinmax Xbinmin Xcolumn Xcorner Xhi Xin XinCount Xintervals Xlo XmaxValue XminValue Xminvalue XoutCount Xrange Xsize Xvalue Y YDisplayIntervals YDisplaySubIntervals YaxisLabel Ybin Ybinmax Ybinmin Ycolumn Ycorner Yhi Yin YinCount Yintervals Ylo YmaxValue YminValue Yminvalue YoutCount Yrange Ysize Yvalue graphXintervals graphYintervals jumpX jumpY keyX keyXsize keyY keyYsize nextX nextY shiftX shiftY shrinkfactorX shrinkfactorY startX startY tryX tryY As you can see from looking over this list, the X and Y capitalization really helps to distinguish the variables. It was very good that the compiler detected these (THANK YOU) as it allowed me to straighten out some incorrect ones. The convention helps me to tell which are the X and Y variables. The collision was with a lower case x and y nicely scoped into local variables in a procedure. To avoid other users of the code getting the inappropriate warning (and sending me email about it!), I was forced to change them to capitals. Frank Heckenbach wrote: > > And we should divide programmers into two groups, one that does not > > care about capitalization and the second that cares. The first group > > produces lot of meaningless variation, but they are irrelevant for > > the discussion since they wish no warning. The second group IMHO > > is much more likely to associate meaning with capitalization. > > So do I, yet I prefer to avoid different capitalizations of the same > identifier (see above). That's fine, but it does not suit everyone, and you apparently haven't run into a condition where there would be a conflict. Frank Heckenbach wrote: > So is the lack of `endif', and a few other things IMHO. We can't > change the fundamentals of Pascal, I'm afraid. Agreed! But this discussion is not about changing the fundamentals of Pascal. It's about changing how GFP reacts to case inconsistency when it is requested to check for case consistency. Programmers will expect the case usage to match the scope of the variable. Regards, Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Molecular Information Theory Group Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/ ps: Sorry if I messed up some of the attributions!

3 3

Re: GPC: daily digest V1 #540
by Tom Schneider 11 Sep '04

11 Sep '04

Waldek Hebisch wrote: > Note that your program consted of a single module (in other words it > contained just main program, without EP modules or units). I started writing in Pascal years before GPC and my programs have survived transition through four different Pascal compilers. When I started the CDC Pascal compiler had an insertion mechanism. I soon realized that this would cause me trouble in giving my programs to others, so I wrote a program in Pascal that does code insertion: http://www.lecb.ncifcrf.gov/~toms/delila/module.html Since I pass most of my programs through this one, it had better be reliable, so I wrote a definition before writing the program: ftp://ftp.ncifcrf.gov/pub/delila/moddef So modules are nice, but would trap me into a particular compiler. My module program avoids system dependencies. Result: code written 20 years ago still runs. > The compiler internally keeps only one copy of given identifier -- > the meaning changes according to the scope, but there is only one > place to store the spelling. It is natural to take scope rules into > account when warning about capitalization, but that requires extra > work. The compiler already keeps track of scope for each variable. So keeping one copy of an identifier just (apparently) reveals that the GPC code is not efficient. In other words, the warning code could (should!) use the code already used for tracking the scope. (I say this without looking into the code GPC itself, but it seems to be a reasonable inference.) Yes, it would take more work to do it right. But I suspect that the end result will be very pretty and highly robust. Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Molecular Information Theory Group Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/

1 0

GPC downloads are confusing
by Tom Schneider 09 Sep '04

09 Sep '04

Folks: We just upgraded to v. 2.1 (20020510). It turns out that this is the intermediate version that has a bug with the page() function. I handle this in my compile script by turning off the demand for standard Pascal, which leaves me slightly vulnerable to non-standard things creeping into my code by accident. On http://www.gnu-pascal.de/current/ is gpc-20020510.tar.gz which I think my sysadmin used. But that page also has gpc-2.1.tar.gz which seems to be more recent. With such odd naming schemes, one can't tell which is the most recent though. I downloaded both and they are identical!!! HUNH???? That is, they unpack to be directories that contain exactly identical files (by diff -r). This download page is quite confusing. If they are the same, how about explaining it on the page? How about getting rid of one? Also, these seem to be from the year 2002. It's two years later. Aren't there more recent snapshots? The page does not give help about this. Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Molecular Information Theory Group Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/

3 2

Mac OS X Pascal Interfaces for GNU Pascal
by Adriaan van Os 09 Sep '04

09 Sep '04

Peter N. Lewis and Gale Paeper have been working hard on the Mac OS X Pascal Interfaces for GNU Pascal. The results are impressive: - added 59 new units, to a total of 268 units and 197731 lines of Pascal - added CFSTR support - added support for four char code constants - added compatible Interfaces for MetroWerks Pascal. The software can be downloaded from <http://www.microbizz.nl/gpc.html>. Detailed release notes are included. Regards, The Mac OS X Pascal Interfaces team: Peter N. Lewis <peter(a)stairways.com.au> Gale Paeper <gpaeper(a)empirenet.com> Adriaan van Os <gpc(a)microbizz.nl>

6 9

A bug in passing strings by value
by Adam Naumowicz 07 Sep '04

07 Sep '04

Hi, I've just noticed that there is a bug in the string assignment if a string is passed by value to a procedure and then assigned to. See the excerpt below, the length of "a" after the assignment is still 1. I'm using: adamn@linux:~/pascal/bug/gpc>gpc -v Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/specs Configured with: ../gcc-3.3.1/configure --enable-languages=pascal Thread model: posix gpc version 20040516, based on gcc-3.3.1 --------------------------- program string_value_bug; procedure P(a:string); begin a:='BC'; writeln('a=',a); end; begin P('A'); end. --------------------------- Best, Adam Naumowicz ====================================================================== Department of Applied Logic fax. +48 (85) 745-7662 Institute of Computer Science tel. +48 (85) 745-7559 (office) University of Bialystok e-mail: adamn(a)mizar.org Sosnowa 64, 15-887 Bialystok, Poland http://math.uwb.edu.pl/~adamn/ ======================================================================

2 3

mySQL
by Adriaan van Os 24 Aug '04

24 Aug '04

From <http://www.gnu-pascal.de/contrib/eike/> I downloaded GPC interfaces to mySQL, contributed by Eike Lange - thanks Eike for contributing them. With some necessary changes, I got things working on Mac OS X. > { This unit interfaces MySQL libs. > Copyright (C) 2003 by Eike Lange > Author: Eike Lange <eike(a)g-n-u.de> > > This unit is free software; you can redistribute it and/or modify > it under the terms of the GNU Library General Public License as > published by the Free Software Foundation, version 2. I don't think full copyright can be claimed, because the Pascal interfaces are based on C-headers, copyrighted by mySQL AB. > /* Copyright (C) 2000-2003 MySQL AB > > This program is free software; you can redistribute it and/or modify > it under the terms of the GNU General Public License as published by > the Free Software Foundation; either version 2 of the License, or > (at your option) any later version. Now, we have an "original work" copyrighted by MySQL AB and licensed under the GPL, plus a "new work" based on the "original work" copyrighted partly by Eike Lange and licensed under the LGPL. (sigh) From a lawyers point of view - I don't think that this is all correct. From a programmer's point of view - Please (!) don't introduce unneeded copyright claims in interface files, except as needed to respect the original works. With all respect for the GPL and the LGPL, I would argue strongly that Pascal interface files be left uncopyrighted. Regards, Adriaan van Os

4 13

GTK-unit
by David Righart 21 Aug '04

21 Aug '04

Arpa Intrabouw I am using Cygwin GPC version 20030830 and Red Hat Linux GPC version 20030830. Last week I downloaded GtkUnits-20010602.tar.gz from Nicola but I can't compile it. The tag asmname is used in the units which I replaced with external name. Does the tag asmname not work with GPC? Now, the linker is complaining with errors. Maybe the units are to old to use with this version of GPC? Is there a newer version of GPC GTK-units? Can anyone help me using Gtk under GPC?? Regards, David.

3 2

Dev Pascal (Bloodshed)
by Ian Miller 14 Aug '04

14 Aug '04

Hi, I know this isn't strictly a GPC question, but I thought someone here might be able to help with this: I recently installed the following version of Dev Pascal from gnu-pascal.de, under Windows XP:- Dev+GNU Pascal 1.94.2 + GPC 20040516 + Mingw runtimes + GCC support files (9.8mb: Win32 GUI self-extracting installer; 29 May 2004) The problem I am getting is that I am not able to click on compilation error message in the Compiler window at the bottom to take me to the corresponding line in the source. Also, sometimes, error message produced by the compiler are not even reproduced in the Compiler window. I suspect that this is because the IDE is not correctly parsing the compiler output and so does not actually know the location of the error. e.g. here is a Compiler window output with errors: Line/ ... | Unit | Message | f | Project2.pas:3: (Each undeclared identifier is reported only once | f | Project2.pas:3: for each routine it appears in.) | f | Project2.pas:3: undeclared identifier `y' (first use in this routine) | f | Project2.pas:5: syntax error before `:' As you can see, the line number of the error is clearly visible in the Message column, but not in the Line column! (This was for compiling a console application, btw). Of course, this isn't much of a problem to a seasoned programmer, however, I would like to use this IDE for a college course teaching Pascal to complete beginners and so it would be extremely useful if this feature worked properly. Any advice (including alternative IDEs for standard non-extended Pascal) most appreciated. cheers, ian

4 7

Stabs and line-numbers
by Adriaan van Os 13 Aug '04

13 Aug '04

I were doing some tests with SLINE line-numbers in stabs debugging info and it appeared to me that line-numbers in gpc version 20040516 (based on gcc-3.3.2) are less accurate than they were in gpc version 20030830 (based on gcc-3.3.2). Maybe there have been changes to the parser ? I could give a detailed example of course, if needed. Regards, Adriaan van Os

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc