00:21:17 <tempire> donri: do you have any further documentation for vim2hs, other than the repo readme?
00:24:28 <donri> not yet
00:26:44 <tempire> :(
00:29:04 <donri> are you wondering about anything in particular?
00:30:16 <tempire> hpaste reports: error: name 'vim' is not defined
00:32:17 <tempire> this may be a vim issue, since I've never used gf, I'm not sure directory put in the path to make it recognize things.
00:32:42 <donri> gf?
00:33:07 <donri> that error is probably from the python interface
00:33:15 <tempire> "Makes Vim aware of Haskell modules and imports allowing you to gf with the cursor on a module to "go" to its source "file", etc."
00:33:39 <donri> usually the $CWD is in path, i add "src" too
00:34:33 <tempire> The syntax highlighting is far superior, but I suppose I'll keep the haskellmode plugin for all the shortcuts to haddock-related stuff/
00:35:10 <donri> i prefer https://github.com/eagletmt/ghcmod-vim because it works better with cabal[-dev]
00:35:21 <donri> but it doesn't come with predefined mappings
00:35:56 <tempire> what all haskell related plugins are you using?
00:37:04 <donri> https://github.com/dag/dotfiles/blob/master/.vim/vundle.vim#L46
00:37:25 <tempire> really, what I want is something that will let me jump to the docs of any package, and the the function definition.
00:37:37 <tempire> that's proving harder than I would imagine.
00:38:23 <donri> vim2hs binds "K" to hoogle, but that usually only works for some standard libs
00:38:38 <donri> though it depends on what sources you have fed hoogle...
01:13:07 <donri> bedtime
04:19:45 <edwardk> Lemmih: in SDL is there a reason why Rect and its ilk keep boxed Ints in the ADTs?
04:36:23 <stepcut> oh… duh. git is *supposed* to be a *distributed* revision control system. But the limitations of git have lead to github being an almost essential part of using git. Making it once again centralized :-/
05:39:47 <Lemmih> edwardk: I don't think so.
05:54:26 <edwardk> was just wondering if it wouldn't benefit from some !'s and a little {-# UNPACK #-} love =)
12:12:03 <alpounet> stepcut, around?
12:31:55 <alpounet> stepcut, would be great if you happen to be around in 4-5 hours, i have a student who's working on a proposal for scoutess, your insight on this would be appreciated :)
16:20:07 <stepcut> alpounet: I am around for a bit
16:20:59 <donri> stepcut: maybe happstack should provide both pretty printing and non-pretty ToMessage instances, either via different imports or possibly cabal flags?
16:21:35 <donri> imports concerning instances can be tricky though, and cabal flags can't be set for dependencies...
16:23:05 <donri> perhaps default to pretty and provide a cabal flag for production deployments where you're more likely to want to mess with build flags anyway
16:27:14 <donri> (seems like something i could work on if you OK an approach)
16:35:33 <mekeor> ACTION just skimmed through the introductory tutorials of snap, yesod and happs and likes happs most yet.
16:36:20 <donri> welcome
16:36:22 <donri> !
16:36:45 <mekeor> =)
16:38:01 <parcs`> yeah, the happs tutorial is amazing
16:38:58 <donri> the happs tutorial is awful. the happstack crash course on the other hand...
16:39:00 <donri> ACTION teasing
16:41:18 <mekeor> ACTION wonders how http://happstack.com/docs/happstack-lite/happstack-lite.html is generated… -- without an generator??
16:41:40 <donri> pandoc i think?
16:41:56 <stepcut> mekeor: literate Haskell + markdown + HsColour
16:42:02 <stepcut> mekeor: and a Makefile
16:42:06 <mekeor> stepcut: ah
16:42:17 <donri> HsColour -lit -css -partial $< | markdown --html4tags >> $@
16:42:19 <stepcut> and CPP
16:42:19 <stepcut> it's not very elegant
16:42:26 <donri> not pandoc :)
16:42:28 <mekeor> ACTION doesn't know HsColour oO -- but that's rather offtopic here…
16:43:36 <stepcut> donri: why do you need pretty instances?
16:44:27 <donri> nicer in development
16:44:59 <stepcut> when in development?
16:45:01 <donri> alternatively i think we should make all instances non-pretty, which includes jmacro
16:45:45 <stepcut> I am in favor of non-pretty
16:46:08 <stepcut> if I want pretty I just hit F12 in chrome, and everything is all prettied up :p
16:46:43 <donri> sure, i have such tools too
16:46:59 <donri> but does that prettify javascript?
16:47:06 <stepcut> yes
16:47:08 <stepcut> one moment
16:47:37 <stepcut> do you have chrome ?
16:48:10 <donri> ah i see it
16:48:36 <stepcut> the {} in the button bar on the bottom of the javascript view ?
16:48:38 <donri> yea
16:48:42 <stepcut> good stuff :)
16:48:45 <donri> firebug doesn't have that
16:49:42 <stepcut> that's why I use chrome :p
17:11:46 <alpounet> hi there
17:13:14 <DMcGill> hey
17:24:03 <alpounet> stepcut, are you around?
17:24:12 <stepcut> alpounet: for a few minutes
17:24:59 <alpounet> DMcGill, do you have your proposal link,
17:25:00 <alpounet> ?
17:25:13 <DMcGill> https://docs.google.com/document/d/1ulYTXJ8WlZz83-OUXMougEtlEjCLDAlSsfbXxg-Kyfs/edit
17:26:02 <DMcGill> I did a little guessing as to how things are going to be implemented
17:26:27 <alpounet> we'll talk about this don't worry, just let me read it
17:29:15 <stepcut> I'm not sure I would bill scoutess as a solution to cabal hell, as it would still be useful even with out hell
17:29:50 <donri> stepcut: http://darcsden.com/dag/happstack/changes
17:30:39 <stepcut> donri: nice. I should do a pull ?
17:30:45 <donri> if you like :)
17:31:25 <donri> not that i know how to pull from darcsden. maybe http://darcsden.com/dag/happstack ?
17:34:26 <stepcut> pulled
17:34:27 <donri> next we need a non-pretty hsp renderer :)
17:38:24 <stepcut> regarding scoutess, the problem with trying to maintain a project is that there is a lot of information you need to know, and a lot of ways things can break. For example,  you might make a change to some code, and break backwards compatility with an older GHC or a different OS with out realizing it.
17:38:49 <stepcut> also, you want to know when there are newer libraries on hackage that you could be using, but are not, because your versions need to be updated
17:39:11 <stepcut> or someone uploads a new package to hackage, and they don't follow the PVP and now your package breaks
17:39:26 <donri> the "problem" is that in haskell it results in build failure. usually, in other languages, things continue to seemingly work fine until a user runs into the issue at runtime. :)
17:39:35 <stepcut> plus, you want to have up to date haddock docs for the -dev version
17:39:37 <alpounet> DMcGill, it wouldn't exactly solve dependency hells, it would let you know about them earlier, among other things! and yeah, see what stepcut says, it provides you more knowledge about the compatibility between your project and its dependencies and the different GHC versions, just by testing a bunch of stuffs
17:40:01 <alpounet> you would know about any breakages BEFORE your releas
17:40:02 <alpounet> e
17:40:09 <stepcut> but if I spend all my time testing, and looking for new packages, and updating the docs, then I will never get around to the real work
17:40:20 <alpounet> instead of just thanks to users providing feedback about some build issues they have
17:40:25 <stepcut> now, it is true that some of the features we want to add to scoutess do deal with dependency hell
17:40:30 <donri> alpounet: it could solve dependency hell by automatically releasing "platforms"
17:40:43 <alpounet> yeah but this isn't planned yet
17:40:44 <stepcut> both in terms of detecting problems, and also in terms of automatically publishing meta packages with known good configurations
17:40:49 <donri> with pinned versions known to work
17:40:53 <stepcut> right
17:41:01 <alpounet> donri, however, your "platforms" have to be compatible with the packages you have installed too
17:41:02 <donri> define "planned" :) might be long-term, but the idea comes from stepcut
17:41:03 <stepcut> but that is just one of many services that scoutess can provide
17:41:07 <DMcGill> Ok, I'll change the focus of the proposal to reflect that too
17:41:24 <alpounet> otherwise it'll just move the dependency hell to other packages
17:41:28 <alpounet> UNLESS everyone uses scoutess
17:41:29 <alpounet> yay
17:41:44 <donri> alpounet: true. but it solves the issue for starting fresh projects. before yesod-platform it was common to not even be able to cabal install yesod in a fresh cabal env.
17:41:57 <alpounet> yeah yeah
17:42:03 <alpounet> THIS was one of the original goals
17:42:09 <donri> :)
17:42:11 <alpounet> "testing a fresh install of your project"
17:44:42 <DMcGill> So it's more a tool used by the package maintainer to give warnings and info about compatibility than one for the user to ease installation?
17:45:05 <donri> well, the result is hopefully easier user installations
17:45:16 <Lemmih> stepcut: I like him.
17:45:19 <donri> but the tool itself is meant for package maintainers
17:47:13 <DMcGill> ah I get it, time for some proposal updating! Some more information on how exactly things are going to be implemented would be helpful as I don't think it's currently detailed/correct enough in that area and also some feedback for my wild guessing for the timeframe
17:47:49 <stepcut> DMcGill: it's definitely targetted to the maintainers. It is supposed to make the end user's life easier by making it easier for the maintainer to do their job well. aka, ensuring the library buils everywhere, ensure it has up to date dependencies, making sure the haddock docs are up to date, making sure that questions on stackoverflow, etc, are getting answered in a timely manner
17:50:17 <alpounet> DMcGill, so yeah, basically the sandboxed building will take as input a given code for your project, and given versions for the dependencies, and then try to build everything as if it was on a computer with a fresh Haskell Platform install
17:52:27 <stepcut> Lemmih: cool.
17:52:33 <stepcut> everyone: gotta run, bbl.
17:52:40 <Lemmih> stepcut: Recuit more peole
17:52:52 <DMcGill> I'll get back to you in 20 mins or so after I've changed the relevant parts, assuming you're still interested in me joining the project for the summer
17:52:57 <Lemmih> Tsk.
17:53:23 <stepcut> DMcGill: of course! I am going to be out for a bit, but I am quite often around on this channel and will be later today
17:53:29 <Lemmih> stepcut: Recruit more people. I have lots of more stuff I want done.
17:53:34 <stepcut> Lemmih: me too :)
17:55:37 <DMcGill> it seems I've got three people watching me work on it realtime ;)
17:57:23 <alpounet> DMcGill, the dependency tracking service will look for new versions of the project's dependencies on e.g hackage and will add them to the local package database (I think) so that we can test building the project against these too
17:58:09 <alpounet> we'll get back to the real details of the two services once you've edited everything
17:58:55 <stepcut> alpounet: I am not sure if that is needed. We want to track the dependencies on hackage to see when they change. But we may not need to actually put them in the local hackage. cabal install can pull from multiple hackage repos.. so it could just use the union of hackage + localhackage
18:00:01 <alpounet> yeah but we'd need to test against the new versions too after we know about them
18:01:06 <alpounet> so we can just cabal-install them from the local hackage
18:01:25 <alpounet> it'd thus not download from hackage but just copy from the local repo
18:02:10 <stepcut> ?
18:02:28 <stepcut> gotta run, we can discuss later
18:02:41 <alpounet> yeah
18:03:05 <alpounet> i'll try to explain a bit more what i meant
18:12:33 <DMcGill> actually scratch that - I'm off for a bit, I'll be on later with my fresh and not-missing-the-point-this-time proposal.
18:17:38 <alpounet> alright
18:17:57 <alpounet> i'll also try to outline the plan, in details, about the two services
18:18:07 <DMcGill> thanks
18:19:14 <DMcGill> I'm starting to feel like I understand what is (or will be) going on, always a plus when programming
18:20:34 <alpounet> yeah
18:20:57 <alpounet> you really have to get more insight on how things will be done to write a more attractive proposal
18:48:06 <mekeor> does happs run on ARM fine?
18:50:48 <mekeor> does happs use template haskell internally?
18:51:55 <donri> it depends on template-haskell anyway
18:54:09 <alpounet> DMcGill, alright. So, here's my take on how scoutess will work. Some details may not be exact since we haven't discussed
18:54:17 <alpounet> *everything*
18:57:32 <alpounet> So you'll configure the program, enabling/disabling the various services it will contain. scoutess will most likely use the cabal file of your project to know about the dependencies and the versions it has to try to build your project with.
18:59:26 <alpounet> We've implemented one fetching mode for now (Hackage). It means that at some point we will be able to fetch a given package version from hackage and store it locally, in a kind of "local hackage" (that's already implemented). This LocalHackage thing is usable as a "local repo" for cabal, so when building a package we can just "install" the depenencies from there.
18:59:58 <alpounet> instead of fetching them from the hackage.haskell.org server which obviously takes more time.
19:01:12 <alpounet> we'll also implement fetching from git/darcs/whatever repositories, of course, so that we'll be able to check against development versions of libraries
19:06:44 <alpounet> now, let's imagine someone of your project commits some new code. scoutess will, for a given set of dependencies versions, create a "virtual" environment, which will kind of emulate a fresh Haskell Platform install (so only containing ghc, cabal and the libraries provided by the Haskell Platform). From there, it will install the dependencies in the right order (we can borrow some code from cabal here, or just use "cabal install" on the pr
19:06:44 <alpounet> oject and let cabal figure out everything by itself, but then we have to use the given versions of the dependencies so we have to handle this somehow.) and then depending on how this goes producce a report telling about how awesome the world is and that everything went smoothly, or how horrible the world is and why the build failed, and probably what has changed since the last time it succeeded, with that very same set of dependencies ver
19:06:45 <alpounet> sions
19:07:24 <alpounet> and we'll have to try building the project with the various dependency versions and with various GHC versions
19:08:02 <alpounet> 'cause maybe the project doesn't build because of some breaking change in GHC 7.4
19:08:47 <alpounet> or maybe the project doesn't support GHC 6.12 anymore because of some new code one of the developers introduced!
19:10:49 <alpounet> and also, we want scoutess to watch if there are new versions of the dependencies released on hackage (or if there's a new commit on the development repo of the project, if a repo has been specified for that dependency), and tell us about it, so that we can try building against that new version. so maybe yeah this step wouldn't be automated and we would have to add that version in the bounds we put in the cabal file, but that's not a big
19:10:50 <alpounet> issue for now.
19:11:46 <alpounet> and yeah we have planned a few additional services, like reporting stuffs on IRC, presenting the haddock documentation of the project AND its dependencies, with hyperlinks going between the different packages' documentations, etc
19:13:23 <alpounet> is everything clear now?
20:09:21 <donri> http://patch-tag.com/r/tphyahoo/patch-tag-public/snapshot/current/content/pretty/templates/toppages/meh.st
20:10:21 <donri> http://patch-tag.com/h/meh heh
20:16:53 <stepcut> DMcGill: the first two sections seem a lot better now!
20:17:48 <DMcGill> yup, just updating deliverables now
20:18:20 <DMcGill> alpounet: that seems ok and certainly is enough for now but I guess we'll find out how well I understand it when I try to implement it!
20:22:11 <donri> http://www.yesodweb.com/blog/2012/03/pipes-like-conduit makes me more confident that pipes will be able to solve the resource problem
20:24:48 <donri> hm conduit's Pipe is not a Category it seems?
20:25:14 <stepkut> ?
20:25:31 <stepkut> ah
20:26:02 <donri> http://www.snoyman.com/haddocks/conduit-0.4.0/Data-Conduit.html
20:27:09 <donri> i somewhat agree though it's not necessarily elegant to have unified type when it results in hacks like "absurd" or the fact that a pipe producer allows unit as input
20:30:16 <donri> well, Pipe alone, in itself, is sorta elegant, but as soon as you start talking about restrictive pipes like Consumer and Producer, isn't separate types better?
20:32:07 <donri> actually, why isn't the input for Producer Void? *reads*
20:33:59 <donri> oh, of course
20:34:24 <donri> await takes no arguments, so even though you can't make a Void value, you can still "await" one
20:34:34 <stepkut> :)
20:36:00 <donri> i suppose separate types wouldn't compose as easily with category?
20:36:16 <stepkut> yeah
20:36:26 <stepkut> the pipes library defines some type aliases I think
20:36:32 <stepkut> but that is just more things to remember, IMO
20:37:16 <donri> yea, Consumer and Producer are aliases for Pipe with input or output set to () or Void, respectively, and Pipeline for both
20:37:50 <stepkut> yeah
20:37:58 <donri> well one benefit of having the aliases i guess is upstream can change the representation
20:38:06 <alpounet> DMcGill, tell me when the doc is updated so that i can comment on it
20:38:06 <donri> like the latest release did with Zero -> Void
20:39:10 <stepkut> yeah
20:42:03 <donri> also separate types in current conduit leads to ... clever naming: Closed, Done, Finished (different constructors for the same concept in the different types)
20:42:16 <stepkut> yeah
20:46:50 <DMcGill> alpounet:, stepcut: It's updated now. The 'dependency tracking' section needs fleshing out a bit more but I'm not too sure what more is needed.
20:47:46 <stepkut> DMcGill: nice
20:49:36 <alpounet> that's waaaaay better indeed
20:52:29 <DMcGill> it addresses most of the points in http://hackage.haskell.org/trac/summer-of-code/wiki/StudApply2012#Questions and unless you have more advice, I'll submit it this evening
20:53:17 <donri> hmmm way above my level but couldn't gadts ensure producers can't await?
20:55:06 <donri> seems superficially similar to http://www.haskell.org/haskellwiki/GADT#Example_with_lists
20:57:51 <alpounet> DMcGill, lemme check it out again
20:58:17 <alpounet> DMcGill, i think we can improve it a bit still
20:58:53 <alpounet> this isn't really ready yet
20:58:58 <alpounet> still a bit more to add IMO
21:08:21 <alpounet> DMcGill, after saying it would take 8 weeks, i think you can give some more details
21:08:56 <alpounet> like what you will actually have to write
21:09:43 <alpounet> i'd probably have worked on the "sandboxed" aspect by then, sure, but you can flesh it out a bit more
21:11:19 <DMcGill> I'll add that. Do you have any suggestions as to what else to put in the 'dependency tracking' section? Also, I think stating that I'll keep a blog of my progress will go down well especially since they were considering making that mandatory anyway. Are the 'synopsis' and 'benefits' sections ok or do you feel they need more too?
21:11:35 <alpounet> like "since that code will have to fetch the required dependency versions from the local repository, from hackage or from some other place (e.g VCS repository), and arrange the right order for building everything in a sandbox
21:12:11 <alpounet> and piping the errors/warnings out to some other code that will construct some data from there
21:12:21 <alpounet> "
21:12:59 <alpounet> and i think we're good for the sandboxed build section
21:14:56 <alpounet> ok, so, for the dependency tracking section, you can be more specific indeed. that service will watch hackage.haskell.org or other "Hackage databases" for new versions of the dependencies and notify you about that. i'm also considering something that would watch a
21:15:05 <alpounet> a VCS repository*
21:18:01 <alpounet> i'm also thinking about scoutess asking you if you want to update the cabal file accordingly to include that bound (or open the cabal file for you with your EDITOR or smth, maybe?) but anyhow having scoutess help you there too
21:18:11 <alpounet> we really aim ease of package maintenance
21:19:00 <alpounet> DMcGill, indeed, telling about having a blog for the GSoC project etc is nice
21:19:16 <alpounet> (and actually having it and publishing stuffs on it if you're selected, ofc :p)
21:19:41 <alpounet> i think the synopsis and benefits sections are ok yup
21:55:18 <DMcGill> Right, updated those sections again. As it gets later the chance of typos and stupid errors increases so watch out for them!
21:59:32 <alpounet> DMcGill, in the sandboxed build section, at the beginning
21:59:52 <alpounet> to be 100% correct, it doesn't take a "program", but rather "a program's source code"
22:00:07 <DMcGill> changed, thanks
22:00:38 <alpounet> "the dependencies need to be installed in the correctly"
22:00:46 <alpounet> a stupid error I guess? :P
22:02:59 <alpounet> ok, seems good
22:03:33 <alpounet> is there any (at least a tiny bit) significant project (open source or for classes or w/e) you've done that you haven't mentionned in the proposal in the section dedicated to yourself?
22:06:23 <DMcGill> would implementing stereoscopic vision alg count? I've also done an interactive visual program, my dissertation is a parser generator and I've got about a third of a game on github
22:06:25 <DMcGill> will any of those do?
22:07:41 <alpounet> sure
22:07:47 <alpounet> not sure the game is worth mentioning, but you can
22:07:56 <alpounet> showing you already have done some projects is good, definitely!
22:08:02 <alpounet> don't be shy about them!
22:14:07 <DMcGill> "I’ve implemented stereoscopic vision using the Repa libraries, produced two projects with HOpenGL and written various parsers and compilers."
22:22:49 <alpounet> sounds good!
22:24:13 <alpounet> stepkut, any comment?
22:29:41 <stepkut> I feel like the deliverables are not quite right organization wise
22:30:18 <stepkut> too much stuff is lumped into sandbox build testing, where as we have things a bit more split up
22:31:35 <stepkut> aka, the Source service that fetches remote code, the LocalHackage service that adds source to a local hackage server, and then sandbox builder than tries to run 'cabal install' on a package from LocalHackage (or LocalHackage + hackage.haskell.org, depending on what we find works better)
22:32:08 <stepkut> and the description seems to not make it clear what one of the the goals of the sandbox building is
22:32:57 <stepkut> using the sandbox building we want to simulate as closely as possible what would happen if we uploaded all the dependencies to hackage right now, and someone on a clean system with nothing but haskell platform installed, trying to do a 'cabal install foo' on the package
22:34:25 <stepkut> so, for example, I am not sure what "Another two weeks for installing the dependencies correctly" refers too, because 'cabal install' is supposed to be doing that for us
22:34:47 <stepkut> "final two weeks for enabling the building of the package itself" same here
22:35:46 <alpounet> stepkut, we need to make cabal install work in a local "package db"
22:35:55 <alpounet> like ~/.cabal/packages/
22:36:03 <alpounet> but one for each build trial
22:36:24 <DMcGill> I might get rid of that whole 8 week breakdown section, it's sheer guesswork and pretty pointless to have imo
22:36:57 <stepkut> I think a breakdown is good. But I think we need to spec out the tasks a bit more clearly
22:40:00 <stepkut> so, we should start that section by clarifying the goal
22:40:03 <alpounet> DMcGill, no, people like such breakdowns
22:40:23 <alpounet> but indeed, what's actually going to be done isn't that clear
22:40:27 <stepkut> we want to test that 'cabal install some-package' would work if everything was uploaded to hackage and built against a fresh haskell platform enviroment
22:40:30 <alpounet> when i re-read it
22:41:15 <stepkut> so, we are trying to create a simulated environment where we just run 'cabal install some-package'
22:42:14 <stepkut> two key parts to simulating that environment are (1) creating a hackage repository that contains the packages we want cabal install to see (2) creating a clean build environment for 'cabal install' to work in
22:42:44 <stepkut> since we want to test against multiple versions of haskell platform, it would be tricky to try to use the normal global Haskell environment
22:43:14 <stepkut> so that is why we need something like hsenv, virthualenv, cabal-dev, etc, where we can easily create a fresh, sandbox to do the build in
22:44:38 <stepkut> but, the work is not really in 'installing the packages' or 'building the package' as it is, creating the 'simulated' enviroment were we can then run a normal cabal install to download and build the packages
22:45:24 <DMcGill> ok, I'll make those changes tomorrow - updating the build section and clarifying the steps. I also have to write a short 500 character summary but that shouldn't take long. It's getting late and I have lectures early in the morning so I think I'm done for the night
22:45:31 <stepkut> k
22:45:34 <stepkut> see you tomorrow!
22:45:34 <DMcGill> thanks for all your help and we'll talk tomorrow
22:45:47 <alpounet> yeah let's continue this tomorrow
22:45:53 <alpounet> you have still a week I think to finish it
22:45:55 <stepkut> I think describing the separate services would be better too
22:45:57 <alpounet> that should be fine :)
22:46:11 <stepkut> like, the source fetching service also ties into the bot that watches for changes
22:46:38 <stepkut> and, building haddock documenting builds on top of sandboxes, localhackage, and the source service
22:47:53 <DMcGill> ok, night!
22:47:59 <stepkut> night!
22:48:51 <alpounet> ok so stepkut, we decide to write something ourselves for the sandbox env?
22:50:34 <stepkut> alpounet: most likely
22:51:44 <alpounet> so this is basically about passing the right --with-ghc and --with-ghc-pkg (or smth like that) to handle ghc, and having a local thing for compiled packages
22:52:06 <alpounet> + (i don't know how we can handle this) the libraries provided by HP
22:52:10 <alpounet> in that same local thing
22:52:11 <stepkut> alpounet: the tools like hsenv, cabal-dev, etc, are intended to be used interactively by developers
22:52:36 <stepkut> alpounet: they do not provide libraries, and tend to affect things globally.. which means you could not run multiple builds in parallel on the same machine
22:52:47 <alpounet> yeah
22:53:24 <stepkut> it would be nice to have something that was completely independent of your global haskell enviroment
22:54:00 <stepkut> like.. it would be nice if it could take the haskell platform .tar.gz files as input, and go from there, installing everything in a separate completely isolated enviroment from your global environment
22:55:02 <stepkut> given the fact that hsenv, capri, cabal-dev, virthual env are around ~1000 lines each.. I don't think it is a huge task. Especially when we can copy what they do for the most part?
22:55:43 <alpounet> yeah
22:55:56 <alpounet> but downloading the HP files will take forever!
22:56:21 <stepkut> alpounet: well, you would only download them once
22:56:28 <alpounet> the binary files aren't exactly lightweight :P
22:56:32 <stepkut> alpounet: and probably only unpack them once
22:56:47 <alpounet> and then we can use our shiny copyDir function :P
22:57:33 <stepkut> alpounet: not sure we even need to do that.. we can, hopefully, just install the platform once in some private directory, and then have 'cabal install' install its extra things into some secondary directory that we can easily wipe afterwards
22:58:05 <alpounet> alright
22:58:06 <stepkut> alpounet: but, if not, then we can just use the copyDir function to copy that clean enviroment
22:59:11 <alpounet> ok so we would have some different HP versions sitting somewhere in a scoutess dir
22:59:26 <stepkut> yeah
22:59:52 <alpounet> and each build would use this and a per-build folder to cabal-install stuffs into a compiled package db local to that folder
22:59:55 <alpounet> smth like that
23:00:11 <stepkut> yeah
23:02:32 <alpounet> aaaalright, sounds like a plan.
23:03:06 <stepkut> it's only a plan if we write it down ;)
23:33:04 <donri> stepkut: http://darcsden.com/dag/happstack/patch/20120326232757-6eb02
23:35:08 <stepkut> donri: what if we added a 'GETOnly' constructor (or something like that?)
23:35:15 <donri> i'm thinking guardRq is easy to use, and GET_ONLY is sort of ugly
23:35:33 <stepkut> yeah
23:35:54 <stepkut> it seem like it would be a pretty rare case anyway
23:35:57 <donri> yea
23:38:44 <stepkut> can you add some unit tests to happstack-server/tests/Happstack/Server/Tests.hs. I can not tell from visual inspection that is is working correctly
23:38:55 <donri> i'll try
23:39:06 <stepkut> let me check something real quick
23:39:07 <donri> i tried matchMethod manually in ghci but could of course have missed something
23:39:40 <donri> there are some obscure things like "not GET", does that match HEAD?
23:39:50 <donri> method (/= GET)
23:39:51 <stepkut> if you run, 'make local' in the tests directory, it should run your tests against your new code
23:41:54 <donri> $ make -C tests/ installed  Cases: 25  Tried: 25  Errors: 0  Failures: 0
23:42:00 <donri> OK I'll see if i can add some tests
23:42:37 <donri> hm that probably didn't use my cabal-dev ...
23:42:45 <stepkut> possibly not
23:44:43 <donri> $ cab -s ../cabal-dev install -ftests
23:44:44 <donri> \o/
23:52:48 <donri> ok cabal-dev seems to bug out on that