Gambit-list Juin 2012

gambit-list@iro.umontreal.ca

19 participants
19 discussions

Puzzlement (different behavior of compiled code)
by David Rush 10 Jui '12

10 Jui '12

With Gambit 4.6.6, I am seeing decidedly different behavior for open-output-file between code compiled with gsc/gcc to run as a standalone executable and that same code compiled with gsc to run under gsi. The source code follows the body of the message, but the error from the standalone run tells the whole story, really. Specifically: ---------------------------------------------------------------------- drr@dibbuk$ make target=gambit test/bug.gambit gsc -:s -link test/bug.Gambit gcc -I/home/drr/include test/bug.c test/bug_.c -o test/bug.gambit \ -L/home/drr/lib -lgambc -lm -lutil -ldl drr@dibbuk$ test/bug.gambit *** ERROR IN flog-file -- (Argument 1) STRING or port settings expected (open-output-file '(|path:| "test.flog" |create:| maybe |append:| #t)) drr@dibbuk$ gsc test/bug.Gambit drr@dibbuk$ gsi Gambit v4.6.6 > (load "test/bug") "/home/drr/git/heureka/framework/test/bug.o2" > (main (vector "this is a test")) > (exit) drr@dibbuk$ cat test.flog this is a test this is a test ------------------------------------------------------------------------ Now the repeated lines in test.flog are expected from the gsi case because the code is effectively run twice, once upon load and once manually (as will be seen from the source below). So what is going on with the standalone execution? I am very puzzled. the source code for bug.Gambit. This is the output of a preprocessor, so it looks a little strange, but it is really very straightforward. ------------------------------------------------------------------ (define _cons_23 cons) (define *flog-use-current-output-port* #f) (define *flog-use-current-error-port* #f) (define flog-file (lambda (_file-name_38 _s_39) ((lambda (_f_40) (begin (display _s_39 _f_40) (newline _f_40) (if *flog-use-current-output-port* (display _s_39 (current-output-port))) (if *flog-use-current-error-port* (display _s_39 (current-error-port))) (close-output-port _f_40))) (open-output-file (_cons_23 (quote path:) (_cons_23 _file-name_38 (quote (create: maybe append: #t)))))))) (define main (lambda (_argv_38) (begin (flog-file "test.flog" "this is a test") ))) (main (command-line))

3 2

Re: [gambit-list] Puzzlement (different behavior of compiled code)
by Mikael 10 Jui '12

10 Jui '12

I cannot see any possibility that the compiler would confuse things in such a way that instead of doing (string->keyword "path") it does (string->symbol "path:") . Can you please reduce this bug to its simplest form and tell the outcome here? This ought to shed light over what's wrong. Brgds 2012/6/10 David Rush <kumoyuki(a)gmail.com> > On 10 June 2012 14:31, Mikael <mikael.rcv(a)gmail.com> wrote: > > > > Uh this is funny: > > > > (open-output-file '(|path:| "test.flog" |create:| maybe |append:| #t)) > > > > look there, there's |:s around the keywords. This means they're *not* > > actually keywords but *symbols* that kind of look like keywords. > > That is interesting. I have no idea why, as I said it's the same code > in both cases (code was included in the tail of the OP) > > > Tried to reproduce your error on 4.6.2: > > > > $ cat a.scm > > (write (cons abcde: 123)) > > $ gsi a.scm > > (abcde: . 123)$ gsc -exe a.scm > > $ ./a > > (abcde: . 123) > > I wonder if mine is a case that occurs because the code renames cons > (in an attempt to avoid variable capture while expanding macros) so > that instead of cons the var referenced is actually _cons_23 - leading > to compiler confusion about special cases. > > > Do you compile this code just with gsc filename.scm or (compile-file > > "filename.scm") or do you have some preprocessor on it? > > from the original message: > > ----------------------------------------------------------------------- > drr@dibbuk$ make target=gambit test/bug.gambit > gsc -:s -link test/bug.Gambit > gcc -I/home/drr/include test/bug.c test/bug_.c -o test/bug.gambit \ > -L/home/drr/lib -lgambc -lm -lutil -ldl > ------------------------------------------------------------------------ > > which is something of a habit i have with Gambit going back many years > in order to actually insert a lot of gcc optimization flags (*not* > included in this test case) > > > Do you see any other reasons for why this occured? > > just what I suggested above. It gives me something to try anyway. > > d > -- > GPG Public key at http://cyber-rush.org/drr/gpg-public-key.txt >

1 0

Gambit on Android
by Steve Graham 10 Jui '12

10 Jui '12

I understand that Android apps are typically written in Java. How then is Gambit able to run on that platform? If it is possible to write GUI apps for the Android using Gambit, are there any pointers on how to get started? Thanks, Steve

4 23

Re: [gambit-list] What about Gambit did you always want to get a good understanding of? (design of any aspect, compiler & VM)
by Estevo 09 Jui '12

09 Jui '12

Thanks to you and Marc for offering your time and knowledge! (Some thoughts follow after the quote.) > Date: Sat, 9 Jun 2012 00:57:11 +0300 > From: Mikael <mikael.rcv(a)gmail.com> > Subject: [gambit-list] What about Gambit did you always want to get a > good understanding of? (design of any aspect, compiler & VM) > To: gambit-list(a)iro.umontreal.ca > Message-ID: > <CACbx-M8N+S7KMYe61Z+X6svuZMd1RNUct8ETuKtXVeJLePo5pA(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > (let's recontextualize the q from the previous email to a separate thread:) > > > Anyone please feel free to suggest questions or angles on subjects that > should be addressed in this document, so that these will be covered too. > > So basically, what about Gambit have you always wanted to get a good > understanding of (and which is not quite obvious from looking at Gambit's > sourcecode), and how would you formulate the questions that would take you > to getting this understanding? This is probably lazy and not very helpful of me, but my reply to that question would be Overview/Start Here. A generalistic article that listed the various aspects of Gambit, and for each of such aspects: - links to papers that may be helpful in understanding the implementation (the email you sent earlier would make an excellent starting point in this regard -- thanks for collecting those!), and - links to the github pages of the most relevant files in the source code. The latter could be pegged to some specific version to make sure docs and code don't fall out of sync. I imagine most of the time it will not be critical to point to the current head. Regards, Estevo.

1 0

What about Gambit did you always want to get a good understanding of? (design of any aspect, compiler & VM)
by Mikael 08 Jui '12

08 Jui '12

(let's recontextualize the q from the previous email to a separate thread:) Anyone please feel free to suggest questions or angles on subjects that should be addressed in this document, so that these will be covered too. So basically, what about Gambit have you always wanted to get a good understanding of (and which is not quite obvious from looking at Gambit's sourcecode), and how would you formulate the questions that would take you to getting this understanding?

1 0

4.6.6 or 4.2.8
by Steve Graham 08 Jui '12

08 Jui '12

Just downloaded and built the latest version. Verbiage in make indicated it was 4.6.6. However, when I fired up gsi and gsc, they both said 4.2.8. I am running on an x64 Linux system. Steve

4 6

Fix expansion of map and foreach
by Bradley Lucier 08 Jui '12

08 Jui '12

Marc: Since you're moving the primitive expansion code to _t-univ.scm, this is a good time to fix the expansions of map and foreach. For example, consider the following source code: (declare (standard-bindings) (extended-bindings) (block)) (define (my-car x) (car x)) (define (map-car l) (map car l)) (define (map-my-car l) (map my-car l)) (define l '((1 2) . 4)) (pp l) (pp 'map-car) (pp (map-car l)) (pp 'map-my-car) (pp (map-my-car l)) I'm not going to show the output of heine:~/Desktop> gsc -c -expansion test-map.scm but you get the following behavior in the interpreter and the compiler: heine:~/Desktop> gsc test-map.scm heine:~/Desktop> gsi test-map.scm ((1 2) . 4) map-car *** ERROR IN "test-map.scm"@20.5 -- (Argument 2) LIST expected (map '#<procedure #2 car> '((1 2) . 4)) heine:~/Desktop> gsi test-map ((1 2) . 4) map-car (1) map-my-car *** ERROR IN | test-map.o3| -- (Argument 2) LIST expected (map '#<procedure #2 my-car> '((1 2) . 4)) And, if you look at the generated C code, map-car unconditionally calls generic car, while map-my-car optimistically expands the call to car. In brief, map-car doesn't catch the error, and it's a lot slower than map-my-car. In my opinion, map-car and map-my-car should have the same code. Brad

2 2

gsc error
by Steve Graham 07 Jui '12

07 Jui '12

What do you make of this? I have MinGW installed, but not Cygwin on my Win7x64. Steve --- C:\Users\Steve\Desktop>type test.scm (declare (block)) (define (f x) (+ (* x x) (- x 1))) (define (g y) (f (f y))) (pp 123) C:\Users\Steve\Desktop>gsc test.scm gcc: error: unrecognized command line option '-mno-cygwin' C:\Users\Steve\Desktop>

2 3

Shrinking Gambit-C
by Steve Graham 07 Jui '12

07 Jui '12

When you use Gambit to create a standalone app, does it contain all of Gambit or only the parts you need for you app? If it contains the whole of Gambit, is there a way to strip away what you need for your app? If so, how would one do that? URL's would be appreciated. Thanks, Steve

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Gambit-list Juin 2012