[Rails-core] Re: The Base class in Rails
Going back to the origin of the thread, I've always thought there's a missing ApplicationModel in Rails and in fact wrote a patch some time ago: http://dev.rubyonrails.org/ticket/10832 The only detail that I am doubting about is that Rails docs inherit from AR::Base in their example code and so Rails docs would change that to ApplicationModel. On the other hand AR can be used outside Rails where ApplicationModel would make no sense in general, and the docs are the same ones. Other than that, I'd personally like to have ApplicationModel someday. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: Rails.env is expensive
On Mon, Oct 13, 2008 at 2:42 AM, Ryan Bigg <[EMAIL PROTECTED]> wrote: > Honestly, what's so hard about calling RAILS_ENV == "production" > wherever it needs to be called? You can still do that of course, that's fine (though it does not look to me as modern Rails anymore). But the fact is Rails does provide Rails.env. Thus, analysis and discussion about its implementation makes sense in my view. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: The Base class in Rails
On Wed, Oct 15, 2008 at 11:34 PM, DHH <[EMAIL PROTECTED]> wrote: > I still like Base both as a name for what the thing is, it's the base > class of Active Record, and for its reusability across different > frameworks, like ActionController::Base, ActiveResource::Base, etc. But we've ApplicationController < AC::Base to put common stuff. Modulo de impedance in the docs I explained, don't you think ApplicationModel < AR::Base makes sense for the same purpose in Rails? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: The Base class in Rails
On Thu, Oct 16, 2008 at 10:12 AM, DHH <[EMAIL PROTECTED]> wrote: > >> Nothing prevents people, but ApplicationController is provided by the >> default Rails skeleton, and used by "script/generate controller". >> >> Having the same for ActiveRecord isn't entirely unreasonable, and wouldn't >> really require touching ActiveRecord -- just Rails generators. > > I've personally never felt the desire to include any such application- > specific behavior for all my Active Record models. And unlike Action > Controller, Active Record doesn't have a monopoly on the model space > in a Rails application (just think Active Resource or vanilla Ruby > objects). I frequently have non-AR models, so ApplicationModel would > be misleading. I see your point. I often reopen AR::Base (or include something, it doesn't really matter). In my experience that's all sharing I need. ApplicationModel would suggest there's a root class for the M layer, and that's not going to work. Yeah. So upon reflection what I miss is a root for AR models in the application, and ApplicationModel is a misleading name for it. Reopening AR::Base does the job, but I'd just prefer a well-defined application specific class provided by the skeleton and generators so you know where people are going to put shared stuff, instead of carefully inspecting config/initializers and lib (say). Given the mismatch such a new root class would imply for the documentation I am unsure it is worth the trouble, I can't think of a good proposal for this at this moment. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] listing of Rails contributors
I wrote this script to get a listing of Rails contributors for a talk (one slide or two with totals, some chart, etc.): http://pastie.org/301285 First of all I'd like to say there are practically 1000 people there, that's just amazing guys In my view that says a lot about the way the project deals with contributions. The listing is not exact due to the svn days, but I've spent some time scanning the output to try to identify the same person under different names, nicks, etc. to get the counters as right as possible. There's a hash table at the top of the script (emails hidden but complete in the original). Please, if you see there's a missing mapping for your name in the listing below just drop me a line! -- fxn 1887 Jeremy Kemper 1836 David Heinemeier Hansson 337 Rick Olson 334 Jamis Buck 280 Nicholas Seckar 278 Michael Koziarski 204 Joshua Peek 188 Marcel Molina 116 Pratik Naik 112 Sam Stephenson 109 Geoff Buesing 79 Tobias L√ºtke 76 Leon Breedt 76 Thomas Fuchs 72 Tarmo T√§nav 69 Sven Fuchs 41 Scott Barron 36 Josh Peek 35 Patrik Naik 35 Cheah Chu Yeow 32 Frederick Cheung 28 Tobias Luetke 27 Josh Susser 27 miloops 26 Manfred Stienstra 24 Nick Sieger 22 Florian Weber 22 Clemens Kofler 19 Kent Sibilev 16 danger 15 Stefan Kaes 15 Ryan Bates 15 fearoffish 14 Xavier Noria 14 jeremymcanally 13 Iain Hecker 13 thechrisoshow 13 Hongli Lai (Phusion) 13 Tom Ward 13 Tim Pope 13 court3nay 12 kampers 11 Caio Chassot 11 [EMAIL PROTECTED] 11 Lucas Carlson 11 mikong 10 lawrence 10 Luca Guidi 10 Tim Bates 10 John Barnette 10 Kevin Clark 10 norbert 9 Scott Baron 9 BobSilva 9 Nick 9 skaes 8 bscofield 8 manfred 8 Ernesto Jimenez 8 Matt Jones 8 mpalmer 8 Henrik N 8 Mislav Marohniƒá 8 Jan De Poorter 7 [EMAIL PROTECTED] 7 cavalle 7 Tom Lea 7 Chad Fowler 7 Alisdair McDiarmid 7 Juanjo Bazan 7 Dan Peterson 7 Jonathan Viney 7 Aliaksey Kandratsenka 7 Eric Hodel 7 Dave Thomas 7 John Long 7 [EMAIL PROTECTED] 7 Michael Schoen 7 [EMAIL PROTECTED] 6 skae 6 sandofsky 6 [EMAIL PROTECTED] 6 adymo 6 Catfish 6 Jos√(c) Valim 6 matt 6 Bob Silva 6 [EMAIL PROTECTED] 6 eventualbuddha 5 [EMAIL PROTECTED] 5 Ulysses 5 dasil003 5 Florian Gross 5 Daniel Schierbeck 5 sjgman9 5 caio 5 tzaharia 5 Sean Treadway 5 dblack 5 coffee2code 5 mindel 5 kamal 5 Steve Purcell 5 what-a-day 5 Alexey 4 protocool 4 Jakob S 4 [EMAIL PROTECTED] 4 Aleksey Kondratenko 4 skaen 4 jamesh 4 Maik Schmidt 4 [EMAIL PROTECTED] 4 Michael Shuerig 4 xaviershay 4 Jeffrey Hardy 4 zenspider 4 [EMAIL PROTECTED] 4 Rich Collins 4 Eugene Pimenov 4 h-lame 4 Marko Seppae 4 [EMAIL PROTECTED] 4 jarkko 4 Leon Bredt 4 [EMAIL PROTECTED] 4 [EMAIL PROTECTED] 4 Eric Anderson 4 lazyatom 4 Ryan Tomayko 4 RubyRedRick 4 [EMAIL PROTECTED] 4 rubyruy 3 Blair Zajac 3 rmm5t 3 David Lowenfels 3 Chris McGrath 3 Michael Schuerig 3 drnic 3 boone 3 lotswholetime 3 xal 3 adam 3 Tim Haines 3 jordi 3 Steven Soroka 3 rasputnik 3 [EMAIL PROTECTED] 3 Flurin Egger 3 [EMAIL PROTECTED] 3 Lawrence Pit 3 [EMAIL PROTECTED] 3 Akira Matsuda 3 [EMAIL PROTECTED] 3 evan 3 nik.wakelin 3 Daniel Guettler 3 [EMAIL PROTECTED] 3 Lars Pind 3 Miles Georgi 3 Francois Beausoleil 3 [EMAIL PROTECTED] 3 demetrius 3 Andreas Schwarz 3 akaspick 3 [EMAIL PROTECTED] 3 murphy 3 Rich Cavanaugh 3 Robby Russell 3 Nathan Witmer 3 mikel 3 [EMAIL PROTECTED] 3 roderickvd 3 jonathan 3 Kevin Glowacz 3 [EMAIL PROTECTED] 3 Will Bryant 3 shugo 3 Duane Johnson 3 Damian Janowski 3 Frederick Ros 3 Andrew Kaspick 3 Ryan Carver 3 Eloy Duran 3 Ernie Miller 3 [EMAIL PROTECTED] 3 Chris Wanstrath 3 Sebastian Kanthak 3 David Dollar 3 [EMAIL PROTECTED] 3 mnaberez 3 [EMAIL PROTECTED] 3 ssoroka 3 Caleb Tennis 3 DeLynn 3 [EMAIL PROTECTED] 3 richcollins 3 madlep 3 Andre Arko 3 Doug Barth 3 Trevor Turk 3 tomafro 3 evl 3 Antonio Cangiano 3 thomas.lee 3 Chad Woolley 3 Jacek Becela 3 Tim Harper 3 joost 3 Cody Fauser 2 Jamis 2 eigentone 2 mutru 2 John Sheets 2 [EMAIL PROTECTED] 2 queso 2 Daniel Morrison 2 stopdropandrew 2 [EMAIL PROTECTED] 2 yerejm 2 George Ogata 2 dcmanges 2 bgreenlee 2 Peter Wagenet 2 Stuart Halloway 2 jkit 2 Ian White 2 Adam 2 [EMAIL PROTECTED] 2 Brennan Dunn 2 mrj 2 Giles Bowkett 2 alloy 2 Rob Anderton 2 ? 2 Irfy 2 matrix9180 2 Robert Evans 2 codahale 2 wesley.moxam 2 John D. Hume 2 GMFlash 2 [EMAIL PROTECTED] 2 oleganza 2 [EMAIL PROTECTED] 2 [EMAIL PROTECTED]
[Rails-core] Re: listing of Rails contributors
Oh shit there's a typo in Pratik's name in the hash, it's corrected now, sorry! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: listing of Rails contributors
2nd version. Counters have changed and grand total now is ~1400 people! http://pastie.org/301335 Awesome! Reason is Pratik recalled in svn some attributions were done in the changelog instead of the commit message. svn authors extraction is done now this way: 1. First extract authors from commit message 2. (new in v2) If empty, check changelogs via `git show id` 3. If empty, author is the committer The revised script is here: http://pastie.org/301336 Some mappings were added as well with the help of Pratik and Mike Gunderloy. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: listing of Rails contributors
On Mon, Oct 27, 2008 at 3:01 PM, Josh Susser <[EMAIL PROTECTED]> wrote: > This is pretty cool to see, but I think it's going to be nigh > impossible to get anything like an accurate list. Even since the move > to github, some core members have been doing commits that don't > include attribution to the original author of the patch (hi, David!), > and even when attribution is made, there's no way to give credit to > all the people who contributed to the patch who weren't the author of > the ticket or the git .diff file. I also see a lot of unmatched > duplicates in your list - look at the two spellings of Tobi's name on > lines 17 and 18 in your list and Kevin Clark on lines 33 and 86, for > examples. And I know my name shows up in the changelog several > different ways too, so who knows. Yeah I saw a few of them and put them in the hash. > Anyhoo, I don't know exactly how you plan to use this data, so that > might all be fine for your purposes. But either way I think it's > great to see even a rough number of the people who've done so much for > Rails. Agreed. Indeed my goal is just to be able to have a slide that says ~1400 contributors and do some rough chart. That's in the context of a section of my keynote where I talk about the project. I tried to cope with a few things you could deal with to try to get a figure close enough with some reasonable heuristics, but of course there's no way you can get an accurate listing. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: listing of Rails contributors
3rd version. Same algorithm but I've got several mappings off-list: http://pastie.org/301432 Yeah, looks like ~1400 is a reasonable figure. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: listing of Rails contributors
> Yep, my name is there in four different places. Great I've added: 'Jarkko Laine' => ['[EMAIL PROTECTED]', 'Jarkko', 'jarkko'] and a few more, like Obie and others: http://pastie.org/301581. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: listing of Rails contributors
On Mon, Oct 27, 2008 at 6:57 PM, Andrew Kaspick <[EMAIL PROTECTED]> wrote: > > 'Andrew Kaspick' => ['[EMAIL PROTECTED]','akaspick'] if it matters Absolutely man! Following a suggestion by Damian Janowski I've switched to gist in order to have a single URL: http://gist.github.com/20150 Following updates will go there. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: listing of Rails contributors
On Mon, Oct 27, 2008 at 7:09 PM, Xavier Noria <[EMAIL PROTECTED]> wrote: > On Mon, Oct 27, 2008 at 6:57 PM, Andrew Kaspick <[EMAIL PROTECTED]> wrote: >> >> 'Andrew Kaspick' => ['[EMAIL PROTECTED]','akaspick'] if it matters > > Absolutely man! > > Following a suggestion by Damian Janowski I've switched to gist in > order to have a single URL: > > http://gist.github.com/20150 > > Following updates will go there. Just for the list archives: Several equivalences have been taken into account. Now moved to http://gist.github.com/20721 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: listing of Rails contributors
On Wed, Oct 29, 2008 at 7:29 PM, Eloy Duran <[EMAIL PROTECTED]> wrote: > > Hi, > > Got one more for you :) > > [EMAIL PROTECTED] & [EMAIL PROTECTED] => Thijs van der Vossen Great, I've spotted "thijsv" as well and updated the list. Thank you Eloy! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: listing of Rails contributors
On Thu, Oct 30, 2008 at 3:08 AM, Sam Granieri <[EMAIL PROTECTED]> wrote: > Here's another alias for you: > sjgman9 => Sam Granieri Excellent, updated, thank you very much! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: listing of Rails contributors
On Thu, Oct 30, 2008 at 8:41 AM, Jonathan Weiss <[EMAIL PROTECTED]> wrote: > > jweiss => Jonathan Weiss Great, list updated, thank you! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: listing of Rails contributors
On Thu, Oct 30, 2008 at 9:52 AM, Spakman <[EMAIL PROTECTED]> wrote: > Here's another: > > Spakman => Mark Somerville Cool. Added and updated thanks! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: listing of Rails contributors
On Thu, Oct 30, 2008 at 3:26 PM, Jordi Bunster <[EMAIL PROTECTED]> wrote: > On the svn days, I went by "jordi" inside the []. Since git, I'm just > myself, Jordi Bunster. Added, thanks Jordi! The list has now complete email addresses to easy searches: http://gist.github.com/20721 This is the current script with guessable addresses in the mapping as well: http://pastie.org/304092 At this moment it has +70 entries and we're close to a grand total of 1350 people. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: listing of Rails contributors
Scores are higher in general now. When the author of a svn commit is not seen in the commit message the script checks changelog entries in git show. A sanity #uniq was applied there. But it turns out some commits like 752721c0729bd8230d9cd0688694c36f71db03f0 or f18356edb728522fcd3b6a00f11b29fd3bff0577 are big and have lots of changelog items, so that #uniq was indeed covering some contributions. The current listing is http://gist.github.com/20721 and there are ~1340 people right now. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: listing of Rails contributors
On Sat, Nov 8, 2008 at 2:25 AM, Jonathan Viney <[EMAIL PROTECTED]> wrote: > I'm in there under Jonathan Viney and [EMAIL PROTECTED], those could > be combined. Excellent, gist updated thank you! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: listing of Rails contributors
2008/11/8 José Valim <[EMAIL PROTECTED]>: > Just accent fix: > > Jos√(c) Valim => José Valim Thank you José! Do you see that one in the current gist? http://gist.github.com/20721 The initial lists piped the output of the script to pbcopy + ⌘V and non-ASCII was mangled. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: listing of Rails contributors
On Mon, Nov 10, 2008 at 1:27 AM, Steven Bristol <[EMAIL PROTECTED]> wrote: > Steven Bristol is the same as stevenbristol Great, updated: http://gist.github.com/20721 The current script is here: http://gist.github.com/23458 I may create a repo and a page somewhere after the conference. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: listing of Rails contributors
On Mon, Nov 10, 2008 at 4:26 PM, Steven Soroka <[EMAIL PROTECTED]> wrote: > Seems like this work is somewhat duplicating what the WWR hackfest > already did, no? The motivation for this effort is to be able to present a slide with a figure that I can show with confidence (I am preparing a keynote that has a section with a few metrics about the project). The current approximation is 1300 people. I can't thank enough all the people that have contributed equivalences! As for the script that computed the hackfests in WWR I don't really think it had any mapping like this. I remember in order to increase your score you had to appear in the message/changelog in a certain way, your user in Trac or something like that. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: listing of Rails contributors
On Mon, Nov 10, 2008 at 10:58 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > "MatthewRudy" > and "Matthew Rudy Jacobs" Excellent, gists updated, thank you! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: listing of Rails contributors
On Mon, Nov 10, 2008 at 9:25 PM, Jakob Skjerning <[EMAIL PROTECTED]> wrote: > > > On 10/11/2008, at 10:07, Xavier Noria wrote: > >>http://gist.github.com/20721 > > For what it's worth, "Jakob S" == "jakob ~ at ~ mentalized.net" One more :-), it's up thank you! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: listing of Rails contributors
On Tue, Nov 11, 2008 at 1:11 AM, Ruy Asan (rubyruy) <[EMAIL PROTECTED]> wrote: > "Ruy Asan" => "rubyruy" Up, thank you! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: listing of Rails contributors
On Tue, Nov 11, 2008 at 3:14 AM, Ryan Bigg <[EMAIL PROTECTED]> wrote: > I am on there as Radar. Great, gists updated thank you! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: listing of Rails contributors
On Wed, Nov 12, 2008 at 2:17 PM, jodosha <[EMAIL PROTECTED]> wrote: > l.guidi -> Luca Guidi Thank you Luca, it's up. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: listing of Rails contributors
Just wanted to thank all the people helping in this effort, we got close to 1300 and that was the figure I presented. I plan to mantain that script + listing in some way or another, perhaps a page somewhere. If you see any other mapping please send it to me! I gathered more metrics about the project like published books (+60), commits per quarter, number of plugins (with help from Benjamin Curtis), etc. Some people asked for the final presentation, it is here: http://www.slideshare.net/fxn/revolucion-rails-presentation/ Topic was revolutions and disruptiveness. Slides are mostly bulletless. The keynote was recorded as well (Spanish), it is the second item here: http://isabel.dit.upm.es/component/option,com_docman/task,cat_view/gid,131/Itemid,74/ Due to technical issues with the video system I couldn't use Keynote and had to present a flat PDF file. Best regards to all!!! -- fxn --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: listing of Rails contributors
Names in CHANGELOGs are going to be normalized with the mapping that resulted from the effort in this thread: http://gist.github.com/23458 This is the current patch: http://rails.lighthouseapp.com/projects/8994/tickets/1495 Please if you'd like to have a different "canonical" name/nick/whatever just drop me a line! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] style for inline comments in dynamically generated methods
Just a sync mail. Dynamically generated methods have now inline comments that depict an instance of the generated code: http://github.com/rails/rails/commit/a2270ef2594b97891994848138614657363f2806 That was inspired by wycats's: http://github.com/rails/rails/commit/6dc12881110d26bb952bd0f565623144f10a07b6 Please take that style into account :-). We iterated a bit over the details on IRC. Comments are 2 spaces apart. If the line gets really too long (say, beyond column 200) first we try to refactor the code to shorten stuff. If not possible we move the comment above the *_eval call. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: Last call for patches - 2.3 final is imminent
More wood! http://rails.lighthouseapp.com/projects/8994/tickets/1995-skip_relative_url_root-is-broken --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: Rails 2.3 HTTP parameter extraction order
On Sun, Mar 22, 2009 at 7:56 AM, tekwiz wrote: > In the docs for ActionView::Helpers::FormHelper#check_box, when > discussing why the method adds a hidden input tag _after_ the checkbox > tag, it says > > "...Rails parameters extraction always gets the first occurrence of > any given key..." > > I'm not sure this is still the case. Indeed it changed in 2.3 but unfortunately the patch didn't update the docs. We noticed this a few days ago, they are correct now in edge. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: http://api.rubyonrails.org/ out of date again
On Tue, Mar 24, 2009 at 5:07 PM, Jeff wrote: > Can someone who has access to the http://api.rubyonrails.org/ website > regenerate the rdocs? It doesn't seem to have been updated for 2.3, API is 2.3, but I know some bit that was not updated... what did you miss? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: http://api.rubyonrails.org/ out of date again
On Sun, Mar 29, 2009 at 10:45 PM, Mislav Marohnić wrote: > On Sun, Mar 29, 2009 at 21:01, Xavier Noria wrote: >> >> On Tue, Mar 24, 2009 at 5:07 PM, Jeff wrote: >> >> > Can someone who has access to the http://api.rubyonrails.org/ website >> > regenerate the rdocs? It doesn't seem to have been updated for 2.3, >> >> API is 2.3, but I know some bit that was not updated... what did you miss? > > First of all, it was generated on Feb 1st and 2.3.2 was released March 15. > It's hard to believe no documentation patches got in in that month and a > half. You're right, there are pending updates. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] listing of Rails contributors
Hi people! Perhaps you remember that effort started some months ago to try to get a good listing of Rails contributors: http://groups.google.com/group/rubyonrails-core/browse_thread/thread/7554c8c5a25b4765 I got plenty of feedback and kept maintaining the list in this gist: http://gist.github.com/20721 I am happy to announce that we've turned that script into a simple webapp that will run under contributors.rubyonrails.org or www.rubyonrails.org/contributors. You can check it out now without design at http://rails-contributors.hashref.com/ I am very glad this is going to be public, it gives credit to hundreds of people that have contributed to the project (about 1400 at this moment). And it is a good indicator in my view of the agility and openness of Rails as an open source project. Also you can just point to that data when someone says it is hard to contribute to Rails, a myth I've heard sometimes. The app is mostly finished at this point, I may add some caching and more tests but that's it. The current name normalization is explained here: http://rails-contributors.hashref.com/names_mapping If you know of anyone who may help wit the design that'd be really great! If you discover any missing name equivalence please just PM me somewhere. -- fxn PS: http://github.com/fxn/rails-contributors/tree/master --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: listing of Rails contributors
On Fri, Apr 3, 2009 at 12:37 AM, Mislav Marohnić wrote: > This is great. I'd love for its permanent home to be > rubyonrails.org/contributors. > Two things: > > did anyone notice the long tail effect? hehe > is the list going to be live (think github post-receive hook) That's the idea, though the way to update is not yet defined. We'll sort it out when we are ready to deploy it. The entry point is just a call to Repo.update(/path/to/working/copy) so we have options. That pulls, understands changes in the mappings, if any, and updates the database. After pulling that's a fraction of a second so it could be triggered by a hook no prob. A cron job would do but I kind of dislike "Last updated at ..." messages, I'd prefer it to be really live. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: redesigning mass attribute assignment (activerecord 3.0?)
On Tue, May 26, 2009 at 12:42 PM, Hongli Lai wrote: > I agree. Lance raises very valid points, but what would what's wrong > with using Hash#slice and Hash#except to solve these problems? > Especially if the documentation for attr_accessible/attr_protected can > be updated to refer to the usage of Hash#slice and Hash#except for > more complex use cases? Yeah I've added it http://github.com/lifo/docrails/commit/6197606588674bd16e17899e0df15adf2a482ba0 I think a concrete application will probably need some controller macro to be able to express those tweaks at a higher level. But the basic technique to build upon is documented there anyway. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: redesigning mass attribute assignment (activerecord 3.0?)
On Tue, May 26, 2009 at 10:30 PM, Matt Jones wrote: > One other thought - going back to the original example (admin user can > mass-assign fields that are normally protected), what about an extra > parameter to update_attributes (and possibly create)? ie: > > @model.update_attributes(params[:whatever], > [:stuff_non_admins_cant_change]) > > So essentially a, "no, really, you can mass-assign these attributes > just this once" parameter. That would still allow regular code to work > correctly while permitting the context-sensitive stuff you're looking > for. Certainly the Hash#except idiom requires you whitelist (or not-blacklist) sensitive data, because attr_(accessible|protected) are of course applied to whatever sanitized hash you pass. So in particular you can only narrow accessible aattributes (or extend protected attributes) Going the other way around sounds better to me, not sure about the API though. I think it requires the same amount of configuration and exceptions, but looks like a safer default. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: redesigning mass attribute assignment (activerecord 3.0?)
On Thu, Jun 11, 2009 at 8:36 PM, Chrisis wrote: > The form fields I specify in the form are the only fields the user is > allowed to change on that particular entry point. Why dont we take > this given as leading and mould our controllers and models to this set > of allowed fields? Imagine a multi-account invoicing application that has a customer selector in the form for invoice creation. That customer_id has to be protected to prevent users from injecting customer_ids belonging to other accounts. Yet it belongs to the form. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] no-brainer patch for Active Support
I am revising AS stuff in the framework while covering core extension for the AS guide. There are class reopenings in Action Pack to add generic stuff like TrueClass#to_param whose natural place would be AS/core_ext in my view (where Array#to_param and friends live). Even Object#to_param is defined twice. I've refactored them out to standard places in AS, and added test coverage which was lacking as well: https://rails.lighthouseapp.com/projects/8994/tickets/2798 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Rails Contributors: do you know these people?
I've being doing a great deal of googling these days to identify people by their handlers or emal addresses for contributors with 4 or more commits, but would need some help with these names: http://contributors.rubyonrails.org/contributors/adam/commits http://contributors.rubyonrails.org/contributors/thedarkone/commits http://contributors.rubyonrails.org/contributors/ulysses/commits http://contributors.rubyonrails.org/contributors/what-a-day/commits http://contributors.rubyonrails.org/contributors/andreas/commits http://contributors.rubyonrails.org/contributors/demetrius/commits http://contributors.rubyonrails.org/contributors/jonathan/commits http://contributors.rubyonrails.org/contributors/mindel/commits http://contributors.rubyonrails.org/contributors/obrie/commits http://contributors.rubyonrails.org/contributors/blaine/commits http://contributors.rubyonrails.org/contributors/evl/commits http://contributors.rubyonrails.org/contributors/jamesh/commits http://contributors.rubyonrails.org/contributors/moro/commits Do you recognize yourself or someone you know under any of those handlers? Any feedback would be appreciated :). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: Rails Contributors: do you know these people?
One more: http://contributors.rubyonrails.org/contributors/alexey/commits BTW the current mapping is: http://contributors.rubyonrails.org/names_mapping --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: Rails Contributors: do you know these people?
On Sat, Jul 18, 2009 at 2:03 AM, Michael Koziarski wrote: > > Ulysses is nick seckar In production, thank you! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: Rails Contributors: do you know these people?
On Sun, Jul 19, 2009 at 12:37 AM, a_matsuda wrote: > Thank you for your hard work! > > On 2009/07/18, at 8:38, Xavier Noria wrote: > >> http://contributors.rubyonrails.org/contributors/moro/commits > > I know this guy. His full name in alphabet is: > > Kyosuke Morohashi > > BTW, I found myself in the list > http://contributors.rubyonrails.org/contributors/akira-matsuda/commits > and noticed that one commit of mine is missing because I made it by a > different author name. > http://github.com/rails/rails/commit/bb33432b0f5bf644713e696e4dafc7e7d3cc5808 > > Could you merge that commit into Akira Matsuda's list somehow? > # It might be difficult to handle because it's written in Japanese > # multibyte chars by mistake... > # Please ignore if it's not a very easy thing to deal with for you. Nothing can challenge the ubernormalizer!!! :-) Both equivalences are up in production, thank you man! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: unable to generate local rdocs?
On Fri, Jul 17, 2009 at 4:55 AM, rogerdpack wrote: > Currently if I do a gem fetch rails, gem unpack xxx.gem > cd xxx > rake rdoc > > I get this: > > Generating HTML... > Could not find HTML template '../doc/template/horo' > > and the doc file remains empty. Is this expected? By trial and error I had the impression that some Rakefiles have doc tasks that are obsolete or perhaps need something that is not in the repo. For a single gem you can get something via the rdoc command. Publishing the public API is the job of release.rb. The tasks involved there do work, as long as you have the Jamis template and an RDoc older than 2.4. We are working on bringing the API to RDoc 2.4, more to come about this. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: Opinion about new finder: :unique
On Sat, Aug 1, 2009 at 8:33 PM, Jason King wrote: > It's a very slippery slope if the core starts trying to predict and > protect developers from non-Rails assumptions. I agree. It is kind of a finder mixed with an assertion. Doesn't fit in core in my view. It's easy to write it yourself nonetheless. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] why Array.wrap ?
Hey Active Support defines Array.wrap (copied below). What's the difference between that and the Ruby builtin Array() method: Array(nil) # => [] Array([0]) # => [0] class C def to_ary [0] end end Array(C.new) # => [0] Array(0) # => [0] Perhaps it was just an overlook that Array() exists? -- fxn class Array # Wraps the object in an Array unless it's an Array. Converts the # object to an Array using #to_ary if it implements that. def self.wrap(object) case object when nil [] when self object else if object.respond_to?(:to_ary) object.to_ary else [object] end end end end --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: why Array.wrap ?
On Mon, Aug 24, 2009 at 11:33 PM, Pratik wrote: > IIRC, it's different on 1.9. Ah I tried as well with same result: [xno...@ruby-versions ~]$ irb191 irb(main):001:0> Array(nil) => [] irb(main):002:0> Array(0) => [0] irb(main):003:0> Array([0]) => [0] ... irb(main):007:0> irb(main):008:0* class C irb(main):009:1> def to_ary irb(main):010:2> [0] irb(main):011:2> end irb(main):012:1> end => nil irb(main):013:0> Array(C.new) => [0] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: why Array.wrap ?
On Mon, Aug 24, 2009 at 11:58 PM, Jeremy Kemper wrote:
> Array("foo\nbar") # => ["foo\n", "bar"]
>
> Array.wrap("foo\nbar") # => ["foo\nbar"]
Excellent I'll the hash example and those to the RDoc and AS guide.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~--~~~~--~~--~--~---
[Rails-core] Re: why Array.wrap ?
On Tue, Aug 25, 2009 at 12:40 AM, Xavier Noria wrote: > Flanafan & Matz Ugh sorry, Flanagan. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: why Array.wrap ?
On Mon, Aug 24, 2009 at 11:38 PM, Michael Koziarski wrote: > > There's also: > >>> Array(:a=>:b) > => [[:a, :b]] >>> > > Mighty annoying. Ah yes, Array() calls #to_a also. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: why Array.wrap ?
On Tue, Aug 25, 2009 at 12:25 AM, Jeremy Kemper wrote: > Array() does too much. We want a uniform wrapper with no surprises. Understood. I wanted to know the difference because I am documenting it. According to the Pickaxe and Flanafan & Matz the difference is exactly that Array.wrap does not call to_a, and those examples depict this. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: why Array.wrap ?
On Mon, Aug 24, 2009 at 11:33 PM, Pratik wrote:
> IIRC, it's different on 1.9.
That's true, for example the return value of Array("foo\nbar") depends
on the Ruby version because strings are not enumerables in 1.9. So you
get ["foo\nbar"] in 1.9, and ["foo\n", "bar"] in 1.8.
So Array.wrap is portable as long as +to_ary+ is portable.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~--~~~~--~~--~--~---
[Rails-core] Re: Rails internals documentation guides
On Sun, Sep 13, 2009 at 2:39 AM, Rodrigo Rosenfeld Rosas wrote: > Docrails will eventually be outdated, since it is a separated project > and it is always behind main development. I don't really know what you mean here. docrails is a branch. The Rails Documentation Team are *not* the documenters of Rails, we are the guys that have an eye in that area of the project, just that. Sure, we do a lot of work on the API, but the Rails documentation comes from patches to master. If a patch is not properly documented it should not be accepted as if it hadn't tests. You know docrails and master are cross merged regularly, there's no way it can become outdated because docrails works directly against the Rails repo. It has its own branch to be able to offer an open policy with a little safety net and strict rules about not touching code. With the purpose of agilizing doc patches that should go the LH way and good luck otherwise. We're doing the guides as well. We commented with Pratik and Mike that code patches should patch guides, but that is not being enforced in practice. As per verisioning, docrails always documents edge, both in API an guides. If you want the docs of a release you take its snapshot (guides are included in Rails releases). The public websites only have stable and edge. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: Rails internals documentation guides
On Sun, Sep 13, 2009 at 3:34 PM, Rodrigo Rosenfeld Rosas wrote: > That is exactly what I meant. I was not complaining. But since the > guides documentation are not an official documentation, Why do you say that? The guides live under rubyonrails.org, are coordinated by the Rails Documentation Team, whose leader is a core team member. Guides are included in the Rails distribution. They are as official as you can get. > there are no > concerns in updating the guides when something changes in source-code in > the same patch. I guess most core developers didn't even read all guides > so that they are aware of changes that possible affect the guides. The > consequences are that the guides will eventually be outdated until > someone notes and updates its documentation to reflect the new changes. Yeah that's a risk. The good news is that guides are under the umbrella of docrails. So updating them is quite easy and that's happening. It could be the case that doesn't happen, certainly, but it can be the case it does. The setup is streamlined and well-supportted to help making that possible. > This is a bit dangerous in my opinion if we want to welcome new > developers. Documentation is one of the most important roles in any > framework. Agreed. For newbies, and for experienced developers also. I personally consult the API everyday, it is very important that it is as good as possible. Complete, with good examples, uniform conventions, etc. That's why I joined docrails as soon as Pratik announced it. > I am always concerned about new adopters and trying to get their > experiences as smooth as possible. That's good. > Congratulations for your work in docrails, by the way. Thank you! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: Rails 3 and Rack compatibility
On Fri, Oct 16, 2009 at 4:18 PM, Joshua Partogi wrote: > Is the latest Rails 3 compatible with Rack 1.0.0 ? I think it isn't: http://github.com/rails/rails/commit/ef70ad5538c4ce02c4d31ef01a8db6b55c837571 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: Make model.number = "1 234" store 1234 instead of 1?
On Mon, Oct 26, 2009 at 10:17 AM, Henrik N wrote: > Since our users have been complaining about putting "1 234" in a form > and having 1 stored instead of 1234 (because of how to_i/to_f works), > I made a simple monkeypatch to get their expected behavior: Don't see this in core. Looks like a custom numerification that makes sense in your application. Both that one and Rails' make arbitrary assumptions about what they tolerate, but Rails is coherent with Ruby and I think the current behaviour is better because of that. Custom rules, yours or others, can be programmed as needed. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: Make model.number = "1 234" store 1234 instead of 1?
On Mon, Oct 26, 2009 at 1:48 PM, Henrik N wrote: > On Oct 26, 1:09 pm, Xavier Noria wrote: >> Don't see this in core. >> >> Looks like a custom numerification that makes sense in your >> application. Both that one and Rails' make arbitrary assumptions about >> what they tolerate, but Rails is coherent with Ruby and I think the >> current behaviour is better because of that. > > I wouldn't call it arbitrary. My proposed behavior is based on how end > users realistically may input numbers, and it improves their > experience without any added ambiguity that I can think of. Support > for commas/periods as thousand separators *would* add ambiguity since > that is locale-dependent, but to my knowledge spaces in numbers are > unambiguous across locales. I understand it is not arbitrary in the sense that it is based on the feedback of some users of *your* application. I didn't mean it is a blind customization, but that is as arbitrary a priori as removing any spurious character. I have applications where numeric input filters remove any \D that is not a comma or a period becaue that make sense for them, so I understand your motivation. Removing \D is as arbitrary as removing \s in my view, and thus I prefer the programmer to do that, instead of core to do that by default. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: Make model.number = "1 234" store 1234 instead of 1?
On Mon, Oct 26, 2009 at 4:38 PM, Henrik N wrote: > I would like to see specific examples of why it might be a bad idea to > remove the spaces. I'm hearing nays but I don't get what issues you > see with this. I do see the benefits, though: more intuitive and human- > friendly input handling. Hey, this is not a back and white issue. You propose a patch in -core, and you get feedback. My feedback is that I do not see it in core. In my view being tolerant to spaces can make sense for some, but that means that 12 678 is goona be 12678 by default in Rails. I don't buy that's good. I don't think that interpretation is any better than 12 a priori. So albeit I understand your motivation, as I said, I think the current default is just as valid as yours, and in addition coherent with what a Ruby programmer would expect from a string to number conversion. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Re: Make model.number = "1 234" store 1234 instead of 1?
On Tue, Oct 27, 2009 at 11:46 AM, Henrik N wrote: > It seems we simply disagree about whether user experience > trumps consistency. I think we rather disagree on whether that gives a significant better user experience. For you it is clear it does, for me (and I guess a few others) the patch just relaxes number input in one of a miriad ways. In particular I don't see why given 12 678 you one should pick 12678. I don't see why you don't pick 1000 out of $1000 Wouldn't that be useful? What would a user could possibly mean other than 1000? One could ask. Given that I think the weakness in the patch is as arbitrary as any other numerification that accepts strings that do not contain well-formed numbers. That is, everything being equal (again, in my opinion), I chose the behaviour that is consistent with Ruby. Because everything being equal we get *in addition* expected behaviour from for the programmer. And in any case it is configurable if an application has custom rules. I understand you disagree, that's OK :). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
[Rails-core] Rails Contributors
Hey just a brief mail to let you know I've done some systematic work on Rails Contributors in the past weeks: Tried to resolve every email address, and checked all handlers that exist as github usernames. At this moment there are 337 email addresses and 440 handlers resolved (over time). Due to this pass the grand total of contributors has gone from 1420 down to 1327, because some of the resolved emails or github usernames corresponded to already existing full names. Some email addresses are unreachable, and some github usernames belong to people who are not the authors of the corresponding commits. They are listed at the top of this file: http://github.com/fxn/rails-contributors/blob/master/app/models/names_manager.rb Please if you recognize any of them just drop me a line! The listing is converging after all these months, and I think we can already compute some meaningful-enough numbers/graphs, like new contributors per month, etc. I'd like to add them in the future. That's it. Best regards to all! -- fxn -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] default_url_options documentation
Please do not hesitate to join docrails for doc patches, it is much
more agile and we put one ticket less in LH.
Sent from my iPhone
El 30/11/2009, a las 16:44, Jeffrey escribió:
> The embedded documentation for ActionController#default_url_options()
> is incomplete, inaccurate or at least misleading. Applying it as
> shown to an application will cause the automated tests to fail on
> argument count mismatches. And other tests that check host in URLs
> may start failing if :host is overwritten. The patch below corrects
> both problems. It is against Rails 2.3.5. It probably also applies
> to earlier versions.
>
> Jeffrey
>
> --- base.rb~2009-11-28 17:56:00.0 -0600
> +++ base.rb2009-11-30 09:35:43.0 -0600
> @@ -1062,8 +1062,8 @@
> # Overwrite to implement a number of default options that all
> url_for-based methods will use. The default options should come in
> # the form of a hash, just like the one you would use for
> url_for directly. Example:
> #
> - # def default_url_options(options)
> - # { :project => @project.active? ? @project.url_name :
> "unknown" }
> + # def default_url_options(options = nil)
> + # super( { :project => @project.active? ?
> @project.url_name : "unknown" } )
> # end
> #
> # As you can infer from the example, this is mostly useful for
> situations where you want to centralize dynamic decisions about the
>
> --
>
> You received this message because you are subscribed to the Google
> Groups "Ruby on Rails: Core" group.
> To post to this group, send email to rubyonrails-
> c...@googlegroups.com.
> To unsubscribe from this group, send email to
> rubyonrails-core+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/rubyonrails-core?hl=en
> .
>
>
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To post to this group, send email to rubyonrails-c...@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] ActiveSupport for Rails 3
I'll do a sistematic pass over all core extensions checking these dependencies. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Re: proposing Object#nonblank? (analogous to Ruby's Numeric#nonzero?)
A predicate returns a true or false value. Albeit an implementation may choose some particular true or false value for convenience, I think it is not a good practice for client code to depend on it. I am -1 because I think a predicate should document only a boolean contract. On the other hand it is something you can easily add to your app, as you've been doing. Sent from my iPhone El 27/12/2009, a las 17:58, ColinDKelley escribió: >> We already have Object#present? :) > > True, but present? is just the inverse of blank?. What we've found > very useful is to have a method that treats blank parameters the same > as missing ones, and allows chaining. > > Check out the example: > > state = params[:state] unless params[:state].blank? > country = params[:country] unless params[:country].blank? > region = state || country || 'US' > > Rewriting with present? isn't any more expressive: > > state= params[:state] if params[:state].present? > country = params[:country] if params[:country].present? > region = state || country || 'US' > > But nonblank? makes it more concise and expressive IMO: > > region = params[:state].nonblank? || params[:country].nonblank? || > 'US' > > We've been using it this way for the last year and it really has > cleaned up a lot of code. More importantly it has become a reflex to > use it inline--as shown above--that has helped us avoid bugs where we > might think a parameter was present but really it was just there with > an empty value. > > I suppose we could keep the method name present? but switch its > behavior to match what's proposed here for nonblank?. But that > contract change could break someone's code who was depending on a > boolean being returned. Also I prefer that nonblank? has a name that > parallels nonzero? from Ruby. > > I like the symmetrical pair of nonzero? and nonblank? because they map > values (0, empty/blank string respectively) to nil that are typically > equivalent to not being present at all. Other languages like Python > found it convenient to have 0 and empty string treated as false for > just this reason I think. > > -Colin > > > On Dec 27, 5:37 am, Pratik wrote: >> We already have Object#present? :) >> >> >> >> >> >> On Sun, Dec 27, 2009 at 7:49 AM, ColinDKelley >> wrote: >>> All, >> >>> I'd like to propose the Object#nonblank? in ActiveSupport, layered >>> over the blank? method. This has been working well for us in the >>> past >>> year and hopefully others will find it useful enough to include in >>> core. >> >>> It is analogous to Ruby's Numeric#nonzero? method: it either returns >>> the object itself (if not blank) or nil (if blank). This makes it >>> easy >>> to treat blank parameters the same as missing ones, and allows >>> chaining: >> >>> For example, this: >> >>> state = params[:state] unless params[:state].blank? >>> country = params[:country] unless params[:country].blank? >>> region = state || country || 'US' >> >>> becomes: >> >>> region = params[:state].nonblank? || params[:country].nonblank? || >>> 'US' >> >>> The ticket is here: >> >>> https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/3 >>> ... >> >>> along with a patch that includes full documentation and tests. >> >>> -- >> >>> You received this message because you are subscribed to the Google >>> Groups "Ruby on Rails: Core" group. >>> To post to this group, send email to rubyonrails-core@googlegroups.com >>> . >>> To unsubscribe from this group, send email to >>> rubyonrails-core+unsubscr...@googlegroups.com >>> . >>> For more options, visit this group athttp://groups.google.com/ >>> group/rubyonrails-core?hl=en. >> >> -- >> Cheers! >> - Pratikhttp://m.onkey.org|http://twitter.com/lifo > > -- > > You received this message because you are subscribed to the Google > Groups "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails- > c...@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en > . > > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Re: proposing Object#nonblank? (analogous to Ruby's Numeric#nonzero?)
On Mon, Dec 28, 2009 at 1:28 AM, Rob Biedenharn wrote: > As for predicate methods returning true or false, the Numeric#nonzero? > to which the OP compares nonblank? is a perfect counter example. The > way that it was explained to me (by Jim Weirich, iirc) was that a > predicate should return either false/true or nil/"not nil" (where "not > nil" is typically a useful object). This is precisely how > Numeric#nonzero? behaves. No, no. Predicates return true or false _values_. The implementor decides which one he wants to return, and it is not required/expected that it is is one of the singletons true/false. In that sense nonzero? is not a counter-example. But you are not going to do arithmetic with the value returned by nonzero? right? Predicates should only have a boolean contract, the chosen returned values shouldn't be documrented or relevant to client code. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] ActiveSupport for Rails 3
On Thu, Dec 17, 2009 at 7:43 PM, Xavier Noria wrote: > I'll do a sistematic pass over all core extensions checking these > dependencies. Done! I've found about 30 missing requires: http://github.com/fxn/rails There's no way to ensure nothing has been left but it is a pass at least. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] HTML5 form field helpers
On Tue, Jan 5, 2010 at 12:26 PM, Mislav Marohnić wrote: > On Mon, Jan 4, 2010 at 15:31, Stephen Celis wrote: >> >> Some may feel that something like "text_field_tag 'email', nil, :type >> => 'email'" is good enough, but this doesn't work for "text_field" >> because any "type" option is overridden to "text" (this could be fixed >> with a smaller patch). > > I suggest making this smaller patch, since it fixes a bug that prevents > people from specifying arbitrary types for form inputs. Next, I would make a > patch that adds method_missing to form builder and allows things like > `anything_field`, which creates an input with type="anything". This is might > be a good future-proof solution until the HTML5 spec is finalized—what do > the others think? If in the future there's a new input type people using old versions could define their own helper as a last resort. I don't think this use case deserves a solution with method_missing. Prefer explicit methods here. I mean, if we expected dozens of new input types it could be worth it perhaps, but... -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Re: Does rails ever automatically bring in a gem?
On Wed, Jan 13, 2010 at 12:05 AM, Yehuda Katz wrote: > I'm guessing the bug was fixed between p72 and p174. That's right, it was present in the first patch levels and fixed later. That's why the patch is still in AS for Rails 3 (albeit it requires 1.8.7). -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
[Rails-core] Class#subclasses
I am writing the AS core extensions guide, and would like to know your opinion about Class#subclasses: AS defines Class#subclasses, it returns the name of all descendants (strings). Same as AC::Base.subclasses. AR::Base.subclasses on the other hand returns all descendants (classes), and it is protected. The guide could warn about AR::Base. We could also redefine AR::Base.subclasses to match the rest (I'd volunteer). ack says there are not a lot of occurrences, but it wouldn't be backwards compatible. What do you think? -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Class#subclasses
On Sat, Jan 16, 2010 at 12:56 PM, Mislav Marohnić wrote: > On Sat, Jan 16, 2010 at 12:37, Xavier Noria wrote: >> >> The guide could warn about AR::Base. We could also redefine >> AR::Base.subclasses to match the rest (I'd volunteer). ack says there >> are not a lot of occurrences, but it wouldn't be backwards compatible. > > I can imagine that plugins might use Base.subclasses to iterate over AR > models. > thinking-sphinx does this, for instance. > > The question is, why would we standardize on strings? Why not actual > references, like `ancestors`? I first thought about changing AR because at least that is a protected method and it could be the case that it breaks less code. But all being equal, I'd expect subclasses to return class objects indeed, for example Object#subclasses_of does, and anyway that is what the name would suggest to me. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
[Rails-core] Re: Class#subclasses
On Sat, Jan 16, 2010 at 12:37 PM, Xavier Noria wrote: > AS defines Class#subclasses, it returns the name of all descendants > (strings). Same as AC::Base.subclasses. Ah, but they are not equivalent because AC::Base#subclasses includes names of non-reachable class objects, whereas Class#subclasses filters them out. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Community announcement: changelog entries
On Tue, Jan 19, 2010 at 9:23 AM, Mikel Lindsaar wrote: > Our friends at Engine Yard have retained my services to go through the Rails > documentation to get the new API documented for Rails 3.0. Great news Mikel! -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Re: Class#subclasses
On Sun, Jan 17, 2010 at 1:54 AM, Michael Koziarski wrote: >> Ah, but they are not equivalent because AC::Base#subclasses includes >> names of non-reachable class objects, whereas Class#subclasses filters >> them out. > > This difference is probably just to enable reset_subclasses to work > around the ruby memory-leak discussed at length on: > > http://rails.lighthouseapp.com/projects/8994/tickets/1339-arbase-should-not-be-nuking-its-children-just-because-it-lost-interest > > There's no reason that the AR version can't be called something else > and move subclasses to be the same everywhere. I've seen that the classes in the framework that need #subclasses implement their own version using the inherited hook. It turns out that Class#subclasses was not being used in the framework, Jeremy suggested it shouldn't be a core extension in that case and we've removed it. That in turn unrolled a series of related utilities that were unused, they are: Object#subclasses_of Object#remove_subclasses_of Object#extended_by Object#extend_with_included_modules_from Class#remove_subclasses Class#remove_class Class#reachable? Class#descedents They are gone as well, and I'll prepare a patch to deprecate them for 2.3. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Re: Class#subclasses
On Wed, Jan 27, 2010 at 9:26 AM, Mislav Marohnić wrote: > Looks like remnants of the old reloading system? > So, if some classes (like ActiveRecord) in the framework implement their own > `subclasses`, why not implement it once in AS and remove those other > implementations? Sounds good because there are 4 o 5 of them. I think they are equivalent except perhaps for visibility which is not probably big deal if we uniform this. I'll have a look at it. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] ActiveModel rdoc gets fullpath in files?
On Mon, Feb 8, 2010 at 9:17 PM, slowhog wrote:
> In activemodel/Rakefile, #{dir} is used in rdoc task, which causes
> full path used under activemodel/doc/files. What is the purpose to
> use #{dir} in activemodel/Rakefile instead of simply use relative path
> like others?
Good catch, should be relative paths.
> I also noticed that activemodel rdoc is not included in the top-level
> rdoc, is this intentional?
Is going to be added.
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To post to this group, send email to rubyonrails-c...@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] ActiveModel rdoc gets fullpath in files?
Both things are fixed now in the repo, thank you! -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
[Rails-core] the main source of API docs is master
I've seen some confusion regarding the role of docrails with regard to the API. Many people have the impression that documentation goes through docrails, but this is not exact. Let me share these remarks with you all: The main source of API docs is master. When a patch to master adds stuff that belongs to the public interface, the patch should include proper tests and rdoc. You do not send the code through master and then document in docrails, rather everything goes in the original patch for it to be complete. If the patch renames/moves/deprecates/... the source tree would be additionally ack'ed to find instances of the previous idiom. The examples in the API docs have to implicitly show what is idiomatic in modern Rails to the reader and may need update. That goes also with the patch. It is difficult to have a global uniform style with contributions by so many people (we're approaching 1500!), or that everybody follows precisely the API conventions (http://wiki.github.com/lifo/docrails/rails-api-documentation-conventions), and so it could be the case that someone in the doc team then copy-edits a little, but that is minor in general. So, what about docrails? The purpose of docrails is to be able to *patch* the docs bypassing LH. For example, if you see an error in the API and you have commit in docrails (otherwise ask lifo), you just fire up a console, edit, and push. Fixed. Since going through docrails is just a shortcut for something that would go trough LH otherwise, merges from docrails into master are now normal and Rails Contributors gives you credit, as if the doc patch went through master (though if several trivial commits are pushed it could be the case they get squashed to keep some balance). -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Re: In development mode not all types are included in the query related to type
In general, if you have grandchildren you need to load them to ensure they are known. I compute them this way: http://gist.github.com/274219 The bottom line is that Active Record needs to know the STI hierarchy that is relevant to any given query. That just does not play nice with autoloading, it is a trade-off. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Re: In development mode not all types are included in the query related to type
On Wed, May 12, 2010 at 4:36 PM, Mislav Marohnić wrote: > When you're querying a parent that doesn't have any non-abstract parent > (meaning he's the top of the STI hierarchy), then theoretically you really > don't have to know the list of descendants. AR could just make a query > without conditions. Exactly, that is why in the last example in Neeraj's gist there's no conditions on the type column even if you load the subclasses: http://gist.github.com/398486 I added a couple of comments at the bottom. Neeraj these are just two techniques that do not match transparently. Do you see what is going on now? I think the ticket could be closed, but a warn about this gotcha could be helpful both in the API and guides. Santiago Pastorino is about to add it. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Asset tag helper and (Google) cache recommendations
On Sat, May 15, 2010 at 5:22 PM, michael.hasenst...@googlemail.com wrote: > Doesn't he have a point? Shouldn't Rails' asset tag helper(s) be > changed accordingly? > > http://github.com/eliotsykes/asset_fingerprint > > > Quote (http://code.google.com/speed/page-speed/docs/caching.html): > > Recommendations > > Don't include a query string in the URL for static resources. > Most proxies, most notably Squid up through version 3.0, do not > cache resources with a "?" in their URL even if a Cache-control: > public header is present in the response. To enable proxy caching for > these resources, remove query strings from references to static > resources, and instead encode the parameters into the file names > themselves. There was precisely a discussion yesterday about this, and we had a look into that plugin. The plugin looks good to me, and it offers also hashing which is good for a multi-server setup. I personally think it would be nice to merge or at least to serve as inspiration to extend the current functionality. It would be good to have real numbers about how many hits an app may save due to cache proxies. You know, to take an informed decision and to be able to document something more concrete about when some option would be better than another and why. Have people working with renamed virtual filenames found any gotchas in practice worth taking into account? -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] api.rubyonrails.org is showing version 2.3.3
On Tue, May 25, 2010 at 4:01 PM, Michael Breen wrote: > I wasn't exactly sure where this should go but I figured this would be a good > place start. Thanks for the heads up Michael, it is up to date now. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] api.rubyonrails.org is showing version 2.3.3
Edge docs are periodically generated from docrails. The API is here http://edgeapi.rubyonrails.org and guides here: http://edgeguides.rubyonrails.org The main source of API docs is rails/master, docrails is mainly for patching. So, there's always a little mismatch between what's in rails/master and what's in docrails. But they are cross-merged like a couple of times a week or so anyway. There are no frozen docs for beta releases as such. -- fxn PS: rails.info was a domain used a while back, nowadays the official URLs are the ones above. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Default JavaScript library
On Mon, May 24, 2010 at 5:54 PM, Daniel Schierbeck wrote: > 1. It is my feeling that the vast majority of the Rails community use > jQuery exclusively. This report from RailsLab says jRails is used by about 16% of RPM users: http://railslab.newrelic.com/2010/05/25/state-of-the-stack-a-ruby-on-rails-benchmarking-report-25-may-2010?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+RailsLab+(RailsLab)&utm_content=Google+Feedfetcher It could be the case that some switch to jQuery without jRails, but I wouldn't expect that to be a significant percent. In any case, a 16% in that particular sample does not seem to support that perception. -- fxn PS: I you match gems and plugins, numbers say Mislav is the king :). -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Default JavaScript library
On Thu, May 27, 2010 at 4:58 PM, Albert Llop wrote: > Projects using jQuery dont necessarily use jRails so I dont think that 16% > is a real indicator of the usage of jQuery in Rails projects. As I said, I don't expect that to be a significant percent. > At least to me it seems like the problem of having Prototype as default > affects mostly to new people. Advanced users will just install jRails and > use jQuery. New people might find themselves thinking they nave to use > Prototype to work with Rails, or other harmful situations. I believe that if > the default lib is the most used everywhere these negative situations will > happen less often. That's a different story. What the 16% tells in my view is that you can't include (1) among the reasons for advocating a switch in the default. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Default JavaScript library
On Thu, May 27, 2010 at 5:32 PM, Yehuda Katz wrote: > The idea that 16% of Rails users use jQuery is divorced from reality. But you are talking perceptions, and the sample talks numbers. Of course 16% has to be taken with some margins, but you can't deny it makes difficult to claim that the vast majority of Rails developers use jQuery exclusively, which was the claim in (1). That is a strong claim! (1 was originally stated as a feeling not a fact, that's fine). If the percent had been 84% then there would be no doubt about it, right? But < 20%... dubious. But it turns out the 84% seems to support that the vast majority are using Prototype, no matter which is our termometer. Hey, I am not saying people can't advocate jQuery because of a series of reasons. I am only raising a flag about this claim about the perceived user base. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Default JavaScript library
On Thu, May 27, 2010 at 5:55 PM, Andy Jeffries wrote: > I completely disagree, just because people don't use jrails, doesn't > mean they're a prototype user. I generally bring in jQuery manually > and delete all the prototype cruft from my projects, but I then write > my own jQuery code to do specifically what I want, ignoring Rails > helpers. I know! The problem is to gauge which percent does that represent. Do you claim that there's a 50% of people using jQuery exclusively without jRails to be able to sum up say 70%? My hypothesis is that that percent is small, and this is of course speculation. But speculation based on the fact that generally speaking one prefers to keep the helpers if the cost is as cheap as installing jRails. I am not claiming 16% is the exact figure, this is a sample, there's that other variable. What I say is that the numbers do not seem to **support**, to bring some evidence in favor of (1), on the contrary. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Rails 3 and Ruby 1.8
On Mon, Jun 7, 2010 at 2:37 PM, Hongli Lai wrote: > According to http://guides.rails.info/getting_started.html Rails 3 > requires either Ruby 1.8.7 < p248 or Ruby 1.9.2dev because everything > in between has bugs. That's quite unfortunate seeing that the MRI core > developers haven't released any fixes for the bugs yet, yet Linux > distributions are eager to package the latest version (p249). > > We've backported the bug fixes that affect Rails 3 to p249 and > included these in the latest REE release, 2010.02. I think the > documentation should be updated with this fact. Great Hongli. I updated the getting started guide, thank you very much! -- fxn PS: rails.info is no longer used for edge docs, although it still serves them. Nowadays the official pointers for edge docs are http://edgeguides.rubyonrails.org and http://edgeapi.rubyonrails.org. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Rails 3 and Ruby 1.8
On Mon, Jun 7, 2010 at 4:47 PM, Andy Jeffries wrote: > Can someone with some clout (maybe DHH as he's most recognisable) send > emails to the owners of these other domains and ask them to serve a 301 > header to the official docs. There are so many domains and Google indexes > them all, it can be hard to know which one is the right one. Yes that would be the right thing to do indeed. rails.info and the machine that serves edge docs are Pratik's, I'll check it out with him. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Where is Rails 3 documentation?
On Tuesday, June 8, 2010, Rodrigo Rosenfeld Rosas wrote: > I have already used these guides for porting most of my app, but I still miss > the API docs for more details. In general API and guides have been revised (except for some), but there have been so many changes in the code base that I am pretty sure they will need an iteration cycle to converge. I think a community effort is needed here. docrails has now public write access, if you see any piece of documentation that lacks something or uses previous idioms please just clone docrails from github, fix it, and up! -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] [PATCH] ActiveSupport OrderedHash Doesn't Support Passing Block to merge
On Sat, Jun 12, 2010 at 4:23 PM, mudge wrote: > On versions of Ruby prior to 1.9 (where Hashes' keys have no set > order), ActiveSupport::OrderedHash implements its own merge and merge! > methods. These implementations differ to the standard library however > in that they do not support passing a block to merge (c.f. > http://ruby-doc.org/core/classes/Hash.html#M002880 for the standard > method signature). > > I have posted a patch including tests at > https://rails.lighthouseapp.com/projects/8994/tickets/4838-patch-add-block-support-to-activesupport-orderedhash-merge > to correct this missing functionality. The implementation also closely > matches that of Rubinius' (c.f. > http://github.com/evanphx/rubinius/blob/master/kernel/common/hash.rb#L429-447 > ) Excellent, applied http://github.com/rails/rails/compare/a087bc8...9183eae -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] [PATCH] ActiveSupport OrderedHash Doesn't Support Passing Block to merge
Just realized the patch is not compatible with 1.9, since in 1.9 only existing keys are merged (that's the key? key test in Rubinius). Will revise it myself. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] [PATCH] ActiveSupport OrderedHash Doesn't Support Passing Block to merge
On Sun, Jun 13, 2010 at 4:42 AM, Xavier Noria wrote: > Just realized the patch is not compatible with 1.9, since in 1.9 only > existing keys are merged (that's the key? key test in Rubinius). Will > revise it myself. Rather, yield is called only for existing keys. This revisions seems to be correct: http://github.com/rails/rails/commit/36143d26cb841210b5f22aff4ed9c093a0554a1a -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] [PATCH] ActiveSupport OrderedHash Doesn't Support Passing Block to merge
On Sun, Jun 13, 2010 at 7:14 AM, Santiago Pastorino wrote: > I've done a tiny improvement to this implementation. > Please Xavier review it ;). > http://github.com/spastorino/rails/commit/63b43575765c7d4042c23ac3ddb1213c1968b5a3 Good, it is up http://github.com/rails/rails/commit/6d19a4a664914e908e75cfe90a0507cc9f53d1cd Thanks! -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Default JavaScript library
We discussed in this thread usage stats. Usage stats seem to favor Prototype, though of course it has been the default since the beginning and that matters. On the other hand, stats about what people prefer *now* suggest that's clearly jQuery: http://survey.hamptoncatlin.com/survey/stats I think this number is worth taking into account. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] RDoc 2.2.0 requirement
On Thu, Jun 17, 2010 at 4:29 PM, Hongli Lai wrote: > Looks like Rails 3 currently depends on RDoc 2.2.0 exactly, even > though the latest version is 2.5.x. Why this specific version? There are plans for improving the documentation. They range from a better template, to rethinking the API in some fundamental way. While these are in the oven we needed to take a decision about what to use for 3.0, which is imminent, since the current API is generated with RDoc 1.x and that lacks backslash support and other features the API is now using. We generated the API with 2.5 in a testing domain and just weren't convinced. The site will change, but it will change to something else. So the choice for this particular iteration has been the most modern RDoc that does not use Darkfish. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
[Rails-core] taking the Rails API to a next level
As I mentioned earlier today, there some ideas to take the API to a next level. I think Ruby on Rails is a fucking awesome software, and it should have a fucking awesome API. Yehuda is working on a different way to organize content. Rizwan Reza is exploring the idea of supporting user comments, there was also a guy in Baltimore that volunteered to have a look into that. But there are also other ideas that I think are interesting at least to be investigated, if any of you want to work on any of them that would be totally great! First of all an axiom: It is OK that we build our own doc tool ad-hoc for Rails, be creative! Four existing ideas, they may conflict with each other but we will sort it out if the case arrives: == User-Centered API Most of the modularity in the Rails code base is there by design. But an end-user does not really care whether AC::Base has been broken in these many modules. If you go to AC::Base you should have all the public interface right there. Accomplishing this is difficult with parsing, since there are inherited hooks going on, autoloads, code like MODULES.each do |mod| include mod end etc. The wild idea is to go and load recursively all the Rails lib directories (except perhaps for a few exceptions with side-effects). With all Rails libs executed, all hooks executed, etc. introspect in memory, and build meaningful docs. You can delegate docstring extraction to an existing parser. == Linking Tests to the API The API should be written in English, but sometimes it would be handy to be able to consult right there the tests for a given method. You know, a block with tests that is hidden by default, akin to the current code block. Here you need to investigate a way to link tests and methods, and be able to insert them in the API. == Testing Rails Guides Rails Guides are really really great, but they need to be maintained. If they had code coverage that would be included with the Rails test suite and people would be aware of content being outdated by a patch. That would help a lot, and hey, having tested documentation isn't an exciting idea by itself? Yehuda, José, and Sam Ruby have done stuff in that line for books (with different approximations). If you'd like to take a stab at this it would be a good idea to have at least a look at their solutions. == Awesome Theme This depends heavily on the rest, but anyway it is very important. For the API to be fucking awesome, it has to *look* fucking awesome. The idea here is to have a gorgeous theme, possibly based on the color palette and overall style of Rails Guides, and Rails Contributors for consistency's sake. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] taking the Rails API to a next level
On Fri, Jun 18, 2010 at 7:03 AM, Evgeniy Dolzhenko wrote: >> etc. The wild idea is to go and load recursively all the Rails lib >> directories (except perhaps for a few exceptions with side-effects). >> With all Rails libs executed, all hooks executed, etc. introspect in >> memory, and build meaningful docs. You can delegate docstring >> extraction to an existing parser. > > My 2cents: someone actually already implemented "the wild idea" here > http://github.com/dolzenko/reflexive > and here > http://github.com/dolzenko/method_extensions (using Ripper parser). That's fantastic! So the planets are aligned :). > The problems I've encountered: > > class_eval still screws the things up, also pretty often there are > layers of behavior-extending modules included in AR::Base before > you get to the actual behavior-defining method (which will have > the docstring you're interested in). This means that using this > approach you will have to specify where to look up particular > methods (like some methods of AR::Base should be looked up > on AR::Relation, etc.) Sure, I think there will be still unsolvable things for an automated tool, perhaps we have methods dynamically generated inside a method definition, the callbacks stuff is particularly dynamic for example... It won't be perfect, but I guess overall it will significantly much better. Excellent Evgeniy, I need to look into your projects in detail, but from a first impression I think they should be definitely included in the Rails tool-chain, or inspire a custom solution. What I am envisioning at this moment is: 1. There's a script that uses your code to build a static[*] website based on runtime introspection. 2. There's some new macro in unit tests or something to link them to methods, I don't know, something like covers 'Some::Module#some_method' and method_extensions, or an adaptation of it for Rails, would provide a #tests accessor. 3. There's a gorgeous template the script in #1 uses to combine and present everything. -- fxn [*] Unless we introduce user comments, I think it is better to keep it static and simple. User comments are hard I think, that'd be for another thread. A search box would also be included but that can also be static. PS: Ryan, need to think about your proposal, will write back later. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] [PATCH] option_groups_from_collection_for_select should produce an HTML-safe string
On Fri, Jun 18, 2010 at 5:16 PM, Wincent Colaiuta wrote:
> Can somebody please review my ticket:
>
> https://rails.lighthouseapp.com/projects/8994/tickets/4879
>
> It's a trivial bugfix ("option_groups_from_collection_for_select
> should produce an HTML-safe string") before RC, I think.
Applied, thank you!
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To post to this group, send email to rubyonrails-c...@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] RDoc 2.2.0 requirement
On Mon, Jun 21, 2010 at 11:47 PM, Jonas Nicklas wrote: > Have you considered SDoc? Imho it's the nicest overall documentation > template so far. The search works incredibly well. You can see it in > action here: http://railsapi.com/doc/rails-v2.3.8/ It's a really nice template. Very clear. We'll take it into account re the other thread about documentation. That template gets rid of the methods and file listing. That's an idea in the background since I think they are mostly useless in practice. When you process the docs you get a list of things, but that does not mean they need to end up in the interface. Indeed, depending on how docs evolve I'd like to experiment with getting rid of everything and leaving just a search box and the main area (does anybody do this?). Specially if we get entry points to the main parts of the framework somehow, so newcomers have some anchors to start browsing. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Another missing activesupport require
On Tue, Jun 29, 2010 at 10:04 PM, Tekin wrote: > This time in active_records/migrations.rb. > > Ticket with patch here: > > https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/5008-migrationsrb-requires-active_supportcore_extmodulealiasing#ticket-5008-2 Excellent, applied thank you! -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
