Livewires begets GASP

I was completely taken in by the Livewires Python Course. While Guido's 1999 Computer Programming for Everybody DARPA grant proposal resulted in at least a few educators finding their way into the community, including both me and the Livewires folks, Python was a tool made for professional software developers. The community consisted overwhelmingly of professional software developers using it for their own pleasure and need. They generally had little clue what would make for a good learning curriculum, and little interest in using Python in education. I remember observing over the years as an outside educator in the Python software community that many of its most able software developers had been misunderstood and mistreated in school, and often had little affection for formal educational institutions.

The Livewires group understood the educational problem deeply, and developed an accessible and engaging curriculum as a result. I love it, since my students over the the last 13 years have told me they really like it too. What's more, another thing I shared with the Livewires developers was in being pioneers in what has since come to be called open educational resources (OER). They released their software under a free software license, and their curriculum materials under a similar free license. This meant I was free to remix and adopt their work to my specific classroom needs.

In the first place, I needed to adapt their religious context to a secular, public school one, since "learning more about Jesus and technology" was not the kind of branding I could use. Second, my students were older and some of them were very advanced programmers. I wanted them to be able to hack on the software library itself, using it to discuss what an API is and the design process that goes into creating one. Thus, the Livewires Python module and course begat the "Graphics API for Students of Python", or GASP, a project so cool it takes your breath away (my deep affection for corny humor generally plays well in high school ;-)

Since 2007 students of Arlington Public Schools have been both using and hacking on GASP. The rest of this post will document the attempt to install the latest incarnation, a port to wrap Pygame by Francesco Crisafulli developed early this year.

Installing GASP on MacOS

I am using Homebrew as my package manager for my school issued MacBook Air laptop. To install Pygame, I first made sure I had the most up-to-date package of Python 3:

$ brew update && brew upgrade python

Then I followed the instructions on the Pygame wiki and installed pygame in user space with:

$ python3 -m pip install -U pygame --user
$ python3 -m pip install -U numpy --user

Note:

Keeping up with the ever changing Python installation practices is a challenge to say the least, as the xkcd comic titled Python Environment makes humorously clear, but I found long time Python core developer, Brett Canon's post on the subject, Why you should use `python -m pip`, very helpful.

I next installed GASP by cloning the git repository inside my Projects sub-directory with:

$ git clone git@gitlab.com:gctaa/gasp-2020.git

I have $HOME/.local/lib/my_python in my PYTHONPATH, so from inside that directory I ran:

$ ln -s [Path to my home directory]/Projects/gasp-2020/gasp gasp

I can now import and start GASP, though the graphics window does not appear as expected.

Installing GASP on GNU/Linux

On my Debian 10 workstation, the GASP installation process is similar, though I used debs instead of Python packages:

$ sudo apt install python3-pygame python3-numpy
$ git clone git@gitlab.com:gctaa/gasp-2020.git
$ ln -s [Path to my home directory]/Projects/gasp-2020/gasp gasp

It also seems to work better, since the display window with white default background works.

Installing GASP on Windows 10

I'm working with a group of very bright and talented students this Summer who are interning with NOVA Web Development. They are learning Python, and I met with four of them this very afternoon to talk about using the GASP Python Course. Two were on Windows, and I mistakenly told them it would be out of the question to get pygame working with Python 3 on Windows.

I'm delighted to say I was totally wrong about that! The Windows Subsystem for Linux has completely changed what you can do on a Windows machine. I have a Dell laptop from work that I setup to dual-boot Ubuntu 20.04 and Windows 10. In the Windows 10 system, I installed Debian 10 on the Linux Subsystem. I thought that GUI programs were out of the question. Not so anymore. Following the instructions I found on How to Run Graphical Linux Desktop Applications from Windows 10’s Bash Shell, I:

1. Installed Xming
2. Followed the same setup instructions for the Debian 10 subsystem listed in the previous section
3. Ran $ export DISPLAY=:0 (I'll explore putting this in the .bashrc file later)

The Way Forward?

I stopped using GASP for several years after I switched to Python 3, since there was no Python 3 version of GASP. Thanks to former student Marco Sirabela, who ported GASP to pyGTK / pycairo, and current student Francesco Crisafulli, who ported it this year to pygame, I now have not one, but two Python 3 implementations to choose from. Marco told me he prefers the Pygame version, and the other one won't run on MacOS, a requirement for me now that my students have school issued MacBooks. With the installation experiment above showing that it is possible to get it to run on all three platforms that I want to support, Linux, MacOS, and Windows, it seems that wrapping Pygame makes sense and should be the focus of our current effort.

This approach isn't without problems, however. Pygame is in the middle of a transition between versions of the SDL library it wraps. Development largely ground to a halt in 2016, and has only recently picked up steam again. I'm hoping we can build the new GASP on top of Pygame 2 now without too much pain, and then continue to improve it as Pygame 2 matures.

I'll explore this over the next week or so and follow up with what I find.