Python 3.8 - alpha release

I tried to work out why Python3 did not start up in a plain TaskWindow, but failed.

When a taskWindow is opened StrongED will check if the -name parameter matches a mode name. If it does then that mode will be used for the TaskWindow. This dates back to a feature request from years ago where someone wanted to define a mode for a specific TaskWindow task so things could be tailored to that task.

Better still I found the removing the space in the -name also worked.

It looks like StrongED’s parsing of the -name field could be better by making sure it matches the entire string rather than up to the first space.

When a taskWindow is opened StrongED will check if the -name parameter matches a mode name.

Thanks very much for that explanation.

It looks like StrongED’s parsing of the -name field could be better by making sure it matches the entire string rather than up to the first space.

Perhaps, but then if a mode specific TaskWindow was required no additional information such as version number could be put in the title bar.

Depending what is required options might be like this:-

-name "Python_3.8.5_1"
-name "Python 3.8.5_1"

I have a question.
With 3.8a6 (because pip) how do I deal with this?

[…]are installed in ‘<Python3$Dir>.Scripts’ which is not on PATH.

I’m probably just a bit thick, but is there a way to sort this environment issue?

Found it, see typos at lines 85 & 86 in !Python3.Lib.sysconfig.

Thanks for spotting that, I’ve updated it here.

Numpy seems to be working well but I am having difficulty importing pygame. I get the following error message
>>> import numpy
>>> import pygame
Traceback (most recent call last):
File “”, line 1, in
File “SCSI::HardDisc4.$.PythonSite.Python38.Site-Packages.pygame.init”, line 120, in
from pygame.base import *

Am I doing something wrong?

Numpy seems to be working well but I am having difficulty importing pygame.

Installing these packages using PackMan should get it to import.

LibFreeType6
LibOgg
LibVorbis
LibFlac
Tremor
LibPNG16-16
LibTIFF5
LibSDL1.2
LibSDLImage1.2
LibMikMod
LibSDLMixer1.2
LibSDLTTF2

Installing these packages using PackMan should get it to import.

It did.

Python 3.8.5+ (riscos-1, Aug 26 2020, 15:37:09) 
[GCC 4.7.4] on riscos
Type "help", "copyright", "credits" or "license" for more information.
>>> import pygame
pygame 1.9.6
Hello from the pygame community. <a href="https://www.pygame.org/contribute.html">https://www.pygame.org/contribute.html</a>
>>> 

but …

Time: Wed Sep  9 09:46:20 2020
Location: Shared Libraries
Current Wimp task: Python_3.8.5_1
Last app to start: TaskWindow 444039C4 00000002  -ctrl

R0  = 00000000 R1  = 475f3844 R2  = 00429270 R3  = 000000dc
R4  = 00429270 R5  = 47261ed4 R6  = 00000000 R7  = 00000000
R8  = 4726280c R9  = 0028a918 R10 = 008011e0 R11 = 008049e4
R12 = 008049e8 R13 = 008049cc R14 = 475f3854 R15 = 475ea5a0
DFAR = 00000000  Mode USR32  Flags nzCv if   PSR = 20000010

475ea558 : 6f6c675f : SWIVS   &6C675F
475ea55c : 5f6c6162 : SWIPL   &6C6162
475ea560 : 726f7464 : RSBVC   R7,PC,#&64,8
475ea564 : 75615f73 : STRVCB  R5,[R1,#-3955]!
475ea568 : 00000078 : ANDEQ   R0,R0,R8,ROR R0
475ea56c : ff000018 : Undefined instruction
475ea570 : e1a0c00d : MOV     R12,R13
475ea574 : e92dd870 : STMDB   R13!,{R4-R6,R11,R12,R14,PC}
475ea578 : e24cb004 : SUB     R11,R12,#4
475ea57c : e15d000a : CMP     R13,R10
475ea580 : bbfffef4 : BLLT    &475EA158
475ea584 : e59f5094 : LDR     R5,&475EA620
475ea588 : e5955000 : LDR     R5,[R5,#0]
475ea58c : e59f3090 : LDR     R3,&475EA624
475ea590 : e5955058 : LDR     R5,[R5,#88]
475ea594 : e7956003 : LDR     R6,[R5,R3]
475ea598 * e5d63000 * LDRB    R3,[R6,#0]
475ea59c : e3530000 : CMP     R3,#0
475ea5a0 : 191ba870 : LDMNEDB R11,{R4-R6,R11,R13,PC}
475ea5a4 : e59f307c : LDR     R3,&475EA628
475ea5a8 : e7953003 : LDR     R3,[R5,R3]
475ea5ac : e3530000 : CMP     R3,#0
475ea5b0 : 159f3074 : LDRNE   R3,&475EA62C
475ea5b4 : 17953003 : LDRNE   R3,[R5,R3]
475ea5b8 : 15930000 : LDRNE   R0,[R3,#0]
475ea5bc : 1bffff21 : BLNE    &475EA248
475ea5c0 : e59f3068 : LDR     R3,&475EA630
475ea5c4 : e7954003 : LDR     R4,[R5,R3]
475ea5c8 : e5942000 : LDR     R2,[R4,#0]
475ea5cc : e5923000 : LDR     R3,[R2,#0]
475ea5d0 : e3530000 : CMP     R3,#0
475ea5d4 : 0a000007 : BEQ     &475EA5F8

R15 = 475ea5a0 = Shared Libraries +2895a0 = __do_global_dtors_aux +30
R14_usr = 475f3854 = Shared Libraries +292854 = call___do_global_ctors_aux +28
          Function call to 475ea570 = Shared Libraries +289570 = __do_global_dtors_aux +0

USR stack:



--------------------------------------------------------------------------------

*somaddress 475ea5a0
Address 475ea5a0 is at offset 0x25A0 of library SharedLibs:lib.abi-2/0.libSDL_image-1/2/so/0/8/4
*

Thanks Chris, I can now import pygame but running two of the standard games aacircle and aliens produces the following eror messages
pygame 1.9.6
Hello from the pygame community. https://www.pygame.org/contribute.html
Traceback (most recent call last):
File “SCSI::HardDisc4.$.Apps.Development.aacircle”, line 35, in
main()
File “SCSI::HardDisc4.$.Apps.Development.aacircle”, line 10, in main
screen = pygame.display.set_mode((500,500))
pygame.error: Invalid bits per pixel (range is {8…32})

pygame 1.9.6
Hello from the pygame community. https://www.pygame.org/contribute.html
Sorry, extended image module required

Any ideas?

File “SCSI::HardDisc4.$.Apps.Development.aacircle”, line 10, in main
screen = pygame.display.set_mode((500,500))
pygame.error: Invalid bits per pixel (range is {8…32})

If you run the python script by double-clicking it runs Python via the !Run file which uses the TaskWindow command. This fails as pygame uses SDL which runs as a Wimp Task so can’t run from a task window.

If you run the script directly it should run OK. Create an obey file and double click that.

python3 aacircle/py 1>/dev/null 2>&1

Yeah. I need to think about how to deal with this generally. “Watch this space” as they say :)

If you run the python script by double-clicking it runs Python via the !Run file which uses the TaskWindow command. This fails as pygame uses SDL which runs as a Wimp Task so can’t run from a task window.

The first thing I do is get rid of that from !Run, so it just runs Python files as a normal tasks. If I want stuff run in a TaskWindow, I’ll create one and drag/type stuff in to it. I’d prefer it if that was the default for all versions of Python.

The first thing I do is get rid of that from !Run, so it just runs Python files as a normal tasks. If I want stuff run in a TaskWindow, I’ll create one and drag/type stuff in to it. I’d prefer it if that was the default for all versions of Python.

I think it will be in the next release because then it’s more like running a BASIC or compiled C program. I can’t remember why it launches things as a TaskWindow by default now.. I guess it seemed a good idea at the time.

I can’t remember why it launches things as a TaskWindow by default now.. I guess it seemed a good idea at the time.

Perhaps in the early stage debugging you found that errors appearing in a nice stable task window was handy?
We all do this kind of things and unless we had a nice scripted plan¹ to remove/tidy up then it gets left until someone else points it out, or we trip over it ourselves.

¹ Yes, we all plan perfectly, don’t we? Er, no…

My guess would be that the initial thought was that a taskwindow allows the command line “interactive” python interpreter to multitask within the desktop, which is nice in terms of usability.
The added bonus is that python scripts which would otherwise lock the machine up, multi-task without needing to be told about RISC OS.
Both are nice features, but as we’ve seen, not necessarily the best defaults.

IMHO, I think the a run action for python script to single-task (as per posts above) is a good one, and if Python is run directly, it could open an interactive task window.

Alternatively, which might be even better, a desktop front end could be written (perhaps in Python… any volunteers?) which adds a python icon to the iconbar. It could then offer the ability to start a taskwindow version of Python or a single tasking one. Scripts dragged to the iconbar could run in a task window (or not) depending on choices. Double-clicking !Python3 could then install to iconbar, whilst double-clicking scripts could call the python executable directly via the alias$@runtype.

The goal must surely be to end up in a position so that Python is as integrated a system resource as BASIC, in terms of user experience. Obviously it isn’t in ROM, so it can’t quite reach BASIC’s level of integration, but we should probably aim for as transparent/similar experience with both languages.

It probably wouldn’t hurt for Edit (and Zap/StrongEd if necessary) to gain Create→Python options on their menus, too, given the significance of Python in the real world now.

given the significance of Python in the real world now.

John Cleese must be pleased!

It probably wouldn’t hurt for Edit (and Zap/StrongEd if necessary) to gain Create→Python options on their menus, too, given the significance of Python in the real world now.

A cursory glance at StrongEd shows it already does, and I’m sure Zap does similarly.

And I’m equally sure they will have since a long time ago!

John Cleese must be pleased!

The full Monty, Chris!

The goal must surely be to end up in a position so that Python is as integrated a system resource as BASIC, in terms of user experience. Obviously it isn’t in ROM, so it can’t quite reach BASIC’s level of integration, but we should probably aim for as transparent/similar experience with both languages.

I have had some experience in porting languages from Unix to RISC OS, and in dealing with the question of taskwindows. At one point I favoured using different filetypes, one for running the interpreter on a file and the other for doing the same in a taskwindow. But after a while I came to see this as a waste of a good filetype, and preferred to use !TaskW . Of course, in Unix one expects to start things up with a commandline, and usually there are lots of options that can be given, but these do not really fit into the RISC OS philosophy of avoiding the keyboard wherever possible. One can, of course, have a special launcher with dialogs and menus and bells and whistles; but I prefer to keep things as simple as possible. So, were one to be porting some language, say called GrassSnake , I would have an application called !GrassSnake. Its !Boot file would set up some system variables relevant to GrassSnake and define an Alias$@Runtype for the filetype allocated to it. The aim would be that once !GrassSnake had been filer_booted its filetype would have an icon and clicking on files of that filetype would run them – and dragging them to !TaskW’s iconbar-icon would run them in a taskwindow.

preferred to use !TaskW

That link is http://www.wra1th.plus.com/zip/TaskW.zip and failed.

However, after a couple of checks the issue seems to be a case sensitivity issue as the use of http://www.wra1th.plus.com/zip/taskW.zip works – note the lowercase “t”

Sorry, that was my fault. It is not even proper camel-case, which Jim Nagel hated so much.

which Jim Nagel hated so much.

Glad someone else remembers his idiosyncracies so fondly!

J.

Sorry, that was my fault.

Just unusual. IIRC URL/URI info is supposed to be case-insensitive

Glad someone else remembers his idiosyncracies so fondly!

Our former director (youngster, 1 month less than me) used to complain long and loud about its use in document titles.

IIRC URL/URI info is supposed to be case-insensitive.

The domain part is; the bit on the local filing system can be, I think, but is generally case-sensitive as it’s running on a system with a case-sensitive filing system.

It is not even proper camel-case, which Jim Nagel hated so much.

I feel that he would have approved of the lower-case initial character, however!

On Windows systems there are two Python executables, python.exe and pythonw.exe — the latter for running applications in windowing mode, I.e. without showing the console. Some versions of Python for Mac do the same (though without the .exe, of course).

I agree with AndrewR’s idea that the experience should be as similar to Basic as possible. The last version of Python3 I tried—earlier this summer—came up in a text window so I could type commands in to the interpreter, but I couldn’t edit those commands — even just trying to backspace messes things up. Perhaps this has now been fixed?