sass --watch not working at all anymore

[TheDutchCoder]

I'm unsure how it happened, but since today sass doesn't watch files/folders anymore, instead it only updates files once on launch and then does nothing.

At first I thought it was an issue with my mapped network drive (Z:), but even running it totally local doesn't work.

I re-installed sass, even tried the alpha build, but to no avail.

Some details:
Windows 7 64-bit
sass-3.2.0.alpha.104 / sass-3.1.16
Command ran: sass --watch test.scss:test.css --style expanded

I had to install the devkit to get listen to work in the first place, but that didn't help either.
I'm getting a little frustrated in all honesty, as sass didn't work that well "out of the box" for me (like no listening, only polling) and now it doesn't do anything for (in my opinion) no reason ;-)

[TheDutchCoder]

Additional info:

After reinstalling sass (removing all other installed gems, except the default ones), I now get a big ruby crash:
C:/Ruby193/lib/ruby/1.1.1/find.rb:49: [BUG] Segmentation fault

With a huge stack trace (which I can't copy here, sorry)

[nex3]

@reinierk Can you provide the non-confidential portion of the segfault stack trace?

@Maher4Ever If this is happening with 3.2.0.alpha.104, that means that it includes your patch. Any insight as to why --watch might still not be working?

[TheDutchCoder]

@nex3 I reinstalled the whole thing and the error disappeared, so it might have had something to do with a crippled Ruby install on my end. Let's forget it for now (as I can't reproduce it anymore).

Also, I don't get the fallback message anymore (so it "pretends" it's actually listening the file, but "listen" is not installed (as it doesn't get installed with sass, using RubyInstaller on Windows)). This is extremely weird and confusing as sass should at least fallback to polling, instead of doing nothing at all.

Is there anything else I can do to help you resolve this?

[TheDutchCoder]

Okay, here's what happens after some seconds/minutes

C:\Users\Reinier>sass --watch C:\home.scss:C:\home.css --style expanded
>>> Sass is watching for changes. Press Ctrl-C to stop.
  overwrite C:\home.css
Errno::EACCES: Permission denied - C:/Users/Reinier/AppData/Local/Google/Chrome/User Data/Default/Current Session
  Use --trace for backtrace.

Access denied in a Chrome Session folder... How does that have to do with sass?? ;-)

I'll trace it and paste it for you as well, hold on...

[nex3]

I have no idea why it would be accessing a chrome folder. What happens when you pass --trace?

[TheDutchCoder]

Still waiting for it to crash ;-) I'll paste the trace when it happens.

[TheDutchCoder]

Here you go:

C:\Users\Reinier>sass --watch C:\home.scss:C:\home.css --style expanded --trace
>>> Sass is watching for changes. Press Ctrl-C to stop.
  overwrite C:\home.css
C:/Ruby/lib/ruby/1.9.1/digest.rb:44:in `initialize': Permission denied - C:/Users/Reinier/ntuser.dat.LOG1 (Errno::EACCES)
        from C:/Ruby/lib/ruby/1.9.1/digest.rb:44:in `open'
        from C:/Ruby/lib/ruby/1.9.1/digest.rb:44:in `file'
        from C:/Ruby/lib/ruby/1.9.1/digest.rb:29:in `file'
        from C:/Ruby/lib/ruby/gems/1.9.1/gems/sass-3.2.0.alpha.104/vendor/listen/lib/listen/directory_record.rb:199:in `content_modified?'
        from C:/Ruby/lib/ruby/gems/1.9.1/gems/sass-3.2.0.alpha.104/vendor/listen/lib/listen/directory_record.rb:152:in `block in detect_modifications_
and_removals'
        from C:/Ruby/lib/ruby/gems/1.9.1/gems/sass-3.2.0.alpha.104/vendor/listen/lib/listen/directory_record.rb:137:in `each'
        from C:/Ruby/lib/ruby/gems/1.9.1/gems/sass-3.2.0.alpha.104/vendor/listen/lib/listen/directory_record.rb:137:in `detect_modifications_and_remov
als'
        from C:/Ruby/lib/ruby/gems/1.9.1/gems/sass-3.2.0.alpha.104/vendor/listen/lib/listen/directory_record.rb:143:in `block in detect_modifications_
and_removals'
        from C:/Ruby/lib/ruby/gems/1.9.1/gems/sass-3.2.0.alpha.104/vendor/listen/lib/listen/directory_record.rb:137:in `each'
        from C:/Ruby/lib/ruby/gems/1.9.1/gems/sass-3.2.0.alpha.104/vendor/listen/lib/listen/directory_record.rb:137:in `detect_modifications_and_remov
als'
        from C:/Ruby/lib/ruby/gems/1.9.1/gems/sass-3.2.0.alpha.104/vendor/listen/lib/listen/directory_record.rb:143:in `block in detect_modifications_
and_removals'
        from C:/Ruby/lib/ruby/gems/1.9.1/gems/sass-3.2.0.alpha.104/vendor/listen/lib/listen/directory_record.rb:137:in `each'
        from C:/Ruby/lib/ruby/gems/1.9.1/gems/sass-3.2.0.alpha.104/vendor/listen/lib/listen/directory_record.rb:137:in `detect_modifications_and_remov
als'
        from C:/Ruby/lib/ruby/gems/1.9.1/gems/sass-3.2.0.alpha.104/vendor/listen/lib/listen/directory_record.rb:116:in `block in fetch_changes'
        from C:/Ruby/lib/ruby/gems/1.9.1/gems/sass-3.2.0.alpha.104/vendor/listen/lib/listen/directory_record.rb:114:in `each'
        from C:/Ruby/lib/ruby/gems/1.9.1/gems/sass-3.2.0.alpha.104/vendor/listen/lib/listen/directory_record.rb:114:in `fetch_changes'
        from C:/Ruby/lib/ruby/gems/1.9.1/gems/sass-3.2.0.alpha.104/vendor/listen/lib/listen/multi_listener.rb:109:in `block in fetch_records_changes'
        from C:/Ruby/lib/ruby/gems/1.9.1/gems/sass-3.2.0.alpha.104/vendor/listen/lib/listen/multi_listener.rb:106:in `each'
        from C:/Ruby/lib/ruby/gems/1.9.1/gems/sass-3.2.0.alpha.104/vendor/listen/lib/listen/multi_listener.rb:106:in `inject'
        from C:/Ruby/lib/ruby/gems/1.9.1/gems/sass-3.2.0.alpha.104/vendor/listen/lib/listen/multi_listener.rb:106:in `fetch_records_changes'
        from C:/Ruby/lib/ruby/gems/1.9.1/gems/sass-3.2.0.alpha.104/vendor/listen/lib/listen/multi_listener.rb:84:in `on_change'
        from C:/Ruby/lib/ruby/gems/1.9.1/gems/sass-3.2.0.alpha.104/vendor/listen/lib/listen/multi_listener.rb:95:in `block in initialize_adapter'
        from C:/Ruby/lib/ruby/gems/1.9.1/gems/sass-3.2.0.alpha.104/vendor/listen/lib/listen/adapters/polling.rb:55:in `call'
        from C:/Ruby/lib/ruby/gems/1.9.1/gems/sass-3.2.0.alpha.104/vendor/listen/lib/listen/adapters/polling.rb:55:in `poll'
        from C:/Ruby/lib/ruby/gems/1.9.1/gems/sass-3.2.0.alpha.104/vendor/listen/lib/listen/adapters/polling.rb:31:in `block in start'

[TheDutchCoder]

That was when aborting by the way, couldn't get it to crash "regularly".

[TheDutchCoder]

Okay my money is on using paths.
I'm just running another test from "D:\sass" with the following command:
sass --watch test.scss:test.css --style expanded --trace

This works perfectly!

So it's either paths in the files/folders to watch, or the difference between where sass is called from and what to watch.

[TheDutchCoder]

Could it be that once the listener has been invoked, it somehow fails to unload it after you cancel the watch?
Because after cancelling the watch on my D:\sass\test.scss file, I couldn't get watch to work anymore. It only updated a different file one on launch and now fails to do anything, so I suspect the listener is still bugged on Windows (and maybe not unloading the listener or something, preventing it from listening again).

[nex3]

@Maher4Ever probably has more insight about this than I do... I'm not familiar with the inner workings of Listen.

[stewart]

I'm getting a similar problem, but my sass doesn't seem to crash, just never updates on file changes. Running sass 3.1.16 on Ruby 1.9.3, OS X Lion. However, if I switch to Ruby 1.8.7, sass starts working again. Same version of sass on both rubies.

[Maher4Ever]

@reinierk Your first problem where Listen crashes is caused because for some reason ntuser.dat.LOG1 was checked for content modifications, although it's a protected Windows file. I'll see what we can do in Listen to avoid these issues in the future.

I couldn't reproduce your second issue in which sass stops working after the first time. I tried it with ruby 1.9.3-p125 on WIndows 7 SP-1 (64-bit) and Ubuntu 11.10 (32-bit).

@nex3 After looking closely at how Listen gets included in sass, I realized that some dependencies of Listen does not get installed. That's why Listen falls to polling on some machines, I didn't see this the previous time because the Listen-gem is of course already installed on my machines. Listen is dependent on 3 other gems (which work as adapters for different operating-systems). I would suggest either including the Listen gem as a dependency in the .gemspec file, or just packing the other dependent gems and adding them to the loadpath, just like Listen is currently included in sass. I'll be glad to help with this process if any help is needed.

[TheDutchCoder]

@Maher4Ever Are you completely sure Listen is included in sass? Because in every clean install I do, after installing sass, there's no listen gem to be found. I first need to install the dev kit and then manually install listen for it to show up (not that it works after that, but still).

I'm a complete Ruby newbee (and honestly enough I don't want to invest a lot of time learning it), so that might be part of the issue here.

Is there any way to see what "listen" is doing from the prompt? I have a strong feeling after the initial launch is keeps running in the background and causes the problem where it won't be listening for any other files after 1 run.

[Maher4Ever]

@reinierk After installing sass, you won't be able to see the listen gem with gem list --local. That's because sass includes listen as a part of the sass-gem and does not rely on rubygems (the packages manager in Ruby) for installing it. To see where listen resides, browse to the sass-gem directory and you will find it under the vendor directory.

Listen is still a new project, so unfortunately there is still no way to get verbose output from it.

Have you tried looking at the process manager on Windows and looking for any ruby process which keeps running after you have stopped the sass command from the terminal?

[TheDutchCoder]

@Maher4Ever Okay thanks for clearing that up for me. I located the listener now, so it should be fine indeed.
There are no ruby processes running after I abort the current --watch, but it could very well be inside a svchost if it's something that's run from a dll, so there's no real way of checking that for me.

I will do a complete re-install today, double check if listen is in the folders (and if I can get it running) and see if I can come up with a scenario that you can reproduce.

[TheDutchCoder]

Okay, did a complete re-install, latest RubyInstaller (Ruby 1.9.3-p194), then "gem install sass" (listen is included as you stated)...

Again same issue, with a slight variation:

1. Watching a file on a different drive (e.g. I run from C:\Users\Reinier and watch a file on Z:\client\wwwroot\styles) doesn't work at all (doesn't even update once), but no error is thrown (so it looks like it's watching, but nothing happens).
2. Watching a file "locally" (same drive, no paths, just filenames like so: "home.scss:home.css"), fires up correctly (no listening though, only polling), parses the scss once and then when I edit the scss file, it randomly updates once (after about 30 seconds or so) and then stops working, or it stops working from the git-go.
3. My Task Manager shows that ruby.exe uses a constant 25% CPU time on my quad core, so that's not really a good sign.
4. After this it's just downhill (e.g. sass stops watching completely), sass fires up but doesn't even parse on the first go anymore.

I really hope this info helps out in a way, because it's driving me insane at this point ;-)

[nex3]

@reinierk I can't reproduce this on Windows either. I've tried all the scenarios you've mentioned and they all work fine for me. What version of Windows are you running?

It's also worth noting that apparently Windows paths using backslashes were being handled incorrectly. This should be fixed by 3ee3411. I don't think this is the source of most of your errors, though.

@Maher4Ever The way Sass used FSSM was to bundle just the core polling and glue code, and allow users to install the full gem if they want to take advantage of native OS facilities.

I'm going to release Sass 3.1.17 some time today, with has @Maher4Ever's fix. If I keep getting reports that it's not working, though, I may have to go back to FSSM :-/.

[TheDutchCoder]

@nex3 I'm having this issue on Windows 7 (64-bit). On Vista (64-bit) sometimes it works, sometimes it doesn't. If it works (polling is used), polling takes anywhere between 10 and 30 seconds, which (for me) is not good enough to work with.

[Maher4Ever]

@nex3 Ok, I understand what you are saying. After all, the force_polling option was added for these usecases :)

I've spent quite some time today looking at how sass works and I almost rewrote how the listener is created in sass. It's simpler now, but also works. The plugin didn't account for new files being added, so no callbacks were registered for them; hence why new directories didn't get picked up.

Also, there is no need to keep a list of files in the plugin as Listen already does that. I didn't send a pull request because 2 tests fail ( because of this line ). I disabled the OS-specific plugins and thus there is no need for any extra dependency.

I'm still not familiar with sass internals, so please take a look at it and maybe you can adapt it for a better integration with Listen.

[nex3]

I've actually found some bugs in the Listen polling backend that may be causing this. I'll submit a pull request with fixes shortly.

[TheDutchCoder]

Can we install this fix somehow? (I tried updating and reinstalling as well, both yield no new results for me and racking the git isn't working (posted that somewhere as well)).

[nex3]

@Maher4Ever Thanks for the change; I've made a few edits and merged it in.

@reinierk I'll be releasing this as 3.1.17 shortly.

[nex3]

3.1.17 is now released.

[TheDutchCoder]

@nex3 Thanks so much, after a quick test I found it's been working (with listen, no polling), although the actual updating is still a little slow (between 5 to 10 secs for me)

[nex3]

@reinierk Glad to hear it's working. Thanks for bearing with us through this. I'm not sure why it's taking so long to update, though. Does it take a long time to display the message on the command line, or to actually modify the CSS file?

[TheDutchCoder]

@nex3 Don't worry about it, I'd like to see this work well for everyone as I love sass! ;-)
It takes long to both update the command line and the file. In fact, as soon as the command line updates, the file itself updates immediately as well, so it's not a visual lag on the prompt, but "real" lag with updating.

I know the default latency is 0.5 seconds, but the update now takes about 3 seconds (give or take, sometimes it's faster, sometimes slower).

I'm a little worried about the CPU load still, on my Core Duo it takes 75% of both cores when watching. I know nothing about ruby, but to me that seems wrong, or at least inefficient (even for a 0.5 second latency).

[nex3]

In that case it looks like a Listen issue, which is out of my expertise.

[Maher4Ever]

@reinierk The core team of Listen is well aware of the performance issues on Windows. We are in the process of investigating the cause of this issue. If you are interested in helping us get more profiling results, please head to the issue's page on the Listen gem repo where I'll post a comment on how anyone could help.

[TheDutchCoder]

@nex3 @Maher4Ever Okay thanks guys, then the first step has been taken successfully (getting sass to work again) and I'll try to help out Listen as much as I can!