Gambit-list Février 2011

gambit-list@iro.umontreal.ca

19 participants
17 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

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

20 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

compiling fib
by Bradley Lucier 29 Mai '11

29 Mai '11

Marc: I don't know why, but I got looking at the compiled code for fib, and it seems to use much more stack space than needed, 8 words per invocation, which seems counter-intuitive to me; is there a problem with the compiler? I'm using the latest git compiler. Brad I started with (declare (standard-bindings) (extended-bindings) (block) (not safe)) (define (fib n) (if (or (fx= n 0) (fx= n 1)) n (fx+ (fib (fx- n 1)) (fib (fx- n 2))))) and got #undef ___PH_PROC #define ___PH_PROC ___H_fib #undef ___PH_LBL0 #define ___PH_LBL0 3 #undef ___PD_ALL #define ___PD_ALL ___D_FP ___D_R0 ___D_R1 #undef ___PR_ALL #define ___PR_ALL ___R_FP ___R_R0 ___R_R1 #undef ___PW_ALL #define ___PW_ALL ___W_FP ___W_R0 ___W_R1 ___BEGIN_P_COD ___BEGIN_P_HLBL ___DEF_P_HLBL_INTRO ___DEF_P_HLBL(___L0_fib) ___DEF_P_HLBL(___L1_fib) ___DEF_P_HLBL(___L2_fib) ___DEF_P_HLBL(___L3_fib) ___DEF_P_HLBL(___L4_fib) ___END_P_HLBL ___BEGIN_P_SW ___DEF_SLBL(0,___L0_fib) ___IF_NARGS_EQ(1,___NOTHING) ___WRONG_NARGS(0,1,0,0) ___DEF_GLBL(___L_fib) ___IF(___FIXEQ(___R1,___FIX(0L))) ___GOTO(___L7_fib) ___END_IF ___GOTO(___L6_fib) ___DEF_GLBL(___L5_fib) ___SET_STK(1,___R0) ___SET_STK(2,___R1) ___SET_R1(___FIXSUB(___R1,___FIX(1L))) ___SET_R0(___LBL(2)) ___ADJFP(8) ___POLL(1) ___DEF_SLBL(1,___L1_fib) ___IF(___FIXEQ(___R1,___FIX(0L))) ___GOTO(___L7_fib) ___END_IF ___DEF_GLBL(___L6_fib) ___IF(___NOT(___FIXEQ(___R1,___FIX(1L)))) ___GOTO(___L5_fib) ___END_IF ___DEF_GLBL(___L7_fib) ___JUMPPRM(___NOTHING,___R0) ___DEF_SLBL(2,___L2_fib) ___SET_STK(-5,___R1) ___SET_R1(___FIXSUB(___STK(-6),___FIX(2L))) ___SET_R0(___LBL(3)) ___IF(___FIXEQ(___R1,___FIX(0L))) ___GOTO(___L7_fib) ___END_IF ___GOTO(___L6_fib) ___DEF_SLBL(3,___L3_fib) ___SET_R1(___FIXADD(___STK(-5),___R1)) ___POLL(4) ___DEF_SLBL(4,___L4_fib) ___ADJFP(-8) ___JUMPPRM(___NOTHING,___STK(1)) ___END_P_SW ___END_P_COD

8 30

cmake for projects written in gambit?
by Matthew Koichi Grimes 06 Avr '11

06 Avr '11

Has anybody used CMake as a build system for their Gambit projects? I'm not talking about building Gambit itself, but rather building projects that are written in Gambit. If so, could I see your CMakeList bulid files? I would also be interested in other build systems' makefiles (make, ant, etc), if people are wiling to share, or point me to an open-source project written in Gambit that I could download. Best, -- Matt

2 4

Re: [gambit-list] Gambit and oximeter
by Petersen, Chris 24 Fév '11

24 Fév '11

Yes, the phone oximeter is written in Gambit-C, with an OpenGL based user interface and some minimal platform specific glue. The app is meant to be a low cost alternative to expensive standalone monitors.. it's a fairly complete implementation, with real-time plethysmogram, oxygen saturation and heart rate trends, saturation pitched heart beat sound and alarms (audible and visual). Gambit-C is really great as a rapid prototyping environment (thanks Marc!), it's robust and extremely portable. The framework used for the oximeter app builds on iOS, Android, OS X, Windows, OpenBSD, NetBSD and Linux. Chris On 2011-02-17, at 8:08 PM, Bradley Lucier wrote: > A user named Chrisp added a line to the "Real-world software and > services" wiki page that seems to imply that the "PhoneOximeter", > > http://phoneoximeter.org/ > > an iPhone app to measure real-time oxygen levels being developed at the > University of British Columbia, is written in Gambit-C. > > I googled "Gambit" on phoneoximeter.org but found nothing that would > confirm this. If it's true, I find it quite exciting. My question is: > Is my interpretation of this wiki change correct? > > Brad Yes that's cool! I couldn't find any other information myself. Perhaps a query on the Gambit list will ring in some more details... Marc

4 7

Namespaces
by nitralime 23 Fév '11

23 Fév '11

Hi folks! Where can I find some documentations about Namespaces in Gambit? The section 7 in manual says: 7. Namespaces TO DO! Regards Nik

4 3

compiling with define-syntax
by Evan Hanson 22 Fév '11

22 Fév '11

Hey all, I'm running into problems compiling files with define-syntax forms. The errors (generally "Operator is not a procedure" and similar) are occuring in macros that work from the interpreter with `gsi -:s` but they're failing with `gsc -:s -link` I'm just wondering if this is possible before I sink anymore time into it. Thanks, Evan

2 2

I think I found a bug on Gambit-C's build process during building for iOS.
by Eonil 20 Fév '11

20 Fév '11

Hi. I'm Hoon Hwangbo, and currently trying to build Gambit-C for Apple's iOS platforms. I think I found a bug on Gambit-C's build process. Please reply your opinions. I started with cross-compiling whole source code with iOS SDK. I followed 'jlongster''s method described on: http://jlongster.com/legacy/scheme-iphone-apps.html I had succeed building for iOS device. `libgambc.a` linked and executed well. But I met some errors during building for iOS simulator. (iOS has 2 kind of platforms, I'll describe about this later section) This is first error. os_io.c: In function ‘___device_stream_kind_from_fd’: os_io.c:5835: error: storage size of ‘s’ isn’t known make[1]: *** [os_io.o] Error 1 make: *** [all-recursive] Error 1 The line at source code is, struct ___stat s; `___stat` is typedef-ed as `stat`. I don't know why, however, it couldn't be compiled. I just modified the code uing `stat` type directly. struct stat s; Compilation continued. And another error pop up. os.c: In function ‘___os_file_info’: os.c:1488: error: storage size of ‘s’ isn’t known make[1]: *** [os.o] Error 1 make: *** [all-recursive] Error 1 Exactly same error and exactly same source code. I modified it as same as above. Compilation continued. Build complete without additional error. It's linked but failed to be executed. It raised a runtime error: Detected an attempt to call a symbol in system libraries that is not present on the iPhone: fstat64 called from function ___device_stream_setup_from_fd in image gambit-c-test3. If you are encountering this problem running a simulator binary within gdb, make sure you 'set start-with-shell off' first. Program received signal: “SIGABRT”. I felt there is an error about determining environment is 32-bit or 64-bit. Because iOS simulator is completely 32bit environment. I rollbacked all changes. I searched `fstat64` from all source code, and I found it's on 'include/configure.h'. It's marked like this. #define HAVE_STAT64 1 I changed it like this. #define HAVE_STAT64 0 Compilation failed again exactly same with first 2 errors. I didn't modified the code like before. Instead of, I looked at 'os.h'. There was a code block. #ifdef HAVE_STAT64 #define USE_stat #define ___stat stat64 #define ___lstat lstat64 #define ___fstat fstat64 #else #ifdef HAVE_STAT #define USE_stat #define ___stat stat #define ___lstat lstat #define ___fstat fstat #endif #endif I modified it like this to force using only 32-bit functions. /* #ifdef HAVE_STAT64 #define USE_stat #define ___stat stat64 #define ___lstat lstat64 #define ___fstat fstat64 #else #ifdef HAVE_STAT */ #define USE_stat #define ___stat stat #define ___lstat lstat #define ___fstat fstat /* #endif #endif */ And finally… It worked! Compiled well, linked well, executed well! I don't know why it was configured using 64-bit functions. Maybe the bug in the tool-chain, but it should be evaded to support iOS. It's working now, but I can't sure my modification is correct. Maybe it's not correct. My modification destructs #ifdef logic. I didn't analyze all the logic. There were test codes, but I don't know how to execute the test. (Can you let me know how to execute the test...?) I'm not good at low-level system programming. I'm just a programmer who want to embed nice scripting system with functional language into my app. I'm newbie on `make` tool-chain and complete newbie on Scheme :) I wish this errors to be corrected. Maybe building for iOS is not so important, this errors may a sign of another bug. Please review the codes at the positions. PS. My environment: - Mac OS X 10.6 Snow Leopard - iOS SDK 4.2 - Gambit-C 4.6 source code of version iOS platform description. ====================== There are 2 kind of iOS platform. - iOS Device. This is real hardware platform composed of ARM(32bit)+darwin(32bit) - iOS Simulator. This is simulated platform on Mac OS X. Composed of x86(32bit)+darwin(32bit) This is not a full emulator. It's behaves a little differently with iOS Device platform. So, Apple offers SDK with 2 versions of development tool-chains. Each version contains modified version of GCC for each platform. CONTACT + Hwangbo Hoon + iPhone: +82 10 4583 3612 + Twitter: http://twitter.com/#!/eonilc + Blog: http://blog.eonil.com/ (Korean)

1 1

Gambit and oximeter
by Bradley Lucier 17 Fév '11

17 Fév '11

A user named Chrisp added a line to the "Real-world software and services" wiki page that seems to imply that the "PhoneOximeter", http://phoneoximeter.org/ an iPhone app to measure real-time oxygen levels being developed at the University of British Columbia, is written in Gambit-C. I googled "Gambit" on phoneoximeter.org but found nothing that would confirm this. If it's true, I find it quite exciting. My question is: Is my interpretation of this wiki change correct? Brad

2 1

embedding CUDA-C (for nVIDIA GPU usage) in Gambit?
by Jason E. Aten 14 Fév '11

14 Fév '11

Hi Gambit enthusiasts, I'm curious if anyone has played with generating CUDA kernels or CUDA from Gambit scheme code. I've learned some Lisp and some Scheme, but I'm still unclear how the "C embedding" in Gambit works. For example, if one needs to call nVidia's nvcc compiler to handle their dialect of C (CUDA-C == C with GPU extensions) instead of gcc (for example), will the Gambit compiler pass through the embedded C-with-extensions to the C compiler of choice? For that matter, the Thrust libraries bring an STL-like interface to creating and using CUDA kernels; is it possible to embed C++ code with templates directly into Gambit Scheme code? Happy to clarify if need be. Any advice or ideas (or experience) would be helpful. Thank you. Best regards, Jason -- Jason E. Aten, Ph.D.

3 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Gambit-list Février 2011