What are /r/oilshell's favorite Products & Services?

From 3.5 billion Reddit comments

Right, makes sense. I've written a nix expression for building osh from the tarball and it seems to work — nixpkgs should also provide some nice testing, as 99% of the actual build scripts are bash and I can just substitute osh for bash in all package builds quite simply.

The first blocker (of many, I suspect!) I've run into on it is that declare -a doesn't work (you already knew that though) and that the parsing just throws the entire script at you if it fails to parse a sourced script (which made finding out that declare -a was the culprit a bit harder!).

Would it make sense to add a rule for _devbuild/cpython-full/python that runs the prepare.sh command and have the app-deps steps depend on that? The whole build process (for building from the git repo) as it currently stands seems to involve a lot of non-obvious commands.

Yes absolutely! Header files are IDLs for binary interfaces :)

COM took that to the next level. It has problems but I think there is some value there.

I wrote about that here, and the rest of the thread has some interesting comments about Win32 being the most stable ABI for Linux games! I'm not in the gaming world but that's apparently a recent evolution / popular opinion.

https://lobste.rs/s/ljsx5r/flatpak_is_not_future#c_upxzcl

Haha ... Well the point is to say that "models" often collide with reality. And some people's entire job is to deal with reality.

When models and reality collide, reality wins :)

That is sort of how I viewed my jobs, although I never had the title SRE or similar. One thing I frequently point out is that SREs started to make more money than SWEs in the last 10 years, at least in my neck of the woods, which was Bay Area tech... That salary bump had to do with having to understand BOTH "the real world" and the models (how the programmer thought things should have worked, but they didn't.)

Comments here: https://lobste.rs/s/qtbxqf/oil_dev_log_7_hollowing_out_python

ANd here: https://www.reddit.com/r/ProgrammingLanguages/comments/9xj8u4/oil_dev_log_7_hollowing_out_the_python_interpreter/

Nice examples! I hadn't thought of that tee idiom.

Oil will provide a way to do everything that bash does -- it's just a matter of how "pretty" the syntax is. The goal is to convert from OSH to Oil automatically [1], which places some constraints on the syntax.

So I might just provide exec literally for compatibility, but discourage it and provide nicer ways of doing the same thing.

For the second example, I'm thinking there will be a C-ish / Python-ish API so you can have multiple file descriptors open with a sane syntax:

https://lobste.rs/s/bqftd6/avoid_directly_manipulating_file#c_dfktuu

Thanks!

[1] http://www.oilshell.org/blog/2017/02/05.html

Wow, with amazing timing: https://lobste.rs/s/vwhaig/configuration_files_suck

Particularly interesting link from there: http://www.haskellforall.com/2016/12/dhall-non-turing-complete-configuration.html

Many :) But Bazel and Ninja aren't really comparable, or only partially overlap. I talked about this here:

https://lobste.rs/s/bqjhuv/fac_build_system/comments/brdw0p#c_brdw0p

There is a separation between high-level and low-level build systems. Ninja seems to have gotten things right -- it's entirely focused on incremental build speed, and it's also portable to Windows -- so it is becoming the de-facto standard low-level build system.

The high level systems have not converged, maybe because they are more like programming languages and have diverse requirements. You have:

• Chrome: Used to be Gyp to Ninja; now is GN to Ninja. Gyp was more like JSON, and GN is more like code, but it still shies away from loops ("Turing completeness").
• Android: Used to be GNU Make, could have been GNU Make -> Ninja, now appears to be Soong/Blueprint/Go -> Ninja
• LLVM: CMake -> Ninja. Ninja generation in CMake is pretty new; as far as I know it did GNU Make, .vsproj, XCode, etc.
• Bazel has it's own build executor written in Java. But I think people have talked about compiling its config/Skylark language to Ninja as well.

I guess it is obvious that I would like oil to be a high level build language (which GNU Make is as well, since it's Turing complete). Since I'm done with developing on Windows, compiling to Ninja is perfect. But this is all vaporware since I still have to release oil and bootstrap it out of Python :)

Thanks for oilshell!

I've a few candidates that might pose good challenges:

• bashforth: https://github.com/Bushmills/Bashforth. osh complains about declare -i and left-hand assignment like (($1 = foo )).

• bashtop: https://github.com/aristocratos/bashtop . After commenting out the guard for bash 4.4, /bashtop:158: fatal: Associative array keys must be strings: $x 'x' "$x" etc.

• I was thinking if the nix build system (that relies on bash AFAIK) would be something to aim for as in THE MOST COMPLEX BASH SYSTEM EVER. I'm no nix expert, but I think it assumes bash.

I'm trying those with osh ./bashforth . Is it the correct way?

Sorry if I'm doing anything wrong from the start, I couldn't follow oil so closely lately.