--- Log opened Sun Feb 08 00:00:45 2009
00:11 < dsrogers> three more patches...
00:12 < dsrogers> I particuarly like how simpleHTTP' turned out.
00:35 < dsrogers> there are almost no convinient ServerPartT methods.
00:35 < dsrogers> i.e. methods of the form a -> ServerPartT
00:36 < dsrogers> there is no reason to be slinging around the request object.  That's why there is a monad.
00:36 < dsrogers> I can't... do
00:37 < dsrogers> do h<-getHeader "authenticate"
01:37 < dsrogers> I've now contributed some rudimentary documentation.
01:37 < dsrogers> though it includes a few tricks I haven't seen in any of the tutorials.
01:38 < dsrogers> it's also exposed some glaringly obvious missing functions in the module.
01:38 < dsrogers> which I hinted at in the documenation.
01:38 < Axman6> i think there needs to be a nice simple step by step tutorial on making something like a fully fledged blogging system
01:39 < Axman6> with posts, comments, categories, possibly RSS feeds
01:40 < dsrogers> I think the first step is to get documenation that doesn't require everyone to puzzle out how to build apps on their own.
01:40 < Axman6> indeed
01:40 < dsrogers> There are 4 or 5 functions in my documentation patch that probably belong in the module itself.
01:41 < dsrogers> and shows an implentation of basicAuth that should replace the built in one, as it's much more reusable.
01:44 < dsrogers> what happened was that I tried to build examples using "do" statements, since ServerPartT and WebT are monads, it seemed like the obvious thing to do.
01:44 < dsrogers> and discovered that all the semantics for doing this were rather off and/or missing
01:48 < dsrogers> anyways, it's getting late so ... happy hacking!
02:37 < mightybyte> Anyone know why I get this when I do "cabal install happstack-server"?  cabal: Unresolved dependencies: base >=3&&<4, base >=3&&<4, base <4, base >=3&&<4...
02:46 < mightybyte> Do I have to have both base-3 and base-4?
03:58 < paulvisschers> When I try to enter a character like ? in a form, When I 'look' at the field's value, I actually get "&#21516;" instead of the expected "?". Is this caused by happs, by internet forms or by haskell?
03:58 < paulvisschers> and how do I fix it?
04:15 < paulvisschers> Unrelated: why doesn't Ev have a MonadIO instance?
08:38 < Saizan> do we keep a changelog of semantic changes?
08:57 < Saizan> paulvisschers: re "&#21516;": that's because happs doesn't perform any decoding of the input
08:58 < Saizan> paulvisschers: re MonadIO for Ev: you are not supposed to perform IO in your methods
08:59 < Saizan> the part about the decoding is something that we need to fix, but it needs a bit of design if we want to support multiple encodings
08:59 < paulvisschers> ok
09:00 < paulvisschers> Then I'll just leave that as it is (I don't really need unicode support atm anyway)
09:00 < paulvisschers> About the MonadIO, that is too bad
09:01 < paulvisschers> I get it, but I will have to use my form library very differently :(
09:01 < Saizan> well, methods can be replayed multiple times and on multiple machines, it'll be quite messy if they do IO
09:01 < paulvisschers> Since I want to add a time added by using getCurrentTime inside the form
09:02 < paulvisschers> yeah I understand
09:02 < paulvisschers> I'll work around it I guess
09:02 < Saizan> you need to pass the time as an argument to the method
09:04 < paulvisschers> :(
09:05 < Saizan> with could make that transformation automatically if we stick to an Applicative interface
09:06 < Saizan> but that's probably overkill :)
09:13 < paulvisschers> The problem is really that I set my form library up for doing monadic stuff inside, but now that power can't be fully utilized
09:13 < paulvisschers> And that is a shame
09:14 < stepcut> paulvisschers: I haven't looked at your library, but in general, I just make wrapper functions around the calls to the methods that do the IO and then pass the values to the method
09:14 < stepcut> paulvisschers: so the end user just calls the wrapper functions and doesn't worry about it
09:15 < stepcut> paulvisschers: dunno if you can do that or not
09:16 < paulvisschers> stepcut: I could, but I sort of already have a bunch of my own wrapper and helper functions that disallow that
09:18 < stepcut> paulvisschers: unicode support in scheduled for 0.3 I think
09:18 < paulvisschers> well disallow is maybe not a good word, but they aren't set up for it at least
09:18 < stepcut> right
09:18 < paulvisschers> Ok I'll just wait for that then
09:20 < paulvisschers> It's also not very nice that I have a type class with forms for each type
09:20 < paulvisschers> since not all of them actually require the time
09:21 < stepcut> OT: I think I am going to implement a pure list in actionscript
09:24 < paulvisschers> I'm not familiar with actionscript
09:24 < paulvisschers> that's similar to javascript?
09:24 < stepcut> yes, they a both based on ecmascript
09:25 < stepcut> adobe created a new standard, ecmascript 4, that they hope to get approved, but it recently got shot down. They also released a fast javascript engine based on emascript 4 to the mozilla foundation
09:26 < stepcut> actionscript has a primitive type system now
09:27 < paulvisschers> ok
09:27 < stepcut> i should just finish my haskell -> swf compiler :)
09:28 < paulvisschers> :)
09:31 < paulvisschers> I'll work on my form lib some more :)
10:12 < mightybyte> Anyone know what I should do about this error when I try to cabal install happstack-server?
10:12 < mightybyte> cabal: Unresolved dependencies: base >=3&&<4, base >=3&&<4, ...
10:13 < dcoutts> mightybyte: I expect the important point there is in the ...
10:13 < mightybyte> dcoutts: It's just "base >=3&&<4" repeated several more times
10:14 < dcoutts> is it?
10:14 < mightybyte> Yaeh
10:14 < mightybyte> cabal: Unresolved dependencies: base >=3&&<4, base >=3&&<4, base >=3&&<4, base >=3&&<4, base >=3&&<4, base >=3&&<4, base >=3&&<4, base >=3&&<4, base >=3&&<4
10:14 < dcoutts> hmm, what version of ghc are you using?
10:14 < dcoutts> what does ghc-pkg list base report?
10:14 < mightybyte> I just installed ghc 6.10.1 on ubuntu
10:15 < mightybyte> base-4.0.0.0
10:15 < dcoutts> and?
10:15 < dcoutts> that's it?
10:15 < mightybyte> Yeah
10:15 < mightybyte> Should they both be in there?
10:15 < dcoutts> you've got a messed up ghc install
10:15 < mightybyte> Ahhhh, ok
10:15 < dcoutts> it's missing base-3.x
10:17 < mightybyte> Ok, I just redid make install
10:17 < mightybyte> Now it's giving me this
10:17 < mightybyte> cabal: ghc version >=6.2 is required but the version of /usr/local/bin/ghc could not be determined.
10:20 < dcoutts> mightybyte: what does /usr/local/bin/ghc --version report?
10:21 < mightybyte> Oh great, it's a symlink to ghc-6.10.1, but the permissions got messed up.  It's 750.
10:21 < mightybyte> That's my problem.
10:22 < mightybyte> I wonder why it's doing that
10:28 < mightybyte> This is weird, when it installs, it sets all kinds of library permissions to 640 or 750
10:29 < paulvisschers> mightybyte: Have you had any success with your form problem yet?
10:30 < mightybyte> paulvisschers: I got almost there, but then ran up against a problem that I'm not sure I can solve the way formlets are currently implemented.
10:30 < paulvisschers> ok
10:30 < paulvisschers> mightybyte: But that works with nested lists as well?
10:31 < mightybyte> Everything works except the behavior when the user enters an invalid form.
10:31 < mightybyte> No, I haven't even thought about nested lists.
10:31 < paulvisschers> Could you maybe send me your code?
10:31 < mightybyte> When the user enters an invalid item in a list, it doesn't always render the resulting form properly.
10:31 < mightybyte> paulvisschers: Sure
10:33 < paulvisschers> mightybyte: what is going wrong?
10:34 < mightybyte> paulvisschers: Well, the formlets massInput uses a linked list implementation.
10:34 < mightybyte> ...are you familiar with it?
10:34 < paulvisschers> not really
10:34 < mightybyte> Ok, let's say you want a Form m xml [a]
10:34 < paulvisschers> I glared over the code a couple of times, but haven't really gone in depth
10:34 < mightybyte> You pass in a Form m xml a
10:35 < mightybyte> And you also pass in a form for a hidden value
10:35 < mightybyte> In my implementation I don't require that to be passed in.
10:35 < mightybyte> It combines Form a and Form h into Form m xml (a, Maybe String)
10:36 < mightybyte> The hidden value is like the next pointer in a linked list
10:36 < mightybyte> The code uses that as the prefix for the field names to the next a in [a]
10:37 < mightybyte> Make sense?
10:38 < paulvisschers> I think I get it
10:38 < mightybyte> But if any one of the form elements has invalid input, then instead of returning "Success (a, String)", it will return "Failure msg"
10:39 < mightybyte> ...and the next pointer is lost.
10:40 < mightybyte> So if the invalid item is the last one in the list, then the form renders properly.  But if it is earlier, then you lose all the subsequent list elements.
10:41 < stepcut> mightybyte: that is why formlet elements aren't allow to depend on each other...
10:41 < paulvisschers> I see
10:42 < mightybyte> stepcut: But it would seem that they have to depend on each other for that massInput implementation to work.
10:42 < paulvisschers> I have hierarchical labeling, so I don't need the output in this case
10:43 < stepcut> I don't understand the specifications for massInput. Do you know the number of elements in the list before you render the form?
10:43 < mightybyte> paulvisschers: Yes.  When I first started looking at formlets, I considered the tradeoff between a linked list approach and a (list_length, [a]) approach.
10:44 < mightybyte> stepcut: No.  That's the point.  Since it's a linked list, you don't know that information.
10:44 < stepcut> how do you render a form with an unknown number of input elements?
10:45 < mightybyte> You traverse the linked list of "next pointer" prefixes until you come to "".
10:45 < paulvisschers> mightybyte: How do you add new fields btw, with pregenerated javascript or by requesting it with ajax?
10:45 < mightybyte> pregenerated javascript
10:46 < mightybyte> My javascript-fu is rather weak, so my solution here is not very robust.
10:46 < stepcut> mightybyte: so when you render the mass input control it has some number of input elements, and then more get added dynamically via javascript before the form is submitted?
10:46 < koeien> i don't know much javascript, but with jQuery i can manage
10:46 < mightybyte> stepcut: Yes.
10:47 < mightybyte> koeien: Yes, I'm using jQuery.
10:50 < koeien> mightybyte: i conclude that formlets should be patched?
10:50 < mightybyte> koeien: Yes.  The current code has even more problems because massInput doesn't support default values at all.
10:51  * stepcut thinks about it
10:51 < mightybyte> stepcut: Yeah, it's difficult to get everything right.
10:52 < mightybyte> I'll hpaste my code
10:52 < koeien> chr1s is the maintainer appearantly
10:52 < mightybyte> Yes, I've been talking to him.
10:53 < koeien> any chance of a new version ? :) i've not been using formlets but if i would start i site i certainly would
10:53 < koeien> (or formbinator of course :)
10:55 < mightybyte> Oooh, hpaste didn't work
10:56 < mightybyte> 500 Internal Server Error
10:56 < mightybyte> 58030 5: Unable to close due to unfinalised statements
10:56 < koeien> they should've used formlets
10:56 < paulvisschers> koeien: I know where you live, so you better use formbinator :)
10:57 < koeien> that is problematic indeed
10:58 < mightybyte> http://moonpatio.com/fastcgi/hpaste.fcgi/view?id=1265#a1265
11:00 < mightybyte> http://moonpatio.com/fastcgi/hpaste.fcgi/view?id=1266
11:04 < dsrogers> good morning...
11:07 < Saizan> hi
11:07 < dsrogers> are we assuming 6.10?
11:08 < Saizan> no
11:09 < dsrogers> ah
11:09 < Saizan> dsrogers: do you agree with the semantic i describe before your patch?
11:09 < dsrogers> which part?
11:09 < Saizan> do modifyResponse f
11:09 < Saizan>     escape x
11:09 < Saizan>     foo
11:09 < Saizan>  ~~~>
11:09 < Saizan> escape x
11:10 < Saizan> i.e. ignoring 'f'
11:10 < dsrogers> I agree that does escape.  But x here is a WebT.
11:10 < Saizan> right
11:10 < Saizan> and what's the problem with that?
11:10 < Saizan> i've not described all the semantic by those examples
11:11 < dsrogers> nothing, if you have a WebT monad in a WebT.
11:11 < dsrogers> but if you're building a reponse in your WebT do block, you don't have a WebT to escape yet.
11:11 < Saizan> i just pointed out that in that cases you patch has changed the semantic
11:11 < Saizan> ok
11:11 < dsrogers> I don't think so.
11:11 < Saizan> i see what you want
11:12 < Saizan> why not?
11:12 < dsrogers> escape' semantics haven't changed, I don't think.
11:12 < dsrogers> oop.
11:12 < dsrogers> escape...
11:12 < dsrogers> why would it have changed?
11:12 < Saizan> well now if you use escape the 'f' is _not_ ignored
11:13 < Saizan> escape only considered modifiers in the WebT it took as argument
11:13 < dsrogers> ahhhh.
11:13 < dsrogers> ah ha!
11:13 < dsrogers> ok.
11:13 < dsrogers> we'll that's fixable.
11:13 < dsrogers> create ignoreResponseHeaders and put a bind to escape' in the new def of escape.
11:14 < dsrogers> err, not ignoreResponseHeaders.  ignoreResponseFilter
11:14 < dsrogers> I was not trying to change the semantics of escape.
11:14 < Saizan> how do you write ingnoreResponseFilter?
11:15 < dsrogers> WebT $ return $ (Ok id ())
11:15 < dsrogers> oh wait ...
11:15 < dsrogers> hmmm..
11:16 < Saizan> i don't think you can with the definition of (>>=) after your patch
11:18 < dsrogers> yeah, not without another Result constructor.
11:20 < dsrogers> so setReponseFilter seems useful regardless.
11:20 < dsrogers> and that can only be done with another Result constructor anyway.
11:21 < dsrogers> so how about a new patch that adds that functionality and then uses to to fix escape?
11:22 < Saizan> let's be clear on the semantic of escape' first
11:22 < dsrogers> i.e. even before the patch you couldn't write setResultFilter
11:22 < dsrogers> ok, go ahead
11:23 < Saizan> "do modifyResponse f; escape' x" should ignore f or not?
11:23 < dsrogers> no.
11:23 < Saizan> why?
11:23 < dsrogers> err, it should not ignore f.
11:24 < dsrogers> because I wanted a control structure that says "I'm done, leave now"
11:24 < Saizan> yeah, and why?
11:24 < Saizan> can't you just return there?
11:24 < dsrogers> return doesn't stop the computation.
11:24 < dsrogers> the next line will get evaluated.
11:25 < Saizan> yeah, but what's an use case where you want to write a next line and still escape earlier? and when you can't do it with standard control structures like if/then/else ?
11:26 < dsrogers> I have two examples in my doc patch that use it.
11:26 < dsrogers> one is contrived, but gets the point across.
11:26 < dsrogers> the other is actually useful.
11:27 < Saizan> ok, i'll read those
11:27 < dsrogers> but you're probably right.  You can probably achieve the same thing with if-then-else.
11:28 < dsrogers> I just read the monad behavior of WebT and thought, hey, that's a control structure, can I use it?
11:28 < Saizan> though it seems a bit weird to have escape and escape' with slightly different semantics (apart from accepting a monadic or pure value)
11:28 < dsrogers> it does...
11:28 < dsrogers> that is defiantly something I don't like.
11:29 < Saizan> i think the main point of escape was to ignore the earlier modifyResponse's, but i'm not the one who designed SimpleHTTP
11:29 < dsrogers> I think it's a bit wierd to pass in a WebT into your WebT monad instead of use using <-
11:30 < dsrogers> I don't think the designer of simpleHTTP thought hard about monad and do block semantics.
11:30 < dsrogers> there are virtually no functions you can use in either of the 2 monads in there in their do blocks they way you would expect them too.
11:31 < dsrogers> e.g. inside a ServerPartT, all you have is getHeader String req.
11:31 < Saizan> well, escape' x = escape (return x) would respect the semantic and be easy to use ina do-block
11:32 < Saizan> (where escape there is the old one)
11:33 < Saizan> in that case no filters are used, since return produces a WebT with none
11:33 < gwern> bleh. getting complete repos of the happs repos is difficult! so many server issues
11:34 < dsrogers> oh hey, I thought it was just me!
11:34 < dsrogers> ah.  Well what if I want to ignore response headers generated up to that point, but continue the computation?
11:35 < dsrogers> there is no way to do that either before the patch or after.
11:37 < Saizan> one could argue that's what the old escape does, but not in first-order style
11:37 < dsrogers> and if you add that, then escape can be written as escape w = ignoreResponseFilter >> w >>= escape'
11:37 < dsrogers> what does "first-order style" mean?
11:38 < Saizan> something like your do-block style
11:39 < Saizan> you're trying to make the monad behave more imperatively
11:39 < dsrogers> well... yes!
11:39 < dsrogers> do blocks are imperative.
11:39 < Saizan> that doesn't mean it's good :)
11:40 < dsrogers> well if you can do imperative, one should expect it to work right.
11:41 < Saizan> how was the old behaviour wrong?
11:41 < dsrogers> it wasn't wrong.  I just think escape' is more useful in a do block as I wrote it.
11:41 < paulvisschers> mightybyte: The code you gave me doesn't include the javascript code for addItem, can you send me that as well?
11:41 < dsrogers> as in, it's a more useful control structure.
11:42 < dsrogers> I also like it because it removes knowledge about the monad machinery from the definition of escape.
11:42 < mightybyte> paulvisschers: It's specific to my app, but sure.
11:42 < dsrogers> so the monad is better encapsulated.
11:42 < Saizan> dsrogers: that's a different issue
11:43 < Saizan> dsrogers: however i don't see the connection between using in a do-block and ignoring or not the earlier modifyResponse
11:43 < Saizan> dsrogers: i think those are orthogonal issues
11:43 < Saizan> dsrogers: that we should discuss separately
11:43 < dsrogers> yes...
11:44 < mightybyte> paulvisschers: It requires jQuery
11:44 < paulvisschers> mightybyte: ok
11:44 < paulvisschers> I'm just going to look at how you generate the code
11:44 < paulvisschers> mightybyte: But you said it's specific to your code, so it won't work with any other forms right?
11:45 < dsrogers> I think ignoring the earlier modifyResponse is not an obvious side effect of a control structure.  You have to look at the code and remember your headers are going to disappear.
11:45 < Saizan> dsrogers: btw, can you clarify your position on the mailing list? so others can see where the discussion is going
11:45 < dsrogers> sure.
11:45 < dsrogers> I'll reply to you again...
11:46 < mightybyte> paulvisschers: Ok, it's on moonpatio.com
11:46 < paulvisschers> ok thanks
11:46 < gwern> (man. 6 darcs get --completes later, and I *still* don't have ixset)
12:01 < gwern> interesting. some of them got all the patches, but the repo is corrupt. at least repair can handle it
12:06 < sm>  gwern: what.. are there network problems with patch-tag.com ?
12:07 < sm> dsrogers: thanks for the docs! \o/
12:08 < dsrogers> are they clear?  or helpful?
12:08 < dsrogers> I'm aiming for both here.
12:08 < sm> I just read the patch on the list.. at least, they are a great step forward
12:09 < sm> clarified some stuff.. I plan to read again when they are rendered somewhere
12:09 < dsrogers> lol ... got it, so not clear.
12:13 < paulvisschers> Does anyone know if there is a way to turn a function of type (Int -> Html) into an equivalent piece of javascript?
12:13 < paulvisschers> so a javascript function going from an integer to an html string?
12:15 < paulvisschers> I think the problem is that this is too general
12:15 < paulvisschers> I basically want the string that represents the integer to be put into several positions inside the html code
12:15 < mightybyte> paulvisschers: What's too general?
12:16 < paulvisschers> converting a function of (Int -> Html) to a javascript version
12:16 < mightybyte> Yeah
12:16 < paulvisschers> without writing a haskell compiler at least
12:16 < mightybyte> Right
12:17 < paulvisschers> The problem is that if I don't use (Int -> Html), I get really horrible code
12:18 < paulvisschers> Since I already have that one
12:18 < dsrogers> you can write a DSL and embed it in haskell.
12:18 < dsrogers> there are lots of examples of that.
12:19 < paulvisschers> dsrogers: Well sure, but it would be nice if I could still use the Html library
12:20 < dsrogers> you still could use the HTML library.
12:20 < dsrogers> if you wrote your DSL correctly.
12:20 < paulvisschers> I'm not so sure about that
12:22 < paulvisschers> It's starting to feel that I will need to redo my entire library to enable javascript support
12:22 < paulvisschers> And it's not going to get any more elegant in the process
12:23 < mightybyte> Nope
12:37 < mightybyte> paulvisschers: I'd try to avoid significant javascript support for now and just work on developing a reasonably robust javascript function that works with your framework.
12:39 < paulvisschers> mightybyte: That still is going to be pretty hard
12:40 < paulvisschers> Since all my forms generate results in the Html datatype
12:40 < mightybyte> Well, then just get some javascript that works for you and don't worry about it for now.
12:40 < paulvisschers> and there isn't really a way to use that to generate javascript to insert forms in general
12:40 < mightybyte> You could just add calls to javascript that should be imported elsewhere
12:41 < paulvisschers> mightybyte: I could do that, but I'm sort of making this for you
12:41 < paulvisschers> Since I don't need dynamic stuff in my forms myself :)
12:42 < mightybyte> paulvisschers: Oh, heh.
12:42 < mightybyte> Writing the javascript was definitely the annoying part for me.
12:43 < paulvisschers> Well I have a javascript function that that updates the counter (inside a hidden field) and then adds a new field
12:43 < mightybyte> I've pretty much decided to leave it alone for now and come back to it later.
12:44 < paulvisschers> only to create the new field, it needs a function from an integer (that is inside the counter) to a piece of html (the new field)
12:44 < mightybyte> That should be sufficient, right?
12:44 < paulvisschers> Well yes, but I would need to generate those functions though
12:44 < paulvisschers> Inside of haskell
12:45 < paulvisschers> I should basically be able to ask a Form m a for this code
12:45 < gwern> sm: no, these are the old happs repos. I'm trying to consolidate them into a repo using my strategy, but I discovered that most of my happs repos were partial
12:45 < mightybyte> Why not just use some javascript that duplicates the last element in the list?
12:45 < paulvisschers> like I'm able to ask for the html
12:45 < sm> ah
12:46 < paulvisschers> mightybyte: Because it needs to be relabeled
12:46 < gwern> (very annoying; my first 2 were complete repos, but there was a problem pulling, so after I finally get the compelte repos Im gonna have to convert them all to darcs2)
12:46 < mightybyte> Yeah, can't you just strategically set up your labeling scheme so a search and replace will do it?
12:47 < mightybyte> To make it robust, you just have to be careful about how you do this.
12:47 < paulvisschers> mightybyte: Perhaps, but I don't see how
12:48 < mightybyte> Well, even if it's not completely robust, it should be possible to do something with well-documented constraints.
12:48 < gwern> (woo, just got happs-util)
12:48 < paulvisschers> maybe, but that isn't the point of this library
12:49 < paulvisschers> it should be trivial to build and use forms
12:49 < mightybyte> Of course, the other possibility would be to just do an AJAX query for the right html.
12:49 < mightybyte> I completely agree, but once you get into javascript, it gets a little more dicey.
12:49 < paulvisschers> mightybyte: True, but that gives other problems
12:50 < mightybyte> Right.  It adds requirements in HAppS, which we've thus far been independant of.
12:50 < paulvisschers> yeah javascript sucks :)
12:52 < mightybyte> I think the pragmatic approach is just to have some javascript that copies the last entry and replaces the field names.
12:54 < paulvisschers> that may be hard though since forms can get pretty complex
12:54 < paulvisschers> But I'll think about it some more
12:54 < mightybyte> Yeah
12:55 < mightybyte> You can see from my code that I just wrap each field in a <tr> tag.
13:01 < mightybyte> You could probably add some div tags with unique IDs around the whole list and/or each element.
13:03 < mightybyte> <div id="listFormlet1">...<div id="listFormlet1Elem4">...
13:07 < koeien> or do it recursively
13:09 < koeien> wrap <span>s inside other <span>s :)
13:09 < koeien> won't help you too much since you probably get the data by id
13:11 < paulvisschers> The problem is that you need to put the ids inside of the inputs, the extra divs and/or spans don't really make it easier to update those
13:11 < koeien> yes
13:19 < mightybyte> paulvisschers: Well, the extra divs give you an easy way to get a whole element formlet, so you can do an easy search and replace to update the names.
13:20 < paulvisschers> ok right
13:21 < mightybyte> ...which is where the prefix approach used in formlets works nicely.
13:21 < mightybyte> ...except you'll make the prefix dependant on the counter instead of held in a chain of "next pointers".
13:22 < mae> gwern: is filestore getting a version bump? (to fix the memory issue ?)
13:25 < gwern> mae: probably. I expect john'll release within the week
13:26 < gwern> mae: although john still isn't happy with the overall memory usage - it peaks for me at 10% of ram, but 10% of 4 gigs is a lot, and 40% of john's 1gig (is a bit much)
13:28 < Saizan> gwern: tried profiling?
13:29 < gwern> profiling is a mess. we can't even convert the .hp to PS
13:29 < Saizan> why?
13:29 < gwern> hp2ps barfs on it
13:29 < gwern> and emits an obscure error about bad formatting
13:29 < Saizan> you kill the process or let it terminate?
13:29 < gwern> kill
13:30 < Saizan> ah, that's why.
13:30 < koeien> yes
13:30 < gwern> it shuts down cleanly when one interrupts it AFAIC
13:30 < koeien> i encountered that in the past :)
13:30 < Saizan> gwern: you should be able to delete the last incomplet section from the .hp and so get hp2ps to work on it
13:31 < Saizan> gwern: there's a paragraph in the ghc manual about this, iirc
13:33 < Saizan> i think the problem here is that waitForTermination is overwriting an handler set by the RTS
13:34 < Saizan> but it's a wild guess
14:15 < dsrogers> why did darcs send insist on sending three patches instead of 1?
14:17 < stepcut> dsrogers: because the patches depend on each other
14:17 < stepcut> ?
14:17 < dsrogers> ahh.
14:18 < dsrogers> darcs is smarter than me, is the problem.
14:22 < Saizan> heh :)
14:23 < dsrogers> Saizan: does my latest email address your concerns?
14:26 < Saizan> dsrogers: i'm looking at it
14:30 < Saizan> dsrogers: have you checked if it respects the monad laws? but i think there might be a simpler structure to do this
14:32 < Saizan> btw, functions like your executeFoo are usually called runFoo or runFooT
14:32 < dsrogers> ah
14:33 < Saizan> and i'd use (Monad m, ToMessage msg) => WebT m msg -> m (Maybe Response) for executeW
14:34 < Saizan> you might not want to have a default Response
14:35 < dsrogers> ok.
14:35 < Saizan> however the important part is about the monad laws
14:35 < dsrogers> it doesn't.
14:36 < dsrogers> I thought it would be simplier if right bind of SetFilter returned an Ok.
14:36 < dsrogers> but it needs to return SetFilter
14:36 < dsrogers> otherwise the monad laws are violated.
14:37 < dsrogers> I even put a comment in justifying the behavior, but it doesn't matter.
14:37 < dsrogers> monad laws come first.
14:37 < koeien> not always :)
14:37 < koeien> in a random number monad i won't care about monad laws
14:37 < Saizan> well, we have to define the equality
14:37 < dsrogers> do doesn't always work right if you don't respect the laws.
14:38 < Saizan> btw, you have Out out a >> SetFilter out' b == Out out' a
14:39 < Saizan> so >> is not associative
14:39 < Saizan> which is another way to say that it doesn't respect the laws :)
14:40 < dsrogers> I think it's more like Ok out a >> SetFilter out' b == Ok out' b
14:40 < dsrogers> but yes.
14:40 < dsrogers> that's where the problem is.
14:41 < Saizan> m = Ok f a; n = SetFilter g b; (m >> m) >> n == n vs. m >> (m >> n) == Ok (f . g) b
14:41 < Saizan> so, what if you return a SetFilter?
14:42 < Saizan> uhm
14:42 < dsrogers> yeah, that's the fix.  My concern was that if you then stuck that return value on the right of a bind or then, it would set the filter /again/
14:42 < dsrogers> but I suppose that's ok.
14:42 < Saizan> i'm not sure it works right
14:43 < Saizan> maybe we need something more like State (Response -> Response) if we want to support setFilter
14:43 < Saizan> ignorePreviousFilters might be doable without
14:43 < dsrogers> yeah, its ok.  If you SetFilter o _ >> Ok o' _ it gives you Ok (o . o') _
14:44 < dsrogers> that's what you want.
14:45 < dsrogers> yep.  WebT is a combo State and Maybe monad.  NoHandle is the maybe behaviors, and the (Response->Response) is the state monad, with some additoinal magic for composing states.
14:47 < dsrogers> do you agree that changing SetFilter out' a' -> return $ SetFilter out' a' is the correct thing to do for restoring the monad laws?
14:47 < Saizan> no, it's different from State, since the (Response -> Response) is all inside while StateT gives you (Response -> m (Response,a))
14:47 < dsrogers> ah, yeah...
14:48 < Saizan> it's more like WriterT (Response -> Response), since (a -> a) is a monoid under composition
14:48 < Saizan> (the Endo monoid in Data.Monoid)
14:48 < dsrogers> our state is a Response->Response.  So state T will give you (Response->Response) -> m ((Response->Response),a) which is like what we have.
14:48 < Saizan> dsrogers: i need to look at it in more detail to be sure
14:50 < dsrogers> ok
14:51  * dsrogers looks up endomorphism.
14:51 < dsrogers> ah.  indeed, that's a better model.
14:54 < Saizan> the old WebT was like ErrorT Response (MaybeT (Writer (Endo Response))) a, plus a run function that applies the Endo Response to the final result
14:55 < dsrogers> What does ErrorT give you?
14:57 < Saizan> Escape
14:57 < dsrogers> ah
14:57 < Saizan> so i think the best way to implement setFilter is to change our Endo monoid to something else with the desired semantic
14:58 < Saizan> it's simpler to check the monoid laws, and we also don't have to deal with the other constructors
14:58 < Saizan> of WebT
14:59 < stepcut> Saizan: make sure to add a unit test for the laws ;)
15:01 < Saizan> stepcut: heh, half of the values are functions but ok :)
15:03 < stepcut> the end user normally provides those functions?
15:03 < Saizan> yes
15:04 < stepcut> maybe you export some functions which the end user can use to easily create unit tests?
15:04 < dsrogers> you could pull out the (.) and have an Ok app out a, where app is a function (Response->Response)->(Response->Response)->(Response->Response) that declares how to combine with the next filter.
15:04 < dsrogers> And SetFilter would become Ok (\x y -> y) () ()
15:06 < dsrogers> and Ok would be Ok (.) out a
15:08 < dsrogers> that makes "app" become our Endo and the filter moves into a StateT where get and set make sense.
15:09 < dsrogers> effectively anyway
15:31 < dsrogers> ok, I have a patch for this.
15:31 < dsrogers> it's much easier to verify the monad laws.
15:32 < dsrogers> do you want to see it Saizan?
15:44 < dsrogers> verifying the monad laws in a general way requires solving the halting problem.
15:50 < dsrogers> hmm, it doesn't obey the second law.
15:51 < dsrogers> ok, the only way I can see to get those constructs seperable is to have a 4th constructor of result and fix what I did to obey the monad laws.
16:18 < mae> h_buildbot: status
16:18 < h_buildbot> Idle.
16:18 < mae> h_buildbot: status
16:18 < h_buildbot> Idle.
16:18 < mae> h_buildbot: build
16:18 < h_buildbot> Build for all started. If one was running, no new one is started.
16:19 < rovar> h_buildbot: so, how are things?
16:19 < h_buildbot> Use: build, status, pause, resume, ping
16:19 < koeien> mae: are you expecting a build?
16:20 < mae> ?
16:20 < mae> i pushed up some patches so yea
16:21 < rovar> h_buildbot: don't be coy.
16:21 < h_buildbot> Use: build, status, pause, resume, ping
16:22 < koeien> mae: ok. it's a bit faster if you either wait for < 5 mins or ask only for the build of ghc-6.10.1 (and ghc-6.8.30
16:22 < koeien> now it's going to build the stable branch first :)
16:23 < koeien> h_buildbot: status
16:23 < h_buildbot> Building ghc-6.8.3_STABLE
16:26 < mae> koeien: yeah ok :) i'll remember that for next time
16:26 < mae> bbl
16:35 < h_buildbot> Build for ghc-6.8.3_STABLE OK. Test suite ran. 15/73 test cases failed. Check http://buildbot.happstack.com/ for details.
16:48 < 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.
17:04 < h_buildbot> Build for ghc-6.8.3 OK. Test suite ran. 16/75 test cases failed. Check http://buildbot.happstack.com/ for details.
17:16 < h_buildbot> Build for ghc-6.10.1 OK. Test suite ran. 16/75 test cases failed. Check http://buildbot.happstack.com/ for details.
17:31 < Saizan> mae: did you take a look at the patches you applied?
18:30 < mae_> Saizan: yes.
18:31 < Saizan> ah, ok then :)
18:32 < mae_> Saizan: you seem to be more in tune with what is going on in them though
18:33 < mae_> Saizan: do you see any problems with them?
18:35 < mae_> Saizan: I guess I just figure we should put stuff like that in sooner before the release -- so we can test them out a bit.
18:35 < Saizan> mae_: do we have a proposed release date for 0.2?
18:36 < mae_> not yet, but I would say early march tentatively
18:36 < mae_> I want to get the code generation tool in, and some test coverage for the multimaster stuff
18:38 < mae_> Saizan: can I leave you in charge of reviewing patches from dsrogers?
18:38 < mae_> since you seem to be more up to speed with what he is doing
18:39 < Saizan> ok
18:55 < mae_> how is everyone doing?
18:55 < Saizan> can someone try to build haddock documentation for happstack-state?
19:00 < mae_> still borked
19:00 < mae_> haddock: internal Haddock or GHC error: Maybe.fromJust: Nothing
19:01 < stepcut> :)
19:01 < Saizan> didn't it work before?
19:02 < mae_> no
19:02 < mae_> it has been broken for awhile
19:02 < mae_> i think it chokes on some TH
19:03 < mae_> but never traced it to find the root cause
19:03 < Saizan> i've some documentation of happstack-state-0.1
19:03 < mae_> hm
19:03 < mae_> was this something that broke after we removed the #ifdef HADDOCK stuff?
19:04 < Saizan> so we've broken it, so we can find the patch and try to infer the related haddock bug
19:11 < mae_> if we could just figure out where it chokes this would help
19:11 < mae_> i couldn't figure out a reasonable way to trace haddock
19:11 < stepcut> $(mkMethods ''RestoreTest ['succValue, 'getValue])
19:12 < stepcut> in happstack-state/tests/Happstack/State/Tests/CheckpointProperties.hs
19:12 < Saizan> that's the culprit? how did you find out?
19:13 < stepcut> trial and error
19:14 < Saizan> ah, in Tests, that was added recently then
19:14 < stepcut> no idea why it makes haddock crash though
19:22 < stepcut> hrm
19:23 < Saizan> the generated code is too weird? :)
19:23 < stepcut> getting closer
19:23 < stepcut> I have a minimal program that causes it to crash, but not when I invoke haddock by hand
19:26 < Saizan> ah, can you paste that somewhere? i'm also working on the .Haddock code in Cabal
19:26 < Saizan> well, i guess you need to share more than one file
19:27 < stepcut> nah, just one file
19:27 < Saizan> how do you call haddock not-by-hand then?
19:27 < dcoutts> Saizan: yes, thanks for that, it's much needed
19:29 < stepcut> damn you hpaste!
19:30 < stepcut> http://moonpatio.com/fastcgi/hpaste.fcgi/view?id=1272#a1272
19:37 < Saizan> stepcut: how do you know that's the cause? it dies with or without both that module and CheckpointProperties.hs in the .cabal for me
19:37 < stepcut> Saizan: you have to comment out Happstack.Tests as well, since it imports CheckpointProperties.hs
19:39 < Saizan> yeah, figured that out :)
19:43 < stepcut> the template haskell code that gets generated is nothing special:
19:43 < stepcut>         instance Happstack.State.ComponentSystem.Methods Happstack.State.Tests.Die.Dummy where
19:43 < stepcut>             { Happstack.State.ComponentSystem.methods _ = [] }
19:49 < stepcut> ok, narrow it down more
19:51 < mae_> hm
19:51 < mae_> maybe it doesn't like that the function is fully qualified?
19:54 < stepcut> no, that is not it
19:57 < stepcut> http://moonpatio.com/fastcgi/hpaste.fcgi/view?id=1272#a1279
20:05 < Saizan> it looks like it dies when the module that defines the macro is being loaded rather than imported from a library
20:05 < Saizan> that's why it works by hand
20:13 < stepcut> could be
20:16 < Saizan> http://trac.haskell.org/haddock/ticket/68
20:17 < stepcut> Saizan: :-/
20:19 < Saizan> so i guess it's #ifdef __HADDOCK__ again? or do we wait for 6.10.2?
20:20 < stepcut> Saizan: if you ifdef out the splice, then it fails to 'check' because functions call undefined things
20:21 < stepcut> Saizan: though, in this particular case, we could consider disabling haddock for the whole test suite ?
20:21 < stepcut> when is 6.10.2 coming out?
20:24 < Saizan> i'm not sure how you can disable haddock for the testsuite
20:25 < stepcut> Saizan: probably not easily unless you are cabal export
20:27 < stepcut> if you just #ifdef out all of Test.hs and CheckpointProperties.hs that might work
20:32 < stepcut> I can do it with #ifdef
20:32 < stepcut> though, __HADDOCK__ does not seem to be defined
20:33 < stepcut> cabal only defines __HADDOCK__ for haddock 1.x :)
20:33 < dcoutts> that's by design
20:33 < stepcut> right
20:34 < stepcut> but what do we do when haddock 2.x isn't really ghc compatible?
20:34 < dcoutts> file bug reports :-)
20:34 < stepcut> besides wait for 6.10.2?
20:34 < stepcut> it's already fixed, just not until 6.10.2
20:35 < dcoutts> I can't think of any workarounds off the top of my head
20:35 < stepcut> well, we can just wait I guess
20:35 < dcoutts> obviously you can build docs yourself, this affects people building their own docs
20:35 < dcoutts> I mean you can provide them on your site
20:36 < stepcut> this works: runhaskell Setup.hs configure -f -tests && runhaskell Setup.hs haddock
20:36 < stepcut> but it would be nice if they showed up on hackagedb
20:37 < Saizan> they won't show on hackagedb unless we finish hackage-server :)
20:38 < Saizan> i guess..
20:40 < stepcut> how is that related?
20:43 < ambrjn> hello there
20:44 < Saizan> stepcut: the documentation is uploaded as a tarball on the server, so it can be built externally
20:45 < Saizan> ambrjn: hi
20:48 < dsrogers> do the type annotations in the comments of an export section matter at all?
20:48 < dsrogers> because in SimpleHTTP.hs some of them are wrong.
20:49 < dsrogers> also, how do you deprecate a function?
20:49 < Saizan> no, they doesn't matter
20:50 < mae_> http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html
20:50 < mae_> see the part that says "WARNING and DEPRECATED pragmas"
20:50 < dsrogers> thanks.
20:50 < mae_>  {-# DEPRECATED f, C, T "Don't use these" #-}
20:50 < mae_> where f, C, and T are export items basically
20:50 < mae_> (constructors or functions)
20:51 < mae_> so it gives an annoying error message when someone uses the function in their lib
20:52 < mae_> so you should say in the deprecated pragma what they should use instead
20:53 < dsrogers> I'm thinking mplus vs multi here
20:55 < stepcut> dsrogers: :-/
20:55 < dsrogers> ?
20:55 < stepcut> those seem pretty different
20:56 < dsrogers> oh, msum v.s multi.
20:56 < stepcut> :)
20:56 < stepcut> that I can approve of
20:57 < Saizan> those better be the same, since i've pushed a multi = msum patch yesterday ;)
20:57 < stepcut> :)
20:59 < dsrogers> Saizan: when combined with my patches for bind, it might be better to define the second case statement of mplus as _ -> a
21:00 < dsrogers> because return a' could alter some meaning.  Though the only way it would matter is a fairly contrived case.
21:00 < Saizan> that's pretty bad though
21:00 < dsrogers> which, mine or yours?
21:01 < Saizan> since with "_ -> a" the 'a' action gets run multiple times, basically
21:01 < dsrogers> ahhh.
21:01 < Saizan> a is an action in the inner monad
21:02 < dsrogers> well.... what if a' is Escape?  or SetFilter?
21:02 < dsrogers> oh I see.
21:02 < dsrogers> nm.
21:02 < dsrogers> the return is for the inner monad as well, isn't it?
21:02 < dsrogers> so it does exactly what you want.
21:03 < Saizan> yeah, you get back the same Result wrapped in the inner monad
21:03  * dsrogers bows before the great Saizan, who's haskell cannot be assaulted 
21:04 < Saizan> i actually just copied the servPlus code from multi without thinking much this time :)
21:05 < gwern> dsrogers: witter would've been something like, '/me surrenders \n Your haskell is best!'
21:06 < stepcut> gwern: did you know that, runhaskell Setup haddock, fails for filestore?
21:06 < Saizan> stepcut: fixed in the stable branch
21:07 < Saizan> of Cabal
21:07 < gwern> stepcut: yes. I did.
21:07  * gwern is starting to suspect macfarlane is living a double life as stepcut - it's almost eery how the two bring up the same exact things
21:07 < stepcut> Saizan: oh, it's a cabal bug?
21:07 < stepcut> :)
21:07 < gwern> yep
21:08 < stepcut> fun
21:08 < gwern> something about paths_* not being generated for the haddock stage
21:08 < dcoutts> that's a separate bug :-)
21:08 < dcoutts> I think it's that we were not passing -i dist/build/autogen to haddock-2.x
21:08 < gwern> oy
21:08 < dcoutts> iirc
21:09 < Saizan> we actually were not looking there when looking for the sources within .Haddock's code
21:16 < dsrogers> what is "ho" for?
21:16 < gwern> with no context, no idea, but haskell.org?
21:16 < dsrogers> Happstack.Server.SimpleHTTP.ho
21:17 < dsrogers> I think i get it now though.
21:21 < Saizan> uhm, it's a bit weird to have it there..
21:21 < dsrogers> agreed
21:51 < dsrogers> where is unrproxify?
21:51 < Saizan> *Happstack.Server.SimpleHTTP> :i unrproxify
21:51 < Saizan> unrproxify :: String -> [(String, String)] -> Request -> Request -- Defined at Happstack/Server/HTTP/Client.hs:44:0-9
22:13 < dsrogers> ok, that's all for me today...
22:30 < h_buildbot> Build for ghc-6.8.3 OK. Test suite ran. 16/75 test cases failed. Check http://buildbot.happstack.com/ for details.
22:35 < h_buildbot> Build for ghc-6.10.1 OK. Test suite ran. 16/75 test cases failed. Check http://buildbot.happstack.com/ for details.
22:52  * Saizan_ >>> sleep
23:26 < h_buildbot> Build for ghc-6.8.3 OK. Test suite ran. 15/75 test cases failed. Check http://buildbot.happstack.com/ for details.
23:39 < h_buildbot> Build for ghc-6.10.1 OK. Test suite ran. 16/75 test cases failed. Check http://buildbot.happstack.com/ for details.
--- Log closed Mon Feb 09 00:00:45 2009