00:00:07 <donri> or just use authenticate directly
00:01:42 <tazjin> The Web.Authenticate one? I though that's for OpenID and login with Facebook etc.?
00:01:53 <donri> and browserid
00:02:20 <donri> why would you want to implement authentication yourself ^_^
00:02:50 <donri> it's really complicated to make securely and just annoys potential users having to do yet another sign up
00:03:02 <tazjin> Well, it's an internal tool at work and I don't feel like using any kind of public authentication method
00:03:11 <donri> ah
00:06:53 <donri> in that case no, i know of no generic module. you should set up happstack-server-tls and store passwords with something like perhaps scrypt
00:09:50 <donri> bedtime
00:10:06 <tazjin> Well, I'm not so much concerned with password security. The tool is not accessible from outside the company and since it's a mobile web app the passwords are four-digit numerical codes (This is debatable, I know)
00:10:08 <tazjin> Sleep well!
06:01:23 <Lemmih> stepcut: (re IO bound) Yes, updates are very IO bound. They might even be more expensive than a database transaction. The only solution is to do lots in parallel.
06:18:53 <Lemmih> stepcut: You've got mail.
06:21:06 <Lemmih> stepcut: I'm a bit surprised that this isn't intuitive to people. The company where I work (they used acid-state before hiring me) also had that problem.
06:21:20 <Lemmih> Did a bunch of sequential updates and wondered why it was slow.
06:22:36 <Lemmih> Your mental model should be that updates are transactions with all the normal performance limitations you get from regular DB transactions.
10:15:02 <Lemmih> stepcut: My schedule is such that I can only do part-time work in the first 1.5 months and then full-time work in the last 1.5 months.
10:15:29 <Lemmih> That should still be enough to complete the backend.
10:15:35 <Lemmih> (And then some)
20:05:14 <alpounet> aaaaaaalright
20:05:15 <alpounet> exam done.
20:05:41 <alpounet> ACTION will eat and then enter the sandboxed builds hell
20:16:46 <stepcut> :)
20:17:07 <stepcut> I am thinking that we might just want to look at the source code for hsenv, cabal-dev, etc, and then implement something that does what we actually want?
20:18:00 <alpounet> oh boy
20:18:05 <alpounet> that's going to be cumbersome :P
20:18:43 <stepcut> i think using the apps directly might be more cumbersome
20:25:27 <alpounet> yeah, that's true
20:27:01 <stepcut> the whole premise of scoutess so far is that trying to use general purpose tools is inferior to a customized solution :p
20:28:35 <alpounet> hah, yeah that's pretty much the story so far
20:29:10 <alpounet> we should get a best build bot software of the year award or something at the end man
20:50:38 <dcoutts> alpounet, stepcut: cabal-dev isn't doing anything particularly special, it's just doing some setup and calling cabal with various flags
20:51:53 <dcoutts> so if you want to have the greatest control then call cabal directly, rather than the extra indirection of cabal-dev
20:52:40 <dcoutts> alpounet: btw, if we can reuse most of the buildbot code for the hackage-server builder client, that'd be nice :-)
20:58:35 <alpounet> for the sandoxed build part? sure
20:58:50 <alpounet> it'll most likely be quite modular
21:04:05 <alpounet> dcoutts, actually, you could just have "scoutess" run on a package whenever a new version is uploaded
21:04:15 <alpounet> with all the fancy options disabled
21:04:55 <dcoutts> alpounet: where would scoutess run?
21:06:00 <dcoutts> for hackage, we want builder clients to monitor either the rss feed, or the package index
21:06:06 <dcoutts> and then to download and build packages
21:06:18 <dcoutts> the builder client can choose what combo of deps to use
21:06:24 <dcoutts> e.g. try stable, try latest etc
21:06:35 <dcoutts> the policy is left up to the builder
21:07:39 <dcoutts> and of course there's also the opportunity to test rebuilding other packages that can depend on the new upload
21:07:52 <dcoutts> in a sense, hackage doesn't care, it just collects the info and presents some reports
21:08:13 <dcoutts> leaving the decision of what to try building to the client
21:12:22 <dcoutts> alpounet: actually it could all integrate reasonably well, if we add a feature to scoutess to allow posting build results to a hackage server
21:13:32 <alpounet> dcoutts, that's something we have planned actually :) the first report posting milestone is just posting some JSON data to a given url
21:13:58 <dcoutts> alpounet: so the design is that the scoutess controls a bunch of builder clients right?
21:13:59 <alpounet> dcoutts, and what you describe is exactly a part of what we want scoutess to do...
21:14:22 <dcoutts> so the server has the smarts and the build bot clients are dumb right?
21:14:36 <alpounet> dcoutts, eventually we want to be able to distribute build tasks yes
21:14:47 <alpounet> so there'll be dumb build bots
21:15:05 <dcoutts> oh currently it's a single-node design, with builds running locally?
21:15:15 <alpounet> currently, it doesn't build anything :P
21:15:22 <dcoutts> :-)
21:15:25 <alpounet> i'm about to tackle the sandboxed building service
21:15:29 <dcoutts> well, initial design
21:15:41 <alpounet> we're just building scoutess out of many tiny services
21:15:55 <alpounet> so the sandboxed building service will just be importable wherever we want
21:16:16 <alpounet> and since we slave bots for actual building, that's where they are going to be
21:16:21 <alpounet> we want*
21:16:40 <dcoutts> ok, but the grander scheme is that you've got some web service where you configure what you want your bots to do, and then just let it go and you can see browse the latest reports etc, right?
21:17:28 <dcoutts> and one configuration is to watch a repo, or bunch of repos (e.g. as extracted from repo info in .cabal files)
21:18:00 <alpounet> dcoutts, yup, except that we haven't talked about a web service for the configuration, we've just planned a simple dyre-based config file
21:18:02 <alpounet> or smth similar
21:18:20 <dcoutts> ok, so local config, and some way of presenting results
21:18:31 <alpounet> offering a web interface isn't hard to do from there though
21:19:21 <dcoutts> ok, so then for a hackage server setup, you "just" want it to monitor the package uploads rather than a repo, and to post results in the format hackage-server understands
21:19:29 <alpounet> and yeah, we plan to be able to watch repositories and offer the possibility to try to build against the HEAD versions of the dependencies
21:20:21 <dcoutts> ok, so I think I'm a bit clearer about how it might all integrate
21:21:20 <dcoutts> it'd simply be one way of configuring scoutess to act as a builder for hackage
21:21:44 <alpounet> i think it doesn't require much more work to get it to monitor package uploads
21:21:51 <alpounet> that could just be another service
21:22:03 <dcoutts> right, it's just polling an rss or a index file
21:22:15 <alpounet> just have to find a way to integrate it nicely with the rest
21:24:20 <alpounet> dcoutts, or, there could just be an external script or something watching for uploads and then calling out to scoutess for the building that new version
21:25:03 <alpounet> but anyway, I think that scoutess fits pretty well for the hackage-server builder client
21:25:09 <alpounet> it's just really not there yet
21:25:28 <dcoutts> alpounet: yep, sounds good
21:26:12 <dcoutts> alpounet: in particular it fills in the hole for a smart builder, not just crowd sourcing user's builds via cabal-install
21:26:29 <dcoutts> but deliberately trying existing packages with new deps, or other similar policies
21:26:30 <alpounet> that's why i offered to mentor a GSoC student on it :p
21:26:37 <dcoutts> great
21:26:56 <alpounet> well, there is no student yet, but i did my best to catch any potential interest
21:27:09 <dcoutts> well, I'll vote for it :-)
21:27:24 <alpounet> dcoutts, yeah, we are really thinking about the most annoying situations
21:27:44 <alpounet> like packages with tons of (direct or indirect) dependencies, like happstack, yesod, and the like
21:28:40 <alpounet> you really want to try the newest versions for all your dependencies, but also older ones, and maybe with GHC 6.12.1 too, and also against the repositories to see if there are no breaking changes being done before it gets released, etc
21:33:43 <alpounet> dcoutts, also, i wrote a kind of "local hackage" service, it'll be used as some kind of cache, so that when working in the sandboxed env, we'll just cabal unpack stuffs from there
21:36:01 <dcoutts> alpounet: what does that local hackage service do?
21:36:26 <alpounet> it's just a HackageDB
21:36:34 <alpounet> (without the web interface ofc)
21:36:48 <dcoutts> alpounet: did you find the mirror client btw?
21:37:10 <dcoutts> can be used to sync between two hackage servers
21:37:24 <dcoutts> if your local service supports PUT then it should work for that too
21:37:57 <dcoutts> can be run for specific set of packages or everything, either one-shot or continuous
21:38:31 <dcoutts> alpounet: let me also forewarn you that I'm planning to enhance the hackage index format
21:38:49 <alpounet> oh.
21:38:58 <alpounet> what changes are you going to introduce?
21:39:01 <dcoutts> but should be backwards compatible, though I can only promise to test with the current central hackage server
21:39:09 <dcoutts> alpounet: a lot more flexible
21:39:36 <dcoutts> alpounet: the index will point to packages via URLs rather than implicit links
21:40:06 <alpounet> oh by the way, i found something to be pretty annoying, without finding any sound reason for it
21:40:10 <dcoutts> and will allow packages to be included by value as well as by reference, though that would not be used in the hackage archive use case
21:41:04 <alpounet> it's the fact that a package archive has to contain a "foo-version" folder, instead of just following the "foo/version/" hierarchy that's used anywhere else
21:41:35 <dcoutts> alpounet: so once we have explicit rather than implicit links, then there will be no such restriction on the layout
21:42:32 <alpounet> oh, that's nice
21:42:57 <dcoutts> indeed it's probably more sensible these days to just shove all the tarballs in one directory, not use any hierarchy
21:43:24 <alpounet> well, that's not what i meant
21:43:45 <alpounet> i rather meant that in the package index, we have <package>/<version>/<package>.cabal and the archive
21:44:16 <alpounet> whereas cabal sdist generates a <package>-<version> folder and tars up that folder
21:45:15 <alpounet> so you always have to jump from one to the other when fetching, adding a package to the index, etc etc
21:47:14 <alpounet> dcoutts, however, i may just borrow the code for handling the package index from hackage-server, when it'll be done :P
21:47:39 <dcoutts> alpounet: yep, we hope to split out a hackage-client package, used by cabal-install
21:49:43 <alpounet> and I think there is some room for a "cabal-install library" too
21:49:51 <dcoutts> aye
21:50:47 <alpounet> that would have saved me a few keystrokes :P
22:11:13 <donri> huh, darcs help is paged but not darcs log -.-
22:52:42 <donri> oh hey you can actually sort of minify jmacro directly, using renderStyle OneLineMode
22:52:58 <donri> FSVO "minify" :P
22:55:12 <donri> stepcut: should we do that for happstack perhaps? blaze isn't pretty-printed for one ...
22:55:35 <donri> although hsp is ... does it even have any other mode
23:00:37 <stepcut> could add a renderAsHtmlMin for HSP
23:01:25 <stepcut> I wonder how minification comparies to just sending the file using compression ?
23:02:25 <donri> both is best
23:03:04 <donri> and minification actually matters... it seems silly but it actually does make a difference. with yui it cuts down the total size to something like a third i think?
23:03:26 <donri> ...with their yui compressor. OneLineMode is far from as aggressive
23:03:45 <donri> hjsmin is disappointingly simple too it seems :( just drops whitespace, basically
23:04:49 <donri> also, for such non-agressive "minification" i suspect it's actually less CPU intensive than rendering pretty, so, yea.
23:22:19 <donri> ACTION discovers language-css
23:49:13 <tazjin> Will anyone slap me if I use the HsColour theme from the Happstack Crash Course in my blog? :p