Gpc

gpc@gnu.de

5400 discussions

Gpc and MacOS?
by Jo Dillon 10 Apr '99

10 Apr '99

Is there any way - any way at all - to get GPC to produce MacOS binaries? I have a huge chunk of code in Turbo Pascal-flavoured Object Pascal I need to port to the Mac. Metrowerks' Object Pascal compiler speaks a different dialect of the language - no virtual keyword (override's instead), no polymorphic functions (you can only override if you use the same parameters), and no constructors or destructors. Does anyone have any idea how this might be achieved? Getting 60,000-odd lines of Object Pascal to compile on the Mac is going to be a nightmare. -- Jo

2 1

Small and unimportant suggestion
by Jo Dillon 10 Apr '99

10 Apr '99

Perhaps you could indicate (in the diffs directory of the source) which release numbers of egcs the patches correspond to? If you've just downloaded egcs 1.1.1 and haven't built it yet it's hard to find out that it's actually egcs-2.91.60; if you /have/ built it yet then it's a bit late to patch the source. -- Jo

2 1

Re: FV4GPC (was Free Vision)
by The African Chief 10 Apr '99

10 Apr '99

Peter Gerwinski wrote: > > The African Chief wrote: > > > > I do not have the energy, time, or even the knowhow to port the > > other FV units (especially those with asm code in them) to GPC, > > so others will have to take on that task on (IIRC Peter is > > looking into doing this - am I right, Peter?). > > Yes, but the amount of other things I have to do is ... well ... > nicht mehr feierlich (= no more solemn; means: no joke). > Better don't hold your breath. :-( Ok. Are there any other takers? > > AFAICS the FV license terms are not GPL compatible and there may > > be other copyright issues that will make the ported FV Objects > > unit not distributable with GPC. > > That's indeed a problem, but I think that they did not decide to > be incompatible to the GPL but just wrote their license in a > careless way. I would be glad if someone could take over the > negotiations. I wrote to the alleged overseer of the FV project quite a while ago - I never got any response. I suppose I could write to Florian Klaempfl (who oversees the FPC development) and see what he can do. > > If anyone is interested, I can > > make a copy of my current "development" version available > > (perhaps on my homepage). > > I can set up a link to that project from the main GPC homepage > if that makes some sense. Or else we can place a homepage for > the FV4GPC project on Agnes in the GPC homepage tree. > > Any thoughts? I would think that Agnes is the best place for it, so the latter idea seems preferable. Basically, I have finished with the Objects unit. That could probably go on immediately (with the caveats [a] that EGCS-based GPC users on Linux and Win32 will not be able to compile the unit until the "New(pFile)" problem is solved, [b] that, for those on Solaris, etc., there may be "endian" issues that I am unaware of). We could just put the Objects unit there, since that is already ported to GPC - or we could put the whole package there for people to see what is required to port the rest of the units to GPC. Any thoughts? -- Best regards, Dr Abimbola A Olowofoyeku (The African Chief) Author of Chief's Installer Pro v5.0 for Win32 Email: laa12(a)keele.ac.uk Homepage: http://ourworld.compuserve.com/homepages/African_Chief

1 0

Re: move-string bug?
by Frank Heckenbach 10 Apr '99

10 Apr '99

Russ Whitaker wrote: > hi Frank > is this a miss-use of move, a bug, or something that has already been > fixed? The former. The capacity is stored internally as the first field of a string, so if you move to "temp", you'll overwrite temp's capacity. What you can do (and that's about the only case where a "move" seems acceptable besides low-level stuff) is to move the characters of a string, like the following: program astrings; var srcstr : string(255); temp : string(120); begin srcstr := 'abcdefghi'; writeln( srcstr.capacity, ' ', length(srcstr), ' ', srcstr); writeln( temp.capacity ); move( srcstr [1], temp [1], length(srcstr)); writeln( temp.capacity, ' ', length(temp), ' ', temp); {$X+} SetLength (temp, length (srcstr)); {$X-} writeln( temp.capacity, ' ', length(temp), ' ', temp); end. However, as you see in this program, to modify the length of a string, you need `SetLength', and this requires extended syntax, so I don't really recommend this method. It's usually easier to use the existing string operations (in this case, of course, a simple `:=' assignment would do, but I assume you have something more complicated in mind -- if you don't know how to achieve it with the string operations, be welcome to ask). Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

move-string bug?
by Russ Whitaker 10 Apr '99

10 Apr '99

hi Frank is this a miss-use of move, a bug, or something that has already been fixed? gpc version 19990118, based on gcc-2.8.1 program as follows: program astrings; { show string bug } var srcstr : string(255); temp : string(120); begin srcstr := 'abcdefghi'; writeln( srcstr.capacity, ' ', length(srcstr), ' ', srcstr); writeln( temp.capacity ); move( srcstr, temp, length(srcstr)); writeln( temp.capacity, ' ', length(temp), ' ', temp); move( srcstr, temp, length(srcstr)+8); writeln( temp.capacity, ' ', length(temp), ' ', temp); end. Output is as follows: 255 9 abcdefghi 120 255 9 a 255 9 abcdefghi thanks, russ

1 0

Re: Free Vision (was File names, DPMI, and Turbo Vision for GPC)
by The African Chief 04 Apr '99

04 Apr '99

Marius Gedminas wrote: [...] > >The port of Free Vision to GPC is currently being worked on. > >Be welcome to join the project, so it will become usable sooner. > > I cannot promise much due to lack of free time, but it's already been > some time since I last inspected Free Vision. Is there a home page for > it now? Not that I know of - but you can get the latest versions from the FPC home page. I have ported the Objects unit to GPC (well, at least until the problem with "New'ing" pointer to files under the EGCS-based GPC compilers for Linux and Win32 are solved). I do not have the energy, time, or even the knowhow to port the other FV units (especially those with asm code in them) to GPC, so others will have to take on that task on (IIRC Peter is looking into doing this - am I right, Peter?). AFAICS the FV license terms are not GPL compatible and there may be other copyright issues that will make the ported FV Objects unit not distributable with GPC. If anyone is interested, I can make a copy of my current "development" version available (perhaps on my homepage). -- Best regards, Dr Abimbola A Olowofoyeku (The African Chief) Author of Chief's Installer Pro v5.0 for Win32 Email: laa12(a)keele.ac.uk Homepage: http://ourworld.compuserve.com/homepages/African_Chief

2 1

Re: File names (was: File names, DPMI, and Turbo Vision for GPC)
by Frank Heckenbach 04 Apr '99

04 Apr '99

Marius Gedminas wrote: > On Sat, Apr 03, 1999 at 12:29:12PM +0200, Peter Gerwinski wrote: > >Don't we need an additional variable `CasePreserving' then which > >is false on FAT but true on VFAT filesystems? > > What would it be used for? I don't think we need it. Actually, one can't rely on file names being stored unmodified at all. E.g., Dos (without LFN) will strip a trailing `.', except in `.' and `..', and anything beyond the 8+3 limitation, anyway. So, one must not rely on finding the file name as one stores it. All one can expect (I hope, at least) is that one can access the file by the same file name one used for storing (i.e., it will be modified the same way...) If one wants to canonicalize a file name, one can try `FExpand'... > >Even worse: This needn't be a constant for one OS but depends > >on the path you are accessing. A file on a FAT filesystem > >mounted under Linux has LFN=CaseSensitive=CasePreserving=false. > > I really think there is no need to go into that level of details. Other > Linux programs do not care for this, why should programs compiled with > GPC be an exception? I agree. I don't think a Linux user mounting a FAT FS with a file `foo' would expect it to show up when expanding `F*' (better mount it umsdos, anyway ;-). Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: bugs under DOS/DJGPP
by Frank Heckenbach 03 Apr '99

03 Apr '99

Maurice Lombardi wrote: > Hi all > I have found a couple of small bugs in the last beta > gpc-19990118.i386-pc-djgppv201.zip > when using LFN=n 8.3 limitation in DOS 6.2 > > The problem comes from the fact that in this situation DOS makes > uppercase all filenames. FindFirst/FindNext in the dos.pas unit has an > odd behavior displayed by the following short program: > > program ff; > uses dos; > var F:SearchRec; > begin > FindFirst('ff.pas',Anyfile,F); > writeln('l ',DosError); > FindFirst('FF.PAS',Anyfile,F); > writeln('u ',DosError); > end. > > DJGPP answers > l 0 > u 18 > i.e. it does NOT recognize the UPPERCASE filename, finding only the > lowercase one. > > In the same situation BP answers > l 0 > u 0 > i.e. it recognizes both. > > The defect can be traced to the function MatchPart in the FindNext > procedure. Correction need to be done only under DJGPP (at compilation > time) when LFN=n at execution time. A possible solution is given by the > attached diff. Thanks for the report. I fixed this -- actually a bit more general: I put into the RTS a new constant FileNamesCaseSensitive and a new function FLoCase to convert a character to lower case if FileNamesCaseSensitive is False and leave it unchanged otherwise, and use them in the Dos unit, so that unit doesn't need any ifdefs. However, I'm not sure about when FileNamesCaseSensitive should be set to False: First of all, I think it should be on all __OS_DOS__ platforms, not only __DJGPP__. Then, what about the LFN stuff? I haven't used such a system, but I've read that it's not really case-sensitive (something like, the case of the files as given on creation is stored, but matching is still insensitive). If that's so, FileNamesCaseSensitive should still be False, and we don't have to check LFN. Can anyone confirm or deny? > Similarly the environment names are always capitalized, so that > GetEnv('path') and GetEnv('PATH') give the same result as displyed in > the following short program: > > program ge; > uses dos; > var F:SearchRec; > begin > writeln('LFN=',GetEnv('LFN')); > writeln('ll ',FSearch('rhide.exe',GetEnv('path'))); > writeln('uu ',FSearch('RHIDE.EXE',GetEnv('PATH'))); > writeln('lu ',FSearch('rhide.exe',GetEnv('PATH'))); > end. BTW, something unrelated to your request: when searching for an executable, you might prefer to use: FSearchExecutable ('rhide', GetEnv (PathEnvVar)); This searches for `rhide.com', `rhide.exe' and `rhide.bat' under Dos (so you get more flexibility there), and on other systems for `rhide' without extension (so it works there, too) and only with executable permission (so it's safer than "FSearch ('rhide', ...)" there). PathEnvVar is currently 'PATH' on all systems, but one never knows what will happen... ;-) BTW, FSearchExecutable and PathEnvVar need the `gpc' unit rather than `dos' (and `FSearch' and `GetEnv' are also present in `gpc' as well as in `dos'). > DJGPP in DOS 6 with LFN=n answers: > > LFN=n > ll > uu F:\DJGPP\BIN\RHIDE.EXE > lu F:\DJGPP\BIN\rhide.exe > > whereas in BP gives always (even in a W95 dos box) > > LFN= > ll F:\DJGPP\BIN\rhide.exe > uu F:\DJGPP\BIN\RHIDE.EXE > lu F:\DJGPP\BIN\rhide.exe > > This behavior of automatic capitalization of environment variables is so > strange that I am not sure it must be reproduced in a unit which aims at > portability: I think that nearly everybody would write naturally > programs with environment variables uppercase as displayed by the set > command. Actually, I have changed this after 19990118 (only for Dos, of course, not affecting other systems where case matters). This is the corresponding entry from the `Fixed bugs' section of the To-Do list (http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html): 19990202: Dos-like systems: convert parameter to GetEnv and CGetEnv to upper case (actually, libc should do so) > A completely different bug is in the crt unit. Readkey returns #10 i.e. > linefeed when one hits the return as well as the ^M keys which should be > #13. > THis is very strange since the demo program testcurs.c which comes with > the sources of PDcurses has the correct behavior. Oh yes, these CR/LF stuff is a bit nasty because if seems to depend on a number of things like terminal modes, which are affected by CheckBreak (perhaps a bug in PDCurses, at least a bit of undocumented behaviour there ;-). I changed CRT a little after 1990118, hope this will also fix the symptom you've experienced: 19990202: DJGPP: CRT: ReadKey returns #10, not #13, for the enter key when CheckBreak is True Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

3 3

bugs under DOS/DJGPP
by Maurice Lombardi 03 Apr '99

03 Apr '99

Hi all I have found a couple of small bugs in the last beta gpc-19990118.i386-pc-djgppv201.zip when using LFN=n 8.3 limitation in DOS 6.2 The problem comes from the fact that in this situation DOS makes uppercase all filenames. FindFirst/FindNext in the dos.pas unit has an odd behavior displayed by the following short program: program ff; uses dos; var F:SearchRec; begin FindFirst('ff.pas',Anyfile,F); writeln('l ',DosError); FindFirst('FF.PAS',Anyfile,F); writeln('u ',DosError); end. DJGPP answers l 0 u 18 i.e. it does NOT recognize the UPPERCASE filename, finding only the lowercase one. In the same situation BP answers l 0 u 0 i.e. it recognizes both. The defect can be traced to the function MatchPart in the FindNext procedure. Correction need to be done only under DJGPP (at compilation time) when LFN=n at execution time. A possible solution is given by the attached diff. Similarly the environment names are always capitalized, so that GetEnv('path') and GetEnv('PATH') give the same result as displyed in the following short program: program ge; uses dos; var F:SearchRec; begin writeln('LFN=',GetEnv('LFN')); writeln('ll ',FSearch('rhide.exe',GetEnv('path'))); writeln('uu ',FSearch('RHIDE.EXE',GetEnv('PATH'))); writeln('lu ',FSearch('rhide.exe',GetEnv('PATH'))); end. DJGPP in DOS 6 with LFN=n answers: LFN=n ll uu F:\DJGPP\BIN\RHIDE.EXE lu F:\DJGPP\BIN\rhide.exe whereas in BP gives always (even in a W95 dos box) LFN= ll F:\DJGPP\BIN\rhide.exe uu F:\DJGPP\BIN\RHIDE.EXE lu F:\DJGPP\BIN\rhide.exe This behavior of automatic capitalization of environment variables is so strange that I am not sure it must be reproduced in a unit which aims at portability: I think that nearly everybody would write naturally programs with environment variables uppercase as displayed by the set command. But for the same reason the first issue on FindFirst/FindNext must be corrected, because filename are usually written in uppercase in DOS, so that the actual behavior of gpc is completely unnatural. A completely different bug is in the crt unit. Readkey returns #10 i.e. linefeed when one hits the return as well as the ^M keys which should be #13. THis is very strange since the demo program testcurs.c which comes with the sources of PDcurses has the correct behavior. Hope this helps Maurice Lombardi -- 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

bugs in DOS/DJGPP
by Maurice Lombardi 03 Apr '99

03 Apr '99

Hi all I have found a couple of small bugs in the last beta -- 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

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