4:52 p.m.
Seems to be mildly broken.
auto-autoloads.el* are generated in $srcdir/modules/, not
$blddir/modules/$module/.
module-load-path ends up being "$blddir/modules/".
(require 'postgresql) fails.
(load-module "postgresql") fails.
(load-module "postgresql/postgresql") succeeds.
Some non-`--srcdir' gnits:
It would be nice if zlib and base64 were detected by toplevel
configure and added to MAKE_SUBDIR.
What happens if both Gnus and modules/base64 provide `base64-encode'?
Which wins? Does list-load-path-shadows detect these as shadows?
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
5:11 p.m.
>>>> "sjt" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
sjt> module-load-path ends up being "$blddir/modules/".
sjt> (require 'postgresql) fails.
appending "postgresql" to the load-path element enables the require to
succeed.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
5:32 p.m.
On Wed, 16 Oct 2002 01:11:26 +0900, "Stephen J. Turnbull" said:
>>>>> "sjt" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
sjt> module-load-path ends up being "$blddir/modules/".
sjt> (require 'postgresql) fails.
appending "postgresql" to the load-path element enables the require to
succeed.
This is sort of what I was getting at with my previous mail - is this a
"require" that *has* to be there, or just a case of getting some other
package to load without complaint?
/Valdis (who ends up using sumo's because it Just Sucks Too Hard to try to
unsnarl all the packages that add features I don't need to packages I wanted)
6:27 p.m.
>>>> "Valdis" == Valdis Kletnieks
<Valdis.Kletnieks(a)vt.edu> writes:
Valdis> On Wed, 16 Oct 2002 01:11:26 +0900, "Stephen J. Turnbull"
Valdis> said:
> appending "postgresql" to the load-path element enables
the
> require to succeed.
Valdis> This is sort of what I was getting at with my previous
Valdis> mail - is this a "require" that *has* to be there, or just
Valdis> a case of getting some other package to load without
Valdis> complaint?
This is a require that _has_ to be there, because we're testing
whether require works at all for modules defined in C. :-) No other
packages involved at all....
Valdis> /Valdis (who ends up using sumo's because it Just Sucks
Valdis> Too Hard to try to unsnarl all the packages that add
Valdis> features I don't need to packages I wanted)
All reasonably large systems with dependencies end up this way. We'd
like to do better, but it's a PITA and disk is cheap....
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
2:29 p.m.
|--==> "VK" == Valdis Kletnieks <Valdis.Kletnieks(a)vt.edu> writes:
VK> /Valdis (who ends up using sumo's because it Just Sucks Too Hard
VK> to try to unsnarl all the packages that add features I don't
VK> need to packages I wanted)
Why don't you:
- Initially install the packages that you want via PUI and
*don't* do 'pui-add-required-packages' [1]
- And then, every once in a while do 'M-x
package-get-update-all'
,----[ C-h f package-get-update-all RET ]
| `package-get-update-all' is an interactive compiled Lisp function
| -- loaded from "package-get"
| (package-get-update-all)
|
| Documentation:
| Fetch and install the latest versions of all currently installed packages.
`----
If I'm understanding you correctly, that should do exactly what you
want.
Footnotes:
[1] People have been asking for this to be implemented
unconditionally so that you always get what's required. IMO this
is a good thang[tm] providing it can be switched off.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
5:32 p.m.
On Wed, 16 Oct 2002 23:29:11 +1000, Steve Youngs <youngs(a)xemacs.org> said:
Why don't you:
- Initially install the packages that you want via PUI and
*don't* do 'pui-add-required-packages' [1]
This of course assumes that I know what set of packages I *really* want...
(I'm playing devil's advocate here - there's nothing insurmountable here,
just a lot of headaches that take time - something that's always lacking ;)
To quote http://www.xemacs.org/Documentation/packageGuide.html
" This is difficult to say. When in doubt, install a package. If you
administrate a big site it might be a good idea to just install everything. A
good minimal set of packages for XEmacs-latin1 would be
As mentioned before, an overview of existing packages and their purpose may be
found at ../Develop/packages.html and under the XEmacs source tree in etc/
PACKAGES.
xemacs-base, xemacs-devel, c-support, cc-mode, debug, dired, efs,
edit-utils, fsf-compat, mail-lib, net-utils, os-utils, prog-modes, text-modes,
time
Unfortunately the package system currently provides neither dependencies nor
conflicts. This will be a future enhancement. The above set includes most
packages that are used by others."
Hmm.. dangling list for latin1.. ;)
And if we don't do dependencies, what's this requires/provides entries in
the package-index file? ;)
Gnus requires w3, and w3 contains a require for emacspeak. Fortunately, it's
protected by an (if (featurep 'emacspeak), and it's not listed as a
'requires'
for w3 in the package-index. On the other hand, I don't see a listing for
emacspeak in the package-index at all (yes, I know it's not in the Sumos
either). But that's OK - it's an *optional* package and won't get sucked in
unless I want that, and the target goal was to only have the subset of stuff
that I want.
Meanwhile, a little ad-crock grep/tr/wc magic shows 53 different things listed
as 'requires' in package-index, and 1,237 'provides' listed. That's
really
confidence-inspiring - combined with the 'emacspeak' example above, it makes
me not trust the 'requires' list provided. Yes, I know the provides are on
the function level and the requires are packages - but now I get to worry
whether the aggregation was done right. Some spot checking, and we find that
mmm-mode requires xemacs-base and fsf-compat - but ibuffer requires *itself*
and xemacs-base. Tramp requires itself, text-modes doesn't. (Yes, I understand
why this is so - doesn't make it any less weird.. ;)
Screw this, it's time to just install the Sumo and pray. Score one for software
bloat. ;)
/Valdis
3:47 a.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> wrote:
Seems to be mildly broken.
You know, it's really hard for me to cultivate an air of infallibility
when you guys keep finding bugs in my code.
auto-autoloads.el* are generated in $srcdir/modules/, not
$blddir/modules/$module/.
I did this on purpose, because the installed XEmacs doesn't have any
subdirectories under "modules". All of the .ell files are in the same
directory, so that's where the (sole) autoload file needs to go. You
are correct in pointing out that this breaks run-in-place, however.
module-load-path ends up being "$blddir/modules/".
That was true before I came along. I just haven't done anything about
it. What should happen is that run-in-place sets module-load-path in a
manner analogous to how load-path is set for the installed XEmacs; i.e.,
every subdirectory of $blddir/modules is added to module-load-path. Now
that I think about it, it would work to add every subdirectory now, as
long as the top-level directory is in module-load-path, too. For the
installed XEmacs, this is right because there aren't any subdirectories,
so only the top-level directory appears. For run-in-place, this is
right even though we get the useless top-level directory entry. I'll
whip up a patch this weekend.
It would be nice if zlib and base64 were detected by toplevel
configure and added to MAKE_SUBDIR.
They aren't ready for prime-time yet. Those modules predate me, and
have the appearance of never quite having been finished. Take a look at
zlib.c, for example. Looks useful, eh? The base64 code is closer to
being something useful, but ...
What happens if both Gnus and modules/base64 provide
`base64-encode'?
Which wins? Does list-load-path-shadows detect these as shadows?
... we don't need it, unless the Gnus version is abysmally slow.
Shadows are a problem. It appears that list-load-path-shadows is only
checking filenames along load-path, so it would not detect such a
problem. As for which one wins, that depends on the order in which
autoloads are loaded. If you look in startup.el (end of the file),
you'll see that module autoloads are loaded first, then package
autoloads. This means that Gnus would win; the base64 module would
never get loaded unless the user explicitly loaded it with load-module.
That's a good thing, IMO. You get the Lisp code unless you explicitly
ask for the (hopefully equivalent) C code, presumably in response to
performance problems.
--
Jerry James
http://www.ittc.ku.edu/~james/
4:23 a.m.
>>>> "Jerry" == Jerry James
<james(a)xemacs.org> writes:
> auto-autoloads.el* are generated in $srcdir/modules/, not
> $blddir/modules/$module/.
Jerry> I did this on purpose,
Ah, OK. Except that the $srcdir/$blddir confusion needs to be ironed
out---are you actually going to find the auto-autoloads to install,
correctly?
The rest all sounds good to me, with the promised patches.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
2:19 p.m.
|--==> "SJT" == Stephen J Turnbull <stephen(a)xemacs.org> writes:
SJT> What happens if both Gnus and modules/base64 provide
SJT> `base64-encode'? Which wins? Does list-load-path-shadows
SJT> detect these as shadows?
What happens now? base64-(d)?encode-* are built-in functions and
'base64' is provided as a feature (base64.c line 420). So if you have
the base64.el from Gnus and or mail-lib, which wins?
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
9:52 a.m.
Steve Youngs <youngs(a)xemacs.org> writes:
|--==> "SJT" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
SJT> What happens if both Gnus and modules/base64 provide
SJT> `base64-encode'? Which wins? Does list-load-path-shadows
SJT> detect these as shadows?
What happens now? base64-(d)?encode-* are built-in functions and
'base64' is provided as a feature (base64.c line 420). So if you have
the base64.el from Gnus and or mail-lib, which wins?
If someone does (require 'base64) the internal one is used, but if
someone uses (load "base64") the loaded one will be used. I think
this is what you would expect. (But the Gnus XEmacs package doesn't
contain base64.el, does it?)
2:59 p.m.
|--==> "SJ" == Simon Josefsson <jas(a)extundo.com> writes:
SJ> Steve Youngs <youngs(a)xemacs.org> writes:
>What happens now? base64-(d)?encode-* are built-in functions and
>'base64' is provided as a feature (base64.c line 420). So if you
>have the base64.el from Gnus and or mail-lib, which wins?
SJ> If someone does (require 'base64) the internal one is used, but
SJ> if someone uses (load "base64") the loaded one will be used. I
SJ> think this is what you would expect.
Yep.
SJ> (But the Gnus XEmacs package doesn't contain base64.el, does
SJ> it?)
No it doesn't, it was moved into mail-lib (and the one in w3 was
nuked). There is a base64.el in Oort, but it's in the contrib
directory.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
7860
days inactive
7862
days old
10 comments
5 participants
participants (5)
-
Jerry James -
Simon Josefsson -
Stephen J. Turnbull -
Steve Youngs -
Valdis Kl=?iso8859-4?Q?=BA?=tnieks