So I've actually thought about this a fair bit recently, since I'm making some changes to C++ code that touch a lot of files in reasonably straightforward ways. The changes should be possible to merge conflict-free in basically 100% of cases, but since so many lines are touched, no VCS merge tool can manage it. Most of my changes are just typenames, so I figured, you could do some sort of AST-based merge to allow those changes to merge with semantic changes to the surrounding code.
But this has a lot of problems. Namely - most of the time, when two people change the same line, the changes really do conflict, and someone really does need to manually merge them. In fact, sometimes even when your VCS merges things happily, it still gets them wrong because two changes conflict semantically but don't touch the same lines.
So I guess I would say, I think merging is an impossible problem to 'solve', and going to a more granular merge strategy is actually a move in the wrong direction. You could maybe fix my particular case by 'whitelisting' those typename changes, and saying 'these are allowed to merge with anything else', but at that point... the effort required to specify that unambiguously and make it work properly is probably higher than just merging the changes.
Shameless plug: At EA we've open-sourced our C++ standard library implementation that focuses on games. While it's not necessarily focused on embedded development, you might be interested in checking it out - it provides a number of fixed_* containers (fixed_vector, fixed_set, etc) which can be configured to use stack allocations only, among some other things you might find interesting :)
I guess I understand the downvotes here, but I really do think you've hit on at least an issue. Maybe not the issue, but it's a pretty big problem.
RMS's conduct here is just... pretty inappropriate. Jokes about abortion, rape, race, sexual orientation, etc, etc, are not something you should be touching as the maintainer of a public project, no matter what your opinions are or how strongly you hold them. The glibc maintainers (completely reasonably) decided that the man pages weren't a good place for potentially-charged jokes like this, and removed it. RMS overruled them in a pretty childlike and insensitive fashion, and that's not appropriate when you're the public face of anything.
I don't give a shit about the politics of glibc - but I do care that someone who is a role model and a public figure acts like this.
But is he? Who considers rms as a role model generally? Barely anyone even knows his positions on anything other than software, and those are often derided. And that's on HN, where he's actually known. My colleagues wouldn't even know his name.
This ignores both the fact that RMS is much more than just the maintainer of glibc, and the fact that 'just forking' glibc doesn't stop the maintainer from having a significant amount of public influence.
The problem is not anything to do with glibc - it's the conduct of someone who, like it or not, is a role model for a lot of people in the community, and has taken on a very public role.
Counter to your glorious Fahrenheit 451 perception of either contemporary society or our future one, it’s just as dystopian to permit humor to be used as suppression of a marginalized subset of people. It is perfectly acceptable to expect that people not discriminate against others that are unlike them, in any way, lest that be a possibility. The key to humor that is actually funny is understanding that, particularly how the word I intentionally emphasized applies to comedy.
(Not saying that happened here, just reacting to your broadening to “policing humor.” Humor is also, you know, funny. That did happen here. Stallman should stick to his day gig.)
You guys both seem to really want there to be high-stakes politics implicated in this story, but there aren't, and pretending that there are looks pretty dumb. It is unlikely in the extreme that the maintainers who want to remove Stallman's dated, unfunny joke are pro-lifers. Presumably, they just think it's a cringey distraction, like this subthread.
The issue is whether Stallman gets veto rights on glibc commits. The maintainers say he doesn't. Since Stallman doesn't do much glibc work, and the maintainers do, presumably Stallman is going to lose this, unless they let him save face out of affection.
Because it hasn't been just his project since he began accepting patches. It's a reflection on every contributor and every member of the community. When a project is the product of many peoples work, dirtying the face of the project affects everyone.
You’d be surprised. It bottomed out at -3 and is now oscillating around 0 and -1. That’s a surprisingly encouraging sign.
I agree wholeheartedly with your assessment of a problem. I think the industry’s reaction to it is an even bigger one and it’s right here, in this thread. Or lack thereof.
I dunno, I find it pretty easy to understand... seems like the main instruction loop is in tvm.c, in the function tvm_vm_run(), which is exactly the first place I looked and seems totally sensible to me.
for (; vm->prog->instr[*instr_idx] != -0x1; ++(*instr_idx))
tvm_step(vm, instr_idx);
Compare that to my 6809 emulator [1]. I have a mc6809_run() function that is pretty much the same, but mc6809_step() is in the same file and not hidden in a header file. There also seems to be a lack of memory operations (like reading or writing) other than PUSH/POP.
Not quite. Multiple dispatch (as mentioned in sibling comments) is basically 'virtual on both object and argument types', so like:
class Vehicle {
virtual void Collide(Vehicle other);
}
class Car {
void Collide(Truck other) { /* hit a truck */ }
void Collide(Car other) { /* hit another car */ }
}
class Truck {
void Collide(Truck other) { /* hit another truck */ }
void Collide(Car other) { /* hit a car */ }
}
Vehicle c = Car();
Vehicle t = Truck();
c.Collide(t); // with multiple dispatch, calls Car::Collide(Truck)
You are using static overloading on the argument rather than dynamic dispatch. If the static type of truck is obscured to a super class, your behavior won't be as expected. In general, overloading shouldn't be used as a replacement for dynamic dispatch, rather it should be used to accommodate multiple incompatible types (e.g. foo(X) and foo(Y) but never foo(Z) if X <: Z and Y <: Z unless foo(Z) maintains the behavior of foo(X) and foo(Y) given an x or a y under subsumption).
Multiple dispatch is typically meant to be purely dynamic in meaning, as wiki puts it:
> Multiple dispatch or multimethods is a feature of some programming languages in which a function or method can be dynamically dispatched based on the run-time (dynamic) type or, in the more general case some other attribute, of more than one of its arguments.[1]
The static type of both c and t is Vehicle, but by dynamic multiple dispatch Car::Collide(Truck) is selected. That's not how C++ works, but the example was exactly about illustrating how C++ doesn't work.
I moved from git to perforce when I switched companies, and even though I actually really like git and consider myself reasonably proficient, I don't mind perforce.
My one real pain point with it isn't so bad, but I dislike how perforce tends to work at a file level instead of a commit level. It's hard for me to make several related changes which all touch the same files, like a series of patches which all refactor the same area of code, but which I would like to review and discuss separately, and potentially revert some/all of.
It's hard to manage this with shelves, because perforce can't handle unshelving the same file in two different CLs. I could submit all the changes to a separate stream, but perforce streams just don't usually work well for us, and it's still hard to experiment by constantly making and rolling back changes.
I guess I'm probably only used to this workflow because I have experience with git, but this is the time when I really miss the granularity of a git commit (and I'm doing a pretty gigantic refactor right now... so it's hitting me quite hard).
I recently had to do something similar with an ancient SVN repo, that had to stay in SVN.
I simply started a git repo in the same base directory as the SVN repo, and did my work in there. Every time I merged a branch back to master I committed to SVN's ^/branches/dev. Just add `.svn` to `.gitignore` and `.git*` to the SVN prop ignore.
You _will_ want to merge from upstream (Whatever Perforce's equivalent to `svn up` or `git pull` is) often, I was merging from upstream before every SVN commit (SVN mostly forces you to do this, `svn status --show-updates` is a huge help here but I don't know if Perforce has a similar feature).
But this has a lot of problems. Namely - most of the time, when two people change the same line, the changes really do conflict, and someone really does need to manually merge them. In fact, sometimes even when your VCS merges things happily, it still gets them wrong because two changes conflict semantically but don't touch the same lines.
So I guess I would say, I think merging is an impossible problem to 'solve', and going to a more granular merge strategy is actually a move in the wrong direction. You could maybe fix my particular case by 'whitelisting' those typename changes, and saying 'these are allowed to merge with anything else', but at that point... the effort required to specify that unambiguously and make it work properly is probably higher than just merging the changes.