Hi
!
I'd like to
get some surface from a picture through perl script let say
some
gimp_get_surface(x1,y1,x2,y2) which could output some matrix -> PDL
structure.
Does such method has
been implemented yet ?
Regards,
Fabian
On Thu, May 11, 2000 at 09:05:58PM +0200, Michael Natterer <[EMAIL PROTECTED]>
wrote:
> > The libgimp code could try to set the signal handler to SIG_DFL before
> > executing the code of the plug-in.
>
> We don't need to do this, as (exec()'ed) children can't inherit handlers
> from their parent
On Thu, May 11, 2000 at 08:33:54PM +0200, Michael Natterer <[EMAIL PROTECTED]>
wrote:
> But we don't do bad things in the SIGCHLD handler anyway
> (no need for sharing data with the app) and in the fatal handler, we just
> quit the app.
"I'll put all my trust in you" ;)
> > > The reason to igno
On Thu, May 11, 2000 at 08:54:44PM +0200, Michael Natterer <[EMAIL PROTECTED]>
wrote:
> > Yes... I wrote a few months ago that I would change that and implement
> > some kind of --enable-stack-trace option, but I never took the time to
> > do it.
>
> Now it's there :) We just have to convert th
(Sorry, I received mitch's mail befoee this one!)
On Thu, May 11, 2000 at 07:23:48PM +0200, Raphael Quinet <[EMAIL PROTECTED]> wrote:
> Hmmm... In the last discussion, I said that I would implement a
> compile-time and a run-time option for choosing this, because some
> people (including myself)
On Thu, May 11, 2000 at 06:48:17PM +0200, Raphael Quinet <[EMAIL PROTECTED]> wrote:
> Note that being MT safe is not enough. For the 4 signals that are
> listed above, you can usually expect that your memory is already
> corrupted. So if you want to minimize the risks of crashing
If it's import
I know that this is really cheezy and it's not for me
but, for many many many photoshop users out there
looking to switch over to Gimp.
The new gimpfreetype dir in CVS is quite interesting.
The todo mentions wanting to do editable text layers
along the lines of the dynamic text plugin (Which is
In regard to: Re: EPIPE, Michael Natterer said (at 9:05pm on May 11, 2000):
>> Another solution is to save and re-install the old signal handler. We
>> may even want to support some kind of chain of signal handers: the new
>> signal handlers installed by the Gimp should call the ones that were
>
Raphael Quinet wrote:
>
> On Thu, 11 May 2000, Marc Lehmann <[EMAIL PROTECTED]> wrote:
> [...]
> > What could be the case, however, is, that gimp itself does not reset it's
> > signal handlers when it execs the plug-ins. If this is the case, then this
> > bug (not restoring signal handlers to the
Raphael Quinet wrote:
>
> On Thu, 11 May 2000, Michael Natterer <[EMAIL PROTECTED]> wrote:
> >
> > This is what currently happens (ok, it happens in the handler, but WNOHANG
> > *should* be absolutely safe).
>
> No, actually it is not safe on all operating systems: as I wrote
> elsewhere, you ca
Marc Lehmann wrote:
>
> On Thu, May 11, 2000 at 12:47:22PM +0200, Michael Natterer
><[EMAIL PROTECTED]> wrote:
> > > The only type that is atomic is sig_atomic_t. Everything else is not atomic
> > > one at least one target where gimp runs. Limiting gimp to gnu-libc-platforms
> > > looks very bad
On Thu, 11 May 2000, Marc Lehmann <[EMAIL PROTECTED]> wrote:
[...]
> What could be the case, however, is, that gimp itself does not reset it's
> signal handlers when it execs the plug-ins. If this is the case, then this
> bug (not restoring signal handlers to their default) might cause many other
On Thu, May 11, 2000 at 12:47:22PM +0200, Michael Natterer <[EMAIL PROTECTED]>
wrote:
> > The only type that is atomic is sig_atomic_t. Everything else is not atomic
> > one at least one target where gimp runs. Limiting gimp to gnu-libc-platforms
> > looks very bad.
>
> See my other mail. I mean
On Thu, 11 May 2000, Michael Natterer <[EMAIL PROTECTED]> wrote:
> Raphael Quinet wrote:
[...]
> > - SIGCHLD or SIGCLD: a child process died. This signal can be
> > delivered at any time. Some systems do not provide a reliable way
> > to know how many processes exited (if they do not support
Marc Lehmann wrote:
>
> >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
Tim Mooney wrote:
>
> 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
> >a
16 matches
Mail list logo
