pax_global_header 0000666 0000000 0000000 00000000064 12656766440 0014532 g ustar 00root root 0000000 0000000 52 comment=dfcaa90b4ed005716de29d64b36d3abea0df715f yard-master/ 0000775 0000000 0000000 00000000000 12656766440 0013326 5 ustar 00root root 0000000 0000000 yard-master/.gitignore 0000664 0000000 0000000 00000000131 12656766440 0015311 0 ustar 00root root 0000000 0000000 _Yardoc .DS_Store *.rbc *.pdf .yardoc *.gem Gemfile.lock /pkg /doc /doc_guide /coverage yard-master/.rspec 0000664 0000000 0000000 00000000010 12656766440 0014432 0 ustar 00root root 0000000 0000000 --color yard-master/.travis.yml 0000664 0000000 0000000 00000002711 12656766440 0015440 0 ustar 00root root 0000000 0000000 # Enables Travis to use their new container-based infrastructure sudo: false # Build for Ruby language: ruby # Enables caching for bundler cache: bundler # Passes arguments to bundle install (http://gembundler.com/man/bundle-install.1.html) # bundler_args: # Specify which ruby versions you wish to run your tests on, each version will be used rvm: - 1.8.7 - 1.9.3 - 2.0 - 2.1 # - 2.2 - re-enable after https://bugs.ruby-lang.org/issues/10693 is fixed - jruby # - ruby-head # RedCloth does not compile on head # - 1.8.6 # Does not work on travis-ci # - 1.9.1 # Does not work on travis-ci # - 1.9.2 # Does not work on travis-ci ..really? # - ree # Does not work on travis-ci ..really? # Define how to run your tests (defaults to `bundle exec rake` or `rake` depending on whether you have a `Gemfile`) script: "bundle exec rake travis_ci" # Define tasks to be completed before and after tests run . Will allow folding of content on frontend #before_script: # - command_1 # - command_2 # #after_script: # - command_1 # - command_2 # Specify an ENV variable to run before: 'bundle install' and 'rake' (or your defined 'script') env: "CI=1 SUITE=1 " # Specify the recipients for email notification #notifications: # recipients: # - email-address-1 # - email-address-2 # Disable email notifications #notifications: # disabled: true notifications: webhooks: urls: - https://webhooks.gitter.im/e/c6dbb9323007dfcf81df yard-master/.yardopts 0000664 0000000 0000000 00000001050 12656766440 0015170 0 ustar 00root root 0000000 0000000 --protected --no-private --embed-mixin ClassMethods --exclude /server/templates/ --exclude /yard/rubygems/ --asset docs/images:images --tag yard.signature:"YARD Tag Signature" --type-name-tag yard.tag:"YARD Tag" --type-name-tag yard.directive:"YARD Directive" --hide-tag yard.tag --hide-tag yard.directive --hide-tag yard.signature --load ./docs/templates/plugin.rb - CHANGELOG.md docs/WhatsNew.md docs/GettingStarted.md docs/Tags.md docs/Overview.md docs/CodeObjects.md docs/Parser.md docs/Handlers.md docs/TagsArch.md docs/Templates.md LICENSE LEGAL yard-master/.yardopts_guide 0000664 0000000 0000000 00000000457 12656766440 0016357 0 ustar 00root root 0000000 0000000 -t guide --title YARD -o doc_guide --exclude /server/templates/ --exclude /yard/rubygems/ --asset docs/images:images - CHANGELOG.md docs/WhatsNew.md docs/GettingStarted.md docs/Tags.md docs/Overview.md docs/CodeObjects.md docs/Parser.md docs/Handlers.md docs/TagsArch.md docs/Templates.md LICENSE LEGAL yard-master/.yardopts_i18n 0000664 0000000 0000000 00000000777 12656766440 0016046 0 ustar 00root root 0000000 0000000 --protected --no-private --exclude /server/templates/ --exclude /yard/rubygems/ --asset docs/images:images --tag yard.signature:"YARD Tag Signature" --type-name-tag yard.tag:"YARD Tag" --type-name-tag yard.directive:"YARD Directive" --hide-tag yard.tag --hide-tag yard.directive --hide-tag yard.signature --load ./docs/templates/plugin.rb - CHANGELOG.md docs/WhatsNew.md docs/GettingStarted.md docs/Tags.md docs/Overview.md docs/CodeObjects.md docs/Parser.md docs/Handlers.md docs/TagsArch.md docs/Templates.md yard-master/CHANGELOG.md 0000664 0000000 0000000 00000040720 12656766440 0015142 0 ustar 00root root 0000000 0000000 # 0.8.7.6 - October 26, 2014 - Support using `@option` tag on keyword arg splat parameter. (#729) - Add `.stats_options` for `YardocTask`. (#800, #801) # 0.8.7.5 - October 26, 2014 - Fix linking of methods in top level namespace in method listing. (#776) - Support using C macros in function declarations. (#810) - YARD will no longer group comment blocks starting on the same column if they are preceded by code. (#798) - Handle anonymous lambda calls in toplevel scope. (#774) - Support I18n in `@overload` tags. (#794) - Support `yard stats` for objects with no file property. (#792) - Support for named arguments in Ruby >= 2.1. (#785) - Exclude README backup files from YARD generation. (#790) - Turned on the lax spacing option in Redcarpet to comply with the Markdown standard. - Escape HTML in YARD server search placeholder template. - Fix issue with `private_class_method` support. (#760, #767) - Enable tables support by default in Redcarpet Markdown provider. (#765) # 0.8.7.4 - March 22, 2014 - Mark C methods as explicit but also remove explicit check in stats. (#727) - Report unresolved parent namespaces as undocumentable errors instead. (#753) - No longer ignore overridden methods from documentation check in stats (#719) - Fix JRuby throwing exception when remove_method called on non-existent method. (#732) - Add basic support for `private_class_method` (#747) - Ensure namespace is always set when parent module is not found. (#753) - Set overflow as auto on table of contents. - Report 100% documented if nothing is undocumented. (#754) - Added support for RubyGems 2.0.0+. (#742) - Allow users to enter their own YARD RakeTask name. (#705) - Fixed a typo that was causing Windows detection to always fail. (#715) - Add debug information when loading a plugin fails. (#711) # 0.8.7.3 - November 1, 2013 - Handle Unicode method/class/file names in server URL encoding (lsegal/rubydoc.info#69). - Style keyword style hashes with same symbol color in code highlighting (#707). - Fix broken JS when visiting docs in file:// scheme (#706). - Add support for new AsciiDoc file extensions (#704). - Fix issues where non-Ruby code blocks would not display in Ruby 2 (#702). - Add support for extra Ruby 2 symbol types in Ripper (#701). - Ensure config directory exists before saving config file (#700). # 0.8.7.2 - September 18, 2013 - Disallow absolute URLs when using frame anchor support. - Support casted functions in CRuby method declarations (#697) # 0.8.7.1 - September 11, 2013 - Fix potential XSS issue with frame anchor support. - Add support for gettext 3.x gem. # 0.8.7 - July 26, 2013 - Added `--hide-api API` option to hide objects with a given `@api` tag (#685). - Added "Returns ...." prefix to summary when a lone @return tag is used. - Fixed issue that caused ref tags to be added to a docstring twice (#678). - Fixed formatting issue in docstring summaries (#686) # 0.8.6.2 - June 27, 2013 - Fixed issue where `yard graph` was not displaying methods # 0.8.6.1 - April 14, 2013 - Fixed broken links in File menu on default HTML template - Added --layout switch to `yard display` to wrap output in layout template. - See {file:docs/WhatsNew.md} for more information on added features. # 0.8.6 - April 13, 2013 - Various fixes and improved Ruby 2.x compatibility support - Added support for `asciidoc` markup type - Added `yard markups` command to list available markup types - Added `yard display` command to display and format an individual object - See {file:docs/WhatsNew.md} for more information on added features. # 0.8.5.2 - February 26, 2013 - Support new keyword argument syntax in method signatures (Ruby 2.x) # 0.8.5.1 - February 25, 2013 - Fix `yard diff` of gem files with RubyGems 2.x # 0.8.5 - February 24, 2013 - Basic support for Ruby 2.0 (fix compat issues in RDoc 4.0, RubyGems 2.0) - Add CSS styling for tables in default HTML template # 0.8.4.1 - February 5, 2013 - Fix regression that broke loading of existing yardoc dbs (#648) # 0.8.4 - February 4, 2013 - Add `-B/--bind` switch to yard server (#593, #608) - Add CodeObjects::Base#title for plugins to customize how object links display (#646) - Disable linking objects filtered out by verifiers (#645) - Allow macro expansion on class methods (#632) - Expand newly attached macro on first DSL method call (#631) - Disable RubyGems plugin in Ruby 2.0 (#627) - Fix line range for class/module node bodies (#626) - Search extended modules for attached DSL macros (#553) # 0.8.3 - October 14, 2012 - Add `--non-transitive-tag` to disable tag transitivity (#571) - Support --db inside .yardopts for graph/server commands (#583, #586) - Fix handling for =begin/=end docstrings (#577, #578) - Parser only sorts file lists when a glob is provided (#572) - Fix formatting in `{include:Object#method}` syntax (#569) - Fix @option tag inside of module functions (#563) - Fix to `--api` and `--no-api` support (#559) - Fix class nesting issues when path starts with "::" (#552) # 0.8.2.1 - June 9, 2012 - Fix a set of regressions in yard server search and dynamic generation # 0.8.2 - June 7, 2012 - Added progress style output in tty terminals - Embedded mixins should ignore methods defined on module (#539) - Fixed permalinks for embedded mixins in `yard server` (#540) - Improve parsing in CRuby code (#543) - Ensure Registry.resolve picks module when parsing mixins (#545) - Fixed regression that caused various commands to not show output (#548) - Respect current visibility when parsing class conditions (#551) # 0.8.1 - May 2, 2012 - Added `--[no-]api` switch to generate docs for API sets (see {file:docs/WhatsNew.md} for details) (#532) - The `yard list` command now uses cache by default (#533) - Fix `yardoc` generating incorrectly named method list file (#528) - Fix HTML output occasionally showing trailing mdash on options list (#522) # 0.8.0 - April 30, 2012 - See {file:docs/WhatsNew.md} for a list of added features - Over 20 bug fixes: - Properly filter hidden setter/getter attributes (#394) - Fix test failures in Linux environments (#397, #472, #473, #512, #513) - Fix attribute inheritance and @private (#432) - Fix attribute parsing (#435) - Allow aliases for attributes (#436) - Fix namespace fetching in `handle_alias()` (#437) - Fix overwritten attributes marked as inherited (#442) - Fix documenting constants defined from C code with `rb_define_const()` (#443) - Do not escape snippets twice (#445) - Ajax method/class search should not fire when a non-printable character is pressed (#446) - Fix yard server crashing when RDoc is not installed (#456) - Fix tags ignored when `(see #foo)` is used (#457) - Fix three "Returns" for two `@overload` tags (#458) - Do not auto-detect DSL methods as method objects if parameter name is not a valid method name (#464) - Fix attaching of macros to Object (#465) - Fix handling of `%w()` source in `[]/[]=` parsed context. (#461, pull in #468) - Don't add default `@return` if `@overload` has `@return`. (#458, pull in #469) - Don't discard tags by (see ...). (#457, pull in #470) - Fix constants listed as inherited when overwritten (#474) - Fix `yardoc --asset` behaving differently on first and subsequent calls. (#477) - `!!!lang` code blocks should set the lang in `
`'s class. (#478, #479)
- Fix "File List" search tab error. (#502)
- Fix search bar not redirecting to method page. (#509)
- Fix server returning exception message bodies as String (#518)
# 0.7.5 - January 31, 2012
- Various minor bug fixes
# 0.7.4 - December 2, 2011
- Redcarpet is now the default Markdown formatting library. GFM now works out-of-box (#404)
- Fix server side searching for elements that are marked private (#420)
- Add 'textile_strict' and 'pre' markup types, reorganize text and none (#416)
- Improve encoding line detection (#415)
- Add support for `rb_define_alias` in CRuby code (#413)
- Fix rendering of some keywords in source view (#410)
- Add support for RDoc 3.10+ (#406, #407)
- Fix typewriter text being processed in code blocks (#403)
- Improve support for has_rdoc in RubyGems 1.8.x (#401)
- See the {file:docs/WhatsNew.md} document for details on added features
# 0.7.3 - October 15, 2011
- Improve support for parsing under Ruby 1.9.2p290 and 1.9.3 (#365, #370)
- Add support for SWIG generated CRuby code (#369)
- Add support for `rb_define_attr` calls in CRuby code (#362)
- Handle file pointers in CRuby code (#358)
# 0.7.2 - June 14, 2011
- Fix `yard --help` not showing proper output
- YARD now expands path to `.yardoc` file in daemon mode for server (#328)
- Fix `@overload` tag linking to wrong method (#330)
- Fix incorrect return type when using `@macro` (#334)
- YARD now requires 'thread' to support RubyGems 1.7+ (#338)
- Fix bug in constant documentation when using `%w()` (#348)
- Fix YARD style URL links when using autolinking markdown (#353)
# 0.7.1 - May 18, 2011
- Fixes a bug in `yard server` not displaying class list properly.
# 0.7.0 - May 17, 2011
- See the {file:docs/WhatsNew.md} document for details on added features
- Make sure that Docstring#line_range is filled when possible (#243)
- Set #verifier in YardocTask (#282)
- Parse BOM in UTF-8 files (#288)
- Fix instance attributes not showing up in method list (#302)
- Fix rendering of %w() literals in constants (#306)
- Ignore keyboard shortcuts when an input is active (#312)
- And more...
# 0.6.8 - April 14, 2011
- Fix regression in RDoc 1.x markup loading
- Fix regression in loading of markup libraries for `yard server`
# 0.6.7 - April 6, 2011
- Fix has_rdoc gem specification issue with new RubyGems plugin API (oops!)
# 0.6.6 - April 6, 2011
- Fix error message when RDoc is not present (#270)
- Add markup type 'none' to perform basic HTML translation (fallback when RDoc is not present)
- Add support for RubyGems 1.7.x (#272)
- Fix rendering of `{url description}` syntax when description contains newline
# 0.6.5 - March 13, 2011
- Support `ripper` gem in Ruby 1.8.7
- Upgrade jQuery to 1.5.1
- Fix handling of alias statements with quoted symbols (#262)
- Add CSS styles (#260)
- Unhandled exception in YARD::Handlers::Ruby::MixinHandler indexing documentation for eventmachine (#248)
- Splice any alias references on method re-definitions into separate methods (#247)
- Fix "yard graph" (#245)
- Don't process ++ typewriter text inside of HTML attributes (#244)
- Prioritize loading of Kramdown before Maruku (#241)
- Skip shebang encoding in docstrings (#238)
- Fix truncation of references in @deprecated (#232)
- Show @api private note when no other tags are present (#231)
- Detect docstrings starting with "##" as `Docstring#hash_flag` (#230)
- Remove trailing whitespace from freeform tags (#229)
- Fix line through for deprecated methods (#225)
- Mistake in Tags.md (#223)
- Improve database storage by being more efficient with filesystem usage (#222)
- Make Registry thread local (#221)
- Support `private_constant` class method for 1.9.3 (#219)
- Do not assume RDoc is installed (#214)
# 0.6.4 - December 21, 2010
- Fix yri tool crashing with new Config class (gh-217)
- Fix support for ::TopLevelConstants (gh-216)
- YARD's test suite is now RSpec2 compatible (gh-215)
- Improved documentation for YARD::Server features (gh-207)
- Fix displaying of collaped method summary lists (gh-204)
- Fix automatic loading of markup providers (gh-206)
- Fix keyboard shortcuts for Chrome (gh-203)
- Disallow `extend self` inside of a class (gh-202)
- Constants now recognized in C extensions (gh-201)
# 0.6.3 - November 21, 2010
- Fixed regression that caused `yardoc --markup` to silently exit
# 0.6.2 - November 15, 2010
- **Plugins no longer automatically load, use `--plugin` to load a plugin**
- Added YARD::Config and ~/.yard/config YAML configuration file
- Added `yard config` command to view/edit YARD configuration file
- Fixes for YARD in 1.8.6 (gh-178)
- Various HTML template adjustments and fixes (gh-198,199,200)
- Improved `yard server -m` multi-project stability (gh-193)
- Fixed handling of `yardoc --no-private` with missing class definitions (gh-197)
- Added support for constants defined in C extensions (gh-177)
- Added support for Structs defined as "Klass = Struct.new(...)" (gh-187)
- Improved parsing support for third-party gems (gh-174,180)
- Improved support for JRuby 1.6.4+. YARD now passes all specs in JRuby (gh-185)
- Improved YARD documentation (gh-172,191,196)
# 0.6.1 - September 06, 2010
- Fixed TOC showing on top of class/method list in no-frames view
- A message now displays when running `yard server` with Rack/Mongrel installed
- Improved performance of JS inline search for large class/method lists
- Improved link titles for relative object links
- Removed `String#camelcase` and `String#underscore` for better Rails compat.
- Fixed support for loading .yardoc files under Windows
- Fixed inheritance tree arrows not displaying in certain environments
# 0.6.0 - August 29, 2010
- Added dynamic local documentation server
- Added @group/@endgroup declarations to organize methods into groups
- Added `yard` executable to serve as main CLI tool with pluggable commands
- Added `--asset` switch to `yardoc` to copy files/dirs to output dir
- Added ability to register/manipulate tags via CLI (`--tag`, etc.)
- Added `yard diff` command
- Added statistics to `yardoc` output (and `yard stats` command)
- Added Javascript generated Table of Contents to file pages
- Updated various APIs
- Removed `yard-graph` executable
- See more changes in the {file:docs/WhatsNew.md what's new document}
# 0.5.8 - June 22, 2010
- Merge fix from 0.6 branch for --no-private visibility checking
# 0.5.7 - June 21, 2010
- Fixed visibility flag parsing in `yardoc`
- Updated Parser Architecture documentation with new SourceParser API
- Improved Registry documentation for new load commands
- Fix loading of .yardoc file as cache (and preserving aliases)
- Fix "lib" directory missing when running YARD on installed gems
# 0.5.6 - June 12, 2010
- Bug fixes for RubyGems plugin, `has_rdoc=false` should now work
- New API for registering custom parsers. See {file:docs/WhatsNew.md}
# 0.5.5 - May 22, 2010
- Various bug fixes
# 0.5.4 - March 22, 2010
- See {file:docs/WhatsNew.md what's new document} for changes
# 0.5.3 - January 11, 2010
- See {file:docs/WhatsNew.md what's new document} for changes
# 0.5.2 - December 16, 2009
- See {file:docs/WhatsNew.md what's new document} for changes
# 0.5.1 - December 15, 2009
- See {file:docs/WhatsNew.md what's new document} for changes
# 0.5.0 - December 13, 2009
- See {file:docs/WhatsNew.md what's new document} for changes
# 0.4.0 - November 15, 2009
- Added new templating engine based on [tadpole](http://github.com/lsegal/tadpole)
- Added YARD queries (`--query` CLI argument to yardoc)
- Greatly expanded YARD documentation
- Added plugin support
- New `@abstract` and `@private` tags
- Changed default rake task to `rake yard`
- Read about changes in {file:docs/WhatsNew.md}
# 0.2.3.5 - August 13, 2009
- Minor bug fixes.
# 0.2.3.4 - August 07, 2009
- Minor bug fixes.
# 0.2.3.3 - July 26, 2009
- Minor bug fixes.
# 0.2.3.2 - July 06, 2009
- Fix Textile hard-break issues
- Add description for @see tag to use as link title in HTML docs.
- Add --title CLI option to specify a title for HTML doc files.
- Add custom.css file that can be overridden with various custom
styelsheet declarations. To use this, simply add `default/fulldoc/html/custom.css`
inside your code directory and use the `-t` template directory yardoc CLI
option to point to that template directory (the dir holding 'default').
- Add support in `yardoc` CLI to specify extra files (formerly --files)
by appending "- extra files here" after regular source files. Example:
yardoc --private lib/**/*.rb - FAQ LICENSE
# 0.2.3.1 - June 13, 2009
- Add a RubyGems 1.3.2+ plugin to generate YARD documentation instead of
RDoc. To take advantage of this plugin, set `has_rdoc = 'yard'` in your
.gemspec file.
# 0.2.3 - June 07, 2009
- See the {file:docs/WhatsNew.md} file for a list of important new features.
# 0.2.2 - Jun 16, 2008
- This is the largest changset since yard's conception and involves a complete
overhaul of the parser and API to make it more robust and far easier to
extend and use for the developer.
# 0.2.1 - February 20, 2008
- See the {file:docs/WhatsNew.md} file for a list of important new features.
# 0.1a - February 24, 2007
- Released 0.1a experimental version for testing. The goal here is
to get people testing YARD on their code because there are too many possible
code styles to fit into a sane amount of test cases. It also demonstrates the
power of YARD and what to expect from the syntax (Yardoc style meta tags).
yard-master/Gemfile 0000664 0000000 0000000 00000001010 12656766440 0014611 0 ustar 00root root 0000000 0000000 source 'https://rubygems.org'
group :development do
gem 'rspec', '~> 3.3'
gem 'rake'
gem 'rvm-tester'
gem 'simplecov'
gem 'samus'
end
group :asciidoc do
gem 'asciidoctor'
end
group :markdown do
gem 'redcarpet', '= 2.3.0', :platforms => :mri
gem 'kramdown', :platforms => :jruby
end
group :textile do
gem 'RedCloth'
end
group :server do
gem 'rack'
end
group :i18n do
gem 'gettext', '>= 2.2.1'
end
# No way to specify 1.8.7 only
# group :parser do
# gem 'ripper', :platforms => :mri_18
# end
yard-master/LEGAL 0000664 0000000 0000000 00000005643 12656766440 0014105 0 ustar 00root root 0000000 0000000 LEGAL NOTICE INFORMATION
------------------------
All the files in this distribution are covered under either the MIT
license (see the file LICENSE) except some files mentioned below.
lib/parser/ruby/legacy/ruby_lex.rb:
This file is under the Ruby license. YARD uses a modified version of it.
Ruby is copyrighted free software by Yukihiro Matsumoto .
You can redistribute it and/or modify it under either the terms of the GPL
version 2 (see the file GPL), or the conditions below:
1. You may make and give away verbatim copies of the source form of the
software without restriction, provided that you duplicate all of the
original copyright notices and associated disclaimers.
2. You may modify your copy of the software in any way, provided that
you do at least ONE of the following:
a) place your modifications in the Public Domain or otherwise
make them Freely Available, such as by posting said
modifications to Usenet or an equivalent medium, or by allowing
the author to include your modifications in the software.
b) use the modified software only within your corporation or
organization.
c) give non-standard binaries non-standard names, with
instructions on where to get the original software distribution.
d) make other distribution arrangements with the author.
3. You may distribute the software in object code or binary form,
provided that you do at least ONE of the following:
a) distribute the binaries and library files of the software,
together with instructions (in the manual page or equivalent)
on where to get the original distribution.
b) accompany the distribution with the machine-readable source of
the software.
c) give non-standard binaries non-standard names, with
instructions on where to get the original software distribution.
d) make other distribution arrangements with the author.
4. You may modify and include the part of the software into any other
software (possibly commercial). But some files in the distribution
are not written by the author, so that they are not under these terms.
For the list of those files and their copying conditions, see the
file LEGAL.
5. The scripts and library files supplied as input to or produced as
output from the software do not automatically fall under the
copyright of the software, but belong to whomever generated them,
and may be sold commercially, and may be aggregated with this
software.
6. THIS SOFTWARE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE.
yard-master/LICENSE 0000664 0000000 0000000 00000002044 12656766440 0014333 0 ustar 00root root 0000000 0000000 Copyright (c) 2007-2015 Loren Segal
Permission is hereby granted, free of charge, to any person
obtaining a copy of this software and associated documentation
files (the "Software"), to deal in the Software without
restriction, including without limitation the rights to use,
copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the
Software is furnished to do so, subject to the following
conditions:
The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
OTHER DEALINGS IN THE SOFTWARE.
yard-master/README.md 0000664 0000000 0000000 00000031352 12656766440 0014611 0 ustar 00root root 0000000 0000000 # YARD: Yay! A Ruby Documentation Tool
[](http://yardoc.org)
[](http://github.com/lsegal/yard)
[](http://rubydoc.org/gems/yard/frames)
[](https://gitter.im/lsegal/yard)
[](http://github.com/lsegal/yard/releases)
[](https://travis-ci.org/lsegal/yard)
[](#license)
## Synopsis
YARD is a documentation generation tool for the Ruby programming language.
It enables the user to generate consistent, usable documentation that can be
exported to a number of formats very easily, and also supports extending for
custom Ruby constructs such as custom class level definitions. Below is a
summary of some of YARD's notable features.
## Feature List
**1. RDoc/SimpleMarkup Formatting Compatibility**: YARD is made to be compatible
with RDoc formatting. In fact, YARD does no processing on RDoc documentation
strings, and leaves this up to the output generation tool to decide how to
render the documentation.
**2. Yardoc Meta-tag Formatting Like Python, Java, Objective-C and other languages**:
YARD uses a '@tag' style definition syntax for meta tags alongside regular code
documentation. These tags should be able to happily sit side by side RDoc formatted
documentation, but provide a much more consistent and usable way to describe
important information about objects, such as what parameters they take and what types
they are expected to be, what type a method should return, what exceptions it can
raise, if it is deprecated, etc.. It also allows information to be better (and more
consistently) organized during the output generation phase. You can find a list
of tags in the {file:docs/Tags.md#taglist Tags.md} file.
YARD also supports an optional "types" declarations for certain tags.
This allows the developer to document type signatures for ruby methods and
parameters in a non intrusive but helpful and consistent manner. Instead of
describing this data in the body of the description, a developer may formally
declare the parameter or return type(s) in a single line. Consider the
following method documented with YARD formatting:
# Reverses the contents of a String or IO object.
#
# @param [String, #read] contents the contents to reverse
# @return [String] the contents reversed lexically
def reverse(contents)
contents = contents.read if contents.respond_to? :read
contents.reverse
end
With the above @param tag, we learn that the contents parameter can either be
a String or any object that responds to the 'read' method, which is more
powerful than the textual description, which says it should be an IO object.
This also informs the developer that they should expect to receive a String
object returned by the method, and although this may be obvious for a
'reverse' method, it becomes very useful when the method name may not be as
descriptive.
**3. Custom Constructs and Extensibility of YARD**: YARD is designed to be
extended and customized by plugins. Take for instance the scenario where you
need to document the following code:
class List
# Sets the publisher name for the list.
cattr_accessor :publisher
end
This custom declaration provides dynamically generated code that is hard for a
documentation tool to properly document without help from the developer. To
ease the pains of manually documenting the procedure, YARD can be extended by
the developer to handle the `cattr_accessor` construct and automatically create
an attribute on the class with the associated documentation. This makes
documenting external API's, especially dynamic ones, a lot more consistent for
consumption by the users.
YARD is also designed for extensibility everywhere else, allowing you to add
support for new programming languages, new data structures and even where/how
data is stored.
**4. Raw Data Output**: YARD also outputs documented objects as raw data (the
dumped Namespace) which can be reloaded to do generation at a later date, or
even auditing on code. This means that any developer can use the raw data to
perform output generation for any custom format, such as YAML, for instance.
While YARD plans to support XHTML style documentation output as well as
command line (text based) and possibly XML, this may still be useful for those
who would like to reap the benefits of YARD's processing in other forms, such
as throwing all the documentation into a database. Another useful way of
exploiting this raw data format would be to write tools that can auto generate
test cases, for example, or show possible unhandled exceptions in code.
**5. Local Documentation Server**: YARD can serve documentation for projects
or installed gems (similar to `gem server`) with the added benefit of dynamic
searching, as well as live reloading. Using the live reload feature, you can
document your code and immediately preview the results by refreshing the page;
YARD will do all the work in re-generating the HTML. This makes writing
documentation a much faster process.
## Installing
To install YARD, use the following command:
$ gem install yard
(Add `sudo` if you're installing under a POSIX system as root)
Alternatively, if you've checked the source out directly, you can call
`rake install` from the root project directory.
**Important Note for Debian/Ubuntu users:** there's a possible chance your Ruby
install lacks RDoc, which is occasionally used by YARD to convert markup to HTML.
If running `which rdoc` turns up empty, install RDoc by issuing:
$ sudo apt-get install rdoc
## Usage
There are a couple of ways to use YARD. The first is via command-line, and the
second is the Rake task.
**1. yard Command-line Tool**
YARD comes packaged with a executable named `yard` which can control the many
functions of YARD, including generating documentation, graphs running the
YARD server, and so on. To view a list of available YARD commands, type:
$ yard --help
Plugins can also add commands to the `yard` executable to provide extra
functionality.
### Generating Documentation
The `yardoc` executable is a shortcut for `yard doc`.
The most common command you will probably use is `yard doc`, or `yardoc`. You
can type `yardoc --help` to see the options that YARD provides, but the
easiest way to generate docs for your code is to simply type `yardoc` in your
project root. This will assume your files are
located in the `lib/` directory. If they are located elsewhere, you can specify
paths and globs from the commandline via:
$ yardoc 'lib/**/*.rb' 'app/**/*.rb' ...etc...
The tool will generate a `.yardoc` file which will store the cached database
of your source code and documentation. If you want to re-generate your docs
with another template you can simply use the `--use-cache` (or -c)
option to speed up the generation process by skipping source parsing.
YARD will by default only document code in your public visibility. You can
document your protected and private code by adding `--protected` or
`--private` to the option switches. In addition, you can add `--no-private`
to also ignore any object that has the `@private` meta-tag. This is similar
to RDoc's ":nodoc:" behaviour, though the distinction is important. RDoc
implies that the object with :nodoc: would not be documented, whereas
YARD still recommends documenting private objects for the private API (for
maintainer/developer consumption).
You can also add extra informative files (README, LICENSE) by separating
the globs and the filenames with '-'.
$ yardoc 'app/**/*.rb' - README LICENSE FAQ
If no globs precede the '-' argument, the default glob (`lib/**/*.rb`) is
used:
$ yardoc - README LICENSE FAQ
Note that the README file can be specified with its own `--readme` switch.
You can also add a `.yardopts` file to your project directory which lists
the switches separated by whitespace (newlines or space) to pass to yardoc
whenever it is run. A full overview of the `.yardopts` file can be found in
{YARD::CLI::Yardoc}.
### Queries
The `yardoc` tool also supports a `--query` argument to only include objects
that match a certain data or meta-data query. The query syntax is Ruby, though
a few shortcuts are available. For instance, to document only objects that have
an "@api" tag with the value "public", all of the following syntaxes would give
the same result:
--query '@api.text == "public"'
--query 'object.has_tag?(:api) && object.tag(:api).text == "public"'
--query 'has_tag?(:api) && tag(:api).text == "public"'
Note that the "@tag" syntax returns the first tag named "tag" on the object.
To return the array of all tags named "tag", use "@@tag".
Multiple `--query` arguments are allowed in the command line parameters. The
following two lines both check for the existence of a return and param tag:
--query '@return' --query '@param'
--query '@return && @param'
For more information about the query syntax, see the {YARD::Verifier} class.
**2. Rake Task**
The second most obvious is to generate docs via a Rake task. You can do this by
adding the following to your `Rakefile`:
YARD::Rake::YardocTask.new do |t|
t.files = ['lib/**/*.rb', OTHER_PATHS] # optional
t.options = ['--any', '--extra', '--opts'] # optional
t.stats_options = ['--list-undoc'] # optional
end
All the settings: `files`, `options` and `stats_options` are optional. `files` will default to
`lib/**/*.rb`, `options` will represents any options you might want
to add and `stats_options` will pass extra options to the stats command.
Again, a full list of options is available by typing `yardoc --help`
in a shell. You can also override the options at the Rake command-line with the
OPTS environment variable:
$ rake yard OPTS='--any --extra --opts'
**3. `yri` RI Implementation**
The yri binary will use the cached .yardoc database to give you quick ri-style
access to your documentation. It's way faster than ri but currently does not
work with the stdlib or core Ruby libraries, only the active project. Example:
$ yri YARD::Handlers::Base#register
$ yri File.relative_path
Note that class methods must not be referred to with the "::" namespace
separator. Only modules, classes and constants should use "::".
You can also do lookups on any installed gems. Just make sure to build the
.yardoc databases for installed gems with:
$ sudo yard gems
If you don't have sudo access, it will write these files to your `~/.yard`
directory. `yri` will also cache lookups there.
**4. `yard server` Documentation Server**
The `yard server` command serves documentation for a local project or all installed
RubyGems. To serve documentation for a project you are working on, simply run:
$ yard server
And the project inside the current directory will be parsed (if the source has
not yet been scanned by YARD) and served at [http://localhost:8808](http://localhost:8808).
### Live Reloading
If you want to serve documentation on a project while you document it so that
you can preview the results, simply pass `--reload` (`-r`) to the above command
and YARD will reload any changed files on each request. This will allow you to
change any documentation in the source and refresh to see the new contents.
### Serving Gems
To serve documentation for all installed gems, call:
$ yard server --gems
This will also automatically build documentation for any gems that have not
been previously scanned. Note that in this case there will be a slight delay
between the first request of a newly parsed gem.
**5. `yard graph` Graphviz Generator**
You can use `yard graph` to generate dot graphs of your code. This, of course,
requires [Graphviz](http://www.graphviz.org) and the `dot` binary. By default
this will generate a graph of the classes and modules in the best UML2 notation
that Graphviz can support, but without any methods listed. With the `--full`
option, methods and attributes will be listed. There is also a `--dependencies`
option to show mixin inclusions. You can output to stdout or a file, or pipe directly
to `dot`. The same public, protected and private visibility rules apply to `yard graph`.
More options can be seen by typing `yard graph --help`, but here is an example:
$ yard graph --protected --full --dependencies
## Changelog
See {file:CHANGELOG.md} for a list of changes.
## License
YARD © 2007-2014 by [Loren Segal](mailto:lsegal@soen.ca). YARD is
licensed under the MIT license except for some files which come from the
RDoc/Ruby distributions. Please see the {file:LICENSE} and {file:LEGAL}
documents for more information.
yard-master/Rakefile 0000664 0000000 0000000 00000002712 12656766440 0014775 0 ustar 00root root 0000000 0000000 require File.dirname(__FILE__) + '/lib/yard'
require File.dirname(__FILE__) + '/lib/yard/rubygems/specification'
require 'rbconfig'
YARD::VERSION.replace(ENV['YARD_VERSION']) if ENV['YARD_VERSION']
task :default => :specs
desc "Builds the gem"
task :gem do
sh "gem build yard.gemspec"
end
desc "Installs the gem"
task :install => :gem do
sh "gem install yard-#{YARD::VERSION}.gem --no-document"
end
begin
require 'rvm-tester'
RVM::Tester::TesterTask.new do |t|
t.rubies = %w(1.8.6 ree jruby 1.8.7 1.9.2 1.9.3)
t.bundle_install = false # don't need to do this all the time
t.verbose = true
end
rescue LoadError
end
task :travis_ci do
ENV['SUITE'] = '1'
ENV['CI'] = '1'
ENV['LEGACY'] = nil
Rake::Task['specs'].execute
if RUBY_VERSION >= '1.9' && RUBY_PLATFORM != 'java'
puts ""
puts "Running specs with in legacy mode"
ENV['LEGACY'] = '1'
Rake::Task['specs'].execute
end
end
desc "Run all specs"
task :specs do
opts = ['rspec', '-c']
opts += ["--require", File.join(File.dirname(__FILE__), 'spec', 'spec_helper')]
opts += ['-I', YARD::ROOT]
if ENV['DEBUG']
$DEBUG = true
opts += ['-d']
end
opts += FileList["spec/**/*_spec.rb"].sort
cmd = opts.join(' ')
puts cmd if Rake.application.options.trace
system(cmd)
raise "Command failed with status (#{$?.to_i}): #{cmd}" if $?.to_i != 0
end
task :spec => :specs
YARD::Rake::YardocTask.new do |t|
t.options += ['--title', "YARD #{YARD::VERSION} Documentation"]
end
yard-master/benchmarks/ 0000775 0000000 0000000 00000000000 12656766440 0015443 5 ustar 00root root 0000000 0000000 yard-master/benchmarks/builtins_vs_eval.rb 0000664 0000000 0000000 00000001664 12656766440 0021347 0 ustar 00root root 0000000 0000000 require 'benchmark'
require File.join(File.dirname(__FILE__), '..', 'lib', 'yard')
TIMES = (ARGV[0] || 10_000).to_i
def bench_builtins(name)
YARD::CodeObjects::BUILTIN_EXCEPTIONS_HASH.has_key? name
end
def bench_eval(name)
eval(name).is_a?(Class)
rescue
false
end
Benchmark.bmbm do |b|
b.report("builtins PASS") { TIMES.times {YARD::CodeObjects::BUILTIN_EXCEPTIONS.each {|y| bench_builtins(y) } } }
b.report("eval PASS") { TIMES.times {YARD::CodeObjects::BUILTIN_EXCEPTIONS.each {|y| bench_eval(y) }} }
b.report("builtins FAIL") { TIMES.times {YARD::CodeObjects::BUILTIN_MODULES.each {|y| bench_builtins(y) } } }
b.report("eval FAIL") { TIMES.times {YARD::CodeObjects::BUILTIN_MODULES.each {|y| bench_eval(y) }} }
b.report("builtins ANY") { TIMES.times {YARD::CodeObjects::BUILTIN_CLASSES.each {|y| bench_builtins(y) } } }
b.report("eval ANY") { TIMES.times {YARD::CodeObjects::BUILTIN_CLASSES.each {|y| bench_eval(y) }} }
end yard-master/benchmarks/concat_vs_join.rb 0000664 0000000 0000000 00000000522 12656766440 0020765 0 ustar 00root root 0000000 0000000 require "benchmark"
STR1 = "Hello"
JOIN = "::"
STR2 = "World"
TESTS = 100_000
Benchmark.bmbm do |results|
results.report("concat") { TESTS.times { "".concat(STR1).concat(JOIN).concat(STR2) } }
results.report("add ") { TESTS.times { STR1 + JOIN + STR2 } }
results.report("join ") { TESTS.times { [STR1, STR2].join(JOIN) } }
end
yard-master/benchmarks/erb_vs_erubis.rb 0000664 0000000 0000000 00000002161 12656766440 0020621 0 ustar 00root root 0000000 0000000 require 'rubygems'
require 'erubis'
require 'erubis/tiny'
require 'erb'
require "benchmark"
require File.join(File.dirname(__FILE__), '..', 'lib', 'yard')
def rungen
YARD::Registry.load_yardoc(File.join(File.dirname(__FILE__), '..', '.yardoc'))
YARD::Registry.at("YARD::CodeObjects::Base").format(:format => :html)
end
Benchmark.bmbm do |x|
x.report("erubis") do
eval <<-eof
module YARD; module Templates; module Template
def erb_with(str, x) Erubis::Eruby.new(str) end
end end end
eof
rungen
end
x.report("fast-erubis") do
eval <<-eof
module YARD; module Templates; module Template
def erb_with(str, x) Erubis::FastEruby.new(str) end
end end end
eof
rungen
end
x.report("tiny-erubis") do
eval <<-eof
module YARD; module Templates; module Template
def erb_with(str, x) Erubis::TinyEruby.new(str) end
end end end
eof
rungen
end
x.report("erb") do
eval <<-eof
module YARD; module Templates; module Template
def erb_with(str, x) ERB.new(str, nil) end
end end end
eof
rungen
end
end yard-master/benchmarks/format_args.rb 0000664 0000000 0000000 00000002341 12656766440 0020274 0 ustar 00root root 0000000 0000000 require "benchmark"
require 'lib/yard'
def format_args_regex(object)
if object.signature
object.signature[/#{Regexp.quote object.name.to_s}\s*(.*)/, 1]
else
""
end
end
def format_args_parameters(object)
if !object.parameters.empty?
args = object.parameters.map {|n, v| v ? "#{n} = #{v}" : n.to_s }.join(", ")
"(#{args})"
else
""
end
end
YARD::Registry.load
$object = YARD::Registry.at('YARD::Generators::Base#G')
log.puts "regex: " + format_args_regex($object)
log.puts "params: " + format_args_parameters($object)
log.puts
TIMES = 100_000
Benchmark.bmbm do |x|
x.report("regex") { TIMES.times { format_args_regex($object) } }
x.report("parameters") { TIMES.times { format_args_parameters($object) } }
end
=begin LAST RUN Jun 23 2008
regex: (generator, opts = {})
params: (generator, opts = {})
Rehearsal ----------------------------------------------
regex 1.270000 0.020000 1.290000 ( 1.294558)
parameters 0.690000 0.000000 0.690000 ( 0.693324)
------------------------------------- total: 1.980000sec
user system total real
regex 1.260000 0.010000 1.270000 ( 1.268214)
parameters 0.670000 0.000000 0.670000 ( 0.679114)
=end
yard-master/benchmarks/generation.rb 0000664 0000000 0000000 00000002160 12656766440 0020122 0 ustar 00root root 0000000 0000000 require "benchmark"
require File.join(File.dirname(__FILE__), '..', 'lib', 'yard')
unless YARD::CodeObjects::Proxy.private_instance_methods.include?('to_obj')
raise "This benchmark is dependent on YARD::CodeObjects::Proxy#to_obj"
end
def rungen
YARD::Registry.clear
YARD::CLI::Yardoc.run('--quiet', '--use-cache')
end
def redef(lock = false)
eval <<-eof
class YARD::CodeObjects::Proxy;
def to_obj
@obj #{lock ? '||' : ''}= YARD::Registry.resolve(@namespace, @name)
end
end
eof
end
Benchmark.bmbm do |x|
x.report("gen-w/o-locking") { redef; rungen }
x.report("gen-with-locking") { redef(true); rungen }
end
=begin Results from 2008-06-07
Rehearsal ----------------------------------------------------
gen-w/o-locking 9.650000 0.450000 10.100000 ( 10.150556)
gen-with-locking 7.790000 0.400000 8.190000 ( 8.373811)
------------------------------------------ total: 18.290000sec
user system total real
gen-w/o-locking 9.820000 0.430000 10.250000 ( 10.293283)
gen-with-locking 7.820000 0.380000 8.200000 ( 8.243326)
=end yard-master/benchmarks/marshal_vs_dbm.rb 0000664 0000000 0000000 00000003520 12656766440 0020751 0 ustar 00root root 0000000 0000000 require 'benchmark'
require 'dbm'
MARSHAL_FILE = "marshal_test.db"
DBM_FILE = "dbm_test"
WRITE_TIMES = 1
READ_TIMES = 100
NUM_INDICES = 10000
INDICES = ['33', '857', '5022', '8555']
def generate_index
'0' * (rand * 4096).floor
end
def write_dbm
File.unlink(DBM_FILE + ".db") if File.exist?(DBM_FILE + ".db")
handle = DBM.new(DBM_FILE)
NUM_INDICES.times {|t| handle[t.to_s] = Marshal.dump(generate_index) }
handle.close
end
def read_dbm
db = DBM.open(DBM_FILE)
INDICES.each {|index| Marshal.load(db[index]) }
db.close
end
def write_marshal
File.unlink(MARSHAL_FILE) if File.exist?(MARSHAL_FILE)
handle = {}
NUM_INDICES.times {|t| handle[t.to_s] = generate_index }
File.open(MARSHAL_FILE, "wb") {|f| f.write(Marshal.dump(handle)) }
end
def read_marshal
db = Marshal.load(File.read(MARSHAL_FILE))
INDICES.each {|index| db[index] }
end
Benchmark.bmbm do |x|
x.report("marshal-write") { WRITE_TIMES.times { write_marshal } }
x.report("dbm-write") { WRITE_TIMES.times { write_dbm } }
x.report("marshal-read ") { READ_TIMES.times { read_marshal } }
x.report("dbm-read ") { READ_TIMES.times { read_dbm } }
end
File.unlink(MARSHAL_FILE)
File.unlink(DBM_FILE + ".db")
__END__
Rehearsal -------------------------------------------------
marshal-write 0.090000 0.070000 0.160000 ( 0.465820)
dbm-write 0.560000 0.570000 1.130000 ( 3.045556)
marshal-read 4.640000 3.180000 7.820000 ( 7.821978)
dbm-read 0.020000 0.020000 0.040000 ( 0.070920)
---------------------------------------- total: 9.150000sec
user system total real
marshal-write 0.080000 0.050000 0.130000 ( 0.436561)
dbm-write 0.560000 0.550000 1.110000 ( 2.030530)
marshal-read 4.670000 3.180000 7.850000 ( 7.842232)
dbm-read 0.010000 0.020000 0.030000 ( 0.053928)
yard-master/benchmarks/parsing.rb 0000664 0000000 0000000 00000003011 12656766440 0017426 0 ustar 00root root 0000000 0000000 require "benchmark"
require 'yard'
require 'logger'
PATH_ORDER = [
'lib/yard/autoload.rb',
'lib/yard/code_objects/base.rb',
'lib/yard/code_objects/namespace_object.rb',
'lib/yard/handlers/base.rb',
'lib/yard/generators/helpers/*.rb',
'lib/yard/generators/base.rb',
'lib/yard/generators/method_listing_generator.rb',
'lib/yard/serializers/base.rb',
'lib/**/*.rb'
]
Benchmark.bmbm do |x|
x.report("parse in order") { YARD::Registry.clear; YARD.parse PATH_ORDER, [], Logger::ERROR }
x.report("parse") { YARD::Registry.clear; YARD.parse 'lib/**/*.rb', [], Logger::ERROR }
end
=begin
load_order branch (2008-06-07):
Rehearsal --------------------------------------------------
parse in order 6.510000 0.050000 6.560000 ( 6.563223)
parse 6.300000 0.040000 6.340000 ( 6.362272)
---------------------------------------- total: 12.900000sec
user system total real
parse in order 6.310000 0.060000 6.370000 ( 6.390945)
parse 6.300000 0.050000 6.350000 ( 6.366709)
api_changes branch before merge (2008-06-07)
Rehearsal --------------------------------------------------
parse in order 6.330000 0.050000 6.380000 ( 6.397552)
parse 6.380000 0.050000 6.430000 ( 6.446954)
---------------------------------------- total: 12.810000sec
user system total real
parse in order 6.320000 0.040000 6.360000 ( 6.394460)
parse 6.040000 0.040000 6.080000 ( 6.099738)
=end
yard-master/benchmarks/pathname_vs_string.rb 0000664 0000000 0000000 00000003537 12656766440 0021673 0 ustar 00root root 0000000 0000000 require 'pathname'
require "benchmark"
require File.dirname(__FILE__) + '/../lib/yard'
pathobj = Pathname.new("a/b/c")
strobj = "a/b/c"
TIMES = 1_000
log.puts "join:"
Benchmark.bmbm do |x|
x.report("pathname") { TIMES.times { Pathname.new("a/b/c").join("d", "e", "f") } }
x.report("string ") { TIMES.times { File.join("a/b/c", "d", "e", "f") } }
x.report("pathname-sameobject") { TIMES.times { pathobj.join("d", "e", "f") } }
x.report("string-sameobject ") { TIMES.times { File.join(strobj, "d", "e", "f") } }
end
log.puts
log.puts
log.puts "cleanpath:"
Benchmark.bmbm do |x|
x.report("pathname") { TIMES.times { Pathname.new("a/b//.././c").cleanpath } }
x.report("string ") { TIMES.times { File.cleanpath("a/b//.././c") } }
end
__END__
join:
Rehearsal -------------------------------------------------------
pathname 0.330000 0.020000 0.350000 ( 0.353481)
string 0.010000 0.000000 0.010000 ( 0.001390)
pathname-sameobject 0.360000 0.020000 0.380000 ( 0.384473)
string-sameobject 0.000000 0.000000 0.000000 ( 0.001187)
---------------------------------------------- total: 0.740000sec
user system total real
pathname 0.330000 0.020000 0.350000 ( 0.350820)
string 0.000000 0.000000 0.000000 ( 0.001055)
pathname-sameobject 0.330000 0.010000 0.340000 ( 0.346949)
string-sameobject 0.000000 0.000000 0.000000 ( 0.001141)
cleanpath:
Rehearsal --------------------------------------------
pathname 0.060000 0.000000 0.060000 ( 0.059767)
string 0.010000 0.000000 0.010000 ( 0.013775)
----------------------------------- total: 0.070000sec
user system total real
pathname 0.060000 0.000000 0.060000 ( 0.059697)
string 0.020000 0.000000 0.020000 ( 0.013624) yard-master/benchmarks/rdoc_vs_yardoc.rb 0000664 0000000 0000000 00000001141 12656766440 0020765 0 ustar 00root root 0000000 0000000 require "benchmark"
files = Dir.glob(File.dirname(__FILE__) + '/../lib/**/*.rb').join(" ")
Benchmark.bmbm do |x|
x.report("rdoc") { `rm -rf rdoc && rdoc -q -o rdoc #{files} && rm -rf rdoc` }
x.report("yardoc") { `rm -rf yard && ./bin/yardoc -q -o yard #{files} && rm -rf yard` }
x.report("yardoc-cached") { `rm -rf yard && ./bin/yardoc -c -q -o yard #{files} && rm -rf yard` }
x.report("yardoc-legacy") { `rm -rf yard && ./bin/yardoc --legacy -q -o yard #{files} && rm -rf yard` }
x.report("yardoc-legacy-cached") { `rm -rf yard && ./bin/yardoc --legacy -c -q -o yard #{files} && rm -rf yard` }
end yard-master/benchmarks/registry_store_types.rb 0000664 0000000 0000000 00000002756 12656766440 0022312 0 ustar 00root root 0000000 0000000 require 'benchmark'
require File.join(File.dirname(__FILE__), '..', 'lib', 'yard')
def parse_and_select_objects
YARD::Registry.load_yardoc(File.join(File.dirname(__FILE__), '..', '.yardoc'))
YARD::Registry.load_all
$paths = []
4.times { $paths << YARD::Registry.paths[rand(YARD::Registry.paths.size)] }
$regular_registry = {}
$types_registry = {}
YARD::Registry.all.each do |object|
$regular_registry[object.path] = object
($types_registry[object.type] ||= {})[object.path] = object
end
end
def run_lookup
$paths.select {|path| $regular_registry[path] }
end
def run_lookup_with_types
$paths.select {|path| $types_registry.values.find {|list| list[path] } }
end
TIMES = 100_000
parse_and_select_objects
p $paths
Benchmark.bmbm do |x|
x.report("normal") { TIMES.times { run_lookup } }
x.report("types") { TIMES.times { run_lookup_with_types } }
end
__END__
# Run on March 22 2012
["YARD::Parser::Ruby::Legacy::RubyToken::TkUnknownChar#initialize",
"YARD::Parser::C::CParser#enumerator",
"YARD::CodeObjects::ClassObject#inherited_meths",
"YARD::Parser::C::Statement#source="]
Rehearsal ----------------------------------------------
normal 0.180000 0.000000 0.180000 ( 0.182640)
types 1.150000 0.010000 1.160000 ( 1.160219)
------------------------------------- total: 1.340000sec
user system total real
normal 0.170000 0.000000 0.170000 ( 0.165621)
types 1.140000 0.000000 1.140000 ( 1.142269)
yard-master/benchmarks/ri_vs_yri.rb 0000664 0000000 0000000 00000001054 12656766440 0017775 0 ustar 00root root 0000000 0000000 require "benchmark"
TIMES = 10
Benchmark.bmbm do |x|
x.report("ri") { TIMES.times { `ri -T YARD::Tags::Library` } }
x.report("yri") { TIMES.times { `./bin/yri -T YARD::Tags::Library` } }
end
__END__
Rehearsal ---------------------------------------
ri 0.000000 0.020000 6.880000 ( 6.929591)
yri 0.000000 0.000000 1.060000 ( 1.074840)
------------------------------ total: 7.940000sec
user system total real
ri 0.000000 0.020000 6.850000 ( 6.871660)
yri 0.000000 0.010000 1.060000 ( 1.067585)
yard-master/benchmarks/ripper_parser.rb 0000664 0000000 0000000 00000001007 12656766440 0020643 0 ustar 00root root 0000000 0000000 # encoding: utf-8
require 'benchmark'
require File.dirname(__FILE__) + '/../lib/yard'
$files = Dir[File.dirname(__FILE__) + '/../lib/**/*.rb'].map {|f| File.read(f) }
$files_rip = Dir[File.dirname(__FILE__) + '/../lib/**/*.rb'].map {|f| [File.read(f), f] }
TIMES = 2
Benchmark.bmbm do |x|
x.report("rip-parser") { TIMES.times { $files_rip.each {|f| YARD::Parser::Ruby::RubyParser.parse(*f) } } }
x.report("yard-parser ") { TIMES.times { $files.each {|f| YARD::Parser::Ruby::Legacy::StatementList.new(f) } } }
end yard-master/benchmarks/splat_vs_flatten.rb 0000664 0000000 0000000 00000000546 12656766440 0021345 0 ustar 00root root 0000000 0000000 require "benchmark"
# To prove that flattening a small list is not significantly slower than
# calling *list (used to get around create_tag list issue)
$a = "FOO BAR BAZ"
def foo(*args) args.last.inspect end
TESTS = 10_000
Benchmark.bmbm do |x|
x.report("splat") { TESTS.times { foo *$a } }
x.report("flatten") { TESTS.times { foo *[$a].flatten } }
end yard-master/benchmarks/template_erb.rb 0000664 0000000 0000000 00000001221 12656766440 0020427 0 ustar 00root root 0000000 0000000 require "benchmark"
require File.join(File.dirname(__FILE__), '..', 'lib', 'yard')
YARD::Registry.load_yardoc(File.join(File.dirname(__FILE__), '..', '.yardoc'))
obj = YARD::Registry.at("YARD::CodeObjects::Base")
TIMES = 3
Benchmark.bm do |x|
x.report("trim-line") { TIMES.times { obj.format(:format => :html) } }
module YARD
module Templates
module Template
def erb(section, &block)
erb = ERB.new(cache(section), nil)
erb.filename = cache_filename(section).to_s
erb.result(binding, &block)
end
end
end
end
x.report("no-trim ") { TIMES.times { obj.format(:format => :html) } }
end yard-master/benchmarks/template_format.rb 0000664 0000000 0000000 00000000422 12656766440 0021151 0 ustar 00root root 0000000 0000000 require "benchmark"
require File.join(File.dirname(__FILE__), '..', 'lib', 'yard')
YARD::Registry.load_yardoc(File.join(File.dirname(__FILE__), '..', '.yardoc'))
obj = YARD::Registry.at("YARD::CodeObjects::Base")
log.puts Benchmark.measure { obj.format(:format => :html) }
yard-master/benchmarks/template_profile.rb 0000664 0000000 0000000 00000000730 12656766440 0021323 0 ustar 00root root 0000000 0000000 require 'rubygems'
require 'ruby-prof'
#require 'benchmark'
require File.join(File.dirname(__FILE__), '..', 'lib', 'yard')
YARD::Registry.load_yardoc(File.join(File.dirname(__FILE__), '..', '.yardoc'))
obj = YARD::Registry.at("YARD::CodeObjects::Base")
#PerfTools::CpuProfiler.start("template_profile") do
#end
result = RubyProf.profile do
obj.format(:format => :html, :no_highlight => true)
end
printer = RubyProf::CallTreePrinter.new(result)
printer.print(STDOUT)
yard-master/benchmarks/yri_cache.rb 0000664 0000000 0000000 00000000623 12656766440 0017717 0 ustar 00root root 0000000 0000000 require File.dirname(__FILE__) + "/../lib/yard"
require "benchmark"
include YARD::CLI
class YARD::CLI::YRI
def print_object(object) end
end
def remove_cache
File.unlink(YRI::CACHE_FILE)
end
TIMES = 10
NAME = 'YARD'
remove_cache; YRI.run(NAME)
Benchmark.bmbm do |x|
x.report("cache ") { TIMES.times { YRI.run(NAME) } }
x.report("no-cache") { TIMES.times { remove_cache; YRI.run(NAME) } }
end yard-master/bin/ 0000775 0000000 0000000 00000000000 12656766440 0014076 5 ustar 00root root 0000000 0000000 yard-master/bin/yard 0000775 0000000 0000000 00000000474 12656766440 0014770 0 ustar 00root root 0000000 0000000 #!/usr/bin/env ruby
# We do all this work just to find the proper load path
path = __FILE__
while File.symlink?(path)
path = File.expand_path(File.readlink(path), File.dirname(path))
end
$:.unshift(File.join(File.dirname(File.expand_path(path)), '..', 'lib'))
require 'yard'
YARD::CLI::CommandParser.run(*ARGV)
yard-master/bin/yardoc 0000775 0000000 0000000 00000000465 12656766440 0015312 0 ustar 00root root 0000000 0000000 #!/usr/bin/env ruby
# We do all this work just to find the proper load path
path = __FILE__
while File.symlink?(path)
path = File.expand_path(File.readlink(path), File.dirname(path))
end
$:.unshift(File.join(File.dirname(File.expand_path(path)), '..', 'lib'))
require 'yard'
YARD::CLI::Yardoc.run(*ARGV)
yard-master/bin/yri 0000775 0000000 0000000 00000000462 12656766440 0014631 0 ustar 00root root 0000000 0000000 #!/usr/bin/env ruby
# We do all this work just to find the proper load path
path = __FILE__
while File.symlink?(path)
path = File.expand_path(File.readlink(path), File.dirname(path))
end
$:.unshift(File.join(File.dirname(File.expand_path(path)), '..', 'lib'))
require 'yard'
YARD::CLI::YRI.run(*ARGV)
yard-master/docs/ 0000775 0000000 0000000 00000000000 12656766440 0014256 5 ustar 00root root 0000000 0000000 yard-master/docs/CodeObjects.md 0000664 0000000 0000000 00000013100 12656766440 0016757 0 ustar 00root root 0000000 0000000 # @title CodeObjects Architecture
# CodeObjects Architecture
Code objects are Ruby objects that describe the code being documented. For instance,
all classes, modules, methods, etc. are all extracted from the Ruby source as code
objects. All of these code objects extend from the {YARD::CodeObjects::Base} class, which
provides basic attributes like source location, source code, name and path.
## CodeObjects Organization
Code objects are divided into two basic types. {YARD::CodeObjects::NamespaceObject NamespaceObjects}
and non-namespace objects. A namespace object refers to any object in Ruby that can have
other objects defined inside of it. In the context of Ruby, this specifically means
modules and classes (both of which are subclasses of `NamespaceObject`). These objects
act like tree structures, maintaining a list of all of their direct children. All non
namespace objects are simply subclasses of the Base class. The {YARD::CodeObjects::RootObject RootObject}
is a special kind of `NamespaceObject` which refers to the top level namespace in Ruby.
Methods that accept a namespace object as a parameter should also accept the symbol
`:root` as a shortcut for the root object.
The following is an overview of the classes within the `CodeObjects` namespace:

## Unique Path Representation
All CodeObjects are uniquely defined by their implementation of {YARD::CodeObjects::Base#path}.
This path is used to locate or store a code object in the {YARD::Registry}. It is therefore
essential that any Base subclass return a unique String value for #path so that the
object may co-exist with other objects in the Registry.
In practice, a path is simply the conventional Ruby representation of a class,
module, constant, class variable or method. For example, the following objects
would have the following respective paths:
* Class `Klass` inside module `Mod`: `Mod::Klass`
* Instance method `bar` inside class `Foo`: `Foo#bar`
* Class method `bar` inside class `Foo`: `Foo.bar`
* Constant `VERSION` inside class `YARD`: `YARD::VERSION`
* Class variable `@@abc` inside class `A`: `A::@@abc`
## Registry
CodeObjects classes are coupled with the {YARD::Registry} class which keeps track of
all instantiated code objects. This is an explicit design choice to allow objects
to be fetched, cached, imported and exported from a centralized location. As mentioned
above, this coupling is a result of the fact that each object is uniquely identified by
its path, which is used to implement lookups. You can read more about the registry
in the {YARD::Registry} class.
## Identity Map
Code objects are instantiated using an identity-map like implementation that guarantees
only one unique Ruby object exists for an object described by a specific path. This
allows developers to create a code object without checking if it already exists in
the {YARD::Registry}. The following example will only create one object:
id = ClassObject.new(:root, "MyClass").object_id #=> 13352
ClassObject.new(:root, "MyClass").object_id #=> 13352
## Proxy Objects
In addition to providing access to existing objects, a {YARD::CodeObjects::Proxy}
class exists which can represent an object at a path that may or may not have been
created. This is necessary to represent a reference to an object in code that is
never defined in the same body of source code, or perhaps defined later. If any
attributes of a proxy are accessed, it will immediately be resolved to the object
at its declared path. In the case where such an object exists, it will act as
a delegate to the object. However, if the object does not exist, a warning will
be raised. Whenever arbitrary code objects are used, care should be taken in
order to make sure attributes are not accessed on unresolvable proxies. An
unresolvable proxy will return a class name of `Proxy` and #type of `:proxy`,
for example:
P(:InvalidObject).type == :proxy #=> true
P(:InvalidObject).is_a?(Proxy) #=> true
## Adding Data to Code Objects
Code objects act as hash-like structures that allow any arbitrary value to be set.
This allows easy extending of existing objects without creating custom subclasses.
For instance, to add a timestamp to a method object (when it was modified, maybe),
it is possible to simply do:
object = MethodObject.new(:root, "my_method")
object[:modified_at] = Time.now
This value can now be retrieved on this object both by the hash `[]` syntax as
well as like any other method:
object.modified_at #=> 2009-06-03 20:08:46 -0400
## Creating a Custom CodeObject
It should first be mentioned that creating a custom code object should not be
necessary in most cases, except when functionality that cannot be represented
by classical Ruby objects is added. A good example *might* be a test class,
which although is technically a Ruby class, has a significantly different purpose
in documentation and needs a different set of metadata, as well as its own
representation in documentation.
The {YARD::CodeObjects::Base#path} implementation is the most important part of the
code object architecture. The first thing any custom code object must guarantee is
that its path value is unique among all other objects. The recommended way to do this
with custom objects is to add a descriptive prefix to the path. For example, the
following is an implementation of the path for a hypothetical `FooObject`:
def path
"__FooPrefix" + sep + super
end
Note that if our FooObject is a `NamespaceObject`, meaning if it can have child
FooObjects defined inside of it, you may need to verify that the prefix is only
applied once.
yard-master/docs/GettingStarted.md 0000664 0000000 0000000 00000057724 12656766440 0017547 0 ustar 00root root 0000000 0000000 # @title Getting Started Guide
# Getting Started with YARD
There are a few ways which YARD can be of use to you or your project. This
document will cover the most common ways to use YARD:
* [Documenting Code with YARD](#docing)
* [Using YARD to Generate Documentation](#using)
* [Configuring YARD](#config)
* [Extending YARD](#extending)
* [Templating YARD](#templating)
* [Plugin Support](#plugins)
## Documenting Code with YARD
By default, YARD is compatible with the same RDoc syntax most Ruby developers
are already familiar with. However, one of the biggest advantages of YARD is
the extended meta-data syntax, commonly known as "tags", that you can use
to express small bits of information in a structured and formal manner. While
RDoc syntax expects you to describe your method in a completely free-form
manner, YARD recommends declaring your parameters, return types, etc. with
the `@tag` syntax, which makes outputting the documentation more consistent
and easier to read. Consider the RDoc documentation for a method to_format:
# Converts the object into textual markup given a specific `format`
# (defaults to `:html`)
#
# == Parameters:
# format::
# A Symbol declaring the format to convert the object to. This
# can be `:text` or `:html`.
#
# == Returns:
# A string representing the object in a specified
# format.
#
def to_format(format = :html)
# format the object
end
While this may seem easy enough to read and understand, it's hard for a machine
to properly pull this data back out of our documentation. Also we've tied our
markup to our content, and now our documentation becomes hard to maintain if
we decide later to change our markup style (maybe we don't want the ":" suffix
on our headers anymore).
In YARD, we would simply define our method as:
# Converts the object into textual markup given a specific format.
#
# @param format [Symbol] the format type, `:text` or `:html`
# @return [String] the object converted into the expected format.
def to_format(format = :html)
# format the object
end
Using tags we can add semantic metadata to our code without worrying about
presentation. YARD will handle presentation for us when we decide to generate
documentation later.
## Which Markup Format?
YARD does not impose a specific markup. The above example uses standard RDoc
markup formatting, but YARD also supports textile and markdown via the
command-line switch or `.yardopts` file (see below). This means that you are
free to use whatever formatting you like. This guide is actually written
using markdown. YARD, however, does add a few important syntaxes that are
processed no matter which markup formatting you use, such as tag support
and inter-document linking. These syntaxes are discussed below.
## Adding Tags to Documentation
The tag syntax that YARD uses is the same @tag-style syntax you may have seen
if you've ever coded in Java, Python, PHP, Objective-C or a myriad of other
languages. The following tag adds an author tag to your class:
# @author Loren Segal
class MyClass
end
To allow for large amounts of text, the @tag syntax will recognize any indented
lines following a tag as part of the tag data. For example:
# @deprecated Use {#my_new_method} instead of this method because
# it uses a library that is no longer supported in Ruby 1.9.
# The new method accepts the same parameters.
def mymethod
end
### List of Tags
A list of tags can be found in {file:docs/Tags.md#taglist}
### Reference Tags
To reduce the amount of duplication in writing documentation for repetitive
code, YARD introduces "reference tags", which are not quite tags, but not
quite docstrings either. In a sense, they are tag (and docstring) modifiers.
Basically, any docstring (or tag) that begins with "(see OTHEROBJECT)" will
implicitly link the docstring or tag to the "OTHEROBJECT", copying any data
from that docstring/tag into your current object. Consider the example:
class MyWebServer
# Handles a request
# @param request [Request] the request object
# @return [String] the resulting webpage
def get(request) "hello" end
# (see #get)
def post(request) "hello" end
end
The above `#post` method takes the docstring and all tags (`param` and `return`)
of the `#get` method. When you generate HTML documentation, you will see this
duplication automatically, so you don't have to manually type it out. We can
also add our own custom docstring information below the "see" reference, and
whatever we write will be appended to the docstring:
# (see #get)
# @note This method may modify our application state!
def post(request) self.state += 1; "hello" end
Here we added another tag, but we could have also added plain text. The
text must be appended *after* the `(see ...)` statement, preferably on
a separate line.
Note that we don't have to "refer" the whole docstring. We can also link
individual tags instead. Since "get" and "post" actually have different
descriptions, a more accurate example would be to only refer our parameter
and return tags:
class MyWebServer
# Handles a GET request
# @param request [Request] the request object
# @return [String] the resulting webpage
def get(request) "hello" end
# Handles a POST request
# @note This method may modify our application state!
# @param (see #get)
# @return (see #get)
def post(request) self.state += 1; "hello" end
end
The above copies all of the param and return tags from `#get`. Note that you
cannot copy individual tags of a specific type with this syntax.
## Declaring Types
Some tags also have an optional "types" field which let us declare a list of
types associated with the tag. For instance, a return tag can be declared
with or without a types field.
# @return [String, nil] the contents of our object or nil
# if the object has not been filled with data.
def validate; end
# We don't care about the "type" here:
# @return the object
def to_obj; end
The list of types is in the form `[type1, type2, ...]` and is mostly free-form,
so we can also specify duck-types or constant values. For example:
# @param argname [#to_s] any object that responds to `#to_s`
# @param argname [true, false] only true or false
Note the latter example can be replaced by the meta-type "Boolean".
Another meta-type is "void", which stands for "no meaningful value"
and is used for return values. These meta-types are by convention
only, but are recommended.
List types can be specified in the form `CollectionClass`.
For instance, consider the following Array that holds a set of Strings and
Symbols:
# @param list [Array] the list of strings and symbols.
We mentioned that these type fields are "mostly" free-form. In truth, they
are defined "by convention". To view samples of common type specifications
and recommended conventions for writing type specifications, see
[http://yardoc.org/types.html](http://yardoc.org/types.html). Note that these
conventions may change every now and then, although we are working on a more
"formal" type specification proposal.
## Documenting Attributes
To document a Ruby attribute, add documentation text above the attribute
definition.
# Controls the amplitude of the waveform.
# @return [Numeric] the amplitude of the waveform
attr_accessor :amplitude
As a short-hand syntax for declaring reader and writer attribute pairs,
YARD will automatically wire up the correct method types and information
by simply defining documentation in the `@return` tag. For example,
the following declaration will show the correct information for the
`waveform` attribute, both for the getter's return type and the
setter's value parameter type:
# @return [Numeric] the amplitude of the waveform
attr_accessor :amplitude
In this case, the most important details for the attribute are the
object type declaration and its descriptive text.
### Documentation for a Separate Attribute Writer
Usually an attribute will get and set a value using the same syntax,
so there is no reason to have separate documentation for an attribute
writer. In the above `amplitude` case, the `Numeric` type is both used
for the getter and setter types.
Sometimes, however, you might want to have separate documentation
for the getter and setter. In this case, you would still add
the documentation text to the getter declaration (or `attr_accessor`)
and use `@overload` tags to declare the separate docstrings. For example:
# @overload amplitude
# Gets the current waveform amplitude.
# @return [Numeric] the amplitude of the waveform
# @overload amplitude=(value)
# Sets the new amplitude.
# @param value [Numeric] the new amplitude value
# @note The new amplitude will only take effect if {#restart}
# is called on the stream.
Note that by default, YARD exposes the reader portion of the attribute
in HTML output. If you have separate `attr_reader` and `attr_writer`
declarations, make sure to put your documentation (for both reader
and writer methods) on the reader declaration using `@overload`
tags as described above. For example:
# @overload ...documentation here...
attr_reader :amplitude
# This documentation will be ignored by YARD.
attr_writer :amplitude
## Documenting Custom DSL Methods
Application code in Ruby often makes use of DSL style metaprogrammed methods.
The most common is the `attr_accessor` method, which of course has built-in
support in YARD. However, frameworks and libraries often expose custom
methods that perform similar metaprogramming tasks, and it is often useful
to document their functionality in your application. Consider the `property`
method in a project like [DataMapper](http://datamapper.org), which creates
a typed attribute for a database model. The code might look like:
class Post
include DataMapper::Resource
property :title, String
end
As of version 0.7.0, YARD will automatically pick up on these basic methods if
you document them with a docstring. Therefore, simply adding some comments to
the code will cause it to generate documentation:
class Post
include DataMapper::Resource
# @return [String] the title property of the post
property :title, String
end
Note that YARD uses the first argument in the method call to determine the
method name. In some cases, this would not be the method name, and you would
need to declare it manually. You can do so with the `@!method` directive:
# @!method foo
create_a_foo_method
The @!method directive can also accept a full method signature with parameters:
# @!method foo(name, opts = {})
create_a_foo_method
You can also set visibility and scope, or modify the method signature with
extra tags. The following adds documentation for a private class method:
# @!method foo(opts = {})
# The foo method!
# @!scope class
# @!visibility private
create_a_private_foo_class_method
Finally, you can tag a method as an attribute by replacing the @!method
tag with @!attribute. The @!attribute directive allows for the flags [r], [w],
or [rw] to declare a readonly, writeonly, or readwrite attribute, respectively.
# @!attribute [w]
# The writeonly foo attribute!
a_writeonly_attribute :foo
(Note that if the name can be automatically detected, you do not need to
specify it in the @!method or @!attribute directives)
However, you will notice a few drawbacks with this basic support:
1. There is a fair bit of duplication in such documentation. Specifically, we
repeat the term String and title twice in the property example.
2. We must write a code comment for this property to show up in the documentation.
If we do not write a comment, it is ignored.
### Macros
Fortunately YARD 0.7.0 also adds macros, a powerful way to add support for
these DSL methods on the fly without writing extra plugins. Macros allow
you to interpolate arguments from the method call inside the docstring,
reducing duplication. If we re-wrote the `property` example from above
using a macro, it might look like:
class Post
include DataMapper::Resource
# @!macro dm.property
# @return [$2] the $1 $0 of the post
property :title, String
end
(Note that $0 represents the method call, in this case `property`. The rest
are arguments in the method call.)
The above example is equivalent to the first version shown in the previous
section. There is also some extra benefit to using this macro, in that we
can re-apply it to any other property in our class by simply calling on
the macro. The following:
# @!macro dm.property
property :view_count, Integer
Would be equivalent to:
# @return [Integer] the view_count property of the post
property :view_count, Integer
Finally, macros can be "attached" to method calls, allowing them to be implicitly
activated every time the method call is seen in the source code of the class,
or an inheriting class. By simply adding the `[attach]` flag, the macro
becomes implicit on future calls. All of the properties below get documented
by using this snippet:
class Post
include DataMapper::Resource
# @!macro [attach] dm.property
# @return [$2] the $1 $0 of the post
property :title, String
property :view_count, Integer
property :email, String
end
You can read more about macros in the {file:docs/Tags.md Tags Overview} document.
## Customized YARD Markup
YARD supports a special syntax to link to other code objects, URLs, files,
or embed docstrings between documents. This syntax has the general form
of `{Name OptionalTitle}` (where `OptionalTitle` can have spaces, but `Name`
cannot).
### Linking Objects `{...}`
To link another "object" (class, method, module, etc.), use the format:
{ObjectName#method OPTIONAL_TITLE}
{Class::CONSTANT My constant's title}
{#method_inside_current_namespace}
Without an explicit title, YARD will use the relative path to the object as
the link name. Note that you can also use relative paths inside the object
path to refer to an object inside the same namespace as your current docstring.
Note that the `@see` tag automatically links its data. You should not use
the link syntax in this tag:
# @see #methodname <- Correct.
# @see {#methodname} <- Incorrect.
If you want to use a Hash, prefix the first { with "!":
# !{ :some_key => 'value' }
### Linking URLs `{http://...}`
URLs are also linked using this `{...}` syntax:
{http://example.com Optional Title}
{mailto:email@example.com}
### Linking Files `{file:...}`
Files can also be linked using this same syntax but by adding the `file:`
prefix to the object name. Files refer to extra readme files you added
via the command-line. Consider the following examples:
{file:docs/GettingStarted.md Getting Started}
{file:mypage.html Name#anchor}
As shown, you can also add an optional `#anchor` if the page is an HTML link.
### Embedding Docstrings `{include:...}`
We saw the `(see ...)` syntax above, which allowed us to link an entire docstring
with another. Sometimes, however, we just want to copy docstring text without
tags. Using the same `{...}` syntax, but using the `include:` prefix, we can
embed a docstring (minus tags) at a specific point in the text.
# This class is cool
# @abstract
class Foo; end
# This is another class. {include:Foo} too!
class Bar; end
The docstring for Bar becomes:
"This is another class. This class is cool too!"
### Embedding Files `{include:file:...}`
You can embed the contents of files using `{include:file:path/to/file}`,
similar to the `{include:OBJECT}` tag above. If the file uses a specific markup
type, it will be applied and embedded as marked up text. The following
shows how the tag can be used inside of comments:
# Here is an example of a highlighted Ruby file:
#
# {include:file:examples/test.rb}
### Rendering Objects `{render:...}`
Entire objects can also be rendered in place in documentation. This can be
used for guide-style documentation which does not document the entire source
tree, but instead selectively renders important classes or methods. Consider
the following documentation inside of a README file:
!!!plain
= igLatinPay!
This library adds pig latin methods to the string class, allowing you
to transform sentences into pig latin.
{render:String#pig_latin}
You can also un-pig-latin-ify a word or sentence:
{render:String#de_pig_latin}
The above would render the methods in place inside the README document,
allowing you to summarize a small library in a single file.
## Using YARD to Generate Documentation
### `yard` Executable
YARD ships with a single executable aptly named `yard`. In addition to
generating standard documentation for your project, you would use this tool
if you wanted to:
* Document all installed gems
* Run a local documentation server
* Generate UML diagrams using [Graphviz][graphviz]
* View `ri`-style documentation
* Diff your documentation
* Analyze documentation statistics.
The following commands are available in YARD 0.6.x (see `yard help` for a
full list):
Usage: yard [options]
Commands:
config Views or edits current global configuration
diff Returns the object diff of two gems or .yardoc files
doc Generates documentation
gems Builds YARD index for gems
graph Graphs class diagram using Graphviz
help Retrieves help for a command
ri A tool to view documentation in the console like `ri`
server Runs a local documentation server
stats Prints documentation statistics on a set of files
Note that `yardoc` is an alias for `yard doc`, and `yri` is an alias for
`yard ri`. These commands are maintained for backwards compatibility.
### `.yardopts` Options File
Unless your documentation is very small, you'll end up needing to run `yardoc`
with many options. The `yardoc` tool will use the options found in this file.
It is recommended to check this in to your repository and distribute it with
your source. This file is placed at the root of your project (in the directory
you run `yardoc` from) and contains all of arguments you would otherwise pass
to the command-line tool. For instance, if you often type:
yardoc --no-private --protected app/**/*.rb - README LEGAL COPYING
You can place the following into your `.yardopts`:
--no-private --protected app/**/*.rb - README LEGAL COPYING
This way, you only need to type:
yardoc
Any extra switches passed to the command-line now will be appended to your
`.yardopts` options.
Note that options for `yardoc` are discussed in the {file:README.md README},
and a full overview of the `.yardopts` file can be found in {YARD::CLI::Yardoc}.
### Documenting Extra Files
"Extra files" are extra guide style documents that help to give a brief overview
of how to use your library/framework, as well as any extra information that
might be vital for your users. The most common "extra file" is the README,
which is automatically detected by YARD if found in the root of your project
(any file starting with `README*`). You can specify extra files on the command
line (or in the `.yardopts` file) by listing them after the '-' separator:
yardoc lib/**/*.rb ext/**/*.c - LICENSE.txt
Note that the README will automatically be picked up, so you do not need to
specify it. If you don't want to modify the default file globs, you can ignore
the first set of arguments:
yardoc - LICENSE.txt
Below you can read about how to customize the look of these extra files, both
with markup and pretty titles.
#### Adding Meta-Data to Extra Files
You can add YARD-style `@tag` metadata to the top of any extra file if prefixed
by a `#` hash comment. YARD allows for arbitrary meta-data, but pays special
attention to the tags `@markup`, `@encoding`, and `@title`. Note that there
cannot be any whitespace before the tags. Here is an example of some tag data
in a README:
# @markup markdown
# @title The Best Library in the World!
# @author The Author Name
This is the best library you will ever meet. Lipsum ...
The `@markup` tag allows you to specify a markup format to use for the file,
including "markdown", "textile", "rdoc", "ruby", "text", "html", or "none"
(no markup). This can be used when the markup cannot be auto-detected using
the extension of the filename, if the file has no extension, or if you want
to override the auto-detection.
By using `@encoding` you can specify a non-standard encoding. Note that
`yardoc --charset` sets the global encoding (for all comments / files),
so if you are using unicode across all your files, you can specify it there.
Using the `@encoding` tag might be used to override the default global
charset, say, if you had a localized `README.jp` file with SJIS data.
Also note that this only affects Ruby 1.9.x, as Ruby 1.8 is not properly
encoding aware.
The `@title` tag allows you to specify a full title name for the document.
By default, YARD uses the filename as the title of the document and lists
it in the file list in the index and file menu. In some cases, the file name
might not be descriptive enough, so YARD allows you to specify a full title:
contents of TITLE.txt:
# @title The Title of The Document
Currently all other meta-data is hidden from view, though accessible
programmatically using the {YARD::CodeObjects::ExtraFileObject} class.
## Configuring YARD
YARD (0.6.2+) supports a global configuration file stored in `~/.yard/config`.
This file is stored as a YAML file and can contain arbitrary keys and values
that can be used by YARD at run-time. YARD defines specific keys that are used
to control various features, and they are listed in {YARD::Config::DEFAULT_CONFIG_OPTIONS}.
A sample configuration file might look like:
:load_plugins: false
:ignored_plugins:
- my_plugin
- my_other_plugin
:autoload_plugins:
- my_autoload_plugin
:safe_mode: false
You can also view and edit these configuration options from the commandline
using the `yard config` command. To list your configuration, use `yard config --list`.
To view a key, use `yard config ITEM`, and to set it, use `yard config ITEM VALUE`.
## Extending YARD
There are many ways to extend YARD to support non-standard Ruby syntax (DSLs),
add new meta-data tags or programmatically access the intermediate metadata
and documentation from code. An overview of YARD's full architecture can be
found in the {file:docs/Overview.md} document.
For information on adding support for Ruby DSLs, see the {file:docs/Handlers.md}
and {file:docs/Parser.md} architecture documents.
For information on adding extra tags, see {file:docs/Tags.md}.
For information on accessing the data YARD stores about your documentation,
look at the {file:docs/CodeObjects.md} architecture document.
## Templating YARD
In many cases you may want to change the style of YARD's templates or add extra
information after extending it. The {file:docs/Templates.md} architecture
document covers the basics of how YARD's templating system works.
## Plugin Support
As of 0.4, YARD will automatically load any gem named with the prefix of
`yard-` or `yard_`. You can use this to load a custom plugin that
[extend](#extending) YARD's functionality. A good example of this
is the [yard-rspec][yard-rspec] plugin, which adds [RSpec][rspec] specifications
to your documentation (`yardoc` and `yri`). You can try it out by installing
the gem or cloning the project and trying the example:
$ gem install yard-rspec -s http://gemcutter.org
or
$ git clone git://github.com/lsegal/yard-spec-plugin
YARD also provides a way to temporarily disable plugins on a per-user basis.
To disable a plugin create the file `~/.yard/ignored_plugins` with a list
of plugin names separated by newlines. Note that the `.yard` directory might
not exist, so you may need to create it.
[graphviz]:http://www.graphviz.org
[yard-rspec]:http://github.com/lsegal/yard-spec-plugin
[rspec]:http://rspec.info
yard-master/docs/Handlers.md 0000664 0000000 0000000 00000015210 12656766440 0016337 0 ustar 00root root 0000000 0000000 # @title Handlers Architecture
# Handlers Architecture
Handlers allow the processing of parsed source code. Handling is done after
parsing to abstract away the implementation details of lexical and semantic
analysis on source and to only deal with the logic regarding recognizing
source statements as {file:docs/CodeObjects.md code objects}.

## The Pipeline
After the {file:docs/Parser.md parser component} finishes analyzing the
source, it is handed off for post-processing to the {YARD::Handlers::Processor}
class, which is responsible for traversing the set of statements given by
the parser and delegating them to matching handlers. Handlers match when the
{YARD::Handlers::Base.handles?} method returns true for a given statement.
The handler can then perform any action after being invoked by the `process`
method.
## The Processor Class
The main purpose of the processor, as mentioned above, is to traverse through
the list of statements given to it by the parser. The processor also keeps
state about what is being processed. For instance, the processor is what keeps
track of the current namespace (the module or class an object is being defined
in), scope (class or instance), file and owner. The owner refers to the object
that is most directly responsible for the source statement being processed. This
is most often the same as the namespace, except when parsing the body of a method,
where the namespace would be the class/module the method is defined in and the
owner would be the method object itself.
## Implementing a Handler
This section covers the basics of implementing a *new-style* Ruby handler. For
details on implementing a legacy handler, see the "API Differences" section below.
a Ruby handler can be implemented simply by subclassing the {YARD::Handlers::Ruby::Base}
class and declaring what node types or source to process with the {YARD::Handlers::Base.handles handles}
class method. A very simple handler that handles a module definition would be:
class MyModuleHandler < YARD::Handlers::Ruby::Base
handles :module
def process
puts "Handling a module named #{statement[0].source}"
end
end
For details on what nodes are, and what node types are, see the
{file:docs/Parser.md parser architecture document}.
In this case the node type being handled is the `:module` type. More than one
node type or `handles` declarations may describe a single handler, for instance,
a handler that handles class definitions should handle the `:class` and `:sclass`
node types respectively (the latter refers to classes defined as `class << Something`).
The {YARD::Handlers::Base#statement statement} attribute refers to the current
node (or statement) that is being handled by the handler.
### Handling a Method Call
In some cases, a developer might need to handle a method call. The parser can
express a method call in many AST forms, so to simplify this process, a method
call can be handled by declaring the following in a `handles` statement:
class MyHandler < YARD::Handlers::Ruby::Base
handles method_call(:describe)
def process
# Process the method call
end
end
In this case we handle any of the method calls to method name `describe` with
the following syntaxes:
describe(something)
describe arg1, arg2, arg3
describe(something) { perform_a_block }
describe "Something" do
a_block
end
### Creating a new Code Object
Usually (but not always) handling is performed to create new code objects to add
to the registry (for information about code objects, see {file:docs/CodeObjects.md this document}).
Code objects should simply be created and added to the existing `namespace`. This
will be enough to add them to the registry. There is also a convenience
{YARD::Handlers::Base#register register} method which quickly sets standard attributed
on the newly created object, such as the file, line, source and docstring of the
object. This method will be seen in the next example.
### Handling an Inner Block
By default, the parser gives the processor class a list of all the top level
statements and the processor parses only those top level statements. If an inner
block of a module, class, method declaration or even a block passed to a method call
needs to be handled, the {YARD::Handlers::Base#parse_block parse_block} method must be called on the list of statements
to parse. This will send the list to the processor to continue processing on that
statement list. The source tree can be selectively parsed in this manner by parsing
only the inner blocks that are relevant to documentation.
For example, the module handler parses the inner body of a module by performing
the following commands:
class YARD::Handlers::Ruby::ModuleHandler < YARD::Handlers::Ruby::Base
handles :module
def process
modname = statement[0].source
mod = register ModuleObject.new(namespace, modname)
parse_block(statement[1], :namespace => mod)
end
end
In this case `statement[1]` refers to a list of extra statements, the block we
wish to parse. Note here that when parsing objects like modules and classes,
we set the namespace for the duration of the block parsing by setting options
on the `parse_block` method.
### API Differences for Legacy Handler
Because the legacy handler uses the legacy parser and therefore a different kind
of AST, there are subtle differences in the handler API. Most importantly, the
`handles` method usually deals with either lexical tokens or source code as a string
or RegExp object. The statement object, similarly, is made up of lexical tokens instead
of semantically parsed nodes (this is described in the {file:docs/Parser.md parser document}).
The module example above can be rewritten as a legacy handler as follows:
class YARD::Handlers::Ruby::Legacy::ModuleHandler < YARD::Handlers::Ruby::Legacy::Base
handles TkMODULE
def process
modname = statement.tokens.to_s[/^module\s+(#{NAMESPACEMATCH})/, 1]
mod = register ModuleObject.new(namespace, modname)
parse_block(:namespace => mod)
end
end
A few notes on the differences:
* We inherit from `Legacy::Base` instead of the standard Ruby Base handler class.
* We exchange node type `:module` for `TkMODULE`, which represents the
first token in the statement.
* We perform direct string manipulation to get the module name.
* `parse_block` does not take a list of statements. In the old parser API,
each statement has a `block` attribute which defines the list of
statements within that statement, if any. Therefore, `parse_block` will
always parse the `statement.block` if it exists.
yard-master/docs/Overview.md 0000664 0000000 0000000 00000005025 12656766440 0016410 0 ustar 00root root 0000000 0000000 # @title Architecture Overview
# Architecture Overview
YARD is separated in three major components, each of which allows YARD to be
extended for a separate purpose. The split also emphasizes YARD's design choice
to explicitly separate data gathering from HTML document generation, something
that tools like RDoc do not do. These components are:
* [Code Parsing & Processing Component](#parsing)
* [Data Storage Component](#storage)
* [Post Processing & Templating System](#templates)
This separation is a major goal of the project, and means that YARD is not *just*
a tool to generate HTML output. The expectation is that any subset of YARD's
major components may be used, extended or modified independently. YARD may be
used just as a data gathering tool (to parse and audit code), just as a data
source (a webserver containing raw unformatted data about code), or just as a
conventional HTML documentation generation tool (like RDoc).
The important classes and dependencies of these components are shown in the
following class diagram:

## Code Parsing & Processing Component
This component is made up of four sub-components, each of which have separate
tasks during the data gathering process (*note: the tag architecture is not*
*shown in the class diagram*). These sub-components are:
* {file:docs/Parser.md}
* {file:docs/Handlers.md}
* {file:docs/CodeObjects.md}
* {file:docs/Tags.md}
The parser component reads source files and converts it into a set of statements
which the handlers then process, creating code objects which in turn create tags
(meta-data) attached to the objects. These objects are all added to the {YARD::Registry},
the data store component.
## Data Storage Component
This component is currently implemented as a simple Ruby marshalled flat namespace
of object. The implementation is found in the single class {YARD::Registry}, which
is the centralized repository for all data being parsed, stored and accessed. There
are future plans to improve this storage mechanism to be backend agnostic and allow
for more robust storage.
## Post Processing & Templating System
This component handles processing of objects from the registry through a templating
engine that allows output to a variety of formats. Practically speaking, this is
where templates can be implemented to change the design, output or structure of
the data. See {file:docs/Templates.md Templates Architecture} for a complete overview.
yard-master/docs/Parser.md 0000664 0000000 0000000 00000021251 12656766440 0016035 0 ustar 00root root 0000000 0000000 # @title Parser Architecture
# Parser Architecture
The parser component of YARD is the first component in the data processing pipeline
that runs before any handling is done on the source. The parser is meant to translate
the source into a set of statements that can be understood by the {file:docs/Handlers.md Handlers}
that run immediately afterwards.
The important classes are described in the class diagram of the entire parser
system below:

(Note: the RubyToken classes are omitted from the diagram)
## SourceParser
The main class {YARD::Parser::SourceParser} acts as a factory class, instantiating
the correct parser class, an implementation of {YARD::Parser::Base}. The selected parser
is chosen based on either the file extension or by selecting it explicitly (as an argument
to parsing methods). YARD supports Ruby and C source files, but custom parsers can
be implemented and registered for various other languages by subclassing `Parser::Base`
and registering the parser with {YARD::Parser::SourceParser.register_parser_type}.
This factory class should always be used when parsing source files rather than
the individual parser classes since it initiates the pipeline that runs the
handlers on the parsed source. The parser used must also match the handlers,
and this is coordinated by the `SourceParser` class as well.
## Using the SourceParser Class
The `SourceParser` class API is optimized for parsing globs of files. As such,
the main method to use the class is the `parse` class method, which takes an
array of file globs or a single file glob.
YARD::Parser::SourceParser.parse('spec_*.rb')
YARD::Parser::SourceParser.parse(['spec_*.rb', '*_helper.rb'])
This is equivalent to the convenience method {YARD.parse}:
YARD.parse('lib/**/*.rb')
In some cases (ie. for testing), it may be more helpful to parse a string of input
directly. In such a case, the method {YARD::Parser::SourceParser.parse_string} should be
used:
YARD::Parser::SourceParser.parse_string("def method(a, b) end")
You can also provide the parser type explicitly as the second argument:
# Parses a string of C
YARD::Parser::SourceParser.parse_string("int main() { }", :c)
Note that these two methods are aliased as {YARD.parse} and {YARD.parse_string} for
convenience.
## Implementing and Registering a Custom Parser
To implement a custom parser, subclass {YARD::Parser::Base}. Documentation on which
abstract methods should be implemented are documented in that class. After the class
is implemented, it is registered with the {YARD::Parser::SourceParser} factory class
to be called when a file of the right extension needs to be parsed, or when a user
selects that parser type explicitly. To register your new parser class, call the
method {YARD::Parser::SourceParser.register_parser_type}:
SourceParser.register_parser_type(:my_parser, MyParser, 'my_parser_ext')
The last argument can be a single extension, a list of extensions (Array), a single Regexp, or a
list of Regexps. Do not include the '.' in the extension.
## The Two Ruby Parser Types
When parsing Ruby, the SourceParser can either instantiate the new {YARD::Parser::Ruby::RubyParser}
class or the {YARD::Parser::Ruby::Legacy::StatementList} class. The first of the
two, although faster, more robust and more efficient, is only available for
Ruby 1.9. The legacy parser parser is available in both 1.8.x and 1.9, if
compatibility is required. The choice of parser will affect which handlers
ultimately get used, since new handlers can only use the new parser and the
same requirement applies to the legacy parser & handlers.
## Switching to Legacy Parser
By default, running YARD under Ruby 1.9 will automatically select the new parser
and new handlers by extension. Although YARD supports both handler styles, plugins
may choose to only implement one of the two (though this is not recommended). If
only the legacy handlers are implemented, the `SourceParser` class should force
the use of the legacy parser by setting the `parser_type` attribute as such:
YARD::Parser::SourceParser.parser_type = :ruby18
The default value is `:ruby`. Note that this cannot be forced the other way around,
a parser type of `:ruby` cannot be set under Ruby 1.8.x as the new parser is not
supported under 1.8.
## RubyParser (the New Parser)
The new Ruby parser uses the Ripper library that is packaged as part of stdlib
in Ruby 1.9. Because of this, it can generate an AST from a string of Ruby input
that is similar to the style of other sexp libraries (such as ParseTree). Each
node generated in the tree is of the base type {YARD::Parser::Ruby::AstNode},
which has some subclasses for common node types.
### AstNode Basics
The `AstNode` class behaves like a standard Array class in which all of its data
make up the list of elements in the array. Unlike other sexp style libraries, however,
the node type is not the first element of the list. Instead, the node type is defined
by the `#type` method. The following examples show some of the basic uses of `AstNode`:
# The sexp defines the statement `hello if 1`
node = s(:if_mod, s(:int, "1"), s(:var_ref, s(:ident, "hello")))
node.type #=> :if_mod
node[0] #=> s(:int, "1")
node[0][0] #=> "1"
(Note the `s()` syntax is shorthand for `AstNode.new(...)`. `s()` with no type
is shorthand for a node of type `:list`)
As shown, not all of the elements are AstNodes in themselves, some are String
objects containing values. A list of only the AstNodes within a node can be
accessed via the {YARD::Parser::Ruby::AstNode#children #children} method. Using
the sexp declared above, we can do:
node.children #=> [s(:int, "1"), s(:var_ref, s(:ident, "hello"))]
### AstNode#source and #line
Every node defines the `#source` method which returns the source code that the
node represents. One of the most common things to do with a node is to grab its
source. The following example shows how this can be done:
source = "if 1 == 1 then\n raise Exception\n end"
ast = YARD::Parser::Ruby::RubyParser.parse(source).root
ast[0].condition.source #=> "1 == 1"
ast[0].then_block.source #=> "raise Exception"
Note that this only works on source parsed from the RubyParser, not sexps
declared using the `s()` syntax. This is because no source code is generated
or stored by nodes. Instead, only the character ranges are stored, which are
then looked up in the original full source string object. For example:
# Following the code snippet above
ast[0].then_block.source_range #=> 17..31
We can also get the line and line ranges in a similar fashion:
ast[0].type #=> :if
ast[0].line #=> 1
ast[0].line_range #=> 1..3 (note the newlines in the source)
### AstNode#jump
Often the AST will be such that the node we care about might be buried arbitrarily
deep in a node's hierarchy. The {YARD::Parser::Ruby::AstNode#jump} method exists
to quickly get at a node of a specific type in such a situation:
# Get the first identifier in the statement
ast = s(s(:int, "1"), s(s(:var_ref, s(:ident, "hello"))))
ast.jump(:ident)[0] #=> "hello"
Multiple types can be searched for at once. If none are found, the original root
node is returned so that it may be chained.
## The Legacy Parser
The goal of the legacy parser is much the same as the new parser, but it is far
more simplistic. Instead of a full-blown AST, the legacy parser simply groups
together lists of "statements" called a {YARD::Parser::Ruby::Legacy::StatementList}.
These statement lists are made up of {YARD::Parser::Ruby::Legacy::Statement} objects.
A statement is any method call condition, loop, or declaration. Each statement
may or may not have a block. In the case of a condition or loop, the block is
the inner list of statements; in the case of a method call, the block is a do
block (if provided). The statements themselves are made up of tokens, so instead
of being semantic in nature like the new parser, statements are tied directly
to the lexical tokens that make them up. To convert a statement into source, you
simply join all the tokens together (this is done through the use of `#to_s`).
Note that because there is little semantic parsing, the legacy parser is less
able to deal with certain Ruby syntaxes. Specifically, the `:if_mod` syntax
seen above ("hello if 1") would be considered two statements with the new parser,
but using the legacy parser it is only one statement:
stmts = ARD::Parser::Ruby::Legacy::StatementList.new("hello if 1")
stmts[0].block #=> nil
stmts[0].tokens.to_s #=> "hello if 1"
In addition, this means that most handling still needs to be done via string
manipulation and regular expression matching, making it considerably more
difficult to use in edge case scenarios.
yard-master/docs/Tags.md 0000664 0000000 0000000 00000032243 12656766440 0015502 0 ustar 00root root 0000000 0000000 # @title Tags Overview
# Tags Overview
Tags represent meta-data as well as behavioural data that can be added to
documentation through the `@tag` style syntax. As mentioned, there are two
basic types of tags in YARD, "meta-data tags" and "behavioural tags", the
latter is more often known as "directives". These two tag types can be
visually identified by their prefix. Meta-data tags have a `@` prefix,
while directives have a prefix of `@!` to indicate that the directive
performs some potentially mutable action on or with the docstring. The
two tag types would be used in the following way, respectively:
# @meta_data_tag some data
# @!directive_tag some data
class Foo; end
This document describes how tags can be specified, how they affect your
documentation, and how to use specific built-in tags in YARD, as well
as how to define custom tags.
## Meta-Data Tags
Meta-data tags are useful to add arbitrary meta-data about a documented
object. These tags simply add data to objects that can be looked up later,
either programmatically, or displayed in templates. The benefit to describing
objects using meta-data tags is that your documentation can be organized
semantically. Rather than having a huge listing of text with no distinction
of what each paragraph is discussing, tags allow you to focus in on specific
elements of your documentation.
For example, describing parameters of a method can often be important to your
documentation, but should not be mixed up with the documentation that describes
what the method itself does. In this case, separating the parameter documentation
into {tag:param} tags can yield much better organized documentation, both in
source and in your output, without having to manually format the data using
standard markup.
All of this meta-data can be easily parsed by tools and used both in your templates
as well as in code checker tools. An example of how you can leverage tags
programmatically is shown in the {tag:todo} tag, which lists a small snippet of
Ruby code that can list all of your TODO items, if they are properly tagged.
Custom meta-data tags can be added either programmatically or via the YARD
command-line. This is discussed in the "[Adding Custom Tags](#Adding_Custom_Tags)"
section.
A list of built-in meta-data tags are found below in the [Tag List](#Tag_List).
## Directives
Directives are similar to meta-data tags in the way they are specified, but they
do not add meta-data to the object directly. Instead, they affect the parsing
context and objects themselves, allowing a developer to create objects
(like methods) outright, rather than simply add text to an existing object.
Directives have a `@!` prefix to differentiate these tags from meta-data tags,
as well as to indicate that the tag may modify or create new objects when
it is called.
A list of built-in directives are found below in the [Directive List](#Directive_List).
## Tag Syntax
Tags begin with the `@` or `@!` prefix at the start of a comment line, followed
immediately by the tag name, and then optional tag data (if the tag requires it).
Unless otherwise specified by documentation for the tag, all "description" text
is considered free-form data and can include any arbitrary textual data.
### Multi-line Tags
Tags can span multiple lines if the subsequent lines are indented by more than
one space. The typical convention is to indent subsequent lines by 2 spaces.
In the following example, `@tagname` will have the text *"This is indented tag data"*:
# @tagname This is
# indented tag data
# but this is not
For most tags, newlines and indented data are not significant and do not impact
the result of the tag. In other words, you can decide to span a tag onto multiple
lines at any point by creating an indented block. However, some tags like
{tag:example}, {tag:overload}, {tag:!macro}, {tag:!method}, and {tag:!attribute}
rely on the first line for special information about the tag, and you cannot
split this first line up. For instance, the {tag:example} tag uses the first line
to indicate the example's title.
### Common Tag Syntaxes
Although custom tags can be parsed in any way, the built-in tags follow a few
common syntax structures by convention in order to simplify the syntax. The
following syntaxes are available:
1. **Freeform data** — In this case, any amount of textual data is allowed,
including no data. In some cases, no data is necessary for the tag.
2. **Freeform data with a types specifier list** — Mostly freeform data
beginning with an *optional* types specifier list surrounded in `[brackets]`.
Note that for extensibility, other bracket types are allowed, such as `<>`,
`()` and `{}`. The contents of the list are discussed in detail below.
3. **Freeform data with a name and types specifier list** — freeform
data beginning with an *optional* types list, as well as a name key. The
name key is *required*. Note that for extensibility, the name can be placed
*before* the types list, like: `name [Types] description`. In this case,
a separating space is not required between the name and types, and you
can still use any of the other brackets that the type specifier list allows.
4. **Freeform data with title** — freeform data where the first line cannot
be split into multiple lines. The first line must also always refer to the
"title" portion, and therefore, if there is no title, the first line must
be blank. The "title" might occasionally be listed by another name in tag
documentation, however, you can identify this syntax by the existence of
a multi-line signature with "Indented block" on the second line.
In the tag list below, the term "description" implies freeform data, `[Types]`
implies a types specifier list, "name" implies a name key, and "title" implies
the first line is a newline significant field that cannot be split into multiple
lines.
### Types Specifier List
In some cases, a tag will allow for a "types specifier list"; this will be evident
from the use of the `[Types]` syntax in the tag signature. A types specifier list
is a comma separated list of types, most often classes or modules, but occasionally
literals. For example, the following {tag:return} tag lists a set of types returned
by a method:
# Finds an object or list of objects in the db using a query
# @return [String, Array, nil] the object or objects to
# find in the database. Can be nil.
def find(query) finder_code_here end
A list of conventions for type names is specified below. Typically, however,
any Ruby literal or class/module is allowed here. Duck-types (method names
prefixed with "#") are also allowed.
Note that the type specifier list is always an optional field and can be omitted
when present in a tag signature. This is the reason why it is surrounded by
brackets. It is also a freeform list, and can contain any list of values, though
a set of conventions for how to list types is described below.
### Type List Conventions
A list of examples of common type listings and what they translate into is
available at http://yardoc.org/types.
Typically, a type list contains a list of classes or modules that are associated
with the tag. In some cases, however, certain special values are allowed or required
to be listed. This section discusses the syntax for specifying Ruby types inside of
type specifier lists, as well as the other non-Ruby types that are accepted by
convention in these lists.
It's important to realize that the conventions listed here may not always adequately
describe every type signature, and is not meant to be a complete syntax. This is
why the types specifier list is freeform and can contain any set of values. The
conventions defined here are only conventions, and if they do not work for your
type specifications, you can define your own appropriate conventions.
Note that a types specifier list might also be used for non-Type values. In this
case, the tag documentation will describe what values are allowed within the
type specifier list.
#### Class or Module Types
Any Ruby type is allowed as a class or module type. Such a type is simply the name
of the class or module.
Note that one extra type that is accepted by convention is the `Boolean` type,
which represents both the `TrueClass` and `FalseClass` types. This type does not
exist in Ruby, however.
#### Parametrized Types
In addition to basic types (like String or Array), YARD conventions allow for
a "generics" like syntax to specify container objects or other parametrized types.
The syntax is `Type`. For instance, an Array might
contain only String objects, in which case the type specification would be
`Array`. Multiple parametrized types can be listed, separated by commas.
Note that parametrized types are typically not order-dependent, in other words,
a list of parametrized types can occur in any order inside of a type. An array
specified as `Array` can contain any amount of Strings or Fixnums,
in any order. When the order matters, use "order-dependent lists", described below.
#### Duck-Types
Duck-types are allowed in type specifier lists, and are identified by method
names beginning with the "#" prefix. Typically, duck-types are recommended
for {tag:param} tags only, though they can be used in other tags if needed.
The following example shows a method that takes a parameter of any type
that responds to the "read" method:
# Reads from any I/O object.
# @param [#read] io the input object to read from
def read(io) io.read end
#### Hashes
Hashes can be specified either via the parametrized type discussed above,
in the form `Hash`, or using the hash specific syntax:
`Hash{KeyTypes=>ValueTypes}`. In the latter case, KeyTypes or ValueTypes can
also be a list of types separated by commas.
#### Order-Dependent Lists
An order dependent list is a set of types surrounded by "()" and separated by
commas. This list must contain exactly those types in exactly the order specified.
For instance, an Array containing a String, Fixnum and Hash in that order (and
having exactly those 3 elements) would be listed as: `Array<(String, Fixnum, Hash)>`.
#### Literals
Some literals are accepted by virtue of being Ruby literals, but also by YARD
conventions. Here is a non-exhaustive list of certain accepted literal values:
* `true`, `false`, `nil` — used when a method returns these explicit literal
values. Note that if your method returns both `true` or `false`, you should use
the `Boolean` conventional type instead.
* `self` — has the same meaning as Ruby's "self" keyword in the context of
parameters or return types. Recommended mostly for {tag:return} tags that are
chainable.
* `void` — indicates that the type for this tag is explicitly undefined.
Mostly used to specify {tag:return} tags that do not care about their return
value. Using a `void` return tag is recommended over no type, because it makes
the documentation more explicit about what the user should expect. YARD will
also add a note for the user if they have undefined return types, making things
clear that they should not use the return value of such a method.
### Reference Tags
Reference tag syntax applies only to meta-data tags, not directives.
If a tag's data begins with `(see OBJECT)` it is considered a "reference tag".
A reference tag literally copies the tag data by the given tag name from the
specified OBJECT. For instance, a method may copy all {tag:param} tags from
a given object using the reference tag syntax:
# @param [String] user the username for the operation
# @param [String] host the host that this user is associated with
# @param [Time] time the time that this operation took place
def clean(user, host, time = Time.now) end
# @param (see #clean)
def activate(user, host, time = Time.now) end
## Adding Custom Tags
If a tag is specific to a given project, consider namespacing
it by naming it in the form projectname.tagname, ie.,
yard.tag_signature.
Custom tags can be added to YARD either via the command-line or programmatically.
The programmatic method is not discussed in this document, but rather in the
{file:docs/TagsArch.md} document.
To add a custom tag via the command-line or .yardopts file, you can use the
`--*-tag` options. A few different options are available for the common tag
syntaxes described above. For example, to add a basic freeform tag, use:
!!!sh
$ yard doc --tag rest_url:"REST URL"
This will register the `@rest_url` tag for use in your documentation and display
this tag in HTML output wherever it is used with the heading "REST URL".
Note that the tag title should follow the tag name with a colon (`:`). Other
tag syntaxes exist, such as the type specifier list freeform tag
(`--type-tag`), or a named key tag with types (`--type-name-tag`).
If you want to create a tag but not display it in output (it is only for
programmatic use), add `--hide-tag tagname` after the definition:
!!!sh
$ yard doc --tag complexity:"McCabe Complexity" --hide-tag complexity
Note that you might not need a tag title if you are hiding it. The title
part can be omitted.
{yard:include_tags}
yard-master/docs/TagsArch.md 0000664 0000000 0000000 00000011144 12656766440 0016275 0 ustar 00root root 0000000 0000000 # @title Tags Architecture
# Tags Architecture
## Programmatic API
### Accessing Tag Information
Tag metadata is added when a {YARD::Docstring} is added to a {file:docs/CodeObjects.md code object}
using the {YARD::CodeObjects::Base#docstring=} attribute. In addition to adding
conventional comments, tags are parsed and associated with the object. The easiest
way to access tags on an object is to use the {YARD::CodeObjects::Base#tag} and `#tags`
methods, for example:
# Using the Foo class object from above
obj.tags(:tagname).first.text #=> "some data"
Because multiple tags can be stored with the same name, they are stored as a list
of tags. The `#tag` method is an alias for the first item in the list of tags.
Also note that the `#tag`, `#tags` and `#has_tag?` methods are all convenience
methods that delegate to the {YARD::Docstring} object described above.
### Adding Custom Tags
The `@tagname` tag used in the above examples is clearly not part of the tags
that come with YARD. If such a tag would actually be part of documentation under
a default install, YARD would raise a warning that the tag does not exist. It is,
however, trivial to add this tag to be recognized by YARD.
All tags in YARD are added to the {YARD::Tags::Library tag library} which makes
use of a tag factory class to parse the data inside the tags. To simply add a
tag that stores simple text like our `@tagname` tag above, use:
YARD::Tags::Library.define_tag("A Sample Tag", :tagname)
This will now allow YARD to add the metadata from `@tagname` to the docstring.
## Tag Factory Architecture
Recognizing a tag is one part of the process. Parsing the tag contents is the
second step. YARD has a tag architecture that allows developers to add or completely
change the way tags contents can be parsed.
The separation of registration and tag creation can be seen in the following
class diagram:

### DefaultFactory
By default, YARD has a few standard syntaxes that can be parsed for tags. These
are all implemented by the {YARD::Tags::DefaultFactory} class. These syntaxes
are:
* Standard text: no parsing is done, but text is stripped of newlines and
multiple spaces.
* Raw text: does no parsing at all, no stripping of newlines or spaces. This
is best used for code snippets.
* Raw text with title: does no parsing on the text but extracts the first line
of the metadata as the "title", useful for tags such as `@example`:
# @example Inspect an element
# myobj.inspect #=> #
* Text with types: parses a list of types at the beginning of the text. Types
are optional. The standard syntax is in the form `[type1, type2, ...]`,
for example:
# @return [String, Symbol] a description here
# @return description here with no types
* Text with types and a name: parses a list of types at the beginning of text
followed by a name and extra descriptive text. For example:
# @param [String] str the string to reverse
def reverse(str) '...' end
As mentioned above, this syntax is implemented by the `DefaultFactory` which can
be swapped out for any factory. In some cases, a developer may want to change
the type declaration syntax to be in the form:
# @tagname name description
This can be done by simply implementing a new factory that parses the data in
this form.
### Implementing a Factory
Factories should implement the method `parse_tag` as well as any `parse_tag_SUFFIX`
method where SUFFIX refers to the suffix added when declaring the tag. For example,
a tag can also be declared as follows:
YARD::Tags::Library.define_tag "Parameter", :param, :with_types
In such a case, the factory will be called with method `parse_tag_with_types`. In
all cases, the method should return a new {YARD::Tags::Tag} object. Generally,
the `parse_tag` methods take 2 or 3 parameters. A simple tag can be implemented
as:
def parse_tag(tag_name, text)
Tag.new(tag_name, text)
end
The text parameter contains pre-parsed text with extra spaces and newlines removed.
If required, the method could also be declared with a third parameter containing
unmodified raw text:
def parse_tag_with_raw_text(tag_name, text, raw_text)
Tag.new(tag_name, raw_text)
end
Note that this method would be invoked for a tag declared with the `:with_raw_text`
suffix.
### Changing the Factory
To change the factory, set the {YARD::Tags::Library.default_factory} attribute:
YARD::Tags::Library.default_factory = MyFactory
This must be done before any parsing is done, or the factory will not be used.
yard-master/docs/Templates.md 0000664 0000000 0000000 00000045373 12656766440 0016552 0 ustar 00root root 0000000 0000000 # @title Templates Architecture
# Templates Architecture
Templates are the main component in the output rendering process of YARD,
which is invoked when conventional HTML/text output needs to be rendered
for a set of code objects.
## Design Goals
The general design attempts to be as abstracted from actual content and templates
as possible. Unlike RDoc which uses one file to describe the entire template,
YARD splits up the rendering of code objects into small components, allowing
template modification for smaller subsets of a full template without having to
duplicate the entire template itself. This is necessary because of YARD's support
for plugins. YARD is designed for extensibility by external plugins, and because
of this, no one plugin can be responsible for the entire template because no
one plugin knows about the other plugins being used. For instance, if an RSpec
plugin was added to support and document specifications in class templates,
this information would need to be transparently added to the template to work
in conjunction with any other plugin that performed similar template modifications.
The design goals can be summarized as follows:
1. Output should be able to be rendered for any arbitrary format with little
modification to YARD's source code. The addition of extra templates should
be sufficient.
2. The output rendered for an object should independently rendered data
from arbitrary sources. These independent components are called "sections".
3. Sections should be able to be inserted into any object without affecting
any existing sections in the document. This allows for easy modification
of templates by plugins.
## Templates
Template modules are the objects used to orchestrate the design goals listed
above. Specifically, they organize the sections and render the template contents
depending on the format.
## Engine
The Engine class orchestrates the creation and rendering of Template modules and
handles serialization or specific rendering scenarios (like HTML). To create
a template, use the {YARD::Templates::Engine.template template} method. The two most
common methods used to initiate output are the {YARD::Templates::Engine.render render}
and {YARD::Templates::Engine.generate generate} methods which generate and
optionally serialize output to a file. The latter, `#generate`, is used
specially to generate HTML documentation and copy over assets that may be
needed. For instance, an object may be rendered with:
YARD::Templates::Engine.render(:object => myobject)
A set of objects may be rendered into HTML documentation by using:
# all_objects is an array of module and class objects
# options includes a :serializer key to copy output to the file system
YARD::Templates::Engine.generate(all_objects, options)
Note that these methods should not be called directly. The {YARD::CodeObjects::Base}
class has a {YARD::CodeObjects::Base#format #format} helper method to render an
object. For instance, the above render example is equivalent to the simple
call `myobject.format`. The `generate` method is a special kind of render
and is called from the {YARD::CLI::Yardoc} command line utility.
## Template Options
A template keeps state when it is rendering output. This state is kept in
an options hash which is initially passed to it during instantiation. Some
default options set the template style (`:template`), the output format (`:format`),
and the serializer to use (`:serializer`). This options hash is modifiable
from all methods seen above. For example, initializing a template to output as
HTML instead of text can be done as follows:
myobject.format(:format => :html)
## Serializer
This class abstracts the logic involved in deciding how to serialize data to
the expected endpoint. For instance, there is both a {YARD::Serializers::StdoutSerializer StdoutSerializer}
and {YARD::Serializers::FileSystemSerializer FileSystemSerializer} class for
outputting to console or to a file respectively. When endpoints with locations
are used (like files or URLs), the serializer implements the {YARD::Serializers::Base#serialized_path #serialized_path}
method. This allows the translation from a code object to its path at the endpoint,
which enables inter-document linking.
Rendered objects are automatically serialized using the object if present,
otherwise the rendered object is returned as a string to its parent. Nested
Templates automatically set the serializer to nil so that they return
as a String to their parent.
## Creating a Template
Templates are represented by a directory inside the {YARD::Templates::Engine.template_paths}
on disk. A standard template directory looks like the following tree:
(Assuming templates/ is a template path)
templates
`-- default
|-- class
| |-- dot
| | |-- setup.rb
| | `-- superklass.erb
| |-- html
| | |-- constructor_details.erb
| | |-- setup.rb
| | `-- subclasses.erb
| |-- setup.rb
| `-- text
| |-- setup.rb
| `-- subclasses.erb
|-- docstring
| |-- html
| | |-- abstract.erb
| | |-- deprecated.erb
| | |-- index.erb
| | `-- text.erb
| |-- setup.rb
| `-- text
| |-- abstract.erb
| |-- deprecated.erb
| |-- index.erb
| `-- text.erb
The path `default` refers to the template style (:template key in options hash)
and the directories at the next level (such as `class`) refer to template
`:type` (options hash key) for a template. The next directory refers to the
output format being used defined by the `:format` template option.
As we saw in the above example, the format option can be set to `:html`, which
would use the `html/` directory instead of `text/`. Finally, the individual .erb
files are the sections that make up the template.
Note that the subdirectory `html/` is also its own "template" that inherits
from the parent directory. We will see more on this later.
## setup.rb
Every template should have at least one `setup.rb` file that defines the
{YARD::Templates::Template#init #init} method to set the
{YARD::Templates::Template#sections #sections} used by the template. If
a setup.rb is not defined in the template itself, there should be a template
that is inherited (via parent directory or explicitly) that sets the sections
on a newly created template.
A standard setup.rb file looks like:
def init
sections :section1, :section2, :section3
end
## Sections
Sections are smaller components that correlate to template
fragments. Practically speaking, a section can either be a template fragment
(a conventional .erb file or other supported templating language), a method
(which returns a String) or another {YARD::Templates::Template} (which in turn has its own
list of sections).
## Nested Sections
Sections often require the ability to encapsulate a set of sub-sections in markup
(HTML, for instance). Rather than use heavier Template subclass objects, a more
lightweight solution is to nest a set of sub-sections as a list that follows
a section, for example:
def init
sections :header, [:section_a, :section_b]
end
The above example nests `section_a` and `section_b` within the `header` section.
Practically speaking, these sections can be placed in the result by `yield`ing
to them. A sample header.erb template might contain:
Header
<%= yieldall %>
This template code would place the output of `section_a` and `section_b` within
the above div element. Using `yieldall`, we can also change the object that is being
rendered. For example, we may want to yield the first method of the class.
We can do this like so:
First method
<%= yieldall :object => object.meths.first %>
This would run the nested sections for the method object instead of the class.
Note that `yieldall` yields to all subsections, whereas `yield` will yield
to each individually (in order) until there are no more left to yield to.
In the vast majority of cases, you'd want to use `yieldall`, since `yield`
makes it hard for users to override your template.
## Inheriting Templates
Parent directory templates are automatically inherited (or mixed in, to be
more accurate) by the current template. This means that the 'default/class/html'
template automatically inherits from 'default/class'. This also means that anything
defined in 'default/class/setup.rb' can be overridden by 'default/class/html/setup.rb'.
Since the Template module is a module, and not a class, they can be mixed in
explicitly (via include/extend) from other templates, which allows templates
to share erb files or helper logic. The 'default/class' template explicitly
mixes in the 'default/module' template, since it uses much of the same sections.
This is done with the helper {YARD::Templates::Template::ClassMethods#T T} method, which
is simply a shorthand for {YARD::Templates::Engine.template Engine.template}.
It can then override (using standard inheritance) the sections from the module
template and insert sections pertaining to classes. This is one of the design
goals described above.
For instance, the first line in `default/class/html/setup.rb` is:
include T('default/module/html')
This includes the 'default/module/html', which means it also includes 'default/module'
by extension. This allows class to make use of any of module's erb files.
## Inserting and Traversing Sections
The ability to insert sections was mentioned above. The class template, for
instance, will modify the #init method to insert class specific sections:
def init
super
sections.place(:subclasses).before(:children)
sections.delete(:children)
sections.place([:constructor_details, [T('method_details')]]).before(:methodmissing)
end
Observe how sections has been modified after the super method was called (the
super method would have been defined in `default/module/setup.rb`). The
`sections` object is of the {YARD::Templates::Section} class and allows sections to be inserted
before or after another section using {Array#place} by it's given name rather
than index. This allows the overriding of templates in a way that does not
depend on where the section is located (since it may have been overriden by
another module).
You can also use `sections[:name]` to find the first child section named `:name`.
For instance, with the following sections declaration:
sections :a, [:b, :c, [:d]]
You can get to the :d section with:
sections[:a][:c][:d]
You can use this to insert a section inside a nested set without using indexed
access. The following command would result in `[:a, [:b, :c, [:d, :e]]]`:
sections[:a][:c].place(:e).after(:d)
There are also two methods, {Insertion#before_any} and {Insertion#after_any},
which allow you to insert sections before or after the first matching section name
recursively. The above example could simply be rewritten as:
sections.place(:e).after_any(:d)
## Overriding Templates by Registering a Template Path
Inheriting templates explicitly is useful when creating a customized template
that wants to take advantage of code re-use. However, most users who want
to customize YARD templates will want to override existing behaviour without
creating a template from scratch.
YARD solves this problem by allowing other template paths to be registered.
Because template modules are represented by a relative path such as 'default/class',
they can be found within any of the registered template paths. A new template
path is registered as:
YARD::Templates::Engine.register_template_path '/path/to/mytemplates'
At this point, any time the 'default/class' template is loaded, the template
will first be looked for inside the newly registered template path. If found,
it will be used as the template module, with the modules from the other
template paths implicitly mixed in.
Therefore, by using the same directory structure as a builtin YARD template,
a user can customize or override individual templates as if the old ones were
inherited. A real world example would further modify the 'default/class' template
seen above by creating such a path in our '/path/to/mytemplates' custom template
path:
/path/to/mytemplates/:
|-- class
| |-- html
| | |-- customsection.erb
| |-- setup.rb
The `setup.rb` file would look like:
def init
super
sections.push :customsection
end
Now, when a class object is formatted as HTML, our customsection.erb will be
appended to the rendered data.
### Overriding Stylesheets and Javascripts
Template authors can override existing stylesheets and javascripts by creating
a file with the same name as existing files within the `fulldoc` template. The
documentation output will utilize the new replacement file.
YARD's `fulldoc` template defines three stylesheets:
/yard/templates/default/:
|-- fulldoc
| |-- html
| | |-- css
| | | |-- common.css
| | | |-- full_list.css
| | | |-- style.css
The `style.css` is the primary stylesheet for the HTML output.
The `full_list.css` is an additional stylesheet loaded specifically for the
search field menus (i.e. class list, method list, and file list).
The `common.css` is an empty css file that an template author can easily override
to provide custom styles for their plugin. However, if a user installs multiple
plugins that utilize this same file to deliver styles, it is possible that they
will be overridden.
YARD's `fulldoc` template defines three javascript files:
/yard/templates/default/:
|-- fulldoc
| |-- html
| | |-- js
| | | |-- app.js
| | | |-- full_list.js
| | | |-- jquery.js
The `app.js` is the primary javascript file for the HTML output.
The `full_list.js` defines additional javascript loaded specifically for the
search field menus (i.e. class list, method list, and file list).
The `jquery.js` is copy of the jquery javascript library.
### Adding a Custom Stylesheet or Javascript
To load additional stylesheets and javascripts with every page (except the search
field menus) generated from the base `layout` template:
1. Define your own custom stylesheet and/or javascript file
(default/ is the default template name inside of the /template root directory):
/template/default/:
|-- fulldoc
| |-- html
| | |-- css
| | | |-- custom.css
| | |-- js
| | | |-- custom.js
2. Create a `setup.rb` in the `layout` template directory and override the methods
`stylesheets` and `javascripts`. The path to the template would be:
/template/default/:
|-- layout
| |-- html
| | |-- setup.rb
And the code would look like:
def stylesheets
# Load the existing stylesheets while appending the custom one
super + %w(css/custom.css)
end
def javascripts
# Load the existing javascripts while appending the custom one
super + %w(js/custom.js)
end
To load additional stylesheets and javascripts for the search menus loaded from
the `fulldoc` template:
1. Define your own custom stylesheet and/or javascript file.
/path/to/mytemplates/:
|-- fulldoc
| |-- html
| | |-- css
| | | |-- custom_full_menu.css
| | |-- js
| | | |-- custom_full_menu.js
3. Override the methods `stylesheets_full_list` and `javascripts_full_list`
in the `setup.rb` file inside fulldoc/html.
def stylesheets_full_list
# Load the existing stylesheets while appending the custom one
super + %w(css/custom.css)
end
def javascripts_full_list
# Load the existing javascripts while appending the custom one
super + %w(js/custom.js)
end
### Overriding Search Menus
By default YARD's `fulldoc` template generates three search fields:
* Class List
* Method List
* File List
Their contents are rendered in methods within the `fulldoc` template:
* `generate_class_list`
* `generate_method_list`
* `generate_file_list`
To override these lists you will need to:
1. Create a `setup.rb` in the `fulldoc` template directory and override the
particular method.
/path/to/mytemplates/:
|-- fulldoc
| |-- html
| | |-- setup.rb
def generate_method_list
@items = prune_method_listing(Registry.all(:method), false)
@items = @items.reject {|m| m.name.to_s =~ /=$/ && m.is_attribute? }
# Here we changed the functionality to reverse the order of displayed methods
@items = @items.sort_by {|m| m.name.to_s }.reverse
@list_title = "Method List"
@list_type = "methods"
asset('method_list.html', erb(:full_list))
end
### Adding Additional Search Menus
By default YARD's `fulldoc` template generates three search fields:
* Class List
* Method List
* File List
These are defined in the `layout` template method `menu_lists` and pulled into
the `fulldoc` template through a similarly named method.
To load an additional menu item:
1. Create a `setup.rb` in the `layout` template directory and override the methods
`menu_lists`. The `type` informs the search field the name of the file.
The `title` is the name that appears above the section when viewed in frames.
The `search_title` is the name that appears in the search field tab on the page.
/path/to/mytemplates/:
|-- layout
| |-- html
| | |-- setup.rb
def menu_lists
# Load the existing menus
super + [ { :type => 'feature', :title => 'Features', :search_title => 'Feature List' } ]
end
2. Create a `setup.rb` in the `fulldoc` template directory and create a method
to generate a menu for the specified `type`.
The method `generate_assets` will look for a function with a signature prefixed
with `generate`, the type value specified, and the suffix `list`. Within that
method you can configure and load the specific objects you wish to display.
/path/to/mytemplates/:
|-- fulldoc
| |-- html
| | |-- setup.rb
def generate_feature_list
# load all the features from the Registry
@items = Registry.all(:feature)
@list_title = "Feature List"
@list_type = "feature"
# optional: the specified stylesheet class
# when not specified it will default to the value of @list_type
@list_class = "class"
# Generate the full list html file with named feature_list.html
# @note this file must be match the name of the type
asset('feature_list.html', erb(:full_list))
end
yard-master/docs/WhatsNew.md 0000664 0000000 0000000 00000151447 12656766440 0016354 0 ustar 00root root 0000000 0000000 # @title What's New?
# What's New in 0.8.x?
1. **Directives (new behavioural tag syntax)** (0.8.0)
2. **Added `--embed-mixin(s)` to embed mixins into class docs** (0.8.0)
3. **Internationalization (I18n) support for translating docs** (0.8.0)
4. **New C parser / handlers architecture** (0.8.0)
5. **YARD will now warn if `@param` name not in method params** (0.8.0)
6. **Added support for `module_function` calls in Ruby code** (0.8.0)
7. **Greatly improved tag documentation using custom template** (0.8.0)
8. **Tags can now contain '.' for namespacing** (0.8.0)
9. **Added "frames" links for non-framed pages for better nav** (0.8.0)
10. **Added Gemfile support to YARD server for local gem sets** (0.8.0)
11. **Server now displays README on index route like static docs** (0.8.0)
12. **Added line numbers to `yard stats --list-undoc --compact`** (0.8.0)
13. **Single object db now default (multi-object db unsupported)** (0.8.0)
14. **Added `--api` tag to generate documentation for API sets** (0.8.1)
15. **Added `--non-transitive-tag` to disable transitive tag** (0.8.3)
16. **Added `-B/--bind` to bind to a port in yard server** (0.8.4)
17. **Added `asciidoc` markup type support** (0.8.6)
18. **Added `yard markups` command to list available markup types** (0.8.6)
19. **Added `yard display` command to display formatted objects** (0.8.6)
20. **Added `--layout` to `yard display` command** (0.8.6.1)
21. **Added `stats_options` for the rake task** (0.8.7.6)
## Directives (new behavioural tag syntax) (0.8.0)
The tags {tag:!macro}, {tag:!method}, {tag:!attribute}, {tag:!group},
{tag:!endgroup}, {tag:!scope} and {tag:!visibility} have been changed
from meta-data tags to directives. This means they should now be called
with the "@!" prefix instead of "@". Note however that for
backward compatibility, the old "@macro", "@method", etc.,
syntax for all of these tags will still work and is supported.
Some backwards incompatible changes were made to {tag:!macro} syntax.
Please read this section carefully if you are using this tag.
YARD 0.8.0 adds a new tag syntax called "directives" using the `@!`
prefix. These directive tags can be used to modify parser state while
processing objects, or even create new objects on the fly. A plugin
API is available similar to tags, and directives should be registered
in the {YARD::Tags::Library} class using {YARD::Tags::Library.define_directive}.
To use a directive, simply call it the same way as any tag. Tag syntax
is documented in {file:docs/Tags.md}.
### Notable features of directives
#### Directives do not need to be attached to object docstrings
Unlike meta-data tags which apply to created objects, directives
do not need to be attached to an object in order to be used. This
means you can have free-standing comments with directives, such as:
# @macro mymacro
# A new macro, not attached to any docstring
# ...other Ruby code here...
# Using the macro:
# @macro mymacro
def mymethod; end
You can do the same to define methods and attributes, as discussed
below.
#### `@!method` and `@!attribute` directives improved
The method and attribute directives can now be used to create multiple
objects in a single docstring. Previously a `@method` or `@attribute`
tag would only create one method per docstring. In 0.8.0, you could
attach multiple methods to the same block of Ruby source, such as:
# @!method foo(a, b, c)
# @!method bar(x, y, z)
# Docstring for code
some_ruby_source
The above creates #foo and #bar and the source listing for both will
be `some_ruby_source` with "Docstring for code" as the docstring.
The attribute directive can take advantage of this functionality as well.
Note that these directives also do not need to be attached to a line of
code to be recognized; they can be in free-standing comments if the
methods are defined dynamically and not associated with any code.
#### New `@!parse` directive to parse Ruby code
A new {tag:!parse} directive was added that allows a developer to have
YARD parse code that might not necessarily be parseable in its original
form. This is useful when using `instance_eval` and other dynamic
meta-programming techniques to define methods or perform functionality.
For instance, a common case of the "self.included" callback in module
to extend a module on a class might be in the form:
def self.included(mod)
mod.extend(self)
end
Unfortunately, this does not get picked up by YARD, but on the original
class, we can add:
class MyClass
# @!parse extend TheDynamicModule
include TheDynamicModule
end
YARD will then parse the code `extend TheDynamicModule` as if
it were in the source file.
You can also use this technique to register regular methods as
attributes, if you did not define them with `attr_*` methods:
def foo; @foo end
def foo=(v) @foo = v end
# Register them as methods:
# @!parse attr_accessor :foo
### Backward incompatible changes to `@!macro` directive
Unfortunately, in order to create the new directives architecture,
some previously supported syntax in `@macro` tags are no longer supported.
Specifically, macros can no longer expand text on an entire docstring.
Instead, macros only expand the data that is indented inside of the tag
text.
This syntax is **no longer supported**:
# @macro mymacro
# Expanding text $1 $2 $3
property :a, :b, :c
In 0.7.0 to 0.7.5, the above would have created a method with the docstring
"Expanding text a b c". This will not work in 0.8.0. Instead, you must
indent all the macro expansion data so that it is part of the `@macro`
tag as follows:
# @!macro mymacro
# Expanding text $1 $2 $3
property :a, :b, :c
Note that we also use the recommended `@!macro` syntax, though `@macro`
is still supported.
## Added `--embed-mixin(s)` to embed mixins into class docs (0.8.0)
Methods from mixins can now be embedded directly into the documentation
output for a class by using `--embed-mixin ModuleName`, or `--embed-mixins`
for all mixins. This enables a documentation writer to refactor methods
into modules without worrying about them showing up in separate files
in generated documentation. When mixin methods are embedded, they
show up in both the original module page and the pages of the classes
they are mixed into. A note is added to the method signature telling the
user where the method comes from.
The `--embed-mixin` command-line option can also take wildcard values
in order to match specific namespaces. For instance, you can embed
only mixins inside of a "Foo::Bar" namespace by doing:
!!!sh
$ yard doc --embed-mixin "Foo::Bar::*"
## Internationalization (I18n) support for translating docs
YARD now ships with the beginnings of internationalization support
for translating documentation into multiple languages. The
`yard i18n` command now allows you to generate ".pot" and ultimately
".po" files for translation with [gettext](http://www.gnu.org/software/gettext).
Note that this tool is a small step in the larger transition for
proper I18n support in YARD. We still have to add proper gettext
support to our templates for proper generation in multiple languages,
but this tool allows you to get started in translating your
documents. Improved I18n support will come throughout the 0.8.x series.
## New C parser / handlers architecture (0.8.0)
The C parser was completely rewritten to take advantage of YARD's
parser and handler architecture. This means more YARD will be more robust
when parsing failures occur, tags and directives will now work consistently
across Ruby and CRuby files ({tag:!group} will now work, for instance),
and developers can now write custom handlers that target CRuby source files.
## YARD will now warn if `@param` name not in method params (0.8.0)
YARD will now give you a warning if you use a `@param` tag in your
source but give an invalid parameter name. This should catch a lot of
common documentation errors and help keep your documentation consistent.
## Added support for `module_function` calls in Ruby code (0.8.0)
The `module_function` command in Ruby is now supported in Ruby files.
It defines two separate methods, one class and one instance method,
both having the exact same docstring, and marks the instance method
as private.
## Greatly improved tag documentation using custom template (0.8.0)
We have completely revamped the {docs/Tags.md} to include documentation
for each meta-data tag and directive with at least one useful example
for each one. This was done using template customization and extension
available within YARD.
## Tags can now contain '.' for namespacing (0.8.0)
Prior to 0.8.0, tags could only contain alphanumeric characters and
underscore. YARD now allows the '.' character in tag names, and it
is now recommended for namespacing project-specific custom tags.
YARD has its own set of custom tags that are namespaced in this
way (using the "yard.tagname" namespace). The namespace recommendation
is to use "projectname.tagname", or "projectname.component.tagname".
## Added "frames" links for non-framed pages for better nav (0.8.0)
Frames navigation has always had a "(no frames)" link to get rid
of the frameset. YARD 0.8.0 introduces a "(frames)" link on non-framed
pages to reverse this, allowing you to navigate between framed and
frameless pages seamlessly.
## Added Gemfile support to YARD server for local gem sets (0.8.0)
The `yard server` command now supports `--gemfile` to serve gems
from a Gemfile.lock, instead of all system-wide gems.
## Server now displays README on index route like static docs (0.8.0)
The `yard server` command will now behave like static docs regarding
the index action for a project, listing the README file if present
before displaying the alphabetic index. Note that the route for
the alphabetic index page has now moved to the explicit '/index' action.
## Added line numbers to `yard stats --list-undoc --compact` (0.8.0)
Line numbers are now listed in the compact listing of undocumented objects
so that they can be more easily located in the files.
## Single object db now default (multi-object db unsupported) (0.8.0)
YARD previously would split the .yardoc db into multiple marshal files
for load-time performance reasons if it grew past a specific number of
objects. This check is now disabled, and YARD will never automatically
switch to a multi-object DB. YARD will now always use the single object
db unless explicitly set with `--no-single-db`. If YARD is taking a
long time to load your .yardoc database, you can try using this
option to split your database into multiple files, but note that this
can cause problems with certain codebases (specifically, if you
have class methods using the same name as a module/class).
## Added `--api` tag to generate documentation for API sets (0.8.1)
You can now use `yardoc --api APINAME` to generate documentation only
for objects with the `@api APINAME` tag (or any parent namespace objects,
since this tag is transitive). Multiple `--api` switches may be used to
generate documentation for multiple APIs together. The following generates
documentation for both the "public" and "developer" APIs, also including
any objects with undefined API (via `--no-api`):
$ yard doc --api public --api developer --no-api
Note that if you use `--api`, you must ensure that you also add `@api`
tags to your namespace objects (modules and classes), not just your methods.
If you do not want to do this, you can also include all objects with *no*
`@api` tag by using `--no-api` as shown above.
Remember that applying an `@api` tag to a class or module will apply it
to all children that do not have this tag already defined, so you can
declare an entire class public by applying it to the class itself. Note
also that these tags can be overridden by child elements if the tag is
re-applied to the individual object.
This feature is a simplified version of the more powerful `--query`
switch. The query to display the same API documentation as the
above example would be:
$ yard doc --query '!@api || @api.text =~ /^(public|private)$/'
But note that `--query` does not work when YARD is in "safe mode"
due to security concerns, whereas `--api` works in either mode.
This enables `--api` to function on remote documentation sites like
[rubydoc.info](http://rubydoc.info).
## Added `--non-transitive-tag` to disable transitive tag (0.8.3)
You can now use `--non-transitive-tag` to disable transitivity on
tags that are defined as transitive by default. For instance, in
some cases you might not want the @api tag to apply to all methods
when you define it on a class. Only the class itself has a specific
@api tag. To do this, you can mark @api as non-transitive with:
$ yard doc --non-transitive-tag api --api some_api
Which will avoid classifying treating @api as a transitive tag
when parsing modules and classes.
## Added `-B/--bind` to bind to a port in yard server (0.8.4)
You can now bind the `yard server` command to a given local port
with `yard server -B PORT` or `yard server --bind PORT`.
## Added `asciidoc` markup type support (0.8.6)
Support for the AsciiDoc markup type is now introduced using the `asciidoc`
markup type (`yard doc -m asciidoc`). Requires the
[asciidoctor](http://rubygems.org/gems/asciidoctor) RubyGem library to be
installed before running YARD.
## Added `yard markups` command to list available markup types (0.8.6)
You can now list all available markup types and their respective providers by
typing `yard markups`. This list also includes the file extensions used to
auto-identify markup types for extra files and READMEs. To use a markup in
the list, call `yard doc` with `-m MARKUP_TYPE`. To select a specific markup
provider library, pass the `-M PROVIDER_NAME` option.
## Added `yard display` command to display formatted objects (0.8.6)
This feature requires the .yardoc registry to have already been
generated. To generate the registry, run yard doc -n.
You can now display a single object (or a list of objects) in the YARD registry
using the `yard display OBJECT ...` command. For example, to display the
`YARD::CodeObjects` module as text (the way it is displayed in `yri`), type:
$ yard display YARD::CodeObjects
You can also format individual objects as HTML. For example, you can format
the above object as HTML and pipe the contents into a file readable by a
web browser:
$ yard display -f html YARD::CodeObjects > codeobjects.html
Custom templating options from `yard doc` can also be used, see
`yard display --help` for more options.
## Added `--layout` to `yard display` command (0.8.6.1)
The `yard display` command now accepts `--layout` to wrap content in a layout
template. Currently the `layout` and `onefile` layout templates are supported,
though any template can be used. If no parameter is specified, the layout will
default to the `layout` template. Example usage:
$ yard display --layout onefile -f html YARD::CodeObjects > codeobjects.html
The above generates a `codeobjects.html` file that is self-contained with
CSS stylesheets and JavaScript code. This is similar to calling
`yard doc --one-file` with only the YARD::CodeObjects object in the registry.
Note that even though this uses the onefile template, the README file will not
be auto-included the way it is with the `yard doc` command. To include the
README text at the top of the onefile template, pass the --readme switch:
$ yard display --layout onefile -f html --readme README.md OBJECT > out.html
# What's New in 0.7.x?
1. **Macro support and detection of DSL methods** (0.7.0)
2. **Inherited attributes now show in HTML output** (0.7.0)
3. **The 'app' directory is now parsed by default** (0.7.0)
4. **Added support for metadata (@title, @markup) in extra files/readmes** (0.7.0)
5. **Added `yard list` command (alias for `yardoc --list`)** (0.7.0)
6. **Added Git support in `yard diff`** (0.7.0)
7. **Added `{include:file:FILENAME}` syntax** (0.7.0)
8. **Added `{render:OBJECT}` syntax to embed object docs in extra files** (0.7.0)
9. **Added improved templates API for custom CSS/JS/menus** (0.7.0)
10. **Added Ruby markup type (`-m ruby`)** (0.7.0)
11. **Added state tracking variables to Parser/Handler architecture** (0.7.0)
12. **Added before/after callbacks to SourceParser** (0.7.0)
13. **Can now use `--yardopts FILE` to specify a custom yardopts file** (0.7.0)
14. **Added new `-t guide` template for guide based docs** (0.7.0)
15. **Github Flavoured Markdown now works out-of-box** (0.7.4)
16. **Added `-m textile_strict` and `-m pre` markup types** (0.7.4)
17. **Reorganized markup types 'text' and 'none'** (0.7.4)
18. **Add support for `rb_define_alias`** (0.7.4)
## Macro support and detection of DSL methods (0.7.0)
YARD will now automatically detect class level method calls, similar to the
way it knows what an `attr_accessor` is. By simply adding documentation to
your class level declarations, YARD can automatically detect them as methods
or attributes in your class. Consider DataMapper's "property" declaration:
class Post
# @attribute
# @return [String] the title of the post
property :title, String
end
The above declaration would be created as the `Post#title`. The optional
`@attribute` tag tells YARD that the property is an "attribute", and not just
a regular method.
In addition to basic DSL method detection, YARD also supports macros to create
docstrings that can be copies to other objects; these macros can also be
"attached" to class level methods to create implicit documentation for macros.
Macros and DSL method detection are discussed in much more detail in the
{file:docs/GettingStarted.md}, so you should read about them there if you're
interested in this feature.
## Inherited attributes now show in HTML output (0.7.0)
Inherited attributes will now show up in HTML documentation using the default
template in the same manner that inherited methods do.
## The 'app' directory is now parsed by default (0.7.0)
YARD tries to follow the "It Just Works" attitude in writing developer tools,
and therefore has added `app/**/*.rb` to the default list of globs that it
searches for code in. You no longer need to create a `.yardopts` just to
list your app directory when documenting your code on rubydoc.info.
We should have done this a while ago! And don't worry, YARD still checks
lib and ext by default, too.
## Added support for metadata (@title, @markup) in extra files/readmes (0.7.0)
Extra files (READMEs, ChangeLogs, LICENSE files, and other guides) now support
metadata tags, just like docstrings in code comments. By adding @tag values
to the top of a file (no whitespace preceding it) inside of a `# comment` line,
YARD will detect and parse these tags and store it for later usage.
Tags can contain arbitrary data as well as arbitrary tag names, however the
tag names @title and @markup are reserved to specify the document title and
markup format respectively. The title will be used in the file list menu,
index page, as well as any linking of the file via the `{file:Filename}`
syntax. An example of a document with metadata would be:
# @title The Best Project Ever!
# @markup rdoc
# @author Foo Bar (custom tag, does not display in templates)
= This Project Rules
== Contents
...
Note that previous versions of YARD recommended specifying the markup of an
extra file with the `#!markup` shebang, but the `@markup` metadata tag is now
the "best practice" for specifying the markup format of an extra file.
## Added `yard list` command (alias for `yardoc --list`) (0.7.0)
The `yardoc --list` command is used to list objects that are parsed from
a codebase. This can be used to grep methods/classes in a codebase from the
command line. `yard list` now calls `yardoc --list` as a convenience command.
Note that the `yardoc --list` command may eventually be replaced by a more
feature-filled `yard list` command, so `yard list` should be used instead of
`yardoc --list` when possible.
## Added Git support in `yard diff` (0.7.0)
The `yard diff` command can now perform object diffing on git repositories.
Provide the `--git` switch to `yard diff` with 2 commit/branches like so:
$ yard diff --git HEAD~5 HEAD
Added objects:
YARD::Parser::SourceParser#contents
YARD::Parser::SourceParser#globals
...
## Added `{include:file:FILENAME}` syntax (0.7.0)
You can now use the `{include:file:FILENAME}` syntax to embed the contents
of an extra file marked up in its markup format. This syntax supports embedding
Ruby source files and performing syntax highlighting on the code.
## Added `{render:OBJECT}` syntax to embed object docs in extra files (0.7.0)
You can now use the `{render:Object}` syntax to embed the documentation
rendering of an entire object (method, class, module) inside of an extra file.
This is useful when writing non-API based guides that might require listing
a few helper methods or classes. The {file:docs/GettingStarted.md} discussed
this syntax in more detail (with example usage).
## Added improved templates API for custom CSS/JS/menus (0.7.0)
Plugin & template developers can now more easily insert custom stylesheet
or JavaScript files in their customized templates, thanks to an abstraction
of the template API. This is documented in the {docs/Templates.md} document.
In addition to custom CSS/JS, developers can also create custom menu tabs
in both the framed and non framed version of the default theme.
## Added Ruby markup type (`-m ruby`) (0.7.0)
The Ruby markup type (`-m ruby`) will now use syntax highlighting for all
formatting. This is probably not useful as a global switch, but can be used
on individual extra files using the metadata markup specification discussed
above.
## Added state tracking variables to Parser/Handler architecture (0.7.0)
The parser and handler architecture now contain state variables
{YARD::Handlers::Base#extra_state} and {YARD::Handlers::Processor#globals}
to share data across handlers and the entire processing phase. `#extra_state`
provided a place to store per-file data, while `#globals` gives the developer
access to inter-file state when parsing multiple files at once.
## Added before/after callbacks to SourceParser (0.7.0)
The {YARD::Parser::SourceParser} class can now register callbacks to execute
code before and after parsing of file globs, as well as before and after
parsing of individual files. This allows plugin developers to perform
setup/teardown (and set global state or update the {YARD::Registry}).
See the documentation for the following methods:
* {YARD::Parser::SourceParser.before_parse_list}
* {YARD::Parser::SourceParser.after_parse_list}
* {YARD::Parser::SourceParser.before_parse_file}
* {YARD::Parser::SourceParser.after_parse_file}
## Can now use `--yardopts FILE` to specify a custom yardopts file (0.7.0)
The `yardoc` command now supports `--yardopts FILE` to specify custom .yardopts
options files. This is useful if you have multiple documentation sets, such
as a guide documentation set and an API documentation set.
## Added new `-t guide` template for guide based docs (0.7.0)
You can now write guide style documentation using a new 'guide' template that
only generates documentation for extra files. You would use it in the form:
yardoc -t guide - README GettingStarted FAQ TroubleShooting LICENSE
This creates the sections for the readme, a getting started, frequently asked
questions, trouble shooting and license page.
If you need to refer to class / method documentation, you can embed API documentation
using the `{render:Object}` tag discussed above.
## Github Flavoured Markdown now works out-of-box (0.7.4)
Due to the growing popularity of Github-Flavoured-Markdown (GFM), YARD now uses
the Redcarpet library as the default Markdown formatting library with GFM fenced
code blocks enabled. This means that you can use fenced code blocks inside of
Markdown files with redcarpet installed without any extra code. Previously, users
who wanted GFM in their Markdown would have to specify `-m markdown -M redcarpet`,
but this is now the default behaviour for YARD.
Note that you can still specify language types in code blocks without GFM in YARD
by using the "!!!lang" prefix syntax. For example (plain means no markup):
!!!plain
!!!plain
Some code
block here.
The GFM version would be:
!!!plain
```plain
Some code
block here.
```
## Added `-m textile_strict` and `-m pre` markup types (0.7.4)
A new "textile_strict" markup type was added which behaves exactly like "textile"
except it enables hard breaks, so newlines behave as line breaks in the HTML
(using `
` tags). This option is added for users who want the classic textile
behaviour.
## Reorganized markup types 'text' and 'none' (0.7.4)
Due to the new pre markup type, the behaviour for text and none were slightly
reorganized to be more intuitive. The following behaviours now represent these
markup types:
* pre: Used to wrap text inside `` tags
* text: No formatting except for hard breaks (`
`) on newlines
* none: No formatting at all.
In all cases, HTML is escaped from input. If you want no HTML escaping, use the
html markup type.
## Add support for `rb_define_alias` (0.7.4)
CRuby code can now make use of the `rb_define_alias` function. Documentation
for aliases is not supported, however.
# What's New in 0.6.x?
1. **Local documentation server for RubyGems or projects (`yard server`)** (0.6.0)
2. **Groups support for method listing** (0.6.0)
3. **Single file template (`--one-file`) support** (0.6.0)
4. **`yard` CLI executable with pluggable commands** (0.6.0)
5. **`yard diff` command to object-diff two versions of a project** (0.6.0)
6. **Added `--asset` option to `yardoc`** (0.6.0)
7. **New template API** (0.6.0)
8. **HTML template now adds inline Table of Contents for extra files pages** (0.6.0)
9. **Removed `--incremental` in favour of `--use-cache`** (0.6.0)
10. **Ad-hoc tag registration via `yardoc` CLI (`--tag`, etc.)** (0.6.0)
11. **Added `--transitive-tags` to register transitive tags** (0.6.0)
12. **`yardoc` now displays RDoc-like statistics (`--no-stats` to hide)** (0.6.0)
13. **`yri` now works on constants** (0.6.0)
14. **Plugins are no longer auto-loaded (added `--plugin` switch)** (0.6.2)
15. **Added `YARD::Config` API and `~/.yard/config` configuration file** (0.6.2)
16. **Added `yard config` command to view/edit configuration** (0.6.2)
17. **Added `yard server -t` template path switch** (0.6.2)
18. **Added `YARD::Server.register_static_path` for static server assets** (0.6.2)
19. **YARD::Registry is now thread local** (0.6.5)
20. **Support for ripper gem in Ruby 1.8.7** (0.6.5)
## Local documentation server for RubyGems or projects (`yard server`) (0.6.0)
The new `yard server` command spawns a documentation server that can serve
either documentation for a local project or installed RubyGems. The server
will host (by default) on http://localhost:8808.
To serve documentation for the active project (in the current directory):
$ yard server
The server can also run in "incremental" mode for local projects. In this
situation, any modified sources will immediately be updated at each request,
ensuring that the server always serve the code exactly as it is on disk.
Documenting your code in this fashion essentially gives you an efficient a
live preview without running a separate command everytime you make a change.
To serve documentation for the active project in incremental mode:
$ yard server --reload
Note that in incremental mode, objects or method groupings
cannot be removed. If you have removed objects or modified groupings, you
will need to flush the cache by deleting `.yardoc` and (optionally)
restarting the server.
The documentation server can also serve documentation for all installed gems
on your system, similar to `gem server`, but using YARD's functionality and
templates. To serve documentation for installed gems:
$ yard server --gems
Documentation for the gem need not be previously generated
at install-time. If documentation for the gem has not been generated, YARD
will do this for you on-the-fly. It is therefore possible to speed up your
gem installs by using `gem install GEMNAME --no-rdoc` without repercussion.
You can also add this switch to your `~/.gemrc` file so that you don't need
to re-type it each time. See [this link](http://stackoverflow.com/questions/1789376/how-do-i-make-no-ri-no-rdoc-the-default-for-gem-install)
for exact instructions.
## Groups support for method listing (0.6.0)
You can now organize methods in a class/module into logical separated groups.
These groups apply lexically and are listed in the order they are defined.
For instance, to define a group:
# @group Rendering an Object
# Documentation here
def foo; end
# Extra documentation...
def bar; end
# @group Another Group
def aaa; end
Note that these `@group` and `@endgroup` declarations are
not "tags" and should always be separated with at least 1 line of whitespace
from any other documentation or code.
In the above example, "Rendering an Object" will be listed with "foo" and
"bar" above "Another Group", even though "aaa" comes before the two other
methods, alphabetically. To end a group, use `@endgroup`. It is not necessary
to end a group to start a new one, only if there is an object following the
group that should not belong in any group.
# @group Group 1
def foo; end
# @endgroup
# This method should not be listed in any group
def bar; end
## Single file template (`--one-file`) support (0.6.0)
`yardoc` now has the `--one-file` option to generate a single-file template
for small scripts and libraries. In this case, any comments at the top of
the script file will be recognized as a README.
## `yard` CLI executable with pluggable commands (0.6.0)
The `yardoc` and `yri` commands are not deprecated and can
continue to be used. They are shortcuts for `yard doc` and `yard ri`
respectively. However, `yard-graph` has been removed.
YARD now has a `yard` executable which combines all pre-existing and new
commands into a single pluggable command that is both easier to remember and
access. To get a list of commands, type `yard --help`.
If you are a plugin developer, you can create your own `yard` command by first
subclassing the {YARD::CLI::Command} class and then registering this class
with the {YARD::CLI::CommandParser.commands} list. For instance:
YARD::CLI::CommandParser.commands[:my_command] = MyCommandClass
The above line will enable the user to execute `yard my_command [options]`.
## `yard diff` command to object-diff two versions of a project (0.6.0)
One of the built-in commands that comes with the new `yard` executable is the
ability to do object-oriented diffing across multiple versions of the same
project, either by 2 versions of a gem, or 2 working copies. Just like
regular diffing tells you which lines have been added/removed in a file,
object diffing allows you to see what classes/methods/modules have been
added/removed between versions of a codebase.
For an overview of how to use `yard diff`, see [YARD Object Oriented Diffing](http://gnuu.org/2010/06/26/yard-object-oriented-diffing/).
## `yard stats` to display statistics and undocumented objects (0.6.0)
YARD now outputs the following statistics when `yard stats` is run:
Files: 125
Modules: 35 ( 4 undocumented)
Classes: 139 ( 29 undocumented)
Constants: 53 ( 20 undocumented)
Methods: 602 ( 70 undocumented)
85.16% documented
Note that these statistics are based on what you have set to show in your
documentation. If you use `@private` tags and/or do not display
private/protected methods in your documentation, these will not show up as
undocumented. Therefore this metric is contextual.
You can also specifically list all undocumented objects (and their file
locations) with the `--list-undoc` option.
## Added `--asset` option to `yardoc` (0.6.0)
The `yardoc` command can now take the `--asset` option to copy over
files/directories (recursively) to the output path after generating
documentation. The format of the argument is "from:to" where from is the
source path and to is the destination. For instance, YARD uses the following
syntax in the `.yardopts` file to copy over image assets from the
'docs/images' directory into the 'images' directory after generating HTML:
--asset docs/images:images
## New template API (0.6.0)
The new template API allows for easier insertion of sections within an
inherited template. You should no longer need to insert by index, an
error-prone process that could break when a template is updated. Instead of:
sections.last.place(:my_section).before(:another_section)
use:
sections.place(:my_section).before_any(:another_section)
You can see more in the {file:docs/Templates.md#Inserting_and_Traversing_Sections}
document.
## HTML template now adds inline Table of Contents for extra files pages (0.6.0)
A table of contents is now generated dynamically using JavaScript for extra
file pages (such as README's, or this document). It is generated based off the
headers (h1,h2,... tags) used in the document, and can be floated to the
right or listed inline on the page.
## Ad-hoc tag registration via `yardoc` CLI (`--tag`, etc.) (0.6.0)
Simple meta-data tags can now be added at the command-line and registered to
display in templates in a number of pre-defined ways. For instance, to create
a freeform text tag, use the following:
--tag my_tag_name:"My Tag Title"
You can also create a "typed" tag (similar to `@return`), a typed named tag
(similar to `@param`) as well as various combinations. The full list of
options are listed in `yardoc --help` under the "Tag Options" section.
If you wish to create a tag to store data but do not wish to show this data
in the templates, use the `--hide-tag` option to hide it from generated output:
--hide-tag my_tag_name
## Added `--transitive-tags` to register transitive tags (0.6.0)
Transitive tags are tags that apply to all descendants of a namespace (class
or module) when documented on that namespace. For instance, the `@since` tag
is a transitive tag. Applying `@since` to a class will automatically apply
`@since` to all methods in the class. Creating a `@since` tag directly on a
method will override the inherited value.
You can specify transitive tags on the command-line by using this option. Note
that the tags must already exist (built-in or created with the `--tag` option)
to be specified as transitive. If you wish to do this programmatically, see
the {YARD::Tags::Library.transitive_tags} attribute.
## `yardoc` now displays RDoc-like statistics (`--no-stats` to hide) (0.6.0)
As seen in the `yard stats` feature overview, `yardoc` displays RDoc-like
statistics when it is run. The output is equivalent to typing `yard stats`.
To hide this output when yardoc is run, use `--no-stats`.
## `yri` now works on constants (0.6.0)
Templates have now been added for text view of constants, which displays any
documentation and the constant value.
## Plugins are no longer auto-loaded (added `--plugin` switch) (0.6.2)
This is a backwards-incompatible change that disables plugins from automatically
loading when YARD starts up. From now on, you should manually declare which
plugins your project is using by adding `--plugin PLUGINNAME` to a `.yardopts`
file in the root of your project. You can also re-enable autoloaded plugins
by setting `load_plugins` to true in your configuration file (`yard config load_plugins true`,
see next item). You can also set `autoload_plugins` to a list of plugins
to be automatically loaded on start.
If you are a YARD plugin author, please make sure to inform your users of these
changes.
Note that `--plugin` switches passed on the commandline (not via `.yardopts`)
are parsed before commands are loaded, and therefore can add in new CLI commands.
## Added `YARD::Config` API and `~/.yard/config` configuration file (0.6.2)
There is a new global configuration API that can be accessed programmatically
and set via the `~/.yard/config` file. The file is encoded as a YAML file,
and looks like:
:load_plugins: false
:ignored_plugins:
- my_plugin
- my_other_plugin
:autoload_plugins:
- my_autoload_plugin
:safe_mode: false
You can also set configuration options via the command-line (see next item).
## Added `yard config` command to view/edit configuration (0.6.2)
A new `yard config` command was created to view or edit the configuration
file via the commandline.
* To view the current configuration use `yard config --list`.
* To view a specific item use `yard config ITEMNAME`
* To modify an item value use `yard config ITEMNAME VALUE`
## Added `yard server -t` template path switch (0.6.2)
The `yard server` command now accepts `-t` or `--template-path` to register
a new template path for template customization.
## Added `YARD::Server.register_static_path` for static server assets (0.6.2)
The server now supports a command to register static asset paths. If you are
extending the YARD::Server modules, make sure to register your asset paths
through this method.
## YARD::Registry is now thread local (0.6.5)
Creating a new thread will now implicitly load a new Registry that can be used
to parse and process new code objects independently of the other threads. Note
that this means you can no longer use the Registry across threads; you must
either access the threadlocal object directly, or synchronize threads to do
the processing in the initial registry's thread.
## Support for ripper gem in Ruby 1.8.7 (0.6.5)
YARD now supports the Ruby 1.8.7 port of the `ripper` gem to improve parsing
of source, both in terms of performance and functionality. When the `ripper`
gem is available, YARD will use the "new-style" handlers. You can take advantage
of this functionality by performing a `gem install ripper`.
What's New in 0.5.x?
====================
1. **Support for documenting native Ruby C code** (0.5.0)
2. **Incremental parsing and output generation with `yardoc -c`** (0.5.0, 0.5.3)
2. **Improved `yri` support to perform lookups on installed Gems** (0.5.0)
3. **Added `yardoc --default-return` and `yardoc --hide-void-return`** (0.5.0)
4. **Multiple syntax highlighting language support** (0.5.0)
5. **New .yardoc format** (0.5.0)
6. **Support for yard-doc-* gem packages as hosted .yardoc dbs** (0.5.1)
7. **Support for extra search paths in `yri`** (0.5.1)
8. **Generating HTML docs now adds frames view** (0.5.3)
9. **Tree view for class list** (0.5.3)
10. **Ability to specify markup format of extra files** (0.5.3)
11. **Keyboard shortcuts for default HTML template** (0.5.4)
Support for documenting native Ruby C code (0.5.0)
--------------------------------------------------
It is now possible to document native Ruby extensions with YARD with a new
C parser mostly borrowed from RDoc. This enables the ability to document
Ruby's core and stdlibs which will be hosted on http://yardoc.org/docs. In
addition, the .yardoc dump for the Ruby-core classes will become available
as an installable gem for yri support (see #3).
Incremental parsing and output generation with `yardoc -c` (0.5.0, 0.5.3)
-------------------------------------------------------------------------
Note: in 0.5.3 and above you must use --incremental
to incrementally generate HTML, otherwise only parsing will be done
incrementally but HTML will be generated with all objects. --incremental
implies -c, so no need to specify them both.
YARD now compares file checksums before parsing when using `yardoc -c`
(aka `yardoc --use-cache`) to do incremental parsing of only the files that
have changed. HTML (or other output format) generation will also only be
done on the objects that were parsed from changed files (\*). This makes doing
a documentation development cycle much faster for quick HTML previews. Just
remember that when using incremental output generation, the index will not
be rebuilt and inter-file links might not hook up right, so it is best to
perform a full rebuild at the end of such previews.
(\*) Only for versions prior to 0.5.3. For 0.5.3+, use `--incremental` for
incremental HTML output.
Improved `yri` support to perform lookups on installed Gems (0.5.0)
-------------------------------------------------------------------
The `yri` executable can now perform lookups on gems that have been parsed
by yard. Therefore, to use this command you must first parse all gems with
YARD. To parse all gems, use the following command:
$ sudo yardoc --build-gems
The above command builds a .yardoc file for all installed gems in the
respective gem directory. If you do not have write access to the gem path,
YARD will write the yardoc file to `~/.yard/gem_index/NAME-VERSION.yardoc`.
Note: you can also use `--re-build-gems` to force re-parsing of all gems.
You can now do lookups with yri:
$ yri JSON
All lookups are cached to `~/.yard/yri_cache` for quicker lookups the second
time onward.
Added `yardoc --default-return` and `yardoc --hide-void-return` (0.5.0)
-----------------------------------------------------------------------
YARD defaults to displaying (Object) as the default return type of any
method that has not declared a @return tag. To customize the default
return type, you can specify:
$ yardoc --default-return 'MyDefaultType'
You can also use the empty string to list no return type.
In addition, you can use --hide-void-return to ignore any method that
defines itself as a void type by: `@return [void]`
Multiple syntax highlighting language support (0.5.0)
-----------------------------------------------------
YARD now supports the ability to specify a language type for code blocks in
docstrings. Although no actual highlighting support is added for any language
but Ruby, you can add your own support by writing your own helper method:
# Where LANGNAME is the language:
def html_syntax_highlight_LANGNAME(source)
# return highlighted HTML
end
To use this language in code blocks, prefix the block with `!!!LANGNAME`:
!!!plain
!!!python
def python_code(self):
return self
By the same token. you can now use `!!!plain` to ignore highlighting for
a specific code block.
New .yardoc format (0.5.0)
--------------------------
To make the above yri support possible, the .yardoc format was redesigned
to be a directory instead of a file. YARD can still load old .yardoc files,
but they will be automatically upgraded if re-saved. The new .yardoc format
does have a larger memory footprint, but this will hopefully be optimized
downward.
Support for yard-doc-* gem packages as hosted .yardoc dbs (0.5.1)
-----------------------------------------------------------------
You can now install special YARD plugin gems titled yard-doc-NAME to get
packaged a .yardoc database. This will enable yri lookups or building docs
for the gem without the code.
One main use for this is the `yard-doc-core` package, which enabled yri
support for Ruby core classes (stdlib coming soon as `yard-doc-stdlib`).
To install it, simply:
$ sudo gem install yard-doc-core
# now you can use:
$ yri String
This will by default install the 1.9.1 core library. To install a library
for a specific version of Ruby, use the `--version` switch on gem:
$ sudo gem install --version '= 1.8.6' yard-doc-core
Support for extra search paths in `yri` (0.5.1)
-----------------------------------------------
You can now add custom paths to non-gem .yardoc files
by adding them as newline separated paths in `~/.yard/yri_search_paths`.
Generating HTML docs now adds frames view (0.5.3)
-------------------------------------------------
`yardoc` will now create a `frames.html` file when generating HTML documents
which allows the user to view documentation inside frames, for those users who
still find frames beneficial.
Tree view for class list (0.5.3)
--------------------------------
The class list now displays as an expandable tree view to better organized an
otherwise cluttered namespace. If you properly namespace your less important
classes (like Rails timezone classes), they will not take up space in the
class list unless the user looks for them.
Ability to specify markup format of extra files (0.5.3)
-------------------------------------------------------
You can now specify the markup format of an extra file (like README) at the
top of the file with a shebang-like line:
#!textile
contents here
The above file contents will be rendered with a textile markup engine
(eg. RedCloth).
Keyboard shortcuts for default HTML template (0.5.4)
----------------------------------------------------
You can now access the "Class List", "Method List" and "File List" with the
'c', 'm' and 'f' keyboard shortcuts in the default HTML template, allowing
for keyboard-only navigation around YARD documentation.
API for registering custom parsers (0.5.6)
------------------------------------------
You can now register parsers for custom source languages by calling the
following method:
SourceParser.register_parser_type(:java, MyJavaParser, 'java')
The parser class MyJavaParser should be a subclass of {YARD::Parser::Base},
and the last argument is a set of extensions (string, array or regexp). You
can read more about registering parsers at the {YARD::Parser::SourceParser}
class documentation.
What's New in 0.4.x?
====================
1. **New templating engine and templates**
2. **yardoc `--query` argument**
3. **Greatly expanded API documentation**
4. **New plugin support**
5. **New tags (@abstract, @private)**
6. **Default rake task is now `rake yard`**
New templating engine and templates
-----------------------------------
The templates were redesigned, most notably removing the ugly frameset, adding
search to the class/method lists, simplifying the layout and making things
generally prettier. You should also notice that more tags are now visible in
the templates such as @todo, the new @abstract and @note tags and some others
that existed but were previously omitted from the generated documentation.
There is also a new templating engine (based on the tadpole templating library)
to allow for much more user customization. You can read about it in
{file:docs/Templates.md}.
yardoc `--query` argument
-------------------------
The yardoc command-line tool now supports queries to select which classes,
modules or methods to include in documentation based on their data or meta-data.
For instance, you can now generate documentation for your "public" API only by
adding "@api public" to each of your public API methods/classes and using
the following argument:
--query '@api.text == "public"'
More information on queries is in the {file:README.md}.
Greatly expanded API documentation
----------------------------------
Last release focused on many how-to and architecture documents to explain
the design of YARD, but many of the actual API classes/methods were still
left undocumented. This release marks a focus on getting YARD's own documentation
up to par so that it can serve as an official reference on the recommended
conventions to use when documenting code.
New plugin support
------------------
YARD now supports loading of plugins via RubyGems. Any gem named `yard-*` or
`yard_*` will now be loaded when YARD starts up. Note that the '-' separator
is the recommended naming scheme.
To ignore plugins, add the gem names to `~/.yard/ignored_plugins` on separate
lines (or separated by whitespace).
New tags (@abstract, @private)
------------------------------
Two new tags were added to the list of builtin meta-tags in YARD. `@abstract`
marks a class/module/method as abstract while `@private` marks an object
as "private". The latter tag is used in situations where an object is public
due to Ruby's own visibility limitations (constants, classes and modules
can never be private) but not actually part of your public API. You should
use this tag sparingly, as it is not meant to be an equivalent to RDoc's
`:nodoc:` tag. Remember, YARD recommends documenting private objects too.
This tag exists so that you can create a query (`--query !@private`) to
ignore all of these private objects in your documentation. You can also
use the new `--no-private` switch, which is a shortcut to the aforementioned
query. You can read more about the new tags in the {file:docs/GettingStarted.md}
guide.
Default rake task is now `rake yard`
------------------------------------
Not a big change, but anyone using the default "rake yardoc" task should
update their scripts:
[http://github.com/lsegal/yard/commit/ad38a68dd73898b06bd5d0a1912b7d815878fae0](http://github.com/lsegal/yard/commit/ad38a68dd73898b06bd5d0a1912b7d815878fae0)
What's New in 0.2.3.x?
======================
1. **Full Ruby 1.9 support**
2. **New parser code and handler API for 1.9**
3. **A new `@overload` tag**
4. **Better documentation**
5. **Template changes and bug fixes**
Full Ruby 1.9 support
---------------------
YARD's development actually focuses primarily on 1.9 from the get-go, so it is
not an afterthought. All features are first implemented for compatibility with
1.9, but of course all functionality is also tested in 1.8.x. YARD 0.2.2 was
mostly compatible with 1.9, but the new release improves and extends in certain
areas where compatibility was lacking. The new release should be fully functional
in Ruby 1.9.
New parser code and handler API for 1.9
---------------------------------------
Using Ruby 1.9 also gives YARD the advantage of using the new `ripper` library
which was added to stdlib. The ripper parser is Ruby's official answer to
projects like ParseTree and ruby2ruby. Ripper allows access to the AST as it
is parsed by the Ruby compiler. This has some large benefits over alternative
projects:
1. It is officially supported and maintained by the Ruby core team.
2. The AST is generated directly from the exact same code that drives the
compiler, meaning anything that compiles is guaranteed to generate the
equivalent AST.
3. It needs no hacks, gems or extra libs and works out of the box in 1.9.
4. It's *fast*.
Having the AST means that developers looking to extend YARD have much better
access to the parsed code than in previous versions. The only caveat is that
this library is not back-compatible to 1.8.x. Because of this, there are
subtle changes to the handler extension API that developers use to extend YARD.
Namely, there is now a standard API for 1.9 and a "legacy" API that can run in
both 1.8.x and 1.9 if needed. A developer can still use the legacy API to write
handlers that are compatible for both 1.8.x and 1.9 in one shot, or decide to
implement the handler using both APIs. Realize that the benefit of using the new
API means 1.9 users will get a 2.5x parsing speed increase over running the legacy
handlers (this is *in addition to* the ~1.8x speed increase of using YARV over MRI).
A new `@overload` tag
---------------------
The new `@overload` tag enables users to document methods that take multiple
parameters depending on context. This is basically equivalent to RDoc's call-seq,
but with a name that is more akin to the OOP concept of method overloading
that is actually being employed. Here's an example:
# @overload def to_html(html, autolink = true)
# This docstring describes the specific overload only.
# @param [String] html the HTML
# @param [Boolean] autolink whether or not to atuomatically link
# URL references
# @overload def to_html(html, opts = {})
# @param [String] html the HTML
# @param [Hash] opts any attributes to add to the root HTML node
def to_html(*args)
# split args depending on context
end
As you can see each overload takes its own nested tags (including a docstring)
as if it were its own method. This allows "virtual" overloading behaviour at
the API level to make Ruby look like overload-aware languages without caring
about the implementation details required to add the behaviour.
It is still recommended practice, however, to stay away from overloading when
possible and document the types of each method's real parameters. This allows
toolkits making use of YARD to get accurate type information for your methods,
for instance, allowing IDE autocompletion. There are, of course, situations
where overload just makes more sense.
Better documentation
--------------------
The first few iterations of YARD were very much a proof of concept. Few people
were paying attention and it was really just pieced together to see what was
feasible. Now that YARD is gaining interest, there are many developers that
want to take advantage of its extensibility support to do some really cool stuff.
Considerable time was spent for this release documenting, at a high level, what
YARD can do and how it can be done. Expect this documentation to be extended and
improved in future releases.
Template changes and bug fixes
------------------------------
Of course no new release would be complete without fixing the old broken code.
Some tags existed but were not present in generated documentation. The templates
were mostly fixed to add the major omitted tags. In addition to template adjustments,
many parsing bugs were ironed out to make YARD much more stable with existing projects
(Rails, HAML, Sinatra, Ramaze, etc.).
yard-master/docs/images/ 0000775 0000000 0000000 00000000000 12656766440 0015523 5 ustar 00root root 0000000 0000000 yard-master/docs/images/code-objects-class-diagram.png 0000664 0000000 0000000 00000173120 12656766440 0023303 0 ustar 00root root 0000000 0000000 ‰PNG
IHDR ¼ Œ O{ öIDATxÚìÝuXTÙðK¬n¸nÙµv v®]kÇÚÝJIcwïê®H¨ˆ¢ˆ"
*¨ "ÝÝÍ0]÷ûûƒt¸‹+1èû}ž}<3Ì\fï|¼¾÷ÜsÏa@¡4Ð0´(„—B!¼
á¥^
…ðR(„—B!¼”O/?À—BQøð«ÀðU‡ÎŠ‚§ÃWUàõi“TH¡(x’ÚøT…·=‡ª(Š¢‡Ó¾j¼…´k(ŠžBÂK!¼Ÿw¤²w³òwʤ £ýDx.;uµµl…•ž‰\¯VPþ ù¨žîvOˆNö½ H–ñ·
ùlÂ[/¹;9²Ëí"*?çËä–5ã'ÙÊ4Áèr ~ÀûÛ\•¥´ o=$è- 8øÝó€ü‡..ª¹@âƒÇ…ëj À•áEè~Ú×.ìKWþÐ!@Žã}?iöF7ý€üÇ÷ßHhÞ:ŒûOY •³‡–ßYqEÆ”½5åâõ¬k'æ¤ÛÛ@ê>PÿÕþÜHö*73-/L@ØŒó6³ÎgíktÍù¿î°þœö'áÃ<þº´Ú
ì‚°NþØ9–Å&O2Ú˜a"jä ¼ÆÏÑ]0þ
‰L,¦LV`® àn…—_É€pæüÞÒþ$¼u˜?”î-›ær°nbÂjÀ[9¿à›…úúãteÍœ ç[wt;Üj…&VÞ|¦¾þ¬åìOwÈñô+. ØÐkÆ5!íOÂ[‡IUs §üû-¤µºƒ)+ Oåü¢o\$bAlþ^ xÒ;ÝÎ ÖíKðÞ–ˆE²Ö6 Dxú ‚t[ÁÒ%¼u˜Sóòã
z=Åó^Ñ87€‹ß•Xl¸
ß‘~@ö¬ó€ÚbK5ÍÄBc5pùô—V'ñüK‘
t8ÕŽúÌoæ†ÑVCPÀa‰É’ ßxÉaÃF»rRÖèï. <
·lÕ·øbËE®_”…h&Ùšš&›3‘g c¬›‚ÔQËŽ²©ŒLØÓÞ$¼u›Ü¸1 äÅæ ›˜,JO’@Ÿ A|\> OKfÆ yâ8&&ÄÈ’âø 8q"€›Pòv
áUÔÃô•k}ri7Þ†˜ˆÍºoh/^
á%¼ÂK¡^
…ðR/…Bx)ÂK¡^
á¥P¯ÂDâfwO1bçXD_áý
ï6|˜"dxߟh0áý°]Ó÷:·XÂ
éâC_áý ]ÓßAA>Išº7}„÷Ãð>PO’Ü›ð^ÂKx /á%¼Ÿ^·ï½u2Ýôäùóg= /áUP¼©“†½ïGÜÇÌÝ [µ[„—ð*^–ðn, ^1 @Æ ·¸d–Þ¥(`öo ¸%?—p„ PÌ#¼„·^ñÆéêjh&`ÍXH÷®[£™ ¼]¦½öŠw-×[Ÿ ‰JñàÝ áU€çbíÕfÈÛ¬½þ/á%¼õ‡—3ñ¤«`ÍXpwK0]˜6YÚxÒ(B ‘Ye0}Vòö cvC6#ÖÕÜ
vŒá%¼õ‡÷í×É@^!ÖŒ’l'üìivÀGŒ –Kd¢äÈë]¹s1±·®lêp,@VüÓöë7†Í"¼„·þðúªæ ÖŒEÄУÏf
༬ëoéˆÛ7Hýa Þ çßÐÁçŸÈïÎïº"æ«ÓÏŸ»…^Â[x“Ú½bÝ8ÜúÐ
8³ÿòn\4dKG @šR4ðM¨E{`Ñ4À ðU~0ìàáDx oýáeOÎ{yw^lÜØ®QAÝþ|Ý«cïs·ýdêËç¿ý È–¹öúå²U¯.–/Ûõ‹ÅŒ³îç†'?ÿÀi‘á%¼õØÛ o‹kð¼dúoM훾@Ú]ókñ¸Zš»@Æ3K‹gbÀ÷¢£ƒ©o™_O‚-¯&€ðÞúÄ[ë!¼„—ð^ÂKx ¯ÂãU”Áè©„—ð~(^ëü