Gpc

gpc@gnu.de

5400 discussions

TR : RE : RE : compiling with gp (was
by Pascal Viandier 11 Nov '05

11 Nov '05

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

1 0

Varying Char Array problem
by vanam srihari kumar 11 Nov '05

11 Nov '05

Dear all I am porting the code developed using sun cc and pc compilers to gpc and gcc my pascal code looks like below ******************************************************* vstr_1024 = VARYING[1024] OF CHAR; (* while porting it to gpc converted above data type as "vstr_1024 = string[1024]"*) FUNCTION sysget_symbol( VAR ENV : vstr_1024) : INTEGER; asmname 'sysget_symbol'; SysStatus:INTEGER; EnvString:vstr_1024; SysStatus := sysget_symbol (EnvString); (*sysget_symbol is a C function*) ******************************************************* my C code looks like below ******************************************************* typedef struct { int length; char text[1024]; } NameString1024; int sysget_symbol( NameString1024 *env) { (*code *) } ******************************************************* But the problem is after passing the vstr_1024 parameter to 'C' function,It is not reading properly. My question is Do we have any data type equivalent to varying char array? Please suggest me the alternative. Regards Hari __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com

2 1

array initialization
by vanam srihari kumar 11 Nov '05

11 Nov '05

Dear All I am porting the code developed using pc and cc compilers on solaris 2.6 to solaris 2.8 with gcc and gpc compilers. I am using the makefile from the older version.In that makefile, linker(ld) is called explicitly. Right now I am facing the below problems 1) related to real array constant intialization. TYPE MaxCPlus_RArray = ARRAY[1..MaxCplus] OF REAL; Maxcomp_Array = ARRAY[1..Maxcomp] OF REAL; CONST wPAF : Maxcomp_Array = [ 0.040, 0.225, 0.100, 0.344, 0.008, 0.098, 0.152, 0.176, 0.193, 0.227, 0.251, 0.197, 0.296, 0.351, 0.394, 0.444, 0.490, 0, 0, 0, 0, 0, 0, 0, 0 ]; it is giving following error /home/kvsspl/esipas81/flo/joint_lib.inc:125: incompatible types in initialization /home/kvsspl/esipas81/flo/joint_lib.inc:125: initial value is of wrong type /home/kvsspl/esipas81/flo/joint_lib.inc:125: set constructor elements must be of ordinal type /home/kvsspl/esipas81/flo/joint_lib.inc:125: set constructor elements must be of ordinal type /home/kvsspl/esipas81/flo/joint_lib.inc:125: set constructor elements must be of ordinal type /home/kvsspl/esipas81/flo/joint_lib.inc:125: set constructor elements must be of ordinal type 2) Do we have the standard library function in gpc which accomplishes the below functionality of sun library function. open(file, pathname, history, error, buffer) open associates the permanent file file with a file variable for reading or writing. open does not actually open the file; 3) compiler error: label `9999' used before containing binding contour what could be the cause for above error Please help me out Regards Hari __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com

4 5

Macro with set
by Peter N Lewis 10 Nov '05

10 Nov '05

Given the Macro definition (which I suspect is more or less irrelevent) {$definec Assert(b) AssertCode((b), __FILE__, __LINE__)} The line: Assert( overwrite_folder in [FOF_Merge, FOF_Overwrite] ); Gives the error: macro `Assert' used with too many (2) args Adding a bracket to the assertion call: Assert( (overwrite_folder in [FOF_Merge, FOF_Overwrite]) ); Resolves the problem. I guess it could be argued that there are two parameters "overwrite_folder in [FOF_Merge" and "FOF_Overwrite]" but clearly the macro code is handling () bracketing, should it also handle [] bracketing perhaps? Thanks, Peter. -- <http://www.stairways.com/> <http://download.stairways.com/>

2 1

__PC0__PCEXIT error
by vanam srihari kumar 09 Nov '05

09 Nov '05

Dear All I am porting the code developed by using sun pc and cc compilers to gpc and gcc.the following error is generated while linking.Please see below the dump. ************************************************* linking /home/kvsspl/exe/solaris/esigraph ld: Software Generation Utilities - Solaris Link Editors: 5.8-1.285 Undefined first referenced symbol in file __PC0__PCEXIT esigraph.o __PC0__PCSTART esigraph.o ld: fatal: Symbol referencing errors. ************************************************* If C main program calls a Pascal procedure that does I/O, then the following code should be included in the C main program before calling the Pascal procedure: #if defined(SOLARIS) __PC0__PCSTART(argc, argv); #endif #if defined(SOLARIS) __PC0__PCEXIT(argc, argv); #endif Please suggest me as how to get rid of this error Regards Hari __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com

3 2

Errors with integer and ordinals
by Alfonso Ruipérez 09 Nov '05

09 Nov '05

{$ extended-pascal} {gpc version 20050331, based on gcc-3.2.3 (mingw special 20030504-1)} program SuccPred (input, output); {ISO 6.7.6.3 (pg. 78 succ(x, k) x shall be of an ordinal-type k shall be of integer-type ... It shall be an error if such a value does not exist. succ(x) Shall be equivalent to succ(x, 1) pred(x) Shall be equivalent to succ(x, -1) } var b: boolean value false; begin writeln('succ(b, 2) = ', Succ(b, 2) ); {must be error!} writeln('Pred(b) = ', Pred(b)); {must be error!} {The next sentence is an error ISO 6.4.2.2 a.1 pg 24 All integral values in the closed interval from -maxint to +maxint shall be values of the integer-type.} {So... pred(-maxint) is not of the integer-type. There must be another out of range error!} writeln('pred(-maxint) = ', pred(-maxint)); {With the next sentence the compiler say 'arithmetical overflow' perhaps should say 'out of range'} writeln('succ( maxchar ) = ', succ( maxchar ) ); end.

2 1

Re: [off-list] Re: __PC0__PCEXIT error
by vanam srihari kumar 09 Nov '05

09 Nov '05

Yes, I did --- Grant Jacobs <gjacobs(a)bioinfotools.com> wrote: > > Just ask the silly question: > > You have defined SOLARIS, haven't you ?! ;-) > > #define SOLARIS, etc... > > > > Grant > > >Dear All > > > >I am porting the code developed by using sun pc and > cc > >compilers to gpc and gcc.the following error is > >generated while linking.Please see below the dump. > >************************************************* > >linking /home/kvsspl/exe/solaris/esigraph > >ld: Software Generation Utilities - Solaris Link > >Editors: 5.8-1.285 > >Undefined first referenced > > symbol in file > >__PC0__PCEXIT esigraph.o > >__PC0__PCSTART esigraph.o > >ld: fatal: Symbol referencing errors. > >************************************************* > >If C main program calls a Pascal procedure that > does > >I/O, then the following code should be included in > the > >C main program before calling the Pascal procedure: > > > >#if defined(SOLARIS) > > __PC0__PCSTART(argc, argv); > >#endif > >#if defined(SOLARIS) > > __PC0__PCEXIT(argc, argv); > >#endif > > > >Please suggest me as how to get rid of this error > > > >Regards > >Hari > > > > > > > > > > > > > >__________________________________ > >Yahoo! FareChase: Search multiple travel sites in > one click. > >http://farechase.yahoo.com > > > -- > ------------------------------------------------------------------- > Grant Jacobs Ph.D. > BioinfoTools > ph. +64 3 478 0095 (office, after 10am) > PO Box 6129, > or +64 27 601 5917 (mobile) > Dunedin, > gjacobs(a)bioinfotools.com > NEW ZEALAND. > Bioinformatics tools: deriving knowledge from > biological data > Bioinformatics tools - software development - > consulting - training > 15 years experience in bioinformatics ready to > solve your problem > Check out the website for more details: > http://www.bioinfotools.com > > The information contained in this mail message is > confidential and > may be legally privileged. Readers of this message > who are not the > intended recipient are hereby notified that any use, > dissemination, > distribution or reproduction of this message is > prohibited. If you > have received this message in error please notify > the sender immed- > iately and destroy the original message. This > applies also to any > attached documents. > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com

2 1

gp under Linux
by Pascal Viandier 08 Nov '05

08 Nov '05

Hello, I build gp on a Debian Linux X86 machine. All went well until I ran the make check. Is there a way to have it working on this platform? Thanks Pascal pascal(a)accovia.com dibm0014:/home/pascal/Pascal/packages/gp-0.60# gpc --version gpc 20050331, based on gcc-3.4.5 20050821 (prerelease) (Debian 3.4.4-8) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Output of make check: dibm0014:/home/pascal/Pascal/packages/gp-0.60# make check ./gp --test-parser --unit-path=/home/pascal/Pascal/packages/gp-0.60 /home/pascal/Pascal/packages/gp-0.60/test-parser.pas > test-parser.tmp ./gp: warning: /home/pascal/Pascal/packages/gp-0.60/test-parser.pas: missing program header sed -e '/^[PVm]/d;s,\/,/,g;s,'`pwd`',@srcdir@,g;s,/home/pascal/Pascal/packages/gp-0 \\.60,@srcdir@,g' < test-parser.tmp > test-parser.new rm -f test-parser.tmp if diff /home/pascal/Pascal/packages/gp-0.60/test-parser.out test-parser.new; then \ echo "GP Parser test succeeded" >&2; \ rm -f test-parser.new; \ else \ echo "GP Parser test failed" >&2; \ fi 2,3c2,4 < K 1 < O --- > T 1 > t i486-linux-gnu > p 5c6 < o @srcdir@/test-parser.o --- > O @srcdir@/test-parser.o 14,16c15,17 < O @srcdir@/gp.o < O @srcdir@/gpc.o < O @srcdir@/md5.o --- > o @srcdir@/gp.o > o @srcdir@/gpc.o > o @srcdir@/md5.o GP Parser test failed

2 1

Re: array intialization
by vanam srihari kumar 08 Nov '05

08 Nov '05

> 3) compiler error: label `9999' used before containing > binding contour > > what could be the cause for above error Could this be a bug that has been solved by now <http://www.gnu-pascal.de/gpc/Fixed-Bugs.html>, item 20050307: problem with string operations and goto (contour0.pas, contourbug.pas, martin1.pas, berend3.pas). ******************************************************* Could you please explain me in detail as how to get rid of this bug Regards Hari __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com

2 1

read anf writeln problem
by vanam srihari kumar 08 Nov '05

08 Nov '05

Dear All I am getting the below errors while using read and readln functions. *************************************************** READ(i_f, PrcObj^.state); ReadLN(i_f,CurPar^.bvalue); error1: argument to `Read'/`ReadLn' from `Text' file is of wrong type error2: argument to `Read'/`ReadLn' from `Text' file is of wrong type *************************************************** i_f : TEXT; 'CurPar' is a record and the bvalue is a boolean variable 'PrcObj' is a record and 'state' is of 'state_list' type state_list = (downed, install, stopped, waiting, started, running); Regards Hari __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com

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