--- Log opened Sun Aug 02 00:00:52 2009
16:03 < mae> woot, i'm testing dl a 3gb file with fileServe
16:03 < mae> getting 11mb / sec on my own machine
16:03 < mae> not bad
16:03 < mae> someone should test this on different machines :)
16:05 < mae> Happstack.Crypto, what hackage package can we replace this with?
16:12 < mae> stepcut: did you ever polish up that lockfile patch ?
16:12 < Lemmih> Don't think you can replace it with a single package.
16:12 < mae> Lemmih: right, but we only use a handful of the stuff in it on the implementation
16:12 < Lemmih> mae: In what implementation?
16:12 < mae> happstack.
16:13 < mae> i just sent an email about it
16:14 < Lemmih> Happstack.Server.S3 should be deleted.
16:21 < mae> my thoughts exactly
16:21 < mae> bbl
16:24 < stepcut> mae: not yet.. didn't want you to get distracted from sendfile support in happstack ;)
16:24 < mae> its done :)
16:24 < mae> try it
16:24 < stepcut> ok
16:25 < mae> try some large static files
16:25 < mae> if you like
16:25 < mae> and md5 sum the source and dest
16:25 < mae> watch the mem, etc
16:30 < stepcut> mae: what version will the next stable release of happstack have?
16:30 < stepcut> 0.4.1 ?
16:31 < mae> yeah..
16:31 < mae> exactly :)
16:31 < stepcut> and 0.4 is the dev branch, right?
16:31 < mae> i want to release this sendfile bit soon
16:31 < mae> but would like to do a few things more things first
16:31 < mae> a little pruning, and take some of the header magic out of the handler
16:32 < mae> push it up further into a higher layer
16:34 < mae> the code isn't bad
16:34 < mae> but belongs in an s3 lib or something
16:34 < stepcut> mae: but, there are also other S3 libs now. So we should see if they are better and maintained
16:34 < mae> yep
16:34 < mae> its always in the repo if someone wants to dig it up :)
16:36 < mae> done.
16:36 < stepcut> we have made some improvements to the lock code. Fixed a bug, and added this function,
16:36 < stepcut> doesProcessExist :: ProcessID -> IO Bool
16:36 < stepcut> doesProcessExist pid =
16:36 < stepcut>     try (signalProcess nullSignal pid) >>= return . either checkException (const True)
16:36 < stepcut>     where checkException e | SE.isDoesNotExistError e = False
16:36 < stepcut>                            | True = throw e
16:37 < stepcut>  
16:37 < mae> ok, nice.
16:37 < stepcut> not sure how portable that actually is, but it might be portable to POSIX platforms
16:37 < mae> go ahead and push it up, and I will fix windows
16:37 < mae> I can write a doesProcessExist for win32
16:37 < stepcut> ok, ProcessID is unix specific
16:37 < mae> oh
16:38 < mae> yeah that should work on windows
16:38 < stepcut> it's a bit clever... it sends kill -0 to the process. Which does nothing. However the return code tells you if that process exists or not
16:38 < stepcut> sorry
16:38 < mae> they have System.Posix.Types on window
16:39 < mae> will it work on bsd?
16:39 < stepcut> that return code tells you if that the signal could be sent successfully. It could fail for two reasons: 1. the process does not exists 2. the user does not have authority to send signals to that process
16:39 < mae> clever is ok i guess, but can you add some comments? :)
16:40 < stepcut> I have no idea if it will actually work on BSD or OS X. That's the part we need to test. It might :)
16:40 < mae> yeesh
16:40 < mae> thats ok i mean, i'm sure the bsd guys will complain when it doesn't work
16:40 < mae> i have nothing to test that on
16:40 < mae> thats what minor releases are for :) x.x.minor
16:41 < mae> in fact, i am banking that they will complain about sendfile not working on bsd, because I still have yet to have someone that is available enough to work out the issues
16:41 < mae> so this just adds more to it
16:41 < mae> last week i hear 6.10.* didn't even build on bsd
16:42 < mae> when someone cares about the platform, it will get fixed
16:43 < stepcut> ok, it should work on FreeBSD
16:45 < stepcut> it appears to work on Linux, FreeBSD, and OS X
16:45 < stepcut> that's good enough for me :)
16:45 < stepcut> those Windows users will probably complain though..
17:07 < Zao> Does it support the AIX send_file yet? :)
17:08 < Zao> Whatever evil you do, please have some fallback functionality for platforms that do not have a send_file/sendfile call around.
17:08 < Zao> I was quite surprised to see that happstack built cleanly on Windows recently. That has not always been the case.
17:10 < stepcut> Zao: fileServeLazy and fileServeStrict are still around
17:11 < stepcut> Zao: same interface, but different performance characterstics
17:12 < stepcut> Zao: in theory, we could use #ifdefs to map fileServe to one of those on platforms with out sendfile.. but doing that at the library level seems a bit...
17:13 < stepcut> maybe we would expose fileServeSendFile, or something, so that apps can explicit pick what they want, or use a generic fileServe that picks whatever works 'best' on that platform
17:14 < stepcut> Zao: happstack aim to support Linux, FreeBSD, OS X, and Windows. Though we don't have any FreeBSD machines to test on, so we have to wait for bug reports
17:19 < Zao> I'd offer access to my FreeBSD box, but GHC doesn't target FreeBSD sparc64 well :)
17:21 < stepcut> :)
22:02 < mae> zao, stepcut: the sendfile library already has a "fallback" implementation built into the cabal file
22:02 < mae> in pure haskell
22:02 < mae> this was a requirement.
22:02 < mae> (for my design)
22:02 < mae> so happstack need not worry about that, it is handled in the sendfile library
22:03 < mae> and you can force the pure haskell impl if you do cabal install sendfile -fportable
--- Log closed Mon Aug 03 00:00:54 2009