If I want to see what an image format can be used for I can do the vkGetPhysicalDeviceImageFormatProperties2() and set the usage flag for the image format. I've noticed if the format isn't supported for those usages and settings the structure I pass in is set to all zero, and I can know if the format supports those uses. So if I want to know if VK_FORMAT_R8G8B8_UINT supports sampling from a shader I set the VK_IMAGE_USAGE_SAMPLED_BIT in the usage flags and call that function.
What I wanted to know is if that's equivalent to calling another function, called vkGetPhysicalDeviceFormatProperties2(), exactly the same name but without 'image' in the name, give that function the format, and check whether the VK_IMAGE_USAGE_SAMPLED_BIT is set.
So using the first method I give the format and usages I want from it, and then check if the values returned are zero max width, max height, etc, meaning those usages aren't supported, versus the second method of passing the format, getting back the flags and then checking the flags.
Are these two methods equivalent?
TL;DR: Do your image format checking properly: ask how you can use the format, then ask what functionality is available from usable format&usage combinations.
If you call vkGetPhysicalDeviceImageFormatProperties2 with usage flags and the like that don't correspond to a supported image type, you get an error: VK_ERROR_FORMAT_NOT_SUPPORTED. It inherits this due to the fact that it is said to "behave similarly to vkGetPhysicalDeviceImageFormatProperties", which has an explicit statement about this error:
If format is not a supported image format, or if the combination of format, type, tiling, usage, and flags is not supported for images, then vkGetPhysicalDeviceImageFormatProperties returns VK_ERROR_FORMAT_NOT_SUPPORTED.
Now normally, a function which gives rise to an error will yield undefined values in any return values. But there is a weird exception:
If the combination of parameters to vkGetPhysicalDeviceImageFormatProperties2 is not supported by the implementation for use in vkCreateImage, then all members of imageFormatProperties will be filled with zero.
However, there's an explicit note saying that this was old, bad behavior and is only preserved for compatibility's sake. Being a compatibility feature means that you can rely on it, but you shouldn't. Also, it only applies to the imageFormatProperties data and not any of the extension structures you can pass.
So it's best to just ignore this and ask your questions in the right order.
Related
I know that by using 0:3 in this code in Pascal will put 3 decimal places to the result
var a,b:real;
begin
a:=23;
b:=7;
writeln(a/b:0:3);
readln;
end.
What I would like to know is if anyone has a source to learn what this : will do with other variables or if adding for example 0:3:4 will make a difference. Basically what : can do to a variable
For the exact definition of write parameters take a look at ISO standards 7185 and 10206, “Standard Pascal” and “Extended Pascal” respectively. These references are useless though if your compiler’s documentation does not make a statement regarding compliance with them. Other compilers have their own non-standard extensions, so the only reliable source of reference is your compiler’s documentation or even its source code if available.
[…] what this : will do with other variables […] Basically what : can do to a variable
As MartynA already noted this language is imprecise: The variables’ values are only read by write/writeLn/writeStr, thus leaving them unmodified.
[…] if adding for example 0:3:4 will make a difference.
To my knowledge a third write parameter is/was only allowed in PXSC, Pascal eXtensions for Scientific Computing. In this case the third parameter would indicate for the rounding mode (nonexistent or 0: closest printable number; greater than zero: round up; less than zero: round down).
Consider the following code:
#%%
Z=np.random.rand(len(X),len(Y))
X=np.arange(0,10)
Y=np.arange(0,10)
[fig1,ax1]=plt.subplots()
pcm=ax1.pcolor(X,Y,Z,cmap='seismic',edgecolors='black')
plt.colorbar(pcm,extend='max')
#[fig1,ax1]=plt.subplots()
#ax1.pcolor(X,Y,Z,cmap='seismic',edgecolors='black')
#plt.colorbar(extend='max')
The uncommented part works while the commented one doesnt. The error returned being:
RuntimeError: No mappable was found to use for colorbar creation. First define a mappable such as an image (with imshow) or a contour set (with contourf).
Looking at the documentation, it is said:
The matplotlib.cm.ScalarMappable (i.e., Image, ContourSet, etc.)
described by this colorbar. This argument is mandatory for the
Figure.colorbar method but optional for the pyplot.colorbar function,
which sets the default to the current image.
In this case, pcm correspond to the return value of ax1.pcolor() which type is "matplotlib.collections.Collection" and doesn't appear in the (non exhaustive) list given by the documentation.
How could I know from the documentation that I would indeed have to provide to plt.colorbar ax1.pcolor ? I know this from a stackoverflow post. How could I guess this from reading at the documentation ?
I know that from their input and output signatures, it's possible to determine the size of a gnuradio block's input and output items. I am wondering whether it's also possible to directly determine input and output type (float vs complex etc) from a block.
Within the GNU Radio runtime, only the size is stored. Type information only exists in the source code, and in GNU Radio Companion if you are using that.
So, no, you cannot get type information from a block object that already exists — except by imperfect outside-information strategies like looking up the block's name in the installed GRC data files to guess what the type is.
Because there are no types but only sizes, items can be reinterpreted if they are the same size, which may occasionally be useful; for example, you can connect a block producing "complex" to one expecting "vector of 2 floats" and get a useful result since a complex is represented as two floats.
Is it legal to use variables in printf without supplying the formatting (such as %d, %f).
for example:
printf("value is ok\r\n",myvalue);
The command compiles without errors nor warning, though I am not absolutely sure if it is legal or dangerous.
This reference says
There should be at least as many of these arguments as the number of values specified in the format specifiers. Additional arguments are ignored by the function.
Base on this information, your statement is perfectly legal, however I don't thinks that this is a good idea, since you code could quickly become confusing, which might lead to bugs.
Edit: The original source does not explicitly mention the case of zero arguments. To add another source, the linux man pages states
The format string is composed of zero or more directives.
This source does not discuss what happens with additional arguments. However, combining these two sources gives a definitive answer.
There were few attempts of questions answerered in regards to ICE03 (String overflow) for CustomActionData, but I cannot seem to determine/conclude the correct (or accepted) practice of how to go around this issue.
My current resolution was to reduce the length of the key-value-pair by keeping both the key and property names short, i.e. from:
<CustomAction Id="MyCustomActionData"
Property="MyCustomActionCA"
Value="myKeyName1=[SOME_PROPERTY_NAME];myKeyName2=[SOME_DESCRIPTIVE_PROPNAME]"/>
to:
<CustomAction Id="MyCustomActionData"
Property="MyCustomActionCA"
Value="k1=[K1];k2=[K2]"/>
But I feel that I'm just sweeping the problem under the rug and sooner or later, I'll encounter again (also, this is based on assumptions of my additional question below).
The more obvious solution is the re-evaluate and re-design it so that least amount of data needs to be passed down to the C# CustomAction (the classic "why would you want to declare a function method to pass 20 parameters?" question by all code-reviewers). Obviously, for most languages today, we can easily redesign the API and pass an object (as a class, struct, etc - depends on languages) that self-contains what it needs, but how does one go about it for inter-process calls (I've seen JSON RPC messages with reasonably large data and I'd usually wonder if it was because somebody tried to fix some legacy code by adding more and more until it got bloated rather than sitting down and re-design, which is not possible on some "11th hour" deadline that just has to get fixed in shortest time allowed).
Perhaps the solution is to create an XML file and use expat ('util:XmlFile') to search and replace the key-value-pair before calling CustomAction, and pass the filename of the altered XML as CustomActionData for CustomAction to use, which then in C# CustomAction code, it just deserializes it and treats it as objects. But that too feels a little klunky (it may also confuse the next developer who takes over my task in the future), not to mention if it was passwords we'd want to not have it in an XML file and keep it as Property with Hidden="yes"...
So my question is, what are the clean/elegant solutions or pattern (or practices) to resolve this issue of passing CustomActionData that may exceed table column size?
If I may also ask an additional question which is somewhat related, I am assuming that the linker (light) warning LGHT1076 is based on the length of the value (i.e. "keyA=[A];keyB=[B]") being too long, and so if I chose very short property variable and key-names, it would most likely not trigger this warning. But from what I understand, the table column size is 255 characters (please correct me if I'm wrong) thus during the run-time, if property value is longer than column size, it can cause some issue (or truncated)?
The solution I use is to create multiple properties and then concatenate the properties at the end into a single property, this way:
<CustomAction Id="SetSqlProperties"
Property="SqlProperties"
Value="SQL_LOGIN_ID=[SQL_LOGIN_ID];SQL_PASSWORD=[SQL_PASSWORD];
SQL_AUTH_TYPE=[SQL_AUTH_TYPE];SQL_SERVERS=[SQL_SERVERS]" />
<CustomAction Id="SetServerProperties"
Property="ServerProperties"
Value="Domain=[DOMAIN];ComputerName=[COMPUTER_NAME];
FullServerName=[FULLCOMPUTERNAME];Version=[ProductVersion];
ServerType=[SERVER_TYPE];SrvMode=[SrvMode]" />
<CustomAction Id="SetPropertiesConfigReplace"
Property="ConfigReplace"
Value="InstallFolder=[INSTALLFOLDER];[ServerProperties];[SqlProperties]" />
In this example I would use the property [ConfigReplace] containing all values from SQL Server and local server.
About the ICE03, in the documentation you can find this:
The string's length is greater than the column width specified by the column definition. Note that the installer does not internally limit the column width to the specified value. See Column Definition Format.
MSDN