On Thu, Dec 26, 2013 at 11:54:34AM -0500, Robert Ellenberg wrote: > I like this idea, as it would make it much easier to make changes without > messing up other people's work. It would take a bit of reorganization, > since the motion module code is spread out over a few folders. I'm thinking > it would help to rearrange these files into "motion_common", > "trajectory_planners", "kinematics", and then "motion" and > "motion2_experimental" for module-specific code. Otherwise, we'll have a > ton of code duplication.
While the trajectory planner does not have as clean or simple an API as kinematics, I don't see why it can't be loadable in exactly the same way kinematics are. But I do not understand why you are saying that what directory files are in would increase or decrease code duplication. I think making the TP loadable would not require any code duplication at all. > Another issue I can see is that whitespace is a crapshoot in most of the > motion files. I'd really like to reindent all of them with spaces and > 4-column indents, but this should probably be done across all of the major > branches at once to prevent merge headaches. Unless the files are totally incomprehensible or are overtly broken (like with dos line endings) the reindenting cure is always worse than the disease. It can make it harder to maintain/merge/work with different branches as you identified, but also is hostile to everyone else who has a clone with work they're maintaining separately (like you...). With centralized VCS you could at least cap the damage, but with git and distributed development, it's very damaging and is totally not worth it for simple aesthetic reasons. > An alternative idea in a similar vein: would it be possible to specify a > trajectory planner module in HAL, separate from the motion module? We'd > have to agree on an API, but I can see that being less duplication and > reorganization than two entirely separate motion modules. Now I see we're thinking along the same lines. Making kins loadable looks like it was utterly simple (in retrospect of course, ha) - see rev dad30801b53 Looks like emcmotStatus and emcmotDebug pointers will have to be passed in through the tpCreate() call but I don't see any other stumbling blocks. If someone else doesn't attack it before I can get to it, I'll try. Chris ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
