March 1999 - Gpc

Re: [ANN] Chief's Unzip v1.10 released
by Frank Heckenbach 15 Mar '99

15 Mar '99

Dr A A Olowofoyeku wrote: > Unzip comes to GPC! This is to announce the release of Chief's Unzip > v1.10. [...] > > 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. Works fine under Linux, as far as I can tell, but is missing some error handling (e.g. given an invalid zip file name, it says "-12 files processed"). Crashes with Bus error under Solaris when trying to access a zip file. I suppose it's an endianness problem with the file contents. You might want to look at the "Routines to handle endianness" in gpc.pas. Frank PS: I'd prefer lower case file names (in the sample command lines, the files themselves etc.), because upper case file names are quite uncommon on those systems where it makes a difference. -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

2 1

[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