random methods always return 0 unless preceeded by a call to seed.

[MrYsLab]

When invoking a random method, if seed is not invoked, the random method always returns zero.

The neopixel example (http://microbit-micropython.readthedocs.io/en/latest/neopixel.html#example) as written does not work and iillustrates the problem. Adding a call to seed fixes the example.

Here is a modified example that works. It lights one neopixel at a time.

from microbit import *
import neopixel
from random import seed, randint

# Setup the Neopixel strip on pin0 with a length of 8 pixels
np = neopixel.NeoPixel(pin0, 8)
np.clear()
seed(3)
sleep(1000)

while True:
    #Iterate over each LED in the strip

    for pixel_id in range(0, len(np)):
        red = randint(0, 60)
        green = randint(0, 60)
        blue = randint(0, 60)

        # Assign the current LED a random red, green and blue value between 0 and 60
        np[pixel_id] = (red, green, blue)

        # Display the current pixel data on the Neopixel strip
        np.show()
        sleep(500)
        np.clear()

[carlosperate]

Hi @MrYsLab

Could you create a small program to reproduce the issue?

I've tried the following on MicroPython v0.9 and v1.0b and it doesn't need to be seeded with a specific value to get non-zero values:

from random import randint

for x in range(10):
    print(randint(0, 60))

[MrYsLab]

I just retested the program below using the Beta Web editor, the version of uflash from pypi and Mu and only the version created by the Beta Web editor works.

"""
    neopixel_random.py

    Repeatedly displays random colours onto the LED strip.
    This example requires a strip of 8 Neopixels (WS2812) connected to pin0.

"""
from microbit import *
import neopixel
from random import randint

# Setup the Neopixel strip on pin0 with a length of 8 pixels
np = neopixel.NeoPixel(pin0, 8)

while True:
    #Iterate over each LED in the strip

    for pixel_id in range(0, len(np)):
        red = randint(0, 60)
        green = randint(0, 60)
        blue = randint(0, 60)

        print(red)

        # Assign the current LED a random red, green and blue value between 0 and 60
        np[pixel_id] = (red, green, blue)

        # Display the current pixel data on the Neopixel strip
        np.show()
        sleep(100)

In addition, on an unrelated issue using the code below, if I load the code from the Beta Web Editor, I get the following error, but the error does not appear using Mu or pypi uflash.

AttributeError: 'MicroBitDigitalPin' object has no attribute 'set_pull'

from microbit import *

pin8.set_pull(pin8.PULL_UP)

I know you folks are working hard and I appreciate the efforts, but it would be very helpful if all 3 ways of creating a hex file would produce consistent results.

[DavidWhaleMEF]

The Beta editor is, as it says, Beta. Thus it has new features in it that are not yet released in live. set_pull is something that is included in the beta release, that did not make it into the live releases that are embedded into the live web editor and the live codewith.mu editors. There was an error in the tagging of the docs that @carlosperate fixed for me last week, where it was showing newer docs than the code that was released in the live editors, and this was causing some confusion. We moved the tag on the docs to rectify it, so docs are now in step with live code. The most notable difference in that was set_pull missing from the live editors.

set_pull in particular has been 'fixed in master' for months, but nobody has had the bandwidth to test all the 'master fixes' thoroughly enough to do a new release to live. That's what we are working on at the moment. But there won't be a release to all live editors until testing is complete. If you are able to test on Beta and feed back here any bugs you find, that will be marvellous and will help the greater cause, thanks!

Our core user base, school teachers, prefer stability over innovation generally, so we are prioritising testing new features rather than banging them out quickly and breaking their existing code.

Thanks for your feedback.

[DavidWhaleMEF]

P.S. @MrYsLab PyMata looks awesome, I'm going to have a good look at that when I get a chance!

[MrYsLab]

I am not sure if this issue should be left open or closed, I will leave the decision up to you.

I need some guidance as to whether or not the Pypi version of uflash should be used at this time. I am pulling it in for pseudo-microbit when using PyCharm to manage micro:bit development

@DavidWhaleMEF If you have any questions about PyMata, just shoot me an email. You might also want to take a look at (shameless self-promotion here) python-banyan with full user guide documentation. I have a version available for JavaScript, Ruby, and Java as well, but have not had the time to document those so they are not yet published. Developing on one language platform allows you to interact with another language platform seamlessly.

[ntoll]

Hi,

So @dpgeorge is awaiting email instructions from @jaustin (and has been for quite a number of weeks) for how to progress the work that will fix this. @DavidWhaleMEF please give Jonny a polite kick to get things moving. :-/

As far as I can tell, development on MicroPython on the micro:bit is stalled as a result.

N.

[jaustin]

@microbit-carlos and I were talking about this today - I've just reached out to @dpgeorge to sort out the next steps. At the moment the beta testing is working well, but we need to get more eyes on it too - thanks @MrYsLab for trying it!

Certainly we can't make a new release until we've tested the current beta build dropped into all the associated tools - so we'll ned to work out the right way to do that, which I think means a widely available beta of Mu and uFlash too.

[dpgeorge]

As has been pointed out, this is fixed in the version1 branch, which is pending merge into master. Let's leave this issue open until such a merge is made.

[dpgeorge]

Fixed in merge of version1 branch at e26d7c89d4a96de0fa0a1dd5aec024b31fc4816e