Gambit-list Décembre 2005

gambit-list@iro.umontreal.ca

13 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

Incremental garbage collector
by Chris Newcombe 01 Jan '06

01 Jan '06

Marc, I read your paper "A compacting incremental collector and its performance in a production quality compiler": www.iro.umontreal.ca/~feeley/papers/ismm98.ps.gz - Is (or will) this incremental collector available for Gambit v4? Soft-realtime behavior is important in my app. - The paper is quite old. Does the description of the blocking collector in section 3 still apply to Gambit v4? (I only ask the second question because under "Main new features" in http://www.iro.umontreal.ca/~boucherd/mslug/meetings/20040519/mslug1.pdf.gz, it mentions "Better GC (safe for space)".) The hybrid approach in this Erlang paper is interesting: http://user.it.uu.se/~kostis/Papers/ismm04.pdf thanks, Chris

4 4

OpenGL bindings for Gambit-C 4.0 beta 15
by TJay 31 Déc '05

31 Déc '05

I've written a binding for OpenGL 1.0 and its corresponding GLU library for Gambit. This binding is done entirely in C style (i.e. pointers, explicit memory management, passing pointers to procedures, etc). I've since decided that it would be nightmare to program in this style, and am now embarking on writing a proper, Scheme-style binding. Anyways I've uploaded it for anyone who's interested. Note that the only testing I've done with it is to clear the framebuffer to white :p http://www.archive.org/download/Cstyle_OpenGL_1.0__GLU_bindings_for_GambitC… ~ TJay ~

1 0

4.0b16 and/or getting address info from a network socket
by david rush 31 Déc '05

31 Déc '05

Hi Y'all, I was really pleased to hear that beta 16 was going to include > (tcp-client-self-socket-info tcp-client-port) > (tcp-client-peer-socket-info tcp-client-port) but now I'm wondering when beta 16 is going to be released so I can use the functions. Failing a clear date (and believe me I know how that goes), can someone please provide a hint about how to implement them myself? A patch file to the beta 15 codebase would also be excellent. I need this for two purposes (although one can be worked around without that information): message routing in a mesh-connected topology and for minimizing the amount of traffic necessary to update the routing maps. And as I write, I have concocted another way to do it, but it also involves writing yet another networking layer :P I'd prefer to leverage the underlying TCP Stack information if I can :) david rush -- DIsruptive Technology!

1 0

Re: [gambit-list] Debugging of invalid generated syntax
by Christian 31 Déc '05

31 Déc '05

At 0:52 Uhr -0500 31.12.2005, Marc Feeley wrote: >On 27-Dec-05, at 6:31 PM, Christian wrote: > >>I'm thinking about writing a 'lowlevel' macro-expansion system which >>tracks source location (as I've mentioned in a mail a few weeks >>ago). That would help with problem 1 (it would directly show the >>relevant line). >> >>My other suggestions would be: >> - (2) show the invalid macro-expanded code in the error message >> - (3) would it be feasible to compile the gambit core with `debug ? >> - (5) are there hooks into the builtin macro-expander? (to be able to >> grab the partially macro-expanded code oneself) > >What Gambit really needs is an implementation of syntax-case that >tracks source location information. It has been on my TODO list for >a while, and I have a few bits and pieces working, but still far >from a complete implementation. Are you modifying the portable syntax-case implementation, or writing a new implementation, or implementing srfi-72 ? Could you already provide some code to experiment with (that might at least help my understandings)? Do you have an estimation of when it will be ready? I've been hoping to reimplement a middle-sized system (publication system for an online journal, currently about 50'000 LOC of own Perl, C, XSP and XSLT code) on Gambit by the end of the next summer (and I only have about one third of the time till then for working on it). Currently there are dangerously many things missing for that: module system (but I think I may handle it with chjmodule), an OO system (meroon (with macro/debugging improvements? Not having error location information in define-method bodies might turn out to be a nightmare) or another system), possibly many smaller things ('greedy' macro expansion?,..) which need more knowledge of Gambit internals from my side. I'm also not yet sure how to handle concurrency, because of the issue of C libraries blocking other gambit threads (maybe I'll just ignore it for now?, or fall back to a forking or multiprocess (Termite?) model?, but would that mean I have to forget interactive development and live debugging and resort to a restart-on-changes model? And thus *really* have to serialize all continuations?). I don't dare to think that I'll also still have to port some server libraries from places like scheme underground or SISC or PLT server (or peek at their sources and implement new ones). Is anyone else wanting to do similar things and willing to join efforts? I'll now just send this mail out, maybe someone should tell me it's impossible. Christian.

1 0

Fwd: [gambit-list] C interface: wrong types generated?
by TJay 31 Déc '05

31 Déc '05

> > I've written an OpenGL + GLU binding for Gambit-C, which is (I think > > and hope) 100% done, except for this type error: > > Great! Care to contribute your code so that I can add it to the > Gambit distribution? > > Marc Sure thing, I just want to test it first, to see if it works at all. Will let you know when I think it's working correctly ;) Note that it's a straightforward mapping from the C API though, no Scheme niceties added, with the exception that malloc'ed memory is garbage collected. I thought it would be better not to change the behaviour of the OpenGL API, and instead build a more programmer-friendly windowing library on top of that. Cheers :) ~ TJay ~

1 0

C interface: wrong types generated?
by TJay 31 Déc '05

31 Déc '05

I don't know if the compiler is generating the wrong type, or i'm doing something wrong... I've written an OpenGL + GLU binding for Gambit-C, which is (I think and hope) 100% done, except for this type error: glColor.c: In function '___H__20_glColor_23_16': glColor.c:1558: warning: pointer targets in passing argument 1 of 'glColor3bv' differ in signedness glColor.c: In function '___H__20_glColor_23_24': glColor.c:1982: warning: pointer targets in passing argument 1 of 'glColor4bv' differ in signedness glNormal.c: In function '___H__20_glNormal_23_5': glNormal.c:563: warning: pointer targets in passing argument 1 of 'glNormal3bv' differ in signedness All three of these mismatched arguments have the same type. Here's the type in C: typedef signed char GLbyte; /* 1-byte signed */ And in Gambit-C: (c-define-type GLbytesigned-char) (c-define-type GLbyte* (pointer GLbyte)) GLAPI void GLAPIENTRY glNormal3bv( const GLbyte *v ); TJay ~

4 12

Debugging of invalid generated syntax
by Christian 31 Déc '05

31 Déc '05

Hello While playing with Meroon (the version provided by Bradley Lucier), I've realized that debugging is made difficult in cases where macro-generated code has invalid syntax. The example where I've seen this: ;; (in "test-meroon.scm": ;; I've define-class'ed area, triangle, and quadrangle, and ;; defined a generic area and a method (area (s triangle) . rest). ;; But this fails: ) (define-method (area (s quadrangle) . rest) (let ((m (if (null? rest) (error "missing m") (car rest)))) (let ((triangle-area (call-next-method))) (warn "triangle-area: " triangle-area) (* triangle-area m)))) ;; when entering the equivalent of ;; (compile-file "./test-meroon.scm" '(debug expansion verbose)) : *** ERROR IN "/home/chris/schemedevelopment/gambit/mod/./test-meroon.scm"@156.1 -- Ill-formed procedure call Now how am I supposed to find out what went wrong? 1- the line/col position points at the start of the define-method form. 2- the error message does not show the macro-expanded code 3- entering ,e in the debugger doesn't show the relevant syntax either, since the gambit internals have been compiled without debugging information. (I'm not sure if compiling with '(debug) would help, since sometimes (frequently?) the lexical environment is not even accessible then; well: ,e often shows it, but entering the name of one of the variables shown by ,e cannot access it.) 4- the `expansion (and `verbose) compile flags don't help either: it seems that the error happens during macro-expansion, before expansion has finished. 5- this won't help either: > (define oldexp c#expand-source) > (define seen-syn #f) > (define seen-res #f) > (set! c#expand-source (lambda (syn) (set! seen-syn syn) (let ((res (oldexp syn))) (set! seen-res res) res))) since after running compilation again, (equal? seen-syn seen-res) is #t, which means that macro-expansion doesn't happen in the default c#expand-source handler -- it is c#wrap-program by default and doesn't do anything. Of course, my example above is relatively simple, and I've tracked the problem down to (call-next-method), it seems that with the rest argument, meroon is building invalid syntax. But gambit doesn't help me in any way to find out exactly what's wrong. I'm thinking about writing a 'lowlevel' macro-expansion system which tracks source location (as I've mentioned in a mail a few weeks ago). That would help with problem 1 (it would directly show the relevant line). My other suggestions would be: - (2) show the invalid macro-expanded code in the error message - (3) would it be feasible to compile the gambit core with `debug ? - (5) are there hooks into the builtin macro-expander? (to be able to grab the partially macro-expanded code oneself) Thanks Christian.

2 1

Adding POLLs to C code
by Bradley Lucier 31 Déc '05

31 Déc '05

Marc: Is there any way to add POLLs to C code? There's a C library I'd like to link to a program, but one C routine could possibly take seconds or minutes to run, and Gambit disables interrupts except through POLLs. Brad

4 3

Creating and returning scheme lists inside C functions?
by TJay 30 Déc '05

30 Déc '05

How do I create a scheme list inside a C function, and return that list? I couldn't find any documentation on this, so I searched through gambit.h and came up with this, which fails to compile due to "___hp" being "undeclared". ___hp seems to be used in the definition of ___CONS. ;;======================================== ;; Is this the correct way to create lists? (c-declare #<<c-declare-end ___SCMOBJ getList () { ___SCMOBJ *a, *b, *c; ___S8 one, two, three; one = 1; two = 2; three = 3; return ___CONS(one, ___CONS(two, ___CONS(three, ___NUL))); } c-declare-end ) (define get-list (c-lambda () scheme-object "getList")) (read) ;So that I can enter the REPL by interrupting the program. ;;======================================== ~ TJay ~

3 2

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 2005