Re: [fltk.general] [FLTK 1.3] Filesystem list inFl_File_Browser(STR#2935)
On 16.04.2013 11:01, MacArthur, Ian (Selex ES, UK) wrote: Michael Baeuerle wrote: I will add the test information to the STR and update the patch. Done. All - I'm looking at this patch #2935 and it looks OK, and Michael reports that it works well on the problem targets. I find it does not break my linux builds. I propose to apply this patch sometime soon'ish - hope to get to it during the course of today. Anyone have any objections? Not from me, please go ahead. Thanks. Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] [FLTK 1.3] Filesystem list inFl_File_Browser(STR#2935)
Michael Baeuerle wrote: I will add the test information to the STR and update the patch. Done. All - I'm looking at this patch #2935 and it looks OK, and Michael reports that it works well on the problem targets. I find it does not break my linux builds. I propose to apply this patch sometime soon'ish - hope to get to it during the course of today. Anyone have any objections? Not from me, please go ahead. Thanks. OK - pushed at #9884 Selex ES Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] [FLTK 1.3] Filesystem list inFl_File_Browser(STR #2935)
To make it look consistent, should I repair this in the rest of the file too? I don't really know, but my feeling is that we should make the minimal change, so that people can more easily see what has *actually* changed. So... in that case I'd propose that you leave the existing code, even where it is wrong, but just try and make the new stuff be right. Does that sound sensible? What do others think? I've worked on projects which have had a mass reformatting to fit with some code standard, or new layout tool, and it's a nightmare. Trying to diff against the versions before the big change becomes useless, so trying to find code regressions becomes impossible. Since then I try to keep the same formatting style as the old code. If you must, reformat the new/changed code only, but leave the old. D. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] [FLTK 1.3] Filesystem list inFl_File_Browser(STR #2935)
I don't really know, but my feeling is that we should make the minimal change, so that people can more easily see what has *actually* changed. So... in that case I'd propose that you leave the existing code, even where it is wrong, but just try and make the new stuff be right. Does that sound sensible? What do others think? I've worked on projects which have had a mass reformatting to fit with some code standard, or new layout tool, and it's a nightmare. Trying to diff against the versions before the big change becomes useless, so trying to find code regressions becomes impossible. Urgh! Been there... useless anecdote follows One time, when we had to change the code to match some prescribed format, what we actually did was fed all the code through an indenter (ISTR we used astyle in practice) with the rules set to get as close as possible to the desired format. Did a reasonable job on the code, though messed up the comments a bit, particularly where the original authors had tried to lay out the comments with ASCII art and stuff... We then compiled the new code and showed that the resulting stripped binary was identical to the un-re-formatted version. And that became our baseline. All diffs were then against that code, in the new style. It pretty much worked, aided considerably by the fact that the diff tool we were using was language sensitive, so ignored changes in the comments, allowing us to progressively fix the messed up comments and put them back as originally intended. Though I'd not necessarily suggest anyone else go this path! Since then I try to keep the same formatting style as the old code. If you must, reformat the new/changed code only, but leave the old. Yes. Selex ES Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
