The Return of the Symbolic Branch!
Recent comments by Bret Johnson caused me to revisit the symbolic branch of lDebug. These were one and two, referencing my earlier reply to this thread on DOS assembly language resources.
In particular, the second message ends in:
I also sometimes use ECM's lDebug, but that is mostly when I'm trying to figure out what someones else's program is doing and don't have the source code or some other way to look at the symbols/names to help try and figure out what's going on. lDebug is much better/easier than D86/D386 for certain kinds of debugging/research.
So, the natural reaction is to consider: what is lDebug not (yet!) better and easier for than the competition? (Mind, I didn't actually ask Bret about this yet.)
‘Move fast and break things’ is a development mantra popularised by Facebook and picked up with enthusiasm by software development teams both small and large. The idea is that if you aren’t breaking things you’re delivering value too slowly.
Why 'Move Fast and Break Things' Doesn’t Work, capacitas Insights (also in the Internet Archive)
mov is of course an 8086 instruction,
and mak is a script name for build scripts that I tend to use, most intricately to build lDebug.
Today a patch I sent to mercurial-devel was allowlisted. It is reproduced here for reference.
rebase: add boolean config item rebase.norebasesource
This allows to use rebase without recording a rebase_source extra field. This is useful for example to build a mirror converted from another SCM (such as svn) by converting only new revisions, and then incrementally add them to the destination by pulling from the newly converted (unrelated) repo and rebasing the new revisions onto the last old already stored changeset. Without this patch the rebased changesets would always receive some rebase_source that would depend on the particular history of the conversion process, instead of only depending on the original source revisions.
After some discussion on lDebugX running a DPMI client in dosemu2 on a hosteurope virtual server, several changes were made to both lDebugX and dosemu2. dosemu2 got a genuine bugfix out of this. Or two. Or three.