Hello, Sean. 2012/8/15 Sean Bartell <[email protected]>: > mainline r1598 seems to have broken libblock (try "blkdump bd/initrd" or > "bithenge fat.bh block:bd/initrd"). Shall be fixed by now.
> Although the FAT script is much more concise than, say, a C version > would be, it has revealed some areas where the Bithenge syntax could > still be improved. There is always space for improvement but in general the syntax is pretty clean and allows to describe even complex formats. > Yet again, my plan was too optimistic: after thinking about C generation > I realized it would require some sort of type inference, and the most > flexible design might even require a virtual machine. I focused on the You are overcomplicating things. This was supposed to be implemented only for the simplest transforms that just map sequence of simple types (e.g. a GIF color table but not the whole image). > FAT script instead. This is not for the first time you deviate from your original plans and you significantly reduce the difficulty of the task. I expect that the FAT script would be in top-notch condition to balance other simplifications and cut-downs. > This week, up until the 20th, is devoted to finishing what already > exists rather than adding new functionality. I plan to: > > - Move the library parts of Bithenge from /uspace/app/ to /uspace/lib/. > Where should test code go? Usually, simple tests are in the tester application. However, it really depends on what you want to test. For unit testing, I would recommend creating new application (bithengetest) modelled after tester that could test individual functions. For testing actual transformations, I think that you should create files with expected output to the src/bithenge directory and then compare these to the actual output. In Linux, that ought to be easy with a simple shell script, for HelenOS you may consider creating simple cmp(1) by your own (and run all tests with batch command). > - Fill out the wiki documentation. I will create a number of pages under > Bithenge/ with an overview and detailed information about syntax, the > API, internals, design decisions and limitations, and future ideas. > > - Write a small test suite. I find SQLite's testing[1] inspiring; I > can't reach anywhere near that level, but I would at least like to use > Valgrind automatically. I will fix bugs I find while testing. > > - Double check the Doxygen comments for all public functions and types. > I will run Doxygen to make sure I haven't added errors accidentally. Okay. Sounds reasonable. Thanks. - Vojta > > Thanks, > Sean Bartell > > [0] > https://bazaar.launchpad.net/~wtachi/helenos/bithenge/view/head:/uspace/dist/src/bithenge/fat.bh > [1] https://www.sqlite.org/testing.html > > _______________________________________________ > 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
