[Openmcl-devel] *default-character-encoding* should be :utf-8

[Gary Byers]

The values of *TERMINAL-CHARACTER-ENCODING-NAME* and *DEFAULT-FILE-CHARACTER-ENCODING*
changed (experimentally) in the trunk in r15236, largely as an attempt to silence
an apparently endless discussion started in:

<http://clozure.com/pipermail/openmcl-devel/2012-March/013401.html>

Both of those variables have historically been initialized to NIL (which
is equivalent to :ISO-8859-1.)

A careful reading of that thread will reveal that if you have files that
aren't encoded in :UTF-8 that's because of sloth, avarice, or some other
personal failing on your part (and would have nothing to do with real-world
issues.)

That change was intentionally not incorporated into 1.8; all other things
being equal, I think that I'd prefer that 1.9 revert back to using NIL/:ISO-8859-1
(but that might cause that discussion to start up again.)

In the bigger picture: as I understand how things currently stand, the trunk
contains workarounds for a couple of Mountain Lion issues (the mechanism used
by things like GUI:EXECUTE-IN-GUI and the problems with #_mach_port_allocate_name)
that have not yet been propagated to 1.8.  Assuming that the fixes/workarounds
are correct and have been smoke-tested to at least some degree, the changes
do need to be incorporated into 1.8 ASAP, and once they are I would think that
you'd want to base your application on 1.8.

I'm a little nervous about the hashing scheme that's being used to avoid
#_mach_port_allocate_name (I don't know how well it scales and don't know
whether or not there are non-obvious race conditions or other thread-safety
issues in the code) and I'd ordinarily be a little reluctant to push something
like that to the release: the consequences of using #_mach_port_allocate_name
are so horrible on Mountain Lion that the hashing scheme is clearly better (even
if it contains its own obscure/subtle problems); on OS releases where
#_mach_port_allocate_name still works, then propagating the change simply risks
introducing some obscure/subtle problems.

I'll try to decide what to do soon, but I don't think that it'd be a good idea
for you (or anyone) to base a shipping application on the CCL trunk, simply
because the trunk's volatility would make it harder for you or us to maintain.


On Sat, 22 Sep 2012, Alexander Repenning wrote:

> tracked down some bugs that are due to the new :utf-8 encoding. When actually did that happen? Anyway, is there a way to set the encoding back (:ascii)? The only *default-character-encoding* variable I can find is part of quicklisp/babel/encodings.
>
> Alex
>
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>