On Wed, 8 Mar 2023 at 13:16, Alan C. Assis wrote:
>
>
> Welcome back go NuttX Lwazi (I'm not been sarcastic, I'm happy to hear
> from you again! You have a great knowledge of BLE can we need! I was
> expecting you to share that working example of BLE application using
> our BLE stack).
>
Thanks,
Hi Jernej,
The ESP-Hosted is in our plans, but it is not priority now.
As you remember in the last NuttX Workshop we had a presentation from
Wilderness Labs about Meadow and they have an ESP32 as co-processor
that has a USRSOCK communication to allow host MCU to use ESP32 WiFi
and Bluetooth.
I
I was wrong. My app was mishandling console input :(
>-Original Message-
>From: Tim Hardisty
>Sent: 09 March 2023 15:34
>To: dev@nuttx.apache.org
>Subject: RE: Help me understand file open/close behaviours?
>
>Guess what - this behaviour is only on Master. Spent an hour or 2 getting
>the
Guess what - this behaviour is only on Master. Spent an hour or 2 getting the
test app and new driver to work under 12.0 release and I can ctrl-C out of my
test app without problem and re-run it without an apocalyptic crash.
I will now raise it as an issue on GitHub.
>-Original
If CONFIG_SERIAL_TERMIOS is not selected then non-consoles will do
nothing. In order to restore legacy behavior you would have to do this:
+#ifdef CONFIG_SERIAL_TERMIOS
if (
-#ifdef CONFIG_SERIAL_TERMIOS
dev->tc_iflag & ECHO
-#else - dev->isconsole
First of all, people never respect pull request formats if this is not
enforced. So enforcement is required as well.
No member of the PMC has authority over any other. An Apache project is
ultra democratic bordering on anarchistic. Each member is basically a
"sovereign citizen."
So we
Yes on this. Distribution provided bare metal arm toolchains have always
been a disappointment for me.
Sebastien
Le 09/03/2023 à 12:03, Petro Karashchenko a écrit :
I think the best way is to install GCC from the ARM website and not using
OS package manager.
On the libm: some time ago I tried to install the RISCV toolchain on Ubuntu
with apt and the installed toolchain was built without libm :)
In other words, running compiler + arch flags with "--print-file-name=libm.a"
option gave me an empty output (also "find gcc_folder -name libm.a" gave me
an
sorry wrong calculation, I meant 7 days * 0.5 hour * 50% * 4 weeks = 7
hours per month.
Still a lot, which could be saved by a few minutes of your company time
per week for specific PRs. Cause not all them need careful review.
Sebastien
Le 09/03/2023 à 11:49, Sebastien Lorquet a écrit :
I
I understand that, but also, you should not force your high-speed
development pace on other developers :)
Because it also consumes a huge resource to review your requests :-)
You asked me to spend half an hour a day on PR review, but you send 50%
of all PRs, so this amounts to (7*0.5)*4 = 14
Thanks for the responses
This feature already exist
> https://github.com/apache/nuttx-apps/blob/master/nshlib/Kconfig#L126-L146
>
As far as I can understand, that is for backquotes `foo` which is a type of
variable expansion. What I need is support for single quotes 'foo' which
means that
Hi,
If I am not mistaken, the existing NSH_CMDPARMS feature will just
execute the command once and copy the stdout into the var?
Aliases are more like virtual commands, that execute their contents when
run.
This is distinct from built-in commands and user implemented programs.
Sebastien
If so, most likely xiaomi will fork nuttx like Samuang and make our own
change. We don't want to spend the time to prepare the patch but no
feedback guarantee, since it consumes a huge resource to prepare the patch.
On Thu, Mar 9, 2023 at 6:15 PM Sebastien Lorquet
wrote:
> Hi,
>
> This sounds
On Thu, Mar 9, 2023 at 6:14 PM Ville Juven wrote:
> Hi all,
>
> I'm in the process of writing support for shell aliases into NSH, but since
> the shell is the front end for NuttX I decided to make a post here for
> opinions on this matter and to open discussion for requirements, mostly to
>
Hello,
I think you did things very,very well, thank you for this.
Here is some feedback:
1 - aliases are not required for me, but It could still be a worthwile
feature for others, and it's a requirement for you.
2 - this feels ok for me, since this is generally a better behaviour of
the
Hi,
This sounds like a corporate rule, does it? Not being critical here,
this is just to understand.
There should be no clear limit for a shared project, we just need time
to take the best decisions.
I feel that you cant force progress if there are no resources to do it.
Remember, most
Hi all,
I'm in the process of writing support for shell aliases into NSH, but since
the shell is the front end for NuttX I decided to make a post here for
opinions on this matter and to open discussion for requirements, mostly to
prevent unexpected regression issues that might arise from this.
Hi all,
thanks for answering.
I'm still in build-phase. No runtime hard-fault. I'm using my fork on
github https://github.com/SimonFilgis/incubator-nuttx
Mr. Xiao nailed it. It choose to use the NuttX internal libm for the moment.
But still something seems to miss, please have a look at the
Yes, this is how I do normally, but we need the rule to ensure the PR gets
progress. e.g. the reviewer needs to give the feedback in one week, one
month or one year.
The reviewer has the rights to approve the change and also has duties to
make progress.
On Thu, Mar 9, 2023 at 5:14 PM
First of all, people never respect pull request formats if this is not
enforced. So enforcement is required as well.
But this is not sufficient by itself, since a programmer's initial
impression of a change can be widely and underestimated.
Often times you *really need* that pull request
Hi,
has someone make an effort to bring ESP- Hosted to NuttX OS. ESP-Hosted
supports Linux integration and RTOS integration. One could use the RTOS way
to bring ESP-Hosted up, but on the other hand NuttX is more like Linux.
What do you think?
Regards,
Jernej
> - All breaking commits should be discusses on dev so that people get
enough time to digest the change and even better get involved int the flow
I think "all breaking commits" is too broad and impractical.
What about code guarded with CONFIG_EXPERIMENTAL? What about the features
just added or
Notify the list!
Simple as that.
If there is no progress, it means this is a complex PR that needs attention.
Just adding reviewers keep the issue github-centric.
Sebastien
Le 09/03/2023 à 10:11, Xiang Xiao a écrit :
If some PR waits for a long time without any review, how to make progress?
+1 100% from me, too.
Sebastien
Le 09/03/2023 à 10:18, David Sidrane a écrit :
+1 100%
I think that the PR should have a summary as well to ensure it is all tied
together. Unless we enable rebase/squash the information will be disjoint.
David
-Original Message-
From:
+1 100%
I think that the PR should have a summary as well to ensure it is all tied
together. Unless we enable rebase/squash the information will be disjoint.
David
-Original Message-
From: alin.jerpe...@sony.com
Sent: Thursday, March 9, 2023 4:13 AM
To: dev@nuttx.apache.org
Cc:
Hi Xiang,
Simply add some reviewers on the right side and they will be notified that
someone asks them to step up
Best regards
Alin
-Original Message-
From: Xiang Xiao
Sent: den 9 mars 2023 10:12
To: dev@nuttx.apache.org
Subject: Re: DISCUSSION - Usage of mailing lists for apache
Hi all,
I agree with David but in my opinion this information should go in the commit
message and no commit without message should be merged.
Not all people will check the PR message but you will always see the reasons
simply by typing "git log" if they are in the commit message
What do you
If some PR waits for a long time without any review, how to make progress?
For example, this PR sent two weaks ago:
https://github.com/apache/nuttx/pull/8610
On Thu, Mar 9, 2023 at 4:40 PM alin.jerpe...@sony.com <
alin.jerpe...@sony.com> wrote:
> Hi all,
>
> I feel that this thread is getting
I would add that all pull request must have a statement explaining the
reason or motivation for the change(s).
Just stating the "What" was done is not enough. There must be a "Why" the
change is needed.
David
-Original Message-
From: alin.jerpe...@sony.com
Sent: Thursday, March 9, 2023
Hi,
Sounds like a good summary, and also a good improvement if implemented
as described here and actually enforced.
May I suggest just a bit more documentation than just official release
notes? For example, warnings in commit messages, so we get no nasty
surprise after an innocent git pull?
Hi all,
I feel that this thread is getting too long without a real outcome
Some observations from my daily interactions with the project:
- I like doing reviews on github and I think that many people in this thread
would agree that this flow is good.
- I like to be able to see all bugs in
31 matches
Mail list logo
