Camelia, the Perl 6 bug

IRC log for #darcs, 2008-02-16

| Channels | #darcs index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:07 kowey just did rm -rf / (but stopped it in time)
00:07 lambdabot kowey: You have 1 new message. '/msg lambdabot @messages' to read it.
00:16 lispy kowey: ah, that's bad!
00:17 kowey hmm... silly IRC client doesn't show me what's going on in #darcs
00:17 lispy hmm...I think I once saw a way to disable that command with bash
00:18 lispy I think it worked by creating a bash function that didn't allow things like, rm -rf /, rm -rf ~/ but allowed other invocations of rm
00:19 kowey i was doing some makefile hacking
00:19 kowey (wxhaskell actually)
00:19 kowey and one of the clean targets had a variable mis-set
00:19 kowey I think I lost the first two and a half applications in /Applications
00:19 lispy :(
00:20 lispy on your mac?
00:20 kowey (that's a convenient first thing to have in /... hopefully no important . files)
00:20 kowey yeah
00:20 kowey btw, what do you have as the first couple of entries?
00:20 lispy on my mac?
00:20 kowey (yeah, if it's not too indiscreet) something, something, then Adobe Reader on mine
00:20 lispy i'm at work right now, so no macs near by
00:20 kowey oh ok
00:21 lispy is researching issue tracking software that also does project management
00:21 lispy we have none, but we need something.
00:22 kowey does trac fit into this category?
00:22 lispy I'm not sure, I put it on the list to look at.
00:23 lispy I'm currently considering, JIRA, FogBugz, Trac and what we use currently for tracking customer issues, EnterpriseWizard
00:24 kowey zooko was extolling the virtues of trac(+darcs) on the tracker just today
00:25 kowey http://bugs.darcs.net/issue491
00:25 lambdabot Title: Issue 491: switch bug tracking to trac+darcs - Darcs bug tracker
00:29 lispy hmm...the search engine in trac is not so good, and for a non-google searchable site that is not so good
00:30 lispy It's not clear from Zooko's email if trac provides per user and per project management though.
00:32 idnar why isn't the site google searchable?
00:32 lispy idnar: it would be for the company I work at
00:32 lispy this is not darcs related, I got off topic
00:32 idnar oh, sorry, I didn't read back enough
00:32 kowey staggers off to bed
00:32 lispy sorry for any confusion :)
00:32 idnar I guess trac's search isn't that great
00:33 idnar it's just a simple text search
00:33 idnar there's a separate ticket query interface that's more powerful, though
00:34 idnar I'm not sure what you mean by per user and per project management, either
00:35 idnar there's a whole slew of trac plugins in various states of brokenness that do various things, so you may be able to assemble the functionality you need, even if it's not part of the Trac core
00:35 lispy Suppose we have 5 projects and 5 developers.  Each developer might work on any of the 5 projects or not at all on some of them.  I would like to know how much time each developer is obligated to (estimate through tickets) on each project and total for each developer.
00:36 lispy Both estimated time remaning per project and per developer and time spent
00:37 idnar ah, I don't know anything about that
00:37 idnar but take a look around http://trac-hacks.org/
00:37 lambdabot Title: Trac Hacks - Plugins Macros etc. - Trac
00:37 idnar (as well as the main trac site)
00:37 lispy okay, I'm looking at the trac FAQ right now
00:38 lispy It does seem that trac either supports it, or a plugin does
00:38 lispy so that means I can't yet exclude it from the summary I'm generating
00:38 lispy (which is good, because it's a cheap solution)
00:41 lispy another thing I'm not clear about is the ratio of trac to repositories
00:41 lispy Do you have a different trac instance for each repository?
00:41 idnar that's the way I use it
00:42 idnar I'm not sure what the status is of multi-project trac instances, either
00:42 lispy that would be a bit of a show stopper in our use case scenario
00:43 lispy Only one installation is required, then for each project create an Environment (using trac-admin <fooproj> initenv). They will be separate projects, all handled by the same installation of Trac.
00:44 lispy Okay, it's still in the running :)
00:44 idnar hmm
00:44 idnar well, depends on what you mean
00:44 idnar a trac "environment" is what I call a trac instance
00:44 idnar it's a completely separate database, configuration file, etc.
00:44 lispy Oh, well maybe I misread their FAQ
00:44 lispy :(
00:45 idnar although you fairly easily run them all from the same deployment, and share auth, and so on
00:45 lispy So separate users?
00:45 idnar but for example, the permissions on each environment will be independent
00:45 idnar even if you share the password file across them all
00:45 idnar although that can be a good thing; user A has access to project A's env, but not project B
00:45 idnar (etc.
00:45 idnar )
00:45 idnar trac doesn't have such fine-grained permissions within a particular environment
00:46 lispy Yeah, the fact that you'd have to look at each project to manage a given developer is bad
00:47 lispy We have lots of projects that each developer is work on at a given time
00:49 idnar http://trac.edgewall.org/wiki/TracMu​ltipleProjects/ComprehensiveSolution
00:50 lambdabot Title: TracMultipleProjects/ComprehensiveSolution - The Trac Project - Trac, http://tinyurl.com/2jug4k
00:50 idnar (I haven't used any of this, I'm just searching the web *g*)
00:52 lispy idnar: yeah, my only complain there is that it's still alpha or beta, so I don't want to recommend my company use it
00:57 idnar yeah
00:57 lispy It's too bad their not done, I like trac.
00:57 lispy they're*
01:02 lispy Hm...I'm not sure the time tracking is very good.
01:02 lispy That's one thing we really like about JIRA
05:38 manveru does anyone know an approximate for the release of darcs2?
06:14 lispy manveru: I don't think on has been set
06:14 lispy manveru: have you tried the pre-release?
06:15 manveru lispy: well, i'm trying it
06:15 manveru actually, i'm trying the darcs version of darcs :)
06:15 manveru darcs-unstable, it's called i think
06:16 manveru i'm not too happy about how things work in mercurial or git... and would love to continue using darcs
06:18 manveru but it's hard if there is only a pre-release and i have no idea how many changes are still coming
06:19 manveru and there is no way to go from a darcs2 repo to a darcs1 repo for compatibility
06:20 lispy Hmm...I can't say for 100% certain, but I think things will be added not changed
06:20 lispy Plus, darcs1 repo can be used by darcs2 and upgraded later
06:20 lispy manveru: what features of darcs2 are you using at the moment?
06:30 manveru lispy: none... i don't know of its features
06:30 manveru what i'm interested in is speed and stability
06:32 lispy manveru: you should read this: http://wiki.darcs.net/DarcsWiki/DarcsTwo
06:32 lambdabot Title: DarcsTwo - DarcsWiki
06:33 manveru lispy: i did
06:33 manveru but i don't see anything called feature there
06:34 manveru my current problem with darcs is that with a history of ~2000 patches it's too slow to work with
06:38 manveru _darcs is now around 18MB, while the actual content is around 3.1MB
06:38 lispy manveru: the features are all explained there, I was just re-reading it
06:39 lispy manveru: have you tried some of the performance enhancing features of darcs1? such as tagging and optimizing?
06:39 lispy do they help?
06:39 manveru they don't help
06:39 manveru i tag around every 50-100 patches
06:39 manveru as part of the normal release cycle
06:40 lispy when you tag darcs tries to ignore everything older than the tag whenever it possibly can
06:40 manveru nods
06:41 manveru but then again you cannot really work with a partial repository
06:41 lispy manveru: now that you have a darcs2 snap shot, have you tried creating a copy of the repository and converting the repo?  Does this help performance?  If not, email darcs-devel with your performance woes and I'm sure they'll get worked on.
06:42 manveru it's hard for me to bench darcs1 vs darcs2 since the servers i'd test it with only have 1.0.9
06:42 manveru i might try the .deb on one machine, since it's nothing critical
06:42 lispy could you test it locally?
06:43 manveru locally there ain't too many problems
06:43 lispy as the wiki says, once you convert a repo you cannot share patches with non-converted repos.  So please be careful about that.
06:43 manveru i know
06:43 lispy what are you main problems then?
06:45 manveru well, as i said, i'd love a real release of darcs2 :)
06:45 manveru so we can officially move to it and most distros provide packages
06:46 lispy I guess I'm getting confused.  You said you wanted speed and stability.  But then you said it's not really a problem locally.
06:46 lispy I'm trying to figure out what operations are prohibitively slow for you on the server (or unstable).
06:49 manveru lispy: last time i checked, `darcs pull -av` took like 2 minutes
06:49 manveru same goes for push
06:51 manveru lispy: http://p.ramaze.net/545
06:51 lambdabot Title: RaPaste
06:51 manveru remote side is a darcs1 repo
06:52 lispy Okay, you could try this experiment with a darcs2 binary and that repo, you can add --verbose and it should give you progress indicators
06:52 lispy that's a new darcs2 feature
06:52 lispy that could help us figure out where the time is spent
06:52 lispy goes to try it out
06:53 manveru around 10 seconds figuring out what kind of repo that is
06:54 manveru 65 seconds: "Reading inventory of repository ramaze@ramaze.net:ramaze.darcs          
06:55 manveru that are the two longest operations...
06:55 lispy could be 1) a slow connection 2) a large inventory
06:55 manveru both
06:55 manveru i't like 30 hops away from japan to finnland
06:55 lispy it should be possible to split the invetory.  In fact, I thought that was the default when you tag and optimize.
06:55 manveru but mercurial still manages to do that in like 5 seconds
06:56 manveru what exactly is the inventory?
06:56 lispy it's essentially a list of what patches are in the repository
06:57 manveru ok
06:57 lispy and because you often don't need anything older than the most recent tag you can split the inventory at tags
06:57 manveru but when i tag locally and push that patch it won't split the remote inventory
06:57 lispy I think you're right.  You'd probably have to optimize on the remote end to do that.
06:57 manveru that might explain that...
06:58 lispy I'd have to read up on it
06:58 lispy goes to find the manual
06:58 manveru hmm
06:58 manveru no, that ain't the issue either
06:59 manveru remote _darcs/intentories only has the patches since last tag
07:00 lispy "#
07:00 lispy What happens when you create a tag in the remote repository or push it over? By right, the size of the inventory should drop to zero (starting from the tag you just pushed). If not, your darcs may be slightly buggy wrt tags. darcs optimize should fix it, emptying out your inventory."
07:00 manveru nods
07:00 manveru it does
07:00 manveru but it's still slow as hell
07:02 lispy "These simple steps (tag and optimize) should resolve most of your pushing woes. If not,
07:02 lispy 1. Check to see if the same darcs operation is significantly faster when dealing with a repository that is on the same machine. 2. If you are using ssh, check to see how long a single ssh connection makes"
07:02 lispy I think that http applise in #2 as well.
07:03 lispy manveru: do you have some patches which are large?  Darcs works best with small, say < 4k bytes, patches
07:04 manveru i have some really old large ones
07:06 lispy if they're old and in both repos I would expect that darcs ignores them.
07:06 manveru i'd love to remove them somehow... since they have no influence on the current repo anymore
07:07 lispy yeah, like darcs optimize --delete-old-history?
07:07 lispy (that's not a real feature)
07:07 manveru especially two patches that add and remove some binary blob
07:07 manveru hehe
07:09 lispy This notion of merging patches that cancel each other out, is kind of important.  People ask for a variation on that theme somewhat frequently.
07:09 lispy But, at least superficially, contradicts the purpose of version control
07:10 lispy You should save all history, even bad history, right?
07:11 lispy manveru: Anyway, I wish I could help more.  And to answer your original question.  I don't think anyone knows when the stable darcs2 will hit the shelves.  The good news is that we've had several pre-releases now so hopefully we're getting closer.
07:12 manveru :)
07:12 manveru well, it's old history... over 1.5 years ago...
07:12 manveru and it's not even code
07:13 manveru anyway, thank you for your help
07:14 manveru i would even prefer if the two patches would become one that says: here i added and removed these 5mb, kthxbai
07:14 manveru instead of two 5mb patches
07:15 manveru that's how old mistakes haunt you :P
07:17 lispy yeah
07:17 lispy I can totally relate
07:17 lispy But, if nothing depends on that patch, maybe it can be unpulled?
07:17 lispy but you'd have to do that in every copy...
07:18 manveru yeah...
07:18 manveru a distributing unpull/unrec would be wondeful :)
07:18 manveru could've saved my ass a couple of times already
07:19 lispy an obliterate patch could be cool
07:19 lispy I wonder how hard that would be
07:19 manveru anyway, watch 'ps -P `pgrep ssh`' gave me a better look at what darcs does
07:19 manveru it reads every file in inventories...
07:20 manveru i think that part could be optimized a lot
07:20 lispy it downloaded each one you mean?
07:20 lispy even though you had it locally? and this is with darcs2?
07:21 manveru remote repo is darcs1 mind you
07:21 lispy I wonder if this happens also with hashed repos in darcs2.
07:21 lispy sure
07:21 manveru but local is latest darcs2
07:22 lispy creating a server side copy of the repo that is hashed would be an interesting experiment.  darcs1 cannot read hashed repos, but otherwise hashed is backwards compatible.
07:22 manveru "/usr/bin/ssh -x -oForwardAgent no -oPermitLocalCommand no -oClearAllForwardings yes -q -lramaze ramaze.net scp -f ramaze.darcs/_darcs/inventories/20061017005130-24​576-5b9b427a53262dd1d97f1e687b8f4e5e449160bd.gz"
07:22 lispy That's probably confusing...what I mean is, hashed is just an optimization of darcs1 format.  It doesn't change the semantics.
07:22 manveru this is one of the commands that takes so long
07:23 lispy manveru: can you create a copy of your repository on the server?
07:23 manveru sure
07:24 manveru but i cannot update the remote darcs, unless you have an ebuild around?
07:24 lispy you can use darcs put
07:24 manveru i can't
07:24 lispy no?
07:24 manveru or, do you mean darcs1 format?
07:25 lispy you can create the hashed version locally, then use darcs  put to place it on the server file system
07:25 lispy put is the opposite of get
07:25 manveru yes
07:25 manveru ok, i can try hashed
07:25 manveru thought you meant 2
07:25 lispy I'm curious if having a hashed repo on the server will give you better performance
07:26 lispy manveru: also, you can use a global cache once you start using hashed
07:26 manveru nods
07:27 manveru converts
07:27 lispy converts?
07:27 manveru hmm
07:27 lispy you're not using 'darcs convert' are you?
07:27 manveru no go
07:27 manveru no
07:27 manveru get --hashed
07:27 lispy you scared me for a second :)
07:28 manveru :)
07:28 lispy no go?
07:28 manveru well, it tries to use the --hashed option remotely
07:28 manveru which, of course, doesn't exist
07:29 lispy okay, well you can do this weird thing
07:29 lispy locally: darcs init --hashed foo-hashed; cd foo-hashed; darcs pull server-repo
07:29 lispy maybe that works?
07:30 lispy Or maybe I didn't understand what failed.  THinking about that a bit more.  Darcs get shouldn't have invoked the remote darcs.  So I don't know why it would fail
07:30 manveru darcs put did
07:31 lispy Oh, interesting.
07:31 lispy well, there is no reason why we have to use darcs to put the repo on the server
07:31 manveru i guess darcs put only does a darcs get
07:31 lispy you could just scp -r the whole repo to the server
07:31 manveru sure
07:31 lispy not sure why I thought put would be easier (I must be tired :)
07:32 manveru that might take 30 minutes or so
07:32 lispy okay
07:32 lispy well, once it's there you can try watching ps again
07:32 lispy and do a pull
07:32 lispy see if it's faster for you
07:32 manveru i would use unison, but the versions differ... and gentoo hasn't put in the latest yet
07:32 manveru nods
07:33 lispy careful with unison on darcs repos.  There was a couple threads about repo corruption due to unison a long while back.
07:33 manveru oh?
07:33 lispy The 'sync'ing of repos can be bad if you unpull or something like that
07:33 lispy I forget the details
07:33 manveru right...
07:34 manveru haven't had problems with that yet
07:34 manveru but good to know... i usually use it for testing stuff only
07:34 lispy It seems like you'd have to work in both copies and get them out of sync to trigger it
07:35 lispy you should also experiment with the global cache.  Did you read about that?
07:35 manveru yes i did
07:36 lispy I think the DarcsTwo page needs to be cleaned up
07:36 lispy you said it was not obvious what were the new features
07:36 lispy and it should give a timeline/estimate if possible
07:39 manveru that would be great, yeah :)
07:40 lispy looks like the manual needs to be updated too
07:43 lispy manveru: good luck and good night
07:45 manveru sleep well :)
09:43 manveru darcs: ramaze.hashed/magic darcs standard input: openBinaryFile: does not exist (No such file or directory)
09:44 manveru anyone got an idea how that happens?
09:44 manveru "~/ramaze % ../bin/darcs-2.0.0pre3-linux push -av ../ramaze.hashed"
09:44 manveru happens when pushing from darcs1 repo to hashed
09:46 manveru the other way round it works fine, pushing/pulling from hashed to darcs1 repo
09:48 manveru lispy: in case you're reading this, using the hashed repo takes only around 30s to push/pull and is a lot faster for local operations as well
09:48 manveru so thank you, you saved us from mercurial :)
10:50 manveru i notice that with the darcs version of darcs-unstable the progress is not shown
10:51 manveru it always is at: "Identifying repository ramaze@ramaze.net:ramaze.hashed format", though i see it downloading patches already
11:34 manveru http://darcs.net/cgi-bin/da​rcs.cgi/unstable/?c=browse is kinda empty :)
11:34 lambdabot Title: darcs repository
14:32 manveru ok...
14:32 manveru after one hour, `get --lazy` actually finished
14:33 manveru now i try to record, it tells me that it's: "Reading pristine 126/559 : fdc15c1fdbb7234dea323894d54a116e5fd49774"
14:33 manveru does that mean it will d/l 126 patches?
14:34 manveru since that's what it looks like when i look at the ssh connections...
14:37 manveru some kind of update on the status would be nice... or a round of pong to pass the time
14:41 markstos Good $localtime
14:41 manveru heya
14:44 manveru so, how about making `darcs get` a bit more intelligent?
14:44 markstos How so?
14:44 manveru using `scp -r` instead of scp every single patch
14:45 manveru i'm just running a test to see the difference
14:45 markstos With darcs 1.0.9 or Darcs 2?
14:45 manveru unstable
14:46 markstos Sometimes "get" uses sftp, but I'm not certain in which cases.
14:46 manveru hmh
14:46 manveru well, i got a bit upset when `darcs get --lazy` took an hour
14:47 manveru with unison i have the repo in a matter of minutes
14:47 markstos That sounds frustrating.  You could always make a tarball of the project, download it, and unpack it.
14:48 markstos Great: then you can use unison.
14:48 manveru i could do both, but can my users?
14:48 manveru and no, serverside unison is out of date, and i won't downgrade
14:48 markstos If they are just users and not developers, sure.
14:49 manveru all my users are developers
14:49 manveru so i try to keep the barrier of entry as low as possible
14:49 markstos What about publishing the site to pull from over https ...or just http ?
14:49 manveru the tarball of the repo you mean?
14:50 markstos Right, as an alternative to a one-time "darcs get"
14:50 manveru how about making "darcs get" as effective as "hg clone"? :)
14:51 markstos How does "hg clone" work over ssh/sftp/scp?
14:51 manveru i can give you a breakdown when i watch it closely
14:52 markstos Post it to darcs-devel if you like. I'm not a darcs programmer, so I could only take notes. Of course, if "darcs get" could perform better, that would be great.
14:52 manveru indeed
14:52 manveru i tried to switch to mercurial last week
14:53 markstos From darcs?
14:53 manveru nods
14:53 markstos I hear good things about Mercurial.
14:53 manveru yeah...
14:53 manveru but didn't work out for us
14:53 markstos Is it also patch-centric, like darcs is, or "tree centric" like svn and others are?
14:54 markstos Why didn't it work out?
14:54 manveru it's a different philosophy, kinda like darcs
14:54 manveru but instead of patch dependency they define common parent changesets
14:55 manveru well, the reason for the switch was the speed of darcs
14:55 manveru we have around 2k patches now
14:56 manveru a push/pull would take 2 minutes just to check if anything new is around
14:56 markstos is afk for a bit
14:57 manveru it didn't work out because it's awkward to use for someone used to the sweet user-interface of darcs
14:58 manveru and i didn't like having 2/3 of the projects history just being useless merges without anything that changed
14:58 manveru so now i put my hope into darcs2
14:58 manveru using a hashed repository at first
15:01 markstos manveru: For our big project, we pull over http, and push over ssh. That makes a big speed difference.
15:01 manveru oh really?
15:01 markstos I have also tried "darcs optimize --reorder", but I'm not sure what effect that had.
15:02 markstos Yes, but in our process patches usuall flow one direction ( alpha -> beta -> production ).  
15:02 manveru well, i tried any optimize option they had :)
15:02 markstos However, you could use shell aliases to toggle your repo names back and forth, so you don't have to type the repo name each time.
15:02 manveru hmh
15:03 manveru well, i'd have to make that rake tasks then
15:03 markstos I have explored it, but I know darcs2 can be compiled with several different http options and some of them support pipelining for further speedups.
15:03 markstos For example, you could make a shell script "darcs_push", which calls "darcs push --no-set-default user@host:/home/repo"
15:04 markstos And "darcs pull" would default to pulling over http (over https if you need to)
15:04 manveru yes
15:05 manveru so you don't use a hashed repo?
15:05 markstos At $work, we are still waiting for darcs-2 to be released.
15:06 markstos A key server runs an ancient FreeBSD server that would be difficult to get darcs compiled on. But, the release of darcs 2 will be a reason to upgrade the OS. :)
15:07 manveru hmm
15:07 manveru the binary versions seem to run just fine
15:07 markstos I'm not aware of a binary for FreeBSD 5.1. :)
15:07 manveru oh well :)
15:07 manveru i don't do anything with bsd...
15:08 manveru i thought it would be somewhat compatible with linux
15:09 manveru hmm
15:09 manveru how many patches do you have at work?
15:10 markstos 2000 ? About 40,000 lines of code, last time I checked. I started using darcs about when 1.0 was released.
15:10 markstos That was perhaps 3 years ago.
15:10 markstos It's a huge website: http://www.1-800-save-a-pet.com/
15:11 manveru hmh
15:11 markstos Supporting about 1,500,000 pet searches / day now.
15:12 markstos We use darcs to pull patches into production, and then rsync the site between several front-end web servers.
15:13 manveru i'm only at around 12k LoC for http://ramaze.net - last time i checked was around 2000 patches
15:13 manveru but we had an image in the repo around a year ago... which really bloats the history
15:14 manveru ah, seems like scp is almost done
15:16 markstos Your project looks neat. I'm bookmarking it.
15:16 manveru heh, thanks
15:16 markstos I help maintain the CGI::Application framework for Perl. http://www.cgi-app.org/
15:16 manveru i'm not in the US and not allowed to have pets... so i guess i won't save any pets
15:17 manveru hmm, i've never done perl
15:17 markstos :) I'm sure you'll save some ruby programmers some time, and some people some money through your open source contributions.
15:17 markstos I've only looked at ruby. :)
15:18 manveru well, i only see perls heritage in ruby
15:19 manveru but when i try to actually read perl it seems so strange...
15:19 manveru alrighty
15:19 manveru scp -r ramaze@ramaze.net:ramaze.hashed .  1.21s user 8.50s system 0% cpu 38:51.73 total
15:19 manveru darcs get --partial ramaze@ramaze.net:ramaze.hashed ramaze  6.08s user 4.97s system 0% cpu 59:59.34 total
15:19 markstos There is ugly perl out there. I think Haskell looks strange, but I'm intrigued by it.
15:19 markstos The ruby I see generally looks clean.
15:20 manveru so... seriously
15:20 manveru --lazy should be a _lot_ faster
15:20 markstos Why use --partial instead of --lazy if you have darcs2 ?
15:20 manveru forgot about it
15:20 manveru darcs accepts both, so i kept it
15:21 markstos Maybe you need a recent tag to limit what --lazy downloads? I'm not completely certain how it works.
15:21 manveru i have a recent tag
15:21 manveru only 16 patches back
15:21 markstos There are *several* bugs that crop with --partial repos. The solution in all cases is to quit using --partial and use --lazy instead.
15:22 manveru manveru@sigma ~/c % time darcs get --partial ramaze@ramaze.net:ramaze.hashed ramaze
15:22 manveru --partial: hashed or darcs-2 repository detected, using --lazy instead
15:22 markstos Hah. Cool.
15:22 manveru i trust in that
15:22 markstos So, you did end up using --lazy. Great.
15:22 manveru as i said
15:23 manveru but lazy is so much slower than a scp -r
15:23 manveru and it's not even the full repo
15:23 markstos You can file a "wishlist" item at bugs.darcs.net for --lazy to perform better, if you'd like.
15:24 markstos Linking to example public repos is always helpful.
15:25 manveru hmh
15:25 manveru well, our repo has been through quite some stuff :)
16:44 droundy manveru: darcs 2 is much faster if you compile with libwww (or a very recent version of libcurl) due to pipelining.
16:45 manveru droundy: it takes 7 minutes, compared to 40 minutes for scp
16:45 markstos droundy: why not compile with libwww by default then?
16:46 droundy markstos: very few poeple have the libwww-dev packages installed, and it doesn't give as nice error messages.
16:46 droundy manveru: you mean 40s for scp?
16:47 droundy manveru: what format is your repository?
16:47 manveru 40s?
16:47 manveru hashed format
16:47 droundy I thougt you said lazy was slower than scp.
16:47 manveru it is
16:47 droundy but 7 minutes is less than 40 minutes...
16:47 manveru droundy: http://bugs.darcs.net/msg3494
16:48 droundy oh, I see.  you don't have darcs 2 installed as the default darcs on your server?
16:48 markstos droundy: Do you know if libwww is packaged for distributions? Or if it is the best option, could we redistribute it?
16:48 droundy markstos: yes, it's in debian.
16:49 manveru droundy: no
16:49 manveru all i could do was put the precompiled one into ~/bin and export that to PATH
16:49 manveru but it seems like .bashrc isn't respected with ssh
16:50 droundy manveru: try installing darcs 2 on the server, and you should get much faster get times.
16:50 manveru it's gentoo, don't have an ebuild
16:50 droundy you may need to stick the PATH definition in .profilerc
16:50 markstos droundy: So we could get the debian and ubuntu packages to be built with libwww.
16:50 droundy markstos: yes.
16:50 droundy s/profilerc/profile/
16:51 markstos Is the minimum GHC version 6.4 now? I just saw 6.2 in the docs and could update it.
16:52 droundy I think the minimum is 6.4
16:53 markstos droundy: so I can update the "Prerequisites" docs, is the order of preference (if they are available): libwww, libcurl, curl and wget.
16:54 manveru droundy: no go with ~/.profile either
16:54 droundy markstos: something like that
16:54 manveru sometimes i wished there was a verbose version of login...
16:55 droundy manveru: maybe your .bashrc has some sort of check whether it's an interactive session? debian's default has something like that.
16:56 manveru droundy: you are right, indeed :)
16:56 droundy :)
16:56 manveru sweet
16:56 manveru that means i will be able to push to the hashed repo now?
16:58 manveru and it works
16:58 manveru droundy: thanks a lot
16:58 manveru now, on to retry darcs get...
17:01 manveru droundy: that doesn't look any faster to me...
17:02 manveru it's still doing things like: "scp -f ramaze.hashed/_darcs/pristine.hashed/3​c441052c172fc7a3ce8134562145a43af5e40"
17:02 markstos droundy: I hope my recent bug triaging hasn't felt overzealous. I've been more assertive about updating the status of things. I figure even if I make some different decisions, it's a net-positive, and wiki-style, anyone else can change the status if they disagree.
17:02 markstos I think it's a good deal clearer now which bugs really need attention, and which are "deferred", if not resolved.
17:03 manveru darcs get over ssh is still magnitudes slower than over http :|
17:04 manveru and it never actually uses the remote darcs installation, so i doubt darcs2 makes any difference remotely
17:07 manveru huh
17:11 manveru http://p.ramaze.net/551
17:12 manveru this doesn't look good
17:14 manveru --debug-verbose says that happens when it comes to the compressing
17:14 markstos mail sending works automatically on Windows, without sendmail, right?
17:26 droundy manveru: in that case it isn't making the connection.  Maybe the static binary on the server is too old? You should see right at the beginning when it tries to make the ssh connection with darcs 2.
17:27 droundy markstos: I like your bug triaging.
17:27 droundy manveru: can I see the --debug output of your darcs get?
17:28 droundy manveru: is darcs2 on the remote server named darcs?
17:28 manveru droundy: yes
17:28 markstos droundy: Thanks. I just "sent" some  doc-patches for the pre-req section.
17:29 droundy markstos: I'm not sure when I'll have a chance to apply them... today I'm taking a break from darcs hacking.
17:29 markstos droundy: I've always appreciated your  life/hack balance.
17:30 markstos http://bugs.darcs.net/ reports only 60 issues that need short-term attention now. That's encouraging.
17:30 manveru droundy: http://p.ramaze.net/552
17:30 markstos Although there are plenty of deferred and wishlist items waiting to be put on a TODO list for Darcs 3. :)
17:53 droundy manveru: it's definitely not making the transfer-mode connection, not sure why... I should add more debug output when the connection fails...
17:53 droundy :(
19:31 lispy markstos: how did you and kowey became certain that bytestring caused the bus error?
19:42 markstos lispy: in the ticket, kowey said that when he tried again with bytestring disabled, the problem went away.
19:43 lispy Oh, I didn't see that part of his email
19:44 lispy is investigating the problem he had with the Hopefully patch
19:45 markstos Great. Thanks lispy.
19:46 markstos Shell question: In darcs test scripts we tend to use "set -ev".  However, in this test script, it is correct for a particular command to fail. how do I handle that so overall test script still continues?
19:47 lispy I'm not sure, I'm a perpetual newbie with sh
19:47 lispy you could turn off set -ev, run the command, check $?, and then turn it back on?
19:48 markstos hmm.. possibly.
19:48 lispy there is likely a general solution though
19:57 scode Anyone using darcs on freebsd/amd64? If so, how did you bootstrap ghc?
19:57 scode I am tring to find a lazy man's way out to get ghc running on said platform ;)
19:58 scode Hopefully doing something about lang/ghc in ports.
19:58 markstos scode: There weren't binary packages for you?
19:59 scode No official upstream for freebsd/amd64, and the port has no magic of its own as of now. Trying to figure out whether I am going to have to do it from scratch, but figured *someone* probably has it running already.
20:00 markstos I would try the #haskell channel.
20:00 scode Sounds like an idea. Dunno why I didn't think of that. :) Thanks.
20:00 scode WIll do so later on; about to leave.
20:03 lispy scode: you could also ask in #ghc potentially.  That's probably a decent way to let them know that platform is in demand.
20:04 scode Well, not trying to make someone go to lengths for it. But if someone has done the work I'd prefer to re-use it. Especially since I figure that the lack of a fix already indicates there might be something non-trivial about it.
20:04 lispy I'm sure if they don't want to work on it, they'll say so :)
20:05 lispy (or, the more polite way of phrasing that, "It can't hurt to ask") :)
20:05 scode :)
20:05 scode Will see what they say when I'm back or tomorrow.
20:05 lispy sure
20:05 lispy good luck
20:07 markstos This bug report indicates the port is still in progress: http://hackage.haskell.org/trac/ghc/ticket/838
20:07 scode Yeah I found that, but hasn't been updated in a while.
20:07 scode Will see.
20:07 sm notes: darcs support in ikiwiki: http://ikiwiki.info/rcs/details/#index3h2 . darcs support in ohloh: http://www.ohloh.net/forums/3491/topics/1138

| Channels | #darcs index | Today | | Search | Google Search | Plain-Text | summary