* [elpa] excorporate.el:257:23:Error: Wrong type argument: listp, start-exco--fsm
@ 2016-07-08 10:56 Mario Lang
2016-07-08 18:34 ` Paul Eggert
0 siblings, 1 reply; 15+ messages in thread
From: Mario Lang @ 2016-07-08 10:56 UTC (permalink / raw
To: emacs-devel
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,
⡍⠁⠗⠊⠕
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [elpa] excorporate.el:257:23:Error: Wrong type argument: listp, start-exco--fsm
2016-07-08 10:56 [elpa] excorporate.el:257:23:Error: Wrong type argument: listp, start-exco--fsm Mario Lang
@ 2016-07-08 18:34 ` Paul Eggert
2016-07-08 20:12 ` Thomas Fitzsimmons
0 siblings, 1 reply; 15+ messages in thread
From: Paul Eggert @ 2016-07-08 18:34 UTC (permalink / raw
To: Mario Lang, emacs-devel
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [elpa] excorporate.el:257:23:Error: Wrong type argument: listp, start-exco--fsm
2016-07-08 18:34 ` Paul Eggert
@ 2016-07-08 20:12 ` Thomas Fitzsimmons
2016-07-10 13:08 ` Mario Lang
2016-07-10 13:08 ` bug#23920: [elpa] excorporate.el:257:23:Error: Wrong type argument: listp, start-exco--fsm Mario Lang
0 siblings, 2 replies; 15+ messages in thread
From: Thomas Fitzsimmons @ 2016-07-08 20:12 UTC (permalink / raw
To: Paul Eggert; +Cc: Mario Lang, emacs-devel
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#23920: [elpa] excorporate.el:257:23:Error: Wrong type argument: listp, start-exco--fsm
2016-07-08 20:12 ` Thomas Fitzsimmons
2016-07-10 13:08 ` Mario Lang
@ 2016-07-10 13:08 ` Mario Lang
2016-07-10 16:24 ` Thomas Fitzsimmons
1 sibling, 1 reply; 15+ messages in thread
From: Mario Lang @ 2016-07-10 13:08 UTC (permalink / raw
To: Thomas Fitzsimmons; +Cc: emacs-devel, 23920
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,
⡍⠁⠗⠊⠕
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [elpa] excorporate.el:257:23:Error: Wrong type argument: listp, start-exco--fsm
2016-07-08 20:12 ` Thomas Fitzsimmons
@ 2016-07-10 13:08 ` Mario Lang
2016-07-10 14:26 ` Stefan Monnier
2016-07-10 13:08 ` bug#23920: [elpa] excorporate.el:257:23:Error: Wrong type argument: listp, start-exco--fsm Mario Lang
1 sibling, 1 reply; 15+ messages in thread
From: Mario Lang @ 2016-07-10 13:08 UTC (permalink / raw
To: Thomas Fitzsimmons; +Cc: 23920, emacs-devel
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,
⡍⠁⠗⠊⠕
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [elpa] excorporate.el:257:23:Error: Wrong type argument: listp, start-exco--fsm
2016-07-10 13:08 ` Mario Lang
@ 2016-07-10 14:26 ` Stefan Monnier
2016-07-10 15:17 ` Thomas Fitzsimmons
0 siblings, 1 reply; 15+ messages in thread
From: Stefan Monnier @ 2016-07-10 14:26 UTC (permalink / raw
To: emacs-devel
> 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [elpa] excorporate.el:257:23:Error: Wrong type argument: listp, start-exco--fsm
2016-07-10 14:26 ` Stefan Monnier
@ 2016-07-10 15:17 ` Thomas Fitzsimmons
2016-07-10 15:20 ` Stefan Monnier
0 siblings, 1 reply; 15+ messages in thread
From: Thomas Fitzsimmons @ 2016-07-10 15:17 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [elpa] excorporate.el:257:23:Error: Wrong type argument: listp, start-exco--fsm
2016-07-10 15:17 ` Thomas Fitzsimmons
@ 2016-07-10 15:20 ` Stefan Monnier
2016-07-10 15:28 ` Stefan Monnier
0 siblings, 1 reply; 15+ messages in thread
From: Stefan Monnier @ 2016-07-10 15:20 UTC (permalink / raw
To: emacs-devel
> --- 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [elpa] excorporate.el:257:23:Error: Wrong type argument: listp, start-exco--fsm
2016-07-10 15:20 ` Stefan Monnier
@ 2016-07-10 15:28 ` Stefan Monnier
2016-07-10 16:22 ` Thomas Fitzsimmons
0 siblings, 1 reply; 15+ messages in thread
From: Stefan Monnier @ 2016-07-10 15:28 UTC (permalink / raw
To: emacs-devel
> 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [elpa] excorporate.el:257:23:Error: Wrong type argument: listp, start-exco--fsm
2016-07-10 15:28 ` Stefan Monnier
@ 2016-07-10 16:22 ` Thomas Fitzsimmons
2016-07-10 20:14 ` [elpa] packages/rudel/rudel-display.el:40:1:Error: eieio-oref called on a class: rudel-backend-factory Mario Lang
0 siblings, 1 reply; 15+ messages in thread
From: Thomas Fitzsimmons @ 2016-07-10 16:22 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#23920: [elpa] excorporate.el:257:23:Error: Wrong type argument: listp, start-exco--fsm
2016-07-10 13:08 ` bug#23920: [elpa] excorporate.el:257:23:Error: Wrong type argument: listp, start-exco--fsm Mario Lang
@ 2016-07-10 16:24 ` Thomas Fitzsimmons
0 siblings, 0 replies; 15+ messages in thread
From: Thomas Fitzsimmons @ 2016-07-10 16:24 UTC (permalink / raw
To: Mario Lang; +Cc: 23920-done
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [elpa] packages/rudel/rudel-display.el:40:1:Error: eieio-oref called on a class: rudel-backend-factory
2016-07-10 16:22 ` Thomas Fitzsimmons
@ 2016-07-10 20:14 ` Mario Lang
2016-07-10 21:27 ` Stefan Monnier
0 siblings, 1 reply; 15+ messages in thread
From: Mario Lang @ 2016-07-10 20:14 UTC (permalink / raw
To: emacs-devel
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,
⡍⠁⠗⠊⠕
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [elpa] packages/rudel/rudel-display.el:40:1:Error: eieio-oref called on a class: rudel-backend-factory
2016-07-10 20:14 ` [elpa] packages/rudel/rudel-display.el:40:1:Error: eieio-oref called on a class: rudel-backend-factory Mario Lang
@ 2016-07-10 21:27 ` Stefan Monnier
2016-07-10 22:19 ` Stefan Monnier
0 siblings, 1 reply; 15+ messages in thread
From: Stefan Monnier @ 2016-07-10 21:27 UTC (permalink / raw
To: emacs-devel
> 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [elpa] packages/rudel/rudel-display.el:40:1:Error: eieio-oref called on a class: rudel-backend-factory
2016-07-10 21:27 ` Stefan Monnier
@ 2016-07-10 22:19 ` Stefan Monnier
2016-07-12 21:52 ` Mario Lang
0 siblings, 1 reply; 15+ messages in thread
From: Stefan Monnier @ 2016-07-10 22:19 UTC (permalink / raw
To: emacs-devel
> 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [elpa] packages/rudel/rudel-display.el:40:1:Error: eieio-oref called on a class: rudel-backend-factory
2016-07-10 22:19 ` Stefan Monnier
@ 2016-07-12 21:52 ` Mario Lang
0 siblings, 0 replies; 15+ messages in thread
From: Mario Lang @ 2016-07-12 21:52 UTC (permalink / raw
To: emacs-devel
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,
⡍⠁⠗⠊⠕
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2016-07-12 21:52 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-07-08 10:56 [elpa] excorporate.el:257:23:Error: Wrong type argument: listp, start-exco--fsm Mario Lang
2016-07-08 18:34 ` Paul Eggert
2016-07-08 20:12 ` Thomas Fitzsimmons
2016-07-10 13:08 ` Mario Lang
2016-07-10 14:26 ` Stefan Monnier
2016-07-10 15:17 ` Thomas Fitzsimmons
2016-07-10 15:20 ` Stefan Monnier
2016-07-10 15:28 ` Stefan Monnier
2016-07-10 16:22 ` Thomas Fitzsimmons
2016-07-10 20:14 ` [elpa] packages/rudel/rudel-display.el:40:1:Error: eieio-oref called on a class: rudel-backend-factory Mario Lang
2016-07-10 21:27 ` Stefan Monnier
2016-07-10 22:19 ` Stefan Monnier
2016-07-12 21:52 ` Mario Lang
2016-07-10 13:08 ` bug#23920: [elpa] excorporate.el:257:23:Error: Wrong type argument: listp, start-exco--fsm Mario Lang
2016-07-10 16:24 ` Thomas Fitzsimmons
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.