On 7/2/07, Red Daly <reddaly@gmail.com> wrote:
There are, however, still many tests that fail. The bulk of these failures are because of semantically meaningless differences in parenscript-compiled javascript and the expected javascript. for example:
It is worth considering using a Javascript parser compare expected vs. compiled Javascript instead of using the slight hack in the current testing code.
Anyhow, now that 5am is compiling we might want to get tests working again. Great work! And yes. And also clean up the documentation. I don't have
I would say it is unnecessary and too complex. If the hack is updated to remove all whitespace (include linebreaks) before comparing generated and expected code, I think that will be good enough to detect 99.9% of all cases were the generated code does not comply with the documentation. I think find undocumented newly added features and tweaks, and documenting them with expected output is a higher priority. Otherwise it is a big chance they will be forgotten when parenscript is refactored. If there is no test for a feature, it will not be seen. the time right now, but can help later if there is anything left to do in some weeks. /Henrik