GLib 2.24.0 released

2010-03-27 Thread Matthias Clasen
GLib 2.24.0 is now available for download at: ftp://ftp.gtk.org/pub/glib/2.24 http://download.gnome.org/sources/glib/2.24 sha256 sums: 7b6aa2cf21e734a6092a711bf196b8d2ddc589b971f93337610c10fa4f23400d glib-2.24.0.tar.bz2 579a668cef12e1db63ee15bbaccc2c9067aee095d85a5eafe4b9d8d4499febfc glib-2.24.

Re: Faster UTF-8 decoding in GLib

2010-03-27 Thread Daniel Elstner
Hi, Am Samstag, den 27.03.2010, 18:04 -0400 schrieb Behdad Esfahbod: > Sure, I wasn't referring to valid data. In valid UTF-8, there is no 5byte or > 6byte sequences either. True, but that was a post-hoc restriction imposed afterwards, when Unicode was redefined as a 21-bit character set, presu

Re: Faster UTF-8 decoding in GLib

2010-03-27 Thread Behdad Esfahbod
On 03/27/2010 05:49 PM, Daniel Elstner wrote: > Hi, > > Am Samstag, den 27.03.2010, 17:40 -0400 schrieb Behdad Esfahbod: >> On 03/27/2010 05:21 PM, Daniel Elstner wrote: >>> Well, I assume that ints are at least 32 bit wide on any platform >>> supported by GLib. But if you meant to say that it wo

Re: Faster UTF-8 decoding in GLib

2010-03-27 Thread Daniel Elstner
Hi, Am Samstag, den 27.03.2010, 17:40 -0400 schrieb Behdad Esfahbod: > On 03/27/2010 05:21 PM, Daniel Elstner wrote: > > Well, I assume that ints are at least 32 bit wide on any platform > > supported by GLib. But if you meant to say that it would break with > > larger ints, I don't see why. As

Re: Faster UTF-8 decoding in GLib

2010-03-27 Thread Behdad Esfahbod
On 03/27/2010 05:21 PM, Daniel Elstner wrote: > Well, I assume that ints are at least 32 bit wide on any platform > supported by GLib. But if you meant to say that it would break with > larger ints, I don't see why. As long as the type is unsigned, it > should be fine. If the utf8 byte has more

Re: Faster UTF-8 decoding in GLib

2010-03-27 Thread Daniel Elstner
Hi, Am Samstag, den 27.03.2010, 16:51 -0400 schrieb Behdad Esfahbod: > On 03/27/2010 04:27 PM, Daniel Elstner wrote: > > > > It is not meant to check for errors. > > Good point. > > > I think it is totally arbitrary to handle some potential errors but not > > others. And I think the current imp

Re: Faster UTF-8 decoding in GLib

2010-03-27 Thread Behdad Esfahbod
On 03/27/2010 04:27 PM, Daniel Elstner wrote: > Hi, > > Am Samstag, den 27.03.2010, 16:12 -0400 schrieb Behdad Esfahbod: > >> Err, you're right. My bad. It's still broken though since it doesn't check >> that the fragment bytes all start with the bits 10. Missing error checking. Looking at: h

Re: Faster UTF-8 decoding in GLib

2010-03-27 Thread Daniel Elstner
Hi, Am Samstag, den 27.03.2010, 16:12 -0400 schrieb Behdad Esfahbod: > Err, you're right. My bad. It's still broken though since it doesn't check > that the fragment bytes all start with the bits 10. Missing error checking. It is not meant to check for errors. I think it is totally arbitrary

Re: Faster UTF-8 decoding in GLib

2010-03-27 Thread Behdad Esfahbod
On 03/26/2010 05:43 PM, Daniel Elstner wrote: > Hi Behdad, > > Am Freitag, den 26.03.2010, 13:25 -0400 schrieb Behdad Esfahbod: > >> * The construct borrowed from glibmm, as beautiful as it is, is WRONG for >> 6-byte-long UTF-8. It just doesn't work. We historically support those >> sequenc

Re: glib's role in the units policy game

2010-03-27 Thread Owen Taylor
On Sat, 2010-03-27 at 02:44 +0100, Benjamin Drung wrote: > Hi, > > I am sending this mail to gtk-devel list to catch as many ideas and > opinions as possible, if you not already following bug #554172 [1]. > > Ubuntu has now a units policy [2] and I want to implement it, but I am > still not sure