Can any one tell me the format of the reference=\ lines in a Visual Basic 6 (VB6) project vbp file? Particularly what look like version numbers but I don't think are in the middle?
e.g.
Reference=*\G{835341D8-AF69-4753-BD84-89B39E426EBC}#1.0#0#C:\CASimpleCom.dll#CASimpleCom
I think the first part is the COM GUID, the last two parts are the location of the DLL and it's internal name but what are the numbers, i.e. #1.0#0#
The UUID is the typelib ID, the 1.0 is the typelib version number.
The third part, a "0" here, is the LCID. This is commonly 0 (unless a localized build of the library has been referenced).
After that comes the file that contains the type information, and last comes descriptive text (the typelib's HelpString value).
Related
I have created a TensorFlow Lite .tflite model which I plan to use on a microcontroller. However, this file must be converted to a C source file, i.e, a TensorFlow Lite for Microcontrollers model. TensorFlow documentation provides a simple way to convert to a C array with the unix command xxd. I am using Windows 10 and do not have access to the unix command and there are no alternative Windows methods documented. After searching superuser, I saw that xxd for Windows now exists. I downloaded the command and ran it on my .tflite model. The results were different than the hello world example.
First, the hello world example model.h file has a comment that say it was "Automatically created from a TensorFlow Lite flatbuffer using the command: xxd -i model.tflite > model.cc" When I ran the command, model.h was not "automatically created".
Second, comparing the model.cc file from the hello world example, with the model.cc file that I generated, they are quite different and I'm not sure how to interpret this (I'm not referring to the differences in the actual array). Again, in the example model.cc file, it states that it was "automatically created" using the xxd command. Line 28 in the example is alignas(8) const unsigned char g_model[] = { and line 237 is const int g_model_len = 2488;. In comparison, the equivalent lines in the file I generated are unsigned char _________g_model[] = { and unsigned int _________g_model_len = 4009981;
While I am not a C expert, I am not sure how to interpret the differences in the files and if I have generated the model.cc file incorrectly. I would greatly appreciate any insight or guidance here on how to properly generate both the model.h and model.cc files from the original model.tflite file.
After doing some experiments, I think this is why you are getting differences:
xxd replaces any non-letter/non-digit character of the path to the input file by an underscore ('_'). Apparently you called xxd with a path for the input file that has 9 such leading characters, perhaps something like "../../../g.model". The syntax of C allows only letters (a to z, A to Z), digits (0 to 9) and underscore as characters of objects' names, and the names need to start with a non-digit. This is the only "manipulation" xxd does to the name of an input file.
Since xxd knows nothing about TensorFlow, it could not had generated the copyright notice. Using this as indication, any other difference had been inserted by other means by the TensorFlow authors, despite the statement "Automatically created from a TensorFlow Lite flatbuffer ...". This could be done manually or by a script, unfortunately I did not find any hint in some quick research on their repository. Apparently the statement means just the data values.
So you need to edit your result:
Add any comment you see fit.
Add the compiler-specific alignas(8) to the array, if your compiler supports it.
Add the keywords const to the array and the length variable. This will tell the compiler to prohibit any write access. And probably this will place the data in read-only memory.
Rename array and length variables to g_model and g_model_len, respectively. Most probably TensorFlow expects these names.
Copy "model.cc" into "model.h", and then apply more editions, as the example demonstrated.
Don't be bothered by different values. Different contents of the model's file are the reason. It's especially simple to check the length variable, it has to have exactly the same value as the size of the input file.
EDIT:
On line 28 which is this text alignas(8) const unsigned char as shown in the example converted model. When I attempt to convert a model (whether it's my custom model or the "hello_world.tflite" example model) the text that would be on line 28 is unsigned char (any other text on that line is not in question). How is line 28 edited & explained?
Concerning the "how": I firmly believe that the authors of TensorFlow literally used an editor (an IDE or a stand-alone program like Notepad++ or Geany) and edited the line, or used some script to automate this.
The reason for alignas(8) is most probably that TensorFlow expects the data with an alignment of 8 bytes, for example because it casts the byte array to a structure that contains values of 8 bytes width.
The insertion of const will also commonly locate the model in read-only memory, which is preferable on most microcontrollers. If it were left out, the model's data were not only writable, but would be located in precious RAM.
On line 237, the text specifically is const int. When I attempt to convert a model (whether it's my custom model or the "hello_world.tflite" example model) the text that would be on line 237 is unsigned int (any other text on that line is not in question). Why are these two lines different in these specific places? It makes me believe that xxd on Windows is not functioning the same?
Again, I firmly believe this was edited manually or by a script. TensorFlow might expect this variable to be of data type int, but any xxd I tried (Windows and Linux) generates unsigned int. I don't think that your specific version of xxd functions differently on Windows.
For const the same thoughts apply as above.
Finally, when I attempt to convert the example model "hello_world.tflite" file using the xxd for windows utility, my resulting array doesn't match the example "hello_world.cc" file. I would expect the array values to be identical if the xxd worked. The last question is how to generate the "model.h" and "model.cc" files on Windows.
Did you note that the model you link is in another branch of the repository?
If I use the branch on GitHub as in your link to "hello_world.cc", I find in "../train/README.md" this archive hello_world_2020_12_28.zip. I unpacked it and ran xxd on the included "model.tflite". The result's data match the included "model.cc" in the archive. But it does not match the data of "hello_world.cc" in the same branch that you linked. The difference is already there.
My conclusion is, that the example result was not generated from the example model. This happens, since developers sometimes don't pay enough attention on what they commit. Yes, it's unfortunate, as it irritates and frustrates beginners like you.
But, as I wrote, don't let this make you headaches. Try the simple example, use the documentation as instructions on the process. Look at the differences in specific data as a quirk. You will encounter such things time after time when working with other's projects. It is quite normal.
I have a function module (FM) in SAP and I call it externally using startRFC. The only output of FM is one internal table. This table has only 1 column of type char(100) and I need to get it to text file. StartRFC works well, but if there is diacritics (for example Czech language: ěščřžýáíé) instead of these characters only hashes # appear.
Have someone ever solved similar issue?
If I call the same algorithm manually and write strings on screen in SAP, everything is ok. But startRFC somehow destroys it. The problem may be in the data transfer between SAP and startRFC. But I don't know how this transfer works.
I found a solution but it is terribly slow. It converts string to hexadecimal string using "gcl_conv_to_x->write" and "gcl_conv_to_x->get_buffer" than calls "SCMS_XSTRING_TO_BINARY" and you need a binary table. But it takes 5minutes to do all this stuff. Without this conversion my algorithm takes 15 seconds.
So finally a solution...
You need to create XSTRING variable and fill it with your text. To convert STRING to XSTRING use FM: SCMS_STRING_TO_XSTRING.
Then you will need an internal table with row type BAPICONTEN. It already contains component (column) of type SDOK_SDATX (RAW 1022).
And you just append a new line to this table like this:
data: my_table_row LIKE LINE OF my_table.
my_table_row-line = my_xstring.
APPEND my_table_row INTO my_table.
This table (my_table) can be returned via RFC and will contain Cyrillic, German characters etc..
I am just a beginner, so do not ask me how to create the table, please :)
I used max(list.files(path, "my_files_v")) to read in the latest my_files_v version.
The directory had files of:
my_files_v1, my_files_v2, ... my_files_v9
My code seemed to work perfectly fine as the script read in always the my_file_v with the highest version until I came to version _v10. From that point onwards max(list.files(..)) always detected _v9 as the max and therefore skipped _v10 and _v11 etc.
One solution would be to extract the version number from the string using substr or something like that but is there a better way of doing that? If not, does anyone know how to extract that pattern from a string as I am very poor regarding that
You could use:
max(as.integer(gsub('my_files_v', '', list.files(path, "my_files_v")))
assuming your files do not have extensions like you've shown. However, so they sort properly in my file browsers, I usually name files with zero padding. In R you can do that with sprintf:
sprintf('%03d', 1:10)
For what its worth, to extract the number portion of the file name you can use regular expressions and grouping:
gsub('my_files_v([0-9]+)\\.Rdata', '\\1', list.files(path, 'my_files_v'))
I have seen that my Visual C++ projects have the following declarations that use COMMAS instead of DOTS for versions:
#define FILEVER 11,0,2,0
#define PRODUCTVER 11,0,2,0
#define STRFILEVER "11, 0, 2, 0\0"
#define STRPRODUCTVER "11, 0, 2, 0\0"
The MS article here also has the same values with commas (actually the above declarations are based on that article). Why are we using COMMAS here? When I open the compiled file properties, I see FileVersion as 11.0.2.0 but ProductVersion as 11,0,2,0 - for which my QA friends say that its a bug :). Is there some standard or maybe some internal mechanism that I am missing?
In the first two definitions because Microsoft resource file syntax calls for commas. For the later two definitions the Microsoft convention sticks to commas there too. Microsoft wants to differ, probably.
The file version is taken from the non-string variant and gets printed with dots in file explorer. The product version gets taken from the string. You could probably write the string with dots yourself. It's a string, it shouldn't matter. But you'll have to edit the .rc file manually—Visual Studio will write commas.
As for the first two definitions, I can see reason for choosing commas in general C++. If you had 11.0.2.0, it would be syntax error in about any context and the only thing you could do is convert it to string with the # operator. But with commas, you can expand it to definition of array or structure. Like int version[] = { 11,0,2,0 };. That's useful if you want to have version check in code.
I have an Installshield2010 project that has had this warning since before my employment
ISDEV : warning -3028: The string ID "IDS_ERROR_27555" was not found in the string table. It is referenced in the table:"Error" in column:"Message".
Looking in the svn history, this row was added to Error table a few years ago - alongside a seemingly unrelated change
<row><td>27555</td><td>##IDS_ERROR_27555##</td></row>
However as the error indicates, there is no corresponding entry in the ISString table.
I'm curious how it got added. The IDS_ERROR strings look like canned strings, it seems really unlikely the person who added this to my ism did so manually.
Of course Flexera's forums are a ghost town. I did find an ism that has that string defined as
<row><td>IDS_ERROR_27555</td><td>1033</td><td>Error attempting to apply permissions to object '[2]'. System error: [3] ([4])</td><td>0</td><td/><td>1394414478</td></row>
Do any of your ism's have IDS_ERROR_27555 defined or referenced? Am very sure I can delete the string and be no worse for wear... but it bugs me to not know what happened.
I don't remember in which version we added these strings, but you can get them by importing the strings file for your language (1033.txt for English) under the Languages folder. Upgrading across versions of InstallShield should have added this string. You can add them yourself by importing the strings file in the String Editor view. Of course if you've modified other strings, you'll want to ensure that you keep your preferred version.