Gambit-list Octobre 2013

gambit-list@iro.umontreal.ca

19 participants
19 discussions

Another patch for naive-div
by Bradley Lucier 25 Oct '13

25 Oct '13

Marc: This patch estimates the size of the quotient much more carefully (at the bit level); it also starts the computation with the first possible nonzero mdigit of the quotient. So it's faster in the very important case of small (but still bignum) dividend and divisor. And it's much simpler to understand than the old code. Passes 32-bit and 64-bit "make check". I don't have a machine that I can configure with 32-bit adigits and 16-bit mdigits (i.e., no "long long"). Brad

2 3

More work on compiled syntax and modules
by Matt Hastie 23 Oct '13

23 Oct '13

Gambit people, After formerly providing a patch that provides rudimentary support for compiled syntax-case modules with Gambit scheme, I'd like to share some recent thoughts that have emerged since I first posted. It was not long after the patch was included in the head, when user Sven Hartrumpf reported that the change regressed compiler functionality on 9/21. Since that time, I have been examining ways to make compilation seamless, which I think means: 1. Compilation should regress, wherein one may use gsc -:s -o <output> -exe <file1> <file2> ... without seeing additional warnings, and correctly run the resultant output. This is true for all other forms of compilation, which include both incremental and flat linking. Anything that is 'standards compliant' should compile correctly with just -:s specified, and ultimately link correctly when presented with other -:s generated output. The syntax-case file should never need to be loaded or included for standards compliant mode, other than internally by Gambit via -:s. 2. Executables and their dependent libraries should not depend on $sc-put-cte, or inclusion/loading of any syntax-case code. syntax-case is an expander and is not needed as a dependency. 3. Flat link files that are loaded into the REPL need $sc-put-cte content present, to effect functionality that was enabled by the former patch. The syntactic environment needs extension as objects are loaded. In the meantime, I went looking in the Chez manual to better identify how it uses syntax-case. I found the definitions for the visit and revisit primitives useful. Dybvig states: "visit reads the named file, which must contain compiled object code compatible with the current machine type and version, and it runs those portions of the compiled object code that establish compile-time information or correspond to expressions identified as "visit" time by eval-when forms contained in the original source file." "revisit reads the named file, which must contain compiled object code compatible with the current machine type and version, and it runs those portions of the compiled object code that compute run-time values or correspond to expressions identified as "revisit" time by eval-when forms contained in the original source file." (from http://www.scheme.com/csug8/system.html) Thus, from a Gambit schemer's perspective: The visit function is that which can "generate" what we conventionally place in a compilable <file>#.scm file from a source of mixed syntax definitions and program. The revisit function provides the program content, with syntax definitions and module metadata stripped. When one examines psyntax73.ss, there are two comments provided on the definitions of build-visit-only and build-revisit-only, the two syntaxes that result in the creation of the respective residuals for visit and revisit: (define-syntax build-visit-only ; should mark the result as "visit only" for compile-file ; in implementations that support visit/revisit (syntax-rules () ((_ exp) exp))) (define-syntax build-revisit-only ; should mark the result as "revisit only" for compile-file, ; in implementations that support visit/revisit (syntax-rules () ((_ exp) exp))) Although it is clear to me that Gambit needs credible implementations for these, my most sophisticated patch to date involves writing two files at compile time, one that contains visit content, and another (the main expander output) that contains the revisit content. I believe that it is necessary to generate both of these files in a single pass, and the generate-id implementation ensures they are uniquely paired. I foresee the following immediate consequences of this implementation: 1. The generation of files, especially the scheme visit content, that were formerly not compiler outputs is undesirable behavior. 2. The c#expand-source is not capable of compiling a second scheme file as a side-effect of compilation. (... or is re-entrant in the general case?!) To proceed, one would have to wrap the compiler with a pre-processor to expand the visit content and perform separate compilations of both visit and revisit content. 3. In a current patch I'm working on without #2, to support symmetric syntax use between to compile units, one must duplicate source files in a compiler command line, just as needs to feed a worse-is-better UNIX ld implementation e.g. gsc -:s -c a b a The first listing of a generates the visit information for compile unit b, whereas the second listing of a provides a correct revisit of a with the visited definitions of b present. I suspect that it is thus necessary for a reasonable implementation of visit to transitively visit all dependencies until a graph of visits is closed, prior to compiling a revisit for a compilation unit. As an aside, all this dogma makes me very happy of the basic choice of Gambit's define-macro, namespaces, and <file>#.scm design. It certainly makes for a beautifully simple scheme implementation, and cuts a lot of needless complexity. Perhaps the original bundling of syntax-case by Marc was an excellent local optima, use of ##include to propagate standards compliant syntax, and use of continued ##namespace for module support. Moving forwards, with the inadequacies of the dual file implementation, I'd like to consider the possibility of building both visit and revisit information into a single object file. To effect this, I've studied the structure of the generated C, which has ripped by brain apart, and I've also looked at other possible mechanisms, like, for example injecting visit information into the linker info structure. I believe the practice of coupling visit + revisit content in a single object will simplify the compiled syntax-case experience for users, and also provide gsc contract continuance as described above, so that existing gambit codebases don't regress. In terms of Dybvig's comments above: How does the community best think "marking of visit/revisit" should occur so that full syntax-case integration can be achieved, assuming this is indeed a desirable goal! Kind regards, Matt Hastie.

4 7

Low prio feature request: GC:able symbols, perhaps via a separate configure option --enable-gc:able-symbols
by Mikael 22 Oct '13

22 Oct '13

Hi! For a lower prio than SMP feature request I wish to suggest GC:able symbols. This would be of use to enable processing of symbols from unsafe or otherwise unknown sources such as frequently is the case in SXML and many other more or less standardized formats. Currently in such use the Gambit process tends to be susceptible to heap overflow possibility/attacks unless there's additional complexity in the form of separate marshalling code that limits symbol import to a pre-specified set only. Very secondarily, an extreme variant of such "unsafe formats" would be some forms of untrusted or otherwise unknown code - for running any form of untrusted code in Gambit, symbols being GC:able would be a key enabler as they'd save the untrusted code handling mechanism of the need to implement symbols<->uninterned symbol conversion in a copying proxy on start and on any passing of values between trusted and untrusted code, and also save of any weird complexity such a proxy would impose on object reference equality, cyclical references support etc. I completely understand that probably the default non-GC:ing quality of symbols is extremely well motivated for minimalism or technical reasons, however wanted to suggest this due to the huge practical use and unifying quality this feature would bring, then as a separate configurable option I guess. If anyone has any thought on this topic feel free to share, Best regards, Mikael

4 6

Post: Compare the productivity of computer languages
by Junia Magellan 19 Oct '13

19 Oct '13

Dear list members, I am the main investigator of a group that is carrying out an experiment, which compares the productivity of computer languages. For instance, one may wish to see if a Python programmer is more productive than a Scheme programmer with the same ability. Here is the spoiler: The volunteers associated with the project were not able to run sqlite3 from Gambit. It seems that the bindings are old, or not well documented. I would appreciate a link to bindings that work out of the box, is the case of both Bigloo and Racket. We therefore need to put in place a measurement theory that provides for the programmer's ability. In this case one can be sure of an equal ability to that of a Scheme programmer. [The research group is working with the following languages: C, Java, C#, Common Lisp SBCL) and Scheme (Racket and Bigloo).] To measure a programmer's ability, the group uses the Rasch model. The same model is also used for measuring the ability of a computer language to increase a programmer's productivity. For the time being, the group is working with the above cited languages. If the reader is unfamiliar with measurement theory, she is invited to visit my page concerning the subject: strues.org/languages Although the page contains original ideas from members of the my research group, it should be noted that there are however mathematical patches borrowed from other researchers, such as Rasch. This lack of originality is in itself not a problem as the page has been constructed purely as an internal report. Of course, in the final paper, due credit will be given through appropriate citations. To everybody's surprise, Python has not shown itself as being the most productive language, while Scheme has, followed closely by sbcl. Python occupies a distant third place. The volunteers are using Racket and Bigloo to program in Scheme. The fact is that everybody found Gambit difficult to use to solve the kind of problems associated with the measurement items. Therefore, nobody is using Gambit. The first difficulty with Gambit is that it does not run out of the box in all hosting services. A member of the group tried to fix the issue by consulting this list, but was not successful. Finally, the problem was solved after consulting Manuel Serrano and a member of the Racket user list. So a volunteer has installed a simple Gambit powered page on Hostgator. We would like thank Manuel Serrano and André for helping us with this task. The other difficult concerns connections to an sql server, while Bigloo and Racket provide out of the box connections, Gambit requires installation of external libraries and bindings to sqlite3, for example, Twenty three volunteers tried to perform the installation and everybody failed. Does anybody on this list know where I can find sources of gsi with sqlite3? As I would like to generate gsi with sqlite3 included, as in Racket. By the way, I am insisting on adding Gambit to the Scheme compiler set used in the experiment, because Gambit has a nice optional infix syntax. I would like to check whether this alters my results. * Junia Magellan* Doutoranda em Inteligência Artificial - Engenharia Elétrica - UFU Mestre em Inteligência Artificial - Ciência da Computação - UFU Docente do IFTM - Campus Avançado Patrocínio Lattes: http://lattes.cnpq.br/3659680417351721

4 4

gsc gets a linker error with -exe
by Dan Wilckens 18 Oct '13

18 Oct '13

Hi, I have a scheme program I'm trying to compile with Gambit-C in MinGW/MSYS under Windows. If I do gsc -exe "filename" the c file is output and gcc compiles fine-until it gets an error in the linker stage:( after successfully compiling DansScheme1.o and DansScheme1_.o and attempting to link them) C:\...lib/libgambc.a(os_base.o):os_base.c:(.text+0x737):undefined reference to 'gai_strerrorA' If I just compile with gsc -c "filename" it puts out a .c file no problem. What should I be looking for? If you need more details let me know. This is version 4.7.0 using Windows Vista with the prebuilt binaries. Any help would be much appreciated.Thanks, Dan

4 4

Re: [gambit-list] 0Sl kernel team
by Dimitris Vyzovitis 18 Oct '13

18 Oct '13

fare, zooko, and vyzo booted the first prototype (yeah, we are all blackhats around here, get over it). feeley, mflatt, and eli +1. so who is that vyzo guy? Hia name is John von Neumann. You might have heard of his gp. So wgat happens next? In the beginning was the command line. But what has no beginning has no end. As I was telling zooko before we erased facebook back in S0pA day, over time the origin of the system becomes unknowable. -- 0l

1 0

Xcode 5
by Marc Feeley 04 Oct '13

04 Oct '13

On #gambit someone reported an issue when compiling Gambit on the newly released Xcode 5. When I try building Gambit with Xcode 5, with and without --enable-single-host, the system builds fine. Has anyone encountered issues compiling with Xcode 5? For your information, I also tried compiling Gambit with GNU gcc 4.8.0. With gcc the compilation and execution times are much better (with --enable-single-host a "make -j8" takes 20 seconds versus 400 seconds for Xcode 5, and the interpreter is about 2x faster). To install GNU gcc on OS X, just use the script misc/install-gnu-gcc-osx . I highly recommend it! Marc

4 8

Re: [gambit-list] Returning values from ##inline-host-code
by Alexander Shendi 02 Oct '13

02 Oct '13

Hi , I need to return values Form an "##inline-host-code" Form. Can I do this at all? See my attempt below. This is for node.JS. Many thanks in advance for your help. Alexander Alexander Shendi <Alexander.Shendi(a)web.de> schrieb: >Dear list, > >how do I return values from a "##inline-host-code" form? > >Here is my attempt, but it doesn't seem to work ... > >(define (command-line) > (vector->list > (##inline-host-code "var vect = new Gambit_vector(); > for(i=0; i < process.argv.length; i++) { > vect.a[i] = process.argv[i]; > } > Gambit_r1 = vect; > "))) > >Many thanks in advance, > >Alexander > > > > >_______________________________________________ >Gambit-list mailing list >Gambit-list(a)iro.umontreal.ca >https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list

2 2

Patch to speed bignum division in common case
by Bradley Lucier 01 Oct '13

01 Oct '13

Marc: Please find enclosed a patch that speeds bignum division in the common case where (quotient a b) is a relatively small integer. Please apply this patch even though it's not a git fetch request. It's been going around in my head for a long time now, and I'd like to get rid of it before I learn about git. In pidigit.scm, a spigot algorithm for calculating the digits of pi, all (or almost all, I haven't checked) of the quotients return a single decimal digit. So this new code improves this performance of this benchmark a bit: To calculate 10,000 decimal digits of pi: Before the patch: firefly:~/programs/gambit/4.6.8/gambit> time ./pidigits2-gambit > /dev/null 5.560u 0.052s 0:05.63 99.6% 0+0k 0+0io 0pf+0w firefly:~/programs/gambit/4.6.8/gambit> time ./pidigits2-gambit > /dev/null 5.564u 0.044s 0:05.62 99.6% 0+0k 0+0io 0pf+0w firefly:~/programs/gambit/4.6.8/gambit> time ./pidigits2-gambit > /dev/null 5.588u 0.048s 0:05.65 99.4% 0+0k 0+0io 0pf+0w After the patch: firefly:~/programs/gambit/4.6.8/gambit> time ./pidigits2-gambit > /dev/null 4.684u 0.024s 0:04.72 99.5% 0+0k 0+0io 0pf+0w firefly:~/programs/gambit/4.6.8/gambit> time ./pidigits2-gambit > /dev/null 4.676u 0.040s 0:04.73 99.5% 0+0k 0+0io 0pf+0w firefly:~/programs/gambit/4.6.8/gambit> time ./pidigits2-gambit > /dev/null 4.648u 0.032s 0:04.69 99.5% 0+0k 0+0io 0pf+0w The code may also improve the performance of (very) bignum gcd, but I haven't checked that. Thoroughly "white box" and "black box" tested. The code includes better bignum shift code that I plan to use later in other places. Brad

2 11

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Gambit-list Octobre 2013