anyone have a can of Raid?

22:48 < pjd_> you seem to have a talent for exposing strange and interesting bugs :)

Yes, that's right. Another Pyrex bug, and another awesome fix from Piet. It's good that the Pyrex guys are getting a chance to find some of these problems, just wish I didn't keep hitting them. To be honest, Pyrex is well used by lots of projects, I just seem to be using the newer language features.

Working to resolve a render bug with widgets now. I'm coding very slowly, using printf everywhere, every function seems to bring two or three new bugs that need to be resolved.

it's ALIVE!

After much debugging coreloop, now set to operate in it's own thread without having to obtain the Python GIL.

It's working and appears to be stable outside of FreeGLUT-related bugs. This can be demonstrated in windows refreshing after their size is changed or uncovered.

At this point the code has all been moved to Pyrex, even the coreloop thread. The latter took two days resolving a bug that turned out to be from Pyrex 0.9.4, we require Pyrex 0.9.5.1a (the latest release) which supports multiple cimport commands for parts of the same package.

Many thanks to Piet Delport for his help in resolving this!

So PySoy compiles beautifully now. Now to get widgets rendering again, specifically soy.widgets.Projector ;-)

pysoy roadmap

Since it's been requested, here's the timeline for PySoy 1.0. Note that hit some of these dates far earlier than projected.

Friday, April 13th: API overhaul (mostly) complete, pushed to SVN and "unfrozen" for continued development

As the new maintainer, in an effort to bring order to chaos, I've frozen development while I restructure the API (and thus the code). On April 13th, if not before, a major SVN commit will be made with these changes. Any bugs I find but cannot fix along the way are being entered into the ticket system for dealing with later, my focus is overall structure and getting coreloop working well under the structure we previously conceived.

Between 4/13 and 5/28, our Summer of Code students will be getting up to speed on what we're doing and our development practices.

Monday, May 28th: Our Summer of Code students begin work.

Since they are working full-time, the three of them together represent a majority of the work being done over the Summer. This is not to say the rest of the development team isn't working as well, but most of what we'll be doing is re-implementing the code we've already done into the new API and debugging/optimizing it. By contrast, the students will be adding new code we have not worked on before so their jobs are significantly more time consuming.

Friday, June 29th: First "beta" release, SVN read access open to public

By the end of June we'll release the codebase as we have it for public viewing. There will be no guarantee that the API will remain the same between this and 1.0 but changes, if any, will be minor. The primary reason for doing this is to get sample games ready before 1.0 release and get input from the larger community on ways it could be further polished.

Summer of Code work will not even be to midterms at this point, but some preliminary student work should be available by this point. There may also be additional "beta" releases between this and the final release.

Friday, August 18th: Release Candidate 1

At least one release candidate will be made prior to 1.0, each with a 48 hour window to find any remaining bugs or issues (ie, a missing file or #ifdef for a platform). Any change represents a new RC with new 48 hour window.

Friday, August 24th: 1.0 Release

We want to hit the "end of summer" deadline and have 1.0 released with the SoC students work included. This leaves enough time for potentially three or four release candidates prior to final release.

1.0 represents a stable API which can be safely developed for.

Thereafter: 1.1 and beyond

Further development remains backwards compatible to code designed for 1.0 while adding new features, optimizing it's speed, or fixing a few fringe-case bugs we missed.

of children and parents..

More of the old Python-side API getting moved over to cdefs, today is the "Children" type 'list' becoming a C array w/ mutex locking and position shifting. I decided to do something a bit more by making this a cdef class:

cdef public class Children [object soyChildren, type soyChildrenType]:
  '''PySoy Children

     This is a thread-safe C array of Python objects for "Parent" classes.
     It's append, index, and remove methods are identical to Python lists.
     The up, down, top, bottom, and move methods move an object in the array.
     The lock and unlock methods control the mutex.
  '''
  cdef int size
  cdef int current
  cdef void **list
  cdef PyThread_type_lock lock

  def void __new__(self)
  cdef void lock(self)
  cdef void unlock(self)
  cdef void append(self, void *child)
  cdef int index(self, void *child)
  cdef void swap(self, int first, int second)
  cdef void up(self, void *child)
  cdef void down(self, void *child)
  cdef void top(self, void *child)
  cdef void bottom(self, void *child)
  cdef void remove(self, void *child)
  def __dealloc__(self)

Instances of this class must be locked/unlocked externally. When the coreloop traverses the various trees it'll lock/unlock thus blocking Python's execution only if Python is trying to modify the children while it's being processed. Much better than using the GIL.

This is in a soy._imports module to keep it out of the way and attached as a cdef attribute to any "parent" class. A similar Child class will reference these methods and can be inherited by the base types which need to attach to a parent.

learning to trust pyrex

I've had a frustrating interesting night with Pyrex, 6 lines of code being written, rewritten, repeatedly, in both C and Pyrex trying to get a simple struct array to work properly.

With some spectacular help from pjd it was finally resolved, and Coreloop is running again, but this spawned a discussion about trusting Pyrex and I've come to realize that - no - I don't trust it. I was coding 6502 assembly in middle school, I started coding C over a decade ago, I don't even use an IDE because it seems to get in the way more than it helps, and here I am trusting this "Pyrex" thing to chew up my code in it's own language, regurgitate it as C, and possibly not give me access to certain things that I need?

However, PySoy is too big to write in C alone, I've been down that road with much smaller modules and it's not fun. I'm going to have to learn to trust the 'rex and start thinking of it as a language of it's own.

In other news, I'm feeling more confident about our SoC students. Hopefully PSF gets enough student slots for us to end up with at least 2 of our applicants.

synergy restored my sanity

So I have a lab setup with multiple testing systems, each with a different kind of video card, and a cluttered desk of keyboards, mice, game controllers and joysticks. There's a mass of braided/tangled/ratnested cables from all these peripherals leading to the computers behind my desk.

By the advice of some X.org devs I installed Synergy and set every test system on a loop. Each continues to have it's own GPU+Monitor, their own GNU/Linux distro for packaging, but I only need one keyboard and one mouse to move between them.

Kudos guys, what's left of my sanity thanks you!

new maintainer

I've resumed my role as pysoy maintainer due to Zach's other committments not leaving enough time for him to continue the position. Zach will remain on as the distribution director and windows packaging lead.

Now that I've had time to review the work that's been done I've started work on an inter-component API and roadmap to move forward. Look for these on the wiki, and yes, they're open for discussion. The role of maintainer is to facilitate and mediate, not dictate.

After this is done we'll begin getting the codebase back into SVN. I feel it's important, especially given new developers joining us, that this be done in the next two weeks. Part of this process will include pruning developers who are no longer active by who works toward this goal.

Summer of Code 2007

PySoy will once again participate in Google's Summer of Code under the Python Software Foundation.

We've had several decent proposals from students and will have a tough time choosing between them. It's always one of the things I have a tough time with, myself. Announcements for which students were accepted will be made April 11th.

a Moment of Nostalgia

Damned. I missed the international C64 convention last month.

Let's see what's new in C64-land.. Ethernet controllers, online games, and apparently plans for a MMORPG. Oh, look, you can even download GEOS at no cost now!

I keep reminding myself it runs at 1mhz, my PDA is more powerful, but it's still nice to think about MMORP'ing on my old commie.

svn.pysoy.org reset

Our subversion server should be ready to go now. The old codebase (that was dumped several months ago) is gone, the blender plugin Palle wrote is copied over as is the media directory, and a /trunk/pysoy directory is awaiting the code Zach's team has been working on.

Oh, yea, we're posting to the CIA bot now. Hopefully we can get the bot in #PySoy soon.