Amber: [CLI] Amber watch starts multiple processes

[docelic]

It appears that when one is running under 'amber watch', every save of a watched file triggers a new build without waiting or canceling eventual ones already running.

So when one saves a couple files in quick succession, multiple builds spin up, taking a lot of RAM and making machine unresponsive till they finish.

[eliasjpr]

I this still happening in master branch?

[faustinoaq]

I this still happening in master branch?

@eliasjpr yes

Maybe we can increase the scanner time here or changing the sleep time depending on previous builds.

Also we can check new file changes concurrently, so we would be able to cancel a build and start a new one as @docelic suggested

[faustinoaq]

Something similar how Travis work, just keeping latest build/commit

[eliasjpr]

I believe this has been addressed on 0.6.3

[faustinoaq]

I believe this has been addressed on 0.6.3

Not yet, amber watch is still recompiling the project after every file change, keeping old build even if the build isn't needed anymore. This issue often happens on low end pc, so you can see the difference:

We should find a way to kill processes building outdated files and just keep the most recent one. Currently we are watching file changes after a build process ends. I think we can run scan_files inside a spawn fiber and stop a current build faster to recompile using new file-changes.

@eliasjpr WDYT?

[eliasjpr]

Was this resolved?

[elorest]

Since processes are being spawned from within amber watch we should be able to add compile processes to an array and kill them once too many are compiling...

It might be best to allow for a certain number though otherwise we might be constantly killing and starting new compilations as we edit a file. Especially if auto save is turned on with your editor.

[faustinoaq]

Since processes are being spawned from within amber watch we should be able to add compile processes to an array and kill them once too many are compiling...

We're already using a processes array, the issue is happening in the building phase because new files can change during a current build, if this happen then a new build is triggered just after previous build is full completed, I think we can check for file changes using spawn and kill a build process and start a new one without waiting for a complete build.

[faustinoaq]

I just got another idea to solve this, instead of always recompiling the project (checking timestamps) we can keep a temporal db file (sqlite) with all sha256 hashes of all the files in the project, so if the hash changes, amber recopiles and if the hash doesn't change then it executes bin/myappexecutable.

Also if a current build is being triggered, and a file changes, then the build is canceled and a new build is executed.

[faustinoaq]

I just got a new nice and simple idea to solve this by using a processes matrix :sunglasses:

[drujensen]

Will be addressed by #476