I bought the app, and I'm really happy with it, thanks!
I know it's a long shot, but some sort of shell integration would be awesome. My typical day is > 60% iTerm2. iTerm2 has shell integration: https://iterm2.com/shell_integration.html, and maybe that would be one way is something that Qbserve could be fetching info about what's going on in the terminal.
Yes, and that the nuances of how things are formatted are really not that important, but rather having a standard which provides a consistent reading experience is the important aspect.
I agree completely with this. After fighting over code formatting for so long (often starting those fights myself), I have thankfully come to realize that what format you use almost never matters, only that you use some standardized format.
I think that's one of the best contributions golang has made to the programming world. The idea that the language itself should be easy and unambiguous for the compiler and the human to parse. And that a single formatting standard makes life easier for everyone.
If we ever move beyond using text files for storing code, we could eliminate formatting differences entirely... but efforts in that direction have run into many issues in the past.
Except the go standard is awful, so a language-wide formatting requirement with bad defaults makes the language basically unusable (since programs are made to be read, not run).
Rust does something similar. It doesn't allow for brace-less clauses and it also bitches and moans at you about 'miss-using' camelCase, snake_case, etc. Which is great because it means that by default all project will follow a similar mark-up.
I thought that the go compiler would throw an error of your code is not in the format produced by gofmt. You don't need to use the tool, but you need to have your code in the same format that the tool would produce.
Nope. The gofmt-contract is a purely social one. But it's one held by nearly the entire go community which probably gave you that impression for good reason.
> gcc seems to use a fixed size "pool" of mutexes attributed to a shared_ptr according to a hash of its pointee address, when dealing with atomic operations. In other words, no rocket-science for atomic shared pointers until now.
A side effect of the shared pool is that you might have two totally unrelated pointers share the same mutex, leading to surprising locking behaviors. Something to keep in mind.
As I explained in a commentary:
As far as I understand gcc implementation. In a pseudo-code it would be:
Mutex mutexes[SIZE_OF_POOL];
int hash(void* p)
{
...
}
std::shared_ptr<t> atomic_load( const std::shared_ptr<t>* p )
{
int r = hash(p);
lock(mutextes[r % SIZE_OF_POOL]);
return *p; // Safe copy of p.
}
All the other atomic operations (store, etc) use the same lock pool, so it should be fine for the copy!
If you want to take a look at gcc's implementation:
Yes, that's my understanding of the implementation as well. I was commenting on the fact that you might have two totally unrelated p1 and p2, where (hash(p1) % SIZE_OF_POOL) == (hash(p2) % SIZE_OF_POOL), that will end up sharing the same mutex.
Yes definitely tricky. It might give a heart attack to some high frequency system designers! I will investigate this topic in future: maybe someone can come up with a spin-lock or lock free solution.
