Re: [Gimp-developer] Re: patch for gimp/po/fr.po
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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: patch for gimp/po/fr.po
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 list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: patch for gimp/po/fr.po
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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: patch for gimp/po/fr.po
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 version of The GIMP is under heavy development, it changes a lot and it is not intented to be used by anyone but developers working on it. It will crash, bring down your computer, wipe your harddisk and don't tell us later, we didn't tell you. For this reason it is a waste of time to keep translations uptodate. Instead translators should focus on updating and correcting the translations in the stable branch. The plan is to have a 1.2.3 release at some point with updated translations and help files plus probably a few bug-fixes. At some point (pretty soon now), I will merge the translations from the stable branch to HEAD so your updates won't get lost. If you update HEAD, but fail to update the stable branch, chances are your work will be lost. 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 strings. The number of warnings I see when trying to start unstable GIMP with LC_ALL=fr_FR makes me one more time believe that translators don't even try their translations before committing them or asking people to commit. It would be very nice if David could create a patch against the stable version since his updates look very good and I wouldn't like to loose this work. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: patch for gimp/po/fr.po
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 strings. Oups, I've forgotten to convert fr.po file to UTF-8. Sorry :-( But I'm not the one... The number of warnings I see when trying to start unstable GIMP with LC_ALL=fr_FR makes me one more time believe that translators don't even try their translations before committing them or asking people to commit. It's right, most of the time, I translate application without even trying to start the binary... I just check the validity of the file with : $ msgfmt -c --stat fr.po But this command doesn't detect bad charset encoding... Librement, -- Christophe Merlet (RedFox) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: patch for gimp/po/fr.po
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 GTK+-2.0 doesn't like to be passed invalid UTF-8 strings. Has this been reported as a bug in GTK? Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: patch for gimp/po/fr.po
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 start GIMP from CVS HEAD with LC_ALL != C since GTK+-2.0 doesn't like to be passed invalid UTF-8 strings. Has this been reported as a bug in GTK? Huh? It's not a bug, it's a feature. All strings in GTK+-2.0 are UTF-8 encoded and the application has to assure that only valid UTF-8 strings end up at the toolkit level. This is the only reasonable solution to the encoding mess and it works just perfect. It allows for example to have different languages with different native encodings in the same widget. Why do you consider this a bug? Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
UTF8 in GTK+ 2.0 (was Re: [Gimp-developer] Re: patch for gimp/po/fr.po)
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 and later ? How about other security considerations? Please don't reply with a cop out like The application has to handle this, that's equivalent to saying We needn't fix the bug because there's a known workaround. Conservative implementation is essential here for robustness AND security. Nick. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: patch for gimp/po/fr.po
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 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 region into the library and then unmap it some time later from another thread. Even if the library were checking (and I'm not sure how it could) that the pointer points to valid address space, there will be a time gap between the check and the use, and my unmapping can get in there. Having the library install its' own signal handler is not an acceptable solution, either. Stephen -- Stephen Norris[EMAIL PROTECTED] Farrow Norris Pty Ltd +61 417 243 239 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: patch for gimp/po/fr.po
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 feature. All strings in GTK+-2.0 are UTF-8 encoded and the application has to assure that only valid UTF-8 strings end up at the toolkit level. This is the only reasonable solution to the encoding mess and it works just perfect. It allows for example to have different languages with different native encodings in the same widget. Why do you consider this a bug? In my opinion, a library which crashes when fed inappropriate external data is buggy by definition. Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: patch for gimp/po/fr.po
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 :). Lourens ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: patch for gimp/po/fr.po
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) where it's impossible to tell until you get the SEGV. For instance, I memory map a file, pass a pointer into the mapped region into the library and then unmap it some time later from another thread. Even if the library were checking (and I'm not sure how it could) that the pointer points to valid address space, there will be a time gap between the check and the use, and my unmapping can get in there. Having the library install its' own signal handler is not an acceptable solution, either. Sounds like a fundamental problem with the UNIX environment design, then. Kelly It's a fundamental problem with having pointers. If you were restricted to some sort of object references that the OS controlled (something like MONADS had, or MULTICS sort of had) then you can avoid the problem. Otherwise, it's hard to fix. -- Stephen Norris[EMAIL PROTECTED] Farrow Norris Pty Ltd +61 417 243 239 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: patch for gimp/po/fr.po
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 region into the library and then unmap it some time later from another thread. Even if the library were checking (and I'm not sure how it could) that the pointer points to valid address space, there will be a time gap between the check and the use, and my unmapping can get in there. Having the library install its' own signal handler is not an acceptable solution, either. Well, call me stupid, but isn't that what mutexes are for? Thread 1 sets the mutex, then calls the library with a pointer to some part of the shared memory. Make sure thread 2 checks the mutex before unmapping and there's no problem at all. Thing is, how is the library going to know whether the pointer is valid or not? All the standard C functions that expect pointers will happily write wherever you point them to, even if it causes a segfault. I don't see how this is a problem with the library. If I divide by zero (which is essentially calling the divide function with illegal values) I get an exception as well. Lourens ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: patch for gimp/po/fr.po
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. For instance, I memory map a file, pass a pointer into the mapped region into the library and then unmap it some time later from another thread. Even if the library were checking (and I'm not sure how it could) that the pointer points to valid address space, there will be a time gap between the check and the use, and my unmapping can get in there. Having the library install its' own signal handler is not an acceptable solution, either. Well, call me stupid, but isn't that what mutexes are for? Thread 1 sets the mutex, then calls the library with a pointer to some part of the shared memory. Make sure thread 2 checks the mutex before unmapping and there's no problem at all. Thing is, how is the library going to know whether the pointer is valid or not? All the standard C functions that expect pointers will happily write wherever you point them to, even if it causes a segfault. I don't see how this is a problem with the library. If I divide by zero (which is essentially calling the divide function with illegal values) I get an exception as well. Lourens 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. Stephen -- Stephen Norris[EMAIL PROTECTED] Farrow Norris Pty Ltd +61 417 243 239 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
