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

[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]

> 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

[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

[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

[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]

> 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

[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

[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]

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

[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

[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.

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. :-)

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

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