05:27:30 <alpounet> i hope the two persons in stepcut's video got paid a lot for... hm, "this".
10:18:55 <mekeor> i should read the happstack-crashcourse.
10:19:57 <donri> you haven't?!
10:20:05 <donri> oh right you use lite
10:20:11 <mekeor> *nod*
10:20:27 <mekeor> but i'm going to do more complicated stuff.
10:20:41 <donri> :)
10:22:40 <mekeor> particulary, i need more powerful routing. (i hope that's the correct term.)
10:23:01 <HugoDaniel> :)
10:24:25 <donri> mekeor: web-routes is awsum
10:26:14 <mekeor> i like the crashcourse. it's written well.
10:26:52 <donri> possibly the best docs in haskell web land
10:27:44 <kstt> don't you mind if I ask questions loosely related to happstack ?
10:27:53 <donri> kstt: shoot
10:28:20 <mekeor> go ahead.
10:28:28 <kstt> in the course of my happstack project, I want (almost need) to use lenses on my state
10:29:06 <kstt> first: do you understant data-lens package numbering policy at http://hackage.haskell.org/package/data-lens ? 2.0.4.1 is mastered by E. Kmett, uploaded on May, 8. However, 2.10.0 is mastered by R. OConnor, uploaded on April, 10 .
10:29:58 <donri> kstt: new maintainer
10:30:03 <kstt> also, more practically, do you know if it is supposed to be possible to generate lenses with "makeLenses" for a data type defined in an other module ? I keep having "Illegal binding of built-in syntax" error messages".
10:30:17 <kstt> donri: who is the new maintainer ?
10:30:22 <donri> roconnor
10:30:44 <mekeor> roconnor uses NixOS, btw… AFAIK…
10:31:10 <kstt> but latest (as of upload date) release is ekmett's ...
10:31:45 <donri> kstt: yes, but that's a patch-level release
10:32:09 <kstt> ok
10:32:13 <kstt> fair enough
10:32:41 <donri> i think 2.9+ changes some fixities or such so perhaps edwardk is doing some minior maintainance for the older releases
10:33:27 <kstt> note to roconnor : I must stick to 2.0.4.1 because its dependencies accept container 0.5, which is not the case for 2.9.*
10:34:06 <kstt> (surprisingly, 2.9.0 is bound to container < 0.5)
10:34:11 <donri> kstt: as for other module, not sure. how are you using makeLenses?
10:34:22 <donri> you need to enable the TemplateHaskell extension
10:34:26 <kstt> the is a module with all the data types
10:34:49 <kstt> I import this module in an other one, then makeLenses on the data types
10:34:57 <donri> kstt: roconnor isn't here, try #haskell
10:36:41 <kstt> ok thanks. For some reason my irc client highlights its name, so I thought he was reading here.
10:36:45 <donri> kstt: duno if TH can reify cross-modules, but in any case it's the more common practice to put such things in the same module
10:37:24 <kstt> in my case I'm a bit embarassed to do so in the same module, but I can certainly live with that
10:37:31 <donri> did you enable template haskell and how are you writing makeLenses?
10:38:05 <donri> embarassed?
10:48:58 <kstt> yeah, the Type module is quiet big. I don't want to export everything, but I want to export every lenses (about 100). I'm too lazy too type them in the module export list. You see ... :)
11:18:17 <mekeor> should i use Happstack.Lite.serve or Happstack.Server.simpleHTTP ?
11:26:20 <donri> either is fine
11:30:39 <donri> the latter allows more fine-grained control over post body decoding whereas the former handles it automatically
11:30:50 <mekeor> there's an example-code on the crashcourse which doesn't work for me:
11:30:50 <mekeor> http://hpaste.org/69328
11:32:47 <donri> mekeor: perhaps disable OverloadedStrings
11:32:58 <donri> it's not used in that example, but you seem to be using it
11:33:46 <mekeor> works. thanks!
11:33:49 <mekeor> donri++
11:33:51 <mekeor> great
11:47:35 <luite> hey guys, does anyone know the http spec here? :p
11:47:54 <luite> or an http header test suite
11:48:13 <mekeor> http is easy.
11:49:08 <luite> mekeor: i was having a discussion with Michael about the LWS rule, in particular what words are when the quoted-string and token productions aren't used explicitly
11:49:24 <luite> do you know that?
11:50:20 <mekeor> no
11:50:27 <luite> depending on your interpretation, the version strings HTTP/1.1 ,  HTTP / 1.1  , and HTTP / 1 . 1    could all be allowed. But in some interpretations the third, or the third and second would be disallowed
11:50:47 <mekeor> use the first then ;)
11:50:53 <mekeor> what's the problem?
11:51:01 <luite> no it's about accepting stuff from clients
11:51:10 <mekeor> ah
11:51:25 <mekeor> accept all then. that'll be the best, IMO…
11:51:34 <donri> luite: perhaps test what others do
11:51:35 <donri> like apache
11:51:43 <luite> donri: yeah it doesn't accept some of them
11:51:57 <donri> mekeor: that's what lead to the situation with html and js :p
11:52:29 <mekeor> :D
11:52:30 <luite> right
11:52:47 <mekeor> then only accept the first. :D
11:53:18 <luite> donri: well the cause is some reddit troll how claimed yesod's "complete disregard for the http specification", now he had a valid point, warp didn't accept multiline headers, but that's been fixed
11:53:30 <luite> now the rest of his comment depends on interpretation of this LWS rule
11:53:34 <donri> luite: isn't there a grammar for this?
11:53:41 <luite> yes, a confusing one
11:53:48 <luite> because of this LWS rule
11:53:55 <donri> LWS?
11:54:27 <luite> the lws rule says that linear whitespace can be implicitly ignored between tokens and quoted strings
11:54:52 <luite> now the http version is something like http-version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
11:55:17 <luite> the lws rule refers to the token rule to explain what words are, and according to that, the string "1.1" is a single word
11:55:48 <luite> so then HTTP / 1.1 would be allowd, but HTTP / 1. 1  would not be
11:56:28 <luite> but on the other hand, some rule further down, has "W/
11:56:34 <luite> err, "W/" as a string literal
11:56:51 <luite> which, if you passed it through some token parsing phase first, would be parsed as two tokens
11:57:15 <luite> does "HTTP" "/" mean that optional spaces are allowd there, and "W/" that they wouldn't be there?
11:57:30 <luite> even though according to the token rule, they are the same number of words?
11:58:22 <luite> allowing optional spaces between every part of a BNF rule sounds terrible, so i assumed that that isn't what they meant
11:58:42 <luite> (if they did, they wouldn't have to refer to the token rule to explain what words are)
12:00:08 <donri> luite: http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html#sec19.3 ?
12:01:32 <luite> donri: right, but if you read that strictly, you should accept multiple splaces where a single is expected. the discussion here is about whether any space is acceptable at all
12:02:12 <donri> "We therefore recommend that operational applications be tolerant of deviations whenever those deviations can be interpreted unambiguously." shrug
12:03:09 <luite> right, but that's just a general remark without SHOULD :p
12:03:42 <luite> only if they shout you MUST or SHOULD obey the RFC ;p
12:03:54 <donri> :)
12:08:06 <luite> stepcut: you were going to do http grammar based testing, right? do you already have a grammar for this?
12:18:42 <donri> luite: he's likely to be asleep for a few more hours
12:51:59 <kstt> what are the requirements a function must respect to be "made Acidic"  (through makeAcidic) please ? I can't find anything in the docstring. I guess all parameters must be somewhat serializable
12:57:14 <donri> kstt: i think it needs an explicit type signature (or it's inferred to MonadReader/MonadState instead of Query/Update) and arguments must be instances of SafeCopy
12:57:48 <kstt> ok
12:58:11 <kstt> thanks
13:41:43 <mekeor> how can i do something like this?: http://codepad.org/XCCF05Nq
13:41:48 <mekeor> if you know what i mean.
13:45:39 <donri> mekeor: http://codepad.org/yany4WnG
13:45:58 <donri> i meant to remove your code
13:45:59 <mekeor> WOW
13:46:13 <mekeor> donri: is there really a function called "domain" ??
13:46:45 <donri> mekeor: no, it's called host
13:46:46 <donri> my bad
13:46:52 <mekeor> heh, alright.
13:46:54 <donri> http://www.happstack.com/docs/happstack-server-7.0.2/doc/html/happstack-server/Happstack-Server-Routing.html#v:host
13:46:55 <mekeor> thank you very much.
13:47:54 <mekeor> really, thank you!
13:48:48 <donri> np
14:12:02 <RenJuan> ACTION wonders what would happen if the different haskell web package were forced to merge.
14:12:16 <RenJuan> s
14:12:19 <donri> horror, unspeakable horror
14:12:44 <RenJuan> and lots of feathers flying no doubt
14:13:18 <RenJuan> yesod is pulling out in front for me ATM due to an app I want to use using it
14:13:53 <RenJuan> but I'd really like to knock all their heads together like Moe with Larry and Curly
14:15:02 <HugoDaniel> :)
14:16:40 <kstt> I really hope no such thing would ever happen :)
14:16:49 <HugoDaniel> eheh
14:17:59 <kstt> I'd be ok to see happstack and snap pushing even further modularity and merging core, because the vision is quiet close
14:18:40 <mightybyte> kstt: We've tried
14:21:01 <donri> kstt: not sure i agree
14:21:15 <RenJuan> what I'd really like is somekina framework in which haskell and lisp web frameworks as well as apache could be interoperated
14:22:38 <mightybyte> In the case of the big three Haskell web frameworks, it seems they are separate for good reasons.
14:23:09 <RenJuan> those being?
14:23:35 <mightybyte> Core philosophical differences in how things should be approached.
14:24:16 <RenJuan> which trumps the greater functionality that would be in place if the duplication of labor were eliminated
14:24:44 <mightybyte> In the case of Yesod vs Snap+Happstack, there's not much duplication.
14:24:50 <mightybyte> The approaches are quite different.
14:25:04 <RenJuan> agreed
14:25:21 <donri> hsp and heist are quite different philosophically, even if both are xml-based
14:25:50 <luite> RenJuan: why integrate apache? do you want to automatically start the underlying haskell framework with apache?
14:25:56 <mightybyte> In the case of Snap vs Happstack, there might be some benefit to a consolidation.  For the most part the components are interchangeable.
14:26:09 <donri> snap prefers the configurator package for configuration whereas i suspect if happstack gets any special support it will involve something like dyre, perhaps
14:26:32 <mightybyte> web-routes and acid-state can already be used with either framework.
14:26:47 <mightybyte> The choice between Snap and Happstack really comes down to which web server and associated API you want to use.
14:27:19 <luite> RenJuan: otherwise it's mainly a matter of configuring a reverse proxy. having the web framework be its own http server seems to scale a lot better than fastcgi
14:27:47 <RenJuan> luite: actually see Apache as the possible defacto vehicle for such a thing. A lot of pkgs, expecially in the lisp side already will run as modules
14:27:48 <donri> mightybyte: well, third-party packages are supported to different degrees between the two. snap might have better support for heist and happstack better support for hsp?
14:28:16 <donri> so it also depends on which other packages you want to use or if you're fine with integrating the packages yourself
14:28:21 <mightybyte> Probably, but that's a function of developer interest, not inherent compatibility.
14:28:28 <luite> RenJuan: hm, apache is kind of heavy, and probably a lot slower than letting your haskell framework serve stuff directly
14:29:15 <mightybyte> RenJuan: see http://snapframework.com/blog/2010/11/17/snap-0.3-benchmarks
14:29:16 <RenJuan> yeah so some below needed that sees two levels above itself the pkgs we're mostly talking about at the 3rd
14:30:01 <RenJuan> that really confirms Ruby's rep as a dog
14:30:21 <mightybyte> RenJuan: Well, not if you ask Ruby guys.
14:30:34 <RenJuan> *somthing below
14:31:17 <RenJuan> i'd rag on rubyist some more but already done so in publicly logged channels more than is politically advisable
14:31:37 <RenJuan> s
14:32:27 <stepcut> don't forget, acme-http, http://www.haskell.org/pipermail/web-devel/2012/002408.html
14:32:33 <stepcut> bbl.
14:33:46 <luite> you can of course use acid-state easily with yesod. web-routes can also be used, but i guess there must be some important reason for that combination, perhaps you really like conduits or something :p (at least if you have web-routes for your whole site, if you just need it for some subsite it isn't that bad)
14:34:20 <RenJuan> stepcut, thx!
14:34:34 <luite> hehe acme-http isn't a real webserver
14:34:47 <luite> well, not one for actually applications anyway
14:34:53 <stepcut> luite: it's more real than fake though
14:34:55 <luite> but it's an interesting experiment
14:34:55 <RenJuan> is it a real project though?
14:34:55 <donri> sure it is! just not an application server yet
14:35:16 <stepcut> RenJuan: it is some initial exploration into the next generation happstack http backend
14:35:16 <RenJuan> so it's like an apache monad oder?
14:35:18 <mightybyte> RenJuan: Yeah, don't take that too seriously.  I think all or most of the acme- packages on hackage are jokes.
14:35:20 <stepcut> ACTION reall has to god now
14:35:28 <stepcut> I mean god
14:35:31 <stepcut> :(
14:35:33 <stepcut> go
14:35:36 <luite> stepcut: oh, i wanted to ask you, do you have a grammar for your grammar based http tester already?
14:35:42 <stepcut> luite: no
14:35:51 <RenJuan> oh yeah, I already had a go around on the acme pkgs, forgot about that
14:36:03 <kstt> mightybyte: indeed, it is clear that yesod philosophy can't be merged with happstack/snap 's
14:36:06 <luite> stepcut: oh, because I was having some discussion with Michael about the http spec, and the rfc is kind of unclear
14:36:30 <RenJuan> there kina like zygomorphic prepormorphisms or whatever
14:36:37 <RenJuan> *they're
14:37:03 <RenJuan> *zygohistomorphic
14:37:20 <luite> with the latest patch, Warp accepts the HTTP version string HTTP / 1.   1
14:38:18 <luite> whether that's actually correct depends on how you read the linear whitespace rule in the grammar description
14:38:54 <luite> so if anyone has given that any thought already, i'd be happy to hear about it :)
14:39:15 <kstt> also, I can only confirm that the snap team and the happstack team have done a beautiful job at decoupling their projects and opening their platform. I have mixed snap server with blaze-html and acid-state, as well as mixing happstack with heist, or even heist with blaze ... with no problem. That's admirable, so congratulations guys !
14:39:50 <donri> \o/
14:39:57 <mightybyte> kstt: Thanks
14:40:17 <luite> kstt: Michael has some github project where he combines yesod with heist (and also another one with another routing library), it isn't as hard as some would ahve you believe
14:41:52 <kstt> luite: I'm sure michael also does a lot with yesod projects to modularize the plateform. But I can not give feedback because I don't use them.
14:41:57 <luite> that said, yesod has always been focussing a bit more on integration, but the distinction yesod=integrated/monolithic <-> snap+happstack=modular/fragmented is really an oversimplification
14:43:17 <mightybyte> I actually think that Yesod should stick to their approach and we should stick to our approach.
14:43:39 <mightybyte> It doesn't seem like there's much to be gained from supporting Heist with Yesod or Hamlet with Snap.
14:48:25 <luite> mightybyte: i don't think any approach needs to be changed, hamlet will remain the default engine in yesod, michael probably just wanted to dispell the myth that if you want modularity and choice, you must use snap or happstack
14:53:19 <kstt> mightybyte: yes, please keep your snap philosophy
14:53:44 <kstt> composability rules
14:56:03 <luite> are there plans for adding client side stuff to snap btw? things like FRP frameworks or more limited forms of interaction where the server isn't directly involved?
15:14:22 <RenJuan> ACTION .oO(I wonder what keyboard layout causes a god vs. go typo)
15:14:41 <mekeor> everyone?
15:14:58 <mekeor> i mean, all? i mean, each?
15:15:28 <mekeor> i should go.
15:15:33 <mekeor> just trolling here.
15:52:36 <donri> stepcut: so i have yui working with web-routes now: https://github.com/dag/happstack-yui/blob/master/demo/happstack-yui-demo.hs
15:53:28 <donri> however, i'm wondering if it would be possible to generalize nestURL to MonadRoute, and if it would then work when the two handlers are of different types
15:54:13 <donri> in more than the URL parameter, i mean
15:55:17 <donri> at the moment, nestURL for yui only works if your handler :: Happstack m => RouteT url m Response
15:55:23 <donri> but that may not be the case with newtyping etc
16:01:47 <donri> (MonadRoute m1, MonadRoute m2) => (URL m1 -> URL m2) -> m1 a -> m2 a  -- something like that?
16:45:04 <stepkut> donri: any recommendations for haskell libraries that can parse and print css ?
16:46:42 <stepkut> http://hackage.haskell.org/package/language-css looks interesting, but doesn't have a parser yet
16:47:13 <stepkut> it does have nice combinators though
16:51:08 <stepkut> would be nice if someone submitted a patch for parsing
16:52:13 <stepkut> ACTION sends an email to the author
16:53:46 <donri> stepkut: http://hackage.haskell.org/package/css-text maybe?
16:55:24 <stepkut> donri: it is pretty unstructed and appears incomplete
16:55:53 <stepkut> donri: plus.. I have been burned any time I have tried to use michael's libraries in the past, so I am hestitant to do it again
16:56:13 <donri> :)
16:57:05 <stepkut> it just returns a bunch of [(Text, Text)] and stuff
16:57:34 <stepkut> if language-css added a jmacro-like QQ, it would be pretty swell
16:57:44 <stepkut> I am pitchin' the idea to the author right now :)
16:57:52 <donri> yes, i want a jmacro css package
16:58:00 <stepkut> the time has come to make a happstack-widgets library
16:58:01 <donri> + perhaps selector nesting
16:58:15 <stepkut> hsx + jmacro is a good start, but also need something for the css aspects
16:58:15 <donri> + monadic variants of both jmacro and the css package
16:58:58 <stepkut> but, we can start the design using a placehold CSS type for now.. (like, newtype CSS = CSS Text, or something)
16:59:51 <stepkut> The big issue, I think is making the CSS and Javascript cacheable?
17:00:35 <donri> CacheT? :)
17:00:41 <stepkut> no client side
17:00:51 <donri> etags!
17:00:58 <stepkut> like.. if a widget has a static stylesheet that goes with it, it would be nice if it was served as a normal .css file s othat the client could only download it once
17:01:22 <stepkut> also.. if you use a widget multiple-times on the same page, you don't want the stylesheet included multiple times
17:01:50 <donri> static assets should have cache-busting urls (e.g. include a version or checksum) and have far-future expires
17:02:05 <stepkut> if the css file is parameterized and slightly different each time you use the widget on the page, then we need a way to avoid namespace conflicts
17:02:20 <stepkut> ooo
17:02:20 <stepkut> neat
17:02:30 <donri> for dynamic assets you can really only have etags... unless you're smart enough to figure out expiration date based on how it is generated
17:02:48 <stepkut> that means the you can skip the if-modified-since overhead, because it doesn't even bother to check?
17:02:53 <donri> yep
17:03:06 <donri> that's the point of the neverExpires thing i added and what i do for yui
17:03:10 <stepkut> right
17:03:16 <donri> we might need some support in web-routes though
17:03:22 <stepkut> sure
17:03:23 <donri> for the checksumming
17:03:33 <donri> because we're too lazy to version our apps
17:03:36 <stepkut> I am fine with widgets relying on web-routes as well
17:03:50 <stepkut> at some point you have to sacrifice flexibility for reusability
17:03:54 <donri> sure
17:03:57 <stepkut> and this seems like the right place
17:04:24 <stepkut> I have the first widget already :)
17:04:51 <stepkut> I want to wrap this up into a widget: http://css-tricks.com/css3-progress-bars/
17:06:05 <stepkut> how many decimal points can a percentage value have in css ?
17:06:24 <donri> no idea
17:06:40 <donri> i round it off to two for fontSize in yui because that's what yui does :p
17:06:57 <stepkut> :)
17:16:02 <donri> is it a plain UI widget or do you intend to have some kind of ajax stuff built into it?
17:16:46 <luite> hm i'd probably use some ui framework if i needed those things
17:16:54 <stepkut> for the first version, I just need a static, meter :: Ratio a -> Color -> Widget
17:17:30 <stepkut> but.. the next step would be to tie into the ajax stuff so that you can make the meter move
17:17:47 <stepkut> like.. providing an progress bar for file uploads
17:17:53 <donri> http://yuilibrary.com/gallery/show/progress-bar not as pretty as the one you linked though
17:17:59 <luite> Ratio a sounds a bit too general :p
17:18:10 <stepkut> luite: oh ?
17:18:19 <luite> stepkut: Ratio String?
17:18:42 <stepkut> well, there is also some constraint, because I eventually just convert it to float
17:18:54 <stepkut> perhaps I should pick a more general type though
17:19:02 <stepkut> aka, anything I can convert to a float?
17:19:09 <luite> RealFrac is the one you want I think
17:19:14 <stepkut> i think so
17:19:25 <stepkut> the numerical hierarchy makes my head hurt
17:19:34 <luite> yeah it's not great :)
17:19:52 <stepkut> donri: widgets!
17:20:49 <stepkut> while yui may provide a progress bar in this instance.. it does not change the fact that widgets are useful
17:20:57 <donri> sure
17:21:45 <luite> why not a widget that uses yui behind the scenes?
17:21:47 <stepkut> so a widget has four optional pieces, HTML, Javascript, CSS, and other assets (.jpg files, etc)
17:21:58 <stepkut> luite: exactly
17:22:11 <donri> how do you like my idea of using hsp templates for all the widget pieces
17:22:54 <stepkut> donri: you mean, making a widget consist of, HSP + JMacro + CMacro ?
17:23:00 <donri> yesod does something like a state monad, addCSSWidget...; addHeadContent...
17:23:22 <donri> we could use harp to lift it out of a full (but minimal) html page
17:23:42 <stepkut> donri: oh, that is cool too
17:23:52 <luite> unfortunately the stuff the yesod widget monad keeps track of is not extensible
17:24:06 <luite> i'm not sure if it should be
17:24:11 <stepkut> luite: yeah, that was my impression, but I have not looked at it in a long time
17:24:30 <stepkut> luite: how does it ensure that the same resources don't get added more than once? Does each resource have a unique id ?
17:24:35 <luite> but at least in one instance, some user wanted to keep track of more (which was possible, just not terribly nicely)
17:24:39 <donri> my idea is more easily extensible i think... for example if you want the "async" attribute set for some script tag, we could just copy the attributes directly
17:24:57 <stepkut> donri: more extensible than what?
17:25:15 <donri> or if you want some script tag at the bottom of the body, we could still pick up on that, track it as a script, and place it at the same place in the layout
17:25:27 <donri> stepkut: yesod's approach with a state-like monad
17:25:37 <stepkut> ah
17:26:22 <luite> stepkut: actually i'm not sure, i think it deduplicates the result for things like css, but for scripts with addJulius [...| |]  i'm not sure what it does
17:26:28 <stepkut> I am hoping we can do both options
17:26:56 <stepkut> you create a Widget, which you can either embed inline <div><% someWidget arg1 arg2 ></div>, or you can use harp, <div><someWidget arg1 arg /></div>
17:27:05 <stepkut> though.. not sure how the args get applied there
17:27:27 <donri> downside is it might be a little more verbose... for example, instead of setTitle "foo" you need to write <html><head><title>...</title></head></html>... although we could allow title outside of head (html does)
17:27:33 <luite> stepkut: but the implementation is kind of ugly, a large record with lots of monoids. michael made it that way because the older version had terrible performance is what i remember
17:28:01 <luite> perhaps some customizable thingie with lenses would work better
17:28:14 <luite> where the user can add his own stuff
17:29:42 <stepkut> I have avoided implementing this so far, because it is not simple to get right ;)
17:30:06 <stepkut> it's easy to do 'wrong', hard to do 'right'
17:30:14 <luite> what yesod has isn't wrong i think, but not terribly flexible
17:30:25 <stepkut> yeah
17:30:44 <stepkut> happstack is all about flexible
17:31:24 <luite> widgets should also be easy to use, so even if it's flexiblized, the current behaviour should be easy to get
17:31:48 <stepkut> donri: for the HaRP version, you still need something that bundles up the various pieces of a widget, and serves the assets, right ?
17:31:52 <stepkut> luite: of course!
17:32:49 <donri> stepkut: yes, i'm just proposing it as an "interface" of sorts
17:33:07 <stepkut> donri: something that would be built on top of the core widget support?
17:33:18 <luite> donri: how would you get the results of running the widgets, and insert it in the complete page layout?
17:33:21 <donri> you still need to write a layout template that puts the pieces back and we still need support stuff for e.g. minifying and concatenating assets
17:34:05 <luite> yeah that's what yesod has the defaultlayout-wrapper for
17:34:11 <donri> i guess i'm not really talking about widgets but more like "pages", perhaps it doesn't work for widgets
17:34:41 <luite> it means that you can't use widgets in your top level layout
17:36:03 <stepkut> so... one type of widget is one where you insert the HTML right where the widget appears in the template, and the related css and script tags just get added to the <head> tag automatically.
17:36:23 <stepkut> a less common type is one where you insert the html in once place, but add the script tag somewhere else (in the body)
17:36:44 <donri> can you really do widgets like that with hsx?
17:37:06 <stepkut> for that case the first solution I can think of is something like <% widgetHtml foo %> and <% widgetScript foo %>, which means you can screw it up.. but Haskell types can only do so much
17:37:10 <luite> stepkut: actually the script tag in the body is useful, to avoid blocking page loads
17:37:15 <luite> but it's still a fixed place
17:37:34 <stepkut> luite: well, isn't that what $(document).ready() and things are for?
17:38:23 <luite> stepkut: yes, but i think the problem is that scripts in the header are still loaded first, and can delay the layout and rendering of the page
17:38:34 <luite> even if they're not run yet
17:38:36 <donri> stepkut: still need to load jquery do get $()
17:39:33 <stepkut> donri: sure. there are portable ways to do that though
17:40:57 <donri> stepkut: sure, but the issue is whether to link jquery from head or end of body
17:41:57 <stepkut> donri: well, we can decide that later
17:42:08 <stepkut> that is easy to change
17:42:42 <donri> certainly
17:45:02 <stepkut> so, should we assume we have some type like, data Widget = ... ?
17:46:24 <stepkut> data Widget = Widget { html :: XML, javascript :: JExpr, css :: CSS, files :: [FilePath] } ?
17:48:07 <stepkut> page :: (XMLGenerator m, EmbedAsChild m Widget) => XMLGenT m (XMLType m) ; page = <html><head></head><body><div><% someWidget :: Widget %></div></body></html>
17:48:19 <stepkut> gotta run before the ran starts up again, bbiab.
17:53:12 <stepkut> so. there are a bunch of flaws with that plan, but by figuring out what they are we can come up with a real solution ;)
17:53:24 <stepkut> like, including the widget more than once results in duplication
17:55:44 <luite> stepkut: what do you do with the files?
18:17:43 <stepcut> luite: that is part of the challenge.. they need to be served via serveFile or serveDirectory. In some cases you could use file-embed.. but not if the assets are videos or something.
18:18:29 <stepcut> luite: I think that when you render the page you need to get back a list of files to serve.. and there needs to be someway to get the base path to those files since they will be in different locations when you are running in the local directory vs installed via cabl vs installed via debian vs etc
18:19:25 <luite> stepcut: no i mean, some code shouldn't be inserted into the page itself, or even in a generated script
18:19:36 <luite> like jquery libraries or yui
18:19:49 <luite> but there still should be a script tag linking to it
18:19:59 <stepcut> right.. dependencies on external javascript files
18:20:04 <stepcut> that are not part of the  widget
18:20:07 <luite> possibly the same for libs that depend on some css
18:20:12 <stepcut> yeah
18:20:19 <stepcut> more stuff to put in the 'list of problems' to sole
18:20:21 <stepcut> solve
18:20:29 <stepcut> eating lunch now though. bbl.
18:20:49 <stepcut> I don't really have any answers yet -- mostly trying to figure out the questions first :)
18:21:22 <luite> hehe me neither, i was just mentioning them to make sure that you don't forget questions :p
18:21:49 <stepcut> yup ! Very useful!
18:25:29 <donri> stepcut: i don't see how you can set html headers etc from something embedded in body with hsx
18:26:29 <donri> or i guess something like filtermonad where embedding adds dependencies that are then injected at the end?
18:32:12 <stepcut> donri: you would need to use HSX with a monad that has a StateT or something to hold the values
18:33:00 <stepcut> then when you flatten the monad, you can extract information..  but.. not sure how that helps with generating the list of files you need to serve
18:34:26 <luite> i still don't really see the point of that list of files. what do you do when there's a file in that list?
18:40:04 <donri> serve it publicly
18:46:02 <luite> hmm, why do oyu need to keep track of that in the widgets? it sounds like some separate thing, some writable static temporary files thing
18:46:25 <luite> where you just let the widget write some temp file, and it gets a route to refer to it
18:47:16 <stepcut> a widget might depend on a particular graphic in order to work correctly
18:48:13 <donri> luite: because you want it to be flexible and not require you to put every dependency in a single directory (e.g. you have widgets in cabal packages with data-files)
18:50:02 <luite> donri: right, perhaps temp files isn't the right name then, you don't always generate the file. but still a FilePath sounds like not enough information, both for the widget and for happstack. the widget probably needs some route to refer to its files, and happstack probably needs some way to provide that route
18:50:45 <stepcut> right
18:50:56 <stepcut> for the url part, we can use web-routes
18:50:59 <donri> luite: sure, i think that was just the sketch
18:51:05 <stepcut> but mapping it to a disk on file still has issues
18:51:26 <tazjin> I've missed the part of the discussion before donri said "serve it publicly", what's this about? ;p
18:51:41 <luite> tazjin: widget support in happstack
18:51:56 <luite> with widget similar to yesod widgets: some html snippet with dependencies like scripts and css
18:52:05 <luite> but the happstack version will be better and more flexible of course ;)
18:52:09 <stepcut> .. and external files (like, jpg, etc)
18:52:31 <luite> right, good point
18:52:43 <donri> we're also looking to support ponies for everyone
18:53:04 <tazjin> Hm, ponies
18:53:55 <donri> tazjin: yes, you can have a pony! yours!
18:54:19 <tazjin> donri: http://www.youtube.com/watch?v=4d_FvgQ1csE
18:56:07 <donri> :)
18:57:24 <tazjin> Ponies begin at 2:50
19:01:22 <tazjin> About the widgets and linking the right files etc.: Michael Snoyman updated elm-yesod today and added a type class that keeps track of the location of the elm-min.js file, to use an elm widget the data type that's instancing Yesod requires an instance of ElmWidget which contains that path (the path is Either (Route master) Text, i.e. both type-safe and simple URLs are supported)
19:01:35 <tazjin> I think a widget based Happstack with a central App data type that needs Widget instances would be cool
19:01:50 <tazjin> Just my $0.05 ;P
19:02:23 <stepcut> dose the elm-min.js have a type associated with it then? Iike, data ElmMinJs ?
19:03:14 <tazjin> https://github.com/tazjin/elm-yesod/blob/master/Language/Elm/Yesod.hs <- line 38
19:09:24 <tazjin> You would obviously have lots of instances in your code, one for each widget, but it would work well I think and also ensure that everything is defined as it should be (using class constraints on the widget-specific functions)
19:21:39 <stepcut> hmm
19:21:46 <stepcut> we'll keep it in mind
19:21:57 <stepcut> but having hundreds of classes like that seems like the wrong approached
19:22:02 <stepcut> approach
19:43:56 <luite> i think that there might be some better way for lightweight widgets, perhaps classes are ok for widgets that need more config
19:45:07 <luite> on the other hand, making a class instance is probably hardly more code than just calling some widget register function
19:47:46 <luite> and classes do make it easy to have dependencies
19:50:13 <stepcut> yeah
19:51:14 <luite> widgets that provide reusable components could be classes (i'm ok with that in yesod), but for example iw as thinking of a widget that just has an icon for a button or something, that should be a bit lighter weight if possible
19:51:31 <stepcut> right
19:51:41 <stepcut> making  class instances feels 'hard' for some reason
19:52:12 <stepcut> but having to do, initWidget [widget1, widget2, widget3], seems easier… but leaves you open to accidentally using uninitialized widgets :-/
19:52:44 <luite> probably easier to implicitly initialize them when they're used
19:55:25 <tazjin> "lightweight" widgets could just not have a class
19:55:45 <tazjin> i.e. add no class constraint, use the same functions as other widgets and done.
19:55:45 <luite> tazjin: yeah but they should still be able to add static or dynamic files somehow
19:56:02 <luite> that's currently not possible in yesod i think, at least not in a modular fashion
19:56:21 <tazjin> So the file is supposed to come with the widget?
19:56:56 <luite> tazjin: yeah that could be useful. of course you cannot just serve data-files from libraries because that would lead to lots of problems with deployment
19:56:58 <stepcut> tazjin: yeah.. like widgets would be distributed via cabal packages
19:57:15 <tazjin> I could think of a way to do that in Yesod though
19:57:16 <luite> but perhaps file-embed could work, or some other workaround to get the files distributed to your deployed location
19:57:17 <stepcut> luite: right.. you can't assume the data files are where cabal would install them
19:57:29 <stepcut> luite: not in  general, because some files are too big
19:58:16 <tazjin> A custom Setup.hs could be generated that takes an environmental variable (WIDGETFILES?) which contains folders with the package names and versions
19:59:01 <luite> tazjin: hmm, not sure about that
19:59:26 <tazjin> Hrm, well, we need to guarantee that the files are at the expected location
19:59:55 <luite> tazjin: right, but how do you know which packages provide widget data files for you?
20:00:37 <tazjin> At what point? When creating the cabal package?
20:00:46 <luite> I'm getting headaches just thinking about battling with cabal again :p
20:01:33 <luite> tazjin: i think when deploying, that could be when doing cabal install
20:01:57 <tazjin> Well, cabal install would of course read it from the Setup.hs file
20:02:31 <luite> right, but say you have some nice button widget, you don't want to edit your Setup.hs when that widget adds an icon file
20:02:46 <tazjin> Ahh, now I get it
20:03:00 <tazjin> I was thinking you were talking about the widget package itself, not the app containing widgets
20:03:13 <luite> oh right, no the widget package can probably just use data-files
20:03:21 <tazjin> Hmm
20:03:54 <luite> I have been thinking about this before, but with executables instead of data files
20:04:30 <luite> since ghcjs generates javascript bundles in ~/.cabal/bin
20:18:51 <mekeor> I want compatibility with blaze-html-0.5.0.0! Give me compatibility with blaze-html-0.5.0.0! NOW!!!
20:19:12 <mekeor> =)
20:21:42 <luite> yesod alread has that ;p
20:22:26 <stepcut> mekeor: happstack-server works with blaze-html 0.5 now..
20:22:34 <stepcut> mekeor: unless you have proof otherwise
20:22:42 <luite> oh wait, not released, sorry
20:22:50 <luite> oh wait it is
20:22:55 <luite> it's some conditional thingie
20:23:36 <mekeor> stepcut: o rly? NICE!
20:23:39 <stepcut> yup
20:23:56 <mekeor> ACTION is running cabal install happstack-server
20:24:07 <stepcut> happstack-server >= 7.0.2
20:24:09 <mekeor> o w8. first cabal update…
20:24:17 <stepcut> :)
20:24:27 <mekeor> stepcut: do i need that >= 7.0.2 ?
20:24:32 <stepcut> no
20:24:36 <mekeor> ok, fine.
20:24:46 <mekeor> you're great, sir.
20:25:49 <stepcut> thanks!
20:25:52 <luite> hehe i like that "w8" works in both english and in dutch
20:26:30 <mekeor> in german, "n8" works and is read as "nacht" and means "night".
20:26:48 <luite> yeah that also works in dutch
20:26:54 <mekeor> neat.
20:27:16 <luite> but it doesn't work in english as well, 8 is not quite the same as "ight"
20:27:18 <tazjin> I never really got how people read n8 as "night"
20:28:11 <donri> they must have some inn8 ability to do it
20:28:34 <tazjin> http://ragefac.es/432
20:29:43 <luite> there must be funnier ones that work in both languages but with a different meaning
20:30:02 <luite> "gr8" in dutch is "gracht" = canal, but that's not really funny
20:30:28 <donri> cave in swedish
20:30:28 <tazjin> it's also Gracht in German, which has no meaning
20:30:46 <donri> gråtta -> grotta
20:31:51 <luite> m8 = macht = power
20:31:52 <mekeor> so, i have both happstack-7.0.0 and happstack-7.2.0 installed. which does GHC use?
20:31:53 <tazjin> If the German word for 8 was also åtta instead of acht it would almost work for us :P (Grotte = grotta)
20:32:03 <tazjin> luite: Same
20:32:12 <mekeor> tazjin: where're you from?
20:32:13 <luite> i kno :)
20:32:20 <mekeor> sweden?
20:32:24 <mekeor> i forgot it…
20:32:40 <mekeor> sweden, yes. i should read more of the chat…
20:32:59 <tazjin> mekeor: Germany/UK, live in Germany at the moment but work in København and Stockholm sometimes
20:33:13 <stepcut> mekeor: if you don't specify, it will use the most recent versions
20:33:21 <tazjin> I'm not Swedish but I speak it :P (Not as well as English and German, but well enough to get along)
20:33:33 <mekeor> stepcut: ok
20:33:36 <stepcut> mekeor: if you run ghci and then do :set -v, it will give you a bunch of messages about packages it is hiding
20:33:50 <stepcut> you can do, ghc-pkg unregister happstack-7.0.0 to remove the old version
20:33:50 <luite> hehe i can read a bit of swedish but can't really comfortably have a conversation in it
20:33:58 <luite> have only been there for half a year
20:34:01 <mekeor> stepcut: why do i still get "No instance for (ToMessage Html)" ?
20:34:04 <stepcut> but it will complain if you have other packages installed that require happstack-7.0.0
20:34:13 <mekeor> "…arising from a use of `toResponse'"
20:34:26 <stepcut> mekeor: probably because you have other packages installed which require happstack-7.0.0 and hence it can't use 7.0.2
20:34:40 <stepcut> try doing,ghc-pkg unregister happstack-7.0.0 and it will tell you what
20:34:46 <mekeor> u meant 7.2.0, right?
20:35:32 <stepcut> there is no 7.2.0, only 7.0.2
20:35:40 <mekeor> erm
20:36:00 <mekeor> strange… i thought i just read that.
20:36:02 <mekeor> mistery.
20:36:48 <mekeor> i have happstack-6.something -- do i have to update that?
20:36:54 <donri> incidentally, i can't upgrade happaste to latest happstack because highlighter needs blaze <0.5
20:37:50 <stepcut> mekeor: just remove it
20:38:00 <stepcut> donri: :(
20:38:58 <mekeor> ah, there's happstack-lite-7.2.0!
20:38:58 <donri> guess i could patch highlighter, but haven't gotten alex to apply other patches for it...
20:40:35 <stepcut> mekeor: Yeah
20:41:06 <stepcut> donri: I think the only interesting change is support for blaze-html >= 0.5.. so...
20:41:12 <mekeor> that's misleading/weird/acceptable/strange/okay/fine.
20:41:43 <mekeor> stepcut: works now. thank you again and again!
20:47:36 <stepcut> mekeor: no problem! Some of the GSoC projects should help with this type of 'cabal hell'
20:56:42 <donri> ACTION patched highlighter
21:05:56 <donri> mekeor: yea the first number matters between packages but the second is individual to each package
21:06:24 <donri> (true about first number for happstack packages, that is)
21:09:18 <donri> stepcut: well, step one is to use cabal for your own project as well, which i think mekeor isn't
21:09:34 <donri> then he can set version constraints so cabal will pick up the right one
21:10:27 <stepcut> donri: that would help in the current case -- hopefully some of the GSoC projects will help with just running ghci as well, such as private depends and stuff
21:11:43 <mekeor> yea, i should use cabal. i will do soon.
21:12:21 <tazjin> I think using cabal-dev with GHCi also does the job
21:12:24 <tazjin> for version constraints
21:13:36 <stepcut> every Haskell GSoC project this summer benefits happstack in some way :)
21:47:39 <stepcut> sorry. I have divided attention today. But I do hope to get this widgets stuff out in the next 3-4 weeks
22:02:59 <donri> stepcut: did you get my questions about nestURL
22:03:41 <stepcut> donri: don't think so.. what medium ?
22:03:49 <donri> here
22:04:30 <stepcut> today?
22:04:36 <donri> yep
22:05:19 <stepcut> oh, I see it now
22:05:21 <stepcut> I don't know
22:05:43 <stepcut> I do know that that type of thing is very much related to some of the improvements I want to make to web-routes though
22:06:04 <donri> cool
22:06:37 <stepcut> I logged it, http://code.google.com/p/happstack/issues/detail?id=209
22:06:49 <stepcut> btw, I don't *just* log bugs..I do actually address them later :)
22:07:11 <donri> haha
22:07:16 <stepcut> and, despite outward appearances, I am working on a bunch of happstack related things at the moment
22:07:32 <stepcut> once I get the happstack.com source code out, things should be a lot better
22:07:33 <donri> with all the money we're throwing at you you better! wait what?
22:07:51 <stepcut> :)
22:08:58 <donri> what is the plan for the server in happstack 8 btw, completely rethink it or try to keep some level of backwards compat?
22:10:01 <stepcut> for 8 everything is up for grabs
22:10:27 <stepcut> that said, I think we got a lot of things almost right
22:10:44 <donri> i'd quite like to clean up some apis, but on the other hand we don't want to have to rewrite the whole ecosystem :p
22:10:56 <stepcut> but.. we want to switch from, dir "foo" $ dir "bar" $ handler, to, do dir "foo" ; dir "bar" ; handler
22:11:23 <stepcut> donri: yeah, that is mostly what I have done since taking over happstack maintainership :)
22:11:31 <donri> hehe
22:12:40 <stepcut> donri: I am almost ready to start happstack 8 for real. step 1: get the happstack.com source released, step 2: fix some high-priority complaints about acid-state, step 3: happstack 8 full steam ahead
22:12:41 <mekeor> n8
22:13:11 <stepcut> we should definitely not abbreviate happstack 8 to, H8
22:13:12 <stepcut> :p
22:13:23 <donri> mekeor: don't mark the bed bugs as wontfix, g'night!
22:13:29 <donri> haha
22:13:53 <donri> H8, 88, HH, Heil Hewhomustnotbenamed
22:15:32 <donri> all glory to the hypnostack?
22:17:18 <stepcut> donri: I am pretty sure hypnostack has been suggested before.. just not sure if it was you or not ;)
22:18:17 <donri> it was probably me
22:19:41 <stepcut> :)
22:20:13 <donri> this is why we need searchable irclogs on the site
22:55:06 <stepcut> donri: yup! I really want a native haskell / acid-state full text search engine
22:55:16 <stepcut> the irc-logs don't require acid-state.. but the search part probably would
23:13:38 <stepcut> sadly, that GSoC project did not make the cut
23:14:09 <stepcut> though.. the proposal was not that strong either.. I just want the outcome :)