Good name for interpreter binary #17

pfalcon · 2014-01-01T01:40:04Z

I wanted to write that "py" name is a bit too generic, and if every python-related project seized that name, there would be conflicts. Well, there're conflicts, from http://docs.python.org/3/whatsnew/3.3.html :

The Python 3.3 Windows installer now includes a py launcher application that can be used to launch Python applications in a version independent fashion.

More info: http://docs.python.org/3/using/windows.html#launcher

So, it would be good idea to come up with a more unclashy name. IMHO, "upython" would be both consistent, clear to users and unique - and based on idea that "u" is common way to represent Greek letter "mu" for "micro"; "mpython" would mean "minipython". But even "mpython" is better than current "py".

And this is of course borders on the question raised in Kickstarter comments - on project shortname/nickname to use in context where full "MicroPython" is too long.

The text was updated successfully, but these errors were encountered:

Mrjohns42 · 2014-01-01T01:41:37Z

I'm in favor of upython

Dr-Syn · 2014-01-01T01:42:52Z

Given that chickenpotpython would probably fly over people's heads, I
suppose I'll have to vote for upython as well.

On Tue, Dec 31, 2013 at 5:40 PM, Paul Sokolovsky
notifications@github.comwrote:

I wanted to write that "py" name is a bit too generic, and if every
python-related project seized that name, there would be conflicts. Well,
there're conflicts, from http://docs.python.org/3/whatsnew/3.3.html :

The Python 3.3 Windows installer now includes a py launcher application that can be used to launch Python applications in a version independent fashion.

More info: http://docs.python.org/3/using/windows.html#launcher

So, it would be good idea to come up with a more unclashy name. IMHO,
"upython" would be both consistent, clear to users and unique - and based
on idea that "u" is common way to represent Greek letter "mu" for "micro";
"mpython" would mean "minipython". But even "mpython" is better than
current "py".

And this is of course borders on the question raised in Kickstarter
comments - on project shortname/nickname to use in context where full
"MicroPython" is too long.

—
Reply to this email directly or view it on GitHubhttps://github.com/dpgeorge/issues/17
.

piranna · 2014-01-01T02:46:02Z

+1 to upython

Send from my Samsung Galaxy Note II
El 01/01/2014 02:42, "Dr-Syn" notifications@github.com escribió:

Given that chickenpotpython would probably fly over people's heads, I
suppose I'll have to vote for upython as well.

On Tue, Dec 31, 2013 at 5:40 PM, Paul Sokolovsky
notifications@github.comwrote:

I wanted to write that "py" name is a bit too generic, and if every
python-related project seized that name, there would be conflicts. Well,
there're conflicts, from http://docs.python.org/3/whatsnew/3.3.html :

The Python 3.3 Windows installer now includes a py launcher application
that can be used to launch Python applications in a version independent
fashion.

More info: http://docs.python.org/3/using/windows.html#launcher

So, it would be good idea to come up with a more unclashy name. IMHO,
"upython" would be both consistent, clear to users and unique - and
based
on idea that "u" is common way to represent Greek letter "mu" for
"micro";
"mpython" would mean "minipython". But even "mpython" is better than
current "py".

And this is of course borders on the question raised in Kickstarter
comments - on project shortname/nickname to use in context where full
"MicroPython" is too long.

—
Reply to this email directly or view it on GitHub<
https://github.com/dpgeorge/micropython/issues/17>
.

—
Reply to this email directly or view it on GitHubhttps://github.com/dpgeorge/issues/17#issuecomment-31417057
.

Neon22 · 2014-01-01T02:59:40Z

I also agree with upython.
But I counter propose mupython. Because:

mu is umabiguous (although u is short for mu - mu is also generally accepted).
having an m at the start associates it more easily with micro python
mu is less likely than u to clash with future projects
strangely its longer and therefore easier to spot as not a misspelling.

but of course upython is shorter...

fogleman · 2014-01-01T03:00:56Z

upython - 👍

migbot · 2014-01-01T03:02:35Z

mupython +1

redteam316 · 2014-01-01T13:07:22Z

mupython is much better.

piranna · 2014-01-01T13:20:58Z

I voted for upython, but after reading the topic, I think now mupython is a
better name, although uPy ir more "scientific" it's true that not so much
people would understand it, so muPy would be a better abreviation.

2014/1/1 Jonathan Greig notifications@github.com

mupython is much better.

—
Reply to this email directly or view it on GitHubhttps://github.com/dpgeorge/issues/17#issuecomment-31422671
.

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton
de sitios diferentes, simplemente escribe un sistema operativo Unix."
– Linus Tordvals, creador del sistema operativo Linux

VitalSparkPlug · 2014-01-01T15:33:31Z

Damien's major effort needs an easy 'hook'
mupython mpython ..doesn't quite do it for me.

Its embedded python. ... pythembed embedpy
easily part of network of things ... pything PyTing
Damien's Python DamPython DamPy
George... Georgie Porgie :-) Bet you never heard that before ! :-| PudPy ....Its so sweet?! and has Pie reference

Any non-pom (Non-English) scratching their head by now?
Its from an English nursery rhyme
Georgie Porgie, Puddin' and Pie,
Kissed the girls and made them cry,
When the boys came out to play
Georgie Porgie ran away

Well ,Damien, Pick something with typing ease that ISN'T google search aliased already!!!
Example ... I search for Arduino CNC GCode to Stepper translator "GRBL" alot...
GRBL is the base code.... and people have made derivatives with "GRBL" some where in the name.
finding GRBL and its derivatives is so easy...Good google presence will really help with adoption. IMHO

Hugh Wallace

On Jan 1, 2014, at 6:21 AM, Jesús Leganés Combarro notifications@github.com wrote:

I voted for upython, but after reading the topic, I think now mupython is a
better name, although uPy ir more "scientific" it's true that not so much
people would understand it, so muPy would be a better abreviation.

2014/1/1 Jonathan Greig notifications@github.com

mupython is much better.

—
Reply to this email directly or view it on GitHubhttps://github.com/dpgeorge/issues/17#issuecomment-31422671
.

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton
de sitios diferentes, simplemente escribe un sistema operativo Unix."
– Linus Tordvals, creador del sistema operativo Linux
—
Reply to this email directly or view it on GitHub.

KeithJRome · 2014-01-01T18:08:08Z

I am a fan of "muPy" or "uPy" (which would be the nickname for the official long name "MicroPython") because it falls in line with other well-known Python libraries and platforms. For example, NumPy, SciPy, FePy, PyPy.

dpgeorge · 2014-01-01T21:43:46Z

Let me first say that the unix port was initially intended just for testing purposes, not suited for the real world. Hence the poor choice of binary name.

It looks like the unix port is gonna get some legs, so, yes, we need a better name.

In the code, I use "mp_" for everything Micro Python related. I like that because it's short and the simplest abbreviation for "Micro Python". "up_" would have been strange. "upy_" would have been okay, "mupy_" reads like muppet and is long :) So that's my rationale for function/type names in C.

For binary, I would say either upython or mupython.

Also I need a name for the board, since I want to make a separate repo for that (see update #18).

fogleman · 2014-01-01T21:47:10Z

mp_ is fine for code, IMO.

upython reminds me of uWSGI. I don't think it will be lost on people that it means "micro."

piranna · 2014-01-01T21:55:16Z

Also I need a name for the board, since I want to make a separate repo for
that (see update #18 #18
) 8000 .

Some days ago I proposed to use "pyb" both in reference to "PYthon Board"
and also because it's being used on the code examples to reference to the
board components, and some people agried it was a good name... :-)

By the way, where are the code examples? Could you be able to upload them
to (another) repo? :-)

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton
de sitios diferentes, simplemente escribe un sistema operativo Unix."
– Linus Tordvals, creador del sistema operativo Linux

pfalcon · 2014-01-01T22:00:53Z

By the way, where are the code examples?

Wanted to ask that too.

Could you be able to upload them to (another) repo? :-)

IMHO they belong to the main repo, let's not spread too thin.

redteam316 · 2014-01-01T22:04:39Z

Look how many people here have actually posted μ instead of u for the binary name. Nobody. Using u is clearly wrong to start with. Also, for any OS that supports symbolic linking, it's not a major problem to provide the alternate spelling, I think it makes more sense to use mupython officially.

The pyb made immediate sense to me for the board.

piranna · 2014-01-01T22:08:27Z

Could you be able to upload them to (another) repo? :-)

IMHO they belong to the main repo, let's not spread too thin.

Inside a "examples" folder like Node.js projects does, for example? Ok, I
agree on that :-)

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton
de sitios diferentes, simplemente escribe un sistema operativo Unix."
– Linus Tordvals, creador del sistema operativo Linux

torwag · 2014-01-01T22:26:35Z

Maybe I did not understand it right, but you are discussing that you want
to find a name for the python module called by micropython to access the
internal functions of the stm controller?

If not just stop reading here ;)

Since the project is called micropython, I see no problem to call the
module micropython as well.
There are two scenarios.

One reads some python code and finds a command like "import mpy". I find
it requires some extra neurons to figure out that the project micropython
provides the module mpy. Basically, you would start to google mpy and just
by chance find out that www.micropython.org is the home of mpy.
Someone learns about micropython and it might just confuse him to find
snippets like mpy.ad(3), since mpy would not tell him anything what is
going on. I would prefer a more task related name.

I guess other projects do similar. I believe there is no real benefit
shorten micropython by using mpython or mupython rather then saving a few
keypress. Many people do something like "import micropython as mp" anyhow.

The only drawback using micropython as name would be that there is a fear
that people would believe that micropython is "only" a python module, since
it is much more then this. But even then, I do not see a problem giving a
module the same name the larger project.

However, if you believe you need to separate the module name from the
project name, I would even go all the way to call the module
stm_io. Since we might have a pic_io, propeller_io and atmel_io later.

Just a total different idea ;)

Torsten

On 1 January 2014 16:33, Hugh Wallace notifications@github.com wrote:

Damien's major effort needs an easy 'hook'
mupython mpython ..doesn't quite do it for me.

Its embedded python. ... pythembed embedpy
easily part of network of things ... pything PyTing
Damien's Python DamPython DamPy
George... Georgie Porgie :-) Bet you never heard that before ! :-| PudPy
....Its so sweet?! and has Pie reference

Any non-pom (Non-English) scratching their head by now?
Its from an English nursery rhyme
Georgie Porgie, Puddin' and Pie,
Kissed the girls and made them cry,
When the boys came out to play
Georgie Porgie ran away

Well ,Damien, Pick something with typing ease that ISN'T google search
aliased already!!!
Example ... I search for Arduino CNC GCode to Stepper translator "GRBL"
alot...
GRBL is the base code.... and people have made derivatives with "GRBL"
some where in the name.
finding GRBL and its derivatives is so easy...Good google presence will
really help with adoption. IMHO

Hugh Wallace

On Jan 1, 2014, at 6:21 AM, Jesús Leganés Combarro <
notifications@github.com> wrote:

I voted for upython, but after reading the topic, I think now mupython
is a
better name, although uPy ir more "scientific" it's true that not so
much
people would understand it, so muPy would be a better abreviation.

2014/1/1 Jonathan Greig notifications@github.com

mupython is much better.

—
Reply to this email directly or view it on GitHub<
https://github.com/dpgeorge/micropython/issues/17#issuecomment-31422671>
.

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un
monton
de sitios diferentes, simplemente escribe un sistema operativo Unix."
– Linus Tordvals, creador del sistema operativo Linux
—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHubhttps://github.com/dpgeorge/issues/17#issuecomment-31424544
.

piranna · 2014-01-01T22:37:35Z

Maybe I did not understand it right, but you are discussing that you want
to find a name for the python module called by micropython to access the
internal functions of the stm controller?

We are discussing three names here:

The main one, the name of the virtual machine. In the same way as
CPython, Jython, IronPython, PyMite and TinyPy, it's being discussed to use
uPython o muPython or similars.
The name of the board itself. Almost nothing discussed yet, but pyb seems
a good candidate :-)
Name of the platform-dependent module, plainly nothing discussed, but
probably the same name as the board (pyb for the STM/MicroPython Board,
arduino for Arduino, etc)

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton
de sitios diferentes, simplemente escribe un sistema operativo Unix."
– Linus Tordvals, creador del sistema operativo Linux

pfalcon · 2014-01-01T22:48:49Z

We are discussing three names here:

Actually, as the title says, this ticket was opened to discuss solely the name of a binary executable file produced by checking out the source code from the repo, going to "unix" subdir, and running "make". Though yeah, people started to discuss 3 other things here too ;-).

torwag · 2014-01-02T00:07:38Z

Ok in that case
I vote for

micropython for the bin (which would be equal to mi) on my zsh shell
and hence, I do not care for long names). However, I dislike if the main
exec file calls differently compared to the package name and I guess the
package name would be micropython in most cases.
micropython board for the board name, just to get it clear, this is the
official board from the micropython project. Please do not use silly names
like the arduino does. Still mixing up UNO, DUE or Duemilanove, or
Diecimila. Anyhow, I would limit the official micropython board to a single
board at a time. This board should be the reference design. A first
starting point for new users and a reference source for experienced users
and other projects to create individual third party designs. After all,
micropython the software will run on a much more third-party devices later.
Hence, I would go with a simple number... micropython board V1, V2, V3,
etc. with sub-numbers for smaller revisions like V1.1 etc. Hmmm... later,
there is a need how to distinguish between officially supported processor
families and those which might receive a port outside of the micropython
core developme 8000 nt.

and

stm_io (or a derivate if you dislike _ in module names) for the module
name which clearly indicates what it is doing.
Further I would vote to call the module names by the microcontroller family
instead of using the board name, this would help to indicate that
micropython runs in theory on all boards including the same processor.
However, that would require to keep the pin assignments and other parts of
the module flexible enough.
Is there any plan to introduce a config file system to address different
boards in the future, thus that one could call.

import stm_io
stm_io.loadconfig("micropython.config")

and all I/O assignments would be readily set for the micro python board
(sure None could look-out for a default file name).

Well guess this is getting OT ;)

Greetings

Torsten

On 1 January 2014 23:48, Paul Sokolovsky notifications@github.com wrote:

We are discussing three names here:

Actually, as the title says, this ticket was opened to discuss solely the
name of a binary executable file produced by checking out the source code
from the repo, going to "unix" subdir, and running "make". Though yeah,
people started to discuss 3 other things here too ;-).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/17#issuecomment-31432080
.

dpgeorge · 2014-01-02T13:23:54Z

Okay, let's keep this issue for it's original title, to discuss the binary that at the moment is unix/py.

The board/hardware is now in a separate repository called pyboard.

davidedb · 2014-01-02T14:24:08Z

I vote for "micropython": this is a fine name, easy to read and remember and to google for.
In fact a simple Google search for micropython takes to the project-related pages.
On the contrary the other names seems already used by other projects:

mpython referes to Monad-Python (https://github.com/dpiponi/Monad-Python);
mupython is an already existing project (https://github.com/laou/MuPython)
upython is used by a couple of existing projects (http://sourceforge.net/projects/upython/ and https://github.com/Enome/uPython)

jonsg · 2014-01-02T14:42:03Z

Folks, how about "mipy" (pronounced "My-Pie")?

It's brief, doesn't appear encumbered by existing use, and doesn't have any negative associations in any (human) language I know.

I don't really want to be typing "micropython" every time I run it, and I don't think I'm alone in that!

redteam316 · 2014-01-02T14:53:12Z

Considering the info David mentions, micropython should really be the name for the interpreter. No nonsense or shortening of the name and is likely what someone would first type into the terminal if they cannot remember exactly.

Eventually this may make it's way into Debian/Ubuntu repositories (or at a minimum, a package provided at micropython.org) and the package should be named micropython.

I.E.
apt-get install python
python

apt-get install micropython
micropython

There are numerous other packages that work the same way. Just keep it simple.

As for the length of the binary name, anyone wanting to do multiple runs should be using a terminal where pressing up brings up the last issued command. I type micropython once and edit the file I want to run accordingly.

Like I mentioned before, create symbolic links for the shortened name(s) when it is determined. Typing the full micropython should "just work". All of the major OS support symbolic linking, if your still running XP, upgrade or use a batch script.

Dr-Syn · 2014-01-02T14:57:00Z

In most cases, you won't be running 'micropython' directly at all; it'll be loaded on the embedded system where it's supposed to execute. In the other cases, tab completion exists ;-)

garbas · 2014-01-02T15:30:26Z

micropython 💯

if project is called micropython and this repository is called micropython it just makes perfect sense to also call binary that way. its just intuitive everything else assumes something. if somebody finds it hard to type (which is funny since autocomplete exists since before i was born) there is always a possibility to create aliases...

pfalcon · 2014-01-02T16:15:53Z

In the other cases, tab completion exists ;-)

Are you sure it indeed exists? Open terminal on your Android phone and check if it indeed does. Wait, where's tab key at all on standard Android virtual keyboard?

Command names are selected not for optimistic conditions where you have brain-computer interface and need just think about something to have it typed, but for conservative environment, where there's no history, no completion, modem is damn slow, touchscreen is resistive, miscalibrated, or broken, and yet you need to run it many times in row ;-).

67E6

garbas · 2014-01-02T16:37:12Z

Quoting Paul Sokolovsky (2014-01-02 17:15:54)

In the other cases, tab completion exists ;-)
Are you sure it indeed exists? Open terminal on your Android phone and check if
it indeed does. Wait, where's tab key at all on standard Android virtual
keyboard?

Command names are selected not for optimistic conditions where you have
brain-computer interface and need just think about something to have it typed,
but for conservative environment, where there's no history, no completion,
modem is damn slow, touchscreen is resistive, miscalibrated, or broken, and yet
you need to run it many times in row ;-).

i'm not saying its going to work for everybody. but it makes sense for
majority. for those "edge" cases you can find solution otherwise.

Rok Garbas - http://www.garbas.si

dpgeorge · 2014-01-02T17:27:58Z

While I don't want to demote my own work (!), I must say that I didn't intend the unix/py version of Micro Python to be used by the general public as an alternative to CPython on the unix command line. Beyond microcontrollers, I can see it being useful in games for a scripting engine, and perhaps on minimal Linux builds (by minimal I mean 16MB RAM minimal). But if you are on a fully fledged unix system, why not use CPython?

To answer my own question, perhaps your Python program is eating lots of memory and you need something a bit leaner (this has happened to me more than once). In that case Micro Python may be a good fit.

This is getting a bit off topic, but I think answers to the above question (why use MP instead of CPython?) are needed to decide what to call the binary.

I agree with @davidedb, that "micropython" is fool proof and future proof. I also agree with @pfalcon that unix commands are meant to be lean. Although, that's what "alias mp=micropython" is for :)

Dr-Syn · 2014-01-02T17:50:24Z

Are you sure it indeed exists? Open terminal on your Android phone and check if it indeed does

Does for me, but then that's because I use specific apps to interface with a real unix system when I want to do real unix things. The instances where you'd have to invoke micropython by name on an otherwise unconfigured system multiple times in a row are so vanishingly rare that, honestly, I don't think it's that worrisome.

Building a 'lean' command name for the unix port is somewhat nonsensical also as the unix port isn't actually the focus of this project--the microcontroller version's the focus; the unix port's just there for the convenience of devs testing out code.

@dpgeorge has it entirely correct: if you're going to be using it on a 'nix system, then alias it to something useful for you. Every project does not need to be everything for everyone; attempting to cover every edge case leads to feature creep, which leads to large binaries, which leads to leaving the scope of this project entirely ;-p

piranna · 2014-01-02T20:36:21Z

[OffTopic]

In the other cases, tab completion exists ;-)

Are you sure it indeed exists? Open terminal on your Android phone and
check if it indeed does. Wait, where's tab key at all on standard Android
virtual keyboard?

https://play.google.com/store/apps/details?id=org.pocketworkstation.pckeyboard

In the last version it also has the Windows logo key, and I can assure you
that's a wonderful keyboard (it's the one that I've been using both in my
tablets and smartphones since more than a year).

Namaste... ;-)

[/OffTopic]

After reading this latest mails, I remove my vote from mupython (as I did
from upython) and give it to plainly call the virtual machine/CLI command
as "micropython". Long? Sure, only problem would be with a 8.3 environment.
Clear? Absolutely :-)

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton
de sitios diferentes, simplemente escribe un sistema operativo Unix."
– Linus Tordvals, creador del sistema operativo Linux

fogleman · 2014-01-02T20:37:32Z

I, too, change my vote to a simple: "micropython" :)

pfalcon · 2014-01-02T20:38:57Z

But if you are on a fully fledged unix system, why not use CPython?

Here's my take:

Indeed, if one writes an app to run on "full-fledged" system (4Gb, 100W power), then it makes no sense to spend time on anything else but writing the app and just use existing solutions like CPython.

I'm personally more interested in Ubiquitous Computing, whose idea is to put exactly as much as needed processing power where it is needed. So, when I want to write simple webapp I want to use toolset which will allow me to scale down say to 16Mb RAM/4Mb ROM router system, even if I initially develop it on 4Gb/100W box. CPython doesn't scale down to those requirements (it simply won't fit in 4Mb). So, instead of using CPython, and then port it to MicroPython (and yes, it will require porting), I'd rather use MicroPython right away.

And if I'd want to develop something useful for deeply embedded uPy system (I love the idea, it just needs to prove itself being really viable), I'd still prefer to do (big) part of development, testing, and debugging on a desktop system, because it's much more convenient (again, because using CPy for that will lead to unneeded surprises).

So, everything looks like having a "desktop" version of MicroPython is good thing to enable full potential of it and make development more productive and convenient. And doing it right (avoiding naming conflicts, choosing good name) will allow more people to leverage it easily (ultimately by installing from a distro package).

pfalcon · 2014-01-02T20:44:34Z

Building a 'lean' command name for the unix port is somewhat nonsensical also as the unix port isn't actually the focus of this project--the microcontroller version's the focus

Then people should not have strong opinions about it (like "call the binary the same as the project, because I have tab completion and don't care if someone else doesn't"). Indeed, I'm surprised that this ticket caught so much attention - it was intended for those few who care about such marginal questions, other naming discussions should have happened is separate tickets.

pfalcon · 2014-01-19T23:24:04Z

Ok, I guess we had good enough discussion and I just committed fe2690d which allows to write full-fledged scripts with unix port. @dpgeorge, can you please decide what will be the good name for the binary and rename it? Thanks!

F438

piranna · 2014-01-19T23:25:34Z

The binary... and the source code folder...

Send from my Samsung Galaxy Note II
El 20/01/2014 00:24, "Paul Sokolovsky" notifications@github.com escribió:

Ok, I guess we had good enough discussion and I just committed fe2690dhttps://github.com/micropython/micropython/commit/fe2690da0a1b8556995f5a6d2368d250f504b4afwhich allows to write full-fledged scripts with unix port.
@dpgeorge https://github.com/dpgeorge, can you please decide what will
be the good name for the binary and rename it? Thanks!

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/17#issuecomment-32725863
.

pfalcon · 2014-01-19T23:31:50Z

No, only the unix binary. If you have any suggestions regarding source code folder, please open separate ticket.

dpgeorge · 2014-01-19T23:41:58Z

I'd want to have the full word "python" in the name (eg not mpy).

As already pointed out, upython, mpython, mupython are already taken.

So, unless we want to clash with something existing / make some people unhappy, that really just leaves "micropython".

pfalcon · 2014-01-19T23:59:50Z

Let's go for it!

atmel-samd: Enable full urandom module from extmod. Closes #17.

Deploy build from travis to S3

extmod/vfs_lfsx.c: Fix a few minor error in vfs_lfsx

update from main

Rename fir.display to fir.draw

dpgeorge closed this as completed Jan 20, 2014

tannewt referenced this issue in tannewt/circuitpython Oct 21, 2016

Merge pull request micropython#24 from adafruit/urandom

2cc1b25

atmel-samd: Enable full urandom module from extmod. Closes #17.

drrk pushed a commit to drrk/micropython that referenced this issue Jan 22, 2017

Merge pull request micropython#17 from emfcamp/travis-binary-deploy

d9b2ae2

Deploy build from travis to S3

elfman2 mentioned this issue Jul 1, 2017

Enable btree duplicate key functionality #3187

Closed

dpgeorge mentioned this issue Nov 25, 2018

unix: Introduce "micropython-dev" variant. #4309

Closed

retryfail pushed a commit to retryfail/micropython that referenced this issue Aug 20, 2020

Merge pull request micropython#17 from robert-hh1/w600_lfsx

f811288

extmod/vfs_lfsx.c: Fix a few minor error in vfs_lfsx

tannewt referenced this issue in tannewt/circuitpython Sep 11, 2020

Merge pull request #17 from adafruit/main

a44c09e

update from main

WeActStudio pushed a commit to WeActStudio/micropython that referenced this issue Feb 14, 2021

Merge pull request micropython#17 from kwagyeman/openmv

e8f5325

Rename fir.display to fir.draw

Uh oh!

Good name for interpreter binary #17

Good name for interpreter binary #17

Comments

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!