Gpc

gpc@gnu.de

5400 discussions

Re: GPC and Threads
by Jose Pascual 07 Oct '04

07 Oct '04

Hi Markus, first of all thank for you answer. > Jose Pascual wrote: > > I'm working in port some of my little application to linux. > All of my > > application has been writting in pascal. My porting to > linux is going > > ok but some of them use threads. > > > > I have read in GPC lists there are people working in a > thread unit for > > GPC, aren't you? > > Yep. great! > > Could someone share this unit with me? I could help to debugging it. > > I'm almost done with the threads themselves and mutexes. If > that is sufficient for your purposes, I'll put it online as > soon as I've finished testing. It'll be afable! I'm in a hurry so I have made some very alpha version with importing funtion from libpthread so I'd like to test your beta version. I'll need threading an semaphore in my application. Do you know (more or less) you are going to put it online? > > thank you so much > > You're welcome, > > Markus thank again best regards Jose Pascual

15 117

Brief comments / additions to docs
by Grant Jacobs 06 Oct '04

06 Oct '04

Here are a few random things I've spotted from a recent round of programming in GPC. (BTW - I know macros aren't part of Pascal, but they are useful, especially if you are porting code to/from C). Excuse me if any of these overlap with things previously covered - I haven't been following the list as I'm too busy of late. Debugging: If your source code is in multiple source files as units (or modules? - I've only tested for units), there is no need to specify the source filename as the GDB man pages suggest (e.g. break is defined as 'break [file:]function'). Just give the function/procedure name. Don't forget to make the first letter of the procedure/function identifier in uppercase - gpc adopts this (odd!) convention to avoid name-space conflicts with C and system libraries. Might be worth adding this to the docs - ? In my hands Exit doesn't seem to so much terminate the program as the proc/fn or the unit. Haven't tested this - I just gave up using it - but it certainly isn't stopping the program. (!) It would be good to see a more sensible error message generated when the compiler detects a missing parameter in the interface vs. implementation definitions of a proc/fn, e.g. if you have: interface function string_eq( str1, str2 : string; ) : boolean ; implementation function string_eq( str1, str2 : string; caseSensitive : boolean ): boolean ; begin ... end ; You get undeclared identifier `caseSensitive' (first use in this routine) rather than some sort of interface/implementation definition mis-match error. Its *very* confusing if you're down in the body of the unit looking at the source code for the function itself as its certainly present there and there is nothing to clue you into looking at the interface definition. If you do a rewrite() or reset(), do nothing with the file, but forget to close the file(s) before ending the program, malloc complains about a "deallocation of a pointer not yet allocated". I presume the post-execution mop-up doesn't handle unused files well -- ? Reset() and rewrite() insist on the buffer size parameter rather than defaulting if an untyped file is used. OK, you can just set it to 1, but its not consistent with the definition of the procedures in the docs which indicate [to me!] that this is optional. Macro expansion of __FILE__ seems to be inconsistent. In cases it expands to a full path and in others to just the local filename. It seems to be that if the file is in the local directory compared to the main program being compiled, just the filename is returned; if the source file is in another directory, a full path is returned. While there is a CurrentRoutineName there is no CurrentUnitName. It'd be useful to have this for debugging writes, to indicate which source file to look for a routine in. [Fussy one] Macros can't do C99's #define many_arg_fn(...) some_fn( __VA_ARGS__ ) trick. The GNU C compiler does support this & its very useful for debugging writes (which, in turn, are useful for test-driven development). Just keeping you on your toes ;-) Grant -- ------------------------------------------------------------------- Grant Jacobs Ph.D. BioinfoTools ph. +64 3 478 0095 (office, after 10am) PO Box 6129, or +64 25 601 5917 (mobile) Dunedin, gjacobs(a)bioinfotools.com NEW ZEALAND. Bioinformatics tools: deriving knowledge from biological data Bioinformatics tools - software development - consulting - training 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.

2 1

Re: Overloads ?
by Waldek Hebisch 06 Oct '04

06 Oct '04

I have not seen Borland specs, but it seems that I independently arrived at similar rules. Let me consider few cases. Simplest is exact match overload -- types of arguments match exactly function arguments. I think we want to allow all such overloads. For example: type month_no = 1..12; servo_pos = 0..1000; for month_no modular increment may be more natural, for servo_pos intement should "stuck" at max value (both are differnt that normal increment). In general, we may want to have colletion of types and equip each one into given set of operations. I do not like discrimnating against subranges here... Next, we may distinguish between say strings and integers. In such case it is natural to allow subranges in place of integer arguments, and use just assignment compatibility. For objects, "standard" reasoning (assuming single inheritance) is: child is more special than parent, has all parent features, so child can appear when parent can apper. Hence, we would like to use most specific overloaded function, going up inheritance chain. We would like to avoid introducing many special cases, so for subranges it is also natural to take most specific one. Of course, with multiple arguments (and also for subranges), "more specific" is only partial order, so it may fail to uniquely determine outcome. Also multiple inheritance (even such as in Object Pascal) breaks linear order. I see the following solutions here: 1) forbid "unorderd" overloads (not so bad because one can force choice using casts, and such cases should be rare anyway) 2) impose some arbitrary order By the way, is 'var' parameter is used to produce a value, then exact match is requred which may in turn force many extra overloads. In such case 'copy in, copy out' parameters are more natural (or Ada 'in out'). -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

1 0

gpc/carbonlib (os x) question
by P. George 05 Oct '04

05 Oct '04

i'm using gpc (on the commandline, not in mw) in os x. i need to call a carbon library function. the following line doesn't work: {$L /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon} when i try to compile with: gpc testcarb.pas -o testcarb ... i get: testcarb.pas:6: error: file `/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon' must be compiled not sure what that means or what i can do about it. thanks. - philip

3 6

Where is the web-server?
by Miklos Cserzo 05 Oct '04

05 Oct '04

Hi Folks, the www.gnu-pascal.de site is down. Where can I find the downloads? When it will be fixed? Cheers, miklos

2 1

scanner, was 'Unused parameter warnings'
by Ernst-Ludwig Bohnen 04 Oct '04

04 Oct '04

Hallo, I followed the long discussion concerning 'Unused parameter warnings' and put my personal sulution for scanning files and strings to: http://www.desy.de/~bohnen/gpc/units1/scanner.pas Other units needed for compilation can be found on the same directory. Ernst-Ludwig

1 0

building GPC toolchain. Large Files Support.
by Igor Marnat 22 Sep '04

22 Sep '04

Hello dear list! I'm building GPC for arm-elf target. In the source directory in files p/rts/configure.in and rts.h options "_LARGEFILE64_SOURCE" and "_FILE_OFFSET_BITS 64" are hardcoded. Is it really necessary? Is it possible to build GPC without large file support as it doesn't make sense for embedded platforms? It doesn't depend of version of GPC sources. Best regards, Igor Marnat mailto:marny@rambler.ru

3 9

Alternative download sites for gpc?
by Francesco Bonomi 21 Sep '04

21 Sep '04

Dear friends, While www.gnu-pascal.de is down (and I hope the job to bring it up again is not too hard) does anyone know of abother download site that is not too outdated? I am searching for documetnation and binaries, but all I find is VERY old stuff. thanks Francesco Bonomi

4 6

Upper/lower case in identifiers
by Tom Schneider 20 Sep '04

20 Sep '04

program capbug(output); (* capbug: capitalization bug in gpc compiler Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Molecular Information Theory Group Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/ *) const (* begin module version *) version = 1.00; (* of capbug.p 2004 Sep 10 2004 Sep 10, 1.00: origin *) (* end module version *) (* begin module describe.capbug *) (* name capbug: capitalization bug in gpc compiler synopsis capbug(output: out) files output: messages to the user description Demonstrate capitals bug in GPC. The name of a local procedure is objected to by GPC if there is a global by the same name but different capitalization. In theory the compiler should keep track of what is local and what is global anyway, so it should be able to avoid this. It is a problem because if one imports procedures from another program, they are not being treated as pure 'black boxes'. Instead, local variable names are being compared to the global variable names. In otherwords, the scope rule of Pascal is being violated when these warnings are generated. This problem is not fixed by adding the flag: -Widentifier-case-local Warn about an identifier written with varying case within one program/module/unit. examples gpc 20040516, based on gcc-3.3.3 for this program itself gives: capbug.p:113: warning: capitalisation of `x' doesn't match capbug.p:111: warning: previous capitalisation `X' capbug.p:113: warning: capitalisation of `y' doesn't match capbug.p:111: warning: previous capitalisation `Y' capbug.p: In procedure `themain': capbug.p:138: warning: capitalisation of `X' doesn't match capbug.p:113: warning: previous capitalisation `x' capbug.p:139: warning: capitalisation of `Y' doesn't match capbug.p:113: warning: previous capitalisation `y' The result is: capbug 1.00 outside: x = 1 outside: y = 2 inside: x = 3 inside: y = 4 themain: X = 5 themain: Y = 6 which demonstrates that the scope rules are being followed when the progrm runs, because X and Y are set before the calls to routines outside and inside, but they are not affected by those calls. That is, the outside and inside routines have local variables. documentation see also {Manual on GPC that gives the -Widentifier-case-local flag:} http://www.gnu-pascal.de/gpc/GPC-Command-Line-Options.html {Discussion on the topic, "Upper/lower case in identifiers":} http://www.gnu-pascal.de/crystal/gpc/en/raw-mail7665.html author Thomas Dana Schneider bugs technical notes *) (* end module describe.capbug *) var X, Y: integer; (* global X and Y *) procedure outside(x, y: integer); (* an outside procedure *) begin x := 1; y := 2; writeln(output,'outside: x = ',x:1); writeln(output,'outside: y = ',y:1); end; (* begin module capbug.themain *) procedure themain; (* the main procedure of the program *) procedure inside(x, y: integer); (* an inside procedure *) begin x := 3; y := 4; writeln(output,'inside: x = ',x:1); writeln(output,'inside: y = ',y:1); end; begin writeln(output,'capbug ',version:4:2); X := 5; Y := 6; outside(X, Y); inside(X, Y); writeln(output,'themain: X = ',X:1); writeln(output,'themain: Y = ',Y:1); end; (* end module capbug.themain *) begin themain; end.

12 30

www.gnu-pascal.de not available
by Eike Lange 18 Sep '04

18 Sep '04

Hi Folks! Due to some misunderstandings is our GPC server not available. Please be patient. Eike -- http://www.gnushi.de

2 2

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