--- Log opened Mon Feb 02 00:00:18 2009
--- Log closed Mon Feb 02 00:53:30 2009
--- Log opened Mon Feb 02 00:53:30 2009
--- Log closed Mon Feb 02 00:53:30 2009
--- Log opened Mon Feb 02 01:09:39 2009
--- Log closed Mon Feb 02 01:10:24 2009
--- Log opened Mon Feb 02 01:10:24 2009
--- Log closed Mon Feb 02 01:10:24 2009
--- Log opened Mon Feb 02 01:11:37 2009
01:24 < mae_> night yall.
03:09 < barkmadly> hey hey everybody
03:35 < mae_> hey hey :)
03:36 < koeien> hello
03:38 < mae_> koeien: build bot doesn't seem to be showing latest builds :\\
03:39 < koeien> that's what i get for using a database
03:45 < mae_> koeien: you need to add 'cabal update' to the script
03:45 < mae_> (to check for new hackage packageS)
03:45 < mae_> and then rerun it
03:46 < koeien> yes building now
03:46 < mae_> k
03:46 < mae_> i've been brushing up on my template haskell :)
03:46 < mae_> so i can fix those naughty warnings
03:47 < koeien> ``internal name''?
03:47 < mae_> yep
03:47 < mae_> for 0.2 I want to get multimaster support to be really ++ awesome
03:47 < mae_> its already in but it needs some testing and documentation
03:48 < h_buildbot> Build for ghc-6.8.3 OK. Test suite ran, all tests passed! Check http://buildbot.happstack.com/ for details.
03:53 < paulvisschers> I want to check out the happs.state stuff a little later on
03:53 < paulvisschers> I like the ideas behind it, but it seems like it could be more elegant
03:54 < h_buildbot> Build for ghc-6.10.1 OK. Test suite ran, all tests passed! Check http://buildbot.happstack.com/ for details.
03:56 < barkmadly> is there some way to build happstack without having to install things?
03:58 < barkmadly> i mean say for instance i want to build happs-data, without having to install happs-util but with having to build happs-util?
04:01 < barkmadly> or would it be easier if i just installed it?
04:01 < koeien> it's far easier if you install
04:02 < barkmadly> so that makes the development cycle go: code -> test -> uninstall -> reinstall?
04:16 < mae_> koeien: data on web page doesn't seem up to date
04:17 < koeien> mae_: yes. odbc is foobar appearantly
04:17 < mae_> : (
04:17 < mae_> mutable state is the devil
04:17 < koeien> the data is inserted into the database
04:31 < koeien> meh, and hdbc-mysql doesn't work correctly so i have to use mysql
04:31 < koeien> ehm, s/ mysql/ odbc/
06:39 < koeien> the page http://buildbot.happstack.com/ should now be updated automagically
06:47 < h_buildbot> Build for ghc-6.8.3 OK. Test suite ran, all tests passed! Check http://buildbot.happstack.com/ for details.
06:51 < h_buildbot> Build for ghc-6.10.1 OK. Test suite build failed. Check http://buildbot.happstack.com/ for details.
07:04 < koeien> now all test cases should run
07:09 < h_buildbot> Build for ghc-6.8.3 OK. Test suite build failed. Check http://buildbot.happstack.com/ for details.
07:14 < h_buildbot> Build for ghc-6.10.1 OK. Test suite ran. 15/45 test cases failed. Check http://buildbot.happstack.com/ for details.
07:36 < Saizan> "Test suite build failed." refers to building happstack-tests?
09:00 < Saizan> do we want to keep 0.1 as a separate branch while working on 0.2?
09:15 < stepcut> Saizan: yes, I just fixed that. It was the -fno-warn-deprecated-flags issue again :)
09:17 < Saizan> are we compiling with -Werror?
09:18 < stepcut> not that I know of
09:21 < h_buildbot> Build for ghc-6.8.3 OK. Test suite ran. 15/45 test cases failed. Check http://buildbot.happstack.com/ for details.
09:26 < h_buildbot> Build for ghc-6.10.1 OK. Test suite ran. 15/45 test cases failed. Check http://buildbot.happstack.com/ for details.
10:23 < koeien> stepcut: 15/45 failures is as expected?
12:26 < mae_> koeien: yes, no worries.
12:27 < koeien> mae_: shiny new stuff on http://buildbot.happstack.com/ now
12:30 < mae_> koeien: great :)
12:44 < koeien> mae_: it may be useful to link to the buildbot on http://happstack.com/develop.html
12:44 < koeien> and/or "Resources"
13:27 < koeien> so, what's holding the 0.1 release up? ;)
13:28 < hydo> Just one outstanding bug at the moment...
13:28 < hydo> "Unit test framework..."
13:28 < hydo> According to the bug tracker, anyway...
13:29 < koeien> yeah. i don't know whether stepcut considers it finished (at least for 0.1)
13:58 < stepcut> I am almost done, I just need to copy the unit test frame work to ixset, state, server, and contrib
13:58 < stepcut> but that should be easy..
14:10 < koeien> nice
14:11 < stepcut> well, there is also the issue that cabal does not have enough power to make it easy to distribute the test suite
14:11 < stepcut> hrm, that is not the best way to describe the problem
14:12 < stepcut> cabal does not provide a satisfying mechanism for allowing optional inclusion of the test suite during compilation.
14:12 < koeien> what's wrong with   if flag(testing) ?
14:13 < stepcut> the primary problem with that solution is that happstack-tests requires all the other packages to be built with the 'tests' flag enabled, but there is no way to specify that in the happstack-tests.cabal file.
14:13 < Saizan> that you can't depend on particular values of the flags for the packages you use
14:13 < stepcut> instead you just get a mysterious error about missing modules
14:14 < koeien> hmm. i take it it's not possible to conditionally name the module?
14:14 < Saizan> maybe we should have distinct packages for the tests, living in the same directory?
14:14 < stepcut> if a single .cabal package could provide multiple libraries, then each module could export happstack-<module> and optionally happstack-<module>-tests
14:15 < Saizan> yeah, why not use two .cabal files?
14:15 < koeien> you could let the testing cabal file depend on the "real" one
14:15 < Saizan> there's some maintaing overhead, sure
14:15 < stepcut> I think it would be nice if when you ran, runhaskell Setup.hs sdist, you got a single tarball that contained the source + tests.... which I think could be done with a bit cleverness
14:16 < Saizan> uhm
14:16 < Saizan> btw, why do we want to distribute the tests?
14:17 < stepcut> with that solution you would build the library, and then cd into the tests directory and build a the second package which contained tests for that library?
14:17 < Saizan> so that users can give reports too?
14:17 < stepcut> yes
14:17 < koeien> Saizan: it can be useful for starting hackers. also it could serve as examples and/or documentation
14:17 < stepcut> maybe the tests fail on AMD64 or something we don't normally test on
14:18  * koeien 's desktop is amd64
14:18 < stepcut> Saizan: also, users might just want to run the testsuite as part of testing their own library
14:18 < stepcut> or application
14:18 < Saizan> for the latter we can't avoid a separate library i think
14:19 < stepcut> Saizan: what do you mean?
14:19 < Saizan> if they are supposed to import those modules from their own code, they must be able to depend on them
14:19 < stepcut> yes
14:19 < Saizan> so we can't conditionally expose them or not
14:20 < stepcut> only because cabal sucks ;)
14:20 < stepcut> we could always expose them...
14:20 < koeien> do the test-libraries have to be in the same package?
14:20 < stepcut> koeien: depends what you mean by 'package'
14:21 < koeien> cabal package
14:21 < Saizan> they might, if they use non-exposed modules
14:21 < koeien> as a 'glass box' test
14:21 < koeien> hmmm. what we could also do, is compile with tests by default.
14:21 < stepcut> koeien: I would like them to be in the tarball for happstack-<module> that gets upload to hackage
14:21 < koeien> users that want to exclude them can do -fwithout-tests
14:22 < koeien> (if they are tight on resources)
14:22 < stepcut> koeien: from a technical standpoint, that is trivial to do
14:22 < Saizan> we could ask on cabal-devel@ if depending of flags is forbidden by design or it's a shortcoming of the current implementation
14:23 < stepcut> the limitation of one-library per .cabal is a bit annoying as well
14:23 < koeien> Saizan: what do we win by doing that?
14:23 < koeien> i.e. it's nice as a suggestion, but won't help the problem
14:24 < Saizan> it's exactly what we need, no?
14:24 < koeien> right, but that won't make it immediately into a release
14:25 < Saizan> well any of the other workarounds are feasible for this release
14:25 < Saizan> even just compiling tests by default would do
14:25 < koeien> also, it would create a dependency on $CABAL_SHINEY_RELEASE
14:25 < Saizan> so what?
14:25 < stepcut> I, personally, have no problem enabling the tests by default
14:25 < koeien> Saizan: that's why i suggested enabling them by default
14:26 < stepcut> I think the #1 priority would be that, cabal-install happstack-tests, should automatically work on a clean system with no user intervention?
14:26 < Saizan> btw, we already depend on Cabal >= 1.6 because of my syb-with-class.cabal
14:26 < Saizan> stepcut: right.
14:26 < koeien> Saizan: ? the buildbot for ghc-6.8.3 does not have it
14:27 < koeien> only -1.2.4
14:27 < stepcut> the easiest way to do that is to switch the polarity so that tests are enabled by default
14:27 < stepcut> and, if no one complains about that, then we can just consider the problem solved and worry about more important stuff :p
14:28 < Saizan> koeien: your cabal-install is compiled against it
14:28 < koeien> that must be indeed. it doesn't show up in ghc-pkg list though
14:29 < Saizan> that's not relevant
14:29 < Saizan> cabal --version
14:29 < koeien> yeah, you're right. my misunderstanding about the ghc-pkg list functionality shines through
14:30 < Saizan> well, the point is that cabal-install doesn't look at the Cabal library installed if built-type: Simple
14:31 < Saizan> stepcut: i think that's the way to go :)
14:31 < koeien> this does mean that we have to invert the build scripts
14:31 < Saizan> invert?
14:32 < koeien> i.e. build-install needs to have the flag, and build-test does not
14:32 < stepcut> Saizan: ok, I'll do it in a bit
14:33 < Saizan> ah, yeah
14:34 < Saizan> to be picky -test can remain like that, while we need -f -tests in the other if we want
14:35 < koeien> it's nicer if we remove it there in -test
14:35 < Saizan> well, yeah, it's a no-op anyway
14:36 < stepcut> ok, I updated the .cabal files, should I add -f -tests to build-install-all.sh ?
14:36 < Saizan> i'm not sure
14:36 < stepcut> I'll leave it alone for now
14:36 < koeien> i can do this manually
14:37 < Saizan> if you're building from the darcs repo you probably want the tests by default
14:37 < koeien> since there was a "$@" in the script for each cabal command
14:37 < stepcut> Saizan: agreed
14:37 < Saizan> yeah
14:38 < koeien> so, then build-install-all.sh does build & install. i pass it -f -tests in my script.  build-install-test.sh  is going to build with tests and install the testsuite. but then this last file seems pretty redundant
14:38 < Saizan> we could setup a specific hackagedb to distribute the release candidates before actually uploading to hackage.haskell.org
14:39 < koeien> nice idea. i could host this if you want, but i need some instruction on how to set it up
14:39 < Saizan> we can use the hackage-server written in happs
14:40 < stepcut> where is syb-with-class 0.5 hosted now ?
14:40 < Saizan> on hackage, and on patch-tag
14:41 < stepcut> ok
14:41  * stepcut notes that he does not have (nor really want) private access to syb-with-class
14:42 < stepcut> the images on patch-tag are not loading for me :(
14:49 < koeien> stepcut: also, no CSS
14:51 < stepcut> no CSS???
14:51 < stepcut> I don't even know what that means
14:51 < koeien> cascading style sheets
14:51 < stepcut> oh!
14:52 < stepcut> I thought we where still talking about tests, I forgot all my image problem ;)
14:52 < stepcut> and cascading style sheets was the only thing I could think for for CSS, which did not make sense in the context of testings
14:54 < stepcut> crap
14:54 < stepcut> I just pushed a patch I didn't mean to :)
14:55 < stepcut> HAppS-Util now has a debian directory... that's good right? right ???? everyone likes debian, yes?
14:55 < koeien> yeeeeehaw debian
14:56 < stepcut> I can do a rollback and push another patch, unless people actually want a debian directory there
14:56 < koeien> you could oblit it, bit risky
14:56 < stepcut> does oblit work remotely?
14:56 < stepcut> I figure the buildbot already has it by now
14:56 < koeien> yes it's probably processing
14:57 < stepcut> I'll do the morally right thing :)
14:58 < stepcut> ok, I rolled it back
15:00 < stepcut> my shame will live on in RCS history forever though
15:00 < stepcut> anyway, tests are now 'on' by default
15:00 < stepcut> i guess I do the rest of the modules since I am working on this stuff now
15:00 < stepcut> and, since I am apparently holding up the release ;)
15:01 < koeien> okay. i'll switch them off in the script
15:01 < h_buildbot> Build for ghc-6.8.3 OK. Test suite ran. 15/45 test cases failed. Check http://buildbot.happstack.com/ for details.
15:07 < h_buildbot> Build for ghc-6.10.1 OK. Test suite ran. 15/45 test cases failed. Check http://buildbot.happstack.com/ for details.
15:07 < stepcut> so, who wants to fix those bugs so the tests pass ;)
15:11 < koeien> stepcut: is that a priority atm?
15:13 < stepcut> no idea
15:14 < Saizan> it'd be weird to release a failing happstack-tests
15:15 < koeien> i'd rather let the world know it's wrong than not release it? i have no idea about the nature of the failing test cases
15:16 < Saizan> we need to explain what those failing tests are then, since it seems you can still use happs
15:16 < h_buildbot> Build for ghc-6.8.3 OK. Test suite ran. 15/45 test cases failed. Check http://buildbot.happstack.com/ for details.
15:17 < stepcut> I think all the tests fail due to the same issue
15:18 < koeien> except for 1 i think
15:18 < koeien> if you look at the logs the message is different
15:20 < stepcut> oh true
15:23 < Saizan> i'm not even sure what happstack-data should do..
15:25 < Saizan> the point of it was to easily [de]serialize haskell types from/to various formats like urls or xml
15:25 < Saizan> being somewhat permissive
15:28 < koeien> would be nice to have such functionality. if somebody wants to import or export data from the application
15:30 < stepcut> Saizan: it has some generic functions too like gFind, gSet, etc
15:32 < sm> morning
15:32 < koeien> 'night
15:46 < koeien> the buildbot now calls the first build with -f-tests, and the second one without. in both cases the script build-install-all.sh is used
15:51 < stepcut> col
15:51 < stepcut> koeien: cool
15:52 < koeien> stepcut: happstack-tests is not being compiled in the script
15:52 < h_buildbot> Build for ghc-6.8.3 OK. Test suite ran. 15/45 test cases failed. Check http://buildbot.happstack.com/ for details.
15:52 < stepcut> koeien: it is currently only built in the build-install-test-all.sh script
15:52 < koeien> is this by design?
15:53 < stepcut> koeien: before today's change it was, now it is just that way because we haven't decided on what 'by design' should be
15:56 < koeien> ok, i reverted to build-install-test-all.sh for the time being
15:56 < stepcut> ok
15:56 < stepcut> the cool thing now is that when I start adding tests to HAppS-IxSet, they should automatically show up in the buildbot
15:56 < koeien> indeed
15:57 < stepcut> because they get linked into the master test program
15:57 < koeien> yeah, i made some counting stuff but that wasn't necessary because of your test overlord program
15:58 < stepcut> :)
15:58 < stepcut> why do some many happs files start with a blank line?
15:58 < stepcut> s/some/so/
16:02 < h_buildbot> Build for ghc-6.8.3 OK. Test suite ran. 15/45 test cases failed. Check http://buildbot.happstack.com/ for details.
16:06 < h_buildbot> Build for ghc-6.10.1 OK. Test suite ran. 15/45 test cases failed. Check http://buildbot.happstack.com/ for details.
16:10 < koeien> i fail to see why HAppS-Data/tests/HAppS/Data/Tests can compile. in the function flexibleManualTests, mkFTest is called, the second argument should be of type (Eq a, Xml a) => a. I don't see the instance of MkMyList YesNo . Could somebody shed some light on this?
16:10 < stepcut> koeien: let me check
16:11 < koeien> i mean file Xml001.hs
16:12 < stepcut> which instance are you not seeing?
16:13 < Saizan> remember that there's an Xml a instance for every Data ctx a
16:13 < stepcut> instance [overlap ok] (Data XmlD t, Default t, Normalize t) => Xml t
16:13 < koeien> ah, i didn't grep low enough
16:14 < stepcut> :info Xml
16:14 < paulvisschers> I'm wondering what data structures you guys are using with happs.state
16:14 < koeien> yeah, :info MkMyList didn't show it
16:14 < stepcut> paulvisschers: Haskell ones...
16:15 < paulvisschers> stepcut: right :)
16:15 < stepcut> paulvisschers: I write whatever types I need for my application, and if I want to save data of that type persistently, then I add the instances needed for happs-state
16:16 < paulvisschers> I meant more that I'm using a bunch of Data.Maps right now with various types in them
16:16 < paulvisschers> each one a component
16:16 < paulvisschers> and they refer to eachother through a Reference datatype
16:16 < stepcut> paulvisschers: you might consider IxSet if you need maps with multiple keys
16:16 < paulvisschers> which is something like data Ref a = Int
16:17 < paulvisschers> stepcut: Is there some documentation on that yet?
16:18 < stepcut> paulvisschers: probably not, I think there are a few examples in the source code...
16:18 < paulvisschers> hmm
16:19 < stepcut> paulvisschers: The structure you are using could be right for your application and seems orthogonal to using Data.Map vs Data.IxSet
16:19 < stepcut> paulvisschers: but, if it doesn't seem right to you, then it might not be
16:19 < paulvisschers> Yeah I guess
16:19 < stepcut> paulvisschers: if you are trying to emulate SQL tables using happs-state, you might be doing it wrong
16:19 < paulvisschers> It's not really the Map that I don't like, but more the references
16:19 < stepcut> unless your data happens to very 'relational' in nature
16:20 < stepcut> I do have references in my code, but it tends to be more specifically typed. Such as, newtype UserId = UserId Integer
16:21 < paulvisschers> I want to use polymorphic functions there as much as possible
16:22 < paulvisschers> so following a reference works based on the type of reference your using
16:22 < stepcut> ok
16:23 < stepcut> I don't really have enough context to understand what you are trying to achieve in the bigger picture
16:23 < paulvisschers> Neither do I :)
16:23 < stepcut> :)
16:24 < paulvisschers> I want to make a Wiki-type site but with various types in it
16:24 < paulvisschers> the site itself will have types like games, developers, genres, users, platforms etc
16:24 < stepcut> ok
16:25 < paulvisschers> and all should have a wiki-like editing page
16:26 < paulvisschers> I would ideally only need to provide stuff like the datatype, and some instances of classes that provide how to render a page, what html form to use etc
16:26 < paulvisschers> that all sort of works
16:26 < paulvisschers> or will eventually
16:26 < stepcut> so all the categories would be predetermined at compile time?
16:26 < paulvisschers> yes
16:27 < paulvisschers> because I need to determine how to the pages showing these look
16:27 < stepcut> yes
16:28 < stepcut> so each page has some sort of key that you can use to find it, and that is what you are calling a Ref ?
16:28 < paulvisschers> yes
16:29 < stepcut> and a page can refer to other pages ?
16:29 < paulvisschers> yes
16:29 < paulvisschers> even sets or lists of them
16:29 < stepcut> other pages in other categories?
16:29 < paulvisschers> yes
16:30 < paulvisschers> for example a game will refer to its developer
16:30 < paulvisschers> and a set of its genres
16:30 < stepcut> so Page as a type like, data Page = Page [PageElement] ; data PageElement = Text String | Link Ref
16:30 < stepcut> effectively
16:31 < stepcut> type Ref = Int
16:31 < stepcut> (well, type Ref = <some sort of key>)
16:31 < koeien> it's a phantom type
16:31 < koeien> data Ref a = Int
16:31 < paulvisschers> I actually use a new record type for each page
16:32 < stepcut> but, these, Ref a, appear in the Page record somewhere?
16:32 < paulvisschers> so something like data Game = Game {name :: String, description :: String, developer :: Ref Developer}
16:32 < stepcut> so the references for a page fixed? You can't just stick them in at random?
16:32 < paulvisschers> yes like in the game datatype I just described
16:33 < paulvisschers> right
16:33 < paulvisschers> I choose what you can refer to in advance
16:33 < stepcut> ok
16:34 < paulvisschers> data Game = Game {name :: String, description :: String, developer :: Ref Developer, genres :: Set (Ref Genre)}
16:34 < paulvisschers> you can have multiple types of references though
16:34 < stepcut> right
16:34 < stepcut> so, what is the issue?
16:34 < paulvisschers> well there isn't really an issue with this part so much
16:35 < stepcut> sweet!
16:35 < paulvisschers> except perhaps that I also want to have pages that contain a list of games for example, and then filter and/or sort them in various ways
16:35 < paulvisschers> although even that isn't such a problem
16:36 < paulvisschers> I just wanted to know if there was a better way
16:36 < stepcut> for that specific issue, the IxSet might help a bit
16:37 < paulvisschers> I do have a slight problem though, but it's not really regarding datatypes
16:37 < paulvisschers> Ok I will look into it then, although I'm going to make a simpler site first, to get some experience with happs
16:37 < stepcut> it has some operators for doing queries like, (games @= someDeveloper), would select all the games written by someDeveloper
16:38 < paulvisschers> ok could be useful
16:38 < paulvisschers> That other problem involves type classes
16:38 < stepcut> ok
16:39 < paulvisschers> I want people to be able to vote for a game
16:39 < paulvisschers> and add discussions to it
16:39 < paulvisschers> they should also be able to add discussions to developers, but not vote for those
16:40 < stepcut> ok
16:40 < paulvisschers> so I made some type classes that would require you to implement getters and setters on your datatype for a type like Score or Topics
16:41 < paulvisschers> and I would then have a bunch of polymorphic functions that implement all the plumbing
16:42 < stepcut> ok
16:42 < paulvisschers> however the problem seems that you can't use mkMethods on those functions unless every page type implements the instance
16:42 < stepcut> could be, mkMethods has some restrictions regarding polymorphism.
16:43 < koeien> re test failures: the instance for MyList is wrong
16:43 < stepcut> koeien: one moment
16:43 < koeien> no problem, i'm bug hunting atm ;) just mentioning progress
16:44 < koeien> the instance for YesNo seems ok
16:44 < stepcut> paulvisschers: even if mkMethods worked, I don't think I would implement it that way. I would problem have a general purpose component for Score, that could refer to any Ref?
16:45 < stepcut> koeien: do you mean the test itself is broken? Or the test is fine, but it is detecting a bug in the MyList instance?
16:45 < paulvisschers> stepcut: Could you elaborate a little?
16:45 < koeien> stepcut: the latter
16:45 < stepcut> koeien: so the test found a valid bug?
16:45 < koeien> stepcut: at least, if i read the intentions of the code correctly ;)
16:45 < koeien> stepcut: yeah
16:45 < stepcut> koeien: sweet!
16:45 < koeien> stepcut: imo
16:45 < koeien> all this under the assumption that i'm not an idiot
16:45 < paulvisschers> stepcut: I was actually just about to ask you if you had a different idea for implementing optional functionality
16:46 < koeien> which is not really likely ;)
16:47 < koeien> stepcut: hmm
16:47 < stepcut> paulvisschers: I would have something like, type Score = Integer, type ScoreBoard = Map Ref Score, and some methods like, voteUp :: Ref -> State ScoreBoard (), voteDown :: Ref -> State ScoreBoard ()
16:47 < stepcut> paulvisschers: I am really fudging the types there, but does that make sense?
16:48 < stepcut> koeien: it's really hard to understand the intentions of that code, I figured if it was not obvious, we could try to ask Lemmih/Alex what they think
16:48 < paulvisschers> stepcut: A little, but I think it would help if you didn't fudge the types
16:48 < stepcut> paulvisschers: :)
16:50 < koeien> stepcut: ah i got it. it's a bug in the test case :>
16:50 < stepcut> paulvisschers: it sounded to me like you wanted to store in the 'Score' for a game in the Game datatype itself? Where-as I would probably have a completely separate module/data type/component/etc, that allowed me to track scores for things.
16:50 < stepcut> koeien: :( That is unfortunate... because we need to be able to explain why it used to be the right anwser but now is not?
16:51 < paulvisschers> stepcut: I get that part, but I'm not sure how you will connect a score to the right item (since these can have different types from eachother)
16:53 < koeien> stepcut: The testcase is about reading "a list of stuff" in xml. if the datatype is "data L a = L [a]", then the XML tree will have to look like   Elem "L" [Elem "42", Elem "37"]   for a list like numbers
16:53 < stepcut> paulvisschers: I assume you are talking about the problem that the type of the reference is, Ref a, not Ref ?
16:53 < koeien> stepcut: the test case was trying [ Elem "42", Elem "37" ]. This is not sufficient
16:53 < paulvisschers> stepcut: indeed
16:55 < Saizan> koeien: that might fall in the "permissive enough" category
16:55 < koeien> Saizan: ok. at least we know why it's failing right now
16:55 < stepcut> paulvisschers: I have done something similar with user accounts though I can't seem to find the example of using it offhand
16:56 < stepcut> paulvisschers: check out this tutorial, http://src.seereason.com/examples/happs-logon-example/
16:56 < koeien> Saizan: indeed. this change fixes a few of the errors (i know have only 1+8=9 errorenous test cases)
16:56 < stepcut> paulvisschers: which depends on this library: http://src.seereason.com/ghc610/HAppS-Extra/
16:56 < koeien> Saizan, stepcut: whether this was an error of the test case, or of the code, I do not know.
16:57 < stepcut> paulvisschers: I have a type, data Accounts a ..., that interoperations with polymorphic functions and mkMethods
16:59 < stepcut> koeien: hold on while I find a message on the mailing list
17:01 < stepcut> koeien: > toXml (Just [1,2 :: Int])
17:01 < stepcut> [CData "1,2"]
17:02 < koeien> what are you trying to say?
17:03 < stepcut> it seems like toXml erases the Just, so maybe the Xml tree for, data L a = L [a], shouldn't have the L after all?
17:03 < paulvisschers> stepcut: I'll check that out, thanks
17:03 < paulvisschers> stepcut: Not now though, it's getting late
17:03 < stepcut> paulvisschers: :)
17:04 < koeien> stepcut: that would be very strange. How is it going to distinguish between Nothing and Just [] then ?
17:04 < stepcut> koeien: I assume the test case worked when they first wrote it. So I am wondering why it is broken now...
17:04 < koeien> can be find the first revision of that test case?
17:04 < koeien> s/be /we /
17:04 < stepcut> koeien: in the old tree using annotate probably
17:05 < koeien> happs.org tree, i take it?
17:06 < stepcut> yeah
17:06 < stepcut> koeien: well, given the nature of some of the failed tests that are now occuring, it may be that in the old code you couldn't distinguisd between Just [] and Nothing, but they fixed that and now the tests fail?
17:07 < koeien> only speculating
17:07 < koeien> but you may be right
17:07 < koeien> igloo was the author of the patch
17:10 < stepcut> so, my assumption is that the test was valid when it was written, and so we shouldn't change the test until we can explain why it started failing and why changing the test is the right fix
17:11 < koeien> agreed
17:16 < koeien> tracking down the situation at that time is a bit difficult, it didn't build on 6.10.1 at that time
17:17 < stepcut> ugh
17:17 < stepcut> how patches are there against happs-ixset since then?
17:17 < stepcut> maybe there is one with a telling title
17:18 < koeien> Fri Feb  1 21:51:33 CET 2008\
17:19 < koeien> well, you can't fault them for not building on 6.8.3 at that time ;)
17:19 < koeien> ehm, 6.10.1
17:20 < stepcut> lame
17:20 < stepcut> if it was H98 it would build ;)
17:20 < koeien> if it was H98 it wasn't as magica^W functional as it is now :)
17:20 < stepcut> :)
17:22 < koeien> anyways, what is the probability of a reasonably speedy reply of old maintainers who can tell us what the problem is?
17:22 < koeien> rather, what the resolution should be?
17:22 < koeien> i can open up a ticket and post the patch there
17:24 < stepcut> dunno, but it seems like it is not a lot of work to try?
17:24 < koeien> sure
17:31 < h_buildbot> Build for ghc-6.8.3 OK. Test suite ran. 15/46 test cases failed. Check http://buildbot.happstack.com/ for details.
17:33 < stepcut> 46!
17:33 < koeien> +1 test case?
17:33 < koeien> nice
17:33 < koeien> as expected?
17:34 < stepcut> but also +1 a  whole module, happstack-ixset
17:34 < koeien> it runs automagically ^^
17:34 < stepcut> yep
17:35 < stepcut> happstate-state has QuickCheck properties! nice!
17:36 < h_buildbot> Build for ghc-6.10.1 OK. Test suite ran. 15/46 test cases failed. Check http://buildbot.happstack.com/ for details.
17:37 < stepcut>     Could not find module `HAppS.State.Saver.Impl.Memory':
17:37 < stepcut> :(
17:39 < stepcut> oh, it works with ./runTests.sh
17:43 < stepcut> the happstack-state tests test some functionality in modules that are not exposed
17:44 < Saizan> that shouldn't be a problem if we build the tests as part of the library, no?
17:44 < stepcut> Saizan: exactly!
17:45 < stepcut> Saizan: means I did it right ;)
17:45 < Saizan> heh :)
17:47 < stepcut> happstack has 88 patches
17:47 < stepcut> though 3 of those are my bogus debian directory
17:48 < koeien> i summarized my findings in a post to the mailing list
17:48 < stepcut> sweet!
18:11 < mae_work> hi all
18:11 < mae_work> did we figure out the tests?
18:13 < stepcut> mae_work: which part?
18:14 < koeien> mae_work: i sent an e-mail to the mailing lists
18:14 < koeien> s/lists/list
18:14 < mae_work> yeah i saw it
18:14 < mae_work> was just wondering
18:14 < mae_work> tests are in by default right?
18:14 < mae_work> i think the failing cases are fine
18:14 < mae_work> most people won't use the tests anyways
18:14 < mae_work> (at least not yet)
18:15 < koeien> tests are in by default now, yes
18:15 < mae_work> kk
18:15 < koeien> you can switch them of by using -f-tests
18:15 < mae_work> and what of this debianization?
18:15 < koeien> stepcut: ^
18:15 < stepcut> mae_work: was an accident
18:15 < mae_work> ah
18:15 < stepcut> mae_work: I had pulled in some patches from another repo and did a, darcs push -as
18:15 < mae_work> but what is it? :)
18:15 < stepcut> oh, just a debian directory for happstack-util
18:16 < stepcut> so you could build .debs
18:16 < mae_work> oh i see
18:16 < stepcut> 'cuz that's how I roll
18:20 < mae_work> yeap :)
18:21 < stepcut> I should have happstack-state integrated into the testsuite soon
18:21 < stepcut> it has a bunch of quickchecks :)
18:21 < koeien> mae_work: it may be useful to link to the buildbot on the happstack.com development-page
18:24 < mae_work> koeien: ok will do.
18:25 < mae_work> I will probably tag the release tommorrow
18:25 < mae_work> so no one break anything !
18:25 < mae_work> (tests and docs are ok)
18:26 < wchogg> Oh man, so don't commit the patch that changes the whole codebase over to Epigram?
18:27 < stepcut> wchogg: he just said don't break it. I assume your Epigram patch proves that it does not break anything...
18:30 < koeien> lol
18:31 < wchogg> *#@%, you called my bluff.
18:33 < stepcut> I wonder if HPC will work with happstack
18:33 < koeien> TH + HPC = boom ?
18:34 < stepcut> koeien: no idea, but I would not be suprised if -threaded, TH, or anything of that nature caused trouble
18:35 < mae_work> : )
18:37 < wchogg> HPC?
18:37 < koeien> Haskell program coverage
18:38 < wchogg> Ah
18:41 < wchogg> So what is TH used for in Happstack other than the serialization code?
18:42 < stepcut> mkMethods
18:42 < koeien> i just encountered it in -Data for XML stuff
18:42 < koeien> that's perhaps what you mean
18:42 < stepcut> deriveAll, deriveSerialize, mkMethods are the most obvious uses of TH I can think of
18:45 < stepcut> ### Failure in: happstack-state:0:checkpointProperties:4:prop_runRestoreCongestion
18:45 < stepcut> Falsifiable, after 59 tests:
18:45 < stepcut> [6,-10,3,14,2,1,-12,-8,-14,17,7,-14,10,-11]
18:45 < stepcut>  
18:45 < stepcut> :(
18:45 < koeien> nice
18:45 < koeien> that's a nontrivial example
18:45 < stepcut> it usually passes
18:46 < koeien> good that this is in the logs
18:48 < mae_work> stepcut: increase the sample size so it fails more consistently :)
18:48 < stepcut> mae_work: yep
18:48 < koeien> also, could you hardcore that example as regression test?
18:49 < stepcut> koeien: sure
18:49 < stepcut> shortly, first I have to write qcrun
18:49 < stepcut> some of the saver tests need a timeout
18:49 < mae_work> TH afte reading up on it a bit is actually really simple
18:49 < mae_work> I think i can improve the existing derive stuff
18:49 < koeien> mae_work: the hardest part is the API
18:53 < koeien> anyway, i'm off to bed. bye
19:11 < stepcut> hrm, I think I need to modify the test executable to detect if they are running at a tty or not
19:12 < mae_work> stepcut: oh?
19:12 < mae_work> koeien: ok thanks :)
19:13 < stepcut> mae_work: the current scripts are friendly for non-interactive use. They don't use any terminal commands, they just print out the final result.
19:13 < stepcut> which is what you want for buildbot, etc.
19:13 < stepcut> but there are enough tests now that if you run the program by hand it looks like it is just hung
19:14 < mae_work> heh
19:14 < stepcut> so, i need a flag or something to switch between the different output options
19:21 < mae_work> default to interactive
19:21 < mae_work> and provie --output-only or something for just printing
19:21 < mae_work> provide *
19:43 < stepcut> with any luck, watch this...
19:59  * mae_work watches
20:04 < h_buildbot> Build for ghc-6.8.3 OK. Test suite ran. 15/1079 test cases failed. Check http://buildbot.happstack.com/ for details.
20:04 < stepcut> tada!
20:05 < Axman6> :o
20:05 < mae_work> whoa
20:05 < mae_work> 1079?
20:05 < mae_work> heh
20:05 < mae_work> is that counting test cases from QC?
20:05 < stepcut> yeah, I am not quite sure how the count got that high
20:05 < mae_work> the auto gen'd ones
20:05 < sm> cool stepcut
20:06 < stepcut> no, each quickcheck is only counted as one test
20:06 < sm> what's the difference between std and test builds, why are there two ?
20:06 < stepcut> sm: they used to have different flags, but now the only real different is whether happstack-tests get built or not
20:07 < mae_work> stepcut: it worries me that the tests don't fail :) did you test the inverse case?
20:07 < mae_work> err what i mean to say is, if you don't first make the test fail, then you don't have as much proof that you are testing something useful in the first place
20:07 < stepcut> ?
20:08 < mae_work> or did you just convert the existing tests?
20:08 < stepcut> I converted the existing tests
20:08 < stepcut> some of which fail already :)
20:09 < mae_work> heh
20:09  * stepcut kicks the impossible
20:11 < mae_work> i'm really glad that we are starting to build up the test suite
20:11 < mae_work> i hope in 0.2 we can get tests for alot of the macid stuff
20:11 < mae_work> that seems to be where alot of people are on the fence
20:12 < mae_work> if we can prove methodically that it is sound, this will help.
20:12 < chessguy> @faq can haskell do the impossible?
20:12 < chessguy> :(
20:12 < mae_work> duh it can
20:14 < h_buildbot> Build for ghc-6.10.1 OK. Test suite ran. 17/1079 test cases failed. Check http://buildbot.happstack.com/ for details.
20:15 < stepcut> I don't think there should be 1079 tests
20:15 < stepcut> I think I am accidently using the list monad or something
20:17 < mae_work> heh
20:18 < stepcut> ah, much better, on 25 now
20:18 < stepcut> I was get smacked by the list monad
20:18 < mae_work> lol
20:24 < stepcut> ok, pushed a fix. Now we only have 71 test cases, but that is still pretty good
20:24 < stepcut> I have not turned any of the code in 'Examples' into tests yet
20:25 < stepcut> I need to add the testsuite code to Server and Contrib still, but they do not have any existing tests to leverage
20:25 < stepcut> something is broken in happserver-state though
20:25 < stepcut> and it seems to be a race condition of some sorts
20:25 < stepcut> I get random failures, but passing in the failing value does not cause a failure
20:26 < stepcut> we should figure out of it is serious or not
20:27 < mae_work> stepcut: ok
20:27 < mae_work> stepcut: i am heading home soon
20:27 < mae_work> i will try to crack the code :)
20:28 < mae_work> either way 0.1 will still be released
20:28 < mae_work> the other thing that is going on, not sure if it is related
20:28 < stepcut> there are some comments at the end of, happstack/HAppS-State/tests/HAppS/State/Tests/CheckpointProperties.hs
20:28 < mae_work> is people report high memory usage (not related to macid)
20:28 < mae_work> so we need to track that bastard down to
20:28 < stepcut> I have never seen that
20:28 < mae_work> too *
20:28 < stepcut> I have run servers for months with no issues
20:29 < mae_work> happens in gitit 0.5 apparently and it doesn't even use state
20:29 < mae_work> stepcut: ic
20:29 < stepcut> in my experience, it's probably something to do with gitit, and nothing to do with happs :)
20:29 < mae_work> stepcut: might be something non-related
20:29 < mae_work> an infinite list gone bad
20:29 < mae_work> or
20:29 < stepcut> yeah
20:29 < mae_work> or foldr
20:30 < stepcut> happstack tends to make people more aware of memory leaks in their code just because it is so long running
20:30 < mae_work> : )
20:31 < mae_work> profiling helps
20:31 < stepcut> that is one of the reasons why the left-fold enumeration stuff is attractive, it prevents a lot of I/O related space leaks (i think?)
20:31 < mae_work> i think it has more to do with strictness
20:39 < h_buildbot> Build for ghc-6.8.3 OK. Test suite ran. 17/1079 test cases failed. Check http://buildbot.happstack.com/ for details.
20:49 < h_buildbot> Build for ghc-6.10.1 OK. Test suite ran. 16/71 test cases failed. Check http://buildbot.happstack.com/ for details.
20:52 < mae_> har
20:56 < stepcut> much better
20:57 < mae_> yep
20:57 < mae_> i'm building everything right now
20:57 < stepcut> well, sort of
20:57 < mae_> so how do i run these tests
20:57 < stepcut> ghc 6.8.3 ran too many tests...
20:57 < mae_> heh
20:57 < stepcut> ./bin/build-install-test-all.sh && ~/.cabal/bin/happstack-tests
20:57 < mae_> stepcut: i think it might have started building before your latest patch
20:57 < stepcut> that will build, install, and run everything
20:57 < mae_> so if my theory is right in 5 minutes it will go again
20:58 < mae_> i don't see that script
20:58 < stepcut> cd HAppS-State/tests/ ; make local
20:58 < stepcut> that script is definitely there
20:58 < stepcut> that is what buildbot uses
20:58 < stepcut> look harder!
20:58 < mae_> ahh i see it now
20:59 < mae_> oh it wasn't +x
20:59 < stepcut> see, I told you :)
20:59 < mae_> didn't show up with tab
20:59 < mae_> duh
20:59 < stepcut> yeah, darcs still does not support permissions
20:59 < mae_> so wait a min
20:59 < mae_> -f tests
20:59 < mae_> i thought tests were in by default
21:00 < stepcut> yeah, that flag is not needed anymore
21:00 < stepcut> both scripts build with tests enabled, but that script also builds the master testsuite
21:01 < mae_> http://pastebin.com/m3e376641
21:02 < mae_> got the same thing
21:02 < stepcut> buildbot.happstack.com got fancier since I last looked :)
21:02 < stepcut> yep. that is the error
21:02 < stepcut> but if you add that result to runRestoreCongestionKnownFailures, it will probably work
21:03 < stepcut> so, as far as I can tell, it's not a particular set of values that causes the problem
21:04 < stepcut> also, I am thinking I should probably build the testsuite binarys with -threaded, though that wouldn't help with this particular issues
21:05 < mae_> well
21:05 < mae_> this definitely looks like a parallel race condition
21:05 < stepcut> sure, but it happens with or with out the threaded runtime
21:06 < mae_> apparently we aren't parallel proof yet
21:06 < mae_> hm
21:06 < mae_> the non-threaded runtime can still spawn threads
21:06 < mae_> it just doesn't allow non-blocking OS-level-IO actions
21:06 < stepcut> right
21:07 < mae_> which hmm forkIO should be a candidate
21:07 < mae_> help me with this
21:07 < stepcut> I have seen this test fail in both the compiled executable  (which does use -threaded) and when using 'make local' (which I believe implies -threaded).
21:07 < mae_> what is this property trying to assert?
21:08 < stepcut> Hence my statement that it making the binaries be compiled with -threaded is unrelated to the test failing
21:11 < stepcut> mae_: no idea :)
21:12 < mae_> the property takes some values
21:12 < mae_> which are basically mock events i guess
21:12 < stepcut> yes
21:12 < stepcut> I think that is right
21:12 < mae_> then it is trying to assert that the list you passed in is the same as the list that is spit out of the monad
21:13 < mae_> forM_
21:13 < stepcut> did you see the big comment at line 66
21:13 < mae_> this says, take these values and run all of them at the same time into the function
21:14 < mae_> yeah
21:15 < mae_> forM_ values $ \value -> forkIO (update (Push value) `finally` signalQSem sem)
21:15 < stepcut> I think it tries to simultaneously cram about bunch of new values into the the state and run a checkpoint
21:15 < mae_> forM_ is mapM_ with its arguments flipped
21:15 < stepcut> yes
21:16 < mae_> mapM_ f is equivalent to sequence_ map f
21:16 < stepcut> yes
21:16 < mae_> sequence_: Evaluate each action in the sequence from left to right and ignore the results
21:16 < mae_> hmm
21:16 < mae_> doesn't sound parallel
21:17 < mae_> you know what
21:17 < mae_> we need to see the results it spits out
21:17 < mae_> isn't there like
21:17 < mae_> assertMatch
21:18 < mae_>  map (assertBool "" . prop_runRestoreCongestion saver) known
21:18 < stepcut> it's parallel because forkIO returns immediately
21:20 < stepcut> what values do you want to see?
21:20 < mae_> how do you tell ghci to load non-exported functions too?
21:21 < mae_> : \
21:21 < mae_> we need to see why it was falsified
21:21 < mae_> not just the values that caused it to be falsified
21:22 < stepcut> if you do :load CheckpointProperties.hs, then you can get all the functions, even if they are not exported
21:22 < stepcut> or you add more stuff to the export list
21:22 < mae_> k
21:24 < stepcut> hunit has was to give more information about the failure, but this test is a quickcheck property, which only returns True/False
21:25 < stepcut> for now, you could modify the property so that when the condition itself so that when it does not hold, you just call error and print out what you want to know
21:26 < stepcut> I am not a quickcheck expert, maybe there is something smarter than can be done
21:27 < gwern> doesn't qc print the counterexample to stdout?
21:27 < stepcut> yes
21:27 < stepcut> but, in this case, that is not enough
21:27 < mae_> i know, i'll just use Debug
21:27 < mae_> and print the end result
21:27 < mae_> before the monad returns
21:28 < stepcut> mae_: sure, that is a less aggrevise version of my suggestion to call error
21:28 < stepcut> mae_: you want to print ls and values in the (\ls -> sum ls == sum values) part I think
21:29 < mae_> wow
21:29 < mae_> it passed this time
21:29 < mae_> weir
21:29 < mae_> d
21:29 < mae_> this is happs-state right
21:30 < stepcut> yes
21:30 < mae_> happstack
21:30 < stepcut> it passes sometimes
21:30 < stepcut> cuz it's a race condition
21:30 < mae_> yep
21:30 < stepcut> in fact, it passes more often than not for me
21:31 < stepcut> considering the test is run 100 times each run, I would say the failure rate is around 0.1%
21:31 < stepcut> which is still too high ;)
21:32 < stepcut> actually, I am getting failures a lot more often now that I compiled with -threaded
21:34 < mae_> using traceShow right now
21:34 < mae_> bingo
21:34 < mae_> got it
21:34 < mae_> http://pastebin.com/m712df608
21:35 < mae_> the 13 is missing
21:35 < mae_> see?
21:36 < mae_> are the numeric values supposed to be unique?
21:36 < mae_> or is it valid that they might be duplicate
21:37 < stepcut> duplicates better be valid
21:41 < mae_> : (
21:44 < h_buildbot> Build for ghc-6.8.3 OK. Test suite ran. 16/1079 test cases failed. Check http://buildbot.happstack.com/ for details.
21:48 < stepcut> 6.8.3 is still running too many test cases...
21:50 < h_buildbot> Build for ghc-6.10.1 OK. Test suite ran. 16/71 test cases failed. Check http://buildbot.happstack.com/ for details.
21:50 < stepcut> mae_: look at the RunRestore type. It's just a fifo/queue thing
21:51 < stepcut> mae_: so duplicates should not be a problem
21:51 < stepcut> and, if duplicates were a problem, then passing in the failing values would fail everytime
21:51 < stepcut> plus, the first test case you pasted had no duplicates
21:52 < stepcut> it looks to me like an event is being dropped, though I have no idea why
21:55 < mae_> you know what
21:56 < mae_> i'm not sure that signalQSem is meant to be ran in parallel
21:56 < mae_> waitQSem is for sure
21:56 < mae_> but I think signalQSem might be assuming that only one thread would be aclling it
21:56 < mae_> calling it *
21:56 < mae_> http://hackage.haskell.org/packages/archive/base/4.0.0.0/doc/html/src/Control-Concurrent-QSem.html#waitQSem
21:56 < stepcut> no idea
21:57 < stepcut> but it would be nice if the test is broken and not happs-state, because the test is a lot simplier
21:58 < mae_> Implement this in the same way as
21:58 < mae_> -- shared variables are implemented - maintaining a list of @MVar@s
21:58 < mae_> -- representing threads currently waiting. The counter is a shared
21:58 < mae_> -- variable, ensuring the mutual exclusion on its access.
21:59 < stepcut> what makes you think that singleQSem is not thread safe
22:01 < mae_> because of the way it is behaving
22:01 < mae_> the only thing that is done in parallel is signalQSem
22:01 < mae_> maybe it is the code
22:01 < mae_> but the test isn't exactly straightforward
22:03 < stepcut> i think the way qsem is being used is the entire point of Qsem
22:04 < mae_> i would tend to agree
22:04 < mae_> but i'm not ruling out it
22:04 < mae_> yet.. :)
22:05 < mae_> so yeah
22:05 < mae_> this test already existed right?
22:05 < mae_> i think the name gives it away
22:05 < mae_> Implement this in the same way as
22:05 < mae_> -- shared variables are implemented - maintaining a list of @MVar@s
22:05 < mae_> -- representing threads currently waiting. The counter is a shared
22:05 < mae_> -- variable, ensuring the mutual exclusion on its access.
22:05 < stepcut> yes
22:05 < mae_> runRestoreCongestionKnownFailures
22:05 < mae_> "known failures"
22:06 < stepcut> oh, that test is new
22:06 < stepcut> but useless
22:06 < mae_> uh?
22:06 < mae_> oh nm
22:06 < mae_> omg i've been looking at the wrong function
22:07 < mae_> sigh
22:07 < stepcut> well, not entirely the wrong function
22:08 < stepcut> prop_runRestoreCongestion is the property that is failing which gets called by that function
22:08 < mae_> ah ok
22:09 < mae_> so i'm at the wright spot
22:09 < mae_> hehe
22:09 < mae_> right *
22:11 < mae_> um
22:11 < mae_> even this:
22:11 < mae_> forM_ values $ \value -> forkIO (update (Push (traceShow value value)) `finally` signalQSem sem)
22:11 < mae_> it is missing one output
22:11 < mae_> http://pastebin.com/m393cb610
22:12 < mae_> it is printed 10 times
22:12 < mae_> but there was 11 original values
22:12 < mae_> the problem happens before it even forks
22:12 < mae_> (or the semaphor is not blocking when it should)
22:12 < stepcut> hrm
22:13 < stepcut> your trace is after the forkIO
22:13 < mae_> right
22:13 < stepcut> what happens if you put it before the forkIO?
22:13 < mae_> good q
22:14 < mae_> let me try
22:17 < stepcut> that trace is only going to get called if Push is evaluated deeply enough
22:17 < mae_> true
22:17 < stepcut> another interesting thing to test would be: forM_ values $ \value -> forkIO (traceShow value (update (Push value)))
22:18 < mae_> yeah
22:19 < mae_> oh man
22:19 < mae_> i guess it dissapears after using Push
22:20 < mae_> http://pastebin.com/m3afe7c98
22:20 < mae_> its silently screwing up the update
22:21 < mae_> well update probably isn't to blame
22:21 < mae_> its probably the spliced code
22:21 < mae_> from MkMethods
22:21 < mae_> so yeah i guess it signals that 1 is available to the semaphore
22:21 < mae_> even if it screwed up
22:22 < mae_> `finally`
22:22 < mae_> so something here is our culprit:
22:22 < mae_> (Push value)
22:23 < mae_> HAppS.State.ComponentTH
22:23 < stepcut> I suspect the update function is returning, but that the Push event is getting lost
22:24 < mae_> but why would it?
22:24 < stepcut> dunno, something related to congested events and checkpointing :)
22:25 < mae_> heh
22:25 < mae_> i bet we can make this fail more consistentlyif we use larger lists
22:26 < mae_> i don't know how to generate random large lists with qc
22:26 < mae_> can you give it a shot?
22:26 < stepcut> check out the comment above createCheckpoint in happstack/HAppS-State/src/HAppS/State/Checkpoint.hs
22:26 < stepcut> I am going to bed in a few minutes
22:26 < stepcut> but I could look at it tomorrow
22:27 < stepcut> you could change:
22:27 < stepcut> prop_runRestoreCongestion withSaver values
22:27 < stepcut> to:
22:28 < stepcut> prop_runRestoreCongestion withSaver values' = let values = concat $ replicate 10 values' in
22:28 < stepcut> not the proper way, but it should work for this test
22:39 < stepcut> ok, time to write DnB and then go to bed
22:42 < gwern> mae_: you could do something like 'prop x = length x > 1000 ==> <test>'
22:42 < gwern> or whatever the 'precondition' operator actually is, I forget
22:42 < gwern> may make the test very slow though since it'll still be generating a lot of small lists
22:43 < stepcut> gwern: I think it is ==>
22:43 < gwern> is it? I was just guessing
22:43 < stepcut> :)
22:43 < stepcut> good guess
22:44 < stepcut> (==>) :: Testable a => Bool -> a -> Property
22:44 < stepcut>  
22:45 < stepcut> the proper method probably uses 'sized' or one of those combinators
--- Log closed Tue Feb 03 00:00:40 2009