Hi! Sorry it has taken forever to reply...
This is the list of possibly orphaned parts of pypy. We should consider each item here and think in detail what to do with them. They're mostly broken or not actively maintained. If nobody shows an interest to maintain them, deleting would be the best solution to avoid clutter. Also they pose a maintenance burden when we proceed with the needed large refactorings. Maybe it is also a solution to lazily delete them as they are broken by refactoring if nobody steps up.
Of course deleted things can easily be brought back from svn history, if there is renewed interest. So the above may sound scarier than it is.
* llvm backend - we need a maintainer for that
As much I as I agree that deleting code is better than leaving it to rot beyond all recognition, I'm still not sure why we need a "maintainer" for this given that no other backend has an explicit maintainer. But anyways I will take that role if it needs be. Most work to be done is in factoring code out of genc and making rffi work (which I am guessing making changes to rffi, but not sure since haven't been following things for last however many months).
* pyrex backend (llvm depends on it tough)
There is no longer this dependency. Cheers, Richard
Good to hear. There is no reason for maintainer, but we need llvm backend to be refactored so it would be easier to maintain for whoever makes changes. Also right now llvm version dependency is so bizzare that I cannot really test it on my machine without additional hassle. I can help with that, if possible. Cheers, fijal On 9/27/07, Richard Emslie <richardemslie@gmail.com> wrote:
Hi!
Sorry it has taken forever to reply...
This is the list of possibly orphaned parts of pypy. We should consider each item here and think in detail what to do with them. They're mostly broken or not actively maintained. If nobody shows an interest to maintain them, deleting would be the best solution to avoid clutter. Also they pose a maintenance burden when we proceed with the needed large refactorings. Maybe it is also a solution to lazily delete them as they are broken by refactoring if nobody steps up.
Of course deleted things can easily be brought back from svn history, if there is renewed interest. So the above may sound scarier than it is.
* llvm backend - we need a maintainer for that
As much I as I agree that deleting code is better than leaving it to rot beyond all recognition, I'm still not sure why we need a "maintainer" for this given that no other backend has an explicit maintainer. But anyways I will take that role if it needs be. Most work to be done is in factoring code out of genc and making rffi work (which I am guessing making changes to rffi, but not sure since haven't been following things for last however many months).
* pyrex backend (llvm depends on it tough)
There is no longer this dependency.
Cheers, Richard
_______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
participants (2)
-
Maciej Fijalkowski -
Richard Emslie