[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Texmacs-dev] Performance of Guile Scheme vs librep Lisp

From: Joris van der Hoeven
Subject: Re: [Texmacs-dev] Performance of Guile Scheme vs librep Lisp
Date: Mon, 14 Nov 2005 10:09:35 +0100
User-agent: Mutt/1.5.9i

Hi again,

If you are interested in a comparison of Scheme implementations,
please search the mailing list archive; about one and a half year
ago (if my memory is right), this issue has been discussed in detail.
For instance, Bigloo might be interesting as a Scheme compiler.

Yours, Joris

On Sat, Nov 12, 2005 at 01:56:31PM -0800, Karl Hegbloom wrote:
> On Sat, 2005-11-12 at 15:12 +0100, Joris van der Hoeven wrote:
> > Yes, if the choice of Guile were to reconsider, there would probably
> > be several good alternatives. The problem is that this is quite
> > difficult in the near future, because our task-list is already
> > full with more urgent things...
> I wrote that stuff about 'librep' vs Guile from previous knowledge,
> without even looking at the relative status of the two projects.  It
> appears that 'librep' is no longer under active development.  That is a
> shame, perhaps, since it is such a nice little Lisp_1.  I think that
> every computer science student and hobby-hacker should read it's source
> code.  There is a lot to learn from it.  It's virtual machine is tight
> and quick.  John Harper, the author of 'librep' told me that his thesis
> had to do with CPU cache performance issues, and the design of the
> 'librep' VM is such that it is meant to reduce cache misses, helping to
> make it run faster.  The indirect-threading method with the jump table
> (vs switch statement) is really slick.
> Of course there is also a lot to learn from the Guile implementation.
> It has features lacking in 'librep' (objects and generic methods), and
> is still being actively developed.  It is in use by many Open Source
> software projects as well.  GnuCash is really coming along nicely, for
> instance.  They have the 'g-wrap' thing working to great effect,
> wrapping their C code very automatically.  There is also a
> 'guile-gnome-platform' project, which also uses g-wrap.  From the
> "HACKING" file:
>         GNU arch is a source management tool that is particularly
>         well-suited to modular, decentralized hacking. It is what we use
>         to manage our code. The canonical source for guile-gnome is our
>         arch archive, address@hidden:
>            $ tla register-archive address@hidden \
>                http://download.gna.org/guile-gnome/archive-2004
>         guile-gnome is developed as a set of modular source packages. To
>         check out guile-gnome, the first thing you will need to do is to
>         check out the `dists' package:
>            $ tla get address@hidden/dists--dev--0 \
>                guile-gnome-dists
>         This will check out the `dists' category into the
>         guile-gnome-dists
>         directory. The next step is to configure the source tree for a
>         given set of wrapsets. Build configurations are kept in
>         configs/gnu.org. There is a `dev' configuration for
>         bleeding-edge hacking, and versioned categories for releases
>         that have already been made. For example, to check out the 2.6.0
>         platform release, you could do the following:
>            $ tla build-config -r
>         configs/gnu.org/guile-gnome-platform-2.6.0
> And, for those who aren't already aware of it's location, the Guile
> Scheme development sources are apparently at:
>  http://www.glug.org/people/ttn/software/guile/ANONCVS
> I personally have not had as much time recently for the study of Guile
> and Guile-Gnome as I'd like to have, but expect that after this years
> Mathematics and Logic, Discrete Mathematics and Computability Theory
> courses, I'll be better prepared for understanding it.  (Perhaps next
> summer, if that's what I wind up doing then.  At that point I can learn
> whether a byte-code VM is viable for Guile.)  I really want to learn
> more about the internal workings of that kind of software subsystem.
> Languages can be quite intriguing.  I also plan at some point to learn
> more about how the classical TeX system works, and more about CAS
> implementation.
> -- 
> Karl Hegbloom <address@hidden>
> _______________________________________________
> Texmacs-dev mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/texmacs-dev

reply via email to

[Prev in Thread] Current Thread [Next in Thread]