another-acct

4 ms·

1.
by another-acct 2y ago
> C, a useless language without effective scopes Mutexes can be handled safely in C. It's "just another flavor" of resource management, which does take quite a bit of discipline. Cascading error paths / exit paths hel
2.
by another-acct 2y ago
Might want to move foo.add() out of the lock scope (assuming foo is a thread-private resource): value = nil lock { if (data.size() > 0) { value = data.pop() } } if (value) { foo.add(value)
3.
by another-acct 2y ago
I think it's fair to comment not only on the subject, but on the writing itself, too. And it might help Justine improve her writing (and reach a larger audience -- after all, blog posts intend to reach some audience, don't the
4.
by another-acct 2y ago
This is how it should be. IIRC -- apologies, can't find a source --, Ulrich Drepper wrote somewhere about NPTL that its mutexes were not particularly lightweight, but that you should design your program for low contention anyways. For
5.
by another-acct 2y ago
> remove locks from code and replace with some kind of queue or messaging abstraction Shared-nothing message passing reflects the underlying (modern) computer architecture more closely, so I'd call the above a good move. Shared memo
6.
by another-acct 2y ago
Agreed; this is what I've always (silently) thought of those fat binaries. Absolute stroke of genius, no doubt, and also a total abomination (IMO) from a sustainability perspective.
7.
by another-acct 2y ago
I also meant to comment about the grandstanding in her post. Technical achievement aside, when a person invents something new, the burden is on them to prove that the new thing is a suitable replacement of / improvement over the exis
8.
by another-acct 2y ago
> or just want to experience and enjoy my excellent (and occasionally eclectic) taste Thanks for the good laugh :) Seriously though, your CV is impressive. I hope you'll land well, and quickly. In my (very recent) job hunt experienc
9.
by another-acct 2y ago
> For me, GitHub PR review drives me crazy. It's good for exactly one round of exchange. After that nobody can tell what the heck is going on. Matches my experience totally. It devolves into a heap of garbage. In comparison, with (i
10.
by another-acct 2y ago
Whenever you force push v2, v3, v4 of your branch called "foobar", you can also push branches called "foobar-v2", "foobar-v3", "foobar-v4" (pointing to identical commit hashes, respectively). The &q
11.
by another-acct 2y ago
IMO you are spot on. GitHub's worst sin is that it has mis-educated new generations of developers. My 16yo son uses github every day; I've needed to explain fetch + rebase to him several times. It just doesn't seem to stick;
12.
by another-acct 2y ago
Agreed 100%, and it's hard to believe how many corporate software developers actively resist this concept. Once the code works, many refuse to invest any time into properly restructuring it for presentation (review) and for posterity (
13.
by another-acct 2y ago
This is the comment I've been looking for! :) High-five! Some remarks: > - The next version is a reply to the previous cover letter Not necessarily; sometimes the new version is not posted in-reply-to anything, but the cover letter
14.
by another-acct 2y ago
> I agree in general, but running git bisect on individual PR commits is just doing it wrong. There will always be commits that break stuff temporarily. That's unacceptable in my book. Before submitting any patch set for review, the
15.
by another-acct 2y ago
> mail based workflows shine as reviewer is more encouraged to apply the series, compile/run it in their env not to mention: if the reviewer does this for every version of the posted series, on appropriately named (versioned) local
16.
by another-acct 2y ago
... Another thing that mailing list-based development gets right ;) Most MUAs should know about a concept called "Drafts". I can have as many draft messages concurrently as I want, I can work on them over several days, and I can s
17.
by another-acct 2y ago
> GitHub is [...] not very reviewer or team friendly though The problem is that reviewers / maintainers are much scarcer than contributors. Workflows and UIs should optimize for reviewer throughput, IMO. (I've never used the th
18.
by another-acct 2y ago
On a mailing list, you used to be able to write up the big picture in the "cover letter" (patch#0). Design-level discussions would generally occur in a subthread of patch#0. Also, once the patch set was fully reviewed, the maintai
19.
by another-acct 2y ago
> GitLab [...] compares different iterations of the force-push "naively", so if your force-push includes for example a rebase onto master because another MR has been merged ahead of yours, the diff will include the changes that
20.
by another-acct 2y ago
> have feature branches that get squashed into a single commit (erasing the history of the branch) Terrible. It makes git-blame and git-bisect essentially unusable. If you have a regression, git-bisect can help you narrow it down to a si
21.
by another-acct 2y ago
> Because it was under 1000 layers of other bullshit Not only because of that. git-range-diff, while absolutely a killer feature, is a relatively new feature of git as well (a bit similarly to "git rebase --update-refs" -- whic
22.
by another-acct 2y ago
> all the actual details of using email are, I would estimate, about 1,000x shittier in 2024 than using GitHub in 2008 Disagree about "all". Tracking patches in need of review is better done in a good MUA than on github. I can