[PATCH]

2010-10-27 Thread Neil Jerram
I have a program that calls (read-elisp) in a loop, to read in a BBDB file. When it gets to the end of the file, the next (read-elisp) throws an error (wrong type arg, pair expected), and the attached patch makes it return '*eoi* instead. Is that correct? Is *eoi* better than # here? Or should

Re: [PATCH] Make (read-elisp) handle EOF

2010-10-27 Thread Neil Jerram
Neil Jerram writes: > I have a program that calls (read-elisp) in a loop [...] Oh dear, sorry for omitting a proper Subject there. I've added one now.

Re: [PATCH]

2010-10-27 Thread Noah Lavine
*eoi* is what the LALR parser generator would need as input, so it seems more consistent with the Guile API to make it return '*eoi*. Noah On Wed, Oct 27, 2010 at 2:27 PM, Neil Jerram wrote: > I have a program that calls (read-elisp) in a loop, to read in a BBDB > file.  When it gets to the end

Re: A Working (but Minimal) JIT

2010-10-27 Thread Ludovic Courtès
Hello! Phil writes: > On Thu, Oct 21, 2010 at 11:29 PM, Noah Lavine wrote: > >> So, this is a possible way to get a JIT engine in Guile. What do >> people think of it? > > General question for the list: Have there already been debates on this > list about doing native compilation all the time l

Re: A Working (but Minimal) JIT

2010-10-27 Thread Ludovic Courtès
Hello Noah! Noah Lavine writes: > After not emailing for a while, I have some good news: a JIT engine is > working! Woow, neat! :-) > The biggest change since the last version is that I switched from > Lightning to libjit. This was mostly because I realized that if I was > going to use Light

Re: [PATCH] Add implementation of SRFI 38

2010-10-27 Thread Ludovic Courtès
Hi Andreas! Andreas Rottmann writes: > +++ b/module/srfi/srfi-38.scm > @@ -0,0 +1,203 @@ > +;; Copyright (C) Andreas Rottmann 2010. Should be FSF. :-) > +;; Copyright (C) Ray Dillinger 2003. All Rights Reserved. Alex Shinn should be mentioned, though without “copyright” since he’s not a copy

Re: [PATCH] Use a fluid for the list of the reader's "hash procedures"

2010-10-27 Thread Ludovic Courtès
Hi! Thanks for the patch. Andreas Rottmann writes: > This is a prerequisite for the patch implementing SRFI-38, which I'll > post next. > > > From: Andreas Rottmann > Subject: Use a fluid for the list of the reader's "hash procedures" > > This allows customizing the reader behavior for a dynam

Re: [PATCH]

2010-10-27 Thread Ludovic Courtès
Hi Neil, Neil Jerram writes: > I have a program that calls (read-elisp) in a loop, to read in a BBDB > file. When it gets to the end of the file, the next (read-elisp) throws > an error (wrong type arg, pair expected), and the attached patch makes > it return '*eoi* instead. > > Is that correct

Re: [PATCH] LALR Parser Documentation Fix

2010-10-27 Thread Ludovic Courtès
Hi, Noah Lavine writes: > The documentation for the LALR parser currently says that the > tokenizer procedure passed to the parser should be a unary procedure > taking a port, but the documentation at > http://code.google.com/p/lalr-scm/wiki/ParserDefinition says it should > be a thunk. The foll

Re: [PATCH] Extend the #:replace list of the SRFI 69 module

2010-10-27 Thread Ludovic Courtès
Andreas Rottmann writes: > From: Andreas Rottmann > Subject: Extend the #:replace list of the SRFI 69 module > > * module/srfi/srfi-69.scm: Add `make-hash-table' and `hash-table?' to > the #:replace list of the module definition. Applied, thanks. Ludo'.

Re: A Working (but Minimal) JIT

2010-10-27 Thread Noah Lavine
Hello! > Interesting.  Dealing with end-of-buffers situation is indeed tricky > with lightning, and register allocation is lacking (I thought this > wouldn’t necessarily be a problem because we can do a reasonable job > with a fixed set of statically allocated registers.) That seems true, yes. Gi

Re: [PATCH]

2010-10-27 Thread Neil Jerram
l...@gnu.org (Ludovic Courtès) writes: > Besides, you might want to check if it’s fixed in the elisp branch, who > knows. :-) Ah, yes, I didn't think of that. As luck would have it, this has indeed been fixed already. :-) Thanks, Neil