Gpc

gpc@gnu.de

5400 discussions

Re: Programmers wanted: CRT, Graph, etc. for GNU Pascal
by Peter Gerwinski 25 Jul '96

25 Jul '96

Berend de Boer wrote: > The point of having an extended pascal compiler > is being portable, at least that's the goal. I agree to the goal of being portable. But I don't think that we can reach this goal just by obeying the Extended Pascal standard. (More about this in a separate mail.) > Assembler and Dos are not the way to go. The point of having a > System, Crt, Printer of Graph unit is entirely uninteresting if it is not > portable except if you want to port Dos Borland Pascal programs to Extended > Pascal. I want to port DOS Borland programs to *GNU Pascal*, and I am sure that many people intend the same. System, Crt, Printer and Graph for GNU Pascal would be *highly interesting* for those programmers who are accustomed to Borland Pascal and think about changing to GNU Pascal (instead of changing to Delphi or C++) in the future. To have those Units on the DOS platform only would be a starting point -- portable versions would be preferred, of course. > Why should anyone want to do this? I assume everyone is programming for > Windows 95/Windows NT or Unix. Are programmers really running Dos today?? Yes, I am for example. More concrete, I am working in an OS/2 DOS box and in the Linux DOSemu (with Novell DOS 7). I do not intend to use Windows 95 or Windows NT, and it will take a long time to get my clients using UNIX (Linux). Up to that day, I will prefer writing good DOS programs to writing poor Windows programs (with a lot of special effects, but slow, uncomfortable, and unstable). In the long term, I intend to become completely platform independent with my BO5 library, i.e. my programs will run under Windows 95/NT, too, just be recompiling. But for the moment, I am stuck with DOS. > Quite a few calls in System or Crt do simply not apply in non-Dos > environments. There are really few of them, but since the source exists, I suggest that somebody ports *everything* to the DOS version of GPC, and we can make the "potentially portable" parts portable in a second stage. > A portable Printer library?? What's the problem? It would just be a Unit (Module) which "knows" the file name of the printer device for the actual operating system and opens a text file "lst", so the application program doesn't need to care about how the printer is named on the operating system. > The calls from System that are portable can for 90% be written in plain > Extended Pascal. However, it would be nice to have a compatibility Unit (Module) which simplifies the port of Borland Pascal programs to GNU Pascal. > We should do better by following existing standards and provide EP > interfaces for that. Borland's Units *are* an existing standard. There may be other standards, but I think these Units are very popular. Furthermore, we *have* the source for them, so I ask again: ******************************************************* We have free sources of Borland Units (CRT, Graph, ...) which cry for being ported to GNU Pascal. Anybody wants to do the job? ******************************************************* Greetings, Peter

2 2

Re: The purpose of GNU Pascal
by Berend de Boer 24 Jul '96

24 Jul '96

> By the way: Where are those many different Extended Pascal compilers? You have Prospero's compilers for Dos/Windows and OS/2, DEC has a Pascal compiler on VAX which implements almost all of the Extended Pascal standard. I'm not sure of the Macintosh, there is a Pascal compiler on the Mac from Warriar, but if that one implements Extended Pascal?? I'm going to research that today. > You don't lose portability by simply including bit-shift operators, objects, etc. into > the Extended Pascal standard. But they didn't include them. No idea, why. Objects are in another standard. bit-shift operators have to depend upon memory layout and byte ordering. But I agree with you that they should be available. > And what about, say, user-defined operators which are almost a *must* for scientific calculations? I completely agree with you that user-defined operators are a must in a field where those operators defined. In most other areas they are not. We can probably atttach a dozen explanations to the following construct: House := PersonA + PersonB; The example you gave had exactly one meaning clear to everyone. > But I don't intend to spend my time with trying to satisfy standard specifications I don't realize their > sense. I can quite agree with you. But don't forget: there are millions, literally millions of code written in some form of Standard Pascal out there in the world. For such people an alternative in the form of GNU Pascal could really be interesting. > How would you define "real Pascal spirit"? Let the compiler do as much as possible for you: basically that comes down to no untyped pointers. I *have* to use much more untyped pointers in Borland Pascal (in obtaining addresses from procedures, strings, etc.) than would be necessary. > Extended Pascal may be good, but GPC will be even better. It is time to set up the next standard! Completely agreed. I can accept the modifications to GPC.GUIDE you presented. Of course a compiler which accepts Borland Pascal syntax is a major advantage. Makes porting much easier. And if you really have good alternatives for Borland's standard libraries... Groetjes, Berend.

2 1

Re: Extended Pascal
by Berend de Boer 24 Jul '96

24 Jul '96

>> Last time I really looked at gpc (beginning 1995) it missed simply too much. > What is missing? If you publish a list, perhaps somebody would like > to do the job of implementing it. OK, I hope to present a list of missing features to this list within a few days. Groetjes, Berend.

1 0

Re: Programmers wanted: CRT, Graph, etc. for GNU Pascal
by Berend de Boer 24 Jul '96

24 Jul '96

>> What use does it have when you already have a good Dos compiler, i.e. Borland >> Pascal? It fullfills all my needs for the Dos environment. > Not mine, and when you look into comp.lang.pascal.borland you will find Yes, I did see your problem, but I never encountered these things. My units are small, so I don't have codesegment faults, and for large arrays I have a few objects of my own which either use XMS/EMS or conv memory to present large arrays. But I see. I make a Posix interface for GPC first and present any difficulties I encounter to you so you can make the necessary changes to the compiler ok? > Note, I HAVE the source of the Graph unit!!! Ah, I now remember you saying this, but shouldn't this be: I have the source of a Graph unit? >> - qualifed imports available? > What's that? To reference a symbol from these modules you always need to add the module name as prefix. Maybe I don't need this now, I'll see. OK, I see if I can write something with gpc. I'll tackle the Posix interface and the Dos unit first. I start using djgpp's port. Which one should I take? Groetjes, Berend.

1 0

Re: The purpose of GNU Pascal
by Berend de Boer 24 Jul '96

24 Jul '96

> Furthermore, I could not write my real-world programs > just with Extended Pascal; I need, for example, bit shift operators, GetMem, > FreeMem, and Objects. You don't need GetMem and FreeMem as I did show you :-) But you need the other two. > and integrate them in one powerful compiler which will set up the next standard. I certainly don't agree with this if the compiler does not have switches to accept only Extended Pascal or only ISO Pascal or only ... Programs conforming to the Extended Pascal will probably not only work in many different environments but also with many different compilers. I don't want to loose that feature/possibility. Extending a compiler with more features is not a problem, but IMO, one should complete the standard parts first. > It is okay to support Extended Pascal (why not?), but in my opinion, > Extended Pascal is not clear and powerful enough to serve as "the new > Pascal standard", so programmers are not motivated to switch from > Borland Pascal to Extended Pascal. I think, this is the reason why > computer vendors do not provide Extended Pascal compilers. Hmm, I don't think that Extended Pascal is not powerful enough. It's true that it does not contain everything one needs, but that's mainly due to the goal of creating a portable language. And the new object standard also rectififies some omissions. I can create everything I want in Extended Pascal programs with only a few routines accessing non-standard parts, mainly concerning bit-operators (you can do this with Extended Pascal, but it's a bit more tedious), and system call access (assembly). A compiler which accepts every Pascal standard and does everything would be nice of course. But there is quite some work to do. So I would like to add that we first focus on the ISO Pascal and Extended Pascal part. Even the ISO Pascal standard, according to Scott Moore (have email address if anyone wants it), needs much looking after. Don't overlook the Pascal standards boys (no girls here I assume). They do much more than you think, but different than Borland Pascal which has quite a C feeling and lost too much of it's real Pascal spirits. Groetjes, Berend.

2 1

Re: Programmers wanted: CRT, Graph, etc. for GNU Pascal
by Berend de Boer 24 Jul '96

24 Jul '96

> There are really few of them, but since the source exists, I suggest > that somebody ports *everything* to the DOS version of GPC, and we can > make the "potentially portable" parts portable in a second stage. What use does it have when you already have a good Dos compiler, i.e. Borland Pascal? It fullfills all my needs for the Dos environment. Besides, what do you mean by 'porting', i.e. should do exactly the same with every quirk inherited or just similar enough? The system unit can be implemented easily, I've done already that for 90%. A few things you can't do like Inc, and some functions which have overloaded parameters (Assign, Close, ...). If similar is good enough, I suggest we define a POSIX interface first, starting from the one I wrote for Dos, and build the Dos unit on top of that. We can do the Crt unit in the same manner, building on top of the curses library. > We have free sources of Borland Units (CRT, Graph, ...) Note, you don't have the source of the Graph unit. >From my viewpoint, Borland Pascal does everything, so spending time for a Dos only solution is not a thing I want. And it is not necessary. And is gpc already for such projects? I see some problems with gpc as I know it: - no renaming, necessary to avoid clashing with c libraries. - qualifed imports available? - how to link with C libraries? You have the c; construct, but exactly how does it work? What does it do? Groetjes, Berend.

2 1

Re: GPC: "how to contribute" file -- job list
by J.J. van der Heijden 24 Jul '96

24 Jul '96

On Fri, 5 Jul 1996 11:01:03 +0200 (MET DST), Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> wrote: [snip] > > List of jobs > ------------ > [snip] > DJ version (DOS) JanJaap works I came across a new DJGPP app called "rhide" It's a Borland-clone IDE that works with djgpp (C & C++) I'll see if I can hack it to work with GPC. Would make a neat Turbo Pascal replacement ;) > > Installation instructions Larry ? > Documentation Larry ? > Larry, if you're there: I rewrote much of the installation notes. Also, I took a "Using and porting GCC" manual, did a "search GCC -- replace with GPC" action, TeXi-fied much of the existing readme's and put it all together. Let me know how to send this stuff to you. > > Run time system Juki works I have preliminary, new "autoconf" scripts for RTS. Should reduce configuration to "configure ; make". Handles all CFLAGS, platform dependant includes etc. I'll see if I can do something simular for GPC itself. Some other RTS related remarks: *) GNU is going international. How about adding localization to RTS? Won't work if you're not on un*x, but can be buildtime selectable (flag to autoconf script) *) How 'bout RTS as an ELF shared library? *) Documentation again: RTS needs documentation. I looked at the Cygnus and DJGPP C libraries and they use Texinfo fragments in the source, extract it with some utility to one big texinfo file. That way it's easy to keep documentation up to date. > Replacement for (parts of) CRT Peter beta (BO5) > Replacement for Graph Peter planned > Replacement for Turbo Vision Peter planned > Now, if somebody would port TVision to un*x (use termcap / info instead of direct screen writes) it would probably be not too much work to port this RHIDE thing to unix. Then you have an IDE. (sorry guys, I'll never be a fan of emacs) /janjaap --- Thus spake the master programmer: "After three days without programming, life becomes meaningless." [The Tao Of Programming]

1 0

Extended Pascal
by Peter Gerwinski 23 Jul '96

23 Jul '96

Berend de Boer wrote: > I would do that when the Extended Pascal port is completed and the object > extensions are added (I think it's not wise to use Borland style objects). Why not? Borland style objects have some advantages with respect to those of Object Pascal (Delphi). Concerning portability, GNU Pascal itself is portable, and I don't know any Object Pascal compiler except Delphi. (I have heared about Object Pascal for the Apple Macintosh, but never seen it.) So there is no compiler around (except those of Borland) to preserve compatibility to. > Last time I really looked at gpc (beginning 1995) it missed simply too much. What is missing? If you publish a list, perhaps somebody would like to do the job of implementing it. Or do it by yourself -- it should be relatively easy since Borland style objects work in GNU Pascal. Yours, Peter ******************************** ATTENTION: New e-mail address! ******************************** -------------------------------------------------------------------------------- Dipl. Phys. Peter Gerwinski Fachbereich Physik Universitaet-GH Essen Phone: +49-201-183-2763 D-45117 Essen Fax: +49-201-183-2120 Germany e-mail: peter.gerwinski(a)uni-essen.de --------------------------------------------------------------------------------

1 0

Turbo Vision, IDE
by Peter Gerwinski 23 Jul '96

23 Jul '96

Jan Jaap van der Heijden wrote: > Now, if somebody would port TVision to un*x (use termcap / info instead of > direct screen writes) it would probably be not too much work to port this > RHIDE thing to unix. Then you have an IDE. (sorry guys, I'll never be a fan > of emacs) I am working on something similar to a port of Turbo Vision to UNIX and any other operating system I can access. The project is called BO5; version 0.0.1 was released on 19. December 1995. For more information about BO5 look at ftp://kampi.hut.fi/jtv/gnu-pascal/turbo-alpha/README.BO5. By the way: There is a Borland-style IDE for Linux called XWPE. Look at the Debian distribution of Linux in the subdirectory source/devel. Yours, Peter ******************************** ATTENTION: New e-mail address! ******************************** -------------------------------------------------------------------------------- Dipl. Phys. Peter Gerwinski Fachbereich Physik Universitaet-GH Essen Phone: +49-201-183-2763 D-45117 Essen Fax: +49-201-183-2120 Germany e-mail: peter.gerwinski(a)uni-essen.de --------------------------------------------------------------------------------

1 0

Re: GPC: "how to contribute" file -- job list
by Berend de Boer 23 Jul '96

23 Jul '96

> Now, if somebody would port TVision to un*x (use termcap / info instead of > direct screen writes) it would probably be not too much work to port this > RHIDE thing to unix. Then you have an IDE. (sorry guys, I'll never be a fan > of emacs) I would do that when the Extended Pascal port is completed and the object extensions are added (I think it's not wise to use Borland style objects). Last time I really looked at gpc (beginning 1995) it missed simply too much. Groetjes, Berend.

1 0

Jump to page:

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