Hi Sean. 2012/7/21 Sean Bartell <[email protected]>: > On Fri, Jul 20, 2012 at 02:48:30PM +0200, Vojtech Horky wrote: >> 2012/7/20 Sean Bartell <[email protected]>: >> transform point = struct { >> .x <- uint32le; >> .y <- uint32le; >> }; >> Generated C code (just to get the feel): >> struct point { >> int x; >> int y; >> } >> void read_point(void *buffer, struct point *out_point) >> { >> /* Either parse the script from some string or >> build the bithenge_transform_t in the code. */ >> ... >> /* Not sure if the API can be used like this directly, >> but that is not the point now. */ >> out_point->x = bithenge_integer_node_value(node[0]); >> out_point->y = bithenge_integer_node_value(node[1]); >> } >> > Ah, now I understand you. This does seem quite useful. I would skip the > stage where the Bithenge API is required, as it doesn't seem like it > would save much work. Okay.
>> > I was only thinking of implementing basic browsing, and in fact I think >> > it should take less than 7 days. >> Can you, please, explain what you exactly mean by basic browsing? > > It could be either a command-line interface, where you can use commands > like ls, cd, and find to explore the Bithenge tree, or a text user > interface like top where you can move around in the tree with the arrow > keys. It would only allow you to explore different parts of the tree and > search for values. Sounds reasonable. I think that you should give priority to the CLI and implement TUI only if there is enough time. >> >> For the editing support, I would say that having C API is a minimum. >> >> It should allow following actions: >> >> * edit primitive values >> >> * add/delete from repetitions >> >> * add/delete optional structs (aka conditional transforms) >> >> Obviously, it must be possible to write the changes back and the >> >> changes must be checked to be valid according to the grammar. If you >> >> would built some command-line editor above this it would be nice. >> > >> > Editing primitive values is fine, but the other two are more difficult. >> > If Bithenge knows the length of a repetition based on a parameter >> > originating from a length field, how does it know to change the length >> > field? If there are pointers in the file, how does Bithenge know to >> I agree. But this functionality would be extremely useful and shall be >> reflected somehow in the overall design of the library. It shall be >> documented how to do it, at least on some abstract/high level. >> >> > change them? Nontrivial editing seems so open-ended that I think it >> > should be left until after GSoC. >> I agree. It would be great if the tool would be developed even after >> GSoC. But still, it ought to be documented somehow... > > Does this mean you want me to think about the way editing support would > be designed, even if I don't actually write code for it? The more I think about it, the more I see that to design a generic editing support is a complicated task. But how about a demo only? For example, code for editing zero-terminated strings. Do you think that writing such example would make sense and is feasible? >> >> Regarding the DWARF support - I do not know the format well and I do >> >> not know whether it is possible to implement core functionality only >> >> first and extend later. What I would like to see in the end is a >> > >> > You can take a look at the DWARF info in a file with readelf -w >> > <filename>. I think DWARF support is possible, but it might take >> > 2+ weeks to reach a usable state. >> You think it would be that demanding to rewrite the specification into >> a Bithenge script or you have also something else in mind? > > I'm thinking of a program that reads DWARF information from an ELF file > and converts it into a Bithenge script. You could then apply the script > to a crash dump or to the task's memory. My concern is that I'm not > familiar with DWARF and it looks complicated, so I can't predict how > long it would take to make something useful. That is an ambitious task. And predicting its time demands is almost impossible if you know very little about DWARF. So, we shall create some subset of this task. IIRC it was Jiri Svoboda who came up originally with the idea of using such library for a (to be created) debugger. Maybe he can give some guidance on the scope of this task. Bye - Vojta > > _______________________________________________ > HelenOS-devel mailing list > [email protected] > http://lists.modry.cz/cgi-bin/listinfo/helenos-devel _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
