[elpa] excorporate.el:257:23:Error: Wrong type argument: listp, start-exco--fsm

[elpa] excorporate.el:257:23:Error: Wrong type argument: listp, start-exco--fsm

[Mario Lang]

Hi.

Am I the only one how sees this error when trying to build elpa?

The error only shows up when the byte-compiler is used.
When the whole file is eval-buffer'd, there is no error.

To me, `define-state-machine' from fsm.el looks file.

Any ideas?

-- 
CYa,
  ⡍⠁⠗⠊⠕

Re: [elpa] excorporate.el:257:23:Error: Wrong type argument: listp, start-exco--fsm

[Paul Eggert]

On 07/08/2016 12:56 PM, Mario Lang wrote:
> Am I the only one how sees this error when trying to build elpa?

No, I also see it, with a plain 'make' at the top level, using emacs-25 
Emacs, and compiling the current bleeding-edge ELPA (commit 
a5d157b2e87427184f2c92a9b7bb9c99d6656aa1 dated June 30).That being said, 
I am by no means an ELPA expert (I first tried to build it today), and 
perhaps I am missing something too.

Re: [elpa] excorporate.el:257:23:Error: Wrong type argument: listp, start-exco--fsm

[Thomas Fitzsimmons]

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 07/08/2016 12:56 PM, Mario Lang wrote:
>> Am I the only one how sees this error when trying to build elpa?
>
> No, I also see it, with a plain 'make' at the top level, using
> emacs-25 Emacs, and compiling the current bleeding-edge ELPA (commit
> a5d157b2e87427184f2c92a9b7bb9c99d6656aa1 dated June 30).That being
> said, I am by no means an ELPA expert (I first tried to build it
> today), and perhaps I am missing something too.

I see it too.  If I build packages/fsm before building
packages/excorporate (by temporarily moving the directory out of
packages/), I don't get the error.

I filed a bug report to discuss further.

Thanks,
Thomas

bug#23920: [elpa] excorporate.el:257:23:Error: Wrong type argument: listp, start-exco--fsm

[Mario Lang]

Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:

> Paul Eggert <eggert@cs.ucla.edu> writes:
>
>> On 07/08/2016 12:56 PM, Mario Lang wrote:
>>> Am I the only one how sees this error when trying to build elpa?
>>
>> No, I also see it, with a plain 'make' at the top level, using
>> emacs-25 Emacs, and compiling the current bleeding-edge ELPA (commit
>> a5d157b2e87427184f2c92a9b7bb9c99d6656aa1 dated June 30).That being
>> said, I am by no means an ELPA expert (I first tried to build it
>> today), and perhaps I am missing something too.
>
> I see it too.  If I build packages/fsm before building
> packages/excorporate (by temporarily moving the directory out of
> packages/), I don't get the error.

That seems to be it.  If I add the following line to the top-level
GNUMakefile, "make" manages to build excorporate.elc just fine (there are
other errors now, particularily with the rudel package).

packages/excorporate/excorporate.elc: packages/fsm/fsm.elc

So the problem seems to be that compilation order is relevant.  If fsm
is loaded uncompiled, it fails.

I wonder if this is consider a bug in fsm.el, or if we shall add the
above quick fix to the GNUMakefile.

-- 
CYa,
  ⡍⠁⠗⠊⠕

bug#23920: [elpa] excorporate.el:257:23:Error: Wrong type argument: listp, start-exco--fsm

[Thomas Fitzsimmons]

Mario Lang <mlang@delysid.org> writes:

> Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:
>
>> Paul Eggert <eggert@cs.ucla.edu> writes:
>>
>>> On 07/08/2016 12:56 PM, Mario Lang wrote:
>>>> Am I the only one how sees this error when trying to build elpa?
>>>
>>> No, I also see it, with a plain 'make' at the top level, using
>>> emacs-25 Emacs, and compiling the current bleeding-edge ELPA (commit
>>> a5d157b2e87427184f2c92a9b7bb9c99d6656aa1 dated June 30).That being
>>> said, I am by no means an ELPA expert (I first tried to build it
>>> today), and perhaps I am missing something too.
>>
>> I see it too.  If I build packages/fsm before building
>> packages/excorporate (by temporarily moving the directory out of
>> packages/), I don't get the error.
>
> That seems to be it.  If I add the following line to the top-level
> GNUMakefile, "make" manages to build excorporate.elc just fine (there are
> other errors now, particularily with the rudel package).
>
> packages/excorporate/excorporate.elc: packages/fsm/fsm.elc
>
> So the problem seems to be that compilation order is relevant.  If fsm
> is loaded uncompiled, it fails.
>
> I wonder if this is consider a bug in fsm.el, or if we shall add the
> above quick fix to the GNUMakefile.

This is now fixed on master, by fsm.el 0.2.1.

Thomas

Re: [elpa] excorporate.el:257:23:Error: Wrong type argument: listp, start-exco--fsm

[Mario Lang]

Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:

> Paul Eggert <eggert@cs.ucla.edu> writes:
>
>> On 07/08/2016 12:56 PM, Mario Lang wrote:
>>> Am I the only one how sees this error when trying to build elpa?
>>
>> No, I also see it, with a plain 'make' at the top level, using
>> emacs-25 Emacs, and compiling the current bleeding-edge ELPA (commit
>> a5d157b2e87427184f2c92a9b7bb9c99d6656aa1 dated June 30).That being
>> said, I am by no means an ELPA expert (I first tried to build it
>> today), and perhaps I am missing something too.
>
> I see it too.  If I build packages/fsm before building
> packages/excorporate (by temporarily moving the directory out of
> packages/), I don't get the error.

That seems to be it.  If I add the following line to the top-level
GNUMakefile, "make" manages to build excorporate.elc just fine (there are
other errors now, particularily with the rudel package).

packages/excorporate/excorporate.elc: packages/fsm/fsm.elc

So the problem seems to be that compilation order is relevant.  If fsm
is loaded uncompiled, it fails.

I wonder if this is consider a bug in fsm.el, or if we shall add the
above quick fix to the GNUMakefile.

-- 
CYa,
  ⡍⠁⠗⠊⠕

Re: [elpa] excorporate.el:257:23:Error: Wrong type argument: listp, start-exco--fsm

[Stefan Monnier]

> So the problem seems to be that compilation order is relevant.  If fsm
> is loaded uncompiled, it fails.
> I wonder if this is consider a bug in fsm.el,

It does sound like a bug in fsm.el (tho it might be a bug
elsewhere, of course).

> or if we shall add the above quick fix to the GNUMakefile.

Not without first understanding the nature of the problem.


        Stefan

Re: [elpa] excorporate.el:257:23:Error: Wrong type argument: listp, start-exco--fsm

[Thomas Fitzsimmons]

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

>> So the problem seems to be that compilation order is relevant.  If fsm
>> is loaded uncompiled, it fails.
>> I wonder if this is consider a bug in fsm.el,
>
> It does sound like a bug in fsm.el (tho it might be a bug
> elsewhere, of course).
>
>> or if we shall add the above quick fix to the GNUMakefile.
>
> Not without first understanding the nature of the problem.

Agreed.  I've been experimenting with macro expansions of
define-state-machine.

I don't know the last time I did a clean build of ELPA, and that's the
only time it shows up (i.e., when fsm.elc doesn't exist yet).  Maybe
this won't have shown up in nightly builds for the same reason.  It'd be
interesting to know when it started happening, since I hadn't seen it
while building ELPA, before Mario's report.

When I added fsm.el to ELPA I changed it to use lexical binding.  The
issue seems to be related that, and to evaluating a lambda at macro
expansion time.  The compiler doesn't like the generated closure's
environment.

I test this patch, and it works:

--- a/packages/fsm/fsm.el
+++ b/packages/fsm/fsm.el
@@ -186,7 +186,7 @@ (cl-defmacro define-state-machine (name &key start sleep)
 	       (put fsm :name ',name)
 	       (put fsm :state nil)
 	       (put fsm :state-data nil)
-	       (put fsm :sleep ,(or sleep (lambda (secs)
+	       (put fsm :sleep ,(or sleep '(lambda (secs)
 					    (accept-process-output
 					     nil secs))))
 	       (put fsm :deferred nil)

But I'm still not sure exactly why the compiler complains about the
closure environment.

Thomas

Re: [elpa] excorporate.el:257:23:Error: Wrong type argument: listp, start-exco--fsm

[Stefan Monnier]

> --- a/packages/fsm/fsm.el
> +++ b/packages/fsm/fsm.el
> @@ -186,7 +186,7 @@ (cl-defmacro define-state-machine (name &key start sleep)
>  	       (put fsm :name ',name)
>  	       (put fsm :state nil)
>  	       (put fsm :state-data nil)
> -	       (put fsm :sleep ,(or sleep (lambda (secs)
> +	       (put fsm :sleep ,(or sleep '(lambda (secs)
>  					    (accept-process-output
>  					     nil secs))))
>  	       (put fsm :deferred nil)

This looks wrong.  it seems to indicate that somewhere else there's
a confusion between a value and an expression.


        Stefan

Re: [elpa] excorporate.el:257:23:Error: Wrong type argument: listp, start-exco--fsm

[Stefan Monnier]

> This looks wrong.  it seems to indicate that somewhere else there's
> a confusion between a value and an expression.

Actually no, it looks correct.  After all `sleep` is itself
an expression (i.e. if you use (define-state-machine foo :sleep (+ x y))
the (+ x y) is not executed at macro-expansion time but at subsequent
run-time), so you indeed want to return an expression and not a value,
hence the need to quote the lambda.


        Stefan

Re: [elpa] excorporate.el:257:23:Error: Wrong type argument: listp, start-exco--fsm

[Thomas Fitzsimmons]

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

>> This looks wrong.  it seems to indicate that somewhere else there's
>> a confusion between a value and an expression.
>
> Actually no, it looks correct.

[...]

Thanks, I pushed the fix to GNU ELPA and bumped fsm's version to 0.2.1.

Thomas

[elpa] packages/rudel/rudel-display.el:40:1:Error: eieio-oref called on a class: rudel-backend-factory

[Mario Lang]

Hi.

Now that fsm.el has been fixed (thanks), the elpa elc build fails in the rudel
package.

The problem seems to be in `eieio-oref' which looks a bit strange to me:

(defun eieio-oref (obj slot)
  "Return the value in OBJ at SLOT in the object vector."
  (declare (compiler-macro
            (lambda (exp)
              (ignore obj)
              (pcase slot
                ((and (or `',name (and name (pred keywordp)))
                      (guard (not (memq name eieio--known-slot-names))))
                 (macroexp--warn-and-return
                  (format-message "Unknown slot `%S'" name) exp 'compile-only))
                (_ exp)))))
  (cl-check-type slot symbol)
  (cl-check-type obj (or eieio-object class))
  (let* ((class (cond ((symbolp obj)
                       (error "eieio-oref called on a class: %s" obj)
                       (let ((c (cl--find-class obj)))
                         (if (eieio--class-p c) (eieio-class-un-autoload obj))
                         c))
                      (t (eieio--object-class obj))))
	 (c (eieio--slot-name-index class slot)))
    ...))

I have to admit that I don't grok eieio, but this piece of code looks
suspicious.  Wouldn't the code after the `error' call be dead?

On a somewhat related note, package rudel could use a port to cl-lib and
cl-generic.  Would that be a worthwhile change to make?

-- 
CYa,
  ⡍⠁⠗⠊⠕

Re: [elpa] packages/rudel/rudel-display.el:40:1:Error: eieio-oref called on a class: rudel-backend-factory

[Stefan Monnier]

> I have to admit that I don't grok eieio, but this piece of code looks
> suspicious.  Wouldn't the code after the `error' call be dead?

Yes, that code is dead, but I kept it for historical/testing reasons.
It should be removed nowadays.

> On a somewhat related note, package rudel could use a port to cl-lib and
> cl-generic.  Would that be a worthwhile change to make?

Yes.

As for the error in the title, I know I tracked it down and fixed it
somewhere at some point, but for some reasons I never pushed it, and now
I can't find the corresponding fix :-(

I'll see if it's on some of my other computers somewhere.


        Stefan

Re: [elpa] packages/rudel/rudel-display.el:40:1:Error: eieio-oref called on a class: rudel-backend-factory

[Stefan Monnier]

> As for the error in the title, I know I tracked it down and fixed it
> somewhere at some point, but for some reasons I never pushed it, and now
> I can't find the corresponding fix :-(

OK, found it.  But drowned in some attempt to use lexical-binding and cl-lib.
I tried to extract the relevant change and pushed it to elpa.git.

Can you try and see if it's working better now?


        Stefan

Re: [elpa] packages/rudel/rudel-display.el:40:1:Error: eieio-oref called on a class: rudel-backend-factory

[Mario Lang]

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

>> As for the error in the title, I know I tracked it down and fixed it
>> somewhere at some point, but for some reasons I never pushed it, and now
>> I can't find the corresponding fix :-(
>
> OK, found it.  But drowned in some attempt to use lexical-binding and cl-lib.
> I tried to extract the relevant change and pushed it to elpa.git.
>
> Can you try and see if it's working better now?

Yes, thank you.  All ELPA elcs now build fine.

-- 
CYa,
  ⡍⠁⠗⠊⠕