3:29 a.m.
The XEmacs Package Smoketest writes:
These are the results from the XEmacs Package Smoketest:
21.5-nomule -- ok
21.5-mule -- ok
21.4-mule -- errors
21.4-nomule -- errors
Isn't it time we fix this?
Well, I've updated package-future.el to take account of Mike's most
recent tweaks (autoload-operators.el in xemacs-base). I made the
obvious change, it (somewhat surprisingly) worked the first time,
except for this crap in jde/lisp/auto-autoloads.el.
What happens, I think, is that the defcustom gets run at autoload
time, and that calls the set method, which calls
`tempo-define-template', which isn't defined.
I think this has to go.
;;;###autoload
(defcustom jde-gen-hashcode-method-template
'("'>"
"\"/**\" '> 'n"
"\" * Calculate the hash code for this object.\" '>
'n"
"\" * \" '> 'n"
"\" * <p>The rules laid out in J. Blosh's Effective Java are
used\" '> 'n"
"\" * for the hash code calculation.</p>\" '>
'n"
"\" * \" '> 'n"
"\" * ＠return the hash code.\" '> 'n"
"\" * \" '> 'n"
"\" * ＠see java.lang.Object#hashCode\" '> 'n"
"\" */\" '> 'n"
"(jde-gen-method-signature \"public\"\ \"int\"
\"hashCode\" nil)"
"(jde-gen-electric-brace)"
"(jde-gen-hashcode-body) '> 'n"
"\"}\" '> 'n '>" )
"*Template for creating a hashCode method.
Setting this variable defines a template instantiation command
`jde-gen-hashcode-method', as a side-effect."
:group 'jde-gen
:type '(repeat string)
:set '(lambda (sym val)
(defalias 'jde-gen-hashcode-method
(tempo-define-template
"java-hashcode-method"
(jde-gen-read-template val)
nil
"Create a hashCode method at the current point."))
(set-default sym val)))
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
10:56 a.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
The XEmacs Package Smoketest writes:
> These are the results from the XEmacs Package Smoketest:
>
> 21.5-nomule -- ok
> 21.5-mule -- ok
> 21.4-mule -- errors
> 21.4-nomule -- errors
Isn't it time we fix this?
Well, I've updated package-future.el to take account of Mike's most
recent tweaks (autoload-operators.el in xemacs-base). I made the
obvious change, it (somewhat surprisingly) worked the first time,
except for this crap in jde/lisp/auto-autoloads.el.
What happens, I think, is that the defcustom gets run at autoload
time, and that calls the set method, which calls
`tempo-define-template', which isn't defined.
I think this has to go.
;;;###autoload
(defcustom jde-gen-hashcode-method-template
The XEmacs 21.5 converts this `defcustom' into a `defvar', and thus the
tempo call never makes it into auto-autoloads.el. This change was made
in changeset c4c8a36043be:
2005-02-02 Ben Wing <ben(a)xemacs.org>
* easy-mmode.el, regexp-opt.el:
Move these files into core.
Uncomment stuff depending on new custom.el.
* autoload.el:
[...]
It doesn't seem to be in 21.4. Shouldn't it?
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
4:18 a.m.
Michael Sperber writes:
> What happens, I think, is that the defcustom gets run at
autoload
> time, and that calls the set method, which calls
> `tempo-define-template', which isn't defined.
>
> I think this has to go.
>
> ;;;###autoload
> (defcustom jde-gen-hashcode-method-template
The XEmacs 21.5 converts this `defcustom' into a `defvar', and thus the
tempo call never makes it into auto-autoloads.el.
Isn't that a bad thing? If it isn't, why does this defwhatever need
to be autoloaded at all?
This change was made in changeset c4c8a36043be:
It doesn't seem to be in 21.4. Shouldn't it?
Because 21.4 is the stable branch. Isn't the right question "should
it?"
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6:27 a.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Michael Sperber writes:
> > What happens, I think, is that the defcustom gets run at autoload
> > time, and that calls the set method, which calls
> > `tempo-define-template', which isn't defined.
> >
> > I think this has to go.
> >
> > ;;;###autoload
> > (defcustom jde-gen-hashcode-method-template
>
> The XEmacs 21.5 converts this `defcustom' into a `defvar', and thus the
> tempo call never makes it into auto-autoloads.el.
Isn't that a bad thing? If it isn't, why does this defwhatever need
to be autoloaded at all?
So that references to the variable don't fail, I assume.
> This change was made in changeset c4c8a36043be:
> It doesn't seem to be in 21.4. Shouldn't it?
Because 21.4 is the stable branch. Isn't the right question "should
it?"
Yes.:-)
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
8:58 a.m.
Michael Sperber writes:
> Isn't that a bad thing? If it isn't, why does this
defwhatever need
> to be autoloaded at all?
So that references to the variable don't fail, I assume.
C'mon, Mike, you're being evasive and lazy. If you make me do the
work that you're too lazy to do, don't expect me to be sympathetic.
Now, grep says there aren't any in jde/lisp. Based on the fact that
when setting this variable you also define `jde-gen-hashcode-method'
which uses the tempoized version of that value (*not* the variable),
it is presumably *incorrect* to refer to that variable in code.
I assume the variable itself exists only to allow customization of
`jde-gen-hashcode-method'.
I propose that the sane thing to do is just get rid of autoload
cookies for defcustoms in JDE. I bet you don't ever miss them; only
Paul Kinnucan will (my guess is that he uses customize to make
on-the-fly bugfixes to the templates).
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
9 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Michael Sperber writes:
> > Isn't that a bad thing? If it isn't, why does this defwhatever need
> > to be autoloaded at all?
>
> So that references to the variable don't fail, I assume.
C'mon, Mike, you're being evasive and lazy. If you make me do the
work that you're too lazy to do, don't expect me to be sympathetic.
Sympathy from you? You must be kidding :-)
I'm sorry, I misunderstood your question: I thought you were asking
about why the translation from `defcustom' to `defvar' is made.
Until the next week, I'm really strapped for time: Could you make the
change and remove the autoload cookie, and create an .upstream file?
Otherwise, it will just have to wait until then.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6086
days inactive
6091
days old
5 comments
2 participants
participants (2)
-
Michael Sperber -
Stephen J. Turnbull