I have a lot of praise for using Memray as part of working out some memory kinks in a codebase I’m working on. It allowed me to quickly iterate on some hunches and then enshrine the resulting memory savings in tests via pytest-memray.
Other spreadsheets solve this by updating references if you need to add more columns and rows (or at least they try). Is the additional complexity of the infinite grid something that customers actually need?
To combat this scenario, we only had build servers populate the cache. Clients were readonly to the cache, so they would benefit from anything that build servers had already built, which covered 95%+ of what clients usually had to rebuild.
Also release builds were excluded from caching, to prevent any form of poisoning there.
My room was next to said bathroom with rather thin walls, so I always appreciated the sound at least be a bit played down by the music.
Another side effect was that you always knew when the bathroom was in use (aside from someone forgetting to turn the light off, which you now had radio playing to remind you off).
My parents just had the radio hooked up to the same circuit that was driving the bathroom lights. You enter the room, turn on the lights and there was instant audio. Makes sense to put this into a product.
Good post to plug the documentary "Tim's Vermeer" ( https://www.imdb.com/title/tt3089388/), which is a joy to watch as they try to reverse-engineer the particular style Vermeer painted in.
Both standard library and other libs make use of them, so you often can't just ignore exceptions.
Also agree on your point - I'm not saying I like exceptions, I like explicitly passing type-encapsulated results/errors more for clarity. Exceptions happen in a "second invisible lane" right next to the code you are writing, and for example aren't immediately visible when reviewing code.
1. no
2. no, not really - however there may be libraries that python has that ruby doesn't have
Side note: Ruby has more syntax to grok, which makes it harder to read (for me). On the other hand Python does have its own idiosyncrasies and subtle behaviors. However, Ruby also has some features (like multiline inline functions) that one may easily miss in Python, but they haven't been worth switching over for me.
> The noexcept specifier protects C++ program from memory leaks and potentially other undesired behaviors brought by throwing exceptions.
While I agree with the presented observation, just letting the exception bubble up to the top would have done the same thing. The memory leak presented here is just the result of not using RAII to clean up the resource.
Throwing an exception through a `noexcept` function terminates (or rather calls std::terminate) because you are doing something you explicitly said you wouldn't do, pass an exception through this function.
> For key functions we hardly know how to handle its exceptions, it might be a good idea to add the noexcept specifier.
On the contrary, `noexcept`s usecase is in places where we want to be sure a function doesn't just throw an exception, as this may thwart some guarantees we want to make to the caller. Sprinkling your functions with `noexcept` just to abort (which is already happening if the exception is unhandled) is bad code. Plus "we hardly know how to handle its exceptions" is the worst cop-out I've heard for dealing with exceptions - C++ exceptions are an essential part of the language and many libraries, so dealing with them should be a prime concern of the programmer.
Having gone through writing a couple of iterations of these, I went back to settling on `PATH="./scripts/:$PATH"`, which in my project root dirs (where I spend 99% of my time anyway on the shell) just works.
Sure, this could be augmented with per-folder environments, fancy runner syntax, but less is more for me in this regard.
Ninja update: Anyway, I like what OP is doing here, seems like a lot of things are done right in this. :)
There is a good amount of research on software engineering, I love love love "Making Software: What Really Works, and Why We Believe It" by Andy Oram, as it demonstrates the non-opinion-based way of thinking about software engineering. And has some really interesting insights to boot.