00:00:04 <stepcut> it will create, data AddPost = AddPost Text, and that is all that will be serialized
00:00:27 <donri> so it might even be better because the event is smaller?
00:00:41 <stepcut> I do not know if searchTerms will be forced to evaluate before the transaction can complete
00:01:02 <stepcut> I guess.. it does not have to be
00:01:14 <donri> ah, i didn't even think about blocking transactions ... yea that's another point
00:01:30 <stepcut> or maybe it does..
00:01:41 <donri> for that sake it's probably best to keep events minimal
00:02:19 <stepcut> Lemmih said we should read the docs, and then complain if we can't figure out the answer just by reading them
00:02:53 <stepcut> that way he can laugh maniacally and read more hpmor
00:03:39 <donri> i wonder if you could have concurrent non-blocking transactions by calculating "dependencies", like, if an event isn't get'ing thing X then transactions modifying thing X can run concurrently ...
00:03:52 <donri> but that doesn't really work because i'm thinking in terms of lenses not the state monad
00:04:17 <donri> in reality you "get" the whole state every time you get anything, yea?
00:05:31 <stepcut> yeah
00:08:31 <stepcut> if you were clever, you might be able to hack acid-state so that you could do something like row-locking on data structures like ixset
00:08:40 <stepcut> but, you would have to be pretty clever :p
00:09:24 <donri> and the question is if anyone *needs* that at the moment :P
00:09:25 <stepcut> not clear how much that cleverness would ultimately buy you
00:09:29 <stepcut> doubt it
00:09:38 <stepcut> my laptop can do 20,000+ updates per second
00:09:40 <donri> like you said, haskell apps probably have like 30 requests per year, not 9000 per second
00:09:53 <stepcut> which is more than most acid-state apps do in their entire life :p
00:10:40 <mightybyte> My app gets ~100 visitors per day.
00:10:44 <donri> haskell: where apps scale, but are never scaled.
00:11:04 <donri> mightybyte: yea, humerous hyperbole
00:11:05 <stepcut> mightybyte: is 20,000 updates per second fast enough ?
00:11:32 <donri> depends. is java faster??
00:12:01 <stepcut> donri: to be fair, ~100 visitors per day is probably more than most happstack apps
00:12:31 <stepcut> in fact, most probably have 1 visitor (the developer) and never even get launched :)
00:12:36 <donri> :D
00:12:45 <donri> except apps that are used by haskell users
00:12:46 <stepcut> not because of technology problems with acid-state though :p
00:12:49 <donri> like patch-tag or later hackage2
00:13:05 <stepcut> hackage2 doesn't even get 100 visitors per day
00:13:08 <stepcut> patch-tag might
00:13:19 <donri> i said later as in "when having replaced hackage1"
00:13:33 <stepcut> ah
00:13:36 <donri> hacakge1 probably gets 100 visits a day from me alone
00:13:55 <stepcut> I was out drinking til the sun came up.. so my reading comprehension is not so great today
00:14:05 <donri> +1
00:14:19 <donri> suddenly! beer craving out of no where :(
00:14:26 <donri> and it's 1am here
00:16:16 <stepcut> :3
01:54:03 <donri>     Can't make a derived instance of `SetAttr (YNode a)'
01:54:03 <donri>       (even with cunning newtype deriving):
01:54:03 <donri>       `SetAttr' does not have arity 1
01:54:08 <donri> <3 ghc error messages
01:55:07 <stepcut> :3
01:56:04 <donri> standalone deriving perhaps?
02:06:16 <stepcut> i don't see how that would help
02:56:32 <stepcut> donri: did you ever figure out how to use the jmacro type checker?
02:56:54 <donri> i asked author, answer is "don't" :)
02:57:45 <stepcut> hah
03:06:18 <donri> bedtime
07:26:07 <dmitrymatveev> hi all!
08:31:21 <dmitrymatveev> I've decided to use MongoDB with Happstack
08:31:56 <dmitrymatveev> to query the DB from the handlers, the handler types were modified to
08:31:56 <dmitrymatveev>  
08:31:56 <dmitrymatveev> RouteT Sitemap (ServerPartT (Action IO)) Response
08:32:31 <dmitrymatveev> Action m is a monad to access the DB
08:32:58 <dmitrymatveev> however, I receive the following error:
08:32:59 <dmitrymatveev>  
08:32:59 <dmitrymatveev>     Couldn't match expected type `IO' with actual type `Action IO'
08:32:59 <dmitrymatveev>     Expected type: Site Sitemap (ServerPartT IO Response)
08:33:01 <dmitrymatveev>       Actual type: Site Sitemap (ServerPartT (Action IO) Response)
08:33:05 <dmitrymatveev>     In the third argument of `implSite', namely `site'
08:33:09 <dmitrymatveev>     In the expression:
08:33:12 <dmitrymatveev>       implSite (pack "http://localhost:8000") (pack "") site
08:33:46 <dmitrymatveev> how the implSite should be invoked to support the Action IO in the bottom of stack?
15:54:08 <stepkut> dmitrymatveev: you probably need mapServerPartT to flatten the (Action IO) into IO ?
15:55:33 <hpaste> stepcut pasted “mapServerPartT example” at http://hpaste.org/65947
15:55:53 <stepkut> that comes from some other code, but the same basic idea
18:47:34 <Lemmih> stepkut: I might choose not to do GSoC this year.
18:47:44 <Lemmih> stepkut: Depends on work.
19:16:53 <stepcut> Lemmih: k
19:23:24 <donri> stepcut: why does your acid-state benchmark use mvars? doesn't that slow it down misleadingly
19:23:53 <stepcut> donri: you got a better idea?
19:24:02 <donri> not sure what the point is :)
19:24:33 <donri> sorry, i wasn't clear: I'm asking honestly, not proposing otherwise
19:24:38 <donri> why are the mvars needed?
19:25:49 <donri> does it have to do with laziness or something
19:26:11 <stepcut> it forks 100,000 threads which operate independently. I don't want to do the ending 'query' until all the updates have completed
19:26:46 <donri> oh right, it creates threads... totally missed that
19:26:50 <stepcut> :)
19:27:04 <donri> ironically i was even thinking "shouldn't you test this concurrently"
19:27:09 <stepcut> :)
19:27:13 <donri> ACTION facepalm
19:27:23 <stepcut> is 100,000 threads enough concurrency for you ?
19:27:38 <Lemmih> Using schduleUpdate would be faster but I guess that's cheating.
19:27:39 <donri> depends, is it more concurrent than java??
19:28:07 <stepcut> Lemmih: yeah. That is testing something different. There should be a test for that as well though
19:28:20 <stepcut> there are many different tests that are missing :)
19:28:35 <stepcut> I just wanted to start with two good ones for putting into sales literature
19:29:06 <donri> how did it compare to sqlite then
19:29:08 <Lemmih> Is the SQLite thingy still 2k times slower?
19:30:01 <stepcut> donri: my sqlite implementation takes 8 seconds to do 100 updates. and the acid-state version takes 4 seconds to do 100,000
19:30:11 <stepcut> donri: but I could be doing sqlite wrong
19:30:31 <donri> also should have benchmarks for higher level SQL wrappers like persistent "et al" (wink wink) since those are slower than raw SQL
19:30:41 <stepcut> donri: I need someone who knows what they are doing to look at the sqlite version
19:31:08 <donri> you don't seem to be using +RTS -N?
19:31:25 <stepcut> donri: that is up to you when you run it
19:31:37 <donri> oh wait you're using 7.4 where -N doesn't require -rtsopts
19:31:38 <stepcut> donri: I didn't though.. I believe it is IO bound anyway
19:31:55 <stepcut> donri: but, I should test and see
19:31:58 <donri> +1
19:32:12 <stepcut> that is really all stuff that should go into the tests and reporting (via criterion)
19:32:21 <Lemmih> Where's the SQLite benchmark code again?
19:32:42 <donri> -with-rtsopts=-N is useful for GHC-Options :)
19:32:50 <stepcut> Lemmih: http://patch-tag.com/r/stepcut/acid-state-benchmarks
19:33:06 <stepcut> http://patch-tag.com/r/stepcut/acid-state-benchmarks/snapshot/current/content/pretty/counter/sqlite3/Main.hs
19:35:21 <Lemmih> Looks like it should be as fast as acid-state.
19:35:43 <stepcut> yeah
19:35:59 <stepcut> if there were in the same ballpark I would think I was doing things right
19:36:11 <stepcut> such a big difference does not give me confidence
19:36:15 <Lemmih> I get a segmentation fault...
19:36:29 <stepcut> :-/
19:36:39 <Lemmih> Do I need to init something?
19:36:46 <stepcut> no
19:37:04 <stepcut> it needs write access to the CWD, but that is it
19:37:08 <parcs`> the WAL
19:37:15 <stepcut> maybe the bindings are broken
19:37:21 <stepcut> WAL?
19:37:46 <parcs`> the WAL is faster than sqlite's default mechanisms.. perhaps you should enable that in the database that you're testing with
19:38:26 <stepcut> ah
19:38:29 <parcs`> also there are a ton of haskell sqlite bindings. maybe the one you're using has some kind of horrible deficiency. 100 updates in 8 seconds is unrealistic
19:38:54 <stepcut> parcs`: yeah, I wondered that as well
19:39:13 <stepcut> parcs`: someone who actually uses SQL would be a better choice to implement these tests than me :)
19:39:57 <stepcut> of course, that is one of the benefits of acid-state. You can get optimal performance with out having to learn about all these crazy options :p
19:40:21 <donri> maybe it'd be most interesting to compare to whatever is commonly used with snap and yesod
19:40:33 <parcs`> sqlite is also pretty horrible at concurrent writes. i suspect acid-state will probably win in all cases
19:40:36 <donri> that's what people are going to be wondering about
19:40:44 <stepcut> yeah
19:40:55 <donri> parcs`: it's not a question if acid-state will win, but rather by how much :)
19:41:01 <Lemmih> stepcut: I don't think it's thread-safe. Replacing 'forkIO' with 'id' fixes the problem.
19:41:09 <stepcut> Lemmih: ah
19:41:23 <stepcut> Lemmih: seems pointless to have a non-threadsafe database library binding
19:41:53 <stepcut> benchmarks are hard :)
19:41:56 <donri> or it is thread-safe but just bad at it as parcs` said?
19:42:03 <parcs`> it's thread safe
19:42:06 <parcs`> but bad
19:42:11 <parcs`> with yesod+persistent+sqlite, 15 concurrent writes causes 90% of connections to fail
19:42:21 <donri> ^_^
19:42:29 <stepcut> donri: in this case, Lemmih got a seg fault..
19:42:40 <donri> you didn't :)
19:42:42 <donri> could be lib/ghc
19:42:54 <Lemmih> I'm on mac.
19:43:00 <donri> i think sqlite itself is supposed to at least *work* concurrently
19:43:13 <parcs`> acid-state blows sqlite out of the water. i suggest you benchmark more performant dbs like postgres
19:43:27 <stepcut> yeah, I just didn't want to install postgres at the time
19:43:50 <donri> you can be "thread safe" by simply blocking all but one thread :P
19:43:56 <stepcut> but, in the GSoC idea I posted I suggested, sqlite, postgres, mongodb, and redis
19:44:05 <donri> redis is going to be interesting
19:44:17 <donri> particularly compared to acid-state's remote backend
19:44:22 <parcs`> but those kinds of benchmarks will be disingenuous because postgres vastly more complex than acid-state... have you benchmarked redis yet? :P
19:44:26 <donri> those setups are similar
19:44:46 <stepcut> sqlite is a useful comparison because it is doesn't require a separate server (unlike postgres), which gives it some of the convenienced of acid-state (but not the performance)
19:45:08 <stepcut> parcs`: not sure that 'vastly more complex' is a selling point :p
19:45:24 <parcs`> hehe, i meant featureful
19:45:49 <stepcut> why is that disingenuous?
19:46:22 <Lemmih> stepcut: Running both test without forkIO for n=10000: SQLite finishes in 7.7s, AcidState in 1.9s.
19:47:01 <stepcut> Lemmih: yeah. That is similar to what I get. acid-state gets a gigantic bump in performance with the forkIO
19:47:19 <stepcut> Lemmih: for reasons I can only partially explain :p
19:47:54 <Lemmih> Why isn't it obvious?
19:48:57 <Lemmih> (That might have sounded condescending, sorry. I want to figure out how to explain it better.)
19:49:07 <stepcut> Lemmih: because.. it is not clear how acid-state can bunch transactions together and still maintain durability. And, for example, if there was a query after every update, would that kill performance?
19:49:19 <stepcut> seems like a 'query' can not return until the 'update' is known to be durable
19:49:35 <Lemmih> stepcut: That is partly correct.
19:50:09 <Lemmih> If you say 'Do UpdateA /then/ QueryB' then the update will have to be serialized before the query can be completed.
19:50:17 <stepcut> obviously, there is some performance improvement on multicore, because parts of the update that do not require the database to locked can be done in parallel
19:50:26 <stepcut> right
19:50:51 <Lemmih> But if you say 'Do UpdateA and QueryB in parallel' then the query can be run against the previous state which has already been committed.
19:50:55 <stepcut> that Is what i meant, do update acid IncCounter ; query acid GetCounter
19:51:08 <stepcut> right
19:52:02 <Lemmih> And if you say 'Do UpdateA and UpdateB in parallel' then AcidState is free to group those events together in any order it feels like.
19:52:38 <stepcut> right
19:53:24 <Lemmih> So saying 'do A and B in parallel' is much faster than saying 'do A and then do B'.
19:53:28 <stepcut> but it doesn't just sit around waiting to see if anything else is going to come in that could be grouped, right ?
19:54:56 <Lemmih> It writes to disk as soon as there's anything to write. If then 10 new events have been created in the time span it takes to do a write, those 10 new events can be grouped together in the next write.
19:55:33 <stepcut> k
19:56:07 <stepcut> that makes sense
19:56:21 <Lemmih> 100,000 parallel transaction might be written like this: group of 1 <flush> group of 100 <flush> group of 1000 <flush> group of 20 <flush> and so on.
19:57:35 <stepcut> so in the case where I do, replicateM 1000 $ forkIO  $ do update acid IncCounter ; query acid GetCounter,  those Updates can still be grouped -- but the queries will have to wait until the update that was partnered with them actually got flushed to disk?
19:57:49 <Lemmih> And the size of what we write to disk is pretty much irrelevant. Only the flushes matter and two flushes are pretty much twice as slow as one flush.
19:58:06 <Lemmih> stepcut: Yep.
19:58:09 <stepcut> nice
19:58:22 <stepcut> great work :)
19:58:33 <Lemmih> Thanks. I like it very much as well. (:
19:59:14 <stepcut> and it is only ~2000 lines of code including comments, imports, and whitespace :p
19:59:30 <stepcut> suck it postgres :p
19:59:51 <stepcut> i gotta make a cake, bbl
20:00:13 <Lemmih> When you have to make cake, you have to make cake. See ya.
20:21:50 <donri> really should put HasAcidState and associated functions into acid-state or at least a separate package
20:25:26 <hpaste> donri pasted “maybe this too, using data-default” at http://hpaste.org/65957
20:28:12 <Lemmih> Make your case.
20:28:57 <Lemmih> I don't believe checkpoints should be created willy-nilly.
20:29:07 <donri> OK
20:29:15 <donri> still a bracket open/close could be neat ;)
20:29:21 <donri> anyway that one is optional convenience
20:29:46 <Lemmih> Why?
20:29:46 <donri> but HasAcidState should really have one official definition so that third-party code can work together
20:29:58 <Lemmih> Why bother closing the acid-state?
20:30:14 <donri> not necessary?
20:30:33 <Lemmih> Of course not. You should always assume that your problem will crash.
20:30:34 <donri> it's usually good practice with things that *can* be closed
20:32:31 <Lemmih> Checkpoints trade CPU time for hard drive space. Not always a good trade.
20:34:39 <donri> i would expect disk space to be cheaper, but OK
20:35:23 <donri> if you're going to fit it in ram anyway ^_^
20:35:31 <donri> though i guess that's only relevant if you also create archives ...
20:39:27 <stepcut> if I am shutting down my server, it is most likely because I am upgrading newer version of the server -- in which case I want a checkpoint in case any of the event methods have changed
20:41:10 <Lemmih> That only works with a single server. Once you're using a cluster, things get a little bit trickier.
20:41:48 <stepcut> yes
20:41:58 <stepcut> once you make clustering a reality, I'll worry about that :)
20:42:03 <Lemmih> Ideally you wouldn't change methods. You'd just add new methods and deprecate the old ones.
20:42:15 <stepcut> yeah
20:42:21 <donri> the point of withState though sorta is convenience particularly for early dev
20:42:24 <stepcut> that is the only sensible solution for a cluster
20:42:51 <stepcut> but I don't know that applying the same policies to a cluster and a single server makes sense
20:43:15 <Lemmih> donri: If I add it to the library then people will think that it is recommended over explicit open/close.
20:43:23 <donri> it gets the state location via Typeable, the initial state from Default and it doesn't do remote backend (unless a separate withState is added to remote) but the point is "get up and running with minimal code"
20:43:32 <donri> fair enough
20:43:33 <stepcut> I am not arguing for the inclusion of withState in acid-state, btw. even though I use it :)
20:44:00 <Lemmih> I might be tempted to add the non-checkpointing version, though. Especially without the defaulting.
20:44:26 <donri> aww, but i so like Default ;)
20:44:35 <stepcut> personally, I would prefer a version with checkpoint, but not defaulting
20:44:39 <donri> that's my own addition to stepcut's idiom though
20:44:50 <stepcut> but, that is just another argument against having any version in there at all :)
20:44:58 <stepcut> everyone wants something a little different :p
20:45:27 <donri> so perhaps in the end it's best that we just add it to our own apps
20:45:31 <donri> as we do now
20:45:36 <donri> was just a thought anyway :)
20:46:34 <donri> as for non-checkpointing, non-defaulting; if closing isn't all that useful then what is the point of bracketing?
20:48:17 <stepcut> anyway, happstack needs a higher level plugin architecture that includes proper resource finalization.. which would probably be an alternative to withState for happstack apps anyway :P
20:49:08 <donri> perhaps, though i somewhat like how happstack development doesn't make you hide everything in a happstack-centric API
20:49:15 <stepcut> right
20:49:30 <donri> it's just another component in your app
20:49:31 <stepcut> so obviously there should be happstack, and then there should be something else built on top of it
20:50:33 <stepcut> i think there should be happstack, which gives you lots of choice and flexibilty. And then there should be another library built on top of it that says, "use this template system, database, plugin architecture, etc. and you get all these other things for free"
20:51:11 <donri> perhaps a generic plugin architecture similar to snaplets, perhaps with support for the plugins package, that can be used with happstack, is possible?
20:51:23 <stepcut> probably
20:51:31 <stepcut> that is actually why I wrote web-routes in the first place
20:51:47 <donri> i'm continuously amazed by how well designed web-routes is
20:51:51 <stepcut> I thought, "I need plugins". Then I thought "plugins need unique, composable  urls"
20:52:11 <stepcut> and then working from that I determined that type-safe urls where the way to get what I wanted
20:52:26 <stepcut> and then I have been too busy to add the rest :p
20:52:31 <donri> )
20:52:32 <donri> :)
20:53:17 <stepcut> the snaplets monad actually feels a lot like the web-routes monad, which is interesting
20:53:25 <stepcut> nestSnaplet vs nestURL, etc
20:53:36 <donri> haven't really looked at snaplets, or nestURL
20:54:12 <stepcut> I looked at snaplets, and then filed some bug reports :p
20:54:38 <stepcut> i need to look at what yesod does as well
20:54:40 <donri> "i put a snaplet in your snaplet so you can snap while i let out yo' dawg"?
20:54:53 <stepcut> though, I think it is one of those areas where everyone arrives at more or less the same solution
20:55:46 <stepcut> I guess that is the beauty of math...
20:55:49 <donri> yea, it could probably be somewhat generalized beyond both particular "frameworks" like happstack and perhaps even beyond web dev
20:56:29 <donri> let's make a "component architecture" á la zope ;)
20:57:13 <stepcut> I've never used zope (or python for that matter)
20:57:54 <donri> half-joking because people tend to find zope and the ZCA overengineered java-style
20:58:59 <donri> FinalizableResourceFactoryFactory -- there, "bracket"!
21:00:12 <stepcut> putting together a playlist for my birthday party.. I think it is going to be all obscure covers of popular songs
21:00:37 <donri> perhaps a good starting point is to think of something that works for both happstack and ircbot, at the same time ...
21:00:49 <stepcut> yeah
21:01:12 <stepcut> working on happstack and ircbot is interesting.. because it is interesting how many things *do not* port well from one to the other
21:01:42 <donri> like request->response vs frp?
21:01:54 <stepcut> like, trying to apply happstack style server parts to ircbot did not work that well .. at least not at first, because irc is persistent instead of stateless, and you can have more than one handler for an incoming message, instead of only one, etc
21:02:20 <stepcut> I think an frp ircbot would be worth trying
21:02:29 <stepcut> as long as someone else is doing the trying ;)
21:02:43 <donri> i don't quite grok what frp even *is*, but from what i've heard it sounds like exactly the sort of thing that works for irc bots
21:03:08 <stepcut> yeah
21:03:36 <stepcut> FRP is also difficult to get right in Haskell.. there were some papers claiming you needed something like Agda to do it right :p
21:03:40 <donri> let's write an frp irc bot using pipes and attoparsec just so we can circlejerk about how awesomely well-designed it is
21:04:20 <stepcut> :)
21:04:32 <stepcut> well, for the real circle jerk, we would finish my agdabot
21:04:43 <stepcut> then we can prove it is awesome
21:05:12 <donri> :)
21:16:08 <donri> i think i'm becoming more comfortable with darcs. still miss in-repo branches and sendmail is way too complicated to configure for gmail (i googled it) though.
21:16:56 <stepcut> yeah
21:17:07 <stepcut> I can't argue with that
21:17:15 <donri> i figured out some hacks to make darcs less "plain": i have colored diffs and logs
21:17:24 <stepcut> :)
21:17:40 <donri> logs by piping them to vim :D with filetype=changelog
21:17:54 <donri> diffs via pygments. there's colordiff too but it doesn't look as good actually.
21:18:20 <stepcut> darcs send made more sense when it was common to have a working sendmail install .. which is only getting less and less common
21:18:34 <donri> yea, *if* that worked it could be neat, i guess
21:19:14 <donri> i read most of the best practices chapter in the user manual. there's some cool setups you can have with mail too ...
21:19:20 <stepcut> it's neat because it lowers the barrier of submitting a patch. You don't have to fork the repo, or have a public mirror. You just do darcs get ; darcs record ; darcs send
21:19:28 <stepcut> and then you can delete your repo once the patch is accepted
21:19:40 <donri> well, today it just hightens the barrier :P
21:19:42 <donri> but yea
21:19:50 <stepcut> i feel 'bad' everytime I have to fork some github repo just to submit a few lines of changes
21:20:04 <stepcut> now that github repo will exist for all time even though it is no longer needed
21:20:13 <donri> for small things you can make the change right there on the website
21:20:27 <donri> and you can delete repos after the changes are pulled
21:20:35 <stepcut> yeah.. github exists to cover up how sucky git is :p
21:20:43 <donri> but, yes :) if send works it's neat
21:20:55 <donri> well git has mail sending too
21:21:08 <donri> haven't used it but i think the kernel is developed that way?
21:21:25 <stepcut> i never got it to work correctly.. and I think a lot of git developers have no idea what to do with a patch they receive that way
21:21:50 <donri> git am? assuming you have a maildir or whatever those are called ...
21:22:02 <donri> is darcs any different?
21:23:18 <stepcut> you just do, darcs apply path-to-patch.dpatch. The difference is that a lot of maintainers who use darcs have actually recieved darcs patches by mail before and know that :p
21:23:42 <donri> ;)
21:24:09 <stepcut> I am tired of revision control systems anyway
21:24:15 <stepcut> I used to be a contributor to TLA :)
21:29:19 <donri> perhaps a wishlist for darcs could be a way to configure darcs send to do an http upload somewhere, or something like that
21:30:22 <donri> sites like patch-tag could even present that as a patch queue with notifications and everything
21:30:32 <stepcut> yeah
21:30:53 <stepcut> I'm going to propose that in #darcs right now :p
21:30:57 <donri> :)
21:31:03 <donri> i'm gonna spy
22:28:14 <donri> stepcut: another thing about darcs send... hard to know if it actually got sent properly. with github i can see my fork right there on the site, i can see the pull request.
22:28:30 <donri> so in any case 'send' must be much more reliable for verifying it got sent or not ...
22:29:10 <donri> i think that's what subconciously scared me before 'darcs send' even failed on me
22:31:41 <donri> can't check afterwards if it sent, or what it sent
22:33:30 <stepcut> yeah
22:34:44 <donri> not sure how to solve that
22:35:00 <donri> one way is if prefs/author is a public ML
22:35:22 <donri> though that's kinda scary! :D
22:35:31 <donri> almost *too* public ;)