Re: gimp 1.1.18

2000-04-04 Thread Garry R. Osgood

Tim Mooney wrote:

> In regard to: Re: gimp 1.1.18, Garry R. Osgood said (at 9:16pm on Mar 24, 2000):
>
> >[EMAIL PROTECTED] wrote:
> >
> >> 
> >
> >> - on alpha-dec-osf4.0d, the program give all errors when loading
> >>   plugins even though plugin does not crash::
> >>
> >>  $  /usr/local/bin/gimp
> >>
> >> ** WARNING **: wire_read: error

> 

> I've seen this at various times on all the alpha-dec-osf boxes I'ved tried
> compiling gimp on -- I think I may have been the first person to report it
> to the developer list.  At various times I've thought the problem had been
> fixed by some change in the gimp, but I just tried 1.1.19 on a 5.0 box with
> patch set #1 last weekend, and the same thing happened.  I have a 4.0f box
> that the problem doesn't happen for though.
>
> As I mentioned when I first reported this problem, it turns out that if you
> run the gimp under `trace' (just like truss) the first time you run the gimp,
> most of the plug-ins are queried successfully and work as expected thereafter.
> At that point, you can run gimp without tracing it, and the plugins work fine.
> It's only the first time through that this happens.



We're definitely going to need help from people with DEC-osf boxes;
between you and Philippe, you've shot my favorite theory down - that
it was a peculiarity of the 4.0F compiler - and I have SGI here, and don't
see it, and most active developers have various flavors of Linux or Solaris
and they don't see it.

It's a fairly well understood truth that the out-of-box gimp actually
starts up the plug-in to invoke its query() function on run-up, but afterwards
a "mature" gimp reads up on plugins from a resource file. So if the resource
file gets built the first time, the problem won't occur subsequently  - until
a new plug-in gets installed.

This leads to two ponder points:

1) the execution pathways on the gimp and plug-in side of the wire that
are unique to query don't get exercised much - nice place for bugs to persist.

2) When an out-of-box gimp is querying all of those plug-ins, a whole lot
of forking is going on - the OS is replicating the Gimp image into a new
process, then overlaying that image with the plug-in executable. Not a
trivial exercise. And it is happening RAT-TAT-TAT-TAT.  Methinks
when you started tracing Gimp, you reduce an undiagnosed timing constraint
on sending messages between processes and the problem goes away. If fork
   timing is an issue, then the isolated and relatively infrequent forks of plug-ins
   likely do not trigger the mis-reading of messages on the wire and they behave
   just fine.

If 2), then nothing bad is likely to be observed when single-stepping through
processes on both sides of the wire - near quiescent conditions - so a debugger
will likely not explicitly show anything. So one is led to ponder the architecture-
particular latencies that occur when a parent is forking off children in fairly
short order.

I'll give the aforementioned execution pathways a careful look this weekend,
and if something interesting suggests itself, I'll send -off-list mail to Tim
and other victims of #2742. Anyone with a DEC out there that wants to play in
this sandbox, come on in.

Be good, be well

Garry






Re: gimp 1.1.18

2000-04-04 Thread Tim Mooney

In regard to: Re: gimp 1.1.18, Garry R. Osgood said (at 9:16pm on Mar 24, 2000):

>[EMAIL PROTECTED] wrote:
>
>> 
>
>> - on alpha-dec-osf4.0d, the program give all errors when loading
>>   plugins even though plugin does not crash::
>>
>>  $  /usr/local/bin/gimp
>>
>> ** WARNING **: wire_read: error
>>
>> ** WARNING **: wire_read: error
>>
>> ** WARNING **: wire_read: error
>>
>> ** WARNING **: wire_read: error
>>
>> 
>>
>> $ /usr/local/lib/gimp/1.1/plug-ins/align_layers
>> /usr/local/lib/gimp/1.1/plug-ins/align_layers is a gimp plug-in and must be run by 
>the gimp to be used
>
>This appears to be a curious manifestation of #2742, which has been pestering
>DEC Alpha people since October (see http://bugs.gnome.org/db/27/2742.html)
>What makes this curious and troublesome was that people seemed to be having
>trouble with compiler version 4.0.F, and reverting to 4.0.D was the workaround.
>You appear to be having trouble with 4.0.D.
>
>One individual upgraded to 5.0 and reported a clean compile.

I've seen this at various times on all the alpha-dec-osf boxes I'ved tried
compiling gimp on -- I think I may have been the first person to report it
to the developer list.  At various times I've thought the problem had been
fixed by some change in the gimp, but I just tried 1.1.19 on a 5.0 box with
patch set #1 last weekend, and the same thing happened.  I have a 4.0f box
that the problem doesn't happen for though.

As I mentioned when I first reported this problem, it turns out that if you
run the gimp under `trace' (just like truss) the first time you run the gimp,
most of the plug-ins are queried successfully and work as expected thereafter.
At that point, you can run gimp without tracing it, and the plugins work fine.
It's only the first time through that this happens.

It's definitely an odd problem.  If anyone has any suggestions for how to
debug it, please let me know.   I would be willing to help.

Tim
-- 
Tim Mooney  [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J1, IACC Building  (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164




Re: gimp 1.1.18

2000-03-26 Thread Marc Lehmann

On Fri, Mar 24, 2000 at 06:28:37PM +0100, [EMAIL PROTECTED] wrote:
>  :*:./update.sh: ./pxgettext: not found

The cvs version should do that better already. It would be ultra-cool ;)
if you could check wether it really works in 1.1.19!

Thanks for testing ;)

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: gimp 1.1.18

2000-03-24 Thread Garry R. Osgood

[EMAIL PROTECTED] wrote:

> 

> - on alpha-dec-osf4.0d, the program give all errors when loading
>   plugins even though plugin does not crash::
>
>  $  /usr/local/bin/gimp
>
> ** WARNING **: wire_read: error
>
> ** WARNING **: wire_read: error
>
> ** WARNING **: wire_read: error
>
> ** WARNING **: wire_read: error
>
> 
>
> $ /usr/local/lib/gimp/1.1/plug-ins/align_layers
> /usr/local/lib/gimp/1.1/plug-ins/align_layers is a gimp plug-in and must be run by 
>the gimp to be used

This appears to be a curious manifestation of #2742, which has been pestering
DEC Alpha people since October (see http://bugs.gnome.org/db/27/2742.html)
What makes this curious and troublesome was that people seemed to be having
trouble with compiler version 4.0.F, and reverting to 4.0.D was the workaround.
You appear to be having trouble with 4.0.D.

One individual upgraded to 5.0 and reported a clean compile.

Be good, be well.

Garry Osgood





gimp 1.1.18

2000-03-24 Thread Philippe . Defert


Package: gimp
Version: 1.1.18

I have generated succesfully with egcs 1.1.2 on the following
platforms:

i686-pc-linux-gnu (Redhat 5.1)
i686-pc-linux-gnu (Redhat 6.0)
i686-pc-linux-gnu (Redhat 6.1)
sparc-sun-solaris2.6
alpha-dec-osf4.0d
hppa1.1-hp-hpux10.20
mips-sgi-irix6.5
powerpc-ibm-aix4.3.2.0

BUT:

- on all platforms, except Linux the generation stops at:

 : :gmake[4]: Entering directory `/scratch/happi/GNU.DESK/gimp-1.1.18/plug-ins/perl/po'
 : :mkdir ../blib/arch/auto/i18n
 : :mkdir translation
 : :mkdir tables
 : :mkdir ../blib/lib/auto/i18n
 : :./update.sh
 :*:./update.sh: ./pxgettext: not found
 :*:gmake[4]: *** [update-pot] Error 1
 : :gmake[4]: Leaving directory `/scratch/happi/GNU.DESK/gimp-1.1.18/plug-ins/perl/po'
 :*:gmake[3]: *** [subdirs] Error 2
 : :gmake[3]: Leaving directory `/scratch/happi/GNU.DESK/gimp-1.1.18/plug-ins/perl'
 :*:gmake[2]: *** [all-recursive] Error 1
 : :gmake[2]: Leaving directory `/scratch/happi/GNU.DESK/gimp-1.1.18/plug-ins'
 :*:gmake[1]: *** [all-recursive] Error 1
 : :gmake[1]: Leaving directory `/scratch/happi/GNU.DESK/gimp-1.1.18'
 :*:gmake: *** [all-recursive-am] Error 2

  Solution: Change the first line of pxgettext from #!/usr/bin/perl to
  #!/usr/local/bin/perl. This should be done by configure or change
  the Makefile to do "perl ./pxgettext" instead.

- on all platforms, except Linux the generation stops at some point as
  -lintl is not put in the link command appropriately (probably a
  configure problem).

  Solution: do make LIBS=-lintl

- on alpha-dec-osf4.0d, the program give all errors when loading
  plugins even though plugin does not crash::

 $  /usr/local/bin/gimp

** WARNING **: wire_read: error

** WARNING **: wire_read: error

** WARNING **: wire_read: error

** WARNING **: wire_read: error



$ /usr/local/lib/gimp/1.1/plug-ins/align_layers 
/usr/local/lib/gimp/1.1/plug-ins/align_layers is a gimp plug-in and must be run by the 
gimp to be used

  What did I do wrong.

- on hppa1.1-hp-hpux10.20, the program starts but never displays much...

Amicalement.
Philippe.



ANNOUNCE: GIMP 1.1.18

2000-03-04 Thread Manish Singh

GIMP 1.1.18 is out there:

ftp://ftp.gimp.org/pub/gimp/unstable/v1.1.18/

The usual fun amount of bugfixes is there.. see ChangeLog for details.

-Yosh