--- Log opened Wed Dec 09 00:00:45 2009
10:23 < HugoDaniel> hi
10:24 < HugoDaniel> how does happstack handle https connections ?
10:30 < JohnDoe365> HugoDaniel: http://huygens.functor.nl/blog/
10:33 < HugoDaniel> thanks JohnDoe365
15:33 < mightybyte> Anyone know what causes happstack's "HTTP request failed with: Unsupported socket
15:33 < mightybyte> ...error?
15:37 < stepcut`> mightybyte: maybe
15:37 < stepcut`> what version of happstack and what OS ?
15:37 < stepcut`> and what version of network and GHC
15:37 < jmcarthur_work> you using localhost or 127.0.0.1 on os x?
15:38 < stepcut`> mightybyte: most critically, I fixed some issues a few weeks ago, if it is broken in head, that would be concerning
15:40 < mightybyte> No, it's not broken in head.
15:40 < mightybyte> I get the error when I try to run my app on a Debian 5 box.
15:41 < mightybyte> I've been running it fine on an ubuntu box.
15:41 < mightybyte> It's compiled with happstack-0.4
15:42 < mightybyte> GHC 6.10.4
15:43 < mightybyte> And network-2.2.1.2
15:43 < stepcut`> hrm
15:44 < stepcut`> what do you mean by happstack-0.4? That is something after 0.3, but not head ?
15:44 < stepcut`> 0.4 stable has not been released yet..
15:45 < mightybyte> Well, I don't know if it's broken in head because I don't usually compile my production app with head.
15:45 < mightybyte> Oh, wait...maybe I tried something from head awhile back.
15:45 < mightybyte> But I haven't updated recently.
15:46 < stepcut`> the only remaining patch for happstack 0.4 stable is a fix so that sendfile() works with GHC 6.12. So, head is in a pretty good state right now AFAIK
15:46 < stepcut`> but one moment
15:46 < mightybyte> Looks like I'm using a version pulled from head on Aug 9
15:47 < stepcut`> http://patch-tag.com/r/mae/happstack/snapshot/hash/20091114171117-8e95d-0ee6c02ecc7bc37c6527af8c9473396319d553c3/patch
15:47 < stepcut`> that is the patch that fixed all know occurances of the unsupported socket error
15:48 < stepcut`> if you want to be conservative you could pull just that patch
15:48 < mightybyte> I'll just pull what's current and give that a try.
15:49 < stepcut`> yeah, there was actually a somewhat serious state bug that was fixed Nov 6 as well, so I would definitely upgrade :)
15:49 < mightybyte> Ok.
15:49 < mightybyte> What was the bug?
15:50 < stepcut`> under heavy congestion, events would sometimes fail (call error and die)
15:50 < mightybyte> Ok
15:50 < mightybyte> I don't usually have that problem.
15:51 < stepcut`> that one test that sometimes failed in happstack-state... I finally tracked it down and it turned out it was a valid bug
15:51 < mightybyte> Cool.  Nice to know the tests are useful.
15:51 < stepcut`> the xml tests that are failing in happstack-data are still a mystery
15:53 < stepcut`> but not very concerning
15:53 < stepcut`> the could be valid if newtypes where supposed to be 'transparent' when rendered to XML, or something like that
15:53 < stepcut`> but at this point it in time, it might be better to say that the current behavior is correct
15:54 < stepcut`> The person who wrote the tests said he may eventually look at them and see if he remembers why he committed broken tests
15:54 < mightybyte> What are the orphan instance warnings?
15:55 < stepcut`> if you define a type in one file, but define class instances for it in another file, they are known as orphan instances
15:55 < stepcut`> there is a risk that you might import only the type, but not the instances
15:55 < mightybyte> Oh.  That doesn't seem worthy of a warning.
15:55 < stepcut`> that can be especially troublesome if you then create new conflicting instances in your module
15:55 < mightybyte> I recently got that warning in some other code I was writing.
15:55 < stepcut`> and then someone tries to import both modules
15:55 < mightybyte> Ahh
15:56 < stepcut`> but, in some cases, they are difficult to avoid
15:56 < mightybyte> Yeah
15:56 < stepcut`> for example, the Serialize class is happstack specific, but has instances for things like String, Char, ByteString, etc.
15:56 < sm> stepcut`: nice work fixing things, thanks
15:56 < stepcut`> sm: I fixed something?
15:57 < sm> what you talked about above
15:57 < stepcut`> ah
15:57 < stepcut`> yeah, if mae would take the patches for sendfile we could release 0.4!
15:57 < sm> oh I thought mae stepped down ?
15:58 < sm> sendfile's a different project I guess
15:58 < stepcut`> from happstack. But he is the only person with commit access to sendfile.
15:58 < stepcut`> unfortunately, the patches to sendfile 6.12 require incompatible API changes
15:59 < stepcut`> and since 6.12 will be out before happstack 0.5, I want to fix 0.4 to work with 6.12 so we don't have to come back to it later
15:59 < sm> seems like mae should put sendfile on patchtag (if not already) and add you as a committer ?
15:59 < stepcut`> it is on patch-tag
15:59 < stepcut`> I asked for commit access
16:00 < stepcut`> though I would still like his stamp of approval for the sendfile patches -- the changes were his idea, but I had to make some other alterations
16:00 < sm> I saw some mails on list.. maybe ask again ? I will vote you for president
16:01 < stepcut`> I just asked again yesterday
16:02 < sm> I'll reply.. do you mean your latest msg down at the end of the happstutorial thread ?
16:02 < stepcut`> I could, of course, just upload sendfile 0.6 to hackage from a forked sendfile
16:03 < stepcut`> I think it is mostly just a time issue on mae's part
16:03 < mightybyte> Hmmm, waht happened to happstack-extra?
16:03 < sm> that's true. I'd say give warning and then do that.. that'll teach him to read email :)
16:03 < stepcut`> he intended to hand all the power to me so that he would not be a blocker, but we missed some stuff
16:04 < stepcut`> mightybyte: http://src.seereason.com/happstack-extra
16:04 < sm> I expect he'll respond again soonish
16:04 < mightybyte> Is it still maintained to compile with the latest happstack head?
16:04 < stepcut`> sm: yeah, I am not in a big rush, I do have other things to do :)
16:05 < stepcut`> mightybyte: in theory, yes. Though we are a bit behind head at the moment for no real reason
16:05 < stepcut`> mightybyte: but it also depends on our forked version of formlets
16:05 < stepcut`> mightybyte: something we hope to unfork someday
16:05 < mightybyte> Ohhhhh
16:05 < mightybyte> Hmmm, the version I had isn't compiling.
16:06 < mightybyte> Let me try updating.
16:06 < mightybyte> I'm the formlets maintainer, do you have anything that I could merge in?
16:06 < stepcut`> mightybyte: possibly
16:06 < stepcut`> mightybyte: one moment
16:07 < stepcut`> mightybyte: this is the patch that caused the fork
16:07 < stepcut`> http://src.seereason.com/formlets-debian/debian/patches/010-xml-monad.diff
16:08 < stepcut`> specifically,
16:08 < stepcut`> -newtype Form xml m a = Form { deform :: Env -> State FormState (Collector (m (Failing a)), m xml, FormContentType) }
16:08 < stepcut`> +newtype Form xml m a = Form { deform :: Env -> State FormState (Collector (m (Failing a)), xml, FormContentType) }
16:08 < stepcut`> instead of 'm xml' we wanted just 'xml'
16:08 < stepcut`> which is actually how formlets used to be
16:09 < stepcut`> then Chris thought that changing it to 'm xml' would make it easier to do inline validation, though he never actually implemented it
16:09 < stepcut`> the problem is that forcing the xml generator and validator to be in the same monad is not always what you want
16:09 < stepcut`> with the old version you could make them be the same monad if you wanted, but you didn't have to
16:11 < stepcut`> I also have a patch that I think is required if you want to be able to implement thing like multi-select inputs
16:12 < stepcut`> anyway, to the best of my knowledge, nothing in formlets requires the, m xml, constraint. Though changing it will require Formlets users to make some trivial(?) changes to their code. Perhaps just changing the type signatures ..
16:13 < stepcut`> for example, change, 'Form XML IO Int'  to 'Form (IO XML) IO Int'
16:13 < aavogt> stepcut`: is there a way to expose the form id for handling the failing case?
16:14 < aavogt> this value is used in the default error messages
16:14 < stepcut`> aavogt: not quite sure what you mean by that
16:14 < aavogt> but there doesn't seem to be a way to get at it if you do any custom validation afterwards
16:15 < aavogt> stepcut`: the "fval(1,2,3)" that gets used as the form's id
16:15 < stepcut`> aavogt: the answer is somewhat complicated
16:15 < aavogt> say you wanted to run something over the generated html to annotate which forms failed
16:15 < aavogt> and also wanted to display a textual suggestion about what is wrong
16:16 < aavogt> such as you cannot select 2 bunnies
16:16 < stepcut`> aavogt: I wrote a patch to the old formlet that demo'd how to do that, though I was not especially thrilled by it
16:16 < aavogt> in what respect?
16:16 < stepcut`> aavogt: but there are a few issues here, just doing more validation should be possible already by using, `check` or `checkM` yes?
16:17 < stepcut`> aavogt: the secondary issue is displaying those error messages 'inline'
16:17 < aavogt> yes, I use check and checkM
16:17 < aavogt> but these don't allow access to the information necessary to stick that stuff inline
16:17 < aavogt> by that stuff, I mean error messages
16:18 < stepcut`> aavogt: here is the forke I did which supports inline errors, http://src.seereason.com/examples/formlets-inline/TextDemo.hs
16:18 < stepcut`> well here, http://src.seereason.com/examples/formlets-inline/
16:19 < aavogt> I'll take a look
16:19 < stepcut`> http://src.seereason.com/~jeremy/formlets-inline.png
16:19 < aavogt> nice, that's what I was looking for
16:19 < aavogt> thanks stepcut`
16:23 < stepcut`> the biggest issue with that code is that it needs to be ported to the new formlets library. But the internals changed a fair bit.
16:24 < stepcut`> mightybyte: so, let me know how you feel about loosen the contraint on the 'xml' part of the Form. As far as I can tell the current, 'm xml' does not bring any benefits?
16:33 < mightybyte> stepcut: Sorry, I was afk for a bit there.
16:39 < mightybyte> stepcut`: Yeah, Chris and I have talked about getting rid of the monad for xml.
16:40 < stepcut`> sweet
16:40 < stepcut`> if that happens, then I can provide a patch that merges the rest
16:40 < stepcut`> or rather a set of patches
16:40 < mightybyte> Ok, that would be nice.
16:40 < stepcut`> the other stuff is pretty straight forward
16:41 < mightybyte> I've been focused on other things recently, so I haven't thought about formlets much.
16:41 < stepcut`> I also have a hsp formlets library
16:41 < stepcut`> I'll just make all the changes we want, and then notify you
16:41 < stepcut`> is formlets in darcs or git these days?
16:42 < mightybyte> It's on github.
16:43 < stepcut`> k
16:43 < mightybyte> Chris's repo is still the official one, but I'm the maintainer (if you can call it that).
16:44 < stepcut`> ok
16:44 < sm> cool
16:45 < mightybyte> stepcut`: Why did you decide to completely remove that monad rather than just using Identity?
16:46 < stepcut`> mightybyte: well, more I decided to not upgrade to the newer version hoping chris would change his mind
16:47 < stepcut`> mightybyte: but also, for HSP it is possibly less annoying
16:47 < stepcut`> oh actually
16:47 < stepcut`> it was for than that
16:48 < stepcut`> i need one monad for generating XML and a different one for doing validation
16:48 < mightybyte> Ok
16:49 < mightybyte> I can't get rid of the nagging thought that decreasing generality here might come back to bite me.
16:49 < stepcut`> and the monads were not compatible with each other ..
16:49 < stepcut`> decreasing generality?
16:49 < stepcut`> how is 'a' less general than 'm a'?
16:51 < stepcut`> with the type, Form xml m a, you can always create an alias, type Form' xml m a = Form (m xml) m a
16:51 < stepcut`> but you can't go the other way..
16:51 < mightybyte> Ahhh, yes.
16:52 < mightybyte> Grrr, don't know why I was thinking that "a" precluded the use of a monad.
16:52 < stepcut`> so, you can still write functions that require the xml and validation to happen in the same monad. But right now we require it, and don't even have any functions like that, as far as I know..
16:52 < mightybyte> Right
16:54 < stepcut`> I think the ContentType stuff is a bit bogus in Formlets, but I have not looked closely -- fortunately, you can just ignore it :)
16:55 < mightybyte> Yeah, I haven't paid much attention to that either.
16:55 < aavogt> it should import the happstack ContentType
16:55 < aavogt> it is a piece of copy pasta fromthere
16:56 < stepcut`> well, my issue with it is that it implies each field in the form can have a different content encoding (multipart/form-data vs url-encoding). But I think that is only definable in the <form ..> element and out of the control of formlets..
16:57 < aavogt> yeah, that was confusing
16:57 < stepcut`> there is a whole other issue too with file uploads. Namely, how do support large file uploads (this is a problem in happstack, even with out formlets)
16:58 < aavogt> there's a space leak
16:58 < stepcut`> you don't really want to accidently force the whole file into memory
16:58 < stepcut`> but right now that is probably what will happen
16:58 < aavogt> I have a basic case that does it
16:58 < mightybyte> Yeah.  I haven't needed file uploads yet, so I haven't looked into it.
16:58 < stepcut`> that is something I hope someone can deal with for happstack 0.5
16:59 < aavogt> http://hpaste.org/fastcgi/hpaste.fcgi/view?id=13896#a13896
16:59 < mightybyte> Maybe I should just bite the bullet and allow users to upload avatar pictures to my website. :)
16:59 < stepcut`> :)
16:59 < aavogt> I think the problem is in the parsing of the multipart
16:59 < stepcut`> aavogt: yes
17:00 < aavogt> I did some profiling, but nothing jumped out as being wrong
17:00 < mightybyte> stepcut`: Is removing the m all you did in your formlet fork?
17:01 < stepcut`> mightybyte: no, there are some other changes. Though I think the new formlets has made some similar changes
17:01 < stepcut`> mightybyte: for example, dealing with controls that don't get submitted when they are not used
17:01 < stepcut`> mightybyte: also, support for multiple selections in a select box
17:01 < mightybyte> Yeah, I have encountered that.
17:02 < mightybyte> The former, not the latter.
17:02 < mightybyte> But you forked from an older version of formlets?
17:02 < stepcut`> for checkboxes, there are some tricks you can use with the existing input' stuff, but for multiselect you really need new core library support
17:02 < stepcut`> yes, 0.4.8 I think
17:03 < stepcut`> We are in the process of updating to 0.6 though
17:03 < mightybyte> That's good.  0.6 is substantially better.
17:03 < stepcut`> :)
17:03 < mightybyte> A result of our efforts at hac-phi.
17:03 < stepcut`> aside from massInput, what else is improved?
17:04 < mightybyte> massInput was the main thing, but I think that drove some improvements to the core.
17:04 < stepcut`> nice
17:05 < mightybyte> Don't remember all the details off the top of my head.
17:06 < stepcut`> mightybyte: so, I think that setting the 'X.identifier' in Text.XHtml is not beneficial
17:06 < stepcut`> actually, that may be cleaned up now...
17:06 < stepcut`> looks like only radio does it
17:07 < mightybyte> Is that not needed for radio buttons?
17:08 < aavogt> stepcut`: some profiling naming the bad functions that do all the allocation: http://omploader.org/vMmV1Nw
17:08 < stepcut`> it's not needed for any inputs. Though for the radio buttons it is used to associate the <label> with the <radio> which makes sense
17:08 < aavogt> I dunno if this helps
17:09 < stepcut`> aavogt: what is the problem?
17:09 < aavogt> file uploads using happstack are not sufficiently lazy
17:09 < aavogt> so you need as much ram as the size of the file
17:10 < stepcut`> aavogt: right. Because the RqData stuff looks up all the values in the multipart form data, which means it has to receive the whole thing first
17:10 < aavogt> I don't know if it has do such
17:11 < stepcut`> aavogt: the way RqData works, it does. There needs to be some other way of dealing with file uploads I think
17:12 < aavogt> hmm, then shouldn't it return strict bytestrings?
17:12 < aavogt> couldn't RqData be fixed?
17:12 < stepcut`> aavogt: How would RqData be fixed?
17:13 < aavogt> by being more lazy
17:13 < stepcut`> but the whole point of RqData is to do a lookup of a key/value pair. When you look up a key, you might have to examine all the keys if it is the last one.
17:14 < stepcut`> But to examine all the keys, you first have to have received them all
17:16 < mightybyte> stepcut`: Would it be better for me to remove m from the current formlets, or just let you submit a patch with it?
17:32 < stepcut`> I'll just submit a patch
17:32 < mightybyte> Ok
17:33 < mightybyte> Or you could fork the repo on git hub, make your changes, and submit a pull request
17:33 < mightybyte> Whatever is easier
17:42 < stepcut`> mightybyte: yeah that is what I am planning to do
17:48 < mightybyte> stepcut`: FYI, I decided to take a look at it and just committed a new branch called remove-xml-monad with the monad removed.
17:48 < mightybyte> It was a pretty straightforward change to just one file.
17:48 < stepcut`> sweet
17:48 < stepcut`> I'll start there then
--- Log closed Thu Dec 10 00:00:47 2009