Greg Hurrell [Tue, 21 Oct 2014 01:57:46 +0000 (18:57 -0700)]
Unconditionally override String#each
This is ok because we're targeting a specific version of Ruby now, and
will soon switch to using refinements to keep the monkey patching
somewhat clean.
It would be nice to just use `#each_line` directly, but elsewhere we
rely on being able to call `#each` uniformly on objects that might be
arrays or strings. (Duck typing, hmph...)
Greg Hurrell [Tue, 21 Oct 2014 01:08:31 +0000 (18:08 -0700)]
Simplify spec helper requires
RSpec takes care of the load path for us, so this absolute path stuff
isn't necessary; but note, you still need to run these specs with
`RUBYLIB` appropriately set; ie:
Wincent Colaiuta [Sun, 29 Aug 2010 23:38:49 +0000 (01:38 +0200)]
Gemfile: depend on Git version of Walrat, separate from gemspec
While Bundler's "gemspec" directive is very convenient, it obviously
doesn't allow for the specification of special dependencies like ":path"
or ":git" based gems, because those can't be specified in the gemspec.
Neither can we pull in the gemspec dependencies with "gemspec" and then
redefine them in the Gemfile, because Bundler will complain.
So, the necessary evil here is to repeat our dependencies in both the
gemspec file and the Gemfile. This is the only way to practically
develop a project like Walrus, which has such a tight coupling to
another gem (in this case, Walrat); sometimes changes in Walrat are
required, and it would be insane to have to be able to test them with
Walrus only after publishing a new release of the Walrat gem (because
Bundler tries to force you to use an "isolated" environment, it makes it
very difficult to, for example, install a local copy of the Walrat
development gem to the system, and then reuse that in the Bundle; it
always wants to check rubygems.org to find out what the official latest
release is).
Wincent Colaiuta [Sun, 29 Aug 2010 23:00:42 +0000 (01:00 +0200)]
Avoid spawning a separate Ruby process during "fill" and "compile"
This is more efficient as it avoids unnecessary forking, but it requires
that the user does not pass conflicting templates in a single batch (for
example, two templates which attempt to define the same class).
Wincent Colaiuta [Sun, 29 Aug 2010 20:52:09 +0000 (22:52 +0200)]
Remove special runtime/eval handling from Walrus::Document
As Walrus::Document is an abstract superclass, it will never be
separately run from the command-line, nor read and dynamically
evaluated, so this special handling can be removed.
Actual subclasses, however, can and will use this handling; see the
Walrus::Compiler class which inserts the necessary statements in every
compiled template.
Wincent Colaiuta [Sun, 29 Aug 2010 20:35:39 +0000 (22:35 +0200)]
Don't require 'pathname' in Walrus::Document
Way back in ancient history (see commit 3607c37 on the Subversion
"trunk" import), the Pathname class was pulled into the Walrus::Document
class because it was needed to implement the new
Walrus::Document.require method:
Make 'Document' subclass requires work more easily for users
without explicit knowledge of Ruby's load path mechanism;
inheritance acceptance specs and changes to get them working
Soon after that (see commit 78bf4e4, still in the Subversion "trunk"
import), the Walrus::Document.require method was ripped out, removing
all dependence on the Pathname class:
Modify '#import' and '#extends' directives to take string literal
parameters instead of constants for consistency with Ruby's '
require' style; this also enables the specification of relative
paths; alternative method for loading templates that aren't in the
load path
The require should have been removed at the same time, but it was
overlooked.
Wincent Colaiuta [Sun, 29 Aug 2010 19:34:40 +0000 (21:34 +0200)]
Make Wopen3 a development dependency instead of a runtime one
This makes Walrus "fork free" and therefore is a step towards
compatibility with JRuby. (Previously "walrus compile" would run but
"walrus fill" would not, because JRuby does not and probably never will
support forking.)
Wincent Colaiuta [Sun, 29 Aug 2010 18:49:18 +0000 (20:49 +0200)]
Ruby 1.9: use Object.class_eval instead of eval
This commit takes the fix that was originally applied in commit af2a030
and extends it to the entire spec suite. With this change there are only
3 failing specs under 1.9 in the entire suite, and notably, all of the
acceptance specs pass, leaving only a couple of "edge cases".
Wincent Colaiuta [Sun, 29 Aug 2010 18:24:10 +0000 (20:24 +0200)]
Ruby 1.9: can no long feed Pathname into Wopen3
Just as with Pathname.glob(...), we can no longer pass Pathname
instances into Wopen3.system. This is because the arguments are passed
to the "exec" method under the hood, and "exec" complains about them
being non-strings.
Wincent Colaiuta [Sun, 29 Aug 2010 17:16:02 +0000 (19:16 +0200)]
Work around variable __FILE__ madness
The value of __FILE__ in a spec will vary depending on how it was
invoked, which can wreak havoc with specs that are sensitive to whether
they are working with relative or absolute paths.
The acceptance specs are one example of such sensitive specs, and they
were broken when run as "spec spec" or "spec acceptance", but not as
"spec spec/acceptance/complete_application_spec.rb".
Work around this by first converting to absolute path, and then back to
absolute, so that we know we are always working with relative paths no
matter how we were in invoked.
Wincent Colaiuta [Sun, 29 Aug 2010 15:05:35 +0000 (17:05 +0200)]
Fix broken handling of directory arguments
Recursing into directories was broken due to infinite recursion, leading
to "stack level too deep" errors.
On fixing this bug and testing it, I've come to see that the ability to
pass in directories is of limited usefulness anyway, because Walrus
expects all files in the directory to be templates. Seeing as compiled
templates are by default written alongside their inputs, this condition
(of all files in a directory being input templates) will fall apart as
soon as you do a "walrus compile" on the directory.
So I am thinking of removing the "-R" switch and the processing of
directory arguments entirely.
Wincent Colaiuta [Sun, 29 Aug 2010 10:53:10 +0000 (12:53 +0200)]
Add "complete application" specs
These currently work, but may need to look at using Bundler to simplify
the invocation of the "walrus" command-line tool here (although that may
itself be opening up a can of worms).
Wincent Colaiuta [Sun, 29 Aug 2010 00:26:06 +0000 (02:26 +0200)]
Add Hextrapolate template files to acceptance spec area
This is a snapshot of the templates that are used to generate the
Hextrapolate application documentation. It is only a snapshot as there
is no need to keep them current with the latest version of the
application; their only purpose is to provide us with a large body of
template files that we can run different versions of Walrus on, on
different Ruby implementations, and confirm that the generated output is
unchanging.
Wincent Colaiuta [Sun, 29 Aug 2010 00:23:59 +0000 (02:23 +0200)]
Add buildtools as a submodule
In preparation for using a complete set of application documentation as
part of the acceptance specs, add buildtools as a submodule (the
application in question depends on buildtools for certain parent
templates and other supporting files).
Wincent Colaiuta [Sun, 29 Aug 2010 00:19:48 +0000 (02:19 +0200)]
Rename "complex" spec files to "tmpl"
Now that we have separate directories, it is no longer necessary to use
file extensions to distinguish between the two types of acceptance spec
inputs.
This is in preparation for the addition of a third type of acceptance
test, which will take an existing template set (eg the Hextrapolate
docs) and run Walrus over that, checking that the output is constant
across versions of Ruby and Walrus.
Wincent Colaiuta [Sat, 28 Aug 2010 20:16:08 +0000 (22:16 +0200)]
Ruby 1.9: workaround changes in Array#to_s behavior
There are plenty of places in the codebase where this behavior change
has impact, but this commit picks off some of the low-hanging fruit.
The problem is that Array, and therefore Walrat::ArrayResult, under 1.9
behavior like this:
[].to_s # => "[]"
[1,2,3].to_s # => "[1, 2, 3]"
(Compare this to 1.8.7 where they returned "" an "123" respectively.)
In other words, Array#to_s is really now a debugging tool more than
anything else, behaving like #inspect. To fix this issue entirely will
probably have to make a number of changes in various parts of the
codebase, including in Walrat itself (particularly the Node class, which
does #to_s internally).
Wincent Colaiuta [Sat, 28 Aug 2010 19:32:06 +0000 (21:32 +0200)]
Ruby 1.9: String#each no longer exists
This is probably not the nicest way to fix this under Ruby 1.9, but it
certainly is the easiest way. Given that Walrus is effectively its own
little sandbox doing this kind of meddling with a core class like
String is perhaps a little more justifiable; nevertheless, I'd like to
later on come up with an alternative compatibility fix.
Wincent Colaiuta [Sat, 28 Aug 2010 17:17:40 +0000 (19:17 +0200)]
Fix unwanted extra lines after compiled tempalte_body
Previously when there was no "outside" content of a template (ie. no
block definitions) we would end up with compiled output like this:
def template_body
...
end
if __FILE__ == $0
...
end
With this commit the unwanted blank line will no longer appear. This
works fine because the DefDirective, which is responsible for producing
the "outside" content, returns it with two trailing newlines when it is
present. So templates with "outside" content continue to look like this:
Wincent Colaiuta [Sat, 28 Aug 2010 16:19:50 +0000 (18:19 +0200)]
Accumulate only last expression in list in an #echo directive
Previously given:
#echo "foo"; "bar"; "baz"
we echoed "foobarbaz" to the template. Now we evaluate all expressions
in the list but only accumulate the last one (ie. the output is "baz"
although "foo" and "bar" are silently evaluated first).
This means that:
#echo @foo = 1 + 2; @foo = @foo + 3; @foo
Now prints "6" whereas previously it would have emitted "366".
This brings us into line with most other template languages and also
with Ruby itself:
Wincent Colaiuta [Sat, 28 Aug 2010 13:38:14 +0000 (15:38 +0200)]
Make use of extracted :line and :here_document_marker rules
These rules snuck into an earlier commit, 1fdfcf8, "Rewrapping and
reformatting for display on narrow terminals". By extracting them and
reusing them here we avoid repeated calls to to_parseable and the
corresponding creation of RegexpParslet instances.
Wincent Colaiuta [Tue, 24 Aug 2010 00:02:39 +0000 (02:02 +0200)]
Various style and consistency fixes in Walrus::Runner
- drop some unnecessary parens
- drop unnecessary #to_s calls
- rewrap some long lines
- reword for consistency
- use shorter syntax for raising (ie. "Class, message" rather than
"Class.new message")
Wincent Colaiuta [Mon, 23 Aug 2010 16:27:22 +0000 (18:27 +0200)]
Set default output extension to empty string
This is an important change because it may break existing workflows.
Previously the default input extension was "tmpl" and the default
output extension was "html".
This meant that given input file:
hello.tmpl
Compilation would yield:
hello.rb
And filling would yield:
hello.html
For these commands:
walrus compile hello.tmpl
walrus fill hello.tmpl
This approach isn't ideal because Walrus is agnostic about the language
that will be used for filled templates. It shouldn't make people who
want to target different languages work harder.
So now we maintain the default input extension of "tmpl" but set the
default output extension to "". This means that given input file:
This is the behavior change which may break existing workflows. To get
the old workflow back we instead have to pass the -e or
--output-extension switches to "walrus fill":
walrus fill -e html hello.tmpl
Or, alternatively, change the source template name:
hello.html.tmpl
Which will cause:
walrus compile hello.html.tmpl
walrus fill hello.html.tmpl
To yield:
hello.html.rb
hello.html
One benefit of using multiple extensions like this is that we can now
point Walrus at a folder containing multiple file types; eg:
display.css.tmpl
index.html.tmpl
And have it produce the filled output with different extensions:
display.css
index.html
Another benefit is that smart text editors can provide better syntax
coloring for files (consider the classic example of a PHP file which
contains HTML text with PHP "islands" embedded inside it).