VS Code (Native) For GoPiGo3 Development

Exactly. Before I invest in any fussiness, I want to see what the no-fuss native installed VSCode offers, leaving some fuss-budget for all the stupid key-stroke learning any new editor entails.

  • Like needing to press return twice after typing import time isn’t helping me!

While my first job out of college was to build a microprocessor software development system (at Hewlett-Packard) that offered context sensitive editing, cross-compile, remote execution with trace and debug, (and even logic analyzer functions as well), I spent 40 years preferring if debug: print("got here"), and to this day do not miss breakpoints, debugger, and variable inspection in the slightest, and have generally used multiple monitors for “context-sensitive help”.

Also remote debug with multi-threaded or multi-processing is an exercise in futility most times.

Give me an editor and a console window and I am very happy. If that editor has context sensitive help that does not obtrusively get in my way then perhaps the whole IDE thing can be tolerated.

Being a Mac user, things like key mappings and setting up remote communications (like in VNC authentication) complicate trying new things. If native VSCode convinces me I can’t live without it, then the next step will be to investigate remote development with VSCode.

1 Like

Git Integration

Wow - didn’t have to do anything to configure git - VSCode somehow knew about my git repo for Legacy Dave and tracked changes (git status), allowed “staging” (git add), and “commit” (git commit).

I couldn’t figure out how to do the git push so did that in a term window…(Found push under … more actions)

Possible Memory Leak?

Seems like the native VSCode might have a memory leak (or two…), as evidenced by the available memory starting out around 280MB and ending around 60MB with a dip to 44MB at one point.

  • Before VSCode (fresh boot): 681MB
  • VSCode initialized with Editor and Terminal panel: 285MB
  • VSCode running program in one Terminal, Editor and 2nd Terminal panel: 260-240MB
  • VSCode running program, plus editor and 2nd term, repeated changes, reruns: 80-44MB
  • After VSCode exit: 689MB

Danger lurking

Had an editor and two term windows open, and tried to delete a hidden term window - the processor load went sky high and never recovered. Was not able to gracefully shutdown, but the system and VSCode seemed to unscathed after rebooting.

1 Like

This kind of problem is exactly the reason I abandoned a native install - I could not trust it for any length of time to not crash or load down my robot unacceptably.

This is because the ext-4 filesystem is a journaling file system.  This kind of graceful recovery is NOT guaranteed and I have totally trashed filesystems using VS Code natively.

I would humbly suggest you do the same after completely uninstalling, (ape-get purge), the original installation.

1 Like

I would also suggest forcing a boot-time e2fsck by using tune2fs and setting the current mount-count to a value larger than the maximum mount count and then reboot the 'bot.

I would strongly suggest that tune2fs be used to set a maximum interval AND a maximum mount count to prevent inadvertent corruption of your robot’s filesystems.  The man page for tune2fs goes into some detail as to why this is an excellent idea.