VK_ERROR_UNKNOWN was part of Vulkan 1.0. However, it was only first defined in Vulkan-Header 1.2.13 (see history).
Is there a particular reason for this?
VK_ERROR_UNKNOWN was added so you have some specific code to return if your driver (or perhaps layer) encounter some inconsistency and panic. Previously VK_ERROR_VALIDATION_FAILED_EXT was often used for the case.
Either way, returning VK_ERROR_UNKNOWN is in of itself a part of undefined behavior, and is not allowed as part of conformant behavior. So it is not compatibility breaking change to introduce the code.
Related
From its documentation, it states that Mono returns empty when it "completes without emitting any items". What does it mean to complete without emitting any items? Does it mean that it never sent any request or?
It depends on the implementation. Generally, for reactive data access libraries it means that the request/query was executed but yielded no results. However, this is not always the case as there are alternative behaviours like returning a default value or returning a Mono with error. Always consult the relevant library (e.g.: Spring Data) documentation to understand the behavior.
Answering from the perspective of "what does it mean in terms of behavior", not "what does the empty Mono behavior means in terms of business logic":
Mono is a Publisher, an interface that is defined to emit a set of signals to its Subscriber: onNext, onComplete, onError.
In the case of Mono the possible combinations are restricted:
onNext followed by onComplete (something was produced and we're done)
onError (something went wrong)
onComplete (nothing was produced but we're done)
The last one is the empty case you're wondering about: an empty Mono is one that never emits the onNext signal but rather simply emits onComplete.
To add to Simon's complete answer (why do I do that, hm?)
One typical use case of Mono returning empty is filtering. Think of it like if you need to do something in if then else style, in terms of Mono you could use .filter for then and .switchIfEmpty for else.
To understand the logic behind, for me it was also useful to look onto interface MonoSink<T> apidoc. It basically says the same: you can either complete without value, or with it, see two overloaded success methods.
Being a newbie Kotlin coder, I wonder, if there are some good practices or even language constructs for declaring pre-conditions in functions.
In Java I have been using Guava's Preconditions checking utilities:
https://github.com/google/guava/wiki/PreconditionsExplained
After some further investigation I came across the require function:
https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/require.html
Is this what is generally used for checking preconditions on functions?
Of course. You can find all of the preconditions in Preconditions.kt. In addition to the require function, there are requireNotNull, check & checkNotNull functions.
Since the documentation describes it poorly in Kotlin, but you can see the Objects#requireNonNull documentation in jdk as further.
Checks that the specified object reference is not null. This method is designed primarily for doing parameter validation in methods and constructors.
I use assert() and require() from the stdlib.
https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/assert.html
https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/require.html
Actually, 'require' appears to not be inherited - that is, if a subclass overrides a function that has a 'require' statement, the 'require' in the parent function is not enforced. A true precondition would also apply in the case of a redefinition of the inherited function, so (IMO) 'require' does not truly provide full precondition-checking functionality.
(I say "appears" because, being new to kotlin, I've learned this by a simple experiment using inheritance - and it's possible I'm wrong - e.g., there's a bug in the compiler causing incorrect behavior, or I've done something wrong in compiling/setup. I don't think this possibility is likely, though.)
Yes, it seems that toolforger is right about 'require'. I just searched for "require" as a keyword at https://kotlinlang.org and couldn't find it, nor as a documented function. It appears to be undocumented (unless the doc for require is hidden somewhere I couldn't find); and, of course, that means we cannot count on it to implement the standard DBC "require" behavior, and so the logical assumption is that it is simply the equivalent to "assert" in C.
What is a "suitable guard" and what does it look like?
Linked this question because it refers to the same compiler message and the answer mentions a guard but not how to create one. Looked through the AspectJ docs but did not find and answer there.
This Lint warning is usually switched off in AJDT (AspectJ Development Tools) within Eclipse, but you can activate it as a warning or even error like this (I had to do it to actually see it at all when trying to reproduce your issue):
You can just ignore the Lint warning because basically it only says that there is no way for certain pointcuts to populate the thisJoinPoint object lazily during runtime because the pointcut has no dynamic component like if(), cflow() or similar, which is actually good news because it means that all your joinpoints can be determined statically during compile/weave time and are thus faster than dynamic pointcuts. On the other hand, the warning says that the tjp object always has to be created because for some reason it is also always needed during runtime and thus cannot be instantiated lazily.
I'm implementing a basic textured cube example, and have run into an interesting problem - after passing my DescriptorWriteSet structure to the UpdateDescriptorSets API call, all of the fields have been zeroed out. Any code which tries to read the fields after that gets a null pointer exception (because the DescriptorBufferInfo pointer is now null). This only happens when VK_LAYER_LUNARG_core_validation is enabled, and if I disable it, the API call seems to work fine.
My sample is incomplete, so I can't say whether it works with the layer disabled, or if I have some error in my code. However, I have been staring at the values being passed in to this call, doing a sanity check, because I was certain I wasn't passing in a null pointer. Is this a bug, or is this expected behaviour?
Windows 10
LunarG SDK 1.0.8 (I'd like to be on 1.0.13, but that requires the newer AMD driver, which blue screens my computer)
EDIT:
It's not just zeroing out the structure I give it - I'm currently passing in only the first DescriptorWriteSet in a constant array, and it's zeroing the second as well. In fact, when I inspect the memory around the array, this layer is touching memory on either side of the array. This seems a lot more like a bug to me...
EDIT 2:
It turns out the problem stemmed from my code:
DescriptorSetLayoutBinding layout_bindings[]{
DescriptorSetLayoutBinding()
.Binding(0)
.Descriptors(DescriptorType::UNIFORM_BUFFER, 1)
.StageFlags(ShaderStageFlagBits::VERTEX),
DescriptorSetLayoutBinding()
.Binding(0)
.Descriptors(DescriptorType::COMBINED_IMAGE_SAMPLER, 1)
.StageFlags(ShaderStageFlagBits::FRAGMENT)
};
Both my layout bindings had the same binding index of 0. Of course, I would expect this to cause problems, but I would not expect this to cause the zeroing of structures passed in future API calls... I'm always hesitant to raise things like this as issues on Github, because more than half the time it's my fault that I'm getting the issue.
The VK_LAYER_LUNARG_core_validation layer should not be modifying the structure pointed to by pDescriptorWrites in the vkUpdateDescriptorSets. If you think it is doing this modification of the structure passed in, please post issue, along with repo case, to https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/issues.
We are finding issues (and reporting them) in EclipseLink's InformixPlatform class--the class responsible for adapting the Informix database to the requirements of the EclipseLink innards.
We have a couple of type conversion issues. For example, Informix supports two opaque literals (t and f--not the characters, but actual literals) as native boolean values. It appears that perhaps EclipseLink is trying to use SMALLINT instead as the database type.
Short of a lot of procedural code inside a SessionCustomizer, I cannot find a good place to correct or improve such global conversion behavior.
Where is the best place to register this global take-a-value-from-the-database-and-convert-it-to-a-Java-object behavior? Other questions seem to indicate that this is impossible, but I find that very hard to believe.
Build your own conversion manager class (extend org.eclipse.persistence.internal.helper.ConversionManager).
and override the method convertObjectToBoolean().
To enable the usage of your own conversion manager instance in eclipselink, use a SessionCustomizer and invoke session.getPlatform().setConversionManager()
However, when looking at the source code of this method it seems that the support of the t and f literals is already implemented (at least in eclipselink 2.3.3). But maybe there's a bug?
It's may be worth debugging this method while your application is running to really see what's going on there.