Hi Sean, thanks for your report. 2012/6/28 Sean Bartell <wingedtachik...@gmail.com>: > Hello, everyone, > > I've finished implementing the first iteration of the Bithenge script > language. You can give the program a script file and a data source and > it will print the decoded result. If you compile my HelenOS branch you > can run "bithenge /src/bithenge/trip.bh /src/bithenge/trip.dat" for an > example. Try it! The language is currently very limited and can only be > used for the simplest of structures. I decided to test it with something more realistic - see the attachments, please.
My example is parsing of USB descriptors. I do not know how much you know USB internals, but briefly USB descriptors describe type and capabilities of the USB device and they form a tree. Current version of Bithenge is not able to parse "any" descriptor, but for a fixed configuration, it works well. The attached example usbkbd.dat is a configuration (including endpoints) descriptor of USB keyboard in QEMU and usbcfgdesc.bh contains the description. The descriptors use mostly uint8 and uint16, so I added other built-in transformations. It was pretty easy (copy-paste mostly) - feel free to use them. After that, it worked and it displayed parsed USB descriptor correctly :-). > I added support for Linux so I can run Bithenge more quickly and use > Valgrind. > > Now that the basics of Bithenge are in place, there are several things I > could start working on. I'm inclined to keep working on the language, > specifically by adding support for parameters and expressions, because Can you, please, elaborate more what you mean by parameters? As a matter of fact, there are some features described on the wiki (Future features section) that I am not sure I understand correctly. Would you, please, describe them in more detail? Or, please, give examples of file-formats/file-systems/whatever where this functionality would be useful. > other aspects of Bithenge won't be very useful until the language is > more powerful. Does this seem like a good idea? >From my point of view, following features shall be on top of your list. Repetition with some kind of "stop condition" (something like "until this field is zero" would be probably enough). Use case is iterating through program stack. Repetition of fixed length, where the length would be determined by some previously known "field". Example could be reports in USB HID descriptor or color palette in GIF. Switch based on some magic value. For example, USB descriptor type is determined from the second byte. Or GIF extension blocks. Skip some data. Either of fixed length (e.g. to skip unknown USB descriptors) or until some pattern is found (e.g. parts of GIF header). Bitmap parsing. Accessing the parsed data at run-time. Currently, you are able to print the data but I found no way to actually work with them. For example, how would I read the latitude from your example once the structure is parsed? This is a very important feature if we want to use Bithenge as a basis for other tools, such as debugger. Optimal solution would be to parse the data into a native C struct. Question is how to populate it. Generate a setter of some kind from the grammar, use some weird macros, ... > I will be on vacation from July 1st through July 14th with limited time > to spend on my project. I'll have intermittent Internet access during > that time, so it would be best to discuss the midterm evaluations before > I leave. Is there anything you want to comment on? One thing I've > noticed is that there hasn't been much response to my past few > updates--not that I asked many questions, but it would have been nice to > get some feedback. Sorry about that. I was following your progress and because it looked okay (code style, direction, etc.), I didn't generate any feedback at all. It was a mistake. Sorry. I have a few questions/notes that came up after going through your last commits. What is the "Try to read 5 bytes and fail if the blob is too long." comment? Could that happen if the length is explicitly given by the other function? I see that you wrote the parser & lexer all by yourself. Was there any specific reason for not using Flex/bison/whatever? Currently, the language is pretty simple but this burden may strike back later... I appreciate that you comment all your public functions. Keep it that way :-). It would be nice to have more example. Preferably of some real structures. But I have no doubt that they will arrive soon. Do not forget that result shall be a library. Currently, everything resides in app/. I had problems orienting myself in the dump, so I added a very primitive indenting - it is attached for inspiration how the output could look like. The implementation is a 2-minute hack that shall never be committed ;-). What are the plans for "write" support? And that's all from me. I hope it makes some sense. Otherwise, feel free to ask. Your progress looks okay to me, but do not forget that you are already in the middle of GSOC (assuming you won't work during your vacation). If you think that you will not be able to implement everything, it is time to discuss what features could be dropped. Otherwise, good job! Bye - Vojta > > Thanks, > Sean Bartell > > _______________________________________________ > HelenOS-devel mailing list > HelenOS-devel@lists.modry.cz > http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
bithenge_indent_hack.patch
Description: Binary data
bithenge_uint16_uint8.patch
Description: Binary data
usbcfgdesc.bh
Description: Binary data
usbkbd.dat
Description: Binary data
_______________________________________________ HelenOS-devel mailing list HelenOS-devel@lists.modry.cz http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
