[Stackless] Re: Stackless Python is DEAD!

Christian Tismer tismer at tismer.com
Sat Jan 19 16:32:32 CET 2002


Jacob Gorm Hansen wrote:

> On Fri, Jan 18, 2002 at 08:43:11PM -0800, Donn Cave wrote:
> 
>>Quoth Christian Tismer <tismer at tismer.com>:
>>...
>>| What do you mean by acceptable?
>>| The 95 percent of users who get their solution
>>| in time will for sure accept it. Who else is relevant?
>>
>>I don't know if anyone is particularly relevant.  By acceptable,
>>I mean that when programmers decide whether to pursue designs
>>that depend on Stackless features, you're asking them to accept a
>>severe loss of portability.  Many of them may find that unimportant,
>>because as you say the majority platforms will be OK for now.  But
>>I can't believe it's going to be generally acceptable.  Maybe I just
>>don't want to believe it, because I think that attitude really sucks.
>>Whatever, we'll see.
>>
> 
> I think it sound interesting, don't see why the way C handles the stack must
> limit what other programs (especially languages) can do. My guess is porting
> these changes is to other compilers and OSes is far from imposssible. I would
> love however, if Christian were to adopt a more unixy development environment,
> using standard patches and a public CVS repo instead of father xmas style
> grand releases, but maybe that will come, as all good things come to those who
> wait.


Ok, I take the challenge. I use CVS for several commercial
projects meanwhile, so I have no trouble to turn Stackless
into a cvs repository.

Some words on future directions:

1) I have been pointed to it already: Instead of throwing all of
    the old Stackless code away, it is also possible to merge it
    with the new approach. The brute-force stack munging would
    then only be needed in the cases where old Stackless blocks.
    This can be considered for a future version.

2) The old stackless was a number of difficult, hairy patches
    which had to be done by hand. This is bad for me.
    There are two ways out of the dilemma, where I choosed the
    simple one for now:
    a) enforce stacklessness by modifying the C stack. This is
       rather easy, with some drawbacks on portability.
    b) write a SWIG-like preprocessor which runs through the whole
       source tree, identifies the code which is to be turned
       into tail recusion, and automatically rewrite it
       accordingly. This appears to be difficult, but it must be
       doable. Probably, nobody should look at the output of
       this preprocessor run, provided it works.

b) would be a very interesting project. I will think more
    of it, when we have a) flying.

cheers - chris

-- 
Christian Tismer             :^)   <mailto:tismer at tismer.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Kaunstr. 26                  :    *Starship* http://starship.python.net/
14163 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
      where do you want to jump today?   http://www.stackless.com/


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



More information about the Stackless mailing list