On Tue, May 03, 2011 at 09:28:43AM +0200, Michael Haberler wrote: [I have trimmed the parts where I have no opinion or feel unqualified to comment]
> - 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'? I am entirely against this. It makes version control work badly across the change, both for human consumption (viewing patches) and merges. I believe that in no way does the incremental ease of reading uniformly-formatted code make up for these problems. Also I believe that in order to do this we'd need to agree on the "one true style" of code, and all such discussions about style and whitespace are 100% a waste of time. > 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. I do understand some of the reasons you want to move tool table handling out of iotask (and possibly eliminate iotask altogether) but I do not see why it should be a database. Can you expand on why you think this is the thing to do? > 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. I am really excited about mapping T and M6 calls to O subs to make things like rack toolchangers not only possible, but relatively easy for someone to set up. I understand entirely why you are working on this. I have an open mind about mapping arbitrary G/M codes to O subs and/or python subroutines, but I cannot think of a reason to do this on any of the kinds of machines I run. Before we talk about the technical details of how to do it, shall we talk about why and whether? My feeling is that configurability for the sake of configurability, especially when it adds dependencies and extra layers of code that will be unused by most users but still require ongoing consideration and maintenance, may not be wise. I'd like to hear what problems (I've heard these called "user stories") we are trying to solve by doing this, and some arguments for why this is the best way to solve them. Chris [p.s. Could you please wrap your text at 72 columns? It is very hard to reply inline otherwise.] ------------------------------------------------------------------------------ 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
