Convuluted Gimp-Perl/Perl-Fu installation : Graphics

Hi there,

I've been trying to get the GIMP 2.0 Perl-scripting working (*).
Unfortunately, trying to install it (under Fedora Core 5) has been a
somewhat convuluted chain of attempted installation, failing, tracking
down dependent modules, trying to install *them*, failing, tracking
down more dependencies and then having *their* installation tests fail.

My rusty knowledge of Perl, how CPAN works and how to track down and
install modules isn't helping, but I can't help feeling that adding
"normal" functionality should be more straightforward.

Am I missing something obvious? I remember writing Gimp Perl scripts
before and I didn't have this trouble, but that was a few years back.

- triffid@oink.co.uk

(*) Yes, I'm aware that the GIMP also supports Scheme. I don't want to
use that because (a) Learning an obscure, weird and not-widely-used
language when Perl is available doesn't make any sense, and (b)
Erm..... okay, that's my only reason. I think it's good enough. :-)

triffid@oink.co.uk schrieb:

> Am I missing something obvious? I remember writing Gimp Perl scripts
> before and I didn't have this trouble, but that was a few years back.

Fedora Core 5 doesn't ship with Gimp-Perl, I assume?

But if they do (and maybe just the source package), is there something
like the build-dep parameter (which tries to get all of the
requirements to build from a particular source image) for apt available
in whatever package management tool you're using?


Michael

triffid@oink.co.uk wrote:
> Hi there,
>
> I've been trying to get the GIMP 2.0 Perl-scripting working (*).
> Unfortunately, trying to install it (under Fedora Core 5) has been a
> somewhat convuluted chain of attempted installation, failing, tracking
> down dependent modules, trying to install *them*, failing, tracking
> down more dependencies and then having *their* installation tests fail.
>
> My rusty knowledge of Perl, how CPAN works and how to track down and
> install modules isn't helping, but I can't help feeling that adding
> "normal" functionality should be more straightforward.
>
> Am I missing something obvious? I remember writing Gimp Perl scripts
> before and I didn't have this trouble, but that was a few years back.
>
> - triffid@oink.co.uk
>
> (*) Yes, I'm aware that the GIMP also supports Scheme. I don't want to
> use that because (a) Learning an obscure, weird and not-widely-used
> language when Perl is available doesn't make any sense, and (b)
> Erm..... okay, that's my only reason. I think it's good enough. :-)
>

Are you installing from rpms or source?

For rpms, a good idea is to use a high-level package installer. *sighs*
I've been away from rpm-based systems for too long, but I think there's
a Gnome rpm GUI and a KDE rpm GUI. The advantage with these is that the
gui should manage dependencies for you.

If, as when I was at Uni, you don't have an Internet connection at home
and have to "shuttle" the packages from another account to your home
machine, the following options to rpm will let you know beforehand, what
each package requires to install.

rpm -p <package-file> --requires

(The -p option will query an uninstalled file, the --requires option
will tell you what the package requires.)

rpm -qa | grep <packagename>

, is a slow, but effective way of looking for installed packages by
name, without leaving the command line. This can be more beneficial than
the rpm option to query installed, as it will let you search for partial
names. E.g. on Mandrake, the rpm install query couldn't find the
libpython package, because it was called libpython2.2a or something. The
grep one-liner found it and the development package.

If you are trying to install the "latest-and-greatest" packages, e.g.
from an unofficial repository, or a development version of RedHat, you
might be better off grabbing the source rpms (.srpm) and rebuilding for
your system. This tends to work with packages at the "top" of the
dependency tree - i.e. the final applications, rather than the
supporting libraries. Going too deep with updating support libraries is
a quick way to #%^!* your entire system. I learnt this, and also not to
rm -rf * while root in / or /usr the hard way.

If you have difficulty with the build dependencies (I.e. the build
system tells you that you require a higher version than what is on your
machine), you can "install" the source rpm, which will drop the source
and build files into /usr/src/RPMS or /usr/src/redhat. Hunt down the
spec file and edit the build and install dependencies. (There's a
document called Max RPM on the internet which will tell you all about
it.) Then there's a series of build options rpm will accept, that will
result in a .rpm file in /usr/src/RPMS/RPM/ix86.

Most of the rpm developers seem to just list the development files they
have on their machine when they write up the spec files, rather than
actually find out if the packages can be build with older libraries.
Most of the time, editing the spec file to match the versions of
installed libraries will still result in a clean build.

Finally, there's the option of building from source tars and installing
in /usr/local. Most of the time, this is the easier approach. When I was
on RedHat/Mandrake, the most valuable thing I learnt was that you don't
HAVE to jam everything into the package system. For some things, it's
more effort than it's worth.

Of course, the debian package manager includes a whole passel of tools
to "massage" installed packages. *grins*

"I want this old version shifted here, and this suffix pinned on the
end, so I can install this new version, but I want the package manager
to know where the old version files are." Or: "A package calls this
library libfoo.so.1.1235 and this other application needs it to be
called libfoo.so - I'll use the debtools to create a 'managed' symbolic
link rather than having a potential dead link floating around if I
uninstall the library package." Cool stuff. Then there's alien. tar.gz
<-> deb <-> rpm. You lose the dependency information though.

Hope that helps?

Joal Heagney

Joal Heagney wrote:
> Are you installing from rpms or source?

Source. Problem was that my knowledge of Perl is a bit rusty, the info
I needed (re: gimp-perl) seemed to be scattered all over the place, and
I didn't think there was an up-to-date RPM.

> For rpms, a good idea is to use a high-level package installer.

Having read this, I took a look at Fedora's Add/Remove software
program, figured out what might- or might not- be needed, and added and
removed stuff that way. It did work (eventually) without too much
hassle.

However, I've realised that- in addition to my ropey Perl knowledge-
Perl/Script-Fu isn't designed with pixel-by-pixel access in mind.

(If there's a better way to properly manipulate the colour of
individual pixels other than get_pixel() and set_pixel(), I couldn't
see it. My routines using them were *very* slow, and research indicates
that this is a problem with the methods themselves- at least under
Script-Fu. The performance I got was unacceptable for manipulating
large photographs as intended.)

My conclusion? I'm looking at the C interface now instead; it actually
looks a lot simpler (for me, anyway).

The RPM info you posted below was actually quite useful; although I
didn't need it this time, it was a nice summary of stuff I *have*
wanted to know at times in the past, and doubtless will in the future,
so I'm bookmarking it. :-)

Thanks,

- triffid@oink.co.uk

Michael Schumacher wrote:
> triffid@oink.co.uk schrieb:
>
> > Am I missing something obvious? I remember writing Gimp Perl scripts
> > before and I didn't have this trouble, but that was a few years back.
>
> Fedora Core 5 doesn't ship with Gimp-Perl, I assume?

I don't know if they shipped with the original distro or got added to
the Add/Updated Programs list later (I'm not too sure how that works,
so...), but it was available as an "Add Programs" option.

I do know that it didn't ship with one of the Fedora versions; I can't
remember which right at this moment.


> But if they do (and maybe just the source package), is there something
> like the build-dep parameter (which tries to get all of the
> requirements to build from a particular source image) for apt available
> in whatever package management tool you're using?

I wasn't originally using packages (for reasons explained in my other
reply); I tried it that way the second time, and it worked.

However, I did eventually get it installed. Thanks for your help!

- triffid@oink.co.uk

triffid@oink.co.uk wrote:

> However, I've realised that- in addition to my ropey Perl knowledge-
> Perl/Script-Fu isn't designed with pixel-by-pixel access in mind.
>
> (If there's a better way to properly manipulate the colour of
> individual pixels other than get_pixel() and set_pixel(), I couldn't
> see it. My routines using them were *very* slow, and research indicates
> that this is a problem with the methods themselves- at least under
> Script-Fu. The performance I got was unacceptable for manipulating
> large photographs as intended.)
>
> My conclusion? I'm looking at the C interface now instead; it actually
> looks a lot simpler (for me, anyway).

There's also the gimp-python interface (built automatically from gimp
source if python-dev packages are installed) - that might have something
better.
Out of curiosity, could you describe what you're doing with Gimp? If
it's maths-based patterns, there are some prebuilt plugins that allow
you to plot these.

> The RPM info you posted below was actually quite useful; although I
> didn't need it this time, it was a nice summary of stuff I *have*
> wanted to know at times in the past, and doubtless will in the future,
> so I'm bookmarking it. :-)

Aw gee. *blushes* The rpm -qa | grep trick was the most useful I found.

> Thanks,
>
> - triffid@oink.co.uk
>

Good luck with your project,

Joal Heagney

Joal Heagney wrote:
> There's also the gimp-python interface (built automatically from gimp
> source if python-dev packages are installed) - that might have something
> better.

Lo siento, no hablo Python.

> Out of curiosity, could you describe what you're doing with Gimp? If
> it's maths-based patterns, there are some prebuilt plugins that allow
> you to plot these.

Messing around with improving out-of-focus and motion-blurred images.
Nothing serious, I just had some ideas I wanted to try out. One of
them- using a two-dimensional unsharp mask in the direction of the
motion blur- seemed to work quite well with one image.

Unfortunately, I got rid of all my lousy blurred photos a while back
:-/

> Good luck with your project,

Thanks,

- triffid