02:30:23 <alpounet> ok stepcut, i have the shell script that generates the package index 02:32:25 <alpounet> it's just ( echo preferred-versions; find . -maxdepth 3 -name '*.cabal' | cut -c3- ) | tar -c -T - -f - | gzip -9 >$tmp 02:32:52 <alpounet> where preferred-versions is just : base < 4 network < 2.2.3 || >= 2.2.4 02:33:08 <stepcut> ooo 02:33:19 <stepcut> now we just need to make it into Haskell code :p 02:34:02 <stepcut> in the builder we will probably have the package decriptions already parsed as the 'PackageDescription' type 02:34:06 <stepcut> from the Cabal library 02:35:36 <alpounet> i believe there already are libraries for tar and gzip 02:36:42 <alpounet> i would gladly rely on these, wouldn't you? :P 02:37:26 <stepcut> yes 02:37:50 <alpounet> oh my 02:38:00 <alpounet> almost 4AM 02:38:07 <stepcut> ! 02:38:38 <alpounet> i'm off to bed 02:39:04 <alpounet> but i saved the scripts so i can just start working for a Haskellized version of these whenever i have some spare time 02:39:25 <alpounet> s/for/on/ 02:39:43 <stepcut> cool 02:40:28 <alpounet> 'night 02:40:36 <stepcut> does the index file contain the paths to the .tar.gz files? Or are they expected to live at some place that can be automatically calculated? 02:41:52 <alpounet> the latter 02:42:06 <stepcut> so, the tar.gz is just a bunch of .cabal files concatted together? 02:42:09 <alpounet> <pkg>/<version>/<pkgid>.tar.gz 02:42:21 <alpounet> yeah 02:42:32 <alpounet> with some potential additional informations 02:42:36 <alpounet> like the preferred-versions thing 02:42:45 <alpounet> see http://hackage.haskell.org/trac/hackage/wiki/HackageDB#Structure 02:42:46 <stepcut> so, we should have a function like, generateIndex :: [PackageDescription] -> FilePath -> IO () 02:42:59 <stepcut> ah cool 02:43:08 <alpounet> yup 02:43:12 <stepcut> that is a useful link :) 02:44:12 <stepcut> oh.. it is even easier than I thought 02:44:37 <stepcut> the .tar.gz just contains a bunch of tar'ed up .cabal files 02:44:58 <stepcut> it's, .tar.gz, not just a .gz with a single file in it 02:45:48 <alpounet> that should not be too hard to reproduce indeed 02:46:04 <alpounet> anyway, i'm off to bed, i'll give this a shot soon 02:46:25 <stepcut> k 02:46:57 <stepcut> I think we want, generateIndex :: [FilePath] -> FilePath -> IO (), where [FilePath] is a list of the .tar.gz files generated by cabal sdist.. 02:47:29 <stepcut> you give it is list of input .tar.gz files, and it generates the entire hackagedb structure in the output directory, or something 10:23:06 <alpounet> stepcut, hm, why would we give it a list of .tar.gz files? 10:23:24 <alpounet> 'cause we'd download the .tar.gz's for the packages, and start from there? 11:07:45 <alpounet> stepcut, i'm writing a few helper functions for the generateIndex thing 14:32:38 <alpounet> have to go 14:33:08 <alpounet> just one bug to fix, and i have a part of the package index thing working 14:36:02 <alpounet> seems to be ok now 14:46:10 <donri> how liberal do you want to be with commit rights? patch-tag and darcs doesn't seem to lend themselves nicely to per-user repos 14:47:02 <alpounet> well 14:47:11 <alpounet> if you want to contribute i could just add you to the repo 14:47:19 <alpounet> stepcut, change pushed 14:47:33 <donri> i want to contribute *if i find something i can contribute*, which i don't know up-front :) 14:47:42 <alpounet> well 14:47:48 <alpounet> we have like tons of things to do 14:48:00 <alpounet> pretty sure you can find something, if you feel motivated 14:48:09 <donri> i'll take a look some time 14:48:13 <donri> i'm dag on patch-tag 14:49:29 <alpounet> alright, just added you 14:49:46 <donri> cool 14:50:02 <donri> ACTION replaces all license notices with gpl affero 14:50:52 <alpounet> hah 14:50:54 <alpounet> alright, just removed you 14:51:00 <alpounet> (kidding) 14:51:42 <donri> ;) 15:05:43 <stepcut> donri: in what does darcs not lend itself well to per-user repos? 15:08:02 <donri> i don't know. to me darcs is an opaque black box and about as useful as subversion. i mainly meant patch-tag in that regard anyway :) 15:08:41 <donri> but for instance the lack of branching 15:08:54 <donri> doesn't exactly encourage a distributed workflow 15:08:56 <stepcut> patch-tag is lacking compared to github 15:09:06 <stepcut> distributed in what way? 15:09:33 <donri> distributed as opposed to centralized with a single repo, commit rights and a linear history 15:10:11 <donri> with git/hub each user easily has their own fork of the mainline repository and lots of feature branches 15:10:48 <stepcut> with darcs, as soon as you do a 'darcs get', you already have your own fork of the mainline 15:10:49 <donri> with darcs the only branching you have is repository cloning, aka. on the level of subversion 15:11:15 <donri> it means you have to manage branching manually 15:11:29 <donri> it means you can't easily share a cabal-dev environment between "branches" for example 15:11:40 <donri> it's just too much work to even bother with 15:12:03 <stepcut> why do you need so many branches? 15:12:11 <donri> why not? 15:12:19 <donri> that's a very darcs thing to ask ;) 15:12:31 <donri> if you've tasted the power of git, there's no going back 15:13:02 <donri> it's a matter of structure 15:13:10 <donri> like asking why you need a module system in a programming language 15:14:29 <donri> the closest thing darcs have is "spontanous branches"; promoted as a power feature, but in reality a complete hack 15:14:48 <donri> like calling the name mangling in C/PHP "powerful modules" 15:15:44 <donri> (and something i suspect is easy to do in git, should you want to.) 15:16:08 <donri> --grep=<pattern> 15:16:10 <donri> Limit the commits output to ones with log message that matches the specified pattern (regular 15:16:12 <donri> expression). 15:16:14 <donri> (git log) 15:18:45 <donri> excuse the strong emotions :$ 15:20:17 <stepcut> so your two biggest complaints about darcs so far are that patch-tag is not as good as github, and there are no in-repo branches? 15:21:01 <donri> i guess those are the primary complaints yes 15:21:56 <donri> i suspect most of my other annoyances are based in my lack of expertise with darcs, rather than something lacking in darcs 15:24:14 <donri> and in part that darcs is simply less complete due to lower momentum (for example nothing comparable to git clean -fdx) 15:25:08 <donri> and I really don't like the "interactive", though i suspect that's a matter of configuration/using the right switches 15:26:57 <stepcut> it is usually only interactive if you forget to specify a required argument 15:27:08 <stepcut> instead of aborting with an error, it just asks you 15:32:31 <donri> minor annoyance: _darcs instead of .darcs. messes with my toolchain -.- 15:32:44 <donri> for example "tree" defaulting to not list hidden files 15:33:57 <donri> or fuzzy finder in vim for that matter 15:37:03 <stepcut> heh, there is a lot of discussion on that, though no really compelling arguments, http://bugs.darcs.net/issue129 15:37:17 <stepcut> bbiab 15:56:03 <mightybyte> It strikes me that people who view a repository in a snapshot-oriented manner probably prefer git and those who take a patch-oriented view probably prefer darcs. 16:03:39 <mightybyte> I suppose you could say that darcs is the first derivative of git. :P 20:01:28 <stepcut> scoutess should probably build and publish the haddock docs as well .. building them is a requirement anyway since it can fail if the comments contain invalid syntax 20:06:59 <stepcut> but it would also be nice to have up-to-data haddocks that tracked the darcs repos 20:09:32 <donri> agreed 20:14:11 <donri> perhaps even building docs for all dependencies with a shared index? 20:14:42 <donri> the crosslinking in haddock is killer 20:15:13 <stepcut> yes 20:15:32 <stepcut> we do that up to a point in the currenty docs on happstack.com.. but it could be better 20:15:35 <donri> also if a dependency package or version isn't on hackage yet ... not sure if that's part of the plan but if it is 20:15:36 <stepcut> and entirely automatic 20:15:49 <stepcut> right now there is too much manual labor involved, so the docs do not get regenerated as often as they should 20:17:32 <stepcut> also, right now there is a single index for all the happstack packages.. which is too confusing 20:17:53 <stepcut> should be easier to see the haddock docs for just only package like happstack-server or happstack-hsp 20:18:00 <stepcut> but still have things cross-linke 20:18:01 <stepcut> d 20:18:14 <donri> maybe have both, if sanely possible 20:20:25 <donri> i'm finding it difficult to contribute to scoutess at this point because it's all rather abstract at the moment... 20:38:56 <stepcut> donri: yeah, there will be more to do soon 20:39:18 <stepcut> still working on making the big picture consistent 20:42:48 <stepcut> i think we need a wrapper around System.Process that uses Pipes so that we can log the build results 23:33:41 <alpounet> stepcut, seen my patches ?