06:30:09 <donri> stepcut: wouldn't, type ServerPart = ServerPartT IO, be better?
07:01:19 <stepcut> donri: probably. not clear if anything would break as a result
07:01:26 <stepcut> but for 8 I am happy to change it
07:03:26 <donri> :)
07:03:28 <donri> @time stepcut
07:03:29 <lambdabot> Local time for stepcut is Wednesday, June 6, 2012 2:04:26 AM Central Daylight Time
07:03:34 <donri> oh dear!
07:03:39 <stepcut> :)
07:04:05 <stepcut> just got back from my friend's birthday party
07:04:29 <stepcut> what ever happened to the prettier derivePathInfo?
07:04:40 <stepcut> @time donri
07:04:41 <lambdabot> Local time for donri is Wed Jun  6 09:05:37
07:04:52 <stepcut> up early? or reeeeeeelly late?
07:05:41 <donri> early i guess
07:05:58 <donri> had doctor's appointment yesterday and passed out when i came home, so got up at like 4am
07:06:08 <stepcut> whoa
07:06:18 <stepcut> sounds like an intense doctor's appt
07:06:59 <donri> haha nah more that i had to push my sleep cycle to be there and exhaustion from the travel
07:07:14 <stepcut> :)
07:08:07 <donri> i was physically unfit before this disease, but now i'm less fit than even when i was still smoking -.-
07:08:46 <stepcut> >:(
07:11:13 <donri> stepcut: re derivePathInfo, still waiting for darcs-2 :)
07:11:22 <stepcut> o
07:11:27 <stepcut> well, I'll fix that then ;)
07:11:39 <donri> didn't i send you a patch though?
07:11:48 <stepcut> possibly
07:11:56 <stepcut> not saying it is your fault :)
07:12:02 <donri> i know
07:12:21 <stepcut> that's why I asked.. :)
07:13:30 <donri> i made the first patch where it's hyphenated and lower-cased but without smart handling of initialisms
07:14:06 <donri> so e.g. DemoURL becomes demo-u-r-l
07:14:30 <donri> what solution did we arrive at for that anyway, i forgot?
07:14:40 <donri> in case of ambiguity that is
07:14:47 <donri> do we work around it or spew an error?
07:15:15 <donri> in the highly probable case that someone writes data Sitemap = DemoURL | DemoUrl
07:16:03 <stepcut> I think that is around where we stopped ?
07:16:23 <donri> i think we decided on throwing errors for that, but not sure
07:16:38 <stepcut> well. DemoURL would be, demo-u-r-l, but DemoUrl would be, demo-url
07:16:54 <stepcut> but, we were trying to figure out if there was something prettier we could do
07:17:01 <donri> yes, but we talked about having DemoURL be demo-url too
07:17:14 <donri> and then, what to do in face of ambiguity
07:18:10 <stepcut> though.. since URL types exist entirely for the purpose of creating URLs.. then maybe it is ok that DemoURL isn't that pretty?
07:18:28 <stepcut> since it could be changed to DemoUrl instead
07:20:10 <donri> or perhaps have FooURL become simply "foo"... i think we discussed having some version of derivePathInfo that takes a transformation function
07:20:24 <stepcut> yeah
07:21:09 <donri> and then simply have derivePathInfo call that with some default transformation
07:21:22 <stepcut> yeah
07:21:45 <donri> btw i think in general it would be nice to establish some conventions and terminology for happstack applications
07:21:53 <stepcut> though it needs two functions perhaps since it needs to go both ways
07:22:33 <donri> (without sacrificing flexibility and without actually *enforcing* the conventions)
07:22:48 <stepcut> yeah
07:22:49 <donri> stepcut: yea, perhaps we could apply boomerang to web-routes... hey wait a minute--
07:22:56 <stepcut> :)
07:23:50 <donri> I've started using a FooURL naming convention for route constructors to avoid clashing with other value constructors and because i don't like yesod's convention of suffix "R"
07:24:08 <stepcut> yeah.. I don't like the R thing either
07:24:26 <donri> URL is a bit more verbose but possibly more readable?
07:24:33 <stepcut> I have often thought that have a derivePathInfo that takes a transform function would be nice though
07:24:41 <stepcut> the bi-directionality of it is the only issue
07:24:51 <donri> plus it goes well with e.g. "showURL" and the associated type "URL"
07:25:01 <stepcut> yeah
07:25:45 <donri> i'm completely unable to read HomeR in any other way than "homer simpsons"
07:26:09 <stepcut> ahaha
07:26:59 <stepcut> Server Party is much better :) (aka, ServerPartT)
07:27:11 <donri> \o/
07:27:41 <donri> that's one area where i'm thinking of conventions and terminology... do we establish "handler" as our preferred word?
07:28:00 <donri> handler / controller / serverpart / server / application; we have too many words for this
07:28:07 <stepcut> i dunno. But I would like to pin that down for 8
07:28:19 <stepcut> Lemmih suggested change ServerPart to just Server
07:29:17 <donri> i had a thought to introduce some form of "representation" thing for handling Accept headers, and then renaming handlers to "transfers". combined with acid "state", we get "representational state transfer" ;)
07:29:33 <stepcut> hahaha
07:30:04 <donri> another idea is to simply call it "HTTP" in lieu with "XML" etc
07:30:24 <stepcut> yeah
07:30:34 <stepcut> but there you have HTTP vs HTTPS
07:30:51 <donri> yea, and then to make it a transformer you get HTTPST? :D
07:31:01 <stepcut> :-}
07:31:02 <donri> ServerT may be better, then
07:32:05 <donri> kind of goes well with the package being "happstack-server" as well, unless we change that for "h8"
07:32:13 <stepcut> :p
07:32:19 <donri> ACTION is totally using "h8" since you said we shouldn't
07:32:25 <stepcut> hehe
07:33:10 <donri> it's funny how i think in english but still pronounce things like "h8" in swedish mentally
07:33:30 <donri> true for all acronyms actually
07:33:35 <donri> sql, url, http, xml...
07:34:00 <stepcut> sql+url == squirrel
07:34:06 <donri> \o/
07:34:12 <donri> squrl
07:36:15 <donri> with the hsp overloaded strings fix, does that work for attribute values as well?
07:36:23 <donri> or do you have to give those types
07:36:42 <donri> <div class=("hello" :: Text)>
07:37:13 <donri> or are string literals as attribute values given types by trhsx too?
07:37:23 <stepcut> string literals are given types too
07:37:59 <donri> good
07:39:20 <donri> what about <% "literals" %>?
07:39:35 <stepcut> not sure
07:39:45 <donri> less important though
07:40:11 <stepcut> the extended defaulting stuff my help there
07:40:23 <stepcut> s/my/might/
07:40:56 <Lemmih> What should I name my talk about AcidState?
07:41:24 <donri> "State Monads on acid"
07:42:04 <stepcut> who is the audience
07:42:27 <Lemmih> Haskell meetup in Zurich.
07:42:38 <Lemmih> So people knowledgable about Haskell.
07:42:53 <Lemmih> *knowledgeable
07:43:05 <Lemmih> I like that, donri.
07:43:27 <stepcut> yeah.. i don't have anything better at the moment
07:43:52 <Lemmih> stepcut: Then what the hell am I paying you for?!
07:44:33 <stepcut> Lemmih: to fix the problem with handles leaking, investigating why checkpoints take so long to load, and figuring out some way to analyze RAM usage
07:44:40 <Lemmih> Oh yeah.
07:45:33 <donri> "oh that"
07:45:46 <Lemmih> "Monads on acid. How persistent state is easy in Haskell." ?
07:45:53 <stepcut> nice
07:46:05 <stepcut> maybe upper case ACID though ?
07:46:29 <donri> "Data durability in face of corrosive acids"
08:19:59 <donri> stepcut: the joke is acid = lsd, doesn't work upper cased
08:20:06 <donri> at least that was my intention
08:20:25 <donri> and "on acid" being trippy version of "on steroids"
08:24:56 <Lemmih> "Everything looks persistent after 200 mcg."
08:25:43 <donri> \o/
08:27:14 <Lemmih> "Worried about data loss? Use acid and you can relax."
08:28:16 <Lemmih> "Sit back and relax. Acid makes your world alright again."
08:28:16 <donri> needs to sound more sciency and academicy and category theory-y
08:29:20 <donri> "Transactions with referential transparency"
08:47:03 <donri> Lemmih: too much like couchdb slogan :p
10:29:09 <kstt> regarding acid-state, I was wondering something (purely theorical, I'm not concerned).
10:30:00 <kstt> let a = smallStructure; b = hugeStructure
10:30:26 <kstt> the size of hugeStrcture is greater than half the system memory
10:30:48 <kstt> the program could pretty well run with an object (b,b)
10:31:03 <kstt> acid-state could even persist it
10:31:35 <kstt> however, I guess it would fail to load it after restart, is that right ?
10:33:02 <kstt> (the astute reader should notice that the 'a' structure is absolutly irrelevant in this discussion :] )
11:39:59 <donri> kstt: i'm not sure at all here but i suspect maybe that you might be right if you checkpoint but otherwise not?
11:42:06 <kstt> I am not sure how serialization is performed, but I suspect that serializing (a,a) will duplicate a. Loading back the data after restart will need twice the memory it needed before shuting down.
11:42:51 <kstt> so it might be impossible to restart the application in the state it was before shutting down. (admitedly, the case is contrived)
11:43:36 <donri> kstt: well if you don't checkpoint, transactions are "replayed" so the sharing haskell does should still work
11:43:48 <donri> but if you checkpoint, it *might* be that "b" is serialized twice. not sure.
11:45:03 <kstt> The problem could happen when serializing IxSet
11:45:11 <donri> i guess it might be a problem without checkpointing too if you're not constructing the tuple inside a transaction
11:45:22 <kstt> indexing usually means that the colelction is large
11:45:45 <donri> ixset indices are created on deserialization, they're not serialized
11:45:47 <kstt> having 10 indexes would maybe mean 10 times more memory consumption after checkpoint & restart
11:45:58 <kstt> ah, ok, fair enough
11:45:59 <donri> ixsets are simply written to disk as lists of members
11:46:32 <donri> and at runtime, data should be shared between indices i think
11:46:41 <kstt> hopefully :)
11:47:02 <donri> but yea, it's not too easy to reason about memory usage with acid-state/ixset... i think that's on stepcut's todo
11:48:44 <kstt> unfortunatly, it's not too easy to reason about memory usage of stepcut's todo file itself
11:49:53 <kstt> as every problem in this world is in stepcut's todo :)
12:14:27 <donri> :D
13:30:05 <Lemmih> ACTION is using AcidState+mongodb at work.
15:28:11 <mekeor> Lemmih is awesome.
15:29:06 <HugoDaniel> :D
15:31:35 <stepcut> kstt: no! I've closed some bugs!
15:32:54 <stepcut> kstt: you are correct that sharing is often lost if you create a checkpoint file and then read data back in.. though, it would be retained if you didn't use checkpoints and replayed all the events
15:33:25 <kstt> but I *do* checkpoint on shutdown
15:33:53 <stepcut> kstt: in the case of IxSet though, the data should be shared since, as donri said, we just convert the IxSet to a list to serialize it
15:34:00 <kstt> thanks for the distinction
15:34:29 <stepcut> kstt: yeah. I think checkpointing is a practical requirement for most people
15:34:34 <kstt> indexes are built at reload time
15:34:39 <stepcut> yeah
15:34:39 <kstt> ?
15:35:15 <stepcut> hmm.. I wonder if we do that lazily or strictly
15:35:17 <kstt> in my case, the most evident use of checkpointing is the evolving acidic API
15:35:37 <stepcut> if we do it lazily that could account for some of the RAM usage we see when loading checkpoints
15:39:03 <donri> stepcut: also even without checkpointing if you pass in the tuple as an argument rather than create it in the event?
15:39:10 <stepcut>  so, if you know you are  going to be doing a bunch of sharing, you could try to create safecopy instances that look for it and exploit it
15:39:11 <donri> i'm guessing
15:45:11 <stepcut> yeah.. when it reads the event file back in, it would read it twice
15:45:57 <stepcut> Lemmih: ooo. what's new in 0.6.4?
15:48:54 <Lemmih> Can't get anything past you, can I?
15:49:36 <Lemmih> It will install a keylogger using TH when you try to compile it.
15:50:12 <Lemmih> stepcut: Updates no longer block queries.
15:50:40 <stepcut> Lemmih: nice.. You claimed that was true in the past, but I couldn't see how :)
15:51:23 <stepcut> not saying I can now either.. (but I haven't look yet)
15:52:08 <Lemmih> I sometimes have a difficult time distinguishing between what is and what will be. (:
15:53:51 <Lemmih> You probably won't notice any difference unless you have lots of long running updates.
15:55:06 <stepcut> :)
15:55:21 <donri> http://hdiff.luite.com/cgit/acid-state/commit?id=0.6.4 ;)
15:55:26 <stepcut> when is your job going to pay you to add replication?
15:56:13 <Lemmih> Not for quite a while /-:
15:56:23 <Lemmih> Moving blobs to mongodb is too good a solution.
15:56:35 <stepcut> so, if a long update is going on and other queries are called, they get the value that was present before the update started ?
15:56:43 <Lemmih> Yes.
15:56:49 <donri> i heard mongo has crappy acidity
15:58:05 <Lemmih> You heard right.
16:02:38 <kstt> "moving blobs" == "putting acid-state data files in a mongodb cluster" ?
16:05:26 <Lemmih> No, just moving data from Haskell space into mongodb.
16:17:52 <kstt> ok
16:18:45 <kstt> did they use to rely on acid-state for that ?
16:22:39 <Lemmih> Yeah, everything was in AcidState early in the prototyping.
16:23:26 <Lemmih> The idea is to start with everything in memory and then move stuff out when it no longer fits.
16:34:22 <kstt> ok
17:08:38 <Lemmih> Sigh, turns out that I don't really need non-blocking queries after all.
17:12:26 <stepcut> oh ?
17:12:35 <stepcut> are you going to upload 0.6.5 ?
17:16:06 <Lemmih> Just to disable the feature?
17:16:24 <Lemmih> I'm not that much of an asshole.
17:17:03 <stepcut> :)
17:17:07 <Lemmih> 0.6.4 will just be a freebie for those who want a slightly faster acid-state.
17:17:14 <stepcut> sweet
17:25:41 <stepcut> we should look at vamping the way the crashcourse is built
17:26:06 <stepcut> I think switching to pandoc would be a good move -- then it could automatically be published for the kindle, etc
17:31:55 <donri_> i've been saying that... :p
17:33:04 <stepcut> yup
17:33:54 <stepcut> but now I am starting a new document, and it is a good time to figure out how to do it right :)
17:34:06 <stepcut> waiting for cabal install pandoc to finish
17:34:13 <donri> i don't like gpl either but it's far less important for a "tool"
17:34:36 <stepcut> except that all tools should also be libraries (which pandoc is), and then for the library part, you do care
17:34:54 <donri> sure
17:34:55 <stepcut> but since I only need the executable here, it doesn't matter
17:35:42 <mightybyte> Yeah, Snap sidesteps the GPL issue by just using the pandoc executable.
17:35:47 <stepcut> pandoc would probably be one of my favorite Haskell libraries if it weren't infected
17:35:50 <donri> i don't really like the bastardized markdown either... but pandoc is kinda nice as a tool
17:36:42 <stepcut> mightybyte: that is just a flagrant violation of the author's intensions in chosing GPL in the first place as far as I can tell
17:37:43 <mightybyte> Actually, I discussed with him the possibility of changing to BSD, and he specifically suggested using the executable as a workaround.
17:39:11 <stepcut> yeah, https://github.com/jgm/pandoc/issues/180
17:40:26 <stepcut> but, having to call an executable instead of a type-safe library API is a reason for it to not be on my top 10 list :)
17:41:36 <mightybyte> Right
19:59:33 <stepkut> the site is back up
20:00:12 <stepkut> and the problems that lead to the current failure have been fixed -- though not the core problem of having an incomplete staging system
20:00:16 <bungley> cool, thanks
20:00:27 <stepkut> but it is certainly planned
20:00:53 <stepkut> just not high enough priority yet -- plus all these failures are part of figuring out how to get it working reliably ;)
20:01:20 <bungley> and resilience too? :p
20:01:23 <stepkut> well. 'all these' is a bit much. I think we have had 2 failures so far this year
20:03:43 <stepkut> the current deployment system is actually pretty reliable.. and even more so now!
20:13:38 <donri> and built for debian... needs moar fedora!
20:29:47 <stepkut> :y