On Thu, Nov 5, 2020 at 2:28 PM Gedare Bloom <ged...@rtems.org> wrote:
> On Thu, Nov 5, 2020 at 1:14 PM Joel Sherrill <j...@rtems.org> wrote: > > > > I tried at one point to figure out how to script the changes when I ran > into them. > > But it was easier to fix them by hand. If you have a simple script, it > would be good > > to have a home for it. We could grow it then. > > > > Not accepting unicode should be checked for patches and should be in > > Coding Conventions. > > > > I think you made a couple of bad mapping choices. > > > > - "(r)" for the registered symbol (circle R) > > - "u" for the micro Greek letter in usec and us (which is strange for > usec) > > > > Some I have no idea about. > > > > + aes.c - absolutely no idea > > + rtl22xx/console/uart.c - maybe an x > > + powerpc/include/mpc83xx/mpc83xx.h - maybe an x > > > > I think a patch series doing copyright symbols, (r), and u for micro > > as individual changes would eliminate a lot and not be controversial. > > That should leave the remaining for a second pass. > > > > One patch per character change is safer to review. > "per kind of character" > > feel free to send all the (C) together, etc. > +1 > > I think the AES one is pTq, math notation for a vector product using > transpose. > > I used https://www.branah.com/unicode-converter and put the UTF-8 we > have in our repo in the box, and that gives some idea what it should > be in the top unicode box. i.e., put "¡°T¡±" in the UTF-8 box and see > what pops out on top > I was hoping you weren't rickrolling us but that's a neat site. :) I think your translation is right. --joel > > > > > --joel > > > > > > On Thu, Nov 5, 2020 at 1:34 PM Christian Mauderer <o...@c-mauderer.de> > wrote: > >> > >> Hello Joel, > >> > >> On 05/11/2020 20:15, Joel Sherrill wrote: > >> > > >> > > >> > On Thu, Nov 5, 2020, 1:12 PM Christian Mauderer <o...@c-mauderer.de > >> > <mailto:o...@c-mauderer.de>> wrote: > >> > > >> > Hello Joel and Sebastian, > >> > > >> > On 05/11/2020 16:44, Joel Sherrill wrote: > >> > > > >> > > > >> > > On Thu, Nov 5, 2020, 9:26 AM Sebastian Huber > >> > > <sebastian.hu...@embedded-brains.de > >> > <mailto:sebastian.hu...@embedded-brains.de> > >> > > <mailto:sebastian.hu...@embedded-brains.de > >> > <mailto:sebastian.hu...@embedded-brains.de>>> wrote: > >> > > > >> > > Hello, > >> > > > >> > > I review currently the Coding Conventions. Should the 80 > >> > characters > >> > > limit be really a 79 characters limit with the \n as the > >> > invisible 80th > >> > > character? > >> > > > >> > > > >> > > Yes. > >> > > > >> > > As old as this makes me feel, I remember printers which did an > >> > automatic > >> > > linefeed and then the newline one if you hit column 80. So it > >> > really is > >> > > 79 unfortunately. > >> > > >> > I don't think printers with an automatic linefeed are a common > use case > >> > for reading the RTEMS source code nowadays. So that maybe isn't > the best > >> > reason for using 79 characters. > >> > > >> > > >> > +1 > >> > > >> > > >> > I would suggest to use the same convention that most coding > styles use > >> > which seems to be 80 characters: > >> > > >> > > https://en.wikipedia.org/wiki/Characters_per_line#In_programming > >> > > >> > At least if there are no more recent examples for tools or > editors where > >> > 79 is a benefit. 80 seems just feels a bit more natural. > >> > > >> > > >> > By the way: If we count '\n': Should we count a tab '\t' as a > single > >> > character, as 2, as 4 or as 8 ones? > >> > > >> > > >> > We shouldn't have tabs in code we own. > >> > >> Good point. > >> > >> > > >> > What about the few Unicode > >> > characters that slipped in over the years? > >> > > >> > > >> > We also shouldn't have unicode characters randomly floating around. > They > >> > tend to pop up in my experience when people copy from word processors > >> > and get fancy quotes. Those cases should be eliminated > >> > >> Last time I stumbled across a tool that didn't like unicode characters I > >> found about 75 lines in RTEMS with unicode characters. I have been to > >> lazy to fix them back then. Mostly because some of them would have > >> needed some thought about what there should have been (I assume it has > >> been a microsecond in some cases, but still not sure). Attached you can > >> find a patch that should replaces most of them without much thought > >> about the content. If you think it's useful, I can polish it up a bit. > >> > >> Best regards > >> > >> Christian > >> > >> > > >> > > >> > Best regards > >> > > >> > Christian > >> > > >> > > > >> > > > >> > > -- > >> > > embedded brains GmbH > >> > > Sebastian HUBER > >> > > Dornierstr. 4 > >> > > 82178 Puchheim > >> > > Germany > >> > > email: sebastian.hu...@embedded-brains.de > >> > <mailto:sebastian.hu...@embedded-brains.de> > >> > > <mailto:sebastian.hu...@embedded-brains.de > >> > <mailto:sebastian.hu...@embedded-brains.de>> > >> > > Phone: +49-89-18 94 741 - 16 > >> > > Fax: +49-89-18 94 741 - 08 > >> > > PGP: Public key available on request. > >> > > > >> > > embedded brains GmbH > >> > > Registergericht: Amtsgericht München > >> > > Registernummer: HRB 157899 > >> > > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, > >> > Thomas Dörfler > >> > > Unsere Datenschutzerklärung finden Sie hier: > >> > > https://embedded-brains.de/datenschutzerklaerung/ > >> > > > >> > > _______________________________________________ > >> > > devel mailing list > >> > > devel@rtems.org <mailto:devel@rtems.org> > >> > <mailto:devel@rtems.org <mailto:devel@rtems.org>> > >> > > http://lists.rtems.org/mailman/listinfo/devel > >> > > > >> > > > >> > > _______________________________________________ > >> > > devel mailing list > >> > > devel@rtems.org <mailto:devel@rtems.org> > >> > > http://lists.rtems.org/mailman/listinfo/devel > >> > > > >> > > > > > _______________________________________________ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
