[guile-emacs] Circular require problem

[guile-emacs] Circular require problem

[Left Right]

Hello, I've asked at #guile IRC channel and was told this is the right
place to report these.

So, I've built Guile-2.2 and Guile-Emacs. Vanilla Emacs didn't start
at first due to:

(provide 'calendar)
(require 'cal-menu)

lines in cal-menu.el. This is because calendar requires cal-menu and
cal-menu requires calendar. It seems like the strategy in these
situation with Emacs Lisp is to put a "fake" provide statement in the
beginning of the file which provides the library, knowing that there's
the second "real" provide statement in the end of the file. I've
witnessed this same problem with couple more libraries, ERC being one
of them. The first thing I tried was:

(unless (featurep 'cal-menu) (require 'cal-menu))

Which, in some cases magically solved the problem, but not in other cases.

But I don't think it is useful to mimic Emacs behavior wrt circular
require. I think it would be better to make circular require possible
by remembering what libraries had already been required.

----

I have more problems to report. I've tried loading some popular Emacs
packages, such as Org, SLIME, ESS and CEDET, and few others, but none
of that worked. Only relatively large library that loaded was Pymacs,
but it affected the rest of the code somehow so that nothing else
would compile any more.

There was another problem with eval-buffer, where (add-to-list
'load-path ...) with the following (require ...) sexp wouldn't work,
but if evaluated sexp after sexp they magically worked.

I have saved backtrace and crash messages, and I could probably
produce more / more specific error messages if I knew better how to
debug. The regular backtrace buffer doesn't seem to be particularly
useful (too much technical info, which is difficult to trace back to
the source of the problem).

Best,

Oleg

Re: [guile-emacs] Circular require problem

[Robin Templeton]

Left Right <olegsivokon@gmail.com> writes:

> Hello, I've asked at #guile IRC channel and was told this is the right
> place to report these.
>
> So, I've built Guile-2.2 and Guile-Emacs. Vanilla Emacs didn't start
> at first due to:
>
> (provide 'calendar)
> (require 'cal-menu)
>
> lines in cal-menu.el. This is because calendar requires cal-menu and
> cal-menu requires calendar. It seems like the strategy in these
> situation with Emacs Lisp is to put a "fake" provide statement in the
> beginning of the file which provides the library, knowing that there's
> the second "real" provide statement in the end of the file. I've
> witnessed this same problem with couple more libraries, ERC being one
> of them. The first thing I tried was:
>
> (unless (featurep 'cal-menu) (require 'cal-menu))
>
> Which, in some cases magically solved the problem, but not in other cases.
>
> But I don't think it is useful to mimic Emacs behavior wrt circular
> require. I think it would be better to make circular require possible
> by remembering what libraries had already been required.

Thank you for the detailed report! This problem has been fixed in the
current version of Guile-Emacs.

I had modified `load' to compile and execute entire files at once, but
the expression-by-expression evaluation normally performed by `load' is
important for breaking `require' cycles like the one you encountered.
Top-level `require' forms are evaluated at compile time but `provide'
forms aren't, so when `load' compiles the whole file at once, early
`provide' forms can never take effect at the right time.

Additionally, some packages simply don't `require' all their
dependencies and can't be byte-compiled cleanly. To support such
packages, `load' now loads source files using an interpreter, just as
standard Emacs does. Guile-Emacs will support automatic compilation
again in the future, but it will take some time to implement in a
completely compatible way.

> I have more problems to report. I've tried loading some popular Emacs
> packages, such as Org, SLIME, ESS and CEDET, and few others, but none
> of that worked. Only relatively large library that loaded was Pymacs,
> but it affected the rest of the code somehow so that nothing else
> would compile any more.

Org, SLIME and ESS all work for me with the current version. (I haven't
tested CEDET or Pymacs.)

> There was another problem with eval-buffer, where (add-to-list
> 'load-path ...) with the following (require ...) sexp wouldn't work,
> but if evaluated sexp after sexp they magically worked.

This should be fixed now as well.

> I have saved backtrace and crash messages, and I could probably
> produce more / more specific error messages if I knew better how to
> debug. The regular backtrace buffer doesn't seem to be particularly
> useful (too much technical info, which is difficult to trace back to
> the source of the problem).

This is now fixed.

Thanks,
Robin
-- 
Inteligenta persono lernas la lingvon Esperanton rapide kaj facile.
Esperanto estas moderna, kultura lingvo por la mondo. Simpla, fleksebla,
belsona, Esperanto estas la praktika solvo de la problemo de universala
interkompreno. Lernu la interlingvon Esperanton!