[darcs-devel] Scriptability, GUI

[David Roundy]

On Sat, Sep 03, 2005 at 04:02:56PM +0200, Daniel Lutz wrote:
> Am 03.09.2005 um 14:45 schrieb David Roundy:
> >We could add a --plain option to annotate, which would eliminate the
> >post-processing and could be implemented to run faster.  Or we could
> >stick this in the query supercommand as something like
> >
> >darcs query filecontents -p foo filename
> 
> This would be great.  Probably even better would be if the command could
> accept a list of patches (e.g. --match ...  --match ...) because file
> "versions" which differ only in a few patches could benefit of their
> common predecessor patches (which could improve efficiency on large
> repositories).

True, but how'd you get the output then? I assumed we'd just dump the file
contents to stdout, but it'd be more of a pain if we need to figure out how
to mark the beginning and ending of the files.  I guess we could output the
file length first, followed by a newline, but that's a bit of a pain.

> >>3) Repository locking. In BitKeeper there is a (blocking) block
> >>command. Something similar would greatly improve the robustness of the
> >>repository when using GUIs and shell scripts.
> >
> >We could certainly implement this.  What do you mean by a "(blocking)"
> >block command? Does it just run forever until interrupted, and then
> >unlock the repo before exiting? I hadn't thought of that.  When this
> >sort of feature was suggested before, the assumption was a "lock" and
> >"unlock" command, and I wasn't comfortable with the "unlock" command
> >since it could easily let people corrupt their repositories.  But if the
> >block command just blocks while it's running, we'd be safe, which would
> >be great.
> 
> According to its documentation BitKeeper's block command blocks as long
> as the calling process exists, if I remember correctly. To be honest, I
> did never use this command (since I never had the need to expand
> BitKeeper's functionality), so I cannot say how good it is in practice.
> But I can try this on Monday.

I guess to do that, it must background itself or something? It's got to
remain running to unblock when the calling process exits.  I think I'd
prefer to just unblock when the block command exits (due to either sigINT
or sigKILL).

> >>4) Setting the explicit dependencies (darcs record) by command
> >>arguments (instead of asking for each available patch).
> >
> >Hmmm.  Explicit dependencies are quite rarely used, so I don't want to
> >complicate the interface much for their sake.  But this would be a
> >pretty easy feature to use... and if we dropped the prompting, we could
> >actually simplify the interface and code.  I can imagine something like
> >five flags, --depends-on-tag --depends-on-patches --depends-on-patch
> >--depends-on-matches --depends-on-match, where the plural and singular
> >versions would add depends to all matching patches or just the most
> >recent matching patch respectively.  Technically we'd only need *either*
> >the singular version *or* the plural one, but I'm not sure which would
> >be more useful.  Probably just the singular, since you don't want to
> >accidentally introduce too many dependencies.
> 
> Personally, I would prefer the --depends-on-match variant.

Okay, but whenever we've got a "match" flag, I like to also have a "patch"
version and a "tag" version, since patch is usually easier than match for
quick typing, and tag is nice if you really want to match a tag.

> >>What do you think:
> >>- Are there already (clean) solutions for this in the current darcs
> >>which I didn't see?
> [...]
> >Adding new darcs commands is actually quite easy due to its internal
> >framework, so this sort of work is appropriate for newer darcs
> >developers.
> 
> Ok, understood the tip :-) Unfortunately Darcs is my first contact with
> Haskell. So, if I wrote Haskell code now it would be bad code... But I
> guess that by examinig the code for interfacing with the GUI tool I will
> get more familar with Darcs/Haskell...

It's up to you.  Coders new to haskell can often produce quite good haskell
code.  I always like getting new contributors--not just as slave labor, but
because it makes working on darcs more fun.

Another (not unrealistic) option would be to find someone else (possibly an
existing darcs coder) who'd be interested in coding features you require,
with whom you could work to establish a useful interface.  This would
probably actually be better than coding yourself (if an interested
volunteer could be found), just because it's always better to have more
people involved in creating an interface.

I actually enjoy reviewing contributed code and giving suggestions for
improvement, so I imagine that learning haskell by contributing to darcs
would be a pleasant experience.  On the other hand, writing the GUI program
probably would by itself be a lot of work, so you would have to judge how
much time you've got to spend.

> >I've definitely been busy.  I glanced at the email when it first came 
> >in,
> 
> Thank you very much!

You're welcome!
-- 
David Roundy
http://www.darcs.net