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)
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)
> > 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... 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
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)
On 12.04.2013 12:09, MacArthur, Ian (Selex ES, UK) wrote: >> I have tested the new code block for AIX on version 5.1 (which lacks >> the prototype for 'mntctl()' in the header file). >> I have tested the code block for NetBSD on versions 2.0 and 5.1 to >> check that the version detection works as intended (and old versions >> that don't support 'getvfsstat()' behave as before). > > OK, that sounds good; if you are feeling keen, might be worth recording those > results in the STR in case anyone else is looking at it too? Yes, please. That doesn't mean that I will be the one to look at it. ;-) >>> - The code doesn't seem to quite match the supposed fltk coding >> style, see: >>> http://www.fltk.org/cmp.php#CS_GENERAL_CODING_STYLE >>> for more guidelines. >>> (I confess this is often an issue for me, the fltk style is not my >> default style...) >> >> Yes, the braces are not correctly placed. But this is wrong in many >> other places of the current code inside 'Fl_File_Browser.cxx'. > > I noticed that, too... > > >> 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? That does exactly match my opinion. Minimal patch with "correct" coding style, so that we can study the patch and see what's being changed. Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
