Bundling macOS Applications with Platypus

So I know that Apple is pushing all app developers to the App Store, but I’ve recently been playing around with Platypus for the Connected Learning Initiative project that I’m working on. I was curious how to bundle together a macOS application, but didn’t want to go through XCode or the Apple Developer Program.

Platypus is pretty nifty because it organizes all of the files and scripts for you, into the appropriate .app folder structure. There were a couple of things that I couldn’t find in the documentation, however, that I wound up having to figure out:

Our bundle actually consists of running two executables on program launch (one that acts as an assessment engine, another as an ePub reader). However, you can only launch one script when you open the app. I wound up creating an AppleScript to open up two instances of Terminal and running one executable per instance. And apparently spaces in Terminal have to be double-forward-slash-escaped instead of single (i.e. \\ instead of the typical command line \):

echo Running ePub reader from $EPUB_READER_SCRIPT
osascript -e "tell app \"Terminal\" to do script \"$EPUB_READER_SCRIPT\""
sleep 3

echo Running assessment engine from $ASSESSMENT_ENGINE_SCRIPT
osascript -e "tell app \"Terminal\" to do script \"$ASSESSMENT_ENGINE_SCRIPT\""
sleep 3

/usr/bin/open -a "/Applications/Google Chrome.app" 'https://localhost:8888/'

One other challenge was finding bundled data files. I was including static files, ePubs, and JSON data files in the application bundle, since it is meant to be a standalone LMS / learning application, and I couldn’t figure out why my scripts couldn’t find the data. The Platypus documents indicate scripts in the app bundle can reference other files in the bundle relative to themselves. The directory structure inside of /Content/Resources was:


However, because I was launching new Terminal instances, the Python scripts inside of your .app bundle had the current working directory set to the user’s home directory (Terminal default). For example, in my main_script.py file, os.getcwd() would return the user’s home directory (/Users/) instead of the app’s /Content/Resources directory.

I wound up having to do something like this in my main_script.py:

import os

ABS_PATH = os.path.dirname(os.path.abspath(__file__))

in order to find and read files relative to my main script.

Exploring Quantum Algorithms

I’ve come to realize that making the best use of quantum computing in the future requires knowledge of quantum algorithms, so I’ve been focusing the last couple of weeks on better understanding those. It’s interesting that there already exist many such quantum algorithms that take advantage of quantum mechanics. To me, it seems like quantum programming will require knowledge and experience of when to use which algorithm, like machine learning programmers need to know when it is more useful to apply different algorithms, depending on what data is available or the intended goal. I’ve been wanting to read this book by Ike, an MIT professor, so waiting for the term to end so that the library copies become available. At least I’ll make an effort to skim it…

I’ve also been reading through the IBM Jupyter notebooks on how to use their qiskit, specifically the one for optimization. In there, they talk about how you could use quantum computing to solve the traveling salesman problem, a classic one in optimization research. It’s interesting that the brute force method for N > ~20 is unsolvable on traditional computing, but if I understand the IBM notebook correctly, it could be brute-forced with (N - 1)^2 qubits — so for example, if N = 20, that would be 361 qubits. Assuming the challenges with error correction as the number of qubits increases can be overcome, that seems like it might be a year or two in the future.

Until I read the Wikipedia article on the traveling salesman problem, I also didn’t realize that people have come up with alternate algorithms that can tackle up to 85,900 cities — amazingly better than the brute force method. While using traditional computing to implement these algorithms seems CPU intensive (i.e. using a supercomputer), it also boggles my mind that to solve this on a quantum computer, you might need 84,999^2 (7.2 trillion) qubits?!?!?! Given the state of technology, that seems decades away or impossible …. it makes me wonder if there are also alternate, quantum versions of these non-brute force methods that would make the required number of qubits more realistic. Kind of like there is a quantum Fourier transform to mirror the traditional discrete Fourier transform. More reading required!