[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#19552: 25.0.50; void-function class-slot-initarg with new EIEIO chan

From: Stefan Monnier
Subject: bug#19552: 25.0.50; void-function class-slot-initarg with new EIEIO changes
Date: Mon, 12 Jan 2015 10:11:37 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

>>> The other is the "gh" Github-access package from Melpa: that gives "too
>>> many arguments to defclass".
>> Can you show a backtrace for that error?
> I don't know how to get a proper backtrace for compilation errors...

   (setq debug-on-error t)
   (setq byte-compile-debug t)

And then `M-x byte-compile'.

> Following any of the linked errors leads to the require statements at
> the top of the file in question, and round and round you go.

That's because the error happens while loading the required file.

> I can't actually get to a real error related to defclass. There's
> something odd about the require pattern of this package: gh-auth.el
> ends this way:

> (provide 'gh-auth)
> ;; to avoid circular dependencies...
> (require 'gh-oauth)
> ;;; gh-auth.el ends here

> I don't really understand why. It might be worth getting Yann Hodique to
> comment.

That's usually done because `gh-auth' needs to use functions from
`gh-oauth' and vice-versa, so the author moved the require after the
provide, so that when `gh-oauth' is required from `gh-auth', the
(require 'gh-auth) found in gh-oauth is just skipped (since we just
did (provide 'gh-auth)) rather than causing a recursive load of gh-auth
which would re-require gh-oauth, ...

It's usually not the best solution to recursive dependencies, but
sometimes it's a handy quick-fix, and in this case I don't think it's
the cause of the "Too many arguments to `defclass'" error.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]