05:24 <g0bl1n> why does merb-gen resource changes the fields/properties order set in the command line ?

05:25 <namelessjon> g0bl1n: It makes a hash of them, iirc.

05:25 <g0bl1n> oh, ok

05:26 <g0bl1n> so it's safe to reorder the model properties, right ?

05:26 <namelessjon> g0bl1n: Entirely.

05:27 <g0bl1n> ok, thanks

05:48 <namelessjon> merboutpost: So, looking at how rails handles etags etc.: It's a much neater solution. I don't know how possible it would be to get something like it in merb, due to the different things we return from actions. (It is also, assuming I'm reading code and spec right, wrong)

06:15 <merboutpost> namelessjon: hm... because R3 has that Controller.action(:action_name) which returns rack app?

06:15 <merboutpost> namelessjon: I thought about that, and it simplify quite a lot of things. Merb could get even smaller

06:16 <merboutpost> namelessjon: I was tempted to start working on switch from Dispatcher to this R3/Rango/Sinatra(?) model

06:24 <somebee> but with merb-datapper: * merb-core (= 1.1.0.pre, runtime) required by merb_datamapper (= 1.1.0.rc1, runtime)<- it should depend on 1.1.0.rc1 obviously

06:26 <merboutpost> somebee: yep, patch already in the github. My mistake. We'll release rc2 soon with more fixes and obviously this fix.

06:26 <somebee> merboutpost: ok

06:26 <merboutpost> somebee: it's now not allowed to repush the same version of the gem, so I coudln't immediately fix it and repush

06:29 <somebee> merboutpost: ok, no problem :) downloading from github instead

06:34 <namelessjon> merboutpost: Actually, it might be more possible than I thought. Anyway, my first step will be to get correct handling of the headers. Then add some 'whole stack' specs. Then see if I can simplify things.

06:38 <merboutpost> namelessjon: Think also about the Controller.action() stuff, to get rid of Dispatcher etc... :-)

06:38 <merboutpost> namelessjon: I'd be interested in it, especially with writing propper Rack support for Merb.

06:40 <namelessjon> merboutpost: Okay.

06:58 <namelessjon> merboutpost: No, I misread the spec. The rails behaviour is right.

06:58 <namelessjon> merboutpost: Also, I am wondering. Is it worth implementing a policy of 'If you touch a file, update the documentation to modern YARD standards'?

07:06 <merboutpost> namelessjon: I had bad/good dreams this night about YARD :-)

07:07 <merboutpost> namelessjon: I'd love to have YARD docs. But I wondered if we could write RDOC -> YARD transformer (doing 80% of work)

07:30 <namelessjon> merboutpost: It might work :) Certainly some bits would be easy.

07:33 <merboutpost> namelessjon: yep I just looked at some stuff and params and returns should be fairly simple

07:34 <merboutpost> namelessjon: hash params would be pain

07:34 <merboutpost> namelessjon: but the quality of the documentation would be much better when in YARD

07:35 <merboutpost> namelessjon: we could say a lot more about the methods and classes in a much neater way

07:35 <namelessjon> merboutpost: Yeah, and we could use yardstick to get it better, too.

07:41 <merboutpost> namelessjon: I'd like to push 1.1.0.rc2 on Sunday

07:41 <merboutpost> namelessjon: Better if it would be possible to push 1.1.0 and not another --pre release.

07:42 <merboutpost> namelessjon: so we would need the CHANGELOG

08:08 <namelessjon> merboutpost: I'm wondering if it's worth adding support for If-Match.

08:11 <merboutpost> namelessjon: I'd pass the ETag stuff through the mailing list

12:05 <somebee> more errors with merb(?) and bundler: http://gist.github.com/335520

12:07 <merboutpost> somebee: probably not merb related, cure for bundler rm -r ~/.bundle; bundle install; ./bin/merb -i and you sould be fine

12:08 <merboutpost> somebee: Bundler does store all in ~/.bundle and I couldn't find better way than deleting it every time I need to install/upgrade :-(

12:08 <merboutpost> somebee: I use 0.9.7 though

12:08 <somebee> merboutpost: same error still. bundler is driving me crazy

12:09 <somebee> merboutpost: after not bundling into vendor/gems (only bundle install) I get another error instead.. home/identu/.bundle/ruby/1.8/gems/merb-core-1.1.0.rc1/bin/merb:13:in `require': no such file to load -- merb-core (LoadError)

12:10 <somebee> I cannot believe how buggy bundler is :(

12:24 <somebee> when will merb 1.1 be released? I'm having soo much trouble with dm+merb+bundler atm that I suppose I'll wait a few weeks

12:26 <snusnu> somebee: 1.1 will happen soon probably .. i heard merboutpost say on sunday … can't you not workaround by requiring stuff explicitly before Bundler.require does its (black) magic?

12:31 <merboutpost> snusnu: Sunday I'd like to release something, don't know if 1.1 but, why not after all. If there is even more patches done till that time. I'm for it to push 1.1.0 to the wild.

12:44 <namelessjon> merboutpost: http://github.com/namelessjon/merb/tree/fix_1085

12:48 <namelessjon> snusnu: ^^

16:21 <namelessjon> merboutpost: http://github.com/namelessjon/merb/tree/fix_1085

16:46 <merboutpost> namelessjon: hi

16:46 <merboutpost> namelessjon: checking

16:46 <merboutpost> namelessjon: switching to the big screen....

16:51 <merboutpost> namelessjon: cool!

16:52 <merboutpost> namelessjon: Shall we start merging it to the master?

16:59 <namelessjon> merboutpost: I don't think any of those patches will change. I do want to add a few more to actually fix the ticket. Just figuring out how to do things with webrat

17:00 <merboutpost> namelessjon: cool, I've marked in LH everything which goes to sunday release as waiting to be merged

17:00 <namelessjon> merboutpost: I'm also pondering either making request_fresh? set the response status, or add a method to wrap it.

17:02 <merboutpost> namelessjon: what are valid statuses?

17:02 <merboutpost> namelessjon: is there more than one?

17:02 <* merboutpost> opening RFC2616

17:03 <namelessjon> merboutpost: For unmodified resources, only 304

17:05 <merboutpost> namelessjon: you currently use if request_fresh? ... in mixin

17:05 <merboutpost> namelessjon: I think that request_fresh? should just care if the request is fresh or not

17:05 <merboutpost> namelessjon: status should be set based on that not inside the request_fresh? I think.

17:06 <namelessjon> merboutpost: Yeah, me too. Is why I was thinking of adding another helper method which would do that.

17:07 <kenphused> merboutpost or namelessjon: what is the fate of merb after 1.1 ?

17:07 <namelessjon> merboutpost: Then we could do 'return if fresh_request(:etag => 'foo', ...)'

17:08 <merboutpost> namelessjon: yep, RFC states that status should be only 304 anyway.

17:08 <namelessjon> merboutpost: I spent a few hours today buried in the rfc *grin*

17:11 <merboutpost> namelessjon: reading... I don't see anywhere stated you must return 304 :-), but on the other hand I don't see any other status to retun :-)

17:11 <merboutpost> kenphused: What you mean? :-)

17:12 <merboutpost> kenphused: probably 1.1.1 ;-)

17:12 <kenphused> merboutpost: with the "merge" of rails and merb

17:12 <kenphused> i would prefer not to have the cruft of rails

17:13 <merboutpost> kenphused: I'm working on Merb because I think Merb > Rails3 :-)

17:13 <namelessjon> merboutpost: Well, you don't have to return 304. But 304 is the only useful status (other than ignoring it and sending 200 anyway)

17:14 <kenphused> merboutpost: wErd

17:14 <merboutpost> namelessjon: yep, so we would have fresh_request? and fresh_request(:etag...) API

17:15 <merboutpost> kenphused: ? (pardon me)

17:15 <kenphused> merboutpost: it's a vanilla ice thing... "werd to your mother"

17:16 <merboutpost> kenphused: After 1.1.0 there is pipeline of what I'd like to do. The question is if I'm allowed to do it but I'd like to implement some more neat things which was pushed to Rails3 and delete couple of thousands of lines from Merb :-)

17:16 <merboutpost> kenphused: which would put merb-core to sloccount < 5000!

17:16 <kenphused> merboutpost: nice...

17:17 <kenphused> i would like to see development continue

17:17 <merboutpost> kenphused: Also I'm more and more skeptical adopting ActiveSupport3 instead of Extlib.........

17:17 <kenphused> merboutpost: EXactly!!!!!

17:17 <namelessjon> merboutpost: Yeah, I think so.

17:17 <g0bl1n> merboutpost: I second that, that Merb > Rails3 !! ;-) Merb FTW !!

17:17 <merboutpost> kenphused: because AS3 would have more sloccount than whole merb-core.... which honestly, doesn't make any sense.

17:18 <kenphused> i've never been a fan of ActiveSupport

17:18 <merboutpost> Current sloccount (with patches not included in master) =~ 6900 I think we can easily go down to 5000

17:20 <merboutpost> namelessjon: not sure if the API we propose for that is clear enough

17:22 <botanicus> I'm glad there is still so many people who like to continue with the development. I like Merb a lot.

17:23 <merboutpost> As hcatlin pointed out yeasterday, there is also 20 milion daily users ;-)

17:27 <namelessjon> merboutpost: I'll put something together with docs. See if it's clearer when there is something concrete

17:28 <merboutpost> namelessjon: I'm thinking that return if fresh_request() is strange because I'd suppose the fresh_request? in the iff

17:29 <merboutpost> namelessjon: hard to decide, :-)

17:29 <merboutpost> namelessjon: but still fresh_requrest? should not set status

17:30 <namelessjon> merboutpost: Well, name can change.

17:33 <merboutpost> namelessjon: is this insane? return_fresh_request(:etag => '') if fresh_request?

17:34 <namelessjon> merboutpost: Yes. It wouldn't return from the action.

17:34 <namelessjon> merboutpost: Also, the etag would only be set after it was checked.

17:40 <merboutpost> namelessjon: ok don't do the wrapper, let people deal with it :-)

17:41 <merboutpost> namelessjon: or I thought: fresh_request(:etag => '') do _stuff_when_not_fresh end

17:42 <merboutpost> namelessjon: that still suffer it won't return from action

17:42 <namelessjon> merboutpost: I kinda want the wrapper. It's not _much_ code, but it would be much neater.

17:42 <namelessjon> merboutpost: Anyway, I'll play with the API, put a gist or a patch for you to look at

17:59 <merboutpost> namelessjon: I'm struggling with the #524

18:00 <merboutpost> namelessjon: I did: redirect(url, :permanent => true) OR redirect(url, :stauts => xxx) OR redirect(url, :permanent => true, :status => xy) where status takes precedence.... to keep backward compatibility

18:01 <namelessjon> merboutpost: That seems okay to me.

18:17 <merboutpost> namelessjon: so we have change file == change it to yard policy ? :-)

18:18 <merboutpost> namelessjon: would you solve it that simple http://github.com/pk/merb/commit/f38996c70d9e23ac7919694eeceb2c711e6c5c6b ?

18:18 <merboutpost> namelessjon: or I should add checking that the status should not be other than 3xx family?

18:19 <merboutpost> namelessjon: I think the check is redundant....

18:31 <namelessjon> merboutpost: I think that's about the only way we'll get yardocs. It's a lot of docs to change.

18:32 <namelessjon> merboutpost: Also, yeah, it probably is.

18:34 <namelessjon> merboutpost: Man, I'm totally stumped on this. Somewhere, if I return status = 304, I get an InvalidURIError

18:36 <namelessjon> merboutpost: Oh right, I found the problem. webrat is lazy.

18:38 <merboutpost> namelessjon: ?

18:39 <merboutpost> namelessjon: repushed http://github.com/pk/merb/commits/fix_524

18:39 <namelessjon> merboutpost: webrat's check for a redirect is (response_code / 100).to_i == 3

18:40 <merboutpost> namelessjon: Sometimes specs involves too much magic that we than test in so isolated environment it breaks in real

18:40 <merboutpost> namelessjon: you're joking.......

18:40 <merboutpost> namelessjon: that would be my WTF of the day ;-)

18:41 <merboutpost> namelessjon: do you have some "tools" to convert RDOCs to YARD? Or you did it by hand?

18:41 <namelessjon> merboutpost: http://github.com/brynary/webrat/blob/master/lib/webrat/core/session.rb#L158

18:42 <namelessjon> merboutpost: So when you return 304, it tries to parse the (non-existant) Location header to work out where to redirect.

18:43 <namelessjon> merboutpost: Bit of s/// in vim, for the :api:, but mostly it wasn't consistent enough.

18:44 <merboutpost> namelessjon: I thought about writing some vim macros or so

18:46 <namelessjon> merboutpost: Yeah. You could probably write one to fix params, for example.

18:46 <namelessjon> merboutpost: Of course, the file I picked to start this with only had like 6 methods, so ;)

18:56 <namelessjon> merboutpost: I might word it as "Status tStatus code to set for the response. Can be any valid redirect status codhas precedence over the :permanent parameter, which is retained for convience"

18:57 <namelessjon> That would have worked better if I was awake.