[#53893] [ruby-trunk - Bug #8204][Open] ObjectSpace.each_object(Bignum) can generate Bignums that are to small to be Bignums — "Hanmac (Hans Mackowiak)" <hanmac@...>
5 messages
2013/04/02
[#53914] [ruby-trunk - Feature #8206][Open] Should Ruby core implement String#blank? — "sam.saffron (Sam Saffron)" <sam.saffron@...>
10 messages
2013/04/03
[#53922] [ruby-trunk - Bug #8208][Open] Raise cached exceptions for nonblocking IO to avoid allocation/stack-copying costs — "headius (Charles Nutter)" <headius@...>
7 messages
2013/04/03
[#54349] [ruby-trunk - Bug #8208] Raise cached exceptions for nonblocking IO to avoid allocation/stack-copying costs
— "headius (Charles Nutter)" <headius@...>
2013/04/16
[#54374] Re: [ruby-trunk - Bug #8208] Raise cached exceptions for nonblocking IO to avoid allocation/stack-copying costs
— Eric Wong <normalperson@...>
2013/04/17
"headius (Charles Nutter)" <headius@headius.com> wrote:
[#53950] [ruby-trunk - Bug #8211][Open] Performance regression of method calls — "dunric (David Unric)" <dunric29a@...>
9 messages
2013/04/03
[#53974] [ruby-trunk - Feature #8215][Open] Support accessing Fiber-locals and backtraces for a Fiber — "halorgium (Tim Carey-Smith)" <ruby-lang-bugs@...>
14 messages
2013/04/03
[#54023] [ruby-trunk - Feature #8223][Open] Make Matrix more omnivorous. — "boris_stitnicky (Boris Stitnicky)" <boris@...>
9 messages
2013/04/05
[#54031] Question about r39944 — Aaron Patterson <tenderlove@...>
Hi,
9 messages
2013/04/05
[#54032] Re: Question about r39944
— "NARUSE, Yui" <naruse@...>
2013/04/05
Even if test directory should be on the load path on test-all, you should
[#54095] [ruby-trunk - Feature #8237][Open] Logical method chaining via inferred receiver — "wardrop (Tom Wardrop)" <tom@...>
34 messages
2013/04/08
[#54097] [ruby-trunk - Feature #8237] Logical method chaining via inferred receiver
— "rosenfeld (Rodrigo Rosenfeld Rosas)" <rr.rosas@...>
2013/04/08
[#54175] [ruby-trunk - Bug #8254][Open] Ruby segfaults on second SystemStackError from parser — "charliesome (Charlie Somerville)" <charlie@...>
3 messages
2013/04/11
[#54185] [CommonRuby - Feature #8257][Open] Exception#cause to carry originating exception along with new one — "headius (Charles Nutter)" <headius@...>
43 messages
2013/04/11
[#54629] Re: [CommonRuby - Feature #8257][Open] Exception#cause to carry originating exception along with new one
— SASADA Koichi <ko1@...>
2013/04/27
(2013/04/12 1:40), headius (Charles Nutter) wrote:
[#54637] Re: [CommonRuby - Feature #8257][Open] Exception#cause to carry originating exception along with new one
— Charles Oliver Nutter <headius@...>
2013/04/27
On Sat, Apr 27, 2013 at 5:19 PM, SASADA Koichi <ko1@atdot.net> wrote:
[#54196] Encouraging use of CommonRuby — Charles Oliver Nutter <headius@...>
I think we need to do more to encourage the use of the CommonRuby
20 messages
2013/04/11
[#54200] Re: Encouraging use of CommonRuby
— Marc-Andre Lafortune <ruby-core-mailing-list@...>
2013/04/11
Hi,
[#54214] Re: Encouraging use of CommonRuby
— Charles Oliver Nutter <headius@...>
2013/04/12
On Thu, Apr 11, 2013 at 3:50 PM, Marc-Andre Lafortune
[#54211] Re: Encouraging use of CommonRuby
— "NARUSE, Yui" <naruse@...>
2013/04/12
As far as I understand, what is CommonRuby and the process over CommonRuby
[#54215] Re: Encouraging use of CommonRuby
— Charles Oliver Nutter <headius@...>
2013/04/12
On Thu, Apr 11, 2013 at 11:25 PM, NARUSE, Yui <naruse@airemix.jp> wrote:
[#54220] Re: Encouraging use of CommonRuby
— "NARUSE, Yui" <naruse@...>
2013/04/12
(2013/04/12 16:40), Charles Oliver Nutter wrote:
[#54232] Re: Encouraging use of CommonRuby
— Charles Oliver Nutter <headius@...>
2013/04/12
On Fri, Apr 12, 2013 at 8:08 AM, NARUSE, Yui <naruse@airemix.jp> wrote:
[#54201] Has ObjectSpace changed recently? — Dave Thomas <dave@...>
I just noticed that in 2.0, I see this:
5 messages
2013/04/11
[#54207] [CommonRuby - Feature #8258][Open] Dir#escape_glob — "steveklabnik (Steve Klabnik)" <steve@...>
15 messages
2013/04/12
[#54266] [CommonRuby - Feature #8258] Dir#escape_glob
— "rkh (Konstantin Haase)" <me@...>
2013/04/14
[#54227] [CommonRuby - Feature #8258] Dir#escape_glob
— "rkh (Konstantin Haase)" <me@...>
2013/04/12
[#54218] [CommonRuby - Feature #8259][Open] Atomic attributes accessors — "funny_falcon (Yura Sokolov)" <funny.falcon@...>
43 messages
2013/04/12
[#63015] [CommonRuby - Feature #8259] Atomic attributes accessors
— headius@...
2014/06/09
Issue #8259 has been updated by Charles Nutter.
[#63016] Re: [CommonRuby - Feature #8259] Atomic attributes accessors
— Eric Wong <normalperson@...>
2014/06/09
I'm not sure if setting the attribute on the ivar is a good way to go.
[#54333] Requesting Commit Access — Aman Gupta <ruby@...1.net>
Hello ruby-core,
16 messages
2013/04/16
[#54368] Re: Requesting Commit Access
— Yukihiro Matsumoto <matz@...>
2013/04/16
Hi,
[#54415] [ruby-trunk - Bug #8286][Open] Can't decode non-MIME Base64 — "adacosta (Alan Da Costa)" <alandacosta@...>
10 messages
2013/04/17
[#54459] [CommonRuby - Feature #8291][Open] Allow retrieving the root Fiber of a Thread — "halorgium (Tim Carey-Smith)" <ruby-lang@...>
5 messages
2013/04/19
[#54473] [Backport 200 - Backport #8299][Open] Minor error in float parsing — "bobjalex (Bob Alexander)" <bobjalex@...>
27 messages
2013/04/19
[#54549] [ruby-trunk - Bug #8299] Minor error in float parsing
— "phasis68 (Heesob Park)" <phasis@...>
2013/04/24
[#54496] [ruby-trunk - Bug #8299] Minor error in float parsing
— "naruse (Yui NARUSE)" <naruse@...>
2013/04/22
[#54509] [ruby-trunk - Bug #8310][Open] resque-web crashes with segfault on Ruby 2.0.0-p0 only, Resque 1.24.1, Redis 2.6.12 — "vaharoni (Amit Aharoni)" <amit.sites@...>
5 messages
2013/04/22
[#54559] [ruby-trunk - Feature #8321][Open] Ripper: I would like coordinates for keywords — "ericp (Eric Promislow)" <eric.promislow@...>
7 messages
2013/04/24
[#54606] Plan to the first 2.0.0 patchlevel release. — Tomoyuki Chikanaga <nagachika00@...>
Hello, Rubyists.
8 messages
2013/04/26
[#54743] Re: Plan to the first 2.0.0 patchlevel release.
— Marc-Andre Lafortune <ruby-core-mailing-list@...>
2013/05/02
Hi,
[#54815] Re: Plan to the first 2.0.0 patchlevel release.
— Aman Gupta <ruby@...1.net>
2013/05/06
Could you please backport the following:
[#54621] [ruby-trunk - Feature #8339][Open] Introducing Geneartional Garbage Collection for CRuby/MRI — "ko1 (Koichi Sasada)" <redmine@...>
43 messages
2013/04/27
[#54643] [ruby-trunk - Feature #8339] Introducing Geneartional Garbage Collection for CRuby/MRI
— "authorNari (Narihiro Nakamura)" <authorNari@...>
2013/04/28
[#54649] Re: [ruby-trunk - Feature #8339] Introducing Geneartional Garbage Collection for CRuby/MRI
— SASADA Koichi <ko1@...>
2013/04/28
(2013/04/28 9:23), authorNari (Narihiro Nakamura) wrote:
[#54770] Re: [ruby-trunk - Feature #8339] Introducing Geneartional Garbage Collection for CRuby/MRI
— Narihiro Nakamura <authornari@...>
2013/05/04
2013/4/28 SASADA Koichi <ko1@atdot.net>:
[#54772] Re: [ruby-trunk - Feature #8339] Introducing Geneartional Garbage Collection for CRuby/MRI
— SASADA Koichi <ko1@...>
2013/05/04
(2013/05/04 12:08), Narihiro Nakamura wrote:
[#54813] Re: [ruby-trunk - Feature #8339] Introducing Geneartional Garbage Collection for CRuby/MRI
— Tanaka Akira <akr@...>
2013/05/06
2013/5/4 SASADA Koichi <ko1@atdot.net>:
[#54816] Re: [ruby-trunk - Feature #8339] Introducing Geneartional Garbage Collection for CRuby/MRI
— SASADA Koichi <ko1@...>
2013/05/06
(2013/05/06 11:50), Tanaka Akira wrote:
[#54822] Re: [ruby-trunk - Feature #8339] Introducing Geneartional Garbage Collection for CRuby/MRI
— Tanaka Akira <akr@...>
2013/05/06
2013/5/6 SASADA Koichi <ko1@atdot.net>:
[#54706] [ruby-trunk - Feature #8339] Introducing Geneartional Garbage Collection for CRuby/MRI
— "sam.saffron (Sam Saffron)" <sam.saffron@...>
2013/04/30
[#54657] Re: [ruby-trunk - Feature #8339][Open] Introducing Geneartional Garbage Collection for CRuby/MRI
— Magnus Holm <judofyr@...>
2013/04/28
On Sat, Apr 27, 2013 at 8:19 PM, ko1 (Koichi Sasada)
[#54662] Re: [ruby-trunk - Feature #8339][Open] Introducing Geneartional Garbage Collection for CRuby/MRI
— SASADA Koichi <ko1@...>
2013/04/28
(2013/04/28 21:40), Magnus Holm wrote:
[#54669] Re: [ruby-trunk - Feature #8339][Open] Introducing Geneartional Garbage Collection for CRuby/MRI
— SASADA Koichi <ko1@...>
2013/04/28
(2013/04/28 23:34), SASADA Koichi wrote:
[#54671] Re: [ruby-trunk - Feature #8339][Open] Introducing Geneartional Garbage Collection for CRuby/MRI
— Magnus Holm <judofyr@...>
2013/04/28
On Sun, Apr 28, 2013 at 6:07 PM, SASADA Koichi <ko1@atdot.net> wrote:
[#54672] Re: [ruby-trunk - Feature #8339][Open] Introducing Geneartional Garbage Collection for CRuby/MRI
— SASADA Koichi <ko1@...>
2013/04/28
(2013/04/29 1:19), Magnus Holm wrote:
[#54673] Re: [ruby-trunk - Feature #8339][Open] Introducing Geneartional Garbage Collection for CRuby/MRI
— Magnus Holm <judofyr@...>
2013/04/28
On Sun, Apr 28, 2013 at 6:29 PM, SASADA Koichi <ko1@atdot.net> wrote:
[#54676] Re: [ruby-trunk - Feature #8339][Open] Introducing Geneartional Garbage Collection for CRuby/MRI
— Eric Wong <normalperson@...>
2013/04/28
"ko1 (Koichi Sasada)" <redmine@ruby-lang.org> wrote:
[#54712] [ruby-trunk - Feature #8339] Introducing Geneartional Garbage Collection for CRuby/MRI
— "sam.saffron (Sam Saffron)" <sam.saffron@...>
2013/04/30
[#54665] [ruby-trunk - Bug #8344][Open] Status of Psych and Syck — "Eregon (Benoit Daloze)" <redmine@...>
18 messages
2013/04/28
[ruby-core:54628] [ruby-trunk - Feature #4211][Rejected] Converting the Ruby and C API documentation to YARD syntax
From:
"zzak (Zachary Scott)" <zachary@...>
Date:
2013-04-27 22:07:52 UTC
List:
ruby-core #54628
Issue #4211 has been updated by zzak (Zachary Scott). Status changed from Assigned to Rejected I'm going to reject this, if you have a specific proposal how to improve RDoc please open a feature ticket. ---------------------------------------- Feature #4211: Converting the Ruby and C API documentation to YARD syntax https://bugs.ruby-lang.org/issues/4211#change-38964 Author: lsegal (Loren Segal) Status: Rejected Priority: Normal Assignee: drbrain (Eric Hodel) Category: doc Target version: next minor =begin The Ruby (high level core/stdlib) documentation and its C API (low level) counterparts currently use two different formats (and tools) to write and generate the final docs. This creates a problem for committers and users alike, where: * Documentation is hard to write, because there is no single documentation style to follow (it depends on the API), and the two existing syntaxes are very different. * Documentation is harder to read because the style and formatting differ due to the lack of consistent enforcement of a single style. * Documentation for the C API (specifically) is harder to find Currently, Doxygen @tag style syntax is slowly being introduced to improve the documentation of Ruby's C API, but this does not solve the three issues noted above. I propose to unify the documentation style used in the codebase to a single format (originally on ruby-core:33883[1]) by using YARD[2] syntax, which is very much like the Doxygen @tag style syntax being introduced anyway. Switching to YARD introduces a number of benefits, namely: * There would be a single syntax to learn for committers wishing to document code, making it easier to write, * The documentation would be formatted and styled consistently across both APIs for users to read, * Documentation would be generated by a single tool for both APIs, meaning a simpler workflow for documenters and users wishing to generate the docs themselves. I pointed out in the original mailing list that much of the documentation problems come from a lack of unified styling, causing parts of documentation to be (or become) inaccurate due to a variety of "human-error" type issues, and because there are no tools to check the correctness. I believe switching to a unified style and making sure it is used consistently will solve many of those issues even without tooling, because it is easier to manually check for errors with a consistent formatting. Furthermore, using a consistent style allows us to take advantage of our tooling to check basic correctness (or "lint") the docs for simple errors. YARD already has tools to do this kind of thing (and they are easily improved), but they depend on that consistent syntax. As far as the C API goes, there is little difference in the existing doxygen syntax (except that I'd suggest the '@tag' instead of Doxygen's alternative '\tag' prefixes, for compatibility). As I wrote in the above ruby-core thread, YARD can already handle most of the written doxygen documentation. Granted, a lot of the support for actually *generating* documentation for a straight "C" style API is missing in YARD, but as I mentioned, I would be willing to improve this support if there is a willingness by the ruby-core developers to create a unified documentation style. h3. Steps forward: We should first discuss whether the Ruby core developers are in favor of such a change. In the event that they are, we would have to look at a few things: * Maintaining compatibility with RDoc (or adding YARD's @tag style support to RDoc) for the high level Ruby API docs while converting the syntax. I have a few ideas on how this can be done. * Improving YARD's ability to generate HTML for straight "C" codebases (which I can implement, if we get this far) * Any other issues / reservations raised by the Ruby core team This is certainly a large proposal, and has some compatibility snags (with RDoc, for instance). Regardless, I think these issues can be worked around or dealt with for the most part, and the benefits of much improved documentation, which Ruby really needs, are certainly worth the effort. [1]: ruby-core:33883: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/33884 [2]: YARD: http://yardoc.org =end -- http://bugs.ruby-lang.org/