Gambit-list Décembre 2007

gambit-list@iro.umontreal.ca

20 participants
25 discussions

Edge triggered I/O with libevent
by Adam Langley 04 Avr '13

04 Avr '13

Gambit uses the select call on POSIX systems to multiplex IO operations. This is fine for small numbers of file descriptors, but falls apart quickly with large numbers[1]. libevent[2] is a wrapper library around a number of modern IO multiplexing systems (epoll on Linux, kqueue on the BSDs as well as poll and select). Attached is a patch which converts Gambit to using edge triggered I/O with epoll and libevent. This also requires a patch (attached) of libevent since the standard distribution doesn't include edge triggering support and the upstream appears to be on holiday. (epoll is required because I don't have a BSD box on which to develop edge triggering support for kqueue) This patch (for Gambit) preprocesses away to nothing unless --enable-libevent is passed to the configure script. (Note that, since this patches the configure.ac script, you'll need to run autoconf to regenerate). I hope I've not broken anything, but at this stage I've only tested that the console and tcp ports work. This patch (in the future) should also allow people, who write programs which use socket calls directly, to integrate into the main event loop at some point. Testing is more than welcome and, if you find a form of IO which is broken, please email me. [1] http://monkey.org/~provos/libevent/libevent-benchmark2.jpg [2] http://monkey.org/~provos/libevent/ -- Adam Langley agl(a)imperialviolet.org http://www.imperialviolet.org (+44) (0)7906 332512 PGP: 9113 256A CC0F 71A6 4C84 5087 CDA5 52DF 2CB6 3D60

2 2

Please don't delete the .c file
by Bradley Lucier 06 Fév '08

06 Fév '08

Marc: I needed to debug a gsc-compiled file with gdb today, and it was fairly inconvenient that the .c file wasn't left around by compile- file in beta 21. I suggest that the .c file be left around for the various source tools that need it. Brad

3 10

Building issues with 4.1.2 under Windows
by Nick 07 Jan '08

07 Jan '08

2 2

Glitch mixing process ports and Xlib.
by Esteban U. Caamano Castro 31 Déc '07

31 Déc '07

I have a problem mixing Gambit C's process ports and Xlib. I got this problem in version 4 beta 20, but could still reproduce it in a freshly built v4.1.2. I thought I'd bounce it here just to make sure I haven't missed something obvious, before submitting a bug report. The reproduction steps are: - Write an app that - Opens a child process with default arguments (only the path). - In the child process, - prints something to (current-error-port). - write-u8 some data to standard output (i.e., back to the main process). - Execute that app from an X terminal. - Close the app window. - Try to type stuff in the X terminal. What you type after that is not displayed in the terminal. Your input is recognized and processed by the terminal, but you can't see it. I could reproduce this in two Debian Linux boxes with different (NVidia vs ATI) proprietary X servers. To make sure this is a problem with Gambit and not Xlib, I have made an (I believe) equivalent pure C program, which doesn't misbehave. I could not reproduce this without involving X Windows. The error does still happen if the X Windows app exits gracefully (i.e., by advertising WM_DELETE_WINDOW protocol and closing the window on receipt of the appropriate ClientMessage,) but only if you print to standard error before opening the window or while it is live. The error doesn't happen if you print to standard error only after closing the window, just before exiting the process. Here is the minimal Gambit program that I could find that will display the error: --- main.scm --- (let ((p (open-process "./child"))) (letrec ((loop (lambda () (let ((evt-type (read-u8 p))) (display "got ") (display evt-type) (newline) (if (eqv? evt-type #!eof) (void) (loop)))))) (loop))) (display "Main says bye!") (newline) --- child.scm --- (c-declare #<<c-declare-end #include <X11/Xlib.h> Display* dpy; int scr; Window win; XEvent event; c-declare-end ) (define open-window (c-lambda () unsigned-long #<<c-lambda-end dpy = XOpenDisplay(NULL); scr = DefaultScreen(dpy); win = XCreateSimpleWindow(dpy, RootWindow(dpy, scr), 0, 0, 300, 300, 0, BlackPixel(dpy, scr), WhitePixel(dpy, scr)); XSelectInput(dpy, win, ExposureMask | ButtonPressMask | StructureNotifyMask); XMapWindow(dpy, win); ___result = win; c-lambda-end )) (define next-event (c-lambda () int #<<c-lambda-end XNextEvent(dpy, &event); ___result = event.type; c-lambda-end )) ;; !!! If you comment out the following lines, !!! ;; !!! the error doesn't happen. !!! (display "Child says hello!" (current-error-port)) (newline (current-error-port)) (open-window) (letrec ((loop (lambda () (write-u8 (next-event)) (force-output) (loop)))) (loop)) --- to test the above --- #!/usr/bin/env sh gsc -link child.scm && \ gcc -lX11 -lgambc child.c child_.c -o child && \ gsi main.scm The following is the equivalent C program that doesn't misbehave (if you try it put it in a separate directory): --- main.c --- #include <stdio.h> #include <stdlib.h> int main(int argc, char** argv) { FILE* fp; int evt; fp = popen("./child", "r"); do { evt = getc(fp); printf("got %d\n", evt); } while (evt != -1); printf("Main says bye!\n"); return 0; } --- child.c --- #include <stdio.h> #include <stdlib.h> #include <X11/Xlib.h> int main(int argc, char** argv) { Display* dpy; int scr; Window win; XEvent event; fprintf(stderr, "Here we go!\n"); dpy = XOpenDisplay(NULL); scr = DefaultScreen(dpy); win = XCreateSimpleWindow(dpy, RootWindow(dpy, scr), 0, 0, 300, 300, 0, BlackPixel(dpy, scr), WhitePixel(dpy, scr)); XSelectInput(dpy, win, ExposureMask | ButtonPressMask | StructureNotifyMask); XMapWindow(dpy, win); for (;;) { XNextEvent(dpy, &event); putchar(event.type); fflush(stdout); } return 0; } --- to test the above --- #!/usr/bin/env sh gcc main.c -o main && \ gcc -lX11 child.c -o child && \ ./main Regards, Esteban.

1 0

FFI and SCMOBJ to C representation
by Adrien Pierard 29 Déc '07

29 Déc '07

Hello, I'm currently writing an API for a simple 2D graphics library for Gambit, based on TinyPTC and SDL. However, it seems that I have some issues with conversion of Scheme data to C. Here is the API idea: (PTC-OPEN name width height) creates a window (PTC-CLOSE) closes the window (PTC-UPDATE buffer) blits the buffer to the window I chose to represent the buffer with a vector. I'd even prefer an U32VECTOR for colors are represented by an unsigned integer, however. The update function works like this: int scm_ptc_update (___SCMOBJ) { int idx; ___SCMOBJ ___temp; // for the type test if ( ___VECTORP(obj) ) { for(idx=0 ; idx < width * height ; idx++ ) { buffer[idx] = ___INT ( ___VECTORREF (obj, idx)); } // Call the underlying update function return (( ptc_update (buffer)) == PTC_SUCCESS ? ___TRU : ___FAL ); } else { return ( ___FAL ); } }; If the test program fills the vector with (vector-set! buffer (random-integer 255)) I see large vertical and periodical stripes, and , roughly, grey noise, instead of blue noise. Printf-ing the values shows a lot of them greater than 255. Therefor, I reckon that my conversion is not correct. How should I then read a Scheme int32 value to store it in C ? Subsidiary question: how can I call pp or pretty-print from withing C? To do something like ___PRETTYPRINT(obj); Cordially, Adrien. -- "I am not a Church numeral; I am a free variable!" (The Scheme Underground) For every complex problem, there is a solution that is simple, neat, and wrong.

2 1

Possibility of Gambit combined with DevCpp?
by Bob McIsaac 27 Déc '07

27 Déc '07

Hi: Since Gambit prebuild with mingw is easy to install and DevCpp from http://www.bloodshed.net/devcpp.html , which embeds gcc 3.4.2 is also easy, would it be possible to combine them with the goal of easing setup for the mingw-challenged such as yours truly? And I should ask if this is feasible or a hopeless hack? The experiment below almost worked but it needs to satisfy Gambit's os.c which is looking for htonl and other winsock functions. These are found in libwsock32.a -Bob- # Project: Test1 # Makefile created for Dev-C++ 4.9.9.2 CC = gcc.exe CFLAGS = -Wall -W -Wno-unused -O1 -fno-math-errno \ -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing \ -fwrapv -fno-common -mieee-fp -shared \ -D___DYNAMIC -D___SINGLE_HOST LIBS = -L"C:/Dev-Cpp/lib" -L"c:/Gambit-C/v4.1.2/lib" INCS = -I"C:/Dev-Cpp/include" -I"c:/Gambit-C/v4.1.2/include" EXE = Test1.exe .PHONY: all all: $(EXE) $(EXE): $(CC) $(CFLAGS) $(INCS) test.c test_.c $(LIBS) \ -lwsock32 -lgambc -o $(EXE) # test.scm just displays hello world. it works with gsi ----- result ---- cd c:/Dev-Cpp/home/test/ make gcc.exe -Wall -W -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fno-common -mieee-fp -shared -D___DYNAMIC -D___SINGLE_HOST -I"C:/Dev-Cpp/include" -I"c:/Gambit-C/v4.1.2/include" test.c test_.c -L"C:/Dev-Cpp/lib" -L"c:/Gambit-C/v4.1.2/lib" \ -lwsock32 -lgambc -o Test1.exe c:/Gambit-C/v4.1.2/lib/libgambc.a(os.o)(.text+0x5f):os.c: undefined reference to `htonl@4' c:/Gambit-C/v4.1.2/lib/libgambc.a(os.o)(.text+0xdd):os.c: undefined reference to `ntohl@4' c:/Gambit-C/v4.1.2/lib/libgambc.a(os.o)(.text+0x22d):os.c: undefined reference to `htons@4' ... ...

2 1

calling a function in dll
by Nick 27 Déc '07

27 Déc '07

2 2

string-length of Asian chracter-set
by Li Xiangyang 21 Déc '07

21 Déc '07

When I eval (string-length some-chinease-string), the result is double of the number of the characters, I try to set some runtime options(-:), not no difference. _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

2 1

Re: [gambit-list] Reading binary files
by Bob McIsaac 20 Déc '07

20 Déc '07

Alex Sandro Queiroz e Silva wrote: > Hallo, > > Bob McIsaac escreveu: >> The puzzling comment to my humble form said : "This code assumes that >> arguments to functions are evaluated left-to-right." But what of it? >> There is a stream of text to be evaluated. Choices are 1. left-right >> evaluation in one pass; 2. parsing the stream into tokens and sorting >> the tokens into a tree according to the rules of the grammar ... not >> Lispy. Choice 1 means typing parentheses so that the evaluator can be >> simple and recursive. ( I assume that evaluation results in a linked >> list) >> > > You are confused here. You may believe that evaluating arguments > to functions "in one pass" is the most efficient way, but it may not > be. Scheme compilers are free to change the order of evaluation of the > arguments to functions at will, so they can find better arrangements. > Not all compilers do that, though. > > Cheers, > -alex > > > > Hi: I am not too worried about efficiency but I must read some more the meaning of evaluation. I thought it was a method of converting expressions into executable code. Perhaps it is more subtle than I realized. Cheers, -Bob-

1 0

Termite in production?
by Joel Reymont 20 Déc '07

20 Déc '07

Is anyone running Termite in production? Is it considered production-ready? Thanks, Joel -- http://wagerlabs.com

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Gambit-list Décembre 2007