l...@gnu.org (Ludovic Courtès) writes:
> * Leave public posts about large changes like those related to
> psyntax, memoization, “expanded structures” (?) & co. of
> May 19th/20th. (I personally don’t get anything of what’s
> happened.)
In the meantime I read the excellent NEWS (heh
We are pleased to announce GNU Guile release 1.9.11. This may be the
last pre-release before the 2.0 release.
It provides many new noteworthy features, most notably the addition of a
compiler and virtual machine. We encourage you to test them and provide
feedback to `guile-de...@gnu.org'.
The G
Hello,
‘procedure-name’ doesn’t currently work on VM programs. It may be due
to commit bdf7759c, which commented out ‘maybe-name-value!’ calls in
psyntax.
Why are these commented out? Is there some bootstrapping issue involved
(e.g., ‘maybe-name-value!’ can’t work with the evaluator)?
Besides,
They claim that MELT is tightly integrated with GCC, but after reading
http://gcc.gnu.org/wiki/MiddleEndLispTranslator, I don't believe it. The "MELT
compiler implementation" description suggests that it's a pretty simple-minded
sexp-to-C translator. I also notice that none of the examples has a
Hi Noah!
Noah Lavine writes:
> Here is my understanding of the three approaches:
>
> The approach in my project was to make machine code a Guile datatype,
> which you could allocate with a special init function and write to
> with writing functions which are just Guile versions of the Lightning
Hello,
Noah Lavine writes:
> I didn't realize GCC had a Lisp interface. Interfacing with GCC would
> be excellent.
MELT is a “middle end”, useful when writing optimization passes, but not
when writing a front-end.
> This is perhaps far-fetched, but I think the best thing would be if we
> could
I didn't realize GCC had a Lisp interface. Interfacing with GCC would
be excellent.
This is perhaps far-fetched, but I think the best thing would be if we
could persuade them to replace MELT with Guile. It looks to me from
the docs like MELT is yet another Lisp engine, which is exactly what
Guile
On Tue, Jun 1, 2010 at 5:06 AM, Andy Wingo wrote:
> Hi Noah,
Hi Andy!
> I feel quite strongly that the calling convention for native code should
> be the same as that of bytecode, and that it should use the same stack.
> This way we don't have to maintain separate stack walkers or debuggers
> or
Hi Julian,
Julian Graham writes:
>> Somehow we had the name of (rnrs bytevectors) wrong -- it was (rnrs
>> bytevector). I've renamed it in git, which should make it into the
>> 1.9.11 prerelease tonight. Sorry for the confusion!
>
> While you're looking at that, what do you want to do about the
Hey Andy,
> Somehow we had the name of (rnrs bytevectors) wrong -- it was (rnrs
> bytevector). I've renamed it in git, which should make it into the
> 1.9.11 prerelease tonight. Sorry for the confusion!
While you're looking at that, what do you want to do about the version
of that module (and of
Hey all,
Somehow we had the name of (rnrs bytevectors) wrong -- it was (rnrs
bytevector). I've renamed it in git, which should make it into the
1.9.11 prerelease tonight. Sorry for the confusion!
Andy
--
http://wingolog.org/
Hi Noah,
On Tue 01 Jun 2010 00:49, Noah Lavine writes:
> The approach in [Ludovic's] plan for JIT, as I understand it, is to
> implement this completely in the C layer. The machine code would be
> stored as part of the representation of a procedure, and would be
> invisible from the Scheme side.
Hi Noah,
On Thu 27 May 2010 23:03, Noah Lavine writes:
> I now have a start at working bindings for Lightning, which you can
> see at http://github.com/noahl/guile-lightning.
Fascinating! Congrats on getting through the foreign function docs; a
high-level interface is really necessary there...
On Mon 31 May 2010 18:27, l...@gnu.org (Ludovic Courtès) writes:
> Andy Wingo writes:
>
>> On Sun 30 May 2010 22:24, No Itisnt writes:
>>
> The reason it bothers me is because it makes it cumbersome to deal
> with input from a port.
True; but it's just how it is, I think. The E
14 matches
Mail list logo
