- Support encoding and decoding four-byte UTF-8 sequences
- E_unicode supports surrogate pairs, renamed to E_utf16be for clarity
- char32_t should be used for storing a Unicode code point
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 allows building against the Python libraries even when the
Python interpreter/executable is missing. The correct extensions
for the binary modules will be guessed, the tests will fail,
and the bytecode for any pure-Python modules will not be
precompiled.
This is not perfect, and we need to more thoroughly address thread safety in the PRC system, but it will nonetheless address a lot of the race condition issues when querying these variables from two threads at the same time.
This requires a macro to override find_package,
as the default behavior in CMake is to fall back
from MODULE onto CONFIG.
Note that Bullet is given a specific override
not to look for a CONFIG, since Bullet tends to
use weird paths in its CONFIG script.
This is preferable because imported targets generally include
all of the relevant information specific to the particular
installation of each package, and without needing to hunt down
a bunch of variables to do it.
To do this, package_option() (which is starting to grow in scope
a little beyond just providing the package option, come to think
of it) is given a new IMPORTED_AS option, which tells the package
configuration system to look for one or more imported targets and
link against them instead.
Instead, let's use a PKG::PKGNAME interface library, which simplifies
the linking and also allows us to use imported libraries from
find_package in the future.
This should obviate the need for pystub as well.
Note that it's currently a little bit hacky; the source will
have to be moved to make the CMake dependencies work better.
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.
For example, this will let us pass a ConfigVariableFilename to anything that accepts a Filename, just like in C++.
Does not work if the return value if the typecast operator requires management.
Currently, the WeakPointerTo comparison operators compare the raw pointers, but this is not useful as it may cause a false equality if one weak pointer in the comparison is expired and points to memory that has since been reused.
Instead, we can define a comparison based on the control block pointer, which exists since the new weak pointer implementation in 0bb81a43c9. This is implemented in the owner_before method, matching C++11 std::weak_ptr semantics.
I would now recommend deprecating most comparison operators of WeakPointerTo or redefining them to make more sense, ie. comparing equal if they (once) referred to the same object and not if they simply point to the same memory address. This has not yet been done, though code that uses the comparison operators has been fixed in this commit.
Overloads of std::owner_less have been provided for creating a map or set with Weak(Const)PointerTo keys.
Only the basics are supported; the __members__ or iter interface is not supported at this time.
See also #351 for discussion on pulling in enum34 module.
If a class inherits from ReferenceCount, it can be destructed by downcasting to ReferenceCount, so it should not be an obstacle to properly clean it up when such a class is returned from C++.
This issue comes up when a CycleData is returned via MemoryUsagePointers, which is not exposed so is wrapped as NodeReferenceCount instead, which has a protected destructor.
If any code is relying on this, please let me know and I will add it back. It appears to be redundant, though, since one can access DtoolClassDict directly.
Symbol kept around temporarily in order to keep ABI compatibility for a short while as people may not update their interrogate and Panda in sync, but it can soon be removed.
I don't know if this is the right solution, but it does fix an issue accessing std::ios::openmode caused by the ios typedef being defined before ios_base is fully specified.
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.
There is a bug in clang versions before 3.2 (including the one shipped with Xcode) that makes it give a "conflicting types" compile error when there is a static constexpr function defined outside the class. The way to work around this is either to remove one of the "static" or "constexpr" keywords, or to simply put the definition inline.
See: https://stackoverflow.com/a/17494592/2135754
I would try and upgrade Xcode to version 5 to see if the problem is fixed, but the buildbot still runs OS X Lion (10.7) and the last version of Xcode that works on Lion is 4.6.3, so it seems easier to just apply these workarounds for now.
This renames acquire/release to lock/unlock in order to be compatible with std::lock_guard and std::unique_lock (which will eventually replace the *MutexHolder classes). It will also allow us to typedef MutexImpl to std::mutex later on.
A blank string to FindPythonInterp finds the version
of Python that the system "python" interpreter invokes,
so this means the default is now the system default.
This removes the requirement that it only be included
in a single C++ file per library, by forcing the compiler
to emit the function that references the version symbol
as a weak symbol itself. Now, the linker will not only
tolerate redundant inclusions, it will also coalesce them
together.
To access a WeakPointerTo in a thread-safe way, use something like this:
if (auto ptr = weak_ptr.lock()) {
..use ptr as regular PointerTo
}
The new implementation no longer needs a reference to be stored to all weak pointers on the WeakReferenceList; a mere count of weak pointers is sufficient. Therefore, callbacks theoretically no longer require a WeakPointerTo to be constructed.
The WeakPointerTo class is not actually atomic; it could be made so, but I don't believe it's worth it at this time.
I have no idea why this error happens, but it does not seem worth the effort to investigate further, so I'm just reverting the previous change to this file.
I am not sure why the definition of NULL was removed; it might have been by mistake, but in any case it broke code like this:
img = PNMImage(w, h, color_space=CS_srgb)
since it would not understand the default value (NULL) for the argument preceding color_space.
This distinction allows us to better support Python 3, since it will raise exceptions when trying to put arbitrary binary data in a str object.
This also adds some convenience functions for efficiently initializing a Datagram or PTA_uchar from a vector_uchar.
This is designed to sanity-check the buildsystem, ensuring that the
expected BUILDING_ macros are defined at the expected time. It
also helps catch cases where the wrong BUILDING_/EXPCL_ macros
are used.
The GCC documentation states that, as of GCC 2.7.2, these aren't
necessary for proper program behavior. The documentation further
discourages their use because they don't suppress unnecessary code
duplication.
The Panda codebase these days uses "extern template class" instead,
which tells the compiler not to perform implicit template expansion
because an explicit template expansion is available for linking
elsewhere in the program. This is a more compiler-neutral way of
achieving the same thing as '#pragma interface', making
'#pragma interface' not only redundant, it could also mask problems
in the "extern template class" machinery.
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.
This will help us catch cases wherein we inadvertently create a circular dependency between component libraries. Right now it only checks inheritance and typedefs, but this can be expanded in the future.
Also, sorts the module initialization by dependency topology. This isn't very important right now, but having this guarantee might help when refactoring module initialization in the future.
Typedefs are evidently always considered "fully defined", so we need to add another condition to the database merging code to prefer the type that is marked "global" when merging two types.
Sam Edwards
Mitchell Stokes
loblao
Younguk Kim
rdb
Psychotropos
Donny Lawrence