--- Log opened Tue Jan 27 00:00:08 2009
02:04 < mae> wheeee
02:15 < mae> squashed issue #1
02:29 < mae> 8 outstanding issues for 0.1
02:29 < mae> http://code.google.com/p/happstack/issues/list?can=2&q=label%3Amilestone-0.1
02:29 < mae> night all
06:37 < koeien> soooooooo i'm ready to set up the build-bot
06:37 < koeien> awake again
06:42 < Saizan> and the build on 6.8 is broken again :)
06:43 < koeien> :)
06:43 < koeien> i can set up 6.8.3, 6.10.1 (and 6.6 but i think nobody's interested in that)
06:47 < Saizan> we use type families so it won't build on 6.6
06:49 < koeien> weren't type families severely broken on 6.8 ?
06:49 < koeien> well, appearantly not :/
06:55 < Saizan> we use them only to associate a list of types with each component
06:59 < koeien> instead of fundeps?
07:00 < Saizan> yeah
07:10 < Saizan> ok, now it builds again :)
07:12 < koeien> so, nightlies and/or builds after every push to the main repo?
09:12 < koeien> Saizan: the new script does not fetch the packages for me automagically
09:13 < Saizan> no? did you cabal update first?
09:17 < koeien> that could be the problem; fresh chroot
09:18 < Saizan> yeah, it doesn't know which packages are on hackage without a "cabal update"
09:19 < koeien> hmm, even then
09:19 < koeien> i removed ~/.cabal ; ran cabal update ; retried
09:20 < koeien> hslogger is not automagically installed
09:21 < Saizan> what if you run "cabal install" directly in one of the directories?
09:22 < koeien> ehm, duh; i should also remove ~/.ghc
09:22 < koeien> now it starts to compile, thanks
09:25 < Saizan> uhm, i'm not sure why .ghc was interfering, but ok :)
09:26 < koeien> Saizan: the ghc-package list still contained the packages that i installed by hand
09:26 < koeien> whereas they did not occur in ~/.cabal
09:29 < Saizan> but ~/.cabal contains only the index of packages on hackage, not the ones installed, that's what puzzles me..
09:29 < koeien> yeah, but i installed them by hand after they were missing; then they were registered as installed in ~/.ghc
09:30 < koeien> but some things were no longer present since i removed ~/.cabal
09:30 < koeien> anyway, it's resolved now
10:17 < stepcut> koeien: AT are broken in 6.8 and the syntax changed in 6.10 I think, but there were not so broken as to be unusable.
10:20 < koeien> mae: et al: where should build results go?
10:22 < stepcut> #happs?
10:22 < stepcut> ;)
10:22 < koeien> that may be a good idea
10:22 < koeien> results of my build-bot, i mean :)
10:22 < stepcut> well, I one-line summary might be nice, but not the whole log
10:23 < koeien> how do the ghc people do this?
10:24 < koeien> i could post a line with a link to a summary and the full log
10:27  * stepcut kicks spread in the head
10:27 < mae> um
10:28 < mae> i mean one line summary would be nice in chat if it is not too much trouble
10:28 < mae> otherwise online is fine :)
10:28 < mae> um
10:28 < mae> if you give me an ip
10:28 < mae> i can create an a record
10:28 < mae> what do you think, buildbot.happstack.com?
10:28 < koeien> fine
10:29 < koeien> huygens.functor.nl --> 85.17.139.97
10:29 < mae> ok you'll prob have to setup a name virtual host
10:29 < koeien> yep
10:30 < stepcut> spread starts and then just exits with no errors. in fact it just says "Successfully configured segment"
10:31 < mae> ok buildbot.happstack.com -> 85.17.139.97
10:32 < mae> might take a little bit to propagate
10:32 < koeien> yeah
10:32 < koeien> it might also take a while before i've set up the vhost, so that's fine
10:32 < koeien> :)
10:33 < mae> hehe
10:33 < mae> ok
10:33 < mae> thanks for stepping up to this
10:33 < mae> it will really help out.
10:33 < mae> gtg to work
10:58 < stepcut> ?hello
10:58 < stepcut> stepbot: hello!
10:59  * stepcut forgets how this thing works
10:59 < stepcut> stepbot: hello
10:59 < stepbot>  hello stepcut. We have now talked 1 time.
10:59 < stepcut> stepbot: get-mae
11:00 < stepcut> stepbot: get-mae
11:00 < stepbot>  mae!! (get-mae has been used 1 time.)
11:03 < koeien> cool
11:03 < koeien> how did you do this?
11:03 < stepcut> koeien: do what?
11:04 < koeien> create such a bot :-)
11:04 < koeien> http://buildbot.happstack.com/ is operational; a sample build log is available for ghc-6.8.3
11:04 < stepcut> koeien: a little glue between HAppS-State and Network.IRC
11:04 < koeien> nice
11:04 < stepcut> koeien: supports multimaster too :)
11:04 < stepcut> one moment
11:06 < koeien> i plan to create a very simple interface on the main page with red/green lights in a table
11:06 < stepcut> koeien: cool
11:07 < stepcut> stepbot1: hello
11:07 < stepbot1>  hello stepcut. We have now talked 2 times.
11:07 < stepcut> stepbot2: hello
11:07 < stepbot2>  hello stepcut. We have now talked 3 times.
11:07 < stepcut> so, stepbot1 and stepbot2 are two different processes. They use HAppS multimaster support to share the state
11:07 < Saizan> maybe running ./bin/clean-all.sh before building would be better?
11:08 < koeien> cool
11:08 < Saizan> nice, which version of spread?
11:08 < koeien> Saizan: yeah, i thought so as well. it's not necessary, but strictly spoken better
11:08 < koeien> i'll add it
11:08 < stepcut> spread 4.0.0
11:09 < stepcut> http://src.seereason.com/happs-bot/
11:09 < stepcut> the DSL for matching incoming messages sucks
11:10 < stepcut> its modelled after SimpleHTTP's dir, path, etc, stuff. But it is not a good match for irc.
11:11 < stepcut> (also that code relies on a patched Network.IRC, not sure if my patches made it upstream)
11:13 < Saizan> not in scope pong :)
11:14 < koeien> stepcut: is that package usable?
11:14 < koeien> as unpatched?
11:14 < koeien> Network.IRC i mean
11:15 < stepcut> koeien: for what I needed. My patches just add the 'pong' and 'notice' commands
11:15 < stepcut> koeien: it's seems sufficient for implementing an irc client
11:15 < koeien> okay. i plan to create a simple script to display the build results here, not as a persistent process though
11:16  * Saizan has a personal branch of irc with an ADT for commands and ByteString instead of String
11:16 < stepcut> Saizan: spiffy
11:17 < stepcut> koeien: I could extend my bot so that you could http POST the data to the bot?
11:17 < stepcut> ;)
11:17 < stepcut> Saizan: is your repo public?
11:18 < koeien> stepcut: mind if i use your code as a starting point?
11:18 < stepcut> koeien: go for it
11:20 < stepcut> koeien: let me know if you have any questions
11:20 < stepcut> koeien: there is some wackiness in that code at the moment. I have not figured out how to get it to shutdown cleanly
11:20 < koeien> kill -9 ? :P
11:21 < stepcut> I was trying to set it up so that when you hit ^C, it would actually send the /quit command
11:22 < stepcut> each incoming IRC message gets handled in its own thread, which prevents blocking, but does raise some interesting race condititons...
11:26 < Saizan> stepcut: http://code.haskell.org/~Saizan/irc but the parser for the ADT still goes via Read
11:28 < Saizan> you can use installHandler to intercept ^C, but you've to make sure to not overwrite other handlers (in particular the one installed by happs-state)
11:29 < stepcut> Saizan: I use waitForTermination from HAppS
11:30 < stepcut> Saizan: the problem had something to do with the structure of my app and getting everything flushed and killed in the right order. I forget why it was hard -- it didn't seem like it should be.
11:33 < stepcut> ugh
11:33 < stepcut> Preprocessing library bytestring-lexing-0.2...
11:33 < stepcut> alex: /usr/share/alex-2.2/AlexWrapper-strict-bytestring: openFile: does not exist (No such file or directory)
11:33 < Saizan> something broken with your alex installation?
11:34 < stepcut> maybe I need alex 2.3 instead of 2.2?
11:34 < stepcut> s/2.2/2.1/
11:34 < mightybyte> stepbot1: hi there
11:34 < mightybyte> stepbot1: hello
11:34 < stepbot1>  hello mightybyte. We have now talked 1 time.
11:35 < Saizan> stepbot2: hello
11:35 < stepbot2>  hello Saizan. We have now talked 1 time.
11:35 < Saizan> stepbot1: hello
11:35 < stepbot1>  hello Saizan. We have now talked 2 times.
11:35 < Saizan> heh nice :)
11:36 < stepcut> someday I might actually run the bots on two geographically separated hosts
11:36 < stepcut> instead of both on the same machine ;)
11:36 < mightybyte> stepcut: I was actually just thinking about doing that.
11:36 < stepcut> mightybyte: doing what?
11:37 < mightybyte> stepcut: Running your bot on my machine and trying to share state with yours.
11:37 < Saizan> i wonder if i should rewrite hspread as an ffi binding over the C spread api, it doesn't seem to work on my machine
11:37 < stepcut> mightybyte: ah, could be done, but we would have to get our spread network working first
11:37 < mightybyte> stepcut: How hard is that?
11:38 < stepcut> mightybyte: dunno. in my experience spread is really tricky to get running, because it doesn't produce any useful error messages if something is wrong
11:38 < stepcut> mightybyte: though it seems to work fine once it is running
11:38 < mightybyte> stepcut: Ahh, I know nothing about spread.
11:39 < stepcut> also, I would probably need to run the bot on a machine that can see through the firewall (or isn't behind one)
11:39 < mightybyte> Yeah, I figured that.
11:39 < stepcut> but, that stuff should all be well documented eventually if we keep using spread
11:40 < mightybyte> Is that the plan?
11:40 < stepcut> I don't think the plan goes that far yet. Supposedly the ideas behind spread are good and HAppS LLC did not want to reinvent the wheel there
11:41 < stepcut> I don't think anyone else has enough experience with spread to really know
11:41 < mightybyte> How much use does spread have in real systems?
11:41 < Saizan> spread is very nice since it gives you a consistent ordering of messages between the nodes
11:43 < stepcut> hrm, I can't build alex 2.3.1
11:43 < stepcut> oh, this might be a debian package issue
11:44 < mightybyte> stepbot1: hello
11:44 < stepbot1>  hello mightybyte. We have now talked 2 times.
11:44 < mightybyte> stepbot2: hello
11:44 < stepbot2>  hello mightybyte. We have now talked 3 times.
11:59 < koeien> stepcut: i don't see how you can send a message to a channel using Network.IRC
11:59 < stepcut> koeien: privmsg
11:59 < koeien> ah
11:59 < koeien> misleading name
11:59 < stepcut> koeien: that IRCs fault
12:00 < koeien> just include "#happs" instead of the username?
12:00 < stepcut> you use privmsg to send a message to a user *or* a channel
12:00 < stepcut> I think so, let me check
12:00 < koeien> i'll spam #test first
12:00 < stepcut> good plan
12:00 < stepcut> i think it just #channel though
12:01 < stepcut> the irc rfc would be the best reference
12:03 < Saizan> now you see why channel names start with # :)
12:04 < stepcut> :)
12:12 < koeien> yeah, # works
12:13 < stepcut> koeien: also, don't forget to respond to pings
12:13 < koeien> i plan to immediately quit after sending a message
12:13 < stepcut> ah
12:13 < koeien> or would this be inconvenient for the channel?
12:14 < stepcut> it'll be three messages instead of one..
12:14 < koeien> yeah, that's a bit annoying
12:15 < koeien> also, if i build for GHC 6.8.3 and 6.10.1, we'll get 2*3=6 messages
12:15 < Saizan> what's happsbot btw?
12:15 < stepcut> nicer would be if there was a permanent channel bot which you could do an HTTP post to
12:15 < stepcut> and then the bot would relay your message
12:15 < koeien> also possible
12:25 < stepcut> bytestring-lexing makes haddock very unhappy
12:26 < Saizan> is that used by attoparsec?
12:26 < stepcut> yes
12:32 < stepcut> Saizan: where does render come from? it is export from Network.IRC.Base, but I don't see it defined anywhere
12:34 < Saizan> oh, it's a deprecated synonim to encode that i must have deleted without correcting the export list
12:34 < stepcut> :)
12:35 < vegai> would it be inconceivable to layer on top of IRC a little saner API
12:35 < stepcut> vegai: no
12:36 < Saizan> btw, i didn't manage to actually write the ircbot framework yet, so i've only used the code in a test bot
12:36 < stepcut> Saizan: I would recommend happs for persistent state, replication, and (soon?) dynamic/static plugin loading ;)
12:36 < Saizan> heh :)
12:37 < stepcut> I am still working out how to best avoid blocking
12:38 < stepcut> in my current bot all incoming messages are handled in a different thread (same as SimpleHTTP). But that could result in out of order weirdness for multiline requests
12:38 < stepcut> but, it has the advantage that plugins won't block the whole thing, even if the plugin author never thinks about it
12:38 < Saizan> i think that you rather want each "plugin" to be run in a separate thread
12:38 < Saizan> and give each one a Chan Message with all the incoming messages
12:38 < stepcut> perhaps
12:39 < stepcut> but then a plugin could block itself
12:39 < Saizan> yes, and cause a space leak of Messages
12:39 < stepcut> like ?get-title http://slowsite.org/
12:40 < stepcut> if that is out to lunch and someone does ?get-title http://fastsite.org/ it would be  nice if the second request came back
12:41 < Saizan> the plugin could still forkIO such a task and continue waiting for more messages..
12:42 < Saizan> but that would be very common then
12:44 < stepcut> Saizan: right. my hope is to design the framework so that developers don't have to remember to forkIO
12:45 < stepcut> because for something like lambdabot, there are a lot of authors, who don't really know all the 'rules'
12:45 < Saizan> eh, yeah
12:45 < stepcut> the current solution works automatically, but with a penality of uncertainty
12:48 < Saizan> but things like ?seen should really see messages inorder
12:49 < stepcut> right
12:49 < stepcut> and some things require a bit of back and forth
12:51 < Saizan> back and forth? you mean something like a session?
12:52 < stepcut> yea
12:54 < stepcut> ?seen being out of order isn't really that  bad. But if you have a trivia game where first responder wins, then it could be an issue
12:54 < stepcut> Saizan: where should I send my patches to your irc library?
12:55 < Saizan> stepcut: my email sanzhiyan -at- gmail -dot- com
12:57 < stepcut> sent
12:57 < stepcut> just adds notice and pong commands
13:05 < Saizan> pushed
13:06 < stepcut> yay
13:07 < stepcut> next i'll update the the bot to use it
13:07 < Saizan> i should contact the original author to see if these changes can go upstream
13:08 < stepcut> yeah
13:08 < stepcut> I just sent him the same patch, but against the 0.4.x line ;)
13:18 < koeien> stepcut: how often do pings come?
13:19 < stepcut> koeien: dunno, every few minutes?
13:19 < koeien> if i don't respond, i'll die? :)
13:20 < stepcut> yes
13:25 < koeien> can i get your `pong' code as well? (does this patch apply to vanilla irc?)
13:26 < stepcut> yes and yes.
13:26 < stepcut> where should I send it?
13:26 < koeien> jochem at functor dot nl
13:28 < stepcut> sent
13:28 < koeien> ack, recvd
13:29 < koeien> thanks
13:30 < stepcut> http://www.facebook.com/pages/Happstack/47967937821
13:30 < stepcut> I'll add some additional admins as appropriate
13:35 < mae_work> yes we will use spread
13:36 < stepcut> heh, that was interesting.
13:53 < h_buildbot> It works :-)
14:01 < h_buildbot> Build for ghc-6.8.3 *failed*. See http://buildbot.happstack.com/ghc-6.8.3/
14:02 < koeien> (don't worry - i did this on purpose)
14:04 < Saizan> (ah, i was wondering..)
14:07 < stepcut> spiffy
14:07 < h_buildbot> Build for ghc-6.8.3 just succeeded. See http://buildbot.happstack.com/ghc-6.8.3/
14:08 < koeien> that was a real message :)
14:09 < wchogg> Awsome job in getting that set up.
14:09 < wchogg> How often will it run?
14:09 < koeien> daily for now
14:09 < wchogg> Okay.  So we'll know fairly quickly if I break things _again_
14:10 < koeien> to be more specific, at 5AM CET
14:11 < koeien> yeah, that's the goal. i could do it after every commit, but then I have to know some when somebody has committed something
14:13 < wchogg> And it runs with ghc-6.8.3 & ghc-6.10.1, then?
14:14 < koeien> not yet, i'll do a ghc-6.10.1 in a few minutes
14:14 < koeien> it's all chroot-ed so hopefully my server doesn't get hacked by you 1337 h4x0rz ;)
14:15  * Saizan inserts a backdoor with TH
14:15 < koeien> Saizan: it's even easier ;) just edit your clean or build-all-script
14:16 < Saizan> eheh, right
14:19 < wchogg> But why mess with shell scripting?  We want _provably correct_ hacking, yo
14:23 < stepcut> wchogg: what OS are you building on ?
14:26 < wchogg> ubuntu 8.04
14:28 < koeien> the buildbot runs debian lenny
14:28 < stepcut> ah
14:28 < koeien> appearantly libc in etch was too old for ghc :/
14:29 < stepcut> is the build bot using a debianized version of happstack ?
14:29 < koeien> ?
14:30 < stepcut> I was wondering if the buildbot produces .debs, or if it just builds the .cabal stuff
14:30 < koeien> it's all cabal
14:30 < koeien> is there a way to produce .debs then?
14:31 < koeien> cabal debianize ... ?
14:32 < vegai> how long does it take to build the whole thing?
14:32 < vegai> if it's not a lot, perhaps you should build it for each and every commit
14:32 < stepcut> koeien: I have debian packages for all of HAppS, but have not migrated to happstack yet
14:32 < koeien> about 6 minutes
14:33 < stepcut> koeien: I use a tool, cabal-debian, to generate the packages -- though things are in a bit up in the air at the moment due to transitioning to 6.10
14:33 < koeien> would be cool. I've thought about creating a giant repository of all cabal packages on earth in debian form
14:33 < koeien> appearantly there is already a tool for it :)
14:34 < stepcut> koeien: Magnus Therning is thinking the same thing I think
14:34 < stepcut> koeien: we are working on getting the kinks out of cabal-debian so that it can assist with that
14:34 < koeien> is he debian dev? i'm not very experienced with .debs
14:35 < stepcut> koeien: not officially
14:35 < koeien> i know two or three debian devs, so i could always ask them if i run into trouble
14:35 < stepcut> we (seereason) have a large happs related .deb collection here, http://deb.seereason.com/, but I would not use it this week due to the ghc 6.10 transition
14:36 < stepcut> koeien: are you on the debian-haskell mailing list?
14:36 < koeien> stepcut: no i'm not
14:36 < stepcut> the *new* debian-haskell mailing list
14:36 < koeien> neither on the new one ;)
14:36 < koeien> i'll subscribe
14:37 < stepcut> http://lists.debian.org/debian-haskell/
14:37 < stepcut> it's low traffic
14:38 < koeien> vegai: i could run it for every patch, without cleaning the stuff. then it will be even less. don't know if it's a good idea
14:39 < vegai> depends on how often you guys are planning on breaking the build :P
14:39 < vegai> perhaps it's more useful once/if you get proper test sets
14:40 < koeien> probably. it's easy to add them to the script
14:43 < koeien> if we want to run the compiler after every commit (which is a good idea imo), i would need an e-mail or HTTP request on every commit though
14:47 < h_buildbot> Build for ghc-6.8.3 just succeeded. See http://buildbot.happstack.com/ghc-6.8.3/
14:52 < h_buildbot> Build for ghc-6.10.1 just succeeded. See http://buildbot.happstack.com/ghc-6.10.1/
14:52 < koeien> 6.10.1 is now done as well, as you can see
14:56 < mightybyte> `/window new hide
14:56 < mightybyte> Oops
14:58 < mae_work> Hi
14:58 < mae_work> so uh, I wanted to point out probably the obvious but
14:58 < mae_work> you could always poll every 5 minutes
14:59 < mae_work> for new patches..
14:59 < koeien> you are talking about the build-bot?
14:59 < mae_work> yep
14:59 < koeien> ok right now it's every night at 5AM CET
15:01 < koeien> but if you don't mind the bandwidth of that (probably not a lot), i'll do it
15:01 < mae_work> you mean patch-tag?
15:01 < koeien> it's hosted by somebody else?
15:02 < mae_work> well yeah, thomas hartman
15:02 < mae_work> but you can poll it
15:02 < koeien> oh yeah the github where git = darcs
15:02 < mae_work> it won't be a problem
15:02 < mae_work> http://happstack.com/develop.html
15:02 < mae_work> you pulling via http?
15:03 < koeien> yep
15:13 < mae_work> ok neat
15:13 < mae_work> great job on that koeien :)
15:13 < koeien> done; pulling every 5 mins
15:13 < mae_work> so if there are no patches, it does nothing?
15:13 < koeien> yes
15:13 < mae_work> great :)
15:13 < koeien> otherwise, it builds for ghc-6.8.3 and ghc-6.10.1 and reports in this channel
15:14 < mae_work> so you basically just built that from scratch eh? :)
15:14 < mae_work> as opposed to using another buildbot solution
15:14 < koeien> yep
15:15 < koeien> the IRC bot is based on stepcut's
15:17 < mae_work> cool
15:17 < koeien> if there will be a testsuite, it can also be run
15:18 < mae_work> ok :)
15:18 < koeien> for that i'll have to modify the script
15:18 < mae_work> I am going to get all the existing tests working before 0.1
15:18 < mae_work> and probably add new ones between 0.1 and 0.2
15:18 < stepcut> what framework are we using for the testsuite?
15:18 < koeien> is this in a suitable form for a formal testsuite? quickcheck/HUnit ?
15:19  * stepcut hopes so
15:19 < mae_work> what are the restrictions of the chroot
15:19 < mae_work> which bins available
15:20 < mae_work> koeien, stepcut: Well, probably quickcheck if possible
15:20 < stepcut> I once wrote a wrapper so that you could embed quickchecks into HUnit
15:20 < stepcut> hunit has a nice framework for organizing your tests and running them
15:20 < mae_work> but for now I was simply referring to the shell scripts lying around under the example folders
15:20 < stepcut> plus somethings work better as unit tests than quickchecks
15:20 < stepcut> we can start by calling the shell scripts from hunit tests
15:20 < stepcut> :)
15:21 < mae_work> so we will probably have an integration test suite which is more ad-hoc and formal test suite with quickcheck
15:21 < mae_work> the ad-hoc test suite will be shell scripts which indicate success with 'exit 0' :)
15:21 < stepcut> I think we can wrap up all the stuff inside HUnit
15:21 < mae_work> yeah?
15:21 < mae_work> so can hunit wrap quickcheck?
15:21 < koeien> darcs and ghc
15:21 < mae_work> or what
15:21 < stepcut> yes
15:22 < mae_work> ic
15:22 < stepcut> hunit tests can do IO as well, so you can exec shell scripts if you want
15:22 < mae_work> stepcut: ok, well i want to keep it simple for 0.1, but we can definitely ramp up the test suite for the 0.2 release
15:22 < koeien> there are in fact two chroots
15:23 < mae_work> koeien: ah i see
15:23 < stepcut> the testpack thing that John Goerzen is debianizing has my code for wrapping QC inside HUnit
15:23 < stepcut> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/testpack
15:23 < stepcut> specifically, http://hackage.haskell.org/packages/archive/testpack/1.0.0/doc/html/Test-HUnit-Tools.html#v%3Aqccheck
15:24 < mae_work> stepcut: are you interested in uploading a skeleton of what you had in mind?
15:24 < mae_work> under test/
15:24 < mae_work> and I can work off of that
15:24 < stepcut> sure
15:24 < mae_work> great
15:25 < stepcut> I'll do it after I finish packaging up my facebook module and go to the grocery store
15:25 < mae_work> ok cool ! :)
15:25 < koeien> if you put it in the repos i can see what i can do to integrate it
15:26 < mae_work> yeah s/upload/push to repo/
15:26 < mae_work> what i meant :)
15:42 < h_buildbot> Build for ghc-6.8.3 just succeeded. See http://buildbot.happstack.com/ghc-6.8.3/
15:45 < h_buildbot> Build for ghc-6.10.1 just succeeded. See http://buildbot.happstack.com/ghc-6.10.1/
15:46 < koeien> hmm, something was committed :)
16:04 < stepcut> started my new facebook module, not usuable yet though (although the demo app does work), http://src.seereason.com/happstack-facebook/
16:26 < koeien> meh
17:49 < koeien> so, i changed some stuff in the code; now using a pidfile for mutual exclusion. let me know if anything breaks
17:51 < stepcut> koeien: in *which* code?
18:06 < stepcut> do we need to be capatible with cabal 1.2? Or can I change defaultUsersHooks to simpleUserHooks in Setup.hs?
18:06 < stepcut> (for happstack)
18:07 < koeien> stepcut: the buildbot code (i have no commit access to the central repos)
18:08 < stepcut> ok :)
18:10 < Saizan> ghc-6.8 comes with 1.4 i think
18:10 < Saizan> and you can upgrade anyhow
18:16 < dcoutts> ghc-6.8 comes with 1.2
18:16 < dcoutts> ghc-6.10 comes with 1.6
18:18 < stepcut> hrm
18:19 < stepcut> leaving it at 1.2 is probably fine until we drop 6.8 support, or need cabal 1.6 for some other reason
18:19 < koeien> is there a problem with 'defaultUsersHooks' ?
18:19 < koeien> (except for possible deprecation)
18:19 < dcoutts> not really
18:19 < stepcut> koeien: you just get a warning
18:19 < stepcut> koeien: and we are trying to clean up warnings
18:19 < dcoutts> the reason we deprecated it is because it's unhelpful wrt ./configure scripts
18:20 < stepcut> what does the Bool mean in this type: runTests :: Args -> Bool -> PackageDescription -> LocalBuildInfo -> IO ()
18:20 < dcoutts> stepcut: lost in the mists of time but preserved for compatibility
18:20 < koeien> yeah, we also get warnings for LANGUAGE PatternSignatures
18:20 < stepcut> dcoutts: also, the link to Distribute.Simple in the 'setup test' section on this page is broken: http://www.haskell.org/cabal/release/latest/doc/users-guide/builders.html#setup-test
18:21 < stepcut> koeien: true
18:21 < stepcut> dcoutts: ok, I'll just continue to ignore it
18:21 < dcoutts> defaultUsersHooks was not the default and it runs ./configure scripts if they're present but does not if they're not which is unhelpful for packages that actually need configure and confusing for those that do not.
18:21 < dcoutts> stepcut: yeah, it's always the same value anyway
18:22 < dcoutts> stepcut: sigh, that link is hard to make work, it either works for the ghc docs or the cabal docs but not both it seems
18:22 < stepcut> dcoutts: if the tests fail, what am I supposed to do? Use (fail  "some tests failed."), or is there a better mechanism?
18:22 < stepcut> call exitFailure myself?
18:23 < dcoutts> stepcut: either would work
18:23 < stepcut> dcoutts: is either method prefered ?
18:23 < dcoutts> stepcut: honestly, nothing ever calls test
18:23 < dcoutts> it's a pretty useless stub
18:23 < dcoutts> we've got plans for proper tests
18:24 < stepcut> oh?
18:24 < stepcut> I was going to make, runhaskell Setup test, work for happstack, is that a waste of time?
18:25 < dcoutts> stepcut: if that's useful to you, then do it
18:26 < dcoutts> stepcut: I think in the end, we'll continue to support custom Setup.hs that set the test hook, so it may prove useful beyond it being handy to you
18:27 < dcoutts> but we're going to aim to add test sections to the .cabal file, basically a variant on executables
18:27 < stepcut> ah
18:27 < dcoutts> with a protocol (or a choice of protocols) to interact between tests and progs that run them and collect the results
18:27 < stepcut> should be easy to adapt what I am doing to support that when it is ready
18:27 < dcoutts> good good
18:28 < dcoutts> the minimal protocol will be exit code
18:28 < stepcut> I am going to try to build the happstack on top of huint, would that work well with the future of cabal?
18:28 < dcoutts> yes, especially once someone implements a hunit & quickcheck batch interface to implement the cabal test protocols
18:29 < stepcut> cool
18:29 < dcoutts> more sophisticated protocols would allow a two way conversation between the tests and the agent running them, eg to list tests, run specific ones and collect individual results.
18:29 < dcoutts> so they can get uploaded to hackage etc
18:31 < koeien> wouldn't it be useful to standardize on, say, HUnit for this purpose?
18:33 < stepcut> hrm. unfortuantely, HAppS/Server/Tests.hs is in the src sub-directory, so I can import it in Setup.hs :-/
18:34 < koeien> {-# OPTIONS_GHC -isrc #-}    -- evil hack
18:34 < stepcut> I swear that has never worked for me
18:35 < stepcut> (and still does not seem to)
18:35 < dcoutts> koeien: no, there's QC and others and custom stuff
18:43 < koeien> stepcut: can't you create a shell script for this? i.e.   runTests.sh: runghc Setup.lhs tests -isrc  or something like this?
18:43 < koeien> unless dcoutts knows the solution
18:47 < stepcut> koeien: well, you wouldn't be able to run Setup.lhs at all with out the script then, and that would not be very good
18:48 < koeien> hmmz
18:48 < stepcut> there are other options though
18:48 < koeien> not even for config/build/install, that's true
18:49 < stepcut> the approach I was taking had other flaws anyway
18:49 < stepcut> it would have resulted in the tests being linked into Setup.lhs which would not be very good
18:50 < koeien> "linked into" ?
18:50 < stepcut> I was going to use the runTests hook to run the hunit tests
18:51 < stepcut> but the hunit tests themselves import all of happstack so they can test the different functions
18:51 < stepcut> so you would essentially have all of happstack imported into your Setup.hs so you could do 'runhaskell Setup test'
18:51 < stepcut> even if you didn't actually plan to run that command ;)
18:52 < koeien> yes, you always have that if you include it in Setup.hs
18:52 < koeien> so Tests.hs ?
18:52 < stepcut> so, clearly I need a separate program that runs the tests and runhaskell Setup.hs test runs that program
18:53 < koeien> yep
18:53 < stepcut> another issue with tests is whether they are run against the version of the library in the local directory, or the version installed system-wide
18:53 < stepcut> both seem useful
18:54 < koeien> but then there is no nice way to communicate (say you want to ask for a list of all testcases). but that's N/A for now anyway
18:54 < stepcut> right
18:54 < koeien> stepcut: i would think this would be the local dir. it would be very strange otherwise ... i would expect 'runghc Setup.hs test' to check the version i'm currently building
18:54 < stepcut> right
18:55 < koeien> like `make test' does with C programs
18:55 < stepcut> right, but you might also want to test your installed system sometimes
18:56 < koeien> perhaps
18:56 < koeien> but would you want to always install the testsuite?
18:56 < stepcut> I also want to avoid the problem where running the test suite causes you to rebuild the source tree even though you just built it
18:57 < koeien> i wouldn't expect it
18:57 < koeien> hmm
18:57 < stepcut> ie. if you do runhaskell Setup configure ; runhaskell Setup build ; runhaskell Setup test
18:57 < koeien> couldn't you do stuff with the things built in dist/ ?
18:58 < stepcut> I think so. But on the other hand, what if someone has changed the source but not rebuilt. They might think their change is good because the test suite ran
18:59 < koeien> what does Cabal do for us in this regard?
18:59 < stepcut> if i make the testsuite a normal executable in the .cabal file, then when you do, runhaskell Setup build, it will automatically build a new ersion of the testsuite linked against the library that was just built
19:00 < koeien> can't you set a flag in the cabal file?
19:00 < koeien> regular mortals may not want to build the testsuite
19:00 < stepcut> sure
19:00 < koeien> although it's not *that* much work
19:00 < stepcut> that would be a useful addition
19:01 < koeien> so, if flag(buildTestsuite) or something like this
19:01 < stepcut> I just meant that you could use that technique to solve the problem of getting the test-suite built against the binaries you just compiled
19:01 < koeien> but what if i change the files, run tests again; nothing has changed in the binary so it will pass again
19:02 < koeien> the same problem applies
19:02 < stepcut> right
19:02 < koeien> if Cabal would check that files have changed, there is no problem
19:02 < koeien> s/check/detect
19:03 < stepcut> well, runhaskell Setup test could force cabal to do a build everytime
19:03 < stepcut> if everything is up-to-date does that go fast?
19:03 < koeien> yes, a few seconds
19:04 < stepcut> so, that might solve the issue, provided you use, runhaskell Setup test, as your primary interface to the test suite
19:04 < stepcut> which is a bit like running, make test
19:04 < koeien> i think so
19:05 < koeien> so, concluding; runh Setup configure --with-testsuite; runh Setup build; runh Setup test
19:06 < koeien> change some files; runh Setup test {- rebuilds automagically -}
19:07 < stepcut> yeah, in-fact you could probaly skip the Setup build step since Setup test will do that
19:07 < koeien> indeed
19:08 < koeien> if you don't do --with-testsuite, runh Setup build will not build the testsuite and the user saves some seconds
19:08 < koeien> although this may be overkill
19:09 < stepcut> it's useful in other ways. cabal-debian would probably try to make a .deb for the test-suite if it was always built.
19:09 < koeien> which is not what we want?
19:10 < stepcut> dunno, it would be a bit weird.
19:10 < koeien> yeah
19:10 < koeien> for profiling libraries you have to specify some flags as well
19:10 < koeien> (-p iirc)
19:11 < koeien> but i think this'll work
19:14 < stepcut> yeah, I'll hack on it more tomorrow
19:15 < koeien> let me know, i can integrate it into the buildbot
19:15 < koeien> if you output some information to stdout in a certain format (like "37/42 tests passed") i can do magic with that as well
19:23 < stepcut> ok
19:29 < stepcut> searching for 'blur intermission' turns up many results for 'lyrics' -- which is nice, seeing as how it is an instrumental piece...
19:29 < wchogg> stepcut : well how else do you figure out how to hum along?
19:30 < stepcut> true
19:30 < koeien> you may know this: can i let google forward the messages to the google group to some other address?
19:31 < koeien> instead of my gmail address?
19:33  * stepcut has no idea.
19:33 < stepcut> I just read the google group in my browser
19:33 < stepcut> and I don't have gmail
19:34 < koeien> i avoid gmail due to privacy issues
19:53 < thetallgu1> you can forward all your mail
19:53 < thetallgu1> I don't think you can do it selectively
19:54 < thetallgu1> Oh, yes you can
19:54 < koeien> just gmail forwarding?
19:54 < thetallgu1> You can create a gmail filter that forwards messages that match
19:54 < koeien> thanks
19:55 < thetallgu1> it's one of the options in the second step of filter creation
19:55 < gwern> (gmail forwarding is great, imo)
19:56 < gwern> and iirc one of the filter options is 'delete'
19:56 < gwern> so you'd create a filter matching the list (gmail has a special search for google groups), forward to an address, and then delete it
20:00 < koeien> this should work. i could also fetch all gmail with fetchmail and set up some procmail rules
20:05 < gwern> 'I could do the sensible easy nearly foolproof thing. but I could also do a thing which is as unreliable as my computer, more difficult, and more fragile than an airplane made out of baling wire.'
20:08 < koeien> :)
21:42 < wchogg> mae : how do you feel about culling code that isn't used in a module & isn't exported?  Count it as dead?
22:03 < barkmadley> sounds dead to me
23:10 < mae> wchogg: yeah sounds dead to me (like barkmadley said)
23:10 < stepcut> mae: I made some progress on the test framework after some false starts
23:10 < mae> stepcut: neat ! :)
23:10 < stepcut> mae: almost tried to import all of happstack into Setup.hs  ;)
23:11 < stepcut> mae: any idea if a .cabal file can provide more than one library?
23:11 < mae> stepcut: ok, will this effect any packages building
23:11 < mae> as in, hold up 0.1 :)
23:11 < stepcut> no
23:11 < mae> ok
23:12 < stepcut> there will eventually be  some mods to Setup.hs and the .cabal, but that can happen whenever
23:12 < mae> I want to release 0.1 in the next week
23:12 < stepcut> ok
23:12 < stepcut> I am hoping to have something in the next day or tow
23:12 < stepcut> two
23:13 < mae> by something, you mean, a grand way to meet all the goals that I saw earlier on chat? :)
23:13 < stepcut> of course!
23:13 < mae> heh
23:13 < stepcut> I think I have it all mapped out
23:14 < stepcut> I am trying to figure out where the tests should live
23:14 < mae> ok well, don't put too much on your plate, if anything release less ambitious version first rather than let this become a road block
23:14 < stepcut> the problem I have now is finding some tests that actually work to include
23:15 < mae> ah i see
23:15 < wchogg> mae : Also, should I be conservative at all on removing unused or commented code?  I've been a bit skittish about it so far & I just don't want to screw anything up.
23:15 < mae> now are you referring to top level tests or unit tests of the functions via hunit or quickcheck
23:15 < stepcut> all of them?
23:16 < mae> wchogg: as a rule of thumb, if it is commented out code, remove it, we can always go back in history
23:16 < stepcut> there are bits of test code in HAppS-State, for example, but it does not compile
23:16 < wchogg> mae : True.
23:16 < mae> as far as the comments go, keep them in almost all cases unless you feel strongly that they don't belong
23:18 < mae> stepcut: ah yes , the example code, I wanted to get that stuff to compile tonight
23:18 < mae> stepcut: have you uploaded the skeleton or are you waiting for real tests?
23:19 < mae> because I would almost say to just upload some fake tests as a proof of concept
23:19 < mae> so then we can start populating it
23:20 < stepcut> mae: I am still working on the pieces about where things go
23:21 < stepcut> that is mostly all there is to do
23:21 < stepcut> The tests will go in some hierarchy like, HAppS.Server.Test
23:21 < stepcut> and then there is a simple test function where you import the tests and glue them together
23:22 < stepcut> but I am not clean if that code should go in, src/HAppS.Server.Test or tests/HAppS.Server.Test
23:22 < stepcut> the latter would be nice if a .cabal package can build two different libraries
23:23 < stepcut> there is some question as to whether people might want to import and use the tests in their own test suites for their own custom applicaitons.
23:23 < stepcut> I have written other libraries where that would be useful, but I am not clear if it would be in HAppS
23:24 < mae> using our tests in their test suites is a big what if
23:24 < mae> so lets assume no for now
23:24 < mae> now is tests/ per package or is tests/ in the root ?
23:24 < stepcut> could be both
23:25 < mae> What benefits do we gain by adding the tests to the cabal package
23:25 < mae> (as in the tarballs)
23:26 < stepcut> in order to run the tests you need build them against the libraries in your working directory. cabal is good at making that happen
23:26 < mae> ok
23:26 < mae> enough said
23:26 < stepcut> you could do, runhaskell Setup.hs configure ;  runhaskell Setup.hs build  ;  runhaskell Setup.hs test
23:26 < mae> Now, semantically
23:26 < stepcut> and test would build the tests against the libraries you just built via 'build'.
23:26 < mae> I eventually want any glue code (between the packages) to go to a "glue" package all by itself
23:27 < stepcut> yeah
23:27 < mae> so semantically, I don't want any integration tests in the package-specific suites
23:27 < stepcut> right
23:27 < mae> anything that has to do with glue and integration should go at the project root
23:27 < mae> for now at least
23:27 < mae> : \
23:27 < stepcut> I expect that each package would have tests that are package specific, and there would be another module that tests the integration
23:27 < stepcut> that is one reason why each module might need to export its test library
23:28 < mae> what do you mean by this
23:28 < mae> I am not understanding
23:28 < mae> which module
23:28 < stepcut> imagine all the tests for HAppS-Server are in, HAppS.Server.Test
23:29 < stepcut> in happstack-glue there is the master test suite, which includes the integration tests, but also runs all the indivdual tests.
23:29 < stepcut> It will, import HAppS.Server.Test (allTests), so it can run those tests
23:31 < stepcut> but, I am not sure that if you install the happstack-server you automatically get HAppS.Server.Test, maybe you have to install the package happstack-server-tests to get that part of the tree
23:31 < stepcut> so that normal users don't have a bunch of Test modules installed that they don't really need
23:32 < stepcut> that relates to the question about where HAppS/Server/Test.hs lives in happstack-server/src or happstack-server/tests
23:32 < stepcut> and whether a single .cabal file can produce multiple libraries
23:34 < mae> ahh ok
23:34 < mae> i get you now
23:34 < stepcut> it might just use the cabal flag mechanims, if you do, runhaskell Setup.hs configure --with-tests then you get the test modules, but by default you do not
23:34 < mae> let me ask you this, do i have to reinstall the package to run the test suite against it (with the cabal testing mechanism)
23:35 < mae> or does it use the files that are in the dir
23:36 < stepcut> also, the Tests stuff might have more structure, like, HAppS.Server.Tests.SimpleHTTP would include the SimpleHTTP tests, etc. And then HAppS.Server.Tests would import and re-export the tests from the submodules. It would also include a master test "allTests" which includes all the tests.
23:36 < stepcut> I plan on having two ways of doing things
23:37 < mae> ok, don't get too hung up on naming semantics
23:37 < stepcut> by using cabal to build the test suite, that will ensure that if you do, runhaskell Setup.hs configure ; runhaskell Setup.hs test, that the test suite gets built against the libs in the local 'dists' directory
23:37 < mae> what is the practical use case of having tests for cabal packages (aside from the possibility of integrating into your own test suites)
23:38 < stepcut> the pratical use is that when you do, runhaskell Setup.hs test, it can build against the libraries you have in your local 'dists' directory instead of the system-wide ones
23:38 < mae> and also it is practical to test the dist tarballs that are generated from the cabal package
23:38 < mae> since we might forget to include a module, for instance
23:39 < mae> right?
23:39 < stepcut> to a degree
23:39 < mae> hmm
23:39 < stepcut> if you do runhaskell Setup.hs sdist, and then extract the tarball and run the tests in there, then that would be a good test that everything was included
23:40 < mae> so where are you stuck right now
23:40 < stepcut> unfortuantely .cabal is not good about checking for things that need to be listed as extra-modules
23:40 < stepcut> I am stuck at: it's 40mins past my bedtime
23:40 < mae> haha
23:40 < mae> ok
23:40 < mae> well go to bed then
23:40 < stepcut> ok. cya tomorrow.
23:40 < mae> don't overdo the engineering on these tests either
23:41 < mae> go for something simple to start with so we can start making tests
23:41 < stepcut> overall this is probaly only 20 lines of code, if that
23:41 < mae> heh ok
23:41 < mae> night
23:41 < stepcut> night
23:42 < stepcut> the goal was to think of everything before I went to bed so it would all be obvious in the morning ;)
23:42 < mae> yeah, funny how that works out
--- Log closed Wed Jan 28 00:00:10 2009