Re: Loading a package applies automatically to future sessions?

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

> It looks like your code is fetching slime-autoloads.elc:
> (let ((load-file-name "/Users/my_username/.emacs.d/elpa/slime-20180126.1033/slime-autoloads.elc"))
> ;; ... bunches of bytecode
> )

Hmm... good catch.  I just added a corresponding FIXME in the code
(hopefully M-x dwim will figure out how to fix it).

>> Also, I'm not 100% surprised that byte-compiling byte-compiled code would
>> fail, but I can't see any immediate reason why it should fail, so it's
>> quite possible to it'd be easy to make it work.
> Not sure why it would fail either, but this is the error that I see for
> that specific chunk of bytecode:
> package-fastpath.el:899:1:Error: Wrong type argument: sequencep, 1004

I'll see if I can reproduce it (it's probably better to try and use the
.el file instead, tho).

> And lo and behold, `emacs-init-time' yields 0.7 seconds. Which is just
> 0.2 seconds higher than what I get with -Q, which I believe is Emacs'
> peak startup time. I also verified that I have access to all my packages
> so it is using package-fastpath.el.

Good, thanks.  Now the numbers correspond better to my expectations.

> So that means your patch has actually increased startup time a lot more
                                        ^^^^^^^^^
                                        improved

> Well, actually those figures are better than what you're saying as per
> my information above. I guess that makes your patch even more
> respectable for a first stab! :)

FWIW "a first stab" often ends up being faster than the end product,
because the first stab was too optimistic.

>> Hmm... I thought this can't happen because the files are concatenated in
>> the same order that they are normally loaded by `package-initialize`.
>> I guess something doesn't work the way I thought it does.
>> Can you investigate to see when or even why it happens?
> It specifically happened with gh.el (https://github.com/sigma/gh.el),
> which is dependent on marshal.el (https://github.com/sigma/marshal.el)
>
> Apparently gh-autoloads.el uses a `gh-defclass' macro, which in turn
> uses a `marshal-defclass' macro. There is definitely some strangeness
> that could be going on here.

Could you try and give some more details about this problem?
E.g. check the fastpath file to see in which order the two packages's
autoloads are placed.  If gh-autoloads.el comes before
marshal-autoloads.el, could you try and figure out why (e.g. maybe
starting with `M-x trace-function RET package-activate RET`
and `M-x trace-function RET package-activate-1 RET`)?


        Stefan