[Microbit-Python] Game API objects I want

[Damien George]

We can't use fibers in MicroPython because there is not enough RAM to
swap the stack out.  The best we can do is run the system tick handler
on an interrupt, or the idle handlers within the same stack as the
main fiber (and only to run C-level code, not Python code).

We have discussed tasks/fibers/multitasking a few times already and I
think the consensus is that MicroPython will expose a pure sequential
execution model.  Anything more than that is too difficult considering
the target audience, and also not necessary.

We can of course do event scheduling in pure Python, or even with some
help from C-land for efficiency.  Larry's proposed Scheduler class is,
I think, a great idea and does not introduce complexity of
multitasking.

Please see https://github.com/dpgeorge/microbit-micropython/issues/36
for further discussion on this topic.


On Fri, Oct 9, 2015 at 11:30 PM, Finney, Joe <j.finney at lancaster.ac.uk> wrote:
> Hi Folks,
>
> If I understand what you're after correctly, you're looking to schedule some work to be done in the future (either as a one shot or recurring condition). Normally, most folks have done this as Jonny has described - just launch a fiber and perform a sleep, and put this in a loop for a recurring condition.
>
> Having functionality to scheduke a callback in the future would be quite compelling though, as it's a very clean abstraction and provides a more absolute notion of time compared to the approach above, and it's not very hard to achieve. We don't have any specific APIs for this at the moment, but some of the underlying mechanisms (fiber scheduler + message bus/eventing) should make this fairly straightforward to implement.
>
> The easiest way to do this on top of the micro:bit DAL API would be to write our handler as a standard message bus listener, and register it with the message bus to receive  user defined event. This will handle all the callback functionality for you, and support multiple callbacks on the same event timer.
> e.g.
>
> void work_callback(MicroBitEvent e)
> {
>         // do stuff.
> }
>
> We could then write  a function or two for the fiber scheduler that keep queue of times at which to send events (there are wait queue much like this in there already). Then, during the period fiber scheduler timer interrupt, fire off the appropriate event which then triggers the event handler.
>
> If you think this would add value for you guys, do shout and we'll see if we can help out.
>
> p.s. I don't always have time to read all the mailing lists I'm on I'm afraid - if you want to grab me, please just cite my github username @finneyj in the email somewhere, and it'll get flagged up in my inbox. :-)
>
> best,
> joe
>
>
> -----Original Message-----
> From: Microbit [mailto:microbit-bounces+j.finney=lancaster.ac.uk at python.org] On Behalf Of Jonathan Austin
> Sent: 09 October 2015 13:21
> To: For Pythonic MicroBit related disucssions
> Subject: Re: [Microbit-Python] Game API objects I want
>
>
>> On 9 Oct 2015, at 05:04, Larry Hastings <larry at hastings.org> wrote:
>>
>>>
>>> Joe has a Fiber scheduler in there, and it might be possible just to
>>> break out bits from that.
>>>
>>
>> I don't think I have access to that repository.
>
> Hmm. Nicholas, Joe - is there a reason for that?
>
>>
>> Unless they're using the terminology in a different way, a Fiber is a completely unrelated concept to an event scheduler.  It's a user-scheduled thread, or a continuation, kind of like Python's "yield".
>
> I'll let Joe comment more as he wrote all this - you're right of course that the fibres alone aren't going to get you the timed events, but I thought that along with the scheduler was a way to request that some work got done in a fiber after some time.
>
> I had a poke though, and can't immediately see that... What I'd like is something that can do:
>
> fibersched.schedule_work(&work_callback, delay); fibersched.recurring_work(&work_callback, period);
>
> But instead it looks like the expected approach is to do something more like spawn a fiber and then sleep (which sleeps gracefully assuming you're not in interrupt context), or spawn a fiber that waits for an event on the bus...
>
> Joe - what's the 'right' way to do that in the runtime at the moment?
>
>>> Failing that, mbed has a Ticker and a Timeout class,
>>>
>>>
>>> https://developer.mbed.org/handbook/Ticker
>>> https://developer.mbed.org/handbook/Timeout
>>
>> These are also not-exactly related.  Those are both interrupt-driven callback functions.  Theoretically they could be mis-used for this ability.  But note the provisos: "no blocking code", "no print / malloc".  I suspect it's impossible to do anything useful in Python in an ISR.
>>
>
> Right, the way people usually build something like the scheduler you describe is to use these  classes to schedule work that gets done in the main thread, so those provisos don't matter - IE you use the ticker/timeout to adding things to a work queue.
>
> there's a nice writeup that implements this on mbed here:
> https://developer.mbed.org/users/AjK/notebook/regarding-interrupts-use-and-blocking/
>
> J
>>
>> /arry
>> _______________________________________________
>> 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