Python 3.8 - alpha release

This isn’t the right place for this. But is there a right place? It seems to be the best kept secret on the Internet. If there is a right place, please link it?

Doug: 11.6" Pinebook. First batch of Pinebook 1080.

I dug out the RO stuff for my Pi3 to try this out. Nice work! For fun I tried bootstrapping pip. Didn’t work. Wasn’t expecting it to. Speaking of functionality; if something approximating WiringPi worked with it, it’d probably be way easier to use than fighting with Linux to do it.

Yes, I’m working towards getting pip to work. I’ve currently managed to get setuptools to “install”, but running pip falls over because the subprocess stuff is somewhat .. “lacking” at the moment.

There is a fair amount of “yak shaving” going on but it will hopefully make python more “complete”.

I think RISC OS on the Pi has access to the GPIO so i guess a WiringPi-like thing would be possible.

It’d be great if you did get it working, but I certainly won’t hold you to it. I believe the RPi has access to GPIO the right way. I certainly know it has access the wrong way :)

There is something that I wanted to mention. You have ported a newer version of python than I have available on anything else. That’s really something!

Is anyone looking at using GPIO via Python on RISC OS? I’ve got a “quick and dirty” version of the RPi.GPIO library written so I can use some of my LED boards using the original supplied Python libraries for them, but I’m learning Python as I go, so probably not the best quality code, plus the GPIO module doesn’t appear to support all the features offered by the RPi.GPIO library.

Whilst doing this, I’ve discovered that time.sleep() only appears to take integer values, whereas lots of example code uses decimal, eg. time.sleep(0.5) to pause for half a second. Currently this pauses for 0sec as 0.5 is round down to an integer. Is this a bug, a feature or am I misunderstanding how it works?

Google says the value is in seconds, and it can be either an int or a float (so 0.2 is valid).

https://www.pythoncentral.io/pythons-time-sleep-pause-wait-sleep-stop-your-code/

Yes the official Python docs seem to say this too, just wondered if I was missing something why the RISC OS Python 3.8.0Alpha4 seems to only work in integer values. I realise this is only an Alpha release so will have some peculiarities.

So it does. I’ve just had a very quick look. It uses select() to do the sleeping on non-windows platforms. I’ve stuck some printfs around the call and it seems to ignore the tv_usec part of the struct. So even 0.99 gives no wait, 1.99 gives 1 second etc.

Having looked at it, it looks like the unixlib ‘select’ function calculated the end time wrongly. The usec part seems to be converted to seconds (so always zero) rather than centiseconds (which I am assuming it needs given it multiplies the sec part by 100).

Not such a quick look then. I will have a think of a way to work around it, and I guess see if it’s listed as a bug in unixlib.

Yes I’m still working on python and getting pip to work. I’ve had lots of fun and games with PipeFS trying to get the subprocess stuff to work…

Thanks, glad it wasn’t me getting it wrong! On the subject of time, time_ns() only appear to give centisecond resolution too, is there any chance of it giving a higher resolution at some point?

I think I’ve fixed the fractional second sleep here, at least withing the accuracy of the monotonic timer (ie. centiseconds). I’ll have a think about time_ns. I think RISC OS internally uses centisecond timer, but a more accurate one may be available now.

Excellent, thanks!
I’m not sure if the OS_MonotonicTime64 SWI ever made it off the drawing board, but in the absence of that it might be worth looking at Druck’s TimerMod to see how it implemnents microsecond timing.

OS_MonotonicTime64

I don’t think it did.

to see how it implemnents microsecond timing

Off the top of my head (or maybe from the other end ;-) ), one could query the hardware timer via HAL call (OS_Hardware something or other), query what the timer rate is ¹, do a bit of maths to work out what the value will be for the delay, then simply keep reading the timer value until the delay expires?

That said – are there actual code examples that would run on RISC OS where centisecond timing isn’t good enough?

¹ It’s normally something like 2MHz isn’t it?

I’m not sure if the OS_MonotonicTime64 SWI ever made it off the drawing board

It’s still taunting me from the shadows. I’ll probably have a go at implementing it soon, since there are a couple of things I’d like to do which would be easier if we had an easy to use high resolution timer.

but in the absence of that it might be worth looking at Druck’s TimerMod to see how it implemnents microsecond timing.

Using TimerMod is probably more sensible than reimplementing what it does within Python/UnixLib. There’s also ROL’s Timer module.

Arguably TimerMod should be extended to support ROL’s Timer module (and OS_ReadMonotonicTime64, once implemented), to make it a one-size-fits-all solution for high resolution timing.

https://www.riscosopen.org/wiki/documentation/show/HAL%20counter%20API

There’s a counter that repeatedly counts down at a high speed. Might be worth looking at that?

The problem with the timer is that things may claim it for their own use, which might cause issues with using it. The MIDI module, for example, tries to claim and use Timer1.

That said – are there actual code examples that would run on RISC OS where centisecond timing isn’t good enough?

My LED cube needs to have timing to greater than centisecond. Running at “full speed” makes it look very flickery, but having centisceond pauses between layers means you can see it being built up. I have pauses of approx 600us between layers :)

The problem with the timer is that things may claim it for their own use, which might cause issues with using it.

Hence the suggestion to use TimerMod

A little late in reply:

Doug: 11.6" Pinebook. First batch of Pinebook 1080.

Tristan , no where did I say first batch I just stated that the 11.6 version does 1920x 1080 which it does currently but agree the early batches did not support that screen resolution.

Apologies if I’ve missed this being discussed, but are there any hardware limitations for the port of Python 3?

It runs fine on a Titanium, assuming I install the required SharedLibs, but on RPCEmu (running RISC OS 5.27) I get

Fatal Python error: _Py_HashRandomization_Init: failed to get random numbers to initialize Python
Python runtime state: preinitialized

Is this something that’s missing from the RiscPC (or RPCEmu) platform, or have I missed something that was installed on the other system?

Not sure if this is the right thread for Python general support, but here goes:
if I set up a block using

import swi
from swi import block
b = block(1)

@Steve: Oddly, it works on my RPCEmu setup. It’s a pretty basic install. I wondered if it was a lack of shared library .. what does *SOStatus tell you? I get..

*SOMStatus
Number of libraries registered: 5

Idx Text from Text to Data from Data to Library name
1 0×3B390018 0×3B397D30 0×3B397D30 0×3B397FD4 ld-riscos/so/1
2 0×3B3982B4 0×3B399A24 0×3B399A24 0×3B399B6C SharedLibs:lib.libdl/1/9/9/so
3 0×3B399B74 0×3B399DDC 0×3B399DDC 0×3B399E5C SharedLibs:lib.abi-2/0.libm/1/0/0/so
4 0×3B399E64 0×3B3BFB5C 0×3B3BFB5C 0×3B3BFF08 SharedLibs:lib.abi-2/0.libgcc_s/so/1
5 0×3B3BFF10 0×3B4E2A74 0×3B4E2A74 0×3B4E5D88 SharedLibs:lib.abi-2/0.libunixlib/5/0/0/so

My *Modules includes a CryptRandom 0.13, which it looks like I got from PackMan.

@Andrew: I’ve raised a ticket for that. It looks like ‘something’ is being treated as a signed int somewhere.

@Andrew: I’ve raised a ticket for that. It looks like ‘something’ is being treated as a signed int somewhere.

Ahh, it’s a bug? I thought I was missing something somewhere! Thanks for raising the ticket, hopefully it will get found and squashed soon! It’s hindering me writing an i2c library!

Ahh, it’s a bug? I thought I was missing something somewhere! Thanks for raising the ticket, hopefully it will get found and squashed soon! It’s hindering me writing an i2c library!

I wonder if using -2147483648 would work as a very nasty hack, until I get it fixed.

I don’t /think/ it will be a major thing to fix, just things are a bit all over the place here – trying to do my actual day job, while stopping two small children destroying the house or each other.

How about (0×7fffffff+(1)) Don’t know how good Python is at optimising constant expressions.

I wonder if using -2147483648 would work as a very nasty hack, until I get it fixed.

Yes, converting to a negative number works! As you say, it’s a nasty hack but might work until it’s fixed properly, but I can put a quick function together to take an unsigned int and convert to a signed int

How about (0×7fffffff+(1))

No, that doesn’t work I’m afraid.

My *Modules includes a CryptRandom 0.13, which it looks like I got from PackMan.

That’s the missing item; thanks!

ETA: It would seem that the complete PackMan requirements are CryptRandom, SharedLibs, SharedLibs-C2 and SharedUnixLibrary.

Thanks Steve – I’ll try to remember to add that to the ReadMe :)

I’ve had a look at the swi block thing. I tried it on 2.7 and it doesn’t work there either (although with a different error).

The simplest fix is probably convert the value to an unsigned long, however that will stop it working for b[x] = -1. It’s probably possible to handle either for the setting side, but going the other way is a bit trickier.

Checking for b[x] == -1: .. and b[x] == 0xffffffff: are both valid, depending on the context. However returning the value as unsigned will stop the first one working, and as signed will stop the second.

One solution might be to create a new class to handle the value, which will do the ‘magic’ to allow it to be compared either way, another might be to extend the ‘block’ class to add functions to set / get signed and unsigned values. There is an argument for changing [] to work with unsigned values as they’re most common (at the risk of breaking existing code, I guess).