--- Log opened Fri Jan 30 00:00:12 2009
00:37 < mae> wchogg: you've been busy!
01:31 < h_buildbot> Build for ghc-6.8.3 just succeeded. See http://buildbot.happstack.com/ghc-6.8.3/
01:36 < h_buildbot> Build for ghc-6.10.1 just succeeded. See http://buildbot.happstack.com/ghc-6.10.1/
01:38 < mae> anyone think we need to keep the xml files for searchpath
01:46 < h_buildbot> Build for ghc-6.8.3 just succeeded. See http://buildbot.happstack.com/ghc-6.8.3/
01:51 < h_buildbot> Build for ghc-6.10.1 just succeeded. See http://buildbot.happstack.com/ghc-6.10.1/
01:59 < Axman6> no lambdabot? :O
02:10 < sm> hi Axman6
02:10 < Axman6> o/
02:10 < sm> there's stepbots..
02:14 < Axman6> so, happstack is an effort to (among other things) improve documentation?
02:15 < Axman6> because, the curent happs docs are pathetic really :\ need some good tutorials and examples (happs-tutorial never worked well for me, there needs to be some variety)
02:24 < sm> Axman6: definitely.. see the recent discussion on happs mail list
02:24 < sm> I'm sure your help would be welcome
02:34 < Axman6> yeah, looks like something i could get into :)
02:59 < mae> Axman6: welcome :)
03:00 < Axman6> i doubt i could help much though :\
03:04 < Axman6> haddock docs is something i'm looking forward to
03:48 < mae> 4 issues to go
03:48 < mae> http://code.google.com/p/happstack/issues/list?q=label:milestone-0.1
03:49 < mae> wchogg: when you get in please make note of what I said in the comments for issue #3
03:50 < mae> night
04:03 < Axman6> i was having a read of http://code.google.com/p/happstack/wiki/WhatToEmulateRoR, and i think that one other thing that can be learnt from RoR is their default project template thing... no idea what it's called. but the thing where you tell it where you want your project, and it creates a default, working project
04:03 < Axman6> got to be one of the best fetures of RoR
04:26 < mae> yeah i agree that is neat
04:26 < mae> like a skeleton to start with
04:26 < mae> to get bootstrapped
04:27 < Axman6> yep, exactly
04:27 < Axman6> something that you can just compile and run, and you'll get a (nice looking) page
04:57 < Axman6> i'd love to have a haskell version of something like movable type
05:29 < Saizan> to get a project template we'd have to decide what the default way to construct an happstack application is :)
05:30 < Axman6> well, make a decision then. having something that doesn't fit what everyone wants is better than nothing at all :)
05:33 < Saizan> what do you think it should include?
05:33 < Axman6> it shoud be a simple hello world type thing
05:34 < Axman6> emulating the default RoR one wouldn't be a bad place to start
05:34 < sm> happs.org gives you a hello world app
05:35 < sm> happstutorial.com's repo is a more complex app, using thomas's smartserver instead of simpleHTTP
05:35 < Axman6> well, something like that then (slightly better looking though...)
05:35 < Saizan> i guess it should also include something about state
05:35 < Axman6> yeah
05:38 < Saizan> uhm, i wonder if we can write something small enough but also somewhat useful
05:40 < Axman6> needs to have a nice, clear filesystem layout too. keeping related things together
05:41  * Axman6 is checking out happs.org
05:41 < Saizan> that's something i've always hated about webapps, why do i need a filesystem layout?
05:42 < Axman6> well, if all you want to do it change the colour of your header, then you don't want to have to go looking through a bunch of html and haskell files just to find the one you want
05:43 < Saizan> i wouldn't run my application from the source tree
05:44 < Saizan> however yes, for static files you need to put them somewhere..
05:46 < Axman6> i kind of like the way movable type works, you get a dir with some cgi and static files, you copy the static dir to your server's content dir, make a server writable dir for your blog, and copy everything else to your cgi-bin
05:46 < Axman6> though, it could be a lot better i guess
05:48 < Saizan> happs doesn't really fit in cgi though, more like fcgi, and however i'd not make use of a standalone server in a "hello world" application
05:48 < Saizan> s/standalone/separate/
05:49 < Saizan> there are so many choices :)
05:50 < Axman6> well, would it be possible to make something that could be used standalone, or through fcgi out of the box?
05:51 < Saizan> standalone is the default, i.e. you compile your program and launch it as your webserver
05:54 < Axman6> what about fcgi?
05:56 < Saizan> there's code for that but not in happstack, it's basically a thin adapter between the fgci and the HAppS.Server.SimpleHTTP interface
05:59 < Axman6> looks like the happs.org stuff is a good place to start
06:05 < Axman6> though, i am confused why there's css files in the js dir
06:09 < Axman6> my only problem is... htf does index2.html work
06:15 < Axman6> how the hell does it get the info for things like HAppS-HTTP?
06:16 < Saizan_> js, i think
06:17 < Axman6> but... where does it say to get the stuff?
06:19 < Axman6> seems like a terrible example. it's doing something cool, and it doesn't seem to actually be coded anywhere at all
06:20 < Axman6> ah, found it
06:22 < Axman6> it's in a very strange place
06:51 < Axman6> also, i think it'd be nice if there was a nice way to do ajax, using only haskell, which produces the necessary js
09:28 < wchogg> mae : You meant the note about 'internal name?' errors?  In a similar vein, it looks like the "defined, not used" warnings with TH generated names are coming from SYB-With-Class so I'm not sure how much we can do about them yet.
10:49 < stepcut> wchogg: I have a patch for that, btw. But it is a patch against syb-with-class.
10:50 < stepcut> it's a pretty trivial patch
10:56 < stepcut> I attached a patch to bug #3.
10:57 < Saizan_> i'm apparently  the new maintainer of syb-with-class :)
10:58 < stepcut> sweet!
10:58 < stepcut> well, apply my patch then ;)
10:58 < stepcut> http://happstack.googlecode.com/issues/attachment?aid=8455658829178510135&name=defined_by_not_used.dpatch
10:59 < Saizan_> done!
11:00 < Saizan_> http://patch-tag.com/publicrepos/syb-with-class
11:00 < stepcut> yay!
11:02 < stepcut> I updated the bug.
11:02 < Saizan_> very simple fix, indeed :)
11:03 < Saizan_> iirc, there are some derivations that leak internal definitions into the toplevel scope of the module
11:11 < mae_work> Saizan_: since you now have http://patch-tag.com/publicrepos/syb-with-class, are you going to put in that missing instance fix too?, and are you going to upload a version bump to hackage before wednesday? :)
11:13 < mae_work> if that fixes http://code.google.com/p/happstack/issues/detail?id=11 then we could close it :)
11:14 < Saizan_> yes, yes :)
11:14 < mae_work> Saizan_: yay!
11:15 < Saizan_> unless there's some technical problem in contructing a fully functioning instance
11:17 < wchogg> Looks like we're almost done with all the stuff for 0.1
11:17 < wchogg> Awesome
11:18 < Axman6> :)
11:19 < stepcut> I am going to duplicate the testing framework from happstack-util into all the other modules, and add the top-level testsuite unless someone complains
11:24 < Saizan_> do we need to depend on quickcheck and hunit even if tests is off?
11:31 < mae_work> Saizan_: i was thinking the same thing
11:31 < mae_work> Saizan_: although i think quickcheck and hunit are part of ghc now
11:31 < mae_work> both 6.8.3 and 6.10.1
11:31 < mae_work> correct me if i'm wrong
11:50 < Saizan_> they are
11:51 < Saizan_> but unnecessary dependencies make the work of cabal-install harder :)
11:52 < Saizan_> e.g. if you try to use happstack in a library where you require a different version of quickcheck it'll either try to rebuild happstack or fail if it can't
11:53 < Saizan_> that's because if you combined the types coming from the two different errors you'd get a type error
11:54 < Saizan_> s/different errors/different versions/
11:54 < stepcut> Saizan_: happstack-util depends on quickcheck and huint because it provides HAppS.Util.Testing, which has some functions to turn quickchecks into unit tests.
11:55 < Saizan_> ah, then ok
11:55 < stepcut> none of the other modules will depend on quickcheck/hunit unless they are built with testing enabled
11:55 < stepcut> though, if they depend on happstack-util, then it does not really matter
11:59 < Saizan_> yeah, but if we indeed use them then it's legit
11:59 < Saizan_> having an -util is somewhat questionable in the first place
12:00 < stepcut> Saizan_: what's the alternative?
12:02 < Saizan_> make libraries with a clear purpouse, or push back something in pre-existing libraries
12:03 < wchogg> Saizan_ : Now that you say that, why don't I change my ticket for looking removing HAppS-Util/Crypto to just be generally about pruning HAppS-Util of as much as possible.
12:06 < stepcut> Saizan_: I think HAppS-Util needs to exist so that things can happen quickly, but treating it as a hopefully temporary home for functions seems like a good idea
12:07 < Saizan_> stepcut: yeah, at least having such things in one place makes judging what to move out easier
12:07 < stepcut> my Extra library has a module, Extra.Misc
12:07 < stepcut> :)
12:08 < Saizan_> that's two places! :)
12:08 < gwern> 'and the fleas have fleas that bit'um and so on ad infinutum'
12:08 < stepcut> :)
12:09 < Saizan_> organizing code is way harder than writing it..
12:10 < stepcut> Extra has lots of things like, Extra.List, Extra.Either, etc. But Extra.Misc is for the extra random stuff
12:10 < gwern> Saizan_: really? I've always found the reverse
12:11 < Saizan_> wchogg: the Crypto ticket is quite concrete, i'd leave it like that
12:11 < stepcut> happstack will be perfect when there is no code left to remove
12:12 < Saizan_> s/ to remove/./
12:12 < Saizan_> ;)
12:13 < Saizan_> gwern: i often find that the problem is not "how do i do this?" but "how do i do this elegantly?"
14:10 < mae_work> re: HAppS-Util library, I agree that alot of this stuff is redundant or not utilized. This stuff should be localized where it makes sense. Additionally, if there are utilities that glue the packages together this can go in the future yet-to-be-named Happstack.Glue/Happstack.Integration that we will set up in 0.3 onward
14:13 < Saizan> localized?
14:13 < mae_work> meaning
14:13 < mae_work> localized to the place where the code is used
14:13 < stepcut> what if it is used in multiple modules?
14:13 < mae_work> its presumptuous to think that HAppS-Util will be useful to anything except HAppS
14:14 < stepcut> sure
14:14 < mae_work> stepcut: can you give me a use case?
14:14 < mae_work> right now the packages server very different purposes
14:14 < stepcut> multiple happstack libraries need to use functions defined in HAppS.Util.Testing
14:15 < mae_work> stepcut: ok, any reason that cannot go in the future 'Glue' library
14:15 < mae_work> its only a test dependency right?
14:15 < stepcut> because the glue library is at the wrong end of the dependency graph...
14:15 < mae_work> stepcut: yeah i just considered that :)
14:16 < stepcut> glue depends on happstack-server, happstack-data, etc, which in turn depend on happstack-util
14:17 < mae_work> well it sounds like test might belong in its own module
14:17 < Saizan> -util is the dual to -glue :)
14:17 < mae_work> Saizan: true
14:17 < mae_work> well not relaly
14:17 < mae_work> because i was envisioning glue to be
14:17 < mae_work> err
14:17 < mae_work> to include userland utitilities
14:17 < Saizan> though i think identifying which code we don't think belongs in happstack but we're only forced to write is a good thing
14:17 < mae_work> like 'happstack <dir here>'
14:18 < mae_work> the whole rails concept
14:18 < stepcut> in theory you could merge -util and -glue if you don't mind circular dependencies ;)
14:18 < mae_work> we give some skeleton code
14:18 < mae_work> stepcut: hehe that sounds messy
14:18 < stepcut> mae_work: it is... you have to make boot files and stuff
14:18 < Saizan> ah -glue should be the famous skeleton project? i thought it was intended to be a library
14:18 < mae_work> stepcut: my original thought was simply to have tests be completely separate from the packages
14:19 < mae_work> but now that your using the cabal test functionality
14:19 < mae_work> that changes thing
14:19 < stepcut> mae_work: I am not actually using cabal test at the moment
14:20 < mae_work> stepcut: what do we gain by having the extra test functionality
14:20 < mae_work> ease of end-user test participation?
14:20 < mae_work> (on diff archs?)
14:20 < mae_work> s/extra test functionality/cabal test functionality/
14:21 < stepcut> at this point in time, probably not much, which is why I did not hook it up. Eventually cabal is going to have better integration with test suites though
14:22 < mae_work> stepcut: ok, well, lets hold off on the cabal test bits then, the test suite can be treated as an independent unit
14:23 < mae_work> this makes the dependencies much simpler
14:23 < stepcut> does it ?
14:23 < mae_work> well, yes, meaning the modules are simply ignorant of the test code
14:23 < mae_work> it is decoupled
14:23 < mae_work> so we don't end up having to worry about circular dependencies if we turn util into a generalized glue module
14:23 < stepcut> they are largely decoupled already...
14:24 < mae_work> stepcut: i am thinking out loud here, tell me where your coming from
14:24 < Saizan> i don't see how -util can become -glue, by seeing the contents of it
14:24 < mae_work> I am simply looking to have a test suite to help improve the quality of the codebase
14:24 < stepcut> the circular dependency thing happens if you take any currently used function from -util and put them in -glue
14:24 < mae_work> stepcut: right
14:24 < mae_work> so i see two sides of the equation here with different benefits and drawbacks
14:26 < mae_work> if util and glue are married, we have less total modules, on the other hand, if the test boilerplate is in there as well, it makes it kind of hairy if we want to import this module later with cabal test
14:26 < stepcut> util and glue can never be merged
14:26 < mae_work> if we keep them separate, it allows us to have semi-reusable code in util, and naughty coupled code in glue
14:26 < mae_work> and allows us to do cabal test later
14:26 < stepcut> the stuff in util isn't glue code...
14:26 < mae_work> yeah your right, i like that solution better
14:27 < stepcut> these issues aren't even related
14:27 < stepcut> cabal test has nothing to do with the merging of -util and -glue
14:28 < stepcut> or maybe I don't understand -glue
14:30 < stepcut> if -glue imports anything from happstack-server, happstack-data, happstack-ixset, etc. then none of those modules should be importing anything from -glue.
14:31 < stepcut> imagine you have no happs on your system. You want to build happstack-server, but opps, it depends on happstack-glue. So you go to build happstack-glue, but, oops, it depends on happstack-server?
14:34 < stepcut> so, happstack-utils is where you put functions that any of the other happstack-* packages depend on. And happstack-glue is where you put the functions that require functions from the other happstack-* packages. And none of the other happstack-* packages can depend on -glue.
14:36 < mae_work> yep
14:37 < mae_work> nice summary
14:37 < stepcut> so, this is completely unrelated to the test framework
14:37 < mae_work> glue can only have a one-way dependency to the other happs packages
14:37 < mae_work> stepcut: yeah i guess I was more thinking about the package semantics
14:37 < stepcut> right, cabal can't handled a circular dependency across packages
14:38 < mae_work> stepcut: in summary, everything you have concluded on so far has been right and sane, and I should just stay out of it :)
14:38 < stepcut> doing circular depends is already hard enough, and it is typically best to assume it can't be done :)
14:38 < stepcut> there is one issue left
14:38 < mae_work> so util will stay
14:38 < mae_work> glue will probably be called something else
14:38 < stepcut> whether the tests should be completely in their own separate package or not
14:39 < mae_work> stepcut: are we able to, with cabal, build without tests by default?
14:39 < mae_work> so the deps don't kick in
14:39 < wchogg> hydo : I've been working a good bit on the warnings suppression.  I should be done well before wednesday.
14:39 < stepcut> mae_work: yes. in fact, the default right now is to build with out tests.
14:39 < hydo> wchogg: sweet1  I'll update the ticket.  Thanks!
14:39 < stepcut> wchogg: did you see that we patched syb-with-class?
14:40 < wchogg> stepcut : yup, so I'll install the darcs syb-with-class.
14:40 < mae_work> stepcut: excellent
14:40 < wchogg> There's barely any warnings left, honestly.
14:41  * mae_work waits for version bump on http://hackage.haskell.org/cgi-bin/hackage-scripts/package/syb-with-class-0.4
14:41 < mae_work> wchogg: internal name?
14:41 < stepcut> mae_work: now, currently happstack-util does currently depend on quickcheck and hunit because of the (non-happstack specific) utility functions I added HAppS.Util.Testing
14:41 < Saizan> mae_work: i'll probably add the instances tomorrow and then release
14:42 < wchogg> mae_work : those I haven't checked yet.  I just meant in general, most of the work is done.
14:42 < stepcut> mae_work: i *could* make that module only exported if you compile with tests enabled, that would be a little weird.
14:42 < wchogg> Saizan : Cool!
14:43 < stepcut> mae_work: since ghc ships with quickcheck and hunit I am inclined to leave those dependencies for now...
14:45 < mae_work> stepcut: don't worry about the util dep for now :) i'm sure in time we will see clarity.
14:45 < mae_work> we will see clearer *
14:45 < Saizan> stepcut: isn't .Testing the same code that is in http://hackage.haskell.org/cgi-bin/hackage-scripts/package/testpack ?
14:46 < stepcut> Saizan: yes, I wrote the code that is in Testing and submitted it to John G. But testpack is LGPL and happstack is BSD3. Seemed easier to just include the functions than deal with license issues.
14:47 < mae_work> wchogg: k, well what i found is that the problem is really with the template haskell funs that are defined in DeriveAll, until we fix $deriveAll, nothing much we can do about it unfortunately.
14:47 < mae_work> : )
14:48 < mae_work> stepcut: where is the chinese wall?!? what if SCO claims ownership of that code and sues our ARSES! FUD FUD FUD
14:48 < mae_work> j/k :)
14:49 < stepcut> mae_work: yeah, the hunit/quickcheck depends issue can be 'solved' without any big changes to the current testsuite layout.
14:49 < wchogg> mae_work : Oh, right!  I got confused between those & the "defined/not used" ones that stepcut's syb-with-class fix fixed.
14:49 < wchogg> mae_work: sorry bout that.
14:49 < Saizan> ah, i didn't pay attention to the license, it's a shame something like that is LGPL though, it's not like it takes any effort to reinvent the wheel
14:49 < stepcut> Saizan: he didn't give me credit either :p
14:50 < stepcut> bastard stole my code and licensed it under the LGPL. I feel like theo
14:50 < stepcut> :p
14:50 < Saizan> ah, nice :D
14:51 < wchogg> stepcut : seriously?  He literally took your work & didn't give you any attribution?
14:51  * stepcut double checkes
14:51 < mae_work> wchogg: it happens :)
14:52 < stepcut> speaking of which, that code might need some attribution. It is very close to the code in QuickCheck
14:52 < wchogg> mae_work : Shh!  I'm trying to work myself into righteous indignation!  ;-)
14:53 < stepcut> wchogg: as far as I can tell my name does not appear anywhere in the package
14:53 < mae_work> wchogg: i don't see any builds since 2am after i pushed, have you submitted any patches? maybe the buildbot is broken
14:53 < wchogg> I haven't submitted anything this morning.
14:53 < mae_work> ahh ok
14:53 < wchogg> I slacked off this morning. :p
14:54 < mae_work> isn't slacking awesome?
14:54 < mae_work> at least for a little while :\
14:54 < wchogg> mae_work : Right!  For a morning it's awesome.  For a day it's maddening.
14:54 < sm> morning all
15:00 < stepcut> mae_work: http://seereason.com/~jeremy/depends.ps
15:00 < stepcut> ;)
15:06 < mae_work> stepcut: neato :)
15:06 < mae_work> did you make this with dia?
15:06 < mae_work> the arrows feel intuitively backwards
15:06 < mae_work> the arrow doesn't mean "depends on this"
15:06 < stepcut> graphviz, and you are right.
15:07  * stepcut fixes it
15:07 < mae_work> it means "this depends on me"
15:07 < mae_work> right now
15:08 < stepcut> fixed
15:08 < mae_work> right ok
15:08 < mae_work> so happstack glue depends on all
15:09 < stepcut> in theory it could
15:09 < mae_work> each individual module only depends on util (for testing at the very least)
15:09 < stepcut> in practice all of those lines are optional
15:09 < mae_work> right
15:09 < mae_work> but anything that ties the stuff together should be in glue
15:09 < Saizan> there are also some lines between the components
15:09 < stepcut> mae_work: yes, and then only need to depend on util for testing when actually build with testing enabled
15:09 < stepcut> right
15:10 < mae_work> so we are kind of seeing happstack-util
15:10 < mae_work> as an internal reuse bin
15:10 < mae_work> probably not too valuable in its own right -- as it will be slanted towards our purposes
15:11 < mae_work> semantically then, if we were to have userland scripts like 'happstack' that makes a skeleton project
15:11 < Saizan> yeah, or "there isn't anything like this on hackage but we don't want to make a specific library yet"
15:11 < mae_work> where would this belong
15:11 < mae_work> probably in the glue package
15:11 < mae_work> right?
15:12 < Saizan> it depends, are those code examples supposed to be edited, or reusable components?
15:12 < mae_work> edited
15:12 < mae_work> and they probably call various libraries
15:12 < mae_work> with such an item there might not be an explicit library dependency
15:12 < mae_work> but it is an understood dependency
15:12 < Saizan> then they don't really belong in a package, at least in the Cabal sense
15:12 < mae_work> as boilerplate is generated which will depend on those things
15:13 < mae_work> Saizan: happstack-glue is probably a misnomer
15:13 < mae_work> happstack glue I see as being the integration package
15:13 < mae_work> so it will have all the tools that assume you are using the whole stack
15:13 < Saizan> yeah, but this integration package is supposed to be a library or not?
15:13 < Saizan> where we define things like webQuery for example
15:13 < mae_work> it is a library, but not in the traditional sense
15:14 < Saizan> why not?
15:14 < mae_work> i guess in debian-speak it would be a dummy package, or meta package, which has some other odds and ends
15:14 < mae_work> it has a meta dependency on the whole stack
15:14 < mae_work> because the generated code from 'happstack myproj' will need those libraries
15:14 < mae_work> so assuming someone has cabal install
15:14 < mae_work> they can do
15:15 < mae_work> 'cabal install happstack-glue'
15:15 < mae_work> and then 'happstack myproj'
15:15 < mae_work> and that is all it takes to get up and running
15:15 < Saizan> ok, but there's code we can't have in any of the packages if we want to keep them as indipendent as possible from each other
15:15 < stepcut> mae_work: ok, updated
15:15 < Saizan> i thought we would have a separate library for that
15:15 < mae_work> Saizan: right, and that is precisely the purpose of happstack-glue (needs another name)
15:15 < mae_work> it will serve as a meta/dummy package
15:16 < mae_work> and also have some tools
15:16 < Saizan> so, will it contain a library or not? :)
15:16 < mae_work> Saizan: define library
15:16 < mae_work> you mean haskell code?
15:16 < Saizan> in the ghc-pkg/Cabal sense of library
15:16 < mae_work> yes it will
15:17 < mae_work> but the code will be mainly centered around 'tools'
15:17 < stepcut> Saizan: well, it should contain a library no matter what. The happstack executable that generates a template should be a very thin wrapper around a library that does all the work, so that you can intergrate that functionality into you own application easily ;)
15:17 < mae_work> stepcut: yep
15:17 < mae_work> so thats what you meant :)
15:18 < mae_work> i imagine there will be lots of misc bits of glue
15:18 < mae_work> and that will also be part of the lib
15:18  * stepcut is frustrated to no end that you have to fork of a call to 'mv' instead of using libbinutils
15:18 < stepcut> s/fork of/fork off/
15:19 < stepcut> mae_work: I added the extra intramodule depends to the graph for ya :)
15:19 < mae_work> can you make two versions
15:19 < mae_work> label this one as 0.1/0.2
15:19 < stepcut> heh
15:19 < mae_work> and the former as 0.3/0.4
15:20 < mae_work> and then we can put on the wiki
15:20 < stepcut> well, HAppS-IxSet will still depend on HAppS-Data.
15:20 < stepcut> and HAppS-State might depend on HAppS-Data, or a new module that does not exist yet.
15:21 < mae_work> well
15:21 < mae_work> the idea is to decouple them
15:22 < mae_work> so ideally they won't interdepend
15:22 < mae_work> if you want you can label it 'ideal 0.3/0.4'
15:22 < mae_work> or 'goal 0.3/0.4'
15:22 < stepcut> regarding happstack-util, we discussed the idea earlier that there should be an ongoing effort to remove things from happstack-util by pushing patches upstream, or creating new non-happstack packages that get upload to hackage
15:22 < mae_work> or 'tentative in no way set in stone 0.3/0.4'
15:22 < mae_work> : )
15:22 < mae_work> i just think we could use the visuals on the wiki
15:23 < stepcut> mae_work: regarding state<->data, it is not clear that the $deriveSerialize functions belong in state anymore than they belong in data.
15:23 < mae_work> stepcut: util :)
15:23 < stepcut> mae_work: and I have used the serialize/migration stuff with out the happs-state stuff
15:23 < stepcut> util is even more wrong!
15:23 < mae_work> generalize them, then util
15:23 < mae_work> or glue :)
15:24 < mae_work> it needs more discussion thats for sure
15:24 < mae_work> i concede
15:24 < stepcut> util is for that stupid stuff that *should be* upstream but isn't. and we already discussed why it can't go in glue ;)
15:24 < mae_work> why not in glue?
15:25 < mae_work> it is a code generation function
15:25  * stepcut ponders
15:25 < mae_work> i mean
15:25 < stepcut> happs-state depends on happs-data for some reason.
15:25 < mae_work> ok lets push this to the future then
15:25 < stepcut> if you move that reason into happstack-glue, then you get the circular depends problem
15:25 < mae_work> when we understand more
15:26 < mae_work> for now lets assume we can decouple them :)
15:27 < stepcut> I am not sure the decoupling is any more sensible than decoupling IxSet from Data.Map, but we can figure that out later.
15:27 < mae_work> stepcut: well, for example, it could very well be that this 'reason' is perfectly valid -- well in that case we should see if the semantics could be changed so this isn't the case
15:27 < mae_work> or that we could use something more generalized or existing for the same thing
15:27 < mae_work> who knows, maybe user defined derive is right around the corner for ghc
15:28 < stepcut> right, but the state code neds to know how to migrate the data between versions, which is
15:28 < stepcut> why I think happs-state depends on happs-data
15:28 < stepcut> but, maybe it can be decoupled by making that interface more abstract
15:29 < mae_work> why does ixset depend on data
15:29 < stepcut> because ixset uses the extra generics functions in data
15:30 < mae_work> stepcut: my thought is simply that if they can't be effectively decoupled in a useful way, then they probably shouldn't be decoupled in the first place
15:30 < stepcut> at the very least, IxSet uses the Default class
15:30 < mae_work> ic.
15:31 < mae_work> well I could imagine using IxSet without default
15:31 < mae_work> IxSet w/ default could be in glue, for instance
15:31 < mae_work> or it could be so straightforward and easy to define the instance
15:31 < mae_work> that we just generate the code in the skeleton
15:31 < stepcut> mae_work: IxSet also has to be serializable, so it needs the migration stuff
15:32 < mae_work> why does it need to be serializable?
15:32 < mae_work> thats only if you want to write it somewhere, yes?
15:32 < stepcut> so that you can use it in your persistent store
15:32 < mae_work> stepcut: what i am saying is
15:32 < mae_work> i can use ixset without macid
15:32 < mae_work> it is a general purpose indexing data structure
15:33 < mae_work> with fancy query operators defined
15:33 < stepcut> yes, but if you want to Serialize it, you need a Serialize instance.
15:34 < stepcut> you can use most data types in Haskell without Data or Typeable, but they still have Data and Typeable instances for when you do need them...
15:34 < mae_work> ok, granted
15:35 < mae_work> so we have to depend on that thing to have the instance?
15:35 < mae_work> that kinda stinks :\
15:35 < stepcut> :)
15:36 < mae_work> i mean
15:36 < mae_work> i guess i just feel like
15:36 < mae_work> if ixset isn't useful in its own right
15:36 < mae_work> then it should just be part of data
15:36 < mae_work> its not that much code
15:36 < mae_work> its in the namespace, after all
15:36 < mae_work> HAppS.Data.IxSet
15:36 < stepcut> sure, but there might be lots of HAppS.Data.* someday, do you want them *all* in the same module?
15:37 < stepcut> should we put all of Data.* in the same tree?
15:37 < mae_work> they could be in the same module, sure.
15:38 < mae_work> is there no way to have the best of both worlds?
15:38 < mae_work> have the instances but only if you are using happstack-data
15:38 < stepcut> only if you make a third module that holds the instances, but then you get orphan instances
15:38 < stepcut> this is a shortcoming of haskell
15:38 < mae_work> right
15:39 < mae_work> ok so
15:39 < mae_work> let me compare these
15:39 < mae_work> 1. roll ixset into happstack-data
15:39 < stepcut> but, HAppS-Data is useful *without* IxSet or State, which is perhaps the argument for keeping those separate
15:39 < mae_work> 2. keep ixset separate, but put the instances for serialiazable in in happs-data
15:40 < mae_work> with 2 i guess it stinks that ixset is now a dep of happs-data
15:40 < wchogg> orphan instances only matter in terms of optimization, I thought, and there's nothing semantically wrong with them.
15:40 < stepcut> 2. won't work, that would be a circular dependency
15:40 < mae_work> but at least ixset can be used by itself
15:40 < stepcut> option 2 is, 1. happs-data in one package 2. happs-ixset in another 3. happs-ixset serialize and Default instances in 3rd integration package
15:41 < mae_work> why can't the instances be in happ-data?
15:41 < mae_work> happs data *
15:41 < stepcut> oh wait
15:41 < mae_work> happs-data can depend on ixset
15:41 < mae_work> but not the other way around
15:41 < stepcut> I forget ixset would not longer depend on data
15:41 < mae_work> yeah happs-data picks up a dependency
15:41 < mae_work> but you get the bonus of being able to use ixset outside of happstack
15:42 < mae_work> without the deps
15:42 < wchogg> I like that option.
15:42 < stepcut> it's kind of backwards
15:42 < stepcut> usually people create orphan instances because they don't have the ability to make the dependencies go the other way
15:43 < mae_work> stepcut: think about it like this, happstack-data adds nice persistence features of its on devising, it knows that ixset is already at the party, so it is going to bring the interface with it so that they can meet up.
15:43 < mae_work> on the other hand
15:43 < mae_work> ixset is a rebel without a cause, he has no need for happs-data if he just wants to hang out in memory and then leave when the ram loses power
15:43 < mae_work> why should he worry about all the baggage that happs-data is bringing into the relationship?
15:44 < stepcut> you have the problem either way though. If I just want to use happs-data to version my data, why do I have to build IxSet too
15:44 < mae_work> stepcut: because ixset is a really small amount of code
15:44 < mae_work> like stepping on a fly
15:44 < mae_work> the other way around is much more cumbersome
15:45 < mae_work> i just wanted an indexing data structure but they threw in the kitchen sink
15:46 < mae_work> in terms of tradeoff, someone who is using happs-data is already bringing on a buttload of code, whats a few more bits, with ixset i could feasibly use it by itself and it is very lightweight
15:46 < stepcut> well, I justed wanted versioned data and I got all these data structures I didn't want ;)
15:46 < mae_work> stepcut: 3 modules? :)
15:46 < mae_work> out of what, 20+?
15:46 < stepcut> sure, it starts with ixset, but soon there are dozens
15:46 < mae_work> hehe
15:47 < mae_work> ok, well
15:47 < mae_work> then in that case
15:47 < stepcut> maybe isxet could have *optionally* depend on happs-data
15:47 < mae_work> put orphaned instances in happstack-glue :)
15:47 < mae_work> stepcut: optional would be nice
15:48 < mae_work> stepcut: does cabal support something like that?
15:48 < stepcut> yes
15:48 < mae_work> what determines if the option is toggled or not
15:49 < stepcut> you set a default in the .cabal file, and when you configure you can also do, -f flag_name
15:49 < stepcut> that is how tests work
15:49 < stepcut> if you do, cabal install, you don't get them, but if you do, cabal install -f test, you do
15:49 < mae_work> but that can't be specified in build-depends can it
15:49 < mae_work> i.e.
15:49 < stepcut> it can
15:49 < mae_work> happstack-glue depends on ixset with data
15:50 < mae_work> really? how
15:50 < stepcut> Library
15:50 < stepcut>   Build-Depends:       mtl, hslogger >= 1.0.2, template-haskell, array,
15:50 < stepcut>                        bytestring, old-time, process, directory, extensible-exceptions,
15:50 < stepcut>                        HUnit, QuickCheck, random
15:50 < stepcut>   if flag(base4)
15:50 < stepcut>     Build-Depends:       base >= 4
15:50 < stepcut>   else
15:50 < stepcut>     Build-Depends:       base < 4
15:50 < stepcut>  
15:50 < stepcut> that is an example where compiling with, -f base4, will select between different versions of base
15:50 < stepcut> (that is from happstack-util)
15:50 < mae_work> ...
15:51 < mae_work> but what about the case where happstack-glue always needs the data instances
15:51 < mae_work> how can that be linked as a cabal dependency (not a build flag)
15:51 < stepcut> then you better compile things right
15:51 < mae_work> ok yeah i don't like that
15:51 < mae_work> : \
15:52 < mae_work> i think ixset should get absorbed into data
15:52 < mae_work> : )
15:52 < stepcut> well, my suggestion would be to enable it by default, but have an off flag for those that don't want it
15:52 < mae_work> hmm ic
15:52 < stepcut> mae_work: I knew you were going to try to merge everything into one package ;)
15:52 < mae_work> stepcut: not everything, I just don't want a cabal package with like 2 modules for god sakes :)
15:52 < stepcut> mae_work: why not?
15:53 < stepcut> parallel, containers, quickcheck, etc
15:53 < stepcut> all have only 2-5 modules
15:53 < mae_work> ok i retract that statement
15:53 < stepcut> and they ship standard with ghc
15:53 < stepcut> everything *used* to be in one giant package and the community has spent the last couple years splitting things into smaller pieces
15:54 < mae_work> what I don't like about this is that to me it seems that happstack-ixset by itself makes the statement 'i am a component useful in my own right' which is a falsification. Yeah ok so we could do the build flag thing but if we could avoid that so much the better.
15:55 < stepcut> happstack depends on many other packages though
15:55 < mae_work> stepcut: true, but these packages are in the same neighborhood
15:55 < mae_work> wife and husband, on two twin beds
15:55 < stepcut> ixset is useful on it's own right, it does not depend on state or server. It only depends on the things it needs like Data.Map, syb-with-class
15:55 < mae_work> instead of one queen
15:55 < mae_work> they sleep in the same room, everyone knows they are having sex, why not just end the charade? :)
15:57 < wchogg> Ah!  My delicate sensibilities.
15:57 < mae_work> wchogg: i apoligize, sir wchogg the chaste.
15:58 < stepcut> anyway, I am not yet convinced that deriveSerialize and Migrate belong in happs-data in the first place, much less IxSet
15:58 < mae_work> stepcut: where then?
15:58 < mae_work> migrate sounds like it might be state-ish
15:59 < stepcut> I would have to look more closely and see how much of happs-data they use
15:59 < stepcut> statish, perhaps, but not macid
15:59 < mae_work> ahh semantics
15:59 < stepcut> I would like to use them the migrate url's though
15:59 < mae_work> hierarchy wars
15:59 < stepcut> s/them the/them to/
15:59 < mae_work> stepcut: ooh  you mean like 403 redirects?
16:00 < stepcut> better.
16:00 < stepcut> yes
16:00 < mae_work> that would be wicked cool
16:00 < stepcut> 403's that know exactly where to go
16:00 < mae_work> and way to think out of the box on that one
16:00 < stepcut> did you see my "404 no more" series?
16:00 < mae_work> but that requires a component that retains an url map
16:00 < stepcut> http://src.seereason.com/~jeremy/SimpleSite1.html
16:01 < mae_work> well wait a min
16:01 < mae_work> yeah you sent that before
16:01 < stepcut> in my system URLs are generated from data-types
16:01 < stepcut> so there is no extra 'map' per se
16:01 < mae_work> what would define how far back you keep redirecting legacy urls
16:02 < stepcut> when the incoming request comes in, it will be deserialized back to a datatype, using the migration functionality if needed
16:02 < mae_work> and what happens when you traipse on a previous url with a new migration
16:02 < mae_work> so for instance, if the url that is coming in is a version 3
16:02 < stepcut> mae_work: you get to decide how far back things go by your migration instances.
16:02 < mae_work> but we're at version 4
16:02 < mae_work> then that means we redirect them
16:02 < stepcut> right
16:03 < mae_work> so feasibly versoin could be a function of the uri
16:03 < mae_work> like
16:03 < mae_work> '/v3/my/path' as a simplistic example
16:03 < stepcut> exactly
16:03 < stepcut> that is pretty much how serialize and migrate work
16:03 < mae_work> right but, what about in the real world where urls are arbitrary
16:03 < mae_work> how do you define a version of an incoming url?
16:03 < mae_work> once again you are stuck using a map :)
16:03 < stepcut> no
16:04 < stepcut> incoming urls are not arbitrary
16:04 < stepcut> the only valid incoming urls are ones where you put content, and you get to decide what that looks like
16:04 < stepcut> users don't get to decide what the valid links on your site are
16:04 < stepcut> you do
16:05 < mae_work> yeah i understand
16:05 < mae_work> but how would this play out in the code
16:05 < mae_work> how do we get from '/foo/bar' to
16:05 < stepcut> well, I wrote a 3 part series that details it... starts off simple and builds up to better system
16:05 < mae_work> URL v 3
16:05 < mae_work> ah i guess i didn't see that
16:05 < mae_work> its linked from here?
16:06 < stepcut> you start the other way, you start with you data types and then you define a scheme for going to a url and back
16:06 < mae_work> kk
16:06 < stepcut> the lamest scheme is that you bascially use, show and read
16:06 < mae_work> i'll read up on it
16:06 < stepcut> which makes for very ugly urls
16:06 < stepcut> so, in real-life you use a more sensible translation scheme
16:07 < stepcut> but, that can be application specific
16:10 < stepcut> part III, Prettier Links
16:11 < mae_work> very very interesting
16:11 < mae_work> i'll bbl
16:12 < mae_work> good talk :)
18:36 < h_buildbot> Build for ghc-6.8.3 just succeeded. See http://buildbot.happstack.com/ghc-6.8.3/
18:41 < h_buildbot> Build for ghc-6.10.1 just succeeded. See http://buildbot.happstack.com/ghc-6.10.1/
21:57 < gwern> so does anyone know whether we are renaming the modules?
21:57 < gwern> (not just the cabal packages)
21:58 < Saizan> we aren't for 0.1 at least
21:58 < gwern> are we going to after that?
22:42 < gwern> @ask mae did you ever get the old repos' history into the patch-tag one?
22:43 < gwern> @ask mae did you ever get the old repos' history into the patch-tag one?
22:43 < lambdabot> Consider it noted.
22:43 < Axman6> you chould get Cale to add #happs to lambdabot's join list
22:44 < gwern> I did already add #happs to the online.rc
22:45 < gwern> but lb is working off an old version; cale would hae to reinstall]
22:45 < gwern> @ask mae I bring it up because macfarlane doesn't think scrapping the history is a good idea either. perhaps it's just that you don't want to do the work yourself?
22:45 < lambdabot> Consider it noted.
22:46 < gwern> @ask mae if I merged the repos myself, would you upload the single repo to patch-tag and happstack would then use it?
22:46 < lambdabot> Consider it noted.
--- Log closed Sat Jan 31 00:00:14 2009