--- Log opened Fri Jul 31 00:00:47 2009
12:07 < sm> hi Oejet
12:07 < sm> did you find out about formlet changes ?
12:14 < Oejet> sm: No.
12:14  * sm pings mightybyte
12:15 < sm> http://hackage.haskell.org/package/formlets is a little short on docs & repo link
13:36 < sm> should I bother with hsp/hsx ?
13:53 < Oejet> sm: Do you have a preferable way of generating HTML (templates, combinators, printf, html-syntax-in-Haskell)?
13:54 < Oejet> sm: Maybe it is just a matter of taste.
13:54 < sm> Oejet: I'm not sure, but I lean towards combinators
13:54 < sm> I have the impression hsp/hsx (what is the difference ?) bring problems and aren't actively maintained
15:31 < stepcut> sm: hsp/hsx are actively maintained
15:31 < stepcut> sm: I use hsp/hsx with formlets as well..
15:32 < sm> stepcut: good to know. You don't find writing xhtml too low-level compared to combinators ?
15:32 < stepcut> sm: Niklas Broberg is the hsp/hsx author, and is working on a GSoC project which is focused on improving haskell-src-exts, with is used by HSX/HSP.
15:32 < sm> ah
15:33 < stepcut> sm: I find that html+css is so figdetty that writing low-level is the only way to do things :(
15:33 < sm> I see what you mean
15:34 < stepcut> sm: though, HSP does not prohibit you from using higher-level combinators...
15:34 < sm> ah
15:34 < stepcut> sm: it just provides a literal XML syntax extension to Haskell. You could write things in a higher-level literal XML that gets transformed into the low-level html...
15:34 < sm> great, given all this I will try it again
15:35 < stepcut> sm: additionally, you can write functions that parameterize the XML...
15:35 < stepcut> sm: so, it's like a XML templating system with the full power of Haskell
15:36 < stepcut> sm: the biggest annoyance is that parse errors aren't as informative as normal Haskell parse errors
15:36 < sm> right. Also I wonder if it's cross-platform (eg windows)
15:37 < stepcut> sm: there should not be any cross-platform issues.. we use it in the demo app in happstack, and I believe that has been tested on windows
15:37 < stepcut> sm: the only system specific thing would be running the trhsx preprocessor
15:37 < sm> thanks for the info
15:37 < sm> I also got a little formlets demo working, can I ask what's changed in the recent release ?
15:38 < stepcut> sm: also HSP can be a bit mysterious if you don't know about associated types
15:38 < stepcut> sm: dunno... I used a mildly forked version of formlets.
15:38 < stepcut> sm: The normal formlets library requires the XML generation monad, and the validator monad to be the same monad -- which is bogus IMO
15:39 < stepcut> sm: and I have a library that adds HSP combinators for formlets
15:39 < sm> cool. In fact I think I'll back off formlets until I get comfortable with straight html & hsp
15:40 < stepcut> sm: plus some extra instances of things like ServerMonad and FilterMonad so that you can make formlets and the code that handles the form submission/processing transparently embeddable in a larger HSP doc
15:41 < stepcut> sm: feel free to ask me questions if you are around. Once I get caught up on things, I want to write a blog post describing how I use HSP+formlets, because it's a pretty neat system, but requires some additional library support, etc.
15:41 < sm> excellent
15:42 < stepcut> sm: I would start by looking at the example in happstack/happstack/template/project to get the basics of using HSP
15:42 < stepcut> sm: it will should what magic lines you need to put at the top of your files to automatically run the preprocessor, etc.
15:43 < stepcut> sm: IMO html sucks. So, no library can make it not suck :)
15:43 < Oejet> stepcut: What kind of editor support do you have for combined Haskell and XML code?
15:43  * sm does that
15:44 < stepcut> Oejet: I just use emacs and the haskell-mode. It would be nice if haskell-mode understood the XML syntax, but it doesn't. I think there is some way to use mixed-mode support in emacs to switch between haskell-mode and nxml mode, but I don't know how. It hasn't bothered me enough to do anything about it.
15:45 < Oejet> stepcut: Will you release some code with said blog post? Maybe even release some code earlier for us to review/test? :D
15:46 < stepcut> Oejet: yes. I hope to get most of the code moved into happstack proper. It is all publicly accessible already. Also, I wrote a simple blog engine that uses it, which I may use to make the post ;)
15:46 < Oejet> Oh, where is it?
15:48 < stepcut> Oejet: the blog engine is here, http://src.seereason.com/happstack-blog/, the rest of the code is here, http://src.seereason.com/, however, some of the libraries exist in multiple locations due to forks for different versions of the compiler.
15:48 < stepcut> Oejet: and some of the libraries have patches applied against them via quilt-targets etc
15:49 < stepcut> Oejet: this file is the authority of which versions we are actually using and what patches are applied: http://src.seereason.com/autobuilder-config/Targets.hs
15:50 < stepcut> Oejet: or you can install all the debs directory from: http://deb.seereason.com/. Currently supported dists are, sid, hardy, and jaunty
15:50 < stepcut> Oejet: if you don't want to install experimental debs on your real system, you can used build-env to create a clean chroot, and install the debs in there to play with them...
15:52 < Oejet> stepcut: Thank you! I will take a look at the code.
15:53 < stepcut> Oejet: in http://src.seereason.com/happstack-blog/Happstack/Blog/Control.hs, the function, blogPost, transforms a formlet into a ServerPartT thing that can be embedded inside literal XML syntax
15:53 < stepcut> Oejet: that code needs some serious cleanup at the moment though.
15:54 < stepcut> Oejet: for example, I don't actually embed the blogPost inside a page, but instead just return the XML -- which is bogus, since it does not include the html, header, or body tags :)
15:54 < stepcut> Oejet: that package contains a blog library, and the demo directory contains an application which uses the library
15:55 < stepcut> Oejet: the code is further complicated by the fact that it is themeable. But not just via CSS, you can provide Haskell code which actually generates the pages with the themes -- similar to how wordpress works.
15:57 < stepcut> Oejet: I've actually fixed a bunch of stuff in a private fork, but that forked depends on a number of closed source libs. So, I need to refork a version of that fork which does not have any closed source dependencies. That is the version I will blog about. It's most the same, but better :)
16:00 < stepcut> Oejet: that blog library also uses URLT. The essence of URLT is described in this series, http://src.seereason.com/~jeremy/SimpleSite1.html
16:06 < Oejet> stepcut: I'll read that too. :)
16:08 < stepcut> there is a lot of stuff package into that happstack-blog library... HSP, formlets, URLT, themeing, happstack, etc. And things like instances of URLT for ServerMonad and XMLGenerator, to make things more cleanly embeddable. So, if it seems confusing, don't be surprised ;)
16:08 < stepcut> Oejet: I think it's a pretty sensible system, but it's a lot to take on at once
16:09 < stepcut> ... without guidance
16:11 < Oejet> Yes, it is a lot.
16:12 < stepcut> Writing about it will be a good way to clean up the code and design :)
16:13 < sm> stepcut++
16:14 < sm> I wonder if such libs will mature to the point where haskell web dev. is as easy to pick up as say rails or django, or is it always going to require more know-how
16:15 < stepcut> sm: the libs are close... the documentation is what needs to mature the most
16:16 < stepcut> sm: though, it also depends if you know Haskell already or not... learning ruby or python is not hard if you already understand OOP. Haskell, not so much...
16:17 < sm> right
16:17 < stepcut> Though, I have done almost 100% functional programming for the last 6+ years. So OOP makes my brain explode when I try ;)
16:18 < sm> I have some gray area where I'm not sure if it's "knowing haskell" or "knowing the intricate details of this advanced library" .. we'll see
16:18 < stepcut> I try to use uninitialized variables and all sort of stuff that you never have to worry about in Haskell
16:18 < stepcut> SPJ keeps adding features to GHC faster than I can learn to use them :p
16:32 < jmcarthur_work> i think that's why i seem to have stopped really switching around between different languages to learn. i haven't finished learning haskell yet, and whenever i get close-ish, i'm wrong
16:32 < jmcarthur_work> there are always new features
16:32 < jmcarthur_work> and new ideas
16:33 < stepcut> jmcarthur_work: yep :)
16:33 < stepcut> jmcarthur_work: Sometimes when I have time I play with Agda a bit, but for real work I use Haskell, and have plently left to learn
16:38 < jmcarthur_work> yeah, same here
16:38 < jmcarthur_work> a little agda and coq on the size, but nothing practical
16:38 < jmcarthur_work> *on the side
16:41 < sm> my first hsp function is complaining: Overlapping instances for EmbedAsChild m [Char]
16:41 < sm> I'm using LANGUAGE FlexibleContexts, FlexibleInstances, MultiParamTypeClasses as in the happstack project template
16:42 < stepcut> sm: yeah, you probably need a type signature, or a more specific one
16:42 < sm> aha
16:42 < stepcut> sm: perhaps just, (XMLGenerator m) => XMLGenT m (HSX.XML m)
16:42 < stepcut> sm: or, (XMLGenerator, EmbedAsChild m String) => XMLGenT m (HSX.XML m)
16:43 < stepcut> sm: if you hpaste the function I can tell you more exactly
16:43 < sm> stepcut: http://gist.github.com/159440
16:44 < sm> my plan was to turn this into a string with renderAsHTML $ evalHSP Nothing $ ...
16:44 < stepcut> sm: try, hpstest' :: HSP XML
16:44 < sm> but first, compilation
16:44 < sm> perfect :)
16:45 < stepcut> evalHSP is in the IO monad I think, so perhaps, renderAsHTML <$> (evalHSP Nothing $ ...)
16:45 < sm> very nice, thanks
16:45 < stepcut> import qualified HSX.XMLGenerator as HSX; hsptest' :: (XMLGenerator m) => XMLGenT m (HSX.XML m), would probably work as well and be more general.
16:46 < stepcut> sm: In my local libs, I have created an instance of XMLGenerator for ServerPartT so that I can do things like:
16:47 < stepcut> <div><% dir "foo" $ ok (toResponse "foo") </div>
16:47 < stepcut> in which case, that <div /> tag will only appear in the ouput if the "foo" guard inside matches...
16:47 < stepcut> fun stuff ;)
16:48 < stepcut> that 'toResponse' might be bogus. But, something to that effect.
16:53 < sm> good stuff, noted
16:54 < sm> I am actually using loli on top of happstack.. just got it to render
16:54 < sm> woot!
16:54 < stepcut> sweet!
16:54 < sm> this is going to be easier than combinators.
16:54 < stepcut> sm: :p
16:55 < stepcut> sm: the type error messages and syntax errors can be annoying, but I like it otherwise
16:55 < stepcut> sm: especially once you start making ServerPartT instances of XMLGenerator
18:03 < sm> stepcut: is it possible to use trace within a HSP function ?
18:05 < stepcut> sm: sure...
18:05 < stepcut> <% trace "foo" %> ?
18:05 < stepcut> well, trace takes a second argument
18:05 < sm> hmm ok
18:05 < stepcut> <% trace "foo" () %>  or something
18:05 < stepcut> not sure what you are trying to trace...
18:05 < sm> I made another HSP wrapper fn which is a do expression (no angle brackets)
18:06 < sm> actually trace was working there.. sorry. Some place it didn't seem to work but I forget where
18:06 < sm> I'm having trouble using the value returned by getParam "var" within a HSP function
18:06 < stepcut> there is no particular reason why trace should not work, unless it was in a thunk that was never needed
18:06 < sm> ok
18:07 < stepcut> what sort of trouble?
18:08 < sm> getParam returns the value in the HSP monad, and I need to extract from that so I can use the value to fill a form field
18:09 < sm> I thought <input name="var" value=(fromMaybe "" $ return $ getParameter amt) /> might work
18:09 < sm> s/getParameter/getParam/
18:10 < sm> probably time for a break
18:12 < stepcut> you are trying to apply fromMaybe ::a -> Maybe a -> a, to a, HSP (Maybe String), value
18:13 < stepcut> sm: fromMaybe "" <$> getParam amt
18:13 < stepcut> sm: fmap (fromMaybe "") (getParam amt)
18:14 < stepcut> sm: return . fromMaybe "" =<< getParam amt
18:14 < sm> I think I see.. I shouldn't try to extract it out of HSP, rather lift the fromMaybe into HSP
18:16 < stepcut> sm: yeah, it's just normal monad stuff here. Just replace HSP with IO, and take it out of the context of the literal XML syntax, and you will see it as a familiar problem
18:16 < stepcut> you could do it this way as well:
18:16 < stepcut> test2 amt =
18:16 < stepcut>     do v <- getParam amt
18:16 < stepcut>        <input name="var" value=(fromMaybe "" v) />
18:16 < stepcut>  
18:17 < sm> ah, I have so far failed to mix do and < > in a function..
18:17 < sm> trhsx complains  Parse error: SemiColon
18:18 < stepcut> sm: also you should do, trhsx Foo.hs, to see what trhsx actually does to your source, just as a simple learning experiment
18:18 < sm> I think I'll look at that code you posted for more examples
18:18 < stepcut> sm: takes some of the mystery out of what is going on in the big picture
18:18 < sm> oh good idea
18:18 < stepcut> sm: one issue with mixing do and < > in a function is the layout rules for do
18:19 < stepcut> this will fail:
18:19 < stepcut> test2 amt =
18:19 < stepcut>     do v <- getParam amt
18:19 < stepcut>        <div>
18:19 < stepcut>         <input name="var" value=(fromMaybe "" v) />
18:19 < stepcut>        </div>
18:19 < stepcut>  
18:19 < stepcut> because the </div> is at the same indentation as the <div>
18:19 < stepcut> test2 amt =
18:19 < stepcut>     do v <- getParam amt
18:19 < stepcut>        <div>
18:19 < stepcut>         <input name="var" value=(fromMaybe "" v) />
18:19 < stepcut>         </div>
18:19 < stepcut>  
18:19 < sm> aHA, thank you
18:20 < stepcut> that will work. It is the same exactly issue as if .. then .. else inside do blocks
18:20 < stepcut> it's a bit annoying, but it is a 'defect' of the do block syntax rules that HSP is following
18:21 < stepcut> it's annoying with if .. then .. else as well ;)
18:24 < sm> hmm.. and getParam should show me the value of a query string parameter, is that right ?
18:25 < stepcut> no idea
18:25 < stepcut> I have never used getParam
18:25  * stepcut looks it up
18:25 < sm> yes, it seems so
18:26 < sm> http://hackage.haskell.org/packages/archive/hsp/0.4.5/doc/html/HSP.html
18:27 < sm> hmm.. perhaps loli is interfering
18:29 < stepcut> no..
18:29 < stepcut> one moment
18:30 < sm> or I need to hook up HSP.Request to a concrete request type somehow
18:30 < stepcut> yeah. evalHSP and friends supply an empty environment.
18:31 < stepcut> there is some HSP CGI interface that actually fills that in I think. Or at least there used to be.
18:31 < sm> ahh, I should use runHSP
18:32 < stepcut> yeah
18:32 < stepcut> I just use the normal happstack stuff for dealing with the environment
18:32 < stepcut> though, I don't actually use the HSP monad anyway, so ..
18:33 < stepcut> but, if you want to use getParam (which is not a bad thing), then, yes, you need to use runHSP and create a valid HSPENv
19:09 < sm> got it
19:10 < sm> phew
19:10 < stepcut> sweet!
19:18  * sm 's loli/happstack/hsp form : http://gist.github.com/159504
19:20 < stepcut> sm: next you should run the output through validate and make sure it is valid html ;)
19:21 < stepcut> cool stuff though
19:43 < sm> hmm
19:44 < sm> does anyone know which package provides Happstack.Server.HSP ? it's not http://hackage.haskell.org/package/happstack-server
19:44 < dons> Lemmih: what did you realize?
19:44  * dons isn't sure he understands whether Binary is working or not for this
19:44 < stepcut> happstack-extra
19:45 < sm> thanks
19:45 < stepcut> dons: my test case was definetaly bogus. The control allowed garbage collection that it wasn't supposed to...
19:46 < dons> so the length encoding isn't hurting too much, then?
19:46 < stepcut> dons: after I fixed it, my control case used 40MB (with no serialization happening), and restoring the state from disk required 50MB. So, that seems acceptable
19:46 < dons> ok. restoring shouldn't hurt
19:46 < dons> it is serialising that requires a 'length' to be called
19:46 < stepcut> in happstack that should not be a problem
19:46 < dons> right, since it is all in memory anyway , evaluated?
19:46 < sm> happstack-extra seems to be incorporated in happstack 0.4 now, at least the HSP stuff
19:47 < stepcut> sm: oops, that's what I meant. the happstack cabal package.
19:47 < stepcut> dons: yeah, happstack state is generally fully evaluated. If you do periodic checkpoints that will force it anyway...
19:48 < dons> right
19:48 < dons> ok. so we're good then
19:48 < stepcut> dons: I am trying to figure out if a 11MB checkpoint file requiring 500-800MB once loaded is a bug or not
19:48 < dons> ok.
19:49 < stepcut> dons: its sees like a big delta, but the data structures largely consist of Strings, which are stored very efficiently via Binary, so... it could be legit
19:49 < dons> is the checkpoint file compressed?
19:49 < stepcut> no
19:49 < stepcut> but, Strings are converted to ByteStrings, which is a form of compression :)
19:49 < dons> ah
19:50 < dons> yes, that could be it. they're, what, 16x smaller?
19:50 < dons> you should keep them as Data.Text strings perhaps
19:50 < stepcut> perhaps
19:50 < dons> converting between string and bytestring is not great
19:50 < stepcut> is Data.Text available now ?
19:50 < dons> yeah. its on hackage for the last few months.
19:51 < dons> http://hackage.haskell.org/package/text
19:51 < stepcut> cool. My intention was to try it when it was ready. Didn't realize it was already here :)
19:51 < dons> utf8-string, of course, also supports some bytestring ops
19:52 < stepcut> yeah, but I think that is a really bad practice
19:52 < stepcut> too easy to screw up encodings and stuff
19:52 < dons> yes, maybe
19:53 < stepcut> or use Data.ByteString.length when you really want the number of characters
19:53 < stepcut> Data.Text seems much safer, with the space advantages of ByteString
19:54 < stepcut> anyway, thanks for your help! I will continue to investigate the rest of the layers and make sure they all seem sane in memory usage.
19:55 < stepcut> and, start using Data.Text where possible
19:56 < stepcut> how efficient is it to convert a utf-8 encoded bytestring to Text ?
19:56 < stepcut> ah, I used Data.Text.Encoding.decodeUtf8
19:57 < stepcut> but now it is dinner time
19:59 < dons> yeah, stay in the text library
19:59 < dons> bos can help
20:02 < stepcut> coming in and out of happstack, the data is a ByteString, because that is what the network library uses
20:03 < stepcut> and some libraries, like pandoc, don't have Data.Text support (yet). So some conversion will still be needed.
20:09 < dons> mm
22:20 < Lemmih> dons: Still here?
--- Log closed Sat Aug 01 00:00:50 2009