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 the syntax for transform parameters[0].
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. 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. - 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. - 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. - 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. 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. 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
