I will probably write a “More Rich Command Shells” to cover things I missed here that are important in some way (like Apple’s MPW).
The next thing I want to write though is about building something that has a command shell UI today and thinking about how to do so in a flexible way that works with multiple output devices.
I have started using IHaskell quite a bit at work. We have a wall display where I keep my notebook up with some graphs. Our product managers have started to rely on it a lot.
Programs use pipes with a high level drawing and event model to communicate with an ezdraw window. The implementation is Scheme and the protocol allows dropping down to Scheme expressions.
e.g. a shell script for a monitor color calibration utility…
ezd -p <<END
(window vr297help 20 5 400 400 "VR297 Adjustment Instructions")
(set-drawing help)
(overlay vr297help help)
(text 10 30 "Turn contrast control to maximum position. Set H-STAT")
.
.
.
(rectangle 475 375 80 80 blk)
(text 475 375 80 80 center center "R G B" blk "9x15")
(object clear (fill-rectangle 0 0 1000 1000 clear))
(click clear 1 (ezd ’(quit)))
END
The last line saves the ezdraw window as a postscript file.
Graphical objects in the window can be made interactive without involving the application. For full control though, events can be piped back to an application like this:
Winterp is a more of a traditional high-level Lisp library for applications. The main distinction is that it uses xlisp, a lightweight Lisp interpreter, that can easily be linked into an application. screenshot
As I posted on HN:
I will probably write a “More Rich Command Shells” to cover things I missed here that are important in some way (like Apple’s MPW).
The next thing I want to write though is about building something that has a command shell UI today and thinking about how to do so in a flexible way that works with multiple output devices.
I have started using IHaskell quite a bit at work. We have a wall display where I keep my notebook up with some graphs. Our product managers have started to rely on it a lot.
Can you post a photo? (Maybe blur out the proprietary stuff).
I mean to take one but forgot. Sorry! I’ll make sure to get one on Monday.
I hoped to see xiki, but looks like the post is python-centric mostly
Xiki is perhaps interesting… I hadn’t heard of it and only took a brief look so far.
My post wasn’t Python centric at all though. I think only iPython was for Python of all of the things I mentioned?
I am in the mountains in Thailand this weekend with poor and very slow internet access.
I don’t think the intent was to be python-specific. xiki is a good example of the general topic.
A couple of lightweight lisp-based systems from days of yore… winterp (xlisp) and ezdraw (scheme).
Since I am out and about… Would you be able to find a good example set of screenshots of those, some documentation, etc?
I am considering a follow up post still to mention anything really important that I missed…
Joel Bartlett’s “Don’t Fidget With Widgets, Draw!” 1991 tech report: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.45.4520 describes ezdraw.
Programs use pipes with a high level drawing and event model to communicate with an ezdraw window. The implementation is Scheme and the protocol allows dropping down to Scheme expressions.
e.g. a shell script for a monitor color calibration utility…
An application profile can be graphed from a profiler by piping something like the following to ezdraw:
The last line saves the ezdraw window as a postscript file.
Graphical objects in the window can be made interactive without involving the application. For full control though, events can be piped back to an application like this:
Winterp is a more of a traditional high-level Lisp library for applications. The main distinction is that it uses xlisp, a lightweight Lisp interpreter, that can easily be linked into an application. screenshot