Gambit-list Avril 2005

gambit-list@iro.umontreal.ca

8 participants
10 discussions

Re: file-seek in Gambit.
by Marc Feeley 18 Sep '05

18 Sep '05

> I can't seem to find a way to seek in and get the position in files > using Gambit (4beta11). Wouldn't this be a handy feature? Yes, I have been planing this for a while and have just completed the implementation and documentation. Here it is: @deffn procedure input-port-byte-position @var{port} @r{[}@var{position} @r{[}@var{whence}@r{]}@r{]} @deffnx procedure output-port-byte-position @var{port} @r{[}@var{position} @r{[}@var{whence}@r{]}@r{]} When called with a single argument these procedures return the byte position where the next I/O operation would take place in the file attached to the given @var{port} (relative to the beginning of the file). When called with two or three arguments, the byte position for subsequent I/O operations on the given @var{port} is changed to @var{position}, which must be an exact integer. When @var{whence} is omitted or is 0, the @var{position} is relative to the beginning of the file. When @var{whence} is 1, the @var{position} is relative to the current byte position of the file. When @var{whence} is 2, the @var{position} is relative to the end of the file. The return value is the new byte position. On most operating systems the byte position for reading and writing of a given bidirectional port are the same. When @code{input-port-byte-position} is called to change the byte position of an input-port, all input buffers will be flushed so that the next byte read will be the one at the given position. When @code{output-port-byte-position} is called to change the byte position of an output-port, there is an implicit call to @code{force-output} before the position is changed. For example: @smallexample > @b{(define p @r{@i{; p is an input-output-port}} (open-file '(path: "test" char-encoding: latin1 create: maybe)))} > @b{(list (input-port-byte-position p) (output-port-byte-position p))} (0 0) > @b{(display "abcdefghij\n" p)} > @b{(list (input-port-byte-position p) (output-port-byte-position p))} (0 0) > @b{(force-output p)} > @b{(list (input-port-byte-position p) (output-port-byte-position p))} (11 11) > @b{(input-port-byte-position p 2)} 2 > @b{(list (input-port-byte-position p) (output-port-byte-position p))} (2 2) > @b{(peek-char p)} #\c > @b{(list (input-port-byte-position p) (output-port-byte-position p))} (11 11) > @b{(output-port-byte-position p -7 2)} 4 > @b{(list (input-port-byte-position p) (output-port-byte-position p))} (4 4) > @b{(write-char #\! p)} > @b{(list (input-port-byte-position p) (output-port-byte-position p))} (4 4) > @b{(force-output p)} > @b{(list (input-port-byte-position p) (output-port-byte-position p))} (5 5) > @b{(input-port-byte-position p 1)} 1 > @b{(read p)} bcd!fghij @end smallexample @end deffn > Also, while I'm making suggestions: Have you thought about > implementing a simple package system, for example something like > Chicken Scheme's eggs[3]? No. I'm not saying this wouldn't be useful, just that I haven't perceived a need for it yet. There's really nothing to change in Gambit itself to implement a package system like the one Chicken uses because Gambit's installation directory (/usr/local/Gambit-C) can be used for this. The subdirectory /usr/local/Gambit-C/package would store the installed packages, and the programs would use these packages like this: (include "~~/package/Xlib.scm") (include "~~/package/arrays.scm") ... or (load "~~/package/foo") The system extension file (~~/gambcext) could also be modified for the packages that need to permanently extend Gambit (this file is loaded whenever the interpreter is started). The most tedious in all of this is to implement the package management tool that installs the packages, compiles them if needed, checks for the latest version, checks package dependencies, etc. If you want to contribute such a tool please be my guest. What I can do is help you out in the design and host the packages that people contribute on Gambit's web site. Of course some of this work may have to be duplicated when the R6RS module system comes out... Marc

2 2

running remote jobs with `time'
by Bill Richter 21 Mai '05

21 Mai '05

I haven't been able to run niced background jobs, and I think I finally know why, because `time' wants to print to the console which no longer exists. But I'm not quite there yet: The Gambit manual says `time' uses the interaction channel: - special form: time EXPR The `time' special form evaluates EXPR and returns the result. As a side effect it displays a message on the interaction channel which indicates how long the evaluation took (in real time and cpu time), how much time was spent in the garbage collector, how much memory was allocated during the evaluation and how many minor and major page faults occured (0 is reported if not running under UNIX). Now the node "Runtime options" says I can change the interaction channel: Both `gsi' and `gsc' as well as executable programs compiled and linked using `gsc' take a `-:' option which supplies parameters to the runtime system. `-' The REPL interaction channel will be standard input and standard output. I have a 1-line file "6.scm" (time (pretty-print 6)) So to me, the manual says that % gsi -:- 6.scm > six-out should print the time info as well as the output 6 to the file "six-out". But it doesn't: (banach)PolyTree> gsi -:- 6.scm > six (time (pretty-print 6)) 0 ms real time 0 ms cpu time (0 user, 0 system) no collections 104 bytes allocated no minor faults 5 major faults (banach)PolyTree> more six-out 6 Now it doesn't make much difference where the time info goes, unless I'm running a job overnight, nice-ed in the bg. These nice-ed bg jobs of mine hang, run for days, and I think because they want to print to the console, which no longer exists. So people must know how to solve this problem. Help!

4 6

srfi-13/14
by ben＠fuhok.net 12 Mai '05

12 Mai '05

I made a few changes to Brad's excellent char-set-lib and string-lib libraries. These versions can be used with gsi, and you don't have to compile them inside the gambit source tree. `gsc -dynamic' should do the trick. I also fixed a copy of small bugs --- hopefully I didn't introduce too many in their place ;-) I haven't tested these rigorously though. Gambit seems like an awfully nice Scheme, but as distributed it is too spartan for my needs. I'd like to help where I can with porting useful libraries. Regards, Ben

2 15

Code for Generic arrays
by Bradley Lucier 30 Avr '05

30 Avr '05

I mentioned before in http://groups-beta.google.com/group/comp.lang.scheme/browse_thread/ thread/b2b0f2 84af10d309/17b266e34fbb7f17?q=lucier+arrays&rnum=3#17b266e34fbb7f17 the availability of code for operations on what I consider to be generic arrays. I've just finished a test suite for that code and in the process found and fixed a fair number of bugs. I'd appreciate any people who might want to try the code, which is at http://www.math.purdue.edu/~lucier/array-code A brief description of the code follows. Arrays are just mappings from Intervals (hyper-rectangles of multi-indices) to Scheme objects; mutable arrays can have this mapping changed with a setter; Fixed-arrays have a backing store. Besides basic functions for manipulating these objects and their fields, the following procedures are provided: Interval-for-each, Interval-reduce Array-lazy-map, Array-for-each, Array-reduce, Array->Fixed-array, Fixed-array-share!, and Array-map Brad

1 0

Any plans to support alternative IO mechanisms? (epoll, kqueue etc)
by Eric Merritt 27 Avr '05

27 Avr '05

A friend posed this question to me and I thought I would forward it to the list to get a correct answer. Are there any plans to make use of mechanisms like epoll or kqueue where they are available (on their respective platforms)?

2 2

statprof -- a statistical profiler for Gambit-C 4.0
by Guillaume Germain 27 Avr '05

27 Avr '05

With some help from Marc Feeley I have implemented a simple statistical profiler for Gambit. It is available at the following address: http://www.iro.umontreal.ca/~germaing/statprof.html Here's an output example: http://www.iro.umontreal.ca/~germaing/ring.scm.html It's not perfect and was put together somewhat quickly, but I think it can be useful. Guillaume

3 3

Re: Doc Request
by Marc Feeley 18 Avr '05

18 Avr '05

I can't answer all your questions right now, but here's some information on wrapping procedures created by compiled code and interpreted code. The abstractions are a bit low-level, but can be used to build your own abstractions. Marc ; Here are a few internal procedures you will find useful. ; ; (##interp-procedure? p) returns true iff the procedure p was created by ; interpreted code (an interpreted procedure) ; ; (##interp-procedure-code p) returns the code pointer of interpreted ; procedure p (the code pointer is unique ; for each lambda-expression and can be used ; to identify the lambda-expression) ; ; (##interp-procedure-rte p) returns the run time environment of ; interpreted procedure p; the runtime ; environment contains the value of bound ; variables; each binding form contributes ; a frame to the environment; each frame ; is a vector and the first element points ; to the enclosing environment; the other ; elements contain bound variable values ; (in the order they appear in the ; source); for environments created by a ; lambda-expression the second element is ; a "self" reference (= the closure) ; ; (##closure? p) returns true iff the procedure p is a closure (note that ; an interpreted procedure is also a closure) ; ; (##closure-code p) returns the code pointer of closure p (the code ; pointer is unique for each lambda-expression and ; can be used to identify the lambda-expression) ; ; (##closure-ref p i) returns the value of free variable number i (>= 1); ; mutable free variables are boxed; a flat closure ; representation is used; the variables appear in ; alphabetical order ; ; (##closure-length p) returns the number of fields in closure p (= the ; number of free variables plus 1) (define (wrap proc info) (lambda (arg1 arg2) (##first-argument info) ; needed so that the compiler keeps "info" ; as a free variable (proc arg1 arg2))) (define code-ptr-of-wrapped (let ((p (wrap #f #f))) (cond ((##interp-procedure? p) (##interp-procedure-code p)) ((##closure? p) (##closure-code p)) (else (error "neither interpreted or compiled closure"))))) (define (wrapped? p) (cond ((##not (##procedure? p)) #f) ((##interp-procedure? p) (eq? (##interp-procedure-code p) code-ptr-of-wrapped)) ((##closure? p) (eq? (##closure-code p) code-ptr-of-wrapped)) (else #f))) (define (wrapped-info p) ; extracts "info" of wrapped procedure p (cond ((##interp-procedure? p) (vector-ref (##interp-procedure-rte p) 3)) ; info is at index 3 ((##closure? p) (##closure-ref p 1)) ; info is at index 1 (else (error "neither interpreted or compiled closure")))) ; test it! works the same compiled and interpreted... (define f (wrap + "this is the addition procedure")) (pp (f 10 20)) ; 30 (pp (wrapped? f)) ; #t (pp (wrapped-info f)) ; "this is the addition procedure" On 17-Apr-05, at 4:49 PM, Ken Dickey wrote: > Greetings, > > I have put together a (pre-alpha/prototype) multiple-inheritance, > multimethod > OO system for Gambit and would like to integrate it closely with > Gambit's > native types (including foreigns). > > The goal is a production quality mi/mm system. > > I would appreciate any notes/docs on internals, especially, > types (##type-type & friends) > ffi > namespaces > compiled procedure representation > > Aside from reading the code, I would not like to inadvertantly miss > assumed > invariants. > > In addition, any hints on the proper protocol for making wrappers for > compiled > code would be helpful. [I am currently using ##make-interp-procedure > (see > krufty code below), but this is not very satisfying]. > > Thanks much, > -KenD > > ;;=========================== > Gambit Version 4.0 beta 12 > >> (include "oops.scm") > Oops: loaded SLOT Support Code > Oops: loaded SLOT-ACCESS Generics Code > Oops: loaded INSTANCE code > Oops: loaded CLASS bootstrap code > Oops: loaded CLASS-HIERARCHY bootstrap code > Oops: loaded DEFINE-CLASS code > Oops: loaded METHODS code > Oops: loaded GENERICS code > loaded Oops! >> (define int-or-string (<type-union> <string> <integer>)) >> (define-method (m (a int-or-string)) (list 'int-or-string a)) > m >> (m 3) > (int-or-string 3) >> (m "3") > (int-or-string "3") >> (define-method (m (s <string>)) (list 'string (next-method))) > #<procedure #3 m> >> (m 5) > (int-or-string 5) >> (m "five") > (string (int-or-string "five")) >> (define-method (m (i <integer>)) > (list 'int i (next-method (number->string i)))) > #<procedure #3 m> >> (m "five") > (string (int-or-string "five")) >> (m 5) > (int 5 (int-or-string "5")) >> (define-class <point> () ((x init-value: 0) (y init-value: 0))) >> (define p (<point> y: 3)) >> (x p) > 0 >> (y p) > 3 >> (x-set! p 5) > #<instance #4 class: #<procedure #5 <point>>> >> (x p) > 5 >> > > ; > ======================================================================= > ====== > ;;; CALLABLES are procedures with slots (a.k.a. executable data > structures) > ;;;; Here used for Classes, Methods & Generic Functions. > > ;; A Callable is an extended Closure: > ;; @@FIXME: !!! make wrapper work for compiled code !!! @@ > ;; slot 0 => <type> ==> <procedure> > ;; slot 1 => $code [NB: Circular self reference] > ;; slot 2 => proc > ;; slot 3 => runtime-environment (or #f) > ;; slot 4 => tag > ;; slot 5 => 1st data slot > ;; slot 6 => 2nd data slot > ;; ... > > > (define %%clone-proc-plus > (let ( (%%interp-proc-type%% (##vector-ref (eval '(lambda (x) x)) > 0)) ) > (lambda (orig-proc num-slots-to-add) > (if (not (procedure? orig-proc)) > (error "Can't clone a non-procedure" orig-proc) > (let ( (proc > (if (or (not (##subtyped? orig-proc)) > (< (##vector-length orig-proc) 4) > (not (eq? (##vector-ref orig-proc 0) > %%interp-proc-type%%))) > ;;@@FIXME: debug wrapper hack for compiled code > @@ > (##make-interp-procedure orig-proc) ;; @@@!!@@@ > ;; > orig-proc)) > ) > (let* ( (orig-length (##vector-length proc)) > (new-length (+ num-slots-to-add orig-length)) > (new-thing (##make-vector new-length #f)) > (max-index (- orig-length 1)) > ) > (##subtype-set! new-thing (##subtype proc)) > (let loop ( (index 0) ) > (##vector-set! new-thing > index > (##vector-ref proc index)) > (if (< index max-index) > (loop (+ index 1)) > new-thing))) > ) ) ) ) ) > > ;; Returns (values constructor predicate make-ref make-set! bind-slot!) > (define proc->callable > (let* ( (tag-slot (##vector-length (eval '(lambda (x) x)))) > (first-data-slot-index (+ 1 tag-slot)) > ) > (lambda (tag num-slots) > (letrec ( (proc->thing > (lambda (proc) > (let ( (new-proc (%%clone-proc-plus proc > (+ 1 num-slots))) ) > (##vector-set! new-proc tag-slot tag) > new-proc))) > (thing? > (lambda (obj) > (and (procedure? obj) > (> (##vector-length obj) > first-data-slot-index) > (eq? tag (##vector-ref obj tag-slot))))) > (make-slot-ref > (lambda (name index) > (let ( (real-index (+ index > first-data-slot-index)) ) > (lambda (obj) > (if (and (thing? obj) > (< real-index (##vector-length obj))) > (##vector-ref obj real-index) > (call-error "Cannot access" 'slot-ref name > obj)))))) > (make-slot-set! > (lambda (name index) > (let ( (real-index (+ index > first-data-slot-index)) ) > (lambda (obj new-value) > (if (and (thing? obj) > (< real-index (##vector-length obj))) > (##vector-set! obj real-index new-value) > (call-error "Cannot slot-set!" name > obj)))))) > (slot-bind! > (lambda (obj index value) > (let ( (real-index (+ index > first-data-slot-index)) ) > (if (and (thing? obj) > (< real-index (##vector-length obj)) > (not (##vector-ref obj real-index))) ;; > #f is > unbound default > (##vector-set! obj real-index value) > (call-error "Cannot slot-set!" index > obj))))) > ) > (values proc->thing thing? make-slot-ref make-slot-set! > slot-bind!) > ) ) ) ) > > ; > ======================================================================= > ====== > ;; E O F ;;

1 0

Re: Help with FFI related error message
by Marc Feeley 12 Avr '05

12 Avr '05

> /usr/local/Gambit-C/bin/gsi lorenz.scm > *** ERROR IN "lorenz.scm"@36.1 -- /usr/local/Gambit-C/bin/gsi: undefined symbol: ____20_glut_2d_ffi_2e_o1 > (load "glut-ffi.o1") > > I assume that ____20_glut_2d_ffi_2e_o1 is the symbol. Only problem is > I can figure out why it's looking for that symbol, not too mention the > curious coincidence that the symbol it's looking for is the name of > the file I am trying to load. Here's a guess... did you rename this file, i.e. mv glut-ffi.o2 glut-ffi.o1 That will not work. The function ____20_glut_2d_ffi_2e_o1 is generated by the Gambit-C compiler in the file "glut-ffi.o1" and corresponds to the initialization function. It has the "o1" part to distinguish the function from the initialization function ____20_glut_2d_ffi_2e_o2 generated in "glut-ffi.o2", if you happen to want to want to load "glut-ffi.o1" and later "glut-ffi.o2" in the same execution of gsi (some operating systems get confused when there are two functions with the same name). Another possibility is that your operating system adds a "_" prefix, or suffix to the symbols and the configure script did not detect this (check the definition of the symbols ___IMPORTED_ID_PREFIX and ___IMPORTED_ID_SUFFIX at the end of include/config.h). Marc

5 9

Re: LAML for Gambit-C 4, gsi
by Thomas Hafner 01 Avr '05

01 Avr '05

Hello, is anybody else interested in running Kurt Nørmark's LAML with Gambit 4? Kurt agrees that I forward some of our conversation about this. I'll upload the attachment that I was talking about to <http://hafner.sdf-eu.org/pool/laml-for-gambit4.tgz> Thomas Hafner <thomas(a)hafner.nl.eu.org> wrote/schrieb <20050323194538.ECC4991B530(a)schnucke.hafner.nl.eu.org>: > Hello Mr. Nørmark, > > Kurt Noermark <normark(a)cs.aau.dk> wrote/schrieb <yeg64zlz665.fsf(a)homer.cs.aau.dk>: > > > Thomas Hafner <thomas(a)hafner.nl.eu.org> writes: > > > > I will like to support your work on establishing a healthy LAML support > > for Gambit-C. In the end, I would like to receive your setup files, and > > include them in forthcoming LAML distributions. > > Thanks for your offer to support me. I've attached an archive > containing my first successfull configuration files for calling LAML > from a command prompt. > > I've used Gambit Version 4.0 beta 11 (the most recent released one > would be beta 12). > > Output of uname -a is: > Linux schnucke 2.4.29 #2 Mit Mär 9 19:35:04 CET 2005 i686 GNU/Linux > > My OS is Debian 3.1. > > > Have you looked at the Emacs stuff, more specifically how to activate > > LAML via Emacs? Personally, I think this the most important part. > > An this part will certainly be part of a "full LAML support" for Gambit. > > Although I'm using Emacs, I'm not used to program in elisp. I noticed, > that the procedure start-process is used to call LAML out of emacs. > That makes me think about what to pass as arguments. You may wonder > why this should be a problem. The promlem that I've encountered is > that the Gambit interpreter (gsi or gsi-script) may treat command > arguments as another files to be loaded. That depends on the first > line of first file to be interpreted. I haven't found another means > (e.g. command line option) to influence that behaviour than by writing > that first line. That works like follows, using bash rather than a > temporary file. > > - If bash is called out of sh, just to demonstrate what have to be > passed as arguments: > > #!/bin/sh > > exec bash -c 'gsi-script <(echo '\''#!/usr/bin/env gsi-script > ;; begin of scheme code > ;;... > ;; end of scheme code > '\'') "$@"' -- 'foo' 'bar' ... > > - Speaking in terms of man 3 exec: > > path[] shall be: > bash > > argv[0] shall be: > -c > > argv[1] shall be: > gsi-script <(echo '#!/usr/bin/env gsi-script > ;; begin of scheme code > ;;... > ;; end of scheme code > ') "$@" > > argv[2] shall be: > -- > > argv[3] shall be: > foo > > argv[4] shall be: > bar > > a.s.o. > > It's not very nice to depend from bash, because some systems (e.g. > NetBSD) don't have it installed per default. But it's more elegant > than a solution using a temporary file, I think. Maybe one day I'll be > able to include that into laml-execute.el. > > Regards > Thomas Hafner > > -- > ___ http://hafner.sdf-eu.org/ ___ > ___ mailto:thomas@ ______________ > ____________ hafner.nl.eu.org ___ Kurt Noermark <normark(a)cs.aau.dk> wrote/schrieb <yegmzsmq4oi.fsf(a)homer.cs.aau.dk>: > Thomas Hafner <thomas(a)hafner.nl.eu.org> writes: > > Thomas, > > I will put your compatibility file and your exec file into the LAML distribution, > and I will notice that you have done the work. > > With respect to starting LAML from Emacs: It is my experience that it can be > quite difficult to know the command line option well enough to start LAML successfully > from Emacs. It took me some time to play with all the options when I handled > MzScheme, Guile, and others. I do not know Gambit at all, and as such it will be very > difficult for me (and most certainly time consuming) to set this up. > > We will leave this aspect unimplemented for Gambit. > > > Hello Mr. Nørmark, > > > > Kurt Noermark <normark(a)cs.aau.dk> wrote/schrieb <yeg64zlz665.fsf(a)homer.cs.aau.dk>: > > > > > Thomas Hafner <thomas(a)hafner.nl.eu.org> writes: > > > > > > I will like to support your work on establishing a healthy LAML support > > > for Gambit-C. In the end, I would like to receive your setup files, and > > > include them in forthcoming LAML distributions. > > > > Thanks for your offer to support me. I've attached an archive > > containing my first successfull configuration files for calling LAML > > from a command prompt. > > > > I've used Gambit Version 4.0 beta 11 (the most recent released one > > would be beta 12). > > > > Output of uname -a is: > > Linux schnucke 2.4.29 #2 Mit Mär 9 19:35:04 CET 2005 i686 GNU/Linux > > > > My OS is Debian 3.1. > > > > > Have you looked at the Emacs stuff, more specifically how to activate > > > LAML via Emacs? Personally, I think this the most important part. > > > An this part will certainly be part of a "full LAML support" for Gambit. > > > > Although I'm using Emacs, I'm not used to program in elisp. I noticed, > > that the procedure start-process is used to call LAML out of emacs. > > That makes me think about what to pass as arguments. You may wonder > > why this should be a problem. The promlem that I've encountered is > > that the Gambit interpreter (gsi or gsi-script) may treat command > > arguments as another files to be loaded. That depends on the first > > line of first file to be interpreted. I haven't found another means > > (e.g. command line option) to influence that behaviour than by writing > > that first line. That works like follows, using bash rather than a > > temporary file. > > > > - If bash is called out of sh, just to demonstrate what have to be > > passed as arguments: > > > > #!/bin/sh > > > > exec bash -c 'gsi-script <(echo '\''#!/usr/bin/env gsi-script > > ;; begin of scheme code > > ;;... > > ;; end of scheme code > > '\'') "$@"' -- 'foo' 'bar' ... > > > > - Speaking in terms of man 3 exec: > > > > path[] shall be: > > bash > > > > argv[0] shall be: > > -c > > > > argv[1] shall be: > > gsi-script <(echo '#!/usr/bin/env gsi-script > > ;; begin of scheme code > > ;;... > > ;; end of scheme code > > ') "$@" > > > > argv[2] shall be: > > -- > > > > argv[3] shall be: > > foo > > > > argv[4] shall be: > > bar > > > > a.s.o. > > > > It's not very nice to depend from bash, because some systems (e.g. > > NetBSD) don't have it installed per default. But it's more elegant > > than a solution using a temporary file, I think. Maybe one day I'll be > > able to include that into laml-execute.el. > > > > Regards > > Thomas Hafner > > > > -- > > ___ http://hafner.sdf-eu.org/ ___ > > ___ mailto:thomas@ ______________ > > ____________ hafner.nl.eu.org ___ > > -- > Kurt Nørmark Phone: +45 9635 8080 > Department of Computer Science Direct phone: +45 9635 8896 > Aalborg University Fax: +45 9815 9889 > Fredrik Bajers Vej 7, Building E E-mail: normark(a)cs.auc.dk > DK-9220 Aalborg Ø WWW: http://www.cs.auc.dk/~normark/ > DENMARK Office: E4-208 > Regards Thomas -- Alter macht immer weiß, aber nicht immer weise. -- Sprichwort

1 1

define-macro question
by ben＠fuhok.net 31 Mar '05

31 Mar '05

Is it possible to use externally defined functions inside a macro definition? For example, one might want to use srfi-1 utilities to manipulate expressions as follows. (load "srfi-1") (define-macro (silly vars . body) (let ((vals (iota (length vars)))) `(let ,(zip vars vals) ,@body))) (silly (foo bar baz) (pp bar)) which should expand to (let ((foo 0) (bar 1) (baz 2)) (pp foo)) This doesn't work because macro expansion happens before srfi-1 is loaded. Bummer. I imagine that one will be able to do this in the next release (it causes a segfault right now), but is there a better way? (define-macro (silly vars . body) (include "srfi-1.scm") (let ((vals (iota (length vars)))) `(let ,(zip vars vals) ,@body))) Regards, Ben

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Gambit-list Avril 2005