Can you post the relevant bits of the files to a gist and link it here, from this description I can't diagnose the issue.

You got it! http://gist.github.com/247826

I had to move the comment, but once I did that I get the following:

$ compass
   exists stylesheets
  compile src/skin_black.sass
   create stylesheets/skin_black.css

$ compass -v
Compass 0.10.0 [2465bab]
Copyright (c) 2008-2009 Chris Eppstein
Released under the MIT License.

As you can see, it works fine. Perhaps you can tell me more about your environment? Are you using compass stand alone or with another framework?

I'm going to see if I can reproduce it without my crazy huge files.

Chris, I found the problem. For some reason I had a vine.sass and a vine.sass that were identical. They were both importing default.sass so when I saw the error I didn't realize it was being generated from vine.sass. I removed vine.sass and everything is right in the world again.

Sorry to bug you!

glad you got it sorted out.

Thanks. I'll get that into the next release.

[Blueprint] Bug Fix: variable referenced in a non-script context within the dquo mixin in the fancy_type module. Closed by 5f32043.

fixed.

fixed by f1bb236

fixed. turns out you couldn't effectively set any boolean property to false.

Interesting. Aren't these the same?

I thought they were the same too until just now. I changed it from 1em to 1 in firebug and saw the computed line-height change from 12px to 24px which is what I had expected. Learn something new every day.

fixed. Thanks for the patch.

I was thinking about this just yesterday - I'll second this motion.

I will talk to nathan about whether this is a sass or compass bug.

If the configuration file changes, wipe out the sass cache and force
compilation. Closed by 3bb5e6d.

Just to be sure: this is not a Sass bug, correct?

Not a sass bug. When the configuration changes, there's no way for Sass to know that the function calls will generate different results. At first, I thought this bug and the one related to line_comments might be related via a root cause in sass, but no.

What version of compass?

Well, I have compass 0.8.17 installed globally, but from the traceback it appears to be using the git checkout I'm in, not the global gem. The checkout is from here http://github.com/ericam/compass/tree/edge (testing Eric's Susy example); based on a checkout of your edge as of this morning.

Eek. the issue is that I'm using a form of Array#index that only exists in ruby 1.8.7+

I pushed a change to my edge branch

http://gemcutter.org/gems/compass

Wow lovely ! (I had tried chriseppstein-compass)

I close this issue, it's not a bug.
config option is used to load a file and not create one… I'm stupid >_>

Well, I uninstalled haml deleting the haml/init.rb and did the rake rails:template ... command again and this time it installed.
So, just a note for me to remember and might b for someone in future.

I also encountered this problem. The fix works but it is also unclear to me why. I believe it might have something to do with the new Dir.glob method in 1.9

Fix a bug in FSSM for ruby 1.9. Closed by bad615e.

Fixed by 772a58d and e744c1e

[Compass Core] The enumerate function now accepts an optional argument to specify the separator. Closed by e0732c8.

Fixed. Please grab the latest versions of compass and the 960 plugin.

This change should be part of the v0.10 release.

016c911
63795c8

too

fixed in v0.10

That change was introduced as part of the v0.9.1 release of blueprint. Compass is currently at v0.9.0. I would like to update to blueprint v0.9.1 as part of the compass v0.10 release. If you'd like to help with that effort, let me know. I'll file a separate issue for the v0.9.1 upgrade.

This was recently brought up on the mailing list.

I will add it for the next release. Thanks!

fixed in 0.8.13 -- just released.

You're correct. That line is not needed. That it shows up is a bug.

I've fixed it on edge about a week ago and it will go out with the next release. Thanks for the report.

This was fixed in v0.8.12.

Fixed in 0.8.13. Just released.

I can confirm this issue is resolved.

That the +inline-block mixin doesn't work on block elements in IE6 & 7 is a known issue. If someone gives a well tested solution that works across a broad array of both inline and block elements, I will accept that patch.

However, I would encourage you to revisit the choice to use a block level element, in many cases a span is more semantically correct for an inline-block based layout.

please test my fix that was posted to the newsgroup.

=inline-block 
  :display -moz-inline-box 
  :-moz-box-orient vertical 
  :display inline-block 
  :vertical-align middle 
  :#zoom 1 
  :#display inline 
  // fixes alignment against native input/button on IE6 
  :#vertical-align auto

This implementation was also posted:

=inline-block
  :display -moz-inline-box
  :-moz-box-orient vertical
  :display inline-block
  :vertical-align middle
  :#display inline
  // fixes alignment against native input/button on IE6
  :#vertical-align auto

Can someone please explain why the :#zoom 1 style is needed or not?

I found this post on the subject. They use conditional comments to target IE < 8, is that what the # hack does?

rules with # will target IE6+7. rules with * will target IE6, but not 7. IE8 seems to have significantly more sane support of CSS in general... not only do the old hacks not work, but most of the time they aren't needed either.

as for the version you post second... the zoom is there to trigger hasLayout engine. inline-block in IE6+7 just triggers hasLayout for inline elements. you can achieve the exact same effect without using inline-block by making it display inline and then triggering hasLayout (like with zoom). that's why the hack works on both inline and block level elements, whereas inline-block in IE6+7 will only work for inline elements.

ah, i see what you mean with that post. what happens there only happens because it's in two separate css blocks. the first block sets it to inline-block, which triggers hasLayout. the second block sets it back to display inline, without un-triggering haslayout because it's done in a separate block. if it was one rule, that would not work. it would instead ignore the inline-block and use the inline statement... never triggering hasLayout.

in short, you can do without the zoom part only if you're using multiple css rules to do it. it our situation, this is not the case. you need the zoom.

Using & in our mixin will allow us to generate two selectors that are the same. I use this trick in the +clearfix mixin. But it seems with any complex selector that would result in more generated css, not less.

chris - use whatever technique you believe to be the most elegant solution. personally... i cheat. i cheat like crazy. i cheat either by using a rails plugin or dojo to add css classes to the html element representing what browser the client claims to be, what os, etc. it lets me avoid css hacks entirely without using conditional comments (which i would not be able to use to target firefox2, for example). it's unfortunate that such a solution is out of the scope of what sass, and compass, could provide. i mean... it makes the selectors themselves more specific, so you could theoretically run into problems. dojo's own inline-block hack is pretty much the same as the one i posted, without the additional firefox2 fix, so as to avoid css specificity issues.

I'm not looking for elegance. Just trying to find a reasonable balance in this effed up world of hacks that we live in. Thank you for your contribution and explanation. I think adding a class to the document body that indicates browser is a nice solution, but not general purpose enough.

I've merged a fix for this into my local edge. It will be part of the v0.10 release.

grrrrr. Yes, that should write the file in binary mode...

Fixed in v0.8.10

I received a report that this bug still exists. Can you confirm or deny?

Now that we have Bundler, I think I can just make compass do a basic require of haml and leave what to load to the user...

Actually, this one is still just a css class that is scoped by a paragraph... I changed the markup.

Fixed here:
http://github.com/merbjedi/compass/commit/ad0cbee36bdc084871648705f3bd2203e3bbed78

merged to edge for the next release.

fixed in v0.8.9

With a better fix in 0.10.0 coming.

ok thanx ;)

I'm also getting these issues... Ruby 1.9.1p0
How long do we expect until this gets fixed?

Hi, I fixed my problem and pushed up to my own master fork http://github.com/priit/compass/tree/master (I made fork only for fixing this bug). By the way, the fix are already pulled to chriseppstein edge branch, so you can use edge or my temporary master branch. Cheers!

I release the fix for this in v0.8.12. Please let me know if you're having any more issues with ruby 1.9.1

seems to be working fine. sass files generate no problems.

:-D Great!

One less ruby 1.9.1 bug to deal with ;)

... Actually it all works pretty well: db drivers - 'kwatch/mysql-ruby' and 'qooba/sqlite3-ruby' being major needed updates. ... and tempfile problem with passenger: http://www.taylorluk.com/articles/2009/08/12/ruby-19-and-passenger

Anyway cheers, ;)

I've had several reports that compass does work on windows. Please indicate the steps to reproduce this issue. What command are you running? What version of windows? Steps you followed to install compass?

Thanks

Hi, thanks for your feedback.

I finally spent some more time on this issue and find out a solution:

* Got to install ImageMagick manually (important: mark "add ImageMagick to system path" during install)
* You have to install RMagik gem manually on windows instructions a there http://rmagick.rubyforge.org/

best regards, Alex

closing. Hopefully google will help people find this issue if it affects them. Feel free to edit the wiki as you feel is appropriate.

I think you need to upgrade. I fixed the bug a while ago and cannot reproduce it using Compass 0.8.7 [9aa9867]

$ compass --version
Compass 0.8.8 [6ae3f9a]
$ mkdir test
$ cd test
$ rails test
$ cd test
$ compass --rails -f blueprint .
...
Congratulations! Your rails project has been configured to use Compass.
Sass will automatically compile your stylesheets during the next
page request and keep them up to date when they change.
Make sure you restart your server!

Next add these lines to the head of your layouts:

%head
  = stylesheet_link_tag 'compiled/screen.css', :media => 'screen, projection'
  = stylesheet_link_tag 'compiled/partials/_base.css'
  = stylesheet_link_tag 'compiled/print.css', :media => 'print'
  /[if lt IE 8]
    = stylesheet_link_tag 'compiled/ie.css', :media => 'screen, projection'

(You are using haml, aren't you?)

This is fixed in edge already and will go out with the next release.

http://github.com/chriseppstein/compass/commit/7b28e9af4ab70b995239158a8c6a809c76184fa0

It's pretty easy to make a new project using an existing setup:

mkdir new_project
cp old_project/config.rb new_project/config.rb
cd new_project
compass -f blueprint --install

Perhaps an example should be added to command line wiki page.

Regarding the project registry and related commands, I feel this might be too much complexity. A simple bash script could accomplish the same. Maybe I don't understand the use case...

http://github.com/ttilley is currently working on some multi-project thing called sassinator. Maybe it will meet your needs when he releases it into the wild.

I posted a revised forms.html.haml to the Compass google groups that should be useful for testing this once fixed. HTH.

That file is now part of the compass/examples/blueprint_default example. Now we just need a fix ;-)

Sorry it has taken me so long to get around to this but I've finally taken some time to look into these issues. It seems that the inline form mixin wasn't getting applied to form.inline in the example, so I've fixed that in the master branch of my fork.

This fixes the alignment of all of the elements except for the submit button, which for some reason is way up. I haven't been able to track it down but it's probably outside of _form.sass, since _form.sass doesn't contain any styles that directly affect the button. =(

Is there any update to this?

I haven't been able to solve it yet and I currently can't allocate time to look into it further. >_<

I applied Enrico's patch and then I poked around for a while. It's very strange. I can't find any CSS difference that matters. But I did find that I could make it render correctly if I added a non-breaking space.

http://github.com/chriseppstein/compass/commit/81942836d095a7a82fb4ddc966bb40eea6b9345b

I think it looks pretty good. If this issue is troubling others enough for them to find the root cause, I'd be happy to accept their patch/fix in any form.

There's a similar comment in the compass implementation file, but perhaps one here would be more useful.

Indeed :)
Anyway, I don't which file you're mentioning, I don't see anything like that in frameworks/blueprint/_ie.sass ?

It's here:
http://github.com/chriseppstein/compass/blob/f8987b816531e2e9bc64c7a24e0c82d9ef34bfff/frameworks/blueprint/stylesheets/blueprint/modules/_grid.sass#L71

But your way is better.

merged. thanks.

oops, sorry. this is a dupe of #26

Compass will continue to default to haml-edge if it is installed, but I will change the behavior to printing out a message only when it is used, not when it is missing.

Load haml-edge if it's all new and shiny. Closed by 59a6067.

[Blueprint] Fixed a bug in the calculations for the +colborder mixin. Closed by d2b1370.

you have to run rake examples and it will build them for you.

ok thanks :)

What version of haml do you have installed? This is likely because you have haml 2.0 and not 2.2 or haml-edge.

Yeah, I figured that out, but forgot to close this issue.

This feature is available in 0.8.

Sorry, this message was suposed to have a label #feature, but I don't know how to apply labels for messages. Perhaps is because I don't have permission.

I just realized that I can configure this on the "config.rb" file. Sorry. I didn't saw anything about the config.rb file in the wiki. Closing this message.

[Sass Extensions] Allow the asset host and cache busting strategies to be defined as part of the compass configuration. Closed by ef47f3d.

Only happens if project is not initialized

fixed in 0.8

Thanks for filing this. I wasn't sure if there was already a way to override and I was just being dense.

I've created a patch here:
http://github.com/tdreyno/compass/commit/9b1f32bd9c9a147eab9e7030eb6c02bbee630a07

However, I don't actually agree with the concept. In my opinion, Compass should not contain any defaults and users would just use Sass normally to inject the colors and sizes like normal. The problem is, that's not how Blueprint is designed. It's designed to automatically have a very solid starting place for sites. This means sites using Blueprint with CSS have a lot of duplication thus the need for Sass & Compass in the first place.

I guess the defaults that are intrinsic to Blueprint muddle up the philosophy of Sass. Hopefully this patch makes people happy, but I can't help but think the increasing complexity is turning Compass into it's own weird language which will need more and more documentation as time goes on.

I agree. The main stylesheet provided by compass if you don't specify a framework is a reset and an empty file.

New frameworks built on Sass from the ground up are already under development and will be much more elegant to use. The compass core framework, tries to provide simple, basic mixins that are common patterns -- not anything that would make a site look presentable out of the box.

Thanks for the work, your thoughts on the matter are well founded, and your effort here is helpful.

There are also issues trying to override a:visited since it is set in the framework.

Perhaps a way to filter out rules on import?

@import foo.sass remove:"css selectors here"

right now I would have to fork the blueprint framework in order to fix this.

Or perhaps a rake task to "pull a snapshot of the framework into my app/stylesheets/framework" then I can tweak and periodically update if needed.

Overriding is easy, it's resetting or removing unwanted styles that's a hassle. I hate to inject more stuff into Sass itself, but maybe a - (minus) prefix to match the + (plus) prefix which removes information from the compiler's view of the sass structure. Obviously, I have no idea if that's even possible with the way Sass is implemented.

I knew I should have waited until the morning to post - I mean removing a:visited

Overriding is the way to go. The Sass compiler can trivially remove the duplication from the generated css in a future version. Maybe that should have been my response to the original request as well...

Fixed by b84dd30

instead of doing this:

@import blueprint.sass
+blueprint

I do this

@import blueprint/modules/grid.sass
@import blueprint/modules/utilities.sass
@import compass/reset.sass

+blueprint-utilities
+blueprint-grid

@beyoumedia is right, you can and should use the sub-mixins if you don't want ALL of blueprint

I suppose I should mention that the commit (in my fork) that fixes this is http://github.com/marnen/compass/commit/36f83511383fdd02be58b0a596a53080b0cb3861 .

I am having no issues with Safari 4. Perhaps you're mistaking !x and !y for the !width and !height (as in your patch), when they are actually for positioning the background image.

Works here: http://www.quicksnapper.com/files/9241/5712114684A3983E08A53A.png

Additionally, it seems quite easy to add width/height to the selector in the normal Sass fashion (I always do this) than to add more variables to the mixin.

You're right that I was a bit confused about the function of the !x and !y parameters, but even when I omitted them entirely, replace-text didn't work. I'll test again and report if anything changes.

Setting height and width and using 0 for !x and !y seems to have done the trick. I guess I'll just wrap that all in my own convenience function. Thanks for your advice here.

I added more comments to the mixin in the code.

after some tests, i found the problem is when the Compass try to touch the file (when detect identical content), after comment the line of touch the scripts runs without problems. The solution maybe is to create a touch implementation to deal with this problem.

It would be good if there was a patch that fixes this issue on windows that I could then test on unix based systems. I don't have easy access to windows.

The ruby implementation is supposed to work on windows. I'd like to have this bug reproduced by others before taking any action. Are you sure you don't have permission or some other issue that's causing the EACCESS error to be able to modify the file.

The issue is that, per
https://prototype.lighthouseapp.com/projects/8888/tickets/16-permission-denied-building-via-sprockets-on-windows, /> File.utime (called by touch) can't be run against a file that's
already open on Windows. I've created a patch that uses IO.read()
instead of File.new().read() to read in the existing file so that it
gets closed properly.

Patch at http://gist.github.com/140766

Fixed.

The plan is to host the stable gem there and the development gem on github. The account is a placeholder until I get around to it. Maybe I can do it for the 0.8 release.

Github gems are no more. I've since learnt that you can create 'prerelease' gems with a special version string:

http://rubygems.rubyforge.org/rdoc/Gem/Version.html

I'm changing all my old github gems back to normal syntax... ERROR: could not find gem compass locally or in a repository ;)

You could move it to Gemcutter instead. It should be a bit easier, and it seems like Gemcutter might take over gem hosting from Rubyforge.

The compass gem is already on gemcutter:

http://gemcutter.org/gems/compass

This is where I'll posting new releases.

Sorry, I see what the problem was now. I was trying to install 0.8.15, which does not exist on gemcutter. When I upped the version number everything worked.

I just did a gem install:

$ gem install haml-edge
Successfully installed haml-edge-2.1.16

That worked. Thanks. I guess then, the install doco needs to be updated to say this.

haml edge is hosted on rubyforge, some older versions of gem don't handle cross-server dependencies. By adding http://gems.github.com/ to you gem server list and not specifying --source for the gem install, you should have installation success. We should update the wiki and blog posts to reflect this, so I'm going to leave this issue open until they do.

I added http://gems.github.com/ to my gem server list, and I actually get

gem install haml-edgeERROR: could not find gem haml-edge locally or in a repository

Not sure whats going on.

haml edge is hosted on rubyforge. compass is hosted on github.

I have:

$ gem sources
*** CURRENT SOURCES ***

http://gems.rubyforge.org/
http://gems.github.com/

$ sudo gem install haml-edge --no-ri
Successfully installed haml-edge-2.1.24
1 gem installed
Installing RDoc documentation for haml-edge-2.1.24...

I don't have enough details to diagnose your issue.

I think this works, closing.

I can confirm this too. I just rebuild edge (0.6.12) to make sure I wasn't using an old version.

Btw, is there a way to add a patch to these issues?

I have already sent a pull request for http://github.com/marcenuc/compass/commits/5868c2e4e19ff2b0d12e326aaa6961f6674575ef

Fixed in 0.6.13.

Looks like it was a haml versioning problem afterall. I removed some older installs and regenerated the compass files and it works now.

I assume your running a rails application environment. It's not "best practice" to check in your generated css in such environments. But assuming you do not agree with me, I still think it's incredibly dangerous to run with a different version of haml in development than in production. I recommend that you either freeze your haml-edge gem in vendor or install it in your production environment. Existing apps will be unaffected by the presence of the haml-edge gem, but compass will pick it up if it sees it.

I, too, look forward to the next stable release of haml so that we can simplify the dependencies. Hopefully it will be soon.

If you're only using compass in development, you can also do two other things:
1. Use compass in standalone mode without the rails integration. In an existing rails project, you can just delete the config/initializers/compass.rb and then run compass --watch to compile your stylesheets.
2. Conditionally run compass by wrapping the contents of config/initializers/compass.rb in a block that checks the current rails environment.

Thank you for the suggestions, I really appreciate it. I like the idea of Compass but if it depends on an edge version of something else and that dependency causes deployment problems then Compass isn't something that I would depend on in production. So thanks for the suggestions for ways to use it during development only. I solved my deployment problem by removing Compass from the project, since I don't have the option of removing the Haml gem from the deployment environment. If I continue to tinker with Compass then I'll just use it in development to trigger Sass. I do like that --watch feature.

You can reproduce the problem very easily. "gem install haml" Then try to run that sample Rails app. If you have both haml and haml-edge then Compass will load haml and then complain that it requires haml 2.1. If you have the ability to totally control what gems are installed in your production environment then that's no problem but Compass won't work on hosting environments that provide Haml and then don't let you mess with your GEM_PATH. That sounds like a niche thing but Dreamhost is one of those hosts and they're popular enough to be relevant.

I explicitly tested the case of having both gems installed, but I will retest. It shouldn't break if both are there and if that's the case, then a patch will be forthcoming. If it's not reproducible in a simple app with just haml and compass installed, then there must be something else that is requiring haml. Can you show me what your gem configuration in your environement looks like? It could be that you're setting the dependency incorrectly and causing the wrong version to get picked up.

I really appreciate your assistance, I know that you're a busy guy. I'm trying to repay Karma by contributing my own gem to the world for doing layouts, which will be compatible with Compass.

To start out my day today, I decided to add Compass back into that problem project that has to go to Dreamhost, to help you to troubleshoot any possible haml/haml-edge incompatibility. I re-ran compass --rails to add config/compass.config and config/initializers/compass.rb, and it WORKED. It deploys to the problem server and it runs. ZOMG now I'm so confused.

I think you can maybe mark this issue closed because I think maybe I was totally wrong. I'm going to continue tinkering with it today to try to reproduce the haml/haml-edge incompatibility that caused me so much grief last night.

Either way, Compass is really neat. Thank you for making it and for releasing it so that I can use it.

I agree that a change would be useful here to control the scoping of LI for nested lists. Please see my comment for more details.

Here's another try. Check out http://github.com/marnen/compass/blob/cf9050857adee8770d4b3a2a92322293c2ddc25d/frameworks/compass/stylesheets/compass/utilities/lists/_horizontal_list.sass .

[Compass Core] Extracted two new mixins from +horizontal-list. Closed by faadde2. The new +horizontal-list-container and +horizontal-list-item mixins can
be used to build your horizontal list when you need more control over
the selectors (E.g. when working with nested lists).

Thanks for your patches, but I decided to fix this using a different approach altogether This approach gives more control to the user when the default mixin doesn't work.

[Command Line] Store sass cache files in the sass directory of the project. Closed by fcdaf41.

Will be part of the 0.8 release.

More clear licensing. Closed by 99f608e.

Please double check that you are running the latest version of haml. If it still happens, please post the full stack trace

Here's what I get.

C:\>haml -v
Haml 2.0.9

C:\>compass -f blueprint sample-project --trace
directory sample-project/
directory images/
directory src/
directory stylesheets/
   create config.rb
   create screen.sass
   create print.sass
   create ie.sass
   create grid.png
   exists stylesheets
  compile ie.sass
ArgumentError on line 18 of C: marshal data too short
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/files.rb:18:in `tree_for'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/file_node.rb:19:in `perform!'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:73:in `_perform'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:61:in `perform'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:82:in `perform_children'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:82:in `map'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:82:in `perform_children'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/file_node.rb:20:in `perform!'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:73:in `_perform'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:61:in `perform'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:82:in `perform_children'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:82:in `map'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:82:in `perform_children'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/file_node.rb:20:in `perform!'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:73:in `_perform'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:61:in `perform'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:82:in `perform_children'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:82:in `map'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:82:in `perform_children'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/file_node.rb:20:in `perform!'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:73:in `_perform'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:61:in `perform'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:82:in `perform_children'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:82:in `map'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:82:in `perform_children'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:78:in `perform!'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:73:in `_perform'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:61:in `perform'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/tree/node.rb:39:in `render'
  C:/Ruby/lib/ruby/gems/1.8/gems/haml-edge-2.1.8/lib/sass/engine.rb:108:in `render'
  C:/Ruby/lib/ruby/gems/1.8/gems/chriseppstein-compass-0.6.6/lib/compass/actions.rb:68:in `compile'
  C:/Ruby/lib/ruby/gems/1.8/gems/chriseppstein-compass-0.6.6/lib/compass/compiler.rb:37:in `run'
  C:/Ruby/lib/ruby/gems/1.8/gems/chriseppstein-compass-0.6.6/lib/compass/compiler.rb:36:in `each'
  C:/Ruby/lib/ruby/gems/1.8/gems/chriseppstein-compass-0.6.6/lib/compass/compiler.rb:36:in `run'
  C:/Ruby/lib/ruby/gems/1.8/gems/chriseppstein-compass-0.6.6/lib/compass/commands/update_project.rb:19:in `perform'
  C:/Ruby/lib/ruby/gems/1.8/gems/chriseppstein-compass-0.6.6/lib/compass/commands/stamp_pattern.rb:19:in `perform'
  C:/Ruby/lib/ruby/gems/1.8/gems/chriseppstein-compass-0.6.6/lib/compass/commands/base.rb:15:in `execute'
  C:/Ruby/lib/ruby/gems/1.8/gems/chriseppstein-compass-0.6.6/lib/compass/commands/project_base.rb:19:in `execute'
  C:/Ruby/lib/ruby/gems/1.8/gems/chriseppstein-compass-0.6.6/lib/compass/exec.rb:197:in `do_command'
  C:/Ruby/lib/ruby/gems/1.8/gems/chriseppstein-compass-0.6.6/lib/compass/exec.rb:57:in `perform!'
  C:/Ruby/lib/ruby/gems/1.8/gems/chriseppstein-compass-0.6.6/lib/compass/exec.rb:40:in `run!'
  C:/Ruby/lib/ruby/gems/1.8/gems/chriseppstein-compass-0.6.6/bin/compass:8
  C:/Ruby/bin/compass:19:in `load'
  C:/Ruby/bin/compass:19

Compass requires edge haml (version > 2.1). You can install it from source, or using the "haml-edge" gem. Instructions are on the wiki.

[Rails] Don't set the output style in the compass.config file for rails projects. It will default according to the runtime environment. Closed by 7b90aef.

This is a Sass bug that has been fixed. You need to upgrade to haml-edge:

sudo gem uninstall haml
sudo gem install haml-edge

I have both running actually... will this mess with my environment if I don't use haml-edge for other projects but use haml? I guess I'm not clear on the diff btwn these releases...

You can just download and install the latest from haml's master branch, that is what haml-edge is. Compass will try to pick up haml-edge if it's installed, but YMMV.

Yes, I've seen this bite people a couple of times now. I'll make a fix.

Print a message when updating a project that has no files. They probably meant to install but forgot the directory argument. Closed by 15ebbfe.

I agree, the blueprint grids are overflow happy, & setting to hidden is not always the desired effect. Can this be abstracted out into a mixin unto itself?

This property was added in blueprint 0.8 and I don't fully understand what it is trying to achieve. My goal is to have the blueprint port stay as true to blueprint proper as makes sense. I'm not inclined to make a change just to silence a validation error that is valid in css3 and likely harmless in css2 (browsers discard properties they don't understand).

What, if any, real issue does this cause?

Ok. I waited 5 days for further comments. Closing this issue.