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

[Alexander Repenning]

On Sep 23, 2012, at 1:49 PM, Gary Byers wrote:

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

Yes, I certainly do not want to contribute to some kind of tedious, ongoing philosophical discussion. My point is of a more pragmatic nature. I am simply reporting that (defvar *default-file-character-encoding* :utf-8) does break a lot of legacy code. Of course that code could be fixed but making :utf-8 the default appears a bit too aggressive. 



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

Sounds like a good idea. As is, CCL 1.8 in Mac App store is a likely to cause substantial trouble with Mountain Lion. 
> 
> 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.

Modulo the need for further debugging and synchronization I think a hash based approach does sound more promising in general. Mountain Lions more "advanced" address space layout randomization including now the relocation of zones at boot time may have contributed to this naming scheme problem turning the creation of threads into some kind of Russian roulette. The new scheme is more flexible and completely avoids the need the 32 bit gamble.

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

Good point. Do you have a rough ETA?

Alex

> 

Prof. Alexander Repenning

University of Colorado
Computer Science Department
Boulder, CO 80309-430

vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf