05:55:27 <donri> stepcut: i think optional support for continuation style is definitely something to consider for some future happstack milestone...
05:55:38 <donri> continuations used to suck for web, but html5 makes them feasible i think
05:55:52 <stepkut> :)
05:56:50 <stepkut> reform is pretty clean, so once the proof of concept is worked out, the rest should be easy
05:56:51 <donri> (because we can put the session identifier in the URL and hide it with the history api)
05:57:00 <stepkut> one problem with happstack is that I didn't write it :)
05:57:04 <donri> hm, not sure this is really directly related to reform
05:57:06 <stepkut> though, I am slowly fixing that :p
05:57:28 <stepkut> right, there are also just plain old continuations for all sorts of links
05:57:30 <donri> :)
05:58:01 <stepkut> might have to rename Happstack 8 to be something else :)
06:03:20 <donri> i think it would be interesting to have some kind of web FRP using websockets and/or continuations, coupled with something like ghcjs for seamless interaction of the client and server
06:03:38 <donri> but i don't think i want to completely replace my whole web stack with that approach only, either
06:06:10 <stepkut> I think FRP + ircbot would be cool
06:06:39 <stepkut> but there is not a lot of money in the ircbot market :p
06:06:45 <donri> yea, http is less naturally reactive, though to some extent that's changing
06:07:15 <stepkut> right
06:07:40 <donri> isn't mm_freak the author of fastirc anyway
06:07:52 <stepkut> no idea
06:08:21 <donri> i think so... fastirc, webwire, netwire...
06:08:45 <donri> mr arrow frp guy
06:12:58 <stepkut> i studied frp a little today
06:13:16 <stepkut> trying to figure out what makes reactive tick
06:14:04 <stepkut> got stuck when I couldn't cabal install TypeCompose
06:14:19 <donri> horay for hackage downtimes
06:15:21 <stepkut> there are a lot of types in reactive
06:15:52 <stepkut> ReactiveG, EventG, FutureG, BehaviorG, Fun, Max, and :.
06:16:02 <stepkut> plus a bunch more
06:16:13 <stepkut> but I am trying to get those all in the same module so I can see everything at once
06:16:58 <donri> maybe sodium is simpler?
06:17:38 <donri> netwire is supposed to see a major new release soon, with "arrowized frp done right" according to mm_freak
06:18:09 <donri> though reactive-banana and sodium are based in applicative
06:18:28 <stepkut> soo many choices!
06:18:35 <stepkut> I wanted to do what none of them do
06:18:58 <donri> i'm assuming you've seen http://www.haskell.org/haskellwiki/FRP_explanation_using_reactive-banana ?
06:19:00 <stepkut> I want to create a FRP DSL for creating animations
06:19:10 <donri> haven't read all of that myself though
06:19:29 <stepkut> I've looked
06:19:41 <stepkut> reactive-banana seems a bit ugly when it comes to time-based stuff
06:19:53 <stepkut> which is not good for my particular use
06:28:24 <stepkut> I want to make a little matrix of pixels and then create animations for it using FRP, but the actually animation might be running under HTML5+javascript, etc
10:00:08 <Lemmih> stepcut: I'll see you at ICFP, neat.
11:07:15 <tazjin> Why would combining two JS files (concatenation, same order as before) break a function? >.>
11:07:25 <tazjin> Funnily enough it also gives me a "type error", haha, as if JS had a type system
11:07:39 <donri> :)
11:08:11 <donri> i think concat should have same effect as sequential script src's
11:09:02 <tazjin> Yeah, it should
11:09:05 <tazjin> but it doesn't
11:11:00 <donri> although
11:11:10 <donri> i can imagine a scenario where that might differ
11:12:07 <donri> aren't function definitions available regardless of the where they're defined? but you can also call them at the top-level of a script
11:12:33 <tazjin> They are
11:12:41 <donri> and with script tags, the second file isn't loaded *yet* when the first one is executing
11:13:01 <donri> but with concat, the functions in the second is available during execution of the code in the first
11:13:39 <tazjin> Hmm
11:13:51 <tazjin> Well
11:13:53 <donri> jmacro sort of fixes that by using var f = func instead of func f
11:14:03 <tazjin> I will solve this issue by not solving it and watching Dexter instead
13:29:13 <donri> why do queries need to be made acidic? why can't we have arbitrary queries by mapping functions on the state? i guess it might be a problem with serialization when using networked backends... maybe cloud haskell will solve that with the "remotable" functions?
13:30:52 <luite> cloud haskell just stores the function name and serializes the arguments
13:32:26 <donri> hm, maybe what exists today but the plans are grander i think?
13:32:31 <donri> with the proposed "static" keyword
13:37:42 <luite> yeah, not sure about progress there though
13:38:11 <donri> i'm just thinking for the future, "would be nice to have"
17:18:28 <stepkut> alpounet: what's the status of the clckwrks pretty url patch?
17:59:44 <stepcut> Lemmih: yup~!
17:59:45 <lambdabot> stepcut: You have 2 new messages. '/msg lambdabot @messages' to read them.
18:00:19 <stepcut> donri: do you have a patch for the prettier derivePathInfo stuff ? Or did we only discuss the ideas
18:01:32 <donri> stepcut: i sent you the patch for "foo-u-r-l"
18:01:32 <stepcut> "donri asked 6m 2d 6h 43m 7s ago: to merge http://paste.pocoo.org/raw/CPcBpzi7fgFeWY7rAwhD/ if he feels like it mkay"
18:01:36 <stepcut> =O
18:01:45 <donri> lol
18:02:01 <donri> that was for the old website
18:02:15 <stepcut> :)
18:04:53 <donri> also wtf lambdabot? :P
18:08:30 <stepcut> I think web-routes should have a TH function a bit like mkYesod that can generate the route table
18:08:44 <stepcut> though I think you would need to create your URL type using GADTs to make that happen
18:08:55 <alpounet> stepcut, haven't been able to work on it these last few days. summer jobs, sun, beach, y'know.
18:09:12 <alpounet> i have to take a look at your modifications to boomerang and use that in my code
18:09:18 <alpounet> will try to get that done before i go to spain
18:10:10 <stepcut> k
18:10:33 <donri> stepcut: you want a quasiquoter for web-routes?
18:10:47 <stepcut> donri: that is a separate issue
18:10:56 <donri> what do you mean then
18:11:30 <stepcut> donri: $(mkRoute ''SomeRoutes) would generate, route url case url of Home -> getHome ; foo -> getFoo, etc
18:12:01 <stepcut> also.. the RouteT type should perhaps include the current URL in the ReaderT
18:12:11 <stepcut> not sure why I didn't do that already
18:12:47 <donri> how is mkRoute better than pattern matching on url in your own route function=
18:13:02 <donri> still can't pass arbitrary arguments to individual handlers?
18:13:05 <stepcut> well, if your function is all boilerplate, then it is just boilerplate
18:13:22 <stepcut> it would be optional, of course
18:13:32 <donri> sure, i just don't see what it adds at all
18:13:43 <stepcut> you don't have to write a route function..
18:14:14 <stepcut> mostly, it makes it easier to do side-by-side comparisons of happstack vs yesod :)
18:14:20 <donri> so instead of "route Home" you write "getHome =", not a big win
18:14:34 <donri> you get string programming instead of haskell powah?
18:14:37 <stepcut> but, also, like derivePathInfo, it allows you to start with some simple TH and then migrate to custom code later, if you need it
18:15:20 <stepcut> well, in the current code you have to write, route Home = getHome, and then implement the getHome function. With mkRoute you would only have to implement getHome
18:15:39 <donri> yes but why would you want getHome instead of route Home in the first place
18:16:10 <stepcut> you want to put all the route handling code directly in the route function ?
18:16:19 <donri> why not?
18:16:33 <stepcut> because it gets unreadable fast and hard to find what you are looking for
18:16:36 <stepcut> I used to do it that way
18:16:48 <stepcut> I am so much happier now that I actually make separate functions for each route
18:16:52 <donri> shrug ok
18:17:12 <stepcut> you can do it whichever ways pleases you though
18:17:25 <donri> just seems to me like doing, someFunc (Just x) = someFuncJust x; someFunc Nothing =someFuncNothing
18:18:10 <stepcut> I usually create one module per page on the website
18:18:20 <stepcut> having a single route function that is thousands of lines long is a big mess
18:18:28 <stepcut> gotta make  food, be back later
18:18:42 <donri> only gain i can see is jump to tag in the editor, because getHome is distinct from route x
18:19:24 <stepcut> donri: that is one
18:19:29 <donri> stepcut: huh but it's not thousands of lines long is it? i guess i'm thinking you have one Site per "module"
18:19:42 <stepcut> donri: nothing you say will convince *me* to switch back to that old method
18:19:43 <donri> and thus one route func per module
18:20:00 <donri> oh, just trying to understand you for myself
18:20:38 <donri> i guess that is the answer: you have a single Site with code scattered across multiple modules
18:21:45 <stepcut> well, I do tend to also divide the code up into subsites
18:21:45 <donri> even then though, it just means you don't need to import qualified ...
18:22:08 <stepcut> like in clckwrks there are separate route URLs for the admin stuff, each plugin, etc
18:23:50 <stepcut> anyway, I have no intention of preventing the use of other styles :)
18:23:51 <donri> although actually... you'd still have a "route" function for each Site, that you'd need to import qualified to nestURL
18:25:57 <donri> stepcut: you could just generate "routeHome" instead of "getHome" and rely on the existing stuff for method routing instead of GADTs?
18:26:18 <donri> routeHome = do method GET <|> do method POST...
18:26:31 <donri> or do you even split those up into different modules
18:26:39 <stepcut> perhaps.. but that is more work for the user?
18:26:51 <stepcut> haven't worked out the details yet
18:26:53 <stepcut> lunch, bbiab
18:27:03 <donri> more work but more power... it's a tradeoff i guess
18:27:23 <donri> like how do you generate a handler that handles two methods?
18:28:06 <donri> i guess you can move the common code to a utility function and use in both handlers
18:29:13 <donri> but, that's the kind of thing i like happstack for over yesod; i can just write what comes naturally in the moment and refactor as needed. but yea you did say this'd be optional :)
20:37:02 <mm_freak> hi there
20:37:50 <mm_freak> as promised i'm trying out happstack again…  it doesn't seem much different from snap from a usage standpoint, except that it's missing some minor convenience features and snaplets
20:38:35 <stepkut> mm_freak: which convience features?
20:39:04 <mm_freak> so if happstack 8 includes an equivalent to snaplets with the same ease of use i might switch back to happstack
20:39:20 <stepkut> spiffy
20:39:21 <mm_freak> stepkut: minor stuff like i mentioned, the command line interface, etc.
20:39:24 <stepkut> k
20:39:35 <stepkut> I'm not against adding that stuff :)
21:46:22 <stepkut> donri: did you actually test this pretty patch to web-routes?
21:47:04 <stepkut> donri: I started monkeying with it before testing it, but I don't think it actually works..
21:47:40 <stepkut> also, verbatimize does not seem necessary -- and they way it is being used seems even more wrong
21:47:53 <stepkut> segment (pack $(stringE (verbatimize $ nameBase conName)))
21:48:12 <stepkut> calls vebatimize on the name of the constructor..which is already capitalized
21:50:02 <donri> i don't remember :)
21:50:50 <stepkut> it should call prettify when it shows the url, and then prettify again on the argument to 'segment' so that it can match on what was previously generated
21:53:46 <donri> i think conName in that position is actually a name taken from the URL
21:54:01 <stepkut> nope
21:54:38 <stepkut> it comes from parseInfo
21:54:47 <stepkut> and is a Name value
21:55:06 <stepkut> we pass, [(Name, Int)] to both toPathSegmentsFn and fromPathSegmentsFn
21:55:09 <stepkut> I fixed this already
21:56:01 <donri> i might have misunderstood how it was working
21:56:20 <stepkut> yeah
21:56:26 <stepkut> I'm guessing you didn't test :)
21:56:38 <stepkut> anyway, this is better, because you don't have to write an inversion function
21:57:04 <stepkut> you could even use an SHA1 sum or something (pigeons be damned)
21:57:10 <donri> are there tests?
21:58:42 <stepkut> not really
21:59:02 <stepkut> in Web.Routes.QuickCheck we provide, pathInfoInverse_prop, which can be used to check that PathInfo instances are valid
21:59:12 <stepkut> but we are not currently running any tests with that
21:59:22 <donri> i remember being very confused about how it all fit together
21:59:26 <donri> TH is difficult to follow :P
21:59:29 <stepkut> yes
22:03:34 <stepkut> part of the trick to TH is to use :set -ddump-splices
22:03:50 <donri> i guess i was trying to generate code like, fromPathSegment path = $(verbatimize path), but it makes more sense to do, fromPathSegments ($(prettify cons)) = cons  -- pseudo TH
22:04:07 <stepkut> the other trick is to drop LSD
22:04:15 <donri> \o/
22:04:34 <donri> i was thinking in code more than meta-code
22:04:38 <stepkut> right
22:05:22 <stepkut> you could check that , ConName == $(verbatimize thePathSegment)
22:06:02 <stepkut> having prettifier + verbatimize makes it possible for verbatimize to understand multiple formats
22:06:39 <stepkut> for example.. running verbatimize on an already verbatimize value is idempotent
22:06:52 <stepkut> so then it would make "foo-bar" or "FooBar" acceptable
22:07:18 <stepkut> but.. then you have multiple URLs for the same resource.. which is apparently unRESTful
22:07:42 <stepkut> the advantage of the prettifier-only solution is that you only have to write one function, not a function and its inverse
22:07:47 <stepkut> so less code, and fewer things to go wrong
22:08:25 <donri> yea
22:10:26 <stepkut> so I am going to go with that
22:22:30 <stepkut> donri: ok, I pushed a patch. Not on hackage yet because I need to generate the haddock docs
22:22:37 <stepkut> plus I want to look into adding mkRoute first
23:01:30 <donri> nice :)
23:01:31 <donri> bedtime
23:04:48 <mm_freak> stepkut: i'm implementing the CPS-based idea right now =)