Question

Question

[Carsten Dominik]

Hi everyone,

I am on the verge to install a new version of Org mode into the Emacs  
tree.
This version includes org-babel, a system to work with source code
snippets embedded in files, for documentation purposes, but also
for evaluating them in a reproducible research way.

For supporting different languages, we will have a few emacs lisp
files which should not be compiled because the have dependencies on
code that is not present in Emacs.  I.e. they do something like

    (require 'slime)

and call lots of functions from this package.

I think the best way it to leave these files
uncompiled.  Is this acceptable?  If yes, how do
I exclude them from compilation in the standard
Emacs build process.

How would I do this?


- Carsten

Re: Question

[Juanma Barranquero]

On Fri, Jul 2, 2010 at 06:15, Carsten Dominik <carsten.dominik@gmail.com> wrote:

> For supporting different languages, we will have a few emacs lisp
> files which should not be compiled because the have dependencies on
> code that is not present in Emacs.  I.e. they do something like
>
>   (require 'slime)
>
> and call lots of functions from this package.

Are these compile-time dependencies?

> I think the best way it to leave these files
> uncompiled.  Is this acceptable?

There are at least 82 .el files in lisp/** than are not compiled.

> If yes, how do
> I exclude them from compilation in the standard
> Emacs build process.

If you just want for the files not being byte-compiled, you can use

  -*- no-byte-compile: t -*-

or

  ;; Local Variables:
  ;; no-byte-compile: t
  ;; End:

but, are these packages usable when non-compiled? Because if they're
not, they should simply be excluded from the Emacs tree, I think.

    Juanma

Re: Question

[Lennart Borgman]

On Fri, Jul 2, 2010 at 6:15 AM, Carsten Dominik
<carsten.dominik@gmail.com> wrote:
> Hi everyone,
>
> I am on the verge to install a new version of Org mode into the Emacs tree.
> This version includes org-babel, a system to work with source code
> snippets embedded in files, for documentation purposes, but also
> for evaluating them in a reproducible research way.
>
> For supporting different languages, we will have a few emacs lisp
> files which should not be compiled because the have dependencies on
> code that is not present in Emacs.  I.e. they do something like
>
>   (require 'slime)
>
> and call lots of functions from this package.
>
> I think the best way it to leave these files
> uncompiled.  Is this acceptable?  If yes, how do
> I exclude them from compilation in the standard
> Emacs build process.

Why not use (require 'slime nil t)?

Question

[Stephen J. Turnbull]

Carsten Dominik writes:

 > For supporting different languages, we will have a few emacs lisp
 > files which should not be compiled because the have dependencies on
 > code that is not present in Emacs.  I.e. they do something like
 > 
 >     (require 'slime)

This is not a problem, unless it's within `eval-when-compile'.  Go
ahead and compile it otherwise.

 > and call lots of functions from this package.

For *functions*, this isn't a problem, either.  However, *macros* from
the slime library must be defined at compile time, because Emacs byte
code doesn't know how to expand and reevaluate macros.  (IIRC, anyway,
for sure XEmacs's bytecode interpreter can't do that.)  Instead, the
macro is expanded, then the expansion is compiled at compile time.

 > I think the best way it to leave these files uncompiled.

I feel sick ... ok, it got better.  No, this is rarely a good idea.
If you have only functions, it's pointless.  If you have macros, then
remember that macros get evaluated twice: once to generate code, and
once to evaluate the generated code.  The function that generates the
expansion is rarely very efficient because it is expected to be
expanded once at compile time.  Instead it is normally written to be
as straightforward an expression of the desired expansion code as
possible.  IOW, you're likely to impose a perceptible performance hit
on those users.

Since org-mode is now part of Emacs, third party packages can assume
it will be available, and if leaving files uncompiled seems your only
option, then it's probably best all-around to contribute that code to
the third-party package, and have it compiled there.

Re: Question

[Richard Stallman]

    For supporting different languages, we will have a few emacs lisp
    files which should not be compiled because the have dependencies on
    code that is not present in Emacs.  I.e. they do something like

	(require 'slime)

Please don't install any files that depend on code not in Emacs.

(Why is that code not in Emacs?  Have people already considered
whether to install it?)

Slime

[Harald Hanche-Olsen]

+ Richard Stallman <rms@gnu.org>:

> (Why is [slime] not in Emacs?  Have people already considered
> whether to install it?)

Perhaps because it is so closely integrated with the swank backend?
You would have to include both for it to make sense including slime.
Note that the swank protocol is still evolving, so at the present time
distributing the slime front end separately from the swank backend
seems to make little sense.

(For those unfamiliar with slime: Slime (Superior Lisp Interaction
Mode for Emacs) refers both to the whole package and to the front end
running in emacs. Swank, as I said, runs in the client lisp. And the
whole package provides a nice integrated development environment for
(mostly common) lisp.

- Harald

Re: Slime

[Chong Yidong]

Harald Hanche-Olsen <hanche@math.ntnu.no> writes:

> + Richard Stallman <rms@gnu.org>:
>
>> (Why is [slime] not in Emacs?  Have people already considered
>> whether to install it?)
>
> Perhaps because it is so closely integrated with the swank backend?
> You would have to include both for it to make sense including slime.
> Note that the swank protocol is still evolving, so at the present time
> distributing the slime front end separately from the swank backend
> seems to make little sense.

I am interested in distributing SLIME as a package for Emacs 24 (it's
already on the tromey.com package archive).  However, although Eric
Marsden and Helmut Eller have copyright assignments, I don't know the
list of other contributors.  (Helmut, could you let me know?)

Re: Slime

[Helmut Eller]

* Chong Yidong [2010-07-02 13:35] writes:

> Harald Hanche-Olsen <hanche@math.ntnu.no> writes:
>
>> + Richard Stallman <rms@gnu.org>:
>>
>>> (Why is [slime] not in Emacs?  Have people already considered
>>> whether to install it?)
>>
>> Perhaps because it is so closely integrated with the swank backend?
>> You would have to include both for it to make sense including slime.
>> Note that the swank protocol is still evolving, so at the present time
>> distributing the slime front end separately from the swank backend
>> seems to make little sense.
>
> I am interested in distributing SLIME as a package for Emacs 24 (it's
> already on the tromey.com package archive).  However, although Eric
> Marsden and Helmut Eller have copyright assignments, I don't know the
> list of other contributors.  (Helmut, could you let me know?)

It's a very long list (more than 100 people):
http://common-lisp.net/project/slime/doc/html/Credits.html#Credits

Of course, most contributed only a few lines.

Helmut

Re: Question

[Carsten Dominik]

OK, thanks for the input everyone.

We'll think about and implement appropriate solutions.
Looking at the files again, I actually think that we can make
them compile with a small number of declare-function statements.

Thanks!

- Carsten

On Jul 2, 2010, at 1:45 PM, Stephen J. Turnbull wrote:

> Carsten Dominik writes:
>
>> For supporting different languages, we will have a few emacs lisp
>> files which should not be compiled because the have dependencies on
>> code that is not present in Emacs.  I.e. they do something like
>>
>>    (require 'slime)
>
> This is not a problem, unless it's within `eval-when-compile'.  Go
> ahead and compile it otherwise.
>
>> and call lots of functions from this package.
>
> For *functions*, this isn't a problem, either.  However, *macros* from
> the slime library must be defined at compile time, because Emacs byte
> code doesn't know how to expand and reevaluate macros.  (IIRC, anyway,
> for sure XEmacs's bytecode interpreter can't do that.)  Instead, the
> macro is expanded, then the expansion is compiled at compile time.
>
>> I think the best way it to leave these files uncompiled.
>
> I feel sick ... ok, it got better.  No, this is rarely a good idea.
> If you have only functions, it's pointless.  If you have macros, then
> remember that macros get evaluated twice: once to generate code, and
> once to evaluate the generated code.  The function that generates the
> expansion is rarely very efficient because it is expected to be
> expanded once at compile time.  Instead it is normally written to be
> as straightforward an expression of the desired expansion code as
> possible.  IOW, you're likely to impose a perceptible performance hit
> on those users.
>
> Since org-mode is now part of Emacs, third party packages can assume
> it will be available, and if leaving files uncompiled seems your only
> option, then it's probably best all-around to contribute that code to
> the third-party package, and have it compiled there.
>