Gpc July 1997

gpc@gnu.de

22 participants
111 discussions

Re: Delphi classes
by David Fiddes 07 Jul '97

07 Jul '97

>What Borland did with Delphi was to design the compiler to work >together with exactly one library (VCL), exactly one set of development >tools (object inspector etc.) on exactly one platform (Windows). I don't >like this approach because it contradicts the general applicability of a >compiler. NO WAY! The only odd thing about Delphi is the compiler portion. The whole system is designed to be cross platform(unlike C/C++,Pascal,et cetera) from the ground up. The only thing preventing it is that Borland is too skint/not interested in doing it. You can replace the VCL if you so wish the only thing you lose is compatibility with the IDE. The Windows VCL implementation could quite easily(and I mean this) be swapped out and replaced with an X-Windows-VCL, Mac-VCL, NEXT-VCL, etc,etc,etc. It should be possible to build(as in compile) a standard(i.e. not using Windows fns direct) Delphi application on any compatible compiler/processor/OS combination without touching the source at ALL. GNU-Delphi is a real possibility. The only thing you would lose is the pretty IDE which, naturally, remains the property of Borland...afterall, everyone has a Windows box to do the initial development on. I would be really interested in a command line cross-compiler for Delphi that would allow me to port my existing Delphi software to the Mac, X Windows,etc for nil effort. I build educational software for a living which gets sold to the general public/consumer(all PC based) and to teachers/schools/colleges,etc which for various political reasons use a wide variety of muck including Macs....I want to sell to these folk...these folk want to buy from me...but they don't want to have to re-equip with PCs....and doing serious development on anything other than Delphi is out of the question as it would quadruple the lead time/number of staff required to complete a given project. fyi, this is why I like GNU-Pascal. yours (rantingly), Dave Dave Fiddes, CALM Software Production Officer Department of Mathematics, Heriot-Watt University, Edinburgh email D.J.Fiddes(a)hw.ac.uk - Tel: 0131-451-3251

1 0

"Easy install" GPC/djgpp release.
by Jan-Jaap van der Heijden 06 Jul '97

06 Jul '97

Hello all, I wrapped up a GPC distribution with all essential tools included, fitting on 1.44" disks. I reused the installation tool of djgpp V1.x. Although it looks a little aged, it does what it's supposed to do. URL: ftp://agnes.dida.physik.uni-essen.de/home/janjaap/easy-djgpp/ Let me know what you think about it. JanJaap --- With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC1925.

1 0

Re: Delphi classes
by Frank Heckenbach 06 Jul '97

06 Jul '97

Peter Gerwinski wrote: > > > New(Foo); > > > Foo.Create; > > > > If it's undefined in Delphi, it wouldn't hurt if there is a defined > > behaviour in gpc. :-) > > You cannot `New' a class because it is a reference, no pointer. > The above should be a syntax error in GPC as well as in Delphi. I meant the "Foo.Create" which could be allowed in gpc, I overlooked the "New(Foo)" line which in fact wouldn't make much sense. > That's the anti-motivating part of compatibility: All this is intended *not* > to be used. Yes, but we basically have the choices to say "you must convert this and this and that before your programs will compile with gpc, then they won't compile with BP anymore, but you can do much better things", or "you can just compile most of your BP programs with gpc, and once you're convinced that gpc really does its job, you can make use of more advanced features as fast as you want to" -- I guess most BP users would accept only the latter way... > > Nice little "trick", but not very systematic. "Free" is a method of an > > object, and this object can be "nil^"!? Technically, it works, but "Free" > > must not be virtual (I guess it isn't in Delphi)! But as a clean way, I'd > > prefer a procedure... (Or should we regard it as defined behaviour to call > > a static method of a non-existing object if the method doesn't access any > > fields of the object?) > > Sorry, but this nice little trick is purest brain-damage! Doesn't matter since Delphi runs only under Windoze -- there's nothing to damage... ;-) > - Dereferencing a `Nil' pointer should yield a runtime error. Both BP > and GPC don't check this, but this is a bug in the compiler to be > eliminated when we implement runtime checks into GPC. A very good idea! > - Releasing the storage of an object while a method of it is running > is idiocy. It should yield a runtime error, too, but this is too > hard to detect for the compiler. True. But I fear a Delphi compatibility library will even have to emulate this... :-( (BTW: Since OOP objects are often compared to real world objects or persons, this "Free" method would mean: 'Commit suicide, and bury your own corpse, please!' ;-) -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Procedural Types
by Bernhard Tschirren 06 Jul '97

06 Jul '97

Somehow, procedural types are not transported through the GPIs correctly. I am using gpc-970624 (BETA) for DJGPP 2.01. The following program demonstrates this bug. In some (RANDOM!) cases, the program works, in others it prints out only the first letter of the 'OK'. The bug does not only affect functions returning CCtring (PChar) values, it affects all procedural types (Procedures AND Functions). BUG02_U.PAS: ------------ Unit Bug02_U; {$X+} Interface Type TProcRec = Record Name1 : ^Function : CString; Name2 : ^Function : CString; End; Implementation End. BUG02.PAS: ---------- Program Bug02; Uses Bug02_U; {$X+} Var ProcRec : TProcRec; Function TheName : CString; Begin TheName := 'OK'; End; Begin ProcRec.Name1 := @TheName; ProcRec.Name2 := @TheName; WriteLn(ProcRec.Name1^); { Prints out 'OK' } WriteLn(ProcRec.Name2^); { Prints out 'OK', or sometimes only 'O' } End. Good Luck finding this bug ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

GPC in an RPM
by Jan-Jaap van der Heijden 06 Jul '97

06 Jul '97

Hello, I finished the RPM (RedHat Linux distribution package) I mentioned earlier. It can be downloaded from a new "redhat" subdirectory on agnes.dida.physik.uni-essen.de While I built it on my RedHat 4.2 distribution, it should work also for other RPM based installations (Caldera, etc.) I included all patches to GCC found in the gcc-2.7.2.1.src.rpm so it should build on Linux/alpha and Linux/sparc as well, but I cannot verify this. As soon as we have gpc-2.1, it should probably be uploaded to the redhat-contrib archive. Okay, so now installation on Redhat is reduced to only a few mouseclicks. Too bad you still need a keyboard to *use* it ;-) JanJaap --- With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC1925.

1 0

GNU Pascal preconfigured
by Peter Gerwinski 05 Jul '97

05 Jul '97

Hi, everybody! (*$ifdef Andreas Eckleder *) Hallo, Andreas! Meine persoenliche Antwort an Dich kam dreimal zurueck mit dem Vermerk "unbekannter Host". Da die Angelegenheit ohnehin alle GPCies betrifft, antworte ich jetzt ueber die Liste. Ich hoffe, Du hast nichts dagegen, dass ich Teile deiner persoenlichen e-mail hier uebersetze und veroeffentliche ... #-) (*$endif *) Andreas Eckleder wrote to me (in German; translation by myself): > What about creating a GNU Pascal distribution with an installation > tool which makes it extremely easy to install, and simultaeously > does some other configuration tasks (environment variables, RHIDE > configuration)? > [...] I would vote for it! Once upon a time I had started myself to write such an installation tool, but then there were several urgent GPC errors which were much more interesting ... ;-) For DOS or for Linux? (Or for SGI?;-) Be welcome to distribute this package on agnes and kampi, together with the rest of GNU Pascal! However we must take care not to spoil the structure of the other parts of the GPC distribution. We do not want to prefer DOS or Linux users to any other ones. The current structure is: / = ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/ or ftp://kampi.hut.fi/jtv/gnu-pascal/ / GPC source, global `README', etc. /binary/ GNU-style GPC binary distribution, i.e. gpc-2.0.i586-linux.tar.gz, gpc-2.0.i386-djgppv201.zip, ... /djgpp/ DJGPP-style GPC distribution (gpc20s.zip, gpc20b.zip) /emx/ EMX-style GPC distribution (gpcsrc.zip, gpcdev.zip) /beta/ beta versions /alpha/ alpha versions /old/ museum /contrib/ useful independent contributions, e.g. `BPCompat' /misc/ other stuff, e.g. the GPC WWW home page. The package (How to call it? What about "Easy GPC?" I am taking this as a working title ... :-) must not occupy the main directory. OTOH, we must not hide it, of course. What about another subdirectory `/easy/' from the same type as `/djgpp/' containing all needed `.zip' files plus the installation program and `README'? Having this, a user only needs to download the contents of *one* directory. /easy/ complete GPC distribution for DOS (DJGPP) with a user-friendly, interactive installation program And the global `README' would get a prominent pointer to this directory: The easy way to install GNU Pascal ================================== If you are running DOS, and you want to install a complete package via a user-friendly, interactive installation tool, please go to the `easy' subdirectory, download all files, store them in one directory on your hard disk, and type `install'. If I remember right, The African Chief (Hi!:) had planned to write something similar for Windows. Then we could create more directories of this type, e.g. `/easy-dos/' and `/easy-w32/', and change the text in `README' accordingly. BTW, the installation program "must" contain a text browser which presents the GNU license in full length! I have the impression that many users consider a program the more interesting, the more penetrant you point them to the license terms and conditions. If you tell them "you can just proceed and use it", people become sceptical. sqr ( BTW ), if all components included are under the GNU GPL, it is perfectly legal to burn the whole stuff on a CD (or a stack of floppies) and to sell that CD. You are invited to do that, too. Tschuess, 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: Delphi classes
by Frank Heckenbach 05 Jul '97

05 Jul '97

Ken Linder wrote: > The Object Inspector is a development tool that allows the developer to > 'non-programaticaly' set the properties of an object before instantiation. > Here is a quick example: > > ... > published > Caption : string; > Status : (Maximized, Minimized, DontKnow); > SomeNum : integer; > ... > Lets say the above is part of an object that can be 'dragged' onto the > desired window. (Yes, I know I am talking Windows here) Selecting the > object after it is dragged onto the window will make the 'object inspector' > display all 'published' properties of that object. The object inspector > will allow the programmer to enter some string for Caption, select one of > the enumerated values for Status, and an integer for SomeNum. At run-time > the object inspector don't exist. It is strictly part of the Delphi (and > C++ builder) development tool. AFAI understand it, it's just some form of debugger, isn't it? (Typical for all the Windoze hype to introduce new names for the same old things...?) I think, changing values of object fields can be done with any debugger. Anyway, so the difference between "published" and "public" is just relevant to the debugger, not to the compiled program? -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: GNU Pascal beta version gpc-970624
by Peter Gerwinski 05 Jul '97

05 Jul '97

According to Maurice Lombardi: > > djtar -x -v gpc-9706.tgz (8.3 limitation) > > It barks: unable to create the directory gpc-970624/p/ Ah - sorry, there should be a separate `.zip' source archive for DJGPP and EMX. I am uploading it now. > I found that the only difference is that now all is in > the subdirectory p/ It seems so. This is done because the GPC source shall go into a subdirectory `p' of the GCC source. However the contents of the directory has changed violently as well. > This is supported also by the fact that the files COPYING.gpc and > INSTALL.gpc which are said in the file gpc-970624/p/install to be within > gpc-970624 together with the directory p are not there. Yes, we first had `COPYING.gpc' and `INSTALL.gpc' in the GCC top directory, but I thought that they are better in the `p' subdirectory. Having two identical files `COPYING' and `COPYING.gpc' in the GCC source looks stupid IMHO, but having two copies of `COPYING' in different directories is okay. 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: Delphi classes
by Peter Gerwinski 05 Jul '97

05 Jul '97

According to Ken Linder: > ... > published > Caption : string; > Status : (Maximized, Minimized, DontKnow); > SomeNum : integer; > ... > Lets say the above is part of an object that can be 'dragged' onto the > desired window. (Yes, I know I am talking Windows here) Selecting the > object after it is dragged onto the window will make the 'object inspector' > display all 'published' properties of that object. The object inspector > will allow the programmer to enter some string for Caption, select one of > the enumerated values for Status, and an integer for SomeNum. At run-time > the object inspector don't exist. It is strictly part of the Delphi (and > C++ builder) development tool. I understand this as follows (please correct me if I am wrong): The object inspector, a development tool, lets you specify values for `published' variables interactively. After that, a copy of the object is stored in a resource file read by the application. Like this, the program can (and will) use an instance of the object with the fields having these values. > You can also attach specialized editors for > complex properties. So you can extend this functionality of the object inspector. When implementing it for GPC, we should do this from the very beginning: The library somehow exports methods how to edit these fields. All this can easily be implemented in a library without touching the compiler. In Delphi, they obviously implemented it in an external program which reads some data about the application (kind of debugging information) which requires close interaction with the compiler. > The inspector also allows the programmer to attach > functions and procedures to events but that is VERY windows based due to the > message passing nature of the Windows OS. ^^^^^^^^^^ (* "Windows program" or "Windows server program". It's no OS, but a GUI. Let's call it "platform" which covers both. ;*) Messages are not Windows-specific. Turbo Vision has them, too, so does the OS/2 presentation manager, and, AFAIK, X always did, too. What Borland did with Delphi was to design the compiler to work together with exactly one library (VCL), exactly one set of development tools (object inspector etc.) on exactly one platform (Windows). I don't like this approach because it contradicts the general applicability of a compiler. For GPC, we should better implement a library (our VCL equivalent; GCL?) which comes with a set of development tools which works with this library, but can be adapted to work with other libraries as far as possible (e.g., it reads some information about the library from a configuration file included in the package). The compiler can produce information of general interest (perhaps the debugging information is already sufficient) read by the development tools, but any library-specific information must be produced by the libary, not by the compiler. 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: Delphi classes
by Peter Gerwinski 05 Jul '97

05 Jul '97

According to Frank Heckenbach: > According to myself (Peter Gerwinski): > > It's "class" = "reference to object". Fortunately, the GCC front-end > > is able to deal with such things, > > Fine! :-) (Front-end? Or back-end?) The front-end definitely is (read: we can use this for GPC); for the back-end it *might* be necessary to convert references to pointers. No big deal. > gpc will certainly not remove objects when classes are implemented. :-) It won't. :-) According to Frank Heckenbach: > According to The African Chief: > > New(Foo); > > Foo.Create; > > If it's undefined in Delphi, it wouldn't hurt if there is a defined > behaviour in gpc. :-) You cannot `New' a class because it is a reference, no pointer. The above should be a syntax error in GPC as well as in Delphi. > My suggestion: implement a compiler switch like '--base-class="TObject"' so > that gpc will use this class by default as a parent class if no parent is > declared (and, of course, if the current class is not "TObject" itself ;-). > With "--delphi", this switch could be set automatically. Then, TObject could > be declared in some unit (like System for Delphi). (For "completeness", we > could also have '--base-object' or so...) Sounds reasonable. > BTW: This is similar to the '--uses="system"' I suggested -- things that > are not really the job of the compiler, but needed for compatibility. Such > switches seem to make the difference to the compiler as small as possible. Sounds reasonable. (Even *more* switches!) > For BP/Delphi programs that are just recompiled with gpc, these switches > can be used. When the programs are really ported to gpc, these things would > probably put into them programs themselves, and the switches would not be > used anymore (neither for native gpc programs), I guess. That's the anti-motivating part of compatibility: All this is intended *not* to be used. > > Like I said, "Create" and "Destroy" are empty in TObject > > (i.e., they contain just an empty "begin end;" block). > > "Free" checks whether the pointer is Nil, and if it is not, > > it calls Destroy. > > Nice little "trick", but not very systematic. "Free" is a method of an > object, and this object can be "nil^"!? Technically, it works, but "Free" > must not be virtual (I guess it isn't in Delphi)! But as a clean way, I'd > prefer a procedure... (Or should we regard it as defined behaviour to call > a static method of a non-existing object if the method doesn't access any > fields of the object?) Sorry, but this nice little trick is purest brain-damage! I saw similar tricks in Turbo Vision. All of this works, but it relies on how the compiler and the RTS do things. - Dereferencing a `Nil' pointer should yield a runtime error. Both BP and GPC don't check this, but this is a bug in the compiler to be eliminated when we implement runtime checks into GPC. - Releasing the storage of an object while a method of it is running is idiocy. It should yield a runtime error, too, but this is too hard to detect for the compiler. 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

← Newer
1
...
6
7
8
9
10
11
12
Older →

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 July 1997