>>>> "Ben" == Ben Wing <ben(a)666.com>
writes:
Ben> Stephen J. Turnbull wrote:
> Current Mule, it's hard to even pass a sane value for where
an
> error happened because of the layers on layers of buffering in
> coding streams.
Ben> This has nothing to do with whether it's written in C or
Ben> Python and everything to do with the buffering, which would
Ben> be the same in either case.
I didn't say passing error codes was hard because it was in C
vs. Python; I was pointing out that the Python design doesn't do much
buffering, so sane error-recovery is possible, and that because it's
in Python, people who are not Python C internals geeks can work on it
safely. I'd like the next generation of XEmacs to be informed by
those design principles.
> Could be. But it's quite clear you're more worried
about
> maintaining Mule compatibility and efficiency for 50MB buffers
> than about getting the cleanest possible design in front of the
> reviewers and testers as quickly as possible.
Ben> all right, stephen, i've had enough; you're really starting
Ben> to piss me off.
You asked for help, but you obviously don't really want the help
that's available. So just commit it when you're ready, and we'll
either like it or not.
I don't really care; I have no doubt that the 18000 line patch you
sent me is far better for my purposes than what we currently have.
But I am not going to be able to reverse engineer architecture from
that in a reasonable amount of time, so I'm not even going to try.
(That doesn't mean I'm not going to study the code, it just means it
will probably be 6 months to a year before I'm ready to give you the
kind of help you want.)
--
School of Systems and Information Engineering
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.