I have a site running with compass-rails and sass-rails. Since the 3.2 update, I get EOFErrors all over the place calling compass functions. Is Sass 3.2 incompatible with compass?
I'm seeing this too when I use Pow. The EOFError appears to occur when you do an @include.
/Users/jeremy/Library/Application Support/Pow/Versions/0.4.0/node_modules/nack/lib/nack/server.rb:97:in `read_nonblock'
/Users/jeremy/Library/Application Support/Pow/Versions/0.4.0/node_modules/nack/lib/nack/server.rb:97:in `block (2 levels) in start'
/Users/jeremy/Library/Application Support/Pow/Versions/0.4.0/node_modules/nack/lib/nack/server.rb:86:in `each'
/Users/jeremy/Library/Application Support/Pow/Versions/0.4.0/node_modules/nack/lib/nack/server.rb:86:in `block in start'
/Users/jeremy/Library/Application Support/Pow/Versions/0.4.0/node_modules/nack/lib/nack/server.rb:66:in `loop'
/Users/jeremy/Library/Application Support/Pow/Versions/0.4.0/node_modules/nack/lib/nack/server.rb:66:in `start'
/Users/jeremy/Library/Application Support/Pow/Versions/0.4.0/node_modules/nack/lib/nack/server.rb:13:in `run'
/Users/jeremy/Library/Application Support/Pow/Versions/0.4.0/node_modules/nack/bin/nack_worker:4:in `<main>'
I've also find this issue, and I find that sass-3.2.0.alpha.278 doesn't have this issue, but all release after sass-3.2.0.alpha.291 will.
Since there's not any tags for alpha release, I have to copy two hash tags from the released gem. Here's the compare view:
I also wanted to confirm that the issue happens only happens for me when running on pow. When running rails s, I do not get the issue. In earlier alpha releases, everything worked fine on pow but upon changing to 3.2.0 final, I get the EOFError.
I also have this issue running Pow 0.4.0
Same here, I tried downgrading with gem 'sass', '3.2.0.alpha.278', but still have the EOF issue.
Reverting to the suggested '3.2.0.alpha.278' worked for me and I'm using Pow 4.0 also
Yep, been seeing this with pow since upgrading over the weekend, have switched to just using webrick for now but would really like a fix that doesn't mean I have to roll back and get slammed with that annoying 'sass is splitting from haml' notice every five seconds.
This is a sass issue or pow issue?
I have a very similar issue but not with pow.. instead with capybara's thin server which means my selenium tests are failing when it tries to compile a css.scss asset on the fly. Reverting to 3.2.0.alpha.278 works fine again. This is only happening on ruby 1.8.7 and only when I run tests - precompiling assets works fine because it's not trying to load thin. I'll investigate further but wanted to note this here.
According to my bisect 0394886 is the first bad commit
If I remove this ensure block then my problem goes away: 0394886#L4R69
Can anybody else reproduce that?
For extra information this happens when I have a manifest file inside a Rails application that uses require (Sprockets method) and I'm getting a LoadError that is being seemingly trapped by this code because the raise comes from sass and not the application (which I'm guessing in turn makes Sprockets trap it). Here's the code that is running inside capybara: https://github.com/jnicklas/capybara/blob/master/lib/capybara.rb#L177-L186 (when it requires the thin handler for rack and tries to rescue the LoadError but sass takes over with the ensure)
Lock to sass 3.1.12 so that tests pass.
They fail on 3.2.0 because of sass/sass#482
I believe c0fba44 should fix this, but I haven't been able to reproduce it to confirm. Can someone here check if it is indeed fixed? You can install 3.3.0.alpha.2 to check.
Don't handle unintended exceptions in perform_arguments.
My stylesheets compile again using 3.3.0.alpha.2. Thanks!
@nex3 How about include this on a 3.2.1 release?
Closing since c0fba44 is confirmed to fix this.
I have same error, because I run gem update. Rollback sass gem version from 3.2.0 to 3.1.19. Fixed ~
@hpyhacking Or upgrade to 3.2.1 or 3.3.0.alpha.3.
Upgrading SASS to 3.2.1 fixed this issue for me, thanks for the hard work!