03:33:41 <dons> hey guys, is the self-demoing happstack tutorial maintained?
03:33:57 <dons> i was recommending it to people, but seems like it doesn't install -- norman ramsey at least reported failure
03:49:08 <JuanDaugherty> so you thought "trust but don't verify" was justified in this case?
03:50:45 <JuanDaugherty> a ponderous thing ought by nature to be trusted in proportion to effort required to throw it some distance
03:55:29 <dons> heh
03:55:38 <dons> i trust stepcut et al
09:29:10 <Entroacceptor> i couldn't get it installed,either
13:00:10 <stepcut> ACTION does not have commit access to the tutorial :-/
13:23:46 <tommc> Just started with happstack-0.5. I got the guestbook server running, but only by running cabal install in the project directory. The import Paths_guestbook (version) of course precludes running interactively.
13:24:14 <tommc> It's easy enough to remove, but that might be confusing to new users.
13:24:26 <stepcut> you can do cabal configure, and then :set -idist/build/autogen, or somethnig like that, to run interactively
13:24:35 <stepcut> bit annoynig though
13:24:58 <tommc> stepcut: ah, didn't know that.
13:25:18 <stepcut> maybe we could add some #ifdefs so that the paths stuff is only used when being built via cabal or something?
13:26:51 <tommc> That would work, although it depends on how quickly users are going to ditch the default project template anyways. *I myself am fairly new to happstack, so don't know this answer yet*
14:08:29 <stevenmarky2> Hello my images are being served from happstack with max-age header =0. How do I control the max-age?
14:12:30 <stepcut> :-/
14:13:05 <stepcut> isn't max-age a cookie thing ?
14:13:46 <stevenmarky2> no, it's in the response header sent to the browser "Cache-Control:max-age=0"
14:14:07 <stevenmarky2> hmm actually.
14:14:44 <stepcut> I don't think happstack sets that at all..
14:15:21 <stevenmarky2> you're right, I'm actually looking at the request header sent from the browser >..>
14:15:33 <stepcut> :)
14:43:03 <stevenmarky2> Thanks anyway. See you later.
14:53:09 <JuanDaugherty> i have faith, in the good sense in which one can have it in real beings with the right kind of orientation, but I don't "trust"
14:53:19 <JuanDaugherty> especially academics
14:53:43 <JuanDaugherty> at least those that live their entire lives in the tower
16:14:53 <aavogt> stepcut: for interactive use of some project put   :set -idist/build/autogen   in a .ghci file in the directory where people run ghci
16:15:10 <stepcut> aavogt: ooo. send a patch :)
16:15:33 <aavogt> if there are #ifdefs based on cabal-produced macros, it's a bit more involved
16:15:50 <aavogt> one more thing to do :)
16:18:19 <stepcut> I'm a bit too busy trying to use happstack at the moment to spend time making it even more awesome :(
16:28:16 <JuanDaugherty> doubtless that will adduce more to it actually working
16:32:29 <stepcut> happstack actually works
16:32:34 <stepcut> :)
16:33:38 <aavogt> stepcut: so the main repo is still mae's branch on patch-tag.com?
16:33:46 <stepcut> aavogt: yes
16:36:13 <aavogt> me somehow also has:
16:36:15 <aavogt> Thu Feb  4 10:59:44 EST 2010  Adam Vogt
16:36:19 <aavogt>   * Fix compile error in example code.
16:36:40 <aavogt> stepcut: did that one get lost, or is it rejected?
16:37:17 <aavogt> ACTION sends it anyways
16:47:27 <stepcut> aavogt: lost I suspect
17:23:01 <gour> evening
17:24:18 <gour> i am evaluating fossil-scm, but its wiki is a toy, so another option is to simply stay with darcs and use gitit...now i wonder if anyone can tell what are memory requirements for running it, i.e. is shared hosting on webfaction enough or nothing without VPS?
17:29:18 <aavogt> gour: I've run gitit (with a git repo) on a shared host with ~100M ram
17:29:38 <aavogt> I think 64 worked, but wasn't enough for other things to run there
17:29:50 <gour> aavogt: thanks
17:30:17 <aavogt> this was with gitit as of 1 year ago, maybe it's memory usage has changed
17:30:21 <gour> i just found post about it - http://wrwills.webfactional.com/2009/10/30/Haskell-on-a-Webfaction-Host
17:30:47 <gour> my plan on WF is 80MB atm...
17:43:24 <HugoDaniel> hi
17:43:35 <HugoDaniel> happstack 5 depends on hsp
17:43:54 <HugoDaniel> which depends on htrhsx
17:43:58 <HugoDaniel> which fails to compile
17:44:26 <HugoDaniel> http://hackage.haskell.org/package/trhsx  and is deprecated
17:51:09 <HugoDaniel> oh well
17:51:12 <HugoDaniel> i have happstack-server
17:51:17 <HugoDaniel> which is the one i actually need :D
17:51:51 <bonobo> HugoDaniel: hsx has trhsx executable inside
17:52:06 <bonobo> and trhsx project is empty :)
17:52:31 <bonobo> it was before cabal could have libs and execs in one package
18:46:45 <stepcut> maybe we can get that package removed.. it seems to cause a lot of trouble
18:52:57 <bonobo> stepcut: interesting is that is just installs for me, without problems
18:53:09 <stepcut> the trhsx package ?
18:53:27 <bonobo> well, haskell-src-exts, which seems to depend on trhsx
18:53:43 <bonobo> or hsp
18:55:04 <stepcut> hsp depends on hsx, which installs the trhsx binary
18:55:18 <stepcut> technically, hsp should depend on the trhsx via the build-tools: mechanism
18:55:45 <bonobo> and that is ok, but there is and old trhsx *package* that used to containn *only* trhsx
18:55:53 <stepcut> right
18:56:00 <stepcut> I just emailed some poeple to see if we can get rid of that package
18:56:18 <bonobo> is it listed as a dependency somewhere?
18:56:27 <bonobo> I don't see that
18:57:16 <stepcut> the trhsx package ?
18:57:50 <bonobo> yes
18:57:57 <stepcut> right
18:58:02 <stepcut> there are no dependencies on it
18:58:24 <bonobo> so it should not be taken into consideration by anything out there...
18:58:26 <stepcut> but if people dont' have ~/.cabal/bin in their PATH, then hsp won't find trhsx and will fail. And then people try to install the trhsx package, which does not help anything
18:58:38 <bonobo> stepcut: ha!
19:00:15 <bonobo> stepcut: on a side note I was working on IxSet and made it twice as fast as it was before for some pathologic scenario :)
19:00:23 <stepcut> yay!
19:00:40 <bonobo> just rewrote intersection and union :)
19:00:47 <stepcut> nice
19:00:50 <stepcut> IxSet needs love
19:01:15 <bonobo> I have no idea why me, but seems I have adopted IxSet :)
19:02:11 <bonobo> we need to get rid of flatten, as it is really slow now, the bottle neck actually
19:02:17 <stepcut> ok, trhsx is not officially marked as deprecated in hackage, maybe that will help
19:02:25 <stepcut> yeah, flatten scares me :)
19:02:57 <bonobo> naaaaah, it is quite calm, but does a lot of useless work
19:03:10 <stepcut> right
19:03:35 <stepcut> I wonder if IxSet could benefit from nested data parallism at all
19:04:13 <stepcut> or any sort of parallelism
19:04:20 <bonobo> NDP is ruled out, there are no vectors there, and Maps and Sets aren't NDPable (yet)
19:04:32 <bonobo> stepcut: I thought about this too
19:04:35 <stepcut> right
19:04:42 <stepcut> we would have to add some vectors :-/
19:04:59 <bonobo> so I imported par/pseq and have put them in some places where it seemed resonable
19:05:18 <stepcut> ah
19:05:23 <stepcut> any results ?
19:05:24 <bonobo> but I did not get any effect neither positive nor negative
19:05:37 <bonobo> I was doing possibly something wrong
19:05:45 <stepcut> did you add the runtime flags to use multiple processors ?
19:06:12 <bonobo> but while doing it I saw that the data is not really independent now, so I'm working on untangling it a bit
19:06:30 <bonobo> yep, flags were there, I hope correct flags they were :)
19:07:10 <bonobo> basic unit of parallelism is to rnf each of indexes
19:07:36 <bonobo> I'm heading toward that goal, will see if it brings anything
19:07:40 <stepcut> cool
19:07:51 <stepcut> parallelism is tough stuff
19:08:18 <bonobo> well, it is
19:08:32 <bonobo> still we have that idle cores here and there
19:08:53 <stepcut> bonobo: yeah, that is what SPJ was saying in a recent talk
19:09:14 <bonobo> yes, I saw that talk too, was really cool
19:09:53 <stepcut> bonobo: of course, the big complaint right now is that IxSet uses to much RAM.. though that has not actually been confirmed either
19:10:40 <bonobo> stepcut: well, I loose my patience waiting when the set is like 50k of (a bit bigger, unreal) elements
19:10:50 <stepcut> all we know is that some happstack checkpoint files are 10MB on disk, but the happstack program consumes 800MB when it is run.. whether that is legitimate or not is unknown...
19:11:01 <bonobo> and it still uses less than 500MB RAM so it seems it is not that bad
19:11:30 <bonobo> stepcut: I read that, mightybyte wrote something about this issue
19:11:42 <stepcut> right
19:12:02 <stepcut> I have another app with similar properties
19:12:09 <bonobo> if he is using String instead of ByteString/Data.Text then I wouldn't be surprized
19:12:22 <stepcut> his app does not use much String in the first place
19:12:36 <stepcut> I have an app that used to, but now it uses Text. Not sure it helped much though
19:13:11 <stepcut> but I need to spend some serious time with the memory profiler to figure out what is actually going on
19:13:56 <bonobo> well, if you can isolate state from you app and create a test case: create set, serialize, read back, see lots of mem used
19:14:05 <bonobo> then I can also look at it
19:14:40 <stepcut> right. I figure someday it will become a big enough problem that I have to actually fix it, but until then my time is focused elsewhere
19:15:41 <bonobo> stepcut: I did ask you alread, but lost it: what hosting services do you use yourself?
19:15:51 <stepcut> vpslink
19:16:00 <stepcut> with the Xen option, not openvz
19:16:08 <stepcut> openvz is not a good choice for happstack apps
19:16:18 <bonobo> why is that?
19:16:55 <stepcut> xen provides virtual memory, but openvz does not. GHC's memory usage tends to allocate a fair bit more virtual memory that it really uses
19:17:17 <bonobo> aaah! that is important!
19:17:19 <bonobo> thanks!
19:17:25 <bonobo> need to go and get some sleep!
19:17:32 <stepcut> so with xen you can have a big swap file that never gets used, but with openvz you have actually RAM allocated that is never used
19:17:37 <bonobo> talk to you tomorrow!
19:17:47 <stepcut> yay!
20:26:43 <HugoDaniel> http://hackage.haskell.org/package/WashNGo-2.12.0.1
20:26:46 <HugoDaniel> interesting
20:27:38 <stepcut> spiffy
20:36:04 <Entroacceptor> yeah, I've seen that before
20:36:06 <Entroacceptor> what is it?
20:41:58 <stepcut> a cabalized version of WASH
20:58:43 <Entroacceptor> I don't trust web libraries where the examples don't work
20:59:17 <stepcut> :)
20:59:36 <Entroacceptor> but the formy stuff looked nice
21:00:04 <Entroacceptor> but as I only look at libraries, never implement stuff with them maybe I should shut up
21:29:16 <HugoDaniel> nah, its nice to have a "first impression" review :)
22:31:47 <HugoDaniel> eheh
22:31:53 <HugoDaniel> i like that blog about the server parties :D
22:53:34 <stepcut> :)
22:58:57 <HugoDaniel> stepcut are you planing on going to the haskell symposium in september in baltimore ?
23:23:56 <kfish> HugoDaniel :)