Gpc

gpc@gnu.de

5400 discussions

Re: Const conflict.
by Peter Gerwinski 26 Apr '97

26 Apr '97

According to Jukka Virtanen: > > [Making the parser more clever ...] > > Then it remains the problem how to interpret the following: > > foo_problem : false .. true = false; > > Because that can be interpreted either as an initialized > or uninitialized subrange. If I were a Pascal compiler, I would read this as an initialized variable. OTOH, a true Extended Pascal compiler *must* read this as a subrange. I think it is save to exclude comparisions with `=' from the expressions valid for the upper bound. The reason for allowing expressions here is to have things like `+', `*', parentheses, etc. in the upper bound; subranges of the Boolean type are exotic enougth that we can immolate them. (Hmm ... somebody might need something like Var Foo: 1 .. 4 + ord ( bar = 3 ) + MyFunc ( A = B ); so I will switch on the `=' again in parentheses and such.) > Extended pascal does require that both bounds of > a subrange can be arbitrary expressions. In GPC (as far > as I recall) only the lower bound can be an expression, > the upper bound needs to be constant, [...] Vice versa. > Anyone who really knows how to hack parsers interested > in this one? I join Juki in asking this question. I think I can fool GPC not to recognize the `=' in upper bound expressions (unless, of course, `--extended-pascal' is on), but I have no idea what to do with the lower bound. 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: BP Turbo Vision sources
by Peter Gerwinski 26 Apr '97

26 Apr '97

According to Jan-Jaap van der Heijden: > > I collected this discussion from comp.os.msdos.programmer.turbvision. > Somebody claims to have gotten permission from Borland to release the BP > Tvision sources to the public "as long as they are not sold". GNU Pascal > is definately the "not for money" category so this may be interesting to > us. Not so definitely. The GPL allows to sell copies of GPC as long as the clients get all rights the vendor had. > Having Turbo Vision available would make it much easier to write > attractive applications, at least for the djgpp/dos port of GPC. Really. We must not distribute Turbo Vision "as part of GPC" because this would restrict distribution of GPC, but it can be in the "contrib" subdirectory. > But I do think we should wait and see what happens next.... I agree. Some official notes from Borland would be good. (The telephone call somebody in a NewsGroup spoke about would not be accepted as a proof in a lawsuit.) (* And GPC cannot compile Turbo Vision anyway at the moment. *) 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: BP style objects: errors.
by Peter Gerwinski 26 Apr '97

26 Apr '97

According to Jan-Jaap van der Heijden: > > 1) References to an incomplete type are not accepted. [...] That's a new bug. I will have a look at it. > 2) Something simular appens in the implementation part: > > [...] > > TErrorProc = procedure(var S: TStream); GPC does not (yet;) have BP's "procedural variables". It has *pointers* to procedures instead. The above can be translated to TErrorProc = ^Procedure ( ????????? TStream ); - ah, sorry! `Var' parameters don't work in this context! Bug!!! Okay, I will see how difficult it is to implement BP's procedural types ... > 3) Obviously, `self' is treated different too... This I don't understand. > All of this with the latest-but-one alpha release, in BP mode with > extended syntax. It should not be necessary to run GPC in BP mode. `--borland-pascal' does not switch ON anything; it only switches OFF the Extended Pascal extensions. And vice versa. I suggest to write all new source for GPC's default mode and to use `--borland-pascal' (or `--extended-pascal' for that matter) just for testing or when worrying about compatibility to Borland (respectively Extended) Pascal. (*$X+, M Extended Syntax is a different thing because it really switches ON some "dangerous" features of GPC. *) > BTW: of course, what I was trying out, was how much trouble it would be to > port TVision to GPC. Seems we have a long way to go.... We will see. (* But anyway I aim to write something *better* ... ;*) > With sufficient thrust, pigs fly just fine. However, this is not > necessarily a good idea. [...] But there may be some people whose programs rely on flying pigs. I am prepared to implement yet another option `--flying-pigs' for such purposes ... 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

errors when passing pointers from a unit
by skye 25 Apr '97

25 Apr '97

I don't realy understand this. I'm new to Pascal tho I've programmed in C for quite some time. I have a unit that dose some _basic_ mode 13h graphics stuff. In it is an off-screen buffer created my allocating a type defined as: type mode13VideoBuffer = array[1..64000] of char; var gBuffer"^mode13VideoBuffer; I have 2 procedures that set up the video mode (by calling some external C functions) and allocate this buffer. procedure InitGraphics; begin {set video mode and other initalization stuff} new(gBuffer); end; procedure TextMode; begin {reset the display and clean up video stuff} dispose(gBuffer); end; All my graphic functions draw to this buffer. To get it to the screen I have a procedre that calls an external C function: procedure gUpdate; begin screenblit( gBuffer); end; It is in this C function that I crash. Here's the screenblit function: //uses libc.a functions void screenblit( unsigned char* buf) { short video = __dpmi_segment_to_descriptor(0xa000); movedata(_my_ds(), (int)buf, video, 0, 320*200); } This only crashes when I pass it a pointer from my unit. I can do the exact same allocation from the main program file and it will work OK. Am I getting confused on how pointers work in C and how they work in Pascal (I thought that they were pretty much the same except for type checking and "true" dynamic allocation)? This how I compile and link: I create a lib from the compiled .o files from my units. I then compile my test program linking in the lib: gpc -g -o gtest.exe gtest.pas -lglib ^^^^ This is my lib NOTE: I can get this system to work in C by replicating the units in .h and .c files and linking the object files on the commanline. HELP? -SC

1 0

BP style objects: errors.
by Jan-Jaap van der Heijden 24 Apr '97

24 Apr '97

Hello, Using gpc to compile (some parts of) Borland's objects unit, I noticed this (so far): 1) References to an incomplete type are not accepted. In the code below, CopyFrom uses a variable S of type TStream, while TStream is not yet finished: type PStream = ^TStream; TStream = object(TObject) Status: Integer; ErrorInfo: Integer; constructor Init; procedure CopyFrom(var S: TStream; Count: Longint); ... BP accepts this, gpc barfs: "type name expected, identifier `Tstream' given" 2) Something simular appens in the implementation part: procedure TStream.Error(Code, Info: Integer); type TErrorProc = procedure(var S: TStream); begin Status := Code; ErrorInfo := Info; if StreamError <> nil then TErrorProc(StreamError)(Self); end; This results in an error: objects.pas: In function `Tstream_Error': objects.pas:141: `object' type definition only allowed at top level objects.pas:141: parse error before `Procedure' objects.pas:142: pointer domain type `Terrorproc' undefined objects.pas:145: undeclared identifier `Terrorproc' (first use this function) objects.pas:145: (Each undeclared identifier is reported only once objects.pas:145: for each function it appears in.) objects.pas:145: parse error before `(' objects.pas:145: missing semicolon objects.pas:145: missing semicolon 3) Obviously, `self' is treated different too... All of this with the latest-but-one alpha release, in BP mode with extended syntax. BTW: of course, what I was trying out, was how much trouble it would be to port TVision to GPC. Seems we have a long way to go.... Greetings, 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: New Alpha
by Peter Gerwinski 24 Apr '97

24 Apr '97

According to Frank Heckenbach: > [...] > However, the following still doesn't work (if it's already/still on the bug > list, please ignore): > > PROGRAM x; > CONST n:1..16=6; {"subrange bounds are not of the same type"} > BEGIN > END. Is this really a bug??? Extended Pascal allows expressions as the upper bound of a subrange. In this case, the expresson "16 = 6" (with the Boolean value "false") is the upper bound - which is indeed not of the same type as the lower bound "1". This is a known shift/reduce conflict in the parser. In principle it should be possible to tell bison to shift it rather than to reduce it - just like with the "dangling else" problem. Since I am a complete beginner with parsers (no theoretical knowledge; my only experience with bison relates to GPC) I would be glad if somebody could help me with this. > {The same with "var ...=...", ok with "var ... value ..."} Strange. On my box, it works with `value'. > Then, a very small problem: > > I have a Pascal program (let's say foo.pas) that uses some units. > [...] > If I compile it with "gpc foo.pas bar.c", it works fine. But if I do > "gpc bar.c foo.pas", it doesn't ("Undefined references" to the C functions). I think that's intended: The GNU linker is a one-pass linker which needs the "lowest" unit in the most right position of the command line. (I think. I don't really know.;-) > In the latter situation also the file foo.gpc is left. That's indeed a bug. Thanks for the report. 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

4 3

Re: Const conflict. Was: Re: New Alpha
by Frank Heckenbach 24 Apr '97

24 Apr '97

Peter Gerwinski wrote: > > {The same with "var ...=...", ok with "var ... value ..."} > > Strange. On my box, it works with `value'. Yes, I meant it's ok with "value". Perhaps I was unclear. > > I have a Pascal program (let's say foo.pas) that uses some units. > > [...] > > If I compile it with "gpc foo.pas bar.c", it works fine. But if I do > > "gpc bar.c foo.pas", it doesn't ("Undefined references" to the C functions). > > I think that's intended: The GNU linker is a one-pass linker which needs > the "lowest" unit in the most right position of the command line. > (I think. I don't really know.;-) I don't think that's the problem. I tried invocing ld manually, and it worked whether bar.o was put before or after the Pascal .o's. However, I noticed that the "automade" unit's .o files were not passed to ld in the latter case: In the first case, gpc issued "ld ... some.o units.o foo.o bar.o ...", in the latter case, it was just "ld ... bar.o foo.o ..." (where foo.o and bar.o were actually temp file names containing the compiled code from foo.pas and bar.c, of course). So, probably this has got something to do with the left over .gpc file... Jakob Heinemann wrote: > > > PROGRAM x; > > > CONST n:1..16=6; {"subrange bounds are not of the same type"} > > > BEGIN > > > END. > > > Is this really a bug??? Extended Pascal allows expressions as the upper > > bound of a subrange. In this case, the expresson "16 = 6" (with the > > Boolean value "false") is the upper bound - which is indeed not of the > > same type as the lower bound "1". Sorry, I didn't see the other possible interpretation when I reported the problem. Actually, BTW, there is a bug in BP - it doesn't even accept the following... ;-) const x:false..(2=3)=false; > I Suppose Frank intended to have a specific value of a subrange as a > constant, but really this is not a good code example, for making good > use of constants in a program you should make an explicit type > declaration, > and though I have not tried it this should work: Thanks for the hint, that's what I'm doing now. It solves the "bug". Phil Nelson wrote: > By forcing the reduce > then the construct "CONST N : false .. 1 = 1 = false;" produces a syntax > error. But, you can still do this by "CONST N : false .. (1 = 1) = false;"; > So I would say that you do want to force the reduce and make equals have to be > parenthesized to get comparison. I thought so, too, but then I realized that this might break some Extended Pascal code: var n:false..1=2; would be valid in EP, but cause an error with the above modification. var n:false..false=false; would declare "n:false..true" uninitialized in EP, but "n:false..false value false" with the modification. While it doesn't seem to do any harm that the variable is initialized, it would make a difference that the range is limited, and a statement like "n:=true" would fail (with some kind of range checking)... Sure, such things are not likely to occur in any real program, but perhaps in some test suites (and if not, they might have to be added to the test suites to claim really 100.00000% compatibility some time)... So, I guess, to remain compatible, the modification can be effective only with "--borland-pascal", or at least not with "--extended-pascal". But I don't know if it's possible to modify the parsing rules depending on switches. If not, I suggest to leave it as it is, and to issue a warning whenever such a thing is encountered, regardless of the switches, since it can be avoided in any case, as was shown, by parentheses or by an explicit type declaration (perhaps the text of the warning should also contain the solutions to avoid confusing people (like me) who encounter it for the first time). -- 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

BP Turbo Vision sources
by Jan-Jaap van der Heijden 24 Apr '97

24 Apr '97

Hello, I collected this discussion from comp.os.msdos.programmer.turbvision. Somebody claims to have gotten permission from Borland to release the BP Tvision sources to the public "as long as they are not sold". GNU Pascal is definately the "not for money" category so this may be interesting to us. Having Turbo Vision available would make it much easier to write attractive applications, at least for the djgpp/dos port of GPC. But I do think we should wait and see what happens next.... Greetings, JanJaap ========================================================================== Subject: TV Pascal sources ? From: marco(a)pool.informatik.rwth-aachen.de (Marco Schmidt) Date: 1997/03/29 Message-Id: <333d55d9.15365994(a)news.rwth-aachen.de> Newsgroups: comp.os.msdos.programmer.turbovision [More Headers] Hi, are there any Turbo Vision Pascal sources available as it is the case for C / C++ ? Thanks in advance, Marco -- Marco Schmidt - Student of Computer Science, Aachen, Germany mailto:marco@pool.informatik.rwth-aachen.de http://www.geocities.com/SiliconValley/Lakes/6686 PGP public key available on my web page - key fingerprint : 78 EC A5 87 34 56 F8 10 C2 6D AF A4 16 6C 08 76 ========================================================================= Subject: Re: TV Pascal sources . From: sukud(a)pncl.co.uk (sukud) Date: 1997/04/01 Message-Id: <5hq8mp$81f(a)soap.uunet.pipex.com> Newsgroups: comp.os.msdos.programmer.turbovision [More Headers] article <333d55d9.15365994(a)news.rwth-aachen.de>, marco(a)pool.informatik.rwth-aachen.de says... > >Hi, > >are there any Turbo Vision Pascal sources available as it is the case >for C / C++ ? > >Thanks in advance, >Marco >-- >Marco Schmidt - Student of Computer Science, Aachen, Germany >mailto:marco@pool.informatik.rwth-aachen.de >http://www.geocities.com/SiliconValley/Lakes/6686 >PGP public key available on my web page - key fingerprint : >78 EC A5 87 34 56 F8 10 C2 6D AF A4 16 6C 08 76 Yes there are. I think you can get them perhaps through your local Borland branch. But when I was traing to get source code for Delhi, the staff behaind the phone was confused when I sad source code of delhi component and was not able to help me. Having source code can be very usefull. For instance just for look, or for making some private part of objict not private, because I neet it. In my case I wanted to change object Tview and with it all his descendats. I wanted make there somethink like object inspector in Delphi, but more stupid. Petr Soukup sukud(a)pncl.co.uk ========================================================================= Subject: Re: Turbo Vision source code. From: "Wellige" <Wellige(a)itk.de> Date: 1997/01/10 Message-Id: <01bbfef7$a07dd940$bd9562c1(a)itk_ms_wellige.itk.de> Newsgroups: comp.os.msdos.programmer.turbovision [More Headers] Miguel Angelo Henley <michael(a)iis.com.br> wrote... > I'm looking for turbo vision source code for turbo pascal. > Where can I find it ? TV source code comes with BP7. As far as I know is the TV Pascal code not free as the C code already is. So I would be suprised if there is a chance to download it. Regards, Tom. -- Tom Wellige wellige(a)itk.de http://www.kst.dit.ie/people/twellige ========================================================================= Subject: TV Pascal Source (was Re: [Q] Need more than integer for TPoint From: sl65r(a)cc.usu.edu (Paul Hepworth) Date: 1997/04/17 Message-Id: <1997Apr17.190452.97084(a)cc.usu.edu> Newsgroups: comp.os.msdos.programmer.turbovision [More Headers] > I've already posted a request for source to this ng, but nobody knew > .. though I got some mails of people who'd like to have the source > code themselves. Sorry, nothing found so far. BP7 came with the source code to pascal TV. I think TP6 did as well, but I'm not positive (I gave away my tp6). I have the sources from BP7, but I haven't read whether Borland has given them to the public domain along with the c++ version or not. If they have, I can make the sources available from my web page. Anyone have a .borland.com URL that shows the public domaining of TV? ========================================================================= Subject: Re: TV Pascal Source (was Re: [Q] Need more than integer for TPoint From: "Wellige" <Wellige(a)itk.de> Date: 1997/04/18 Message-Id: <5j75uj$53o(a)news.Dortmund.Germany.EU.net> Newsgroups: comp.os.msdos.programmer.turbovision [More Headers] Paul, >BP7 came with the source code to pascal TV. I think TP6 did as well, but >I'm not positive (I gave away my tp6). I have the sources from BP7, but >I haven't read whether Borland has given them to the public domain along >with the c++ version or not. If they have, I can make the sources available >from my web page. Anyone have a .borland.com URL that shows the public >domaining of TV? A few weeks ago I spoke to someone from Borland Germany and he told me that the sources are free as long as they are not sold. It's definatley allowed to publish them e.g. on the Web. Sincerely, Tom -- Tom Wellige wellige(a)itk.de http://www.kst.dit.ie/people/twellige ========================================================================= Subject: Re: TV Pascal Source From: u6ed4(a)wvnvm.wvnet.edu (Cyber-Babushka) Date: 1997/04/18 Message-Id: <Pine.LNX.3.95.970418084428.211A-100000@seraphim> Newsgroups: comp.os.msdos.programmer.turbovision [More Headers] On Fri, 18 Apr 1997, Wellige wrote: >A few weeks ago I spoke to someone from Borland Germany and he told me that >the sources are free as long as they are not sold. It's definatley allowed >to publish them e.g. on the Web. In that case, if someone would please send me the Pascal sources, I would be happy to put them on the TVPlus web site as a courtesy. Would someone on the newsgroup please forward this request to the mailing list? My posts never make it through. I think I was put on review or something for posting the pointer to the FAQ too many times without changing it. Problem is, there's no listowner to take me off review, and I've written to the sysop without getting an answer. bonni http://wvnvm.wvnet.edu/~u6ed4/bonni.html C++ Turbo Vision archive: http://brooks.wvn.wvnet.edu/tvhome __ __ IC | XC | bonni mierzejewska "The Lone Quilter" ---+--- | u6ed4(a)wvnvm.wvnet.edu NI | KA | Kelly's Creek Homestead, Maidsville, WV ========================================================================= Subject: Re: TV Pascal Source (was Re: [Q] Need more than integer for TPoint From: codc01(a)gel.usherb.ca (Carl Eric Codere) Date: 1997/04/18 Message-Id: <codc01.255.0008B169(a)gel.usherb.ca> Newsgroups: comp.os.msdos.programmer.turbovision [More Headers] In article <5j75uj$53o(a)news.Dortmund.Germany.EU.net> "Wellige" <Wellige(a)itk.de> writes: >A few weeks ago I spoke to someone from Borland Germany and he told me that >the sources are free as long as they are not sold. It's definatley allowed >to publish them e.g. on the Web. Are you sure about this? There has been no official word on this from Borland USA, do you know where I can get more information, since each time I e-mail Borland, I do not get any reply! Carl Eric Codere (aka The Black One) Pascal and asm programming http://www-edu.gel.usherb.ca/codc01 ========================================================================= Subject: Re: TV Pascal Source (was Re: [Q] Need more than integer for TPoint From: "Wellige" <Wellige(a)itk.de> Date: 1997/04/21 Message-Id: <5jf56a$77m(a)news.Dortmund.Germany.EU.net> Newsgroups: comp.os.msdos.programmer.turbovision [More Headers] Carl, >Are you sure about this? There has been no official word on this from Borland >USA, do you know where I can get more information, since each time I e-mail >Borland, I do not get any reply! Thats what the guy from Borland Germany told me: it's ok for Borland to post them in newsgroups when explaining something. So it will be also ok to make them somewhere accessable on the net so one don't have to resend them everytime in a newsgroup. Sincerely, Tom -- Tom Wellige wellige(a)itk.de http://www.kst.dit.ie/people/twellige -- 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

New Alpha: EMX run time library broken?
by Peter Gerwinski 23 Apr '97

23 Apr '97

Hello, I was reported that the EMX run time library of the latest alpha GPC (gpc-970420) is broken: Not even `hello.pas' can be linked. Since I cannot reproduce the error on my own system (I can link even more complicated EMX programs here ... :-) I ask whether somebody else has observed the same problem. Perhaps there is a bug which only shows up in some configurations ... 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: New Alpha
by Frank Heckenbach 23 Apr '97

23 Apr '97

First of all: Thanks for implementing all the new features and removing many bugs! I like especially the packed arrays and records and the write(ln) with subranges! :-) Most of the bugs I reported in the last few months seem to have gone. However, the following still doesn't work (if it's already/still on the bug list, please ignore): PROGRAM x; CONST n:1..16=6; {"subrange bounds are not of the same type"} {The same with "var ...=...", ok with "var ... value ..."} BEGIN END. Then, a very small problem: I have a Pascal program (let's say foo.pas) that uses some units. I've put the following line into it: {$IFDEF __GPC__}{$automake="-O3"}{$ENDIF} It also needs some C functions contained in bar.c . If I compile it with "gpc foo.pas bar.c", it works fine. But if I do "gpc bar.c foo.pas", it doesn't ("Undefined references" to the C functions). In the latter situation also the file foo.gpc is left. It's no real problem since the first version works, but I just want to make sure if this is supposed behaviour (for any reason) or a little bug. BTW, the problem in Linux that I described is still there, but I solved it (temporarily) by moving cpp to cpp_ and putting the following script as cpp: #!/bin/sh /usr/lib/gcc-lib/i486-linux/2.7.2.1/cpp_ $* -U__GNUC_MINOR__ -D__GNUC_MINOR__=7 Probably not a very elegant solution, but it seems to work for now... -- 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

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