Ar an seachtú lá is fiche de mí Aibreán, scríobh Stephen J. Turnbull:
Over the past couple of months HEAD has become pretty much unusable
for ordinary work for me. Now that you've merged Ben's unicode branch,
everything I use pretty quickly runs into an error.
I’m sorry to hear that; it wasn’t something I was aware of. M-x
report-emacs-bug RET still works, to my knowledge.
For one thing, I frequently run into problems with --with-union-type
regularly, such as a lack of an EXFUN declaration for Fvalues, which
at some point since my previous update got used in elhash.c (otherwise
there don't seem to be any uses in C code).
of 2017-03-10 should
have addressed that.
I've also run into issues with non-bignum code on several
started building with bignums but still get too many errors to use trunk
for real work. (I don't know if the Fvalues declaration needs
Non-bignum Lisp code? What code, where?
Perhaps some of it is due to pickier recent compilers (I mostly use
some recent version of LLVM on Mac). For example the chartab_range
initializer bug patched below seems to go back about a decade, and the
Info bug (separate formal patch) goes back to prehistory.
I mostly use some recent version of GCC, 6.something on Mac. Recent-ish LLVM
(clang-3.8) on Debian too. As above I very occasionally build on Win32 with
an ancient compiler on a Windows XP VM, I don’t have the cycles available to
install a more recent MS compiler and fight with it to get things building.
The chartab range initializer bug is Ben’s, from the unicode-internal code.
I'm also seeing (small) increases in the number of tests that
my system, and HEAD seems to infloop (100% CPU for 10 minutes) in
mule-tests on trunk.
Right, I see that on the buildbot, I’ll look into it some evening this week.
To get work done, I've gone back to pre-unicode versions.
Do you have plans to stabilize trunk any time soon?
I use XEmacs every day. It is beta software, but from my perspective it is
as usable and as stable as is the norm for it. I am grateful for your email
communicating that this is not the case for you, and I will work more on it
later this week.
Appended: current patches against r6066. The "labs" patch
should be autoconfiscated, since it involves types of libc functions.
The “labs” patch involves a signed time zone offset from GMT, in seconds.
There are 43200 seconds in 12 hours. If a fixnum value has been supplied
that requires the full bit-width of a long to represent, we should error.
abs() is appropriate, but we should check the range and cast first,
check_integer_range (zone, make_fixnum (60 * 60 * -12),
make_fixnum (60 * 60 * 12));
I have been seeing the warning for that call for a while and didn’t make a
change partly because I hadn’t devoted the cycles to think the above fully
‘As I sat looking up at the Guinness ad, I could never figure out /
How your man stayed up on the surfboard after forty pints of stout’