Gpc May 1999

gpc@gnu.de

25 participants
69 discussions

Re: Two GNU Pascal ideas
by Frank Heckenbach 12 May '99

12 May '99

Peter Gerwinski wrote: > > 3. Have some extension to indicate C linkage (like C++ and > > some C compilers do). Maybe an extension or alternative > > to the EXTERNAL keyword. > > This already exists. See `info -f gpc -n "Other languages"'. > > Procedure Foo; C; (* extern void foo ( void ); *) > > Procedure FooBar; asmname 'FooBar'; (* extern void FooBar ( void ); *) I should mention that we're thinking about changing the syntax of external declarations and the internal names of Pascal identifiers soon. In order to allow the same identifier in different units/modules (which is required by both the Standard and Borland Pascal and which GPC currently doesn't support), we need to change the "name mangling", anyway. Instead of "Foobar" for an identifier `FooBar' declared in a unit/module `Baz', we could probably use `baz.foobar' (or `baz$foobar'), all lower-case, without risking name clashes with the libc. For the external declarations, my suggestions is: Procedure Foo; external; (* extern void foo ( void ); *) (I.e., `external' will convert the name to lower-case, without the module name prefix.) Procedure FooBar; external name 'FooBar'; (* extern void FooBar ( void ); *) I've heard Delphi has something like this (`external' and `name'). Is it the same syntax, or what does it look like in Delphi? BTW, we could then also have: Procedure FooBar; name 'FooBar'; begin end; to declare a Pascal procedure with a given internal name, instead of the "strange" form that is now necessary: Procedure FooBar; asmname 'FooBar'; Procedure FooBar; begin end; These are just ideas right now. Any comments? Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Interested about GNU Pascal development
by GrimReaperX 12 May '99

12 May '99

Hi, I am a 19 years old college student. I study programming. I like Linux/Unix* alot because of the open-source concept and also because these OS are highly configurable and customizable. I run RedHat 5.2 on a i386 machine (Pentium 166MhZ, 48MB ram) and If you need to traduct english-to-french or french-to-english feel free to ask me :) I can also do alpha/beta testings. This far, my teachers only showed us the basics of Pascal (Console..) and some C. But as my studies advances I will get better. In fact, I am willing to do whatever I can to help Linux/Unix*/GNU to grow. (Little anger toward microsoft....well let's rather say some hatred ;) reboot-reboot reboot) I live in Quebec, Canada. Cya soon! Pierre-Luc Vincent a.k.a. GrimReaperX grimreaperx(a)usa.net

3 3

Re: prior parameter's size depends on `foo'
by Frank Heckenbach 12 May '99

12 May '99

David James wrote: > There may well already be a provided routine to do this (return the > last i characters of a string), and if there is, I'd be grateful for > a pointer to it, but even so I think I'd still like to be able to > write similar procedures/functions. The functions `Copy' and `SubStr', when called with 2 parameters s and i, return all the characters of s starting from the i'th. The difference is that `SubStr' causes a runtime error when i < 1 or i > Length (s), while `Copy' returns the empty string then. So, to get the last i characters of s, you can use `Copy (s, Length (s) - i + 1)', or if you want to accept i > Length (s) here and get the whole string then, you could do `Copy (s, Max (1, Length (s) - i + 1))'. Peter Gerwinski wrote: > * In this example we are mixing Extended Pascal modules with > UCSD (Borland) Pascal units. EP wants `import' instead of > `uses'. > > While GPC accepts all this, it is maybe better to stick to one > flavour of modularized Pascal programming which means either > EP-style modules or UCSD-style unit, but not a mixture. He did `uses gpc;' which is correct since gpc.pas is indeed a unit (and is not available as a module). So I think it's alright to mix this unit with modules. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: prior parameter's size depends on `foo'
by david＠tcs01.demon.co.uk 11 May '99

11 May '99

In message <19990511213235.C1105(a)esmeralda.gerwinski.de> Peter Gerwinski writes: > > You probably stumbled about a bug in GPC. > > To help us to fix GPC it would be best if you reduced the > problem to a program `david1.pas' which > > * is as short as possible, > > * reproduces the bug, > > * and is intended to writeln 'OK' if no bug > occured and something else otherwise. The problem is at compile-time, attached is a small module which exhibits this behaviour. My system is Red Hat Linux release 5.2 (Apollo) running kernel 2.0.36 on an i586. I've built gcc-2.8.1 and gpc 19990118. gpc -v gives the following output ----------------------------------------------------------------- Reading specs from /usr/lib/gcc-lib/i586-pc-linux-gnu/2.8.1/specs gpc version 19990118, based on gcc-2.8.1 ----------------------------------------------------------------- Compiling the following module with gpc -c dajmod.p gives the output shown below file dajmod.p: ----------------------------------------------------------------- module dajmod1 interface; export dajmod = (str_tail); procedure str_tail(protected source:string;protected i:integer;var dest:string); end. module dajmod1 implementation; uses gpc; var s1,s2:string(255); i:integer; procedure str_tail; var s2:string(255); begin (*str_tail*) if (length(source)=0) or (i<1) or (i>length(source)) then dest:='' else begin moveleft(source[length(source)-i+1], s2[1], i); (*$x+*) setlength(s2,i); (*$x-*) dest:=s2; end; end; (*str_tail*) end. ----------------------------------------------------------------- Output from compiler: dajmod.p: In function `Str_tail': dajmod.p:9: prior parameter's size depends on `Source' ----------------------------------------------------------------- There may well already be a provided routine to do this (return the last i characters of a string), and if there is, I'd be grateful for a pointer to it, but even so I think I'd still like to be able to write similar procedures/functions. -- David James mailto:david@tcs01.demon.co.uk

2 1

Re: Fw: gcc-19990330
by Frank Heckenbach 11 May '99

11 May '99

J. David Bryan wrote: > > > > p.s. think "Trim" should trim both spaces and tab chrs > > > > ( now only spaces) low priority wish list > > > > What does the standard say about this? (`Trim' is a predefined > > function of the standard, so we have to care about the standard > > here.) > > Section 6.7.6.7 (String functions) in ISO 10206 (Extended Pascal) says for > "Trim": > > ...the function shall yield the value of substr(sv,1,p-1), where p is > the least value in the closed interval 1..n such that each component of > sv[p..n] is the char-type value space. > > So "Trim" only trims spaces. > > > > Alternatively (if the standard wants only spaces), we could also make a > > different routine for spaces and tabs... > > A different function would be the proper implementation. I just noticed that the (non-standard) GPC procedures TrimLeft/TrimRight/TrimBoth and the equivalent functions TrimLeftStr/TrimRightStr/TrimBothStr do trim both spaces and tabs. So I suppose they can be used here. Or are there any votes for making them trim only spaces like Trim does? BTW, the same effect (trim all leading "space characters" (spaces and tabs)) could also be realized by: uses GPC; const NoSpaceCharacters = [Low (Char) .. High (Char)] - SpaceCharacters; ... foo := Copy (s, CharPos (NoSpaceCharacters, s)) Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: bash
by Frank Heckenbach 11 May '99

11 May '99

Russ Whitaker wrote: > hi frank > > i'm not a bash expert either: it took me 2 hours to come up with the > following > > enter the following 6 lines of code in a file called test > > #!/bin/sh > if [ $1 = $2 ]; then > echo "ok" > else > echo "oops" > fi > > next, chmod 777 test > then try it: > ./test 1 1 > and > ./test 1 2 > > now go back and change the = to == and try it and you get > > ./test: [: ==: binary operator expected > oops With my bash, it always reacts correctly, regardless whether I call it as `bash' or `sh'. > note: bash is from slakware 3.5 Which version is this (try `bash --version')? Not that it's really important for GPC, but I always like to find out the reasons for problems. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: bash
by Russ Whitaker 11 May '99

11 May '99

hi ls -l /bin/sh gives lrwxrwxrwx ... /bin/sh ->bash bash -version give GNU bash, version 1.14.7(1) guess it's about time for me to update thanks Russ ---------- > From: Nick Burrett <nick.burrett(a)btinternet.com> > To: gpc(a)gnu.de > Subject: Re: bash > Date: Tuesday, May 11, 1999 4:19 AM > > > I tried this with bash 2.02 and there is no problem since = and == are > interpreted the same in this case. > > Are you sure you are executing the script with `bash' and not `sh' ? > The first line would seem to suggest `sh' which may be the cause of > the problem. > > Nick.

1 0

prior parameter's size depends on `foo'
by david＠tcs01.demon.co.uk 11 May '99

11 May '99

I'm seeing the error message "prior parameter's size depends on `foo'" whilst trying to compile an extended pascal module. I'm finding it difficult to strip this down to a really small example which shows the behaviour, but it is associated with a var parameter which is typed as string. Before I spend a lot more time trying to make a very small example of this - anyone have any suggestions as to what I might be doing wrong? -- David James mailto:david@tcs01.demon.co.uk

2 1

Enhancing gdb for GNU Pascal
by Tranter, Jeff 11 May '99

11 May '99

We're looking at using GNU Pascal to replace a proprietary Pascal compiler developed internally. One of the issues with the users is debugging. They would like good source-level debugging capability. GDB seems to work quite well with GNU Pascal but it could be enhanced. I propose to make some changes to it to better support Pascal debugging: - a real Pascal mode, which would be associated with Pascal source file extensions so the debugger would automatically do into Pascal mode when debugging .pas or .p files - evaluation of Pascal expressions (initially I would just copy the modula-2 mode expression parser). The main features here are proper array subscripting and pointer expressions. I plan to add support for sets. - look at making matching of identifiers case-insensitive, so for example, the user could set a breakpoint on a routine called "FOO", "foo", or "Foo" and have it match with what the compiler generated symbol was. - look at allowing the user to set a breakpoint on a program's begin...end block, i.e. have the debugger know that program "FOO" starts at label "program_Foo". Similarly, handle the pseduo-variable used for function return values from the debugger expression evaluator. Currently the user needs to know that for function "FOO" the return value variable is called "retval_Foo". Would these changes be worthwhile? Is anyone already working on them? Are there any other debugging features that would be useful?

2 1

Two GNU Pascal ideas
by Tranter, Jeff 11 May '99

11 May '99

Two thoughts on GNU Pascal to discuss: Based on previous experiences with another Pascal system, one of the most useful features was run-time checking (array bounds, sub-ranges, enumerated types, etc.). This often found problems in code without much effort. It could also be selectively be turned off for efficiency. With GNU Pascal we have C-style run-time checking (i.e. essentially no run-time error checking unless a wild pointer causes some type of exeception). I'm wondering: 1. Would people find this a useful feature for GNU Pascal? 2. Would it be feasible to implement it in the compiler? -------------------------------------- GNU Pascal converts the case-insensitive Pascal identifiers to symbols that are lower-case with the first letter capitalized. This has two implications: - in gdb you need to use the capitalized identifier which is not intuitive to users - you cannot call C routines that do not match the capitalized naming scheme. The first issue can presumably be fixed in the debugger, but the second is more of a problem because I'd like to be able to call C code directly. I can see several approaches to solve this: 1 Make Pascal case sensitive (probably not an option since it would presumably not match the language spec) 2. Convert Pascal symnbols to all lowercase. You could then call C routines if they were all lowercase (which is the most common). 3. Have some extension to indicate C linkage (like C++ and some C compilers do). Maybe an extension or alternative to the EXTERNAL keyword. Note, a side effect of capitalizing all identifiers in the lexical analyzer is that currently the compiler may report an error such as foo.pas:1: parse error before `Error' when the source code actually used the string 'ERROR'.

2 1

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 May 1999