Unicode characters in codebase.
Hello! A few weeks ago I had some problems with a static analysis tool that couldn't parse NuttX code, due to non-Unicode characters. I provided a couple of PRs and fixed the issues, but it got me thinking... Do we really need Unicode characters within the codebase? I can only think of problems with this, from missing glyphs from fonts, to difficulties in search... I don't see any value in writing μs instead of us, or I²C instead of I2C. What do you think? Shall we allow such characters, or enforce ASCII-only characters in the codebase?
Re: Unicode characters in codebase.
Agree! It is better to avoid it. On 10/10/22, Fotis Panagiotopoulos wrote: > Hello! > > A few weeks ago I had some problems with a static analysis tool that > couldn't parse NuttX code, due to non-Unicode characters. I provided a > couple of PRs and fixed the issues, but it got me thinking... > > Do we really need Unicode characters within the codebase? > > I can only think of problems with this, from missing glyphs from fonts, to > difficulties in search... > I don't see any value in writing μs instead of us, or I²C instead of I2C. > > What do you think? > Shall we allow such characters, or enforce ASCII-only characters in the > codebase? >
Re: Unicode characters in codebase.
Let's remove them! Thanks for looking into this issue Best Regards Alin On Mon, 10 Oct 2022, 17:25 Alan C. Assis, wrote: > Agree! It is better to avoid it. > > On 10/10/22, Fotis Panagiotopoulos wrote: > > Hello! > > > > A few weeks ago I had some problems with a static analysis tool that > > couldn't parse NuttX code, due to non-Unicode characters. I provided a > > couple of PRs and fixed the issues, but it got me thinking... > > > > Do we really need Unicode characters within the codebase? > > > > I can only think of problems with this, from missing glyphs from fonts, > to > > difficulties in search... > > I don't see any value in writing μs instead of us, or I²C instead of I2C. > > > > What do you think? > > Shall we allow such characters, or enforce ASCII-only characters in the > > codebase? > > >
DHCP renewal problem.
Hello everyone, While I am still tracking down various issues regarding networking with NuttX, I observed something interesting within the DHCP client code. When dhcpc_request is called, the current IP address is set to INADDR_ANY. This is in file dhcpc.c, line 714. This sounds normal for the initial request. But what about when renewing the lease? In this case the system already has a perfectly valid IP address. Setting the interface back to INADDR_ANY, even temporarily, can cause problems to other tasks than may be using the same NIC simultaneously. If another task tries any communication during the DHCP renewal, it fails. I don't think that there is an actual need for it to fail. Also, I believe that setting the address to INADDR_ANY does not benefit DHCP, as it is not using the current IP address in any way (it broadcasts only). I am very tempted to remove this from the DHCP client. Unless I am missing something?
Re: Unicode characters in codebase.
Shall I enhance nxstyle to check for this? Is this the correct place for this check? On Mon, Oct 10, 2022 at 6:30 PM Alin Jerpelea wrote: > Let's remove them! > > Thanks for looking into this issue > > Best Regards > Alin > > On Mon, 10 Oct 2022, 17:25 Alan C. Assis, wrote: > > > Agree! It is better to avoid it. > > > > On 10/10/22, Fotis Panagiotopoulos wrote: > > > Hello! > > > > > > A few weeks ago I had some problems with a static analysis tool that > > > couldn't parse NuttX code, due to non-Unicode characters. I provided a > > > couple of PRs and fixed the issues, but it got me thinking... > > > > > > Do we really need Unicode characters within the codebase? > > > > > > I can only think of problems with this, from missing glyphs from fonts, > > to > > > difficulties in search... > > > I don't see any value in writing μs instead of us, or I²C instead of > I2C. > > > > > > What do you think? > > > Shall we allow such characters, or enforce ASCII-only characters in the > > > codebase? > > > > > >
Re: Unicode characters in codebase.
Some of these are are people's names or in documentation, I don't see any reason to update that. Things like mu or I2C seems reasonable to convert for searchability. --Brennan On Mon, Oct 10, 2022, 8:33 AM Fotis Panagiotopoulos wrote: > Shall I enhance nxstyle to check for this? Is this the correct place for > this check? > > On Mon, Oct 10, 2022 at 6:30 PM Alin Jerpelea wrote: > > > Let's remove them! > > > > Thanks for looking into this issue > > > > Best Regards > > Alin > > > > On Mon, 10 Oct 2022, 17:25 Alan C. Assis, wrote: > > > > > Agree! It is better to avoid it. > > > > > > On 10/10/22, Fotis Panagiotopoulos wrote: > > > > Hello! > > > > > > > > A few weeks ago I had some problems with a static analysis tool that > > > > couldn't parse NuttX code, due to non-Unicode characters. I provided > a > > > > couple of PRs and fixed the issues, but it got me thinking... > > > > > > > > Do we really need Unicode characters within the codebase? > > > > > > > > I can only think of problems with this, from missing glyphs from > fonts, > > > to > > > > difficulties in search... > > > > I don't see any value in writing μs instead of us, or I²C instead of > > I2C. > > > > > > > > What do you think? > > > > Shall we allow such characters, or enforce ASCII-only characters in > the > > > > codebase? > > > > > > > > > >
Re: Unicode characters in codebase.
nxstyle should only complain if this is a source or build file, right? And only if if the unicode is outside of a comment. Unicode characters are useful in .txtf, .md, a probably other file typles and also in code comments. There are flags in nxstyle that tells if you the type of file (by extension) and if nxstyle is parsing within a comment. On 10/10/2022 9:33 AM, Fotis Panagiotopoulos wrote: Shall I enhance nxstyle to check for this? Is this the correct place for this check? On Mon, Oct 10, 2022 at 6:30 PM Alin Jerpelea wrote: Let's remove them! Thanks for looking into this issue Best Regards Alin On Mon, 10 Oct 2022, 17:25 Alan C. Assis, wrote: Agree! It is better to avoid it. On 10/10/22, Fotis Panagiotopoulos wrote: Hello! A few weeks ago I had some problems with a static analysis tool that couldn't parse NuttX code, due to non-Unicode characters. I provided a couple of PRs and fixed the issues, but it got me thinking... Do we really need Unicode characters within the codebase? I can only think of problems with this, from missing glyphs from fonts, to difficulties in search... I don't see any value in writing μs instead of us, or I²C instead of I2C. What do you think? Shall we allow such characters, or enforce ASCII-only characters in the codebase?
Re: Unicode characters in codebase.
I am not a attorney, but I seem to recall that a legal reference reference to a copyright or a trademark require the © and small tm superscript . This -- plus the names that Brennan mentions -- are some of the reasons why unicode really needs to be permitted within comments. None of these should appear in code. On 10/10/2022 9:39 AM, Brennan Ashton wrote: Some of these are are people's names or in documentation, I don't see any reason to update that. Things like mu or I2C seems reasonable to convert for searchability. --Brennan On Mon, Oct 10, 2022, 8:33 AM Fotis Panagiotopoulos wrote: Shall I enhance nxstyle to check for this? Is this the correct place for this check? On Mon, Oct 10, 2022 at 6:30 PM Alin Jerpelea wrote: Let's remove them! Thanks for looking into this issue Best Regards Alin On Mon, 10 Oct 2022, 17:25 Alan C. Assis, wrote: Agree! It is better to avoid it. On 10/10/22, Fotis Panagiotopoulos wrote: Hello! A few weeks ago I had some problems with a static analysis tool that couldn't parse NuttX code, due to non-Unicode characters. I provided a couple of PRs and fixed the issues, but it got me thinking... Do we really need Unicode characters within the codebase? I can only think of problems with this, from missing glyphs from fonts, to difficulties in search... I don't see any value in writing μs instead of us, or I²C instead of I2C. What do you think? Shall we allow such characters, or enforce ASCII-only characters in the codebase?
Re: Unicode characters in codebase.
> nxstyle should only complain if this is a source or build file, right? > And only if if the unicode is outside of a comment. Unicode characters > are useful in .txtf, .md, a probably other file typles and also in code > comments. Of course I am talking strictly about .h/.c files. Documentation can use anything. However, I would also include comments. > Some of these are are people's names or in documentation, I don't see any > reason to update that. These can be left as is. Although, I believe that even names shall use ASCII letters only. For example, my name is Φώτης. I wouldn't expect anyone else on this project to actually know how to pronounce or write this... Using the latin letters "Fotis" makes it much more "user-friendly". On Mon, Oct 10, 2022 at 6:40 PM Gregory Nutt wrote: > nxstyle should only complain if this is a source or build file, right? > And only if if the unicode is outside of a comment. Unicode characters > are useful in .txtf, .md, a probably other file typles and also in code > comments. > > There are flags in nxstyle that tells if you the type of file (by > extension) and if nxstyle is parsing within a comment. > > On 10/10/2022 9:33 AM, Fotis Panagiotopoulos wrote: > > Shall I enhance nxstyle to check for this? Is this the correct place for > > this check? > > > > On Mon, Oct 10, 2022 at 6:30 PM Alin Jerpelea > wrote: > > > >> Let's remove them! > >> > >> Thanks for looking into this issue > >> > >> Best Regards > >> Alin > >> > >> On Mon, 10 Oct 2022, 17:25 Alan C. Assis, wrote: > >> > >>> Agree! It is better to avoid it. > >>> > >>> On 10/10/22, Fotis Panagiotopoulos wrote: > Hello! > > A few weeks ago I had some problems with a static analysis tool that > couldn't parse NuttX code, due to non-Unicode characters. I provided a > couple of PRs and fixed the issues, but it got me thinking... > > Do we really need Unicode characters within the codebase? > > I can only think of problems with this, from missing glyphs from > fonts, > >>> to > difficulties in search... > I don't see any value in writing μs instead of us, or I²C instead of > >> I2C. > What do you think? > Shall we allow such characters, or enforce ASCII-only characters in > the > codebase? > > >
Re: Unicode characters in codebase.
I used the following two commands to check for non-ASCII characters within
the codebase:
find . -name "*.h" -exec grep --color='auto' -P -n "[\x80-\xFF]" {} \;
find . -name "*.c" -exec grep --color='auto' -P -n "[\x80-\xFF]" {} \;
The problematic characters are very few.
I could only see two names, one of which is not printed correctly on my
system (I believe).
I saw some © characters, which according to wikipedia (
https://en.wikipedia.org/wiki/Copyright_symbol#Typing_the_character) it is
OK to write as (C).
And then there are some files that contain an unreadable mess within the
comments.
See attached.
[image: image.png]
On Mon, Oct 10, 2022 at 6:49 PM Fotis Panagiotopoulos
wrote:
> > nxstyle should only complain if this is a source or build file, right?
> > And only if if the unicode is outside of a comment. Unicode characters
> > are useful in .txtf, .md, a probably other file typles and also in code
> > comments.
>
> Of course I am talking strictly about .h/.c files. Documentation can use
> anything.
> However, I would also include comments.
>
>
> > Some of these are are people's names or in documentation, I don't see any
> > reason to update that.
>
> These can be left as is. Although, I believe that even names shall use
> ASCII letters only.
> For example, my name is Φώτης. I wouldn't expect anyone else on this
> project to actually know how to pronounce or write this...
> Using the latin letters "Fotis" makes it much more "user-friendly".
>
>
> On Mon, Oct 10, 2022 at 6:40 PM Gregory Nutt wrote:
>
>> nxstyle should only complain if this is a source or build file, right?
>> And only if if the unicode is outside of a comment. Unicode characters
>> are useful in .txtf, .md, a probably other file typles and also in code
>> comments.
>>
>> There are flags in nxstyle that tells if you the type of file (by
>> extension) and if nxstyle is parsing within a comment.
>>
>> On 10/10/2022 9:33 AM, Fotis Panagiotopoulos wrote:
>> > Shall I enhance nxstyle to check for this? Is this the correct place for
>> > this check?
>> >
>> > On Mon, Oct 10, 2022 at 6:30 PM Alin Jerpelea
>> wrote:
>> >
>> >> Let's remove them!
>> >>
>> >> Thanks for looking into this issue
>> >>
>> >> Best Regards
>> >> Alin
>> >>
>> >> On Mon, 10 Oct 2022, 17:25 Alan C. Assis, wrote:
>> >>
>> >>> Agree! It is better to avoid it.
>> >>>
>> >>> On 10/10/22, Fotis Panagiotopoulos wrote:
>> Hello!
>>
>> A few weeks ago I had some problems with a static analysis tool that
>> couldn't parse NuttX code, due to non-Unicode characters. I provided
>> a
>> couple of PRs and fixed the issues, but it got me thinking...
>>
>> Do we really need Unicode characters within the codebase?
>>
>> I can only think of problems with this, from missing glyphs from
>> fonts,
>> >>> to
>> difficulties in search...
>> I don't see any value in writing μs instead of us, or I²C instead of
>> >> I2C.
>> What do you think?
>> Shall we allow such characters, or enforce ASCII-only characters in
>> the
>> codebase?
>>
>>
>>
Re: [RESULT] Release Apache NuttX (Incubating) 11.0.0 [RC2]
Hi, If you want to play with 68k, tell me, the ti68k calculators (ti89,92+,v200,titanium) should be great platforms: 256K RAM and 2-4M flash, full keyboard and lcd screen. They have some peculiarities, I could help with drivers or find friends that could. The cemetech/tiplanet communities should like it. Sebastien On 10/8/22 18:06, Tomek CEDRO wrote: On Sat, Oct 8, 2022 at 4:58 PM Alan C. Assis wrote: Hi Tomek, I think 6502 compiler are evolving, but I don't know if they are compatible. There is a interesting comparison here: https://gglabs.us/node/2293 CC. Gabriele here, since I don't know if here is in our list! Thank you Alan :-) 8-bit platforms are on list, but before I would like to make smooth out-of-the box experience with NuttX on FreeBSD, then port MicroPython to NuttX, then as a training in porting I would prefer to target 16-bit MC68000 in the first place (Atari + Amiga), then 8-bit Atari, in that order, and all of that in my free time between other tasks, so there is no rush :-)
Re: [RESULT] Release Apache NuttX (Incubating) 11.0.0 [RC2]
Several years ago Mike Smith did a 68000 port of NuttX. I’m not sure if he completed it or not, but the port never came upstream. Mike is no longer involved with NuttX and probably not contactable. If anyone out there in PX4 land knows where Mike kept his code, that might be helpful. A port to one of the WDC 65xx parts would also be interesting: https://www.westerndesigncenter.com/ On Mon, Oct 10, 2022 at 4:12 PM Sebastien Lorquet wrote: > Hi, > > If you want to play with 68k, tell me, the ti68k calculators > (ti89,92+,v200,titanium) should be great platforms: 256K RAM and 2-4M > flash, full keyboard and lcd screen. > > They have some peculiarities, I could help with drivers or find friends > that could. > > The cemetech/tiplanet communities should like it. > > Sebastien > > On 10/8/22 18:06, Tomek CEDRO wrote: > > On Sat, Oct 8, 2022 at 4:58 PM Alan C. Assis wrote: > >> Hi Tomek, > >> I think 6502 compiler are evolving, but I don't know if they are > compatible. > >> There is a interesting comparison here: > >> https://gglabs.us/node/2293 > >> CC. Gabriele here, since I don't know if here is in our list! > > Thank you Alan :-) 8-bit platforms are on list, but before I would > > like to make smooth out-of-the box experience with NuttX on FreeBSD, > > then port MicroPython to NuttX, then as a training in porting I would > > prefer to target 16-bit MC68000 in the first place (Atari + Amiga), > > then 8-bit Atari, in that order, and all of that in my free time > > between other tasks, so there is no rush :-) > > >
