@Mislav I've just released the first version of my alternative to Livereload: http://github.com/jeroenvandijk/Reloader (also available as a gem). I would have liked to put more effort in it before releasing it, but I realized that it would otherwise take too long to get it out there. The main difference with Livereload is that it plugs into your Rails app (only tested with edge) and it should just work after doing a `bundle install` and running `bundle exec reloader` (couldn't think of a better name). It uses RSpactor because I noticed that it was quite faster than for example Watcher. I used faye (http://faye.jcoglan.com/) to handle all the websocket stuff, but that could be a bit slower than a bare metal one. Didn't have enough time to test that. I didn't really see a difference between using the Sass middleware to generate the new stylesheets and the direct Sass commands. That said, I didn't benchmark it with tools just with my gut feeling.
Hope this inspires you or anyone else. I sure hope to improve it in the near future. Would like to hear your opinion about it. On Fri, Jul 30, 2010 at 8:26 PM, Nathan Weizenbaum <[email protected]> wrote: > On Fri, Jul 30, 2010 at 1:47 AM, Mislav Marohnić < > [email protected]> wrote: >> >> I've looked into fssm used by Sass/Compass, but it's still tied to >> RubyCocoa, meaning it needs system ruby on the Mac. We've done some work on >> RSpactor to use FSEvents directly without the need for RubyCocoa, meaning it >> can be installed on any ruby. When this and Linux support is released, >> RSpactor will have a slight advantage over fssm. But the real reason why I'm >> sticking to RSpactor is that I have bigger plans for it. I might rename my >> fork, though, since it's getting further and further away from official >> version(s?). >> >> As for polling on Windows, I don't plan to support it because I don't >> believe it can work for a huge project. Polling several .sass files can >> scale, but for using LiveReload and auto-testing you have to poll for >> hundreds of files, and that just eats away the CPU and hard drive life. >> > > We would love it if you'd release your FSEvents handler as a separate > package that we could hook into in FSSM. We've been meaning to write an FFI > wrapper for a while, but haven't gotten around to it. > > It's important for sass --watch to work on Windows, even if it doesn't work > well. We don't have the same scaling needs as autotest, and we do have > relatively many Windows users. At some point I may grit my teeth and write a > wrapper for Windows' file-notification APIs... > > I'm curious what your "bigger plans" are. > > There might have been a misunderstanding here. I love the >> Sass::Plugin::Rack middleware. What I was saying is that the brittle >> solution for LiveReload is the middleware *reordering* you were discussing >> in this thread. If the server handles static files on its own (like Apache), >> the direct request to a .css file will never hit the ruby app, and all the >> middleware magic you did here to support direct requests to stylesheets is >> useless. The true solution for LiveReload is my script: the same process >> that handles websocket connection for the browser also listens to change >> events on the filesystem *and* compiles Sass. >> > > Ah, I see, I misunderstood. I agree. > > -- > You received this message because you are subscribed to the Google Groups > "Haml" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected] <haml%[email protected]>. > For more options, visit this group at > http://groups.google.com/group/haml?hl=en. > -- You received this message because you are subscribed to the Google Groups "Haml" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/haml?hl=en.
