#Successors to Mu

1 messages · Page 1 of 1 (latest)

fluid yacht
#

I just saw this announcement this morning in the Mu repo, and am sorry to see this. Thank you ntoll and friends very much for Mu, which served us so well as the "easy editor" for beginners. Given the long time since the last release, we have already been thinking about how to move on. I welcome CircuitPython users' thoughts in this thread.

rustic jolt
#

Could Adafruit take over the project? Maybe as a CircuitPython specific editor (without all the other coding modes)? blinkacomputer

fluid yacht
#

The problem as I see it is that Mu became a project that had to be as much or more about about packaging as editing, in order to be able to run on a wide variety of platforms, including obsolete ones. We have to get away from that problem: I think the easiest way is to push the packaging/compatibility issues onto something else, which means a browser, for browser-based editors, or a widely-available base platform, like VSCode.

subtle wave
#

Wow. A huge thanks to ntoll and volunteers on the Mu project. I've used Mu to teach CircuitPython to classmates, at hackerspaces and events. I think the two points ntoll makes here is pretty important to the discussion as a whole, too. "Almost ten years later, there are lots of well funded and supported tools that fulfil the reason Mu was created."

#

In the context of education - I’m sure an educator could elaborate on this better than I can - a browser-based tool like code.circuitpython.org might be the most accessible option. Educational budgets are often tight like ntoll mentioned in this blog post and Chromebooks are particularly popular in USA K-12 settings.

brave parrot
#

Kind of sad since learning I naturually went with what Adafruit recommended and it has done the job well. But I have often wondered if there were other editors that would offer more feature but still have some of the basic easiness of use that MU offered. But I only casually looked into it. That said...

With the concept of a browser based editor, would this require the board be on the same network as the editor, or while browser based, would it still be able to communicate to development boards directly via the USB port? And would the browser editor be available for use offline?

hoary blade
#

Thank you for the supportive messages folks.

What @fluid yacht says is true: in order to try to support as many weird, old, shonky and slightly strange computing setups one often finds in schools, we've had to really struggle to get Mu's installation and packaging story working. This is a headache I wouldn't wish on anyone.

My day job is working on PyScript (Python in the browser), and we find that space is full of all sorts of technical challenges... but "installation" isn't one of them... just point your browser to a URL. Alas, the web is the last truly open platform sans-walled gardens.

#

WRT browser based editors... browser based USB-serial APIs are mature enough for plug-in-and-play AFAICT.

rustic jolt
#

I am not an educator, but a couple of weeks ago I held my first workshop teaching CircuitPython on the Circuit Playground Express. Since the event was only about 2 hours long, Mu was the best tool to get people up and running very fast, and let them focus on the code, not toolchain setup.

I love Mu and its ease of use, and I'll be sad to see it go -- thank you ntoll, and everyone else who worked on it!

I guess the next best thing are the online editors like https://code.circuitpython.org/ or https://viper-ide.org/ , though they are not quite as plug-in-and-play as Mu yet -- they need a couple of extra steps to connect -- and they are not available offline, nor on all browsers.

fluid yacht
#

and they are not available offline.
Could a local copy serve that purpose? Sometimes browser security restrictions prevent that.

wet stone
hoary blade
hoary blade
#

(i.e. you're escaping their walled garden via the web).

#

FWIW I sometime wonder about recreating Mu but as a PyScript application... but then I remember there are only 24 hours in a day.

fluid yacht
severe bone
#

For a workshop series I did back in August, I settled on thonny.

I did test Mu but encountered a bug which was frustrating me and was going to frustrate the audience.

I had to explain thonny's "one quirk" but at the same time I was able to optimize the workshop by taking advantage of the quirk.

Quirk:

Thonny does something unique - when using the RUN command or button. It loads the current Python code from the editor into the board's active memory and executes it. By default the code is not saved on the board. This is great for quickly developing and debugging code, but it can be confusing when it's time to make the code persist.
For teaching, this "code not written to the hardware" was an advantage because students could jump from exercise to exercise without having to repeated copy code to the hardware. They would just open an example, look at the code and click "run".

severe bone
hoary blade
hushed yoke
#

I tried to work around browser limitations with an Electron app, but that does have its own... complications in terms of multi-platforming. I don't actually want to make Discotool Manager (I guess that's what I call it) into a real (if simple) editor outside of the minimum necessary to do quick edits, but you know if I can just plug some features into it from an existing javascript library, eh why not. (I'm using CodeMirror). I have actually be using it to edit files on ESP32-C3 boards with ease