Re: [IMPORTANT] - Migration to ci-builds.a.o

[Brennan Ashton]

Dave,
Our INFRA ticket is still waiting so I cannot migrate the job.

https://issues.apache.org/jira/browse/INFRA-20687

Thanks,
Brennan

On Fri, Aug 14, 2020, 1:27 PM Dave Fisher  wrote:

> You will find this page helpful:
> https://cwiki.apache.org/confluence/display/INFRA/Migrating+jobs+from+Jenkins+to+Cloudbees
>
> > On Aug 14, 2020, at 1:02 PM, Brennan Ashton 
> wrote:
> >
> > Dave,
> > Thanks for the heads up.  We did not know about this (I'll subscribe
> > to the build list), it looks like we need to file a ticket for a new
> > folder to be created for the project (NuttX).  I'll do that now and
> > try to migrate tonight.
> >
> > Thanks
> > --Brennan
> >
> > On Fri, Aug 14, 2020 at 12:49 PM Dave Fisher  wrote:
> >>
> >> Hi -
> >>
> >> There is a critical migration for Jenkins builds that the project is
> missing.
> >>
> >> Several PMC members ought to be subscribed to bui...@apache.org.
> >>
> >> Please act quickly.
> >>
> >> Regards,
> >> Dave
> >>
> >>> Begin forwarded message:
> >>>
> >>> From: Gavin McDonald 
> >>> Subject: [IMPORTANT] - Migration to ci-builds.a.o
> >>> Date: July 16, 2020 at 9:33:08 AM PDT
> >>> To: builds 
> >>> Reply-To: bui...@apache.org
> >>> Reply-To: gmcdon...@apache.org
> >>>
> >>> Hi All,
> >>>
> >>> This NOTICE is for everyone on builds.apache.org. We are migrating to
> a new
> >>> Cloudbees based Client Master called https://ci-builds.apache.org. The
> >>> migrations of all jobs needs to be done before the switch off date of
> 15th
> >>> August 2020, so you have a maximum of 4 weeks.
> >>>
> >>> There is no tool or automated way of migrating your jobs, the
> >>> differences in the platforms, the plugins and the setup makes it
> impossible
> >>> to do in a safe way. So, you all need to start creating new jobs on
> >>> ci-infra.a.o and then , when you are happy, turn off your old builds on
> >>> builds.a.o.
> >>>
> >>> There are currently 4 agents over there ready to take jobs, plus a
> floating
> >>> agent which is shared amongst many masters (more to come). I will
> migrate
> >>> away 2 more agents from builds.a.o to ci-builds.a.o every few days, and
> >>> will keep an eye of load across both and adjust accordingly.
> >>>
> >>> If needed, create a ticket on INFRA jira for any issues that crop up,
> or
> >>> email here on builds@a.o. there may be one or two plugins we need to
> >>> install/tweak etc.
> >>>
> >>> We will be not using 'Views' at the top level, but rather we will take
> >>> advantage of 'Folders Plus' - each project will get its own Folder and
> have
> >>> authorisation access to create/edit jobs etc within that folder. I will
> >>> create these folders as you ask for them to start with. This setup
> allows
> >>> for credentials isolation amongst other benefits, including but not
> limited
> >>> to exclusive agents (Controlled Agents) for your own use , should you
> have
> >>> any project targeted donations of agents.
> >>>
> >>> As with other aspects of the ASF, projects can choose to just enable
> all
> >>> committers access to their folder, just ask.
> >>>
> >>> We will re-use builds.apache.org as a CNAME to ci-builds.a.o but will
> not
> >>> be setting up any forwarding rules or anything like that.
> >>>
> >>> So, please, get started *now *on this so you can be sure we are all
> >>> completed before the final cutoff date of 15th August 2020.
> >>>
> >>> Any questions - I expect a few (dozen :) ) - ask away and/or file INFRA
> >>> tickets.
> >>>
> >>> Hadoop and related projects have their own migration path to follow,
> same
> >>> cut off date, Cassandra, Beam, CouchDB have already migrated and are
> doing
> >>> very well in their new homes.
> >>>
> >>> Lets get going ...
> >>>
> >>> --
> >>>
> >>> *Gavin McDonald*
> >>> Systems Administrator
> >>> ASF Infrastructure Team
> >>
>
>

Build failed in Jenkins: NuttX-Nightly-Build #254

[Apache Jenkins Server]

See 

Changes:


--
Started by timer
Running as SYSTEM
[EnvInject] - Loading node environment variables.
[EnvInject] - Preparing an environment for the build.
[EnvInject] - Keeping Jenkins system variables.
[EnvInject] - Keeping Jenkins build variables.
[EnvInject] - Executing and processing the following script content: 
# This is a read-only credential and not explicitly a secret.  There does not 
seem to be a way to do this with the Jenkins docker plugin...
# This docker env plugin also manages to mess up pulling from docker hub...
# see JENKINS-54021
rm -rf ~/.docker/config.json
docker pull alpine:3.6

set +x
docker login https://docker.pkg.github.com -u btashton -p $GITHUB_RO_TOKEN
set -x

[jenkins-slave] $ /bin/bash -xe /tmp/jenkins8716576510528724131.sh
+ rm -rf /home/jenkins/.docker/config.json
+ docker pull alpine:3.6
3.6: Pulling from library/alpine
5a3ea8efae5d: Pulling fs layer
5a3ea8efae5d: Download complete
5a3ea8efae5d: Pull complete
Digest: sha256:66790a2b79e1ea3e1dabac43990c54aca5d1ddf268d9a5a0285e4167c8b24475
Status: Downloaded newer image for alpine:3.6
docker.io/library/alpine:3.6
+ set +x
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
WARNING! Your password will be stored unencrypted in 
/home/jenkins/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store

Login Succeeded
[EnvInject] - Script executed successfully.
[EnvInject] - Injecting contributions.
Building remotely on H27 (ubuntu) in workspace 

Pull Docker image 
docker.pkg.github.com/apache/incubator-nuttx-testing/nuttx-ci-linux:latest from 
repository ...
$ docker pull 
docker.pkg.github.com/apache/incubator-nuttx-testing/nuttx-ci-linux:latest
latest: Pulling from apache/incubator-nuttx-testing/nuttx-ci-linux
Digest: sha256:c71a630cd84a1965b264719500354c27a918a501b7c75091d107283586e9a6bc
Status: Image is up to date for 
docker.pkg.github.com/apache/incubator-nuttx-testing/nuttx-ci-linux:latest
docker.pkg.github.com/apache/incubator-nuttx-testing/nuttx-ci-linux:latest
$ docker run --rm --entrypoint /bin/true alpine:3.6
$ docker run --tty --rm --entrypoint /sbin/ip alpine:3.6 route
$ docker run --tty --detach --privileged --workdir 
 --volume 
/home/jenkins/jenkins-slave:/home/jenkins/jenkins-slave:rw --volume 
/tmp:/tmp:rw --net bridge --add-host dockerhost:172.17.0.1 --env 
BUILD_CAUSE=TIMERTRIGGER --env BUILD_CAUSE_TIMERTRIGGER=true --env 
BUILD_DISPLAY_NAME=#254 --env BUILD_ID=254 --env BUILD_NUMBER=254 --env 
BUILD_TAG=jenkins-NuttX-Nightly-Build-254 --env 
BUILD_URL=https://builds.apache.org/job/NuttX-Nightly-Build/254/ --env 
CLASSPATH= --env EXECUTOR_NUMBER=1 --env  --env 
HUDSON_HOME=/x1/jenkins/jenkins-home --env 
HUDSON_SERVER_COOKIE=f4ebd1e6b0d976e8 --env 
HUDSON_URL=https://builds.apache.org/ --env 
JENKINS_HOME=/x1/jenkins/jenkins-home --env 
JENKINS_SERVER_COOKIE=f4ebd1e6b0d976e8 --env 
JENKINS_URL=https://builds.apache.org/ --env JOB_BASE_NAME=NuttX-Nightly-Build 
--env 
JOB_DISPLAY_URL=https://builds.apache.org/job/NuttX-Nightly-Build/display/redirect
 --env JOB_NAME=NuttX-Nightly-Build --env 
JOB_URL=https://builds.apache.org/job/NuttX-Nightly-Build/ --env 
NIX_LABEL=ubuntu --env "NODE_LABELS=H27 ubuntu" --env NODE_NAME=H27 --env 
ROOT_BUILD_CAUSE=TIMERTRIGGER --env ROOT_BUILD_CAUSE_TIMERTRIGGER=true --env 
RUN_CHANGES_DISPLAY_URL=https://builds.apache.org/job/NuttX-Nightly-Build/254/display/redirect?page=changes
 --env 
RUN_DISPLAY_URL=https://builds.apache.org/job/NuttX-Nightly-Build/254/display/redirect
 --env WIN_LABEL=Windows --env 
WORKSPACE= 
docker.pkg.github.com/apache/incubator-nuttx-testing/nuttx-ci-linux:latest 
/bin/bash -c tail -f /dev/null
Docker container 
7f8238b73211f713540066f6780b0677baef534d97ce0180a65db2b74a016a98 started to 
host the build
$ docker exec --tty 
7f8238b73211f713540066f6780b0677baef534d97ce0180a65db2b74a016a98 env
[NuttX-Nightly-Build] $ docker exec --tty --user 910:910 
7f8238b73211f713540066f6780b0677baef534d97ce0180a65db2b74a016a98 env 
_=/home/jenkins/tools/java/latest1.8/bin/java BUILD_CAUSE=TIMERTRIGGER 
BUILD_CAUSE_TIMERTRIGGER=true BUILD_DISPLAY_NAME=#254 BUILD_ID=254 
BUILD_NUMBER=254 BUILD_TAG=jenkins-NuttX-Nightly-Build-254 
BUILD_URL=https://builds.apache.org/job/NuttX-Nightly-Build/254/ CLASSPATH= 
EXECUTOR_NUMBER=1 GITHUB_RO_TOKEN=32a0204cbf2be36a8da2c25586c1391ce802c542 
HOME=/home/jenkins HOSTNAME=7f8238b73211 HUDSON_HOME=/x1/jenkins/jenkins-home 
HUDSON_SERVER_COOKIE=f4ebd1e6b0d976e8 HUDSON_URL=https://builds.apache.org/ 
JENKINS_HOME=/x1/jenkins/jenkins-home JENKINS_SERVER_COOKIE=f4ebd1e6b0d976e8 
JENKINS_URL=https://builds.apache.org/ JOB_BASE_NAME=Nu

Re: Color ANSI support in nsh

[Christian Catchpole]

Thanks Matias!

I've dropped the code into a gist if anyone is interested in using it.
It's c++ but of course wouldn't take much to turn in a C with structs. and
of course modify it in other ways to your own needs.

You simply call one of these methods..

void log(const char * source, const char * instance, const char * action,
char * detail);
void log(const char * source, const char * instance, const char * action,
char * detail, int value);

the second is simply a convenience to print a message with an integer.
source, instance and action should be constant / non moving. if they do
move the pointer compare (not string compare) will simply miss and it will
go to a new line.  if it runs out of lines it simply replaces the last
time. total lines is defined by a constant as this affects the amount of
memory it's going to consume.

https://gist.github.com/slipperyseal/2903dea1c34b21476dab4e2aab963467

CC


On Tue, 18 Aug 2020 at 09:50, Matias N.  wrote:

> I really liked your telemetry app with colored output you shown on the
> video.
>
> On Mon, Aug 17, 2020, at 20:47, Christian Catchpole wrote:
> > something to consider with querying the terminal for capabilities /
> > terminal size etc, is where there is no terminal actually connected at
> the
> > time.  this would cause it to hang or require timeouts or other
> > complications. but i guess querying might only occur after user input.
> > Again, as long as its all optional, people can apply what they like.
> >
> > this is something i really love about NuttX. nice and lean baseline but
> so
> > much discoverable behind kconfig options.
> >
> > again, i'll put together a basic proposal for ANSI support in NSH and see
> > what people think of the implementation.
> >
> >
> > On Tue, 18 Aug 2020 at 05:06, Gregory Nutt  wrote:
> >
> > > A basic terminfo/termcaps  could be very trivial
> > >
> > > > A more general solution would be handy but what is there really in
> the
> > > > embedded world that doesn't support vt100? There more code there is,
> the
> > > > more interesting ways it can go wrong :-)
> > >
> > > I have sometimes used cat /dev/ttyS0 on the host as a terminal.
> > >
> > > I seen some simple Linux terminals that do not support VT-100.
> > >
> > > The NuttX cu terminal does not support VT-100 commands.
> > >
> > > There are several.
> > >
> > >
> > >
> >
>

Re: Color ANSI support in nsh

[Alan Carvalho de Assis]

I liked it to!

Should be nice to have some "text bar" widgets too, like we have in
the alsamixer ;-)

BR,

Alan

On 8/17/20, Matias N.  wrote:
> I really liked your telemetry app with colored output you shown on the
> video.
>
> On Mon, Aug 17, 2020, at 20:47, Christian Catchpole wrote:
>> something to consider with querying the terminal for capabilities /
>> terminal size etc, is where there is no terminal actually connected at
>> the
>> time.  this would cause it to hang or require timeouts or other
>> complications. but i guess querying might only occur after user input.
>> Again, as long as its all optional, people can apply what they like.
>>
>> this is something i really love about NuttX. nice and lean baseline but
>> so
>> much discoverable behind kconfig options.
>>
>> again, i'll put together a basic proposal for ANSI support in NSH and see
>> what people think of the implementation.
>>
>>
>> On Tue, 18 Aug 2020 at 05:06, Gregory Nutt  wrote:
>>
>> > A basic terminfo/termcaps  could be very trivial
>> >
>> > > A more general solution would be handy but what is there really in
>> > > the
>> > > embedded world that doesn't support vt100? There more code there is,
>> > > the
>> > > more interesting ways it can go wrong :-)
>> >
>> > I have sometimes used cat /dev/ttyS0 on the host as a terminal.
>> >
>> > I seen some simple Linux terminals that do not support VT-100.
>> >
>> > The NuttX cu terminal does not support VT-100 commands.
>> >
>> > There are several.
>> >
>> >
>> >
>>
>

Re: Color ANSI support in nsh

[Matias N.]

I really liked your telemetry app with colored output you shown on the video.

On Mon, Aug 17, 2020, at 20:47, Christian Catchpole wrote:
> something to consider with querying the terminal for capabilities /
> terminal size etc, is where there is no terminal actually connected at the
> time.  this would cause it to hang or require timeouts or other
> complications. but i guess querying might only occur after user input.
> Again, as long as its all optional, people can apply what they like.
> 
> this is something i really love about NuttX. nice and lean baseline but so
> much discoverable behind kconfig options.
> 
> again, i'll put together a basic proposal for ANSI support in NSH and see
> what people think of the implementation.
> 
> 
> On Tue, 18 Aug 2020 at 05:06, Gregory Nutt  wrote:
> 
> > A basic terminfo/termcaps  could be very trivial
> >
> > > A more general solution would be handy but what is there really in the
> > > embedded world that doesn't support vt100? There more code there is, the
> > > more interesting ways it can go wrong :-)
> >
> > I have sometimes used cat /dev/ttyS0 on the host as a terminal.
> >
> > I seen some simple Linux terminals that do not support VT-100.
> >
> > The NuttX cu terminal does not support VT-100 commands.
> >
> > There are several.
> >
> >
> >
> 

Re: Color ANSI support in nsh

[Christian Catchpole]

something to consider with querying the terminal for capabilities /
terminal size etc, is where there is no terminal actually connected at the
time.  this would cause it to hang or require timeouts or other
complications. but i guess querying might only occur after user input.
Again, as long as its all optional, people can apply what they like.

this is something i really love about NuttX. nice and lean baseline but so
much discoverable behind kconfig options.

again, i'll put together a basic proposal for ANSI support in NSH and see
what people think of the implementation.


On Tue, 18 Aug 2020 at 05:06, Gregory Nutt  wrote:

> A basic terminfo/termcaps  could be very trivial
>
> > A more general solution would be handy but what is there really in the
> > embedded world that doesn't support vt100? There more code there is, the
> > more interesting ways it can go wrong :-)
>
> I have sometimes used cat /dev/ttyS0 on the host as a terminal.
>
> I seen some simple Linux terminals that do not support VT-100.
>
> The NuttX cu terminal does not support VT-100 commands.
>
> There are several.
>
>
>

Re: new documentation

[Nathan Hartman]

On Mon, Aug 17, 2020 at 4:28 PM Matias N.  wrote:

> Hi everyone,
>
> just wanted to let you know in case it was lost in the sea of github
> notification emails that today I undraft the
> "new documentation" PR so that you can start reviewing it. Please have a
> look at the PR description to get a better
> idea of the changes and go into the link included there where you can see
> the rendered documentation. You can also
> have a look at the RST files themselves to observe how they look.


Thanks for the heads up!

While we had good feedback on this thread and on the PR already, we would
> like to be sure everyone gets a chance to
> look at it since this replaces the current HTML based documentation.
>
> PR: https://github.com/apache/incubator-nuttx/pull/1501


Will do. Thanks again!

Nathan

Re: new documentation

[Matias N.]

Hi everyone,

just wanted to let you know in case it was lost in the sea of github 
notification emails that today I undraft the 
"new documentation" PR so that you can start reviewing it. Please have a look 
at the PR description to get a better
idea of the changes and go into the link included there where you can see the 
rendered documentation. You can also
have a look at the RST files themselves to observe how they look.

While we had good feedback on this thread and on the PR already, we would like 
to be sure everyone gets a chance to
look at it since this replaces the current HTML based documentation.

PR: https://github.com/apache/incubator-nuttx/pull/1501

Best,
Matias

On Mon, Aug 3, 2020, at 13:17, Matias N. wrote:
> Yeah, that's definitely one of the things that we discussed.
> 
> Thanks for the feedback, I think the next step would be to open a draft PR
> and then continue working on migrating the HTML docs from there. While the PR
> is open, the CI we setup will continue to update the documentation at the
> URL I shared before. Once we finish migration we would switch CI system to
> publish docs at the NuttX website and then the PR should be mergeable.
> 
> Since I'm waiting for a board to arrive to continue with the BLE stuff I'll 
> pick this up.
> I will build up a list of TODOs to complete migration and include it in the 
> PR description.
> 
> Best,
> Matias
> 
> On Mon, Aug 3, 2020, at 13:10, Adam Feuer wrote:
>> Alin and Alan,
>> 
>> Regarding showing clear status of the NuttX support for each board– yes,
>> good idea. Matias and I already talked about some ways to do that. We just
>> didn't want to work on that without getting some show of support for this
>> direction.
>> 
>> cheers
>> adam
>> 
>> On Mon, Aug 3, 2020 at 1:01 AM Jerpelea, Alin 
>> wrote:
>> 
>> > Hi Adam,
>> > the new documentation looks good and I found it structured and easy to
>> > follow.
>> > I like Alan's suggestion with the status of each board so that people can
>> > know what the status of each board is and set the proper expectation
>> > Best Regards
>> > Alin
>> >
>> > 
>> > Från: Alan Carvalho de Assis 
>> > Skickat: den 1 augusti 2020 21:34
>> > Till: dev@nuttx.apache.org 
>> > Ämne: Re: new documentation
>> >
>> > Hi Adam,
>> >
>> > It is already getting a very good shape! This is a great improvement to
>> > NuttX!
>> >
>> > In the Supported Boards I think we could implement some table showing
>> > the supported status of each board, similar to this:
>> >
>> > https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.postmarketos.org_wiki_Devices&d=DwIBaQ&c=fP4tf--1dS0biCFlB0saz0I0kjO5v7-GLPtvShAo4cc&r=9PLdMPCoy-UxqQeL_7fkXjdHjEO-awBtN4-Wr8MqKGE&m=W5J6Fu44S6B8l5kjBrq0VIctd4MfVrBMufGYk2rhMiM&s=NZhumqoq022xPnYUJi5awErtVlI4mp4ZVmG2CXbsnaY&e=
>> >
>> > Some RTOSes claim to support some boards, but when you try to use it
>> > you discover only some basic features are supported. I think it is
>> > good for NuttX to make things clear from start.
>> >
>> > Just my 2 cents.
>> >
>> > BR,
>> >
>> > Alan
>> >
>> > On 8/1/20, Adam Feuer  wrote:
>> > > Thanks Xiang.
>> > >
>> > > Does anyone else have feedback or improvement ideas?
>> > >
>> > > cheers
>> > > adam
>> > >
>> > > On Sat, Aug 1, 2020 at 1:28 AM Xiang Xiao 
>> > > wrote:
>> > >
>> > >> I looked at the content last week, but forget to send my feedback email,
>> > >> sorry. I definitely support the idea: the document is
>> > >> managed and released as the source code and collect all documents in one
>> > >> place. This step is very important to keep the consistent
>> > >> between the implementation and the documentation. It also encourage the
>> > >> contributor improve the document just like the code.
>> > >>
>> > >> > -Original Message-
>> > >> > From: Matias N. 
>> > >> > Sent: Saturday, August 1, 2020 1:01 AM
>> > >> > To: dev@nuttx.apache.org
>> > >> > Subject: Re: new documentation
>> > >> >
>> > >> > Hi again,
>> > >> > I was wondering if you have checked the demo for the new documentation
>> > >> that Brennan, Adam and me have put together. I'm really
>> > >> > looking forward to see this part of the official repo. If we can get
>> > >> some validation on the this we can start building a PR to
>> > >> finish
>> > >> > migrating the HTMLs and link existing READMEs as a first step. We can
>> > >> continue working on the content in iterations after that.
>> > >> >
>> > >> > Best,
>> > >> > Matias
>> > >> >
>> > >> > On Thu, Jul 23, 2020, at 11:22, Matias N. wrote:
>> > >> > > Hi,
>> > >> > > I started a new thread since the "Markdown READMEs" one was already
>> > >> too long and it is probably best to leave that one for the
>> > >> > Markdown conversion effort on its own.
>> > >> > > The last couple of days Brennan, Adam and me managed to build a
>> > >> > > working demo of the proposed documentation system. We used a
>> > separate
>> > >> > > repo since the CI jobs we're using (GitHub pages based) are not
>> > 

Re: Color ANSI support in nsh

[Gregory Nutt]

A basic terminfo/termcaps  could be very trivial


A more general solution would be handy but what is there really in the
embedded world that doesn't support vt100? There more code there is, the
more interesting ways it can go wrong :-)


I have sometimes used cat /dev/ttyS0 on the host as a terminal.

I seen some simple Linux terminals that do not support VT-100.

The NuttX cu terminal does not support VT-100 commands.

There are several.

Re: Color ANSI support in nsh

[Dave Marples]

A more general solution would be handy but what is there really in the
embedded world that doesn't support vt100? There more code there is, the
more interesting ways it can go wrong :-)

(BTW; ctrl-L to clear the screen was one of the first things I added after
fixing backspace/deleteboth of those drove me crazy).

Regards

Dave

On Mon, 17 Aug 2020, 15:51 Gregory Nutt,  wrote:

>
> > I would suggest that you look at how this is handled in standard
> terminals. This works in the form
> > of escape sequence which give a code that the terminal can interpret as
> being a color. This would
> > make it available to applications in a standard form.
>
> Good point.  The GNU part of GNU/Linux devotes a lot of logic into
> managing terminals. Eg.
>
> https://www.gnu.org/software/termutils/manual/termcap-1.3/html_mono/termcap.html
> and https://linux.die.net/man/5/terminfo and
> https://pubs.opengroup.org/onlinepubs/007908799/xcurses/terminfo.html
> and etc...
>
> NuttX generally just hard codes VT-100 terminal types (or the
> almost-dentical ANSII terminal type).  But there are lots of others.
> Perhaps we should really be considering how we handle terminals in
> general not just color on or off?  That is really what the current
> discussion is about, terminal capabilities (termcaps) and
> customizations.  Maybe, as a start, we should consider a
> terminfo/termaps for monochrome vs. color only.  That would be a step in
> the Unix direction version yet-another-ad-hoc-config-setting.
>
>
>
>

Re: Pre-check flow

[Brennan Ashton]

Ramya,
Apologies, for the delay.  I think what would make the most sense to
start just updating the existing Docker file to include a new build
stage for the toolchain and open a PR.  We can then look at the build
time and move things around a bit if we need to.  One of the things
that we can do is publish an image that contains the rx build stage
and then pull that when doing later build in the CI.  This will let us
skip building that stage if it is untouched.

--Brennan

On Mon, Aug 17, 2020 at 5:35 AM Ramya N  wrote:
>
> Hi Brennan,
>
> Can you please share your comments regarding the build time for container as 
> shared in the previous mail.
>
> Best Regards,
> Ramya N
> 
> From: Ramya N 
> Sent: 12 August 2020 20:37
> To: dev@nuttx.apache.org 
> Subject: Re: Pre-check flow
>
> 
>  **This is an external email. Please check the sender’s full email address 
> (not just the sender name) and exercise caution before you respond or click 
> any embedded link/attachment.**
> 
>
> Hi,
>
> I am planning to add RX Toolchain for the Renesas architecture (for RX65N 
> board) with reference to the build steps provided in the below URL,
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc-renesas.com%2Fwiki%2Findex.php%3Ftitle%3DHow_to_build_the_RX_Toolchain_under_Ubuntu_14.04&data=02%7C01%7Cramya.n%40tataelxsi.co.in%7Cd246105d086140414f3108d83ed17604%7Cad6a39dd96b6436882daf2ec4d92e26a%7C0%7C0%7C637328416671279997&sdata=rrECtJf5DVRS0XIhA0fPiD2SdJbzvsGrbOkw73oYTRI%3D&reserved=0
>
> I checked on the local build time for the container when RX Toolchain is 
> added. Build time would be increased to 30 minutes (approx).
>
> I'm new to the docker container setup in the github. Is there any reference 
> available for publishing the intermediate container and using it when 
> building?
>
> Does "publish the intermediate container" mean pushing the Dockerfile (with 
> RX toolchain) to incubator-nuttx-testing repo?
>
> Best Regards,
> Ramya N
> 
> From: Brennan Ashton 
> Sent: 11 August 2020 10:29
> To: dev@nuttx.apache.org 
> Subject: Re: Pre-check flow
>
> 
>  **This is an external email. Please check the sender’s full email address 
> (not just the sender name) and exercise caution before you respond or click 
> any embedded link/attachment.**
> 
>
> On Mon, Aug 10, 2020, 9:42 PM Xiang Xiao  wrote:
>
> >
> >
> > > -Original Message-
> > > From: Ramya N 
> > > Sent: Monday, August 10, 2020 10:42 PM
> > > To: dev@nuttx.apache.org
> > > Subject: Pre-check flow
> > >
> > > Hi,
> > >
> > > 1. In the NuttX Pre-check flow, docker image is built from "Pre-built
> > Toolchain" of each architecture. If the pre-built toolchain
> > is not
> > > available, can we build the toolchain from "Toolchain Source Code" in
> > the Dockerfile of incubator-nuttx-testing repo?
> > >
> >
> > I think so, but Brennan can give more input.
> >
>
> We can although I would like more details on this. I don't want to give
> people horrible build times for the container so it might make sense to
> publish the intermediate container as well and use that when building.
>
> Can you share what architecture and compiler you are wanting to add?
>
> --Brennan
>
> >
> 
> Disclaimer: This email and any files transmitted with it are confidential and 
> intended solely for the use of the individual or entity to whom they are 
> addressed. If you are not the intended recipient of this message , or if this 
> message has been addressed to you in error, please immediately alert the 
> sender by reply email and then delete this message and any attachments. If 
> you are not the intended recipient, you are hereby notified that any use, 
> dissemination, copying, or storage of this message or its attachments is 
> strictly prohibited. Email transmission cannot be guaranteed to be secure or 
> error-free, as information could be intercepted, corrupted, lost, destroyed, 
> arrive late or incomplete, or contain viruses. The sender, therefore, does 
> not accept liability for any errors, omissions or contaminations in the 
> contents of this message which might have occurred as a result of email 
> transmission. If verification is required, please request for a hard-copy 
> version.
> 

Re: Color ANSI support in nsh

[Gregory Nutt]

I would suggest that you look at how this is handled in standard terminals. 
This works in the form
of escape sequence which give a code that the terminal can interpret as being a 
color. This would
make it available to applications in a standard form.


Good point.  The GNU part of GNU/Linux devotes a lot of logic into 
managing terminals. Eg. 
https://www.gnu.org/software/termutils/manual/termcap-1.3/html_mono/termcap.html 
and https://linux.die.net/man/5/terminfo and 
https://pubs.opengroup.org/onlinepubs/007908799/xcurses/terminfo.html 
and etc...


NuttX generally just hard codes VT-100 terminal types (or the 
almost-dentical ANSII terminal type).  But there are lots of others.  
Perhaps we should really be considering how we handle terminals in 
general not just color on or off?  That is really what the current 
discussion is about, terminal capabilities (termcaps) and 
customizations.  Maybe, as a start, we should consider a 
terminfo/termaps for monochrome vs. color only.  That would be a step in 
the Unix direction version yet-another-ad-hoc-config-setting.

Re: Color ANSI support in nsh

[Matias N.]

Having the ability to display color on the console is really useful to provide 
easy
to read output in many scenarios (e.g. test with OK/ERROR). 

But I agree it should be disabled by default and not overly complicate things.

I would suggest that you look at how this is handled in standard terminals. 
This works in the form
of escape sequence which give a code that the terminal can interpret as being a 
color. This would
make it available to applications in a standard form. 

As per coloring the prompt, bash uses special environment variables that allow 
you to redefine the
prompt and this way you can insert those escape sequences to color it.

Best,
Matias

Re: Color ANSI support in nsh

[Gregory Nutt]

This is my suggestion, it should be enabled by default, but disabled
by default if CONFIG_DEFAULT_SMALL is selected.

What do you think?

I would prefer to see it just disabled by default.

Re: Color ANSI support in nsh

[Alan Carvalho de Assis]

Hi Maciej,

I completely agree with it, I was only saying there is an alternative.

I also want native support to have Color support in the terminal.

This is my suggestion, it should be enabled by default, but disabled
by default if CONFIG_DEFAULT_SMALL is selected.

What do you think?

BR,

Alan

On 8/17/20, Maciej Wójcik  wrote:
> 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: Pre-check flow

[Ramya N]

Hi Brennan,

Can you please share your comments regarding the build time for container as 
shared in the previous mail.

Best Regards,
Ramya N

From: Ramya N 
Sent: 12 August 2020 20:37
To: dev@nuttx.apache.org 
Subject: Re: Pre-check flow


 **This is an external email. Please check the sender’s full email address (not 
just the sender name) and exercise caution before you respond or click any 
embedded link/attachment.**


Hi,

I am planning to add RX Toolchain for the Renesas architecture (for RX65N 
board) with reference to the build steps provided in the below URL,
https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc-renesas.com%2Fwiki%2Findex.php%3Ftitle%3DHow_to_build_the_RX_Toolchain_under_Ubuntu_14.04&data=02%7C01%7Cramya.n%40tataelxsi.co.in%7Cd246105d086140414f3108d83ed17604%7Cad6a39dd96b6436882daf2ec4d92e26a%7C0%7C0%7C637328416671279997&sdata=rrECtJf5DVRS0XIhA0fPiD2SdJbzvsGrbOkw73oYTRI%3D&reserved=0

I checked on the local build time for the container when RX Toolchain is added. 
Build time would be increased to 30 minutes (approx).

I'm new to the docker container setup in the github. Is there any reference 
available for publishing the intermediate container and using it when building?

Does "publish the intermediate container" mean pushing the Dockerfile (with RX 
toolchain) to incubator-nuttx-testing repo?

Best Regards,
Ramya N

From: Brennan Ashton 
Sent: 11 August 2020 10:29
To: dev@nuttx.apache.org 
Subject: Re: Pre-check flow


 **This is an external email. Please check the sender’s full email address (not 
just the sender name) and exercise caution before you respond or click any 
embedded link/attachment.**


On Mon, Aug 10, 2020, 9:42 PM Xiang Xiao  wrote:

>
>
> > -Original Message-
> > From: Ramya N 
> > Sent: Monday, August 10, 2020 10:42 PM
> > To: dev@nuttx.apache.org
> > Subject: Pre-check flow
> >
> > Hi,
> >
> > 1. In the NuttX Pre-check flow, docker image is built from "Pre-built
> Toolchain" of each architecture. If the pre-built toolchain
> is not
> > available, can we build the toolchain from "Toolchain Source Code" in
> the Dockerfile of incubator-nuttx-testing repo?
> >
>
> I think so, but Brennan can give more input.
>

We can although I would like more details on this. I don't want to give
people horrible build times for the container so it might make sense to
publish the intermediate container as well and use that when building.

Can you share what architecture and compiler you are wanting to add?

--Brennan

>

Disclaimer: This email and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed. If you are not the intended recipient of this message , or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply email and then delete this message and any attachments. If you are not 
the intended recipient, you are hereby notified that any use, dissemination, 
copying, or storage of this message or its attachments is strictly prohibited. 
Email transmission cannot be guaranteed to be secure or error-free, as 
information could be intercepted, corrupted, lost, destroyed, arrive late or 
incomplete, or contain viruses. The sender, therefore, does not accept 
liability for any errors, omissions or contaminations in the contents of this 
message which might have occurred as a result of email transmission. If 
verification is required, please request for a hard-copy version.

Re: Color ANSI support in nsh

[Maciej Wójcik]

There is a debug menu of NuttX configuration in which you can enable
different levels of logging. You could add an option to differentiate
colours based on debug level. I think this would be both great and doable.

Then if it would be accepted, expose colorful logs to applications somehow.
I wasn't using application level logging recently, just `printf|s. Don't
know how it works now, but it should also be doable.

On Mon, 17 Aug 2020, 13:34 Christian Catchpole, 
wrote:

> Thanks everyone.  There's obviously different levels of how far you take
> it. And not just colour, but simple things like "clear screen on NSH
> start", which I found useful for one use case at least.  Having commands
> colour aware as they are in linux is perhaps overkill at this stage. As a
> minimum I found coloring the prompt and then returning to regular print was
> a small but useful trick.
>
> As I'm new to NuttX and returning to serious C/systems development perhaps
> this is something I'll look into as a trial for getting to know Kconfig and
> the NuttX build system.
>
> Perhaps we could have a prompt color option in Kconfig which defaults to
> none.
> And clear screen on start which defaults to no.
>
> CC
>
> On Mon, 17 Aug 2020 at 21:24, Dave Marples  wrote:
>
> > Guys, chill, it was a joke :-) of course colour has utility for improved
> > cognition. Back in the day I remember discussions about if colour
> terminals
> > would ever take off cos folks couldn't see the point of them. That
> argument
> > got resolved.
> >
> > Colour certainly has utility. Small size does too. If we can accommodate
> > both (KConfig) then everyone is a winner.
> >
> > Dave
> >
> > On Mon, 17 Aug 2020, 07:50 Maciej Wójcik,  wrote:
> >
> > > 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, <
> david.sidr...@nscdg.com>
> > > > >> 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 case

Re: Color ANSI support in nsh

[Christian Catchpole]

Thanks everyone.  There's obviously different levels of how far you take
it. And not just colour, but simple things like "clear screen on NSH
start", which I found useful for one use case at least.  Having commands
colour aware as they are in linux is perhaps overkill at this stage. As a
minimum I found coloring the prompt and then returning to regular print was
a small but useful trick.

As I'm new to NuttX and returning to serious C/systems development perhaps
this is something I'll look into as a trial for getting to know Kconfig and
the NuttX build system.

Perhaps we could have a prompt color option in Kconfig which defaults to
none.
And clear screen on start which defaults to no.

CC

On Mon, 17 Aug 2020 at 21:24, Dave Marples  wrote:

> Guys, chill, it was a joke :-) of course colour has utility for improved
> cognition. Back in the day I remember discussions about if colour terminals
> would ever take off cos folks couldn't see the point of them. That argument
> got resolved.
>
> Colour certainly has utility. Small size does too. If we can accommodate
> both (KConfig) then everyone is a winner.
>
> Dave
>
> On Mon, 17 Aug 2020, 07:50 Maciej Wójcik,  wrote:
>
> > 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 b

Re: Color ANSI support in nsh

[Dave Marples]

Guys, chill, it was a joke :-) of course colour has utility for improved
cognition. Back in the day I remember discussions about if colour terminals
would ever take off cos folks couldn't see the point of them. That argument
got resolved.

Colour certainly has utility. Small size does too. If we can accommodate
both (KConfig) then everyone is a winner.

Dave

On Mon, 17 Aug 2020, 07:50 Maciej Wójcik,  wrote:

> 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
> > >> >
> > >>
> > >
> >
> >
>