The actual bundling is currently commented out in the bottom of
build_apps.build_runtimes(). Generating the .app was tested from a Linux
host and looks mostly correct upon a visual inspection of the contents.
However, no testing was done for actually running the .app on macOS,
which is why it is commented out. This was also not tested on Python 2.
There are also some TODO comments that need to be addressed.
- Do not take into accound SBS if it is not enabled
- Always return value for getSize()
- Properly handle SBS for window-events
- Redo positioning of aspect2d(p) markers exactly as
they are created when adjusting aspect ratio
Signed-off-by: deflected <deflected@users.noreply.github.com>
This introduces AsyncFuture as a new base class of AsyncTask. It's modelled after asyncio's Future class, except that it is thread-safe and you can use result() to block the current thread waiting for the future to finish (of course this is not necessary for use with coroutines).
AsyncFuture should be used for any operation that finishes in the future, to get the benefit of awaitability within coroutines as well as a standard interface for querying status and results of the operation as well as cancelling it. As such, it's been implemented in various places, including texture.prepare() and win.trigger_copy().
Note that AsyncFuture is intended to be used *once*; it cannot be used more than once. As an example of how this works, tex.prepare() will return the same future as long as the prepare isn't complete, but when it is done, subsequent calls to tex.prepare() will return a new future.
Gets rid of properties defined as both MAKE_SEQ_PROPERTY/MAKE_MAP_PROPERTY, which are just a bad idea. Instead, adds a way for map properties to define a separate "keys" interface.
Fixes: #203
This will be a good way to make sure everything in the tests work under
a frozen environment.
NOTE: The application builds and runs, but no tests are collected. We
still need to figure out how we want to handle tests. Freeze them all
and modify test collection? Add py/test files to the build directory and
try to run them?
This is necessary because when Python is initialized, it takes the codec to use from GetConsoleCP() and GetConsoleOutputCP() without bothering to check whether the given codec is available. However, in most cases, the console codepage will be the same as the ANSI codepage (ie. GetACP()) which is always supported by Python via the 'mbcs' codec.
So what we do is we check whether the console codepage is frozen in, and if not, we set the console codepage to the ANSI codepage and set the stdin/stdout/stderr encoding to 'mbcs'.
This is still not a perfect solution because the ACP may not be able to encode all characters that the application is printing, which would still result in unexpected errors. Ideally, we'd pull in Python 3.6's _io._WindowsConsoleIO class, which bypasses this whole mess by directly using the wide-character Windows APIs to write to the console.
