<    March 2010    >
Su Mo Tu We Th Fr Sa
    1  2  3  4  5  6
 7  8  9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31
00:16 warreng joined
00:36 thewoolleyman joined
00:59 mvoigt joined
01:19 mvoigt joined
01:21 RichGuk joined
01:24 teamon joined
02:26 teamon joined
02:30 thewoolleyman joined
02:33 voker57 joined
02:49 hipe_ joined
02:59 RichGuk joined
03:13 splattael joined
03:36 jxie joined
03:43 mvoigt joined
04:06 hipertracker joined
04:15 neaf joined
04:24 fbru02 joined
04:36 fbru02 joined
05:35 g0bl1n joined
05:41 jb-san joined
05:49 anteaya joined
05:50 diemer joined
05:52 teamon joined
06:17 hipe joined
06:17 snusnu joined
06:18 demet8 joined
06:20 teamon joined
06:21 morohashi joined
06:22 merboutpost joined
06:27 <g0bl1n> Hi, <%= select :birth_day, :collection => (1..31).each { |d| << [d,"#{d}"] } %>
06:27 <g0bl1n> this doesn't work
06:27 <g0bl1n> what is the best approach ?
06:28 <merboutpost> g0bl1n: collection needs to be [[],[]]
06:28 <g0bl1n> yes
06:28 <g0bl1n> but I'd like to automate it
06:28 <g0bl1n> since I'll need to insert much greater values
06:28 <merboutpost> g0bl1n: so (1..31).map {|d| [d,d.to_s] }
06:29 <merboutpost> g0bl1n: read difference between map/each
06:29 <g0bl1n> indeed
06:29 <g0bl1n> ty merboutpost
06:30 <merboutpost> g0bl1n: how it works is that the select helper calls first/last on the element
06:30 <merboutpost> g0bl1n: so [] responds to first/last, but any object which respond the same can be element of the collection
06:31 <g0bl1n> oh, I see
06:31 <g0bl1n> ty
06:32 <merboutpost> g0bl1n: also if you have collection of objects, you can actually define, what methods will be called on element, for example if you have collection of Objects with #name and #id you can say call these instead of first/last
06:33 <g0bl1n> rereading this last one :)
06:33 fbru02 joined
06:34 <g0bl1n> ok, nice
06:35 <g0bl1n> ty merboutpost sweet, working nice !!
06:39 teamon_ joined
06:42 teamon joined
06:59 robin_alm joined
07:02 splattael joined
07:22 teamon joined
07:30 hosh_office joined
07:40 <merboutpost> namelessjon: there are no specs for Merb::Config
07:51 hcatlin joined
07:51 <hcatlin> so!
07:51 <hcatlin> this 1.1rc1
07:52 <hcatlin> can we get that via gems?
07:54 kw0lf joined
07:55 robin_alm left
07:58 jxie joined
08:01 <merboutpost> hcatlin: hi
08:01 <merboutpost> hcatlin: do you use DataMapper?
08:01 <merboutpost> hcatlin: I made mistake and merb_datamapper depends on the pre still
08:01 <merboutpost> hcatlin: but otherwise you should be able to do gem install merb-core (and friends) --pre
08:01 <merboutpost> hcatlin: and get rc1
08:02 <hcatlin> cool
08:02 <merboutpost> namelessjon: Please any thoughts on http://github.com/pk/merb/commit/eb322ce7a7ab53c5a695e72cb28cd008d9821c79
08:02 <merboutpost> hcatlin: rc2 will deliver bug fixes
08:07 <hcatlin> wait, 1.1rc1 is just... what's been going on in master for a while, right?
08:08 <hcatlin> we really, really, really want this to be out as 1.1.1
08:08 <hcatlin> (speaking as wikipedia)
08:08 <hcatlin> its causing my sysadmins to get really pissed at me
08:08 <hcatlin> puppet doesn't understand "--pre"
08:11 <hcatlin> merboutpost: rc2 will do *more* bugfixes?
08:11 <merboutpost> hcatlin: yes
08:12 <hcatlin> any chances in not using the --pre bit anymore? :)
08:12 <hcatlin> or not really
08:12 <hcatlin> using that wonderful 3rd version number that we don't use
08:12 <merboutpost> hcatlin: well I wanted to push 1.1.0 instead of rc1 :-)
08:12 <hcatlin> who disagreed?
08:12 snusnu joined
08:12 <merboutpost> hcatlin: and get rid of --pre and do other releases with 1.1.1 ...
08:13 <hcatlin> well, me and my 20 million daily hits on merb agrees
08:13 <hcatlin> (does that count like votes?)
08:13 <merboutpost> hcatlin: :-)
08:13 <merboutpost> hcatlin: What version are you running currently?
08:14 <hcatlin> a custom build of 1.1.0.pre
08:14 <hcatlin> well
08:14 <hcatlin> i built my own release
08:14 <hcatlin> its using bundler
08:14 <hcatlin> however, in attempting to get this in a scalable state
08:14 <hcatlin> (aka, where we can comission servers)
08:14 <hcatlin> bundler doesn't work with 1.3.5 gems... so i'm SOL
08:15 <hcatlin> (debian addicts)
08:15 <hcatlin> so now we are having to manually do gems
08:15 <merboutpost> hcatlin: I use 1.3.5 and bundler 0.9.7 and 1.1.0.rc1 on Ubuntu
08:15 <hcatlin> ?
08:15 <hcatlin> wait, i thought bundler required 1.3.6?
08:15 <merboutpost> hcatlin: that works, later versions of the bundler requires that not that one particular version I stop on
08:15 <merboutpost> :)
08:16 <merboutpost> hcatlin: ubuntu doesn't have 1.3.6 packages and my sysadmis would kill me if I'd install rubygems from source
08:16 <hcatlin> agreed!
08:17 <hcatlin> i am sending my sysadmin in here
08:17 <hcatlin> do you have a second to discuss it?
08:17 <merboutpost> hcatlin: if you don't need some features from Bundler > 0.9.7 you can happily live with the Bundler 0.9.7
08:17 <merboutpost> hcatlin: yep.
08:17 <hcatlin> it uses the same directory structure
08:18 <merboutpost> hcatlin: so did you made any changes for the merb 1.1.0.pre (like any patches you'd like to see in rc2) ?
08:18 <g0bl1n> hcatlin, are you from Yellow Pages ? 20M daily hits :-O
08:18 <hcatlin> wikipedia
08:18 <merboutpost> hcatlin: they changed directory structure changed only in 0.8.x -> 0.9.x AFAIK
08:18 <hcatlin> merboutpost: no, but we do have an ugly workaround for some routes stuff
08:19 <merboutpost> hcatlin: I found that mutex was always off :-)
08:19 <hcatlin> http://github.com/hcatlin/wikimedia-mobile/blob/master/app/controllers/articles.rb
08:19 <g0bl1n> oh ok :-)
08:19 <hcatlin> if you look at the show action
08:19 <hcatlin> the first two ifs deal with things we can't do in routes
08:19 <merboutpost> hcatlin: grr... use_mutex == true all the time
08:20 <hcatlin> wait, would that fix this?
08:20 <merboutpost> hcatlin: no, just that merb did locked currently in 1.1.x and other versions.
08:20 thewoolleyman joined
08:20 <merboutpost> hcatlin: it ignored c[:use_mutex] = false settings...
08:22 <merboutpost> hcatlin: ahh... I remember some debate about the // in the urls
08:22 warreng joined
08:26 <merboutpost> hcatlin: not sure if I understand completely the second if but that should be possible with the deferred routes
08:26 <merboutpost> snusnu: http://github.com/pk/merb/commit/eb322ce7a7ab53c5a695e72cb28cd008d9821c79, please
08:30 <namelessjon> merboutpost: s/shuld/should/ Other than that, any idea why the original location was failing?
08:32 <snusnu> merboutpost: that's really it :P? i mean, it may very well be … have no chance to really test atm i'm afraid :/ .. it'd be most awesome to have that fixed tho, fo sure
08:36 <merboutpost> namelessjon: yes
08:37 <merboutpost> namelessjon: because classes are loaded before the Configuration is loaded. And because that previous location was class scope it as set when classes were loaded
08:38 <namelessjon> merboutpost: Ah, of course.
08:39 <merboutpost> namelessjon: I first moved that to the Dispatcher#handle but it's waste to do assignment every time
08:39 <merboutpost> namelessjon: I think that in the setup of the configuration is right place. Since it really involves configuration.
08:40 <merboutpost> namelessjon: also if you checkout the specs I made.... You may wonder why the examples are wrapped in the lamba {}
08:40 <namelessjon> merboutpost: Yeah, I can't think of why you'd want to change the option in a running app.
08:42 <merboutpost> namelessjon: Merb.start_environment setups... well whole environment and that's kind a global. So lambdas{} makes it local to the example.
08:44 <namelessjon> merboutpost: That's a nice trick :)
08:48 <snusnu> merboutpost: so, wouldn't that fix warrant an rc2 :P … yeah, i'm lazy, and don't want to adapt merb-gen for different merb/merb_datamapper version numbers :)
08:49 <merboutpost> namelessjon, snusnu: Probably, I'm working on more fixes
08:49 <merboutpost> namelessjon, snusnu: hcatlin wanted to push 1.1.0, --pre cause sysadmin headaches
08:49 <snusnu> merboutpost: awesome, really nice that you found more time to work on merb again
08:51 <snusnu> merboutpost: yeah, i skimmed over the conversation .. i agree, 1.1 should get out, and then it's time to leverage the patch level .. pre should mostly be for convenience .. and looses more and more importance to me, with bundler working nicely with git repos .. that may just be me tho
08:54 jdomg joined
08:57 <merboutpost> snusnu, namelessjon: +1 to push 1.1.0
08:58 <merboutpost> and do fast and plenty of 1.1.x :-0
09:00 anteaya joined
09:09 <namelessjon> merboutpost: +1. Do we have release notes? Or at least "Stuff that broke/changed from 1.0.x to 1.1.x"?
09:12 <merboutpost> namelessjon: that's the biggest tricky part :-(
09:13 <merboutpost> namelessjon: I know snusnu put something together. Maybe some git log magick could help
09:24 <namelessjon> merboutpost: If people have been good with commit messages, yeah :)
09:25 <namelessjon> merboutpost: /me has a play
09:31 <namelessjon> merboutpost: Wow, 309 commits. (with some dups in there)
09:32 <merboutpost> namelessjon: yep its more than year :-)
09:32 neaf joined
09:33 <merboutpost> namelessjon: maybe when we dump that & filter dups. And than go through it some major commits will pop up so we can write more about them. Others we can include just as CHANGELOG
09:34 <namelessjon> merboutpost: Yeah, I'm playing with git-log opts to filter out as many as I can.
09:35 <merboutpost> namelessjon, snusnu: LOL: This http://github.com/wycats/merb/commit/d26a80d193b23a30f991ad695410e4fcaf1925e1 fixes something, and breaks other stuff
09:35 <merboutpost> namelessjon, snusnu: namely https://merb.lighthouseapp.com/projects/7433/tickets/1304-multipart-input-parsing-produces-wrong-checkbox-input
09:39 <snusnu> merboutpost: yeah, i remember that :)
09:39 hipe joined
09:44 <namelessjon> man, we must have some confused history and merges. ^^;
09:45 <merboutpost> namelessjon: I did. I pushed 2x my master instead of official
09:46 <merboutpost> namelessjon: that resulted in the good code but messed up history
09:49 <namelessjon> merboutpost: Ah. Also, I have to go out now. bbl.
09:50 <merboutpost> namelessjon: ok, no prob.
09:58 <merboutpost> namelessjon, snusnu, careo: Anybody knows about multipart/form-data parser in a GEM!
09:59 <merboutpost> ^^ Best would be C implementation really.
10:01 <snusnu> merboutpost: isn't there rack-param parser or something?
10:01 <snusnu> merboutpost: oh wait, i dunno if that handles multipart stuff or if it was just about nested form params ...
10:02 <merboutpost> snusnu: I'm fixing now multipart parsing in Merb and really it's a mess.
10:02 <snusnu> :/
10:02 <merboutpost> snusnu: it only will be slow, but also prone to errors. This should definitely be gem, most likely written in C!
10:02 <snusnu> merboutpost: what about jruby?
10:02 <merboutpost> snusnu: that's the reason I played with Nginx upload module which does multipart parting for you and not in merb
10:03 <merboutpost> snusnu: well jruby would be kind a specific solution, how many people can host on jruby?
10:06 hosh_office joined
10:07 <snusnu> merboutpost: i dunno, but probably quite some, with more to come
10:07 <snusnu> merboutpost: anyhow, i'm not against a C impl .. i wonder if it's really necessary tho
10:08 <merboutpost> snusnu: WTF!!! Rack has multipart parsing, and it suffers all the bugs which was fixed for merb! And it's almost the same code!
10:08 <snusnu> hehe shit
10:09 <snusnu> and btw
10:09 <* snusnu> hates gems that check if rails or merb are present
10:09 <Tass`> snusnu, like?
10:09 <snusnu> only because they need to know an app root .. seriously, that's the only reason i came across so far
10:09 <snusnu> dm-paperclip
10:09 <Tass`> hum
10:10 <Tass`> there should just be ROOT
10:11 <snusnu> Tass`: i'm leaning towards a #root and #root= module accessor in the toplevel namespace (Paperclip in this case) .. that could be set by application initializers .. or fallback to: @root ||= (ENV['RAILS_ENV'] || ENV['MERB_ENV'] || ENV['RACK_ENV'])
10:15 <snusnu> Tass`: i will patch dm-paperclip to work like that .. i can't stand all those conditionals that assume (only 2) of ruby webframeworks
10:16 <snusnu> Tass`: lol .. i just realized how stupid my code above is .. assigning an ENV to a root :P
10:17 <snusnu> Tass`: you get the idea tho … obviously that needs to be done for both env and root
10:17 <snusnu> Tass`: the gems i mean (resque and paperclip) both need env and root iirc, i already patched resque and it was accepted .. now paperclip
10:17 <Tass`> snusnu, heh, Rango.root :-)
10:18 <snusnu> Tass`: yeah there's Rails.root and Merb.root too .. the thing is, if a gem needs to place something relative to the app root (or based on the app env) .. it shouldn't access these constants (imho) .. it should provide a way to tell it "its own root"
10:19 <snusnu> Tass`: otherwise you always end up assuming one (out of possibly many) candidates .. like rails or merb in this example .. or even more, Rango,Ramaze,Waves .. whatever
10:20 <snusnu> Tass`: imho "feature detection" is the wrong approach here as it assumes to much about the loadpath .. paperclip needs a root to anchor it's relative paths to? give it one
10:20 <snusnu> Tass`: don't let it guess one
10:21 <snusnu> Tass`: needless to say, bundler made the problem creep up (by not respecting Gemfile order, and imho rightfully so, but that's a different discussion :P)
10:25 <Tass`> snusnu, yeah, heroku blew up due to that... had to make some hacks ;-)
10:25 <snusnu> Tass`: on a related note … i hate gems that check for the presence of dm-validations .. seriously, who doesn't use them at all?
10:26 <Tass`> snusnu, http://github.com/Tass/dota/compare/heroku
10:27 <snusnu> Tass`: looking at tht gemfile .. i pushed fixes for all of dm-more yesterday to my AS branch .. so in case you use your fork because of this, you shouln't need to anymore, soon
10:28 <Tass`> snusnu, AS? activesupport?
10:29 <snusnu> yup
10:29 <snusnu> 3.0.0.beta1
10:29 <snusnu> only
10:29 <Tass`> well, I'm using my branch due to validates_size ;-)
10:29 <snusnu> ah right! :) sorry
10:43 <Tass`> snusnu, you can merge that ;>
10:50 <snusnu> Tass`: haven't had time yet to look closer at it .. it's about validation has 1..5, :things and such, right?
10:51 yinkei joined
10:53 <Tass`> snusnu, well, yes, you can do that too
10:54 <Tass`> snusnu, it basically adds validates_size :citations, :max => 5, :min => 3, :within => (3..5) # if I remember the API correctly
10:55 <snusnu> Tass`: ah ok, so that could be triggered with autovalidation of relationships too then?
10:55 <Tass`> snusnu, correctly.
10:55 <snusnu> Tass`: pardon my ignorance :P .. what part of the validates_size wasn't working before?
10:56 <snusnu> Tass`: :min and :max?
10:57 <Tass`> snusnu, it didn't exist at all ;-)
10:57 <snusnu> Tass`: or have you "generalized the check" to take relationships into account … sorry, i should probably read the patch before talking about it, but i (think) i don't have time now :P
10:57 <snusnu> Tass`: heh
10:57 <Tass`> snusnu, http://github.com/Tass/dm-more/commit/175623fe3630ddc4d58a71a56a43a299b01d4072
10:57 <snusnu> Tass`: i thought there was a validates_size already ...
10:57 <Tass`> snusnu, didn't see it
10:59 hipe_ joined
11:00 nitsujw joined
11:01 stepheneb joined
11:04 yipstar joined
11:16 <merboutpost> snusnu, namelessjon: Last fix for today: http://github.com/pk/merb/commit/4325ffff46b5a1056b9c54ce5ba91a61a91aa1d6
11:16 <merboutpost> snusnu, namelessjon: please review and +-1 :-)
11:20 <snusnu> merboutpost: not being familiar with multipart stuff at all, and not having an app to test it out now, i can only say that http://github.com/pk/merb/commit/4325ffff46b5a1056b9c54ce5ba91a61a91aa1d6#L1R78 probably needs renaming
11:21 <merboutpost> snusnu: more verbose commit :)
11:21 <merboutpost> snusnu: ok
11:25 <merboutpost> snusnu: fixed http://github.com/pk/merb/commit/4028cfea8fb58de5ad2dc45cd301e228ff1b898c
11:27 <namelessjon> merboutpost: The it "should" is still there?
11:27 <snusnu> merboutpost: ah ok, more verbose message now i get it, but yeah, the "should" is still there :P
11:29 neaf joined
11:29 warreng joined
11:35 <merboutpost> namelessjon: that is another commit (second) fixing multipart, the shuld in the first will be fixed in a minute
11:38 <merboutpost> namelessjon: ok should fixed here http://github.com/pk/merb/commit/5a83fa3594cd60cbd3e14bbba8d85ecbf4ce4654
11:39 <merboutpost> I think these patches justify to push rc2.
11:40 <namelessjon> merboutpost: No, I meant in the spec in the multipart fix, the spec is 'it "should" do'
11:41 <merboutpost> namelessjon: he, so I had mistakes in both specs :-)
11:48 jer joined
11:49 warreng_ joined
11:55 ezmobius joined
12:03 warreng_ joined
12:04 <merboutpost> namelessjon, snusnu: Changelog updates for rc1, rc2: http://github.com/pk/merb/commit/edb0d7a90accb92ae5c0752e4025461e3f9b28ab
12:05 neaf joined
12:07 <snusnu> merboutpost: looks good, i'd probably elaborate a bit more on the :use_mutex issue, like, merb now actually *works* in threaded mode
12:08 <snusnu> merboutpost: also, iirc i asked you that already some time ago .. but what does !!!BC!!!! mean?
12:08 <merboutpost> snusnu: backward compatibility ?
12:08 <merboutpost> snusnu: and !!!!! === break :-)
12:08 yinkei joined
12:08 <snusnu> merboutpost: ahh yes now i remember :P
12:09 <merboutpost> snusnu: feel free to change whatever you want
12:09 yinkei joined
12:09 <snusnu> merboutpost: i'm lost in datamapper plugin code atm :/
12:11 <merboutpost> MAN! it's such a pain to switch VIM <-> XCode!
12:12 stepheneb joined
12:13 RichGuk joined
12:27 <Frost> merboutpost: can't you use vim as a source code editor from xcode?
12:34 <merboutpost> Frost: but the code completion? Will it work?
12:34 <merboutpost> Frost: did you try some vim integration for objc?
12:36 <Frost> merboutpost: I have no idea, actually. It might work, but on the other hand, it might not.. :/
12:40 <Frost> at least it seems like you can get vim to interpret .m file endings as objc instead of matlab quite easily
12:43 <merboutpost> Frost: I'm trying and it seems to be good enough
12:43 <merboutpost> Frost: this helps http://www.glsoftware.net/blog/archives/27-Integrating-Xcode-and-VIM.html
12:43 <Frost> google is your friend, and so on :)
12:55 warreng joined
13:00 justin-george joined
13:14 felipec joined
13:15 <felipec> I'm getting "Resource route not found" where the resource is clearly defined, apparently it's a DM bug: http://www.mail-archive.com/merb@googlegroups.com/msg02418.html
13:15 <felipec> but how do I workaround it?
13:16 <namelessjon> felipec: That's an old thread. DM has changed significantly since then
13:17 <felipec> but I'm still getting the error
13:17 <namelessjon> felipec: Could you pastie some code?
13:18 <felipec> namelessjon: http://pastie.org/872565
13:20 <namelessjon> felipec: brb. I'll look when I get back
13:21 <felipec> namelessjon: do you know how much time?
13:24 yinkei joined
13:31 stepheneb joined
13:32 <namelessjon> felipec: What merb/dm version, btw?
13:38 <felipec> namelessjon: nah, I checked the model: property :test_result, Integer
13:38 <felipec> has 1, :test_result isn't working either, but I'm on that
13:39 <namelessjon> felipec: It should work down a has 1. Though in dm, you do need one end to have a belongs_to
13:39 neaf joined
13:40 <felipec> namelessjon: er, but that doesn't make sense in this model: last_test_result is a view, showing the last row of test_result
13:42 josephwilk joined
13:45 <felipec> I guess I will have to use TestResult.get
13:46 <namelessjon> felipec: The number of queries is the same. You could maybe wrap it in a nice method.
13:48 <felipec> right, I could override LastTestResult's method
13:59 <felipec> can't seem to ad a method either in the generator, nor in the model
14:06 ezmobius joined
14:24 warreng joined
14:26 teamon joined
14:33 warreng joined
14:51 jstad joined
15:18 kw0lf joined
15:25 snusnu joined
15:33 hassox joined
15:37 RichGuk joined
16:14 warreng joined
16:26 stepheneb joined
16:26 stepheneb joined
16:30 thewoolleyman_ joined
16:33 hipertracker joined
16:36 fbru02_ joined
16:41 siplux joined
16:44 morohashi joined
16:48 <siplux> xxx/quit
16:53 siplux joined
16:55 geekounet joined
17:07 kenphused joined
17:10 thewoolleyman joined
17:13 thewoolleyman joined
17:18 thewoolleyman_ joined
17:20 beawesomeinstead joined
17:43 hipertracker_ joined
17:51 Hosh joined
18:04 merboutpost joined
18:05 <merboutpost> namelessjon, snusnu: I'm wild today: http://github.com/pk/merb/tree/fix_1212
18:05 <merboutpost> another patch for rc2 :-)
18:09 namelessjon joined
18:11 GoTTeM joined
18:11 <GoTTeM> hello?
18:18 <merboutpost> GoTTeM: ?
18:34 kw0lf joined
18:41 hcatlin joined
18:45 hcatlin joined
18:46 yipstar joined
18:56 yinkei joined
18:59 <snusnu> nice merboutpost, i really appreciate your wildness :P
19:00 <namelessjon> snusnu: Wildness?
19:05 <snusnu> namelessjon: heh, i was just referring to merboutpost saying: I'm wild today: http://github.com/pk/merb/tree/fix_1212
19:06 <snusnu> namelessjon: is wildness an english word :)?
19:07 <merboutpost> snusnu, namelessjon: any idea ? https://merb.lighthouseapp.com/projects/7433/tickets/1040-uninitialized-constant-merbtemplateerubisxmlhelper-when-use-foo-at-htmlerb
19:08 <namelessjon> snusnu: Ah, that was said whilst I was pinged out.
19:08 <merboutpost> snusnu, namelessjon: I'm trying to crack it for a while but can't find fix
19:09 <snusnu> merboutpost: hmm i dunno, i remember confirming it, but i never saw that syntax, ever
19:14 <merboutpost> snusnu, namelessjon: http://rubyforge.org/tracker/index.php?func=detail&aid=21825&group_id=1320&atid=5201
19:14 <namelessjon> merboutpost: I was just about to say, that was the issue
19:16 <namelessjon> merboutpost: I think we can work around with something like...
19:18 <namelessjon> merboutpost: https://gist.github.com/5ea14a372a34d643a3ac
19:18 <merboutpost> namelessjon: trying...
19:18 <namelessjon> merboutpost: n/b, that is untested :)
19:19 <merboutpost> namelessjon: I managed to fix it with:
19:19 <merboutpost> code = "def #{name}(_locals={}); #{assigns}; #{template.src}; end"
19:19 <merboutpost> code.gsub!(/Erubis::XmlHelper/, '::Erubis::XmlHelper')
19:19 <merboutpost> :-)))))))))))))
19:19 <merboutpost> brute force
19:21 <namelessjon> merboutpost: Does my solution not work?
19:22 <merboutpost> namelessjon: no that was solution before you posted
19:22 <merboutpost> namelessjon: your solution works! Sweeet!
19:23 <merboutpost> namelessjon: another bug killed.
19:30 <namelessjon> merboutpost: sweet. If my understandng of ruby classes is right, that should only be a reference to the real module, too.
19:30 yinkei joined
19:33 <merboutpost> namelessjon: I still try to understand what that actually do :-)
19:33 <merboutpost> namelessjon: how I can change autor of the commit?
19:33 <merboutpost> namelessjon: I'd like to give you credit
19:36 g0bl1n joined
19:36 <merboutpost> namelessjon: ah git ament
19:36 <merboutpost> amend
19:39 <merboutpost> namelessjon: sweeeet: http://github.com/pk/merb/tree/fix_1040
19:42 <namelessjon> merboutpost: I'd probably move line 193 down about 6-7 lines.
19:43 <namelessjon> merboutpost: We might as well do it when we already have the class open.
19:43 <namelessjon> merboutpost: The gist was just to show the class structure.
19:45 stepheneb joined
19:45 stepheneb joined
19:47 <merboutpost> namelessjon: repushed
19:48 <namelessjon> merboutpost: That's neater, thanks :)
19:49 <merboutpost> namelessjon: This reminded me that I should stop hacking... stupid.
19:50 <merboutpost> namelessjon: I like to merge all patches which are ready. To master tomorrow.
19:50 <merboutpost> namelessjon: today could be too risky.
19:50 <namelessjon> merboutpost: Yeah, 2am is a little late for that ;)
20:46 <namelessjon> merboutpost: https://merb.lighthouseapp.com/projects/7433/tickets/1085-make-sure-the-etag-solution-works < looking at this. (and the http rfc)
20:47 <merboutpost> namelessjon: cool! Thanks!
20:47 <merboutpost> namelessjon: I'm playing with https://merb.lighthouseapp.com/projects/7433-merb/tickets/524-support-all-redirect-status-codes#ticket-524-17
20:52 <namelessjon> merboutpost: The main issue I see with Matteti's suggestion is that ... a precondition match isn't exceptional. But it's about the only way you could do the necessary halt in a helper method.
20:52 justin-george joined
20:53 <merboutpost> namelessjon: wycats claimed that Rails3 solve condidional get in propper way and that implementation in Merb was hack
20:54 <merboutpost> namelessjon: I'm too tired now, have to sleep
20:55 <namelessjon> merboutpost: naturally. ;) Well, it certainly has some problems with regards to the spec, anyway.
20:55 <merboutpost> namelessjon: ttyl
20:55 <namelessjon> merboutpost: G'night
21:31 hipe joined
21:31 Hosh joined
21:35 thewoolleyman joined
21:45 hipe joined
22:08 hcatlin joined
22:09 maximeguilbot joined
22:48 hipe joined
23:08 snusnu joined
23:32 warreng joined
23:36 thewoolleyman joined
23:41 bdimcheff joined