[Stackless] Google Summer of Code - PSF / Time is Short
Carlos Eduardo de Paula
carlosedp at gmail.com
Wed Mar 21 13:44:06 CET 2007
Probably I did not expressed me in correct way when I meant by "core",
I was thinking about functionality to improve the usability of
stackless and increase its usage and the range of what it applies.
The ideas you proposed are very nice, I liked the documentation and
the monkeypatching ones, I will think more about it and give a
feedback to you all if I will apply on it...
I have one issue though, some questions proposed by monkeypatch can be
addressed by other ways... like the twisted approach in the networking
side, where we can a nonblocking network access have using the last
example of the blockOn function posted some days ago.
The file access module would be a great addition, but i need to study
ctypes and posix file access more deeply...
The documentation is a much needed feature, and I was already thinking
about it.. maybe write something like Grant Olson's tutorial with many
Anyway, I will give a feedback between today and tomorrow morning about it..
Thanks a lot,
On 3/20/07, Richard Tew <richard.m.tew at gmail.com> wrote:
> 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
> * 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,
Stackless mailing list
Stackless at stackless.com
More information about the Stackless