00:25:06 <stepcut> donri: it's up again, there is a watch dog that will reboot it after a minute
00:25:20 <stepcut> donri: site code is creeping ever closer
00:26:02 <donri> :)
01:10:35 <tazjin> Urgh, done with the elm QuasiQuoter. Time to call it a day. Night!
01:13:09 <donri> show us
01:13:35 <donri> is the idea to generate js with a haskell-like language using qq?
01:18:45 <stepcut> tazjin: sounds neat!
01:19:06 <donri> oh hey elm's server uses happstack-server
01:19:09 <tazjin> Well, have you seen elm on /r/haskell lately?
01:19:13 <stepcut> donri: yup!
01:19:24 <stepcut> donri: hope to do some more exploration about it sometime
01:19:44 <tazjin> I felt like it needed better integration with both Happstack and Yesod, so I wrote a small example how to use it with Yesod
01:20:04 <tazjin> then I noticed that type-safe URLs don't play along well with not being able to interpolate variables, so a QuasiQuoter was needed :p
01:21:31 <tazjin> Evan hasn't merged it into the main branch yet, so it's available in my fork at https://github.com/tazjin/Elm
01:21:51 <tazjin> Example here: https://github.com/tazjin/Elm/blob/master/Examples/elm-yesod/Main.hs
01:23:50 <tazjin> and Elm source with interpolated variables (ll 29-31) https://github.com/tazjin/Elm/blob/master/Examples/elm-yesod/elm_source/index.elm
01:30:04 <donri> stepcut: random thought; perhaps the new server should be designed from the ground up as a "rest server" by which i mean for example that "routing" should support both method and headers like accept, and respond with the correct status codes on failure... not sure if it's relevant to the server, the framework or individual apps but, just a thought.
01:31:02 <donri> nothing prevents you from doing it already with happstack 7, but MonadPlus works against you though so you'd need to reimplement a lot that could perhaps be either in the server or "framework"
01:31:13 <stepcut> donri: sounds interesting.. classically, the problem has been that the type system is not powerful enough
01:31:54 <stepcut> but.. the type system is getting more and more awesome :)
01:32:15 <stepcut> Also, I did prototype a way to extend web-routes using GADTs so that you could specific the request methods for each constructor
01:32:35 <donri> sounds cool
01:32:51 <stepcut> I am not sure if that is really a win or not.. I don't find myself using the wrong request methods
01:32:54 <donri> though not sure what that would do for URL building?
01:33:05 <stepcut> one moment
01:33:12 <donri> i suppose you *could* use it for forms if you control both action and method attributes
01:33:39 <stepcut> right, hold on
01:34:16 <donri> then again forms only support GET and POST in html
01:34:22 <donri> even html5 :(
01:35:10 <stepcut> https://groups.google.com/group/yesodweb/msg/3002f88fbb8a0964
01:37:55 <donri> oh right, methods in the types. i was misinterpreting constructor to mean the value constructors.
01:38:11 <donri> which in hindsight would be kind of useless/insane
01:38:22 <stepcut> heh
01:38:57 <stepcut> my biggest issue with type-safe urls right now is dealing with contexts where you want to call 'showURL' but there are several different URL types that you want to pull from
01:39:19 <stepcut> but, I think that could work like the HasAcidState class or something
01:39:30 <stepcut> I have not had time to explore it.. but it will be a top priority soon
01:39:37 <stepcut> after I finish dealing with the acid-state stuff probably
01:41:07 <donri> i'd love to be able to expose the happstack-yui Sitemap and allow users to use showURL for it outside implYUISite... is that what you're talking about?
01:41:24 <stepcut> not sure
01:41:54 <stepcut> the easiest example I can think of is if you had a site that uses http and https and you wanted separate URL types for http vs https
01:42:09 <stepcut> so that you could not accidently generated a http path for a https-only url
01:42:46 <donri> isn't it good enough to have some API for overriding the URL generated for a route?
01:42:53 <donri> also for CDNs etc
01:43:14 <stepcut> there are other uses cases as well
01:43:15 <donri> or do you feel it is risky when it's not separate types
01:43:39 <stepcut> if you have a site with plugins, then plugins need to be able to generates routes for themselves, the base site, or the possible other plugins they depend on
01:43:53 <stepcut> but.. when you are developing the plugin itself, you do not have access to the top-level route type
01:44:02 <stepcut> only some of the sub-routes
01:44:40 <stepcut> with the current web-routes stuff -- that works fine -- as long as you only want to generate URLs for the current component
01:45:14 <stepcut> but, when you want to generate routes for the parent or other child components-- you have to pass in the showRouteFn functions by hand and pass them around instead of just calling, showURL Foo
01:45:18 <stepcut> very clunky
01:45:32 <donri> yea
01:45:43 <donri> maybe that's a workaround i could use in happstack-yui though for now
01:45:47 <stepcut> that, and initialization/shutdown are two of the biggest issues with creating a plugin architecture
01:45:58 <donri> return a tuple of the serverpart and the routeFn
01:46:42 <stepcut> sounds feasible
01:46:50 <donri> well, the response
01:47:29 <donri> or, hum... :p
01:50:10 <donri> not sure web-routes exposes enough for that to be possible without reimplementing some parts
01:50:28 <stepcut> well, nothing in web-routes is set in stone
01:50:50 <stepcut> nothing anywhere in the happstack ecosystem is, in fact
01:50:52 <donri> implYUISite gets the domain and approot which it passes to implSite which gives back a serverpart
01:50:58 <stepcut> aside from trying our best to do it right
01:51:02 <donri> i have a Site, but it knows not of domain and approot right?
01:51:26 <stepcut> yeah
01:51:31 <stepcut> those get added by runSite
01:51:31 <donri> sure but i was hoping to do this without having to wait for changes "upstream" ;)
01:51:53 <stepcut> though, in one application I had to create a SitePlus where I did include those values..
01:52:08 <stepcut> which is a hack indicating that something is not quite right I think
01:53:15 <donri> so what i need to do is get the formatPathSegments from my Site and then construct the routeFn function myself from that and the domain and approot?
01:53:58 <stepcut> that sounds similar to what I had to do
01:54:18 <stepcut> not pretty
01:54:51 <donri> and less pretty in hsp too... unless you make your own web-routes-hsp for it too :p
01:57:31 <stepcut> :)
01:57:44 <stepcut> pretty is important
01:59:58 <donri> it's not a critical issue for yui because usually you'll point to the routes at most twice (css and js in <head/>) but still, if you change the parameters you pass to implYUISite you will get no errors and the links will not update for you
02:00:15 <stepcut> yeah.. not great
02:02:13 <donri> also if you upgrade happstack-yui to something with a new bundled version of yui, you'll still be pointing to the old version which isn't served anymore but might be cached in browsers
02:02:27 <stepcut> gross!
02:02:30 <donri> (they're neverExpires with yui version included in URL for cache-busting)
02:02:51 <stepcut> you should file a bug with all those notes so that we can explore them in detail next time we look at web-routes
02:06:27 <stepcut> but.. now it is time to practice violin
02:06:32 <donri> cool!
02:06:39 <stepcut> so, everyone start practicing!
02:08:48 <donri> stepcut: http://code.google.com/p/happstack/issues/detail?id=206 like that?
02:09:05 <stepcut> great
02:10:53 <donri> perhaps if i expose the boomerang sitemap as well users could have like, data Sitemap = YUI Y.Sitemap | ..., sitemap = rYUI . "yui" </> Y.sitemap <> ...
02:11:03 <donri> and then <script src=(YUI ComboHandlerURL)/> ?
02:12:37 <donri> when i wrote the code i think i was thinking i didn't want to mess with users sitemaps... but that might be the cleanest solution
02:13:15 <donri> oh right, then you also have to have them thread it in in their route function... three places to thread in yui...
02:14:12 <donri> guess i could keep that optional
02:17:47 <donri> https://github.com/dag/happstack-yui/issues/3
02:40:34 <stepcut> violin practice: done
02:40:38 <stepcut> now time for some FM synthesis
02:41:28 <donri> silly workaround for hsx+overloadedstrings: quasiquotes! most string interpolation packages return either Text or work with IsString directly, without needing overloaded strings
02:41:48 <stepcut> the best work-around is to install hsx from darcs, where that is fixed
02:41:53 <donri> :)
02:41:57 <stepcut> I complained to niklas that he did not release it on hackage yet
02:42:15 <stepcut> betime
02:42:17 <stepcut> bedtime
02:42:22 <donri> good night
05:12:11 <plat0> donri: thanks, started using language-css
09:05:16 <HugoDaniel> hi
10:02:48 <Lemmih> Sigh, I have one of the best jobs I can imagine and still I'm bored.
10:03:06 <srhb> Tried drugs?
10:03:08 <srhb> ;)
10:03:20 <Lemmih> Yes, actually. (:
10:03:30 <srhb> Well, if that won't cut it you're doomed.
10:15:18 <HugoDaniel> Lemmih: have you though about fishing in cape verde ?
10:15:24 <HugoDaniel> *thought
10:18:36 <Lemmih> I can honestly say that fishing in cape verde has never crossed my mind.
10:21:23 <HugoDaniel> well, thats my dream job :/
10:59:55 <Lemmih> Going to Mars would be fun, though.
11:00:12 <stepkut> Lemmih: on a one way mission?
11:00:49 <HugoDaniel> http://gizmodo.com/5913858/these-are-the-reactions-of-an-iss-astronaut-to-spacexs-dragon
11:00:51 <donri> @time stepkut
11:00:52 <lambdabot> Local time for stepkut is Tue May 29 06:01:39 2012
11:00:53 <luite> dunno, i heard that ping times from mars are pretty terrible :p
11:01:01 <stepkut> donri: :)
11:01:01 <donri> you're up early :p
11:01:05 <stepkut> yup
11:01:20 <stepkut> have house guests for the next month and they go to bed at a sensible hour -- like 10PM
11:01:47 <donri> i went to bed at a sensible hour yesterday. sensible in  your time zone that is.
11:02:01 <stepkut> Lemmih: have you thought about adding replication support to acid-state ;)
11:02:04 <stepkut> donri: heh
11:02:17 <Lemmih> stepkut: If it wouldn't get in the way of my plans to live indefinitely, sure.
11:02:32 <Lemmih> stepkut: So much thought, so little time.
11:02:32 <stepkut> Lemmih: :)
11:03:06 <stepkut> Lemmih: i am going to look into the problem with running out of file descriptors on startup soon
11:05:48 <Lemmih> Oh my precious Flow, where art thou?
11:06:16 <stepkut> heh
11:07:24 <donri> Lemmih: ritalin!
11:09:51 <alpounet> ketamin!
19:22:00 <donri> stepcut: "mpure" in lieu with msum etc
19:22:38 <stepkut> donri: perhaps.. but that might imply it has something to do with Monoids
19:22:52 <stepkut> where-as mapM, filterM, pureM, mean something about monads?
19:24:43 <donri> msum, mplus, mzero, mfilter, but i guess those are all about a specific monad not monads in general
19:25:34 <stepkut> oh, right, msum is monads, I was thinking of mconcat/mempty/mappend
19:25:37 <donri> actually pureM doesn't really make sense either... the type doesn't end with m a
19:25:50 <stepkut> yeah
19:26:03 <donri> ACTION likes "monadically"
19:26:44 <donri> "frm", like "arr" ;)
19:26:51 <stepkut> well, arr is already taken
19:26:55 <stepkut> oh
19:26:55 <stepkut> sorry
19:27:24 <donri> toForm, like toHtml
20:17:33 <tazjin> Hah, successfully built an elm example application with web-routes and URL interpolation. I'll add this as an example to the Elm repository later :-)
20:35:28 <stepcut> nice!
20:35:43 <stepcut> I definitely want to check out elm more
20:36:13 <stepcut> would an happstack-elm library be useful? I know elm currently depends on happstack-server, but.. maybe there is more we could be doing?
20:51:10 <tazjin> Elm itself doesn't depend on anything besides blaze
20:51:51 <tazjin> I've restructured it a bit so that the compiler is separate from the server (I think Happstack might cause dependency issues with Snap or Yesod users, and I generally like it when things are modular)
20:52:08 <tazjin> I'm not yet sure what the best way to integrate Elm with Happstack would be
20:52:46 <tazjin> The default compiler function returns (Html, Html, String) --(body, CSS, JS)
20:53:24 <tazjin> We can already use blaze html without any issues in Happstack, I'm not sure how sensible an elm-hsp package would be considering that elm does the entire site generation
20:54:52 <stepcut> I see a dependency on happstack-server, http://hackage.haskell.org/package/Elm-
20:55:30 <tazjin> Yes, that's not the current version though
20:55:39 <stepcut> ah
20:55:53 <tazjin> https://github.com/evancz/Elm/blob/master/elm/Elm.cabal
20:55:59 <stepcut> well, I am definitely interested in making sure it works well with happstack, cuz I had javascript :)
20:56:26 <kstt> had you ?
20:56:41 <stepcut> hate
20:56:50 <stepcut> sorry, too many conversations at once
20:58:15 <stepcut> tazjin: the CSS is still an Html tag? Is that just a <style> tag with all the CSS in it ?
21:01:51 <stepcut> sounds like there is room for some some sort of happstack-elm, even if it is just a function or two
21:02:49 <tazjin> Yep
21:02:58 <tazjin> well, elm-yesod is just a single function as well
21:03:25 <tazjin> https://github.com/tazjin/Elm/blob/master/elm-yesod/Language/Elm/Yesod.hs
21:04:15 <stepcut> i think using blaze with happstack is fine. I don't see an advantage of using HSP if the whole page is auto-generated
21:04:23 <tazjin> The Happstack version would have to take care of the things that happen in a Yesod widget, i.e. a bit more than just elm-yesod
21:04:32 <stepcut> like what?
21:04:38 <tazjin> Yesod widgets also set the page title, embed the JS library in the right header position etc.
21:04:41 <donri> blaze makes sense for things like rendering syntax highlighting
21:04:56 <stepcut> how does it generate the title ?
21:05:02 <tazjin> The elm-happstack function needs to do those things, i.e. apply some kind of default-layout
21:05:26 <tazjin> well, basically Yesod has a defaultLayout function which conists of the basic HTML structure (<html>, <head> and <body> tag)
21:05:31 <stepcut> seems like we just need a, elmTemplate :: (Html, Html, String) -> Html, function ?
21:05:41 <tazjin> this layout embeds ^{pageBody} ^{pageHead} and ^{pageTitle}
21:05:51 <tazjin> and all Yesod widgets called in the handler are inserted at the appropriate positions
21:05:55 <stepcut> yeah.. HSP has a defaultTemplate function, but there is no blaze one.. but its just a few lines of code
21:06:01 <tazjin> Yep
21:06:10 <tazjin> So yeah, I think the switch to HSP for this would not make sense
21:06:33 <stepcut> appropriate? the css and javascript just have to appear i the <head> tag, right ? what other positional information is important?
21:07:03 <tazjin> Well, a widget has the functions toWidgetBody and toWidgetHead and whatever you throw into those is always inserted at the intended position
21:07:12 <tazjin> But that part is static for elm, so that will be hardcoded
21:07:28 <stepcut> yeah
21:07:33 <stepcut> what about the title?
21:07:49 <tazjin> So, things that need to be passed into the elmTemplate function: The title, the position of the elm-min.js file and the elm source code
21:08:26 <tazjin> if type-safe URLs are used the handler needs to pre-render those (see the elm-yesod example, line 58 https://github.com/tazjin/Elm/blob/master/Examples/elm-yesod/Main.hs )
21:09:01 <tazjin> Okay, I'll write this up and see how it turns out.
21:09:07 <tazjin> Is Snap blaze compatible?
21:09:18 <tazjin> If yes I could just create elm-blaze
21:09:24 <stepcut> there is a bunch to embed blaze into heist
21:09:29 <stepcut> in xmlhtml perhaps
21:09:34 <donri> heist has a function for rendering blaze to heist
21:09:40 <donri> yes it might be there
21:09:41 <tazjin> Hrrm, I haven't looked at Heist at all yet
21:10:16 <stepcut> I don't find heist all that interesting.. you still have to write haskell code in many cases, and you just get less type-safety..
21:10:46 <donri> i'm not sure what elm-blaze would bring
21:10:58 <donri> if it already compiles to a full html
21:11:06 <tazjin> It's not a full html
21:11:22 <tazjin> it's just the content div and the dispatcher function, as well as the actual javascript that needs to be in the head
21:11:26 <tazjin> not the whole HTML document
21:11:30 <tazjin> (oh, and the CSS of course)
21:12:32 <stepcut> right.. does it make sense to embed the CSS and JS into the html directly, or is there some reason to put the .js and .css in external 'files'
21:12:45 <tazjin> https://github.com/tazjin/Elm/blob/master/elm/src/GenerateHtml.hs
21:12:49 <stepcut> doing external seems tricky
21:13:01 <tazjin> Yes, at the moment the css is static, but that might not be the case for long
21:13:18 <tazjin> the elm library is external, of course
21:13:21 <stepcut> k
21:14:06 <stepcut> so, it seems like we can use generateHtml to generate a Html, and then we just need to use serveFile or something to serve the static .js file. Or maybe even file-embed?
21:14:36 <stepcut> a smarter version could cache the results of compilation?
21:15:00 <stepcut> gotta run, bbiab
21:16:57 <kstt> stepcut: a nice usage of heist is to allow users to create new html content at runtime, with the ability to use a library of powerful splices (photo gallery, pagination, summary ...).
21:17:48 <kstt> in which case heist contents usually don't live in a static directory of files
21:18:40 <stepcut> kstt: I'll have to think about that
21:18:47 <kstt> in my opinion, this is the direction heist should take, because at the moment it insists that there should be a static directory of heist files, which almost defeats the main advantage of runtime flexibility.
21:19:21 <stepcut> kstt: I think I would rather have plugins working reliably
21:21:10 <tazjin> Ah, nothing else is needed. I totally forgot that Language.Elm exports the generateHtml function now. I'll write a new example quickly
21:22:43 <donri> kstt: hint under safe haskell + external hsp? :)
21:23:03 <donri> heist might be better suited for end-users though, i admit
21:47:45 <tazjin> Okay, stepcut: https://github.com/tazjin/Elm/tree/master/Examples/elm-happstack
21:50:04 <tazjin> also donri :]
21:51:10 <tazjin> If you want to try it, clone the current version of elm from https://github.com/tazjin/Elm/tree/master/elm and use that
21:58:24 <stepcut> tazjin: neat.
21:58:52 <stepcut> so.. what would we want to do to make it into a library
21:59:20 <tazjin> Nothing, I think
21:59:33 <tazjin> this example uses the plain Language.Elm module, so ...
22:00:00 <tazjin> I like the elmResponse function, but an entire library for that? Hrm, it can easily be defined in some file somewhere
22:00:10 <tazjin> also because the URL for the elm-min.js file will vary
22:00:36 <stepcut> where would that 'somewhere' be?
22:00:48 <stepcut> for the .js file.. it could use file-embed ?
22:00:57 <stepcut> or, serveFile ?
22:01:10 <stepcut> or, maybe it just needs a section in the crash course?
22:01:13 <tazjin> with somewhere I meant inside the user's project
22:01:20 <tazjin> yeah, a simple crash course section would probably be enough
22:01:25 <stepcut> k
22:01:29 <tazjin> I think adding another library would make it too complicated
22:02:16 <stepcut> a version of elmResponse that could cache the compiled source, and which used file embed could still be simple
22:02:54 <stepcut> though.. it would need some way to uniquely identify a source file
22:03:06 <stepcut> but. the source is a String.. so a sha1 hash could be sufficient
22:04:20 <tazjin> yeah
22:04:45 <tazjin> if you hack something together I'd like to put it in the elm repository instead of spreading elm-related things out over to the happstack repo etc.
22:05:31 <stepcut> right.. the cache could just be a TVar (Map SHA1 (Html, Html, String))
22:05:48 <stepcut> though, you could go one level more and do, TVar (Map SHA1 Response). But that makes it happstack specific
22:06:02 <stepcut> or.. the initi function could be
22:06:20 <stepcut> initCache :: (Html, Html, String -> response) -> TVar (Map SHA1 response)
22:07:23 <stepcut> hmm..  -> TVar ((Html, Html, String) -> response, Map SHA1 response)
22:07:30 <tazjin> I don't see any issue with it being Happstack specific
22:07:44 <stepcut> well the 'Response' type is happstack specific
22:07:54 <tazjin> we've got a yesod specific library, the Snap guys might have some other solution in mind that's deeply rooted in Heist
22:08:00 <tazjin> so elm-happstack is totally okay imho
22:08:03 <stepcut> ah
22:08:06 <stepcut> yeah
22:08:25 <stepcut> still. if there is room to put some parts in a common library I am fine with that
22:09:20 <tazjin> As far as I know Michael and the rest of the Yesod team are working on their own caching solution (iirc luite mentioned that a while ago)
22:09:39 <tazjin> so that should also cover elm-yesod
22:09:55 <tazjin> If we do find something to put in a common library then well, fine :P
22:13:55 <stepcut> :)
23:03:34 <donri> stepcut: did you see http://paolocapriotti.com/blog/2012/05/29/pipes-2.0-vs-pipes-core/
23:03:48 <donri> i hate that it's named pipes-core -.-
23:04:47 <luite> yeah...
23:17:17 <donri> stepcut: it would be cool if we could have separate types for hsx for sake of ToMessage so instead of XML we have HTML --> renders as text/html with html5 doctype, Atom --> renders as application/atom+xml... etc
23:18:42 <donri> would also help to prevent you from using html templates in atom templates etc?
23:36:17 <stepcut> donri: yeah.. could be done
23:36:36 <donri> perhaps after we have hsx-th :p
23:37:30 <donri> might also allow for instances like EmbedAsChild Atom HTML for post bodies