Our support was stuck on an ancient version that has not been available for a while. If we were to continue support it should be done around the new PhysX 5.0 API, not 2.8.4.
It doesn't seem like this setting is actually needed (because mayapath does the necessary set-up), but while it's set, we might as well set it to something more sensible.
This effectively ends support for 32-bit Intel Macs. It switches the standard library to libc++, allowing us to use features from C++11.
There are some known bugs with older versions of libc++ (such as the istream::eof() bug); we may end up raising the minimum further (eg. to 10.9) soon if the situation becomes untenable.
Fixes#300
This back-end has been deprecated by Apple for a while, and has not been used in Panda. As we will no longer be supporting 32-bit macs going forward, and the Carbon windowing API is not available for 64-bit mac, there's no point in keeping it.
Let's show a warning when an option has been removed but its presence would not have affected the build in an important way. For options like --use-awesomium we should still show an error since it invokes behavior we no longer support, but it should be harmless to specify --no-awesomium.
This changes the Assimp include path to point to the
directory containing assimp/ instead of inside assimp/
directly. This is for consistency with how the Assimp
project defines their "include path" and keeps the actual
inclusions themselves unambiguous (since Assimp's headers
have fairly generic filenames).
This is done by adding a PyTargetAdd function, which builds the target into a Python ABI-specific temporary directory, allowing multiple Python versions to be built into the same built dir side-by-side. This could greatly speed up buildbot builds.
It also paves the way for building multiple Python versions in the same makepanda call / installer by changing PyTargetAdd to add one target per enabled Python version.
Since this still takes a long time to build, even with the previous change, it would be better for one CPU to chew on this in the background while the rest of the build continues.
The no-arguments get_text() and set_text() will now return Unicode strings in Python 3, but passing in an encoding will make them return/take bytes objects.
In Python 2, they all take regular strings, but Unicode is also accepted by the no-argument get_text() and set_text().
In the future we probably want to remove most of this interface for Python users, to whom all this is unnecessary since it duplicates functionality already in the standard library.
This reimplements the spinlock on top of std::atomic_flag, which is guaranteed to be lockless. It also inserts the PAUSE (REP NOP) instruction which is strongly recommended to be placed in busy-wait loops by Intel.
This also includes a recursive spinlock implementation.
The spinlock implementation is disabled by default, but can be enabled by adding the --override MUTEX_SPINLOCK=1 flag to makepanda.
Rationale:
1. Per standard, fstream::open takes 2 arguments.
If platforms add a third, they're out of spec.
2. The only platform I could find that takes a file
mask specifically as the third argument is IRIX,
which Panda hasn't targeted in forever.
3. The mask being requested isn't even particularly
interesting - falling back to a platform default
is best.
4. When USE_PANDAFILESTREAM is defined, pfstream
is implemented as PandaFileStream, which doesn't
have a three-argument open() and breaks immediately.
5. makepanda doesn't ever define HAVE_OPEN_MASK
6. It's been broken for so long that, if it were
important to anybody, it would have been fixed by now.
This makes it possible to include it multiple times in a single
translation unit, and/or multiple times in a single dynamic
library (and without excess code bloat, too).
As of f69354d9fa, this is just always
expected on all platforms. If it's not defined,
TemplateClass<X>::_type_handle won't link correctly with some compilers
(e.g. Clang) and the lack of 'extern template class' will result in
duplicated code in any case. In short, turning it off causes problems.
makepanda also always turns this on, so it doesn't represent any
optional feature or autodetected platform-specific behavior anyway.
It can be launched from the termux shell using the provided run_python.sh script, which can communicate with the Panda activity using a socket (which is the only way we can reliably get command-line output back to the program.)
The Python script needs to be readable by the Panda activity (which implies it needs to be in /sdcard).
The standard library is packed into the .apk, and loaded using zipimport. Extension modules are included using a special naming convention and import hook in order to comply with Android's strict demands on how libraries must be named to be included in an .apk.
[skip ci]
This has been due for a while. The last FFTW 2.x release was in 1999.
Note that this does change some of the loops; this has two benefits:
1) The halfcomplex storage order is now explained with a comment.
2) It fixed the special case "don't break a run of bytes for a zero" which
was never triggering due to the value not being *exactly* 0.0.
I have tested these changes against older FFT-compressed animation .bams
and no noticeable decompression changes are present, so a .bam version
bump is not necessary.
We no longer copy libs to a separate libs dir to entertain Ant (which is no longer the build system of choice on Android). Also, rather than copying the Java sources to built/src, we now compile them and put the classes in built/classes.
Furthermore, executables are really compiled as executables now (rather than as libraries) to allow building and running Panda in termux.
The binary path we get from /proc/self/exe isn't very useful; the path to the .apk is barely more useful but it still doesn't make a whole lot of sense. It might make more sense to set it to the path of the native .so that is being loaded by NativeActivity.
These files are from the NDK, but don't seem to be included in termux. Since they are two small files that change very rarely, it's easier to just include them in the Panda repo.
[skip ci]
- allow setting API target with --target=android-21
- always link to libpython on Android, seems to be necessary
- support aarch64 (arm64-v8 ABI) architecture
- enable building on an Android machine (tested in termux)
[skip ci]
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.
This makes it possible to run pytest in the root directory. It also lets us store metadata such as the current version number, preventing us from having this in several different places, and allowing us to phase out parsing dtool/PandaVersion.pp.
rdb
kamgha
Mitchell Stokes
Sam Edwards
DrEuler
Sebastian Hoffmann
Younguk Kim
tobspr