--- Log opened Thu Sep 10 00:00:25 2009
01:37 < jmcarthur> man, i really wish happstack-state didn't rely on TH so much
01:37 < jmcarthur> if you find a bug in the TH you are screwed
01:38 < jmcarthur> "Instances should not be defined directly, but using mkMethods" ... helpful documentation for the Methods type class there
01:38 < jmcarthur> yes, i will check the open tickets / submit the bug, when i get around to it
01:39 < jmcarthur> the thing is, it doesn't even seem like this would be that hard to write manually, once you reverse engineer the TH
01:50 < SubStack> jmcarthur: agree
01:51 < SubStack> I've been looking into just that
01:51 < jmcarthur> i mean, i can see the TH being around for convenience
01:51 < jmcarthur> i just don't want it to be required
01:52 < jmcarthur> and i want the documentation to explain how to do things with TH
01:52 < jmcarthur> *without
01:52 < SubStack> who knows how much of it will still work with haskell prime
01:53 < jmcarthur> there, success! i have successfully reverse engineered what i needed
01:54 < jmcarthur> thank god for -ddump-splices
01:55 < SubStack> neat
01:56 < jmcarthur> apparently if a method has a type variable but doesn't use it in an argument then mkMethods fails
01:57 < jmcarthur> can be gotten around by using scoped type variables and annotating the Update/Query pattern appropriately in the definition for methods
01:59 < jmcarthur> well, where "gotten around" means "gotten around once you have made the TH magic go away"
01:59 < SubStack> if only it were non-trivial to serialize functions
02:01 < jmcarthur> that would be nice for so many things
02:02 < jmcarthur> distributed computation would be almost easy
02:02 < jmcarthur> besides deciding which node should do what, of course
02:05 < SubStack> I've thought about using the foreign interface to grab the pointer address
02:06 < jmcarthur> eek
02:06 < jmcarthur> you would have to visit a lot of pointers if you are trying to serialize a closure
02:07 < SubStack> well, at least to uniquely identify one
02:07 < jmcarthur> and it wouldn't work on different architectures
02:07 < SubStack> unique identification would be good enough for some purposes
02:07 < jmcarthur> ah
02:07 < jmcarthur> just say "this is function X" not "this is function X with parameters Y and Z applied"
02:08 < jmcarthur> doesn't sound so nice to me, though
02:09 < jmcarthur> i'm not even sure it would be optimization safe
02:09 < SubStack> if only yhc were further along
02:12 < SubStack> admittedly, I have no idea how far along yhc is
02:12 < SubStack> ick, scons
02:15 < SubStack> there is a yhccore in hackage, this confuses me
02:16  * SubStack wonders how hard it would be to get ghc to share data with yhc
14:14 < burp> I want to use hdbc with happstack, I planned to embed a Reader or State monad into it, and save the database connection in it
14:14 < burp> but I want to keep the connection persistent
14:14 < burp> and not reset it on each request or open a new one
14:14 < burp> and as I understood happstack restarts the state each time
14:15 < burp> how to do it then?
14:22 < jmcarthur_work> burp, open the connection outside of the ServerT stuff and pass it in
14:22 < burp> hm, right
14:22 < jmcarthur_work> like main = do conn <- openConnection ; runServerT (<use conn here>)... or whatever... been a while since i did top level ServerT stuff, so that is probably not the right identifiers, but you get the idea
14:45 < burp> hm yup :>
14:49 < burp> http://stackoverflow.com/questions/1141677/concurrent-db-connection-pool-in-haskell
17:19 < Dunearhp> Persistence is one of the most common changes required for web frameworks
17:20 < Dunearhp> I've just started learning happstack and that is one of the most frustrating issues I've had
17:21 < Dunearhp> the happstack tutorial has a StateT Example
17:21 < Dunearhp> http://tutorial.happstack.com/src/StateTExample.hs
17:22 < jmcarthur_work> well, StateT is not for persistence
17:22 < Dunearhp> that highlights the trivial use of a stateful handler without showing how to make it persistent
17:22 < jmcarthur_work> ah, you know this ;)
17:23 < Dunearhp> I'd like to know how to modify that example to be persistent
17:23 < Dunearhp> I'm still getting my head around it all
17:24 < jmcarthur_work> unfortunately, it's a lot more involved than StateT
17:25 < jmcarthur_work> that tutorial does cover happstack-state though
17:25 < jmcarthur_work> http://tutorial.happstack.com/src/FirstMacid.hs
17:28 < Dunearhp> the thing is that that doesn't tell me how to splice it into the happstack server
17:34 < Dunearhp> I ended up trying to use the tutorial's own server as an example, but it is more complex, and has more dependencies than a beginner can easily cope with
17:43 < jmcarthur_work> you just use IO to perform the atomic methods in happstack-state
17:43 < jmcarthur_work> you don't really mix in the MACID monad or anything like that
18:37 < mightybyte> Dunearhp: You might check out some of my blog posts at http://softwaresimply.blogspot.com.  I discuss Happstack's persistence system in several posts.
18:37 < mightybyte> Some of the posts are old and out of date, but the basic concepts still apply.
18:38 < mightybyte> In the posts about happstack-auth, I use Happstack's state system to persist a user database.
18:51 < ray> it would be great if someone could do something about http://code.google.com/p/happstack/issues/detail?id=105
19:33 < jmcarthur> i see a patch there already
--- Log closed Fri Sep 11 00:00:27 2009