Why Sponsor Oils? | blog | oilshell.org
I plan to release OSH 0.5 next week! This post is an update on what's happened since the last release.
In late March, I wrote a post to relieve myself of Oil-related "duties" while attending the Recurse Center.
But a few things happened in the meantime, and I ended up working on Oil a lot:
Guido van Rossum tweeted about my project [1], which attracted new contributors. I kept my promise to review their pull requests quickly.
I'm embarrassed that the resulting commits have been sitting unreleased in the repo since May, but I'll fix this shortly.
Pair programming is a core part of the Recurse Center experience. It turned out that many people were interested in pairing on Oil, so it was natural to work on it. You'll see this in the release notes.
After the handling the logistics of traveling and housing, it felt good to work on Oil, rather than something more speculative and unfamiliar.
In the same post on Recurse Center (abbreviated RC from now on), I wrote about these subprojects:
sh -x.I've decided to focus on two of these projects. They address the main problem I see: that OSH is basically a slower and less featureful version of bash right now!
While I've built a solid foundation for the project, I'm not surprised that it doesn't have regular users. I want to change that in the coming months.
This is a "carrot" for OSH, or at least a candidate for one. (The Oil language is still the main carrot, but it's a longer-term design and implementation effort.)
Before leaving for New York, I prototyped a web-based shell trace tool with my friend Eric.
I conjectured that we could use bash as the client, rather than Oil. I
came up with some horrible hacks involving the $PS4 variable, which controls
the output of sh -x.
This led to a working demo, but I'm not sure how successful this experiment was. When I get back to San Francisco, I plan to release it and solicit feedback.
The OPy compiler is necessary to turn OSH into a "production quality" shell. It's a risky and unusual implementation strategy, but I'm optimistic based on the progress so far.
I haven't worked on it too much this summer, but I had some realizations based on conversations with Darius Bacon, who wrote one of the articles I mentioned here:
Compiling to C code is probably easier than compiling to bytecode and writing my own VM. It's more direct, and will solve the "double interpretation" problem.
There's more than one way to compile a subset of Python to C code. PyPy compiles a control flow graph to C, but higher-level translations are also possible.
The C code strategy and the bytecode strategy have a lot of work in common, so I don't have to choose between them now.
For example, Python 3.8 will remove the BREAK_LOOP and CONTINUE_LOOP
opcodes and express them in terms of jumps. I want to reproduce this
change in OPy. It's useful whether we compile to bytecode or native code.
(Python issue; credit for bringing this to my attention.)
My time at RC has given me many ideas for blog posts, which fall in these categories:
I'll sketch these ideas in the next post.
[1] I e-mailed Guido about his recent blog
post on
pgen, the bespoke parser generator that powers Python. (Oil uses pgen2,
the Python port of pgen.)
Among other things, this conversation clarified that "regular expression" with
respect to pgen refers to EBNF iteration syntax like + and *, as
opposed to the recursion of plain BNF.
Related: other posts on #parsing. I've written a lot about parsing shell, but parsing Python is interesting too.