I will refrain from weighing in on this debate, but I thought I would share a quotable quote -- when I was helping a postdoc understand some code I found a bug, and fixed it on the fly. His response was "Do not fix it so that it is self consistently WRONG."
EBo On Thu, 3 May 2012 22:37:38 +0200, Jan de Kruyf wrote: > Michael, > dont get too excited, we do understand you are busy, and this can of > worms > causes issues, now that you have taken off the lid. > As it should, because any oldish project has issues like this. And > they do > need to get resolved!! there is no doubt about that. > > At the same time I personally *highly value* your time and > contibution that > you freely give to the project. > > So that out of the way: This is my considered input to the issues I > have > seen coming past my eye. (And I probably missed some, but never mind) > > 1. The matter of old Gene feeling ignored: > This is at least in part caused by silly SourceForge that has ideas. > I also > failed to log a bug report when I tried just now > Partly my set up, partly Source Forge, partly wrong info on the wiki > page. > (*Please drop me a note whoever is maintaining this part of the > business*) > If I myself were pushed in a corner like he is at the moment, I would > probably have exploded a bit louder, with your permission. > > 2. The program vs MDI issue: > operators love to quickly do something and not write a big program, > so that > is why there is MDI. It is a human interface concept, nothing more. > But a > very important one. In general it is used slowly and not concurrent > with a > program, except by code-breaking specialists like me and you. But > then > again we dont stand behind a real machine all that often. >>From architectural point of view it is just another file that needs > executing, you are right about that. > > 3. I understand that the present situation is not at all SAFE from a > conceptual point of view. But in practice people have not noticed it. > It is not worse than taking all safety switches off a machine, as is > often > done when they get in the way of expediency. > (Yes I know that is shocking!) > > 4. So I would vote to revert to a release before you disabled the > faulty > code, and publish a formal warning from the directors of the project > on the > users list. > > 5. At the same time someone(two, three) might volunteer to be the > active > maintainer(s) of the specs of the project, and also be the safety > officer(s), since we deal with real, powerful and dangerous machines > here. > If you have ever seen pieces of casting fly though the workshop > because of > a faulty control you will know what I mean!. And safety laws are > definitely > not getting any easier. > > 6. MOST IMPORTANT. > Would the board please pay attention to the state of the project. You > people did a wonderful job getting all this started and bringing it > where > it is today, but at the same time life went by, smoothly and without > a > ripple; we all lived off the glorious past. But now that there is > some real > and very needed development going on, to get LCNC up to todays > standards, > the stress cracks start to show. > > So lets get focussed and not into each others hair! > > Regards, > > Jan de Kruyf. > > > > > > > On Thu, May 3, 2012 at 9:14 PM, Michael Haberler <[email protected]> > wrote: > >> >> Am 03.05.2012 um 17:35 schrieb Chris Radek: >> >> > On Thu, May 03, 2012 at 01:35:13PM +0200, Michael Haberler wrote: >> >> >> >> note I proposed handling proper queuing of MDI commands by >> modifying >> >> Axis to have a queue of MDI commands, and feed them to task one >> by one >> >> within the interpreter state constraints. >> > >> > I have said this before but maybe not plainly enough - >> >> No I havent heard it, and I didnt find it in the linuxcnc >> requirements/API >> spec document either. Where is google search with useful results >> when we >> need it >> >> > I think this >> > isn't something to fix in AXIS because if we want MDI queueing to >> work >> > (and I hope we do, somehow) it should work for all UIs. >> >> Considering that this may be a valid argument, under which light it >> behooves to specify: >> >> - the interpreter input handling needs a queue, which will reside in >> task >> for now and have some configurable maximum size >> - that queue shall be flushed on any interpreter abort >> - task needs a way to report queue state, (size, and full condition) >> - emcmodule needs to enabled to report said state to a caller >> - task will drive dequeuing and feeding of interp commands from that >> list >> - the UI's shall observe the 'input queue full' status to disable >> any >> input facility >> >> The above shall be added to the core linuxcnc requirements/API spec, >> in >> other words: fed into the #linuxcnc-dev IRC channel. >> >> While mhaberler is away, said IRC channel is tasked to deliberate >> and >> decide the following question: >> >> - does it make any sense to differentiate input handling mechanisms >> wrt >> 'auto mode' and 'MDI mode' AT ALL, OR is it ok to have the interp >> input >> queue carry any command of the types 'open ngc file', 'execute ngc >> file' >> and 'execute a string (aka MDI mode)'? >> >> mhaberler can think of no valid reason for two interfaces right now, >> as he >> has never understood the conceptual difference between auto mode and >> MDI >> mode in the first place except for 'string' versus 'file', which >> obviously >> at some distant past was meant to mean 'single block' versus >> 'several >> blocks in a file' >> >> - Michael >> >> style reference: http://static.mah.priv.at/public/dambeaver.txt and >> assorted EU directives ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
