Gpc August 1997

gpc@gnu.de

23 participants
88 discussions

Re: Pointer & GPC question...
by Dr E. Buxbaum 27 Aug '97

27 Aug '97

> From: Orlando Llanes <a010111t(a)bc.seflin.org> > To: GNU Pascal Mailing List <gpc(a)hut.fi> > Subject: Re: Pointer & GPC question... > Date sent: Tue, 26 Aug 1997 13:11:28 -0400 > Cool, so would the admin have to install it? Or could it be >installed by a > normal user? Another thing I'm curious of is does Linux use or support DPMI > in it's native state? Or does it have it's own proprietary memory scheme? DPMI (Dos Protected Mode Interface) is a technique to allow the Dos operating system (which is 16 bit) to run 32-Bit software. Linux is a true 32 bit OS (on a x86 PC, anyway) and therefore does not require DPMI or similar crutches. One thing less to take care off...

1 0

Re: Can't run gpc_970714 :-(
by Ken Linder (KC7RAD) 26 Aug '97

26 Aug '97

At 11:06 PM 8/25/97 +0200, Peter Gerwinski wrote: >Okay, next try: Please run `gpc -E t1.pas'. The result >should look like the following: > > # 1 "t1.pas" > program t1; > > begin > writeln('test'); > end. > >(* I.e., your program with `# 1 "t1.pas"' in front of it. *) Yes, indeed! This is what I received after using the -E option > >If you get this, run `gpc -dY t1.pas'. The result should be >almost the same: > > 1"t1.pas" > program t1; > > begin > writeln('test'); > end. > Well, using the -dY option, I received the same errors as before... Should I start crying yet????? ;-) Good luck & thanks! Ken L.

1 0

Re: Can't run gpc_970714 :-(
by Peter Gerwinski 26 Aug '97

26 Aug '97

According to Ken Linder: > > Well, using the -dY option, I received the same errors as before... But GPC must also copy the source to the standard error device. How does that output look like? Does the error message go before or after the first source line? 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 [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Pointer & GPC question...
by Peter Gerwinski 26 Aug '97

26 Aug '97

According to Orlando Llanes: > > I know I'm pushing the envelope with this series of e-mails, so if it's > off-topic, then reply by e-mail, we'll discuss it there, and I'll post a > summary to the list if desired. Since it's about developping a library for GNU Pascal, it's on-topic. Please go on - it's very interesting. :-) > Cool, so would the admin have to install it? Or could it be installed by a > normal user? The admin. > Another thing I'm curious of is does Linux use or support DPMI > in it's native state? Or does it have it's own proprietary memory scheme? It has its own memory scheme. Well, I wouldn't call it "proprietary" since everything in the Linux kernel is FREE. ;-) Memory in Linux is much easier than in DOS because it uses a flat model - just forget about segment addresses, selectors and such. For details use the kernel source - it is always with you ... > If anybody has a suggestion on something to add, any ideas, or would like > me to send them the game lib specs, feel free to e-mail me. Your plan looks very good; just a general remark: Be careful when porting things from DOS to Linux. Some of the most useful features of DOS, DPMI for example, are just a workaround for other things that are implemented in a much cleaner and easier way in Linux. :-) 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 [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Pointer & GPC question...
by Orlando Llanes 26 Aug '97

26 Aug '97

I know I'm pushing the envelope with this series of e-mails, so if it's off-topic, then reply by e-mail, we'll discuss it there, and I'll post a summary to the list if desired. Cool, so would the admin have to install it? Or could it be installed by a normal user? Another thing I'm curious of is does Linux use or support DPMI in it's native state? Or does it have it's own proprietary memory scheme? > From: Michael Meeks <michael(a)zeus.imaginator.com> > Because ... this would invalidate all the security measures. At > ... > is youre uncle ( perhaps ). oh, and make the program run suid to that For the time being, I'll create wrappers for SVGALib. I'm not just creating a graphics lib, I'm creating a cross platform game programming lib (yes I'm aware of SVGALib ported to the PC, but it's buggy). I'm looking at how things are done on different OS's so I don't take a wrong turn with my lib. For example, while I was planning the Mode-X support and working on VBE support, I realized that graphics on the Macintosh are different (I decided to "emulate" these modes on the Mac if possible). > I would just use SVGAlib myself, as it is supported, and supports > lots of hardware + there is llittle point in duplicating effort ! :) and > IIRC it supports off screen buffers etc. The architecture I'm using for the graphics portion of the game lib is similar in concept to a loadable device driver, but it will use objects: * A unit defines a base object and is used as a pointer to the other objects in the "generic" unit * Each object overrides the base API * Methods added are proprietary to the object, otherwise there is no need to extend the base object API further * According to certain mode ranges, a specific object is initialized (de-initializing the previous one if neccessary) and the object base pointer is set to that of the new object * An off-screen buffer is allocated by the object * Error codes are returned so the programmer can handle errors and so that the programmer knows where the objects failed (memory error, driver failure, etc) * The off-screen buffer is exposed so that the programmer can implement their own custom routines, special effects, 3-D routines, etc * First set of inherited objects will support VBE 256/32k/64k/16M color modes, VGA, 3 to 7 Mode-X resolutions (VBE LFB will be supported after the VBE engine is in place) * Expandable to support triple buffering (I haven't fully thought this out yet) * Custom mouse handlers (also not fully thought out yet) with support for monochrome or 256/hi/true color cursors If anybody has a suggestion on something to add, any ideas, or would like me to send them the game lib specs, feel free to e-mail me. My goals are to make the libs logical, tight coded, handling as much of the platform/OS specific details as possible (Device Context Handles in Windows for example), to make the lib Modular yet Integrated, to provide flexibility, to make it easily extensible, and to provide a "load on use" style so that only what's needed is loaded. See ya! Orlando Llanes

1 0

Re: Diff Utility for the PC...
by Peter Gerwinski 26 Aug '97

26 Aug '97

According to Orlando Llanes: > > Does anybody know of a non-cryptic Diff utility for the PC? What do you consider "non-cryptic"? And what do you mean with "PC"? On my PC I use GNU diff exclusively, on Linux or FreeBSD as well as on [Caldera|DR|Novell|MS]-DOS (DJGPP); probably an OS/2 port (EMX) also exists. GNU diff is very configurable. If you don't like its default output # diff gpc-oldgcc/p/gpc-lex.c gpc-egcs/p/gpc-lex.c [...] 1966c1971 < error ("integer constant does not fit in integer type"); --- > error ("value does not fit in longest integer type"); use either the `-c' option to get a "context diff": # diff -c gpc-oldgcc/p/gpc-lex.c gpc-egcs/p/gpc-lex.c [...] *** 1963,1969 **** else { /* should be effectively unreachable */ ! error ("integer constant does not fit in integer type"); type = integer_type_node; } TREE_TYPE (yylval.ttype) = type; --- 1968,1974 ---- else { /* should be effectively unreachable */ ! error ("value does not fit in longest integer type"); type = integer_type_node; } TREE_TYPE (yylval.ttype) = type; or the `-u' option to get a "unified diff" (my preferred format): # diff -u gpc-oldgcc/p/gpc-lex.c gpc-egcs/p/gpc-lex.c [...] @@ -1963,7 +1968,7 @@ else { /* should be effectively unreachable */ - error ("integer constant does not fit in integer type"); + error ("value does not fit in longest integer type"); type = integer_type_node; } TREE_TYPE (yylval.ttype) = type; or type `diff --help' to get all options listed. Hope this helps, 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 [970714] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

Diff Utility for the PC...
by Orlando Llanes 26 Aug '97

26 Aug '97

Does anybody know of a non-cryptic Diff utility for the PC? -- See ya! Orlando Llanes

1 0

GNU Pascal questions
by Fausto Iannuzzi 25 Aug '97

25 Aug '97

Hi! I have read it's possible to call gcc functions from a gpc program or unit adding "C;" to functions' declaration. Is it also possible to call or use gpc functions, or generally gpc code, from a gcc program? Does gpc support operator overloading? Thanks. bye, Fausto. Reply addresses: fausty(a)itb.it (primary - local provider) fausty(a)peacelink.it (gateway - please no files here) Homepage: www.itb.it/users/fausty/welcome.html

1 0

Re: Can't run gpc_970714 :-(
by Peter Gerwinski 25 Aug '97

25 Aug '97

According to Ken Linder: > > I tried it and this is what I got: > [...] > > /tmp/cca00301.i:1: numeric constant with no digits > [...] That's indeed funny - I don't see any problem here. Okay, next try: Please run `gpc -E t1.pas'. The result should look like the following: # 1 "t1.pas" program t1; begin writeln('test'); end. (* I.e., your program with `# 1 "t1.pas"' in front of it. *) If you get this, run `gpc -dY t1.pas'. The result should be almost the same: 1"t1.pas" program t1; begin writeln('test'); end. (* Actually, it should be the same, but that's a minor bug in gpc-lex.c. #*) Thanks for your cooperation, 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 [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Can't run gpc_970714 :-(
by Ken Linder (KC7RAD) 25 Aug '97

25 Aug '97

At 03:22 PM 8/25/97 +0200, Peter Gerwinski wrote: ...snip... > > gpc -v <other options> foo.pas -o foo > ^^ >and post the result here? > Hi Peter, I tried it and this is what I got: { the command: } [klinder@kenslinux klinder]$ gpc -v t1.pas -o t1 { the result } gpc version 970714(2.7.2.1) /usr/lib/gcc-lib/i586-unknown-linux/2.7.2.1/gpc-cpp -lang-pascal -v -nocharescape -undef -D__GNUC__=2 -D__GPC__=2 -D__GNUC_MINOR__=7 -D__ELF__ -Dunix -Di386 -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__linux__ -D__unix -D__i386 -D__linux -Asystem(unix) -Asystem(posix) -Acpu(i386) -Amachine(i386) -D__i486__ t1.pas /tmp/cca00301.i GNU CPP version 970714(2.7.2.1) (i386 Linux/ELF) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/i586-unknown-linux/include /usr/lib/gcc-lib/i586-unknown-linux/2.7.2.1/include /usr/include End of search list. /usr/lib/gcc-lib/i586-unknown-linux/2.7.2.1/gpc1 /tmp/cca00301.i -quiet -dumpbase t1.pas -version -famtmpfile=t1.gpc -o /tmp/cca00301.s GNU Pascal version 970714(2.7.2.1) (i386 Linux/ELF) compiled by GNU C version 2.7.2.1 /tmp/cca00301.i:1: numeric constant with no digits /tmp/cca00301.i:1: numeric constant with no digits /tmp/cca00301.i:1: invalid #line /tmp/cca00301.i:2: warning: missing program header /tmp/cca00301.i: In function 'program_noname': /tmp/cca00301.i:2: parse error at null character { now the program } program t1; begin writeln('test'); end. {***************** whew *****************} I thought perhaps something was funny with my Linux setup so I freshly installed RedHat 4.1 on a i486. Exact same thing (except for the temp file name) So, same result on three different computers, all with RedHat 4.1 installation. A laptop, and two desk-tops. Ver 2 of GPC works great! I removed the 970714 files and untared version 2. It works great!!! Good Luck! If anything becomes obvious to me I will let you know! Thanks! Confused in Las Vegas... Ken L.

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

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