Hello Sean. 2012/7/22 Sean Bartell <[email protected]>: > Hello, everyone, > > I returned from vacation this week, but I started working slowly due to > illness. I was too busy to work much during my vacation, but I designed I hope you are okay by now.
> the syntax for transform parameters[0]. The syntax looks nice and clean. > I've also worked on planning the rest of the summer. My original plan > was to finish the language by the start of my vacation. Unfortunately, I > only completed the basic parts of the language. My suggested new plan is > to continue developing the language as follows: > > Jul 21-22: implement some minor improvements such as indentation > support. > > Jul 22-27: implement transform parameters and some transforms that use > them. > > Jul 28-29: implement conditions (if and switch) and possibly comparison > operators. > > Jul 30-Aug 1: implement basic repetition. There will be three types: > - apply a transform repeatedly until the end of the data. > - apply a transform a known number of times. > - apply a transform until some condition is true, if the last element is > specially marked somehow. > > Aug 2-4: implement bitfields. It should be possible to specify that some > sequence of bytes should be treated as a sequence of bits, and to read > arbitrary-length bitfields like with structs. > > Aug 4-6: allow scripts to get arbitrary subblobs. This is necessary when > the data has pointers to other offsets in the data, rather than all > being stored sequentially. Thanks for the schedule. I hope you would be able to follow it and deliver all the promised features. As it looks there would be new features every few days, you can make (and I would recommend it) your status reports more often. No need to wait till the end of the week. I am looking forward to try them. > This schedule leaves 6 more days until the suggested end of coding, and > there are 7 days after that until the deadline. There are several things > I could work on during that time: > > - An interactive browser for the decoding result. Instead of just > dumping the result as JSON or a Python literal, you could start the > browser and use familiar commands like ls, cat, and find to explore > the decoded tree. This would only take a few days. Although I originally wanted the browser, now I would rather vote for other things. We can always scroll through the dump in the editor. Or finally implement the pipe FS and a proper pager ;-). > - A program to generate C code from Bithenge scripts. Given a Bithenge > script describing a structure, you could automatically generate a > standalone C header and code to read that structure and do the > endianness conversion, offset calculation, and so on. The output could > be used in HelenOS instead of writing the code manually. I estimate I > could make this in a few days for basic structures, with more time > needed for repetition support. > > - Trivial editing support. It would be possible to change the values of > data fields as long as you didn't change their lengths. This would > probably take 2-4 days. Figuring out how to do more complex editing is > an open-ended task that could take weeks. I would like to have an API to change (simple) fields. More complex editing is probably out of question. I also think that it is not necessary to add write support for all backends. > - DWARF support. Bithenge could read the DWARF debugging information > from an ELF executable and convert it into a Bithenge script, which > could then be applied to a core dump or running task memory to view > the task's data structures. The DWARF specification is fairly complex, > and I don't know how much of it is necessary for a basic > implementation, so I think this could take anywhere from 1-4 weeks. Given the fact that you cannot predict how long it would take, it would definitely take longer and we probably need to drop this part. Though I am not very happy about it. > - A complete FAT script. Although the language improvements above should > be enough for useful FAT decoding, there will be more potential > language improvements. For instance, with some advanced language > features Bithenge could automatically decode long file name entries > and associate them with the correct file. This idea involves extending > Bithenge to implement some chosen format, like FAT, as well as > possible, and I could spend an arbitrary amount of time on it. Having Bithenge script of a complex data structure (such as FAT) is a must-have part of your GSoC project. > I'm interested in working on all of these at some point, but I'd like > your opinions on what I should do during GSoC. The FAT script (or something similarly complex) must be delivered during GSoC. Next I would like to see the code generator and trivial editing support. Also do not forget about the documentation. I appreciate that you document all public functions, but there ought to be some kind of higher-level documentation as well. For example in the form of short tutorials such as: "if you want to introduce your own dump format do this", "if you need to traverse the tree in some way, do this" or "if you want to add your own backend, define function x and y" etc. I expect that others would offer their opinions as well. There is still some time to discuss which of the topics are the most interesting. - Vojta > > Thanks, > Sean Bartell > > [0] http://trac.helenos.org/wiki/StructuredBinaryData#Transformparameters > > _______________________________________________ > 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
