nex3 / haml
- Source
- Commits
- Network (83)
- Issues (18)
- Downloads (47)
- Wiki (1)
- Graphs
-
Branch:
master
-
Haml version 2.2.16
I've got some code with a few consecutive multiline blocks, mostly form fields and their related auto_complete code. When two multiline blocks are placed next to each other, even with a blank line between, they collapse into one multiline block and cause a compile error. Expected behaviour would be to allow a blank line to terminate the multiline block.
%p I think this might get | pretty long so I should | probably make it | multiline so it doesn't | look awful. | %p And this one | will get long as well | so let's make it pretty |Well, you get the idea.
Comments
-
Noticed a small "bug" with SASS. While using nested rules with child selectors (a > b). For example:
class1 > color: green class2 color: redBecomes:
class1 > {color: green;} class1 > class2 {color: red;}This is okay for class2, but for class 1 the selector declaration shouldn't end with >.
Comments
This is the correct behavior. Sass doesn't (and shouldn't) parse your selectors and try to guess what you meant -- it just does what you wrote. In this case, what you wrote is properties nested beneath "class1 >".
A better way to write this might be
class1 color: green > class2 color: redYes, this is a solution. However, I have a lot of nested classes under class1 and they should be the direct childs of class1. I can use this workaround, but I thought that maybe there will be a easier solution for this.
chriseppstein
Sun Dec 20 10:13:04 -0800 2009
| link
You can use the parent reference operator (&) like this:
class1 color: green & > class2 color: redOr you could do this for DRYness so DRY that it chafes:
.class1 color: green & > .class2 color: red .class3 color: blue -
This line of code throws an error for me:
attrs = public_id.scan(/DTD\s+([^\s]+)\s*([^\s]*)\s*([^\s]*)\s*\/\//)[0]The error:
/opt/local/lib/ruby/gems/1.8/gems/haml-2.2.16/bin/../lib/haml/html.rb:135:in `to_haml': private method `scan' called for nil:NilClass (NoMethodError)(Yes, it's /opt/local style, the machine came that way and I haven't had time to fix it.)
Anyway, I searched the gem for other instances of that variable, using both ack and grep, and the string public_id does not appear anywhere else in the code base.
Comments
gilesbowkett
Fri Dec 18 09:56:21 -0800 2009
| link
aarrgh, markdown, dammit
-
0 votes
I recently discovered the following compiler problem. My SASS file includes:
... !category_indicator_image = url(/images/grayshoe.png) ...
background-image = !category_indicator_imageAnd the CSS file generated has:
background-image: url(/images/gray shoe.png);NOTE: it inserted a space after "gray" in my filename. It only happens if I have a standard color name (e.g. 'grayshoe.png' or 'silvershoe.png') in the filename (e.g. 'smallshoe.png' does not generate a file with an extra space).
Comments
-
There's ActionView::Template::Error instead.
Because of this change haml plugin now doesn't work.
This change was introduced in rails/rails@c130409
Comments
-
0 votes
Regression in Haml 2.2.15 : if -else and comments
3 comments Created 29 days ago by mediavrogBefore v 2.2.15 cou could do
- if logged_in? logged in - # logged out - else logged out
Now, this throws an error because of the comment before "- else";
If you remove the comment, it'll workComments
First of all, this doesn't work in 2.2.14, either.
Second, I don't understand why it would be expected to work. The comment line is indented at the same level as the opening "if". That means that it closes the "if" block, and if the "if" block is closed by something other than "else" or "elsif", Haml adds an "end". Comments are no exception to the indentation rules.
ok i get the point;
i just thought comments are to be ignored since they basically aren't involved into any kind of logic/.. -
0 votes
Sass parser doesn't handle ampersand inside a comment.
2 comments Created about 1 month ago by paulnicholsonThe ampersand token seems to have higher precedence in the parser than the comment token. If you have an ampersand in a comment, you get the error:
Sass::SyntaxError: Base-level rules cannot contain the parent-selector-referencing character '&'.
Comments
paulnicholson
Tue Dec 01 09:02:28 -0800 2009
| link
After spending a few minutes digging through the Sass parser code, it seems that making a comment with a single slash is incorrect, and the syntax we needed was two slashes (Sass comment). Unfortunately, the TextMate Haml plugin comments with a single slash. It isn't clear to me what the single slash syntax is intended to do. It doesn't give a syntax error, but it doesn't do anything useful. I don't know why you would want to parse a line as Sass, without context, and then discard the results. Perhaps this syntax could be made interchangeable with the Sass comment syntax, or could give a syntax error. Either of these options would make the language less accident-prone.
The results aren't discarded. Unless you use a comment syntax --
//or/*-- the line is interpreted as a selector. This is what's happening for/. If there are no properties nested beneath the selector (which would presumably be the case if you're treating it as a comment) a warning is printed.Unless there's more agreement that this is a seriously annoying issue, I think I'd rather not expand the comment syntax.
-
0 votes
if/else branch with no if body compiles as syntax error
1 comment Created about 1 month ago by seancribbsAn if statement that has no body but is immediately followed by else on the next line causes a syntax error:
The error is registered at the end of the template although the cause is much earlier. This is using Haml 2.2.9 and 2.2.11.
Comments
-
0 votes
obsolete stacktrace filename kludge in Rails plugin
1 comment Created about 1 month ago by sunakuI'm using haml 2.2.13 and I noticed that the Haml Rails plugin source code still retains an old kludge workaround for not being able to pass the template filename to
Haml::Engineconstructor (fromlib/haml/template/plugin.rb):# There's no way to tell Haml about the filename, # so we've got to insert it ourselves. e.backtrace[0].gsub!('(haml)', file_name) if e.is_a?(Haml::Error)The YARDOC shows that
Haml::Engineconstructor takes a:filenameoption, so that should be used instead of the above kludge. Thanks.Comments
-
!sidebar_columns = floor(!blueprint_grid_columns / 3)
I'm getting 313.333px, so the floor isn't working.Comments
-
0 votes
Haml gives a warning when setting an attribute with a non-ascii character
1 comment Created about 1 month ago by TheAdmiralWhen trying to set an attribute of an element to a value that contains an accented character like so:
echo "%a{:href => 'héllo'}= 'A Hello Link'" | haml -s output.htmlHaml gives the following warning:
/usr/local/lib/ruby/gems/1.9.1/gems/haml-2.2.13/lib/haml/helpers.rb:486: warning: regexp match /.../n against to UTF-8 stringI'm using Ruby 1.9.1, and I've set the Haml :encoding => "UTF-8". Tested using Haml 2.2.13, but IIRC this happened in 2.2.12 too.
Comments
-
0 votes
Ruby 1.9 bug on html2haml [patch]
2 comments Created about 1 month ago by ChristophPetschnigWhen trying to convert a file that starts with
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
, html2haml will fail on html.rb, line 199 with code, that is not compatible with Ruby 1.9strictness[0] = strictness[0] - 32
needs to be replaced with
strictness[0] = strictness[0].kind_of?(Fixnum) ? strictness[0] - 32 : (strictness[0].ord - 32).chr
This is working on 1.8 and 1.9. Get the diff at http://purevirtual.de/temp/fixed_html2haml_19_bug.diff
Sorry, I did't write any tests, because my mal tests fail to run (because of /action_controller/status_codes.rb)
Hope that helps anyone. Kind regards
Christoph Petschnig
Comments
-
Ruby 1.8.7 (2009-06-12 patchlevel 174)
Rails 2.3.4
Haml 2.2.11My application crashes with following exception:
undefined local variable or method `check' for #<ApplicationController:0x30ad108> /opt/ruby-enterprise/lib/ruby/gems/1.8/gems/haml-2.2.11/lib/sass/plugin/rails.rb:25:in `process'The local variable `check' is hidden in method AC::Base#process.
Comments
-
0 votes
haml should rescue exception in case gem is not installed.
3 comments Created about 1 month ago by marcandreplugin should gracefully fail if gem not installed, so that we can use rake gems:install. Otherwise:
$ sudo rake gems:install --trace rake aborted! no such file to load -- hamlComments
I'm sorry, I don't completely understand this bug report. I assume this is within Rails? What are the steps I should take to reproduce this?
Quick reply!
Yes, for rails. Here's how to recreate it:
$ rails demo; cd demo create --snip-- create log/test.log $ haml --rails . Haml plugin added to .add haml as a dependency:
$ mate config/environment.rb --snip-- Rails::Initializer.run do |config| + config.gem "haml" # Settings in config/environments/* take precedence over those specified here. --snip--Fake we copied this code over to a new machine:
$ sudo gem uninstall haml --snip-- Removing haml --snip--The rails way of installing the required gems (assuming they are not vendored) is:
$ sudo rake gems:install (in /Users/work/test/demo) rake aborted! no such file to load -- haml (See full trace by running task with --trace) -
0 votes
image_url fails when an image path name has a color in it
2 comments Created about 1 month ago by steam#footer background: :image= image_url(white-70-percent.png)produces:
#footer { background-image: url('../../images/white -70-percent.png'); }It shouldn't be adding a space after the string "white".
Comments
DEPRECATION WARNING: On line 2, character 41 of 'test.sass' Implicit strings have been deprecated and will be removed in version 2.4. 'percent.png' was not quoted. Please add double quotes (e.g. "percent.png").Use:
#footer background-image = image_url("white-70-percent.png") -
0 votes
Compiled haml templates ought to `ensure` the @haml_buffer is returned at the end (maybe)
2 comments Created about 1 month ago by rubyruyThis line here:
@haml_buffer = @haml_buffer.upper
(from http://github.com/nex3/haml/blob/master/lib/haml/precompiler.rb#L101 )
... won't run if there are errors inside the template. 99.99% of the time this won't be a problem as errors inside the template will stop execution of the whole app and nothing else will get rendered by haml.
However, we are being naughty in our app and actually rescuing from certain errors in our partials in order to continue with a semi-rendered page if possible - so this does actually end up biting us in the ass.
So I'm not sure if this can really be considered a bug or not. On one hand, the current behaviour works fine based on some fairly reasonable assumptions on how it will be used. On the the other hand, that line, like any well behaved clean-up tasks, should simply be guaranteed to run using an
ensure...
Comments
This may be the same issue as raised in this conversation. I agree it would be good practice to have an
ensure... I'll add one. -
0 votes
2.2.10 breaks string concat in rails production environment
2 comments Created 2 months ago by cjolly= link_to('haml', 'http://github.com/nex3/haml'), '.'works fine in Rails 2.2.2 development mode, throws an exception in production:
/Library/Ruby/Gems/1.8/gems/haml-2.2.10/lib/haml/helpers/action_view_mods.rb:13:in `render'I discovered this behavior after upgrading from Haml 2.1.0, where it worked fine in both development and production environments.
Comments
Concatenating strings with commas is not valid Ruby code, and is no more valid when that Ruby happens to be within a Haml document. That it works in development mode in 2.2.* is a bug. It's fixed in the master branch, but the fix hasn't been backported because it requires some reasonably in-depth changes to the compiler and as suchis not something I feel comfortable doing in stable.
-
0 votes
css2sass incorrectly translates :focus pseudo-element
5 comments Created 2 months ago by zapnapsteps to reproduce:
- run css2sass on meyer's classic reset.css
- place sass file in the appropriate location
- when translated back to css for the browser, it chokes on the incorrect definition
Sass::SyntaxError: Properties aren't allowed at the root of a document.
on line 23 of /Users/nap/dev/example/public/stylesheets/sass/reset.sassComments
For future reference, it would be nice to just include the Sass code causing the error. In this case:
:focus outline: 0On second thought,
css2sassis also relevant here, since the code that should be generated is\:focus outline: 0But the point still remains: it would have been nice to just post the original CSS snippet causing the error, rather than referencing a document containing it.
[Sass] [css2sass] Automatically backslash-escape pseudo-classes.
Closed by 9e5a42a
[Sass] [css2sass] Automatically backslash-escape pseudo-classes.
Closed by 9e5a42a
-
The Rails XSS protection is applied twice (or more) when rendering a partial:
= render "my_partial"The string returned by render is not marked as html_safe?, so when HAML escapes it again. When I was playing with haml and rails XSS protection, I fixed that by adding this line: http://github.com/nono/haml/blob/rails_xss/lib/haml/precompiler.rb#L102. I'm sure you'll find a cleaner way to do that.
Comments
[Haml] Mark the return value of the Haml rendering method as HTML safe if XSS protection is enabled.
Closed by 60ab39b
-
0 votes
The Rails XSS protection doesn't work with Rails 2.3.5
2 comments Created 2 months ago by nonoPlugins are loaded after gems, so when haml (a gem) checks ActionView::Base.xss_safe?, it returns false (the rails 2.3.5 default value). After this, the rails_xss plugin is loaded and it modifies ActionView::Base.xss_safe? to return true, but it's too late.
Comments
-
1 vote
SASS Rails plugin broken due to RAILS_ROOT behaviour
3 comments Created 2 months ago by dbackeusHaml breaks current edge rails with error;
undefined method `first' for #<Pathname:/public/stylesheets/sass>This can be fixed by changing all the paths in sass/plugin/rails.rb from
RAILS_ROOT + '/public/stylesheets/sass'to"#{RAILS_ROOT}/public/stylesheets/sass"or even"#{Rails.root}/public/stylesheets/sass"sinceRAILS_ROOTis getting deprecated.Comments
There are various incompatibilities between Haml/Sass and Rails 3.0 that I'm going to focus on at once at some point in the future, but I'm going to let this sit for now. If you want to fork and create a fix, though (it should work with old and new Rails versions), I'll merge it in.
-
0 votes
1 comment Created 2 months ago by TwisolExtraneous spaces in tags with elements with an apostrophe in an attributeHamlxCompare the following two snippets of code.
%one %two %three %four{:attr => ""}This renders as:
<one> <two> <three> <four attr="'"></four> </three> </two> </one>This seems to be correct. The second snippet of code only adds a single apostrophe to the attribute:
%one %two %three %four{:attr => "'"}However, this renders as:
<one> <two> <three> <four attr="'"> </four> </three> </two> </one>There is extraneous spacing inside the 'four' tag, which seems to be equal to the indentation amount of the 'four' tag. Experimentation shows that the deeper into the nesting 'four' is, the more spaces crop up. This issue does not appear when using the parenthesized list () instead of the Ruby hash {}. I am using the Powerful Penny release with Ruby on Rails.
Comments
-
The Haml reference says "Literal textarea and pre tags automatically preserve their content." by converting newlines "to the XHTML whitespace escape code, ". However, during some experiments of mine, this doesn't seem correct.
%outer %pre 12345 12345The above Haml outputs as:
<outer>12345 12345</outer>(note: it appears Markdown isn't liking the pre tag up there. Would appreciate learning how to fix that.)
This is quite incorrect, both per the reference and per the display of the above code. The second line suffers from extra visible whitespace to the left.
This also applies to the textarea element, and likely whatever other elements Haml deems to be whitespace-sensitive. I am using the Poweful Penny release with Ruby on Rails.
Comments
-
If you write a similar construction:
-# Metatags -# Charset %meta{:charset => 'utf-8'} -# Keywords %meta{:name => 'keyword', :content => 'words'}get this html
<meta charset="utf-8"></meta> <meta name="keywords" content="words"></meta>
Meta should not have a closing tag
Comments
In Haml 2.2.8, this is the output I get:
<meta charset='utf-8'> </meta> <meta content='words' name='keyword' />This is the expected output. The first meta tag has content nested beneath it - namely, the comment. This causes Haml to render it as a content tag with the appropriate closing tag. The second met tag has no content, and so is self-closing.
The solution to this is to not indent the "Keywords" comment beneath the meta tag you don't want closed.
Your right.
I use html syntax but not xhtml. In w3c specification written: End tag: forbidden. Maybe make imposiible for end tag for meta element? -
I'm using haml 2.2.6, with the option html_escape activated.
I'm expecting that the two following lines are similar:
You & me You & #{'me'}But it's not the case. For the second line, the & is escaped, so the result is:
You &amp; meThe documentation seems to match my expectation (only the string inperpolation should be escaped), but maybe, it's the normal behaviour. In that case, can I suggest to make it clear in the doc?
Comments
-
%p This is a test of the multi-line | system. | %p This should be part of a separate p | element. |outputs:
<p>This is a test of the multi-line system. %p This should be part of a separate p element.</p>.While
%p This is a test of the multi-line | system. | %p This should be part of a separate p element.works correctly
Comments
This is intentional. Multi-line blocks are intentionally annoying to use, especially when you're using many in a row. This is because there's almost always a better solution. In this case, the text should be nested within the
ptags:%p This is no longer a test of the multi-line system. %p This should be part of a separate p element.The most common use-case of multiline blocks is for Ruby code. The annoyingness of multiline blocks in Haml remind developers that large blocks of Ruby code should almost always be moved into helpers, rather than placed in the view. This keeps your templates much cleaner and easier to read.
If you absolutely must have two multiline blocks in a row in a template, separate them with a comment:
%p This is a test of the multi-line | system. | -# %p This should be part of a separate p | element. | -
0 votes
Converting HTML to Haml doesn't work from TextMate due to problem in version.rb
1 comment Created 3 months ago by kjvargaI've submitted a pull request, but I'm opening this because my work mates also have the same problem and so it may be helpful to have more info on it out there.
My patch: http://github.com/kjvarga/haml/commit/5ef9b00176d97d9030200b4410f65087552067ae
When converting text in TextMate to Haml, you get an exception from vendor.rb (30) about not being able to find the VERSION file:
haml/version.rb:30:in `read': No such file or directory
The reason is because FILE as used in lib.rb in the scope() method is reported as:
/Users/karl/.gem/ruby/1.8/gems/haml-2.2.5/lib/haml/../haml.rb
Which is a relative path, so the File.dirname() calls don't end up at the Haml gem root as they should. I've created a simple patch to call File.expand_path(FILE) to make it absolute first.
Regards,
Karl
Comments
adamsalter
Mon Oct 05 18:56:20 -0700 2009
| link
This is fixed in 2.2.6
-
0 votes
3 comments Created 3 months ago by adamsalterhtml2haml could be a bit more descriptive if bad encoding found (ruby1.9)HamlxWould be nice if html2haml reported line numbers when failing on bad encodings, so that problems can be tracked down quicker.
Currently,
$ html2haml my_utf8_file.html my_utf8_file.haml => invalid byte sequence in UTF-8Comments
I think this is probably an Hpricot issue. I'll investigate further when I have a chance.
Nope, turns out it's not an Hpricot issue. It's going to be a little tricky to get decent error reporting going here, since we'll have to parse the string as binary to find the invalid characters, but I'll work on it.
-
HAML template files should be able to set the encoding for the file on the first line, similar to normal ruby. (or at least have some way of specifying the encoding per file.)
-# encoding: utf-8 %p Éat thís!Comments
adamsalter
Tue Sep 22 23:42:54 -0700 2009
| link
Come to think of it this would probably apply to Sass css as well ;)
In general, the template encoding is the responsibility of whatever's loading the template. When Haml's used as a plugin, it takes its templates as Ruby strings; the encoding of these strings is the responsibility of the caller.
The exception to this is the
hamlexecutable, which loads its own templates. If a convention emerges (that is, Rails comes up with a way) for specifying the encoding of the template, I'll update thehamlexecutable to respect that if possible.Sass is a different story, since it does load its own files. I've opened #40 specifically for Sass.
adamsalter
Wed Sep 23 04:48:39 -0700 2009
| link
is it possible to do a valid_encoding? (and report bad line no.) on the string before beginning template parsing?
-
0 votes
Not sure if this is an issue with HAML code or with the Rails code.
Rails: 2.3.4
Haml: 2.2.4A gist containing more information
The evil line from my template:
- form_for @user, :html => {:id => 'reset-password-end-form', :method => :put}, :url => password_reset_path do |f|The exact errors reported were:
/home/kojul/railsigti/app/views/password_resets/edit.haml:22: syntax error, unexpected kENSURE, expecting kEND /home/kojul/railsigti/app/views/password_resets/edit.haml:24: syntax error, unexpected $end, expecting kENDNote the error messages... my template is only 20 lines, so this occurs after some of it has been processed.
I knew I didn't mis-indent anything, so I went looking around and found nothing on the issue.
Figured it out though.Look at the id tag declaration... there's a "-end" in it. Changing it to "reset-passwordend-form" worked as did anything that didn't have specifically an "-end" in it.
It doesn't matter if it's the id tag either... it could be any tag and it just requires a "-end" in it to mess everything up.As I said at the top, I'm not sure if this is an issue with the form_for helper or with something within the HAML code itself.
Comments
-
Colors printed by SassScript when the output format is
:compressedshould be printed in the smallest possible format. This means the shortest of "#nnnnnn", "#nnn", and the HTML4 color name, depending on what's available.Comments
-
0 votes
calling sass functions within mixin arguments
3 comments Created 5 months ago by chriseppsteinIf you try to call a sass function as a mixin argument you get a syntax error.
Example:
=foo(!a) div :background-color = !a +foo(rgb(255,255,0))Comments
-
This sass:
h2 display:none font-weight:boldGenerates no error and no css.
Comments
chriseppstein
Sat Jul 18 10:46:09 -0700 2009
| link
Nevermind, these appear as valid selectors with no rules to the sass engine and so they get silently dropped.
-
1 vote
3 comments Created 5 months ago by chriseppsteinEasyxSupport rgba and hsla in script contextsSassxColor objects need an alpha layer and we need to build corresponding support for rgba() and hsla() functions.
Color objects that have 100% opacity shouldn't output as rgba(), of course.
Comments
chriseppstein
Sun Jul 19 13:27:24 -0700 2009
| link
Pretty well supported now.
-
0 votes
Sass: Syntax error when nesting functions as arguments to mixins
1 comment Created 5 months ago by chriseppstein -
Guys, I wrote the following markup:
%a(href="#") AllBut it is raising an error. I could fix that writing:
%a(href="\#") AllI had to escape the "#" character. I think that it is an error and maybe it's about a bad parsing in the interpolation feature. Maybe the parser is thinking that I am trying to interpolate something just because i used the "#" character. You could interpolate something just if it is inside a #{...}, and not when you find a #.
What do you think?
Comments
[Haml] Fix a bug with new attribute parsing.
Closed by 84670b2
hugobarauna
Mon Jul 20 12:03:33 -0700 2009
| link
Cool, thanks! =D
-
Reported here:
http://groups.google.com/group/compass-users/msg/f6360f7669651271?hl=enremoving the sass cache caused the bug to go away. The problem is due to the cached file referencing an import that no longer exists.
Comments
-
This Sass file
// Working comment @media screen, projection // Not working comment body color: greencauses this error:
/* NoMethodError: You have a nil object when you didn't expect it! You might have expected an instance of Array. The error occurred while evaluating nil.+ Backtrace: /Library/Ruby/Gems/1.8/gems/haml-2.1.0/lib/sass/tree/directive_node.rb:39:in `to_s' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/lib/sass/tree/directive_node.rb:21:in `each' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/lib/sass/tree/directive_node.rb:21:in `to_s' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/lib/sass/tree/node.rb:36:in `to_s' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/lib/sass/tree/node.rb:32:in `each' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/lib/sass/tree/node.rb:32:in `to_s' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/lib/sass/engine.rb:104:in `render' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/lib/sass/plugin.rb:75:in `update_stylesheet' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/lib/sass/plugin.rb:60:in `update_stylesheets' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/lib/sass/plugin.rb:55:in `each' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/lib/sass/plugin.rb:55:in `update_stylesheets' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/lib/sass/plugin.rb:53:in `each' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/lib/sass/plugin.rb:53:in `update_stylesheets' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/lib/sass/plugin/rails.rb:16:in `process' /Library/Ruby/Gems/1.8/gems/actionpack-2.3.2/lib/action_controller/base.rb:391:in `process' /Library/Ruby/Gems/1.8/gems/actionpack-2.3.2/lib/action_controller/base.rb:386:in `call' /Library/Ruby/Gems/1.8/gems/actionpack-2.3.2/lib/action_controller/routing/route_set.rb:433:in `call' /Library/Ruby/Gems/1.8/gems/actionpack-2.3.2/lib/action_controller/dispatcher.rb:88:in `dispatch' /Library/Ruby/Gems/1.8/gems/actionpack-2.3.2/lib/action_controller/dispatcher.rb:111:in `_call' /Library/Ruby/Gems/1.8/gems/actionpack-2.3.2/lib/action_controller/dispatcher.rb:82:in `initialize' /Library/Ruby/Gems/1.8/gems/activerecord-2.3.2/lib/active_record/query_cache.rb:29:in `call' /Library/Ruby/Gems/1.8/gems/activerecord-2.3.2/lib/active_record/query_cache.rb:29:in `call' /Library/Ruby/Gems/1.8/gems/activerecord-2.3.2/lib/active_record/connection_adapters/abstract/query_cache.rb:34:in `cache' /Library/Ruby/Gems/1.8/gems/activerecord-2.3.2/lib/active_record/query_cache.rb:9:in `cache' /Library/Ruby/Gems/1.8/gems/activerecord-2.3.2/lib/active_record/query_cache.rb:28:in `call' /Library/Ruby/Gems/1.8/gems/activerecord-2.3.2/lib/active_record/connection_adapters/abstract/connection_pool.rb:361:in `call' /Library/Ruby/Gems/1.8/gems/actionpack-2.3.2/lib/action_controller/vendor/rack-1.0/rack/head.rb:9:in `call' /Library/Ruby/Gems/1.8/gems/actionpack-2.3.2/lib/action_controller/vendor/rack-1.0/rack/methodoverride.rb:24:in `call' /Library/Ruby/Gems/1.8/gems/actionpack-2.3.2/lib/action_controller/params_parser.rb:15:in `call' /Library/Ruby/Gems/1.8/gems/actionpack-2.3.2/lib/action_controller/rewindable_input.rb:25:in `call' /Library/Ruby/Gems/1.8/gems/actionpack-2.3.2/lib/action_controller/session/cookie_store.rb:93:in `call' /Library/Ruby/Gems/1.8/gems/actionpack-2.3.2/lib/action_controller/reloader.rb:9:in `call' /Library/Ruby/Gems/1.8/gems/actionpack-2.3.2/lib/action_controller/failsafe.rb:11:in `call' /Library/Ruby/Gems/1.8/gems/actionpack-2.3.2/lib/action_controller/vendor/rack-1.0/rack/lock.rb:11:in `call' /Library/Ruby/Gems/1.8/gems/actionpack-2.3.2/lib/action_controller/vendor/rack-1.0/rack/lock.rb:11:in `synchronize' /Library/Ruby/Gems/1.8/gems/actionpack-2.3.2/lib/action_controller/vendor/rack-1.0/rack/lock.rb:11:in `call' /Library/Ruby/Gems/1.8/gems/actionpack-2.3.2/lib/action_controller/dispatcher.rb:106:in `call' /Library/Ruby/Gems/1.8/gems/rails-2.3.2/lib/rails/rack/static.rb:31:in `call' /Library/Ruby/Gems/1.8/gems/actionpack-2.3.2/lib/action_controller/vendor/rack-1.0/rack/urlmap.rb:46:in `call' /Library/Ruby/Gems/1.8/gems/actionpack-2.3.2/lib/action_controller/vendor/rack-1.0/rack/urlmap.rb:40:in `each' /Library/Ruby/Gems/1.8/gems/actionpack-2.3.2/lib/action_controller/vendor/rack-1.0/rack/urlmap.rb:40:in `call' /Library/Ruby/Gems/1.8/gems/rails-2.3.2/lib/rails/rack/log_tailer.rb:17:in `call' /Library/Ruby/Gems/1.8/gems/actionpack-2.3.2/lib/action_controller/vendor/rack-1.0/rack/content_length.rb:13:in `call' /Library/Ruby/Gems/1.8/gems/actionpack-2.3.2/lib/action_controller/vendor/rack-1.0/rack/chunked.rb:15:in `call' /Library/Ruby/Gems/1.8/gems/actionpack-2.3.2/lib/action_controller/vendor/rack-1.0/rack/handler/mongrel.rb:61:in `process' /Library/Ruby/Gems/1.8/gems/mongrel-1.1.5/lib/mongrel.rb:159:in `process_client' /Library/Ruby/Gems/1.8/gems/mongrel-1.1.5/lib/mongrel.rb:158:in `each' /Library/Ruby/Gems/1.8/gems/mongrel-1.1.5/lib/mongrel.rb:158:in `process_client' /Library/Ruby/Gems/1.8/gems/mongrel-1.1.5/lib/mongrel.rb:285:in `run' /Library/Ruby/Gems/1.8/gems/mongrel-1.1.5/lib/mongrel.rb:285:in `initialize' /Library/Ruby/Gems/1.8/gems/mongrel-1.1.5/lib/mongrel.rb:285:in `new' /Library/Ruby/Gems/1.8/gems/mongrel-1.1.5/lib/mongrel.rb:285:in `run' /Library/Ruby/Gems/1.8/gems/mongrel-1.1.5/lib/mongrel.rb:268:in `initialize' /Library/Ruby/Gems/1.8/gems/mongrel-1.1.5/lib/mongrel.rb:268:in `new' /Library/Ruby/Gems/1.8/gems/mongrel-1.1.5/lib/mongrel.rb:268:in `run' /Library/Ruby/Gems/1.8/gems/actionpack-2.3.2/lib/action_controller/vendor/rack-1.0/rack/handler/mongrel.rb:34:in `run' /Library/Ruby/Gems/1.8/gems/rails-2.3.2/lib/commands/server.rb:111 /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in `gem_original_require' /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in `require' ./script/server:3 */If the "Not working comment" is removed everything works fine and as expected.
Comments
-
0 votes
This css breaks css2sass [Stack level too deep]
2 comments Created 6 months ago by chriseppsteinComments
chriseppstein
Sat Jun 27 12:42:15 -0700 2009
| link
-
When there's empty line within mixin sass generates output code outside mixin instead of include it. Gem version haml-edge-2.1.33
Example:
=example_mixin :width 200px :height 200px .example_class :float leftOutput:
.example_class { float: left; } #example_id { width: 200px; height: 200px; }Instead of:
#example_id { width: 200px; height: 200px; } #example_id .example_class { float: left; }Comments
I can't reproduce this. Given input
=example_mixin :width 200px :height 200px .example_class :float left #example_id +example_mixinI get the expected output
#example_id { width: 200px; height: 200px; } #example_id .example_class { float: left; }This is with the latest master branch. What's your OS/Ruby version?
Just found that in environment.rb(in rails project) I used haml gem instead of haml-edge. After appropriate change everything working fine. So bug exists in stable branch - any chance to correct it?
-
0 votes
Comment Node value not picking up empty new lines
1 comment Created 6 months ago by richardadayIf I have a comment node that looks like:
/** This the first line. There is an empty line below me. This is the third lineAnd I do call .value on that CommentNode, I get this:
"This the first line. There is an empty line below me.\nThis is the third line"
instead of
"This the first line. There is an empty line below me.\n\nThis is the third line"
Comments
-
This should be legal:
http://gist.github.com/129758But results in the following error:
Syntax error on line 5: The line was indented 6 levels deeper than the previous line.Comments
-
0 votes
Compile error if you use a space in block arguments declaration
5 comments Created 6 months ago by caius/ Work fine %ul - array.each do |x| %li= x / Fails with a compile error %ul - array.each do | x | %li= xComments
This is expected - there's no good way to distinguish between the latter case and the multiline operator.
I've encountered this bug when switching to current version of haml (2.2.3). Haml 2.0.9 did not produce compile error on the line
- links.each do |href, text |and 2.2.3 does!
I believe current behavior violates the principle of least surprise ;-). Block args with spaces is perfectly normal in Ruby, should be also legal in haml, IMO.
If this feature could not be fixed for now, it is worth mentioning in the haml docs as a caveat
I'm pretty sure this happened in 2.0.9 as well:
~/code/haml (tags/2.0.9·)$ echo -e '- foo.each do |a, b |\n %p foo' | ./bin/haml Exception on line 2: compile error (haml):2: syntax error, unexpected ';', expecting '|' (haml):3: syntax error, unexpected kEND, expecting $end _hamlout.push_text("<p>foo</p>\n");end; ^ Use --trace for backtrace. ~/code/haml (tags/2.0.9·)$ ./bin/haml --version Haml 2.0.9.a4f0471I agree that this is a little surprising, but I'm not sure what to do about it, nor am I sure where it could be documented that people would see it.
A full code snippet that compiled with 2.0.9 has been like this:
:ruby links=[] #Actual content omitted - links.each do |href, text | %dt %a{:href=>"http://#{href}", :title=>text}=href %dd = textIt seems that preceding ruby filter interfered with the following haml processing. Just for the curious.
Concerning documentation, I may suggest adding a brief note into the section of haml reference which deals with multiline strings. Another good place may be the FAQ ?
That was a bug in the filter parsing code that caused multiline blocks not to get parsed immediately afterwards. It wasn't intended to work the way it did and wouldn't have in any other context.
Multiline blocks are already mentioned in the reference and in the FAQ.
-
Comments
atinypixel
Sat Jun 06 21:30:09 -0700 2009
| link
Okay, I figured out what the problem was. In my helpers I have to wrap everything in the capture_haml method. This wasn't clear in any documentation or the README. Can you please make these changes (and other major changes) apparent in the README for folks upgrading from 2.0.9?
It's always been an error to use the return value of
haml_tag. In previous versions, it worked by accident in some (but not all) cases, so we're removing that behavior in 2.2.0. It should throw an informative exception if the return value is used.I don't consider this a breaking change, since code that used
haml_tagin this way was already broken. I have added a note to thehaml_tagdocumentation clarifying the proper usage, though.Add a note to the haml_tag docs making it clear that it's invalid to use the return value.
Closed by 890614b
atinypixel
Sun Jun 07 21:18:31 -0700 2009
| link
Thanks a ton! That makes a lot more sense.
-
1 vote
Log:
Processing ApplicationController# (for ::1 at 2009-06-02 20:03:17) [GET]
Parameters: {"action"=>"index", "controller"=>"home"}ActionView::TemplateError (undefined method `filename' for #<ActionView::Template:0x3be5854>) in /Users/jonas/Development/jobbix/app/views/home/index.html.haml:
haml (2.1.0) [v] lib/haml/template/plugin.rb:15:in `compile' haml (2.1.0) [v] lib/sass/plugin/rails.rb:19:in `process' /opt/local/lib/ruby/1.8/webrick/httpserver.rb:104:in `service' /opt/local/lib/ruby/1.8/webrick/httpserver.rb:65:in `run' /opt/local/lib/ruby/1.8/webrick/server.rb:173:in `start_thread' /opt/local/lib/ruby/1.8/webrick/server.rb:162:in `start' /opt/local/lib/ruby/1.8/webrick/server.rb:162:in `start_thread' /opt/local/lib/ruby/1.8/webrick/server.rb:95:in `start' /opt/local/lib/ruby/1.8/webrick/server.rb:92:in `each' /opt/local/lib/ruby/1.8/webrick/server.rb:92:in `start' /opt/local/lib/ruby/1.8/webrick/server.rb:23:in `start' /opt/local/lib/ruby/1.8/webrick/server.rb:82:in `start'Comments
-
Assume the following source CSS:
div .warning { color: #d21a19; } span .debug { cursor: crosshair;} div .debug { cursor: default; }css2sass 2.1.0 results in:
div .warning :color #d21a19 .debug :cursor default span .debug :cursor crosshairOf course, this results in CSS like so:
div .warning { color: #d21a19; } div .debug { cursor: default; } span .debug { cursor: crosshair; }Since the selectors have the same specificity, order is important, and css2sass seems to prefer to nesting level over origin order. The sass produced should have been:
div .warning :color #d21a19 span .debug :cursor crosshair div .debug :cursor defaultComments
markdown mangled, meh. Hopefully the point is clear enough.
The specificity may be the same, but this is only a problem if a .debug-classed element exists within a span as well as a div...which of course, is not unheard of. I know this may not be an option for you, but this seems indicative of inadequately specific selectors.
Maybe css2sass should have a "strict" mode that preserves order exactly?
[Sass] Don't re-order rules in css2sass.
Closed by 08afa18
-
How about an config variable to define whether .css should be
@import'd or inlined? Or a way of indicating, in sass, whether an @import on a .css should be inlined rather than becoming a CSS @import?Comments
I'm not sure this is worth doing. It would make the semantics of
@import foo.cssreally confusing - right now, CSS files are never inlined, and Sass files always are. This means that it always refers to CSS files using their URLs, which will often not be the same as their actual paths in the filesystem. I think conflating the two would be more trouble than it's worth.Maybe @import shouldn't have such inconsistent behavior? Maybe replace @import with @inline, which will always try to inline the target file into the existing file, and @include, which will always try to link to the file externally. Making @import contingent upon the filetype of the target is inherently confusing.
At some point we're going to modify the semantics of
@importor (more likely) add a new directive that has different semantics. However, I don't think inlining raw CSS will be part of that; Sass does a lot of processing on the code before it's displayed (and will do more in the future) and mixing raw CSS up with all that is more of a headache than it's worth. Just usecss2sassand convert it if you want to include it. -
2 votes
Very obscure exception caused by special case line in SASS
2 comments Created 7 months ago by grimenThis is something that got introduced in 2.1.0, because I didn't have this issue before:
SASS:
:color transparent //:image url(../images/menu_gray_arrow.png) :image url(../images/navigation/menu_arrows_supplier.png)
Outputs in browser:
TypeError: can't convert nil into String
...and in the containing CSS:
/* TypeError: can't convert nil into String Backtrace: /Library/Ruby/Gems/1.8/gems/haml-2.1.0/rails/../lib/sass/tree/attr_node.rb:38:in `<<' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/rails/../lib/sass/tree/attr_node.rb:38:in `to_s' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/rails/../lib/sass/tree/attr_node.rb:37:in `each' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/rails/../lib/sass/tree/attr_node.rb:37:in `to_s' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/rails/../lib/sass/tree/rule_node.rb:77:in `to_s' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/rails/../lib/sass/tree/rule_node.rb:77:in `map' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/rails/../lib/sass/tree/rule_node.rb:77:in `to_s' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/rails/../lib/sass/tree/rule_node.rb:88:in `to_s' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/rails/../lib/sass/tree/rule_node.rb:87:in `each' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/rails/../lib/sass/tree/rule_node.rb:87:in `to_s' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/rails/../lib/sass/tree/rule_node.rb:88:in `to_s' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/rails/../lib/sass/tree/rule_node.rb:87:in `each' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/rails/../lib/sass/tree/rule_node.rb:87:in `to_s' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/rails/../lib/sass/tree/rule_node.rb:88:in `to_s' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/rails/../lib/sass/tree/rule_node.rb:87:in `each' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/rails/../lib/sass/tree/rule_node.rb:87:in `to_s' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/rails/../lib/sass/tree/rule_node.rb:88:in `to_s' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/rails/../lib/sass/tree/rule_node.rb:87:in `each' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/rails/../lib/sass/tree/rule_node.rb:87:in `to_s' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/rails/../lib/sass/tree/node.rb:36:in `to_s' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/rails/../lib/sass/tree/node.rb:32:in `each' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/rails/../lib/sass/tree/node.rb:32:in `to_s' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/rails/../lib/sass/engine.rb:104:in `render' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/rails/../lib/sass/plugin.rb:75:in `update_stylesheet' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/rails/../lib/sass/plugin.rb:60:in `update_stylesheets' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/rails/../lib/sass/plugin.rb:55:in `each' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/rails/../lib/sass/plugin.rb:55:in `update_stylesheets' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/rails/../lib/sass/plugin.rb:53:in `each' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/rails/../lib/sass/plugin.rb:53:in `update_stylesheets' /Library/Ruby/Gems/1.8/gems/haml-2.1.0/rails/../lib/sass/plugin/rails.rb:16:in `process' /Users/jonas/Development/m2m/jobbix/vendor/rails/actionpack/lib/action_controller/base.rb:391:in `process' /Users/jonas/Development/m2m/jobbix/vendor/rails/actionpack/lib/action_controller/base.rb:386:in `call' /Users/jonas/Development/m2m/jobbix/vendor/rails/actionpack/lib/action_controller/routing/route_set.rb:433:in `call' /Users/jonas/Development/m2m/jobbix/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:88:in `dispatch_without_newrelic' /Users/jonas/.gem/ruby/1.8/gems/newrelic_rpm-2.8.9/lib/new_relic/agent/instrumentation/dispatcher_instrumentation.rb:44:in `dispatch' /Users/jonas/Development/m2m/jobbix/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:111:in `_call' /Users/jonas/Development/m2m/jobbix/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:82:in `initialize' /Users/jonas/.gem/ruby/1.8/gems/rack-1.0.0/lib/rack/head.rb:9:in `call' /Users/jonas/.gem/ruby/1.8/gems/rack-1.0.0/lib/rack/head.rb:9:in `call' /Users/jonas/.gem/ruby/1.8/gems/rack-1.0.0/lib/rack/methodoverride.rb:24:in `call' /Users/jonas/Development/m2m/jobbix/vendor/rails/actionpack/lib/action_controller/params_parser.rb:15:in `call' /Users/jonas/Development/m2m/jobbix/vendor/rails/actionpack/lib/action_controller/rewindable_input.rb:25:in `call' /Users/jonas/Development/m2m/jobbix/vendor/rails/actionpack/lib/action_controller/session/abstract_store.rb:122:in `call' /Users/jonas/Development/m2m/jobbix/vendor/rails/activerecord/lib/active_record/query_cache.rb:29:in `call' /Users/jonas/Development/m2m/jobbix/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb:34:in `cache' /Users/jonas/Development/m2m/jobbix/vendor/rails/activerecord/lib/active_record/query_cache.rb:9:in `cache' /Users/jonas/Development/m2m/jobbix/vendor/rails/activerecord/lib/active_record/query_cache.rb:28:in `call' /Users/jonas/Development/m2m/jobbix/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb:361:in `call' /Users/jonas/Development/m2m/jobbix/vendor/rails/actionpack/lib/action_controller/reloader.rb:9:in `call' /Users/jonas/Development/m2m/jobbix/vendor/rails/actionpack/lib/action_controller/failsafe.rb:11:in `call' /Users/jonas/.gem/ruby/1.8/gems/rack-1.0.0/lib/rack/lock.rb:11:in `call' /Users/jonas/.gem/ruby/1.8/gems/rack-1.0.0/lib/rack/lock.rb:11:in `synchronize' /Users/jonas/.gem/ruby/1.8/gems/rack-1.0.0/lib/rack/lock.rb:11:in `call' /Users/jonas/Development/m2m/jobbix/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:106:in `call' /Users/jonas/Development/m2m/jobbix/vendor/rails/railties/lib/rails/rack/static.rb:31:in `call' /Users/jonas/.gem/ruby/1.8/gems/rack-1.0.0/lib/rack/urlmap.rb:46:in `call' /Users/jonas/.gem/ruby/1.8/gems/rack-1.0.0/lib/rack/urlmap.rb:40:in `each' /Users/jonas/.gem/ruby/1.8/gems/rack-1.0.0/lib/rack/urlmap.rb:40:in `call' /Users/jonas/Development/m2m/jobbix/vendor/rails/railties/lib/rails/rack/log_tailer.rb:17:in `call' /Users/jonas/.gem/ruby/1.8/gems/rack-1.0.0/lib/rack/content_length.rb:13:in `call' /Users/jonas/.gem/ruby/1.8/gems/rack-1.0.0/lib/rack/chunked.rb:15:in `call' /Users/jonas/.gem/ruby/1.8/gems/rack-1.0.0/lib/rack/handler/mongrel.rb:61:in `process' /Library/Ruby/Gems/1.8/gems/mongrel-1.1.5/lib/mongrel.rb:159:in `process_client' /Library/Ruby/Gems/1.8/gems/mongrel-1.1.5/lib/mongrel.rb:158:in `each' /Library/Ruby/Gems/1.8/gems/mongrel-1.1.5/lib/mongrel.rb:158:in `process_client' /Library/Ruby/Gems/1.8/gems/mongrel-1.1.5/lib/mongrel.rb:285:in `run' /Library/Ruby/Gems/1.8/gems/mongrel-1.1.5/lib/mongrel.rb:285:in `initialize' /Library/Ruby/Gems/1.8/gems/mongrel-1.1.5/lib/mongrel.rb:285:in `new' /Library/Ruby/Gems/1.8/gems/mongrel-1.1.5/lib/mongrel.rb:285:in `run' /Library/Ruby/Gems/1.8/gems/mongrel-1.1.5/lib/mongrel.rb:268:in `initialize' /Library/Ruby/Gems/1.8/gems/mongrel-1.1.5/lib/mongrel.rb:268:in `new' /Library/Ruby/Gems/1.8/gems/mongrel-1.1.5/lib/mongrel.rb:268:in `run' /Users/jonas/.gem/ruby/1.8/gems/rack-1.0.0/lib/rack/handler/mongrel.rb:34:in `run' /Users/jonas/Development/m2m/jobbix/vendor/rails/railties/lib/commands/server.rb:111 /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in `gem_original_require' /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in `require' script/server:3 */ body:before { white-space: pre; font-family: monospace; content: "TypeError: can't convert nil into String"; }Works:
SASS:
:color transparent :image url(../images/navigation/menu_arrows_supplier.png)
I don't see why this line is any different than any other commented lines, i.e. leading @//@?
Comments
This actually goes deeper than that, the comment @//@ is messed up in HAML 2.1.0. Example:
Works:
.box //:color black :border :style solidDon't work:
.box :border //:color black :style solidIn other words...comments are no longer allowed to be a child to a element with leading @:@. This can't be a new feature...rather a newly introduced bug.
-
0 votes
Haml doesn't work properly with encoding under Passenger and Ruby 1.9.1
20 comments Created 8 months ago by deepjHi,
I'm getting very strange issue under above configuration. The similar issue was reported on Passenger's issue tracker but it was selected as invalid (I don't know why).I can't locate where the issue is :(
ArgumentError in Home#index Showing app/views/home/index.html.haml where line # raised: invalid byte sequence in US-ASCII Extracted source (around line #): RAILS_ROOT: /mnt/hgfs/test Application Trace | Framework Trace | Full Trace /usr/local/lib/ruby/gems/1.9.1/gems/haml-2.0.9/lib/haml/engine.rb:88:in `initialize' /usr/local/lib/ruby/gems/1.9.1/gems/haml-2.0.9/lib/haml/template/plugin.rb:21:in `new' /usr/local/lib/ruby/gems/1.9.1/gems/haml-2.0.9/lib/haml/template/plugin.rb:21:in `compile' /usr/local/lib/ruby/gems/1.9.1/gems/actionpack-2.3.2/lib/action_view/template_handler.rb:11:in `call' /usr/local/lib/ruby/gems/1.9.1/gems/actionpack-2.3.2/lib/action_view/renderable.rb:19:in `compiled_source' /usr/local/lib/ruby/gems/1.9.1/gems/actionpack-2.3.2/lib/action_view/renderable.rb:70:in `compile!' /usr/local/lib/ruby/gems/1.9.1/gems/actionpack-2.3.2/lib/action_view/renderable.rb:61:in `compile' /usr/local/lib/ruby/gems/1.9.1/gems/actionpack-2.3.2/lib/action_view/renderable.rb:28:in `render' /usr/local/lib/ruby/gems/1.9.1/gems/actionpack-2.3.2/lib/action_view/template.rb:194:in `render_template' /usr/local/lib/ruby/gems/1.9.1/gems/actionpack-2.3.2/lib/action_view/base.rb:260:in `render' /usr/local/lib/ruby/gems/1.9.1/gems/haml-2.0.9/lib/haml/helpers/action_view_mods.rb:14:in `render_with_haml' /usr/local/lib/ruby/gems/1.9.1/gems/actionpack-2.3.2/lib/action_controller/base.rb:1241:in `render_for_file' /usr/local/lib/ruby/gems/1.9.1/gems/actionpack-2.3.2/lib/action_controller/base.rb:937:in `render' /usr/local/lib/ruby/gems/1.9.1/gems/actionpack-2.3.2/lib/action_controller/benchmarking.rb:51:in `block in render_with_benchmark' /usr/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.2/lib/active_support/core_ext/benchmark.rb:17:in `block in ms' /usr/local/lib/ruby/1.9.1/benchmark.rb:308:in `realtime' /usr/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.2/lib/active_support/core_ext/benchmark.rb:17:in `ms' /usr/local/lib/ruby/gems/1.9.1/gems/actionpack-2.3.2/lib/action_controller/benchmarking.rb:51:in `render_with_benchmark' /usr/local/lib/ruby/gems/1.9.1/gems/actionpack-2.3.2/lib/action_controller/base.rb:1317:in `default_render' /usr/local/lib/ruby/gems/1.9.1/gems/actionpack-2.3.2/lib/action_controller/base.rb:1323:in `perform_action' /usr/local/lib/ruby/gems/1.9.1/gems/actionpack-2.3.2/lib/action_controller/filters.rb:617:in `call_filters' /usr/local/lib/ruby/gems/1.9.1/gems/actionpack-2.3.2/lib/action_controller/filters.rb:610:in `perform_action_with_filters' /usr/local/lib/ruby/gems/1.9.1/gems/actionpack-2.3.2/lib/action_controller/benchmarking.rb:68:in `block in perform_action_with_benchmark' /usr/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.2/lib/active_support/core_ext/benchmark.rb:17:in `block in ms' /usr/local/lib/ruby/1.9.1/benchmark.rb:308:in `realtime' /usr/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.2/lib/active_support/core_ext/benchmark.rb:17:in `ms' /usr/local/lib/ruby/gems/1.9.1/gems/actionpack-2.3.2/lib/action_controller/benchmarking.rb:68:in `perform_action_with_benchmark' /usr/local/lib/ruby/gems/1.9.1/gems/actionpack-2.3.2/lib/action_controller/rescue.rb:160:in `perform_action_with_rescue' /usr/local/lib/ruby/gems/1.9.1/gems/actionpack-2.3.2/lib/action_controller/flash.rb:141:in `perform_action_with_flash' /usr/local/lib/ruby/gems/1.9.1/gems/actionpack-2.3.2/lib/action_controller/base.rb:523:in `process' /usr/local/lib/ruby/gems/1.9.1/gems/actionpack-2.3.2/lib/action_controller/filters.rb:606:in `process_with_filters' /usr/local/lib/ruby/gems/1.9.1/gems/haml-2.0.9/lib/sass/plugin/rails.rb:19:in `process' /usr/local/lib/ruby/gems/1.9.1/gems/actionpack-2.3.2/lib/action_controller/base.rb:391:in `process' /usr/local/lib/ruby/gems/1.9.1/gems/actionpack-2.3.2/lib/action_controller/base.rb:386:in `call' /usr/local/lib/ruby/gems/1.9.1/gems/actionpack-2.3.2/lib/action_controller/routing/route_set.rb:433:in `call'
Every file has utf-8 encoding.
When I run this website under the webrick it works fine.
Comments
I don't think this is a Haml issue. It's likely to be a problem with Rails. Haml doesn't deal with loading files at all.
deepj, you need to tell the ruby-binary that you are using utf8. Passenger does not send environment-variables through to ruby.
Creating a 'fake' ruby-bin, and making
phusion use that worked:Create something like ruby_utf8 in /usr/local/bin/ or the place you have your binaries.
It should contain:
#!/bin/bash exec /usr/local/bin/ruby -E utf-8:utf-8 "$@"When pointing phusion to this instead of the regular ruby bin, everything works :)
somebee: It seems too complicated. If your solution works, then Encoding.default_internal = Encoding.default_external = "utf-8" in your config.ru must also works.
Hi somebee, thanks for you advice but I'm afraid it doesn't work for me. I acted upon your instruction.
-rwxr-xr-x 1 root root 57 2009-04-20 17:37 ruby_utf8 deepj@popelnice:/usr/local/bin$ cat ruby_utf8 #!/bin/bash exec /usr/local/bin/ruby -E utf-8:utf-8 "$@"
My apache configuration:
deepj@popelnice:~$ cat /etc/apache2/sites-available/test ServerName test.local DocumentRoot /home/deepj/www/test/public PassengerRuby /usr/local/bin/ruby_utf8 RailsEnv development ...Hi Somebee,
your solution works so I'm sorry to you :) I didn't noticed PassengerRuby option may only occur once :) Very thx for your advice :)
adamsalter
Mon Oct 26 18:39:13 -0700 2009
| link
I'm getting something like this as well... I'm hesitant to open a new bug because it's so hard to track down.
As nex3 said HAML only uses strings, but the exact same code works with erb. I think it has something to do with the string being created in ASCII-8BIT and then passed on to Rails.
I notice that Rails has a
# encoding: utf-8setting on a ActionView file which has no 'strange' characters, this could be to ensure that the string is the right encoding at creation time. I think HAML is possibly seeing the same problem. But as I said, it is sooo hard to track down.http://github.com/rails/rails/blob/2-3-stable/actionpack/lib/action_view/renderable.rb#L1
The exact error i'm getting is:
ActionView::TemplateError (incompatible character encodings: ASCII-8BIT and UTF-8) on line <a href="/nex3/haml/issues/#issue/9" class="internal">#9</a> of app/views/artists/bio.html.haml: app/views/artists/bio.html.haml:9:in `_run_haml_app47views47artists47bio46html46haml' haml (2.2.9) lib/haml/helpers/action_view_mods.rb:14:in `render_with_haml' haml (2.2.9) lib/haml/helpers/action_view_mods.rb:14:in `render_with_haml' haml (2.2.9) lib/sass/plugin/rails.rb:19:in `process' compass (0.8.17) lib/compass/app_integration/rails/action_controller.rb:7:in `process_with_compass' <internal:prelude>:8:in `synchronize' passenger (2.2.5) lib/phusion_passenger/rack/request_handler.rb:95:in `process_request' passenger (2.2.5) lib/phusion_passenger/abstract_request_handler.rb:207:in `main_loop' passenger (2.2.5) lib/phusion_passenger/railz/application_spawner.rb:378:in `start_request_handler' passenger (2.2.5) lib/phusion_passenger/railz/application_spawner.rb:336:in `block in handle_spawn_application' passenger (2.2.5) lib/phusion_passenger/utils.rb:183:in `safe_fork' passenger (2.2.5) lib/phusion_passenger/railz/application_spawner.rb:334:in `handle_spawn_application' passenger (2.2.5) lib/phusion_passenger/abstract_server.rb:352:in `main_loop' passenger (2.2.5) lib/phusion_passenger/abstract_server.rb:196:in `start_synchronously' passenger (2.2.5) lib/phusion_passenger/abstract_server.rb:163:in `start' passenger (2.2.5) lib/phusion_passenger/railz/application_spawner.rb:213:in `start' passenger (2.2.5) lib/phusion_passenger/spawn_manager.rb:262:in `block (2 levels) in spawn_rails_application' passenger (2.2.5) lib/phusion_passenger/abstract_server_collection.rb:126:in `lookup_or_add' passenger (2.2.5) lib/phusion_passenger/spawn_manager.rb:256:in `block in spawn_rails_application' passenger (2.2.5) lib/phusion_passenger/abstract_server_collection.rb:80:in `block in synchronize' <internal:prelude>:8:in `synchronize' passenger (2.2.5) lib/phusion_passenger/abstract_server_collection.rb:79:in `synchronize' passenger (2.2.5) lib/phusion_passenger/spawn_manager.rb:255:in `spawn_rails_application' passenger (2.2.5) lib/phusion_passenger/spawn_manager.rb:154:in `spawn_application' passenger (2.2.5) lib/phusion_passenger/spawn_manager.rb:287:in `handle_spawn_application' passenger (2.2.5) lib/phusion_passenger/abstract_server.rb:352:in `main_loop' passenger (2.2.5) lib/phusion_passenger/abstract_server.rb:196:in `start_synchronously'
adamsalter
Mon Oct 26 18:39:50 -0700 2009
| link
Haml 2.2.9, Rails 2.3.4, Ruby 1.9.1p243, Mac OSX
Adam, can you reproduce this reliably on your machine? If so, I could give you some debugging monkeypatches to see if we can collectively figure out what's going on...
adamsalter
Thu Oct 29 21:41:16 -0700 2009
| link
I think now it's a mixture of problems:
I have another bug raised here, and honglai comes to the same conclusion:
http://code.google.com/p/phusion-passenger/issues/detail?id=404
in irb:
>> "http://localhost/posts/eeé".encode('ASCII-8BIT') Encoding::UndefinedConversionError: "\xC3\xA9" from UTF-8 to ASCII-8BIT from (irb):7:in `encode' from (irb):7 from /opt/local/bin/irb:12:in `<main>'This looks wrong, since ASCII-8BIT is essentially binary, which should allow any conversion.
I also can get errors with passenger and HAML, but not ./script/server and HAML, and strings are encoded differently in HAML than ERB.
in ERB (with both Passenger and WEBrick):
<%= "é".encoding %> => ASCII-8BITin HAML (with WEBrick)
= "é".encoding => UTF-8in HAML (with Passenger) it gets an error trying to read the HAML file itself, since it was expecting US-ASCII, and é is not valid US-ASCII.
ActionView::TemplateError (invalid byte sequence in US-ASCII) in app/views/albums/show.html.haml: haml (2.2.9) lib/haml/engine.rb:101:in `split' haml (2.2.9) lib/haml/engine.rb:101:in `initialize' haml (2.2.9) lib/haml/template/plugin.rb:21:in `new' haml (2.2.9) lib/haml/template/plugin.rb:21:in `compile' haml (2.2.9) lib/haml/helpers/action_view_mods.rb:13:in `render_with_haml' haml (2.2.9) lib/haml/helpers/action_view_mods.rb:13:in `render_with_haml' app/controllers/albums_controller.rb:18:in `show' haml (2.2.9) lib/sass/plugin/rails.rb:19:in `process' compass (0.8.17) lib/compass/app_integration/rails/action_controller.rb:7:in `process_with_compass' <internal:prelude>:8:in `synchronize' passenger (2.2.5) lib/phusion_passenger/rack/request_handler.rb:95:in `process_request' passenger (2.2.5) lib/phusion_passenger/abstract_request_handler.rb:207:in `main_loop' passenger (2.2.5) lib/phusion_passenger/railz/application_spawner.rb:378:in `start_request_handler' passenger (2.2.5) lib/phusion_passenger/railz/application_spawner.rb:336:in `block in handle_spawn_application' passenger (2.2.5) lib/phusion_passenger/utils.rb:183:in `safe_fork' passenger (2.2.5) lib/phusion_passenger/railz/application_spawner.rb:334:in `handle_spawn_application' passenger (2.2.5) lib/phusion_passenger/abstract_server.rb:352:in `main_loop' passenger (2.2.5) lib/phusion_passenger/abstract_server.rb:196:in `start_synchronously' passenger (2.2.5) lib/phusion_passenger/abstract_server.rb:163:in `start' passenger (2.2.5) lib/phusion_passenger/railz/application_spawner.rb:213:in `start' passenger (2.2.5) lib/phusion_passenger/spawn_manager.rb:262:in `block (2 levels) in spawn_rails_application' passenger (2.2.5) lib/phusion_passenger/abstract_server_collection.rb:126:in `lookup_or_add' passenger (2.2.5) lib/phusion_passenger/spawn_manager.rb:256:in `block in spawn_rails_application' passenger (2.2.5) lib/phusion_passenger/abstract_server_collection.rb:80:in `block in synchronize' <internal:prelude>:8:in `synchronize' passenger (2.2.5) lib/phusion_passenger/abstract_server_collection.rb:79:in `synchronize' passenger (2.2.5) lib/phusion_passenger/spawn_manager.rb:255:in `spawn_rails_application' passenger (2.2.5) lib/phusion_passenger/spawn_manager.rb:154:in `spawn_application' passenger (2.2.5) lib/phusion_passenger/spawn_manager.rb:287:in `handle_spawn_application' passenger (2.2.5) lib/phusion_passenger/abstract_server.rb:352:in `main_loop' passenger (2.2.5) lib/phusion_passenger/abstract_server.rb:196:in `start_synchronously'As I said it's fully repeatable. If you want any more information just let me know.
adamsalter
Thu Oct 29 21:46:52 -0700 2009
| link
I can also make HAML with WEBrick crash the same as Passenger with HAML (using a string from the database) by doing:
= "é" => ActionView::TemplateError (incompatible character encodings: ASCII-8BIT and UTF-8) on line \#9 of app/views/artists/bio.html.haml:This seems to be trying to convert the UTF-8 string to ASCII-8BIT in the template code.
adamsalter
Mon Nov 02 21:20:11 -0800 2009
| link
Just letting you know I can get erb working with the patch from this ticket:
Unfortunately, I tried changing the HAML plugin code to match:
lib/haml/template/plugin.rb:21
source.force_encoding('utf-8') if '1.9'.respond_to?(:force_encoding) Haml::Engine.new(source, options).send(:precompiled_with_ambles, [])and I still get the same error.
Hi Adam,
can you try the following trick?Encoding.default_internal = 'utf-8' Encoding.default_external = 'utf-8'
You just need to put this code into environment.rb before this line:
require File.join(File.dirname(__FILE__), 'boot')
adamsalter
Tue Nov 03 16:58:20 -0800 2009
| link
deepj,
That does not work for me.
My rack seems to crash with:
[2009-11-04 11:56:13] ERROR NoMethodError: You have a nil object when you didn't expect it! You might have expected an instance of Array. The error occurred while evaluating nil.each /Users/adam/.gem/ruby/1.9.1/gems/rack-1.0.1/lib/rack/utils.rb:196:in `initialize' /Users/adam/.gem/ruby/1.9.1/gems/rack-1.0.1/lib/rack/content_length.rb:14:in `new' /Users/adam/.gem/ruby/1.9.1/gems/rack-1.0.1/lib/rack/content_length.rb:14:in `call' /Users/adam/.gem/ruby/1.9.1/gems/rack-1.0.1/lib/rack/handler/webrick.rb:50:in `service' /opt/local/lib/ruby1.9/1.9.1/webrick/httpserver.rb:111:in `service' /opt/local/lib/ruby1.9/1.9.1/webrick/httpserver.rb:70:in `run' /opt/local/lib/ruby1.9/1.9.1/webrick/server.rb:183:in `block in start_thread' Error during failsafe response: "\xC3" from ASCII-8BIT to UTF-8
adamsalter
Tue Nov 03 16:59:53 -0800 2009
| link
The only reliable fix I have found is to have a encoding helper:
def encode_ascii_8bit(text) text.respond_to?(:force_encoding) ? text.force_encoding('ASCII-8BIT') : text endAnd wrap all offending elements.
Right now I'm working on fixing some edge Rails incompatibilities and a very annoying error line numbering bug that just cropped up - I'd like to fix at least the former and get Haml 2.2.11 out this weekend. After that, I'll devote some serious cycles to trying to figure out what's going on here, and with luck find and release a fix for 2.2.12 the weekend after.
Sorry Adam, I forgot to mention you need to add # encoding: utf-8 to your controllers too.
# encoding: utf-8 class YourController < ApplicationController end
This works for me.
Since apparently it didn't get automatically linked, I've tracked this down and come as close as possible to a fix in 76bd406. Here's the content of the commit message:
This is a complicated issue, but I'll do my best to explain it here. By default, Haml encodes its templates as Encoding.default_internal, which is usually UTF-8. This means that strings printed to the template should be either UTF-8 or UTF-8-compatible ASCII. So far, all well and good.
Now, it's possible to have strings that are marked as ASCII-8bit, but which aren't UTF-8 compatible. This includes valid UTF-8 strings that are forced into an ASCII-8bit encoding. If one of these strings is concatenated to a UTF-8 string, Ruby says "I don't know what to do with these non-ASCII characters!" and throws an encoding error. I call this sort of string "fake ASCII."
This is what was happening in the referenced GitHub issue (or at least in the sample app Adam Salter created at http://github.com/adamsalter/test-project/tree/haml_utf8). The template was UTF-8 encoded, and it was being passed a fake ASCII string, marked as ASCII-8bit but with UTF-8 byte sequences in it, and it was choking.
The issue now becomes: where is this fake ASCII string coming from? From the database. The database drivers used by Rails aren't Ruby 1.9 compatible. Despite storing UTF-8 strings in the database, the drivers return fake ASCII strings.
The best solution to this is clearly to fix the database drivers, but that will probably take some time. One stop-gap would be to call
force_encoding("utf-8")on all the database values somewhere, which is still a little annoying. Finally, the solution provided in this commit is to set:encoding => "ascii-8bit"for Haml. This makes the Haml template itself fake ASCII, which is wrong but will help prevent encoding errors.
adamsalter
Sun Nov 08 16:59:22 -0800 2009
| link
Nathan,
Don't you think the best fix would be for Ruby1.9/Rails to include a encoding converter ASCII-8BIT <=> UTF-8?
If Rails included this then it would fix all the rails issues anyway.
Clearly UTF-8 to ASCII-8BIT is a no-op, it's essentially the same as using force_encoding, but ASCII-8BIT to UTF-8 would mean that you could depend on all data to be valid UTF-8. It would really make life so much easier.
Anyway thanks for the commit. I think it should fix the immediate issues.I think that would just be a band-aid. The real issue is that you've got UTF-8 strings that aren't marked as UTF-8, and that's what needs to be fixed.
adamsalter
Sun Nov 08 18:20:08 -0800 2009
| link
Yes, I think I see. But I think the DB adapters don't want to actually use UTF-8 because of the many encoding/re-encoding potential problems, so they just accept/return ASCII-8BIT. If there was a converter, you could be sure that a UTF-8 string was really UTF-8, to and from the db, and rack, and Rails.
Would that mean that we have to use Iconv for all data going into the database? Really this should happen at the adapter level I guess. Then they could return UTF-8 (or chosen encoding) reliably.
I personally think that an encoding converter between UTF-8 and ASCII-8BIT would solve all of Rails' problems. I kind of wish it could be included in Ruby1.9, but I'm not sure that that is likely. -
0 votes
:javascript filter breaks #{local} variables
3 comments Created 8 months ago by alexgorbatchevon haml 2.0.9
require 'haml/engine' template_broken = ' :javascript - [1, 2, 3, 4].each do |item| = "Hey #{item}" ' puts Haml::Engine.new(template_broken).to_htmlcauses
(haml):3:in `to_html': undefined local variable or method `item' for #<Object:0x2bedf64> (NameError) from c:/ruby/lib/ruby/gems/1.8/gems/haml-2.0.9/lib/haml/engine.rb:149:in `to_html' from c:/ruby/lib/ruby/gems/1.8/gems/haml-2.0.9/lib/haml/engine.rb:149:in `instance_eval' from c:/ruby/lib/ruby/gems/1.8/gems/haml-2.0.9/lib/haml/engine.rb:149:in `to_html' from haml.rb:9however, this works just fine. notice that I replaced :javascript filter with regular %script tag.
require 'haml/engine' template_broken = ' %script - [1, 2, 3, 4].each do |item| = "Hey #{item}" ' puts Haml::Engine.new(template_broken).to_htmlComments
You're misunderstanding the Javascript filter. Like other Haml filters, it doesn't take Haml code; it takes Javascript code. For example:
:javascript function foo() { return "bar"; }
alexgorbatchev
Sun Apr 19 15:46:56 -0700 2009
| link
Have I missed this somewhere in the doc? It seems odd that I can't generate output inline for a filter. Is this a technical limitation or by design? Think I saw something about scope issues in HAML code comments...
This is by design. You can put Ruby code in a filter using
#{}, like so::javascript var rails_version = #{Rails::VERSION::STRING.to_json}but you can't use Haml constructs like "-" and "=". The purpose of filters is to allow non-Haml languages, like Javascript, to be embedded within Haml.
-
1 vote
Universal Interpolation... lines should be allowed to start with #
2 comments Created 8 months ago by merbjediWith the universal interpolation implementation, I very often like to start the line with #{} in order to add stuff to the end.
For example
.contact_info #{person.name}'s Address Something else...This currently fails.
Would be very nice if the precompiler could recognize #{ as a starting character and switch the line mode to normal interpolation ("==" style).
Comments
First of all, this is not the right way to put lots of text in the document. You should nest the text beneath the paragraph tag, like so:
Multiline is meant for long blocks of Ruby code.
Second, this is the expected behavior. Like everywhere else in Haml, empty lines are ignored in multiline blocks. It's difficult to put multiple multiline blocks together side-by-side precisely because you shouldn't be doing that in general. See this FAQ question. If you insist on having multiple multiline blocks in a row, you need to separate them with a comment (
-#).