[Stackless] Google Summer of Code - PSF / Time is Short

Richard Tew richard.m.tew at gmail.com
Tue Mar 20 19:51:53 CET 2007


On 3/20/07, Carlos Eduardo de Paula <carlosedp at gmail.com> wrote:
> Richard, this is my case.. I would really like to contribute... but
> dont have an idea on what to contribute...
>
> I recently created the examples project but i would like to contribute
> to something in the core...

Well, I am not sure what you mean by core.  Perhaps you mean
some C level work on Stackless to enhance or upgrade it.  In which
case Christian is better than I at knowing what could be done there.
Even if you don't mean that, Christian can probably come up with
better ideas than I will list below.

These are various projects which I have in mind to do and see them
as potentially helping make Stackless more approachable as well
as fleshing it out to make it more usable.

How much of these make up enough to constitute a summer of code
project I do not know.  Perhaps some combination of one or more
will do the trick.

* Documentation.

Stackless could do with a documentation starter pack.  Documenting
the API, usage and a variety of other topics including how to go about
various things.  I imagine it could get quite extensive.  It might
would be in the format standard Python documentation is written in,
ready to generate HTML to be added to the website both directly
accessible or as a download for the convenience of users.  Or
alternately ideally done in a wiki, but set up to generate into
the desired formats from there.  Perhaps ready to build nightly.

* slpmonkeypatch

What seems like a long time ago now, Andrew Dalke suggested
making Stackless more naturally usable by using monkey patching
to make things like sockets, files and other blocking API to
transparently block their calling tasklets on channels.  So with little
effort people could get Stackless to just work IO wise.

However, for this to be done properly it needs work done to support
posix systems and work done to support Windows systems.  I
envisage it using overlapped IO / IO completion ports on Windows
with replacement socket and file objects wrapping the use of those.
There is most of a file object written to this end already.  I have no
idea how this would be accomplished on posix systems.  I imagine
the existing stacklesssocket object needs an accompanying
stacklessfile object and there are some accoutrements that claim
to effect some degree of asynchronous file IO in asyncore, but
I don't think its enough.

I imagine however it is done, on both platforms ctypes is the best
approach to overcoming lackings in the Python runtimes
facilities.

* A scheduling interpreter.

This is an idea my coworker Michael Brannan and I were thinking
about.  We were thinking of how we use Stackless, embedded in
our game servers and clients.  We have a console, but when we
use it to create tasklets and such, the scheduler isn't a concern.
The application embeds Stackless and the scheduler is pumped
by it.  The console can just be used to enter Python commands
like the normal interpreter.  But it is so much more approachable
for playing around with Stackless functionality because the
scheduler is pumped by the applicaton.  You don't need to worry
about running the scheduler.  Or that when all the channels are blocked
the scheduler will exit.  The lifetime of the scheduler and its
running is tied to the lifetime of the application.  Any tasklets
you create in the console just run as soon as they execute (or
rather perhaps immediately after when the scheduler is next
pumped by the application).

Writing a console like this, where it is entered by telnet or
accessed through a custom UI is pretty trivial.  But I am not
sure how easy it would be to adapt the normal interpreter
to work this way when someone starts it up.  Especially in
a non-invasive way, with no C changes to the mainline Python
code.  Ideally any C changes would be isolated to the Stackless
directory.  Or it would be done in Python.

Is this actually worth doing?  Not sure.  That needs judging
by people who could or could not see themselves using it.


Anyway, these are all the projects which come to mind for now.
As I said, Christian probably has a lot more worthwhile ones.
And they might not be what you mean by core.

Hope it helps in any case,
Richard.

_______________________________________________
Stackless mailing list
Stackless at stackless.com
http://www.stackless.com/mailman/listinfo/stackless



More information about the Stackless mailing list