Erroneous exceptions and variable corruption

[rhubarbdog]

i have written a multi-player client server game called Two Weeks it's a clone of fortnight. The repositorty is https://github.com/rhubarbdog/microbit-two-weeks

sometimes micropython crashes throwing an exception which cannot be true, one is

TypeError: exceptions must derive from BaseException but the line of code is display.show(Image.SAD_FACE)

another reads something like

ValueError: 'int' object can not be indexed but in the line of code refers to a tuple.

when i run a multi player version of Two Weeks the client and server assume each other's id, i'm yet to see the bug it may be hardware.
Pressing up and down on the controller seemed to change the variable player in the client

[rhubarbdog]

This function called from a second function

def plot(xxx, yyy, ilume):
    print(xxx, yyy, ilume)
    display.set_pixel(xxx, yyy, ilume)

causes this error

  File "main.py", line 187, in <module>
  File "main.py", line 134, in draw_screen
  File "main.py", line 51, in plot
AttributeError: 'int' object has no attribute 'set_pixel'

line 51 is display.set_pixel the values of xxx, yyy and ilume are 0,0 and 1

I've discovered the bug in my Two weeks client server game it was programmer-error please ignore the last 3 lines of my previous comment

[rhubarbdog]

I'm looking like a bit of an idiot here as ignore my previous post.
i found that error i accidentally declared a variable display

I still stand by my initial post, as here is another weird one

Traceback (most recent call last):
  File "main.py", line 194, in <module>
TypeError: tuple indices must be integers, not MicroBitCompass

the line of code is

display.show(Image.ALL_CLOCKS[compass])

[martinwork]

I didn't spot it either, but this error message has a clue! compass == microbit.compass.

[carlosperate]

As Martin mentions (thanks!), the problem is the clashing of the compass instance created with from microbit import *:
https://github.com/rhubarbdog/microbit-two-weeks/blob/5816fe9fcb3a81eb092a724a873d6c5884328a5e/game.py#L6

And then creating the compass variable:
https://github.com/rhubarbdog/microbit-two-weeks/blob/5816fe9fcb3a81eb092a724a873d6c5884328a5e/game.py#L136

So display.show(Image.ALL_CLOCKS[compass]) is esentially doing the same as this:

import microbit
microbit.display.show(Image.ALL_CLOCKS[microbit.compass])

[rhubarbdog]

Yeah thanks for the bug fix.
The problem is I have somany screen variables that I stupidly used pseudonym display
I stopped that microbiology compass non sense by setting compass to None in an initialisation step.
It's kinda cool in python that you can just reuse a variable name like temp and change its type, but it allows you to snooker yourself so easily. Warnings like 'do you really want to have variable compass when importing from module microbit` wouldn't be that difficult but i didn't write the python language definition.

Now I've demonstrated how easy it is to look like an idiot, perhaps that error about int index index and tuple is me making a stupid reuse of a variable. I knew I may break micropython and not be able to get a client server game going. In version 1 my screen was a list of 1 hundred strings each of 100 characters like 40kb but it was showing good promiss I've had to use a byte array now as I was experiencing memory allocation problems.

The issue with the other two messages which I think i've forced out of micropython will be so hard to reproduce because it is very asynchronous sending radio packets of button presses and receiving a new screen back.

Except for @dpgeorge seeing that when micropyton has many modules imported (math, radio, random, music and some of microbit) on a really small system there may be a bit of error corruption and weird crashes that pressing reset may solve but a re-flash always does work, so their may be some corruption on packets that microFS is transferring but the checksum is also damaged, but because it can be like that the checksum of the new data is equal to the corrupted checksum.

[microbit-carlos]

when micropyton has many modules imported (math, radio, random, music and some of microbit) on a really small system there may be a bit of error corruption and weird crashes that pressing reset may solve but a re-flash always does work, so their may be some corruption on packets that microFS is transferring but the checksum is also damaged, but because it can be like that the checksum of the new data is equal to the corrupted checksum.

I didn't quite understand this one? Is the issue transferring files via microFS when the micro:bit is running a Python programme with many imports?

[dpgeorge]

The internal MicroPython VM and runtime are very robust, there should not be any corruption or errors no matter how many modules are imported. In the worst case it will just give a MemoryError if it runs out of resources.

sometimes micropython crashes throwing an exception which cannot be true, one is

TypeError: exceptions must derive from BaseException but the line of code is display.show(Image.SAD_FACE)

This is an interesting error... can you give more context and describe in more detail how it comes about? Did you press ctrl-C to stop the running program?