Skip to content
Snippets Groups Projects
Commit 12e92f12 authored by Garen Torikian's avatar Garen Torikian
Browse files

Add samples of prose content

parent 50f3b2e3
No related branches found
No related tags found
No related merge requests found
Gregory Romé has written an AsciiDoc plugin for the Redmine project management application.
https://github.com/foo-users/foo
へと `vicmd` キーマップを足してみている試み、
アニメーションgifです。
tag::romé[]
Gregory Romé has written an AsciiDoc plugin for the Redmine project management application.
end::romé[]
== Überschrift
* Codierungen sind verrückt auf älteren Versionen von Ruby
\ No newline at end of file
AsciiDoc Home Page
==================
Example Articles
~~~~~~~~~~~~~~~~
- Item 1
- Item 2
- Item 3
Document Title
==============
Doc Writer <thedoc@asciidoctor.org>
:idprefix: id_
Preamble paragraph.
NOTE: This is test, only a test.
== Section A
*Section A* paragraph.
=== Section A Subsection
*Section A* 'subsection' paragraph.
== Section B
*Section B* paragraph.
.Section B list
* Item 1
* Item 2
* Item 3
= Creole
Creole is a Creole-to-HTML converter for Creole, the lightweight markup
language (http://wikicreole.org/). Github uses this converter to render *.creole files.
Project page on github:
* http://github.com/minad/creole
Travis-CI:
* https://travis-ci.org/minad/creole
RDOC:
* http://rdoc.info/projects/minad/creole
== INSTALLATION
{{{
gem install creole
}}}
== SYNOPSIS
{{{
require 'creole'
html = Creole.creolize('== Creole text')
}}}
== BUGS
If you found a bug, please report it at the Creole project's tracker
on GitHub:
http://github.com/minad/creole/issues
== AUTHORS
* Lars Christensen (larsch)
* Daniel Mendler (minad)
== LICENSE
Creole is Copyright (c) 2008 - 2013 Lars Christensen, Daniel Mendler. It is free software, and
may be redistributed under the terms specified in the README file of
the Ruby distribution.
= Overview =
The GDB Tracepoint Analysis feature is an extension to the Tracing and Monitoring Framework that allows the visualization and analysis of C/C++ tracepoint data collected by GDB and stored to a log file.
= Getting Started =
The feature can be installed from the Eclipse update site by selecting '''Linux Tools''' > '''GDB Tracepoint Analysis'''.
The feature requires GDB version 7.2 or later to be installed on the local host. The executable program 'gdb' must be found in the path.
= GDB Trace Perspective =
To open the perspective, select '''Window''' > '''Open Perspective''' > '''Other...''' > '''GDB Trace'''.
The perspective includes the following views by default:
* '''Project Explorer''': This view shows the projects in the workspace and is used to create and manage Tracing projects.
* '''Debug''': This view shows the running C/C++ Postmortem Debugger instances and displays the thread and stack trace associated with a tracepoint.
* '''Trace Control''': This view shows the status of the debugger and allows navigation of trace records.
* '''Console''': This view displays console output of the C/C++ Postmortem Debugger.
The editor area contains the '''Events''' and '''C/C++''' editors when a GDB Trace is opened.
[[Image:images/GDBTracePerspective.png]]
= Collecting Tracepoint Data =
Collecting the C/C++ tracepoint data is outside the scope of this feature. It can be done from the GDB command line or by using the CDT debug component within Eclipse. See the CDT FAQ entry in the [[#References | References]] section.
= Importing Tracepoint Data =
Some information in this section is redundant with the LTTng User Guide. For further details, see the LTTng User Guide entry in the [[#References | References]] section.
== Creating a Tracing Project ==
In the '''Project Explorer''' view, right-click and select '''New''' > '''Project...''' from the context menu. In the '''New Project''' dialog, select '''Tracing''' > '''Tracing Project''', click '''Next''', name your project and click '''Finish'''.
== Importing a GDB Trace ==
In your tracing project, right-click on the '''Traces''' folder and select '''Import...'''. Browse to, or enter, a source directory. Select the trace file in the tree. Optionally set the trace type to '''GDB : GDB Trace'''. Click '''Finish'''.
Alternatively, the trace can be drag & dropped to the '''Traces''' folder from any external file manager.
== Selecting the GDB Trace Type ==
Right-click the imported trace in the '''Traces''' folder and choose '''Select Trace Type...''' > '''GDB''' > '''GDB Trace''' from the context menu. This step can be omitted if the trace type was selected at import.
The trace will be updated with the GDB icon [[Image:images/gdb_icon16.png]].
== Selecting the Trace Executable ==
The executable file that created the tracepoint data must be identified so that the C/C++ Postmortem Debugger can be launched properly.
Right-click the GDB trace in the '''Traces''' folder and choose '''Select Trace Executable...''' from the context menu. Browse to, or enter, the path of the executable file and press '''OK'''.
The selected file must be recognized by GDB as an executable.
= Visualizing Tracepoint Data =
== Opening a GDB Trace ==
In the '''Traces''' folder, double-click the GDB trace or right-click it and select '''Open''' from the context menu.
The tracepoint data will be opened in an Events editor, and a C/C++ Postmortem Debugger instance will be launched.
If available in the workspace, the source code corresponding to the first trace record will also be opened in a C/C++ editor.
At this point it is recommended to relocate the Events editor outside of the default editor area, so that it is not hidden by the C/C++ editor.
== Viewing Trace Data ==
In the Events editor, a table is shown with one row for each trace record. The '''Trace Frame''' column shows the sequential trace record number. The '''Tracepoint''' column shows the number assigned by GDB at collection time for this tracepoint. The '''File''' column shows the file name, line number and method where the tracepoint was set. The '''Content''' column shows the data collected at run-time by the tracepoint.
Searching and filtering can be done on any column by entering a regular expression in the column header.
== Navigating the GDB Trace ==
Trace records can be selected in the Events editor using the keyboard or mouse. The C/C++ Postmortem Debugger in the '''Debug''' view will be updated to show the stack trace of the current trace record.
The trace can also be navigated from the '''Trace Control''' view by clicking the '''Next Trace Record''' or '''Previous Trace Record''' buttons. The Events editor and '''Debug''' views will be updated.
= References =
* [http://wiki.eclipse.org/index.php/Linux_Tools_Project/LTTng2/User_Guide LTTng User Guide]
* [http://wiki.eclipse.org/CDT/User/FAQ#How_can_I_trace_my_application_using_C.2FC.2B.2B_Tracepoints.3F CDT FAQ - How can I trace my application using C/C++ Tracepoints?]
= Updating This Document =
This document is maintained in a collaborative wiki. If you wish to update or modify this document please visit [http://wiki.eclipse.org/index.php/Linux_Tools_Project/GDB_Tracepoint_Analysis/User_Guide http://wiki.eclipse.org/Linux_Tools_Project/GDB_Tracepoint_Analysis/User_Guide]
#+OPTIONS: H:3 num:nil toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t TeX:t LaTeX:t skip:nil d:(HIDE) tags:not-in-toc
#+STARTUP: align fold nodlcheck hidestars oddeven lognotestate
#+SEQ_TODO: TODO(t) INPROGRESS(i) WAITING(w@) | DONE(d) CANCELED(c@)
#+TAGS: Write(w) Update(u) Fix(f) Check(c)
#+TITLE: org-ruby
#+AUTHOR: Brian Dewey
#+EMAIL: bdewey@gmail.com
#+LANGUAGE: en
#+PRIORITIES: A C B
#+CATEGORY: worg
{Back to Worg's index}
* Motivation
The dominant simple plain-text markup languages for the web are
Textile and Markdown. A factor for the popularity of those markup
formats is the widespread availability of simple, free packages for
converting the formats to HTML. For example, the world of
Ruby-powered websites has settled on RedCloth for converting Textile
to HTML.
The default way to convert org-mode files to HTML is the powerful
publishing functionality provided by =emacs=. However, =emacs= does
not easiliy integrate into many existing website frameworks.
=Org-ruby= tries to make it easier to use org-mode files in both
dyanmic and static website generation tools written in
Ruby. =Org-ruby= is a simple Ruby gem to convert org-mode files to
HTML.
* Using Org-ruby
=Org-ruby= follows the same model as other Ruby markup
libraries. You install the gem:
#+BEGIN_EXAMPLE
sudo gem install org-ruby
#+END_EXAMPLE
Then, to convert an org-file to HTML in your Ruby code:
#+BEGIN_EXAMPLE
require 'rubygems'
require 'org-ruby'
data = IO.read(filename)
puts Orgmode::Parser.new(data).to_html
#+END_EXAMPLE
* Walkthrough: Using org-ruby with Webby
Here is an example of how to integrate =org-ruby= into Webby, a
static website generation tool written in Ruby.
Webby follows a similar pattern to other static site generation
tools (like nanoc, Jekyll, and webgen):
- You author website content in text with simple markup
- Each page is fed through one or more /filters/ to produce HTML
- The HTML is mixed in with layouts to produce the final pages
For a Webby site, a the source for a page may look like this:
#+BEGIN_EXAMPLE
---
title: Special Directories
created_at: 2009-12-17
status: Complete
filter:
- erb
- maruku
tags:
- powershell
---
<%= @page.title %>
==================
Special Directories are a set of directories, each of which has a
function that will navigate you to the appropriate directory using
the push-location cmdlet. For example, the function `home` might
navigate to `c:\users\bdewey.`
Install
-------
Copy the module to somewhere in `ENV:PSModulePath`. Then,
InstallModule SpecialDirectories
#+END_EXAMPLE
In the above example, the text is written in Markdown. At the top of
the file, metadata informs Webby to pass the text through two
/filters/ to produce HTML. The first filter, =erb=, handles embedded
Ruby. In this case, it will replace ~<%= @page.title %>~ with the
page title (=Special Directories=). The second filter uses Maruku to
translate Markdown into HTML.
You can use the exact same pattern to include org-mode files in a
Webby site. For this walkthrough, I assume you already have Webby
installed, and that you've already created a site.
1. Make sure you have =org-ruby= installed: =sudo gem install
org-ruby=.
2. You need to register a new Webby filter to handle org-mode
content. Webby makes this easy. In the =lib/= folder of your
site, create a file =orgmode.rb=:
#+BEGIN_EXAMPLE
require 'org-ruby'
Webby::Filters.register :org do |input|
Orgmode::Parser.new(input).to_html
end
#+END_EXAMPLE
This code creates a new filter, =org=, that will use the
=org-ruby= parser to translate org-mode input into HTML.
3. Create your content. For example:
#+BEGIN_EXAMPLE
---
title: Orgmode Parser
created_at: 2009-12-21
status: Under development
filter:
- erb
- org
tags:
- orgmode
- ruby
---
<%= @page.title %>
Status: <%= @page.status %>
* Description
Helpful Ruby routines for parsing orgmode files. The most
significant thing this library does today is convert orgmode files
to textile. Currently, you cannot do much to customize the
conversion. The supplied textile conversion is optimized for
extracting "content" from the orgfile as opposed to "metadata."
* History
** 2009-12-29: Version 0.4
- The first thing output in HTML gets the class "title"
- HTML output is now indented
- Proper support for multi-paragraph list items.
See? This paragraph is part of the last bullet.
- Fixed bugs:
- "rake spec" wouldn't work on Linux. Needed "require 'rubygems'".
#+END_EXAMPLE
This file will go through the =erb= and =org= filters; as defined
in the previous step, the =org= filter will use =org-ruby= to
generate HTML.
That's all there is to it!
= \RDoc - Ruby Documentation System
home :: https://github.com/rdoc/rdoc
rdoc :: http://docs.seattlerb.org/rdoc
bugs :: https://github.com/rdoc/rdoc/issues
code quality :: {<img src="https://codeclimate.com/badge.png" alt="code climate">}[https://codeclimate.com/github/rdoc/rdoc]
== Description
RDoc produces HTML and command-line documentation for Ruby projects. RDoc
includes the +rdoc+ and +ri+ tools for generating and displaying documentation
from the command-line.
== Generating Documentation
Once installed, you can create documentation using the +rdoc+ command
$ rdoc [options] [names...]
For an up-to-date option summary, type
$ rdoc --help
A typical use might be to generate documentation for a package of Ruby
source (such as RDoc itself).
$ rdoc
This command generates documentation for all the Ruby and C source
files in and below the current directory. These will be stored in a
documentation tree starting in the subdirectory +doc+.
You can make this slightly more useful for your readers by having the
index page contain the documentation for the primary file. In our
case, we could type
% rdoc --main README.rdoc
You'll find information on the various formatting tricks you can use
in comment blocks in the documentation this generates.
RDoc uses file extensions to determine how to process each file. File names
ending +.rb+ and +.rbw+ are assumed to be Ruby source. Files
ending +.c+ are parsed as C files. All other files are assumed to
contain just Markup-style markup (with or without leading '#' comment
markers). If directory names are passed to RDoc, they are scanned
recursively for C and Ruby source files only.
To generate documentation using +rake+ see RDoc::Task.
To generate documentation programmatically:
gem 'rdoc'
require 'rdoc/rdoc'
options = RDoc::Options.new
# see RDoc::Options
rdoc = RDoc::RDoc.new
rdoc.document options
# see RDoc::RDoc
== Writing Documentation
To write documentation for RDoc place a comment above the class, module,
method, constant, or attribute you want documented:
##
# This class represents an arbitrary shape by a series of points.
class Shape
##
# Creates a new shape described by a +polyline+.
#
# If the +polyline+ does not end at the same point it started at the
# first pointed is copied and placed at the end of the line.
#
# An ArgumentError is raised if the line crosses itself, but shapes may
# be concave.
def initialize polyline
# ...
end
end
The default comment markup format is the RDoc::Markup format.
TomDoc[rdoc-ref:RDoc::TomDoc], Markdown[rdoc-ref:RDoc::Markdown] and
RD[rdoc-ref:RDoc::RD] format comments are also supported. You can set the
default comment format for your entire project by creating a
<tt>.rdoc_options</tt> file. See RDoc::Options@Saved+Options for instructions
on creating one. You can also set the comment format for a single file
through the +:markup:+ directive, but this is only recommended if you wish to
switch markup formats. See RDoc::Markup@Other+directives.
Comments can contain directives that tell RDoc information that it cannot
otherwise discover through parsing. See RDoc::Markup@Directives to control
what is or is not documented, to define method arguments or to break up
methods in a class by topic. See RDoc::Parser::Ruby for directives used to
teach RDoc about metaprogrammed methods.
See RDoc::Parser::C for documenting C extensions with RDoc.
To determine how well your project is documented run <tt>rdoc -C lib</tt> to
get a documentation coverage report. <tt>rdoc -C1 lib</tt> includes parameter
names in the documentation coverage report.
== Bugs
See CONTRIBUTING@Bugs for information on filing a bug report. It's OK to file
a bug report for anything you're having a problem with. If you can't figure
out how to make RDoc produce the output you like that is probably a
documentation bug.
== License
RDoc is Copyright (c) 2001-2003 Dave Thomas, The Pragmatic Programmers.
Portions (c) 2007-2011 Eric Hodel. Portions copyright others, see individual
files and LEGAL.rdoc for details.
RDoc is free software, and may be redistributed under the terms specified in
LICENSE.rdoc.
== Warranty
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.
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment