Gpc

gpc@gnu.de

5400 discussions

Re: ODP: Interfacing DJGPP C with Pascal
by Peter Gerwinski 02 Dec '97

02 Dec '97

According to Stanislaw Kozlowski: > > Yes, this is all that I needed. Maybe this informationit should be included > in INFO help ? Yes, that would be good. In fact I am already working on such things, but it costs time ... :-( > In fact inspecting binary code of LIBPC.A I figured out > that _p_initialize should be called but I did no know the parameters. Why didn't you inspect the *source* code of `libgpc.a'? It is available from the same place where you got the binaries. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

1 0

subscribe
by Marco Klein 02 Dec '97

02 Dec '97

1 0

Re: File/Record locking on Linux with GPC
by Peter Gerwinski 01 Dec '97

01 Dec '97

According to Pismo: > I need to lock records or at least files on database > written with GPC on Linux system ... how? What do you mean by "locking records"? How would you do this manually or with another programming language? Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

2 1

Re: Sockets
by Peter Gerwinski 01 Dec '97

01 Dec '97

Hello, Matthew! Hi, everybody! According to RHS Linux User: > I was trying to open a socket, but the problem I kept running into was > that connect wants a sockaddr struct, and in C you just casted it... > (struct sockaddr *)&address but, I don't think that that is possible in > pascal, [...] Since you cannot simply #include a C header file in a Pascal program you have to define the type by yourself: Const AF_UNSPEC = 0; AF_UNIX = 1; (* Unix domain sockets *) AF_INET = 2; (* Internet IP Protocol *) AF_AX25 = 3; (* Amateur Radio AX.25 *) AF_IPX = 4; (* Novell IPX *) AF_APPLETALK = 5; (* Appletalk DDP *) AF_NETROM = 6; (* Amateur radio NetROM *) AF_BRIDGE = 7; (* Multiprotocol bridge *) AF_AAL5 = 8; (* Reserved for Werner's ATM *) AF_X25 = 9; (* Reserved for X.25 project *) (*$ifdef LINUX_2_1_X *) AF_INET6 = 10; (* IP version 6 *) (*$endif *) AF_MAX = 12; (* For now.. *) Type SockAddrPtr = ^SockAddr; SockAddr = record case family: ShortCard of AF_UNSPEC: ( data: packed array [ 0..13 ] of Char ); AF_INET: ( port: ShortWord; address: array [ 1..4 ] of Byte ); end (* SockAddr *); Having this you can declare a variable `Address' of type `SockAddr', so `@Address' will have the correct type - no need to cast. However, `SockAddrPtr ( @Address )' is the exact analogon of your C fragment above. Hope this helps, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

1 0

Re: Sockets
by Kevin A. Foss 01 Dec '97

01 Dec '97

On Thu, 27 Nov 1997 11:15:44 -0800 (PST), RHS Linux User wrote: Hello, >I was trying to open a socket, but the problem I kept running into was >that connect wants a sockaddr struct, and in C you just casted it... >(struct sockaddr *)&address but, I don't think that that is possible in >pascal, so if anyone has successfully done this or knows how. please email >me, Well, I've done some work interfacing GPC with sockets, and the problem you describe is the first one I hit. The only solution I've found so far for problems like these is to wrap them inside callable C routines. E.g. I have something like: int bind_socket(int orig_sock, short family, u_short port) { struct sockaddr_in serv_adr; memset( &serv_adr, 0, sizeof(serv_adr) ); serv_adr.sin_family = family; serv_adr.sin_addr.s_addr = htonl(INADDR_ANY); serv_adr.sin_port = htons(port); if (bind( orig_sock, (struct sockaddr *) & serv_adr, sizeof(serv_adr)) < 0) { close(orig_sock); return (-1); } return (0); } in socket.c (with all of the necessary includes) Then in my Pascal source I use: function bind_socket(socket : integer; family : ShortInt; port : ShortCard) : integer; C; and I can bind a socket with a call like: result := bind_socket(socket, AF_INET, port); The at compile time I just include my C file with the source: gcc sockettest.pas socket.c -lsocket or whatever... As I explore more of the features in GPC hopefully I'll be able to make more calls directly from Pascal, but for calls like bind(), accept() and connect() I've found it easier to write a wrapper in C. Obviously it would take a while to write good wrappers that would return full error conditions to GPC not to mention allowing users to get at all of the socket options you have in C, but I've been just kludging solutions that happen to fit my needs. Right now all I have working is a quick-and-dirty connection where a client can send strings to a server process on another machine and have it echoed back slightly modified. -Kevin -- Kevin A. Foss --- kfoss(a)mint.net --

1 0

Re: agnes down ?
by Jan-Jaap van der Heijden 30 Nov '97

30 Nov '97

I'm sorry that I ever questioned the stability of agnes. We seem to be dealing with a severe case of Micro$ofteritis here: [janjaap@ZOO-station janjaap]$ traceroute agnes.dida.physik.uni-essen.de traceroute to agnes.dida.physik.uni-essen.de (132.252.78.226), 30 hops max, 40 byte packets 1 router (130.89.220.1) 2.711 ms 3.995 ms 2.914 ms 2 Enschede2.router.surfnet.nl (145.41.162.97) 3.528 ms 2.835 ms 2.879 ms 3 BR1.Enschede.surf.net (145.41.8.109) 2.121 ms 6.237 ms 4.252 ms 4 BR2.Amsterdam.surf.net (145.41.7.30) 5.64 ms 14.08 ms 8.182 ms 5 BR1.Amsterdam.surf.net (145.41.8.101) 7.403 ms 12.607 ms 24.147 ms 6 Amsterdam1.belsurf.net (192.12.54.9) 7.402 ms 6.613 ms 9.705 ms 7 Amsterdam6.att-unisource.net (192.12.54.2) 8.483 ms 8.549 ms 7.352 ms 8 amsterdam5.att-unisource.net (195.206.64.17) 318.871 ms 361.2 ms 18.563 ms 9 frankfurt5.att-unisource.net (195.206.64.22) 17.684 ms 21.509 ms 23.506 ms 10 frankfurt6.att-unisource.net (195.206.64.42) 22.506 ms 43.934 ms 46.413 ms 11 DE.ten-34.net (195.206.64.62) 225.805 ms 264.866 ms 287.893 ms 12 ir-frankfurt1.WiN-IP.DFN.DE (193.203.227.18) 33.907 ms 20.889 ms 21.918 ms 13 ZR-Frankfurt1.WiN-IP.DFN.DE (188.1.144.98) 22.164 ms 22.444 ms 23.534 ms 14 ZR-Koeln1.WiN-IP.DFN.DE (188.1.144.33) 75.619 ms 211.154 ms 242.466 ms 15 Uni-Essen1.WiN-IP.DFN.DE (188.1.6.102) 27.147 ms 28.515 ms 36.096 ms 16 KR-Uni-Essen1.WiN-IP.DFN.DE (188.1.6.166) 28.153 ms 30.981 ms 24.481 ms 17 Uni-Essen1.WiN-IP.DFN.DE (188.1.6.165) 28.175 ms 27.505 ms 27.928 ms 18 KR-Uni-Essen1.WiN-IP.DFN.DE (188.1.6.166) 251.871 ms 30.899 ms 30.939 ms 19 Uni-Essen1.WiN-IP.DFN.DE (188.1.6.165) 30.12 ms 33.21 ms 39.284 ms 20 KR-Uni-Essen1.WiN-IP.DFN.DE (188.1.6.166) 27.753 ms 28.763 ms 28.15 ms 21 Uni-Essen1.WiN-IP.DFN.DE (188.1.6.165) 46.955 ms 32.169 ms 37.127 ms 22 KR-Uni-Essen1.WiN-IP.DFN.DE (188.1.6.166) 37.985 ms 35.388 ms 26.641 ms 23 Uni-Essen1.WiN-IP.DFN.DE (188.1.6.165) 28.455 ms 30.814 ms 30.428 ms 24 KR-Uni-Essen1.WiN-IP.DFN.DE (188.1.6.166) 47.757 ms 29.068 ms 30.278 ms 25 Uni-Essen1.WiN-IP.DFN.DE (188.1.6.165) 28.909 ms 49.848 ms 38.464 ms 26 KR-Uni-Essen1.WiN-IP.DFN.DE (188.1.6.166) 42.089 ms 31.354 ms 35.137 ms 27 Uni-Essen1.WiN-IP.DFN.DE (188.1.6.165) 30.687 ms 44.349 ms 70.558 ms 28 KR-Uni-Essen1.WiN-IP.DFN.DE (188.1.6.166) 33.559 ms 49.084 ms 36.502 ms 29 Uni-Essen1.WiN-IP.DFN.DE (188.1.6.165) 36.483 ms 45.423 ms 33.041 ms 30 KR-Uni-Essen1.WiN-IP.DFN.DE (188.1.6.166) 34.048 ms 32.716 ms 33.079 ms Damn, you shouldn't use NT for serious work :-( JJ --- With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC1925.

1 0

agnes down ?
by Jan-Jaap van der Heijden 30 Nov '97

30 Nov '97

agnes.dida.physik.uni-essen.de seems to be down since last night. Peter (you're not reading this -- your email is @agnes...), I hope nothing serious happened. JJ --- With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC1925.

1 0

Re: Interfacing DJGPP C with Pascal
by Peter Gerwinski 29 Nov '97

29 Nov '97

According to Stanislaw Kozlowski: > I am trying to link a Pascal unit DJGPP C. It links OK but > Pascal run time library seems to be unitialized [...] Before you can use the Pascal run time library you must initialize it by calling `_p_initialize()'. External declaration in C notation follows: extern void _p_initialize ( int argc, char **argv, char **envp ); (The parameters are self-explanatory for C programmers.;-) GPC quits the program by calling extern void _p_finalize ( void ); but it is sufficient to call `_p_fflush()' since `_p_finalize()' reads /* This is called when program ends normally */ void _p_finalize () { _p_fflush(FALSE); /* Call an empty routine, user might want to execute some code here */ _p_final (); exit (0); } Hope this helps, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

1 0

this unit does not work
by laussy 29 Nov '97

29 Nov '97

Hi all, I would like to put some file operation in a separate precompiled unit. The matter is the assign binding code given in the info file does not work when put in a UNIT, where it works when in the program source itself, and some others units I made exactly the same way works fine (not using to begin do). Here is the unit code contening just the binding : -------------- UNIT files_operations; INTERFACE Procedure Assign ( Var T: Text; Name: String ); IMPLEMENTATION Procedure Assign ( Var T: Text; Name: String ); Var B : BindingType; begin (* Assign *) unbind ( T ); B:= binding ( T ); B.Name:= Name; bind ( T, B ); B:= binding ( T ); end; (* Assign *) END. --------------- And when linked as the usual way in the program, it makes it crash (segmentation fault). gpc --version 2.0(2.7.2.1)

2 1

Re: iso10206 Seek Functions and a couple other little things....
by Peter Gerwinski 28 Nov '97

28 Nov '97

According to Kevin A. Foss: > > Actually it works without patching the source because you are doing > non-continuous reads -e.g. using seekread() before each read(). Okay, so what about this one: Program Test ( Output ); Var Data: File [ 0..25 ] of Char; C: Char; begin rewrite ( Data ); for C:= 'A' to 'Z' do write ( Data, C ); reset ( Data ); SeekRead ( Data, ord ( 'O' ) - ord ( 'A' ) ); read ( Data, C ); write ( C ); SeekRead ( Data, ord ( 'K' ) - ord ( 'A' ) - 1 ); read ( Data, C ); read ( Data, C ); writeln ( C ); end. It produces "OK" with the patch; "OJ" without. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

1 0

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