April 2005 - Gpc

dereferencing untyped pointer
by Prof A Olowofoyeku (The African Chief) 23 Apr '05

23 Apr '05

Hi How does one get rid of the "dereferencing untyped pointer" error without endless typecasting? Is there a switch or compiler directive? Thanks. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

8 18

Re: bug: ncurses + slackware 10.0, 10.1
by Frank Heckenbach 11 Apr '05

11 Apr '05

Thomas Dickey wrote: > On Sun, 10 Apr 2005, Frank Heckenbach wrote: > > > Russell Whitaker wrote: > > > >> Program below illustrates a bug: lower case a, lower case f thru z, > >> and number 0 are printed with graphic characters. This bug did not > >> appear in earlier versions of slackware. > > With the given example, I see a difference which I assume is what you're > talking about: if I run the sample in Linux console, linked against > ncurses 5.4 (or current), I'm seeing the cells 32-127 as line-drawing. > (Cells 0-31 are control characters, and are blank). > > Running against ncurses 5.3 or earlier, I don't see line-drawing. > > In each case, cells 128-255 are displaying the PC-specific font (some > double-width lines, etc). Indeed 128-255 are ok in all versions I tried. (I left 0-31 out of the test to avoid side-effects, and they don't seem relevant here.) > Since the difference is in how cells 32-127 are displayed, I assume that's > the issue. (Though the comments about direct access to the PC font are > a little confusing to me...). > > I agree with part of this. The part that I don't agree with is the > assumption that setting A_ALTCHARSET would in some cases not try to use > the terminal's alternate character set. (The sample code sets it in every > cell). Yes, it does, but in addition to setting smacs/rmacs ncurses does some internal remapping by means of real_map[] which it didn't do before AIUI. > > Anyway, the affected characters are all printable ASCII characters > > which are the same, at least in the IBM PC character mapping and > > probably most other fonts, so if necessary I could just turn off > > A_ALTCHARSET for those characters (#if 0 in the example below). > > yes - that sounds right. > > Bear in mind that you're actually using the smpch/rmpch feature, which > happens to work because smacs/smpch and rmacs/rmpch are the same strings. > I seem to recall that long ago ncurses had something like A_PCCHARSET > to distinguish these, but since it was not part of X/Open curses, that > was dropped. It was still available, I could probably use it, but now, A_ALTCHARSET is the only way to get at the font directly, isn't it? > > Is this the recommended thing to do, or is there another way to get > > direct access to all characters of the underlying font (on the Linux > > console)? > > As I understand the issue yes (though actually there's underlying font for > cells 32-127, which you don't seem to want). Maybe we have different definitions of underlying font, but in the end, we seem to mean the same. What I mean is the font as loaded which has the standard ASCII characters in 32-127 (and other characters such as line drawing in higher positions), and I want to output them just this way. Since ncurses remaps some of the ASCII characters, and since they're usually mapped 1:1 to the font anyway, I think I should just not set A_ALTCHARSET for those charaters as my patch did. If that's just it, I think we can consider the issue solved. 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

Strange error message in GPC20050331
by Markus Gerwinski 11 Apr '05

11 Apr '05

Hi folks, the line: if getMouseButtonPressStream^ .getLastEvent^ .getTarget = fLastEvent^ .getTarget then results in an error message: alpevents.pas:1255: error: invalid type of argument of `^' The error message disappears if I change the line into: if ( getMouseButtonPressStream^ .getLastEvent )^ .getTarget = fLastEvent^ .getTarget then What's that? Regards, Markus

2 4

"pos" and whole words
by Prof A Olowofoyeku (The African Chief) 10 Apr '05

10 Apr '05

Hi I have been trying to implement a "pos" function that only matches whole words. Below is my best effort. Is there a more efficient (or "better") way of implementing this? Thanks. { a "pos" function that matches whole words only } function PosInString (const sub, str : String) : Cardinal; Const nSeparators = ['a'..'z', 'A'..'Z', '0'..'9']; { non-separators } Var i, j : Cardinal; begin result := 0; If (sub = '') or (str = '') then Exit; i := pos (sub, str); { any match? } if (i = 0) then exit; { search for whole words only } result := i; j := length (sub) + i; if (i = 1) or ((i >1) and (Not (str [pred (i)] in nSeparators))) then begin if (j < length (str)) and (str [j] in nSeparators) then result := 0; end else result := 0; end; { test: correct results in comments } begin writeln (PosInString ('adam', 'he is adamant')); {0} writeln (PosInString ('adam', 'why is he so adamant about it?')); {0} writeln (PosInString ('adam', 'he knows about adam ant')); {16} writeln (PosInString ('adam', 'adam and eve')); {1} writeln (PosInString ('adam', 'eve and adam')); {9} writeln (PosInString ('adam', 'eve and adam ate the apple')); {9} end. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

7 13

framebuffer dev note
by Rick Engebretson 09 Apr '05

09 Apr '05

In playing with framebuffer drawing efforts, something interesting came up. In brief (so as not to bore everyone) the same draw program and unit works differently between fpc and gpc. But neither work. I suspect it is in the rewrite and/or blockwrite functions. I'm using 16bit pixels so I'm dealing with converting 16 bit to byte writes. Anyway, for a simple red horizontal line on a solid background. Fpc gives me two red lines on a clean blue background. While gpc gives me a single red line on a spotted blue background. Also, gpc gave me the proper error code for using blockwrite on a typed file. Conclusion; a bad program performs differently on fpc and gpc.

3 14

[Fwd: Re: Link/Load problem using gpc Trap unit]
by Maurice Lombardi 07 Apr '05

07 Apr '05

-------- Message d'origine -------- Sujet: Re: Link/Load problem using gpc Trap unit Date: Thu, 07 Apr 2005 18:17:09 +0100 De: Maurice Lombardi <Maurice.Lombardi(a)ujf-grenoble.fr> A: Angelo FUMAGALLI <Angelo.Fumagalli(a)alcatel.it> Références: <E1DIUER-00032L-00(a)hera.math.uni.wroc.pl><1112730270.11406.474775(a)goedel.fjf.gnu.de><003901c53b74$ef09f720$7c286297@Fumagalli> <1112886396.968.886374(a)goedel.fjf.gnu.de> <013601c53b8c$5a79a930$7c286297@Fumagalli> Angelo.Fumagalli(a)alcatel.it a écrit: > gpc pi.o ulib.a gpclib.a gcclib.a -o p.exe gpclib.a or libgpc.a ?? > > to solve the undefined reference have I also to link the trap.o and trapc.o > files??? yes, everything you need in that case, but when you link with gpc (instead of ld) it finds himself libgpc.a and libgcc.a (so a wrong name may succeed). Try to use the option -v to see what is done. Maurice -- 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 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr -- 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 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

1 0

Environment Variables
by Andy Ball 06 Apr '05

06 Apr '05

Hello, How do I read an environment variable from my gpc Pascal program? This should enable me to accept data input via a form on the Web. - Andy Ball

8 14

Who uses Pascal?
by John Ollason 06 Apr '05

06 Apr '05

Greetings, I follow the postings on the mailing list with interest but seldom feel that I have anything to contribute. I am becoming concerned that some fundamental questions that we ought to address are simply being ignored. The most important question is Is Pascal a dead language? This might look like flame bait, but it isn't. Evidently the development of GPC presents a variety of interesting technical problems in the construction of a portable compiler, but the solution of such problems, though interesting in itself, deteriorates into navel-gazing if there isn't a group of users, reasonably sophisticated programmers who use write programs in Pascal. While there is a cohort of people like me who learnt Pascal in the '70s and '80s, the language is no longer taught in the introductory courses in programming at Aberdeen University of which I am a member, and as far as I can discover it certainly is not taught at school. With the decreasing number of recruits to the population of Pascal programmers it seems to me that Pascal is dying out and there is little anybody can do to conserve it. Perhaps my perceptions are mistaken, perhaps there is still a thriving process of recruitment to the ALGOL tradition, but I fear that the recruitment is not happening in Britain and certainly not in America. I belong to a fortunate group of programmers, those whose first language was ALGOL 60, trapped for a while with FORTRAN 4---What a dog's dinner after ALGOL!--- forced on to PL/1---a dog's banquet after FORTRAN---starvation rations then with BASIC, then the revelation of Pascal, which I started to use in 1978 and have used ever since as my favoured language, currently using GPC under linux. My programming is entirely scientific, simulating dynamical systems of interacting animals. I have no interest in GUIs and all my programs work from the command line. With a colleague I used to teach an introductory programming course for students with an interest in ecological modelling, using Level 0 ISO Pascal. Now, I believe introductory courses are taught using Visual BASIC or Java, neither of which, it seems to me, have the elegance and security of Pascal. So the base of users in my immediate vicinity is shrinking year by year, and to my eyes the quality of programs written by graduate students and postdocs is much worse now than it was when Pascal was the first language learnt. After all when you have learnt how to program in Pascal, you can write Pascal in any language, even PERL. So the question is Where is Pascal taught and used? I don't think that it's in computing science departments: my contact with computer scientists suggests that they regard themselves as far too grand for code-bashing. I suspect that the language is primarily used by what we might call gentleman-programmers, people who need fairly elaborate programs for their work that don't fit easily into the Mathematica, Matlab, systems, but which, for all that, require fairly sophisticated number crunching. Typically such programs are used by the programmers who write them, and so there is little need for fancy user (noddy) friendly interfaces. So who uses Pascal now? Who teaches Pascal now? Anybody interested in discussing these matters? John O.

7 12

[Fwd: Re: GPC ALPHA 20050331 released]
by Maurice Lombardi 06 Apr '05

06 Apr '05

-------- Message d'origine -------- Sujet: Re: GPC ALPHA 20050331 released Date: Tue, 05 Apr 2005 11:16:46 +0100 De: Maurice Lombardi <Maurice.Lombardi(a)ujf-grenoble.fr> A: James A. Morrison <jim.morrison(a)gmail.com> Références: <1112304080.8194.673009(a)goedel.fjf.gnu.de> <676645fc050331161525d4e1e2(a)mail.gmail.com> <42516C85.5000803(a)ujf-grenoble.fr> <676645fc05040410363c400c7(a)mail.gmail.com> James A. Morrison a écrit: >>> A diff is available at >>>http://www.csclub.uwaterloo.ca/~ja2morri/pascal/200502-200503.diff.gz >> >>I have tried to use it because of current gpc server unavailability. >>I does not work as is because of missing files, >>notably predef.h which was renamed as predef.def. >> > > > A new diff is at > http://www.csclub.uwaterloo.ca/~ja2morri/pascal/200502-200503-1.diff.gz Thanks I used it to compile with gcc-3.2.3 / DJGPP Success, with the following results of the test suite Test Run By dosuser on 2005-04-04 21:39:45 Native configuration is djgpp (KNAUTIE) # of tests 4946 # of expected passes 4938 # of unexpected failures 6 # of unsupported tests 2 c:/djgpp/b/gnu/build.gcc/gcc/xgpc version 20050331, based on gcc-3.2.3 in detail: TEST fjf1021d.pas: c:/djgpp/b/gnu/gcc-3.23/gcc/p/test/fjf1021d.pas:7: expressions with side-effects are not allowed in schema types failed TEST fjf1021h.pas: c:/djgpp/b/gnu/gcc-3.23/gcc/p/test/fjf1021h.pas:6: expressions with side-effects are not allowed in schema types failed TEST fjf1021i.pas: c:/djgpp/b/gnu/gcc-3.23/gcc/p/test/fjf1021i.pas:8: expressions with side-effects are not allowed in schema types failed TEST fjf1021j.pas: c:/djgpp/b/gnu/gcc-3.23/gcc/p/test/fjf1021j.pas:6: expressions with side-effects are not allowed in schema types failed TEST fjf1021k.pas: c:/djgpp/b/gnu/gcc-3.23/gcc/p/test/fjf1021k.pas:7: expressions with side-effects are not allowed in schema types failed TEST fjf1044s.pas: c:/djgpp/b/gnu/gcc-3.23/gcc/p/test/fjf1044s.pas: In procedure `p': c:/djgpp/b/gnu/gcc-3.23/gcc/p/test/fjf1044s.pas:36: Internal compiler error in expand_call, at calls.c:3078 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu-pascal.de/todo.html> for instructions. failed TEST fjf165a.pas: SKIPPED: German locale not installed TEST longr2.pas: SKIPPED: no LongReal math routines available Rather good, only fjf1044s is new w/r to the previous alpha. Maurice -- 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 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

1 0

Re: Who uses Pascal? Part 2
by Andrew Gregory 06 Apr '05

06 Apr '05

> -----Original Message----- > From: Frank Heckenbach [mailto:ih8mj@fjf.gnu.de] > Sent: 05 April 2005 12:23 > To: gpc(a)gnu.de > Subject: Re: Who uses Pascal? Part 2 > > > Andrew Gregory wrote: > > > I think that Pascal is still one of the better compiled languages. > > For someone who wants to write GUI applications on Windows, Delphi > > is a good choice because of features such as the form designer. > > But things have moved on: Powerful dynamic scripting languages > > such as Python contain a lot of new thinking, and really do save > > time in many applications (e.g. data processing). There is a good > > case for writing core functions (e.g. maths) in a compiled > > standardised language such as Pascal or extended Pascal, which > > will be around for decades, then writing interfaces to scripting > > languages as required. Unfortunately, to interface Python and gpc, > > you have to go via C, so for new code it's tempting just to use C. > > But what does "go via C" actually mean? I remember a joint project I > did with a C++ programmer. We also "went via C" which means he wrote > `extern "C"' and I wrote `external name' etc. No actual C code was > involved (apart from the GMP library which is written in C (and > assembler) and was used by both Pascal and C++ parts of the > program). So "going via C" doesn't have to mean more than using a > simple (i.e., only types available in C, no schemata, templates or > objects etc.) and well-defined (no name-mangling) calling interface. > > 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 > At the highest level Python is a "typeless" language - all of the parameters supplied to a function are references to objects of type PyObject (as Python is written in C I assume that a PyObject is a C struct although I've not looked into this in detail). A PyObject may contain a float, string, complex etc., or a sequence of references to other objects. Dynamic typing (i.e. type checking at run time rather than compile time) is a feature if Python. Python library functions (prototypes in Python.h, binary library libpython24.a) such as PyComplex_AsCComplex for example must be called for type checking and for conversions to C types at run time. Correct me if I'm wrong, but as far as I know you cannot do that directly from Pascal without quite a lot of work to get Python.h and the many include files within into a Pascal-compatible form. Therefore you have to use C or C++. If you declare a file of C externs for your Pascal procedures and functions, you can generate Python wrapper interface code automatically using SWIG (www.swig.org) although this is not always worthwhile. I've interfaced several Pascal mathematical libraries to Python via C - it doesn't take that long and the results are excellent. Andrew. ------------------------------------------------------------------- This e-mail and any attachments may contain confidential and/or privileged material; it is for the intended addressee(s) only. If you are not a named addressee, you must not use, retain or disclose such information. NPL Management Ltd cannot guarantee that the e-mail or any attachments are free from viruses. NPL Management Ltd. Registered in England and Wales. No: 2937881 Registered Office: Serco House, 16 Bartley Wood Business Park, Hook, Hampshire RG27 9UY United Kingdom -------------------------------------------------------------------

3 2