November 2003 - Gpc

GUI Toolkits
by Adriaan van Os 27 Nov '03

27 Nov '03

Recently, I surfed the web looking for multi-platform GUI toolkits, available for GNU/Linux and being ported to Mac OS X/Darwin. I welcome comments from developers more experienced in these respective technologies. 1. the Gnome desktop environment with the Gtk+ toolkit. GPC bindings are available in the gpc contrib directory, but they are based on Gtk 1.2 rather than 2.x. I believe, I saw Gtk 2.x bindings for Free Pascal somewhere on the web, but I may be wrong. 2. the KDE desktop environment with the Qt toolkit, which is C++ based. So, in the Gnome versus KDE war, Gnome seems to be the natural choice. Also, you have to pay for Qt, unless you write GPL licensed software. 3. in the sources of KDevelop, I found references to GNU Pascal. However, KDevelop is not mentioned on the GNU Pascal website. 4. GLUT ... 5. Open Motif ... 6. LessTif ... 7. TkInter ... 8. Perl/Tk ... 9. Tcl/Tk ... 10. WxWindows ... 11. XForms ... 12. Mowitz ... Regards, Adriaan van Os

2 2

GUI Toolkits
by Dr Christian Hicks 27 Nov '03

27 Nov '03

From: Eike Lange Subject: GUI Toolkits Date: 26 Nov 2003, 20:04:16 Hi! On Wed, Nov 26, 2003 at 04:29:03PM +0000, Dr Christian Hicks wrote: > This is something I am very interested in too. I have > a large (legacy) Pascal program which has the interface > written in Xview via C. XView also seems to be in the > legacy category. I am wanting an interface that will > run on Linux, Cygwin and Solaris. - How about GTK or X-Lib? The GTK link on Cygwin is dead. However I have found a link http://xlang.sourceforge.net/gtk+-win32.html that has a download link. I'll have a look when I get a chance. >From memory XView is written using XLib. I think Xlib would involve lots of low level programming which I am hoping to avoid. Chris Dr Christian Hicks Senior Lecturer, School of Mechanical & Systems Engineering, Stephenson Building, University of Newcastle upon Tyne, NE1 7RU. Phone: +44 191 222 6238 Mobile 0795 8317804 Fax: + 44 191 222 8600 Homepage: http://www.staff.ncl.ac.uk/chris.hicks

1 0

GUI Toolkits
by Dr Christian Hicks 26 Nov '03

26 Nov '03

This is something I am very interested in too. I have a large (legacy) Pascal program which has the interface written in Xview via C. XView also seems to be in the legacy category. I am wanting an interface that will run on Linux, Cygwin and Solaris. I am currently looking at tk-tcl which I have used before. I have so far got to the stage of learning how to link from GNU Pascal to GNU C (and vis versa). Tk-tcl can also be linked to C and is quite portable. There are some free GUI builders that I am going to look at (e.g. TkBuilder). I have posted some examples on the web. See: http://www.staff.ncl.ac.uk/chris.hicks/programming.htm http://www.staff.ncl.ac.uk/chris.hicks/tktcl.htm I do not know whether I am pursuing the best option - rather I am going in a direction that I am relatively familiar with. I will post some examples when I have had time to do them. I also have tried looking at GNOME (but the Cygwin link is dead). I would welcome any advice as to which GUI builder / language is best to use. I want something that is free and portable accross Linux, Cygwin and Solaris. Many thanks, Chris Dr Christian Hicks Senior Lecturer, School of Mechanical & Systems Engineering, Stephenson Building, University of Newcastle upon Tyne, NE1 7RU. Phone: +44 191 222 6238 Mobile 0795 8317804 Fax: + 44 191 222 8600 Homepage: http://www.staff.ncl.ac.uk/chris.hicks

2 1

Re: memory offset problem?
by Frank Heckenbach 26 Nov '03

26 Nov '03

Toby Ewing wrote: > > Alternatively, you could perhaps do without a schema: > > > > var > > Buffy: array [0 .. wid - 1] of ByteCard; > > Can't do that: the program has to adjust to different sized images. Wid is > determined by a combination of input file and user input, so there's no way to > know it at compile time. As I tried to explain, it doesn't have to be known at compile time. Of course, it has to be known at runtime when the declaration is made. If you need it in a routine which determines the size during its execution, you could either put the declaration in the statement part (non-standard) or move it to a subroutine. > > GPC allows such non-constant sized declarations according to EP. > > > > > And why > > > isn't the program complaining? > > > > Because GPC doesn't (yet) implement runtime range-checking. One of > > the next versions will. > > I thought that I'd get a memory violation, or GPF, or something like that. This depends on what's there in memory. In this case, it's the discriminant, so you will clobber it (which might to subsequent problems later when you do some things with the schema). In other cases, there may be other variables which get clobbered. You can't expect to always get memory violations. Tools like efence will help somewhat (i.e., produce more segfaults on invalid accesses), but not 100% (see the doc). That's why we need compiler generated runtime range-checking at all. Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)

1 0

memory offset problem?
by Toby Ewing 26 Nov '03

26 Nov '03

Hi, all I've been writing a program that draws an image (based on file input), then outputs the image as a tiff file. During debugging, I just wrote out the image one pixel at a time: for h := 1 to ht do for w := 1 to wid do write(Iout, Image^[w,h]); It works fine, but of course it's slow. So once the rest of the program was working, I decided to speed it up. Now I allocate memory for one line of the image, dump the image one line at a time into it, and blockwrite that line: type PBufary = ^Bufary; Bufary(mX : shortCard) = array[0..mX] of byteCard; [...] var Buffy : PBufary; [...] New(Buffy,wid-1); Extend(Iout,OutFileName,wid); for h := 1 to ht do begin for w := 1 to wid do Buffy^[w-1] := Image^[w,h]; BlockWrite(Iout,Buffy^,1); end; Close(Iout); Dispose(Buffy); It's way faster, as I expected. (The Extend is because I write the fileheader to a file of shortCard, close it, then re-open it with Extend so I can use the BlockWrite.) BUT the image has a 2-pixel-wide black line down the left side. To get rid of it, I had to do: for h := 1 to ht do begin for w := 1 to wid do Buffy^[w-3] := Image^[w,h]; { <== *** -3!?!?} BlockWrite(Iout,Buffy^,1); end; This makes no sense, but it works. What's with this 2 byte offset? And why isn't the program complaining? thanks, Toby

2 1

Lots of examples including Pascal calls C and C calls Pascal
by Dr Christian Hicks 26 Nov '03

26 Nov '03

I have been learning to program in C over the last few weeks and have put some examples together. These include how to call Pascal from C and how to call C from Pascal. I am grateful to other people for their help, particularly The African Chief. Please see: http://www.staff.ncl.ac.uk/chris.hicks/programming.htm Please bear in mind that I am not an expert. I would welcome any constructive comments. Best regards, Chris Dr Christian Hicks Senior Lecturer, School of Mechanical & Systems Engineering, Stephenson Building, University of Newcastle upon Tyne, NE1 7RU. Phone: +44 191 222 6238 Mobile 0795 8317804 Fax: + 44 191 222 8600 Homepage: http://www.staff.ncl.ac.uk/chris.hicks

5 7

Re: gpc-20030830, Cygwin and "Stat"
by Prof A Olowofoyeku (The African Chief) 23 Nov '03

23 Nov '03

I wrote: > With your gpc binaries, based on gcc-3.3.1-3, it works correctly. With > your gpc sources, my sources, and the pristine sources, built, on a > freshly installed Cygwin, and based on gcc-3.2.3, it gives the result > shown above. This is the first time that this error has shown up. I have > traced down to the _p_Stat() function in rts.c, and I have ascertained > that the error happens here, with respect to FileExists: The call: > " if (Special) *Special = S_ISCHR (st.st_mode) || S_ISBLK (st.st_mode) > || S_ISFIFO (st.st_mode) || S_ISSOCK (st.st_mode);" > > returns 1. I don't know what "Special" means and why it is returning > true here. But I doubt that that attribute has any significant meaning > under Windows. > > The DirectoryExists call fails here: > " if (Dir) *Dir = S_ISDIR (st.st_mode);" > This returns 0 if you pass any directory other than "/". > > Is this a gcc-3.2.3 problem? I don't know - and I would doubt it. On the > other hand, it obviously doesn't exist with your gcc-3.3.1-3 based > binary. I have just built gpc-20030830 on gcc-3.3.1-3 sources, and this problem does not exist with the new gpc binaries. So it seems that the problem is related to gcc-3.2.3. This is all mysterious to me ... Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/

1 0

gpc-20030830, Cygwin and "Stat"
by Prof A Olowofoyeku (The African Chief) 23 Nov '03

23 Nov '03

Hi There is a problem with Cygwin and gpc-20030830, which is illustrated in this program: program fbug; uses gpc; begin Writeln (FileExists ('fbug.pas')); Writeln (DirectoryExists ('.')); end. In both cases, it prints "False", when indeed both the file and directory do exist. Checking filename.pas shows that both functions call "Stat", and I presume that this is where the problem lies - but I have no idea what do do about it. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/

2 2

Simple GNU P calls GNU C works on Redhat but not Cygwin!
by Dr Christian Hicks 22 Nov '03

22 Nov '03

I have gone back to basics and tried simple.p [ program test(input,output); begin writeln("hello world"); end. ] I am getting the same error messages: /usr/lib/gcc-lib/i686-pc-cygwin/3.2.3/libgpc.a(rts.o)(.text+0x18ef):rts.c: undefined reference to `_ftruncate64' /usr/lib/gcc-lib/i686-pc-cygwin/3.2.3/libgpc.a(rts.o)(.text+0x18b4):rts.c: undefined reference to `_lseek64' collect2: ld returned 1 exit status This is the same error message that I got from my Pascal calls C program. There is clearly something not right with my binary distribution. I will try and do a reinstallation and then run the test suite. gpc -v gives: Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.2.3/specs Configured with: ../configure --enable-languages=pascal --enable-threads=posix --with-system-zlib --enable-nls --without-included-gettext --enable-interpreter --disable-sjlj-exceptions --enable-shared --build=i686-pc-cygwin --host=i686-pc-cygwin --target=i686-pc-cygwin --enable-haifa --prefix=/usr Thread model: posix gpc version 20030830, based on gcc-3.2.3 Best regards, Chris Dr Christian Hicks Senior Lecturer, School of Mechanical & Systems Engineering, Stephenson Building, University of Newcastle upon Tyne, NE1 7RU. Phone: +44 191 222 6238 Mobile 0795 8317804 Fax: + 44 191 222 8600 Homepage: http://www.staff.ncl.ac.uk/chris.hicks

4 7

Another Pascal / C problem
by Dr Christian Hicks 22 Nov '03

22 Nov '03

I am now trying to pass a string as well as an integer between C and Pascal. I am getting a segmentation fault. I would be grateful if tell me what I have done wrong. I attach the files pcallc.p, ccall.c ccall.h and Makefile and show the output at the end. Many thanks, Chris pcallc.p: [ program pascalcallsC(input,output); procedure world; external name 'world'; procedure w1(var i : integer; var s : cstring); external name 'c_w1'; var i : integer; s : cstring; begin writeln("Hello world from Pascal"); world; writeln("Returned from C to Pascal\n"); i := 96; w1(i,s); writeln("Returned from C again I = ",i); writeln("Return from C cstring = ",s); {segmentation fault on this line} s := "This is a CString"; writeln("Trying out pascal ",s); end. ] ccall.c: [ #include <stdio.h> #include <string.h> #include "ccall.h" void world (void) { printf("\nHello World from C\n"); } void c_w1 (int *i, char *s) { printf("Now in function c_w1\n"); strcpy(s,"Mary had a little lamb\n"); printf("Hello again from C i = %i\n%sXXX\n",(*i),s); (*i) = 56; printf("Leaving C\n"); } ] ccall.h: [ extern void world(void); extern void w1(int *i, char *s); ] Makefile: [ pcallc : pcallc.p ccall.o gpc -o pcallc pcallc.p ccall.o --cstrings-as-strings ccall.o : ccall.c gcc -c ccall.c clean: rm *.o pcallc ccall.o ] output: [nmansys@mmme1 pcallsc2]$ pcallc Hello world from Pascal Hello World from C Returned from C to Pascal Now in function c_w1 Hello again from C i = 96 Mary had a little lamb XXX Leaving C Returned from C again I = 56 Segmentation fault Dr Christian Hicks Senior Lecturer, School of Mechanical & Systems Engineering, Stephenson Building, University of Newcastle upon Tyne, NE1 7RU. Phone: +44 191 222 6238 Mobile 0795 8317804 Fax: + 44 191 222 8600 Homepage: http://www.staff.ncl.ac.uk/chris.hicks

3 2