RE: official nuttx-ci-linux image

Love it! -Original Message- From: Takashi Yamamoto [mailto:yamam...@midokura.com.INVALID] Sent: Thursday, August 06, 2020 4:03 AM To: dev@nuttx.apache.org Subject: official nuttx-ci-linux image hi, the docker image used by the CI (nuttx-ci-linux) is useful for other purposes. but as far

RE: stm32f7 CONFIG_RAM understanding

) and sometimes fails advertising uorb topics (also heap allocation problem as I see). While I'm investigating this I notice this difference with RAM size config and ask this question (of course it may not be related to my issue). вт, 4 авг. 2020 г. в 22:49, David Sidrane : Both are not used

RE: stm32f7 CONFIG_RAM understanding

Both are not used in the source. I would assume it is a legacy C from the F4, that should be removed. *From:* Oleg Evseev [mailto:ev.m...@gmail.com] *Sent:* Tuesday, August 04, 2020 12:45 PM *To:* dev@nuttx.apache.org *Subject:* Re: stm32f7 CONFIG_RAM understanding No, internal memory.

RE: [GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1487: libc: Avoid ctype function to evaluate the argument more than once

the argument more than once 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 > Subje

RE: [GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1487: libc: Avoid ctype function to evaluate the argument more than once

ode 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 Message- > > From: David Sidrane > > Sent: Friday, July 31, 2020 7:32 AM &g

RE: [GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1487: libc: Avoid ctype function to evaluate the argument more than once

-1 on more bloat It is a simple matter to see the cost of a PR if we add bloaty (https://github.com/google/bloaty) to ci. -Original Message- From: Gregory Nutt [mailto:spudan...@gmail.com] Sent: Thursday, July 30, 2020 12:25 PM To: dev@nuttx.apache.org Subject: Re: [GitHub]

RE: [GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1487: libc: Avoid ctype function to evaluate the argument more than once

But how long does it take you, when the linker tell you, you have over flowed .text by 256 bytes? -Original Message- From: GitBox [mailto:g...@apache.org] Sent: Thursday, July 30, 2020 12:13 PM To: comm...@nuttx.apache.org Subject: [GitHub] [incubator-nuttx] xiaoxiang781216 commented on a

RE: Can we implement ctype functions through table?

; -Original Message- > From: David Sidrane > Sent: Tuesday, July 28, 2020 8:23 PM > To: dev@nuttx.apache.org > Subject: RE: Can we implement ctype functions through table? > > Xiang, > > If there is a small usage do you think flash will grow by 256 bytes? I > would

RE: Can we implement ctype functions through table?

Xiang, If there is a small usage do you think flash will grow by 256 bytes? I would be surprised. Should you uses a config option? David -Original Message- From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com] Sent: Monday, July 27, 2020 10:40 PM To: dev@nuttx.apache.org Subject: RE:

The PX4 Developer Summit - This week

The PX4 Developer Summit - This week Hi All! In case anyone wants' to tune in…. The PX4 Developer Summit is the annual flagship conference hosted by Dronecode for the drone development community. Here is the schedule: *https://bit.ly/2YXe4Rd*

RE: SVD -> header generator

Hi Matias, > I thought about doing this for a long time Yes So many times...Thank you for doing it! David -Original Message- From: Matias N. [mailto:mat...@imap.cc] Sent: Friday, July 03, 2020 1:45 PM To: dev@nuttx.apache.org Subject: SVD -> header generator Hi, I thought about doing

RE: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release

I am not sure if this was in the last release, but there is a secondary level change to date that the CONFIG_TIME_EXTENDED was removed and made permanently enabled. Things like CONFIG_TIME_EXTENDED were there to scale down for resource constrained configurations. I for one would like to preserve

RE: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release

This is a cool tool. https://github.com/google/bloaty Here is a set of ways to use it. https://github.com/PX4/Firmware/blob/4e7dedede79872401f50c733bd74e5ddf1fa41f1/cmake/bloaty.cmake (please ignore the cmake...) This is the one that can be used to see the deltas, in our case from mater to the

RE: MCU only booting from reset via SWD when compiled without optimizations?

Hi Matias, >> > > Yes, I do recall some issue with the F429's in this regard. There was >> > > an errata. I believe that there are some pins in the upper 256Kb bank >> > > that interfered with some other peripheral. DavidS would know better >> > > than I. I thought it effected USB? The FLASH/USB

RE: NXView

Why not use the ETM? -Original Message- From: Gregory Nutt [mailto:spudan...@gmail.com] Sent: Friday, June 12, 2020 5:03 PM To: dev@nuttx.apache.org Subject: NXView Hi, List, I have been contemplating a NuttX-based Open Source project today and I am interested in seeing if anyone is

RE: New Wiki Page

This is super helpful! Thank you Greg! -Original Message- From: Gregory Nutt [mailto:spudan...@gmail.com] Sent: Thursday, June 11, 2020 7:07 AM To: dev@nuttx.apache.org Subject: New Wiki Page Why Can't Kernel Threads Have pthreads?

RE: Release 9.1

I was speaking of git tag, for convenience. I guess the other question I want to know is what is on master that is not in the release? If we use git tags: One is dropped on the branch point. One is dropped on the release point. The delta on master is the full set of commits that came in to

RE: Release 9.1

Would tags do the same thing? How does this work over time? Many PRs or keep force pushing to the PR? How about use cherry-pick -e and add the prefix [BACKPORT] on the back ported commits. -Original Message- From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com] Sent: Monday,

RE: [DISCUSS] requirements for commit messages and PRs

I think there are may more aspect than just the release notes. Yes we can ask every time for information but that is not a good use of everyone's time. Let the template ask for it. At the time the PR comes in, the submitter is the "expert in the problem domain". Not the committer. The

RE: [DISCUSS] requirements for commit messages and PRs

No make up one, with instruction. Let get the best of all the input. But I think it would help to stop call then by judgmental names. Unless of course the final one will be god-wonderful :) -Original Message- From: Gregory Nutt [mailto:spudan...@gmail.com] Sent: Thursday, June 04, 2020

RE: [DISCUSS] requirements for commit messages and PRs

I agree there are 2 extremes: No information and Too much information. No information leads to hundreds of emails a day with no value. To much information requires focus to triage. The question I want to know the answer to is: Do I care about this change, now or in the future? Personally I think

[DISCUSS] requirements for commit messages and PRs

Let's discuss what is needed in commit messages PRs 1) Effective team communication 2) Have a problem statement 3) Provide reasoning for solution and alternatives 4) Provide test instructions steps for reproduction 5) Provides content usable in release notes. Here is a straw man with some

RE: Organising Release Notes for 9.1

Hartman [mailto:hartman.nat...@gmail.com] Sent: Thursday, June 04, 2020 6:23 AM To: dev@nuttx.apache.org Subject: Re: Organising Release Notes for 9.1 On Thu, Jun 4, 2020 at 7:58 AM David Sidrane wrote: > I think _Every PR_ needs a description do begin to be a responsible and > profes

RE: Organising Release Notes for 9.1

Nice! I think _Every PR_ needs a description do begin to be a responsible and professional contribution. The small extra level of effort will keep the team informed and provide the documentation for the release process. We should not have to reverse engineer intent to get the one line "what" and

RE: NuttX config browser

Hi Maciej, Could you have an option to upload a defconfig to see the settings based on it? David -Original Message- From: Maciej Wójcik [mailto:w8j...@gmail.com] Sent: Sunday, May 31, 2020 8:23 PM To: dev@nuttx.apache.org Subject: Re: NuttX config browser Hello Alan, A suggestion:

RE: [OT] Linux now using 100 char lines as default

Let's one up them and keep it binary at the same time 128! :) -Original Message- From: Alan Carvalho de Assis [mailto:acas...@gmail.com] Sent: Monday, June 01, 2020 4:22 AM To: dev Subject: [OT] Linux now using 100 char lines as default Interesting:

RE: SPI slave interface discussion

Hi Jukka, Would you mind opening a Draft PR for this disscussion. (See the Drop down on github [Create pull request] ) David *From:* Laitinen, Jukka [mailto:jukka.laiti...@intel.com] *Sent:* Thursday, May 21, 2020 11:23 PM *To:* dev@nuttx.apache.org *Subject:* RE: SPI slave

RE: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED not set

This is super confusing to me. The todo list says. Status: Open Priority:Low. Things are working OK the way they are. But the design could be improved and made a little more efficient with this change. So it sounds like no

RE: Jenkins build is back to normal : NuttX-Nightly-Build #159

Thank you Haitao Liu, Takashi Yamamoto and Masayuki Ishikawa for this! -Original Message- From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com] Sent: Wednesday, May 20, 2020 6:17 AM To: dev@nuttx.apache.org Subject: Re: Jenkins build is back to normal : NuttX-Nightly-Build #159 Hi all, We

RE: nxstyle warnings: Fail precheck?

The rule use to be: long lines were ok in arch header files. When I made nxstyle output error parsable output, that was a warning not an error. Then we got to make it fit below the ruler. Then we got to it better conform. So now I guess they are all errors. David -Original Message-

RE: Adding support for STM32G474RET6

3 or 4 volunteers who can perform the review: David Sidrane? Mateusz Szafoni? Matias N.? Alan? Others? My personal preference would be stand out of the way and let a team of experts do the review and merge. I get overwhelmed with large changes that I don't understand and usually just commit them b

RE: [NOMINATION] Self nominate to be a mentor of Apache NuttX

Hi Dou, Welcome! Thank you for offering to help! David -Original Message- From: Duo Zhang [mailto:zhang...@apache.org] Sent: Monday, May 11, 2020 6:11 PM To: dev@nuttx.apache.org Cc: gene...@incubator.apache.org; 俊平堵 Subject: [NOMINATION] Self nominate to be a mentor of Apache NuttX

RE: Direct commits to repository

Way back when, I added a no_push to prevent any direct pushing. This may help others. git remote set-url --push origin no_push *From:* Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com] *Sent:* Monday, April 27, 2020 10:26 PM *To:* dev@nuttx.apache.org *Subject:* Re: Direct

RE: The new Apache NuttX Logo

+1 -Original Message- From: David Alessio [mailto:david.s.ales...@gmail.com] Sent: Saturday, April 18, 2020 1:30 PM To: dev@nuttx.apache.org Cc: palomino...@gmail.com; 李骁; nand...@xiaomi.com; Hans Subject: Re: The new Apache NuttX Logo I feel strongly about this. "NuttX" preserves the

RE: Adding support for STM32G474RET6

How about in the commit hooks? -Original Message- From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com] Sent: Thursday, April 16, 2020 7:47 PM To: dev@nuttx.apache.org Subject: Re: Adding support for STM32G474RET6 On Fri, Apr 17, 2020 at 5:54 AM David Sidrane wrote: > > Tha

RE: Adding support for STM32G474RET6

To: dev@nuttx.apache.org Subject: Re: Adding support for STM32G474RET6 On Thu, Apr 16, 2020 at 1:00 PM David Sidrane wrote: > If you look at the Kinetis, > https://github.com/apache/incubator-nuttx/blob/master/arch/arm/include/kinetis/kinetis_pmc.h#L50-L63 > > You can see the gist of t

RE: Adding support for STM32G474RET6

Nathan, If you look at the Kinetis, https://github.com/apache/incubator-nuttx/blob/master/arch/arm/include/kinetis/kinetis_pmc.h#L50-L63 You can see the gist of that approach. It idea was as developers on the outside of the MFG, we only see the deltas in datasheets. We do not know, the feature

Re: Adding support for STM32G474RET6

How does the RCC (clock tree) compare? On Wed, Apr 15, 2020, 5:11 PM Nathan Hartman wrote: > On Wed, Apr 15, 2020 at 4:08 PM Gregory Nutt wrote: > > This document address migration from F1 to F3 and addresses all major > > differences between F1 and F3: AN4228, Application note, Migrating

RE: Adding support for STM32G474RET6

Hi Nathan, I have not looked at the G part yet so I cannot say for certain, but I can share this: We learned many lessons from the coupling in the stm32 dirs. The take away was Avoid it! The F7 model is much better - the goal is to not have ifdef rash. Layered includes bring it the correct

RE: STM32H7 support

Hi John, >Is there a working document or set of notes detailing ongoing/needed work for STM32H7 support? Not really - a diff to the F7 file usually will show the holes but there is also the datasheet diff view. We used SDMMC2 in all H7 designs and that choice gave us the ability to bring out

RE: Fail checks no new warnings?

Hi Greg, I was able to do this once before: #if !defined(TODO) # if !defined(NO_PRINT_TODOS) # define DO_PRAGMA(x) _Pragma (#x) # define TODO(x) DO_PRAGMA(message ("TODO - " #x)) # else # define TODO(x) # endif #endif IIRC it allowed me to print compiler output that was not treated as

RE: Build errors with inline functions

> the error will crop back up if MPU support is enabled without also > performing a protected build since up_mpu.c is only included in a > protected build. Just a heads up there are some case on some HW (imxrt, maybe the K66 for the DMA) were the MPU is needed to enable the proper access but not

RE: PR and issue Templates

uest, etc. On Fri, Mar 20, 2020 at 12:48 PM David Sidrane wrote: > Hi, > > > > We spend a lot of time on PRs repeating ourselves on format, license. > > > > Giving directed links and examples will not challenge contributors with > having to ferret this out on their own.

PR and issue Templates

:* Abdelatif Guettouche [mailto:notificati...@github.com] *Sent:* Friday, March 20, 2020 4:42 AM *To:* apache/incubator-nuttx *Cc:* David Sidrane; Mention *Subject:* Re: [apache/incubator-nuttx] Support for Litex VexRiscV (#595) @aenrbs New files need to have an Apache license. Kconfig, README and auto

RE: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

Hi Adam, See inline… *From:* Adam Feuer [mailto:a...@starcat.io] *Sent:* Tuesday, March 17, 2020 12:10 PM *To:* David Sidrane *Cc:* dev@nuttx.apache.org *Subject:* Re: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?] David, Yes, I agree that it would

RE: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

uch greater. David *From:* Adam Feuer [mailto:a...@starcat.io] *Sent:* Monday, March 16, 2020 3:35 PM *To:* David Sidrane; dev@nuttx.apache.org *Subject:* Re: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?] Here's a Github compare with .clang-format f

RE: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

T_REQUIRE_VERSION TabWidth:8 UseTab: Never ... On Sat, Mar 14, 2020 at 1:29 AM David Sidrane wrote: Hi Adam and Maciej, Thank you for spending you time on this. It will be a huge win for everyone! The way I have been looking at this is like in transfer-function with an offse

RE: Should we relax precheck a little bit?

Yeah I thought about the too But think of the can of worm on the commit history: Every PR touches the cfg file. Rebase HELL! Yuch! Fix or replace the tool! -Original Message- From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com] Sent: Sunday, March 15, 2020 6:08 AM To:

RE: Question of PR Etiquette

Helping someone is not a bad thing. Consider the effect on the community and the code. What use to happen with patches: patches were emailed, ***modified*** and committed. Submitted != Committed - Was that BAD Etiquette? What use to happen with a PR: PR were submitted, 1-N more commits were

Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

hat. Maybe a post-processing script that only looked at > > these macros would work. Or a contribution to clang-format. I'll think > > about it some more. > > > > -adam > > > > On Sun, Mar 8, 2020 at 3:40 AM David Sidrane > > wrote: > > > > >

RE: Should we relax precheck a little bit?

On Wed, Mar 11, 2020 at 8:13 AM David Sidrane > wrote: > > > First, I have to say that I value the NuttX coding standard - it make > > for > > the most readable code I have EVERY worked on. I want it preserved. > > > > But in light of the below discussion: I am c

RE: Should we relax precheck a little bit?

First, I have to say that I value the NuttX coding standard - it make for the most readable code I have EVERY worked on. I want it preserved. But in light of the below discussion: I am changing my position that the "rule" CI is to just check ONLY the changes to a file AND if the only CI failure

RE: Github Issue on Build Failure

> It looks like there is a Jenkins plugin that allows the Github issue to be created relatively easily. I'd be happy to try and get this working if everyone agrees. +1 -Original Message- From: Anthony Merlino [mailto:anth...@vergeaero.com] Sent: Tuesday, March 10, 2020 9:57 AM To:

RE: Should we relax precheck a little bit?

I agree with Alin. -1 -Original Message- From: Alin Jerpelea [mailto:jerpe...@gmail.com] Sent: Monday, March 09, 2020 5:36 AM To: dev@nuttx.apache.org Subject: Re: Should we relax precheck a little bit? -1 I thin that as a long term goal we should aim to have it enabled and leave each

FW: Should we relax precheck a little bit?

ack to Clang. I'll try your idea about combining all the files under sched into a set. When you said you got 95% of the way there, do you have a .clang-format file that I could use as a starting point? If so that would help me start where you left off. cheers adam On Sun, Mar 8, 2020 at 3:40 AM Da

RE: Should we relax precheck a little bit?

Hi Adam, Have a look at https://github.com/mikr/whatstyle I got furthest with clang-format and it. It may be we get a 95% of the way there with it and we can add a backend secondary scripts. I was unable to convince Greg to create a master template so my approach was to combine all the files

Re: Should we relax precheck a little bit?

that works and can format the codebase. But we are where we are. So why don't you call a vote? On 2020/03/08 04:13:11, Xiang Xiao wrote: > On Sun, Mar 8, 2020 at 2:46 AM David Sidrane wrote: > > > > -1 It is Not inline with long term goal and a violation of the Inviolable > >

RE: Should we relax precheck a little bit?

-1 It is Not inline with long term goal and a violation of the Inviolable o Expediency is not a justification for violating the coding standard. -Original Message- From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com] Sent: Saturday, March 07, 2020 10:11 AM To: dev@nuttx.apache.org

irony

irony *https://github.com/apache/incubator-nuttx/runs/491066405#step:5:11*

RE: squashing commits or not

not the accepted workflow > at present. Yes, but eventually, that's the workflow we are going to call a vote on. All committers can edit and improve it. Non committers can ask to have the necessary permissions. On Thu, Mar 5, 2020 at 5:55 PM David Sidrane wrote: > > Abdelatif, > > Thank

RE: stm32h7 support for SDRAM via FMC

Andrew, My apologies! Bitbucket is a legacy mirror. Greg can you put a Notice on the site to avoid this sort of thing. Please submit a PR on Github https://github.com/apache/incubator-nuttx https://github.com/apache/incubator-nuttx-apps David -Original Message- From: Заболотный

RE: squashing commits or not

t 5:37 PM David Sidrane wrote: > > I think you are over-reading this. If we do not have a clear list of > instructions we are not helping, we are confusing our would be committers > (Additional Committers email). If you do not think of them as Rules but > more > of sharing your &q

RE: squashing commits or not

Why would you merge it to branch it is not ready? This is not hard. The PR will not pass CI if it fails Style check. Period! That is a simple check. We should have that by now. Also add it to the commit hooks locally. (document the work flow and add the script to download it - or put it in the

RE: squashing commits or not

I think you are over-reading this. If we do not have a clear list of instructions we are not helping, we are confusing our would be committers (Additional Committers email). If you do not think of them as Rules but more of sharing your "best engineering judgment" to educate the group, you know,

RE: squashing commits or not

If you have clear work steps for a rebase work flow (prior to review). Contributors can and will do PR hygiene. -Original Message- From: Gregory Nutt [mailto:spudan...@gmail.com] Sent: Thursday, March 05, 2020 9:20 AM To: dev@nuttx.apache.org Subject: Re: squashing commits or not > If

RE: squashing commits or not

How about clear to the point work steps? Do we have the interim workflow listed anywhere that it can be read, without the diatribes? -Original Message- From: Gregory Nutt [mailto:spudan...@gmail.com] Sent: Thursday, March 05, 2020 8:00 AM To: dev@nuttx.apache.org Subject: Re: squashing

RE: squashing commits or not

Isn't that is just more noise? -Original Message- From: Miguel Ángel Herranz [mailto:mig...@midokura.com.INVALID] Sent: Thursday, March 05, 2020 8:16 AM To: dev@nuttx.apache.org Subject: Re: squashing commits or not Why not just leave all the commits and generate on master a single merge

RE: squashing commits or not

Agree! If you read the work flow I suggested you will see it is a rebase until review WF. Noise should always be squashed. -Original Message- From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com] Sent: Thursday, March 05, 2020 4:53 AM To: dev@nuttx.apache.org Subject: Re:

RE: Progress on making a release

I am unclear about the build status and what has been added and if all the configs are in the test list. As I read the email from Xiang Xiao - all the builds do not build yet. I thought in the past ALL the builds were built before a release. -Original Message- From: Abdelatif

RE: Build is broken

@nuttx.apache.org Subject: Re: Build is broken may i assume you are using linux? here's a fix i tested on ubuntu. https://github.com/apache/incubator-nuttx-apps/pull/95/commits/adb08a2634ef8df99d509a472e28a7907f73210d On Sat, Feb 22, 2020 at 1:21 AM David Sidrane wrote: > > This is what

RE: Build is broken

is broken On Sat, Feb 22, 2020 at 12:58 AM Nathan Hartman wrote: > > On Fri, Feb 21, 2020 at 11:21 AM David Sidrane > wrote: > > > This is what I did: > > > > For apps and nuttx git fetch nuttx > > For apps and nuttx git checkout master > >

RE: Build is broken

b 22, 2020 at 12:13 AM David Sidrane wrote: > > Build is broken > > Build is broken > > And the output looks very ODD - any ideas on what happened? > > Leaving directory > '/home/david_s5/src/PX4/repos/mainline/NuttX/apps/platform' > > arm-none-eabi-ar rcs > /h

RE: Build is broken

on braches? David -Original Message- From: Nathan Hartman [mailto:hartman.nat...@gmail.com] Sent: Friday, February 21, 2020 7:17 AM To: dev@nuttx.apache.org Subject: Re: Build is broken On Fri, Feb 21, 2020 at 10:13 AM David Sidrane wrote: > Build is broken > > Build

Build is broken

Build is broken Build is broken And the output looks very ODD - any ideas on what happened? Leaving directory '/home/david_s5/src/PX4/repos/mainline/NuttX/apps/platform' arm-none-eabi-ar rcs /home/david_s5/src/PX4/repos/mainline/NuttX/apps/libapps.a make[1]: Entering directory

RE: IMXRT 1060 USB Device (copy of LPC43/LPC31 driver) - Set-up buffer problems

DTCM and D-cache are different You will need to add the cache clean and invalidate in the write/read functions to support D-cache. If you open a PR on Git hub, I will have a look at it. For comparison an STM32F7/H7 have these functions in the correct palces. David -Original Message-

RE: NuttX SocketCAN implementation

+pavel -Original Message- From: Peter Van Der Perk [mailto:peter.vanderp...@nxp.com] Sent: Tuesday, February 11, 2020 6:58 AM To: dev@nuttx.apache.org Subject: NuttX SocketCAN implementation Hi all, This is a follow up to the SocketCAN integration into NuttX discussion. As discussed

RE: [GitHub] [incubator-nuttx-testing] justinmclean commented on issue #2: Multibranch pipeline job example

Yet another great argument for github actions. -Original Message- From: GitBox [mailto:g...@apache.org] Sent: Tuesday, February 04, 2020 1:26 PM To: dev@nuttx.apache.org Subject: [GitHub] [incubator-nuttx-testing] justinmclean commented on issue #2: Multibranch pipeline job example

RE: Linker error

Ivan, There is a limit on what C++ can be compiled and built with Nuttx. The key is to not include any foreign (non nuttx) headers you can see the defconfigs setting used on PX4 here https://github.com/PX4/Firmware/tree/master/boards/px4/fmu-v5/nuttx-config/nsh and the things needed in Make.def

RE: [DISCUSS] adding templates for files.

My argument for this is the coding standard document can reference the directory and `cp` or `copy` can be used to get a properly formatted staring point file. This is opposed to cutting and pasting from a web browser and possibly really getting garbage in the file. Less tools, less margin for

[DISCUSS] adding templates for files.

When we do get this figured out. Can we put templates in a folder in the nuttx repo named something like: template_c_file.txt template_h_file.txt template_Make_file.txt template_ld_file.txt template_script_file.txt -Original Message- From: Gregory Nutt [mailto:spudan...@gmail.com] Sent:

RE: IMXRT1050 USDHC

Hi Ivan, It is correct. It fixes a bug that was added when the imxrt1020 came in. Apparently Dave did not wire the CD pin of the IC to the socket (He used a GPIO). But that change broke the case were the CD pin of the IC is wired to the socket Please See

RE: [DISCUSS] Wrapping up the Workflow document

, January 29, 2020 11:03 AM To: dev@nuttx.apache.org Subject: Re: [DISCUSS] Wrapping up the Workflow document On Wed, Jan 29, 2020 at 10:14 AM David Sidrane wrote: > My general comment on the Workflow document is it is too much information > and comments. > > Perhaps it can be broken into pa

RE: [DISCUSS] Wrapping up the Workflow document

, January 29, 2020 6:47 AM To: dev@nuttx.apache.org Subject: Re: [DISCUSS] Wrapping up the Workflow document On Wed, Jan 29, 2020 at 8:10 AM David Sidrane wrote: > Good tips! git is s powerful it is nice to lean other's tricks. > > Here is my `gitlast` command (it helps me answer the

RE: [DISCUSS] Wrapping up the Workflow document

and destination (git push src:dest) That's more typing, but prevents some mistakes. On Wed, Jan 29, 2020, 01:38 David Sidrane wrote: > Hi Abdelatif, > > Yes I know. It is a defensive move, on my part, that makes it safe when > working with multiple companies who might not appreciat

Re: [DISCUSS] Wrapping up the Workflow document

; You can merge local branch from a different remote than the branch is > tracking, giving that the merge is possible of course. > > On Wed, Jan 29, 2020 at 12:15 AM David Sidrane > wrote: > > > > Hi Abdelatif > > > > > Why do you prefer git reset

RE: [DISCUSS] Wrapping up the Workflow document

fork/master shall always be behind upstream/master, which will result in a fast forward. Why do you prefer git reset --hard /master to git merge /master after a fetch? On Tue, Jan 28, 2020 at 11:16 PM David Sidrane wrote: > > Hi Abdelatif, > > > Are you assuming that the work is alway

RE: [DISCUSS] Wrapping up the Workflow document

t the procedure described in the workflow will generate merge commits? Keeping a WIP branch in synch is missing from the workflow. Basically same as you described, that should consist of synching master (fetch + merge from upstream) then rebasing the branch on top of master. On Tue, Jan 28, 2020 a

RE: [VOTE] Remove Windows Native support?

-1 Keep it. It enables adoption. David -Original Message- From: cheshmedzh...@gmail.com [mailto:cheshmedzh...@gmail.com] Sent: Monday, January 20, 2020 8:25 AM To: dev@nuttx.apache.org Subject: RE: [VOTE] Remove Windows Native support? -1 Keep It. It is useful, less or more... Best

RE: [DISCUSS] Remove Windows Native support?

+1 FIX THE WINDOWS NATIVE SUPPORT && add a native test environment -Original Message- From: Alin Jerpelea [mailto:jerpe...@gmail.com] Sent: Thursday, January 16, 2020 4:06 AM To: dev@nuttx.apache.org Subject: Re: [DISCUSS] Remove Windows Native support? I am for option 3 FIX THE WINDOWS

RE: [DISCUSS]Bug Tracking

-Original Message- From: Brennan Ashton [mailto:bash...@brennanashton.com] Sent: Wednesday, January 15, 2020 10:24 AM To: dev@nuttx.apache.org Subject: Re: [DISCUSS]Bug Tracking On Wed, Jan 15, 2020, 10:09 AM David Sidrane wrote: > +1 for Github issues per repo. > > Repos can b

RE: [DISCUSS]Bug Tracking

+1 for Github issues per repo. Repos can be cross referenced in markup. Assignees can be assigned labels can be assigned. Projects (roll up across repos) can be assigned. Milestones can be assigned. UI is simple and effective Query by any of the above attributes. The interfaces is present when on

RE: Apache Code Relese (Was Re: Side-effects of removing (void))

The NuttX project is still misusing the tools. It is not the PR. It is the process (or lack of one) To solve this problem: Build the PR on top of master BEFORE merging. Do not MERGE until PR on master builds. David -Original Message- From: Gregory Nutt [mailto:spudan...@gmail.com]

Re: Issue Reporting

>>>>>> This can all be turned on with the .asf.yml file and I can submit the >>>>>> pr for that if we want. >>>>>> >>>>>> --Brennan >>>>>> >>>>>> >>>>>> On Mon, Dec 30, 20

RE: Working Effectively (was Point of Order)

+1 Adding a tool that promotes violating the INVIOLABLES.txt on several aspect (expedience and non conformant code into the repo) feels like a very bad choice. How is this being justified? David -Original Message- From: Alin Jerpelea [mailto:jerpe...@gmail.com] Sent: Tuesday, January

Re: What happened to (void) for ignored return values?

it to ASK wiki? > > BR, > > Alan > > On 1/3/20, David Sidrane wrote: > > Given all the input from ASF mentors : Should this live on the ASF Nuttx > > servers, possibly labeled "interim work flow", and should it be voted on > > prior to use? >

[DISCUSS] RE: Working Effectively (was Point of Order)

, December 30, 2019 6:01 PM To: dev@nuttx.apache.org Subject: Re: Working Effectively (was Point of Order) On Tue, Dec 31, 2019 at 7:09 AM David Sidrane wrote: > > Hold on! > Having a coding standard with 4000+ files in the repo that do not pass the > test… > …reminds me of

RE: User Email Account

Hi Justin, I would say we all understand the argument. We do not agree with how the problem is solved. Why are we making everyone drink from the fire hose? Please help make this work for everyone. Clearly, from the responses, it is not. How about we make multiple lists and arrogate them to top

FW: [PX4/Firmware] To test [PX4/NuttX] [BACKPORT] STM32F7 and STM32H7 SDMMC internal pull up usage fixed (#78) (#13787)

FYI *From:* modaltb [mailto:notificati...@github.com] *Sent:* Monday, December 30, 2019 4:13 PM *To:* PX4/Firmware *Cc:* David Sidrane; Author *Subject:* Re: [PX4/Firmware] To test [PX4/NuttX] [BACKPORT] STM32F7 and STM32H7 SDMMC internal pull up usage fixed (#78) (#13787) Tested over 300

RE: Future Trademark Issues

ues Taking a quick look at PX4 it looks like it would be an issue, however it's one that easily fixed in a number of ways. It's not urgent to fix now. On Tue, 31 Dec 2019, 09:57 David Sidrane, wrote: > Nope! > > -Original Message- > From: Gregory Nutt [mailto:spu

RE: User Email Account

+1 -Original Message- From: 张铎(Duo Zhang) [mailto:palomino...@gmail.com] Sent: Monday, December 30, 2019 10:49 PM To: dev@nuttx.apache.org Subject: Re: User Email Account But I think posting so many 'hard to read' emails to the mailing list will hurt user experience and cause users to

<    1   2   3   4   >