[#43077] problems committing — Aaron Patterson <tenderlove@...>
It seems like the disk might be full on the svn server:
5 messages
2012/03/05
[#43090] "\\".gsub("\\", "\\\\") == "\\" ?!!! — Rodrigo Rosenfeld Rosas <rr.rosas@...>
Please, help me understand what is happening here.
6 messages
2012/03/06
[#43094] Re: "\\".gsub("\\", "\\\\") == "\\" ?!!!
— Xavier Noria <fxn@...>
2012/03/06
A literal passed as second argument to gsub goes over two
[#43120] [ruby-trunk - Bug #6124][Open] What is the purpose of "fake" gems in Ruby — Vit Ondruch <v.ondruch@...>
27 messages
2012/03/07
[#43142] Questions about thread performance (with benchmark included) — Rodrigo Rosenfeld Rosas <rr.rosas@...>
A while ago I've written an article entitled "How Nokogiri and JRuby
10 messages
2012/03/08
[#43785] Re: Questions about thread performance (with benchmark included)
— Tomoyuki Chikanaga <nagachika00@...>
2012/03/28
Hello, Rodrigo.
[#43797] Re: Questions about thread performance (with benchmark included)
— Rodrigo Rosenfeld Rosas <rr.rosas@...>
2012/03/28
Em 27-03-2012 23:22, Tomoyuki Chikanaga escreveu:
[#44213] Re: Questions about thread performance (with benchmark included)
— SASADA Koichi <ko1@...>
2012/04/09
Hi,
[#44214] Re: Questions about thread performance (with benchmark included)
— Urabe Shyouhei <shyouhei@...>
2012/04/09
#### MRI threads myths and facts #####
[#44220] Re: Questions about thread performance (with benchmark included)
— Rodrigo Rosenfeld Rosas <rr.rosas@...>
2012/04/09
Hi Urabe, thank you for your input, but I think you have
[#43163] Help w/ some C to create NullClass — trans <transfire@...>
I am trying to write a C extension for "NullClass" functionality. I've
3 messages
2012/03/10
[#43245] [ruby-trunk - Bug #6131][Open] Ctrl-C handler do not work from exec process (Windows) — Luis Lavena <luislavena@...>
10 messages
2012/03/12
[#43279] [ruby-trunk - Bug #6148][Open] ruby_1_9_3 revision conflict — Jon Forums <redmine@...>
4 messages
2012/03/14
[#43313] [ruby-trunk - Feature #6150][Open] add Enumerable#grep_v — Suraj Kurapati <sunaku@...>
17 messages
2012/03/15
[#43325] [ruby-trunk - Bug #6154][Open] Eliminate extending WaitReadable/Writable at runtime — Charles Nutter <headius@...>
25 messages
2012/03/16
[#43369] Re: [ruby-trunk - Bug #6154][Open] Eliminate extending WaitReadable/Writable at runtime
— Tanaka Akira <akr@...>
2012/03/17
2012/3/16 Charles Nutter <[email protected]>:
[#43326] [ruby-trunk - Bug #6154] Eliminate extending WaitReadable/Writable at runtime
— Charles Nutter <headius@...>
2012/03/16
[#43334] [ruby-trunk - Bug #6155][Open] Enumerable::Lazy#flat_map raises an exception when an element does not respond to #each — Dan Kubb <dan.kubb@...>
9 messages
2012/03/16
[#43345] [ruby-trunk - Bug #6159][Open] Enumerable::Lazy#inspect — Benoit Daloze <redmine@...>
10 messages
2012/03/16
[#43497] [ruby-trunk - Bug #6179][Open] File::pos broken in Windows 1.9.3p125 — "jmthomas (Jason Thomas)" <jmthomas@...>
24 messages
2012/03/20
[#43502] [ruby-trunk - Feature #6180][Open] to_b for converting objects to a boolean value — "AaronLasseigne (Aaron Lasseigne)" <aaron.lasseigne@...>
17 messages
2012/03/20
[#43529] [ruby-trunk - Bug #6183][Open] Enumerator::Lazy performance issue — "gregolsen (Innokenty Mikhailov)" <anotheroneman@...>
36 messages
2012/03/21
[#43814] [ruby-trunk - Feature #6219][Open] Return value of Hash#store — "MartinBosslet (Martin Bosslet)" <Martin.Bosslet@...>
20 messages
2012/03/28
[#43904] [ruby-trunk - Feature #6225][Open] Hash#+ — "trans (Thomas Sawyer)" <transfire@...>
36 messages
2012/03/29
[#43923] [ruby-trunk - Feature #6225] Hash#+
— "shyouhei (Shyouhei Urabe)" <shyouhei@...>
2012/03/30
[#43909] [ruby-trunk - Feature #6225][Assigned] Hash#+
— "mame (Yusuke Endoh)" <mame@...>
2012/03/29
[#43920] [ruby-trunk - Feature #6225] Hash#+
— "shyouhei (Shyouhei Urabe)" <shyouhei@...>
2012/03/30
[#43951] [ruby-trunk - Bug #6228][Open] [mingw] Errno::EBADF in ruby/test_io.rb on ruby_1_9_3 — "jonforums (Jon Forums)" <redmine@...>
28 messages
2012/03/30
[#43996] [ruby-trunk - Bug #6236][Open] WEBrick::HTTPServer swallows Exception — "regularfry (Alex Young)" <alex@...>
13 messages
2012/03/31
[#44015] [Ruby 1.8 - Bug #6239][Open] super Does Not Pass Modified Rest Args When Originally Empty — "mudge (Paul Mucur)" <mudge@...>
6 messages
2012/03/31
[ruby-core:43982] [ruby-trunk - Feature #4211][Assigned] Converting the Ruby and C API documentation to YARD syntax
From:
"mame (Yusuke Endoh)" <mame@...>
Date:
2012-03-31 02:09:45 UTC
List:
ruby-core #43982
Issue #4211 has been updated by mame (Yusuke Endoh). Status changed from Open to Assigned ---------------------------------------- Feature #4211: Converting the Ruby and C API documentation to YARD syntax https://bugs.ruby-lang.org/issues/4211#change-25503 Author: lsegal (Loren Segal) Status: Assigned Priority: Normal Assignee: drbrain (Eric Hodel) Category: DOC Target version: =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/