unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Should we just start dumping cl-lib?
@ 2015-10-02  4:52 Daniel Colascione
  2015-10-02  5:12 ` John Wiegley
  2015-10-02 11:46 ` Mark Oteiza
  0 siblings, 2 replies; 24+ messages in thread
From: Daniel Colascione @ 2015-10-02  4:52 UTC (permalink / raw)
  To: Emacs developers

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

Commit d605a539d4863c7e7c66aaea6e538ae14c47f3d7 broke Emacs when winner
was enabled without cl-lib being loaded. Nobody seems to have noticed
until now, which suggests that either almost nobody uses winner, or
almost everybody has cl-lib loaded anyway. Maybe it's time to just dump
cl-lib with Emacs.


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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Should we just start dumping cl-lib?
  2015-10-02  4:52 Should we just start dumping cl-lib? Daniel Colascione
@ 2015-10-02  5:12 ` John Wiegley
  2015-10-02  5:28   ` Daniel Colascione
  2015-10-02 11:46 ` Mark Oteiza
  1 sibling, 1 reply; 24+ messages in thread
From: John Wiegley @ 2015-10-02  5:12 UTC (permalink / raw)
  To: emacs-devel

>>>>> Daniel Colascione <dancol@dancol.org> writes:

> Commit d605a539d4863c7e7c66aaea6e538ae14c47f3d7 broke Emacs when winner was
> enabled without cl-lib being loaded. Nobody seems to have noticed until now,
> which suggests that either almost nobody uses winner, or almost everybody
> has cl-lib loaded anyway. Maybe it's time to just dump cl-lib with Emacs.

I use winner, but always have cl-lib loaded. As for dumping it into Emacs; is
there a precedent for including Lisp libraries of this type into core?

John



^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Should we just start dumping cl-lib?
  2015-10-02  5:12 ` John Wiegley
@ 2015-10-02  5:28   ` Daniel Colascione
  2015-10-02  7:19     ` Eli Zaretskii
  2015-10-02  7:21     ` Oleh Krehel
  0 siblings, 2 replies; 24+ messages in thread
From: Daniel Colascione @ 2015-10-02  5:28 UTC (permalink / raw)
  To: emacs-devel

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

On 10/01/2015 10:12 PM, John Wiegley wrote:
>>>>>> Daniel Colascione <dancol@dancol.org> writes:
> 
>> Commit d605a539d4863c7e7c66aaea6e538ae14c47f3d7 broke Emacs when winner was
>> enabled without cl-lib being loaded. Nobody seems to have noticed until now,
>> which suggests that either almost nobody uses winner, or almost everybody
>> has cl-lib loaded anyway. Maybe it's time to just dump cl-lib with Emacs.
> 
> I use winner, but always have cl-lib loaded.

So does almost everyone else, apparently. So let's save everyone some
initialization CPU time and preload cl-lib.

> As for dumping it into Emacs; is
> there a precedent for including Lisp libraries of this type into core?

XEmacs does it.


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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Should we just start dumping cl-lib?
  2015-10-02  5:28   ` Daniel Colascione
@ 2015-10-02  7:19     ` Eli Zaretskii
  2015-10-02  8:07       ` Eli Zaretskii
  2015-10-02  8:23       ` Artur Malabarba
  2015-10-02  7:21     ` Oleh Krehel
  1 sibling, 2 replies; 24+ messages in thread
From: Eli Zaretskii @ 2015-10-02  7:19 UTC (permalink / raw)
  To: Daniel Colascione; +Cc: emacs-devel

> From: Daniel Colascione <dancol@dancol.org>
> Date: Thu, 1 Oct 2015 22:28:53 -0700
> 
> >> Commit d605a539d4863c7e7c66aaea6e538ae14c47f3d7 broke Emacs when winner was
> >> enabled without cl-lib being loaded. Nobody seems to have noticed until now,
> >> which suggests that either almost nobody uses winner, or almost everybody
> >> has cl-lib loaded anyway. Maybe it's time to just dump cl-lib with Emacs.
> > 
> > I use winner, but always have cl-lib loaded.
> 
> So does almost everyone else, apparently.

Only those who use winner, apparently.  This incident tells us nothing
about those who don't use winner, right?

> So let's save everyone some initialization CPU time and preload
> cl-lib.

Up until now, the rules for pre-loading package X were that either
(a) some preloaded package requires X, or (b) X will be auto-loaded at
the beginning of every session by some very frequent operation, like
visiting the first file or creating a window or a frame.

Since winner is itself an optional package that not everyone uses
(e.g., I don't), this case doesn't seem to qualify, IMO.



^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Should we just start dumping cl-lib?
  2015-10-02  5:28   ` Daniel Colascione
  2015-10-02  7:19     ` Eli Zaretskii
@ 2015-10-02  7:21     ` Oleh Krehel
  1 sibling, 0 replies; 24+ messages in thread
From: Oleh Krehel @ 2015-10-02  7:21 UTC (permalink / raw)
  To: Daniel Colascione; +Cc: emacs-devel

Daniel Colascione <dancol@dancol.org> writes:

> So does almost everyone else, apparently. So let's save everyone some
> initialization CPU time and preload cl-lib.

I'm all for it. I can't imagine using Emacs without loading cl-lib.

    Oleh



^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Should we just start dumping cl-lib?
  2015-10-02  7:19     ` Eli Zaretskii
@ 2015-10-02  8:07       ` Eli Zaretskii
  2015-10-02  8:23       ` Artur Malabarba
  1 sibling, 0 replies; 24+ messages in thread
From: Eli Zaretskii @ 2015-10-02  8:07 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: dancol, emacs-devel

> Date: Fri, 02 Oct 2015 10:19:12 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> Up until now, the rules for pre-loading package X were that either
> (a) some preloaded package requires X, or (b) X will be auto-loaded at
> the beginning of every session by some very frequent operation, like
> visiting the first file or creating a window or a frame.
> 
> Since winner is itself an optional package that not everyone uses
> (e.g., I don't), this case doesn't seem to qualify, IMO.

OTOH, visiting a C file or a file in Outline mode loads cl-lib, so
perhaps it's indeed time to preload it.



^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Should we just start dumping cl-lib?
  2015-10-02  7:19     ` Eli Zaretskii
  2015-10-02  8:07       ` Eli Zaretskii
@ 2015-10-02  8:23       ` Artur Malabarba
  2015-10-02 12:21         ` Andreas Schwab
  1 sibling, 1 reply; 24+ messages in thread
From: Artur Malabarba @ 2015-10-02  8:23 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Daniel Colascione, emacs-devel

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

> Up until now, the rules for pre-loading package X were that either
> (a) some preloaded package requires X, or (b) X will be auto-loaded at
> the beginning of every session by some very frequent operation, like
> visiting the first file or creating a window or a frame.
>
> Since winner is itself an optional package that not everyone uses
> (e.g., I don't), this case doesn't seem to qualify, IMO.

This might still be an instance of (b), given how many packages require
cl-lib. It would be useful if someone grepped together a list of all such
packages so we could figure how often it'll just be loaded at startup
anyway.

[-- Attachment #2: Type: text/html, Size: 722 bytes --]

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Should we just start dumping cl-lib?
  2015-10-02  4:52 Should we just start dumping cl-lib? Daniel Colascione
  2015-10-02  5:12 ` John Wiegley
@ 2015-10-02 11:46 ` Mark Oteiza
  2015-10-02 13:37   ` Tassilo Horn
                     ` (2 more replies)
  1 sibling, 3 replies; 24+ messages in thread
From: Mark Oteiza @ 2015-10-02 11:46 UTC (permalink / raw)
  To: emacs-devel

Daniel Colascione <dancol@dancol.org> writes:

> Commit d605a539d4863c7e7c66aaea6e538ae14c47f3d7 broke Emacs when winner
> was enabled without cl-lib being loaded. Nobody seems to have noticed
> until now, which suggests that either almost nobody uses winner, or
> almost everybody has cl-lib loaded anyway. Maybe it's time to just dump
> cl-lib with Emacs.

Bug#21549

I'd be happy to have more useful functions in "core". (Can we have
`filter` yet?)



^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Should we just start dumping cl-lib?
  2015-10-02  8:23       ` Artur Malabarba
@ 2015-10-02 12:21         ` Andreas Schwab
  2015-10-02 12:38           ` Artur Malabarba
  0 siblings, 1 reply; 24+ messages in thread
From: Andreas Schwab @ 2015-10-02 12:21 UTC (permalink / raw)
  To: Artur Malabarba; +Cc: Eli Zaretskii, Daniel Colascione, emacs-devel

Artur Malabarba <bruce.connor.am@gmail.com> writes:

> This might still be an instance of (b), given how many packages require
> cl-lib.

They should require it only during compiling.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."



^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Should we just start dumping cl-lib?
  2015-10-02 12:21         ` Andreas Schwab
@ 2015-10-02 12:38           ` Artur Malabarba
  2015-10-02 14:27             ` Rasmus
  0 siblings, 1 reply; 24+ messages in thread
From: Artur Malabarba @ 2015-10-02 12:38 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: Eli Zaretskii, Daniel Colascione, emacs-devel

2015-10-02 13:21 GMT+01:00 Andreas Schwab <schwab@linux-m68k.org>:
> They should require it only during compiling.

That's only viable if they only use macros. Many of them use functions
from cl-lib so they need a proper require.

Below is a list of all files which grep for ^(require 'cl-lib), which
means they require it at runtime. If any of these are expected to be
loaded at the start of every session, then we should either fix that
require or preload cl-lib.
The ones tat catch my attention are vc.el and help-mode.el.

man.el:92
emacs-lisp/cl.el:30
emacs-lisp/cl-extra.el:40
emacs-lisp/edebug.el:56
emacs-lisp/cl-seq.el:44
emacs-lisp/ert.el:60
emacs-lisp/generator.el:79
emacs-lisp/cl-macs.el:46
emacs-lisp/eieio-core.el:34
dom.el:27
calendar/parse-time.el:37
calendar/todo-mode.el:57
doc-view.el:139
frameset.el:41
wid-edit.el:58
edmacro.el:66
url/url-http.el:28
midnight.el:39
shadowfile.el:78
vc/vc.el:710
vc/ediff-init.el:27
eshell/em-ls.el:29
eshell/em-term.el:34
image-dired.el:159
profiler.el:29
desktop.el:138
progmodes/sql.el:229
progmodes/hideif.el:107
progmodes/ebrowse.el:36
progmodes/xref.el:53
progmodes/gdb-mi.el:94
progmodes/python.el:262
thumbs.el:60
help-mode.el:33
help-fns.el:35
net/gnutls.el:38
net/rcirc.el:46
net/nsm.el:27
net/sasl-scram-rfc.el:40
woman.el:417



^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Should we just start dumping cl-lib?
  2015-10-02 11:46 ` Mark Oteiza
@ 2015-10-02 13:37   ` Tassilo Horn
  2015-10-02 15:22     ` Artur Malabarba
  2015-10-02 13:45   ` Eli Zaretskii
  2015-10-02 15:13   ` Nicolas Petton
  2 siblings, 1 reply; 24+ messages in thread
From: Tassilo Horn @ 2015-10-02 13:37 UTC (permalink / raw)
  To: Mark Oteiza; +Cc: emacs-devel

Mark Oteiza <mvoteiza@udel.edu> writes:

>> Commit d605a539d4863c7e7c66aaea6e538ae14c47f3d7 broke Emacs when
>> winner was enabled without cl-lib being loaded. Nobody seems to have
>> noticed until now, which suggests that either almost nobody uses
>> winner, or almost everybody has cl-lib loaded anyway. Maybe it's time
>> to just dump cl-lib with Emacs.
>
> Bug#21549
>
> I'd be happy to have more useful functions in "core". (Can we have
> `filter` yet?)

There are `seq-filter', `seq-remove', `seq-map', `seq-mapcat',
`seq-reduce', etc. in the new seq.el, and a nice API for associative
structures in map.el which are in "core" although not dumped just like
cl-lib.

Many seq.el functions have cl-lib counterparts which do pretty much the
same.  So the decision if cl-lib should be dumped is also a strategic
decision.  Do we want to advocate seq.el or cl-lib?  (Well, right now
seq.el depends on cl-lib so we couldn't dump seq.el without cl-lib but
anyway...)

Bye,
Tassilo



^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Should we just start dumping cl-lib?
  2015-10-02 11:46 ` Mark Oteiza
  2015-10-02 13:37   ` Tassilo Horn
@ 2015-10-02 13:45   ` Eli Zaretskii
  2015-10-02 14:14     ` Mark Oteiza
  2015-10-02 16:07     ` John Wiegley
  2015-10-02 15:13   ` Nicolas Petton
  2 siblings, 2 replies; 24+ messages in thread
From: Eli Zaretskii @ 2015-10-02 13:45 UTC (permalink / raw)
  To: Mark Oteiza; +Cc: emacs-devel

> From: Mark Oteiza <mvoteiza@udel.edu>
> Date: Fri, 02 Oct 2015 07:46:46 -0400
> 
> I'd be happy to have more useful functions in "core". (Can we have
> `filter` yet?)

Please always accompany such suggestions with rationale.  Adding to
the core just because "why not?" is IMO not a good methodology.  Some
people still care about the memory footprint of programs, so we don't
want to bloat that unless there are good reasons.  Such reasons can
only be discussed on a case by case basis.



^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Should we just start dumping cl-lib?
  2015-10-02 13:45   ` Eli Zaretskii
@ 2015-10-02 14:14     ` Mark Oteiza
  2015-10-02 14:18       ` Eli Zaretskii
  2015-10-02 16:07     ` John Wiegley
  1 sibling, 1 reply; 24+ messages in thread
From: Mark Oteiza @ 2015-10-02 14:14 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

On 02/10/15 at 04:45pm, Eli Zaretskii wrote:
> > From: Mark Oteiza <mvoteiza@udel.edu>
> > Date: Fri, 02 Oct 2015 07:46:46 -0400
> > 
> > I'd be happy to have more useful functions in "core". (Can we have
> > `filter` yet?)
> 
> Please always accompany such suggestions with rationale.  Adding to
> the core just because "why not?" is IMO not a good methodology.  Some
> people still care about the memory footprint of programs, so we don't
> want to bloat that unless there are good reasons.  Such reasons can
> only be discussed on a case by case basis.

Understood, thanks.

Regarding the breakage with winner.el, I don't understand why under some
circumstances nothing seems to break if cl- functions are used at
runtime in things with only `(eval-when-compile (require 'cl-lib))`. For
instance, git-grepping for 'cl-remove-if' I see package.el and
checkdoc.el don't require cl-lib at runtime.



^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Should we just start dumping cl-lib?
  2015-10-02 14:14     ` Mark Oteiza
@ 2015-10-02 14:18       ` Eli Zaretskii
  2015-10-02 14:22         ` Mark Oteiza
  0 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2015-10-02 14:18 UTC (permalink / raw)
  To: Mark Oteiza; +Cc: emacs-devel

> Date: Fri, 2 Oct 2015 10:14:52 -0400
> From: Mark Oteiza <mvoteiza@udel.edu>
> Cc: emacs-devel@gnu.org
> 
> Regarding the breakage with winner.el, I don't understand why under some
> circumstances nothing seems to break if cl- functions are used at
> runtime in things with only `(eval-when-compile (require 'cl-lib))`. For
> instance, git-grepping for 'cl-remove-if' I see package.el and
> checkdoc.el don't require cl-lib at runtime.

Are the cl-lib functions they use auto-loaded, perhaps?



^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Should we just start dumping cl-lib?
  2015-10-02 14:18       ` Eli Zaretskii
@ 2015-10-02 14:22         ` Mark Oteiza
  2015-10-02 14:38           ` Eli Zaretskii
  0 siblings, 1 reply; 24+ messages in thread
From: Mark Oteiza @ 2015-10-02 14:22 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

On 02/10/15 at 05:18pm, Eli Zaretskii wrote:
> > Date: Fri, 2 Oct 2015 10:14:52 -0400
> > From: Mark Oteiza <mvoteiza@udel.edu>
> > Cc: emacs-devel@gnu.org
> > 
> > Regarding the breakage with winner.el, I don't understand why under some
> > circumstances nothing seems to break if cl- functions are used at
> > runtime in things with only `(eval-when-compile (require 'cl-lib))`. For
> > instance, git-grepping for 'cl-remove-if' I see package.el and
> > checkdoc.el don't require cl-lib at runtime.
> 
> Are the cl-lib functions they use auto-loaded, perhaps?

Yes. However, it was an issue in winner.el--why not in these libraries?



^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Should we just start dumping cl-lib?
  2015-10-02 12:38           ` Artur Malabarba
@ 2015-10-02 14:27             ` Rasmus
  0 siblings, 0 replies; 24+ messages in thread
From: Rasmus @ 2015-10-02 14:27 UTC (permalink / raw)
  To: emacs-devel

Hi,

Artur Malabarba <bruce.connor.am@gmail.com> writes:

> Below is a list of all files which grep for ^(require 'cl-lib), which
> means they require it at runtime. If any of these are expected to be
> loaded at the start of every session, then we should either fix that
> require or preload cl-lib.

Plus some libraries "reimplement" cl functions.  Org for sure, but I
/think/ also Gnus (but I'm guessing here).  This is not necessarily bad as
not all Emacsens have cl-lib; still it would be nicer to rely on cl-lib.

Rasmus

-- 
Sådan en god dansk lagereddike kan man slet ikke bruge mere




^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Should we just start dumping cl-lib?
  2015-10-02 14:22         ` Mark Oteiza
@ 2015-10-02 14:38           ` Eli Zaretskii
  0 siblings, 0 replies; 24+ messages in thread
From: Eli Zaretskii @ 2015-10-02 14:38 UTC (permalink / raw)
  To: Mark Oteiza; +Cc: emacs-devel

> Date: Fri, 2 Oct 2015 10:22:40 -0400
> From: Mark Oteiza <mvoteiza@udel.edu>
> Cc: emacs-devel@gnu.org
> 
> On 02/10/15 at 05:18pm, Eli Zaretskii wrote:
> > > Date: Fri, 2 Oct 2015 10:14:52 -0400
> > > From: Mark Oteiza <mvoteiza@udel.edu>
> > > Cc: emacs-devel@gnu.org
> > > 
> > > Regarding the breakage with winner.el, I don't understand why under some
> > > circumstances nothing seems to break if cl- functions are used at
> > > runtime in things with only `(eval-when-compile (require 'cl-lib))`. For
> > > instance, git-grepping for 'cl-remove-if' I see package.el and
> > > checkdoc.el don't require cl-lib at runtime.
> > 
> > Are the cl-lib functions they use auto-loaded, perhaps?
> 
> Yes. However, it was an issue in winner.el--why not in these libraries?

The issue in winner.el, AFAIU, was under very specific circumstances.
Perhaps under those circumstances, those other packages will also have
some problem.

I'd suggest to dig into the problem with winner and understand why it
happens in that specific situation.  E.g., perhaps load-path is not
yet set when the custom file is loaded?



^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Should we just start dumping cl-lib?
  2015-10-02 11:46 ` Mark Oteiza
  2015-10-02 13:37   ` Tassilo Horn
  2015-10-02 13:45   ` Eli Zaretskii
@ 2015-10-02 15:13   ` Nicolas Petton
  2 siblings, 0 replies; 24+ messages in thread
From: Nicolas Petton @ 2015-10-02 15:13 UTC (permalink / raw)
  To: Mark Oteiza, emacs-devel

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

Mark Oteiza <mvoteiza@udel.edu> writes:

> Daniel Colascione <dancol@dancol.org> writes:
>
>> Commit d605a539d4863c7e7c66aaea6e538ae14c47f3d7 broke Emacs when winner
>> was enabled without cl-lib being loaded. Nobody seems to have noticed
>> until now, which suggests that either almost nobody uses winner, or
>> almost everybody has cl-lib loaded anyway. Maybe it's time to just dump
>> cl-lib with Emacs.
>
> Bug#21549
>
> I'd be happy to have more useful functions in "core". (Can we have
> `filter` yet?)

It's not in "core", it's not preloaded, but seq.el provides useful
additional sequence-manipulation functions such as `seq-filter'.

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Should we just start dumping cl-lib?
  2015-10-02 13:37   ` Tassilo Horn
@ 2015-10-02 15:22     ` Artur Malabarba
  0 siblings, 0 replies; 24+ messages in thread
From: Artur Malabarba @ 2015-10-02 15:22 UTC (permalink / raw)
  To: emacs-devel, Mark Oteiza

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

I agree. seq-filter is fine and seq.el is bundled with Emacs, so it should
be enough. There's also an equivalent in cl under a different name.

We have enough unprefixed symbols already, let's not start adding more
unless they are very basic things like `def` macros or flow control macros.

On 2 Oct 2015 2:37 pm, "Tassilo Horn" <tsdh@gnu.org> wrote:
>
> Mark Oteiza <mvoteiza@udel.edu> writes:
>
> >> Commit d605a539d4863c7e7c66aaea6e538ae14c47f3d7 broke Emacs when
> >> winner was enabled without cl-lib being loaded. Nobody seems to have
> >> noticed until now, which suggests that either almost nobody uses
> >> winner, or almost everybody has cl-lib loaded anyway. Maybe it's time
> >> to just dump cl-lib with Emacs.
> >
> > Bug#21549
> >
> > I'd be happy to have more useful functions in "core". (Can we have
> > `filter` yet?)
>
> There are `seq-filter', `seq-remove', `seq-map', `seq-mapcat',
> `seq-reduce', etc. in the new seq.el, and a nice API for associative
> structures in map.el which are in "core" although not dumped just like
> cl-lib.
>
> Many seq.el functions have cl-lib counterparts which do pretty much the
> same.  So the decision if cl-lib should be dumped is also a strategic
> decision.  Do we want to advocate seq.el or cl-lib?  (Well, right now
> seq.el depends on cl-lib so we couldn't dump seq.el without cl-lib but
> anyway...)
>
> Bye,
> Tassilo
>

[-- Attachment #2: Type: text/html, Size: 1875 bytes --]

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Should we just start dumping cl-lib?
  2015-10-02 13:45   ` Eli Zaretskii
  2015-10-02 14:14     ` Mark Oteiza
@ 2015-10-02 16:07     ` John Wiegley
  2015-10-03  0:19       ` Daniel Colascione
  1 sibling, 1 reply; 24+ messages in thread
From: John Wiegley @ 2015-10-02 16:07 UTC (permalink / raw)
  To: emacs-devel

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> Please always accompany such suggestions with rationale. Adding to the core
> just because "why not?" is IMO not a good methodology. Some people still
> care about the memory footprint of programs, so we don't want to bloat that
> unless there are good reasons. Such reasons can only be discussed on a case
> by case basis.

Although personally I wouldn't mind seeing cl-lib in core, for the benefit of
Emacs I have to agree with Eli. It's not something we should do just because
it sounds like a good idea, but because not doing it would cost us something.
Shaving a few milliseconds from startup is not enough of a gain to be worth
bloating core.

John



^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Should we just start dumping cl-lib?
  2015-10-02 16:07     ` John Wiegley
@ 2015-10-03  0:19       ` Daniel Colascione
  2015-10-03  7:22         ` Eli Zaretskii
  0 siblings, 1 reply; 24+ messages in thread
From: Daniel Colascione @ 2015-10-03  0:19 UTC (permalink / raw)
  To: emacs-devel

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

On 10/02/2015 09:07 AM, John Wiegley wrote:
>>>>>> Eli Zaretskii <eliz@gnu.org> writes:
> 
>> Please always accompany such suggestions with rationale. Adding to the core
>> just because "why not?" is IMO not a good methodology. Some people still
>> care about the memory footprint of programs, so we don't want to bloat that
>> unless there are good reasons. Such reasons can only be discussed on a case
>> by case basis.
> 
> Although personally I wouldn't mind seeing cl-lib in core, for the benefit of
> Emacs I have to agree with Eli. It's not something we should do just because
> it sounds like a good idea, but because not doing it would cost us something.
> Shaving a few milliseconds from startup is not enough of a gain to be worth
> bloating core.

What's the cost of increasing the size of the dumped image? We don't
take COW faults on most of the pages, so we can discard them at will.
Because the OS can discard clean pages without writing them to the
pagefile and reconstitute them at will, transferring code from Emacs
private allocations to the dumped Emacs image _decreases_ memory
footprint. That we also shave a few milliseconds off startup is another
benefit.

If not cl-lib, then what? What is the actual bar?


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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Should we just start dumping cl-lib?
  2015-10-03  0:19       ` Daniel Colascione
@ 2015-10-03  7:22         ` Eli Zaretskii
  2015-10-04  1:24           ` Daniel Colascione
  0 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2015-10-03  7:22 UTC (permalink / raw)
  To: Daniel Colascione; +Cc: emacs-devel

> From: Daniel Colascione <dancol@dancol.org>
> Date: Fri, 2 Oct 2015 17:19:45 -0700
> 
> On 10/02/2015 09:07 AM, John Wiegley wrote:
> >>>>>> Eli Zaretskii <eliz@gnu.org> writes:
> > 
> >> Please always accompany such suggestions with rationale. Adding to the core
> >> just because "why not?" is IMO not a good methodology. Some people still
> >> care about the memory footprint of programs, so we don't want to bloat that
> >> unless there are good reasons. Such reasons can only be discussed on a case
> >> by case basis.
> > 
> > Although personally I wouldn't mind seeing cl-lib in core, for the benefit of
> > Emacs I have to agree with Eli. It's not something we should do just because
> > it sounds like a good idea, but because not doing it would cost us something.
> > Shaving a few milliseconds from startup is not enough of a gain to be worth
> > bloating core.
> 
> What's the cost of increasing the size of the dumped image? We don't
> take COW faults on most of the pages, so we can discard them at will.
> Because the OS can discard clean pages without writing them to the
> pagefile and reconstitute them at will, transferring code from Emacs
> private allocations to the dumped Emacs image _decreases_ memory
> footprint. That we also shave a few milliseconds off startup is another
> benefit.
> 
> If not cl-lib, then what? What is the actual bar?

Did you miss my further message where I said we should probably
preload cl-lib, because many popular commands in a fresh session load
it anyway?



^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Should we just start dumping cl-lib?
  2015-10-03  7:22         ` Eli Zaretskii
@ 2015-10-04  1:24           ` Daniel Colascione
  2015-10-04  6:48             ` Eli Zaretskii
  0 siblings, 1 reply; 24+ messages in thread
From: Daniel Colascione @ 2015-10-04  1:24 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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

On 10/03/2015 12:22 AM, Eli Zaretskii wrote:
>> From: Daniel Colascione <dancol@dancol.org>
>> Date: Fri, 2 Oct 2015 17:19:45 -0700
>>
>> On 10/02/2015 09:07 AM, John Wiegley wrote:
>>>>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>
>>>> Please always accompany such suggestions with rationale. Adding to the core
>>>> just because "why not?" is IMO not a good methodology. Some people still
>>>> care about the memory footprint of programs, so we don't want to bloat that
>>>> unless there are good reasons. Such reasons can only be discussed on a case
>>>> by case basis.
>>>
>>> Although personally I wouldn't mind seeing cl-lib in core, for the benefit of
>>> Emacs I have to agree with Eli. It's not something we should do just because
>>> it sounds like a good idea, but because not doing it would cost us something.
>>> Shaving a few milliseconds from startup is not enough of a gain to be worth
>>> bloating core.
>>
>> What's the cost of increasing the size of the dumped image? We don't
>> take COW faults on most of the pages, so we can discard them at will.
>> Because the OS can discard clean pages without writing them to the
>> pagefile and reconstitute them at will, transferring code from Emacs
>> private allocations to the dumped Emacs image _decreases_ memory
>> footprint. That we also shave a few milliseconds off startup is another
>> benefit.
>>
>> If not cl-lib, then what? What is the actual bar?
> 
> Did you miss my further message where I said we should probably
> preload cl-lib, because many popular commands in a fresh session load
> it anyway?

I did, sorry. Anyway, let's wait until we have a new maintainer and
release Emacs 25 before making this change, but it sounds like we
definitely want to proceed in the direction of dumping cl-lib.

Trying to do it locally, I ran into a very weird problem: functions we
call at compile time, like cl--defalias, raise errors when called:  the
bytecode vector ends up being the number zero instead of the expected
string. Turning cl--defalias and similar functions into macros makes the
build work, but it doesn't solve the real problem.


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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Should we just start dumping cl-lib?
  2015-10-04  1:24           ` Daniel Colascione
@ 2015-10-04  6:48             ` Eli Zaretskii
  0 siblings, 0 replies; 24+ messages in thread
From: Eli Zaretskii @ 2015-10-04  6:48 UTC (permalink / raw)
  To: Daniel Colascione; +Cc: emacs-devel

> Cc: emacs-devel@gnu.org
> From: Daniel Colascione <dancol@dancol.org>
> Date: Sat, 3 Oct 2015 18:24:30 -0700
> 
> > Did you miss my further message where I said we should probably
> > preload cl-lib, because many popular commands in a fresh session load
> > it anyway?
> 
> I did, sorry. Anyway, let's wait until we have a new maintainer and
> release Emacs 25 before making this change, but it sounds like we
> definitely want to proceed in the direction of dumping cl-lib.

I see no reason to wait until Emacs 25.1 is released.  The release
date is sufficiently far away for us to be able to do that ASAP.

> Trying to do it locally, I ran into a very weird problem: functions we
> call at compile time, like cl--defalias, raise errors when called:  the
> bytecode vector ends up being the number zero instead of the expected
> string. Turning cl--defalias and similar functions into macros makes the
> build work, but it doesn't solve the real problem.

If you have time, please try fixing this.

Thanks.



^ permalink raw reply	[flat|nested] 24+ messages in thread

end of thread, other threads:[~2015-10-04  6:48 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-10-02  4:52 Should we just start dumping cl-lib? Daniel Colascione
2015-10-02  5:12 ` John Wiegley
2015-10-02  5:28   ` Daniel Colascione
2015-10-02  7:19     ` Eli Zaretskii
2015-10-02  8:07       ` Eli Zaretskii
2015-10-02  8:23       ` Artur Malabarba
2015-10-02 12:21         ` Andreas Schwab
2015-10-02 12:38           ` Artur Malabarba
2015-10-02 14:27             ` Rasmus
2015-10-02  7:21     ` Oleh Krehel
2015-10-02 11:46 ` Mark Oteiza
2015-10-02 13:37   ` Tassilo Horn
2015-10-02 15:22     ` Artur Malabarba
2015-10-02 13:45   ` Eli Zaretskii
2015-10-02 14:14     ` Mark Oteiza
2015-10-02 14:18       ` Eli Zaretskii
2015-10-02 14:22         ` Mark Oteiza
2015-10-02 14:38           ` Eli Zaretskii
2015-10-02 16:07     ` John Wiegley
2015-10-03  0:19       ` Daniel Colascione
2015-10-03  7:22         ` Eli Zaretskii
2015-10-04  1:24           ` Daniel Colascione
2015-10-04  6:48             ` Eli Zaretskii
2015-10-02 15:13   ` Nicolas Petton

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