With a diff program or better a merge program like meld one can easily see the white space changes that are extra to the real code changes and can confuse or waste time of a reviewer. Whitespace changes are often made by badly set editorr or a feeling that formatting may not be as you wish.
I downloaded streamer.c from git and the new version and created two files from them first I used meld to fix whitespace differences this created http://www.collection.archivist.info/archive/mirror/linuxcnc/streamer.c.slv.djc I exported a diff patch http://www.collection.archivist.info/archive/mirror/linuxcnc/streamer.dif Dave Caroline all in http://www.collection.archivist.info/archive/mirror/linuxcnc/ I happened to save the dif before the fixed streamer.c so timestamps are not as one could expect On 08/03/2015, Slavko Kocjancic <esla...@gmail.com> wrote: > On 08. 03. 2015 04:38, EBo wrote: >> On Mar 7 2015 8:47 AM, Sebastian Kuzminsky wrote: >>> On 03/06/2015 11:28 PM, Slavko Kocjancic wrote: >>>> ... >>>> >>>> I just throw my eyes to that. And find what? >>>> One of thing is "Add flow control to halstreamer". I already do that >>>> and >>>> even post the change but nobody care about that. I post changes on >>>> this >>>> list and forum but didn't push to trunk as I don't have permission >>>> to do >>>> that. >>> >>> That's not true. I reviewed your patch and gave you feedback on what >>> you would need to fix for it to be mergable. You never finished it. >>> >>> https://sourceforge.net/p/emc/feature-requests/125/ >> >> Sounds like we need a couple of FAQ items to communicate what is >> expected for patches. I will say that reading the feature request log >> that both parties were clear: >> >> 1) it needs a little cleaning up and documenting in order to merge into >> the source. >> >> 2) the poster is not familiar with what is meant by the terms "white >> space", and was unsure about how to edit the documentation. >> >> In all of this there are two assumptions that should be clearly >> expressed. 1) most of the developer/maintainers either do not have the >> time or choose not to spend time to clean up code formatting and style >> issues. It might seem trivial for one or two additions, but could >> easily turn into a full time job, and we really need people to make >> their new code look as close to code around it. This will help its long >> term maintainability, and we have to rely on the posting fixes/additions >> to sort as much of this out as possible. 2) The original poster figured >> that he got it close enough and wanted us to jump in and polish it up. >> What he should have done at that point is either get on IRC or email the >> list and ask for help instead of assuming that someone would read the >> feature request and jump in. So, you basically need to find either a >> champion or a fellow compatriot to help do the finish polish. It might >> take awhile to find someone to help -- as most of us are insanely busy, >> and unless this is something that we *NEED*, we end up working on our >> own projects. >> >> There are probably a couple of dozen little features which are in the >> same state. I know that I submitted a *huge* patch to fix a 32/64-bit >> issue awhile back, and I doubt that it ever got pulled in as there was >> something that needed changing and I had a huge job at work come up, and >> only the gods know whatever happened with it... >> >> Now that these things are being tracked better, it is less likely to be >> dropped and forgotten. That said, I think giving a couple of these hung >> patches to a GSoC intern would be a great help. >> >> Well, that's my 2c >> >> EBo -- >> >> > > EBo I think You catch the trouble. > From my point of view you hit all the troubles. > -it needs little cleaning (I don't know what's wrong at all) > -I really don't know how to edit documentation. > > And I realy just put my code in web and let to someone find it and > update the code, instead to find person who are capable to do that and > ask it to do that for me. > > Slavko. > > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, > sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for > all > things parallel software development, from weekly thought leadership blogs > to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
