02:09:47 <stepcut> happstack 0.5.0 release party! Everyone have a beer!
02:34:18 <stepcut> shapr: http://i.imgur.com/ViSf8.png
02:38:15 <shapr> stepcut: haha!
02:39:53 <Zao> So what's new and shiny?
02:51:49 <stepcut> Zao: http://www.facebook.com/l.php?u=http%3A%2F%2Fwww.haskell.org%2Fpipermail%2Fhaskell-cafe%2F2010-May%2F077218.html&h=ec7c3
02:51:55 <stepcut> one moment
02:52:03 <stepcut> Zao: http://www.haskell.org/pipermail/haskell-cafe/2010-May/077218.html
02:57:56 <aavogt> hey stepcut, the docs here seem to be malformed: http://happstack.com/docs/0.5.0/happstack/HSP-Google-Analytics.html
02:58:17 <stepcut> aavogt: malformed /
02:58:17 <aavogt> as in, I think you need a space between the  -- |, and the text
02:58:18 <stepcut> ?
02:58:21 <stepcut> ah
02:58:26 <aavogt> as in, not there
02:58:56 <aavogt> ACTION would blame haddock here
03:01:37 <stepcut> pushed a patch, thanks
03:01:46 <stepcut> I just assumed I hadn't written any docs ;0
03:02:11 <stepcut> but documentation is our #1 priority now :)
03:05:27 <stepcut> first task will be to merge the two scripts we have for generating the haddock stuff into one working script :)
03:06:09 <aavogt> what happened there?
03:06:28 <stepcut> there ?
03:06:42 <aavogt> as to why there are two separate scripts
03:08:02 <stepcut> the person who generated the 0.4.3 docs for the happstack.com site, left the script they used in the tar of the generated docs they gave me. But I didn't noticed until today. Someone submitted a patch for generating docs from the darcs repo a while back.
03:08:17 <stepcut> need to merge the two though
03:08:31 <stepcut> the one in happstack.com gets all the packages from hackage
03:08:47 <stepcut> the one in happstack does not put everything into a single directory
03:09:09 <aavogt> :(
03:09:16 <aavogt> I think I did the ones for the site
03:09:26 <stepcut> so I want the happstack one do to what the happstack.com one does, but using the local happstack source, not the ones from hackage
03:09:32 <stepcut> aavogt: :)
03:09:52 <stepcut> aavogt: well I used it for 0.5.0 -- which some minor changes  -- such as changing the directory name to 0.5.0 ;p
03:11:40 <aavogt> but of course, that stuff for the index making is stolen mostly from ghc's script to generate the index
03:12:13 <stepcut> :)
03:16:36 <aavogt> stepcut: I use something like this for docs from darcs: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=25316#a25316
03:16:59 <stepcut> aavogt: yeah, that looks like the code that is used to generate the docs on the site
03:17:15 <aavogt> yeah, lots of copy-pasta
03:23:20 <shapr> yarr
03:30:09 <stepcut> arr, it's drivin' me nuts
10:00:14 <Entroacceptor> stepcut: can't cabal install happstack on my server, ixset depends on quickcheck==2, which is missing
10:00:33 <Entroacceptor> debian with ghc-6.12
10:02:04 <Entroacceptor> or wait, qc-2.1 is on hackage...
10:02:21 <Entroacceptor> weird
13:07:53 <stepcut> Entroacceptor: it's not really clear why it depends on QuickCheck 2.. because it shouldn't..
13:26:50 <stepcut> I think that even though the happstack-ixset-tests executable is set to, Buildable: False, those dependencies are still leaking into the system somehow..
13:27:12 <stepcut> on my GHC 6.10, it just causes cabal to d/l and install QC
13:27:20 <stepcut> maybe in later versions the problem is half-fixed
13:27:49 <dcoutts> stepcut: yes, non-buildable components contribute to the package deps
13:28:02 <dcoutts> fixing that turned out to be harder than I thought
13:28:17 <stepcut> dcoutts: so we are seeing something weirder though
13:29:18 <stepcut> dcoutts: when people cabal install happstack, they get an error,
13:29:19 <stepcut> Configuring happstack-ixset-0.5.0...
13:29:20 <stepcut> cabal: At least the following dependencies are missing:
13:29:20 <stepcut> QuickCheck ==2.*
13:29:55 <stepcut> but if they cabal install QuickCheck, then it works ..
13:30:11 <dcoutts> stepcut: are they using cabal-install-0.8.0 with Cabal 1.8.0.2 ?
13:30:18 <stepcut> why does cabal decide it depends on QuickCheck, but decide not to d/l it ?
13:30:38 <dcoutts> sounds like they're using the version where I tried to fix the problem with non-buildable components contributing to the package deps
13:30:48 <dcoutts> but it didn't work out and I had to revert it
13:30:54 <stepcut> ok
13:30:58 <dcoutts> it works again in cabal-install-0.8.2 with Cabal 1.8.0.4
13:31:11 <stepcut> thanks. I'll post that in my followup
13:31:26 <dcoutts> Entroacceptor: perhaps you can try that
13:31:43 <stepcut> for now I moved the Build-depends so that they are guarded by the tests flag. Though really, we need to put the tests in separate package(s) I guess
13:32:11 <stepcut> or maybe we should wait to see what the GSoC cabal test people come up with ?
13:33:32 <dcoutts> stepcut: that will likely not make any difference
13:33:55 <dcoutts> if the test flag is on by default at least
13:34:16 <stepcut> the test flag is off by default
13:34:50 <stepcut> the core issue is that depending on QC2 right now causes a lot of problems, because a lot of other libraries use QC1
13:35:00 <dcoutts> yes, I know :-(
13:35:23 <dcoutts> cabal has to be conservative, it does not know that QC1 and QC2 most likely will live together happily
13:35:45 <dcoutts> it has to assume that it could be as bad as the bytestring-0.9.0.1 vs bytestring-0.9.0.2 issue
13:36:02 <stepcut> but happstack does not really need to depend on any version of QC for most people, so we did the wrong thing and made the tests only compiled when a flag is enabled.. which caused other problems because we broke the rules
13:36:25 <dcoutts> ah because the tests are exported as a public API ?
13:36:40 <stepcut> yeah
13:36:53 <dcoutts> right, public API has to be independent of flags
13:37:02 <stepcut> so we really just need to put the tests in a seperate package or set of packages
13:37:15 <dcoutts> or wait for the cabal test support
13:37:26 <stepcut> right
13:37:33 <dcoutts> oh, but these are public API, so that's not relevant
13:38:15 <stepcut> well, maybe.. it depends on what the cabal test support offers. Maybe we won't desire them to be public at that point..
13:38:23 <dcoutts> if you want it exported then you have to do it unconditionally
13:38:31 <dcoutts> in the main package or a separate package
13:38:37 <dcoutts> cabal test support helps for testsuites
13:39:02 <dcoutts> and lets users or other test agents run them automatically
13:40:00 <stepcut> dcoutts: oh, one user that reported that install error is indeed using cabal-install 0.8.2 and cabal 1.8.0.2
13:40:32 <dcoutts> stepcut: ok, the fix is in Cabal library version 1.8.0.4, cabal-install must be built against that version of the Cabal lib
13:40:34 <stepcut> dcoutts: does it provide an system for aggregating tests from multiple packages ?
13:40:58 <dcoutts> stepcut: no, a way of providing a testsuite with a package and running it automatically and collecting results
13:41:20 <dcoutts> stepcut: however there is nothing to stop your testsuite depending on multiple other packages
13:41:29 <dcoutts> and running code exported by them
13:41:32 <stepcut> so, we should put our tests in a seperate package then ?
13:41:51 <dcoutts> stepcut: I don't know, it depends on what your tests are for
13:42:04 <dcoutts> do you want servers to be able to run self-checks?
13:42:09 <stepcut> dcoutts: yes
13:42:11 <dcoutts> is it actually intended as a public API
13:42:16 <dcoutts> ok then, it must be exported
13:42:19 <dcoutts> and unconditionally
13:42:20 <stepcut> dcoutts: yes
13:42:31 <dcoutts> so you can either do that in each package, or separately
13:43:01 <stepcut> dcoutts: yeah. Directly in the package was nice, except for the QC issue. So I guess we will do separately.
13:43:06 <dcoutts> if it's separate it can only use the public APIs of the packages it is testing
13:43:23 <dcoutts> but it would remove the QC dep from the main packages
13:43:39 <dcoutts> stepcut: I might be inclined to keep it, the QC problem will get less bad over time
13:43:49 <stepcut> dcoutts: yeah.. I am not sure we have private APIs, but that is certainly something to keep in mind
13:44:00 <dcoutts> as people move to QC2 and when we improve the tools to handle private deps better
13:44:06 <stepcut> dcoutts: yeah, that is my other hope
13:44:13 <dcoutts> eg the new platform release uses QC2
13:44:21 <dcoutts> which is the signal for everyone to move
13:44:23 <stepcut> dcoutts: I don't really want them in a separate package
13:48:32 <stepcut> if people built happstack-ixset prior to my patch, then they are going to have QuickCheck 2 vs QuickCheck 1 issues, even though the actually code did not link against QuickCheck, right ?
13:54:40 <stepcut> thanks!
14:03:02 <dcoutts> stepcut: honestly I'm not quite sure :-)
14:04:16 <stepcut> dcoutts: I think it will.. cabal does not yet have the smarts to check for unused dependencies
14:05:08 <dcoutts> stepcut: it's probably quicker to test than for me to think it through :-)
14:49:25 <rdtsc> can happstack be run by hugs?
20:44:48 <stepcut> rdtsc: highly unlikely
20:45:30 <stepcut> rdtsc: requires template haskell among other things