On 02 Oct 2001 16:44:18 -0500, Federico Mena Quintero [EMAIL PROTECTED] said:
It is physically impossible to synchronize clocks.
Sounds like a fundamental problem with the design of the universe.
Indeed. We should return the universe for a refund.
Kelly
David Odin wrote:
Hi,
You'll find a patch for the gimp/po/fr.po file attached to this mail. I
hope this is the right list for this.
Thanks,
I'll commit your patch.
Librement,
--
Christophe Merlet (RedFox)
___
Gimp-developer mailing
Hi,
Christophe Merlet [EMAIL PROTECTED] writes:
You'll find a patch for the gimp/po/fr.po file attached to this mail. I
hope this is the right list for this.
Thanks,
I'll commit your patch.
feel free to commit, but please commit to the stable branch (gimp-1-2).
Salut, Sven
Hi,
Christophe Merlet [EMAIL PROTECTED] writes:
This was a patch against the HEAD branch of gimp... then I've commited
to the HEAD branch...
fine. I just want to take the opportunity to explain once again how we
treat translations at the moment and why we do it this way.
The CVS HEAD
Sven Neumann wrote:
One more thing to consider: Localisation in GIMP HEAD is considerably
broken since we have to switch all the po files to UTF-8. You can create
some nice crashes if you try to start GIMP from CVS HEAD with LC_ALL != C
since GTK+-2.0 doesn't like to be passed invalid UTF-8
On 29 Aug 2001 10:59:06 +0200, Sven Neumann [EMAIL PROTECTED] said:
One more thing to consider: Localisation in GIMP HEAD is considerably
broken since we have to switch all the po files to UTF-8. You can
create some nice crashes if you try to start GIMP from CVS HEAD with
LC_ALL != C since
Hi,
Kelly Martin [EMAIL PROTECTED] writes:
On 29 Aug 2001 10:59:06 +0200, Sven Neumann [EMAIL PROTECTED] said:
One more thing to consider: Localisation in GIMP HEAD is considerably
broken since we have to switch all the po files to UTF-8. You can
create some nice crashes if you try to
On Wed, Aug 29, 2001 at 07:58:52AM -0500, Kelly Martin wrote:
In my opinion, a library which crashes when fed inappropriate external
data is buggy by definition.
Let's be more specific:
Does the GTK+ UTF8 implementation meet the requirements for security
purposes laid down in Unicode 3.0.1
On Wed, Aug 29, 2001 at 09:38:45PM -0500, Kelly Martin wrote:
On Thu, 30 Aug 2001 10:05:15 +1000, Stephen Robert Norris [EMAIL PROTECTED] said:
So it's the library's fault if I pass it a bad pointer and it causes
a SEGV?
Yes.
Kelly
I'd be interested to know how to avoid that. I'm
Ah so it is the libraries fault that it crashes when you pass it an
unterminated string? Cool.
--Larry
On Wed, 2001-08-29 at 07:58, Kelly Martin wrote:
On 29 Aug 2001 14:44:49 +0200, Sven Neumann [EMAIL PROTECTED] said:
Has this been reported as a bug in GTK?
Huh? It's not a bug, it's a
Stephen Robert Norris wrote:
Yes, this is a way the application can avoid the problem; it's not a way
the library can.
My point was that it's impossible with modern OS's to avoid the possibility
of the library crashing.
Ah, we agree then, that was the point I was trying to make as well
On Wed, Aug 29, 2001 at 11:22:26PM -0500, Kelly Martin wrote:
On Thu, 30 Aug 2001 13:42:05 +1000, Stephen Robert Norris [EMAIL PROTECTED] said:
I'd be interested to know how to avoid that. I'm pretty sure I can
construct a scenario (with multiple threads and memory mapping, for
example)
Stephen Robert Norris wrote:
I'd be interested to know how to avoid that. I'm pretty sure I can
construct a scenario (with multiple threads and memory mapping,
for example) where it's impossible to tell until you get the SEGV. For
instance, I memory map a file, pass a pointer into the mapped
On Thu, Aug 30, 2001 at 07:34:57AM +0200, Lourens Veen wrote:
Stephen Robert Norris wrote:
I'd be interested to know how to avoid that. I'm pretty sure I can
construct a scenario (with multiple threads and memory mapping,
for example) where it's impossible to tell until you get the SEGV.
14 matches
Mail list logo
