Re: hello again

>>>>> "Ben" == Ben Wing <[email protected]> writes:

    Ben> andy mentioned that perhaps kyle is back?

Kyle is definitely not "back" yet, although as always Kyle responds to
pings, and occasionally posts opinions about stuff (most recently,
some questions about readability of fonts).

Steve Youngs has resigned from the Board (probably, he's been waffling
about it).  Hrvoje is back as a reviewer, but hasn't yet been able to
commit time to coding.  Didier and Olivier popped their heads up
briefly, and Olivier contributed a couple of patches, but they didn't
seem able to commit chunks of time.  Ditto Bill P.  Martin has
contributed an intermittent stream of patches recently.  Yoshiki
posted once.

Jerry James, Norbert Koch, and Ville Skytta joined the Board while you
were away; Ville's currently mostly inactive (and was mostly working
on packages).  Norbert works exclusively on packages.

    Ben> anyway, i'm wondering if someone can fill me in on what's
    Ben> currently going on, and especially on what the current
    Ben> problems are that need to be fixed.

AFAIK, not much has changed in the low-level code base, at least the
parts you work on most, since you left.

KKCC (the new GC algorithm/architecture) is mostly finished, and Mike
says they're about ready to add a new collector as an option.  Jerry
has been doing a lot of work on modules, and has them mostly working
on Windows.  There have been changes in at least one pervasive macro:
Jerry fixed the xfree macro to not have aliasing problems when
error-checking memory.

A few bugs in regexp and search have been found and fixed.

I've been slogging through the Mule code, which I understand a lot
better now, and plan to start integrating latin-unity features (but
not as implemented in latin-unity, which has problems similar to those
of GNU's "safe-charsets" feature).  I also want to disable ISO 2022
escape sequences in ISO 8859 coding systems, which will be safe once
latin-unity is in place.  (That's a non-conforming Mule/GNU extension
to ISO 8859 AFAICT.)

There's an experimental patch to add Xft (font anti-aliasing) support
to X builds.  I've been keeping an eye on that with a view to
Mule-izing lwlib.

At higher levels, Steve Y did a bunch of work on PUI, and there have
been some minor fixes to Lisp.  Lots of new packages (including
hyperbole and oo-browser from Infodock.)

I'm also working on getting a real issue tracker implemented.

Problems in 21.4 and 21.5 known to me:

1.  Font selection seems quite broken on many X platforms.  The
    Options menu sometimes doesn't work, sizing is screwy, etc.

2.  There are data loss problems in streams.  One seems to be
    associated with Mule-UCS and UTF-8 files, the other hit me doing a
    C-u M-! cvs diff.

3.  The egregious XFree86 standard violation where they use Compound
    Text extended segments to encode ISO 8859-15 in Compound Text, in
    particular when transferring text selections.  We really need to
    deal with this, it's a FAQ.  (I have a hack that I'll put into
    latin-unity, but since it's not in the ISO 2022 coding stream,
    there are several possible failure modes.)

Problems in 21.5 known to me:

1.  Cygwin 1.5 and Windows XP instability.  Both platforms are rife
    with problems.  With Andy busy (he's still running some ancient
    version of Cygwin and maybe Windows 2000 precisely to avoid the
    instability), we really have no experience to bring to bear on
    those problems.

2.  There's a test failure in --without-mule builds because EOL is not
    being correctly recognized (I think, not fully analyzed).

3.  There's a problem with coding systems in processes.  Maybe it's
    just that process-coding-system-alist is initialized to nil?  (I
    just thought of that, sorry.)

4.  Coding detection is still very weak.  I'm less than happy with the
    coding detection algorithm, too---we can discuss that later, I'm
    not sure my ideas are practical.  I really should put together a
    corpus of texts to use to test that.  But definitely we need to
    have more sensible defaults (I'm not sure where, I don't have any
    problems).

5.  There are some issues in the byte-code interpreter.  The weak
    references (empherons) that Mike & Co have implemented now have a
    test suite, but it always fails because the interpreter protects
    its whole allocated stack, which typically includes old objects.
    So Mike changed the GC_PROS to protect only what was needed, but
    apparently there are bytecodes that can unexpectedly GC.  (The
    first one found was Fset, it GCs via a dontusethis-* handler.
    But there are others.)  This is usually referred to as the "freed
    lrecord" crash.

There are probably others.

    Ben> also, i definitely have a bunch of workspaces containing
    Ben> uncommitted material, which at the very least i'd like to get
    Ben> somewhere on [the/a] server.

To get them on the server, just commit them to branches.  At least
people will be able to review them there, and it probably will help
with version skew.


-- 
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.