Re: Color ANSI support in nsh
I am confused a bit. Are you all guys talking about the same thing? If I understand correctly Christian just wanted to introduce colors to NSH. Colours in the terminal are not about looking good. Colours improve readability. The same text on the screen carries more information. This is why everyone is using syntax highlighting in the editor when programming. It is easier to spot red error and yellow warning than just all black text in terminal log. It would be great if there would be native option to enable this, without pdcurses. On Mon, 17 Aug 2020, 08:32 , wrote: > Please do not make technology about looks in functionality it has to > work and be solid and has to address its purposes. If all is finished and > value is there, one could bring a nice color too it 😉 Color is throwing > money where functionality died > > Ben > > -Oorspronkelijk bericht- > Van: Alan Carvalho de Assis > Verzonden: zondag 16 augustus 2020 17:02 > Aan: dev@nuttx.apache.org > Onderwerp: Re: Color ANSI support in nsh > > Christian, > > If I'm not wrong NuttX already has this feature to fancy interface if you > use of pdcurses library. > > Greg added pdcurses some time ago and Ken Petit added support to use it > over telnet > > BR, > > Alan > > On 8/16/20, Christian Catchpole wrote: > > Yeah i should have had a poke around before posting on the group. I > > keep finding NuttX has so many features in the Kconfig :) I also > > suggested command history then found my Spresence NSH has history, so > > obviously i was not the first to think of it. > > I don't want to go TOO crazy with ANSI colours. I'll experiment with a > > few things and then loop back around and see what others think. > > > > Thanks, > > Christian > > > > > > On Sun, 16 Aug 2020 at 22:11, Dave Marples wrote: > > > >> Hiya, > >> > >> Yes, there's some cheesy simple stuff in there already (mainly to > >> stop the zephyr folks throwing shade cos their terminal is prettier). > >> At the moment it only highlights commands, responses and errors iirc, > >> but making it more context aware would certainly be niceit's > >> already switched on/off by kconfig option. > >> > >> Regards > >> > >> Dave > >> > >> On Sun, 16 Aug 2020, 12:24 David Sidrane, > >> wrote: > >> > >> > Hi Christian, > >> > > >> > As long as there is a Knob in Kconfig to enable / disable each > >> > feature (that defaults to disable) the impact is 0. > >> > > >> > IIRC there is a history, and some fancy-ness that was added by Dave > >> > a > >> while > >> > ago. Good docs and an example defconfig would will keep it > >> > maintained > >> (and > >> > built). Once we have scripted test running against the sim (or real > >> > HW) test cases will keep it from breaking. > >> > > >> > David > >> > > >> > -Original Message- > >> > From: Christian Catchpole [mailto:christ...@catchpole.net] > >> > Sent: Saturday, August 15, 2020 5:52 PM > >> > To: dev@nuttx.apache.org > >> > Subject: Color ANSI support in nsh > >> > > >> > Hi everyone, > >> > > >> > I have been adding ANSI escape codes for colour support to my app’s > >> console > >> > output and have been experimenting with adding it to nsh itself. At > >> > a minimum to colour the prompt. > >> > > >> > I had been thinking this is something i could develop and propose > >> > to come back into the mainline as a nsh kconfig option. > >> > > >> > But before i do, the obvious question is, has this been proposed > >> > before > >> and > >> > are there reasons we wouldn’t want this in NuttX? > >> > > >> > I’m also thinking it would be good to have a single line of command > >> > history. Other configurable options could be clear screen on nsh > >> > entry (I added this as my app was using ANSI line positioning and > >> > resets back into nsh looked messy). There are all sorts of fun > >> > things which could be done with ANSI terminal emulation. > >> > > >> > Thanks, > >> > See you all tonight. Where you’ll see my demo going crazy with ANSI > >> colour > >> > codes. > >> > > >> > Christian > >> > > >> > > > >
RE: Color ANSI support in nsh
Please do not make technology about looks in functionality it has to work and be solid and has to address its purposes. If all is finished and value is there, one could bring a nice color too it 😉 Color is throwing money where functionality died Ben -Oorspronkelijk bericht- Van: Alan Carvalho de Assis Verzonden: zondag 16 augustus 2020 17:02 Aan: dev@nuttx.apache.org Onderwerp: Re: Color ANSI support in nsh Christian, If I'm not wrong NuttX already has this feature to fancy interface if you use of pdcurses library. Greg added pdcurses some time ago and Ken Petit added support to use it over telnet BR, Alan On 8/16/20, Christian Catchpole wrote: > Yeah i should have had a poke around before posting on the group. I > keep finding NuttX has so many features in the Kconfig :) I also > suggested command history then found my Spresence NSH has history, so > obviously i was not the first to think of it. > I don't want to go TOO crazy with ANSI colours. I'll experiment with a > few things and then loop back around and see what others think. > > Thanks, > Christian > > > On Sun, 16 Aug 2020 at 22:11, Dave Marples wrote: > >> Hiya, >> >> Yes, there's some cheesy simple stuff in there already (mainly to >> stop the zephyr folks throwing shade cos their terminal is prettier). >> At the moment it only highlights commands, responses and errors iirc, >> but making it more context aware would certainly be niceit's >> already switched on/off by kconfig option. >> >> Regards >> >> Dave >> >> On Sun, 16 Aug 2020, 12:24 David Sidrane, >> wrote: >> >> > Hi Christian, >> > >> > As long as there is a Knob in Kconfig to enable / disable each >> > feature (that defaults to disable) the impact is 0. >> > >> > IIRC there is a history, and some fancy-ness that was added by Dave >> > a >> while >> > ago. Good docs and an example defconfig would will keep it >> > maintained >> (and >> > built). Once we have scripted test running against the sim (or real >> > HW) test cases will keep it from breaking. >> > >> > David >> > >> > -Original Message- >> > From: Christian Catchpole [mailto:christ...@catchpole.net] >> > Sent: Saturday, August 15, 2020 5:52 PM >> > To: dev@nuttx.apache.org >> > Subject: Color ANSI support in nsh >> > >> > Hi everyone, >> > >> > I have been adding ANSI escape codes for colour support to my app’s >> console >> > output and have been experimenting with adding it to nsh itself. At >> > a minimum to colour the prompt. >> > >> > I had been thinking this is something i could develop and propose >> > to come back into the mainline as a nsh kconfig option. >> > >> > But before i do, the obvious question is, has this been proposed >> > before >> and >> > are there reasons we wouldn’t want this in NuttX? >> > >> > I’m also thinking it would be good to have a single line of command >> > history. Other configurable options could be clear screen on nsh >> > entry (I added this as my app was using ANSI line positioning and >> > resets back into nsh looked messy). There are all sorts of fun >> > things which could be done with ANSI terminal emulation. >> > >> > Thanks, >> > See you all tonight. Where you’ll see my demo going crazy with ANSI >> colour >> > codes. >> > >> > Christian >> > >> >
Re: cpp cxx help - No thread API
Xiang you are amazing! It built flawlessly and the bundled example hellocxx is up and running. Thank you so much! Also, a big thank you NuttX developers for your hard work on this project! Matt On Sun, Aug 16, 2020 at 8:30 AM Xiang Xiao wrote: > I just append a new patch to PR 1592, please try it: > > https://github.com/apache/incubator-nuttx/pull/1592/commits/79afeea64be227e218176805970cca1b2287ba29 > > > > -Original Message- > > From: Matt DeWall > > Sent: Sunday, August 16, 2020 2:28 AM > > To: dev@nuttx.apache.org > > Subject: Re: cpp cxx help - No thread API > > > > Thanks Xiang - that got me to the linking step! I'm getting this error: > > > > make[2]: Leaving directory > > '/nuttx/nuttx_patch/nuttx/boards/arm/stm32/common' > > LD: nuttx > > arm-none-eabi-ld: > > > /tools/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/lib/thumb/v7- > > m/nofp//libsupc++.a(vterminate.o): > > in function `__gnu_cxx::__verbose_terminate_handler()': > > vterminate.cc:(.text._ZN9__gnu_cxx27__verbose_terminate_handlerEv+0xf4): > > undefined reference to `_impure_ptr' > > make[1]: *** [Makefile:172: nuttx] Error 1 > > make[1]: Leaving directory '/nuttx/nuttx_patch/nuttx/arch/arm/src' > > make: *** [tools/Makefile.unix:401: nuttx] Error 2 > > > > I tried the hack going around about using this to overwrite > vterminate.cc for the uclib library: > > > > arm-none-eabi-ar -x libsupc++.a vterminate.o > > > > I was able to generate vterminate.o in that way but the "hack" mentions > overwriting an existing vterminate.o. I can't find > > vterminate.o anywhere else in the project. > > > > Probably doesn't matter, but here's the part of a map generated with > LDFLAGS where it references the _impure_ptr > > > > ... > > _exit > > /nuttx/nuttx_patch/nuttx/staging/libsched.a(exit.o) > > > > /nuttx/nuttx_patch/nuttx/staging/libsched.a(pthread_exit.o) > > _impure_ptr > > > /tools/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/lib/thumb/v7- > > m/nofp//libsupc++.a(vterminate.o) > > _sbss > > /nuttx/nuttx_patch/nuttx/staging/libarch.a(stm32_start.o) > > ... > > > > > > > > > > On Fri, Aug 14, 2020 at 8:24 PM Xiang Xiao > > wrote: > > > > > Only PMC/committer have the permission to update those repositories if > > > I remember correctly, so we can manage github.com/nuttx using the same > > > Apache process. > > > > > > > -Original Message- > > > > From: Gregory Nutt > > > > Sent: Saturday, August 15, 2020 3:27 AM > > > > To: dev@nuttx.apache.org > > > > Subject: Re: cpp cxx help - No thread API > > > > > > > > > > > > > Guys, I think we should move your bitbucket libcxx to > > > > > github.com/nuttx to make it more official. > > > > > > > > > > What do you think? Other (better) option should including official > > > > > support to NuttX on llvm libcxx. > > > > > > > > i would NEVER recommend github.com/nuttx for any significant use. > > > There are many people with totally uncontrolled write access > > > > those repositories. There are not controls, no reviews, no > > > > management, > > > no checks and balances. It is complete unsafe to store > > > > anything that people really depend on. > > > > > > > > I have suggested in the past that we bring those directories under > > > > the > > > project management umbrella, but for no those are unsafe, > > > > unmanaged, garbage repositories. DO NOT PUT ANTYTHING YOU CARE > > > > ABOUT > > > THERE. > > > > > > > > That can change. but that is the current state: Unsafe and only > > > > suited > > > for garbage. > > > > > > > > > > >
RE: cpp cxx help - No thread API
I just append a new patch to PR 1592, please try it: https://github.com/apache/incubator-nuttx/pull/1592/commits/79afeea64be227e218176805970cca1b2287ba29 > -Original Message- > From: Matt DeWall > Sent: Sunday, August 16, 2020 2:28 AM > To: dev@nuttx.apache.org > Subject: Re: cpp cxx help - No thread API > > Thanks Xiang - that got me to the linking step! I'm getting this error: > > make[2]: Leaving directory > '/nuttx/nuttx_patch/nuttx/boards/arm/stm32/common' > LD: nuttx > arm-none-eabi-ld: > /tools/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/lib/thumb/v7- > m/nofp//libsupc++.a(vterminate.o): > in function `__gnu_cxx::__verbose_terminate_handler()': > vterminate.cc:(.text._ZN9__gnu_cxx27__verbose_terminate_handlerEv+0xf4): > undefined reference to `_impure_ptr' > make[1]: *** [Makefile:172: nuttx] Error 1 > make[1]: Leaving directory '/nuttx/nuttx_patch/nuttx/arch/arm/src' > make: *** [tools/Makefile.unix:401: nuttx] Error 2 > > I tried the hack going around about using this to overwrite vterminate.cc for > the uclib library: > > arm-none-eabi-ar -x libsupc++.a vterminate.o > > I was able to generate vterminate.o in that way but the "hack" mentions > overwriting an existing vterminate.o. I can't find > vterminate.o anywhere else in the project. > > Probably doesn't matter, but here's the part of a map generated with LDFLAGS > where it references the _impure_ptr > > ... > _exit > /nuttx/nuttx_patch/nuttx/staging/libsched.a(exit.o) > > /nuttx/nuttx_patch/nuttx/staging/libsched.a(pthread_exit.o) > _impure_ptr > /tools/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/lib/thumb/v7- > m/nofp//libsupc++.a(vterminate.o) > _sbss > /nuttx/nuttx_patch/nuttx/staging/libarch.a(stm32_start.o) > ... > > > > > On Fri, Aug 14, 2020 at 8:24 PM Xiang Xiao > wrote: > > > Only PMC/committer have the permission to update those repositories if > > I remember correctly, so we can manage github.com/nuttx using the same > > Apache process. > > > > > -Original Message- > > > From: Gregory Nutt > > > Sent: Saturday, August 15, 2020 3:27 AM > > > To: dev@nuttx.apache.org > > > Subject: Re: cpp cxx help - No thread API > > > > > > > > > > Guys, I think we should move your bitbucket libcxx to > > > > github.com/nuttx to make it more official. > > > > > > > > What do you think? Other (better) option should including official > > > > support to NuttX on llvm libcxx. > > > > > > i would NEVER recommend github.com/nuttx for any significant use. > > There are many people with totally uncontrolled write access > > > those repositories. There are not controls, no reviews, no > > > management, > > no checks and balances. It is complete unsafe to store > > > anything that people really depend on. > > > > > > I have suggested in the past that we bring those directories under > > > the > > project management umbrella, but for no those are unsafe, > > > unmanaged, garbage repositories. DO NOT PUT ANTYTHING YOU CARE > > > ABOUT > > THERE. > > > > > > That can change. but that is the current state: Unsafe and only > > > suited > > for garbage. > > > > > >
Re: Color ANSI support in nsh
Christian, If I'm not wrong NuttX already has this feature to fancy interface if you use of pdcurses library. Greg added pdcurses some time ago and Ken Petit added support to use it over telnet BR, Alan On 8/16/20, Christian Catchpole wrote: > Yeah i should have had a poke around before posting on the group. I keep > finding NuttX has so many features in the Kconfig :) > I also suggested command history then found my Spresence NSH has history, > so obviously i was not the first to think of it. > I don't want to go TOO crazy with ANSI colours. I'll experiment with a few > things and then loop back around and see what others think. > > Thanks, > Christian > > > On Sun, 16 Aug 2020 at 22:11, Dave Marples wrote: > >> Hiya, >> >> Yes, there's some cheesy simple stuff in there already (mainly to stop >> the >> zephyr folks throwing shade cos their terminal is prettier). At the >> moment >> it only highlights commands, responses and errors iirc, but making it >> more >> context aware would certainly be niceit's already switched on/off by >> kconfig option. >> >> Regards >> >> Dave >> >> On Sun, 16 Aug 2020, 12:24 David Sidrane, >> wrote: >> >> > Hi Christian, >> > >> > As long as there is a Knob in Kconfig to enable / disable each feature >> > (that >> > defaults to disable) the impact is 0. >> > >> > IIRC there is a history, and some fancy-ness that was added by Dave a >> while >> > ago. Good docs and an example defconfig would will keep it maintained >> (and >> > built). Once we have scripted test running against the sim (or real HW) >> > test >> > cases will keep it from breaking. >> > >> > David >> > >> > -Original Message- >> > From: Christian Catchpole [mailto:christ...@catchpole.net] >> > Sent: Saturday, August 15, 2020 5:52 PM >> > To: dev@nuttx.apache.org >> > Subject: Color ANSI support in nsh >> > >> > Hi everyone, >> > >> > I have been adding ANSI escape codes for colour support to my app’s >> console >> > output and have been experimenting with adding it to nsh itself. At a >> > minimum to colour the prompt. >> > >> > I had been thinking this is something i could develop and propose to >> > come >> > back into the mainline as a nsh kconfig option. >> > >> > But before i do, the obvious question is, has this been proposed before >> and >> > are there reasons we wouldn’t want this in NuttX? >> > >> > I’m also thinking it would be good to have a single line of command >> > history. Other configurable options could be clear screen on nsh entry >> > (I >> > added this as my app was using ANSI line positioning and resets back >> > into >> > nsh looked messy). There are all sorts of fun things which could be >> > done >> > with ANSI terminal emulation. >> > >> > Thanks, >> > See you all tonight. Where you’ll see my demo going crazy with ANSI >> colour >> > codes. >> > >> > Christian >> > >> >
Re: Telnet: up arrow key in putty returns ^[[A
Hi Alan, I can open an issue, but I can't check the latest NuttX master in the near future, so I would like not to additionally disturb people yet :) вс, 16 авг. 2020 г. в 17:07, Alan Carvalho de Assis : > Hi Oleg, > > Well, I don't know if there is an easy way to fix it. > > BTW, could you please open an issue for it? > > https://github.com/apache/incubator-nuttx/issues > > BR, > > Alan > > On 8/16/20, Oleg Evseev wrote: > > Hi all, > > > > Up arrow key in Putty returns ^[[A instead of choosing last command when > > connected to NuttX 8.2 via Telnet, while everything is ok when connected > to > > serial console. > > > > I've already tried different keyboard configurations ("linux", Xterm and > so > > on) in putty as suggested in internet - nothing helps. > > > > Windows 10, Extra putty 0.29 RC2 (I've also tried usual putty) > > > > Can it be NuttX issue? > > Thanks in advance for any thoughts. > > > > --- > > With regards, Oleg. > > >
Re: Color ANSI support in nsh
Yeah i should have had a poke around before posting on the group. I keep finding NuttX has so many features in the Kconfig :) I also suggested command history then found my Spresence NSH has history, so obviously i was not the first to think of it. I don't want to go TOO crazy with ANSI colours. I'll experiment with a few things and then loop back around and see what others think. Thanks, Christian On Sun, 16 Aug 2020 at 22:11, Dave Marples wrote: > Hiya, > > Yes, there's some cheesy simple stuff in there already (mainly to stop the > zephyr folks throwing shade cos their terminal is prettier). At the moment > it only highlights commands, responses and errors iirc, but making it more > context aware would certainly be niceit's already switched on/off by > kconfig option. > > Regards > > Dave > > On Sun, 16 Aug 2020, 12:24 David Sidrane, wrote: > > > Hi Christian, > > > > As long as there is a Knob in Kconfig to enable / disable each feature > > (that > > defaults to disable) the impact is 0. > > > > IIRC there is a history, and some fancy-ness that was added by Dave a > while > > ago. Good docs and an example defconfig would will keep it maintained > (and > > built). Once we have scripted test running against the sim (or real HW) > > test > > cases will keep it from breaking. > > > > David > > > > -Original Message- > > From: Christian Catchpole [mailto:christ...@catchpole.net] > > Sent: Saturday, August 15, 2020 5:52 PM > > To: dev@nuttx.apache.org > > Subject: Color ANSI support in nsh > > > > Hi everyone, > > > > I have been adding ANSI escape codes for colour support to my app’s > console > > output and have been experimenting with adding it to nsh itself. At a > > minimum to colour the prompt. > > > > I had been thinking this is something i could develop and propose to come > > back into the mainline as a nsh kconfig option. > > > > But before i do, the obvious question is, has this been proposed before > and > > are there reasons we wouldn’t want this in NuttX? > > > > I’m also thinking it would be good to have a single line of command > > history. Other configurable options could be clear screen on nsh entry (I > > added this as my app was using ANSI line positioning and resets back into > > nsh looked messy). There are all sorts of fun things which could be done > > with ANSI terminal emulation. > > > > Thanks, > > See you all tonight. Where you’ll see my demo going crazy with ANSI > colour > > codes. > > > > Christian > > >
Re: Telnet: up arrow key in putty returns ^[[A
Hi Oleg, Well, I don't know if there is an easy way to fix it. BTW, could you please open an issue for it? https://github.com/apache/incubator-nuttx/issues BR, Alan On 8/16/20, Oleg Evseev wrote: > Hi all, > > Up arrow key in Putty returns ^[[A instead of choosing last command when > connected to NuttX 8.2 via Telnet, while everything is ok when connected to > serial console. > > I've already tried different keyboard configurations ("linux", Xterm and so > on) in putty as suggested in internet - nothing helps. > > Windows 10, Extra putty 0.29 RC2 (I've also tried usual putty) > > Can it be NuttX issue? > Thanks in advance for any thoughts. > > --- > With regards, Oleg. >
Telnet: up arrow key in putty returns ^[[A
Hi all, Up arrow key in Putty returns ^[[A instead of choosing last command when connected to NuttX 8.2 via Telnet, while everything is ok when connected to serial console. I've already tried different keyboard configurations ("linux", Xterm and so on) in putty as suggested in internet - nothing helps. Windows 10, Extra putty 0.29 RC2 (I've also tried usual putty) Can it be NuttX issue? Thanks in advance for any thoughts. --- With regards, Oleg.
Re: Color ANSI support in nsh
Hiya, Yes, there's some cheesy simple stuff in there already (mainly to stop the zephyr folks throwing shade cos their terminal is prettier). At the moment it only highlights commands, responses and errors iirc, but making it more context aware would certainly be niceit's already switched on/off by kconfig option. Regards Dave On Sun, 16 Aug 2020, 12:24 David Sidrane, wrote: > Hi Christian, > > As long as there is a Knob in Kconfig to enable / disable each feature > (that > defaults to disable) the impact is 0. > > IIRC there is a history, and some fancy-ness that was added by Dave a while > ago. Good docs and an example defconfig would will keep it maintained (and > built). Once we have scripted test running against the sim (or real HW) > test > cases will keep it from breaking. > > David > > -Original Message- > From: Christian Catchpole [mailto:christ...@catchpole.net] > Sent: Saturday, August 15, 2020 5:52 PM > To: dev@nuttx.apache.org > Subject: Color ANSI support in nsh > > Hi everyone, > > I have been adding ANSI escape codes for colour support to my app’s console > output and have been experimenting with adding it to nsh itself. At a > minimum to colour the prompt. > > I had been thinking this is something i could develop and propose to come > back into the mainline as a nsh kconfig option. > > But before i do, the obvious question is, has this been proposed before and > are there reasons we wouldn’t want this in NuttX? > > I’m also thinking it would be good to have a single line of command > history. Other configurable options could be clear screen on nsh entry (I > added this as my app was using ANSI line positioning and resets back into > nsh looked messy). There are all sorts of fun things which could be done > with ANSI terminal emulation. > > Thanks, > See you all tonight. Where you’ll see my demo going crazy with ANSI colour > codes. > > Christian >
RE: Color ANSI support in nsh
Hi Christian, As long as there is a Knob in Kconfig to enable / disable each feature (that defaults to disable) the impact is 0. IIRC there is a history, and some fancy-ness that was added by Dave a while ago. Good docs and an example defconfig would will keep it maintained (and built). Once we have scripted test running against the sim (or real HW) test cases will keep it from breaking. David -Original Message- From: Christian Catchpole [mailto:christ...@catchpole.net] Sent: Saturday, August 15, 2020 5:52 PM To: dev@nuttx.apache.org Subject: Color ANSI support in nsh Hi everyone, I have been adding ANSI escape codes for colour support to my app’s console output and have been experimenting with adding it to nsh itself. At a minimum to colour the prompt. I had been thinking this is something i could develop and propose to come back into the mainline as a nsh kconfig option. But before i do, the obvious question is, has this been proposed before and are there reasons we wouldn’t want this in NuttX? I’m also thinking it would be good to have a single line of command history. Other configurable options could be clear screen on nsh entry (I added this as my app was using ANSI line positioning and resets back into nsh looked messy). There are all sorts of fun things which could be done with ANSI terminal emulation. Thanks, See you all tonight. Where you’ll see my demo going crazy with ANSI colour codes. Christian