So in Ruby 1.9.2-p290 I can do this
content_for :something, do
end
which is quite nice.
But that's a syntax error in Ruby 1.9.3-p125 and instead I need to do this
content_for(:something) do
end
Where can I find documentation about this syntax restriction?
Is there any other way it could be written in 1.9.3-p125?
Just remove the comma:
content_for :something do
end
Related
I've just upgraded an old project to Rails 4 and I've just realized that it has upgrade the schema.rb using the new-style hash syntax. I suppose Rails is gonna use this syntax for all its generators.
How can I, friendly, say to Rails that I prefer the old-style syntax for hashes?
schema.rb is created by rake db:migrate command. As per my knowledge, it will be hard to suggest the old-style syntax for hashes to Rails. BUT nothing is impossible, you can play around with rails/activerecord/lib/active_record/schema_dumper.rb file. The only problem is when you upgrade the rails gem next time it will override.
This old-style syntax to new-style syntax for hashes was done in Dump schema using new style hash commit.
I know this is not exactly an answer to your question, but it might help nevertheless.
If you use vim, this will allow you to toggle between the old & new syntax (source):
function! s:RubyHashSyntaxToggle() range
if join(getline(a:firstline, a:lastline)) =~# '=>'
silent! execute a:firstline . ',' . a:lastline . 's/[^{,]*[{,]\?\zs:\([^: ]\+\)\s*=>/\1:/g'
else
silent! execute a:firstline . ',' . a:lastline . 's/[^{,]*[{,]\?\zs\([^: ]\+\):/:\1 =>/g'
endif
endfunction
command! -bar -range RubyHashSyntaxToggle <line1>,<line2>call s:RubyHashSyntaxToggle()
noremap <Leader>rh :RubyHashSyntaxToggle<CR>
At max it will take you 3 keystrokes to get the schema the way you want. It is not automatic, but as a counterpart it will work on any file, not just on the schema.
You could invoke the substitution every time you save a file (I do that to remove extra spaces at the ends of lines).
And if you don't use vim, these regexes probably be adapted to other editors.
I'm learning how to write parsers, and to do so, I'm writing parser for SQL.
Grammar I'm writing is processed by perl Parse::Eyapp module, which is very similar to standard yacc.
When I added support for single-operand operators (not sure what is the correct name - operators like 12!, or ## 'value'), when compiling the grammar to perl, I got:
14 shift/reduce conflicts
I had it also earlier, but I solved it by adding appropriate %left and %right, but this time I'm at loss, since the problem seems to be from conflict between 1-operand operators, and more traditional two-operand ones.
Full grammar is too long to put in here, so I'll just link to it.
To compile it, I use command:
eyapp -m Pg::SQL::Parser::SQL -o SQL.pm SQL.eyp
When running eyapp ... with verbose enabled, I get this output.
So, the question is: how to solve the problem in here?
Aargh. Looks like I misdiagnosed the problem. The real cause of the problem were not unary operators, but cast (expr '::' normal_type).
Adding %left '::' at the end of priority configs solved the problem.
In case you're curious - commit link.
I'm running a Octopress blog which is based on Jekyll. Now I wanted to add some Javascript which I like to write in CoffeeScript.
I followed this Gist to create a simple converter that compiles CoffeeScript to Javascript:
module Jekyll
require 'coffee-script'
class CoffeeScriptConverter < Converter
safe true
priority :low
def matches(ext)
ext =~ /coffee/i
end
def output_ext(ext)
'.js'
end
def convert(content)
begin
CoffeeScript.compile content
rescue StandardError => e
puts "CoffeeScript error: #{e.message}"
end
end
end
end
The problem is that the generated Javascript file has all quotes escaped (single quotes by ‘ and double quotes by “)
When I output the generated Javascript code in the convert method, it looks fine (quotes are not escaped).
I googled a lot but nobody seems to have this problem.
What could be the issue here?
Turns out Octopress runs the content through RubyPants by default (see plugins/octopress_filters.rb). Disabling RubyPants did the trick!
Since RubyPants ignores content inside HTML comments we can disable RubyPants filtering on the fly by surrounding the output in HTML comments. This also eliminates the need to modify the OctoPress original code.
I've done just that in this gist.
I am watching this great video by Jeremy on CoffeeScript. He explains that one of the ideals of CoffeeScript is to have "everything be an expression".
How close to this ideal has CoffeeScript got? What are the CoffeeScript non-expressions?
There are a few things that are not converted into expressions in coffeescript, as explained in the documentation:
There are a handful of statements in JavaScript that can't be meaningfully converted into expressions, namely break, continue, and return. If you make use of them within a block of code, CoffeeScript won't try to perform the conversion.
Everything else is wrapped in function closures and handled by coffeescript, which means you can do cool stuff like
alert(
try
nonexistent / undefined
catch error
"And the error is ... #{error}"
)
Most PHP Developers are likely familar with the Syntax Highlighter called "GeSHi", which takes code, highlights it, with the use of HTML and CSS:
include('geshi.php');
$source = 'echo "hello, world!";
$language = 'php';
$path = 'geshi/';
$geshi = new GeSHi($source, $language, $path);
echo $geshi->parse_code();
GeSHi Supports a wide range of languages.
I wonder, is there a similar Module for Perl?
Perl has a port of Kate highlighting system: Syntax::Highlight::Engine::Kate which seems to be somewhat close to what you need. It appears to be part of Padre.
You also have an option of HTML client side highlighters (logic is obviously JS), such as Google's code prettifyer
Two good lists of syntax highlighting engines are:
Wiki syntax highlighting article - among the ones it lists, the Perl ports/APIs seem to exist for Kate and Colorer (Syntax::Highlight::Universal)
This very good review of HTML syntax highlighters, which contains a lot of client-side ones such as SHJS and many others.
Please be aware that NONE of those generic highlighters work "100% correctly", the way the syntax highlighters work in good IDEs, because they use regular expressions for approximate parsing instead of lexers for actual language grammar parsing. More details on the Wiki
You can also consider this for client side syntax highlighting.
http://alexgorbatchev.com/SyntaxHighlighter/
I have had some very good results with the PPI::HTML package. It uses PPI to parse the Perl before converting the text to HTML.
Pure Perl: Syntax::Highlight::Engine::Kate (there is Kate plugin for Padre IDE).
Wrappers for C libraries: Syntax::Highlight::Universal, Syntax::SourceHighlight.
Using external tools: Text::VimColor, Text::EmacsColor.
Also there are many one-language highlighters on CPAN.
You can always write a small php script to make GeSHi usable from command line and then call it within your perl script.
I did this for gitweb so I could leave svn (and websvn) behind for good.
My search brought me here, because I was looking for a 'Perl Syntax Highlighter' like the title said and not an general highlighter implemented in Perl.
To highlight only Perl, perltidy --html can be used. It belongs to the Perl::Tidy distribution the main module can be imported and used without spawning a process.
https://metacpan.org/dist/Perl-Tidy/view/bin/perltidy#HTML-OPTIONS
So not what the OP actually wanted to know, but hopefully of help for others coming here for the same reasons like me ... :)