github-markup 4.0.2 → 5.0.0

Sign up to get free protection for your applications and to get access to all the features.
@@ -15,18 +15,20 @@ Using Java from Ruby is JRuby's best-known feature---but you can also go in the
15
15
 
16
16
 
17
17
  <h1>
18
- <a name="Red_Bridge_JRuby_Embed"></a>Red Bridge (JRuby Embed)</h1>
18
+ <a name="Red_Bridge_JRuby_Embed"></a>Red Bridge (JRuby Embed)
19
+ </h1>
20
+
19
21
 
20
22
 
21
23
  <p><tt>one-&lt;two</tt>
22
24
  </p><pre>a-b</pre>
23
25
 
24
-
25
26
  <p>JRuby has long had a private embedding API, which was closely tied to the runtime's internals and therefore changed frequently as JRuby evolved. Since version 1.4, however, we have also provided a more stable public API, known as Red Bridge or JRuby Embed. Existing Java programs written to the <a href="DirectJRubyEmbedding">legacy API</a> should still work, but we strongly recommend Red Bridge for all new projects.
26
27
  </p>
27
28
 
28
29
  <h2>
29
- <a name="Features_of_Red_Bridge"></a>Features of Red Bridge</h2>
30
+ <a name="Features_of_Red_Bridge"></a>Features of Red Bridge
31
+ </h2>
30
32
 
31
33
 
32
34
  <p>Red Bridge consists of two layers: Embed Core on the bottom, and implementations of <a href="http://www.jcp.org/en/jsr/detail?id=223" target="_blank">JSR223</a> and <a href="http://jakarta.apache.org/bsf/" target="_blank">BSF</a> on top. Embed Core is JRuby-specific, and can take advantage of much of JRuby's power. JSR223 and BSF are more general interfaces that provide a common ground across scripting languages.
@@ -46,14 +48,16 @@ For projects requiring multiple scripting languages, JSR223 is a good fit. Thoug
46
48
  </p>
47
49
 
48
50
  <h1>
49
- <a name="Previous_Embedding_JRuby_Page"></a>Previous Embedding JRuby Page</h1>
51
+ <a name="Previous_Embedding_JRuby_Page"></a>Previous Embedding JRuby Page
52
+ </h1>
50
53
 
51
54
 
52
55
  <p>We recommend using Embed Core; however, if you're maintaining code that uses the old API, you can find its documentation on the <a href="JavaIntegration">legacy embedding</a><sup>[<a href="#cite_note-1">1</a>]</sup> page.
53
56
  </p>
54
57
 
55
58
  <h1>
56
- <a name="References"></a>References</h1>
59
+ <a name="References"></a>References
60
+ </h1>
57
61
 
58
62
 
59
63
  <p></p><ol><li>
@@ -10,7 +10,8 @@
10
10
 
11
11
  <ul>
12
12
 
13
- <li><p>Create a working compiler that understands the majority of the MATLAB/Octave programming language.</p>
13
+ <li>
14
+ <p>Create a working compiler that understands the majority of the MATLAB/Octave programming language.</p>
14
15
 
15
16
  </li>
16
17
  </ul>
@@ -21,13 +22,16 @@
21
22
 
22
23
  <ul>
23
24
 
24
- <li><p>The first is the parser, located in the <code>src/parser/</code> directory. The parser proper is composed of three source files, <i>grammar.pg</i> which is a Perl6Grammar file, and <i>actions.pm</i> which is the associated actions file written in NQP, and <i>grammar-oper.pm</i> which is the operator precedence parser. In addition, several helper functions used by the parser are located in <code>src/internals</code>.</p>
25
+ <li>
26
+ <p>The first is the parser, located in the <code>src/parser/</code> directory. The parser proper is composed of three source files, <i>grammar.pg</i> which is a Perl6Grammar file, and <i>actions.pm</i> which is the associated actions file written in NQP, and <i>grammar-oper.pm</i> which is the operator precedence parser. In addition, several helper functions used by the parser are located in <code>src/internals</code>.</p>
25
27
 
26
28
  </li>
27
- <li><p>The second component is the library of builtin functions in the <code>src/builtins/</code> directory. These functions are, currently, written primarily in PIR. Function names prefixed with an underscore are &quot;private&quot; functions for use with the parser. Other functions should have names which are the same as names for regular MATLAB or Octave functions, since they will be available to the HLL. These are also separated into different namespaces depending on visibility and utility.</p>
29
+ <li>
30
+ <p>The second component is the library of builtin functions in the <code>src/builtins/</code> directory. These functions are, currently, written primarily in PIR. Function names prefixed with an underscore are "private" functions for use with the parser. Other functions should have names which are the same as names for regular MATLAB or Octave functions, since they will be available to the HLL. These are also separated into different namespaces depending on visibility and utility.</p>
28
31
 
29
32
  </li>
30
- <li><p>A number of library functions are written in M, or mostly M with some inline PIR code in <code>toolbox/</code>.</p>
33
+ <li>
34
+ <p>A number of library functions are written in M, or mostly M with some inline PIR code in <code>toolbox/</code>.</p>
31
35
 
32
36
  </li>
33
37
  </ul>
@@ -2,7 +2,7 @@
2
2
  <h2>Subtitle</h2>
3
3
  <p>Example text.</p>
4
4
  <div>
5
- <p>Table of Contents</p>
5
+ <p><a href="#top">Table of Contents</a></p>
6
6
  <ul>
7
7
  <li><a href="#header-2">Header 2</a></li>
8
8
  <li><a href="#field-list">Field list</a></li>
@@ -102,7 +102,8 @@ python.code('hello world')
102
102
  </tr>
103
103
  </tbody>
104
104
  </table>
105
- <a href="https://scan.coverity.com/projects/621"><img alt="Coverity Scan Build Status" src="https://scan.coverity.com/projects/621/badge.svg">
105
+ <a href="https://scan.coverity.com/projects/621">
106
+ <img alt="Coverity Scan Build Status" src="https://scan.coverity.com/projects/621/badge.svg">
106
107
  </a>
107
108
  <img alt="Coverity Scan Build Status" src="https://scan.coverity.com/projects/621/badge.svg">
108
109
  <a name="field-list"></a>
@@ -133,5 +134,4 @@ but no problem!</td>
133
134
  </table>
134
135
  <p><a href="mailto:someone@somewhere.org">someone@somewhere.org</a></p>
135
136
  <p>Press <kbd>Ctrl+C</kbd> to quit</p>
136
-
137
- <p><strong>RAW HTML!</strong></p> p {color:blue;}
137
+ <p><strong>RAW HTML!</strong></p> p {color:blue;}
@@ -43,4 +43,4 @@
43
43
 
44
44
  </div>
45
45
  </div>
46
- </div>
46
+ </div>
@@ -1,5 +1,5 @@
1
1
  <div>
2
- <p>Contents</p>
2
+ <p><a href="#top">Contents</a></p>
3
3
  <ul>
4
4
  <li>
5
5
  <a href="#introduction">1   Introduction</a><ul>
@@ -29,4 +29,4 @@ C source code.</p>
29
29
  </ul>
30
30
  <p><strong>pycparser</strong> is unique in the sense that it's written in pure Python - a very
31
31
  high level language that's easy to experiment with and tweak. To people familiar
32
- with Lex and Yacc, <strong>pycparser</strong>'s code will be simple to understand.</p>
32
+ with Lex and Yacc, <strong>pycparser</strong>'s code will be simple to understand.</p>
metadata CHANGED
@@ -1,14 +1,14 @@
1
1
  --- !ruby/object:Gem::Specification
2
2
  name: github-markup
3
3
  version: !ruby/object:Gem::Version
4
- version: 4.0.2
4
+ version: 5.0.0
5
5
  platform: ruby
6
6
  authors:
7
7
  - Chris Wanstrath
8
8
  autorequire:
9
9
  bindir: bin
10
10
  cert_chain: []
11
- date: 2023-10-11 00:00:00.000000000 Z
11
+ date: 2024-06-17 00:00:00.000000000 Z
12
12
  dependencies:
13
13
  - !ruby/object:Gem::Dependency
14
14
  name: rake
@@ -92,28 +92,28 @@ dependencies:
92
92
  requirements:
93
93
  - - "~>"
94
94
  - !ruby/object:Gem::Version
95
- version: 1.8.1
95
+ version: 1.16.5
96
96
  type: :development
97
97
  prerelease: false
98
98
  version_requirements: !ruby/object:Gem::Requirement
99
99
  requirements:
100
100
  - - "~>"
101
101
  - !ruby/object:Gem::Version
102
- version: 1.8.1
102
+ version: 1.16.5
103
103
  - !ruby/object:Gem::Dependency
104
104
  name: nokogiri-diff
105
105
  requirement: !ruby/object:Gem::Requirement
106
106
  requirements:
107
107
  - - "~>"
108
108
  - !ruby/object:Gem::Version
109
- version: 0.2.0
109
+ version: 0.3.0
110
110
  type: :development
111
111
  prerelease: false
112
112
  version_requirements: !ruby/object:Gem::Requirement
113
113
  requirements:
114
114
  - - "~>"
115
115
  - !ruby/object:Gem::Version
116
- version: 0.2.0
116
+ version: 0.3.0
117
117
  - !ruby/object:Gem::Dependency
118
118
  name: github-linguist
119
119
  requirement: !ruby/object:Gem::Requirement
@@ -177,6 +177,8 @@ files:
177
177
  - test/markups/README.hidetitle.asciidoc.html
178
178
  - test/markups/README.litcoffee
179
179
  - test/markups/README.litcoffee.html
180
+ - test/markups/README.long.rst
181
+ - test/markups/README.long.rst.html
180
182
  - test/markups/README.markdown
181
183
  - test/markups/README.markdown.html
182
184
  - test/markups/README.mediawiki
@@ -213,14 +215,14 @@ required_ruby_version: !ruby/object:Gem::Requirement
213
215
  requirements:
214
216
  - - ">="
215
217
  - !ruby/object:Gem::Version
216
- version: '0'
218
+ version: 3.0.0
217
219
  required_rubygems_version: !ruby/object:Gem::Requirement
218
220
  requirements:
219
221
  - - ">="
220
222
  - !ruby/object:Gem::Version
221
223
  version: '0'
222
224
  requirements: []
223
- rubygems_version: 3.0.3
225
+ rubygems_version: 3.5.11
224
226
  signing_key:
225
227
  specification_version: 4
226
228
  summary: The code GitHub uses to render README.markup
@@ -237,6 +239,8 @@ test_files:
237
239
  - test/markups/README.hidetitle.asciidoc.html
238
240
  - test/markups/README.litcoffee
239
241
  - test/markups/README.litcoffee.html
242
+ - test/markups/README.long.rst
243
+ - test/markups/README.long.rst.html
240
244
  - test/markups/README.markdown
241
245
  - test/markups/README.markdown.html
242
246
  - test/markups/README.mediawiki