In regard to: Re: EPIPE, Nick Lamb said (at 2:57am on May 11, 2000):
On Wed, May 10, 2000 at 07:15:57PM -0500, Tim Mooney wrote:
Finding a processor/OS combo where sizeof(pointer) != sizeof(int) is pretty
easy, however. How does this change your thinking?
Wouldn't atomicity guarantees be a
However, a signal handler can do whatever it likes with the app's structures
as long as it uses atomic data access (which can be a pointer, as pointers
have the same size as integers, which are atomic. This is true at least on
all processors which have a GNU libc port and finding a processor
On Wed, 10 May 2000, Michael Natterer [EMAIL PROTECTED] wrote:
Michael Natterer wrote:
Austin Donnelly wrote:
[ two mails i totally agree with ]
I'm about to commit some code which should bring the signal
stuff into a sane state. The ChangeLog entry is quite verbose
and
Date: Wed, 10 May 2000 19:15:57 -0500 (CDT)
From: Tim Mooney [EMAIL PROTECTED]
cc: Raphael Quinet [EMAIL PROTECTED], [EMAIL PROTECTED]
In regard to: Re: EPIPE, Michael Natterer said (at 12:40am on May 11, 2000):
This is what currently happens (ok, it happens in the handler, but
Raphael Quinet wrote:
- does this happen with the dynamic text tool?
Dynamic Text seems to have problems with incomplete locale
environments (like setting LC_MESSAGES only).
The setting that makes it work for me is
export LC_ALL=DE_de
Maybe this is the problem?
bye,
--Mitch
Sven Neumann [EMAIL PROTECTED] said:
Hi,
having only used canned tools (like the ones in
photoshop and that come with graphics drivers) i made
a script to help calibrate monitors. im trying to
gather info on color matching to make a free
implementation of ICC profiles. i already
having only used canned tools (like the ones in
photoshop and that come with graphics drivers) i made
a script to help calibrate monitors. im trying to
gather info on color matching to make a free
implementation of ICC profiles. i already got the c
code for reading/writing profiles from color.org
In regard to: Re: EPIPE, Michael Natterer said (at 12:40am on May 11, 2000):
This is what currently happens (ok, it happens in the handler, but WNOHANG
*should* be absolutely safe).
However, a signal handler can do whatever it likes with the app's structures
as long as it uses atomic data access
I'm trying to get Gimp 1.1.21 to work correctly on Solaris 7
I've compiled the code fine this morning, and apart from the Error below it runs
fine:
gimp: shmat failed...disabling shared memory tile transport
The Problem is that, anytime I click on the text button, then
type in some text,
Hi,
having only used canned tools (like the ones in
photoshop and that come with graphics drivers) i made
a script to help calibrate monitors. im trying to
gather info on color matching to make a free
implementation of ICC profiles. i already got the c
code for reading/writing profiles
On Wed, 10 May 2000, Anton Enright [EMAIL PROTECTED] wrote:
I'm trying to get Gimp 1.1.21 to work correctly on Solaris 7
I've compiled the code fine this morning, and apart from the Error below
it runs fine:
gimp: shmat failed...disabling shared memory tile transport
This is very common
On Wed, May 10, 2000 at 07:15:57PM -0500, Tim Mooney wrote:
Finding a processor/OS combo where sizeof(pointer) != sizeof(int) is pretty
easy, however. How does this change your thinking?
Wouldn't atomicity guarantees be a processor feature, and hence tied
to word size (probably pointer width
12 matches
Mail list logo
