--- Log opened Thu Jan 22 06:29:53 2009
--- Log closed Thu Jan 22 06:30:16 2009
--- Log opened Thu Jan 22 06:30:37 2009
--- Log closed Thu Jan 22 06:31:56 2009
--- Log opened Thu Jan 22 06:32:21 2009
--- Log closed Thu Jan 22 06:34:55 2009
--- Log opened Thu Jan 22 06:35:38 2009
--- Log closed Thu Jan 22 06:35:51 2009
--- Log opened Thu Jan 22 06:39:26 2009
06:50 < aovcharenko> ping
07:11 < hugo___> :P
07:11 < hugo___> aovcharenko: pong
07:11 < aovcharenko> heh, works ;)
11:27 < thomashartman1> this is a test of logging.
11:27 < thomashartman1> hoorah. logging works.
11:27 < wchogg> woo!  log-test!
11:27 < thomashartman1> will send matt details so he can get this public under happstack.
11:50 < sm> morning
11:51 < wchogg> Hello
11:51 < wchogg> It's still a bit quiet in here
11:51 < Saizan> hi
11:54 < thomashartman1> wchogg: feel better now?
11:54 < wchogg> thomashartman1 : yes, I'm considerably less gassy.
11:55 < wchogg> thomashartman1 : BTW, is the activation e-mail for patch-tag working?
11:56 < sm> worked for me, but slowly
11:56 < sm> I think there's a fleshy component
11:56 < wchogg> slave labor?
11:57 < sm> er, meant in a good way thomashartman1
11:57 < Saizan> mmh patch-tag is not really googlable
11:57 < sm> no it isn't
11:57 < wchogg> Sorry, I knew what you meant I was just being absurd.
11:59 < sm> yes, I was apologising for calling him fleshy
11:59 < sm> we'll just talk amongst ourselves till he gets back :)
11:59 < thomashartman1> saizan: ya think patchtag would have been better?
12:00 < thomashartman1> I had the logo both ways... just thought it looked better with the hyphen for some reason.
12:00 < thomashartman1> (patchtag redirects to patch-tag at the moment)
12:00 < thomashartman1> sm: how slowly?
12:01 < sm> I forget.. maybe 15, 30m
12:01 < thomashartman1> m=miliseconds?
12:01 < sm> iirc
12:01 < sm> minutes
12:01 < thomashartman1> 30 minutes to fetch a page?
12:01 < thomashartman1> uh oh.
12:01 < sm> no, to receive the password email
12:01 < sm> I'm not that patient :)
12:02 < thomashartman1> mm, yeah, this email thing is becoming a bottleneck.
12:02 < thomashartman1> in my experience email usually gets sent within the minute but it sporadically takes longer. not good.
12:02 < Saizan> thomashartman1: i actually get more results with patchtag, so it's just that it's not linked from anywhere so it has a low pagerank
12:03 < thomashartman1> saizan: oh I thought you meant not googleable as in, awkward to search on because of the hyphen
12:03 < sm> I think patchtag would be better. It's still slightly obscure imho
12:03 < sm> any other contenders ?
12:03 < thomashartman1> github obviously :)
12:03 < sm> I kind of liked patchshack
12:03 < sm> what about simple darcshub ?
12:03 < thomashartman1> patchshack.com sells boy scout meritbadges unfortunately
12:03 < sm> boring but clear
12:03 < sm> oh
12:03 < thomashartman1> (I had patch-shack)
12:03 < thomashartman1> darcshub is owned by github
12:04 < sm> ACK
12:04 < thomashartman1> and even if it wasn't... kind of copying.
12:04 < sm> but it is a copy.. nothing wrong with that
12:04 < thomashartman1> well, they own it :)
12:04 < thomashartman1> darcsweb.com but it's kinda boring, and there's already an unrelated project called that which didn't register the domain
12:05 < sm> darcshut :)
12:05 < thomashartman1> I don't want to rely too heavily on darcs branding.
12:05 < sm> I hear you
12:05 < sm> though it's nice for the darcs project
12:05 < thomashartman1> since to have a whispers chance of commercial success eventually need to expand beyond that.
12:05 < thomashartman1> Probably either gonna be patchtag or patch-tag.
12:05 < thomashartman1> probably gonna be patch-tag :)
12:06 < thomashartman1> since I have about 80 other fires to put out without screwing around with the name even more.
12:11 < thomashartman1> anybody here remember offhand how to install ghc as non-root user?
12:11 < Saizan> very nice project anyhow :) are you using darcs via the library or just calling the executable directly?
12:11 < thomashartman1> oh I think I found it
12:12 < thomashartman1> just calling exe
12:12 < thomashartman1> it's pretty much all a wrapper over shell commands
12:12 < thomashartman1> which I'm managing with hsh
12:12 < thomashartman1> since I'm planning on hopefully supporting other vcs eventually figured that made more sense
12:13 < thomashartman1> sm: also considered darcside. but taken.
12:13 < sm> oh, shame, that was catchy
12:13 < Saizan> i wonder if gitit's filestore interface can be of any use to present statistics etc..
12:13  * sm votes +1 for gitit integration
12:14 < thomashartman1> sm: for patch-tag?
12:14 < sm> yes, I think it would make sense. gitit is nearly ready for real use over darcs
12:15 < thomashartman1> I'm exploring that possibility with benja.
12:15 < sm> it's equivalent to a nicer trac, without the issue tracker
12:15 < thomashartman1> (As you may recall that's the project I announced to happs list)
12:15 < sm> gwern and I have been working on it the last day or so
12:15 < thomashartman1> have you pinged benja about this?
12:15 < sm> I don't know benha
12:16 < sm> benj
12:16 < sm> a
12:16 < thomashartman1> i'll introduce you via email
12:18 < Saizan> tbh, gitit's code looked quite scary to me, two huge modules with huge impure functions inside
12:18 < Saizan> not really haskelly
12:18 < sm> oh it's kind of refreshing to work on a wiki in one module (haven't noticed the second)
12:18 < gwern> Saizan: true. but better to have something working well which can be refactored than to have nothing at all
12:19 < sm> john mcfarlane is also the author of pandoc and others, so I think it can improve when he needs it to
12:19 < gwern> although 1200loc in one module is admittedly a bit much, I think it's mostly because there's a lot in there which was written when needed and john hasn't pushed bits upstream or out into modules
12:19 < Saizan> gwern: sure, but if you start with a bad codebase it's hard to see opportunities for better code when you add to it
12:20 < gwern> for example, I think happs should provide functions for gzipping HTML and for adding cache/expiry headers; gitit shouldn't've to do it itself
12:20 < Saizan> yeah, that too
12:20 < Saizan> and modules for dealing with sessions and  users
12:21 < sm> gitit is a great driver for happs improvement
12:21 < sm> something happs has really needed
12:22 < mightybyte> Saizan: I've been improving my module for users and sessions that I'm using for my site.
12:22 < mightybyte> Saizan: Once I have it a little more mature, I'll definitely contribute it.
12:22 < gwern> Saizan: but hey, if you think gitit is bad now, you should be grateful I pushed for a filestore lib and took out about 1200loc from gitit :)
12:22 < thomashartman1> Benja has created meta-gitit as sort of experimental project for me.
12:22 < thomashartman1> (will be open source)
12:23 < Saizan> mightybyte: do you have a repo? it could be a good package on hackage
12:23 < thomashartman1> exploring the idea of whether it's feasible to build on gitit for something that patch-tag can use as user-configureable wiki / issue tracking
12:23 < sm> yay gwern
12:23 < Saizan> i think we should have plenty of "plugins" happs packages around :)
12:23 < mightybyte> Saizan: Not right now.  It's just in the code I'm developing for my site.
12:24 < sm> Saizan: absolutely
12:24 < mightybyte> Although it is separated out in a relatively modular fashion.
12:24 < sm> how to manage the explosion will be a challenge
12:24 < sm> clear interfaces I guess
12:25 < sm> and nice cabal packages
12:25 < Saizan> mightybyte: yeah, that's a nice strategy to produce small libs
12:25 < Saizan> oh
12:25 < Saizan> another project that might drive happs is the new hackage-server
12:25 < thomashartman1> problem with gitit is not easy to modify templates, so hard to add it as "feature" to a branded site like patch-tag.
12:25 < mightybyte> I'm not sure where it will end up going in HAppS, but hopefully it will fit somewhere.
12:26 < mightybyte> This is just something that needs to be present in a mature framework.
12:26 < wchogg> Hrmm...so should the examples subdirectory of HAppS-Server get moved into yet another seperate package?  I'm trying to get rid of the State dependency.
12:27 < Saizan> btw, anyone has tried multimaster recently?
12:30 < gwern> what is multimaster?
12:30 < mightybyte> gwern: Data replicated on different servers to increase reliability and scalability.
12:30 < Saizan> the ability to have multiple happs process dealing with the same state
12:30 < Saizan> *processes
12:31 < mightybyte> Saizan: Is multimaster supposed to work across machines?
12:31 < gwern> mightybyte: ah.
12:31 < Saizan> yeah, that's the point, no?
12:31 < mightybyte> Ok, thought so.
12:31  * gwern decides that's not useful for gitit anytime in the foreseeable future and ignores this multimaster discussion
12:31 < mightybyte> Just checking
12:32  * Saizan never actually tried it
12:32 < mightybyte> gwern: Yeah, my site is nowhere near needing it either.
12:33 < Saizan> it's still nice if you want to manipulate the state with an external tool, instead of going via the web api, i think
12:33 < mightybyte> Oh, true.
12:33 < mightybyte> Hmmm, there may be ways I can use that.
12:33 < mightybyte> But it's still a ways away.
12:34 < mightybyte> I'm still working on the underlying data model and CRUD functionality, which is fairly complex.
12:38 < gwern> sm: my gzip changes have made it into gitit HEAD
12:38 < gwern> if you want to try it out
12:44  * gwern is pleased with HEAD performance currently. it's nice to see the first page load by 0.8s then 0.3s and then 0.2s
12:57 < sm> yay
13:31 < gwern> sm: how welldoes gzip work for you?
13:31 < sm> gwern: haven't tested it, sorryu
13:31 < gwern> bah
13:31 < sm> but I'm assuming it's awesome
13:32 < gwern> it's been cleaned up and is available in head, all you have to do is git pull and reinstall, and you won't do it? :(
13:32 < sm> nope, I'm busy
13:32 < gwern> (despair! the internets have driven me to despair!)
13:32 < sm> need a solution for file types!
13:32 < sm> and git!
13:32  * sm pulls hair
13:33  * gwern hangs self
13:52 < sm> oh, there is.. see happstack.com
13:52 < gwern> sm: there is no happstack repo?
13:52 < gwern> I thought we were supposed to be using happstack now
13:53 < sm> personally, it's too early to churn the code, but feel free
13:53 < gwern> matthew wants my gzip code, and I'd like it out of gitit
13:53 < sm> what's the hurry ?
13:54 < gwern> his request is taking up space in my email box, and the switch should be relatively easy
13:55 < sm> well there's a nice combined happstack repo.. it discarded all prior history, alas
13:55 < gwern> hm. so do I work against it?
13:56 < gwern> and why did it discard history? that was unnecessary. just pull from all the branchs and do a few mass darcs mvs...
13:56 < sm> wchogg has already sent a few patches against it to the list, I think
13:56 < sm> gwern: I don't think you could darcs pull those repos into one
13:56 < sm> could you ?
13:56 < gwern> why not?
13:57 < gwern> pick an arbitrary one - begin, say. cd inside it, do a mkdir begin, darcs add && record begin, darcs mv * begin/; then pull from, say, happs-server. now ./ is full of happs-server stuff. do a mkdir happs-server/....
13:58  * gwern did just this with my personal wiki's repo, to pull from my original document repo
13:58 < sm> interesting, you might want to post on list, the repo split is being discussed
14:05 < Saizan> is the history of any use, once you've it mangled like that?
14:05 < gwern> Saizan: yes. remember darcs tracks files through renames
14:06 < gwern> (turns out git doesn't by default, interestingly)
14:06 < gwern> Saizan: so if you rename begin/foo to begin/begin/foo, and you do a darcs changes begin/begin/foo, you'll see all the history you'd expect to
14:06 < gwern> if you follow me
14:07 < Saizan> yeah
14:09  * Saizan wonders if darcs will realize most of the patches are the same ones
14:10 < sm> the repos were originally one of course.. they share the same history for the first couple of years
14:10 < sm> eg HAppS-State was split off with Thu Aug  9 19:11:02 PDT 2007  shae@ScannedInAvian.com
14:10 < sm>   * move HAppS.MACID.* to HAppS.State.* and put it into its own cabal package and darcs repository.
14:10 < Saizan> that's what i was referring to
14:10 < gwern> I don't really have an opinion on the topic. having one repo makes it easier to follow development of course, but I wonder how well it works for active development - scaling, conflicting patches, etc.
14:11 < Saizan> the main problem for me after the split was rebuilding only what was necessary
14:12 < Saizan> and putting things back into one repo but with distinct packages is not going to help
14:13 < sm> Saizan: how do you mean ? how did the split cause you a problem ?
14:15 < gwern> sm: I think he's referring to 'i make a change in -state and reinstalled, but now server and begin are still installed against the unmodified -state
14:15 < sm> I'm thinking it might have been smarter if they'd kept it as one repo, but generating multiple hackage packages - like the happstack repo
14:15 < gwern> whereas if happs were one single .cabal file, he'd do a clean && build && hinstall, and everything would be linked against the latest
14:16 < gwern> of course, this does mean duplicated work and means other people can't depeond on only a part of happs...
14:16 < Saizan> without the clean, actually :)
14:16 < Saizan> but ghc is smarter about rebuilding now, so it shouldn't be a problem anymore
14:16 < gwern> I've been bitten enough times by not cleaning that I've taken an absolutist position on it
14:17 < sm> maybe linking is slower with a monolithic happs ?
14:18 < gwern> it seems kind of sad that with oen of the best DVCSs around, we're still throwing away the history...
14:19 < sm> I'm not *absolutely* against that.. it's radical, but sometimes radical is the quickest way forward
14:19 < sm> I'm not so sure your merge scheme will actually work, and not have a heavy conflictful repo ? would have to see it
14:20 < sm> definitely interested in this discussion about what's easiest to work with going forward though
14:20 < gwern> sm: why don't you try it? I merged begin & dns to see whether it worked as I remembered, and it did
14:22 < gwern> and where would the conflicts be? unless the repos had subdirectories that were names of the new-repo-directories (ie I move begin's content to begin/, pull happs-server, and for some crazy reason happs-server had a bunch of files currently stored in a begin/)
14:22 < sm> I don't fully understand it
14:22 < gwern> try it out then. it makes much more sense when you do it than when I explain it
14:36 < mae___> hey guys
14:36 < mae___> I wanted to come in and informally discuss the issues regarding the monolithic repository
14:36 < mae___> anyone around?
14:37 < sm> hi mae___
14:37 < mae___> hi there
14:38 < sm> before you jump in, any luck reaching alex by phone ?
14:38 < mae___> not so far
14:38 < sm> I think it's better I don't stick my nose in, but I'll try if you want me to
14:39 < sm> I would feel better about the fork, name etc. if we could here from him and know for sure if we can reclaim/update any of the existing web presence, that HAppS is not going to come back from the dead, etc.
14:39 < sm> hear
14:42 < mae___> good news
14:42 < mae___> i just got a hold of alex
14:42 < sm> \o/
14:45 < gwern> and?
14:47  * sm looks forward to alex's post
14:47 < mae___> 1 sec
14:51 < mae___> and he says he doesn't have time right now
14:52 < mae___> he wants someone else to take it over for now, with the possibility of coming back
14:52 < mae___> so he should give ownership of the mailing list and/or google code etc to me or lemmih
14:52 < mae___> but that has yet to be seen
14:55 < wchogg> Well, at least that's something.
14:55 < mae___> yep
15:01 < wchogg> thomashartman1 : so you want there to be just one darcs & only one or two cabal packages?
15:05 < mightybyte> mae___: I'm here
15:05 < sm> mae___: good work, so what's next step ? will we hear from him again ?
15:05 < Saizan> i'd say we should make packages more indipendent rather than lumping everything back together
15:05 < sm> *is* he canoeing up the amazon ?
15:05 < gwern> hm, why are my expire headers claiming the files expire at the start of the Unix epoch? =/
15:06 < Saizan> gwern: overflow?
15:06 < gwern> dunno
15:06 < Saizan> teh 32bit unix epoch is going to end soon..
15:07 < mae___> sm: Yeah, he will get the information to me or Lemmih, like I said
15:07 < gwern> maybe it was. hm. addMinutes claimed it only took an Int arg to increment the DateTime...
15:07 < gwern> poor docs
15:07 < mightybyte> mae___: I'm currently using HAppS to develop a website that I plan to deploy to the public, so I'm thrilled that you are reviving HAppS activity.
15:08 < gwern> switching to Integer seems to fix it
15:09 < gwern> dunno how much of a benefit expire headers will be tho
15:09 < mae___> mightybyte: neat ! :)
15:11 < mightybyte> mae___: In the process of doing my site, I'm expanding the basic HAppS auth package that I began in my blog posts.
15:12 < mightybyte> mae___: Since that is so crucial to real-world use, I would like to add that code to HAppS proper when it matures a little more.
15:14 < mightybyte> I also tend to favor a monolithic package.
15:16 < mae___> yeah
15:16 < mae___> I think a package should only be split if there is a true use case for it to be used independently
15:16 < mightybyte> mae___: Although it would be reasonable to separate out the core HTTP server functionality.
15:16 < mae___> i favor monolithic package + cut the code in half while keeping the same functionality
15:17 < mae___> also i favor not using the more advanced / esoteric haskell extensions if it can be avoided as this is a major brainfuck for most would-be contributors
15:17 < mightybyte> Yeah, I don't know much about that area of the code.
15:17 < mae___> so i mean, obviously there is a good need for some of the extensions, but others probably not so much
15:18 < mightybyte> I've gotten the impression that removing the TH stuff would drastically increase the boilerplate requirements, which would not be good.
15:20 < gwern> man, yslow is so picky
15:21 < mightybyte> Oh, recently I got frustrated trying to come up with a good way to deal with time/dates in HAppS.
15:21 < gwern> I added expire headers to gitit, and it still gives an F
15:21 < gwern> because they have to be 'far future'. oh no, 2 days in the future is not good enough
15:21 < mightybyte> I think HAppS should provide some typeclass instances for at least one of the core date/time data types.
15:22 < gwern> (hm, the images aren't appearing. weird)
15:23 < gwern> maybe expire headers don't work for imaes
15:24 < b_krolik> hi, can anyone help me to understand state components in happs, please?
15:25 < mightybyte> b_krolik: Have you seen the posts at http://softwaresimply.blogspot.com/ ?
15:26 < gwern> it doesn't work on js as well?
15:26 < gwern> this is getting strange
15:26 < b_krolik> mightybyte: yep, I think I understand the basics, but don't why would you want to have separate ones and what are dependencies
15:26 < b_krolik> *don't know
15:26 < mightybyte> b_krolik: Separate ones can be useful for modularity.
15:27 < mightybyte> For instance...the code I developed in the blog posts could be used as an auth/user system.
15:28 < mightybyte> To make it modular and allow drop-in functionality, you would include it in your application's state and list it as a dependency.
15:28 < mightybyte> Then you would be able to use it without changing any of the auth code at all.
15:29 < gwern> d'oh
15:29 < gwern> that was a stpud mistake - I left a constant in the factored out code - "css"
15:29 < gwern> so of course it only worked for css requests :)
15:30 < b_krolik> mightybyte: is listing a component as a dependency required to be able to use it?
15:30 < mightybyte> Yes, I believe so.
15:31 < mightybyte> ...unless you use that component as your direct, top-level state.
15:31 < b_krolik> i see, thanks :)
15:31 < mightybyte> You're welcome.
15:32 < b_krolik> another question - if you have separate components, is it possible to update several in one transaction?
15:32 < mightybyte> Hmmm, not sure off the top of my head.
15:32 < mightybyte> I think it is.
15:33 < mightybyte> You just create an Update action that modifies everything that is needed.
15:33 < b_krolik> i tried creating methods that access different components, but it fails either on TH phase or even earlier on typecheck
15:34 < mightybyte> Can you paste code?
15:36 < mightybyte> http://hpaste.org
15:37 < mightybyte> ...which is written in HAppS btw.
15:40 < gwern> hm. how to write gzip :: Response -> Response...
15:40 < b_krolik> hmm, hpaste.org is down :(
15:40 < sm> what's new..
15:40 < gwern> sm: I've finished up expire headers and sent john my diff
15:41 < gwern> now I'm working on gzipping the img/css/js, not just the text
15:41 < mightybyte> b_krolik: Then try pastebin.com
15:41 < gwern> use moonpatio. that's got hpaste2
15:41 < gwern> @where moonpatio
15:41 < gwern> > 1 + 1
15:41 < gwern> no lb?
15:41 < mightybyte> Ahhh, I wasn't aware of moonpation.
15:42 < gwern> well it's at http://moonpatio.com:8080/
15:45 < b_krolik> good, that one works
15:47 < gwern> maybe I'm supposed to gzip the file before it becomes a Response...
15:48 < sm> gwern: might be time to read a doc ? :)
15:48 < b_krolik> mightybyte: http://moonpatio.com:8080/fastcgi/hpaste.fcgi/view?id=853#a853
15:48 < b_krolik> error is in the end
15:48 < gwern> ah, here we go
15:48 < b_krolik> this is the simplest attempt
15:48 < gwern> Response is a record which contains a lazy bytestring in rsBody
15:48 < gwern> sm: yes, I agreed
15:53 < gwern> thoughts?
15:53 < gwern> 'foo r@(Response {rsBody=body}) =  setHeader "Content-Encoding" "gzip" $ r {rsBody = compress body}'
15:53 < b_krolik> there are many state components in AllIn.hs, but no example of transactional update of more than one
15:53 < mightybyte> b_krolik: Yeah, I'm looking around.  It may not be possible.
15:56 < b_krolik> mightybyte: if it isn't, than it somewhat undermines the usefulness of components for reusability, imho
15:56 < thomashartman1> indeed.
15:58 < mightybyte> b_krolik: Yeah, I would agree, although it might be argued that you can design your components such that you don't need to update more than one in the same transaction.
15:58 < mightybyte> Look at the type of one of the other operations.
15:58 < mightybyte> saveLog :: (Control.Monad.State.Class.MonadState UserLogs m) =>
15:58 < mightybyte>            Uid -> WorkLog -> m ()
16:00 < mightybyte> If you were going to modify two components at once, you'd either have to have do something funky with this type, or use the type of the top-level component.
16:01 < b_krolik> mightybyte: in my example AppState is the top level component, and it has UserLogs as a dependency
16:02 < b_krolik> that's why I'm surprised to see it failing
16:04 < mightybyte> The error happens before TH even comes into the picture.
16:04 < mightybyte> If you comment out ", 'saveLogWithMessage" it still fails to type check.
16:05 < b_krolik> in this case, yes, but I think that in one case I managed to get it to typecheck just to fail on TH
16:05 < mightybyte> Ahh, well that's good.
16:05 < mightybyte> Then you might be able to change the TH, or just derive your own instance.
16:06 < mightybyte> Check with Saizan or Lemmih about this.  They know more than I do.
16:07 < mightybyte> Thus far my use of HAppS has been relatively straightforward.  I haven't encountered any of these issues.
16:10 < b_krolik> ofc you can do a lot without getting into this sort of thing, but it would be interesting to understand the idea
16:10 < mightybyte> I guess my advice for now would be to not be quite so granular with your components.
16:11 < mightybyte> Yeah, I agree.
16:11 < mightybyte> At the moment I can't think of an example where it would be critical to be able to update multiple components atomically, but there may be a good one out there.
16:12 < b_krolik> the simplest would be the reusable components case, i think
16:13 < mightybyte> Well, but you could argue that truly reusable components don't need atomicity with data outside that component.
16:14 < mae___> true, but they might be combined with something else that needs to ensure atomicity :)
16:14 < mightybyte> I'm starting to think I may remember Lemmih saying that a Component is defined as a box which gives you atomic guarantees on the inside.
16:14 < mae___> i was under the assumption that this could be handled atomically across components
16:15 < Lemmih> It was a deliberate decision. Unbounded transactions hurt performance.
16:15 < mightybyte> mae___: It would certainly be nice, but I'm not sure how to do it.
16:15 < Lemmih> It hurts scalability, that is.
16:15 < mightybyte> Ahh, he's awake. :)
16:15 < mae___> yeah unbounded transactions do suck
16:15 < b_krolik> so is it true that you can't have atomic actions for more than one component?
16:15 < mae___> i can vouch for that running some helpdesk software that uses msql
16:16 < Lemmih> b_krolik: Yes.
16:16 < mightybyte> This serves to force the developer to think carefully about what needs atomicity.
16:16 < b_krolik> Lemmih: what is your idea of what a component is then?
16:17 < Lemmih> b_krolik: It's a piece of state with atomic operations.
16:18 < Lemmih> b_krolik: The bounded transactions are a side-effect. They're the defining feature.
16:18 < Lemmih> *aren't a side-effect
16:19 < b_krolik> Lemmih: if you cannot have actions that consistently update several components, doesn't it mean that you cannot have any serious interdependencies between components?
16:19 < mae___> well if you can't combine components I would assume you can still nest them right?
16:19 < mae___> even if you have to hack up the code to do so :)
16:20 < b_krolik> mae___: what do you mean by nesting?
16:20 < mae___> meaning
16:20 < mae___> any stateful code you put in a component is atomic
16:20 < mightybyte> mae___: Yes, you can nest them, which is what I'm doing with my Auth framework.
16:20 < Lemmih> mae___: A component is just a haskell data-structure. You can make it as large as you want.
16:20 < mae___> so you can combine the code from several components if you absolutely need atomicity
16:21 < Lemmih> b_krolik: That is right so some extent.
16:21 < mae___> i say to hell with transactional integrity, enter components that are non-sensitive to "outside world" influence
16:22 < b_krolik> mae___: then they cease to be _several_ components
16:22 < mae___> b_krolik: right :)
16:22 < Lemmih> Components are a middle ground between unbounded transactions and no transactions at all.
16:22 < mae___> right
16:23 < mightybyte> mae___: Well, I heard someone from one of the big web companies (Amazon, Ebay, etc...) saying that if you want to really scale, you have to give up guaranteed integrity.
16:23 < Lemmih> Amazon famously uses a huge MySQL database without any transactions.
16:23 < mightybyte> Yeah, I think that's what I'm remembering.
16:23 < mae___> well i think that if people use their brains they can learn to make the components work together asynchronously rather than going crazy with transactions
16:23 < Lemmih> Components gives you scalability + some data safety.
16:24 < mae___> right
16:25 < mae___> i love it :)
16:25 < mae___> Lemmih, did you get the email I sent to alex?
16:25 < Lemmih> Yes.
16:25 < mae___> I was able to get a hold of him on the phone
16:25 < mae___> ok
16:27 < b_krolik> now that you've explained that it's a deliberate design decision, at least we can stop trying to find a way to make it work and use our brains on something more useful instead ;)
16:27 < mae___> hehe
16:28 < mae___> ok all, I will be back later.
16:29 < b_krolik> it was that being able to specify dependencies in any of the components created a false impression that dependent component have a tighter relationships between them
16:30 < Lemmih> The dependency list is just there to make sure the right components are loaded.
16:31 < b_krolik> so there's basically no point in defining dependencies in anything but the top-level state component, right?
16:32 < Lemmih> There is. A Wiki component may, for example, use another component for generating unique ids.
16:33 < Lemmih> Using the wiki component should then load the unique-id component as well.
16:33 < b_krolik> can it do a query in its update methods?
16:34 < Lemmih> No, but the external interface might use both components.
16:34 < mightybyte> My Auth component is a great candidate for dependencies IMO.
16:34 < Lemmih> newPage = do new_id <- update GetNewId; update $ NewPage new_id
16:35 < mightybyte> Transactional updates to the user list are good, but you don't need those tranactions to creep anywhere else.
16:35 < b_krolik> then it makes as much sense to put both UID and Wiki as dependencies in the main state, doesn't it?
16:36 < Lemmih> b_krolik: You might not know exactly which components the wiki interface depends on.
16:37 < b_krolik> mightybyte: agree, there are a lot of things you can do w/o transactions, it's just good to know if you can do something, if the need arises
16:39 < b_krolik> Lemmih: you mean if wiki is a re-useable library?
16:39 < Lemmih> b_krolik: Yes.
16:42 < b_krolik> Lemmih: I see, btw in my experiments with the state I noticed that happs doesn't seem to be too happy if a dependency is listed several times, is this intentional?
16:43 < b_krolik> if this is the case you wouldn't be able to re-use uid component for wiki and users for example
16:43 < Lemmih> b_krolik: Yes, using the "same" component twice is an error.
16:44 < b_krolik> Lemmih: do you have to have users-uid and wiki-uid then?
16:44 < Lemmih> You differentiate with types.
16:45 < Lemmih> UniqueId UserId, UniqueId WikiPageId.
16:46 < b_krolik> what would the type of getNewId be in this case?
16:47 < Lemmih> getNewId :: t -> Update (UniqueId t) t
16:47  * b_krolik wonders if learning more Haskell before starting with HAppS was a better idea.
16:48 < Lemmih> Or: getNewId :: t -> Update (UniqueId t) Integer, if so desired.
16:48 < b_krolik> and what do you pass as t here?
16:48 < Lemmih> UserId or WikiPageId.
16:49 < mightybyte> b_krolik: I've had similar thoughts.  But HAppS has definitely moved my Haskell abilities forward more quickly than they were before.
16:50 < b_krolik> and *Id are like token types, with no data?
16:51 < Lemmih> b_krolik: They may or may not be. Two different implementations are possible.
16:55 < bkrolik> I hate blackouts :(
16:56 < bkrolik> is there a history log for this channel, btw?
16:57 < Lemmih> Not yet.
16:57 < wchogg> I thought thomas set one up earlier today
16:58 < Lemmih> Oh, guess I'm just out of the loop (:
16:58 < Lemmih> happsbot: !logs
17:20 < b_krolik> did anyone find out if logs are recorded?
17:21 < sm> ask thomashartman1
17:21 < sm> is #haskell ? what do they use ?
17:24 < b_krolik> sm: thx
17:30 < b_krolik> is it worth trying to switch to 0.9.3 from
17:34 < b_krolik> looks like switching from staying awake to sleeping is a better idea for now.
17:58 < mae___> logs -> http://happstack.com/irc-logs/log.01-22-2009
17:59 < hydo> oo logging...
17:59 < mae___> its just a screened irssi for right now
17:59 < mae___> no fancy lambdabot or anything :)
17:59 < mae___> better than nothing
18:00 < Saizan> ok
18:00 < Saizan> we can change the url in the topic then
18:00 < mae___> well the other one is still useful
18:00 < mae___> hmm you know what
18:00 < mae___> I'll put the old logs on here too
18:01  * Saizan uses tinyurl to gain topic space
18:06 < doublec> I need a smaller url for my 'not a tutorial' :)
18:08 < Saizan> yeah, and mae___ should add happstack url maybe :)
18:10 < mae___> i'm not an op, my registered name is 'mae'
18:14 < Saizan> i'm not an op either
18:14 < Saizan> anyone can set the topic here
18:15 < mae___> oh
18:15 < mae___> hah
18:15 < mae___> well sorry my irc chops are not that great
18:15 < mae___> i'm getting the old logs
18:28 < Saizan> mae___: a question, how familiar are you with the codebase?
18:28 < mae___> I've poked around quite a bit, there are parts I don't understand, but I have a decent grasp of where the different pieces lay
18:30 < mae___> why do you ask? :)
18:32 < Saizan> well, since you're going to decide which patches to apply.. :)
18:33 < mae___> Saizan: I am no way claiming to have the highest aptitude for haskell nor am I claiming that I am the most familiar with this codebase
18:34 < mae___> Saizan: That said, I do have some particular things in the codebase I would like to clean up test more thoroghly, as far as my judgement on patches goes, I think that I should not be the sole reviewer.
18:35 < mae___> 1. I want to work on marketing this platform (mainly through the blog) to the outside world (only the hardcore types read mailing list :)
18:36 < mae___> 2. I want to foster a good community and if I am successful I will most likely have the least amount of bragging rights as far as "clever code" goes. This will keep me busy.
18:36 < mae___> Does this answer your question?
18:37 < Saizan> yeah, i like your work on trying to bring momentum to the project :)
18:38 < mae___> Thanks :)
18:38 < sm> xmonad project may be a good model
18:38 < mae___> Yeah well I don't want to let EGO run this project.
18:38 < mae___> so while were on the topic
18:38 < mae___> who wants to step up to the plate to help with the patch acceptance?
18:39 < mae___> you just need to sign up on patch-tag
18:40 < Saizan> i've an account already :)
18:40 < mae___> ok great
18:40 < mae___> also while were here, I would like to admit a FUBAR
18:41 < Saizan> (i've been a developer for a while)
18:41 < mae___> I guess I forgot to put HAppS-Util in there but I can't fix it till i'm home
18:41 < mae___> this is how i found out
18:41 < mae___> http://twitter.com/thsutton/status/1138072463
18:41 < mae___> lol
18:41 < mae___> i googled for 'happstack'
18:41 < Saizan> heh :)
18:42 < mae___> could have sworn I did but doh!
18:42 < mae___> its nice to hear some good feedback
18:42 < mae___> because I feel like I'm wrestling a guerilla
18:45 < mae___> Saizan: you wrote the haskell spread client right?
18:46 < mae___> ok i added you saizan
18:46 < Saizan> yeah
18:46 < mae___> http://patch-tag.com/repo/happstack/home
18:48 < Saizan> cool :)
18:48 < mae___> and again guys, I am totally up for any reccomendations, we may not see eye to eye on everything, but I want everyone's input (especially coders who have been working on this awhile)
18:49 < mae___> ah that doesn't look right, recommendations
18:49 < mae___> I better spellcheck now that chat is on the record :D
18:49 < gwern> I can make lambdabot join here if y'all want
18:52 < Saizan> a lb with happs modules in scope would be good :)
18:52 < gwern> that's... probably not gonna happen
18:52 < Saizan> well, at least for :t and ?hoogle
18:52 < Saizan> not for @run
18:53 < gwern> hoogle, you'd've to talk to ndm
18:53 < mae___> I see
18:53 < gwern> dunno about :t
18:53 < mae___> well if lambdabot can do the logs then this definitely makes life easier
18:53 < Saizan> can it?
18:53 < Saizan> btw, can we still build haddocks?
18:53  * Saizan tries
18:55 < gwern> I dunno
18:55 < gwern> 'Below are years 2004 and 2005 public logs provided by clog (an IRC channel logging "bot") for #haskell on the Freenode (formerly known as Open Projects (formerly known as Linpeople)) IRC network. '
18:56 < mae___> okeydokey then
18:56 < mae___> old logs are there now too
18:56 < mae___> http://happstack.com/irc-logs/
18:58 < gwern> can't find out how to get clog logging
18:58 < gwern> I've asked in #tunes
18:59 < mae___> Saizan: let me know if anyone else needs commit rights ok?
--- Log closed Thu Jan 22 19:00:50 2009
--- Log opened Thu Jan 22 19:00:50 2009
--- Log closed Thu Jan 22 19:00:50 2009
--- Log opened Thu Jan 22 19:00:51 2009
19:07 < Saizan> mae___: ok
19:08 < Saizan> what about small obvious cleanups? like solving haddock parse errors
19:08 < mae___> what about them?
19:08 < mae___> : )
19:08 < Saizan> i should just push?:)
19:08 < mae___> yeah
19:08 < mae___> full speed ahead
19:09 < mae___> my feeling is
19:09 < mae___> anything that is cleanup or involves reducing the total amount of code is an easy yes
19:10 < mae___> by cleanup i mean, fixing compile warnings, haddock errors, files that aren't used.. etc etc
19:12 < Saizan> good
19:12 < Saizan> any clue about this though? http://pastebin.com/m184a09c6
19:12 < Saizan> i get that error when i try to push
19:17 < gwern> mae___: are you the #happs channel owner?
19:18 < gwern> Saizan: sounds like growing pains in patch-tag?
19:19 < Saizan> gwern: might be
19:19 < gwern> permissions error sounds like out of space maybe or perhaps the directories have bad permission (maybe you weren't added to the right unix group?)
19:22 < Saizan> i seem to be able to write to that directory
19:22 < mae___> nope
19:22 < Saizan> oh, no
19:22 < Saizan> not to inventories
19:23 < mae___> eh ok
19:23 < mae___> so is anyone else experiencing this?
19:23 < mae___> hmm let me get thomas involved
19:23 < gwern> if lb were here we could do @seen :(
19:23 < Saizan> you are the owner of inventories, instead of root
19:23 < mae___> er
19:24 < mae___> ok process of elimination
19:24 < mae___> you uploaded your ssh key right?
19:24 < gwern> how could he even get to the point of writing inventory if he didn't upload a ssh key?
19:25 < Saizan> yes, and i can also push to my own repo
19:25 < Saizan> and i'm logged in right now
19:25 < Saizan> drwxr-sr-x 2 mae    b21039724b360ba8596a5d5ca65e26a1  4096 Jan 21 01:46 inventories
19:25 < Saizan> it misses write permissions for the group
19:26 < Saizan> e.g. like:
19:26 < Saizan> drwxrws--- 2 root   b21039724b360ba8596a5d5ca65e26a1  4096 Jan 22 19:18 patches
19:26 < gwern> aha, so it was a group problem!
19:27 < mae___> what is your point of reference?
19:27 < mae___> are you in the box?
19:28 < Saizan> yes
19:28 < Saizan> i've logged in with "ssh Saizan@www.patch-tag.com"
19:28 < mae___> ah ok
19:30 < Saizan> i think there should be some way to prevent the wrong permissions to being set
19:30 < Saizan> or change the default ones at least
19:30 < Saizan> but i don't know unix that well :)
19:30 < mae___> so what do the permissions need to be?
19:30 < mae___> well there is umask
19:30 < Saizan> drwxrws---, i'd say
19:35 < Saizan> the blog should be on planet.haskell.org :)
19:36 < Saizan> vtw
19:36 < Saizan> "btw"
19:41 < mae___> isn't planet haskell an aggregator?
19:42 < Saizan> yeah, i meant the feed should be added there, so that we can reach more haskellers
19:42 < mae___> who do i have to contact?
19:43 < Saizan> http://planet.haskell.org/faq.html
19:44 < mae___> k
19:45 < mae___> be back later, I will get this resolved
21:55 < mae> saizan are you around?
21:58 < sm> gwern, how about this for gitit -
21:58 < sm> pageTypeHints       = [
21:58 < sm>     (readRST, ["README","NEWS"])
21:58 < sm>    ,(readMarkdown, [".*.markdown"])
21:58 < sm>    ,(readPlaintext, ["LICENSE"])
21:58 < sm>    ,(readOrgmode, ["NOTES"])
21:58 < sm>   ]
21:58 < gwern> seems kind of arbitrary
21:58 < sm> regular expressions matched against the whole filename, to select the pandoc read function
21:59 < gwern> and Orgmode? what the hell is that?
21:59 < sm> that's just my example local config
21:59 < sm> emacs org-mode of course.. pandoc doesn't support it yet
21:59 < sm> so you have something like this in your config.. or it can be empty
22:00 < sm> and there's a default markup
22:00 < gwern> hm, in the COnfig.hs?
22:00 < sm> yeah
22:00 < gwern> but that doesn't resolve the problem of foo.tex and foo.rst - where does [foo]() go to?
22:02 < sm> those should not both be created, but if they are it links to the first
22:02 < sm> alphabetically
22:03 < sm> or a page listing them all.. whatever
22:03 < sm> a paypal form where you pay a fine to the developers
22:06 < wchogg> mae : I'm sorry I haven't comitted to the main repo yet.  Thomas is still trying to work out what went goofy with my account on patch-tag.
22:09 < mae> wchogg: its fine, saizan was having the same problem
22:09 < mae> no worries
22:09 < mae> thomas is going to work on fixing it
22:09 < mae> but now that i have you here :)
22:09 < mae> can you paste the error in a pastebin?
22:10 < gwern> sm: well, john's active as of a few minutes ago
22:10 < gwern> email him maybe with a full proposal
22:10 < gwern> (me too)
22:11 < wchogg> mae : I don't know if there's really anything to paste.
22:12 < mae> oh? whats goofy about the account?
22:12 < wchogg> mae : It's inactive.  I can't use it for anything.
22:13 < mae> oh, bummer.
22:13 < mae> will you be here for a little while?
22:13 < wchogg> Yeah
22:14 < mae> ok
22:14 < mae> I think thomas will probably come on in a little bit
22:14 < mae> I told him on the phone about it already
22:14 < mae> hes still trying to get the kinks out :)
22:15 < gwern> well that's what beta testers are for
22:23 < mae> : )
--- Log closed Thu Jan 22 22:27:40 2009