another-acct
No user record in our sample, but another-acct has activity below (stories or comments). Likely we have partial data — the full bulk-load will fill profiles in.
No user record in our sample, but another-acct has activity below (stories or comments). Likely we have partial data — the full bulk-load will fill profiles in.
> 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 help.
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) }
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,…
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…
> 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…
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.
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…
> 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…
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 "foobar" branch is what…
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…
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…
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…
> 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…
> 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…
... 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,…
> 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…
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,…
> 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…
> 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…
> 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"…
> 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…