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.
This is inefficient because it induces an unnecessary ref()/unref() pair when we just need to move the pointer out of the function. Thanks to 23128e4695, we can now move between related pointer types, making the .p() hack unnecessary.
This is useful because these types are created at static init time, and giving them a constexpr constructor and trivial destructor lets them be created during constant initialization, which helps to prevent static init ordering issues.
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.
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.
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.
This happened when a M_dual transparent object is given the
M_filled_wireframe render attrib. M_dual would copy the transparent
parts of the object to the transparent back-to-front bin, before
the M_filled_wireframe handler could deal with the M_filled_wireframe
flag.
The solution is just to switch the order - let M_filled_wireframe be
dealt with before the transparency code gets a chance to make a copy.
What's being addressed here is the circumstance where an ancestor of
a PlaneNode has a ClipPlaneAttrib that references said PlaneNode.
The code here is just being copied out of LightAttrib, which has the
exact same mode of operation (it nominates a sorted list of on/off
NodePaths) and a compatible structure. LightAttrib has had this problem
in the past, so using the same solution makes sense.
This just starts with PandaNode, and uses DCAST_INTO_R instead of DCAST
to catch bad bams. BamWriter should never produce bam output that will
trigger this; I found this with a fuzzer.
I'm unsure about the tradeoff between bam loading performance and
robustness in the face of bad bams. It certainly makes a lot of sense
in debug builds, but we might want to consider a compile flag that
forces bam-related asserts always on even in release builds.
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 remove support for coercing non-ReferenceCounted types that are neither default-constructible nor move-assignable, but it turns out none of the classes we really need it for matches that.
It further cuts down on the amount of code that is being generated to support coercion in cases where it makes absolutely no sense.
* Disable state munger, which isn't needed
* Reflect updates to TextureStage properties (Fixes#178)
* Also respect combine mode and rgb scale changes
* Allow rehashing and clearing generated shader cache
State munger is now disabled whenever any shader is applied. Panda assumes that any custom shader will apply color scale by itself.
rdb
Sam Edwards
Mitchell Stokes
Younguk Kim