--- Log opened Wed Apr 01 00:00:06 2009
00:49 < sm> hey all.. how can I get rid of warnings like this when I link with happstack ? ld: atom sorting error for _hspreadzm0zi3zi1_ControlziConcurrentziChanziCloseable_W_closure_tbl and _hspreadzm0zi3zi1_ControlziConcurrentziChanziCloseable_R_closure_tbl in /Users/simon/.cabal/lib/hspread-0.3.1/ghc-6.8.2/libHShspread-0.3.1.a(Closeable.o)
02:24 < cocon> anyone using awstats or similar with success?
04:44 < solidsnack> mae: Have you given a talk at Galois yet?
06:19 < HugoDaniel> this might sound stupid, but...
06:20 < HugoDaniel> ...is there a fastcgi binding planned to happstack ?
06:20 < HugoDaniel> in order to allow its use in servers where only apache is available (and users can't open sockets)
06:21 < HugoDaniel> im thinking in hosting services like "dreamhosting" and others like that
06:22 < HugoDaniel> i really enjoy the ServerPartT approach of happstack, specially now with its monoid structure
06:54 < HugoDaniel> i also think it would be sweet to have the class "HasHeaders" public
09:37 < stepcut> HugoDaniel: there was a fastcgi binding for happs. No one has updated it to work with happstack AFAIK
09:38 < stepcut> HugoDaniel:  http://darcs.haskell.org/~lemmih/happs-fcgi/
11:07 < cocon> anyone using awstats or similar with success?
12:12 < mightybyte> Anyone know what causes this message?
12:12 < mightybyte> "HTTP request failed with: <socket: 5>: hPutBuf: resource vanished (Connection reset by peer)"
12:12 < gwern> hm, reminds me of the errors I saw when I backgrounded gitit and closed the terminal/shell
12:13 < mightybyte> My app is running in the foreground.
12:13 < mightybyte> It's not clear to me what conditions cause this.
12:14 < mightybyte> And I haven't noticed that anything stops working when I get that message.
12:45 < guenni> what's the easiest way to get the difference of 2 "YYYY:MM:DD:HH-MM-SS" in day fractions? The Time library confuses me
13:04 < sm> guenni: yes it's a bit hard to get your head around
13:04 < guenni> sm: sure is
13:04 < sm> I don't think the lib is bad, just time is complex
13:05 < guenni> I wasn't saying it's bad, just confusing
13:05 < sm> this gets the number you want: let parsetime s = fromMaybe (error "time parse failure") (parseTime defaultTimeLocale "%Y:%m:%d:%H-%M-%S" s) in (diffUTCTime (parsetime s2) (parsetime s1)) / 86400
13:10 < guenni> sm: thx
13:10 < sm> you're welcome
13:16 < iago> > length [1..1000000]
13:16 < iago> ops
14:48 < wchogg> Does anyone have sharable examples of using formlets with HSP?
15:26 < cocon> anyone using awstats or similar with success?
16:02 < mightybyte> Someone should build a CMS on top of happstack.
16:23 < cocon> what's a CMS?
16:59 < mightybyte> content management system
18:13 < stepcut> wchogg: re: formlets. For what purpose?
18:20 < mae_work> dcoutts: any plans to support stdcall in c2hs ?
18:20 < mae_work> it assumes ccall right now
18:20 < mae_work> trying to build some windows libs..
18:20 < mae_work> for work
18:20 < dcoutts> mae_work: oh, I wasn't really aware of that issue
18:21 < dcoutts> mae_work: please file a ticket
18:21 < dcoutts> http://hackage.haskell.org/trac/c2hs/
18:22 < dcoutts> mae_work: it'd have to be an extension to the call/fun syntax
18:22 < dcoutts> hmm
18:22 < dcoutts> unless it's visible in the header declaration
18:22 < dcoutts> in which case it could be automatic
18:23 < dcoutts> how are stdcall functions defined in Windows header files?
18:23 < dcoutts> I presume these are mingw's headers, not MS headers
18:23 < mae_work> yah
18:23 < mae_work> 1 sec
18:23 < dcoutts> since c2hs can only parse GNU C not MS C
18:23 < mae_work> i think they are identifiable because of @
18:24 < dcoutts> mae_work: we don't know about the link level stuff, only the header declarations
18:24 < dcoutts> is it not a declaration attribute?
18:25 < mae_work> BOOL WINAPI EnumProcesses(DWORD *,DWORD,DWORD *);
18:25 < mae_work> perhaps WINAPI means stdcall?
18:25 < mae_work> also, another request I have is to make the parms optional for #fun
18:26 < mae_work> right now i am putting #call in a module export
18:26 < mae_work> example: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=3196#a3196
18:26 < mae_work> althought i actually think this syntax isn't half bad :)
18:27 < mae_work> if you want to purely let c2hs handle the type safety
18:27 < mae_work> and then do the rest in haskell
18:27 < dcoutts> hrm, that means c2hs has to parse Haskell
18:28 < dcoutts> to see if it's used in an export context
18:28 < mae_work> ok forget it then :)
18:28 < dcoutts> but not having to specify function args would be handy
18:28 < mae_work> dcoutts: um, i don't know quite what you mean, but if c2hs parsed for WINAPI, isn't this just parsing C?
18:29 < mae_work> and then it changes ccall to stdcall
18:29 < dcoutts> mae_work: WINAPI gets expanded by cpp
18:29 < dcoutts> the question is what it expands into at the level of raw C syntax
18:29 < mae_work> ic
18:30 < dcoutts> http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/Function-Attributes.html#Function-Attributes
18:30 < dcoutts> there's a stdcall attribute
18:31 < mae_work> expanded
18:31 < mae_work> BOOL __attribute__((__stdcall__)) EnumProcesses(DWORD *,DWORD,DWORD *);
18:31 < dcoutts> right
18:31 < dcoutts> ok, so that's doable
18:31 < mae_work> great :)
18:31 < dcoutts> the C parser already parses attributes, but ignores them
18:31 < dcoutts> they're not added into the AST
18:31 < dcoutts> so that'd need work
18:31 < mae_work> so all u have to do is change ccall to stdcall
18:32 < dcoutts> then c2hs would have to look for that attribute in the AST
18:32 < mae_work> dcoutts: great, well for the time being i was almost going to use hsc, but figured that this is worth spending the time to communicate :)
18:32 < dcoutts> mae_work: so when you file the ticket in the c2hs trac, ping the maintainer of the Language.C library
18:32 < mae_work> manual FFI types is something id on't wanna deal with
18:32 < dcoutts> mae_work: hsc2hs doesn't help here
18:32 < dcoutts> hsc2hs doesn't really help at all with function imports
18:33 < mae_work> i know it doesnt
18:33 < mae_work> the point is that this lib i am making doesn't work without stdcall
18:33 < dcoutts> yep
18:33 < mae_work> and short of doing sed s/ccall/stdcall i didn't know what to do
18:33 < mae_work> and that felt too hacky
18:33 < mae_work> : )
18:33 < dcoutts> :-)
18:34 < dcoutts> it'd be a pretty useful feature actually
18:35 < dcoutts> there are some libs like opengl that use a different calling convention on windows than elsewhere
18:35 < dcoutts> and the gl binding currently uses hacky CPP
18:35 < mae_work> um i don't have a user/pass for this
18:35 < dcoutts> username "guest" and password "guest"
18:35 < dcoutts> if it were using c2hs with this feature it'd be automagic
18:38 < mae_work> http://hackage.haskell.org/trac/c2hs/ticket/17#comment:1
19:50 < cocon> anyone using awstats or similar with success?
19:52 < sm> still no luck cocon
21:10 < sm> a question about cabal files
21:11 < sm> I was able to install all of happstack with cabal install happstack, but it seems I need to list each sub package separately in Build-Depends in .cabal, is that right ?
21:18 < MarcWeber> sm ? Can't you give a complete description? What are you trying to do ? I don't know.
21:18 < MarcWeber> You've installed happstack. So what do you want to do with it? write another app depending on it?
21:19 < gwern> sm: basically. 'happstack' the cabal package depends on things like 'happstack-data'
21:19 < MarcWeber> Could you also copy paste the error you get to rafb.net/paste?
21:19 < gwern> but you could just use 'happstack-data' or happstack-ixset without using the rest
21:19 < gwern> they're logically separate packages
21:19 < sm> there's no need for all that.. just a small question, thanks anyway MarcWeber
21:20 < sm> yes I had to list them individually in Build-Depends
21:20 < MarcWeber> ok then :)
21:20 < MarcWeber> I even don't know about happstack-data yet.. I've missed it. I really have to switch focus towards haskell again..
21:22 < sm> here's a tougher one, why do I still get ld: atom sorting error when I link [with] the hspread lib ?
21:22 < gwern> now that's one I've never seen ebfore, so no idea
21:22 < sm> seems harmless, I think it's something that needs fixing in that lib
21:23 < sm> how's gitit hacking these days gwern ?
21:35 < gwern> sm: pretty well
21:35 < gwern> the interwiki plugin is stable and included in head
21:35 < gwern> my next plugin, one for archiving external links, is blocked on the issue that gitit doesn't have a 'pre-save hook' if you follow - just a 'render hook'
21:36 < dbg_> wow, i just upgraded a pretty hairy set of simpleHTTP request handlers from HAppS to Happstack
21:36 < dbg_> it was much easier than i feared, and now my code is much simpler!
21:36 < sm> aha
21:37 < sm> do pages still use .page suffix ?
21:37 < sm> nice dbg_
21:37 < gwern> sm: yes
21:37 < gwern> we don't have any better ideas on how to do it, and it currently seems to work
21:48 < mightybyte> dbg_: I just did the same thing.  It wasn't too bad.
21:48 < mightybyte> dbg_: I did get stuck in a place or two, but I like the finished result.
21:49 < mightybyte> dbg_: No more debating about whether something should be of type ServerPartT or [ServerPartT].
21:57 < dbg_> mightybyte: yeah, and you don't have to keep switching between WebT and ServerPartT ... i don't even totally understand it, i just know it is much more intuitive now.
22:32 < mightybyte> mae: ping
22:35 < dbg_> quit
22:35 < dbg_> \quit
23:17 < mae> mightybyte: ping
--- Log closed Thu Apr 02 00:00:06 2009