8:08 a.m.
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
Second, I'm repeating it because as far as I know everybody who
writes Emacs Lisp would prefer that their code function correctly in
as many environments as possible, as long as it costs them nothing
to write it that way. You feel that way, too, you've said so. Do
you habitually write code _knowing_ that if the wrong somebody
borrows it, their application will break?
I don't know how I write code anymore. The MULE APIs have never been
documented, and it's never been published what is and what is not safe
in Mule. I know my code contained the implicit int->char conversions,
because that was easier to write.
Mule breaks too much to be worthy of so much consideration at this
level. Yes, I believe new C code should adhere to existing
abstractions, but I'm not so convinced that we should break (the rest
of) the Lisp world for the sake of Asians. I explained to you many
times now why I tell all my friends to compile _without_ Mule. I'm
not about to repeat it.
12:12 a.m.
New subject: Char-related crashes (hopefully) fixed
>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)iskon.hr> writes:
Hrvoje> Mule breaks too much to be worthy of so much consideration
Hrvoje> at this level.
I see it differently: Mule breaks too much to not get fixed. Mule
breaks so much that it needs to be fixed by design, not by patching
a few weak spots.
The questions are what needs to be fixed and how, in what order. Life
would be a lot easier for Mule fixers if there were no int-char. You
and Kyle are rightly objecting to that as a burden on the traditional
(ASCII -> Latin-1) developer/user base. So I'm looking for a
compromise. But because there are fundamental design problems in the
current Mule, we need to think about the transition to a sensible
design. That is going to break things; but if handled well the
transition can be a minimal burden.
One simple fix is to remove Mule. Of course I'll object to that, but
that's certainly an option for the XEmacs community. I won't be able
to afford to remain a member, though :-(
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
__________________________________________________________________________
__________________________________________________________________________
What are those two straight lines for? "Free software rules."
12:34 a.m.
New subject: Char-related crashes (hopefully) fixed
Stephen J. Turnbull writes:
>>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)iskon.hr> writes:
Hrvoje> Mule breaks too much to be worthy of so much consideration
Hrvoje> at this level.
I see it differently: Mule breaks too much to not get fixed. Mule
breaks so much that it needs to be fixed by design, not by patching
a few weak spots.
I agree with this.
The questions are what needs to be fixed and how, in what order.
Life
would be a lot easier for Mule fixers if there were no int-char. You
and Kyle are rightly objecting to that as a burden on the traditional
(ASCII -> Latin-1) developer/user base. So I'm looking for a
compromise. But because there are fundamental design problems in the
current Mule, we need to think about the transition to a sensible
design. That is going to break things; but if handled well the
transition can be a minimal burden.
Yes, we need a transition plan, but I don't think it necessarily
needs to break things. Right now we have the --with-mule
configuration option. We could leave MULE as it is and
essentially abandon it. We add a new configure option,
--with-i18n=MULE that gives access to the old MULE code for those
who want it or have apps that need it. --with-i18n=NEWGOOP can
build XEmacs with whatever the new design is. With this, we
don't break MULE code or non-MULE code. Stuff only breaks if you
build with --with-i18n=<something-other-than-no>, which is ideal
since it continues to let us roll releases during development.
I think using a name other than MULE for the new design will be
an overall win. The MULE name has baggage associated with it
that I think we want to be free of.
One simple fix is to remove Mule.
That is certainly not something I want to see.
4:37 a.m.
New subject: Char-related crashes (hopefully) fixed
>>>> "Kyle" == Kyle Jones
<kyle_jones(a)wonderworks.com> writes:
Kyle> Right now we have the --with-mule configuration option. We
Kyle> could leave MULE as it is and essentially abandon it. We
Kyle> add a new configure option, --with-i18n=MULE that gives
Kyle> access to the old MULE code for those who want it or have
Kyle> apps that need it.
OK by me. Note that this could easily result in a definitive break
with the FSF line of development if we take advantage of the freedom
that --with-i18n=NEWGOOP gives us in terms of design.
Kyle> --with-i18n=NEWGOOP can build XEmacs with whatever the new
Kyle> design is. With this, we don't break MULE code or non-MULE
Kyle> code. Stuff only breaks if you build with
Kyle> --with-i18n=<something-other-than-no>, which is ideal since
Kyle> it continues to let us roll releases during development.
At some point, code using int-char will have to be retired; but the
transition period will be long and the people who want the new stuff
can bear the burden of hunting it down.
What about byte-compiler warnings and maybe runtime debugging output a
la Ebola for the --with-i18n=no case (the byte-compiler warnings would
be automatic, the runtime stuff would be optional for volunteers
willing to help fix stuff)?
I'm happy with this. One caveat is that I can't volunteer to deal
with the autoconf magic, I just don't have the skills.
The other caveat is that Ben has already expressed opposition to this;
he wants --with-mule gone.
Kyle> I think using a name other than MULE for the new design will
Kyle> be an overall win. The MULE name has baggage associated
Kyle> with it that I think we want to be free of.
"Steve" would do except that it has the same semantic connotations as
"Mule". :-)
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
__________________________________________________________________________
__________________________________________________________________________
What are those two straight lines for? "Free software rules."
10:19 p.m.
New subject: Char-related crashes (hopefully) fixed
>>>> "Kyle" == Kyle Jones
<kyle_jones(a)wonderworks.com> writes:
Kyle> Stephen J. Turnbull writes:
> >>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)iskon.hr> writes:
>
Hrvoje> Mule breaks too much to be worthy of so much consideration
Hrvoje> at this level.
>
> I see it differently: Mule breaks too much to not get fixed. Mule
> breaks so much that it needs to be fixed by design, not by patching
> a few weak spots.
Kyle> I agree with this.
> The questions are what needs to be fixed and how, in what order.
Life
> would be a lot easier for Mule fixers if there were no int-char. You
> and Kyle are rightly objecting to that as a burden on the traditional
> (ASCII -> Latin-1) developer/user base. So I'm looking for a
> compromise. But because there are fundamental design problems in the
> current Mule, we need to think about the transition to a sensible
> design. That is going to break things; but if handled well the
> transition can be a minimal burden.
Kyle> Yes, we need a transition plan, but I don't think it necessarily
Kyle> needs to break things. Right now we have the --with-mule
Kyle> configuration option. We could leave MULE as it is and
Kyle> essentially abandon it. We add a new configure option,
Kyle> --with-i18n=MULE that gives access to the old MULE code for those
Kyle> who want it or have apps that need it. --with-i18n=NEWGOOP can
Kyle> build XEmacs with whatever the new design is. With this, we
Kyle> don't break MULE code or non-MULE code. Stuff only breaks if you
Kyle> build with --with-i18n=<something-other-than-no>, which is ideal
Kyle> since it continues to let us roll releases during development.
Kyle> I think using a name other than MULE for the new design will be
Kyle> an overall win. The MULE name has baggage associated with it
Kyle> that I think we want to be free of.
> One simple fix is to remove Mule.
Kyle> That is certainly not something I want to see.
Conceptually, it should be trivial to have a --with-mule build that
that acts in a Latin-1 way -- provide a function that makes sure that
only 'binary is used for all encoding/decoding operations. This way
there will be no unexpected surprises decoding tar.gz files or
whatever. This should probably be implemented using a language
environment. Maybe it should even be the default ???!!??
And in this case users could still explicitly edit, say, Latin-2 files
using
C-u C-x C-f foo RET iso-8859-2 RET
This is similar in spirit to FSF Emacs' --unibyte flag, but seems
cleaner. Ben?
(What will not work, however, is using the `font trick'
(i.e. specifying a Latin-2 font in a non-mule XEmacs) for editing
Latin-2 files. I suppose we could change the registry setting for all
one-byte charsets in this language environment so that all iso8859-*
fonts would be valid for latin-1 instead of just iso8859-1.
(get-charset 'latin-iso8859-1)
#<charset latin-iso8859-1 "Latin-1" "ISO8859-1 (Latin-1)"
"ISO8859-1 (Latin-1)" 96 l2r cols=1 g1 final='A' reg=iso8859-1
0x2ad>
I've added xemacs-mule to the CC list.
Martin
2:02 a.m.
New subject: Char-related crashes (hopefully) fixed
>>>> "mb" == Martin Buchholz
<martin(a)xemacs.org> writes:
mb> Conceptually, it should be trivial to have a --with-mule build
mb> that that acts in a Latin-1 way -- provide a function that
mb> makes sure that only 'binary is used for all encoding/decoding
mb> operations. This way there will be no unexpected surprises
mb> decoding tar.gz files or whatever. This should probably be
mb> implemented using a language environment. Maybe it should
mb> even be the default ???!!??
Welcome, Martin!
A lot of this was hashed over a couple of weeks ago (on a CC list), I
put forward a pretty detailed proposal which Ben reviewed. As soon as
I finish grading final exams I'll get back to that. You were on the
CC list, so you should have a copy; if not I can send you a digest of
the relevant discussion.
Olivier Galibert has a pretty detailed plan for dealing with the
`unibyte' issue. No naming problems, it will all be totally
automatic.
As for new architecture, Ben's pretty much signed off on that, as has
Steve. We can call it Mule or not; at a high level, it will have to
integrate with existing Mule APPs[1] for backward compatibility, but
internally we are substantially diverging from FSF already.
I think it's time for a clean break _if_ Ben and Olivier have the
resources to follow up on the plans they've already suggested. Ben at
least has a lot of other things in mind I know, but he seemed to put
pretty high priority on Mule when we were discussing it earlier.
Footnotes:
[1] Application Programming Practices. I will not dignify the
current mess with the name "interface".
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
__________________________________________________________________________
__________________________________________________________________________
What are those two straight lines for? "Free software rules."
12:18 p.m.
New subject: Char-related crashes (hopefully) fixed
Help!!!!!!!!!!!!!!
I step away for a week and suddenly there's a whole slew of messages proposing
all sorts of grand ideas for Mule, and lots of comments about Ben this and Ben
that ...
I'm gonna have to spend some time (tomorrow, perhaps) going through this mail
and figuring out what you guys are getting at. We also need some god-damned
ORGANIZATION here. This means we need a document that contains
-- all the concrete proposals that anyone has made, along with who made them.
the proposals listed here should be SHORT. If anyone has long proposals, put
an abstract here and the proposal itself down below.
-- a list of the major players.
-- the long proposals referenced above.
Perhaps I'll make something like this and put it on a website, so people can
look and suggest changes. (I am, after all, according to the official Job
list that I made up, the "meta-maintainer", and so it's probably my job
anyway
to do this organizing -- that is, until we get an official Secretary, who
doesn't fucking have any god-damned hand problems!)
ben
"Stephen J. Turnbull" wrote:
>>>>> "mb" == Martin Buchholz
<martin(a)xemacs.org> writes:
mb> Conceptually, it should be trivial to have a --with-mule build
mb> that that acts in a Latin-1 way -- provide a function that
mb> makes sure that only 'binary is used for all encoding/decoding
mb> operations. This way there will be no unexpected surprises
mb> decoding tar.gz files or whatever. This should probably be
mb> implemented using a language environment. Maybe it should
mb> even be the default ???!!??
Welcome, Martin!
A lot of this was hashed over a couple of weeks ago (on a CC list), I
put forward a pretty detailed proposal which Ben reviewed. As soon as
I finish grading final exams I'll get back to that. You were on the
CC list, so you should have a copy; if not I can send you a digest of
the relevant discussion.
Olivier Galibert has a pretty detailed plan for dealing with the
`unibyte' issue. No naming problems, it will all be totally
automatic.
As for new architecture, Ben's pretty much signed off on that, as has
Steve. We can call it Mule or not; at a high level, it will have to
integrate with existing Mule APPs[1] for backward compatibility, but
internally we are substantially diverging from FSF already.
I think it's time for a clean break _if_ Ben and Olivier have the
resources to follow up on the plans they've already suggested. Ben at
least has a lot of other things in mind I know, but he seemed to put
pretty high priority on Mule when we were discussing it earlier.
Footnotes:
[1] Application Programming Practices. I will not dignify the
current mess with the name "interface".
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
__________________________________________________________________________
__________________________________________________________________________
What are those two straight lines for? "Free software rules."
--
ben
--
In order to save my hands, I am cutting back on my responses, especially to
XEmacs-related mail. You
_will_ get a response, but please be patient. If you need an immediate
response and itÂ’s not apparent in
your message, please say so. Thanks for your understanding.
9126
days inactive
9130
days old
6 comments
5 participants
participants (5)
-
Ben Wing -
Hrvoje Niksic -
Kyle Jones -
Martin Buchholz -
Stephen J. Turnbull