I think there are conceptual problems mixing unwind-protect-like constructs and call/cc.
The cl-cont lib appears to only support a subset of CL (in particular unwind-protect is not supported).
So cl-cont doesn't demonstrate that CL can support it, only that a restricted subset of CL can.
I don't know if it is possible to sensibly accommodate unwind-protect and call/cc in the same language, it seems smarter people than I have avoided doing so.
Scheme's dynamic-wind serves the same purpose as unwind-protect (except with entry conditions as well, since a continuation could suddenly return into your protected code), and plays nicely with continuations. I'm not sure about the details, though.
Thanks for that, pretty interesting. I guess that makes writing entry and exit conditions a little more interesting, since they could end up being invoked multiple times.
> Note that there may be a merge conflict when you run "git merge stable."
There is a git command, 'git mergetool'. This will go through all conflicting files and launch an external tool (you can configure which) to handle the merge. If you save your merged results, it will git add for you, just leaving you to commit at the end.
(From the manpage) It has support for: kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff
Editing conflicted files by hand does work, but for complex conflicts I prefer the approach above.
Really, I don't forsee much of a synchronization problem. People can commit to whichever branch they prefer; I'll keep an eye on the RSS feed, as might others, and if a bugfix gets pushed in one branch but not cherry-picked, we'll do it. There aren't too many commits that human error is going to matter all that much.
As for merging, there are already some commits in stable that aren't in master, because their functionality was based on Anarki-only features in master. Merging would try to merge those as well, which may have unintended consequences. It might also double up a bunch of the commits in master, which would be unfortunate.
I'm still not all that familiar with Git, though, and I would love to have nice history. I'm all ears for suggestions.
> there are already some commits in stable that aren't in master, because their functionality was based on Anarki-only features in master. Merging would try to merge those as well, which may have unintended consequences. It might also double up a bunch of the commits in master, which would be unfortunate.
That would be a one-time headache with the first merge. After that, as long as bugfixes go into the stable branch, you won't have that problem. (Just had a quick look, it seems like it's currently a fairly trivial merge with only a few minor conflicts - I think git is doing the right thing for you here, but I don't know arc well enough to be sure).
> I would love to have nice history. I'm all ears for suggestions.
Basically, imho, splitting a tree is work and merging shouldn't be.
So by putting the commits in the right place to start with, you're avoiding work (and errors, and people checking with other people to see if that is supposed to be like that, etc).
You're essentially preserving more information as to the purpose of the fix (this is a bugfix) in a way that the tools can get hold of.
Anyway - I'm not a git expert, but that's the way I'd do it.
