--- Log opened Wed Feb 04 00:00:59 2009
00:02 < mae_> Yeah, mostly not my effort but others
00:02 < mae_> But i'll take a small helping of credit, I guess.
00:02 < mae_> I won't ask for seconds.
00:02 < mae_> Good job everyone!
00:05 < h_buildbot> Build for ghc-6.10.1 OK. Test suite ran. 15/73 test cases failed. Check http://buildbot.happstack.com/ for details.
00:09 < mae_> ok, i'm out of here for now, whew need a break
00:32 < dons> mae_: i'll add the happstack blog to planet.haskell.org, ok?
00:36 < dons> mightybyte: also, you want your blog on planet.haskell too?
00:36 < dons> any other happstack bloggers?
00:38 < dons> we should get some happs projects together for  the jane street and google summers of code!
01:19 < mae_> dons: thanks, that would be great
01:22 < dons> ok. done.
01:22 < dons> check planet.haskell.org
01:22 < dons> should have much better visibility now, p.h.o goes everywhere.
01:38 < mae_> yep looks good
05:44 < koeien> woot 0.1 has been shipped
06:16 < mightybyte> dons: I see you already put it up.  I can't think of any reason why I wouldn't want that. :)
07:37 < Saizan> woot "cabal install happstack-server"
07:37 < dcoutts> :-)
08:38 < paulvisschers> Installing happstack now
08:38 < paulvisschers> I still need to import with HAppS.Server and such right?
08:40 < wchogg> Modules names didn't change, if that's what you're asking.
09:09 < mightybyte> stepcut, paulvisschers: ping
09:09 < paulvisschers> mightybyte: pong
09:09 < paulvisschers> what's up?
09:10 < mightybyte> Looking back at the code ideas you had yesterday, it looks like your code is for fixed size lists.  I'm looking for variable sized lists.
09:10 < mightybyte> i.e. the user clicks an "add more" button that adds elements to the form with javascript.
09:11 < paulvisschers> Ah right
09:11 < mightybyte> ...which introduces the need to differentiate the field name somehow.
09:11 < paulvisschers> That is possible, but hard
09:12 < stepcut> mightybyte: that is tricky stuff to do using formlets, but I have done it
09:12 < paulvisschers> Actually the whole label stuff at the top of the file is there because of that
09:12 < mightybyte> Yeah, that's my requirement, and it looks like the formlet library is a little more conducive to that than formbinator.
09:13 < mightybyte> stepcut: Yeah, it was working fine for me until I had to start supporting defaults.
09:13 < stepcut> mightybyte: I have to run, but I will be around later today, and we can compare notes
09:13 < mightybyte> Ok
09:14 < paulvisschers> The problem is that my javascript isn't very good
09:14 < mightybyte> paulvisschers: Yeah, but it looked like you hadn't integrated that yet.
09:14 < mightybyte> Same here :|
09:14 < paulvisschers> The label stuff is integrated fully
09:15 < mightybyte> Oh, integrated, but not used yet.
09:15 < paulvisschers> and if you use the list function to make a list of forms, the labels get an extra index
09:16 < paulvisschers> so instead of 1 - 2 - 3 - 4 you get 1 - 2 - 3.1 - 3.2 - 4
09:16 < paulvisschers> so you can use javascript there to generate the 3.3 form
09:17 < mightybyte> Ok
09:17 < paulvisschers> Although I haven't actually done something like that yet, since it's not that simple and I haven't needed it yet
09:17 < mightybyte> Yeah
09:17 < mightybyte> It has presented quite a bit of difficulty for me.
09:18 < mightybyte> But once I get everything worked out, it should be pretty straightforward.
09:19 < paulvisschers> I don't know how easy it's going to be, but it's definitely on the todo list for formbinator
09:20 < mightybyte> Ok
09:21 < mightybyte> Well I think I'll keep working with Formlets for now.  I'm seeing light at the end of the tunnel.
09:21 < paulvisschers> ok good luck with that
09:21 < mightybyte> Let me know if you get around to doing it.
09:22 < paulvisschers> I will
09:22 < mightybyte> Thanks
09:28 < koeien> h_buildbot: pause
09:28 < h_buildbot> Paused
09:28 < paulvisschers> If I have an url like /blaat/?name=hoi, how do I get the value of name?
09:29 < Saizan> with the look* functions
09:30 < paulvisschers> ah right
09:32 < Saizan> withDataFn (look "name") $ \value ->
10:56 < koeien> h_buildbot: status
10:56 < h_buildbot> Idle.
10:56 < koeien> h_buildbot: build ghc-6.8.3_STABLE
10:56 < h_buildbot> Build for ghc-6.8.3_STABLE started. If one was running, no new one is started.
10:56 < koeien> h_buildbot: status
10:56 < h_buildbot> Building ghc-6.8.3_STABLE
10:57 < koeien> h_buildbot: ping
10:57 < h_buildbot> pong
10:58 < koeien> h_buildbot:
10:58 < koeien> h_buildbot: nonsense
10:58 < h_buildbot> Use: build, status, pause, resume, ping
10:58 < mightybyte> koeien: Nice
10:58 < koeien> the stable branch is now in the buildbot as well
11:00 < koeien> so bug fixes are monitored as well ;)
11:01 < mightybyte> jThis is great infrastructure.
11:03 < h_buildbot> Build for ghc-6.8.3_STABLE OK. Test suite ran. 17/73 test cases failed. Check http://buildbot.happstack.com/ for details.
11:04 < koeien> i have to do something during the lectures ;)
11:04 < koeien> h_buildbot: status
11:04 < h_buildbot> Idle.
11:04 < koeien> h_buildbot: build
11:04 < h_buildbot> Build for all started. If one was running, no new one is started.
11:04 < koeien> h_buildbot: status
11:04 < h_buildbot> Building ghc-6.8.3_STABLE
11:09 < mae_> so uh
11:09 < mae_> great
11:09 < mae_> man you are the buildbot king
11:09 < mae_> i am late for work
11:09 < mae_> just woke up
11:09 < mae_> argh
11:09 < mae_> bbl
11:09 < paulvisschers> mightybyte: http://moonpatio.com:8080/fastcgi/hpaste.fcgi/view?id=1196#a1196 This is some output that is generated by formbinator when using listOf
11:10 < paulvisschers> mightybyte: I'm not very good at javascript though, so I'm not really sure how it should be used to add another field in there (especially with nested lists)
11:18 < h_buildbot> Build for ghc-6.8.3_STABLE OK. Test suite ran. 17/73 test cases failed. Check http://buildbot.happstack.com/ for details.
11:20 < mightybyte> paulvisschers: Oh, I haven't even thought about nested lists. :)
11:31 < h_buildbot> Build for ghc-6.10.1_STABLE OK. Test suite ran. 17/73 test cases failed. Check http://buildbot.happstack.com/ for details.
11:46 < h_buildbot> Build for ghc-6.8.3 OK. Test suite ran. 17/73 test cases failed. Check http://buildbot.happstack.com/ for details.
11:49 < koeien> h_buildbot: status
11:49 < h_buildbot> Building ghc-6.10.1
11:55 < koeien> h_buildbot: pause
11:55 < h_buildbot> Already paused, or currently building. Try 'status'
11:58 < h_buildbot> Build for ghc-6.10.1 OK. Test suite ran. 16/73 test cases failed. Check http://buildbot.happstack.com/ for details.
11:58 < koeien> h_buildbot: status
11:58 < h_buildbot> Idle.
11:58 < koeien> h_buildbot: pause
11:58 < h_buildbot> Paused
11:58 < koeien> h_buildbot: status
11:58 < h_buildbot> Paused.
11:58 < koeien> h_buildbot: resume
11:58 < h_buildbot> Resumed.
11:58 < koeien> h_buildbot: status
11:58 < h_buildbot> Idle.
11:59 < koeien> ok i'll quit spamming ;) it works
12:59 < mae_work> um just wanted to say that
12:59 < mae_work> if any patches were in the queue but stopped because of 0.1
12:59 < mae_work> please feel free to start working on happstack dev branch again
13:00 < mae_work> i know there were some on th ml
13:00 < mae_work> the *
13:04 < mae_work> well i guess just 1
13:04 < mae_work> http://groups.google.com/group/HAppS/browse_thread/thread/4ef11226f84a8d02?hl=en
13:04 < Saizan> are we sure we want to support the latest HaXml ?
13:05 < mae_work> Saizan: i'm not sure, do we? :)
13:06 < mae_work> I don't see why not, but lets hear your perspective.
13:06 < Saizan> iirc, malcomw considers the 1.13.x the stable one
13:06 < mae_work> ahh
13:07 < mae_work> please post your counter-reply on the thread then
13:08 < mae_work> and i will back you up
13:08 < mae_work> err i guess it would just be a 'counter'
13:08 < mae_work> that is a double negative, in a sense
13:18 < Saizan> do i sound harsh in that reply?
13:21 < mae_work> nope
13:34 < koeien> nah not really
13:34 < koeien> i'm not sure about my patch though, whether it's the right approach
13:34 < koeien> somebody with more experience with HAppS-Data should be able to answer it
13:38 < koeien> mae_work: perhaps also an e-mail to the 'real' haskell mailing list?
13:38 < mae_work> which is?
13:39 < mae_work> cafe?
13:39 < koeien> no
13:39 < koeien> you just sent one there
13:39 < mae_work> ok
13:39 < koeien> haskell@
13:39 < koeien> http://www.haskell.org/haskellwiki/Mailing_Lists
13:40 < koeien> it's pretty low-volume but appropriate to announce that there
13:41 < mae_work> don't see an announce there
13:41 < mae_work> you sent one?
13:41 < koeien> no
13:41 < koeien> i could do so, if you're not subscribed
13:42 < mae_work> just sent one
13:42 < koeien> ok
13:43 < koeien> yes, got it
13:43 < koeien> mae_work: do you have any opinion about issue 51, http://code.google.com/p/happstack/issues/detail?id=51
13:48 < mae_work> not sure
13:49 < mae_work> lets let it sit a bit longer, as I am not sure either
13:49 < mae_work> what exactly is wrap doing
13:49 < mae_work> its adding an extra element?
13:49 < koeien> yes
13:49 < mae_work> a wrapping Xml element?
13:50 < koeien> yes
13:50 < koeien> (locally as a helper function)
13:50 < mae_work> i see that
13:50 < mae_work> but hmm
13:50 < mae_work> i guess i don't understand what this test is trying to prove
13:50 < mae_work> until we understand that we shouldn't mess with it
13:51 < koeien> igloo wrote that test case
13:51 < koeien> i understand what it's trying, but i doubt this is correct/feasible
13:51 < mae_work> let me work on that in the back of my mind, i gotta run
13:51 < koeien> bye
15:38 < koeien> appearantly 0.1 fails to compile on windows
15:38 < stepcut> yeah
15:38 < stepcut> apparently we don't have any windows developers
15:39 < koeien> nope, gnu/linux here
15:39 < koeien> also some osx people i think ;)
15:40 < stepcut> the happstack facebook page member is 100% male as well. Thus far, happstack is used entirely by men who use linux and mac os x... :-/
15:40 < koeien> does this surprise you?
15:41 < stepcut> well, 20% of computer science majors are women, and windows is a pretty popular platform :)
15:41 < koeien> i don't have facebook, not planning to sign up either
15:41 < koeien> not at my uni
15:41 < koeien> about the women ;)
15:42 < stepcut> the percentage keeps dropping after peaking a number of years ago
15:42 < koeien> i think it's < 10% here
15:42 < koeien> mathematics is more even
15:43 < stepcut> yeah, women are taking over vet med though
15:44 < koeien> the government is trying to get more women in hard sciences here. so far most women are attracted to "soft" hard sciences
15:44 < koeien> as opposed to "real" hard sciences
15:45 < koeien> anyway, is there any way to fix that bug? i can't test it :/
15:45 < koeien> i see no reason not to support windows
15:46 < koeien> except for the fact that we can't test it :P
15:48 < stepcut> agreed
15:48 < stepcut> happstack should be pretty OS agnostic. In, hopefully it will run on HOp someday :)
15:49 < koeien> a purely functional operating system?
15:50 < stepcut> http://lambda-the-ultimate.org/node/299
15:51 < stepcut> http://programatica.cs.pdx.edu/House/
15:51 < koeien> i've heard about house
15:51 < stepcut> same thing
15:52 < stepcut> hop just doesn't have a full desktop environment
15:52 < wchogg> hop is basically just the ghc that can run on bare metal, I thought
15:53 < Saizan> can we get code.google.com to send updates to issues to a mailing list?
15:53 < stepcut> obviously, supporting all sorts of network cards and hard drive controls would be a nightmare. But something that supported only EC2, for example, might be attractive.
15:54 < Saizan> happs-* compiled fine on windows btw
15:57 < stepcut> hrm
15:57 < stepcut> where some #ifdefs removed?
16:00 < stepcut> ah, the addition of acceptLite is what happened
16:00 < Saizan> yeah, to fix this: http://code.google.com/p/happstack/issues/detail?id=1&can=7
16:01 < koeien> that says "fixed"
16:02 < stepcut> fixed somethings, broke others :)
16:02 < stepcut> I'll file a new bug
16:03 < koeien> Saizan: this bug tracker is suboptimal imo
16:03 < Saizan> it says fixed because the issue was fixed, but the solution wasn't tested enough
16:04 < koeien> yeah, not on Windows
16:04 < Saizan> we had a report on solaris too
16:04 < koeien> appearantly ;)
16:04 < Saizan> essentially we're going too lowlevel to be portable..
16:06 < koeien> this is about 'reverse resolution'? why would we need this?
16:06 < paulvisschers> <stepcut> well, 20% of computer science majors are women, and windows is a pretty popular platform :) -- It's only 1-3% at our uni
16:07 < paulvisschers> Same uni as koeien actually
16:07 < koeien> o rly?
16:08 < paulvisschers> Yup
16:08 < koeien> ;)
16:08 < paulvisschers> We had 3 out of 75 in our year, then there was 1, then 0 en then 2 or something
16:08 < paulvisschers> Ow you meant about the uni :)
16:09 < koeien> stepcut: i have an OpenBSD VM
16:11 < stepcut> sweet!
16:11 < koeien> not that i use this regularly. in fact i only booted it twice
16:11 < stepcut> is the buildbot portable to windows at all?
16:11 < koeien> no
16:12 < stepcut> I have windows xp on my laptop, but I have not booted it in a year
16:12 < koeien> apart from shellscripting & unix fifo's, yes
16:12 < koeien> and chroots
16:12 < stepcut> shellscripting == the suck
16:12 < koeien> i only use it a bit to start programs, i have some haskell scripts to parse stuff
16:12 < stepcut> we should advertise on the list for someone to build happstack on windows regularily
16:13 < koeien> if somebody could get the buildbot to work on windows, that would be fine as well. but i can't provide it myself
16:15 < Saizan> the API for network should make clearer what's portable and what isn't, though
16:15 < koeien> i don't know how to have multiple ghc installations on windows anyway
16:16 < Saizan> they get installed in different directories
16:17 < koeien> yeah, but how to call them. change the PATH ?
16:17 < Saizan> or just specify the full path
16:17 < koeien> hard to do with cabal
16:17 < Saizan> why?
16:17 < koeien> cabal --with-ghc=?   ?
16:18 < Saizan> cabal install -w C:/ghc/6.8.3/bin/ghc
16:18 < koeien> hmm, --wth-compiler, never mind
16:18 < Saizan> --with-ghc works too
16:18 < koeien> anyway, i don't have access to a windows machine
16:20 < koeien> i could try a build on OpenBSD now :)
16:21 < stepcut> koeien: well, even one version of ghc on windows would be better than what we got now :)
16:22 < koeien> stepcut: Greg Fitzgerald volunteered for windows
16:22 < stepcut> sweet!
16:22 < koeien> yeah, together with the buildbot we can minimize such issues
16:23 < koeien> BSD and GNU/Linux should be pretty similar anyway
16:23 < koeien> (at least, from the Haskell point of view...)
16:26 < Saizan> so, we've to port the buildscripts to System.Process?
16:26 < koeien> if you want to port it at all
16:26 < stepcut> I wonder if buildbot would run on mac os
16:27 < stepcut> does the buildbot that builds using ghc 6.8.3 need to be built *with* 6.8.3? Or can it use the improved System.Process stuff in 6.10?
16:28 < koeien> i see no problem requiring 6.10
16:28 < Saizan> apart from people only having 6.8 on their machines :)
16:28 < koeien> how many people that want to run the buildbot only have 6.8 ?
16:28 < koeien> not many, i guess
16:28 < stepcut> too bad buildbot doesn't use happstack-state. The different buildbots could have a shared state :)
16:29 < koeien> stepcut: :):) MySQL does that too!
16:29 < stepcut> :p
16:29 < koeien> i only used MySQL because i had that installed already
16:29 < stepcut> tehehe
16:29 < koeien> and the files can get pretty big
16:29 < koeien> so i rather have them on disk
16:29 < stepcut> yeah, but happstate gives you precise control over what goes in RAM vs disk
16:30 < stepcut> :p
16:30 < koeien> ok. anyway, it is better to eat our own dog food, i agree
16:30 < Saizan> uhm wait
16:31 < Saizan> cabal-install already has build-reports implemented
16:31 < Saizan> we can use that
16:31  * stepcut does not even know what that means
16:32 < Saizan> i only partially do :)
16:32 < Saizan> but see ~/.cabal/logs/build.log for example
16:32  * koeien doesn't really see the advantage vs. piping the output to a file
16:33 < Saizan> well there should also be support for sending them to a central server
16:34 < stepcut> I'm glad someone agrees with me... http://code.google.com/p/happstack/issues/detail?id=29
16:35 < koeien> stepcut: yeah it seemed nice on the presentation. i have no informed opinion so far
16:35 < koeien> Saizan: having lots of buildbots + 1 central repository of build results?
16:36 < stepcut> I just find it humorous that someone added the same link that I already had
16:36 < Saizan> koeien: exactly
16:37 < Saizan> koeien: and being very easy to become a buildbot
16:37 < koeien> Saizan: how would we do this? porting all scripts to Haskell + running the MySQL server while listening to 0.0.0.0 ?
16:38 < koeien> or provide some HTTP - API
16:38 < stepcut> it would be nice if build-reports could send the report to a central server, even if it failed, because that would make it easy for us to get full reports when people's builds fail (such as the windows and open solaris failures)
16:39 < koeien> stepcut: i dislike to do this "phoning home" automagically
16:39 < stepcut> koeien: well, it could be as automatic as darcs send? Would that be ok?
16:39 < koeien> stepcut: yeah that's fine
16:39 < Saizan> for generating the reports we can simply use "cabal install --build-reports"
16:40 < Saizan> to send them back we can either finish to implement this: http://hackage.haskell.org/trac/hackage/ticket/184
16:40 < koeien> stepcut: but don't use sendmail, lots of people aren't going to have that configure
16:40 < Saizan> or write our own tool
16:40 < stepcut> koeien: not if our tool does an HTTP post instead of an email
16:40 < koeien> it's fine to use the cabal feature, other people could profit
16:40 < koeien> stepcut: yes, HTTP is fine
16:41 < koeien> writing our own tool is not hard to do and is potentially faster
16:42 < koeien> but i see what i can do to open up the buildbot. i use chroot, but it's problematic to do that with windows
16:42 < stepcut> I wonder if we can add it to Setup.hs so you can do, runhaskell Setup.hs send-build-report
16:42  * koeien wonders how extensive the build-report is
16:42 < koeien> the files in ~/.cabal/logs are very short
16:43 < koeien> it's useful to have the whole log
16:43 < Saizan> well, if you enable the --build-reports flag you get all the cabal output in a separate file
16:43 < koeien> this was only a summary?
16:43 < koeien> we could do our own magic in bin/build-install-all.sh but that's not portable anyway
16:44 < Saizan> yes, in build.log you get only the summary
16:44 < koeien> it would be great to lower the barrier to submit this reports
16:44 < koeien> and to become a dedicated buildbot
16:45 < koeien> for some platform + GHC
16:45 < h_buildbot> Build for ghc-6.8.3 OK. Test suite ran. 17/73 test cases failed. Check http://buildbot.happstack.com/ for details.
16:48 < Saizan> the poor man version is e.g to ask them to send ~/.cabal/logs/happstack-server-0.1.log via mail after building with --build-reports :)
16:48 < koeien> this is acceptable imo
16:48 < koeien> anyway, i'll port the build script to Haskell
16:49 < Saizan> it doesn't the summary though, only the output
16:49 < koeien> the wrapper script, that gets run every 5 mins, is non-portable
16:49 < koeien> depends on how to use crontab on your platform
16:49 < koeien> and how to chroot, if you want to do that
16:50 < stepcut> that sounds good
16:51 < koeien> then i have to think about some HTTP API as well
16:52 < koeien> and i promised an article about Happstack + SSL :)
16:53 < Saizan> cabal-install has cabal report too
16:53 < koeien> that gets pushed to the central hackagedb server?
16:54 < Saizan> that's the idea, or any server you specify in .cabal/config
16:54 < koeien> the bug report mentions that it's mostly server side that's left
16:54 < Saizan> yeah
16:55 < Saizan> though report is looking for files under reports/, while the logs are created in logs/
16:55 < Saizan> we need to contact dcoutts :)
16:55 < koeien> we could use (or wait for) that for regular users + some scripts to set up a buildbot / pushing info to central buildbot server
16:57 < koeien> at least i woudl suggest to wait for the cabal implementation
16:58 < h_buildbot> Build for ghc-6.10.1 OK. Test suite ran. 16/73 test cases failed. Check http://buildbot.happstack.com/ for details.
16:59 < Saizan> well yeah, but cabal needs contributors :)
16:59 < Saizan> and hackage-server is in happs too
17:00 < koeien> i understand that, but let's not duplicate effort here ;)
17:00 < Saizan> yeah, exactly,  i was saying that if we implement something like this we should do that in cabal :)
17:00 < koeien> so: Haskell has, an operating system, an editor, a window manager, a compiler, a revision control system, a shell
17:00 < koeien> a web server :) we only need a browser...
17:01 < Saizan> a shell?
17:01 < koeien> http://changelog.complete.org/archives/492-announcing-hsh-the-haskell-shell
17:01 < koeien> yes, pointless ;)
17:02 < Saizan> not bad if it's portable to windows :)
17:02 < koeien> i'll see how far i'll get porting the build scripts this week
17:02 < koeien> + creating some HTTP api
17:03 < stepcut> koeien: what, Network.Browser isn't good enough for ya ?
17:03 < koeien> i use netcat to browse
17:03 < stepcut> :p
17:06 < stepcut> the buildbot should try to build the haddock docs as well
17:06 < stepcut> since those often fail
17:07 < koeien> wasn't that due to a bug in haddock?
17:07 < stepcut> dunno, but even if haddock is working correctly, the docs often fail
17:08 < stepcut> if you forget to escape stuff
17:08 < koeien> good idea
17:08 < koeien> i'll do that after the haskellification
17:08 < stepcut> ok
17:24 < koeien> i'll just do    main = readFile "shellScript" >>= system
17:25 < stepcut> koeien: :-/
17:36 < paulvisschers> stepcut: What country are you from?
17:37 < stepcut> paulvisschers: U.S. of A.
17:38 < stepcut> why?
17:38 < paulvisschers> koeien and I were just discussing how this channel was at its most active at 4:30 AM
17:39 < stepcut> :)
17:39 < stepcut> I am least active at 4:30AM
17:39 < stepcut> depending on what time zone you are talking about ;)
17:39 < paulvisschers> Ours, which is +1 at the moment
17:39 < koeien> lol
17:39 < stepcut> it's 4:39PM were I am right now
17:39 < paulvisschers> 11:39 PM here
17:40 < stepcut> ah
17:40 < paulvisschers> which means I should actually go to bed around now
17:40 < stepcut> mae is west coast, so it's 2:40PM where he is
17:41 < Saizan> yay, 3 happstackers(?) in GMT+1
17:41 < koeien> i actually saw some happs advocacy lately on the functional programming day
17:41 < koeien> in the netherlands
17:42 < stepcut> heh
17:42 < paulvisschers> chr1s and eelco are also GMT+1, although they haven't really said anything for a while
17:42 < paulvisschers> koeien: From those two :)
17:42 < koeien> i know :/
17:42 < stepcut> apparently happstackcon is going to be in GMT+1 :)
17:42 < koeien> there's no way around it :)
17:43 < koeien> i heard people talking about a hackathon in utrecht. was that ghc-related?
17:43 < paulvisschers> Yeah I read that too
17:43 < paulvisschers> dons said something in a mail about a hackage hackathon
17:56 < paulvisschers> I'm off, goodnight
18:47 < dcoutts> @yarr!
18:48 < Apocalisp> I want to help
18:48 < dcoutts> Saizan: so you'd run a hackage-server and get users/bots to report to that
18:48 < dcoutts> Saizan: and if that involved making improvements to the hackage-server that'd be great :-)
18:49 < wchogg> Anyone know why the simpleHTTP' function isn't exposed by HAppS.Server.SimpleHTTP ?  I'm not sure why that would be.
18:49 < dcoutts> Saizan: it needs a little love, but it's basically all there.
18:49 < Saizan> dcoutts: and you think it's better to get reports against tarballs on that server rather then letting users push reports of the build after pulling from the darcs repo?
18:50 < dcoutts> Saizan: cabal-install will only generate reports for packages that come from a server
18:50 < dcoutts> otherwise it does not know where to send them
18:50 < dcoutts> and it'd be a privacy leak in general
18:50 < stepcut> wchogg: no idea. Looks like it used to be.
18:50 < koeien> that's precisely what we want
18:50 < dcoutts> koeien: sorry, which?
18:50 < Saizan> dcoutts: ok, i guess we can upload snapshots to our server
18:51 < Saizan> dcoutts: but does it also generate the full log and uploads it with --build-reports, right?
18:51 < koeien> dcoutts: not sending reports to hackage for darcs builds ;)
18:51 < Saizan> well, the uploading is done by cabal report i guess
18:52 < Saizan> koeien: we can have our own semi-private hackage :)
18:52 < koeien> Saizan: yeah that could be
18:52 < koeien> Saizan: but not sure why it's more useful than fresh darcs at this point
18:52 < koeien> Saizan: except for the build-report thingy :)
18:53 < Saizan> it can be useful for nightlies or release candidates, so you've a precise tarball to refer to
18:54 < Saizan> even if darcs changes | head works fine for that i guess :)
18:55 < koeien> rc's are of course possible
18:55 < koeien> but they should be tagged anyway?
18:55 < dcoutts> if you're running your own hackage server then there's no problem in uploading nightly snapshots
18:55 < koeien> it could be useful in addition to having a few buildbots
18:56 < stepcut> dcoutts: I often do not realize that modules are missing from my .cabal until I try to do a 'runhaskell Setup.hs sdist' and discover the unpacked tarball does not build. Is that something that is going to change?
18:56 < dcoutts> stepcut: eventually yes
18:56 < stepcut> dcoutts: sweet!
18:56 < dcoutts> stepcut: in two ways, the first is an sdist --check  thing, to sdist and try to build from it
18:57 < dcoutts> the second, harder, is when cabal does it's own module dep chasing it'll discover which modules you forgot to list
18:57 < stepcut> koeien: in the short term, it would be nice if buildbot used sdist to build tarballs, and then unpack those tarballs elsewhere to build them so we notice...
18:57 < stepcut> dcoutts: cool
18:57 < dcoutts> Saizan: yes, I think it should work with --build-reports and cabal report
18:57 < koeien> stepcut: sdist is a cheap operation right?
18:57 < dcoutts> Saizan: however if you have suggestions for a better user interface that'd be nice
18:58 < stepcut> koeien: yeah, it just tars up the files referenced in the .cabal
18:58 < dcoutts> Saizan: the current one was only for demonstration purposes, it's not necessarily the final ui
18:58 < koeien> stepcut: in that case i can build from the generated tarball instead of in the repos
18:58 < dcoutts> sdist also checks for various QA problems
18:58 < koeien> yeah -Werror and stuff
18:58 < stepcut> koeien: yeah, the only tricky part is knowing the name of the tarball, because it includes a version number from the .cabal
18:59 < koeien> stepcut: i can probably figure it out or override it
18:59 < dcoutts> koeien: no, packaging specific problems, missing or silly things in the .cabal file
18:59 < dcoutts> koeien: if you're using cabal-install, then 'cabal check' does the same thing
18:59 < koeien> ok. i thought -Werror was disallowed as well
18:59 < stepcut> koeien: if you are really intense, I can show you how to parse the .cabal using the cabal libraries :)
18:59 < dcoutts> koeien: oh, I see, yes. Checks of that sort.
18:59 < koeien> stepcut: i'll use grep and cut
18:59 < koeien> stepcut: ;)
19:00 < stepcut> koeien: that won't be very portable...
19:00 < koeien> stepcut: j/k
19:00 < stepcut> I recently wrote a function that looks at your installed package index and tries to figure out which libraries are provided as virtual packages by the ghc6 deb
19:00 < koeien> stepcut: problem is that i have to do 7 sdists or so
19:01 < stepcut> so, I am now slightly familiar with using the cabal API
19:01 < stepcut> koeien: mapM buildAndInstall ["happstack-util", "happstack-data", etc]
19:01 < stepcut> ;)
19:01 < dcoutts> stepcut: mm, how does it do that? work out which ones are installed in the same location as the rts package?
19:01 < Saizan> dcoutts: the server part of the build reports is all to be done?
19:01 < koeien> stepcut: yeah but i need to keep track of dependencies
19:02 < dcoutts> Saizan: pretty much, though only up to demo quality and there is no authentication at the moment iirc
19:02 < koeien> i'll try to keep the buildbot as general as possible, so other haskelling projects can use it if they want
19:02 < dcoutts> koeien: you know that .cabal files can specify darcs/git/whatever repos?
19:02 < koeien> dcoutts: and what does this imply?
19:03 < dcoutts> koeien: it'd be really useful to have a tool that would do the equivalent of cabal install's build reports, but for dev repos
19:03 < stepcut> dcoutts: it finds all the installed packages cabal packages, and then it looks to see if the 'library-dirs' directory for a package is listed in /var/lib/dpkg/info/ghc6.list
19:03 < koeien> dcoutts: yes that's basically what i built. http://buildbot.happstack.com/
19:03 < stepcut> s/installed packages cabal/installed cabal/
19:04 < dcoutts> stepcut: right
19:04 < dcoutts> koeien: nice
19:04 < koeien> dcoutts: it is not very portable atm, won't run on windows
19:04 < stepcut> dcoutts: unfortunately a perfect mapping from cabal name -> debian package name is much trickier
19:04 < dcoutts> koeien: so would it be useful to that system to discover the repo from the/a .cabal file?
19:04 < dcoutts> stepcut: I thought it was mostly mechanical
19:05 < stepcut> dcoutts:  it is hard to tell if the profiling libraries will be in a -dev or -prof package.
19:05 < koeien> dcoutts: at this moment i just do a 'darcs pull -a'
19:05 < dcoutts> stepcut: oh, they're not consistent?
19:05 < koeien> dcoutts: i don't see what i can do with that information
19:05 < stepcut> dcoutts: it is mechanical to the degree that everyone follows the same rules for naming their debian packages based on the cabal package name
19:06 < dcoutts> koeien: eg, perhaps a way to configure a build bot client would be to point it to a hackage server and have it build the dev versions of the packages there
19:06 < stepcut> dcoutts: I think most people follow the same rules. But no one is enforcing it. Since most of the packages we build where created by cabal-debian though, that helps us in the short term
19:06 < dcoutts> stepcut: right
19:06 < Saizan> dcoutts: how do i add my own server as a repo to cabal-install? it doesn't seem to have an equivalent of /packages/archive
19:07 < dcoutts> Saizan: it's in the .cabal/config file
19:07 < dcoutts> remote-repo: name1:url1
19:07 < koeien> dcoutts: at this moment it just 'tracks' a darcs repository
19:07 < dcoutts> remote-repo: name2:url2
19:07 < Saizan> dcoutts: i'm looking at it, and it currently has remote-repo: hackage.haskell.org:http://hackage.haskell.org/packages/archive
19:07 < dcoutts> Saizan: so add an extra line
19:07 < koeien> dcoutts: so not a hackage server
19:08 < Saizan> dcoutts: and what do i use as url?
19:08 < dcoutts> koeien: right, I'm just thinking for the future
19:08 < koeien> dcoutts: the hackage server now already 'autobuilds', right? at least the official one does
19:08 < dcoutts> Saizan: ah, right, yes. I think for new style hackage servers you just use the root url, not packages/blah
19:08 < dcoutts> koeien: yes, though not very well
19:09 < koeien> dcoutts: what could be improved?
19:09 < koeien> there is also an IRC bot :)
19:09 < dcoutts> koeien: the new system has a better design for that, but it's not completed, mostly due to lack of time on my part
19:09 < koeien> h_buildbot: status
19:09 < h_buildbot> Idle.
19:10 < dcoutts> koeien: so Saizan is looking at trying the new system, and since the server side is implemented on happs, I hope you and he might be able to help us complete it
19:10 < koeien> dcoutts: okay. for the happs needs its more useful to track a repos i think. it could upload nightlies automagically
19:10 < dcoutts> I aim to get back to work on the new hackage-server, eg port it to happstack and complete the build reporting etc
19:11 < dcoutts> but my first goal is point releases of Cabal and cabal-install
19:11 < koeien> Saizan: what do you think of the pro/cons of each system? to me it would seem useful to have a hybrid system, or at least to keep tracking a repos (i.e. what it's now doing)
19:12 < dcoutts> koeien: sure. More generally I'd like to get the hackage server to support this stuff, not just for released packages but also dev versions.
19:12 < dcoutts> I think it'd be useful for many projects and in-house dev teams
19:12 < koeien> yep
19:12 < koeien> continuous integration ftw
19:14 < koeien> so you'd like hackage+1 to support automatic tracking of darcs/git/hg repositories?
19:15 < dcoutts> koeien: depends what you mean about that exactly
19:15 < koeien> or am i understanding this incorrectly?
19:15 < dcoutts> the info is already there in .cabal files (at least if people put the info in)
19:15 < dcoutts> the current and new hackage server can report on the web pages the links to the repos
19:15 < koeien> dcoutts: atm the buildbot polls a darcs repos every 5 minutes, and builds the package if there are changes
19:16 < dcoutts> but the bigger benefit is in tools that can use the repo info to do interesting things
19:16 < koeien> there are two orthogonal issues, tracking a repos, and sending reports to the hackage db
19:16 < dcoutts> like building, tracking changes etc
19:16 < dcoutts> koeien: yep right
19:16 < Saizan> koeien: i think we should have bots that send reports to our hackage-server, so we get both automated and casual reports
19:17 < Saizan> koeien: we've to work a little on the presentation though
19:17 < koeien> Saizan: yes. the problem is that the automated builds are 'newer' than the casual builds
19:18 < koeien> so there has to be support for that in the server
19:18 < Saizan> http://79.9.57.119/packages/syb-with-class-0.5.2/buildreports <- does this link work?
19:18 < dcoutts> yep
19:18 < koeien> for me it does
19:18 < Saizan> nice, just to show that it works :)
19:19 < koeien> sounds ok. we just need a better version number scheme
19:19 < koeien> or at least, a way to distinguish versions
19:20 < dcoutts> Saizan: so obviously the presentation of the build reports is currently very primitive
19:20 < dcoutts> koeien: yes, the current detailed build report info is not good for distinguishing dev versions
19:20 < dcoutts> that really needs a darcs/git context field
19:21 < koeien> unfortunately hg is better in this regard
19:21 < koeien> compared to darcs
19:21 < koeien> i don't know how to solve this in darcs
19:21 < stepcut> koeien: I might
19:21 < dcoutts> as in #darcs
19:21 < Saizan> what about sdist --snapshot? too hard to tell at which point in the repo it refers to?
19:22 < dcoutts> Saizan: that's only daily resolution, but it could be higher, the snapshot does not need to use a date
19:22 < dcoutts> it could be a context hash
19:23 < koeien> stepcut: please tell :)
19:23 < Saizan> oh, right
19:23 < dcoutts> anyway, I'm glad we're thinking about this :-) however right now I've got to sleep
19:23 < dcoutts> g'night chaps
19:23 < koeien> i'm going to bed as well
19:23 < Saizan> night :)
19:24 < stepcut> koeien: there is some code here that generates a unique revision for a darcs repo, I forget what rules it follows though, http://src.seereason.com/autobuilder/Debian/AutoBuilder/BuildTarget/Darcs.hs
19:24 < stepcut> the unique revision number is pretty intense though
19:25 < stepcut> Revision: darcs:http://src.seereason.com/ghc610/autobuilder=20090201182257-c6ee2-e01976a76cfe4aceb127cdc1d9bb2f2f824aff38.gz
19:25 < koeien> oh that's fine
19:25 < koeien> if you could get it by that code
19:26 < stepcut> that directory contains a bunch of instances of BuildTarget
19:26 < stepcut> which is a class for checking out, updating, and getting a unique id for a source code
19:26 < stepcut> so, it knows how to tell if anything has changed after a darcs pull, etc
19:27 < koeien> stepcut: yeah i do that by grepping on the output
19:27 < koeien> ;)
19:28 < Saizan> the id in question is 20090201182257-c6ee2-e01976a76cfe4aceb127cdc1d9bb2f2f824aff38 ?
19:28 < stepcut> yes...
19:28 < koeien> ah i see.
19:28 < stepcut> I have very little idea what that id  it actually means
19:28 < koeien> just the XML output of darcs changes --xml-output
19:29 < koeien> but, will that enable us to recover the repos of that hash?
19:29 < Saizan> and can you get back to a particular point in the repo from that? or do you just zip and save the state of the repo at that point?
19:30 < stepcut> Saizan: dunno. in the context of this code, a source .deb is produced
19:30 < koeien> well, it's kinda essential ;)
19:31 < Saizan> hg has revision numbers?
19:31 < koeien> not numbers, but hashes
19:31 < koeien> but hg is linear
19:32 < koeien> hg, example   changeset:   12:c7574eb7bb4a
19:32 < koeien> you can always refer to that hash to recover the state at that point
19:36 < koeien> i don't see a way to emulate this in darcs
19:36 < stepcut> koeien: I don't think you can do any better than storing a list of all the hashes of all the patches?
19:37 < koeien> painful... very painful
19:37 < stepcut> :)
19:37 < koeien> also painful to restore
19:37 < stepcut> that's what linus said..
19:37 < koeien> ?
19:38 < Saizan> it seems there's darcs changes --context
19:38 < Saizan> and darcs get --context=FILE
19:39 < koeien> yes that should do the trick
19:39 < koeien> you have to send that file with the build report though
19:40 < Saizan> right, and we can use its hash as a sort of additional version point
19:40 < koeien> Saizan: there is no way to recover from that
19:41 < koeien> i.e. given a hash i cannot restore the repos in that state
19:41 < Saizan> no
19:41 < Saizan> the hash was only to have a compact way to distinguish it from the base version in the .cabal
19:41 < Saizan> we still need the whole file
19:42 < koeien> but in the sdist .tar.gz, a _darcs repos will not be included
19:42 < koeien> so regular users only have a version number
19:43 < koeien> and bleeding-edge users/developers have a version number+SHA-1 hash
19:43 < Saizan> sha-1 hash of the context?
19:43 < koeien> yeah, or whatever hash you like
19:43 < koeien> as a way to immediately identify things that are "the same"
19:43 < Saizan> though the build-reports don't include a tarball as of now
19:43 < koeien> or grouping
19:44 < koeien> Saizan: "tarball"?
19:44 < Saizan> oh, right, we don't need that..
19:44 < Saizan> koeien: i was thinking about the sources
19:44 < koeien> Saizan: but what if a user grabs a nightly?
19:45 < koeien> Saizan: the nightly will not include the repos metadata
19:45 < Saizan> no, it'll have a date
19:45 < koeien> as an extra cabal field?
19:46 < Saizan> like happstack-server-0.1.20090201
19:46 < koeien> ok
19:46 < Saizan> like sdist --snapshot do
19:46 < koeien> we have to store the fact that 20090201 == this list of patches
19:46 < Saizan> but we probably want to group the nightlies under the 0.1 version
19:47 < Saizan> koeien: ..or we can include the context file in the .tar.gz
19:47 < koeien> Saizan: yeah but that's a bit ugly perhaps?
19:47 < koeien> Saizan: in any case only for nightlies
19:47 < Saizan> koeien: right
19:48 < koeien> Saizan: but then the build-report stuff of cabal needs some adaption, i think?
19:48 < koeien> Saizan: or there should be a way to submit an extra file
19:48 < Saizan> koeien: for nightlies we don't need anything extra, the original tarball will be on the server
19:49 < koeien> hmm
19:49 < Saizan> koeien: from darcs directly we need a way to add the darcs context, yeah
19:49 < koeien> anyway, i'm really going to bed now
19:49 < koeien> let's talk more later this week
19:49 < Saizan> ok :)
19:50 < Saizan> night
19:50 < koeien> bye
20:49 < sm> hey all.. didn't I see mention of all lower-case names in the 0.1 release notes ?
20:50 < sm> hmm.. maybe pulling those changes onto a mac fs did not rename the files
20:50  * sm gets a fresh copy
20:51 < sm> no! still HAppS, everywhere HAppS!
20:51 < stepcut> sm: the cabal names are lower case
20:51 < stepcut> the module names are not being transitioned until later (though not much later)
20:52 < sm> I see, thanks
20:52 < Saizan> is HAppS so untypable?:)
20:52  * stepcut looks HAppS
20:52 < sm> yes
20:52 < stepcut> s/looks/loves/
20:54 < Saizan> i like it too, it's short, and you can refer to happs without much problems, i don't write write imports that often
20:55 < stepcut> plus 'happscon' is easier to say than 'happstackcon'
21:31 < mae_> ; )
21:34 < gwern> what are the happs, friends?
21:34 < Axman6> hmm, happscons
22:58 < mightybyte> HAppS is rather horrible to type for those of us who learned the traditional hit-shift-with-the-opposite-hand technique.
22:59 < mightybyte> I'd love the name if they had just spelled it Happs or happs.
23:17 < shapr> well, you could skip the caps
23:18 < mightybyte> I'm anal about correct caps.
23:19 < mightybyte> It's a tragic character flaw. :)
23:19 < shapr> heh
23:56 < mae_> ok, pushed up a module for util
23:56 < mae_> converts HostAddress6 and HostAddress to human readable string
23:56 < mae_> hoping to dissolve need for getNameInfo
23:57 < stepcut> sweet!
23:57 < mae_> I need the happs-util tests run on a mac and windows platform before I feel comfortable backporting as a stable release (i want to fix the windows build for happs-server)
23:57 < mae_> well actually they won't run on windows
23:57 < mae_> the tests require getnameinfo :\
23:57 < mae_> god network is borked
23:58 < mae_> well, at least make sure it compiles on windows
23:58 < mae_> (without tests)
23:58 < mae_> bbl
--- Log closed Thu Feb 05 00:00:00 2009