Hi Lee, please read my last two emails again, you might have missed my point.
----->> The existing mechanism, with existing tool table, will be retained, as a module, as default. <<------- As I said clearly, the use of a module with, say, sqlite will be *optional*, which is why nobody will be forced to use it and switch. This is about creation of a plugin mechanism and an API, and it gives you the freedom to use XML or otherwise as you see fit. -Michael Am 04.05.2011 um 19:43 schrieb Lee Studley: > Hi Michael, > > Not to start a war: > > I personally cannot stand SQL and would prefer a hand editable form. > SQL is a weak attempt at an organized language and much more hassle to use > and learn than needed. > I've used Cassandra, XML, and other forms that make life much easier. > > Please use some other editable form. XML, .... > -Lee Studley > > > On 5/3/2011 12:28 AM, Michael Haberler wrote: >> 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 >> > ------------------------------------------------------------------------------ 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
