search

lucamezzalira / haxe-watchify

automatic build tool for your Haxe and OpenFL projects. It monitors the changes in your files and runs the build of your projects
https://www.npmjs.com/package/haxe-watchify
51 stars 4 forks source link

Windows 7: FlashDevelop: infinite build loops. #3

Closed sruloart closed 9 years ago

sruloart commented 9 years ago

It happens with all of the targets AFAIK. It should stop trying to build the project after it encounters a build issue (with FlashDevelop especially, as there's an annoying bug where you can't delete/replace the files in the export directory).

Another, smaller issue, is that building the .swf file isn't very helpful with an OpenFL default build command because most people use the stand-alone player. You can add -web to the end of the Flash build command, so it would add an index.html file the user can use to test the .swf with. This index would be rebuilt on every build though, not sure if that's a problem.

I'm really excited about this project, especially about the all

GENERAL: live reload JS and Flash targets

Keep it up! :)

lucamezzalira commented 9 years ago

Hi, I don't have a Windows system configured on my macbook to try FlashDevelop yet, I'll do ASAP. BTW it's correct that it's trying to rebuild a failing target because it's the point of automation build, so it's giving a feedback that something is going wrong in a particular build! It's not right that is going in an infinite loop but I suppose to know the issue you are encountering :D

What do you think if I'll add the possibility to set the parameter to use in order to build an OpenFL project, so currently it's build by default but if you are able to set test could resolve the problem in your opinion? Or the workflow would be better with the -web parameter activate?

sruloart commented 9 years ago

I know :) my point is that on Windows building means opening another cmd process, and another one, and another one...my 16gb of RAM fills up completely in a few seconds. I've no clue as for why it's doing that.

I think that building / testing for Flash with Watchify means the user would have to use an index.html to quickly see the new builds. The stand-alone player won't re-open itself (building or testing), but a live-reloading index.html will reload the new .swf.

So there are two options:

  1. You add -web: the user would then need to use something like live.js to reload the web page (it's generated by OpenFL every time, building or testing) which means it will also manually reload the new .swf.
  2. You make an index.html file of your own, containing a script to reload the .swf if it changes, or let the user to use something like: https://www.npmjs.com/package/simple-autoreload-server to watch his .swf by himself.

In every case it's not a big deal for the avid user.

lucamezzalira commented 9 years ago

FlashDevelop in order to use the completion server and have the code completion saves the file you are working every now on, that's why the watchify tool is going in build loop. BTW I'll ask to Philippe, the creator of FlashDevelop, how it's working precisely and I'm going to understand if I can implement a workaround.

The idea to use an html page for Flash target is not bad at all, I'll investigate further on this topic, there was another suggestion to use halk live editing lib, I want to give it a try and see if it could fit better.

I keep you posted on that side!

sruloart commented 9 years ago

Halk support would be awesome :D This is the most updated version I'm aware of btw: https://github.com/profelis/halk2, but personally I couldn't get this to work with my set-up :|

lucamezzalira commented 9 years ago

I tried quickly yesterday without any fortune, I'll spend more time tonight. Otherwise I'm going to ask information to its creator :P

Anyway I could temporary starts to implement the solutions with live reload of an HTML page if I can't see any progress with Halk

lucamezzalira commented 9 years ago

Hi may I ask you to try setting as compiler the server instead of the normal compiler? Actually I had better performance with that on Windows

screen shot 2015-07-07 at 00 30 04
sruloart commented 9 years ago

The haxe build works great, it's the OpenFL version that keeps on creating new cmd and haxelib processes (cmd.exe_32, haxelib.exe_32), maybe it's something to do with haxelib? or at least the haxelib command.

This long command isn't really needed: Error: Command failed: C:\Windows\system32\cmd.exe /s /c "haxelib run openfl build neko " ^C

This command should be enough: openfl build neko

I don't know if it would solve the problem, but my best guess is that there's something in this line that is the culprit.

lucamezzalira commented 9 years ago

ok I'll give it a try, probably I'll be able to kill the current process before starting a new one. I think in the next release with the live reload the performance on OpenFL target will be better

lucamezzalira commented 9 years ago

can you tell me in the meantime I'm checking the live reload feature on windows if this thing is resolved with the new version please?

sruloart commented 9 years ago

I can't use haxe-watchify at all because of issue #10 (it gives me the same error no matter how I try to use it, haxe or openfl, test or build, with a config file and without). I'll try forcing it to work :)

lucamezzalira commented 9 years ago

did you try to re-install it doing:

npm uninstall -g haxe-watchify

and then install it again from scratch?

sruloart commented 9 years ago

I did, but late last night, let me see...this is what I'm getting: C:\Users\user\AppData\Roaming\npm\node_modules\haxe-watchify\node_modules\livere loadx\node_modules\ws\node_modules\bufferutil>if not defined npm_config_node_gyp (node "E:\Program Files\nodejs\node_modules\npm\bin\node-gyp-bin....\node_mo dules\node-gyp\bin\node-gyp.js" rebuild ) else (node rebuild ) gyp ERR! configure error gyp ERR! stack Error: Can't find Python executable "python", you can set the PYT HON env variable. gyp ERR! stack at failNoPython (E:\Program Files\nodejs\node_modules\npm\nod e_modules\node-gyp\lib\configure.js:114:14) gyp ERR! stack at E:\Program Files\nodejs\node_modules\npm\node_modules\node -gyp\lib\configure.js:69:11 gyp ERR! stack at FSReqWrap.oncomplete (evalmachine.:95:15) gyp ERR! System Windows_NT 6.1.7601 gyp ERR! command "node" "E:\Program Files\nodejs\node_modules\npm\node_modu les\node-gyp\bin\node-gyp.js" "rebuild" gyp ERR! cwd C:\Users\user\AppData\Roaming\npm\node_modules\haxe-watchify\node_m odules\livereloadx\node_modules\ws\node_modules\bufferutil gyp ERR! node -v v0.12.6 gyp ERR! node-gyp -v v2.0.1 gyp ERR! not ok npm WARN optional dep failed, continuing utf-8-validate@1.1.0 npm WARN optional dep failed, continuing bufferutil@1.1.0 C:\Users\user\AppData\Roaming\npm\haxe-watchify -> C:\Users\user\AppData\Roaming \npm\node_modules\haxe-watchify\src\haxe-watchify.js haxe-watchify@1.2.0 C:\Users\user\AppData\Roaming\npm\node_modules\haxe-watchify

├── commander@2.8.1 (graceful-readlink@1.0.1) ├── chalk@1.1.0 (escape-string-regexp@1.0.3, supports-color@2.0.0, ansi-styles@2 .1.0, strip-ansi@3.0.0, has-ansi@2.0.0) ├── livereloadx@0.3.8 (pause@0.0.1, commander@2.3.0, debug@2.0.0, minimatch@0.2. 14, fsmonitor@0.2.4, http-proxy@0.8.7, send@0.9.3, ws@0.7.2) └── chokidar@1.0.5 (arrify@1.0.0, path-is-absolute@1.0.0, is-glob@1.1.3, glob-pa rent@1.2.0, async-each@0.1.6, is-binary-path@1.0.1, readdirp@1.4.0, anymatch@1.3 .0)

And it's not working yet, sadly, but I still have high hopes for this to work! :D

sruloart commented 9 years ago

Nice! I've tested it pretty thoroughly and this issue is fixed! :D But I have more minor issues...

lucamezzalira commented 9 years ago

ok please document them in a new one issue, thanks for the test

sruloart commented 9 years ago

Oops, didn't see your message in time so I've opened 2 separate issues, but they aren't related :)

lucamezzalira commented 9 years ago

that's definitely fine, even better so I can work on them separately, you did the right choice