rb-fsevent backend doesn't work about fssm HOT 6 CLOSED

freaking seriously? >_<

export FWDEBUG="true"
gem install rb-fsevent

and then you should get a dramatically over-verbose level of debugging info from the binary that gets compiled. I'll need to look into this more deeply tomorrow.

from fssm.

I'm not kidding about the level of verbosity btw, but that'll hopefully let you determine whether the problem is in rb-fsevent, FSSM, or later on in the chain. You should be seeing output to the effect of:

append_path called for: /Users/ttilley/src/rb-fsevent/spec/fixtures/custom 'path
  resolved path to: /Users/ttilley/src/rb-fsevent/spec/fixtures/custom 'path

config.sinceWhen    18446744073709551615
config.latency      0.300000
config.flags        00000000
config.paths
  /Users/ttilley/src/rb-fsevent/spec/fixtures/custom 'path

FSEventStreamRef @ 0x100108590:
   allocator = 0x7fff7006eee0
   callback = 0x100001522
   context = {0, 0x0, 0x0, 0x0, 0x0}
   numPathsToWatch = 1
   pathsToWatch = 0x7fff7006eee0
        pathsToWatch[0] = '/Users/ttilley/src/rb-fsevent/spec/fixtures/custom 'path'
   latestEventId = -1
   latency = 300000 (microseconds)
   flags = 0x00000000
   runLoop = 0x0
   runLoopMode = 0x0


FSEventStreamCallback fired!
  numEvents: 1
  event path: /Users/ttilley/src/rb-fsevent/spec/fixtures/custom 'path/
  event flags: 00000000
  event ID: 114922439

from fssm.

a good example of a funky issue i've seen before is /tmp/ on mac... technically, /tmp is a symlink to /private/tmp, so performing path resolution should give you that as the result. However, the MacOS internal path normalization API additionally takes any paths with /private/ at the start and chops that off. Some things use the kind of realpath behavior you'd normally expect, and others use the strange strange MacOS version of reality. The debugging output should make this kind of problem clear, as you're shown the path that was passed in, what my mostly-sane normalization resolved that to before calling fsevents, and what path was returned by fsevents after an event was fired under that path.

from fssm.

i was going to attempt to use compass's own documentation to test compass, but you have some funky assumptions about how git works hard coded. you're expecting to read directly from .git/refs/heads/master like it's going to be there as a file in all cases when this isn't true.

[13:12:14][compass](master)$ git branch -r
  chriseppstein/css3-v2
  chriseppstein/css3pie
  chriseppstein/lemonade
  chriseppstein/master
  chriseppstein/stable
  origin/HEAD -> origin/stable
  origin/css3-v2
  origin/css3pie
  origin/lemonade
  origin/master
  origin/stable
[13:12:21][compass](master)$ ls .git/refs/remotes/chriseppstein/
[13:12:25][compass](master)$ ls .git/refs/remotes/origin/
HEAD
[13:12:29][compass](master)$ ls .git/refs/heads/
[13:12:36][compass](master)$ 

if you want the git hash of the current branch, you should probably ask git for it:

[13:14:59][compass](master)$ git rev-parse HEAD
9cafbc642c8d223a929d6c849bf557f4be3b09c7

Though, it might just be that I'm using a funky reference format and a funky git release that you haven't hit this:

[13:16:14][compass](master)$ git --version
git version 1.7.5.rc3.233.g94081.dirty

from fssm.

fixed in 0.2.7. holy crap was that one a brain fart. also, further proof that 99.9% of FSSM users are only using it via compass.

from fssm.

I've verified that this fixes the issue on compass. Thanks for the quick turn around.

from fssm.