Can you redefine compinit to a no-op during OMZ loading, and then do it yourself at the end?

IMO zshrc should explicitly call compinit so it happens exactly once in a central location.

A shaded executable jar is useful but not sufficient if you want to e.g. start the service on boot. So there’s some value in having an actual .deb. I was somewhat surprised by this approach when I first joined that company but it worked well in practice.

This is a personal and debatable opinion unrelated to C, but I find giant files to be unreadable from a diving-in-a-new-codebase standpoint. I consider it a good engineering practice to separate logical units in distinct files. The author has another project which does this: https://github.com/vurtun/mmx .

I think there’s a balance between micro and humongous source files. An analogy with writing, think about having paragraphs of one line versus one giant paragraph, you want neither.

With respect to my colleague here, it’s not actually a dealbreaker.

In fact, with the lack of a standardized package manager and build system, for C and C++ projects it is often preferable to simply have a source file or two for a neat feature. Other options are generally:

• Rely on the system headers and libraries to exist/be the correct version (via aptitude or whatever)
• Bundle the full source files in a lib/vendor directory and tweak the build system to build them too if needed (for say dynamic libs)
• Carefully package up the library headers and static libs, and hope you’re building with the correct versions (architecture, debug settings, linkage, etc.)

And then there is the joy of trying to actually step-through that garbage when debugging.

Or, you can just add a big honking header file like this, and move along–though I think it would’ve made more sense for it to be header+single source file. In this case, builds look normal, debugging is the same as for your own code, and everything can be simpler.

Theft is great (sentences to take out of context…) but the major problem with it is that it doesn’t come with any sort of library of data generators or shrinkers, so it’s extremely DIY. Most of the work in doing this sort of thing is writing those generators and shrinkers, so it really helps to have a pre-built library of them rather than having to roll your own.

I’ll grant that rolling your own is very in the spirit of the language, but I’d still rather not do it if I don’t have to and I’m probably as close as it gets to being an expert in the subject. :-)

I did look into theft. But this is where I find scripting language much more pleasant to work with. Hypothesis comes with automatic ‘reduction’ functions, while in theft you have to implement all of this.

Writing the equivalent testing functionnality with theft would have probably taken as much code as the testee’s code.