I have a new project! (Oh no). So one day, sort of randomly, J.O'D on haskell-cafe takes the intiative to a start a wxhaskell revival process, and naturally enough, I volunteered to help out. I have now been assigned the task of making sure the Unicode stuff works (which I'm interpreting mostly as figure out how to write a semi-automated eyeball test suite).
Of course, one of the first things I ask for is for wxhaskell to switch to darcs. This project has been first-hand experience for me why a distributed version control system is so useful: it keeps the bit-rot away. Darcs's patch-oriented nature would have allowed us to keep a Unicode fork of wxhaskell alive whilst waiting for the official maintainers to find the time to bring the project back to life. You can't blame them... people are busy, right? The situation we faced with wxhaskell was one where Unix patch was piling on top of Unix patch; it was getting a little messy and annoying. This was exactly the kind of situation where easy forking and easy healing can keep a niche project alive.
I feel kinda silly. I've apparently had a tailorised darcs mirror of wxhaskell lying around since early July and just never went public with it. So tonight, after TD offered to host the darcs stuff, I finally dusted it off, and converted my Unicode mega-patch into 5 darcs patches and uploaded the whole deal on my homepage. I'm not linking it, because it's really supposed to be temporary. But the rest of the wxhaskell revival team know about it. So it's moving!
wxC and SWIG
SS on the wxc list has suggested we switch from handwriting our wxC stuff to autogenerating it with SWIG. It's been interesting discussing with him. Learned a bit from the process, and got a reminder (duh) that wxC is actually C++ code (of course, what else would it be?), only that it behaves exactly like C code on the outside. Anyway, long term project's looking interesting. SS says that given enough configuration, we should be able to generate the wxC code directly, even including the kind of annotations that wxhaskell needs. But we also agree that this kind of thing is for the long term. Short term priority is to get the new wxhaskell and wxc out the door!
I have a new project! (Oh no). So one day, sort of randomly, J.O'D on haskell-cafe takes the intiative to a start a wxhaskell revival process, and naturally enough, I volunteered to help out. I have now been assigned the task of making sure the Unicode stuff works (which I'm interpreting mostly as figure out how to write a semi-automated eyeball test suite).
Of course, one of the first things I ask for is for wxhaskell to switch to darcs. This project has been first-hand experience for me why a distributed version control system is so useful: it keeps the bit-rot away. Darcs's patch-oriented nature would have allowed us to keep a Unicode fork of wxhaskell alive whilst waiting for the official maintainers to find the time to bring the project back to life. You can't blame them... people are busy, right? The situation we faced with wxhaskell was one where Unix patch was piling on top of Unix patch; it was getting a little messy and annoying. This was exactly the kind of situation where easy forking and easy healing can keep a niche project alive.
I feel kinda silly. I've apparently had a tailorised darcs mirror of wxhaskell lying around since early July and just never went public with it. So tonight, after TD offered to host the darcs stuff, I finally dusted it off, and converted my Unicode mega-patch into 5 darcs patches and uploaded the whole deal on my homepage. I'm not linking it, because it's really supposed to be temporary. But the rest of the wxhaskell revival team know about it. So it's moving!
wxC and SWIG
SS on the wxc list has suggested we switch from handwriting our wxC stuff to autogenerating it with SWIG. It's been interesting discussing with him. Learned a bit from the process, and got a reminder (duh) that wxC is actually C++ code (of course, what else would it be?), only that it behaves exactly like C code on the outside. Anyway, long term project's looking interesting. SS says that given enough configuration, we should be able to generate the wxC code directly, even including the kind of annotations that wxhaskell needs. But we also agree that this kind of thing is for the long term. Short term priority is to get the new wxhaskell and wxc out the door!
wxhaskell / wxC
No comments:
Post a Comment