Changes from atomic / "safe" writes not detected (Webstorm, Intellij, vim, maybe c9)

[jthomaschewski]

Changes from atomic / "safe" writes not detected (Webstorm, Intellij, vim, maybe c9)

[gadicc]

Hey @JBBr

Thanks for the amazing write-up! Wonderful to get such clear issues.

I'd rather just support "safe" writes (aka atomic writes). I think I have this working now, and it will be in the next release. What OS are you on? I'm on Linux. I'm going to leave this issue open so when the next release is out you can confirm that this is working.

The speed thing might have just been other improvements we've been making in meteor-hmr. The atomic writes should be very close to the same speed as a normal write.

[jthomaschewski]

thanks, just tell me if I can help you in any way (test master on osx/linux/windows with "safe write" or anything else)?

btw: I tested the new refactor.7 release as it includes your "atomic writes" commit. Unfortunately hot-reload still fails with Intellij's "safe write". No error log in console anymore (As the TODO log for renames has been removed).
whoops, my fault. Sorry for the confusion. Although refactor.7 has been released after the "atomic writes" commit, it's not yet in the packaged accelerator version. So I will probably have to wait for a new release or try the master directly.

[Vincent-P]

Best way to test is to try master directly.

[gadicc]

hey guys sorry i'm away for the weekend, i might have made a mistake somewhere trying to get this out before i left but i'm pretty sure the latest accelerator should be running, v1.0.7. What I maybe didn't mention is that you must quit Meteor and restart it to load the new accelerator version (maybe we'll fix this in a future release). it's a long weekend here so might only be back tuesday :)

[jthomaschewski]

I did a meteor reset and ran meteor again with refactor.7 build. Now meteor-hotload-accelerator includes the changes.
Unfortunately hot reload still does not work with "safe write" setting. Just get a plain => Client modified -- refreshing in meteor console and a full browser refresh on every change.

But don't worry, have a nice weekend! I think this isn't a major problem anyway - it's just confusing for people how do not understand why hot-reload isn't working as it's supposed to.

[gadicc]

Thanks for the patience, @JBBr. Either way I'd like to try get this fixed, ideally meteor-hmr should work correctly wherever meteor does. The problem is just how unreliable node's fs.watch() is, in certain circumstances and across platforms. Can you try gadicc:ecmascript-hot@=1.3.2-refactor.8 and see if it's any better?

[gadicc]

I also added this to the README in the meantime:

On a save, you should see the following on the client console:

[gadicc:hot] Connected and ready.
[gadicc:hot] Updating ["/client/colors.js"]
[gadicc:hot] Skipping HCP after successful HMR

If you're not seeing that, probably we're not picking up the save. The
biggest reason for this currently is atomic writes ("safe writes"),
which we're working to fix. You can track the progress in
#53.

Otherwise see further down about DEBUG LOGGING.

[gadicc]

You can try gadicc:ecmascript-hot@=1.3.2-refactor.9 too... would love feedback on both releases.

[jthomaschewski]

Nice, it works for me now in both refactor.9 and refactor.8. I'm on OSX 10.11 by the way. I haven't tested it yet on other systems. Maybe the behavior of file watches is different on Linux/Windows.

While using refactor.9 I had an issue with removing an element (in this case removing an entire <p>something</p>. The whole Meteor process crashes with the following output.

I wasn't able to reproduce this and I'm not sure if this has to do anything with atomic writes or even meteor-hmr. Looks more like some kind of websocket connection problem. But just in case - maybe you see the cause of this directly.

undefined:0
/Users/user/.meteor/packages/static-html/.1.0.7.c2cb7b++os+web.browser+web.cordova/plugin.compileStaticHtmlBatch.os/npm/node_modules/meteor/promise/node_modules/meteor-promise/promise_server.js:116

^      throw error;

            ^
Error: EBADF, write
SyntaxError: Unexpected end of input
    at Object.parse (native)
    at WebSocket.<anonymous> (/Users/user/.meteor/packages/gadicc_ecmascript-hot/.1.3.2-refactor.9.h926c6++os+web.browser+web.cordova/plugin.compile-ecmascript-hot.os/npm/node_modules/meteor/gadicc_hot-build/node_modules/meteor-hotload-accelerator/lib/accelerator.js:89:22)
    at WebSocket.emit (events.js:98:17)
    at Receiver.self._receiver.ontext (/Users/user/.meteor/packages/meteor-tool/.1.3.2_4.1ig628y++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/ws/lib/WebSocket.js:682:10)
    at Receiver.opcodes.1.finish (/Users/user/.meteor/packages/meteor-tool/.1.3.2_4.1ig628y++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/ws/lib/Receiver.js:391:14)
    at /Users/user/.meteor/packages/meteor-tool/.1.3.2_4.1ig628y++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/ws/lib/Receiver.js:372:33
    at Receiver.expectData (/Users/user/.meteor/packages/meteor-tool/.1.3.2_4.1ig628y++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/ws/lib/Receiver.js:147:5)
    at Receiver.expectHandler (/Users/user/.meteor/packages/meteor-tool/.1.3.2_4.1ig628y++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/ws/lib/Receiver.js:371:16)
    at Receiver.add (/Users/user/.meteor/packages/meteor-tool/.1.3.2_4.1ig628y++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/ws/lib/Receiver.js:87:24)
    at Socket.firstHandler (/Users/user/.meteor/packages/meteor-tool/.1.3.2_4.1ig628y++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/ws/lib/WebSocket.js:663:22)

[gadicc]

Yay! Thanks for reporting back. Ok, so the big change I did from refactor.8 -> refactor.9 was unnecessary, but probably more sustainable :) I'm on Linux, so we have that covered... Windows, I'm hoping that since I'm using Atom's patchwatcher code now, well, it seems to be a lot more stable and cross-platform compatible.

One more report from @clayne11 here:

refactor.9 working for me with:

OS: Mac OS X 10.11
Text editors: Atom, vim

vim definitely didn't work with refactor.7

I'm going to close this issue since we've solved it. But the other error you saw, we do use a websocket for the hmr and I've definitely seen this error before, so it probably is hmr-related. If you see it again, please open a new issue, especially if you figure out how to reproduce it. One possibility is this is caused by not using atomic writes (where the "changed" event can fire multiple times during a long write)... I should probably debounce the event.