pythonmidi-devel

[Pythonmidi-devel] Pyrex experiences?

[Lennart R. <re...@nu...>]

A big problem popped up yesterday:

It turns out that a Python objects __del__ does not necessarily get 
called when a program exits. I knew this once, but I had forgotten it.

This means the ports does not get closed unless you specifically call 
close on the objects. This is major bug for a Python program, where the 
garbage collection is supposed to make sure you never have to deallocate 
resources. It's also makes my computer crash. Not immediatly mind you, 
but say, 30 minutes later, or so. XP just silently goes *poof* and 
reboots. NOT fun! (It's probably crappy MIDI drivers that cause this).

The solution to this is supposed to be to write the whole python object 
in C, instead of just wrapping the c methods in a python object. C 
objects do get properly deallocated when a program exits, I'm told. Now, 
that means that the C code suddenly gets MUCH more complex (and it 
wasn't exactly trivial before either) so I'm gonna look at doing this in 
Pyrex.

So, anybody have any interesting experiences with Pyrex?

Re: [Pythonmidi-devel] Pyrex experiences?

[Jay V. <jv...@ac...>]

>The solution to this is supposed to be to write the whole python
>object in C, instead of just wrapping the c methods in a python
>object. C objects do get properly deallocated when a program exits,
>I'm told. Now, that means that the C code suddenly gets MUCH more
>complex (and it wasn't exactly trivial before either) so I'm gonna
>look at doing this in Pyrex.

i don't personally think that C-code to interface to python objects 
is that complex.  i've been coding in C since '85 but only hacking 
python for 2 or 3 years, so maybe thats just me.

and anyway, its already been done for MidiShare:

/src/midishare/lang/python/src/Midi.c

and

/src/midishare/lang/python/src/MidiPlayer.c


.. already cross the python/midi bridge.

-- 

;

Jay Vaughan

Re: [Pythonmidi-devel] Pyrex experiences?

[Lennart R. <re...@nu...>]

Jay Vaughan wrote:
> i don't personally think that C-code to interface to python objects is 
> that complex.  i've been coding in C since '85 but only hacking python 
> for 2 or 3 years, so maybe thats just me.

Well, I have been avoiding C and C++ since 96 so I'm beginning to forget 
it, and C-extentions bring up frightful memories. ;)

No, it ain't that complex. But it takes very careful driving, I don't 
understand all the details which annoy me, and then going from just 
wrapping methods to making objects didn't seem very inviting. ;) So I'll 
go for Pyrex first and see if that works.

> and anyway, its already been done for MidiShare:
> 
> /src/midishare/lang/python/src/Midi.c
> 
> and
> 
> /src/midishare/lang/python/src/MidiPlayer.c

Yeah, yeah, I know you like MidiShare. ;) I'm sure it's great. But one 
of the original objectives when I started this was to make something 
simple and low-level that did not require third-party libraries.

I notice that the interest in this seem frigthfully low, but I don't 
care. I'll just have to do it all myself. No problems, it will just take 
very long. :)

RE: [Pythonmidi-devel] Pyrex experiences?

[Tim T. <tj...@no...>]

> So, anybody have any interesting experiences with Pyrex?

Pyrex is fabulous, in my experience.  The way it lets
you seamlessly combine C and python code is almost spooky.
I've used it for both portaudio and VST-plugin host development.

BTW, let me encourage your efforts by saying that I would love
to see some simple and low-level (but complete, with arbitrary sysex)
MIDI support in python.

     ...Tim...

Re: [Pythonmidi-devel] Pyrex experiences?

[Lennart R. <re...@nu...>]

Tim Thompson wrote:
>>So, anybody have any interesting experiences with Pyrex?
> 
> 
> Pyrex is fabulous, in my experience.  The way it lets
> you seamlessly combine C and python code is almost spooky.
> I've used it for both portaudio and VST-plugin host development.
> 
> BTW, let me encourage your efforts by saying that I would love
> to see some simple and low-level (but complete, with arbitrary sysex)
> MIDI support in python.

Cool, thanks! Yes, I think pyrex ix the way to go. I have some problems 
passing structs by reference for the moment, but other than that it 
seems to work fine.

[Pythonmidi-devel] Pyrex summary

[Lennart R. <re...@nu...>]

Well, I have tried Pyrex a bit now, and it's not bad. Although it isn't 
much quicker to get started with that writing C-extensions, and there is 
a lot of trickery and detailing that you need to know both in 
C-extensions and Pyrex. But in the end the code gets much easier to 
understand and modify.

However, the problem I had, which I was recommended to fix with Pyrex, 
does not get solved at all. Pyrex does not seem to help with that at 
all, as far as i can tell. The objects deallocation will still not get 
called at Python exit.

Instead, I will now try hooking into atexit and sys.exceptionhook. Less 
neat, but hopefully working.


So, bye-bye Pyrex is was nice to know ya! :) Maybe we'll meet again!

//Lennart

Re: [Pythonmidi-devel] Pyrex experiences?

[Jack J. <Jac...@cw...>]

On 30 Oct 2004, at 08:00, Tim Thompson wrote:

>> So, anybody have any interesting experiences with Pyrex?
>
> Pyrex is fabulous, in my experience.

Pyrex is pretty good, but one should keep in mind that it's "yet 
another tool". What I mean is that using pyrex would create a 
dependency on it, and this would mean either that end users (assuming 
they want to or have to install the midi stuff from source) would have 
to install it too, or the source distribution would have to contain the 
pyrex C output files.
--
Jack Jansen, <Jac...@cw...>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

Re: [Pythonmidi-devel] Pyrex experiences?

[Lennart R. <re...@nu...>]

Jack Jansen wrote:
> Pyrex is pretty good, but one should keep in mind that it's "yet another 
> tool". What I mean is that using pyrex would create a dependency on it, 
> and this would mean either that end users (assuming they want to or have 
> to install the midi stuff from source) would have to install it too, or 
> the source distribution would have to contain the pyrex C output files.

Well thats the good thing, it's only a tool for the developers.
The unix distribution should definitely be the c-files. Windows (and 
mac?) distros should be binaries, if course.

[Pythonmidi-devel] Deallocating resources using destructors

[Donovan P. <dp...@ul...>]

On Oct 29, 2004, at 3:59 AM, Lennart Regebro wrote:

> A big problem popped up yesterday:
>
> It turns out that a Python objects __del__ does not necessarily get 
> called when a program exits. I knew this once, but I had forgotten it.
>
> This means the ports does not get closed unless you specifically call 
> close on the objects. This is major bug for a Python program, where 
> the garbage collection is supposed to make sure you never have to 
> deallocate resources. It's also makes my computer crash. Not 
> immediatly mind you, but say, 30 minutes later, or so. XP just 
> silently goes *poof* and reboots. NOT fun! (It's probably crappy MIDI 
> drivers that cause this).
>
> The solution to this is supposed to be to write the whole python 
> object in C, instead of just wrapping the c methods in a python 
> object. C objects do get properly deallocated when a program exits, 
> I'm told. Now, that means that the C code suddenly gets MUCH more 
> complex (and it wasn't exactly trivial before either) so I'm gonna 
> look at doing this in Pyrex.

I'm not sure where you got the idea that C objects get deallocated when 
a program exits. It's true that stack-local variables of simple type 
such as integers or chars will be automatically released because the 
entire stack is released when the program exits, but this has nothing 
to do with externally allocated resources such as memory allocated with 
malloc, opened file handles, or opened midi ports. In fact, it is 
absolutely impossible to arrange for some code to be invoked upon the 
unexpected termination of your c program.

In general, relying on destructors to free externally allocated 
resources is a bad, bad idea. Rather than attempting to rewrite your 
program in C, I would suggest you just rewrite the python portion to 
explicitly free resources in case of unexpected error (using a try: 
finally: block, for example.)

dp

Re: [Pythonmidi-devel] Deallocating resources using destructors

[Tony C. <to...@tc...>]

try registering your cleanup function with atexit.
This is supposed to be called when sys.exit is called.
Would you See if this works for you?


At 10:31 AM 11/04/04, you wrote:

>On Oct 29, 2004, at 3:59 AM, Lennart Regebro wrote:
>
>>A big problem popped up yesterday:
>>
>>It turns out that a Python objects __del__ does not necessarily get 
>>called when a program exits. I knew this once, but I had forgotten it.
>>
>>This means the ports does not get closed unless you specifically call 
>>close on the objects. This is major bug for a Python program, where the 
>>garbage collection is supposed to make sure you never have to deallocate 
>>resources. It's also makes my computer crash. Not immediatly mind you, 
>>but say, 30 minutes later, or so. XP just silently goes *poof* and 
>>reboots. NOT fun! (It's probably crappy MIDI drivers that cause this).
>>
>>The solution to this is supposed to be to write the whole python object 
>>in C, instead of just wrapping the c methods in a python object. C 
>>objects do get properly deallocated when a program exits, I'm told. Now, 
>>that means that the C code suddenly gets MUCH more complex (and it wasn't 
>>exactly trivial before either) so I'm gonna look at doing this in Pyrex.
>
>I'm not sure where you got the idea that C objects get deallocated when a 
>program exits. It's true that stack-local variables of simple type such as 
>integers or chars will be automatically released because the entire stack 
>is released when the program exits, but this has nothing to do with 
>externally allocated resources such as memory allocated with malloc, 
>opened file handles, or opened midi ports. In fact, it is absolutely 
>impossible to arrange for some code to be invoked upon the unexpected 
>termination of your c program.
>
>In general, relying on destructors to free externally allocated resources 
>is a bad, bad idea. Rather than attempting to rewrite your program in C, I 
>would suggest you just rewrite the python portion to explicitly free 
>resources in case of unexpected error (using a try: finally: block, for 
>example.)
>
>dp
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by:
>Sybase ASE Linux Express Edition - download now for FREE
>LinuxWorld Reader's Choice Award Winner for best database on Linux.
>http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
>_______________________________________________
>Pythonmidi-devel mailing list
>Pyt...@li...
>https://lists.sourceforge.net/lists/listinfo/pythonmidi-devel