pyallegro-general — General Python-Allegro-stuff

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?

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-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 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.

[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] Some steps to take over the world

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

On 2005-01-06, Grzegorz Adam Hankiewicz <gr...@ti...> wrote:
> Looking at the current state of pyallegro I figured out these things
> seem missing or are fixable. What do you think about them? I could put
> them in a TODO file for future reference.
> 
> Mailing list for CVS commit notifications.

I have created this list and set up the commit scripts. Everything
should be working fine, and you can subscribe at:

  https://lists.sourceforge.net/mailman/listinfo/pyallegro-commits

[Pyallegro] Some steps to take over the world

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

Looking at the current state of pyallegro I figured out these things
seem missing or are fixable. What do you think about them? I could put
them in a TODO file for future reference.

Mailing list for CVS commit notifications.

Document all C functions and methods with docstrings.

Document all .py functions and methods with docstrings.

Make alpy keys (defines?) work with stable and WIP. Dynamically?

Related to keys, maybe it is possible to detect WIPs at runtime to
enable special methods?

Fix possibly incorrect access of direct memory through
Bitmap_Object_get_data.

Installation documentation for Windows and Linux.

Web page with some info.

More Allegro examples ported to pyallegro.

Standarise on UTF-8 encoding and check all potential functions
passing/returning strings.  exunicode?

Specific examples showing python potential. Or just small games,
to show why Python+Allegro means less lines of code.

New OO Pyallegro?

Re: [Pyallegro] Bitmap.from_string() support

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

On 2005-01-04, Grzegorz Adam Hankiewicz <gr...@ti...> wrote:
> The attached patch provides to the Bitmap class a from_string() method
> which is fit to work with external libraries like PIL. Such a "loose"
> method can work with any kind of external lib without having to make
> alpy aware of it. Along with this patch I'm attaching a small image
> viewer I wrote which precisely exploits this from_string() method.

Commited. I'll silently commit the documentation patches on weekends, if
that's ok.

[Pyallegro] Bitmap.from_string() support

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

Hi.

The attached patch provides to the Bitmap class a from_string() method
which is fit to work with external libraries like PIL. Such a "loose"
method can work with any kind of external lib without having to make
alpy aware of it. Along with this patch I'm attaching a small image
viewer I wrote which precisely exploits this from_string() method.

If somebody gives me CVS write access I will also slowly fill in the
python docstrings of the binding. These can be used to generate the
documentation or queried interactively with shells like iPython. And of
course I'll apply this from_string() patch as well.

Re: [Pyallegro] atexit problems in windows

[Alberto G. <al...@ti...>]

> I was about to create a set of allegro bindings in python when it occurred 
> to me that I should check whether it had already been done, first.
> 
> Thank you, you saved me a lot of work :)

Great! As you may have noticed, the project is somewhat frozen, so if you are interested in maintaining it, please let me know.

> 
> I had problems getting pyallegro to work in windows. I'm running Windows XP. 
> I compile in Cygwin. I compile _alpy into a .pyd file (python DLL). I run 
> Python 2.2.2 in Windows (not cygwin). Allegro is compiled as a DLL for 
> mingw32, and I create a .a archive for linking using dlltool. When I run 
> python, I get thus far:
> 
> >>>import alpy
> >>>alpy.init_allegro()
> 
> A new window is created, but not displayed (it appears in the taskbar only) 
> and Python does not accept any more keyboard input. I have to kill python 
> and the new window at this point.
> 
> The problem, which I have hacked a fix for, seems to be because of the 
> atexit function. I had to change _alpymodule.c to call
> 
>     install_allegro(alpy_system, &errno, NULL);
> 
> instead of
> 
>     install_allegro(alpy_system, &errno, atexit);
> 
> Naturally this is a poor solution, since it doesn't call allegro's cleanup 
> routines on exit. I wonder if the behavior of atexit could be simulated 
> within DllMain to achieve the right result?

Sorry, but I wasn't able to reproduce the problem.
Here is my environment:

WinME, mingw32 (gcc 2.95.3), Python 2.2.2, latest pyallegro cvs

With this environment, everything works fine (apart from a compilation error given by line 4471 - just comment it out or remove the final ';'): this means that I get the invisible window, but I'm still able to interact with the python interpreter correctly.

As I have no way of accessing an XP box right now, I can't help you, sorry.

Regards,
Alberto

[Pyallegro] atexit problems in windows

[C R. <re...@ho...>]

I was about to create a set of allegro bindings in python when it occurred 
to me that I should check whether it had already been done, first.

Thank you, you saved me a lot of work :)

I had problems getting pyallegro to work in windows. I'm running Windows XP. 
I compile in Cygwin. I compile _alpy into a .pyd file (python DLL). I run 
Python 2.2.2 in Windows (not cygwin). Allegro is compiled as a DLL for 
mingw32, and I create a .a archive for linking using dlltool. When I run 
python, I get thus far:

>>>import alpy
>>>alpy.init_allegro()

A new window is created, but not displayed (it appears in the taskbar only) 
and Python does not accept any more keyboard input. I have to kill python 
and the new window at this point.

The problem, which I have hacked a fix for, seems to be because of the 
atexit function. I had to change _alpymodule.c to call

    install_allegro(alpy_system, &errno, NULL);

instead of

    install_allegro(alpy_system, &errno, atexit);

Naturally this is a poor solution, since it doesn't call allegro's cleanup 
routines on exit. I wonder if the behavior of atexit could be simulated 
within DllMain to achieve the right result?

_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*.  
http://join.msn.com/?page=features/featuredemail

[Pyallegro] PyAllegro 0.1 released

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

PyAllegro 0.1 is now released. This is the first public release in
almost a year. Which is nice.

http://sourceforge.net/project/showfiles.php?group_id=22470&release_id=68761

And thank you.

Re: [Pyallegro] Re: So how do I use that?

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

On Fri, Jan 04, 2002 at 01:26:36AM -0500, Alberto Griggio wrote:
> Can you tell me the details of the errors you get and of your environment?
> I tested with both python 2.2 and python 2.1.1 (the only two versions I
> have at the moment) and everything seems to work fine.

Installing Python 2.1.1 from source didn't install the dl module by
default, it's desactivated in Modules/Setup. I installed again, and
now the "import dl" doesn't fail, the dlopen doesn't fail, but I keep
getting undefined references.

Tell me which details of my environment you need:

[gregorio:50] [~/cvs/libs/pyallegro]$ python2.1
Python 2.1.1 (#1, Jan  4 2002, 19:41:43)
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more information.
>>>

[gregorio:51] [~/cvs/libs/pyallegro]$ allegro-config --libs
-L/usr/local/lib -L/usr/X11R6/lib -Wl,-export-dynamic -lalleg-4.0.1 -lalleg_unsharable

[gregorio:52] [~/cvs/libs/pyallegro]$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.2/specs
gcc version 2.95.2 20000220 (Debian GNU/Linux)

-- 
 Grzegorz Adam Hankiewicz   gr...@te...   http://gradha.infierno.org/

[Pyallegro] Re: So how do I use that?

[Alberto G. <al...@ti...>]

Grzegorz Adam Hankiewicz wrote:
> I checked out but module loading still fails with undefined symbols.

Can you tell me the details of the errors you get and of your environment?
I tested with both python 2.2 and python 2.1.1 (the only two versions I
have at the moment) and everything seems to work fine.

Alberto Griggio

Re: [Pyallegro] Re: So how do I use that?

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

On Thu, Jan 03, 2002 at 09:06:37PM -0500, Alberto Griggio wrote:
> That is, the problem is not in the path, but in the external symbols
> lookup.
> 
> I've found a possible solution to this problem: it seems to work, but I've
> not tested it very much, so there might be some pitfalls.
> Anyway, you can get it from CVS.

I checked out but module loading still fails with undefined symbols.

-- 
 Grzegorz Adam Hankiewicz   gr...@te...   http://gradha.infierno.org/

[Pyallegro] Re: So how do I use that?

[Alberto G. <al...@ti...>]

> As for determining what happens with pyallegro that it doesn't load
> it's modules, you only need to have one module, it doesn't matter which
> one, to know if it get's loaded or not. I have for example modified
> allegro/src/linux/fbcon.c, around line 956 in function _module_init to
> make the following first call:
>
>  printf("Entering fbcon module initialization\n");
>
I think I found the problem: if you uncomment line 110 of
src/unix/umodules.c, and then execute this:

>>> import alpy
>>> alpy.allegro_init()

you should get something like this:

Error loading module: /usr/local/lib/allegro/4.0/alleg-vga.so: undefined
symbol: _drawing_mode
Error loading module: /usr/local/lib/allegro/4.0/alleg-fbcon.so: undefined
symbol: empty_string
Error loading module: /usr/local/lib/allegro/4.0/alleg-svgalib.so:
undefined symbol: empty_string
Error loading module: /usr/local/lib/allegro/4.0/alleg-dga2.so: undefined
symbol: XextCreateExtension
Error loading module: /usr/local/lib/allegro/4.0/alleg-esddigi.so:
undefined symbol: empty_string

That is, the problem is not in the path, but in the external symbols
lookup.

I've found a possible solution to this problem: it seems to work, but I've
not tested it very much, so there might be some pitfalls.
Anyway, you can get it from CVS.

Of course, tell me if something goes wrong: at the moment all the examples
should work.

Alberto Griggio

Re: [Pyallegro] Re: So how do I use that?

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

On Thu, Jan 03, 2002 at 01:03:26AM -0500, Alberto Griggio wrote:
> The same happens to me too. I think you know much better than me the
> details of Allegro internals, so if you say this is a modules issue, I'll
> look in that direction: anyway, I switched from Allegro 3.9.36 (without
> modules) to 4.0.0 only a couple of weeks ago, so I didn't notice this
> until last week.

I am not that expert about Allegro internals, just happen to have dived
into the waters a few times for such things like the fbcon driver.

As for determining what happens with pyallegro that it doesn't load
it's modules, you only need to have one module, it doesn't matter which
one, to know if it get's loaded or not. I have for example modified
allegro/src/linux/fbcon.c, around line 956 in function _module_init to
make the following first call:

  printf("Entering fbcon module initialization\n");

It would be much "cleaner" to use AL_TRACE, but that one only get's
included in debug versions and I haven't bothered yet to play with
pyallegro and debug allegro versions.

Once you have an installed module with that, you can go to X and run the
C version of exhello. While the window pops up you should see at least
once that printf appearing in the xterm. This is because each module get's
registered before calling it's module dependant set_gfx_mode funcion.

Now, if you repeat that with exhello.py, you won't see any printf message.
That's as far as I have reached yet, because I still don't know how the
dynamic loader works with paths and such things. I will tell you if I
find out, of course.

-- 
 Grzegorz Adam Hankiewicz   gr...@te...   http://gradha.infierno.org/

Re: [Pyallegro] Re: Just a random question about wrapper implementation

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

On Thu, Jan 03, 2002 at 01:03:59AM -0500, Alberto Griggio wrote:
> Hello.
> I'm glad to see you are so interested to PyAllegro.

Somebody has to :) I really like Python, but recently I started reading
about Lua, and it's nicer there to implement C libraries, since lua can
map directly script globals to C globals. There even is a tool which
given a header file creates lua code which "imports" the C lib.

Very nice, so I thought about creating such a conversion tool for python,
but then I learned about python not mapping C globals :(

BTW, if it feels cleaner or at least nicer/easier to implement, remember
that Allegro has a few poll_keyboard, poll_mouse, etc, so you could
make the python code require to do this, maybe improving runtime speed,
since then the user would decide when the python wrapper has to get into
the C lib to retrieve the apropiate values.

-- 
 Grzegorz Adam Hankiewicz   gr...@te...   http://gradha.infierno.org/

Re: [Pyallegro] Just a random question about wrapper implementation

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

On ke, 2002-01-02 at 02:28, Grzegorz Adam Hankiewicz wrote:
> I seem to have overlooked global variables wrapping
> standard procedures.  IOW: how the hell do you wrap around something
> like say mouse_x?
> 
> My little understanding tells me that you would create a python wrapper
> class.  User python code would use methods of this class like set/get
> to write/read the variable, and the class code would do the actual trick
> of modifying/returning the real C global value. Python example:

I have a hunch that there is some way to wrap a variable. Perhaps by
creating a new type.

But the class method is propably a cleaner way to wrap that.

>  import pyallegro
>  pyallegro.install()
>  pyallegro.whatever()
>  print "Mouse is at %d" % pyallegro.mouse_x.get()

I think a better style (similar to what's done in python-gnome) would be
this:

  import alpy
  alpy.init()
  alpy.whatever()
  print "Mouse is at %d" % alpy.mouse.x

Here the __getattr__-method could be defined for a class 
'mouse'. See the syntax from
http://www.python.org/doc/current/ref/attribute-access.html#l2h-110

Still I don't know if this can be applied at the module-level.


-- 
Juha-Matti Tapio, ATK-suunnittelija, fil. yo.
+358-50-5419230

[Pyallegro] Re: Just a random question about wrapper implementation

[Alberto G. <al...@ti...>]

Hello.
I'm glad to see you are so interested to PyAllegro.

To answer to the question about wrapping global variables, I must say: it
depends on the variable :)
As regards mouse_x, for example, there is a function called
'get_mouse_pos' which returns a 4-tuple of ints: mouse_z, mouse_y,
mouse_z, mouse_b.
For globals which value change only after the invocation of some functions
(for example screen), the solution was to update the value inside that
function, for example:

def set_gfx_mode(card, w, h, v_w, v_h):
    .....
    global screen
    screen = _alpy.get_screen()
    ....

and so on.

Other solutions are possible, especially using __getattr__/__setattr__
(have a look at 'counters' object in alpy.py for example)

There are situations, anyway, where the get/set pair of functions seems
difficult to avoid: I've used it for example to provide access to the
'line' member of BITMAP structs.

I hope the answer is enough: if not, ask it again :-)

Alberto Griggio

[Pyallegro] Re: So how do I use that?

[Alberto G. <al...@ti...>]

> Now, for example exhello.py doesn't work under console but does under
> X.  Explanation: it has something to do with paths, since I am using
> fbdev and this driver is compiled as an allegro module. Where should I
> look at to fix this? The example just fails with GFX_SAFE. On my
> computer the only driver which works under console is framebuffer, and
> it was me who wrote it's GFX_SAFE behaviour, so I know for sure it's a
> module loading issue, allegro C examples work perfectly.

The same happens to me too. I think you know much better than me the
details of Allegro internals, so if you say this is a modules issue, I'll
look in that direction: anyway, I switched from Allegro 3.9.36 (without
modules) to 4.0.0 only a couple of weeks ago, so I didn't notice this
until last week. Thank you for the explaination: when I first saw the
problem, I really didn't know where to look for a solution! I'll try to
fix it as soon as possible.

Alberto Griggio

Re: [Pyallegro] So how do I use that?

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

On Wed, Jan 02, 2002 at 12:46:59AM +0200, Juha-Matti Tapio wrote:
> How does it react to "setup.py install_lib"?

Wait a moment please... I am eating my hat by now... (munch munch).

I am sorry, just forgot to update my cvs copy so I had not been running
the latest code: I've been reportin ghosts. Now everything works cleanly
for python2.1, and for python1.5 the only glitch is:

[~/cvs/libs/pyallegro]$ ./setup.py build
running build
running build_py
not copying alpy.py (output up-to-date)
running build_ext
building '_alpy' extension
gcc -g -O2 -fPIC -I/usr/local/include -I/usr/include/python1.5 -c _alpymodule.c -o build/temp.linux-i686-1.5/_alpymodule.o
_alpymodule.c: In function `blend_driver':
_alpymodule.c:3450: warning: assignment discards qualifiers from pointer target type
_alpymodule.c: In function `alpy_create_color_map':
_alpymodule.c:3502: `PyExc_Warning' undeclared (first use in this function)
_alpymodule.c:3502: (Each undeclared identifier is reported only once
_alpymodule.c:3502: for each function it appears in.)
error: command 'gcc' failed with exit status 1

> Currently set_gfx_mode() returns always None. Instead it raises
> AlpyException when it failes to set the mode.

The error was caused by using old code. Now, for example exhello.py
doesn't work under console but does under X. Explanation: it has something
to do with paths, since I am using fbdev and this driver is compiled as an
allegro module. Where should I look at to fix this? The example just fails
with GFX_SAFE. On my computer the only driver which works under console
is framebuffer, and it was me who wrote it's GFX_SAFE behaviour, so I know
for sure it's a module loading issue, allegro C examples work perfectly.

-- 
 Grzegorz Adam Hankiewicz   gr...@te...   http://gradha.infierno.org/

[Pyallegro] Just a random question about wrapper implementation

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

Hello.

After reading some documentation to see if I could help with the
pyallegro wrapper, I seem to have overlooked global variables wrapping
standard procedures.  IOW: how the hell do you wrap around something
like say mouse_x?

My little understanding tells me that you would create a python wrapper
class.  User python code would use methods of this class like set/get
to write/read the variable, and the class code would do the actual trick
of modifying/returning the real C global value. Python example:

 import pyallegro
 pyallegro.install()
 pyallegro.whatever()
 print "Mouse is at %d" % pyallegro.mouse_x.get()

Is this correct? If yes, huh, it's kinda ugly...

-- 
 Grzegorz Adam Hankiewicz   gr...@te...   http://gradha.infierno.org/

Re: [Pyallegro] So how do I use that?

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

On ti, 2002-01-01 at 23:49, Grzegorz Adam Hankiewicz wrote:
> On Tue, Jan 01, 2002 at 10:45:43PM +0200, Juha-Matti Tapio wrote:
> > > Output/effect remains the same as root or user. Same messages with both
> > > python versions (1.5 and 2.1).
> > 
> > Just a thought. Do you have python-dev package installed?
> Yes. The only problem is with installation: only _alpy.so get's installed,
> none other files are copied anywhere. 

How does it react to "setup.py install_lib"?

> > Currently the cvs-version seems to build nicely with the newest 2.1 and
> > 2.2 Debian packages.
> Yes. Please put somewhere (maybe that lone README?) that those versions
> are required to run:

Done.

> #!/usr/bin/env python2.1
> from alpy import *
> install_allegro(SYSTEM_AUTODETECT)
> install_keyboard()
> print "Hey man"
> print set_gfx_mode(GFX_AUTODETECT, 320, 200)
> readkey()

> I would expect it to set a graphic mode, but it doesn't, it prints
> None. readkey works though.

Currently set_gfx_mode() returns always None. Instead it raises
AlpyException when it failes to set the mode.

What happens, if you do this:

from alpy ipmort *
import _alpy
install_allegro(SYSTEM_AUTODETECT)
install_keyboard()
_alpy.set_gfx_mode(GFX_AUTODETECT, 320, 200)
readkey()

It might give a more precise error message.

-- 
Juha-Matti Tapio, ATK-suunnittelija, fil. yo.
+358-50-5419230

Re: [Pyallegro] So how do I use that?

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

On Tue, Jan 01, 2002 at 10:45:43PM +0200, Juha-Matti Tapio wrote:
> > Output/effect remains the same as root or user. Same messages with both
> > python versions (1.5 and 2.1).
> 
> Just a thought. Do you have python-dev package installed?

Yes. The only problem is with installation: only _alpy.so get's installed,
none other files are copied anywhere. The same happens with python 2.1,
which I installed from source, but there's just one big source file to
download from www.python.org, so I guess I don't need anything more.

> Currently the cvs-version seems to build nicely with the newest 2.1 and
> 2.2 Debian packages.

Yes. Please put somewhere (maybe that lone README?) that those versions
are required to run:

Python 1.5.2 (#0, Dec 27 2000, 13:59:38)  [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import alpy
Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "alpy.py", line 23, in ?
    import _alpy, sys
ImportError: /usr/lib/python1.5/site-packages/_alpy.so: undefined symbol: PyObject_DEL
>>>

Python 2.1.1 (#1, Aug 25 2001, 15:17:34)
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import alpy
>>> print alpy.install_allegro
<function install_allegro at 0x8174afc>
>>>

BTW, I figured out that Allegro just doesn't work with interactive python
sessions (at least for me), because I tried to build my own pyallegro
version from scratch. However, the following script doesn't work as
expected for me:

#!/usr/bin/env python2.1

from alpy import *

install_allegro(SYSTEM_AUTODETECT)
install_keyboard()
print "Hey man"
print set_gfx_mode(GFX_AUTODETECT, 320, 200)
readkey()

I would expect it to set a graphic mode, but it doesn't, it prints
None. readkey works though.

-- 
 Grzegorz Adam Hankiewicz   gr...@te...   http://gradha.infierno.org/