Generating const arrays in C from a database - perl

I have to provide some C++ code consisting of const arrays initialised with well-known values.
More precisely, several arrays containing
Between 0 and 255 strings for a text-based user interface
Metadata, like lengths and positions of those strings
Data representing a hierarchical menu structure
Metadata connecting the menu structure with the strings and configuration data stored elsewhere
The menu items are accessed by their index in an array, and are related to other linked menu items, also accessed by index.
Here is the code I want to generate automatically from a better editable document:
/* gl_PsNMenuType holds one byte of metadata for each menu. This byte will describe
whether the menu only refers to a bunch of submenus or if it is a terminal item, where
the user actually can enter a setting to be saved */
const uint8_t gl_PsNMenuType[MAXMENUS] PROGMEM = { 0, 0, 0, 0, 0};
/* gl_PsNMenuParent holds the index of each menu's parent menu. i.e. tree one step up */
const uint8_t gl_PsNMenuParent[MAXMENUS] PROGMEM = { 0, 0, 0, 0, 0, 1, 1, 1, 2, 2, 2, 3, 3, 3}; // referenz auf den übergeordneten MP
/* gl_PsNMenuFixTexts is a list of identifiers text snippets which build the layout of
the respective menu. The text snippets are stored in gl_PsFixTexts and the respective
index of a text snippet is saved here. MFTS is a list sentinel*/
const uint8_t gl_PsNMenuFixTexts[MAXMENUS][MAXFIXTEXTSPM] PROGMEM = {
{ 20, 2, MFTS}, // text snippets for menu 0
{2, 9, 1, MFTS}, // for menu 1
{2, 10, MFTS}, //2
{2, 11, MFTS}, //3
{2, 13, MFTS} //4
};
/* gl_PsNMenuParentListText holds the identifiers of the text snippets which shall be
displayed by the parent menu while selection before descending to the submenus. There's
one such snippet for each menu. */
const uint8_t gl_PsNMenuParentListText[MAXMENUS] PROGMEM = { 0, 9, 10, 11, 13};
/* gl_PsNMenuFtPos closely relates to gl_PsNMenuFixTexts. The positions on the display
for each text snippet of a menu are stored here. */
const uint8_t gl_PsNMenuFtPos[MAXMENUS][MAXFIXTEXTSPM] PROGMEM = { // Liste der Fixtextpositionen
{ 0, 5, MFTS, MFTS, MFTS}, // 0
{ 0, 5, MFTS, MFTS, MFTS}, // 1
{ 0, 5, MFTS, MFTS, MFTS}, // 2
{ 0, 5, MFTS, MFTS, MFTS}, // 3
{ 0, 5, MFTS, MFTS, MFTS}, // 4
};
/* gl_PsNMenuChildren stores the indices of all submenus reachable from a certain menu
this is essentially the structure of the menu tree MAXMENUS is used for array size and
also as sentinel*/
const uint8_t gl_PsNMenuChildren[MAXMENUS][MAXMENUCHILDREN] PROGMEM = {
{ 5, 1, 2, 3, 4, MAXMENUS}, // 0
{ 4, 7, 8, 9, MAXMENUS}, // 1
{1, MAXMENUS}, //2
{1, MAXMENUS}, // 3
{3, 5, 6, MAXMENUS} // 4
};
/* finally the text snippets */
const uint8_t gl_PsFixTexts[MAXFIXTEXTS][MAXFIXTEXTLEN] PROGMEM = {
{5, 0x54, 0x65, 0x73, 0x74, 0x31 }, // 0: Test1
{9, 0x62, 0x6c, 0x61, 0x62, 0x6c, 0x61, 0x62, 0x6c, 0x62 }, // 1: bla
{4, 0x4d, 0x65, 0x6e, 0x75}, // 2: Menu
{4, 0x4d, 0x61, 0x69, 0x6e}, // 20: Main
{4, 0x65, 0x78, 0x69, 0x74}, // 21: exit
{4, 0x62, 0x61, 0x63, 0x6b} // 22: back
};
This is shortened for brevity and dysfunctional in this state.
As the contents of those arrays are exclusively uint8_t characters it would be much simpler to write the data automatically, while ensuring that the referencing indices are all correct.
I want some other data describing the menu structure in a more elaborate but maintainable way.
I thought about making a spreadsheet where I could show the hierarchy across the columns and enter all the data. Then some tool would be needed to break down the hierarchy.
I hope someone can let me know of any tools that are suitable for this task. If there's nothing available then I have to write a Perl conversion program. Are there any useful CPAN libraries?
Edit: some further explanation of the use of the arrays
This data will be utilised by an user interface function, which is rather simplicistic. There will be an identifier pointing to the actual menu entry, which is edited or viewed by the user. This identifier will be used as index wherever MAXMENUS is defining the array size. these arrays describe the look and feel of every menu entry. The menu entries refer to different strings (gl_PsFixTexts) and positions (gl_PsNMenuFtPos) which declare, how and where to display strings when processing a certain menu entry.
The most important arrays are gl_PsNMenuParent and gl_PsNMenuChildren which point to the menu entries above and below in hierarchy. This is, how the code will let the user navigate through the menu structure.
There's also some information if this is an terminal entry in the menu tree, i.e. if there's some data to change, which again means modifying a setting for the software.

Here is my best answer, based on what you have told us.
Menu information like that is commonly stored as XML. An XML data file would allow you to relate menu items to their text labels and their children quite expressively.
In the end you could write a GUI front end that would present that XML in a graphical form and allow you as much facility and complexity as want to write.
In the end, it is the XML file that is the authority on the interface structure, and which can be converted very easily with Perl to any format that you desire.
Also, following on from what #MatsPetersson said in his comment, I would much rather see
{9, 'b', 'l', 'a', 'b', 'l', 'a', 'b', 'l', 'a'}, // 1: blablabla
which is certain to be acceptable to as a uint8_t [] initialiser.
If you want further help then you will have to expand your description with a line-by-line explanation of what your "desired output" means in English.

Related

AES encryption under contiki on CC2650

I am currently trying to add AES encryption to an existing beacon-demo that uses the TI cc2650 sensortag. I am using the AES API provided by contiki under core/lib.
My main looks like this:
static const uint8_t AES_key[16] = { 0xC0 , 0xC1 , 0xC2 , 0xC3 ,
0xC4 , 0xC5 , 0xC6 , 0xC7 ,
0xC8 , 0xC9 , 0xCA , 0xCB ,
0xCC , 0xCD , 0xCE , 0xCF };// AES Key
static uint8_t plain_text[16] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13,
14, 15, 16}; // Plain-text to be encrypted.
const struct aes_128_driver AES_128;
.
.
.
printf("Plain_Text: %d \r\n", plain_text);
AES_128.set_key(AES_key);
AES_128.encrypt(plain_text);
printf("Encrypted_Text: %p\r\n", plain_text);
Unfortunately when I run the code the plain text is unchangeable. Using some extra prints, I realize that the encrypt function is working but the output is still unchangeable. Can someone please tell me what am I doing wrong here?
Please note that I already added the following line to my conf file:
#define AES_128_CONF aes_128_driver
Well as #kfx pointed out in the comments const struct aes_128_driver AES_128 was shadowing the global variable.

Lihaoyi PPrint Deep Tree

title: Lihaoyi PPrint Deep Tree
link: Lihaoyi PPrint Deep Tree
I have a "deep" tree of case classes that I want to pprint as "like Scala" source code.
... because I want to view, copy and paste them to make a UnitTest
I am using lihaoyi's pprint to perform the stringify of the values, BUT after a few levels, pprint stops printing.
I've checked in the tokenize thing and the instance is being emitted as-is; you can see that the strings aren't being excaped.
I can (manually) "tweak" my tests to test parts of the results and get my pretty source, but ... it feels wrong.
Original "Lack of deep" printout
Module(
Set(),
Set(
Material(
"testTextLayoutContainer",
List(
Attribute("Position", VecSingle(2)),
Attribute("UV", VecSingle(2)),
Attribute("Color", VecFixed(4))
),
List(
UniformInstance("ProjMtx", MatSingle(4, 4)),
UniformInstance("Texture", Texture(2, VecFixed(4)))
),
Set(
//
// this is the line that's not being pprinted
//
Program(ImGui,testTextLayoutContainer,Set(Attribute(Color,VecFixed(4)), Attribute(Position,VecSingle(2)), Attribute(UV,VecSingle(2))),Set(UniformInstance(Texture,Texture(2,VecFixed(4))), UniformInstance(ProjMtx,MatSingle(4,4))),Set(VaryingCopy(Attribute(Color,VecFixed(4))), VaryingCopy(Attribute(UV,VecSingle(2)))),List(Lookup(UniformInstance(ProjMtx,MatSingle(4,4))), Lookup(Attribute(Position,VecSingle(2))), Literal(0.0), Literal(1.0), Construct(VecSingle(4),List(Lookup(Attribute(Position,VecSingle(2))), Literal(0.0), Literal(1.0))), External(mat*vec,List(Lookup(UniformInstance(ProjMtx,MatSingle(4,4))), Construct(VecSingle(4),List(Lookup(Attribute(Position,VecSingle(2))), Literal(0.0), Literal(1.0)))),VecSingle(4)), Output(Vertex(ProductTransform(Lookup(UniformInstance(ProjMtx,MatSingle(4,4))),Construct(VecSingle(4),List(Lookup(Attribute(Position,VecSingle(2))), Literal(0.0), Literal(1.0))))),External(mat*vec,List(Lookup(UniformInstance(ProjMtx,MatSingle(4,4))), Construct(VecSingle(4),List(Lookup(Attribute(Position,VecSingle(2))), Literal(0.0), Literal(1.0)))),VecSingle(4))), Lookup(Attribute(Color,VecFixed(4))), Output(VaryingCopy(Attribute(Color,VecFixed(4))),Lookup(Attribute(Color,VecFixed(4)))), Lookup(Attribute(UV,VecSingle(2))), Output(VaryingCopy(Attribute(UV,VecSingle(2))),Lookup(Attribute(UV,VecSingle(2))))),List(Lookup(VaryingCopy(Attribute(Color,VecFixed(4)))), Access(Lookup(VaryingCopy(Attribute(Color,VecFixed(4)))),x), Lookup(UniformInstance(Texture,Texture(2,VecFixed(4)))), Lookup(VaryingCopy(Attribute(UV,VecSingle(2)))), Sample(UniformInstance(Texture,Texture(2,VecFixed(4))),Lookup(VaryingCopy(Attribute(UV,VecSingle(2))))), Access(Sample(UniformInstance(Texture,Texture(2,VecFixed(4))),Lookup(VaryingCopy(Attribute(UV,VecSingle(2))))),x), External(*,List(Access(Lookup(VaryingCopy(Attribute(Color,VecFixed(4)))),x), Access(Sample(UniformInstance(Texture,Texture(2,VecFixed(4))),Lookup(VaryingCopy(Attribute(UV,VecSingle(2))))),x)),VecFixed(1)), Access(Lookup(VaryingCopy(Attribute(Color,VecFixed(4)))),y), Access(Sample(UniformInstance(Texture,Texture(2,VecFixed(4))),Lookup(VaryingCopy(Attribute(UV,VecSingle(2))))),y), External(*,List(Access(Lookup(VaryingCopy(Attribute(Color,VecFixed(4)))),y), Access(Sample(UniformInstance(Texture,Texture(2,VecFixed(4))),Lookup(VaryingCopy(Attribute(UV,VecSingle(2))))),y)),VecFixed(1)), Access(Lookup(VaryingCopy(Attribute(Color,VecFixed(4)))),z), Access(Sample(UniformInstance(Texture,Texture(2,VecFixed(4))),Lookup(VaryingCopy(Attribute(UV,VecSingle(2))))),z), External(*,List(Access(Lookup(VaryingCopy(Attribute(Color,VecFixed(4)))),z), Access(Sample(UniformInstance(Texture,Texture(2,VecFixed(4))),Lookup(VaryingCopy(Attribute(UV,VecSingle(2))))),z)),VecFixed(1)), Access(Lookup(VaryingCopy(Attribute(Color,VecFixed(4)))),w), Access(Sample(UniformInstance(Texture,Texture(2,VecFixed(4))),Lookup(VaryingCopy(Attribute(UV,VecSingle(2))))),w), External(*,List(Access(Lookup(VaryingCopy(Attribute(Color,VecFixed(4)))),w), Access(Sample(UniformInstance(Texture,Texture(2,VecFixed(4))),Lookup(VaryingCopy(Attribute(UV,VecSingle(2))))),w)),VecFixed(1)), Construct(VecFixed(4),List(External(*,List(Access(Lookup(VaryingCopy(Attribute(Color,VecFixed(4)))),x), Access(Sample(UniformInstance(Texture,Texture(2,VecFixed(4))),Lookup(VaryingCopy(Attribute(UV,VecSingle(2))))),x)),VecFixed(1)), External(*,List(Access(Lookup(VaryingCopy(Attribute(Color,VecFixed(4)))),y), Access(Sample(UniformInstance(Texture,Texture(2,VecFixed(4))),Lookup(VaryingCopy(Attribute(UV,VecSingle(2))))),y)),VecFixed(1)), External(*,List(Access(Lookup(VaryingCopy(Attribute(Color,VecFixed(4)))),z), Access(Sample(UniformInstance(Texture,Texture(2,VecFixed(4))),Lookup(VaryingCopy(Attribute(UV,VecSingle(2))))),z)),VecFixed(1)), External(*,List(Access(Lookup(VaryingCopy(Attribute(Color,VecFixed(4)))),w), Access(Sample(UniformInstance(Texture,Texture(2,VecFixed(4))),Lookup(VaryingCopy(Attribute(UV,VecSingle(2))))),w)),VecFixed(1)))), Output(Fragment(Construct(VecFixed(4),List(ProductAtomic(Access(Lookup(VaryingCopy(Attribute(Color,VecFixed(4)))),x),Access(Sample(UniformInstance(Texture,Texture(2,VecFixed(4))),Lookup(VaryingCopy(Attribute(UV,VecSingle(2))))),x)), ProductAtomic(Access(Lookup(VaryingCopy(Attribute(Color,VecFixed(4)))),y),Access(Sample(UniformInstance(Texture,Texture(2,VecFixed(4))),Lookup(VaryingCopy(Attribute(UV,VecSingle(2))))),y)), ProductAtomic(Access(Lookup(VaryingCopy(Attribute(Color,VecFixed(4)))),z),Access(Sample(UniformInstance(Texture,Texture(2,VecFixed(4))),Lookup(VaryingCopy(Attribute(UV,VecSingle(2))))),z)), ProductAtomic(Access(Lookup(VaryingCopy(Attribute(Color,VecFixed(4)))),w),Access(Sample(UniformInstance(Texture,Texture(2,VecFixed(4))),Lookup(VaryingCopy(Attribute(UV,VecSingle(2))))),w))))),Construct(VecFixed(4),List(External(*,List(Access(Lookup(VaryingCopy(Attribute(Color,VecFixed(4)))),x), Access(Sample(UniformInstance(Texture,Texture(2,VecFixed(4))),Lookup(VaryingCopy(Attribute(UV,VecSingle(2))))),x)),VecFixed(1)), External(*,List(Access(Lookup(VaryingCopy(Attribute(Color,VecFixed(4)))),y), Access(Sample(UniformInstance(Texture,Texture(2,VecFixed(4))),Lookup(VaryingCopy(Attribute(UV,VecSingle(2))))),y)),VecFixed(1)), External(*,List(Access(Lookup(VaryingCopy(Attribute(Color,VecFixed(4)))),z), Access(Sample(UniformInstance(Texture,Texture(2,VecFixed(4))),Lookup(VaryingCopy(Attribute(UV,VecSingle(2))))),z)),VecFixed(1)), External(*,List(Access(Lookup(VaryingCopy(Attribute(Color,VecFixed(4)))),w), Access(Sample(UniformInstance(Texture,Texture(2,VecFixed(4))),Lookup(VaryingCopy(Attribute(UV,VecSingle(2))))),w)),VecFixed(1)))))))
)
)
)
)
You can provide a height and a width, so if you provide a big enough value it will show it all.
scala> pprint.pprintln(Seq(1, 2, 3), width = Int.MaxValue, height = Int.MaxValue)
so
# pprint.pprintln(1 to 10, 3, 10)
Range.Inclusive(
1,
2...
can be
# pprint.pprintln(1 to 10, Int.MaxValue, Int.MaxValue)
Range.Inclusive(1, 2, 3, 4, 5, 6, 7, 8, 9, 10)
Edit:
as mentioned in the docs this is a feature to stop out of memory errors when printing really big data structures.
http://www.lihaoyi.com/upickle-pprint/pprint/#GettingStarted

Is there any replacement for "GtkRuler" in GTK3?

I want to display the horizontal and vertical ruler on the frame with gtk3.
this is my frame:
I want to display ruler on the frame like this:
BUT GtkRuler has been removed from GTK 3 for being unmaintained and too specialized!!
this is my GTK3/c cpde:
/* The horizontal ruler goes on top. As the mouse moves across the
* drawing area, a motion_notify_event is passed to the
* appropriate event handler for the ruler. */
hrule = gtk_hruler_new ();
gtk_ruler_set_metric (GTK_RULER (hrule), GTK_PIXELS);
gtk_ruler_set_range (GTK_RULER (hrule), 7, 13, 0, 20);
g_signal_connect_swapped (area, "motion_notify_event",
G_CALLBACK (EVENT_METHOD (hrule, motion_notify_event)),
hrule);
gtk_table_attach (GTK_TABLE (table), hrule, 1, 2, 0, 1,
GTK_EXPAND|GTK_SHRINK|GTK_FILL, GTK_FILL, 0, 0);
/* The vertical ruler goes on the left. As the mouse moves across
* the drawing area, a motion_notify_event is passed to the
* appropriate event handler for the ruler. */
vrule = gtk_vruler_new ();
gtk_ruler_set_metric (GTK_RULER (vrule), GTK_PIXELS);
gtk_ruler_set_range (GTK_RULER (vrule), 0, YSIZE, 10, YSIZE );
g_signal_connect_swapped (area, "motion_notify_event",
G_CALLBACK (EVENT_METHOD (vrule, motion_notify_event)),
vrule);
gtk_table_attach (GTK_TABLE (table), vrule, 0, 1, 1, 2,
GTK_FILL, GTK_EXPAND|GTK_SHRINK|GTK_FILL, 0, 0);
What ideas on how to solve this task would you suggest? Or on what resource on the internet can I find help?
If your code has a compatible license, you can simply copy the GtkRuler out of GTK 2 into your code, making any changes necessary to make it work with GTK 3.

Convert powershell cmdlet to C#

How could I convert the follow powershell command to C# code, especially parameters for -index.
Get-Mailbox | select-object -index 0, 1, 2, 3, 4, 5
I just want to retrieve the mail box many times to avoid extremely big memory usage.
How to set 0, 1, 2, 3, 4, 5 to CommandParameters?
I'm not a programmer but this is should get you closer:
Command cmdMailbox = new Command("Get-Mailbox");
cmdMailbox.Parameters.Add("Identity", 'someone');
Command cmdSelect = new Command("Select-Object");
int[] indexes = new int[] {0,1,2,3,4,5};
cmdSelect.Parameters.Add("Index",indexes );

How to extract information from the llvm metadata

I have the following piece of code:
int main(int argc, char *argv[])
{
int a = 2;
int b = 5;
int soma = a + b;
//...}
The resulting llvm bitcode is:
define i32 #main(i32 %argc, i8** %argv) #0 {
entry:
...
%a = alloca i32, align 4
%b = alloca i32, align 4
%soma = alloca i32, align 4
...
call void #llvm.dbg.declare(metadata !{i32* %a}, metadata !15), !dbg !16
store i32 2, i32* %a, align 4, !dbg !16
call void #llvm.dbg.declare(metadata !{i32* %b}, metadata !17), !dbg !18
store i32 5, i32* %b, align 4, !dbg !18
call void #llvm.dbg.declare(metadata !{i32* %soma}, metadata !19), !dbg !20
%0 = load i32* %a, align 4, !dbg !20
%1 = load i32* %b, align 4, !dbg !20
%add = add nsw i32 %0, %1, !dbg !20
store i32 %add, i32* %soma, align 4, !dbg !20
...
!1 = metadata !{i32 0}
!2 = metadata !{metadata !3}
...
!15 = metadata !{i32 786688, metadata !3, metadata !"a", metadata !4, i32 6, metadata !7, i32 0, i32 0} ; [ DW_TAG_auto_variable ] [a] [line 6]
!16 = metadata !{i32 6, i32 0, metadata !3, null}
!17 = metadata !{i32 786688, metadata !3, metadata !"b", metadata !4, i32 7, metadata !7, i32 0, i32 0} ; [ DW_TAG_auto_variable ] [b] [line 7]
!18 = metadata !{i32 7, i32 0, metadata !3, null}
!19 = metadata !{i32 786688, metadata !3, metadata !"soma", metadata !4, i32 8, metadata !7, i32 0, i32 0} ; [ DW_TAG_auto_variable ] [soma] [line 8]
!20 = metadata !{i32 8, i32 0, metadata !3, null}
From the bitcode I need to get the following text:
a = 2
b = 5
soma = a + b
My doubt is how to extract the information I need from the metadata (dgb)??
Right now I only have the name of the instructions I-> getName () and the name of the operands with valueOp Value * = I-> getOperand (i); valueOp-> getName (). Str ();
The metadata is very extensive. How do I get this information from the metadata?
Relying on I->getName() for finding the variable name is not a good idea - you have the debug info for that. The proper approach for finding out the names of all the C/C++ local variables is to traverse the IR and look for all calls to #llvm.dbg.declare, then go to their 2nd operand (the debug metadata), and retrieve the variable name from there.
Use the source-level debugging guide to find out how the debug metadata is laid out. In particular, for local variables, the 3rd argument will be a metadata string with the variable name in the C/C++ source.
So the remaining thing is to find out what the variables are initialized to. For that, follow the 1st argument to #llvm.dbg.declare for getting the actual LLVM value used, then locate the 1st store instruction into it, and check what data is used there.
If it's a constant, you now have everything you need to output a = 5-style information. If it's another instruction, you have to follow it yourself and "decode" it - e.g., if it's an "add", then you need to print its two operands with a "+" in-between, etc. And of course the prints have to be recursive... not simple. But it will provide you with the accurate initialization value.
If you're looking for something a lot more coarse and you have access to the original source, you can just get the line number in which the variable is declared (the 5th operand in the debug metadata, assuming the tag (1st operand) is indeed DW_TAG_auto_variable and not DW_TAG_arg_variable, which indicates a parameter). Then print out that line from the original source. But this will not print all the relevant information (if the initialization value is constructed from multiple lines) and can print irrelevant information (if there are multiple statements in that line, for example).
Finally, remember optimization can seriously screw with debug information. If getting those print-outs is important, be careful with your -O option, maybe stick to -O0.