VC-SVN problem

VC-SVN problem

[Shawn Boyette]

Sorry if this should have gone to bug-gnu-emacs; I use CVS builds and
thus figured that devel would be more appropriate.

Short and sweet problem: for roughly the past 1.5 weeks, attempting to
commit any file under subversion control results in failure. The
messages are as follows:

  Wrote /home/mdxi/web/dict/kdict/edit/edit.xi [2 times]
  Loading log-edit...
  Loading easy-mmode...done
  Loading easymenu...done
  Loading log-edit...done
  Mark set
  Press C-c C-c when you are done editing.
  Enter a change comment.  Type C-c C-c when done
  Checking in /home/mdxi/web/dict/kdict/edit/edit.xi...
  vc-svn-checkin: Symbol's function definition is void: list*

The check-in is not successful, and the *VC-log* window is not
removed. This isn't a killer, obviously, but it's pretty dang annoying. 

I hate to just complain about things, but I've just started studying
my copy of the elisp intro book, so this one's pretty much over my
head.

-- 
Shawn Boyette
mdxi@collapsar.net

Re: VC-SVN problem

[Karl Fogel]

Shawn Boyette <mdxi@collapsar.net> writes:
> Sorry if this should have gone to bug-gnu-emacs; I use CVS builds and
> thus figured that devel would be more appropriate.
> 
> Short and sweet problem: for roughly the past 1.5 weeks, attempting to
> commit any file under subversion control results in failure. The
> messages are as follows:
> 
>   Wrote /home/mdxi/web/dict/kdict/edit/edit.xi [2 times]
>   Loading log-edit...
>   Loading easy-mmode...done
>   Loading easymenu...done
>   Loading log-edit...done
>   Mark set
>   Press C-c C-c when you are done editing.
>   Enter a change comment.  Type C-c C-c when done
>   Checking in /home/mdxi/web/dict/kdict/edit/edit.xi...
>   vc-svn-checkin: Symbol's function definition is void: list*
> 
> The check-in is not successful, and the *VC-log* window is not
> removed. This isn't a killer, obviously, but it's pretty dang annoying. 
> 
> I hate to just complain about things, but I've just started studying
> my copy of the elisp intro book, so this one's pretty much over my
> head.

I believe the problem is that 'list*' is in the 'cl' package, but
vc-svn.el doesn't have

   (require 'cl)

anywhere.  For some people it won't be an error, because they already
have 'cl' loaded for some other reason; but in a pristine Emacs like
yours, it fails.

Stefan, would you rather require 'cl', or just rewrite
'vc-svn-checkin' to not use 'list*'?

Shawn, in the meantime, see if putting 

   (require 'cl)

in your .emacs fixes the problem.

-Karl

Re: VC-SVN problem

[Shawn Boyette]

On Fri, May 07, 2004 at 02:58:17PM -0500, Karl Fogel wrote:

> Shawn, in the meantime, see if putting 
> 
>    (require 'cl)
> 
> in your .emacs fixes the problem.

Indeed it does; many thanks.

-- 
Shawn Boyette
mdxi@collapsar.net

Re: VC-SVN problem

[Karl Fogel]

Shawn Boyette <mdxi@collapsar.net> wrote regarding vc-svn.el:
> > Shawn, in the meantime, see if putting 
> > 
> >    (require 'cl)
> > 
> > in your .emacs fixes the problem.
> 
> Indeed it does; many thanks.

So, I'd like to fix this in vc-svn.el, in the simplest way: by adding
(require 'cl) so that 'list*' is available.

But that brings me to a larger question, which is, what *are* the
criteria for committing to files in Emacs?  I've been trying to grok
the answer by watching this list, but that's not working as well as
I'd hoped.

I'm not talking about controversial new features here.  Clearly, those
need to be discussed on the list, and a consensus should emerge,
before they are checked in.  I'm just talking about bugfixes (like
this one to vc-svn.el) and minor enhancements.

In some other projects, a committer can commit anywhere, according to
their judgement.  If a change is wrong, or non-optimal, this can be
brought up on the list later and the problem can be resolved with a
new change, or an explanation of why the old change really is okay, or
whatever.  In other projects, voting is required; in still other
projects, approvial by an area maintainer is required.

These policies are usually spelled out in some file called HACKING or
DEVEL or MAINTENANCE, in the top level of the project.  There are no
such written guidelines for Emacs, as far as I can tell (?).  The only
thing I've been able to glean from lurking is that

   a) RMS seems to have the final say
   b) certain area maintainers commit without discussion

I haven't rethreaded this message, because it might be that the answer
is simple and doesn't need to happen in a new thread.  (Maybe there's
a written guideline, and I just missed it somehow?)

Anyway, to return to my original question: is it okay to commit this
change to vc-svn.el?

Thanks,
-Karl

P.S. Is emacs-commit unused now?  It appears to be all spam since the
     beginning of this year, according to the archives, though there
     were real commit mails before then.  The exact same situation
     seems to hold for emacs-diffs, which makes me wonder if they're
     not two names for the same list...

     http://mail.gnu.org/archive/html/emacs-commit/
     http://mail.gnu.org/archive/html/emacs-diffs/

Re: VC-SVN problem

[John Paul Wallington]

> So, I'd like to fix this in vc-svn.el, in the simplest way: by adding
> (require 'cl) so that 'list*' is available.

Just checking: do you mean (eval-when-compile (require 'cl)) ?

(The cl package defines a compiler macro for `list*', and the elisp
manual's coding conventions say not to load cl at runtime.)

Re: VC-SVN problem

[Jim Blandy]

John Paul Wallington <jpw@gnu.org> writes:

> > So, I'd like to fix this in vc-svn.el, in the simplest way: by adding
> > (require 'cl) so that 'list*' is available.
> 
> Just checking: do you mean (eval-when-compile (require 'cl)) ?
> 
> (The cl package defines a compiler macro for `list*', and the elisp
> manual's coding conventions say not to load cl at runtime.)

I've gotta be missing something obvious:

What do you do if your package actually uses functions from CL, not
just macros?  Then CL must be loaded at runtime.  Are such packages
simply unsuitable for inclusion in the Emacs distribution?

Re: VC-SVN problem

[John Paul Wallington]

> > Just checking: do you mean (eval-when-compile (require 'cl)) ?
> > 
> > (The cl package defines a compiler macro for `list*', and the elisp
> > manual's coding conventions say not to load cl at runtime.)
> 
> I've gotta be missing something obvious:

I don't think so.

> What do you do if your package actually uses functions from CL, not
> just macros?  Then CL must be loaded at runtime.

Well, some functions in the cl library have corresponding compiler
macros and you can use those without loading cl at runtime in addition
to its normal macros.  Also, by default the byte compiler issues
"function from cl package called at runtime" warnings now so
inadvertent use at runtime is easy to detect.

I guess whether to rewrite an existing package to avoid runtime use of
cl or to follow those conventions when developing a new package is up
to the maintainers of that package.

> Are such packages simply unsuitable for inclusion in the Emacs
> distribution?

Yes, I believe so.

Earlier in this thread RMS said that it's not acceptable for any
package in Emacs to require cl at runtime:
http://mail.gnu.org/archive/html/emacs-devel/2004-05/msg00506.html

Re: VC-SVN problem

[Richard Stallman]

    What do you do if your package actually uses functions from CL, not
    just macros?  Then CL must be loaded at runtime.  Are such packages
    simply unsuitable for inclusion in the Emacs distribution?

They are unsuitable unless they are changed not to use those functions.

Re: VC-SVN problem

[Miles Bader]

On Sat, May 08, 2004 at 07:16:30PM -0500, Karl Fogel wrote:
> But that brings me to a larger question, which is, what *are* the
> criteria for committing to files in Emacs?  I've been trying to grok
> the answer by watching this list, but that's not working as well as
> I'd hoped.

I think it's generally `If you're not sure, ask.'

Luckily there seem to be no bozos with commit access, so this seems to work
pretty well.  Everybody starts out feeling nervous about what's OK to commit,
and so ask about everything, and then gradually become more confident and
start committing without asking -- and by that time their judgement has
become good enough that they don't screw things up.

[Sort of like `If you have to ask the price, you can't afford it.' :-]

-Miles
-- 
Saa, shall we dance?  (from a dance-class advertisement)

Re: VC-SVN problem

[Thien-Thi Nguyen]

Karl Fogel <kfogel@floss.red-bean.com> writes:

   I haven't rethreaded this message, because it might be that the
   answer is simple and doesn't need to happen in a new thread.

"the answer is simple: there is no simple answer!"

(basically, if you were to write a HACKING file, it would
eventually boil down to this, after first starting as a general
policy, then over time being revised to add exception upon ever
higher-ordered exception. :-)

thi

Re: VC-SVN problem

[Richard Stallman]

    So, I'd like to fix this in vc-svn.el, in the simplest way: by adding
    (require 'cl) so that 'list*' is available.

Please don't do that.  It's not acceptable for any package in Emacs to
do that.  The CL functions are not standard parts of the Emacs Lisp
language, and the user may have defined the same names in some other
way.

Re: VC-SVN problem

[Karl Fogel]

Richard Stallman <rms@gnu.org> writes:
>     So, I'd like to fix this in vc-svn.el, in the simplest way: by adding
>     (require 'cl) so that 'list*' is available.
> 
> Please don't do that.  It's not acceptable for any package in Emacs to
> do that.  The CL functions are not standard parts of the Emacs Lisp
> language, and the user may have defined the same names in some other
> way.

Thanks, I'll remember that.  John Paul Wallington's suggestion was to
use use (eval-when-compile (require 'cl)) instead.

Re: VC-SVN problem

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     So, I'd like to fix this in vc-svn.el, in the simplest way: by adding
>     (require 'cl) so that 'list*' is available.
> 
> Please don't do that.  It's not acceptable for any package in Emacs to
> do that.  The CL functions are not standard parts of the Emacs Lisp
> language, and the user may have defined the same names in some other
> way.

Usually
(eval-when-compile '(require 'cl))

should be sufficient, and it is what is recommended for that
functionality in the Elisp manual.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: VC-SVN problem

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> Richard Stallman <rms@gnu.org> writes:
> 
> >     So, I'd like to fix this in vc-svn.el, in the simplest way: by adding
> >     (require 'cl) so that 'list*' is available.
> > 
> > Please don't do that.  It's not acceptable for any package in Emacs to
> > do that.  The CL functions are not standard parts of the Emacs Lisp
> > language, and the user may have defined the same names in some other
> > way.
> 
> Usually
> (eval-when-compile '(require 'cl))
> 
> should be sufficient, and it is what is recommended for that
> functionality in the Elisp manual.

Ok, I goofed.  Spurious quoting.  Here is the original passage from
the manual:

   * Please don't require the `cl' package of Common Lisp extensions at
     run time.  Use of this package is optional, and it is not part of
     the standard Emacs namespace.  If your package loads `cl' at run
     time, that could cause name clashes for users who don't use that
     package.

     However, there is no problem with using the `cl' package at compile
     time, for the sake of macros.  You do that like this:

          (eval-when-compile (require 'cl))



-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: VC-SVN problem

[Richard Stallman]

    Stefan, would you rather require 'cl', or just rewrite
    'vc-svn-checkin' to not use 'list*'?

Packages in Emacs are not supposed to require cl at run time.
Users can have their own definitions for the function names
that CL defines, and they won't want CL to be loaded.

Re: VC-SVN problem

[Kevin Rodgers]

Karl Fogel wrote:
 > Stefan, would you rather require 'cl', or just rewrite
 > 'vc-svn-checkin' to not use 'list*'?

Wouldn't the second option be better?

| list* is a compiled Lisp function in `cl'.
| (list* ARG &rest REST)
|
| Return a new list with specified args as elements, cons'd to last arg.
| Thus, `(list* A B C D)' is equivalent to `(nconc (list A B C) D)', or to
| `(cons A (cons B (cons C D)))'.

-- 
Kevin Rodgers

Re: VC-SVN problem

[Stefan Monnier]

>> Stefan, would you rather require 'cl', or just rewrite
>> 'vc-svn-checkin' to not use 'list*'?
> Wouldn't the second option be better?

Why?  The byte-compiler will turn it into the equivalent calls to `cons'.
`list*' is a pretty simple a common list operation.  Actually it's
predefined in Emacs Lisp, once under the name backquote-list*-function
and once under the name backquote-list*-macro.


        Stefan

Re: VC-SVN problem

[Miles Bader]

On Mon, May 10, 2004 at 03:16:04PM -0400, Stefan Monnier wrote:
> `list*' is a pretty simple a common list operation.  Actually it's
> predefined in Emacs Lisp, once under the name backquote-list*-function
> and once under the name backquote-list*-macro.

Actually this is one of those functions I've wished for a long time was in
the emacs core.

Any reason why not?  It's a very simple function, has no `issues' that I can
see, and quite useful...

Since as you say it's _already_ being defined under a different name in
backquote, it might even same some space.

-Miles
-- 
Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.