I'd like to do a few things, but I rather hear opinions beforehand. minor stuff:
logging: The LogDebug stuff in interp_o_words.cc and the related logfile are only mildly useful - too verbose, and not correlated to the rcs_* log. I'd like to move that to the logging the way it's done in task (with rcs_*), and appropriate stubs in gcodemodule for UI execution. regression testing: I'd like to make rs274 infile-aware so inifile-dependent features can be tested. Any suggestions/warnings? cleanups: - add flags to EMC/DEBUG for: execution logging of oword subs, remapped O-word code operations, and remapped O-word python subroutines (yes! see below) - dynamic memory allocation (strdup/free in interp_o_words.cc etc): I'd like to to replace that with a hash-based string store which is not susceptible to leaks - strings wouldnt be freed but allocated without duplicates and storage would have an upper bound given by number of symbols in the program. I'll probably use an STL hash_map, or some other string store - I'm open to suggestions. - reformatting. I know this is a nono, but occasionally source files are very hard to read and edit due to formatting and indentation, and the temptation is high to do that. Beyond the occasional source file: Can we discuss a 'whitespace reformat day'? major stuff: tooltable replacement: tooltablev2 will get a decent abstract data type, implemented with an sqlite3 database, and move from iocontrol to task and interp, handled through Python callouts. Actual logic will move to Python and sqlite3 procedures. This is disjoint from remapping G/Mcodes since the tool-related change primitives are needed anyway - just potentially a lot more powerful. new software components: - for tooltablev2 I'd want to use sqlite3 (my suspicion is if its good enough for A350 flight management software, it should be ok for EMC ;-) - for Python/C interfacing: any opposition to using boost.python? It is way easier to interface C++ through boost.python than through the Python/C API, and seems to be the-defacto standard of doing this. See for instance the opencamlib bindings by Anders - the .cpp files here: http://code.google.com/p/opencamlib/source/browse/#svn%2Ftrunk%2Fsrc Both sqlite3 and boost.python are available in 8.04, too. Python-dev would be needed, too. I know this sounds quite ambitious and two extra packages come in, but I think the time has come to cut loose from some past decisions. I'm ready to take slappings now ;-) Michael --- status notes: Remapping: I now have a execution model which allows selective remapping; not only of Tx/M6/M61 but also of G- and M-codes, including control for properly sequenced operation. This remapping even works recursively - so a O-word subroutine handling, say, M6, may call other remapped codes. Python subroutines: A trivial fallout of work with owords were Python subroutines - if, say 'o<foo> call' is executed and 'foo' happens to be a Python callable in a module imported through ini, it is executed instead of searching for a Oword procedure. While the execution environment for such functions doing work for remapped codes is fairly limited it is much cleaner in terms of side effects than executing O-word subroutines, and I think it might be the better model long run. it also strikes me as the logical way of doing - at least part of - the tool change operations when moved to Interp and task from iocontrol. It probably means that task might do part of its work through Python as well. ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
