From ntoll at ntoll.org Tue Aug 11 18:09:12 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Tue, 11 Aug 2015 17:09:12 +0100 Subject: [Microbit-Python] Latest (good) news - MicroPython and editor demo videos Message-ID: <55CA1E28.1000008@ntoll.org> Hi Folks, I've prepared the following videos. Please watch them and give feedback. By the end of this afternoon I'll push all the code that makes this happen (web-editor -> microbit .hex file) to the repos here: https://github.com/sparkslabs/micropython-bit There are three videos: https://www.youtube.com/watch?v=6MoBKf3jTIY - the Python editor running on a local instance of TouchDevelop. This is, ultimately, what we need to integrate with Microsoft. It's very simple and pretty much works as advertised. https://www.youtube.com/watch?v=duyqxrvDXzU - connecting to the micro:bit and interacting with it via the standard Python REPL. A very 1980's 8 bit feel. It's also a nice demonstration of just how capable MicroPython is. Kudos to Damien for such an amazing feat. https://www.youtube.com/watch?v=jCIWY485bx0 - flashing the device with .hex files generated via the Python editor embedded within TouchDevelop. It's just like all the other editors but it works offline (construction of the .hex file is done within the user's browser rather than via Microsoft and ARM's compilation cloud service thingamabobs). Howard - will these suffice for the purposes of demonstrating the work completed so far for tomorrow..? Finally, I'm trying to get micro:bits so people can play, develop and improve these first initial steps. To be honest, I've managed to get nowhere despite flagging this up (sorry Howard, I realise you're not the BBC but just the messenger). :-/ I'll ping the list when there's code to look at (even though you won't be able to run it). Best wishes, Nicholas. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From damien.p.george at gmail.com Tue Aug 11 18:42:58 2015 From: damien.p.george at gmail.com (Damien George) Date: Tue, 11 Aug 2015 17:42:58 +0100 Subject: [Microbit-Python] Latest (good) news - MicroPython and editor demo videos In-Reply-To: <55CA1E28.1000008@ntoll.org> References: <55CA1E28.1000008@ntoll.org> Message-ID: Awesome Nicholas! Really nice to see this all coming together so neatly. Did you know that tab completion works? :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ntoll at ntoll.org Tue Aug 11 18:43:57 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Tue, 11 Aug 2015 17:43:57 +0100 Subject: [Microbit-Python] Latest (good) news - MicroPython and editor demo videos In-Reply-To: References: <55CA1E28.1000008@ntoll.org> Message-ID: <55CA264D.3050608@ntoll.org> On 11/08/15 17:42, Damien George wrote: > Did you know that tab completion works? :) > No I did not. My life in complete. I'm pretty certain there's a flying pig just outside my window. :-) N. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From ntoll at ntoll.org Tue Aug 11 22:11:03 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Tue, 11 Aug 2015 21:11:03 +0100 Subject: [Microbit-Python] Editor code update... Message-ID: <55CA56D7.3000804@ntoll.org> Hi, I just pushed the latest code to: https://github.com/sparkslabs/micropython-bit I've updated the instructions so you should be able to easily set up a local dev environment and recreate the work from the earlier videos. PLEASE CHECK THIS and tell me if you run into any problems. I've also started the user-facing help page - it's pretty much a generic bootstrap based project with some Python / micro:bit related visual cues added. Other than that and some outline text, it's empty. I've had a chat with Giles (PythonAnywhere) and things are ready for me to deploy this editor for integration into the staging / test / whatever deployments of the microbit.co.uk website. All I need to do is put the contents of the git repository into a statically hosted endpoint hosted at: https://microbit.pythonanywhere.com/ I'll ensure it's password protected and share those details tomorrow when I've finished. The ball is now most definitely in the BBC's court since the Python side of things is very much in a usable state ready for testing by a wider audience. Best wishes, Nicholas. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From mail at timgolden.me.uk Tue Aug 11 22:53:10 2015 From: mail at timgolden.me.uk (Tim Golden) Date: Tue, 11 Aug 2015 21:53:10 +0100 Subject: [Microbit-Python] Editor code update... In-Reply-To: <55CA56D7.3000804@ntoll.org> References: <55CA56D7.3000804@ntoll.org> Message-ID: <55CA60B6.20900@timgolden.me.uk> Thanks, Nicholas. I'm on the end of the world's slowest broadband here in Cheshire, but I will try to clone and build from your repo. In other news, my friend Joe managed to get Micropython built and running on the Microbit (with some help from Damien) and he's been playing around with a few examples as well. TJG On 11/08/2015 21:11, Nicholas H.Tollervey wrote: > Hi, > > I just pushed the latest code to: > > https://github.com/sparkslabs/micropython-bit > > I've updated the instructions so you should be able to easily set up a > local dev environment and recreate the work from the earlier videos. > > PLEASE CHECK THIS and tell me if you run into any problems. > > I've also started the user-facing help page - it's pretty much a generic > bootstrap based project with some Python / micro:bit related visual cues > added. Other than that and some outline text, it's empty. > > I've had a chat with Giles (PythonAnywhere) and things are ready for me > to deploy this editor for integration into the staging / test / whatever > deployments of the microbit.co.uk website. > > All I need to do is put the contents of the git repository into a > statically hosted endpoint hosted at: > > https://microbit.pythonanywhere.com/ > > I'll ensure it's password protected and share those details tomorrow > when I've finished. > > The ball is now most definitely in the BBC's court since the Python side > of things is very much in a usable state ready for testing by a wider > audience. > > Best wishes, > > Nicholas. > > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > From ntoll at ntoll.org Tue Aug 11 22:53:55 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Tue, 11 Aug 2015 21:53:55 +0100 Subject: [Microbit-Python] Editor code update... In-Reply-To: <55CA60B6.20900@timgolden.me.uk> References: <55CA56D7.3000804@ntoll.org> <55CA60B6.20900@timgolden.me.uk> Message-ID: <55CA60E3.6050506@ntoll.org> On 11/08/15 21:53, Tim Golden wrote: > Thanks, Nicholas. I'm on the end of the world's slowest broadband here > in Cheshire, but I will try to clone and build from your repo. > > In other news, my friend Joe managed to get Micropython built and > running on the Microbit (with some help from Damien) and he's been > playing around with a few examples as well. > > TJG > That's not Joe from Lancaster Uni is it..? He's a legend! N. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From mail at timgolden.me.uk Tue Aug 11 22:58:15 2015 From: mail at timgolden.me.uk (Tim Golden) Date: Tue, 11 Aug 2015 21:58:15 +0100 Subject: [Microbit-Python] Editor code update... In-Reply-To: <55CA60E3.6050506@ntoll.org> References: <55CA56D7.3000804@ntoll.org> <55CA60B6.20900@timgolden.me.uk> <55CA60E3.6050506@ntoll.org> Message-ID: <55CA61E7.1040808@timgolden.me.uk> On 11/08/2015 21:53, Nicholas H.Tollervey wrote: > On 11/08/15 21:53, Tim Golden wrote: >> Thanks, Nicholas. I'm on the end of the world's slowest broadband here >> in Cheshire, but I will try to clone and build from your repo. >> >> In other news, my friend Joe managed to get Micropython built and >> running on the Microbit (with some help from Damien) and he's been >> playing around with a few examples as well. >> >> TJG >> > > That's not Joe from Lancaster Uni is it..? Nope. It's Joe from Manchester, working for a certain national media organisation. TJG From damien.p.george at gmail.com Tue Aug 11 23:55:23 2015 From: damien.p.george at gmail.com (Damien George) Date: Tue, 11 Aug 2015 22:55:23 +0100 Subject: [Microbit-Python] Editor code update... In-Reply-To: <55CA61E7.1040808@timgolden.me.uk> References: <55CA56D7.3000804@ntoll.org> <55CA60B6.20900@timgolden.me.uk> <55CA60E3.6050506@ntoll.org> <55CA61E7.1040808@timgolden.me.uk> Message-ID: Nicholas: I managed to follow your instructions and get the MicroPython version of TouchDevelop running locally! Two things to note: 1. I managed to install the npm packages localling by not giving the -g switch to npm. But then jake is not in your path (it's in TouchDevelop/node_modules/.bin). 2. I didn't need to enter the strange jnhrsrcsui code anywhere. Also some things re MicroPython: 1. If your script is in an infinite loop and you connect via serial then CTRL-C should break out of the loop and drop you to the REPL (with a KeyboardInterrupt exception, as per Python specs :) 2. We should probably display any SyntaxError's or other error messages on the microbit's display, for those who don't have serial access and wonder why their script doesn't run. On Tue, Aug 11, 2015 at 9:58 PM, Tim Golden wrote: > On 11/08/2015 21:53, Nicholas H.Tollervey wrote: >> >> On 11/08/15 21:53, Tim Golden wrote: >>> >>> Thanks, Nicholas. I'm on the end of the world's slowest broadband here >>> in Cheshire, but I will try to clone and build from your repo. >>> >>> In other news, my friend Joe managed to get Micropython built and >>> running on the Microbit (with some help from Damien) and he's been >>> playing around with a few examples as well. >>> >>> TJG >>> >> >> That's not Joe from Lancaster Uni is it..? > > > Nope. It's Joe from Manchester, working for a certain national media > organisation. > > TJG > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit From ntoll at ntoll.org Fri Aug 28 17:08:25 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Fri, 28 Aug 2015 16:08:25 +0100 Subject: [Microbit-Python] A request for help... fancy designing a Pythonic API that up to 1 million kids would use..? Message-ID: <55E07969.5080409@ntoll.org> Hi Folks, Although this list has been a tad quiet recently, things are moving along when it comes to Python on the micro:bit. The "blessed" device abstraction layer (DAL) created by Lancaster University for the BBC to use with the micro:bit is now working with MicroPython. What we need to do is create a Pythonic "microbit" module that gives users of Python direct access to the device hardware via the DAL. In terms of the work, this is simply a task of code-plumbing. However, the challenge will be in creating something that is Pythonic and easy enough for the nation's 11yo to get their heads around. That means obvious mono-syllabic names and shallow namespaces while still retaining the "shape" of the DAL. So, I'm going to start writing some documentation about the various features that the DAL exposes and both Damien and I would like help in designing the API (since actually coding it is a relatively simple task of connecting Python to the DAL). It's definitely a case of more eyes will make this better. In case you're wondering, we already have made a start. So for example, here's the output from MicroPython's help() function: >>> help() Welcome to MicroPython on the micro:bit! Be brave! Break things! Learn and have fun! :-) Type 'import microbit', press return and try these commands: microbit.display.scroll('Hello') microbit.system_time() microbit.sleep(1000) microbit.button_a.is_pressed() What do these commands do? Can you improve them? HINT: use the up and down arrow keys to get your command history (saves you typing). Explore: Type 'help(something)' to find out about it. Type 'dir(something)' to see what it can do. Stuff to explore: microbit.accelerometer -- detect the device's position (orientation) microbit.button_a.is_pressed() -- is button A pressed? (True or False) microbit.button_b.is_pressed() -- is button B pressed? (True or False) microbit.compass -- detect the device's heading microbit.display -- display things (pixels, characters, words) microbit.panic() -- go into panic mode (requires a restart) microbit.random(n) -- get a random number between 0 and n microbit.sleep(n) -- wait for n milliseconds (1 second = 1000) microbit.system_time() -- get the number of milliseconds since reset Control commands: CTRL-C -- stop a running program CTRL-D -- on a blank line, do a soft reset of the micro:bit The only major part of the DAL we've not already started to reference is the IO namespace for accessing the pins along the bottom of the device. Pretty much all of the above namespaces have things missing or clunkily named. So, fancy helping 1 million kids learn and play with Python? You will be given credit in the code and perhaps an easter egg I have in mind. ;-) Let me know your thoughts! Best wishes, Nicholas. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From david at thinkingbinaries.com Fri Aug 28 21:00:24 2015 From: david at thinkingbinaries.com (David Whale) Date: Fri, 28 Aug 2015 20:00:24 +0100 Subject: [Microbit-Python] A request for help... fancy designing a Pythonic API that up to 1 million kids would use..? In-Reply-To: <55E07969.5080409@ntoll.org> References: <55E07969.5080409@ntoll.org> Message-ID: Nicholas, I'd be interested in reviewing the API spec proposals when they are done (naming and containership of namespaces, parameters etc). Just one point. I'd like to propose that there is significant value in using *exactly* the same names as are already used in the TouchDevelop API, with exactly the same groupings. There's been a lot of work recently to consolidate the TouchDevelop, Blocks [and to some extent CodeKingdoms] vocabulary for things, so that it is a mostly seamless experience to move from one language to another, with the transferrable knowledge of the common micro:bit API tying everything together. Please do look back at the TouchDevelop, there have been a number of commits to the live site in the last week or two with changes to default namespaces, some additional 'standard' linked in libraries like bits, game, and events, some name changes, and stuff like that. system_time() for example is not one of the vocabulary words in use in the live system, it has been renamed a few times and has settled now on "running time". I don't think we should get too hung up on it being "Pythonic", as long as it is 'Python'. David ___________________________________________________________ David Whale, B.Sc (Hons), MIET *Software Engineer and IET Schools Liaison Officer, Essex* email: dwhale at theiet.org twitter: @whaleygeek blog: blog.whaleygeek.co.uk Co-author of the new book "Adventures in Minecraft" - lets get kids coding! On 28 August 2015 at 16:08, Nicholas H.Tollervey wrote: > Hi Folks, > > Although this list has been a tad quiet recently, things are moving > along when it comes to Python on the micro:bit. > > The "blessed" device abstraction layer (DAL) created by Lancaster > University for the BBC to use with the micro:bit is now working with > MicroPython. > > What we need to do is create a Pythonic "microbit" module that gives > users of Python direct access to the device hardware via the DAL. > > In terms of the work, this is simply a task of code-plumbing. However, > the challenge will be in creating something that is Pythonic and easy > enough for the nation's 11yo to get their heads around. That means > obvious mono-syllabic names and shallow namespaces while still retaining > the "shape" of the DAL. > > So, I'm going to start writing some documentation about the various > features that the DAL exposes and both Damien and I would like help in > designing the API (since actually coding it is a relatively simple task > of connecting Python to the DAL). It's definitely a case of more eyes > will make this better. > > In case you're wondering, we already have made a start. So for example, > here's the output from MicroPython's help() function: > > >>> help() > Welcome to MicroPython on the micro:bit! > > Be brave! Break things! Learn and have fun! :-) > > Type 'import microbit', press return and try these commands: > microbit.display.scroll('Hello') > microbit.system_time() > microbit.sleep(1000) > microbit.button_a.is_pressed() > What do these commands do? Can you improve them? HINT: use the up and > down arrow keys to get your command history (saves you typing). > > Explore: > Type 'help(something)' to find out about it. Type 'dir(something)' to > see what it can do. > > Stuff to explore: > microbit.accelerometer -- detect the device's position > (orientation) > microbit.button_a.is_pressed() -- is button A pressed? (True or False) > microbit.button_b.is_pressed() -- is button B pressed? (True or False) > microbit.compass -- detect the device's heading > microbit.display -- display things (pixels, characters, > words) > microbit.panic() -- go into panic mode (requires a restart) > microbit.random(n) -- get a random number between 0 and n > microbit.sleep(n) -- wait for n milliseconds (1 second = > 1000) > microbit.system_time() -- get the number of milliseconds since > reset > > Control commands: > CTRL-C -- stop a running program > CTRL-D -- on a blank line, do a soft reset of the micro:bit > > > The only major part of the DAL we've not already started to reference is > the IO namespace for accessing the pins along the bottom of the device. > > Pretty much all of the above namespaces have things missing or clunkily > named. > > So, fancy helping 1 million kids learn and play with Python? You will be > given credit in the code and perhaps an easter egg I have in mind. ;-) > > Let me know your thoughts! > > Best wishes, > > Nicholas. > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damien.p.george at gmail.com Sat Aug 29 00:22:59 2015 From: damien.p.george at gmail.com (Damien George) Date: Fri, 28 Aug 2015 23:22:59 +0100 Subject: [Microbit-Python] A request for help... fancy designing a Pythonic API that up to 1 million kids would use..? In-Reply-To: References: <55E07969.5080409@ntoll.org> Message-ID: Hi David, How do I find the reference/list of functions for the TouchDevelop API? Is it documented somewhere on the live site, or in a code repository somewhere? Thanks! Damien. On Fri, Aug 28, 2015 at 8:00 PM, David Whale wrote: > Nicholas, > > I'd be interested in reviewing the API spec proposals when they are done > (naming and containership of namespaces, parameters etc). > > Just one point. I'd like to propose that there is significant value in using > *exactly* the same names as are already used in the TouchDevelop API, with > exactly the same groupings. There's been a lot of work recently to > consolidate the TouchDevelop, Blocks [and to some extent CodeKingdoms] > vocabulary for things, so that it is a mostly seamless experience to move > from one language to another, with the transferrable knowledge of the common > micro:bit API tying everything together. > > Please do look back at the TouchDevelop, there have been a number of commits > to the live site in the last week or two with changes to default namespaces, > some additional 'standard' linked in libraries like bits, game, and events, > some name changes, and stuff like that. system_time() for example is not one > of the vocabulary words in use in the live system, it has been renamed a few > times and has settled now on "running time". > > I don't think we should get too hung up on it being "Pythonic", as long as > it is 'Python'. > > David > > ___________________________________________________________ > David Whale, B.Sc (Hons), MIET > Software Engineer and IET Schools Liaison Officer, Essex > > email: dwhale at theiet.org > twitter: @whaleygeek > blog: blog.whaleygeek.co.uk > > Co-author of the new book "Adventures in Minecraft" - lets get kids coding! > > > On 28 August 2015 at 16:08, Nicholas H.Tollervey wrote: >> >> Hi Folks, >> >> Although this list has been a tad quiet recently, things are moving >> along when it comes to Python on the micro:bit. >> >> The "blessed" device abstraction layer (DAL) created by Lancaster >> University for the BBC to use with the micro:bit is now working with >> MicroPython. >> >> What we need to do is create a Pythonic "microbit" module that gives >> users of Python direct access to the device hardware via the DAL. >> >> In terms of the work, this is simply a task of code-plumbing. However, >> the challenge will be in creating something that is Pythonic and easy >> enough for the nation's 11yo to get their heads around. That means >> obvious mono-syllabic names and shallow namespaces while still retaining >> the "shape" of the DAL. >> >> So, I'm going to start writing some documentation about the various >> features that the DAL exposes and both Damien and I would like help in >> designing the API (since actually coding it is a relatively simple task >> of connecting Python to the DAL). It's definitely a case of more eyes >> will make this better. >> >> In case you're wondering, we already have made a start. So for example, >> here's the output from MicroPython's help() function: >> >> >>> help() >> Welcome to MicroPython on the micro:bit! >> >> Be brave! Break things! Learn and have fun! :-) >> >> Type 'import microbit', press return and try these commands: >> microbit.display.scroll('Hello') >> microbit.system_time() >> microbit.sleep(1000) >> microbit.button_a.is_pressed() >> What do these commands do? Can you improve them? HINT: use the up and >> down arrow keys to get your command history (saves you typing). >> >> Explore: >> Type 'help(something)' to find out about it. Type 'dir(something)' to >> see what it can do. >> >> Stuff to explore: >> microbit.accelerometer -- detect the device's position >> (orientation) >> microbit.button_a.is_pressed() -- is button A pressed? (True or False) >> microbit.button_b.is_pressed() -- is button B pressed? (True or False) >> microbit.compass -- detect the device's heading >> microbit.display -- display things (pixels, characters, >> words) >> microbit.panic() -- go into panic mode (requires a >> restart) >> microbit.random(n) -- get a random number between 0 and n >> microbit.sleep(n) -- wait for n milliseconds (1 second = >> 1000) >> microbit.system_time() -- get the number of milliseconds since >> reset >> >> Control commands: >> CTRL-C -- stop a running program >> CTRL-D -- on a blank line, do a soft reset of the micro:bit >> >> >> The only major part of the DAL we've not already started to reference is >> the IO namespace for accessing the pins along the bottom of the device. >> >> Pretty much all of the above namespaces have things missing or clunkily >> named. >> >> So, fancy helping 1 million kids learn and play with Python? You will be >> given credit in the code and perhaps an easter egg I have in mind. ;-) >> >> Let me know your thoughts! >> >> Best wishes, >> >> Nicholas. >> >> >> _______________________________________________ >> 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 > From david at thinkingbinaries.com Sat Aug 29 00:56:24 2015 From: david at thinkingbinaries.com (David Whale) Date: Fri, 28 Aug 2015 23:56:24 +0100 Subject: [Microbit-Python] A request for help... fancy designing a Pythonic API that up to 1 million kids would use..? In-Reply-To: References: <55E07969.5080409@ntoll.org> Message-ID: Hi Damien, Yes, there is a detailed list of keywords and their operation descriptions under the help pages. Presuming you have access to the live site, here is the link... https://live.microbit.co.uk/td/contents Or press the help link on the top right of the site, and on the page you see, there is a "touch develop" help link under the touch develop section. it's moved around a bit, and in particular a recent change includes the removal of the 'microbit' namespace and just the 'equivalent namespaces from blocks' were left in scope, with a few others added. These are: basic control events game image input led pins math bits The basic, control, image, input, led, pins were designed to be an almost 1:1 translation from the blocks, so that when the convert feature was used, the kids basically got roughly the same program. I'm presuming we therefore have a choice of import styles so one could use import microbit microbit.led.fadein() or: from microbit import * led.fadein() There are some small differences in the code kingdoms, for example they call things a Pattern() whereas TD and blocks call them an Image(), but roughly there is a 1:1 mapping of concepts in code kingdoms and *most* of the names are close or identical. The game library is something that is not really a device abstraction, but I think much research with user groups done by the BBC lead to believe that it was a major abstraction that kids always used very quickly from getting started, so they included it as one of the default namespaces. It has a (very small) model of scoring and stuff like that. Hope this helps! David ___________________________________________________________ David Whale, B.Sc (Hons), MIET *Software Engineer and IET Schools Liaison Officer, Essex* email: dwhale at theiet.org twitter: @whaleygeek blog: blog.whaleygeek.co.uk Co-author of the new book "Adventures in Minecraft" - lets get kids coding! On 28 August 2015 at 23:22, Damien George wrote: > Hi David, > > How do I find the reference/list of functions for the TouchDevelop > API? Is it documented somewhere on the live site, or in a code > repository somewhere? > > Thanks! > > Damien. > > > On Fri, Aug 28, 2015 at 8:00 PM, David Whale > wrote: > > Nicholas, > > > > I'd be interested in reviewing the API spec proposals when they are done > > (naming and containership of namespaces, parameters etc). > > > > Just one point. I'd like to propose that there is significant value in > using > > *exactly* the same names as are already used in the TouchDevelop API, > with > > exactly the same groupings. There's been a lot of work recently to > > consolidate the TouchDevelop, Blocks [and to some extent CodeKingdoms] > > vocabulary for things, so that it is a mostly seamless experience to move > > from one language to another, with the transferrable knowledge of the > common > > micro:bit API tying everything together. > > > > Please do look back at the TouchDevelop, there have been a number of > commits > > to the live site in the last week or two with changes to default > namespaces, > > some additional 'standard' linked in libraries like bits, game, and > events, > > some name changes, and stuff like that. system_time() for example is not > one > > of the vocabulary words in use in the live system, it has been renamed a > few > > times and has settled now on "running time". > > > > I don't think we should get too hung up on it being "Pythonic", as long > as > > it is 'Python'. > > > > David > > > > ___________________________________________________________ > > David Whale, B.Sc (Hons), MIET > > Software Engineer and IET Schools Liaison Officer, Essex > > > > email: dwhale at theiet.org > > twitter: @whaleygeek > > blog: blog.whaleygeek.co.uk > > > > Co-author of the new book "Adventures in Minecraft" - lets get kids > coding! > > > > > > On 28 August 2015 at 16:08, Nicholas H.Tollervey > wrote: > >> > >> Hi Folks, > >> > >> Although this list has been a tad quiet recently, things are moving > >> along when it comes to Python on the micro:bit. > >> > >> The "blessed" device abstraction layer (DAL) created by Lancaster > >> University for the BBC to use with the micro:bit is now working with > >> MicroPython. > >> > >> What we need to do is create a Pythonic "microbit" module that gives > >> users of Python direct access to the device hardware via the DAL. > >> > >> In terms of the work, this is simply a task of code-plumbing. However, > >> the challenge will be in creating something that is Pythonic and easy > >> enough for the nation's 11yo to get their heads around. That means > >> obvious mono-syllabic names and shallow namespaces while still retaining > >> the "shape" of the DAL. > >> > >> So, I'm going to start writing some documentation about the various > >> features that the DAL exposes and both Damien and I would like help in > >> designing the API (since actually coding it is a relatively simple task > >> of connecting Python to the DAL). It's definitely a case of more eyes > >> will make this better. > >> > >> In case you're wondering, we already have made a start. So for example, > >> here's the output from MicroPython's help() function: > >> > >> >>> help() > >> Welcome to MicroPython on the micro:bit! > >> > >> Be brave! Break things! Learn and have fun! :-) > >> > >> Type 'import microbit', press return and try these commands: > >> microbit.display.scroll('Hello') > >> microbit.system_time() > >> microbit.sleep(1000) > >> microbit.button_a.is_pressed() > >> What do these commands do? Can you improve them? HINT: use the up and > >> down arrow keys to get your command history (saves you typing). > >> > >> Explore: > >> Type 'help(something)' to find out about it. Type 'dir(something)' to > >> see what it can do. > >> > >> Stuff to explore: > >> microbit.accelerometer -- detect the device's position > >> (orientation) > >> microbit.button_a.is_pressed() -- is button A pressed? (True or False) > >> microbit.button_b.is_pressed() -- is button B pressed? (True or False) > >> microbit.compass -- detect the device's heading > >> microbit.display -- display things (pixels, characters, > >> words) > >> microbit.panic() -- go into panic mode (requires a > >> restart) > >> microbit.random(n) -- get a random number between 0 and n > >> microbit.sleep(n) -- wait for n milliseconds (1 second = > >> 1000) > >> microbit.system_time() -- get the number of milliseconds since > >> reset > >> > >> Control commands: > >> CTRL-C -- stop a running program > >> CTRL-D -- on a blank line, do a soft reset of the micro:bit > >> > >> > >> The only major part of the DAL we've not already started to reference is > >> the IO namespace for accessing the pins along the bottom of the device. > >> > >> Pretty much all of the above namespaces have things missing or clunkily > >> named. > >> > >> So, fancy helping 1 million kids learn and play with Python? You will be > >> given credit in the code and perhaps an easter egg I have in mind. ;-) > >> > >> Let me know your thoughts! > >> > >> Best wishes, > >> > >> Nicholas. > >> > >> > >> _______________________________________________ > >> 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 > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sparks.m at gmail.com Sat Aug 29 13:12:08 2015 From: sparks.m at gmail.com (Michael) Date: Sat, 29 Aug 2015 12:12:08 +0100 Subject: [Microbit-Python] A request for help... fancy designing a Pythonic API that up to 1 million kids would use..? In-Reply-To: References: <55E07969.5080409@ntoll.org> Message-ID: As a general comment, the design idea behind the original DAL was that it should be a child friendly base layer for interacting with the device. ie "These are the words the device understands". The languages on top ideally should ALL use the same DAL (however much it's changed since then) primarily to reinforce that view. This doesn't preclude the idea of there being language specific extensions, but the point is if the *device* is viewed to understand the same core vocabulary, then what they learn in one context can be brought through with them to the next. (imagine if the sockets API had never been created and everyone had to invent their own mechanism for interaction with networks in each new language.. Sure we all use higher abstractions but we have a common operating model, hence the DAL) To get an idea of what I mean by that it might be worth having a look at what the person who wrote "sniff" wrote about what happens from visual to text languages[1]. I don't agree with the conclusion (which is to write a new language), but the idea of allowing children and other users to retain their mental model of how a "thing" works does matter. [1] http://www.sniff.org.uk/p/scratch-is-graphical-programming.html In particular, I suspect this is why the project overview page for the prototype having python previews rather than visual worked well - since they could directly link the mental models. MIchael. (still largely away from connectivity until sept, but saw this while briefly connected!) On 28 August 2015 at 23:56, David Whale wrote: > Hi Damien, > > Yes, there is a detailed list of keywords and their operation descriptions > under the help pages. > > Presuming you have access to the live site, here is the link... > > https://live.microbit.co.uk/td/contents > > Or press the help link on the top right of the site, and on the page you > see, there is a "touch develop" help link under the touch develop section. > > it's moved around a bit, and in particular a recent change includes the > removal of the 'microbit' namespace and just the 'equivalent namespaces > from blocks' were left in scope, with a few others added. > > These are: > > basic > control > events > game > image > input > led > pins > math > bits > > The basic, control, image, input, led, pins were designed to be an almost > 1:1 translation from the blocks, so that when the convert feature was used, > the kids basically got roughly the same program. > > I'm presuming we therefore have a choice of import styles so one could use > > import microbit > > microbit.led.fadein() > > or: > > from microbit import * > > led.fadein() > > There are some small differences in the code kingdoms, for example they > call things a Pattern() whereas TD and blocks call them an Image(), but > roughly there is a 1:1 mapping of concepts in code kingdoms and *most* of > the names are close or identical. > > The game library is something that is not really a device abstraction, but > I think much research with user groups done by the BBC lead to believe that > it was a major abstraction that kids always used very quickly from getting > started, so they included it as one of the default namespaces. It has a > (very small) model of scoring and stuff like that. > > Hope this helps! > > David > > > > > > ___________________________________________________________ > David Whale, B.Sc (Hons), MIET > *Software Engineer and IET Schools Liaison Officer, Essex* > > email: dwhale at theiet.org > twitter: @whaleygeek > blog: blog.whaleygeek.co.uk > > Co-author of the new book "Adventures in Minecraft" > - lets get kids coding! > > > On 28 August 2015 at 23:22, Damien George > wrote: > >> Hi David, >> >> How do I find the reference/list of functions for the TouchDevelop >> API? Is it documented somewhere on the live site, or in a code >> repository somewhere? >> >> Thanks! >> >> Damien. >> >> >> On Fri, Aug 28, 2015 at 8:00 PM, David Whale >> wrote: >> > Nicholas, >> > >> > I'd be interested in reviewing the API spec proposals when they are done >> > (naming and containership of namespaces, parameters etc). >> > >> > Just one point. I'd like to propose that there is significant value in >> using >> > *exactly* the same names as are already used in the TouchDevelop API, >> with >> > exactly the same groupings. There's been a lot of work recently to >> > consolidate the TouchDevelop, Blocks [and to some extent CodeKingdoms] >> > vocabulary for things, so that it is a mostly seamless experience to >> move >> > from one language to another, with the transferrable knowledge of the >> common >> > micro:bit API tying everything together. >> > >> > Please do look back at the TouchDevelop, there have been a number of >> commits >> > to the live site in the last week or two with changes to default >> namespaces, >> > some additional 'standard' linked in libraries like bits, game, and >> events, >> > some name changes, and stuff like that. system_time() for example is >> not one >> > of the vocabulary words in use in the live system, it has been renamed >> a few >> > times and has settled now on "running time". >> > >> > I don't think we should get too hung up on it being "Pythonic", as long >> as >> > it is 'Python'. >> > >> > David >> > >> > ___________________________________________________________ >> > David Whale, B.Sc (Hons), MIET >> > Software Engineer and IET Schools Liaison Officer, Essex >> > >> > email: dwhale at theiet.org >> > twitter: @whaleygeek >> > blog: blog.whaleygeek.co.uk >> > >> > Co-author of the new book "Adventures in Minecraft" - lets get kids >> coding! >> > >> > >> > On 28 August 2015 at 16:08, Nicholas H.Tollervey >> wrote: >> >> >> >> Hi Folks, >> >> >> >> Although this list has been a tad quiet recently, things are moving >> >> along when it comes to Python on the micro:bit. >> >> >> >> The "blessed" device abstraction layer (DAL) created by Lancaster >> >> University for the BBC to use with the micro:bit is now working with >> >> MicroPython. >> >> >> >> What we need to do is create a Pythonic "microbit" module that gives >> >> users of Python direct access to the device hardware via the DAL. >> >> >> >> In terms of the work, this is simply a task of code-plumbing. However, >> >> the challenge will be in creating something that is Pythonic and easy >> >> enough for the nation's 11yo to get their heads around. That means >> >> obvious mono-syllabic names and shallow namespaces while still >> retaining >> >> the "shape" of the DAL. >> >> >> >> So, I'm going to start writing some documentation about the various >> >> features that the DAL exposes and both Damien and I would like help in >> >> designing the API (since actually coding it is a relatively simple task >> >> of connecting Python to the DAL). It's definitely a case of more eyes >> >> will make this better. >> >> >> >> In case you're wondering, we already have made a start. So for example, >> >> here's the output from MicroPython's help() function: >> >> >> >> >>> help() >> >> Welcome to MicroPython on the micro:bit! >> >> >> >> Be brave! Break things! Learn and have fun! :-) >> >> >> >> Type 'import microbit', press return and try these commands: >> >> microbit.display.scroll('Hello') >> >> microbit.system_time() >> >> microbit.sleep(1000) >> >> microbit.button_a.is_pressed() >> >> What do these commands do? Can you improve them? HINT: use the up and >> >> down arrow keys to get your command history (saves you typing). >> >> >> >> Explore: >> >> Type 'help(something)' to find out about it. Type 'dir(something)' to >> >> see what it can do. >> >> >> >> Stuff to explore: >> >> microbit.accelerometer -- detect the device's position >> >> (orientation) >> >> microbit.button_a.is_pressed() -- is button A pressed? (True or >> False) >> >> microbit.button_b.is_pressed() -- is button B pressed? (True or >> False) >> >> microbit.compass -- detect the device's heading >> >> microbit.display -- display things (pixels, characters, >> >> words) >> >> microbit.panic() -- go into panic mode (requires a >> >> restart) >> >> microbit.random(n) -- get a random number between 0 and n >> >> microbit.sleep(n) -- wait for n milliseconds (1 second = >> >> 1000) >> >> microbit.system_time() -- get the number of milliseconds >> since >> >> reset >> >> >> >> Control commands: >> >> CTRL-C -- stop a running program >> >> CTRL-D -- on a blank line, do a soft reset of the micro:bit >> >> >> >> >> >> The only major part of the DAL we've not already started to reference >> is >> >> the IO namespace for accessing the pins along the bottom of the device. >> >> >> >> Pretty much all of the above namespaces have things missing or clunkily >> >> named. >> >> >> >> So, fancy helping 1 million kids learn and play with Python? You will >> be >> >> given credit in the code and perhaps an easter egg I have in mind. ;-) >> >> >> >> Let me know your thoughts! >> >> >> >> Best wishes, >> >> >> >> Nicholas. >> >> >> >> >> >> _______________________________________________ >> >> 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 >> > >> _______________________________________________ >> 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: From ntoll at ntoll.org Sat Aug 29 13:19:43 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Sat, 29 Aug 2015 12:19:43 +0100 Subject: [Microbit-Python] A request for help... fancy designing a Pythonic API that up to 1 million kids would use..? In-Reply-To: References: <55E07969.5080409@ntoll.org> Message-ID: <55E1954F.4020509@ntoll.org> Hi David, Many thanks for the comments. I've looked at the TouchDevelop API and - to be honest - I have significant problems with it. As a teacher I'm left wondering how an average (i.e. a SATs level 4) 11yo would react to such a complicated beast. As a developer, I'm concerned about some of the vague naming ("callibrate" - callibrate what?), apparent duplications (drawing pixels on the display) and size of it all when you think about the simplicity of the micro:bit device itself. I believe that if we base the Python API on this we're going to end up with a horrible mess. When we looked at TouchDevelop we (as in those of us in the Python community who had signed the NDA) came to the conclusion that it was such a different beast to Python, that we'd be fitting a square peg into a round hole. We decided that TD is obviously a wonderful resource, it's just it's not a very Pythonic resource and trying to make Python work with it would end up in some weird shonky compromise that created more problems than it solved. I also believe there's something to be said for providing alternatives. Given that both the TD and Python API will ultimately sit on top of the DAL they will, of course, be similar. However, the way the API is expressed will be different simply because TD and Python ARE different. Nevertheless, I suspect we will use the same names as the DAL (display, IO, button A etc) but will probably make them conform to the Python PEP-8 standard (so it'll be button_a for example). But most importantly, we need to build something appropriate for a reading age of 11. Our aim must be to build the *best* API we can for kids to learn about the micro:bit via Python. If it's inconsistent with Microsoft's then so be it. Viva la difference and let many flowers bloom! If we do our job right then kids shouldn't have a problem moving between platforms. Python's API ought to feel natural and fun to use from the perspective of an 11yo. This beats consistency every time. Of course, we'll be sharing what we're doing via this list. We need help from people on this list! Please feel free to jump in, offer constructive critique and ideas. This is potentially the way a million children first experience Python. It's important work! Best wishes, N. On 28/08/15 20:00, David Whale wrote: > Nicholas, > > I'd be interested in reviewing the API spec proposals when they are done > (naming and containership of namespaces, parameters etc). > > Just one point. I'd like to propose that there is significant value in > using *exactly* the same names as are already used in the TouchDevelop > API, with exactly the same groupings. There's been a lot of work > recently to consolidate the TouchDevelop, Blocks [and to some extent > CodeKingdoms] vocabulary for things, so that it is a mostly seamless > experience to move from one language to another, with the transferrable > knowledge of the common micro:bit API tying everything together. > > Please do look back at the TouchDevelop, there have been a number of > commits to the live site in the last week or two with changes to default > namespaces, some additional 'standard' linked in libraries like bits, > game, and events, some name changes, and stuff like that. system_time() > for example is not one of the vocabulary words in use in the live > system, it has been renamed a few times and has settled now on "running > time". > > I don't think we should get too hung up on it being "Pythonic", as long > as it is 'Python'. > > David > > ___________________________________________________________ > David Whale, B.Sc (Hons), MIET > *Software Engineer and IET Schools Liaison Officer, Essex* > > email: dwhale at theiet.org > twitter: @whaleygeek > blog: blog.whaleygeek.co.uk > > Co-author of the new book "Adventures in Minecraft" > - lets get kids coding! > > > On 28 August 2015 at 16:08, Nicholas H.Tollervey > wrote: > > Hi Folks, > > Although this list has been a tad quiet recently, things are moving > along when it comes to Python on the micro:bit. > > The "blessed" device abstraction layer (DAL) created by Lancaster > University for the BBC to use with the micro:bit is now working with > MicroPython. > > What we need to do is create a Pythonic "microbit" module that gives > users of Python direct access to the device hardware via the DAL. > > In terms of the work, this is simply a task of code-plumbing. However, > the challenge will be in creating something that is Pythonic and easy > enough for the nation's 11yo to get their heads around. That means > obvious mono-syllabic names and shallow namespaces while still retaining > the "shape" of the DAL. > > So, I'm going to start writing some documentation about the various > features that the DAL exposes and both Damien and I would like help in > designing the API (since actually coding it is a relatively simple task > of connecting Python to the DAL). It's definitely a case of more eyes > will make this better. > > In case you're wondering, we already have made a start. So for example, > here's the output from MicroPython's help() function: > > >>> help() > Welcome to MicroPython on the micro:bit! > > Be brave! Break things! Learn and have fun! :-) > > Type 'import microbit', press return and try these commands: > microbit.display.scroll('Hello') > microbit.system_time() > microbit.sleep(1000) > microbit.button_a.is_pressed() > What do these commands do? Can you improve them? HINT: use the up and > down arrow keys to get your command history (saves you typing). > > Explore: > Type 'help(something)' to find out about it. Type 'dir(something)' to > see what it can do. > > Stuff to explore: > microbit.accelerometer -- detect the device's position > (orientation) > microbit.button_a.is_pressed() -- is button A pressed? (True or False) > microbit.button_b.is_pressed() -- is button B pressed? (True or False) > microbit.compass -- detect the device's heading > microbit.display -- display things (pixels, characters, > words) > microbit.panic() -- go into panic mode (requires a > restart) > microbit.random(n) -- get a random number between 0 and n > microbit.sleep(n) -- wait for n milliseconds (1 second = > 1000) > microbit.system_time() -- get the number of milliseconds since > reset > > Control commands: > CTRL-C -- stop a running program > CTRL-D -- on a blank line, do a soft reset of the micro:bit > > > The only major part of the DAL we've not already started to reference is > the IO namespace for accessing the pins along the bottom of the device. > > Pretty much all of the above namespaces have things missing or clunkily > named. > > So, fancy helping 1 million kids learn and play with Python? You will be > given credit in the code and perhaps an easter egg I have in mind. ;-) > > Let me know your thoughts! > > Best wishes, > > Nicholas. > > > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From david at thinkingbinaries.com Sat Aug 29 13:48:29 2015 From: david at thinkingbinaries.com (David Whale) Date: Sat, 29 Aug 2015 12:48:29 +0100 Subject: [Microbit-Python] A request for help... fancy designing a Pythonic API that up to 1 million kids would use..? In-Reply-To: <55E1954F.4020509@ntoll.org> References: <55E07969.5080409@ntoll.org> <55E1954F.4020509@ntoll.org> Message-ID: Hi Nicholas, I do get what you are saying about it being their first Python experience, and therefore it does make sense for that to be a good Python experience, as well as a good micro:bit experience. Good point. I think the best first step is to propose the top end of the Python API on this mailing list so we can see what it might look like, it will then be easier to see where additional value or 'Pythonic' magic could be added to make it easier and more natural in that language. However, I think the first step is to list all the namespaces, methods, and parameters in one list (I *think* this is just a matter of working through this page and writing down the Python equivalent): https://live.microbit.co.uk/td/contents That's probably a 20 minute task for a first stab that makes no effort at adding Pythonic beauty, and it then creates something that we could discuss as a community and make sensible compromises in various places, as you say, between consistency with the TD vocabulary and a specific Python enabled or enhanced experience. I'm happy to write down that first list as a straw-man for others to shoot down in flames, if you want. David ___________________________________________________________ David Whale, B.Sc (Hons), MIET *Software Engineer and IET Schools Liaison Officer, Essex* email: dwhale at theiet.org twitter: @whaleygeek blog: blog.whaleygeek.co.uk Co-author of the new book "Adventures in Minecraft" - lets get kids coding! On 29 August 2015 at 12:19, Nicholas H.Tollervey wrote: > Hi David, > > Many thanks for the comments. > > I've looked at the TouchDevelop API and - to be honest - I have > significant problems with it. As a teacher I'm left wondering how an > average (i.e. a SATs level 4) 11yo would react to such a complicated > beast. As a developer, I'm concerned about some of the vague naming > ("callibrate" - callibrate what?), apparent duplications (drawing pixels > on the display) and size of it all when you think about the simplicity > of the micro:bit device itself. > > I believe that if we base the Python API on this we're going to end up > with a horrible mess. > > When we looked at TouchDevelop we (as in those of us in the Python > community who had signed the NDA) came to the conclusion that it was > such a different beast to Python, that we'd be fitting a square peg into > a round hole. We decided that TD is obviously a wonderful resource, it's > just it's not a very Pythonic resource and trying to make Python work > with it would end up in some weird shonky compromise that created more > problems than it solved. > > I also believe there's something to be said for providing alternatives. > > Given that both the TD and Python API will ultimately sit on top of the > DAL they will, of course, be similar. However, the way the API is > expressed will be different simply because TD and Python ARE different. > Nevertheless, I suspect we will use the same names as the DAL (display, > IO, button A etc) but will probably make them conform to the Python > PEP-8 standard (so it'll be button_a for example). > > But most importantly, we need to build something appropriate for a > reading age of 11. > > Our aim must be to build the *best* API we can for kids to learn about > the micro:bit via Python. If it's inconsistent with Microsoft's then so > be it. Viva la difference and let many flowers bloom! If we do our job > right then kids shouldn't have a problem moving between platforms. > Python's API ought to feel natural and fun to use from the perspective > of an 11yo. This beats consistency every time. > > Of course, we'll be sharing what we're doing via this list. We need help > from people on this list! Please feel free to jump in, offer > constructive critique and ideas. This is potentially the way a million > children first experience Python. > > It's important work! > > Best wishes, > > N. > > On 28/08/15 20:00, David Whale wrote: > > Nicholas, > > > > I'd be interested in reviewing the API spec proposals when they are done > > (naming and containership of namespaces, parameters etc). > > > > Just one point. I'd like to propose that there is significant value in > > using *exactly* the same names as are already used in the TouchDevelop > > API, with exactly the same groupings. There's been a lot of work > > recently to consolidate the TouchDevelop, Blocks [and to some extent > > CodeKingdoms] vocabulary for things, so that it is a mostly seamless > > experience to move from one language to another, with the transferrable > > knowledge of the common micro:bit API tying everything together. > > > > Please do look back at the TouchDevelop, there have been a number of > > commits to the live site in the last week or two with changes to default > > namespaces, some additional 'standard' linked in libraries like bits, > > game, and events, some name changes, and stuff like that. system_time() > > for example is not one of the vocabulary words in use in the live > > system, it has been renamed a few times and has settled now on "running > > time". > > > > I don't think we should get too hung up on it being "Pythonic", as long > > as it is 'Python'. > > > > David > > > > ___________________________________________________________ > > David Whale, B.Sc (Hons), MIET > > *Software Engineer and IET Schools Liaison Officer, Essex* > > > > email: dwhale at theiet.org > > twitter: @whaleygeek > > blog: blog.whaleygeek.co.uk > > > > Co-author of the new book "Adventures in Minecraft" > > - lets get kids coding! > > > > > > On 28 August 2015 at 16:08, Nicholas H.Tollervey > > wrote: > > > > Hi Folks, > > > > Although this list has been a tad quiet recently, things are moving > > along when it comes to Python on the micro:bit. > > > > The "blessed" device abstraction layer (DAL) created by Lancaster > > University for the BBC to use with the micro:bit is now working with > > MicroPython. > > > > What we need to do is create a Pythonic "microbit" module that gives > > users of Python direct access to the device hardware via the DAL. > > > > In terms of the work, this is simply a task of code-plumbing. > However, > > the challenge will be in creating something that is Pythonic and easy > > enough for the nation's 11yo to get their heads around. That means > > obvious mono-syllabic names and shallow namespaces while still > retaining > > the "shape" of the DAL. > > > > So, I'm going to start writing some documentation about the various > > features that the DAL exposes and both Damien and I would like help > in > > designing the API (since actually coding it is a relatively simple > task > > of connecting Python to the DAL). It's definitely a case of more eyes > > will make this better. > > > > In case you're wondering, we already have made a start. So for > example, > > here's the output from MicroPython's help() function: > > > > >>> help() > > Welcome to MicroPython on the micro:bit! > > > > Be brave! Break things! Learn and have fun! :-) > > > > Type 'import microbit', press return and try these commands: > > microbit.display.scroll('Hello') > > microbit.system_time() > > microbit.sleep(1000) > > microbit.button_a.is_pressed() > > What do these commands do? Can you improve them? HINT: use the up and > > down arrow keys to get your command history (saves you typing). > > > > Explore: > > Type 'help(something)' to find out about it. Type 'dir(something)' to > > see what it can do. > > > > Stuff to explore: > > microbit.accelerometer -- detect the device's position > > (orientation) > > microbit.button_a.is_pressed() -- is button A pressed? (True or > False) > > microbit.button_b.is_pressed() -- is button B pressed? (True or > False) > > microbit.compass -- detect the device's heading > > microbit.display -- display things (pixels, > characters, > > words) > > microbit.panic() -- go into panic mode (requires a > > restart) > > microbit.random(n) -- get a random number between 0 > and n > > microbit.sleep(n) -- wait for n milliseconds (1 > second = > > 1000) > > microbit.system_time() -- get the number of milliseconds > since > > reset > > > > Control commands: > > CTRL-C -- stop a running program > > CTRL-D -- on a blank line, do a soft reset of the micro:bit > > > > > > The only major part of the DAL we've not already started to > reference is > > the IO namespace for accessing the pins along the bottom of the > device. > > > > Pretty much all of the above namespaces have things missing or > clunkily > > named. > > > > So, fancy helping 1 million kids learn and play with Python? You > will be > > given credit in the code and perhaps an easter egg I have in mind. > ;-) > > > > Let me know your thoughts! > > > > Best wishes, > > > > Nicholas. > > > > > > _______________________________________________ > > 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 > > > > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at thinkingbinaries.com Sat Aug 29 13:51:17 2015 From: david at thinkingbinaries.com (David Whale) Date: Sat, 29 Aug 2015 12:51:17 +0100 Subject: [Microbit-Python] A request for help... fancy designing a Pythonic API that up to 1 million kids would use..? In-Reply-To: References: <55E07969.5080409@ntoll.org> <55E1954F.4020509@ntoll.org> Message-ID: Actually, I'll stand up and be counted. I'll do a first pass of this now as a "stake in the ground", which others than then attack with the flame thrower. Back in 20 mins. D ___________________________________________________________ David Whale, B.Sc (Hons), MIET *Software Engineer and IET Schools Liaison Officer, Essex* email: dwhale at theiet.org twitter: @whaleygeek blog: blog.whaleygeek.co.uk Co-author of the new book "Adventures in Minecraft" - lets get kids coding! On 29 August 2015 at 12:48, David Whale wrote: > Hi Nicholas, > > I do get what you are saying about it being their first Python experience, > and therefore it does make sense for that to be a good Python experience, > as well as a good micro:bit experience. Good point. > > I think the best first step is to propose the top end of the Python API on > this mailing list so we can see what it might look like, it will then be > easier to see where additional value or 'Pythonic' magic could be added to > make it easier and more natural in that language. However, I think the > first step is to list all the namespaces, methods, and parameters in one > list (I *think* this is just a matter of working through this page and > writing down the Python equivalent): > > https://live.microbit.co.uk/td/contents > > That's probably a 20 minute task for a first stab that makes no effort at > adding Pythonic beauty, and it then creates something that we could discuss > as a community and make sensible compromises in various places, as you say, > between consistency with the TD vocabulary and a specific Python enabled or > enhanced experience. > > I'm happy to write down that first list as a straw-man for others to shoot > down in flames, if you want. > > David > > > ___________________________________________________________ > David Whale, B.Sc (Hons), MIET > *Software Engineer and IET Schools Liaison Officer, Essex* > > email: dwhale at theiet.org > twitter: @whaleygeek > blog: blog.whaleygeek.co.uk > > Co-author of the new book "Adventures in Minecraft" > - lets get kids coding! > > > On 29 August 2015 at 12:19, Nicholas H.Tollervey wrote: > >> Hi David, >> >> Many thanks for the comments. >> >> I've looked at the TouchDevelop API and - to be honest - I have >> significant problems with it. As a teacher I'm left wondering how an >> average (i.e. a SATs level 4) 11yo would react to such a complicated >> beast. As a developer, I'm concerned about some of the vague naming >> ("callibrate" - callibrate what?), apparent duplications (drawing pixels >> on the display) and size of it all when you think about the simplicity >> of the micro:bit device itself. >> >> I believe that if we base the Python API on this we're going to end up >> with a horrible mess. >> >> When we looked at TouchDevelop we (as in those of us in the Python >> community who had signed the NDA) came to the conclusion that it was >> such a different beast to Python, that we'd be fitting a square peg into >> a round hole. We decided that TD is obviously a wonderful resource, it's >> just it's not a very Pythonic resource and trying to make Python work >> with it would end up in some weird shonky compromise that created more >> problems than it solved. >> >> I also believe there's something to be said for providing alternatives. >> >> Given that both the TD and Python API will ultimately sit on top of the >> DAL they will, of course, be similar. However, the way the API is >> expressed will be different simply because TD and Python ARE different. >> Nevertheless, I suspect we will use the same names as the DAL (display, >> IO, button A etc) but will probably make them conform to the Python >> PEP-8 standard (so it'll be button_a for example). >> >> But most importantly, we need to build something appropriate for a >> reading age of 11. >> >> Our aim must be to build the *best* API we can for kids to learn about >> the micro:bit via Python. If it's inconsistent with Microsoft's then so >> be it. Viva la difference and let many flowers bloom! If we do our job >> right then kids shouldn't have a problem moving between platforms. >> Python's API ought to feel natural and fun to use from the perspective >> of an 11yo. This beats consistency every time. >> >> Of course, we'll be sharing what we're doing via this list. We need help >> from people on this list! Please feel free to jump in, offer >> constructive critique and ideas. This is potentially the way a million >> children first experience Python. >> >> It's important work! >> >> Best wishes, >> >> N. >> >> On 28/08/15 20:00, David Whale wrote: >> > Nicholas, >> > >> > I'd be interested in reviewing the API spec proposals when they are done >> > (naming and containership of namespaces, parameters etc). >> > >> > Just one point. I'd like to propose that there is significant value in >> > using *exactly* the same names as are already used in the TouchDevelop >> > API, with exactly the same groupings. There's been a lot of work >> > recently to consolidate the TouchDevelop, Blocks [and to some extent >> > CodeKingdoms] vocabulary for things, so that it is a mostly seamless >> > experience to move from one language to another, with the transferrable >> > knowledge of the common micro:bit API tying everything together. >> > >> > Please do look back at the TouchDevelop, there have been a number of >> > commits to the live site in the last week or two with changes to default >> > namespaces, some additional 'standard' linked in libraries like bits, >> > game, and events, some name changes, and stuff like that. system_time() >> > for example is not one of the vocabulary words in use in the live >> > system, it has been renamed a few times and has settled now on "running >> > time". >> > >> > I don't think we should get too hung up on it being "Pythonic", as long >> > as it is 'Python'. >> > >> > David >> > >> > ___________________________________________________________ >> > David Whale, B.Sc (Hons), MIET >> > *Software Engineer and IET Schools Liaison Officer, Essex* >> > >> > email: dwhale at theiet.org >> > twitter: @whaleygeek >> > blog: blog.whaleygeek.co.uk >> > >> > Co-author of the new book "Adventures in Minecraft" >> > - lets get kids coding! >> > >> > >> > On 28 August 2015 at 16:08, Nicholas H.Tollervey > > > wrote: >> > >> > Hi Folks, >> > >> > Although this list has been a tad quiet recently, things are moving >> > along when it comes to Python on the micro:bit. >> > >> > The "blessed" device abstraction layer (DAL) created by Lancaster >> > University for the BBC to use with the micro:bit is now working with >> > MicroPython. >> > >> > What we need to do is create a Pythonic "microbit" module that gives >> > users of Python direct access to the device hardware via the DAL. >> > >> > In terms of the work, this is simply a task of code-plumbing. >> However, >> > the challenge will be in creating something that is Pythonic and >> easy >> > enough for the nation's 11yo to get their heads around. That means >> > obvious mono-syllabic names and shallow namespaces while still >> retaining >> > the "shape" of the DAL. >> > >> > So, I'm going to start writing some documentation about the various >> > features that the DAL exposes and both Damien and I would like help >> in >> > designing the API (since actually coding it is a relatively simple >> task >> > of connecting Python to the DAL). It's definitely a case of more >> eyes >> > will make this better. >> > >> > In case you're wondering, we already have made a start. So for >> example, >> > here's the output from MicroPython's help() function: >> > >> > >>> help() >> > Welcome to MicroPython on the micro:bit! >> > >> > Be brave! Break things! Learn and have fun! :-) >> > >> > Type 'import microbit', press return and try these commands: >> > microbit.display.scroll('Hello') >> > microbit.system_time() >> > microbit.sleep(1000) >> > microbit.button_a.is_pressed() >> > What do these commands do? Can you improve them? HINT: use the up >> and >> > down arrow keys to get your command history (saves you typing). >> > >> > Explore: >> > Type 'help(something)' to find out about it. Type 'dir(something)' >> to >> > see what it can do. >> > >> > Stuff to explore: >> > microbit.accelerometer -- detect the device's position >> > (orientation) >> > microbit.button_a.is_pressed() -- is button A pressed? (True or >> False) >> > microbit.button_b.is_pressed() -- is button B pressed? (True or >> False) >> > microbit.compass -- detect the device's heading >> > microbit.display -- display things (pixels, >> characters, >> > words) >> > microbit.panic() -- go into panic mode (requires a >> > restart) >> > microbit.random(n) -- get a random number between 0 >> and n >> > microbit.sleep(n) -- wait for n milliseconds (1 >> second = >> > 1000) >> > microbit.system_time() -- get the number of milliseconds >> since >> > reset >> > >> > Control commands: >> > CTRL-C -- stop a running program >> > CTRL-D -- on a blank line, do a soft reset of the micro:bit >> > >> > >> > The only major part of the DAL we've not already started to >> reference is >> > the IO namespace for accessing the pins along the bottom of the >> device. >> > >> > Pretty much all of the above namespaces have things missing or >> clunkily >> > named. >> > >> > So, fancy helping 1 million kids learn and play with Python? You >> will be >> > given credit in the code and perhaps an easter egg I have in mind. >> ;-) >> > >> > Let me know your thoughts! >> > >> > Best wishes, >> > >> > Nicholas. >> > >> > >> > _______________________________________________ >> > 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 >> > >> >> >> >> _______________________________________________ >> Microbit mailing list >> Microbit at python.org >> https://mail.python.org/mailman/listinfo/microbit >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ntoll at ntoll.org Sat Aug 29 13:54:49 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Sat, 29 Aug 2015 12:54:49 +0100 Subject: [Microbit-Python] A request for help... fancy designing a Pythonic API that up to 1 million kids would use..? In-Reply-To: References: <55E07969.5080409@ntoll.org> <55E1954F.4020509@ntoll.org> Message-ID: <55E19D89.8040705@ntoll.org> :-) Remember the contents of the help() text I pasted. That's essentially where we're at, right now. It's based upon the DAL (not TD). N. On 29/08/15 12:51, David Whale wrote: > Actually, I'll stand up and be counted. I'll do a first pass of this now > as a "stake in the ground", which others than then attack with the flame > thrower. > > Back in 20 mins. > > D > > > ___________________________________________________________ > David Whale, B.Sc (Hons), MIET > *Software Engineer and IET Schools Liaison Officer, Essex* > > email: dwhale at theiet.org > twitter: @whaleygeek > blog: blog.whaleygeek.co.uk > > Co-author of the new book "Adventures in Minecraft" > - lets get kids coding! > > > On 29 August 2015 at 12:48, David Whale > wrote: > > Hi Nicholas, > > I do get what you are saying about it being their first Python > experience, and therefore it does make sense for that to be a good > Python experience, as well as a good micro:bit experience. Good point. > > I think the best first step is to propose the top end of the Python > API on this mailing list so we can see what it might look like, it > will then be easier to see where additional value or 'Pythonic' > magic could be added to make it easier and more natural in that > language. However, I think the first step is to list all the > namespaces, methods, and parameters in one list (I *think* this is > just a matter of working through this page and writing down the > Python equivalent): > > https://live.microbit.co.uk/td/contents > > That's probably a 20 minute task for a first stab that makes no > effort at adding Pythonic beauty, and it then creates something that > we could discuss as a community and make sensible compromises in > various places, as you say, between consistency with the TD > vocabulary and a specific Python enabled or enhanced experience. > > I'm happy to write down that first list as a straw-man for others to > shoot down in flames, if you want. > > David > > > ___________________________________________________________ > David Whale, B.Sc (Hons), MIET > *Software Engineer and IET Schools Liaison Officer, Essex* > > email: dwhale at theiet.org > twitter: @whaleygeek > blog: blog.whaleygeek.co.uk > > Co-author of the new book "Adventures in Minecraft" > - lets get kids coding! > > > On 29 August 2015 at 12:19, Nicholas H.Tollervey > wrote: > > Hi David, > > Many thanks for the comments. > > I've looked at the TouchDevelop API and - to be honest - I have > significant problems with it. As a teacher I'm left wondering how an > average (i.e. a SATs level 4) 11yo would react to such a complicated > beast. As a developer, I'm concerned about some of the vague naming > ("callibrate" - callibrate what?), apparent duplications > (drawing pixels > on the display) and size of it all when you think about the > simplicity > of the micro:bit device itself. > > I believe that if we base the Python API on this we're going to > end up > with a horrible mess. > > When we looked at TouchDevelop we (as in those of us in the Python > community who had signed the NDA) came to the conclusion that it was > such a different beast to Python, that we'd be fitting a square > peg into > a round hole. We decided that TD is obviously a wonderful > resource, it's > just it's not a very Pythonic resource and trying to make Python > work > with it would end up in some weird shonky compromise that > created more > problems than it solved. > > I also believe there's something to be said for providing > alternatives. > > Given that both the TD and Python API will ultimately sit on top > of the > DAL they will, of course, be similar. However, the way the API is > expressed will be different simply because TD and Python ARE > different. > Nevertheless, I suspect we will use the same names as the DAL > (display, > IO, button A etc) but will probably make them conform to the Python > PEP-8 standard (so it'll be button_a for example). > > But most importantly, we need to build something appropriate for a > reading age of 11. > > Our aim must be to build the *best* API we can for kids to learn > about > the micro:bit via Python. If it's inconsistent with Microsoft's > then so > be it. Viva la difference and let many flowers bloom! If we do > our job > right then kids shouldn't have a problem moving between platforms. > Python's API ought to feel natural and fun to use from the > perspective > of an 11yo. This beats consistency every time. > > Of course, we'll be sharing what we're doing via this list. We > need help > from people on this list! Please feel free to jump in, offer > constructive critique and ideas. This is potentially the way a > million > children first experience Python. > > It's important work! > > Best wishes, > > N. > > On 28/08/15 20:00, David Whale wrote: > > Nicholas, > > > > I'd be interested in reviewing the API spec proposals when they are done > > (naming and containership of namespaces, parameters etc). > > > > Just one point. I'd like to propose that there is significant value in > > using *exactly* the same names as are already used in the TouchDevelop > > API, with exactly the same groupings. There's been a lot of work > > recently to consolidate the TouchDevelop, Blocks [and to some extent > > CodeKingdoms] vocabulary for things, so that it is a mostly seamless > > experience to move from one language to another, with the transferrable > > knowledge of the common micro:bit API tying everything together. > > > > Please do look back at the TouchDevelop, there have been a number of > > commits to the live site in the last week or two with changes to default > > namespaces, some additional 'standard' linked in libraries like bits, > > game, and events, some name changes, and stuff like that. system_time() > > for example is not one of the vocabulary words in use in the live > > system, it has been renamed a few times and has settled now on "running > > time". > > > > I don't think we should get too hung up on it being "Pythonic", as long > > as it is 'Python'. > > > > David > > > > ___________________________________________________________ > > David Whale, B.Sc (Hons), MIET > > *Software Engineer and IET Schools Liaison Officer, Essex* > > > > email: dwhale at theiet.org > > > > twitter: @whaleygeek > > blog: blog.whaleygeek.co.uk > > > > > Co-author of the new book "Adventures in Minecraft" > > - lets get kids coding! > > > > > > On 28 August 2015 at 16:08, Nicholas H.Tollervey > > >> wrote: > > > > Hi Folks, > > > > Although this list has been a tad quiet recently, things > are moving > > along when it comes to Python on the micro:bit. > > > > The "blessed" device abstraction layer (DAL) created by > Lancaster > > University for the BBC to use with the micro:bit is now > working with > > MicroPython. > > > > What we need to do is create a Pythonic "microbit" module > that gives > > users of Python direct access to the device hardware via > the DAL. > > > > In terms of the work, this is simply a task of > code-plumbing. However, > > the challenge will be in creating something that is > Pythonic and easy > > enough for the nation's 11yo to get their heads around. > That means > > obvious mono-syllabic names and shallow namespaces while > still retaining > > the "shape" of the DAL. > > > > So, I'm going to start writing some documentation about > the various > > features that the DAL exposes and both Damien and I would > like help in > > designing the API (since actually coding it is a > relatively simple task > > of connecting Python to the DAL). It's definitely a case > of more eyes > > will make this better. > > > > In case you're wondering, we already have made a start. So > for example, > > here's the output from MicroPython's help() function: > > > > >>> help() > > Welcome to MicroPython on the micro:bit! > > > > Be brave! Break things! Learn and have fun! :-) > > > > Type 'import microbit', press return and try these commands: > > microbit.display.scroll('Hello') > > microbit.system_time() > > microbit.sleep(1000) > > microbit.button_a.is_pressed() > > What do these commands do? Can you improve them? HINT: use > the up and > > down arrow keys to get your command history (saves you > typing). > > > > Explore: > > Type 'help(something)' to find out about it. Type > 'dir(something)' to > > see what it can do. > > > > Stuff to explore: > > microbit.accelerometer -- detect the device's > position > > (orientation) > > microbit.button_a.is_pressed() -- is button A pressed? > (True or False) > > microbit.button_b.is_pressed() -- is button B pressed? > (True or False) > > microbit.compass -- detect the device's > heading > > microbit.display -- display things > (pixels, characters, > > words) > > microbit.panic() -- go into panic mode > (requires a > > restart) > > microbit.random(n) -- get a random number > between 0 and n > > microbit.sleep(n) -- wait for n > milliseconds (1 second = > > 1000) > > microbit.system_time() -- get the number of > milliseconds since > > reset > > > > Control commands: > > CTRL-C -- stop a running program > > CTRL-D -- on a blank line, do a soft reset of the > micro:bit > > > > > > The only major part of the DAL we've not already started > to reference is > > the IO namespace for accessing the pins along the bottom > of the device. > > > > Pretty much all of the above namespaces have things > missing or clunkily > > named. > > > > So, fancy helping 1 million kids learn and play with > Python? You will be > > given credit in the code and perhaps an easter egg I have > in mind. ;-) > > > > Let me know your thoughts! > > > > Best wishes, > > > > Nicholas. > > > > > > _______________________________________________ > > 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 > > > > > > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From david at thinkingbinaries.com Sat Aug 29 14:35:59 2015 From: david at thinkingbinaries.com (David Whale) Date: Sat, 29 Aug 2015 13:35:59 +0100 Subject: [Microbit-Python] A request for help... fancy designing a Pythonic API that up to 1 million kids would use..? In-Reply-To: References: <55E07969.5080409@ntoll.org> <55E1954F.4020509@ntoll.org> Message-ID: Hi All, Here are the latest TD namespaces and contents, which you should note is not necessarily the DAL API, so read it a bit with a pinch of salt in places. Also I checked both the docs and the latest actual editor and there are differences, which I have marked as below. This *might* be the best/most definitive list we have at the moment, at least! This is not an attempt to make it Pythonic, only a stake in the ground to say it is a starting point to move forward from, to raise discussions per method as to whether to keep consistency or add Pythonic magic (or both, of course). Nicholas - is it best for us to converse directly on this, or on the list? i.e. are there others who would like to be involved, or is it best for some of us to go off to one side for a bun-fight and report back when we have something more solid to propose? KEY - means removed from latest drop but still in docs * means appeared in latest drop but not in docs yet MICROBIT.BASIC NAMESPACE ------------------------ plot image(leds) show number(value, interval) show string(text, interval) show animation(leds, interval) clear screen() forever(body) pause(ms) MICROBIT.LED NAMESPACE ---------------------- plot(x, y) unplot(x, y) point(x, y)->bool set brightness(value) fade in(ms) fade out(ms) *plot all() *screenshot->img *toggle(x, y) *toggle all() *brightness()->int MICROBIT.CONTROL NAMESPACE -------------------------- in background(body) *MICROBIT.EVENTS NAMESPACE ------------------------- {possibly limited to bluetooth only, but they do go on the event bus, so there might still be a way to get these to action even without BT} *remote control(event) * event=[play,pause,stop,next track, previous track, rewind, volume up, volume down] *camera(event) * event=[take photo, start video capture, stop video capture, toggle front-rear, * launch photo mode, launch video mode, stop photo mode, stop video mode] *alert(event) * event=[display toast, vibrate, play sound, play ringtone, find my phone, * alarm 1, alarm 2, alarm 3, alarm 4, alarm 5, alarm 6, *audio recorder(event) * event=[launch, start capture, stop capture, stop] *MICROBIT.GAME NAMESPACE ----------------------- (a standard library already included in the root namespace) *add life(lives) *add score(points) *current time()->number *level->number *level up() *life()->number *remove life(live) *score()->number *set life(value) *set score(value) *start countdown(ms) MICROBIT.INPUT NAMESPACE ------------------------ {note, 'body' is block of code} button is pressed(name)->bool on button pressed(body) acceleration(dimension)->number compass heading()->number calibrate() running time()->number on shake(body) on fall(body) on screen up(body) on screen down(body) on logo up(body) on logo down(body) *pin is pressed(name)->bool *on pin pressed(body) MICROBIT.IMAGE NAMESPACE ------------------------ create image img->clear() img->set pixel(x,y,value) img->pixel(x,y)->bool img->show image(x offset) img->scroll image(x offset per step, interval) img->width()->int MICROBIT.PINS NAMESPACE ----------------------- analog read pin(name)->number analog write pin(name, value) digital read pin(name)->number digital write pin(name, value) -pin is pressed [moved to input namespace] -on pin pressed [moved to input namespace] MICROBIT.MATH NAMESPACE ----------------------- abs(x)->number clamp(min, max, value)->number max(x, y)->number min(x, y)->number mod(x, y)->number pow(x, y)->number random(limit)->number *sqrt(x)->number *sign(x)->number MICROBIT.BITS NAMESPACE ----------------------- add int32 multiply int32 subtract int32 and uint32(x, y)->number xor uint32(x, y)->number -not uint32 [removed] -create buffer [removed] -string to buffer [removed] rotate left uint32(x, bits)->number rotate right uint32(x, bits)->number shift left uint32(x, bits)->number shift right uint32(x, bits)->number END. ___________________________________________________________ David Whale, B.Sc (Hons), MIET *Software Engineer and IET Schools Liaison Officer, Essex* email: dwhale at theiet.org twitter: @whaleygeek blog: blog.whaleygeek.co.uk Co-author of the new book "Adventures in Minecraft" - lets get kids coding! On 29 August 2015 at 12:51, David Whale wrote: > Actually, I'll stand up and be counted. I'll do a first pass of this now > as a "stake in the ground", which others than then attack with the flame > thrower. > > Back in 20 mins. > > D > > > ___________________________________________________________ > David Whale, B.Sc (Hons), MIET > *Software Engineer and IET Schools Liaison Officer, Essex* > > email: dwhale at theiet.org > twitter: @whaleygeek > blog: blog.whaleygeek.co.uk > > Co-author of the new book "Adventures in Minecraft" > - lets get kids coding! > > > On 29 August 2015 at 12:48, David Whale > wrote: > >> Hi Nicholas, >> >> I do get what you are saying about it being their first Python >> experience, and therefore it does make sense for that to be a good Python >> experience, as well as a good micro:bit experience. Good point. >> >> I think the best first step is to propose the top end of the Python API >> on this mailing list so we can see what it might look like, it will then be >> easier to see where additional value or 'Pythonic' magic could be added to >> make it easier and more natural in that language. However, I think the >> first step is to list all the namespaces, methods, and parameters in one >> list (I *think* this is just a matter of working through this page and >> writing down the Python equivalent): >> >> https://live.microbit.co.uk/td/contents >> >> That's probably a 20 minute task for a first stab that makes no effort at >> adding Pythonic beauty, and it then creates something that we could discuss >> as a community and make sensible compromises in various places, as you say, >> between consistency with the TD vocabulary and a specific Python enabled or >> enhanced experience. >> >> I'm happy to write down that first list as a straw-man for others to >> shoot down in flames, if you want. >> >> David >> >> >> ___________________________________________________________ >> David Whale, B.Sc (Hons), MIET >> *Software Engineer and IET Schools Liaison Officer, Essex* >> >> email: dwhale at theiet.org >> twitter: @whaleygeek >> blog: blog.whaleygeek.co.uk >> >> Co-author of the new book "Adventures in Minecraft" >> - lets get kids coding! >> >> >> On 29 August 2015 at 12:19, Nicholas H.Tollervey wrote: >> >>> Hi David, >>> >>> Many thanks for the comments. >>> >>> I've looked at the TouchDevelop API and - to be honest - I have >>> significant problems with it. As a teacher I'm left wondering how an >>> average (i.e. a SATs level 4) 11yo would react to such a complicated >>> beast. As a developer, I'm concerned about some of the vague naming >>> ("callibrate" - callibrate what?), apparent duplications (drawing pixels >>> on the display) and size of it all when you think about the simplicity >>> of the micro:bit device itself. >>> >>> I believe that if we base the Python API on this we're going to end up >>> with a horrible mess. >>> >>> When we looked at TouchDevelop we (as in those of us in the Python >>> community who had signed the NDA) came to the conclusion that it was >>> such a different beast to Python, that we'd be fitting a square peg into >>> a round hole. We decided that TD is obviously a wonderful resource, it's >>> just it's not a very Pythonic resource and trying to make Python work >>> with it would end up in some weird shonky compromise that created more >>> problems than it solved. >>> >>> I also believe there's something to be said for providing alternatives. >>> >>> Given that both the TD and Python API will ultimately sit on top of the >>> DAL they will, of course, be similar. However, the way the API is >>> expressed will be different simply because TD and Python ARE different. >>> Nevertheless, I suspect we will use the same names as the DAL (display, >>> IO, button A etc) but will probably make them conform to the Python >>> PEP-8 standard (so it'll be button_a for example). >>> >>> But most importantly, we need to build something appropriate for a >>> reading age of 11. >>> >>> Our aim must be to build the *best* API we can for kids to learn about >>> the micro:bit via Python. If it's inconsistent with Microsoft's then so >>> be it. Viva la difference and let many flowers bloom! If we do our job >>> right then kids shouldn't have a problem moving between platforms. >>> Python's API ought to feel natural and fun to use from the perspective >>> of an 11yo. This beats consistency every time. >>> >>> Of course, we'll be sharing what we're doing via this list. We need help >>> from people on this list! Please feel free to jump in, offer >>> constructive critique and ideas. This is potentially the way a million >>> children first experience Python. >>> >>> It's important work! >>> >>> Best wishes, >>> >>> N. >>> >>> On 28/08/15 20:00, David Whale wrote: >>> > Nicholas, >>> > >>> > I'd be interested in reviewing the API spec proposals when they are >>> done >>> > (naming and containership of namespaces, parameters etc). >>> > >>> > Just one point. I'd like to propose that there is significant value in >>> > using *exactly* the same names as are already used in the TouchDevelop >>> > API, with exactly the same groupings. There's been a lot of work >>> > recently to consolidate the TouchDevelop, Blocks [and to some extent >>> > CodeKingdoms] vocabulary for things, so that it is a mostly seamless >>> > experience to move from one language to another, with the transferrable >>> > knowledge of the common micro:bit API tying everything together. >>> > >>> > Please do look back at the TouchDevelop, there have been a number of >>> > commits to the live site in the last week or two with changes to >>> default >>> > namespaces, some additional 'standard' linked in libraries like bits, >>> > game, and events, some name changes, and stuff like that. system_time() >>> > for example is not one of the vocabulary words in use in the live >>> > system, it has been renamed a few times and has settled now on "running >>> > time". >>> > >>> > I don't think we should get too hung up on it being "Pythonic", as long >>> > as it is 'Python'. >>> > >>> > David >>> > >>> > ___________________________________________________________ >>> > David Whale, B.Sc (Hons), MIET >>> > *Software Engineer and IET Schools Liaison Officer, Essex* >>> > >>> > email: dwhale at theiet.org >>> > twitter: @whaleygeek >>> > blog: blog.whaleygeek.co.uk >>> > >>> > Co-author of the new book "Adventures in Minecraft" >>> > - lets get kids coding! >>> > >>> > >>> > On 28 August 2015 at 16:08, Nicholas H.Tollervey >> > > wrote: >>> > >>> > Hi Folks, >>> > >>> > Although this list has been a tad quiet recently, things are moving >>> > along when it comes to Python on the micro:bit. >>> > >>> > The "blessed" device abstraction layer (DAL) created by Lancaster >>> > University for the BBC to use with the micro:bit is now working >>> with >>> > MicroPython. >>> > >>> > What we need to do is create a Pythonic "microbit" module that >>> gives >>> > users of Python direct access to the device hardware via the DAL. >>> > >>> > In terms of the work, this is simply a task of code-plumbing. >>> However, >>> > the challenge will be in creating something that is Pythonic and >>> easy >>> > enough for the nation's 11yo to get their heads around. That means >>> > obvious mono-syllabic names and shallow namespaces while still >>> retaining >>> > the "shape" of the DAL. >>> > >>> > So, I'm going to start writing some documentation about the various >>> > features that the DAL exposes and both Damien and I would like >>> help in >>> > designing the API (since actually coding it is a relatively simple >>> task >>> > of connecting Python to the DAL). It's definitely a case of more >>> eyes >>> > will make this better. >>> > >>> > In case you're wondering, we already have made a start. So for >>> example, >>> > here's the output from MicroPython's help() function: >>> > >>> > >>> help() >>> > Welcome to MicroPython on the micro:bit! >>> > >>> > Be brave! Break things! Learn and have fun! :-) >>> > >>> > Type 'import microbit', press return and try these commands: >>> > microbit.display.scroll('Hello') >>> > microbit.system_time() >>> > microbit.sleep(1000) >>> > microbit.button_a.is_pressed() >>> > What do these commands do? Can you improve them? HINT: use the up >>> and >>> > down arrow keys to get your command history (saves you typing). >>> > >>> > Explore: >>> > Type 'help(something)' to find out about it. Type 'dir(something)' >>> to >>> > see what it can do. >>> > >>> > Stuff to explore: >>> > microbit.accelerometer -- detect the device's position >>> > (orientation) >>> > microbit.button_a.is_pressed() -- is button A pressed? (True or >>> False) >>> > microbit.button_b.is_pressed() -- is button B pressed? (True or >>> False) >>> > microbit.compass -- detect the device's heading >>> > microbit.display -- display things (pixels, >>> characters, >>> > words) >>> > microbit.panic() -- go into panic mode (requires a >>> > restart) >>> > microbit.random(n) -- get a random number between 0 >>> and n >>> > microbit.sleep(n) -- wait for n milliseconds (1 >>> second = >>> > 1000) >>> > microbit.system_time() -- get the number of milliseconds >>> since >>> > reset >>> > >>> > Control commands: >>> > CTRL-C -- stop a running program >>> > CTRL-D -- on a blank line, do a soft reset of the >>> micro:bit >>> > >>> > >>> > The only major part of the DAL we've not already started to >>> reference is >>> > the IO namespace for accessing the pins along the bottom of the >>> device. >>> > >>> > Pretty much all of the above namespaces have things missing or >>> clunkily >>> > named. >>> > >>> > So, fancy helping 1 million kids learn and play with Python? You >>> will be >>> > given credit in the code and perhaps an easter egg I have in mind. >>> ;-) >>> > >>> > Let me know your thoughts! >>> > >>> > Best wishes, >>> > >>> > Nicholas. >>> > >>> > >>> > _______________________________________________ >>> > 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 >>> > >>> >>> >>> >>> _______________________________________________ >>> Microbit mailing list >>> Microbit at python.org >>> https://mail.python.org/mailman/listinfo/microbit >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at hotpy.org Sat Aug 29 19:25:34 2015 From: mark at hotpy.org (Mark Shannon) Date: Sat, 29 Aug 2015 18:25:34 +0100 Subject: [Microbit-Python] A request for help... fancy designing a Pythonic API that up to 1 million kids would use..? In-Reply-To: References: <55E07969.5080409@ntoll.org> <55E1954F.4020509@ntoll.org> Message-ID: <55E1EB0E.1050006@hotpy.org> Hi, Here is my initial suggestion for an API covering all the TD contents as provided by David. As a general comment, I like to suggest that we shouldn't be too afraid to add things to the builtin namespace. If every program is going to start with: import microbit from microbit import pins from microbit import leds from microbit import buttons from microbit import game from microbit import inputs then we may as well adds those to the builtins namespace. So I would suggest that the following objects (which could be modules) are added to the builtins at startup: pins, leds, buttons, game, inputs I have made fairly extensive use of properties: img = leds.image ; leds.image = img rather than img = leds.get_image() ; leds.set_image(img) Not only do I think this is a more readable, pythonic interface, it also prevents the following error, when parentheses are forgotten. >>> image = led.get_image >>> image So, here is a first draft of the API: On 29/08/15 13:35, David Whale wrote: [snip] > > MICROBIT.BASIC NAMESPACE > ------------------------ > > plot image(leds) What does this do? There is no image argument. To display an image on the leds: leds.image = img > show number(value, interval) I'm guessing that this displays a number using the leds. If so, then: leds.show(number, duration=REASONABLE_DEFAULT) > show string(text, interval) Same for text? leds.show(text, duration=REASONABLE_DEFAULT) > show animation(leds, interval) And again? leds.show(animation, duration=REASONABLE_DEFAULT) > clear screen() leds.clear() > forever(body) I think "while True:" works quite well for this :) > pause(ms) Seems fine as a function in the builtins namespace. > > > MICROBIT.LED NAMESPACE > ---------------------- > > plot(x, y) I like: leds[x,y] = True (or leds[x][y] = True)* but that may be being too clever, perhaps leds.set(x, y, val=True) would be better and/or leds.turn_on(x,y) * Note that this would involve creation of an intermediate column object: col = leds[x] ; col[y] = val > unplot(x, y) As above leds[x,y] = False (or leds[x][y] = False) or leds.set(x, y, False) and/or leds.turn_off(x, y) > point(x, y)->bool val = leds[x,y] or val = leds.get(x,y) > set brightness(value) leds.brightness = value > fade in(ms) leds.fade_in(ms) > fade out(ms) leds.fade_out(ms) > *plot all() > *screenshot->img leds.image > *toggle(x, y) leds.toggle(x,y) ("leds[x,y] ^= True" is being too clever :) ) > *toggle all() leds.toggle_all() > *brightness()->int val = leds.brightness > > > MICROBIT.CONTROL NAMESPACE > -------------------------- > > in background(body) > > > *MICROBIT.EVENTS NAMESPACE > ------------------------- > {possibly limited to bluetooth only, but they do go on the event bus, > so there might still be a way to get these to action even without BT} I don't get what these do, so I'll punt on these for now. > > *remote control(event) > * event=[play,pause,stop,next track, previous track, rewind, volume up, > volume down] > *camera(event) > * event=[take photo, start video capture, stop video capture, toggle > front-rear, > * launch photo mode, launch video mode, stop photo mode, stop video mode] > *alert(event) > * event=[display toast, vibrate, play sound, play ringtone, find my phone, > * alarm 1, alarm 2, alarm 3, alarm 4, alarm 5, alarm 6, > *audio recorder(event) > * event=[launch, start capture, stop capture, stop] > > > *MICROBIT.GAME NAMESPACE > ----------------------- > (a standard library already included in the root namespace) > *add life(lives) game.lives += lives > *add score(points) game.score += points > *current time()->number game.current_time() or game.now() which is concise, but a bit less clear. > *level->number game.level > *level up() game.level += 1 > *life()->number game.lives > *remove life(live) game.lives -= number > *score()->number game.score > *set life(value) game.lives = value > *set score(value) game.score = value > *start countdown(ms) game.start_countdown(ms) > > > MICROBIT.INPUT NAMESPACE > ------------------------ > {note, 'body' is block of code} > > button is pressed(name)->bool buttons.name.is_pressed > on button pressed(body) buttons.name.when_pressed(func) # func can be any callable taking 0 arguments > acceleration(dimension)->number inputs.acceleration (as a vector?) inputs.x_acceleration, etc for components. (read-only property) > compass heading()->number inputs.compass_heading (read-only property) > calibrate() What does this do? Give it a meaningful name. > running time()->number inputs.running_time or just inputs.time (read-only property) The following should all take a callable. > on shake(body) > on fall(body) > on screen up(body) > on screen down(body) > on logo up(body) > on logo down(body) > *pin is pressed(name)->bool pins.name.pressed > *on pin pressed(body) pins.name.when_pressed(func) > Because the event functions take a callable, they can all be used as decorators (probably not for beginners). > > MICROBIT.IMAGE NAMESPACE > ------------------------ > Is there really only one image? Surely we want image objects (which only need one bit per LED so can tiny) and pass those around. > create image img = Image() > img->clear() I would like to make images immutable, like numbers and strings. It seems much more natural that images are immutable, and it is the leds that change. However, it might be frustrating being unable to modify an image without creating a new one. I think it would be good to provide a way to create a new image pictorially: img = Image('''.x.x. ..... ..x.. x...x .xxx.''') Although this isn't very efficient in terms of code size. We could also provide a "library" of images as each individual image is very small: images.letters['c'], images.digits[4], images.happy_face, images.sad_face, images.star, etc. If images are mutable, then the above would need to create a copy of the stored image. > img->set pixel(x,y,value) If images are to be mutable, then is making them indexable too obscure? img[x,y] = value or img.set_pixel(x,y, value=True) > img->pixel(x,y)->bool img[x,y] or img.get_pixel(x,y) > img->show image(x offset) leds.image = img > img->scroll image(x offset per step, interval) leds.scroll(image, step=1, interval=SENSIBLE_DEFAULT) > img->width()->int img.width It might be worth adding some utility methods on Image class, such as rotate_left/right/up/down() and invert() > > > MICROBIT.PINS NAMESPACE > ----------------------- > > analog read pin(name)->number pins.name.analog_value > analog write pin(name, value) pins.name.analog_value = value > digital read pin(name)->number pins.name.digital_value > digital write pin(name, value) pins.name.digital_value = value > -pin is pressed [moved to input namespace] pins.name.is_pressed > -on pin pressed [moved to input namespace] pins.name.when_pressed(func) > > > MICROBIT.MATH NAMESPACE > ----------------------- > We already have the math module for most of these > abs(x)->number The builtin function abs already exists. > clamp(min, max, value)->number Just add this to the math module Use the standard Python implementation of these. > max(x, y)->number > min(x, y)->number > mod(x, y)->number > pow(x, y)->number > random(limit)->number > *sqrt(x)->number > *sign(x)->number > > > > MICROBIT.BITS NAMESPACE > ----------------------- Rather than this namespace, it would be better to add an int32 type to the builtin namespace. In fact, is this necessary at all? Wouldn't int do the job? > add int32 > multiply int32 > subtract int32 > and uint32(x, y)->number > xor uint32(x, y)->number > -not uint32 [removed] > > -create buffer [removed] > -string to buffer [removed] > rotate left uint32(x, bits)->number res = math.rotate_left32(x, bits) > rotate right uint32(x, bits)->number res = math.rotate_right32(x, bits) > shift left uint32(x, bits)->number > shift right uint32(x, bits)->number > > END. > [snip] Cheers, Mark. From david at thinkingbinaries.com Sat Aug 29 20:06:32 2015 From: david at thinkingbinaries.com (David Whale) Date: Sat, 29 Aug 2015 19:06:32 +0100 Subject: [Microbit-Python] A request for help... fancy designing a Pythonic API that up to 1 million kids would use..? In-Reply-To: <55E1EB0E.1050006@hotpy.org> References: <55E07969.5080409@ntoll.org> <55E1954F.4020509@ntoll.org> <55E1EB0E.1050006@hotpy.org> Message-ID: Good stuff Mark! The fonts are already in the C++ code, it would be good to find a way to reuse those and expose them as read only values perhaps, otherwise we'll take a hit on additional flash space to define them all again. I like the added value of rotate and invert etc on an image. This is something I always want to have to do when using the gestures. There was some talk about the screen "auto rotating" but I haven't seen that surface into the languages yet. plot image() takes an inline definition of a pattern (a sort of inline image) in the TD, so it's a way to do things without creating an image object. It might under the bonnet actually create an immutable image, not sure. The animate() function cycles through frames of a wider image (i.e. an image that is 15 pixels wide would have 5 frames and it would animate one complete cycle at the animation period between each frame change). calibrate() calibrate the sensors, it prompts the user to draw a figure of 8 and uses it to calibrate internal scales and offsets I think for the compass at least possibly also the accelerometer depending on the device. int with standard Python rotation and bitwise operators would I think remove the need for all the int32/uint32 stuff. I like the idea of microbit namespace being pre-imported - a recent change to the TD configuration now does this, so that you automatically have the leds, game, pins etc within the default namespace. There used to *also* be a micro:bit namespace but the BBC took that out because it was felt I think that it would be confusing to have two ways of doing the same thing - unfortunately it broke a lot of scripts/tutorials in the process!! All of the events are for the bluetooth link to phone/tablet app, although I don't think bluetooth is on the cards at the moment for Python, due to lack of RAM. I do know that the events in particular can be injected into the eventbus on the micro:bit independent of the bluetooth, so I listed them just in case anyone thought they might be useful - e.g. posting a "camera.take photo" event to the event bus, could send a message over the virtual serial port on the USB connection, and that could trigger some python app on a raspberry pi to take a photo with the pi camera, for example. Just a thought. One other point regarding Nicholas's statement about adding value vs consistency. The standard 5x5 fonts are a real pain with longer messages as they take a long time to scroll and are hard to read. I have a TD library that builds 3x5 fonts (with exception of W and M which are 5x5) and that makes long scrolling messages much more readable. It would be interesting to think about how one might, in Python, provide a user defined font set if they wanted to. Not critical as it could be provided as a user provided library, but it's something I've bumped into regularly with every app I've written so far. Also, there is some evidence, I think, of a possible "get out of jail free" card in how images are coded internally in TD, not sure, but because per-pixel brightness is now supported, images in TD are just strings of 1 and 0 with spaces between them, I'm guessing there might be support one day for using those spaces to insert a brightness hint for each pixel. Brightness is a uint8 (greyscale, or more strictly 'redscale' as the LEDs are red!) See also your notes about treating images like strings - actually in the code generated by all the languages, they *are* strings. e.g. a smiley face followed by a straight face in TD comes out like this when I choose the "print script" option from TD: function main () basic ? plot image("0 0 0 0 0 0 0 0 0 0\n0 1 0 1 0 0 1 0 1 0\n0 0 0 0 0 0 0 0 0 0\n1 0 0 0 1 1 1 1 1 1\n0 1 1 1 0 0 0 0 0 0") end function An image is basically a wide raster with 5 rows. If you have two frames in the image, then the raster is 16 pixels wide. Note the (wasteful) spaces in between each pixel. Hope this helps. David ___________________________________________________________ David Whale, B.Sc (Hons), MIET *Software Engineer and IET Schools Liaison Officer, Essex* email: dwhale at theiet.org twitter: @whaleygeek blog: blog.whaleygeek.co.uk Co-author of the new book "Adventures in Minecraft" - lets get kids coding! On 29 August 2015 at 18:25, Mark Shannon wrote: > Hi, > > Here is my initial suggestion for an API covering all the TD contents as > provided by David. > > As a general comment, I like to suggest that we shouldn't be too afraid to > add things to the builtin namespace. > If every program is going to start with: > import microbit > from microbit import pins > from microbit import leds > from microbit import buttons > from microbit import game > from microbit import inputs > > then we may as well adds those to the builtins namespace. > > So I would suggest that the following objects (which could be modules) are > added to the builtins at startup: > pins, leds, buttons, game, inputs > > I have made fairly extensive use of properties: > img = leds.image ; leds.image = img > rather than img = leds.get_image() ; leds.set_image(img) > > Not only do I think this is a more readable, pythonic interface, > it also prevents the following error, when parentheses are forgotten. > > >>> image = led.get_image > >>> image > > > > > > So, here is a first draft of the API: > > On 29/08/15 13:35, David Whale wrote: > [snip] > >> >> MICROBIT.BASIC NAMESPACE >> ------------------------ >> >> plot image(leds) >> > What does this do? There is no image argument. > To display an image on the leds: > leds.image = img > > show number(value, interval) >> > I'm guessing that this displays a number using the leds. If so, then: > leds.show(number, duration=REASONABLE_DEFAULT) > > show string(text, interval) >> > Same for text? > leds.show(text, duration=REASONABLE_DEFAULT) > > show animation(leds, interval) >> > And again? > leds.show(animation, duration=REASONABLE_DEFAULT) > > clear screen() >> > leds.clear() > > forever(body) >> > I think "while True:" works quite well for this :) > > pause(ms) >> > Seems fine as a function in the builtins namespace. > > >> >> MICROBIT.LED NAMESPACE >> ---------------------- >> >> plot(x, y) >> > I like: leds[x,y] = True (or leds[x][y] = True)* > but that may be being too clever, perhaps > leds.set(x, y, val=True) would be better > and/or > leds.turn_on(x,y) > > * Note that this would involve creation of an intermediate column object: > col = leds[x] ; col[y] = val > > unplot(x, y) >> > As above > leds[x,y] = False (or leds[x][y] = False) > or > leds.set(x, y, False) > and/or > leds.turn_off(x, y) > > point(x, y)->bool >> > val = leds[x,y] > or > val = leds.get(x,y) > > set brightness(value) >> > leds.brightness = value > > fade in(ms) >> > leds.fade_in(ms) > > fade out(ms) >> > leds.fade_out(ms) > > *plot all() >> *screenshot->img >> > leds.image > > *toggle(x, y) >> > leds.toggle(x,y) > ("leds[x,y] ^= True" is being too clever :) ) > > *toggle all() >> > leds.toggle_all() > > *brightness()->int >> > val = leds.brightness > > >> >> MICROBIT.CONTROL NAMESPACE >> -------------------------- >> >> in background(body) >> >> >> *MICROBIT.EVENTS NAMESPACE >> ------------------------- >> {possibly limited to bluetooth only, but they do go on the event bus, >> so there might still be a way to get these to action even without BT} >> > > I don't get what these do, so I'll punt on these for now. > >> >> *remote control(event) >> * event=[play,pause,stop,next track, previous track, rewind, volume up, >> volume down] >> *camera(event) >> * event=[take photo, start video capture, stop video capture, toggle >> front-rear, >> * launch photo mode, launch video mode, stop photo mode, stop video mode] >> *alert(event) >> * event=[display toast, vibrate, play sound, play ringtone, find my >> phone, >> * alarm 1, alarm 2, alarm 3, alarm 4, alarm 5, alarm 6, >> *audio recorder(event) >> * event=[launch, start capture, stop capture, stop] >> >> >> *MICROBIT.GAME NAMESPACE >> ----------------------- >> (a standard library already included in the root namespace) >> *add life(lives) >> > game.lives += lives > >> *add score(points) >> > game.score += points > >> *current time()->number >> > game.current_time() or game.now() which is concise, but a bit less clear. > >> *level->number >> > game.level > >> *level up() >> > game.level += 1 > >> *life()->number >> > game.lives > >> *remove life(live) >> > game.lives -= number > >> *score()->number >> > game.score > >> *set life(value) >> > game.lives = value > >> *set score(value) >> > game.score = value > >> *start countdown(ms) >> > game.start_countdown(ms) > >> >> >> MICROBIT.INPUT NAMESPACE >> ------------------------ >> {note, 'body' is block of code} >> >> button is pressed(name)->bool >> > buttons.name.is_pressed > >> on button pressed(body) >> > buttons.name.when_pressed(func) > # func can be any callable taking 0 arguments > > acceleration(dimension)->number >> > inputs.acceleration (as a vector?) > inputs.x_acceleration, etc for components. > (read-only property) > > compass heading()->number >> > inputs.compass_heading > (read-only property) > > calibrate() >> > What does this do? Give it a meaningful name. > > running time()->number >> > inputs.running_time or just inputs.time > (read-only property) > > The following should all take a callable. > >> on shake(body) >> on fall(body) >> on screen up(body) >> on screen down(body) >> on logo up(body) >> on logo down(body) >> > > *pin is pressed(name)->bool >> > pins.name.pressed > > *on pin pressed(body) >> > pins.name.when_pressed(func) > >> >> > Because the event functions take a callable, they can all be used as > decorators (probably not for beginners). > > >> MICROBIT.IMAGE NAMESPACE >> ------------------------ >> >> Is there really only one image? > Surely we want image objects (which only need one bit per LED so can tiny) > and pass those around. > > create image >> > img = Image() > > img->clear() >> > I would like to make images immutable, like numbers and strings. It seems > much more natural that images are immutable, and it is the leds that change. > However, it might be frustrating being unable to modify an image without > creating a new one. > > I think it would be good to provide a way to create a new image > pictorially: > img = Image('''.x.x. > ..... > ..x.. > x...x > .xxx.''') > Although this isn't very efficient in terms of code size. > > We could also provide a "library" of images as each individual image is > very small: > images.letters['c'], images.digits[4], images.happy_face, images.sad_face, > images.star, etc. > > If images are mutable, then the above would need to create a copy of the > stored image. > > img->set pixel(x,y,value) >> > If images are to be mutable, then is making them indexable too obscure? > img[x,y] = value > or > img.set_pixel(x,y, value=True) > > img->pixel(x,y)->bool >> > img[x,y] > or > img.get_pixel(x,y) > > img->show image(x offset) >> > leds.image = img > > img->scroll image(x offset per step, interval) >> > leds.scroll(image, step=1, interval=SENSIBLE_DEFAULT) > > img->width()->int >> > img.width > > > It might be worth adding some utility methods on Image class, such as > rotate_left/right/up/down() and invert() > > >> >> MICROBIT.PINS NAMESPACE >> ----------------------- >> >> analog read pin(name)->number >> > pins.name.analog_value > > analog write pin(name, value) >> > pins.name.analog_value = value > > digital read pin(name)->number >> > pins.name.digital_value > > digital write pin(name, value) >> > pins.name.digital_value = value > > -pin is pressed [moved to input namespace] >> > pins.name.is_pressed > > -on pin pressed [moved to input namespace] >> > pins.name.when_pressed(func) > > >> >> MICROBIT.MATH NAMESPACE >> ----------------------- >> >> We already have the math module for most of these > > abs(x)->number >> > The builtin function abs already exists. > > clamp(min, max, value)->number >> > Just add this to the math module > > Use the standard Python implementation of these. > >> max(x, y)->number >> min(x, y)->number >> mod(x, y)->number >> pow(x, y)->number >> random(limit)->number >> *sqrt(x)->number >> *sign(x)->number >> >> >> >> MICROBIT.BITS NAMESPACE >> ----------------------- >> > Rather than this namespace, it would be better to > add an int32 type to the builtin namespace. > In fact, is this necessary at all? > Wouldn't int do the job? > > add int32 >> multiply int32 >> subtract int32 >> and uint32(x, y)->number >> xor uint32(x, y)->number >> -not uint32 [removed] >> >> -create buffer [removed] >> -string to buffer [removed] >> > > rotate left uint32(x, bits)->number >> > res = math.rotate_left32(x, bits) > > rotate right uint32(x, bits)->number >> > res = math.rotate_right32(x, bits) > > shift left uint32(x, bits)->number >> shift right uint32(x, bits)->number >> >> END. >> >> [snip] > > Cheers, > Mark. > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at hotpy.org Sat Aug 29 21:23:42 2015 From: mark at hotpy.org (Mark Shannon) Date: Sat, 29 Aug 2015 20:23:42 +0100 Subject: [Microbit-Python] Is there a publicly available Asm/C/C++ API yet? Message-ID: <55E206BE.1020500@hotpy.org> Hi, If we are to design a nice Pythonic API on top of the underlying low-level API it would help to know what that API is. Does one exist yet, ideally on Github or a similar open website? Did I missed an announcement or is it still not public yet? Googling and searching github gives me nothing useful. Cheers, Mark. From david at thinkingbinaries.com Sat Aug 29 22:03:06 2015 From: david at thinkingbinaries.com (David Whale) Date: Sat, 29 Aug 2015 21:03:06 +0100 Subject: [Microbit-Python] Is there a publicly available Asm/C/C++ API yet? In-Reply-To: <55E206BE.1020500@hotpy.org> References: <55E206BE.1020500@hotpy.org> Message-ID: Hi Mark, No, you didn't miss anything, it's just "behind a curtain" at the moment, for the short term at least. Speak to Nicholas - it's accessible to those who need access to it, but it's not in the public domain (yet). So, if you are willing to roll your sleeves up and spec and/or write an amazing API for us, Nicholas can pull the necessary strings to get you access to the information you need to do a great job of it. So, don't let it be a problem - Nicholas can you help here if Mark is willing to jump in and help out? Hint, if you don't already have an account on developer.mbed.org sign up for one now, it'll be quicker to get you access to the key files that way. David ___________________________________________________________ David Whale, B.Sc (Hons), MIET *Software Engineer and IET Schools Liaison Officer, Essex* email: dwhale at theiet.org twitter: @whaleygeek blog: blog.whaleygeek.co.uk Co-author of the new book "Adventures in Minecraft" - lets get kids coding! On 29 August 2015 at 20:23, Mark Shannon wrote: > Hi, > > If we are to design a nice Pythonic API on top of the underlying low-level > API it would help to know what that API is. > > Does one exist yet, ideally on Github or a similar open website? > > Did I missed an announcement or is it still not public yet? > > Googling and searching github gives me nothing useful. > > Cheers, > Mark. > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > -------------- next part -------------- An HTML attachment was scrubbed... URL: