On Feb 4 2013 4:18 AM, Michael Haberler wrote: > Am 04.02.2013 um 11:29 schrieb EBo: > >> On Feb 4 2013 2:58 AM, Michael Haberler wrote: >>> Am 04.02.2013 um 10:25 schrieb EBo: >>> >> Well, I can see this going two ways. EMC works now. > > well, the new RTOS branches do, too - sticking with that for the > moment:
true, but I was not the one complaining that it is difficult to integrate, and thinking that a modular approach would help. >> In the past, and >> I can read it between the lines now, that the invasiveness of the >> modifications will take so much time and effort that lots of other >> things gets pushed back. > > I dont agree on 'invasiveness'. In fact the RTAPI api is used > basically unchanged, barring some new functions for PCI handling; the > codebase is much cleaner and easier to maintain I would think. I am > not aware of any outstanding bugs, in particular not the RTAI RTAPI. ok. How difficult would it be to break all the new stuff out into modules, and build a modular framework for it? > Altogether I think that is a actually an incremental change. I would love to be proven wrong on this one, but I can see modularizing monolithic code causing all sorts of unforeseen consequences. You might be lucky though. > I agree on 'lot of effort' but we're spending a disproportionate > amount of time on kernel packaging, testing, configuration & build; > skunkworks nows;) The RTAPI work has settled for quite a while. Btw > some of that kernel packaging effort is driven by the 'everything on > one CPU' limitation - without that it'd be easier sailing. what else do you see as changing if you break the 'everything on > one CPU' limitation? >> I guess my 2C would be that it would make more >> sense to incorporate these level of changes into v3 and back port >> once >> it is working and time allows. > > I dont think that will happen because I dont see anybody to do it, > and I dont quite see the point either - I've on purpose left the > option open to merge the new RT OS work into either master or > v2.5_branch. That option is still open and undecided. So my question to you is how long do you keep the 2.5 branch if/when a 3.0 branch becomes stable and fully functional? It should not be 0, but it also should not be forever. > I dont care one way or the other, but one should be aware of the fact > that merging this into master will accelerate deprecation of the > v2.5_branch as few will see benefit in backpatching things into older > branches, including me. Putting it further off will widen the gap > even > further. absolutely. But where do you dry the line between changes that are big enough that they deserve to be slated for 2.6, 2.7, or 3.0? Working incrementally is all find and good, and if we really refactor various pieces of the code to make them more modular or update HAL so we can drop NML, Each of these changes are serious enough to be designated a revision to version bump. >> The problem becomes you are spending a >> LOT more time trying to shoehorn stuff into a structure that it does >> not >> well fit. Starting from a cleaner abstraction and moving forward in >> a >> methodological fashion will end up getting this done a lot faster >> than >> fighting the shoehorning. Also, if people have not done it already, >> I >> *strongly* recommend setting up a fully automated unit and >> regression >> test suite. I prefer the eXtreme Programming (XP) methodology >> myself, >> but any modern software engineering approach will benefit the >> project. > > switching theme to other structural work, for instance removing the > 'everything on one CPU' limitation: > > I dont quite believe in the big-bang architectural changes in the > linuxcnc context. There are way too many moving parts affected in > parallel, and that isnt doable by a single person either - and that > is > the modus operandi by and large of this project, give and take some > exceptions. Barring a significant sudden cultural change, it is hard > to see the team to do that. So I think de-facto forking the codebase > is unrealistic. But there appear to be issues that are deeply ingrained enough that you will likely never address them until someone either forks EMC or at least makes a branch and changes things whole cloth. > I would rather see it in a parallel evolution of replacement parts. > For instance, the duplicate middleware (NML+HAL, both not quite > fitting the bill) is a pressing structural problem. The way I would > see forward is to make HAL messaging capable such that it can take > over the - fairly minimal - messaging aspects of NML, and then start > migrating components piecemeal. That would be a limited-impact > approach as it can be done and verified in isolated contexts, and it > would take the IMO most pressing issue off the list. Agreed. I would also advocate using that upgrade to implement/test full regression/unit testing. > there are some issues which cannot be resolved by any amount of > redesign, because they require a community decision or manpower. For > instance, decide to deprecate Tcl use and eventually remove using > code; or alternatively find a person which carries that effort > forward > onto a new base; I dont see either one. That is an issue, but how much code is effected with removing tcl? IIRC, Ray's interface uses tcl, but is there more? > The big issue keeping *me* back here is actually relicensing. It is > completely unrealistic IMO to address the above problem within the > current GPL2only restriction. Is there a list of effected code that cannot be made (L)GPL2+? > re motion: I think piecemeal is entirely possible here too - branch > off a second component, build in parallel, modularize, and leave it > as > an option. When it becomes clear it's beneficial, folks will switch; > if not, then not - no damage done except some lines of halcmd. true, but I think it will take a lot more time when you consider the whole collection of work -- and I would love to be proven wrong. > I think that doing such structural changes without rocking the boat > too much is one of the large - and I find very interesting - > challenges, a bit like nailing a pudding onto the wall ;) When you can do that, but I do not think that it is entirely possible. I gave up nailing pudding to the wall when I successfully nailed a floppy disk to the wall, then later pulled it off the wall and read the data off of it (true story). EBo -- ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
