From ntoll at ntoll.org Tue Sep 1 09:27:18 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Tue, 1 Sep 2015 08:27:18 +0100 Subject: [Microbit-Python] JOE / DAMIEN - REQUIRES ACTION Re: Is there a publicly available Asm/C/C++ API yet? In-Reply-To: <55E206BE.1020500@hotpy.org> References: <55E206BE.1020500@hotpy.org> Message-ID: <55E55356.8010004@ntoll.org> On 29/08/15 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? > TL;DR - Joe and Damien, can you please add Mark Shannon (markshannon) to the repos referenced below. Mark, OK... so the DAL has a private repos. I've cc'd Joe F. from Lancaster Uni who has been leading this work. When the device is delivered to schools this code will be open sourced. Damien has a special MicroPython-microbit repos hosting the, er, microbit version of MicroPython (what else?). The instructions for compiling the project etc... are in the README therein. It is the DAL that exposes a C++ API upon which MicroPython will build its "microbit" module. This evening, on the train home from London, I intend listing/documenting its capabilities and posting them onto this list for all to see. > Did I missed an announcement or is it still not public yet? > > Googling and searching github gives me nothing useful. > We're still very much covered by the NDA. Remember, this is more for media management purposes. Everything is "open sourced" when the devices are delivered to schools. Happy to answer questions..! But I suspect things become clearer when you see the code. If anyone else wants access, please shout - you've all signed the NDA so there shouldn't be a problem and we need all the help we can get..! N. > Cheers, > Mark. > _______________________________________________ > 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 j.finney at lancaster.ac.uk Tue Sep 1 11:07:23 2015 From: j.finney at lancaster.ac.uk (Finney, Joe) Date: Tue, 1 Sep 2015 09:07:23 +0000 Subject: [Microbit-Python] JOE / DAMIEN - REQUIRES ACTION Re: Is there a publicly available Asm/C/C++ API yet? In-Reply-To: <55E55356.8010004@ntoll.org> References: <55E206BE.1020500@hotpy.org> <55E55356.8010004@ntoll.org> Message-ID: <052A0FA2625F4047A69AED33E191ACB023B18576@EX-1-MB1.lancs.local> Hi Nicholas, Yes, of course. Can you clarify exactly which repo though? We've moved our active dev tree onto github, and there's a snapshot on mbed.org that we update periodically. So mbed tends to be more stable, and Github tends to be more up to date. Which is best for you guys? It's probably important that you all look at the same one. :-) joe -----Original Message----- From: Nicholas H.Tollervey [mailto:ntoll at ntoll.org] Sent: 01 September 2015 08:27 To: microbit at python.org; Finney, Joe Subject: JOE / DAMIEN - REQUIRES ACTION Re: [Microbit-Python] Is there a publicly available Asm/C/C++ API yet? On 29/08/15 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? > TL;DR - Joe and Damien, can you please add Mark Shannon (markshannon) to the repos referenced below. Mark, OK... so the DAL has a private repos. I've cc'd Joe F. from Lancaster Uni who has been leading this work. When the device is delivered to schools this code will be open sourced. Damien has a special MicroPython-microbit repos hosting the, er, microbit version of MicroPython (what else?). The instructions for compiling the project etc... are in the README therein. It is the DAL that exposes a C++ API upon which MicroPython will build its "microbit" module. This evening, on the train home from London, I intend listing/documenting its capabilities and posting them onto this list for all to see. > Did I missed an announcement or is it still not public yet? > > Googling and searching github gives me nothing useful. > We're still very much covered by the NDA. Remember, this is more for media management purposes. Everything is "open sourced" when the devices are delivered to schools. Happy to answer questions..! But I suspect things become clearer when you see the code. If anyone else wants access, please shout - you've all signed the NDA so there shouldn't be a problem and we need all the help we can get..! N. > Cheers, > Mark. > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit From ntoll at ntoll.org Tue Sep 1 11:39:21 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Tue, 1 Sep 2015 10:39:21 +0100 Subject: [Microbit-Python] JOE / DAMIEN - REQUIRES ACTION Re: Is there a publicly available Asm/C/C++ API yet? In-Reply-To: <052A0FA2625F4047A69AED33E191ACB023B18576@EX-1-MB1.lancs.local> References: <55E206BE.1020500@hotpy.org> <55E55356.8010004@ntoll.org> <052A0FA2625F4047A69AED33E191ACB023B18576@EX-1-MB1.lancs.local> Message-ID: <55E57249.3060609@ntoll.org> Hi Joe, In the yotta.json file the following (GitHub???) repos are referenced: "dependencies":{ "mbed-classic": "~0.0.4", "ble": "lancaster-university/BLE_API#master", "ble-nrf51822": "lancaster-university/nRF51822#master", "microbit-dal":"lancaster-university/microbit-dal#master" }, Does this answer your question? Basically, we're asking for access to the repos that will allow people to build MicroPython (on of which is the microbit-dal we're building our "microbit" module on top of). Regards, N. On 01/09/15 10:07, Finney, Joe wrote: > Hi Nicholas, > > Yes, of course. Can you clarify exactly which repo though? We've > moved our active dev tree onto github, and there's a snapshot on > mbed.org that we update periodically. So mbed tends to be more > stable, and Github tends to be more up to date. > > Which is best for you guys? It's probably important that you all look > at the same one. :-) > > joe > > -----Original Message----- From: Nicholas H.Tollervey > [mailto:ntoll at ntoll.org] Sent: 01 September 2015 08:27 To: > microbit at python.org; Finney, Joe Subject: JOE / DAMIEN - REQUIRES > ACTION Re: [Microbit-Python] Is there a publicly available Asm/C/C++ > API yet? > > On 29/08/15 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? >> > > TL;DR - Joe and Damien, can you please add Mark Shannon (markshannon) > to the repos referenced below. > > Mark, > > OK... so the DAL has a private repos. I've cc'd Joe F. from Lancaster > Uni who has been leading this work. When the device is delivered to > schools this code will be open sourced. > > Damien has a special MicroPython-microbit repos hosting the, er, > microbit version of MicroPython (what else?). The instructions for > compiling the project etc... are in the README therein. > > It is the DAL that exposes a C++ API upon which MicroPython will > build its "microbit" module. This evening, on the train home from > London, I intend listing/documenting its capabilities and posting > them onto this list for all to see. > >> Did I missed an announcement or is it still not public yet? >> >> Googling and searching github gives me nothing useful. >> > > We're still very much covered by the NDA. Remember, this is more for > media management purposes. Everything is "open sourced" when the > devices are delivered to schools. > > Happy to answer questions..! But I suspect things become clearer when > you see the code. > > If anyone else wants access, please shout - you've all signed the NDA > so there shouldn't be a problem and we need all the help we can > get..! > > N. > >> Cheers, Mark. _______________________________________________ >> 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 j.finney at lancaster.ac.uk Tue Sep 1 11:42:36 2015 From: j.finney at lancaster.ac.uk (Finney, Joe) Date: Tue, 1 Sep 2015 09:42:36 +0000 Subject: [Microbit-Python] JOE / DAMIEN - REQUIRES ACTION Re: Is there a publicly available Asm/C/C++ API yet? In-Reply-To: <55E57249.3060609@ntoll.org> References: <55E206BE.1020500@hotpy.org> <55E55356.8010004@ntoll.org> <052A0FA2625F4047A69AED33E191ACB023B18576@EX-1-MB1.lancs.local> <55E57249.3060609@ntoll.org> Message-ID: <052A0FA2625F4047A69AED33E191ACB023B18679@EX-1-MB1.lancs.local> Ah, ok. Looks like you're on the github view. Will get a github invite out to Mark in a mo. joe -----Original Message----- From: Nicholas H.Tollervey [mailto:ntoll at ntoll.org] Sent: 01 September 2015 10:39 To: Finney, Joe; microbit at python.org Subject: Re: JOE / DAMIEN - REQUIRES ACTION Re: [Microbit-Python] Is there a publicly available Asm/C/C++ API yet? Hi Joe, In the yotta.json file the following (GitHub???) repos are referenced: "dependencies":{ "mbed-classic": "~0.0.4", "ble": "lancaster-university/BLE_API#master", "ble-nrf51822": "lancaster-university/nRF51822#master", "microbit-dal":"lancaster-university/microbit-dal#master" }, Does this answer your question? Basically, we're asking for access to the repos that will allow people to build MicroPython (on of which is the microbit-dal we're building our "microbit" module on top of). Regards, N. On 01/09/15 10:07, Finney, Joe wrote: > Hi Nicholas, > > Yes, of course. Can you clarify exactly which repo though? We've moved > our active dev tree onto github, and there's a snapshot on mbed.org > that we update periodically. So mbed tends to be more stable, and > Github tends to be more up to date. > > Which is best for you guys? It's probably important that you all look > at the same one. :-) > > joe > > -----Original Message----- From: Nicholas H.Tollervey > [mailto:ntoll at ntoll.org] Sent: 01 September 2015 08:27 To: > microbit at python.org; Finney, Joe Subject: JOE / DAMIEN - REQUIRES > ACTION Re: [Microbit-Python] Is there a publicly available Asm/C/C++ > API yet? > > On 29/08/15 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? >> > > TL;DR - Joe and Damien, can you please add Mark Shannon (markshannon) > to the repos referenced below. > > Mark, > > OK... so the DAL has a private repos. I've cc'd Joe F. from Lancaster > Uni who has been leading this work. When the device is delivered to > schools this code will be open sourced. > > Damien has a special MicroPython-microbit repos hosting the, er, > microbit version of MicroPython (what else?). The instructions for > compiling the project etc... are in the README therein. > > It is the DAL that exposes a C++ API upon which MicroPython will build > its "microbit" module. This evening, on the train home from London, I > intend listing/documenting its capabilities and posting them onto this > list for all to see. > >> Did I missed an announcement or is it still not public yet? >> >> Googling and searching github gives me nothing useful. >> > > We're still very much covered by the NDA. Remember, this is more for > media management purposes. Everything is "open sourced" when the > devices are delivered to schools. > > Happy to answer questions..! But I suspect things become clearer when > you see the code. > > If anyone else wants access, please shout - you've all signed the NDA > so there shouldn't be a problem and we need all the help we can get..! > > N. > >> Cheers, Mark. _______________________________________________ >> Microbit mailing list Microbit at python.org >> https://mail.python.org/mailman/listinfo/microbit > > From ntoll at ntoll.org Tue Sep 1 11:47:47 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Tue, 1 Sep 2015 10:47:47 +0100 Subject: [Microbit-Python] JOE / DAMIEN - REQUIRES ACTION Re: Is there a publicly available Asm/C/C++ API yet? In-Reply-To: <052A0FA2625F4047A69AED33E191ACB023B18679@EX-1-MB1.lancs.local> References: <55E206BE.1020500@hotpy.org> <55E55356.8010004@ntoll.org> <052A0FA2625F4047A69AED33E191ACB023B18576@EX-1-MB1.lancs.local> <55E57249.3060609@ntoll.org> <052A0FA2625F4047A69AED33E191ACB023B18679@EX-1-MB1.lancs.local> Message-ID: <55E57443.3090105@ntoll.org> Great stuff! N. On 01/09/15 10:42, Finney, Joe wrote: > Ah, ok. Looks like you're on the github view. Will get a github invite out to Mark in a mo. > > joe > > -----Original Message----- > From: Nicholas H.Tollervey [mailto:ntoll at ntoll.org] > Sent: 01 September 2015 10:39 > To: Finney, Joe; microbit at python.org > Subject: Re: JOE / DAMIEN - REQUIRES ACTION Re: [Microbit-Python] Is there a publicly available Asm/C/C++ API yet? > > Hi Joe, > > In the yotta.json file the following (GitHub???) repos are referenced: > > "dependencies":{ > "mbed-classic": "~0.0.4", > "ble": "lancaster-university/BLE_API#master", > "ble-nrf51822": "lancaster-university/nRF51822#master", > "microbit-dal":"lancaster-university/microbit-dal#master" > }, > > Does this answer your question? > > Basically, we're asking for access to the repos that will allow people to build MicroPython (on of which is the microbit-dal we're building our "microbit" module on top of). > > Regards, > > N. > > On 01/09/15 10:07, Finney, Joe wrote: >> Hi Nicholas, >> >> Yes, of course. Can you clarify exactly which repo though? We've moved >> our active dev tree onto github, and there's a snapshot on mbed.org >> that we update periodically. So mbed tends to be more stable, and >> Github tends to be more up to date. >> >> Which is best for you guys? It's probably important that you all look >> at the same one. :-) >> >> joe >> >> -----Original Message----- From: Nicholas H.Tollervey >> [mailto:ntoll at ntoll.org] Sent: 01 September 2015 08:27 To: >> microbit at python.org; Finney, Joe Subject: JOE / DAMIEN - REQUIRES >> ACTION Re: [Microbit-Python] Is there a publicly available Asm/C/C++ >> API yet? >> >> On 29/08/15 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? >>> >> >> TL;DR - Joe and Damien, can you please add Mark Shannon (markshannon) >> to the repos referenced below. >> >> Mark, >> >> OK... so the DAL has a private repos. I've cc'd Joe F. from Lancaster >> Uni who has been leading this work. When the device is delivered to >> schools this code will be open sourced. >> >> Damien has a special MicroPython-microbit repos hosting the, er, >> microbit version of MicroPython (what else?). The instructions for >> compiling the project etc... are in the README therein. >> >> It is the DAL that exposes a C++ API upon which MicroPython will build >> its "microbit" module. This evening, on the train home from London, I >> intend listing/documenting its capabilities and posting them onto this >> list for all to see. >> >>> Did I missed an announcement or is it still not public yet? >>> >>> Googling and searching github gives me nothing useful. >>> >> >> We're still very much covered by the NDA. Remember, this is more for >> media management purposes. Everything is "open sourced" when the >> devices are delivered to schools. >> >> Happy to answer questions..! But I suspect things become clearer when >> you see the code. >> >> If anyone else wants access, please shout - you've all signed the NDA >> so there shouldn't be a problem and we need all the help we can get..! >> >> N. >> >>> Cheers, Mark. _______________________________________________ >>> 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 damien.p.george at gmail.com Tue Sep 1 11:55:44 2015 From: damien.p.george at gmail.com (Damien George) Date: Tue, 1 Sep 2015 10:55:44 +0100 Subject: [Microbit-Python] JOE / DAMIEN - REQUIRES ACTION Re: Is there a publicly available Asm/C/C++ API yet? In-Reply-To: <55E57443.3090105@ntoll.org> References: <55E206BE.1020500@hotpy.org> <55E55356.8010004@ntoll.org> <052A0FA2625F4047A69AED33E191ACB023B18576@EX-1-MB1.lancs.local> <55E57249.3060609@ntoll.org> <052A0FA2625F4047A69AED33E191ACB023B18679@EX-1-MB1.lancs.local> <55E57443.3090105@ntoll.org> Message-ID: markshannon has been added to my private repo. Mark: you have push access (don't know any other way to give you access without full access) but please don't push! Send PRs only. Thanks :) On Tue, Sep 1, 2015 at 10:47 AM, Nicholas H.Tollervey wrote: > Great stuff! > > N. > > On 01/09/15 10:42, Finney, Joe wrote: >> Ah, ok. Looks like you're on the github view. Will get a github invite out to Mark in a mo. >> >> joe >> >> -----Original Message----- >> From: Nicholas H.Tollervey [mailto:ntoll at ntoll.org] >> Sent: 01 September 2015 10:39 >> To: Finney, Joe; microbit at python.org >> Subject: Re: JOE / DAMIEN - REQUIRES ACTION Re: [Microbit-Python] Is there a publicly available Asm/C/C++ API yet? >> >> Hi Joe, >> >> In the yotta.json file the following (GitHub???) repos are referenced: >> >> "dependencies":{ >> "mbed-classic": "~0.0.4", >> "ble": "lancaster-university/BLE_API#master", >> "ble-nrf51822": "lancaster-university/nRF51822#master", >> "microbit-dal":"lancaster-university/microbit-dal#master" >> }, >> >> Does this answer your question? >> >> Basically, we're asking for access to the repos that will allow people to build MicroPython (on of which is the microbit-dal we're building our "microbit" module on top of). >> >> Regards, >> >> N. >> >> On 01/09/15 10:07, Finney, Joe wrote: >>> Hi Nicholas, >>> >>> Yes, of course. Can you clarify exactly which repo though? We've moved >>> our active dev tree onto github, and there's a snapshot on mbed.org >>> that we update periodically. So mbed tends to be more stable, and >>> Github tends to be more up to date. >>> >>> Which is best for you guys? It's probably important that you all look >>> at the same one. :-) >>> >>> joe >>> >>> -----Original Message----- From: Nicholas H.Tollervey >>> [mailto:ntoll at ntoll.org] Sent: 01 September 2015 08:27 To: >>> microbit at python.org; Finney, Joe Subject: JOE / DAMIEN - REQUIRES >>> ACTION Re: [Microbit-Python] Is there a publicly available Asm/C/C++ >>> API yet? >>> >>> On 29/08/15 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? >>>> >>> >>> TL;DR - Joe and Damien, can you please add Mark Shannon (markshannon) >>> to the repos referenced below. >>> >>> Mark, >>> >>> OK... so the DAL has a private repos. I've cc'd Joe F. from Lancaster >>> Uni who has been leading this work. When the device is delivered to >>> schools this code will be open sourced. >>> >>> Damien has a special MicroPython-microbit repos hosting the, er, >>> microbit version of MicroPython (what else?). The instructions for >>> compiling the project etc... are in the README therein. >>> >>> It is the DAL that exposes a C++ API upon which MicroPython will build >>> its "microbit" module. This evening, on the train home from London, I >>> intend listing/documenting its capabilities and posting them onto this >>> list for all to see. >>> >>>> Did I missed an announcement or is it still not public yet? >>>> >>>> Googling and searching github gives me nothing useful. >>>> >>> >>> We're still very much covered by the NDA. Remember, this is more for >>> media management purposes. Everything is "open sourced" when the >>> devices are delivered to schools. >>> >>> Happy to answer questions..! But I suspect things become clearer when >>> you see the code. >>> >>> If anyone else wants access, please shout - you've all signed the NDA >>> so there shouldn't be a problem and we need all the help we can get..! >>> >>> N. >>> >>>> Cheers, Mark. _______________________________________________ >>>> 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 j.finney at lancaster.ac.uk Tue Sep 1 11:57:38 2015 From: j.finney at lancaster.ac.uk (Finney, Joe) Date: Tue, 1 Sep 2015 09:57:38 +0000 Subject: [Microbit-Python] JOE / DAMIEN - REQUIRES ACTION Re: Is there a publicly available Asm/C/C++ API yet? In-Reply-To: References: <55E206BE.1020500@hotpy.org> <55E55356.8010004@ntoll.org> <052A0FA2625F4047A69AED33E191ACB023B18576@EX-1-MB1.lancs.local> <55E57249.3060609@ntoll.org> <052A0FA2625F4047A69AED33E191ACB023B18679@EX-1-MB1.lancs.local> <55E57443.3090105@ntoll.org> Message-ID: <052A0FA2625F4047A69AED33E191ACB023B18799@EX-1-MB1.lancs.local> Folks, Just sent an invite to the micro:bit DAL repo also. I did create a read only group for the same reason as Damien mentioned, so let's see if it works! :-) Mark: let me know if there's an access control problem. joe -----Original Message----- From: Damien George [mailto:damien.p.george at gmail.com] Sent: 01 September 2015 10:56 To: For Pythonic MicroBit related disucssions Cc: Finney, Joe Subject: Re: [Microbit-Python] JOE / DAMIEN - REQUIRES ACTION Re: Is there a publicly available Asm/C/C++ API yet? markshannon has been added to my private repo. Mark: you have push access (don't know any other way to give you access without full access) but please don't push! Send PRs only. Thanks :) On Tue, Sep 1, 2015 at 10:47 AM, Nicholas H.Tollervey wrote: > Great stuff! > > N. > > On 01/09/15 10:42, Finney, Joe wrote: >> Ah, ok. Looks like you're on the github view. Will get a github invite out to Mark in a mo. >> >> joe >> >> -----Original Message----- >> From: Nicholas H.Tollervey [mailto:ntoll at ntoll.org] >> Sent: 01 September 2015 10:39 >> To: Finney, Joe; microbit at python.org >> Subject: Re: JOE / DAMIEN - REQUIRES ACTION Re: [Microbit-Python] Is there a publicly available Asm/C/C++ API yet? >> >> Hi Joe, >> >> In the yotta.json file the following (GitHub???) repos are referenced: >> >> "dependencies":{ >> "mbed-classic": "~0.0.4", >> "ble": "lancaster-university/BLE_API#master", >> "ble-nrf51822": "lancaster-university/nRF51822#master", >> "microbit-dal":"lancaster-university/microbit-dal#master" >> }, >> >> Does this answer your question? >> >> Basically, we're asking for access to the repos that will allow people to build MicroPython (on of which is the microbit-dal we're building our "microbit" module on top of). >> >> Regards, >> >> N. >> >> On 01/09/15 10:07, Finney, Joe wrote: >>> Hi Nicholas, >>> >>> Yes, of course. Can you clarify exactly which repo though? We've moved >>> our active dev tree onto github, and there's a snapshot on mbed.org >>> that we update periodically. So mbed tends to be more stable, and >>> Github tends to be more up to date. >>> >>> Which is best for you guys? It's probably important that you all look >>> at the same one. :-) >>> >>> joe >>> >>> -----Original Message----- From: Nicholas H.Tollervey >>> [mailto:ntoll at ntoll.org] Sent: 01 September 2015 08:27 To: >>> microbit at python.org; Finney, Joe Subject: JOE / DAMIEN - REQUIRES >>> ACTION Re: [Microbit-Python] Is there a publicly available Asm/C/C++ >>> API yet? >>> >>> On 29/08/15 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? >>>> >>> >>> TL;DR - Joe and Damien, can you please add Mark Shannon (markshannon) >>> to the repos referenced below. >>> >>> Mark, >>> >>> OK... so the DAL has a private repos. I've cc'd Joe F. from Lancaster >>> Uni who has been leading this work. When the device is delivered to >>> schools this code will be open sourced. >>> >>> Damien has a special MicroPython-microbit repos hosting the, er, >>> microbit version of MicroPython (what else?). The instructions for >>> compiling the project etc... are in the README therein. >>> >>> It is the DAL that exposes a C++ API upon which MicroPython will build >>> its "microbit" module. This evening, on the train home from London, I >>> intend listing/documenting its capabilities and posting them onto this >>> list for all to see. >>> >>>> Did I missed an announcement or is it still not public yet? >>>> >>>> Googling and searching github gives me nothing useful. >>>> >>> >>> We're still very much covered by the NDA. Remember, this is more for >>> media management purposes. Everything is "open sourced" when the >>> devices are delivered to schools. >>> >>> Happy to answer questions..! But I suspect things become clearer when >>> you see the code. >>> >>> If anyone else wants access, please shout - you've all signed the NDA >>> so there shouldn't be a problem and we need all the help we can get..! >>> >>> N. >>> >>>> Cheers, Mark. _______________________________________________ >>>> 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 damien.p.george at gmail.com Tue Sep 1 12:59:22 2015 From: damien.p.george at gmail.com (Damien George) Date: Tue, 1 Sep 2015 11:59:22 +0100 Subject: [Microbit-Python] JOE / DAMIEN - REQUIRES ACTION Re: Is there a publicly available Asm/C/C++ API yet? In-Reply-To: <052A0FA2625F4047A69AED33E191ACB023B18799@EX-1-MB1.lancs.local> References: <55E206BE.1020500@hotpy.org> <55E55356.8010004@ntoll.org> <052A0FA2625F4047A69AED33E191ACB023B18576@EX-1-MB1.lancs.local> <55E57249.3060609@ntoll.org> <052A0FA2625F4047A69AED33E191ACB023B18679@EX-1-MB1.lancs.local> <55E57443.3090105@ntoll.org> <052A0FA2625F4047A69AED33E191ACB023B18799@EX-1-MB1.lancs.local> Message-ID: Mark: my microbit-micropython repository currently doesn't build because there are issues with the microbit-dal repository and it seems that I'm unable to tell yotta (the build system) to use a specific hash-version of that repo (it uses the latest version which is no longer compatible). I won't be able to fix this for a few days. On Tue, Sep 1, 2015 at 10:57 AM, Finney, Joe wrote: > Folks, > > Just sent an invite to the micro:bit DAL repo also. > > I did create a read only group for the same reason as Damien mentioned, so let's see if it works! :-) > > Mark: let me know if there's an access control problem. > > joe > > -----Original Message----- > From: Damien George [mailto:damien.p.george at gmail.com] > Sent: 01 September 2015 10:56 > To: For Pythonic MicroBit related disucssions > Cc: Finney, Joe > Subject: Re: [Microbit-Python] JOE / DAMIEN - REQUIRES ACTION Re: Is there a publicly available Asm/C/C++ API yet? > > markshannon has been added to my private repo. > > Mark: you have push access (don't know any other way to give you > access without full access) but please don't push! Send PRs only. > Thanks :) > > On Tue, Sep 1, 2015 at 10:47 AM, Nicholas H.Tollervey wrote: >> Great stuff! >> >> N. >> >> On 01/09/15 10:42, Finney, Joe wrote: >>> Ah, ok. Looks like you're on the github view. Will get a github invite out to Mark in a mo. >>> >>> joe >>> >>> -----Original Message----- >>> From: Nicholas H.Tollervey [mailto:ntoll at ntoll.org] >>> Sent: 01 September 2015 10:39 >>> To: Finney, Joe; microbit at python.org >>> Subject: Re: JOE / DAMIEN - REQUIRES ACTION Re: [Microbit-Python] Is there a publicly available Asm/C/C++ API yet? >>> >>> Hi Joe, >>> >>> In the yotta.json file the following (GitHub???) repos are referenced: >>> >>> "dependencies":{ >>> "mbed-classic": "~0.0.4", >>> "ble": "lancaster-university/BLE_API#master", >>> "ble-nrf51822": "lancaster-university/nRF51822#master", >>> "microbit-dal":"lancaster-university/microbit-dal#master" >>> }, >>> >>> Does this answer your question? >>> >>> Basically, we're asking for access to the repos that will allow people to build MicroPython (on of which is the microbit-dal we're building our "microbit" module on top of). >>> >>> Regards, >>> >>> N. >>> >>> On 01/09/15 10:07, Finney, Joe wrote: >>>> Hi Nicholas, >>>> >>>> Yes, of course. Can you clarify exactly which repo though? We've moved >>>> our active dev tree onto github, and there's a snapshot on mbed.org >>>> that we update periodically. So mbed tends to be more stable, and >>>> Github tends to be more up to date. >>>> >>>> Which is best for you guys? It's probably important that you all look >>>> at the same one. :-) >>>> >>>> joe >>>> >>>> -----Original Message----- From: Nicholas H.Tollervey >>>> [mailto:ntoll at ntoll.org] Sent: 01 September 2015 08:27 To: >>>> microbit at python.org; Finney, Joe Subject: JOE / DAMIEN - REQUIRES >>>> ACTION Re: [Microbit-Python] Is there a publicly available Asm/C/C++ >>>> API yet? >>>> >>>> On 29/08/15 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? >>>>> >>>> >>>> TL;DR - Joe and Damien, can you please add Mark Shannon (markshannon) >>>> to the repos referenced below. >>>> >>>> Mark, >>>> >>>> OK... so the DAL has a private repos. I've cc'd Joe F. from Lancaster >>>> Uni who has been leading this work. When the device is delivered to >>>> schools this code will be open sourced. >>>> >>>> Damien has a special MicroPython-microbit repos hosting the, er, >>>> microbit version of MicroPython (what else?). The instructions for >>>> compiling the project etc... are in the README therein. >>>> >>>> It is the DAL that exposes a C++ API upon which MicroPython will build >>>> its "microbit" module. This evening, on the train home from London, I >>>> intend listing/documenting its capabilities and posting them onto this >>>> list for all to see. >>>> >>>>> Did I missed an announcement or is it still not public yet? >>>>> >>>>> Googling and searching github gives me nothing useful. >>>>> >>>> >>>> We're still very much covered by the NDA. Remember, this is more for >>>> media management purposes. Everything is "open sourced" when the >>>> devices are delivered to schools. >>>> >>>> Happy to answer questions..! But I suspect things become clearer when >>>> you see the code. >>>> >>>> If anyone else wants access, please shout - you've all signed the NDA >>>> so there shouldn't be a problem and we need all the help we can get..! >>>> >>>> N. >>>> >>>>> Cheers, Mark. _______________________________________________ >>>>> 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 ntoll at ntoll.org Sun Sep 6 20:53:25 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Sun, 6 Sep 2015 19:53:25 +0100 Subject: [Microbit-Python] MicroPython micro:bit metronome hardware / IO testing Message-ID: <55EC8BA5.2030509@ntoll.org> Hi Folks, Watch this video (Howard, yes, it's private): https://www.youtube.com/watch?v=Ghdt0WMIe3c Basically, Damien has connected up the IO API in the DAL and I spent half an hour this evening testing it with a numpty hardware project (the metronome). As you can see I'm having quite a lot of fun. I've not forgotten about the API work... but I started a new contract last week and that has been taking up a lot of my time. Expect documentation and other things from me over this coming week. Both Damien and I have been making progress in terms of enhancing the capabilities of MicroPython on the micro:bit (e.g. from my perspective, output from help() is meaningful to 11yo kids and there's even an "import this" with appropriate micro-poem, for fun). Finally, both Damien and I will be at PyCon UK and sprinting on the MicroPython / micro:bit work on the Monday. Come join us, you may get a special "gift" to take home with you and/or a chance for some Pythonic posterity. ;-) As always, comments, constructive critique and ideas most welcome! 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 Sun Sep 6 22:43:33 2015 From: david at thinkingbinaries.com (David Whale) Date: Sun, 6 Sep 2015 21:43:33 +0100 Subject: [Microbit-Python] MicroPython micro:bit metronome hardware / IO testing In-Reply-To: <55EC8BA5.2030509@ntoll.org> References: <55EC8BA5.2030509@ntoll.org> Message-ID: Love it! All we need now is a resident editor, and we have a BBC Micro just like the 1980's. No, seriously, I mean this as a good thing - typing interactively is magic, but if you make a typing error, you have to type the whole lot in again (just like with the python shell). A simple resident editor, and you don't need *anything* else to use your microbit! I've always loved the live coding feel of interactive python, interactive lua, interactive ruby, that's why I like those languages so much. (live coding with Python and Minecraft is huge fun by the way) It is so easy to "run a little live experiment" to see how something works, then switch back to your bigger program you are editing and knit it all together into a bigger application. 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 6 September 2015 at 19:53, Nicholas H.Tollervey wrote: > Hi Folks, > > Watch this video (Howard, yes, it's private): > > https://www.youtube.com/watch?v=Ghdt0WMIe3c > > Basically, Damien has connected up the IO API in the DAL and I spent > half an hour this evening testing it with a numpty hardware project (the > metronome). As you can see I'm having quite a lot of fun. > > I've not forgotten about the API work... but I started a new contract > last week and that has been taking up a lot of my time. Expect > documentation and other things from me over this coming week. Both > Damien and I have been making progress in terms of enhancing the > capabilities of MicroPython on the micro:bit (e.g. from my perspective, > output from help() is meaningful to 11yo kids and there's even an > "import this" with appropriate micro-poem, for fun). > > Finally, both Damien and I will be at PyCon UK and sprinting on the > MicroPython / micro:bit work on the Monday. Come join us, you may get a > special "gift" to take home with you and/or a chance for some Pythonic > posterity. ;-) > > As always, comments, constructive critique and ideas most welcome! > > 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 Sun Sep 6 22:47:03 2015 From: damien.p.george at gmail.com (Damien George) Date: Sun, 6 Sep 2015 21:47:03 +0100 Subject: [Microbit-Python] MicroPython micro:bit metronome hardware / IO testing In-Reply-To: References: <55EC8BA5.2030509@ntoll.org> Message-ID: Very cool Nicholas! I agree with David that it's very fragile if you type something wrong in the script (you did very well Nicholas to get it correct first time on camera!). I guess the first thing you'd do would be break the code into simple functions, ones you can test individually. Then it's easy to modify on the fly. BTW, I can add auto-indenting if you think that would be helpful (I think it is). Cheers, Damien. On Sun, Sep 6, 2015 at 9:43 PM, David Whale wrote: > Love it! > > All we need now is a resident editor, and we have a BBC Micro just like the > 1980's. > > No, seriously, I mean this as a good thing - typing interactively is magic, > but if you make a typing error, you have to type the whole lot in again > (just like with the python shell). A simple resident editor, and you don't > need *anything* else to use your microbit! > > I've always loved the live coding feel of interactive python, interactive > lua, interactive ruby, that's why I like those languages so much. (live > coding with Python and Minecraft is huge fun by the way) It is so easy to > "run a little live experiment" to see how something works, then switch back > to your bigger program you are editing and knit it all together into a > bigger application. > > 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 6 September 2015 at 19:53, Nicholas H.Tollervey wrote: >> >> Hi Folks, >> >> Watch this video (Howard, yes, it's private): >> >> https://www.youtube.com/watch?v=Ghdt0WMIe3c >> >> Basically, Damien has connected up the IO API in the DAL and I spent >> half an hour this evening testing it with a numpty hardware project (the >> metronome). As you can see I'm having quite a lot of fun. >> >> I've not forgotten about the API work... but I started a new contract >> last week and that has been taking up a lot of my time. Expect >> documentation and other things from me over this coming week. Both >> Damien and I have been making progress in terms of enhancing the >> capabilities of MicroPython on the micro:bit (e.g. from my perspective, >> output from help() is meaningful to 11yo kids and there's even an >> "import this" with appropriate micro-poem, for fun). >> >> Finally, both Damien and I will be at PyCon UK and sprinting on the >> MicroPython / micro:bit work on the Monday. Come join us, you may get a >> special "gift" to take home with you and/or a chance for some Pythonic >> posterity. ;-) >> >> As always, comments, constructive critique and ideas most welcome! >> >> 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 ntoll at ntoll.org Mon Sep 7 09:31:52 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Mon, 7 Sep 2015 08:31:52 +0100 Subject: [Microbit-Python] MicroPython micro:bit metronome hardware / IO testing In-Reply-To: References: <55EC8BA5.2030509@ntoll.org> Message-ID: <55ED3D68.1040703@ntoll.org> Morning! It's funny that you pick up on the "live coding" aspect of this (rather than the IO hack that I was trying to demo). :-) Totally get the problems with making mistakes and typing in the REPL. Damien, auto-indenting (4 spaces please!) would be very handy. I also agree that splitting things into functions would be the way to go - but I was in a rush. I also think it a "feature" that if you've flashed a script onto the device and you drop into the REPL you'll see all your code is in scope (e.g. dir() will return all the expected things). I believe this is a HUGE win for the purposes of testing and playtime. Anyway, glad you enjoyed it. More stuff coming soon. N. On 06/09/15 21:47, Damien George wrote: > Very cool Nicholas! > > I agree with David that it's very fragile if you type something wrong > in the script (you did very well Nicholas to get it correct first time > on camera!). > > I guess the first thing you'd do would be break the code into simple > functions, ones you can test individually. Then it's easy to modify > on the fly. > > BTW, I can add auto-indenting if you think that would be helpful (I > think it is). > > Cheers, > Damien. > > > On Sun, Sep 6, 2015 at 9:43 PM, David Whale wrote: >> Love it! >> >> All we need now is a resident editor, and we have a BBC Micro just like the >> 1980's. >> >> No, seriously, I mean this as a good thing - typing interactively is magic, >> but if you make a typing error, you have to type the whole lot in again >> (just like with the python shell). A simple resident editor, and you don't >> need *anything* else to use your microbit! >> >> I've always loved the live coding feel of interactive python, interactive >> lua, interactive ruby, that's why I like those languages so much. (live >> coding with Python and Minecraft is huge fun by the way) It is so easy to >> "run a little live experiment" to see how something works, then switch back >> to your bigger program you are editing and knit it all together into a >> bigger application. >> >> 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 6 September 2015 at 19:53, Nicholas H.Tollervey wrote: >>> >>> Hi Folks, >>> >>> Watch this video (Howard, yes, it's private): >>> >>> https://www.youtube.com/watch?v=Ghdt0WMIe3c >>> >>> Basically, Damien has connected up the IO API in the DAL and I spent >>> half an hour this evening testing it with a numpty hardware project (the >>> metronome). As you can see I'm having quite a lot of fun. >>> >>> I've not forgotten about the API work... but I started a new contract >>> last week and that has been taking up a lot of my time. Expect >>> documentation and other things from me over this coming week. Both >>> Damien and I have been making progress in terms of enhancing the >>> capabilities of MicroPython on the micro:bit (e.g. from my perspective, >>> output from help() is meaningful to 11yo kids and there's even an >>> "import this" with appropriate micro-poem, for fun). >>> >>> Finally, both Damien and I will be at PyCon UK and sprinting on the >>> MicroPython / micro:bit work on the Monday. Come join us, you may get a >>> special "gift" to take home with you and/or a chance for some Pythonic >>> posterity. ;-) >>> >>> As always, comments, constructive critique and ideas most welcome! >>> >>> 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 -------------- 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 Mon Sep 7 22:50:57 2015 From: damien.p.george at gmail.com (Damien George) Date: Mon, 7 Sep 2015 21:50:57 +0100 Subject: [Microbit-Python] MicroPython micro:bit metronome hardware / IO testing In-Reply-To: <55ED3D68.1040703@ntoll.org> References: <55EC8BA5.2030509@ntoll.org> <55ED3D68.1040703@ntoll.org> Message-ID: Nicholas: 1. Smart indenting is now implemented (4 spaces, plus backspace over 4 spaces). 2. When a script finishes (either CTRL-C or script just ends) the REPL will have all global objects defined by the script. They will be accessible using dir() and tab completion will pick them up. This is already a standard feature of Python. On Mon, Sep 7, 2015 at 8:31 AM, Nicholas H.Tollervey wrote: > Morning! > > It's funny that you pick up on the "live coding" aspect of this (rather > than the IO hack that I was trying to demo). :-) > > Totally get the problems with making mistakes and typing in the REPL. > Damien, auto-indenting (4 spaces please!) would be very handy. I also > agree that splitting things into functions would be the way to go - but > I was in a rush. > > I also think it a "feature" that if you've flashed a script onto the > device and you drop into the REPL you'll see all your code is in scope > (e.g. dir() will return all the expected things). I believe this is a > HUGE win for the purposes of testing and playtime. > > Anyway, glad you enjoyed it. More stuff coming soon. > > N. > > On 06/09/15 21:47, Damien George wrote: >> Very cool Nicholas! >> >> I agree with David that it's very fragile if you type something wrong >> in the script (you did very well Nicholas to get it correct first time >> on camera!). >> >> I guess the first thing you'd do would be break the code into simple >> functions, ones you can test individually. Then it's easy to modify >> on the fly. >> >> BTW, I can add auto-indenting if you think that would be helpful (I >> think it is). >> >> Cheers, >> Damien. >> >> >> On Sun, Sep 6, 2015 at 9:43 PM, David Whale wrote: >>> Love it! >>> >>> All we need now is a resident editor, and we have a BBC Micro just like the >>> 1980's. >>> >>> No, seriously, I mean this as a good thing - typing interactively is magic, >>> but if you make a typing error, you have to type the whole lot in again >>> (just like with the python shell). A simple resident editor, and you don't >>> need *anything* else to use your microbit! >>> >>> I've always loved the live coding feel of interactive python, interactive >>> lua, interactive ruby, that's why I like those languages so much. (live >>> coding with Python and Minecraft is huge fun by the way) It is so easy to >>> "run a little live experiment" to see how something works, then switch back >>> to your bigger program you are editing and knit it all together into a >>> bigger application. >>> >>> 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 6 September 2015 at 19:53, Nicholas H.Tollervey wrote: >>>> >>>> Hi Folks, >>>> >>>> Watch this video (Howard, yes, it's private): >>>> >>>> https://www.youtube.com/watch?v=Ghdt0WMIe3c >>>> >>>> Basically, Damien has connected up the IO API in the DAL and I spent >>>> half an hour this evening testing it with a numpty hardware project (the >>>> metronome). As you can see I'm having quite a lot of fun. >>>> >>>> I've not forgotten about the API work... but I started a new contract >>>> last week and that has been taking up a lot of my time. Expect >>>> documentation and other things from me over this coming week. Both >>>> Damien and I have been making progress in terms of enhancing the >>>> capabilities of MicroPython on the micro:bit (e.g. from my perspective, >>>> output from help() is meaningful to 11yo kids and there's even an >>>> "import this" with appropriate micro-poem, for fun). >>>> >>>> Finally, both Damien and I will be at PyCon UK and sprinting on the >>>> MicroPython / micro:bit work on the Monday. Come join us, you may get a >>>> special "gift" to take home with you and/or a chance for some Pythonic >>>> posterity. ;-) >>>> >>>> As always, comments, constructive critique and ideas most welcome! >>>> >>>> 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 > From ntoll at ntoll.org Mon Sep 21 09:36:35 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Mon, 21 Sep 2015 08:36:35 +0100 Subject: [Microbit-Python] Sprinting today / Github usernames Message-ID: <55FFB383.9020803@ntoll.org> Hi Folks, Those of you at PyCon UK today for the sprints are WELCOME to join us to hack on MicroPython/micro:bit things. Damien and I worked out a sprint plan yesterday afternoon on the back of the proverbial fag packet. I've asked Joe Finney (from Lancaster University) to add those of you whose GitHub usernames I have to the university's DAL (device abstraction layer) repository on Github. You'll need read access to this in order to compile the version of MicroPython targeting the micro:bit. Joe and James from Lancaster have put a HUGE amount of effort into this layer and one of the tasks we'll be exploring further is how to Pythonically represent their underlying C++ API through the microbit module I demonstrated to the whole conference yesterday in the lightning talks. 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 ntoll at ntoll.org Mon Sep 21 21:58:34 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Mon, 21 Sep 2015 20:58:34 +0100 Subject: [Microbit-Python] Hello new MicroPythonistas Message-ID: <5600616A.2000107@ntoll.org> Hi Folks, Just a quick heads up that we had a marvellous time at PyCon UK for the sprints on MicroPython on the micro:bit. One immediate upshot is that we have several new members (all of whom are covered by the NDA). Once I've caught up with sleep, I'll post a more full summary here for the benefit of all. 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 alainjackson at hotmail.com Tue Sep 22 01:52:45 2015 From: alainjackson at hotmail.com (Alan) Date: Mon, 21 Sep 2015 23:52:45 +0000 Subject: [Microbit-Python] Flat API In-Reply-To: <5600616A.2000107@ntoll.org> References: <5600616A.2000107@ntoll.org> Message-ID: Hi All! I had a great time with all of you at pycon UK and playing with the microbit, thanks! On the way home I was thinking a lot about the API and the REPL and 11 year old kids. I had a bit of a thought that I wanted to try out - don't shout and scream and hiss. I don't know how much you'll like it. Looking at the microbit module there's very few name clashes within it so I wondered what it would be like if there was a version of it that was almost completely flattened. Especially for using with the REPL. Here's my thinking - the hardware isn't going to change (is it?). It's got 20 pins, it's only ever going to have 20 pins, 25 LEDs, 2 buttons etc. So when you're in the REPL, wanting to see immediate results on the hardware itself, and you're in such an small, embedded environment, do you want to type: microbit.pins.pin0.set_digital_value(1) or would you rather type dpin0 = True ? Anyway, as a thought experiment, here's an idea of a flattened API. The attributes with an "=" sign means you can assign to them. ====8<==== Attributes: dpin0 = dpin1 = . . dpin19 = dpin20 = apin0 = apin1 = . . apin19 = apin20 = pins.analog_period = pixel[0,0] = brightness = display_mode = image = button_a button_b force_x #accellerometer.get_x() force_y force_z heading compass_x compass_y compass_z compass.is_calibrated compass.is_calibrating system_time Methods: shift_left() shift_right() shift_up() shift_down() write(...) #display.print(...) scroll(...) animate(...) clear() compass.calibrate() compass.clear_calibration() i2c.read() i2c.write(...) sleep(...) random() reset() panic() ====8<==== My little program that scrolls through a message using the two buttons then becomes: from flat_microbit import * message = "1234567890" index = 0 while True: if button_a: index = (index - 1) % 10 elif button_b: index = (index + 1) % 10 write(message[index]) sleep(50) Cheers, Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From sparks.m at gmail.com Tue Sep 22 02:19:20 2015 From: sparks.m at gmail.com (Michael) Date: Tue, 22 Sep 2015 01:19:20 +0100 Subject: [Microbit-Python] Flat API In-Reply-To: References: <5600616A.2000107@ntoll.org> Message-ID: 2 immediate thoughts: - Firstly I like flat APIs for things, and especially for kids. It's simpler to understand - that why the DAL I designed for the prototype was simple and deliberately eschewed various OO features. - Secondly, the advantage of the DAL though is that it is (or should be) the same across the various platforms/languages. The best analogy I have here is the sockets API. This is the same in C, ruby, python, etc, but often you'll also find a local best practice version, which is often friendlier. That said practicalities here probably decide whether this is good or bad for the production device's DAL. Let's assume that this doesn't have to be either/or. In particular this also means that a child who learns at school they can make something happen like this: microbit.pins.pin0.set_digital_value(1) In one of the other languages can bring that knowledge with them, when they come to python. However, it also means they'd be *delighted* to discover that in python they can do this instead: dpin0 = True ie support them in the transition. As a result, if it's not a choice of either/or, but could do both, I would suggest that this would be a good thing. I don't like the word pythonic personally, because it's often (ab)used to mean "I do/don't like that". In this case though, I think this makes the attributes equivalent to properties, and that I quite like and think is a more python-y way of doing things that having setter/getter functions. I like this, though perhaps call the module/package "mb" instead, so you could do this: mb.dpin0 = True ... so that it's short and sweet to type, but retains the benefit of namespacing. Personally, I have a suspicion that once things become open source, that someone may well do a version 2/3 bit, and so keeping a short/friendly namespace for this is probably a good idea. (This is complete and utter speculation incidentally, but I think reasonable speculation) Regards, Michael. (who needs to set up a build chain and understand how practical/impractical this is) On 22 September 2015 at 00:52, Alan wrote: > > Hi All! > > I had a great time with all of you at pycon UK and playing with the > microbit, thanks! > > On the way home I was thinking a lot about the API and the REPL and 11 > year old kids. I had a bit of a thought that I wanted to try out - don't > shout and scream and hiss. I don't know how much you'll like it. > > Looking at the microbit module there's very few name clashes within it so > I wondered what it would be like if there was a version of it that was > almost completely flattened. Especially for using with the REPL. > > Here's my thinking - the hardware isn't going to change (is it?). It's got > 20 pins, it's only ever going to have 20 pins, 25 LEDs, 2 buttons etc. So > when you're in the REPL, wanting to see immediate results on the hardware > itself, and you're in such an small, embedded environment, do you want to > type: > > microbit.pins.pin0.set_digital_value(1) > > or would you rather type > > dpin0 = True ? > > > Anyway, as a thought experiment, here's an idea of a flattened API. The > attributes with an "=" sign means you can assign to them. > > > ====8<==== > > > > Attributes: > > dpin0 = > dpin1 = > . > . > dpin19 = > dpin20 = > > > apin0 = > apin1 = > . > . > apin19 = > apin20 = > > pins.analog_period = > > pixel[0,0] = > brightness = > display_mode = > image = > > button_a > button_b > > force_x #accellerometer.get_x() > force_y > force_z > > heading > > compass_x > compass_y > compass_z > > compass.is_calibrated > compass.is_calibrating > > system_time > > > Methods: > > shift_left() > shift_right() > shift_up() > shift_down() > > write(...) #display.print(...) > scroll(...) > animate(...) > clear() > > compass.calibrate() > compass.clear_calibration() > > i2c.read() > i2c.write(...) > > sleep(...) > random() > > reset() > panic() > > > > ====8<==== > > My little program that scrolls through a message using the two buttons > then becomes: > > > > from flat_microbit import * > > message = "1234567890" > index = 0 > > while True: > if button_a: > index = (index - 1) % 10 > elif button_b: > index = (index + 1) % 10 > > write(message[index]) > sleep(50) > > > > > Cheers, > > Alan > > > _______________________________________________ > 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 Tue Sep 22 07:37:55 2015 From: david at thinkingbinaries.com (David Whale) Date: Tue, 22 Sep 2015 06:37:55 +0100 Subject: [Microbit-Python] Flat API In-Reply-To: References: <5600616A.2000107@ntoll.org> Message-ID: Hi all (& new contributors) I'd say that both are good, with a proviso.... Please can we settle on a defined core API very soon, as I and my colleagues are already writing resources based on MicroPython on the micro:bit, and it's going to be really painful if things keep changing! Also, we shouldn't force people down an "import microbit" or "from microbit import *" route, we should let people choose. Everyone on my team prefer "from microbit import *" as why would you need a microbit namespace on a microbit, you're sitting in front of the microbit so you know it's one of those already! I agree with Michael - both. But please can someone (Nicholas?) define the core API (basically what we had a week ago that already works!) so we can develop resources against it, and the other innovation around the outside can be added as needed. By define, I mean "write it up in a document, on a github wiki, or whatever, and version it" and also say "this part is the core part and is pretty much fixed and this other stuff here is under discussion and might change". There's not as much time as you think available to us to get this thing finished! Many thanks 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 22 September 2015 at 01:19, Michael wrote: > 2 immediate thoughts: > > - Firstly I like flat APIs for things, and especially for kids. It's > simpler to > understand - that why the DAL I designed for the prototype was > simple and deliberately eschewed various OO features. > > - Secondly, the advantage of the DAL though is that it is (or should > be) the same across the various platforms/languages. The best > analogy I have here is the sockets API. This is the same in C, ruby, > python, etc, but often you'll also find a local best practice version, > which is often friendlier. That said practicalities here probably decide > whether this is good or bad for the production device's DAL. > > Let's assume that this doesn't have to be either/or. > > In particular this also means that a child who learns at school they can > make something happen like this: > > microbit.pins.pin0.set_digital_value(1) > > > In one of the other languages can bring that knowledge with them, > when they come to python. However, it also means they'd be *delighted* > to discover that in python they can do this instead: > > dpin0 = True > > > ie support them in the transition. > > As a result, if it's not a choice of either/or, but could do both, I would > suggest that this would be a good thing. I don't like the word pythonic > personally, because it's often (ab)used to mean "I do/don't like that". > In this case though, I think this makes the attributes equivalent to > properties, and that I quite like and think is a more python-y way of > doing things that having setter/getter functions. > > I like this, though perhaps call the module/package "mb" instead, so > you could do this: > > mb.dpin0 = True > > > ... so that it's short and sweet to type, but retains the benefit of > namespacing. > > > > Personally, I have a suspicion that once things become open source, that > someone may well do a version 2/3 bit, and so keeping a short/friendly > namespace for this is probably a good idea. (This is complete and utter > speculation incidentally, but I think reasonable speculation) > > Regards, > > > Michael. (who needs to set up a build chain and understand how > practical/impractical this is) > > > On 22 September 2015 at 00:52, Alan wrote: > >> >> Hi All! >> >> I had a great time with all of you at pycon UK and playing with the >> microbit, thanks! >> >> On the way home I was thinking a lot about the API and the REPL and 11 >> year old kids. I had a bit of a thought that I wanted to try out - don't >> shout and scream and hiss. I don't know how much you'll like it. >> >> Looking at the microbit module there's very few name clashes within it so >> I wondered what it would be like if there was a version of it that was >> almost completely flattened. Especially for using with the REPL. >> >> Here's my thinking - the hardware isn't going to change (is it?). It's >> got 20 pins, it's only ever going to have 20 pins, 25 LEDs, 2 buttons etc. >> So when you're in the REPL, wanting to see immediate results on the >> hardware itself, and you're in such an small, embedded environment, do you >> want to type: >> >> microbit.pins.pin0.set_digital_value(1) >> >> or would you rather type >> >> dpin0 = True ? >> >> >> Anyway, as a thought experiment, here's an idea of a flattened API. The >> attributes with an "=" sign means you can assign to them. >> >> >> ====8<==== >> >> >> >> Attributes: >> >> dpin0 = >> dpin1 = >> . >> . >> dpin19 = >> dpin20 = >> >> >> apin0 = >> apin1 = >> . >> . >> apin19 = >> apin20 = >> >> pins.analog_period = >> >> pixel[0,0] = >> brightness = >> display_mode = >> image = >> >> button_a >> button_b >> >> force_x #accellerometer.get_x() >> force_y >> force_z >> >> heading >> >> compass_x >> compass_y >> compass_z >> >> compass.is_calibrated >> compass.is_calibrating >> >> system_time >> >> >> Methods: >> >> shift_left() >> shift_right() >> shift_up() >> shift_down() >> >> write(...) #display.print(...) >> scroll(...) >> animate(...) >> clear() >> >> compass.calibrate() >> compass.clear_calibration() >> >> i2c.read() >> i2c.write(...) >> >> sleep(...) >> random() >> >> reset() >> panic() >> >> >> >> ====8<==== >> >> My little program that scrolls through a message using the two buttons >> then becomes: >> >> >> >> from flat_microbit import * >> >> message = "1234567890" >> index = 0 >> >> while True: >> if button_a: >> index = (index - 1) % 10 >> elif button_b: >> index = (index + 1) % 10 >> >> write(message[index]) >> sleep(50) >> >> >> >> >> Cheers, >> >> Alan >> >> >> _______________________________________________ >> 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 tom at viner.tv Tue Sep 22 10:15:29 2015 From: tom at viner.tv (Tom Viner) Date: Tue, 22 Sep 2015 09:15:29 +0100 Subject: [Microbit-Python] Flat API In-Reply-To: References: <5600616A.2000107@ntoll.org> Message-ID: On 22 September 2015 at 06:37, David Whale wrote: > "from microbit import *" I can see the benefit of "from microbit import *" to chop the namespace by one level (and 9 characters per go) since *there is only one module* but since you can't then do microbit. you absolutely need to ensure people have a way of knowing what they just imported. Two possible ways of doing that: - emphasise even further the ability to do dir() to see what's in your namespace. I recommend terminal colouring to highlight the help message at repl start time. - if we're willing to break with normal python: import * could output a help message to stderr listing the names of the items imported. That would be the student friendly approach. Finally, regardless of our preference, some people will indeed use, "from microbit import *" so we must ensure that all microbit.* items don't clash with builtins and - for the future - std library module names. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at thinkingbinaries.com Tue Sep 22 10:48:27 2015 From: david at thinkingbinaries.com (David Whale) Date: Tue, 22 Sep 2015 09:48:27 +0100 Subject: [Microbit-Python] Flat API In-Reply-To: References: <5600616A.2000107@ntoll.org> Message-ID: Yes, I think it already talks about dir() in the help() text - or if it doesn't, I know Nicholas was going to add that along with a possible help(modules), as we were all very keen that a lot of the libraries could be discovered by exploration alone. 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 22 September 2015 at 09:15, Tom Viner wrote: > On 22 September 2015 at 06:37, David Whale > wrote: > >> "from microbit import *" > > > I can see the benefit of "from microbit import *" to chop the namespace by > one level (and 9 characters per go) since *there is only one module* but > since you can't then do microbit. you absolutely need to ensure people > have a way of knowing what they just imported. > > Two possible ways of doing that: > - emphasise even further the ability to do dir() to see what's in your > namespace. I recommend terminal colouring to highlight the help message at > repl start time. > - if we're willing to break with normal python: import * could output a > help message to stderr listing the names of the items imported. That would > be the student friendly approach. > > Finally, regardless of our preference, some people will indeed use, "from > microbit import *" so we must ensure that all microbit.* items don't clash > with builtins and - for the future - std library module names. > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alainjackson at hotmail.com Tue Sep 22 11:35:47 2015 From: alainjackson at hotmail.com (Alan) Date: Tue, 22 Sep 2015 09:35:47 +0000 Subject: [Microbit-Python] Flat API In-Reply-To: References: <5600616A.2000107@ntoll.org>, , Message-ID: Hi, Both the full standard API and the flat one, yes, that's great. I like "mb" as the module name. Cheers, Alan Date: Tue, 22 Sep 2015 01:19:20 +0100 From: sparks.m at gmail.com To: microbit at python.org Subject: Re: [Microbit-Python] Flat API 2 immediate thoughts: - Firstly I like flat APIs for things, and especially for kids. It's simpler to understand - that why the DAL I designed for the prototype was simple and deliberately eschewed various OO features. - Secondly, the advantage of the DAL though is that it is (or should be) the same across the various platforms/languages. The best analogy I have here is the sockets API. This is the same in C, ruby, python, etc, but often you'll also find a local best practice version, which is often friendlier. That said practicalities here probably decide whether this is good or bad for the production device's DAL. Let's assume that this doesn't have to be either/or. In particular this also means that a child who learns at school they canmake something happen like this: microbit.pins.pin0.set_digital_value(1) In one of the other languages can bring that knowledge with them,when they come to python. However, it also means they'd be *delighted*to discover that in python they can do this instead: dpin0 = True ie support them in the transition. As a result, if it's not a choice of either/or, but could do both, I wouldsuggest that this would be a good thing. I don't like the word pythonicpersonally, because it's often (ab)used to mean "I do/don't like that".In this case though, I think this makes the attributes equivalent toproperties, and that I quite like and think is a more python-y way ofdoing things that having setter/getter functions. I like this, though perhaps call the module/package "mb" instead, soyou could do this: mb.dpin0 = True ... so that it's short and sweet to type, but retains the benefit of namespacing. Personally, I have a suspicion that once things become open source, thatsomeone may well do a version 2/3 bit, and so keeping a short/friendlynamespace for this is probably a good idea. (This is complete and utterspeculation incidentally, but I think reasonable speculation) Regards, Michael. (who needs to set up a build chain and understand how practical/impractical this is) On 22 September 2015 at 00:52, Alan wrote: Hi All! I had a great time with all of you at pycon UK and playing with the microbit, thanks! On the way home I was thinking a lot about the API and the REPL and 11 year old kids. I had a bit of a thought that I wanted to try out - don't shout and scream and hiss. I don't know how much you'll like it. Looking at the microbit module there's very few name clashes within it so I wondered what it would be like if there was a version of it that was almost completely flattened. Especially for using with the REPL. Here's my thinking - the hardware isn't going to change (is it?). It's got 20 pins, it's only ever going to have 20 pins, 25 LEDs, 2 buttons etc. So when you're in the REPL, wanting to see immediate results on the hardware itself, and you're in such an small, embedded environment, do you want to type: microbit.pins.pin0.set_digital_value(1) or would you rather type dpin0 = True ? Anyway, as a thought experiment, here's an idea of a flattened API. The attributes with an "=" sign means you can assign to them. ====8<==== Attributes: dpin0 = dpin1 = . . dpin19 = dpin20 = apin0 = apin1 = . . apin19 = apin20 = pins.analog_period = pixel[0,0] = brightness = display_mode = image = button_a button_b force_x #accellerometer.get_x() force_y force_z heading compass_x compass_y compass_z compass.is_calibrated compass.is_calibrating system_time Methods: shift_left() shift_right() shift_up() shift_down() write(...) #display.print(...) scroll(...) animate(...) clear() compass.calibrate() compass.clear_calibration() i2c.read() i2c.write(...) sleep(...) random() reset() panic() ====8<==== My little program that scrolls through a message using the two buttons then becomes: from flat_microbit import * message = "1234567890" index = 0 while True: if button_a: index = (index - 1) % 10 elif button_b: index = (index + 1) % 10 write(message[index]) sleep(50) Cheers, Alan _______________________________________________ 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 Tue Sep 22 11:41:47 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Tue, 22 Sep 2015 10:41:47 +0100 Subject: [Microbit-Python] Flat API In-Reply-To: References: <5600616A.2000107@ntoll.org> Message-ID: <5601225B.4020209@ntoll.org> On 22/09/15 10:35, Alan wrote: > Hi, > > Both the full standard API and the flat one, yes, that's great. I like > "mb" as the module name. > For an API to be child friendly it should be obviously named in a short and simple way. "mb" is not obvious - the use of acronyms is a big no-no (just ask any teacher). :-) 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 sparks.m at gmail.com Tue Sep 22 11:52:17 2015 From: sparks.m at gmail.com (Michael) Date: Tue, 22 Sep 2015 10:52:17 +0100 Subject: [Microbit-Python] Flat API In-Reply-To: <5601225B.4020209@ntoll.org> References: <5600616A.2000107@ntoll.org> <5601225B.4020209@ntoll.org> Message-ID: Not fussy about the name - anything that's clear to children is better than anything that isn't :) Stick with "import microbit" then . You could always have other bits. :) Michael. On 22 September 2015 at 10:41, Nicholas H.Tollervey wrote: > On 22/09/15 10:35, Alan wrote: > > Hi, > > > > Both the full standard API and the flat one, yes, that's great. I like > > "mb" as the module name. > > > > For an API to be child friendly it should be obviously named in a short > and simple way. "mb" is not obvious - the use of acronyms is a big no-no > (just ask any teacher). > > :-) > > N. > > > > _______________________________________________ > 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 Tue Sep 22 12:06:38 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Tue, 22 Sep 2015 11:06:38 +0100 Subject: [Microbit-Python] Flat API In-Reply-To: References: <5600616A.2000107@ntoll.org> <5601225B.4020209@ntoll.org> Message-ID: <5601282E.5080206@ntoll.org> You can always, import microbit as mb That's the beauty of Python - you get a choice. N. On 22/09/15 10:52, Michael wrote: > Not fussy about the name - anything that's clear to children is better > than anything that isn't :) > Stick with "import microbit" then . You could always have other bits. :) > > Michael. > > On 22 September 2015 at 10:41, Nicholas H.Tollervey > wrote: > > On 22/09/15 10:35, Alan wrote: > > Hi, > > > > Both the full standard API and the flat one, yes, that's great. I like > > "mb" as the module name. > > > > For an API to be child friendly it should be obviously named in a short > and simple way. "mb" is not obvious - the use of acronyms is a big no-no > (just ask any teacher). > > :-) > > N. > > > > _______________________________________________ > 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 tom at viner.tv Tue Sep 22 12:46:55 2015 From: tom at viner.tv (Tom Viner) Date: Tue, 22 Sep 2015 11:46:55 +0100 Subject: [Microbit-Python] Flat API In-Reply-To: References: <5600616A.2000107@ntoll.org> Message-ID: On 22 September 2015 at 10:35, Alan wrote: > Both the full standard API and the flat one, yes, that's great. I like > "mb" as the module name. I don't actually think dpin0 = True is pythonic if that does anything other than set (and completely override) a variable value. And I think we agreed yesterday that standard properties were an extra concept to explain, and furthermore not introspectable. So that rules out mb.dpin0 = True too. To avoid confusion with duplicate modules and top level properties, can we agree that the "flat api" is simply "from microbit import *" and that's the way you dump a load of module names into the global namespace. -------------- next part -------------- An HTML attachment was scrubbed... URL: From larry at hastings.org Tue Sep 22 13:09:55 2015 From: larry at hastings.org (Larry Hastings) Date: Tue, 22 Sep 2015 12:09:55 +0100 Subject: [Microbit-Python] Flat API In-Reply-To: References: <5600616A.2000107@ntoll.org> Message-ID: <56013703.80902@hastings.org> On 09/22/2015 01:19 AM, Michael wrote: > > microbit.pins.pin0.set_digital_value(1) > Actually where we left it yesterday, this would be spelled microbit.pins.p0.write_digital(1) > dpin0 = True I don't like this API. First, I don't think the kids are going to make loads of use of the pins. Certainly not on the first day, or I suspect even the first two weeks. They'll play with things that are easy and fun, presumably the two buttons and the display, and start learning programming concepts like variables, functions, and flow control. It's okay if infrequently-used things are slightly longer to spell. Second, I definitely came around on the idea that pins are more like sockets and less like values. Hiding it behind a property is misleading, and as such is a disservice to the user. Third, There Should Be One--And Preferably Only One--Obvious Way To Do It. I'm not supportive of having a second shorter spelling just 'cause it's shorter, and I'm definitely supportive of replacing the API we hammered out yesterday with abrupt names like this. Fourth, as we were admonished yesterday, abbreviations are a no-no. They're confusing for non-native-speakers of English. Fifth, if the user is making frequent use of pin 0, they can make their own abbreviation: import microbit as m def dpin0(x): m.pins.p0.write_digital(x) And thus learn something--and feel clever!--in the process. Good API design is not code golf, trying to find the shortest possible way to spell something. Nor should an API try to be all things to all people. Rather, a good API should be concise without sacrificing readability. I remind you of the old maxim that we spend far more time reading code than we ever spent writing it. That will be especially true of the kids, whose will have much more trouble getting their first programs to work than any of us did. Let's not be PHP, where there's one flat namespace for all functions. But we don't have to be Java either, where four or five dots in a package name is not uncommon. Python frequently inhabits a happy medium, and I think what we had on the board yesterday found this happy medium too. //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sparks.m at gmail.com Tue Sep 22 13:15:26 2015 From: sparks.m at gmail.com (Michael) Date: Tue, 22 Sep 2015 12:15:26 +0100 Subject: [Microbit-Python] Flat API In-Reply-To: References: <5600616A.2000107@ntoll.org> Message-ID: Hm. Good points. I can see the argument for ruling out python properties as well. That said, from a user perspective, I'm not convinced that mb.dpin0 = True (or rather microbit.dpin0 = True) is unclear. [ actually scratch that, writing this has convinced me that any variation on properties is a bad idea, but I'll leave the next bit to explain why I've convinced myself ] After all, we say "this is something that can be set by the microbit runtime, as well as the child" then that approach isn't actually far off how the prototype's DAL actually worked. (For good or ill) In particular this: pixel[0,0] = Which could map to (perhaps): microbit.pixel[0,0] = Is actually really close to this code that was valid C code: void set_point(uint8_t x, uint8_t y, uint8_t state) { if (x <0) return; if (x >DISPLAY_WIDTH-1) return; if (y <0) return; if (y >DISPLAY_HEIGHT -1) return; display[x][y] = state; } (This is a copy and paste of the code that underlined "plot/unplot" in the prototype's DAL :-) ) I mainly mention this because for somethings - like structures - this *might* be a good approach. For example: from microbit import dpins from microbit import apins from microbit import display pin[0] = True reading = apins[0] display[0,0] = 1 I must admit, now I've typed that, I think this approach might actually end up confusing a child. Having everything as an explicit function - though in a flat namespace - is probably better? from microbit import * set_dpin(0, True) set_dpin(0, False) pressed = getButton("A") reading = measure_analog_pin(0) That said, a flat namespace of functions is precisely what the prototype DAL was so, that might be worth a look :-) Michael. On 22 September 2015 at 11:46, Tom Viner wrote: > > On 22 September 2015 at 10:35, Alan wrote: > >> Both the full standard API and the flat one, yes, that's great. I like >> "mb" as the module name. > > > I don't actually think dpin0 = True is pythonic if that does anything > other than set (and completely override) a variable value. And I think we > agreed yesterday that standard properties were an extra concept to explain, > and furthermore not introspectable. So that rules out mb.dpin0 = True too. > > To avoid confusion with duplicate modules and top level properties, can we > agree that the "flat api" is simply "from microbit import *" and that's the > way you dump a load of module names into the global namespace. > > > > _______________________________________________ > 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 Tue Sep 22 13:50:22 2015 From: sparks.m at gmail.com (Michael) Date: Tue, 22 Sep 2015 12:50:22 +0100 Subject: [Microbit-Python] Flat API In-Reply-To: <56013703.80902@hastings.org> References: <5600616A.2000107@ntoll.org> <56013703.80902@hastings.org> Message-ID: Good API design for children though is not the same as good API design for everything. For many children, I expect that this ... microbit.pins.p0.write_digital(x) .. will read as "microbit pins p0 write digital x", and they'd wonder "Why are the words in the wrong order?", which would suggest they would prefer something that reads like "microbit write digital pin 0 x". Whether this is flat, or not, whether the words are separated by "." or _ , is almost irrelevant. To a child, there's NO difference at all. (I know there is in practice, but to them BOTH are just noise, which results in the words being in the wrong order here) It's also worth bearing in mind that at KS3 at school children aren't taught object orientation (it's not in the curriculum), so this could easily be confusing. Especially for a first introduction. To me that almost suggests the opposite of normal: microbit.write_digital_pin_0(ON) That's pretty gratuitious, but inherently *clearer* if you are 11. (just based on working with cubs and scouts, so limited experience, but some) >From an implementation perspective this might may more sense: microbit.write_digital_pin(0, ON) That then has the risk they'll put duff values in for pin numbers though. Now making errors is part of coding, so I'm not averse to it on that basis, but out of these two options, the former increases the chance of success, which I think is a good rationale for a decision. The only other point I'd make is in this thread write/read and set/get have been used, and I'd suggest that one and only one of those gets used. IMO, set/get make more sense: microbit.set_digital_pin_0(ON) Remember, the API isn't designed for developers or teachers, but for 11 year olds - of all abilities - many of whom will have reading and writing difficulties. So while as you say this isn't code golf - trying to find the absolute shortest way of writing something, being brief *if possible* matters. At least 1/2 can't spell well at this age - which probably means auto-completion really matters here. (For me that's also the reason short and sweet is a good idea). It'd probably be useful to capture all this in a document we can all edit/view rather than just in email. Seeing what the suggestions look like is clearer then. Even just a page editted directly on github. (I'm not sure where would be the place where everyone could see - otherwise I'd just create one :-) Michael On 22 September 2015 at 12:09, Larry Hastings wrote: > > > On 09/22/2015 01:19 AM, Michael wrote: > > > microbit.pins.pin0.set_digital_value(1) > > > Actually where we left it yesterday, this would be spelled > > microbit.pins.p0.write_digital(1) > > > dpin0 = True > > > I don't like this API. > > First, I don't think the kids are going to make loads of use of the pins. > Certainly not on the first day, or I suspect even the first two weeks. > They'll play with things that are easy and fun, presumably the two buttons > and the display, and start learning programming concepts like variables, > functions, and flow control. It's okay if infrequently-used things are > slightly longer to spell. > > Second, I definitely came around on the idea that pins are more like > sockets and less like values. Hiding it behind a property is misleading, > and as such is a disservice to the user. > > Third, There Should Be One--And Preferably Only One--Obvious Way To Do > It. I'm not supportive of having a second shorter spelling just 'cause > it's shorter, and I'm definitely supportive of replacing the API we > hammered out yesterday with abrupt names like this. > > Fourth, as we were admonished yesterday, abbreviations are a no-no. > They're confusing for non-native-speakers of English. > > Fifth, if the user is making frequent use of pin 0, they can make their > own abbreviation: > > import microbit as m > def dpin0(x): m.pins.p0.write_digital(x) > > And thus learn something--and feel clever!--in the process. > > > Good API design is not code golf, trying to find the shortest possible way > to spell something. Nor should an API try to be all things to all people. > Rather, a good API should be concise without sacrificing readability. I > remind you of the old maxim that we spend far more time reading code than > we ever spent writing it. That will be especially true of the kids, whose > will have much more trouble getting their first programs to work than any > of us did. > > Let's not be PHP, where there's one flat namespace for all functions. But > we don't have to be Java either, where four or five dots in a package name > is not uncommon. Python frequently inhabits a happy medium, and I think > what we had on the board yesterday found this happy medium too. > > > */arry* > > _______________________________________________ > 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 Tue Sep 22 14:33:15 2015 From: sparks.m at gmail.com (Michael) Date: Tue, 22 Sep 2015 13:33:15 +0100 Subject: [Microbit-Python] Flat API In-Reply-To: References: <5600616A.2000107@ntoll.org> <56013703.80902@hastings.org> Message-ID: In case helpful, I've copied and pasted into a wiki page here: http://www.sparkslabs.com/share/MicrobitAPI username: microbit password: bigbangburgerbar The contents of: microbit-micropython/inc/microbit/qstrdefsport.h Which appears to be where the names for the API are defined. I've also created a couple of placeholders for allowing edits to say "Current API" "XXXX's Proposal" The former is currently empty, and there are a few XXXX's sections - which are currently all empty, except one which copies in Alan's suggestion. (or will have by the time most peole read this) It's a fairly naff wiki, and if there's a single github repo we all have access to, I'd prefer to move the page there. But it's something. This is in part so we can see all of these on one page. Michael. On 22 September 2015 at 12:50, Michael wrote: > Good API design for children though is not the same as good API design for > everything. For many children, I expect that this ... > > microbit.pins.p0.write_digital(x) > > .. will read as "microbit pins p0 write digital x", and they'd wonder > "Why are the words in the wrong order?", which would suggest they would > prefer something that reads like "microbit write digital pin 0 x". > > Whether this is flat, or not, whether the words are separated by "." or _ > , is almost irrelevant. To a child, there's NO difference at all. (I know > there is in practice, but to them BOTH are just noise, which results in the > words being in the wrong order here) > > It's also worth bearing in mind that at KS3 at school children aren't > taught object orientation (it's not in the curriculum), so this could > easily be confusing. Especially for a first introduction. > > To me that almost suggests the opposite of normal: > > microbit.write_digital_pin_0(ON) > > That's pretty gratuitious, but inherently *clearer* if you are 11. (just > based on working with cubs and scouts, so limited experience, but some) > From an implementation perspective this might may more sense: > > microbit.write_digital_pin(0, ON) > > That then has the risk they'll put duff values in for pin numbers though. > Now making errors is part of coding, so I'm not averse to it on that basis, > but out of these two options, the former increases the chance of success, > which I think is a good rationale for a decision. > > The only other point I'd make is in this thread write/read and set/get > have been used, and I'd suggest that one and only one of those gets used. > IMO, set/get make more sense: > > microbit.set_digital_pin_0(ON) > > Remember, the API isn't designed for developers or teachers, but for 11 > year olds - of all abilities - many of whom will have reading and writing > difficulties. So while as you say this isn't code golf - trying to find the > absolute shortest way of writing something, being brief *if possible* > matters. At least 1/2 can't spell well at this age - which probably means > auto-completion really matters here. (For me that's also the reason short > and sweet is a good idea). > > > > It'd probably be useful to capture all this in a document we can all > edit/view rather than just in email. Seeing what the suggestions look like > is clearer then. Even just a page editted directly on github. (I'm not sure > where would be the place where everyone could see - otherwise I'd just > create one :-) > > > Michael > > On 22 September 2015 at 12:09, Larry Hastings wrote: > >> >> >> On 09/22/2015 01:19 AM, Michael wrote: >> >> >> microbit.pins.pin0.set_digital_value(1) >> >> >> Actually where we left it yesterday, this would be spelled >> >> microbit.pins.p0.write_digital(1) >> >> >> dpin0 = True >> >> >> I don't like this API. >> >> First, I don't think the kids are going to make loads of use of the >> pins. Certainly not on the first day, or I suspect even the first two >> weeks. They'll play with things that are easy and fun, presumably the two >> buttons and the display, and start learning programming concepts like >> variables, functions, and flow control. It's okay if infrequently-used >> things are slightly longer to spell. >> >> Second, I definitely came around on the idea that pins are more like >> sockets and less like values. Hiding it behind a property is misleading, >> and as such is a disservice to the user. >> >> Third, There Should Be One--And Preferably Only One--Obvious Way To Do >> It. I'm not supportive of having a second shorter spelling just 'cause >> it's shorter, and I'm definitely supportive of replacing the API we >> hammered out yesterday with abrupt names like this. >> >> Fourth, as we were admonished yesterday, abbreviations are a no-no. >> They're confusing for non-native-speakers of English. >> >> Fifth, if the user is making frequent use of pin 0, they can make their >> own abbreviation: >> >> import microbit as m >> def dpin0(x): m.pins.p0.write_digital(x) >> >> And thus learn something--and feel clever!--in the process. >> >> >> Good API design is not code golf, trying to find the shortest possible >> way to spell something. Nor should an API try to be all things to all >> people. Rather, a good API should be concise without sacrificing >> readability. I remind you of the old maxim that we spend far more time >> reading code than we ever spent writing it. That will be especially true >> of the kids, whose will have much more trouble getting their first programs >> to work than any of us did. >> >> Let's not be PHP, where there's one flat namespace for all functions. >> But we don't have to be Java either, where four or five dots in a package >> name is not uncommon. Python frequently inhabits a happy medium, and I >> think what we had on the board yesterday found this happy medium too. >> >> >> */arry* >> >> _______________________________________________ >> Microbit mailing list >> Microbit at python.org >> https://mail.python.org/mailman/listinfo/microbit >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewelse1997 at gmail.com Tue Sep 22 14:33:44 2015 From: matthewelse1997 at gmail.com (Matthew Else) Date: Tue, 22 Sep 2015 12:33:44 +0000 Subject: [Microbit-Python] Flat API In-Reply-To: References: <5600616A.2000107@ntoll.org> <56013703.80902@hastings.org> Message-ID: If I think back to the time that I first learned to code, which would have been when I was younger than the kids using the micro:bit, I feel like .p0 could feel like some sort of special syntax in the same way that square brackets can seem confusing to kids learning to code. I suppose this goes along with the idea that abbreviations are bad in this context. As a result I feel like even this could reduce confusion, by simply having this: from microbit import pins pins.pin0.digital_write(1) pins.pin0.analog_write(0.5) or pins.pin0.analog_write(128) pins.pin0.digital_write(0) print(pins.pin0.digital_read()) print(pins.pin0.analog_read()) i.e. Having pinX instead of pX. On Tue, Sep 22, 2015 at 12:50 PM Michael wrote: > Good API design for children though is not the same as good API design for > everything. For many children, I expect that this ... > > microbit.pins.p0.write_digital(x) > > .. will read as "microbit pins p0 write digital x", and they'd wonder > "Why are the words in the wrong order?", which would suggest they would > prefer something that reads like "microbit write digital pin 0 x". > > Whether this is flat, or not, whether the words are separated by "." or _ > , is almost irrelevant. To a child, there's NO difference at all. (I know > there is in practice, but to them BOTH are just noise, which results in the > words being in the wrong order here) > > It's also worth bearing in mind that at KS3 at school children aren't > taught object orientation (it's not in the curriculum), so this could > easily be confusing. Especially for a first introduction. > > To me that almost suggests the opposite of normal: > > microbit.write_digital_pin_0(ON) > > That's pretty gratuitious, but inherently *clearer* if you are 11. (just > based on working with cubs and scouts, so limited experience, but some) > From an implementation perspective this might may more sense: > > microbit.write_digital_pin(0, ON) > > That then has the risk they'll put duff values in for pin numbers though. > Now making errors is part of coding, so I'm not averse to it on that basis, > but out of these two options, the former increases the chance of success, > which I think is a good rationale for a decision. > > The only other point I'd make is in this thread write/read and set/get > have been used, and I'd suggest that one and only one of those gets used. > IMO, set/get make more sense: > > microbit.set_digital_pin_0(ON) > > Remember, the API isn't designed for developers or teachers, but for 11 > year olds - of all abilities - many of whom will have reading and writing > difficulties. So while as you say this isn't code golf - trying to find the > absolute shortest way of writing something, being brief *if possible* > matters. At least 1/2 can't spell well at this age - which probably means > auto-completion really matters here. (For me that's also the reason short > and sweet is a good idea). > > > > It'd probably be useful to capture all this in a document we can all > edit/view rather than just in email. Seeing what the suggestions look like > is clearer then. Even just a page editted directly on github. (I'm not sure > where would be the place where everyone could see - otherwise I'd just > create one :-) > > > Michael > > On 22 September 2015 at 12:09, Larry Hastings wrote: > >> >> >> On 09/22/2015 01:19 AM, Michael wrote: >> >> >> microbit.pins.pin0.set_digital_value(1) >> >> >> Actually where we left it yesterday, this would be spelled >> >> microbit.pins.p0.write_digital(1) >> >> >> dpin0 = True >> >> >> I don't like this API. >> >> First, I don't think the kids are going to make loads of use of the >> pins. Certainly not on the first day, or I suspect even the first two >> weeks. They'll play with things that are easy and fun, presumably the two >> buttons and the display, and start learning programming concepts like >> variables, functions, and flow control. It's okay if infrequently-used >> things are slightly longer to spell. >> >> Second, I definitely came around on the idea that pins are more like >> sockets and less like values. Hiding it behind a property is misleading, >> and as such is a disservice to the user. >> >> Third, There Should Be One--And Preferably Only One--Obvious Way To Do >> It. I'm not supportive of having a second shorter spelling just 'cause >> it's shorter, and I'm definitely supportive of replacing the API we >> hammered out yesterday with abrupt names like this. >> >> Fourth, as we were admonished yesterday, abbreviations are a no-no. >> They're confusing for non-native-speakers of English. >> >> Fifth, if the user is making frequent use of pin 0, they can make their >> own abbreviation: >> >> import microbit as m >> def dpin0(x): m.pins.p0.write_digital(x) >> >> And thus learn something--and feel clever!--in the process. >> >> >> Good API design is not code golf, trying to find the shortest possible >> way to spell something. Nor should an API try to be all things to all >> people. Rather, a good API should be concise without sacrificing >> readability. I remind you of the old maxim that we spend far more time >> reading code than we ever spent writing it. That will be especially true >> of the kids, whose will have much more trouble getting their first programs >> to work than any of us did. >> >> Let's not be PHP, where there's one flat namespace for all functions. >> But we don't have to be Java either, where four or five dots in a package >> name is not uncommon. Python frequently inhabits a happy medium, and I >> think what we had on the board yesterday found this happy medium too. >> >> >> */arry* >> >> _______________________________________________ >> 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 Tue Sep 22 14:37:31 2015 From: sparks.m at gmail.com (Michael) Date: Tue, 22 Sep 2015 13:37:31 +0100 Subject: [Microbit-Python] Flat API In-Reply-To: References: <5600616A.2000107@ntoll.org> <56013703.80902@hastings.org> Message-ID: Added to the wiki page :) Michael. On 22 September 2015 at 13:33, Matthew Else wrote: > If I think back to the time that I first learned to code, which would have > been when I was younger than the kids using the micro:bit, I feel like .p0 > could feel like some sort of special syntax in the same way that square > brackets can seem confusing to kids learning to code. I suppose this goes > along with the idea that abbreviations are bad in this context. As a result > I feel like even this could reduce confusion, by simply having this: > > from microbit import pins > > pins.pin0.digital_write(1) > > pins.pin0.analog_write(0.5) or pins.pin0.analog_write(128) > > pins.pin0.digital_write(0) > > print(pins.pin0.digital_read()) > > print(pins.pin0.analog_read()) > > i.e. Having pinX instead of pX. > > On Tue, Sep 22, 2015 at 12:50 PM Michael wrote: > >> Good API design for children though is not the same as good API design >> for everything. For many children, I expect that this ... >> >> microbit.pins.p0.write_digital(x) >> >> .. will read as "microbit pins p0 write digital x", and they'd wonder >> "Why are the words in the wrong order?", which would suggest they would >> prefer something that reads like "microbit write digital pin 0 x". >> >> Whether this is flat, or not, whether the words are separated by "." or _ >> , is almost irrelevant. To a child, there's NO difference at all. (I know >> there is in practice, but to them BOTH are just noise, which results in the >> words being in the wrong order here) >> >> It's also worth bearing in mind that at KS3 at school children aren't >> taught object orientation (it's not in the curriculum), so this could >> easily be confusing. Especially for a first introduction. >> >> To me that almost suggests the opposite of normal: >> >> microbit.write_digital_pin_0(ON) >> >> That's pretty gratuitious, but inherently *clearer* if you are 11. (just >> based on working with cubs and scouts, so limited experience, but some) >> From an implementation perspective this might may more sense: >> >> microbit.write_digital_pin(0, ON) >> >> That then has the risk they'll put duff values in for pin numbers though. >> Now making errors is part of coding, so I'm not averse to it on that basis, >> but out of these two options, the former increases the chance of success, >> which I think is a good rationale for a decision. >> >> The only other point I'd make is in this thread write/read and set/get >> have been used, and I'd suggest that one and only one of those gets used. >> IMO, set/get make more sense: >> >> microbit.set_digital_pin_0(ON) >> >> Remember, the API isn't designed for developers or teachers, but for 11 >> year olds - of all abilities - many of whom will have reading and writing >> difficulties. So while as you say this isn't code golf - trying to find the >> absolute shortest way of writing something, being brief *if possible* >> matters. At least 1/2 can't spell well at this age - which probably means >> auto-completion really matters here. (For me that's also the reason short >> and sweet is a good idea). >> >> >> >> It'd probably be useful to capture all this in a document we can all >> edit/view rather than just in email. Seeing what the suggestions look like >> is clearer then. Even just a page editted directly on github. (I'm not sure >> where would be the place where everyone could see - otherwise I'd just >> create one :-) >> >> >> Michael >> >> On 22 September 2015 at 12:09, Larry Hastings wrote: >> >>> >>> >>> On 09/22/2015 01:19 AM, Michael wrote: >>> >>> >>> microbit.pins.pin0.set_digital_value(1) >>> >>> >>> Actually where we left it yesterday, this would be spelled >>> >>> microbit.pins.p0.write_digital(1) >>> >>> >>> dpin0 = True >>> >>> >>> I don't like this API. >>> >>> First, I don't think the kids are going to make loads of use of the >>> pins. Certainly not on the first day, or I suspect even the first two >>> weeks. They'll play with things that are easy and fun, presumably the two >>> buttons and the display, and start learning programming concepts like >>> variables, functions, and flow control. It's okay if infrequently-used >>> things are slightly longer to spell. >>> >>> Second, I definitely came around on the idea that pins are more like >>> sockets and less like values. Hiding it behind a property is misleading, >>> and as such is a disservice to the user. >>> >>> Third, There Should Be One--And Preferably Only One--Obvious Way To Do >>> It. I'm not supportive of having a second shorter spelling just 'cause >>> it's shorter, and I'm definitely supportive of replacing the API we >>> hammered out yesterday with abrupt names like this. >>> >>> Fourth, as we were admonished yesterday, abbreviations are a no-no. >>> They're confusing for non-native-speakers of English. >>> >>> Fifth, if the user is making frequent use of pin 0, they can make their >>> own abbreviation: >>> >>> import microbit as m >>> def dpin0(x): m.pins.p0.write_digital(x) >>> >>> And thus learn something--and feel clever!--in the process. >>> >>> >>> Good API design is not code golf, trying to find the shortest possible >>> way to spell something. Nor should an API try to be all things to all >>> people. Rather, a good API should be concise without sacrificing >>> readability. I remind you of the old maxim that we spend far more time >>> reading code than we ever spent writing it. That will be especially true >>> of the kids, whose will have much more trouble getting their first programs >>> to work than any of us did. >>> >>> Let's not be PHP, where there's one flat namespace for all functions. >>> But we don't have to be Java either, where four or five dots in a package >>> name is not uncommon. Python frequently inhabits a happy medium, and I >>> think what we had on the board yesterday found this happy medium too. >>> >>> >>> */arry* >>> >>> _______________________________________________ >>> 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 larry at hastings.org Tue Sep 22 14:36:43 2015 From: larry at hastings.org (Larry Hastings) Date: Tue, 22 Sep 2015 13:36:43 +0100 Subject: [Microbit-Python] Flat API In-Reply-To: References: <5600616A.2000107@ntoll.org> <56013703.80902@hastings.org> Message-ID: <56014B5B.40606@hastings.org> On 09/22/2015 12:50 PM, Michael wrote: > For many children, I expect that this ... > > microbit.pins.p0.write_digital(x) > > .. will read as "microbit pins p0 write digital x", and they'd wonder > "Why are the words in the wrong order?", That's good news indeed! Anything that inspires curiosity about programming in children can't be all bad. Perhaps they'll ask their teacher "why are those words in the wrong order?", and the teacher will explain about going from the most general to the most specific, and the child will have learned something. > Good API design for children though is not the same as good API design > for everything Why not? Children want to live in the world of adults. And if we're going to teach them programming, we should start them off with good habits. I find children to be pragmatic--if they want to get something done, you show them how to do it, they use it and move on with their lives. If you say "to check if button a is pressed, use if microbit.buttons.a.is_pressed():", they'll say "okay", not "that's too much to type, I give up on programming forever, just flunk me already". You suggest children have difficulty spelling--true enough, but contorting the API is not the correct response. Instead, how about we enhance upyed's ability to detect errors early? It happily generates firmware files even when the Python has obvious syntax errors. I suppose it's too much to hope for for upyed to sprout enough syntax-coloring smarts to flag misspelled words? In any case, why did we spend all day yesterday arguing about designing a good API, if that's a terrible bad idea and instead we need to design a dumbed-down API that minimizes keystrokes? Rather than speculate about hypothetical 11-year-olds, perhaps we could consult with an actual programming-teacher-of-11-year-olds to gain some hard data. Do we need to minimize keystrokes? Do we need to dumb down the API, or is a level or two of nesting okay? //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sparks.m at gmail.com Tue Sep 22 15:05:15 2015 From: sparks.m at gmail.com (Michael) Date: Tue, 22 Sep 2015 14:05:15 +0100 Subject: [Microbit-Python] Flat API In-Reply-To: <56014B5B.40606@hastings.org> References: <5600616A.2000107@ntoll.org> <56013703.80902@hastings.org> <56014B5B.40606@hastings.org> Message-ID: Hi, Sorry if I've offended you (it looks like I might've done). I couldn't attend yesterday for reasons beyond my control (I don't get to choose what I work on, and had to get back to work :-( ). If I could stayed yesterday I would've raised these comments then. Is there a written description somewhere ? I've not seen it - other than the small comment that's on this thread. FWIW, I'm certain that there are good justifications for every decision taken yesterday, and I'm absolutely sympathetic to what they probably are, but knowing what those justifications are is good. All I've seen so far though is what's been posted to this list. Incidentally, I'm not talking about hypothetical 11 year olds, I work with cubs and scouts and have done for the past 3 years, which isn't a great selection - but it's a representative slice of non-tech focussed kids (boys and girls) - ie the audience this is going to. (I've run simple robot building sessions with these now for around 150 children as well) It's not the same as an actual Y7 teacher, but it's the best I've got... :) I'm certainly not suggesting a dumbed-down API. More one with training wheels still attached :-) Anyway, if anyone has a copy of the current API proposal posting here or on the wiki would be really useful. Any single item out of context probably doesn't paint a complete picture. Michael. On 22 September 2015 at 13:36, Larry Hastings wrote: > > > On 09/22/2015 12:50 PM, Michael wrote: > > For many children, I expect that this ... > > microbit.pins.p0.write_digital(x) > > .. will read as "microbit pins p0 write digital x", and they'd wonder > "Why are the words in the wrong order?", > > > That's good news indeed! Anything that inspires curiosity about > programming in children can't be all bad. Perhaps they'll ask their > teacher "why are those words in the wrong order?", and the teacher will > explain about going from the most general to the most specific, and the > child will have learned something. > > > Good API design for children though is not the same as good API design for > everything > > > Why not? Children want to live in the world of adults. And if we're > going to teach them programming, we should start them off with good habits. > > I find children to be pragmatic--if they want to get something done, you > show them how to do it, they use it and move on with their lives. If you > say "to check if button a is pressed, use if > microbit.buttons.a.is_pressed():", they'll say "okay", not "that's too > much to type, I give up on programming forever, just flunk me already". > > You suggest children have difficulty spelling--true enough, but contorting > the API is not the correct response. Instead, how about we enhance upyed's > ability to detect errors early? It happily generates firmware files even > when the Python has obvious syntax errors. I suppose it's too much to hope > for for upyed to sprout enough syntax-coloring smarts to flag misspelled > words? > > > In any case, why did we spend all day yesterday arguing about designing a > good API, if that's a terrible bad idea and instead we need to design a > dumbed-down API that minimizes keystrokes? > > > Rather than speculate about hypothetical 11-year-olds, perhaps we could > consult with an actual programming-teacher-of-11-year-olds to gain some > hard data. Do we need to minimize keystrokes? Do we need to dumb down the > API, or is a level or two of nesting okay? > > > */arry* > > _______________________________________________ > 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 Tue Sep 22 15:59:09 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Tue, 22 Sep 2015 14:59:09 +0100 Subject: [Microbit-Python] Flat API In-Reply-To: References: <5600616A.2000107@ntoll.org> Message-ID: <56015EAD.2010900@ntoll.org> Hi, WRT API discussions. I have photos of the whiteboard and what we verbally agreed. I'll write up and post later today. N. On 22/09/15 00:52, Alan wrote: > > Hi All! > > I had a great time with all of you at pycon UK and playing with the > microbit, thanks! > > On the way home I was thinking a lot about the API and the REPL and 11 > year old kids. I had a bit of a thought that I wanted to try out - don't > shout and scream and hiss. I don't know how much you'll like it. > > Looking at the microbit module there's very few name clashes within it > so I wondered what it would be like if there was a version of it that > was almost completely flattened. Especially for using with the REPL. > > Here's my thinking - the hardware isn't going to change (is it?). It's > got 20 pins, it's only ever going to have 20 pins, 25 LEDs, 2 buttons > etc. So when you're in the REPL, wanting to see immediate results on the > hardware itself, and you're in such an small, embedded environment, do > you want to type: > > microbit.pins.pin0.set_digital_value(1) > > or would you rather type > > dpin0 = True ? > > > Anyway, as a thought experiment, here's an idea of a flattened API. The > attributes with an "=" sign means you can assign to them. > > > ====8<==== > > > > Attributes: > > dpin0 = > dpin1 = > . > . > dpin19 = > dpin20 = > > > apin0 = > apin1 = > . > . > apin19 = > apin20 = > > pins.analog_period = > > pixel[0,0] = > brightness = > display_mode = > image = > > button_a > button_b > > force_x #accellerometer.get_x() > force_y > force_z > > heading > > compass_x > compass_y > compass_z > > compass.is_calibrated > compass.is_calibrating > > system_time > > > Methods: > > shift_left() > shift_right() > shift_up() > shift_down() > > write(...) #display.print(...) > scroll(...) > animate(...) > clear() > > compass.calibrate() > compass.clear_calibration() > > i2c.read() > i2c.write(...) > > sleep(...) > random() > > reset() > panic() > > > > ====8<==== > > My little program that scrolls through a message using the two buttons > then becomes: > > > > from flat_microbit import * > > message = "1234567890" > index = 0 > > while True: > if button_a: > index = (index - 1) % 10 > elif button_b: > index = (index + 1) % 10 > > write(message[index]) > sleep(50) > > > > > Cheers, > > Alan > > > > _______________________________________________ > 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 damien.p.george at gmail.com Tue Sep 22 16:19:32 2015 From: damien.p.george at gmail.com (Damien George) Date: Tue, 22 Sep 2015 15:19:32 +0100 Subject: [Microbit-Python] Flat API In-Reply-To: <56015EAD.2010900@ntoll.org> References: <5600616A.2000107@ntoll.org> <56015EAD.2010900@ntoll.org> Message-ID: I think what we came up with yesterday (a few levels of nesting, descriptive but not overly verbose methods for everything) is a good compromise and we should stick with it. I think micro:bit code is going to be read *a lot* more than it is written (even more so than normal "adult" code). As such, it's better to have clear and obvious naming. I think kids will spend more time taking existing code and modifying it, rather than writing from scratch. So if they see something like "microbit.pins.p0.write_digital(1)" then it's pretty obvious what they should change to make it pin 1, or make it a 0 output (but could be more obvious if it was pins.pin0). The most important thing (as David said) is that we decide very soon on something, something that's practical and works, so that tutorials and demos can be written. See https://www.microbit.co.uk/td/contents for the Touch Develop API. Some things to note (some of these changed since I last looked): - they have namespaces and some notion of object orientation - they use analog_read_pin, digital_write_pin, etc. - compass_heading is in the same namespace as acceleration (both are accessors) On Tue, Sep 22, 2015 at 2:59 PM, Nicholas H.Tollervey wrote: > Hi, > > WRT API discussions. I have photos of the whiteboard and what we > verbally agreed. > > I'll write up and post later today. > > N. > > On 22/09/15 00:52, Alan wrote: >> >> Hi All! >> >> I had a great time with all of you at pycon UK and playing with the >> microbit, thanks! >> >> On the way home I was thinking a lot about the API and the REPL and 11 >> year old kids. I had a bit of a thought that I wanted to try out - don't >> shout and scream and hiss. I don't know how much you'll like it. >> >> Looking at the microbit module there's very few name clashes within it >> so I wondered what it would be like if there was a version of it that >> was almost completely flattened. Especially for using with the REPL. >> >> Here's my thinking - the hardware isn't going to change (is it?). It's >> got 20 pins, it's only ever going to have 20 pins, 25 LEDs, 2 buttons >> etc. So when you're in the REPL, wanting to see immediate results on the >> hardware itself, and you're in such an small, embedded environment, do >> you want to type: >> >> microbit.pins.pin0.set_digital_value(1) >> >> or would you rather type >> >> dpin0 = True ? >> >> >> Anyway, as a thought experiment, here's an idea of a flattened API. The >> attributes with an "=" sign means you can assign to them. >> >> >> ====8<==== >> >> >> >> Attributes: >> >> dpin0 = >> dpin1 = >> . >> . >> dpin19 = >> dpin20 = >> >> >> apin0 = >> apin1 = >> . >> . >> apin19 = >> apin20 = >> >> pins.analog_period = >> >> pixel[0,0] = >> brightness = >> display_mode = >> image = >> >> button_a >> button_b >> >> force_x #accellerometer.get_x() >> force_y >> force_z >> >> heading >> >> compass_x >> compass_y >> compass_z >> >> compass.is_calibrated >> compass.is_calibrating >> >> system_time >> >> >> Methods: >> >> shift_left() >> shift_right() >> shift_up() >> shift_down() >> >> write(...) #display.print(...) >> scroll(...) >> animate(...) >> clear() >> >> compass.calibrate() >> compass.clear_calibration() >> >> i2c.read() >> i2c.write(...) >> >> sleep(...) >> random() >> >> reset() >> panic() >> >> >> >> ====8<==== >> >> My little program that scrolls through a message using the two buttons >> then becomes: >> >> >> >> from flat_microbit import * >> >> message = "1234567890" >> index = 0 >> >> while True: >> if button_a: >> index = (index - 1) % 10 >> elif button_b: >> index = (index + 1) % 10 >> >> write(message[index]) >> sleep(50) >> >> >> >> >> Cheers, >> >> Alan >> >> >> >> _______________________________________________ >> 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 larry at hastings.org Tue Sep 22 16:49:39 2015 From: larry at hastings.org (Larry Hastings) Date: Tue, 22 Sep 2015 15:49:39 +0100 Subject: [Microbit-Python] Flat API In-Reply-To: References: <5600616A.2000107@ntoll.org> <56013703.80902@hastings.org> <56014B5B.40606@hastings.org> Message-ID: <56016A83.10202@hastings.org> On 09/22/2015 02:05 PM, Michael wrote: > Hi, > > > Sorry if I've offended you (it looks like I might've done). Naah, no worries. And I didn't realize you weren't there yesterday--I didn't get everybody's names. This is private, but I can post this to the list if you like, //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sparks.m at gmail.com Tue Sep 22 16:51:38 2015 From: sparks.m at gmail.com (Michael) Date: Tue, 22 Sep 2015 15:51:38 +0100 Subject: [Microbit-Python] Flat API In-Reply-To: References: <5600616A.2000107@ntoll.org> <56015EAD.2010900@ntoll.org> Message-ID: Hi, I'll refrain from commenting until I see the proposed python API. I do know that while the trial system supported people forking code/making changes, and writing their own, the "fork my version" of this code was a minority use - so the vast majority of code was created from scratch. Whether that's _representative_ , I don't know, but it's a data point. Again, the question I'd have is are we aiming to support all children, or just some. These are just questions though, and I won't make any more comments until I see the proposed API. (Also, I don't claim to be right, and it won't be my decision anyway :) ) Regards, Michael. On 22 September 2015 at 15:19, Damien George wrote: > I think what we came up with yesterday (a few levels of nesting, > descriptive but not overly verbose methods for everything) is a good > compromise and we should stick with it. > > I think micro:bit code is going to be read *a lot* more than it is > written (even more so than normal "adult" code). As such, it's better > to have clear and obvious naming. > > I think kids will spend more time taking existing code and modifying > it, rather than writing from scratch. So if they see something like > "microbit.pins.p0.write_digital(1)" then it's pretty obvious what they > should change to make it pin 1, or make it a 0 output (but could be > more obvious if it was pins.pin0). > > The most important thing (as David said) is that we decide very soon > on something, something that's practical and works, so that tutorials > and demos can be written. > > See https://www.microbit.co.uk/td/contents for the Touch Develop API. > Some things to note (some of these changed since I last looked): > - they have namespaces and some notion of object orientation > - they use analog_read_pin, digital_write_pin, etc. > - compass_heading is in the same namespace as acceleration (both are > accessors) > > > > On Tue, Sep 22, 2015 at 2:59 PM, Nicholas H.Tollervey > wrote: > > Hi, > > > > WRT API discussions. I have photos of the whiteboard and what we > > verbally agreed. > > > > I'll write up and post later today. > > > > N. > > > > On 22/09/15 00:52, Alan wrote: > >> > >> Hi All! > >> > >> I had a great time with all of you at pycon UK and playing with the > >> microbit, thanks! > >> > >> On the way home I was thinking a lot about the API and the REPL and 11 > >> year old kids. I had a bit of a thought that I wanted to try out - don't > >> shout and scream and hiss. I don't know how much you'll like it. > >> > >> Looking at the microbit module there's very few name clashes within it > >> so I wondered what it would be like if there was a version of it that > >> was almost completely flattened. Especially for using with the REPL. > >> > >> Here's my thinking - the hardware isn't going to change (is it?). It's > >> got 20 pins, it's only ever going to have 20 pins, 25 LEDs, 2 buttons > >> etc. So when you're in the REPL, wanting to see immediate results on the > >> hardware itself, and you're in such an small, embedded environment, do > >> you want to type: > >> > >> microbit.pins.pin0.set_digital_value(1) > >> > >> or would you rather type > >> > >> dpin0 = True ? > >> > >> > >> Anyway, as a thought experiment, here's an idea of a flattened API. The > >> attributes with an "=" sign means you can assign to them. > >> > >> > >> ====8<==== > >> > >> > >> > >> Attributes: > >> > >> dpin0 = > >> dpin1 = > >> . > >> . > >> dpin19 = > >> dpin20 = > >> > >> > >> apin0 = > >> apin1 = > >> . > >> . > >> apin19 = > >> apin20 = > >> > >> pins.analog_period = > >> > >> pixel[0,0] = > >> brightness = > >> display_mode = > >> image = > >> > >> button_a > >> button_b > >> > >> force_x #accellerometer.get_x() > >> force_y > >> force_z > >> > >> heading > >> > >> compass_x > >> compass_y > >> compass_z > >> > >> compass.is_calibrated > >> compass.is_calibrating > >> > >> system_time > >> > >> > >> Methods: > >> > >> shift_left() > >> shift_right() > >> shift_up() > >> shift_down() > >> > >> write(...) #display.print(...) > >> scroll(...) > >> animate(...) > >> clear() > >> > >> compass.calibrate() > >> compass.clear_calibration() > >> > >> i2c.read() > >> i2c.write(...) > >> > >> sleep(...) > >> random() > >> > >> reset() > >> panic() > >> > >> > >> > >> ====8<==== > >> > >> My little program that scrolls through a message using the two buttons > >> then becomes: > >> > >> > >> > >> from flat_microbit import * > >> > >> message = "1234567890" > >> index = 0 > >> > >> while True: > >> if button_a: > >> index = (index - 1) % 10 > >> elif button_b: > >> index = (index + 1) % 10 > >> > >> write(message[index]) > >> sleep(50) > >> > >> > >> > >> > >> Cheers, > >> > >> Alan > >> > >> > >> > >> _______________________________________________ > >> 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 Tue Sep 22 17:09:22 2015 From: sparks.m at gmail.com (Michael) Date: Tue, 22 Sep 2015 16:09:22 +0100 Subject: [Microbit-Python] Flat API In-Reply-To: <56016A83.10202@hastings.org> References: <5600616A.2000107@ntoll.org> <56013703.80902@hastings.org> <56014B5B.40606@hastings.org> <56016A83.10202@hastings.org> Message-ID: Cool. I was more worried I'd offended you. Glad I haven't :-) (it's very difficult to tell over email, so try to err on the side of caution!) To explain where I'm coming from perhaps better, I've been hanging out on the computing at school forum now for 2-3 years (or more), and randomly reply to python queries on there, and been rather surprised to see this response sort of response from time to time - either to my replies or to other people's: ... thanks for taking the time to write it. Although the fact that you recommend using functions also reminded me that we are not in the right territory: Functions are outside the scope of OCR GCSE programming, believe it or not (they are present in the AQA specifications though, so maybe I should switch?) (this was in a response to a simple question about validating input data, and simply suggested simple "isint" and "isfloat" functions to avoid repeating the same logic over and over...) That's a little scary to me, and it's always at the back of my mind - because it's a far more common perspective. That comment incidentally is from a teacher who is teaching 14-16 year olds rather than 11-12 year olds. (and yes, there were plenty of other replies from other teachers saying that was the wrong approach) It's interesting actually, if this was an API for CodeClubs (even for the same age range), I wouldn't even have worried at all. Anyway, I'll wait to see the bike now before I start suggesting training wheels or a different colour shed :-) Regards, Michael. On 22 September 2015 at 15:49, Larry Hastings wrote: > > > On 09/22/2015 02:05 PM, Michael wrote: > > Hi, > > > Sorry if I've offended you (it looks like I might've done). > > > > Naah, no worries. And I didn't realize you weren't there yesterday--I > didn't get everybody's names. > > This is private, but I can post this to the list if you like, > > > */arry* > > _______________________________________________ > 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 Tue Sep 22 18:09:03 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Tue, 22 Sep 2015 17:09:03 +0100 Subject: [Microbit-Python] Flat API In-Reply-To: References: <5600616A.2000107@ntoll.org> <56013703.80902@hastings.org> <56014B5B.40606@hastings.org> <56016A83.10202@hastings.org> Message-ID: <56017D1F.5020206@ntoll.org> Some context on examination boards in the UK (the organisations who set the GCSE exams that kids sit at 16). They're conservative, slow moving and I've not been impressed by their computing related offerings (I've worked with a few teachers on example answers to "mock" examination questions). If we work to placate the examination board requirements then we might as well give up. We can (and must) do better than the numpty nonsense I've seen emerge as examination requirements / questions. Who knows? We may actually prompt positive change. N. On 22/09/15 16:09, Michael wrote: > Cool. I was more worried I'd offended you. Glad I haven't :-) > > (it's very difficult to tell over email, so try to err on the side of > caution!) > > To explain where I'm coming from perhaps better, I've been hanging out > on the computing at school forum now for 2-3 years (or more), and > randomly reply to python queries on there, and been rather surprised to > see this response sort of response from time to time - either to my > replies or to other people's: > > ... thanks for taking the time to write it. Although the fact that > you recommend using functions also reminded me that we are not in > the right territory: Functions are outside the scope of OCR GCSE > programming, believe it or not (they are present in the AQA > specifications though, so maybe I should switch?) > > > (this was in a response to a simple question about validating input > data, and simply suggested simple "isint" and "isfloat" functions to > avoid repeating the same logic over and over...) > > That's a little scary to me, and it's always at the back of my mind - > because it's a far more common perspective. That comment incidentally is > from a teacher who is teaching 14-16 year olds rather than 11-12 year > olds. (and yes, there were plenty of other replies from other teachers > saying that was the wrong approach) > > It's interesting actually, if this was an API for CodeClubs (even for > the same age range), I wouldn't even have worried at all. > > Anyway, I'll wait to see the bike now before I start suggesting training > wheels or a different colour shed :-) > > Regards, > > > Michael. > > On 22 September 2015 at 15:49, Larry Hastings > wrote: > > > > On 09/22/2015 02:05 PM, Michael wrote: >> Hi, >> >> >> Sorry if I've offended you (it looks like I might've done). > > > Naah, no worries. And I didn't realize you weren't there > yesterday--I didn't get everybody's names. > > This is private, but I can post this to the list if you like, > > > //arry/ > > _______________________________________________ > 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 ben at raspberrypi.org Tue Sep 22 18:46:46 2015 From: ben at raspberrypi.org (Ben Nuttall) Date: Tue, 22 Sep 2015 17:46:46 +0100 Subject: [Microbit-Python] Flat API In-Reply-To: References: <5600616A.2000107@ntoll.org> <56013703.80902@hastings.org> <56014B5B.40606@hastings.org> <56016A83.10202@hastings.org> Message-ID: +1 Ben --- Ben Nuttall Education Developer Advocate Raspberry Pi Foundation www.raspberrypi.org UK registered charity 1129409 On 22 September 2015 at 17:09, Nicholas H.Tollervey wrote: > Some context on examination boards in the UK (the organisations who set > the GCSE exams that kids sit at 16). > > They're conservative, slow moving and I've not been impressed by their > computing related offerings (I've worked with a few teachers on example > answers to "mock" examination questions). > > If we work to placate the examination board requirements then we might > as well give up. We can (and must) do better than the numpty nonsense > I've seen emerge as examination requirements / questions. > > Who knows? We may actually prompt positive change. > > N. > > On 22/09/15 16:09, Michael wrote: > > Cool. I was more worried I'd offended you. Glad I haven't :-) > > > > (it's very difficult to tell over email, so try to err on the side of > > caution!) > > > > To explain where I'm coming from perhaps better, I've been hanging out > > on the computing at school forum now for 2-3 years (or more), and > > randomly reply to python queries on there, and been rather surprised to > > see this response sort of response from time to time - either to my > > replies or to other people's: > > > > ... thanks for taking the time to write it. Although the fact that > > you recommend using functions also reminded me that we are not in > > the right territory: Functions are outside the scope of OCR GCSE > > programming, believe it or not (they are present in the AQA > > specifications though, so maybe I should switch?) > > > > > > (this was in a response to a simple question about validating input > > data, and simply suggested simple "isint" and "isfloat" functions to > > avoid repeating the same logic over and over...) > > > > That's a little scary to me, and it's always at the back of my mind - > > because it's a far more common perspective. That comment incidentally is > > from a teacher who is teaching 14-16 year olds rather than 11-12 year > > olds. (and yes, there were plenty of other replies from other teachers > > saying that was the wrong approach) > > > > It's interesting actually, if this was an API for CodeClubs (even for > > the same age range), I wouldn't even have worried at all. > > > > Anyway, I'll wait to see the bike now before I start suggesting training > > wheels or a different colour shed :-) > > > > Regards, > > > > > > Michael. > > > > On 22 September 2015 at 15:49, Larry Hastings > > wrote: > > > > > > > > On 09/22/2015 02:05 PM, Michael wrote: > >> Hi, > >> > >> > >> Sorry if I've offended you (it looks like I might've done). > > > > > > Naah, no worries. And I didn't realize you weren't there > > yesterday--I didn't get everybody's names. > > > > This is private, but I can post this to the list if you like, > > > > > > //arry/ > > > > _______________________________________________ > > 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 Tue Sep 22 20:48:46 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Tue, 22 Sep 2015 19:48:46 +0100 Subject: [Microbit-Python] Videos from yesterday Message-ID: <5601A28E.7090408@ntoll.org> Hi Folks, Some fun videos shot yesterday - I think they capture the fun we had playing with the device. https://www.youtube.com/watch?v=rhF3FKQhfNw https://www.youtube.com/watch?v=qxm0PNNL0NA https://www.youtube.com/watch?v=PZ8t1sMwlE0 https://www.youtube.com/watch?v=KwTE8Jkq7X4 https://www.youtube.com/watch?v=OMM2dU-isNc https://www.youtube.com/watch?v=10tAh1qGGUA https://www.youtube.com/watch?v=aR9s7Y1j9Sw https://www.youtube.com/watch?v=J0jdFO1glLw NOTE: These are UNLISTED so please don't share... blah blah blah NDA blah blah blah. :-/ I'm going to be at the BBC on Thursday and will try to get some sort of a more relaxed position from the BBC about making this sort of thing public. Enjoy... :-) 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 Sep 22 21:44:07 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Tue, 22 Sep 2015 20:44:07 +0100 Subject: [Microbit-Python] API design heuristics from PyCon UK Message-ID: <5601AF87.9000600@ntoll.org> Hi Folks, So, I'd like to call a halt on the bike-shedding. :-) I believe we had reached a consensus yesterday and I've added photos of the final state of the white-board and summarised our discussion in the following pull request: https://github.com/dpgeorge/microbit-micropython/pull/24 Please, while everyone loves discussing API design, we need to finalise things because various people are relying on us to have something that DOES NOT CHANGE in some fundamental way. For example, David Whale (also on this list) from the IEE needs to be sure we're not pulling the rug from underneath him and his micro:bit/MicroPython work. I also want to add collaborators soon who will be creating further educational resources. So, PLEASE CHECK THE PR and feel free to propose changes to my branch. These changes should only be corrections - NO NEW SUGGESTIONS for flat APIs or other funky stuff. ;-) We need to be pragmatic, practical and focussed on kids. That means simple, obvious and easy to use. I also like Larry's concern for consistency and facilitating the formation of good habits. KISS with a dash of wisdom is the order of the day. ;-) Damien, can you leave the PR open for just the next 24 hours so people have a chance to correct my fumbles and poor memory? (See my "here be dragons" section.) In 24 hours time I want us to be able to start working on this. I certainly want to get the built-in help started soon and definitely don't want to keep changing it..! As always, comments, constructive critique and ideas are most welcome. Yay! All the best, 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 maria.korolyuk at gmail.com Tue Sep 22 23:17:58 2015 From: maria.korolyuk at gmail.com (Mariia Koroliuk) Date: Tue, 22 Sep 2015 22:17:58 +0100 Subject: [Microbit-Python] some questions (and where should I ask them normally?) Message-ID: Hello, I hope this is a right way to ask :) Please tell me how to do it properly! Is there come conversation somewhere with general queries? 1) How does the creating new Image work? For example, I want to define CHESS='1,0,1,0,1 \n 0,1,0,1,0 \n 1,0,1,0,1 \n 0,1,0,1,0 \n 1,0,1,0,1 ' (I think this is the form was discussed?) For builded images, it would be microbit.display.print(microbit.Image.YES) But then I would try microbit.display.print(CHESS) which obviously print it as a string :) I tried to do something like microbit.Image.CHESS='1,0,1,0,1 \n 0,1,0,1,0 \n 1,0,1,0,1 \n 0,1,0,1,0 \n 1,0,1,0,1 ' which doesn't work too :( (I can print it in the loop through microbit.display.image.set_pixel_value but it is quite stupid) I guess it would be nice for kids to have an option to print an image they define. 2) How do I control the brightness of one pixel? Something like microbit.display.set_brightness (3,3,200)? -------------- next part -------------- An HTML attachment was scrubbed... URL: From larry at hastings.org Tue Sep 22 23:29:26 2015 From: larry at hastings.org (Larry Hastings) Date: Tue, 22 Sep 2015 22:29:26 +0100 Subject: [Microbit-Python] some questions (and where should I ask them normally?) In-Reply-To: References: Message-ID: <5601C836.4020604@hastings.org> On 09/22/2015 10:17 PM, Mariia Koroliuk wrote: > Hello, > > I hope this is a right way to ask :) Please tell me how to do it > properly! Is there come conversation somewhere with general queries? > > 1) How does the creating new Image work? For example, I want to define > > CHESS='1,0,1,0,1 \n 0,1,0,1,0 \n 1,0,1,0,1 \n 0,1,0,1,0 \n 1,0,1,0,1 ' > (I think this is the form was discussed?) I believe that's the initializer for the constructor. You need to make an Image object. chess = microbit.Image(CHESS) microbit.display.print(chess) Image might be inside microbit.display, I'm not sure. > 2) How do I control the brightness of one pixel? Something like > > microbit.display.set_brightness (3,3,200)? > The LEDs are either on or off. No brightness control. //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewelse1997 at gmail.com Tue Sep 22 23:31:25 2015 From: matthewelse1997 at gmail.com (Matthew Else) Date: Tue, 22 Sep 2015 21:31:25 +0000 Subject: [Microbit-Python] some questions (and where should I ask them normally?) In-Reply-To: <5601C836.4020604@hastings.org> References: <5601C836.4020604@hastings.org> Message-ID: There is a way of doing set_brightness (greyscale), however I'm not entirely clear about how you would do it :p On Tue, Sep 22, 2015 at 10:29 PM Larry Hastings wrote: > > > On 09/22/2015 10:17 PM, Mariia Koroliuk wrote: > > Hello, > > I hope this is a right way to ask :) Please tell me how to do it properly! > Is there come conversation somewhere with general queries? > > 1) How does the creating new Image work? For example, I want to define > > CHESS='1,0,1,0,1 \n 0,1,0,1,0 \n 1,0,1,0,1 \n 0,1,0,1,0 \n 1,0,1,0,1 ' (I > think this is the form was discussed?) > > > I believe that's the initializer for the constructor. You need to make an > Image object. > chess = microbit.Image(CHESS) > microbit.display.print(chess) > > Image might be inside microbit.display, I'm not sure. > > > > 2) How do I control the brightness of one pixel? Something like > > microbit.display.set_brightness (3,3,200)? > > > The LEDs are either on or off. No brightness control. > > > */arry* > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewelse1997 at gmail.com Tue Sep 22 23:33:12 2015 From: matthewelse1997 at gmail.com (Matthew Else) Date: Tue, 22 Sep 2015 21:33:12 +0000 Subject: [Microbit-Python] some questions (and where should I ask them normally?) In-Reply-To: References: <5601C836.4020604@hastings.org> Message-ID: You need to do image.set_pixel_value(x, y, (value from 0 to 255)) On Tue, Sep 22, 2015 at 10:31 PM Matthew Else wrote: > There is a way of doing set_brightness (greyscale), however I'm not > entirely clear about how you would do it :p > > On Tue, Sep 22, 2015 at 10:29 PM Larry Hastings > wrote: > >> >> >> On 09/22/2015 10:17 PM, Mariia Koroliuk wrote: >> >> Hello, >> >> I hope this is a right way to ask :) Please tell me how to do it >> properly! Is there come conversation somewhere with general queries? >> >> 1) How does the creating new Image work? For example, I want to define >> >> CHESS='1,0,1,0,1 \n 0,1,0,1,0 \n 1,0,1,0,1 \n 0,1,0,1,0 \n 1,0,1,0,1 ' >> (I think this is the form was discussed?) >> >> >> I believe that's the initializer for the constructor. You need to make >> an Image object. >> chess = microbit.Image(CHESS) >> microbit.display.print(chess) >> >> Image might be inside microbit.display, I'm not sure. >> >> >> >> 2) How do I control the brightness of one pixel? Something like >> >> microbit.display.set_brightness (3,3,200)? >> >> >> The LEDs are either on or off. No brightness control. >> >> >> */arry* >> _______________________________________________ >> 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 Tue Sep 22 23:50:43 2015 From: damien.p.george at gmail.com (Damien George) Date: Tue, 22 Sep 2015 22:50:43 +0100 Subject: [Microbit-Python] some questions (and where should I ask them normally?) In-Reply-To: References: <5601C836.4020604@hastings.org> Message-ID: Yes, this is the right channel for questions and discussion. Larry is correct: you construct an image using img = microbit.Image('0,1,0,0,0\n...') then use it: microbit.display.print(img) To use the greyscale feature you need to first do: microbit.display.set_display_mode(1) (Yes that's obscure, it needs a nicer way to do it!) On Tue, Sep 22, 2015 at 10:33 PM, Matthew Else wrote: > You need to do image.set_pixel_value(x, y, (value from 0 to 255)) > > On Tue, Sep 22, 2015 at 10:31 PM Matthew Else > wrote: >> >> There is a way of doing set_brightness (greyscale), however I'm not >> entirely clear about how you would do it :p >> >> On Tue, Sep 22, 2015 at 10:29 PM Larry Hastings >> wrote: >>> >>> >>> >>> On 09/22/2015 10:17 PM, Mariia Koroliuk wrote: >>> >>> Hello, >>> >>> I hope this is a right way to ask :) Please tell me how to do it >>> properly! Is there come conversation somewhere with general queries? >>> >>> 1) How does the creating new Image work? For example, I want to define >>> >>> CHESS='1,0,1,0,1 \n 0,1,0,1,0 \n 1,0,1,0,1 \n 0,1,0,1,0 \n 1,0,1,0,1 ' >>> (I think this is the form was discussed?) >>> >>> >>> I believe that's the initializer for the constructor. You need to make >>> an Image object. >>> chess = microbit.Image(CHESS) >>> microbit.display.print(chess) >>> >>> Image might be inside microbit.display, I'm not sure. >>> >>> >>> >>> 2) How do I control the brightness of one pixel? Something like >>> >>> microbit.display.set_brightness (3,3,200)? >>> >>> >>> The LEDs are either on or off. No brightness control. >>> >>> >>> /arry >>> _______________________________________________ >>> 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 tom at viner.tv Tue Sep 22 23:58:40 2015 From: tom at viner.tv (Tom Viner) Date: Tue, 22 Sep 2015 22:58:40 +0100 Subject: [Microbit-Python] Videos from yesterday In-Reply-To: <5601A28E.7090408@ntoll.org> References: <5601A28E.7090408@ntoll.org> Message-ID: great fun, thanks for sharing (this far and no further)! good luck at the BBC On 22 September 2015 at 19:48, Nicholas H.Tollervey wrote: > Hi Folks, > > Some fun videos shot yesterday - I think they capture the fun we had > playing with the device. > > https://www.youtube.com/watch?v=rhF3FKQhfNw > https://www.youtube.com/watch?v=qxm0PNNL0NA > https://www.youtube.com/watch?v=PZ8t1sMwlE0 > https://www.youtube.com/watch?v=KwTE8Jkq7X4 > https://www.youtube.com/watch?v=OMM2dU-isNc > https://www.youtube.com/watch?v=10tAh1qGGUA > https://www.youtube.com/watch?v=aR9s7Y1j9Sw > https://www.youtube.com/watch?v=J0jdFO1glLw > > NOTE: These are UNLISTED so please don't share... blah blah blah NDA > blah blah blah. :-/ > > I'm going to be at the BBC on Thursday and will try to get some sort of > a more relaxed position from the BBC about making this sort of thing > public. > > Enjoy... > > :-) > > N. > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maria.korolyuk at gmail.com Wed Sep 23 00:00:28 2015 From: maria.korolyuk at gmail.com (Mariia Koroliuk) Date: Tue, 22 Sep 2015 23:00:28 +0100 Subject: [Microbit-Python] some questions (and where should I ask them normally?) In-Reply-To: References: <5601C836.4020604@hastings.org> Message-ID: Thanks :) I mean if I need a different brightness for different pixels? is it possible? On 22 September 2015 at 22:50, Damien George wrote: > Yes, this is the right channel for questions and discussion. > > Larry is correct: you construct an image using > > img = microbit.Image('0,1,0,0,0\n...') > > then use it: > > microbit.display.print(img) > > To use the greyscale feature you need to first do: > > microbit.display.set_display_mode(1) > > (Yes that's obscure, it needs a nicer way to do it!) > > > On Tue, Sep 22, 2015 at 10:33 PM, Matthew Else > wrote: > > You need to do image.set_pixel_value(x, y, (value from 0 to 255)) > > > > On Tue, Sep 22, 2015 at 10:31 PM Matthew Else > > > wrote: > >> > >> There is a way of doing set_brightness (greyscale), however I'm not > >> entirely clear about how you would do it :p > >> > >> On Tue, Sep 22, 2015 at 10:29 PM Larry Hastings > >> wrote: > >>> > >>> > >>> > >>> On 09/22/2015 10:17 PM, Mariia Koroliuk wrote: > >>> > >>> Hello, > >>> > >>> I hope this is a right way to ask :) Please tell me how to do it > >>> properly! Is there come conversation somewhere with general queries? > >>> > >>> 1) How does the creating new Image work? For example, I want to define > >>> > >>> CHESS='1,0,1,0,1 \n 0,1,0,1,0 \n 1,0,1,0,1 \n 0,1,0,1,0 \n 1,0,1,0,1 ' > >>> (I think this is the form was discussed?) > >>> > >>> > >>> I believe that's the initializer for the constructor. You need to make > >>> an Image object. > >>> chess = microbit.Image(CHESS) > >>> microbit.display.print(chess) > >>> > >>> Image might be inside microbit.display, I'm not sure. > >>> > >>> > >>> > >>> 2) How do I control the brightness of one pixel? Something like > >>> > >>> microbit.display.set_brightness (3,3,200)? > >>> > >>> > >>> The LEDs are either on or off. No brightness control. > >>> > >>> > >>> /arry > >>> _______________________________________________ > >>> 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 larry at hastings.org Wed Sep 23 00:01:26 2015 From: larry at hastings.org (Larry Hastings) Date: Tue, 22 Sep 2015 23:01:26 +0100 Subject: [Microbit-Python] API design heuristics from PyCon UK In-Reply-To: <5601AF87.9000600@ntoll.org> References: <5601AF87.9000600@ntoll.org> Message-ID: <5601CFB6.4050706@hastings.org> On 09/22/2015 08:44 PM, Nicholas H.Tollervey wrote: > Hi Folks, > > So, I'd like to call a halt on the bike-shedding. :-) > > I believe we had reached a consensus yesterday and I've added photos of > the final state of the white-board and summarised our discussion in the > following pull request: > > https://github.com/dpgeorge/microbit-micropython/pull/24 Is that a "private" repo? I get a 404 error featuring Octocat Kenobi. My account is "larryhastings", //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From maria.korolyuk at gmail.com Wed Sep 23 00:03:41 2015 From: maria.korolyuk at gmail.com (Mariia Koroliuk) Date: Tue, 22 Sep 2015 23:03:41 +0100 Subject: [Microbit-Python] some questions (and where should I ask them normally?) In-Reply-To: References: <5601C836.4020604@hastings.org> Message-ID: Thanks! already noticed second answer too :P Thanks you so much! and sorry for lots of letters! On 22 September 2015 at 23:00, Mariia Koroliuk wrote: > Thanks :) > > I mean if I need a different brightness for different pixels? is it > possible? > > On 22 September 2015 at 22:50, Damien George > wrote: > >> Yes, this is the right channel for questions and discussion. >> >> Larry is correct: you construct an image using >> >> img = microbit.Image('0,1,0,0,0\n...') >> >> then use it: >> >> microbit.display.print(img) >> >> To use the greyscale feature you need to first do: >> >> microbit.display.set_display_mode(1) >> >> (Yes that's obscure, it needs a nicer way to do it!) >> >> >> On Tue, Sep 22, 2015 at 10:33 PM, Matthew Else >> wrote: >> > You need to do image.set_pixel_value(x, y, (value from 0 to 255)) >> > >> > On Tue, Sep 22, 2015 at 10:31 PM Matthew Else < >> matthewelse1997 at gmail.com> >> > wrote: >> >> >> >> There is a way of doing set_brightness (greyscale), however I'm not >> >> entirely clear about how you would do it :p >> >> >> >> On Tue, Sep 22, 2015 at 10:29 PM Larry Hastings >> >> wrote: >> >>> >> >>> >> >>> >> >>> On 09/22/2015 10:17 PM, Mariia Koroliuk wrote: >> >>> >> >>> Hello, >> >>> >> >>> I hope this is a right way to ask :) Please tell me how to do it >> >>> properly! Is there come conversation somewhere with general queries? >> >>> >> >>> 1) How does the creating new Image work? For example, I want to define >> >>> >> >>> CHESS='1,0,1,0,1 \n 0,1,0,1,0 \n 1,0,1,0,1 \n 0,1,0,1,0 \n 1,0,1,0,1 ' >> >>> (I think this is the form was discussed?) >> >>> >> >>> >> >>> I believe that's the initializer for the constructor. You need to >> make >> >>> an Image object. >> >>> chess = microbit.Image(CHESS) >> >>> microbit.display.print(chess) >> >>> >> >>> Image might be inside microbit.display, I'm not sure. >> >>> >> >>> >> >>> >> >>> 2) How do I control the brightness of one pixel? Something like >> >>> >> >>> microbit.display.set_brightness (3,3,200)? >> >>> >> >>> >> >>> The LEDs are either on or off. No brightness control. >> >>> >> >>> >> >>> /arry >> >>> _______________________________________________ >> >>> 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 damien.p.george at gmail.com Wed Sep 23 00:07:04 2015 From: damien.p.george at gmail.com (Damien George) Date: Tue, 22 Sep 2015 23:07:04 +0100 Subject: [Microbit-Python] some questions (and where should I ask them normally?) In-Reply-To: References: <5601C836.4020604@hastings.org> Message-ID: You can do the following: img = microbit.Image('255,1,1,0,0\n,1,1,0,0,0\n') microbit.display.print(img) On Tue, Sep 22, 2015 at 11:03 PM, Mariia Koroliuk wrote: > Thanks! already noticed second answer too :P > > Thanks you so much! and sorry for lots of letters! > > > On 22 September 2015 at 23:00, Mariia Koroliuk > wrote: >> >> Thanks :) >> >> I mean if I need a different brightness for different pixels? is it >> possible? >> >> On 22 September 2015 at 22:50, Damien George >> wrote: >>> >>> Yes, this is the right channel for questions and discussion. >>> >>> Larry is correct: you construct an image using >>> >>> img = microbit.Image('0,1,0,0,0\n...') >>> >>> then use it: >>> >>> microbit.display.print(img) >>> >>> To use the greyscale feature you need to first do: >>> >>> microbit.display.set_display_mode(1) >>> >>> (Yes that's obscure, it needs a nicer way to do it!) >>> >>> >>> On Tue, Sep 22, 2015 at 10:33 PM, Matthew Else >>> wrote: >>> > You need to do image.set_pixel_value(x, y, (value from 0 to 255)) >>> > >>> > On Tue, Sep 22, 2015 at 10:31 PM Matthew Else >>> > >>> > wrote: >>> >> >>> >> There is a way of doing set_brightness (greyscale), however I'm not >>> >> entirely clear about how you would do it :p >>> >> >>> >> On Tue, Sep 22, 2015 at 10:29 PM Larry Hastings >>> >> wrote: >>> >>> >>> >>> >>> >>> >>> >>> On 09/22/2015 10:17 PM, Mariia Koroliuk wrote: >>> >>> >>> >>> Hello, >>> >>> >>> >>> I hope this is a right way to ask :) Please tell me how to do it >>> >>> properly! Is there come conversation somewhere with general queries? >>> >>> >>> >>> 1) How does the creating new Image work? For example, I want to >>> >>> define >>> >>> >>> >>> CHESS='1,0,1,0,1 \n 0,1,0,1,0 \n 1,0,1,0,1 \n 0,1,0,1,0 \n 1,0,1,0,1 >>> >>> ' >>> >>> (I think this is the form was discussed?) >>> >>> >>> >>> >>> >>> I believe that's the initializer for the constructor. You need to >>> >>> make >>> >>> an Image object. >>> >>> chess = microbit.Image(CHESS) >>> >>> microbit.display.print(chess) >>> >>> >>> >>> Image might be inside microbit.display, I'm not sure. >>> >>> >>> >>> >>> >>> >>> >>> 2) How do I control the brightness of one pixel? Something like >>> >>> >>> >>> microbit.display.set_brightness (3,3,200)? >>> >>> >>> >>> >>> >>> The LEDs are either on or off. No brightness control. >>> >>> >>> >>> >>> >>> /arry >>> >>> _______________________________________________ >>> >>> 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 > From damien.p.george at gmail.com Wed Sep 23 00:08:23 2015 From: damien.p.george at gmail.com (Damien George) Date: Tue, 22 Sep 2015 23:08:23 +0100 Subject: [Microbit-Python] API design heuristics from PyCon UK In-Reply-To: <5601CFB6.4050706@hastings.org> References: <5601AF87.9000600@ntoll.org> <5601CFB6.4050706@hastings.org> Message-ID: Larry, you're now added to the repository. On Tue, Sep 22, 2015 at 11:01 PM, Larry Hastings wrote: > > > On 09/22/2015 08:44 PM, Nicholas H.Tollervey wrote: > > Hi Folks, > > So, I'd like to call a halt on the bike-shedding. :-) > > I believe we had reached a consensus yesterday and I've added photos of > the final state of the white-board and summarised our discussion in the > following pull request: > > https://github.com/dpgeorge/microbit-micropython/pull/24 > > > Is that a "private" repo? I get a 404 error featuring Octocat Kenobi. > > My account is "larryhastings", > > > /arry > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > From david at thinkingbinaries.com Wed Sep 23 00:13:17 2015 From: david at thinkingbinaries.com (David Whale) Date: Tue, 22 Sep 2015 23:13:17 +0100 Subject: [Microbit-Python] Flat API In-Reply-To: References: <5600616A.2000107@ntoll.org> <56013703.80902@hastings.org> <56014B5B.40606@hastings.org> <56016A83.10202@hastings.org> Message-ID: I'm sure both GCSE and AQA specifications talk about abstraction and decomposition - how can you do that without functions?? All our 11 year olds use functions in the schools I work with. We introduce functions in Adventures in Minecraft (aimed at 11-15 year olds and mostly syncronised to the GCSE curriculum) in chapter 3 and use them extensively through to chapter 10 as a way to build up and test programs in small incremental steps. I personally think OCR are wrong on this. 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 22 September 2015 at 16:09, Michael wrote: > Cool. I was more worried I'd offended you. Glad I haven't :-) > > (it's very difficult to tell over email, so try to err on the side of > caution!) > > To explain where I'm coming from perhaps better, I've been hanging out on > the computing at school forum now for 2-3 years (or more), and randomly > reply to python queries on there, and been rather surprised to see this > response sort of response from time to time - either to my replies or to > other people's: > > ... thanks for taking the time to write it. Although the fact that you > recommend using functions also reminded me that we are not in the right > territory: Functions are outside the scope of OCR GCSE programming, believe > it or not (they are present in the AQA specifications though, so maybe I > should switch?) > > > (this was in a response to a simple question about validating input data, > and simply suggested simple "isint" and "isfloat" functions to avoid > repeating the same logic over and over...) > > That's a little scary to me, and it's always at the back of my mind - > because it's a far more common perspective. That comment incidentally is > from a teacher who is teaching 14-16 year olds rather than 11-12 year olds. > (and yes, there were plenty of other replies from other teachers saying > that was the wrong approach) > > It's interesting actually, if this was an API for CodeClubs (even for the > same age range), I wouldn't even have worried at all. > > Anyway, I'll wait to see the bike now before I start suggesting training > wheels or a different colour shed :-) > > Regards, > > > Michael. > > On 22 September 2015 at 15:49, Larry Hastings wrote: > >> >> >> On 09/22/2015 02:05 PM, Michael wrote: >> >> Hi, >> >> >> Sorry if I've offended you (it looks like I might've done). >> >> >> >> Naah, no worries. And I didn't realize you weren't there yesterday--I >> didn't get everybody's names. >> >> This is private, but I can post this to the list if you like, >> >> >> */arry* >> >> _______________________________________________ >> 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 alainjackson at hotmail.com Wed Sep 23 01:25:05 2015 From: alainjackson at hotmail.com (Alan) Date: Tue, 22 Sep 2015 23:25:05 +0000 Subject: [Microbit-Python] Flat API In-Reply-To: References: <5600616A.2000107@ntoll.org>, , , <56013703.80902@hastings.org>, , <56014B5B.40606@hastings.org>, , <56016A83.10202@hastings.org>, , Message-ID: Sometimes when agreement doesn't come easily it can be because the goal isn't clear to everyone.... which made think that perhaps the goal isn't clear to me. What is the goal of micro:bit? Is it to teach 11 year-olds good programming skills? Or is it to inspire 11 year-olds with an interest in problem solving, STEM etc.? If it's the first, then there's a strong case to make our designs "proper", even at the expense of making things a bit more difficult for the novice initially. If it's the second then the emphasis changes and it's more weighted towards accessibility, I think. I realise I've been assuming the goal is the second and I'm happy to be corrected if it's not. In my mind the micro:bit is it's own fun little problem solving universe. It doesn't have a web browser or built in games (yay!) - it's only going to do what you make it do. It's amazing that you can program it in python. Even if it happened to use some non-standard variant of python or its API wasn't completely "proper" it wouldn't really bother me... iff we're aiming for the second goal. If we're aiming for the first, it would bother me. When I suggested a flat version of the API I wasn't just thinking about 11 year-olds and their typing or spelling ski11z, I was thinking about teachers and myself. I'm wondering if, in the classroom (which is only one situation of its use), it's going to feel more like "live coding". It really did for me when we were all round the table at pycon and Nick was saying "You've got 20 minutes to make something interesting", and I was coding on the REPL, continuously recreating my program with the up arrow and finding out the command history is only 10 lines. If these thoughts aren't useful or are bike-shedding, please ignore them. I don't want to waste your valuable time and distract you from the cool stuff you're doing. Cheers, Alan Date: Tue, 22 Sep 2015 23:13:17 +0100 From: david at thinkingbinaries.com To: microbit at python.org Subject: Re: [Microbit-Python] Flat API I'm sure both GCSE and AQA specifications talk about abstraction and decomposition - how can you do that without functions?? All our 11 year olds use functions in the schools I work with. We introduce functions in Adventures in Minecraft (aimed at 11-15 year olds and mostly syncronised to the GCSE curriculum) in chapter 3 and use them extensively through to chapter 10 as a way to build up and test programs in small incremental steps. I personally think OCR are wrong on this. 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 22 September 2015 at 16:09, Michael wrote: Cool. I was more worried I'd offended you. Glad I haven't :-) (it's very difficult to tell over email, so try to err on the side of caution!) To explain where I'm coming from perhaps better, I've been hanging out on the computing at school forum now for 2-3 years (or more), and randomly reply to python queries on there, and been rather surprised to see this response sort of response from time to time - either to my replies or to other people's: ... thanks for taking the time to write it. Although the fact that you recommend using functions also reminded me that we are not in the right territory: Functions are outside the scope of OCR GCSE programming, believe it or not (they are present in the AQA specifications though, so maybe I should switch?) (this was in a response to a simple question about validating input data, and simply suggested simple "isint" and "isfloat" functions to avoid repeating the same logic over and over...) That's a little scary to me, and it's always at the back of my mind - because it's a far more common perspective. That comment incidentally is from a teacher who is teaching 14-16 year olds rather than 11-12 year olds. (and yes, there were plenty of other replies from other teachers saying that was the wrong approach) It's interesting actually, if this was an API for CodeClubs (even for the same age range), I wouldn't even have worried at all. Anyway, I'll wait to see the bike now before I start suggesting training wheels or a different colour shed :-) Regards, Michael. On 22 September 2015 at 15:49, Larry Hastings wrote: On 09/22/2015 02:05 PM, Michael wrote: Hi, Sorry if I've offended you (it looks like I might've done). Naah, no worries. And I didn't realize you weren't there yesterday--I didn't get everybody's names. This is private, but I can post this to the list if you like, /arry _______________________________________________ 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 alainjackson at hotmail.com Wed Sep 23 02:28:51 2015 From: alainjackson at hotmail.com (Alan) Date: Wed, 23 Sep 2015 00:28:51 +0000 Subject: [Microbit-Python] error code?... :(020 In-Reply-To: References: <5600616A.2000107@ntoll.org>, , , , , , <56013703.80902@hastings.org>, , , , <56014B5B.40606@hastings.org>, , , , <56016A83.10202@hastings.org>, , , , , Message-ID: Hi, I wrote a small program to draw on the LED matrix, but after setting a few LEDs on I get what looks like an error message on the LEDs: ":(020" (Frowny-face zero two zero) It just keeps repeating that and my program stops but there's no stack trace on the python repl. Is that a built in hardware error code or something? Has anyone else seen that? Here's my program: ====8<==== from microbit import * index = 0 while True: if button_a.is_pressed(): x = index % 5 y = int(index / 5) display.image.set_pixel_value(x,y, not(display.image.get_pixel_value(x,y))) if button_b.is_pressed(): index = (index + 1) % 25 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alainjackson at hotmail.com Wed Sep 23 05:02:51 2015 From: alainjackson at hotmail.com (Alan) Date: Wed, 23 Sep 2015 03:02:51 +0000 Subject: [Microbit-Python] error code?... :(020 In-Reply-To: References: <5600616A.2000107@ntoll.org>, ,,, ,,, ,,<56013703.80902@hastings.org>, ,,, ,,<56014B5B.40606@hastings.org>, ,,, ,,<56016A83.10202@hastings.org>, ,,, , , , , , Message-ID: Error code update. I'm consistently getting the ":( 020" code after 42 button presses (of any combination of buttons A and B). Is there a button click buffer that's overflowing somewhere? If there is I can't see a method on the microbit API to clear it. Cheers, Alan From: alainjackson at hotmail.com To: microbit at python.org Date: Wed, 23 Sep 2015 00:28:51 +0000 Subject: [Microbit-Python] error code?... :(020 Hi, I wrote a small program to draw on the LED matrix, but after setting a few LEDs on I get what looks like an error message on the LEDs: ":(020" (Frowny-face zero two zero) It just keeps repeating that and my program stops but there's no stack trace on the python repl. Is that a built in hardware error code or something? Has anyone else seen that? Here's my program: ====8<==== from microbit import * index = 0 while True: if button_a.is_pressed(): x = index % 5 y = int(index / 5) display.image.set_pixel_value(x,y, not(display.image.get_pixel_value(x,y))) if button_b.is_pressed(): index = (index + 1) % 25 _______________________________________________ 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 Wed Sep 23 09:18:36 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Wed, 23 Sep 2015 08:18:36 +0100 Subject: [Microbit-Python] API design heuristics from PyCon UK In-Reply-To: <5601CFB6.4050706@hastings.org> References: <5601AF87.9000600@ntoll.org> <5601CFB6.4050706@hastings.org> Message-ID: <5602524C.3020300@ntoll.org> Hi Larry, You'll also need access to Lancaster University's DAL (device abstraction layer) private repository in order to build MicroPython. I'm not sure if you were in the room when we explained this, but the DAL sits on top of ARM's C mbed layer (that directly interacts with the hardware) and provides some level of common abstractions / functionality for both MicroPython and Microsoft's TouchDevelop. I'll ping James and/or Joe at Lancaster to add you with the details you provided for Damien. Interesting aside - Microsoft's offering uses Javascript to "compile" an AST (expressed as a JSON object) into C++ that is linked against the DAL. This blob of code is sent to ARM's "cloud" mBed compilation platform and a hex file is (ultimately) returned to the user as a download in their browser. Yes, you need to be connected to the internet to compile in TouchDevelop. Our web based offering contains the .hex file for MicroPython embedded in the HTML (we want kids to "view source" and find it). We encode the user's Python script into the .hex format and concatenate it to the embedded hex file. When MicroPython starts up it looks at the memory location used for the user's Python script - if there's something there, it runs it. It's simple and works offline. We also have a hexify command (written in Python) that'll do the same sort of thing. I intend to create something pip-installable that'll give you a bunch of commands to make writing for the micro:bit easy. Hope this sheds more light on things... N. On 22/09/15 23:01, Larry Hastings wrote: > > > On 09/22/2015 08:44 PM, Nicholas H.Tollervey wrote: >> Hi Folks, >> >> So, I'd like to call a halt on the bike-shedding. :-) >> >> I believe we had reached a consensus yesterday and I've added photos of >> the final state of the white-board and summarised our discussion in the >> following pull request: >> >> https://github.com/dpgeorge/microbit-micropython/pull/24 > > Is that a "private" repo? I get a 404 error featuring Octocat Kenobi. > > My account is "larryhastings", > > > //arry/ > > > _______________________________________________ > 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 ntoll at ntoll.org Wed Sep 23 09:36:49 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Wed, 23 Sep 2015 08:36:49 +0100 Subject: [Microbit-Python] API design heuristics from PyCon UK In-Reply-To: <5601AF87.9000600@ntoll.org> References: <5601AF87.9000600@ntoll.org> Message-ID: <56025691.4070502@ntoll.org> OK... I've made a slight alteration to the wiki page to fold in Damien's comments about wait and loop keywords and the animate method. Anything else..? Many thanks to Matthew for making a rather good start on the wiki which can be found here: https://github.com/dpgeorge/microbit-micropython/wiki N. On 22/09/15 20:44, Nicholas H.Tollervey wrote: > Hi Folks, > > So, I'd like to call a halt on the bike-shedding. :-) > > I believe we had reached a consensus yesterday and I've added photos of > the final state of the white-board and summarised our discussion in the > following pull request: > > https://github.com/dpgeorge/microbit-micropython/pull/24 > > Please, while everyone loves discussing API design, we need to finalise > things because various people are relying on us to have something that > DOES NOT CHANGE in some fundamental way. For example, David Whale (also > on this list) from the IEE needs to be sure we're not pulling the rug > from underneath him and his micro:bit/MicroPython work. I also want to > add collaborators soon who will be creating further educational resources. > > So, PLEASE CHECK THE PR and feel free to propose changes to my branch. > These changes should only be corrections - NO NEW SUGGESTIONS for flat > APIs or other funky stuff. ;-) > > We need to be pragmatic, practical and focussed on kids. That means > simple, obvious and easy to use. I also like Larry's concern for > consistency and facilitating the formation of good habits. KISS with a > dash of wisdom is the order of the day. ;-) > > Damien, can you leave the PR open for just the next 24 hours so people > have a chance to correct my fumbles and poor memory? (See my "here be > dragons" section.) > > In 24 hours time I want us to be able to start working on this. I > certainly want to get the built-in help started soon and definitely > don't want to keep changing it..! > > As always, comments, constructive critique and ideas are most welcome. > > Yay! > > All the best, > > Nicholas. > > > > > _______________________________________________ > 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 sparks.m at gmail.com Wed Sep 23 11:02:44 2015 From: sparks.m at gmail.com (Michael) Date: Wed, 23 Sep 2015 10:02:44 +0100 Subject: [Microbit-Python] What is the goal of micro:bit? ( Was Re: Flat API ) Message-ID: [ This email has become a bit longer than I intended but I think it's important to say, since this was a great question, and deserves a proper answer. It's passionately it seems, but certainly isn't critiquing anyone or any API! ] > What is the goal of micro:bit? > > Is it to teach 11 year-olds good programming skills? > > Or is it to inspire 11 year-olds with an interest in problem solving, STEM etc.? While I don't think (and I doubt you do either) this is either/or, you're right, there is a trade off. The goal of micro:bit is very much the latter. To INSPIRE a generation. Quite literally. Why? Over the past 10 years the numbers of children taking computing in the UK dropped dramatically. At A-Level - where they should be able to come out of school with useful skills (I know I did) - esp if they get an A or a B - the numbers dropped below 4000 children nationally taking A-Level. Out of those, less than 200 were young ladies, and out of those less than 50 got grade A or B at A-Level. (ie more women at the Django Girls track at pycon UK gained useful skills than young ladies as recently as 2013 - which is when I last crunched the stats. (I've got graphs that show this if people are really interested) There are improvements across the board since 2013, and the curriculum is there to teach those good skills. The micro:bit is NOT there to replace the curriculum, or teachers. It is designed very heavily with the start of Key Stage 3 in mind - both in computing but in design technology, science and textiles as well. (Key Stage three is the first three years of seconday school for those like me who never has KS3, Y7/9 in their vocabulary. It's the 3 years you learn stuff without the pressure of exams in secondary school, ages 11-14) It isn't designed to replace anything else on the market. It is designed however to help and ENTICE people get the first rung on the ladder whereby they they think the ladder might be worth climing. It's aim is to INSPIRE. Who is it intended to inspire? Geeks? No. They'll get interested anyway. None of us on this list is now or ever has been the target audience. Kids with inspired, inspiring, engaged teachers? No. They're awesome, this is intended to help them inspire their kids, but they're not the audience. They'd find *something* however, without this. (this also means any teacher who attended Pycon UK is also NOT the audience, since they're already engaged.) The audience is the child who has yet to be turned off computing (but will be or perhaps has been) because they've had 6/7 years of homework in primary school and for the past 4 of them they've probably been using computers to write up and draw up their homework, and to open their eyes to the idea that they can create something cool. The idea is to simply make it as simple, as possible, as accessible as possible for the child who who when exposed to this stuff becomes interested. (After all, by the time they reach A-Level, that's 36,000 children who were turned off by the curriculum) It's the child who is not just pre-GCSE, but 2 years pre-GCSE. 2 years pre-GCSE in a school where a teacher teaches the bare minimum of the simplest curriculum, which they chose because they don't know very much at all. It's the child who's teacher thinks "I won't teach that that yet, because there'll be nothing for next year". It's the child who's teacher was until last year a Business Studies teacher and thinks that the move to teach coding is a stupid and annoying one, and that there's no point teaching year 7 or 8 anything now because by the time they reach year 9, the curriculum will change back again after a failed experiment. It's for the child who can't get access to a library because they live in the highlands of scotland, or orkneys, or Falklands. It's for the child who thinks "I can't spell, I can't do anything" - but they CAN do this, and suddenly they have a world of opportunity before them, and it turns out 4 years later they're undiagnosed dyslexic. It's for the child who's teacher only goes over any idea once, and generally only covers what's on the BBC Bytesize website, because they know the BBC puts a lot of effort into making that cover the curriculum (whether it achieves that is another matter), and they believe rightly or wrongly that's enough, and the child is ill that one day and it's never repeated. (I can think of specific representative teachers for each of these) In short, the target audience is for a child, just out of primary school, who's parents don't care, who's teaching support doesn't care, and doesn't think they can do things, and to inspire THEM that they can. It's for children who have never touched code, and are only doing so because their teacher is telling them to, and think they're the wrong sort of person (a common view amongst girls), and given half a chance they'd be doing something else. It's a device aimed at supporting EVERY child, including the "weakest" child, they child who believes they *can't* either because they really can't (there is a bell curve for everything), or simply because they've never been told they can (and needs to hear it). It's a device aimed not at you, or me, or our younger selves, but at everyone. It's aimed at the person you see in the shop who now is a checkout person, and was once 11. It's aimed the street cleaner you see, but when they were 11. It's aimed at the office worker who is bored with their work, and solves problems every day, but was once 11. This was the reason that the prototype had a flat API, since you only look in one place. It was based on watching real users and seeing the problems they have (the events prototype that came earlier). It's based on experience of working with children of all abilities - the ones with dyslexia, dyspraxia, ADD, or just plain average, or below average intelligence. Every other possible audience involved benefits from those decisions. Now, I'm not going to bikeshed the API - until I get to review what's been proposed - since that's really unfair and disrespectful to those who graciously gave up their time on monday, for which I'm very thankful. Given the choice, in this project I choose inspiration, not correctness, every time. You could say people often say "Make it work, make it work right, make it fast", but before that there has to be the decision "to make". On that basis, I didn't even require this line: from microbit import * Or this: import microbit The functions were just considerded builtins to the device. I can see why every other python programmer balks at this, but this is precisely the approach that pygame zero takes (I'd not seen that before pycon uk, so my impression could be wrong there). That said, to put this into perspective, if we inspire just 3% of children to change their minds and start climbing the ladder, then we haven't just done good, but we will actually have reversed 15-17 years of decline in this field, and that will hit in 2020. (rather than 2028 - which is when the first set of primary kids starting the new curriculum will leave school) Hmm. That was longer than I expected. Sorry about that. But I do know the answer to this question - the goal of the micro:bit is very simply INSPIRATION, and that should be the trade off here. (But yes, correctness matters) As I said though, this isn't posted to critique or support any particular API. It's just intended to explain the thinking behind the device, and the impact on my thinking when building the prototype and designing its API. I also think that the decision won't be mine and shouldn't be mine either, and I'll support whatever decision IS made, proudly and loudly. While getting resources and materials done ASAP does matter, sacrificing that for spending a day or two discussing whether an API is the right one - especially with regard to the tensions between ease of use and "correctness" is good. Pythonic-ness good. Micro-bitty-ness, better :-) Regards, Michael. (and once again, sorry about the length of this, but I feel pretty passionately about this :-) On 23 September 2015 at 00:25, Alan wrote: > Sometimes when agreement doesn't come easily it can be because the goal > isn't clear to everyone.... which made think that perhaps the goal isn't > clear to me. > > > > If it's the first, then there's a strong case to make our designs > "proper", even at the expense of making things a bit more difficult for the > novice initially. > > If it's the second then the emphasis changes and it's more weighted > towards accessibility, I think. > > I realise I've been assuming the goal is the second and I'm happy to be > corrected if it's not. > > > In my mind the micro:bit is it's own fun little problem solving universe. > It doesn't have a web browser or built in games (yay!) - it's only going to > do what you make it do. It's amazing that you can program it in python. > Even if it happened to use some non-standard variant of python or its API > wasn't completely "proper" it wouldn't really bother me... iff we're aiming > for the second goal. If we're aiming for the first, it would bother me. > > > When I suggested a flat version of the API I wasn't just thinking about 11 > year-olds and their typing or spelling ski11z, I was thinking about > teachers and myself. I'm wondering if, in the classroom (which is only one > situation of its use), it's going to feel more like "live coding". It > really did for me when we were all round the table at pycon and Nick was > saying "You've got 20 minutes to make something interesting", and I was > coding on the REPL, continuously recreating my program with the up arrow > and finding out the command history is only 10 lines. > > If these thoughts aren't useful or are bike-shedding, please ignore them. > I don't want to waste your valuable time and distract you from the cool > stuff you're doing. > > Cheers, > > Alan > > ------------------------------ > Date: Tue, 22 Sep 2015 23:13:17 +0100 > From: david at thinkingbinaries.com > To: microbit at python.org > Subject: Re: [Microbit-Python] Flat API > > I'm sure both GCSE and AQA specifications talk about abstraction and > decomposition - how can you do that without functions?? > > All our 11 year olds use functions in the schools I work with. We > introduce functions in Adventures in Minecraft (aimed at 11-15 year olds > and mostly syncronised to the GCSE curriculum) in chapter 3 and use them > extensively through to chapter 10 as a way to build up and test programs in > small incremental steps. > > I personally think OCR are wrong on this. > > 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 22 September 2015 at 16:09, Michael wrote: > > Cool. I was more worried I'd offended you. Glad I haven't :-) > > (it's very difficult to tell over email, so try to err on the side of > caution!) > > To explain where I'm coming from perhaps better, I've been hanging out on > the computing at school forum now for 2-3 years (or more), and randomly > reply to python queries on there, and been rather surprised to see this > response sort of response from time to time - either to my replies or to > other people's: > > ... thanks for taking the time to write it. Although the fact that you > recommend using functions also reminded me that we are not in the right > territory: Functions are outside the scope of OCR GCSE programming, believe > it or not (they are present in the AQA specifications though, so maybe I > should switch?) > > > (this was in a response to a simple question about validating input data, > and simply suggested simple "isint" and "isfloat" functions to avoid > repeating the same logic over and over...) > > That's a little scary to me, and it's always at the back of my mind - > because it's a far more common perspective. That comment incidentally is > from a teacher who is teaching 14-16 year olds rather than 11-12 year olds. > (and yes, there were plenty of other replies from other teachers saying > that was the wrong approach) > > It's interesting actually, if this was an API for CodeClubs (even for the > same age range), I wouldn't even have worried at all. > > Anyway, I'll wait to see the bike now before I start suggesting training > wheels or a different colour shed :-) > > Regards, > > > Michael. > > On 22 September 2015 at 15:49, Larry Hastings wrote: > > > > On 09/22/2015 02:05 PM, Michael wrote: > > Hi, > > > Sorry if I've offended you (it looks like I might've done). > > > > Naah, no worries. And I didn't realize you weren't there yesterday--I > didn't get everybody's names. > > This is private, but I can post this to the list if you like, > > > */arry* > > _______________________________________________ > 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 damien.p.george at gmail.com Wed Sep 23 11:44:26 2015 From: damien.p.george at gmail.com (Damien George) Date: Wed, 23 Sep 2015 10:44:26 +0100 Subject: [Microbit-Python] What is the goal of micro:bit? ( Was Re: Flat API ) In-Reply-To: References: Message-ID: Thanks Michael, that's a great read and good to have a "mission statement" to make decisions by. We do need to remember that Touch Develop and Code Kingdoms provide an alternative to (Micro)Python (and MP provides an alternative to them) and having alternatives already increases the adoption and use of the device. Some students might find the blockly interface more inspiring, while others like Python. So it's important that we provide something *different* (and I think Python is providing a little more computer-science rigour than the other offerings). We must also remember that we're bound by the Python language itself -- and the Python way of doing things -- so that places some restrictions on API design. I think though that we can slightly modify our API design to fit better with Michael's statement. I propose: 1. We replace microbit.pins.p[0-20] with top level names microbit.pin0 .. microbit.pin20. This removes a "namespace" level but still keps things clean (pin0.write_digital(1) is pretty obvious). 2. We revert to microbit.button_a and microbit.button_b. 3. On entering the REPL we execute from microbit import * to make all names available. Then it's very easy for a student to do display.print('hello!'), and other things. We should ensure that there are no short names in the microbit namespace that could easily clash with other names. 4. We should have from microbit import * written automatically at the start of the script in the editor (currently we have import microbit). That way students have immediate access to the functions/objects, but they can change that line to import microbit if they want. I think other decisions, like whether we use read_digital, digital_read or set_digital_value, are neither here nor there and don't affect the "first impressions" of the device (but still we'll try to choose sensible and consistent names). For the students that are hard to reach and engage, as long as the teacher can get them a REPL, they can type display.print('hahaha') and get something working, I think that's the best we can offer. Python's learning curve is shallow but long. And we can make the same thing on the microbit: the first thing kids do (display.print) should be super easy to do. And from there it should be a gradual learning curve towards more fun and advanced things. And the learning curve should continue for a long time for those more advanced students. I think we can do that. On Wed, Sep 23, 2015 at 10:02 AM, Michael wrote: > [ This email has become a bit longer than I intended but I think it's > important to say, since this was a great question, and deserves a proper > answer. It's passionately it seems, but certainly isn't critiquing anyone or > any API! ] > >> What is the goal of micro:bit? >> >> Is it to teach 11 year-olds good programming skills? >> >> Or is it to inspire 11 year-olds with an interest in problem solving, STEM >> etc.? > > While I don't think (and I doubt you do either) this is either/or, you're > right, there is a trade off. > > The goal of micro:bit is very much the latter. To INSPIRE a generation. > Quite literally. > > Why? > > Over the past 10 years the numbers of children taking computing in the UK > dropped dramatically. At A-Level - where they should be able to come out of > school with useful skills (I know I did) - esp if they get an A or a B - the > numbers dropped below 4000 children nationally taking A-Level. Out of those, > less than 200 were young ladies, and out of those less than 50 got grade A > or B at A-Level. (ie more women at the Django Girls track at pycon UK gained > useful skills than young ladies as recently as 2013 - which is when I last > crunched the stats. (I've got graphs that show this if people are really > interested) > > There are improvements across the board since 2013, and the curriculum is > there to teach those good skills. > > The micro:bit is NOT there to replace the curriculum, or teachers. It is > designed very heavily with the start of Key Stage 3 in mind - both in > computing but in design technology, science and textiles as well. (Key Stage > three is the first three years of seconday school for those like me who > never has KS3, Y7/9 in their vocabulary. It's the 3 years you learn stuff > without the pressure of exams in secondary school, ages 11-14) > > It isn't designed to replace anything else on the market. It is designed > however to help and ENTICE people get the first rung on the ladder whereby > they they think the ladder might be worth climing. > > It's aim is to INSPIRE. > > Who is it intended to inspire? > > Geeks? No. They'll get interested anyway. None of us on this list is now or > ever has been the target audience. > > Kids with inspired, inspiring, engaged teachers? No. They're awesome, this > is intended to help them inspire their kids, but they're not the audience. > They'd find *something* however, without this. (this also means any teacher > who attended Pycon UK is also NOT the audience, since they're already > engaged.) > > The audience is the child who has yet to be turned off computing (but will > be or perhaps has been) because they've had 6/7 years of homework in primary > school and for the past 4 of them they've probably been using computers to > write up and draw up their homework, and to open their eyes to the idea that > they can create something cool. > > The idea is to simply make it as simple, as possible, as accessible as > possible for the child who who when exposed to this stuff becomes > interested. (After all, by the time they reach A-Level, that's 36,000 > children who were turned off by the curriculum) > > It's the child who is not just pre-GCSE, but 2 years pre-GCSE. 2 years > pre-GCSE in a school where a teacher teaches the bare minimum of the > simplest curriculum, which they chose because they don't know very much at > all. > > It's the child who's teacher thinks "I won't teach that that yet, because > there'll be nothing for next year". > > It's the child who's teacher was until last year a Business Studies teacher > and thinks that the move to teach coding is a stupid and annoying one, and > that there's no point teaching year 7 or 8 anything now because by the time > they reach year 9, the curriculum will change back again after a failed > experiment. > > It's for the child who can't get access to a library because they live in > the highlands of scotland, or orkneys, or Falklands. > > It's for the child who thinks "I can't spell, I can't do anything" - but > they CAN do this, and suddenly they have a world of opportunity before them, > and it turns out 4 years later they're undiagnosed dyslexic. > > It's for the child who's teacher only goes over any idea once, and generally > only covers what's on the BBC Bytesize website, because they know the BBC > puts a lot of effort into making that cover the curriculum (whether it > achieves that is another matter), and they believe rightly or wrongly that's > enough, and the child is ill that one day and it's never repeated. > > (I can think of specific representative teachers for each of these) > > In short, the target audience is for a child, just out of primary school, > who's parents don't care, who's teaching support doesn't care, and doesn't > think they can do things, and to inspire THEM that they can. > > It's for children who have never touched code, and are only doing so because > their teacher is telling them to, and think they're the wrong sort of person > (a common view amongst girls), and given half a chance they'd be doing > something else. > > It's a device aimed at supporting EVERY child, including the "weakest" > child, they child who believes they *can't* either because they really can't > (there is a bell curve for everything), or simply because they've never been > told they can (and needs to hear it). It's a device aimed not at you, or me, > or our younger selves, but at everyone. It's aimed at the person you see in > the shop who now is a checkout person, and was once 11. It's aimed the > street cleaner you see, but when they were 11. It's aimed at the office > worker who is bored with their work, and solves problems every day, but was > once 11. > > This was the reason that the prototype had a flat API, since you only look > in one place. It was based on watching real users and seeing the problems > they have (the events prototype that came earlier). It's based on experience > of working with children of all abilities - the ones with dyslexia, > dyspraxia, ADD, or just plain average, or below average intelligence. > > Every other possible audience involved benefits from those decisions. > > Now, I'm not going to bikeshed the API - until I get to review what's been > proposed - since that's really unfair and disrespectful to those who > graciously gave up their time on monday, for which I'm very thankful. > > Given the choice, in this project I choose inspiration, not correctness, > every time. You could say people often say "Make it work, make it work > right, make it fast", but before that there has to be the decision "to > make". > > On that basis, I didn't even require this line: > > from microbit import * > > Or this: > > import microbit > > The functions were just considerded builtins to the device. I can see why > every other python programmer balks at this, but this is precisely the > approach that pygame zero takes (I'd not seen that before pycon uk, so my > impression could be wrong there). > > That said, to put this into perspective, if we inspire just 3% of children > to change their minds and start climbing the ladder, then we haven't just > done good, but we will actually have reversed 15-17 years of decline in this > field, and that will hit in 2020. (rather than 2028 - which is when the > first set of primary kids starting the new curriculum will leave school) > > Hmm. That was longer than I expected. Sorry about that. > > > But I do know the answer to this question - the goal of the micro:bit is > very simply INSPIRATION, and that should be the trade off here. (But yes, > correctness matters) > > As I said though, this isn't posted to critique or support any particular > API. It's just intended to explain the thinking behind the device, and the > impact on my thinking when building the prototype and designing its API. I > also think that the decision won't be mine and shouldn't be mine either, and > I'll support whatever decision IS made, proudly and loudly. > > While getting resources and materials done ASAP does matter, sacrificing > that for spending a day or two discussing whether an API is the right one - > especially with regard to the tensions between ease of use and "correctness" > is good. > > Pythonic-ness good. Micro-bitty-ness, better :-) > > Regards, > > Michael. > > (and once again, sorry about the length of this, but I feel pretty > passionately about this :-) > > > On 23 September 2015 at 00:25, Alan wrote: >> >> Sometimes when agreement doesn't come easily it can be because the goal >> isn't clear to everyone.... which made think that perhaps the goal isn't >> clear to me. >> >> >> >> If it's the first, then there's a strong case to make our designs >> "proper", even at the expense of making things a bit more difficult for the >> novice initially. >> >> If it's the second then the emphasis changes and it's more weighted >> towards accessibility, I think. >> >> I realise I've been assuming the goal is the second and I'm happy to be >> corrected if it's not. >> >> >> In my mind the micro:bit is it's own fun little problem solving universe. >> It doesn't have a web browser or built in games (yay!) - it's only going to >> do what you make it do. It's amazing that you can program it in python. Even >> if it happened to use some non-standard variant of python or its API wasn't >> completely "proper" it wouldn't really bother me... iff we're aiming for the >> second goal. If we're aiming for the first, it would bother me. >> >> >> When I suggested a flat version of the API I wasn't just thinking about 11 >> year-olds and their typing or spelling ski11z, I was thinking about teachers >> and myself. I'm wondering if, in the classroom (which is only one situation >> of its use), it's going to feel more like "live coding". It really did for >> me when we were all round the table at pycon and Nick was saying "You've got >> 20 minutes to make something interesting", and I was coding on the REPL, >> continuously recreating my program with the up arrow and finding out the >> command history is only 10 lines. >> >> If these thoughts aren't useful or are bike-shedding, please ignore them. >> I don't want to waste your valuable time and distract you from the cool >> stuff you're doing. >> >> Cheers, >> >> Alan >> >> ________________________________ >> Date: Tue, 22 Sep 2015 23:13:17 +0100 >> From: david at thinkingbinaries.com >> To: microbit at python.org >> Subject: Re: [Microbit-Python] Flat API >> >> I'm sure both GCSE and AQA specifications talk about abstraction and >> decomposition - how can you do that without functions?? >> >> All our 11 year olds use functions in the schools I work with. We >> introduce functions in Adventures in Minecraft (aimed at 11-15 year olds and >> mostly syncronised to the GCSE curriculum) in chapter 3 and use them >> extensively through to chapter 10 as a way to build up and test programs in >> small incremental steps. >> >> I personally think OCR are wrong on this. >> >> 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 22 September 2015 at 16:09, Michael wrote: >> >> Cool. I was more worried I'd offended you. Glad I haven't :-) >> >> (it's very difficult to tell over email, so try to err on the side of >> caution!) >> >> To explain where I'm coming from perhaps better, I've been hanging out on >> the computing at school forum now for 2-3 years (or more), and randomly >> reply to python queries on there, and been rather surprised to see this >> response sort of response from time to time - either to my replies or to >> other people's: >> >> ... thanks for taking the time to write it. Although the fact that you >> recommend using functions also reminded me that we are not in the right >> territory: Functions are outside the scope of OCR GCSE programming, believe >> it or not (they are present in the AQA specifications though, so maybe I >> should switch?) >> >> >> (this was in a response to a simple question about validating input data, >> and simply suggested simple "isint" and "isfloat" functions to avoid >> repeating the same logic over and over...) >> >> That's a little scary to me, and it's always at the back of my mind - >> because it's a far more common perspective. That comment incidentally is >> from a teacher who is teaching 14-16 year olds rather than 11-12 year olds. >> (and yes, there were plenty of other replies from other teachers saying that >> was the wrong approach) >> >> It's interesting actually, if this was an API for CodeClubs (even for the >> same age range), I wouldn't even have worried at all. >> >> Anyway, I'll wait to see the bike now before I start suggesting training >> wheels or a different colour shed :-) >> >> Regards, >> >> >> Michael. >> >> On 22 September 2015 at 15:49, Larry Hastings wrote: >> >> >> >> On 09/22/2015 02:05 PM, Michael wrote: >> >> Hi, >> >> >> Sorry if I've offended you (it looks like I might've done). >> >> >> >> Naah, no worries. And I didn't realize you weren't there yesterday--I >> didn't get everybody's names. >> >> This is private, but I can post this to the list if you like, >> >> >> /arry >> >> _______________________________________________ >> 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 >> > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > From sparks.m at gmail.com Wed Sep 23 11:56:16 2015 From: sparks.m at gmail.com (Michael) Date: Wed, 23 Sep 2015 10:56:16 +0100 Subject: [Microbit-Python] What is the goal of micro:bit? ( Was Re: Flat API ) In-Reply-To: References: Message-ID: +1 (As you say, I still very much want it to be python-y python :-) ) After all, one of my favourite things is the braces one in __future__ : ... >>> from __future__ import braces File "", line 1 SyntaxError: not a chance :-) Michael. On 23 September 2015 at 10:44, Damien George wrote: > Thanks Michael, that's a great read and good to have a "mission > statement" to make decisions by. > > We do need to remember that Touch Develop and Code Kingdoms provide an > alternative to (Micro)Python (and MP provides an alternative to them) > and having alternatives already increases the adoption and use of the > device. Some students might find the blockly interface more > inspiring, while others like Python. So it's important that we > provide something *different* (and I think Python is providing a > little more computer-science rigour than the other offerings). > > We must also remember that we're bound by the Python language itself > -- and the Python way of doing things -- so that places some > restrictions on API design. > > I think though that we can slightly modify our API design to fit > better with Michael's statement. I propose: > > 1. We replace microbit.pins.p[0-20] with top level names microbit.pin0 > .. microbit.pin20. This removes a "namespace" level but still keps > things clean (pin0.write_digital(1) is pretty obvious). > > 2. We revert to microbit.button_a and microbit.button_b. > > 3. On entering the REPL we execute from microbit import * to make all > names available. Then it's very easy for a student to do > display.print('hello!'), and other things. We should ensure that > there are no short names in the microbit namespace that could easily > clash with other names. > > 4. We should have from microbit import * written automatically at the > start of the script in the editor (currently we have import microbit). > That way students have immediate access to the functions/objects, but > they can change that line to import microbit if they want. > > I think other decisions, like whether we use read_digital, > digital_read or set_digital_value, are neither here nor there and > don't affect the "first impressions" of the device (but still we'll > try to choose sensible and consistent names). For the students that > are hard to reach and engage, as long as the teacher can get them a > REPL, they can type display.print('hahaha') and get something working, > I think that's the best we can offer. > > Python's learning curve is shallow but long. And we can make the same > thing on the microbit: the first thing kids do (display.print) should > be super easy to do. And from there it should be a gradual learning > curve towards more fun and advanced things. And the learning curve > should continue for a long time for those more advanced students. I > think we can do that. > > > > > > > On Wed, Sep 23, 2015 at 10:02 AM, Michael wrote: > > [ This email has become a bit longer than I intended but I think it's > > important to say, since this was a great question, and deserves a proper > > answer. It's passionately it seems, but certainly isn't critiquing > anyone or > > any API! ] > > > >> What is the goal of micro:bit? > >> > >> Is it to teach 11 year-olds good programming skills? > >> > >> Or is it to inspire 11 year-olds with an interest in problem solving, > STEM > >> etc.? > > > > While I don't think (and I doubt you do either) this is either/or, you're > > right, there is a trade off. > > > > The goal of micro:bit is very much the latter. To INSPIRE a generation. > > Quite literally. > > > > Why? > > > > Over the past 10 years the numbers of children taking computing in the UK > > dropped dramatically. At A-Level - where they should be able to come out > of > > school with useful skills (I know I did) - esp if they get an A or a B - > the > > numbers dropped below 4000 children nationally taking A-Level. Out of > those, > > less than 200 were young ladies, and out of those less than 50 got grade > A > > or B at A-Level. (ie more women at the Django Girls track at pycon UK > gained > > useful skills than young ladies as recently as 2013 - which is when I > last > > crunched the stats. (I've got graphs that show this if people are really > > interested) > > > > There are improvements across the board since 2013, and the curriculum is > > there to teach those good skills. > > > > The micro:bit is NOT there to replace the curriculum, or teachers. It is > > designed very heavily with the start of Key Stage 3 in mind - both in > > computing but in design technology, science and textiles as well. (Key > Stage > > three is the first three years of seconday school for those like me who > > never has KS3, Y7/9 in their vocabulary. It's the 3 years you learn stuff > > without the pressure of exams in secondary school, ages 11-14) > > > > It isn't designed to replace anything else on the market. It is designed > > however to help and ENTICE people get the first rung on the ladder > whereby > > they they think the ladder might be worth climing. > > > > It's aim is to INSPIRE. > > > > Who is it intended to inspire? > > > > Geeks? No. They'll get interested anyway. None of us on this list is now > or > > ever has been the target audience. > > > > Kids with inspired, inspiring, engaged teachers? No. They're awesome, > this > > is intended to help them inspire their kids, but they're not the > audience. > > They'd find *something* however, without this. (this also means any > teacher > > who attended Pycon UK is also NOT the audience, since they're already > > engaged.) > > > > The audience is the child who has yet to be turned off computing (but > will > > be or perhaps has been) because they've had 6/7 years of homework in > primary > > school and for the past 4 of them they've probably been using computers > to > > write up and draw up their homework, and to open their eyes to the idea > that > > they can create something cool. > > > > The idea is to simply make it as simple, as possible, as accessible as > > possible for the child who who when exposed to this stuff becomes > > interested. (After all, by the time they reach A-Level, that's 36,000 > > children who were turned off by the curriculum) > > > > It's the child who is not just pre-GCSE, but 2 years pre-GCSE. 2 years > > pre-GCSE in a school where a teacher teaches the bare minimum of the > > simplest curriculum, which they chose because they don't know very much > at > > all. > > > > It's the child who's teacher thinks "I won't teach that that yet, because > > there'll be nothing for next year". > > > > It's the child who's teacher was until last year a Business Studies > teacher > > and thinks that the move to teach coding is a stupid and annoying one, > and > > that there's no point teaching year 7 or 8 anything now because by the > time > > they reach year 9, the curriculum will change back again after a failed > > experiment. > > > > It's for the child who can't get access to a library because they live in > > the highlands of scotland, or orkneys, or Falklands. > > > > It's for the child who thinks "I can't spell, I can't do anything" - but > > they CAN do this, and suddenly they have a world of opportunity before > them, > > and it turns out 4 years later they're undiagnosed dyslexic. > > > > It's for the child who's teacher only goes over any idea once, and > generally > > only covers what's on the BBC Bytesize website, because they know the BBC > > puts a lot of effort into making that cover the curriculum (whether it > > achieves that is another matter), and they believe rightly or wrongly > that's > > enough, and the child is ill that one day and it's never repeated. > > > > (I can think of specific representative teachers for each of these) > > > > In short, the target audience is for a child, just out of primary school, > > who's parents don't care, who's teaching support doesn't care, and > doesn't > > think they can do things, and to inspire THEM that they can. > > > > It's for children who have never touched code, and are only doing so > because > > their teacher is telling them to, and think they're the wrong sort of > person > > (a common view amongst girls), and given half a chance they'd be doing > > something else. > > > > It's a device aimed at supporting EVERY child, including the "weakest" > > child, they child who believes they *can't* either because they really > can't > > (there is a bell curve for everything), or simply because they've never > been > > told they can (and needs to hear it). It's a device aimed not at you, or > me, > > or our younger selves, but at everyone. It's aimed at the person you see > in > > the shop who now is a checkout person, and was once 11. It's aimed the > > street cleaner you see, but when they were 11. It's aimed at the office > > worker who is bored with their work, and solves problems every day, but > was > > once 11. > > > > This was the reason that the prototype had a flat API, since you only > look > > in one place. It was based on watching real users and seeing the problems > > they have (the events prototype that came earlier). It's based on > experience > > of working with children of all abilities - the ones with dyslexia, > > dyspraxia, ADD, or just plain average, or below average intelligence. > > > > Every other possible audience involved benefits from those decisions. > > > > Now, I'm not going to bikeshed the API - until I get to review what's > been > > proposed - since that's really unfair and disrespectful to those who > > graciously gave up their time on monday, for which I'm very thankful. > > > > Given the choice, in this project I choose inspiration, not correctness, > > every time. You could say people often say "Make it work, make it work > > right, make it fast", but before that there has to be the decision "to > > make". > > > > On that basis, I didn't even require this line: > > > > from microbit import * > > > > Or this: > > > > import microbit > > > > The functions were just considerded builtins to the device. I can see why > > every other python programmer balks at this, but this is precisely the > > approach that pygame zero takes (I'd not seen that before pycon uk, so my > > impression could be wrong there). > > > > That said, to put this into perspective, if we inspire just 3% of > children > > to change their minds and start climbing the ladder, then we haven't just > > done good, but we will actually have reversed 15-17 years of decline in > this > > field, and that will hit in 2020. (rather than 2028 - which is when the > > first set of primary kids starting the new curriculum will leave school) > > > > Hmm. That was longer than I expected. Sorry about that. > > > > > > But I do know the answer to this question - the goal of the micro:bit is > > very simply INSPIRATION, and that should be the trade off here. (But yes, > > correctness matters) > > > > As I said though, this isn't posted to critique or support any particular > > API. It's just intended to explain the thinking behind the device, and > the > > impact on my thinking when building the prototype and designing its API. > I > > also think that the decision won't be mine and shouldn't be mine either, > and > > I'll support whatever decision IS made, proudly and loudly. > > > > While getting resources and materials done ASAP does matter, sacrificing > > that for spending a day or two discussing whether an API is the right > one - > > especially with regard to the tensions between ease of use and > "correctness" > > is good. > > > > Pythonic-ness good. Micro-bitty-ness, better :-) > > > > Regards, > > > > Michael. > > > > (and once again, sorry about the length of this, but I feel pretty > > passionately about this :-) > > > > > > On 23 September 2015 at 00:25, Alan wrote: > >> > >> Sometimes when agreement doesn't come easily it can be because the goal > >> isn't clear to everyone.... which made think that perhaps the goal isn't > >> clear to me. > >> > >> > >> > >> If it's the first, then there's a strong case to make our designs > >> "proper", even at the expense of making things a bit more difficult for > the > >> novice initially. > >> > >> If it's the second then the emphasis changes and it's more weighted > >> towards accessibility, I think. > >> > >> I realise I've been assuming the goal is the second and I'm happy to be > >> corrected if it's not. > >> > >> > >> In my mind the micro:bit is it's own fun little problem solving > universe. > >> It doesn't have a web browser or built in games (yay!) - it's only > going to > >> do what you make it do. It's amazing that you can program it in python. > Even > >> if it happened to use some non-standard variant of python or its API > wasn't > >> completely "proper" it wouldn't really bother me... iff we're aiming > for the > >> second goal. If we're aiming for the first, it would bother me. > >> > >> > >> When I suggested a flat version of the API I wasn't just thinking about > 11 > >> year-olds and their typing or spelling ski11z, I was thinking about > teachers > >> and myself. I'm wondering if, in the classroom (which is only one > situation > >> of its use), it's going to feel more like "live coding". It really did > for > >> me when we were all round the table at pycon and Nick was saying > "You've got > >> 20 minutes to make something interesting", and I was coding on the REPL, > >> continuously recreating my program with the up arrow and finding out the > >> command history is only 10 lines. > >> > >> If these thoughts aren't useful or are bike-shedding, please ignore > them. > >> I don't want to waste your valuable time and distract you from the cool > >> stuff you're doing. > >> > >> Cheers, > >> > >> Alan > >> > >> ________________________________ > >> Date: Tue, 22 Sep 2015 23:13:17 +0100 > >> From: david at thinkingbinaries.com > >> To: microbit at python.org > >> Subject: Re: [Microbit-Python] Flat API > >> > >> I'm sure both GCSE and AQA specifications talk about abstraction and > >> decomposition - how can you do that without functions?? > >> > >> All our 11 year olds use functions in the schools I work with. We > >> introduce functions in Adventures in Minecraft (aimed at 11-15 year > olds and > >> mostly syncronised to the GCSE curriculum) in chapter 3 and use them > >> extensively through to chapter 10 as a way to build up and test > programs in > >> small incremental steps. > >> > >> I personally think OCR are wrong on this. > >> > >> 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 22 September 2015 at 16:09, Michael wrote: > >> > >> Cool. I was more worried I'd offended you. Glad I haven't :-) > >> > >> (it's very difficult to tell over email, so try to err on the side of > >> caution!) > >> > >> To explain where I'm coming from perhaps better, I've been hanging out > on > >> the computing at school forum now for 2-3 years (or more), and randomly > >> reply to python queries on there, and been rather surprised to see this > >> response sort of response from time to time - either to my replies or to > >> other people's: > >> > >> ... thanks for taking the time to write it. Although the fact that you > >> recommend using functions also reminded me that we are not in the right > >> territory: Functions are outside the scope of OCR GCSE programming, > believe > >> it or not (they are present in the AQA specifications though, so maybe I > >> should switch?) > >> > >> > >> (this was in a response to a simple question about validating input > data, > >> and simply suggested simple "isint" and "isfloat" functions to avoid > >> repeating the same logic over and over...) > >> > >> That's a little scary to me, and it's always at the back of my mind - > >> because it's a far more common perspective. That comment incidentally is > >> from a teacher who is teaching 14-16 year olds rather than 11-12 year > olds. > >> (and yes, there were plenty of other replies from other teachers saying > that > >> was the wrong approach) > >> > >> It's interesting actually, if this was an API for CodeClubs (even for > the > >> same age range), I wouldn't even have worried at all. > >> > >> Anyway, I'll wait to see the bike now before I start suggesting training > >> wheels or a different colour shed :-) > >> > >> Regards, > >> > >> > >> Michael. > >> > >> On 22 September 2015 at 15:49, Larry Hastings > wrote: > >> > >> > >> > >> On 09/22/2015 02:05 PM, Michael wrote: > >> > >> Hi, > >> > >> > >> Sorry if I've offended you (it looks like I might've done). > >> > >> > >> > >> Naah, no worries. And I didn't realize you weren't there yesterday--I > >> didn't get everybody's names. > >> > >> This is private, but I can post this to the list if you like, > >> > >> > >> /arry > >> > >> _______________________________________________ > >> 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 > >> > > > > > > _______________________________________________ > > 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 Wed Sep 23 12:24:57 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Wed, 23 Sep 2015 11:24:57 +0100 Subject: [Microbit-Python] What is the goal of micro:bit? ( Was Re: Flat API ) In-Reply-To: References: Message-ID: <56027DF9.6070003@ntoll.org> +1 N. (at work so brevity required) On 23/09/15 10:44, Damien George wrote: > Thanks Michael, that's a great read and good to have a "mission > statement" to make decisions by. > > We do need to remember that Touch Develop and Code Kingdoms provide an > alternative to (Micro)Python (and MP provides an alternative to them) > and having alternatives already increases the adoption and use of the > device. Some students might find the blockly interface more > inspiring, while others like Python. So it's important that we > provide something *different* (and I think Python is providing a > little more computer-science rigour than the other offerings). > > We must also remember that we're bound by the Python language itself > -- and the Python way of doing things -- so that places some > restrictions on API design. > > I think though that we can slightly modify our API design to fit > better with Michael's statement. I propose: > > 1. We replace microbit.pins.p[0-20] with top level names microbit.pin0 > .. microbit.pin20. This removes a "namespace" level but still keps > things clean (pin0.write_digital(1) is pretty obvious). > > 2. We revert to microbit.button_a and microbit.button_b. > > 3. On entering the REPL we execute from microbit import * to make all > names available. Then it's very easy for a student to do > display.print('hello!'), and other things. We should ensure that > there are no short names in the microbit namespace that could easily > clash with other names. > > 4. We should have from microbit import * written automatically at the > start of the script in the editor (currently we have import microbit). > That way students have immediate access to the functions/objects, but > they can change that line to import microbit if they want. > > I think other decisions, like whether we use read_digital, > digital_read or set_digital_value, are neither here nor there and > don't affect the "first impressions" of the device (but still we'll > try to choose sensible and consistent names). For the students that > are hard to reach and engage, as long as the teacher can get them a > REPL, they can type display.print('hahaha') and get something working, > I think that's the best we can offer. > > Python's learning curve is shallow but long. And we can make the same > thing on the microbit: the first thing kids do (display.print) should > be super easy to do. And from there it should be a gradual learning > curve towards more fun and advanced things. And the learning curve > should continue for a long time for those more advanced students. I > think we can do that. > > > > > > > On Wed, Sep 23, 2015 at 10:02 AM, Michael wrote: >> [ This email has become a bit longer than I intended but I think it's >> important to say, since this was a great question, and deserves a proper >> answer. It's passionately it seems, but certainly isn't critiquing anyone or >> any API! ] >> >>> What is the goal of micro:bit? >>> >>> Is it to teach 11 year-olds good programming skills? >>> >>> Or is it to inspire 11 year-olds with an interest in problem solving, STEM >>> etc.? >> >> While I don't think (and I doubt you do either) this is either/or, you're >> right, there is a trade off. >> >> The goal of micro:bit is very much the latter. To INSPIRE a generation. >> Quite literally. >> >> Why? >> >> Over the past 10 years the numbers of children taking computing in the UK >> dropped dramatically. At A-Level - where they should be able to come out of >> school with useful skills (I know I did) - esp if they get an A or a B - the >> numbers dropped below 4000 children nationally taking A-Level. Out of those, >> less than 200 were young ladies, and out of those less than 50 got grade A >> or B at A-Level. (ie more women at the Django Girls track at pycon UK gained >> useful skills than young ladies as recently as 2013 - which is when I last >> crunched the stats. (I've got graphs that show this if people are really >> interested) >> >> There are improvements across the board since 2013, and the curriculum is >> there to teach those good skills. >> >> The micro:bit is NOT there to replace the curriculum, or teachers. It is >> designed very heavily with the start of Key Stage 3 in mind - both in >> computing but in design technology, science and textiles as well. (Key Stage >> three is the first three years of seconday school for those like me who >> never has KS3, Y7/9 in their vocabulary. It's the 3 years you learn stuff >> without the pressure of exams in secondary school, ages 11-14) >> >> It isn't designed to replace anything else on the market. It is designed >> however to help and ENTICE people get the first rung on the ladder whereby >> they they think the ladder might be worth climing. >> >> It's aim is to INSPIRE. >> >> Who is it intended to inspire? >> >> Geeks? No. They'll get interested anyway. None of us on this list is now or >> ever has been the target audience. >> >> Kids with inspired, inspiring, engaged teachers? No. They're awesome, this >> is intended to help them inspire their kids, but they're not the audience. >> They'd find *something* however, without this. (this also means any teacher >> who attended Pycon UK is also NOT the audience, since they're already >> engaged.) >> >> The audience is the child who has yet to be turned off computing (but will >> be or perhaps has been) because they've had 6/7 years of homework in primary >> school and for the past 4 of them they've probably been using computers to >> write up and draw up their homework, and to open their eyes to the idea that >> they can create something cool. >> >> The idea is to simply make it as simple, as possible, as accessible as >> possible for the child who who when exposed to this stuff becomes >> interested. (After all, by the time they reach A-Level, that's 36,000 >> children who were turned off by the curriculum) >> >> It's the child who is not just pre-GCSE, but 2 years pre-GCSE. 2 years >> pre-GCSE in a school where a teacher teaches the bare minimum of the >> simplest curriculum, which they chose because they don't know very much at >> all. >> >> It's the child who's teacher thinks "I won't teach that that yet, because >> there'll be nothing for next year". >> >> It's the child who's teacher was until last year a Business Studies teacher >> and thinks that the move to teach coding is a stupid and annoying one, and >> that there's no point teaching year 7 or 8 anything now because by the time >> they reach year 9, the curriculum will change back again after a failed >> experiment. >> >> It's for the child who can't get access to a library because they live in >> the highlands of scotland, or orkneys, or Falklands. >> >> It's for the child who thinks "I can't spell, I can't do anything" - but >> they CAN do this, and suddenly they have a world of opportunity before them, >> and it turns out 4 years later they're undiagnosed dyslexic. >> >> It's for the child who's teacher only goes over any idea once, and generally >> only covers what's on the BBC Bytesize website, because they know the BBC >> puts a lot of effort into making that cover the curriculum (whether it >> achieves that is another matter), and they believe rightly or wrongly that's >> enough, and the child is ill that one day and it's never repeated. >> >> (I can think of specific representative teachers for each of these) >> >> In short, the target audience is for a child, just out of primary school, >> who's parents don't care, who's teaching support doesn't care, and doesn't >> think they can do things, and to inspire THEM that they can. >> >> It's for children who have never touched code, and are only doing so because >> their teacher is telling them to, and think they're the wrong sort of person >> (a common view amongst girls), and given half a chance they'd be doing >> something else. >> >> It's a device aimed at supporting EVERY child, including the "weakest" >> child, they child who believes they *can't* either because they really can't >> (there is a bell curve for everything), or simply because they've never been >> told they can (and needs to hear it). It's a device aimed not at you, or me, >> or our younger selves, but at everyone. It's aimed at the person you see in >> the shop who now is a checkout person, and was once 11. It's aimed the >> street cleaner you see, but when they were 11. It's aimed at the office >> worker who is bored with their work, and solves problems every day, but was >> once 11. >> >> This was the reason that the prototype had a flat API, since you only look >> in one place. It was based on watching real users and seeing the problems >> they have (the events prototype that came earlier). It's based on experience >> of working with children of all abilities - the ones with dyslexia, >> dyspraxia, ADD, or just plain average, or below average intelligence. >> >> Every other possible audience involved benefits from those decisions. >> >> Now, I'm not going to bikeshed the API - until I get to review what's been >> proposed - since that's really unfair and disrespectful to those who >> graciously gave up their time on monday, for which I'm very thankful. >> >> Given the choice, in this project I choose inspiration, not correctness, >> every time. You could say people often say "Make it work, make it work >> right, make it fast", but before that there has to be the decision "to >> make". >> >> On that basis, I didn't even require this line: >> >> from microbit import * >> >> Or this: >> >> import microbit >> >> The functions were just considerded builtins to the device. I can see why >> every other python programmer balks at this, but this is precisely the >> approach that pygame zero takes (I'd not seen that before pycon uk, so my >> impression could be wrong there). >> >> That said, to put this into perspective, if we inspire just 3% of children >> to change their minds and start climbing the ladder, then we haven't just >> done good, but we will actually have reversed 15-17 years of decline in this >> field, and that will hit in 2020. (rather than 2028 - which is when the >> first set of primary kids starting the new curriculum will leave school) >> >> Hmm. That was longer than I expected. Sorry about that. >> >> >> But I do know the answer to this question - the goal of the micro:bit is >> very simply INSPIRATION, and that should be the trade off here. (But yes, >> correctness matters) >> >> As I said though, this isn't posted to critique or support any particular >> API. It's just intended to explain the thinking behind the device, and the >> impact on my thinking when building the prototype and designing its API. I >> also think that the decision won't be mine and shouldn't be mine either, and >> I'll support whatever decision IS made, proudly and loudly. >> >> While getting resources and materials done ASAP does matter, sacrificing >> that for spending a day or two discussing whether an API is the right one - >> especially with regard to the tensions between ease of use and "correctness" >> is good. >> >> Pythonic-ness good. Micro-bitty-ness, better :-) >> >> Regards, >> >> Michael. >> >> (and once again, sorry about the length of this, but I feel pretty >> passionately about this :-) >> >> >> On 23 September 2015 at 00:25, Alan wrote: >>> >>> Sometimes when agreement doesn't come easily it can be because the goal >>> isn't clear to everyone.... which made think that perhaps the goal isn't >>> clear to me. >>> >>> >>> >>> If it's the first, then there's a strong case to make our designs >>> "proper", even at the expense of making things a bit more difficult for the >>> novice initially. >>> >>> If it's the second then the emphasis changes and it's more weighted >>> towards accessibility, I think. >>> >>> I realise I've been assuming the goal is the second and I'm happy to be >>> corrected if it's not. >>> >>> >>> In my mind the micro:bit is it's own fun little problem solving universe. >>> It doesn't have a web browser or built in games (yay!) - it's only going to >>> do what you make it do. It's amazing that you can program it in python. Even >>> if it happened to use some non-standard variant of python or its API wasn't >>> completely "proper" it wouldn't really bother me... iff we're aiming for the >>> second goal. If we're aiming for the first, it would bother me. >>> >>> >>> When I suggested a flat version of the API I wasn't just thinking about 11 >>> year-olds and their typing or spelling ski11z, I was thinking about teachers >>> and myself. I'm wondering if, in the classroom (which is only one situation >>> of its use), it's going to feel more like "live coding". It really did for >>> me when we were all round the table at pycon and Nick was saying "You've got >>> 20 minutes to make something interesting", and I was coding on the REPL, >>> continuously recreating my program with the up arrow and finding out the >>> command history is only 10 lines. >>> >>> If these thoughts aren't useful or are bike-shedding, please ignore them. >>> I don't want to waste your valuable time and distract you from the cool >>> stuff you're doing. >>> >>> Cheers, >>> >>> Alan >>> >>> ________________________________ >>> Date: Tue, 22 Sep 2015 23:13:17 +0100 >>> From: david at thinkingbinaries.com >>> To: microbit at python.org >>> Subject: Re: [Microbit-Python] Flat API >>> >>> I'm sure both GCSE and AQA specifications talk about abstraction and >>> decomposition - how can you do that without functions?? >>> >>> All our 11 year olds use functions in the schools I work with. We >>> introduce functions in Adventures in Minecraft (aimed at 11-15 year olds and >>> mostly syncronised to the GCSE curriculum) in chapter 3 and use them >>> extensively through to chapter 10 as a way to build up and test programs in >>> small incremental steps. >>> >>> I personally think OCR are wrong on this. >>> >>> 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 22 September 2015 at 16:09, Michael wrote: >>> >>> Cool. I was more worried I'd offended you. Glad I haven't :-) >>> >>> (it's very difficult to tell over email, so try to err on the side of >>> caution!) >>> >>> To explain where I'm coming from perhaps better, I've been hanging out on >>> the computing at school forum now for 2-3 years (or more), and randomly >>> reply to python queries on there, and been rather surprised to see this >>> response sort of response from time to time - either to my replies or to >>> other people's: >>> >>> ... thanks for taking the time to write it. Although the fact that you >>> recommend using functions also reminded me that we are not in the right >>> territory: Functions are outside the scope of OCR GCSE programming, believe >>> it or not (they are present in the AQA specifications though, so maybe I >>> should switch?) >>> >>> >>> (this was in a response to a simple question about validating input data, >>> and simply suggested simple "isint" and "isfloat" functions to avoid >>> repeating the same logic over and over...) >>> >>> That's a little scary to me, and it's always at the back of my mind - >>> because it's a far more common perspective. That comment incidentally is >>> from a teacher who is teaching 14-16 year olds rather than 11-12 year olds. >>> (and yes, there were plenty of other replies from other teachers saying that >>> was the wrong approach) >>> >>> It's interesting actually, if this was an API for CodeClubs (even for the >>> same age range), I wouldn't even have worried at all. >>> >>> Anyway, I'll wait to see the bike now before I start suggesting training >>> wheels or a different colour shed :-) >>> >>> Regards, >>> >>> >>> Michael. >>> >>> On 22 September 2015 at 15:49, Larry Hastings wrote: >>> >>> >>> >>> On 09/22/2015 02:05 PM, Michael wrote: >>> >>> Hi, >>> >>> >>> Sorry if I've offended you (it looks like I might've done). >>> >>> >>> >>> Naah, no worries. And I didn't realize you weren't there yesterday--I >>> didn't get everybody's names. >>> >>> This is private, but I can post this to the list if you like, >>> >>> >>> /arry >>> >>> _______________________________________________ >>> 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 >>> >> >> >> _______________________________________________ >> 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 damien.p.george at gmail.com Wed Sep 23 14:54:25 2015 From: damien.p.george at gmail.com (Damien George) Date: Wed, 23 Sep 2015 13:54:25 +0100 Subject: [Microbit-Python] error code?... :(020 In-Reply-To: References: <5600616A.2000107@ntoll.org> <56013703.80902@hastings.org> <56014B5B.40606@hastings.org> <56016A83.10202@hastings.org> Message-ID: Hi Alan, Error code 020 is "out of memory". The problem is as you guessed: there is an event put on the event queue each time the button is pressed. To clear this queue your code needs to "yield". You can do this by putting sleep(1) in your loop. This is totally unexpected behaviour and I'll work out how to fix it (Ie your code should just work). Cheers, Damien. On Wed, Sep 23, 2015 at 4:02 AM, Alan wrote: > Error code update. > > I'm consistently getting the ":( 020" code after 42 button presses (of any > combination of buttons A and B). > > Is there a button click buffer that's overflowing somewhere? If there is I > can't see a method on the microbit API to clear it. > > Cheers, > > Alan > > ________________________________ > From: alainjackson at hotmail.com > To: microbit at python.org > Date: Wed, 23 Sep 2015 00:28:51 +0000 > Subject: [Microbit-Python] error code?... :(020 > > > Hi, > > I wrote a small program to draw on the LED matrix, but after setting a few > LEDs on I get what looks like an error message on the LEDs: > > ":(020" > > (Frowny-face zero two zero) > > It just keeps repeating that and my program stops but there's no stack trace > on the python repl. > > Is that a built in hardware error code or something? Has anyone else seen > that? > > Here's my program: > > ====8<==== > > from microbit import * > > index = 0 > > while True: > if button_a.is_pressed(): > x = index % 5 > y = int(index / 5) > display.image.set_pixel_value(x,y, > not(display.image.get_pixel_value(x,y))) > > if button_b.is_pressed(): > index = (index + 1) % 25 > > _______________________________________________ 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 sparks.m at gmail.com Wed Sep 23 15:56:01 2015 From: sparks.m at gmail.com (Michael) Date: Wed, 23 Sep 2015 14:56:01 +0100 Subject: [Microbit-Python] What is the goal of micro:bit? ( Was Re: Flat API ) In-Reply-To: <56027DF9.6070003@ntoll.org> References: <56027DF9.6070003@ntoll.org> Message-ID: By chance, and related - this came by my twitter feed today: http://edtechnology.co.uk/Article/girls-think-stem-subjects-are-too-hard Basically says 60% of girls aged 12 (ie in Year 7) think that STEM subjects are for boys, not for girls, because they perceive that the subjects are too which makes it a boys subject. That's just one example of the issues here. (They're wrong, for the statistics that I've seen that are comparable, girls do on average 5% better, but 5% never won hearts and minds! Flashing heart logo when your friends are nearby, that's a different matter :-) (There's many studies like this, but worth raising as a factor) Michael. On 23 September 2015 at 11:24, Nicholas H.Tollervey wrote: > +1 > > N. > > (at work so brevity required) > > On 23/09/15 10:44, Damien George wrote: > > Thanks Michael, that's a great read and good to have a "mission > > statement" to make decisions by. > > > > We do need to remember that Touch Develop and Code Kingdoms provide an > > alternative to (Micro)Python (and MP provides an alternative to them) > > and having alternatives already increases the adoption and use of the > > device. Some students might find the blockly interface more > > inspiring, while others like Python. So it's important that we > > provide something *different* (and I think Python is providing a > > little more computer-science rigour than the other offerings). > > > > We must also remember that we're bound by the Python language itself > > -- and the Python way of doing things -- so that places some > > restrictions on API design. > > > > I think though that we can slightly modify our API design to fit > > better with Michael's statement. I propose: > > > > 1. We replace microbit.pins.p[0-20] with top level names microbit.pin0 > > .. microbit.pin20. This removes a "namespace" level but still keps > > things clean (pin0.write_digital(1) is pretty obvious). > > > > 2. We revert to microbit.button_a and microbit.button_b. > > > > 3. On entering the REPL we execute from microbit import * to make all > > names available. Then it's very easy for a student to do > > display.print('hello!'), and other things. We should ensure that > > there are no short names in the microbit namespace that could easily > > clash with other names. > > > > 4. We should have from microbit import * written automatically at the > > start of the script in the editor (currently we have import microbit). > > That way students have immediate access to the functions/objects, but > > they can change that line to import microbit if they want. > > > > I think other decisions, like whether we use read_digital, > > digital_read or set_digital_value, are neither here nor there and > > don't affect the "first impressions" of the device (but still we'll > > try to choose sensible and consistent names). For the students that > > are hard to reach and engage, as long as the teacher can get them a > > REPL, they can type display.print('hahaha') and get something working, > > I think that's the best we can offer. > > > > Python's learning curve is shallow but long. And we can make the same > > thing on the microbit: the first thing kids do (display.print) should > > be super easy to do. And from there it should be a gradual learning > > curve towards more fun and advanced things. And the learning curve > > should continue for a long time for those more advanced students. I > > think we can do that. > > > > > > > > > > > > > > On Wed, Sep 23, 2015 at 10:02 AM, Michael wrote: > >> [ This email has become a bit longer than I intended but I think it's > >> important to say, since this was a great question, and deserves a proper > >> answer. It's passionately it seems, but certainly isn't critiquing > anyone or > >> any API! ] > >> > >>> What is the goal of micro:bit? > >>> > >>> Is it to teach 11 year-olds good programming skills? > >>> > >>> Or is it to inspire 11 year-olds with an interest in problem solving, > STEM > >>> etc.? > >> > >> While I don't think (and I doubt you do either) this is either/or, > you're > >> right, there is a trade off. > >> > >> The goal of micro:bit is very much the latter. To INSPIRE a generation. > >> Quite literally. > >> > >> Why? > >> > >> Over the past 10 years the numbers of children taking computing in the > UK > >> dropped dramatically. At A-Level - where they should be able to come > out of > >> school with useful skills (I know I did) - esp if they get an A or a B > - the > >> numbers dropped below 4000 children nationally taking A-Level. Out of > those, > >> less than 200 were young ladies, and out of those less than 50 got > grade A > >> or B at A-Level. (ie more women at the Django Girls track at pycon UK > gained > >> useful skills than young ladies as recently as 2013 - which is when I > last > >> crunched the stats. (I've got graphs that show this if people are really > >> interested) > >> > >> There are improvements across the board since 2013, and the curriculum > is > >> there to teach those good skills. > >> > >> The micro:bit is NOT there to replace the curriculum, or teachers. It is > >> designed very heavily with the start of Key Stage 3 in mind - both in > >> computing but in design technology, science and textiles as well. (Key > Stage > >> three is the first three years of seconday school for those like me who > >> never has KS3, Y7/9 in their vocabulary. It's the 3 years you learn > stuff > >> without the pressure of exams in secondary school, ages 11-14) > >> > >> It isn't designed to replace anything else on the market. It is designed > >> however to help and ENTICE people get the first rung on the ladder > whereby > >> they they think the ladder might be worth climing. > >> > >> It's aim is to INSPIRE. > >> > >> Who is it intended to inspire? > >> > >> Geeks? No. They'll get interested anyway. None of us on this list is > now or > >> ever has been the target audience. > >> > >> Kids with inspired, inspiring, engaged teachers? No. They're awesome, > this > >> is intended to help them inspire their kids, but they're not the > audience. > >> They'd find *something* however, without this. (this also means any > teacher > >> who attended Pycon UK is also NOT the audience, since they're already > >> engaged.) > >> > >> The audience is the child who has yet to be turned off computing (but > will > >> be or perhaps has been) because they've had 6/7 years of homework in > primary > >> school and for the past 4 of them they've probably been using computers > to > >> write up and draw up their homework, and to open their eyes to the idea > that > >> they can create something cool. > >> > >> The idea is to simply make it as simple, as possible, as accessible as > >> possible for the child who who when exposed to this stuff becomes > >> interested. (After all, by the time they reach A-Level, that's 36,000 > >> children who were turned off by the curriculum) > >> > >> It's the child who is not just pre-GCSE, but 2 years pre-GCSE. 2 years > >> pre-GCSE in a school where a teacher teaches the bare minimum of the > >> simplest curriculum, which they chose because they don't know very much > at > >> all. > >> > >> It's the child who's teacher thinks "I won't teach that that yet, > because > >> there'll be nothing for next year". > >> > >> It's the child who's teacher was until last year a Business Studies > teacher > >> and thinks that the move to teach coding is a stupid and annoying one, > and > >> that there's no point teaching year 7 or 8 anything now because by the > time > >> they reach year 9, the curriculum will change back again after a failed > >> experiment. > >> > >> It's for the child who can't get access to a library because they live > in > >> the highlands of scotland, or orkneys, or Falklands. > >> > >> It's for the child who thinks "I can't spell, I can't do anything" - but > >> they CAN do this, and suddenly they have a world of opportunity before > them, > >> and it turns out 4 years later they're undiagnosed dyslexic. > >> > >> It's for the child who's teacher only goes over any idea once, and > generally > >> only covers what's on the BBC Bytesize website, because they know the > BBC > >> puts a lot of effort into making that cover the curriculum (whether it > >> achieves that is another matter), and they believe rightly or wrongly > that's > >> enough, and the child is ill that one day and it's never repeated. > >> > >> (I can think of specific representative teachers for each of these) > >> > >> In short, the target audience is for a child, just out of primary > school, > >> who's parents don't care, who's teaching support doesn't care, and > doesn't > >> think they can do things, and to inspire THEM that they can. > >> > >> It's for children who have never touched code, and are only doing so > because > >> their teacher is telling them to, and think they're the wrong sort of > person > >> (a common view amongst girls), and given half a chance they'd be doing > >> something else. > >> > >> It's a device aimed at supporting EVERY child, including the "weakest" > >> child, they child who believes they *can't* either because they really > can't > >> (there is a bell curve for everything), or simply because they've never > been > >> told they can (and needs to hear it). It's a device aimed not at you, > or me, > >> or our younger selves, but at everyone. It's aimed at the person you > see in > >> the shop who now is a checkout person, and was once 11. It's aimed the > >> street cleaner you see, but when they were 11. It's aimed at the office > >> worker who is bored with their work, and solves problems every day, but > was > >> once 11. > >> > >> This was the reason that the prototype had a flat API, since you only > look > >> in one place. It was based on watching real users and seeing the > problems > >> they have (the events prototype that came earlier). It's based on > experience > >> of working with children of all abilities - the ones with dyslexia, > >> dyspraxia, ADD, or just plain average, or below average intelligence. > >> > >> Every other possible audience involved benefits from those decisions. > >> > >> Now, I'm not going to bikeshed the API - until I get to review what's > been > >> proposed - since that's really unfair and disrespectful to those who > >> graciously gave up their time on monday, for which I'm very thankful. > >> > >> Given the choice, in this project I choose inspiration, not correctness, > >> every time. You could say people often say "Make it work, make it work > >> right, make it fast", but before that there has to be the decision "to > >> make". > >> > >> On that basis, I didn't even require this line: > >> > >> from microbit import * > >> > >> Or this: > >> > >> import microbit > >> > >> The functions were just considerded builtins to the device. I can see > why > >> every other python programmer balks at this, but this is precisely the > >> approach that pygame zero takes (I'd not seen that before pycon uk, so > my > >> impression could be wrong there). > >> > >> That said, to put this into perspective, if we inspire just 3% of > children > >> to change their minds and start climbing the ladder, then we haven't > just > >> done good, but we will actually have reversed 15-17 years of decline in > this > >> field, and that will hit in 2020. (rather than 2028 - which is when the > >> first set of primary kids starting the new curriculum will leave school) > >> > >> Hmm. That was longer than I expected. Sorry about that. > >> > >> > >> But I do know the answer to this question - the goal of the micro:bit is > >> very simply INSPIRATION, and that should be the trade off here. (But > yes, > >> correctness matters) > >> > >> As I said though, this isn't posted to critique or support any > particular > >> API. It's just intended to explain the thinking behind the device, and > the > >> impact on my thinking when building the prototype and designing its > API. I > >> also think that the decision won't be mine and shouldn't be mine > either, and > >> I'll support whatever decision IS made, proudly and loudly. > >> > >> While getting resources and materials done ASAP does matter, sacrificing > >> that for spending a day or two discussing whether an API is the right > one - > >> especially with regard to the tensions between ease of use and > "correctness" > >> is good. > >> > >> Pythonic-ness good. Micro-bitty-ness, better :-) > >> > >> Regards, > >> > >> Michael. > >> > >> (and once again, sorry about the length of this, but I feel pretty > >> passionately about this :-) > >> > >> > >> On 23 September 2015 at 00:25, Alan wrote: > >>> > >>> Sometimes when agreement doesn't come easily it can be because the goal > >>> isn't clear to everyone.... which made think that perhaps the goal > isn't > >>> clear to me. > >>> > >>> > >>> > >>> If it's the first, then there's a strong case to make our designs > >>> "proper", even at the expense of making things a bit more difficult > for the > >>> novice initially. > >>> > >>> If it's the second then the emphasis changes and it's more weighted > >>> towards accessibility, I think. > >>> > >>> I realise I've been assuming the goal is the second and I'm happy to be > >>> corrected if it's not. > >>> > >>> > >>> In my mind the micro:bit is it's own fun little problem solving > universe. > >>> It doesn't have a web browser or built in games (yay!) - it's only > going to > >>> do what you make it do. It's amazing that you can program it in > python. Even > >>> if it happened to use some non-standard variant of python or its API > wasn't > >>> completely "proper" it wouldn't really bother me... iff we're aiming > for the > >>> second goal. If we're aiming for the first, it would bother me. > >>> > >>> > >>> When I suggested a flat version of the API I wasn't just thinking > about 11 > >>> year-olds and their typing or spelling ski11z, I was thinking about > teachers > >>> and myself. I'm wondering if, in the classroom (which is only one > situation > >>> of its use), it's going to feel more like "live coding". It really did > for > >>> me when we were all round the table at pycon and Nick was saying > "You've got > >>> 20 minutes to make something interesting", and I was coding on the > REPL, > >>> continuously recreating my program with the up arrow and finding out > the > >>> command history is only 10 lines. > >>> > >>> If these thoughts aren't useful or are bike-shedding, please ignore > them. > >>> I don't want to waste your valuable time and distract you from the cool > >>> stuff you're doing. > >>> > >>> Cheers, > >>> > >>> Alan > >>> > >>> ________________________________ > >>> Date: Tue, 22 Sep 2015 23:13:17 +0100 > >>> From: david at thinkingbinaries.com > >>> To: microbit at python.org > >>> Subject: Re: [Microbit-Python] Flat API > >>> > >>> I'm sure both GCSE and AQA specifications talk about abstraction and > >>> decomposition - how can you do that without functions?? > >>> > >>> All our 11 year olds use functions in the schools I work with. We > >>> introduce functions in Adventures in Minecraft (aimed at 11-15 year > olds and > >>> mostly syncronised to the GCSE curriculum) in chapter 3 and use them > >>> extensively through to chapter 10 as a way to build up and test > programs in > >>> small incremental steps. > >>> > >>> I personally think OCR are wrong on this. > >>> > >>> 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 22 September 2015 at 16:09, Michael wrote: > >>> > >>> Cool. I was more worried I'd offended you. Glad I haven't :-) > >>> > >>> (it's very difficult to tell over email, so try to err on the side of > >>> caution!) > >>> > >>> To explain where I'm coming from perhaps better, I've been hanging > out on > >>> the computing at school forum now for 2-3 years (or more), and randomly > >>> reply to python queries on there, and been rather surprised to see this > >>> response sort of response from time to time - either to my replies or > to > >>> other people's: > >>> > >>> ... thanks for taking the time to write it. Although the fact that > you > >>> recommend using functions also reminded me that we are not in the right > >>> territory: Functions are outside the scope of OCR GCSE programming, > believe > >>> it or not (they are present in the AQA specifications though, so maybe > I > >>> should switch?) > >>> > >>> > >>> (this was in a response to a simple question about validating input > data, > >>> and simply suggested simple "isint" and "isfloat" functions to avoid > >>> repeating the same logic over and over...) > >>> > >>> That's a little scary to me, and it's always at the back of my mind - > >>> because it's a far more common perspective. That comment incidentally > is > >>> from a teacher who is teaching 14-16 year olds rather than 11-12 year > olds. > >>> (and yes, there were plenty of other replies from other teachers > saying that > >>> was the wrong approach) > >>> > >>> It's interesting actually, if this was an API for CodeClubs (even for > the > >>> same age range), I wouldn't even have worried at all. > >>> > >>> Anyway, I'll wait to see the bike now before I start suggesting > training > >>> wheels or a different colour shed :-) > >>> > >>> Regards, > >>> > >>> > >>> Michael. > >>> > >>> On 22 September 2015 at 15:49, Larry Hastings > wrote: > >>> > >>> > >>> > >>> On 09/22/2015 02:05 PM, Michael wrote: > >>> > >>> Hi, > >>> > >>> > >>> Sorry if I've offended you (it looks like I might've done). > >>> > >>> > >>> > >>> Naah, no worries. And I didn't realize you weren't there yesterday--I > >>> didn't get everybody's names. > >>> > >>> This is private, but I can post this to the list if you like, > >>> > >>> > >>> /arry > >>> > >>> _______________________________________________ > >>> 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 > >>> > >> > >> > >> _______________________________________________ > >> 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 tom at viner.tv Wed Sep 23 20:24:19 2015 From: tom at viner.tv (Tom Viner) Date: Wed, 23 Sep 2015 19:24:19 +0100 Subject: [Microbit-Python] What is the goal of micro:bit? ( Was Re: Flat API ) In-Reply-To: References: <56027DF9.6070003@ntoll.org> Message-ID: +1 for what's been said so far. Can I propose that the repl auto executes: >>> microbit import * >>> dir() and the editor pre-populates with: from microbit import * # you can use display, button_a, button_b, pin0 ... pin20 etc etc if adult devs don't read the docs... On 23 September 2015 at 14:56, Michael wrote: > By chance, and related - this came by my twitter feed today: > > http://edtechnology.co.uk/Article/girls-think-stem-subjects-are-too-hard > > Basically says 60% of girls aged 12 (ie in Year 7) think that STEM > subjects are for boys, not for girls, because they perceive that the > subjects are too which makes it a boys subject. That's just one example of > the issues here. (They're wrong, for the statistics that I've seen that are > comparable, girls do on average 5% better, but 5% never won hearts and > minds! Flashing heart logo when your friends are nearby, that's a different > matter :-) > > (There's many studies like this, but worth raising as a factor) > > > Michael. > > On 23 September 2015 at 11:24, Nicholas H.Tollervey > wrote: > >> +1 >> >> N. >> >> (at work so brevity required) >> >> On 23/09/15 10:44, Damien George wrote: >> > Thanks Michael, that's a great read and good to have a "mission >> > statement" to make decisions by. >> > >> > We do need to remember that Touch Develop and Code Kingdoms provide an >> > alternative to (Micro)Python (and MP provides an alternative to them) >> > and having alternatives already increases the adoption and use of the >> > device. Some students might find the blockly interface more >> > inspiring, while others like Python. So it's important that we >> > provide something *different* (and I think Python is providing a >> > little more computer-science rigour than the other offerings). >> > >> > We must also remember that we're bound by the Python language itself >> > -- and the Python way of doing things -- so that places some >> > restrictions on API design. >> > >> > I think though that we can slightly modify our API design to fit >> > better with Michael's statement. I propose: >> > >> > 1. We replace microbit.pins.p[0-20] with top level names microbit.pin0 >> > .. microbit.pin20. This removes a "namespace" level but still keps >> > things clean (pin0.write_digital(1) is pretty obvious). >> > >> > 2. We revert to microbit.button_a and microbit.button_b. >> > >> > 3. On entering the REPL we execute from microbit import * to make all >> > names available. Then it's very easy for a student to do >> > display.print('hello!'), and other things. We should ensure that >> > there are no short names in the microbit namespace that could easily >> > clash with other names. >> > >> > 4. We should have from microbit import * written automatically at the >> > start of the script in the editor (currently we have import microbit). >> > That way students have immediate access to the functions/objects, but >> > they can change that line to import microbit if they want. >> > >> > I think other decisions, like whether we use read_digital, >> > digital_read or set_digital_value, are neither here nor there and >> > don't affect the "first impressions" of the device (but still we'll >> > try to choose sensible and consistent names). For the students that >> > are hard to reach and engage, as long as the teacher can get them a >> > REPL, they can type display.print('hahaha') and get something working, >> > I think that's the best we can offer. >> > >> > Python's learning curve is shallow but long. And we can make the same >> > thing on the microbit: the first thing kids do (display.print) should >> > be super easy to do. And from there it should be a gradual learning >> > curve towards more fun and advanced things. And the learning curve >> > should continue for a long time for those more advanced students. I >> > think we can do that. >> > >> > >> > >> > >> > >> > >> > On Wed, Sep 23, 2015 at 10:02 AM, Michael wrote: >> >> [ This email has become a bit longer than I intended but I think it's >> >> important to say, since this was a great question, and deserves a >> proper >> >> answer. It's passionately it seems, but certainly isn't critiquing >> anyone or >> >> any API! ] >> >> >> >>> What is the goal of micro:bit? >> >>> >> >>> Is it to teach 11 year-olds good programming skills? >> >>> >> >>> Or is it to inspire 11 year-olds with an interest in problem solving, >> STEM >> >>> etc.? >> >> >> >> While I don't think (and I doubt you do either) this is either/or, >> you're >> >> right, there is a trade off. >> >> >> >> The goal of micro:bit is very much the latter. To INSPIRE a generation. >> >> Quite literally. >> >> >> >> Why? >> >> >> >> Over the past 10 years the numbers of children taking computing in the >> UK >> >> dropped dramatically. At A-Level - where they should be able to come >> out of >> >> school with useful skills (I know I did) - esp if they get an A or a B >> - the >> >> numbers dropped below 4000 children nationally taking A-Level. Out of >> those, >> >> less than 200 were young ladies, and out of those less than 50 got >> grade A >> >> or B at A-Level. (ie more women at the Django Girls track at pycon UK >> gained >> >> useful skills than young ladies as recently as 2013 - which is when I >> last >> >> crunched the stats. (I've got graphs that show this if people are >> really >> >> interested) >> >> >> >> There are improvements across the board since 2013, and the curriculum >> is >> >> there to teach those good skills. >> >> >> >> The micro:bit is NOT there to replace the curriculum, or teachers. It >> is >> >> designed very heavily with the start of Key Stage 3 in mind - both in >> >> computing but in design technology, science and textiles as well. (Key >> Stage >> >> three is the first three years of seconday school for those like me who >> >> never has KS3, Y7/9 in their vocabulary. It's the 3 years you learn >> stuff >> >> without the pressure of exams in secondary school, ages 11-14) >> >> >> >> It isn't designed to replace anything else on the market. It is >> designed >> >> however to help and ENTICE people get the first rung on the ladder >> whereby >> >> they they think the ladder might be worth climing. >> >> >> >> It's aim is to INSPIRE. >> >> >> >> Who is it intended to inspire? >> >> >> >> Geeks? No. They'll get interested anyway. None of us on this list is >> now or >> >> ever has been the target audience. >> >> >> >> Kids with inspired, inspiring, engaged teachers? No. They're awesome, >> this >> >> is intended to help them inspire their kids, but they're not the >> audience. >> >> They'd find *something* however, without this. (this also means any >> teacher >> >> who attended Pycon UK is also NOT the audience, since they're already >> >> engaged.) >> >> >> >> The audience is the child who has yet to be turned off computing (but >> will >> >> be or perhaps has been) because they've had 6/7 years of homework in >> primary >> >> school and for the past 4 of them they've probably been using >> computers to >> >> write up and draw up their homework, and to open their eyes to the >> idea that >> >> they can create something cool. >> >> >> >> The idea is to simply make it as simple, as possible, as accessible as >> >> possible for the child who who when exposed to this stuff becomes >> >> interested. (After all, by the time they reach A-Level, that's 36,000 >> >> children who were turned off by the curriculum) >> >> >> >> It's the child who is not just pre-GCSE, but 2 years pre-GCSE. 2 years >> >> pre-GCSE in a school where a teacher teaches the bare minimum of the >> >> simplest curriculum, which they chose because they don't know very >> much at >> >> all. >> >> >> >> It's the child who's teacher thinks "I won't teach that that yet, >> because >> >> there'll be nothing for next year". >> >> >> >> It's the child who's teacher was until last year a Business Studies >> teacher >> >> and thinks that the move to teach coding is a stupid and annoying one, >> and >> >> that there's no point teaching year 7 or 8 anything now because by the >> time >> >> they reach year 9, the curriculum will change back again after a failed >> >> experiment. >> >> >> >> It's for the child who can't get access to a library because they live >> in >> >> the highlands of scotland, or orkneys, or Falklands. >> >> >> >> It's for the child who thinks "I can't spell, I can't do anything" - >> but >> >> they CAN do this, and suddenly they have a world of opportunity before >> them, >> >> and it turns out 4 years later they're undiagnosed dyslexic. >> >> >> >> It's for the child who's teacher only goes over any idea once, and >> generally >> >> only covers what's on the BBC Bytesize website, because they know the >> BBC >> >> puts a lot of effort into making that cover the curriculum (whether it >> >> achieves that is another matter), and they believe rightly or wrongly >> that's >> >> enough, and the child is ill that one day and it's never repeated. >> >> >> >> (I can think of specific representative teachers for each of these) >> >> >> >> In short, the target audience is for a child, just out of primary >> school, >> >> who's parents don't care, who's teaching support doesn't care, and >> doesn't >> >> think they can do things, and to inspire THEM that they can. >> >> >> >> It's for children who have never touched code, and are only doing so >> because >> >> their teacher is telling them to, and think they're the wrong sort of >> person >> >> (a common view amongst girls), and given half a chance they'd be doing >> >> something else. >> >> >> >> It's a device aimed at supporting EVERY child, including the "weakest" >> >> child, they child who believes they *can't* either because they really >> can't >> >> (there is a bell curve for everything), or simply because they've >> never been >> >> told they can (and needs to hear it). It's a device aimed not at you, >> or me, >> >> or our younger selves, but at everyone. It's aimed at the person you >> see in >> >> the shop who now is a checkout person, and was once 11. It's aimed the >> >> street cleaner you see, but when they were 11. It's aimed at the office >> >> worker who is bored with their work, and solves problems every day, >> but was >> >> once 11. >> >> >> >> This was the reason that the prototype had a flat API, since you only >> look >> >> in one place. It was based on watching real users and seeing the >> problems >> >> they have (the events prototype that came earlier). It's based on >> experience >> >> of working with children of all abilities - the ones with dyslexia, >> >> dyspraxia, ADD, or just plain average, or below average intelligence. >> >> >> >> Every other possible audience involved benefits from those decisions. >> >> >> >> Now, I'm not going to bikeshed the API - until I get to review what's >> been >> >> proposed - since that's really unfair and disrespectful to those who >> >> graciously gave up their time on monday, for which I'm very thankful. >> >> >> >> Given the choice, in this project I choose inspiration, not >> correctness, >> >> every time. You could say people often say "Make it work, make it work >> >> right, make it fast", but before that there has to be the decision "to >> >> make". >> >> >> >> On that basis, I didn't even require this line: >> >> >> >> from microbit import * >> >> >> >> Or this: >> >> >> >> import microbit >> >> >> >> The functions were just considerded builtins to the device. I can see >> why >> >> every other python programmer balks at this, but this is precisely the >> >> approach that pygame zero takes (I'd not seen that before pycon uk, so >> my >> >> impression could be wrong there). >> >> >> >> That said, to put this into perspective, if we inspire just 3% of >> children >> >> to change their minds and start climbing the ladder, then we haven't >> just >> >> done good, but we will actually have reversed 15-17 years of decline >> in this >> >> field, and that will hit in 2020. (rather than 2028 - which is when the >> >> first set of primary kids starting the new curriculum will leave >> school) >> >> >> >> Hmm. That was longer than I expected. Sorry about that. >> >> >> >> >> >> But I do know the answer to this question - the goal of the micro:bit >> is >> >> very simply INSPIRATION, and that should be the trade off here. (But >> yes, >> >> correctness matters) >> >> >> >> As I said though, this isn't posted to critique or support any >> particular >> >> API. It's just intended to explain the thinking behind the device, and >> the >> >> impact on my thinking when building the prototype and designing its >> API. I >> >> also think that the decision won't be mine and shouldn't be mine >> either, and >> >> I'll support whatever decision IS made, proudly and loudly. >> >> >> >> While getting resources and materials done ASAP does matter, >> sacrificing >> >> that for spending a day or two discussing whether an API is the right >> one - >> >> especially with regard to the tensions between ease of use and >> "correctness" >> >> is good. >> >> >> >> Pythonic-ness good. Micro-bitty-ness, better :-) >> >> >> >> Regards, >> >> >> >> Michael. >> >> >> >> (and once again, sorry about the length of this, but I feel pretty >> >> passionately about this :-) >> >> >> >> >> >> On 23 September 2015 at 00:25, Alan wrote: >> >>> >> >>> Sometimes when agreement doesn't come easily it can be because the >> goal >> >>> isn't clear to everyone.... which made think that perhaps the goal >> isn't >> >>> clear to me. >> >>> >> >>> >> >>> >> >>> If it's the first, then there's a strong case to make our designs >> >>> "proper", even at the expense of making things a bit more difficult >> for the >> >>> novice initially. >> >>> >> >>> If it's the second then the emphasis changes and it's more weighted >> >>> towards accessibility, I think. >> >>> >> >>> I realise I've been assuming the goal is the second and I'm happy to >> be >> >>> corrected if it's not. >> >>> >> >>> >> >>> In my mind the micro:bit is it's own fun little problem solving >> universe. >> >>> It doesn't have a web browser or built in games (yay!) - it's only >> going to >> >>> do what you make it do. It's amazing that you can program it in >> python. Even >> >>> if it happened to use some non-standard variant of python or its API >> wasn't >> >>> completely "proper" it wouldn't really bother me... iff we're aiming >> for the >> >>> second goal. If we're aiming for the first, it would bother me. >> >>> >> >>> >> >>> When I suggested a flat version of the API I wasn't just thinking >> about 11 >> >>> year-olds and their typing or spelling ski11z, I was thinking about >> teachers >> >>> and myself. I'm wondering if, in the classroom (which is only one >> situation >> >>> of its use), it's going to feel more like "live coding". It really >> did for >> >>> me when we were all round the table at pycon and Nick was saying >> "You've got >> >>> 20 minutes to make something interesting", and I was coding on the >> REPL, >> >>> continuously recreating my program with the up arrow and finding out >> the >> >>> command history is only 10 lines. >> >>> >> >>> If these thoughts aren't useful or are bike-shedding, please ignore >> them. >> >>> I don't want to waste your valuable time and distract you from the >> cool >> >>> stuff you're doing. >> >>> >> >>> Cheers, >> >>> >> >>> Alan >> >>> >> >>> ________________________________ >> >>> Date: Tue, 22 Sep 2015 23:13:17 +0100 >> >>> From: david at thinkingbinaries.com >> >>> To: microbit at python.org >> >>> Subject: Re: [Microbit-Python] Flat API >> >>> >> >>> I'm sure both GCSE and AQA specifications talk about abstraction and >> >>> decomposition - how can you do that without functions?? >> >>> >> >>> All our 11 year olds use functions in the schools I work with. We >> >>> introduce functions in Adventures in Minecraft (aimed at 11-15 year >> olds and >> >>> mostly syncronised to the GCSE curriculum) in chapter 3 and use them >> >>> extensively through to chapter 10 as a way to build up and test >> programs in >> >>> small incremental steps. >> >>> >> >>> I personally think OCR are wrong on this. >> >>> >> >>> 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 22 September 2015 at 16:09, Michael wrote: >> >>> >> >>> Cool. I was more worried I'd offended you. Glad I haven't :-) >> >>> >> >>> (it's very difficult to tell over email, so try to err on the side of >> >>> caution!) >> >>> >> >>> To explain where I'm coming from perhaps better, I've been hanging >> out on >> >>> the computing at school forum now for 2-3 years (or more), and >> randomly >> >>> reply to python queries on there, and been rather surprised to see >> this >> >>> response sort of response from time to time - either to my replies or >> to >> >>> other people's: >> >>> >> >>> ... thanks for taking the time to write it. Although the fact that >> you >> >>> recommend using functions also reminded me that we are not in the >> right >> >>> territory: Functions are outside the scope of OCR GCSE programming, >> believe >> >>> it or not (they are present in the AQA specifications though, so >> maybe I >> >>> should switch?) >> >>> >> >>> >> >>> (this was in a response to a simple question about validating input >> data, >> >>> and simply suggested simple "isint" and "isfloat" functions to avoid >> >>> repeating the same logic over and over...) >> >>> >> >>> That's a little scary to me, and it's always at the back of my mind - >> >>> because it's a far more common perspective. That comment incidentally >> is >> >>> from a teacher who is teaching 14-16 year olds rather than 11-12 year >> olds. >> >>> (and yes, there were plenty of other replies from other teachers >> saying that >> >>> was the wrong approach) >> >>> >> >>> It's interesting actually, if this was an API for CodeClubs (even for >> the >> >>> same age range), I wouldn't even have worried at all. >> >>> >> >>> Anyway, I'll wait to see the bike now before I start suggesting >> training >> >>> wheels or a different colour shed :-) >> >>> >> >>> Regards, >> >>> >> >>> >> >>> Michael. >> >>> >> >>> On 22 September 2015 at 15:49, Larry Hastings >> wrote: >> >>> >> >>> >> >>> >> >>> On 09/22/2015 02:05 PM, Michael wrote: >> >>> >> >>> Hi, >> >>> >> >>> >> >>> Sorry if I've offended you (it looks like I might've done). >> >>> >> >>> >> >>> >> >>> Naah, no worries. And I didn't realize you weren't there yesterday--I >> >>> didn't get everybody's names. >> >>> >> >>> This is private, but I can post this to the list if you like, >> >>> >> >>> >> >>> /arry >> >>> >> >>> _______________________________________________ >> >>> 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 >> >>> >> >> >> >> >> >> _______________________________________________ >> >> 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 Wed Sep 23 22:42:33 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Wed, 23 Sep 2015 21:42:33 +0100 Subject: [Microbit-Python] J.S.MicroBach Message-ID: <56030EB9.4010401@ntoll.org> Hi Folks, So it's not exactly amazing quality sound... in fact, I've basically made one of those bloody annoying bloopy-bleep-bleep birthday cards, but this: https://www.youtube.com/watch?v=4L12BP64AQM :-) Great work Matthew (whose work I've adapted to make this work). You pretty much nailed it, although I've changed the musical representation a little and I feel there's a tad more to do to make it child-friendly and familiar given other music representation systems on the computer. Damien, please find attached two scripts: The first script, bach.py, is what is flashed onto the device in the demo. When I connect to the REPL I get this... >>> dir() Traceback (most recent call last): File "", line 1 MemoryError: parser could not allocate enough memory I'm guessing we've run out of RAM. Given the code (and my lack of experience writing for embedded platforms with MicroPython) any hints on what I could do? The second script, music.py, is essentially the same as the first but with more of the music added to the notes list. When I try to flash the device I see the following scrolling across the screen: memory allocation error I'm guessing the script is simply too big to compile given the 16k RAM we have available..? Hey ho... I'm guessing this is a similar situation to David's pancake game. This is a GOOD THING for us to encounter. At the very worst we'll be unable to do anything about it in a technical sense so will have a heads up and time to get the messaging of such states correct so users have a chance to work out what's going on. My feeling is that we could create a whole new music based namespace under microbit (i.e. microbit.music) containing things like the following made up off the top of my head in a hand-wavy sort of a way: microbit.music.Tune - based on Matthew's class demonstrated in the video but implemented in C. microbit.music.play('c', 1, 1000) - play the note C in octave 1 for 1 second. microbit.music.pitch(440, 1000) - play the pitch for 1 second. The play method above is basically a friendly wrapper around this one. microbit.music.stop() - what you'd expect ;-) The final millisecond argument to the play and pitch methods could be optional (the device just keeps playing the note until it's changed). We could then use the accelerometer to change the pitch etc... Also, we could use the wait keyword as Damien suggested with the display methods to make musical things run in the background. Does this make sense..? As always, ideas, constructive critique and feedback is most welcome! All the best, Nicholas. -------------- next part -------------- A non-text attachment was scrubbed... Name: bach.py Type: text/x-python Size: 1952 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: music.py Type: text/x-python Size: 2901 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From matthewelse1997 at gmail.com Wed Sep 23 22:59:50 2015 From: matthewelse1997 at gmail.com (Matthew Else) Date: Wed, 23 Sep 2015 20:59:50 +0000 Subject: [Microbit-Python] J.S.MicroBach In-Reply-To: <56030EB9.4010401@ntoll.org> References: <56030EB9.4010401@ntoll.org> Message-ID: Hi Nick That's awesome! I could probably save some space by implementing the music module in C/C++, instead of Python which shouldn't be too difficult, but it just makes it a bit harder for people to experiment with if they want to add functionality. I was also planning to have a look at making the BLE API library (and the associated NRF51 specific bits of that) an optional extra in the DAL, but I haven't got round to that yet - essentially, I'm free for the next week and a bit until I start uni, so I'm happy to do all of these sorts of things since I don't have a great deal of other stuff to do. I would suggest that the best thing to do would be to create an issue on GitHub about flash/ram size issues, and I'll see to what extent I can try and reduce RAM usage (I would imagine Damien would probably be of more help with that, since I'm not that familiar with the internals of micropython), since it would be a shame if kids were to run out of RAM when they're doing awesome things like that. I've created a pull request with the music module included as a frozen python module (I think this is the right way of doing it for modules written in Python), which allows you to do things like: import music... Of course I agree with the changes to the API - I think it makes sense to do it that way. In the more recent version of the music code there's an 'add_notes' method, which lets you specify the notes as a list of tuples (essentially representing the arguments to the add_note method) - this would do more or less what you've done in your bach example. On Wed, Sep 23, 2015 at 9:42 PM Nicholas H.Tollervey wrote: > Hi Folks, > > So it's not exactly amazing quality sound... in fact, I've basically > made one of those bloody annoying bloopy-bleep-bleep birthday cards, but > this: > > https://www.youtube.com/watch?v=4L12BP64AQM > > :-) > > Great work Matthew (whose work I've adapted to make this work). You > pretty much nailed it, although I've changed the musical representation > a little and I feel there's a tad more to do to make it child-friendly > and familiar given other music representation systems on the computer. > > Damien, please find attached two scripts: > > The first script, bach.py, is what is flashed onto the device in the > demo. When I connect to the REPL I get this... > > >>> dir() > Traceback (most recent call last): > File "", line 1 > MemoryError: parser could not allocate enough memory > > I'm guessing we've run out of RAM. Given the code (and my lack of > experience writing for embedded platforms with MicroPython) any hints on > what I could do? > > The second script, music.py, is essentially the same as the first but > with more of the music added to the notes list. When I try to flash the > device I see the following scrolling across the screen: > > memory allocation error > > I'm guessing the script is simply too big to compile given the 16k RAM > we have available..? > > Hey ho... I'm guessing this is a similar situation to David's pancake game. > > This is a GOOD THING for us to encounter. At the very worst we'll be > unable to do anything about it in a technical sense so will have a heads > up and time to get the messaging of such states correct so users have a > chance to work out what's going on. > > My feeling is that we could create a whole new music based namespace > under microbit (i.e. microbit.music) containing things like the > following made up off the top of my head in a hand-wavy sort of a way: > > microbit.music.Tune - based on Matthew's class demonstrated in the video > but implemented in C. > microbit.music.play('c', 1, 1000) - play the note C in octave 1 for 1 > second. > microbit.music.pitch(440, 1000) - play the pitch for 1 second. The play > method above is basically a friendly wrapper around this one. > microbit.music.stop() - what you'd expect ;-) > > The final millisecond argument to the play and pitch methods could be > optional (the device just keeps playing the note until it's changed). We > could then use the accelerometer to change the pitch etc... > > Also, we could use the wait keyword as Damien suggested with the display > methods to make musical things run in the background. > > Does this make sense..? > > As always, ideas, constructive critique and feedback is most welcome! > > All the best, > > Nicholas. > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maria.korolyuk at gmail.com Thu Sep 24 00:30:48 2015 From: maria.korolyuk at gmail.com (Mariia Koroliuk) Date: Wed, 23 Sep 2015 23:30:48 +0100 Subject: [Microbit-Python] J.S.MicroBach In-Reply-To: References: <56030EB9.4010401@ntoll.org> Message-ID: Ow wow thats amazing! If I would be a kid I would get super excited about it! (well I am not a kid and I am still super excited about it!) On 23 September 2015 at 21:59, Matthew Else wrote: > Hi Nick > > That's awesome! > > I could probably save some space by implementing the music module in > C/C++, instead of Python which shouldn't be too difficult, but it just > makes it a bit harder for people to experiment with if they want to add > functionality. > > I was also planning to have a look at making the BLE API library (and the > associated NRF51 specific bits of that) an optional extra in the DAL, but I > haven't got round to that yet - essentially, I'm free for the next week and > a bit until I start uni, so I'm happy to do all of these sorts of things > since I don't have a great deal of other stuff to do. I would suggest that > the best thing to do would be to create an issue on GitHub about flash/ram > size issues, and I'll see to what extent I can try and reduce RAM usage (I > would imagine Damien would probably be of more help with that, since I'm > not that familiar with the internals of micropython), since it would be a > shame if kids were to run out of RAM when they're doing awesome things like > that. > > I've created a pull request with the music module included as a frozen > python module (I think this is the right way of doing it for modules > written in Python), which allows you to do things like: import music... > > Of course I agree with the changes to the API - I think it makes sense to > do it that way. In the more recent version of the music code there's an > 'add_notes' method, which lets you specify the notes as a list of tuples > (essentially representing the arguments to the add_note method) - this > would do more or less what you've done in your bach example. > > On Wed, Sep 23, 2015 at 9:42 PM Nicholas H.Tollervey > wrote: > >> Hi Folks, >> >> So it's not exactly amazing quality sound... in fact, I've basically >> made one of those bloody annoying bloopy-bleep-bleep birthday cards, but >> this: >> >> https://www.youtube.com/watch?v=4L12BP64AQM >> >> :-) >> >> Great work Matthew (whose work I've adapted to make this work). You >> pretty much nailed it, although I've changed the musical representation >> a little and I feel there's a tad more to do to make it child-friendly >> and familiar given other music representation systems on the computer. >> >> Damien, please find attached two scripts: >> >> The first script, bach.py, is what is flashed onto the device in the >> demo. When I connect to the REPL I get this... >> >> >>> dir() >> Traceback (most recent call last): >> File "", line 1 >> MemoryError: parser could not allocate enough memory >> >> I'm guessing we've run out of RAM. Given the code (and my lack of >> experience writing for embedded platforms with MicroPython) any hints on >> what I could do? >> >> The second script, music.py, is essentially the same as the first but >> with more of the music added to the notes list. When I try to flash the >> device I see the following scrolling across the screen: >> >> memory allocation error >> >> I'm guessing the script is simply too big to compile given the 16k RAM >> we have available..? >> >> Hey ho... I'm guessing this is a similar situation to David's pancake >> game. >> >> This is a GOOD THING for us to encounter. At the very worst we'll be >> unable to do anything about it in a technical sense so will have a heads >> up and time to get the messaging of such states correct so users have a >> chance to work out what's going on. >> >> My feeling is that we could create a whole new music based namespace >> under microbit (i.e. microbit.music) containing things like the >> following made up off the top of my head in a hand-wavy sort of a way: >> >> microbit.music.Tune - based on Matthew's class demonstrated in the video >> but implemented in C. >> microbit.music.play('c', 1, 1000) - play the note C in octave 1 for 1 >> second. >> microbit.music.pitch(440, 1000) - play the pitch for 1 second. The play >> method above is basically a friendly wrapper around this one. >> microbit.music.stop() - what you'd expect ;-) >> >> The final millisecond argument to the play and pitch methods could be >> optional (the device just keeps playing the note until it's changed). We >> could then use the accelerometer to change the pitch etc... >> >> Also, we could use the wait keyword as Damien suggested with the display >> methods to make musical things run in the background. >> >> Does this make sense..? >> >> As always, ideas, constructive critique and feedback is most welcome! >> >> All the best, >> >> 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 -------------- An HTML attachment was scrubbed... URL: From sparks.m at gmail.com Thu Sep 24 00:33:20 2015 From: sparks.m at gmail.com (Michael) Date: Wed, 23 Sep 2015 23:33:20 +0100 Subject: [Microbit-Python] J.S.MicroBach In-Reply-To: <56030EB9.4010401@ntoll.org> References: <56030EB9.4010401@ntoll.org> Message-ID: That's *really* fun :-) Michael. On 23 September 2015 at 21:42, Nicholas H.Tollervey wrote: > Hi Folks, > > So it's not exactly amazing quality sound... in fact, I've basically > made one of those bloody annoying bloopy-bleep-bleep birthday cards, but > this: > > https://www.youtube.com/watch?v=4L12BP64AQM > > :-) > > Great work Matthew (whose work I've adapted to make this work). You > pretty much nailed it, although I've changed the musical representation > a little and I feel there's a tad more to do to make it child-friendly > and familiar given other music representation systems on the computer. > > Damien, please find attached two scripts: > > The first script, bach.py, is what is flashed onto the device in the > demo. When I connect to the REPL I get this... > > >>> dir() > Traceback (most recent call last): > File "", line 1 > MemoryError: parser could not allocate enough memory > > I'm guessing we've run out of RAM. Given the code (and my lack of > experience writing for embedded platforms with MicroPython) any hints on > what I could do? > > The second script, music.py, is essentially the same as the first but > with more of the music added to the notes list. When I try to flash the > device I see the following scrolling across the screen: > > memory allocation error > > I'm guessing the script is simply too big to compile given the 16k RAM > we have available..? > > Hey ho... I'm guessing this is a similar situation to David's pancake game. > > This is a GOOD THING for us to encounter. At the very worst we'll be > unable to do anything about it in a technical sense so will have a heads > up and time to get the messaging of such states correct so users have a > chance to work out what's going on. > > My feeling is that we could create a whole new music based namespace > under microbit (i.e. microbit.music) containing things like the > following made up off the top of my head in a hand-wavy sort of a way: > > microbit.music.Tune - based on Matthew's class demonstrated in the video > but implemented in C. > microbit.music.play('c', 1, 1000) - play the note C in octave 1 for 1 > second. > microbit.music.pitch(440, 1000) - play the pitch for 1 second. The play > method above is basically a friendly wrapper around this one. > microbit.music.stop() - what you'd expect ;-) > > The final millisecond argument to the play and pitch methods could be > optional (the device just keeps playing the note until it's changed). We > could then use the accelerometer to change the pitch etc... > > Also, we could use the wait keyword as Damien suggested with the display > methods to make musical things run in the background. > > Does this make sense..? > > As always, ideas, constructive critique and feedback is most welcome! > > All the best, > > 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 Thu Sep 24 00:45:21 2015 From: damien.p.george at gmail.com (Damien George) Date: Wed, 23 Sep 2015 23:45:21 +0100 Subject: [Microbit-Python] J.S.MicroBach In-Reply-To: References: <56030EB9.4010401@ntoll.org> Message-ID: Hi Nicholas, I did a bit of coding and managed to reduce the parser RAM usage by around 30%. So now your bach.py works fine and you can dir() at the REPL. music.py still has memory issues, but it's no longer in the compiler. It's the fact that you have 3 big lists containing the tune: the first is the one in the script, the second is the one that the first is expanded to (with note, octave and duration) and the third is the notes list in the Tune object. I've adjusted the script so that it plays the tune directly from the list in the script (so only has one big list). See attached. It works very well and the tune is awesome! I love the beepy-bloopy sound. BTW, you'll need to git pull and recompile the firmware to take advantage of the new RAM improvements. Cheers, Damien. On Wed, Sep 23, 2015 at 11:33 PM, Michael wrote: > That's *really* fun :-) > > > Michael. > > On 23 September 2015 at 21:42, Nicholas H.Tollervey wrote: >> >> Hi Folks, >> >> So it's not exactly amazing quality sound... in fact, I've basically >> made one of those bloody annoying bloopy-bleep-bleep birthday cards, but >> this: >> >> https://www.youtube.com/watch?v=4L12BP64AQM >> >> :-) >> >> Great work Matthew (whose work I've adapted to make this work). You >> pretty much nailed it, although I've changed the musical representation >> a little and I feel there's a tad more to do to make it child-friendly >> and familiar given other music representation systems on the computer. >> >> Damien, please find attached two scripts: >> >> The first script, bach.py, is what is flashed onto the device in the >> demo. When I connect to the REPL I get this... >> >> >>> dir() >> Traceback (most recent call last): >> File "", line 1 >> MemoryError: parser could not allocate enough memory >> >> I'm guessing we've run out of RAM. Given the code (and my lack of >> experience writing for embedded platforms with MicroPython) any hints on >> what I could do? >> >> The second script, music.py, is essentially the same as the first but >> with more of the music added to the notes list. When I try to flash the >> device I see the following scrolling across the screen: >> >> memory allocation error >> >> I'm guessing the script is simply too big to compile given the 16k RAM >> we have available..? >> >> Hey ho... I'm guessing this is a similar situation to David's pancake >> game. >> >> This is a GOOD THING for us to encounter. At the very worst we'll be >> unable to do anything about it in a technical sense so will have a heads >> up and time to get the messaging of such states correct so users have a >> chance to work out what's going on. >> >> My feeling is that we could create a whole new music based namespace >> under microbit (i.e. microbit.music) containing things like the >> following made up off the top of my head in a hand-wavy sort of a way: >> >> microbit.music.Tune - based on Matthew's class demonstrated in the video >> but implemented in C. >> microbit.music.play('c', 1, 1000) - play the note C in octave 1 for 1 >> second. >> microbit.music.pitch(440, 1000) - play the pitch for 1 second. The play >> method above is basically a friendly wrapper around this one. >> microbit.music.stop() - what you'd expect ;-) >> >> The final millisecond argument to the play and pitch methods could be >> optional (the device just keeps playing the note until it's changed). We >> could then use the accelerometer to change the pitch etc... >> >> Also, we could use the wait keyword as Damien suggested with the display >> methods to make musical things run in the background. >> >> Does this make sense..? >> >> As always, ideas, constructive critique and feedback is most welcome! >> >> All the best, >> >> 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: music.py Type: text/x-python Size: 3284 bytes Desc: not available URL: From ntoll at ntoll.org Thu Sep 24 10:34:39 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Thu, 24 Sep 2015 09:34:39 +0100 Subject: [Microbit-Python] J.S.MicroBach In-Reply-To: References: <56030EB9.4010401@ntoll.org> Message-ID: <5603B59F.4060601@ntoll.org> Hi Damien, :-) On 23/09/15 23:45, Damien George wrote: > Hi Nicholas, > > I did a bit of coding and managed to reduce the parser RAM usage by > around 30%. So now your bach.py works fine and you can dir() at the > REPL. > Yes, but far more important are the comments you make below regarding taking up memory with large data structures. > music.py still has memory issues, but it's no longer in the compiler. > It's the fact that you have 3 big lists containing the tune: the first > is the one in the script, the second is the one that the first is > expanded to (with note, octave and duration) and the third is the > notes list in the Tune object. > Exactly... I imagined it would be something like this. It's good to encounter these problems because you get to feel what it's like to program in such a memory constrained environment. > I've adjusted the script so that it plays the tune directly from the > list in the script (so only has one big list). See attached. It > works very well and the tune is awesome! I love the beepy-bloopy > sound. > Yeah... the version I'll use this afternoon has more of the piece added to the end. > BTW, you'll need to git pull and recompile the firmware to take > advantage of the new RAM improvements. > Done. Cheers, N. > Cheers, > Damien. > > > On Wed, Sep 23, 2015 at 11:33 PM, Michael wrote: >> That's *really* fun :-) >> >> >> Michael. >> >> On 23 September 2015 at 21:42, Nicholas H.Tollervey wrote: >>> >>> Hi Folks, >>> >>> So it's not exactly amazing quality sound... in fact, I've basically >>> made one of those bloody annoying bloopy-bleep-bleep birthday cards, but >>> this: >>> >>> https://www.youtube.com/watch?v=4L12BP64AQM >>> >>> :-) >>> >>> Great work Matthew (whose work I've adapted to make this work). You >>> pretty much nailed it, although I've changed the musical representation >>> a little and I feel there's a tad more to do to make it child-friendly >>> and familiar given other music representation systems on the computer. >>> >>> Damien, please find attached two scripts: >>> >>> The first script, bach.py, is what is flashed onto the device in the >>> demo. When I connect to the REPL I get this... >>> >>>>>> dir() >>> Traceback (most recent call last): >>> File "", line 1 >>> MemoryError: parser could not allocate enough memory >>> >>> I'm guessing we've run out of RAM. Given the code (and my lack of >>> experience writing for embedded platforms with MicroPython) any hints on >>> what I could do? >>> >>> The second script, music.py, is essentially the same as the first but >>> with more of the music added to the notes list. When I try to flash the >>> device I see the following scrolling across the screen: >>> >>> memory allocation error >>> >>> I'm guessing the script is simply too big to compile given the 16k RAM >>> we have available..? >>> >>> Hey ho... I'm guessing this is a similar situation to David's pancake >>> game. >>> >>> This is a GOOD THING for us to encounter. At the very worst we'll be >>> unable to do anything about it in a technical sense so will have a heads >>> up and time to get the messaging of such states correct so users have a >>> chance to work out what's going on. >>> >>> My feeling is that we could create a whole new music based namespace >>> under microbit (i.e. microbit.music) containing things like the >>> following made up off the top of my head in a hand-wavy sort of a way: >>> >>> microbit.music.Tune - based on Matthew's class demonstrated in the video >>> but implemented in C. >>> microbit.music.play('c', 1, 1000) - play the note C in octave 1 for 1 >>> second. >>> microbit.music.pitch(440, 1000) - play the pitch for 1 second. The play >>> method above is basically a friendly wrapper around this one. >>> microbit.music.stop() - what you'd expect ;-) >>> >>> The final millisecond argument to the play and pitch methods could be >>> optional (the device just keeps playing the note until it's changed). We >>> could then use the accelerometer to change the pitch etc... >>> >>> Also, we could use the wait keyword as Damien suggested with the display >>> methods to make musical things run in the background. >>> >>> Does this make sense..? >>> >>> As always, ideas, constructive critique and feedback is most welcome! >>> >>> All the best, >>> >>> 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From larry at hastings.org Thu Sep 24 15:17:17 2015 From: larry at hastings.org (Larry Hastings) Date: Thu, 24 Sep 2015 14:17:17 +0100 Subject: [Microbit-Python] error code?... :(020 In-Reply-To: References: <5600616A.2000107@ntoll.org> <56013703.80902@hastings.org> <56014B5B.40606@hastings.org> <56016A83.10202@hastings.org> Message-ID: <5603F7DD.1030407@hastings.org> I wish to understand this more. Micropython has an internal, hidden-from-view, event queue? How do I examine and interact with it? I thought button_a.is_pressed() was polling; is it watching for button events on this event queue? Does that imply that I can get delayed / buffered button presses? In general how do I keep the event queue from filling? //arry/ On 09/23/2015 01:54 PM, Damien George wrote: > Hi Alan, > > Error code 020 is "out of memory". > > The problem is as you guessed: there is an event put on the event > queue each time the button is pressed. To clear this queue your code > needs to "yield". You can do this by putting sleep(1) in your loop. > > This is totally unexpected behaviour and I'll work out how to fix it > (Ie your code should just work). > > Cheers, > Damien. > > > > On Wed, Sep 23, 2015 at 4:02 AM, Alan wrote: >> Error code update. >> >> I'm consistently getting the ":( 020" code after 42 button presses (of any >> combination of buttons A and B). >> >> Is there a button click buffer that's overflowing somewhere? If there is I >> can't see a method on the microbit API to clear it. >> >> Cheers, >> >> Alan >> >> ________________________________ >> From: alainjackson at hotmail.com >> To: microbit at python.org >> Date: Wed, 23 Sep 2015 00:28:51 +0000 >> Subject: [Microbit-Python] error code?... :(020 >> >> >> Hi, >> >> I wrote a small program to draw on the LED matrix, but after setting a few >> LEDs on I get what looks like an error message on the LEDs: >> >> ":(020" >> >> (Frowny-face zero two zero) >> >> It just keeps repeating that and my program stops but there's no stack trace >> on the python repl. >> >> Is that a built in hardware error code or something? Has anyone else seen >> that? >> >> Here's my program: >> >> ====8<==== >> >> from microbit import * >> >> index = 0 >> >> while True: >> if button_a.is_pressed(): >> x = index % 5 >> y = int(index / 5) >> display.image.set_pixel_value(x,y, >> not(display.image.get_pixel_value(x,y))) >> >> if button_b.is_pressed(): >> index = (index + 1) % 25 >> >> _______________________________________________ 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 larry at hastings.org Thu Sep 24 15:15:14 2015 From: larry at hastings.org (Larry Hastings) Date: Thu, 24 Sep 2015 14:15:14 +0100 Subject: [Microbit-Python] The all-seeing British airport security Message-ID: <5603F762.1060900@hastings.org> I'm now in the secured area, having checked in for my flight home. They pulled my rolly bag to go through it item by item. One of the few things they didn't bother to pull out? The partially-collapsed Costa coffee cup containing my Microbit. Next stop: America's vast reverse-engineering complex, where I will be paid a handsome bounty by Mr. Slugworth for this device, the creme of British engineering! Shhhhh, //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ntoll at ntoll.org Thu Sep 24 22:49:18 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Thu, 24 Sep 2015 21:49:18 +0100 Subject: [Microbit-Python] The all-seeing British airport security In-Reply-To: <5603F762.1060900@hastings.org> References: <5603F762.1060900@hastings.org> Message-ID: <560461CE.20104@ntoll.org> Larry, I really hope this is a joke..! I can't stress how stressed both I and the BBC are about the device being given away. 8-O N. On 24/09/15 14:15, Larry Hastings wrote: > > > I'm now in the secured area, having checked in for my flight home. They > pulled my rolly bag to go through it item by item. One of the few > things they didn't bother to pull out? The partially-collapsed Costa > coffee cup containing my Microbit. Next stop: America's vast > reverse-engineering complex, where I will be paid a handsome bounty by > Mr. Slugworth for this device, the creme of British engineering! > > Shhhhh, > > > //arry/ > > > _______________________________________________ > 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 sparks.m at gmail.com Thu Sep 24 22:59:30 2015 From: sparks.m at gmail.com (Michael) Date: Thu, 24 Sep 2015 21:59:30 +0100 Subject: [Microbit-Python] The all-seeing British airport security In-Reply-To: <560461CE.20104@ntoll.org> References: <5603F762.1060900@hastings.org> <560461CE.20104@ntoll.org> Message-ID: I'm sure it is. Very much reads that way to me :-) That said, I really like the idea of there being 5 golden tickets included in a selection of the devices shipped out, and then something cool happening as a result. :-) Michael. On 24 September 2015 at 21:49, Nicholas H.Tollervey wrote: > Larry, > > I really hope this is a joke..! I can't stress how stressed both I and > the BBC are about the device being given away. > > 8-O > > N. > > On 24/09/15 14:15, Larry Hastings wrote: > > > > > > I'm now in the secured area, having checked in for my flight home. They > > pulled my rolly bag to go through it item by item. One of the few > > things they didn't bother to pull out? The partially-collapsed Costa > > coffee cup containing my Microbit. Next stop: America's vast > > reverse-engineering complex, where I will be paid a handsome bounty by > > Mr. Slugworth for this device, the creme of British engineering! > > > > Shhhhh, > > > > > > //arry/ > > > > > > _______________________________________________ > > 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 Thu Sep 24 23:12:01 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Thu, 24 Sep 2015 22:12:01 +0100 Subject: [Microbit-Python] My visit to the BBC today Message-ID: <56046721.80508@ntoll.org> Hi Folks, So I demoed MicroPython to quite a full room of BBC people and other partners in the project today. It seemed to go quite well and people were positive about the work done so far. Happily, I spent some time chatting with Fiona and Jo in an effort to get the BBC to see our PoV about openness and I think I made progress. It is my hope that we will be able to work "in the open" soon - although it won't include the DAL library we rely on. The music got a round of applause. Well done Matthew! :-) I even had someone in charge of the launch event come over and chat to me asking what the musical capabilities of the device might be. I told her anything is possible with Python, but it mainly depends on how big a moon you want on that stick in the given time frame. :-) 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 sparks.m at gmail.com Thu Sep 24 23:23:26 2015 From: sparks.m at gmail.com (Michael) Date: Thu, 24 Sep 2015 22:23:26 +0100 Subject: [Microbit-Python] My visit to the BBC today In-Reply-To: <56046721.80508@ntoll.org> References: <56046721.80508@ntoll.org> Message-ID: That's no moon... Michael. (all good news BTW :-) On 24 September 2015 at 22:12, Nicholas H.Tollervey wrote: > Hi Folks, > > So I demoed MicroPython to quite a full room of BBC people and other > partners in the project today. It seemed to go quite well and people > were positive about the work done so far. > > Happily, I spent some time chatting with Fiona and Jo in an effort to > get the BBC to see our PoV about openness and I think I made progress. > It is my hope that we will be able to work "in the open" soon - although > it won't include the DAL library we rely on. > > The music got a round of applause. Well done Matthew! :-) > > I even had someone in charge of the launch event come over and chat to > me asking what the musical capabilities of the device might be. I told > her anything is possible with Python, but it mainly depends on how big a > moon you want on that stick in the given time frame. > > :-) > > N. > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewelse1997 at gmail.com Thu Sep 24 23:48:26 2015 From: matthewelse1997 at gmail.com (Matthew Else) Date: Thu, 24 Sep 2015 21:48:26 +0000 Subject: [Microbit-Python] My visit to the BBC today In-Reply-To: References: <56046721.80508@ntoll.org> Message-ID: I'm happy to look at what sort of interesting things we can do with music - are there any things in particular that they want it to do? On Thu, 24 Sep 2015 at 22:23, Michael wrote: > That's no moon... > > Michael. > > (all good news BTW :-) > > On 24 September 2015 at 22:12, Nicholas H.Tollervey > wrote: > >> Hi Folks, >> >> So I demoed MicroPython to quite a full room of BBC people and other >> partners in the project today. It seemed to go quite well and people >> were positive about the work done so far. >> >> Happily, I spent some time chatting with Fiona and Jo in an effort to >> get the BBC to see our PoV about openness and I think I made progress. >> It is my hope that we will be able to work "in the open" soon - although >> it won't include the DAL library we rely on. >> >> The music got a round of applause. Well done Matthew! :-) >> >> I even had someone in charge of the launch event come over and chat to >> me asking what the musical capabilities of the device might be. I told >> her anything is possible with Python, but it mainly depends on how big a >> moon you want on that stick in the given time frame. >> >> :-) >> >> N. >> >> >> _______________________________________________ >> 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 damien.p.george at gmail.com Fri Sep 25 00:02:22 2015 From: damien.p.george at gmail.com (Damien George) Date: Thu, 24 Sep 2015 23:02:22 +0100 Subject: [Microbit-Python] My visit to the BBC today In-Reply-To: References: <56046721.80508@ntoll.org> Message-ID: Sounds good Nicholas, thanks for being our champion! BTW, I saw that Python now has a "coming soon" button at microbit.co.uk. On Thu, Sep 24, 2015 at 10:48 PM, Matthew Else wrote: > I'm happy to look at what sort of interesting things we can do with music - > are there any things in particular that they want it to do? > > On Thu, 24 Sep 2015 at 22:23, Michael wrote: >> >> That's no moon... >> >> Michael. >> >> (all good news BTW :-) >> >> On 24 September 2015 at 22:12, Nicholas H.Tollervey >> wrote: >>> >>> Hi Folks, >>> >>> So I demoed MicroPython to quite a full room of BBC people and other >>> partners in the project today. It seemed to go quite well and people >>> were positive about the work done so far. >>> >>> Happily, I spent some time chatting with Fiona and Jo in an effort to >>> get the BBC to see our PoV about openness and I think I made progress. >>> It is my hope that we will be able to work "in the open" soon - although >>> it won't include the DAL library we rely on. >>> >>> The music got a round of applause. Well done Matthew! :-) >>> >>> I even had someone in charge of the launch event come over and chat to >>> me asking what the musical capabilities of the device might be. I told >>> her anything is possible with Python, but it mainly depends on how big a >>> moon you want on that stick in the given time frame. >>> >>> :-) >>> >>> N. >>> >>> >>> _______________________________________________ >>> 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 > From david at thinkingbinaries.com Fri Sep 25 00:07:51 2015 From: david at thinkingbinaries.com (David Whale) Date: Thu, 24 Sep 2015 23:07:51 +0100 Subject: [Microbit-Python] My visit to the BBC today In-Reply-To: References: <56046721.80508@ntoll.org> Message-ID: It was indeed an awesome demo Nicholas - well done all! 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 24 September 2015 at 22:23, Michael wrote: > That's no moon... > > Michael. > > (all good news BTW :-) > > On 24 September 2015 at 22:12, Nicholas H.Tollervey > wrote: > >> Hi Folks, >> >> So I demoed MicroPython to quite a full room of BBC people and other >> partners in the project today. It seemed to go quite well and people >> were positive about the work done so far. >> >> Happily, I spent some time chatting with Fiona and Jo in an effort to >> get the BBC to see our PoV about openness and I think I made progress. >> It is my hope that we will be able to work "in the open" soon - although >> it won't include the DAL library we rely on. >> >> The music got a round of applause. Well done Matthew! :-) >> >> I even had someone in charge of the launch event come over and chat to >> me asking what the musical capabilities of the device might be. I told >> her anything is possible with Python, but it mainly depends on how big a >> moon you want on that stick in the given time frame. >> >> :-) >> >> N. >> >> >> _______________________________________________ >> 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 Fri Sep 25 00:33:26 2015 From: david at thinkingbinaries.com (David Whale) Date: Thu, 24 Sep 2015 23:33:26 +0100 Subject: [Microbit-Python] My visit to the BBC today In-Reply-To: References: <56046721.80508@ntoll.org> Message-ID: Just some random thoughts.... Background music would be awesome (in the same way that Damien has surfaced background animations). I reckon if you could find a way to use the internal fibre scheduling safely, you could have 3 channels running, one on each pin, and "externally mix them" with resistors or capacitors into a single speaker. This would give you 3 channel sound just like the original AY-3-8910 chip on the BBC Micro!!! My ultimate test here would be to play "Eurythmics: Sweet dreams are made of this" and "Stranglers:Golden Brown" in the same arrangements as the original ones done on the BBC micro!!! The other thing that would be cool is an external tool that converts a MIDI file into the python data structures that plays that same music. That would then be a really easy way to bring in other pieces, as there are plenty of MIDI editors and sources of MIDI on the internet. Envelopes - the AY-3-8910 on the beeb had ADSR envelopes. You loaded 4 numbers into registers and it did the attack, delay, sustain and release for you automatically, and this made it possible to do really nice phrasing and expression. The touch sensing works great now - how about something akin to the new PiPiano that Pimoroni made for the Pi based on Zachs original Pi Piano??? All of these are a *bit* 1980's demo (Nicholas will understand that quote!) There is a really awesome opportunity to implement MIDI or OSC support for linking to external devices and using the MicroBit as the programmable sequencer or controller for them. Python support for either in some way would be a "game changer" (not my words, someone else's words!) - think micro:bit gestures controlling an external soft MIDI synth on a bigger computer. Think linking that to DMX lighting and controlling the school stage lights with it too in sync with the music - the micro:bit as a performance device! Just random ideas. Shoot them down. 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 24 September 2015 at 23:07, David Whale wrote: > It was indeed an awesome demo Nicholas - well done all! > > 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 24 September 2015 at 22:23, Michael wrote: > >> That's no moon... >> >> Michael. >> >> (all good news BTW :-) >> >> On 24 September 2015 at 22:12, Nicholas H.Tollervey >> wrote: >> >>> Hi Folks, >>> >>> So I demoed MicroPython to quite a full room of BBC people and other >>> partners in the project today. It seemed to go quite well and people >>> were positive about the work done so far. >>> >>> Happily, I spent some time chatting with Fiona and Jo in an effort to >>> get the BBC to see our PoV about openness and I think I made progress. >>> It is my hope that we will be able to work "in the open" soon - although >>> it won't include the DAL library we rely on. >>> >>> The music got a round of applause. Well done Matthew! :-) >>> >>> I even had someone in charge of the launch event come over and chat to >>> me asking what the musical capabilities of the device might be. I told >>> her anything is possible with Python, but it mainly depends on how big a >>> moon you want on that stick in the given time frame. >>> >>> :-) >>> >>> N. >>> >>> >>> _______________________________________________ >>> 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 matthewelse1997 at gmail.com Fri Sep 25 00:36:13 2015 From: matthewelse1997 at gmail.com (Matthew Else) Date: Thu, 24 Sep 2015 22:36:13 +0000 Subject: [Microbit-Python] My visit to the BBC today In-Reply-To: References: <56046721.80508@ntoll.org> Message-ID: I have a tonne of free time so I'll have a stab at this! On Thu, 24 Sep 2015 at 23:33, David Whale wrote: > Just some random thoughts.... > > Background music would be awesome (in the same way that Damien has > surfaced background animations). > > I reckon if you could find a way to use the internal fibre scheduling > safely, you could have 3 channels running, one on each pin, and "externally > mix them" with resistors or capacitors into a single speaker. This would > give you 3 channel sound just like the original AY-3-8910 chip on the BBC > Micro!!! My ultimate test here would be to play "Eurythmics: Sweet dreams > are made of this" and "Stranglers:Golden Brown" in the same arrangements as > the original ones done on the BBC micro!!! > > The other thing that would be cool is an external tool that converts a > MIDI file into the python data structures that plays that same music. That > would then be a really easy way to bring in other pieces, as there are > plenty of MIDI editors and sources of MIDI on the internet. > > Envelopes - the AY-3-8910 on the beeb had ADSR envelopes. You loaded 4 > numbers into registers and it did the attack, delay, sustain and release > for you automatically, and this made it possible to do really nice phrasing > and expression. > > The touch sensing works great now - how about something akin to the new > PiPiano that Pimoroni made for the Pi based on Zachs original Pi Piano??? > > All of these are a *bit* 1980's demo (Nicholas will understand that quote!) > > There is a really awesome opportunity to implement MIDI or OSC support for > linking to external devices and using the MicroBit as the programmable > sequencer or controller for them. Python support for either in some way > would be a "game changer" (not my words, someone else's words!) - think > micro:bit gestures controlling an external soft MIDI synth on a bigger > computer. Think linking that to DMX lighting and controlling the school > stage lights with it too in sync with the music - the micro:bit as a > performance device! > > Just random ideas. Shoot them down. > > 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 24 September 2015 at 23:07, David Whale > wrote: > >> It was indeed an awesome demo Nicholas - well done all! >> >> 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 24 September 2015 at 22:23, Michael wrote: >> >>> That's no moon... >>> >>> Michael. >>> >>> (all good news BTW :-) >>> >>> On 24 September 2015 at 22:12, Nicholas H.Tollervey >>> wrote: >>> >>>> Hi Folks, >>>> >>>> So I demoed MicroPython to quite a full room of BBC people and other >>>> partners in the project today. It seemed to go quite well and people >>>> were positive about the work done so far. >>>> >>>> Happily, I spent some time chatting with Fiona and Jo in an effort to >>>> get the BBC to see our PoV about openness and I think I made progress. >>>> It is my hope that we will be able to work "in the open" soon - although >>>> it won't include the DAL library we rely on. >>>> >>>> The music got a round of applause. Well done Matthew! :-) >>>> >>>> I even had someone in charge of the launch event come over and chat to >>>> me asking what the musical capabilities of the device might be. I told >>>> her anything is possible with Python, but it mainly depends on how big a >>>> moon you want on that stick in the given time frame. >>>> >>>> :-) >>>> >>>> N. >>>> >>>> >>>> _______________________________________________ >>>> 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 alainjackson at hotmail.com Fri Sep 25 03:09:25 2015 From: alainjackson at hotmail.com (Alan) Date: Fri, 25 Sep 2015 01:09:25 +0000 Subject: [Microbit-Python] error code?... :(020 In-Reply-To: <5603F7DD.1030407@hastings.org> References: <5600616A.2000107@ntoll.org>, , , <56013703.80902@hastings.org>, , <56014B5B.40606@hastings.org>, , <56016A83.10202@hastings.org>, , , , , , , <5603F7DD.1030407@hastings.org> Message-ID: I've just been writing myself an event queue for button pushes etc... maybe that's not necessary if there already is one, if it's accessible. Cheers, Alan To: microbit at python.org From: larry at hastings.org Date: Thu, 24 Sep 2015 14:17:17 +0100 Subject: Re: [Microbit-Python] error code?... :(020 I wish to understand this more. Micropython has an internal, hidden-from-view, event queue? How do I examine and interact with it? I thought button_a.is_pressed() was polling; is it watching for button events on this event queue? Does that imply that I can get delayed / buffered button presses? In general how do I keep the event queue from filling? /arry On 09/23/2015 01:54 PM, Damien George wrote: Hi Alan, Error code 020 is "out of memory". The problem is as you guessed: there is an event put on the event queue each time the button is pressed. To clear this queue your code needs to "yield". You can do this by putting sleep(1) in your loop. This is totally unexpected behaviour and I'll work out how to fix it (Ie your code should just work). Cheers, Damien. On Wed, Sep 23, 2015 at 4:02 AM, Alan wrote: Error code update. I'm consistently getting the ":( 020" code after 42 button presses (of any combination of buttons A and B). Is there a button click buffer that's overflowing somewhere? If there is I can't see a method on the microbit API to clear it. Cheers, Alan ________________________________ From: alainjackson at hotmail.com To: microbit at python.org Date: Wed, 23 Sep 2015 00:28:51 +0000 Subject: [Microbit-Python] error code?... :(020 Hi, I wrote a small program to draw on the LED matrix, but after setting a few LEDs on I get what looks like an error message on the LEDs: ":(020" (Frowny-face zero two zero) It just keeps repeating that and my program stops but there's no stack trace on the python repl. Is that a built in hardware error code or something? Has anyone else seen that? Here's my program: ====8<==== from microbit import * index = 0 while True: if button_a.is_pressed(): x = index % 5 y = int(index / 5) display.image.set_pixel_value(x,y, not(display.image.get_pixel_value(x,y))) if button_b.is_pressed(): index = (index + 1) % 25 _______________________________________________ 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 larry at hastings.org Fri Sep 25 04:40:11 2015 From: larry at hastings.org (Larry Hastings) Date: Thu, 24 Sep 2015 19:40:11 -0700 Subject: [Microbit-Python] The all-seeing British airport security In-Reply-To: References: <5603F762.1060900@hastings.org> <560461CE.20104@ntoll.org> Message-ID: <5604B40B.9070302@hastings.org> Just to be clear: yes, this was a joke. If the non-existant "America's vast reverse-engineering complex" wasn't enough of a clue, I'd hoped the namedrop of Mr. Slugworth would put it over the edge. Mr. Slugworth, for those of you who don't remember their Dahl, was a rival candymaker in "Charlie And The Chocolate Factory". He made such dubious-sounding confections as the "Slugworth Sizzler". In the 70s movie version, Slugworth appeared as a character, meeting the children in secret and bribing them to bring him an Everlasting Gobstopper so he might reverse-engineer it. Sorry to give Nicholas kittens; I would have replied sooner, but I was flying home from London to Seattle. //arry/ On 09/24/2015 01:59 PM, Michael wrote: > I'm sure it is. Very much reads that way to me :-) > > That said, I really like the idea of there being 5 golden tickets > included in a selection of the devices shipped out, and then something > cool happening as a result. > > :-) > > > Michael. > > On 24 September 2015 at 21:49, Nicholas H.Tollervey > wrote: > > Larry, > > I really hope this is a joke..! I can't stress how stressed both I and > the BBC are about the device being given away. > > 8-O > > N. > > On 24/09/15 14:15, Larry Hastings wrote: > > > > > > I'm now in the secured area, having checked in for my flight > home. They > > pulled my rolly bag to go through it item by item. One of the few > > things they didn't bother to pull out? The partially-collapsed > Costa > > coffee cup containing my Microbit. Next stop: America's vast > > reverse-engineering complex, where I will be paid a handsome > bounty by > > Mr. Slugworth for this device, the creme of British engineering! > > > > Shhhhh, > > > > > > //arry/ > > > > > > _______________________________________________ > > 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 larry at hastings.org Fri Sep 25 04:42:52 2015 From: larry at hastings.org (Larry Hastings) Date: Thu, 24 Sep 2015 19:42:52 -0700 Subject: [Microbit-Python] The all-seeing British airport security In-Reply-To: References: <5603F762.1060900@hastings.org> <560461CE.20104@ntoll.org> Message-ID: <5604B4AC.4050806@hastings.org> p.s. However, the bit about them not looking in the Costa cup, and me rolling with my Micro:bit through security--that part was true. Micro:bit and nerd are happily at home now. On 09/24/2015 01:59 PM, Michael wrote: > I'm sure it is. Very much reads that way to me :-) > > That said, I really like the idea of there being 5 golden tickets > included in a selection of the devices shipped out, and then something > cool happening as a result. > > :-) > > > Michael. > > On 24 September 2015 at 21:49, Nicholas H.Tollervey > wrote: > > Larry, > > I really hope this is a joke..! I can't stress how stressed both I and > the BBC are about the device being given away. > > 8-O > > N. > > On 24/09/15 14:15, Larry Hastings wrote: > > > > > > I'm now in the secured area, having checked in for my flight > home. They > > pulled my rolly bag to go through it item by item. One of the few > > things they didn't bother to pull out? The partially-collapsed > Costa > > coffee cup containing my Microbit. Next stop: America's vast > > reverse-engineering complex, where I will be paid a handsome > bounty by > > Mr. Slugworth for this device, the creme of British engineering! > > > > Shhhhh, > > > > > > //arry/ > > > > > > _______________________________________________ > > 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 Fri Sep 25 09:04:59 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Fri, 25 Sep 2015 08:04:59 +0100 Subject: [Microbit-Python] The all-seeing British airport security In-Reply-To: <5604B40B.9070302@hastings.org> References: <5603F762.1060900@hastings.org> <560461CE.20104@ntoll.org> <5604B40B.9070302@hastings.org> Message-ID: <5604F21B.1090303@ntoll.org> What a relief. ;-) Not sure BBC lawyers read Dahl - it's just they're very Very VERY touchy about precisely the situation that was joked about and they're always keen to impress this upon partner representatives like me. My concern was rather selfish - the joke was a potential flurry of emails with the BBC that I really didn't fancy having to deal with. ;-) Just to be clear - jokes are GOOD!!!! For the record, my reaction was: * "Hahahahahaha, Larry's a card" * "Oh shit, people from the BBC are on this list" * "ZOMG I really don't want to have to spend time explaining Slugworth to cover our arses" * "Arghhhh MUST SEND EMAIL" :-) Phew... and thanks for your patience..! N. On 25/09/15 03:40, Larry Hastings wrote: > > > Just to be clear: yes, this was a joke. If the non-existant "America's > vast reverse-engineering complex" wasn't enough of a clue, I'd hoped the > namedrop of Mr. Slugworth would put it over the edge. Mr. Slugworth, > for those of you who don't remember their Dahl, was a rival candymaker > in "Charlie And The Chocolate Factory". He made such dubious-sounding > confections as the "Slugworth Sizzler". In the 70s movie version, > Slugworth appeared as a character, meeting the children in secret and > bribing them to bring him an Everlasting Gobstopper so he might > reverse-engineer it. > > Sorry to give Nicholas kittens; I would have replied sooner, but I was > flying home from London to Seattle. > > > //arry/ > > On 09/24/2015 01:59 PM, Michael wrote: >> I'm sure it is. Very much reads that way to me :-) >> >> That said, I really like the idea of there being 5 golden tickets >> included in a selection of the devices shipped out, and then something >> cool happening as a result. >> >> :-) >> >> >> Michael. >> >> On 24 September 2015 at 21:49, Nicholas H.Tollervey > > wrote: >> >> Larry, >> >> I really hope this is a joke..! I can't stress how stressed both I and >> the BBC are about the device being given away. >> >> 8-O >> >> N. >> >> On 24/09/15 14:15, Larry Hastings wrote: >> > >> > >> > I'm now in the secured area, having checked in for my flight >> home. They >> > pulled my rolly bag to go through it item by item. One of the few >> > things they didn't bother to pull out? The partially-collapsed >> Costa >> > coffee cup containing my Microbit. Next stop: America's vast >> > reverse-engineering complex, where I will be paid a handsome >> bounty by >> > Mr. Slugworth for this device, the creme of British engineering! >> > >> > Shhhhh, >> > >> > >> > //arry/ >> > >> > >> > _______________________________________________ >> > 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 ntoll at ntoll.org Fri Sep 25 10:19:44 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Fri, 25 Sep 2015 09:19:44 +0100 Subject: [Microbit-Python] My visit to the BBC today In-Reply-To: References: <56046721.80508@ntoll.org> Message-ID: <560503A0.5080909@ntoll.org> Hi, Comments in-line... On 24/09/15 23:33, David Whale wrote: > Just some random thoughts.... > > Background music would be awesome (in the same way that Damien has > surfaced background animations). > +1 > I reckon if you could find a way to use the internal fibre scheduling > safely, you could have 3 channels running, one on each pin, and > "externally mix them" with resistors or capacitors into a single > speaker. This would give you 3 channel sound just like the original > AY-3-8910 chip on the BBC Micro!!! My ultimate test here would be to > play "Eurythmics: Sweet dreams are made of this" and "Stranglers:Golden > Brown" in the same arrangements as the original ones done on the BBC > micro!!! > Hahahaha... you had those programs too..? Did you also have the Bach Toccata and Fugue (another piece of musical programming amazement)..? > The other thing that would be cool is an external tool that converts a > MIDI file into the python data structures that plays that same music. > That would then be a really easy way to bring in other pieces, as there > are plenty of MIDI editors and sources of MIDI on the internet. > MIDI is a very simple standard. IIRC it's just channels (giving you instruments) along with numbers representing pitches and an offset so stuff gets played at the correct time. > Envelopes - the AY-3-8910 on the beeb had ADSR envelopes. You loaded 4 > numbers into registers and it did the attack, delay, sustain and release > for you automatically, and this made it possible to do really nice > phrasing and expression. > I remember those. Combined with the "noise" channel (0) you could get some interesting effects. > The touch sensing works great now - how about something akin to the new > PiPiano that Pimoroni made for the Pi based on Zachs original Pi Piano??? > > All of these are a *bit* 1980's demo (Nicholas will understand that quote!) > Nothing wrong with the 1980s (well, the good bits of the 1980s)... ;-) > There is a really awesome opportunity to implement MIDI or OSC support > for linking to external devices and using the MicroBit as the > programmable sequencer or controller for them. Python support for either > in some way would be a "game changer" (not my words, someone else's > words!) - think micro:bit gestures controlling an external soft MIDI > synth on a bigger computer. Think linking that to DMX lighting and > controlling the school stage lights with it too in sync with the music - > the micro:bit as a performance device! > EXACTLY! That's where I'm going with this... > Just random ideas. Shoot them down. > > D > Far better to make them fly! ;-) 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 david at thinkingbinaries.com Fri Sep 25 11:19:19 2015 From: david at thinkingbinaries.com (David Whale) Date: Fri, 25 Sep 2015 10:19:19 +0100 Subject: [Microbit-Python] The all-seeing British airport security In-Reply-To: <5604F21B.1090303@ntoll.org> References: <5603F762.1060900@hastings.org> <560461CE.20104@ntoll.org> <5604B40B.9070302@hastings.org> <5604F21B.1090303@ntoll.org> Message-ID: Don't muck about guys. You have no idea what we've all gone through to make this happen and get extra devices. personally I've been in a logistics nightmare for weeks sharing devices with geographically diverse members of my team. If you can't be and can't act 100% responsible, please leave the team. If you can be, then please be awesome and muck in and follow the guidance of Nicholas. Thanks. End of. Sent from my new HTC On Sep 25, 2015 8:04 AM, "Nicholas H.Tollervey" wrote: > What a relief. ;-) > > Not sure BBC lawyers read Dahl - it's just they're very Very VERY touchy > about precisely the situation that was joked about and they're always > keen to impress this upon partner representatives like me. > > My concern was rather selfish - the joke was a potential flurry of > emails with the BBC that I really didn't fancy having to deal with. ;-) > > Just to be clear - jokes are GOOD!!!! For the record, my reaction was: > > * "Hahahahahaha, Larry's a card" > * "Oh shit, people from the BBC are on this list" > * "ZOMG I really don't want to have to spend time explaining Slugworth > to cover our arses" > * "Arghhhh MUST SEND EMAIL" > > :-) > > Phew... and thanks for your patience..! > > N. > > > On 25/09/15 03:40, Larry Hastings wrote: > > > > > > Just to be clear: yes, this was a joke. If the non-existant "America's > > vast reverse-engineering complex" wasn't enough of a clue, I'd hoped the > > namedrop of Mr. Slugworth would put it over the edge. Mr. Slugworth, > > for those of you who don't remember their Dahl, was a rival candymaker > > in "Charlie And The Chocolate Factory". He made such dubious-sounding > > confections as the "Slugworth Sizzler". In the 70s movie version, > > Slugworth appeared as a character, meeting the children in secret and > > bribing them to bring him an Everlasting Gobstopper so he might > > reverse-engineer it. > > > > Sorry to give Nicholas kittens; I would have replied sooner, but I was > > flying home from London to Seattle. > > > > > > //arry/ > > > > On 09/24/2015 01:59 PM, Michael wrote: > >> I'm sure it is. Very much reads that way to me :-) > >> > >> That said, I really like the idea of there being 5 golden tickets > >> included in a selection of the devices shipped out, and then something > >> cool happening as a result. > >> > >> :-) > >> > >> > >> Michael. > >> > >> On 24 September 2015 at 21:49, Nicholas H.Tollervey >> > wrote: > >> > >> Larry, > >> > >> I really hope this is a joke..! I can't stress how stressed both I > and > >> the BBC are about the device being given away. > >> > >> 8-O > >> > >> N. > >> > >> On 24/09/15 14:15, Larry Hastings wrote: > >> > > >> > > >> > I'm now in the secured area, having checked in for my flight > >> home. They > >> > pulled my rolly bag to go through it item by item. One of the few > >> > things they didn't bother to pull out? The partially-collapsed > >> Costa > >> > coffee cup containing my Microbit. Next stop: America's vast > >> > reverse-engineering complex, where I will be paid a handsome > >> bounty by > >> > Mr. Slugworth for this device, the creme of British engineering! > >> > > >> > Shhhhh, > >> > > >> > > >> > //arry/ > >> > > >> > > >> > _______________________________________________ > >> > 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 > > > > > > _______________________________________________ > 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 Fri Sep 25 11:29:41 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Fri, 25 Sep 2015 10:29:41 +0100 Subject: [Microbit-Python] Music things... please dive in! Message-ID: <56051405.1050402@ntoll.org> Issue on GitHub can be found here: https://github.com/dpgeorge/microbit-micropython/issues/31 Please dive in and discuss. I'm not precious and welcome constructive critique, feedback and ideas about anything I write (in both English and code). Knock yourselves out! As David mentioned - this could be an important differentiator / game changer for MicroPython on the micro:bit. :-) 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 Fri Sep 25 11:33:55 2015 From: mail at timgolden.me.uk (Tim Golden) Date: Fri, 25 Sep 2015 10:33:55 +0100 Subject: [Microbit-Python] Music things... please dive in! In-Reply-To: <56051405.1050402@ntoll.org> References: <56051405.1050402@ntoll.org> Message-ID: <56051503.1090109@timgolden.me.uk> Could I be added to that repo, please? (tjguk). It's showing up 404 for me, so I imagine it's a private repo to which I haven't been granted access. Thanks TJG On 25/09/2015 10:29, Nicholas H.Tollervey wrote: > Issue on GitHub can be found here: > > https://github.com/dpgeorge/microbit-micropython/issues/31 > > Please dive in and discuss. I'm not precious and welcome constructive > critique, feedback and ideas about anything I write (in both English and > code). Knock yourselves out! > > As David mentioned - this could be an important differentiator / game > changer for MicroPython on the micro:bit. > > :-) > > N. > > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > From ntoll at ntoll.org Fri Sep 25 11:36:16 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Fri, 25 Sep 2015 10:36:16 +0100 Subject: [Microbit-Python] Music things... please dive in! In-Reply-To: <56051503.1090109@timgolden.me.uk> References: <56051405.1050402@ntoll.org> <56051503.1090109@timgolden.me.uk> Message-ID: <56051590.9050707@ntoll.org> OK... so Damien will have to do that. I'll also ping Joe and James at Lancaster Uni to give you access to the device abstraction layer (DAL) that you'll need to build the code locally. N. On 25/09/15 10:33, Tim Golden wrote: > Could I be added to that repo, please? (tjguk). > > It's showing up 404 for me, so I imagine it's a private repo to which I > haven't been granted access. > > Thanks > > TJG > > On 25/09/2015 10:29, Nicholas H.Tollervey wrote: >> Issue on GitHub can be found here: >> >> https://github.com/dpgeorge/microbit-micropython/issues/31 >> >> Please dive in and discuss. I'm not precious and welcome constructive >> critique, feedback and ideas about anything I write (in both English and >> code). Knock yourselves out! >> >> As David mentioned - this could be an important differentiator / game >> changer for MicroPython on the micro:bit. >> >> :-) >> >> N. >> >> >> >> _______________________________________________ >> 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 mail at timgolden.me.uk Fri Sep 25 11:37:11 2015 From: mail at timgolden.me.uk (Tim Golden) Date: Fri, 25 Sep 2015 10:37:11 +0100 Subject: [Microbit-Python] Music things... please dive in! In-Reply-To: <56051590.9050707@ntoll.org> References: <56051405.1050402@ntoll.org> <56051503.1090109@timgolden.me.uk> <56051590.9050707@ntoll.org> Message-ID: <560515C7.7040503@timgolden.me.uk> Fairly sure I've got the DAL one (I got an invite the other day which I accepted). TJG On 25/09/2015 10:36, Nicholas H.Tollervey wrote: > OK... so Damien will have to do that. I'll also ping Joe and James at > Lancaster Uni to give you access to the device abstraction layer (DAL) > that you'll need to build the code locally. > > N. > > On 25/09/15 10:33, Tim Golden wrote: >> Could I be added to that repo, please? (tjguk). >> >> It's showing up 404 for me, so I imagine it's a private repo to which I >> haven't been granted access. >> >> Thanks >> >> TJG >> >> On 25/09/2015 10:29, Nicholas H.Tollervey wrote: >>> Issue on GitHub can be found here: >>> >>> https://github.com/dpgeorge/microbit-micropython/issues/31 >>> >>> Please dive in and discuss. I'm not precious and welcome constructive >>> critique, feedback and ideas about anything I write (in both English and >>> code). Knock yourselves out! >>> >>> As David mentioned - this could be an important differentiator / game >>> changer for MicroPython on the micro:bit. >>> >>> :-) >>> >>> N. >>> >>> >>> >>> _______________________________________________ >>> 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 > From ntoll at ntoll.org Fri Sep 25 11:39:57 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Fri, 25 Sep 2015 10:39:57 +0100 Subject: [Microbit-Python] Music things... please dive in! In-Reply-To: <560515C7.7040503@timgolden.me.uk> References: <56051405.1050402@ntoll.org> <56051503.1090109@timgolden.me.uk> <56051590.9050707@ntoll.org> <560515C7.7040503@timgolden.me.uk> Message-ID: <5605166D.9080606@ntoll.org> On 25/09/15 10:37, Tim Golden wrote: > Fairly sure I've got the DAL one (I got an invite the other day which I > accepted). > > TJG > If it's this one: https://github.com/lancaster-university/microbit-dal Then you're all set up (except for MicroPython). :-) 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 Fri Sep 25 11:42:03 2015 From: mail at timgolden.me.uk (Tim Golden) Date: Fri, 25 Sep 2015 10:42:03 +0100 Subject: [Microbit-Python] Music things... please dive in! In-Reply-To: <5605166D.9080606@ntoll.org> References: <56051405.1050402@ntoll.org> <56051503.1090109@timgolden.me.uk> <56051590.9050707@ntoll.org> <560515C7.7040503@timgolden.me.uk> <5605166D.9080606@ntoll.org> Message-ID: <560516EB.8030004@timgolden.me.uk> On 25/09/2015 10:39, Nicholas H.Tollervey wrote: > On 25/09/15 10:37, Tim Golden wrote: >> Fairly sure I've got the DAL one (I got an invite the other day which I >> accepted). >> >> TJG >> > > If it's this one: > > https://github.com/lancaster-university/microbit-dal > > Then you're all set up (except for MicroPython). Yep: I can see that TJG From mail at timgolden.me.uk Fri Sep 25 11:52:53 2015 From: mail at timgolden.me.uk (Tim Golden) Date: Fri, 25 Sep 2015 10:52:53 +0100 Subject: [Microbit-Python] Music things... please dive in! In-Reply-To: <56051590.9050707@ntoll.org> References: <56051405.1050402@ntoll.org> <56051503.1090109@timgolden.me.uk> <56051590.9050707@ntoll.org> Message-ID: <56051975.50501@timgolden.me.uk> Damien's now added me and I can see the microbit-micropython repo. Thanks, TJG On 25/09/2015 10:36, Nicholas H.Tollervey wrote: > OK... so Damien will have to do that. I'll also ping Joe and James at > Lancaster Uni to give you access to the device abstraction layer (DAL) > that you'll need to build the code locally. > > N. > > On 25/09/15 10:33, Tim Golden wrote: >> Could I be added to that repo, please? (tjguk). >> >> It's showing up 404 for me, so I imagine it's a private repo to which I >> haven't been granted access. >> >> Thanks >> >> TJG >> >> On 25/09/2015 10:29, Nicholas H.Tollervey wrote: >>> Issue on GitHub can be found here: >>> >>> https://github.com/dpgeorge/microbit-micropython/issues/31 >>> >>> Please dive in and discuss. I'm not precious and welcome constructive >>> critique, feedback and ideas about anything I write (in both English and >>> code). Knock yourselves out! >>> >>> As David mentioned - this could be an important differentiator / game >>> changer for MicroPython on the micro:bit. >>> >>> :-) >>> >>> N. >>> >>> >>> >>> _______________________________________________ >>> 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 > From ntoll at ntoll.org Fri Sep 25 13:16:51 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Fri, 25 Sep 2015 12:16:51 +0100 Subject: [Microbit-Python] Music things... please dive in! In-Reply-To: <56051405.1050402@ntoll.org> References: <56051405.1050402@ntoll.org> Message-ID: <56052D23.10803@ntoll.org> OK... a quite comprehensive formal-ish specification is now on the wiki here: https://github.com/dpgeorge/microbit-micropython/wiki/music-API Yay Matthew! :-) N. On 25/09/15 10:29, Nicholas H.Tollervey wrote: > Issue on GitHub can be found here: > > https://github.com/dpgeorge/microbit-micropython/issues/31 > > Please dive in and discuss. I'm not precious and welcome constructive > critique, feedback and ideas about anything I write (in both English and > code). Knock yourselves out! > > As David mentioned - this could be an important differentiator / game > changer for MicroPython on the micro:bit. > > :-) > > N. > > > > _______________________________________________ > 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 damien.p.george at gmail.com Fri Sep 25 15:50:22 2015 From: damien.p.george at gmail.com (Damien George) Date: Fri, 25 Sep 2015 14:50:22 +0100 Subject: [Microbit-Python] error code?... :(020 In-Reply-To: References: <5600616A.2000107@ntoll.org> <56013703.80902@hastings.org> <56014B5B.40606@hastings.org> <56016A83.10202@hastings.org> <5603F7DD.1030407@hastings.org> Message-ID: Regarding the event queue. This is something that's implemented in the underlying DAL, it's nothing to do with MicroPython. There is a message bus and events can be posted to the message bus, with a timestamp. You can attach arbitrary C/C++ functions to be called when an event is posted. For example, with the buttons, when the button state changes then events are generated. The buttons have software debouncing and also timing to see how long they have been pressed. The events are: - button high transition - button low transition - button click - button long press - button held Events will remain on the queue until the handler is run. Since the threading scheme of the DAL is cooperative your code must yield for the events to be processed. This is likely to change very soon so that events handlers are executed preemptively (on an interrupt). Currently in the MicroPython bindings to the DAL we don't use these events. We simply return the current state of the button (high or low) as read on the button GPIO. But probably it's a good idea to use these events so that you can react to a "click" without sitting in a tight polling loop. The difficult thing will be to make a clean API that doesn't require the user to know/understand events or preemption, and doesn't require them to yield or make sure the queue doesn't overflow. We could try something like: button.is_held() # simply get the state of the GPIO as it currently does button.was_clicked() # return true if the button was clicked since the last call to this function; resets the state to false button.was_long_clicked() # same as above, but for long click We anyway need a similar set of concepts for gestures (eg gesture.did_fall(), gesture.was_shaken()). Thoughts? On Fri, Sep 25, 2015 at 2:09 AM, Alan wrote: > > I've just been writing myself an event queue for button pushes etc... maybe > that's not necessary if there already is one, if it's accessible. > > Cheers, > > Alan > ________________________________ > To: microbit at python.org > From: larry at hastings.org > Date: Thu, 24 Sep 2015 14:17:17 +0100 > Subject: Re: [Microbit-Python] error code?... :(020 > > > > I wish to understand this more. Micropython has an internal, > hidden-from-view, event queue? How do I examine and interact with it? > > I thought button_a.is_pressed() was polling; is it watching for button > events on this event queue? Does that imply that I can get delayed / > buffered button presses? > > In general how do I keep the event queue from filling? > > > /arry > > On 09/23/2015 01:54 PM, Damien George wrote: > > Hi Alan, > > Error code 020 is "out of memory". > > The problem is as you guessed: there is an event put on the event > queue each time the button is pressed. To clear this queue your code > needs to "yield". You can do this by putting sleep(1) in your loop. > > This is totally unexpected behaviour and I'll work out how to fix it > (Ie your code should just work). > > Cheers, > Damien. > > > > On Wed, Sep 23, 2015 at 4:02 AM, Alan wrote: > > Error code update. > > I'm consistently getting the ":( 020" code after 42 button presses (of any > combination of buttons A and B). > > Is there a button click buffer that's overflowing somewhere? If there is I > can't see a method on the microbit API to clear it. > > Cheers, > > Alan > > ________________________________ > From: alainjackson at hotmail.com > To: microbit at python.org > Date: Wed, 23 Sep 2015 00:28:51 +0000 > Subject: [Microbit-Python] error code?... :(020 > > > Hi, > > I wrote a small program to draw on the LED matrix, but after setting a few > LEDs on I get what looks like an error message on the LEDs: > > ":(020" > > (Frowny-face zero two zero) > > It just keeps repeating that and my program stops but there's no stack trace > on the python repl. > > Is that a built in hardware error code or something? Has anyone else seen > that? > > Here's my program: > > ====8<==== > > from microbit import * > > index = 0 > > while True: > if button_a.is_pressed(): > x = index % 5 > y = int(index / 5) > display.image.set_pixel_value(x,y, > not(display.image.get_pixel_value(x,y))) > > if button_b.is_pressed(): > index = (index + 1) % 25 > > _______________________________________________ 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 > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > From ben at raspberrypi.org Fri Sep 25 22:43:58 2015 From: ben at raspberrypi.org (Ben Nuttall) Date: Fri, 25 Sep 2015 21:43:58 +0100 Subject: [Microbit-Python] error code?... :(020 In-Reply-To: <0847aa0b30c5469dbb51d5b595e2f9ff@THHSTE15D1BE1.hs20.net> References: <5600616A.2000107@ntoll.org> <56013703.80902@hastings.org> <56014B5B.40606@hastings.org> <56016A83.10202@hastings.org> <5603F7DD.1030407@hastings.org> <0847aa0b30c5469dbb51d5b595e2f9ff@THHSTE15D1BE1.hs20.net> Message-ID: If anyone's interested, we just added a nifty callback feature into gpiozero (the kid friendly GPIO lib for Raspberry Pi I'm working on). Example usage: button = Button(2) # gpio pin 2 led = LED(3) # gpio pin 3 button.when_pressed = led.on button.when_released = led.off See the code here: https://github.com/RPi-Distro/python-gpiozero/blob/master/gpiozero/input_devices.py All credit to the genius that is Dave Jones. Ben --- Ben Nuttall Education Developer Advocate Raspberry Pi Foundation www.raspberrypi.org UK registered charity 1129409 On 25 September 2015 at 14:50, Damien George wrote: > Regarding the event queue. This is something that's implemented in > the underlying DAL, it's nothing to do with MicroPython. > > There is a message bus and events can be posted to the message bus, > with a timestamp. You can attach arbitrary C/C++ functions to be > called when an event is posted. > > For example, with the buttons, when the button state changes then > events are generated. The buttons have software debouncing and also > timing to see how long they have been pressed. The events are: > - button high transition > - button low transition > - button click > - button long press > - button held > > Events will remain on the queue until the handler is run. Since the > threading scheme of the DAL is cooperative your code must yield for > the events to be processed. This is likely to change very soon so > that events handlers are executed preemptively (on an interrupt). > > Currently in the MicroPython bindings to the DAL we don't use these > events. We simply return the current state of the button (high or > low) as read on the button GPIO. > > But probably it's a good idea to use these events so that you can > react to a "click" without sitting in a tight polling loop. > > The difficult thing will be to make a clean API that doesn't require > the user to know/understand events or preemption, and doesn't require > them to yield or make sure the queue doesn't overflow. > > We could try something like: > > button.is_held() # simply get the state of the GPIO as it currently does > button.was_clicked() # return true if the button was clicked since the > last call to this function; resets the state to false > button.was_long_clicked() # same as above, but for long click > > We anyway need a similar set of concepts for gestures (eg > gesture.did_fall(), gesture.was_shaken()). > > Thoughts? > > > On Fri, Sep 25, 2015 at 2:09 AM, Alan wrote: > > > > I've just been writing myself an event queue for button pushes etc... > maybe > > that's not necessary if there already is one, if it's accessible. > > > > Cheers, > > > > Alan > > ________________________________ > > To: microbit at python.org > > From: larry at hastings.org > > Date: Thu, 24 Sep 2015 14:17:17 +0100 > > Subject: Re: [Microbit-Python] error code?... :(020 > > > > > > > > I wish to understand this more. Micropython has an internal, > > hidden-from-view, event queue? How do I examine and interact with it? > > > > I thought button_a.is_pressed() was polling; is it watching for button > > events on this event queue? Does that imply that I can get delayed / > > buffered button presses? > > > > In general how do I keep the event queue from filling? > > > > > > /arry > > > > On 09/23/2015 01:54 PM, Damien George wrote: > > > > Hi Alan, > > > > Error code 020 is "out of memory". > > > > The problem is as you guessed: there is an event put on the event > > queue each time the button is pressed. To clear this queue your code > > needs to "yield". You can do this by putting sleep(1) in your loop. > > > > This is totally unexpected behaviour and I'll work out how to fix it > > (Ie your code should just work). > > > > Cheers, > > Damien. > > > > > > > > On Wed, Sep 23, 2015 at 4:02 AM, Alan wrote: > > > > Error code update. > > > > I'm consistently getting the ":( 020" code after 42 button presses (of > any > > combination of buttons A and B). > > > > Is there a button click buffer that's overflowing somewhere? If there is > I > > can't see a method on the microbit API to clear it. > > > > Cheers, > > > > Alan > > > > ________________________________ > > From: alainjackson at hotmail.com > > To: microbit at python.org > > Date: Wed, 23 Sep 2015 00:28:51 +0000 > > Subject: [Microbit-Python] error code?... :(020 > > > > > > Hi, > > > > I wrote a small program to draw on the LED matrix, but after setting a > few > > LEDs on I get what looks like an error message on the LEDs: > > > > ":(020" > > > > (Frowny-face zero two zero) > > > > It just keeps repeating that and my program stops but there's no stack > trace > > on the python repl. > > > > Is that a built in hardware error code or something? Has anyone else seen > > that? > > > > Here's my program: > > > > ====8<==== > > > > from microbit import * > > > > index = 0 > > > > while True: > > if button_a.is_pressed(): > > x = index % 5 > > y = int(index / 5) > > display.image.set_pixel_value(x,y, > > not(display.image.get_pixel_value(x,y))) > > > > if button_b.is_pressed(): > > index = (index + 1) % 25 > > > > _______________________________________________ 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 > > > > _______________________________________________ > > 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 ben at raspberrypi.org Fri Sep 25 22:45:21 2015 From: ben at raspberrypi.org (Ben Nuttall) Date: Fri, 25 Sep 2015 21:45:21 +0100 Subject: [Microbit-Python] The all-seeing British airport security In-Reply-To: References: <5603F762.1060900@hastings.org> <560461CE.20104@ntoll.org> <5604B40B.9070302@hastings.org> <5604F21B.1090303@ntoll.org> Message-ID: Chill out, people. Don't let Larry think we don't have a sense of humour (or read Dahl)! Ben --- Ben Nuttall Education Developer Advocate Raspberry Pi Foundation www.raspberrypi.org UK registered charity 1129409 On 25 September 2015 at 10:19, David Whale wrote: > Don't muck about guys. You have no idea what we've all gone through to > make this happen and get extra devices. personally I've been in a logistics > nightmare for weeks sharing devices with geographically diverse members of > my team. If you can't be and can't act 100% responsible, please leave the > team. If you can be, then please be awesome and muck in and follow the > guidance of Nicholas. Thanks. End of. > > Sent from my new HTC > On Sep 25, 2015 8:04 AM, "Nicholas H.Tollervey" wrote: > >> What a relief. ;-) >> >> Not sure BBC lawyers read Dahl - it's just they're very Very VERY touchy >> about precisely the situation that was joked about and they're always >> keen to impress this upon partner representatives like me. >> >> My concern was rather selfish - the joke was a potential flurry of >> emails with the BBC that I really didn't fancy having to deal with. ;-) >> >> Just to be clear - jokes are GOOD!!!! For the record, my reaction was: >> >> * "Hahahahahaha, Larry's a card" >> * "Oh shit, people from the BBC are on this list" >> * "ZOMG I really don't want to have to spend time explaining Slugworth >> to cover our arses" >> * "Arghhhh MUST SEND EMAIL" >> >> :-) >> >> Phew... and thanks for your patience..! >> >> N. >> >> >> On 25/09/15 03:40, Larry Hastings wrote: >> > >> > >> > Just to be clear: yes, this was a joke. If the non-existant "America's >> > vast reverse-engineering complex" wasn't enough of a clue, I'd hoped the >> > namedrop of Mr. Slugworth would put it over the edge. Mr. Slugworth, >> > for those of you who don't remember their Dahl, was a rival candymaker >> > in "Charlie And The Chocolate Factory". He made such dubious-sounding >> > confections as the "Slugworth Sizzler". In the 70s movie version, >> > Slugworth appeared as a character, meeting the children in secret and >> > bribing them to bring him an Everlasting Gobstopper so he might >> > reverse-engineer it. >> > >> > Sorry to give Nicholas kittens; I would have replied sooner, but I was >> > flying home from London to Seattle. >> > >> > >> > //arry/ >> > >> > On 09/24/2015 01:59 PM, Michael wrote: >> >> I'm sure it is. Very much reads that way to me :-) >> >> >> >> That said, I really like the idea of there being 5 golden tickets >> >> included in a selection of the devices shipped out, and then something >> >> cool happening as a result. >> >> >> >> :-) >> >> >> >> >> >> Michael. >> >> >> >> On 24 September 2015 at 21:49, Nicholas H.Tollervey > >> > wrote: >> >> >> >> Larry, >> >> >> >> I really hope this is a joke..! I can't stress how stressed both I >> and >> >> the BBC are about the device being given away. >> >> >> >> 8-O >> >> >> >> N. >> >> >> >> On 24/09/15 14:15, Larry Hastings wrote: >> >> > >> >> > >> >> > I'm now in the secured area, having checked in for my flight >> >> home. They >> >> > pulled my rolly bag to go through it item by item. One of the >> few >> >> > things they didn't bother to pull out? The partially-collapsed >> >> Costa >> >> > coffee cup containing my Microbit. Next stop: America's vast >> >> > reverse-engineering complex, where I will be paid a handsome >> >> bounty by >> >> > Mr. Slugworth for this device, the creme of British engineering! >> >> > >> >> > Shhhhh, >> >> > >> >> > >> >> > //arry/ >> >> > >> >> > >> >> > _______________________________________________ >> >> > 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 >> > >> >> >> >> _______________________________________________ >> 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 Sun Sep 27 12:52:46 2015 From: damien.p.george at gmail.com (Damien George) Date: Sun, 27 Sep 2015 11:52:46 +0100 Subject: [Microbit-Python] My visit to the BBC today In-Reply-To: <560503A0.5080909@ntoll.org> References: <56046721.80508@ntoll.org> <560503A0.5080909@ntoll.org> Message-ID: Hi David, Regarding your thoughts on extended music support. I tried playing an audio sample on the microbit (4k/s, mono) but it's very difficult to get working. Because there is no proper DAC you need to use the PWM output at a very high frequency (highest seems to be 30kHz) then change the duty ratio at 4kHz to output the audio data. You then need an external low-pass filter (cap+resistor) to make it a proper analog signal for the speaker. But the microbit doesn't have enough power on its pin to drive the (passive) filter and the speaker. It might work with very high impedance headphones, or with an active filter (basically an external amplifier), but I didn't try these options because they are getting out of the scope of what kids can wire up. Of course, we could do anything if we could make hardware add-on modules (eg a DAC over SPI) but that's not really feasible at this point :) Note being able to do proper analog signals means that audio synth is also off the table for the time being (I don't think you can do attack-sustain-decay-release with a purely digital signal...?). So at the moment we just have "music", which is playing a simple square-wave "note" using PWM. That is capable of driving an external speaker (or headphones). Multiple channel music is possible because there are 3 timers in the MCU, and each one would be needed to provide a different frequency for the note. At the moment only timer2 is supported by mbed and the DAL so we'd need to do some low-level hacking to get 3 independent music channels. Regarding MIDI: given the above constraints (ie no proper analog output) how would you imagine MIDI working? Cheers, Damien. On Fri, Sep 25, 2015 at 9:19 AM, Nicholas H.Tollervey wrote: > Hi, > > Comments in-line... > > On 24/09/15 23:33, David Whale wrote: >> Just some random thoughts.... >> >> Background music would be awesome (in the same way that Damien has >> surfaced background animations). >> > > +1 > >> I reckon if you could find a way to use the internal fibre scheduling >> safely, you could have 3 channels running, one on each pin, and >> "externally mix them" with resistors or capacitors into a single >> speaker. This would give you 3 channel sound just like the original >> AY-3-8910 chip on the BBC Micro!!! My ultimate test here would be to >> play "Eurythmics: Sweet dreams are made of this" and "Stranglers:Golden >> Brown" in the same arrangements as the original ones done on the BBC >> micro!!! >> > > Hahahaha... you had those programs too..? Did you also have the Bach > Toccata and Fugue (another piece of musical programming amazement)..? > >> The other thing that would be cool is an external tool that converts a >> MIDI file into the python data structures that plays that same music. >> That would then be a really easy way to bring in other pieces, as there >> are plenty of MIDI editors and sources of MIDI on the internet. >> > > MIDI is a very simple standard. IIRC it's just channels (giving you > instruments) along with numbers representing pitches and an offset so > stuff gets played at the correct time. > >> Envelopes - the AY-3-8910 on the beeb had ADSR envelopes. You loaded 4 >> numbers into registers and it did the attack, delay, sustain and release >> for you automatically, and this made it possible to do really nice >> phrasing and expression. >> > > I remember those. Combined with the "noise" channel (0) you could get > some interesting effects. > >> The touch sensing works great now - how about something akin to the new >> PiPiano that Pimoroni made for the Pi based on Zachs original Pi Piano??? >> >> All of these are a *bit* 1980's demo (Nicholas will understand that quote!) >> > > Nothing wrong with the 1980s (well, the good bits of the 1980s)... ;-) > >> There is a really awesome opportunity to implement MIDI or OSC support >> for linking to external devices and using the MicroBit as the >> programmable sequencer or controller for them. Python support for either >> in some way would be a "game changer" (not my words, someone else's >> words!) - think micro:bit gestures controlling an external soft MIDI >> synth on a bigger computer. Think linking that to DMX lighting and >> controlling the school stage lights with it too in sync with the music - >> the micro:bit as a performance device! >> > > EXACTLY! That's where I'm going with this... > >> Just random ideas. Shoot them down. >> >> D >> > > Far better to make them fly! ;-) > > N. > > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > From ntoll at ntoll.org Sun Sep 27 12:57:34 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Sun, 27 Sep 2015 11:57:34 +0100 Subject: [Microbit-Python] My visit to the BBC today In-Reply-To: References: <56046721.80508@ntoll.org> <560503A0.5080909@ntoll.org> Message-ID: <5607CB9E.3060203@ntoll.org> On 27/09/15 11:52, Damien George wrote: > Regarding MIDI: given the above constraints (ie no proper analog > output) how would you imagine MIDI working? > Yes, I'd be interested to know... if we just use the micro:bit as a signalling device for a midi-event played by something else, then we're onto something funky. See especially MIDI channel 10 (general percussion): https://en.wikipedia.org/wiki/General_MIDI#Percussion :-) 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 david at thinkingbinaries.com Sun Sep 27 17:38:06 2015 From: david at thinkingbinaries.com (David Whale) Date: Sun, 27 Sep 2015 16:38:06 +0100 Subject: [Microbit-Python] My visit to the BBC today In-Reply-To: <5607CB9E.3060203@ntoll.org> References: <56046721.80508@ntoll.org> <560503A0.5080909@ntoll.org> <5607CB9E.3060203@ntoll.org> Message-ID: Yes, makes sense. I seem to remember the AY-3-8190 on the Beeb had some external filtering components to resolve that issue with raw PWM. MIDI is just a serial message. All you have to do is use a baud rate of 31250 bps and send short binary messages. The interface circuitry is really simple (just an opto isolator 6N129 I think). James Devine tells me there is a serial port that comes out on the pins of the micro:bit, and Geoff at Kitronik now has hundreds of edge connectors in stock along with great little solderable breakout boards. Receive and send are just as easy as each other. You can then plug the 5pin DIN into any MIDI device and it will work (both for playback synth and also for note and controller input into the micro:bit). I did a MIDI receiver on a Parallax Propellor a few years ago, plugged my friends keyboard into it, and we played the standard "Chip Gracey vocal tract synth" on the prop through some loud speakers, it was awesome - think "choir oooh-ahhs on steroids!!!" An interesting use case would be to get the accelerometer reading from the micro:bit and map this to sending serial MIDI messages for a pitch bend controller message, you could then 'live' interact with any old MIDI device using the micro:bit - There are also soft synths on PC's and if you get one of those little MIDI/USB adaptors they work on PC and mac. If MIDI works, you can get it working out of the box with SonicPi I think. It's also not far off getting OSC working (open sound control) which is the raw messaging format accepted by SonicPi and you then get access to every parameter of every soft synth inside SonicPi. 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 27 September 2015 at 11:57, Nicholas H.Tollervey wrote: > On 27/09/15 11:52, Damien George wrote: > > Regarding MIDI: given the above constraints (ie no proper analog > > output) how would you imagine MIDI working? > > > > Yes, I'd be interested to know... if we just use the micro:bit as a > signalling device for a midi-event played by something else, then we're > onto something funky. > > See especially MIDI channel 10 (general percussion): > > https://en.wikipedia.org/wiki/General_MIDI#Percussion > > :-) > > N. > > > > _______________________________________________ > 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 Sun Sep 27 19:49:50 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Sun, 27 Sep 2015 18:49:50 +0100 Subject: [Microbit-Python] Authors' list in modthis.cpp Message-ID: <56082C3E.2060209@ntoll.org> Hi Folks, If you submit a patch for MicroBit/MicroPython please make sure you also ensure your name is listed in the this_authors function in source/microbit/modthis.cpp file (it should be obvious where it goes). Please leave Damien at the head and me at the tail. Remember that we also nicely wrap such printf output to 79(ish) characters. I've already done this for Matthew (see https://github.com/dpgeorge/microbit-micropython/pull/33) and I suspect Mark and Maria will have work merged in soon (I can't wait to see the new images). Once the DAL related greyscale stuff is worked out, I'd love to add a "sparkles" function to the new "love" module (see https://github.com/dpgeorge/microbit-micropython/pull/32). Also, we could do an equalizer module where the peak reading fades properly (viz: http://www.animated-gifs.eu/leisure-music-equalizers/0026.gif) I think it important that everyone is acknowledged for their efforts! 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 Sun Sep 27 19:53:29 2015 From: damien.p.george at gmail.com (Damien George) Date: Sun, 27 Sep 2015 18:53:29 +0100 Subject: [Microbit-Python] Authors' list in modthis.cpp In-Reply-To: <56082C3E.2060209@ntoll.org> References: <56082C3E.2060209@ntoll.org> Message-ID: Regarding greyscale, I have opened an issue here https://github.com/lancaster-university/microbit-dal/issues/14 to discuss it. To make things easier I think it would be good to have greyscale mode enabled by default (and actually no way to go to black and white, greyscale is more powerful). On Sun, Sep 27, 2015 at 6:49 PM, Nicholas H.Tollervey wrote: > Hi Folks, > > If you submit a patch for MicroBit/MicroPython please make sure you also > ensure your name is listed in the this_authors function in > source/microbit/modthis.cpp file (it should be obvious where it goes). > > Please leave Damien at the head and me at the tail. Remember that we > also nicely wrap such printf output to 79(ish) characters. I've already > done this for Matthew (see > https://github.com/dpgeorge/microbit-micropython/pull/33) and I suspect > Mark and Maria will have work merged in soon (I can't wait to see the > new images). > > Once the DAL related greyscale stuff is worked out, I'd love to add a > "sparkles" function to the new "love" module (see > https://github.com/dpgeorge/microbit-micropython/pull/32). > > Also, we could do an equalizer module where the peak reading fades > properly (viz: > http://www.animated-gifs.eu/leisure-music-equalizers/0026.gif) > > I think it important that everyone is acknowledged for their efforts! > > Best wishes, > > Nicholas. > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > From ntoll at ntoll.org Sun Sep 27 19:55:16 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Sun, 27 Sep 2015 18:55:16 +0100 Subject: [Microbit-Python] Authors' list in modthis.cpp In-Reply-To: References: <56082C3E.2060209@ntoll.org> Message-ID: <56082D84.4010505@ntoll.org> On 27/09/15 18:53, Damien George wrote: > Regarding greyscale, I have opened an issue here > https://github.com/lancaster-university/microbit-dal/issues/14 to > discuss it. > > To make things easier I think it would be good to have greyscale mode > enabled by default (and actually no way to go to black and white, > greyscale is more powerful). > Yeah, I saw this and it's what prompted my thinking about stuff that sparkles, fades and pulsates. It'd be a rather cool differentiator for MicroPython. ;-) 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 Sun Sep 27 22:50:32 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Sun, 27 Sep 2015 21:50:32 +0100 Subject: [Microbit-Python] My visit to the BBC today In-Reply-To: References: <56046721.80508@ntoll.org> <560503A0.5080909@ntoll.org> <5607CB9E.3060203@ntoll.org> Message-ID: <56085698.50707@ntoll.org> Hi David, See comments in-line below... On 27/09/15 16:38, David Whale wrote: > Yes, makes sense. I seem to remember the AY-3-8190 on the Beeb had some > external filtering components to resolve that issue with raw PWM. > > MIDI is just a serial message. All you have to do is use a baud rate of > 31250 bps and send short binary messages. The interface circuitry is > really simple (just an opto isolator 6N129 I think). > To my numpty musician ears, 6N129 sounds like a droid from Star Wars. I really should find the time to do an introductory course on electrical engineering to learn about this stuff. > James Devine tells me there is a serial port that comes out on the pins > of the micro:bit, and Geoff at Kitronik now has hundreds of edge > connectors in stock along with great little solderable breakout boards. > Receive and send are just as easy as each other. You can then plug the > 5pin DIN into any MIDI device and it will work (both for playback synth > and also for note and controller input into the micro:bit). > Oooh... again - to my numpty musician ears - you're basically saying we can easily make the micro:bit look like something sending midi signals via the IO pins and Geoff's connectors/breakout boards. > > I did a MIDI receiver on a Parallax Propellor a few years ago, plugged > my friends keyboard into it, and we played the standard "Chip Gracey > vocal tract synth" on the prop through some loud speakers, it was > awesome - think "choir oooh-ahhs on steroids!!!" > Fantastic... when using such instruments it's important to ensure you use an epic "sound font" (https://en.wikipedia.org/wiki/SoundFont) for the maximum "ZOMG that's amazeballs" effect. ;-) > An interesting use case would be to get the accelerometer reading from > the micro:bit and map this to sending serial MIDI messages for a pitch > bend controller message, you could then 'live' interact with any old > MIDI device using the micro:bit - There are also soft synths on PC's and > if you get one of those little MIDI/USB adaptors they work on PC and mac. > Exactly the sort of idea I had in mind. I want to try to make a trom:bit (a cross between a trombone and micro:bit). As you know, you change the pitch on a trombone with a slide (I guess you could say it's obviously analog) and we could do something similar with the accelerometer. ;-) Basically, I want to be a bit silly and create a sad microbit sound (wah wah wah waaaah - http://www.sadtrombone.com/). > If MIDI works, you can get it working out of the box with SonicPi I > think. It's also not far off getting OSC working (open sound control) > which is the raw messaging format accepted by SonicPi and you then get > access to every parameter of every soft synth inside SonicPi. > That's the beauty of MIDI - it's such a simple protocol and works every-bloody-where. :-) It would make the micro:bit such a lot of fun and compelling programmable device. Just imagine live programming such things from the REPL. I know from practical experience as a music teacher - if you give a bunch of kids instruments they will experiment, explore and enjoy what they're doing - sound and music is such a fun feedback mechanism. They'll also want to show their friends and, much to their annoyance, their parents too. If we can capitalise on this... ;-) N. > 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 27 September 2015 at 11:57, Nicholas H.Tollervey > wrote: > > On 27/09/15 11:52, Damien George wrote: > > Regarding MIDI: given the above constraints (ie no proper analog > > output) how would you imagine MIDI working? > > > > Yes, I'd be interested to know... if we just use the micro:bit as a > signalling device for a midi-event played by something else, then we're > onto something funky. > > See especially MIDI channel 10 (general percussion): > > https://en.wikipedia.org/wiki/General_MIDI#Percussion > > :-) > > N. > > > > _______________________________________________ > 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 alainjackson at hotmail.com Mon Sep 28 01:30:56 2015 From: alainjackson at hotmail.com (Alan) Date: Sun, 27 Sep 2015 23:30:56 +0000 Subject: [Microbit-Python] error code?... :(020 In-Reply-To: References: <5600616A.2000107@ntoll.org>, , , <56013703.80902@hastings.org>, , <56014B5B.40606@hastings.org>, , <56016A83.10202@hastings.org>, , , , , , , <5603F7DD.1030407@hastings.org> , <0847aa0b30c5469dbb51d5b595e2f9ff@THHSTE15D1BE1.hs20.net>, Message-ID: That looks nice! From: ben at raspberrypi.org Date: Fri, 25 Sep 2015 21:43:58 +0100 To: microbit at python.org Subject: Re: [Microbit-Python] error code?... :(020 If anyone's interested, we just added a nifty callback feature into gpiozero (the kid friendly GPIO lib for Raspberry Pi I'm working on). Example usage: button = Button(2) # gpio pin 2 led = LED(3) # gpio pin 3 button.when_pressed = led.on button.when_released = led.off See the code here: https://github.com/RPi-Distro/python-gpiozero/blob/master/gpiozero/input_devices.py All credit to the genius that is Dave Jones. Ben --- Ben Nuttall Education Developer Advocate Raspberry Pi Foundation www.raspberrypi.org UK registered charity 1129409 On 25 September 2015 at 14:50, Damien George wrote: Regarding the event queue. This is something that's implemented in the underlying DAL, it's nothing to do with MicroPython. There is a message bus and events can be posted to the message bus, with a timestamp. You can attach arbitrary C/C++ functions to be called when an event is posted. For example, with the buttons, when the button state changes then events are generated. The buttons have software debouncing and also timing to see how long they have been pressed. The events are: - button high transition - button low transition - button click - button long press - button held Events will remain on the queue until the handler is run. Since the threading scheme of the DAL is cooperative your code must yield for the events to be processed. This is likely to change very soon so that events handlers are executed preemptively (on an interrupt). Currently in the MicroPython bindings to the DAL we don't use these events. We simply return the current state of the button (high or low) as read on the button GPIO. But probably it's a good idea to use these events so that you can react to a "click" without sitting in a tight polling loop. The difficult thing will be to make a clean API that doesn't require the user to know/understand events or preemption, and doesn't require them to yield or make sure the queue doesn't overflow. We could try something like: button.is_held() # simply get the state of the GPIO as it currently does button.was_clicked() # return true if the button was clicked since the last call to this function; resets the state to false button.was_long_clicked() # same as above, but for long click We anyway need a similar set of concepts for gestures (eg gesture.did_fall(), gesture.was_shaken()). Thoughts? On Fri, Sep 25, 2015 at 2:09 AM, Alan wrote: > > I've just been writing myself an event queue for button pushes etc... maybe > that's not necessary if there already is one, if it's accessible. > > Cheers, > > Alan > ________________________________ > To: microbit at python.org > From: larry at hastings.org > Date: Thu, 24 Sep 2015 14:17:17 +0100 > Subject: Re: [Microbit-Python] error code?... :(020 > > > > I wish to understand this more. Micropython has an internal, > hidden-from-view, event queue? How do I examine and interact with it? > > I thought button_a.is_pressed() was polling; is it watching for button > events on this event queue? Does that imply that I can get delayed / > buffered button presses? > > In general how do I keep the event queue from filling? > > > /arry > > On 09/23/2015 01:54 PM, Damien George wrote: > > Hi Alan, > > Error code 020 is "out of memory". > > The problem is as you guessed: there is an event put on the event > queue each time the button is pressed. To clear this queue your code > needs to "yield". You can do this by putting sleep(1) in your loop. > > This is totally unexpected behaviour and I'll work out how to fix it > (Ie your code should just work). > > Cheers, > Damien. > > > > On Wed, Sep 23, 2015 at 4:02 AM, Alan wrote: > > Error code update. > > I'm consistently getting the ":( 020" code after 42 button presses (of any > combination of buttons A and B). > > Is there a button click buffer that's overflowing somewhere? If there is I > can't see a method on the microbit API to clear it. > > Cheers, > > Alan > > ________________________________ > From: alainjackson at hotmail.com > To: microbit at python.org > Date: Wed, 23 Sep 2015 00:28:51 +0000 > Subject: [Microbit-Python] error code?... :(020 > > > Hi, > > I wrote a small program to draw on the LED matrix, but after setting a few > LEDs on I get what looks like an error message on the LEDs: > > ":(020" > > (Frowny-face zero two zero) > > It just keeps repeating that and my program stops but there's no stack trace > on the python repl. > > Is that a built in hardware error code or something? Has anyone else seen > that? > > Here's my program: > > ====8<==== > > from microbit import * > > index = 0 > > while True: > if button_a.is_pressed(): > x = index % 5 > y = int(index / 5) > display.image.set_pixel_value(x,y, > not(display.image.get_pixel_value(x,y))) > > if button_b.is_pressed(): > index = (index + 1) % 25 > > _______________________________________________ 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 > > _______________________________________________ > 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 alainjackson at hotmail.com Mon Sep 28 01:43:13 2015 From: alainjackson at hotmail.com (Alan) Date: Sun, 27 Sep 2015 23:43:13 +0000 Subject: [Microbit-Python] error code?... :(020 In-Reply-To: References: <5600616A.2000107@ntoll.org>, , , <56013703.80902@hastings.org>, , <56014B5B.40606@hastings.org>, , <56016A83.10202@hastings.org>, , , , , , , <5603F7DD.1030407@hastings.org>, , Message-ID: I was about to try and create button events by polling and inserting events into a micropython event queue, but that seems a bit silly if that's what the underlying DAL is doing. The events I was planning to create were the same ones as the DAL already has. As a half-way measure I like the button.was_clicked() method you suggested. I do like callbacks though. Whenever I try and write polling stuff it just gets messy and scrappy quite quickly. Maybe I just need more practice :) -Alan > Date: Fri, 25 Sep 2015 14:50:22 +0100 > From: damien.p.george at gmail.com > To: microbit at python.org > Subject: Re: [Microbit-Python] error code?... :(020 > > Regarding the event queue. This is something that's implemented in > the underlying DAL, it's nothing to do with MicroPython. > > There is a message bus and events can be posted to the message bus, > with a timestamp. You can attach arbitrary C/C++ functions to be > called when an event is posted. > > For example, with the buttons, when the button state changes then > events are generated. The buttons have software debouncing and also > timing to see how long they have been pressed. The events are: > - button high transition > - button low transition > - button click > - button long press > - button held > > Events will remain on the queue until the handler is run. Since the > threading scheme of the DAL is cooperative your code must yield for > the events to be processed. This is likely to change very soon so > that events handlers are executed preemptively (on an interrupt). > > Currently in the MicroPython bindings to the DAL we don't use these > events. We simply return the current state of the button (high or > low) as read on the button GPIO. > > But probably it's a good idea to use these events so that you can > react to a "click" without sitting in a tight polling loop. > > The difficult thing will be to make a clean API that doesn't require > the user to know/understand events or preemption, and doesn't require > them to yield or make sure the queue doesn't overflow. > > We could try something like: > > button.is_held() # simply get the state of the GPIO as it currently does > button.was_clicked() # return true if the button was clicked since the > last call to this function; resets the state to false > button.was_long_clicked() # same as above, but for long click > > We anyway need a similar set of concepts for gestures (eg > gesture.did_fall(), gesture.was_shaken()). > > Thoughts? > > > On Fri, Sep 25, 2015 at 2:09 AM, Alan wrote: > > > > I've just been writing myself an event queue for button pushes etc... maybe > > that's not necessary if there already is one, if it's accessible. > > > > Cheers, > > > > Alan > > ________________________________ > > To: microbit at python.org > > From: larry at hastings.org > > Date: Thu, 24 Sep 2015 14:17:17 +0100 > > Subject: Re: [Microbit-Python] error code?... :(020 > > > > > > > > I wish to understand this more. Micropython has an internal, > > hidden-from-view, event queue? How do I examine and interact with it? > > > > I thought button_a.is_pressed() was polling; is it watching for button > > events on this event queue? Does that imply that I can get delayed / > > buffered button presses? > > > > In general how do I keep the event queue from filling? > > > > > > /arry > > > > On 09/23/2015 01:54 PM, Damien George wrote: > > > > Hi Alan, > > > > Error code 020 is "out of memory". > > > > The problem is as you guessed: there is an event put on the event > > queue each time the button is pressed. To clear this queue your code > > needs to "yield". You can do this by putting sleep(1) in your loop. > > > > This is totally unexpected behaviour and I'll work out how to fix it > > (Ie your code should just work). > > > > Cheers, > > Damien. > > > > > > > > On Wed, Sep 23, 2015 at 4:02 AM, Alan wrote: > > > > Error code update. > > > > I'm consistently getting the ":( 020" code after 42 button presses (of any > > combination of buttons A and B). > > > > Is there a button click buffer that's overflowing somewhere? If there is I > > can't see a method on the microbit API to clear it. > > > > Cheers, > > > > Alan > > > > ________________________________ > > From: alainjackson at hotmail.com > > To: microbit at python.org > > Date: Wed, 23 Sep 2015 00:28:51 +0000 > > Subject: [Microbit-Python] error code?... :(020 > > > > > > Hi, > > > > I wrote a small program to draw on the LED matrix, but after setting a few > > LEDs on I get what looks like an error message on the LEDs: > > > > ":(020" > > > > (Frowny-face zero two zero) > > > > It just keeps repeating that and my program stops but there's no stack trace > > on the python repl. > > > > Is that a built in hardware error code or something? Has anyone else seen > > that? > > > > Here's my program: > > > > ====8<==== > > > > from microbit import * > > > > index = 0 > > > > while True: > > if button_a.is_pressed(): > > x = index % 5 > > y = int(index / 5) > > display.image.set_pixel_value(x,y, > > not(display.image.get_pixel_value(x,y))) > > > > if button_b.is_pressed(): > > index = (index + 1) % 25 > > > > _______________________________________________ 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 > > > > _______________________________________________ > > 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 larry at hastings.org Mon Sep 28 03:32:07 2015 From: larry at hastings.org (Larry Hastings) Date: Sun, 27 Sep 2015 18:32:07 -0700 Subject: [Microbit-Python] Play Simple Slalom Message-ID: <56089897.7080002@hastings.org> Attached is "Simple Slalom", a simple game for the Microbit. Paste the contents of the file into upyed and download the firmware to your device. To play: you are the bright pixel at the bottom. Walls come towards you from the top. Navigate through the hole in each wall by tilting the micro:bit. The game speeds up as it continues. When you lose, you're shown a sad face, then your score, then the screen goes blank. Press both buttons to start a new game. I may make a more complex slalom game in the future, //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: simple_slalom.py Type: text/x-python Size: 3162 bytes Desc: not available URL: From ntoll at ntoll.org Mon Sep 28 09:18:49 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Mon, 28 Sep 2015 08:18:49 +0100 Subject: [Microbit-Python] Play Simple Slalom In-Reply-To: <56089897.7080002@hastings.org> References: <56089897.7080002@hastings.org> Message-ID: <5608E9D9.6010507@ntoll.org> Hi Larry, Hahahahaha... my hight score (after playing for about 2 minutes) is 6. That's just made my Monday morning! :-) How did you find coding the device? Anything we could improve? We should put these into the demos directory. Also, Damien - can you put your pac-man game in there..? :-) N. On 28/09/15 02:32, Larry Hastings wrote: > > > Attached is "Simple Slalom", a simple game for the Microbit. Paste the > contents of the file into upyed and download the firmware to your device. > > To play: you are the bright pixel at the bottom. Walls come towards you > from the top. Navigate through the hole in each wall by tilting the > micro:bit. > > The game speeds up as it continues. When you lose, you're shown a sad > face, then your score, then the screen goes blank. Press both buttons > to start a new game. > > > I may make a more complex slalom game in the future, > > > //arry/ > > > _______________________________________________ > 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 damien.p.george at gmail.com Mon Sep 28 16:29:49 2015 From: damien.p.george at gmail.com (Damien George) Date: Mon, 28 Sep 2015 15:29:49 +0100 Subject: [Microbit-Python] Play Simple Slalom In-Reply-To: <5608E9D9.6010507@ntoll.org> References: <56089897.7080002@hastings.org> <5608E9D9.6010507@ntoll.org> Message-ID: Thanks Larry! That you put it in the public domain means I can add it to the repo, which I'll do. I see that you used "import microbit as m". While I understand your dislike of "from microbit import *" I think the examples should be consistent and all use this latter idiom. I can change your code. On Mon, Sep 28, 2015 at 8:18 AM, Nicholas H.Tollervey wrote: > Hi Larry, > > Hahahahaha... my hight score (after playing for about 2 minutes) is 6. > > That's just made my Monday morning! :-) > > How did you find coding the device? Anything we could improve? > > We should put these into the demos directory. > > Also, Damien - can you put your pac-man game in there..? :-) > > N. > > On 28/09/15 02:32, Larry Hastings wrote: >> >> >> Attached is "Simple Slalom", a simple game for the Microbit. Paste the >> contents of the file into upyed and download the firmware to your device. >> >> To play: you are the bright pixel at the bottom. Walls come towards you >> from the top. Navigate through the hole in each wall by tilting the >> micro:bit. >> >> The game speeds up as it continues. When you lose, you're shown a sad >> face, then your score, then the screen goes blank. Press both buttons >> to start a new game. >> >> >> I may make a more complex slalom game in the future, >> >> >> //arry/ >> >> >> _______________________________________________ >> 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 damien.p.george at gmail.com Mon Sep 28 16:38:49 2015 From: damien.p.george at gmail.com (Damien George) Date: Mon, 28 Sep 2015 15:38:49 +0100 Subject: [Microbit-Python] error code?... :(020 In-Reply-To: References: <5600616A.2000107@ntoll.org> <56013703.80902@hastings.org> <56014B5B.40606@hastings.org> <56016A83.10202@hastings.org> <5603F7DD.1030407@hastings.org> Message-ID: The RPi gpiozero library uses threading. I think the nasty things that threading introduces are way too complex for kids (as already discussed by us elsewhere). button.was_clicked() is much simpler than using threading: it effectively inspects the queue of events and removes the "clicked" event if it exists, returning True. We could expose a more complex queue API, eg microbit.events, with functions: isempty(), clear(), peek() and pop(). But I think that's a lot more difficult to use than button.was_clicked(). Alternatively we could make a proper callback handling model. I'll start an issue on github to discuss it. On Mon, Sep 28, 2015 at 12:43 AM, Alan wrote: > I was about to try and create button events by polling and inserting events > into a micropython event queue, but that seems a bit silly if that's what > the underlying DAL is doing. The events I was planning to create were the > same ones as the DAL already has. > > As a half-way measure I like the button.was_clicked() method you suggested. > > I do like callbacks though. > > Whenever I try and write polling stuff it just gets messy and scrappy quite > quickly. Maybe I just need more practice :) > > -Alan > >> Date: Fri, 25 Sep 2015 14:50:22 +0100 >> From: damien.p.george at gmail.com >> To: microbit at python.org > >> Subject: Re: [Microbit-Python] error code?... :(020 >> >> Regarding the event queue. This is something that's implemented in >> the underlying DAL, it's nothing to do with MicroPython. >> >> There is a message bus and events can be posted to the message bus, >> with a timestamp. You can attach arbitrary C/C++ functions to be >> called when an event is posted. >> >> For example, with the buttons, when the button state changes then >> events are generated. The buttons have software debouncing and also >> timing to see how long they have been pressed. The events are: >> - button high transition >> - button low transition >> - button click >> - button long press >> - button held >> >> Events will remain on the queue until the handler is run. Since the >> threading scheme of the DAL is cooperative your code must yield for >> the events to be processed. This is likely to change very soon so >> that events handlers are executed preemptively (on an interrupt). >> >> Currently in the MicroPython bindings to the DAL we don't use these >> events. We simply return the current state of the button (high or >> low) as read on the button GPIO. >> >> But probably it's a good idea to use these events so that you can >> react to a "click" without sitting in a tight polling loop. >> >> The difficult thing will be to make a clean API that doesn't require >> the user to know/understand events or preemption, and doesn't require >> them to yield or make sure the queue doesn't overflow. >> >> We could try something like: >> >> button.is_held() # simply get the state of the GPIO as it currently does >> button.was_clicked() # return true if the button was clicked since the >> last call to this function; resets the state to false >> button.was_long_clicked() # same as above, but for long click >> >> We anyway need a similar set of concepts for gestures (eg >> gesture.did_fall(), gesture.was_shaken()). >> >> Thoughts? >> >> >> On Fri, Sep 25, 2015 at 2:09 AM, Alan wrote: >> > >> > I've just been writing myself an event queue for button pushes etc... >> > maybe >> > that's not necessary if there already is one, if it's accessible. >> > >> > Cheers, >> > >> > Alan >> > ________________________________ >> > To: microbit at python.org >> > From: larry at hastings.org >> > Date: Thu, 24 Sep 2015 14:17:17 +0100 >> > Subject: Re: [Microbit-Python] error code?... :(020 >> > >> > >> > >> > I wish to understand this more. Micropython has an internal, >> > hidden-from-view, event queue? How do I examine and interact with it? >> > >> > I thought button_a.is_pressed() was polling; is it watching for button >> > events on this event queue? Does that imply that I can get delayed / >> > buffered button presses? >> > >> > In general how do I keep the event queue from filling? >> > >> > >> > /arry >> > >> > On 09/23/2015 01:54 PM, Damien George wrote: >> > >> > Hi Alan, >> > >> > Error code 020 is "out of memory". >> > >> > The problem is as you guessed: there is an event put on the event >> > queue each time the button is pressed. To clear this queue your code >> > needs to "yield". You can do this by putting sleep(1) in your loop. >> > >> > This is totally unexpected behaviour and I'll work out how to fix it >> > (Ie your code should just work). >> > >> > Cheers, >> > Damien. >> > >> > >> > >> > On Wed, Sep 23, 2015 at 4:02 AM, Alan wrote: >> > >> > Error code update. >> > >> > I'm consistently getting the ":( 020" code after 42 button presses (of >> > any >> > combination of buttons A and B). >> > >> > Is there a button click buffer that's overflowing somewhere? If there is >> > I >> > can't see a method on the microbit API to clear it. >> > >> > Cheers, >> > >> > Alan >> > >> > ________________________________ >> > From: alainjackson at hotmail.com >> > To: microbit at python.org >> > Date: Wed, 23 Sep 2015 00:28:51 +0000 >> > Subject: [Microbit-Python] error code?... :(020 >> > >> > >> > Hi, >> > >> > I wrote a small program to draw on the LED matrix, but after setting a >> > few >> > LEDs on I get what looks like an error message on the LEDs: >> > >> > ":(020" >> > >> > (Frowny-face zero two zero) >> > >> > It just keeps repeating that and my program stops but there's no stack >> > trace >> > on the python repl. >> > >> > Is that a built in hardware error code or something? Has anyone else >> > seen >> > that? >> > >> > Here's my program: >> > >> > ====8<==== >> > >> > from microbit import * >> > >> > index = 0 >> > >> > while True: >> > if button_a.is_pressed(): >> > x = index % 5 >> > y = int(index / 5) >> > display.image.set_pixel_value(x,y, >> > not(display.image.get_pixel_value(x,y))) >> > >> > if button_b.is_pressed(): >> > index = (index + 1) % 25 >> > >> > _______________________________________________ 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 >> > >> > _______________________________________________ >> > 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 > From larry at hastings.org Mon Sep 28 18:31:47 2015 From: larry at hastings.org (Larry Hastings) Date: Mon, 28 Sep 2015 09:31:47 -0700 Subject: [Microbit-Python] Play Simple Slalom In-Reply-To: <5608E9D9.6010507@ntoll.org> References: <56089897.7080002@hastings.org> <5608E9D9.6010507@ntoll.org> Message-ID: <56096B73.80002@hastings.org> On 09/28/2015 12:18 AM, Nicholas H.Tollervey wrote: > Hahahahaha... my hight score (after playing for about 2 minutes) is 6. I just got a 12; I believe I got a 13 during testing with the current parameters. Unless I misunderstand my own code (always a possibility) it shouldn't get any faster after 12 walls. > How did you find coding the device? Anything we could improve? I used upyed. I'd hit the "download" button, then shuffle the firmware.hex file around. I iterated a fair amount this way. It's liveable. Naturally, the biggest feature I want is user modules. AFAICT there's no way to write my own .py file and import it. Is that a feature we could consider adding? I'd also like to use my own editor. Finally, it'd be deluxe to be able to upload just the text payload, rather than the entire firmware--that's speed things up immensely. It looks like the firmware format allows specifying the offset; could we emit a supplemental firmware.hex that just overwrote the program text area but left the actual Micropython alone? To make user modules: I envision a command-line tool that builds the firmware similarly to the hexlifyScript / etc in upyed. You point it at an existing firmware.hex file and a .py file. It scans over the file looking for "import" statements; it knows what modules are built-in, so it knows what files it needs to grab. It would then assemble the new firmware.hex file for you. And maybe it could even scan your computer, find the Microbit filesystem, and copy over the new firmware! If this tool was judged to be "swell" we could even change upyed to run from a local web server and have that shell out to the firmware-builder tool. The text payload would have to change to allow multiple "files"; maybe something like this? bytes payload --------------- 1 'M' 1 'P' 1 length n1 of module 1 name n1 bytes of module 1 name 2 length f1 of module 1 contents f1 bytes of module 1 contents 1 length n2 of module 2 name n2 bytes of module 2 name 2 length f2 of module 2 contents f2 bytes of module 2 contents The name would include all the dots, thus if os.path were 258 bytes it would look like MP\x07os.path\x01\x02[...contents of os.path...] The actual script to execute would naturally be called __main__. And speaking of changing the text payload: I notice a comment in hexlifyScript that says the length should be < 8k. If we start allowing user modules, we could eventually get bigger than that. Is 8k a necessary limit, or would it be possible to up it to say 32k? On 09/28/2015 07:29 AM, Damien George wrote: > I see that you used "import microbit as m". While I understand your > dislike of "from microbit import *" I think the examples should be > consistent and all use this latter idiom. I can change your code. If you like. I'll probably iterate on it, at which point I'll change it myself. //arry / -------------- next part -------------- An HTML attachment was scrubbed... URL: From damien.p.george at gmail.com Mon Sep 28 18:40:57 2015 From: damien.p.george at gmail.com (Damien George) Date: Mon, 28 Sep 2015 17:40:57 +0100 Subject: [Microbit-Python] Play Simple Slalom In-Reply-To: <56096B73.80002@hastings.org> References: <56089897.7080002@hastings.org> <5608E9D9.6010507@ntoll.org> <56096B73.80002@hastings.org> Message-ID: Hi Larry, Thanks for the great feedback! Just quickly to respond to a few points: > Finally, it'd be deluxe to be able to upload just the text payload, rather > than the entire firmware--that's speed things up immensely. It looks like > the firmware format allows specifying the offset; could we emit a > supplemental firmware.hex that just overwrote the program text area but left > the actual Micropython alone? Yes, I think that would be possible. Just make a standalone .hex with the script. I didn't yet try it. The show stopper would be that if the device erases all its flash pages before coping the .hex. I don't know the details of how it works to know about this point. I guess it just need experimenting! BTW, you will like tools/pyboard.py: it's a script that allows to download your own script to the microbit (from your PC) and execute it. Eg: python3 ./tools/pyboard.py /dev/ttyACM0 my_microbit_program.py Caveats: - Since it uploads the script all at once there must be enough RAM to hold the script *and* to compile it. For this reason large scripts won't work this way. - You may need to reset the microbit (using its reset button on the "back") between runs of pyboard.py (don't know why yet, probably due to memory issues again). Cheers, Damien. From larry at hastings.org Mon Sep 28 19:13:15 2015 From: larry at hastings.org (Larry Hastings) Date: Mon, 28 Sep 2015 10:13:15 -0700 Subject: [Microbit-Python] How to build the firmware on Ubuntu Message-ID: <5609752B.2090607@hastings.org> I just got the cross-compiler working on Linux, specifically Ubuntu 64-bit. To save other people some time, I made a shell script that with luck will install all the required packages. Just run the attached "prebuild.sh". After that, follow the instructions in the README.md and you should be ready to rock. I also attached my "connect.sh", which runs Picocom for me. (Though sometimes the Microbit is on ttyACM1, not ttyACM0. Maybe it should glob them and use the highest-numbered one?) Cheers, //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: prebuild.sh Type: application/x-shellscript Size: 220 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: connect.sh Type: application/x-shellscript Size: 36 bytes Desc: not available URL: From damien.p.george at gmail.com Mon Sep 28 22:31:55 2015 From: damien.p.george at gmail.com (Damien George) Date: Mon, 28 Sep 2015 21:31:55 +0100 Subject: [Microbit-Python] How to build the firmware on Ubuntu In-Reply-To: <5609752B.2090607@hastings.org> References: <5609752B.2090607@hastings.org> Message-ID: In the microbit-micropython repository there is a Makefile which has some useful targets (the main one calls yt build to do the compilation). It has "make deploy" to mount, copy firmware and unmount the device. It has "make serial" to run picocom. It should always appear on ttyACM0 unless the USB device gets reset/replugged *while* the port is open. Easiest solution is to just quit picocom (ctrl-A, ctrl-X) before reflashing. On Mon, Sep 28, 2015 at 6:13 PM, Larry Hastings wrote: > > > I just got the cross-compiler working on Linux, specifically Ubuntu 64-bit. > To save other people some time, I made a shell script that with luck will > install all the required packages. Just run the attached "prebuild.sh". > After that, follow the instructions in the README.md and you should be ready > to rock. > > I also attached my "connect.sh", which runs Picocom for me. (Though > sometimes the Microbit is on ttyACM1, not ttyACM0. Maybe it should glob > them and use the highest-numbered one?) > > Cheers, > > > /arry > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > From damien.p.george at gmail.com Mon Sep 28 23:11:29 2015 From: damien.p.george at gmail.com (Damien George) Date: Mon, 28 Sep 2015 22:11:29 +0100 Subject: [Microbit-Python] Play Simple Slalom In-Reply-To: References: <56089897.7080002@hastings.org> <5608E9D9.6010507@ntoll.org> <56096B73.80002@hastings.org> Message-ID: Slalom and maze scripts have been added to the examples directory. I got 13 on the slalom! On Mon, Sep 28, 2015 at 5:40 PM, Damien George wrote: > Hi Larry, > > Thanks for the great feedback! Just quickly to respond to a few points: > >> Finally, it'd be deluxe to be able to upload just the text payload, rather >> than the entire firmware--that's speed things up immensely. It looks like >> the firmware format allows specifying the offset; could we emit a >> supplemental firmware.hex that just overwrote the program text area but left >> the actual Micropython alone? > > Yes, I think that would be possible. Just make a standalone .hex with > the script. I didn't yet try it. The show stopper would be that if > the device erases all its flash pages before coping the .hex. I don't > know the details of how it works to know about this point. I guess it > just need experimenting! > > BTW, you will like tools/pyboard.py: it's a script that allows to > download your own script to the microbit (from your PC) and execute > it. Eg: > > python3 ./tools/pyboard.py /dev/ttyACM0 my_microbit_program.py > > Caveats: > - Since it uploads the script all at once there must be enough RAM to > hold the script *and* to compile it. For this reason large scripts > won't work this way. > - You may need to reset the microbit (using its reset button on the > "back") between runs of pyboard.py (don't know why yet, probably due > to memory issues again). > > Cheers, > Damien. From mark at hotpy.org Tue Sep 29 23:56:28 2015 From: mark at hotpy.org (Mark Shannon) Date: Tue, 29 Sep 2015 14:56:28 -0700 Subject: [Microbit-Python] Units for API functions. Message-ID: <560B090C.6000000@hotpy.org> Hi all, We've all had fun discussing the names of functions in the API, but what about units? So far, we have agreed on units for I/O pins and times. For pin I/O we accept values in the range 0 to 1023, with a unit of 3.3/1023 volts. 0 to 1023 translates directly to the capability of the DAC/ADC on the device. For measuring time, it seems that milliseconds are the standard. That leaves brightness, the accelerometer and the compass. For brightness, I would like to propose using a linear scale of *perceived* brightness. Acceptable values would range from 0 to N, where N is in the range 10 to ~15. 0 is off. 1 to N are linearly increasing levels of brightness. The value passed to the underlying C++ layer must be in the range 0 to 255. Therefore, a brightness of n would translate to roughly K**(n-1), where K**(N-1) would be about 255. Candidates for N are: 10, 10 is a natural limit for kids used to decimal. 11, it goes to 11 :) 15, 15 is the maximum hex digit and about the limit of being able to distinguish between brightness levels. (I prefer 11, the bbc iplayer volume goes to 11). What about ranges/units for the accelerometer or compass? Does anyone have any thoughts on those? If they are to be arbitrary, it might make sense to choose 0-1023 for consistency with the other I/O. In terms of the implementation, I would expect that all inputs take ints or floats and all outputs return ints. They should be documented as "number" throughout. E.g. Pin.write_analog(x) will take an int or float and be documented as taking any number between 0 and 1023. Cheers, Mark. P.S. If you haven't played with brightnesses, then try the attached program. -------------- next part -------------- A non-text attachment was scrubbed... Name: beating_heart.py Type: text/x-python Size: 557 bytes Desc: not available URL: From damien.p.george at gmail.com Wed Sep 30 00:11:42 2015 From: damien.p.george at gmail.com (Damien George) Date: Tue, 29 Sep 2015 23:11:42 +0100 Subject: [Microbit-Python] Units for API functions. In-Reply-To: <560B090C.6000000@hotpy.org> References: <560B090C.6000000@hotpy.org> Message-ID: Hi Mark, I think brightness should range from 0-9 inclusive. Reason: that's 10 values, it's Pythonic (range(10)), and most importantly you can encode an image in a string using single digits: "09990\n09090\n...". The compass outputs a heading in degrees. The accelerometer is (or should be) in milli-g's. Ie 1000=9.8m/s^2. I think that arguments which correspond to continuous numeric values should allow int or float (with implicit truncation of float to int), while others should be int only. Eg set_pixel(x,y) should have x,y int only, yet write_analog(v) should allow v to be a float. Cheers, Damien. On Tue, Sep 29, 2015 at 10:56 PM, Mark Shannon wrote: > Hi all, > > We've all had fun discussing the names of functions in the API, > but what about units? > > So far, we have agreed on units for I/O pins and times. > > For pin I/O we accept values in the range 0 to 1023, with a unit of 3.3/1023 > volts. > 0 to 1023 translates directly to the capability of the DAC/ADC on the > device. > > For measuring time, it seems that milliseconds are the standard. > > That leaves brightness, the accelerometer and the compass. > > For brightness, I would like to propose using a linear scale of *perceived* > brightness. Acceptable values would range from 0 to N, where N is in the > range 10 to ~15. > 0 is off. 1 to N are linearly increasing levels of brightness. > The value passed to the underlying C++ layer must be in the range 0 to 255. > Therefore, a brightness of n would translate to roughly K**(n-1), where > K**(N-1) would be about 255. > Candidates for N are: > 10, 10 is a natural limit for kids used to decimal. > 11, it goes to 11 :) > 15, 15 is the maximum hex digit and about the limit of being able to > distinguish between brightness levels. > (I prefer 11, the bbc iplayer volume goes to 11). > > What about ranges/units for the accelerometer or compass? > Does anyone have any thoughts on those? > If they are to be arbitrary, it might make sense to choose 0-1023 for > consistency with the other I/O. > > In terms of the implementation, I would expect that all inputs take ints or > floats and all outputs return ints. They should be documented as "number" > throughout. > E.g. Pin.write_analog(x) will take an int or float and be documented as > taking any number between 0 and 1023. > > Cheers, > Mark. > > P.S. > If you haven't played with brightnesses, then try the attached program. > > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > From mark at hotpy.org Wed Sep 30 00:26:12 2015 From: mark at hotpy.org (Mark Shannon) Date: Tue, 29 Sep 2015 15:26:12 -0700 Subject: [Microbit-Python] Units for API functions. In-Reply-To: References: <560B090C.6000000@hotpy.org> Message-ID: <560B1004.5000809@hotpy.org> On 29/09/15 15:11, Damien George wrote: > Hi Mark, > > I think brightness should range from 0-9 inclusive. Reason: that's 10 > values, it's Pythonic (range(10)), and most importantly you can encode > an image in a string using single digits: "09990\n09090\n...". > > The compass outputs a heading in degrees. Really? Mine must need fixing :( What about the x,y,z values? > > The accelerometer is (or should be) in milli-g's. Ie 1000=9.8m/s^2. > > I think that arguments which correspond to continuous numeric values > should allow int or float (with implicit truncation of float to int), > while others should be int only. Eg set_pixel(x,y) should have x,y > int only, yet write_analog(v) should allow v to be a float. > > Cheers, > Damien. > > > On Tue, Sep 29, 2015 at 10:56 PM, Mark Shannon wrote: >> Hi all, >> >> We've all had fun discussing the names of functions in the API, >> but what about units? >> >> So far, we have agreed on units for I/O pins and times. >> >> For pin I/O we accept values in the range 0 to 1023, with a unit of 3.3/1023 >> volts. >> 0 to 1023 translates directly to the capability of the DAC/ADC on the >> device. >> >> For measuring time, it seems that milliseconds are the standard. >> >> That leaves brightness, the accelerometer and the compass. >> >> For brightness, I would like to propose using a linear scale of *perceived* >> brightness. Acceptable values would range from 0 to N, where N is in the >> range 10 to ~15. >> 0 is off. 1 to N are linearly increasing levels of brightness. >> The value passed to the underlying C++ layer must be in the range 0 to 255. >> Therefore, a brightness of n would translate to roughly K**(n-1), where >> K**(N-1) would be about 255. >> Candidates for N are: >> 10, 10 is a natural limit for kids used to decimal. >> 11, it goes to 11 :) >> 15, 15 is the maximum hex digit and about the limit of being able to >> distinguish between brightness levels. >> (I prefer 11, the bbc iplayer volume goes to 11). >> >> What about ranges/units for the accelerometer or compass? >> Does anyone have any thoughts on those? >> If they are to be arbitrary, it might make sense to choose 0-1023 for >> consistency with the other I/O. >> >> In terms of the implementation, I would expect that all inputs take ints or >> floats and all outputs return ints. They should be documented as "number" >> throughout. >> E.g. Pin.write_analog(x) will take an int or float and be documented as >> taking any number between 0 and 1023. >> >> Cheers, >> Mark. >> >> P.S. >> If you haven't played with brightnesses, then try the attached program. >> >> >> >> _______________________________________________ >> 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 alainjackson at hotmail.com Wed Sep 30 03:14:07 2015 From: alainjackson at hotmail.com (Alan) Date: Wed, 30 Sep 2015 01:14:07 +0000 Subject: [Microbit-Python] memory error In-Reply-To: References: <5600616A.2000107@ntoll.org>, , , <56013703.80902@hastings.org>, , <56014B5B.40606@hastings.org>, , <56016A83.10202@hastings.org>, , , , , , , <5603F7DD.1030407@hastings.org>, , , , Message-ID: Hi, How much memory does the Microbit have for a python program? I've written a small program about 105 lines long. It's 3kB on my hard disk. It runs ok now but when it was 115 lines long and 3.2kB I kept getting memory allocation errors as soon as I pressed the reset button. If I commented about 10 lines out of my program it would run and it didn't seem to matter which 10 lines. So I assumed it was out of program memory? Cheers, Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From alainjackson at hotmail.com Wed Sep 30 03:26:44 2015 From: alainjackson at hotmail.com (Alan) Date: Wed, 30 Sep 2015 01:26:44 +0000 Subject: [Microbit-Python] Where to put examples In-Reply-To: References: <5600616A.2000107@ntoll.org>, , , , , , <56013703.80902@hastings.org>, , , , <56014B5B.40606@hastings.org>, , , , <56016A83.10202@hastings.org>, , , , , , , , , , , , , , <5603F7DD.1030407@hastings.org>, , , , , , , , Message-ID: Hi, Is there a good place to put example microbit programs? I've written a couple, nothing too exciting yet: 1) a timer 2) a watch, just needs a rubber band to strap it to your wrist :) Cheers, Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ntoll at ntoll.org Wed Sep 30 08:29:17 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Wed, 30 Sep 2015 07:29:17 +0100 Subject: [Microbit-Python] Where to put examples In-Reply-To: References: <5600616A.2000107@ntoll.org> <56013703.80902@hastings.org> <56014B5B.40606@hastings.org> <56016A83.10202@hastings.org> <5603F7DD.1030407@hastings.org> Message-ID: <560B813D.7060300@ntoll.org> There's an examples directory in the GitHub repos - just send a pull request to Damien. N. On 30/09/15 02:26, Alan wrote: > Hi, > > Is there a good place to put example microbit programs? > > I've written a couple, nothing too exciting yet: > > 1) a timer > 2) a watch, just needs a rubber band to strap it to your wrist :) > > > Cheers, > > Alan > > > _______________________________________________ > 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 ntoll at ntoll.org Wed Sep 30 08:29:51 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Wed, 30 Sep 2015 07:29:51 +0100 Subject: [Microbit-Python] Units for API functions. In-Reply-To: <560B1004.5000809@hotpy.org> References: <560B090C.6000000@hotpy.org> <560B1004.5000809@hotpy.org> Message-ID: <560B815F.1070105@ntoll.org> WRT the compass... I believe the underlying hardware isn't that great when it comes accuracy. N. On 29/09/15 23:26, Mark Shannon wrote: > > > On 29/09/15 15:11, Damien George wrote: >> Hi Mark, >> >> I think brightness should range from 0-9 inclusive. Reason: that's 10 >> values, it's Pythonic (range(10)), and most importantly you can encode >> an image in a string using single digits: "09990\n09090\n...". >> >> The compass outputs a heading in degrees. > Really? Mine must need fixing :( > What about the x,y,z values? > >> >> The accelerometer is (or should be) in milli-g's. Ie 1000=9.8m/s^2. >> >> I think that arguments which correspond to continuous numeric values >> should allow int or float (with implicit truncation of float to int), >> while others should be int only. Eg set_pixel(x,y) should have x,y >> int only, yet write_analog(v) should allow v to be a float. >> >> Cheers, >> Damien. >> >> >> On Tue, Sep 29, 2015 at 10:56 PM, Mark Shannon wrote: >>> Hi all, >>> >>> We've all had fun discussing the names of functions in the API, >>> but what about units? >>> >>> So far, we have agreed on units for I/O pins and times. >>> >>> For pin I/O we accept values in the range 0 to 1023, with a unit of >>> 3.3/1023 >>> volts. >>> 0 to 1023 translates directly to the capability of the DAC/ADC on the >>> device. >>> >>> For measuring time, it seems that milliseconds are the standard. >>> >>> That leaves brightness, the accelerometer and the compass. >>> >>> For brightness, I would like to propose using a linear scale of >>> *perceived* >>> brightness. Acceptable values would range from 0 to N, where N is in the >>> range 10 to ~15. >>> 0 is off. 1 to N are linearly increasing levels of brightness. >>> The value passed to the underlying C++ layer must be in the range 0 >>> to 255. >>> Therefore, a brightness of n would translate to roughly K**(n-1), where >>> K**(N-1) would be about 255. >>> Candidates for N are: >>> 10, 10 is a natural limit for kids used to decimal. >>> 11, it goes to 11 :) >>> 15, 15 is the maximum hex digit and about the limit of being able to >>> distinguish between brightness levels. >>> (I prefer 11, the bbc iplayer volume goes to 11). >>> >>> What about ranges/units for the accelerometer or compass? >>> Does anyone have any thoughts on those? >>> If they are to be arbitrary, it might make sense to choose 0-1023 for >>> consistency with the other I/O. >>> >>> In terms of the implementation, I would expect that all inputs take >>> ints or >>> floats and all outputs return ints. They should be documented as >>> "number" >>> throughout. >>> E.g. Pin.write_analog(x) will take an int or float and be documented as >>> taking any number between 0 and 1023. >>> >>> Cheers, >>> Mark. >>> >>> P.S. >>> If you haven't played with brightnesses, then try the attached program. >>> >>> >>> >>> _______________________________________________ >>> 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 damien.p.george at gmail.com Wed Sep 30 13:01:57 2015 From: damien.p.george at gmail.com (Damien George) Date: Wed, 30 Sep 2015 12:01:57 +0100 Subject: [Microbit-Python] memory error In-Reply-To: References: <5600616A.2000107@ntoll.org> <56013703.80902@hastings.org> <56014B5B.40606@hastings.org> <56016A83.10202@hastings.org> <5603F7DD.1030407@hastings.org> Message-ID: Hi Alan, Can you post your code? On Wed, Sep 30, 2015 at 2:14 AM, Alan wrote: > Hi, > > How much memory does the Microbit have for a python program? > > I've written a small program about 105 lines long. It's 3kB on my hard disk. > It runs ok now but when it was 115 lines long and 3.2kB I kept getting > memory allocation errors as soon as I pressed the reset button. If I > commented about 10 lines out of my program it would run and it didn't seem > to matter which 10 lines. So I assumed it was out of program memory? > > Cheers, > > Alan > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit >