Hello,
I have introduced nxcurl as a simplified curl for NuttX. It is a real
port, only the function names are different.
The interface is similar to the real curl.
It is not abandoned, the implemented features work.
IIRC it supports what is required for reimplementing webclient on top of
i
Let's restart the problem: it's definitely a bug that ctype macros evaluate
it's argument more than once. If the code size is more important than the
speed, let's change all macros to normal function that we get the correction
behavior and save the code size at the same time.
> -Original Me
Robert,
I dug into this a little more, and I am fairly confident that the PCI
subsystem will find your device since it properly traverses the
bridges and can identify multiple buses.
A couple things that are probably important to check, you are not
using the COM port on your motherboard for this t
Here is the size report for stm32f103-minimum:nsh:
The master:
textdata bss dec hex filename
43255 1082196 45559b1f7 nuttx
With lookup table patch(https://github.com/apache/incubator-nuttx/pull/1487):
textdata bss dec hex filename
43567 1
> The normal function size is smaller than macro version.
The comment and data seem to be in conflict.
master:43255 is less than 'normal function':43275
Am I missing something?
-Original Message-
From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com]
Sent: Friday, July 31, 2020 3:19 AM
To:
The x86_64
> I would also recommend working off of my branch. There is stuff in
> the current pci branch that will need to go away especially around MSI
> and MSI-X. If you are ok using the legacy interrupt for now it should
> be ok.
I agree.
That PCI feature branch I started is quite embarrass
Yes, you are right: function version is still 20Bytes bigger than macro
version. Do you have a better solution to fix this problem?
> -Original Message-
> From: David Sidrane
> Sent: Friday, July 31, 2020 6:29 PM
> To: dev@nuttx.apache.org
> Subject: RE: [GitHub] [incubator-nuttx] xiaoxi
Xiang,
First let me say thank you for digging in to this.
The test case can relay influence the data.
The table is a step function. One call +256, the others are subject to
compiler magic.
If we think along the lines of scalability, the table is fine on BIG un
constrained systems. The calls are
Hello,
I have two questions related PR#1478
(https://github.com/apache/incubator-nuttx/pull/1478):
1. I think there's a configuration error with "Build / macOS (sim)" since it is
using -Wempty-body, or is this intentional?
It gives errors for
for (namelen = 0; dirinfo->fd_lfname[namelen] != '\0
Yes, you are right: function version is still 20Bytes bigger than macro
version. Do you have a better solution to fix this problem?
Just to remind people that my original size concern was not with the
table approach. I think the size if about a wash. Applications that do
a lot of string man
2. Is there a way to flush a fat file system? Because I think the unexpected
behaviour I've seen was related to debugging and fat cache flush.
I tried to use fsync on the folder (which was proposed in a linux related
discussion), but open on a folder returns errno 21 (is a directory).
fsync o
My size concern is only in the PROTECTED build mode. In that
case, the ROM table would be duplicated: Once in user-space and once
in kernel space. That is the wasteful part because the OS does NOT do
any significant string processing and is a case where there would be
an unnecessary
> From: Gregory Nutt [mailto:spudan...@gmail.com]
> fsync on any open file descriptor will flush the file system since data
> is only buffered for for metadata and one file at a time.
This explains why my problem seems gone after I introduced a fsync on the file
in my test case.
I will have anoth
On Fri, Jul 31, 2020 at 9:46 AM Schock, Johannes - NIVUS GmbH <
johannes.sch...@nivus.com> wrote:
> Hello,
> I have two questions related PR#1478 (
> https://github.com/apache/incubator-nuttx/pull/1478):
>
> 1. I think there's a configuration error with "Build / macOS (sim)" since
> it is using -W
Hmmm... I don't agree.
The Coding Standard encourages empty "while loops":
https://cwiki.apache.org/confluence/display/NUTTX/Coding+Standard#while
Why should this not applicable for "for loops"? I think there are many already
in the tree.
And why is only "Build / macOS (sim)" complaining?
Johan
Macro version still evaluate the argument more than once regardless you name it
kisdigit or isdigit. I am fine with any following combination:
1.lookup table for both userspace and kernel
2.normal function for both userspace and kernel
3.lookup table for userspace and normal function for kernel
Bu
Hmmm... I don't agree.
The Coding Standard encourages empty "while loops":
https://cwiki.apache.org/confluence/display/NUTTX/Coding+Standard#while
Why should this not applicable for "for loops"? I think there are many already
in the tree.
Actually, I think that is an error in the coding docum
Dear Apache Leaders,
Does Apache have some streaming account (i.e. Zoom) that we could use
to N.O.W event?
What will be the tool used to "ApacheCon @Home 2020" streaming?
Could we use the same tool?
I asked this question in the private list, but didn't get response.
Anyway if Apache cannot sup
On 7/31/2020 8:44 AM, Xiang Xiao wrote:
Macro version still evaluate the argument more than once regardless you name it
kisdigit or isdigit. I am fine with any following combination:
1.lookup table for both userspace and kernel
2.normal function for both userspace and kernel
3.lookup table for u
Have you looked at the free jitsi open source platform?
When is your now event?
On Fri, Jul 31, 2020, 10:58 Alan Carvalho de Assis
wrote:
> Dear Apache Leaders,
>
> Does Apache have some streaming account (i.e. Zoom) that we could use
> to N.O.W event?
>
> What will be the tool used to "ApacheC
Hi Kevin,
Thank you for the suggestion, yes I considered jitsi as an option, but
it has users limit. It is limited to 75 users, but many reports said
it is hard when using with more than 35 people.
In theory we could support more users if we run it on our own server.
The event will happen Aug 15
Ok. I am open to using my zoom account if you need.
On Fri, Jul 31, 2020, 11:39 Alan Carvalho de Assis
wrote:
> Hi Kevin,
>
> Thank you for the suggestion, yes I considered jitsi as an option, but
> it has users limit. It is limited to 75 users, but many reports said
> it is hard when using with
Hi Kevin,
Than you very much! I really appreciate it!
I will contact you to get more info.
BR,
Alan
On 7/31/20, Kevin A. McGrail wrote:
> Ok. I am open to using my zoom account if you need.
>
> On Fri, Jul 31, 2020, 11:39 Alan Carvalho de Assis
> wrote:
>
>> Hi Kevin,
>>
>> Thank you for the
On Fri, Jul 31, 2020 at 10:55 AM Gregory Nutt wrote:
> > Hmmm... I don't agree.
> >
> > The Coding Standard encourages empty "while loops":
> > https://cwiki.apache.org/confluence/display/NUTTX/Coding+Standard#while
> > Why should this not applicable for "for loops"? I think there are many
> > al
My opinion: If a loop does not require a body, I suggest to use
braces, rather than a semicolon, because it is less prone to
programmer error. I would be okay with either:
while (condition)
{
}
or
while (condition) {}
And of the two, I think the second one expresses the intent best.
As a conclusion for me:
If you don't want to force braces, the macos/sim build test needs to be fixed.
Importantly: It's not a style test that is failing, it's a build test.
Nevertheless I will change the code in my PR to use braces, because it seems to
be the preferred way (at least by Greg and N
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 l
Before we change the coding standard, I suggest that we get more
feedback from the dev community.
My opinion: If a loop does not require a body, I suggest to use
braces, rather than a semicolon, because it is less prone to
programmer error. ...
I should not be so opposed to coding standard ch
On Fri, Jul 31, 2020 at 1:42 PM Gregory Nutt wrote:
>
> > Before we change the coding standard, I suggest that we get more
> > feedback from the dev community.
> >
> > My opinion: If a loop does not require a body, I suggest to use
> > braces, rather than a semicolon, because it is less prone to
29 matches
Mail list logo
