How do I set a int32 to use a fixed size for encoding?
In the API, it says
PB_LTYPE_FIXED32 0x04 32-bit integer or floating point.
But what option do I set in the .proto file to encode a int32 as a PB_LTYPE_FIXED32 as opposed to a PB_LTYPE_VARINT?
In the function encode_basic_field the fields structure, which is autogenerated, stores the field type which means that this information is set in .proto file somehow.
I think you should try "int32_t" instead of int32.
please check the "nanopb" project, in the file "nanopb_generator.py", there is a dictionary called "datatypes", here is some code:
FieldD.TYPE_FIXED32: ('uint32_t', 'FIXED32', 4, 4),
FieldD.TYPE_SFIXED32: ('int32_t', 'SFIXED32', 4, 4),
because it's my first time to see the "nanopb" project, I'm not 100% sure whether it will work or not.
Related
I am trying to use the GetShortPathName() function to give me the short version of two paths, but it succeeds in only one path and fails in the other path.
// Get the game directory path
wchar_t GameDirPath[MAX_PATH] = L"\0";
GetCurrentDirectory(MAX_PATH, GameDirPath);
// Get the engine directory path
wchar_t EngineDirPath[MAX_PATH] = L"\0";
wcscat(EngineDirPath, GameDirPath);
wcscat(EngineDirPath, L"\\Assets\\Engine\\");
// Get the short path of the engine directory
wchar_t EngineShortPath[MAX_PATH] = L"\0";
GetShortPathName(EngineDirPath, EngineShortPath, MAX_PATH);
The following gives me the correct short path:
D:\Games\NEEDFO~1\Assets\Engine\
But this one doesn't:
D:\Games\FIFA 97\Assets\Engine\
Note that the two examples exist in the same folder "Games".
In short:
I want to pass the path to "DOSBox.exe" as a parameter but it doesn't accept the windows paths like this "D:\Games\FIFA 97\Assets\Engine", so you must convert it to a DOS path like this "D:\Games\FIFA97~1\Assets\Engine", so, I try to use the GetShortPathName() function to do that mission.
Why does this problem happen, and how can I solve it?
As the documentation explicitly states:
If the specified path is already in its short form and conversion is not needed, the function simply copies the specified path to the buffer specified by the lpszShortPath parameter.
The API behaves as documented. There's nothing that needs to be fixed.
Back to 90s, when DOS OS was largely used, files and directories names were limited to a maximum length of 8 characters (8.3 format; meaning 8 bytes for the file name and 3 for the file extension).
So hello.txt file was admitted, and helloguys.txt (9 chars log) was "illegal".
With Windows this limitation has beeen removed, and short names have been introduced in order to convert paths to DOS compliant format.
Now that we know what a short path is, we can analyze your case. In path
D:\Games\Fifa 97\Assets\Engine\
every token is DOS compliant. So what is the short version of this path? Well, the path itself. And that's why GetShortPathName( ) returns an unchanged path.
You can find a wide description in docs page.
I just created a simple PDF Document containing a word "Test" in it and created a byte stream out of it in C# Console Application:
buff = File.ReadAllBytes(<Path of File>);
The size of the file is around 9,651 bytes. I also created a Win32 C dll that exports a function which takes the file byte array and the length of the byte array as an argument, declared in C# using this:
[DllImport("<path to dll>", CallingConvention = CallingConvention.Cdecl)]
public static extern int file_data(byte[] byteArray, int length);
The method in C dll is exported as below:
#define FILEDATA_API __declspec(dllexport)
FILEDATA_API int file_data(char *byteArray, int size);
I then invoked ret = file_data(buff, buff.length); and in the C code, wrote the character pointer received directly to a temp file character by character as below:
while (length> 0)
{
fprintf(outFile, "%c", *fileData); //fileData is the actual byte array received from C# Code
fileData++;
length--;
}
But the problem arises here, the C code that dumps out the byte array to a file character by character generates a file of size 9,755 bytes. Most of the content inside it seems to look correct, except some new lines that gets introduced(as far as i know and may be some additional data), which causes the PDF file to get corrupted and this dumped out version does not open in Adobe. Can someone please provide some pointers on where I might be going wrong? I cannot use %s in fprint since some combination of the byte array in the PDF results in null terminated string in C which then dumps out even lesser data than I expect.
Thanks.
UPDATE:
The desired behavior is that the file byte array as received from C#
and when written using C code to a file should make the file open
successfully in Adobe.
The code present in the problem should be
sufficient for someone to generate a win32 dll, that simply writes
out the char pointer to a file, but I have added few more details.
You're probably calling fopen without the b mode flag. Append b to your mode specifier:
FILE *outFile = fopen("file.txt", "wb")
From this site (emphasis mine):
Text files are files containing sequences of lines of text. Depending on the environment where the application runs, some special character conversion may occur in input/output operations in text mode to adapt them to a system-specific text file format. Although on some environments no conversions occur and both text files and binary files are treated the same way, using the appropriate mode improves portability.
In my experience, this "conversion" on Windows changes \n to \r\n at least.
In file text.txt I have this sentenc:
"Příliš žluťoučký kůň úpěl ďábelské ódy."
(I think Windows uses Windows-1250 code page to represent this text.)
In my program I save it to a buffer
char string[1000]
and render string with ttf to SDL_Surface *surface
surface = TTF_RenderText_Blended(font, string, color);
/*(font is true type and support this text)*/
But it gives me not correct result:
I need some reputation points to post images
so I can only describe that ř,í,š,ž,ť,ů,ň,ď are not displayed correctly.
Is it possible to use ttf for rendering this sentence correctly?
(I tried also TTF_RenderUTF8_Blended, TTF_RenderUNICODE_Solid... with worse result.)
The docs for TTF_RenderText_Blended say that it takes a Latin-1 string (Windows-1252) - this will be why it isn't working.
You'll need to convert your input text to UTF-8 and use RenderUTF8, or to UTF-16 and use RenderUNICODE to ensure it is interpreted correctly.
How you do this depends on what platform your app is targeted to - if it is Windows, then the easiest way would be to use the MultiByteToWideChar Win32 API to convert it to UTF-16 and then use the TTF_RenderUNICODE_Blended to draw it.
My solution will be this:
Three input files. In first file there will be a set of symbols from czech alphabet.
Second file will be sprite bitmap file where graphic symbols will be sorted in the
same order as in first file. In my program symbols from third input file will be compared with symbols from first file and right section of sprite will be copied on sreen one by one.
I will leave out sdl_ttf. It has some advantages and disadvantages but I think it will work for my purposes.
Thanks for all responses
This is format description of Vray's .vrscene file:
http://spot3d.com/vray/help/maya/sdk22/vrscene_format.html
I interested in paragraph about "Compressed hexadecimal lists". There is said that compressed list equals to header ("ZIPB") + uncompressed size + compressed size + zlib compressed string.
For example, in my .vrscene I have such compressed list: "ZIPB2C01000015000000e7X81OT0TG4S5ENN3D8Z8IVAPODONF7EA"
It means that "e7X81OT0TG4S5ENN3D8Z8IVAPODONF7EA" -- zlib compressed string. But I dont know how to decompress it. When I do Base64 decode I receive header 0x7bb5. I dont know such a header. Maybe I shouldnt use Base64 and should do something other instead?
So I know this is old, but the information in here was enough to get me to a solution, the only difference being that I have a different compressed list from a different vrscene file.
As you established, you need to remove the first 20 characters from the string since they are just descriptors used by vray and not part of the compressed data.
import base64, zlib
data = "ZIPCB81900003C000000eAHt0iERAAAMxLDC9694MkYCaqCXVZMHDDDAAAMMMMAAAwwwwAADDDDAAAMMMMAAAwwwwMC7gQMbojNx"
encoded_data = data[20:] #"eAHt0iERAAAMxLDC9694MkYCaqCXVZMHDDDAAAMMMMAAAwwwwAADDDDAAAMMMMAAAwwwwMC7gQMbojNx"
compressed_data = base64.b64decode(encoded_data)
hex_data = zlib.decompress(compressed_data)
# b'\x08\x00\x00\x00\x08\x00\x00\x00\x08\x00\x00\x00\x08\x00\x00\x00\x08\x00\x00\x00\x08\x00\x00\x00\x08\x00\x00\x00\x08\x00\x00\x00\x08\x00\x00\x00...'
Once you are at this point you have the raw hexidecimal list without any compression. If you want to turn that into readable python data types you can use struct to unpack them depending on what data type is stored in the list.
Further reading in the documentation that was linked explains that all such lists are stored as 4 bytes per entry (written as 8 half-bytes in the docs, but as far as python is concerned it's just 4 bytes). With that information we can determine that the number of entries in the list should be the length of the hex_data / 4 and build a struct format string that will unpack the whole list at once.
import struct
#I have a list of ints as my example, but for floats you could use "f" instead
format = "i" * int(len(hex_data)/4)
values = struct.unpack(format, hex_data)
# [8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, ...]
There are also Color lists and Vector lists, but they are just float lists that need to be unflattened.
vectors = []
for i in range(0, int(len(values)), 3):
vectors.append(tuple(values[i:i+3]))
Since this method seems to be working with all of the compressed hex lists I've been encountering up to this point it seems like there is either an issue with the file you were originally trying to parse data from, or the developers were using an encoding method other than base64 at one point but have adopted base64 encoding since then (Perhaps that's the reason for "ZIPC" appearing in my files as opposed to "ZIPB in your example).
The documentation says hexadecimal, but the string you provided has other characters. It is probably not base64, since you don't get a valid zlib header at the start. (By the way, I get 0x7b 0xb5 when I decode it with base64, not what you got. But either way, it's not a zlib header.) Do you have a better source for the description of the format?
The data must have been highly compressible, e.g. all zeros, since it apparently went from 4140 bytes to 21 bytes.
I am trying to read some settings from php.ini using zend. The API that I am using is
long zend_ini_long(char *name, uint name_length, int orig)
But it always returns 0. I have double checked the name and also made sure that the value I am specifying in php.ini is greater then 0. Is there anything I am missing?
long maxwait = zend_ini_long("max_execution_time",
sizeof("max_execution_time"), 0);
The problem is that ZEND_STRL is not returning the right length for the way that this API is intended to be used, so don't use it.
I should add that most of the hash tables maintained internally by PHP assume that the NUL terminator character is included in the length of the string being hashed (its part of the overall binary safety concept), which is why we use sizeof() rather than strlen() or sizeof()-1.
Do you need to read php.ini file? Maybe the information is available with phpinfo()?
But if you must are the "www user" allowed to read the file at all? If you change permissions does it still return 0?
You can use the standard php function: ini_get('var-name');
Example:
ini_get('include_path');