It should be short, to the point, and understandable by
itself. ``fixes for testsuite'' is okay, ``fix for issue79'' and
``Issue14 addendum'' are not.
This doesn't make sense to me. fix for issue79 is more useful to me than
fixes for testsuite, while also being shorter.
If I see ``fixes
* Adds target: api-doc. api-doc is generated by haddock
Are we willing to start writing Haddock mark-up in the sources? If we
decide we do, there's no going back.
Juliusz
___
darcs-devel mailing list
RepoVersion is David's code for versioning repositories. It will
allow us to have a Darcs binary able to handle different repository
formats and convert patches on the fly, much like Darcs-Git is able to
convert between Git and Darcs on the fly.
I'm just now getting to this and I don't see
Total time (wall clock)
orig: 5 hours +
no-reread: 6 minutes
Peak RES (as measured by top)
orig: 940MB
no-reread: 950MB
Am I reading this correctly? This unoptimisation makes Darcs 50 times
faster on large records while not using significantly more memory?
This looks like some serious
Sat Jan 14 17:58:32 EST 2006 Zachary P. Landau [EMAIL PROTECTED]
* Add support to make_email for optional headers
Why? (Not complaining, I just want to make sure people actually need
a feature before committing it.)
Juliusz
Total time (wall clock)
orig: 5 hours +
no-reread: 6 minutes
Peak RES (as measured by top)
orig: 940MB
no-reread: 950MB
Am I reading this correctly? This unoptimisation makes Darcs 50 times
faster on large records while not using significantly more memory?
At *least* 50 times
Total time (wall clock)
orig: 5 hours +
no-reread: 6 minutes
Peak RES (as measured by top)
orig: 940MB
no-reread: 950MB
Am I reading this correctly? This unoptimisation makes Darcs 50 times
faster on large records while not using significantly more memory?
At
Jason had only 1 GB physical RAM
Only?
When I was a lad...
Juliusz
___
darcs-devel mailing list
darcs-devel@darcs.net
http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
Jason, could you please repeat this test with a mere 100MB commit?
Juliusz
___
darcs-devel mailing list
darcs-devel@darcs.net
http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
DarcsURL: http://www.abridgegame.org/repos/darcs-unstable
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary==_
--=_
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
Wed Nov 23 16:27:17 GMT 2005 [EMAIL PROTECTED]
* Add newline between long comment and changed files
Jason had only 1 GB physical RAM
Only?
When I was a lad...
;-)
Last year I bought a second GB of physical RAM in order to avoid running out of
physical RAM while using darcs + vmware + web browser + xemacs.
Regards,
Zooko
___
darcs-devel
On Jan 16, 2006, at 08:20:11, Juliusz Chroboczek wrote:
So the tradeoff is:
- illegally use Old PGP within an attachment, as we do, which makes
the signature verifiable outside of the mailer, but not within it;
- obey the rules and use PGP/MIME, which will make it impossible to
- illegally use Old PGP within an attachment, as we do, which makes
the signature verifiable outside of the mailer, but not within it;
- obey the rules and use PGP/MIME, which will make it impossible to
verify the signature after the attachment is saved to disk.
Does anyone
Note that this also happens when no MTA is involved. This is issue 56.
Would anyone familiar with the new MIME encoder be willing to have a
look at RFC 3156?
I'm suddenly realising we are in trouble, and that it's better to
leave things in the current state than implement PGP/MIME.
There
[add installation/configuration instructions for Windows users
I'm not quite happy with including a raw dump of the automatically
generated HTML. In particular, including the Javascript doesn't make
sense.
My suggestion would be to write a new chapter in the manual, based on
this
Sat Jan 14 17:58:32 EST 2006 Zachary P. Landau [EMAIL PROTECTED]
* Add support to make_email for optional headers
Why? (Not complaining, I just want to make sure people actually need
a feature before committing it.
Juliusz,
I added it because I was looking for a way to add in a
On Sunday 15 January 2006 21:24, Jason Dagit wrote:
On Jan 15, 2006, at 7:34 AM, Aggelos Economopoulos wrote:
On Sunday 15 January 2006 05:04, Jason Dagit wrote:
Peak RES (as measured by top)
orig: 940MB
no-reread: 950MB
Peak VIRT (as measured by top)
orig: 1756MB
no-reread:
Sat Jan 14 17:06:52 EST 2006 Zachary P. Landau [EMAIL PROTECTED]
* Update tests to use --logfile instead of --file
Without commenting on the change of option names, I think
this patch name says the reverse of what's intended.
Indeed it does. I was having a dyslexic day. I can resubmit
On Jan 16, 2006, at 5:34 AM, Juliusz Chroboczek wrote:
* Adds target: api-doc. api-doc is generated by haddock
Are we willing to start writing Haddock mark-up in the sources? If we
decide we do, there's no going back.
Yes, I think it would be a good thing. I also don't see it as
On Jan 16, 2006, at 6:23 AM, Juliusz Chroboczek wrote:
Jason, could you please repeat this test with a mere 100MB commit?
What would you like me to focus on if I do that? I've done this test
with 37MB commit and my findings then were pretty close to my
findings here as I recall.
On Jan 16, 2006, at 5:41 AM, Juliusz Chroboczek wrote:
Total time (wall clock)
orig: 5 hours +
no-reread: 6 minutes
Peak RES (as measured by top)
orig: 940MB
no-reread: 950MB
Am I reading this correctly? This unoptimisation makes Darcs 50 times
faster on large records while not using
Sat Jan 14 04:22:52 PST 2006 Jason Dagit [EMAIL PROTECTED]
* Do not reread freshly written patch when recording.
I've looked at the code again -- and I'm puzzled. I s'pose it's
linesPS biting us again.
The experimental results are definitely promising, but there's
obviously something going
On 1/16/06, Juliusz Chroboczek [EMAIL PROTECTED] wrote:
* Add support to make_email for optional headers
Why? (Not complaining, I just want to make sure people actually need
a feature before committing it.
I added it because I was looking for a way to add in a In-Reply-To
header.
On Jan 16, 2006, at 8:09 AM, Juliusz Chroboczek wrote:
Sat Jan 14 04:22:52 PST 2006 Jason Dagit [EMAIL PROTECTED]
* Do not reread freshly written patch when recording.
I've looked at the code again -- and I'm puzzled. I s'pose it's
linesPS biting us again.
Maybe, I had at least one
Does anyone see a good way out? For now, I'm closing the report as
unfixable.
How about we generate and send both kinds of signatures?
I'm not very keen on that, unless someone is willing to spend time
investigating how mailers react to such things.
25 matches
Mail list logo
