00:10:14 <stepcut> someone needs to work on clckwrks-plugin-darcs some more :)
00:11:14 <stepkut> I'm finally overhauling the plugin system, which should help
00:13:35 <hpaste> donri pasted “cabal install clckwrks” at http://hpaste.org/75891
00:13:45 <donri> :/
00:14:09 <donri> that's so helpful, cabal!
00:14:38 <stepkut> :)
00:14:51 <donri> hm seems to install with older cabal-install
00:14:57 <donri> are you using 16 yet?
00:14:58 <stepkut> >:(
00:15:09 <stepkut> i am someplaces
00:15:21 <stepkut> I think I just used 16 + OS X yesterday to build clckwrks
00:16:25 <donri> time to wipe ~/.cabal :D
00:19:55 <donri> and now cabal is failing to upgrade itself ^_^
00:20:41 <donri> ah had to wipe .ghc too
00:21:51 <donri> stepkut: new pipes released
00:25:12 <donri> this one is supposed to support parsing
00:29:30 <stepkut> epic!
00:29:42 <stepkut> next someone needs to fix bug #104 in fay
01:03:40 <donri> fails with clean .ghc .cabal too
01:04:58 <donri> gonna try again without -j
01:16:10 <donri> i want a package with pathtype-style phantom types and system-filepath-style correct handling of encodings
01:23:04 <donri> fails without -j too
01:23:26 <adnam> stepkut: i can perhaps take a look at it today, haven't had time yet
01:30:16 <donri> and again, built fine with cabal 14
01:31:16 <donri> stepkut: i bet it's your custom setup.hs
01:31:24 <donri> but the error is completely not helpful/existent
01:44:15 <donri> yep, it builds fine with build-type:Simple and no build-tools:trhsx on cabal 16
01:46:04 <donri> seems to work with runghc Setup.hs install, with no changes though
01:48:31 <stepkut> so.. what does that mean?
01:48:56 <donri> maybe that cabal-install 16 is broken for build-type:Custom ?
01:49:22 <donri> do you recall if you used cabal-install or setup.hs when you installed
01:49:25 <donri> yesterday
02:00:18 <stepkut> dunno
20:03:40 <stepkut> it seems like yesod uses type classes as a way to create 'global variables' in a number of places :-/
20:09:09 <luite> how bad is that?
20:38:47 <stepkut> in the recents yesod widgets example, things were hardcoded at compile time that I would usually configure via runtime flags
20:39:24 <stepkut> since those values were pure values like, fooRoot :: Text, there is no way to change them aside from recompiling.. you couldn't just override them with a command-line flag
20:47:49 <luite> often they get a Yesod foundation type argument, fooRoot :: Yesod y => y -> Text
21:02:12 <stepkut> yeah, which is static
21:04:54 <luite> stepkut: you can fill the yesod datatype at startup, from a config file for example. but you cannot change these config things while running the program
21:05:31 <stepkut> well, the things I saw were, like, fooRoot _ = "http://example.org/something.js"
21:05:56 <stepkut> so, that implies the value is determined entirely at compile time since the value is not even examined
21:06:08 <luite> right, that's a static value, but if you want to make it configurable itbecomes fooRoot y = getSomeField y
21:07:15 <stepkut> i guess the _ makes them global constants instead of global variables :)
21:07:47 <stepkut> but I do see how it could be made configurable
21:08:25 <luite> it's more or less like ghc's static flags, that are loaded at startup, cannot be changed by the api
21:08:41 <luite> of course the ghc folks thinks they should be removed since they make the ghc api less flexible :p
21:08:48 <stepkut> ghc is not exactly a shining example of good haskell code :)
21:09:26 <stepkut> ghc is a good example of Haskell being pretty robust in the terms of long term large scale changes
21:10:45 <luite> my own code probably isn't much better than ghc :)
21:10:49 <luite> probably worse...
21:15:27 <stepkut> so, nt yesod, it seems like they use type classes as a form of abstraction.. like this function depends on having '(SomeConfig master) => ' available. I used to think that was cool.. but know I don't for some reason :-/
21:16:24 <stepkut> i should figure out why and see if it is a legit reason or not
21:16:42 <luite> do you know a good alternative?
21:16:59 <luite> it's pretty convenient this way to make hierarchies of dependencies
21:17:15 <luite> but i guess it might not scale with all the implicit arguments in generic library code
21:18:15 <stepkut> how about.. you just pass in a record of the value you want explicitly instead of using a dictionary and passing them in implicitly?
21:18:16 <stepkut> not sure..
21:19:11 <luite> i think snap uses some explicit initialization code for every part
21:20:53 <luite> but these typeclass "hacks" are used for a lot of very small info things, "i know a jquery url" etc, i think michael disliked having to load config explicitly for all of those
21:21:32 <luite> I've never really thought properly about alternatives though
21:33:28 <stepkut> well, you can create a record with the default values.. you don't have to explicitly load them from disk
21:36:25 <luite> stepkut: that would still require some infrastructure to get the right record. say I'm in some handler monad, and i want to statically require that i can get a piece of jquery configuration from it, how?
21:37:34 <stepkut> in yesod you would have something like, foo :: (SomeJQueryWidget master) => ..., but you could just do, foo :: SomeJQueryWidget -> ... ?
21:38:20 <stepkut> if you don't want to pass it around explicitly, then just put it in a ReaderT ?
21:39:23 <luite> stepkut: hm what would the type sig then look like?
21:40:46 <luite> the idea is that i can for example make a form field that requires jquery, with only the YesodJQuery constraint on "master", otherwise i don't have to do anything to use that kind of fields, my monad stack stays the same, no extra parameter passing
21:40:57 <stepkut> ok, so in yesod we curretly have a type like:
21:40:58 <stepkut> plot :: (YesodJquery master, YesodJqplot master) => PlotSettings -> GWidget sub master ()
21:42:02 <stepkut> but.. you could have something like this instead, plot :: PlotSettings -> GWidget (YesodJquery :+: YesodJqplot) ()
21:42:12 <stepkut> ?
21:43:35 <stepkut> for a GWidget that is defined differently :)
21:44:15 <stepkut> not sure
21:44:17 <stepkut> I know I don't like the type-class route :)
21:44:32 <luite> dunno, how does that improve things?
21:45:26 <stepkut> less type classes ;)
21:45:26 <stepkut> s/less/fewer/
21:45:45 <luite> well if that's a goal :p
21:46:20 <stepkut> i think it is a good one
21:46:29 <stepkut> but, to really figure things out I would have to implement an alternative method and do a side-by-side comparison
21:46:50 <luite> hm, i'm not sure... though this config stuff is a bit of an abuse of typeclasses i guess
21:46:58 <stepkut> right now I am just going on the fact that I used to do things that way, and now I don't
21:46:58 <stepkut> I'm going to assume I had some reason :)
21:47:14 <luite> i have to admit that i haven't touched yesod very much lately :)
21:47:43 <stepkut> well.. that would be more interesting if it was because you have been to busy writting happstack code :)
21:48:23 <luite> hehe unfortunately not
21:48:25 <stepkut> s/to/too/
21:51:02 <stepkut> in other news.. pipes-2.4.0 \o/
21:51:59 <luite> yeah i saw it
21:52:03 <stepkut> proxy transformers \o/
21:52:13 <luite> still haven't used pipes though
21:52:34 <stepkut> we really need 2.5 before we can truely make a pipes based http backend
21:52:38 <stepkut> but 2.4 is useful enough to fake it
21:53:10 <stepkut> with 2.5 we can guard against upstream pipe termination
21:59:45 <luite> ah