[Microbit-Python] How does GC work in micro:bit MicroPython?

[Damien George]

> My plan, at least initially, was to keep the internal implementation details a secret from MicroPython.  The MP object stores a pointer to an opaque type (scheduler_t, etc) which is managed in my implementation.

This is entirely feasible: if you're writing sheduler_t in C (not C++)
then just use m_malloc instead of malloc to allocate your data and
it'll go on the GC heap.  Just be sure to keep a root pointer to it
somewhere (if you store the pointer in a micropython object then
that's good enough).

On Mon, Oct 12, 2015 at 9:52 AM, Larry Hastings <larry at hastings.org> wrote:
>
> On 10/12/2015 01:36 AM, Mark Shannon wrote:
>
> You'll need to make your button minder a MicroPython object anyway, so it
> should be allocated on the MicroPython heap instead.
>
>
> My plan, at least initially, was to keep the internal implementation details
> a secret from MicroPython.  The MP object stores a pointer to an opaque type
> (scheduler_t, etc) which is managed in my implementation.  This makes
> debugging my classes on my Linux desktop feasible.
>
> I wouldn't mind merging my objects irrevocably into MicroPython objects once
> everything is completely settled.
>
>
> OOI, would it be possible to add the additional functionality to the
> pre-existing button object?
>
>
> The thing is, there's a bit of logic in there that I don't know if we want
> to stain the button object with.  My button minder can handle watching three
> buttons for you: A, B, and "both".  Handling "both" means incurring a slight
> delay before recognizing a solo button press on A or B, because humans are
> slow.  Recognizing "both" is optional, and if you don't have it turned on
> there's no delay.
>
> If we don't mind permanently incurring that delay, I could add a
> was_pressed() method to button_a and button_b, and add a separate
> button_both (button_ab?) object that behaved like a virtual both-buttons
> button.
>
> FYI we could make it so the delay only affected was_pressed(), is_pressed()
> could still report in real-time.
>
> In case you haven't looked at it, the rationale and API for my three objects
> is all up on the Bitbucket page.  That URL again:
>
> https://bitbucket.org/larry/microbit_game
>
>
> Perhaps a list of custom events objects would be more efficient.
> Whether custom object or tuple, it should be MicroPython objects all the way
> down :)
>
>
> A MicroPython list of custom event objects might be many things, but "more
> efficient" I sincerely doubt.  My current implementation has a packed C
> array of structs.  How could a MicroPython list of custom event objects
> possibly be more efficient, in any measurable dimension?
>
> The Scheduler object really just contains that list of events.  So I
> wouldn't mind making it a subclass of the MP list, if that'd work... would
> it?  It really just needs a couple of extra methods on top of what list
> already provides.  Failing is-a, we're back to has-a, which is where we
> started.
>
>
> /arry
>
>
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit
>