From sparks.m at gmail.com  Sun Nov  1 08:39:41 2015
From: sparks.m at gmail.com (Michael)
Date: Sun, 1 Nov 2015 13:39:41 +0000
Subject: [Microbit-Python] Accessor API design on the micro:bit
In-Reply-To: <56351FA9.3080809@willingconsulting.com>
References: <563396BF.5030703@hastings.org> <5633DDEF.2040100@ntoll.org>
 <CAB+QZVAw7j1ZEt3vqtctcNVWnqQbSS3LJKfknw8G9WHPJNmBBw@mail.gmail.com>
 <5634EC61.4020003@hastings.org>
 <CAB+QZVB7unA1nk_MnLtQx-dSb7DnnvMihPGXKrqwQaj0Bois7A@mail.gmail.com>
 <56351FA9.3080809@willingconsulting.com>
Message-ID: <CAB+QZVC=yUvfY4a0rTfJ-DvA8JR95fxLwFtwpc=ZroHqk5DrHQ@mail.gmail.com>

On 31 October 2015 at 20:08, Carol Willing <willingc at willingconsulting.com>
wrote:

> While I am joining this discussion after a couple of months of history, I
> am going to step back for a moment and ask a simple question:
>
> Does this have to be a decision between x, x(), get_x()?
>
> For the accelerometer (not necessarily all other functionality, but since
> the accelerometer is built into the chip and accessible without soldering
> anything, it will be used by many), could we support all three?
>

Personally, I would say pick one. If we pick one, be consistent with the
rest of the API. If we choose .x , .y, .z here, it should also be .pin1,
.pin2, .pin3, .temp, .time etc (IMHO) Likewise if we choose .x(), .y(),
.z() (or an alternative accessor method) it should be that.

If we actively choose a mixed economy, then it needs to be *very clear*.

If I was an 11 year old with access to Google, I could find resources
> appropriate for an 11 year old that use all three of these approaches:
> Young Coders workshop, Adafruit/Sparkfun, MicroPython tutorials, Python for
> Kids book, and others.
>

Depends on your assumption of the target audience. The aim of the micro:bit
isn't just to appeal to the child motivated to learn coding, and/or
supported by enthusiastic parents or teachers, but to appeal to the wide
demographic that *won't* have that support nor go to google in the first
place.

Like you, if I was 11, I could find similar things, yes. However, the most
insightful and bluntest thing said to me by my editorial colleagues when we
were working on the prototype was "You're not the target demographic"
(meaning me me obv :-). (Also, it was said in a kind, good natured way, obv
:) )

The target audience here haven't chosen to attend a code club, or an event,
and aren't doing it in their own time (yet)  but are a co-opted audience
we're hoping to inspire to learn to take things further.

The reason isn't because those who are enthusastic/supported aren't worth
supporting (this does support them), but it's to encourage *back* the tens
of thousands (per year) who ran away from computing as thing they might be
interested in. (Which given I'm talking over a 10 year period, means closer
to hundreds of thousands thinking about it, which is quite scary)

Having read everything you've said (and agreeing with a lot of it), I think
you're coming at this from the perspective of "this person/child is
motivated to do this". I'm coming at it from the perspective of someone who
doesn't yet know they could enjoy this, and has simply had this set as
homework for the weekend initially, and there's two outcomes (out of many)
that spring to mind. The one that goes home and finds "this is easier than
I expected" and *plays* all weekend with it, and the one that goes home and
finds it really difficult all weekend for reasons none of us expected or
predicted, and spends all weekend fighting it and comes in demoralised. The
former is full of win, the latter isn't. And to be clear, I fully expect
that both ends of the spectrum will exist if you're going to everyone in an
age group.

I know the reality is always going to be a spectrum and bell curve towards
one end of those experiences or the other, and anything we can do to shift
it towards the fund end, the better.

In that situation, this is what win looks like:

* http://bug.iotoy.org/bug/program/900/

(I tend to pick that one, because it's my favourite and it was the most
unexpected usage I saw, though more complex things got made)

This is what fail looks like:

* http://bug.iotoy.org/bug/program/2719/

While there's hundreds (thousands even - when you consider the
versions were stored) of programs that got made during the trial of
the former kind - which was ace, and while I know you can't please
everyone all the time or make things perfect, I always feel sorry for
the person who wrote the second one.

> Based on my experience teaching a wide spectrum of children, I do
> think with gentle instruction all levels will be able to use the
accelerometer.

I absolutely agree, and I'm just concerned about the ones have to learn
without
teacher support, and who's parents didn't understand this stuff. If I'm
overly
worried, cool :)

Thinking about it, if this was "just" to support an already engaged audience
like code clubs, etc, I wouldn't be anywhere near as concerned - this is in
part
driven by the fact that when I do various activities with cubs and scouts,
if
it's an activity they're engaged with and with a shallow learning curve
it's a
lot *simpler* (and more fun for everyone), and that's not really even a
co-opted
group. (though in some cases for the younger end it is)

> Warmly,
> Carol

Likewise - and please do challenge working assumptions, it's the only
way things improve IMO.

Best Regards,

Michael.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151101/2ee6d288/attachment.html>

From ntoll at ntoll.org  Sun Nov  1 09:16:38 2015
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Sun, 1 Nov 2015 14:16:38 +0000
Subject: [Microbit-Python] Accessor API design on the micro:bit
In-Reply-To: <56351FA9.3080809@willingconsulting.com>
References: <563396BF.5030703@hastings.org> <5633DDEF.2040100@ntoll.org>
 <CAB+QZVAw7j1ZEt3vqtctcNVWnqQbSS3LJKfknw8G9WHPJNmBBw@mail.gmail.com>
 <5634EC61.4020003@hastings.org>
 <CAB+QZVB7unA1nk_MnLtQx-dSb7DnnvMihPGXKrqwQaj0Bois7A@mail.gmail.com>
 <56351FA9.3080809@willingconsulting.com>
Message-ID: <56361EC6.5000909@ntoll.org>

OK... what an interesting discussion. :-)

Then I remembered I had a "captive" 11yo in my home! So I asked him
which one he preferred (and videoed the discussion). Here's the exchange
with my son, over Sunday morning breakfast, in all its glory:

https://www.youtube.com/watch?v=9w4I_xEwlcA

Put simply he prefers accelerometer.x over .get_x() and .x() because
it's less typing.

Emboldened by this feedback I've visited some of his buddies this
morning (I totally realise this is not at all scientific) to get their
opinion.

I'm quite surprised by the results - they agree with Sam: ".x" is the
unanimous verdict for the best way to express this for all three 11yo
I've surveyed. I was expecting ".get_x()" to win because it was obvious
what it was doing.

But, for example, Max explained that he didn't like all the "weird
symbols" and mentioned that, "I don't get 'get', isn't it just 'x'? Why
do I need to 'get' it"..? (Max didn't want to be videoed.)

Lewis, (whose video is here:
https://www.youtube.com/watch?v=uyec2VqYwJs) also likes the simplicity
of ".x" and felt that all the others just looked complicated.

So, the evidence I've collected so far appears to support Larry and that
we should trust the heuristic of "simplicity wins".

Once again, I totally realise this is not scientific in any way. But I
thought I'd ask those 11yo I had within "range" this morning because
they're our target audience.

I've been booked to do some gardening this afternoon... but will return
this evening.

I look forward to reading all your thoughts. :-)

N.

On 31/10/15 20:08, Carol Willing wrote:
> While I am joining this discussion after a couple of months of history,
> I am going to step back for a moment and ask a simple question:
> 
> Does this have to be a decision between x, x(), get_x()?
> 
> For the accelerometer (not necessarily all other functionality, but
> since the accelerometer is built into the chip and accessible without
> soldering anything, it will be used by many), could we support all three?
> 
> If I was an 11 year old with access to Google, I could find resources
> appropriate for an 11 year old that use all three of these approaches:
> Young Coders workshop, Adafruit/Sparkfun, MicroPython tutorials, Python
> for Kids book, and others.
> 
> If I didn't have access to Google, I, as a student, would use `help` or
> example programs to model what I would choose. It's critical for the
> educational setting for the approach to be consistent within an example
> program. While in a perfect world that might imply consistent across all
> example programs.
> 
> Yet, we know that there are several approaches to programming that lend
> the same result but with differing implementations.
> 
> It seems to me if there is space to support all three for the
> accelerometer that would make reasonable sense. We can tailor the help
> message to guide to the desired approach; yet, all three will work for
> the student whether they are using a recommended approach or something
> that they googled.
> 
> Based on my experience teaching a wide spectrum of children, I do think
> with gentle instruction all levels will be able to use the accelerometer.
> 
> Warmly,
> Carol
> 
> 
> -- 
> *Carol Willing*
> Developer | Willing Consulting
> https://willingconsulting.com
> 
> 
> _______________________________________________
> 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: <http://mail.python.org/pipermail/microbit/attachments/20151101/5b7ea76c/attachment-0001.sig>

From ntoll at ntoll.org  Sun Nov  1 09:27:15 2015
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Sun, 1 Nov 2015 14:27:15 +0000
Subject: [Microbit-Python] Accessor API design on the micro:bit
In-Reply-To: <56361EC6.5000909@ntoll.org>
References: <563396BF.5030703@hastings.org> <5633DDEF.2040100@ntoll.org>
 <CAB+QZVAw7j1ZEt3vqtctcNVWnqQbSS3LJKfknw8G9WHPJNmBBw@mail.gmail.com>
 <5634EC61.4020003@hastings.org>
 <CAB+QZVB7unA1nk_MnLtQx-dSb7DnnvMihPGXKrqwQaj0Bois7A@mail.gmail.com>
 <56351FA9.3080809@willingconsulting.com> <56361EC6.5000909@ntoll.org>
Message-ID: <56362143.1010301@ntoll.org>

This also makes me wonder about descriptor v accessor in other parts of
the API. For example, could we do this?

>>> microbit.pin0  # digital read
1
>>> microbit.pin0  # analog read
234
>>> microbit.pin0 = 0  # digital set
>>> microbit.pin0 = 234  # analog set (0...255)

Not sure whether digital should be 1/0 or True/False. What's the most
widespread convention here? I'm thinking of True/False because that
makes it obvious that the pin is digital rather than it's simply a very
low reading on an analog in.

Thoughts..? Does this make sense..?

N.


On 01/11/15 14:16, Nicholas H.Tollervey wrote:
> OK... what an interesting discussion. :-)
> 
> Then I remembered I had a "captive" 11yo in my home! So I asked him
> which one he preferred (and videoed the discussion). Here's the exchange
> with my son, over Sunday morning breakfast, in all its glory:
> 
> https://www.youtube.com/watch?v=9w4I_xEwlcA
> 
> Put simply he prefers accelerometer.x over .get_x() and .x() because
> it's less typing.
> 
> Emboldened by this feedback I've visited some of his buddies this
> morning (I totally realise this is not at all scientific) to get their
> opinion.
> 
> I'm quite surprised by the results - they agree with Sam: ".x" is the
> unanimous verdict for the best way to express this for all three 11yo
> I've surveyed. I was expecting ".get_x()" to win because it was obvious
> what it was doing.
> 
> But, for example, Max explained that he didn't like all the "weird
> symbols" and mentioned that, "I don't get 'get', isn't it just 'x'? Why
> do I need to 'get' it"..? (Max didn't want to be videoed.)
> 
> Lewis, (whose video is here:
> https://www.youtube.com/watch?v=uyec2VqYwJs) also likes the simplicity
> of ".x" and felt that all the others just looked complicated.
> 
> So, the evidence I've collected so far appears to support Larry and that
> we should trust the heuristic of "simplicity wins".
> 
> Once again, I totally realise this is not scientific in any way. But I
> thought I'd ask those 11yo I had within "range" this morning because
> they're our target audience.
> 
> I've been booked to do some gardening this afternoon... but will return
> this evening.
> 
> I look forward to reading all your thoughts. :-)
> 
> N.
> 
> On 31/10/15 20:08, Carol Willing wrote:
>> While I am joining this discussion after a couple of months of history,
>> I am going to step back for a moment and ask a simple question:
>>
>> Does this have to be a decision between x, x(), get_x()?
>>
>> For the accelerometer (not necessarily all other functionality, but
>> since the accelerometer is built into the chip and accessible without
>> soldering anything, it will be used by many), could we support all three?
>>
>> If I was an 11 year old with access to Google, I could find resources
>> appropriate for an 11 year old that use all three of these approaches:
>> Young Coders workshop, Adafruit/Sparkfun, MicroPython tutorials, Python
>> for Kids book, and others.
>>
>> If I didn't have access to Google, I, as a student, would use `help` or
>> example programs to model what I would choose. It's critical for the
>> educational setting for the approach to be consistent within an example
>> program. While in a perfect world that might imply consistent across all
>> example programs.
>>
>> Yet, we know that there are several approaches to programming that lend
>> the same result but with differing implementations.
>>
>> It seems to me if there is space to support all three for the
>> accelerometer that would make reasonable sense. We can tailor the help
>> message to guide to the desired approach; yet, all three will work for
>> the student whether they are using a recommended approach or something
>> that they googled.
>>
>> Based on my experience teaching a wide spectrum of children, I do think
>> with gentle instruction all levels will be able to use the accelerometer.
>>
>> Warmly,
>> Carol
>>
>>
>> -- 
>> *Carol Willing*
>> Developer | Willing Consulting
>> https://willingconsulting.com
>>
>>
>> _______________________________________________
>> 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: <http://mail.python.org/pipermail/microbit/attachments/20151101/69704ab5/attachment.sig>

From willingc at willingconsulting.com  Sun Nov  1 10:16:26 2015
From: willingc at willingconsulting.com (Carol Willing)
Date: Sun, 1 Nov 2015 07:16:26 -0800
Subject: [Microbit-Python] Accessor API design on the micro:bit
In-Reply-To: <CAB+QZVC=yUvfY4a0rTfJ-DvA8JR95fxLwFtwpc=ZroHqk5DrHQ@mail.gmail.com>
References: <563396BF.5030703@hastings.org> <5633DDEF.2040100@ntoll.org>
 <CAB+QZVAw7j1ZEt3vqtctcNVWnqQbSS3LJKfknw8G9WHPJNmBBw@mail.gmail.com>
 <5634EC61.4020003@hastings.org>
 <CAB+QZVB7unA1nk_MnLtQx-dSb7DnnvMihPGXKrqwQaj0Bois7A@mail.gmail.com>
 <56351FA9.3080809@willingconsulting.com>
 <CAB+QZVC=yUvfY4a0rTfJ-DvA8JR95fxLwFtwpc=ZroHqk5DrHQ@mail.gmail.com>
Message-ID: <56362CCA.2040105@willingconsulting.com>

On 11/1/15 5:39 AM, Michael wrote:
>
> Having read everything you've said (and agreeing with a lot of it), I 
> think you're coming at this from the perspective of "this person/child 
> is motivated to do this". I'm coming at it from the perspective of 
> someone who doesn't yet know they could enjoy this, and has simply had 
> this set as homework for the weekend initially, and there's two 
> outcomes (out of many) that spring to mind. The one that goes home and 
> finds "this is easier than I expected" and *plays* all weekend with 
> it, and the one that goes home and finds it really difficult all 
> weekend for reasons none of us expected or predicted, and spends all 
> weekend fighting it and comes in demoralised. The former is full of 
> win, the latter isn't. And to be clear, I fully expect that both ends 
> of the spectrum will exist if you're going to everyone in an age group.
>

Hi Michael,

I loved your response. Let me add a little perspective on my personal 
philosophy and why I asked the question if all 3 approaches for the 
accelerometer (only) could be implemented.

I have spent the better part of the last 25 years doing outreach with 
students of all ages - all skill levels, all motivation levels, and 
across many different demographic axes. I understand what it is like to 
work with "at risk" youth, children that have come from abusive living 
environments, children that are not engaged, children that have been 
told "they can't". For those children, it's a delicate dance between 
building trust, offering choice, providing structure through firm (but 
still gentle) boundaries.

I have worked with preteen and teen girls that have been told they can't 
because they are not good in math, science, or whatever. I spend time 
with them creating possibilities to bridge their interests to the real 
world impacts of tech. Sometimes it's cracking open the door to 
possibilities, sometimes it is reopening a door that has been slammed 
shut many times.

I have also worked with children with autism and aspergers. I have been 
blessed to see what they create, their pride, and their struggles 
through sensory overstimulation and frustration.

Flexibility and including all children are my two motivating factors.

Honestly, I will make do with whatever materials that I have. I'm just 
trying to broaden the discussion from the binary or "either-or" thinking 
that comes naturally to many of us in the software/engineering world and 
tap into the creativity and many options that we use to prototype and 
iterate :D

Warmly,
Carol
"Humble" door opener

-- 
*Carol Willing*
Developer | Willing Consulting
https://willingconsulting.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151101/243746e9/attachment.html>

From larry at hastings.org  Sun Nov  1 10:57:14 2015
From: larry at hastings.org (Larry Hastings)
Date: Sun, 1 Nov 2015 07:57:14 -0800
Subject: [Microbit-Python] Accessor API design on the micro:bit
In-Reply-To: <56351FA9.3080809@willingconsulting.com>
References: <563396BF.5030703@hastings.org> <5633DDEF.2040100@ntoll.org>
 <CAB+QZVAw7j1ZEt3vqtctcNVWnqQbSS3LJKfknw8G9WHPJNmBBw@mail.gmail.com>
 <5634EC61.4020003@hastings.org>
 <CAB+QZVB7unA1nk_MnLtQx-dSb7DnnvMihPGXKrqwQaj0Bois7A@mail.gmail.com>
 <56351FA9.3080809@willingconsulting.com>
Message-ID: <5636365A.1010209@hastings.org>



On 10/31/2015 01:08 PM, Carol Willing wrote:
> Does this have to be a decision between x, x(), get_x()?

I think it should be, yes.  I remind you of the guiding principle from 
the Zen Of Python: "There should be one (and preferably only one) 
obvious way to do it".  This is so often cited it's been abbreviated as 
TOOWTDI (There's Only One Way To Do It).  No foolin'!

Having only one way to do things enhances code clarity.  If there are 
two ways to read the X value of the accelerometer, I might use one and 
you'd use the other, and then I'd puzzle over your code (and you mine) 
when it came time for code review.


On 11/01/2015 06:27 AM, Nicholas H.Tollervey wrote:
> This also makes me wonder about descriptor v accessor in other parts of
> the API. For example, could we do this?
> >> microbit.pin0  # digital read
> 1
> >> microbit.pin0  # analog read
> 234
> >> microbit.pin0 = 0  # digital set
> >> microbit.pin0 = 234  # analog set (0...255)

We probably /could/, but it would be difficult and it would introduce 
another problem.

You're proposing that we make pin0 (and presumably the others) a 
"property".  In CPython, modules don't support properties.  We could get 
around that by making "microbit" not be a module--or, perhaps, a 
subclass of module that supports properties.

(Of course, we're not /using/ CPython, we're using /MicroPython/. And 
it's possible MicroPython modules actually /do/ support properties.   
Damien?)


The other technological problem it raises: we could no longer use 
attributes on the pin0 object.  For example we could no longer say:

    microbit.pin0.set_digital_mode(True)

(or whatever the method is called here, I forgot).  Python would see 
microbit.pin0 and say "oh, that's a property", call the property's 
getter function, and return the result.  If the result was 234 then this 
would be the same as 234.set_digital_mode(True) which clearly won't work.

(The only way to get your hands on the actual pin0 object would be 
through the dict, e.g. microbit.__dict__['pin0'].set_digital_mode(True) 
would work.  But obviously that's a bad API.)


My final argument is subjective.  I'll remind you that at the PyCon UK 
sprints I was actually arguing for this exact thing--that you should set 
the value of pin0 by saying microbit.pin0 = True or what have you.  But 
I was convinced to change my mind.  What did it was, again, citing the 
rule of thumb for when to make something a property: it shouldn't feel 
like it is /doing/ something.  A property should behave like a passive 
object.  But the I/O pins are doing I/O, and I/O is traditionally an 
active API.  I've never seen a file object or a socket that behaved like 
a passive object.

Again, it's a subjective distinction.  But checking the accelerometer 
reading feels like a passive activity, like looking at my watch for the 
time.  Whereas reading the input pin feels more active, like checking my 
mailbox to see if I have any letters.


Cheers,


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151101/23060a7f/attachment-0001.html>

From sparks.m at gmail.com  Sun Nov  1 13:02:04 2015
From: sparks.m at gmail.com (Michael)
Date: Sun, 1 Nov 2015 18:02:04 +0000
Subject: [Microbit-Python] Accessor API design on the micro:bit
In-Reply-To: <56362143.1010301@ntoll.org>
References: <563396BF.5030703@hastings.org> <5633DDEF.2040100@ntoll.org>
 <CAB+QZVAw7j1ZEt3vqtctcNVWnqQbSS3LJKfknw8G9WHPJNmBBw@mail.gmail.com>
 <5634EC61.4020003@hastings.org>
 <CAB+QZVB7unA1nk_MnLtQx-dSb7DnnvMihPGXKrqwQaj0Bois7A@mail.gmail.com>
 <56351FA9.3080809@willingconsulting.com>
 <56361EC6.5000909@ntoll.org> <56362143.1010301@ntoll.org>
Message-ID: <CAB+QZVBSKuBiAggdZ0X0ZLLQRytX6F-bGy-GPj6o_eWWe0TZew@mail.gmail.com>

Hi Nick,

What about HIGH/LOW instead? (I tend to use that rather than True/False,
since IMO it's clearer)

Michael

On 1 November 2015 at 14:27, Nicholas H.Tollervey <ntoll at ntoll.org> wrote:

> This also makes me wonder about descriptor v accessor in other parts of
> the API. For example, could we do this?
>
> >>> microbit.pin0  # digital read
> 1
> >>> microbit.pin0  # analog read
> 234
> >>> microbit.pin0 = 0  # digital set
> >>> microbit.pin0 = 234  # analog set (0...255)
>
> Not sure whether digital should be 1/0 or True/False. What's the most
> widespread convention here? I'm thinking of True/False because that
> makes it obvious that the pin is digital rather than it's simply a very
> low reading on an analog in.
>
> Thoughts..? Does this make sense..?
>
> N.
>
>
> On 01/11/15 14:16, Nicholas H.Tollervey wrote:
> > OK... what an interesting discussion. :-)
> >
> > Then I remembered I had a "captive" 11yo in my home! So I asked him
> > which one he preferred (and videoed the discussion). Here's the exchange
> > with my son, over Sunday morning breakfast, in all its glory:
> >
> > https://www.youtube.com/watch?v=9w4I_xEwlcA
> >
> > Put simply he prefers accelerometer.x over .get_x() and .x() because
> > it's less typing.
> >
> > Emboldened by this feedback I've visited some of his buddies this
> > morning (I totally realise this is not at all scientific) to get their
> > opinion.
> >
> > I'm quite surprised by the results - they agree with Sam: ".x" is the
> > unanimous verdict for the best way to express this for all three 11yo
> > I've surveyed. I was expecting ".get_x()" to win because it was obvious
> > what it was doing.
> >
> > But, for example, Max explained that he didn't like all the "weird
> > symbols" and mentioned that, "I don't get 'get', isn't it just 'x'? Why
> > do I need to 'get' it"..? (Max didn't want to be videoed.)
> >
> > Lewis, (whose video is here:
> > https://www.youtube.com/watch?v=uyec2VqYwJs) also likes the simplicity
> > of ".x" and felt that all the others just looked complicated.
> >
> > So, the evidence I've collected so far appears to support Larry and that
> > we should trust the heuristic of "simplicity wins".
> >
> > Once again, I totally realise this is not scientific in any way. But I
> > thought I'd ask those 11yo I had within "range" this morning because
> > they're our target audience.
> >
> > I've been booked to do some gardening this afternoon... but will return
> > this evening.
> >
> > I look forward to reading all your thoughts. :-)
> >
> > N.
> >
> > On 31/10/15 20:08, Carol Willing wrote:
> >> While I am joining this discussion after a couple of months of history,
> >> I am going to step back for a moment and ask a simple question:
> >>
> >> Does this have to be a decision between x, x(), get_x()?
> >>
> >> For the accelerometer (not necessarily all other functionality, but
> >> since the accelerometer is built into the chip and accessible without
> >> soldering anything, it will be used by many), could we support all
> three?
> >>
> >> If I was an 11 year old with access to Google, I could find resources
> >> appropriate for an 11 year old that use all three of these approaches:
> >> Young Coders workshop, Adafruit/Sparkfun, MicroPython tutorials, Python
> >> for Kids book, and others.
> >>
> >> If I didn't have access to Google, I, as a student, would use `help` or
> >> example programs to model what I would choose. It's critical for the
> >> educational setting for the approach to be consistent within an example
> >> program. While in a perfect world that might imply consistent across all
> >> example programs.
> >>
> >> Yet, we know that there are several approaches to programming that lend
> >> the same result but with differing implementations.
> >>
> >> It seems to me if there is space to support all three for the
> >> accelerometer that would make reasonable sense. We can tailor the help
> >> message to guide to the desired approach; yet, all three will work for
> >> the student whether they are using a recommended approach or something
> >> that they googled.
> >>
> >> Based on my experience teaching a wide spectrum of children, I do think
> >> with gentle instruction all levels will be able to use the
> accelerometer.
> >>
> >> Warmly,
> >> Carol
> >>
> >>
> >> --
> >> *Carol Willing*
> >> Developer | Willing Consulting
> >> https://willingconsulting.com
> >>
> >>
> >> _______________________________________________
> >> 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: <http://mail.python.org/pipermail/microbit/attachments/20151101/52d068f8/attachment.html>

From sparks.m at gmail.com  Sun Nov  1 13:16:28 2015
From: sparks.m at gmail.com (Michael)
Date: Sun, 1 Nov 2015 18:16:28 +0000
Subject: [Microbit-Python] Accessor API design on the micro:bit
In-Reply-To: <56362CCA.2040105@willingconsulting.com>
References: <563396BF.5030703@hastings.org> <5633DDEF.2040100@ntoll.org>
 <CAB+QZVAw7j1ZEt3vqtctcNVWnqQbSS3LJKfknw8G9WHPJNmBBw@mail.gmail.com>
 <5634EC61.4020003@hastings.org>
 <CAB+QZVB7unA1nk_MnLtQx-dSb7DnnvMihPGXKrqwQaj0Bois7A@mail.gmail.com>
 <56351FA9.3080809@willingconsulting.com>
 <CAB+QZVC=yUvfY4a0rTfJ-DvA8JR95fxLwFtwpc=ZroHqk5DrHQ@mail.gmail.com>
 <56362CCA.2040105@willingconsulting.com>
Message-ID: <CAB+QZVBdynbH+1TSoBL=_1MS2J2bG+EEJFpknFUKo1Hk=8a1+Q@mail.gmail.com>

Hi Carol,


I don't claim to be an authority or anything. I think you undersell
yourself by calling yourself a "humble" door opener. I've only been helping
with local youth groups for only a few years now --*nowhere* near your
level of experience, so I think your comments are really inspiring, and
glad to listen to your advice :-)

I must admit, usually I'm a big advocate for "let's allow this or
that" rather than "let's just do this or that". In this case I think we
should do "this OR that" (ideally across the whole API not just one area),
and any exceptions are well documented. (Reason being less to learn in
order to use everything on the device)


Michael.

On 1 November 2015 at 15:16, Carol Willing <willingc at willingconsulting.com>
wrote:

> Hi Michael,
>
> I loved your response. Let me add a little perspective on my personal
> philosophy and why I asked the question if all 3 approaches for the
> accelerometer (only) could be implemented.
>
> I have spent the better part of the last 25 years doing outreach with
> students of all ages - all skill levels, all motivation levels, and across
> many different demographic axes. I understand what it is like to work with
> "at risk" youth, children that have come from abusive living environments,
> children that are not engaged, children that have been told "they can't".
> For those children, it's a delicate dance between building trust, offering
> choice, providing structure through firm (but still gentle) boundaries.
>
> I have worked with preteen and teen girls that have been told they can't
> because they are not good in math, science, or whatever. I spend time with
> them creating possibilities to bridge their interests to the real world
> impacts of tech. Sometimes it's cracking open the door to possibilities,
> sometimes it is reopening a door that has been slammed shut many times.
>
> I have also worked with children with autism and aspergers. I have been
> blessed to see what they create, their pride, and their struggles through
> sensory overstimulation and frustration.
>
> Flexibility and including all children are my two motivating factors.
>
> Honestly, I will make do with whatever materials that I have. I'm just
> trying to broaden the discussion from the binary or "either-or" thinking
> that comes naturally to many of us in the software/engineering world and
> tap into the creativity and many options that we use to prototype and
> iterate :D
>
> Warmly,
> Carol
> "Humble" door opener
>
> --
> *Carol Willing*
> Developer | Willing Consulting
> https://willingconsulting.com
>
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151101/fb7bc4f5/attachment.html>

From willingc at willingconsulting.com  Sun Nov  1 12:51:53 2015
From: willingc at willingconsulting.com (Carol Willing)
Date: Sun, 1 Nov 2015 09:51:53 -0800
Subject: [Microbit-Python] Accessor API design on the micro:bit
In-Reply-To: <5636365A.1010209@hastings.org>
References: <563396BF.5030703@hastings.org> <5633DDEF.2040100@ntoll.org>
 <CAB+QZVAw7j1ZEt3vqtctcNVWnqQbSS3LJKfknw8G9WHPJNmBBw@mail.gmail.com>
 <5634EC61.4020003@hastings.org>
 <CAB+QZVB7unA1nk_MnLtQx-dSb7DnnvMihPGXKrqwQaj0Bois7A@mail.gmail.com>
 <56351FA9.3080809@willingconsulting.com> <5636365A.1010209@hastings.org>
Message-ID: <56365139.9070507@willingconsulting.com>

On 11/1/15 7:57 AM, Larry Hastings wrote:
>
>
> On 10/31/2015 01:08 PM, Carol Willing wrote:
>> Does this have to be a decision between x, x(), get_x()?
>
> I think it should be, yes.  I remind you of the guiding principle from 
> the Zen Of Python: "There should be one (and preferably only one) 
> obvious way to do it".  This is so often cited it's been abbreviated 
> as TOOWTDI (There's Only One Way To Do It).  No foolin'!

Larry, Ideally one "obvious" way but there are frequently convenience 
functions that do the same/similar thing :P Though your point is taken :-)

>
> Having only one way to do things enhances code clarity.  If there are 
> two ways to read the X value of the accelerometer, I might use one and 
> you'd use the other, and then I'd puzzle over your code (and you mine) 
> when it came time for code review.
>
>
> On 11/01/2015 06:27 AM, Nicholas H.Tollervey wrote:
>> This also makes me wonder about descriptor v accessor in other parts of
>> the API. For example, could we do this?
>> >> microbit.pin0  # digital read
>> 1
>> >> microbit.pin0  # analog read
>> 234
>> >> microbit.pin0 = 0  # digital set
>> >> microbit.pin0 = 234  # analog set (0...255)
>
> We probably /could/, but it would be difficult and it would introduce 
> another problem.
>
> You're proposing that we make pin0 (and presumably the others) a 
> "property".  In CPython, modules don't support properties.  We could 
> get around that by making "microbit" not be a module--or, perhaps, a 
> subclass of module that supports properties.
>
> (Of course, we're not /using/ CPython, we're using /MicroPython/. And 
> it's possible MicroPython modules actually /do/ support properties.   
> Damien?)
>
>
> The other technological problem it raises: we could no longer use 
> attributes on the pin0 object.  For example we could no longer say:
>
>     microbit.pin0.set_digital_mode(True)
>
> (or whatever the method is called here, I forgot).  Python would see 
> microbit.pin0 and say "oh, that's a property", call the property's 
> getter function, and return the result.  If the result was 234 then 
> this would be the same as 234.set_digital_mode(True) which clearly 
> won't work.
>
> (The only way to get your hands on the actual pin0 object would be 
> through the dict, e.g. 
> microbit.__dict__['pin0'].set_digital_mode(True) would work.  But 
> obviously that's a bad API.)
>
>
> My final argument is subjective.  I'll remind you that at the PyCon UK 
> sprints I was actually arguing for this exact thing--that you should 
> set the value of pin0 by saying microbit.pin0 = True or what have 
> you.  But I was convinced to change my mind.  What did it was, again, 
> citing the rule of thumb for when to make something a property: it 
> shouldn't feel like it is /doing/ something.  A property should behave 
> like a passive object.  But the I/O pins are doing I/O, and I/O is 
> traditionally an active API.  I've never seen a file object or a 
> socket that behaved like a passive object.
>
> Again, it's a subjective distinction.  But checking the accelerometer 
> reading feels like a passive activity, like looking at my watch for 
> the time.  Whereas reading the input pin feels more active, like 
> checking my mailbox to see if I have any letters

While I would love to see a matrix of approach vs. benefits and 
downsides from a student and teacher perspective, I don't have a strong 
preference. What I do think we are all in agreement on is that good 
documentation and clarity in help messages will be important for the end 
users.

Warmly,
Carol

-- 
*Carol Willing*
Developer | Willing Consulting
https://willingconsulting.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151101/7e3c0a52/attachment-0001.html>

From willingc at willingconsulting.com  Sun Nov  1 15:09:56 2015
From: willingc at willingconsulting.com (Carol Willing)
Date: Sun, 1 Nov 2015 12:09:56 -0800
Subject: [Microbit-Python] Accessor API design on the micro:bit
In-Reply-To: <CAB+QZVBdynbH+1TSoBL=_1MS2J2bG+EEJFpknFUKo1Hk=8a1+Q@mail.gmail.com>
References: <563396BF.5030703@hastings.org> <5633DDEF.2040100@ntoll.org>
 <CAB+QZVAw7j1ZEt3vqtctcNVWnqQbSS3LJKfknw8G9WHPJNmBBw@mail.gmail.com>
 <5634EC61.4020003@hastings.org>
 <CAB+QZVB7unA1nk_MnLtQx-dSb7DnnvMihPGXKrqwQaj0Bois7A@mail.gmail.com>
 <56351FA9.3080809@willingconsulting.com>
 <CAB+QZVC=yUvfY4a0rTfJ-DvA8JR95fxLwFtwpc=ZroHqk5DrHQ@mail.gmail.com>
 <56362CCA.2040105@willingconsulting.com>
 <CAB+QZVBdynbH+1TSoBL=_1MS2J2bG+EEJFpknFUKo1Hk=8a1+Q@mail.gmail.com>
Message-ID: <56367194.7010309@willingconsulting.com>

On 11/1/15 10:16 AM, Michael wrote:
> Hi Carol,
>
>
> I don't claim to be an authority or anything. I think you undersell 
> yourself by calling yourself a "humble" door opener. I've only been 
> helping with local youth groups for only a few years now --*nowhere* 
> near your level of experience, so I think your comments are really 
> inspiring, and glad to listen to your advice :-)

I'm pretty sure that our collective experiences and discussion will make 
something truly awesome :-)

>
> I must admit, usually I'm a big advocate for "let's allow this or 
> that" rather than "let's just do this or that". In this case I think 
> we should do "this OR that" (ideally across the whole API not just one 
> area), and any exceptions are well documented. (Reason being less to 
> learn in order to use everything on the device)

I agree. I'm just throwing out ideas to make sure that we know "why" we 
are choosing one approach over another and that we are not prematurely 
eliminating an option that may give flexibility down the road (since I'm 
working under the assumption that classrooms of students will not easily 
be upgrading their microbit - which may be a flawed assumption).


Thanks!
Carol



-- 
*Carol Willing*
Developer | Willing Consulting
https://willingconsulting.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151101/68999421/attachment.html>

From dhylands at gmail.com  Sun Nov  1 15:45:33 2015
From: dhylands at gmail.com (Dave Hylands)
Date: Sun, 1 Nov 2015 12:45:33 -0800
Subject: [Microbit-Python] Accessor API design on the micro:bit
In-Reply-To: <56367194.7010309@willingconsulting.com>
References: <563396BF.5030703@hastings.org> <5633DDEF.2040100@ntoll.org>
 <CAB+QZVAw7j1ZEt3vqtctcNVWnqQbSS3LJKfknw8G9WHPJNmBBw@mail.gmail.com>
 <5634EC61.4020003@hastings.org>
 <CAB+QZVB7unA1nk_MnLtQx-dSb7DnnvMihPGXKrqwQaj0Bois7A@mail.gmail.com>
 <56351FA9.3080809@willingconsulting.com>
 <CAB+QZVC=yUvfY4a0rTfJ-DvA8JR95fxLwFtwpc=ZroHqk5DrHQ@mail.gmail.com>
 <56362CCA.2040105@willingconsulting.com>
 <CAB+QZVBdynbH+1TSoBL=_1MS2J2bG+EEJFpknFUKo1Hk=8a1+Q@mail.gmail.com>
 <56367194.7010309@willingconsulting.com>
Message-ID: <CABi1daHhGDVxen2SpG_rF8LUmna1nHLWJCJ2KBHr2HVjx-qFig@mail.gmail.com>

Hi,

My name is Dave Hylands. I'm one of the contributers to the MicroPython
project, and I'm still learning what is and isn't pythonic. I have zero
experience teaching kids, so take anything I say here with a grain of salt.
I'm a professional software developer who works mostly in C and C++ and got
interested in MicroPython for some of my robotics projects.

I joined this mailing list a few days ago, somewhere in the middle of this
thread.

I think that looking at a single object, like the accelerator, you can come
up with an ideal way of interfacing with it.

Then you can look at other objects like a pin and its ideal way of
interfacing might be slightly different (because with a pin you can do more
than just read it, you can set it, you can change attributes about it like
pull-up & pull-down, etc).

When you come up with an ideal interface for each object/peripheral, as a
programmer, I actually find this awkward. It means I'm forced to read the
documentation to figure out how to use it.

As a programmer, I prefer to see consistency across interfaces. So, just
pulling this out as an example, for a pin, I might want pin0.value = True
and read using x = pin0.value. If this were done for other objects, then I
would have expected that the accelerometer would be accessed using
accel.x.value (for consistency). I could imagine that some accelerometers
might have additional attributes beyond just their value.

Anwways - I'll shut up now - just thought I'd add a small interjection.

-- 
Dave Hylands
Shuswap, BC, Canada
http://www.davehylands.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151101/1cfcd1ec/attachment.html>

From ntoll at ntoll.org  Sun Nov  1 17:26:00 2015
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Sun, 1 Nov 2015 22:26:00 +0000
Subject: [Microbit-Python] Sharing devices
Message-ID: <56369178.9000603@ntoll.org>

Hi Folks,

So those of you who already have a device: this doesn't really apply to
you but I'd love to hear your feedback all the same.

I've been chatting with Naomi Ceder (on this mailing list) about
improving the diversity of contributors to our efforts. A fallout of
this discussion was an email about how to make best use of the handful
of micro:bits I now have to send out to people (these are in addition to
those handed out at PyCon UK).

We hit upon the idea of a "world tour" combined with the concept of a
"friendship cake" (viz: https://en.wikipedia.org/wiki/Herman_cake)
mashed up with GeoCaching (bear with me here...).

:-)

Essentially, I'll seed the five devices to people who have expressed an
interest and who are spread out around the world. I'll contact these
people off list so I can grab their postal address. Each micro:bit has a
name: Mary, Meena, Mandela, Mei-Xiu and Mohandas and maybe even a
mission (for example, Mary might want to travel around the world in a
westerly direction). You get the idea. It's supposed to be fun and
engaging for both the Python community and kids when they start to learn
about how the project was made.

Once you get your device you have a week to do something with it: create
a Python project, write a tutorial, plug it into some hardware... that
sort of thing. Most importantly, we get to see different members of the
Python community contribute to the Python aspect of the micro:bit
project. Once you've created your contribution you should log what
you've done in a GeoCaching like diary/travel-log that I've hacked
together this evening. It's *very* early days and a lot is missing but
you can get the idea by pointing your browser here:

http://microworldtour.github.io/

The source code is static HTML and you contribute via pull requests to
this repository:

https://github.com/microworldtour/microworldtour.github.io

Once you've had it a week you should decide who the next person should
be to get your micro:bit. This will be entirely *your* decision.
However, the candidates for you to choose from will be listed on a (to
be written) page on the site. I'll make sure it's all obvious what you
need to do. New candidates will get onto the list by creating a pull
request. :-)

I'll write up more instructions tomorrow.

In the meantime I'd love to hear feedback. Basically I'm trying to solve
three problems:

1) Getting the handful of micro:bits into the hands of as many people as
possible.

2) Ensuring we have contributions from a diverse number of people spread
all over the world (Python *is* an international community after all).

3) Creating resources and a fun record of what we've been up. The
website would be a cute "advert" for collaborators.

Does this make sense..?

As always, constructive critique, comments and idea are 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: <http://mail.python.org/pipermail/microbit/attachments/20151101/e18c3972/attachment.sig>

From damien.p.george at gmail.com  Sun Nov  1 18:59:21 2015
From: damien.p.george at gmail.com (Damien George)
Date: Sun, 1 Nov 2015 23:59:21 +0000
Subject: [Microbit-Python] Accessor API design on the micro:bit
In-Reply-To: <5636365A.1010209@hastings.org>
References: <563396BF.5030703@hastings.org> <5633DDEF.2040100@ntoll.org>
 <CAB+QZVAw7j1ZEt3vqtctcNVWnqQbSS3LJKfknw8G9WHPJNmBBw@mail.gmail.com>
 <5634EC61.4020003@hastings.org>
 <CAB+QZVB7unA1nk_MnLtQx-dSb7DnnvMihPGXKrqwQaj0Bois7A@mail.gmail.com>
 <56351FA9.3080809@willingconsulting.com>
 <5636365A.1010209@hastings.org>
Message-ID: <CANw+Mznf1J4tp0m4=AFpMNgu+4g48AmL7uNRx3qMjVvvdU_RsQ@mail.gmail.com>

Hi all,

A long discussion!  Some remarks below.

> The other technological problem it raises: we could no longer use attributes
> on the pin0 object.  For example we could no longer say:
>
> microbit.pin0.set_digital_mode(True)

The way it currently works is: pin0.read_digital(),
pin0.read_analog(), pin0.write_digital(x), pin0.write_analog(y).  So
if you wan't to go down the property route, it'd translate to:

pin0.digital_value # get
pin0.digital_value = 1 # set
pin0.analog_value # get
pin0.analog_value = 123 # set

That's not too bad.  But then how about pin0.is_touched() ?
pin0.touched_value as read-only property seems awkward.

And then pin0.set_analog_period()... does it become pin0.analog_period
= 123?  It's going to be a fine line between deciding whether
something is a function or property, and then if some are functions
and some properties that requires effort remembering, and time
teaching.

> My final argument is subjective.  I'll remind you that at the PyCon UK
> sprints I was actually arguing for this exact thing--that you should set the
> value of pin0 by saying microbit.pin0 = True or what have you.  But I was
> convinced to change my mind.  What did it was, again, citing the rule of
> thumb for when to make something a property: it shouldn't feel like it is
> doing something.  A property should behave like a passive object.

Actually, getting the value of the accelerometer is doing something
very non-trivial: it does an I2C read on the bus to update the value.
Whether this implementation detail (is it an implementation detail?)
should factor in to the decision to use (or not) properties is an
interesting discussion.

One big advantage of making everything functions is that you have room
to grow the API in the future if the function call needs to have
arguments added to it.  For example, maybe getting the accelerometer
value has an optional argument to force the update of the value (ie do
an I2C read even if one was just done), or maybe there's an argument
to specify the g-range.

Also, consider the button API: do we want button.value as a read-only
property?  What about button.was_pressed()? [this method checks if the
button was pressed since last time, and resets the flag]  It would be
difficult explaining to an 11yo that have button.value is a property
while button.was_pressed() is a method.

My argument is: functions are more general/powerful than properties
and are going to be needed in some places, so best to just have
everything a function and teach only that concept.

Cheers,
Damien.

From ntoll at ntoll.org  Mon Nov  2 03:23:01 2015
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Mon, 2 Nov 2015 08:23:01 +0000
Subject: [Microbit-Python] Accessor API design on the micro:bit
In-Reply-To: <CANw+Mznf1J4tp0m4=AFpMNgu+4g48AmL7uNRx3qMjVvvdU_RsQ@mail.gmail.com>
References: <563396BF.5030703@hastings.org> <5633DDEF.2040100@ntoll.org>
 <CAB+QZVAw7j1ZEt3vqtctcNVWnqQbSS3LJKfknw8G9WHPJNmBBw@mail.gmail.com>
 <5634EC61.4020003@hastings.org>
 <CAB+QZVB7unA1nk_MnLtQx-dSb7DnnvMihPGXKrqwQaj0Bois7A@mail.gmail.com>
 <56351FA9.3080809@willingconsulting.com> <5636365A.1010209@hastings.org>
 <CANw+Mznf1J4tp0m4=AFpMNgu+4g48AmL7uNRx3qMjVvvdU_RsQ@mail.gmail.com>
Message-ID: <56371D65.9010801@ntoll.org>

OK...

On 01/11/15 23:59, Damien George wrote:

<snip lots of conversation/>

> My argument is: functions are more general/powerful than properties
> and are going to be needed in some places, so best to just have
> everything a function and teach only that concept.
>

I get this (and I'm playing devil's advocate here).

The concern Larry's original post has raised for me (again) is basically
naming and simplicity. The kids I spoke to thought the underscores and
parenthesis "complicated" compared to the descriptor.

In terms of the accelerometer could the function just be as follows..?

>>> accelerometer.x()
>>> accelerometer.y()
>>> accelerometer.z()

While there's a very real danger of us Yak shaving the hell out of this,
I believe it's so important that we get our API right, up front.

By the way, my rule of thumb when thinking about the above was:

* Assume functions/methods because that appears to be the way people
want to go.

* Avoid multi-word names.

* Use simple obvious words.

* Less typing.

How would that translate to the button API..? That's hard...

>>> button.on()  # instead of button.is_pressed()
>>> button.pressed()  # instead of was_pressed()

Not sure I like the above, but I hope you can see where I'm trying to
get to here. I'm definitely trying to avoid function_names_like_this()
which would be hard to type and/or look intimidating to an 11yo.

Thoughts, feedback and constructive critique most welcome..!

N.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/microbit/attachments/20151102/5923f330/attachment.sig>

From steve at blanc.ltd.uk  Mon Nov  2 05:55:56 2015
From: steve at blanc.ltd.uk (Stephen Hawkes)
Date: Mon, 02 Nov 2015 10:55:56 +0000
Subject: [Microbit-Python] Sharing devices
In-Reply-To: <56369178.9000603@ntoll.org>
References: <56369178.9000603@ntoll.org>
 <ecbea439998bc8d05fa09e5b8328f061@frontapp.com>
Message-ID: <ecbea439998bc8d05fa09e5b8328f061@frontapp.com>

Do let me know if some design love would be helpful here.


Best



~Steve


-- 



Blanc Limited

Blythe Valley Innovation Centre

Central Boulevard

Solihull, B90 8AJ



+44 (0) 33 33 44 7 800

www.blanc.ltd.uk




 > On Sun, Nov 1, 2015 at 10:26 pm, <ntoll at ntoll.org> Nicholas H.Tollervey 
wrote:


 > Hi Folks,


 > So those of you who already have a device: this doesn't really apply to

 > you but I'd love to hear your feedback all the same.


 > I've been chatting with Naomi Ceder (on this mailing list) about

 > improving the diversity of contributors to our efforts. A fallout of

 > this discussion was an email about how to make best use of the handful

 > of micro:bits I now have to send out to people (these are in addition to

 > those handed out at PyCon UK).


 > We hit upon the idea of a "world tour" combined with the concept of a

 > "friendship cake" (viz: https://en.wikipedia.org/wiki/Herman_cake)

 > mashed up with GeoCaching (bear with me here...).


 > :-)


 > Essentially, I'll seed the five devices to people who have expressed an

 > interest and who are spread out around the world. I'll contact these

 > people off list so I can grab their postal address. Each micro:bit has a

 > name: Mary, Meena, Mandela, Mei-Xiu and Mohandas and maybe even a

 > mission (for example, Mary might want to travel around the world in a

 > westerly direction). You get the idea. It's supposed to be fun and

 > engaging for both the Python community and kids when they start to learn

 > about how the project was made.


 > Once you get your device you have a week to do something with it: create

 > a Python project, write a tutorial, plug it into some hardware... that

 > sort of thing. Most importantly, we get to see different members of the

 > Python community contribute to the Python aspect of the micro:bit

 > project. Once you've created your contribution you should log what

 > you've done in a GeoCaching like diary/travel-log that I've hacked

 > together this evening. It's *very* early days and a lot is missing but

 > you can get the idea by pointing your browser here:


 > http://microworldtour.github.io/


 > The source code is static HTML and you contribute via pull requests to

 > this repository:


 > https://github.com/microworldtour/microworldtour.github.io


 > Once you've had it a week you should decide who the next person should

 > be to get your micro:bit. This will be entirely *your* decision.

 > However, the candidates for you to choose from will be listed on a (to

 > be written) page on the site. I'll make sure it's all obvious what you

 > need to do. New candidates will get onto the list by creating a pull

 > request. :-)


 > I'll write up more instructions tomorrow.


 > In the meantime I'd love to hear feedback. Basically I'm trying to solve

 > three problems:


 > 1) Getting the handful of micro:bits into the hands of as many people as

 > possible.


 > 2) Ensuring we have contributions from a diverse number of people spread

 > all over the world (Python *is* an international community after all).


 > 3) Creating resources and a fun record of what we've been up. The

 > website would be a cute "advert" for collaborators.


 > Does this make sense..?


 > As always, constructive critique, comments and idea are 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: <http://mail.python.org/pipermail/microbit/attachments/20151102/526230b8/attachment.html>

From mark at hotpy.org  Mon Nov  2 13:32:05 2015
From: mark at hotpy.org (Mark Shannon)
Date: Mon, 2 Nov 2015 18:32:05 +0000
Subject: [Microbit-Python] Accessor API design on the micro:bit
In-Reply-To: <56362143.1010301@ntoll.org>
References: <563396BF.5030703@hastings.org> <5633DDEF.2040100@ntoll.org>
 <CAB+QZVAw7j1ZEt3vqtctcNVWnqQbSS3LJKfknw8G9WHPJNmBBw@mail.gmail.com>
 <5634EC61.4020003@hastings.org>
 <CAB+QZVB7unA1nk_MnLtQx-dSb7DnnvMihPGXKrqwQaj0Bois7A@mail.gmail.com>
 <56351FA9.3080809@willingconsulting.com> <56361EC6.5000909@ntoll.org>
 <56362143.1010301@ntoll.org>
Message-ID: <5637AC25.7090101@hotpy.org>



On 01/11/15 14:27, Nicholas H.Tollervey wrote:
> This also makes me wonder about descriptor v accessor in other parts of
> the API. For example, could we do this?
>
>>>> microbit.pin0  # digital read
> 1

We could, but we shouldn't.
microbit.pin0 should be a pin, as it is as at the moment.
 >>> microbit.pin0
<MicroBitPin ...>

>>>> microbit.pin0  # analog read
> 234
>>>> microbit.pin0 = 0  # digital set
>>>> microbit.pin0 = 234  # analog set (0...255)

Again no. Normal assignment rules for an attribute should apply.
 >>> microbit.pin0 = "Hello"
 >>> microbit.pin0
"Hello"

Plus, we would have to change microbit from a module to an instance of a 
custom class, in order to support descriptors.

If we really want to use properties for pins then it should be:
microbit.pin0.digital(_value)
and
microbit.pin0.analog(_value)

But I prefer the read()/write() methods.

For the accelerometer, there is no digital/analog state change, and you 
cannot write to it. So accelerometer.x seems consistent with "x" 
appearing to be a simple attribute of the accelerometer object.

IMO, descriptors should generally appear to have the same interface as 
simple object attributes, even if they are "special" under the covers.

>
> Not sure whether digital should be 1/0 or True/False. What's the most
> widespread convention here? I'm thinking of True/False because that
> makes it obvious that the pin is digital rather than it's simply a very
> low reading on an analog in.
I think digit(al) means digit in base-2. So I prefer 0/1.
Also pins are high/low. 1 for high, 0 for low seems more natural than 
true for high and false for low.

Cheers,
Mark.

>
> Thoughts..? Does this make sense..?
>
> N.
>
>
> On 01/11/15 14:16, Nicholas H.Tollervey wrote:
>> OK... what an interesting discussion. :-)
>>
>> Then I remembered I had a "captive" 11yo in my home! So I asked him
>> which one he preferred (and videoed the discussion). Here's the exchange
>> with my son, over Sunday morning breakfast, in all its glory:
>>
>> https://www.youtube.com/watch?v=9w4I_xEwlcA
>>
>> Put simply he prefers accelerometer.x over .get_x() and .x() because
>> it's less typing.
>>
>> Emboldened by this feedback I've visited some of his buddies this
>> morning (I totally realise this is not at all scientific) to get their
>> opinion.
>>
>> I'm quite surprised by the results - they agree with Sam: ".x" is the
>> unanimous verdict for the best way to express this for all three 11yo
>> I've surveyed. I was expecting ".get_x()" to win because it was obvious
>> what it was doing.
>>
>> But, for example, Max explained that he didn't like all the "weird
>> symbols" and mentioned that, "I don't get 'get', isn't it just 'x'? Why
>> do I need to 'get' it"..? (Max didn't want to be videoed.)
>>
>> Lewis, (whose video is here:
>> https://www.youtube.com/watch?v=uyec2VqYwJs) also likes the simplicity
>> of ".x" and felt that all the others just looked complicated.
>>
>> So, the evidence I've collected so far appears to support Larry and that
>> we should trust the heuristic of "simplicity wins".
>>
>> Once again, I totally realise this is not scientific in any way. But I
>> thought I'd ask those 11yo I had within "range" this morning because
>> they're our target audience.
>>
>> I've been booked to do some gardening this afternoon... but will return
>> this evening.
>>
>> I look forward to reading all your thoughts. :-)
>>
>> N.
>>
>> On 31/10/15 20:08, Carol Willing wrote:
>>> While I am joining this discussion after a couple of months of history,
>>> I am going to step back for a moment and ask a simple question:
>>>
>>> Does this have to be a decision between x, x(), get_x()?
>>>
>>> For the accelerometer (not necessarily all other functionality, but
>>> since the accelerometer is built into the chip and accessible without
>>> soldering anything, it will be used by many), could we support all three?
>>>
>>> If I was an 11 year old with access to Google, I could find resources
>>> appropriate for an 11 year old that use all three of these approaches:
>>> Young Coders workshop, Adafruit/Sparkfun, MicroPython tutorials, Python
>>> for Kids book, and others.
>>>
>>> If I didn't have access to Google, I, as a student, would use `help` or
>>> example programs to model what I would choose. It's critical for the
>>> educational setting for the approach to be consistent within an example
>>> program. While in a perfect world that might imply consistent across all
>>> example programs.
>>>
>>> Yet, we know that there are several approaches to programming that lend
>>> the same result but with differing implementations.
>>>
>>> It seems to me if there is space to support all three for the
>>> accelerometer that would make reasonable sense. We can tailor the help
>>> message to guide to the desired approach; yet, all three will work for
>>> the student whether they are using a recommended approach or something
>>> that they googled.
>>>
>>> Based on my experience teaching a wide spectrum of children, I do think
>>> with gentle instruction all levels will be able to use the accelerometer.
>>>
>>> Warmly,
>>> Carol
>>>
>>>
>>> --
>>> *Carol Willing*
>>> Developer | Willing Consulting
>>> https://willingconsulting.com
>>>
>>>
>>> _______________________________________________
>>> 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 tom at viner.tv  Mon Nov  2 14:41:39 2015
From: tom at viner.tv (Tom Viner)
Date: Mon, 2 Nov 2015 19:41:39 +0000
Subject: [Microbit-Python] Sharing devices
In-Reply-To: <56369178.9000603@ntoll.org>
References: <56369178.9000603@ntoll.org>
Message-ID: <CANBSuyFkxHxM4fzkwdznmhea22EzLM+cV0Evg0UgmsUvXin0gQ@mail.gmail.com>

This sounds like a really fun idea Nic.

How do you envisage gaining the attention of Python users round the world?
Local mailing lists and user groups? Who would be responsible for posting
to these groups?

Then choosing the next person to send the device to, would you have
prospective recipients write a short bio or intro to their contribution
idea? Then have the current holders choose from that list? (and apply to
see a postal address - no changing your mind, you can't read everyone's
address type thing, but you can see all applicants on a suitably
approximate map)


On 1 November 2015 at 22:26, Nicholas H.Tollervey <ntoll at ntoll.org> wrote:

> Hi Folks,
>
> So those of you who already have a device: this doesn't really apply to
> you but I'd love to hear your feedback all the same.
>
> I've been chatting with Naomi Ceder (on this mailing list) about
> improving the diversity of contributors to our efforts. A fallout of
> this discussion was an email about how to make best use of the handful
> of micro:bits I now have to send out to people (these are in addition to
> those handed out at PyCon UK).
>
> We hit upon the idea of a "world tour" combined with the concept of a
> "friendship cake" (viz: https://en.wikipedia.org/wiki/Herman_cake)
> mashed up with GeoCaching (bear with me here...).
>
> :-)
>
> Essentially, I'll seed the five devices to people who have expressed an
> interest and who are spread out around the world. I'll contact these
> people off list so I can grab their postal address. Each micro:bit has a
> name: Mary, Meena, Mandela, Mei-Xiu and Mohandas and maybe even a
> mission (for example, Mary might want to travel around the world in a
> westerly direction). You get the idea. It's supposed to be fun and
> engaging for both the Python community and kids when they start to learn
> about how the project was made.
>
> Once you get your device you have a week to do something with it: create
> a Python project, write a tutorial, plug it into some hardware... that
> sort of thing. Most importantly, we get to see different members of the
> Python community contribute to the Python aspect of the micro:bit
> project. Once you've created your contribution you should log what
> you've done in a GeoCaching like diary/travel-log that I've hacked
> together this evening. It's *very* early days and a lot is missing but
> you can get the idea by pointing your browser here:
>
> http://microworldtour.github.io/
>
> The source code is static HTML and you contribute via pull requests to
> this repository:
>
> https://github.com/microworldtour/microworldtour.github.io
>
> Once you've had it a week you should decide who the next person should
> be to get your micro:bit. This will be entirely *your* decision.
> However, the candidates for you to choose from will be listed on a (to
> be written) page on the site. I'll make sure it's all obvious what you
> need to do. New candidates will get onto the list by creating a pull
> request. :-)
>
> I'll write up more instructions tomorrow.
>
> In the meantime I'd love to hear feedback. Basically I'm trying to solve
> three problems:
>
> 1) Getting the handful of micro:bits into the hands of as many people as
> possible.
>
> 2) Ensuring we have contributions from a diverse number of people spread
> all over the world (Python *is* an international community after all).
>
> 3) Creating resources and a fun record of what we've been up. The
> website would be a cute "advert" for collaborators.
>
> Does this make sense..?
>
> As always, constructive critique, comments and idea are 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: <http://mail.python.org/pipermail/microbit/attachments/20151102/fbb2aac3/attachment.html>

From ntoll at ntoll.org  Mon Nov  2 15:29:37 2015
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Mon, 2 Nov 2015 20:29:37 +0000
Subject: [Microbit-Python] Accessor API design on the micro:bit
In-Reply-To: <5637AC25.7090101@hotpy.org>
References: <563396BF.5030703@hastings.org> <5633DDEF.2040100@ntoll.org>
 <CAB+QZVAw7j1ZEt3vqtctcNVWnqQbSS3LJKfknw8G9WHPJNmBBw@mail.gmail.com>
 <5634EC61.4020003@hastings.org>
 <CAB+QZVB7unA1nk_MnLtQx-dSb7DnnvMihPGXKrqwQaj0Bois7A@mail.gmail.com>
 <56351FA9.3080809@willingconsulting.com> <56361EC6.5000909@ntoll.org>
 <56362143.1010301@ntoll.org> <5637AC25.7090101@hotpy.org>
Message-ID: <5637C7B1.7060801@ntoll.org>

Hi Mark,

Excellent points well made. Thank you.

:-)

N.

On 02/11/15 18:32, Mark Shannon wrote:
> 
> 
> On 01/11/15 14:27, Nicholas H.Tollervey wrote:
>> This also makes me wonder about descriptor v accessor in other parts of
>> the API. For example, could we do this?
>>
>>>>> microbit.pin0  # digital read
>> 1
> 
> We could, but we shouldn't.
> microbit.pin0 should be a pin, as it is as at the moment.
>>>> microbit.pin0
> <MicroBitPin ...>
> 
>>>>> microbit.pin0  # analog read
>> 234
>>>>> microbit.pin0 = 0  # digital set
>>>>> microbit.pin0 = 234  # analog set (0...255)
> 
> Again no. Normal assignment rules for an attribute should apply.
>>>> microbit.pin0 = "Hello"
>>>> microbit.pin0
> "Hello"
> 
> Plus, we would have to change microbit from a module to an instance of a
> custom class, in order to support descriptors.
> 
> If we really want to use properties for pins then it should be:
> microbit.pin0.digital(_value)
> and
> microbit.pin0.analog(_value)
> 
> But I prefer the read()/write() methods.
> 
> For the accelerometer, there is no digital/analog state change, and you
> cannot write to it. So accelerometer.x seems consistent with "x"
> appearing to be a simple attribute of the accelerometer object.
> 
> IMO, descriptors should generally appear to have the same interface as
> simple object attributes, even if they are "special" under the covers.
> 
>>
>> Not sure whether digital should be 1/0 or True/False. What's the most
>> widespread convention here? I'm thinking of True/False because that
>> makes it obvious that the pin is digital rather than it's simply a very
>> low reading on an analog in.
> I think digit(al) means digit in base-2. So I prefer 0/1.
> Also pins are high/low. 1 for high, 0 for low seems more natural than
> true for high and false for low.
> 
> Cheers,
> Mark.
> 
>>
>> Thoughts..? Does this make sense..?
>>
>> N.
>>
>>
>> On 01/11/15 14:16, Nicholas H.Tollervey wrote:
>>> OK... what an interesting discussion. :-)
>>>
>>> Then I remembered I had a "captive" 11yo in my home! So I asked him
>>> which one he preferred (and videoed the discussion). Here's the exchange
>>> with my son, over Sunday morning breakfast, in all its glory:
>>>
>>> https://www.youtube.com/watch?v=9w4I_xEwlcA
>>>
>>> Put simply he prefers accelerometer.x over .get_x() and .x() because
>>> it's less typing.
>>>
>>> Emboldened by this feedback I've visited some of his buddies this
>>> morning (I totally realise this is not at all scientific) to get their
>>> opinion.
>>>
>>> I'm quite surprised by the results - they agree with Sam: ".x" is the
>>> unanimous verdict for the best way to express this for all three 11yo
>>> I've surveyed. I was expecting ".get_x()" to win because it was obvious
>>> what it was doing.
>>>
>>> But, for example, Max explained that he didn't like all the "weird
>>> symbols" and mentioned that, "I don't get 'get', isn't it just 'x'? Why
>>> do I need to 'get' it"..? (Max didn't want to be videoed.)
>>>
>>> Lewis, (whose video is here:
>>> https://www.youtube.com/watch?v=uyec2VqYwJs) also likes the simplicity
>>> of ".x" and felt that all the others just looked complicated.
>>>
>>> So, the evidence I've collected so far appears to support Larry and that
>>> we should trust the heuristic of "simplicity wins".
>>>
>>> Once again, I totally realise this is not scientific in any way. But I
>>> thought I'd ask those 11yo I had within "range" this morning because
>>> they're our target audience.
>>>
>>> I've been booked to do some gardening this afternoon... but will return
>>> this evening.
>>>
>>> I look forward to reading all your thoughts. :-)
>>>
>>> N.
>>>
>>> On 31/10/15 20:08, Carol Willing wrote:
>>>> While I am joining this discussion after a couple of months of history,
>>>> I am going to step back for a moment and ask a simple question:
>>>>
>>>> Does this have to be a decision between x, x(), get_x()?
>>>>
>>>> For the accelerometer (not necessarily all other functionality, but
>>>> since the accelerometer is built into the chip and accessible without
>>>> soldering anything, it will be used by many), could we support all
>>>> three?
>>>>
>>>> If I was an 11 year old with access to Google, I could find resources
>>>> appropriate for an 11 year old that use all three of these approaches:
>>>> Young Coders workshop, Adafruit/Sparkfun, MicroPython tutorials, Python
>>>> for Kids book, and others.
>>>>
>>>> If I didn't have access to Google, I, as a student, would use `help` or
>>>> example programs to model what I would choose. It's critical for the
>>>> educational setting for the approach to be consistent within an example
>>>> program. While in a perfect world that might imply consistent across
>>>> all
>>>> example programs.
>>>>
>>>> Yet, we know that there are several approaches to programming that lend
>>>> the same result but with differing implementations.
>>>>
>>>> It seems to me if there is space to support all three for the
>>>> accelerometer that would make reasonable sense. We can tailor the help
>>>> message to guide to the desired approach; yet, all three will work for
>>>> the student whether they are using a recommended approach or something
>>>> that they googled.
>>>>
>>>> Based on my experience teaching a wide spectrum of children, I do think
>>>> with gentle instruction all levels will be able to use the
>>>> accelerometer.
>>>>
>>>> Warmly,
>>>> Carol
>>>>
>>>>
>>>> -- 
>>>> *Carol Willing*
>>>> Developer | Willing Consulting
>>>> https://willingconsulting.com
>>>>
>>>>
>>>> _______________________________________________
>>>> 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: <http://mail.python.org/pipermail/microbit/attachments/20151102/074f0909/attachment-0001.sig>

From larry at hastings.org  Mon Nov  2 16:06:57 2015
From: larry at hastings.org (Larry Hastings)
Date: Mon, 2 Nov 2015 13:06:57 -0800
Subject: [Microbit-Python] Accessor API design on the micro:bit
In-Reply-To: <CANw+Mznf1J4tp0m4=AFpMNgu+4g48AmL7uNRx3qMjVvvdU_RsQ@mail.gmail.com>
References: <563396BF.5030703@hastings.org> <5633DDEF.2040100@ntoll.org>
 <CAB+QZVAw7j1ZEt3vqtctcNVWnqQbSS3LJKfknw8G9WHPJNmBBw@mail.gmail.com>
 <5634EC61.4020003@hastings.org>
 <CAB+QZVB7unA1nk_MnLtQx-dSb7DnnvMihPGXKrqwQaj0Bois7A@mail.gmail.com>
 <56351FA9.3080809@willingconsulting.com> <5636365A.1010209@hastings.org>
 <CANw+Mznf1J4tp0m4=AFpMNgu+4g48AmL7uNRx3qMjVvvdU_RsQ@mail.gmail.com>
Message-ID: <5637D071.8090700@hastings.org>



On 11/01/2015 03:59 PM, Damien George wrote:
> Actually, getting the value of the accelerometer is doing something
> very non-trivial: it does an I2C read on the bus to update the value.
> Whether this implementation detail (is it an implementation detail?)
> should factor in to the decision to use (or not) properties is an
> interesting discussion.

Well, again, technically, right now the act of reading the device is 
done asynchronously in the idle thread.  Directly interacting with the 
"accelerometer" object doesn't cause a read.

Plus, you read all three values at once, and you only do so when the 
device has new values to read.  So even if we changed it so querying the 
accelerometer for its X value caused an I2C read, it wouldn't happen 
every time.

This is one reason why you have to go with a /subjective/ assessment, 
whether or not doing something "feels" like it has code behind it.  
Implementations change back and forth.  So as API designers we should 
decide whether or not getting the x value from the accelerometer "feels" 
like it's doing work.


> One big advantage of making everything functions is that you have room
> to grow the API in the future if the function call needs to have
> arguments added to it.  For example, maybe getting the accelerometer
> value has an optional argument to force the update of the value (ie do
> an I2C read even if one was just done), or maybe there's an argument
> to specify the g-range.

As they say on python-dev: YAGNI.  (For those unfamiliar: an acronym for 
"You Ain't Gonna Need It".)  I wouldn't want to mix in the g-range in as 
a parameter, and I think "force a fresh read" would be fine as a 
separate function call, were we to add such functionality, which I don't 
think anyone is currently proposing we do.

The best API for the accelerometer IMO would be for it to automatically 
publish fresh values to the user, and I believe that's not merely 
achievable but actually reasonably straightforward. Implemented like 
that, I foresee no eventuality where we'd have to add parameters to 
"read the current x value from the accelerometer".  So a member / 
property should permanently suffice.


> Also, consider the button API: do we want button.value as a read-only
> property?  What about button.was_pressed()?

Speaking personally--I'm not sure.  Maybe I should take a step back and 
look at the API overall, and make a specific proposal about? I've been 
thinking about doing this anyway.


> My argument is: functions are more general/powerful than properties
> and are going to be needed in some places, so best to just have
> everything a function and teach only that concept.

I don't know what the curriculum will look like, but I would be very 
surprised indeed if it permanently skipped variables and only ever 
taught the students functions.  Since presumably the students /will/ be 
taught about variables, I don't see a need to remove any and all 
variables (or things that merely look like variables!) from our API.


Cheers,


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151102/92c41e5c/attachment.html>

From damien.p.george at gmail.com  Mon Nov  2 18:54:32 2015
From: damien.p.george at gmail.com (Damien George)
Date: Mon, 2 Nov 2015 23:54:32 +0000
Subject: [Microbit-Python] Sharing devices
In-Reply-To: <CANBSuyFkxHxM4fzkwdznmhea22EzLM+cV0Evg0UgmsUvXin0gQ@mail.gmail.com>
References: <56369178.9000603@ntoll.org>
 <CANBSuyFkxHxM4fzkwdznmhea22EzLM+cV0Evg0UgmsUvXin0gQ@mail.gmail.com>
Message-ID: <CANw+MzkpQ+z-gETbt_78EXmd+g=us-W01_Y-J4aM7eWnevvZzQ@mail.gmail.com>

A really great idea Nicholas!

To get maximum benefit they'd need to get posted out very soon I
guess.  That way we have more examples and tutorials (or even improved
C code) when the device is used by the students.  But I guess the
world tour could still continue even after Jan next year.

On Mon, Nov 2, 2015 at 7:41 PM, Tom Viner <tom at viner.tv> wrote:
> This sounds like a really fun idea Nic.
>
> How do you envisage gaining the attention of Python users round the world?
> Local mailing lists and user groups? Who would be responsible for posting to
> these groups?
>
> Then choosing the next person to send the device to, would you have
> prospective recipients write a short bio or intro to their contribution
> idea? Then have the current holders choose from that list? (and apply to see
> a postal address - no changing your mind, you can't read everyone's address
> type thing, but you can see all applicants on a suitably approximate map)
>
>
> On 1 November 2015 at 22:26, Nicholas H.Tollervey <ntoll at ntoll.org> wrote:
>>
>> Hi Folks,
>>
>> So those of you who already have a device: this doesn't really apply to
>> you but I'd love to hear your feedback all the same.
>>
>> I've been chatting with Naomi Ceder (on this mailing list) about
>> improving the diversity of contributors to our efforts. A fallout of
>> this discussion was an email about how to make best use of the handful
>> of micro:bits I now have to send out to people (these are in addition to
>> those handed out at PyCon UK).
>>
>> We hit upon the idea of a "world tour" combined with the concept of a
>> "friendship cake" (viz: https://en.wikipedia.org/wiki/Herman_cake)
>> mashed up with GeoCaching (bear with me here...).
>>
>> :-)
>>
>> Essentially, I'll seed the five devices to people who have expressed an
>> interest and who are spread out around the world. I'll contact these
>> people off list so I can grab their postal address. Each micro:bit has a
>> name: Mary, Meena, Mandela, Mei-Xiu and Mohandas and maybe even a
>> mission (for example, Mary might want to travel around the world in a
>> westerly direction). You get the idea. It's supposed to be fun and
>> engaging for both the Python community and kids when they start to learn
>> about how the project was made.
>>
>> Once you get your device you have a week to do something with it: create
>> a Python project, write a tutorial, plug it into some hardware... that
>> sort of thing. Most importantly, we get to see different members of the
>> Python community contribute to the Python aspect of the micro:bit
>> project. Once you've created your contribution you should log what
>> you've done in a GeoCaching like diary/travel-log that I've hacked
>> together this evening. It's *very* early days and a lot is missing but
>> you can get the idea by pointing your browser here:
>>
>> http://microworldtour.github.io/
>>
>> The source code is static HTML and you contribute via pull requests to
>> this repository:
>>
>> https://github.com/microworldtour/microworldtour.github.io
>>
>> Once you've had it a week you should decide who the next person should
>> be to get your micro:bit. This will be entirely *your* decision.
>> However, the candidates for you to choose from will be listed on a (to
>> be written) page on the site. I'll make sure it's all obvious what you
>> need to do. New candidates will get onto the list by creating a pull
>> request. :-)
>>
>> I'll write up more instructions tomorrow.
>>
>> In the meantime I'd love to hear feedback. Basically I'm trying to solve
>> three problems:
>>
>> 1) Getting the handful of micro:bits into the hands of as many people as
>> possible.
>>
>> 2) Ensuring we have contributions from a diverse number of people spread
>> all over the world (Python *is* an international community after all).
>>
>> 3) Creating resources and a fun record of what we've been up. The
>> website would be a cute "advert" for collaborators.
>>
>> Does this make sense..?
>>
>> As always, constructive critique, comments and idea are 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 sparks.m at gmail.com  Tue Nov  3 03:58:37 2015
From: sparks.m at gmail.com (Michael)
Date: Tue, 3 Nov 2015 08:58:37 +0000
Subject: [Microbit-Python] Accessor API design on the micro:bit
In-Reply-To: <5637D071.8090700@hastings.org>
References: <563396BF.5030703@hastings.org> <5633DDEF.2040100@ntoll.org>
 <CAB+QZVAw7j1ZEt3vqtctcNVWnqQbSS3LJKfknw8G9WHPJNmBBw@mail.gmail.com>
 <5634EC61.4020003@hastings.org>
 <CAB+QZVB7unA1nk_MnLtQx-dSb7DnnvMihPGXKrqwQaj0Bois7A@mail.gmail.com>
 <56351FA9.3080809@willingconsulting.com>
 <5636365A.1010209@hastings.org>
 <CANw+Mznf1J4tp0m4=AFpMNgu+4g48AmL7uNRx3qMjVvvdU_RsQ@mail.gmail.com>
 <5637D071.8090700@hastings.org>
Message-ID: <CAB+QZVDtD4nzr7jmrZTLtmXua5u-aoD7qNhOVbqAf42tMerLcg@mail.gmail.com>

On 2 November 2015 at 21:06, Larry Hastings <larry at hastings.org> wrote:
...

> I don't know what the curriculum will look like, but I would be very
> surprised indeed if it permanently skipped variables and only ever taught
> the students functions.  Since presumably the students *will* be taught
> about variables, I don't see a need to remove any and all variables (or
> things that merely look like variables!) from our API.
>

Strawman argument. They're taught variables not properties. To them a
variable a value that when you set it, it stays that value until you change
it again.

To you it's "merely look like a variable", but that merely is actually an
extra-ordinary leap.

Python properties are an advanced concept in any python tutorial because
they require understanding of descriptors, and python objects,
getters/setters (since they're there under the hood) and so on.

Also, while I think they're *nice* they are actually far far less used than
people realise.

$ pwd
/usr/lib/python2.7/dist-packages

$ grep @property `find -type f|grep py$`|cut -d: -f1 |uniq |sort|cut -d/
-f2|sort|uniq |wc -l
62

$ ls -p|grep /|wc -l
239

$ find -type f|grep py$|wc -l
   7713

$ wc -l `find -type f|grep py$`|tail -1
 2164030 total

$ grep @property `find -type f|grep py$`|wc -l
   1151

ie the best figure I can find is 1/4 of projects used use python
properties, 3% of files use them, and you'll only see a @property usage in
one out of every 2000 lines of code.

To me that suggests it's niche *except* for people who have been using
python for years - that's much much much more niche than I expected.


Michael.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151103/f7969688/attachment-0001.html>

From damien.p.george at gmail.com  Tue Nov  3 10:45:30 2015
From: damien.p.george at gmail.com (Damien George)
Date: Tue, 3 Nov 2015 15:45:30 +0000
Subject: [Microbit-Python] Accessor API design on the micro:bit
In-Reply-To: <CAB+QZVDtD4nzr7jmrZTLtmXua5u-aoD7qNhOVbqAf42tMerLcg@mail.gmail.com>
References: <563396BF.5030703@hastings.org> <5633DDEF.2040100@ntoll.org>
 <CAB+QZVAw7j1ZEt3vqtctcNVWnqQbSS3LJKfknw8G9WHPJNmBBw@mail.gmail.com>
 <5634EC61.4020003@hastings.org>
 <CAB+QZVB7unA1nk_MnLtQx-dSb7DnnvMihPGXKrqwQaj0Bois7A@mail.gmail.com>
 <56351FA9.3080809@willingconsulting.com>
 <5636365A.1010209@hastings.org>
 <CANw+Mznf1J4tp0m4=AFpMNgu+4g48AmL7uNRx3qMjVvvdU_RsQ@mail.gmail.com>
 <5637D071.8090700@hastings.org>
 <CAB+QZVDtD4nzr7jmrZTLtmXua5u-aoD7qNhOVbqAf42tMerLcg@mail.gmail.com>
Message-ID: <CANw+MzmQFErinKoNzYQoPnALXrY2ZsQ2UP_oayuH0dG277qQvg@mail.gmail.com>

> Well, again, technically, right now the act of reading the device is done asynchronously in the idle thread.  Directly interacting with the "accelerometer" object doesn't cause a read.

No, calling "get_x()" does actually cause a read on the I2C bus if the
accelerometer is not "up to date".

Regarding "variables".  As Michael points out, accelerometer.x is not
really a variable in the sense that the kids will learn, because 1)
you can't change it; 2) it changes by itself.  So I'd say that .x as a
property is a much more sophisticated concept than a traditional
variable or a function.

In our current API everything without parenthesis is a fixed entity.
Eg microbit.pin0, Image.HEART.  And everything with parenthesis at the
end is a function call that does something or interacts with the real
world.

From larry at hastings.org  Tue Nov  3 12:14:07 2015
From: larry at hastings.org (Larry Hastings)
Date: Tue, 3 Nov 2015 09:14:07 -0800
Subject: [Microbit-Python] Accessor API design on the micro:bit
In-Reply-To: <CANw+MzmQFErinKoNzYQoPnALXrY2ZsQ2UP_oayuH0dG277qQvg@mail.gmail.com>
References: <563396BF.5030703@hastings.org> <5633DDEF.2040100@ntoll.org>
 <CAB+QZVAw7j1ZEt3vqtctcNVWnqQbSS3LJKfknw8G9WHPJNmBBw@mail.gmail.com>
 <5634EC61.4020003@hastings.org>
 <CAB+QZVB7unA1nk_MnLtQx-dSb7DnnvMihPGXKrqwQaj0Bois7A@mail.gmail.com>
 <56351FA9.3080809@willingconsulting.com> <5636365A.1010209@hastings.org>
 <CANw+Mznf1J4tp0m4=AFpMNgu+4g48AmL7uNRx3qMjVvvdU_RsQ@mail.gmail.com>
 <5637D071.8090700@hastings.org>
 <CAB+QZVDtD4nzr7jmrZTLtmXua5u-aoD7qNhOVbqAf42tMerLcg@mail.gmail.com>
 <CANw+MzmQFErinKoNzYQoPnALXrY2ZsQ2UP_oayuH0dG277qQvg@mail.gmail.com>
Message-ID: <5638EB5F.6070804@hastings.org>



On 11/03/2015 07:45 AM, Damien George wrote:
>> Well, again, technically, right now the act of reading the device is done asynchronously in the idle thread.  Directly interacting with the "accelerometer" object doesn't cause a read.
> No, calling "get_x()" does actually cause a read on the I2C bus if the
> accelerometer is not "up to date".

Ah, that must be recent.  I haven't updated my checkouts very recently, 
as I want a stable platform to work on, and in all my checkouts get_x 
looks like this:

    int MicroBitAccelerometer::getX()
    {
         return sample.x;
    }

which obviously cannot perform a read on the I2C bus.

Again, this is consistent with part of my point: implementations change, 
and you need not marry your API to the details of your (current) 
implementation.  Just because get_x() currently can cause a read on the 
I2C bus does not mean that it will always do so--as until recently it 
did not.


> Regarding "variables".  As Michael points out, accelerometer.x is not
> really a variable in the sense that the kids will learn, because 1)
> you can't change it; 2) it changes by itself.  So I'd say that .x as a
> property is a much more sophisticated concept than a traditional
> variable or a function.
>
> In our current API everything without parenthesis is a fixed entity.
> Eg microbit.pin0, Image.HEART.  And everything with parenthesis at the
> end is a function call that does something or interacts with the real
> world.

Since I'm clearly out of date, I can't speak definitively on current 
behaviors of the micro:bit.  But, assuming that it no longer has a 
separate thread performing asynchronous updates, and that the API 
doesn't have any property objects, I'm happy to assume that this 
statement is true.

The question that needs settling is: is this an important distinction?  
I don't mean to mischaracterize anybody's viewpoint, but my 
understanding is that you and others on the mailing list feel this 
distinction is very important, that a self-updating "accelerometer.x" 
would confuse or otherwise have some kind of deleterious effect on the 
students and their learning.  My position is, no, this is conceptually 
harmless, and it makes the object--and therefore MicroPython on the 
micro:bit generally--more pleasant to use, a win for our side.  Your 
arguments haven't caused me to change my mind, and I gather my arguments 
have yet to change yours.

So--now what?


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151103/00ef0334/attachment.html>

From ntoll at ntoll.org  Sat Nov  7 10:57:06 2015
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Sat, 7 Nov 2015 15:57:06 +0000
Subject: [Microbit-Python] Important: towards version 0.9, 1.0 and 1.1
Message-ID: <563E1F52.7070709@ntoll.org>

Dear All,

Both Damien and I have contributed to this email despite it only
appearing to be from me.

TL;DR - we need to have a finalised release of MicroPython so teachers
and others can start to plan with confidence what their lessons will
contain.

To this end we propose the following milestones with listed features (in
no particular order) and associated time-line:

https://github.com/bbcmicrobit/micropython/milestones

Mid-November: 0.9
-----------------

* documented consistent API
(https://github.com/bbcmicrobit/micropython/issues/76 and
https://github.com/bbcmicrobit/micropython/issues/64 and
https://github.com/bbcmicrobit/micropython/issues/59)
* builtin help mostly finished
(https://github.com/bbcmicrobit/micropython/issues/21)
* async music (https://github.com/bbcmicrobit/micropython/issues/31)
* gestures (https://github.com/bbcmicrobit/micropython/issues/9)
* working random function
(https://github.com/bbcmicrobit/micropython/issues/68)
* button_a.was_pressed()
(https://github.com/bbcmicrobit/micropython/issues/69)

Early-December: 1.0
-------------------

* BLE (https://github.com/bbcmicrobit/micropython/issues/71)
* Larry's game/event related classes
(https://github.com/bbcmicrobit/micropython/issues/70)
* Choose function (https://github.com/bbcmicrobit/micropython/issues/72)

January: 1.1
------------

* Speech (Shhh... it's a surprise) :-)
* persistent storage (https://github.com/bbcmicrobit/micropython/issues/73)
* built-in image effects
(https://github.com/bbcmicrobit/micropython/issues/74)
* more builtin music (https://github.com/bbcmicrobit/micropython/issues/75)
* ability for 2 microbits to communicate with each other using a
physical wire (https://github.com/bbcmicrobit/micropython/issues/37 and
https://github.com/bbcmicrobit/micropython/issues/12)
* built in tutorial (https://github.com/bbcmicrobit/micropython/issues/77)

Obviously, some things that are "easy" might make it into earlier
versions - for example, more built-in music is a 1/2 hour job for Nicholas.

As you can see, each of these features has an associated issue in GitHub
(if it doesn't have so already).

So, please check out those issues, feel free to contribute and let's
create something great for all those beginning Pythonistas..!

As always, your help is most appreciated and ideas, constructive
critique and feedback is most welcome.

Get stuck in!

Nicholas and Damien.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/microbit/attachments/20151107/9870db86/attachment.sig>

From ntoll at ntoll.org  Sat Nov  7 13:38:56 2015
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Sat, 7 Nov 2015 18:38:56 +0000
Subject: [Microbit-Python] First draft doc attempt at Larry's game related
 work
Message-ID: <563E4540.1060805@ntoll.org>

Hi Folks,

If you remember, Larry created three classes to aid in game making on
the micro:bit. You can find his notes here:

https://bitbucket.org/larry/microbit_game

The next steps were for us to define a MicroPython API in much the same
as we did for the music API. To this end I've created a first draft of
documentation describing what this may look like as an API for kids
based upon Larry's work.

IT'S A STRAW MAN. I'm not precious about anything I've written and would
welcome feedback and pull requests to the docs. I'll be pushing for
getting a consensus soon-ish so work can start on getting Larry's code
merged into MicroPython in the appropriate manner.

You'll find it in the game-api-docs branch of our repos or here:

https://github.com/bbcmicrobit/micropython/blob/game-api-docs/docs/game_api.rst

Although GitHub munges RST so here's a direct link to the raw file:

https://raw.githubusercontent.com/bbcmicrobit/micropython/game-api-docs/docs/game_api.rst

As always, comments, constructive critique and ideas are 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: <http://mail.python.org/pipermail/microbit/attachments/20151107/10830494/attachment.sig>

From radomir at dopieralski.pl  Sat Nov  7 15:06:25 2015
From: radomir at dopieralski.pl (Radomir Dopieralski)
Date: Sat, 7 Nov 2015 21:06:25 +0100
Subject: [Microbit-Python] First draft doc attempt at Larry's game
 related work
In-Reply-To: <563E4540.1060805@ntoll.org>
References: <563E4540.1060805@ntoll.org>
Message-ID: <20151107210625.29f2fd3e@ghostwheel>

On Sat, 7 Nov 2015 18:38:56 +0000
"Nicholas H.Tollervey" <ntoll at ntoll.org> wrote:

> Hi Folks,
> 
> If you remember, Larry created three classes to aid in game making on
> the micro:bit. You can find his notes here:
> 
> https://bitbucket.org/larry/microbit_game
[...]
> 
> As always, comments, constructive critique and ideas are most welcome!

It looks good, I just have a couple of notes, not sure how relevant they are.

When I read "Only returns this true value once per button press.", a red
flag came up. That means that a method that you use to read data modifies the
data you are reading, effectively destroying it. It means that you are up for
horrible pain and suffering if you ever dare to use that method in more than
one place. And that means that the only sane way of using it is to call it
somewhere in your main loop and cache the result in a global variable. That
is a bad practice in itself.

I am even more worried that this is not mentioned in the actual documentation,
so that people who stumble into this problem are likely to be taken by
surprise and baffled.

I only hope that it is not mentioned in the documentation because it was
actually removed in the final version.

I have some limited experience writing small games with PyGame for Ludum
Dare, and I noticed that the way I do timing in them is very different from
what is proposed here. There are basically two main use cases: a turn-based
game and a real-time game.

In a turn-based game, you basically sit there waiting until the player presses
a key or otherwise provides input. Once that happens, you process the input,
modify the game state accordingly, update the display (possibly playing some
animations) and go back to waiting. If the player provides input while you are
processing it, it should get buffered, and might in addition skip the
animation.

Real-time games usually are not really real-time, in the sense of real-time
systems. They actually run on an internal clock, calculating and displaying
"frames" for the player. There are two ways this internal clock may work. In
the simplest case, the clock "ticks" at a specified number of ticks per second,
and during each tick, a single frame is calculated. The process usually starts
with retrieving any player input from the buffers, and possibly updates from
outside, in a case of an online game. Those are then processed, together with
advancing any internal game clocks and updating its internal state. Then the
display is updated, and the system waits for the next clock tick. The more
advanced way, the frames are calculated as fast as possible, but they get an
additional parameter from the clock -- the time since the last frame. That is
used to integrate any motion and animations (in the simplest case, the
positions of objects are updated by their speed times the time, but there are
better ways to do it). This makes the system a little more robust against
frames that took too long to calculate -- it becomes less fluent, but the game
time doesn't slow down, as in the first approach.

In any way, while the proposed scheduler class could be used to implement the
first approach to the real-time games (using only small part of its
functionality), it's not very helpful for the turn-based case and the case with
fluid frames.

I wonder if we could provide some help for writing those other kinds of games,
especially the turn-based ones, as this is probably going to be the easiest
to make. Some ideas would include an input buffer (we take it for granted on
a PC), a function similar to pygame.time.Clock.tick that waits until a set time
passes from its last call, and perhaps an integrator?

-- 
Radomir Dopieralski

From ntoll at ntoll.org  Sat Nov  7 19:43:21 2015
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Sun, 8 Nov 2015 00:43:21 +0000
Subject: [Microbit-Python] PLEASE CHECK - microbit world tour website
Message-ID: <563E9AA9.5010109@ntoll.org>

Hi Folks,

http://microworldtour.github.io/

Put simply... does it make sense..? What would you change..?

Initial announcement will be made on Monday. Updates will be ongoing.

Also, if you look closely, you'll see who I've chosen to be in the first
group of 5 recipients.

(Made you look!)

:-)

N.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/microbit/attachments/20151108/a91d0cc4/attachment.sig>

From damien.p.george at gmail.com  Sun Nov  8 06:49:48 2015
From: damien.p.george at gmail.com (Damien George)
Date: Sun, 8 Nov 2015 11:49:48 +0000
Subject: [Microbit-Python] PLEASE CHECK - microbit world tour website
In-Reply-To: <563E9AA9.5010109@ntoll.org>
References: <563E9AA9.5010109@ntoll.org>
Message-ID: <CANw+Mz=1MX=gZtdzi=eCwAU0wRrLk1szB=MZtjK7VD23knb4SQ@mail.gmail.com>

Really awesome work Nicholas!

I think the instructions are clear, but even so the procedure is a
little bit complex, especially for those who have not used github
before to make a pull request.  I don't think there's much you can do
about this, and we can help people with the submissions, and then once
there are a few already done others can see how to do it.

If only the microbits multiplied by 5 at each person... :)


On Sun, Nov 8, 2015 at 12:43 AM, Nicholas H.Tollervey <ntoll at ntoll.org> wrote:
> Hi Folks,
>
> http://microworldtour.github.io/
>
> Put simply... does it make sense..? What would you change..?
>
> Initial announcement will be made on Monday. Updates will be ongoing.
>
> Also, if you look closely, you'll see who I've chosen to be in the first
> group of 5 recipients.
>
> (Made you look!)
>
> :-)
>
> N.
>
>
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit
>

From mark at hotpy.org  Sun Nov  8 07:59:27 2015
From: mark at hotpy.org (Mark Shannon)
Date: Sun, 8 Nov 2015 12:59:27 +0000
Subject: [Microbit-Python] Heap size
Message-ID: <563F472F.60304@hotpy.org>

Hi,

I guess this is a question for Damien.
How is the size of the GC heap determined?

The code is here
https://github.com/bbcmicrobit/micropython/blob/master/source/microbit/mprun.c#L78
but where does the magic constant 9820 come from?

I'm planning on doing some experiments with a cut-down version of the 
DAL, and I would like to see how much more heap we can get.

Cheers,
Mark.

From dhylands at gmail.com  Sun Nov  8 12:44:28 2015
From: dhylands at gmail.com (Dave Hylands)
Date: Sun, 8 Nov 2015 09:44:28 -0800
Subject: [Microbit-Python] Heap size
In-Reply-To: <563F472F.60304@hotpy.org>
References: <563F472F.60304@hotpy.org>
Message-ID: <CABi1daEWAsvZW-bG9FV5ZPuLrh5cFHQEO-qZf25UXfqWLk3QRA@mail.gmail.com>

How much RAM does the microbit have?

Based on the the 9820, I'm going to guess 16K.

The normal memory layout is that you have global variables, heap, and
stack. The heap and stack grow towards each other, so the stack is normally
starts at the highest possible memory address and grows downwards and the
heap starts immediately after the global variables.

Was a linker map produced as part of the build?

On Sun, Nov 8, 2015 at 4:59 AM, Mark Shannon <mark at hotpy.org> wrote:

> Hi,
>
> I guess this is a question for Damien.
> How is the size of the GC heap determined?
>
> The code is here
>
> https://github.com/bbcmicrobit/micropython/blob/master/source/microbit/mprun.c#L78
> but where does the magic constant 9820 come from?
>
> I'm planning on doing some experiments with a cut-down version of the DAL,
> and I would like to see how much more heap we can get.
>
> Cheers,
> Mark.
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit
>



-- 
Dave Hylands
Shuswap, BC, Canada
http://www.davehylands.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151108/85b4f008/attachment.html>

From damien.p.george at gmail.com  Sun Nov  8 13:07:36 2015
From: damien.p.george at gmail.com (Damien George)
Date: Sun, 8 Nov 2015 18:07:36 +0000
Subject: [Microbit-Python] Heap size
In-Reply-To: <CABi1daEWAsvZW-bG9FV5ZPuLrh5cFHQEO-qZf25UXfqWLk3QRA@mail.gmail.com>
References: <563F472F.60304@hotpy.org>
 <CABi1daEWAsvZW-bG9FV5ZPuLrh5cFHQEO-qZf25UXfqWLk3QRA@mail.gmail.com>
Message-ID: <CANw+Mzm76T7P9+6Mq5u2DiVFXhEngiDNsxKNjusBUVPHiJO+bA@mail.gmail.com>

There is also an mbed heap (currently 2k) so I found the best thing to
do for the uPy heap is to just use a static buffer in the BSS (as per
mprun.c).

Mark: you can try reducing the size of the mbed heap to give us more
room.  Ultimately the best thing to do is combine the heaps, but
that's non trivial (since C++ new's use the mbed heap, you'd have to
hook into that).  So I think just reducing the size of the mbed heap
is the easiest, especially if it only allocates on startup, we can
determine how much it actually needs.

Anyway, to answer the question: 9820 came from increasing the number
by units of 16 bytes until it didn't fit anymore :)


On Sun, Nov 8, 2015 at 5:44 PM, Dave Hylands <dhylands at gmail.com> wrote:
> How much RAM does the microbit have?
>
> Based on the the 9820, I'm going to guess 16K.
>
> The normal memory layout is that you have global variables, heap, and stack.
> The heap and stack grow towards each other, so the stack is normally starts
> at the highest possible memory address and grows downwards and the heap
> starts immediately after the global variables.
>
> Was a linker map produced as part of the build?
>
> On Sun, Nov 8, 2015 at 4:59 AM, Mark Shannon <mark at hotpy.org> wrote:
>>
>> Hi,
>>
>> I guess this is a question for Damien.
>> How is the size of the GC heap determined?
>>
>> The code is here
>>
>> https://github.com/bbcmicrobit/micropython/blob/master/source/microbit/mprun.c#L78
>> but where does the magic constant 9820 come from?
>>
>> I'm planning on doing some experiments with a cut-down version of the DAL,
>> and I would like to see how much more heap we can get.
>>
>> Cheers,
>> Mark.
>> _______________________________________________
>> Microbit mailing list
>> Microbit at python.org
>> https://mail.python.org/mailman/listinfo/microbit
>
>
>
>
> --
> Dave Hylands
> Shuswap, BC, Canada
> http://www.davehylands.com
>
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit
>

From mark at hotpy.org  Sun Nov  8 14:19:48 2015
From: mark at hotpy.org (Mark Shannon)
Date: Sun, 8 Nov 2015 19:19:48 +0000
Subject: [Microbit-Python] Heap size
In-Reply-To: <CANw+Mzm76T7P9+6Mq5u2DiVFXhEngiDNsxKNjusBUVPHiJO+bA@mail.gmail.com>
References: <563F472F.60304@hotpy.org>
 <CABi1daEWAsvZW-bG9FV5ZPuLrh5cFHQEO-qZf25UXfqWLk3QRA@mail.gmail.com>
 <CANw+Mzm76T7P9+6Mq5u2DiVFXhEngiDNsxKNjusBUVPHiJO+bA@mail.gmail.com>
Message-ID: <563FA054.8080808@hotpy.org>

Hi,

My plan was to reduce the amount of static data (bss) space used by the DAL:
https://github.com/lancaster-university/microbit-dal/issues/40.

With no DAL fibers and no message bus, we should be able to recover a 
few more kbs (its like the 1980s all over again :) ).
We might also be able to drop the mbed heap size to 1k as well.

OOI, how hard would it be to support malloc and free in the MicroPython 
GC? It already uses a free-list allocator, so it might only need an 
extra header bit to mark an object as not collectable even though it is 
unreachable.
That way we can drop the mbed heap size to zero and it might just be 
possible to support BLE and the REPL at the same time.

Cheers,
Mark.

On 08/11/15 18:07, Damien George wrote:
> There is also an mbed heap (currently 2k) so I found the best thing to
> do for the uPy heap is to just use a static buffer in the BSS (as per
> mprun.c).
>
> Mark: you can try reducing the size of the mbed heap to give us more
> room.  Ultimately the best thing to do is combine the heaps, but
> that's non trivial (since C++ new's use the mbed heap, you'd have to
> hook into that).  So I think just reducing the size of the mbed heap
> is the easiest, especially if it only allocates on startup, we can
> determine how much it actually needs.
>
> Anyway, to answer the question: 9820 came from increasing the number
> by units of 16 bytes until it didn't fit anymore :)
>
>
> On Sun, Nov 8, 2015 at 5:44 PM, Dave Hylands <dhylands at gmail.com> wrote:
>> How much RAM does the microbit have?
>>
>> Based on the the 9820, I'm going to guess 16K.
>>
>> The normal memory layout is that you have global variables, heap, and stack.
>> The heap and stack grow towards each other, so the stack is normally starts
>> at the highest possible memory address and grows downwards and the heap
>> starts immediately after the global variables.
>>
>> Was a linker map produced as part of the build?
>>
>> On Sun, Nov 8, 2015 at 4:59 AM, Mark Shannon <mark at hotpy.org> wrote:
>>>
>>> Hi,
>>>
>>> I guess this is a question for Damien.
>>> How is the size of the GC heap determined?
>>>
>>> The code is here
>>>
>>> https://github.com/bbcmicrobit/micropython/blob/master/source/microbit/mprun.c#L78
>>> but where does the magic constant 9820 come from?
>>>
>>> I'm planning on doing some experiments with a cut-down version of the DAL,
>>> and I would like to see how much more heap we can get.
>>>
>>> Cheers,
>>> Mark.
>>> _______________________________________________
>>> Microbit mailing list
>>> Microbit at python.org
>>> https://mail.python.org/mailman/listinfo/microbit
>>
>>
>>
>>
>> --
>> Dave Hylands
>> Shuswap, BC, Canada
>> http://www.davehylands.com
>>
>> _______________________________________________
>> 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  Sun Nov  8 14:29:00 2015
From: damien.p.george at gmail.com (Damien George)
Date: Sun, 8 Nov 2015 19:29:00 +0000
Subject: [Microbit-Python] Heap size
In-Reply-To: <563FA054.8080808@hotpy.org>
References: <563F472F.60304@hotpy.org>
 <CABi1daEWAsvZW-bG9FV5ZPuLrh5cFHQEO-qZf25UXfqWLk3QRA@mail.gmail.com>
 <CANw+Mzm76T7P9+6Mq5u2DiVFXhEngiDNsxKNjusBUVPHiJO+bA@mail.gmail.com>
 <563FA054.8080808@hotpy.org>
Message-ID: <CANw+Mz=_7kQXkCc-1uFo47ivLSAZxJUvqrtQMBvr7G7xkGPm5Q@mail.gmail.com>

> My plan was to reduce the amount of static data (bss) space used by the DAL:
> https://github.com/lancaster-university/microbit-dal/issues/40.

Your intentions are good, but I don't know if Joe will be willing to
merge such large structurcal changes :(

> With no DAL fibers and no message bus, we should be able to recover a few
> more kbs (its like the 1980s all over again :) ).
> We might also be able to drop the mbed heap size to 1k as well.

That would be great.

> OOI, how hard would it be to support malloc and free in the MicroPython GC?

Very easy.  Just call gc_alloc and gc_free.  It will work correctly.

> It already uses a free-list allocator, so it might only need an extra header
> bit to mark an object as not collectable even though it is unreachable.

No, easiest to do one of 2 things:

1. Keep a global pointer to the data in ROOT_POINTERS
2. Make gc_collect (see mprun.c) scan the entire bss/data sections.
(This is how it originally worked, before we restricted it to just the
ROOT_POINTERS area to make it run faster.  But with only a few kbytes
in the bss/data sections, it'll run fast enough).


> That way we can drop the mbed heap size to zero and it might just be
> possible to support BLE and the REPL at the same time.

BLE+REPL is going to be tough: BLE needs 8k+2k.  Stack needs 2k.  That
leaves 4k for data+bss+heap.

From damien.p.george at gmail.com  Sun Nov  8 17:49:10 2015
From: damien.p.george at gmail.com (Damien George)
Date: Sun, 8 Nov 2015 22:49:10 +0000
Subject: [Microbit-Python] First draft doc attempt at Larry's game
 related work
In-Reply-To: <20151107210625.29f2fd3e@ghostwheel>
References: <563E4540.1060805@ntoll.org> <20151107210625.29f2fd3e@ghostwheel>
Message-ID: <CANw+MzmWzw7jXThZk1oF4fE9KyvAbvO9YrbXypkvRmVc1hMONg@mail.gmail.com>

Wouldn't it be much cleaner to have the scheduler implement something
that a for loop can iterate over?  Ie schedule.run() raises
StopIteration to finish.  Then you have:

for ev in schedule.run():
    print(ev)


On Sat, Nov 7, 2015 at 8:06 PM, Radomir Dopieralski
<radomir at dopieralski.pl> wrote:
> On Sat, 7 Nov 2015 18:38:56 +0000
> "Nicholas H.Tollervey" <ntoll at ntoll.org> wrote:
>
>> Hi Folks,
>>
>> If you remember, Larry created three classes to aid in game making on
>> the micro:bit. You can find his notes here:
>>
>> https://bitbucket.org/larry/microbit_game
> [...]
>>
>> As always, comments, constructive critique and ideas are most welcome!
>
> It looks good, I just have a couple of notes, not sure how relevant they are.
>
> When I read "Only returns this true value once per button press.", a red
> flag came up. That means that a method that you use to read data modifies the
> data you are reading, effectively destroying it. It means that you are up for
> horrible pain and suffering if you ever dare to use that method in more than
> one place. And that means that the only sane way of using it is to call it
> somewhere in your main loop and cache the result in a global variable. That
> is a bad practice in itself.
>
> I am even more worried that this is not mentioned in the actual documentation,
> so that people who stumble into this problem are likely to be taken by
> surprise and baffled.
>
> I only hope that it is not mentioned in the documentation because it was
> actually removed in the final version.
>
> I have some limited experience writing small games with PyGame for Ludum
> Dare, and I noticed that the way I do timing in them is very different from
> what is proposed here. There are basically two main use cases: a turn-based
> game and a real-time game.
>
> In a turn-based game, you basically sit there waiting until the player presses
> a key or otherwise provides input. Once that happens, you process the input,
> modify the game state accordingly, update the display (possibly playing some
> animations) and go back to waiting. If the player provides input while you are
> processing it, it should get buffered, and might in addition skip the
> animation.
>
> Real-time games usually are not really real-time, in the sense of real-time
> systems. They actually run on an internal clock, calculating and displaying
> "frames" for the player. There are two ways this internal clock may work. In
> the simplest case, the clock "ticks" at a specified number of ticks per second,
> and during each tick, a single frame is calculated. The process usually starts
> with retrieving any player input from the buffers, and possibly updates from
> outside, in a case of an online game. Those are then processed, together with
> advancing any internal game clocks and updating its internal state. Then the
> display is updated, and the system waits for the next clock tick. The more
> advanced way, the frames are calculated as fast as possible, but they get an
> additional parameter from the clock -- the time since the last frame. That is
> used to integrate any motion and animations (in the simplest case, the
> positions of objects are updated by their speed times the time, but there are
> better ways to do it). This makes the system a little more robust against
> frames that took too long to calculate -- it becomes less fluent, but the game
> time doesn't slow down, as in the first approach.
>
> In any way, while the proposed scheduler class could be used to implement the
> first approach to the real-time games (using only small part of its
> functionality), it's not very helpful for the turn-based case and the case with
> fluid frames.
>
> I wonder if we could provide some help for writing those other kinds of games,
> especially the turn-based ones, as this is probably going to be the easiest
> to make. Some ideas would include an input buffer (we take it for granted on
> a PC), a function similar to pygame.time.Clock.tick that waits until a set time
> passes from its last call, and perhaps an integrator?
>
> --
> Radomir Dopieralski
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit

From ntoll at ntoll.org  Sun Nov  8 18:50:42 2015
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Sun, 8 Nov 2015 23:50:42 +0000
Subject: [Microbit-Python] First draft doc attempt at Larry's game
 related work
In-Reply-To: <20151107210625.29f2fd3e@ghostwheel>
References: <563E4540.1060805@ntoll.org> <20151107210625.29f2fd3e@ghostwheel>
Message-ID: <563FDFD2.4010502@ntoll.org>

On 07/11/15 20:06, Radomir Dopieralski wrote:
> On Sat, 7 Nov 2015 18:38:56 +0000
> "Nicholas H.Tollervey" <ntoll at ntoll.org> wrote:
> 
>> Hi Folks,
>>
>> If you remember, Larry created three classes to aid in game making on
>> the micro:bit. You can find his notes here:
>>
>> https://bitbucket.org/larry/microbit_game
> [...]
>>
>> As always, comments, constructive critique and ideas are most welcome!
> 
> It looks good, I just have a couple of notes, not sure how relevant they are.
> 
> When I read "Only returns this true value once per button press.", a red

Where are you reading this in the document I wrote..?

> flag came up. That means that a method that you use to read data modifies the
> data you are reading, effectively destroying it. It means that you are up for
> horrible pain and suffering if you ever dare to use that method in more than
> one place. And that means that the only sane way of using it is to call it
> somewhere in your main loop and cache the result in a global variable. That
> is a bad practice in itself.
> 
> I am even more worried that this is not mentioned in the actual documentation,
> so that people who stumble into this problem are likely to be taken by
> surprise and baffled.
> 
> I only hope that it is not mentioned in the documentation because it was
> actually removed in the final version.
> 

So this is a straw man document based on the initial work Larry so
kindly contributed. The intention is to quickly generate discussion (it
worked) so we can speedily agree an API and associated implementation
details in order to port Larry's work to the micro:bit.

Basically, jump in with comments, constructive critique and ideas. Code
is welcome too. ;-)

> I have some limited experience writing small games with PyGame for Ludum
> Dare, and I noticed that the way I do timing in them is very different from
> what is proposed here. There are basically two main use cases: a turn-based
> game and a real-time game.
> 
> In a turn-based game, you basically sit there waiting until the player presses
> a key or otherwise provides input. Once that happens, you process the input,
> modify the game state accordingly, update the display (possibly playing some
> animations) and go back to waiting. If the player provides input while you are
> processing it, it should get buffered, and might in addition skip the
> animation.
> 

Right... you've basically described a Tamogotchi type game for the
micro:bit.

> Real-time games usually are not really real-time, in the sense of real-time
> systems. They actually run on an internal clock, calculating and displaying
> "frames" for the player. There are two ways this internal clock may work. In
> the simplest case, the clock "ticks" at a specified number of ticks per second,
> and during each tick, a single frame is calculated. The process usually starts
> with retrieving any player input from the buffers, and possibly updates from
> outside, in a case of an online game. Those are then processed, together with
> advancing any internal game clocks and updating its internal state. Then the
> display is updated, and the system waits for the next clock tick. The more
> advanced way, the frames are calculated as fast as possible, but they get an
> additional parameter from the clock -- the time since the last frame. That is
> used to integrate any motion and animations (in the simplest case, the
> positions of objects are updated by their speed times the time, but there are
> better ways to do it). This makes the system a little more robust against
> frames that took too long to calculate -- it becomes less fluent, but the game
> time doesn't slow down, as in the first approach.
> 
> In any way, while the proposed scheduler class could be used to implement the
> first approach to the real-time games (using only small part of its
> functionality), it's not very helpful for the turn-based case and the case with
> fluid frames.
> 
> I wonder if we could provide some help for writing those other kinds of games,
> especially the turn-based ones, as this is probably going to be the easiest
> to make. Some ideas would include an input buffer (we take it for granted on
> a PC), a function similar to pygame.time.Clock.tick that waits until a set time
> passes from its last call, and perhaps an integrator?
> 

We could do this. However, we could leave it to kids to implement a
simple turn based game themselves?

N.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/microbit/attachments/20151108/50a411f6/attachment.sig>

From ntoll at ntoll.org  Sun Nov  8 18:58:34 2015
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Sun, 8 Nov 2015 23:58:34 +0000
Subject: [Microbit-Python] First draft doc attempt at Larry's game
 related work
In-Reply-To: <CANw+MzmWzw7jXThZk1oF4fE9KyvAbvO9YrbXypkvRmVc1hMONg@mail.gmail.com>
References: <563E4540.1060805@ntoll.org> <20151107210625.29f2fd3e@ghostwheel>
 <CANw+MzmWzw7jXThZk1oF4fE9KyvAbvO9YrbXypkvRmVc1hMONg@mail.gmail.com>
Message-ID: <563FE1AA.6050904@ntoll.org>

On 08/11/15 22:49, Damien George wrote:
> Wouldn't it be much cleaner to have the scheduler implement something
> that a for loop can iterate over?  Ie schedule.run() raises
> StopIteration to finish.  Then you have:
> 
> for ev in schedule.run():
>     print(ev)
> 

I like it. My initial reaction is that this feels right.

Or how about both ways? Just make the schedule class iterable and keep
the run method available for those times when you need it.

for ev in schedule:
    print(ev)

In fact, I can imagine this being a good opportunity to introduce the
notion of an iterable to kids.

Calling .run() each iteration of a "while True:" loop perhaps appears
most obvious in a naive sort of a way. But once the kids have got their
heads around the notion of what the schedule class does, asking
"wouldn't it be nicer if..." and showing them the iterator, explaining
even magic methods and so on, would be a natural next step.

N.

> 
> On Sat, Nov 7, 2015 at 8:06 PM, Radomir Dopieralski
> <radomir at dopieralski.pl> wrote:
>> On Sat, 7 Nov 2015 18:38:56 +0000
>> "Nicholas H.Tollervey" <ntoll at ntoll.org> wrote:
>>
>>> Hi Folks,
>>>
>>> If you remember, Larry created three classes to aid in game making on
>>> the micro:bit. You can find his notes here:
>>>
>>> https://bitbucket.org/larry/microbit_game
>> [...]
>>>
>>> As always, comments, constructive critique and ideas are most welcome!
>>
>> It looks good, I just have a couple of notes, not sure how relevant they are.
>>
>> When I read "Only returns this true value once per button press.", a red
>> flag came up. That means that a method that you use to read data modifies the
>> data you are reading, effectively destroying it. It means that you are up for
>> horrible pain and suffering if you ever dare to use that method in more than
>> one place. And that means that the only sane way of using it is to call it
>> somewhere in your main loop and cache the result in a global variable. That
>> is a bad practice in itself.
>>
>> I am even more worried that this is not mentioned in the actual documentation,
>> so that people who stumble into this problem are likely to be taken by
>> surprise and baffled.
>>
>> I only hope that it is not mentioned in the documentation because it was
>> actually removed in the final version.
>>
>> I have some limited experience writing small games with PyGame for Ludum
>> Dare, and I noticed that the way I do timing in them is very different from
>> what is proposed here. There are basically two main use cases: a turn-based
>> game and a real-time game.
>>
>> In a turn-based game, you basically sit there waiting until the player presses
>> a key or otherwise provides input. Once that happens, you process the input,
>> modify the game state accordingly, update the display (possibly playing some
>> animations) and go back to waiting. If the player provides input while you are
>> processing it, it should get buffered, and might in addition skip the
>> animation.
>>
>> Real-time games usually are not really real-time, in the sense of real-time
>> systems. They actually run on an internal clock, calculating and displaying
>> "frames" for the player. There are two ways this internal clock may work. In
>> the simplest case, the clock "ticks" at a specified number of ticks per second,
>> and during each tick, a single frame is calculated. The process usually starts
>> with retrieving any player input from the buffers, and possibly updates from
>> outside, in a case of an online game. Those are then processed, together with
>> advancing any internal game clocks and updating its internal state. Then the
>> display is updated, and the system waits for the next clock tick. The more
>> advanced way, the frames are calculated as fast as possible, but they get an
>> additional parameter from the clock -- the time since the last frame. That is
>> used to integrate any motion and animations (in the simplest case, the
>> positions of objects are updated by their speed times the time, but there are
>> better ways to do it). This makes the system a little more robust against
>> frames that took too long to calculate -- it becomes less fluent, but the game
>> time doesn't slow down, as in the first approach.
>>
>> In any way, while the proposed scheduler class could be used to implement the
>> first approach to the real-time games (using only small part of its
>> functionality), it's not very helpful for the turn-based case and the case with
>> fluid frames.
>>
>> I wonder if we could provide some help for writing those other kinds of games,
>> especially the turn-based ones, as this is probably going to be the easiest
>> to make. Some ideas would include an input buffer (we take it for granted on
>> a PC), a function similar to pygame.time.Clock.tick that waits until a set time
>> passes from its last call, and perhaps an integrator?
>>
>> --
>> Radomir Dopieralski
>> _______________________________________________
>> 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: <http://mail.python.org/pipermail/microbit/attachments/20151108/37a10598/attachment.sig>

From microbit at sheep.art.pl  Mon Nov  9 03:15:04 2015
From: microbit at sheep.art.pl (Radomir Dopieralski)
Date: Mon, 9 Nov 2015 09:15:04 +0100
Subject: [Microbit-Python] First draft doc attempt at Larry's game
 related work
In-Reply-To: <563FDFD2.4010502@ntoll.org>
References: <563E4540.1060805@ntoll.org> <20151107210625.29f2fd3e@ghostwheel>
 <563FDFD2.4010502@ntoll.org>
Message-ID: <20151109091504.18bf3712@ghostwheel>

On Sun, 8 Nov 2015 23:50:42 +0000
"Nicholas H.Tollervey" <ntoll at ntoll.org> wrote:

> On 07/11/15 20:06, Radomir Dopieralski wrote:

[...]

> > I wonder if we could provide some help for writing those other
> > kinds of games, especially the turn-based ones, as this is probably
> > going to be the easiest to make. Some ideas would include an input
> > buffer (we take it for granted on a PC), a function similar to
> > pygame.time.Clock.tick that waits until a set time passes from its
> > last call, and perhaps an integrator?
>
> We could do this. However, we could leave it to kids to implement a
> simple turn based game themselves?

That is always an option, however, I'm not sure someone who is just
starting will come up with the idea of a ring buffer for input. The
buffer we have in our PCs has become so natural and obvious, that we
often don't even realize it is there.

On a slightly related note, can you attach interrupts to button presses?

By the way, I have written a simple snake game for a microcontroller,
it's not great code, but it could give us some idea about how such a
game could look and work https://hackaday.io/project/7011-frowney

We could also look for other such games and see what they used, and
then think of some way of abstracting that.

-- 
Radomir Dopieralski

From larry at hastings.org  Wed Nov 11 22:57:03 2015
From: larry at hastings.org (Larry Hastings)
Date: Wed, 11 Nov 2015 19:57:03 -0800
Subject: [Microbit-Python] Halp! Reinstalled OS and can't build firmware
 anymore.
Message-ID: <56440E0F.7000308@hastings.org>


I /should/ be current with microbit / micropython / yotta modules.  But 
I installed Ubuntu 15.10, and it turns out my "prebuild.sh" is 
insufficient to get all the dependencies.  When I start a build I get 
this error right away:

    In file included from
    /home/larry/src/microbit/microbit-micropython/yotta_modules/mbed-classic/api/Timer.h:19:0,
                      from
    /home/larry/src/microbit/microbit-micropython/yotta_modules/mbed-classic/common/Timer.cpp:16:
    /home/larry/src/microbit/microbit-micropython/yotta_modules/mbed-classic/api/platform.h:25:19:
    fatal error: cstddef: No such file or directory
      #include <cstddef>
                        ^


This sure looks like libstdc++ to me.  I installed every likely-looking 
libstdc++ library I could find in the package manager.  No joy.

Anybody go from 0 to compiling on Ubuntu recently?

Anxiously yours,


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151111/42811a73/attachment.html>

From ntoll at ntoll.org  Thu Nov 12 03:27:37 2015
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Thu, 12 Nov 2015 08:27:37 +0000
Subject: [Microbit-Python] Halp! Reinstalled OS and can't build firmware
 anymore.
In-Reply-To: <56440E0F.7000308@hastings.org>
References: <56440E0F.7000308@hastings.org>
Message-ID: <56444D79.1000006@ntoll.org>

Larry,

Apologies if this sounds funny, but can you confirm that you've followed
all the instructions in the README file? I notice there are a couple of
PPAs that need adding and you also need to tell yotta to target
bbc-microbit-classic-gcc-nosd.

I'm only asking because, on far too many occasions, I have missed
something in the README. Consider this a pre-flight check to ensure that
we're all on the same page that, "yes, I did follow all the bloody
instructions in the README Nicholas, thankyouverymuch" and thus
something more fundamental has broken. ;-)

I'll spin up a virtualized Ubuntu and have a go myself over lunch (I've
just arrived at "real work" [tm] to an inbox full of "ugh").

All the best,

Nicholas.

On 12/11/15 03:57, Larry Hastings wrote:
> 
> I /should/ be current with microbit / micropython / yotta modules.  But
> I installed Ubuntu 15.10, and it turns out my "prebuild.sh" is
> insufficient to get all the dependencies.  When I start a build I get
> this error right away:
> 
>     In file included from
>     /home/larry/src/microbit/microbit-micropython/yotta_modules/mbed-classic/api/Timer.h:19:0,
>                      from
>     /home/larry/src/microbit/microbit-micropython/yotta_modules/mbed-classic/common/Timer.cpp:16:
>     /home/larry/src/microbit/microbit-micropython/yotta_modules/mbed-classic/api/platform.h:25:19:
>     fatal error: cstddef: No such file or directory
>      #include <cstddef>
>                        ^
> 
> 
> This sure looks like libstdc++ to me.  I installed every likely-looking
> libstdc++ library I could find in the package manager.  No joy.
> 
> Anybody go from 0 to compiling on Ubuntu recently?
> 
> Anxiously yours,
> 
> 
> //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: <http://mail.python.org/pipermail/microbit/attachments/20151112/9e3905dd/attachment.sig>

From larry at hastings.org  Thu Nov 12 04:24:01 2015
From: larry at hastings.org (Larry Hastings)
Date: Thu, 12 Nov 2015 01:24:01 -0800
Subject: [Microbit-Python] Halp! Reinstalled OS and can't build firmware
 anymore.
In-Reply-To: <56444D79.1000006@ntoll.org>
References: <56440E0F.7000308@hastings.org>
	<56444D79.1000006@ntoll.org>
Message-ID: <CAOBd=7=HhmM-TS++A5KfS=Frw9_MGJyQbvOySkw1xLntZdTHJQ@mail.gmail.com>

I wrote the instructions on adding the PPAs ;-)

Yes, I ran the stuff in the README.  I actually open the README and
copy-and-paste it into my shell.  And I added the PPAs in the list.  But it
appears there's some other thing missing--either that, or, the PPAs aren't
entirely ready for the recently-shipped Ubuntu 15.10.

On Thu, Nov 12, 2015 at 12:27 AM, Nicholas H.Tollervey <ntoll at ntoll.org>
wrote:

> Larry,
>
> Apologies if this sounds funny, but can you confirm that you've followed
> all the instructions in the README file? I notice there are a couple of
> PPAs that need adding and you also need to tell yotta to target
> bbc-microbit-classic-gcc-nosd.
>
> I'm only asking because, on far too many occasions, I have missed
> something in the README. Consider this a pre-flight check to ensure that
> we're all on the same page that, "yes, I did follow all the bloody
> instructions in the README Nicholas, thankyouverymuch" and thus
> something more fundamental has broken. ;-)
>
> I'll spin up a virtualized Ubuntu and have a go myself over lunch (I've
> just arrived at "real work" [tm] to an inbox full of "ugh").
>
> All the best,
>
> Nicholas.
>
> On 12/11/15 03:57, Larry Hastings wrote:
> >
> > I /should/ be current with microbit / micropython / yotta modules.  But
> > I installed Ubuntu 15.10, and it turns out my "prebuild.sh" is
> > insufficient to get all the dependencies.  When I start a build I get
> > this error right away:
> >
> >     In file included from
> >
>  /home/larry/src/microbit/microbit-micropython/yotta_modules/mbed-classic/api/Timer.h:19:0,
> >                      from
> >
>  /home/larry/src/microbit/microbit-micropython/yotta_modules/mbed-classic/common/Timer.cpp:16:
> >
>  /home/larry/src/microbit/microbit-micropython/yotta_modules/mbed-classic/api/platform.h:25:19:
> >     fatal error: cstddef: No such file or directory
> >      #include <cstddef>
> >                        ^
> >
> >
> > This sure looks like libstdc++ to me.  I installed every likely-looking
> > libstdc++ library I could find in the package manager.  No joy.
> >
> > Anybody go from 0 to compiling on Ubuntu recently?
> >
> > Anxiously yours,
> >
> >
> > //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: <http://mail.python.org/pipermail/microbit/attachments/20151112/986c70a0/attachment.html>

From tom at viner.tv  Sun Nov 15 15:59:08 2015
From: tom at viner.tv (Tom Viner)
Date: Sun, 15 Nov 2015 20:59:08 +0000
Subject: [Microbit-Python] Automating upyed copy hex file to micro:bit
Message-ID: <CANBSuyEVMLsSdc5YSSWWKXZwJxCB=CYDOAY0_f2yup6SosNXJA@mail.gmail.com>

Hi all,

Now that's I've got my own micro:bit (for a week), as part of microworldtour
<https://microworldtour.github.io/microbit/meixiu.html> I've been playing
around in the upyed editor and trying out the examples.

It doesn't take long to get bored of having to drag the new hex file over
on each change. I've been keeping up with this mailing list, and I'm
surprised this hasn't come up before?

Now long term, people have mentioned making more of an IDE, that I'm sure
would take care of this. But for the moment this is my solution:

https://github.com/tomviner/upyflashed

Comments welcome. It's only tested on Ubuntu so far. In particular it
guesses your browser download directory will be at ~/Downloads and uses
psutil to read your mounted drives looking for one ending in "MICROBIT",
but you can also pass params to the upyflashed command.

Cheers,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151115/24a87357/attachment.html>

From damien.p.george at gmail.com  Sun Nov 15 16:24:21 2015
From: damien.p.george at gmail.com (Damien George)
Date: Sun, 15 Nov 2015 21:24:21 +0000
Subject: [Microbit-Python] Automating upyed copy hex file to micro:bit
In-Reply-To: <CANBSuyEVMLsSdc5YSSWWKXZwJxCB=CYDOAY0_f2yup6SosNXJA@mail.gmail.com>
References: <CANBSuyEVMLsSdc5YSSWWKXZwJxCB=CYDOAY0_f2yup6SosNXJA@mail.gmail.com>
Message-ID: <CANw+Mzmr8FpRdvOheCzgNCYH2JmA1=F+NzuDj7gLVDaHgNMKqg@mail.gmail.com>

Hi Tom,

There is a script called "pyboard.py" which can be used to execute a
script from your PC on the device.  Find it here:
https://github.com/bbcmicrobit/micropython/blob/master/tools/pyboard.py

There are instructions at the top of that file on how to use it.  I
think it'll make your life much easier!

Note that you may need to reset the device (using the reset switch on
the back) before running pyboard.py each time, especially if you're
downloading a big script.

Also note that large scripts will fail to run due to out-of-memory
errors.  This is because pyboard.py is downloading the entire script
into RAM, and then compiling it.  If you run into this problem then
you need to revert to the .hex file way of doing things (which can run
roughly 3 times script size as pyboard.py).

Happy hacking!

Cheers,
Damien.


On Sun, Nov 15, 2015 at 8:59 PM, Tom Viner <tom at viner.tv> wrote:
> Hi all,
>
> Now that's I've got my own micro:bit (for a week), as part of microworldtour
> I've been playing around in the upyed editor and trying out the examples.
>
> It doesn't take long to get bored of having to drag the new hex file over on
> each change. I've been keeping up with this mailing list, and I'm surprised
> this hasn't come up before?
>
> Now long term, people have mentioned making more of an IDE, that I'm sure
> would take care of this. But for the moment this is my solution:
>
> https://github.com/tomviner/upyflashed
>
> Comments welcome. It's only tested on Ubuntu so far. In particular it
> guesses your browser download directory will be at ~/Downloads and uses
> psutil to read your mounted drives looking for one ending in "MICROBIT", but
> you can also pass params to the upyflashed command.
>
> Cheers,
> Tom
>
>
>
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit
>

From ntoll at ntoll.org  Mon Nov 16 03:49:44 2015
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Mon, 16 Nov 2015 08:49:44 +0000
Subject: [Microbit-Python] Version 0.9 - mid-Novermber (it *IS* mid-November)
Message-ID: <564998A8.1080409@ntoll.org>

Hi folks,

A couple of weeks ago, after discussion with Damien, I drew an arbitrary
line in the sand for version 0.9 (the details of which can be found
here: https://github.com/bbcmicrobit/micropython/milestones/Version%200.9).

Several of you have made wonderful and substantial contributions to the
tickets found therein.

Now is the time to put that final bit of effort in an land these changes.

It was my wife's birthday over the weekend and is my daughter's birthday
today, so I'm a tad tied up with family things. But I intend to spend
some time tomorrow and Wednesday on getting to 0.9.

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: <http://mail.python.org/pipermail/microbit/attachments/20151116/25197bb5/attachment.sig>

From mschafer at wireframe.biz  Mon Nov 16 20:25:27 2015
From: mschafer at wireframe.biz (Mark Schafer)
Date: Tue, 17 Nov 2015 14:25:27 +1300
Subject: [Microbit-Python] neopixel and micropython
Message-ID: <564A8207.6010801@wireframe.biz>

Hi All,
I'm working on adding Neopixel support to the Microbit.
Specifically using https://github.com/lavallc/nrf51-neopixel

Currently Damien has added this to the bbcmicrobit/micropython repo

I'm a python guy and I'm probably going to need some help.
Cheers, Mark...

From ntoll at ntoll.org  Tue Nov 17 10:07:12 2015
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Tue, 17 Nov 2015 15:07:12 +0000
Subject: [Microbit-Python] Battery plug orientation
Message-ID: <564B42A0.4060809@ntoll.org>

Hi,

It's not clear which is +/- for the battery plug. Can someone who knows
(Jonny? David W?) confirm which way round it is..?

Thanks!

N.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/microbit/attachments/20151117/2160c859/attachment.sig>

From david at thinkingbinaries.com  Tue Nov 17 12:33:47 2015
From: david at thinkingbinaries.com (David Whale)
Date: Tue, 17 Nov 2015 17:33:47 +0000
Subject: [Microbit-Python] Battery plug orientation
In-Reply-To: <564B42A0.4060809@ntoll.org>
References: <564B42A0.4060809@ntoll.org>
Message-ID: <CABeH_St-n1yQ+qVnj2R2O3C2w-oEw_OJ=sTVCkEJGHi--h_CVA@mail.gmail.com>

Hi Nicholas

It changed between revisions. On the older revision boards that had no silk
screen haircut on them, the red positive went next to the reset switch.
This was wrong compared to every other battery pack wiring you might find
on the internet for other boards.

The newer boards with the silk screen haircut on the front, the red wire is
on the edge of the board. The later version of the board now also has a 3V
marked on the underside edge of the micro:bit to clarify this.

So, on the more recent boards, if you buy a battery pack for an Adafruit
Flora, Gemma etc, it is wired the same, which is useful indeed!

See attached wobbly photo I just took of my latest micro:bit - you can just
about see on the top right corner the 3V and the little solid and dashed
line on the silk screen.

[image: Inline images 1]

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" <http://amzn.to/ZGfxZG>
- lets get kids coding!


On 17 November 2015 at 15:07, Nicholas H.Tollervey <ntoll at ntoll.org> wrote:

> Hi,
>
> It's not clear which is +/- for the battery plug. Can someone who knows
> (Jonny? David W?) confirm which way round it is..?
>
> Thanks!
>
> N.
>
>
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151117/4700c13d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2015-11-17 17.31.36.jpg
Type: image/jpeg
Size: 75995 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/microbit/attachments/20151117/4700c13d/attachment-0001.jpg>

From ntoll at ntoll.org  Tue Nov 17 18:53:16 2015
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Tue, 17 Nov 2015 23:53:16 +0000
Subject: [Microbit-Python] Battery plug orientation
In-Reply-To: <CABeH_St-n1yQ+qVnj2R2O3C2w-oEw_OJ=sTVCkEJGHi--h_CVA@mail.gmail.com>
References: <564B42A0.4060809@ntoll.org>
 <CABeH_St-n1yQ+qVnj2R2O3C2w-oEw_OJ=sTVCkEJGHi--h_CVA@mail.gmail.com>
Message-ID: <564BBDEC.3010903@ntoll.org>

Great stuff David, and many many thanks!

N.

On 17/11/15 17:33, David Whale wrote:
> Hi Nicholas
> 
> It changed between revisions. On the older revision boards that had no
> silk screen haircut on them, the red positive went next to the reset
> switch. This was wrong compared to every other battery pack wiring you
> might find on the internet for other boards.
> 
> The newer boards with the silk screen haircut on the front, the red wire
> is on the edge of the board. The later version of the board now also has
> a 3V marked on the underside edge of the micro:bit to clarify this.
> 
> So, on the more recent boards, if you buy a battery pack for an Adafruit
> Flora, Gemma etc, it is wired the same, which is useful indeed!
> 
> See attached wobbly photo I just took of my latest micro:bit - you can
> just about see on the top right corner the 3V and the little solid and
> dashed line on the silk screen.
> 
> Inline images 1
> 
> David
> 
> 
> ___________________________________________________________
> David Whale, B.Sc (Hons), MIET
> *Software Engineer and IET Schools Liaison Officer, Essex*
> 
> email:  dwhale at theiet.org <mailto:dwhale at theiet.org>
> twitter: @whaleygeek
> blog:  blog.whaleygeek.co.uk <http://blog.whaleygeek.co.uk>
> 
> Co-author of the new book "Adventures in Minecraft"
> <http://amzn.to/ZGfxZG> - lets get kids coding!
> 
> 
> On 17 November 2015 at 15:07, Nicholas H.Tollervey <ntoll at ntoll.org
> <mailto:ntoll at ntoll.org>> wrote:
> 
>     Hi,
> 
>     It's not clear which is +/- for the battery plug. Can someone who knows
>     (Jonny? David W?) confirm which way round it is..?
> 
>     Thanks!
> 
>     N.
> 
> 
>     _______________________________________________
>     Microbit mailing list
>     Microbit at python.org <mailto:Microbit at python.org>
>     https://mail.python.org/mailman/listinfo/microbit
> 
> 
> 
> 
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/microbit/attachments/20151117/66dfc00b/attachment.sig>

From microbit at sheep.art.pl  Wed Nov 18 05:04:55 2015
From: microbit at sheep.art.pl (Radomir Dopieralski)
Date: Wed, 18 Nov 2015 11:04:55 +0100
Subject: [Microbit-Python] Battery plug orientation
In-Reply-To: <564BBDEC.3010903@ntoll.org>
References: <564B42A0.4060809@ntoll.org>
 <CABeH_St-n1yQ+qVnj2R2O3C2w-oEw_OJ=sTVCkEJGHi--h_CVA@mail.gmail.com>
 <564BBDEC.3010903@ntoll.org>
Message-ID: <20151118110455.5f8aca8f@ghostwheel>

On 17/11/15 17:33, David Whale wrote:

> The newer boards with the silk screen haircut on the front, the red
> wire is on the edge of the board. The later version of the board
> now also has a 3V marked on the underside edge of the micro:bit to
> clarify this.

Excellent, thank you! Of course this is exactly the opposite of how
the plugs on Turnigy LiPos are keyed :(

Do you also happen to know what voltages are accepted?

-- 
Radomir Dopieralski

From david at thinkingbinaries.com  Wed Nov 18 05:26:12 2015
From: david at thinkingbinaries.com (David Whale)
Date: Wed, 18 Nov 2015 10:26:12 +0000
Subject: [Microbit-Python] Battery plug orientation
In-Reply-To: <20151118110455.5f8aca8f@ghostwheel>
References: <564B42A0.4060809@ntoll.org>
 <CABeH_St-n1yQ+qVnj2R2O3C2w-oEw_OJ=sTVCkEJGHi--h_CVA@mail.gmail.com>
 <564BBDEC.3010903@ntoll.org> <20151118110455.5f8aca8f@ghostwheel>
Message-ID: <CABeH_SuLL77aSdZuN_0_VP9PPXf5pYq7gKZLHz+iE3KZkR1oug@mail.gmail.com>

On the voltages front...

Jonny is your man there. I think the on-chip regulator is used, so checking
the data sheet (and accounting for 1 diode drop, I think) might give you
the answer.

I seem to recall I saw Michael Sparks using a two coin cell (6V) battery
pack with it successfully, although that's  probably not recommended, it
appeared to work!

I use the same one from the Adafruit sewables kit but only fit one battery
- usefully the contacts on the other battery container if bent enough will
connect together, giving you a nice flat little battery pack including an
on-off switch. However, the AAA batteries last for ages, but the coin cell
runs out a lot quicker, and I sometimes notice some spurious resets with
it, presumably because it's not providing enough current with some of the
smaller capacity batteries.

One to be aware of is if you power it from the 3V pad at the bottom, I
think that avoids the diode drop from what I remember Howard saying, so you
might have to be more careful with voltage and polarisation on those pads -
but I think Jonny could squash any heresay and speculation here. I don't
have access to the schematics so I can't really comment in detail.

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" <http://amzn.to/ZGfxZG>
- lets get kids coding!


On 18 November 2015 at 10:04, Radomir Dopieralski <microbit at sheep.art.pl>
wrote:

> On 17/11/15 17:33, David Whale wrote:
>
> > The newer boards with the silk screen haircut on the front, the red
> > wire is on the edge of the board. The later version of the board
> > now also has a 3V marked on the underside edge of the micro:bit to
> > clarify this.
>
> Excellent, thank you! Of course this is exactly the opposite of how
> the plugs on Turnigy LiPos are keyed :(
>
> Do you also happen to know what voltages are accepted?
>
> --
> Radomir Dopieralski
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151118/764b3460/attachment.html>

From ntoll at ntoll.org  Fri Nov 20 21:44:09 2015
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Sat, 21 Nov 2015 02:44:09 +0000
Subject: [Microbit-Python] Python editor for TouchDevelop
Message-ID: <564FDA79.7020207@ntoll.org>

Hi Folks,

Video of the re-designed editor. Still lots to do, but we're getting
there..!

https://www.youtube.com/watch?v=09pRYw0XiC4

As always, comments, constructive critique and ideas most welcome!

N.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/microbit/attachments/20151121/d3f07c65/attachment.sig>

From mark at hotpy.org  Sun Nov 22 15:44:03 2015
From: mark at hotpy.org (Mark Shannon)
Date: Sun, 22 Nov 2015 20:44:03 +0000
Subject: [Microbit-Python] Merging Pull requests.
Message-ID: <56522913.1060702@hotpy.org>

Hi all,

Can I repeat my request that everyone uses the standard GitHub 
mechanisms for reviewing and merging code.
No one should merge their own code and *all* code should be reviewed 
before merging.

Although my original reason for asking this is to democratize our
development process, there also practical reasons for asking.

Using a standard git merge allows git to track which branches have been 
merged, which makes it a lot easier to safely delete branches and
keep a record of work completed.

If a branch is not merged cleanly then this:
$ git branch -d my-finished-branch
doesn't work and I need to manual verify that the branch has indeed been 
merged and no commits omitted.

Cheers,
Mark.

From damien.p.george at gmail.com  Sun Nov 22 18:01:00 2015
From: damien.p.george at gmail.com (Damien George)
Date: Sun, 22 Nov 2015 23:01:00 +0000
Subject: [Microbit-Python] Merging Pull requests.
In-Reply-To: <56522913.1060702@hotpy.org>
References: <56522913.1060702@hotpy.org>
Message-ID: <CANw+Mzn2zbJKZ0CWaw6GZJ5oXGX6Jo3ugorRQhtxU8emXYHEHg@mail.gmail.com>

Hi Mark,

I always rebase a branch before merging, and this (usually) means that
the git hash changes and so your "git branch -d" will need to be a
"git branch -D".

Rebasing and having a linear history is, in my opinion, much more
important for long term maintainability than using standard git
merging and being able to see that the exact commit went through
(which may not be true since there could have been conflicts).

Most of the time a rebase will be clean and the commits just go
through, albeit with a new hash.

Cheers,
Damien.



On Sun, Nov 22, 2015 at 8:44 PM, Mark Shannon <mark at hotpy.org> wrote:
> Hi all,
>
> Can I repeat my request that everyone uses the standard GitHub mechanisms
> for reviewing and merging code.
> No one should merge their own code and *all* code should be reviewed before
> merging.
>
> Although my original reason for asking this is to democratize our
> development process, there also practical reasons for asking.
>
> Using a standard git merge allows git to track which branches have been
> merged, which makes it a lot easier to safely delete branches and
> keep a record of work completed.
>
> If a branch is not merged cleanly then this:
> $ git branch -d my-finished-branch
> doesn't work and I need to manual verify that the branch has indeed been
> merged and no commits omitted.
>
> Cheers,
> Mark.
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit

From guido at python.org  Sun Nov 22 18:12:12 2015
From: guido at python.org (Guido van Rossum)
Date: Sun, 22 Nov 2015 15:12:12 -0800
Subject: [Microbit-Python] Merging Pull requests.
In-Reply-To: <CANw+Mzn2zbJKZ0CWaw6GZJ5oXGX6Jo3ugorRQhtxU8emXYHEHg@mail.gmail.com>
References: <56522913.1060702@hotpy.org>
 <CANw+Mzn2zbJKZ0CWaw6GZJ5oXGX6Jo3ugorRQhtxU8emXYHEHg@mail.gmail.com>
Message-ID: <CAP7+vJKQGXaCkEq7_hOLBgaV5eQ-Mae3C0hJj09zA3dLmAK=bA@mail.gmail.com>

I believe this is a topic of holy war proportions. I agree with
Damien, branches are distracting in the long-term history (and so are
GitHub merge turds). Tooling can help here (though I don't know what
to recommend -- at Dropbox we use Phabricator which takes care of this
for us but it's too heavy for an open source project). Code review is
of course a different topic, I agree that all code should be reviewed
before it is merged/rebased.

On Sun, Nov 22, 2015 at 3:01 PM, Damien George
<damien.p.george at gmail.com> wrote:
> Hi Mark,
>
> I always rebase a branch before merging, and this (usually) means that
> the git hash changes and so your "git branch -d" will need to be a
> "git branch -D".
>
> Rebasing and having a linear history is, in my opinion, much more
> important for long term maintainability than using standard git
> merging and being able to see that the exact commit went through
> (which may not be true since there could have been conflicts).
>
> Most of the time a rebase will be clean and the commits just go
> through, albeit with a new hash.
>
> Cheers,
> Damien.
>
>
>
> On Sun, Nov 22, 2015 at 8:44 PM, Mark Shannon <mark at hotpy.org> wrote:
>> Hi all,
>>
>> Can I repeat my request that everyone uses the standard GitHub mechanisms
>> for reviewing and merging code.
>> No one should merge their own code and *all* code should be reviewed before
>> merging.
>>
>> Although my original reason for asking this is to democratize our
>> development process, there also practical reasons for asking.
>>
>> Using a standard git merge allows git to track which branches have been
>> merged, which makes it a lot easier to safely delete branches and
>> keep a record of work completed.
>>
>> If a branch is not merged cleanly then this:
>> $ git branch -d my-finished-branch
>> doesn't work and I need to manual verify that the branch has indeed been
>> merged and no commits omitted.
>>
>> 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



-- 
--Guido van Rossum (python.org/~guido)

From mark at hotpy.org  Sun Nov 22 18:24:54 2015
From: mark at hotpy.org (Mark Shannon)
Date: Sun, 22 Nov 2015 23:24:54 +0000
Subject: [Microbit-Python] Merging Pull requests.
In-Reply-To: <CANw+Mzn2zbJKZ0CWaw6GZJ5oXGX6Jo3ugorRQhtxU8emXYHEHg@mail.gmail.com>
References: <56522913.1060702@hotpy.org>
 <CANw+Mzn2zbJKZ0CWaw6GZJ5oXGX6Jo3ugorRQhtxU8emXYHEHg@mail.gmail.com>
Message-ID: <56524EC6.8000301@hotpy.org>



On 22/11/15 23:01, Damien George wrote:
> Hi Mark,
>
> I always rebase a branch before merging, and this (usually) means that
> the git hash changes and so your "git branch -d" will need to be a
> "git branch -D".
That is all very well on your own private code base, but it doesn't work 
on a shared code base.
Who gets to rebase other people's branches and who doesn't?
Your approach just doesn't work if everyone is to be treated equally.

>
> Rebasing and having a linear history is, in my opinion, much more
> important for long term maintainability than using standard git
> merging and being able to see that the exact commit went through
> (which may not be true since there could have been conflicts).
History is not neat and linear.
What use is DVCS history, if not for working out how certain parts of 
the code came to be and who worked on them? If you linearise the 
history, then you can loose that.

>
> Most of the time a rebase will be clean and the commits just go
> through, albeit with a new hash.
Asking everyone to rebase their own branches before review will keep 
everything clean. It is also fair and transparent.

>
> Cheers,
> Damien.
>
>
>
> On Sun, Nov 22, 2015 at 8:44 PM, Mark Shannon <mark at hotpy.org> wrote:
>> Hi all,
>>
>> Can I repeat my request that everyone uses the standard GitHub mechanisms
>> for reviewing and merging code.
>> No one should merge their own code and *all* code should be reviewed before
>> merging.
>>
>> Although my original reason for asking this is to democratize our
>> development process, there also practical reasons for asking.
>>
>> Using a standard git merge allows git to track which branches have been
>> merged, which makes it a lot easier to safely delete branches and
>> keep a record of work completed.
>>
>> If a branch is not merged cleanly then this:
>> $ git branch -d my-finished-branch
>> doesn't work and I need to manual verify that the branch has indeed been
>> merged and no commits omitted.
>>
>> 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 mark at hotpy.org  Sun Nov 22 18:32:49 2015
From: mark at hotpy.org (Mark Shannon)
Date: Sun, 22 Nov 2015 23:32:49 +0000
Subject: [Microbit-Python] Merging Pull requests.
In-Reply-To: <CAP7+vJKQGXaCkEq7_hOLBgaV5eQ-Mae3C0hJj09zA3dLmAK=bA@mail.gmail.com>
References: <56522913.1060702@hotpy.org>
 <CANw+Mzn2zbJKZ0CWaw6GZJ5oXGX6Jo3ugorRQhtxU8emXYHEHg@mail.gmail.com>
 <CAP7+vJKQGXaCkEq7_hOLBgaV5eQ-Mae3C0hJj09zA3dLmAK=bA@mail.gmail.com>
Message-ID: <565250A1.4070706@hotpy.org>

Hi Guido,
I didn't know you were taking an interest in this project. Do you have a 
micro:bit?

I think the advantage of the GitHub model is that it is equitable.
Working on CPython has convinced me that a fair and democratic model is 
very important.

Cheers,
Mark

On 22/11/15 23:12, Guido van Rossum wrote:
> I believe this is a topic of holy war proportions. I agree with
> Damien, branches are distracting in the long-term history (and so are
> GitHub merge turds). Tooling can help here (though I don't know what
> to recommend -- at Dropbox we use Phabricator which takes care of this
> for us but it's too heavy for an open source project). Code review is
> of course a different topic, I agree that all code should be reviewed
> before it is merged/rebased.
>
> On Sun, Nov 22, 2015 at 3:01 PM, Damien George
> <damien.p.george at gmail.com> wrote:
>> Hi Mark,
>>
>> I always rebase a branch before merging, and this (usually) means that
>> the git hash changes and so your "git branch -d" will need to be a
>> "git branch -D".
>>
>> Rebasing and having a linear history is, in my opinion, much more
>> important for long term maintainability than using standard git
>> merging and being able to see that the exact commit went through
>> (which may not be true since there could have been conflicts).
>>
>> Most of the time a rebase will be clean and the commits just go
>> through, albeit with a new hash.
>>
>> Cheers,
>> Damien.
>>
>>
>>
>> On Sun, Nov 22, 2015 at 8:44 PM, Mark Shannon <mark at hotpy.org> wrote:
>>> Hi all,
>>>
>>> Can I repeat my request that everyone uses the standard GitHub mechanisms
>>> for reviewing and merging code.
>>> No one should merge their own code and *all* code should be reviewed before
>>> merging.
>>>
>>> Although my original reason for asking this is to democratize our
>>> development process, there also practical reasons for asking.
>>>
>>> Using a standard git merge allows git to track which branches have been
>>> merged, which makes it a lot easier to safely delete branches and
>>> keep a record of work completed.
>>>
>>> If a branch is not merged cleanly then this:
>>> $ git branch -d my-finished-branch
>>> doesn't work and I need to manual verify that the branch has indeed been
>>> merged and no commits omitted.
>>>
>>> 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 guido at python.org  Sun Nov 22 19:37:42 2015
From: guido at python.org (Guido van Rossum)
Date: Sun, 22 Nov 2015 16:37:42 -0800
Subject: [Microbit-Python] Merging Pull requests.
In-Reply-To: <565250A1.4070706@hotpy.org>
References: <56522913.1060702@hotpy.org>
 <CANw+Mzn2zbJKZ0CWaw6GZJ5oXGX6Jo3ugorRQhtxU8emXYHEHg@mail.gmail.com>
 <CAP7+vJKQGXaCkEq7_hOLBgaV5eQ-Mae3C0hJj09zA3dLmAK=bA@mail.gmail.com>
 <565250A1.4070706@hotpy.org>
Message-ID: <CAP7+vJKE04R8aAwVbLfhDpqFqNq2WgYOhrHnmtAoTSvRX4DCog@mail.gmail.com>

On Sun, Nov 22, 2015 at 3:32 PM, Mark Shannon <mark at hotpy.org> wrote:
> Hi Guido,
> I didn't know you were taking an interest in this project. Do you have a
> micro:bit?

Yes, Nick sent me one. I haven't had much time to play with it, but I
showed it off at a conference a few weeks ago to great acclaim.

> I think the advantage of the GitHub model is that it is equitable.
> Working on CPython has convinced me that a fair and democratic model is very
> important.

I'm sorry already I jumped into the discussion; I have no desire to continue it.

--Guido

> Cheers,
> Mark
>
>
> On 22/11/15 23:12, Guido van Rossum wrote:
>>
>> I believe this is a topic of holy war proportions. I agree with
>> Damien, branches are distracting in the long-term history (and so are
>> GitHub merge turds). Tooling can help here (though I don't know what
>> to recommend -- at Dropbox we use Phabricator which takes care of this
>> for us but it's too heavy for an open source project). Code review is
>> of course a different topic, I agree that all code should be reviewed
>> before it is merged/rebased.
>>
>> On Sun, Nov 22, 2015 at 3:01 PM, Damien George
>> <damien.p.george at gmail.com> wrote:
>>>
>>> Hi Mark,
>>>
>>> I always rebase a branch before merging, and this (usually) means that
>>> the git hash changes and so your "git branch -d" will need to be a
>>> "git branch -D".
>>>
>>> Rebasing and having a linear history is, in my opinion, much more
>>> important for long term maintainability than using standard git
>>> merging and being able to see that the exact commit went through
>>> (which may not be true since there could have been conflicts).
>>>
>>> Most of the time a rebase will be clean and the commits just go
>>> through, albeit with a new hash.
>>>
>>> Cheers,
>>> Damien.
>>>
>>>
>>>
>>> On Sun, Nov 22, 2015 at 8:44 PM, Mark Shannon <mark at hotpy.org> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Can I repeat my request that everyone uses the standard GitHub
>>>> mechanisms
>>>> for reviewing and merging code.
>>>> No one should merge their own code and *all* code should be reviewed
>>>> before
>>>> merging.
>>>>
>>>> Although my original reason for asking this is to democratize our
>>>> development process, there also practical reasons for asking.
>>>>
>>>> Using a standard git merge allows git to track which branches have been
>>>> merged, which makes it a lot easier to safely delete branches and
>>>> keep a record of work completed.
>>>>
>>>> If a branch is not merged cleanly then this:
>>>> $ git branch -d my-finished-branch
>>>> doesn't work and I need to manual verify that the branch has indeed been
>>>> merged and no commits omitted.
>>>>
>>>> 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
>>
>>
>>
>>
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit



-- 
--Guido van Rossum (python.org/~guido)

From damien.p.george at gmail.com  Mon Nov 23 05:28:13 2015
From: damien.p.george at gmail.com (Damien George)
Date: Mon, 23 Nov 2015 10:28:13 +0000
Subject: [Microbit-Python] Merging Pull requests.
In-Reply-To: <56524EC6.8000301@hotpy.org>
References: <56522913.1060702@hotpy.org>
 <CANw+Mzn2zbJKZ0CWaw6GZJ5oXGX6Jo3ugorRQhtxU8emXYHEHg@mail.gmail.com>
 <56524EC6.8000301@hotpy.org>
Message-ID: <CANw+MzmOuRL0nsWXkk_5h2k8yP0qz7C0fpuooA_zSRoOj5ajYg@mail.gmail.com>

> Asking everyone to rebase their own branches before review will keep
> everything clean. It is also fair and transparent.

We can try this approach.  But it means organising the order in which
PRs get merged, and asking the owner to rebase cleanly when the
reviewer is ready to merge.

From damien.p.george at gmail.com  Tue Nov 24 10:38:37 2015
From: damien.p.george at gmail.com (Damien George)
Date: Tue, 24 Nov 2015 15:38:37 +0000
Subject: [Microbit-Python] Halp! Reinstalled OS and can't build firmware
 anymore.
In-Reply-To: <CAOBd=7=HhmM-TS++A5KfS=Frw9_MGJyQbvOySkw1xLntZdTHJQ@mail.gmail.com>
References: <56440E0F.7000308@hastings.org> <56444D79.1000006@ntoll.org>
 <CAOBd=7=HhmM-TS++A5KfS=Frw9_MGJyQbvOySkw1xLntZdTHJQ@mail.gmail.com>
Message-ID: <CANw+MznhF789gOiaxCQaYKK7ODUBqva_rtJv5qsE3w06=rNrhQ@mail.gmail.com>

Larry, did you find a solution to this?  We have another report of the
same problem: https://github.com/bbcmicrobit/micropython/issues/109

On Thu, Nov 12, 2015 at 9:24 AM, Larry Hastings <larry at hastings.org> wrote:
> I wrote the instructions on adding the PPAs ;-)
>
> Yes, I ran the stuff in the README.  I actually open the README and
> copy-and-paste it into my shell.  And I added the PPAs in the list.  But it
> appears there's some other thing missing--either that, or, the PPAs aren't
> entirely ready for the recently-shipped Ubuntu 15.10.
>
>
> On Thu, Nov 12, 2015 at 12:27 AM, Nicholas H.Tollervey <ntoll at ntoll.org>
> wrote:
>>
>> Larry,
>>
>> Apologies if this sounds funny, but can you confirm that you've followed
>> all the instructions in the README file? I notice there are a couple of
>> PPAs that need adding and you also need to tell yotta to target
>> bbc-microbit-classic-gcc-nosd.
>>
>> I'm only asking because, on far too many occasions, I have missed
>> something in the README. Consider this a pre-flight check to ensure that
>> we're all on the same page that, "yes, I did follow all the bloody
>> instructions in the README Nicholas, thankyouverymuch" and thus
>> something more fundamental has broken. ;-)
>>
>> I'll spin up a virtualized Ubuntu and have a go myself over lunch (I've
>> just arrived at "real work" [tm] to an inbox full of "ugh").
>>
>> All the best,
>>
>> Nicholas.
>>
>> On 12/11/15 03:57, Larry Hastings wrote:
>> >
>> > I /should/ be current with microbit / micropython / yotta modules.  But
>> > I installed Ubuntu 15.10, and it turns out my "prebuild.sh" is
>> > insufficient to get all the dependencies.  When I start a build I get
>> > this error right away:
>> >
>> >     In file included from
>> >
>> > /home/larry/src/microbit/microbit-micropython/yotta_modules/mbed-classic/api/Timer.h:19:0,
>> >                      from
>> >
>> > /home/larry/src/microbit/microbit-micropython/yotta_modules/mbed-classic/common/Timer.cpp:16:
>> >
>> > /home/larry/src/microbit/microbit-micropython/yotta_modules/mbed-classic/api/platform.h:25:19:
>> >     fatal error: cstddef: No such file or directory
>> >      #include <cstddef>
>> >                        ^
>> >
>> >
>> > This sure looks like libstdc++ to me.  I installed every likely-looking
>> > libstdc++ library I could find in the package manager.  No joy.
>> >
>> > Anybody go from 0 to compiling on Ubuntu recently?
>> >
>> > Anxiously yours,
>> >
>> >
>> > //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
>

From sparks.m at gmail.com  Tue Nov 24 11:25:56 2015
From: sparks.m at gmail.com (Michael)
Date: Tue, 24 Nov 2015 16:25:56 +0000
Subject: [Microbit-Python] Halp! Reinstalled OS and can't build firmware
 anymore.
In-Reply-To: <CANw+MznhF789gOiaxCQaYKK7ODUBqva_rtJv5qsE3w06=rNrhQ@mail.gmail.com>
References: <56440E0F.7000308@hastings.org> <56444D79.1000006@ntoll.org>
 <CAOBd=7=HhmM-TS++A5KfS=Frw9_MGJyQbvOySkw1xLntZdTHJQ@mail.gmail.com>
 <CANw+MznhF789gOiaxCQaYKK7ODUBqva_rtJv5qsE3w06=rNrhQ@mail.gmail.com>
Message-ID: <CAB+QZVB7rnRaf-AmQ3o8Eoa6gDVTC9F_DYNnyzOmJFnBa_OgtA@mail.gmail.com>

In this context, this:

    #include <cstddef>

Doesn't refer to libstdc++, it refers to this:

   /usr/arm-none-eabi/include/c++/4.9.3/cstddef

(rather than libstd++ etc)


Looking at the PPA info:

    https://launchpad.net/~terry.guo/+archive/ubuntu/gcc-arm-embedded

That does list packages for 15.10 -- ie  "wily"

The build status looks fine too from here:


https://launchpad.net/~terry.guo/+archive/ubuntu/gcc-arm-embedded/+packages

So that looks like the package exists.

Couple of possibilities:

- When you upgrade from one version of ubuntu to the next, some sources are
disabled, and need to be manually re-enabled. That might be the case here.
- Secondly, it might be that it's installed, but yotta can't find it. If
the above file exists on your system, that might be the cause.

My guess therefore is it might be the former PPA. (easiest option to
overlook and would just need re-enabling) The less nice option is that it's
installed and yotta can't find it. The file above is the one you're looking
for though.

Looking at the other PPA (which seems less relevant, but that could be
wrong)

    https://launchpad.net/~pmiller-opensource/+archive/ubuntu/ppa

And also in:

    https://launchpad.net/~pmiller-opensource/+archive/ubuntu/ppa/+packages

I note that none of the packages there mention "wily" -- suggesting that
pmiller hasn't updated his PPA for wily/15.10 as yet. As to how much of a
problem that would be I'm not sure, but I think it's separate from not
being able to find cstddef, and one you'd hit after fixing the cstddef one.

All that said, it might also be worth checking that the output of this:

apt-cache showpkg gcc-arm-none-eabi

Shows useful stuff, rather than something like:

N: Unable to locate package gcc-arm-none-eabi

Hopefully some of that might be of use...


Michael.


On 24 November 2015 at 15:38, Damien George <damien.p.george at gmail.com>
wrote:

> Larry, did you find a solution to this?  We have another report of the
> same problem: https://github.com/bbcmicrobit/micropython/issues/109
>
> On Thu, Nov 12, 2015 at 9:24 AM, Larry Hastings <larry at hastings.org>
> wrote:
> > I wrote the instructions on adding the PPAs ;-)
> >
> > Yes, I ran the stuff in the README.  I actually open the README and
> > copy-and-paste it into my shell.  And I added the PPAs in the list.  But
> it
> > appears there's some other thing missing--either that, or, the PPAs
> aren't
> > entirely ready for the recently-shipped Ubuntu 15.10.
> >
> >
> > On Thu, Nov 12, 2015 at 12:27 AM, Nicholas H.Tollervey <ntoll at ntoll.org>
> > wrote:
> >>
> >> Larry,
> >>
> >> Apologies if this sounds funny, but can you confirm that you've followed
> >> all the instructions in the README file? I notice there are a couple of
> >> PPAs that need adding and you also need to tell yotta to target
> >> bbc-microbit-classic-gcc-nosd.
> >>
> >> I'm only asking because, on far too many occasions, I have missed
> >> something in the README. Consider this a pre-flight check to ensure that
> >> we're all on the same page that, "yes, I did follow all the bloody
> >> instructions in the README Nicholas, thankyouverymuch" and thus
> >> something more fundamental has broken. ;-)
> >>
> >> I'll spin up a virtualized Ubuntu and have a go myself over lunch (I've
> >> just arrived at "real work" [tm] to an inbox full of "ugh").
> >>
> >> All the best,
> >>
> >> Nicholas.
> >>
> >> On 12/11/15 03:57, Larry Hastings wrote:
> >> >
> >> > I /should/ be current with microbit / micropython / yotta modules.
> But
> >> > I installed Ubuntu 15.10, and it turns out my "prebuild.sh" is
> >> > insufficient to get all the dependencies.  When I start a build I get
> >> > this error right away:
> >> >
> >> >     In file included from
> >> >
> >> >
> /home/larry/src/microbit/microbit-micropython/yotta_modules/mbed-classic/api/Timer.h:19:0,
> >> >                      from
> >> >
> >> >
> /home/larry/src/microbit/microbit-micropython/yotta_modules/mbed-classic/common/Timer.cpp:16:
> >> >
> >> >
> /home/larry/src/microbit/microbit-micropython/yotta_modules/mbed-classic/api/platform.h:25:19:
> >> >     fatal error: cstddef: No such file or directory
> >> >      #include <cstddef>
> >> >                        ^
> >> >
> >> >
> >> > This sure looks like libstdc++ to me.  I installed every
> likely-looking
> >> > libstdc++ library I could find in the package manager.  No joy.
> >> >
> >> > Anybody go from 0 to compiling on Ubuntu recently?
> >> >
> >> > Anxiously yours,
> >> >
> >> >
> >> > //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: <http://mail.python.org/pipermail/microbit/attachments/20151124/4ebba6f7/attachment.html>

From damien.p.george at gmail.com  Tue Nov 24 11:45:42 2015
From: damien.p.george at gmail.com (Damien George)
Date: Tue, 24 Nov 2015 16:45:42 +0000
Subject: [Microbit-Python] Halp! Reinstalled OS and can't build firmware
 anymore.
In-Reply-To: <CAB+QZVB7rnRaf-AmQ3o8Eoa6gDVTC9F_DYNnyzOmJFnBa_OgtA@mail.gmail.com>
References: <56440E0F.7000308@hastings.org> <56444D79.1000006@ntoll.org>
 <CAOBd=7=HhmM-TS++A5KfS=Frw9_MGJyQbvOySkw1xLntZdTHJQ@mail.gmail.com>
 <CANw+MznhF789gOiaxCQaYKK7ODUBqva_rtJv5qsE3w06=rNrhQ@mail.gmail.com>
 <CAB+QZVB7rnRaf-AmQ3o8Eoa6gDVTC9F_DYNnyzOmJFnBa_OgtA@mail.gmail.com>
Message-ID: <CANw+MzkiYdcti_ifetraQS3GMKzm2_Jzsdbx_TVcYT3mY3K8fA@mail.gmail.com>

See here for a fix:
https://github.com/bbcmicrobit/micropython/issues/109#issuecomment-159331459

On Tue, Nov 24, 2015 at 4:25 PM, Michael <sparks.m at gmail.com> wrote:
> In this context, this:
>
>     #include <cstddef>
>
> Doesn't refer to libstdc++, it refers to this:
>
>    /usr/arm-none-eabi/include/c++/4.9.3/cstddef
>
> (rather than libstd++ etc)
>
>
> Looking at the PPA info:
>
>     https://launchpad.net/~terry.guo/+archive/ubuntu/gcc-arm-embedded
>
> That does list packages for 15.10 -- ie  "wily"
>
> The build status looks fine too from here:
>
>
> https://launchpad.net/~terry.guo/+archive/ubuntu/gcc-arm-embedded/+packages
>
> So that looks like the package exists.
>
> Couple of possibilities:
>
> - When you upgrade from one version of ubuntu to the next, some sources are
> disabled, and need to be manually re-enabled. That might be the case here.
> - Secondly, it might be that it's installed, but yotta can't find it. If the
> above file exists on your system, that might be the cause.
>
> My guess therefore is it might be the former PPA. (easiest option to
> overlook and would just need re-enabling) The less nice option is that it's
> installed and yotta can't find it. The file above is the one you're looking
> for though.
>
> Looking at the other PPA (which seems less relevant, but that could be
> wrong)
>
>     https://launchpad.net/~pmiller-opensource/+archive/ubuntu/ppa
>
> And also in:
>
>     https://launchpad.net/~pmiller-opensource/+archive/ubuntu/ppa/+packages
>
> I note that none of the packages there mention "wily" -- suggesting that
> pmiller hasn't updated his PPA for wily/15.10 as yet. As to how much of a
> problem that would be I'm not sure, but I think it's separate from not being
> able to find cstddef, and one you'd hit after fixing the cstddef one.
>
> All that said, it might also be worth checking that the output of this:
>
> apt-cache showpkg gcc-arm-none-eabi
>
> Shows useful stuff, rather than something like:
>
> N: Unable to locate package gcc-arm-none-eabi
>
> Hopefully some of that might be of use...
>
>
> Michael.
>
>
> On 24 November 2015 at 15:38, Damien George <damien.p.george at gmail.com>
> wrote:
>>
>> Larry, did you find a solution to this?  We have another report of the
>> same problem: https://github.com/bbcmicrobit/micropython/issues/109
>>
>> On Thu, Nov 12, 2015 at 9:24 AM, Larry Hastings <larry at hastings.org>
>> wrote:
>> > I wrote the instructions on adding the PPAs ;-)
>> >
>> > Yes, I ran the stuff in the README.  I actually open the README and
>> > copy-and-paste it into my shell.  And I added the PPAs in the list.  But
>> > it
>> > appears there's some other thing missing--either that, or, the PPAs
>> > aren't
>> > entirely ready for the recently-shipped Ubuntu 15.10.
>> >
>> >
>> > On Thu, Nov 12, 2015 at 12:27 AM, Nicholas H.Tollervey <ntoll at ntoll.org>
>> > wrote:
>> >>
>> >> Larry,
>> >>
>> >> Apologies if this sounds funny, but can you confirm that you've
>> >> followed
>> >> all the instructions in the README file? I notice there are a couple of
>> >> PPAs that need adding and you also need to tell yotta to target
>> >> bbc-microbit-classic-gcc-nosd.
>> >>
>> >> I'm only asking because, on far too many occasions, I have missed
>> >> something in the README. Consider this a pre-flight check to ensure
>> >> that
>> >> we're all on the same page that, "yes, I did follow all the bloody
>> >> instructions in the README Nicholas, thankyouverymuch" and thus
>> >> something more fundamental has broken. ;-)
>> >>
>> >> I'll spin up a virtualized Ubuntu and have a go myself over lunch (I've
>> >> just arrived at "real work" [tm] to an inbox full of "ugh").
>> >>
>> >> All the best,
>> >>
>> >> Nicholas.
>> >>
>> >> On 12/11/15 03:57, Larry Hastings wrote:
>> >> >
>> >> > I /should/ be current with microbit / micropython / yotta modules.
>> >> > But
>> >> > I installed Ubuntu 15.10, and it turns out my "prebuild.sh" is
>> >> > insufficient to get all the dependencies.  When I start a build I get
>> >> > this error right away:
>> >> >
>> >> >     In file included from
>> >> >
>> >> >
>> >> > /home/larry/src/microbit/microbit-micropython/yotta_modules/mbed-classic/api/Timer.h:19:0,
>> >> >                      from
>> >> >
>> >> >
>> >> > /home/larry/src/microbit/microbit-micropython/yotta_modules/mbed-classic/common/Timer.cpp:16:
>> >> >
>> >> >
>> >> > /home/larry/src/microbit/microbit-micropython/yotta_modules/mbed-classic/api/platform.h:25:19:
>> >> >     fatal error: cstddef: No such file or directory
>> >> >      #include <cstddef>
>> >> >                        ^
>> >> >
>> >> >
>> >> > This sure looks like libstdc++ to me.  I installed every
>> >> > likely-looking
>> >> > libstdc++ library I could find in the package manager.  No joy.
>> >> >
>> >> > Anybody go from 0 to compiling on Ubuntu recently?
>> >> >
>> >> > Anxiously yours,
>> >> >
>> >> >
>> >> > //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 microbit at sheep.art.pl  Tue Nov 24 11:51:35 2015
From: microbit at sheep.art.pl (Radomir Dopieralski)
Date: Tue, 24 Nov 2015 17:51:35 +0100
Subject: [Microbit-Python] Halp! Reinstalled OS and can't build firmware
 anymore.
In-Reply-To: <CAB+QZVB7rnRaf-AmQ3o8Eoa6gDVTC9F_DYNnyzOmJFnBa_OgtA@mail.gmail.com>
References: <56440E0F.7000308@hastings.org> <56444D79.1000006@ntoll.org>
 <CAOBd=7=HhmM-TS++A5KfS=Frw9_MGJyQbvOySkw1xLntZdTHJQ@mail.gmail.com>
 <CANw+MznhF789gOiaxCQaYKK7ODUBqva_rtJv5qsE3w06=rNrhQ@mail.gmail.com>
 <CAB+QZVB7rnRaf-AmQ3o8Eoa6gDVTC9F_DYNnyzOmJFnBa_OgtA@mail.gmail.com>
Message-ID: <20151124175135.72dab7a8@ghostwheel>

Thank you!

Thanks to your hints, I fixed it and got micropython to compile.

I fixed it with this command:

sudo ln
-s /usr/lib/arm-none-eabi/include/c++/4.9 /usr/lib/arm-none-eabi/include/c++/4.9.3

Cheers!


On Tue, 24 Nov 2015 16:25:56 +0000
Michael <sparks.m at gmail.com> wrote:

> In this context, this:
> 
>     #include <cstddef>
> 
> Doesn't refer to libstdc++, it refers to this:
> 
>    /usr/arm-none-eabi/include/c++/4.9.3/cstddef
> 
> (rather than libstd++ etc)
> 
> 
> Looking at the PPA info:
> 
>     https://launchpad.net/~terry.guo/+archive/ubuntu/gcc-arm-embedded
> 
> That does list packages for 15.10 -- ie  "wily"
> 
> The build status looks fine too from here:
> 
> 
> https://launchpad.net/~terry.guo/+archive/ubuntu/gcc-arm-embedded/+packages
> 
> So that looks like the package exists.
> 
> Couple of possibilities:
> 
> - When you upgrade from one version of ubuntu to the next, some
> sources are disabled, and need to be manually re-enabled. That might
> be the case here.
> - Secondly, it might be that it's installed, but yotta can't find it.
> If the above file exists on your system, that might be the cause.
> 
> My guess therefore is it might be the former PPA. (easiest option to
> overlook and would just need re-enabling) The less nice option is
> that it's installed and yotta can't find it. The file above is the
> one you're looking for though.
> 
> Looking at the other PPA (which seems less relevant, but that could be
> wrong)
> 
>     https://launchpad.net/~pmiller-opensource/+archive/ubuntu/ppa
> 
> And also in:
> 
>     https://launchpad.net/~pmiller-opensource/+archive/ubuntu/ppa/+packages
> 
> I note that none of the packages there mention "wily" -- suggesting
> that pmiller hasn't updated his PPA for wily/15.10 as yet. As to how
> much of a problem that would be I'm not sure, but I think it's
> separate from not being able to find cstddef, and one you'd hit after
> fixing the cstddef one.
> 
> All that said, it might also be worth checking that the output of
> this:
> 
> apt-cache showpkg gcc-arm-none-eabi
> 
> Shows useful stuff, rather than something like:
> 
> N: Unable to locate package gcc-arm-none-eabi
> 
> Hopefully some of that might be of use...
> 
> 
> Michael.
> 
> 
> On 24 November 2015 at 15:38, Damien George
> <damien.p.george at gmail.com> wrote:
> 
> > Larry, did you find a solution to this?  We have another report of
> > the same problem:
> > https://github.com/bbcmicrobit/micropython/issues/109
> >
> > On Thu, Nov 12, 2015 at 9:24 AM, Larry Hastings <larry at hastings.org>
> > wrote:
> > > I wrote the instructions on adding the PPAs ;-)
> > >
> > > Yes, I ran the stuff in the README.  I actually open the README
> > > and copy-and-paste it into my shell.  And I added the PPAs in the
> > > list.  But
> > it
> > > appears there's some other thing missing--either that, or, the
> > > PPAs
> > aren't
> > > entirely ready for the recently-shipped Ubuntu 15.10.
> > >
> > >
> > > On Thu, Nov 12, 2015 at 12:27 AM, Nicholas H.Tollervey
> > > <ntoll at ntoll.org> wrote:
> > >>
> > >> Larry,
> > >>
> > >> Apologies if this sounds funny, but can you confirm that you've
> > >> followed all the instructions in the README file? I notice there
> > >> are a couple of PPAs that need adding and you also need to tell
> > >> yotta to target bbc-microbit-classic-gcc-nosd.
> > >>
> > >> I'm only asking because, on far too many occasions, I have missed
> > >> something in the README. Consider this a pre-flight check to
> > >> ensure that we're all on the same page that, "yes, I did follow
> > >> all the bloody instructions in the README Nicholas,
> > >> thankyouverymuch" and thus something more fundamental has
> > >> broken. ;-)
> > >>
> > >> I'll spin up a virtualized Ubuntu and have a go myself over
> > >> lunch (I've just arrived at "real work" [tm] to an inbox full of
> > >> "ugh").
> > >>
> > >> All the best,
> > >>
> > >> Nicholas.
> > >>
> > >> On 12/11/15 03:57, Larry Hastings wrote:
> > >> >
> > >> > I /should/ be current with microbit / micropython / yotta
> > >> > modules.
> > But
> > >> > I installed Ubuntu 15.10, and it turns out my "prebuild.sh" is
> > >> > insufficient to get all the dependencies.  When I start a
> > >> > build I get this error right away:
> > >> >
> > >> >     In file included from
> > >> >
> > >> >
> > /home/larry/src/microbit/microbit-micropython/yotta_modules/mbed-classic/api/Timer.h:19:0,
> > >> >                      from
> > >> >
> > >> >
> > /home/larry/src/microbit/microbit-micropython/yotta_modules/mbed-classic/common/Timer.cpp:16:
> > >> >
> > >> >
> > /home/larry/src/microbit/microbit-micropython/yotta_modules/mbed-classic/api/platform.h:25:19:
> > >> >     fatal error: cstddef: No such file or directory
> > >> >      #include <cstddef>
> > >> >                        ^
> > >> >
> > >> >
> > >> > This sure looks like libstdc++ to me.  I installed every
> > likely-looking
> > >> > libstdc++ library I could find in the package manager.  No joy.
> > >> >
> > >> > Anybody go from 0 to compiling on Ubuntu recently?
> > >> >
> > >> > Anxiously yours,
> > >> >
> > >> >
> > >> > //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
> >



-- 
Radomir Dopieralski

-- 
Radomir Dopieralski

From sparks.m at gmail.com  Tue Nov 24 11:53:58 2015
From: sparks.m at gmail.com (Michael)
Date: Tue, 24 Nov 2015 16:53:58 +0000
Subject: [Microbit-Python] Halp! Reinstalled OS and can't build firmware
 anymore.
In-Reply-To: <20151124175135.72dab7a8@ghostwheel>
References: <56440E0F.7000308@hastings.org> <56444D79.1000006@ntoll.org>
 <CAOBd=7=HhmM-TS++A5KfS=Frw9_MGJyQbvOySkw1xLntZdTHJQ@mail.gmail.com>
 <CANw+MznhF789gOiaxCQaYKK7ODUBqva_rtJv5qsE3w06=rNrhQ@mail.gmail.com>
 <CAB+QZVB7rnRaf-AmQ3o8Eoa6gDVTC9F_DYNnyzOmJFnBa_OgtA@mail.gmail.com>
 <20151124175135.72dab7a8@ghostwheel>
Message-ID: <CAB+QZVBSiQxQPJv_hmSxOTXEi2EaidYtoY20P_cDj5=03GMZ1Q@mail.gmail.com>

np. I figured a positive result might be useful :)


Michael.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151124/7086d8cc/attachment.html>

From larry at hastings.org  Wed Nov 25 08:20:46 2015
From: larry at hastings.org (Larry Hastings)
Date: Wed, 25 Nov 2015 05:20:46 -0800
Subject: [Microbit-Python] Halp! Reinstalled OS and can't build firmware
 anymore.
In-Reply-To: <CANw+MznhF789gOiaxCQaYKK7ODUBqva_rtJv5qsE3w06=rNrhQ@mail.gmail.com>
References: <56440E0F.7000308@hastings.org> <56444D79.1000006@ntoll.org>
 <CAOBd=7=HhmM-TS++A5KfS=Frw9_MGJyQbvOySkw1xLntZdTHJQ@mail.gmail.com>
 <CANw+MznhF789gOiaxCQaYKK7ODUBqva_rtJv5qsE3w06=rNrhQ@mail.gmail.com>
Message-ID: <5655B5AE.2030904@hastings.org>



On 11/24/2015 07:38 AM, Damien George wrote:
> Larry, did you find a solution to this?  We have another report of the
> same problem: https://github.com/bbcmicrobit/micropython/issues/109

I finally figured it out a week ago.  The problem is that Ubuntu also 
ships a gcc-arm-none-eabi, and they've marked their current release as 
version "15:4.9.3+svn227297-1".  Debian's apt sees the "15:" at the 
front and says "oh goody, that's the latest version, much more recent 
than "4.9.3.2015q3-1wily1".  So it picks the default one instead of the 
one from the Terry Guo PPA.

To fix:

 1. Run Synaptic.
 2. Search for "gcc-arm-none-eabi".
 3. If the package is installed, uninstall the package, letting it
    uninstall whatever else it says it has to.
 4. While still having the "gcc-arm-none-eabi" package selected, open
    the menus and select "Package | Force Version...".
 5. In the "Force Version" pop-up dialog box, choose the Terry Guo
    version, currently "4.9.3.2015q3-1wily1", and install.
 6. Finally, while still having the "gcc-arm-none-eabi" package
    selected, open the menus and select "Package | Lock Version".


Having done that, I can now build the micro:bit firmware on my laptop 
using the 64-bit workstation release of Ubuntu 15.10.


Cheers,


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151125/2a00a6c4/attachment.html>

From martin at ohanlonweb.com  Wed Nov 25 08:50:03 2015
From: martin at ohanlonweb.com (Martin O'Hanlon)
Date: Wed, 25 Nov 2015 13:50:03 +0000
Subject: [Microbit-Python] Micropython random numbers
Message-ID: <CAD64x+a8mWzv4uYeARa9TPeL8qCUZi8uyt6mkORWUqQUNKRV2A@mail.gmail.com>

A microbit is on its way to me...  I've got an idea but it would be really
useful to be able to create a random number, the equivalent of
random.randint(0,5).

>From a quick look through Micropython's docs I dont think a random function
is available.

Has anyone got any inspired thoughts about how I might create a 'pseudo
random number' using micropython.

Mart


-- 

Blog - www.stuffaboutcode.com

Twitter - @martinohanlon
<http://twitter.com/intent/user?screen_name=martinohanlon>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151125/f749a436/attachment.html>

From sparks.m at gmail.com  Wed Nov 25 09:10:05 2015
From: sparks.m at gmail.com (Michael)
Date: Wed, 25 Nov 2015 14:10:05 +0000
Subject: [Microbit-Python] Micropython random numbers
In-Reply-To: <CAD64x+a8mWzv4uYeARa9TPeL8qCUZi8uyt6mkORWUqQUNKRV2A@mail.gmail.com>
References: <CAD64x+a8mWzv4uYeARa9TPeL8qCUZi8uyt6mkORWUqQUNKRV2A@mail.gmail.com>
Message-ID: <CAB+QZVCK_J-b5T7eUXN0_6BGSBy170aOyPLFO7yrDJoEXtey=w@mail.gmail.com>

Check one of the sensors to see which one is changing lots, and take some
digits from that?

(If you're shaking it and take values from the accelerometer with pauses
between from the compass you'll probably get values as random as shaking a
dice :-) )


Michael.

On 25 November 2015 at 13:50, Martin O'Hanlon <martin at ohanlonweb.com> wrote:

> A microbit is on its way to me...  I've got an idea but it would be really
> useful to be able to create a random number, the equivalent of
> random.randint(0,5).
>
> From a quick look through Micropython's docs I dont think a random
> function is available.
>
> Has anyone got any inspired thoughts about how I might create a 'pseudo
> random number' using micropython.
>
> Mart
>
>
> --
>
> Blog - www.stuffaboutcode.com
>
> Twitter - @martinohanlon <http://twitter.com/intent/user?screen_name=martinohanlon>
>
>
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151125/26f2347e/attachment.html>

From damien.p.george at gmail.com  Wed Nov 25 09:15:14 2015
From: damien.p.george at gmail.com (Damien George)
Date: Wed, 25 Nov 2015 14:15:14 +0000
Subject: [Microbit-Python] Micropython random numbers
In-Reply-To: <CAB+QZVCK_J-b5T7eUXN0_6BGSBy170aOyPLFO7yrDJoEXtey=w@mail.gmail.com>
References: <CAD64x+a8mWzv4uYeARa9TPeL8qCUZi8uyt6mkORWUqQUNKRV2A@mail.gmail.com>
 <CAB+QZVCK_J-b5T7eUXN0_6BGSBy170aOyPLFO7yrDJoEXtey=w@mail.gmail.com>
Message-ID: <CANw+Mzm1hR-a1iGYjaZYL7fFg_RmKBYgaCiwu=HndEFYi_Hb0g@mail.gmail.com>

There is a microbit.random() function.

On Wed, Nov 25, 2015 at 2:10 PM, Michael <sparks.m at gmail.com> wrote:
> Check one of the sensors to see which one is changing lots, and take some
> digits from that?
>
> (If you're shaking it and take values from the accelerometer with pauses
> between from the compass you'll probably get values as random as shaking a
> dice :-) )
>
>
> Michael.
>
> On 25 November 2015 at 13:50, Martin O'Hanlon <martin at ohanlonweb.com> wrote:
>>
>> A microbit is on its way to me...  I've got an idea but it would be really
>> useful to be able to create a random number, the equivalent of
>> random.randint(0,5).
>>
>> From a quick look through Micropython's docs I dont think a random
>> function is available.
>>
>> Has anyone got any inspired thoughts about how I might create a 'pseudo
>> random number' using micropython.
>>
>> Mart
>>
>>
>> --
>>
>> Blog - www.stuffaboutcode.com
>>
>> Twitter - @martinohanlon
>>
>>
>> _______________________________________________
>> 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  Wed Nov 25 09:40:35 2015
From: david at thinkingbinaries.com (David Whale)
Date: Wed, 25 Nov 2015 14:40:35 +0000
Subject: [Microbit-Python] Micropython random numbers
In-Reply-To: <CANw+Mzm1hR-a1iGYjaZYL7fFg_RmKBYgaCiwu=HndEFYi_Hb0g@mail.gmail.com>
References: <CAD64x+a8mWzv4uYeARa9TPeL8qCUZi8uyt6mkORWUqQUNKRV2A@mail.gmail.com>
 <CAB+QZVCK_J-b5T7eUXN0_6BGSBy170aOyPLFO7yrDJoEXtey=w@mail.gmail.com>
 <CANw+Mzm1hR-a1iGYjaZYL7fFg_RmKBYgaCiwu=HndEFYi_Hb0g@mail.gmail.com>
Message-ID: <CABeH_SsrUugNO-=g-thgig4XNzVe8KVA-f9ADai2Sy0ZEsu1Gg@mail.gmail.com>

There is indeed microbit.random()


Note that there is some evidence of a bug in the runtime random function at
the moment when I use it from Touch Develop, it's not very random, because
it is not seeded (I think).

My Dr Who Daleks game always shoots me on the first two goes, because the
random number sequence is, I think, the same every time.

It would be good if the first time random() was called it seeded it with
the running_time variable so that it was automatically randomized.

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" <http://amzn.to/ZGfxZG>
- lets get kids coding!


On 25 November 2015 at 14:15, Damien George <damien.p.george at gmail.com>
wrote:

> There is a microbit.random() function.
>
> On Wed, Nov 25, 2015 at 2:10 PM, Michael <sparks.m at gmail.com> wrote:
> > Check one of the sensors to see which one is changing lots, and take some
> > digits from that?
> >
> > (If you're shaking it and take values from the accelerometer with pauses
> > between from the compass you'll probably get values as random as shaking
> a
> > dice :-) )
> >
> >
> > Michael.
> >
> > On 25 November 2015 at 13:50, Martin O'Hanlon <martin at ohanlonweb.com>
> wrote:
> >>
> >> A microbit is on its way to me...  I've got an idea but it would be
> really
> >> useful to be able to create a random number, the equivalent of
> >> random.randint(0,5).
> >>
> >> From a quick look through Micropython's docs I dont think a random
> >> function is available.
> >>
> >> Has anyone got any inspired thoughts about how I might create a 'pseudo
> >> random number' using micropython.
> >>
> >> Mart
> >>
> >>
> >> --
> >>
> >> Blog - www.stuffaboutcode.com
> >>
> >> Twitter - @martinohanlon
> >>
> >>
> >> _______________________________________________
> >> 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: <http://mail.python.org/pipermail/microbit/attachments/20151125/68889612/attachment-0001.html>

From C.J.Sangwin at ed.ac.uk  Wed Nov 25 09:14:35 2015
From: C.J.Sangwin at ed.ac.uk (SANGWIN Chris)
Date: Wed, 25 Nov 2015 14:14:35 +0000
Subject: [Microbit-Python] Micropython random numbers
In-Reply-To: <CAD64x+a8mWzv4uYeARa9TPeL8qCUZi8uyt6mkORWUqQUNKRV2A@mail.gmail.com>
References: <CAD64x+a8mWzv4uYeARa9TPeL8qCUZi8uyt6mkORWUqQUNKRV2A@mail.gmail.com>
Message-ID: <AMXPR05MB12067A179550BE321363BC885050@AMXPR05MB120.eurprd05.prod.outlook.com>





From: Microbit [mailto:microbit-bounces+c.j.sangwin=ed.ac.uk at python.org] On Behalf Of Martin O'Hanlon
Sent: 25 November 2015 13:50
To: microbit at python.org
Subject: [Microbit-Python] Micropython random numbers

A microbit is on its way to me...  I've got an idea but it would be really useful to be able to create a random number, the equivalent of random.randint(0,5).

From a quick look through Micropython's docs I dont think a random function is available.

Has anyone got any inspired thoughts about how I might create a 'pseudo random number' using micropython.

Mart


--

Blog - www.stuffaboutcode.com<http://www.stuffaboutcode.com>

Twitter - @martinohanlon<http://twitter.com/intent/user?screen_name=martinohanlon>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151125/93b92309/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://mail.python.org/pipermail/microbit/attachments/20151125/93b92309/attachment.ksh>

From mark at hotpy.org  Wed Nov 25 15:25:03 2015
From: mark at hotpy.org (Mark Shannon)
Date: Wed, 25 Nov 2015 20:25:03 +0000
Subject: [Microbit-Python] Micropython random numbers
In-Reply-To: <CABeH_SsrUugNO-=g-thgig4XNzVe8KVA-f9ADai2Sy0ZEsu1Gg@mail.gmail.com>
References: <CAD64x+a8mWzv4uYeARa9TPeL8qCUZi8uyt6mkORWUqQUNKRV2A@mail.gmail.com>
 <CAB+QZVCK_J-b5T7eUXN0_6BGSBy170aOyPLFO7yrDJoEXtey=w@mail.gmail.com>
 <CANw+Mzm1hR-a1iGYjaZYL7fFg_RmKBYgaCiwu=HndEFYi_Hb0g@mail.gmail.com>
 <CABeH_SsrUugNO-=g-thgig4XNzVe8KVA-f9ADai2Sy0ZEsu1Gg@mail.gmail.com>
Message-ID: <5656191F.6070002@hotpy.org>



On 25/11/15 14:40, David Whale wrote:
> There is indeed microbit.random()
>
>
> Note that there is some evidence of a bug in the runtime random function
> at the moment when I use it from Touch Develop, it's not very random,
> because it is not seeded (I think).
>
> My Dr Who Daleks game always shoots me on the first two goes, because
> the random number sequence is, I think, the same every time.
>
> It would be good if the first time random() was called it seeded it with
> the running_time variable so that it was automatically randomized.
Except that running_time is initialized to 0 at start up, so you will 
still predictable values.

I would suggest getting seed bits from the accelerometer.
 >>> a.get_x() ^ a.get_y() ^ a.get_z()
should do the job.

Cheers,
Mark.

>
> David.
>
> ___________________________________________________________
> David Whale, B.Sc (Hons), MIET
> *Software Engineer and IET Schools Liaison Officer, Essex*
>
> email: dwhale at theiet.org <mailto:dwhale at theiet.org>
> twitter: @whaleygeek
> blog: blog.whaleygeek.co.uk <http://blog.whaleygeek.co.uk>
>
> Co-author of the new book "Adventures in Minecraft"
> <http://amzn.to/ZGfxZG> - lets get kids coding!
>
>
> On 25 November 2015 at 14:15, Damien George <damien.p.george at gmail.com
> <mailto:damien.p.george at gmail.com>> wrote:
>
>     There is a microbit.random() function.
>
>     On Wed, Nov 25, 2015 at 2:10 PM, Michael <sparks.m at gmail.com
>     <mailto:sparks.m at gmail.com>> wrote:
>      > Check one of the sensors to see which one is changing lots, and
>     take some
>      > digits from that?
>      >
>      > (If you're shaking it and take values from the accelerometer with
>     pauses
>      > between from the compass you'll probably get values as random as
>     shaking a
>      > dice :-) )
>      >
>      >
>      > Michael.
>      >
>      > On 25 November 2015 at 13:50, Martin O'Hanlon
>     <martin at ohanlonweb.com <mailto:martin at ohanlonweb.com>> wrote:
>      >>
>      >> A microbit is on its way to me...  I've got an idea but it would
>     be really
>      >> useful to be able to create a random number, the equivalent of
>      >> random.randint(0,5).
>      >>
>      >> From a quick look through Micropython's docs I dont think a random
>      >> function is available.
>      >>
>      >> Has anyone got any inspired thoughts about how I might create a
>     'pseudo
>      >> random number' using micropython.
>      >>
>      >> Mart
>      >>
>      >>
>      >> --
>      >>
>      >> Blog - www.stuffaboutcode.com <http://www.stuffaboutcode.com>
>      >>
>      >> Twitter - @martinohanlon
>      >>
>      >>
>      >> _______________________________________________
>      >> Microbit mailing list
>      >> Microbit at python.org <mailto:Microbit at python.org>
>      >> https://mail.python.org/mailman/listinfo/microbit
>      >>
>      >
>      >
>      > _______________________________________________
>      > Microbit mailing list
>      > Microbit at python.org <mailto:Microbit at python.org>
>      > https://mail.python.org/mailman/listinfo/microbit
>      >
>     _______________________________________________
>     Microbit mailing list
>     Microbit at python.org <mailto:Microbit at python.org>
>     https://mail.python.org/mailman/listinfo/microbit
>
>
>
>
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit
>

From david at thinkingbinaries.com  Wed Nov 25 15:40:19 2015
From: david at thinkingbinaries.com (David Whale)
Date: Wed, 25 Nov 2015 20:40:19 +0000
Subject: [Microbit-Python] Micropython random numbers
In-Reply-To: <5656191F.6070002@hotpy.org>
References: <CAD64x+a8mWzv4uYeARa9TPeL8qCUZi8uyt6mkORWUqQUNKRV2A@mail.gmail.com>
 <CAB+QZVCK_J-b5T7eUXN0_6BGSBy170aOyPLFO7yrDJoEXtey=w@mail.gmail.com>
 <CANw+Mzm1hR-a1iGYjaZYL7fFg_RmKBYgaCiwu=HndEFYi_Hb0g@mail.gmail.com>
 <CABeH_SsrUugNO-=g-thgig4XNzVe8KVA-f9ADai2Sy0ZEsu1Gg@mail.gmail.com>
 <5656191F.6070002@hotpy.org>
Message-ID: <CABeH_St+GQR07VYDjBc+a01vbp6qzwDLTuSSR+aiSq-ApmvPqQ@mail.gmail.com>

Most games start from a button press, that has an indeterminate user
initiated start time.

But the noise bits from the accelerometer are just as good.

This is a DAL issue though.

D.

Sent from my new HTC
On Nov 25, 2015 8:25 PM, "Mark Shannon" <mark at hotpy.org> wrote:

>
>
> On 25/11/15 14:40, David Whale wrote:
>
>> There is indeed microbit.random()
>>
>>
>> Note that there is some evidence of a bug in the runtime random function
>> at the moment when I use it from Touch Develop, it's not very random,
>> because it is not seeded (I think).
>>
>> My Dr Who Daleks game always shoots me on the first two goes, because
>> the random number sequence is, I think, the same every time.
>>
>> It would be good if the first time random() was called it seeded it with
>> the running_time variable so that it was automatically randomized.
>>
> Except that running_time is initialized to 0 at start up, so you will
> still predictable values.
>
> I would suggest getting seed bits from the accelerometer.
> >>> a.get_x() ^ a.get_y() ^ a.get_z()
> should do the job.
>
> Cheers,
> Mark.
>
>
>> David.
>>
>> ___________________________________________________________
>> David Whale, B.Sc (Hons), MIET
>> *Software Engineer and IET Schools Liaison Officer, Essex*
>>
>> email: dwhale at theiet.org <mailto:dwhale at theiet.org>
>> twitter: @whaleygeek
>> blog: blog.whaleygeek.co.uk <http://blog.whaleygeek.co.uk>
>>
>> Co-author of the new book "Adventures in Minecraft"
>> <http://amzn.to/ZGfxZG> - lets get kids coding!
>>
>>
>> On 25 November 2015 at 14:15, Damien George <damien.p.george at gmail.com
>> <mailto:damien.p.george at gmail.com>> wrote:
>>
>>     There is a microbit.random() function.
>>
>>     On Wed, Nov 25, 2015 at 2:10 PM, Michael <sparks.m at gmail.com
>>     <mailto:sparks.m at gmail.com>> wrote:
>>      > Check one of the sensors to see which one is changing lots, and
>>     take some
>>      > digits from that?
>>      >
>>      > (If you're shaking it and take values from the accelerometer with
>>     pauses
>>      > between from the compass you'll probably get values as random as
>>     shaking a
>>      > dice :-) )
>>      >
>>      >
>>      > Michael.
>>      >
>>      > On 25 November 2015 at 13:50, Martin O'Hanlon
>>     <martin at ohanlonweb.com <mailto:martin at ohanlonweb.com>> wrote:
>>      >>
>>      >> A microbit is on its way to me...  I've got an idea but it would
>>     be really
>>      >> useful to be able to create a random number, the equivalent of
>>      >> random.randint(0,5).
>>      >>
>>      >> From a quick look through Micropython's docs I dont think a random
>>      >> function is available.
>>      >>
>>      >> Has anyone got any inspired thoughts about how I might create a
>>     'pseudo
>>      >> random number' using micropython.
>>      >>
>>      >> Mart
>>      >>
>>      >>
>>      >> --
>>      >>
>>      >> Blog - www.stuffaboutcode.com <http://www.stuffaboutcode.com>
>>      >>
>>      >> Twitter - @martinohanlon
>>      >>
>>      >>
>>      >> _______________________________________________
>>      >> Microbit mailing list
>>      >> Microbit at python.org <mailto:Microbit at python.org>
>>      >> https://mail.python.org/mailman/listinfo/microbit
>>      >>
>>      >
>>      >
>>      > _______________________________________________
>>      > Microbit mailing list
>>      > Microbit at python.org <mailto:Microbit at python.org>
>>      > https://mail.python.org/mailman/listinfo/microbit
>>      >
>>     _______________________________________________
>>     Microbit mailing list
>>     Microbit at python.org <mailto:Microbit at python.org>
>>     https://mail.python.org/mailman/listinfo/microbit
>>
>>
>>
>>
>> _______________________________________________
>> Microbit mailing list
>> Microbit at python.org
>> https://mail.python.org/mailman/listinfo/microbit
>>
>> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151125/a2895f60/attachment.html>

From ntoll at ntoll.org  Thu Nov 26 14:19:17 2015
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Thu, 26 Nov 2015 19:19:17 +0000
Subject: [Microbit-Python] Windows
Message-ID: <56575B35.7050506@ntoll.org>

Folks,

I forgot to mention.

I've been giving various workshops since October (about once a week) to
various Python and teacher groups.

Pythonistas take to the device like a duck to water. Teachers, however,
all turn up with Windows laptops and the experience is *very* sub-par.

My little "microrepl" doesn't really work well nor cut the mustard. Can
anyone suggest some other serial emulator for Windows?

Put simply, most of our target users will be on Windows. We need to make
that as joyful an experience as possible. Zero install (static
binaries), as little set-up as possible and clear instructions are
what's needed here.

I've not used Windows since 2008. I wouldn't know where to start. :-/

Thoughts, ideas, offers of help most welcome!

Nicholas.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/microbit/attachments/20151126/f5bdc8c2/attachment.sig>

From ntoll at ntoll.org  Thu Nov 26 14:22:35 2015
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Thu, 26 Nov 2015 19:22:35 +0000
Subject: [Microbit-Python] RESENT - Python Editor
Message-ID: <56575BFB.1090907@ntoll.org>

(Resent since my original email from 10 minutes ago appears to have got
lost). :-(

Hi Folks,

First of all, many apologies for going off the radar recently. Put
simply, I've had to deliver the code editor for TouchDevelop and needed
to hunker down. Happily, it's "finished" pending BBC testing. This will,
of course, result in updates and changes, but I believe I've broken the
camel's back.

Here's a video of the latest version, including all of Steve Hawkes'
wonderful design!

https://www.youtube.com/watch?v=7pq7XUBHOYs

The source code is still supposed to be "hidden".

However, it's hiding in plain view (as Michael Sparks would put it). If
Microsoft can develop their web based programming tools (i.e.
TouchDevelop) in the open, so can the Python Software Foundation.

Ergo, here's the code:

https://github.com/bbcmicrobit/PythonEditor

(There's NOTHING in that repos that reveals anything above and beyond
what has already been published about the device.)

Grace Hopper FTW.

PLEASE PLEASE PLEASE feel free to take a look, try it out and CONTRIBUTE
bug fixes, code and documentation. I will definitely need help in terms
of web development for cross browser testing. I'll also be updating the
stand-alone browser to the same code / tests / design over the weekend:

https://github.com/ntoll/upyed

Also, the "help.html" file could do with some love. I'd like there to be
a very simple tutorial, some videos and example code. All written for
11yo.

If you're wondering why we need a Python presence in the TouchDevelop
platform then the answer is simple: it's the "blessed" platform that the
BBC will be pushing. Our editor is, I guess, a sort of a Trojan horse
pointing a way to Python and the "hacker" (used in the positive sense)
community.

As always, comments, constructive critique and ideas most welcome!

In other news, David Whale has put me in touch with an 11yo girl called
Abbie who has been designing some images for us. I'll try to get those
wrapped up into a PR over the weekend. We've also had our first bug
report from a teacher
(https://github.com/bbcmicrobit/micropython/issues/110) although I see
Radomir and Mark are all over that issue.

Also, Tom and Radomir have been having fun with their micro:bits as part
of the world tour:

http://microworldtour.github.io/

Robots! Water! Videos! Code! Dead micro:bits! Shocking stuff..!

Carol (California) has had hers a few days, Mark (New Zealand) had his
arrive today and Naomi (Chicago) and I are following the package
tracking site as USPS appear to have kidnapped hers (it's in the
Washington DC area at the moment). I've been in touch with a bunch of
Brazilians who'd love to get their hands on one! Please feel free to
suggest others who might want to take part. The more far flung, the
better! Know anyone in the Antarctic?

If *you* have a micro:bit and have something cool to show, please
contribute it via pinging me an email. I'll add an "honourable mentions"
page to the website so you can add things there. Alternatively, create a
pull request into the examples directory.

I'm off to the pub for a well earned drink.

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: <http://mail.python.org/pipermail/microbit/attachments/20151126/0e91bb17/attachment.sig>

From ntoll at ntoll.org  Thu Nov 26 14:15:11 2015
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Thu, 26 Nov 2015 19:15:11 +0000
Subject: [Microbit-Python] Python Editor
Message-ID: <56575A3F.2020503@ntoll.org>

Hi Folks,

First of all, many apologies for going off the radar recently. Put
simply, I've had to deliver the code editor for TouchDevelop and needed
to hunker down. Happily, it's "finished" pending BBC testing. This will,
of course, result in updates and changes, but I believe I've broken the
camel's back.

Here's a video of the latest version, including all of Steve Hawkes'
wonderful design!

https://www.youtube.com/watch?v=7pq7XUBHOYs

The source code is still supposed to be "hidden".

However, it's hiding in plain view (as Michael Sparks would put it). If
Microsoft can develop their web based programming tools (i.e.
TouchDevelop) in the open, so can the Python Software Foundation.

Ergo, here's the code:

https://github.com/bbcmicrobit/PythonEditor

(There's NOTHING in that repos that reveals anything above and beyond
what has already been published about the device.)

Grace Hopper FTW.

PLEASE PLEASE PLEASE feel free to take a look, try it out and CONTRIBUTE
bug fixes, code and documentation. I will definitely need help in terms
of web development for cross browser testing. I'll also be updating the
stand-alone browser to the same code / tests / design over the weekend:

https://github.com/ntoll/upyed

Also, the "help.html" file could do with some love. I'd like there to be
a very simple tutorial, some videos and example code. All written for
11yo. ;-)

If you're wondering why we need a Python presence in the TouchDevelop
platform then the answer is simple: it's the "blessed" platform that the
BBC will be pushing. Our editor is, I guess, a sort of a Trojan horse
pointing a way to Python and the "hacker" (used in the positive sense)
community.

As always, comments, constructive critique and ideas most welcome!

In other news, David Whale has put me in touch with an 11yo girl called
Abbie who has been designing some images for us. I'll try to get those
wrapped up into a PR over the weekend. We've also had our first bug
report from a teacher
(https://github.com/bbcmicrobit/micropython/issues/110) although I see
Radomir and Mark are all over that issue. ;-)

Also, Tom and Radomir have been having fun with their micro:bits as part
of the world tour:

http://microworldtour.github.io/

Robots! Water! Videos! Code! Dead micro:bits! Shocking stuff..!

Carol (California) has had hers a few days, Mark (New Zealand) had his
arrive today and Naomi (Chicago) and I are following the package
tracking site as USPS appear to have kidnapped hers (it's in the
Washington DC area at the moment). I've been in touch with a bunch of
Brazilians who'd love to get their hands on one! Please feel free to
suggest others who might want to take part. The more far flung, the
better! Know anyone in the Antarctic? ;-)

If *you* have a micro:bit and have something cool to show, please
contribute it via pinging me an email. I'll add an "honourable mentions"
page to the website so you can add things there. Alternatively, create a
pull request into the examples directory.

I'm off to the pub for a well earned drink. :-)

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: <http://mail.python.org/pipermail/microbit/attachments/20151126/242629d4/attachment.sig>

From david at thinkingbinaries.com  Thu Nov 26 14:53:02 2015
From: david at thinkingbinaries.com (David Whale)
Date: Thu, 26 Nov 2015 19:53:02 +0000
Subject: [Microbit-Python] Windows
In-Reply-To: <56575B35.7050506@ntoll.org>
References: <56575B35.7050506@ntoll.org>
Message-ID: <CABeH_SsJquqBEg5oARTeUspNjMempqZUDF2nePpQUstWAStHxQ@mail.gmail.com>

The mbed forums refer to TeraTerm or Putty, which is what was on the
microbit.co.uk site the other day (although I can't find it now, so it
looks like it might have been removed).

https://developer.mbed.org/handbook/Terminals

There is a version of Putty called Putty Portable that is pre-built with
everything you need and designed to run as zero-install from a USB memory
stick.

http://download.cnet.com/windows/putty/3260-20_4-6262044-1.html

Putty supports serial ports, terminal emulations etc. You can store
settings in config files that load when you run it.

However, you still on windows have to install the mbed serial port driver,
to get any level of communication with the device. The instructions for
that are here:

https://developer.mbed.org/handbook/Windows-serial-configuration

I've had a reasonable amount of success with Putty Portable.

Presumably you could build a package (with permission from ARM) that has
the mbed serial driver inside the package, so that you don't have to wait
for ages with the spinning symbol while it tries to find it on the internet?


When I worked on chapter 5 of 'Adventures in Minecraft' I had all the same
issues with windows that you are experiencing. The closest I could get was
to write a script (it was actually in python, but could be a static C
application) that followed the following flow:

"remove your device then press ENTER"
(code scans the windows registry for key HARDWARE\DEVICEMAP\SERIALCOMM)

All the nodes of this key identify the COM port numbers currently present.
Keep this list in a variable.

"plug in your device and press ENTER"
(code scans the windows registry for key HARDWARE\DEVICEMAP\SERIALCOMM)


Diff the two lists, anything that has been added is the COM port you just
plugged in. Keep a copy of that locally and use it to connect later.

All the code for this is here, help yourself if any of it is of use:
https://github.com/whaleygeek/anyio/blob/master/anyio/arduino/ports_win32.py

I'm sure it would be possible for someone to build a statically built C
application with a little dialog box that does exactly the same, and then
stores the COM port number in the configuration file used by Putty
Portable. Wrap up the mbed driver inside the same package and a few
instructions, and it might actually be quite slick.

Hope this helps.

David.


___________________________________________________________
David Whale, B.Sc (Hons), MIET
*Software Engineer and IET Schools Liaison Officer, Essex*

email:  dwhale at theiet.org
twitter: @whaleygeek
blog:  blog.whaleygeek.co.uk

Co-author of global bestselling book "Adventures in Minecraft"
<http://amzn.to/ZGfxZG> - lets get kids coding!
Now in English, Spanish, Chinese and Russian.


On 26 November 2015 at 19:19, Nicholas H.Tollervey <ntoll at ntoll.org> wrote:

> Folks,
>
> I forgot to mention.
>
> I've been giving various workshops since October (about once a week) to
> various Python and teacher groups.
>
> Pythonistas take to the device like a duck to water. Teachers, however,
> all turn up with Windows laptops and the experience is *very* sub-par.
>
> My little "microrepl" doesn't really work well nor cut the mustard. Can
> anyone suggest some other serial emulator for Windows?
>
> Put simply, most of our target users will be on Windows. We need to make
> that as joyful an experience as possible. Zero install (static
> binaries), as little set-up as possible and clear instructions are
> what's needed here.
>
> I've not used Windows since 2008. I wouldn't know where to start. :-/
>
> Thoughts, ideas, offers of help most welcome!
>
> Nicholas.
>
>
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151126/0d3c7446/attachment-0001.html>

From dhylands at gmail.com  Thu Nov 26 14:44:47 2015
From: dhylands at gmail.com (Dave Hylands)
Date: Thu, 26 Nov 2015 11:44:47 -0800
Subject: [Microbit-Python] Windows
In-Reply-To: <56575B35.7050506@ntoll.org>
References: <56575B35.7050506@ntoll.org>
Message-ID: <CABi1daEMvSvonDwX2o5Oc7vixrZwU_aQw3kXTvzcOO3vb9=jGQ@mail.gmail.com>

I thought that TeraTerm could be run off a thumbdrive - no installation
required. It isn't a static executable, i.e. it has a bunch of DLLs, but I
thought that was one of their claims to fame - no registry required.

I've written simple terminal emulators in python, but the one I have right
now is linux focused.

On Thu, Nov 26, 2015 at 11:19 AM, Nicholas H.Tollervey <ntoll at ntoll.org>
wrote:

> Folks,
>
> I forgot to mention.
>
> I've been giving various workshops since October (about once a week) to
> various Python and teacher groups.
>
> Pythonistas take to the device like a duck to water. Teachers, however,
> all turn up with Windows laptops and the experience is *very* sub-par.
>
> My little "microrepl" doesn't really work well nor cut the mustard. Can
> anyone suggest some other serial emulator for Windows?
>
> Put simply, most of our target users will be on Windows. We need to make
> that as joyful an experience as possible. Zero install (static
> binaries), as little set-up as possible and clear instructions are
> what's needed here.
>
> I've not used Windows since 2008. I wouldn't know where to start. :-/
>
> Thoughts, ideas, offers of help most welcome!
>
> Nicholas.
>
>
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit
>
>


-- 
Dave Hylands
Shuswap, BC, Canada
http://www.davehylands.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151126/277c4105/attachment.html>

From Jonathan.Austin at arm.com  Thu Nov 26 16:39:48 2015
From: Jonathan.Austin at arm.com (Jonathan Austin)
Date: Thu, 26 Nov 2015 21:39:48 +0000
Subject: [Microbit-Python] Windows
In-Reply-To: <56575B35.7050506@ntoll.org>
References: <56575B35.7050506@ntoll.org>
Message-ID: <CF28F30F-B3A7-402D-83D7-4E352B3330E6@arm.com>

Hi Nicholas,

> On 26 Nov 2015, at 19:19, Nicholas H.Tollervey <ntoll at ntoll.org> wrote:
>
> My little "microrepl" doesn't really work well nor cut the mustard. Can
> anyone suggest some other serial emulator for Windows?
>

I have been using Beagle Term, the Chrome App for a lot of my recent
demos (on OS X):

https://chrome.google.com/webstore/detail/beagle-term/gkdofhllgfohlddimiiildbgoggdpoea?hl=en

I?ve just fired up a Windows VM and tested this with a micro:bit, it works

I did have to install the driver (done previously) but the terminal
experience itself was nice.

> Put simply, most of our target users will be on Windows. We need to make
> that as joyful an experience as possible. Zero install (static
> binaries), as little set-up as possible and clear instructions are
> what's needed here.
>

Honestly, I think it would be really cool to build a custom MicroPython
Chrome App - that loaded the IDE with a ?Repl? pane down the bottom?

This doesn?t solve the driver side, but it does solve the terminal UX
issue

Chrome Apps have access to the system serial port, so that would be a nice
cross platform way to give a good experience.

Jonny



> I've not used Windows since 2008. I wouldn't know where to start. :-/
>
> Thoughts, ideas, offers of help most welcome!
>
> Nicholas.
>
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


From microbit at sheep.art.pl  Thu Nov 26 17:09:19 2015
From: microbit at sheep.art.pl (Radomir Dopieralski)
Date: Thu, 26 Nov 2015 23:09:19 +0100
Subject: [Microbit-Python] Windows
In-Reply-To: <CF28F30F-B3A7-402D-83D7-4E352B3330E6@arm.com>
References: <56575B35.7050506@ntoll.org>
 <CF28F30F-B3A7-402D-83D7-4E352B3330E6@arm.com>
Message-ID: <20151126230919.17f672f8@ghostwheel>

On Thu, 26 Nov 2015 21:39:48 +0000
Jonathan Austin <Jonathan.Austin at arm.com> wrote:

[snip - problems on Windows]

It would be awesome to just ship a Raspberry Pi with those, so that we
don't have to deal with Windows ever again ;-) and more importantly,
have a consistent environment that we control.

-- 
Radomir Dopieralski

From david at thinkingbinaries.com  Thu Nov 26 18:04:05 2015
From: david at thinkingbinaries.com (David Whale)
Date: Thu, 26 Nov 2015 23:04:05 +0000
Subject: [Microbit-Python] Windows
In-Reply-To: <CF28F30F-B3A7-402D-83D7-4E352B3330E6@arm.com>
References: <56575B35.7050506@ntoll.org>
 <CF28F30F-B3A7-402D-83D7-4E352B3330E6@arm.com>
Message-ID: <CABeH_SsfWqqsVtd9JMrM4JSe=-BmP0_H8yhZxDT7e-bD3BEieQ@mail.gmail.com>

Not all schools have chrome installed though?

Asking schools to install any software burns about 15 weeks off of your
engagement time. Trust me, it took us 15 weeks to get python installed in
one school and then they got it wrong!

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 global bestselling book "Adventures in Minecraft"
<http://amzn.to/ZGfxZG> - lets get kids coding!
Now in English, Spanish, Chinese and Russian.


On 26 November 2015 at 21:39, Jonathan Austin <Jonathan.Austin at arm.com>
wrote:

> Hi Nicholas,
>
> > On 26 Nov 2015, at 19:19, Nicholas H.Tollervey <ntoll at ntoll.org> wrote:
> >
> > My little "microrepl" doesn't really work well nor cut the mustard. Can
> > anyone suggest some other serial emulator for Windows?
> >
>
> I have been using Beagle Term, the Chrome App for a lot of my recent
> demos (on OS X):
>
>
> https://chrome.google.com/webstore/detail/beagle-term/gkdofhllgfohlddimiiildbgoggdpoea?hl=en
>
> I?ve just fired up a Windows VM and tested this with a micro:bit, it works
>
> I did have to install the driver (done previously) but the terminal
> experience itself was nice.
>
> > Put simply, most of our target users will be on Windows. We need to make
> > that as joyful an experience as possible. Zero install (static
> > binaries), as little set-up as possible and clear instructions are
> > what's needed here.
> >
>
> Honestly, I think it would be really cool to build a custom MicroPython
> Chrome App - that loaded the IDE with a ?Repl? pane down the bottom?
>
> This doesn?t solve the driver side, but it does solve the terminal UX
> issue
>
> Chrome Apps have access to the system serial port, so that would be a nice
> cross platform way to give a good experience.
>
> Jonny
>
>
>
> > I've not used Windows since 2008. I wouldn't know where to start. :-/
> >
> > Thoughts, ideas, offers of help most welcome!
> >
> > Nicholas.
> >
> > _______________________________________________
> > Microbit mailing list
> > Microbit at python.org
> > https://mail.python.org/mailman/listinfo/microbit
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151126/9e5f51b2/attachment-0001.html>

From david at thinkingbinaries.com  Thu Nov 26 18:05:52 2015
From: david at thinkingbinaries.com (David Whale)
Date: Thu, 26 Nov 2015 23:05:52 +0000
Subject: [Microbit-Python] Windows
In-Reply-To: <20151126230919.17f672f8@ghostwheel>
References: <56575B35.7050506@ntoll.org>
 <CF28F30F-B3A7-402D-83D7-4E352B3330E6@arm.com>
 <20151126230919.17f672f8@ghostwheel>
Message-ID: <CABeH_St9LP6rTsmPdPQT5Zw=Zj47J+uQk+dp+6TA2-XKKr3eVA@mail.gmail.com>

I tried the micro:bit TD website on a Raspberry Pi 2 inside the epiphany
browser, it was as slow as treacle and pretty much unusable.

Shipping raspberry pi's to schools doesn't actually solve *every* problem -
it creates a different set of problems that still need to be managed, in my
experience.

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 global bestselling book "Adventures in Minecraft"
<http://amzn.to/ZGfxZG> - lets get kids coding!
Now in English, Spanish, Chinese and Russian.


On 26 November 2015 at 22:09, Radomir Dopieralski <microbit at sheep.art.pl>
wrote:

> On Thu, 26 Nov 2015 21:39:48 +0000
> Jonathan Austin <Jonathan.Austin at arm.com> wrote:
>
> [snip - problems on Windows]
>
> It would be awesome to just ship a Raspberry Pi with those, so that we
> don't have to deal with Windows ever again ;-) and more importantly,
> have a consistent environment that we control.
>
> --
> Radomir Dopieralski
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151126/337695b5/attachment.html>

From david.john.ames at gmail.com  Thu Nov 26 18:11:03 2015
From: david.john.ames at gmail.com (Dave Ames)
Date: Thu, 26 Nov 2015 23:11:03 +0000
Subject: [Microbit-Python] Windows
In-Reply-To: <CABeH_SsfWqqsVtd9JMrM4JSe=-BmP0_H8yhZxDT7e-bD3BEieQ@mail.gmail.com>
References: <56575B35.7050506@ntoll.org>
 <CF28F30F-B3A7-402D-83D7-4E352B3330E6@arm.com>
 <CABeH_SsfWqqsVtd9JMrM4JSe=-BmP0_H8yhZxDT7e-bD3BEieQ@mail.gmail.com>
Message-ID: <CANqypVrToByQHexwvwsEkd6tZgeJZcTw2=m_uWNFJZMru7aU5w@mail.gmail.com>

We had to use IE at last school. Meant various online things couldn't be
done. Had to use a User Agent switcher, with Chrome, on my own linux laptop
in order to be able to connect to the internet via the proxy server. Also
had to supply login details every time.

I assume that with Microsoft's involvement everything has to be runnable in
their favourite browser?

My favourite Python install problem, was arriving at a school to run Python
CPD, to discover that Idle wasn't there, just the python executable.

On Thu, 26 Nov 2015 23:04 David Whale <david at thinkingbinaries.com> wrote:

> Not all schools have chrome installed though?
>
> Asking schools to install any software burns about 15 weeks off of your
> engagement time. Trust me, it took us 15 weeks to get python installed in
> one school and then they got it wrong!
>
> 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 global bestselling book "Adventures in Minecraft"
> <http://amzn.to/ZGfxZG> - lets get kids coding!
> Now in English, Spanish, Chinese and Russian.
>
>
> On 26 November 2015 at 21:39, Jonathan Austin <Jonathan.Austin at arm.com>
> wrote:
>
>> Hi Nicholas,
>>
>> > On 26 Nov 2015, at 19:19, Nicholas H.Tollervey <ntoll at ntoll.org> wrote:
>> >
>> > My little "microrepl" doesn't really work well nor cut the mustard. Can
>> > anyone suggest some other serial emulator for Windows?
>> >
>>
>> I have been using Beagle Term, the Chrome App for a lot of my recent
>> demos (on OS X):
>>
>>
>> https://chrome.google.com/webstore/detail/beagle-term/gkdofhllgfohlddimiiildbgoggdpoea?hl=en
>>
>> I?ve just fired up a Windows VM and tested this with a micro:bit, it works
>>
>> I did have to install the driver (done previously) but the terminal
>> experience itself was nice.
>>
>> > Put simply, most of our target users will be on Windows. We need to make
>> > that as joyful an experience as possible. Zero install (static
>> > binaries), as little set-up as possible and clear instructions are
>> > what's needed here.
>> >
>>
>> Honestly, I think it would be really cool to build a custom MicroPython
>> Chrome App - that loaded the IDE with a ?Repl? pane down the bottom?
>>
>> This doesn?t solve the driver side, but it does solve the terminal UX
>> issue
>>
>> Chrome Apps have access to the system serial port, so that would be a nice
>> cross platform way to give a good experience.
>>
>> Jonny
>>
>>
>>
>> > I've not used Windows since 2008. I wouldn't know where to start. :-/
>> >
>> > Thoughts, ideas, offers of help most welcome!
>> >
>> > Nicholas.
>> >
>> > _______________________________________________
>> > Microbit mailing list
>> > Microbit at python.org
>> > https://mail.python.org/mailman/listinfo/microbit
>>
>> IMPORTANT NOTICE: The contents of this email and any attachments are
>> confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose the
>> contents to any other person, use it for any purpose, or store or copy the
>> information in any medium. Thank you.
>>
>> _______________________________________________
>> Microbit mailing list
>> Microbit at python.org
>> https://mail.python.org/mailman/listinfo/microbit
>>
>
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151126/601e269d/attachment.html>

From damien.p.george at gmail.com  Thu Nov 26 17:50:37 2015
From: damien.p.george at gmail.com (Damien George)
Date: Thu, 26 Nov 2015 22:50:37 +0000
Subject: [Microbit-Python] Windows
In-Reply-To: <20151126230919.17f672f8@ghostwheel>
References: <56575B35.7050506@ntoll.org>
 <CF28F30F-B3A7-402D-83D7-4E352B3330E6@arm.com>
 <20151126230919.17f672f8@ghostwheel>
Message-ID: <CANw+Mz=3a+bx9gT9d=ctkSSPpOUevaCMRve2CmELua689vmvaA@mail.gmail.com>

The best solution would be if Microsoft enabled a standard, generic
USB CDC serial driver for any serial device that was plugged in to the
USB port, just like Linux and Mac already do.

On Thu, Nov 26, 2015 at 10:09 PM, Radomir Dopieralski
<microbit at sheep.art.pl> wrote:
> On Thu, 26 Nov 2015 21:39:48 +0000
> Jonathan Austin <Jonathan.Austin at arm.com> wrote:
>
> [snip - problems on Windows]
>
> It would be awesome to just ship a Raspberry Pi with those, so that we
> don't have to deal with Windows ever again ;-) and more importantly,
> have a consistent environment that we control.
>
> --
> Radomir Dopieralski
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit

From dhylands at gmail.com  Thu Nov 26 18:33:10 2015
From: dhylands at gmail.com (Dave Hylands)
Date: Thu, 26 Nov 2015 15:33:10 -0800
Subject: [Microbit-Python] Windows
In-Reply-To: <CANw+Mz=3a+bx9gT9d=ctkSSPpOUevaCMRve2CmELua689vmvaA@mail.gmail.com>
References: <56575B35.7050506@ntoll.org>
 <CF28F30F-B3A7-402D-83D7-4E352B3330E6@arm.com>
 <20151126230919.17f672f8@ghostwheel>
 <CANw+Mz=3a+bx9gT9d=ctkSSPpOUevaCMRve2CmELua689vmvaA@mail.gmail.com>
Message-ID: <CABi1daG3DS9_6WSujU7qH_wnojb9fdWre1a3mTjOD9oRpcGOGw@mail.gmail.com>

Couldn't we take a copy of the pycdc.inf one that comes with MicroPython
and tweak it for the microbit?
That could be on the same thumb drive as the terminal program.

On Thu, Nov 26, 2015 at 2:50 PM, Damien George <damien.p.george at gmail.com>
wrote:

> The best solution would be if Microsoft enabled a standard, generic
> USB CDC serial driver for any serial device that was plugged in to the
> USB port, just like Linux and Mac already do.
>
> On Thu, Nov 26, 2015 at 10:09 PM, Radomir Dopieralski
> <microbit at sheep.art.pl> wrote:
> > On Thu, 26 Nov 2015 21:39:48 +0000
> > Jonathan Austin <Jonathan.Austin at arm.com> wrote:
> >
> > [snip - problems on Windows]
> >
> > It would be awesome to just ship a Raspberry Pi with those, so that we
> > don't have to deal with Windows ever again ;-) and more importantly,
> > have a consistent environment that we control.
> >
> > --
> > Radomir Dopieralski
> > _______________________________________________
> > 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
>



-- 
Dave Hylands
Shuswap, BC, Canada
http://www.davehylands.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151126/98eee4f4/attachment-0001.html>

From damien.p.george at gmail.com  Thu Nov 26 18:35:05 2015
From: damien.p.george at gmail.com (Damien George)
Date: Thu, 26 Nov 2015 23:35:05 +0000
Subject: [Microbit-Python] Windows
In-Reply-To: <CABi1daG3DS9_6WSujU7qH_wnojb9fdWre1a3mTjOD9oRpcGOGw@mail.gmail.com>
References: <56575B35.7050506@ntoll.org>
 <CF28F30F-B3A7-402D-83D7-4E352B3330E6@arm.com>
 <20151126230919.17f672f8@ghostwheel>
 <CANw+Mz=3a+bx9gT9d=ctkSSPpOUevaCMRve2CmELua689vmvaA@mail.gmail.com>
 <CABi1daG3DS9_6WSujU7qH_wnojb9fdWre1a3mTjOD9oRpcGOGw@mail.gmail.com>
Message-ID: <CANw+Mznuwi1i9uEw8bOSssApV7sqTb8H5e8-a9HV_P8oW_mbTg@mail.gmail.com>

pybcdc.inf still requires some effort to install, and probably
administrator rights (although I could be wrong here...).

On Thu, Nov 26, 2015 at 11:33 PM, Dave Hylands <dhylands at gmail.com> wrote:
> Couldn't we take a copy of the pycdc.inf one that comes with MicroPython and
> tweak it for the microbit?
> That could be on the same thumb drive as the terminal program.
>
> On Thu, Nov 26, 2015 at 2:50 PM, Damien George <damien.p.george at gmail.com>
> wrote:
>>
>> The best solution would be if Microsoft enabled a standard, generic
>> USB CDC serial driver for any serial device that was plugged in to the
>> USB port, just like Linux and Mac already do.
>>
>> On Thu, Nov 26, 2015 at 10:09 PM, Radomir Dopieralski
>> <microbit at sheep.art.pl> wrote:
>> > On Thu, 26 Nov 2015 21:39:48 +0000
>> > Jonathan Austin <Jonathan.Austin at arm.com> wrote:
>> >
>> > [snip - problems on Windows]
>> >
>> > It would be awesome to just ship a Raspberry Pi with those, so that we
>> > don't have to deal with Windows ever again ;-) and more importantly,
>> > have a consistent environment that we control.
>> >
>> > --
>> > Radomir Dopieralski
>> > _______________________________________________
>> > 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
>
>
>
>
> --
> Dave Hylands
> Shuswap, BC, Canada
> http://www.davehylands.com
>
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit
>

From david at thinkingbinaries.com  Thu Nov 26 18:35:08 2015
From: david at thinkingbinaries.com (David Whale)
Date: Thu, 26 Nov 2015 23:35:08 +0000
Subject: [Microbit-Python] Windows
In-Reply-To: <CANw+Mz=3a+bx9gT9d=ctkSSPpOUevaCMRve2CmELua689vmvaA@mail.gmail.com>
References: <56575B35.7050506@ntoll.org>
 <CF28F30F-B3A7-402D-83D7-4E352B3330E6@arm.com>
 <20151126230919.17f672f8@ghostwheel>
 <CANw+Mz=3a+bx9gT9d=ctkSSPpOUevaCMRve2CmELua689vmvaA@mail.gmail.com>
Message-ID: <CABeH_SuZY5jkz4XTzDhr_wnOGvF0yHjO71_NehSDYiH3DMQpbg@mail.gmail.com>

Tell me about it! - the Mac and Raspberry Pi setups of Adventures in
Minecraft hardware chapter were a dream. The windows setup was a real pain
due to lack of what you describe as default behaviour on the other two
platforms.

I think somewhere along the way, someone said "nobody uses serial ports any
more" and the rest is history :(

___________________________________________________________
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 global bestselling book "Adventures in Minecraft"
<http://amzn.to/ZGfxZG> - lets get kids coding!
Now in English, Spanish, Chinese and Russian.


On 26 November 2015 at 22:50, Damien George <damien.p.george at gmail.com>
wrote:

> The best solution would be if Microsoft enabled a standard, generic
> USB CDC serial driver for any serial device that was plugged in to the
> USB port, just like Linux and Mac already do.
>
> On Thu, Nov 26, 2015 at 10:09 PM, Radomir Dopieralski
> <microbit at sheep.art.pl> wrote:
> > On Thu, 26 Nov 2015 21:39:48 +0000
> > Jonathan Austin <Jonathan.Austin at arm.com> wrote:
> >
> > [snip - problems on Windows]
> >
> > It would be awesome to just ship a Raspberry Pi with those, so that we
> > don't have to deal with Windows ever again ;-) and more importantly,
> > have a consistent environment that we control.
> >
> > --
> > Radomir Dopieralski
> > _______________________________________________
> > Microbit mailing list
> > Microbit at python.org
> > https://mail.python.org/mailman/listinfo/microbit
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151126/b60b447b/attachment.html>

From david at thinkingbinaries.com  Thu Nov 26 18:44:51 2015
From: david at thinkingbinaries.com (David Whale)
Date: Thu, 26 Nov 2015 23:44:51 +0000
Subject: [Microbit-Python] Windows
In-Reply-To: <CABi1daG3DS9_6WSujU7qH_wnojb9fdWre1a3mTjOD9oRpcGOGw@mail.gmail.com>
References: <56575B35.7050506@ntoll.org>
 <CF28F30F-B3A7-402D-83D7-4E352B3330E6@arm.com>
 <20151126230919.17f672f8@ghostwheel>
 <CANw+Mz=3a+bx9gT9d=ctkSSPpOUevaCMRve2CmELua689vmvaA@mail.gmail.com>
 <CABi1daG3DS9_6WSujU7qH_wnojb9fdWre1a3mTjOD9oRpcGOGw@mail.gmail.com>
Message-ID: <CABeH_SvyGTB=NoPXDQW2Mm9UDQWQvGLKwpnksCQNwoOVSo6sMg@mail.gmail.com>

Does it have a digital signature in it? If not, you have to do about 5
restarts on windows 8.1 to remove 'driver enforcement mode'.



___________________________________________________________
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 global bestselling book "Adventures in Minecraft"
<http://amzn.to/ZGfxZG> - lets get kids coding!
Now in English, Spanish, Chinese and Russian.


On 26 November 2015 at 23:33, Dave Hylands <dhylands at gmail.com> wrote:

> Couldn't we take a copy of the pycdc.inf one that comes with MicroPython
> and tweak it for the microbit?
> That could be on the same thumb drive as the terminal program.
>
> On Thu, Nov 26, 2015 at 2:50 PM, Damien George <damien.p.george at gmail.com>
> wrote:
>
>> The best solution would be if Microsoft enabled a standard, generic
>> USB CDC serial driver for any serial device that was plugged in to the
>> USB port, just like Linux and Mac already do.
>>
>> On Thu, Nov 26, 2015 at 10:09 PM, Radomir Dopieralski
>> <microbit at sheep.art.pl> wrote:
>> > On Thu, 26 Nov 2015 21:39:48 +0000
>> > Jonathan Austin <Jonathan.Austin at arm.com> wrote:
>> >
>> > [snip - problems on Windows]
>> >
>> > It would be awesome to just ship a Raspberry Pi with those, so that we
>> > don't have to deal with Windows ever again ;-) and more importantly,
>> > have a consistent environment that we control.
>> >
>> > --
>> > Radomir Dopieralski
>> > _______________________________________________
>> > 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
>>
>
>
>
> --
> Dave Hylands
> Shuswap, BC, Canada
> http://www.davehylands.com
>
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151126/a0bc1a37/attachment.html>

From dhylands at gmail.com  Thu Nov 26 18:53:02 2015
From: dhylands at gmail.com (Dave Hylands)
Date: Thu, 26 Nov 2015 15:53:02 -0800
Subject: [Microbit-Python] Windows
In-Reply-To: <CABeH_SvyGTB=NoPXDQW2Mm9UDQWQvGLKwpnksCQNwoOVSo6sMg@mail.gmail.com>
References: <56575B35.7050506@ntoll.org>
 <CF28F30F-B3A7-402D-83D7-4E352B3330E6@arm.com>
 <20151126230919.17f672f8@ghostwheel>
 <CANw+Mz=3a+bx9gT9d=ctkSSPpOUevaCMRve2CmELua689vmvaA@mail.gmail.com>
 <CABi1daG3DS9_6WSujU7qH_wnojb9fdWre1a3mTjOD9oRpcGOGw@mail.gmail.com>
 <CABeH_SvyGTB=NoPXDQW2Mm9UDQWQvGLKwpnksCQNwoOVSo6sMg@mail.gmail.com>
Message-ID: <CABi1daHo_SGo-apgxdZFMzSTv1oUns1ygF0FuRL57PUYYx80zw@mail.gmail.com>

The signed bits are provided by Microsoft.

Microspft provides the driver file, called usbser.sys

I've attached the file that shows up on the pyboard.

I'm assuming that the microbit shows as just a cdc interface, in which case
you'll want to edit the two lines near the end:

%DESCRIPTION%=DriverInstall, USB\VID_f055&PID_9800&MI_00,
USB\VID_f055&PID_9800&MI_01

and remove everything from the comma to the end of the line and change the
VID & PID.

The strings at the end of the file probably should also be tweaked



On Thu, Nov 26, 2015 at 3:44 PM, David Whale <david at thinkingbinaries.com>
wrote:

> Does it have a digital signature in it? If not, you have to do about 5
> restarts on windows 8.1 to remove 'driver enforcement mode'.
>
>
>
> ___________________________________________________________
> 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 global bestselling book "Adventures in Minecraft"
> <http://amzn.to/ZGfxZG> - lets get kids coding!
> Now in English, Spanish, Chinese and Russian.
>
>
> On 26 November 2015 at 23:33, Dave Hylands <dhylands at gmail.com> wrote:
>
>> Couldn't we take a copy of the pycdc.inf one that comes with MicroPython
>> and tweak it for the microbit?
>> That could be on the same thumb drive as the terminal program.
>>
>> On Thu, Nov 26, 2015 at 2:50 PM, Damien George <damien.p.george at gmail.com
>> > wrote:
>>
>>> The best solution would be if Microsoft enabled a standard, generic
>>> USB CDC serial driver for any serial device that was plugged in to the
>>> USB port, just like Linux and Mac already do.
>>>
>>> On Thu, Nov 26, 2015 at 10:09 PM, Radomir Dopieralski
>>> <microbit at sheep.art.pl> wrote:
>>> > On Thu, 26 Nov 2015 21:39:48 +0000
>>> > Jonathan Austin <Jonathan.Austin at arm.com> wrote:
>>> >
>>> > [snip - problems on Windows]
>>> >
>>> > It would be awesome to just ship a Raspberry Pi with those, so that we
>>> > don't have to deal with Windows ever again ;-) and more importantly,
>>> > have a consistent environment that we control.
>>> >
>>> > --
>>> > Radomir Dopieralski
>>> > _______________________________________________
>>> > 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
>>>
>>
>>
>>
>> --
>> Dave Hylands
>> Shuswap, BC, Canada
>> http://www.davehylands.com
>>
>> _______________________________________________
>> 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
>
>


-- 
Dave Hylands
Shuswap, BC, Canada
http://www.davehylands.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151126/137744ab/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pybcdc.inf
Type: application/octet-stream
Size: 2436 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/microbit/attachments/20151126/137744ab/attachment-0001.obj>

From david at thinkingbinaries.com  Fri Nov 27 01:34:11 2015
From: david at thinkingbinaries.com (David Whale)
Date: Fri, 27 Nov 2015 06:34:11 +0000
Subject: [Microbit-Python] Windows
In-Reply-To: <CABi1daHo_SGo-apgxdZFMzSTv1oUns1ygF0FuRL57PUYYx80zw@mail.gmail.com>
References: <56575B35.7050506@ntoll.org>
 <CF28F30F-B3A7-402D-83D7-4E352B3330E6@arm.com>
 <20151126230919.17f672f8@ghostwheel>
 <CANw+Mz=3a+bx9gT9d=ctkSSPpOUevaCMRve2CmELua689vmvaA@mail.gmail.com>
 <CABi1daG3DS9_6WSujU7qH_wnojb9fdWre1a3mTjOD9oRpcGOGw@mail.gmail.com>
 <CABeH_SvyGTB=NoPXDQW2Mm9UDQWQvGLKwpnksCQNwoOVSo6sMg@mail.gmail.com>
 <CABi1daHo_SGo-apgxdZFMzSTv1oUns1ygF0FuRL57PUYYx80zw@mail.gmail.com>
Message-ID: <CABeH_St9X65w7FgGVW4yje_=KZAhpEmso729qWjY_zCDD91ipw@mail.gmail.com>

There's no digital signature in that file. So on windows >= 8.1 you'll have
to restart 4 or 5 times with administrator access in order to get the
driver to install by disabling the "driver enforcement mode" feature that
they added in 8.1




___________________________________________________________
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 global bestselling book "Adventures in Minecraft"
<http://amzn.to/ZGfxZG> - lets get kids coding!
Now in English, Spanish, Chinese and Russian.


On 26 November 2015 at 23:53, Dave Hylands <dhylands at gmail.com> wrote:

> The signed bits are provided by Microsoft.
>
> Microspft provides the driver file, called usbser.sys
>
> I've attached the file that shows up on the pyboard.
>
> I'm assuming that the microbit shows as just a cdc interface, in which
> case you'll want to edit the two lines near the end:
>
> %DESCRIPTION%=DriverInstall, USB\VID_f055&PID_9800&MI_00,
> USB\VID_f055&PID_9800&MI_01
>
> and remove everything from the comma to the end of the line and change the
> VID & PID.
>
> The strings at the end of the file probably should also be tweaked
>
>
>
> On Thu, Nov 26, 2015 at 3:44 PM, David Whale <david at thinkingbinaries.com>
> wrote:
>
>> Does it have a digital signature in it? If not, you have to do about 5
>> restarts on windows 8.1 to remove 'driver enforcement mode'.
>>
>>
>>
>> ___________________________________________________________
>> 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 global bestselling book "Adventures in Minecraft"
>> <http://amzn.to/ZGfxZG> - lets get kids coding!
>> Now in English, Spanish, Chinese and Russian.
>>
>>
>> On 26 November 2015 at 23:33, Dave Hylands <dhylands at gmail.com> wrote:
>>
>>> Couldn't we take a copy of the pycdc.inf one that comes with MicroPython
>>> and tweak it for the microbit?
>>> That could be on the same thumb drive as the terminal program.
>>>
>>> On Thu, Nov 26, 2015 at 2:50 PM, Damien George <
>>> damien.p.george at gmail.com> wrote:
>>>
>>>> The best solution would be if Microsoft enabled a standard, generic
>>>> USB CDC serial driver for any serial device that was plugged in to the
>>>> USB port, just like Linux and Mac already do.
>>>>
>>>> On Thu, Nov 26, 2015 at 10:09 PM, Radomir Dopieralski
>>>> <microbit at sheep.art.pl> wrote:
>>>> > On Thu, 26 Nov 2015 21:39:48 +0000
>>>> > Jonathan Austin <Jonathan.Austin at arm.com> wrote:
>>>> >
>>>> > [snip - problems on Windows]
>>>> >
>>>> > It would be awesome to just ship a Raspberry Pi with those, so that we
>>>> > don't have to deal with Windows ever again ;-) and more importantly,
>>>> > have a consistent environment that we control.
>>>> >
>>>> > --
>>>> > Radomir Dopieralski
>>>> > _______________________________________________
>>>> > 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
>>>>
>>>
>>>
>>>
>>> --
>>> Dave Hylands
>>> Shuswap, BC, Canada
>>> http://www.davehylands.com
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
>
> --
> Dave Hylands
> Shuswap, BC, Canada
> http://www.davehylands.com
>
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151127/23da35af/attachment.html>

From dhylands at gmail.com  Fri Nov 27 01:46:24 2015
From: dhylands at gmail.com (Dave Hylands)
Date: Thu, 26 Nov 2015 22:46:24 -0800
Subject: [Microbit-Python] Windows
In-Reply-To: <CABeH_St9X65w7FgGVW4yje_=KZAhpEmso729qWjY_zCDD91ipw@mail.gmail.com>
References: <56575B35.7050506@ntoll.org>
 <CF28F30F-B3A7-402D-83D7-4E352B3330E6@arm.com>
 <20151126230919.17f672f8@ghostwheel>
 <CANw+Mz=3a+bx9gT9d=ctkSSPpOUevaCMRve2CmELua689vmvaA@mail.gmail.com>
 <CABi1daG3DS9_6WSujU7qH_wnojb9fdWre1a3mTjOD9oRpcGOGw@mail.gmail.com>
 <CABeH_SvyGTB=NoPXDQW2Mm9UDQWQvGLKwpnksCQNwoOVSo6sMg@mail.gmail.com>
 <CABi1daHo_SGo-apgxdZFMzSTv1oUns1ygF0FuRL57PUYYx80zw@mail.gmail.com>
 <CABeH_St9X65w7FgGVW4yje_=KZAhpEmso729qWjY_zCDD91ipw@mail.gmail.com>
Message-ID: <CABi1daH0NQOfUMB4JFp-+T7kYiy_Qbbr1zir5LMAGhXXrs2wrA@mail.gmail.com>

Hi David,

I'll take your word for it. The newest Windows machine I have is Windows 7,
and that's one of those really cheap $300 laptops.

Dave Hylands

On Thu, Nov 26, 2015 at 10:34 PM, David Whale <david at thinkingbinaries.com>
wrote:

> There's no digital signature in that file. So on windows >= 8.1 you'll
> have to restart 4 or 5 times with administrator access in order to get the
> driver to install by disabling the "driver enforcement mode" feature that
> they added in 8.1
>
>
>
>
> ___________________________________________________________
> 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 global bestselling book "Adventures in Minecraft"
> <http://amzn.to/ZGfxZG> - lets get kids coding!
> Now in English, Spanish, Chinese and Russian.
>
>
> On 26 November 2015 at 23:53, Dave Hylands <dhylands at gmail.com> wrote:
>
>> The signed bits are provided by Microsoft.
>>
>> Microspft provides the driver file, called usbser.sys
>>
>> I've attached the file that shows up on the pyboard.
>>
>> I'm assuming that the microbit shows as just a cdc interface, in which
>> case you'll want to edit the two lines near the end:
>>
>> %DESCRIPTION%=DriverInstall, USB\VID_f055&PID_9800&MI_00,
>> USB\VID_f055&PID_9800&MI_01
>>
>> and remove everything from the comma to the end of the line and change
>> the VID & PID.
>>
>> The strings at the end of the file probably should also be tweaked
>>
>>
>>
>> On Thu, Nov 26, 2015 at 3:44 PM, David Whale <david at thinkingbinaries.com>
>> wrote:
>>
>>> Does it have a digital signature in it? If not, you have to do about 5
>>> restarts on windows 8.1 to remove 'driver enforcement mode'.
>>>
>>>
>>>
>>> ___________________________________________________________
>>> 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 global bestselling book "Adventures in Minecraft"
>>> <http://amzn.to/ZGfxZG> - lets get kids coding!
>>> Now in English, Spanish, Chinese and Russian.
>>>
>>>
>>> On 26 November 2015 at 23:33, Dave Hylands <dhylands at gmail.com> wrote:
>>>
>>>> Couldn't we take a copy of the pycdc.inf one that comes with
>>>> MicroPython and tweak it for the microbit?
>>>> That could be on the same thumb drive as the terminal program.
>>>>
>>>> On Thu, Nov 26, 2015 at 2:50 PM, Damien George <
>>>> damien.p.george at gmail.com> wrote:
>>>>
>>>>> The best solution would be if Microsoft enabled a standard, generic
>>>>> USB CDC serial driver for any serial device that was plugged in to the
>>>>> USB port, just like Linux and Mac already do.
>>>>>
>>>>> On Thu, Nov 26, 2015 at 10:09 PM, Radomir Dopieralski
>>>>> <microbit at sheep.art.pl> wrote:
>>>>> > On Thu, 26 Nov 2015 21:39:48 +0000
>>>>> > Jonathan Austin <Jonathan.Austin at arm.com> wrote:
>>>>> >
>>>>> > [snip - problems on Windows]
>>>>> >
>>>>> > It would be awesome to just ship a Raspberry Pi with those, so that
>>>>> we
>>>>> > don't have to deal with Windows ever again ;-) and more importantly,
>>>>> > have a consistent environment that we control.
>>>>> >
>>>>> > --
>>>>> > Radomir Dopieralski
>>>>> > _______________________________________________
>>>>> > 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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Dave Hylands
>>>> Shuswap, BC, Canada
>>>> http://www.davehylands.com
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>
>>
>> --
>> Dave Hylands
>> Shuswap, BC, Canada
>> http://www.davehylands.com
>>
>> _______________________________________________
>> 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
>
>


-- 
Dave Hylands
Shuswap, BC, Canada
http://www.davehylands.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151126/24e6dd30/attachment-0001.html>

From david at thinkingbinaries.com  Fri Nov 27 02:17:10 2015
From: david at thinkingbinaries.com (David Whale)
Date: Fri, 27 Nov 2015 07:17:10 +0000
Subject: [Microbit-Python] Windows
In-Reply-To: <CABi1daH0NQOfUMB4JFp-+T7kYiy_Qbbr1zir5LMAGhXXrs2wrA@mail.gmail.com>
References: <56575B35.7050506@ntoll.org>
 <CF28F30F-B3A7-402D-83D7-4E352B3330E6@arm.com>
 <20151126230919.17f672f8@ghostwheel>
 <CANw+Mz=3a+bx9gT9d=ctkSSPpOUevaCMRve2CmELua689vmvaA@mail.gmail.com>
 <CABi1daG3DS9_6WSujU7qH_wnojb9fdWre1a3mTjOD9oRpcGOGw@mail.gmail.com>
 <CABeH_SvyGTB=NoPXDQW2Mm9UDQWQvGLKwpnksCQNwoOVSo6sMg@mail.gmail.com>
 <CABi1daHo_SGo-apgxdZFMzSTv1oUns1ygF0FuRL57PUYYx80zw@mail.gmail.com>
 <CABeH_St9X65w7FgGVW4yje_=KZAhpEmso729qWjY_zCDD91ipw@mail.gmail.com>
 <CABi1daH0NQOfUMB4JFp-+T7kYiy_Qbbr1zir5LMAGhXXrs2wrA@mail.gmail.com>
Message-ID: <CABeH_SugutqmFh_fCJ44ULexCTuVouWJ+uSpbkZSquJKHK5KcA@mail.gmail.com>

This is the torture I had to push my windows users through on win 8.1 to
install a 'standard' CDC USBSER driver:

https://learn.sparkfun.com/tutorials/disabling-driver-signature-on-windows-8

Since my book was published, sparkfun have now signed all their drivers. If
we can get a signed driver for the micro:bit serial class, all of this pain
will go away.





___________________________________________________________
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 global bestselling book "Adventures in Minecraft"
<http://amzn.to/ZGfxZG> - lets get kids coding!
Now in English, Spanish, Chinese and Russian.


On 27 November 2015 at 06:46, Dave Hylands <dhylands at gmail.com> wrote:

> Hi David,
>
> I'll take your word for it. The newest Windows machine I have is Windows
> 7, and that's one of those really cheap $300 laptops.
>
> Dave Hylands
>
> On Thu, Nov 26, 2015 at 10:34 PM, David Whale <david at thinkingbinaries.com>
> wrote:
>
>> There's no digital signature in that file. So on windows >= 8.1 you'll
>> have to restart 4 or 5 times with administrator access in order to get the
>> driver to install by disabling the "driver enforcement mode" feature that
>> they added in 8.1
>>
>>
>>
>>
>> ___________________________________________________________
>> 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 global bestselling book "Adventures in Minecraft"
>> <http://amzn.to/ZGfxZG> - lets get kids coding!
>> Now in English, Spanish, Chinese and Russian.
>>
>>
>> On 26 November 2015 at 23:53, Dave Hylands <dhylands at gmail.com> wrote:
>>
>>> The signed bits are provided by Microsoft.
>>>
>>> Microspft provides the driver file, called usbser.sys
>>>
>>> I've attached the file that shows up on the pyboard.
>>>
>>> I'm assuming that the microbit shows as just a cdc interface, in which
>>> case you'll want to edit the two lines near the end:
>>>
>>> %DESCRIPTION%=DriverInstall, USB\VID_f055&PID_9800&MI_00,
>>> USB\VID_f055&PID_9800&MI_01
>>>
>>> and remove everything from the comma to the end of the line and change
>>> the VID & PID.
>>>
>>> The strings at the end of the file probably should also be tweaked
>>>
>>>
>>>
>>> On Thu, Nov 26, 2015 at 3:44 PM, David Whale <david at thinkingbinaries.com
>>> > wrote:
>>>
>>>> Does it have a digital signature in it? If not, you have to do about 5
>>>> restarts on windows 8.1 to remove 'driver enforcement mode'.
>>>>
>>>>
>>>>
>>>> ___________________________________________________________
>>>> 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 global bestselling book "Adventures in Minecraft"
>>>> <http://amzn.to/ZGfxZG> - lets get kids coding!
>>>> Now in English, Spanish, Chinese and Russian.
>>>>
>>>>
>>>> On 26 November 2015 at 23:33, Dave Hylands <dhylands at gmail.com> wrote:
>>>>
>>>>> Couldn't we take a copy of the pycdc.inf one that comes with
>>>>> MicroPython and tweak it for the microbit?
>>>>> That could be on the same thumb drive as the terminal program.
>>>>>
>>>>> On Thu, Nov 26, 2015 at 2:50 PM, Damien George <
>>>>> damien.p.george at gmail.com> wrote:
>>>>>
>>>>>> The best solution would be if Microsoft enabled a standard, generic
>>>>>> USB CDC serial driver for any serial device that was plugged in to the
>>>>>> USB port, just like Linux and Mac already do.
>>>>>>
>>>>>> On Thu, Nov 26, 2015 at 10:09 PM, Radomir Dopieralski
>>>>>> <microbit at sheep.art.pl> wrote:
>>>>>> > On Thu, 26 Nov 2015 21:39:48 +0000
>>>>>> > Jonathan Austin <Jonathan.Austin at arm.com> wrote:
>>>>>> >
>>>>>> > [snip - problems on Windows]
>>>>>> >
>>>>>> > It would be awesome to just ship a Raspberry Pi with those, so that
>>>>>> we
>>>>>> > don't have to deal with Windows ever again ;-) and more importantly,
>>>>>> > have a consistent environment that we control.
>>>>>> >
>>>>>> > --
>>>>>> > Radomir Dopieralski
>>>>>> > _______________________________________________
>>>>>> > 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
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Dave Hylands
>>>>> Shuswap, BC, Canada
>>>>> http://www.davehylands.com
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>
>>>
>>>
>>> --
>>> Dave Hylands
>>> Shuswap, BC, Canada
>>> http://www.davehylands.com
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
>
> --
> Dave Hylands
> Shuswap, BC, Canada
> http://www.davehylands.com
>
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151127/77cb6b3c/attachment.html>

From ntoll at ntoll.org  Fri Nov 27 03:06:21 2015
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Fri, 27 Nov 2015 08:06:21 +0000
Subject: [Microbit-Python] [JONNY TAKE NOTE] Re:  Windows
In-Reply-To: <CABeH_SugutqmFh_fCJ44ULexCTuVouWJ+uSpbkZSquJKHK5KcA@mail.gmail.com>
References: <56575B35.7050506@ntoll.org>
 <CF28F30F-B3A7-402D-83D7-4E352B3330E6@arm.com>
 <20151126230919.17f672f8@ghostwheel>
 <CANw+Mz=3a+bx9gT9d=ctkSSPpOUevaCMRve2CmELua689vmvaA@mail.gmail.com>
 <CABi1daG3DS9_6WSujU7qH_wnojb9fdWre1a3mTjOD9oRpcGOGw@mail.gmail.com>
 <CABeH_SvyGTB=NoPXDQW2Mm9UDQWQvGLKwpnksCQNwoOVSo6sMg@mail.gmail.com>
 <CABi1daHo_SGo-apgxdZFMzSTv1oUns1ygF0FuRL57PUYYx80zw@mail.gmail.com>
 <CABeH_St9X65w7FgGVW4yje_=KZAhpEmso729qWjY_zCDD91ipw@mail.gmail.com>
 <CABi1daH0NQOfUMB4JFp-+T7kYiy_Qbbr1zir5LMAGhXXrs2wrA@mail.gmail.com>
 <CABeH_SugutqmFh_fCJ44ULexCTuVouWJ+uSpbkZSquJKHK5KcA@mail.gmail.com>
Message-ID: <56580EFD.6080600@ntoll.org>

On 27/11/15 07:17, David Whale wrote:
> This is the torture I had to push my windows users through on win 8.1 to
> install a 'standard' CDC USBSER driver:
> 
> https://learn.sparkfun.com/tutorials/disabling-driver-signature-on-windows-8
> 
> Since my book was published, sparkfun have now signed all their drivers.
> If we can get a signed driver for the micro:bit serial class, all of
> this pain will go away.
> 

Hi David,

It's great to have your perspective on this and I feel really bad for
you having to go through such pain.

As I understand it, we need to get these drivers signed and only
Microsoft are able to do this for us. Given that this isn't just a
micro:bit related problem but an ARM embed issue perhaps Jonny can
confirm the following...

When I booted up my Windows partition I installed the driver without any
of the pain David speaks of (to be clear, it was the driver referenced
here: https://developer.mbed.org/handbook/Windows-serial-configuration).
Perhaps I was using Windows 7 - I'll need to check. Yet it appears to my
non-Windows-using eyes that because it was relatively pain free, the
required driver is therefore already signed.

If not (i.e. I have my mental model of the problem wrong), can we, as
co-partners of Microsoft on this project, get them to provide the
appropriately signed file? Who (and how) might be best to make this happen?

Can this driver be included on the device along with that HTML file that
points to ARM mbed..?

Jonny? Thoughts?

Ultimately, the user story should be something like (and I realise I may
sound facetious here), as an 11yo kid sitting at my parent's Windows
computer I want to plug in my micro:bit and have clear instructions and
all the files I need to install the correct drivers.

;-)

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: <http://mail.python.org/pipermail/microbit/attachments/20151127/b1324302/attachment.sig>

From peter.inglesby at gmail.com  Fri Nov 27 04:05:14 2015
From: peter.inglesby at gmail.com (Peter Inglesby)
Date: Fri, 27 Nov 2015 09:05:14 +0000
Subject: [Microbit-Python] Python Editor
In-Reply-To: <56575A3F.2020503@ntoll.org>
References: <56575A3F.2020503@ntoll.org>
Message-ID: <CAENJrPkYO2KxxyGC316dcbf6vyBgAgbZrm4VtBbmGxd+Z+EeHA@mail.gmail.com>

Hi Nicholas, hi everyone,

I've managed to get this to work, and it looks great.  Nice work, Nicholas
and Steve!

If anyone else is trying to build this, they should be aware of
https://github.com/bbcmicrobit/PythonEditor/issues/2.

Cheers,

Peter.

On 26 November 2015 at 19:15, Nicholas H.Tollervey <ntoll at ntoll.org> wrote:

> Hi Folks,
>
> First of all, many apologies for going off the radar recently. Put
> simply, I've had to deliver the code editor for TouchDevelop and needed
> to hunker down. Happily, it's "finished" pending BBC testing. This will,
> of course, result in updates and changes, but I believe I've broken the
> camel's back.
>
> Here's a video of the latest version, including all of Steve Hawkes'
> wonderful design!
>
> https://www.youtube.com/watch?v=7pq7XUBHOYs
>
> The source code is still supposed to be "hidden".
>
> However, it's hiding in plain view (as Michael Sparks would put it). If
> Microsoft can develop their web based programming tools (i.e.
> TouchDevelop) in the open, so can the Python Software Foundation.
>
> Ergo, here's the code:
>
> https://github.com/bbcmicrobit/PythonEditor
>
> (There's NOTHING in that repos that reveals anything above and beyond
> what has already been published about the device.)
>
> Grace Hopper FTW.
>
> PLEASE PLEASE PLEASE feel free to take a look, try it out and CONTRIBUTE
> bug fixes, code and documentation. I will definitely need help in terms
> of web development for cross browser testing. I'll also be updating the
> stand-alone browser to the same code / tests / design over the weekend:
>
> https://github.com/ntoll/upyed
>
> Also, the "help.html" file could do with some love. I'd like there to be
> a very simple tutorial, some videos and example code. All written for
> 11yo. ;-)
>
> If you're wondering why we need a Python presence in the TouchDevelop
> platform then the answer is simple: it's the "blessed" platform that the
> BBC will be pushing. Our editor is, I guess, a sort of a Trojan horse
> pointing a way to Python and the "hacker" (used in the positive sense)
> community.
>
> As always, comments, constructive critique and ideas most welcome!
>
> In other news, David Whale has put me in touch with an 11yo girl called
> Abbie who has been designing some images for us. I'll try to get those
> wrapped up into a PR over the weekend. We've also had our first bug
> report from a teacher
> (https://github.com/bbcmicrobit/micropython/issues/110) although I see
> Radomir and Mark are all over that issue. ;-)
>
> Also, Tom and Radomir have been having fun with their micro:bits as part
> of the world tour:
>
> http://microworldtour.github.io/
>
> Robots! Water! Videos! Code! Dead micro:bits! Shocking stuff..!
>
> Carol (California) has had hers a few days, Mark (New Zealand) had his
> arrive today and Naomi (Chicago) and I are following the package
> tracking site as USPS appear to have kidnapped hers (it's in the
> Washington DC area at the moment). I've been in touch with a bunch of
> Brazilians who'd love to get their hands on one! Please feel free to
> suggest others who might want to take part. The more far flung, the
> better! Know anyone in the Antarctic? ;-)
>
> If *you* have a micro:bit and have something cool to show, please
> contribute it via pinging me an email. I'll add an "honourable mentions"
> page to the website so you can add things there. Alternatively, create a
> pull request into the examples directory.
>
> I'm off to the pub for a well earned drink. :-)
>
> 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: <http://mail.python.org/pipermail/microbit/attachments/20151127/87e76ea3/attachment-0001.html>

From carlos.p.a.87 at gmail.com  Fri Nov 27 04:46:35 2015
From: carlos.p.a.87 at gmail.com (Carlos P.A.)
Date: Fri, 27 Nov 2015 09:46:35 +0000
Subject: [Microbit-Python] [JONNY TAKE NOTE] Re: Windows
Message-ID: <CAC_p0yD7yt9a3gOsB2zXU9M9aHA4yVxaqv9p97SN7zAP0SmYqg@mail.gmail.com>

> When I booted up my Windows partition I installed the driver without any
> of the pain David speaks of (to be clear, it was the driver referenced
> here: https://developer.mbed.org/handbook/Windows-serial-configuration).
> Perhaps I was using Windows 7 - I'll need to check. Yet it appears to my
> non-Windows-using eyes that because it was relatively pain free, the
> required driver is therefore already signed.


Hi Nicholas, I was in your session at the Cambridge Makespace a few weeks
back with a Windows 8 laptop and installing the drivers was quite pain
free. I believe at the time the executable was hosted in one of the github
repositories, but I would assume it is the same one you'd linked in your
post. This installer must be signed, as I was able to install it on Win8.1
without any issues and use the microbit right away.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151127/f1a2a5d7/attachment.html>

From ssouravsingh12 at gmail.com  Sun Nov 29 03:27:00 2015
From: ssouravsingh12 at gmail.com (Sourav Singh)
Date: Sun, 29 Nov 2015 13:57:00 +0530
Subject: [Microbit-Python] Creating In-built tutorial for MicroPython
Message-ID: <CALpy4prpj3uxNQ8m=QL200dW5ruSyiUvQsMMdh9c6hV+ycOFVA@mail.gmail.com>

Hello,

I am Sourav Singh from India. I go by the Github username souravsingh

I saw an issue opened by Nicholas on making an In-built tutorial for
Micropython.

I would like to know about the views if the group on this. I can start
working on the issue once Nicholas gives the green signal from his side.

With Regards,

Sourav Singh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151129/eb581efd/attachment.html>

From ntoll at ntoll.org  Sun Nov 29 04:02:32 2015
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Sun, 29 Nov 2015 09:02:32 +0000
Subject: [Microbit-Python] Creating In-built tutorial for MicroPython
In-Reply-To: <CALpy4prpj3uxNQ8m=QL200dW5ruSyiUvQsMMdh9c6hV+ycOFVA@mail.gmail.com>
References: <CALpy4prpj3uxNQ8m=QL200dW5ruSyiUvQsMMdh9c6hV+ycOFVA@mail.gmail.com>
Message-ID: <565ABF28.1090406@ntoll.org>

Hi Sourav,

I'm up to my eyes in work *right now* but I promise to reply soon.

N.

On 29/11/15 08:27, Sourav Singh wrote:
> Hello,
> 
> I am Sourav Singh from India. I go by the Github username souravsingh
> 
> I saw an issue opened by Nicholas on making an In-built tutorial for
> Micropython.
> 
> I would like to know about the views if the group on this. I can start
> working on the issue once Nicholas gives the green signal from his side.
> 
> With Regards,
> 
> Sourav Singh
> 
> 
> 
> _______________________________________________
> 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: <http://mail.python.org/pipermail/microbit/attachments/20151129/457902fb/attachment.sig>

From mschafer at wireframe.biz  Sun Nov 29 04:48:39 2015
From: mschafer at wireframe.biz (Mark Schafer)
Date: Sun, 29 Nov 2015 22:48:39 +1300
Subject: [Microbit-Python] flashing the Microbit
Message-ID: <565AC9F7.1000700@wireframe.biz>

I've got my Ubuntu14.04 compiling using Yotta and I'm getting a hex file.
But I've looked and just can't find out how to get the newly built hex 
file onto the Microbit from Linux.

- On here it doesn't say:
      https://github.com/bbcmicrobit/micropython
- I've used dfutils (from windows) for the stm version of the hardware 
but I don't think that's going to work for the Microbit
- This page (https://github.com/bbcmicrobit/PythonEditor) suggests I can 
send it over on a serial connection if I install pyserial and determine 
which tty its on.
     - it also seems to be suggesting the .hex file is a hidden file 
(but I can't see it on the unit that arrived in the mail) when doing a 
directory listing on the Microbit plugged into windows..?

Where is this extra info - bound to be there - I just can't find it :(

Thanks, Mark...

From microbit at sheep.art.pl  Sun Nov 29 05:11:03 2015
From: microbit at sheep.art.pl (Radomir Dopieralski)
Date: Sun, 29 Nov 2015 11:11:03 +0100
Subject: [Microbit-Python] flashing the Microbit
In-Reply-To: <565AC9F7.1000700@wireframe.biz>
References: <565AC9F7.1000700@wireframe.biz>
Message-ID: <20151129111103.06b7b507@ghostwheel>

Hi Mark,

this is a bit unintuitive, indeed.

You see, when you connect micro:bit to the USB port of your computer,
it becomes visible as a serial port, but also as a storage device with
some files in there. You can read those files for basic help. You can
also simply copy the .hex file onto that storage device, to have it
uploaded as the new firmware. You will not see the file in there after
you copy it, though, because it's not really added to the filesystem --
hence people say it's hidden.

I hope that helps.

On Sun, 29 Nov 2015 22:48:39 +1300
Mark Schafer <mschafer at wireframe.biz> wrote:

> I've got my Ubuntu14.04 compiling using Yotta and I'm getting a hex
> file. But I've looked and just can't find out how to get the newly
> built hex file onto the Microbit from Linux.
> 
> - On here it doesn't say:
>       https://github.com/bbcmicrobit/micropython
> - I've used dfutils (from windows) for the stm version of the
> hardware but I don't think that's going to work for the Microbit
> - This page (https://github.com/bbcmicrobit/PythonEditor) suggests I
> can send it over on a serial connection if I install pyserial and
> determine which tty its on.
>      - it also seems to be suggesting the .hex file is a hidden file 
> (but I can't see it on the unit that arrived in the mail) when doing
> a directory listing on the Microbit plugged into windows..?
> 
> Where is this extra info - bound to be there - I just can't find it :(
> 
> Thanks, Mark...
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit


-- 
Radomir Dopieralski

From david at thinkingbinaries.com  Sun Nov 29 05:25:50 2015
From: david at thinkingbinaries.com (David Whale)
Date: Sun, 29 Nov 2015 10:25:50 +0000
Subject: [Microbit-Python] flashing the Microbit
In-Reply-To: <20151129111103.06b7b507@ghostwheel>
References: <565AC9F7.1000700@wireframe.biz>
 <20151129111103.06b7b507@ghostwheel>
Message-ID: <CABeH_SsobhEvqMevwBTWnj3Q6b=ApxbPVMjfS5eSkqks2zQAvw@mail.gmail.com>

Step 3 on this page explains how. Just copy the file either using the file
manager, or with a copy command.

https://www.microbit.co.uk/device/usb

The interface chip on the micro:bit emulates a filing system, it is not a
real filing system, hence you won't see the file that you copy onto the
device in most instances.

The device will auto-eject at the end of the programming process. Depending
which version of firmware you have (which breed of early access device you
have) you might have to press the reset button on the back to start the
code running.

It's a standard mbed device, so you can get more technical details here:

https://developer.mbed.org/handbook/Downloading-a-program

Hope this helps.

David


___________________________________________________________
David Whale, B.Sc (Hons), MIET
*Software Engineer and IET Schools Liaison Officer, Essex*

email:  dwhale at theiet.org
twitter: @whaleygeek
blog:  blog.whaleygeek.co.uk

Co-author of global bestselling book "Adventures in Minecraft"
<http://amzn.to/ZGfxZG> - lets get kids coding!
Now in English, Spanish, Chinese and Russian.


On 29 November 2015 at 10:11, Radomir Dopieralski <microbit at sheep.art.pl>
wrote:

> Hi Mark,
>
> this is a bit unintuitive, indeed.
>
> You see, when you connect micro:bit to the USB port of your computer,
> it becomes visible as a serial port, but also as a storage device with
> some files in there. You can read those files for basic help. You can
> also simply copy the .hex file onto that storage device, to have it
> uploaded as the new firmware. You will not see the file in there after
> you copy it, though, because it's not really added to the filesystem --
> hence people say it's hidden.
>
> I hope that helps.
>
> On Sun, 29 Nov 2015 22:48:39 +1300
> Mark Schafer <mschafer at wireframe.biz> wrote:
>
> > I've got my Ubuntu14.04 compiling using Yotta and I'm getting a hex
> > file. But I've looked and just can't find out how to get the newly
> > built hex file onto the Microbit from Linux.
> >
> > - On here it doesn't say:
> >       https://github.com/bbcmicrobit/micropython
> > - I've used dfutils (from windows) for the stm version of the
> > hardware but I don't think that's going to work for the Microbit
> > - This page (https://github.com/bbcmicrobit/PythonEditor) suggests I
> > can send it over on a serial connection if I install pyserial and
> > determine which tty its on.
> >      - it also seems to be suggesting the .hex file is a hidden file
> > (but I can't see it on the unit that arrived in the mail) when doing
> > a directory listing on the Microbit plugged into windows..?
> >
> > Where is this extra info - bound to be there - I just can't find it :(
> >
> > Thanks, Mark...
> > _______________________________________________
> > Microbit mailing list
> > Microbit at python.org
> > https://mail.python.org/mailman/listinfo/microbit
>
>
> --
> Radomir Dopieralski
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151129/16f21b5f/attachment-0001.html>

From microbit at sheep.art.pl  Sun Nov 29 05:30:52 2015
From: microbit at sheep.art.pl (Radomir Dopieralski)
Date: Sun, 29 Nov 2015 11:30:52 +0100
Subject: [Microbit-Python] flashing the Microbit
In-Reply-To: <CABeH_SsobhEvqMevwBTWnj3Q6b=ApxbPVMjfS5eSkqks2zQAvw@mail.gmail.com>
References: <565AC9F7.1000700@wireframe.biz>
 <20151129111103.06b7b507@ghostwheel>
 <CABeH_SsobhEvqMevwBTWnj3Q6b=ApxbPVMjfS5eSkqks2zQAvw@mail.gmail.com>
Message-ID: <20151129113052.22245184@ghostwheel>

By the way, I noticed that right after uploading the hex file, my device
will restart twice. Basically, it will start running the uploaded
program for a second or two, and then suddenly restart. Is that normal?
Should it behave like that? It only happens right after programming.


On Sun, 29 Nov 2015 10:25:50 +0000
David Whale <david at thinkingbinaries.com> wrote:

> Step 3 on this page explains how. Just copy the file either using the
> file manager, or with a copy command.
> 
> https://www.microbit.co.uk/device/usb
> 
> The interface chip on the micro:bit emulates a filing system, it is
> not a real filing system, hence you won't see the file that you copy
> onto the device in most instances.
> 
> The device will auto-eject at the end of the programming process.
> Depending which version of firmware you have (which breed of early
> access device you have) you might have to press the reset button on
> the back to start the code running.
> 
> It's a standard mbed device, so you can get more technical details
> here:
> 
> https://developer.mbed.org/handbook/Downloading-a-program
> 
> Hope this helps.

-- 
Radomir Dopieralski

From mschafer at wireframe.biz  Sun Nov 29 06:08:47 2015
From: mschafer at wireframe.biz (Mark Schafer)
Date: Mon, 30 Nov 2015 00:08:47 +1300
Subject: [Microbit-Python] flashing the Microbit
In-Reply-To: <CABeH_SsobhEvqMevwBTWnj3Q6b=ApxbPVMjfS5eSkqks2zQAvw@mail.gmail.com>
References: <565AC9F7.1000700@wireframe.biz>
 <20151129111103.06b7b507@ghostwheel>
 <CABeH_SsobhEvqMevwBTWnj3Q6b=ApxbPVMjfS5eSkqks2zQAvw@mail.gmail.com>
Message-ID: <565ADCBF.6020905@wireframe.biz>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151130/3262ad0f/attachment.html>

From david at thinkingbinaries.com  Sun Nov 29 08:57:39 2015
From: david at thinkingbinaries.com (David Whale)
Date: Sun, 29 Nov 2015 13:57:39 +0000
Subject: [Microbit-Python] flashing the Microbit
In-Reply-To: <20151129113052.22245184@ghostwheel>
References: <565AC9F7.1000700@wireframe.biz>
 <20151129111103.06b7b507@ghostwheel>
 <CABeH_SsobhEvqMevwBTWnj3Q6b=ApxbPVMjfS5eSkqks2zQAvw@mail.gmail.com>
 <20151129113052.22245184@ghostwheel>
Message-ID: <CABeH_Std=qkVGRsEkVhtxdAfhU3JBpq-WB7tE6eEF+NVortuCg@mail.gmail.com>

Depending which build of early access device you have, there is a bug in
the pre-loaded firmware on some of them, that causes the device to reset,
then after a few seconds reset again (but only after a download process).



___________________________________________________________
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 global bestselling book "Adventures in Minecraft"
<http://amzn.to/ZGfxZG> - lets get kids coding!
Now in English, Spanish, Chinese and Russian.


On 29 November 2015 at 10:30, Radomir Dopieralski <microbit at sheep.art.pl>
wrote:

> By the way, I noticed that right after uploading the hex file, my device
> will restart twice. Basically, it will start running the uploaded
> program for a second or two, and then suddenly restart. Is that normal?
> Should it behave like that? It only happens right after programming.
>
>
> On Sun, 29 Nov 2015 10:25:50 +0000
> David Whale <david at thinkingbinaries.com> wrote:
>
> > Step 3 on this page explains how. Just copy the file either using the
> > file manager, or with a copy command.
> >
> > https://www.microbit.co.uk/device/usb
> >
> > The interface chip on the micro:bit emulates a filing system, it is
> > not a real filing system, hence you won't see the file that you copy
> > onto the device in most instances.
> >
> > The device will auto-eject at the end of the programming process.
> > Depending which version of firmware you have (which breed of early
> > access device you have) you might have to press the reset button on
> > the back to start the code running.
> >
> > It's a standard mbed device, so you can get more technical details
> > here:
> >
> > https://developer.mbed.org/handbook/Downloading-a-program
> >
> > Hope this helps.
>
> --
> Radomir Dopieralski
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151129/0a9f598b/attachment-0001.html>

From mark at hotpy.org  Sun Nov 29 12:41:17 2015
From: mark at hotpy.org (Mark Shannon)
Date: Sun, 29 Nov 2015 17:41:17 +0000
Subject: [Microbit-Python] Connecting the microbit to a bread board.
Message-ID: <565B38BD.40108@hotpy.org>

Hi,

Does anyone know what component I need to expose all the pins on a bread 
board?
I'm imaging a female edge connector to male pin array thing,
but I don't know how to specify it, so I can't buy one :(

I don't want to rely on crocodile clips that are likely to come loose or 
short adjacent pins.

Cheers,
Mark.




From ntoll at ntoll.org  Sun Nov 29 12:45:25 2015
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Sun, 29 Nov 2015 17:45:25 +0000
Subject: [Microbit-Python] Connecting the microbit to a bread board.
In-Reply-To: <565B38BD.40108@hotpy.org>
References: <565B38BD.40108@hotpy.org>
Message-ID: <565B39B5.2030205@ntoll.org>

Hi Mark,

Tom Viner (cc'd) has one of these do-hickeys.

I'll see Tom on Thursday at the London Code Dojo. I can get it to you if
you like, or Tom could post it..?

N.


On 29/11/15 17:41, Mark Shannon wrote:
> Hi,
> 
> Does anyone know what component I need to expose all the pins on a bread
> board?
> I'm imaging a female edge connector to male pin array thing,
> but I don't know how to specify it, so I can't buy one :(
> 
> I don't want to rely on crocodile clips that are likely to come loose or
> short adjacent pins.
> 
> 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: <http://mail.python.org/pipermail/microbit/attachments/20151129/bcdb2175/attachment.sig>

From david at thinkingbinaries.com  Sun Nov 29 13:01:36 2015
From: david at thinkingbinaries.com (David Whale)
Date: Sun, 29 Nov 2015 18:01:36 +0000
Subject: [Microbit-Python] Connecting the microbit to a bread board.
In-Reply-To: <565B39B5.2030205@ntoll.org>
References: <565B38BD.40108@hotpy.org>
	<565B39B5.2030205@ntoll.org>
Message-ID: <CABeH_SswrBsCxU33rK4sDB43SLorPsbX+QwfNvB4r0sCuUSENw@mail.gmail.com>

Kitronik is the only supplier at the moment

https://www.kitronik.co.uk/5601-edge-connector-breakout-board.html

Same day delivery.

We've also had some success melting PCI connectors off of old motherboards
at MakerSpace, which is how we made our very first Mega:Bit.

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 global bestselling book "Adventures in Minecraft"
<http://amzn.to/ZGfxZG> - lets get kids coding!
Now in English, Spanish, Chinese and Russian.


On 29 November 2015 at 17:45, Nicholas H.Tollervey <ntoll at ntoll.org> wrote:

> Hi Mark,
>
> Tom Viner (cc'd) has one of these do-hickeys.
>
> I'll see Tom on Thursday at the London Code Dojo. I can get it to you if
> you like, or Tom could post it..?
>
> N.
>
>
> On 29/11/15 17:41, Mark Shannon wrote:
> > Hi,
> >
> > Does anyone know what component I need to expose all the pins on a bread
> > board?
> > I'm imaging a female edge connector to male pin array thing,
> > but I don't know how to specify it, so I can't buy one :(
> >
> > I don't want to rely on crocodile clips that are likely to come loose or
> > short adjacent pins.
> >
> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151129/773bd41e/attachment.html>

From mark at hotpy.org  Sun Nov 29 13:33:22 2015
From: mark at hotpy.org (Mark Shannon)
Date: Sun, 29 Nov 2015 18:33:22 +0000
Subject: [Microbit-Python] Connecting the microbit to a bread board.
In-Reply-To: <CABeH_SswrBsCxU33rK4sDB43SLorPsbX+QwfNvB4r0sCuUSENw@mail.gmail.com>
References: <565B38BD.40108@hotpy.org> <565B39B5.2030205@ntoll.org>
 <CABeH_SswrBsCxU33rK4sDB43SLorPsbX+QwfNvB4r0sCuUSENw@mail.gmail.com>
Message-ID: <565B44F2.7010201@hotpy.org>

Thanks,

Melting stuff off a motherboard sounds like a good way to inhale some 
carcinogens. I think I'll just buy one :)

Cheers,
Mark.

On 29/11/15 18:01, David Whale wrote:
> Kitronik is the only supplier at the moment
>
> https://www.kitronik.co.uk/5601-edge-connector-breakout-board.html
>
> Same day delivery.
>
> We've also had some success melting PCI connectors off of old
> motherboards at MakerSpace, which is how we made our very first Mega:Bit.
>
> D
>
>
> ___________________________________________________________
> David Whale, B.Sc (Hons), MIET
> *Software Engineer and IET Schools Liaison Officer, Essex*
>
> email: dwhale at theiet.org <mailto:dwhale at theiet.org>
> twitter: @whaleygeek
> blog: blog.whaleygeek.co.uk <http://blog.whaleygeek.co.uk>
>
> Co-author of global bestselling book "Adventures in Minecraft"
> <http://amzn.to/ZGfxZG> - lets get kids coding!
> Now in English, Spanish, Chinese and Russian.
>
>
> On 29 November 2015 at 17:45, Nicholas H.Tollervey <ntoll at ntoll.org
> <mailto:ntoll at ntoll.org>> wrote:
>
>     Hi Mark,
>
>     Tom Viner (cc'd) has one of these do-hickeys.
>
>     I'll see Tom on Thursday at the London Code Dojo. I can get it to you if
>     you like, or Tom could post it..?
>
>     N.
>
>
>     On 29/11/15 17:41, Mark Shannon wrote:
>      > Hi,
>      >
>      > Does anyone know what component I need to expose all the pins on
>     a bread
>      > board?
>      > I'm imaging a female edge connector to male pin array thing,
>      > but I don't know how to specify it, so I can't buy one :(
>      >
>      > I don't want to rely on crocodile clips that are likely to come
>     loose or
>      > short adjacent pins.
>      >
>      > Cheers,
>      > Mark.
>      >
>      >
>      >
>      > _______________________________________________
>      > Microbit mailing list
>      > Microbit at python.org <mailto:Microbit at python.org>
>      > https://mail.python.org/mailman/listinfo/microbit
>
>
>
>     _______________________________________________
>     Microbit mailing list
>     Microbit at python.org <mailto:Microbit at python.org>
>     https://mail.python.org/mailman/listinfo/microbit
>
>
>
>
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit
>

From tom at viner.tv  Sun Nov 29 16:42:09 2015
From: tom at viner.tv (Tom Viner)
Date: Sun, 29 Nov 2015 21:42:09 +0000
Subject: [Microbit-Python] Connecting the microbit to a bread board.
In-Reply-To: <565B39B5.2030205@ntoll.org>
References: <565B38BD.40108@hotpy.org> <565B39B5.2030205@ntoll.org>
Message-ID: <CANBSuyFBpMuQU+qB8beuhnn3_y82r=mDE9HXnsdkAc9oRpPRcw@mail.gmail.com>

>
> Tom Viner (cc'd) has one of these do-hickeys.


Not any more, I posted it along with Mei-Xui. Sorry if you'd wanted me to
pass it back to you directly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151129/13006dbc/attachment.html>

From ntoll at ntoll.org  Sun Nov 29 16:44:48 2015
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Sun, 29 Nov 2015 21:44:48 +0000
Subject: [Microbit-Python] Connecting the microbit to a bread board.
In-Reply-To: <CANBSuyFBpMuQU+qB8beuhnn3_y82r=mDE9HXnsdkAc9oRpPRcw@mail.gmail.com>
References: <565B38BD.40108@hotpy.org> <565B39B5.2030205@ntoll.org>
 <CANBSuyFBpMuQU+qB8beuhnn3_y82r=mDE9HXnsdkAc9oRpPRcw@mail.gmail.com>
Message-ID: <565B71D0.3080009@ntoll.org>

On 29/11/15 21:42, Tom Viner wrote:
>     Tom Viner (cc'd) has one of these do-hickeys.
> 
> 
> Not any more, I posted it along with Mei-Xui. Sorry if you'd wanted me
> to pass it back to you directly.

No problem. David W. gave us the link to buy one! ;-)

N.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/microbit/attachments/20151129/3b6e300b/attachment-0001.sig>

From damien.p.george at gmail.com  Sun Nov 29 16:51:08 2015
From: damien.p.george at gmail.com (Damien George)
Date: Sun, 29 Nov 2015 21:51:08 +0000
Subject: [Microbit-Python] flashing the Microbit
In-Reply-To: <CABeH_Std=qkVGRsEkVhtxdAfhU3JBpq-WB7tE6eEF+NVortuCg@mail.gmail.com>
References: <565AC9F7.1000700@wireframe.biz>
 <20151129111103.06b7b507@ghostwheel>
 <CABeH_SsobhEvqMevwBTWnj3Q6b=ApxbPVMjfS5eSkqks2zQAvw@mail.gmail.com>
 <20151129113052.22245184@ghostwheel>
 <CABeH_Std=qkVGRsEkVhtxdAfhU3JBpq-WB7tE6eEF+NVortuCg@mail.gmail.com>
Message-ID: <CANw+Mznd2+kUOgnmZQvVc0Yn0K9cOWs56=w8NKqNTnEU6hGRxg@mail.gmail.com>

If the hex file downloaded to the device then it should be working
(yes it should disappear after copying).

If you're on a Mac or Linux then you should get a tty USB device.  On
Windows you'll need to install a driver.

makecombinedhex.py is used to combine a firmware with a Python script,
which is then executed on start up:

python3 makecombinedhex.py firmware.hex myscript.py > firm.hex
cp firm.hex /mnt



On Sun, Nov 29, 2015 at 1:57 PM, David Whale <david at thinkingbinaries.com> wrote:
> Depending which build of early access device you have, there is a bug in the
> pre-loaded firmware on some of them, that causes the device to reset, then
> after a few seconds reset again (but only after a download process).
>
>
>
> ___________________________________________________________
> 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 global bestselling book "Adventures in Minecraft" - lets get
> kids coding!
> Now in English, Spanish, Chinese and Russian.
>
>
> On 29 November 2015 at 10:30, Radomir Dopieralski <microbit at sheep.art.pl>
> wrote:
>>
>> By the way, I noticed that right after uploading the hex file, my device
>> will restart twice. Basically, it will start running the uploaded
>> program for a second or two, and then suddenly restart. Is that normal?
>> Should it behave like that? It only happens right after programming.
>>
>>
>> On Sun, 29 Nov 2015 10:25:50 +0000
>> David Whale <david at thinkingbinaries.com> wrote:
>>
>> > Step 3 on this page explains how. Just copy the file either using the
>> > file manager, or with a copy command.
>> >
>> > https://www.microbit.co.uk/device/usb
>> >
>> > The interface chip on the micro:bit emulates a filing system, it is
>> > not a real filing system, hence you won't see the file that you copy
>> > onto the device in most instances.
>> >
>> > The device will auto-eject at the end of the programming process.
>> > Depending which version of firmware you have (which breed of early
>> > access device you have) you might have to press the reset button on
>> > the back to start the code running.
>> >
>> > It's a standard mbed device, so you can get more technical details
>> > here:
>> >
>> > https://developer.mbed.org/handbook/Downloading-a-program
>> >
>> > Hope this helps.
>>
>> --
>> Radomir Dopieralski
>> _______________________________________________
>> 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  Sun Nov 29 17:40:51 2015
From: david at thinkingbinaries.com (David Whale)
Date: Sun, 29 Nov 2015 22:40:51 +0000
Subject: [Microbit-Python] flashing the Microbit
In-Reply-To: <CANw+Mznd2+kUOgnmZQvVc0Yn0K9cOWs56=w8NKqNTnEU6hGRxg@mail.gmail.com>
References: <565AC9F7.1000700@wireframe.biz>
 <20151129111103.06b7b507@ghostwheel>
 <CABeH_SsobhEvqMevwBTWnj3Q6b=ApxbPVMjfS5eSkqks2zQAvw@mail.gmail.com>
 <20151129113052.22245184@ghostwheel>
 <CABeH_Std=qkVGRsEkVhtxdAfhU3JBpq-WB7tE6eEF+NVortuCg@mail.gmail.com>
 <CANw+Mznd2+kUOgnmZQvVc0Yn0K9cOWs56=w8NKqNTnEU6hGRxg@mail.gmail.com>
Message-ID: <CABeH_SsL2Hfch2SAAVHA-cyLffLpNp+Kxaqn7yP11F9GkpWXDQ@mail.gmail.com>

Also make sure you use the right baud rate and serial parameters:

115200,n,8,1



___________________________________________________________
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 global bestselling book "Adventures in Minecraft"
<http://amzn.to/ZGfxZG> - lets get kids coding!
Now in English, Spanish, Chinese and Russian.


On 29 November 2015 at 21:51, Damien George <damien.p.george at gmail.com>
wrote:

> If the hex file downloaded to the device then it should be working
> (yes it should disappear after copying).
>
> If you're on a Mac or Linux then you should get a tty USB device.  On
> Windows you'll need to install a driver.
>
> makecombinedhex.py is used to combine a firmware with a Python script,
> which is then executed on start up:
>
> python3 makecombinedhex.py firmware.hex myscript.py > firm.hex
> cp firm.hex /mnt
>
>
>
> On Sun, Nov 29, 2015 at 1:57 PM, David Whale <david at thinkingbinaries.com>
> wrote:
> > Depending which build of early access device you have, there is a bug in
> the
> > pre-loaded firmware on some of them, that causes the device to reset,
> then
> > after a few seconds reset again (but only after a download process).
> >
> >
> >
> > ___________________________________________________________
> > 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 global bestselling book "Adventures in Minecraft" - lets get
> > kids coding!
> > Now in English, Spanish, Chinese and Russian.
> >
> >
> > On 29 November 2015 at 10:30, Radomir Dopieralski <microbit at sheep.art.pl
> >
> > wrote:
> >>
> >> By the way, I noticed that right after uploading the hex file, my device
> >> will restart twice. Basically, it will start running the uploaded
> >> program for a second or two, and then suddenly restart. Is that normal?
> >> Should it behave like that? It only happens right after programming.
> >>
> >>
> >> On Sun, 29 Nov 2015 10:25:50 +0000
> >> David Whale <david at thinkingbinaries.com> wrote:
> >>
> >> > Step 3 on this page explains how. Just copy the file either using the
> >> > file manager, or with a copy command.
> >> >
> >> > https://www.microbit.co.uk/device/usb
> >> >
> >> > The interface chip on the micro:bit emulates a filing system, it is
> >> > not a real filing system, hence you won't see the file that you copy
> >> > onto the device in most instances.
> >> >
> >> > The device will auto-eject at the end of the programming process.
> >> > Depending which version of firmware you have (which breed of early
> >> > access device you have) you might have to press the reset button on
> >> > the back to start the code running.
> >> >
> >> > It's a standard mbed device, so you can get more technical details
> >> > here:
> >> >
> >> > https://developer.mbed.org/handbook/Downloading-a-program
> >> >
> >> > Hope this helps.
> >>
> >> --
> >> Radomir Dopieralski
> >> _______________________________________________
> >> 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: <http://mail.python.org/pipermail/microbit/attachments/20151129/33cf84ee/attachment.html>

From mschafer at wireframe.biz  Sun Nov 29 23:35:17 2015
From: mschafer at wireframe.biz (Mark Schafer)
Date: Mon, 30 Nov 2015 17:35:17 +1300
Subject: [Microbit-Python] flashing the Microbit
In-Reply-To: <CABeH_SsL2Hfch2SAAVHA-cyLffLpNp+Kxaqn7yP11F9GkpWXDQ@mail.gmail.com>
References: <565AC9F7.1000700@wireframe.biz>
 <20151129111103.06b7b507@ghostwheel>
 <CABeH_SsobhEvqMevwBTWnj3Q6b=ApxbPVMjfS5eSkqks2zQAvw@mail.gmail.com>
 <20151129113052.22245184@ghostwheel>
 <CABeH_Std=qkVGRsEkVhtxdAfhU3JBpq-WB7tE6eEF+NVortuCg@mail.gmail.com>
 <CANw+Mznd2+kUOgnmZQvVc0Yn0K9cOWs56=w8NKqNTnEU6hGRxg@mail.gmail.com>
 <CABeH_SsL2Hfch2SAAVHA-cyLffLpNp+Kxaqn7yP11F9GkpWXDQ@mail.gmail.com>
Message-ID: <565BD205.6050807@wireframe.biz>

OK making progress again.
Found my terminal, settings, and talking to the unit over serial.

- dmesg revealed the tty was called ttyACM0
     - dmesg | grep tty

I used "sudo apt-get gtkterm" because looks like no serial terms are 
included in distro
Luckily ACM0 also showed up on the list of possible terms in this program.
So I think its possibly a generally useful solution for everyone.

Thanks for the settings David.
Now I have a prompt.

Overall I am surprised at how hard this all was and glad I documented it.
Mark...



From ntoll at ntoll.org  Mon Nov 30 02:18:19 2015
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Mon, 30 Nov 2015 07:18:19 +0000
Subject: [Microbit-Python] flashing the Microbit
In-Reply-To: <565BD205.6050807@wireframe.biz>
References: <565AC9F7.1000700@wireframe.biz>
 <20151129111103.06b7b507@ghostwheel>
 <CABeH_SsobhEvqMevwBTWnj3Q6b=ApxbPVMjfS5eSkqks2zQAvw@mail.gmail.com>
 <20151129113052.22245184@ghostwheel>
 <CABeH_Std=qkVGRsEkVhtxdAfhU3JBpq-WB7tE6eEF+NVortuCg@mail.gmail.com>
 <CANw+Mznd2+kUOgnmZQvVc0Yn0K9cOWs56=w8NKqNTnEU6hGRxg@mail.gmail.com>
 <CABeH_SsL2Hfch2SAAVHA-cyLffLpNp+Kxaqn7yP11F9GkpWXDQ@mail.gmail.com>
 <565BD205.6050807@wireframe.biz>
Message-ID: <565BF83B.6040407@ntoll.org>

Mark,

I appreciate you taking the pain of setting all this up. It's very
helpful simply because it's hard for us (who have it set up already) to
appreciate the steps required and assumptions made.

This will not be in vain! We'll fold it back into the documentation!

At least you're not on Windows! Now *that* is hard work to get set up.

Best wishes,

Nicholas.

On 30/11/15 04:35, Mark Schafer wrote:
> OK making progress again.
> Found my terminal, settings, and talking to the unit over serial.
> 
> - dmesg revealed the tty was called ttyACM0
>     - dmesg | grep tty
> 
> I used "sudo apt-get gtkterm" because looks like no serial terms are
> included in distro
> Luckily ACM0 also showed up on the list of possible terms in this program.
> So I think its possibly a generally useful solution for everyone.
> 
> Thanks for the settings David.
> Now I have a prompt.
> 
> Overall I am surprised at how hard this all was and glad I documented it.
> 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: <http://mail.python.org/pipermail/microbit/attachments/20151130/5468bfe4/attachment-0001.sig>

From microbit at sheep.art.pl  Mon Nov 30 03:11:55 2015
From: microbit at sheep.art.pl (Radomir Dopieralski)
Date: Mon, 30 Nov 2015 09:11:55 +0100
Subject: [Microbit-Python] flashing the Microbit
In-Reply-To: <565BD205.6050807@wireframe.biz>
References: <565AC9F7.1000700@wireframe.biz>
 <20151129111103.06b7b507@ghostwheel>
 <CABeH_SsobhEvqMevwBTWnj3Q6b=ApxbPVMjfS5eSkqks2zQAvw@mail.gmail.com>
 <20151129113052.22245184@ghostwheel>
 <CABeH_Std=qkVGRsEkVhtxdAfhU3JBpq-WB7tE6eEF+NVortuCg@mail.gmail.com>
 <CANw+Mznd2+kUOgnmZQvVc0Yn0K9cOWs56=w8NKqNTnEU6hGRxg@mail.gmail.com>
 <CABeH_SsL2Hfch2SAAVHA-cyLffLpNp+Kxaqn7yP11F9GkpWXDQ@mail.gmail.com>
 <565BD205.6050807@wireframe.biz>
Message-ID: <20151130091155.43abe9b4@ghostwheel>

Almost every distro has "screen" included, which has a serial term.
Just run:

$ screen /dev/ttyACM0 115200

in a terminal. To exit, do "ctrl+a" and then press "K".


On Mon, 30 Nov 2015 17:35:17 +1300
Mark Schafer <mschafer at wireframe.biz> wrote:

> OK making progress again.
> Found my terminal, settings, and talking to the unit over serial.
> 
> - dmesg revealed the tty was called ttyACM0
>      - dmesg | grep tty
> 
> I used "sudo apt-get gtkterm" because looks like no serial terms are 
> included in distro
> Luckily ACM0 also showed up on the list of possible terms in this
> program. So I think its possibly a generally useful solution for
> everyone.
> 
> Thanks for the settings David.
> Now I have a prompt.
> 
> Overall I am surprised at how hard this all was and glad I documented
> it. Mark...

-- 
Radomir Dopieralski

From martin at ohanlonweb.com  Mon Nov 30 09:00:55 2015
From: martin at ohanlonweb.com (Martin O'Hanlon)
Date: Mon, 30 Nov 2015 14:00:55 +0000
Subject: [Microbit-Python] Bluetooth Access?
Message-ID: <CAD64x+bZvh-BC327KgKQy1cEu9isxmbcwboUj8XKs62BmFmYtQ@mail.gmail.com>

Can I access the Bluetooth functions on the MicroBit? If I can, how can I?
If I cant, could I?

-- 

Blog - www.stuffaboutcode.com

Twitter - @martinohanlon
<http://twitter.com/intent/user?screen_name=martinohanlon>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20151130/b6de2d03/attachment.html>

From ntoll at ntoll.org  Mon Nov 30 09:09:10 2015
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Mon, 30 Nov 2015 14:09:10 +0000
Subject: [Microbit-Python] Bluetooth Access?
In-Reply-To: <CAD64x+bZvh-BC327KgKQy1cEu9isxmbcwboUj8XKs62BmFmYtQ@mail.gmail.com>
References: <CAD64x+bZvh-BC327KgKQy1cEu9isxmbcwboUj8XKs62BmFmYtQ@mail.gmail.com>
Message-ID: <565C5886.6080302@ntoll.org>

Hi Martin,

The answer are:

* No you can't yet. This is because BLE imposes memory constraints that
make it hard to use Python (apparently the BLE stack takes up 12k of the
16k RAM).

* Damien has a genius plan for how we might get around this. I'll let
him describe it.

* As far as I can tell, there's not a lot you can usefully do with BLE
*right now* - given some onerous flash memory constraints that we've
already exceeded you could re-flash the device.

Sorry. :-(

N.

On 30/11/15 14:00, Martin O'Hanlon wrote:
> Can I access the Bluetooth functions on the MicroBit? If I can, how can
> I? If I cant, could I?
> 
> -- 
> 
> Blog - www.stuffaboutcode.com <http://www.stuffaboutcode.com>
> 
> Twitter - @martinohanlon
> <http://twitter.com/intent/user?screen_name=martinohanlon>
> 
> 
> 
> _______________________________________________
> 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: <http://mail.python.org/pipermail/microbit/attachments/20151130/5c57d72c/attachment.sig>

From damien.p.george at gmail.com  Mon Nov 30 09:38:45 2015
From: damien.p.george at gmail.com (Damien George)
Date: Mon, 30 Nov 2015 14:38:45 +0000
Subject: [Microbit-Python] Bluetooth Access?
In-Reply-To: <565C5886.6080302@ntoll.org>
References: <CAD64x+bZvh-BC327KgKQy1cEu9isxmbcwboUj8XKs62BmFmYtQ@mail.gmail.com>
 <565C5886.6080302@ntoll.org>
Message-ID: <CANw+MzkiFfZ5Ek_-PQAb0=K0vC11VfV96-Erd3htGYfSzvDnzA@mail.gmail.com>

Martin, what BLE features are you interested in?

As Nicholas said, MicroPython can't currently expose the underling BLE
features.  It's something we are working on!

On Mon, Nov 30, 2015 at 2:09 PM, Nicholas H.Tollervey <ntoll at ntoll.org> wrote:
> Hi Martin,
>
> The answer are:
>
> * No you can't yet. This is because BLE imposes memory constraints that
> make it hard to use Python (apparently the BLE stack takes up 12k of the
> 16k RAM).
>
> * Damien has a genius plan for how we might get around this. I'll let
> him describe it.
>
> * As far as I can tell, there's not a lot you can usefully do with BLE
> *right now* - given some onerous flash memory constraints that we've
> already exceeded you could re-flash the device.
>
> Sorry. :-(
>
> N.
>
> On 30/11/15 14:00, Martin O'Hanlon wrote:
>> Can I access the Bluetooth functions on the MicroBit? If I can, how can
>> I? If I cant, could I?
>>
>> --
>>
>> Blog - www.stuffaboutcode.com <http://www.stuffaboutcode.com>
>>
>> Twitter - @martinohanlon
>> <http://twitter.com/intent/user?screen_name=martinohanlon>
>>
>>
>>
>> _______________________________________________
>> 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
>