lexbind

lexbind

[Richard Stallman]

The recent bytecomp bug, fixed (mostly) by renaming some local
variables, gives an argument for installing the lexbind branch.
The main issues about it are

(1) What are good ways to declare certain variables dynamic?

(2) What packages will break?

I think we have made considerable advances in the past year in
reducing what will break.

Re: lexbind

[Stefan Monnier]

> The recent bytecomp bug, fixed (mostly) by renaming some local
> variables, gives an argument for installing the lexbind branch.
> The main issues about it are

> (1) What are good ways to declare certain variables dynamic?

`defvar' is the standard way to do that.  CL offers ways to do it inside
`declare' macro calls, but I don't think it's an important refinement.

> (2) What packages will break?

Hopefully none since the lexbind branch only uses lexical-binding when
the code asks for it.


        Stefan

Re: lexbind

[Richard Stallman]

    > (1) What are good ways to declare certain variables dynamic?

    `defvar' is the standard way to do that.  CL offers ways to do it inside
    `declare' macro calls, but I don't think it's an important refinement.

I am not sure `defvar' is enough.  The reason is that using it to fix
existing packages may require renaming.

    > (2) What packages will break?

    Hopefully none since the lexbind branch only uses lexical-binding when
    the code asks for it.

I did not realize that.  In that case, installing it won't break
anything.

Re: lexbind

[Stefan Monnier]

>> (1) What are good ways to declare certain variables dynamic?
>     `defvar' is the standard way to do that.  CL offers ways to do it inside
>     `declare' macro calls, but I don't think it's an important refinement.

> I am not sure `defvar' is enough.  The reason is that using it to fix
> existing packages may require renaming.

Yes, it may require renaming.  It's usually not a big deal, tho.

>> (2) What packages will break?

>     Hopefully none since the lexbind branch only uses lexical-binding when
>     the code asks for it.

> I did not realize that.  In that case, installing it won't break
> anything.

Modulo bugs, of course,


        Stefan

Re: lexbind

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> (1) What are good ways to declare certain variables dynamic?
>>     `defvar' is the standard way to do that.  CL offers ways to do it inside
>>     `declare' macro calls, but I don't think it's an important refinement.
>
>> I am not sure `defvar' is enough.  The reason is that using it to fix
>> existing packages may require renaming.
>
> Yes, it may require renaming.  It's usually not a big deal, tho.
>
>>> (2) What packages will break?
>
>>     Hopefully none since the lexbind branch only uses lexical-binding when
>>     the code asks for it.
>
>> I did not realize that.  In that case, installing it won't break
>> anything.
>
> Modulo bugs, of course,

Could you list the advantages and the principal difference, and the kind
of breakage to expect?  If most developers can agree this is something
worth having in the long run, then we should make a plan when to
integrate it.  I don't have a feeling yet for the 23.1 time/feature
frame our maintainers are aiming for, namely how early we are in the
feature admission phase.

I certainly would like to have a replacement for the ugly (and
non-byte-compiled)

`(lambda (...) ... ',value )

constructs necessary at various places.  Would lexbind help?  How?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: lexbind

[Stefan Monnier]

> I certainly would like to have a replacement for the ugly (and
> non-byte-compiled)

> `(lambda (...) ... ',value )

You can already use `lexical-let' for that.  In a certain sense, the
`lexbind' branch makes let-binding behave like lexical-let by default.


        Stefan

Re: lexbind

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I certainly would like to have a replacement for the ugly (and
>> non-byte-compiled)
>
>> `(lambda (...) ... ',value )
>
> You can already use `lexical-let' for that.  In a certain sense, the
> `lexbind' branch makes let-binding behave like lexical-let by default.

It does not look pretty in the source.  Are function parameters let or
lexical-let to their values in lexbind?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: lexbind

[Miles Bader]

David Kastrup <dak@gnu.org> writes:
> It does not look pretty in the source.  Are function parameters let or
> lexical-let to their values in lexbind?

lexically-bound (presuming the source file is tagged "lexically-bound").

-Miles

-- 
Accord, n. Harmony.

Re: lexbind

[paul r]

>
>  >     Hopefully none since the lexbind branch only uses lexical-binding when
>  >     the code asks for it.

will this allow lexical binding for defun ? Currently defun binds
function to symbol globaly, so it can not be used as a local-only
function helper, for instance in a tail-recursion.

Re: lexbind

[Stefan Monnier]

>> >     Hopefully none since the lexbind branch only uses lexical-binding when
>> >     the code asks for it.

> will this allow lexical binding for defun ?

No.  Just like there's no dynamically-scoped binding for functions,
I don't know of any plans to have lexically-scoped bindings
for functions.

> Currently defun binds function to symbol globaly, so it can not be
> used as a local-only function helper, for instance in
> a tail-recursion.

You can use

  (let ((loop (lambda (arg) body)))
    ... (funcall foo exp) ...)


-- Stefan

Re: lexbind

[paul r]

> You can use
>
>   (let ((loop (lambda (arg) body)))
>     ... (funcall foo exp) ...)
>

yes, that's what I do when needed. I was just wondering about this
point because I like the lexical scope of (define (fct ...) ...) in
Scheme. On the other hand, emacs lisp in not scheme, and I'm sure
there good reasons for globaly binding with (defun ...).
Thanks

-- paul

Re: lexbind

[Miles Bader]

"paul r" <paul.r.ml@gmail.com> writes:
> On the other hand, emacs lisp in not scheme, and I'm sure
> there good reasons for globaly binding with (defun ...).

Well there's the occasional desire to have other files use your
functions...

-miles

-- 
Genealogy, n. An account of one's descent from an ancestor who did not
particularly care to trace his own.

Re: lexbind

[paul r]

>
> Well there's the occasional desire to have other files use your
>  functions...
>
>  -miles
>
>
for sure you have never seen one of *my* functions, or you would not
believe any other file want to refer to it !
more seriously, there is this obvious case showing globaly bound
functions are required.
 On the other hand, some others functions will never be use out of
lexical scope, so the developper has to choose between :
 - manipulate symbols bound to lambda definitions as proposed above,
which is a working solution but far less pleasant to manipulate than
normaly "defun-ed" functions
 - do a regular (defun ...), which ends up being noisy.

In the current CVS, I can count more than 7600 fonctions in the "M-x
describe-function" completion buffer. A quick look at them make me
think a lot of them are not designed to work out of lexical scope, or
at least they are designed by a mode, for its own use only, and could
therefore be in the lexical scope.

In the spirit of the (lexical-let ...), a possible improvement could
be to have a (lexical-defun ...), don't you think ? It would not break
anything and would make at least one person happy, maybe more. Just an
idea, be sure I appreciate you know this topic several orders of
magnitude better than I will ever do.

-- paul

Re: lexbind

[Stephen J. Turnbull]

paul r writes:

 > In the spirit of the (lexical-let ...), a possible improvement could
 > be to have a (lexical-defun ...),

What improvement is this over

    (require 'cl-macs)
    (flet ((...)))

I guess it requires two less levels of parentheses, and one less level
of indentation.  Anything else?

Re: lexbind

[Miles Bader]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
>  > In the spirit of the (lexical-let ...), a possible improvement could
>  > be to have a (lexical-defun ...),
>
> What improvement is this over
>
>     (require 'cl-macs)
>     (flet ((...)))
>
> I guess it requires two less levels of parentheses, and one less level
> of indentation.  Anything else?

Well, practically speaking, a slight problem is that it doesn't work
with cl's implementation of flet (which besides being very ugly, doesn't
actually implement lexical binding anyway).

Of course in conjunction with lexical binding, it would be good to have
a real implementation of flet.

Still, if you were using it for an entire file full of functions, issues
like the extra indentation (which is actually fairly large) and parens
could indeed be annoying.

-Miles

-- 
Dictionary, n.  A malevolent literary device for cramping the growth of
a language and making it hard and inelastic. This dictionary, however,
is a most useful work.

Re: lexbind

[Dan Nicolaescu]

Miles Bader <miles.bader@necel.com> writes:

  > "Stephen J. Turnbull" <stephen@xemacs.org> writes:
  > >  > In the spirit of the (lexical-let ...), a possible improvement could
  > >  > be to have a (lexical-defun ...),
  > >
  > > What improvement is this over
  > >
  > >     (require 'cl-macs)
  > >     (flet ((...)))
  > >
  > > I guess it requires two less levels of parentheses, and one less level
  > > of indentation.  Anything else?
  > 
  > Well, practically speaking, a slight problem is that it doesn't work
  > with cl's implementation of flet (which besides being very ugly, doesn't
  > actually implement lexical binding anyway).
  > 
  > Of course in conjunction with lexical binding, it would be good to have
  > a real implementation of flet.
  > 
  > Still, if you were using it for an entire file full of functions, issues
  > like the extra indentation (which is actually fairly large) and parens
  > could indeed be annoying.

Strange that nobody has asked this yet: what about performance?  I there
already  a noticeable improvement? 

Re: lexbind

[Stephen J. Turnbull]

Miles Bader writes:

 > "Stephen J. Turnbull" <stephen@xemacs.org> writes:
 > >  > In the spirit of the (lexical-let ...), a possible improvement could
 > >  > be to have a (lexical-defun ...),
 > >
 > > What improvement is this over
 > >
 > >     (require 'cl-macs)
 > >     (flet ((...)))
 > >
 > > I guess it requires two less levels of parentheses, and one less level
 > > of indentation.  Anything else?
 > 
 > Well, practically speaking, a slight problem is that it doesn't work
 > with cl's implementation of flet (which besides being very ugly, doesn't
 > actually implement lexical binding anyway).

Sorry, I meant `labels', which does claim to do so.

Remember, the OP already mentioned `labels'.  I'm not asking that we
keep the cl-macs implementation (although the `labels' implementation
isn't all that ugly, IMO), just why use a different name?  Is there a
difference in behavior intended?

Re: lexbind

[paul r]

> Sorry, I meant `labels', which does claim to do so.
>

At the end, what is the "officially recommended" way of defining a
local function ?
    -   (labels ...) , a macro  coming from cl-macs ?
or - (let ((fct (lambda ...))) .) which is not a macro, but is
syntaxly less convenient to manipulate?
Thanks for your light.

-- Paul

Re: lexbind

[Stefan Monnier]

> At the end, what is the "officially recommended" way of defining a
> local function ?
>     -   (labels ...) , a macro  coming from cl-macs ?
> or - (let ((fct (lambda ...))) .) which is not a macro, but is
> syntaxly less convenient to manipulate?
> Thanks for your light.

Either way is fine,


        Stefan

Re: lexbind

[Stephen J. Turnbull]

paul r writes:

 > At the end, what is the "officially recommended" way of defining a
 > local function ?
 >     -   (labels ...) , a macro  coming from cl-macs ?
 > or - (let ((fct (lambda ...))) .) which is not a macro, but is
 > syntaxly less convenient to manipulate?
 > Thanks for your light.

It depends on where you are working.  If you're doing something deep
in the core, then you do not want to require cl-macs (there are ways
to avoid pulling it into the build, but they're fragile and ugly), and
the (let ((fct ...)) ... (funcall fct ...)) idiom may be preferred.

Otherwise, it's a matter of style, and since Stefan says both are OK,
it's up to you.  I've not tried the latter (I usually just use flet
which is a bad habit from my early days, labels is usually more
appropriate for my use), but the `(funcall fct ...)' idiom might be
useful to remind the programmer later that `fct' is local, not global.

Of course if the function is so big that you forget that while reading
it, maybe something else is wrong with the code. :-)

Re: lexbind

[David De La Harpe Golden]

paul r wrote:
>>  >     Hopefully none since the lexbind branch only uses lexical-binding when
>>  >     the code asks for it.
> 
> will this allow lexical binding for defun ? Currently defun binds
> function to symbol globaly, so it can not be used as a local-only
> function helper, for instance in a tail-recursion.
> 
> 

DEFUN doesn't establish local lexically scoped function bindings in
common lisp either, you use FLET or LABELS to establish local functions.
 (Yes I have noticed emacs lisp isn't common lisp, I'm just saying.)

Re: lexbind

[Richard Stallman]

    > I am not sure `defvar' is enough.  The reason is that using it to fix
    > existing packages may require renaming.

    Yes, it may require renaming.  It's usually not a big deal, tho.

I think we would be better off also having other mechanisms
for doing this, which do not require renaming.

Re: lexbind

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     > I am not sure `defvar' is enough.  The reason is that using it to fix
>     > existing packages may require renaming.
>
>     Yes, it may require renaming.  It's usually not a big deal, tho.
>
> I think we would be better off also having other mechanisms
> for doing this, which do not require renaming.

Could you give a concrete example of what you're talking about?

-Miles

-- 
Occam's razor split hairs so well, I bought the whole argument!

Re: lexbind

[Richard Stallman]

    >     Yes, it may require renaming.  It's usually not a big deal, tho.
    >
    > I think we would be better off also having other mechanisms
    > for doing this, which do not require renaming.

    Could you give a concrete example of what you're talking about?

One mechanism that has been used is (declare (special foo)).
That is one possible choice now.

lexbind

[Stefan Monnier]

Just a heads up that the lexbind-new branch is moving forward.

It's not yet ready for inclusion (still a few things to clean up and
a few more to change), but I finally got it to run mpc.el (compiled
using lexical-binding).


        Stefan

Re: lexbind

[Daniel Colascione]

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

On 2/17/11 2:10 PM, Stefan Monnier wrote:
> Just a heads up that the lexbind-new branch is moving forward.
> 
> It's not yet ready for inclusion (still a few things to clean up and
> a few more to change), but I finally got it to run mpc.el (compiled
> using lexical-binding).

That's great news. Thanks.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: lexbind

[Daniel Colascione]

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

On 2/17/11 7:54 PM, Daniel Colascione wrote:
> On 2/17/11 2:10 PM, Stefan Monnier wrote:
>> Just a heads up that the lexbind-new branch is moving forward.
>>
>> It's not yet ready for inclusion (still a few things to clean up and
>> a few more to change), but I finally got it to run mpc.el (compiled
>> using lexical-binding).
> 
> That's great news. Thanks.

Err, I forgot to add --- what about mpc.el makes it a milestone?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: lexbind

[Stefan Monnier]

>>> Just a heads up that the lexbind-new branch is moving forward.
>>> It's not yet ready for inclusion (still a few things to clean up and
>>> a few more to change), but I finally got it to run mpc.el (compiled
>>> using lexical-binding).
>> That's great news. Thanks.
> Err, I forgot to add --- what about mpc.el makes it a milestone?

Well, the author of the closure conversion code (cconv.el) picked a few
files and "made them use lexbind" (mostly set lexical-binding to t and
replace lexical-let by let), among them pcase and mpc.  Since compiling
uses pcase (via macroexpand-all), running the compiled mpc code is
a good test (also the mpc code used lexical-let to build closures).

I.e. running mpc.el was my first "non-toy test" and it bumped into
a good number of bugs.  So, while I'm sure there are still bugs lurking,
I expect that most codes should be compiled correctly now.


        Stefan

Re: lexbind

[Tom Tromey]

Stefan> Just a heads up that the lexbind-new branch is moving forward.

Very cool.

Stefan> It's not yet ready for inclusion (still a few things to clean up and
Stefan> a few more to change), but I finally got it to run mpc.el (compiled
Stefan> using lexical-binding).

I checked it out and did a make bootstrap.
It failed as appended.

Tom

Compiling /space/tromey/EmacsBzr/Git/emacs/lisp/emacs-lisp/chart.el
Debugger entered--Lisp error: (wrong-type-argument listp "Forgot to expand macro eieio-object-p")
  error-message-string("Forgot to expand macro eieio-object-p")
  byte-compile-report-error("Forgot to expand macro eieio-object-p")
  byte-compile-form((eieio-object-p (car local-args)))
  byte-compile-one-arg((not (eieio-object-p (car local-args))))
  byte-compile-form((not (eieio-object-p (car local-args))))
  byte-compile-if((if (not (eieio-object-p (car local-args))) (signal (quote no-method-definition) (list (quote shared-initialize) local-args)) (let ((scoped-class (quote eieio-default-superclass)) (eieio-generic-call-next-method-list nil) (eieio-generic-call-key method-primary) (eieio-generic-call-methodname (quote shared-initialize)) (eieio-generic-call-arglst local-args)) (apply (quote (lambda (obj slots) "Set slots of OBJ with SLOTS which is a list of name/value pairs.\nCalled from the constructor routine." (let ((scoped-class ...)) (while slots (let ... ...) (setq slots ...))))) local-args))))
  byte-compile-form((if (not (eieio-object-p (car local-args))) (signal (quote no-method-definition) (list (quote shared-initialize) local-args)) (let ((scoped-class (quote eieio-default-superclass)) (eieio-generic-call-next-method-list nil) (eieio-generic-call-key method-primary) (eieio-generic-call-methodname (quote shared-initialize)) (eieio-generic-call-arglst local-args)) (apply (quote (lambda (obj slots) "Set slots of OBJ with SLOTS which is a list of name/value pairs.\nCalled from the constructor routine." (let ((scoped-class ...)) (while slots (let ... ...) (setq slots ...))))) local-args))) nil)
  byte-compile-top-level((progn (if (not (eieio-object-p (car local-args))) (signal (quote no-method-definition) (list (quote shared-initialize) local-args)) (if nil (apply (quote no-applicable-method) (car local-args) (quote shared-initialize) local-args) (let ((scoped-class (quote eieio-default-superclass)) (eieio-generic-call-next-method-list nil) (eieio-generic-call-key method-primary) (eieio-generic-call-methodname (quote shared-initialize)) (eieio-generic-call-arglst local-args)) (apply (quote (lambda (obj slots) "Set slots of OBJ with SLOTS which is a list of name/value pairs.\nCalled from the constructor routine." (let ... ...))) local-args))))) nil lambda)
  byte-compile-lambda((lambda (&rest local-args) "Set slots of OBJ with SLOTS which is a list of name/value pairs.\nCalled from the constructor routine." (if (not (eieio-object-p (car local-args))) (signal (quote no-method-definition) (list (quote shared-initialize) local-args)) (if nil (apply (quote no-applicable-method) (car local-args) (quote shared-initialize) local-args) (let ((scoped-class (quote eieio-default-superclass)) (eieio-generic-call-next-method-list nil) (eieio-generic-call-key method-primary) (eieio-generic-call-methodname (quote shared-initialize)) (eieio-generic-call-arglst local-args)) (apply (quote (lambda (obj slots) "Set slots of OBJ with SLOTS which is a list of name/value pairs.\nCalled from the constructor routine." (let ... ...))) local-args))))))
  (let ((byte-compile-free-references nil) (byte-compile-warnings nil)) (byte-compile-lambda (\` (lambda (&rest local-args) (\, doc-string) (if (not (eieio-object-p (car local-args))) (signal (quote no-method-definition) (list (\, ...) local-args)) (if (\, (if ... nil ...)) (apply (quote no-applicable-method) (car local-args) (\, ...) local-args) (let (... ... ... ... ...) (apply ... local-args))))))))
  eieio-defgeneric-form-primary-only-one(shared-initialize "Set slots of OBJ with SLOTS which is a list of name/value pairs.\nCalled from the constructor routine." eieio-default-superclass (lambda (obj slots) "Set slots of OBJ with SLOTS which is a list of name/value pairs.\nCalled from the constructor routine." (let ((scoped-class (aref obj object-class))) (while slots (let ((rn (eieio-initarg-to-attribute (object-class-fast obj) (car slots)))) (if (not rn) (slot-missing obj (car slots) (quote oset) (car (cdr slots))) (eieio-oset obj rn (car (cdr slots))))) (setq slots (cdr (cdr slots)))))))
  (fset method (eieio-defgeneric-form-primary-only-one method doc-string (car entry) (cdr entry)))
  (let* ((doc-string (documentation method)) (M (get method (quote eieio-method-tree))) (entry (car (aref M method-primary)))) (fset method (eieio-defgeneric-form-primary-only-one method doc-string (car entry) (cdr entry))))
  eieio-defgeneric-reset-generic-form-primary-only-one(shared-initialize)
  (if (generic-primary-only-one-p method) (eieio-defgeneric-reset-generic-form-primary-only-one method) (eieio-defgeneric-reset-generic-form-primary-only method))
  (if (generic-primary-only-p method) (if (generic-primary-only-one-p method) (eieio-defgeneric-reset-generic-form-primary-only-one method) (eieio-defgeneric-reset-generic-form-primary-only method)) (eieio-defgeneric-reset-generic-form method))
  (progn (if (generic-primary-only-p method) (if (generic-primary-only-one-p method) (eieio-defgeneric-reset-generic-form-primary-only-one method) (eieio-defgeneric-reset-generic-form-primary-only method)) (eieio-defgeneric-reset-generic-form method)))
  (if eieio-optimize-primary-methods-flag (progn (if (generic-primary-only-p method) (if (generic-primary-only-one-p method) (eieio-defgeneric-reset-generic-form-primary-only-one method) (eieio-defgeneric-reset-generic-form-primary-only method)) (eieio-defgeneric-reset-generic-form method))))
  (when eieio-optimize-primary-methods-flag (if (generic-primary-only-p method) (if (generic-primary-only-one-p method) (eieio-defgeneric-reset-generic-form-primary-only-one method) (eieio-defgeneric-reset-generic-form-primary-only method)) (eieio-defgeneric-reset-generic-form method)))
  eieio-defmethod(shared-initialize (((obj eieio-default-superclass) slots) "Set slots of OBJ with SLOTS which is a list of name/value pairs.\nCalled from the constructor routine." (let ((scoped-class (aref obj object-class))) (while slots (let ((rn (eieio-initarg-to-attribute (object-class-fast obj) (car slots)))) (if (not rn) (slot-missing obj (car slots) (quote oset) (car (cdr slots))) (eieio-oset obj rn (car (cdr slots))))) (setq slots (cdr (cdr slots)))))))
  (defmethod shared-initialize ((obj eieio-default-superclass) slots) "Set slots of OBJ with SLOTS which is a list of name/value pairs.\nCalled from the constructor routine." (let ((scoped-class (aref obj object-class))) (while slots (let ((rn (eieio-initarg-to-attribute (object-class-fast obj) (car slots)))) (if (not rn) (slot-missing obj (car slots) (quote oset) (car (cdr slots))) (eieio-oset obj rn (car (cdr slots))))) (setq slots (cdr (cdr slots))))))
  (progn (if (fboundp (quote compiled-function-arglist)) (defalias (quote eieio-compiled-function-arglist) (quote compiled-function-arglist)) (defun eieio-compiled-function-arglist (func) "Return the argument list for the compiled function FUNC." (aref func 0))) (defvar eieio-hook nil "*This hook is executed, then cleared each time `defclass' is called.") (defvar eieio-error-unsupported-class-tags nil "Non-nil to throw an error if an encountered tag is unsupported.\nThis may prevent classes from CLOS applications from being used with EIEIO\nsince EIEIO does not support all CLOS tags.") (defvar eieio-skip-typecheck nil "*If non-nil, skip all slot typechecking.\nSet this to t permanently if a program is functioning well to get a\nsmall speed increase.  This variable is also used internally to handle\ndefault setting for optimization purposes.") (defvar eieio-optimize-primary-methods-flag t "Non-nil means to optimize the method dispatch on primary methods.") (defvar this nil "Inside a method, this variable is the object in question.\nDO NOT SET THIS YOURSELF unless you are trying to simulate friendly slots.\n\nNote: Embedded methods are no longer supported.  The variable THIS is\nstill set for CLOS methods for the sake of routines like\n`call-next-method'.") (defvar scoped-class nil "This is set to a class when a method is running.\nThis is so we know we are allowed to check private parts or how to\nexecute a `call-next-method'.  DO NOT SET THIS YOURSELF!") (defvar eieio-initializing-object nil "Set to non-nil while initializing an object.") (defconst eieio-unbound (if (and (boundp (quote eieio-unbound)) (symbolp eieio-unbound)) eieio-unbound (make-symbol "unbound")) "Uninterned symbol representing an unbound slot in an object.") (defvar eieio-default-superclass nil) (defconst class-symbol 1 "Class's symbol (self-referencing.).") (defconst class-parent 2 "Class parent slot.") (defconst class-children 3 "Class children class slot.") (defconst class-symbol-obarray 4 "Obarray permitting fast access to variable position indexes.") (defconst class-public-a 5 "Class attribute index.") (defconst class-public-d 6 "Class attribute defaults index.") (defconst class-public-doc 7 "Class documentation strings for attributes.") (defconst class-public-type 8 "Class type for a slot.") (defconst class-public-custom 9 "Class custom type for a slot.") (defconst class-public-custom-label 10 "Class custom group for a slot.") (defconst class-public-custom-group 11 "Class custom group for a slot.") (defconst class-public-printer 12 "Printer for a slot.") (defconst class-protection 13 "Class protection for a slot.") (defconst class-initarg-tuples 14 "Class initarg tuples list.") (defconst class-class-allocation-a 15 "Class allocated attributes.") (defconst class-class-allocation-doc 16 "Class allocated documentation.") (defconst class-class-allocation-type 17 "Class allocated value type.") (defconst class-class-allocation-custom 18 "Class allocated custom descriptor.") (defconst class-class-allocation-custom-label 19 "Class allocated custom descriptor.") (defconst class-class-allocation-custom-group 20 "Class allocated custom group.") (defconst class-class-allocation-printer 21 "Class allocated printer for a slot.") (defconst class-class-allocation-protection 22 "Class allocated protection list.") (defconst class-class-allocation-values 23 "Class allocated value vector.") (defconst class-default-object-cache 24 "Cache index of what a newly created object would look like.\nThis will speed up instantiation time as only a `copy-sequence' will\nbe needed, instead of looping over all the values and setting them\nfrom the default.") (defconst class-options 25 "Storage location of tagged class options.\nStored outright without modifications or stripping.") (defconst class-num-slots 26 "Number of slots in the class definition object.") (defconst object-class 1 "Index in an object vector where the class is stored.") (defconst object-name 2 "Index in an object where the name is stored.") (defconst method-static 0 "Index into :static tag on a method.") (defconst method-before 1 "Index into :before tag on a method.") (defconst method-primary 2 "Index into :primary tag on a method.") (defconst method-after 3 "Index into :after tag on a method.") (defconst method-num-lists 4 "Number of indexes into methods vector in which groups of functions are kept.") (defconst method-generic-before 4 "Index into generic :before tag on a method.") (defconst method-generic-primary 5 "Index into generic :primary tag on a method.") (defconst method-generic-after 6 "Index into generic :after tag on a method.") (defconst method-num-slots 7 "Number of indexes into a method's vector.") (defsubst eieio-specialized-key-to-generic-key (key) "Convert a specialized KEY into a generic method key." (cond ((eq key method-static) 0) ((< key method-num-lists) (+ key 3)) (t key))) (autoload (quote byte-compile-file-form-defmethod) "eieio-comp" "This function is used to byte compile methods in a nice way.") ...)
  (eval-and-compile (if (fboundp (quote compiled-function-arglist)) (defalias (quote eieio-compiled-function-arglist) (quote compiled-function-arglist)) (defun eieio-compiled-function-arglist (func) "Return the argument list for the compiled function FUNC." (aref func 0))) (defvar eieio-hook nil "*This hook is executed, then cleared each time `defclass' is called.") (defvar eieio-error-unsupported-class-tags nil "Non-nil to throw an error if an encountered tag is unsupported.\nThis may prevent classes from CLOS applications from being used with EIEIO\nsince EIEIO does not support all CLOS tags.") (defvar eieio-skip-typecheck nil "*If non-nil, skip all slot typechecking.\nSet this to t permanently if a program is functioning well to get a\nsmall speed increase.  This variable is also used internally to handle\ndefault setting for optimization purposes.") (defvar eieio-optimize-primary-methods-flag t "Non-nil means to optimize the method dispatch on primary methods.") (defvar this nil "Inside a method, this variable is the object in question.\nDO NOT SET THIS YOURSELF unless you are trying to simulate friendly slots.\n\nNote: Embedded methods are no longer supported.  The variable THIS is\nstill set for CLOS methods for the sake of routines like\n`call-next-method'.") (defvar scoped-class nil "This is set to a class when a method is running.\nThis is so we know we are allowed to check private parts or how to\nexecute a `call-next-method'.  DO NOT SET THIS YOURSELF!") (defvar eieio-initializing-object nil "Set to non-nil while initializing an object.") (defconst eieio-unbound (if (and (boundp (quote eieio-unbound)) (symbolp eieio-unbound)) eieio-unbound (make-symbol "unbound")) "Uninterned symbol representing an unbound slot in an object.") (defvar eieio-default-superclass nil) (defconst class-symbol 1 "Class's symbol (self-referencing.).") (defconst class-parent 2 "Class parent slot.") (defconst class-children 3 "Class children class slot.") (defconst class-symbol-obarray 4 "Obarray permitting fast access to variable position indexes.") (defconst class-public-a 5 "Class attribute index.") (defconst class-public-d 6 "Class attribute defaults index.") (defconst class-public-doc 7 "Class documentation strings for attributes.") (defconst class-public-type 8 "Class type for a slot.") (defconst class-public-custom 9 "Class custom type for a slot.") (defconst class-public-custom-label 10 "Class custom group for a slot.") (defconst class-public-custom-group 11 "Class custom group for a slot.") (defconst class-public-printer 12 "Printer for a slot.") (defconst class-protection 13 "Class protection for a slot.") (defconst class-initarg-tuples 14 "Class initarg tuples list.") (defconst class-class-allocation-a 15 "Class allocated attributes.") (defconst class-class-allocation-doc 16 "Class allocated documentation.") (defconst class-class-allocation-type 17 "Class allocated value type.") (defconst class-class-allocation-custom 18 "Class allocated custom descriptor.") (defconst class-class-allocation-custom-label 19 "Class allocated custom descriptor.") (defconst class-class-allocation-custom-group 20 "Class allocated custom group.") (defconst class-class-allocation-printer 21 "Class allocated printer for a slot.") (defconst class-class-allocation-protection 22 "Class allocated protection list.") (defconst class-class-allocation-values 23 "Class allocated value vector.") (defconst class-default-object-cache 24 "Cache index of what a newly created object would look like.\nThis will speed up instantiation time as only a `copy-sequence' will\nbe needed, instead of looping over all the values and setting them\nfrom the default.") (defconst class-options 25 "Storage location of tagged class options.\nStored outright without modifications or stripping.") (defconst class-num-slots 26 "Number of slots in the class definition object.") (defconst object-class 1 "Index in an object vector where the class is stored.") (defconst object-name 2 "Index in an object where the name is stored.") (defconst method-static 0 "Index into :static tag on a method.") (defconst method-before 1 "Index into :before tag on a method.") (defconst method-primary 2 "Index into :primary tag on a method.") (defconst method-after 3 "Index into :after tag on a method.") (defconst method-num-lists 4 "Number of indexes into methods vector in which groups of functions are kept.") (defconst method-generic-before 4 "Index into generic :before tag on a method.") (defconst method-generic-primary 5 "Index into generic :primary tag on a method.") (defconst method-generic-after 6 "Index into generic :after tag on a method.") (defconst method-num-slots 7 "Number of indexes into a method's vector.") (defsubst eieio-specialized-key-to-generic-key (key) "Convert a specialized KEY into a generic method key." (cond ((eq key method-static) 0) ((< key method-num-lists) (+ key 3)) (t key))) (autoload (quote byte-compile-file-form-defmethod) "eieio-comp" "This function is used to byte compile methods in a nice way.") ...)
  eval-buffer(#<buffer  *load*> nil "/space/tromey/EmacsBzr/Git/emacs/lisp/emacs-lisp/eieio.el" nil t)  ; Reading at buffer position 112490
  load-with-code-conversion("/space/tromey/EmacsBzr/Git/emacs/lisp/emacs-lisp/eieio.el" "/space/tromey/EmacsBzr/Git/emacs/lisp/emacs-lisp/eieio.el" nil t)
  require(eieio)
  apply(require eieio)
  byte-compile-file-form-require((require (quote eieio)))
  byte-compile-file-form((require (quote eieio)))
  #[nil "r\bq\210	\203\r\0\306	\n\"\210eb\210\307\x13\310\307w\210\311\312!\203\"\0\313y\210\202\x12\0m\204D\0`\211\x14\x15\307\x1e\x13\314\b!\x1e\x14\x0e\x13\203;\0\315\316!\210\317\x0e\x14!\210*\202\x12\0\320 \210d\x15\321 \210)	\205Y\0r\nq\210\322	!)\207" [bytecomp-inbuffer bytecomp-filename bytecomp-outbuffer byte-compile-unresolved-functions byte-compile-read-position byte-compile-last-position byte-compile-insert-header nil " 	\n\f" looking-at ";" 1 read byte-compile-warn "!! The file uses old-style backquotes !!\nThis functionality has been obsolete for more than 10 years already\nand will be removed soon.  See (elisp)Backquote in the manual." byte-compile-file-form byte-compile-flush-pending byte-compile-warn-about-unresolved-functions byte-compile-fix-header old-style-backquotes form] 4]()
  byte-compile-from-buffer(#<buffer  *Compiler Input*> "/space/tromey/EmacsBzr/Git/emacs/lisp/emacs-lisp/chart.el")
  byte-compile-file("/space/tromey/EmacsBzr/Git/emacs/lisp/emacs-lisp/chart.el")
  batch-byte-compile-file("/space/tromey/EmacsBzr/Git/emacs/lisp/emacs-lisp/chart.el")
  batch-byte-compile()
  command-line-1(("--eval" "(setq max-lisp-eval-depth 1000)" "-f" "batch-byte-compile" "/space/tromey/EmacsBzr/Git/emacs/lisp/emacs-lisp/chart.el"))
  command-line()
  normal-top-level()

Re: lexbind

[Stefan Monnier]

> I checked it out and did a make bootstrap.
> It failed as appended.

If it got to compiling eieio, then it didn't really fail ;-)
Try "make -k", and you should see that only a handful of Elisp files trigger
the above problem.
In any case I believe I've fixed the above bug earlier today.
OTOH I'm not actually sure that my fix is correct (it makes the
compilation succeed but the resulting code might not be correct).


        Stefan

Emacs 23.3 released

[Chong Yidong]

GNU Emacs 23.3 has been released, and is now available at
ftp.gnu.org/gnu/emacs/ and the GNU FTP mirrors (see
http://www.gnu.org/order/ftp.html).

The SHA1 checksums are:

 de2c924655f0f4e012cc119840cd341a1d40e32c  emacs-23.3.tar.bz2
 53bdfe584f98c13265caa3eea3cfdf79ca0f7584  emacs-23.3.tar.gz

Please send bug reports to <bug-gnu-emacs@gnu.org>.  You can use the
command M-x report-emacs-bug to do this.

Emacs 23.3 is primarily a bugfix release.  Also included are a number of
enhancements to VC and Rmail, and a new indentation library, smie.el.
For details, see the file etc/NEWS.

Re: Emacs 23.3 released

[Stefan Monnier]

A big thanks to everybody for the work they put into this release.

I hope we will be able to jump right to 24.1 without an intermediate
23.4, but if you find bugs that are not specific to trunk, please still
commit them to emacs-23.

Talking about 24.1, I now consider the lexbind-new branch as "fully
functional": there are still a few changes I want to do there before
merging, but they should only impact performance and code quality, so
I encourage people to try it out and report any regression so they can
be addressed before we merge it into trunk.


        Stefan


>>>>> "Chong" == Chong Yidong <cyd@stupidchicken.com> writes:

> GNU Emacs 23.3 has been released, and is now available at
> ftp.gnu.org/gnu/emacs/ and the GNU FTP mirrors (see
> http://www.gnu.org/order/ftp.html).

> The SHA1 checksums are:

>  de2c924655f0f4e012cc119840cd341a1d40e32c  emacs-23.3.tar.bz2
>  53bdfe584f98c13265caa3eea3cfdf79ca0f7584  emacs-23.3.tar.gz

> Please send bug reports to <bug-gnu-emacs@gnu.org>.  You can use the
> command M-x report-emacs-bug to do this.

> Emacs 23.3 is primarily a bugfix release.  Also included are a number of
> enhancements to VC and Rmail, and a new indentation library, smie.el.
> For details, see the file etc/NEWS.

Re: Emacs 23.3 released

[Thierry Volpiatto]

Hi Stefan,

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> A big thanks to everybody for the work they put into this release.
>
> I hope we will be able to jump right to 24.1 without an intermediate
> 23.4, but if you find bugs that are not specific to trunk, please still
> commit them to emacs-23.
>
> Talking about 24.1, I now consider the lexbind-new branch as "fully
> functional": there are still a few changes I want to do there before
> merging, but they should only impact performance and code quality, so
> I encourage people to try it out and report any regression so they can
> be addressed before we merge it into trunk.

A quick try to lexbind give me this error on startup:

--8<---------------cut here---------------start------------->8---
Debugger entered--Lisp error: (wrong-type-argument listp 0)
  ad-parse-arglist(0)
  ad-map-arglists(0 0)
  ad-make-mapped-call(0 0 ad-Orig-dired-find-file-other-window)
  ad-make-advised-definition(dired-find-file-other-window)
  ad-activate-advised-definition(dired-find-file-other-window nil)
  ad-activate(dired-find-file-other-window nil)
  byte-code(
[...]

 [current-load-list elscreen-dired-version (lambda (defconst-tmp-var) (defconst elscreen-dired-version defconst-tmp-var)) "0.1.0 (November 6, 2005)" provide elscreen-dired require elscreen ad-add-advice dired-find-file-other-window (elscreen-dired-find-file-other-window nil t (advice lambda nil (let ((window-configuration (current-window-configuration)) (buffer nil)) ad-do-it (unless (eq major-mode 'dired-mode) (setq buffer (current-buffer)) (set-window-configuration window-configuration) (elscreen-find-and-goto-by-buffer buffer t))))) around nil ad-activate] 5)
  require(elscreen-dired)
  eval-buffer(#<buffer  *load*> nil "/home/thierry/.emacs.el" nil t)  ; Reading at buffer position 45697
  load-with-code-conversion("/home/thierry/.emacs.el" "/home/thierry/.emacs.el" t t)
  load("~/.emacs" t t)

[...]

 [init-file-user system-type user-init-file-1 user-init-file otherfile source ms-dos "~" "/_emacs" windows-nt directory-files nil "^\\.emacs\\(\\.elc?\\)?$" "~/.emacs" "^_emacs\\(\\.elc?\\)?$" "~/_emacs" "/.emacs" t load expand-file-name "init" file-name-as-directory "/.emacs.d" file-name-extension "elc" file-name-sans-extension ".el" file-exists-p file-newer-than-file-p message "Warning: %s is newer than %s" sit-for 1 "default" alt inhibit-default-init inhibit-startup-screen] 7]()
  command-line()
  normal-top-level()
--8<---------------cut here---------------end--------------->8---

No error with emacs -Q.

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: Emacs 23.3 released

[Stefan Monnier]

> A quick try to lexbind give me this error on startup:

> --8<---------------cut here---------------start------------->8---
> Debugger entered--Lisp error: (wrong-type-argument listp 0)
>   ad-parse-arglist(0)

Does the patch below fix it for you?


        Stefan


=== modified file 'lisp/emacs-lisp/advice.el'
--- lisp/emacs-lisp/advice.el	2011-01-28 21:42:11 +0000
+++ lisp/emacs-lisp/advice.el	2011-03-11 04:16:59 +0000
@@ -2535,17 +2535,11 @@
   "Return the argument list of DEFINITION.
 If DEFINITION could be from a subr then its NAME should be
 supplied to make subr arglist lookup more efficient."
-  (cond ((ad-compiled-p definition)
-	 (aref (ad-compiled-code definition) 0))
-	((consp definition)
-	 (car (cdr (ad-lambda-expression definition))))
-	((ad-subr-p definition)
-	 (if name
-	     (ad-subr-arglist name)
-	   ;; otherwise get it from its printed representation:
-	   (setq name (format "%s" definition))
-	   (string-match "^#<subr \\([^>]+\\)>$" name)
-	   (ad-subr-arglist (intern (match-string 1 name)))))))
+  (require 'help-fns)
+  (cond
+   ((or (ad-macro-p definition) (ad-advice-p))
+    (help-function-arglist (cdr definition)))
+   (t (help-function-arglist definition))))
 
 ;; Store subr-args as `((arg1 arg2 ...))' so I can distinguish
 ;; a defined empty arglist `(nil)' from an undefined arglist:

=== modified file 'lisp/help-fns.el'
--- lisp/help-fns.el	2011-03-06 21:22:16 +0000
+++ lisp/help-fns.el	2011-03-11 04:15:05 +0000
@@ -124,6 +124,21 @@
       (nreverse arglist)))
    ((byte-code-function-p def) (aref def 0))
    ((eq (car-safe def) 'lambda) (nth 1 def))
+   ((subrp def)
+    (let ((arity (subr-arity def))
+          (arglist ()))
+      (dotimes (i (car arity))
+        (push (intern (concat "arg" (number-to-string (1+ i)))) arglist))
+      (if (not (numberp (cdr arglist)))
+          (progn
+            (push '&rest arglist)
+            (push 'rest arglist))
+        (push '&optional arglist)
+        (dotimes (i (- (cdr arity) (car arity)))
+          (push (intern (concat "arg" (number-to-string
+                                       (1+ i (car arity)))))
+                arglist)))
+      (nreverse arglist)))
    ((and (eq (car-safe def) 'autoload) (not (eq (nth 4 def) 'keymap)))
     "[Arg list not available until function definition is loaded.]")
    (t t)))

Re: Emacs 23.3 released

[Thierry Volpiatto]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Does the patch below fix it for you?

The patch apply fine but now i have an error when compiling:

--8<---------------cut here---------------start------------->8---
byte-compile-fix-header old-style-backquotes form] 4]()
  byte-compile-from-buffer(#<buffer  *Compiler Input*> "/home/thierry/tmp/emacs-lexbind/lisp/ses.el")
  byte-compile-file("ses.el")
  batch-byte-compile-file("ses.el")
  batch-byte-compile()
  command-line-1(("--eval" "(setq max-lisp-eval-depth 1200)" "-f" "batch-byte-compile" "ses.el"))
  command-line()
  normal-top-level()

make[2]: *** [ses.elc] Erreur 255
make[2]: quittant le répertoire « /home/thierry/tmp/emacs-lexbind/lisp »
make[1]: *** [compile-main] Erreur 2
make[1]: quittant le répertoire « /home/thierry/tmp/emacs-lexbind/lisp »
make: *** [lisp] Erreur 2
--8<---------------cut here---------------end--------------->8---

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: Emacs 23.3 released

[Stefan Monnier]

>> Does the patch below fix it for you?
> The patch apply fine but now i have an error when compiling:

The backtrace you showed seemed incomplete.  But the patch I sent had
a gross error.  I've installed a better version on the lexbind branch,
so please try again.


        Stefan

Re: Emacs 23.3 released

[Juanma Barranquero]

I'm now bootstrapping lexbind-new straight from the repo, with just two changes:

- Using loaddefs.el from a previous bootstrap as ldefs-boot.el.
- Reverting the change to lisp/emacs-lisp/debug.el so backtraces are manageable.

On make'ing the target compile-CMD, byecompiling the COMPILE_FIRST
files throws errors for pcase.el, macroexp.el and cconv.el, like
these:

  Debugger entered--Lisp error: (file-error "Opening input file" "no
such file or directory"
"C:/emacs/lexbind-new/lisp/emacs-lisp/pcase.elc")
    insert-file-contents("C:/emacs/lexbind-new/lisp/emacs-lisp/pcase.elc")
    byte-compile-file("C:/emacs/lexbind-new/lisp/emacs-lisp/pcase.elc")
    batch-byte-compile-file("C:/emacs/lexbind-new/lisp/emacs-lisp/pcase.elc")
    batch-byte-compile(t)
    batch-byte-compile-if-not-done()
    funcall(batch-byte-compile-if-not-done)
    [...etc...]

Bootstrapping then continues normally and produces a working
executable (pcase.el, macroexp.el and cconv.el get correctly compiled
along with everything else).

    Juanma

Re: Emacs 23.3 released

[Stefan Monnier]

> I'm now bootstrapping lexbind-new straight from the repo, with just
> two changes:

Great.  So my changes to makefile.w32-in work?  The mind boggles!

> - Using loaddefs.el from a previous bootstrap as ldefs-boot.el.

Hmm... I'm really curious why that's needed.  I rarely bootstrap my
usual Emacs, but I bootstrap the lexbind branch pretty often (using
some underused old 16-core Athlon X2 machine, it's barely 3mins to
bootstrap, less than a minute and a half to recompile all the files) for
benchmarking purposes.  So under GNU/Linux it bootstraps fine, and the
loaddefs.el should not be affected much by platform differences, AFAICT.

I just noticed that, contrary to my belief, the lexbind branch does have
changes in ldefs-boot (so I'll get conflicts at the next merge that
changes ldefs-boot).  Could you try

   bzr revert -r ancestor:../trunk lisp/ldefs-boot.el

or copy the trunk's ldefs-boot.el to see if that fixes the problem?
(both the trunk's and the current lexbind version work fine for me under
GNU/Linux).

> On make'ing the target compile-CMD, bytecompiling the COMPILE_FIRST
> files throws errors for pcase.el, macroexp.el and cconv.el, like
> these:

I guess the patch below will fix those problem.


        Stefan


=== modified file 'lisp/makefile.w32-in'
--- lisp/makefile.w32-in	2011-03-12 03:32:43 +0000
+++ lisp/makefile.w32-in	2011-03-14 13:49:12 +0000
@@ -84,9 +84,9 @@
 COMPILE_FIRST = \
 	$(lisp)/emacs-lisp/byte-opt.el \
 	$(lisp)/emacs-lisp/bytecomp.el \
-	$(lisp)/emacs-lisp/pcase.elc \
-	$(lisp)/emacs-lisp/macroexp.elc \
-	$(lisp)/emacs-lisp/cconv.elc \
+	$(lisp)/emacs-lisp/pcase.el \
+	$(lisp)/emacs-lisp/macroexp.el \
+	$(lisp)/emacs-lisp/cconv.el \
 	$(lisp)/subr.el \
 	$(lisp)/progmodes/cc-mode.el \
 	$(lisp)/progmodes/cc-vars.el

Re: Emacs 23.3 released

[Juanma Barranquero]

On Mon, Mar 14, 2011 at 15:10, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>   bzr revert -r ancestor:../trunk lisp/ldefs-boot.el
[...]
> I guess the patch below will fix those problem.

Yeah, lexbind-new bootstraps now fine on Windows.

    Juanma

RE: Lexbind (was: Emacs 23.3 released)

[Stefan Monnier]

>>   bzr revert -r ancestor:../trunk lisp/ldefs-boot.el
>> I guess the patch below will fix those problem.
> Yeah, lexbind-new bootstraps now fine on Windows.

Great, thanks.  Now on to actual run-time errors.


        Stefan

Re: Lexbind (was: Emacs 23.3 released)

[Juanma Barranquero]

> Now on to actual run-time errors.

I've had several hangups while reading from the minibuffer. No CPU
usage, but no response whatsoever so I had to kill Emacs.

I just had one while running under GDB, so I Ctrl-C and I got the
attached backtrace.

Note that I'm not running emacs -Q, but with my normal setup
(icomplete, ido, etc.)

    Juanma



(gdb) bt
#0  0x0112c987 in next_element_from_buffer (it=0x88c250) at xdisp.c:6744
#1  0x0112171f in get_next_display_element (it=0x88c250) at xdisp.c:5630
#2  0x0112292b in move_it_in_display_line_to (it=<value optimized
out>, to_charpos=-1, to_x=-1, op=0) at xdisp.c:6956
#3  0x0112620f in move_it_to (it=0x88c250, to_charpos=-1, to_x=-1,
to_y=-1, to_vpos=1, op=4) at xdisp.c:7333
#4  0x0112e87f in move_it_by_lines (it=0x88c250, dvpos=1, need_y_p=1)
at xdisp.c:7757
#5  0x01136a6e in try_scrolling (window=<value optimized out>,
just_this_one_p=0, arg_scroll_conservatively=143165576, scroll_step=0,
    temp_scroll_step=0, last_line_misfit=0) at xdisp.c:13128
#6  0x0114e0cd in redisplay_window (window=<value optimized out>,
just_this_one_p=0) at xdisp.c:14168
#7  0x011502b3 in redisplay_window_0 (window=56712709) at xdisp.c:12362
#8  0x01012961 in internal_condition_case_1 (bfun=0x1150290
<redisplay_window_0>, arg=56712709, handlers=53689030,
    hfun=0x1109770 <redisplay_window_error>) at eval.c:1536
#9  0x0110f137 in redisplay_windows (window=<value optimized out>) at
xdisp.c:12342
#10 0x011310f6 in redisplay_internal (preserve_echo_area=<value
optimized out>) at xdisp.c:11919
#11 0x01132a65 in redisplay_preserve_echo_area (from_where=8) at xdisp.c:12174
#12 0x0103384a in detect_input_pending_run_timers (do_display=1) at
keyboard.c:10365
#13 0x0101e7e1 in wait_reading_process_output (time_limit=450,
microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=53704730,
wait_proc=0x0,
    just_wait_proc=0) at process.c:4856
#14 0x01081f63 in sit_for (timeout=1800, reading=1, do_display=1) at
dispnew.c:6017
#15 0x01036e95 in read_char (commandflag=1, nmaps=4, maps=0x88f190,
prev_event=53704730, used_mouse_menu=0x88f288, end_time=0x0) at
keyboard.c:2601
#16 0x0103853e in read_key_sequence (keybuf=0x88f2f8, prompt=53704730,
dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1,
    bufsize=30) at keyboard.c:9199
#17 0x0103b07a in command_loop_1 () at keyboard.c:1409
#18 0x0101288b in internal_condition_case (bfun=0x103ae30
<command_loop_1>, handlers=53758362, hfun=0x102ae50 <cmd_error>) at
eval.c:1491
#19 0x0102a51d in command_loop_2 (ignore=53704730) at keyboard.c:1129
#20 0x010127c9 in internal_catch (tag=53860642, func=0x102a4f0
<command_loop_2>, arg=53704730) at eval.c:1235
#21 0x0102afd7 in command_loop () at keyboard.c:1094
#22 0x0102b0cb in recursive_edit_1 () at keyboard.c:731
#23 0x010accc3 in read_minibuf (map=53693814, initial=53704730,
prompt=<value optimized out>, backup_n=<value optimized out>,
expflag=0,
    histvar=58957570, histpos=0, defalt=82462646, allow_props=0,
inherit_input_method=1) at minibuf.c:661
#24 0x010148d7 in Ffuncall (nargs=8, args=0x88f630) at eval.c:3012
#25 0x010c2e07 in exec_byte_code (bytestr=<value optimized out>,
vector=20030189, maxdepth=36, args_template=53704730, nargs=0,
    args=<value optimized out>) at bytecode.c:766
#26 0x01014231 in funcall_lambda (fun=20030013, nargs=2,
arg_vector=0x88f7e4) at eval.c:3218
#27 0x010146d0 in Ffuncall (nargs=3, args=0x88f7e0) at eval.c:3035
#28 0x010c2e07 in exec_byte_code (bytestr=<value optimized out>,
vector=20035461, maxdepth=28, args_template=53704730, nargs=0,
    args=<value optimized out>) at bytecode.c:766
#29 0x01014231 in funcall_lambda (fun=20035341, nargs=0,
arg_vector=0x88f900) at eval.c:3218
#30 0x010131ee in apply_lambda (fun=20035341, args=<value optimized
out>) at eval.c:3096
#31 0x01013507 in eval_sub (form=20035950) at eval.c:2406
#32 0x01017312 in Feval (form=20035950, lexical=53704730) at eval.c:2212
#33 0x010c3da7 in Fcall_interactively (function=54514858,
record_flag=53704730, keys=53725957) at callint.c:343
#34 0x010149d9 in Ffuncall (nargs=4, args=0x88fbb0) at eval.c:2993
#35 0x01014dc1 in call3 (fn=53872642, arg1=54514858, arg2=53704730,
arg3=53704730) at eval.c:2785
#36 0x0103b387 in command_loop_1 () at keyboard.c:1528
#37 0x0101288b in internal_condition_case (bfun=0x103ae30
<command_loop_1>, handlers=53758362, hfun=0x102ae50 <cmd_error>) at
eval.c:1491
#38 0x0102a51d in command_loop_2 (ignore=53704730) at keyboard.c:1129
#39 0x010127c9 in internal_catch (tag=53756458, func=0x102a4f0
<command_loop_2>, arg=53704730) at eval.c:1235
#40 0x0102b021 in command_loop () at keyboard.c:1108
#41 0x0102b0cb in recursive_edit_1 () at keyboard.c:731
#42 0x0102b265 in Frecursive_edit () at keyboard.c:793
#43 0x01002e5f in main (argc=<value optimized out>, argv=0xa22d08) at
emacs.c:1684

Lisp Backtrace:
"read-from-minibuffer" (0x88f634)
"read-regexp" (0x88f7e4)
"occur-read-primary-args" (0x88f900)
"call-interactively" (0x88fbb4)
(gdb)

Re: Lexbind

[Stefan Monnier]

> I just had one while running under GDB, so I Ctrl-C and I got the
> attached backtrace.

Hmm... the lexbind branch does not touch the redisplay code at all, so
this is perplexing.  My best guess so far is that some part of the
changed C code corrupts some part of the memory, leading to the inf-loop.


        Stefan

Re: Lexbind

[Wojciech Meyer]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> I just had one while running under GDB, so I Ctrl-C and I got the
>> attached backtrace.
>
> Hmm... the lexbind branch does not touch the redisplay code at all, so
> this is perplexing.  My best guess so far is that some part of the
> changed C code corrupts some part of the memory, leading to the inf-loop.
>
>
>         Stefan

I noticed some hang ups few days ago with a fresh update. Not only on
`lexbind' branch but on `trunk' as well. I didn't try to debug it. Now I
rebuilt it, with complete cleanup of repository, and it *seems* to be
better. The hangup was happening usually after M-x and then Emacs was
not responsive and taking significant CPU time. `pkill emacs' had seemed to
interrupt the hang, but later it was happening again and `pkill emacs'
was killing Emacs completely. I don't know if it is relevant to the
discussion. I do have similar configuration that Juanma cited.

Wojciech

Re: Lexbind

[Juanma Barranquero]

On Thu, Mar 17, 2011 at 21:01, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Hmm... the lexbind branch does not touch the redisplay code at all, so
> this is perplexing.

Perhaps it is just bad luck that I didn't get lockups running the
trunk, but I don't think so. It's happened at least five or six times
with lexbind-new, and I don't remember the last time I had trouble
with the trunk.

> My best guess so far is that some part of the
> changed C code corrupts some part of the memory, leading to the inf-loop.

So it's going to be difficult to catch :-(

    Juanma

Re: Lexbind

[joakim]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Thu, Mar 17, 2011 at 21:01, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
>> Hmm... the lexbind branch does not touch the redisplay code at all, so
>> this is perplexing.
>
> Perhaps it is just bad luck that I didn't get lockups running the
> trunk, but I don't think so. It's happened at least five or six times
> with lexbind-new, and I don't remember the last time I had trouble
> with the trunk.
>
>> My best guess so far is that some part of the
>> changed C code corrupts some part of the memory, leading to the inf-loop.
>
> So it's going to be difficult to catch :-(

What's the state of running Emacs under Valgrind these days? I have a
vague memory that it might be possible with an undumped Emacs.

>     Juanma
>

-- 
Joakim Verona