19:48:40 <aavogt> in which order should I get a database connection and run simpleHTTP?
19:49:15 <aavogt> should there be one connection per response, or one connection for the life of the app?
19:52:48 <stepcut> I would connect to the database before starting to accepting incoming requests
19:53:25 <mightybyte> stepcut: So the change in QC dependencies now conflicts with another library.
19:53:33 <stepcut> but it also depends on the database.. for example, MySQL had some issues with multiple threads and overlapping queries
19:53:42 <stepcut> mightybyte: sweet!
19:53:53 <mightybyte> stepcut: :(
19:54:02 <stepcut> mightybyte: I see no solution except to using runhaskell so that the warning is ignored, or for everyone to upgrade to QC2
19:54:38 <stepcut> mightybyte: at least happstack isn't holding up the train to QC2 land anymore ;)
19:55:07 <stepcut> what library is conflicting now?
19:55:14 <mightybyte> In #haskell, ivanm seemed to think that it's not good to include testing libraries as package dependencies.
19:55:20 <mightybyte> Crypto
19:55:28 <mightybyte> (used by happstack-auth)
19:56:09 <aavogt> the dependencies can be made optional though
19:56:17 <stepcut> mightybyte: well, happstack-util provides functions to turn quickcheck tests into hunit tests... we can't not depend on QC2 and still provide that functionality
19:56:47 <mightybyte> aavogt: How can it be made optional?
19:57:20 <stepcut> aavogt: that is actually not allowed. You can not have flags which change the API which is exported
19:58:40 <aavogt> even considering CPP here?
19:58:55 <stepcut> aavogt: it can be done, it is just not allowed..
19:59:04 <mightybyte> lol
19:59:07 <aavogt> depends how you have the tests organized... they could just be in separate binary
19:59:37 <stepcut> aavogt: but that is not the problem here. The problem is that happstack-util exports a function which turns quickchecks into hunit tests
20:00:06 <stepcut> aavogt: we could put that in a separate library, and put all the tests in separate libraries as well
20:00:29 <aavogt> you can also put those functions in a separate module
20:00:59 <stepcut> aavogt: they already are in separate modules..
20:01:00 <aavogt> I'm 100% sure that takusen has some stuff in the .cabal file to enable modules given specific flags
20:01:11 <stepcut> aavogt: yes, I am 100% sure that is not allowed
20:01:48 <mightybyte> <sighs>
20:01:51 <aavogt> http://hackage.haskell.org/packages/archive/Takusen/0.8.5/Takusen.cabal
20:02:10 <aavogt> If flag(blah); ExposedModules: ...
20:02:24 <stepcut> yes.. that is not allowed
20:02:26 <aavogt> or am I still missing something?
20:02:35 <stepcut> here is the problem
20:02:47 <aavogt> hackage won't accept such packages anymore?
20:03:00 <stepcut> how does another library depend on the version of takusen that has those modules enabled?
20:03:21 <aavogt> you can't
20:03:39 <stepcut> aavogt: so cabal install won't work then, right?
20:04:38 <aavogt> only if people actually use those missing modules
20:05:03 <stepcut> well, if no one is using them, then might as well delete them ;)
20:06:53 <aavogt> are people using these functions?
20:07:14 <aavogt> I guess they are, otherwise we wouldn't have such troubles with them...
20:09:29 <stepcut> there are really only two correct solutions -- we always export the test utility functions and tests in happstack-*, or we move all of those functions into separate packages
20:09:58 <stepcut> happstack-util-tests.cabal, happstack-data-tests.cabal, etc
20:11:34 <stepcut> I would accept a patch that did the latter
20:13:08 <mightybyte> What about not exporting the test utility functions?
20:13:25 <aavogt> is it possible to get ghci to run trhsx?
20:14:06 <stepcut> mightybyte: not exporting them ever?
20:14:36 <stepcut> mightybyte: the tests in the other happstack-* libraries use those functions, so they have to be exported somewhere
20:14:45 <stepcut> aavogt: yes
20:14:53 <mightybyte> Which functions are these?
20:15:05 <stepcut> aavogt: just put {-# OPTIONS -F -pgmFtrhsx -fno-warn-orphans -Wwarn #-} at the top of the .hs file
20:15:28 <stepcut> aavogt: you can not have it run trhsx on things you input directly at the command prompt as far as I know
20:15:54 <stepcut> mightybyte: happstack-util/src/Happstack/Util/Testing.hs
20:16:15 <stepcut> mightybyte: some of the tests in happstack-state are quickchecks -- but our testing framework is based on hunit
20:16:28 <aavogt> thanks stepcut
20:17:38 <mightybyte> stepcut: Hmmm, that code doesn't depend on Happstack.  Seems like it could go into HUnit or QuickCheck.
20:18:13 <stepcut> mightybyte: yes, most of the code in happstack-util is not happstack specific and could go somewhere else..
20:19:08 <stepcut> mightybyte: that module actually come from haskell-extra, but depending on that seemed even worse :)
20:19:10 <mightybyte> Grrrr, this is an annoying problem.
20:19:38 <stepcut> yes, dependencies are an endless source of annoyance
20:20:05 <mightybyte> What to do...
20:20:16 <stepcut> use runhaskell Setup  ;)
20:20:32 <stepcut> or patch Crypto ?
20:20:48 <mightybyte> I'm looking at that.
20:21:02 <stepcut> or submit a patch that splits all the testing stuff out into separate packages
20:21:20 <mightybyte> Looks like Creighton is the maintainer of Crypto.
20:21:37 <stepcut> yes
20:21:56 <mightybyte> He'll probably accept a patch.
20:22:34 <stepcut> it would also be swell if Crypto did not depend on NewBinary.. but that is harder
21:14:46 <dcoutts> aavogt: conditional modules in the takusen style is not really allowed
21:14:46 <lambdabot> dcoutts: You have 2 new messages. '/msg lambdabot @messages' to read them.
21:14:54 <dcoutts> though we don't actually prevent it
21:14:59 <dcoutts> it breaks packaging assumptions
21:17:21 <stepcut> dcoutts: so now that happstack uses QC2, that means any library that you want to use with happstack that depends directly or indirectly on QC must also use QC2?
21:17:56 <dcoutts> sadly, yes
21:18:03 <stepcut> ok, just checking
21:18:27 <stepcut> HaXml is going to be a pain in that regard
21:18:29 <dcoutts> and in your case you actually export QC stuff, it's not just a private dependency
21:18:40 <dcoutts> QC2 will be in the next HP release
21:18:50 <stepcut> nifty
21:18:56 <dcoutts> so everyone is going to be encouraged to update anyway
21:19:12 <stepcut> is HaXml 1.20 going to be in the next HP release?
21:19:15 <dcoutts> no
21:19:20 <dcoutts> it's not been proposed
21:20:07 <stepcut> it should probably be proposed since 1.13 is officially dead now.. and 1.20 is stable
21:20:21 <stepcut> assuming any version of HaXml is in HP
21:20:47 <dcoutts> I'd be happy to see HaXml proposed for the HP
21:21:11 <dcoutts> though it'll be an interesting one, what with there being 3 other xml libs that also might want to try
21:22:05 <dcoutts> DB, xml and GUI are going to be the fun ones to get into the HP
21:22:14 <stepcut> HaXml 1.20 is certainly a bigger challenger than 1.13
21:22:22 <stepcut> DB == happstack-state ;)
21:22:45 <dcoutts> yes, it would obviously be 1.20+ and not the old 1.13
21:22:57 <dcoutts> if any version of HaXml were to be added
21:23:11 <stepcut> right
21:24:10 <stepcut> dcoutts: cabal install sometimes fails with ghc-pkg dump failed under 6.13.. am I doing something wrong? Or just too new for cabal?
21:24:36 <stepcut> or maybe too new, but not new enough..
21:25:26 <dcoutts> stepcut: what version of cabal-install, Cabal and ghc?
21:27:00 <stepcut> ah, it seems my cabal-install is still at 0.6.2 using 1.6.0.3
21:27:16 <stepcut> but the other parts are, The Glorious Glasgow Haskell Compilation System, version 6.13 and Cabal-1.9.0
21:27:19 <stepcut> that can't be good :)
21:28:04 <stepcut> I am guessing that upgrading to 0.8.0 would help things
21:28:15 <stepcut> or should I get it from darcs?
21:30:22 <dcoutts> stepcut: cabal install -w ghc-6.10.4 'cabal-install >= 0.8'
21:30:50 <stepcut> what does the -w ghc-6.10.4 do ?
21:31:05 <dcoutts> use that version of ghc to do the build
21:31:18 <dcoutts> since that version of cabal cannot use 6.12
21:31:33 <stepcut> ah.. guess I just won't use it for now
21:31:44 <dcoutts> change as appropriate for whatever older version of ghc you've still got
21:32:03 <stepcut> the oldest I got is 6.13 :)
21:32:05 <dcoutts> if you only have 6.12 now then you need to boostrap cabal-install again
21:32:16 <vki> map (+2) [1..10]
21:32:34 <stepcut> [3,4,5,6,7,8,9,10,11,12]
21:35:54 <vki> @help
21:35:55 <lambdabot> help <command>. Ask for help for <command>. Try 'list' for all commands
21:36:10 <vki> @list
21:36:10 <lambdabot> http://code.haskell.org/lambdabot/COMMANDS
21:36:18 <stepcut> vki:  if you want lambdabot to do it, you gotta preface it with >
21:36:22 <stepcut> > map (+2) [1..10]
21:36:23 <lambdabot>   [3,4,5,6,7,8,9,10,11,12]
21:36:41 <vki> >map (+2) [1..10]
21:36:53 <stepcut> need a space after >
21:36:58 <vki> > map (+2) [1..10]
21:36:59 <lambdabot>   [3,4,5,6,7,8,9,10,11,12]
21:37:29 <vki> thanks, and how to get to @pl commands?
21:37:53 <stepcut> @pl \f x -> map f x
21:37:53 <lambdabot> map
21:37:56 <stepcut> ?
21:38:10 <stepcut> 
ACTION is not really up on the state of the art lambdabot commands

21:39:14 <vki> > @
21:39:15 <lambdabot>   <no location info>: parse error on input `@'
21:39:34 <vki> > @pl \f x -> x*x
21:39:36 <lambdabot>   <no location info>: parse error on input `@'
21:39:44 <vki> @pl \f x -> x*x
21:39:45 <lambdabot> const (join (*))
21:46:38 <McManiaC> good old join
21:46:39 <McManiaC> :)