* bug#45610: 27.1; Symbol’s function definition is void: seq-concatenate
@ 2021-01-02 12:29 Leo Liu
2021-01-02 12:47 ` Eli Zaretskii
0 siblings, 1 reply; 14+ messages in thread
From: Leo Liu @ 2021-01-02 12:29 UTC (permalink / raw)
To: 45610
I have the following macro that is working until 27.1.
(defmacro cl-concatenatef (type place &rest sequences)
`(cl-callf2 cl-concatenate ,type ,place ,@sequences))
cl-concatenate is inlinable (since forever) as declared in cl-macs:
(cl-proclaim '(inline cl-acons cl-map cl-concatenate cl-notany
cl-notevery cl-revappend cl-nreconc gethash))
In 27.1 after expansion only (apply #'seq-concatenate type sequences)
remains bypassing the cl-concatenate autoload which is supposed to load
the dependency seq.el.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#45610: 27.1; Symbol’s function definition is void: seq-concatenate
2021-01-02 12:29 bug#45610: 27.1; Symbol’s function definition is void: seq-concatenate Leo Liu
@ 2021-01-02 12:47 ` Eli Zaretskii
2021-01-02 14:22 ` Leo Liu
0 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2021-01-02 12:47 UTC (permalink / raw)
To: Leo Liu; +Cc: 45610
> From: Leo Liu <sdl.web@gmail.com>
> Date: Sat, 02 Jan 2021 20:29:37 +0800
>
> I have the following macro that is working until 27.1.
>
> (defmacro cl-concatenatef (type place &rest sequences)
> `(cl-callf2 cl-concatenate ,type ,place ,@sequences))
>
> cl-concatenate is inlinable (since forever) as declared in cl-macs:
>
> (cl-proclaim '(inline cl-acons cl-map cl-concatenate cl-notany
> cl-notevery cl-revappend cl-nreconc gethash))
>
> In 27.1 after expansion only (apply #'seq-concatenate type sequences)
> remains bypassing the cl-concatenate autoload which is supposed to load
> the dependency seq.el.
What did that expand to in Emacs 26?
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#45610: 27.1; Symbol’s function definition is void: seq-concatenate
2021-01-02 12:47 ` Eli Zaretskii
@ 2021-01-02 14:22 ` Leo Liu
2021-01-02 14:25 ` Eli Zaretskii
0 siblings, 1 reply; 14+ messages in thread
From: Leo Liu @ 2021-01-02 14:22 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 45610
On 2021-01-02 14:47 +0200, Eli Zaretskii wrote:
> What did that expand to in Emacs 26?
The body of cl-concatenate before Emacs 27:
(pcase type
(`vector (apply #'vconcat sequences))
(`string (apply #'concat sequences))
(`list (apply #'append (append sequences '(nil))))
(_ (error "Not a sequence type name: %S" type)))
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#45610: 27.1; Symbol’s function definition is void: seq-concatenate
2021-01-02 14:22 ` Leo Liu
@ 2021-01-02 14:25 ` Eli Zaretskii
2021-01-02 16:07 ` Leo Liu
0 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2021-01-02 14:25 UTC (permalink / raw)
To: Leo Liu; +Cc: 45610
> From: Leo Liu <sdl.web@gmail.com>
> Cc: 45610@debbugs.gnu.org
> Date: Sat, 02 Jan 2021 22:22:35 +0800
>
> On 2021-01-02 14:47 +0200, Eli Zaretskii wrote:
> > What did that expand to in Emacs 26?
>
> The body of cl-concatenate before Emacs 27:
>
> (pcase type
> (`vector (apply #'vconcat sequences))
> (`string (apply #'concat sequences))
> (`list (apply #'append (append sequences '(nil))))
> (_ (error "Not a sequence type name: %S" type)))
Thanks. Then does the patch below fix the problem in Emacs 27.1?
diff --git a/lisp/emacs-lisp/cl-extra.el b/lisp/emacs-lisp/cl-extra.el
index 9c9da4a..a6e6619 100644
--- a/lisp/emacs-lisp/cl-extra.el
+++ b/lisp/emacs-lisp/cl-extra.el
@@ -556,6 +556,7 @@ cl-subseq
(defun cl-concatenate (type &rest sequences)
"Concatenate, into a sequence of type TYPE, the argument SEQUENCEs.
\n(fn TYPE SEQUENCE...)"
+ (require 'seq)
(apply #'seq-concatenate type sequences))
;;; List functions.
^ permalink raw reply related [flat|nested] 14+ messages in thread
* bug#45610: 27.1; Symbol’s function definition is void: seq-concatenate
2021-01-02 14:25 ` Eli Zaretskii
@ 2021-01-02 16:07 ` Leo Liu
2021-01-02 16:30 ` Eli Zaretskii
0 siblings, 1 reply; 14+ messages in thread
From: Leo Liu @ 2021-01-02 16:07 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 45610
On 2021-01-02 16:25 +0200, Eli Zaretskii wrote:
> Thanks. Then does the patch below fix the problem in Emacs 27.1?
Yes it does.
> diff --git a/lisp/emacs-lisp/cl-extra.el b/lisp/emacs-lisp/cl-extra.el
> index 9c9da4a..a6e6619 100644
> --- a/lisp/emacs-lisp/cl-extra.el
> +++ b/lisp/emacs-lisp/cl-extra.el
> @@ -556,6 +556,7 @@ cl-subseq
> (defun cl-concatenate (type &rest sequences)
> "Concatenate, into a sequence of type TYPE, the argument SEQUENCEs.
> \n(fn TYPE SEQUENCE...)"
> + (require 'seq)
> (apply #'seq-concatenate type sequences))
>
> ;;; List functions.
But it seems the function will become slower when called regularly
because of the (require 'seq).
Is it better to remove cl-concatenate from the cl-proclaim list in
cl-macs.el?
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#45610: 27.1; Symbol’s function definition is void: seq-concatenate
2021-01-02 16:07 ` Leo Liu
@ 2021-01-02 16:30 ` Eli Zaretskii
2021-01-02 16:35 ` Lars Ingebrigtsen
2021-01-02 16:45 ` Leo Liu
0 siblings, 2 replies; 14+ messages in thread
From: Eli Zaretskii @ 2021-01-02 16:30 UTC (permalink / raw)
To: Leo Liu, Stefan Monnier, Lars Ingebrigtsen; +Cc: 45610
> From: Leo Liu <sdl.web@gmail.com>
> Cc: 45610@debbugs.gnu.org
> Date: Sun, 03 Jan 2021 00:07:47 +0800
>
> On 2021-01-02 16:25 +0200, Eli Zaretskii wrote:
> > Thanks. Then does the patch below fix the problem in Emacs 27.1?
>
> Yes it does.
Then I'd like to push this fix to the release branch, but...
> > (defun cl-concatenate (type &rest sequences)
> > "Concatenate, into a sequence of type TYPE, the argument SEQUENCEs.
> > \n(fn TYPE SEQUENCE...)"
> > + (require 'seq)
> > (apply #'seq-concatenate type sequences))
> >
> > ;;; List functions.
>
> But it seems the function will become slower when called regularly
> because of the (require 'seq).
...slightly, yes.
> Is it better to remove cl-concatenate from the cl-proclaim list in
> cl-macs.el?
Wouldn't that make it even slower? And cause incompatibilities with
already byte-compiled files that saw the original cl-macs.el?
But I'm not an expert on these issues, so I'l defer to Stefan and Lars
here.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#45610: 27.1; Symbol’s function definition is void: seq-concatenate
2021-01-02 16:30 ` Eli Zaretskii
@ 2021-01-02 16:35 ` Lars Ingebrigtsen
2021-01-03 15:46 ` Eli Zaretskii
2021-01-02 16:45 ` Leo Liu
1 sibling, 1 reply; 14+ messages in thread
From: Lars Ingebrigtsen @ 2021-01-02 16:35 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 45610, Stefan Monnier, Leo Liu
Eli Zaretskii <eliz@gnu.org> writes:
> But I'm not an expert on these issues, so I'l defer to Stefan and Lars
> here.
Hey, what did I do? :-)
I think the easiest fix here is to put an autoload cookie on
seq-concatenate. But there may be something off on the macro expansion
that should be fixed instead, perhaps?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#45610: 27.1; Symbol’s function definition is void: seq-concatenate
2021-01-02 16:30 ` Eli Zaretskii
2021-01-02 16:35 ` Lars Ingebrigtsen
@ 2021-01-02 16:45 ` Leo Liu
1 sibling, 0 replies; 14+ messages in thread
From: Leo Liu @ 2021-01-02 16:45 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, Stefan Monnier, 45610
On 2021-01-02 18:30 +0200, Eli Zaretskii wrote:
> Wouldn't that make it even slower?
Indeed. But my suggestion to remove it was based on the fact that
cl-concatenate depends on another package at runtime, unlike other items
on that list.
> And cause incompatibilities with already byte-compiled files that saw
> the original cl-macs.el?
>
> But I'm not an expert on these issues, so I'l defer to Stefan and Lars
> here.
I am curious too.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#45610: 27.1; Symbol’s function definition is void: seq-concatenate
2021-01-02 16:35 ` Lars Ingebrigtsen
@ 2021-01-03 15:46 ` Eli Zaretskii
2021-01-03 16:19 ` Leo Liu
2021-01-04 5:39 ` Leo Liu
0 siblings, 2 replies; 14+ messages in thread
From: Eli Zaretskii @ 2021-01-03 15:46 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 45610, monnier, sdl.web
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Leo Liu <sdl.web@gmail.com>, Stefan Monnier <monnier@iro.umontreal.ca>,
> 45610@debbugs.gnu.org
> Date: Sat, 02 Jan 2021 17:35:08 +0100
>
> I think the easiest fix here is to put an autoload cookie on
> seq-concatenate.
Leo, does this work for your use case? In your opinion, is this
better than my suggestion?
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#45610: 27.1; Symbol’s function definition is void: seq-concatenate
2021-01-03 15:46 ` Eli Zaretskii
@ 2021-01-03 16:19 ` Leo Liu
2021-01-04 5:39 ` Leo Liu
1 sibling, 0 replies; 14+ messages in thread
From: Leo Liu @ 2021-01-03 16:19 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, 45610, monnier
On 2021-01-03 17:46 +0200, Eli Zaretskii wrote:
> Leo, does this work for your use case? In your opinion, is this
> better than my suggestion?
Yes autoload works too.
I was hesitant to suggest it because the autoload (cookie) would live
too far away from cl-concatenate.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#45610: 27.1; Symbol’s function definition is void: seq-concatenate
2021-01-03 15:46 ` Eli Zaretskii
2021-01-03 16:19 ` Leo Liu
@ 2021-01-04 5:39 ` Leo Liu
2021-01-04 15:07 ` Eli Zaretskii
1 sibling, 1 reply; 14+ messages in thread
From: Leo Liu @ 2021-01-04 5:39 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, 45610, monnier
On 2021-01-03 17:46 +0200, Eli Zaretskii wrote:
> In your opinion, is this better than my suggestion?
I didn't comment much on this point last night.
Adding (require 'seq) to cl-concatenate is probably the least favourable
because it also defeats the purpose of the `inline' cl-proclaim.
Adding autoload cookie for seq-concatenate is simple though not the
cleanest, IOW, we have the workings of cl-concatenate in some situations
depend on the autoload cookie. But this is not uncommon practice.
Given the dilemma we are in I wonder if the considerations for `inline'
cl-concatenate in the first place are no longer applicable.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#45610: 27.1; Symbol’s function definition is void: seq-concatenate
2021-01-04 5:39 ` Leo Liu
@ 2021-01-04 15:07 ` Eli Zaretskii
2021-01-04 17:35 ` Stefan Monnier
0 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2021-01-04 15:07 UTC (permalink / raw)
To: Leo Liu; +Cc: larsi, 45610, monnier
> From: Leo Liu <sdl.web@gmail.com>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 45610@debbugs.gnu.org, monnier@iro.umontreal.ca
> Date: Mon, 04 Jan 2021 13:39:03 +0800
>
> On 2021-01-03 17:46 +0200, Eli Zaretskii wrote:
> > In your opinion, is this better than my suggestion?
>
> I didn't comment much on this point last night.
>
> Adding (require 'seq) to cl-concatenate is probably the least favourable
> because it also defeats the purpose of the `inline' cl-proclaim.
>
> Adding autoload cookie for seq-concatenate is simple though not the
> cleanest, IOW, we have the workings of cl-concatenate in some situations
> depend on the autoload cookie. But this is not uncommon practice.
>
> Given the dilemma we are in I wonder if the considerations for `inline'
> cl-concatenate in the first place are no longer applicable.
Thanks.
Stefan, any comments? My personal tendency is to add the autoload
cookie, with a comment saying that cl-concatenate needs that. At
least on the emacs-27 branch. Any problems or issues with that? What
do people think about removing cl-concatenate from the inline
declaration (on master)?
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#45610: 27.1; Symbol’s function definition is void: seq-concatenate
2021-01-04 15:07 ` Eli Zaretskii
@ 2021-01-04 17:35 ` Stefan Monnier
2021-01-09 12:13 ` Eli Zaretskii
0 siblings, 1 reply; 14+ messages in thread
From: Stefan Monnier @ 2021-01-04 17:35 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: larsi, Leo Liu, 45610
> Stefan, any comments? My personal tendency is to add the autoload
> cookie, with a comment saying that cl-concatenate needs that. At
> least on the emacs-27 branch. Any problems or issues with that?
Sounds good to me.
> What do people think about removing cl-concatenate from the inline
> declaration (on master)?
Fine by me as well,
Stefan
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#45610: 27.1; Symbol’s function definition is void: seq-concatenate
2021-01-04 17:35 ` Stefan Monnier
@ 2021-01-09 12:13 ` Eli Zaretskii
0 siblings, 0 replies; 14+ messages in thread
From: Eli Zaretskii @ 2021-01-09 12:13 UTC (permalink / raw)
To: Stefan Monnier; +Cc: larsi, sdl.web, 45610-done
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Leo Liu <sdl.web@gmail.com>, larsi@gnus.org, 45610@debbugs.gnu.org
> Date: Mon, 04 Jan 2021 12:35:13 -0500
>
> > Stefan, any comments? My personal tendency is to add the autoload
> > cookie, with a comment saying that cl-concatenate needs that. At
> > least on the emacs-27 branch. Any problems or issues with that?
>
> Sounds good to me.
>
> > What do people think about removing cl-concatenate from the inline
> > declaration (on master)?
>
> Fine by me as well,
I've now done both, and I'm closing this bug.
Thanks.
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2021-01-09 12:13 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-02 12:29 bug#45610: 27.1; Symbol’s function definition is void: seq-concatenate Leo Liu
2021-01-02 12:47 ` Eli Zaretskii
2021-01-02 14:22 ` Leo Liu
2021-01-02 14:25 ` Eli Zaretskii
2021-01-02 16:07 ` Leo Liu
2021-01-02 16:30 ` Eli Zaretskii
2021-01-02 16:35 ` Lars Ingebrigtsen
2021-01-03 15:46 ` Eli Zaretskii
2021-01-03 16:19 ` Leo Liu
2021-01-04 5:39 ` Leo Liu
2021-01-04 15:07 ` Eli Zaretskii
2021-01-04 17:35 ` Stefan Monnier
2021-01-09 12:13 ` Eli Zaretskii
2021-01-02 16:45 ` Leo Liu
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).