Hopefully this will get sent to the right place... I have been poking around the Perl script that creates the Refcard and managed to get it to spit out a new (well, not quite but...) refcard.rst which can then be build into the webpage when using make to create the htdocs. It works if I change the asm source directory to the avr8 one but not with the common/words. The problem is that the Perl regexes are so tightly bound with the file having 4 line in exactly the right place. It looks for the "VE_" + name + ":" line then uses the three prior lines to fill the name, stack effect and description. The files in the common/words don't have the same layout since they contain the ".if cpu_" etc lines to handle the msp430 and avr8 flavors.
Now for the good news. It seems that every file in the common/words has a variant for both the msp430 and avr8. Any of those could just be tagged with a new hash called %TYPEOF or something to that effect. Then the avr8/words could be parsed since they have the same top 3 lines and be tagged for the avr8. As I mentioned, those already work just fine. I've created a new refcard.html for those. Now, the msp430 is a whole other bag of worms. The information that is being parsed is all mashed up in the first line and doesn't contain a section name. So, to start out with. The msp430 asm files could be fixed by hand to have the proper information in the top 3 lines, but only if they are not generated somehow that will undo the work. Perhaps whatever spits out those asm files could be convinced to put that info there? I have no idea. I know that with g4 I could easily convince it to place those 3 lines as needed just by putting them as comments in the file. It works quite nicely. So, since I don't know anything about the 430 stuff I'll leave that for now. The bigger issue is the way the asm files are searched to create the refcard. That could be fixed without too much of a problem I think. Well, apart from having to figure out the right place to add in for the new type thing. Perl is Perl. I didn't have any idea about how to read it before this and at least can now follow the internal logic. It reminds me of a project to find solutions from every permutation of some packing puzzles I made. I wrote one bash script that fed off another and another etc. It works, but I don't hardly dare breathe too hard on it. ;) This has the same feel. It works but only because it works. I can keep playing with it this week and try to make some progress on it. Perl is easy enough to pick up enough. However, if I spoke Python I'd probably just rewrite the whole mess and fix the comments in the common/words to conform with the rest of them. Most of it is just scut work with the addition of tagging the crossover words with their proper flavor. So, if anyone is still this far along. I can use the scripts to create the stuff to make the htdocs for the site and the epub file. I tried to do the pdf but after adding package after package after package of the texlive stuff I gave up and just wrote a new rule to create the epub but not the pdf. It shouldn't matter except I can't test the pdf output. I will gladly continue to pursue this as I do find Perl interesting enough to muck with. It's pretty amazing apart from the fact that it is like reading a book that is printed entirely in stereogram. That's that for now. It seems that AmForth Weekend 1 is still bearing fruit (such as it is). Mark _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
