Gpc

gpc@gnu.de

5400 discussions

byte data type in TP and GPC
by xstang＠post.cz 12 Dec '05

12 Dec '05

Hi, I have an old TP binary record, that consist of integer, real and byte data types. After reading the byte variable from the record I get wrong numbers. Does anyone know if there's any difference between the byte type in GPC and TP? Thanx

3 2

Re: Dev+GNU Pascal
by xstang＠post.cz 09 Dec '05

09 Dec '05

The original TP file record consists of 3 types: integer, real and byte, I replaced the original integer with smallint, but it still doesn't work and the result I get is even worse. Sorry for bothering again, thanx ----- PŮVODNÍ ZPRÁVA ----- Od: "Prof A Olowofoyeku (The African Chief)" <chiefsoft(a)bigfoot.com> Komu: xstang(a)post.cz Předmět: Re: Dev+GNU Pascal Datum: 8.12.2005 - 15:54:56 > On 8 Dec 2005 at 14:43, xstang(a)post.cz wrote: > > > I have one more question: do you have any experiences > > with reading > > old TP binary files? I try to read one and rewrite it > > to text > > file, but it's not done correctly. Thanx > > Same way as you read and write them with TP - except > that the sizes of > data types are often different in GPC, and therefore > you might need to > specify more particularly the size of the data types > that you use e.g., > "word" and "integer" are 16-bit in TP but 32-bit in > GPC, and strings > are implemented as schema in GPC - so any record > containing strings is > going to have a different size. See > \dev_gpc\units\winapi\wintypes.pas > to see how to declare integers and words with specific > sizes in GPC. > > PS: general questions like this should go to the GPC > list. The question > about the IDE is about a specific tool that I am > maintaining for a > specific platform (Windows) and that is of no general > interest to many > of the people on the GPC list. > > Best regards, The Chief > -------- > Prof. Abimbola A. Olowofoyeku (The African Chief) > web: http://www.greatchief.plus.com/ > > -- !VÁNOCE! --- SURVIVAL L-Carnitin+HCA+Chrom - 250ml ZDARMA --- Štíhlá linie pod stromeček. http://www.sportwave.cz

2 3

Problem with compiling gpc20041812 on solaris 10 intel platform
by prasad svr 09 Dec '05

09 Dec '05

Hi , I am tring to compile GPC-20041218 on solaris 10 Intel Platform using gcc-3.3.3.While compiling Iam getting an error like bellow. /usr/local/bin/gcc-3.3.3 -o p/declarations.o -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -DHAVE_CONFIG_H -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -I. -Ip -I/home/prasad/gcc-install/gcc-3.3.3/gcc -I/home/prasad/gcc-install/gcc-3.3.3/gcc/p -I/home/prasad/gcc-install/gcc-3.3.3/gcc/config -I/home/prasad/gcc-install/gcc-3.3.3/gcc/../include -DGPC -I/home/prasad/gcc-install/gcc-3.3.3/gcc/p /home/prasad/gcc-install/gcc-3.3.3/gcc/p/declarations.c /home/prasad/gcc-install/gcc-3.3.3/gcc/p/declarations.c: In function `init_decl_processing': /home/prasad/gcc-install/gcc-3.3.3/gcc/p/declarations.c:1469: error: `set_word_size' undeclared (first use in this function) /home/prasad/gcc-install/gcc-3.3.3/gcc/p/declarations.c:1469: error: (Each undeclared identifier is reported only once /home/prasad/gcc-install/gcc-3.3.3/gcc/p/declarations.c:1469: error: for each function it appears in.) /home/prasad/gcc-install/gcc-3.3.3/gcc/p/declarations.c:1470: error: `set_words_big_endian' undeclared (first use in this function) make[1]: *** [p/declarations.o] Error 1 make[1]: Leaving directory `/home/prasad/gcc-install/gpc-build/gcc' make: *** [all-gcc] Error 2 Please help on this problem. Regards Prasad -- _______________________________________________ Search for businesses by name, location, or phone number. -Lycos Yellow Pages http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.as…

2 1

(no subject)
by xstang＠post.cz 08 Dec '05

08 Dec '05

I have installed Dev+GNU pascal on computer with win xp professional. Whenever I try to compile any source code I get an error message: c:\dev_gpc\lib\gcc-lib\mingw32\3.2.3\collect2.exe: and: No such file: No such file or directory I've checked and the file exist in this location. Other error (in a different source code) is: c:\dev_gpc\examples\projects\grclock.pas:9: module/unit interface `Dos' could not be imported Can anyone help me, thanx -- Nesnesitelně lehká matematika: http://www.e-matematika.cz

2 5

GCC 3.4.5 has been released
by Adriaan van Os 08 Dec '05

08 Dec '05

Forwarding the message announcing the release of gcc-3.4.5 > From: Gabriel Dos Reis <gdr(a)integrable-solutions.net> > Date: 7 december 2005 21:25:09 GMT+01:00 > To: gcc-announce(a)gcc.gnu.org > Cc: gcc(a)gcc.gnu.org > Subject: GCC 3.4.5 has been released > > > I'm pleased to announce that GCC 3.4.5 has been released. > > This version is a minor release, from the 3.4.x series, fixing > regressions with respect to previous versions of GCC. It can be > downloaded from the FTP servers listed here > > http://www.gnu.org/order/ftp.html > > A list of known fixed bugs is available from here > > > http://gcc.gnu.org/gcc-3.4/changes.html > > > Many thanks to GCC contributors who made this release possible. > > -- > Gabriel Dos Reis > gdr(a)integrable-solutions.net

1 0

Best practice to link with C code
by Pascal Viandier 07 Dec '05

07 Dec '05

I have a question regarding the way to link a Pascal module to C code. For example, if in the following module: Module ctest interface; Export ctests = all; Procedure MyCProc(I:Integer); external name 'mycproc'; End. { Interface } Module ctest Implementation; End; { Implementation } If mycproc() is implemented in cproc.c, is it better to put {$L cproc.c} in the Interface or in the Implementation Section? Both work, but is a way better than the other? Regards, Pascal Viandier pascal(a)accovia.com

2 2

Reals
by Prof. Harley Flanders 03 Dec '05

03 Dec '05

Is there a unit out there for high precision real arithmetic (analysis), more than type Extended (10 bytes)? HF -- ============================= Prof. Harley Flanders 3533 Windemere Court Ann Arbor, MI 48105-2867 Home: 734 668 1546 harley(a)umich.edu =============================

2 1

Crt, read and Ctrl-C
by Waldek Hebisch 03 Dec '05

03 Dec '05

The following program tries to catch Ctrl-C using crt unit: program ctrl1; uses crt; var c : char; begin crtinit; CheckBreak := false; read(c); writeln('ord(c) = ', ord(c)) end . However, when I run it and press Ctrl-C I get: ./a.out: attempt to read past end of Input (error #454 at 40b255) A bug or a feature? -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

1 0

gp vs --automake
by Pascal Viandier 01 Dec '05

01 Dec '05

Hi all, I try to use gp to build my programs and have trouble with Pascal sources using c parts. When invoked by gp, gpc stops where I put {$L source.c} saying "error: file 'source.c' must be compiled. I remarked that gpc is called with --no-automake in its options list, even if I put --automake on gp command-line. This prevents the compilation of the c sources prior the Pascal module. My question is: Is the --no-automake passed to gpc causing the problem or is it because gp should compile the c sources before the Pascal module? I applied all the recent patches to gp but with no success on this particular problem. Also, I solved the problem of link with external libraries with gp by processing the dependencies list before the command-line options in routine StartPipe(). This works well. If you are interested by the modification I can send it. Although I don't know which tool you use to make your diffs, I an ready to learn it. Let me know. Regards Pascal Viandier pascal(a)accovia.com

3 6

Compiling with gp
by Pascal Viandier 29 Nov '05

29 Nov '05

Hello, The gp fix solved the false cyclic dependencies problem. The compilation runs smooth now. Thanks! However, I probably missed something because gp does not succeed to make the programs completely for two main reasons. First: There are some objects from c sources not found at link time. I put {$L my_c_extern.c} in a Pascal source but gp says "my_c_extern.c must be compiled" and stops instead of compiling it (I think since is knows that the source must be compiled, it should do it, no?). Then I tried {$L my_c_extern.o} instead and gp says " My_c_extern.c:999: undefined reference to 'symbol' where 'symbol' is defined in a third party library for which I put a -l directive on gp command-line. Second: The link command. I put gp in verbose mode and made a copy of the link command which fails to find out what is going wrong. I see that the list of my external (third party) libraries comes before any object in the link command. (-llib1 -llib2...) By putting this list of libraries at the end of the link command, it worked. But since I have no control on this at the gp command-line level I cannot make it work. Also, I noticed that objects are written in the same directory as gpi files despite the option --object-destination-path=obj on the gp command-line. Am I trying to make gp do things it was never designed for? Hope this is clearly explained. I use gp with Debian Linux on x86 if this detail matters. Thanks Pascal Viandier pascal(a)accovia.com -----Message d'origine----- De : gpc-owner(a)gnu.de [mailto:gpc-owner@gnu.de] De la part de Pascal Viandier Envoyé : November 11, 2005 15:36 À : gpc(a)gnu.de Objet : TR : RE : RE : compiling with gp (was Sorry I made a typo in the description of the dependencires: The third line of the schema should be: . Module C implementation section imports Module A and Module B (not Module C) Pascal Viandier pascal(a)accovia.com -----Message d'origine----- De : gpc-owner(a)gnu.de [mailto:gpc-owner@gnu.de] De la part de Pascal Viandier Envoyé : November 11, 2005 15:21 À : gpc(a)gnu.de Objet : RE : RE : compiling with gp (was Hi, The schema of the cyclic dependencies I face is: . Module A implementation section imports Module B . Module B implementation section imports Module A and Module C . Module C implementation section imports Module A and Module C Please note the dependencies are in the implementation sections, not in the interfaces. Although for each module the interface section is in a separate file included in the appropriate implementation file (i.e. A.pas includes A.h but no other file), I think this is not the cause of the problem. With this, gp says: cyclic interface dependency A.pas -> B.pas -> C.pas and it stops. Hope this schema will help clarify the situation. Regards Pascal pascal(a)accovia.com > -----Message d'origine----- > De : gpc-owner(a)gnu.de [mailto:gpc-owner@gnu.de] De la part de Frank > Heckenbach > Envoyé : November 11, 2005 09:03 > À : gpc(a)gnu.de > Objet : Re: RE : compiling with gp (was > > Pascal Viandier wrote: > > > Just my two cents: > > Like Mr Van Os, I have myself the problem of cyclic dependencies in many > > programs I ported from SUN Pascal to GNU Pascal. There are hundreds of > > separate modules with cyclic dependencies up to 8th level. > > To avoid misunderstandings: GP generally should be able to handle > cyclic dependencies. I've used it compile a project with ~200 units, > all interdependent (not written by me, obviously :-). > > So we don't need to discuss whether to do that. > > > For now, I use make to build the programs because of these dependencies. > I > > have to call it two times to build the interfaces, because there are > also > > cyclic dependencies in some interface sections that import others. > > Cyclic dependencies within interfaces are forbidden, both in Borland > and Extended Pascal. (I.e., interface A uses interface B, and > interface B uses interface A.) GP will also reject this, and there's > really no sane way to do this, as you could easily construct > circular definitions and contradictions this way. > > What you can do is: Interface A uses interface B, and implementation > B uses interface A. Then GP should, in this order, compile interface > B, all of A, implementation B. > > If that's what you need, then GP should work for you. There may be > abug, perhaps the same one Adriaan found, and then, of course, I'd > like to fix it, when I know what it is ... > > > Although I am not sure if I can completely build the programs with it > since > > they link with many third party libraries and I have not found the way > to do > > it in the gp documentation yet. > > Libraries are easy. There are two ways, both work the same with GP > as with automake, and the second one also with manual make: > > - Put {$L} directives in the source (see e.g., the GMP and RegEx > units that come with GPC). > > - Add -l options on the command line. > > > > >> I am now implementing for gp: > > > >> > > > >> --compile-file Compile a file as fast as possible. > > > >> Imported > > > >> units that need recompilation are > > > >> compiled > > > >> --interface-only, which implies > that > > > >> successive linking will fail. > > > >> Therefore, > > > >> this option is useful during the > > > >> development phase only. > > > >> This option implies -c > > > >> --check-file Check the syntax of a file as fast > as > > > >> possible. Imported units that need > > > >> recompilation are compiled > > > >> --interface-only. > > > >> This option implies -c > > > >> > > > >> It mostly works already (I will post a diff later). The time gain > is > > > >> dramatic. > > > > > > > > IIUC, this is only necessary because of the bug you suppose in your > > > > previous mail (otherwise no other units would have to be recompiled > > > > if not changed)? So it might be a better use of time to concentrate > > > > on the acutal bug than on temporary work-arounds. > > > > > > No, I consider this a valuable feature, although the impact may in > > > general not be so dramatic as in my current project, porting an > > > application to GPC with many cyclic dependencies (which I didn't write > > > myself). > > Perhaps I don't yet quite understand it. Provided GP makes no > mistakes and imports are not recompiled unless necessary. So I > suppose you mean the situation that you changed the implementation > of an imported unit? But you don't want to compile (and therefore > check for syntax errors) this other unit? > > > > I will try to be useful and fix gp myself. Compile times are also > > > spoiled by the quadratic operator search > > > (<http://www.gnu-pascal.de/crystal/gpc/en/mail10055.html>) and that is > > > something I cannot fix easily myself (at some points in the > compilation > > > I see the IDE's progress bar and line counter move line by line, often > > > lines with calculations). > > I see. BTW, Waldek are you interested in the general solution of > this issue (including overloaded routines)? I'm not too much ATM > (there are many more urgent issues). If you aren't either, perhaps I > could at least try some quick fix to ease this problem somewhat. -- > Still using name-based search, with all its disadvantages, but > perhaps storing a list of actually defined operators in the > OPERATOR_DECL (this will also be a preparation for the real > solution), and then for each operator retrieve the type names and > compare them -- I suppose if we get rid of the ACONCAT and > get_identifier in the loop this way, this might make things much > faster. > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://www.gnu-pascal.de/todo.html > GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 > E5E8

3 4

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