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 ?