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
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.
*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
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
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
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
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
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
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
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'.
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
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
12 matches
Mail list logo