Why Sponsor Oils? | blog | oilshell.org
I attended the Recurse Center for two main reasons:
I feel like the trip was a success on both counts. Read on for details!
I could write at length about what I did for the last three weeks at Recurse Center, but this video demonstrates it more concisely:
The idea is to visualize four-dimensional geometry with raytracing. I studied these ideas over 15 years ago, but I didn't have the programming skills to do anything interesting with them.
Happily, shell scripts helped us complete this project! It took ~500 lines of shell to coordinate ~1100 lines of Python, the PBRT renderer, ImageMagick, ffmpeg, and a few other components. The rendering was distributed across 66 cores on 3 machines.
I explain this further in the README.md of the pbrt-video repository. I also wrote about the math involved.
Aside from using shell scripts, I stretched myself in a few other ways:
Feel free to ask me questions about this project or about the Recurse Center.
I didn't take a full break from Oil this summer: I worked on it with others and even made a release.
But the break was enough to renew my enthusiasm for the project!
I just released OSH 0.6.pre1:
It's almost identical to OSH 0.5.0, but I ran the benchmarks on my personal machines instead of Recurse Center machines. (A side benefit of RC was forcing me to fully automate and decouple the release process from particular machines.)
I want to make more frequent Oil releases going forward, and I plan to number them as follows:
0.6.pre1
0.6.pre2 # a regular time-based release
0.6.pre3 # could be a few weeks later, or even a day later
...
0.6.0 # When enough significant functionality has piled up,
# change the last digit to 0.
0.7.pre1
0.7.pre2
...
0.7.0 # More significant functionality.
0.7.1 # A patch release fix a bug.
# Patch releases are not likely before 1.0.
I think this scheme is nicer for frequent releases. I just finished re-reading the Cathedral and the Bazaar, and more than one passage made me think about Oil.
In the chapter Release Early, Release Often, there's an anecdote about the release cadence of Linux:
In those early times (around 1991) it wasn't unknown for [Linus Torvalds] to release a new kernel more than once a day!
In the chapter The Importance of Having Users, there's an assertion about parallelizing software development:
Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
Caveat: I'm not sure how parallelizable Oil development is due to its unusual metaprogrammed style, but I welcome comments on this topic.
In any case, it can't hurt to release more often, and the new numbering scheme facilitates that.
It's time to write another project roadmap, but now that Oil has more contributors, this should be a conversation rather than a pronouncement in a blog post.
Zulip is now the place to discuss Oil. Please join oilshell.zulipchat.com if you're curious!
There are a number of priorities to juggle: