Gpc

gpc@gnu.de

5400 discussions

Re: Variable number of parameters
by Frank Heckenbach 18 Mar '97

18 Mar '97

(Continuation of this thread from c.l.p.b) kblix(a)sn.no (Kim Robert Blix) wrote: > heckenb(a)mi.uni-erlangen.de (Frank Heckenbach) once said: > >> There is NO challange in locating the obstacles - they will become obvious > >> anyway. Try to find a solution instead - Its so much more rewarding. > > > >No, I don't agree. Your approach sounds much like "let's just program a few > >lines, and if it doesn't work, we'll change everything". This ad-hoc strategy > >might work for small projects, but any larger project (of which a Pascal > >compiler is most definitely one), needs some good planning and design before > >starting the actual coding. This includes identifying all the obstacles in > >advance, and finding solutions to them - first a general solution, then a > >concrete way to implement the solution, then verify that the solution really > >covers all situations... It might not be as much fun as just sitting down in > >front of the screen and typing a few lines of code, but it's the only way to > >manage the complexity of such a project. > > Yes, I agree. What I meant was that when this was first presented to the group, > a lot of people started by saying "this cant be done" and "this is not possible" > instead of "this would be hard because of that and that, but could possibly be > solved by this" .. The only constructive replays has come from you. Thanks! But don't forget that the newsgroup is about *Borland* Pascal, and most people are mainly interested in it, and speaking from this perspective. > >But again: be careful with it! C needs it because the language itself lacks > >some features like constants or modularization. However, Pascal - in a > >sufficiently sophisticated version - should not need a preprocessor at all, > >except for things like symbol-dependent compilation. IMHO, it's good style > >to avoid the preprocessor when possible. > > But It can be oooh so practical when needed. :) But there are many traps. Imagine the following: {$define sum a+b} d*sum - this will be d*a+b, i.e. (d*a)+b instead of d*(a+b) as one might expect. or: {$define square(a) a*a} (if sqr wasn't already declared) function f:real; begin {Long and complicated code} end; square(f) - you see what happens? > >> you could just check what the variable was defined as, and then handle it in the > >> appropriate way. this would go for any declared variable. In cases like this: > >> write('this is a number',51) > >> > >> you check if its a string (quoted) or a number (non-quoted). This pretty much > >> includes most cases. > > > >Not quite. Detecting the types is a bit more complex than you might imagine > >now, but it is surely possible - it's one of the important things the compile > >has to keep track of. The difficulty comes in when the compiler has to decide > >between several possible procedures/functions to call (as it can do for > >Write(ln), but is quite more involved for user-defined overloading/varargs). > > Do you have an example where the above approach would fail? You mean the rule: string if quoted, number otherwise? There are many examples: - variables: not quoted, but can be strings, numbers or anything else - function results: the same - expressions (like a+b): the same - constants: the same - ... And dont't forget that there are many other types besides strings and numbers! If you're really interested in how these things works, you'll have to find out a lot about parsing and similar things. > >I think we should carry on this discussion on the mailing list. If you follow > >up, please post there. Anyone else from this group who's interested in this > >subject can subscribe to the list or fetch the postings from its archive, > >with the URLs I posted the other day. > > Argh! :) You could have mentioned that a bit earlier in your post! :) > I'll Jump in and subscribe today. I'd assume you read the whole article before starting to reply... Besides, you could still have posted to the list instead of the newsgroup, I suppose... -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Pascal Compiler Bug
by Gareth Wilson 18 Mar '97

18 Mar '97

Please Read This Text File :-( _____________________________________________________________________ Sent by RocketMail. Get your free e-mail at http://www.rocketmail.com The following code, especially the Arrays, causes GPC1.EXE to page fault. I think this is a bug of the compiler because if I comment them out the compiler runs (complaining about invalid reference to Colours, Cmds, etc.) Type TComStr = String(8); TColStr = String(12); Const NumCmds : Byte = 12; Var Colours : Array[0..15] Of TColStr Value (0 :'BLACK'; 1 :'BLUE'; 2 :'GREEN'; 3 :'CYAN'; 4 :'RED'; 5 :'MAGENTA'; 6 :'BROWN'; 7 :'LIGHTGREY'; 8 :'DARKGREY'; 9 :'LIGHTBLUE'; 10:'LIGHTGREEN'; 11:'LIGHTCYAN'; 12:'LIGHTRED'; 13:'LIGHTMAGENTA'; 14:'YELLOW'; 15:'WHITE'); Cmds : Array[1..12] Of TComStr Value (1 :'@POS('; 2 :'@COLOUR('; 3 :'@CLS'; 4 :'@WAIT('; 5 :'@CURSON'; 6 :'@CURSOFF'; 7 :'@FILE('; 8 :'@LOAD('; 9 :'@SAVE('; 10:'@FILL('; 11:'@SLEEP('; 12:'@SOUND('); Stack trace: Exiting due to signal SIGSEGV Page fault at eip=0003bdbd, error=0004 eax=00000112 ebx=00191ecc ecx=0018db3c edx=00191e38 esi=00182dd4 edi=00000006 ebp=00182cf8 esp=00182cec program=c:/utils/djgpp/bin\gpc1.exe cs: sel=0127 base=100d0000 limit=001cffff ds: sel=012f base=100d0000 limit=001cffff es: sel=012f base=100d0000 limit=001cffff fs: sel=010f base=000165b0 limit=0000ffff gs: sel=013f base=00000000 limit=ffffffff ss: sel=012f base=100d0000 limit=001cffff Call frame traceback EIPs: 0x0003bdbd 0x0003bdee 0x0001b2a4 0x0006fdfa 0x000721e9 0x0011818e Please respond to Gareth_Wilson(a)RocketMail.Com.

1 0

Re: Sockets
by Berend de Boer 18 Mar '97

18 Mar '97

You wrote: >I need to use network sockets from gpc. Can I do this? How? Yes, by writing a module which links in the corresponding c routines. Groetjes, Berend.

1 0

Sockets
by Stephen Lindholm 17 Mar '97

17 Mar '97

I need to use network sockets from gpc. Can I do this? How?

1 0

Re: GPC for the DEC Alpha
by Peter Gerwinski 17 Mar '97

17 Mar '97

According to JanJaap van der Heijden: > I don't know much about the Alpha and GPC related bugs, but I did some work > to build Redhat RPM's for GPC. RPM? What's that? > As you may know, Redhat Linux is available > for iX86, sparc and alpha. The GCC sources from redhat come with a number of > patches to build on the alpha. Anybody who wants to build GPC for > Linux/alpha will have to apply these, probably. Are these patches freely available? If so, we should point to them in the GPC documentation and README files. And in the FAQ - even more important. > Normally, I would not have > come up with this untill it matured a bit, but since the topic of Alphas has > come up: is there anybody out there running a Redhat Linux/Alpha machine who > would want to test these RPM's on it? The Alpha I have access to does not run Linux. Perhaps somebody else has a Linux/Alpha system? And I am still interested in example programs which trigger those Alpha-with-high-optimization-specific errors, you know. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125]

2 1

Re: gpc and gcc 2.7.2.2
by JanJaap van der Heijden 14 Mar '97

14 Mar '97

At 09:11 AM 3/11/97 +0100, you wrote: >Hi, > >I have install gcc and would like to take 2.7.2.2. >I read that gpc 2.0 is for gcc 2.7.2.1. Is it difficult >to make it work with 2.7.2.2? > Quoting gcc-2.7.2.1-2.7.2.2.diff: "The reason for the 2.7.2.2 release is to add support for GNU C library version 2 on GNU/Linux systems." If you study this (small) patch, you find out that no changes have been made to the compiler internals at all, only minor changes to some config files. So, unless you have a Linux/glibc2 system, I see no need to upgrade from 2.7.2.1 to 2.7.2.2 If you have 2.7.2.2 and want to built GPC with it, just edit Makefile.in and change GCCVERSION to 2.7.2.2. It will not harm GPC since no _real_ changes to GCC were made anyway. Have fun, JanJaap -- "Nothing shocks me, I'm a scientist", Indiana Jones

1 0

Re: GPC for the DEC Alpha
by JanJaap van der Heijden 14 Mar '97

14 Mar '97

At 11:19 PM 3/14/97 +0100, you wrote: >Hi! > >As you know perhaps from the GPC documentation, there are some known bugs >with optimization on the DEC Alpha. Up to now I was not able to hunt >them, but it seems like that I will get access to an Alpha workstation >till 1. November. > >Since I only know that these bugs exist but I don't have a single example >program, I would be glad if the DEC Alpha users among you could send me >their example programs which fail with high optimization levels. > I don't know much about the Alpha and GPC related bugs, but I did some work to build Redhat RPM's for GPC. As you may know, Redhat Linux is available for iX86, sparc and alpha. The GCC sources from redhat come with a number of patches to build on the alpha. Anybody who wants to build GPC for Linux/alpha will have to apply these, probably. Normally, I would not have come up with this untill it matured a bit, but since the topic of Alphas has come up: is there anybody out there running a Redhat Linux/Alpha machine who would want to test these RPM's on it? JanJaap -- "Nothing shocks me, I'm a scientist", Indiana Jones

1 0

GPC for the DEC Alpha
by Peter Gerwinski 14 Mar '97

14 Mar '97

Hi! As you know perhaps from the GPC documentation, there are some known bugs with optimization on the DEC Alpha. Up to now I was not able to hunt them, but it seems like that I will get access to an Alpha workstation till 1. November. Since I only know that these bugs exist but I don't have a single example program, I would be glad if the DEC Alpha users among you could send me their example programs which fail with high optimization levels. Thanks in advance, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Apparent gpc bug
by Peter Gerwinski 14 Mar '97

14 Mar '97

According to Stephen Lindholm: > gpc barfs on this program.[...] > > [...] > > type > TLittleChar = 'A' .. 'C'; Ah - I see. Okay, it's easy to fix: In gpc-parse.y do the following: 8< ---------------------------------------------------------------------------- gpc-parse.y gpc/gpc-parse.y --- gpc-970226/gpc-parse.y Thu Feb 27 11:34:07 1997 +++ gpc/gpc-parse.y Wed Mar 12 19:36:39 1997 @@ -1568,6 +1568,8 @@ subrange_type : constant TWODOTS expression { + $1 = string_may_be_char ($1); + $3 = string_may_be_char ($3); if (PEDANTIC (E_O_PASCAL) && (! TREE_CONSTANT ($3) || ! TREE_CONSTANT ($1))) pedwarn ("ISO 7185 Pascal does not allow non-constant range bounds"); 8< ---------------------------------------------------------------------------- The bug will be corrected in the next alpha release, too. Thanks for the report! Yours, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Pascal's identity
by Peter Gerwinski 14 Mar '97

14 Mar '97

Hi, everybody! Let me just tell you my thoughts about Pascal's identity and the future of GPC. My point is: I need a working GPC as soon as possible to make a living. At the moment, I am programming mostly in Borland Pascal 7.0. But BP7 has no future outside Windows 95, so I want to switch to GPC completely. To me, features which make my programs evolve faster have highest priority. (Of course, actual bug fixes have highest priority, too.) It is desirable to comply to existing standards, but I don't consider this compliance as an end in itself - at least concerning Pascal where very few people know the standard and even fewer are content with it. For example I continue to use BP-style Units although there are EP Modules. I find Units better. (BTW, Units have not been invented by Borland, but they are part of the UCSD Pascal standard.) OTOH, I see the advantages of Schema types, so I want to have them before I start porting my major application programs to GPC (i.e. continue with BO5). For some standard features I don't see their use, but they are hard to implement, so I assign them quite a low priority. This especially applies to some error messages required by the standard, e.g. for unresolved `case'. In case somebody else wants to take care of such things, I would be glad to help him or her to get into GPC hacking. So completing the standard/s does *not* have higher priority to me than to create GPC extensions. (However I will try to do both.) Concerning the purity of Pascal I agree that there are *some* extensions which should at least be warned about unless you explicitly enable them (with (*$X+*) - or with the command-line option "--extended-syntax"). I am speaking of those extensions which could become a trap for beginners. For example, function overloading should be disabled by default because it might confuse a beginner who does not yet know enough about parameter lists. OTOH, I don't see any need for disabling operator overloading by default because you cannot overload an operator unintentionally. For the case somebody does not like GPC to support a mixture of several Pascal dialects, there exist options which enforce a certain standard, including all misfeatures, as far as implemented. For example, the "--borland-pascal" option does not only disable EP Modules, but also the warning about assignment to typed constants. OTOH, the "--extended-pascal" option disables UCSD Units. Both options disable operator overloading. I hope this helps to clarify what direction I intend GPC to go. Suggestions are welcome; actual help to implement things is even more welcome. ;-) Yours, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125]

1 0

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