Guile-Emacs update

Guile-Emacs update

[BT Templeton]

Hello all,

I've pushed several significant changes to the public Guile-Emacs
repository at <http://git.hcoop.net/?p=bpt/emacs.git>:

 * Synchronized with bzr trunk as of mid-July.

 * Guile's control operators are used for all Elisp control-flow
   functionality, including special binding, unwind-protect, errors,
   catch/throw, and quit handling.

 * Guile exceptions are handled safely, and are re-thrown as Elisp
   errors.

 * Emacs's I/O functions can now print arbitrary Guile objects.

 * Coccinelle, a semantic patching tool, can now parse 99% of Emacs's C
   code base, compared to 75% previously. This requires using a patched
   version of Coccinelle (<http://git.hcoop.net/?p=bpt/coccinelle.git>)
   and using admin/coccinelle/macros.h as the "--macro-file" argument to
   the spatch command.

 * Last but not least, there is now an `eval-scheme' command:

   (eval-scheme "(define (fact n) (if (= n 0) 1 (* n (fact (1- n)))))")
   (eval-scheme "(fact 23)") => 25852016738884976640000

Guile-Emacs requires libgc 7.2d or better and the development version of
Guile. More information is available on the Emacs Wiki at
<http://www.emacswiki.org/emacs/GuileEmacs>.

-- 
Inteligenta persono lernas la lingvon Esperanton rapide kaj facile.
Esperanto estas moderna, kultura lingvo por la mondo. Simpla, fleksebla,
belsona, Esperanto estas la praktika solvo de la problemo de universala
interkompreno. Lernu la interlingvon Esperanton!

Re: Guile-Emacs update

[Noah Lavine]

[-- Attachment #1: Type: text/plain, Size: 1992 bytes --]

Hello,

Thanks for the update! This is very exciting.

I looked at the emacswiki page you linked. It links to a page called
GuileEmacsTodo, but that doesn't seem to be your current to-do list (it was
edited too long ago). Could you say what differences a user would notice
between Guile Emacs and regular Emacs (if any)? Are there any things that
don't work, or any performance regressions?

Best,
Noah Lavine


On Sat, Jul 20, 2013 at 7:54 PM, BT Templeton <bt@hcoop.net> wrote:

> Hello all,
>
> I've pushed several significant changes to the public Guile-Emacs
> repository at <http://git.hcoop.net/?p=bpt/emacs.git>:
>
>  * Synchronized with bzr trunk as of mid-July.
>
>  * Guile's control operators are used for all Elisp control-flow
>    functionality, including special binding, unwind-protect, errors,
>    catch/throw, and quit handling.
>
>  * Guile exceptions are handled safely, and are re-thrown as Elisp
>    errors.
>
>  * Emacs's I/O functions can now print arbitrary Guile objects.
>
>  * Coccinelle, a semantic patching tool, can now parse 99% of Emacs's C
>    code base, compared to 75% previously. This requires using a patched
>    version of Coccinelle (<http://git.hcoop.net/?p=bpt/coccinelle.git>)
>    and using admin/coccinelle/macros.h as the "--macro-file" argument to
>    the spatch command.
>
>  * Last but not least, there is now an `eval-scheme' command:
>
>    (eval-scheme "(define (fact n) (if (= n 0) 1 (* n (fact (1- n)))))")
>    (eval-scheme "(fact 23)") => 25852016738884976640000
>
> Guile-Emacs requires libgc 7.2d or better and the development version of
> Guile. More information is available on the Emacs Wiki at
> <http://www.emacswiki.org/emacs/GuileEmacs>.
>
> --
> Inteligenta persono lernas la lingvon Esperanton rapide kaj facile.
> Esperanto estas moderna, kultura lingvo por la mondo. Simpla, fleksebla,
> belsona, Esperanto estas la praktika solvo de la problemo de universala
> interkompreno. Lernu la interlingvon Esperanton!
>
>
>

[-- Attachment #2: Type: text/html, Size: 2799 bytes --]

Re: Guile-Emacs update

[Taylan Ulrich B.]

Great news! :)

Noah Lavine <noah.b.lavine@gmail.com> writes:

> I looked at the emacswiki page you linked. It links to a page called
> GuileEmacsTodo, but that doesn't seem to be your current to-do list
> (it was edited too long ago).

The GSoC project has a better to-do list if I'm not mistaken.

By the way I've had it in mind for some time that we might want to
hijack the GuileEmacs page on EmacsWiki for the current
(i.e. Templeton's) project, updating and merging it with GuileEmacsTodo,
and moving the old contents of the GuileEmacs page to
"GuileEmacsHistory".  I'm saying this because it feels like the current
project has achieved a very mature state, much farther than any old
attempts (correct me), and might just be merged with upstream in the
next few years or so.  Tell me if I'm being silly.

> Could you say what differences a user would notice between Guile Emacs
> and regular Emacs (if any)? Are there any things that don't work, or
> any performance regressions?

Before this new series of changes, the two user-visible changes listed
at the bottom were up to date (unless the July-upstream rebase made a
difference), and the now-mentioned changes don't immediately sound
relevant to them, so I wouldn't be surprised if they're still up to
date.  I'll definitely test the latest version later today and update
the list as necessary though.  (Feel free to do so before me, of
course.)

Taylan

Re: Guile-Emacs update

[BT Templeton]

Noah Lavine <noah.b.lavine@gmail.com> writes:

> Thanks for the update! This is very exciting.
>
> I looked at the emacswiki page you linked. It links to a page called
> GuileEmacsTodo, but that doesn't seem to be your current to-do list (it was
> edited too long ago). Could you say what differences a user would notice
> between Guile Emacs and regular Emacs (if any)? Are there any things that
> don't work, or any performance regressions?

Yes, it is a bit out-of-date; as Taylan suggested,
<http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/bpt/35002>
is a better overview if you're interested in what's coming next.

For end-users, there should be no significant differences between
Guile-Emacs and regular Emacs at this time, and any incompatibility with
existing Emacs packages is a bug. It's likely that there will be slight
performance regressions for a while, in the course of switching to the
Guile VM, but nothing too major; I do have to use it myself on a
relatively old laptop, after all. (-:

-- 
Inteligenta persono lernas la lingvon Esperanton rapide kaj facile.
Esperanto estas moderna, kultura lingvo por la mondo. Simpla, fleksebla,
belsona, Esperanto estas la praktika solvo de la problemo de universala
interkompreno. Lernu la interlingvon Esperanton!

Re: Guile-Emacs update

[joakim]

BT Templeton <bt@hcoop.net> writes:

> Hello all,
>
> I've pushed several significant changes to the public Guile-Emacs
> repository at <http://git.hcoop.net/?p=bpt/emacs.git>:
>
>  * Synchronized with bzr trunk as of mid-July.
>
>  * Guile's control operators are used for all Elisp control-flow
>    functionality, including special binding, unwind-protect, errors,
>    catch/throw, and quit handling.
>
>  * Guile exceptions are handled safely, and are re-thrown as Elisp
>    errors.
>
>  * Emacs's I/O functions can now print arbitrary Guile objects.
>
>  * Coccinelle, a semantic patching tool, can now parse 99% of Emacs's C
>    code base, compared to 75% previously. This requires using a patched
>    version of Coccinelle (<http://git.hcoop.net/?p=bpt/coccinelle.git>)
>    and using admin/coccinelle/macros.h as the "--macro-file" argument to
>    the spatch command.
>
>  * Last but not least, there is now an `eval-scheme' command:
>
>    (eval-scheme "(define (fact n) (if (= n 0) 1 (* n (fact (1- n)))))")
>    (eval-scheme "(fact 23)") => 25852016738884976640000
>
> Guile-Emacs requires libgc 7.2d or better and the development version of
> Guile. More information is available on the Emacs Wiki at
> <http://www.emacswiki.org/emacs/GuileEmacs>.

I tried this today. I had prepared myself for a lot of work, but I was
surprised to find that the build procedure was very simple!

More or less, on Fedora 19:

# this isnt like the instructions above, but the fedora repo guile is
# seemingly pretty okay
yum install guile* 

#the clone took about 10 minutes
git clone git://git.hcoop.net/git/bpt/emacs.git

#make takes a loong time, much more than a normal emacs
./autogen.sh && ./configure && make

The build took 53 minutes including the time to clone the first time.
The second time took only a couple of minutes. This was on a fairly
beefy machine.

m-x tetris, and m-x zone worked fine!

(eval-scheme "(define (fact n) (if (= n 0) 1 (* n (fact (1- n)))))")
(eval-scheme "(fact 23)") => 25852016738884976640000

also worked fine!

I find this pretty awesome. I'm, hmm, awestruck!

-- 
Joakim Verona

Re: Guile-Emacs update

[Paul Smith]

On Wed, 2013-07-31 at 20:54 +0200, joakim@verona.se wrote:
> #make takes a loong time, much more than a normal emacs
> ./autogen.sh && ./configure && make

I'm not familiar with building Emacs, but doesn't its build system
support parallel compilation (couldn't you run "make -j4" or whatever's
appropriate for your system to get a nice speedup)?

Re: Guile-Emacs update

[joakim]

Paul Smith <psmith@gnu.org> writes:

> On Wed, 2013-07-31 at 20:54 +0200, joakim@verona.se wrote:
>> #make takes a loong time, much more than a normal emacs
>> ./autogen.sh && ./configure && make
>
> I'm not familiar with building Emacs, but doesn't its build system
> support parallel compilation (couldn't you run "make -j4" or whatever's
> appropriate for your system to get a nice speedup)?
>

I think the slowness was during lisp compilation, and that didnt use to
benefit from parallel compilation. I might try again though.

-- 
Joakim Verona

Re: Guile-Emacs update

[Óscar Fuentes]

joakim@verona.se writes:

>> I'm not familiar with building Emacs, but doesn't its build system
>> support parallel compilation (couldn't you run "make -j4" or whatever's
>> appropriate for your system to get a nice speedup)?
>
> I think the slowness was during lisp compilation, and that didnt use to
> benefit from parallel compilation. I might try again though.

Dunno about Guile-Emacs, but the regular Emacs build has not problem
compiling the Lisp files in parallel.

Re: Guile-Emacs update

[Taylan Ulrich B.]

joakim@verona.se writes:

> Paul Smith <psmith@gnu.org> writes:
>
>> On Wed, 2013-07-31 at 20:54 +0200, joakim@verona.se wrote:
>>> #make takes a loong time, much more than a normal emacs
>>> ./autogen.sh && ./configure && make
>>
>> I'm not familiar with building Emacs, but doesn't its build system
>> support parallel compilation (couldn't you run "make -j4" or whatever's
>> appropriate for your system to get a nice speedup)?
>>
>
> I think the slowness was during lisp compilation, and that didnt use to
> benefit from parallel compilation. I might try again though.

The slowness is during .el byte-code compilation (and partly autoload
generation), because the Makefile starts a new Emacs for every .el to be
compiled, and Guile Emacs starts very slow (about 10 seconds?) because
the "dumping" feature of Emacs is disabled, thus it loads even the
fundamental Elisp libraries from the ground up when started (the
executable is "barebones").  The loading of said fundamental Elisp
libraries is normally suppressed by using not a barebones executable,
but an executable that's generated by starting said barebones executable
once (*with* dumping capability), loading the files, then dumping.

(Yeah, Emacs actually supports dumping its memory image into a runnable
executable, see Elisp function `dump-emacs', but it's limited and
unusable for day-to-day usage, and only used during compilation to
generate this executable with pre-loaded Elisp libraries.)

I managed to inhibit .el compilation and autoload generation by screwing
around with the Makefiles and loadup.el; the result just causes more
headaches if you want to test Guile Emacs in a sane fashion, but it
basically works if you don't have a fancy .emacs, and allows to test
changes in the base C source (which is what I'm doing recently), so if
you have a similar use-case you can notify me and I'll post the hacky
patches somewhere.

Re: Guile-Emacs update

[Andy Wingo]

On Thu 01 Aug 2013 00:17, taylanbayirli@gmail.com (Taylan Ulrich B.) writes:

> the "dumping" feature of Emacs is disabled

Eventually Guile will support linking together multiple separately
compiled files into one ELF image.  (The object file format in the
development Guile branch is ELF -- we have our own linker and loader, so
we currently plan on using this format even on non-ELF platforms.)  That
should mostly provide the speedy loading that the dumping facility gives
to Emacs.  Loading a file would look for the appropriate entry point in
the image and load that.  There is still some runtime relocation and
initialization that needs to happen, but it should be possible to get
most of the advantages of the "dump" phase.

Andy
-- 
http://wingolog.org/

Re: Guile-Emacs update

[Eli Zaretskii]

> From: Andy Wingo <wingo@pobox.com>
> Date: Sat, 07 Sep 2013 11:29:10 +0200
> Cc: guile-user@gnu.org, BT Templeton <bt@hcoop.net>, joakim@verona.se,
> 	emacs-devel@gnu.org
> 
> On Thu 01 Aug 2013 00:17, taylanbayirli@gmail.com (Taylan Ulrich B.) writes:
> 
> > the "dumping" feature of Emacs is disabled
> 
> Eventually Guile will support linking together multiple separately
> compiled files into one ELF image.  (The object file format in the
> development Guile branch is ELF -- we have our own linker and loader, so
> we currently plan on using this format even on non-ELF platforms.)

Was this ever tested on any non-ELF platform, such as MinGW?

Re: Guile-Emacs update

[Andy Wingo]

On Sat 07 Sep 2013 12:02, Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andy Wingo <wingo@pobox.com>
>> Date: Sat, 07 Sep 2013 11:29:10 +0200
>> Cc: guile-user@gnu.org, BT Templeton <bt@hcoop.net>, joakim@verona.se,
>> 	emacs-devel@gnu.org
>> 
>> On Thu 01 Aug 2013 00:17, taylanbayirli@gmail.com (Taylan Ulrich B.) writes:
>> 
>> > the "dumping" feature of Emacs is disabled
>> 
>> Eventually Guile will support linking together multiple separately
>> compiled files into one ELF image.  (The object file format in the
>> development Guile branch is ELF -- we have our own linker and loader, so
>> we currently plan on using this format even on non-ELF platforms.)
>
> Was this ever tested on any non-ELF platform, such as MinGW?

It just landed a couple months ago, so the time for that hasn't really
come yet.  But it doesn't rely on any interfaces of the platform, so I
don't anticipate problems.

Andy
-- 
http://wingolog.org/