[Microbit-Python] Say hola to microperi [WIP]
David Whale
david at thinkingbinaries.com
Mon May 16 04:18:21 EDT 2016
I think it's not really how schools organise their IT that is the problem.
It's us developers who assume that *everyone else* is happy with spending
hours downloading all sorts of things and building packages from source.
I actually take sides with Laura Dixon on this one.
Why should I have to download a program in order to install some other
program?
I don't think we're there yet as an industry. If we want to engage with
schools and teachers, we have to have some better best-practices that we
can all follow to make it easier and more accessible for them.
Another one to add to the 'lunchtime beer and chat' agenda ;-)
David
___________________________________________________________
David Whale, B.Sc (Hons), MIET
*Software Engineer and IET Schools Liaison Officer, Essex*
On 16 May 2016 at 08:47, Nicholas H.Tollervey <ntoll at ntoll.org> wrote:
> For the Mu editor Carlos did some amazing work in automatically building
> a stand-alone executable for Windows, OSX and Linux.
>
> Of course, Windows will complain if you try to run a stand-alone
> executable and warn you to the extent that you'll imagine the world is
> about to end, but there you go.
>
> Unfortunately, the real problem (the way schools organise their IT) is
> impossible for us to fix. Ergo all this faffing about. Nevertheless,
> it's worth it when teachers and kids get their hands on the good stuff.
>
> Best wishes,
>
> N.
>
> On 15/05/16 16:13, David Whale wrote:
> > Hi Joe,
> >
> > Yes, but the way we typically do this is to unzip the package directory
> > into the users project directory. That's how I do it with the anyio
> > library I wrote for my minecraft book, and that's ow the original
> > mb_remote works.
> >
> > i.e. if the user project directory is my_awesome_project
> > ...and if there is a file my_awesome_project/test1.py
> > ...and if there is a folder my_awesome_project/microbit
> >
> > ...then when you import microbit in test1.py, it all works.
> >
> > The embedded serial folder inside the microbit folder (with it's magic
> > sys.path modifier) just makes it all work seamlessly.
> >
> > It really is very simple to use.
> >
> > Lines 28..33
> > here:
> https://github.com/whaleygeek/mb_remote/blob/master/src/microbit.py#L28
> >
> >
> > Teachers hate it when you have to run install scripts and need admin
> > access, because (a) it means you have to beg to the IT technician which
> > sometimes takes months (literally), and (b) it means that they have to
> > consider which machines are configured correctly and which are not.
> >
> > If all you have to do is unzip a folder and start coding, it's *really*
> > simple. They can even give the instructions to the kids and they can
> > just unzip the file into their user directory and it all works
> seamlessly.
> >
> > In one school, it took the technician 3 months (of continuous teacher
> > begging) to get python installed, just so they could run the GCSE
> > controlled assessments.
> >
> > David
> >
> >
> > ___________________________________________________________
> > David Whale, B.Sc (Hons), MIET
> > *Software Engineer and IET Schools Liaison Officer, Essex*
> >
> >
> > On 15 May 2016 at 13:21, Joe Glancy <joe.t.glancy at gmail.com
> > <mailto:joe.t.glancy at gmail.com>> wrote:
> >
> > That's a good point - embedding pyserial would certainly make it
> > more portable, as it doesn't depend on anything else except standard
> > modules then. The only (small) limitation with a zero install is
> > that scripts would have to be in the same location as the module's
> > directory, but that's hardly an issue.
> >
> >
> > On Sun, 15 May 2016, 10:42 David Whale, <david at thinkingbinaries.com
> > <mailto:david at thinkingbinaries.com>> wrote:
> >
> > Joe and Andrew,
> >
> > Just a comment about this, please read this article, and
> > consider *changing* how you package this, especially for
> teachers:
> >
> >
> https://codeboom.wordpress.com/2016/05/11/scratch-is-the-new-powerpoint/
> >
> > The version that I wrote back in August 2015 is zero install -
> > yes, ZERO install. All a teacher has to do is to press the
> > DownloadZip button, unzip it, and run it. This is VITAL for
> > teachers to use these resources, especially on a Raspberry Pi
> > where mostly they are not connected to the internet most of the
> > time. Most of the time they want to just grab a file on a USB
> > memory stick, and copy it over. sudo pip install is *useless* in
> > this situation.
> >
> > Raspberry Pi's are mostly not connected to the internet in
> > schools, because it stores the wifi password in plain text in
> > the config file, and school IT technicians ban the teachers from
> > using them for this reason (as it exposes the password to the
> > kids, and then all their phones start connecting to the wifi and
> > makes it crash). Really, this is a big problem, believe me!
> >
> > The way I did this was to *embed* pyserial into the package (and
> > the licence allows for this providing you are clear about the
> > containing licence). Please see my original
> > here: https://github.com/whaleygeek/mb_remote and you will see
> > this works really great. There is also a little bit of python
> > magic in the file (it modifies the sys.path inplace) to make
> > sure that this happens automatically. (you need to make this
> > Python 3 safe still, of course).
> >
> > Can I strongly urge you to make it zero install? It'll get
> > adopted really quickly that way.
> >
> > I've had a number of chats with teachers already about this and
> > they are really excited about it, but they said to me 'ah, it's
> > all that sudo pip stuff, that never works for us'. Lots of
> > teachers I speak to gave in with PyGameZero because they
> > couldn't get it to install.
> >
> > Thanks
> >
> > David
> >
> >
> >
> >
> > ___________________________________________________________
> > David Whale, B.Sc (Hons), MIET
> > *Software Engineer and IET Schools Liaison Officer, Essex*
> >
> >
> > On 14 May 2016 at 22:54, Joe Glancy <joe.t.glancy at gmail.com
> > <mailto:joe.t.glancy at gmail.com>> wrote:
> >
> > Thanks David :)
> >
> > I'll see if I can find that demo and get it up and working
> > with this module - would be nice to have some examples with
> > it where it can interact with things such as MCPI straight
> > out of the box.
> >
> > And indeed it does make an excellent addon, mostly thanks to
> > the pretty much universal serial interface it uses to
> > communicate (which allows it to be easily interfaced on many
> > platforms with minimal (or even none) setup required).
> >
> > As a matter of fact, I thought up of something very similar
> > to this but which communicated over Bluetooth instead a
> > while ago (using a stock micro:bit image), with a Raspberry
> > Pi 3 and micro:bit as use case. Unfortunately, I found it
> > impossible to get the micro:bit to work properly with BlueZ,
> > despite some help from the BlueZ IRC and Linux Bluetooth
> > mailing list.This kind of lead to the wired approach you see
> > now. Maybe the recent BlueZ updates will fix this, so that a
> > wireless alternative to this module exists too.
> >
> >
> > On Sat, 14 May 2016, 22:25 David Whale,
> > <david at thinkingbinaries.com
> > <mailto:david at thinkingbinaries.com>> wrote:
> >
> > Looks great, Joe and Andrew!
> >
> > Yes, I wrote this original mb_remote version back in
> > August 2015, but the Python API on the micro:bit changed
> > many times since then and I've been too busy to maintain
> > it. However, it's great to see this moving forward.
> > There are some really nice use cases (especially
> > micro:bit + Raspberry Pi) where this sort of approach is
> > both really useful and great fun, as I discovered with
> > my early tests.
> >
> > The 'flying xwing in minecraft with a micro:bit' that
> > Martin and I did, was really the inspiration for me
> > writing the mb_remote, more to get a feel for what it
> > would look like than anything else. I had come to the
> > conclusion that the micro:bit makes a great peripheral
> > for other computers, what with it's onboard sensors and
> > I/O pins, and having a really quick way to extend your
> > python from the host PC onto the micro:bit is really fun.
> >
> > I'm also glad to see you take forward the idea of poking
> > commands into the REPL and getting responses (that's
> > much better than having to load custom firmware onto the
> > micro:bit, as other solutions tend to go for).
> >
> > David
> >
> >
> >
> ___________________________________________________________
> > David Whale, B.Sc (Hons), MIET
> > *Software Engineer and IET Schools Liaison Officer,
> Essex*
> >
> >
> > On 14 May 2016 at 20:58, Joe Glancy
> > <joe.t.glancy at gmail.com <mailto:joe.t.glancy at gmail.com>>
> > wrote:
> >
> > Myself and Andrew (Mulholland, @gbaman on GitHub -
> > credit to him for first starting this) have been
> > working on something similar to David's mb_remote
> > module for Python, called microperi
> > (micro-peripheral, as that is what the micro:bit
> > becomes :). It is currently (and very much) an alpha
> > work-in-progress, and I'm only informing everyone
> > here about it because we need testers and, more
> > importantly, feedback.
> >
> > It lives at https://github.com/JoeGlancy/microperi,
> > and because none of the install methods
> > (pip3/python3 setup.py install) work properly as of
> > now, the best way to try it is just create your
> > scripts in the same directory where the docs
> > (README, CONTRIBUTING etc) are and use `import
> > microperi` (check out the example in the README for
> > a bit of a better howto).
> >
> > It exposes almost all of the micro:bit's MicroPython
> > `microbit` module, which is completely available
> > through a microperi.Microbit object. This is
> > actually one of the things that I'd like feedback
> > about; see below for more information (I don't think
> > I've explained this too well, but it's the best I
> > could think of and word). If you just want to try it
> > out, get cloning and give it a whirl. Anything you
> > spot as a bug or something you feel needs to be
> > improved/implemented, just create an issue or submit
> > a PR (check CONTRIBUTING.rst first though).
> >
> > We decided on the Microbit object (instead of one
> > pre-set object called `microperi.microbit`, which it
> > actually was originally) so that multiple micro:bits
> > can be used at the same time. The constructor is:
> >
> > microperi.Microbit(port=None)
> >
> > If port is not specified, the module will
> > automatically detect the first available micro:bit
> > and use that one (Nick, the finding code is from
> > microrepl - could you comment on licensing please?).
> > Otherwise, `port` must be a string determining the
> > serial port which the micro:bit is connected to
> > (e.g: /dev/ttyACM0, COM1, etc).
> >
> > Usual usage of the object is along the following
> > lines (or, more literal, line):
> >
> > microbit = microperi.Microbit()
> >
> > and then things like the microbit.Image class are
> > available through `microbit.Image`. However, if I
> > were to call the micro:bit object a different name
> > in my script (such as "uBit"), the Image class would
> > be accessible as uBit.Image, which deviates from the
> > MicroPython API. However, we did not want to place
> > things like the Image & pin classes in somewhere
> > like `microperi.microbit.Class_name` because then
> > you'd have a bit of a mess like so:
> >
> > from microperi import *
> > uBit = Microbit()
> > solid = microbit.Image.SNAKE
> > uBit.display.show(solid)
> >
> > because some things (e.g: microbit.i2c.read) would
> > be accessible through `uBit.i2c.read`, and others
> > (e.g: microbit.Image) would be accessible through
> > `microbit.Image`, when they both should be under
> > `microbit.X`, if you understand what I mean.
> >
> > The best solution for this currently is just calling
> > the object `microbit`, and then everything will be
> > as it should, but if you don't some things will be
> > in different places.
> >
> > Anyway, I hope that this module will prove itself
> > useful for people and perhaps even in the classroom,
> > as it notably allows not only use of the microbit
> > module but also every other Python 3 module out
> > there, allowing much more powerful (possibly IoT
> > integrated?) scripts to be created on a much more
> > powerful machine. I look forward to any feedback,
> > and hope for a proper, stable release (with
> > documentation of some sort) sometime soon.
> >
> > _______________________________________________
> > Microbit mailing list
> > Microbit at python.org <mailto:Microbit at python.org>
> > https://mail.python.org/mailman/listinfo/microbit
> >
> >
> > _______________________________________________
> > Microbit mailing list
> > Microbit at python.org <mailto:Microbit at python.org>
> > https://mail.python.org/mailman/listinfo/microbit
> >
> >
> > _______________________________________________
> > Microbit mailing list
> > Microbit at python.org <mailto:Microbit at python.org>
> > https://mail.python.org/mailman/listinfo/microbit
> >
> >
> > _______________________________________________
> > Microbit mailing list
> > Microbit at python.org <mailto:Microbit at python.org>
> > https://mail.python.org/mailman/listinfo/microbit
> >
> >
> > _______________________________________________
> > Microbit mailing list
> > Microbit at python.org <mailto:Microbit at python.org>
> > https://mail.python.org/mailman/listinfo/microbit
> >
> >
> >
> >
> > _______________________________________________
> > Microbit mailing list
> > Microbit at python.org
> > https://mail.python.org/mailman/listinfo/microbit
> >
>
>
>
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20160516/cd269ecf/attachment-0001.html>
More information about the Microbit
mailing list