On Tue, Feb 4, 2025 at 5:32 PM Sebastien Lorquet wrote:
> Great news, now that the build errors are sorted out, we are greeted
> with the
> * * * r u n t i m e e r r o r s * * *
> the binary does not even start. it's stm32f429.
> tomorrow is jtag day.
> THIS IS FINE. I AM CALM. NO PROBLEM. I AM
Great news, now that the build errors are sorted out, we are greeted
with the
* * * r u n t i m e e r r o r s * * *
the binary does not even start. it's stm32f429.
tomorrow is jtag day.
THIS IS FINE. I AM CALM. NO PROBLEM. I AM HAPPY.
Sebastien
On 04/02/2025 11:59, Sebastien Lorquet wro
The mess will not stop by using more tools.
It will stop by taking hard decisions that will be resisted against, and
learning to say NO sometimes, instead of accepting everything to please
everyone.
I am not sure the nuttx project is ready for the required changes.
I have fixed the libboard
Yes Sebastien, its a mess, I can see it crystal clear now, code base
is not a pigsty for untested ideas, this needs to stop, thanks for
sounding the alarm!
I am just sad that Greg left because of that, I understand it now :-(
GitHub is not important for me, its a tool that we use for code
review,
I dont have a github account, this website looks like it is very
important for you. you keep mentioning it at every occasion.
linkage of nuttx and apps repo is a problem and I think more efforts
should be made to decouple it even more.
Otherwise you cant really tell anyone that they can have
> That is not excuse. Maintaining old API is not hard. Usually it's just a
simple
call to new API, which will not require further maintenence. You can even
kick
it to separate file so it does not break code aesthetics ;)
If it were that simple it wouldn't be a problem. But no, it isn't.
I just gi
On Fri, Jan 31, 2025 at 10:09 PM wrote:
>
> On 2025-01-31 21:14:23, raiden00pl wrote:
> > > No, just be super careful designing API to "userspace" and once commited
> > it
> > stays. Forever. Bad APIs will remain. Posix does not remove bad APIs as
> > well.
> > That's why we still have "creat" ins
On 2025-01-31 21:14:23, raiden00pl wrote:
> > No, just be super careful designing API to "userspace" and once commited
> it
> stays. Forever. Bad APIs will remain. Posix does not remove bad APIs as
> well.
> That's why we still have "creat" instead of "create". Or we have 3 poll
> APIs in
> Linux (
On Fri, Jan 31, 2025 at 3:15 PM raiden00pl wrote:
> > No, just be super careful designing API to "userspace" and once commited
> it
> stays. Forever. Bad APIs will remain. Posix does not remove bad APIs as
> well.
> That's why we still have "creat" instead of "create". Or we have 3 poll
> APIs in
> No, just be super careful designing API to "userspace" and once commited
it
stays. Forever. Bad APIs will remain. Posix does not remove bad APIs as
well.
That's why we still have "creat" instead of "create". Or we have 3 poll
APIs in
Linux (select/poll/epoll). You really want to change API, you b
On Fri, Jan 31, 2025 at 6:01 PM Sebastien Lorquet wrote:
> hello
> you are right, let's try:
> 12.8.0 -> configure broken
> 12.7.0 -> configure works
>
> apps is copied from master.
>
> CC: nsh_alias.c
> In file included from nsh_alias.c:39:
> nsh_console.h:191:18:error: 'LINE_MAX' undeclared her
On Fri, Jan 31, 2025 at 5:48 PM Sebastien Lorquet wrote:
> The interface between the two should be loose:
>
> -the build system, to get the code -> can be forced to be simple and
> fixed. call make -C $(APPS) app_code and nothing else.
> -the libc
>
> Apart from that I see no need to have a shared
On Fri, Jan 31, 2025 at 5:30 PM Sebastien Lorquet wrote:
> hello
> My proposal is:
> 1) define how the app build system is invoked and never move that
./tools/configure.sh ...
(g)make
That does not change :-)
Alternatively you can use CMake.
> 2) define that nuttx expects apps in a particular
I agree, here is an example change I had to do:
int itf_bring_up(int sd, struct ifreq *pifr)
{
int ret;
- pifr->ifr_flags = IFF_UP;
+ IFF_SET_UP(pifr->ifr_flags);
ret = ioctl(sd, SIOCSIFFLAGS, (unsigned long)pifr);
if (ret < 0)
{
@@ -263,7 +263,7 @@int itf_bring_up(
hello
you are right, let's try:
12.8.0 -> configure broken
12.7.0 -> configure works
apps is copied from master.
CC: nsh_alias.c
In file included from nsh_alias.c:39:
nsh_console.h:191:18:error: 'LINE_MAX' undeclared here (not in a
function); did you mean 'LINK_MAX'?
191 | char cn_lin
On 2025-01-31 17:34:48, raiden00pl wrote:
> How do you want to maintain compatibility between nuttx-apps and
> nuttx while both are active development projects, and what's more
> one of them is optional? It's not possible.
Same way as app/kernel compatibility is maintained in othes Unices like Linu
The interface between the two should be loose:
-the build system, to get the code -> can be forced to be simple and
fixed. call make -C $(APPS) app_code and nothing else.
-the libc
Apart from that I see no need to have a shared api.
What am I missing?
Sebastien
On 31/01/2025 17:34, raiden
On 2025-01-31 16:20:51, Tomek CEDRO wrote:
> On Fri, Jan 31, 2025 at 3:35 PM wrote:
> > On 2025-01-31 13:48:32, Tomek CEDRO wrote:
> > > On Fri, Jan 31, 2025 at 1:41 PM Sebastien Lorquet
> > > wrote:
> > > > Of course I also tried with the commit before that one, and it didnt
> > > > work either
How do you want to maintain compatibility between nuttx-apps and
nuttx while both are active development projects, and what's more
one of them is optional? It's not possible.
It would be possible if we assumed that the API in NuttX is perfect
and will not require changes, which is not true. There
hello
My proposal is:
1) define how the app build system is invoked and never move that
2) define that nuttx expects apps in a particular file at a particular
place and never move that.
Also, enfore the use of the posix api everywhere. that should be enough...
the app/os limit is probably i
On Fri, Jan 31, 2025 at 7:50 AM Tomek CEDRO wrote:
> On Fri, Jan 31, 2025 at 1:41 PM Sebastien Lorquet
> wrote:
> > Of course I also tried with the commit before that one, and it didnt
> > work either.
>
> Sebastien, did you try the release packages? Does the problem occur in
> the release packa
On Fri, Jan 31, 2025 at 3:35 PM wrote:
> On 2025-01-31 13:48:32, Tomek CEDRO wrote:
> > On Fri, Jan 31, 2025 at 1:41 PM Sebastien Lorquet
> > wrote:
> > > Of course I also tried with the commit before that one, and it didnt
> > > work either.
> >
> > Sebastien, did you try the release packages?
On 2025-01-31 13:48:32, Tomek CEDRO wrote:
> On Fri, Jan 31, 2025 at 1:41 PM Sebastien Lorquet
> wrote:
> > Of course I also tried with the commit before that one, and it didnt
> > work either.
>
> Sebastien, did you try the release packages? Does the problem occur in
> the release packages?
>
On Fri, Jan 31, 2025 at 1:41 PM Sebastien Lorquet wrote:
> Of course I also tried with the commit before that one, and it didnt
> work either.
Sebastien, did you try the release packages? Does the problem occur in
the release packages?
Upstream master is for development purposes, things may get
On 31/01/2025 13:16, Tomek CEDRO wrote:
On Fri, Jan 31, 2025 at 10:30 AM Sebastien Lorquet wrote:
Many problems arise when the nuttx and nuttx-apps are not in sync.
I always keep its masters in sync.. if there is no info on the website
we need to update documentation :-)
This is not possib
On Fri, Jan 31, 2025 at 10:30 AM Sebastien Lorquet wrote:
> Many problems arise when the nuttx and nuttx-apps are not in sync.
I always keep its masters in sync.. if there is no info on the website
we need to update documentation :-)
And I guess for the user its best to use release packages of n
Hi Sebastien,
The application repository should be independent from the main nuttx
> repo, right? and should continue to work even if nuttx is updated,
> right? Thats a reasonable expectation, right? but this is clearly not
> the case.
>
> This is a clear breakage of the os/app interface.
Yes, w
Application.mk was not up to date. hah.
The application repository should be independent from the main nuttx
repo, right? and should continue to work even if nuttx is updated,
right? Thats a reasonable expectation, right? but this is clearly not
the case.
This is a clear breakage of the os/a
Can you believe it?
After fixing all these apps so they talk with this OS, THE APPS BUILD
SYSTEM IS BROKEN
IN: /home/slo/Sources/product-env/product/apps/libapps.a ->
staging/libapps.a
install -m 0644 /home/slo/Sources/product-env/product/apps/libapps.a
staging/libapps.a
install: impossible
No rant here just facts, of the kind that makes my head explode.
Many problems arise when the nuttx and nuttx-apps are not in sync.
This should not happen, because nuttx sort-of promises an os/app
separation, and I dont think it is actually enforced.
I'm not talking about internal interfaces
30 matches
Mail list logo
