Gpc

gpc@gnu.de

5400 discussions

[ANN] Chief's Unzip v1.10 released
by Dr A A Olowofoyeku 15 Mar '99

15 Mar '99

Hi folks! Unzip comes to GPC! This is to announce the release of Chief's Unzip v1.10. This is a freeware package with sources for unzipping ZIP archives. The package supports GPC (January '99 beta: tested under Linux, mingw32, and djgpp); BP 7.0 (Dos, Dpmi, Win16); Delphi (Win16 and Win32), Virtual Pascal (OS/2 and Win32), and FreePascal (Dos, Linux). This package is a Pascal port of the InfoZip C sources. Example programs are included. Thanks to Frank for identifying some non-portable things in the previous releases and to Peter for supplying a "portable continuation". This is the URL to the package; http://ourworld.compuserve.com/homepages/African_Chief/chfzip11.zip PS: I would like to keep a list of the various GPC platforms on which the package has been used successfully, so if you are able to compile and use it successfully under anything other than Linux, mingw32 and djgpp, please drop me a line. If you have had to amend anything to make it compile/work correctly, please send me the diffs so that I can find ways of merging the changes into the main distribution. Best regards, The Chief -------- Dr. Abimbola A. Olowofoyeku (The African Chief) Email: laa12(a)keele.ac.uk Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ Author of: Chief's Installer Pro v5.00 for Win32 ftp://ftp.simtel.net/pub/simtelnet/win95/install/chief500.zip

2 2

new email, temporary (ii)
by stefand＠ferrari.lcam.u-psud.fr 11 Mar '99

11 Mar '99

Hallo, you are receiving this message because your name is in my nickname list, or because I have more or less recently received an email from you, sent to one of my accounts at the University of Tennessee, be that sad(a)utkux.utcc.utk.edu or sad(a)utk.edu or anything else along the lines of sad@..(ending in utk.edu). Unfortunately, the mail server on this is account is currently in a state of confusion about my person. Email sent to me bounces and the system claims that I don't exist or you have mistyped my name. These claims are greatly exaggerated. I have notified the sysadmins at UTK asking for it to be fixed asap. For now please use the following address to get in touch with me: stefand(a)lcam.u-psud.fr Please, take a note of it and update your nickname or email alias files accordingly. I will let you know as soon as my usual email address starts working again. The 'Reply-To:' header in my own email setup has been updated, so simple replies to recent email messages from me should work as expected. Kind regard & cheers, Stefan A. Deutscher PS1: This message is generated automatically. You should receive it only about once, and for email sent to any of my accounts at utk.edu. PS2: The local system being used to mail this message decided to mess up as well and some people received only an empty message. So I send it again, hoping that this should arrive in all its beauty.

1 0

new email (temporary)
by stefand＠ferrari.lcam.u-psud.fr 11 Mar '99

11 Mar '99

Hallo, I have more or less recently received an email from you, sent to one of my accounts at the University of Tennessee, be that sad(a)utkux.utcc.utk.edu or sad(a)utk.edu or anything else along the lines of sad@..(ending in utk.edu). Unfortunately, the mail server on this is account is currently in a state of confusion about my person. Email sent to me bounces and the system claims that I don't exist or you have mistyped my name. These claims are greatly exaggerated. I have notified the sysadmins at UTK asking for it to be fixed asap. For now please use the following address to get in touch with me: stefand(a)lcam.u-psud.fr Please, take a note of it and update your nickname or email alias files accordingly. I will let you know as soon as my usual email address starts working again. The 'Reply-To:' header in my own email setup has been updated, so simple replies to recent email messages from me should work as expected. Kind regard & cheers, Stefan A. Deutscher PS: This message is generated automatically. You should receive it only once, and for email sent to any of my accounts at utk.edu.

1 0

arrays of dynamic size
by scholle＠pol-15.uni-duisburg.de 11 Mar '99

11 Mar '99

Hi, Folks! I am still working on this damned dyn-array problem. For what reason is it that a construction of type MaxFirmenGroesse = ^integer; type workers = array [1..MaxFirmenGroesse] of (anything) does not work? Can you please tell me how the correct form would look like? Where is my mistake? -- Stefan Czinczoll scholle(a)uni-duisburg.de

2 1

Arrays with variable size?
by FSR SoWi 10 Mar '99

10 Mar '99

Hi, Folks! I am still working on my global working simulation and for performance reasons I thougt it would be better to use arrays of variable size (so that the machine will not go _completely_ to its knees ;-). Can you please give me some advice on this one? How has the declaration to look like? Thanks in advance -- Stefan Czinczoll scholle(a)uni-duisburg.de

2 1

Internal implementation of files
by Frank Heckenbach 07 Mar '99

07 Mar '99

Hi, this posting is about the internal implementation of Pascal files in the Run Time Systems. Most Pascal programs are not affected by this, so many programmers can just ignore this. In the C library, there are two kinds of file access routines. One kind of them is for integer file handles (which interface directly to the OS on most platforms), the others use `FILE *' pointers. They do internal buffering and some other things, and internally use integer file handles. Pascal files in GPC are currently based on `FILE *' pointers. I want to change them to use integer file handles, because I've found that using `FILE *' causes some disadvantages: - It's obviously less efficient to go through 2 extra layers (Pascal file -> FILE * and FILE * -> Integer) than only 1 layer. So this change should speed up file operations (though probably not by very much). - Both FILE * and Pascal files do internal buffering which is not only inefficient, but makes it hard to control how much data is read ahead. This is important for terminals, pipes etc. and currently involves some kludges to get it approximately right. - I've found that the semantics of FILE * and those of Pascal files don't really fit together well (e.g. the ways of representing run time errors or end-of-file), so currently a lot of RTS code deals with converting between those semantics. - By using integer handles, we get less dependent on bugs in routines out of our control. E.g., I just came across a bug (I think) in fwrite() (a FILE * routine) in a special situation, while write() (the corresponding integer routine) works correctly in this situation. Note, this does not mean that one should use integer file handles in Pascal programs, it's just about the way that `Text', `File' and `File of foo' are represented internally. The interface to Pascal programs would not change except for the 2 things that currently deal with FILE * (aka CFilePtr): - AssignCFile and the CFile field of BindingType. I added them only recently, so most of you probably don't even know they exist. ;-) They are needed for some purposes in the RTS and the units, but I could do the same with integer handles. - The GetFile function which currently returns the FILE * of a Pascal file. This function would vanish, and instead there would be GetFileHandle which does the same that currently `FileNo (GetFile (f))' does. Since most usages of GetFile that I'm aware of are in fact together with FileNo, this change would actually simplify those programs. A problem would only be there if a program really uses the FILE * for anything directly. However, a solution using fdopen() seems possible. So, if there are no protests, I'm going to do this change until the next release. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

conformance tests
by hchang-tky＠umin.u-tokyo.ac.jp 24 Feb '99

24 Feb '99

I am developing a Pascal interpreter adapted for simulation of biological systems. I want to check my interpreter, and could you please let me know how (or if) I can get conformance tests? Thank you. Hangil Chang.

2 1

Re: bug in sin/cos (longreal) ?
by Frank Heckenbach 24 Feb '99

24 Feb '99

Maurice Lombardi wrote: > Hi all, > I have found a strange bug which popped up in the last beta. > when compiling the following short program > > program bug; > var x:real; y:LongReal; > begin > x:=1; y:=1; > writeln(cos(x)); > writeln(cos(y)); > writeln(cos(pi*x)); > end. > > the linker says that it cannot find module cosl (* Not module cosl, but the C routine cosl(). *) > in the lines containing the second and third writeln > which demand for cos(longreal) either directly > or indirecly (presumably pi is long real). Yes, that's a new bug. Since it only shows on systems without cosl() etc. in their libm, like DJGPP, we didn't note it so far. Here's the fix, if you have the GPC sources and can recompile them: diff -p -r -U3 -N -X /home/frank/script/gpcdiff.exclude orig/p/rts.c p/rts.c --- orig/p/rts.c Wed Feb 17 21:56:06 1999 +++ p/rts.c Wed Feb 24 02:01:13 1999 @@ -78,16 +78,16 @@ struct rts_symbol rts[] = { { r_COLLECT,"_p_collect", NULL_RTX, NULL_TREE, 0}, - { p_ARCTAN, "atan", NULL_RTX, NULL_TREE, 0}, - { p_COS, "cos", NULL_RTX, NULL_TREE, 0}, + { p_ARCTAN, "_p_arctan", NULL_RTX, NULL_TREE, 0}, + { p_COS, "_p_cos", NULL_RTX, NULL_TREE, 0}, { p_EXP, "_p_exp", NULL_RTX, NULL_TREE, 0}, { p_LN, "_p_ln", NULL_RTX, NULL_TREE, 0}, - { p_SIN, "sin", NULL_RTX, NULL_TREE, 0}, + { p_SIN, "_p_sin", NULL_RTX, NULL_TREE, 0}, { p_SQRT, "_p_sqrt", NULL_RTX, NULL_TREE, 0}, - { pp_ARCTAN, "atanl", NULL_RTX, NULL_TREE, 0}, - { pp_SIN, "sinl", NULL_RTX, NULL_TREE, 0}, - { pp_COS, "cosl", NULL_RTX, NULL_TREE, 0}, + { pp_ARCTAN, "_pp_arctan", NULL_RTX, NULL_TREE, 0}, + { pp_SIN, "_pp_sin", NULL_RTX, NULL_TREE, 0}, + { pp_COS, "_pp_cos", NULL_RTX, NULL_TREE, 0}, { pp_EXP, "_pp_exp", NULL_RTX, NULL_TREE, 0}, { pp_LN, "_pp_ln", NULL_RTX, NULL_TREE, 0}, { pp_SQRT, "_pp_sqrt", NULL_RTX, NULL_TREE, 0}, Otherwise, you can work around the bug until the next release by linking the following C file: #include <math.h> long double sinl (long double x) { return sin (x); } long double cosl (long double x) { return cos (x); } long double sqrtl (long double x) { return sqrt (x); } long double logl (long double x) { return log (x); } long double expl (long double x) { return exp (x); } long double atanl (long double x) { return atan (x); } long double powl (long double x, long double y) { return pow (x, y); } Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

bug in sin/cos (longreal) ?
by Maurice Lombardi 23 Feb '99

23 Feb '99

Hi all, I have found a strange bug which popped up in the last beta. when compiling the following short program program bug; var x:real; y:LongReal; begin x:=1; y:=1; writeln(cos(x)); writeln(cos(y)); writeln(cos(pi*x)); end. the linker says that it cannot find module cosl in the lines containing the second and third writeln which demand for cos(longreal) either directly or indirecly (presumably pi is long real). It popped up when I tried to recompile old programs which used a lot of cos(pi* ). With grep I do not find cosl (and sinl) in any library, only in gpc1.exe (and similars cc1.exe cc1plus.exe f771.exe). Have I missed something in the installation ? (I work with DJGPP / gpc-19990118_i386-pc-djgppv201.zip) thanks in advance ! -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: +33 (0)4 76 51 47 51 Fax: +33 (0)4 76 51 45 44 mailto:Maurice.Lombardi@ujf-grenoble.fr

1 0

demo
by Russ Whitaker 22 Feb '99

22 Feb '99

tried to compile "pi.pas" and got as far as ld: cannot open -lgmp: No such file or directory so how do i create -lgmp and what directory does it belong in? thanks Russ russwhit(a)mind.net

2 1

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