On 3/20/06, Juliusz Chroboczek <[EMAIL PROTECTED]> wrote: > > http://bugs.darcs.net/issue79 > > > I sent in a workaround for this, but as far as I know it was rejected. > > I try to be very clear (some would say rude) when I reject a patch. > For every patch you send, you should see feedback on darcs-devel > unless I push the patch. > > I do not mind seeing patches multiple times; quite the contrary, it > means I don't miss any.
And so what is the status of my patches pertaining to issue79? I have no easy way to check. Do you? If you say "yes", then please let me know what it is, I'm looking for such a system. I don't think it would be hard to build and I've been trying to find some time to pound it out. I'm thinking, for simplicity sake, that procmail could grab emails with patches and fire off a script that adds the patch and email to a database. I bet it would be pretty quick to build a python or ruby on rails webpage that allowed simple views into the database plus some metadata management. We could add a console interface too, or make the webpage simple enough to work well with w3m or links. Once we had that we could add all manner of cool features. People could vote on patches, add comments, download them, change their status all from one interface. Actually, I wonder if it could be implemented as a roundup extension? > I've got the following patches of yours in my mailbox: > > - ``Do not reread freshly written patch when recording'', rejected > due to Ian's opposition (which I happen to disagree with, but he's > the better Haskell programmer); I'll accept this patch when you > convince Ian; I don't feel a need to convince Ian, the numbers speak for themselves. Either you agree or you don't. But, while we're on the subject, using mmap for arbitrarily sized chunks of memory (as we do now) is a Bad Idea(tm). In fact, I'd say we should avoid mmap'ing more than a few megabytes at a time (and have the actual amount settable by the user). > - three patches dated 14 Jan 2006, which I will push as soon as you > find a better name instead of ``--file'' (as I've mentioned, I like > ``--logfile'', but it's up to you, I'm only doing the complaining); > - ``Add -i as an alias for --interactive'', which should get in (I was > waiting for somebody to object, but nobody has for now). These patches are not mine as Zachary points out in another email. I'm guessing the missattribution was a simple typo, but it has the appearance that even you could benefit from automated patch tracking. > If there's anything that I've lost, please resubmit it or complain > with the message-id of the submission. I get what you're saying, but how can I know if you've lost something. I'm over here and you're over there... :) > > The more fundamental problem here is that we have been relying on the > > laziness of haskell to make it efficient to read files and whatnot but > > IMO this won't cut it anymore and we're going to have to design this > > explicitly into darcs. > > I would tend to agree, but I happen to believe that Ian disagrees with > that. And both of you are better Haskell programmers than I am, so I > can only make conservative decisions when you disagree. If I had more time to work on implementation I'd be activily lobbying for the manual chunking, but instead I'm waiting for the new patch format and hoping that will make most of the problems just go away. *crosses fingers* Does anyone know how much of a patch is required to be in memory at once for darcs to be able to do its magic? If the answer is "the whole thing" that means that chunking patch reads is probably a waste of time. If it turns out you need just a whole line at once that gives good hope for the common case (someone could construct a 4GB file that is just one line, but with the exception of binary data I wouldn't expect it to happen often). Jason _______________________________________________ darcs-users mailing list [email protected] http://www.abridgegame.org/mailman/listinfo/darcs-users
