Ar an seachtú lá déag de mí Lúnasa, scríobh Stephen J. Turnbull:
[...] Also, as long as we're here, it has long been my opinion
that there
should be a single test suite, with individual tests conditionalized on
version as appropriate. This could be packaged, which would also make
test-harness.el available to packages for their own automated tests.
However Martin was quite strongly opposed, on the grounds that tests are
very often implementation specific. My response to that (at the risk of
understating his reasons) is that where code can be shared, it should be,
and where it can't be, it should be explicitly marked as such. The one
test suite, version-conditional tests satisfies both criteria IMO.
Comments?
Yes, that’s a reasonable approach.
Vin Shelton writes:
> So, I think there are 3 things wrong here:
>
> (1) [Minor] the "Wrote /home/acs/test-revert-buffer-resets-modiff"
> should be suppressed.
Wrap the call to `save-buffer' in a call to `Silence-Message'. This
may have been intentional to ensure a reminder to fix:
> BTW, why is it writing this file to my home
> directory? Shouldn't the test use some temporary directory or the
> build or test directory?
Yes. I couldn't remember whether `make-temp-name' was the sanctioned
(robust and secure) way to do this, so I punted.
It is, AIUI. Though the Gnus people do check with #’file-already-exists
after they call it--see
http://tinyurl.com/2hm355 in Google code search.
> (2) The actual unexpected errors: "Unsupported Unicode
code point"...
If Aidan wants to work on this, he probably knows more about it than I
do offhand. If he doesn't, I'll get to it.
The issue here is that I just changed the Lisp reader to error when it sees
a Unicode code point that the current XEmacs doesn’t support. Portable code
needs to be able to handle this case, because that’s what GNU does too; and
we support all valid UCS code points right now in Mule XEmacs, so we don’t
error illegitimately there. However, it happens *all the time* under
non-Mule XEmacs, which is kind of the point of non-Mule XEmacs.
Okay, I’ve got a solution; call #’read at runtime on escaped versions of the
relevant strings. The tests aren’t executed on non-Mule, so the error won’t
happen, but the Unicode escape functionality will still be tested in passing
(while testing the coding-cookie-in-compiled-files functionality). I’ll send
a patch later today.
> (3) The fact that the summary does not report the unexpected
errors.
This may be hard to do well. I'll take a look at it.
> Unexpected error (error "Can't activate input method
> `german-postfix'") while executing interpreted code.
This is due to the fact that the Makefile suppresses adding packages
to the load-path. Probably the best thing to do is have a
package-dependent-tests.el, which is run as a separate command.
os-tests.el calls #’Skip-Test-Unless in a similar context (when components
required for a test are not available) so something similar might be the
least intrusive approach; I’m not certain what the right check would be,
though-- (assq 'leim packages-package-list) ? But leim doesn’t provide all
the input methods--egg and skk are exceptions, at least.
--
On the quay of the little Black Sea port, where the rescued pair came once
more into contact with civilization, Dobrinton was bitten by a dog which was
assumed to be mad, though it may only have been indiscriminating. (Saki)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta