Gpc

gpc@gnu.de

5400 discussions

Re: Long integers
by Peter Gerwinski 02 Jul '97

02 Jul '97

According to Frank Heckenbach: > > [...] -- or is it an instance of the "cannot write > longint variables" known bug? It is. 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 [970624] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: latest wip
by Peter Gerwinski 02 Jul '97

02 Jul '97

Bill Currie wrote: > > Where can I get the latest WIP version? What's that? > Never mind, just found it (DOH! blind as a bat) :-) 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 [970624] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

latest wip
by Bill Currie 02 Jul '97

02 Jul '97

Where can I get the latest WIP version? I'ld like to see if I can lend a hand. (Couldn't find a reference on the web pages,faq or info docs). Bill -- Leave others their otherness.

1 1

Re: bugs, incompatibity, function attributes
by Peter Gerwinski 02 Jul '97

02 Jul '97

According to The African Chief: > > 1. specifying DLL names; > With Borland, you need to specify the name of the DLL from which > you are importing a function. You need to do this with *every* > function. This is extremely tedious. Try doing that with the whole > Win32 API for example. Also, you would need to find some documentation > on which DLL holds which function. That is even more tedious. Thus, if we > are going to support the Borland syntax, then using it should be optional. > With GPC, you don't need to specify the DLL name - that is, I think, a > *great* advantage over Borland. Or you can specify the DLL name *once* with (*$L foo.a *) or something similar to be implemented. Yes - a great advantage! > 2. not having to redeclare the entire function in the implementation section; > I think it is good to support this. With Borland, you can redeclare the whole > function, or you can just specify it's name. You are not forced to do it in > any particular way, and you can mix and match. It would be nice if GPC > supported this. GPC *does* support this. > 3. Delphi's "name" directive; > This is exactly the same as GPC's "asmname" directive. We can > implement this simply by also allowing just the use of "name" in any place > where "asmname" would be allowed (i.e., we can dispense with the "asm" > part of the "asmname" directive). That way, we get the best of both worlds! Sounds reasonable. So should we just change "asmname" to "name"? Or keep both? 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 [970624] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

Re: Long integers
by Frank Heckenbach 02 Jul '97

02 Jul '97

Peter Gerwinski wrote: > When I have the time :-( I "must" have a look at those pages. Maybe we > can find more interesting ideas for GPC there ... I'm quite sure, actually (though I only took a quick glance at them)! :-) (It'll be interesting to see if gpc's adopting other features can keep pace with new Pascal dialects being developed... ;-) > Schema discriminants must be ordinal types, but the following compiles: > > Type > roots ( p, q: Integer ) > = array [ 1..1 + ord ( sqr ( p ) / 4 - q <> 0 ) ] of Complex; > > However it is useless since > > Var > x: roots ( 4, 4 ); > > crashes GPC. That's what I meant with my "bug report". I didn't check if the type or the var declaration caused the internal error. I just found another bug -- or is it an instance of the "cannot write longint variables" known bug? var c:cardinal value $ffffffff; begin writeln(c) end. ...writes -1. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: Some new features
by Frank Heckenbach 02 Jul '97

02 Jul '97

Peter Gerwinski wrote: > > - Commandline options to specify the directory(ies) > > a) to search for units/modules (source or compiled) > > My current plan is to use the `-L' path/s for this purpose. Yes, why not! (What I'd like best is if it (with "--automake") would look for a source file in the current directory and the "-L" path, and for a compiled module in the "-L" path and the b) path (see below), and if it finds both, compare the dates, regardless where it found them. I think that's how BP does it -- or even a little bit better... :-) > > b) to put compiled modules (.o, .gpi, .gpm) > > c) to put compiled programs (executables). > > \begin{sigh} > Even more options! > \end{sigh} But those are more useful than average, I think... ;-) I, personally, can't stand other files put between my sources, and for executables, there usually exists a separate directory, anyway... > What about extending (*$executable-file-name="foo"*) to accept > a directory? Or else (*$executable-path-name="/foo"*) and > (*$object-path-name="/bar"*)? I don't agree. The *name* of the executable can be considered part of the program. The *path* where it will be stored will be system dependent, so the path, IMHO, does not belong into the source, but on the commandline (or into a (system or user or project specific) config file, of course). > > - Passing the actual size for untyped (resp. void) parameters, so it can > > be access with sizeof. > > This would spoil compatibility to other languages such as C. What about: var x:void -> like C var/const x -> like BP > So perhaps make "Procedure Foo ( Var x )" pass the size, and keep > "Procedure Foo ( Var x: Void )" as it is (i.e. without passing the size)? I was typing too soon before reading this... :-) > Or introduce another data type? Only if necessary. (But I don't see why it would be, since there are already two types and two purposes -- if existing programs with "var x" do rely on C compatibility, those (few, probably) programs should be changed rather than the compiler...) > Okay; I have put it on my list. Fine! :-) And another one: For procedural variables, BP uses "@ProcVar" to cast them into a pointer(!!!). gpc does not understand this, but the (more logical, IMHO) "Pointer(ProcVar)". Unfortunately, BP doesn't accept the latter, so AFAICS there's yet no way that works on both. :-( Since we can't change BP, we should make gpc recognize "@ProcVar", perhaps also only in "--borland-pascal". -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: bugs, incompatibity, function attributes
by Peter Gerwinski 01 Jul '97

01 Jul '97

According to Jan-Jaap van der Heijden: > > Borland does it like this: > > ----------------------------------------- > unit Foo; > > interface > > function Bar(var i: integer): integer; > > implementation > > function Bar; external; > > end. > ----------------------------------------- GPC allows this: Unit Foo; Interface Function Bar ( Var i: Integer ): Integer; external; Implementation end. (Or `attribute', or `asmname' in the Interface part.) However, Borland-comptaible syntax should be supported, too. > Although it accepts the input, GPC doesn't do anything with the > directives. (function attributes not surviving the GPI mechanism is a > long-standing bug, but the "asmname" is silently ignored). It's fixed now. :-) > [...] > GPC has no equivalent for the "DLLfile". > But, if implemented, the automake mechanism could add an option > "-lDLLfile" to the linker command line, something you have to do manually > now. This is useful for all platforms, not just windows DLL's BTW. I agree. > 1. Are there any reasons not to change the "external" declaration, at > least for "borland" mode? This should be done. With what priority? > 2. Any objections against allowing (working, that is) function attributes > in the implementation part? When we want them in the GPI file, they *must* be present already in the Interface part. Greetings, 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 [970624] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Long integers
by Peter Gerwinski 01 Jul '97

01 Jul '97

According to Frank Heckenbach: > > How do you know about PXSC, anyway? Everything I know about PXSC is from one book, "Pascal-SC", in German only, I once have found at our library. I was impressed by the possibilities of exact (!) numerical calculations, and operator overloading. > I did a Yahoo search on "PXSC", and it showed quite a few interesting > things about PXSC (besides a few other things abbreviated by "PXSC" and > several links to gpc pages :-), e.g. PXSC "home pages": > > http://ma70.rz.uni-karlsruhe.de/~ae25/iam/html/language/xsc-sprachen.html > http://wwwma.rz.uni-karlsruhe.de/~ae08/iam/html/language/pxsc.html > > I also learned about even more Pascal extensions, like XL Pascal and > Pascal++ (see > http://www.informatik.uni-halle.de/lehre/pascal/sprache/pas0.html). When I have the time :-( I "must" have a look at those pages. Maybe we can find more interesting ideas for GPC there ... > On a page about BP, I found this remarkable statement: > "Borland is the leader in Object-Oriented Programming, winning more awards > for technical innovation and customer support than anyone else. That means > that when you use Turbo Pascal, you're guaranteed to have the best > development environment available, backed by the best support available. > It's Borland's commitment to you. > [...] > Copyright ) 1995 Borland International, Inc." > Things must have changed very much within 2 years... :-( That's just the problem: They didn't change (read: improve) anything since 2 years and more. > > Think of a schema as a type declaration with parameters which can occur > > anywhere in the declared type: as array or subrange boundaries, or as a > > variant record selector. > > Anywhere??? (roots:array[1..1+ord(sqr(p)/4-q<>0)] of complex;-) Schema discriminants must be ordinal types, but the following compiles: Type roots ( p, q: Integer ) = array [ 1..1 + ord ( sqr ( p ) / 4 - q <> 0 ) ] of Complex; However it is useless since Var x: roots ( 4, 4 ); crashes GPC. Expressions in schemata don't seem to work at all currently. > [long numbers] > > Not really the whole library; multiplying a long number by 10 (or any base) > would be relatively easy to do manually. But you're right, it won't probably > be needed too often, so this little inefficiency of the conversion at runtime > seems tenable... :-) ... except, maybe, if PXSC demands it ...? The compiler would have to deal with expressions formed by such numbers. Better leave this for a library. 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 [970624] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Some new features
by Peter Gerwinski 01 Jul '97

01 Jul '97

According to Frank Heckenbach: > > Here are a few features I'd like to see in gpc. I hope they can be > implemented without much work... > > - Commandline options to specify the directory(ies) > a) to search for units/modules (source or compiled) My current plan is to use the `-L' path/s for this purpose. > b) to put compiled modules (.o, .gpi, .gpm) > c) to put compiled programs (executables). > > (They're similar to some BP options, except that BP uses the same for b) > and c) which I think is a bad idea, so I'd prefer different options.) \begin{sigh} Even more options! \end{sigh} What about extending (*$executable-file-name="foo"*) to accept a directory? Or else (*$executable-path-name="/foo"*) and (*$object-path-name="/bar"*)? > - Passing the actual size for untyped (resp. void) parameters, so it can > be access with sizeof. This would spoil compatibility to other languages such as C. > (E.g., with untyped files (at least in BP) I often have to do things like > "blockread(f,x,sizeof(x))", which could be simplified to > "blockreadvar(f,x)" then.) So perhaps make "Procedure Foo ( Var x )" pass the size, and keep "Procedure Foo ( Var x: Void )" as it is (i.e. without passing the size)? Or introduce another data type? > And for better BP compatibility: > > - A function "Concat", equivalent to the operator "+" for strings. It can't > be declared in system.pas since (in BP) it allows an arbitrary number of > arguments. > > - Ignoring the BP directives "near" and "far" after procedure/function > declarations (they're irrelevant to gpc, anyway) -- only in > "--borland-pascal" mode, of course. Okay; I have put it on my list. 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 [970624] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Long integers
by Frank Heckenbach 01 Jul '97

01 Jul '97

Peter Gerwinski wrote: > I have heared of a library "gmp" which could be a useful tool to > achieve this. Just write a Pascal interface for it ... I'll look for it (when I've got some time... ;-) > > BTW: Is there any information about schema types and/or PXSC available? > > I don't know more about them than I saw in some examples. > > So do I. :-( How do you know about PXSC, anyway? I did a Yahoo search on "PXSC", and it showed quite a few interesting things about PXSC (besides a few other things abbreviated by "PXSC" and several links to gpc pages :-), e.g. PXSC "home pages": http://ma70.rz.uni-karlsruhe.de/~ae25/iam/html/language/xsc-sprachen.html http://wwwma.rz.uni-karlsruhe.de/~ae08/iam/html/language/pxsc.html I also learned about even more Pascal extensions, like XL Pascal and Pascal++ (see http://www.informatik.uni-halle.de/lehre/pascal/sprache/pas0.html). On a page about BP, I found this remarkable statement: "Borland is the leader in Object-Oriented Programming, winning more awards for technical innovation and customer support than anyone else. That means that when you use Turbo Pascal, you're guaranteed to have the best development environment available, backed by the best support available. It's Borland's commitment to you. [...] Copyright ) 1995 Borland International, Inc." Things must have changed very much within 2 years... :-( > Think of a schema as a type declaration with parameters which can occur > anywhere in the declared type: as array or subrange boundaries, or as a > variant record selector. Anywhere??? (roots:array[1..1+ord(sqr(p)/4-q<>0)] of complex;-) (I just tried it, it gives an internal compiler error. Not that I'd expect this to compile, but I heard somewhere, internal errors should always be reported...) > I doubt whether this is really useful. Numbers of this size aren't usually > typed in as decimal digits, but they are characterized as "2 pow 103 - 2 pow > 97 + 3 pow 13". And you can always write a function which accepts a string > or a chain of integers or whatever and returns a long number. > > [...] > > Then the compiler would have to use this arbitrary-precision library (gmp?) > by itself because a number must be multiplied by ten each time a digit is > read. Not really the whole library; multiplying a long number by 10 (or any base) would be relatively easy to do manually. But you're right, it won't probably be needed too often, so this little inefficiency of the conversion at runtime seems tenable... :-) ... except, maybe, if PXSC demands it ...? -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://www.mi.uni-erlangen.de/~heckenb/links.htm

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