pyallegro-general

[Pyallegro] Questions about current implementation

[Grzegorz A. H. <gr...@ti...>]

Hi.

What is the file allegro.c used for? I can rename it and the alpy
module is still built.

And why at some point in alpy.py functions like get_allegro_id or
get_default_palette are deleted? Strikes me as odd that they still
are included in documentation.txt.

Re: [Pyallegro] Questions about current implementation

[Juha-Matti T. <jm...@ve...>]

On Sat, Jan 29, 2005 at 06:14:23PM +0000, Grzegorz Adam Hankiewicz wrote:
> What is the file allegro.c used for? I can rename it and the alpy
> module is still built.

If my memory serves me right, it is the original module and it is not 
used anymore. allegro.py seems to be it's pair as they both carry the
$Log$-notation which I used to prefer a few years ago.

> And why at some point in alpy.py functions like get_allegro_id or
> get_default_palette are deleted? Strikes me as odd that they still
> are included in documentation.txt.

Everything is imported into alpy module's namespace by 
from _alpy import * earlier and the del-statements are propably meant to
hide those imported definitions from the user. However most of these
deletions are not necessary because those functions are wrapped in
python-functions by the same name.

Re: [Pyallegro] Questions about current implementation

[Grzegorz A. H. <gr...@ti...>]

On 2005-01-29, Juha-Matti Tapio <jm...@ve...> wrote:
> > What is the file allegro.c used for? I can rename it and the
> > alpy module is still built.
> 
> If my memory serves me right, it is the original module and it is
> not used anymore. allegro.py seems to be it's pair as they both
> carry the $Log$-notation which I used to prefer a few years ago.

You want to keep it?

> > And why at some point in alpy.py functions like get_allegro_id
> > or get_default_palette are deleted? Strikes me as odd that they
> > still are included in documentation.txt.
> 
> Everything is imported into alpy module's namespace by from _alpy
> import * earlier and the del-statements are propably meant to
> hide those imported definitions from the user. However most of
> these deletions are not necessary because those functions are
> wrapped in python-functions by the same name.

Hmmm... documentation generated by pydoc is beginning to look nice.

One thing I haven't looked yet, and you may save me the trouble,
is how is Allegro linked into alpy? Meaning, if I build alpy
against allegro 4.1.10 and then remove 4.1.10 and install 4.0.3,
would alpy import this version? Or once you build alpy, it is only
able to import the specific version it has been linked against?

Maybe 4.1.x vs 4.0.x was not a good example, because the ABI changes,
but what about 4.0.0 vs 4.0.3 then? If the library can change, alpy
will need version detection codes to modify the key constants. At
the moment I use a custom patch so that the shift key works for
4.1.18, because it's define changed at some point.

Re: [Pyallegro] Questions about current implementation

[Juha-Matti T. <jm...@ve...>]

On Sun, Jan 30, 2005 at 08:51:52PM +0000, Grzegorz Adam Hankiewicz wrote:
> On 2005-01-29, Juha-Matti Tapio <jm...@ve...> wrote:
> > > What is the file allegro.c used for? I can rename it and the
> > > alpy module is still built.
> > If my memory serves me right, it is the original module and it is
> > not used anymore. allegro.py seems to be it's pair as they both
> > carry the $Log$-notation which I used to prefer a few years ago.
> You want to keep it?

Not really. It's propably best to dispose of it to prevent confusion.

> One thing I haven't looked yet, and you may save me the trouble,
> is how is Allegro linked into alpy? Meaning, if I build alpy
> against allegro 4.1.10 and then remove 4.1.10 and install 4.0.3,
> would alpy import this version? Or once you build alpy, it is only
> able to import the specific version it has been linked against?

setup.py calls allegro-config (on *NIX platforms) to determine the
libraries to link against. On win32 it seems to link straight to alleg.

I did a little test:

$ allegro-config --libs release
-L/usr/lib -L/usr/X11R6/lib -lalleg-4.1.15 -lm -lpthread -lXxf86dga -lXxf86vm -lXpm -lXext -lX11 -ldl

$ ldd build/lib.linux-ppc-2.3/_alpy.so
        liballeg.so.4.1 => /usr/lib/liballeg.so.4.1 (0x6fe8d000)
        libm.so.6 => /lib/libm.so.6 (0x6fdf8000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x6fd87000)
        libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x6fd66000)
        libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x6fd34000)
	libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x6fc3b000)
        libdl.so.2 => /lib/libdl.so.2 (0x6fc18000)
        libc.so.6 => /lib/libc.so.6 (0x6fab9000)
        /lib/ld.so.1 => /lib/ld.so.1 (0x08000000) 

Based on this I would expect alpy to continue to work with any 4.1-version
that has the same ABI but not with any other 4.x-version.

> Maybe 4.1.x vs 4.0.x was not a good example, because the ABI changes,
> but what about 4.0.0 vs 4.0.3 then? If the library can change, alpy
> will need version detection codes to modify the key constants. At
> the moment I use a custom patch so that the shift key works for
> 4.1.18, because it's define changed at some point.

Ok, constants might be a bit tricky since they come from the header
files and not the dynamic library (and alpy.py has them hardcoded).

If the constants change within the 4.1-series then I do not see any
choice but to add version detection. This might need parsing of
allegro_id.

Normally it might be nice if the constants could be autogenerated from
the headers at alpy's compile time, but this might not be possible if
they can change within minor-level versions of the library.

Re: [Pyallegro] Questions about current implementation

[Grzegorz A. H. <gr...@ti...>]

On 2005-01-31, Juha-Matti Tapio <jm...@ve...> wrote:
> Not really. It's propably best to dispose of it to prevent confusion.

Ok, removed.

> Ok, constants might be a bit tricky since they come from the header
> files and not the dynamic library (and alpy.py has them hardcoded).
> 
> If the constants change within the 4.1-series then I do not see
> any choice but to add version detection. This might need parsing
> of allegro_id.
> 
> Normally it might be nice if the constants could be autogenerated
> from the headers at alpy's compile time, but this might not
> be possible if they can change within minor-level versions of
> the library.

Oh, I think I'll deal with the problem when somebody other than me
finds it too. It's really a minor issue, and besides, who is using
an Allegro WIP with Pyalleg?