Running PC-BASIC in browser.

[nmanumr]

I have successfully been able to compile PC-BASIC for browsers using pyodide.

I had to make a lot of blocking code async so that It can work in browser. I'm using pygame interface on browser which seems to work out of the box.

Question

I notices its mentioned that pygames interface is deprecated and will be removed in upcomming version. I just wanted to ask why it was deprecated.

Future Plans

• As of now its just a proof of concept and it works. So first of all I'm planning to make it a standalone web app.
• Secondly I would like to merge my changes upstream so that the web app version is accessible from pc-basic.org.

PS: here is my fork

[robhagemans]

Hi Nauman,

First of all, congratulations! That's impressive. Thanks for sharing your code - I'll certainly try and play around with it a bit.

On your questions:

• I deprecated the pygame interface for several reasons: the immediate cause was that it appeared, at the time, no longer maintained; it was dependent on an old SDL version 1.2 and there seemed to be no plans to upgrade. Meanwhile SDL1.2 was itself being deprecated so this was becoming a support issue. The apparent successor at the time (this was a few years ago) was pygame-sdl2 but this project made a conscious choice not to support 8-bit surfaces, which I heavily used. At that point I considered that what I was using pygame for was a fairly limited amount of functionality, and if an important part of that disappeared it wasn't worth working around it. Moreover this as easily replicated using the SDL2 library directly, at which point it was better to "cut out the middleman". However the interface was still working well so while I developed the replacement I kept it in place. Longer term however I don't want to maintain two separate modules doing essentially the same thing, but needing separate testing, etc. Currently PC-BASIC supports too many platforms, options, interfaces, Python versions etc. and I cannot keep the effort up with testing and releases - between the day job and other interests, I just don't have the time anymore.
• Of course since then, pygame development has picked up again and I noticed they now have a SDL2 version. But given that I've built the SDL2-based code anyway and it works better than the pygame one, I still don't feel like bringing back the dependency.
• In terms of merging this, I think it would be worthwhile: it could be a lower-maintenance path to releases (releasing Windos and Mac packages is a huge pain). But it will not be easy to get there - for example, I don't want to have two replicated code bases living together with much the same code, one async and one not. But perhaps it is possible for the async version to support all use cases/interfaces, including cli, text and graphical on the desktop. Obviously as you point out this is a proof of concept, and it is awesome that it works - further development might perhaps consider that as a target?
• I'm assuming async is needed for I/O related items. There is a potential clash / architectural difference with the interface setup in PC-BASIC which is thread based. I'm not super attached to the thread approach, its main aim was to separate the interface form the core library but non-I/O threads in Python are problematic due to the GIL. (The GIL may be going away, but it'll be a while...) So if an async approach can fully replace the thread approach, that again is interesting as it may address the performance issues with threads.

This turned out to be a long message, hope the background helps

[nmanumr]

Thanks for detailed response Rob.

Regarding Pygame, Pyodide also supports the SDL based packages, so I believe I can get it working on the web as well. When I previously tried the SDL interface, it failed because it couldn't find the DLL file. I think I can fix this and will give it another try.

But perhaps it is possible for the async version to support all use cases/interfaces, including cli, text and graphical on the desktop.

Regarding the async version, I agree that it should work well. The only issue is Python 2 support. Are you sure we should continue supporting Python 2?

If you'd like, I can start by porting the existing codebase to asyncio for the desktop first, and then move on to porting pcbasic to the web.

[robhagemans]

Hi Nauman,

We definitely don't need to support Python2 anymore, nor any other Python versions older than 3.9.

In fact that's one of the other things I deprecated and wanted to drop as part of a 2.1 branch, alongside the pygame and curses interfaces which are replaced by the sdl2 and ansi ones. I also will drop support for old Windows versions. All in all this means that we can get rid of a large amount of compatibility and workaround code (modern Python3 under Windows gets Unicode right; moreover Windows now supports ANSI escape sequences in the terminal). I'm also considering to get rid of the custom packaging code in favour of some standard solution, though I'm not yet sure which one.

I might still do a 2.0.8 release supporting all of the above, just to include the fix for MOD as it's a bit of an annoying bug, but other than that development can move o a clean 2.1

[nmanumr]

Ok let me start by porting to asyncio I will open a PR soon.