cmake(bugfix):Synchronize the compilation differences between CMake and Makefile in nuttx repo

Summary
sync CMake missing sources
There are differences between the current CMake base and Makefile.
This patch synchronizes the differences between modules
so that the CMake compilation content should be consistent with the Makefile.
Impact
[arm ach, fs, sched, mm , libc, drivers]
Testing
all CI build

[Experimental Bot, please feedback here]
Yes, but with minor improvements:
Meets Requirements:

Summary:  Clearly states the "why" (CMake/Makefile discrepancy), "what" (synchronizing modules), and "how" (patch for consistency).
Impact:  Lists affected areas, which is helpful.
Testing:  States "all CI builds" pass, indicating thoroughness.

Suggested Improvements:

Impact:

Be more specific. Instead of just listing areas, briefly describe the impact within each.  E.g., "fs: Adds missing source files for X feature."
 Even if it's "NO", explicitly state it for clarity (especially security, compatibility, etc.).

Testing:

While "all CI builds" is good, a few specific examples of before/after log snippets would add strong evidence. Choose ones demonstrating the problem being solved.

Overall: Good start!  Adding the specifics mentioned above will make this PR review much smoother.

hi @simbit18 It seems that there is a bash command line limitation issue under msys2
Could you help take a look?

Hi @xuxin930 Sure now I try.

I tried this PR locally
Cmake
The problem does not occur when building NuttX only with Cmake.
[100%] Linking C static library libapps.a
[100%] Built target apps
[100%] Building C object apps/system/nsh/CMakeFiles/apps_nsh.dir/nsh_main.c.obj
[100%] Linking C static library libapps_nsh.a
[100%] Built target apps_nsh
[100%] Building C object apps/system/nsh/CMakeFiles/apps_sh.dir/sh_main.c.obj
[100%] Linking C static library libapps_sh.a
[100%] Built target apps_sh
[100%] Building C object apps/examples/hello/CMakeFiles/apps_hello.dir/hello_main.c.obj
[100%] Linking C static library libapps_hello.a
[100%] Built target apps_hello
[100%] Building C object CMakeFiles/nuttx.dir/empty.c.obj
[100%] Linking C executable nuttx
[100%] Built target nuttx
[100%] Generating nuttx.hex
[100%] Built target nuttx-hex
[100%] Generating nuttx.bin
[100%] Built target nuttx-bin

Cmake+Ninja
The problem occurs when building NuttX with Cmake+Ninja.
/bin/sh: line 1: /home/bit/nuttxnew/tools/gcc-arm-none-eabi/bin/arm-none-eabi-ar: Argument list too long
[813/1026] Building C object mm/CMakeFiles/mm.dir/umm_heap/umm_malloc_size.c.obj
ninja: build stopped: subcommand failed.

It is certainly related to the fact that Windows has a limit of 8192 characters for command line arguments.
This does not seem an easy error to solve!!!
Should we disable CMAKE + Ninja for Msys2 while waiting for a solution?

Should we disable CMAKE + Ninja for Msys2 while waiting for a solution?

@simbit18 nice catch!
We split the ar step here, but it seems that it only works for the default generator, not the ninja generator.
I agree that disable the ninja generator  in the msys2 environment.
https://github.com/apache/nuttx/blob/0647b4999058ba8886c7c7c201ad0c539d54360e/arch/arm/src/cmake/gcc.cmake#L80-L92

@xuxin930  I will be away for a few days so if you decide to disable Cmake + Ninja for Msys2 just remove -N
on build.yml for Nuttx
https://github.com/apache/nuttx/blob/6ea3dcace44bece9b7a5f91f6080fdbd3030d9f9/.github/workflows/build.yml#L327
and Apps
https://github.com/apache/nuttx-apps/blob/faea166566d1620d5ca4f6b5ea0419b148b042f4/.github/workflows/build.yml#L322

and Apps https://github.com/apache/nuttx-apps/blob/faea166566d1620d5ca4f6b5ea0419b148b042f4/.github/workflows/build.yml#L322

@simbit18  sure, thanks for your suggestion.


Autocomplete

Is there any way to add text suggestions while typing?

Wrote my own version of richtext with text suggestions


Is resovleEntityReference still relevant?

What
Decide if manager.resolveEntityReference(ref) is meaningful or it could simply be manager.entityData(ref, BlobTrait), where BlobTrait  defines a url property.
Why
#238 resolves one of the lingering messy parts of the current API design. The spec hierarchy precluded the ability to define concrete, well known behaviour that was shared across branches in the spec tree. This meant Specifications could never be used to reliably define any particular aspect of an entity in isolation. This predicated methods such as resolveEntityReference in order to formalise a common shared behaviour of "resolving to a string".
Being able to concretely ask for specific data from an entity simplifies many aspects of the conceptual model, and removes the baked-in concept of a string-to-string mapping as a core premise.
This already caused us issues with "non file based entities" where there may be no specific primary string. The name "primary string" itself shows the problem - that is, it is unspecific and leaves a lot to interpretation. This all goes away.
This could have performance implications though for the primary (current) use case of resolving paths? There should be no reason not to intern all spec/trait magic strings though I think?
If we do this, then it most certainly means that #31 should be manager.entityTraits(ref, context), that returns the collection of trait names that the entity supports.
This change has the additional benefit that it encourages a formal definition of any well-known traits that hosts or managers may wish to use within the system, something lost with the old attributes free-for-all bucket.
Potential downsides
A potential issue with this approach of a host specifying it's intended usage by requesting a specific trait is that you would need a "default" trait that a generic resolver with no knowledge of usage could use to 'resolve a ref to any old string'.
This raises the question though - is the idea of "blind resolving" compatible with the overarching principal in this API of providing contextual information about the use of the data?
If such a behaviour was required, one way to achieve this could be to simply define a string trait, with a value property, and use entityData(ref, StringTrait), which effectively models the behaviour of resolveEntityReference:
def resolveEntityReference(self, ref, context):
    return StringTrait(self.entityData(ref, StringTrait.name, context)).getValue()

ACs

A decision on whether this is a sensible change.
Documentation of the proposed API changes.
A qualitative performance comparison against some naive manager implementation, that has the data for a BlobTrait  in memory that shows, the comparative cost of resolving 1,000,000 unique references in terms of the differences in:

Total wall-clock time.
CPU Time spent in the API (not including the internal cost of looking up the resolved data in the manager).
Portion of API time spent in memory allocations.

Sketch
Assuming:
trait EntityTrait {
    name: "entity"
}

trait BlobTrait {
    name: "blob",
    props: { url: str, mimeType: str }
}

trait ImageTrait {
    name: "image",
    props: { colorSpace: str }
}

spec ImageSpec {
    traits: ["entity", "blob", "image"]
}

Publishing an image
A host wishes to publish an image to a target entity reference, ensuring its color space is properly tracked.
img = ImageSpec()
img.blobTrait().setUrl("file:///some/render.exr")
img.imageTrait().setColorSpace("ACES - ACES2065-1")

context.access = context.kWrite
published_ref = manager.register(ref, img, context)

Simple resolve only
A generic script handling bulk resolution of references to data URLs.
context.access = context.kRead
url = manager.entityData(ref, ['blob'], context)['blob']['url']

More data in one call
A compositing application wanting to load an image with the correct colorspace.
context.access = context.kRead

img_data = manager.entityData(ref, [BlobTrait.name, ImageTrait.name], context)

path = BlobTrait(img_data).getUrl()
colorspace = ImageTrait(img_data).getColorSpace()

or
context.access = context.kRead

img_data = manager.entityData(ref, ImageSpec.traitNames, context)

img = ImageSpec(img_data)
url = img.blobTrait().getUrl()
colorspace = img.imageTrait().getColorSpace()

The first example has the advantage of only requesting data that is explicitly required. The second, may fetch more data than is necessary, depending on exactly which traits the spec used composes.
Note however, that in either case, this is one less API call than the current implementation that would required a call to resolveEntityReference then getEntityAttributes.
Browsing
A compositing application wanting to browse for ACES colorspace images only.
Note: this is not affected by these changes, but illustrates the symmetry.
widget = ui_delegate.getWidget(kEntityBrowserIdentifier, context)

required_spec = ImageSpec()
required_spec.imageTrait().setColorSpace("ACES - ACES2065-1")
context.access = context.kReadMultiple

refs = widget.browse(required_spec, context)

The above uses a spec over just ImageTrait, as the other traits of ImageSpec (entity and blob) are also essential to subsequent operations.

.. alternatively, we could just call it manager.resolve(ref, traitNames, context) and get rid of entityAttributes 🙃

It'd be nice it we didnt ever end up needing it to be magical as it makes life easier for the manager...

Agreed.  Maybe we try going with the assumption that we don't need a generic StringTrait that can map to multiple things depending on the context.  Seems easy enough to add later.

On re-thinking/re-reading this issue, I just want to second the AC for performance comparison.
I recall previous conversations about critical paths for performance, and IIRC the only example is the "resolving thousands of references to their primary string" case.  So it may be that we need a special case just for this, where we forego specifications/traits/dictionaries (or it may be that the difference in negligible in practice).
Are there other foreseeable bulk queries that must be performant?

Are there other foreseeable bulk queries that must be performant?

I don't believe there are any in the the current API that we know of today.
An interesting side thought on this, is that would actually batching queries, vs individual lookups totally eclipse the benefits any specific fast-path API call?
It would be interesting to find out, in the happy fast path, for these high-volume resolves, how many hit a cache in such a way that the C++ overhead would eclipse the cost of actually resolving?
In that, we've heard anecdotally that some people are stalling + batching up resolves in their USD AR 2 resolver to avoid the individual back-end query latency slowing everything.
I believe its a side effect of the (loosely) BFS that most scene expansion algorithms go for that means batching would required a shift in approach on the host side?

Closing as we have decided to switch to the unified model (see #269), work planned.


Added a couple of resources

Added the Cyber Wizardry Institute and MDN web development learning links.

Thanks @mpmckenna8!
Merging your additions, but then moving Cyber Wizardry Institute under Schools section.

Moved Cyber Wizard Institute under Schools section:  aa4828d


Idea: Auto-discover and auto-enable repos

Clear and concise description of the problem
The steps to get Woodpecker running for a repo are quite involved:

If it's a new repo, click "Reload Repositories", so Woodpecker discover the new repo from SCM
Click "Enable" on the repo, which installs the webhook into SCM
Push a .woodpecker.yml to the repo

On other CIs like GitHub Actions it's only one simple step:

Push a .github/workflows/something.yml to the repo

Suggested solution
Provide a way to skip steps 1 and 2 for a better UX.
The SCM could trigger a webhook to Woodpecker on repo creation/deletion/push/tag (System Webhook in Gitea), which is all that Woodpecker would need to work. With such an integration, per-repo webhooks would also become unnecessary.
Validations

[X] Checked that the feature isn't part of the next version already [https://woodpecker-ci.org/faq#which-version-of-woodpecker-should-i-use]
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

#71 seems to be for GitHub, my aim here is for Gitea.


Translate the Gherkin Rule keyword

Last year, a new Rule keyword was added to Gherkin. Please help us by adding a comment to this issue, and we'll update the parser accordingly. Example:
Norwegian (no): Regel
Obrigado!

Serbian (Cyrillic): Правило
Serbian (Latin): Pravilo

Много хвала @pzelenovic!
(In case anyone wonders - I know how to use Google Translate, but these translations should be done by humans in case we choose the wrong translation amongst many possibilities).

Polish (pl): Reguła.

Thanks @Jaahquubel

Turkish (tr): Kural


question - Windows Iot core gateway?

Does anyone know if they gateway functionality has been adapted to run on windows Iot core?

I have not tested the code on UWP. I think there might need to be some changes to be done in the Bluetooth/socket/Serial over USB stacks.


Call#to_s doesn't deal with underscored names correctly

ToSVisitor#visit_call invoked through Call#to_s does not deal very well with underscored names, e.g. _variable or _method.
Testcode:
Parser.parse("foo._bar").to_s #=> "_barfoo"
Parser.parse("foo._bar(1)").to_s #=> "foo _bar 1"
Parser.parse("_foo.bar").to_s #=> "(_foo).bar"

Thank you.

You are right, thank you! :-)


Can't get the Read Example to work on ESP32 Arduino in PlatformIO

I really wanna use this library because it's well documented, actively developed and non-blocking. So big THANK YOU!!
Unfortunately i can't get the arduino read example to work. Im on a ESP32 Thing Plus with the Sparkfun DMX Shield.
My platformio.ini
[env]
platform = espressif32
monitor_speed = 115200
framework = arduino
lib_deps =
    esp_log.h
    someweisguy/esp_dmx @ 3.0.3-beta
    ;https://github.com/someweisguy/esp_dmx/

[env:debug_thingPlus]
board = sparkfun_esp32s2_thing_plus_c
board_upload.flash_size = 16MB
build_flags =
    -D CORE_DEBUG_LEVEL=5

And then I'm using your example from here:
https://github.com/someweisguy/esp_dmx/blob/v3.0.3-beta/examples/DMXRead/DMXRead.ino
I've only added an else statement at the end with a debug message, like so:
...
/* Stop the program. */
    while (true) yield();

 // This is what i've added:
  } else {
    Serial.println("Waiting for DMX...");
    Serial.println("Error: " + String(packet.err));
  }

The packet return the Error: 263. In my research a came across this breadcrumb-trail:

The ESP32 error 263 corresponds to a timeout error, often associated with I2C communication. This error might occur due to several reasons such as:
A bad connection in your I2C setup.
Incorrect configuration of the I2C setup.
Not sending the correct register addresses.

Any ideas what's happening?

By the way, I'm using UART Port1 and GPIO Pins 16, 17 and 21 (standard ESP32) according to their DMX library example code:
... // lines 28 - 30
int enablePin = 21;		//dafault on ESP32
int rxPin = 16;
int txPin = 17;
...

Just realised, after studying those products for hours, that there is a discrepancy in the documentation: In their DMX library (above) they'r using GPIO21 as Enable. But if I map the the Sparkfun DMX Shield documentation to the Sparkfun ESP32 Thing Plus graphical datasheet it looks like Enable is GPIO4. I will ring the board through with my multimeter later today to rule out that it's a hardware / pin definition issue.

Thanks for the kind words and so sorry for the confusion! I am also a bit perplexed - I have a couple Sparkfun DMX shields as well and I've had no issues using GPIO 21 as the enable pin. I do not see a revision number listed on my Sparkfun DMX shields. If your has a revision number on it, then I suppose that would be the issue.
Two quick side notes:

If you are using RDM with the Sparkfun shield you should solder a 120ohm resistor as the terminating resistor if you haven't already. Using RDM without that terminating resistor may cause problems sending and receiving RDM requests.
Based on the issue you submitted in #78, it appears you are using the latest commit which is currently experimental. You may continue to have issues using the experimental commit, but hopefully they are few and far between. If you would like to use a more stable commit, you should use the tagged commits. That said, I am very nearly done with version 3.1 so hopefully you'll have a stable version with the latest features soon!

Let me know if you have any comments, questions, or concerns!


Add documentation for configuring Project

Need to add documentation for configuring the project so user can easily setup this project in their environment and run locally.

@vivekpatel19 thank you for your feedback. I will take care of this.

I take a look at the repo and I found it so simple. That’s why I couldn’t find how to document it. If you want to contribute it, you are welcome. Fell free to reopen the issue.


Feature/branch coverage

🚨 Proposed changes
Hi, while I was working on a project I had a very similar need to get results out of a ..input file. But in addition I needed to get branch coverage. So I forked your repo and added branchCoverage method. Ive added some test files to have a better understanding of formats meanwhile. And also Ive done some refactoring :)
⚙ Types of changes
What types of changes does your code introduce? Put an x in the boxes that apply

[ ] New feature (non-breaking change which adds functionality)
[ ] Bugfix (non-breaking change which fixes an issue)
[ x ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation Update (if none of the other choices apply)
[ x ] Refactor

Hi! I didn't have a lot of time to check my old projects so I missed that sorry


Can't Upload

Using centos 7 and php 7.4.
Can't seem to upload. The progress meter is just instantly 100%. Chrome inspector shows data being posted. Progress meter turns red but then nothing. Nothing occurs on the client, the file is not displayed, there is nothing in respository dir and nothing is logged. I can see chunks being posted in the httpd access log. But otherwise nothing happens.
Am I missing something?

Hi

Check server logs (/var/log/apache2/error.log)
Make sure your webserver can read and write to filegator/repository/ and all filegator/private/* folders

In php.ini had to turn on:
file_uploads = On
Strangely most results searching about this don't mention it. Maybe it's on by default and I turned it off as a precaution. Anyway I got uploads working now (although I ended up modifying simple-file-manger because I needed something super simple).

cool, closing this...


upgrade to webpack 4 and babel 7

hi @orYoffe , do you want to upgrade the webpack to 4 and the babel to 7?

Hi @geminiyellow, thanks for the suggestion. I would be happy to but I would wait for create-react-app to upgrade to babel 7 and webpack 4 and then i will recreate it from that project.
PRs are welcome :)


add untiray update

Context: The update for the interferometer is a unitary update
Description of the Change:
Benefits:
Possible Drawbacks:
Related GitHub Issues:

Thanks for the links. Don't forget to update the changelog.

Thanks for the links. Don't forget to update the changelog.

I don't know which release version of the changelog I should add. And under which issue?

The latest version (0.4). No need to reference an issue if none was opened.

@ziofil, I tried to put it in the category ``improvements''. You can tell me if it is the correct place to put it.

I would put it under bug fix, and add a short explanation that it fixes an issue that one could end up with unphysical interferometers.

How about this?

Hmm... if looks as if the update_unitary method isn't covered in the tests... why? We are training an interferometer in the tests 🤔

Hmm... if looks as if the update_unitary method isn't covered in the tests... why? We are training an interferometer in the tests 🤔

I think I know why. I only add these functions. But I haven't massively replaced all the orthogonal things by unitary things. Let me fix it.

@ziofil I've changed all over in MM from orthogonal -> unitary. Please tell me if I made some mistakes on the way to do it.

Training has something wrong. It looks like the loss function goes up and down all the time. Try this function in tests/test_training/tests_opt.py-> test_learning_two_mode_Interferometer().

Training has something wrong. It looks like the loss function goes up and down all the time. Try this function in tests/test_training/tests_opt.py-> test_learning_two_mode_Interferometer().

Fix this. The problem was the euclidean to unitary gradient calculation.

Great work Yuan, I left a few simple suggestions. My biggest comment regards the update step for the RealInterferometer. As the parameter is an NxN orthogonal matrix, shouldn't we use the orthogonal update rule here?

Thanks Filippo.

I was thinking to add a new test about update of the orthogonal group;
Because every formula between unitary and orthogonal is the same, except for the T with the dagger. So in case that the matrix is real, the update rule of the unitary group would degenerate into the one of the orthogonal group. This is my idea. But I still need the test to support this statement. Let us see.

@ziofil Need one more review here please!