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.