--- Log opened Thu Jan 29 00:00:11 2009
01:04 < mae> hello :)
01:38 < vegai> a little bit of critique: http://aftnn.org/journal/661
01:42 < sm> vegai: interesting
01:45 < vegai> I wonder if it's possible for happs-server to reach the performance of nginx when serving static files
02:00 < Lemmih> I doubt anyone is willing to spend that much time optimizing the server.
02:52 < mae> : )
02:53 < mae> nginx can serve static files in front of happstack
02:53 < mae> happstack will serve app data super fast tho ;)
03:42 < vegai> therefore might it be also sensible to have happs be an fcgi application?
04:17 < koeien> mae: my real name is `Jochem Berndsen' btw :) (for the 'responsibilities' page)
04:51 < Saizan_> mae: no response from Igloo yet
05:06 < Saizan_> stepcut: why do you need the installed packages for the testsuite?
08:10 < gour> hi, happstack is not intended to be used on cheap shared hosting ever?
08:10 < gour> something in the range of django-reqs.
08:10 < Saizan> it depends on the size of the state managed by MACID
08:11 < gour> so. it will stay MACID-only, without some dbase back-end?
08:12 < mightybyte> gour: You can use a db back-end if you want to.
08:12 < gour> hmm
08:13 < gour> the point is whether to stay with haskell for my web needs or dive into django and being able to host site without VPS
08:13 < mightybyte> But that's arguably not the intent of HAppS.
08:13 < gour> that's i understands and question if happstack will modify it a bit
08:14 < mightybyte> My understanding is that happstack won't modify that much.
08:14 < Saizan> well, you are not forced to use HAppS-State, and you can easily use a separate rdbm via the libraries on hackage
08:15 < mightybyte> happs(tack) has a web server, and it has MACID state contructs.  If you want to use the server alone, that's fine.
08:15 < Saizan> if you're asking for some special support for databases inside happstack, that's not planned
08:16 < mightybyte> We might argue over whether it's the web server part or the state part that is the main point of happs, but I think most developers would say that the state part is the real point.
08:16 < gour> ok. so database support is not going to be part of framework
08:17 < mightybyte> Not to my knowledge.
08:17 < gour> ok. thanks
08:19 < gour> i agree that happs is great, but for my needs something more like haskell-django would be appropriate
08:20 < Saizan> there are other haskell webframeworks
08:21 < gour> turbinado?
08:21 < Saizan> yeah, and others i think
08:21 < Saizan> i've never used those, though
08:22 < gour> not shared-hosting-friendly
08:23 < gour> i'm more for http://blog.snoyman.com/2009/01/25/haskell-web-framework/ stuff
08:24 < koeien> can you run arbitrary programs on your shared host?
08:24 < mightybyte> dbpatterson mentions the hvac framework in a comment at http://aftnn.org/journal/661
08:24 < koeien> yep. hvac works okay
08:24 < gour> yes, e.g. darcs
08:24 < koeien> it's mostly a dispatcher
08:25 < gour> many devs are coming to python due to django...
08:25 < koeien> i work with django myself
08:25 < koeien> i have mixed feelings about it
08:25 < koeien> i want static & strong typing
08:26 < koeien> but you can get something up & running very fast
08:27 < gour> i'm aware of haskell's strong points. will use it for desktop app
08:28 < koeien> but you can use a relational database with HAppS
08:29 < koeien> i am working on a sort of ORM for haskell, don't know if i finish it
08:29 < gour> that would be nice
08:29 < koeien> yes. it's quite a bit of work
08:29 < koeien> i would like to finish a prototype first, and then ask -cafe for some ideas and suggestions
08:30 < koeien> i don't know if it's a good idea :)
08:31 < koeien> turbinado has some other ideas
08:31 < koeien> i don't think HAppS is the best choice for shared hosting
08:33 < gour> yeah. it looks so
08:33  * koeien has a VPS though :)
08:35 < stepcut> A VPS is like $7
08:35  * gour would like to know more about it...lunch.bbs
08:35 < koeien> my vps is 100 euro / year (ex 19% VAT)
08:35 < stepcut> assuming your state is small
08:35 < koeien> 768 meg, 10GB
08:36 < stepcut> I have been using vplinks. $7 for 64MB RAM, $15 for 128MB RAM. Obviously not a lot of RAM. But not everyone has big datasets either
08:37 < stepcut> A minimal happs application only uses a few MB of RAM though
08:39 < koeien> hmm, it appears that darcs is hanging
08:39 < koeien> on the buildbot
08:40 < h_buildbot> Build for ghc-6.10.1 *failed*. See http://buildbot.happstack.com/ghc-6.10.1/
08:40 < koeien> sorry about that
08:42 < wchogg> Any idea what happened?
08:42 < koeien> darcs hanged for two hours
08:42 < koeien> 100% cpu
08:43 < wchogg> ...wow
08:43 < wchogg> that's impressive
08:43 < koeien> darcs 2.0.2
08:43 < koeien> i killed the process, so the build failed
08:44 < wchogg> What's weird is that I think I'm the about the only one who's been submitting in the past ~12 hours, so there shouldn't be any crazy conflicts.
08:44 < koeien> conflicts?
08:44 < koeien> i don't change that repos :/
08:45 < wchogg> I meant anything that could cause darcs to get into a weird state, like in darcs1.  I thought I remembered that there was some kind of edge case with the patch handling that caused it to go crazy.
08:46 < koeien> do you have any idea if that's fixed in 2.2
08:46 < wchogg> I'm essentially a darcs n00b, so I don't know if there are still open problems like that.
08:46 < koeien> i asked #darcs, no response so far
08:48 < koeien> you committed a patch at 12:45 CET?
08:48 < koeien> pushed*
08:52 < wchogg> Yes, that was probably me.
08:52 < koeien> ok
08:52 < koeien> i'll investigate. i switched the thing off for now
08:57 < Saizan> pulled fine here
08:57 < koeien> yes, pulled fine here as well
08:57 < koeien> when i retried..
09:02 < koeien> switching to 2.2 should solve the problem according to thorkilnaur on #darcs.
09:03 < stepcut> we should add a 'minimum system requires' to the documentation. Something like, "deloying happstack requires a VPS or dedicated system with a minimum of 64MB of RAM"
09:03 < koeien> that's entirely dependent on how much data the user wants to store
09:04 < stepcut> yes, but if your system does not meet those requirements, happstack is probably not going to work for you...
09:04 < koeien> the trivial 'hello world' program uses 2MB or something like that
09:04 < stepcut> koeien: right
09:05 < stepcut> koeien: I had a hello world program with a hit counter and it was under 4MB and ran for many months
09:07 < stepcut> I am not sure what the real minimum requirements are, but if we decide that it is 64MB, then we don't have to feel compelled to do anything when people complain that they can't run it on their VPS with only 32MB
09:08 < stepcut> related is the core value/principle that happstack should be able to scale really big in a linear fashion. happstack is more interested in solving the problem of handling 250 million visitors a month than running on a shared host.
09:08 < koeien> i don't know what a reasonable memory size is
09:09 < koeien> for a VPS
09:09 < stepcut> the smallest I have seen is 64MB for around $7/month
09:09 < stepcut> but I didn't look very hard
09:10 < koeien> that's very cheap
09:10 < stepcut> vpslink.com
09:10 < stepcut> I've had good luck so far, but I have not really done anything with any load
09:11 < stepcut> there is a  #vpslink on freenode which seems to have vpslink techs in it sometimes ;)
09:11 < koeien> my plan is better though :)
09:12 < stepcut> oh?
09:12 < koeien> 768 meg, 10GB for 119 euros /yr
09:13 < stepcut> cool
09:13 < stepcut> is that available to anyone?
09:14 < koeien> no, not really :)
09:14 < stepcut> :p
09:14 < koeien> i don't even need that much RAM
09:14 < koeien> it could come in handy though
09:30  * gour has 4EUR/m at djangohosting.ch
10:12 < koeien> darcs-2.2 is now available on the buildbots
10:14 < h_buildbot> Build for ghc-6.8.3 just succeeded. See http://buildbot.happstack.com/ghc-6.8.3/
10:17 < h_buildbot> Build for ghc-6.10.1 just succeeded. See http://buildbot.happstack.com/ghc-6.10.1/
10:17 < wchogg> Awesome, thanks!
10:26 < koeien> please let me know if any of you commits something and the buildbot doesn't wake up
10:26 < koeien> in that case i'll have to put a wrapper around darcs
10:35 < Saizan> i wonder what to do with HAppS.Server.UDP and HAppS.Server.HList
10:36  * stepcut didn't even know those existed
10:37 < koeien> HList does not sound like it's useful for the outside world
10:38 < Saizan> they aren't in the .cabal file
10:38 < Saizan> koeien: don't be afraid of type hackery! :)
10:39 < stepcut> :)
10:43 < h_buildbot> Build for ghc-6.8.3 just succeeded. See http://buildbot.happstack.com/ghc-6.8.3/
10:43 < koeien> Saizan: yeah, explain that to my mum :)
10:44 < koeien> she is terrified whenever I mention it
10:44 < koeien> :)
10:44 < wchogg> Well of course!  You only mention it by calling her at 3 am & whispering it in a creepy voice.
10:45 < wchogg> "type haaaAAaackery"
10:45 < koeien> lol
10:45 < wchogg> "Teh Oleg is calling from inside the house!"
10:45 < h_buildbot> Build for ghc-6.10.1 just succeeded. See http://buildbot.happstack.com/ghc-6.10.1/
12:03 < h_buildbot> Build for ghc-6.8.3 just succeeded. See http://buildbot.happstack.com/ghc-6.8.3/
12:11 < sm> nice
12:53 < h_buildbot> Build for ghc-6.8.3 just succeeded. See http://buildbot.happstack.com/ghc-6.8.3/
12:53 < sm> um.. too much :)
12:53 < wchogg> too much what?
12:54 < sm> too many routine build announcements, I'm thinking
12:54 < wchogg> I think it's useful to have it run when a patch is sent.
12:55 < h_buildbot> Build for ghc-6.10.1 just succeeded. See http://buildbot.happstack.com/ghc-6.10.1/
12:55 < sm> oh, is that what it is..
12:55 < sm> I think I'd rather see just: patch .... applied, when it works
12:57 < sm> is that hard to do ?
13:04 < stepcut> cabal is not working :(
13:05 < Saizan> uh?
13:05 < Saizan> what's the problem?
13:05 < stepcut> when I build the exectuable, it can't one of the modules that the library provides
13:06 < stepcut> not sure why
13:06 < wchogg> Which executable?
13:06 < stepcut> the new test suite
13:06 < Saizan> it can't see? uhm they are built into different directories, but the source-dirs can be shared
13:06 < stepcut> I'm going to poke a bit more
13:07  * stepcut ponders
13:07 < Saizan> did you forgot to set hs-source-dirs: src/,<the others> in the executable stanza?
13:08 < stepcut> when you have a cabal package which builds a library and a binary that uses that library, does it build the library twice? (once for the library, and a second time when it builds the executable that uses it)
13:08 < Saizan> yes.
13:09 < stepcut> I can import older modules by depending on HAppS-Util, but then I think my binary is built against the HAppS-Util installed on the system, not the version I just built
13:09 < stepcut> ok, I will use hs-source-dirs then
13:09 < stepcut> annoying that I have to build the library twice :(
13:10 < Saizan> that's why i think it might be better to test against the installed libraries
13:10 < Saizan> maybe using a local package.conf
13:11 < Saizan> but having runghc Setup test sure is nice
13:14 < stepcut> being able to run the tests against the installed libraries should be doable
13:14 < Saizan> though, when we're testing e.g. happstack-state we've built it against the installed happstack-data, happstack-util, so implicitly we already run the test against installed libraries
13:14 < stepcut> yes
13:15 < stepcut> though each module also has it's only local tests
13:15 < stepcut> s/only/own/
13:16 < stepcut> ok, things are shaping up here
13:16 < Saizan> that can be influenced by the behaviour of the dependencies
13:20 < stepcut> ok, in the tsets directory, make local, will test against the working directory, make installed, will test the installed libraries
13:20 < stepcut> (assuming you built them with, runhaskell Setup configure -f tests)
13:23 < Saizan> looks good enough, except for make, but i guess the rules are simple enough?
13:25 < Saizan> how does make local builds the modules? using ghc directly?
13:27 < stepcut> if you are at the top-level and do, runhaskell Setup test, it should build and run the test-suite using cabal (and that will test against the working directory).
13:28 < stepcut> alternatively, if you cd into the 'tests' directory you can run the test by doing, runhaskell Tests.hs
13:28 < stepcut> but, by default that would run the tests against the installed libraries, since the version in the working directory is not in scope
13:28 < stepcut> but, you could do, runhaskell -i../src Test.hs, and than would run the tests agaist the working directory
13:29 < stepcut> the Makefile just has a target for each of those options
13:29 < Saizan> i see
13:29 < stepcut> currently, if you want to test against the installed libraries, you need to do, runhaskell Setup.hs configure -f tests
13:30 < stepcut> because we don't normally include the tests in the installed libraries
13:31 < stepcut> but, if we want to have a top-level test suite that runs the intergration tests, plus all of the per-library tests, then it useful to have the libraries installed with the tests compiled in so that the master test suite can call them
13:31 < Saizan> and the tests are going to be all in one module, or?
13:32 < Saizan> however maybe i should just wait the patch and see :)
13:33 < stepcut> each library will provide it's own tests
13:33 < stepcut> for example, HAppS.Utils.Test
13:33 < stepcut> or, in a larger library you might split that up, HappS.Utils.Test.Common, HappS.Utils.Test.TH, etc
13:34 < stepcut> though, you would still have a HAppS.Utils.Test which would combine all the tests together and export them as 'allTests'
13:34 < Saizan> ok, that's what i was referring to
13:35 < stepcut> the top-level test suite can import HAppS.Utils.Test, HAppS.Data.Test, etc. and combine all tests, TestList [U.allTests, D.allTests, etc]
13:37 < stepcut> HUnit has reasonable support for a tree of unit tests
13:38 < stepcut> for example, if you can do, "master test suite" ~: [ U.allTests, D.allTests ], it creates hierarchical, breadcrumb label for the tests as it runs them
13:39 < stepcut> I also added the code to HAppS-Utils for wrapping up quickcheck's as hunit tests
13:40 < stepcut> I should also add a wrapper for running an external program which returns 0 or 1.
13:40 < stepcut> so we can call shell scripts (eewwwww)
13:40 < Saizan> ugh
13:41 < stepcut> I almost got all the code written, next I need to write the documentation so that people understand what is going on
13:41 < stepcut> though, it's not very complex at alll
13:42 < stepcut> the documentation is more to explain the design decisions
13:42 < h_buildbot> Build for ghc-6.8.3 just succeeded. See http://buildbot.happstack.com/ghc-6.8.3/
13:43 < stepcut> adding tests and using the tests should be obvious even if you don't read the docs
13:44 < stepcut> that's hopefully a sign that I did it right ;)
13:45 < stepcut> that fact that it is easy to run the tests against the install libraries or the  working directory is also a good sign
13:58 < stepcut> hrm, I am not going to hook up, runhaskell Setup test, quite yet. Too hard for too little gain.
14:00 < stepcut> maybe we can add 'dist' to the boring files in darcs?
14:26 < sm> oh, lots of changes in happstack repo.. nice
14:29 < stepcut> oops. I already had the latest patch to happstack in my old HAppS-Data repo, I didn't realize I never sent it upstream
14:29 < stepcut> :)
14:29 < stepcut> it's a great patch to have though
14:33 < stepcut> happstack-util now depends on quickcheck and hunit. That should be ok, right?
14:45 < sm> sounds good to me
14:47 < stepcut> ok, I pushed a patch that adds a testsuite to HAppS-Util
14:47 < stepcut> and I started a wiki page: http://code.google.com/p/happstack/wiki/UnitTestingFramework?ts=1233258435&updated=UnitTestingFramework
14:49 < stepcut> after some discussion, the next step is to copy and paste the stuff to the other modules, and the create a top-level test-suite which integrates them all
14:49 < stepcut> that last step is much easier then it sounds, btw
14:49 < sm> great
14:49 < stepcut> it just imports the tests and glues them together -- a few lines of code
14:49 < stepcut> also, I have not written the wrapper that calls external scripts yet
14:50 < h_buildbot> Build for ghc-6.8.3 *failed*. See http://buildbot.happstack.com/ghc-6.8.3/
14:50 < h_buildbot> Build for ghc-6.10.1 *failed*. See http://buildbot.happstack.com/ghc-6.10.1/
14:50 < stepcut> :(
14:50 < stepcut> I guess I broke it :)
14:51  * stepcut ponders what could be wrong
14:52 < stepcut> oh, just a missing file because darcs whatsnew -l has to much noise
14:57 < h_buildbot> Build for ghc-6.8.3 just succeeded. See http://buildbot.happstack.com/ghc-6.8.3/
14:59 < h_buildbot> Build for ghc-6.10.1 just succeeded. See http://buildbot.happstack.com/ghc-6.10.1/
15:07 < stepcut> yay!
15:07 < stepcut> in a few days h_buildbot will even run the test suite ;)
15:09 < stepcut> now I have to eat lunch and then fix cabal-debian so that it can figure out what packages a bundled with ghc6
15:11 < h_buildbot> Build for ghc-6.8.3 just succeeded. See http://buildbot.happstack.com/ghc-6.8.3/
15:15 < h_buildbot> Build for ghc-6.10.1 just succeeded. See http://buildbot.happstack.com/ghc-6.10.1/
17:15 < sm> go stepcut
17:20  * stepcut goes
18:26 < h_buildbot> Build for ghc-6.8.3 just succeeded. See http://buildbot.happstack.com/ghc-6.8.3/
18:31 < h_buildbot> Build for ghc-6.10.1 just succeeded. See http://buildbot.happstack.com/ghc-6.10.1/
18:39 < thsutton> I've started adding an export list and haddock comments to HApps.Util.Common and was wondering if I should bother with warnings/hlint suggestions while I'm at it?
18:47 < Saizan> warning surely, we've a ticket for them
18:48 < mae_work> thsutton: if you see an easy fix to a warning, go for it, but keep ignore the deprecated pragma ones (the ones that are left are for ghc 6.8.3 compat)
18:48 < thsutton> Cool.
18:48 < thsutton> How about adding dependancies to fix them?
18:49 < thsutton> hlint suggests Control.Arrow.first instead of HApps.Util.Common.doFst
18:49 < mae_work> dependencies?
18:49 < mae_work> ah
18:49 < mae_work> no, no major code changes
18:49 < mae_work> 0.1/0.2 are going to be happs compatible bugfix releases
18:49 < mae_work> well i know thats not major
18:50 < thsutton> Cool, I'll stick to adding exports lists, haddock comments, and type signatures then.
18:50 < mae_work> cool, thanks alot!
18:50 < mae_work> 0.3 will be a time when we can make more liberal changes
18:50 < Saizan> Control.Arrow is in base
18:51 < thsutton> I'll work slowly through happstack-util over the next few days.
18:53 < thsutton> Also it's suggesting that doFst and doSnd are just C.A.first C.A.second which is a good change to make, but I notice now that doFst and doSnd don't seem to be used anywhere...
18:54 < thsutton> Oops. Time to head to the office.
19:00 < mae_work> bbl
19:05 < stepcut> happstack-utils has one unit test now :)
19:06 < stepcut> split seems to be working ;)
19:08 < davidL> \o/
19:11 < thsutton> Not on OS X it doesn't.
19:11 < thsutton> The () need to be inside quotes for POSIX shells.
19:12 < thsutton> Otherwise `make` gives shell errors.
19:12 < stepcut> oh
19:13 < stepcut> I just use OS X to ssh into my ubuntu box :)
19:16  * sm does actual haskell development on os x.. useful for uncovering platform issues
19:17 < stepcut> i will someday.
19:17 < stepcut> anyway I pushed a patch to fix the quoting (I hope)
19:18 < stepcut> the fact that sh and make are such a nightmare is one of the reasons why I wanted to do this test framework in Haskell :)
19:18 < koeien> stepcut: could you explain how i can call it in the buildbot?
19:19 < stepcut> koeien: there are a variety of ways, do you actually install the libraries as part of the build process?
19:19 < koeien> i use Saizan's script, but i can do anything you like
19:20 < stepcut> the build-install-all ?
19:20 < thsutton> Works now
19:20 < koeien> yes
19:20 < thsutton> Yay!
19:21 < stepcut> koeien: in a few days I will likely have a similar script (or will modify that script) so that it also builds and installs the testsuite
19:22 < koeien> stepcut: how do i interpret the result? i want to distinguish between build errors and test failures
19:22 < stepcut> one moment
19:23 < stepcut> change, cd HAppS-Util       && cabal install "$@" && \, to, cd HAppS-Util       && cabal install -f flags "$@" && \
19:23 < stepcut> oops
19:23 < stepcut> -f tests
19:23 < stepcut> afterwards there should be a binary, happstack-util-tests
19:23 < stepcut> (in /usr/local/bin )
19:23 < koeien> i don't install as root
19:23 < stepcut> run that binary and it will run the tests. exit 0 == success! exit 1 == failure!
19:23 < koeien> so ~/.cabal/bin/ :)
19:24 < stepcut> ok
19:24 < koeien> cool. i'll see if i can integrate it, will probably be this weekend
19:24 < stepcut> eventually there well also be a master testsuite like, happstack-integration-test
19:24 < koeien> this is only for happstack-util ?
19:24 < stepcut> which will run all the individual library tests, plus any other tests
19:25 < stepcut> koeien: so far. I will be copying the model to each module, and also have a top-level test suite that runs them all
19:25 < stepcut> but I wanted to get some feedback on what I did in happstack-utils before I hope it to all the other modules
19:26 < h_buildbot> Build for ghc-6.8.3 just succeeded. See http://buildbot.happstack.com/ghc-6.8.3/
19:31 < h_buildbot> Build for ghc-6.10.1 just succeeded. See http://buildbot.happstack.com/ghc-6.10.1/
19:35 < thsutton> Does anyone have suggestions about haddock comment style? Should they include code snippets demonstrating functions like Data.List?
19:36 < stepcut> thsutton: yes, and big O notation like Data.Map
19:36 < stepcut> :)
19:37 < stepcut> well, maybe only for the places that big O is sensible
19:37 < thsutton> Most of H.U.Common seems to have been written to avoid anon functions.
19:37 < thsutton> :-)
19:37 < Saizan> do we have anything related to that?:)
19:38 < thsutton> Most of them are O(1) or O(n).
19:38  * stepcut wonders what the big O for simpleHTTP is
19:38 < stepcut> or waitForTermination?
19:39 < Saizan> O(User)
19:39  * stepcut does not really know how to calculate big O
19:39 < thsutton> O(?)?
19:39 < thsutton> O(_|_)?
19:39 < stepcut> somehow I got a degree in computer engineering and never had a single minute of instruction on big O
19:39 < koeien> O(oo) :)
19:40 < sm> that was the minute you were out drinking beer :)
19:40 < stepcut> stupid mail-order degree
19:41 < koeien> stepcut: it's very easy. for a function f, O(f) = { g : exists n, forall m > n, g(m) <= f(m) } :)
19:41 < Saizan> there's a k there, i think
19:41 < Saizan> g(m) <= k*f(m)
19:42 < koeien> yep.
19:42 < koeien> exists k ...
19:42 < koeien> so much for "very easy" :)
19:43 < Saizan> "grows slower than" :)
19:44 < koeien> well, or "as fast as"
19:44 < thsutton> Or "not faster than"
19:45 < koeien> the notation is abused of course, so O(n^2) really means O( \n -> n^2 )
19:45 < Saizan> not "as fast as" since "n" is O(n^2)
19:46 < koeien> Saizan: no, i meant "grows slower than or as fast as"
19:46 < koeien> n^2 is O(n^2)
19:46 < Saizan> ah, right
19:47 < koeien> in mathematics, it's even more ambiguous as always as to what O(..) means
19:48 < Saizan> i've never used it in contexts unrelated to complexity
19:48 < koeien> it's widely used in calculating limits
19:48 < koeien> very convenient'
19:49 < Saizan> i've used small-o for that
19:49 < koeien> yes. that is also used
19:49 < koeien> but that's ambiguous :) in this case small-o means, "vanishes faster than..."
19:50  * stepcut things OO programmers must get paid by the character
19:50 < thsutton> :-)
19:51 < stepcut> data NoteEvent = NoteEvent { start :: EventTime, duration :: EventTime, note : Note, velocity : Float } is around 25 lines of actionscript 3.0
19:54 < stepcut> and every class has to go in a separate file
20:00 < stepcut> and this 'new' keyword is lame too
22:00 < stepcut> stepbot1: hello
22:00 < stepbot1>  hello stepcut. We have now talked 4 times.
22:09 < mae> Saizan: regarding the whole missing instance thing / Igloo. Can you go ahead and submit the instances to the happstack codebase so it is in for the 0.1 release/
22:09 < mae> i think fixing upstream might take a bit longer
22:11 < stepcut> mae: I commited some unit testing framework to happstack-util
22:12 < stepcut> mae: if we like it I will add the rest, which is basically more of the same
22:12 < stepcut> mae: also there is some documentation in the wiki, which I will improve if we like this system
22:14 < stepcut> so far there is one unit test. the 'split' function in HAppS.Util.Common seems to work
23:03 < gwern> split?
23:03 < gwern> as in Data.List.Split?
23:03 < mae> stepcut: ok thanks :)
23:05 < stepcut> gwern: if there were a Data.List.split...
23:08  * gwern pities stepcut. perhaps in your day there was none, but we have Hackage now
23:16 < gwern> 'We're lucky we didn't end up with something cute like "Mr.
23:16 < gwern> Happstack"... thank-you, Mr. Handsome'
23:18 < gwern> stepcut: in case my gnomic utterances make no sense, I was suggesting scrapping the util function and instead relying on byorgey's 'split' package'
23:22 < stepcut> the first step might be to determine if it is even used
--- Log closed Fri Jan 30 00:00:12 2009