On Sat, Jan 05, 2008 at 05:25:06PM +0300, Dmitry Kurochkin wrote:
> 2008/1/5, Tristan Seligmann <[EMAIL PROTECTED]>:
> > * Dmitry Kurochkin <[EMAIL PROTECTED]> [2008-01-05 02:58:35 +0300]:
> >
> > > > Also related to this idea: can we adjust the order of downloads in the
> > > > queue? e.g. maybe
2008/1/5, Tristan Seligmann <[EMAIL PROTECTED]>:
> * Dmitry Kurochkin <[EMAIL PROTECTED]> [2008-01-05 02:58:35 +0300]:
>
> > > Also related to this idea: can we adjust the order of downloads in the
> > > queue? e.g. maybe I'd like to add a file towards the front of the queue
> > > because I need i
* Dmitry Kurochkin <[EMAIL PROTECTED]> [2008-01-05 02:58:35 +0300]:
> > Also related to this idea: can we adjust the order of downloads in the
> > queue? e.g. maybe I'd like to add a file towards the front of the queue
> > because I need it right now. This might be doable if waitForURL could bum
2008/1/4, David Roundy <[EMAIL PROTECTED]>:
> On Fri, Dec 21, 2007 at 04:12:49AM +0300, Dmitry Kurochkin wrote:
> > I have completed initial work on libwww pipelining. Output of darcs whatsnew
> > is attached (sorry for that, I will try to make a proper patch tomorrow).
> > What is done:
> > - libc
On Fri, Dec 21, 2007 at 04:12:49AM +0300, Dmitry Kurochkin wrote:
> I have completed initial work on libwww pipelining. Output of darcs whatsnew
> is attached (sorry for that, I will try to make a proper patch tomorrow).
> What is done:
> - libcurl functionality is implemented using libwww. Now pip
Hi all.
Here is the patch.
I get a strange segfault on one machine with Debian testing + custom ghc.
It is not reproducible on Debian unstable.
Segfault happens in get command after the first patch is downoaded
(when "Copying patch 1 of
N" is printed). Despite all my efforts I could not find the
I have completed initial work on libwww pipelining. Output of darcs whatsnew
is attached (sorry for that, I will try to make a proper patch tomorrow).
What is done:
- libcurl functionality is implemented using libwww. Now pipelining works.
- New Libcurl module provides 3 functions:
* copyUrl - sa
Yeah, the configure step is precisely the place to put that, and sticking
it right into the makefile for now will be great. Thanks!
David
On Wed, Dec 19, 2007 at 07:15:15PM +0300, Dmitry Kurochkin wrote:
> The problem is that ghc eats -DHAVE_CONFIG_H option from libwww-config
> --cflags.
> If I
2007/12/19, David Roundy <[EMAIL PROTECTED]>:
> On Dec 18, 2007 10:00 PM, Dmitry Kurochkin <[EMAIL PROTECTED]> wrote:
> > I tried to get pipelining working with cURL, but no luck. It looks to me
> > that cURL multi API is overcomplicated and not-too-well documented...
> >
> > So I have taken a look
2007/12/18, Peter Lund <[EMAIL PROTECTED]>:
> On Mon, 2007-12-17 at 21:42 -0800, Stefan O'Rear wrote:
>
> > > Neon is GPL and is used as the basis for HTTP support in gnome-vfs and
> > > Nautilus, the file manager in Gnome. It supports WebDAV, TLS, cookies,
> > > connection keep-alive, and transfer
2007/12/19, David Roundy <[EMAIL PROTECTED]>:
> On Dec 19, 2007 9:53 AM, Dmitry Kurochkin <[EMAIL PROTECTED]> wrote:
> > I have created a Libwww.hs module and hslibwww.c. Libwww.hs provides
> > getUrl and getUrls functions. I have changed copyRemotesNormal to use
> > getUrls. And it is ready for te
Debian testing. I will try it on unstable when get home.
I'll see if I can make ghc to print commands it runs.
Regards,
Dmitry
2007/12/19, David Roundy <[EMAIL PROTECTED]>:
> This is puzzling. What OS are you using? It seems like ghc should be
> calling the same gcc you've got on the system...
On Wed, 2007-12-19 at 06:00 +0300, Dmitry Kurochkin wrote:
> So I have taken a look at libwww and it works great! I created (copied
> a sample) simple program to load given URL many times using only
> persistent connection and using pipelining. And results are much better
> than I expected: loadin
The problem is that ghc eats -DHAVE_CONFIG_H option from libwww-config --cflags.
If I run:
% ghc -c hslibwww.c `libwww-config --cflags` -optc-DHAVE_CONFIG_H
It compiles fine. I guess this should be dealt with in configure step?
For now I will just put needed flags into makefile.
Regards,
Dmi
On Dec 19, 2007 9:53 AM, Dmitry Kurochkin <[EMAIL PROTECTED]> wrote:
> I have created a Libwww.hs module and hslibwww.c. Libwww.hs provides
> getUrl and getUrls functions. I have changed copyRemotesNormal to use
> getUrls. And it is ready for testing. But I get compilation errors on
> hslibwww.c.
>
This is puzzling. What OS are you using? It seems like ghc should be
calling the same gcc you've got on the system... :(
David
On Dec 19, 2007 10:51 AM, Dmitry Kurochkin <[EMAIL PROTECTED]> wrote:
> Copied too fast. Here is what I get:
>
> % ghc -c hslibwww.c `libwww-config --cflags`
> In file
On Dec 18, 2007 10:00 PM, Dmitry Kurochkin <[EMAIL PROTECTED]> wrote:
> I tried to get pipelining working with cURL, but no luck. It looks to me
> that cURL multi API is overcomplicated and not-too-well documented...
>
> So I have taken a look at libwww and it works great! I created (copied
> a sam
On Mon, 2007-12-17 at 21:42 -0800, Stefan O'Rear wrote:
> > Neon is GPL and is used as the basis for HTTP support in gnome-vfs and
> > Nautilus, the file manager in Gnome. It supports WebDAV, TLS, cookies,
> > connection keep-alive, and transfer compression. I think it only needs
> > its arms twi
On Mon, 2007-12-17 at 10:18 -0500, David Roundy wrote:
> Any suggestions how to go about doing this? I quick look suggests that
> libcurl can't handle http pipelining, and that no haskell HTTP library does
> so. The only library I can find that does seem to support it is libwww,
> which looks lik
On Tue, 2007-12-18 at 18:51 +0900, Stephen J. Turnbull wrote:
> The problem with neon in my experience is that they don't hesitate to
> change the API in incompatible ways, occasionally requiring
> substantial changes in the caller.
That's a bit annoying.
> It appears that at least on the
> Ma
I tried to get pipelining working with cURL, but no luck. It looks to me
that cURL multi API is overcomplicated and not-too-well documented...
So I have taken a look at libwww and it works great! I created (copied
a sample) simple program to load given URL many times using only
persistent connecti
After looking at this a bit more it does not look so good to me.
I thought that darcs uses a new TCP connection for each patch. But
wireshark shows that it uses persistent connection already.
So there is no TCP handshake overhead.
Pipelining is sending multiple requests without waiting for respon
I don't have the post from Peter yet, so I'm responding to Stefan's.
Stefan O'Rear writes:
> On Tue, Dec 18, 2007 at 06:11:58AM +0100, Peter Lund wrote:
> > Neon is GPL and is used as the basis for HTTP support in gnome-vfs and
> > Nautilus, the file manager in Gnome. It supports WebDAV, TLS,
I do not have experience with cURL. But I do not think this is a problem.
The real problem is time... Still this does not seem like too much work. I
will try to look at it tomorrow.
Regards,
Dmitry
David Roundy wrote:
> H. Alas, curl 7.16 is not yet in debian stable (my default for when we
On Tue, Dec 18, 2007 at 06:11:58AM +0100, Peter Lund wrote:
> On Mon, 2007-12-17 at 10:18 -0500, David Roundy wrote:
>
> > Any suggestions how to go about doing this? I quick look suggests that
> > libcurl can't handle http pipelining, and that no haskell HTTP library does
> > so. The only librar
Hi David,
According to cURL changelog pipeline support has been added in version
7.16.0:
CURLMOPT_PIPELINING added for enabling HTTP pipelined transfers.
I did not use it myself but from the docs it looks like this is just
what you want. Quote:
CURLMOPT_PIPELINING
Pass a long set to 1 to ena
On Tue, Dec 18, 2007 at 08:27:23AM +0900, Stephen J. Turnbull wrote:
> David Roundy writes:
> > H. Alas, curl 7.16 is not yet in debian stable (my default for when we
> > can require something),
>
> This is an optimization. Add a configure test for it, build it in
> when available, add a D
David Roundy writes:
> H. Alas, curl 7.16 is not yet in debian stable (my default for when we
> can require something),
This is an optimization. Add a configure test for it, build it in
when available, add a Darcs option for it whether or not it's
actually, and a warning that this option
H. Alas, curl 7.16 is not yet in debian stable (my default for when we
can require something), but that's still very interesting! Do you by any
chance have experience coding with libcurl? We've only ever used the "easy"
interface, and if you'd like to take a shot at updating src/hscurl.c to u
On 12/17/07, David Roundy <[EMAIL PROTECTED]> wrote:
>
> Any suggestions how to go about doing this? I quick look suggests that
> libcurl can't handle http pipelining, and that no haskell HTTP library does
> so. The only library I can find that does seem to support it is libwww,
> which looks like
On Thu, Dec 13, 2007 at 07:19:02PM -0800, Stefan O'Rear wrote:
> On Thu, Dec 13, 2007 at 07:12:45PM -0800, David Roundy wrote:
> > Still on my todo list (of issues that you've reported):
> >
> > 2. figuring out a nice way to speed up a lazy darcs get. Currently it
> >grabs each file in the re
On Mon, Dec 17, 2007 at 12:20:28AM -0500, Max Battcher wrote:
> On Dec 16, 2007 4:45 PM, Alexander Staubo <[EMAIL PROTECTED]> wrote:
> > I'm a bit confused about the new repository formats. There's the new
> > hashed format, and also the "darcs-2 format"; but I don't see an
> > explanation anywhere
On Thu, Dec 13, 2007 at 07:19:02PM -0800, Stefan O'Rear wrote:
> On Thu, Dec 13, 2007 at 07:12:45PM -0800, David Roundy wrote:
> > Still on my todo list (of issues that you've reported):
> >
> > 2. figuring out a nice way to speed up a lazy darcs get. Currently it
> >grabs each file in the re
On Thu, Dec 13, 2007 at 07:12:45PM -0800, David Roundy wrote:
> Still on my todo list (of issues that you've reported):
>
> 2. figuring out a nice way to speed up a lazy darcs get. Currently it
>grabs each file in the repository individually. This means we're not
>harmed by long history,
On Thu, Dec 13, 2007 at 09:35:52AM +, Simon Marlow wrote:
> David Roundy wrote:
>> The difference here is that I haven't implemented the time-stamp
>> synchronizing feature for hashed repositories. I wasn't sure it was
>> still needed (and would be nice to drop, as it's a bit hackish), since
>
On Dec 16, 2007 4:45 PM, Alexander Staubo <[EMAIL PROTECTED]> wrote:
> I'm a bit confused about the new repository formats. There's the new
> hashed format, and also the "darcs-2 format"; but I don't see an
> explanation anywhere as to why Darcs 2 needs two new formats or why
> users should not sim
On 12/16/07, David Roundy <[EMAIL PROTECTED]> wrote:
> You aren't using hashed repositories, are you? You won't see that
> incredible, wonderful performance improvement from optimize, because you'll
> already get it when you switch to hashed repositories, since then you won't
> need to download any
On Sun, Dec 16, 2007 at 01:12:21AM +0100, Alexander Staubo wrote:
> On 12/14/07, David Roundy <[EMAIL PROTECTED]> wrote:
> > You don't need to call optimize on the repository that is used to create
> > the tag, and you shouldn't need to do so very often.
>
> Ah, I thought perhaps you needed to do
On Sun, Dec 16, 2007 at 01:12:59AM +0100, Alexander Staubo wrote:
> On 12/15/07, David Roundy <[EMAIL PROTECTED]> wrote:
> > My arguments here started looking pretty thin, so I've now added automatic
> > optimization for hashed repositories. I think this'll be pretty cheap, and
> > if it turns out
On 12/15/07, David Roundy <[EMAIL PROTECTED]> wrote:
> My arguments here started looking pretty thin, so I've now added automatic
> optimization for hashed repositories. I think this'll be pretty cheap, and
> if it turns out to be a performance regression, then we can always revert
> it. The only
On 12/14/07, David Roundy <[EMAIL PROTECTED]> wrote:
> You don't need to call optimize on the repository that is used to create
> the tag, and you shouldn't need to do so very often.
Ah, I thought perhaps you needed to do this in order to reduce the
search space on both sides of the exchange.
> >
On Sat, Dec 15, 2007 at 05:38:43PM +0100, Petr Rockai wrote:
> > Anyhow, it'll be a couple of hours before tests are passed and changes are
> > pushed, but then I'd appreciate it if you'd take another look at this! (I
> > could do it myself but right now I think I need a break... and it's far
> > e
David Roundy <[EMAIL PROTECTED]> writes:
> Okay, I've found a couple of really stupid bits of code, and this goes a
> lot faster now. The "17" pull took under three seconds, and that's with
> profiling running. Fortunately (and perhaps unsurprisingly) the issue was
> largely with the "easy" parts
My arguments here started looking pretty thin, so I've now added automatic
optimization for hashed repositories. I think this'll be pretty cheap, and
if it turns out to be a performance regression, then we can always revert
it. The only command upon which we really shouldn't be bothering to do
th
On Fri, Dec 14, 2007 at 10:15:13PM +0100, Alexander Staubo wrote:
> On 12/14/07, David Roundy <[EMAIL PROTECTED]> wrote:
> > On Fri, Dec 14, 2007 at 01:33:33PM +, Simon Marlow wrote:
> > > I guess I don't understand why optimize is exposed to the user at all. if
> > > there's an optimal state f
On 12/14/07, David Roundy <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 14, 2007 at 01:33:33PM +, Simon Marlow wrote:
> > I guess I don't understand why optimize is exposed to the user at all. if
> > there's an optimal state for the repository, why can't it be maintained in
> > that state?
>
> It's
On Fri, Dec 14, 2007 at 09:18:29AM -0800, David Roundy wrote:
> > Hmm, I have just tested the nested conflict issue. Now, the behaviour
> > is *much* better in darcs-2 than it has been in darcs one. I have
> > modified Pekka Pessi's misery.sh (from [darcs-users] unique features +
> > exponential ti
Thanks, Peter, for making this investigation!
On Fri, Dec 14, 2007 at 01:42:14PM +0100, Petr Rockai wrote:
> Hi,
>
> first of all, hats off for the progress you have made!
>
> David Roundy <[EMAIL PROTECTED]> writes:
> > The future of darcs is in the darcs-2 repository format, which features a
>
On Fri, Dec 14, 2007 at 01:33:33PM +, Simon Marlow wrote:
> David Roundy wrote:
> > On Fri, Dec 14, 2007 at 10:04:57AM +, Simon Marlow wrote:
> >> David Roundy wrote:
> >>> Okay, it turns out that it was indeed bad strictness causing the trouble.
> >>> For some reason, I had made the PatchI
David Roundy wrote:
> On Fri, Dec 14, 2007 at 10:04:57AM +, Simon Marlow wrote:
>> David Roundy wrote:
>>> Okay, it turns out that it was indeed bad strictness causing the trouble.
>>> For some reason, I had made the PatchInfoAnd data type strict in both its
>>> components, which meant that eve
On Fri, Dec 14, 2007 at 10:04:57AM +, Simon Marlow wrote:
> David Roundy wrote:
> > Okay, it turns out that it was indeed bad strictness causing the trouble.
> > For some reason, I had made the PatchInfoAnd data type strict in both its
> > components, which meant that every time we read a patch
Hi,
first of all, hats off for the progress you have made!
David Roundy <[EMAIL PROTECTED]> writes:
> The future of darcs is in the darcs-2 repository format, which features a
> new merge algorithm that introduces two major user-visible changes
>
> 1. It should no longer be possible to confuse d
David Roundy wrote:
> On Wed, Dec 12, 2007 at 01:45:13PM +, Simon Marlow wrote:
>> "darcs changes" seems to have a big performance regression:
>>
>> $ time darcs2 changes --last=10 >/dev/null
>>
>> I killed it after 3 minutes of CPU time and the process had grown to 1.4Gb.
>> darcs1 does thi
On Thu, Dec 13, 2007 at 07:12:45PM -0800, David Roundy wrote:
> On Thu, Dec 13, 2007 at 09:50:50AM +, Simon Marlow wrote:
> > Simon Marlow wrote:
> > >David Roundy wrote:
> > >>Yikes! That's actually a very surprising bug. I'd be interested in
> > >>hearing if it shows up if you run a darcs2 o
On Thu, Dec 13, 2007 at 09:50:50AM +, Simon Marlow wrote:
> Simon Marlow wrote:
> >David Roundy wrote:
> >>Yikes! That's actually a very surprising bug. I'd be interested in
> >>hearing if it shows up if you run a darcs2 optimize first? Either way,
> >>of course, it's a serious bug, but that'd
On Thu, Dec 13, 2007 at 01:36:09PM -0800, Stefan O'Rear wrote:
> On Thu, Dec 13, 2007 at 09:35:52AM +, Simon Marlow wrote:
> > David Roundy wrote:
> >> The difference here is that I haven't implemented the time-stamp
> >> synchronizing feature for hashed repositories. I wasn't sure it was
> >>
On Wed, Dec 12, 2007 at 01:45:13PM +, Simon Marlow wrote:
> "darcs changes" seems to have a big performance regression:
>
> $ time darcs2 changes --last=10 >/dev/null
>
> I killed it after 3 minutes of CPU time and the process had grown to 1.4Gb.
> darcs1 does this in 0.05 seconds using 2M
On Wed, Dec 12, 2007 at 01:55:13PM +, Simon Marlow wrote:
> A small UI issue:
>
> $ darcs2 get http://darcs.haskell.org/ghc-darcs2
>
> darcs failed: Incompatibility with repository
> http://darcs.haskell.org/ghc-darcs2:
> Cannot mix darcs-2 repositories with older formats
>
>
> Since I'm
On Thu, Dec 13, 2007 at 09:50:50AM +, Simon Marlow wrote:
> Simon Marlow wrote:
> >David Roundy wrote:
> >>Yikes! That's actually a very surprising bug. I'd be interested in
> >>hearing if it shows up if you run a darcs2 optimize first? Either way,
> >>of course, it's a serious bug, but that'd
Simon Marlow wrote:
> David Roundy wrote:
>> Yikes! That's actually a very surprising bug. I'd be interested in
>> hearing if it shows up if you run a darcs2 optimize first? Either way,
>> of course, it's a serious bug, but that'd give a hint where the
>> trouble is.
>
> darcs2 check has nearly f
David Roundy wrote:
> darcs check should work to indicate the conversion went fine.
Just fired one off, I'll let you know if it finishes before I've written
this email :-)
>> $ darcs2 query repo
>>Type: darcs
>> Format: hashed, darcs-2-experimental
>>Root: /64pl
HOORAY! Thank you David, Ganesh, Eric and others.
___
darcs-devel mailing list
darcs-devel@darcs.net
http://lists.osuosl.org/mailman/listinfo/darcs-devel
Dear darcs-devel folks:
Oh by the way, let me say: "HOORAY!". I suspected that darcs 2 was
never going to actually happen, and now I see that it *is* going to
happen! Way to go! This breathes new life into the darcs project!
Regards,
Zooko
___
Thanks for your report!
On Dec 12, 2007 8:45 AM, Simon Marlow <[EMAIL PROTECTED]> wrote:
> David Roundy wrote:
>
> > === Creating a repository in the darcs-2 format ===
> >
> > Converting an existing repository to the darcs-2 format is as easy as
> >
> > darcs convert oldrepository newrepository
>
Simon Marlow wrote:
> It is also online here:
>
> http://darcs.haskell.org/ghc-darcs2
Getting a lazy partial repository over http isn't particularly quick:
$ time darcs2 get http://darcs.haskell.org/ghc-darcs2 --darcs-2
Finished getting.
495.19s real 2.08s user 1.12s system 0%
A small UI issue:
$ darcs2 get http://darcs.haskell.org/ghc-darcs2
darcs failed: Incompatibility with repository
http://darcs.haskell.org/ghc-darcs2:
Cannot mix darcs-2 repositories with older formats
Since I'm trying to get a darcs-2 format repository, I would expect it to
just work, and gi
David Roundy wrote:
> === Creating a repository in the darcs-2 format ===
>
> Converting an existing repository to the darcs-2 format is as easy as
>
> darcs convert oldrepository newrepository
I did this for GHC's repository. I left it running last night, and I'm not
sure whether it complete
We are happy to announce the first prerelease version of darcs 2! Darcs 2
will feature numerous improvements, and this prerelease will also feature a
few regressions, so we're looking for help, from both Haskell developers
and users willing to try this release out. Read below, to see how you can
b
68 matches
Mail list logo
