Février 2013 - Gambit-list - mailman.iro.umontreal.ca

Efficient Compilation of Tail Calls and Continuations to JavaScript
by Marc Feeley 18 Sep '13

18 Sep '13

Eric Thivierge is in Copenhagen today, at the Scheme Workshop, presenting our latest paper: "Efficient Compilation of Tail Calls and Continuations to JavaScript" You can get the paper on the Scheme Worshop web page: http://users-cs.au.dk/danvy/sfp12/programme-sfp12.html It describes the implementation of tail calls and continuations in Gambit-JS and evaluates its performance. Even if you are not specifically interested in the JavaScript back-end the paper may be interesting to read as it provides a brief explanation of the Gambit Virtual Machine (GVM) and compiler front-end, and a complete example of compilation from Scheme, to GVM, to JavaScript. The performance evaluation (see attached tables) shows that the approach used by Gambit-JS is consistently faster than Scheme2JS and Spock. Marc Execution times using V8 (Chrome 21.0.1180.89): Gambit-JS Scheme2JS Spock fib35 .80 1.54 1.9x 2.40 3.0x nqueens12 .72 .76 1.1x 2.33 3.3x oddeven .83 1.92 2.3x 5.62 6.8x ctak .18 17.64 95.9x .59 3.2x contfib30 1.17 106.01 90.9x 3.38 2.9x btsearch2000 1.35 25.40 18.8x 7.93 5.9x threads10 1.34 24.68 18.5x 4.40 3.3x Execution times using JagerMonkey (Firefox 15.0.1): Gambit-JS Scheme2JS Spock fib35 1.07 7.66 7.2x 20.73 19.4x nqueens12 1.49 2.62 1.8x 12.97 8.7x oddeven 1.09 1.93 1.8x 33.91 31.1x ctak 1.25 30.38 24.3x 1.86 1.5x contfib30 5.88 156.79 26.7x 10.61 1.8x btsearch2000 11.19 27.16 2.4x 16.54 1.5x threads10 6.97 34.36 4.9x 22.11 3.2x Execution times using Nitro (Safari 6.0): Gambit-JS Scheme2JS Spock fib35 1.32 6.53 4.9x 84.69 64.2x nqueens12 1.31 1.89 1.4x 45.15 34.4x oddeven 2.52 1.55 .6x 143.97 57.1x ctak .30 52.88 177.4x 4.18 14.0x contfib30 1.60 2311.69 1443.0x 25.98 16.2x btsearch2000 3.46 102.98 29.7x 92.02 26.6x threads10 3.03 74.21 24.5x 74.88 24.7x

4 10

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

Transforming top-level program code
by Jason Felice 13 Mar '13

13 Mar '13

I've had a couple ideas for modifications to the Scheme reader that I imagine would be front-ends to the compiler. Examples: 1. A front end which reads Scheme source but specially handles square braces, transforming them into Objective-C method calls via my library, so that I can put the following in a program: (let ((s [[NSString alloc] initWithCapacity:42])) ...) And have it dispatch non-dynamically (my current project is completely dynamic). 2. A testing library where "check" forms appear under each function in the same file as documentation. The check forms normally expand to nothing, but a command can be run from the command line scans the current directory and sub-directories for .scm files which (check ...) forms in them and runs them. 3. A complete environment with support for a lot of SRFI's and utility functions built in - a new REPL/compiler which is specialized for some domain. Black hole appears to do something like this. My question is, how do I hook into Gambit to compile or interpret after I've transformed the code, preserving line numbers?

2 4

Problem with interactive development using remote REPL of iOS Sim.
by Tatsuya Tsuda 09 Mar '13

09 Mar '13

Hi, I am a newbie of Gambit Scheme coming from Clojure. Currently I am trying to build an iOS app in Gambit. I have successfully done the following: 1. Built 4.6.6-devel git version (snapshot of two weeks ago) of Gambit using llvm-gcc 2. Built Gambit REPL using iOS SDK 6.1 by using both clang and llvm-gcc from Xcode. 3. Minimized the remote REPL part of Gambit REPL and created a simple app 3.1. Created a scheme file, init.scm, to register and change the text of the UILabel. ;; The whole init.scm (declare (standard-bindings) (extended-bindings) (block) (fixnum) ;(not safe) ) (c-define-type UILabel* (pointer "UILabel")) (c-declare "#import <UIKit/UIKit.h>") (define current-label #f) (c-define (register-label label) (UILabel*) void "register_label" "" (set! current-label label)) (define change-label-text (c-lambda ((pointer "UILabel")) void #<<c-code ___arg1.text = @"Text changed."; c-code )) 3.2. In Xcode, I defined a viewDidLoad method as below, which prints "Hello Wolrd" and then passes the label to the scheme function register_label(). // Part of VIewController.m - (void)viewDidLoad { [super viewDidLoad]; // Do any additional setup after loading the view, typically from a nib. _label = [[UILabel alloc] init]; _label.text = @"Hello World"; [_label setLineBreakMode:UILineBreakModeWordWrap]; [_label setNumberOfLines:0]; _label.frame = CGRectMake(0, 225, 320, 30); _label.textAlignment = UITextAlignmentCenter; [self.view addSubview:_label]; _timer = nil; _queuedActions = [[NSMutableArray alloc] init]; gambit_setup(); register_label(_label); repl_server_start(); [self heartbeat_tick]; } So far, I have successfully built this simple app. I can connect to the remote REPL of iOS Simulator from the Emacs Inferior Lisp, and even able to change the text of the label dynamically by doing like (change-label-text current-label). Now it seems that I can develop iOS apps, but I want to go further with the interactive development using the REPL. What I want to do is like: 1. Redefine the change-label-text function by changing the text like "New text!" 2. Create a loadable library gsc -cc-options "-arch i386 -x objective-c -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk -D__IPHONE_OS_VERSION_MIN_REQUIRED=40300" -ld-options "-framework CoreFoundation -framework Foundation -framework UIKit" lib/init.scm 3. Do below in REPL (define old-label current-label) 4. Load the loadable library init.o1 from the REPL 5. Do below in REPL (change-label-text old-label) 6. Then an error in Xcode and the app terminates. 2013-02-27 17:38:31.305 gambit-test[61410:11303] *** NSForwarding: warning: selector (0x87a6f44) for message 'setText:' does not match selector known to Objective C runtime (0xabb96d)-- abort 2013-02-27 17:38:31.306 gambit-test[61410:11303] -[UILabel setText:]: unrecognized selector sent to instance 0x8284a50 2013-02-27 17:38:31.306 gambit-test[61410:11303] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[UILabel setText:]: unrecognized selector sent to instance 0x8284a50' *** First throw call stack: (0x21a4012 0x15e1e7e 0x222f4bd 0x2193bbc 0x219394e 0x87a6e07 0x44b0c0) libc++abi.dylib: terminate called throwing an exception I can create and load a loadable library with no errors. It seems that something is missing. Does anyone know how to solve this kind of problem? Thanks, Tatsuya Tsuda

7 20

Anything particular needed to compile on FreeBSD? 'make' on the compilation of the ~fourth file gives: error: 'openpty' was not declared in this scope
by Mikael 07 Mar '13

07 Mar '13

The compilation error is: error: 'openpty' was not declared in this scope This was tried on latest FreeBSD 9.0 AMD64 with the gcc46 package installed, i.e., pkg_add -r gcc46; CXX=/usr/local/bin/g++46 ./configure --enable-cplusplus --enable-single-host; make . I tried with both the source for 4.6.6 and 4.6.7 as found on the repo today. This entire prob made me think maybe there's some operating system headers file package or alike that I missed, though I would guess not as Gambit not has any dependencies apart from what's really core to a C compiler and standard OS and the configure step should have failed if there's any issues with those. Also, googling for it does not make me anywiser - apparently lots of people speak about crosscompat issues, which is unrelated to the question of it being defined at all, which this error seems to regard. Can anyone else reproduce this problem? Any clue what it might be / how to resolve it? Thanks, Mikael

3 2

Build tool, directory structure
by Jason Felice 07 Mar '13

07 Mar '13

I've been thinking about modularity problems (aside from actual module systems). One of the problems I have is that invoking gsc from a Makefile is pretty rough because of dependencies. I almost always end up with files not recompiling. I'm thinking of a simple build tool which takes a directory structure like so: bin/ lib/ test/ And just does the right thing. All the lib files compiled independently, with dependencies calculated, files which have a hash mark in them are skipped. The resulting files are linked against each program in bin/ and test/, and test programs are run. Just this much functionality would be a huge improvement for my workflow. Deisgn thoughts? -Jason

5 6

Fwd: Build tool, directory structure
by Jason Felice 01 Mar '13

01 Mar '13

Forgot to include the list. ---------- Forwarded message ---------- From: Jason Felice <jason.m.felice(a)gmail.com> Date: Thu, Feb 28, 2013 at 2:57 PM Subject: Re: [gambit-list] Build tool, directory structure To: Marc Feeley <feeley(a)iro.umontreal.ca> Here's a historic one which I know would often run tests with stale code. https://github.com/maitria/gambit-objc/blob/273de0a8e66ce9c0ef40afc0bbdf0b3… I would occasionally have to clean everything to get it to rebuild the code under test. I never figured out why. I had another pretty similar setup that ended up working the same way which I can't find right now. One thing to note is that when I build the sources separately, I avoid compiling to object files because I can't predict the name in the Makefile. -Jason On Thu, Feb 28, 2013 at 1:30 PM, Marc Feeley <feeley(a)iro.umontreal.ca>wrote: > > On 2013-02-28, at 11:03 AM, Jason Felice <jason.m.felice(a)gmail.com> wrote: > > > I've been thinking about modularity problems (aside from actual module > systems). One of the problems I have is that invoking gsc from a Makefile > is pretty rough because of dependencies. I almost always end up with files > not recompiling. > > Before suggesting a better design I would like to understand this problem. > Can you give an example, or your current makefile, error logs, etc? > > Marc > >

1 1

Gauche Devlog - Land of Lisp on Gauche
by Bradley Lucier 27 Fév '13

27 Fév '13

http://blog.practical-scheme.net/gauche/20130223-land-of-lisp I thought this blog entry might be of interest to some of us here on the Gambit list. Brad

1 0

Gambit wiki down
by Marc Feeley 26 Fév '13

26 Fév '13

For your information the Gambit wiki was down this weekend due to a power outage. It had nothing to do with the recent hard disk crash. The wiki is back online now. Marc

1 0

C stack frames need to be returned in exactly the same order they were created Re: FFI and threads: abrupt exit 71
by Mikael 25 Fév '13

25 Fév '13

Dimitris, (From only looking very generally at your code,) May this be a stack unwinding problem? If you unwind a stack other than in the same order it was wound in the first place, your Gambit process will terminate or at least crash. Example: You have a lambda A that invokes C-lambda B that invokes lambda C. Also, a lambda D that invokes C-lambda E that invokes lambda F. If you invoke A and A invokes B and B invokes C, and then say, Gambit switches thread, and that Gambit thread invokes D which invokes E which invokes F, and then, say, Gambit switches thread again, and that Gambit thread returns from C to B. Then your Gambit process is toast. To handle this you can switch off Gambit's threading system when you're in B or E for the course of your C and F calls respectively. Note that switching off Gambit's threading system means that some or several of Gambit's built-in IO primitives would block forever. See the "How to work with external libraries" Wiki page for how to switch it off. Was this of help? Mikael 2013/2/23 Dimitris Vyzovitis <vyzo(a)hackzen.org> > I am running into an abrupt exit with error code 71 (OSError) when > multiple (scheme) threads are making ffi calls that upcall to scheme. > > A simplified scenario (see attached file) is as follows: > 2 or more threads make an ffi call. > The ffi call is a longer running procedure, that makes upcalls into > scheme procedures that do I/O. > This results in the program exiting abruptly with error code 71, and > no context information regarding the error (even when compiled and > running with full debugging). > > For an illustration of the problem, see the attached file. > > The following should print dots indefinitely, but instead quickly > terminates with 71. > > $ gsc exit71.scm > $ gsi -e "(begin (load \"exit71\") (main))" > ....<plenty of dots>.... $ echo $? > 71 > > This is with gambit-4.6.6, system is GNU/Linux x86-64. > > -- vyzo > > _______________________________________________ > Gambit-list mailing list > Gambit-list(a)iro.umontreal.ca > https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list > >

3 7