Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ev3dev IDE #788

Closed
laurensvalk opened this issue Nov 30, 2016 · 64 comments

Comments

Projects
None yet
10 participants
@laurensvalk
Copy link

commented Nov 30, 2016

The discussion of integrated development environments (IDE) for ev3dev has come up several times. (477, 783). Though many existing IDE's work fine for eperienced programmers, they have the same problems as the non-IDE setup, which is manual configuration of various tools to make it work nicely with EV3.

Though it may be a long shot, I think the solution to make ev3dev both easier to use and more accessible for new users, is to develop an ev3dev IDE that lets users write a program (Python), connect to the EV3, upload and run the program, and see the output on the screen.

This (and much more) is essentially what Brixcc did for the NXC (C-based) language for NXT. And NXC was very popular among hobbyists.

These are all major obstacles for new users, especially if they're new to programming, networking, Linux, and Python.

To make this possible, the IDE would need:

  • A text file editor. (Eliminates problems with line endings in many editors)
  • The ev3dev Python library (for documentation and autocomplete) with examples
  • A connect/disconnect button with ip address field, to connect to the robot (Actual connection procedures remain unchanged. But IDE could point to associated docs.)
  • Local (PC) and remote (EV3) file trees (Eliminates need for Filezilla). Either mounted locally or through sftp.
  • A "run program" button. This saves the file, sends program and dependencies to robot, makes executable, runs it within brickman, displays output in IDE. (Eliminates need for terminal, scp, cd, mv, rm, chmod +x, shebang, ./runme.py and ctrl+c)
  • A terminal window for other interaction, like apt-get (Eliminates need for Putty)

This reduces the overall process for new users to:

  • Flashing an SD card with Etcher
  • Setting up a connection
  • Learning Python

There might even be existing IDE that can do all of this. Perhaps it could be forked to bring all this basic functionality to the front while hiding unused functions, and extended where needed.

Alternatively, some IDE's let you create a certain "workspace" or "plugin" or "extension" that may allow one to pre-configure such an environment.

@dwalton76

This comment has been minimized.

Copy link

commented Nov 30, 2016

Maybe start with:
https://github.com/mindsensors/PiStorms?files=1

I haven't done much research on their web UI just throwing out ideas.

@WasabiFan

This comment has been minimized.

Copy link
Member

commented Nov 30, 2016

Great outline! Off the top of my head using tools I'm familiar with, I think that the most realistic potential manifestation of this idea would be the following:

  • Develop an ev3dev extension for Visual Studio Code that includes as much of this as possible. This could even be spun as a generic "remote development" add-in. This would target the standard IDE so that existing users could use it as-is.
  • Fork Visual Studio Code and modify it to be an ev3dev SKU, and package the Python and ev3dev extensions with it. This would likely include basic skinning (e.g. icons) and a more direct route from installation to using the deployment features.

I choose that particular IDE because it is cross-platform and supports many languages so that it can be used for things other than Python. It also has a large set of preexisting extensions, so we might even be able to get an existing SSH and file explorer extension. I'm trying to avoid web-IDEs because they depend on the speed of the EV3 brick in many cases, and upgrading one required getting internet access on the brick and handling the slow installation process (not to mention how little support they get). What do others think? I'm hoping that we can also look into other options like @dwalton76 mentioned. Once Etcher has gotten the "next steps" feature implemented, we'd even be able to advertise this IDE from within the flashing process.

I'll have a lot of free time over the holidays (two weeks from now) so that would be a great time for me to start work on projects like this.

@massimiliano-mantione

This comment has been minimized.

Copy link

commented Dec 1, 2016

IMHO forking VS code would be overkill: it should be extensible enough.
And if for any reason its extension API is not powerful enough (which I really doubt is the case) then Atom would be a better choice (I an sure its extension API is powerful enough).

Maybe, after the EV3 VS code extension is done, it would be nice to have an installer for the combination of VS code (any version we like and know works ok) and any needed extensions.
This would make it a "one stop shop" solution guaranteed to work with EV3 (is that what you meant by "ev3dev SKU"?).

But, that said, if the needed extensions will be properly packaged in the VS code extensions marketplace, the marginal usefulness of the "VS code and EV3 IDE" installer will likely be minimal: installing extensions from within VS code is easy enough, and doable from anybody that installed VS code.

BTW, VS code has in integrated terminal, advanced enough to support ncurses programs (so: definitely usable).
So we have two options for the remote execution of programs:

  • an extension that uses RPyC or something similar
  • an extension that automates logging into the EV3 through ssh using the integrated terminal, remembering the EV3 address and user credentials, preferably integrated with the "file sync" extension so that the "EV3 connection" data is stored only once (and if the brick changes IP address it must be updated only once to have everything working)

Thinking about it, the only missing piece would be this "EV3 connection" extension, that would use other extensions (file sync, terminal, eventually RPyC) so that the user can edit locally but work seamlessly on the EV3.

This setup would also use the VS code Python extension, but would work equally well for any language supported by VS code.

Does this look like a good plan?

Note 1:
There are other extensible IDEs around besides VS code, but I would exclude them for several reasons:

  • the "Eclipse" category of IDEs are too big and complex, and writing extensions for them is equally complex
  • the "emacs or vi" category of extensible editors are not usable by the intended audience

AFAIK the only other contender would be Atom.
In the end it is "almost the same" as VS code (they are very similar, modular, extensible, with a Javascript runtime...).
My feeling (I use both) is that the end user experience would be slightly better with VS code.

Note 2:
I am sort of giving up with the idea of a web based IDE for the EV3, because:

  • fighting with the installation issues is an uphill battle
  • having a 0.10.x nodejs does not help at all
  • waiting for nodejs-chakracode to support jitting on linux-arm will take too long
  • I do not know of suitable web based IDEs that are not based on nodejs
  • the dev experience on a web based IDE would be worse than the one provided by a locally installed VS code anyway (especially the integration of intellisense)
@laurensvalk

This comment has been minimized.

Copy link
Author

commented Dec 1, 2016

Thanks for the input all. An extension/plugin sounds like the easiest approach indeed.

Downloading the standard IDE and installing the ev3dev plugin afterwards is probably fine. (In terms of documentation, it's easy to explain why one would need an ev3dev plugin.)

  • an extension that automates logging into the EV3 through ssh using the integrated terminal, remembering the EV3 address and user credentials (...)

That's what I currently had in mind. Because this is not very Python specific, the same approach can be used for other programming languages, but Python is probably good to start with.

@laurensvalk

This comment has been minimized.

Copy link
Author

commented Dec 1, 2016

There is one thing somewhat more specific to ev3dev that I briefly mentioned above, but I should probably explain it in more detail. This is optional, but more user friendly/intuitive:

When the user presses "Run Program", all of the above steps happen, but there is also some interaction with Brickman. When the program runs, the screen/leds should indicate this, just like you see currently when running something from brickman. Likewise, you would be able to stop the program with the back button. Just like running normal EV3-G programs.

Without this functionality, it's really easy to get confused about what is running, and from where. Especially when a robot is approaching the edge of a table, or breaking up otherwise. There's no easy way to stop it besides looking for the terminal window on your computer, all the while the robot is tearing itself apart (yes, this happens. For now, all my ev3dev robots use a touch sensor as kill switch.)

This also prevents issues with stopping the program when the connection fails (disconnecting the USB cable while running the robot), and you can't accidentally start the program multiple times.

@dlech dlech added the planning label Dec 1, 2016

@JorgePe

This comment has been minimized.

Copy link
Contributor

commented Dec 1, 2016

Maybe I'm pushing to mush but if we have this IDE running on a linux system then we can also run our code directly on it without the need for the EV3 because some LEGO devices are already supported directly through USB (like WeDo 1.0) or UART or even brickpi. So brickman shouldn't be a dependency for this idea (unless we can also run brickman in the linux system).

@laurensvalk

This comment has been minimized.

Copy link
Author

commented Dec 1, 2016

I'm not sure I follow---I believe the point is to make programming the EV3 easier, not eliminate the EV3 :)

There are all kinds of ways to make it really technical, but what I'm looking for is an experience similar to the standard method (User makes program on PC, presses start, robot now moves around independently until program ends.)

Except now with Python.

By making the process similar, except for the language itself, the transition should be easier. They can always move to more advanced stuff later, if they want.

@dlech

This comment has been minimized.

Copy link
Member

commented Dec 1, 2016

When the user presses "Run Program", all of the above steps happen, but there is also some interaction with Brickman. When the program runs, the screen/leds should indicate this, just like you see currently when running something from brickman. Likewise, you would be able to stop the program with the back button. Just like running normal EV3-G programs.

See #790

@JorgePe

This comment has been minimized.

Copy link
Contributor

commented Dec 1, 2016

@laurensvalk when reading your first post, I found myself thinking:

  • I have this ev3dev IDE running on my laptop
  • I write some code for the EV3 and the IDE sends it to the EV3, runs it and may even debug it
  • well, I have some LEGO devices that are supported by ev3dev (like WeDo 1.0) but that are also supported on other linux systems, even non-ev3dev systems like my own Ubuntu laptop since ev3dev release the drivers as a standalone package
  • so, it's great to have this IDE to run my code on the EV3 but it would be also great if this same IDE could run my code on my laptop

I know that this is not what you were thinking when proposing this IDE for education purposes. But if/when we have this IDE, it can be extended for advanced uses, don't you think?

WeDo 1.0 was the first LEGO device that came to my mind but there are some others possible cases that don't require hacking a FTDI cable to a LEGO UART device.

And having the possibility of running code locally as well as remotely would also allow some sort of distributed computing like it is being discussed in other issues.

Another not so good example: I'm using an old LEGO Dacta Interface B right now through a USB to RS232 adapter. Someone proposed already creating an ev3dev driver for the Interface B... that would allow us to use this IDE to control 8 LEGO motors.

@laurensvalk

This comment has been minimized.

Copy link
Author

commented Dec 1, 2016

Ah, that makes sense. I think I misunderstood your previous post, sorry about that.

Yes, a good IDE could definitely make more advanced development more convenient too.

@WasabiFan

This comment has been minimized.

Copy link
Member

commented Dec 2, 2016

Is this a goal that we want to pursue? If so, can we decide on a more concrete list of features and how they're supposed to work? I think this is essentially what has been mentioned here:

  • Auto-configuration of Python lib autocomplete
  • Built-in interface to connect to an ev3dev device
  • Proper mechanism to handle running code on target (using the product of #790)
  • Integrated SSH session
  • File browser or other explorer

There are also some other ideas I've seen:

  • An RPyC interface
  • A remote brickman-style device browser
    • Potentially with the ability to run motors

Focusing on the feasibility of these ideas (focusing on the "main" features), we need to make sure that we choose a platform and technology that will support us. Many editor extension frameworks explicitly prevent you from presenting your own UI, which is something we have to consider. VS Code, for example, lets you display text input dialogs, add status bar items, and register commands, but you can't create your own pane with custom content (although you might be able to hack it together using an "HTML preview"). There are some APIs that make it fairly easy to support our use cases, however: for example, you can spawn a terminal pane within the IDE and have it use an arbitrary executable as the shell, so building an SSH provider should be easy. The file explorer would be the hardest part. Once we figure out what features we're interested in, we can decide on a platform that supports our use case.

@massimiliano-mantione

This comment has been minimized.

Copy link

commented Dec 2, 2016

About the file browser, probably we should focus our resources wisely.

Having it integrated in the IDE might be nontrivial, unless we leverage existing "mount remote FS" solutions.
If we do, then the integration is actually free.

My gut feeling is that for remote file system exploration we should value host file system integration more than IDE integration, and eventually get IDE integration through file system integration.

Something like sshfs would fit perfectly for this use case.
The trouble is windows, which, AFAIK, does not have a command line based client, so automation of the connection from the IDE would not be possible.

My point is that reimplementing a remote file system explorer inside an IDE is doable but IMHO is a complex project with little marginal usefulness (over native file system integration solutions).
Therefore I would not spend time on that, at least not immediately.

I would focus on these basic functions:

  • store the connection info somewhere (likely in the plugin preferences), which means:
    • the ev3 IP address
    • the username (default is "robot")
    • the password (default is "maker" so it would work out of the box?) (and-or ssh key? but for beginners I would stick to passwords at the beginning)
  • copy files to the ev3 "at the right time" (likely on save, likely reusing an already existing extension)
  • open a shell on the ev3 in the integrated terminal
  • run programs remotely (see #790 and note that if we can ssh into the ev3 we might not need RPyC at all: ssh is a more general solution)

(the last two goals are sort of overlapping in functionality, I would implement the cheapest to do 1st and then the other)

Only after these are done we could think about the need of a deeper remote file system integration inside the IDE.

@laurensvalk

This comment has been minimized.

Copy link
Author

commented Dec 2, 2016

About the file browser, probably we should focus our resources wisely. Having it integrated in the IDE might be nontrivial

Aren't there existing solutions for this? In Eclipse, for instance, you can do all of this with the Remote System Explorer plugin. Maybe there are similar solutions for the simpler editors mentioned in this thread?

eclipsepi

See video demo

Basically this ^^ is what I had in mind while writing the first post in this thread. Except using Python, so you can skip the cross compilation.

@WasabiFan

This comment has been minimized.

Copy link
Member

commented Dec 2, 2016

You're right -- there are existing solutions for remote file explorer. For us, it's a matter of finding one that works with out target platform.

@laurensvalk

This comment has been minimized.

Copy link
Author

commented Dec 4, 2016

It looks like there are several existing sftp plugins for Atom. I just tried one called "remote sync" on both a Windows 8 host and a Ubuntu host without problems. Saving the file locally automatically syncs the file to the EV3.

Though this one in particular doesn't seem to display the remote files, and doesn't let you set the executable bit, I think.

Another interesting one, haven't tried this one yet server-script: "Atom editor package to sync files and/or run a script on the server"

@WasabiFan

This comment has been minimized.

Copy link
Member

commented Dec 6, 2016

I do a similar thing with other editors, and I think the workflow works very well. One important issue that we need to keep in mind is that our goal is to build a small ecosystem of beginner-friendly and integrated tools for our editor of choice; just packaging existing tools likely won't do that, as each will have its own connection interface and process. If we want to leverage existing extensions, we need to make sure that there's a programmatic interface by which we can leverage them in our own universal connection utility (or a means to add that ability to the existing extension).

@dwalton76

This comment has been minimized.

Copy link

commented Jan 3, 2017

@fisherds

This comment has been minimized.

Copy link

commented Jan 16, 2017

Is anyone on this list familiar with both Open Roberta and Coding with Chrome for EV3 development? They are similar in various ways just curious if anyone has tried both and has advice for which I should start investing time into. Looking for a non-LabView, blocky programming IDE for a kids camp. I'm leaning towards Coding with Chrome since it can seemingly do both blockly (for the young kids) and text languages (for the older kids), if anyone has used it and has advice. Also I know ev3dev has support for Open Roberta. Not really sure how to even connect to Coding with Chrome. Thanks for any advice.

Coding with Chrome links:

Open Roberta links:

I fine with using a PyCharm as my IDE for my college class that uses ev3dev, but I'm teaching a summer camp for kids and looking for a lighter weight option for the 1st-8th grade kids. We used Enchanting for our NXT robots (http://enchanting.robotclub.ab.ca/tiki-index.php). It was pretty awesome but that developer never did an EV3 version. Just curious if anyone recommended one vs another that has tried both. Enchanting was ahead of it's time for NXT, too bad that project died. Anyway I think I need to pick between Open Roberta or Coding with Chrome as the top EV3 blockly options. I've still tried neither. :(

@dlech

This comment has been minimized.

Copy link
Member

commented Jan 23, 2017

I was playing around with (advanced) text editors this weekend, in particular Atom and Visual Studio Code. I have to say, Atom still feels very "beta" it freezes and crashes frequently and had some interesting quirks (like only doing syntax highlighting for the first 100 chars of a line).

On the other hand, Visual Studio is really slick. And, out of the box, it can do most of the "requirements" laid out in the original post here.

A text file editor. (Eliminates problems with line endings in many editors)

A very full featured one at that.

The ev3dev Python library (for documentation and autocomplete) with examples

There isn't anything built in for this, but it is easy enough to create a virtualenv with ev3dev-lang-python to get the desired results. This shouldn't be too hard to automate.

A connect/disconnect button with ip address field, to connect to the robot (Actual connection procedures remain unchanged. But IDE could point to associated docs.)

Extensions are not allowed to modify the UI, so this is not quite as nice as it could be, but I found a number of extensions that let me connect to the EV3 in various ways. All of these use text files for configuration.

Local (PC) and remote (EV3) file trees (Eliminates need for Filezilla). Either mounted locally or through sftp.

There are quite a few existing extensions for syncing files remotely. I tried the one called "Deploy" and it works very nicely. It even has the option to sync on save.

A "run program" button. This saves the file, sends program and dependencies to robot, makes executable, runs it within brickman, displays output in IDE. (Eliminates need for terminal, scp, cd, mv, rm, chmod +x, shebang, ./runme.py and ctrl+c)

This part is lacking, but we should be able to write our own extension for this.

A terminal window for other interaction, like apt-get (Eliminates need for Putty)

Comes with a built-in terminal.


And the main reason I am bringing this up is that Visual Studio Code can also do remote python debugging! I uploaded 2 new packages to the ev3dev repository last night python-ptvsd and python3-ptvsd (use those instead of pip install ptvsd). Unfortunately, I was not able to get the python3 version to work on EV3 (it works on RPi, but there seems to be some kind of deadlock while attaching to EV3), but the python2 version is working on EV3. So, if anyone gets the python3 version working on EV3, please let me know.

@WasabiFan

This comment has been minimized.

Copy link
Member

commented Jan 24, 2017

I agree on all points; I personally think that we should either find a web-based IDE that works well or use VS Code. It feels to me like the latter option would enable both beginners and advanced users, so I think that is a good course of action to pursue.

Assuming we're willing to write our own extension, I think we can circumvent many of the issues you outlined above as well. Extensions are allowed to depend on other extensions, so we can actually publish an ev3dev extension which packages any others that we want and supplements their functionality. For example, we could add universal connection configuration (along with a status bar item and such) and then feed that to each of the constituent extensions. Additionally -- and this is something I really like about the VS Code extensibility model -- a terminal panel can be loaded with a custom shell executable. So, we could wire it up so that you can open a PuTTY terminal on Windows while using a bash terminal with ssh on Linux. It could also add things like the "run" button.

Unfortunately, I was not able to get the python3 version to work on EV3 (it works on RPi, but there seems to be some kind of deadlock while attaching to EV3), but the python2 version is working on EV3. So, if anyone gets the python3 version working on EV3, please let me know.

Odd; I can't recall if I've used it to debug Python 3, but I can confirm that some variety of Python worked in the past 😆

@ghost

This comment has been minimized.

Copy link

commented Jan 28, 2017

I'm not a big planner/promoter of ev3dev, but here's my thoughts.

  1. Don't go for VS Code. You'll turn any people who don't like Microsoft away. (Although it does run on Ubuntu, it will "send data to Microsoft")
  2. Don't go for a really big IDE where we're only using half the features. That will turn people away.
  3. Do go for something flexible where features can be added/removed as needed. So if a user installs it, and then decides they want a C package, for example, it can be installed, while another user deletes the Python package.

Based on those suggestions, the IDEs I can think of are... Eclipse.

Why Eclipse? Because I think it's pretty flexible. The base package is only 100MB, and hey, I use my Eclipse Android version as a Java programming environment too.

Eclipse is also backed by an open-source community, with many plugins available to the user. Here's a search box for the open-source projects they make:

https://projects.eclipse.org/search/projects

When I put in Eclipse, I get many results. Apparently they divide their source code into sections.

However, your ideas are your ideas. I just wanted to give my two cents on the matter.

PS: If you're going to use Visual Studio Code, I can't help test because it is much too fat for my machine.

@dlech

This comment has been minimized.

Copy link
Member

commented Jan 28, 2017

I think you have Visual Studio Code confused with Visual Studio

@ghost

This comment has been minimized.

Copy link

commented Jan 28, 2017

@dlech I know what Visual Studio Code is. It's different from Visual Studio. It was released recently right?

@dlech

This comment has been minimized.

Copy link
Member

commented Jan 29, 2017

Yes. In that case, I don't understand your statement that it is "much too fat". At 33MB, it is much less "fat" than the 100MB Eclipse base package.

@WasabiFan

This comment has been minimized.

Copy link
Member

commented Jan 29, 2017

I'll preface this by saying that I use Eclipse easily 10x more than I do Visual Studio code, largely out of necessity, so I have a fairly large amount of experience with it. I'll also note that I am easily offended by people ignoring data.

Firstly, directly addressing your bullets...

You'll turn any people who don't like Microsoft away.

If someone is going to refuse to use software just because of the company that sponsors it (keep in mind that it's entirely free, so Microsoft doesn't directly benefit from your use) I am not particularly inclined to accommodate their requests. If they're refusing to evaluate the features and instead looking at the logo on the downloads page, there's little chance that anything else they say is legitimately based on the software. I am looking to make decisions based on the functionality that's best for everyone, not the branding.

Although it does run on Ubuntu, it will "send data to Microsoft"

Eclipse does the same (or at least, it did a year ago). Both programs have the option to disable the telemetry as well. The difference is that Eclipse sends the data to the Eclipse Foundation while VS Code sends it to Microsoft.

Do go for something flexible where features can be added/removed as needed. So if a user installs it, and then decides they want a C package, for example, it can be installed, while another user deletes the Python package.

That applies to both VS Code and Eclipse. The difference is that in Eclipse the process of installing a language extension is arduous and painful, while VS Code is speedy and simple. It even recommends the related extensions when you open up a file!

Based on those suggestions, the IDEs I can think of are... Eclipse.

As you said:

Don't go for a really big IDE where we're only using half the features. That will turn people away.

I think that's reason enough to avoid Eclipse.

Eclipse is also backed by an open-source community, with many plugins available to the user.

I agree; there are many more extensions available for Eclipse. However, from my experience, many of them are chronically broken because they are thrown together by people who don't bother to maintain them. Visual Studio Code has many fewer plugins, but they are higher-quality and have better coverage (their marketplace is here). I think that makes it much easier to support ev3dev work in VS Code.

If you're going to use Visual Studio Code, I can't help test because it is much too fat for my machine.

Both numerically and anecdotally, this is nonsensical. As you said, Eclipse's entirely empty install size is just over 100MB; meanwhile, VS Code for Windows is 50MB with extensions for core languages included (and all supported syntax highlighting). On Linux it's more like 30MB. As for speed, in my timings on Windows, Visual Studio Code takes 5.6 seconds to fully load while Eclipse takes 26 (8.9 to the workspace selection screen, then the remainder until the window loads).


In general, I find VS Code (and many other editors/IDEs) to be much more modern and user-friendly than Eclipse is. As with many GUI apps which are maintained by the community, Eclipse's interface is pretty disjointed and core design choices have clearly been made without sufficient reasoning. I wouldn't subject our users to that.

@ghost

This comment has been minimized.

Copy link

commented Jan 29, 2017

@WasabiFan Let me respond to that:

As for speed, in my timings on Windows, Visual Studio Code takes 5.6 seconds to fully load while Eclipse takes 26 (8.9 to the workspace selection screen, then the remainder until the window loads).

That's probably running on a fast machine. A 1.5 GHz Pentium 4 will probably take longer than that (Eclipse takes about 1min on my machine).
Therefore,

If you're going to use Visual Studio Code, I can't help test because it is much too fat for my machine.

This is entirely a matter of personal opinion. You are free to select whatever you want.

Both programs have the option to disable the telemetry as well.

It has been argued before that in Microsoft programs, the "telemetry disable" option doesn't really disable the telemetry, it disables a small chunk. Personally, I trust open-source better than Microsoft.

@WasabiFan

This comment has been minimized.

Copy link
Member

commented Jan 29, 2017

This is entirely a matter of personal opinion. You are free to select whatever you want.

It's not. You can choose to not use the software -- in that case, refer to my previous post -- and I have no issue with it; however asserting that the comparative preference of Eclipse is based on load speed or install size is entirely erroneous, as my data suggest. Regardless of the speed of one's processor, Eclipse will be slower unless some fantastical optimization kicks in.

It has been argued before that in Microsoft programs, the "telemetry disable" option doesn't really disable the telemetry, it disables a small chunk. Personally, I trust open-source better than Microsoft.

Those two points are contradictory. If you want to inspect the source, go for it. If you'd like to submit a PR to them to add additional options, I'm sure they'd be happy to review it. And there's nothing preventing you from building from source. It is exactly the same as Eclipse in openness -- except for the fact that Microsoft's code is easy to access and contribute to on GitHub, while the Eclipse Foundation has obfuscated that process.


I don't have anything against you and welcome input from others; but baseless attacks get under my skin.

@Joshua-Jurgensmeier

This comment has been minimized.

Copy link

commented May 1, 2017

I will definitely look into it. I think I like the idea of an interpreted language over a compiled one though. It's a little bit simpler. Also, duck-typing is simpler for people who have never programmed before. However, neither of these were really problems with RobotC, so maybe they aren't that important.

Thanks,
Josh

@dlech

This comment has been minimized.

Copy link
Member

commented Jul 26, 2017

VSCode finally affords a bit of UI for extensions (since v1.13). So, here is what I have come up with so far. I think it meets most of @laurensvalk's original criteria (except for the python bits). Please try it out.

https://marketplace.visualstudio.com/items?itemName=dlech.ev3dev-browser

How is your work coming along @WasabiFan?

@WasabiFan

This comment has been minimized.

Copy link
Member

commented Jul 27, 2017

That looks pretty good!

My previous progress was mostly around implementing a proper remote SSH terminal as well as some other related features, plus the ability to remotely run files and make them executable and such. I ran into a blocking issue with constraints that they put on integrated terminals which halted my progress back when I was working on it. It looks like you have implemented most of that by yourself, but I'll take a look when I have access to it and see if I had implemented anything additional.

@laurensvalk

This comment has been minimized.

Copy link
Author

commented Jul 27, 2017

I've just tried it, great work @dlech!

I'll post comments over at the repository, unless you prefer to have it somewhere else.

@dlech

This comment has been minimized.

Copy link
Member

commented Jul 27, 2017

There are more people subscribed here, so for general comments, here is better. For technical issues, at the repository is better.

@JorgePe

This comment has been minimized.

Copy link
Contributor

commented Jul 28, 2017

I'm amazed... never used Visual Studio Code and it was easy, just needed to install the .deb package, add ev3dev extension and python extension and my EV3 appeared, can open an ssh session, transfer code...
(just a minor issue after install .deb with GUI, always crashed, repeated from shell and works fine).

Great work indeed!

@laurensvalk

This comment has been minimized.

Copy link
Author

commented Jul 31, 2017

Currently, all downloaded files have the executable bit set.

Perhaps this could be done automatically for files with a certain known extension (*.py, *.sh etc), but not for others. That might cover most cases while the command line is available for nontrivial situations.

This way a GUI option for toggling the executable bit may not be necessary. That in turn avoids some potential clutter in the right-click menu. (I like the fact that you currently just see "Run".)

Any connected ev3dev device should be automatically discovered. No configuration necessary.

When first using this, it can be a bit tricky to see that something is not working. Would it be possible to have a default text like "No ev3dev devices found" in that list, whenever no ev3dev device is found? (I think I'm experiencing this right now, but I'm not sure)

Error messages will be displayed in the output pane.

I'm not sure whether this is planned, but will it be possible to see a program's output too? Right now, it's printed on the EV3 screen, I think.

Start a remote SSH session

This is a really nice feature. However, the way it is currently initiated from a local terminal could be somewhat confusing to beginning users. This way, the terminal tab has a different function depending on whether one has started an SSH session.

Perhaps the SSH terminal could be on its own tab, appearing only when the SSH session is started? Or, have the additional tab there from the beginning, and have a button on that tab to start the session.

@dlech

This comment has been minimized.

Copy link
Member

commented Jul 31, 2017

Perhaps this could be done automatically for files with a certain known extension (*.py, *.sh etc), but not for others. That might cover most cases while the command line is available for nontrivial situations

I considered checking for files that start with a shebang (#!) and making them executable, but not other files. But, if you use a compiled language, such as Go, then the executable file won't have a shebang or a file extension, so I'm not sure how to identify these sorts of files.

Just going by file extension is probably not a good idea, because if you forget the shebang, then you will get strange (not obvious) error messages when trying to run the file.

When first using this, it can be a bit tricky to see that something is not working. Would it be possible to have a default text like "No ev3dev devices found" in that list, whenever no ev3dev device is found?

After having used it a bit myself, I'm thinking of redoing how connections work. I found that having all available devices listed was annoying. I only want to work with one device at a time. So, I am thinking of adding a "Connect to device" button and command that scans for devices and if there is more than one, lets you pick the one you want to work with. It could also allow for manual entry for cases where device discovery is not working (e.g. it could work for ev3dev-jessie).

Also, I don't want this extension enabled all of the time. I use VS Code for most all of my work these days so I would prefer to have the browser manually triggered by a command. In other words, users wouldn't see anything until they pressed CTRL+SHIFT+P (or F1) and ran the "Connect to ev3dev device..." command.

I'm not sure whether this is planned, but will it be possible to see a program's output too? Right now, it's printed on the EV3 screen, I think.

Yes, this is planned. It is done for those who want to use the screen but don't want to have to learn how to use graphics mode. Any debug messages that should appear should in the VS Code output window should be written to stderr. Any messages that should be displayed on the screen should be written to stdout.

Perhaps the SSH terminal could be on its own tab, appearing only when the SSH session is started? Or, have the additional tab there from the beginning, and have a button on that tab to start the session.

This is a limitation of VS Code. You cannot add "tabs" in the "panel". The 4 "tabs" (problems, output, debug console and terminal) are fixed. Once you use VS Code for a while, you understand how they work.

There can be multiple terminals. But, instead of adding tabs, they are selected from a combo box. I have given the terminal the name of the ev3dev device, so that is what shows up in the combo box. I think this is the best we can do currently and it fits with the VS Code paradigm. (The output tab works the same way, our output is one of many selected from a list.)

selection_014

@dlech

This comment has been minimized.

Copy link
Member

commented Jul 31, 2017

BTW, if there are any Javascripters out there that would like to take over this project, be my guest. 😃

@WasabiFan

This comment has been minimized.

Copy link
Member

commented Jul 31, 2017

@dlech If you open issues over there for contributions you're interested in, I might take on a few!

@WasabiFan

This comment has been minimized.

Copy link
Member

commented Jul 31, 2017

I haven't gotten a chance to play around with this yet (Etcher was throwing a fit and I didn't have the time to find an older version) but it certainly looks like exactly what we want. Some thoughts:

  • It sounds like it attempts to auto-detect devices. Could we also add a palette command for "direct connect"?
  • It would be nice to add a status bar item which showed the device(s) you were connecting to and their status.
  • I think SSH terminals should be labelled with the device name prepended with SSH: or similar to indicate what that terminal is
  • Are there any oddities in the rendering of SSH output, e.g. double SSH prompts or rendering issues with colors and similar complex escape codes?
  • What do those green circle icons indicate? Are they placeholders or is there a meaning?
  • It would be interesting to look into the usefulness of a "upload file from device" button/command which let you copy files the other direction (e.g., data or logs).
  • We should document this on the 'site and in the appropriate guides once it's in a reasonable state.

Yes, this is planned. It is done for those who want to use the screen but don't want to have to learn how to use graphics mode. Any debug messages that should appear should in the VS Code output window should be written to stderr. Any messages that should be displayed on the screen should be written to stdout.

Does this mean that you don't plan to output stdout to the VSCode window? I think that we should output both streams to the VSCode console; separating them would confuse users, and it's hard to read + copy the text on the display.


I'd be happy to open PRs for any of those features if we're interested in pursuing them. Great work!

@dlech

This comment has been minimized.

Copy link
Member

commented Jul 31, 2017

It sounds like it attempts to auto-detect devices. Could we also add a palette command for "direct connect"?

Yes. I am thinking this is a good idea. My thought is that the command will show a list of discovered devices which you can select or you can type in a hostname or IP address manually.

It would be nice to add a status bar item which showed the device(s) you were connecting to and their status.

What do those green circle icons indicate? Are they placeholders or is there a meaning?

The green circle means that the device is connected. yellow means connecting and red means disconnected. I did this instead of having something in the status bar. I would like to avoid the status bar if possible since it tends to get a bit cluttered.

Are there any oddities in the rendering of SSH output, e.g. double SSH prompts or rendering issues with colors and similar complex escape codes?

When we open an ssh terminal, it is just typing ssh robot@<address> for you. On Windows, we are using plink.exe so you have to have PuTTY installed. So, if there are any oddities, it is a VS Code bug. I haven't noticed any though.

I think SSH terminals should be labelled with the device name prepended with SSH: or similar to indicate what that terminal is

👍

It would be interesting to look into the usefulness of a "upload file from device" button/command which let you copy files the other direction (e.g., data or logs).

👍 It should be simple enough to add a context menu item for this.

We should document this on the 'site and in the appropriate guides once it's in a reasonable state.

Of course.

Does this mean that you don't plan to output stdout to the VSCode window?

Here is how I see it going down...

Hypothetical conversation if stdout goes to VS Code.

  • New user: How do I display text on the screen of the EV3?
  • Expert: Well, first you have to put the console in graphics mode.
  • New user: How do I put the console in graphics mode?
  • Expert: Well you have to use an ioctl
  • New user: What is an ioctl?
  • Expert: Never mind. We can cheat and just turn off the cursor.
  • New user: How do you turn off the cursor.
  • Expert: setterm --cursor off
  • New user: OK, now what?
  • Expert: Now you need a graphics library.
  • New user: OK, which library should I use?
  • Expert: Well, that depends on which programming language you are using. For some languages, you may have to write your own.
  • New user: :-/

Hypothetical conversation if stdout goes to console on the device.

  • New user: How do I display text on the screen?
  • Expert: echo "hello world" or your programming language's equivalent of printf().
  • New user: OK, that works, but the text is too small, I can't read it.
  • Expert: Use setfont Lat15-Fixed13 to make the font bigger. You can find a list of fonts by running ls /usr/share/consolefonts/Lat15* in an SSH terminal.
  • New user: Awesome thanks!
  • New user: How do I print debug messages and have them show up in VS Code?
  • Expert: echo "hello debug" 1>&2 or your programming language's equivalent of fprintf(stderr, ...).
  • New user: Thanks again!
  • Russian user: I want to use a Cyrillic font to write in Russian.
  • Expert: #904

So, you can see why I'm pushing to make it this way. There are a few things to learn, but they are very simple.

Another thing to consider is what happens when you run the program directly from the brick. Where is stdout supposed to go in that case? If people get used to it being redirected to to VS Code, they might wonder why their program behaves differently (e.g. junk displayed on the screen) that doesn't happen when they run remotely.

it's hard to read + copy the text on the display.

But error messages use stderr and this is what you usually want to copy, so they will be easily copied in the VS Code output panel. If your python program crashes, the stack track will show up in VS Code.

Furthermore, we can add a "screenshot" button to our extension. 😃

@dlech

This comment has been minimized.

Copy link
Member

commented Jul 31, 2017

FYI, I've transfered the git repository to https://github.com/ev3dev/vscode-ev3dev-browser, so if anyone wants to watch it, open issues, write wiki page or whatever, it is open for business.

@WasabiFan

This comment has been minimized.

Copy link
Member

commented Aug 1, 2017

I think the core of your reasoning on the terminal vs. display is sound. Certainly, the goal of avoiding all that complexity to write to the display is a good one. However, I'm worried that we'll never get to have those conversations you're describing because people will be dissuaded before they get that far.

Some thoughts /questions:

  • Why would it be an issue that the default way to display text on the screen is also the default way of displaying text in the console? Why do we want to separate them?
  • If you're a teacher using this as a teaching tool, how do you explain to your students that you need to use stderr in this case but every other program should use stdout? (the error stream is rarely taught in an introductory course at all, and repurposing it makes things that much more difficult.)
  • In my mind, outputting to the VSCode console is the "default" expected action. Why not use stderr for the display and stdout for the terminal?
  • Could we design this a setting? Or a custom escape code for writing to the display and provide helpers in common languages?
  • How do we communicate this design choice effectively?

To me, it feels like the kind of hack that an experienced developer would understand and a beginner would be completely confounded by.


When running on the brick, I would either expect all output to go to the display or to split it between the display and a log file in the same way we would split it between the display and VSCode's terminal.

I like the screenshot button idea!

@dlech

This comment has been minimized.

Copy link
Member

commented Aug 1, 2017

Why would it be an issue that the default way to display text on the screen is also the default way of displaying text in the console? Why do we want to separate them?

I don't understand the question. The screen is the console.

If you're a teacher using this as a teaching tool, how do you explain to your students that you need to use stderr in this case but every other program should use stdout?

I should let the teachers here answer this one, but IMHO, using stderr for debug messages is not a bad thing to do in general.

In my mind, outputting to the VSCode console is the "default" expected action. Why not use stderr for the display and stdout for the terminal?

OK, I think when you say "the VSCode console", you mean the output panel. The output panel is for logging error messages (including debug messages). That is it. It is not interactive. It is not a terminal.

If we switch things around, then your python stack trace from your crash will print on the EV3 screen (because python prints error messages to stderr like any well behaved program), which is totally not what we want.

Could we design this a setting? Or a custom escape code for writing to the display and provide helpers in common languages?

You are making this harder than it needs to be. 😃

How do we communicate this design choice effectively?

With sample code...

#!/usr/bin/env python3

import os
import sys
import time

os.system('setfont Lat15-Fixed14')  # make the font big enough to read
print('Hello World!')  # print to EV3 screen
print('Hello VSCode!', file=sys.stderr)  # print to VSCode output panel
time.sleep(5)  # allow some time to see what we printed
@WasabiFan

This comment has been minimized.

Copy link
Member

commented Aug 1, 2017

I don't understand the question. The screen is the console.

The primary "console" that a user is aware of is the output window in VSCode. The technical implementation is opaque to the user.

If my EV3 is in a robot frame and I want to be able to iterate on code, being forced to look at the screen in any capacity is going to make my life difficult. Screenshotting helps, but isn't a real solution.

OK, I think when you say "the VSCode console", you mean the output panel. The output panel is for logging error messages (including debug messages). That is it. It is not interactive. It is not a terminal.

You are making this harder than it needs to be. 😃

To me, our extension is logically the equivalent of running your app locally with the typical "run" configuration, but have it execute on your EV3 instead -- in other words, just as a local Python app's stdout and stderr streams would be redirected to the output window, I would expect those of a remote one to do the same. Any additional functionality intended to let me write to the screen is an extra capability that I would expect to require an additional action. While it might be more complicated for us, it's easier for a consumer.

@laurensvalk

This comment has been minimized.

Copy link
Author

commented Aug 1, 2017

print('Hello World!')  # print to EV3 screen
print('Hello VSCode!', file=sys.stderr)  # print to VSCode output panel

^^^ I think this is great! (Both from a user and a teacher point of view).

And since there is a Python library, that last one can always be turned into a command that's easier to remember and indicative of where it's printed. (And which does not make it sound like an "error").

@Joshua-Jurgensmeier

This comment has been minimized.

Copy link

commented Aug 15, 2017

Works awesome! One question, what is the plan going forward for combining this extension with the ev3dev Python library? To me, it seems like there are two options:

A. An extension that includes the current functionality and all language bindings (autocomplete/docs). Named something like "ev3dev".

B. One extension that includes the current functionality and separate extensions for each language binding. Respectively named something like "ev3dev-browser" and "ev3dev-language" (e.g. "ev3dev-python").

The former seems better, as it is simpler for the end user to setup. I don't know what affect this would have on complexity behind the scenes. As mentioned previously (somewhere way up there), getting the Python library integrated with the extension would be the first priority.

@dlech

This comment has been minimized.

Copy link
Member

commented Aug 15, 2017

Ev3dev at it's core is language-agnostic, so we won't be including anything python-specific in the core plugin.

That is not to say that an ev3devPython plugin could not be created that depends on the ev3devBrowser plugin (and the existing VS Code python plugin) so that you get the "one-click" install experience.

However, my experience so far with python in VS Code tells me that there is quite a bit of complexity involved in getting a one-click python solution.

So far, my preferred way of doing it is:

  • install python 3.5 (this matches ev3dev-stretch)
  • install virtualenv (pip install virtualenv)
  • create a new ev3dev virtualenv (virtualenv ev3dev --python=/path/to/python3.5)
  • run the virtualenv in a terminal (ev3dev/scripts/activate)
  • install python-ev3dev in the virutalenv (pip install python-ev3dev)
  • launch VS Code from that terminal so it uses the virtualenv (code /path/to/project)
  • then the VS Code python extension will do it's magic with autocompletion and whatnot.

I think people are just going to have to play with this and try all the possibilities, then if someone comes up with a really slick way of doing things, we could make an extension out of it.

@dlech

This comment has been minimized.

Copy link
Member

commented Aug 16, 2017

v0.2.0 of the VS Code extension is released. Play with it and let us know what you think.

@dlech

This comment has been minimized.

Copy link
Member

commented Aug 17, 2017

I've added a python hello world to help people get started.

https://github.com/ev3dev/vscode-hello-python

@dlech

This comment has been minimized.

Copy link
Member

commented Aug 26, 2017

v0.3.1 of the VS Code extension is released. It's starting to feel less alpha and more beta.

🎉 This release has a major new feature to build, download and run with a single click or key press. (And a slightly less major, but very cool screenshot feature thanks to @WasabiFan).

The only missing major feature at this point is stopping motors when things go bad.

@dlech

This comment has been minimized.

Copy link
Member

commented Aug 28, 2017

I've added a Go hello world as well. https://github.com/ev3dev/vscode-hello-go

cc: @kortschak

@kortschak

This comment has been minimized.

Copy link
Member

commented Aug 29, 2017

I considered checking for files that start with a shebang (#!) and making them executable, but not other files. But, if you use a compiled language, such as Go, then the executable file won't have a shebang or a file extension, so I'm not sure how to identify these sorts of files.

Just going by file extension is probably not a good idea, because if you forget the shebang, then you will get strange (not obvious) error messages when trying to run the file.

file will return that these are ELF, so you can sniff that.

I've added a Go hello world as well. https://github.com/ev3dev/vscode-hello-go

That LGTM. Thanks.

On a tangentially related note to this thread. The sisyphus package in ev3go is intended to be, in addition to being a testing framework package, a mechanism to allow simulation of an ev3dev device on an arbitrary host machine. This can be used to testing code before applying it to an actual robot. In the long run this would benefit from having a physics engine backing it, but for simple task it suits as it stands.

@dlech

This comment has been minimized.

Copy link
Member

commented Aug 29, 2017

file will return that these are ELF, so you can sniff that.

Hmm... that might work. I suspect that Windows does not have a built-in file command, so we would have to run it on the remote device.

@dlech

This comment has been minimized.

Copy link
Member

commented Sep 5, 2017

v0.4.0 of the VS Code extension is released.

Suggestions from #788 (comment) are implemented. There is also now a way to enter an IP address if automatic discovery is not working.

I think I'm going to call this issue closed. Please open new issues for any feature requests or bug reports.

@dlech dlech closed this Oct 3, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.