Skip to content
This repository has been archived by the owner on Sep 2, 2021. It is now read-only.

update shell node version to 6.3.1 #543

Merged
merged 6 commits into from
Sep 3, 2016
Merged

update shell node version to 6.3.1 #543

merged 6 commits into from
Sep 3, 2016

Conversation

zaggino
Copy link
Contributor

@zaggino zaggino commented Dec 14, 2015

ref: adobe/brackets#11748

I've tried doing this, but I get the following error which is not comprehensible for me:

>> Error: Command failed: C:\WINDOWS\system32\cmd.exe /s /c "bash scripts/fix-msvc.sh"
>>       2 [main] bash 3416 C:\Program Files\Git\usr\bin\bash.exe: * fatal error in forked process - fork: can't reserve memory for parent stack 0x600000 - 0x800000, (child has 0x400000 - 0x600000), Win32 error 487
>>     513 [main] bash 3416 cygwin_exception::open_stackdumpfile: Dumping stack trace to bash.exe.stackdump
>>       2 [main] bash 8080 fork: child -1 - forked process 3416 died unexpectedly, retry 0, exit code 0x100, errno 11
>> scripts/fix-msvc.sh: fork: retry: No child processes
>> 1004878 [main] bash 10932 C:\Program Files\Git\usr\bin\bash.exe: * fatal error in forked process - fork: can't reserve memory for parent stack 0x600000 - 0x800000, (child has 0x400000 - 0x600000), Win32 error 487
>> 1005294 [main] bash 10932 cygwin_exception::open_stackdumpfile: Dumping stack trace to bash.exe.stackdump
>> 1100847 [main] bash 8080 fork: child -1 - forked process 10932 died unexpectedly, retry 0, exit code 0x100, errno 11
>> scripts/fix-msvc.sh: fork: retry: No child processes
>> 3108069 [main] bash 8804 C:\Program Files\Git\usr\bin\bash.exe: * fatal error in forked process - fork: can't reserve memory for parent stack 0x600000 - 0x800000, (child has 0x400000 - 0x600000), Win32 error 487
>> 3108730 [main] bash 8804 cygwin_exception::open_stackdumpfile: Dumping stack trace to bash.exe.stackdump
>> 3207844 [main] bash 8080 fork: child -1 - forked process 8804 died unexpectedly, retry 0, exit code 0x100, errno 11
>> scripts/fix-msvc.sh: fork: retry: No child processes
>> 7224872 [main] bash 11240 C:\Program Files\Git\usr\bin\bash.exe: * fatal error in forked process - fork: can't reserve memory for parent stack 0x600000 - 0x800000, (child has 0x400000 - 0x600000), Win32 error 487
>> 7226544 [main] bash 11240 cygwin_exception::open_stackdumpfile: Dumping stack trace to bash.exe.stackdump
>> 7316396 [main] bash 8080 fork: child -1 - forked process 11240 died unexpectedly, retry 0, exit code 0x100, errno 11
>> scripts/fix-msvc.sh: fork: retry: No child processes
>> 15320804 [main] bash 11272 C:\Program Files\Git\usr\bin\bash.exe: * fatal error in forked process - fork: can't reserve memory for parent stack 0x600000 - 0x800000, (child has 0x400000 - 0x600000), Win32 error 487
>> 15321198 [main] bash 11272 cygwin_exception::open_stackdumpfile: Dumping stack trace to bash.exe.stackdump
>> 15409163 [main] bash 8080 fork: child -1 - forked process 11272 died unexpectedly, retry 0, exit code 0x100, errno 11

also, why do we need npm?

@ingorichter
Copy link
Contributor

I don't exactly see why we need npm. Perhaps @jasonsanjose recalls why we need it.

@zaggino
Copy link
Contributor Author

zaggino commented Dec 17, 2015

btw npm is only part of node-win so it makes me wonder why there is npm for windows and not for other envs

@ingorichter
Copy link
Contributor

That's a good question to ask. What happens if you don't download it? Are you able to build and run the tests?

@jasonsanjose
Copy link
Member

Whew. That took some digging but there's the answer c913ec8. We used npm to install a dependency on ws for websocket support.

In #209 we moved that code from @joelrbrandt's git repo into the brackets-shell repo, but we never removed the npm dependency.

Looks safe to remove to me.

@ingorichter
Copy link
Contributor

Great! Thanks for digging this up @jasonsanjose. @zaggino do want to remove it in this PR?

@zaggino
Copy link
Contributor Author

zaggino commented Dec 17, 2015

Yes, because npm package is no longer on the nodejs server and the format of the tar in npm registry is a bit different.

@ficristo
Copy link
Collaborator

@zaggino @ingorichter Is this blocked on something?

@abose
Copy link
Contributor

abose commented May 13, 2016

@ficristo Have you tested if

  1. the existing file watching mechanism is properly woking with updated node engine?
  2. installing extensions from the extension manager works.
  3. Unit tests relating to extension pass
  4. instant search is working
  5. Unit tests relating to instant search is working.
    Once all these are verified, I could run some test cases with updated node.

@abose
Copy link
Contributor

abose commented May 13, 2016

Oh wait! it was @zaggino 's PR 😅 Wrongly addressed to @ficristo .

@zaggino
Copy link
Contributor Author

zaggino commented May 16, 2016

This is not finished, I've run into fatal error in forked process and wasn't able to get around it. Compiling brackets works fine on my machine but not with this PR.

@zaggino
Copy link
Contributor Author

zaggino commented May 17, 2016

if anyone wants to try to compile the shell with this PR, go ahead ... maybe something is wrong with my machine, I'll test this on Mac when I get a chance

@@ -377,22 +377,12 @@ module.exports = function (grunt) {

var done = this.async(),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now this is unused: remove or call it.
(I've had some trouble testing the PR because of this)

@ficristo
Copy link
Collaborator

ficristo commented May 31, 2016

Some days ago I tryed this PR and had some problems.
I tryed again today and seems to run fine on Windows... 😕
(I've removed the done variable in my test)

@ingorichter
Copy link
Contributor

I tried this today and it failed to download the node binary. The current download URL is http://nodejs.org/dist/v4.4.4/node-v4.4.4-darwin-x86.tar.gz, but this version is no longer available. Only the x64 version is available for OSX. So, this needs to be updated and then the question is: does it compile and work with the x64 version?

@zaggino
Copy link
Contributor Author

zaggino commented Jul 30, 2016

I'd be great if someone could tackle this...
brackets-userland/brackets-eslint#36

@AdriVanHoudt
Copy link

what is blocking this?

@ficristo
Copy link
Collaborator

ficristo commented Aug 2, 2016

@AdriVanHoudt first things that come to my mind:

  • I left some comments that should be answered.
  • I think the version for OSX should be changed. See @ingorichter comment.
  • Verify all steps mentioned by @abose.
  • What we will do for Linux since is building from another branch?

@ingorichter
Copy link
Contributor

I tried again last night and we have to change to the x64 variant. Changing it to x64 makes the download and build succeed. I haven't tested yet if Brackets launches and behaves properly (my machine had some thermal issues and shutdown down :-/). I can test it tonight on a different machine.

@zaggino
Copy link
Contributor Author

zaggino commented Aug 3, 2016

I've changed Mac to the 64 bits; I've updated to the latest node (as there's little point to upgrading to v4 now that v6 is out); Removed some remaining npm references;

I'd love if someone from Adobe could try to build this on the machines that they use to build releases as my current Windows machine stopped being able to compile brackets-shell for whatever reason.

If I have a valid build of shell, I can start working on a PR of making https://github.com/adobe/brackets work with it.

PR for linux build branch should also not be an issue later.

@zaggino
Copy link
Contributor Author

zaggino commented Aug 3, 2016

Guys, what about not porting fsevents_win and using https://github.com/paulmillr/chokidar for watching file system changes? If it's good for others, it should be good for Brackets, no? @ficristo @ingorichter

http://ourcodeworld.com/articles/read/160/watch-files-and-directories-with-electron-framework

@ficristo
Copy link
Collaborator

ficristo commented Aug 3, 2016

@zaggino I'm totally in favor: adobe/brackets#12190

@zaggino
Copy link
Contributor Author

zaggino commented Aug 3, 2016

Ok, I'm gonna try building this shell and run tests using adobe/brackets#12190 branch, we'll see what happens. Anyone else is welcome to do the same :)

@zaggino zaggino changed the title update node and npm versions to latest LTS update shell node version to 6.3.1 Aug 3, 2016
@ingorichter
Copy link
Contributor

@zaggino I like the idea. Frees some resources for us. I'll give it a try tonight

@ficristo ficristo added this to the Release 1.8 milestone Aug 26, 2016
@zaggino
Copy link
Contributor Author

zaggino commented Aug 26, 2016

Now that adobe/brackets#12647 has landed in master, there're no other native dependencies that would block this from merging.

Please review/merge @ingorichter @ficristo

I'd love to see this land for 1.8 to solve brackets-userland/brackets-eslint#36 and also adobe/brackets#11748 (comment)

@ficristo
Copy link
Collaborator

ficristo commented Aug 28, 2016

To test this I've run only the test suite on Windows 10.
I see some consistent failures:

  • Integration \ FindInFiles
  • MainView \ MainViewManager
  • Extensions \ Code Folding
  • Extensions \ HealthData

but I doubt any of these is related to this PR.
For example I'm sure the FindInFiles is on master too, but I didn't test master to check the others.

@ficristo
Copy link
Collaborator

ficristo commented Sep 1, 2016

I tryed both on Windows10 and OSX and see some consistent failures on Integration \ FindInFiles and Extensions \ HealthData but I'm sure they are on master too.
@zaggino have you checked @abose comment?
Otherwise I think this is ready.

@zaggino
Copy link
Contributor Author

zaggino commented Sep 1, 2016

@ficristo @abose

  1. yes, file watching was updated to support node 6 and that's already in master
  2. yes, installing extensions from the extension manager works.
  3. yes, unit tests relating to extension manager pass
  4. yes, instant search is working
  5. yes, unit tests related to instant search are working

running this branch and latest master, no unit test is failing, from integration tests there are two failures which are definitely not related to this

@nethip
Copy link
Contributor

nethip commented Sep 2, 2016

@zaggino and everyone else on this thread. Thanks for your amazing efforts in taking up this herculean task. As always, I am in awe 👍

@@ -71,7 +71,7 @@ module.exports = function (grunt) {
},
"node-mac": {
"dest" : "<%= downloads %>",
"src" : "http://nodejs.org/dist/v<%= node.version %>/node-v<%= node.version %>-darwin-x86.tar.gz"
"src" : "http://nodejs.org/dist/v<%= node.version %>/node-v<%= node.version %>-darwin-x64.tar.gz"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We might want to leave the mac node to be 32 bit, as our native node extensions are still 32 bit and they would not load on 64 bit node.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which native node extensions are you talking about?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Node doesn't have 32-bit builds for Mac anymore:
image

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah. Now that we have moved to Chokidar, I don't think we will have any references to native node extensions. I was referring to this library which we were using earlier for file watching.

https://github.com/adobe/brackets/tree/release/src/filesystem/impls/appshell/node/node_modules/fsevents

I think then it should be fine to go with 64 bit.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants