Jan, Am 03.05.2012 um 22:37 schrieb Jan de Kruyf:
> 1. The matter of old Gene feeling ignored: > This is at least in part caused by silly SourceForge that has ideas. I also I'm sure the technicalities of a browser incompatibility can be worked out one way or the other > 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 I never advocated to remove the feature; I find it very useful. I just insist on doing it right - bug against bug compensation isnt. Chris insists in doing it identically for all UI's, and right he is. A development branch should be considered broken at times, and people using it should understand that and be prepared to live with this restriction for extended period of times while a proper solution is thought through and done. Turning around, for developers this means that different rules apply - of course one should get a released version working again soon, or 'more working' under a communicated set of restrictions, rather than ponder on end. But for a development version, it would be good to be relieved from the 'fix asap' requirement, which translates into 'patching around' at times. Taking a step back, to me the whole issue is a problem with management of expectations, in that case 'what does master do for me, and what am I getting into', which refers to your item 6. > 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!) I understand currently to be unsafe *for sure* (NB: not excluding others): - a call to an oword sub executing and that sub has a toolchange, probe or read HAL pin read operation - that call is immediately followed by some other operation > 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. I dont agree with that. If you are daring enough to expose your machine to a development branch and are just dying to have that 'feature' reenabled you could just as well execute 'git revert 81f105' before building. I dont see the point on prodding developers into making master a 'quasi production branch', this defeats its very purpose. Compared to other projects, the incompatibilities in the development branch relative to released versions are harmless at best. Please realize that what currently is going on is VERY incremental progress, which is great for users, but can also be read as: fundamental issues arent touched at all, or at least not in master. This is also an item 6 issue IMO, but opinions vary on that. > 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 I think starting with a spec for the current code *now* is a bit of a lost cause. I'm sure you noticed my tongue-in-cheek on the design document theme. I am convinced it makes a lot of sense for any future design beyond the current development branch, and I plan to be repulsively teutonic about it. - Michael > 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 >> >> >> >> ------------------------------------------------------------------------------ >> 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 >> > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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
