--- Log opened Thu Feb 19 00:00:17 2009
00:04 < mae> cool thanks all :)
00:14 < stepcut> mae: hrm, I don't see hyena as being lazy IO. From what I remember of the system, I do not see any reason it could not be implemeted in OCaml, for example. It seems to me that it is a way to offer many of the benefits of lazy IO, but with out the unpredictibility ?
00:14 < stepcut> mae: also, did you see the problem I am having related to IxSet ?
00:16 < mae> stepcut: yes, i know it is not what people call "lazy IO" in haskell
00:16 < mae> but the enumerator still can be applied to a lazy stream
00:16 < mae> but the memory allocation / deallocation is much more predictable
00:17 < mae> stepcut: I kind of scanned the chat logs, whats up?
00:17 < mae> why is the migration instance hard?
00:18 < mae> wouldn't you write the migration instances for the types themselves that IxSet is indexing?
00:18 < mae> i mean you don't need to worry about migrating the maps
00:18 < mae> they can be rebuilt
00:19 < stepcut> mae: if the Map data structure itself changed, then you would have to worry about migrating maps
00:19 < stepcut> mae: in my case, the data types that are being indexed have changed, IxSet is what has changed.
00:22 < stepcut> oops
00:22 < stepcut> the data types that are being indexed have *NOT* changed
00:24 < Saizan> what problems are you having with migrate? isn't just a matter of unpacking the old constructors and repacking in the new ones?
00:25 < stepcut> Saizan: the code is easy. But, writing the type signatures is hard.
00:26 < stepcut> though, maybe I just got it...
00:26 < stepcut> oh nm. I didn't.
00:26 < Saizan> the context for the instance you mean?
00:27 < stepcut> yes
00:28 < stepcut> I start with this:
00:28 < stepcut> instance Version (IxSet a) where
00:28 < stepcut>     mode = extension 1 (Proxy :: Proxy (HAppS.IxSet b))
00:28 < stepcut> but then I get this error:
00:28 < stepcut>     Could not deduce (Migrate b a) from the context (Version (IxSet a))
00:29 < stepcut> so I add (Migrate b a), and I get more errors, and then it spirals out of control
00:29 < stepcut> eventually I have:
00:29 < stepcut> instance (Indexable b c, Ord b, Data b, Serialize b, Migrate b a) => Version (IxSet a) where
00:30 < stepcut> but I still get the error:
00:30 < stepcut>     Could not deduce (HAppS.Indexable b1 b)
00:31 < Saizan> do you have ScopedTypeVars on?
00:31 < stepcut> yes
00:36 < stepcut> with more monkeying around I can get to this point:
00:36 < stepcut> src/Happstack/Data/IxSet.hs:153:9:
00:36 < stepcut>     Could not deduce (HAppS.Indexable b c, Ord b, Data b, Serialize b, Migrate b a)
00:36 < stepcut>     from the context (HAppS.Indexable b c, Ord b, Data b, Serialize b, Migrate b a, Serialize a, Ord a, Data a, a b)
00:36 < stepcut>  
00:36 < stepcut> which blows my mind
00:36 < Saizan> mmh, do we need HAppS.IxSet b? isn't "HAppS.IxSet a" enough?
00:37 < Saizan> stepcut: those variables aren't really the same ones, probably
00:37 < Saizan> though "a b" looks funny
00:37 < stepcut> Saizan: extension :: (Serialize b, Migrate b a) => Happstack.Data.Serialize.VersionId a -> Proxy b -> Mode a
00:38 < stepcut> that is what forces the migration to be, HAppS.IxSet b -> IxSet a, instead of HAppS.IxSet a -> IxSet a
00:38 < Saizan> why? can't you write "extension 1 (Proxy :: Proxy (HAppS.IxSet a)"?
00:39  * stepcut checks
00:39 < Saizan> adding the missing )
00:41 < dons> go go go go! you guys rock. http://www.reddit.com/r/haskell/comments/7yk18/socalfp_presentation_slides_happstack_is_better/
00:42 < stepcut> Saizan: this seems to be working better
00:43 < stepcut> Saizan: is there a cooler way to write this:
00:43 < stepcut> instance Migrate (HAppS.IxSet a) (IxSet a) where
00:43 < stepcut>     migrate (HAppS.ISet a)  = ISet a
00:43 < stepcut>     migrate (HAppS.IxSet a) = IxSet a
00:43 < stepcut> something using generics? gcast or something?
00:43 < stepcut> it's very boiler plate
00:44 < stepcut> dons: sorry, the IT department at my house has blocked reddit
00:45 < dons> heh
00:45 < dons> but the *haskell* reddit is full of goodness
00:46 < Saizan> mmh, yeah, you should be able to using dataTypeOf and fromConstr, but i wouldn't bother
00:46 < stepcut> dons: hreddit.com ? written in happstack?
00:46 < stepcut> Saizan: in this case I don't care, but sometimes it gets tedious with bigger structures
00:47 < stepcut> any ideas why, typeOf sometimes returns a fully qualified name, and other times doesn't?
00:47 < Saizan> for the same types?
00:48 < stepcut> no, I am drumming up an example, one moment
00:49 < stepcut> Prelude Happstack.Data.IxSet Data.Typeable Data.Set> typeOf (undefined :: Set Int)
00:49 < stepcut> Set Int
00:49 < stepcut> Prelude Happstack.Data.IxSet Data.Typeable Data.Set> typeOf (undefined :: IxSet Int)
00:49 < stepcut> Happstack.Data.IxSet.IxSet Int
00:49 < stepcut> that is the whole reason why we need migration for IxSet in the first place.
00:51 < Saizan> #include "Typeable.h"
00:51 < Saizan> INSTANCE_TYPEABLE1(Set,setTc,"Set")
00:51 < Saizan> from Data/Set.hs
00:52 < stepcut> ah.. craziness
00:52 < Saizan> that's probably because those sources are shared among compilers
00:53 < stepcut> having typeOf behave differently was very mystifying
00:53 < stepcut> at least it makes sense now
00:54 < stepcut> so, now Serialize for IxSet has the type:
00:54 < stepcut> instance forall a b c. (HAppS.Indexable a b, Serialize a, Ord a, Data a, Indexable a b) => Serialize (IxSet a) where
00:54 < Saizan> c?
00:55 < stepcut> oops, don't need the c anymore
00:55 < stepcut> but there is a bigger problem
00:56 < stepcut> the Serialize instance now requires a (HAppS.Indexable a b) instance, which is I think is generated by $(HAppS.inferIxSet ...)
00:56 < Saizan> right
00:56 < stepcut> but, you are going to normally do that, for a new type
00:56 < stepcut> s/you are/you aren't/
00:57 < Saizan> ah, if you've also changed the type of the elements you mean?
00:59 < stepcut> no. I mean if you had this patch applied. And then you tried to create a brand new IxSet, it would fail because you did not create an old HAppS.Indexable instance for it
00:59 < Saizan> oh, right, i see
01:00 < Saizan> well, do we need to duplicate the class?
01:00 < stepcut> I'm not sure what you mean
01:00 < Saizan> i don't think so
01:01 < stepcut> the ultimate goal is to deprecate HAppS.Data.IxSet completely and remove it from the happstack source tree. In fact we have done that already.
01:01 < Saizan> with what you've so far one should have both HAppS-IxSet and happstack-ixset installed to migrate?
01:01 < Saizan> eh, ok
01:02 < Saizan> so we're going to have HAppS.Data.IxSet in happstack-ixset
01:02 < stepcut> but, that means that you can't migrate your old HAppS-IxSet based data
01:02 < Saizan> but there's no reason we need two Indexable classes
01:03 < stepcut> so I think that for the next release (0.2) happstack-ixset needs to included both HAppS.Data.IxSet and Happstack.Data.IxSet, and then later we can drop HAppS.Data.IxSet after peopel have migrated.
01:03 < Saizan> right
01:03 < stepcut> yeah, maybe we can get rid of HAppS.Indexable
01:03 < stepcut> that could work
01:03 < stepcut> I'll try that tommorw
01:04 < stepcut> if we can get rid of that, then supporting, HAppS.IxSet b -> IxSet a, might even be easy
01:04 < stepcut> that HAppS.Indexable is the big troublemaker for the type checker
01:08 < dsrogers> how do I convert a ByteString to a string?
01:10 < stepcut> dsrogers: depends on what is in the ByteString
01:10 < dsrogers> ASCII
01:10 < dsrogers> it's a header.
01:10 < stepcut> dsrogers: for ascii or latin1, unpack. For utf8, use fromString in utf8-string
01:10 < dsrogers> unpack in Data.ByteString wants to give me a [Word8]
01:11 < stepcut> Data.ByteString.Char8.unpack ?
01:11 < stepcut> Saizan: thanks for your help. It's past midnight so I am going to continue tomorrow.
01:11 < dsrogers> ahh
01:11 < dsrogers> thanks.
01:12 < Saizan> stepcut: np :)
01:13 < Saizan> btw, attoparsec might be a better choice if we're working with ByteString
01:14 < Saizan> but that's for when/if we're going to optimize for speed
02:12 < dsrogers> anyone here?
02:12 < dsrogers> looky
02:12 < dsrogers> http://hpaste.org/fastcgi/hpaste.fcgi/view?id=1542#a1542
02:13 < Saizan> cool :)
02:15 < dsrogers> just have to fix the semantics a little bit.
02:15 < dsrogers> then I'll send out a patch.
02:16 < dsrogers> it even knows how to handle a 406
02:16 < dsrogers> rfc compliant, even.
04:10 < dsrogers> done!
04:10 < dsrogers> that took longer than anticipated.
07:37 < kynes> hi
07:38 < kynes> are there any example web apps made with happs?
07:40 < paulvisschers> kynes: http://tutorial.happstack.com/
07:42 < Evanlec> hehe
07:42 < Evanlec> just watched the little better-than-x.pdf
07:47 < kynes> :)
07:48 < kynes> I believe the web site can be more readable
07:51 < paulvisschers> Yup
07:51 < paulvisschers> But there isn't really anything better out there
07:52 < paulvisschers> Although it's being worked on
08:34 < gwern> kynes: wel, gitit uses happs, so find a gitit example
08:35 < kynes> gwern, thanks
09:04 < Evanlec> heh
09:04 < Evanlec> happs is having a little popularity problem eh
09:05 < gour> why do you think so?
09:10 < gour> having some more docs and being a little bit more friendly (maybe: less radical) would be nice...but, well, devs have their own reasons we have to respect...maybe turbinado (although "not-so-innovative") will provide that
09:30 < kfish> a minimal "hello world" on happstack.com would be useful
09:30 < kfish> (like on http://www.sinatrarb.com/ )
09:36 < gour> i suggested to turbinado dev to 'port' some of django tutorials...there are many and since django is nicely documented it can help adopting the framework
10:05 < stepcut> there is a simple example in happstack/happstack/template/project
10:07 < stepcut> it's not a tutorial, and it is the process of being cleaned up still, but it aims to be a good starting point for your own applications
10:07 < stepcut> here is a (temporary) copy of it running -> http://www.hacketeria.com/
10:14 < wchogg> stepcut : do you know what daemonize is for in Util
10:48 < h_buildbot> Build for ghc-6.8.3 OK. Test suite ran. 14/69 test cases failed. Check http://buildbot.happstack.com/ for details.
10:54 < h_buildbot> Build for ghc-6.10.1 OK. Test suite ran. 15/69 test cases failed. Check http://buildbot.happstack.com/ for details.
11:05 < h_buildbot> Build for ghc-6.8.3 OK. Test suite build failed. Check http://buildbot.happstack.com/ for details.
11:06 < Saizan_> ahah! someone broke the build!
11:11 < h_buildbot> Build for ghc-6.10.1 OK. Test suite ran. 15/69 test cases failed. Check http://buildbot.happstack.com/ for details.
11:12 < wchogg> I'm pretty sure the last patch was mine & it just added haddock comments.
11:14 < Saizan_> yeah, it looks like a problem with the installation
11:14 < wchogg> Hrmm..."liscensing issues" is probably not the most descriptive answer I could have gotten.
11:15 < Saizan_> some of Crypto is under GPL no?
11:16 < wchogg> Why is that a problem?
11:16 < Saizan_> happs is BSD3
11:16 < Saizan_> if you use a GPL library you must license as GPL
11:17 < wchogg> I thought that was only if you distributed the actual code in some way, not just using it in compiled form.
11:18 < Saizan_> it still counts as derivative work, afaiu
11:19 < wchogg> ...
11:19 < wchogg> licensing is silly sometimes, kthx
11:19 < wchogg> Is there anything I can do about it?
11:19 < Saizan_> GPL would be quite useless if it were different, i suppose
11:20 < Saizan_> mmh, make a distrinct package with only the BSD3 parts?
11:20 < wchogg> I think the GPL code is a fairly small part of Crypto at this point.  If I rewrote the rest myself, I could proclaim that code to be BSD3 couldn't I?
11:22 < Saizan_> if you throw away the GPL code then i think so
11:22 < wchogg> Okay.  That'll probably be a goal for the next Crypto release.
13:08 < koeien> h_buildbot: build ghc-6.8.3
13:08 < h_buildbot> Build for ghc-6.8.3 started. If one was running, no new one is started.
13:16 < h_buildbot> Build for ghc-6.8.3 OK. Test suite ran. 14/69 test cases failed. Check http://buildbot.happstack.com/ for details.
13:18 < wchogg> has anyone figured out if those failing happstack-data tests are a real problem?
13:35 < koeien> wchogg: the semantics of happstack-data are unclear
13:40 < wchogg> is it then reasonable to just assume that the current behavior is correct de facto?
13:43 < koeien> well, no, since the test cases fail
13:45 < wchogg> koeien : I thought the whole point is that we don't know why the test cases expect the behavior they do.
13:46 < wchogg> koeien : In which case, isn't the validity of the test itself suspect?
13:46 < koeien> wchogg: that doesn't mean that the current behavior is correct
13:46 < koeien> wchogg: yes i doubt the validity of the test cases
13:46 < koeien> wchogg: but the semantics are not well defined afaik
13:46 < wchogg> koeien : Well, I was saying we can "accept" it as effectively correct since we have no reason to think it's wrong until the semantics are better worked out.
13:47 < wchogg> koeien : unless one can point to a bug caused by it
13:47 < wchogg> koeien : Maybe I'm just being nitpicky, but I don't like the idea of us getting used to seeing tests failing.  That should be alarming, not common place.
13:47 < koeien> wchogg: we could also argue that it is effectively incorrect
13:50 < wchogg> koeien : I have a feeling we're not going to agree on this. ;)
13:50 < koeien> :)
13:50 < koeien> well, if the semantics are unclear you can say it's correct, but that does not convey any meaning then
13:51 < stepcut> wchogg: the Daemonize stuff looks like it (1) uses prevents file looking to prevent multiple copies from running (2) restarts the server automatically if the binary is updated
13:51 < wchogg> True.  Which is why I think the tests should be removed until we know we *can* say something as opposed to just seeing "Oh, 14 cases failed.  That means everything is normal"
13:51 < stepcut> no, maybe not (2)
13:52 < koeien> wchogg: then why not remove/disable happstack-data ? :)
13:52 < wchogg> koeien : Because it appears to work in Happstack applications, yes?
13:53 < koeien> wchogg: well i'm all for keeping it, but there should be some "future" for it
13:56 < wchogg> koeien : happstack-data is used in happstack-state, yes?
13:57 < koeien> i was mostly talking about the xml stuff
13:57 < koeien> is that used as well? (at least that's where most of the test cases are failing)
13:57 < unmarshal> hello
13:57 < koeien> hi
13:57 < wchogg> koeien : Ah, valid point.
13:57 < unmarshal> i'm very excited to see the new direction on happstack
13:57 < koeien> unmarshal: good to hear
13:57 < wchogg> koeien : I'm not sure if the xml stuff is really used anywhere.
13:57 < unmarshal> would definitely be interested in helping out any way I can
13:58 < unmarshal> I'm very interested in using happstack for building nice concise REST web services
13:58 < unmarshal> i'm working on implementing the google file system in haskell
13:58 < unmarshal> and i think a nice happs REST protocol would be the best way to go
13:58 < koeien> wchogg: i sent an e-mail on the mailing list about a week ago. no response :)
13:59 < koeien> wchogg: it appears to be little used if at all
13:59 < dsrogers> koeien: you can't assume your users are on the mailing list.
13:59 < koeien> dsrogers: sure
13:59 < koeien> but it's hard to find out otherwise
14:03 < dsrogers> unmarshal: REST isn't really a protocol.  It's more like guidelines for building protocols.
14:03 < unmarshal> yeah i know this
14:03 < unmarshal> REST-like interface
14:03 < unmarshal> for speaking to each other
14:03 < unmarshal> is what i meant to say
14:04 < dsrogers> anyone tried out my compression part yet?
14:04 < unmarshal> i've implemented HTTP many occasions mainly for building tools for fuzz testing
14:04 < unmarshal> chunked encoding, etc.
14:04 < unmarshal> i would be ahppy
14:04 < unmarshal> happy
14:04 < unmarshal> to use those tools i built
14:04 < unmarshal> to assess the reliability
14:04 < unmarshal> of happs
14:04 < unmarshal> when the time comes
14:05 < dsrogers> well you can do it now...
14:05 < unmarshal> will look into it
14:06 < dsrogers> just make sure you're doing it against happstack, and not happs
14:06 < unmarshal> right
14:07 < unmarshal> i saw a blog post about a new http client lib being written
14:07 < unmarshal> how much progress has been made on it?
14:07 < dsrogers> there is?
14:07 < unmarshal> i'd like to convert the amazon web services tools (s3, etc) to use it
14:07 < dsrogers> where?
14:07 < unmarshal> here
14:07 < unmarshal> http://mattelder.org/projects/haskell-http-library/
14:10 < dsrogers> mae: you're guidelines are too strict, imo.  I mean, it's fine for small stuff, but big stuff needs things like aliasing, for example.
14:11  * dsrogers works for a large website
14:12 < unmarshal> you responding based on the blog post?
14:16 < dsrogers> yeah
14:16 < dsrogers> aliasing is sometimes incredibly useful.  Especially when proxying connections.
14:22 < unmarshal> is happstack going to be as xslt heavy as happs?
14:23 < unmarshal> i've heard that being a big turn off for a lot of people
14:23 < unmarshal> when they looked at happs
14:23 < dsrogers> you don't need xslt.
14:23 < unmarshal> i've personally never used it
14:23 < unmarshal> so i don't know much about it
14:23 < dsrogers> it's just some of the authors really like it.
14:24 < dsrogers> I hate it.
14:24 < unmarshal> yeah
14:24 < dsrogers> but no, you don't need it.
14:24 < unmarshal> i've heard nothing but bad things about it
14:24 < unmarshal> okay, good to know
14:24 < dsrogers> people have been using plain HTML files, HString, haxml, anything really
14:25 < dsrogers> you could even embed strings if you like pain or something
14:33 < gour> is using of reST markup privilege of python-based frameworks only (pandoc has support for subset of reST)?
14:34 < dsrogers> what?
14:34 < dsrogers> I think you're missing a verb.
14:34 < gour> which verb do you miss?
14:35 < dsrogers> what is "reST markup privilege?"
14:37 < gour> take it as: is it use of 'reST markup' the feature available only in...
14:39 < sm> gour: it seems to be
14:39 < sm> what's missing in pandoc reST ?
14:39 < gour> ahh, that's bad...markdown is too limited for my writing
14:39 < gour> tables is the main feature
14:40 < sm> ah
14:40 < sm> do you use them much ?
14:40 < gour> yep. i need them
14:41 < sm> personally I miss embedded html most. (I'm usually building sites, not pure docs.)
14:41 < gour> someone was saying to extend reST parser, but nothing yet
14:41 < gour> i'd need reST for blog-posts
14:42 < gour> actually, reST is my main markup used for authoring...with full reST support in pandoc, one could even convert to ConTeXt for 1st-class pdf publishing
14:44 < gour> from pandoc docs: "...it doesn't handle tables, option lists, or footnotes. "
15:06 < Saizan_> unmarshal: you never had to use xslt with happs
15:09 < unmarshal> kk
15:09 < unmarshal> i've never sat down and learned happs
15:09 < unmarshal> i really like the idea of the happs-state
15:09 < unmarshal> but i haven't done any web programming using haskell yet
15:10  * gour admires work done on happstack, but hope that (lighter) turbinado will become usefull as well for not so demanding web-apps
15:11 < stepcut> :)
15:11 < stepcut> I'm thinking we should just rename happstack to katamari :p
15:12 < gour> lol
15:12 < dsrogers> does that mean we'll get presents?
15:12 < unmarshal> it rolls over things
15:12 < dsrogers> and rainbows?
15:13 < dsrogers> I think happstack needs to be sold to people differently.  The stuff in happstack-server, which has nothing to do with that that state preservation stuff is great on it's own.
15:13 < dsrogers> I use SQL and JSON with it.
15:13 < stepcut> mostly it just rolls around and sucks up other projects. For example, happstack is now looking to 'include' HSP, hyena, and hstringtemplate
15:13 < stepcut> dsrogers: yeah, and I have used happstack-state with out the -server
15:13 < dsrogers> exactly
15:13 < gour> dsrogers: good idea. i'd also use sql db & json...
15:14 < stepcut> dsrogers: that is part of the beauty of happstack is that there are lots of pieces that work well together, but you can pick and choose the pieces that you need for your particular project
15:14 < gour> ...but macid is not for every setup
15:14 < dsrogers> indeed.  but a lot of people see the front page and go, eeew.
15:15 < dsrogers> I just want to use my (insert favorite web programming model here)
15:15 < gour> who would not run away screaming...
15:15 < dsrogers> when in reality, happstack-server is probably exactly what they wanted.
15:16 < stepcut> dsrogers: yeah, I have been meaning to do a writeup on what the philosphy behind happstack is (or should be)
15:16 < stepcut> dsrogers: because, there are somethings that happstack is not suitable for -- for example, shared server environments
15:16 < dsrogers> well happstack-server is
15:16 < stepcut> if you can't run your own daemons, then -server and -state are not very useful
15:16 < dsrogers> if you use a traditional DB backend.
15:16 < gour> i'll probably never have need for sharding for my web needs, just capable framework (ala django), helping to feed some boilerplate code
15:17 < stepcut> dsrogers: you will still need to run a server though on port 80, which most shared hosts do not allow
15:17 < gour> that's why i'm looking at django 'cause i did not want to entangle with php in order to tweak some (otherwise nice) cms-es
15:17 < dsrogers> stepcut: a wrapper for cgi for fcgi is not hard.
15:17 < dsrogers> and you still get to use ServerPartT
15:17 < gour> having fcgi would be cool...
15:17 < dsrogers> which is my favorite part anyway
15:18 < stepcut> dsrogers: right, there is already a fastcgi wrapper for happstack.
15:18 < stepcut> ServerPartT is one of my least favorite parts ;)
15:18 < gour> and some docs to use DB back-end...
15:18 < dsrogers> it was one of my least favorites.
15:18 < dsrogers> then I fixed it ;-)
15:18 < gour> then turbinado could join happstack as probably did yesod dev
15:19 < gour> otherwise, so many frameworks, none is even half-baked :-/
15:19 < dsrogers> but that's just another point.  you don't have to use happstack-server.  You can still use happstack-state
15:19 < stepcut> dsrogers: I don't like how everything is all string based. Too easy to make typos.
15:19 < stepcut> dsrogers: I don't think it makes it easy to write components which can be easily combined together, because there is no standard for specifying where the root path of each component is
15:20 < dsrogers> oh, I'm working on a fix for that.
15:20 < dsrogers> I'm also working on a standard library of reusable components.
15:20 < dsrogers> but fundamentally, you're going to have to write strings somewhere.
15:20 < dsrogers> you have to parse your URL somehow.
15:21 < stepcut> dsrogers: this is my (in-progress) solution to avoiding strings: http://src.seereason.com/~jeremy/SimpleSite1.html
15:21 < dsrogers> I'm also getting around to making a library of common HTTP constants too.
15:21 < stepcut> dsrogers: basically, I turn the URLs into composable Types, so that generating and parsing the URIs is all done by code not by hand. So, you get the type-checker to find your typos for you.
15:22 < stepcut> common HTTP constants?
15:22 < dsrogers> for headers.
15:23 < dsrogers> and return codes.
15:23 < dsrogers> there are a lot of strings sprinkled in the code.
15:23 < Saizan_> maybe use a proper enumeration
15:23 < Saizan_> like in the HTTP library
15:24 < dsrogers> indeed.
15:24 < dsrogers> that's what I had in mind.
15:24 < stepcut> I know there are some constants in, happstack/happstack-server/src/Happstack/Server/HTTP/Handler.hs
15:24 < dsrogers> stepcut: you're just using Network.URI, right?
15:24 < dsrogers> ok
15:24 < stepcut> but it would be nice if there was a common library used by happstack-server, hyena, etc
15:25 < Saizan_> right, it looks like HTTP has implemented this but it's not exposed in a sensible way
15:25 < stepcut> dsrogers: no...
15:25 < Saizan_> in fact some modules in -server are copy/pasted from it, iirc
15:29 < dsrogers> ohic
15:30 < stepcut> dsrogers: basically, you create data-types to represent the 'path' to the different resources in your site, like data Gallery = Thumbnails | ShowImage ImageId Size
15:30 < dsrogers> right.
15:30 < dsrogers> what's the url look like?
15:30 < stepcut> dsrogers: and there is a function that turns a value like, (ShowImage ImageId Size) into a url.
15:31 < stepcut> dsrogers: ultimately, the urls should look like very normal URLs, /gallery/showimage/123/fullsize
15:32 < stepcut> the 'interesting' part is that there also a ReaderT enivorment that holds the current root path to where you are
15:32 < dsrogers> yeah, I'm already thinking about something like that for ServerPartT, since it's already a ReaderT
15:32 < stepcut> so, in the Gallery modules, it just uses, showURL (ShowImage 123 Fullscreen), to generate a link, but that link could be nested
15:32 < dsrogers> proabably askEnv localEnv, akin to askRq and localRq
15:33 < stepcut> so if you had, data Gallaries = MyGallery Gallery | YourGallery Gallery, each would get its own unique links
15:34 < stepcut> dsrogers: spiffy
15:34 < dsrogers> "already a ReaderT" lol
15:35 < dsrogers> already a ReaderT, WriterT, MaybeT and ErrorT
15:35 < stepcut> what about an RWST ??
15:35 < dsrogers> what's a RWST?
15:36 < stepcut> it's a monad transformer that combines Reader Writer and State
15:36 < stepcut> but, it's different than just stacking them
15:39 < Saizan_> it's not a State yet :)
15:39 < dsrogers> indeed.
15:40 < stepcut> maybe it needs a LogicT and QIOT
15:41 < Saizan_> and then CC-delcont so that we can call it continuation-base?
15:41 < Saizan_> *based
15:42 < stepcut> nice
15:42 < stepcut> PerhapsT
15:44 < dsrogers> oo, anyone want to try a hand at writing a lifting instance for MonadFix?
15:45 < dsrogers> and MonadCont?
15:52 < dsrogers> what?   noone?
15:53 < Saizan_> can't you use newtype deriving for those?
15:53  * stepcut is still trying to fix IxSet migration
15:53 < dsrogers> um, maybe?
15:53 < dsrogers> I don't think so though.
15:53 < Saizan_> try it
15:54 < dsrogers> I'll have to try later.
15:56 < dsrogers> it's official.  4 MM lines of code is too much
15:58 < stepcut> sweet!
15:58 < stepcut> 10k should be plenty
15:59 < dsrogers> The app I work on every day as 4MM
15:59 < dsrogers> written in at least 7 languages
15:59 < dsrogers> no, 8
15:59 < dsrogers> no 9
15:59 < dsrogers> shit.
15:59 < dsrogers> I should stoop counting
16:02 < dsrogers> 10k wouldn't even cover our tax handling code.
16:03 < stepcut> :)
16:05 < dsrogers> heh
16:05 < dsrogers> some days it's frustrating
16:05 < stepcut> 9 languages... so one more, say Haskell, shouldn't matter, right ?
16:06 < dsrogers> lol.
16:06 < dsrogers> if it's jhaskell noone would care.
16:06 < stepcut> and, then once it is all written in Haskell it would only be 400K lines
16:06 < dsrogers> but demanding that our developers install ghc is a little steep
16:06 < stepcut> apt-get install ghc6
16:06 < stepcut> bam! done!
16:07 < dsrogers> lol
16:08 < stepcut> this IxSet migration stuff is not going well
16:08 < dsrogers> what's wrong?
16:08 < Saizan_> yeah, i thought we were almost there yesterday
16:09 < stepcut> Saizan_: I don't see a way to drop the HAppS.Indexable .. at least not with out circular imports
16:09 < Saizan_> we can put it in its own module i think
16:10 < stepcut> Saizan_: yeah, I think that is what I am going to do
16:11  * Saizan_ is trying to build the docs using ghc HEAD
16:14 < stepcut> Saizan_: argh. Easier said than done. Indexable needs to refer to the IxSet datatype in Happstack.Data.IxSet but other things in that module refer to Indexable. So, I would need to move the IxSet datatype into a new module as well. Except I can't because that would break migration :-|
16:16 < Saizan_> oh, right, because of empty
16:18 < Saizan_> we might change the Serialize instance of HAppS.IxSet so that it no longer requires Indexable, using the ISet constructor
16:18 < dsrogers> what about an export-import approach?
16:20 < Saizan_> oh, fun happstack-data doesn't compile with 6.11
16:23 < Saizan_> stepcut: uhm, i think i can fix that, can you construct a patch with the code as of yesterday?
16:23 < Saizan_> stepcut: i.e. with the new Serialize instance compiling but requiring HAppS.Indexable
16:23 < dsrogers> is there discussion of 6.11 somewhere?
16:25 < stepcut> Saizan_: sure, I am wondering if maybe we want to add special migration type similar to, extension, but called, renamed, which would indicate that the only thing which changed was the name?
16:25 < Saizan_> 6.11 is the name for the current developement version, there's a mailing about it i think
16:26 < dsrogers> so, shared libraries in there yet?
16:27 < Saizan_> stepcut: so that the old type doesn't need to exist?
16:27 < stepcut> Saizan_: yeah..
16:27 < stepcut> Saizan_: actually, normal migration does not even affected by renames
16:29 < stepcut> Saizan_: it's only checkpoints that are, because checkpoints actually serialize the name of the component.
16:32 < stepcut> Saizan_: where should I send the patch?
16:32 < Saizan_> sanzhiyan -at- gmail dot com
16:34 < stepcut> Saizan_: sent, I think...
16:35 < Saizan_> stepcut: arrived.
16:45 < stepcut> Saizan_: sweet!
17:13 < Saizan__> stepcut: i've sent you a patch back, unfortunately i had to define the new IxSet in an .Internal module, if we want Happstack.Data.IxSet to export the Version and Migration instances
17:14 < Saizan__> stepcut: oh, i forgot to add that module to the .cabal file in other-modules
17:58 < stepcut> Saizan__:
17:58 < stepcut> src/Happstack/Data/IxSet.hs:130:11:
17:58 < stepcut>       Could not deduce (HAppS.Indexable a b)
17:58 < stepcut>       from the context (Version (IxSet a), Serialize a, Ord a, Data a, Indexable a b1)
17:58 < stepcut>       arising from a use of `extension' at src/Happstack/Data/IxSet.hs:130:11-54
17:58 < stepcut>  
18:03 < Saizan__> stepcut: ah, sorry, recorded only half of the changes
18:05 < Saizan__> stepcut: i've sent another bundle
18:15 < stepcut> :)
19:07 < Saizan> i've built happstack-data's documentation, yay, commenting out some code though
19:29 < wchogg> Saizan_ : what was the offender causing haddock to break?
19:31 < Saizan_> wchogg: this bug http://trac.haskell.org/haddock/ticket/68
19:31 < Saizan_> so you need ghc HEAD to generate the sources..
19:32 < Saizan_> s/sources/docs/
19:47 < perspectivet> Saizan_: long time no chat, did that hspread stuff ever get used?
19:48 < perspectivet> Saizan: long time no chat, did that hspread stuff ever get used?
19:50 < Saizan> perspectivet: yup. multimaster got implemented with it
19:57 < perspectivet> is that actually working now?
20:01 < wchogg> yes, multimaster works well from what I can tell
20:01 < wchogg> I've been playing with it for a new chapter in happs tutorial
20:03 < perspectivet> cool.  I helped a bit with hspread back in the day, I was just curious if it ever got used.
20:03 < perspectivet> or rather how far along the multimaster work went
20:03 < perspectivet> I'll have to pull it down and give it a try.
20:04 < wchogg> Honestly I found hspread less finicky than Spread itself.
20:04 < perspectivet> you can thank Saizan for that, as he did most of the work.
20:05 < perspectivet> I helped a *bit*
20:12 < oshyshko> How to write a handler that prints POST body? I already have one that return URL as response: [ dir "json"    [withRequest $ \rq -> ok $ toResponse $ rqURL rq]
20:18 < Saizan> oshyshko: use rqBody instead
20:18 < Saizan> oshyshko: maybe you've to unpack it since it's a bytestring
20:18 < Saizan> unless there's a ToMessage instance for ByteStrings
20:24 < oshyshko> Yeah. rqBody :: Request -> RqBody. Is there a function that extracts ByteString from it?
20:41 < oshyshko> Nevermind. I've just written my own one.
20:44  * stepcut mostly understands the binary format of checkpoint files now
20:45 < Saizan> stepcut: does the migration work?
20:45 < oshyshko> Another question: how do I call IO function from a handler? E.g. my function is "callJson :: String -> IO String". Usage (wrong): [withRequest $ \rq -> ok $ toResponse $ ???callJson??? $ getBody $ rqBody rq]
20:45 < stepcut> Saizan: trying it now
20:46 < Saizan> oshyshko: [withRequest $ \rq -> do x <- liftIO $ callJson $ getBody $ rqBody rq); ok $ toResponse x]
20:49 < stepcut> Saizan: I get this error:
20:49 < stepcut> ghc: /usr/lib/haskell-packages/ghc6/lib/happstack-ixset-0.1.9/ghc-6.10.1/HShappstack-ixset-0.1.9.o: unknown symbol `happstackzmixsetzm0zi1zi9_HappstackziDataziIxSetziInternal_ISet_con_info'
20:49 < stepcut> when trying to link against the new IxSet
20:50 < Saizan> eh, right, add Happstack.Data.IxSet.Internal to other-modules
20:50 < Saizan> sorry for the sloppyness :)
20:50 < stepcut> no problem
20:50 < stepcut> I am pretty out of it myself, been sick the past few days
20:51 < Saizan> i'm battling against my flaky internet connection and random kernel panics, wondering if they are related.
20:52 < stepcut> :-/
20:52 < oshyshko> Saizan: thank you!
20:52 < mae> wow
20:52 < mae> Net::Amazon::S3 uses about 10x the filesize of heap when doing a PUT
20:52 < mae> that is awful
20:53 < Saizan> i hope our S3 module is doing better
20:53 < mae> I had to reduce my tarball chunks to 25MB so it only uses 300ish MB of memory :)
20:53 < mae> Saizan: I am using backup-manager because its easy
20:53 < mae> but I am not impressed :)
20:56 < mae> when is ghc 6.8.2 out?
20:59 < Saizan> you mean when we should drop support for it?
21:03 < mae> um no sorry
21:03 < mae> haha
21:03 < mae> i meant
21:03 < mae> when is 6.10.2 out
21:13 < Saizan> they decided to postpone it a couple of weeks because of some papers deadline
21:14 < dsrogers> how ... academic!
21:15 < dsrogers> not that I'm complaining.
21:16 < dsrogers> finally!  off to home!
21:16 < dsrogers> ...
21:16 < dsrogers> man, what a commute.
21:17 < stepcut> haha
21:23 < dsrogers> where was that directory listing code I should look at?
21:28 < dsrogers> so I don't think compress support works in that output filter I wrote.
21:29 < dsrogers> what library should I be using to decomress the data?
21:29 < dsrogers> anyone know?
21:30 < Saizan> zlib?
21:30 < Saizan> that's the standard for gzip compression
21:31 < dsrogers> that's for "gzip"
21:31 < dsrogers> what about "compress"?
21:31 < Saizan> ah
21:32 < dsrogers> is says it's equivilent to compress.
21:32 < dsrogers> ...
21:32 < dsrogers> gurr.
21:37 < dsrogers> ahhhh
21:37 < dsrogers> I misread the rfc.
21:37 < dsrogers> I'll fix now.
21:38 < stepcut> sucka
21:46 < dsrogers> fixed!
22:04 < stepcut> gah! someone removed Happstack.Store.Util :(
22:05 < Saizan> mae
22:06 < stepcut> that guy apparently doesn't care about migrating an existing data :(
22:08 < dsrogers> gahhh
22:08 < dsrogers> apparently happstack really doesn't like IPv6
22:09 < dsrogers> I didn't used to get ISEs over IPv6.
22:10 < dsrogers> what happened?
22:23 < dsrogers> anyways, fixed!
22:25 < chessguy> @users
22:25 < dsrogers> @users
22:37 < stepcut> so withDataFn is not backwards compatible to 0.1 ?
22:37 < stepcut> or dir maybe?
22:37  * stepcut figures out what is going on
22:46 < mae> dsrogers, stepcut: i removed ipv6 support
22:46 < mae> it breaks the build under windows.
22:46 < dsrogers> can we make it conditional?
22:46 < mae> we can add it back when the network package is updated to be more ipv6 friendly
22:47 < mae> dsrogers: the network package does conditional compilation
22:47 < dsrogers> because taking it out breaks me entirely
22:47 < Saizan> stepcut: you've to use msum
22:47 < mae> dsrogers: explain.
22:47 < dsrogers> I'm on an IPv6 network.
22:47 < dsrogers> when I type "localhost:5000" the peer address is IPv6
22:47 < dsrogers> and it barfs.
22:48 < mae> ic.
22:48 < mae> so you can't use 127.0.0.1?
22:48 < dsrogers> same problem.
22:48 < stepcut> Saizan: ok
22:48 < dsrogers> the browser uses "host: 127.0.0.1" but connects with an ipv6 connection.  This is because "127.0.0.1" looks up as an IPv6 address
22:49 < mae> so the socket is binding to wildcard then i think
22:49 < dsrogers> yes...
22:49 < dsrogers> but in any case, why can't I have it just for my system?
22:49 < mae> one way to fix this is to allow simpleHTTP to accept a bind address
22:49 < dsrogers> it's only one line...
22:49 < dsrogers> in fact, I don't see how this is breaking anything.
22:49 < mae> dsrogers: you can, i wanted to keep ipv6 but I figured fixing windows was more important
22:50 < mae> i thought that ipv6 would translate to ipv4 transparently
22:50 < dsrogers> noooo.
22:50 < mae> dsrogers: so we can do some conditional compilation i suppose
22:50 < mae> but other platforms also do not support ipv6
22:50 < dsrogers> the problem here is that it accepts the ipv6 connection just fine and then says it doesn't like it.
22:51 < mae> we need a portable way to detect whether the host libc supports ipv6
22:51 < dsrogers> if it didn't bind to ipv6 at all, we would be ok.
22:51 < dsrogers> did you look at my patch?  how is that one line not portable?
22:51 < dsrogers> is that type not availabe on systems that don't have conditional compilation?
22:51 < mae> the thing that irks me is that, network will conditionally turn off the constructors for HostAddress6 etc
22:51 < mae> even SockAddrInet6
22:52 < dsrogers> ahhhh
22:52 < dsrogers> that is very irksome.
22:52 < Saizan> maybe we need TH
22:52 < mae> so you _have_ to have conditional infecting static compilation code anywhere you match
22:52 < mae> i wish they would have done something like
22:52 < Saizan> you can check if a constructor is available with reify
22:52 < mae> Network.Socket.supportsIPV6 :: Bool
22:52 < mae> and still exposed HostAddress6 to all platforms
22:53 < Saizan> yeah, like isIEEE
22:53 < mae> hm.
22:53 < mae> so uhm
22:54 < mae> Saizan, can you write me an example snippet of code how i check to see if a constructor exists?
22:54 < mae> so i can update the code
22:54 < Saizan> ok
22:55  * stepcut is not sure that adding msum all over his code is an improvement
22:55 < dsrogers> the alternative is to limit your bind address to ipv4 only (i.e. don't bind to *)
22:56 < mae> stepcut: its more explicit / orthogonal though :)
22:56 < stepcut> I suppose
22:56 < mae> dsrogers: yeah thats what i mentioned earlier
22:56  * stepcut is hoping to get convinced over time
22:56 < dsrogers> ah, didn't see that before.
22:57 < mae> <mae> one way to fix this is to allow simpleHTTP to accept a bind address
22:57 < dsrogers> stepcut: the idea is that you'll be able to delete extra []'s
22:57 < dsrogers> I believed you.
22:57 < dsrogers> I'm just ill
22:57 < mae> heh
22:57 < dsrogers> ssl has terrible documenation
22:57 < stepcut> why is method deprecated?
22:58 < dsrogers> because it's redundant now.
22:58 < dsrogers> it pushes you into WebT
22:58 < dsrogers> there is no reason to do that.
22:58 < stepcut> what if I am already in WebT
22:58 < dsrogers> did you read the release notes?
22:58 < dsrogers> you don't need to be in WebT anymore.
22:58 < dsrogers> I wrote some release notes explaining this.
22:58 < stepcut> where are these notes?
22:59 < dsrogers> projectroot/RELEASE_NOTES
23:00 < dsrogers> http://patch-tag.com:5003/publicrepos/happstack/RELEASE_NOTES
23:02 < h_buildbot> Build for ghc-6.8.3 failed. Check http://buildbot.happstack.com/ for details.
23:06 < Saizan> uhm i've some problems constructing a name that'll match 'SockAddrInet6
23:06 < Saizan> without using that quotation off course
23:09 < h_buildbot> Build for ghc-6.10.1 OK. Test suite ran. 15/69 test cases failed. Check http://buildbot.happstack.com/ for details.
23:10 < stepcut> grr, Failed to load interface for `Happstack.Data.HList':
23:10  * stepcut tries to figure out how is depending on that
23:10  * stepcut is starting to like it better when happs didn't change at all ;)
23:11 < dsrogers> heh
23:11 < dsrogers> mae: did you move HList around or something?
23:11 < dsrogers> that should be in the release notes too
23:11  * stepcut has a *lot* of happstack based code to update
23:12 < stepcut> cookieFixer :: ServerPartT m a -> ServerPartT m a
23:12 < stepcut> cookieFixer (ServerPartT sp) = ServerPartT $ \request -> sp (request { rqCookies = (fixedCookies request) } )
23:12 < stepcut> how should I rewrite this?
23:12 < Saizan> mae: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=1559#a1559
23:13 < Saizan> stepcut: add a ReaderT layer
23:13 < dsrogers> cookieFixer a = localRq (\request -> sp (request { rqCookies = (fixedCookies request) } )) a
23:14 < dsrogers> your types will change.
23:14 < Saizan> or thath.
23:14 < mae> stepcut: Happstack.Contrib.HList
23:14 < stepcut> mae: I don't actually need it, I just need to rebuild everything that ever linked against it that I depend on in my app
23:14 < mae> regarding release notes, it is in CHANGELOG
23:14 < mae> release notes i intended more as an in depth ad-hoc note thing
23:14 < mae> and changelog is terse
23:15 < mae> not much to explain, other than the fact that i changed it
23:15 < mae> stepcut: ok :)
23:16 < mae> dsrogers: you going to integrate the cookie fix?
23:16 < dsrogers> you want me too?
23:16 < dsrogers> I can do that.
23:16 < mae> absolutely
23:16 < mae> is there an issue for that?
23:17 < dsrogers> where is the cookie fixer?
23:17 < mae> i'll create one if there isn't
23:17 < dsrogers> we can close the gzip compression issue now, too
23:17 < stepcut> dsrogers: happstack-extra
23:17 < stepcut> dsrogers: http://src.seereason.com/happstack-extra
23:17 < mae> dsrogers: your a project member on the google code thing right?
23:17 < Saizan> coockie fixer in which sense?
23:17 < dsrogers> yes
23:18 < mae> dsrogers: go ahead and mark that issue as fixed then.
23:18 < dsrogers> Saizan: apparently the parser dies if the cookie is not RFC compliant.
23:18 < stepcut> Saizan: 'fixes' the cookie parsing when google cookies are involved
23:18 < Saizan> aaah, i was the first to report that bug, actually :)
23:19 < dsrogers> oh.
23:19 < Saizan> so we're going to "fix" the parser at the origin, i guess?
23:19 < dsrogers> I'm not a "project member"
23:19 < dsrogers> I just have an account.
23:19 < dsrogers> so I can't close issues.
23:19 < dsrogers> that would explain why I didn't do it before..
23:20 < dsrogers> that's the idea.
23:20 < mae> i just added you
23:20 < mae> daniel@phasevelocity.org
23:21 < dsrogers> ack!
23:21 < dsrogers> that's going to be on the web now!
23:21 < stepcut> Saizan: yeah, some day we should fix happstack-server so that no fixes are needed
23:21 < dsrogers> eh.
23:21 < mae> http://code.google.com/p/happstack/issues/detail?id=65
23:21 < stepcut> dsrogers: yay!
23:21 < mae> ^ cookie fixer bug
23:21 < dsrogers> I doubt my spam could get worse.
23:22 < mae> dsrogers: same, it seems to have died off, but about a month ago i was getting 100 spam messages a day that made it past my spam filter. they were really crafty too, they looked like out of office replies, and fake bounce messages.
23:23 < mae> sorry about that though :)
23:25 < dsrogers> so is there any reason I can't just yoink everything in there?
23:26 < stepcut> dsrogers: is there a, withRequestSP :: (Request -> ServerPartT m a) -> ServerPartT m a ?
23:26 < h_buildbot> Build for ghc-6.10.1 OK. Test suite ran. 16/69 test cases failed. Check http://buildbot.happstack.com/ for details.
23:27 < dsrogers> (askRq >>=)
23:28 < dsrogers> and if I yoink cookie fixer is it going to break anyones applications?
23:28 < stepcut> yoink?
23:28 < dsrogers> take
23:28 < dsrogers> its onamonapia
23:28 < stepcut> dunno
23:29 < dsrogers> stepcut: do you know if you pass an RFC compliant cookie, will it return the same value?
23:29 < dsrogers> I can figure this out, of course...
23:30 < dsrogers> stepcut, are you fixing Happstack-helpers?
23:32 < wchogg> What's wrong with happstack-helpers?
23:32 < dsrogers> it doesn't compile under HEAD proabbly
23:32 < dsrogers> uhoh... cookie parsing uses "fail"
23:32 < stepcut> no just my own code
23:33 < wchogg> ghc head or happstack head?
23:33 < wchogg> which do you mean?
23:33 < dsrogers> happstack.
23:33 < wchogg> Hrmm...I'll take a look a bit later.
23:33 < dsrogers> so, what was the behavior of fail before I refactored ServerPartT?
23:33 < wchogg> Might not be tonight though.
23:34 < dsrogers> how do I get darcs to show me an old version of a file?
23:36 < dsrogers> anyone?
23:37 < h_buildbot> Build for ghc-6.8.3 OK. Test suite build failed. Check http://buildbot.happstack.com/ for details.
23:37 < Saizan> darcs diff --from-patch or something like that
23:40 < dsrogers> darcs diff is completely broken for me.
23:41 < dsrogers> fucking case insenstivie bug.
23:41 < dsrogers> GURR!
23:41 < dsrogers> would anyone mind giving me a hand here?
23:41 < dsrogers> and give me a definition of "fail" pre my patches?
23:41 < dsrogers> for the ServerPartT and WebT monads?
23:41  * stepcut has no idea
23:42 < mae> Saizan: crash course in if/then for TH?
23:43 < mae> hm
23:43 < mae> get your darcs working :)
23:43 < dsrogers> it's a bug in darcs.
23:43 < dsrogers> it's been there forever.
23:43 < mae> dsrogers: slow and steady wins the race, don't burn out! :)
23:43 < Saizan> 05:42     Saizan : , [| if True then 1 else 2 |]
23:43 < Saizan> 05:42    lunabot :  CondE (ConE True) (LitE (IntegerL 1)) (LitE (IntegerL 2))
23:44 < Saizan> dsrogers: use the 0.1 tarball
23:44 < mae> Saizan: is that "at compile time" flow control?
23:44 < dsrogers> ah.
23:44 < dsrogers> good idea.
23:44 < Saizan> mae: ah, no
23:44 < dsrogers> hmm, so Happstack.Server.Cookie calls "fail" if cookie parsing fails
23:44 < dsrogers> it should really return an Either or something.
23:44 < Saizan> mae: so you want something like #ifdef but in TH?
23:44 < mae> Saizan: yeppers.
23:45 < mae> Saizan: if we use the constructor at all on platforms that don't support it, the compilation will choke
23:45 < mae> Saizan: s/platforms that don't support it/platforms that network doesn't support because it uses conditional compilation/
23:45 < Saizan> $(if condition then foo :: Q Exp else bar :: Q Exp) where foo and bar are the AST of the code
23:46 < mae> k
23:46 < Saizan> that you can create with [| .. |]
23:46 < mae> thx !
23:46 < stepcut> Saizan: noCalcs seems to be missing now...
23:47 < mae> Saizan: is "else" required? :)
23:47 < Saizan> mae: yes, as always
23:47 < mae> hmm
23:47 < dsrogers> fail wasn't overridden.
23:47 < mae> so what is Nothing for Q exp
23:47 < dsrogers> which means it throws an exception
23:47 < mae> err Q Exp
23:47 < dsrogers> and now it does an ISE
23:47 < Saizan> stepcut: it means you removed it in the patch you sent to me
23:47 < dsrogers> and cookie parsing, when it fails, will throw an ISE
23:48 < dsrogers> that's not good.
23:48 < stepcut> Saizan: ok, I'll take the blame :)
23:48 < mae> Q [| |] ?
23:48 < mae> :)
23:48 < Saizan> i don't think there's a Nothing
23:48 < Saizan> where are you splicing that code? what type it expects?
23:49 < Saizan> stepcut: noCalcs _ = () anyhow
23:49 < mae> i'm using it to conditionally add a pattern for SockAddrInet6
23:49 < mae> under acceptLite
23:50 < Saizan> ah, then you want to generate the whole case expression, and include or not that case
23:50 < mae> hm
23:50 < mae> ok
23:50 < Saizan> or use WildP in the else case
23:50 < mae> WildP is
23:50 < mae> nothing?
23:50 < mae> :)
23:50 < Saizan> i don't recall if you can splice in pattern position
23:51 < Saizan> WildP is _
23:51 < mae> oh i see
23:51 < dsrogers> mae: you have to put the entire expression  into a slice IIRC
23:51  * Saizan takes a look
23:53 < Saizan> it seems you can't simply splice a pattern
23:54 < mae> ok
23:54 < mae> 10-4
--- Log closed Fri Feb 20 00:00:12 2009