9:51 p.m.
I wrote:
Well, sort of. Has anybody thought about trying to add something to
the
smoketest to find miscompiled macros? I can think of a fairly easy
approach, which is not guaranteed to catch everything, but should catch
most instances.
So I improved the scripts to look for both defmacro and defmacro*, and
to output the package and filename to make it easier to hunt for the
culprits. Here they are:
And here is the output from current CVS packages and Mats' last
smoketest log:
defadvice: def in xemacs-base/advice.el, bad use in xemacs-base/ffap.el
dired-parse-ls: def in dired/dired-sex.el, bad use in dired/dired-oas.el
bbdb-search: def in lisp/bbdb-com.el, bad use in net-utils/feedmail.el
rmail-select-summary: def in rmail/rmail.el, bad use in gnus/lisp/gnus-util.el
gnus-group-entry: def in lisp/gnus.el, bad use in gnus/lisp/gnus-xmas.el
gnus-active: def in lisp/gnus.el, bad use in gnus/lisp/gnus-xmas.el
gnus-info-method: def in lisp/gnus.el, bad use in gnus/lisp/gnus-xmas.el
gnus-info-marks: def in lisp/gnus.el, bad use in gnus/lisp/gnus-xmas.el
gnus-info-level: def in lisp/gnus.el, bad use in gnus/lisp/gnus-xmas.el
gnus-info-score: def in lisp/gnus.el, bad use in gnus/lisp/gnus-xmas.el
vm-easy-menu-define: def in vm/vm-easymenu.el, bad use in tm/tm-vm.el
vm-save-restriction: def in vm/vm-macro.el, bad use in tm/tm-vm.el
x-color-defined-p: def in perl-modes/cperl-mode.el, bad use in src/zenirc-color.el
semantic-token-token: def in semantic/semantic.el, bad use in semantic/document.el
semantic-token-function-args: def in semantic/semantic-util.el, bad use in
semantic/document.el
semantic-token-variable-modifiers: def in semantic/semantic-util.el, bad use in
semantic/document.el
define-skeleton: def in xemacs-base/skeleton.el, bad use in ada/ada-stmt.el
defdialect: def in ilisp/ilisp-dia.el, bad use in ilisp/ilisp-cl.el
defdialect: def in ilisp/ilisp-dia.el, bad use in ilisp/ilisp-ccl.el
defdialect: def in ilisp/ilisp-dia.el, bad use in ilisp/ilisp-cmu.el
defdialect: def in ilisp/ilisp-dia.el, bad use in ilisp/ilisp-sbcl.el
defdialect: def in ilisp/ilisp-dia.el, bad use in ilisp/ilisp-chs.el
defdialect: def in ilisp/ilisp-dia.el, bad use in ilisp/ilisp-acl.el
defdialect: def in ilisp/ilisp-dia.el, bad use in ilisp/ilisp-kcl.el
defdialect: def in ilisp/ilisp-dia.el, bad use in ilisp/ilisp-hlw.el
defdialect: def in ilisp/ilisp-dia.el, bad use in ilisp/ilisp-luc.el
defdialect: def in ilisp/ilisp-dia.el, bad use in ilisp/ilisp-xls.el
defdialect: def in ilisp/ilisp-dia.el, bad use in ilisp/ilisp-openmcl.el
defdialect: def in ilisp/ilisp-dia.el, bad use in ilisp/ilisp-sch.el
profile: def in xemacs-devel/profile.el, bad use in edit-utils/search-buffers.el
speedbar-message: def in speedbar/speedbar.el, bad use in speedbar/sb-rmail.el
combine-after-change-calls: def in prog-modes/diff-mode.el, bad use in
mmm-mode/mmm-cmds.el
speedbar-with-writable: def in vhdl/vhdl-mode.el, bad use in ess/lisp/ess-menu.el
bbdb: def in lisp/bbdb-mhe.el, bad use in ess/lisp/mouseme.el
quail-define-rules: def in leim/quail.el, bad use in quail/cyril-jis.el
I am copying XEmacs Beta on this so that discussion of the scripts and
whether something like them is desirable for XEmacs can continue on the
design list, and discussion of whether any of this output points to
actual bugs can take place on the beta list.
--
Jerry James
http://www.ittc.ku.edu/~james/
4:14 p.m.
New subject: Automated package dependencies
I wrote about scripts for finding miscompiled macros. Almost all of
them turned out to be bugs in the build process, or missing requires, or
somebody thinking that (require 'foo) inside a function makes foo load
at compile time. I will send a patch as soon as I get a chance to try
building my patched tree to see if I fixed everything, or if possibly
some of the macros expand to expressions containing other macros that
won't expand properly.....
A few of these turned out to be interesting in their own right.
I wrote:
x-color-defined-p: def in perl-modes/cperl-mode.el, bad use in
src/zenirc-color.el
This one is inside a test for Emacs version, and is in the branch taken
when FSF Emacs is in use, so it is an expected failure, I guess.
combine-after-change-calls: def in prog-modes/diff-mode.el, bad use
in mmm-mode/mmm-cmds.el
Apparently, we don't have combine-after-change-calls. The def in
prog-modes/diff-mode.el is a compatability hack. Given that this
function is also used elsewhere, I suggest that we move the definition
for combine-after-change-calls from prog-modes/diff-mode.el to somewhere
in fsf-compat. However, I don't see a file in fsf-compat where it
really fits. Recommendations?
bbdb: def in lisp/bbdb-mhe.el, bad use in ess/lisp/mouseme.el
This turned out to be a bug in my script, whcih didn't recognize / as a
valid symbol in a function name, combined with a missing require in
mouseme.el. It did not really point to an error.
quail-define-rules: def in leim/quail.el, bad use in
quail/cyril-jis.el
I don't know how to fix this one. The bad use is one directory level
below the definition, and the definition has an autoload cookie.
Obviously, the autoload is not autoloading at compile time. Somebody
else will have to figure out how to fix it.
--
Jerry James
http://www.ittc.ku.edu/~james/
11:27 p.m.
New subject: Automated package dependencies
What can I say? I apparently like talking to myself...
I wrote:
I wrote about scripts for finding miscompiled macros. Almost all of
them turned out to be bugs in the build process, or missing requires, or
somebody thinking that (require 'foo) inside a function makes foo load
at compile time. I will send a patch as soon as I get a chance to try
building my patched tree to see if I fixed everything, or if possibly
some of the macros expand to expressions containing other macros that
won't expand properly.....
Well, this is turning out to be more difficult than I expected. I had
to add some build time dependencies to make macros available at the
right times and places, and now I have dependency cycles. For example:
1) gnus contains gnus-util.el, which uses the macro
rmail-select-summary, so it requires rmail
2) rmail contains rmail.el, which requires tm-view, so it requires tm
3) tm contains bunches of stuff that require things in gnus
And that isn't the only cycle. How should I handle them? I would just
ignore them and hope that the right thing happened, but somehow I have
reached a state where the build process ends thusly:
xemacs -no-autoloads -vanilla -batch -eval '(setq stack-trace-on-error t
load-ignore-out-of-date-elc-files t load-show-full-path-in-messages t)' -l
/usr/src/xemacs/packages/package-compile.el -- gnus w3 mh-e mailcrypt rmail eterm mail-lib
xemacs-base fsf-compat ecrypto tm apel -- -f batch-byte-compile gnus/lisp/earcon.el
Loading /usr/local/lib/xemacs-21.4.10/lisp/auto-autoloads...
Loading /usr/src/xemacs/packages/xemacs-packages/apel/auto-autoloads...
Loading /usr/src/xemacs/packages/xemacs-packages/tm/auto-autoloads...
Loading /usr/src/xemacs/packages/xemacs-packages/ecrypto/auto-autoloads...
Loading /usr/src/xemacs/packages/xemacs-packages/fsf-compat/auto-autoloads...
Loading /usr/src/xemacs/packages/xemacs-packages/xemacs-base/auto-autoloads...
Loading /usr/src/xemacs/packages/xemacs-packages/mail-lib/auto-autoloads...
Loading /usr/src/xemacs/packages/xemacs-packages/eterm/auto-autoloads...
Loading /usr/src/xemacs/packages/xemacs-packages/rmail/auto-autoloads...
Loading /usr/src/xemacs/packages/xemacs-packages/mailcrypt/auto-autoloads...
Loading /usr/src/xemacs/packages/xemacs-packages/mh-e/auto-autoloads...
Loading /usr/src/xemacs/packages/xemacs-packages/w3/lisp/auto-autoloads...
Loading /usr/src/xemacs/packages/xemacs-packages/gnus/gnus/lisp/auto-autoloads...
Compiling /usr/src/xemacs/packages/xemacs-packages/gnus/gnus/lisp/earcon.el...
>Error occurred processing gnus/lisp/earcon.el:
Variable
binding depth exceeds max-specpdl-size
Done
make[2]: *** [gnus/lisp/earcon.elc] Error 1
make[2]: Leaving directory `/usr/src/xemacs/packages/xemacs-packages/gnus'
make[1]: *** [gnus/bytecompile.target] Error 2
make[1]: Leaving directory `/usr/src/xemacs/packages/xemacs-packages'
make: *** [xemacs-packages/bytecompile.target] Error 2
It looks like an infinite (require 'foo) recursion somewhere, because
this didn't happen until I started adding compile-time requires. Whee!
Is there a general rule for handling circular dependencies like this?
--
Jerry James
http://www.ittc.ku.edu/~james/
11:42 p.m.
New subject: Automated package dependencies
>>>> "Jerry" == Jerry James
<james(a)xemacs.org> writes:
Jerry> What can I say? I apparently like talking to myself...
I'm listening, Jerry :-)
Jerry> I wrote:
> I wrote about scripts for finding miscompiled macros. Almost all
of
> them turned out to be bugs in the build process, or missing requires, or
> somebody thinking that (require 'foo) inside a function makes foo load
> at compile time. I will send a patch as soon as I get a chance to try
> building my patched tree to see if I fixed everything, or if possibly
> some of the macros expand to expressions containing other macros that
> won't expand properly.....
Jerry> Well, this is turning out to be more difficult than I expected. I had
Jerry> to add some build time dependencies to make macros available at the
Jerry> right times and places, and now I have dependency cycles. For example:
Jerry> 1) gnus contains gnus-util.el, which uses the macro
Jerry> rmail-select-summary, so it requires rmail
Jerry> 2) rmail contains rmail.el, which requires tm-view, so it requires tm
Jerry> 3) tm contains bunches of stuff that require things in gnus
Jerry> And that isn't the only cycle. How should I handle them? I would just
Jerry> ignore them and hope that the right thing happened, but somehow I have
Jerry> reached a state where the build process ends thusly:
Jerry> xemacs -no-autoloads -vanilla -batch -eval '(setq stack-trace-on-error t
load-ignore-out-of-date-elc-files t load-show-full-path-in-messages t)' -l
/usr/src/xemacs/packages/package-compile.el -- gnus w3 mh-e mailcrypt rmail eterm mail-lib
xemacs-base fsf-compat ecrypto tm apel -- -f batch-byte-compile gnus/lisp/earcon.el
Jerry> Loading /usr/local/lib/xemacs-21.4.10/lisp/auto-autoloads...
Jerry> Loading /usr/src/xemacs/packages/xemacs-packages/apel/auto-autoloads...
Jerry> Loading /usr/src/xemacs/packages/xemacs-packages/tm/auto-autoloads...
Jerry> Loading /usr/src/xemacs/packages/xemacs-packages/ecrypto/auto-autoloads...
Jerry> Loading
/usr/src/xemacs/packages/xemacs-packages/fsf-compat/auto-autoloads...
Jerry> Loading
/usr/src/xemacs/packages/xemacs-packages/xemacs-base/auto-autoloads...
Jerry> Loading /usr/src/xemacs/packages/xemacs-packages/mail-lib/auto-autoloads...
Jerry> Loading /usr/src/xemacs/packages/xemacs-packages/eterm/auto-autoloads...
Jerry> Loading /usr/src/xemacs/packages/xemacs-packages/rmail/auto-autoloads...
Jerry> Loading
/usr/src/xemacs/packages/xemacs-packages/mailcrypt/auto-autoloads...
Jerry> Loading /usr/src/xemacs/packages/xemacs-packages/mh-e/auto-autoloads...
Jerry> Loading /usr/src/xemacs/packages/xemacs-packages/w3/lisp/auto-autoloads...
Jerry> Loading
/usr/src/xemacs/packages/xemacs-packages/gnus/gnus/lisp/auto-autoloads...
Jerry> Compiling
/usr/src/xemacs/packages/xemacs-packages/gnus/gnus/lisp/earcon.el...
>> Error occurred processing gnus/lisp/earcon.el:
Jerry> Variable binding depth exceeds max-specpdl-size
Jerry> Done
Jerry> make[2]: *** [gnus/lisp/earcon.elc] Error 1
Jerry> make[2]: Leaving directory
`/usr/src/xemacs/packages/xemacs-packages/gnus'
Jerry> make[1]: *** [gnus/bytecompile.target] Error 2
Jerry> make[1]: Leaving directory `/usr/src/xemacs/packages/xemacs-packages'
Jerry> make: *** [xemacs-packages/bytecompile.target] Error 2
Jerry> It looks like an infinite (require 'foo) recursion somewhere, because
Jerry> this didn't happen until I started adding compile-time requires. Whee!
Jerry> Is there a general rule for handling circular dependencies like this?
Jerry> --
Jerry> Jerry James
Jerry> http://www.ittc.ku.edu/~james/
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
11:59 p.m.
New subject: Automated package dependencies
On Tue, 2002-12-17 at 01:27, Jerry James wrote:
What can I say? I apparently like talking to myself...
I like listening, don't consider (equal silence ignorance) :)
Seriously, your efforts are really appreciated, but unfortunately
providing any sensible comments about this stuff is beyond my lisp
knowledge. "Makes sense to me" is about the best I can do :/
1) gnus contains gnus-util.el, which uses the macro
rmail-select-summary, so it requires rmail
2) rmail contains rmail.el, which requires tm-view, so it requires tm
3) tm contains bunches of stuff that require things in gnus
Aren't this kind of cycles automatically dropped? ISTR seeing some
messages about detected and dropped dep cycles somewhere when building
packages. Ah, but that must have been for REQUIRES in Makefiles...
It looks like an infinite (require 'foo) recursion somewhere,
because
this didn't happen until I started adding compile-time requires. Whee!
Is there a general rule for handling circular dependencies like this?
Dunno, but how's about using something like this to prevent it?
(or (featurep 'foo) (require 'foo))
Also, if you're building from per-package dirs, could you try if my
patch at [1] affects this in any way? I'm planning to commit the patch
(as well as a corresponding one to unsupported area) tomorrow.
[1] <http://list-archive.xemacs.org/xemacs-patches/200212/msg00089.html>
--
\/ille Skyttä
scop at xemacs.org
1:08 a.m.
New subject: Automated package dependencies
>>>> "Ville" == Ville Skytt <Ville>
writes:
Ville> On Tue, 2002-12-17 at 01:27, Jerry James wrote:
> What can I say? I apparently like talking to myself...
Ville> I like listening, don't consider (equal silence ignorance) :)
im here to jerry
Ville> Seriously, your efforts are really appreciated, but unfortunately
Ville> providing any sensible comments about this stuff is beyond my lisp
Ville> knowledge. "Makes sense to me" is about the best I can do :/
thats about my knowledge right now too tho scop is probably ahead of
me in the lisp skills
> 1) gnus contains gnus-util.el, which uses the macro
> rmail-select-summary, so it requires rmail
> 2) rmail contains rmail.el, which requires tm-view, so it requires tm
> 3) tm contains bunches of stuff that require things in gnus
Ville> Aren't this kind of cycles automatically dropped? ISTR seeing some
Ville> messages about detected and dropped dep cycles somewhere when building
Ville> packages. Ah, but that must have been for REQUIRES in Makefiles...
> It looks like an infinite (require 'foo) recursion somewhere,
because
> this didn't happen until I started adding compile-time requires. Whee!
> Is there a general rule for handling circular dependencies like this?
Ville> Dunno, but how's about using something like this to prevent it?
Ville> (or (featurep 'foo) (require 'foo))
that looks good to me too
Ville> Also, if you're building from per-package dirs, could you try if my
Ville> patch at [1] affects this in any way? I'm planning to commit the patch
Ville> (as well as a corresponding one to unsupported area) tomorrow.
Ville> [1]
<http://list-archive.xemacs.org/xemacs-patches/200212/msg00089.html>
im having one of my radical ideas again
this one could solve a few problems and create some more
seems like we need to get the lisp these kind of loopy dependancies
use into a common package ( xemacs-base ? ) so we can have the
packages that require them all point to one package instead of each
other in really bizzare ways
did that make sense to anyone else ??
think shared lisp library.
anyway let me know if you need a less Rendhalver explanation
--
XEmacs Advocate | Do not try the patience of Wizards,
Gentoo Devotee | for they are subtle and quick to anger.
Perl Hacker | - Elric (Technomage) , Babylon 5.
Apache God | <mailto:rendhalver at xemacs.org> <GnuPG KeyID: AE51D190>
10:21 a.m.
New subject: Automated package dependencies
>>>> "R" == rendhalver
<rendhalver(a)xemacs.org> writes:
R> seems like we need to get the lisp these kind of loopy
R> dependancies use into a common package ( xemacs-base ? ) so we
R> can have the packages that require them all point to one
R> package instead of each other in really bizzare ways
You can have that "common package", today. It's called "GNU
Emacs".
It even includes our biggest REQUIRE'able, Gnus. ;-)
Seriously, I think you'll find that the transitive closure of these
loopy dependencies is a pretty big chunk of our packages.
R> think shared lisp library.
All Lisp libraries are shared in that sense.
Remember that most Lisp libraries are all declaration/definition; not
very much code is executed at load time. (That's inaccurate, in fact
things like defun are often defined in Lisp, but it's close enough.)
For the problems we're dealing with in REQUIRES, we never want
compiled Lisp, either. Macros and defsubsts are open-coded in Lisp,
then their callers are compiled. So in the build process, we just
need to get lots and lots of Lisp definitions loaded, but only the
macros and the defsubsts. (And in fact the defsubsts don't _need_ to
be loaded at compile time, because they provide a regular defun so
that a defsubst is funcall'able. But that defeats the purpose of a
defsubst. We do want them available if at all possible.)
Circularities are not an issue at compile time.
The issues of "what packages do we _need_ at run time" are important,
but they should be handled by a different mechanism from REQUIRES.
How about SUGGESTS?
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
5:18 p.m.
New subject: Automated package dependencies
>>>> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
>>>> "R" == rendhalver
<rendhalver(a)xemacs.org> writes:
R> seems like we need to get the lisp
these kind of loopy
R> dependancies use into a common package ( xemacs-base ? ) so we
R> can have the packages that require them all point to one
R> package instead of each other in really bizzare ways
Stephen> You can have that "common package", today. It's called
"GNU Emacs".
Stephen> It even includes our biggest REQUIRE'able, Gnus. ;-)
Stephen> Seriously, I think you'll find that the transitive closure of these
Stephen> loopy dependencies is a pretty big chunk of our packages.
ok looks like i need to explain myself better
i ment why dont we move that loopily required lisp into one package ??
then it would stop the foo requires bar and bar requires foo complications
R> think shared lisp library.
Stephen> All Lisp libraries are shared in that sense.
Stephen> Remember that most Lisp libraries are all declaration/definition; not
Stephen> very much code is executed at load time. (That's inaccurate, in fact
Stephen> things like defun are often defined in Lisp, but it's close enough.)
Stephen> For the problems we're dealing with in REQUIRES, we never want
Stephen> compiled Lisp, either. Macros and defsubsts are open-coded in Lisp,
Stephen> then their callers are compiled. So in the build process, we just
Stephen> need to get lots and lots of Lisp definitions loaded, but only the
Stephen> macros and the defsubsts. (And in fact the defsubsts don't _need_ to
Stephen> be loaded at compile time, because they provide a regular defun so
Stephen> that a defsubst is funcall'able. But that defeats the purpose of a
Stephen> defsubst. We do want them available if at all possible.)
Stephen> Circularities are not an issue at compile time.
Stephen> The issues of "what packages do we _need_ at run time" are
important,
Stephen> but they should be handled by a different mechanism from REQUIRES.
Stephen> How about SUGGESTS?
Stephen> --
Stephen> Institute of Policy and Planning Sciences
http://turnbull.sk.tsukuba.ac.jp
Stephen> University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573
JAPAN
Stephen> Ask not how you can "do" free software business;
Stephen> ask what your business can "do for" free software.
--
XEmacs Advocate | Do not try the patience of Wizards,
Gentoo Devotee | for they are subtle and quick to anger.
Perl Hacker | - Elric (Technomage) , Babylon 5.
Apache God | <mailto:rendhalver at xemacs.org> <GnuPG KeyID: AE51D190>
9:39 p.m.
New subject: Automated package dependencies
On Wed, 18 Dec 2002 03:18:18 +1000, rendhalver(a)xemacs.org (Rendhalver [Peter Brown])
said:
i ment why dont we move that loopily required lisp into one package
??
then it would stop the foo requires bar and bar requires foo complications
Because that one package would be the transitive closure of all the loops.
In other words, most of the existing packages would be sucked in like
interstellar debris into a black hole. And don't even SUGGEST that we have
one package for each loop - that becomes even more resource sucking than
a black hole (consider more complicated dependency graphs, such as a figure-8
or a tetrahedon - I think somebody already posted the Gnus/tm/something/something
as being a 4-step loop. Excuse me while I vomit. ;)
10:56 a.m.
New subject: Automated package dependencies
>>>> "Valdis" == Valdis Kletnieks
<Valdis.Kletnieks(a)vt.edu> writes:
Valdis> On Wed, 18 Dec 2002 03:18:18 +1000, rendhalver(a)xemacs.org (Rendhalver
[Peter Brown]) said:
> i ment why dont we move that loopily required lisp into one
package ??
> then it would stop the foo requires bar and bar requires foo complications
Valdis> Because that one package would be the transitive closure of all the loops.
Valdis> In other words, most of the existing packages would be sucked in like
Valdis> interstellar debris into a black hole. And don't even SUGGEST that we
have
Valdis> one package for each loop - that becomes even more resource sucking than
Valdis> a black hole (consider more complicated dependency graphs, such as a
figure-8
Valdis> or a tetrahedon - I think somebody already posted the
Gnus/tm/something/something
Valdis> as being a 4-step loop. Excuse me while I vomit. ;)
ok i think there is some kind of complete misunderstanding on my part
probably due to my current lack of explanation skills right now
(which is unusual for me)
ok im going to try again
we have a package called foo and a package called bar
foo needs some lisp functions in bar
bar needs some lisp functions in foo
so instead of having them require each other, which seems like a
dependancy nightmare to me, we move the lisp functions that foo
requires from bar into a separate package called bob
and we move the lisp functions that bar requires from foo in that bob
package as well, so instead of foo requiring bar and bar requiring foo
foo requires bob and bar requires bob
no more weird dependancy problems hence problem solved
does that help ??
--
XEmacs Advocate | Do not try the patience of Wizards,
Gentoo Devotee | for they are subtle and quick to anger.
Perl Hacker | - Elric (Technomage) , Babylon 5.
Apache God | <mailto:rendhalver at xemacs.org> <GnuPG KeyID: AE51D190>
2:05 p.m.
New subject: Automated package dependencies
On Wed, 18 Dec 2002, rendhalver(a)xemacs.org wrote:
>>>>> "Valdis" == Valdis Kletnieks
<Valdis.Kletnieks(a)vt.edu> writes:
Valdis> On Wed, 18 Dec 2002 03:18:18 +1000, rendhalver(a)xemacs.org (Rendhalver
[Peter Brown]) said:
>> i ment why dont we move that loopily required lisp into one package ??
>> then it would stop the foo requires bar and bar requires foo complications
Valdis> Because that one package would be the transitive closure of all the
loops.
Valdis> In other words, most of the existing packages would be sucked in like
Valdis> interstellar debris into a black hole. And don't even SUGGEST that we
have
Valdis> one package for each loop - that becomes even more resource sucking than
Valdis> a black hole (consider more complicated dependency graphs, such as a
figure-8
Valdis> or a tetrahedon - I think somebody already posted the
Gnus/tm/something/something
Valdis> as being a 4-step loop. Excuse me while I vomit. ;)
ok i think there is some kind of complete misunderstanding on my part
probably due to my current lack of explanation skills right now
(which is unusual for me)
ok im going to try again
we have a package called foo and a package called bar
foo needs some lisp functions in bar
bar needs some lisp functions in foo
so instead of having them require each other, which seems like a
dependancy nightmare to me, we move the lisp functions that foo
requires from bar into a separate package called bob
and we move the lisp functions that bar requires from foo in that bob
package as well, so instead of foo requiring bar and bar requiring foo
foo requires bob and bar requires bob
no more weird dependancy problems hence problem solved
does that help ??
NOTE: You can have files that mutually require each other as long as
the lisp files do their provides before doing any requires.
It is not necessary to move code around to break the functional
dependency chain. Of course, moving code around may make the code
more organized and easier to follow.
-jeff
7:45 p.m.
New subject: Automated package dependencies
On Tue, 2002-12-17 at 12:21, Stephen J. Turnbull wrote:
The issues of "what packages do we _need_ at run time" are
important,
but they should be handled by a different mechanism from REQUIRES.
How about SUGGESTS?
Yes, that concept has turned up a couple of times lately, IIRC
previously labeled as "RECOMMENDS". Such a thing would be welcome, and
supported (if not enforced?) by pui.
--
\/ille Skyttä
scop at xemacs.org
2:47 a.m.
New subject: Automated package dependencies
On 17 Dec 2002, scop(a)xemacs.org wrote:
On Tue, 2002-12-17 at 01:27, Jerry James wrote:
> What can I say? I apparently like talking to myself...
FWIW, it was a pretty clever idea.
Files using macros defined in other files should require those files
inside of an eval-when?
(eval-when (compile) (require 'macro-file))
If the macro expands into functions then you might need autoload
cookies for those functions.
I like listening, don't consider (equal silence ignorance) :)
Seriously, your efforts are really appreciated, but unfortunately
providing any sensible comments about this stuff is beyond my lisp
knowledge. "Makes sense to me" is about the best I can do :/
> 1) gnus contains gnus-util.el, which uses the macro
> rmail-select-summary, so it requires rmail
> 2) rmail contains rmail.el, which requires tm-view, so it requires tm
> 3) tm contains bunches of stuff that require things in gnus
Aren't this kind of cycles automatically dropped? ISTR seeing some
messages about detected and dropped dep cycles somewhere when building
packages. Ah, but that must have been for REQUIRES in Makefiles...
> It looks like an infinite (require 'foo) recursion somewhere, because
> this didn't happen until I started adding compile-time requires. Whee!
> Is there a general rule for handling circular dependencies like this?
Dunno, but how's about using something like this to prevent it?
(or (featurep 'foo) (require 'foo))
require (defined in src/fns.c) already does a featurep check (both
featurep and require do memq on the features list).
The ordering of require and provide statements can cause recursions.
Here is a simple way to reproduce recursion:
foo.el:
-----
(require 'bar)
(provide 'foo)
-----
bar.el:
-----
(require 'foo)
(provide 'bar)
-----
Then do:
(require 'foo)
If you do all provides first, then requires, you will not get infinite recursion.
-jeff
7:46 a.m.
New subject: Automated package dependencies
On Tue, 2002-12-17 at 04:47, Jeff Mincy wrote:
> (or (featurep 'foo) (require 'foo))
require (defined in src/fns.c) already does a featurep check (both
featurep and require do memq on the features list).
Ah, of course.
If you do all provides first, then requires, you will not get
infinite
recursion.
Hmm. IIRC many files under packages/ do provides *last*...
--
\/ille Skyttä
scop at xemacs.org
10:29 a.m.
New subject: Automated package dependencies
>>>> "Jeff" == Jeff Mincy
<jeff(a)delphioutpost.com> writes:
Jeff> Files using macros defined in other files should require
Jeff> those files inside of an eval-when? (eval-when (compile)
Jeff> (require 'macro-file))
Why an eval-when? require is already specially treated at compile
time. Just require the file and be done with it.
Jeff> If the macro expands into functions then you might need
Jeff> autoload cookies for those functions.
Ugh. That's really ugly. No. Just require and be done with it.
An autoload cookie is really a way of exporting an API. Don't
pollute the API so you can reduce the number of requires; you end up
loading the file either way! A require is how you say "I need access
to your internals."
Jeff> If you do all provides first, then requires, you will not
Jeff> get infinite recursion.
And IIRC this is not harmful, in the sense that when loading XEmacs
records provides, and if the load fails for some reason, the provides
are undone.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
3:45 p.m.
New subject: Automated package dependencies
Well, I'm glad people were paying attention after all. I was starting
to feel like a guy at a party who is telling a joke and gets to the
punchline, only to discover that everybody else left to go get a beer.
"Stephen J. Turnbull" <stephen(a)xemacs.org> wrote:
Why an eval-when? require is already specially treated at compile
time. Just require the file and be done with it.
But only at top-level, apparently. The miscompiled defadvice in ffap.el
immediately follows a (require 'advice), but it is not at top-level. If
you look at ffap.elc, you'll see that the require is compiled in there
all right, so it will be executed at run time. However, the defadvice
macro is compiled as a function call, so the require clearly did not
take effect at compile time.
Also, some of the miscompiled macros I'm seeing are taken care of with a
require at compile time, but there is no run time dependency on the file
containing the macro. Doing an (eval-when-compile (require 'foo)) makes
perfect sense in that case.
Jeff> If the macro expands into functions then you might need
Jeff> autoload cookies for those functions.
Ugh. That's really ugly. No. Just require and be done with it.
Some of the miscompiled macros have autoload cookies already, but the
containing package was not in the REQUIRES list. I've just added to
REQUIRES in those cases.
Jeff> If you do all provides first, then requires, you will
not
Jeff> get infinite recursion.
And IIRC this is not harmful, in the sense that when loading XEmacs
records provides, and if the load fails for some reason, the provides
are undone.
That is correct. I'll have to move some provides then. I hadn't
thought about defsubsts, either, so I'll deal with those once I get the
macros to settle down and behave correctly. Keep watching for a patch.
I'll get a successful compile one of these days...
--
Jerry James
http://www.ittc.ku.edu/~james/
11:58 p.m.
New subject: [PATCH packages] Expand macros at compile time
I wrote:
That is correct. I'll have to move some provides then. I
hadn't
thought about defsubsts, either, so I'll deal with those once I get the
macros to settle down and behave correctly. Keep watching for a patch.
I'll get a successful compile one of these days...
Here is the patch. This makes my script complain about only two uses:
the expected x-color-defined-p use in zenirc-color.el, and the
combine-after-change-calls use in mmm-cmds.el. I await opinions from
the powers that be on whether combine-after-change-calls should be
defined in fsf-compat and, if so, where.
mule-packages/leim/ChangeLog addition:
2002-12-17 Jerry James <james(a)xemacs.org>
* Makefile (REQUIRES): Add self so that quail-define-rules autoloads.
xemacs-packages/ada/ChangeLog addition:
2002-12-17 Jerry James <james(a)xemacs.org>
* Makefile (REQUIRES): Add xemacs-base so that define-skeleton
autoloads.
xemacs-packages/dired/ChangeLog addition:
2002-12-17 Jerry James <james(a)xemacs.org>
* dired-oas.el: Load the definition of dired-parse-ls when compiling.
xemacs-packages/edit-utils/ChangeLog addition:
2002-12-17 Jerry James <james(a)xemacs.org>
* Makefile (REQUIRES): Add xemacs-devel so that profile autoloads.
xemacs-packages/ess/ChangeLog addition:
2002-12-17 Jerry James <james(a)xemacs.org>
* Makefile (REQUIRES): Add speedbar to satisfy compile time macro
needs.
* lisp/ess-menu.el: Require speedbar at compile time to define
speedbar-with-writable.
Remove useless require inside a featurep.
xemacs-packages/eudc/ChangeLog addition:
2002-12-17 Jerry James <james(a)xemacs.org>
* Makefile (REQUIRES): Add rmail, tm, and apel to satisfy
transitive dependencies from gnus.
xemacs-packages/gnus/ChangeLog addition:
2002-12-17 Jerry James <james(a)xemacs.org>
* Makefile (REQUIRES): Add tm and apel to satisfy transitive
dependencies from rmail.
xemacs-packages/gnus/gnus/lisp/ChangeLog addition:
2002-12-17 Jerry James <james(a)xemacs.org>
* gnus-util.el: Require rmail at compile time to define
rmail-select-summary.
* gnus-xmas.el: Move the provide to the top to break a cycle.
Require gnus at compile time to define several macros.
* gnus.el: Move the provide to the top to break a cycle.
xemacs-packages/ilisp/ChangeLog addition:
2002-12-17 Jerry James <james(a)xemacs.org>
* Makefile (PRELOADS): Also preload ilisp-dia so that defdialect
is defined.
xemacs-packages/net-utils/ChangeLog addition:
2002-12-17 Jerry James <james(a)xemacs.org>
* Makefile (REQUIRES): Add bbdb and gnus to autoload macro
definitions, and rmail, tm, and apel to satisfy transitive
dependencies on gnus.
* feedmail.el: Require bbdb-com at compile time to define
the bbdb-search macro.
xemacs-packages/semantic/ChangeLog addition:
2002-12-17 Jerry James <james(a)xemacs.org>
* document.el: Require semantic and semantic-util at compile time
to define macros.
xemacs-packages/speedbar/ChangeLog addition:
2002-12-17 Jerry James <james(a)xemacs.org>
* sb-rmail.el: Require speedbar at compile time to define the
speedbar-message macro.
xemacs-packages/tm/ChangeLog addition:
2002-12-17 Jerry James <james(a)xemacs.org>
* tm-vm.el: Require vm-easymenu and vm-macro at compile time to
define macros.
xemacs-packages/vhdl/ChangeLog addition:
2002-12-17 Jerry James <james(a)xemacs.org>
* vhdl-mode.el (speedbar-with-writable): Removed, along with
incorrect comment.
xemacs-packages/xemacs-base/ChangeLog addition:
2002-12-17 Jerry James <james(a)xemacs.org>
* ffap.el: Require advice at compile time, not load time.
xemacs-packages/xemacs-devel/ChangeLog addition:
2002-12-17 Jerry James <james(a)xemacs.org>
* Makefile (REQUIRES): Add rmail, tm, and apel due to transitive
dependencies on gnus.
packages source patch:
Diff command: cvs -q diff -uN
Files affected: xemacs-packages/xemacs-devel/Makefile xemacs-packages/xemacs-base/ffap.el
xemacs-packages/vhdl/vhdl-mode.el xemacs-packages/tm/tm-vm.el
xemacs-packages/speedbar/sb-rmail.el xemacs-packages/semantic/document.el
xemacs-packages/net-utils/feedmail.el xemacs-packages/net-utils/Makefile
xemacs-packages/ilisp/Makefile xemacs-packages/gnus/gnus/lisp/gnus.el
xemacs-packages/gnus/gnus/lisp/gnus-xmas.el xemacs-packages/gnus/gnus/lisp/gnus-util.el
xemacs-packages/gnus/Makefile xemacs-packages/eudc/Makefile
xemacs-packages/ess/lisp/ess-menu.el xemacs-packages/ess/Makefile
xemacs-packages/edit-utils/Makefile xemacs-packages/dired/dired-oas.el
xemacs-packages/ada/Makefile mule-packages/leim/Makefile
Index: mule-packages/leim/Makefile
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/mule-packages/leim/Makefile,v
retrieving revision 1.25
diff -d -u -u -r1.25 Makefile
--- mule-packages/leim/Makefile 2002/12/08 21:25:36 1.25
+++ mule-packages/leim/Makefile 2002/12/17 23:13:06
＠＠ -22,7 +22,7 ＠＠
MAINTAINER = XEmacs Development Team <xemacs-beta(a)xemacs.org>
PACKAGE = leim
PKG_TYPE = regular
-REQUIRES = mule-base fsf-compat xemacs-base
+REQUIRES = leim mule-base fsf-compat xemacs-base
CATEGORY = mule
ELCS = quail.elc leim-list.elc
Index: xemacs-packages/ada/Makefile
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/ada/Makefile,v
retrieving revision 1.13
diff -d -u -u -r1.13 Makefile
--- xemacs-packages/ada/Makefile 2002/12/08 21:26:21 1.13
+++ xemacs-packages/ada/Makefile 2002/12/17 23:13:06
＠＠ -22,7 +22,7 ＠＠
MAINTAINER = XEmacs Development Team <xemacs-beta(a)xemacs.org>
PACKAGE = ada
PKG_TYPE = regular
-REQUIRES =
+REQUIRES = xemacs-base
CATEGORY = standard
ELCS = ada-mode.elc ada-stmt.elc
Index: xemacs-packages/dired/dired-oas.el
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/dired/dired-oas.el,v
retrieving revision 1.2
diff -d -u -u -r1.2 dired-oas.el
--- xemacs-packages/dired/dired-oas.el 2001/03/31 17:15:14 1.2
+++ xemacs-packages/dired/dired-oas.el 2002/12/17 23:13:06
＠＠ -11,6 +11,10 ＠＠
;;; Don't require or provide anything, as this file is just an archive.
+;;; jwj -- On the other hand, dired-parse-ls is a macro, so we had better
+;;; load its definition when compiling
+(eval-when-compile (require 'dired-sex))
+
(defun dired-sort-on-size ()
"Sorts a dired listing on file size.
If your ls cannot sort on size, this is useful as `dired-after-readin-hook':
Index: xemacs-packages/edit-utils/Makefile
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/edit-utils/Makefile,v
retrieving revision 1.102
diff -d -u -u -r1.102 Makefile
--- xemacs-packages/edit-utils/Makefile 2002/12/08 21:27:17 1.102
+++ xemacs-packages/edit-utils/Makefile 2002/12/17 23:13:06
＠＠ -24,7 +24,7 ＠＠
MAINTAINER = XEmacs Development Team <xemacs-beta(a)xemacs.org>
PACKAGE = edit-utils
PKG_TYPE = single-file
-REQUIRES = xemacs-base fsf-compat dired mail-lib
+REQUIRES = xemacs-base xemacs-devel fsf-compat dired mail-lib
CATEGORY = standard
ELCS = abbrevlist.elc after-save-commands.elc array.elc atomic-extents.elc \
Index: xemacs-packages/ess/Makefile
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/ess/Makefile,v
retrieving revision 1.8
diff -d -u -u -r1.8 Makefile
--- xemacs-packages/ess/Makefile 2002/12/08 21:27:32 1.8
+++ xemacs-packages/ess/Makefile 2002/12/17 23:13:06
＠＠ -22,7 +22,7 ＠＠
MAINTAINER = A.J. Rossini <rossini(a)xemacs.org>
PACKAGE = ess
PKG_TYPE = regular
-REQUIRES = xemacs-base mail-lib fsf-compat edit-utils
+REQUIRES = xemacs-base mail-lib fsf-compat edit-utils speedbar
CATEGORY = standard
ELS = $(wildcard lisp/*.el)
Index: xemacs-packages/ess/lisp/ess-menu.el
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/ess/lisp/ess-menu.el,v
retrieving revision 1.2
diff -d -u -u -r1.2 ess-menu.el
--- xemacs-packages/ess/lisp/ess-menu.el 2002/12/16 23:24:25 1.2
+++ xemacs-packages/ess/lisp/ess-menu.el 2002/12/17 23:13:06
＠＠ -210,6 +210,8 ＠＠
;;; Speedbar stuff.
+;; Compile time: require speedbar so macros expand correctly
+(eval-when-compile (require 'speedbar))
(defun S-speedbar-buttons (buffer)
"attempted hack."
＠＠ -231,10 +233,10 ＠＠
(speedbar-add-supported-extension ".s")
(speedbar-add-supported-extension ".q"))
+;; Load time: use speedbar if available
(if (featurep 'speedbar)
(progn
(message "enabling speedbar support")
- (require 'speedbar)
(ess-S-initialize-speedbar)))
; Run load hook and provide package
Index: xemacs-packages/eudc/Makefile
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/eudc/Makefile,v
retrieving revision 1.37
diff -d -u -u -r1.37 Makefile
--- xemacs-packages/eudc/Makefile 2002/12/08 21:27:36 1.37
+++ xemacs-packages/eudc/Makefile 2002/12/17 23:13:06
＠＠ -22,7 +22,7 ＠＠
MAINTAINER = Oscar Figueiredo <oscar(a)xemacs.org>
PACKAGE = eudc
PKG_TYPE = regular
-REQUIRES = fsf-compat xemacs-base bbdb mail-lib gnus
+REQUIRES = fsf-compat xemacs-base bbdb mail-lib gnus rmail tm apel
CATEGORY = standard
ELCS = eudc.elc eudc-hotlist.elc eudc-export.elc eudc-bob.elc \
Index: xemacs-packages/gnus/Makefile
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/gnus/Makefile,v
retrieving revision 1.74
diff -d -u -u -r1.74 Makefile
--- xemacs-packages/gnus/Makefile 2002/12/08 21:27:57 1.74
+++ xemacs-packages/gnus/Makefile 2002/12/17 23:13:06
＠＠ -23,7 +23,7 ＠＠
PACKAGE = gnus
PKG_TYPE = regular
REQUIRES = gnus w3 mh-e mailcrypt rmail eterm mail-lib xemacs-base fsf-compat \
- ecrypto
+ ecrypto tm apel
CATEGORY = standard
LISPFILES = $(wildcard gnus/lisp/*.el)
ELCS = $(LISPFILES:.el=.elc)
Index: xemacs-packages/gnus/gnus/lisp/gnus-util.el
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/gnus/gnus/lisp/gnus-util.el,v
retrieving revision 1.21
diff -d -u -u -r1.21 gnus-util.el
--- xemacs-packages/gnus/gnus/lisp/gnus-util.el 2001/02/08 08:57:17 1.21
+++ xemacs-packages/gnus/gnus/lisp/gnus-util.el 2002/12/17 23:13:07
＠＠ -652,7 +652,7 ＠＠
;;; Functions for saving to babyl/mail files.
(defvar rmail-default-rmail-file)
+(eval-when-compile (require 'rmail))
(defun gnus-output-to-rmail (filename &optional ask)
"Append the current article to an Rmail file named FILENAME."
(require 'rmail)
Index: xemacs-packages/gnus/gnus/lisp/gnus-xmas.el
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/gnus/gnus/lisp/gnus-xmas.el,v
retrieving revision 1.12
diff -d -u -u -r1.12 gnus-xmas.el
--- xemacs-packages/gnus/gnus/lisp/gnus-xmas.el 2001/02/08 08:57:18 1.12
+++ xemacs-packages/gnus/gnus/lisp/gnus-xmas.el 2002/12/17 23:13:07
＠＠ -27,10 +27,13 ＠＠
;;; Code:
+(provide 'gnus-xmas)
+
(require 'text-props)
(defvar menu-bar-mode (featurep 'menubar))
(require 'messagexmas)
(require 'wid-edit)
+(eval-when-compile (require 'gnus))
(defgroup gnus-xmas nil
"XEmacsoid support for Gnus"
＠＠ -873,7 +876,5 ＠＠
gnus-mailing-list-menu))
(add-hook 'gnus-mailing-list-mode-hook 'gnus-xmas-mailing-list-menu-add)
-
-(provide 'gnus-xmas)
;;; gnus-xmas.el ends here
Index: xemacs-packages/gnus/gnus/lisp/gnus.el
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/gnus/gnus/lisp/gnus.el,v
retrieving revision 1.26
diff -d -u -u -r1.26 gnus.el
--- xemacs-packages/gnus/gnus/lisp/gnus.el 2001/02/08 08:57:18 1.26
+++ xemacs-packages/gnus/gnus/lisp/gnus.el 2002/12/17 23:13:08
＠＠ -27,6 +27,8 ＠＠
;;; Code:
+(provide 'gnus)
+
(eval '(run-hooks 'gnus-load-hook))
(eval-when-compile (require 'cl))
＠＠ -2951,7 +2953,5 ＠＠
;; Allow redefinition of Gnus functions.
(gnus-ems-redefine)
-
-(provide 'gnus)
;;; gnus.el ends here
Index: xemacs-packages/ilisp/Makefile
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/ilisp/Makefile,v
retrieving revision 1.49
diff -d -u -u -r1.49 Makefile
--- xemacs-packages/ilisp/Makefile 2002/12/08 21:28:13 1.49
+++ xemacs-packages/ilisp/Makefile 2002/12/17 23:13:08
＠＠ -33,7 +33,7 ＠＠
REQUIRES = xemacs-base mail-lib fsf-compat eterm sh-script
CATEGORY = standard
-PRELOADS = -l ilisp-def -l comint
+PRELOADS = -l ilisp-def -l ilisp-dia -l comint
ELCS = ilxemacs.elc ilcompat.elc completer.elc comint-ipc.elc bridge.elc \
ilisp-def.elc ilisp-sym.elc \
Index: xemacs-packages/net-utils/Makefile
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/net-utils/Makefile,v
retrieving revision 1.32
diff -d -u -u -r1.32 Makefile
--- xemacs-packages/net-utils/Makefile 2002/12/08 21:28:44 1.32
+++ xemacs-packages/net-utils/Makefile 2002/12/17 23:13:09
＠＠ -22,7 +22,7 ＠＠
MAINTAINER = XEmacs Development Team <xemacs-beta(a)xemacs.org>
PACKAGE = net-utils
PKG_TYPE = single-file
-REQUIRES = w3 efs mail-lib xemacs-base fsf-compat eterm sh-script
+REQUIRES = bbdb w3 efs mail-lib xemacs-base fsf-compat eterm sh-script gnus rmail tm
apel
CATEGORY = standard
ELCS = browse-cltl2.elc xemacsbug.elc feedmail.elc metamail.elc net-utils.elc \
Index: xemacs-packages/net-utils/feedmail.el
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/net-utils/feedmail.el,v
retrieving revision 1.4
diff -d -u -u -r1.4 feedmail.el
--- xemacs-packages/net-utils/feedmail.el 2001/05/11 14:54:32 1.4
+++ xemacs-packages/net-utils/feedmail.el 2002/12/17 23:13:10
＠＠ -909,6 +909,8 ＠＠
:type 'list
)
+;; jwj -- Get the definition of bbdb-search
+(eval-when-compile (require 'bbdb-com))
(defun feedmail-spray-via-bbdb ()
"Example function for use with feedmail spray mode.
Index: xemacs-packages/semantic/document.el
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/semantic/document.el,v
retrieving revision 1.8
diff -d -u -u -r1.8 document.el
--- xemacs-packages/semantic/document.el 2002/08/12 03:26:23 1.8
+++ xemacs-packages/semantic/document.el 2002/12/17 23:13:11
＠＠ -40,6 +40,10 ＠＠
;; This contains most variable settings for auto-comment generation.
(require 'document-vars)
+(eval-when-compile
+ (require 'semantic)
+ (require 'semantic-util))
+
;;; Code:
;;; User customizations
Index: xemacs-packages/speedbar/sb-rmail.el
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/speedbar/sb-rmail.el,v
retrieving revision 1.5
diff -d -u -u -r1.5 sb-rmail.el
--- xemacs-packages/speedbar/sb-rmail.el 2002/08/09 22:08:29 1.5
+++ xemacs-packages/speedbar/sb-rmail.el 2002/12/17 23:13:11
＠＠ -41,6 +41,7 ＠＠
;; "Rmail specific speedbar button generator.")
;;
;; This file requires speedbar.
+(eval-when-compile (require 'speedbar))
;;; Change log:
;; 0.1 - first revision copied from speedbspec.el V 0.1.1
Index: xemacs-packages/tm/tm-vm.el
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/tm/tm-vm.el,v
retrieving revision 1.1.1.1
diff -d -u -u -r1.1.1.1 tm-vm.el
--- xemacs-packages/tm/tm-vm.el 1998/01/14 06:27:57 1.1.1.1
+++ xemacs-packages/tm/tm-vm.el 2002/12/17 23:13:12
＠＠ -38,7 +38,9 ＠＠
(eval-when-compile
(require 'tm-mail)
(require 'vm)
- (require 'vm-window))
+ (require 'vm-window)
+ (require 'vm-easymenu)
+ (require 'vm-macro))
(require 'tm-edit)
(require 'tm-view)
Index: xemacs-packages/vhdl/vhdl-mode.el
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/vhdl/vhdl-mode.el,v
retrieving revision 1.4
diff -d -u -u -r1.4 vhdl-mode.el
--- xemacs-packages/vhdl/vhdl-mode.el 2001/02/17 01:25:49 1.4
+++ xemacs-packages/vhdl/vhdl-mode.el 2002/12/17 23:13:16
＠＠ -12834,13 +12834,6 ＠＠
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Display functions
-;; macros must be defined in the file they are used (copied from `speedbar.el')
-(defmacro speedbar-with-writable (&rest forms)
- "Allow the buffer to be writable and evaluate FORMS."
- (list 'let '((inhibit-read-only t))
- (cons 'progn forms)))
-(put 'speedbar-with-writable 'lisp-indent-function 0)
-
(defun vhdl-speedbar-display-directory (directory depth &optional rescan)
"Display directory and hierarchy information in speedbar."
(setq vhdl-speedbar-show-projects nil)
Index: xemacs-packages/xemacs-base/ffap.el
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/xemacs-base/ffap.el,v
retrieving revision 1.6
diff -d -u -u -r1.6 ffap.el
--- xemacs-packages/xemacs-base/ffap.el 2002/10/20 08:38:03 1.6
+++ xemacs-packages/xemacs-base/ffap.el 2002/12/17 23:13:16
＠＠ -1289,7 +1289,7 ＠＠
(if (boundp 'PC-completion-as-file-name-predicate)
;; modern version of complete.el, just set the variable:
(setq PC-completion-as-file-name-predicate 'ffap-complete-as-file-p)
- (require 'advice)
+ (eval-when-compile (require 'advice))
(defadvice PC-do-completion (around ffap-fix act)
"Work with ffap."
(let ((minibuffer-completion-table
Index: xemacs-packages/xemacs-devel/Makefile
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/xemacs-devel/Makefile,v
retrieving revision 1.57
diff -d -u -u -r1.57 Makefile
--- xemacs-packages/xemacs-devel/Makefile 2002/12/08 21:31:10 1.57
+++ xemacs-packages/xemacs-devel/Makefile 2002/12/17 23:13:16
＠＠ -24,7 +24,7 ＠＠
MAINTAINER = XEmacs Development Team <xemacs-beta(a)xemacs.org>
PACKAGE = xemacs-devel
PKG_TYPE = single-file
-REQUIRES = xemacs-base ispell mail-lib gnus
+REQUIRES = xemacs-base ispell mail-lib gnus rmail tm apel
CATEGORY = standard
ELCS = bench.elc checkdoc.elc docref.elc eldoc.elc elp.elc eval-expr.elc \
--
Jerry James
http://www.ittc.ku.edu/~james/
9:06 p.m.
New subject: [A] [PATCH packages] Expand macros at compile time
APPROVE
On Wed, 2002-12-18 at 01:58, Jerry James wrote:
Here is the patch. This makes my script complain about only two
uses:
the expected x-color-defined-p use in zenirc-color.el, and the
combine-after-change-calls use in mmm-cmds.el. I await opinions from
the powers that be on whether combine-after-change-calls should be
defined in fsf-compat and, if so, where.
I trust your analysis is correct, go ahead and commit, Jerry. Thanks
for looking into this!
While you're at it, could you also check if Ben's (yet unapplied)
diff-mode dependency fix should be handled the same way as this patch
fixes things instead of Makefile tricks? The patch is at
<http://list-archive.xemacs.org/xemacs-patches/200212/msg00083.html>;.
--
\/ille Skyttä
scop at xemacs.org
11:34 p.m.
New subject: [A] [PATCH packages] Expand macros at compile time
Ville Skyttä <scop(a)xemacs.org> wrote:
I trust your analysis is correct, go ahead and commit, Jerry.
You're going to regret trusting my analysis, you know. :-) Committed.
While you're at it, could you also check if Ben's (yet
unapplied)
diff-mode dependency fix should be handled the same way as this patch
fixes things instead of Makefile tricks? The patch is at
<http://list-archive.xemacs.org/xemacs-patches/200212/msg00083.html>;.
Hmmm... The stuff I just did seems to show that a bunch more
dependencies like that are needed. I wonder if there is some way of
automatically extracting such dependencies? I can think of a byte
compiler modification that would make it easy, but that might not be a
popular way to go. (Basically, you would record the source path for
each macro as it is defined, and upon expanding a macro, compare the
source path for the file being compiled with the source path for the
macro, and emit a log record if they are not in the same directory.
Then a post-processor could pick out those records and compute the
dependencies.)
Anyway, I think Ben's change is harmless, at least, and probably a good
idea.
--
Jerry James
http://www.ittc.ku.edu/~james/
2:58 a.m.
New subject: Automated package dependencies
Talking to myself again. I must be an academician or something...
I wrote:
That is correct. I'll have to move some provides then. I
hadn't
thought about defsubsts, either, so I'll deal with those once I get the
macros to settle down and behave correctly. Keep watching for a patch.
I'll get a successful compile one of these days...
Okay, after making some changes to my scripts to make them behave in a
nicer fashion, applying my recent patch to (nearly) wipe out instances
of miscompiled macros, and adding the check for defsubst, this is the
current output. The x-color-defined-p and combine-after-change-calls
are the remaining macro cases; the rest are defsubsts. I still need
input on what to do with combine-after-change-calls.
read-event:
Definition: xemacs-packages/pcomplete/pcomplete.el
Miscompile: xemacs-packages/xemacs-base/comint.el
decode-mime-charset-region-default:
Definition: xemacs-packages/apel/mcs-xm.el
Miscompile: xemacs-packages/apel/mcs-xmu.el
read-event:
Definition: xemacs-packages/pcomplete/pcomplete.el
Miscompile: xemacs-packages/tpu/tpu-mapper.el
bbdb-string-trim:
Definition: xemacs-packages/bbdb/lisp/bbdb.el
Miscompile: xemacs-packages/eudc/eudc-export.el
read-event:
Definition: xemacs-packages/pcomplete/pcomplete.el
Miscompile: xemacs-packages/supercite/supercite.el
read-event:
Definition: xemacs-packages/pcomplete/pcomplete.el
Miscompile: xemacs-packages/gnus/gnus/lisp/gnus-util.el
set-buffer-multibyte:
Definition: xemacs-packages/apel/poem-xm.el
Miscompile: xemacs-packages/gnus/gnus/lisp/gnus-util.el
set-buffer-multibyte:
Definition: xemacs-packages/apel/poem-xm.el
Miscompile: xemacs-packages/gnus/gnus/lisp/imap.el
set-buffer-multibyte:
Definition: xemacs-packages/apel/poem-xm.el
Miscompile: xemacs-packages/gnus/gnus/lisp/mail-source.el
set-buffer-multibyte:
Definition: xemacs-packages/apel/poem-xm.el
Miscompile: xemacs-packages/gnus/gnus/lisp/mm-util.el
string-as-multibyte:
Definition: xemacs-packages/apel/poem.el
Miscompile: xemacs-packages/gnus/gnus/lisp/qp.el
set-buffer-multibyte:
Definition: xemacs-packages/apel/poem-xm.el
Miscompile: xemacs-packages/gnus/gnus/lisp/qp.el
mm-handle-media-type:
Definition: xemacs-packages/gnus/gnus/lisp/mm-decode.el
Miscompile: xemacs-packages/gnus/gnus/lisp/rfc2015.el
bbdb-search-simple:
Definition: xemacs-packages/bbdb/lisp/bbdb.el
Miscompile: xemacs-packages/tm/mu-bbdb.el
bbdb-search-simple:
Definition: xemacs-packages/bbdb/lisp/bbdb.el
Miscompile: xemacs-packages/tm/tm-bbdb.el
vm-real-message-of:
Definition: xemacs-packages/vm/vm-message.el
Miscompile: xemacs-packages/tm/tm-vm.el
vm-buffer-of:
Definition: xemacs-packages/vm/vm-message.el
Miscompile: xemacs-packages/tm/tm-vm.el
vm-headers-of:
Definition: xemacs-packages/vm/vm-message.el
Miscompile: xemacs-packages/tm/tm-vm.el
vm-text-of:
Definition: xemacs-packages/vm/vm-message.el
Miscompile: xemacs-packages/tm/tm-vm.el
vm-virtual-messages-of:
Definition: xemacs-packages/vm/vm-message.el
Miscompile: xemacs-packages/tm/tm-vm.el
vm-set-modflag-of:
Definition: xemacs-packages/vm/vm-message.el
Miscompile: xemacs-packages/tm/tm-vm.el
vm-start-of:
Definition: xemacs-packages/vm/vm-message.el
Miscompile: xemacs-packages/tm/tm-vm.el
vm-end-of:
Definition: xemacs-packages/vm/vm-message.el
Miscompile: xemacs-packages/tm/tm-vm.el
vm-new-flag:
Definition: xemacs-packages/vm/vm-message.el
Miscompile: xemacs-packages/tm/tm-vm.el
vm-unread-flag:
Definition: xemacs-packages/vm/vm-message.el
Miscompile: xemacs-packages/tm/tm-vm.el
vm-number-of:
Definition: xemacs-packages/vm/vm-message.el
Miscompile: xemacs-packages/tm/tm-vm.el
vm-text-end-of:
Definition: xemacs-packages/vm/vm-message.el
Miscompile: xemacs-packages/tm/tm-vm.el
set-buffer-multibyte:
Definition: xemacs-packages/apel/poem-xm.el
Miscompile: xemacs-packages/mew/mew/mew-decode.el
x-color-defined-p:
Definition: xemacs-packages/perl-modes/cperl-mode.el
Miscompile: xemacs-packages/zenirc/src/zenirc-color.el
semantic-token-start:
Definition: xemacs-packages/semantic/semantic.el
Miscompile: xemacs-packages/semantic/semantic-example.el
semantic-token-start:
Definition: xemacs-packages/semantic/semantic.el
Miscompile: xemacs-packages/semantic/semantic-util-modes.el
semantic-token-end:
Definition: xemacs-packages/semantic/semantic.el
Miscompile: xemacs-packages/semantic/semantic-util-modes.el
semantic-flex-start:
Definition: xemacs-packages/semantic/semantic.el
Miscompile: xemacs-packages/semantic/semantic-util-modes.el
semantic-flex-end:
Definition: xemacs-packages/semantic/semantic.el
Miscompile: xemacs-packages/semantic/semantic-util-modes.el
read-event:
Definition: xemacs-packages/pcomplete/pcomplete.el
Miscompile: xemacs-packages/emerge/emerge.el
line-beginning-position:
Definition: xemacs-packages/eshell/esh-util.el
Miscompile: xemacs-packages/idlwave/idlwave.el
read-event:
Definition: xemacs-packages/pcomplete/pcomplete.el
Miscompile: xemacs-packages/jde/lisp/efc.el
line-beginning-position:
Definition: xemacs-packages/eshell/esh-util.el
Miscompile: xemacs-packages/jde/lisp/jde-db.el
line-end-position:
Definition: xemacs-packages/eshell/esh-util.el
Miscompile: xemacs-packages/jde/lisp/jde-db.el
read-event:
Definition: xemacs-packages/pcomplete/pcomplete.el
Miscompile: xemacs-packages/prog-modes/simula.el
read-event:
Definition: xemacs-packages/pcomplete/pcomplete.el
Miscompile: xemacs-packages/eterm/term.el
set-buffer-multibyte:
Definition: xemacs-packages/apel/poem-xm.el
Miscompile: xemacs-packages/eshell/eshell.el
line-beginning-position:
Definition: xemacs-packages/eshell/esh-util.el
Miscompile: xemacs-packages/pcomplete/pcmpl-cvs.el
line-end-position:
Definition: xemacs-packages/eshell/esh-util.el
Miscompile: xemacs-packages/pcomplete/pcmpl-cvs.el
line-end-position:
Definition: xemacs-packages/eshell/esh-util.el
Miscompile: xemacs-packages/pcomplete/pcmpl-linux.el
read-event:
Definition: xemacs-packages/pcomplete/pcomplete.el
Miscompile: xemacs-packages/pcomplete/pcomplete.el
ediff-multiframe-setup-p:
Definition: xemacs-packages/ediff/ediff-init.el
Miscompile: xemacs-packages/edit-utils/lazy-lock.el
semantic-token-p:
Definition: xemacs-packages/semantic/semantic.el
Miscompile: xemacs-packages/speedbar/speedbar.el
semantic-token-name:
Definition: xemacs-packages/semantic/semantic.el
Miscompile: xemacs-packages/speedbar/speedbar.el
read-event:
Definition: xemacs-packages/pcomplete/pcomplete.el
Miscompile: xemacs-packages/calc/calc.el
read-event:
Definition: xemacs-packages/pcomplete/pcomplete.el
Miscompile: xemacs-packages/hm--html-menus/adapt.el
set-buffer-multibyte:
Definition: xemacs-packages/apel/poem-xm.el
Miscompile: xemacs-packages/psgml/psgml-dtd.el
match-string-no-properties:
Definition: xemacs-packages/prog-modes/verilog-mode.el
Miscompile: xemacs-packages/text-modes/po-mode.el
line-end-position:
Definition: xemacs-packages/eshell/esh-util.el
Miscompile: xemacs-packages/tramp/lisp/tramp.el
set-buffer-multibyte:
Definition: xemacs-packages/apel/poem-xm.el
Miscompile: xemacs-packages/sieve/sieve-manage.el
combine-after-change-calls:
Definition: xemacs-packages/prog-modes/diff-mode.el
Miscompile: xemacs-packages/mmm-mode/mmm-cmds.el
match-string-no-properties:
Definition: xemacs-packages/prog-modes/verilog-mode.el
Miscompile: xemacs-packages/ess/lisp/ess-latex.el
match-string-no-properties:
Definition: xemacs-packages/prog-modes/verilog-mode.el
Miscompile: xemacs-packages/ess/lisp/noweb-mode.el
read-event:
Definition: xemacs-packages/pcomplete/pcomplete.el
Miscompile: xemacs-packages/ocaml/inf-caml.el
string-as-unibyte:
Definition: xemacs-packages/apel/poem.el
Miscompile: xemacs-packages/sasl/ntlm.el
read-event:
Definition: xemacs-packages/pcomplete/pcomplete.el
Miscompile: xemacs-packages/fortran-modes/f90.el
set-buffer-multibyte:
Definition: xemacs-packages/apel/poem-xm.el
Miscompile: xemacs-packages/pgg/pgg.el
set-buffer-multibyte:
Definition: xemacs-packages/apel/poem-xm.el
Miscompile: xemacs-packages/pgg/pgg-parse.el
line-end-position:
Definition: xemacs-packages/eshell/esh-util.el
Miscompile: mule-packages/mule-base/ethio-util.el
lookup-temp-buffer:
Definition: mule-packages/lookup/lisp/lookup.el
Miscompile: mule-packages/lookup/lisp/lookup-utils.el
--
Jerry James
http://www.ittc.ku.edu/~james/
10:29 a.m.
New subject: Automated package dependencies
>>>> "Jerry" == Jerry James
<james(a)xemacs.org> writes:
Jerry> decode-mime-charset-region-default:
Jerry> Definition: xemacs-packages/apel/mcs-xm.el
Jerry> Miscompile: xemacs-packages/apel/mcs-xmu.el
APEL. Why am I not surprised.
However, anything involving APEL should be treated _very_ carefully.
APEL compiles are XEmacs version dependent, and often involve
replacing primitive functions.
The combine-after-change-calls question is in my queue, but that may
need to wait for Ben to get back or Hrvoje to resurface.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
10:41 a.m.
New subject: Automated package dependencies
>>>> "Jerry" == Jerry James
<james(a)xemacs.org> writes:
Jerry> "Stephen J. Turnbull" <stephen(a)xemacs.org> wrote:
> Why an eval-when? require is already specially treated at
> compile time. Just require the file and be done with it.
Jerry> But only at top-level, apparently.
That needs to be fixed, but it's not going to be done in 21.4.
Jerry> The miscompiled defadvice in ffap.el immediately follows a
Jerry> (require 'advice), but it is not at top-level.
My preference would be to move the require to top-level.
Jerry> Also, some of the miscompiled macros I'm seeing are taken
Jerry> care of with a require at compile time, but there is no run
Jerry> time dependency on the file containing the macro. Doing an
Jerry> (eval-when-compile (require 'foo)) makes perfect sense in
Jerry> that case.
"Perfect sense" assumes either (a) somebody keeps perfect track of
changes to code and removes the eval-when if necessary, or (b) the
macro's code is frozen, guaranteed never to be changed again. It
makes a lot of sense as an optimization, but it's nothing more than
that. And it's not clear to me if the space saving is anything but
negligible.
Some packages, like VM, collect all their macros into a single file.
But even then you can't be sure that they won't call out to something
else that is required in the macro library.
Jerry> Some of the miscompiled macros have autoload cookies
Jerry> already, but the containing package was not in the REQUIRES
Jerry> list. I've just added to REQUIRES in those cases.
Cool.
Jerry> That is correct. I'll have to move some provides then. I
Jerry> hadn't thought about defsubsts, either,
Good, I'm glad my pessimism occasionally serves more usefully than
just a strong depressant. :-)
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
8012
days inactive
8017
days old
21 comments
7 participants
participants (7)
-
Adrian Aichner -
Jeff Mincy -
Jerry James -
Rendhalver [Peter Brown] -
Stephen J. Turnbull -
Valdis Kl=?iso8859-4?Q?=BA?=tnieks -
Ville Skyttä