Guileôòùs Texinfo parser
Argh. The idea of a full second Texinfo parser in GNU is fundamentally
wrong. If you want to call it a "Guile docstring parser, whose language
happens to bear some resemblance to a subset of Texinfo", fine.
Anyway, your change to use more Guile in the Guile build p
Hi,
Stefan and Mark, I think you are talking past each other. Stefan is
offering a very concrete definition of what he wants, and Mark is looking
for a more abstract version. Here is what I think Stefan wants, in the
language of R5RS' storage model:
A variable is simply a name for a particular lo
Mike Gran skribis:
>> Attached is a patch to use Guile’s Texinfo support [0] to build said
>> file. Guile’s Texinfo parser is incomplete but sufficient to handle
>> those docstrings.
>
>> OK to commit?
>
> If Guile depends on Guile for multiple stages the build, it becomes
> difficult to recover
On Thursday, March 21, 2013 03:03:06 PM Mark H Weaver wrote:
> Stefan, you're still describing your proposal in terms of low-level
> implementation details such as stacks. In the general case, we cannot
> store environment structures on the stack. Furthermore, in the
> general case *all* variable
Stefan, you're still describing your proposal in terms of low-level
implementation details such as stacks. In the general case, we cannot
store environment structures on the stack. Furthermore, in the general
case *all* variables in scheme are bound to locations, not values. Only
in special case
Hi Ludo
> Attached is a patch to use Guile’s Texinfo support [0] to build said
> file. Guile’s Texinfo parser is incomplete but sufficient to handle
> those docstrings.
> OK to commit?
If Guile depends on Guile for multiple stages the build, it becomes
difficult to recover from a problem when
l...@gnu.org (Ludovic Courtès) skribis:
> Alternately, would you suggest using a different approach?
Attached is a patch to use Guile’s Texinfo support [0] to build said
file. Guile’s Texinfo parser is incomplete but sufficient to handle
those docstrings.
It solves an actual bug for anyone usin
On Thursday, March 21, 2013 11:35:19 AM Noah Lavine wrote:
> (lambda ()
> (let ((x 5))
> (set! x (compute-1 x))
> (set! x (compute-2 x))
> x))
>
> becomes
>
> (lambda ()
> (let ((k1 (lambda (x) (k2 (compute-2 x
> (k2 (lambda (x) x)))
> (k1 (compute-1 x
>
> How
Hello,
Yes, you're completely right - making it work on all platforms is much
better than what I had proposed. I'm glad you're doing this.
Thanks,
Noah
On Thu, Mar 21, 2013 at 5:15 AM, Ludovic Courtès wrote:
> Hi Noah,
>
> Noah Lavine skribis:
>
> > I've thought for a while that if I had tim
Hello,
I think I understand what Stefan wants here, and I think it should probably
be possible.
If I understand correctly, the issue is that when a continuation is
captured, it stores the *locations* of all of the variables in-scope at
that point. If that continuation is invoked many times, each
On Thu 21 Mar 2013 14:53, Andrew Gaylard writes:
> (catch #t
> (λ ()
> (throw 'oops)) ; should not crash the vm
> (λ ()
> (display "Success!")(newline))) ; never reached
>
> the VM still cores; "Success" is never shown. However, you've probably
> spotted my mistake: the handler should be (λ (key
On 03/21/13 11:43, Andy Wingo wrote:
On Fri 15 Mar 2013 22:01, Brent Pinkney writes:
When I resume the continuation in another thread, all works perfectly
UNLESS the continued execution throws and exception.
Then guile exits with a core dump.
By contrast if I resume the continuation in the sa
Andy Wingo skribis:
> On Thu 21 Mar 2013 10:40, l...@gnu.org (Ludovic Courtès) writes:
>
>>> l...@gnu.org (Ludovic Courtès) writes:
I plan to commit the patch below, which adds bindings for
>>>‘sendfile’.
>
> Should probably go in gnulib at some point, no?
Yes, you’re right. I’ll see what
On 03/21/13 11:15, Ludovic Courtès wrote:
Noah Lavine skribis:
I've thought for a while that if I had time (which I know I won't) I would
make a module called (linux) with bindings for non-POSIX Linux kernel
features. What do you think of this idea? If so, what do you think of
putting sendfile
On Thu 21 Mar 2013 10:40, l...@gnu.org (Ludovic Courtès) writes:
>> l...@gnu.org (Ludovic Courtès) writes:
>>> I plan to commit the patch below, which adds bindings for
>>‘sendfile’.
Should probably go in gnulib at some point, no? Looks good tho :)
--
http://wingolog.org/
On Fri 15 Mar 2013 22:01, Brent Pinkney writes:
> When I resume the continuation in another thread, all works perfectly
> UNLESS the continued execution throws and exception.
> Then guile exits with a core dump.
>
> By contrast if I resume the continuation in the same thread and then
> throw and
Hi Mark,
Mark H Weaver skribis:
> l...@gnu.org (Ludovic Courtès) writes:
>> I plan to commit the patch below, which adds bindings for ‘sendfile’.
>>
>> Comments?
>
> Looks great to me, modulo one comment below.
Thanks for the quick review!
> I especially like the fact that although it can make
Ok, This was a first step to get what I would like to have implemented
in the tree il backend (Not for scheme but perhaps something useful
for e.g. emacs-lisp, python etc).
My main issue with the current setup is that adding undoing and
redoing feature with the help of prompts will fail in 95% of
Hi Noah,
Noah Lavine skribis:
> I've thought for a while that if I had time (which I know I won't) I would
> make a module called (linux) with bindings for non-POSIX Linux kernel
> features. What do you think of this idea? If so, what do you think of
> putting sendfile there and expanding it wit
On Thu 21 Mar 2013 01:38, Mark H Weaver writes:
> Chris K. Jester-Young has been hard at work getting his SRFI-41
> implementation ready in time for Guile 2.0.8, and I think it might be
> ready to push. What do you think?
Needs documentation.
--
http://wingolog.org/
20 matches
Mail list logo
