Bug in emacs

Bug in emacs

[Jean Pierre Lemue]

[-- Attachment #1.1: Type: text/plain, Size: 789 bytes --]

I have a big bug on emacs. I can't resolve it.

When I compile a "*.el" (not all of them) I get this message :

Compiling file c:/Program Files/emacs/bin/atteindre.el at Tue Oct 07
14:37:27 2003
  !! Wrong number of arguments ((#[nil "\300c\207" ["$\\infty "] 1 nil nil]
1))

Thus all the lisp functions that are in this file are compiled with good
result and this file was compiled with success before monday 07/10/03.

More, since the same day:
I can't open tex file with auctex with the following message:
When I open an "*.tex" I get:

File mode specification error: (wrong-number-of-arguments #[nil "\300c\207" ["-\\infty "] 1 nil nil] 1)


The word "infty" in the error's message appears because this bug becomes while I used a macro with "infty" as input.
Thanks

[-- Attachment #1.2: Type: text/html, Size: 1491 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs

Re: Bug in emacs

[era]

On Tue, 7 Oct 2003 15:44:30 +0200, Jean Pierre Lemue
<jp-lemue@club-internet.fr> posted to gmane.emacs.bugs:
 > I have a big bug on emacs. I can't resolve it.

If you have macros which influence the meaning of forms you are
compiling, the macro needs to be loaded before you compile. What you
are reporting seems like a typical symptom of failing to load the
macro in question before compiling.

A workaround would be to make sure you eval the macro definition
before compiling.

I'm not sure what the bug really is. Perhaps it would be useful to get
a warning when compiling / evaling something when a macro +is+ in
effect and the file you are compiling is not pulling it in properly?
Then at least you get a hint to fix it while you still can, while
those who do it right will not experience any adverse effects.

/* era */

-- 
The email address era     the contact information   Just for kicks, imagine
at iki dot fi is heavily  link on my home page at   what it's like to get
spam filtered.  If you    <http://www.iki.fi/era/>  500 pieces of spam for
want to reach me, see     instead.                  each wanted message.

Re: Bug in emacs

[Kevin Rodgers]

era@iki.fi wrote:

> If you have macros which influence the meaning of forms you are
> compiling, the macro needs to be loaded before you compile. What you
> are reporting seems like a typical symptom of failing to load the
> macro in question before compiling.
> 
> A workaround would be to make sure you eval the macro definition
> before compiling.
> 
> I'm not sure what the bug really is. Perhaps it would be useful to get
> a warning when compiling / evaling something when a macro +is+ in
> effect and the file you are compiling is not pulling it in properly?
> Then at least you get a hint to fix it while you still can, while
> those who do it right will not experience any adverse effects.


When the compiler comes across a (function arg ...) form, either the
function is defined or it isn't.  If it's defined, either as a function
or a macro, all is well.  If it's not defined, the compiler can't know
whether it is a function or a macro and assumes it's a function.  A
macro can't be "in effect" if it's file was not loaded "properly".

The compiler does issue warnings when it encounters an undefined
macro/function:

While compiling the end of the data in file /home/kevinr/emacs/foo.el:
   ** the function bar is not known to be defined.

-- 
Kevin Rodgers

Re: Bug in emacs

[era]

On Mon, 13 Oct 2003 10:28:06 -0600, Kevin Rodgers <ihs_4664@yahoo.com>
posted to gmane.emacs.bugs:
 > era@iki.fi wrote:
 >> I'm not sure what the bug really is. Perhaps it would be useful to
 >> get a warning when compiling / evaling something when a macro +is+
 >> in effect and the file you are compiling is not pulling it in
 >> properly? Then at least you get a hint to fix it while you still
 >> can, while those who do it right will not experience any adverse
 >> effects.
 > When the compiler comes across a (function arg ...) form, either the
 > function is defined or it isn't.  If it's defined, either as a function
 > or a macro, all is well.  If it's not defined, the compiler can't know
 > whether it is a function or a macro and assumes it's a function.  A
 > macro can't be "in effect" if it's file was not loaded "properly".

What I'm saying is that macro expansion during compilation could
trigger a warning if the macro is not loaded properly by the code
which is being compiled. This is a fuzzy idea at best, but I was
thinking of something like:

  0. Maintain a buffer of per-byte-compilation macros

  1. When a new byte compilation starts, flush the buffer of macros.
     Set a flag to indicate that byte compilation is in progress. (I
     would kind of assume that this already happens but I haven't
     checked.)

  2. When byte compilation is taking place and a macro is defined, add
     the macro to the buffer of per-byte-compilation macros with the
     property "defined during compilation".

  3. When byte compilation is taking place and a macro is expanded,
     check in the buffer, and if the macro is not listed as having
     been defined during this compilation, throw a warning.

  4. When byte compilation finishes, the flag to indicate that byte
     compilation is taking place will need to be taken down, of
     course.

This obviously requires already-loaded requires etc to be performed
anew during byte compilation, or some cunning caching of the buffer
which keeps track of when and where a macro was defined (maybe make it
global and permanent per session instead of per-compilation?)

 > The compiler does issue warnings when it encounters an undefined
 > macro/function:
 > While compiling the end of the data in file /home/kevinr/emacs/foo.el:
 >    ** the function bar is not known to be defined.

So now you'd also get something like

  While compiling toplevel forms:
    ** reference to macro `foo' which was not defined during compilation

as a warning that the code may not execute correctly on a system where
the macro is not somehow automatically loaded before the compiled code
will be executed. (As a bonus maybe the `foo' could be clickable so
you could look at the macro's documentation and maybe find out where
it is defined.)

/* era */

-- 
The email address era     the contact information   Just for kicks, imagine
at iki dot fi is heavily  link on my home page at   what it's like to get
spam filtered.  If you    <http://www.iki.fi/era/>  500 pieces of spam for
want to reach me, see     instead.                  each wanted message.

Re: Bug in emacs

[era]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 4050 bytes --]

On 14 Oct 2003 09:05:20 +0300, era@iki.fi posted to gmane.emacs.bugs:
 > On Mon, 13 Oct 2003 10:28:06 -0600, Kevin Rodgers <ihs_4664@yahoo.com>
 > posted to gmane.emacs.bugs:
 >> era@iki.fi wrote:
 >>> I'm not sure what the bug really is. Perhaps it would be useful to
 >>> get a warning when compiling / evaling something when a macro +is+
 >>> in effect and the file you are compiling is not pulling it in
 >>> properly? Then at least you get a hint to fix it while you still
 >>> can, while those who do it right will not experience any adverse
 >>> effects.
 >> When the compiler comes across a (function arg ...) form, either the
 >> function is defined or it isn't.  If it's defined, either as a function
 >> or a macro, all is well.  If it's not defined, the compiler can't know
 >> whether it is a function or a macro and assumes it's a function.  A
 >> macro can't be "in effect" if it's file was not loaded "properly".
 > What I'm saying is that macro expansion during compilation could
 > trigger a warning if the macro is not loaded properly by the code
 > which is being compiled.

Oog, I got this backwards. (Thanks to RMS for pointing out my error in
private mail.) The problem is that when a macro is +not+ defined when
code is byte-compiled, the compiler assumes it's a function call; then
when the compiled code is executed, and the macro +is+ defined, you
get an error.

The following example is hopefully representative, although I'm not
sure under what circumstances the dreaded "wrong number of arguments"
error is triggered -- couldn't quickly reproduce that here.

;;; trinket.el --- test case for macro error
;;
;; Steps to repeat:
;;
;;  0. Start fresh copy of Emacs
;;  1. Save this file as /tmp/trinket.el and byte-compile into /tmp/trinket.elc
;;  2. Save /tmp/macro.el (inlined below) and byte-compile into /tmp/macro.elc
;;  3. M-: (load-file "/tmp/trinket.elc")
;;  4. M-: (trinket)
;;     => ERROR: Symbol's function definition is void: f (as expected)
;;  5. Visit macro.el and eval the macro definition
;;  6. M-: (trinket)
;;     => ERROR: Invalid function: (macro lambda (x n) (\` (let ((m (make-list (\, n) (quote y)))) (while m (message (\, x)) (setq m (cdr m))))))
;;  7. Restart Emacs
;;  8. M-: (load-file "/tmp/macro.elc")
;;  9. M-: (load-file "/tmp/trinket.elc")
;; 10. M-: (trinket)
;;    => ERROR: Invalid function: (macro . #[(x n) "ÂÃÄ\bÅBBDCÆÃÇ	DÈBBBE‡" [n x let m make-list ((quote y)) while message ((setq m (cdr m)))] 6])

(defun trinket ()
  (f "This is neat, isn't it?" 4) )

;; Inlined copy of macro.el --- extract into /tmp/macro.el and byte-compile
;?;?; macro.el --- supplementary file for trinket.el
;?;
;?;(defmacro f (x n)
;?;  `(let ((m (make-list ,n 'y)))
;?;     (while m (message ,x) (setq m (cdr m))) ))
;?;
;?;?; macro.el ends here

;;; trinket.el ends here

The main problem I guess is that the error message with the porridge
of byte-compiled opcodes isn't exactly helpful, and that sometimes you
have no idea which macro is causing it, and thus what defined it and
when.

So the upgraded wishlist suggestion would be to check whether a
compiled opcode which is about to be executed is shadowed by a macro,
and in that case display a warning identifying the macro in question.
(As per the message I got from RMS, all macros are expanded at
compilation time, so byte-compiled code should never refer to any
macros, if I got this right.)

Still, I think my earlier suggestion would be useful for preventing
this sort of error, i.e. when performing macro expansion at byte
compilation time, warn if the code in question did not manage to
define the macro properly, either by including it directly, or
requiring / loading / whatever a file which contains the definition.

/* era */

-- 
The email address era     the contact information   Just for kicks, imagine
at iki dot fi is heavily  link on my home page at   what it's like to get
spam filtered.  If you    <http://www.iki.fi/era/>  500 pieces of spam for
want to reach me, see     instead.                  each wanted message.

Re: Bug in emacs

[era]

On 16 Oct 2003 10:59:30 +0300, era@iki.fi posted to gmane.emacs.bugs:
 > Oog, I got this backwards. (Thanks to RMS for pointing out my error in
 > private mail.) The problem is that when a macro is +not+ defined when
 > code is byte-compiled, the compiler assumes it's a function call; then
 > when the compiled code is executed, and the macro +is+ defined, you
 > get an error.

And just to elaborate, one semi-important aspect of this is that it is
hard to be sure that you are (require)ing everything you should, and
that getting a warning when you are compiling code which uses a macro
which is not properly required by that code would be a useful aid for
developers.

A related problem which I imagine could be tackled with the same
mechanism is that if you happen to have loaded or required a library
which your code uses, but the code does not properly load or require
it, you don't get any warning at compilation time currently. It would
be useful to get a warning in this case, too.

Down the line, you could even have a function which figures out and
automatically inserts adequate (require) and (load) forms in your
code. (Figuring out whether a library provides something you would
like to require is annoying drudgery too.)

/* era */

-- 
The email address era     the contact information   Just for kicks, imagine
at iki dot fi is heavily  link on my home page at   what it's like to get
spam filtered.  If you    <http://www.iki.fi/era/>  500 pieces of spam for
want to reach me, see     instead.                  each wanted message.

Bug in emacs

[Eric J Russell]

Hello,

I found something in the emacs psychiatrist that doesn't make sense:

"Maybe you should consult a doctor of medicine, I am a psychiatrist."

In fact, a psychiatrist is by definition also a doctor of medicine along 
with being a psychologist.

Perhaps the string should instead read "Maybe you should consult a 
doctor of medicine. I am a psychologist." -- and the name of the feature 
should be "emacs psychologist"

Best regards,

Eric Russell

Re: Bug in emacs

[Richard M. Stallman]

    Perhaps the string should instead read "Maybe you should consult a 
    doctor of medicine. I am a psychologist." -- and the name of the feature 
    should be "emacs psychologist"

It is already supposed to be called "psychologist"; those two
occurrences of "psychiatrist" are errors.  I will fix them.
Thanks.