--- Log opened Sun Jan 25 00:00:02 2009
02:42 < sm> night all
02:47 < mae> night
03:05 < T-Cell> How do I compile an HAppS module into type executable?
03:06 < T-Cell> ..anyone?
12:00 < rovar> wow, decent group of people in here
12:17 < wchogg> mae: hey, can you add 'creighton' to the happs account & take out wchogg?  I made a second account that had no trouble activating.
12:51 < stepcut> patch-tag.com should either state that you need to upload square profile pictures, or it should maintain the aspect ration when scaling...
12:58 < Saizan_> i wonder where is the bugtracker
13:54 < mae> wchogg: been there, done that. :)
13:55 < wchogg> mae : and thanks for that
13:55 < mae> patch tag bug tracker is: http://groups.google.com/group/patch-tag-users
13:55 < mae> : )
13:59 < wchogg> So should there be a .cabal for HAppS-DNS & HAppS-SMTP?  Are they meant to get distributed in packages?
14:01 < mae> ah there is no cabal for them? heh
14:01 < mae> maybe they are a work in progress
14:01 < Saizan_> at the time alexj wasn't very fond of cabal, preferring his searchpath
14:01 < mae> ah
14:02 < mae> well if we intend to keep them separate then yeah, they should have their own cabal packages
14:02 < wchogg> A'ight.
14:02 < mae> yeah lets do that for now
14:02 < mae> we don't want to make too many changes leading up to 0.2
14:02 < mae> we want to cleanup what is there
14:03 < wchogg> Right.
14:03 < mae> but most likely I will remove HAppS-Plugins unless someone can give me a good reason not to
14:03 < Saizan_> so HAppS-Contrib is for later?
14:03 < mae> Saizan_: um well, good question! there are things like facebook
14:03 < mae> which really should be taken care of asap
14:04 < wchogg> I just pushed the HAppS-Contrib with the facebook modules in it.
14:04 < wchogg> It has its own .cabal as well.
14:04 < wchogg> Nothing else is in it, though.
14:04 < mae> ok, well is it gone from happs server?
14:04 < wchogg> Right
14:04 < mae> ok good
14:05 < mae> yeah lets do contrib
14:05 < mae> but lets be very conservative on how much dicing up we do at this point
14:05 < mae> focus on existing bugs and cleanup
14:05 < wchogg> At the moment I'm seeing if I can figure out why HAppS-DNS doesn't even compile.
14:05 < mae> can anyone think of any other candidates for happs-contrib right now?
14:05 < mae> ahh :)
14:06 < chessguy> hi guys
14:06 < wchogg> Hello
14:07 < mae> oh by the way
14:07 < mae> one other nuance
14:08 < mae> we have a couple choices here
14:08 < mae> bump the HAppS-* package version #'s t something higher than they are now
14:08 < mae> this is kind of messy
14:08 < mae> what I propose is a different option
14:08 < mae> relabel the package names
14:08 < mae> HAppS-Server becomes happstack-server
14:09 < mae> etc etc.
14:09 < wchogg> seconded!
14:09 < mae> but the module names stay the same
14:09 < Saizan_> i think that's a bad move
14:09 < mae> Saizan_: go on
14:09 < wchogg> Really?  It seems like a good move in order to distinguish from the original HAppS stream
14:09 < Saizan_> it's not like we're competing with HAppS
14:10 < Saizan_> we're inheriting, and users can assume that they can continue to work with the new releases
14:10 < wchogg> Eh.  I see your point.  I guess I just wanted to leave the door for the original HAppS open in case Alex came back to it some day & wanted to continue his own path.
14:10 < mae> Saizan_: so what do you propose that we do to address the version conflict? should we just label it 1.1 1.2 (to replace 0.1 0.2 in the roadmap)
14:12 < Saizan_> that way we're still "stealing" the version 1 from alex :)
14:12 < mae> Saizan_: its not stealing, he told me on the phone he wanted someone else to take over :)
14:12 < mae> Saizan_: i'm just trying to think of something reasonable here
14:13 < mae> i mean if we do the cabal package relable
14:13 < mae> relabel *
14:13 < mae> but the module names stay the same
14:13 < mae> someone could merely change the package they are compiling with
14:13 < Saizan_> that's true
14:13 < mae> i.e. drop in happstack-server for HAppS-Server
14:13 < mae> and we don't steal version 1.x
14:14 < mae> and also, since i intended 0.1 to be the "unstable rc" release, 1.1 is kind of misleading :)
14:15 < mae> so lets assume for a minute that we decide to relabel just the cabal package names
14:15 < mae> we release 0.1 after a bit
14:15 < mae> people test it with their happs projects
14:16 < mae> and we get a chance to iron out any issues that cropped up for 0.2
14:16 < mae> and voila, 0.2 can be the golden boy for awhile while we shuffle around
14:16 < mae> Saizan_: what say you? :)
14:17 < Saizan_> if we get people to switch then it sounds like a plan :)
14:17 < mae> well its basically switch or die
14:17 < mae> its like the argument for using the 2.6 kernel over the 2.4 one
14:17 < mae> (linux)
14:18 < mae> 2.4 isn't really maintained anymore
14:18 < stepcut> you could use, 0.10.x
14:18 < mae> thats true
14:18 < stepcut> and then when it gets up to, like 0.18, we can just drop the 0. and call it happs, 18
14:18 < mae> but something always bugged me about that because it is less in the decimal system than 0.9 :)
14:18 < stepcut> (which is what happened to emacs)
14:19 < mae> heh
14:19 < stepcut> :p
14:19 < stepcut> dpkg --compare-versions 0.10 gt  0.9 && echo "true"
14:19 < stepcut> that all that matters to me :)
14:20 < Saizan_> i imagined something like that :)
14:20 < mae> The other really compelling argument for relabeling to new cabal packages
14:20 < mae> is that I absolutely loath the alternating caps
14:21 < Saizan_> heh, fsvo really compelling
14:22 < Saizan_> abd you'd still have it in module names
14:22 < stepcut> mae: :p
14:22 < mae> Saizan_: yeah but its a start
14:22 < mae> he he
14:23 < stepcut> but the trade off is that it is longer
14:23 < stepcut> though, arguably the same number of keystrokes if you consider 'shift' to be keystroke?
14:24 < wchogg> To be honest, I'd count hitting shift as a two keystroke penalty for how much it slows me down.
14:24 < stepcut> :p
14:25 < koeien> yeah, "Happstack" >> "HAppS" imo
14:25 < wchogg> I'm only half kidding here.  HAppS takes me longer to type than happstack
14:26 < stepcut> I think it should be happStack since the 'S' gets used to mean two different things
14:26 < stepcut> happstack takes twice as long to say as happs though
14:28 < mae> lol
14:28 < mae> Happstack is like saying "flapjack" or "pattywhack" give a dog a bone
14:29 < wchogg> Okay, now I'm craving pancakes.
14:29 < Saizan_> this is like the lexical syntax of comments, we could go on for ages :)
14:29 < stepcut> is that the new slogan? "Nicknack, happstack give the dog a bone"
14:29 < mae> ok so I want to move forward with cabal package relabeling to the all-lowercase happstack paradigm, no module names will be changed.
14:30 < mae> I'm making a ticket right now
14:30 < wchogg> Okay.  I'm messing around with .cabal's anyway right now.
14:30 < mae> ok can i put you as the owner wchogg then?
14:30 < wchogg> Yup
14:30 < mae> i'm setting as a 0.1 milestone
14:30 < mae> ok
14:31 < wchogg> I made one for HAppS-DNS.  I'm working on getting SMTP compiling
14:31 < Saizan_> btw, currently some LANGUAGE extensions are in the .cabal files and not in modules' pragmas
14:32 < Saizan_> so you can't load those files directly in ghci without looking at the .cabal
14:32 < stepcut> Saizan_: I would like to see them added an a per module basis, though I always regret a bit that the .cabal file does not know what extensions are needed then
14:32 < mae> http://code.google.com/p/happstack/issues/detail?id=17
14:32 < dcoutts> stepcut: do both
14:33 < mae> ok so who is volunteering for this task
14:33 < stepcut> dcoutts: in theory, yes, in practice, it would have to be automated
14:33 < mae> perfect for a 0.1 milestone
14:33 < dcoutts> stepcut: eventually it'll be enforced that they're specified in the .cabal file
14:33 < dcoutts> and we'd like to move to where they're listed but not applied to every module
14:33 < stepcut> dcoutts: I would like to request something that walks the tree and makes the list automatically
14:33 < wchogg> dcoutts: but if you're having to put it in both places, isn't that a bit of duplication?
14:34 < mae> wchogg: yeah i would agree with this
14:34 < dcoutts> wchogg: no because you do not use every extension in every module
14:34 < mae> what problems will be caused if we omit the extensions from the cabal file
14:34 < dcoutts> stepcut: yes, it'd have to inform you that you were using an extension without listing it in the .cabal file
14:34 < mae> keep in mind this is 0.1, we can always change it later
14:34 < dcoutts> mae: bad QA ratings on hackage :-)
14:34 < mae> heh
14:35 < dcoutts> mae: if the extensions are CPP or TemplageHaskell however bad things will happen
14:35 < mae> allright, well then lets put it in both places as dcoutts suggests
14:35 < dcoutts> because Cabal will then not know that you're using them and then cannot help you
14:35 < wchogg> mae : so we're keeping the '-'s in the package names, yes?  HAppS-Server -> happstack-server
14:35 < mae> its stupid but whatever :)
14:35 < mae> wchogg: yes
14:35 < dcoutts> eg profiling will not work when Cabal does not know you#re using TemplateHaskell
14:35 < wchogg> mae : cool, thanks
14:35 < stepcut> dcoutts: in the olden days License-file: could refer to a file in a subdirectory, e.g., debian/changelog, but this does not work anymore, because something tries to copy the whole directory path instead of just he basename.
14:35 < mae> dcoutts: ooh fun.
14:36 < wchogg> dcoutts : ouch.  Alright, I guess we should fix it.
14:36 < dcoutts> stepcut: I'm not sure I follow, where is the license file exactly?
14:37 < dcoutts> stepcut: you mean the license file is ./foo/bar  and it tries to install it to $docdir/foo/bar ?
14:38 < stepcut> dcoutts: opps, typo. In the .cabal file I used to put, License-file: debian/copyright, but I had to stop doing that because of what you just said regarding /foo/bar
14:38 < dcoutts> stepcut: it should work with current versions
14:38 < stepcut> I should look up the exact details, but something went funny at some point in time
14:38  * stepcut checks
14:38 < dcoutts> it should always install the file to $docdir/bar  not  $docdir/foo/bar
14:38 < mae> what do you guys think about this issue, is this important for 0.1?
14:38 < mae> http://code.google.com/p/happstack/issues/detail?id=11
14:39 < stepcut> dcoutts: that sounds like what I want, but I think it was doing the latter for a while
14:39 < dcoutts> stepcut: yes, I recall fixing it
14:39 < stepcut> dcoutts: sweet!
14:39 < dcoutts> copyFileVerbose verbosity lfile (docPref </> takeFileName lfile)
14:39 < dcoutts> looks right to me
14:39 < stepcut> dcoutts: cool, I am testing
14:40 < Saizan_> mae: we should ask if someone uses HAppS.Data.Xml
14:40 < stepcut> Saizan_: I have considered using to occasionally export my data store, just-in-case
14:41 < stepcut> Saizan_: i did use it when I use xslt
14:43 < mae> ok well xslt is still part of the "happs legacy" umbrella, we aren't trying to turn things upside down yet
14:43 < mae> so i'm gonna say 0.1 milestone
14:44 < stepcut> I think the xslt stuff is useful -- it's just not for me :)
14:44 < mae> yep
14:44 < stepcut> don't you mean. 0.10  ;)
14:45 < mae> how difficult is this? (http://code.google.com/p/happstack/issues/detail?id=14 Rid HAppS-Server of dependency on HAppS-State)
14:45 < mae> is this requiring a lot of change or minimal
14:45 < stepcut> the only sillier than 0.10 > 0.9 is 0.1 > 0.9 :p
14:45  * stepcut looks
14:45 < mae> i don't remember who suggested this
14:46 < Saizan_> mae: removing "import HAppS.State.Control" from HAppS.Server
14:46 < Saizan_> that's the only change needed
14:46 < mae> so it doesn't really need it?
14:47 < Saizan_> oh, and webQuery/webUpdate off course
14:47 < Saizan_> no, it's not used in any substantial way
14:47 < mae> Saizan_: so is this a potentially unsettling/destabilizing change, or is it acceptable as a "compatibility path" from happs legacy
14:47 < mae> does it belong in 0.1
14:48 < stepcut> mae: people might have to explicitly import HAppS.State.Control since it will not be re-exported by HAppS.Server
14:48 < mae> thats not the end of the world IMO
14:48 < stepcut> mae: so, not 100% compatible, though easy to deal with
14:48 < Saizan_> and define their own webQuery and webUpdate if they were using them
14:48 < mae> that can be fleshed out between 0.1-0.2 bug reports
14:48 < mae> (after 0.1 released)
14:49 < dcoutts> so at some point I guess I should convert the new hackage-server to use happstack
14:49 < stepcut> Saizan_: I use webQuery / webUpdate quite a bit...
14:49 < mae> oo
14:49 < mae> ok, this is sounding more spooky for 0.1
14:49 < stepcut> :-/
14:49 < stepcut> yeah...
14:49 < mae> lets shelve it till 0.3
14:49 < mae> not in goals for 0.1/0.2
14:50 < mae> 0.1/0.2 should be pretty easy releases
14:50 < stepcut> sounds good
14:52 < Saizan_> it raises the question of where we should put things like these
14:52 < mae> webQuery / webUpdate ?
14:52 < mae> to take a page out of rails book
14:52 < mae> they have the diff modules
14:52 < mae> and then one "integration module"
14:52 < mae> called rails
14:52 < mae> so similarily
14:53 < mae> we could have a cabal package
14:53 < mae> just plain 'happstack'
14:53 < mae> which assumes you are going to use the kitchen sink
14:53 < mae> (or people can import individual integration modules i.e. webUpdate webQuery
14:53 < mae> )
14:54 < mae> Happstack.Integration
14:54 < stepcut> so far I am not opposed to that idea
14:55 < mae> i think thats probably the way to go
14:55 < mae> and then we can take decoupling to the next level
14:55 < mae> so the libraries are truly independent
14:55 < mae> all the glue goes in Happstack.Integration
14:56 < wchogg> so that's more of a 0.3> goal?
14:56 < mae> well not official at this point
14:56 < stepcut> yeah
14:56 < mae> but yeah i'd say its 0.3ish
14:56 < wchogg> cool
14:56 < mae> that could be put in issues as an enhancement
14:57 < stepcut> we should figure out a plan for utf-8 and other character encodings and get that in the plan as well, because that is a major issue with the current HAppS IMO
14:57 < mae> stepcut: ok, that is issue 15
14:58 < stepcut> stepcut: yeah, the mailing list post it links to is mine
14:58 < mae> I mean, it couldn't hurt to have all responses be utf-8 encoded
14:58 < mae> since it is backwards compatible with ascii
14:58  * stepcut stops talking to himself
14:58 < Saizan_> so the server should look at the headers and use the right encoding?
14:58 < vegai> will happstack be on hackage soon?
14:58 < mae> stepcut: so do you have an idea of how this should be implemented?
14:58 < stepcut> mae: it would only break people who using latin1 characters that are not ascii
14:59 < gwern> we could call our package not 'rails' but 'piles' :)
14:59 < mae> vegai: hopefully in the next few weeks we will have a 0.1 out which will be mostly compatible with existing happs projects (module names will still be HAppS)
14:59 < mae> gwern: piles .. heh
14:59 < stepcut> Saizan_: the quickfix is to just use utf-8 pervasively, the more flexible fix is to allow the use and control of multiple encodings
14:59 < gwern> since multiple editions of happstack would be 'stacks', or 'piles'
14:59 < mae> gwern: or heaps (since ghc uses the heap when allocating memory :)
15:00 < gwern> (yes, but heaps doesn't include the disease connotations of 'piles')
15:00 < mae> haha
15:00 < mae> thats awesome
15:00 < mae> i don't know if i want that connatation : /
15:00 < stepcut> Saizan_: I suspect that supporting multiple encodings will break backwards compatibility, though maybe that could be solved by putting the affect functions in different modules
15:00 < mae> oops connotation
15:01 < gwern> well, to be strict a particular disease is one of the denotations of 'piles', not connotation
15:01 < Saizan_> also, we don't have good representation for non-encoded strings, unless we use [Char]
15:02 < stepcut> Saizan_: certainly all uses of [Char] should be as a list of unicode code points
15:02  * Saizan_ nods
15:02 < gwern> default unicode would simplify gitit a little - currently it has fromString/encodeString all over the place
15:02 < stepcut> Saizan_: but if you want a compact representation of unicode codepoints like, ByteUnicode, then we don't have that yet
15:03 < gwern> although I wonder if it mightn't break gzip encoding
15:03 < stepcut> gwern: I wouldn't expect it to. The encoding happens as part of the ToMessage class
15:05 < stepcut> my inclination is that the current implementation of HAppS (no support for unincode/utf-8) is not acceptable these days. reddit and friends would have a field day with that. Switching to only utf-8/unicode support in the short term is more social acceptable solution and does not require much architecting.
15:06 < stepcut> and is more likely to fix existing happs programs than break them, except perhaps gitit
15:06 < stepcut> since things in gitit would get doublely encoded/decoded
15:06 < gwern> oh the irony, being punished for being virtuous (by protecting unicode)
15:07 < Saizan_> i remember some gotchas with getting something like url-encoding of utf8 octects, but i guess there's a standard way to deal with that
15:07 < stepcut> Saizan_: I don't understand...
15:10 < wchogg> mae : I finished renaming the packages & changing the author & maintainer fields.  It was something stupid I could do before I needed to clean the house.
15:10 < Saizan_> i had to url-decode before utf8-decoding
15:10 < Saizan_> when dealing with data in POST queries
15:11  * stepcut ponders
15:13 < Saizan_> wchogg: i think you can't just erase the copyright like that, we can only extend it to report our contribution
15:14 < wchogg> I thought the copyright was on the name?
15:14 < stepcut> Saizan_: this works fine for us, lookPairsUnicode = asks fst >>= return . map (\ (n,vbs) -> (n, utf8ToUnicode (inputValue vbs)))
15:15 < stepcut> Saizan_: ah, but utf8ToUnicode seems to do a bunch of stuff
15:15 < stepcut> Saizan_: such as decoding entity references..
15:15 < Saizan_> the copyright is on the code too
15:16 < Saizan_> "Redistributions of source code must retain the above copyright
15:16 < Saizan_> notice, this list of conditions and the following disclaimer.
15:16 < Saizan_> from COPYING
15:16 < stepcut> mae: anyway, I might be the world expert on utf-8/unicode support in HAppS, so I can do that when the time is right...
15:17 < Saizan_> also, it seems just fair to give credit
15:17  * stepcut votes for leaving HAppS LLC in the .cabal file
15:18 < wchogg> Saizan : ah, well I can fix that later unless you want to now.
15:18 < wchogg> I apologize for the mistake
15:19 < stepcut> the name of the .cabal file and the name listed in the .cabal file need to match, or hackage gets unhappy
15:19 < stepcut> e.g., it needs to be happstack-server.cabal  not HAppS-Server.cabal
15:22 < wchogg> Ah, didn't realize that either.
15:22 < Saizan_> about -DNS, if we use Control.OldException we must depend on base-4, otherwise we've to use the CPP macros like in the other packages
15:23 < wchogg> Well, since we were targetting 6.10 I thought it'd be fine to depend on base-4
15:24 < wchogg> I'll fix the naming of the .cabal's quick.
15:26 < mae> wchogg: thanks man, much appreciated :)
15:27 < gwern> wchogg: the name is trademarked, not copyrighted iirc
15:27 < mae> regarding HAppS LLC, I wasn't suggesting removing this from anything but the Author field in cabal, the copyright remains intact
15:27 < gwern> puts haps llc in the author field, I say
15:27 < mae> in fact you actually run into issues where we are using his trademark for unauthorized modifications
15:27 < mae> if you want to look at both sides
15:27 < dcoutts> there's no problem listing multiple authors
15:28 < wchogg> mae : Right, that was my misunderstanding of how the copyright worked.
15:28 < mae> usually most opensource licenses say something along the lines of "don't use my name on derivative product"
15:29 < mae> so again, I don't see why the author field in cabal is a big deal, he is still in all the copyright notices
15:29 < mae> or rather happs llc is
15:30 < mae> wchogg: also it is not your fault, I told you in the mailing list to remove it, so really people should direct blame at me
15:38 < mae> wchogg, etc. al. I will add HAppS LLC to the authors list
15:38 < wchogg> Sure
15:39 < mae> so since we're diving into the legal nitty gritty
15:39 < mae> how does the copyright work on a bsd license
15:39 < mae> happs llc retains copyright, but others retain copyright to the modifications?
15:39 < mae> or how does that work
15:40 < koeien> ianal, but indeed
15:41 < T-Cell> hey can anyone out there answer a quick question about happs?
15:41 < dcoutts> T-Cell: ask your questions, don't ask if you can ask your question :-)
15:44 < gwern> mae: of course you retain copyright on your modifications
15:45 < stepcut> mae: that is basically how it works.
15:46 < stepcut> mae: GPL works that way as well. Though the FSF encourages people to assign the copyright to the FSF (which is a formal process)
15:46 < gwern> who would it be assigned to if not you? you have to sign copyright assignment forms to assign it to happs (which is why contributing code straight to GNU is such a pain)
15:47 < koeien> i think it's pointless to assign copyright (in the case of the BSD-licewnse)
15:47 < gwern> no, it's not pointless. it's perfectly sensible for GNU to do it. it's just that we don't need that sort of heavyduty protection
15:47 < gwern> no more than we need to formalize and write happs in Coq
15:47 < koeien> for GNU, since they use GPL for lots of stuff
15:48 < stepcut> gwern: hey now!
15:48 < stepcut> gwern: ok, maybe not Coq, how about agda ?
15:48 < gwern> -_-
15:49 < stepcut> ATS?
16:08 < T-Cell> I'm attempting to create an app that serves up some html (see the source code here http://haskell.nfshost.com/question.pdf). Problem is, when I call the function main it does not print anything. Why is this?
16:09 < mae> is there any type of modification to lambdabot to have it poll for new patches in a remote darcs repository and then paste them in chat ?
16:09 < mae> (the summary lines)
16:10 < mae> I just added two patches, one addresses the multiple authors, the second adds two scripts, one which does a build/install for all 5 cabalized packages, the other builds sdists of all the cabalized packages
16:10 < chessguy> mae:  there's nothing like that
16:11 < mae> man that sure would be neat.
16:11  * stepcut will be glad when libdarcs is ready for production
16:12 < stepcut> T-Cell: do you know about hpaste.org ?
16:12 < T-Cell> hpaste is broken last time I checked
16:12 < stepcut> ah
16:12 < T-Cell> yeah.. Service Temporarily Unavailable
16:14 < stepcut> odd that it is running apache...
16:17 < T-Cell> anyway.. does anyone know of a wiki page that explains how to render html using happs?
16:20 < stepcut> T-Cell: when I run your code, it renders the document as text/plain
16:20 < koeien> stepcut: maybe as proxy. that was how I set up my fastcgi, or how i would set up my HappS
16:21 < stepcut> T-Cell: you want to change, renderHtml to toResponse
16:21 < stepcut> T-Cell: there is a type class ToMessage which is used to turn different values into HAppS Responses
16:21 < stepcut> T-Cell: among other things, that sets the content-type for HTML to 'text/html'
16:22 < stepcut> T-Cell: by calling renderHtml manually, you were turning your HTML into a  String, and then it was serving the page as a text/plain, since it was a plain old String
16:23 < stepcut> T-Cell: not sure why you didn't get any output at all though. However, I would start by changing renderHtml to toResponse and see if that works for you
16:23 < stepcut> T-Cell: also, make sure you are pointing your browser at http://localhost:8000/ (or whatever machine the server is running on)
16:25 < stepcut> T-Cell: happstack.com has links to some tutorials
16:25 < mae> what is mightybyte's real name?
16:27 < mae> arg
16:30 < stepcut> koeien: I just have people connect directly to my HAppS servers, what is the advantage of getting apache involved?
16:30 < gwern> mae: there is no existing polling thing. the closest I can think of is darcswatch
16:31 < koeien> stepcut: if you serve other content
16:31 < stepcut> does darcs support server side commit hooks?
16:32 < stepcut> koeien: could you use that if you wanted to serveral HAppS servers for different domains on the same machine? (all on port 80)?
16:33 < koeien> yes.
16:33 < stepcut> and as a way to add ssl support ?
16:33 < koeien> although i did not do that with HAppS, but with FastCGI
16:33 < koeien> no idea about SSL
16:34 < koeien> i would think that apache does not add or remove SSL in that case
16:34 < koeien> but i'm not sure
16:35 < stepcut> HAppS + SSL and multiple HAppS servers for different domains on the same machine, are two issues I would love to know how to handle
16:35 < koeien> the last issue can be resolved by using apache as a proxy
16:35 < koeien> see, mod_proxy and the 'Proxy' and 'ProxyReverse' directives
16:36 < stepcut> using apache as a proxy, but with out FastCGI ?
16:36 < koeien> this is orthogonal to FastCGI. i used lighttpd with FastCGI
16:36 < stepcut> ok
16:37 < mae> new blog post: http://blog.happstack.com/2009/01/25/the-march-to-01-begins/
16:37 < koeien> you could easily replace the lighty server with any HAppS-application
16:38 < koeien> using virtual hosts you can then serve multiple domains with multiple (or the same) HAppS-application
16:39  * stepcut wonders what a Buz Czar does
16:39 < stepcut> hands out redbulls?
16:44 < mae> well
16:44 < mae> my expectation is that
16:44 < mae> once we release 0.1
16:44 < mae> we'll get a ton of bug reports
16:44 < mae> so the bug peeps can handle organizing it
16:46 < stepcut> well, I'd like to report a bug in the blog post
16:50 < mae> yes?
16:51 < mae> do tell
16:56 < stepcut> actually, two bugs
16:56 < stepcut> first it refers to the position as 'Buz Czar', second it refers to ghc 6.8.10
16:57 < mae> ok firstly, there is a mention of bug czar at the bottom
16:57 < mae> :)
16:57 < mae> thats what i morphed into
16:57 < mae> secondly, yeah i actually did think about but thought the difference didn't matter
16:57 < mae> now that i think about it though, i will add
16:57 < mae> thanks for the bug report
16:57 < stepcut> now I am more confused
16:58 < stepcut> there is ghc, there is a 6.8.x and a 6.10.1, but what is
16:58 < mae> oh buz czar
16:58 < mae> duh
16:58 < mae> hahahah
16:58 < mae> your right
16:59 < mae> ok it should be fixed now
17:00 < stepcut> looks the same to me (http://blog.happstack.com/2009/01/25/the-march-to-01-begins/)
17:01 < mae> refresh?
17:01 < stepcut> I tried, maybe I don't know the magic combination for safari
17:01 < stepcut> I'll try links
17:01 < mae> clear cache
17:01 < mae>  heh
17:03 < stepcut> it's better, but I still don't know what refers to
17:05 < wchogg> Pretty sure it's supposed to be 6.10.1
17:05 < mae> oh
17:05 < mae> sorry guys, today I guess I'm striking it rich in typos
17:06 < mae> ok this time it should be fixed :)
17:14 < stepcut> much better
17:14 < stepcut> I don't care about 6.10 vs 6.10.1, but 6.8.10 is just crazy talk!
17:15 < koeien> do you think it is realistic to maintain backwards-compatibility?
17:18 < mae> koeien: to some measure yes
17:19 < mae> koeien: for 0.2 the only difference in terms of functionality should be the switch in the cabal packages
17:19 < mae> the module names at that point will be the same
17:24 < mae> which isn't actually a change in functionality
17:24 < mae> it mean you just have to slightly change your build process
17:30 < koeien> okay. i don't think it is very important though; documentation and other stuff are far more important imho
17:31 < Saizan_> wchogg: as a side note, you don't need to put underscore in the patch name, it's not intended to be a filename :)
17:34 < mae> hehe
17:35 < mae> yeah that tripped me up with darcs the first time i used it too
17:35 < mae> koeien: complete haddock documentation + type signatures in the source is a 0.2 milestone
17:39 < stepcut> and, of course, it should work with haddock 2.x
17:39 < stepcut> there are some funny comments in happs that break haddock
17:40 < stepcut> mae: do you have any plans for happs-hsp-template?
17:47 < koeien> mae: cool
17:50 < doublec> hsp requires hs-plugins which doesn't work with 6.10 iirc
17:51 < Saizan> if we assume haddock 2.x we can remove those #ifdef _HADDOCK_
17:53 < stepcut> hsp does not require hs-plugins, but happs-hsp-template does
17:54 < stepcut> doublec: but I believe are correct that plugins do not work with 6.10. But maybe hint does?
17:55 < gwern> it does
17:56 < stepcut> the dependency tracking code in happs-hsp-template was busted anyway. I have it halfway rewritten (and a bit more general)
17:57 < stepcut> its a cool idea though -- especially as your link times get longer and longer
17:57 < stepcut> though it adds 28MB on the size of the executable
17:57 < gwern> oh it's not that bad
17:57 < stepcut> well, hsplugins was
17:57 < stepcut> not sure about hint + 6.10
17:58 < stepcut> it would be nice if you could use dynamic loading during development, but statically link the production version
17:58 < gwern> hint is more like 18megs unstripped
18:00 < stepcut> my personal VPS only has 128MB, so every MB counts :)
18:03 < Saizan> can someone try to build the haddock documentation for *-data ? it's the only one failing for me
18:04 < stepcut> Saizan: fails for me too
18:05 < stepcut> Saizan: with an internal error
18:08 < Saizan> haddock: internal Haddock or GHC error: Maybe.fromJust: Nothing <- how i love partial functions..
18:08 < stepcut> :)
18:12 < mae> stepcut: i don't but if you do I'd love to hear your ideas for 0.3 inclusion :)
18:12 < stepcut> mae: are you familiar with it at all?
18:13 < stepcut> mae: are you familiar with it at all?
18:13 < stepcut> oops
18:14 < mae> stepcut: I'm familiar with hsp, i'm familiar with the mailing list post, but I other than that I don't know where your coming from :)
18:14 < mae> if you have a good idea lets hear it !
18:14 < mae> better yet post the details on the mailing list so others can participate too.
18:15 < stepcut> mae: happs-hsp-template lets you put your HSP pages in separate files (like Index.hs), you can then edit those pages, and the running HAppS server automatically notices the changes, recompiles the page, and dynamically loads it into ram -- typically faster than you can switch to the browser and hit refresh
18:15 < stepcut> mae: compared to relinking your whole application everytime you make a minor tweak to the HTML trying to get your layout to look right
18:16 < mae> stepcut: that sounds good, does this straightjacket us into some uncomfortable paradigm as far as file-to-uri mappings go?
18:16 < mae> or can we represent a component as an hsp
18:16 < mae> for example
18:17 < mae> like a web part or server part
18:17 < mae> (disregard "component" as it is ambiguous)
18:18 < stepcut> there is no particalur file-to-uri mapping. instead of calling a function like, ok . toResponse =<< myPage, you do something like, ok . toResponse =<< evalPage "MyPage.hs"
18:18 < stepcut> I forget the exact syntax
18:18 < mae> ahh ok
18:18 < mae> what happens on failure
18:18 < stepcut> what kind of failure?
18:18 < mae> like
18:18 < mae> failure to compile
18:18 < mae> :)
18:19 < stepcut> it returns the compiler errors so you see them in the browser as text/plain
18:19 < stepcut> though that could be changed -- originally it didn't do that, but I think I modified my copy to
18:19 < mae> yikes
18:19 < mae> good for dev, bad for production updates :\
18:20 < mae> is there an option that lets you compile them into the executable?
18:20 < mae> like a cpp directive or something
18:20 < stepcut> mae: no -- that is the big missing feature, IMO
18:20 < mae> stepcut: I would support this 100% if it had a feature like that
18:20 < stepcut> happs-hsp-template is awesome for development, but a big liability for most production sites
18:20 < mae> i mean that is awesome for dev
18:21 < mae> yeah because there is always the runtime "what if it doesn't compile?" does the webserver have the right deps? etc etc
18:21 < stepcut> so, being able to use it during dev, but statically build/link everything for production would make it really killer
18:21 < mae> absolutely
18:21 < stepcut> I don't actually use happs-hsp-template because of that
18:21 < stepcut> but I am not sure that it is unsolvable
18:22 < mae> if we could have this by 0.6 i'd be happy
18:22 < stepcut> happs-hsp-template was a quick hack that lemmih and niklas did over a few days I think
18:22 < mae> as this is the whole "make it friendly to developers and end users" milestone
18:22 < mae> well rather 0.5 is leading up to 0.6
18:22 < stepcut> yeah, it's not high priority. But it could be really cool, so it would be nice to not forget about it
18:23 < mae> stepcut: if you can keep an eye on this and work on it in the back of your brain for now, this would be very very awesome
18:23 < stepcut> oh, one other thing
18:23 < Saizan> the MyPage.hs contains something like a module (with imports etc..) or just an expression?
18:24 < stepcut> mae: this is a 3 part series on the alternative to dir, method, page, etc, that I was talking about: http://src.seereason.com/~jeremy/SimpleSite1.html
18:24 < stepcut> (source: http://src.seereason.com/urlt/)
18:25 < stepcut> there are a bunch of little issues to be solved, but the big idea seems to work
18:26 < mae> relative links would also be neat, so that way you could easily do a scriptalias /foo on your apache site
18:26 < mae> without needing a subdomain
18:26 < stepcut> I'm not sure I understand
18:26 < mae> ehm
18:27 < mae> i just mean that the linking structure would use relative links
18:27 < mae> instead of absolute /
18:27 < stepcut> ah
18:27 < mae> if it could rather, then it would be very very portable
18:27 < mae> apache lets you do alot of neat things with mod alias
18:27 < mae> i'm pretty sure you can proxy paths too
18:27 < mae> it rewrites the urls to make it work
18:28 < mae> i.e.
18:28 < mae> incoming request to /foo/bar gets rewritten to /bar when it proxies it to the app server
18:29 < mae> but for this to work the html also must be relative-proof (because the links are getting clicked on and are passed to apache... apache will not also automatically fix the links in your html source)
18:29 < mae> so just saying, if the hsp handled all the interlinking as you say, it would be nice if the links were also output in relative format
18:29 < mae> so happstack can be highly embeddable
18:30 < mae> (into existing websites)
18:30 < mae> but yeah, thats just a rant
18:30 < mae> not that important for right now
18:30 < mae> if we can start with hsp's for dev and binaries for prod then this would be excellent
18:32 < mae> thanks for the discussion, I really hope you can make this a reality :)
18:32 < stepcut> HSP does not really have any special support for links... Just embedding literate XML into haskell source
18:34 < stepcut> anyway, I have to get back to cleaning house
18:38 < mae> heh
18:38 < mae> chores call :)
18:38 < mae> stepcut: let me know if you find a decent way to compile hsp into binary form
18:38 < mae> If the implementation is not too difficult we can do this in 0.3
18:40 < stepcut> compiling HSP into binary form is easy. It's only problematic if you want to use happs-hsp-template to support dynamic loading
18:41 < stepcut> mae: http://nhlab.blogspot.com/2008/07/html-templating-in-happs-using-hsp.html
18:41 < stepcut> the first example shows how to compile it into you application. Then it goes on to show how to use happs-hsp-template for dynamic loading.
18:46 < mae> well can't we just have two compilation targets
18:46 < mae> hsp-dynamic and hsp-static
18:46 < mae> perhaps a make file? whats the haskell equivalent of a Rakefile (ruby) or Makefile (unix)
18:47 < stepcut> well, the usage is really different
18:47 < stepcut> with normally HSP your page generation functions are just normal functions that you pass arguments into. And you can use webQuery, etc
18:47 < stepcut> with the dynamic page loading, you have to marshal you data into JSON, etc.
18:48 < mae> um, so how does this marshalling approach work?
18:48 < mae> I mean isn't there a way we can use the preprocessor to define either static or dynamic mode at compile time
18:48 < mae> while still having the interfaces be the same in the hsp and on the happstack side of things
18:49 < stepcut> maybe, it would require template haskell I think
18:49 < mae> you know like
18:49 < mae> -DDYNAMIC_HSP
18:49 < mae> -DSTATIC_HSP
18:50 < mae> something of that sort
18:50 < mae> at compile time
18:50 < mae> would be ideal
18:50 < mae> stepcut: well we're using TH all over the place already :)
18:50 < mae> not like it adds another dependency
18:50 < stepcut> right, it's just not straight-forwardly obvious how to do it
18:50 < mae> heh
18:51 < stepcut> the locations of the page files on the disk are just haskell Strings that get evaluated at runtime in the dynamic version.
18:51 < stepcut> When you try to compile statically, you don't even know what to look for
18:51 < mae> hmm ok
18:51 < mae> if we consistently name HSP's this shouldn't be too bad.
18:52 < mae> i.e. MyHSP.hs
18:52 < mae> we wrap it with a high level library
18:52 < mae> where you just specify a hsp name (with same naming rules as modules)
18:53 < mae> renderHSP "MyHSP"
18:53 < Saizan> why do you have to marshal the data into JSON? doesn't everything happen in the server-side?
18:53 < mae> if we are using dynamic that gets converted to evaluate "MyHSP.hs"
18:54 < mae> if we use the static then i guess hmm it would have to import MyHSP qualified in a different scope and run the function instead
18:54 < mae> i can see why this is tricky in haskell :)
18:54 < stepcut> mae: yep
18:54 < stepcut> mae: I think it is solveable, but needs some gooding thinking first
18:54 < mae> the other option would be to just marshall everything into json as an intermediary step, it can't add that much overhead
18:55 < mae> but i don't really like this solution
18:55 < mae> because i like to let ghc optimize things
18:56 < mae> hmph
18:56 < stepcut> Saizan: all dynamically loaded pages have to have the same type. Something like, Web XML. So, that does not leave any way to pass arbitrary arguments to the different pages.
18:57 < stepcut> Saizan: the solution is two fold, (1) there is an read-only enviroment that you can add values to. That environment gets passed to the page. (2) in a loaded page, there is function which allows you to simulated making an HTTP request back to server, so that you can get more information.
18:59 < stepcut> Saizan: the data passed back could be binary or something else, but using JSON means that you can have consistent REST/JSON interface for your pages and your 3rd party API
18:59 < mae> stepcut: how does the code loading work, does it depend on ghci or does it use some other form of IPC on another process which is in charge of running the hsps?
19:00 < stepcut> mae: it uses hsplugins to compile and load the pages into the server process.
19:00 < Saizan> and you don't use only (1) because it's better to let the page ask for what it needs?
19:00 < stepcut> mae: with plugins, you basically have a copy of the ghc compiler and the linker in your application.. that's why it is so big.
19:00 < mae> stepcut: how much overhead is added from hsps if any that you know of? (as opposed to static  code rolled into the binary)
19:02 < mae> i see.
19:02 < stepcut> Saizan: (1) is not strictly required. But it is easier to use than adding a full 'callback'. But (2) is definitely required, because the page function might need all sorts of stuff that you can not anticipate when you call the page function.
19:04 < mae> im wondering if hsp has a static compilation target option built in already
19:05 < stepcut> mae: well, let's be clear on the terminology. hsp is a library and a pre-processor, which allow you to embed literal XML into your haskell programs. It is completely indepedent of HAppS and was designed and built with out HAppS in mind. happs-hsp-template is a solution for dynamically loading and compiling modules that use hsp. Though, even then, that is only because it was a quick hack. Ideally happs-hsp-template could be used
19:05 < stepcut> Text.XHtml instead of HSP.
19:06 < mae> sorry please replace hsp with plugins for my last message
19:07 < mae> we should get dons in here
19:07 < mae> :)
19:07 < stepcut> so, happs-hsp-template has a huge memory foot print, because it links in the whole ghc compiler. Adds about 28MB unstripped, and 15MB stripped just to the binary. Requires a fair chunk of ram as well.
19:07 < stepcut> dons will tell you that hsplugins is deprecated and you shouldn't use it :)
19:07 < mae> oh thats fun
19:07 < stepcut> in fact, it does not work at all with 6.10. But, we could do something similar with hint
19:08 < stepcut> though it still has a big footprint.
19:08 < stepcut> gwern said around 18MB unstripped
19:08 < mae> why can't we just use ghci
19:09 < mae> seeing as how we are targetting this for development anyways
19:09 < mae> it supports dynamic code loading etc
19:09 < Saizan> it doesn't support hot-swapping of code
19:10 < stepcut> mae: happs-hsp-template actually compiles the page and loads it into memory, so there is no runtime penalty for using happs-hsp-templates
19:10 < mae> Saizan: it doesn't? isn't that what :reload does?
19:10 < Saizan> :reload won't update the code a running thread, for example
19:11 < Saizan> s/a/in a/
19:11 < mae> hmm
19:11 < mae> i see
19:12 < Saizan> you need explicit eval calls if you want to change the code at runtime
19:12 < stepcut> is there anyway to get ghci to kill all the background threads aside from restarting it recompletely?
19:12 < mae> well ok so we do a bit of housekeeping, its not like we need the whole ranch
19:12 < mae> we keep track of the peer threads
19:12 < mae> so we can kill them if an hsp is updated
19:12 < mae> so any keep-alive sessions will dissapear
19:12 < mae> and they'll get the fresh stuff next request
19:12 < mae> simple as cherry pie
19:12 < stepcut> mae: I am not clear why using ghci is any better than using hint?
19:13 < mae> and then we can statically link
19:13 < mae> stepcut: because its less dependencies :)
19:13 < mae> i am not familiar with hint
19:13 < mae> looking into it
19:13 < Saizan> hint is just a thin layer over the ghc-api
19:13 < Saizan> and ghci is a similar layer
19:13 < mae> ok well basically we are talking about the same thing then
19:13 < stepcut> mae: hint is just a wrapper around the ghc-api. And ghc-api comes with ghc for free :)
19:14 < mae> ghci uses the ghc api
19:14 < Saizan> but, i don't think there's any way to have something like "import MyPage; ... page ..." and have page be something else after a reload
19:15 < mae> Saizan: true, but if we restart any threads that were using the MyPage module after the reload, then it should be brand new right?
19:16 < Saizan> i don't think so
19:16 < mae> hm
19:16 < stepcut> mae: I am still unclear how you intend to use ghci. Is the happs server process going to shell out to ghci?
19:17 < mae> I am weaving a web of confusion
19:18 < mae> let me start from the beginning
19:18 < stepcut> :)
19:19 < Saizan> my impression is that to actually see the effect of changing the MyPage module you've to reload all the modules that depends on it
19:19 < mae> OK, so what i'm suggesting is throw out happs-hsp-template
19:19 < mae> use hsp
19:19 < stepcut> ok, i'm with you so far
19:19 < mae> hsp gives us static compilation
19:19 < mae> with embedded xml
19:19 < mae> right?
19:19 < stepcut> yes
19:19 < stepcut> it would be almost exactly like using Text.XHtml
19:20 < mae> ok, so then we simply use the ghci api to recompile the hsp when we see fit, without all the json intermediary mumbo jumbo
19:20  * stepcut ponders
19:21 < mae> we do a little house keeping if we are in "development mode" which will reload the necessary files and/or kill the needed threads
19:21 < mae> when a page is changed
19:21 < mae> nothing more, nothing less
19:21 < Saizan> you basically have to kill your server and restart it
19:22 < mae> Saizan: are you sure? if the hsp code is called in the worker threads then we can kill those and be allright
19:22 < mae> or am i missing something
19:23 < stepcut> mae: ok, so my module imports Page.Index and calls, index :: String -> HSP XML, to generate the index page, right?
19:23 < mae> ok
19:23 < mae> listening
19:24 < Saizan> mae: it's not like reloading Page.Index automatically updates the references to it in static code
19:24 < stepcut> then I change, Page/Index.hs and update the index function
19:24 < Saizan> mae: so all the code that needs to see the updated code must be dynamic/interpreted as well
19:25 < stepcut> the dependency checker recognizes that Page/Index.hs has been modified (using inotify, etc) and recompiles that module
19:26 < mae> Saizan: so can we not simply avoid making static references to hsp pages? A function signature like renderPage :: String -> IO (HSP XML)
19:26 < mae> the thread memoizes the HSP XML
19:26 < mae> and then when we kill the thread it has to get it again
19:27 < stepcut> mae: so you would do, renderPage "Pages/Index.hs" ?
19:28 < Saizan> i don't see the difference with happs-hsp-templates then
19:28 < mae> stepcut: something like that, the point is it would be a monadic function which would return the hsp at the beginning of a peer connection to the http server
19:28 < mae> so this way it is only called once per peer
19:28 < mae> should be plenty good for dev
19:28 < mae> imo
19:28 < stepcut> mae: how would you statically link then?
19:28 < mae> Saizan: well doesn't happs-hsp-templates do additional stuff like marshalling json data etc
19:29 < mae> stepcut: we can use CPP, if static compilation is desired then we use the static function reference as opposed to the dynamic (every time a thread starts) function reference
19:29 < Saizan> yeah, but i thought we were discussing how to get static linking in a nice way
19:30 < stepcut> mae: what happens if the type of the index function changes?
19:30 < mae> stepcut: well I suppose your hosed at that point :)
19:30 < mae> good point
19:31 < mae> is that the reason fo the json madness? to unbox and generalize the stuff you pass into the hsp?
19:31 < stepcut> mae: in fact, what is the type of the index page? with renderPage :: String -> (HSP XML)< it appears that the index page must be a function that does not take any arguments?
19:32 < mae> stepcut: don't put too much stock in that function definition, I was mainly trying to point out the idea rather than the specific implementation :)
19:32 < stepcut> mae: but, no matter what, all your page functions are going to have the same type
19:32 < mae> Saizan: define "nice" ? avoiding cpp directives?
19:33 < Saizan> mae: yeah
19:33 < Saizan> especially since you'd have to put those in two places
19:33 < mae> Saizan: :)
19:33 < Saizan> among the imports and in the expression
19:34 < stepcut> Saizan: can template haskell add new imports to the top of the module?
19:34 < mae> ok then i guess my solution is a dead end for the time being, but the ride was illuminating
19:34 < Saizan> stepcut: not currently
19:34 < stepcut> mae: i think you basically re-invented happs-hsp-template :)
19:34 < mae> stepcut: yeah..
19:35 < mae> stepcut: what if i were to say that the code loading should fail if the type changed
19:35 < mae> because obviously there is other code depending on that
19:35 < mae> : )
19:36 < stepcut> mae: well, it does not work like that. If you statically link in a module, and then you dynamically load that same module, it does not replace the statically linked version.
19:37 < mae> stepcut: right but keeping this back to the page example, assuming the page is dynamically loaded, why is "what if the type changes on the page" a valid problem?
19:37 < mae> why should it change?
19:37 < Saizan> stepcut: each page could easily have a different type, the only problem is when you want to change the type of a page without editing the code that uses it
19:37 < stepcut> what happens is you get a handle to the dynamically loaded version, and you can call any function you want (I believe you specify the function name as a String). However, the type of the function is determined at compile time.
19:39 < stepcut> mae: well, i guess if it changed, then the server-side would have to change as well, so I take that back.
19:39 < mae> Saizan: this seems like a good design decision to me, if you change the page type and not the underlying code that uses it, it should fail! (in this case you recompile / restart the whole thing)
19:39 < stepcut> mae: yeah, I actually agree with that part
19:40 < stepcut> the difficult in the current happs-hsp-template code is that all pages have to have the same type due to the way dynamic loading works
19:40 < stepcut> I am trying to remember why that is though
19:40 < mae> stepcut: ok this issue can be worked around by having wrapper type
19:40 < mae> so you can do
19:40 < mae> DynamicCode a
19:40 < mae> which could be
19:41 < mae> DynamicCode (a -> b -> HSP XML)
19:41 < mae> or
19:41 < Saizan> when you dynamically load something you get a Data.Dynamic.Dynamic back, essentially
19:41 < stepcut> mae: the dynamic loader requires that the type be monomorphic
19:41 < mae> DynamicCode (x -> y -> HSP XML)
19:41 < mae> stepcut: well that sucks :(
19:41 < stepcut> mae: :)
19:41 < stepcut> I know because I tried that already :)
19:41 < mae> stepcut: wait, but i can reload code in ghci that is not monomorphic
19:42  * stepcut ponders
19:42 < mae> i think its in its application that it has to be monomorphic
19:42 < mae> no?
19:42 < stepcut> I am only familiar with what hsplugins offered, maybe ghc-api can do other tricks now
19:43 < mae> stepcut: i'm just coming from the point of view that, "if ghci can do it, we can do it"
19:43 < Saizan> it all boils down to unsafeCoerce, really :)
19:43 < mae> the reason i favor the method i'm rolling with right now
19:43 < mae> is that I don't want to lose the Strong Typing between happstack and HSP
19:43 < mae> json sounds nice for a REST web service, but not for internal
19:43 < mae> not when you got haskell!
19:44 < mae> Saizan: yeah well, sometimes you must get your hands bloody :)
19:44 < mae> can't let your henchmen do all the work
19:45 < stepcut> mae: yeah, did not like the loss of strong typing that you got with happs-hsp-template, that was another I stopped using it
19:46 < mae> yay
19:46 < stepcut> though, you can actually regain that
19:46 < mae> ok so assuming that what we talked about is possible
19:46 < stepcut> to a degree
19:46 < mae> do you guys like those semantics
19:46 < stepcut> which semantics
19:46 < mae> 1. dynamic code loading only supports the hsp side of the equation
19:47 < mae> 2. dynamic vs static compilation turned off or on with a cpp flag
19:47 < mae> thos eone
19:47 < mae> those ones *
19:47 < stepcut> I don't understand what 1 means
19:47 < mae> assuming we can get different types of hsp with minimal cost
19:48 < mae> stepcut: referring to what we said earlier, meaning, if you change the code in the hsp, it will be automatically reloaded, but if you change the code on something that is not an hsp then you will have to recompile / restart
19:48 < stepcut> ah, ok.
19:49 < mae> s/an/a
19:49 < stepcut> that sounds good, except I see no reason for that mechanism to be hsp specific.
19:49 < mae> stepcut: ok -- but then we get into the messy business of having to use dynamic function references
19:49 < mae> which actually probably isn't that big of a deal
19:50 < mae> it could be in a separate module
19:50 < mae> Happstack.Integration for instance
19:50 < stepcut> I don't think that is the case...
19:50 < mae> stepcut: explain
19:51 < Saizan> if you don't want to reload the code each time you call it you need a Map/IORef where to store those functions
19:51 < stepcut> if you already have the ability to load page functions that have different types like, User -> Pass -> HSP XML, then why would, User -> Pass -> IO Html, be any different?
19:52 < stepcut> if you changed from one to the other, then you would have to do a full rebuild. But I don't see any reason to make the general mechanism HSP specific.
19:53 < mae> Saizan: sounds interesting :) and the IORef is a monomorphic type?
19:55 < stepcut> mae: i think he means that you need a Map/IORef type thing so that when you do, execTemplate "Page.hs" "page_name", it can cache the compilation and loading of the page instead of recompiling it everytime?
19:55 < mae> ah i see.
19:56 < Saizan> yeah, that
19:56 < stepcut> (which is what happs-hsp-template does)
19:56 < mae> ok so for version 1, i mean, lets not do any premature optimization here, what if we just did a reload on every page request if a command line arg is given
19:56 < Saizan> and if you store Dynamic's there you can cast them to the right type at the call site
19:57 < mae> that is feasibly pretty easy
19:58 < Saizan> to load polymorphic functions, expecially the ones with a typeclass context, we need to investigate the ghc-api further
19:58 < stepcut> Saizan: something like, (execTemplate "Page.hs" "function" :: IO Dynamic) >>= \f -> (fromJust $ fromDynamic f) arg1 arg2 arg3
19:59 < Saizan> stepcut: yeah, the fromDynamic part could be inside execTemplate
19:59 < mae> i gotta step out guys, spending time with wife -- talk to you later.
19:59 < stepcut> Saizan: execTemplate :: (Dynamic a) => String -> String -> a
19:59 < Saizan> execTemplate :: Typeable a => String -> String -> IO a
20:00 < stepcut> right
20:00 < stepcut> how would you pass arguments to the page function?
20:01 < stepcut> oh, duh.
20:01 < Saizan> execTemplate "Page.hs" "function" >>= \f -> f arg1 arg2
20:01 < stepcut> I forgot
20:01 < stepcut> short memory ;)
20:01 < stepcut> now, the next question is, how can we get the type checker to ensure that we are apply the right number and type of arguments
20:02 < Saizan> you can actually get polymorphic functions in this way if you don't mind having a wrapper datatype
20:02 < Saizan> right number and type wrt the current version of Page.hs?
20:02 < stepcut> yeah
20:03 < stepcut> ok, thinking out loud here, what if we had a type like, data Page a = Page "Page.hs" "function" a
20:04 < Saizan> what about requiring you to import Page anyway and use a macro like $(execTemplate 'Page.function) >>= \f -> ..
20:04 < stepcut> and execTemplate :: (Typeable a) => Page a -> String -> String -> IO a
20:04 < Saizan> ?
20:05 < stepcut> and then, you would export things like, indexPage :: Page ; indexPage = Page "Index.hs" "index" index
20:05 < Saizan> the only downside is that you get Page linked in even if you won't use that code
20:05  * stepcut ponders
20:07 < stepcut> I think your TH solution is almost the same thing, but using TH instead of creating the Page things by hand
20:07 < stepcut> with that TH solution, could it take an argument to switch between dynamic loading, vs just calling the function directly?
20:08 < Saizan> i don't see why not
20:08 < stepcut> ok, this sounds like was I imagining, but had not worked out in detail
20:09 < Saizan> initially i thought we didn't want to import the Page module in the dynamic case
20:09 < Saizan> but if we want static typing you can't avoid it
20:09 < stepcut> right
20:09 < stepcut> I would rather have static typing than save a few bytes -- considering that ghc-api adds 18MB, the extra bit won't matter
20:10 < stepcut> and, it is really just a development feature that you turn off for live sites most of the time
20:10 < stepcut> I am not yet positive it has to get linked in either
20:11 < Saizan> but, if you want to cache the functions and the return type is in IO, does that mean we've to use a global IORef for the table?
20:11 < stepcut> if I import a module, but don't use any functions from it, then ghc won't link any of those functions in.
20:12 < Saizan> with split-objs you mean?
20:12 < stepcut> Saizan: i dunno, just in general?
20:13 < stepcut> Saizan: my applications don't contain the all the functions in Prelude even if I don't use them, do they?
20:13 < Saizan> the core libraries are built with split-objects turned on
20:14 < Saizan> but i don't really know
20:14 < stepcut> regarding the global IORef: in happs-hsp-template, you explicitly create the cache table, and then you store it in a ReaderT monad. You wrap everything in a call like, makeCache -$\cache -> runHSPTemplate cache $ impl
20:15 < stepcut> lets assume that ghc only links functions that are actually called
20:15 < stepcut> then adding, import Page, won't cause anything additional to be linked in.
20:16 < stepcut> now, $(execTemplate 'Page.function), does use something from Page, but it only uses it at compile to to extract the type information. So, after splicing is done, the Page.function is not used anymore, and also may not be linked into the final application?
20:17 < stepcut> anyway, I would use it even if that is not the case
20:17 < stepcut> the trick now is to hack up, 	 $(execTemplate 'Page.function) >>= \f -> .., and see if it really works
20:18 < stepcut> is so, I think it would be a useful library in its own right, unrelated to happs in any way
20:18 < Saizan> right
20:19 < stepcut> would be useful for lambdabot, etc
20:19 < stepcut> or, xmonad, yi, etc
20:19 < stepcut> any place where dynamic loading is useful, but static compilation is also desirable
20:22 < Saizan> the only part i'm unsure of is if Page.function is polymorphic with a typeclass context
20:22 < Saizan> s/if/what happens if/
20:22 < stepcut> dunno. But even if Page.function has to be monomorphic, it is still nice.
20:24 < stepcut> worst case, you have to write a wrapper that fixes the types. After all you are (most likely?) going to apply it to some arguments with monomorphic types?
20:25 < stepcut> ok, I really have to clean now
23:23 < wchogg> Okay, this is really strange.  I can compile the happstack-dns package, but if I try to load it I get a weird "unknown symbol" error.  Anyone else seen that?
--- Log closed Mon Jan 26 00:00:06 2009