Wincent Colaiuta [Mon, 11 May 2009 21:30:01 +0000 (23:30 +0200)]
Rename _Wikitext_parser_* functions to _Wikitext_*
While it makes sense to name functions that are externally
exported to the "Ruby" side following the "Module_Class_*"
pattern, it's not really justified or necessary for functions
which are for internal use only.
This is especially the case for some of these functions whose
internal purpose and use and drifted away from the external
counterparts. (For example, the _Wikitext_append_sanitized_link_target
function which no longer mirrors the externally visible
Wikitext_parser_sanitize_link_target function.)
Wincent Colaiuta [Mon, 11 May 2009 19:11:12 +0000 (21:11 +0200)]
Reformat _Wikitext_utf8_to_utf32 for better readability
Reduce line lengths to make the _Wikitext_utf8_to_utf32
function more readable, most notably by splitting lengthy
condition expressions and bitwise-OR expressions across
multiple lines.
Wincent Colaiuta [Mon, 11 May 2009 19:00:20 +0000 (21:00 +0200)]
Avoid copying string backing when returning from parse function
This is a somewhat nasty hack to avoid making a copy of the output
when it comes time to return from the function. For the time being
it will only work with Ruby 1.8.x, or at least, 1.9.x hasn't been
tested yet.
Wincent Colaiuta [Mon, 11 May 2009 18:56:42 +0000 (20:56 +0200)]
Make _Wikitext_parser_sanitize_link_target return void
Avoid the creation of another temporary Ruby String instance
by appending directly to a buffer. As part of this change the
_Wikitext_parser_sanitize_link_target function has been renamed
to _Wikitext_parser_append_sanitized_link_target.
Wincent Colaiuta [Mon, 11 May 2009 17:23:02 +0000 (19:23 +0200)]
Refactor _Wikitext_utf32_char_to_entity (append to buffer)
Rename the _Wikitext_utf32_char_to_entity function to
_Wikitext_append_entity_from_utf32_char, teaching it to
append to a target buffer directly rather than creating
a temporary Ruby String instance.
I don't particularly like these low-level manipulations but
the main goal here is to avoid the extra allocation; a
subsequent commit will clean up.
Wincent Colaiuta [Sun, 10 May 2009 23:44:11 +0000 (01:44 +0200)]
Add sanity checks to parsing benchmark scripts
After the grand refactoring there are evidently still some lingering
low-level errors, because the benchmarking scripts are bailing with
an "overlong encoding" error after a certain period of time (full
output below).
I've added some sanity checks to the scripts to try and catch discrepancies
but so far none have been discovered.
Here is the full output of the run (this one for "parsing.rb", but the
results are similar for "profile_parsing.rb"):
Rehearsal -------------------------------------------------------------
short slab of ASCII text 1.800000 0.020000 1.820000 ( 2.182344)
short slab of UTF-8 text 3.540000 0.030000 3.570000 ( 4.127638)
longer slab of ASCII text 14.600000 0.140000 14.740000 ( 17.301072)
longer slab of UTF-8 text 46.150000 0.490000 46.640000 ( 58.118039)
--------------------------------------------------- total: 66.770000sec
user system total real
short slab of ASCII text 1.800000 0.020000 1.820000 ( 2.087143)
short slab of UTF-8 text 3.580000 0.040000 3.620000 ( 4.315676)
longer slab of ASCII text 14.680000 0.160000 14.840000 ( 18.018380)
longer slab of UTF-8 text benchmarks/parsing.rb:321:in `parse': invalid
encoding: overlong encoding (Wikitext::Parser::Error)
from benchmarks/parsing.rb:321:in `parse'
from benchmarks/parsing.rb:320:in `times'
from benchmarks/parsing.rb:320:in `parse'
from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/...
from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/...
from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/...
from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/...
from benchmarks/parsing.rb:331
Wincent Colaiuta [Sun, 10 May 2009 16:19:12 +0000 (18:19 +0200)]
Overallocate for speed in str.c
One of the key motivations for switching to the str_t type internally
is that we can avoid allocations by re-using the same storage over and
over during the transformation.
We can avoid other allocations by overallocating when more storage
is requested, seeing as almost all requests for more storage will
later be followed by other requests.
At the moment, the original implementation is quite fast:
user system total real
short slab of ASCII text 1.440000 0.000000 1.440000 ( 1.445547)
short slab of UTF-8 text 2.900000 0.010000 2.910000 ( 2.927274)
longer slab of ASCII text 12.710000 0.040000 12.750000 ( 12.816209)
longer slab of UTF-8 text 35.210000 0.080000 35.290000 ( 35.661577)
The new implementation is actually slower, because we have had to add
some wasteful conversions back-and-forth between VALUE/String and str_t:
short slab of ASCII text 1.550000 0.000000 1.550000 ( 1.556956)
short slab of UTF-8 text 3.340000 0.010000 3.350000 ( 3.377874)
longer slab of ASCII text 15.410000 0.030000 15.440000 ( 15.484308)
longer slab of UTF-8 text 45.230000 0.130000 45.360000 ( 45.631355)
It is expected that the performance loss will be recovered once these
wasteful conversions are eliminated.
But before going that far, adding overallocation brings very large
improvements, enough to compensate for the inefficient conversions:
short slab of ASCII text 1.190000 0.010000 1.200000 ( 1.233443)
short slab of UTF-8 text 2.460000 0.020000 2.480000 ( 2.536714)
longer slab of ASCII text 11.000000 0.050000 11.050000 ( 11.208843)
longer slab of UTF-8 text 33.490000 0.130000 33.620000 ( 34.190941)
Those numbers use an overallocation constant of 256 bytes; will later
experiment with other constants to find the optimal overallocation.
Wincent Colaiuta [Fri, 8 May 2009 15:44:01 +0000 (17:44 +0200)]
Change 4 VALUE (String) members of the parser_t struct to str_t type
This is unfortuantely quite a large commit because the nature of
the change requires many parts to be modified at once; the
intermediate stages are not buildable and therefore not
bisectable.
Change the capture, output, link_target and link_text members of
the parser struct from VALUE (String) type to str_t. This should
improve performance because the str_t is faster and designed for
easy reuse so we can allocate a few instances at the beginning
of parsing and then use them repeatedly throughout the parse,
thus avoid many time-consuming allocations.
Remove the "capturing" member and instead use the "capture"
pointer as an indication of whether capturing is in progress.
Change the type of the "target" param in the
_Wikitext_pop_from_stack function (and the other "pop
from stack" functions) from VALUE (String) to pointer
to str_t.
Change the type of the "check_autolink" parameter to the
_Wikitext_append_hyperlink function from VALUE (boolean) to
bool.
Remove redundant passing in of parser->output to the
_Wikitext_pop_from_stack function.
Teach _Wikitext_blank to accept a pointer to a str_t struct
rather than a Ruby String (VALUE).
Add parser_new function to encapsulate the initial allocation
and initialization of the parser_t struct.
Rename str_append_rb_str function to str_append_string for
consistency with other functions in str.c.
Wincent Colaiuta [Fri, 8 May 2009 14:49:04 +0000 (16:49 +0200)]
Make parser struct participate in Ruby's Garbage Collection
Instead of having individual str_t and ary_t members participate
in Ruby's mark-and-sweep Garbage Collection, put the parser
struct on the stack and make the parser participate; it will
be responsible for cleaning up its own member resources when
it falls out of scope.
Wincent Colaiuta [Fri, 8 May 2009 14:08:03 +0000 (16:08 +0200)]
Add "capturing" member to parser struct
This is preparation for the eventual move of some, perhaps all,
of the members which are currently of String (VALUE) type to the
faster, more easily reused str_t type.
With the VALUE type we can check whether a member is initialized
or in use by doing a NIL_P(member) test.
This is not possible with the str_t type as it is a struct rather
than a pointer (although admittedly, we will be using a pointer to
the struct rather than the struct itself).
We don't want to dispose of the struct and set the pointer to NULL
because the whole point of reusing the str_t structs is that we
can allocate them only once at the start of parsing and then
use them over and over.
Likewise we don't want to abuse the "len" member of the srt_t
struct (for example, setting it to -1 to flag that it is not
in use), because it is not exactly intuitive or self-evident.
Similarly, we don't want to add an additional struct member (a
boolean) to indicate whether the struct is in use or not. The
struct itself shouldn't have to know or care about this; this
should be the responsibility of the caller using the struct.
So for now we set up this "capturing" bool so that we can
track when the parser is in capturing mode. The intention is
that in a later commit the "capture" member will become a
str_t instance (or a pointer to one).
Wincent Colaiuta [Fri, 8 May 2009 13:39:27 +0000 (15:39 +0200)]
Use C99 _Bool type
Seeing as we already compile in C99 mode, we may as well make use
of the _Bool type defined by that standard. We also include the
system "stdbool.h" header so as to have access to the "bool", "true"
and "false" convenience macros.
Wincent Colaiuta [Fri, 8 May 2009 12:50:31 +0000 (14:50 +0200)]
Improve efficiency of _Wikitext_pop_all_from_stack
Use a for-loop instead of repeatedly calling ary_entry inside
a while-loop. The simple integer comparison will be faster
than the function call. (And in any case, the
_Wikitext_pop_from_stack function which is called here will
do an ary_entry call anyway; so what's really happening here
with this change is that we call ary_entry once for each item
instead of twice.)
Wincent Colaiuta [Fri, 8 May 2009 12:10:54 +0000 (14:10 +0200)]
Reuse link_target if link_text is Qnil in _Wikitext_append_hyperlink
This cleans up a few call sites of _Wikitext_append_hyperlink. The
majority of these sites pass in the same text for the link target
and link text parameters, so teach the function to automatically
reuse the link target as the link text if no link text is explicitly
provided.
Wincent Colaiuta [Fri, 8 May 2009 12:00:31 +0000 (14:00 +0200)]
Minor clean-up in _Wikitext_rollback_failed_external_link
Minor reorganization to make _Wikitext_rollback_failed_external_link a
little cleaner. Avoid the almost identical calls to
_Wikitext_append_hyperlink and instead set up a link_class local
variable.
Wincent Colaiuta [Fri, 8 May 2009 11:31:01 +0000 (13:31 +0200)]
Refactor _Wikitext_rollback_failed_link function and friends
The _Wikitext_rollback_failed_link function now encapsulates the
common pattern of trying to roll back failed internal and external
links in a single function call.
On those occasions when we want to roll back only one type of link
we must instead use the _Wikitext_rollback_failed_internal_link or
_Wikitext_rollback_failed_external_link functions.
Wincent Colaiuta [Thu, 7 May 2009 23:03:44 +0000 (01:03 +0200)]
Teach _Wikitext_append_hyperlink to check the autolink setting
Rather than checking the autolink setting in the numerous sites
where _Wikitext_append_hyperlink is called, move the check into
the function itself, and pass a flag in specifying whether to
perform the check.
The overall saving here is about 8 lines thanks to the eliminated
repetition.
Wincent Colaiuta [Thu, 7 May 2009 22:52:05 +0000 (00:52 +0200)]
Remove temporary string variable from _Wikitext_hyperlink
Now that _Wikitext_hyperlink returns void there is no longer any
need to use a temporary String instance. Instead, we append
directly to the parser->output buffer, thus saving an allocation.
Wincent Colaiuta [Thu, 7 May 2009 22:30:54 +0000 (00:30 +0200)]
Add comment justifying the scope_includes_space variable
This comment serves as a reminder for why this variable exists
(to remember what was on the stack prior to popping); without
it the reader might ask "why do we have a temporary variable
here which is only used once?".
Wincent Colaiuta [Thu, 7 May 2009 15:57:32 +0000 (17:57 +0200)]
Remove stale comment
This comment is a left-over from the distant past when many of
these functions were explicitly marked as inline functions,
rather than letting the compiler decided when to inline.
Wincent Colaiuta [Thu, 7 May 2009 09:35:57 +0000 (11:35 +0200)]
Use absolute paths in internal "requires"
Ensure that when locally testing or otherwise using a specific
version of the extension that the files included using "require"
come from the same version and not from some other version in the
load path.
For example, prior to this commit, doing an:
irb -r ext/wikitext lib/wikitext/string
Would not produce the desired result. First the local copy of the
extension would be loaded, then the local "lib/wikitext/string",
but then the latter would do a "require 'wikitext/parser'", which
would load the first corresponding file in the load path (usually
the latest installed gem), which would in turn do a "require
'wikitext'" and end up loading the first corresponding file in
the load path.
Wincent Colaiuta [Wed, 6 May 2009 23:03:58 +0000 (01:03 +0200)]
Specify ":indent => false" default in wikitext/string extension
Seeing as the String extension is primarily for use in Rails
applications, where setting up Haml to run with "ugly" mode turned
on is a good idea, it makes sense to make the "w" and "to_wikitext"
methods on the String class pass in ":indent => false" by default.
This can be overridden if desired by passing in an explicit indent
such as ":indent => 0".
Wincent Colaiuta [Wed, 6 May 2009 22:02:46 +0000 (00:02 +0200)]
Add support for "absolute" image "src" attributes
Under the default settings input like "{{foo.png}}" will be translated
to an "img" tag with "src" attribute of "/images/foo.png".
With this commit, we provide a shortcut for breaking out of the "prefix"
directory: any target beginning with a slash will be interpreted as
"absolute". So input like "{{/foo.png}}" will yield a "src" of
"/foo.png".
This is a somewhat prettier mechanism than using inputs like
"{{../foo.png}}", which already worked under the current translator.
Previously we accepted buggy input like "[[ ]]", "[[ ]]"
and "[[ |foo]]" and dutifully turned it into empty links
like:
<a href="/wiki/"></a>
And:
<a href="/wiki/">foo</a>
It clearly makes no sense for a bad link like "[[ ]]" to
take the user back to the wiki index, so now we spit out
these bad links verbatim to provide feedback to the user
that there's something wrong with their input.
Wincent Colaiuta [Fri, 27 Mar 2009 12:42:49 +0000 (13:42 +0100)]
Fix PRE_START and BLOCKQUOTE_START following shorthand
This adds a special case for PRE_START and
BLOCKQUOTE_START tokens which immediately follow
PRE and BLOCKQUOTE shorthand lines.
Basically, if they appear in the first column
then they are valid, because they close the old
(shorthand) blocks and open a new block. Anywhere
other than the first column they are considered
illegal.
Wincent Colaiuta [Fri, 27 Mar 2009 11:03:35 +0000 (12:03 +0100)]
Consistently apply "mailto" class to mailto URIs
Implement more consistent CSS styling given mailto URIs.
The following inputs previously received "external" CSS
styling because mailto URIs are tokenized as URIs rather
than MAIL tokens:
Wincent Colaiuta [Mon, 23 Feb 2009 21:39:01 +0000 (22:39 +0100)]
Accept options hash in "to_wikitext" and "w" methods
Seeing as "w" is the most frequently-used means of translating
wikitext in the context of a web application, it makes sense to
provide a means of passing in an optional options hash so that
overrides can be conveniently fed into the parser on demand.
Wincent Colaiuta [Mon, 23 Feb 2009 11:28:52 +0000 (12:28 +0100)]
Add "base_heading_level" option
An integer between 0 and 6 denoting the current "heading level".
This can be used to inform the parser of the "context" in which
it is translating markup.
For example, the parser might be translating blog post excerpts
on a page where there is an "h1" title element for the page itself
and an "h2" title element for each excerpt. In this context it is
useful to set base_heading_level to 2, so that any "top level"
headings in the markup (that is "h1" elements) can be automatically
transformed into "h3" elements so that they appear to be
appropriately "nested" inside the containing page elements.
In this way, markup authors can be freed from thinking about
which header size they should use and just always start from "h1"
for their most general content and work their way down.
An additional benefit is that markup can be used in different
contexts at different levels of nesting and the headings will be
adjusted to suit automatically with no intervention from the
markup author.
Finally, it's worth noting that in contexts where the user input
is not necessarily trusted, this setting can be used to prevent
users from inappropriately employing "h1" tags in deeply-nested
contexts where they would otherwise disturb the visual harmony of
the page.
Wincent Colaiuta [Fri, 13 Feb 2009 17:28:33 +0000 (18:28 +0100)]
Ruby 1.9: add magic comments to indicate source file encoding
Lots of these spec files are actually in UTF-8. Ruby 1.8.6
just slurped them in as byte streams so they just worked, but
1.9.1 expects them all to be ASCII and complains when they are
not.
We add these "magic" comments so that Ruby 1.9 knows that the
files are UTF-8-encoded and won't complain.
Wincent Colaiuta [Tue, 3 Feb 2009 22:48:00 +0000 (23:48 +0100)]
Fix subtle Rakefile breakage
As mentioned in b12cb25, the 1.4.0 release was broken due to a misfire
during "rake package".
The diagnosis was as follows; before each of the following tests, a
"rake clobber" was executed to start with a clean slate:
- "rake gem": "make" does appear to be executed,
but produced gem is incomplete
- "rake make; rake gem": produced gem is complete
- "rake package": "make" does appear to be executed,
but produced gem is incomplete
- "rake make; rake package": you can see "clobber"
task getting executed, then "make"; you would
expect this automated "make" not to work seeing
as it is broken in two other cases above, but
the built gem is complete and it works!
Specifically, in the incomplete gems, the generated
extension Makefile has these lines:
Note that the Makefile in the sourcetree in all of these tests
was correct; it was only the file generated from the gems that
was incorrect.
Further inspection showed that the wikitext_ragel.c file was not
included in the gem. This was the key; the file was missing
from inside the gem even though it was correctly generated outside
while building the gem. Naturally, the Makefile was also missing the
file ("mkmf" generates the SRCS and OBJS lines based on what it
finds in the directory).
The reason the file was missing was that the "files" entry in the
Gem specification was evaluated too early, before the dependencies
in the tasks had been executed, and before the "wikitext_ragel.c"
file even existed.
Running "rake make" manually beforehand was enough to make
everything work because it ensured that the "wikitext_ragel.c"
file was present at the time the Gem specification was evaluated;
even though the file was later clobbered and rebuilt it didn't
matter because the "files" entry was correct.
It would have been nice for the gem build to fail due to the
missing file. I would have been alerted then to the fact that
1.4.0 was broken; I'm going to see if I can make the build process
barf in the face of a missing file like that.
Wincent Colaiuta [Tue, 3 Feb 2009 21:49:34 +0000 (22:49 +0100)]
Bump version number prior to 1.4.1 release
This version is basically identical to 1.4.0 but the 1.4.0 gem that was
published on RubyForge was faulty due to an as-yet unexplained bug in
Rake or the Rakefile.
The gem was made using "rake package", which produces a gem which
passes all the specs but which is missing the required object file,
wikitext_ragel.o. "rake clobber; rake package" also suffers from the
missing object file.
"rake clobber; rake make; rake package", on the other hand, does
include the required file.
So for now I want to get a new release out to replace the broken gem
on RubyForge; will investigate the Rake/Rakefile bug subsequently.
Wincent Colaiuta [Sun, 1 Feb 2009 21:28:29 +0000 (22:28 +0100)]
Bump version number prior to 1.4.0 release
As this release involves a compatiblity-breaking change
(the replacement of "special" links in internal link spans
with "path" links in external link spans) bumping the release
number up to 1.4.0.
Wincent Colaiuta [Sun, 1 Feb 2009 21:03:47 +0000 (22:03 +0100)]
Create "special links" from external rather than internal links
It was a clumsy design decision to offer detection of "special links"
inside internal links:
[[/issues/20 | ticket #20]]
A much nicer syntax is to use external links instead:
[/issues/20 ticket #20]
In this commit I rip out the old implementation as well as a
supporting instance variable (treat_slash_as_special), and a
couple of related low-level struct members used at the C
level (treat_slash_as_special and special_link) which were
themselves all probably evidence of "design smell".
In place of the old feature we move handling of "path"-style
links to inside of external links. Specs and docs are updated
accordingly.
git.wincent.com / wikitext.git / log
