Ann: Generic Image Decoder v.01

10 views
Skip to first unread message

Gautier write-only

unread,
Jun 26, 2010, 5:49:20 AM6/26/10
to
Hello,
I have the pleasure to announce the first release of the Generic Image
Decoder.

The Generic Image Decoder (GID) is an Ada package for decoding a broad
variety of image formats, from any data stream, to any kind of medium,
be it an in-memory bitmap, a GUI object, some other stream, arrays of
floating-point initial data for scientific calculations, a browser
element, a device,...
Animations are supported.

Currently supported formats are: BMP, GIF, JPEG, PNG, TGA.

URL: http://gen-img-dec.sf.net/

Enjoy
Gautier

deadlyhead

unread,
Jun 26, 2010, 12:56:53 PM6/26/10
to
On Jun 26, 2:49 am, Gautier write-only <gautier_niou...@hotmail.com>
wrote:

Quite excellent.

No bindings, eh? I'm impressed. Is it mostly translations? For
instance, did you translate the libpng for the PNG encoding?

I'll try it out soon.

--deadlyhead

Gautier write-only

unread,
Jun 26, 2010, 4:47:01 PM6/26/10
to
On 26 juin, 18:56, deadlyhead <deadlyh...@gmail.com> wrote:

> Quite excellent.

Thanks - but try it first ;-)

> No bindings, eh?  I'm impressed.  Is it mostly translations?  For
> instance, did you translate the libpng for the PNG encoding?

JPEG is mostly translated from NanoJPEG; the rest has been written
from scratch, with a good part of re-use from other Ada sources.
For instance the PNG decompression is taken from the Zip-Ada sources;
the GIF decompression is a contribution.

> I'll try it out soon.

I'd be glad to have some feedbacks.

G.

deadlyhead

unread,
Jun 27, 2010, 3:29:03 PM6/27/10
to
On Jun 26, 1:47 pm, Gautier write-only <gautier_niou...@hotmail.com>
wrote:

> I'd be glad to have some feedbacks.
>
> G.

A quick note.

I just tried compiling this package with a GNAT compiler built from
the gcc 4.4.2 sources and the GNU binutils package and got the classic
`cannot find libaddr2line.a' error. I understand that this library
comes with the binutils supplied by AdaCore with their binaries and
sources, but I prefer to build my compilers from the actual GNU
sources if at all possible.

Searching comp.lang.ada, I've come to understand that in more recent
GNAT versions (later than GNAT 2009?), and hopefully more recent GCCs
(i.e. gcc 4.5.0), GNAT no longer needs libaddr2line[1]. I'm compiling
a new gcc right now. Hopefully this will fix the problem. I'll let
you know.

-- deadlyhead

[1] http://groups.google.com/group/comp.lang.ada/msg/b9e4af2e1e4b55b6

Simon Wright

unread,
Jun 27, 2010, 5:09:43 PM6/27/10
to
deadlyhead <deadl...@gmail.com> writes:

> Searching comp.lang.ada, I've come to understand that in more recent
> GNAT versions (later than GNAT 2009?), and hopefully more recent GCCs
> (i.e. gcc 4.5.0), GNAT no longer needs libaddr2line[1]. I'm compiling
> a new gcc right now. Hopefully this will fix the problem. I'll let
> you know.

On Mac OS X, GCC 4.5.0's GNAT.Traceback.Symbolic says

-- Version used on unimplemented targets

-- Run-time symbolic traceback is currently supported on the
-- following targets:

-- HP-UX
-- IRIX
-- GNU/Linux x86
-- AIX
-- Solaris sparc
-- Tru64
-- OpenVMS/Alpha
-- Windows NT/XP/Vista

-- This version is used on all other targets, it generates a warning
-- at compile time if it is with'ed, and the bodies generate
-- messages saying that the functions are not implemented.

The working version (g-trasym.adb) in the 4.5.0 sources includes

package body GNAT.Traceback.Symbolic is

pragma Linker_Options ("-laddr2line");
pragma Linker_Options ("-lbfd");
pragma Linker_Options ("-liberty");

and hasn't changed on trunk.

Maybe GNAT GPL 2010 will have the promised change ...


Anyway, you should be able to find where GNAT.Traceback.Symbolic is
referenced, usually in the main program, and revert to plain (hex)
tracebacks.

Gautier write-only

unread,
Jun 27, 2010, 6:36:11 PM6/27/10
to
On 27 juin, 21:29, deadlyhead <deadlyh...@gmail.com> wrote:

> A quick note.
>
> I just tried compiling this package with a GNAT compiler built from
> the gcc 4.4.2 sources and the GNU binutils package and got the classic
> `cannot find libaddr2line.a' error.

I guess you tried to build tb.ads in the "Debug" mode (that's the
default), which uses GNAT's symbolic traceback. You can build
to_bmp.adb or mini.adb - without the trace-back wrapper - and also try
other build modes as well. Or even use a complete version of GNAT or
even another compiler ;-).
______________________________________________________________
Gautier's Ada programming -- http://gautiersblog.blogspot.com/

deadlyhead

unread,
Jun 27, 2010, 7:31:27 PM6/27/10
to
On Jun 27, 3:36 pm, Gautier write-only <gautier_niou...@hotmail.com>
wrote:

Yup. I ran `gnatmake -Pgid' with no other switches, which I _knew_
compiled in Debug mode, but I didn't really consider the implications.

So now, here I am compiling GCC 4.5.0, trying to navigate the strange
and frightening labyrinth of installing and updated CLooG/PPL, GMP,
MPFR and MPC while not torching half my Debian toolchain, and I
could've just added -XBuild_Mode=Fast... Oh, well. A reinstall of GCC
was bound to happen soon anyway.

-- deadlyhead

Ludovic Brenta

unread,
Jun 27, 2010, 7:33:04 PM6/27/10
to

Since you're on Debian, gnat-4.4 has working symbolic tracebacks. They
are unfortunately broken in gnat-4.3.

--
Ludovic Brenta.

deadlyhead

unread,
Jun 27, 2010, 9:13:29 PM6/27/10
to
On Jun 27, 4:33 pm, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
>
> Since you're on Debian, gnat-4.4 has working symbolic tracebacks.  They
> are unfortunately broken in gnat-4.3.
>
> --
> Ludovic Brenta.

Actually, I'm really impressed with the job you've been doing
packaging GNAT for Debian. I have it installed, too, but I've never
felt comfortable polluting my system's environment with libraries,
etc, that I'm just playing around with. I _do_ use the Debian-
supplied compilers to test code that I've written, to make sure that
it doesn't break in a ``clean'' environment.

I think I originally compiled my current installation of GNAT-from-GCC
because I wanted to try out the AVR libraries, and found that I just
felt more comfortable building other Ada libs from source in my local
toolchain. Of course, there is the whole maintenance issue, but
that's the price I pay for control. Personally, I _really_ prefer
building from scratch, ala Linux From Scratch, but haven't had the
time to devote to that recently. If only the Hurd were stable enough
to build and maintain a production environment from sources; then I'd
be really happy.

Reply all
Reply to author
Forward
0 new messages