14:07:04 <tazjin|work> Hrmm, I'm suddenly getting a ton of "Could not deduce (Control.Monad.State.Class.MonadState[...]" for the data type holding my Acid State
14:07:12 <tazjin|work> this just started happening .. ideas?
14:07:44 <donri> show relevant code
14:08:32 <tazjin|work> http://hpaste.org/67707 <-
14:09:06 <tazjin|work> this worked without any problems until, well, I didn't change anything.
14:09:56 <stepcut> how many versions of mtl does, ghc-pkg list mtl, show ?
14:10:23 <tazjin|work> 2.0.1.0 and 2.1.1
14:10:35 <tazjin|work> Which of the two should I hide?
14:11:56 <stepcut> it's not a matter of hiding, per se.. but I suspect that your acid-state was built against 2.0.1.0 and your app is using 2.1.1
14:12:37 <tazjin|work> Hmm, the package base is relatively new on this box. Let me check on Hackage which mtl version acid-state currently installs
14:12:57 <tazjin|work> Apparently no specific version
14:13:00 <stepcut> yeah
14:13:06 <stepcut> and mtl 2.1 is pretty newish
14:13:24 <stepcut> so.. my guess is that you recently installed something else that pulled in mtl 2.1
14:13:42 <stepcut> if you do, ghc-pkg unregister mtl-2.1.1, it will tell you it can't do that because some packages depend on it
14:14:37 <stepcut> your best long term plan is probably to make sure everything is built against 2.1, otherwise it will keep getting reinstalled
14:15:04 <stepcut> moving locations, be back in 20
14:15:25 <donri> tazjin|work: are you building your app with cabal?
14:15:40 <tazjin|work> donri: Normally yes, but not when testing in ghci ;-)
14:16:09 <donri> cabal-dev ghci :)
14:18:04 <donri> tazjin|work: have you looked at data-lens-fd?
14:18:24 <donri> you don't seem to be using the state api of lenses
14:22:24 <tazjin|work> I used it as demonstrated in the Crash Course, lets see
16:17:33 <stepkut> I need a better name for this type, data SessionData sessionData = Unread | NoChange sessionData | Modified sessionData  | Expired
16:17:47 <stepkut> SessionData is too useful of a name to waste on that type -- plus it is not a great name for it anyway
16:24:25 <alpounet> stepkut, SessionState? SessionStatus?
16:27:19 <donri> are we exporting that type?
16:30:36 <stepkut> donri: we are, for the sake of runSessionStateT
16:32:23 <donri> but we should keep naming things badly for sake of historic consistency
16:32:28 <donri> WebT I'm looking at you
16:36:33 <stepkut> :)
16:36:45 <stepkut> I'll get to WebT later
16:36:58 <donri> you get them!
16:36:59 <stepkut> first plan is to get these high-level libraries into a stable state
16:37:04 <stepkut> then work on acme-http
16:37:13 <stepkut> then examine the routing combinators
16:37:38 <stepkut> then look at ServerPartT and what we actually want out of a web monad (and if we want a web arrow as well..)
16:37:41 <alpounet> planning on making H8 the fastest web framework?
16:37:42 <mightybyte> We already got to WebT. :)
16:37:51 <stepkut> alpounet: of course!
16:37:54 <donri> acme-http wishlist: websockets, spdy
16:37:56 <stepkut> alpounet: but, also the most correct!
16:38:07 <alpounet> stepkut, yeah, kind of the perfect web framework
16:38:10 <stepkut> alpounet: or.. the most provably correct
16:38:40 <stepkut> SessionStatus could work
16:38:40 <alpounet> tricky to keep performances at the top in the same time
16:38:43 <luite> are you still going to work on grammar based testing?
16:38:52 <stepkut> luite: yup
16:39:10 <luite> cool, though that won't help much proving correctness of course :p
16:39:35 <stepkut> alpounet: no... correctness and speed are not in conflict
16:39:48 <stepkut> luite: o rly?
16:39:55 <luite> stepkut: well it's testing, not proving
16:40:02 <stepkut> luite: sure
16:40:08 <alpounet> stepkut, well, actually, from what i've seen, a lot of people care about one or the other, but not that often either
16:40:12 <donri> testing against a formal grammar
16:40:27 <alpounet> of course they do a bit, but they don't spend weeks profiling the code base when they mostly care about correctness
16:40:37 <stepkut> luite: I am going to explore if there is some way to use agda to actually prove anything
16:40:58 <luite> "Program testing can be used to show the presence of bugs, but never to show their absence!" <- obligatory Dijkstra quote :p
16:41:45 <stepkut> alpounet: one reason I am interested in the stronger testing/proving is that low-level performance code tends to be trickier and less 'obviously correct'
16:41:52 <luite> donri: well, the idea of grammar based testing is to generate more relevant test cases based on the grammar, ir am i understanding it wrong
16:41:55 <luite> ?
16:42:22 <alpounet> stepkut, yeah, that's an interesting approach
16:43:03 <luite> stepkut: that would be nice, but sounds tricky. I only know a bit of HOL though, not much other experience with theorem provers.
16:43:05 <stepkut> luite: yes, the idea a grammar based testing is to show that the tests do actually cover all the cases
16:43:32 <donri> luite: that's how i understood it too. and you're right it's not quite "proving" in the usual sense, but i think it's not "just testing" either.
16:44:44 <stepkut> looking at a simpler problem.. can you prove that && works correctly by writing tests?
16:45:23 <stepkut> for my purposes.. the answer is yes.. if you show that every possible input has the correct output.. I would consider that a valid 'proof'. But mathematically speaking.. I have no idea if that counts
16:45:28 <luite> donri: right, it does sound a bit like some paper i had to present for a programming/correctness course, where the idea was to automatically generate test cases that cover all branches for primitive recursive functions
16:46:51 <luite> stepkut: well in this case the number of inputs is actually really limited, so you can prove by exhaustion, which actually is valid
16:47:10 <luite> but with grammar based testing, you don't exhaustively test
16:47:32 <luite> you could probably make it easier to work it into a complete proof if you have all interesting cases tested
16:49:29 <stepkut> right
16:49:38 <luite> (don't know if that's that interesting though in practice, but having a good http test suite would be a really nice thing to have)
16:50:07 <stepkut> since many things in http can have unlimited length/repetition, you could never test exhaustively
16:50:26 <luite> but i think that in practice, you'd never be able to verify the implementation in agda, only a model
16:50:43 <stepkut> you would need to use some level of induction to suggest that it probably works for any number of repetitions
16:51:43 <stepkut> luite: perhaps. One option would be to generate the Haskell code from an Agda program
16:51:52 <stepkut> luite: but.. then you have to prove that your generator is correct ;)
16:52:10 <luite> right :)
16:54:19 <luite> anyway i'm quite interested in these things, but i always find it difficult to see how they work out in practice, since i'm myself only able to prove trivial things. if you succeed you could probably write some paper about it :)
16:55:23 <stepkut> luite: yeah.. it is definitely experimental..
16:55:56 <stepkut> luite: but, so is using Haskell in the first place :p
16:57:09 <luite> right :)
16:57:52 <luite> i always feel a bit nervous about blog posts like dbpatterson's comparing haskell to some mainstream language
19:20:47 <Ngevd> Is there an opposite of "trailingSlash"?
19:21:33 <donri> guardRq $ \rq -> last (rqUri rq) /= '/'
19:22:47 <Ngevd> Thanks
19:23:07 <donri> perhaps we should add a noTrailingSlash
19:23:15 <Ngevd> I'd support it
19:23:26 <stepcut> donri: i was just typing the same thing
19:23:33 <stepcut> it has been requested more than once
19:23:35 <donri> \o/
19:23:51 <stepcut> well, the question about the opposite of noTrailingSlash has been asked more than once
19:24:28 <donri> i'll add it?
19:25:07 <stepcut> sure!
19:25:13 <Ngevd> :)
19:25:21 <stepcut> I am finishing up the docs for ClientSession and adding HSX.QQ to hsx
19:25:30 <donri> nice
19:28:02 <donri> stepcut: http://darcsden.com/dag/happstack/patch/20120427192723-6eb02
19:29:20 <stepkut> pulled! It will be in the next release
19:29:23 <stepkut> which should be soon
19:29:51 <donri> oh crap i forgot something, hold
19:30:14 <stepkut> :-|
19:30:19 <stepkut> not that soon ;)
19:30:25 <donri> haha
19:30:59 <stepkut> actually.. this is the only patch to happstack-server since the last release..
19:31:14 <donri> http://darcsden.com/dag/happstack/patch/20120427193032-6eb02
19:31:17 <stepkut> most of the work has been going on elsewhere
19:31:20 <donri> ^ me being stupid
19:31:28 <stepkut> :)
19:31:31 <stepkut> I have done that more than once
19:31:42 <donri> :)
19:32:23 <donri> ghc *does* help: Warning: Defined but not used: `noTrailingSlash'
19:32:27 <donri> but easy to miss without -Werror
19:45:47 <Ngevd> Could you change the type signature of Happstack.Lite.asContentType to String -> FilePath -> ServerPart String?
19:46:33 <stepkut> Ngevd: I did..
19:46:36 <stepkut> ACTION double checks
19:47:05 <stepkut> http://hackage.haskell.org/packages/archive/happstack-lite/7.1.1/doc/html/Happstack-Lite.html#v:asContentType
19:47:33 <donri> rather, you changed the type of serveFile
19:47:39 <Ngevd> Aaaah
19:47:47 <stepkut> ah yes
19:47:53 <donri> which has the same effect :)
19:47:56 <stepkut> http://hackage.haskell.org/packages/archive/happstack-lite/7.1.1/doc/html/Happstack-Lite.html#v:serveFile
19:47:59 <stepkut> I knew I changed something
19:48:14 <stepkut> I could be convinced to change it again though
19:48:59 <donri> duno, this way you can't use the request to select the mimetype, but you don't need to liftIO (and if you need the former, you can use happstack-server)
19:49:16 <stepkut> donri: yeah..
19:49:33 <stepkut> i think that is why I have fileServe the type i did in the first place
19:49:34 <donri> so i think the current types are most consistent with the goals of "lite"
19:49:36 <stepkut> maybe I should go the other way..
19:50:46 <donri> or even make it a pure (FilePath -> String)
19:50:48 <donri> shrug
19:51:12 <stepkut> pure is no good
19:51:17 <stepkut> you might want to use libmagic or something
19:51:26 <stepkut> maybe libmagic is pure.. but you get the idea
19:51:29 <donri> with lite?
19:51:41 <stepkut> sure
19:51:59 <donri> also maybe export guessContentTypeM + mimTypes or remove the references to those from the haddock
19:52:04 <stepkut> I don't think it makes it all that harder to understand
19:52:26 <stepkut> k
19:53:57 <donri> actually we could clean up those haddocks in general... "NOTE: alias for serveFileUsing filePathSendFile" "see also: defaultIxFiles" not very useful to lite users
19:55:15 <donri> i keep typoing luite
19:55:27 <stepkut> heh
19:55:39 <donri> happstack-luite
19:57:28 <luite> my own happstack, that would be neat!
19:57:50 <stepkut> everyone should have their own happstack!
19:59:27 <Ngevd> Ooh, this reminds me, I need to do the docs for my family tree library
20:00:03 <luite> is it a red-black tree?
20:00:33 <Ngevd> Family trees, most annoyingly, aren't trees
20:00:51 <stepkut> are they acyclic graphs?
20:00:54 <stepkut> ACTION ponders
20:01:02 <stepkut> I guess.. no
20:01:17 <Ngevd> They're graphs with some stupid restrictions
20:01:25 <donri> yo DAG
20:02:13 <stepkut> if you come from royalty.. it's more like the family bamboo shoot?
20:02:34 <Ngevd> If you come from royalty, it's like a family grouse-bush
20:02:41 <stepkut> ah
20:02:42 <Ngevd> Have you seen some of their family trees?
20:02:47 <stepkut> yeah
20:12:22 <stepkut> anything else I should change in happstack-lite before I make another release?
20:13:41 <stepkut> otherwise I have happstack-lite 7.2.0 ready for release!
20:16:48 <stepkut> Lemmih: If I kill the server while I checkpoint is being written corrupting the checkpoint.. what is the expect behavior on restart?
20:22:20 <stepkut> getting the {-# LANGUAGE #-} pragma to show up in haddock comments is.. tricky
20:23:20 <tazjin> I'm intending to create a small screencast today about creating a blog with Happstack, web-routes, acid-state and hamlet. What do you think I should use to demonstrate authentication? Is the clientsession package ready for this? :P
20:23:37 <stepkut> clientsession does not do authentication
20:24:00 <stepkut> happstack-authenticate does.. though I have never tried to integrate it with hamlet
20:24:16 <stepkut> but if you can easily embed blaze-html into hamlet.. it should not be too hard
20:24:32 <tazjin> Yeah, you can natively embed it since hamlet works on top of blaze
20:24:32 <stepkut> and if it is.. I am willing to fix happstack-authenticate so that it is not :)
20:24:40 <stepkut> right, that is what I was thinking
20:24:51 <stepkut> oh. ugh..
20:25:00 <stepkut> thinks are slightly complicated at the moment hough
20:25:02 <stepkut> though
20:25:20 <tazjin> Why?
20:25:20 <stepkut> happstack-authenticate uses blaze-html 0.2 because I don't like digestive-functors 0.3
20:25:43 <stepkut> and so, I need to patch happstack-authenticate to not use digestive-functors at all.. which is what I am supposed to be doing today
20:25:58 <stepkut> but instead I am submitting patches to hsx, creating hsx-qq and patching happstack-lite :p
20:27:04 <tazjin> Hrrm
20:27:35 <tazjin> I don't feel like implementing a real authentication/session management thing works well in a screencast that demonstrates how to create a blog fast and easy
20:28:44 <stepkut> ah
20:28:48 <stepkut> let me think
20:28:57 <stepkut> do you need to implement login at all then?
20:29:30 <tazjin> Well, I need a way to add blog posts
20:29:40 <stepkut> right.. but you could start by allowing anyone to add blog posts
20:29:53 <tazjin> _
20:30:19 <stepkut> you could start by dividing your routes into Admin AdminURL | others
20:30:26 <stepkut> but, not actually secure the Admin route..
20:30:39 <stepkut> and then later show how to secure Admin
20:30:55 <tazjin> Yeah, hrrmm
20:31:24 <stepkut> using client session for authentication would be a bit.. odd I think
20:31:57 <stepkut> not really sure how it would help anything
20:32:25 <stepkut> if you want to allow login.. then you need a list of accounts on the server-side and some way to present authentication credentials
20:32:36 <stepkut> after that you just need a cookie to indentify the user?
20:33:07 <tazjin> You mean I should just not do encryption?
20:33:14 <tazjin> That would be a possibility, I guess
20:33:25 <stepkut> well, for encryption you should use happstack-server-tls
20:33:47 <stepkut> which is independent from authentication
20:33:47 <tazjin> People will weigh this against the Yesod screencast on creating a blog though, but in my opinion Happstack is more of a "library" for web development, while Yesod is more of a fully fledged web framework
20:34:07 <stepkut> tazjin: well.. you may want to wait a bit then
20:34:30 <stepkut> though, perhaps not
20:34:59 <stepkut> I think.. this would be a good screencast
20:35:00 <donri> stepkut: uh if you just do a normal cookie the user can put "admin" there?
20:35:02 <tazjin> How about BrowserID, do we have a nice implementation for that?
20:35:06 <donri> this is exactly what clientsession is for?
20:35:24 <stepkut> donri: well, normally you would put some really big random number in there..
20:35:37 <donri> or just use clientsession? :)
20:35:51 <stepkut> donri: I guess that is where you could use clientsession.. but it seems wrong somehow
20:36:03 <donri> seems like exactly the point to me
20:36:12 <donri> what would you use it for?
20:36:23 <tazjin> What donri says was actually exactly what I was thinking
20:36:30 <donri> what you're talking about is basically server sessions
20:36:32 <stepkut> I'm not sold on the security of storing data in a cookie that you don't want the user to read
20:36:52 <stepkut> but.. clientsessions are what is available today
20:37:00 <donri> we're just putting the user id or name in there
20:37:02 <donri> not that secret :)
20:37:07 <stepkut> serversessions are coming next :)
20:37:15 <stepkut> donri: well. secrets -- or things they are not allowed to change
20:37:37 <donri> i don't see how a random number is more secure than all the stuff in clientsession
20:37:44 <stepkut> I'm not sure that it is :)
20:38:02 <stepkut> maybe we should be using the sessionid from the underlying ssl connection?
20:38:08 <donri> or just put a random id in clientsession!
20:38:17 <stepkut> or digest-auth?
20:38:19 <donri> when less is *not* more
20:38:40 <donri> stepkut: so, what have we been making happstack-clientsession for then?
20:39:38 <stepkut> donri: it's useful.. even if you don't fully trust the encryption aspect
20:39:44 <donri> is the ssl id persistent between request?
20:39:55 <stepkut> donri: hmm. good question..
20:40:19 <stepkut> it's been a long time since I read about low-level ssl
20:40:35 <stepkut> anyway, clientsession is probably the best choice available today
20:40:40 <stepkut> especially when I release it later today ;)
20:40:45 <donri> my point exactly :)
20:40:54 <donri> i agree server sessions may be more interesting in the long run
20:41:36 <stepkut> I guess I am reluctant to 'official' prompt any sort of authenication/security measures at the moment.. because they are tricky to get right.. and I don't want to get caught with my pants down :)
20:41:41 <donri> though clientsessions might still have uses, for example for zomg horizontal scaling of apps where not every request must access an acid-state anyway
20:41:48 <stepkut> 'officially'
20:41:59 <donri> :)
20:42:24 <stepkut> that is one reason why happstack-authenticate is not on hackage yet
20:42:25 <donri> tazjin: just blog that stepkut said to use http basic auth and that ssl is overrated
20:42:33 <stepkut> I would like to have some sort of security audit done
20:42:35 <Ngevd> Officially caught, or officially with your pants down? :P
20:42:38 <tazjin> Okay :3
20:43:00 <tazjin> I'll also say that it's secure anyways if your wifi network is encrypted with WEP
20:43:04 <tazjin> to further underline my point
20:43:23 <donri> exactly!
20:43:38 <stepkut> tazjin: WEP :p
20:44:04 <donri> wholly encrypted protocol
20:44:15 <tazjin> and there's no reason to encrypt passwords in the server's database, for all we know the users can't access it directly anyways!
20:45:01 <stepkut> tazjin: anyway, if you mention that the authetication system is just a placeholder, and not intended for real world usage, then that should be fine :)
20:45:02 <donri> well since acid-state is in-memory there's no need for any encryption or hashing
20:45:08 <donri> obviously.
20:45:10 <stepkut> donri: :p
20:45:12 <Ngevd> tazjin, trust
20:45:17 <tazjin> [22:40:55] <stepkut> anyway, clientsession is probably the best choice available today
20:45:17 <tazjin> [22:41:00] <stepkut> especially when I release it later today ;)
20:45:23 <tazjin> stepkut: I thought it was released already?
20:45:34 <donri> updates!
20:45:37 <Ngevd> I don't like feeling that I can just access all the passwords to all the users of my service
20:45:38 <stepkut> tazjin: yes, but a new version with some API changes is coming out
20:45:48 <stepkut> tazjin: the API is done in darcs, just finishing the haddock docs
20:45:52 <tazjin> Is the new version tested, at least a bit?
20:46:04 <stepkut> tazjin: yes.. there is even a working demo now
20:46:15 <tazjin> Okay, cool. Where's the repo? I'll just use that
20:46:36 <stepkut> it's in the normal happstack repo in the happstack-clientsession directory
20:46:41 <tazjin> Okay
20:46:50 <stepkut> darcs get http://patch-tag.com/r/mae/happstack
20:48:20 <tazjin> My biggest issue with darcs is the speed of the get command
20:48:40 <donri> Ngevd: we were being silly
20:50:08 <Ngevd> I know, hence the ":P"
20:50:14 <Ngevd> The silliest emoticon
20:50:28 <donri> i meant re <Ngevd> I don't like feeling that I can just access all the passwords to all the users of my service
20:50:35 <Ngevd> Aaaaah
20:50:41 <stepkut> tazjin: yep. And the lack of a good alternative to github
20:50:59 <donri> tazjin: ^C to be lazy? :)
20:51:27 <tazjin> donri: Git would do a full checkout with the entire history in the time that darcs needs to even get to the part where you ^C
20:51:49 <donri> truth
20:51:56 <donri> there's some work being done there though
20:52:11 <donri> 2.8 has preview support for some speedups over http i think
20:52:23 <parcs`> well if you git clone from an http repo you will get poor performance too
20:52:38 <donri> parcs`: still better i think, because heavy packing
20:52:59 <parcs`> significantly better?
20:53:04 <tazjin> current happstack-clientsession from the happstack repo doesn't compile for me
20:53:05 <donri> haven't measured
20:54:17 <stepkut> tazjin: what error ?
20:54:55 <tazjin> http://pastebin.com/V1YRwbjD
20:57:22 <stepkut> ok, hsx-qq is now available, but I want niklas to pull it into patch-tag.com/r/nibro/hsx-qq and make that the official repo before I release it on hackage, http://src.seereason.com/hsx-qq/
20:57:36 <stepkut> now onto happstack-clientsession
20:57:52 <stepkut> tazjin: what version of GHC ?
20:58:00 <tazjin> 7.2.2
20:58:03 <tazjin> does it require 7.4?
20:58:11 <stepkut> i hope not
20:58:26 <stepkut> probably just an explicit type signature
20:58:31 <stepkut> one moment
20:59:16 <stepkut> another shining example of why we need scoutess
20:59:24 <donri> 7.2? that's a strange ghc to be using these days
21:00:27 <donri> i get the same on 7.0.4 btw
21:00:59 <tazjin> Why is 7.2 strange?
21:01:17 <donri> it was sort of a preview for what was to become 7.4
21:01:27 <stepkut> if you add, listen' :: m (a, s) -> m ((a, w), s) and pass' :: m ((a, w -> w), s) -> m (a, s), does it work?
21:01:28 <donri> there was never any haskell-platform for 7.2
21:01:59 <stepkut> 7.2 was a tech preview release because they usually make a major release right before ICFP, but could not get it done in time this year
21:02:04 <stepkut> at least that is my understanding
21:02:48 <stepkut> I think the official recommendation was to stick with 7.0 and wait til 7.4 unless you want to play with the new stuff
21:03:18 <donri> builds for me with those
21:03:21 <stepkut> k
21:03:23 <tazjin> stepkut: It compiled
21:03:27 <stepkut> sweet
21:03:28 <stepkut> I'll add them
21:03:47 <donri> 7.4 being smarter?
21:04:10 <stepkut> no idea
21:05:05 <donri> btw idea re scoutess: before doing complete rebuilds, on a commit just build inside an existing env and only do full build if that passes
21:05:13 <donri> because full builds tend to take several minutes
21:05:33 <tazjin> stepkut: btw, I think you should add the function to happstack-hamlet that turns the (url -> [(Text, Maybe Text)] -> ) into a (url -> [(Text, Text)] -> ..)
21:05:55 <stepkut> tazjin: agreed
21:06:14 <stepkut> especially since it does not add a dependency on web-routes
21:06:28 <tazjin> yeah
21:06:38 <tazjin> but *if* somebody wants to use web-routes with Hamlet it becomes necessary
21:06:43 <stepkut> right
21:07:05 <stepkut> though I wish I could find the place in the yesod empire that made me switch to [(Text, Maybe Text)] in the first place
21:07:24 <tazjin> ;P
21:08:26 <donri> this worked for me with lucius: https://github.com/dag/happaste/blob/b5c2e4e68f6957a16e921f63f5c87af5f1cacd4f/src/Happaste/Types.hs#L138
21:08:29 <stepkut> ok, I pushed a patch for happstack-lite-7.2.0. let me know if there is anything else I should change before releasing it
21:08:46 <stepkut> donri: ooo
21:09:08 <stepkut> donri: is Lucius cool? I have not had time to evaluate all the various CSS libraries and pick a favorite
21:09:14 <stepkut> I just write static .css files still :-/
21:09:20 <donri> note that type Lucius url = (url -> [(Text,Maybe Text)] -> Text) -> Css
21:09:40 <stepkut> perhaps I should rename happstack-hamlet to happstack-shakespeare and support hamlet/lucius/etc ?
21:09:43 <stepkut> ah
21:09:52 <donri> stepkut: i find lucius a little rigid when you want to do fun refactoring stuff
21:09:57 <stepkut> k
21:11:01 <donri> stepkut: but compared to static css it's better
21:12:49 <donri> luite: d'ya know why lucius and hamlet are different here?
21:12:57 <donri> our resident yesodian
21:14:17 <stepkut> http://hackage.haskell.org/packages/archive/http-types/0.6.10/doc/html/Network-HTTP-Types.html#t:QueryText
21:14:50 <stepkut> that is where I picked up the Maybe Text from I think
21:15:00 <luite> donri: hmm, dunno
21:15:01 <tazjin> stepkut: Every static CSS file is a valid Lucius file, you just get the added benefit of automatic minification etc.
21:15:34 <luite> donri: what's the difference you're talking about?
21:15:38 <donri> do you? i thought that was a separate part of yesod
21:15:52 <stepkut> of course.. if I am going to support web-routes+hamlet a little.. maybe I should support it a lot ?
21:16:13 <tazjin> luite: Hamlet expects a function of type (url ->  [(Text, Text)] ->)
21:16:22 <tazjin> luite: Lucius threw that "Maybe" in there somewhere
21:16:44 <stepkut> right now the only thing in happstack-hamlet is:
21:16:45 <stepkut> hamletToResponse :: (url -> [(Text, Text)] -> Text) -- ^ function to 'url' values in the template into their 'String' representation
21:16:45 <stepkut>                  -> HtmlUrl url  -- ^ a 'Hamlet' template
21:16:45 <stepkut>                  -> Response
21:16:50 <luite> hmm, that's interesting
21:17:00 <donri> luite: nevermind
21:17:07 <stepkut> should I just change that function to take,  (url -> [(Text, Maybe Text)] -> Text) ?
21:17:09 <donri> tazjin: actually, it seems to work with Maybe here
21:17:18 <stepkut> I could I can export the conversion function as well..
21:17:53 <tazjin> The hamletToResponse function is a bit superfluous I think
21:18:07 <tazjin> donri: Doesn't for me
21:18:09 <donri> [hamlet| <p>Hi |] :: (url -> [(Text,Maybe Text)] -> Text) -> Html
21:18:11 <donri> ^ that works fine for me
21:18:25 <donri> same without Maybe
21:18:29 <tazjin> What version of hamlet do you have?
21:18:42 <donri> 1.0.1.1
21:19:01 <tazjin> 1.0.1 here, wonder if something changed in *.1
21:19:12 <donri> doubtful
21:19:13 <stepkut> on my sytem I have:
21:19:14 <stepkut> type HtmlUrl url = Text.Hamlet.Render url -> Html
21:19:27 <stepkut> and .. the type of Render is not exported so I have no idea what it is :-/
21:19:30 <stepkut> how nice!
21:19:34 <donri> yes, it infers (t0 -> Html)
21:19:36 <luite> so it's both [(Text,Text)] right?
21:19:41 <luite> Hamlet and Lucius?
21:19:45 <donri> but with added type information it accepts Maybe
21:20:06 <stepkut> http://hackage.haskell.org/packages/archive/hamlet/1.0.1.1/doc/html/src/Text-Hamlet.html#HtmlUrl
21:20:13 <stepkut> type Render url = url -> [(Text, Text)] -> Text
21:20:46 <luite> right that looks the same as the one in shakespeare-css
21:21:15 <donri> i think it just ignores that argument so any type works
21:22:05 <stepkut> oh.. I have an idea
21:22:16 <donri> tazjin: how was it failing for you?
21:22:36 <luite> donri: it probably doesn't output an explicit type sig with TH
21:22:43 <tazjin> Couldn't match expected type [(Text, Text)]with actual type [(Text, Maybe Text)]etc.
21:22:52 <donri> tazjin: how are you rendering it?
21:23:00 <tazjin> (yeah, not the exact error, but you know)
21:23:17 <tazjin> well if I have a template :: HtmlUrl Sitemap (with Sitemap being the type holding the web-routes)
21:23:24 <donri> ah there's your problem
21:23:38 <tazjin> What, that I'm actually using web-routes?
21:23:49 <donri> you don't hve to use the HtmlUrl type
21:23:55 <donri> it's fixed to Text
21:24:44 <tazjin> Let me try something
21:25:09 <donri> you can make your own, type Template = (Sitemap -> [(Text,Maybe Text)] -> Text) -> Html
21:25:48 <stepkut> yeah
21:26:13 <donri> that's why it was working with lucius for me because i wasn't using the provided CssUrl type synonym
21:26:30 <tazjin> Ah, I see
21:26:59 <stepkut> so.. I am not sure what to do in happstack-hamlet
21:27:35 <donri> stepkut: could provide a new HtmlUrl to match happstack customs
21:28:06 <donri> or really web-routes, but yea
21:28:06 <tazjin> Should probably call it something different though
21:29:25 <stepkut> yeah.. too many choices
21:29:32 <donri> tazjin: so is it working now without the conversion function?
21:29:36 <stepkut> I am not sure how significant the type HtmlUrl is in the first place..
21:29:40 <tazjin> Yeah
21:29:55 <donri> stepkut: not significant at all, just creates confusion as evident :)
21:30:15 <donri> perhaps a note in the haddocks would suffice
21:30:37 <tazjin> I don't think happstack-hamlet is needed anymore then
21:31:06 <donri> true... it's just blaze Html anyway which already has an instance
21:31:32 <donri> web-routes-hamlet might be more interesting a package
21:31:48 <tazjin> donri: What would you put in there?
21:32:05 <tazjin> We just need the askRouteFn function which we've already got, nothing else is needed
21:32:10 <stepkut> donri: yeah.. I think happstack-hamlet is obsolete.. but web-route-hamlet might be useful
21:32:12 <donri> the glue for askRouteFn and all that
21:33:13 <donri> perhaps even a new quasi-quoter so you don't have to wrap it in a monad yourself
21:33:24 <stepkut> :-/
21:33:36 <donri> why the frowny face
21:33:50 <stepkut> would rather just fix HSX and ditch Hamlet entirely :)
21:34:03 <donri> hah agreed, but if we're doing hamlet at all ...
21:34:14 <stepkut> someone who actually uses hamlet needs to tell me what they actually want
21:34:32 <tazjin> I switched my blog over to Hamlet yesterday and I don't feel like anything is needed
21:34:35 <stepkut> I do agree that happstack-hamlet is kind of obsolete. It even says so in the comment :)
21:34:41 <tazjin> besides a short chapter in the crash course which I'm working on already
21:34:46 <stepkut> yeah
21:35:17 <stepkut> based on your blog post, my only feeling is that a help function that calls askRouteFn for you might be nice
21:35:22 <stepkut> but certainly not essential
21:35:37 <donri> well what I'm thinking is hamlet in RouteT
21:35:57 <stepkut> donri: right..
21:36:04 <stepkut> is it really worth it?
21:36:26 <donri> i don't see how else you could nicely handle askRouteFn
21:36:27 <stepkut> maybe we want to deprecate happstack-hamlet, and just have sections in the crash course showing how to use hamlet and hamlet + web-routes
21:38:34 <donri> i suppose we could just have a function that takes the hamlet template
21:38:44 <donri> but from there it shouldn't be hard to provide a new QQ to do that in one go ...
21:38:55 <stepkut> sure
21:39:05 <stepkut> for web-routes-hamlet?
21:39:09 <donri> yea
21:39:20 <stepkut> well. I would take a patch, but I am not going to write it
21:39:24 <donri> k :)
21:39:26 <stepkut> due to time constraints
21:39:34 <donri> +1, focus on stuff I care about
21:39:34 <stepkut> gotta fix a bug in HSX.Transform
21:39:44 <donri> which doesn't really include hamlet 0:)
21:39:48 <stepkut> :)
21:40:07 <stepkut> I care about hamlet a little bit
21:40:10 <stepkut> just not a lot
21:48:07 <tazjin> I've decided to leave out the authentication/session part
21:48:09 <tazjin> in the screencast
21:48:34 <tazjin> I'll just say that Happstack (and Snap) are a little more low-level than Yesod in that regard, and there might be another screencast later that touches these topics
21:49:16 <stepkut> tazjin: you should say that happstack-authenicate is an optional component of happstack and you will cover it separately :p
21:49:32 <tazjin> But what if I never do? :P
21:49:50 <stepkut> and that you will cover again separately if you get enough paypal donations
21:51:01 <tazjin> > PayPal
21:51:01 <tazjin> urgh
21:51:02 <lambdabot>   Not in scope: data constructor `PayPal'
21:51:08 <tazjin> Oh shut up lambdabot
21:51:12 <stepkut> heh
21:51:43 <tazjin> PayPal isn't really known for being a nice and trustworthy company
21:52:13 <stepkut> oh that reminds me.. I have to paypal someone some money
21:52:34 <stepkut> because if I write them a check they will lose it
21:55:26 <tazjin> I've never written anyone a check, I don't think that's very common here in Europe
21:58:05 <stepkut> I don't write many
21:58:32 <stepkut> the address on my checkbook is from 4 or 5 residences ago, and the bank no longer exists :p
21:58:47 <stepkut> but the checks are still good.. I swear!
21:59:04 <tazjin> Yeeah . sure
21:59:15 <stepkut> ok, I am going to take the silence as a sign that happstack-lite-7.2.0 is awesome and ready to go
22:00:26 <stepkut> and I am doing nothing on happstack-hamlet until I get some clear direction from someone who knows what is up
22:04:00 <tazjin> ok
22:04:22 <stepkut> oh right, I am going to rename SessionData to SessionStatus.. but that probably won't affect your screencast
22:04:34 <stepkut> but if you wait a few minutes I can push a patch
22:05:27 <tazjin> I haven't started the screencast yet
22:05:39 <tazjin> I'm writing this thing once before to see which parts can be simplified
22:06:05 <tazjin> Also I'll leave out sessions, so it won't ;-)
22:06:33 <stepkut> ah yeah :)
22:13:44 <tazjin> Would you mind if I called Happstack a web library instead of a framework?
22:13:47 <tazjin> I still think that term fits better
22:14:13 <stepcut> it's more like a collection of libraries
22:15:09 <tazjin> Yeah, okay
22:15:11 <donri> i like to think of it as a "toolkit"
22:15:18 <tazjin> toolkit is great
22:16:52 <stepcut> sure
22:17:18 <stepcut> ecosystetm
22:18:04 <stepcut> cult
22:19:37 <donri> all glory to the hypnostack
22:19:55 <stepkut> heh
22:19:55 <tazjin> that is
22:20:01 <tazjin> I think we should take that as a new motto
22:20:58 <stepkut> the boundaries of happstack are a bit vague.. like web-routes, acid-state, and hsx, are all independent from happstack as well as optional :-/
22:21:20 <stepkut> but.. I use them, so I consider them part of happstack :)
22:30:17 <stepkut> hmm. making the client session be an instance of SafeCopy is actually really sweet
22:30:25 <stepkut> because you get version migration
22:30:30 <stepkut> suck it yesod!
22:30:41 <stepkut> .. unless they have version migration too :)
22:30:50 <donri> :)
22:31:59 <stepkut> in theory we might want to force migration to dirty the session data so that the migrated  version gets sent to the client.. but migration is too transparent for us to know that it happened at the moment
22:35:09 <luite> stepkut: no yesod just has text->text maps, i think it will see some changes when the caching framework is implemented
22:35:34 <stepkut> ah
22:36:03 <donri> stepkut: well as soon as you put a new session it'll be migrated right?
22:36:18 <stepkut> what will the caching framework cache ?
22:36:24 <luite> i haven't really heard any requests for non-text sessions
22:36:42 <stepkut> donri: yes. it is only a problem if you never put.
22:37:19 <stepkut> luite: well.. no one requested an iPhone before they made one :p
22:37:37 <stepkut> though.. penny from inspector gadget had a ipad/iphone way back in the day..
22:37:40 <stepkut> and I did want one of those..
22:38:35 <luite> stepkut: it will make the per-request cache more typesafe and probably some longer duration caches. it's mainly to support things like widgets that require expensive db lookups, or remote data, but that don't need to be refreshed for every request
22:40:08 <stepkut> how generic is it supposed to be?
22:41:18 <luite> generic enough ;)
22:41:56 <stepkut> I dunno..
22:42:52 <luite> the idea is to have the cache keys tagged with the value type so the cache doesn't get type variables or constraints for things stored inside it
22:43:32 <stepkut> tagged in what way?
22:43:36 <luite>  Key Int
22:43:40 <luite> stores an int in the cache
22:44:42 <luite> similar to vault, but there keys are generated in an IO action, so you can't have top-level keys
22:44:44 <stepkut> so, the cache is basically a Map SomeHash Dynamic stored in a TVar or something?
22:45:04 <luite> right
22:45:04 <stepkut> and any 'Key a' can be turned into a SomeHash somehow?
22:45:22 <luite> right, with Typeable
22:45:49 <luite> i don't know if there's a better way with fewere constraints, haven't found any
22:47:21 <luite> but the question is still whether to just support plain keys, or to have a more elaborate setup that also stores the result of lookups that require some parameters
22:47:22 <stepkut> don't think so
22:47:57 <luite> anyway once the type of keys has been decided, they can be used for session lookup as well
22:48:26 <stepkut> so, you can store keys of different types in the same cache, right ?
22:48:32 <luite> yes
22:49:35 <stepkut> are you going to enforce any type-safety checks for whether a Key type might appear in the cache?
22:54:38 <luite> haven't really thought about whether it's possible to have constraints for specific cache types, but i think it should be
22:55:25 <luite> obviously a session type map would need to be serializable
22:56:06 <stepkut> oh ?
22:56:08 <luite> strictly speaking, if you want to allow as lmuch flexibility as possible, it wouldn't
22:57:15 <luite> but one of the goals is to not let the session backend "pollute" the types of the whole application too much
22:58:59 <luite> and i think some serializability is not really a problematic assumption, if you don't have that, you cannot share session data between servers
22:59:54 <luite> so bad luck for the user with a small-scale webapp who wants to store MVars directly in sessions :p
23:00:49 <stepkut> if you want to share between servers.. hassle Lemmih to finish replication for acid-state
23:01:07 <luite> how would you replicate non-serializable types?
23:01:20 <stepkut> you can't
23:01:24 <luite> rihgt
23:01:42 <stepkut> but once you have serialization and replication and transactions.. you have acid-state ;)
23:02:33 <luite> except that acit-state doesn't have replication?
23:02:35 <luite> acid
23:02:44 <stepkut> not yet
23:03:03 <luite> anyway i don't see serializability as a harmful restriction whatsoever
23:03:04 <stepkut> but the problems faced by acid-state replication and cache replication are pretty much the same I think
23:03:13 <stepkut> I don't either
23:03:20 <luite> oh no replication is planned for caches
23:03:48 <luite> neither for sessions, at least not directly in the front end, only in the back end
23:03:54 <stepkut> yes.. and I am saying, you should just stick the cache in acid-state and then add replication to acid-state
23:04:49 <luite> i'm not sure that would gain us much
23:05:50 <luite> the point is heterogenous maps (with some api to restrict lifetime and size) with unique keys
23:05:52 <stepkut> if acid-state already supported replication you could just stick a Map in acid-state and be 90% of the way there..
23:06:25 <stepkut> if you can serialize it.. you can stick it in acid-state
23:06:33 <luite> does acid-state help with type-tagged keys?
23:06:55 <stepkut> no.. that is a feature of the type you stick in acid-state
23:08:51 <luite> right, but i don't understand the point of acid-state: the point of the cache is to have some Map with a nice interface around it. sure you can stick the map in acid-state, but then the only thing you gain is persistence, and perhaps replication, while the cache is intended for things that should not be persisted for a long time
23:09:32 <stepkut> then do it your way :)
23:12:03 <luite> nothing is final btw, felipe wants to just do per-request caches
23:12:36 <stepkut> per-request ? It only spans the duration of a single request?
23:12:40 <luite> yeah
23:12:54 <stepkut> why would you need replication then?
23:13:03 <stepkut> oh..
23:13:10 <stepkut> he doesn't want replication..
23:13:27 <luite> uh i never said we would need replication, only if you want session storage in the same map, then clientsession would require it
23:13:29 <stepkut> what is the point of per-request caches? Why would you query the same data more than once in a single request
23:13:50 <luite> for example authentication stuff that requests information about the current user
23:14:09 <stepkut> Wouldn't State be sufficient for that ?
23:14:12 <luite> it's easier to make modular code if you just lookup through some cache
23:14:52 <stepkut> this sounds supiciously like global state
23:15:06 <luite> does it? how is it more global than State ?
23:15:11 <stepkut> I just want to do some IO call and magically get my answer back
23:17:17 <luite> a common use case is a page with 10 widgets, where all those widgets are rendered slightly differently (edit buttons for example) if the currently logged in user is an admin
23:17:17 <stepkut> I dunno.. I'm not sold on the idea ye
23:17:20 <stepkut> yet
23:18:02 <luite> the cache makes it possible to easily supply some cached lookup function that gets the user details only once per request
23:20:04 <luite> maybe there's a better way, but say you have some generic widgets that do something expensive
23:20:15 <stepkut> where does this cache live?
23:20:31 <luite> then they can make some Key that's somehow unique, calculate that expensive thing at most once per request
23:20:44 <luite> this particular lives in the Request
23:20:58 <stepkut> inside on IORef or something?
23:21:11 <stepkut> yikes
23:21:21 <stepkut> inside of an IORef or something?
23:21:25 <luite> probably
23:22:32 <stepkut> ah.. IORefs and QuasiQuotation.. the yesod way! :p
23:23:18 <luite> that's the old version that's not quite type safe
23:23:48 <luite> but do you really have a better idea?
23:24:16 <stepkut> no.. I am increasingly less clear on what it is you are actually hoping to do
23:25:34 <stepkut> so instead I am going to finish this documentation and release a new happstack-clientsession
23:26:35 <luite> the point is to make things more modular: allow a widget library writer to say that some value should be cached, at least for the duration of a request
23:26:58 <luite> without introducing any constraints on the user application type
23:40:59 <luite> perhaps there is a better way and i should wait for happstack to implement it properly first ;p
23:46:43 <stepkut> :)
23:47:37 <stepkut> I've been more interested in longer-lived (and possibly replicating) caching
23:49:18 <stepkut> I am curious how much data exists that is useful multiple times in a single request, but not across multiple requests
23:50:03 <stepkut> seems like user details would have a longer shelf-life than a single request
23:50:41 <luite> once you go longer than a request, you'd have to deal with expiration, logging out
23:50:44 <stepkut> yeah
23:51:22 <stepkut> I have yet to want this sort of feature.. I wonder what I am doing wrong
23:51:38 <luite> probably you're using acid-state
23:51:42 <stepkut> :)
23:51:57 <luite> dunno if that's wrong, but it does mean no replication :p
23:52:00 <stepkut> just cache everything!
23:56:23 <stepkut> when should I use getKey vs getDefaultKey?
23:57:21 <luite> uh you can always use getKey if you want?
23:57:50 <stepkut> how do I generate the file that I pass to getKey?
23:58:23 <luite> oh i think that might get generated automatically if it doesn't exist
23:58:52 <stepkut> getDefaultKey definitely generates a file.. it is just given you control over the filename?
23:58:58 <luite> yeah
23:59:42 <stepkut> oh I see
23:59:48 <stepkut> it is even in the docs
23:59:53 <stepkut> I thought I looked there already