- Gambit-list - mailman.iro.umontreal.ca

Macros, separate files, and all that
by Bradley Lucier 31 Jan '13

31 Jan '13

Marc: Assume that there's a file called "streams.scm" that has Phil Bewig's streams code in it, and that there's a file called "sieve.scm" that uses the definitions in streams.scm Now, when I do [Media-Mac-mini-3:~/Downloads] lucier% gsi -:s Gambit v4.6.6 > (load "streams.scm") "/Users/lucier/Downloads/streams.scm" > (load "sieve.scm") "/Users/lucier/Downloads/sieve.scm" > (stream->list 10 primes) (2 3 5 7 11 13 17 19 23 29) everything works fine. But if I compile the streams code and do [Media-Mac-mini-3:~/Downloads] lucier% gsi -:s Gambit v4.6.6 > (load "streams") "/Users/lucier/Downloads/streams.o3" > (load "sieve.scm") *** ERROR IN #<procedure #2>, "sieve.scm"@5.6 -- Unbound variable: define-stream then, as you can see, a macro from streams.o3 is not available for use in expanding sieve.scm. So, I guess I don't understand the "persistence" or whatever you would call it of R5RS macros, and how that interacts with Gambit's compilation model. Can you help? Brad

3 6

How do I create a pipeline of processes, as in shell?
by Jussi Piitulainen 29 Jan '13

29 Jan '13

In shell it is easy to run a program, and it is easy to chain programs into a pipeline where each process writes to the following process. In Gambit-C it appears to be easy to run a program and write to the process and read from the process. I failed to find a way to specify that the output of one process should be connected to the input of another. I have found open-process, process-status. I have found some discussions about running single processes. How does one implement the following lines in Gambit-C? $ sort infile | uniq -c | sort -nr $ sort < infile | uniq -c | sort -nr > outfile Is this non-trivial? I'm looking for something like the following, so that those processes would wait for their input and proceed when it becomes available. (let ((p (pipe '(path: "sort" arguments: ("infile")) '(path: "uniq" arguments: ("-c")) '(path: "sort" arguments: ("-nr"))))) (let* ((r1 (read-line p)) ...) ...)) (parameterize ((current-input-port (open-input-file "infile")) (current-output-port (open-output-file "outfile"))) (process-status (pipe "sort" '(path: "uniq" arguments: ("-c")) ...))) I'm _not_ looking for (string-append ...).

3 6

A rudimentary pipeline implementation with bridging threads
by Jussi Piitulainen 28 Jan '13

28 Jan '13

Assuming my previous question came through, I asked about implementing pipelines of processes in Gambit-C. The problem was that I could not seem to make the output of one process to connect to the input of the next on their own. I'm now experimenting with Gambit-C threads to bridge those gaps. Here is a rudimentary implementation of what I want. The comments indicate things that I think I know I still need to do. I haven't used threads much before, and never in Scheme. The original question stands: am I overlooking some obvious way to do such pipelines that Gambit-C already has? Because this is the easy 80% of the work and another 80% sheer tedium probably remains :) (define (echo from to) ;should use a buffer (do ((line (read-line from) (read-line from))) ((eof-object? line)) (display line to) (newline to))) (define (piece from to) (lambda () (echo from to) ;should allocate a private buffer for echo (close-output-port to) ;stopped using it as output port (process-status from))) ;wait for it - maybe time it out? (define (end from) ;not closing current output port (lambda () (echo from (current-output-port)) (process-status from))) ;actually, the end should be controlled by the called altogether! or ;is it now? ;caller needs to close the first pipe segment as output port, and do I ;need to force some output or close input ports? and errors should be ;handled, including diagnostic output from the processes and failed ;status of any, and not leave processes around on any sort of error if ;possible. oh and do all those threads terminate nicely and always? (define (pipe first . rest) (let ((first (open-process first))) (do ((last first (car rest)) (rest (map open-process rest) (cdr rest))) ((null? rest) (thread-start! (make-thread (end last))) ;;^altogether mistaken - leave it to the caller (values first last)) (thread-start! (make-thread (piece last (car rest))))))) (define (test) ;has hardwired end to echo the output in current output (call-with-values ;^fix it so the called handles reading and waiting (lambda () (pipe "date" '(path: "tr" arguments: ("0-9" "D")))) (lambda (first last) (close-output-port first))))

2 3

Request: examples of cool uses of macros
by Jason Felice 27 Jan '13

27 Jan '13

Hi! Does anyone have any examples of macros which drastically improve readability or simplicity of code? Maybe neat hacks? Not *deep* hacks that take a long time to understand, but things which can be used to illustrate why macros are powerful and awesome. Background: I'm giving a talk tomorrow on Scheme to prisoners in a job training program. The purpose is to expand their brains by exposing them to concepts they haven't seen before (they don't have Internet access). The talk is about Scheme and "Code is Data". I've laid the foundation, but am getting to the point where I want to have some flashy and interesting uses of macros. Any help would be appreciated. Thanks, -Jason

5 4

Re: [gambit-list] BH
by Mikael More 25 Jan '13

25 Jan '13

Hi Alvaro, (Two Q:s for you at the bottom.) 2013/1/25 Álvaro Castro-Castilla <alvaro.castro.castilla(a)gmail.com> > Hi! > > I write about the 2 latest emails here: > > * Separate module-systems compilation: > That's it. I think that is the best solution. I already did a proof of > concept in the past for scheme spheres and it works well: some modules > are expanded with one expander and some with other. The result is > taken by Gambit seamlessly. > In my experience, people don't mix define-macros and syntax-rules. For > those cases where you *NEED* define-macros (like processing names of > identifiers) a second pass could be offered, but is another story. > One simple expander per module is a modular and simple solution I'm > totally in for. > Yeah. By this do you mean that you think the idea I proposed in the email ~17hrs ago is a good direction for the development? > * Lightweight-portable implementation of BH: > You can see some of the techniques I talk about here: > https://www.youtube.com/watch?v=Q7c0rU9Lv28 > > The point is that if you have an implementation that is lightweight > and pluggable enough, you can use it for remote REPLs of any kind > (mobile debugging, web servers, hot code swapping in webservers -which > can be done with termite-), like the example of the video. > > Why I so much like Alexpander is because it does exactly that: it is > less than 1KLOC and works with any scheme system. The only issue with > being portable is that you don't have that nice error reporting, > apparently (and that you don't use the non-portable facilities that > could make it faster and more compact). But BH doesn't need to be > portable across scheme implementations so this is our chance to make a > BH with these features. > > This is why I insist so much on the separation of concerns and the > lightest possible BH. > I've been thinking about possible ways of making BH just a text > processor (like Alexpander currently is), and I believe is possible. > The only issue is that probably you need to output more than one file. > Simply knowing which symbols to prepend with which namespace prefix, > you already have a simple module system that can have the same > encapsulation properties than BH, if you mix that with macro expansion > then you have all you need. > > The only thing I'm trying to figure out is how to make this #namespace > be prepended to macros names, as they need to be part of the module > system as well, but that could be handled by the macro expander (which > goes hand in hand with this module system). > > Really, what I have now working at Scheme Spheres and works pretty > well (waaaaay faster macro expansion than BH) gives me this: > - full expansion of syntax-rules in a first pass > - expansion of define-macro's in a second pass > - module system in the Gambit style > - fully embeddable in any system that I want to not just eval scheme > code, but process its macros > > What does it need to achieve all we need from Blackhole and be > superior due to the portability and embeddability? > - module system that incorporates the macros > - better error reporting for macros > > In summary, a solution like I'm proposing would have the following > features: > > - embedabbility: could be embedded in a web browser (with a javascript > backend), in a web server for hot code swapping and testing, live > coding (see http://toplap.org/ for some examples of this world, and > let me tell you that one of the most interesting apps for live coding > is currently running on Racket), remote debugging and coding of > Android devices. And many others options that this would open the > doors to. > - composability: a separation of concerns would make it easy for > people to make small apps that glue together a workflow, very much in > the Unix style. Also, this would be more welcoming for people to > contribute to new "utilities". For instance, we now should worry just > about the essential utilities (macros, modules and maybe packages), > but all the niceties that we find in other ecosystems can be built on > top of these 3 (and I'm talking about gem/sids, bundler/sbundle, > testing, literate programming, automatization). And these utilities > could be used by people who don't want to use BH at all! > - control: simplicity and respecting the "Gambit ways" (like just > producing a Scheme output and delegate to Gambit), will allow for > *full* control of how you want your code to live. > I mean, with BH we > lost control of things like dynamically loading object files by need, > What was this about, can you describe the use case and problem? > or just compiling everything in one C file for MAX performance > (avoiding trampolines). > I believe BH has a feature for this, it's something like that it can take all the modules at least in the same dir and make only one module file out of them. Well, that is my proposal, and I believe it is actually much simpler > than original Blackhole and would solve more problems. > Yes, it looks like it will be something like this. Best regards, > > Álvaro > So basically the Scheme environment-specific code (like production of ##namespace codes, inserting code into the Scheme environment, doing compile-file) should be split apart from as much of the module system 'core' as possible. Maybe, I'll start drafting some kind of API for all this stuff soon. * Would be happy if you could give spontaneous feedback on the API draft I sent you yesterday, for interface between package management/module loader and module system. I'm not clear on what kind of requirements that a live coding environment or alike could have. Really, this BH now will be made primarily for Gambit, and support for generation toward other systems will be a bit like a bonus. I believe something like a-set-of-modules => a Scheme code image suitable for feeding Scheme2JS with, is completely realistic. * Alvaro: When do you believe your document on use and advanced use of syntax-rules will be ready? I'm a but curious on how line number info should be managed through this expansion process. I know Gambit has an internal format for it already, hopefully we can just hook onto that. All the macro expanders will need to traverse the input Scheme structure atop a DSL that deals with this format. Really, if the DSL:s involved are just well documented, and all the involved modules can be loaded as ordinary BH modules for anyone who wants to use them, then I believe we've got a high degree of plugability and reusability and dynamicity in all kinds of directions already there. So, BH was monolithic in these respects, perhaps it could have been designed like this but it was not. Hopefully by just doing this we get all those godo qualities. Brgds, Mikael

1 0

Demo code for mobile apps in Gambit Scheme?
by Andrew Pennebaker 24 Jan '13

24 Jan '13

I see that Gambit apps can be written for iOS. What about Android and Windows RT? Any demo code we can use as a reference? -- Cheers, Andrew Pennebaker www.yellosoft.us

3 3

Black Hole and C source
by Jason Felice 23 Jan '13

23 Jan '13

Is there a way to get the generated C (or assembly) from bh? I can't find one. Thanks! -Jason

4 10

Several questions about gambit
by Chris Müller 23 Jan '13

23 Jan '13

Hey :) I've currently started to learn/use scheme for some experiments in machine learning and chose gambit for its close relation to c. I would like to share my first impression and misunderstandings with you and have some questions which maybe also help other newcomers. 1) I managed to compile my scheme library into a dynamic loadable unit that i use in some scripts for the gsi interpreter. Does anyone know how i can specify some kind of loadpath (e.g. via ENV, commandline flag) for the interpreter where (load "...") searches scheme modules? (Or any other common alternatives) Currently i'm always using relative paths through (string-append (path-directory (this-source-file)) "/" "module") based on the file location itself. 2) I've struggled in the beginning very much with the usage of gsc and gsi. My first step is often calling the --help flag of the command itself. Unfortanetely, i haven't found any useful option like "gsc --help" or "gsi --help" that provides a short summary about its common command flags. The man page and the -:h flag provides some information about runtime configuration. But it seems a little incomplete. (Especially for compiling scheme files to .o1). It would be a great help to extend this summary with the mentioned options from the documentation in "/usr/share/gambc" or "info gambit-c". (If i missed something interesting, just let me know) 3) For my own purpose i'm currently implementing a trivial testing library similar to rspec and would like to share this. The wiki mentioned two package systems (Black Hole and Snow). I like to ask if there exists some preferences using a specific system and which one do you suggest (or is there even one of them deprecated?) 4) Do you know a good scheme alternative for the printf command in c? I've currently only used (print ..) and (display ..) which worked, but i would also prefer some formated outputs for the future :) 5) I have currently no clue about gambit overall capabilities. But i guess it already belongs to the most matured scheme implementation due to its older age. I'm especially interested in its foreign interface to C and it would be interesting to know if its possible to bind bigger libraries like Glib/GTK/Cairo flawlessly. (Or does there exists some known limitations that could lead to obvious problems). Hope you nevermind this trivial questions that helps me a little in gambits scheme landscape. Chris

4 7

web server example
by Fred Weigel 22 Jan '13

22 Jan '13

A sample web server is supplied with Gambit-C. I am using gsi 4.6.6 [fred@dejah Gambit-C]$ gsi Gambit v4.6.6 > and tried the web server (for inclusion into some of my own code). I do like the design, but there seems to be a bug. In http.scm line 827, there is a reference to function (print). The problem is that (print) doesn't produce ANY output on "port", and the contents are then interpreted as a flat text file. I replaced (print) with (display), and the thing works (as expected). Running on Fedora 17 Linux, with the invocation gsi base64 html http web-server 8000 (as recommended).

2 2

Proposal: Addition of a parameter option for signalling IO error as #f/#!eof result value instead of as exception
by Mikael 19 Jan '13

19 Jan '13

Dear Marc and Gambit community, Here's a reflection on Gambit's IO routines' use of exceptions and a proposition for a tweak. For context, please check the previous email. Here we go: I've come to relate to exceptions as a suitable medium pretty much solely for conveying an error state that requires manual administrator/programmer intervention. Exceptions to the "solely" would be if there's some rare invocation of some routine, where a catch-all "it failed" kind of result would be satisfactory for error handling. Thus, for instance if you make a laboratory project of connecting one computer to another and suddenly a read-u8 operation fails, that's a good reason to throw an exception. But, if you do read-u8:s all the time in a context where some of them are expected to fail, I suggest the view that making that result in an exception is a terrible idea because of the reasons below. So to sum up, Gambit's IO routines currently throw a quite wide variety of exceptions. At least a bunch of them essentially convey the same thing as a #f or #!eof result would have done. *Lots of cases when exception on IO error is a bad idea* A typical example of when this makes a difference, is when you want to make some IO work in Gambit, where some form of eof-like IO failure is an expected outcome. Examples: * read-u8 from a TCP port that may or may not be closed now * write-substring to a TCP port that may or may not be closed now * A HTTP request, in particular if it's to a host that's not under your control All these calls cannot be wrapped individually in with-exception-catcher blocks, you'd need a 1Thz core for per-byte reading of large amounts of data with each read-u8 wrapped in a with-exception-catcher to not be too expensive, so my best understanding today is that the locations in Gambit's runtime that currently always produce exceptions in these cases, would benefit of a tweak: *What about: Introduce a global parameter object that introduces the option of #f/#!eof result instead of exception on IO error* As to keep code simple and effective, I would propose the introduction of a global parameter object io-prefer-eof-result-to-exception to control this behavior, and perhaps one or two more global parameters to be assigned detailed error info in the event of io error. Whenever a user needs to use IO with performance and in a might-fail context, he/she just switches this parameter to #t. What's important is that IO can be done at high performance when it works. Unlike individual invocations wrapped in with-exception-catcher, the presence of a parameter value has no overhead on individual procedure invocations. IO operation failures are extremely rare compared to IO operation successes (maybe 1:10,000), so the error handling code will be executed quite rarely and thus unwrapping of a parameter object is a no brainer expense in the context. As to get to this suggestion, I experimented over a long period with with-exception-catcher and with extracting Gambit* *IO routine code as to make custom exception-safe variants of them, this lead to the understanding that that cannot be reliably done, and involves copying of so much code that it's by far better to make a Gambit patch for this in the first place anyhow. *#f preferable over #!eof as IO operation return value in case of EOF due to its more central position in the type system?* Last, there is some #!eof returning in case of EOF already in Gambit's IO API. I have the impression that it's not completely consistent. It's struck me that #!eof not is so universal as EOF signal afterall: In a great many cases, #f would be better due to its role in the type system - to do meaningful stuff with #!eof you need to typecast it to boolean (i.e. (eq? result-value #!eof)) to do anything meaningful with it anyhow, and all the regarded procedures never throw #f within their current definition anyhow. Because of this at most or all of read-subu8vector read-substring read-u8 read-char peek-char read-line write-subu8vector write-substring write-u8 write-char force-output close-input-port close-output-port close-port input-port-timeout-set! output-port-timeout-set! would do better with #f than #!eof as return value to signal EOF. *Preliminary thought about next step: Make a patch and when it's mature, include it in the Gambit repo* Preliminarily I think this would be a good idea to pursue by making a Gambit patch that incorporates this functionality, and when it's mature, incorporating that patch into Gambit's master branch. The value of having it in the master branch is that this way, Gambit-based libraries such as a HTTP client, can be written in the coding style that follows from this, which would clean up the code *alot* and calibrate design decisions in an advantageous direction: Basically, error handling is done more explicitly but is much more specific - which is completely OK for IO-dense code for real world use, as this is what that kind of code does effectively anyhow - and there's some kind of performance increase. Please feel free to share any thoughts you have on this topic, what do you say about the idea? Best regards, Mikael

1 0