Gambit-list Mars 2013

gambit-list@iro.umontreal.ca

21 participants
30 discussions

Minor tweak to main wiki page
by Mikael 12 Mar '13

12 Mar '13

http://dynamo.iro.umontreal.ca/wiki/index.php/Main_Page minor tweak, hope it cheered it up a bit - Gambit is really positive so the introduction deserves to reflect that directly :-) brgds Was: Gambit-C is a version of the Gambit programming system in which the compiler generates portable C code. The main features of Gambit-C are: - *Conformance.* The Gambit-C system conforms to the R4RS, R5RS and IEEE Scheme standards and implements all optional features. Tail calls and first class continuations conform to the Scheme semantics. The full numeric tower is implemented, including: arbitrary precision integers (bignums), rationals, inexact reals (floating point numbers), and complex numbers. Several extensions to Scheme are provided, including: lightweight threads, a foreign-function interface (FFI), and extended I/O capabilities (Unicode, networking, subprocesses, ...). - *Portability.* Because the system is mostly written in Scheme and the compiler generates portable C code, it is easy to port the system as well as programs compiled with it to any platform with a decent C or C++ compiler. There is no reliance on a particular C compiler, although the system can take advantage of some *gcc*-specific constructs. The C code generated is oblivious to the endianness and word size of the target environment (32 and 64 bit architectures are currently supported). - *Performance.* The compiler includes several powerful program transformations such as user procedure inlining, partial-evaluation, and lambda-lifting. With appropriate declarations in the source code the executable programs generated by the compiler run roughly as fast as equivalent C programs. Programs containing no declarations are also optimized without compromising the Scheme semantics by speculatively inlining predefined procedures (see the benchmarks<http://dynamo.iro.umontreal.ca/wiki/index.php/Benchmarks> page for a comparison with other Scheme implementations and other languages). Thanks to an efficient implementation of continuations, the thread system is very efficient and can support millions of concurrent threads. The bignum library uses sophisticated algorithms that are in some cases asymptotically faster than those of GMP (GNU Multiple Precision Arithmetic Library). [Note: With the release of GMP 4.3.0 in April 2009, this claim is no longer true; see the benchmarks<http://dynamo.iro.umontreal.ca/wiki/index.php/Benchmarks> page for some crude comparisons on large integers.] ( <- removed ) - *Reliability.* Stable releases typically have very few bugs. Bug tracking is done with bugzilla <http://www.bugzilla.org/>. Gambit-C has been used to develop large-scale real-world software and services<http://dynamo.iro.umontreal.ca/wiki/index.php/Real-world_software_and_servi…> in academic and commercial settings. => Now: Gambit-C is a version of the Gambit programming system in which the compiler generates portable C code. The main features of Gambit-C are: - *Conformance.* The Gambit-C system conforms to the R4RS, R5RS and IEEE Scheme standards and implements all optional features. Tail calls and first class continuations conform to the Scheme semantics. The full numeric tower is implemented, including: arbitrary precision integers (bignums), rationals, inexact reals (floating point numbers), and complex numbers. Several extensions to Scheme are provided, including: lightweight threads, a foreign-function interface (FFI), and extended I/O capabilities (Unicode, networking, subprocesses, ...). - *Portability.* Because the system is mostly written in Scheme and the compiler generates portable C code, it is easy to port the system as well as programs compiled with it to any platform with a decent C or C++ compiler. There is no reliance on a particular C compiler, although the system can take advantage of some *gcc*-specific constructs. The C code generated is oblivious to the endianness and word size of the target environment (32 and 64 bit architectures are currently supported). There are no external library dependencies, and OS API dependencies can be removed so as to run directly on the bare metal. The system includes high-performance bignum support utilizing sophisticated algorithms, implemented in Scheme. ( <- added ) - *Performance.* The compiler includes several powerful program transformations such as user procedure inlining, partial-evaluation, and lambda-lifting. With appropriate declarations in the source code the executable programs generated by the compiler run roughly as fast as equivalent C programs. Programs containing no declarations are also optimized without compromising the Scheme semantics by speculatively inlining predefined procedures (see the benchmarks<http://dynamo.iro.umontreal.ca/wiki/index.php/Benchmarks> page for a comparison with other Scheme implementations and other languages). Thanks to an efficient implementation of continuations, the thread system is very efficient and can support millions of concurrent threads. - *Reliability.* Stable releases typically have very few bugs. Bug tracking is done with bugzilla <http://www.bugzilla.org/>. Gambit-C has been used to develop large-scale real-world software and services<http://dynamo.iro.umontreal.ca/wiki/index.php/Real-world_software_and_servi…> in academic and commercial settings.

2 1

Bugzilla down?
by Mikael 12 Mar '13

12 Mar '13

http://www.iro.umontreal.ca/~gambit/bugzilla/ Software error: Can't connect to the database. Error: Access denied for user 'gambit'@'webby.iro.umontreal.ca' (using password: YES) Is your database installed and up and running? Do you have the correct username and password selected in localconfig? For help, please send mail to the webmaster, giving this error message and the time and date of the error.

2 1

Gambit and Thread safity
by tcl super dude 12 Mar '13

12 Mar '13

Hi, I am trying to develop a gambit-c image processing app on android. My approach is to develop all the GUI related code in java and all image processing code in scheme. So far, I tested my scheme code on the PC and I am about to migrate it to android. I use a remote repl to develop on android. The java class run as an Android Service so it is not directly connected to an Activity (GUI). This way I can still send code while using different windows (Activities). There are 2 threads on the Service. Thread1 - java Thread2 - gambit (using a heartbeat to resume gambit threads) from the remote repl side everything is fine, coz I am talking only with gambit using TCP. Now I want Java to talk to gambit and back. I know JNI, but my concern is with thread safety. what I want: 1 - I want to call a gambit eval function from java so I can execute arbitrary scheme code from my service on the java side. 2 - I want to eval_scheme(String code) to not block the java thread 3 - I want it to be safe (I don't want the code to deadlock or crash) Let me explain what I have so far: 1 - I can eval any scheme code. I just wrote a c-define of eval plus some exception handling on scheme side. It works so far, and even show errors on LOGCAT (android error, debug and info log facility) 2 - eval_scheme does not block if I create a scheme thread and yield, so it will actually execute the scheme procedure on the next heartbeat (so eval_scheme returns immediately) 3 - I don't know if what I am doing is thread safe. I mean, when I can eval_scheme it uses a scheme procedure which I don't know if is safe. I mean, I am executing two peaces of gambit code in two different system threads here. (1) the gambit interpreter/repl on its own system thread, and (2) eval_scheme() on the java thread (the second system thread). is eval_scheme() thread safe? Can I execute it in two different system threads? (remember eval_scheme () is just scheme eval from the C/java/JNI side) Just before wrote this e-mail I was driving back home while thinking about a solution in case what I am coding is the wrong approach. I though I could code eval_scheme to change an attribute of the Java Service class, a String for example(or maybe a list of those), and that string to be the code gambit has to execute next. In the gambit side I would have a scheme thread checking this string once in while (every 200ms for example) and of course making sure that gambit system thread is the only one accessing the java string (MonitorEnter/MonitorExit JNI functions) and then execute the code if the string is not null, and set the string to null after reading it and before executing the scheme code (which could take a while). This way I would not need to execute a gambit procedure from the java thread. I'd like to know what you guys thing about the second approach to the problem too. thx.

1 0

Re: [gambit-list] Your feedback would be much appreciated re: Proposal for enabling IO errors to be reported through returning of a custom value instead of by throwing exception, through DSL with exports: ##io-error-behavior param, ##default-io-error-behavior unique value, ##last-io-error param.
by Mikael 10 Mar '13

10 Mar '13

Hi Dimitris, Thank you for your response. Feel most free to send it to the Gambit ML too, as to encourage further conversation on this topic. The IO performance can be boosted to really good performance by doing it via read/write-subu8vector only, but that has huge system-level limitations so even though for almost-all applications that can solve it, in the big picture it's not a solution. Re boosting byte-level access speeds, I remember I think Marc making a ML post where he inlined read-char's or read-u8's code in the user code and got much higher performance that way. That saves of the trampoline call at least... It should be easy to repeat that experiment as to check out how it affects performance. Condition variables... Hmm. Do you have any clue at what granularity they work? Brgds :) Mikael 2013/3/10 Dimitris Vyzovitis <vyzo(a)hackzen.org> > +1 > > If I may add, point (f) should be a priority. i/o performance is > severely hampered by the constant mutex acquisitions. > At a first approximation, each individual write should stop writing > one character at a time (with a mutex lock each time). > Having full control of whether a mutex is used at all is even better, > as it is almost always the case that a single thread is > reading/writing a port (exceptions being the std ports). The problem > there is the way the i/o system i simplemented though, as the events > are tied to condition variables and these in turn tied to mutexes to > work reliably. > > PS: I owe you some coroutines :) > >

1 1

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

08 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 06 Mar '13

06 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 06 Mar '13

06 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

What about including in Gambit a builtin procedure for getting a port's OS file descriptor (to get TCP port's socket descriptor etc.)? Incl patch draft.
by Mikael 06 Mar '13

06 Mar '13

Dear Marc and list, ( There are times when extracting the file descriptor for instance from a Gambit TCP port is extremely useful. One example of this would be when using OpenSSL, where OpenSSL reads and writes directly to and from the socket, thus saving us from a round of buffering and thereby increasing performance. There ought to be loads and loads of other C libraries where this is of great use also. Also, it ought to be useful for doing lowlevel configuration of fd:s and sockets using OS API:s, like turning on or off keepalives, etc. Gambit's IO system scales excellently for C code to do socket reads and writes, in the sense that Gambit not interferes with it with any background buffering or alike. Gambit can even 'multiplex' sockets managed in C thanks to that the user can make Gambit include selected Gambit TCP ports in its IO scheduler's select() calls, still without doing any reads or writes due to buffering, using the |##device-port-wait-for-input!| (and |##device-port-wait-for-output!|, currently in a pull request to the Gambit repo) procedures. Currently, extracting the socket FD requires a quite ugly hack that relies on the user code having access to os_io.h. This is ugly both considering that compiled Gambit distributions don't include os_io.h (by good reasons, as it's an internal file), considering that os_io.h may change and also #include does not have a reference to Gambit's installation directory so the hack would not be future-proof ever. Fd:s never change during the course of the lifetime of a Gambit port object, so this kind of use is clearly good design. ) What about adding support for Gambit port file descriptor retrieval by adding to Gambit a procedure (##os-device-get-fd port) => socket-fd-int ? Even if this is not like the 'recommended official way' of doing IO in Gambit, I think it's of great value that it is in the box, and again, it does work perfectly already, just that a ugly hack needs to be used to make it go around in this moment, and this would be completely remedied by the addition of such a procedure. As regards how to implement it, my current best understanding is this would be done by something like: * Adding to lib/_kernel.scm row 4124 (here bc. this is where all of Gambit's internal c-lambda:s are and C code is required to deliver this): (define-prim ##os-device-get-fd (c-lambda (scheme-object) scheme-object "___os_device_get_fd")) * Adding to lib/os_io.h row 680: extern ___SCMOBJ ___os_device_get_fd ___P((___SCMOBJ dev), ()); * Adding to lib/os_io.c row 7500 (possibly the 'logics' code in this procedure would be split out and put at row 1405 or so): ___SCMOBJ ___os_device_get_fd ___P((___SCMOBJ dev), (dev) ___SCMOBJ dev;) { ___device *d = ___CAST(___device*,___FIELD(dev,___FOREIGN_PTR)); switch ___device_kind(d) { case ___FILE_DEVICE_KIND: ___device_file *d = ___CAST(___device_file*,d); #ifdef USE_POSIX return d->fd; #elif USE_WIN32 return d->handle; #else return ___UNIMPL_ERR; #endif case ___TTY_DEVICE_KIND: ___device_tty *d = ___CAST(___device_tty*,d); return d->t; case ___SERIAL_DEVICE_KIND: ___device_serial *d = ___CAST(___device_serial*,d); return d->h; case ___TCP_CLIENT_DEVICE_KIND: ___device_tcp_client *d = ___CAST(___device_tcp_client*,d); return d->s; case ___TCP_SERVER_DEVICE_KIND: ___device_tcp_server *d = ___CAST(___device_tcp_server*,d); return d->s; else: return ___FAL; } } I did not try to compile the code above, though I believe it would compile and work with only minor modifications. The returned value currently is not converted to a Scheme object so will cause Gambit to crash. I did not add ___FIX() here as the returned value could just be bigger than ___FIX_MAX . Is there any straightforward way to do unsigned int (or ___U64) to ___SCMOBJconversion? I don't find ___UINT_to_SCMOBJ's (or ___U64_to_SCMOBJ's) definition anywhere. Thoughts? Best regards, Mikael

1 0

___FETCH_F32 and ___FETCH_F64?
by Mikael 06 Mar '13

06 Mar '13

Dear Marc, There's ___FETCH_(S|U)(64|32|16|8) but no ___FETCH_F32 and ___FETCH_F64. Currently those need to be defined separately by the user something like #define ___FETCH_F32(x) &___F32VECTORREF(X,0) #define ___FETCH_F64(x) &___F64VECTORREF(X,0) The ability to fetch F32 and F64-vectors is useful when passing a float or double array to some C library, for instance for math or 3D. Is there any particular reason for why they were not bundled til now? What about including them, if not else then for completeness? Thanks, Mikael

2 1

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Gambit-list Mars 2013