01:37:42 <stepkut> McManiaC: ping
04:08:48 <stepkut> k, directory listing is nearly complete
04:09:05 <stepkut> soon it will be time to refactor
04:17:53 <mtnviewmark> stepcut: I'm building something much like you did with HS and dynamic plugins
04:18:08 <mtnviewmark> and I'm running into this problem: Everything works from within ghci
04:18:17 <mtnviewmark> but if I build my application with cabal and run it
04:18:24 <mtnviewmark> then on the first plugin load I see this error:
04:18:32 <mtnviewmark> unknown symbol `___stginit_zzlibzm0zi5zi2zi0_CodecziCompressionziZZlib_'
04:18:53 <mtnviewmark> I think the issue is that the dynamic code needs zlib
04:19:01 <mtnviewmark> but Main.hs does not
04:19:07 <mtnviewmark> did you run into something like this?
04:19:43 <stepcut> yes
04:20:03 <stepcut> but the fix was to patch hsplugins -- that should be fixed now..
04:20:35 <mtnviewmark> well, I'm actually not using hsplugins - I'm just doing something very very simillar
04:20:37 <mtnviewmark> what was the patch?
04:22:36 <stepcut> I don't remember. It was not chasing dependencies correctly.
04:22:50 <stepcut> I submitted the patch and it was applied, as far as I know...
04:23:14 <stepcut> if you are not using hsplugins, what are you using ?
04:24:04 <mtnviewmark> I'm building a dynamic, web-based IDE for Haskell, based on Snap (ducks)
04:24:57 <mtnviewmark> stepcut - so you mean that you had to make it chase the dependencies at runtime?
04:25:15 <stepcut> yes, it had to find all the dependencies to be loaded and make sure they were loaded
04:25:22 <stepcut> is this a problem with hint ?
04:26:32 <stepcut> also, what made you choose snap over happstack? I'm not going to try to talk you out of it -- I  am just curious how happstack could improve
04:27:34 <mtnviewmark> hint? the library? no - zlib!
04:28:11 <mtnviewmark> For this use we wanted a web stack that was a close to "normal" way of doing web apps as possible
04:28:42 <mtnviewmark> to be honest - the project is somewhat agnostic about that part - only it does get exposed to the users - when they want to write a dynamic web page that gets the query args, say
04:28:45 <stepcut> mtnviewmark: what is abnormal about happstack?
04:29:13 <stepcut> but, what are you using to load the plugin? you said you were not using hsplugin.. so how are you loading the plugin then ?
04:29:22 <mtnviewmark> I don't really know - I didn't compare one to the other - I had understood that happstack tried to be more comprehensive in it's approach - doesn't it have a STM tie in, etc?
04:29:47 <mtnviewmark> no no - I mis-typed - we are using the plugins package to load the libs
04:29:59 <stepcut> mtnviewmark: there are two primary libraries provided by happstack. happstack-server (which is similar to snap), and happstack-state. The are completely independent though.
04:30:27 <mtnviewmark> then I guess we could use happstack-server vs. snap-server   --- -how would one choose one over the other?
04:30:28 <stepcut> happstack-state does use STM, but not happstack-server
04:31:36 <mtnviewmark> I'm now wondering how hsplugins could find missing libs at runtime..... does it read the ghc-pkg database? how does it know where the libs even are?
04:31:55 <stepcut> it does read the pkg database
04:32:50 <mtnviewmark> aha  - you require  plugins > 1.5.1.4
04:32:55 <mtnviewmark> I have 1.5.1.3
04:32:58 <stepcut> :)
04:33:00 <mtnviewmark> >=
04:33:13 <stepcut> is 1.5.1.4 on hackage now ?
04:33:37 <stepcut> yes it is.
04:33:44 <stepcut> I would try upgrading and see if that fixes things.
04:33:46 <mtnviewmark> don't know - but you require it in your .cabal file
04:33:54 <mtnviewmark> in the midst...
04:33:54 <stepcut> http://hackage.haskell.org/package/plugins-1.5.1.4
04:34:19 <stepcut> there is a second issues with hsplugins -- it does not work correctly if the modules you are trying to load using hierarchical module namse
04:34:27 <stepcut> I did not fix that -- I wish somebody would though ;)
04:34:33 <mtnviewmark> yes - I have that on my bug list
04:34:37 <mtnviewmark> and saw that you have it too
04:34:57 <stepcut> it is not especially difficult. It does not involve the scary parts of hsplugins
04:35:16 <mtnviewmark> also - I found that the API is somewhat screwy --- if, like in my case, you don't know which of several symbols may be in the built module
04:35:57 <stepcut> did you see my trick for allowing your code to switch between static and dynamic linking, while still preserving some type safety?
04:36:17 <mtnviewmark> no - for this project always dynamic is just fine
04:36:30 <stepcut> most of the code in happstack-plugins is not happstack specific. It would be nice to factor that non-happstack stuff out so that other people can use it.
04:36:54 <mtnviewmark> yes - your use of plugins is much more sophisticated than ours at present
04:37:10 <mtnviewmark> we had on the TODO list to do all the tracking work that you did
04:37:19 <mtnviewmark> but now we have on the TODO list to just crib from you!  :-)
04:37:26 <stepcut> so, it sounds like the happstack messaging needs to be more clear that happstack-server and happstack-state are separate entities. And also discuss how to know if happstack-server is optimal for your project.
04:37:51 <mtnviewmark> so what *are* the differences between the servers then?
04:40:18 <stepcut> At the high-level, they are basically the same I think -- some minor differences in the details, but largely the same. At the low-level, snap has an iteratee based backend, and happstack-server is using lazy IO
04:40:49 <stepcut> happstack-server will eventually move to iteratee based IO as well, but we are hoping to leverage hyena for that, rather than roll our own
04:40:55 <mtnviewmark> so essentially - no difference - the issue is going to be which one plays better with the new IO system, I suspect
04:41:10 <mtnviewmark> hyena as in Johan's server?
04:41:13 <stepcut> yes
04:41:23 <mtnviewmark> he's my collaborator on this project!  :-)
04:41:48 <stepcut> snap use hlibev directly, so I think it is not much affected by the new IO manager
04:42:13 <stepcut> happstack should benefit, though I have not be able to upgrade to GHC 7 to test yet due to a tricky compilation error in HSP
04:42:15 <mtnviewmark> right - I think Johan's intent is that if and when he gets hyena ready - we'll just base on that...
04:42:20 <mtnviewmark> I suppose
04:42:48 <stepcut> yeah. hyena is pretty sweet (in theory). It is exactly what we want for happstack-server
04:43:07 <stepcut> the interesting part of happstack-server is really the high-level stuff. The low-level backend is largely invisible as long as it works well
04:44:44 <mtnviewmark> right- so what Haskell needs is a good, highly efficient low-level web server that then allows different web server high level frameworks on top of it
04:44:55 <stepcut> exactly
04:45:05 <stepcut> and that is exactly what hyena is supposed to be
04:45:12 <mtnviewmark> I know there was some attempt at trying to unify the web server interfaces before
04:45:18 <stepcut> in theory, happstack, snap, and yesod could all use it
04:45:24 <mtnviewmark> (I added my $0.02 a while back)
04:45:33 <stepcut> right, yesod tried to use the WAI interface introduced by hyena
04:45:44 <stepcut> but other people felt it was too early to standardize
04:45:47 <mtnviewmark> but didn't he define a variant: NAI?
04:45:53 <stepcut> yes
04:46:05 <mtnviewmark> so - for now - a 1000 flowers bloom
04:46:06 <stepcut> nobody thought the old variant was correct
04:47:12 <stepcut> honestly, I think the differentiation between the different frameworks is going to come from what is built at an even higher level than the server component
04:47:22 <stepcut> there is really only so many ways to build a haskell web server
04:48:17 <stepcut> a lot of the structure of snap was borrowed directly from happstack, so it is no surprise that the inside of the Snap monad is similar to the ServerPart monad. But michael snoyman pretty much rolled his own with out looking at other peoples code from what I can tell, and it looks shockingly similar
04:51:03 <stepcut> but, then yesod has it's whole system for building apps built on top of the server portion. It uses web-routes for the routing, hamlet for the HTML, cassius for the CSS, julius for the javascript, etc. It has a somewhat fixed concept for how you build your apps very much based around REST
04:51:17 <stepcut> and a strong love of quasi quotations
04:52:48 <mtnviewmark> right - I agree that innovation, and distinction, will occur at the higher levels
04:53:31 <mtnviewmark> WOOT! That rocks! It Works!
04:54:04 <stepcut> there is, of course, a lot of collobaration as well. Michael and I worked together a bunch on  web-routes (which I originally developed) and so it works with yesod, happstack, and can be extended to other frameworks as well
04:54:23 <stepcut> and we (mostly him) worked on the authenticate library as well (for openid auth stuff)
04:54:41 <stepcut> I would like to try to get the plugin stuff more collaborative as well
04:55:16 <stepcut> happstack is using hsplugins, yesod and snap use hint. It would be nice to figure out what the advantages of the different approaches are and then build a common library we can all use.
04:55:27 <mtnviewmark> ACTION wonders if he should admit that in his day job he is implementing OAuth2.... in Java...
04:55:39 <stepcut> just bind to the haskell library ;)
04:55:48 <stepcut> oh
04:55:51 <stepcut> oauth is different
04:55:57 <stepcut> though there is a haskell oauth library as well
04:56:09 <mtnviewmark> right - and the ink on OAuth2 isn't even dry yet
04:57:07 <mtnviewmark> johan and I talked with dons in Baltimore and it seemed like plugins was going to be the more robust solution -- though I can't remember why
04:57:51 <mtnviewmark> (normally all this low level stuff is Johan's part - but he's on a trip - and I've got a demo at a conference tomorrow!)
05:02:43 <mtnviewmark> no decoding of query args or post body args in Happstack?
05:03:54 <stepcut> there certainly is
05:04:23 <stepcut> http://www.happstack.com/docs/crashcourse/RqData.html#rqdata
05:06:17 <stepcut> supports file uploads as well
05:06:41 <mtnviewmark> "either from a POST or a GET request" -- pet peeve of mine -
05:06:49 <stepcut> oh ?
05:07:02 <mtnviewmark> I don't think frameworks should do that - they are different, and when coding pages you should know where they are coming from
05:07:14 <mtnviewmark> they have very different properties in the Web Architecture
05:07:46 <stepcut> you can specify where to look if you car, foo <- body $ look "foo" vs foo <- queryString $ look "foo"
05:07:46 <mtnviewmark> ANY request can have query arguments - just part of the URLs
05:08:02 <mtnviewmark> a way of parameterizing a resource request, visible to the caching infrastructure
05:09:50 <mtnviewmark> ah
05:12:46 <stepcut> what made you think happstack did not support decoding ?
05:20:39 <mtnviewmark> Reqeust seemd like the obvious data type
05:20:46 <mtnviewmark> and it doesn't have any clear support
05:21:33 <stepcut> yeah, that's why we had to write documentation :)
05:40:34 <mtnviewmark> it is very early stage, but the project is called Barley - (on github)
05:41:06 <mtnviewmark> it isn't really at even 0.1 release yet - but keep an eye out for info on the Haskell reddit soonish
05:41:40 <stepcut> k
16:16:46 <HugoDaniel> ACTION is dead
17:22:54 <McManiaC> stepcut: pong
17:23:23 <stepkut> so, I remember another way to migrate your data
17:24:24 <McManiaC> ok?
17:24:26 <stepkut> if you had a version of happstack-auth that had the type in the old *and* new location, then you could have a special version of your serve that has a component for each location. It would have some code that would then copy the data from the old component to the new component. You just run it once to get all your data migrated.
17:24:40 <stepkut> I have done that before -- it's not awesome, but it works
17:26:06 <McManiaC> hm yeh
17:27:24 <stepkut> or... you could help get 0.6 out the door so we can fix it for real in 0.7 :p
17:33:10 <HugoDaniel> is there any support for websocket being planed ?
17:33:36 <HugoDaniel> i saw that there is already a package in hackage for the protocol
17:33:55 <stepkut> HugoDaniel: it is not currently planned. Though it sounds desirable
17:34:01 <HugoDaniel> http://hackage.haskell.org/package/network-websocket-0.3
17:34:03 <HugoDaniel> ok
17:34:19 <stepkut> yeah
17:34:28 <stepkut> what would we need to do to actually support websocket ?
17:34:35 <HugoDaniel> i dont know :/
17:34:52 <HugoDaniel> i think netsocket just skips the http mambo jambo and sends all the stuff in tcp
17:34:56 <stepkut> me neither :p
17:35:00 <stepkut> that is one reason it is not planned
17:35:03 <HugoDaniel> but im not even sure about this
17:35:22 <HugoDaniel> i might start doing that, but im a noob so i could use some help getting started :P
17:35:25 <stepkut> nice
17:35:39 <stepkut> I can answer happstack related questions
17:35:42 <HugoDaniel> would it be a problem if happstack depended on that pkg ?
17:35:46 <HugoDaniel> allright
17:36:11 <stepkut> that package depends on 'webserver', so it might be a bit odd
17:38:32 <stepkut> gotta run to aerial class at the moment though
17:40:12 <HugoDaniel> hmm
17:40:13 <HugoDaniel> i see
17:40:13 <McManiaC> stepkut: I'd help you immediatly if I wouldn't have to do quantum mechanics-, computational physics- and numerics-exercises and implement monad comprehensions for GHC at the same time
17:40:17 <McManiaC> :D
18:04:28 <stepcut> :p
18:19:31 <McManiaC> :)