Gpc July 1997

gpc@gnu.de

22 participants
111 discussions

Delphi definitions and such...
by Ken Linder 08 Jul '97

08 Jul '97

Hi all, I just thought we ought to get some definitions out of the way regarding Delphi. 1) Delphi Development tool IDE) and compiler/linker/interactive debugger. Strictly NOT platform independant. Only implemented OS (if you could call it that :^) is the group of Windows OSs. (Although I did read that there is an IBM AS400 version of Delphi (hmmm... interesting!)) 2) Object Pascal A superset of Borland Pascal. The language that is compiled by the Delphi compiler. Through the utilization of the VCL, the Delphi IDE is partialy built on Delphi. This version of pascal is not standard but seems to be an extension of ISO 7185. 3) VCL (Visual Component Library) Library that is both linkable into an executable and dynamicaly used by the Delphi IDE. It is written in Object Pascal. If anyone is interested, I could go a bit further and elaborate, but alas, I am behind on my ncurses/GPC programming! Later... Ken L. kc7rad(a)vegasnet.net klinder(a)hn.com

1 0

Re: Delphi classes
by Peter Gerwinski 08 Jul '97

08 Jul '97

According to The African Chief: > > If you don't use "override", then it creates a new method by the > same name, which replaces the original one. The full implications > of this are not clear to me yet, but they have caused me some > grief a few times (things not behaving as you expect). But I think that I have understood it now. :-) While `override' overrides a virtual method, i.e. replaces its entry in the VMT, `virtual' would create a new entry in the VMT, thus making the old method inaccessible - except when using this class through a pointer to a parent class. One example (I hope there aren't too many typos): Type FooClass = class Constructor Create; Procedure Bar; virtual; end (* FooClass *); Foo2Class = class ( FooClass ) Procedure Bar; override; end (* Foo2Class *); Foo3Class = class ( Foo2Class ) Procedure Bar; virtual; end (* Foo3Class *); Foo4Class = class ( Foo3Class ) Procedure Bar; override; end (* Foo4Class *); Var Foo: FooClass; Foo2: Foo2Class; Foo3: Foo3Class; Foo4: Foo4Class; ... Foo4:= Foo4Class.Create; Foo3:= Foo4; Foo2:= Foo4; Foo:= Foo4; Foo4.Bar; (* calls Foo4Class.Bar *) Foo3.Bar; (* calls Foo4Class.Bar which overrides Foo3Class.Bar *) Foo2.Bar; (* calls Foo2Class.Bar *) Foo1.Bar; (* calls Foo2Class.Bar which overrides FooClass.Bar *) That's my guess. If somebody really *knows* it, please tell me! > given this; "Procedure Foo (Bar:TObject)" > > In Delphi, Bar is a pointer (even though it is automatically deferenced). > In BP it is not a pointer (you would have to do "Bar: pObject", and then > do some magic to dereference it automatically, to achieve the same > thing). In BP (and GPC), you have to write "Procedure Foo ( Var Bar: tObject )" to get (almost) exactly the same: `Var' parameters are internally passed through a pointer which is implicitly dereferenced whenever you access the parameter. > >Sounds logical. But when does Delphi create objects by itself? > > When it manages the project, e,g., when you drag objects from > the repository onto your form - which is how most Delphi programs > are meant to be written. Then it's not Delphi (the compiler) who creates and destroys the objects but VCL which has this close interaction with the development tools. > Well, "Free" is written in ASM. So, maybe therein lies the magic. > I don't understand the ASM code, so I can't really comment on this. Well, as long as you know *exactly* what the compiler does, you can write and use `Free' - perhaps even as a virtual method. But I remember well a rather strange bug in one of my programs when I upgraded from TP6 to BP7 without replacing my heavily-modified Turbo Vision with the new version, and I finally discovered the following in `menus.pas' from Turbo Vision: function NewItem(Name, Param: TMenuStr; KeyCode: Word; Command: Word; AHelpCtx: Word; Next: PMenuItem): PMenuItem; var T: PView; P: PMenuItem; begin if (Name <> '') and (Command <> 0) then begin New(P); P^.Next := Next; P^.Name := NewStr(Name); P^.Command := Command; P^.Disabled := not T^.CommandEnabled(Command); P^.KeyCode := KeyCode; P^.HelpCtx := AHelpCtx; P^.Param := NewStr(Param); NewItem := P; end else NewItem := Next; end; Note that "T^.CommandEnabled(Command)" is called with `T' being an *uninitialized* local variable! So it was quite natural that my BP7-compiled protected-mode program barfed. But why did the same program accept it when compiled with TP6? Well, `CommandEnabled' is not a virtual method, and the body of `CommandEnabled' does never refer to any data fields of the object. (So why it's a method then???) Everything which happens with the implicit `Self' parameter then is that it is loaded into the `es:di' register pair ... which doesn't matter in real mode but causes a protection fault in protected mode if the `es' register does not get a valid selector. That's why the BP7 program crashed. So, everybody, don't use uninitialized local variables, especially not pointers! Yes, Borland, you too! How did Borland solve this problem in BP7? const T: PView = nil; ... P^.Disabled := not T^.CommandEnabled(Command); ... It's great, isn't it? Now you see why I do not want to trust Delphi and VCL and prefer to hack GPC instead ... 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

SHIT! (Sorry) - Procedural Types
by Bernhard Tschirren 07 Jul '97

07 Jul '97

>Now we are in trouble: I cannot reproduce this bug, neither on DJGPP, nor >on Linux. AARRRGGHHH! All procedures are defined in a unit! Whats worse, some test programs refuse to compile - but only sometimes!! As I said in the original mail, the problem is not CString or Function related - problems also occur with procedures. Im using the latest beta GPC for DJGPP 2.01. The following tests were compiled from a DOS shell under Windows 3.11, but they also occur when running in pure DOS using CWSDPMI r3. Below is the ACTUAL (no lie) screen shot of what just happened to me! [Including the habitual typing mistake - oops] <-------------- BEGIN SEENSHOT ------------------------> E:\DJGPP\GPC\BUG>q bug02\ gpc bug02.pas -o bug02.exe bug02.pas: In function `program_Bug02': bug02.pas:16: incompatible types in assignment E:\DJGPP\GPC\BUG>gpc bug02.pas -o bug02.exe bug02.pas: In function `program_Bug02': bug02.pas:15: incompatible types in assignment E:\DJGPP\GPC\BUG>gpc bug02.pas -o bug02.exe bug02.pas: In function `program_Bug02': bug02.pas:15: incompatible types in assignment bug02.pas:16: incompatible types in assignment E:\DJGPP\GPC\BUG>gpc bug02.pas -o bug02.exe E:\DJGPP\GPC\BUG>bug02 OK OK 5460 5456 O OK 5460 5456 E:\DJGPP\GPC\BUG> <-------------- END SCREENSHOT ------------------------> What the @%^!? It compiled OK, but I forgot to use --automake! STRANGE! OK, here comes the source: BUG02.PAS: ---------- Program Bug02; Uses Bug02_U; {$X+} Var ProcRec : TProcRec; S1,S2 : CString; Begin ProcRec.Name1 := @NameFunc; ProcRec.Name2 := @NameFunc; S1 := ProcRec.Name1^; { Line 15 } S2 := ProcRec.Name1^; { Line 16 } WriteLn(ProcRec.Name1^); WriteLn(S1); WriteLn(Word(ProcRec.Name1)); { Testing Procedure Address } WriteLn(Word(S1)); { Testing CString Address } WriteLn; WriteLn(ProcRec.Name2^); WriteLn(S2); WriteLn(Word(ProcRec.Name2)); WriteLn(Word(S2)); WriteLn; End. BUG02_U.PAS: ------------ Unit Bug02_U; {$X+} Interface Type TProcRec = Record Name1 : ^Function : CString; Name2 : ^Function : CString; End; Function NameFunc : CString; Implementation Function NameFunc : CString; Begin NameFunc := 'OK'; End; End. <-----------------------------------------------------> This is one of those nightmare bugs because it shows up at random times. Hang on, Ive just had an --IDEA--! Please wait while I compile once more... DAMN - Its not unit related. Compiling the program below gave me the following error messages. NOTE: It compiled OK the first time!?!? <-------------- BEGIN SCREENSHOT ----------------------> E:\DJGPP\GPC\BUG>gpc bug03.pas -o bug03.exe E:\DJGPP\GPC\BUG>gpc bug03.pas -o bug03.exe bug03.pas: In function `program_Bug02': bug03.pas:24: incompatible types in assignment E:\DJGPP\GPC\BUG>gpc bug03.pas -o bug03.exe bug03.pas: In function `program_Bug02': bug03.pas:24: incompatible types in assignment bug03.pas:25: incompatible types in assignment E:\DJGPP\GPC\BUG>gpc bug03.pas -o bug03.exe bug03.pas: In function `program_Bug02': bug03.pas:24: incompatible types in assignment bug03.pas:25: incompatible types in assignment E:\DJGPP\GPC\BUG>bug03 O OK 1408960 5456 OK OK 1408960 5456 E:\DJGPP\GPC\BUG> <-------------- END SCREENSHOT ------------------------> BUG03.PAS: ---------- Program Bug02; {$X+} Type TProcRec = Record Name1 : ^Function : CString; Name2 : ^Function : CString; End; Function NameFunc : CString; Begin NameFunc := 'OK'; End; Var ProcRec : TProcRec; S1,S2 : CString; Begin ProcRec.Name1 := @NameFunc; ProcRec.Name2 := @NameFunc; S1 := ProcRec.Name1^; { Line 24 } S2 := ProcRec.Name1^; { Line 25 } WriteLn(ProcRec.Name1^); WriteLn(S1); WriteLn(Word(ProcRec.Name1)); WriteLn(Word(S1)); WriteLn; WriteLn(ProcRec.Name2^); WriteLn(S2); WriteLn(Word(ProcRec.Name2)); WriteLn(Word(S2)); WriteLn; End. <---------------------------------------------------------------> I hope I dont cause too much headache with this bug report :~( I know how bad it is hunting down bugs. I had to fix a last minute bug over the weekend - The program was scheduled to be delivered to the client on Monday (Today). Luckily it was a success! Now Ive got a week of holiday - then I go back to UNI! Busy, busy, busy -- And Im only 18!! Whats to come of the future!! AAARRGGHHH! :-) Once again, Good Luck ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

Re: Delphi classes
by Peter Gerwinski 07 Jul '97

07 Jul '97

Hello Dave, hello everybody! According to David Fiddes: > According to myself (Peter Gerwinski): > >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. Sorry, but I don't understand this. I have the impression that we are referring to different things when speaking about "Delphi". Since I think it is important for future GPC development that I understand what Delphi really is, let me please pose some questions - and sorry, if they sound stupid. > The whole > system is designed to be cross platform(unlike C/C++,Pascal,et cetera) from > the ground up. What do you mean with "unlike C/C++, Pascal, etc."? These are language definitions, which do not say anything about the platform the compiler and/or the compiled program have to run on. The only platform- specific think I find in the language definitions is that all of them require some terminal I/O for implementation of the `writeln'/`printf'/etc. procedures /functions. > The only thing preventing it is that Borland is too > skint/not interested in doing it. Here I agree: If Borland wished, they could make Delphi platform-independent. What I meant above is that they decided in a quite early stage to support only the Windows platform, and now it's way too late to adapt VCL to support, say, X11 as well. I would be glad if somebody proved me wrong. > You can replace the VCL if you so wish > the only thing you lose is compatibility with the IDE. This is the point where I must ask: What you mean with "Delphi"? So far, I have seen four definitions: 1. the language definition, 2. the compiler (including compiler switches and such), 3. the compiler and the VCL, or 4. the compiler, the VCL, and development tools (the IDE plus all the tools for "visual programming"). When speaking about Delphi compatibility for GPC I refer to meaning #1 above. #2 is out of range, but one can work around this by using (*$ifdef*)s for incompatible compiler switches. (* There is only one thing in GPC preventing us from really doing so: the missing {$ifopt x+}. That's still planned. *) Most people who want to have a Delphi-com- patible system mean #4, but could live with #3, too. What I personally aim is #1, but I am almost sure that once we have #1, somebody else will create #3, and perhaps even #4. :-) > The Windows VCL > implementation could quite easily(and I mean this) Why do you think this would be easy? I doubt that it is, but (as I already wrote) I would be glad if somebody proved me wrong. > 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. You mean the source of the program, not that of VCL. You are probably right. The point where we disagree is the "quite easily" above. As far as I have understood Delphi's internals up to now (which is not much, sorry), you need a lot of compiler magic for a working VCL. (That's what I meant with the compiler being designed to work together with exactly VCL.) For example, when I create a Delphi project (Thanks, Larry!) with one form containing three `CheckBox'es, Delphi considers the following as the source of my program: -- project1.dpr -- program Project1; uses Forms, Unit1 in 'UNIT1.PAS' {Form1}; {$R *.RES} begin Application.CreateForm(TForm1, Form1); Application.Run; end. -- unit1.pas -- unit Unit1; interface uses SysUtils, WinTypes, WinProcs, Messages, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls; type TForm1 = class(TForm) CheckBox1: TCheckBox; CheckBox2: TCheckBox; CheckBox3: TCheckBox; private { Private declarations } public { Public declarations } end; var Form1: TForm1; implementation {$R *.DFM} end. >From this example I can learn that Delphi 1. allows to pass class types as arguments of procedures somehow (see the call to `Application.CreateForm'), and 2. allows some magic for the other parts of VCL to locate the data fields `CheckBox[1-3]' in `TForm1'. (* Is this the meaning of the famous `published'? *) While I can accept most general-purpose language extensions (#1 could be such a thing), I don't like compiler functionality specifically designed for one library - which I suspect in #2. Please correct me if I am wrong. > 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. (* One of the reasons why I started with GPC was because I cannot stand Delphi's IDE ... ;*) Not everyone has one, but everyone who wants to use such a "GNU-Delphi" probably has. How should such a GNU-Delphi look like? > 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, (The Mac is likely to cause trouble here, because MacOS is not supported by GNU, AFAIK.) > X Windows,etc for nil effort. "Nil effort" isn't realistic - at least the compiler switches will have to be adapted - but let's aim "minimum 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.... ... which I can understand well ... > 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. (* For me it's vice-versa: Using Delphi for serious development would quarter the time needed to produce a running program (10%), but would quadruple the time/number of staff required to get it stable (90%). ;*) > fyi, this is why I like GNU-Pascal. I hope - and am doing my best - that you won't be disappointed. > yours (rantingly), :-) 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 [970624] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: GNU Pascal preconfigured
by The African Chief 07 Jul '97

07 Jul '97

On Sat, 5 Jul 1997 16:20:07 +0200 (MET DST) Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> wrote: [...] >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. Better still, what about one ZIP file? Put all the relevant .ZIP files inside a single ZIP file, and that is all that the user needs to download. >If I remember right, The African Chief (Hi!:) 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. Sounds okay to me. I planned to write an install script to be used with my installer (with a free registration given to the GPC team for the purpose of providing and installation routine for GPC distribution). I am still willing to do this - so (Peter and/or Jan-Jaap) if or when you need this, just drop me a note! Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.60 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

Re: Delphi classes
by The African Chief 07 Jul '97

07 Jul '97

On Fri, 4 Jul 1997 16:27:32 +0200 Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: > >Marius Gedminas wrote: > >> In Delphi you can declare a method 'virtual' or 'dynamic' and when you want to >> override it in an descendant class, you must do it with 'override' directive. > >And what happens if you don't use "override"? If you don't use "override", then it creates a new method by the same name, which replaces the original one. The full implications of this are not clear to me yet, but they have caused me some grief a few times (things not behaving as you expect). >Peter Gerwinski wrote: > >> It's "class" = "reference to object". Fortunately, the GCC front-end >> is able to deal with such things, > >Fine! :-) (Front-end? Or back-end?) > >> so we "only" have to implement the >> syntax into GPC - and take care that it doesn't break other applications >> of reference types such as `Var' parameters and procedural variables. > >Yes. Are value and reference parameters of class type the same, then (in >Delphi)? Or do reference parameters pass a pointer/reference to the >reference, i.e. do they allow destroying and recreating the object? Who knows? > >Are pointers to classes allowed in Delphi, and what do they mean? If you mean this; Type MyFoo = Class end; Type pMyFoo = ^MyFoo; Var Foo : pMyFoo; - then the answer is "yes", this will be accepted in the sense that it will compile. However, when you run the program, I cannot tell you what will happen. I have not ever tried it, neither do I have any desire to do so. In fact, there is no point at all in doing something of that nature. >AFAICG, objects in Delphi are typically things like windows, editors, dialogs >and such "big things". Not at all. There are all sorts of classes, including collections, strings, maths, Zip/UnZip, etc. >> Delphi also supports both Objects and Classes - > >With the differences like I described them? I am not sure I remember how you described them. However the main difference is that Objects in Delphi are the same as the Objects in BP (and GPC). Classes are different, in the ways which have before been explained. > >> so it would be nice if we could as well. > >gpc will certainly not remove objects when classes are implemented. :-) > >> >> [b] the constructor does the heap allocation stuff, >> >> e.g., "Foo := MyFoo.Create" >> >> *allocates memory for Foo "(New, Foo)" >> >> *calls Foo^.Create (constructor) >> > >> >So it's the same as "Foo := New(MyFoo, Create)" in BP? >> >> More or less. > >I'd like to know it exactly. Is there any difference (besides the different >syntax, of course)? given this; "Procedure Foo (Bar:TObject)" In Delphi, Bar is a pointer (even though it is automatically deferenced). In BP it is not a pointer (you would have to do "Bar: pObject", and then do some magic to dereference it automatically, to achieve the same thing). > >> Delphi destroys all objects that it creates itself. However, >> if you manually create an object by calling its constructor, >> you have to destroy it yourself with a call to "Free". > >Sounds logical. But when does Delphi create objects by itself? When it manages the project, e,g., when you drag objects from the repository onto your form - which is how most Delphi programs are meant to be written. >AFAIK, gpc doesn't do this yet, so we'd have to adopt this as well!? We would need a Delphi-like IDE. >> 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?) Well, "Free" is written in ASM. So, maybe therein lies the magic. I don't understand the ASM code, so I can't really comment on this. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.60 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

Re: Delphi classes
by The African Chief 07 Jul '97

07 Jul '97

On Sat, 5 Jul 1997 16:16:55 +0200 (MET DST) Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> wrote: [...] >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. Yes, this is more or less the correct analysis. >> You can also attach specialized editors for >> complex properties. > >So you can extend this functionality of the object inspector. Yes, by writing your own "property editor" for your objects or data structures. Delphi's object inspector at the moment only works well with enumerated types, Pascal strings, and numerical types. If your object has properties which are records or pointers or other more complex data structures, you will need to write your own property editor for these structures, otherwise, you cannot "publish" those properties. They will have to be "public". Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.60 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

Re: Delphi classes
by The African Chief 07 Jul '97

07 Jul '97

On Sat, 5 Jul 1997 20:21:24 +0200 Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: > >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. The object inspector is not a form of debugger. It is a visual design tool, that allows the properties of an object to be set and changed without writing any source code (just change the values in the object inspector). Thus, it is possible (in theory) to write a fully fledged program without writing a single line of code. It all depends on the richness of your "components". >Anyway, so the difference between "published" and "public" is just relevant >to the debugger, not to the compiled program? It is relevant to the object inspector, at design time. The values which you set in the object inspector are preserved in the compiled program (just as if you had manually written the code to set those values before compiling the program). Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.60 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

GNU Pascal preconfigured
by Peter Gerwinski 07 Jul '97

07 Jul '97

According to Jan-Jaap van der Heijden: > > I have some preliminary stuff here to package GPC in an RPM. RPM is a > popular package manager in the Linux world. It makes upgrading a > binary distribution as easy as `rpm -U gpc-YYMMDD.i386.rpm' Hmm ... now it is as easy as `tar xzf gpc-YYMMDD.i386-linux.tar.gz'. I am probably missing something. 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]

2 1

Procedural Types
by Peter Gerwinski 07 Jul '97

07 Jul '97

Hallo, Bernhard, hello, everybody! According to Bernhard Tschirren: > > [...] 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'. [...] (*$if 0 *) Now we are in trouble: I cannot reproduce this bug, neither on DJGPP, nor on Linux. I'd like to ask you to do further analysis on this: - Is the address returned by `Name1' and `Name2' the same? (It should be!) - What are the bytes pointed to by both returned `CString's? I mean something like the following: Program Bug02; Uses Bug02_U in 'b5u.pas'; {$X+} Type ByteArray = array [ 0..3 ] of Byte; ByteArrayPtr = ^ByteArray; Var ProcRec : TProcRec; P1, P2: CString; i: Integer; Function TheName : CString; Begin TheName := 'OK'; End; Begin ProcRec.Name1 := @TheName; ProcRec.Name2 := @TheName; P1:= ProcRec.Name1^; P2:= ProcRec.Name2^; writeln ( Integer ( P1 ) ); writeln ( Integer ( P2 ) ); writeln ( P1 ); writeln ( P2 ); for i:= 0 to 3 do write ( ByteArrayPtr ( P1 )^ [ i ] : 4 ); writeln; for i:= 0 to 3 do write ( ByteArrayPtr ( P2 )^ [ i ] : 4 ); writeln; End. On my system, the result is 5456 5456 OK OK 79 75 0 144 79 75 0 144 as it should be. (The 5456 and 144 are fixed, but arbitrary numbers.) (*$else *) Ah - now I have it! :-) With high probability that's another shape of a known bug: You cannot assign procedures defined in a *program* to procedural variables (or procedural pointers, like in your example). :-( To check this, please move `TheName' to a Unit (either `Bug02_u' or another one), and retry. <keeping fingers crossed> These procedures are treated as local subprocedures of the main program which is a procedure by itself. This is the source of a lot of trouble, also in other contexts, but it is necessary to make some nonlocal `goto's work which are required by Extended Pascal. (No, I don't use `goto', and I don't know more about this, sorry. If I had a test program for these nonlocal `goto's, I could try to make the other stuff work *without* breaking `goto'; right now I don't dare to touch this. ;-) (*$endif *) Thanks for your help, 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
...
5
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