scsh next steps
Roderic Morris <[email protected]> Wed, 12 May 2010 20:00:01 -0700
| Newsgroups | gmane.lisp.scheme.scsh,gmane.lisp.scheme.scsh.devel |
|---|---|
| Message-ID | <[email protected]> |
Hey everyone, I've made a list of some of the things that need to be done for new scsh, to get it to a useful state. Any advice, comments, code, or other form of help you can offer related to them would be appreciated. - Move everything to S48 ports. Scsh's ports were built on undocumented internal s48 apis that've since changed. I don't know how to reimplement them properly with the new apis, and figuring that out would probably take quite a bit of time. I think the best way forward would be to ignore the port relieving machinery for now, and simply use s48's fd-ports everywhere. The ops that are broken because they rely on scsh ports are more essential than that feature. - Implement port revealing mechanism on top of S48 ports if possible. I haven't looked into it yet, but since scsh exports its own open-file and all the other ops over ports, I think it could do all the book keeping necessary for this, and hopefully a new type of port wouldn't be needed. - Move to autotools & fix platform specific code. There are a couple of places where I've hardcoded Linux specific values for now, so I could get rid of the platform specific directories. I think a better solution than those directories would be to do what s48 does and simply get the values from C. This'll require a bulid system though, and in the interest of portability, autotools would probably be the way to go. - Get command line options working. I haven't looked into this much, but it seems "-s" is the only functioning option. The apis that top.scm (does the command line parsing and startup stuff) uses have changed quite a bit, so it'd just be a matter of learning them and making the necessary changes. - Set up proper hosting & bug tracking. - Documentation, including a listing of what's changed.