Replace cloud9 with coder?

[fnoop]

https://github.com/codercom/code-server

[fnoop]

Basic visual studio code support in place, some extensions installed automatically.

• Extensions not working.
• Need to install a default workspace/config.
• Configure python for maverick python, linting etc: https://code.visualstudio.com/docs/python/linting

[fnoop]

Increasing the kernel limit hugely increases memory usage but still doesn't have enough to cover the entire maverick filetree:

    # Increase kernel inotify watcher limits
    base::sysctl::conf { 
        "fs.inotify.max_user_watches": 	value => $filewatchers;
    }

Probably just suppressing the warning is ok - and document that changes on the filesystem may not be picked up through codeserver.

[fnoop]

Extensions don't work:

[fnoop]

Startup errors:

[fnoop]

No terminal:

[fnoop]

Updated node.js from 8.x to 10.x (latest LTS).

Memory note: coder/code-server#232
We shouldn't make this the default unfortunately, probably still stick with cloud9 as default. Install both, but make cloud9 active and codeserver inactive.

[fnoop]

Ah, updating node.js to 10.x fixes most of the above problems. Terminal works, extensions work, python now linting etc.

[fnoop]

Need to suppress load warnings/errors, as they show up every time it's loaded in a browser.

[fnoop]

Python setup:

• Select custom maverick python install interpreter
• Use black formatter?
• Which linter? pylint?

goodrobots/maverick-api#42

[SamuelDudley]

Great work!
+1 for black formatter. Re linter I'm not too fussed.

[fnoop]

Good tips:
https://dev.to/selrond/tips-to-use-vscode-more-efficiently-3h6p

[fnoop]

code v2 complete rewrite, much more efficient:
https://github.com/cdr/code-server/releases

Also, vscode native remote extensions now work with raspberry, as an additional option.

[SamuelDudley]

Having the dev environment accessible by the browser is quite useful IMO as it lowers the barrier of entry to having a web browser installed on the machine. So +1 for code-server if it is infact reliable.

We can document the use of vscode remote if that is the user preference.

My 2c

[fnoop]

maverick_web::codeserver manifests updated with code-server v2 build steps. v2 uses a lot more memory to build, but packages into a single binary and has much reduced memory usage at runtime. Good enough I think to make it the default and deprecate cloud9.

Memory usage for codeserver v2 is still 200mb+ resident which is too much for a pi zero with 512mb ram. resident memory usage of cloud9 is only about half that - 120mb+, but I don't think worth keeping around and supporting it, particularly as it's license is distinctly non-opensource friendly. For smaller systems like rpizero, just install but disable codeserver by default and allow the user to quickly start when they need it.

[fnoop]

https://theia-ide.org/
https://github.com/eclipse-theia/theia

[fnoop]

c9 dead, should be removed asap:
c9/core#536

[fnoop]

Nothing is likely to replace c9 anytime soon on smaller boards, due to the memory limitation. Fork c9/core and reference that, just incase amazon pull the upstream repo.

[fnoop]

Need to do a memory review of all current options:
c9
codeserver
theia

[cglusky]

Not an IDE, just the editor functions of VS Code in browser
https://microsoft.github.io/monaco-editor/index.html

Likely much more light weight and would also likely require a bunch of work to make useful in context. But still worth noting IMO.

[fnoop]

Forked cloud9 to github.com/fnoop in case amazon pull the now-dead c9 repo.
Adding theia manifest as well - looks like a very interesting alternative, as well as being properly open-source project.

[fnoop]

There are lots of problems with cloud9 alternatives, the two biggest are currently:

• Massive resources needed to build codeserver - impossible on 2gb, struggles on 4gb ram. Theia needs a lot of resources but less - it builds on 4gb.
• Big resources needed to run codeserver and theia - RAM usage isn't too bad (although more than cloud9) but they both seem to mandate inotify file watchers to construct the file tree. This either fails (theia) and/or requires a huge increase in kernel file watcher limits with corresponding RAM increase.

Suggest that this is shelved until 2.0 - for now we'll stick with cloud9, which is a known quantity and stable. I've forked the repo and repointed, just in case amazon pull the upstream repo.