14:35:34 <donri> stepcut: just watched the clckwrks demo, it's looking nice and promising!
14:36:34 <HugoDaniel> :D
14:46:34 <stepcut> donri: epic!
14:46:53 <stepcut> donri: I'm pretty excited about 1.0.. though there is quite a bit left to do to get there
14:47:22 <stepcut> I am wondering if I should skip ahead and get the dynamic loading finished first.. just because it is sexy
14:50:26 <stepcut> it would be nice to get the core really locked down and then focus on the various plugins
14:50:38 <stepcut> like the cms/blog one, and maybe a wiki one
16:41:41 <sm> stepcut: +1, no more plugins/features even needed for a 1.0 imho, but dynamic loading would add a lot of wow factor
16:42:11 <stepkut> yeah, I don't plan to add any new plugins for 1.0, just clean up the page plugin
16:42:18 <stepkut> there are still some silly parts about it
16:42:56 <stepkut> for example, if you are editing an already published, and you use 'preview', it will actually make your changes go live right away
16:42:56 <donri> honestly knowing how people work the focus should be on visual polish :p
16:43:08 <stepkut> donri: indeed
16:43:13 <stepkut> donri: it's better!
16:43:16 <stepkut> donri: but not yet best
16:43:31 <stepkut> but, the groundwork is now layed for making it look best
16:44:31 <stepkut> the dynamic loading code 'works' already.. but still have to do the boring part of tying it into cabal :(
16:44:44 <stepkut> and, ultimately, cabal sandboxes
17:07:14 <donri> stepkut: sister's new violin https://fbcdn-sphotos-d-a.akamaihd.net/hphotos-ak-frc1/860473_10151756032969325_241721880_o.jpg
17:08:05 <donri> an hardanger fiddle
17:27:11 <stepkut> fancy
17:27:24 <stepkut> I'm slowly working on my electric violin
17:27:29 <stepkut> I have a body shape finally
17:27:42 <stepkut> And think I have the bridge issue worked out
17:27:50 <stepkut> next thing to figure out is the scale length I want to use
17:31:55 <stepcut> I am probably going to do a neck-through-body design
20:57:07 <Jeanne-Kamikaze> any clckwrks dev around ?
20:59:54 <donri> Jeanne-Kamikaze: stepcut and stepkut share authorship
21:01:33 <Jeanne-Kamikaze> I have accelerate installed which requires cryptohash. Problem is, when I attempt to install clckwrks, I get a version clash and I am warned that if I proceed the accelerate package will break: cryptohash-0.8.3 (reinstall) changes: crypto-api-0.11 -> 0.10.2
21:01:33 <stepkut> yup
21:01:44 <Jeanne-Kamikaze> the question is, is there any reason why clckwrks depends on that old version ?
21:01:54 <stepkut> i doubt it
21:02:21 <Jeanne-Kamikaze> and do you know which package pulls the crypto dependency ? because there's no crypto in clckwrks.cabal
21:02:32 <stepkut> hold on
21:03:15 <stepkut> ACTION needs scoutess
21:09:02 <bergmark> fb =>
21:09:03 <bergmark> crypto-api==0.10.2/installed-659...
21:13:03 <Jeanne-Kamikaze> and which other package is pulling fb ? how did you figure that out by the way ?
21:13:35 <stepkut> it seems the latest version of  happstack-authenticate is not on hackage at the moment, I am about to push some updates
21:13:43 <bergmark> i did: cabal install clckwrks 'crypto-api == 0.11' 'cryptohash == 0.8.3'
21:13:53 <Jeanne-Kamikaze> oh
21:14:13 <stepkut> scoutess would have caught this problem for me :-/
21:14:54 <Jeanne-Kamikaze> I'm using clckwrks straight from the darcs repo by the way
21:15:02 <stepkut> cool
21:15:08 <stepkut> you'll still need the new happstack-authenticate
21:17:00 <Jeanne-Kamikaze> well if the one from darcs works I'm happy
21:17:04 <Jeanne-Kamikaze> gonna try that now
21:17:05 <stepkut> so.. it seems that fb is gumming up the works
21:17:31 <stepkut> it does not allow the latest http-conduit or the latest crypto-api
21:18:44 <levi> Are you using http-conduit?
21:18:57 <donri> Jeanne-Kamikaze: the repo url on hackage is wrong for hs-auth
21:19:14 <stepkut> levi: yes, the authenticate library requires it
21:19:14 <donri> Jeanne-Kamikaze: it's in http://hub.darcs.net/stepcut/happstack now
21:19:32 <Jeanne-Kamikaze> fb has an old version of crypto hard-coded in its cabal file. Maybe if I change that it'll just work
21:20:13 <stepkut> Jeanne-Kamikaze: hopefully
21:20:17 <levi> stepkut: I have started looking at websockets/sockjs again, but the variety of servers and streaming APIs has be a bit bewildered.
21:20:24 <stepkut> levi: yeah
21:20:40 <stepkut> levi: i'm still looking at the parsing problem
21:20:41 <donri> Jeanne-Kamikaze: could work. 'cabal unpack fb' is useful for that
21:21:08 <Jeanne-Kamikaze> ok thanks
21:21:49 <levi> stepkut: What in particular about the parsing problem?
21:21:54 <stepkut> I updated happstack-authenticate-0.10.3 to hackage.. seems 0.10.1 was actually there after all
21:21:59 <stepkut> but 0.10.3 is prettier
21:22:40 <stepkut> levi: most of the HTTP related specs provide a machine parsable ABNF spec.. but we don't use that in any way to prove that our parsers are correct
21:22:53 <stepkut> levi: and, accordingly, most probably are not
21:23:13 <stepkut> levi: obviously, there are cases where we might intentially deviate from the spec, but that should be annotated as well
21:23:52 <stepkut> instead of someone just modifying the parser and letting everyone else who comes along later wonder if the parser is intentionally wrong or accidentally wrong
21:26:35 <levi> So are you speaking of Happstack's preferred server specifically, or available servers in general?
21:26:51 <stepkut> all haskell web servers
21:27:18 <stepkut> they all contain hand written parsers, and we are required to believe that the implementor correctly interpretted and translated the specifications into code
21:28:39 <levi> Well, ultimately the specifications aren't the actual arbiter of usefulness as much as we'd like them to be.
21:28:50 <Jeanne-Kamikaze> well that didn't do the trick, fb could use some updating
21:30:12 <levi> And compliance with published grammars is typically only a very small portion of a standard.
21:30:13 <stepkut> levi: it is one thing to vary from the spec on purpose.. it's another thing to just screw it up
21:30:18 <levi> Right.
21:30:50 <levi> My point is that the only way to really test standards compliance is a test suite.
21:31:17 <stepkut> oh ?
21:32:01 <stepkut> well.. yes, that too
21:32:11 <levi> I happen to be sitting in a meeting of a standardization group that is discussing test plans. ;)
21:32:16 <stepkut> :)
21:32:47 <stepkut> well, whatever the method.. none of the current Haskell implemenations do a wonderful job of convincing me they are correct
21:33:22 <levi> Clarity of source code is a laudable goal, but something can *look* like it clearly implements a protocol specification without actually doing so, and something completely opaque can work just fine.
21:33:36 <stepkut> sure
21:34:07 <stepkut> but how do I know it is working just fine?
21:35:31 <levi> Well, you need to run it against a test suite. :)
21:35:42 <donri> levi: well the idea here is to use the formal grammars from the specs to either generate the actual parser, or to generate exhaustive test cases for a hand-written parser, thus making sure that at least the parsing is exactly as specified
21:35:45 <stepkut> which test suite?
21:36:24 <levi> donri: I think generating an exhaustive test suite is a more useful thing, actually.
21:36:42 <donri> if there's a standard test suite for http that can be used for a haskell server i'm sure stepkut is interested in that too
21:36:56 <stepkut> levi: how would you generate a test suite?
21:37:01 <levi> stepkut: That I don't know, but that's the direction I would advise you to move in.
21:37:54 <donri> not sure i agree there. it's likely easier to mess that up than a mechanical translation of a grammar
21:38:45 <donri> we tend to prefer formal specifications over tests in haskell ;) although *exhaustive* tests are equivalent i guess
21:39:19 <levi> Sure, but correctness is not the only desirable property of a parser, and it may not even rank in the top few properties as far as practical usefulness goes.
21:39:41 <levi> There's no point in constructing a correct parser if it doesn't make your practical parser any more correct.
21:39:58 <donri> this should be one and the same parser
21:40:02 <donri> not sure what you're thinking of
21:40:10 <levi> Generating a test suite allows you to find and verify fixes of *any* implementation.
21:41:04 <donri> generating the implementation from the specification allows you to skip the testing all together ;)
21:41:33 <levi> Theoretically. :)
21:41:39 <donri> i see your point and you're not wrong, but both options are valid i say. and generating a test suite seems harder.
21:42:04 <donri> levi: well there's no guarantee tests are right either
21:43:02 <levi> Generating a *correct parser* from a specification is not terribly difficult. Generating a correct implementation of HTTP 1.1 from its specification is impossible in a purely mechanical way.  It's not precise enough.
21:43:26 <donri> i see. but then we can't generate a test suite either.
21:43:37 <levi> Not automatically.
21:43:47 <donri> what we need, then, is manually written tests, but we can use those either way
21:45:41 <levi> My point is that if you want confidence in real-world software, you need a test suite for it.  That doesn't have to be the only thing you use, and reducing the coverage necessary by verifying parts in other ways is great as far as you can take it, but it can negatively impact other goals.
21:47:11 <donri> i agree you need tests for behavior, at least without dependent types
21:47:28 <levi> I mean, given a programming language grammar, you can mechanically generate a parser that is a 100% correct implementation of the grammar (for a suitably constrained grammar).  But for practical reasons, you may actually need to use a hand-build parser in your product.
21:47:53 <donri> property testing and strong types are much more exhaustive and reliable when applicable though
21:47:59 <levi> For purposes of error reporting, or tooling, or whatever.
21:48:55 <donri> levi: that's what stepkut is looking into now IIUC. how to combine parser generation with code usefully
21:49:34 <stepkut> levi: yes, the idea is to allow you to write a parser by hand that is still machine checked against the grammar
21:49:42 <levi> Anyway, I am not opposed to making a new HTTP parser that's mechanically generated from the EBNF in the spec, but that's just part of the spec and only part of the practical concerns of a web server.
21:50:05 <donri> i'm sure stepkut is aware of this :)
21:50:24 <donri> point is to make what you can, statically verified
21:50:35 <stepkut> you can't really useful parser from the spec anyway
21:51:22 <stepkut> the purpose of parsing the data is to translate it into a useful data type, like Request, and you can't do that automatically from the spec
21:59:49 <levi> Anyway, since formal grammars are actually formally defined as 'language generators' rather than matchers, using one in a quickcheck-style tester is a reasonable thing to do.
22:01:02 <stepkut> how would that work?
22:01:39 <levi> It would generate random valid HTTP requests and test if they were parsed correctly.
22:01:53 <stepkut> how would it know if they are parsed correctly?
22:03:48 <levi> Well, that's the tricky part, and depends on the same data representation problem you need to solve for the parser generation as well.
22:04:19 <stepkut> there is no parser generator..
22:04:35 <stepkut> well, not one that generates a parser from the spec anyway
22:08:29 <levi> Right, but you're talking about doing something to solve the problem. :)
22:08:58 <stepkut> yes.. I am writing the parser by hand in a way that can be machine checked