forked from willghatch/racket-rash
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathTODO
175 lines (113 loc) · 13.5 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
If you want to help, there are various things you might do:
* One thing that would be helpful regardless of your level of ability
is documentation help. I wrote most of the docs in a hurry and they
aren't very good. You could read them and let me know what doesn't
make sense, or edit them and send pull requests. All the examples I
used were sort of stupid things I pulled off the top of my head that
aren't really compelling. So if you think of some good examples
(eg. useful pipelining, especially mixed pipelines of external
programs and racket functions) that would be great.
* Testing! I have written very few tests. Tests that use external
programs are somewhat difficult because they rely on the
environment, they can't be run in the sandbox provided by the
automated test servers (though this basically just means there
should be a directory of tests that the auto server won't run and
that I (or other contributors) can run locally), etc. But I've been
planning on making a directory of tests that use common unix tools
that should be generally available, and having them do operations in
some sandbox directory and check that they are correct.
* You can look through the TODO files in the repositories ( IE
https://github.com/willghatch/racket-rash and
https://github.com/willghatch/racket-shell-pipeline ) or grep for
"TODO" in the code base and see if there are things you want to try
working on.
* You can report any bugs you find.
* You can raise issues for things that you dislike or find weird, or
features that you want that are missing. One reason I have said
"it's not stable yet" aside from some missing features is that I
want a space to collect feedback for general improvements before a
stable release.
* You can try writing some interesting pipeline operators (requires
some macro know-how, so it may not be the best project if you're new
to Racket). You could also just think up pipeline operators you
would find convenient or useful and tell me about them.
General Todos (written more for my memory than for something readable by others)
--------------------------------------------------------------------------------
* unix pipeline member argument generalization of env -- run code in thread to change dynamic environment in any way (this makes env easier -- have &env *only* extend/override, and if you want to reset the environment you can use the generalization)
* have lexically scoped defaults for all pipeline options, similar to how the implicit starter operator works
** the forms for setting these (eg. the rash macro) should be able to set a new default for each or fall back to the current lexical default. I guess there should just be a syntax parameter for each. But should they be publicly available as syntax parameters or wrapped up in some api like the rash macro setting it or something?
* optional kw-args for rash macros that affect read tables, macros to define rash macros and rash-module-begin with different defaults for all options including read table options
* maybe make it a syntax error to have a normal racket expression [IE starting a line with an open paren] have a pipeline later on the same line. This will clear up any issues with having the first segment of a pipeline open with parens.
* review names -- pick good ones before doing any stable release
* look through TODO comments
* better drracket integration
** fix interactions window -- it was working (though not great) before but then I broke it.
** write a lexer for coloring, maybe
* make #lang rash/bash-env or something that uses bash syntax for environment variables and aliases
** it will be nice just as a configuration bridge so you can share a fair amount of config with bash
misc
----
* option-app -- needs better name (kw-check-app?), and should it be part of another package? I think I want to use it in more packages...
About interactive shells
------------------------
* job control -- see TODO file for shell-pipeline package.
* discoverability
** the default prompt should help with discoverability -- maybe say the command to get help, look up docs, etc. Something like «type HELP START» in LoE.
** how can interactive features be more discoverable than just being listed in the docs/tutorial?
** in the short term this probably doesn't matter much, but long term it would be nice.
Documentation
-------------
Maybe at some point there should be a section for Racketeers unfamiliar with Rash or shells in general, and a section for people familiar with shells to but unfamiliar with Racket.
Line Editing
------------
For now I've got racket's readline FFI library working for OK line editing.
In the long term, what I really want is an emacs in racket that can be used as the line editor. Specifically, I would want an emacs-style extensible editor where the buffer objects and editing commands are not tied to any sort of display, such that they could be connected to different displays (even more flexibly than GNU emacs with its ability to be used with curses/terminal version and a gui version). Then one such display could be a line-editor style display that just lives in the bottom lines of a terminal, but still give full emacs buffer style editing to the code in the line (or lines -- obviously it should have real support for multi-lines) that you are editing. The editor would be connected to your repl evaluator and be able to talk with it to determine information about the code in the buffer, do various different types of completion on it, know whether it is a valid command/whether it parses, etc. Of course then you could also make a curses-style interface, and a gui interface, and maybe (hopefully!) even embed it to be the editor inside DrRacket (and in other GUI racket programs that have text editing fields). Then you could, among other things, have custom editing commands, keymaps, editing modes (a la vim), etc all set up in one place and used in your shell, in your stand-alone text editor, editing fields in other programs, etc. Several people have talked about wanting an emacs in Racket. It would be a big project. If nobody else makes one I can definitely see myself doing it (a basic version, at least), but it's not really at the top of my priorities right now -- I need to do things like, say, work on my PhD. So I don't see this happening terribly soon.
However distant it may be, you really want this sort of thing in your shell. The only major difference between bash and zsh, for instance, is that zsh has an emacs as its editor. And that makes a world of difference. Zsh has many more and better programmed completions available. It has many really useful plugins (eg. zaw -- it's like helm in emacs). It's why so many people love zsh so much when as a language it is essentially the same as bash. But while it has an emacs, you have to do all the extending in (*gulp*) zsh itself... so plugins for zsh are rather limited by the implementation language. Wouldn't it be great if the extension language for your editor were... any language in the Racket ecosystem? Yes, it would.
Bugs
----
* `(rash «ls»)` at the top level of the repl acts like `ls` at the top level of the repl, which is wrong. The in/out/err options are set by splicing-syntax-parameterize. Is there a bug in how I set that up?
TODOs merged hastily from shell-pipeline's previously separate repo:
* option for shared stderr string capture or individual ones. Per unix-y section, at least.
* improve dollar-expansion -- eg. maybe don't always expand to a string, so I can use $funcname at the head of a unix pipe for unix-style functions in pipelines.
* mixed/pipeline pipeline-kill
* pipeline send signal? eg. to send sighup when rash is killed so that some programs (eg nohup) can decide whether or not they should die.
* Better API for redirection settings in basic and mixed pipelines
** specifically, how to tell it truncate/append/error
** how to tell it you want stderr as a string-port or shared-string-port
* good API for setting defaults
** all default values should have syntax parameters that are either exposed as such or have a nice API for setting their values, and they should probably all live in one file in private/
*** specifically these include the defaults for in/out/err, the default pipeline starter, the default truncate/append/error behavior for out/err, default strict/permissive/lazy correctness, lazy-timeout,
* option for code to run in manager thread before running members in order to modify parameters - IE generalization of modifying env for all members.
** environment variable / generic thread environment mutation per-member as well
* process fd/temp-file redirects a la <() >() from bash
** Probably I want a flag struct for each. The struct will contain a thunk that will evaluate to a file name (for <()) or will take a file name (for >(), the pipeline running mechanism will have to give it one).
** Unless it's actually backed by FD, the output process will have to finish before starting the input process, and pipeline waiting will have to wait for the sub-pipeline stuff as well...
* I should probably provide a standard wrapper for the run-pipeline macro that detects some AND and OR identifiers and splits into multiple run-pipeline macros that automatically turn on pipeline-object-return
** I should probably also change the option for returning the pipeline object to take an argument rather than being just a presence-only flag...
* inspecting pipeline segments with correct compound member handling
* add a set of symbols that the output-transformer can translate into common-case functions -- 'string, 'trim, 'lines, etc.
* look through TODO comments
* a version of pipeline-macro that doesn't have all the overhead (maybe one that doesn't allow unix-segments)
** maybe it's not terribly important, because it would be doing mostly the same thing as the threading macro, but it would be more flexible -- eg. =filter=, =for=, etc are nice, especially if they have short names.
** =object-pipe= should have a keyword argument that sets whether it auto-converts ports, and the default is a syntax parameter that the efficient vs convenient rash macros can set accordingly. Also, this allows the one-off occasions when you do want to do the opposite, without requiring a different =basic-object-pipe=
** obj-pipeline-spec, unix-pipeline-spec, and composite-pipeline-spec should be syntax parameters that are also set by the outside macro, basically determining whether they produce runtime pipeline objects or if they desugar to the fast path that has no process or thread overhead.
* I want to have a macro to define a first class pipeline segment (IE a compound-pipeline-member, but one that is always a joint and not a starter). Maybe a compound-pipeline-member can be called as a function, which takes one argument and shoves it into the pipeline?
** how will this interact with the trimmed-down version of the macro from above?
* Currently each object segment runs in its own thread, but maybe they should always run in the manager thread instead. That way they can eg. mutate the environment, and that can be an easy way to implement whole-pipeline environment changes. Also it will lower threading overhead. However, it is the way it is currently so that the manager thread can (in some future day) catch a signal to suspend for job control.
less important TODO items, which may wait until version 2
---------------------------------------------------------
* bg issues
** what does it mean to run with stdin in the background unless I have job control?
** maybe the default input port should be allowed to be some function that determines what input it gets based on things like whether it's in the background or not?
* a custom exn type for unix pipeline failures?
* Pipeline suspend/resume -- Threads have pause/resume, Unix processes have sigstop/sigcont, but I'm not sure how to pause/suspend windows processes. Maybe a Unix-only feature? But this is a pretty standard shell feature for job control.
* job control -- for an interactive shell, how should the shell capture references to the pipelines to do job control?
** importantly, currently the repl is still the foreground process of the terminal when you press control c or control z, so it gets sigint or sigstop even when you have launched eg. vim
** I need to set a pipeline to all have the same process group ID that is different than the pgid of the host shell. Right now I can either let them all keep the pgid of the shell or give each of them a different pgid. Anything else would require changes to the subprocess API in the C code of Racket.
** I need to use `tcsetpgrp` to set the foreground process group on a terminal, to control which processes get sigint/sigstop signals from C-c and C-z.
** I maybe ought to do some signal handling setup of the subprocesses also, for sigtou, sigtin, and maybe I need to specially handle sighup and sigterm in the shell repl?
** When Racket gets SIGHUP the main thread generates exn:break:hang-up, and for SIGQUIT it generates exn:break:terminate. So a handler around the main repl loop can propogate SIGHUP to any jobs (except disowned ones) and quit gracefully.
* bg pipeline disowning?
** This is really only reasonable for external-proccess-only pipelines, and I'm not sure how reasonable it is on Windows.
* ulimit and other resource limiting things for subprocesses and pipeline threads -- how can I go about doing that?
* initial input-port transformer to try to solve readline-port issues -- there doesn't seem to be any way to get the real stdin port from the readline port, so this is hopeless for the moment.