Août 2011 - Gambit-list - mailman.iro.umontreal.ca

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

05 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

How to pass a u8vector to the FFI
by Mikael 21 Sep '11

21 Sep '11

You do this, by declaring the passed u8vector as a scheme-object in the c-lambda definition. The memory pointer to the u8vector's contents in the C code is resolved by void *u8vectorptr = ___CAST(void*,&___FETCH_U8(___BODY(theu8vectorschemeobjectvariable),___INT(0))); Remember that the pointer is only to be kept until the next return to Scheme. Mikael 2010/3/30 Álvaro Castro-Castilla <alvaro.castro.castilla(a)gmail.com> > Hi! > > Is there a way to pass a u8-vector to a FFI interface somehow? > The way I expect this to work is through a (pointer unsigned-char), but it > obviously doesn't work, claiming a proper C pointer. I would like to be able > to build this arrays from Scheme code. Is there a way? > > Currently I have to call a FFI function to set char by char, calling the > c-lambda function too many times. > > One thing that could work is something that converts u8-vectors to unsigned > char* arrays, does that exist in Gambit? > > > Thanks, > > Álvaro > > _______________________________________________ > Gambit-list mailing list > Gambit-list(a)iro.umontreal.ca > https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list > >

6 10

Two small changes to _num.scm
by Bradley Lucier 11 Sep '11

11 Sep '11

These changes tweak acos (special-casing (acos 1) => 0 (all exact)) and complex division (using the naive algorithm in fewer cases). Brad

5 13

Re: [gambit-list] [racket] Racketizing Chrome
by Marc Feeley 31 Aoû '11

31 Aoû '11

I can help out Gambetizing Chrome. Just send me an email. Marc On 2011-08-31, at 8:51 AM, Hendrik Boom wrote: > On Tue, Aug 30, 2011 at 08:30:54PM -0400, Ray Racine wrote: >> Chrome has solidified their native app capability. Downside, only support >> is native apps in C or C++. Racket scheme is embeddable in a C program, >> hence, the theoretical possibility of Racket embedded within Chrome. As >> native apps are just another app loadable from the Chrome Web Store, Racket >> in Chrome is just another app install like any other app. In fact a >> particular Web App in the store could be a combination of the Racket native >> app with zos. > > If your aim isn't specifically Racket, but just to get Scheme in Chrome, > you might want to consider Gambit, a Scheme implementation that compiles > to C: http://dynamo.iro.umontreal.ca/~gambit/wiki/index.php/Main_Page

1 0

Debian seems to be way behind
by Hendrik Boom 31 Aoû '11

31 Aoû '11

I see the current version of gambit-s is 4.6.1. Is there some reason why the Debian package for gambit (gambc) is stuck at 4.2.8-1.1? It there some technical or Debian-political reason, or is it just a matter of inertia? -- hendrik

2 1

Can #. or equivalent be made available when compiling files?
by Matt Lamari 29 Aoû '11

29 Aoû '11

I want to know if #. or something equivalent is available when compiling .scm files. That is, the ability to tell the reader to directly eval a form at read time. I've been shown this: http://dynamo.iro.umontreal.ca/~gambit/wiki/index.php?title=Documentation:P… But am not sure how this should be applied to reading compiled code, if it's applicable, if it's possible. If this code or something like it should be used to influence the reader, where should it go? What's the best way to get the ability to have #. in the middle of compiled .scm? Thanks, Matt

3 4

Gambit REPL being removed from App Store
by Marc Feeley 27 Aoû '11

27 Aoû '11

It seems that Apple will be removing Gambit REPL from the App Store. Apparently it is in violation of the developer agreement. I'll have the details later. For now, if you don't yet have Gambit REPL, this might be a good time to download it from the App Store. Marc

6 5

Strangeness with sprintf
by Vladimir Darmanian 27 Aoû '11

27 Aoû '11

Hello list. Came across some weird behaviour when attempting a simple openssl ffi which I cannot reproduce in C alone. Attached is the scheme code and the (more or less) equivalent C code. The output of the scheme code is as follows: 81b637d8fcd2c6da6359e6963113a1170de795e4b725b84d1e0b4cfd9ec58ce9 81b637d8fcd2c6da6359e6963113a1170de795e4b725b84d1e0b4cfd9ec58ce9 8131333133333331333333333333333133333333333333333333333333333331 8131333133333331333333333333333133333333333333333333333333333331 The first line is the correct sha256 hash of the string "bob" from the sha256-final form. The second line is what should be (and is) the correct hash based on the byte array returned from sha256-final. The third line is the erroneous hash as a result of storing the hash string using sprintf using the same byte array as before. The final line is printing the resulting hash string from within scheme which should be the same as the third line (which it is and so is 'correctly' erroneous :). The first problem/question is: why is sprintf screwing up? And why does it only screw up in bytes->string and not in sha256_final? The second problem occurs when you swap the order of the two loops in bytes->string after which the output is: 81b637d8fcd2c6da6359e6963113a1170de795e4b725b84d1e0b4cfd9ec58ce9 3831333133333331333333333333333133333333333333333333333333333331 8131333133333331333333333333333133333333333333333333333333333331 8131333133333331333333333333333133333333333333333333333333333331 Why the hell is the second line now completely screwed up? Interesting to note that the first hex value (81) is correct in the erroneous (sprintf) strings, yet after swapping the two loops around the first hex value (now 38) is different even though the rest of the erroneous hash string is the same. Please release me from this madness. PS: remember to pass "-lcrypto" when compiling.

1 0

REPL, values and '#'
by Adrien Piérard 23 Aoû '11

23 Aoû '11

Hello, Given that '#' is supposed to be a placeholder for the latest returned value, I'd expect > (values 1 2) 1 2 > # 1 2 instead of > (values 1 2) 1 2 > # 2 Or at least, the returned value to be the first one of multiple values, not the last. I think that it's not common to use # and values together in the REPL, but I find the above behaviour not very natural. Cheers, P! -- Français, English, 日本語, 한국어

3 4

Help with creating executable.
by Vijay Mathew 20 Aoû '11

20 Aoû '11

Hi, I am trying to generate an executable from a Scheme file: ;; hello.ss (display "hello world") (newline) On Ubuntu Linux (11.4, 32bit) with Gambit v4.2, I tried the following command: $ gsc -o hello -exe hello.ss It failed with a warning "misplaced option -exe". On Windows 7 (64bit) with Gambit v4.6.1, I get the following error: $ gsc -o hello.exe -exe hello.ss Access is denied. Access is denied. Access is denied. *** ERROR IN ##for-each -- No such file or directory (delete-file "C:\\Users\\VMathew\\Desktop\\hello.o") On both machines the gcc compiler is installed and is working properly. I am following the directions at http://www.iro.umontreal.ca/~gambit/doc/gambit-c.html#GSC What could be going wrong? Thanks, --Vijay

3 6