Example downstream manifest+module repo in zephyrproject-rtos

Create a new repository in the https://github.com/zephyrproject-rtos organizationt that can serve both as reference and as a starting point for users wanting to create their own manifest+module repo (later this can be extended with additional sample module repos).
https://github.com/zephyrproject-rtos/zephyr-downstream-application
which would have:

A west.yml so it serves as a manifest repo. This will import zephyr's manifest.
A zephyr/module.yml so it serves as an actual downstream module. This should include:

A custom CMakeLists.txt
A custom Kconfig.module
A custom board, using board_root and dts_root

A library configurable with Kconfig
A driver configurable with Kconfig and Devicetree
A sample that uses that library and driver (and other Zephyr ones)
A test that tests the library

We could then move https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/application_development/out_of_tree_driver/hello_world_module/zephyr to the new repository.

self-assigned at least for any west instrumentation changes needed to get this working in CI on each PR

For clarification,is this an example of what could be done, what is expected to be done, or what will be supported for the mid- to long- term?

A driver configurable with Kconfig

... and dts, I assume?

For clarification,is this an example of what could be done, what is expected to be done, or what will be supported for the mid- to long- term?

imo this will be a repo that can be used to ensure that Zephyr module features for out-of-tree are working can be tested by CI so that it is ensured that it work as expected.
At the same time, it can serve as a simple reference point for downstream users.
That way we ensure:

A reference point of a single use case
CI testing of Zephyr module features
Guarantee that the reference point will always be in sync with the code, else CI will fail

@tejlmand, I agree with the need to support CI verification of Zephyr module features. I think this needs to be more than a "simple reference point" of how those features can be used. I want to know how the module is expected to be setup - in practice, a boilerplate. Extending my downstream modules as Zephyr module features get added is fine (and expected), but restructuring it to take advantage of a new feature is highly undesirable.
Since we need to support extending existing external repositories to be zephyr modules (e.g. github.com/project-chip/connectedhomeip), I propose:

All(?) the zephyr unique files be kept under the necessary zephyr sub-directory, following the zephyr repo directory structure (e.g. manifests, those discovered by sanitycheck/CI, hello_ sample, west extension scripts, Kconfig files).
Shared namespaces (e.g. include pathnames, CPP symbols, Kconfig vars, etc) be prepended with the module repository org/name, where dashes are replaced with underscores. (It's really too long, but we need to avoid namespace conflicts.)
Automatic formatting rules are provided for all files beneath the zephyr sub-directory structure (e.g. .clang-format). This will simplify file comparisons against the boilerplate.
A repo-level .gitignore be commented with why each setting is necessary, since some may conflict with pre-existing build tools.

A couple more:

Names/prefixes of tags and the main development branch and tags are recommended to be the manifest repository name. Since this is a manifest+module repository the main development branch should be renamed to the name of this repository. (This means there will not be a branch named "master", and a "zephyr" branch likely will not be meaningful or useful.)
A module version and manifest version schemes, policies, and query/discovery mechanisms should be set up, since the zephyr version is no longer the manifest version.

Please remember that the board "unit_testing" requires different build logic in the test files, so the module interface functionality verification needs to include an example of that.

I think this needs to be more than a "simple reference point" of how those features can be used. I want to know how the module is expected to be setup - in practice, a boilerplate.

@gregshue I'm not sure I get you on this one. I don't think we have expectations of our users in the form of "if you don't structure your module in this way, you're doing it wrong" in this case. I am assuming @tejlmand means "simple reference point" as "here is a way to do it that we think works well and can commit to maintaining". (Please LMK if I misunderstood that.)
So a simple reference point is a boilerplate for a "typical" application with an in-tree SoC, but out of tree board, application, and driver for an IC on the board that doesn't have upstream support yet.
Is it possible we are in violent agreement on this?

@gregshue my take on the other bullets:

All(?) the zephyr unique files be kept under the necessary zephyr sub-directory, following the zephyr repo directory structure (e.g. manifests, those discovered by sanitycheck/CI, hello_ sample, west extension scripts, Kconfig files).

-1 from me.
Flat is better than nested in this case, in my opinion. Users can always nest if their use case is suited for that.

Shared namespaces (e.g. include pathnames, CPP symbols, Kconfig vars, etc) be prepended with the module repository org/name, where dashes are replaced with underscores. (It's really too long, but we need to avoid namespace conflicts.)

I think it could be nicer to 'steal' some short names that are unlikely to conflict. I expect most users will change these anyway, to suit their own project naming conventions.
Karim Yaghmour does this in his Embedded Android book's chapters on adding board support for that operating system. He names the board the "coyote pad", and defines namespaces and files based on that. Microsoft does something similar with the fictional "Contoso" corporation in some of their publications. I personally find this practice easy to understand. It's just "foo" in another form.
Some specific ideas:

board name: plank, so files like boards/arm/plank/Kconfig, etc. (this matches the board porting guide, where "plank" is a stand-in for the custom board name)
sample name: killer-app, so files like killer-app/src/main.c
driver: for the chippy device, so files like drivers/sensor/chippy/{chippy.c,chippy.h}, preprocessor header guards VND_CHIPPY_H, Kconfig option CONFIG_CHIPPY, etc.
devicetree vendor prefix for chippy: vnd, so files like dts/bindings/sensor/vnd,chippy.yaml (vnd is used by the test case bindings as a stand-in for a real vendor)

Test case names would use these as well.
It would be straightforward to tell the story of the development of the new Plank device and its killer application in the documentation. This can also say that internally, the Plank includes an SoC already supported by Zephyr and the VND corporation's chippy sensor, which is not supported upstream. Etc.

Automatic formatting rules are provided for all files beneath the zephyr sub-directory structure (e.g. .clang-format). This will simplify file comparisons against the boilerplate.

Here be dragons; this is far from a settled question in the project, even just for line length.
I suggest that instead, we just make sure the linters that run on code in main zephyr repository also pass on this new module. We can discuss formatters if and when Zephyr itself starts to use them.

A repo-level .gitignore be commented with why each setting is necessary, since some may conflict with pre-existing build tools.

+1

Names/prefixes of tags and the main development branch and tags are recommended to be the manifest repository name. Since this is a manifest+module repository the main development branch should be renamed to the name of this repository. (This means there will not be a branch named "master", and a "zephyr" branch likely will not be meaningful or useful.)

While I am personally in favor of avoiding a main branch named "master", I think this is a project-wide question (which I believe the TSC is already discussing) and this module's main branch name should follow what the zephyr repository uses, to be changed if and when zephyr itself does.

A module version and manifest version schemes, policies, and query/discovery mechanisms should be set up, since the zephyr version is no longer the manifest version.

I don't know that I agree with a module-wide version right now; can you explain why that is worth having? I agree that a version numbering mechanism for killer-app makes good sense, though.

@mbolivar-nordic , I had not equated "simple reference point" with "boilerplate". With your clarification I think we are in agreement. Thanks for sharing your understanding. (BTW, I never assumed approaches other than this boilerplate were "wrong", just that the downstream maintainer assumes responsibility for designing/implementing/verifying support as module interface features get extended. :-))
Regarding your comments above:
If we don't set up a pattern to manage namespaces, et. al. at scale and beyond the scope of GitHub, then we have not addressed the crux of the problem. Similarly, if we haven't provided an example of how to extend existing repositories to be modules, then we also have not addressed the crux of the problem.
In my experience reuse-and-extend is a much more powerful enabler and paradigm than leverage-and-potential-reuse.  I  expect users to not rename anything from zephyrproject-rtos. It is much more efficient to live within the existing naming and reuse all applicable analysis and code provenance than to re-apply unnecessary changes over the long support/maintenance lifetime of IoT products (est. 10+ yrs). For boards, samples, drivers, applications (samples/testcases), and device tree settings, there is no need to "rename" anything. ("Renaming" implies removing the original.) Zephyr has already been designed to support extensions for each of these. You can easily copy from an existing implementation of any of these to create an additional one (whether in-tree or out-of-tree), and leaving the original intact makes it easier to track updates and apply relevant fixes.

Here be dragons; this is far from a settled question in the project, even just for line length.

By providing the same .clang-format file as exists in Zephyr, users can choose to enable, change, or disable automatic formatting as they like. It's no different than currently in the zephyr repo.  :-)

While I am personally in favor of avoiding a main branch named "master", I think this is a project-wide question (which I believe the TSC is already discussing) and this module's main branch name should follow what the zephyr repository uses, to be changed if and when zephyr itself does.

I have been participating in Process Working Group meetings and monitoring TSC discussions for several weeks, so am aware of the topic. The recommendation for the main branch name to be 'zephyr' came from the PWG, and it makes sense that all existing modules (which happen to be upstream of zephyr) have a main/integration branch name of zephyr. This issue is now introducing downstream modules, which necessarily provide their own manifest. Naming the downstream module's main branch as 'zephyr' doesn't set up a scalable pattern. But recommending that main integration branch names follow the manifest repo name does scale within at least GitHub, and fits with the existing TSC preference. Part of the reason for expressing it here is to help the TSC evaluate their current preference. :-)

I don't know that I agree with a module-wide version right now; can you explain why that is worth having? I agree that a version numbering mechanism for killer-app makes good sense, though

As I see it, one of the huge benefits is Zephyr is a Software Product Line. Zephyr Project is set up for reuse-and-extension, and some of that reuse will come from open source repos outside of zephyrproject-rtos (e.g. Project CHIP). In an SPL, a FW image is simply a set of build configuration settings and a few image-unique values. The vast majority of logic is or will be shared with at least one other image. Building out of the same source branch reduces maintenance across the whole SPL. Consider the case where a user wants to build dozens of different FW images for the same class of from the same branch of code. Or they need to support the same implementation over SOCs from a variety of vendors.
What does that have to do with module version numbers? Anyone wanting to integrate a downstream module into their product will want to use a released version for code stability, issue tracking, and eventually partial analysis for security certification submissions. In this case we are setting up a boilerplate for a downstream module, so we should provide a versioning mechanism tied into the Zephyr ecosystem.
Cheers!

@mbolivar @tejlmand @carlescufi After looking into how the Zephyr build system currently extracts version information, it seems like the following is all that is needed to tie downstream manifest modules into the Zephyr build system version extraction mechanisms:

Make sure this downstream repository has an initial annotated tag following the pattern used within the existing manifest repository (zephyr). The build system uses this to initialize the BUILD_VERSION cmake & preprocessor variables and reports it in the boot banner.

Q: What should the prefix of the tag be (since zephyr is not the manifest repository)?

Provide a VERSION file. The build system uses this to initialize the PROJECT_VERSION_* cmake variables.

Q: Where should the VERSION file be located?

Proposal: module.yml should describe the location of the hardcoded file (or a script to generate the file)? For this repository the hardcoded file or generation script should be at some level beneath the zephyr folder.

These will reveal places where we have assumed ZEPHYR_BASE is also the manifest repository (which is no longer true), and drive distinction back into the zephyr repository. I see it will already drive change into zephyr/cmake/version.cmake and zephyr/cmake/git.cmake.

Considering module names (and associated namespaces), it would be beneficial if all zephyrproject-rtos downstream modules were easily identified within the name. Perhaps github.com/zephyrproject-rtos/oot_*, with this specific repository being named oot_boilerplate or oot_template?

@tejlmand We will also need to verify the solution also supports the Forest topology, where the manifest repo contains no business logic. I expect this will require a separate OOT manifest(s)-only repository with:

multiple west.yml files

one importing only zephyr
at least one including an OOT module with one or more applications

VERSION data (unique per manifest file?)

Perhaps this additional repository should be named oot_manifest_only?

@tejlmand We will also need to verify the solution also supports the Forest topology, where the manifest repo contains no business logic. I expect this will require a separate OOT manifest(s)-only repository with:

Note, the main point of testing in this case is to ensure that Zephyr modules works.
West and west workspace topology should be tested by west, and not Zephyr.
This is done here:
https://github.com/zephyrproject-rtos/west/tree/master/tests

@tejlmand The Zephyr build system also needs to be verified to work in different topologies, notably when zephyr is not the manifest repository. This is true whether the manifest repository has any prj.conf or is configured from an alternate manifest file. Since Zephyr explicitly supports the Forest topology separate from the Star topology (w/o Zephyr as manifest), an example of a manifest-only repository seems appropriate. This is especially important if the overall FW version or BUILD_VERSION should map to a distinct manifest.

The Zephyr build system also needs to be verified to work in different topologies, notably when zephyr is not the manifest repository.

@gregshue  you seem to miss the point that west is an optional tool.
https://docs.zephyrproject.org/latest/guides/modules.html#without-west
What this issue should focus on is that the Zephyr module infrastructure works correctly.
That is, ensuring ZEPHYR_MODULES works.
One way to obtain a list of modules, is by using west list, and therefore it makes sense to combine this into a repo that can also work as a simple reference point, as that will serve two purposes:

Makes it easier to integrate into CI
Show to users a simple way they can structure their project

Doing testing of other typologies is therefore outside the scope of this.

In this case we are setting up a boilerplate for a downstream module, so we should provide a versioning mechanism tied into the Zephyr ecosystem.

Zephyr is already calling into the module's CMake build system.
That build system can decide how it wants to handle versioning.
It could decide to use a VERSION:
https://github.com/nrfconnect/sdk-nrf/blob/master/VERSION
or it could decide to fetch the version info using git (if available), e.g.:
git describe --tags
If we start imposing a version field in the module.yml, then we force users to update that field.
As long as Zephyr itself doesn't use the field, I see no reason to introduce this, and definitely not as part of this task.
(Feel free to open a new enhancement suggestion for this/)

Considering module names (and associated namespaces), it would be beneficial if all zephyrproject-rtos downstream modules were easily identified within the name. Perhaps github.com/zephyrproject-rtos/oot_*, with this specific repository being named oot_boilerplate or oot_template?

I don't think this is the right issue for such discussion.

These will reveal places where we have assumed ZEPHYR_BASE is also the manifest repository

west is an optional tool, so Zephyr knows nothing about being a manifest repo.

Shared namespaces (e.g. include pathnames, CPP symbols, Kconfig vars, etc) be prepended with the module repository org/name, where dashes are replaced with underscores. (It's really too long, but we need to avoid namespace conflicts.)

I think it could be nicer to 'steal' some short names that are unlikely to conflict. I expect most users will change these anyway, to suit their own project naming conventions.

agree with @mbolivar-nordic here.
Especially as usersin some cases might want to uses same names as another module in order to replace/overrule that module.
As example, they want to use the same set of MBEDTLS Kconfig names as Zephyr does, as this allows them to override default menus/default settings.

@tejlmand , Thank you for your feedback. I absolutely agree that ZephyrProject specifies that west is optional.

What this issue should focus on is that the Zephyr module infrastructure works correctly.

I think you have recognized a general need that is tangential to this ticket. This ticket is about creating an Example downstream module with simple business logic and covers the breadth of points of extensions and is a suitable pattern for extending existing 3rd-party open source repositories (e.g. https://github.com/project-chip/connectedhomeip , https://github.com/bacnet-stack/bacnet-stack, https://github.com/micro-ROS/micro_ros_zephyr_module).
As such, this ticket will set precedence (and likely direction) for the following:

Downstream/OOT naming pattern for modules owned by zephyrproject-rtos
Namespace management pattern for Downstream/OOT modules (for symbols in Kconfig, CMake, C pre-processor, linker, include paths, shell, logging, etc.)
Directory structure organization
Documentation organization
How the Zephyr build system natively supports versioning of downstream/OOT projects

Why consider versioning? Because PROJECT_VERSION* does not refer to the image built from an out-of-tree prj.conf.

I have created a proposed implementation for this example at https://github.com/gregshue/oot_module_example. It does not have a board, driver, or dts implementation, but provides the structure and documentation to hold them.  I would submit this as a PR but the Zephyr Project repository has not yet been created.
I will post an RFC for this proposal below.
@carlescufi @tejlmand Is there anything else needed to move this along?

Introduction
Establish an out-of-tree module example (boilerplate) repository
demonstrating how to extend open-source repositories to also be
Zephyr out-of-tree modules.
Problem description
Users will be creating and integrating open source and private out-of-tree
extensions to the Zephyr ecosystem. To be successful the Zephyr support for
out-of-tree integration needs to be more formally documented, continuously
verified, and one or more examples provided and maintained. No example
currently exists.
Proposed change
Create a feature-rich example/boilerplate repository for out-of-tree modules
which provides the following in a natural application and extension of
existing Zephyr patterns:

Zephyr directory tree structure and build interface files immediately
beneath the required zephyr subdirectory

documentation on the out-of-tree module design and support

trivial examples of functionality to verify and demonstrate out-of-tree
support. Functionality includes boards, dts, drivers, subsystems,
sample applications. Each functional example is provided with tests,
samples and documentation.

an overall scalable pattern for namespace management

Detailed RFC
Existing external repositories have structures and build systems that
are probably not aligned with the Zephyr build system.  These repositories
must provide a top-level zephyr subdirectory to be recognized by the
Zephyr build system as a module. This is a natural place to keep
Zephyr integration files isolated from the rest of the repository and
for users to start debugging system integration.  This subdirectory
introduces a level of indirection that affects the following parts
of the current Zephyr repository patterns:

Namespace patterns need to be extended to include module
identification. The set of affected namespaces includes:

Zephyr Project repository naming patterns
Proposal: All Zephyr Project out-of-tree modules begin with `oot_`.

Zephyr Project repository branch naming patterns
Proposal: All Zephyr Project out-of-tree modules have
Zephyr Project managed changes mainlined to a branch
named `zp-<module-abbrev>`

Zephyr Project repository tag naming patterns
Proposal: All Zephyr Project out-of-tree modules have
Zephyr Project created tags are named `zp-<module-abbrev>-*`

Kconfig
Proposal: OOT modules have a module-level Kconfig variable to
enable the module, which defaults to module disabled, matching
the module abbreviation.  All Kconfig variables defined by this
module begin with the module abbreviation.

CMake/make variables
Proposal: OOT module build variables begin with the module
abbreviation.

C preprocessor symbols
Proposal: OOT module CPP symbols not derived from other
namespaces begin with the module abbreviation.

include file pathnames
Proposal: OOT module header file pathnames contain a directory
named with either the module name or module prefix, located
beneath the common layers
(e.g. include/drivers/<module-abbrev>/).

linker symbols (whether from C identifiers or linker directive files)
Proposal: OOT module entrypoint symbols begin with the
module prefix.

Manifest file location and count.  Out-of-tree repositories
are downstream of the zephyr repository, so cannot be part of the
Zephyr default manifest file.  For development and maintenance supprt
each OOT module must provide a manifest file pulling in the version
of Zephyr it depends upon.  In practice, OOT modules must simultaneously
support multiple versions of Zephyr (to maintain an already integrated
Zephyr version and to extend coverage to a version being integrated).
Proposal: manifest files are kept in a `manifests` folder
parallel to `tests` and `doc`. Each manifest file should be in
a separate subdirectory within the manifests tree.

Documentation label naming patterns should support generating
an aggregate document for all content in the manifest configuration.
Proposal: Documentation labels begin with the module
abbreviation.

There are also a few changes needed as Zephyr is no longer the manifest
repository.  These include:

Build files
Proposal: Build files need to clearly distinguish when
referencing ZEPHYR_BASE for build tools/logic vs static data vs
working around the manifest repository being treated differently
than (other) modules.

Build and CI processes
Proposal: always go through `module.yml` to discover and
interface with OOT modules.

module.yml
Proposal: module.yml defaults map to the Zephyr directory tree
placed at the location of the module.yml file.

Documentation settings must be unique to the module (e.g. module name).
but needs to align with the documentation of Zephyr.
Proposal: Module documentation parallels the structure and build
processes of Zephyr.  Documentation generation tools, scripts,
and static data are reused in the module by default.  Module-
specific data (e.g. images, copyright statements) is kept in
a location parallel to the replaced content.

Versioning of manifest modules is distinct from versioning of the
kernel. Some solution must be provided by the example.
Proposal: Zephyr Project originated manifest modules use the
same versioning mechanism, numbering scheme, and tag usage as
in Zephyr.

All of the above proposals are for patterns that apply to all current
and future Zephyr Project originated OOT modules, and are recommendations
for OOT modules originated elsewhere. The specific values for the first example
also need to be addressed.
Proposal: This specific example repository is named
`oot_module_example` and uses the abbreviation `OMX`
(Out-of-tree Module eXample) or `omx` in the above namespaces.

Dependencies
All of the above has been developed and verified in a non-Zephyr Project
repository using west 0.8.01a and dependent on Zephyr v2.3.0.  No
changes were necessary, but build system support broke in Zephyr v2.4.0.
The support of out-of-tree modules impacts every team to varying degrees.
A few teams must maintain parallel implementations in each repository
(e.g. Documentation generation, build files, release notes, CI processes).
Concerns and Unresolved Questions
There are a few open issues that eventually need to be address:

How to indicate which manifest in the repository was used to
build a particular project or for a particular test run?

How to reduce collisions for module name or module abbreviations?

How to support generating aggregate documentation (covering multiple
OOT modules and Zephyr)?

Alternatives
The option of addressing only this one example repository was
considered, but the first example will set de-facto standards
and precedence.  Ignoring scalability of the example was
considered too large of a risk to the project.
Options with fewer parallels were considered but that increased the
chance of inconsistencies across OOT modules, making the integration
effort more difficult.

I noticed two edits are needed in the RFC:

Proposal: module.yml defaults map to the Zephyr directory tree
placed at the location of the module.yml file.

For backwards compatibility module.yml defaults need to map to the directory above the one containing the module.yml file.

Concerns and Unresolved Questions

Add the following concern:

Especially for the guard #ifdef in include files, how should the naming pattern be extended to include the module abbreviation?

@gregshue @tejlmand @mbolivar-nordic @nashif @MaureenHelm @galak
Let's settle on the name first, I am not very happy with oot_module_example.
Here's a few proposals:

external-application-sample
oot-application-sample
oot-repo-sample
oot-project-sample
sample-oot-repo
sample-oot-project
sample-oot-application
example-external-application
example-external-module

Essentially, do we want to call this an application or a module? or something in-between? And also, is this a sample or an example?
I personally favor sample-oot-project because:

It uses a sample- prefix that we can reuse later to add more sample repos
I prefer sample to example personally, to be consistent with our samples/ folder
Using project covers both application and module

@carlescufi @tejlmand @mbolivar-nordic @nashif @MaureenHelm @mglb
Based on the description of this issue and the need to verify all out-of-tree mechanisms, this repository will eventually contain all the following as a clone-able and copy-able/rename-able boilerplate for user repositories:

Zephyr build, verification, analysis, and document generation hooks.
Example boards, DTS files, drivers, subsystems, provided APIs, stand-alone applications, tests, samples, with associated Kconfig files.
Multiple manifest files for easy configuration to the LTS, latest release, and latest versions of Zephyr.
An application directory tree containing multiple sub-directories (since a minimal application has no unique source but an empty main()).

It is never expected that this repo represents the only way to support modules. Rather, it provides a maintained template that may be copied onto an existing repository to extend it into a Zephyr module, and the changes tracked by users as Zephyr evolves.
Having worked through the preliminary versions (privately and publicly), this is no more or less of an application than zephyr is (since every sample and test is itself an application according to Zephyr documentation).  We are really dealing with an (OOT) extension plugging into the Zephyr build system. This seems closest to how Zephyr uses the term module, and it is well beyond the scope of how Zephyr uses the term application.
The term project is heavily overloaded already and already causing challenges in CMAKE variable naming. If we introduce project for a repository, then what will developers conclude when they hear the phrase "Zephyr Project"?
Without knowing the difference between a sample vs an example, I would prefer separate terms at the repository name vs a folder name.  (It will already be bad enough when we consider the zephyr repository being detected by the Zephyr build system as a module itself.  This would end up with the mounted file zephyr/zephyr/module.yaml.)

Please consider this also. At least one existing Zephyr module (Civetweb) is purely at the application layer, uses a communication protocol generally unsuitable to resource constrained devices (HTTP/S), and probably has Kconfig variables independent of the rest of the Zephyr tree. If it were to evolve into an OOT manifest+module (downstream of Zephyr instead of upstream), what would be the desired repository name with zephyrproject-rtos?

Hmm ... from here I found the following distinction between example vs sample:

2.One difference between the two concepts is in the purpose of their use. An example’s purpose is to illustrate or reinforce something. Examples are made to be followed and replicated. On the other hand, a sample is made to describe the quality and nature of something.

It seems this repository is scoped (and desired) to be an example, not just a sample.

@gregshue I read your comments and it seems like you don't like the name suggested by @carlescufi , but I don't see a concrete suggestion for a replacement. Did I miss one?

@mbolivar I had already suggested oot_module_example, which @carlescufi didn't like.
Since I had wrestled with this naming pattern issue before, I just wanted to pass along what I had already discovered. :-) What is most important to me is

meaningful, scalable pattern that fits with the rest of zephyrproject-rtos
clarity in written and spoken word

For clarity reasons I had avoided project, application, external, sample. and repo. It turns out that example fits the repository purpose and intended usage better than sample.
At this point we're really figuring out a repository naming scheme that scales well and makes sense.  :-)

OK, thanks :). I get it now. So summarizing where we are at on the naming:

@carlescufi proposes sample-oot-project
@gregshue proposes oot_module_example

I agree with @carlescufi that this is more than just a 'module'. Actually I find "OOT module" a bit redundant. A module, pretty much by definition, is out of tree.
I agree with @gregshue that 'project' is a bit of an overloaded term in general, but disagree in this context. In west terms, 'project' is a well-defined concept that captures what this issue describes making, and I don't have a more specific term in mind.
I don't have strong feelings about 'sample' vs 'example', but I lean softly towards 'sample' just because it keeps consistency with 'zephyr/samples', which for better or worse is what our example applications are inside.
So all in all I agree with @carlescufi 's proposal.

I'm surprised to hear this described as more than just a 'module'. What does this provide that is beyond the existing defined scope of an out-of-tree 'module'?
Though the west definition of 'project' maps cleanly to this, neither the CMake definition, Zephyr build variables PROJECT, nor the usage of "Zephyr Project" do. All of them are well defined concepts that need to be clearly managed and configured within this module scripts and files.
I wasn't aware of the difference between 'sample' vs 'example' until prompted by @carlescufi 's question. I know samples get referenced in documentation and maintained as part of the CI system, but samples are intentionally simplistic and short. These are necessarily much more complete to act as a boilerplate or templates of best practice coding patterns.
@mbolivar One point of clarification:  Zephyr already distinguishes between OOT and in-tree modules by where the glue code is located and managed.  An OOT module has the Kconfig & glue code outside the zephyr repository.  Either kind of module is always a repository external to zephyr even if it is hosted at zephyrproject-rtos.

Greg Shue<EMAIL_ADDRESS>writes:

I'm surprised to hear this described as more than just a 'module'.
What does this provide that is beyond the existing defined scope of an
out-of-tree 'module'?

It's not externally maintained, and it's a west manifest repository.

Though the west definition of 'project' maps cleanly to this,
neither the CMake definition, Zephyr build variables PROJECT, nor
the usage of "Zephyr Project" do.

This is restating the premise "the term 'project' is overloaded",
which is already granted.

All of them are well defined concepts that need to be clearly
managed and configured within this module scripts and files.

This doesn't seem to follow from the premise; does it?
What about including the word 'project' in the name of this git
repository prevents managing and configuring those things?

I wasn't aware of the difference between 'sample' vs 'example' until
prompted by @carlescufi 's question. I know samples get referenced
in documentation and maintained as part of the CI system, but
samples are intentionally simplistic and short. These are
necessarily much more complete to act as a boilerplate or templates
of best practice coding patterns.

I don't have a dog in this fight. Either is fine with me, slight
preference for consistency, like I said.

@mbolivar One point of clarification:  Zephyr already distinguishes
between OOT and in-tree modules by where the glue code is located
and managed.  An OOT module has the Kconfig & glue code outside the
zephyr repository.  Either kind of module is always a repository
external to zephyr even if it is hosted at zephyrproject-rtos.

To be honest, I don't agree, and I don't think any of the definitions
of "Zephyr module" in the
documentation
agree either.
"In-tree module" is an oxymoron in this context.

@mbolivar-nordic , perhaps I misunderstood the definition of a Zephyr 'module'.  Here are the things that led to my impression:

I noticed that samples/application_development/out_of_tree_driver/hello_world_module/zephyr/module.yml is part of the sample, and both out_of_tree and module caught my attention.

From the Application Development samples Out Of Tree Driver

... demonstrates custom zephyr drivers ... that are maintained outside of Zephyr.

From  modules.html (not in document order)

... if a module defines out of tree boards, ...

A module can be described using a file named zephyr/module.yml.

When a module has a module.yml file, it will automatically be included into the Zephyr build system.

In the context of Zephyr’s build system those [externally maintained projects] are called modules. These modules must be integrated with the Zephyr build system, ...

[ZEPHYR_EXTRA_MODULES environment variable] can be useful if you want to keep the list of modules found with west and also add your own.

There were other documentation statements that contradicted these. Given the existence of the OOT samples, references to modules defining out-of-tree boards, and the explicit directions on how to add modules of my own, I assumed the contradictory statements are simply out of date.
Terms and definitions are important for clear communication. What did I miss or misunderstand?

have been a bit busy, but let me give my comments.

Actually I find "OOT module" a bit redundant. A module, pretty much by definition, is out of tree.

I completely agree. I would like to avoid this term.

There were other documentation statements that contradicted these. Given the existence of the OOT samples, references to modules defining out-of-tree boards, and the explicit directions on how to add modules of my own, I assumed the contradictory statements are simply out of date.

yes, I guess this stems from the days where Zephyr was a single repo, and as such everything else was out-of-tree.
With the introduction, and especially the root extension, then I think we should try to cleanup the usage of out-of-tree.
Maybe use Zephyr module defined boards, and similar.

Terms and definitions are important for clear communication. What did I miss or misunderstand?

Completely agree. Sometimes features are introduced, but old terms stays around, even if they starts to be a bit imprecise.
So we should clear up those places.
As has also been discussed #28583, I believe it is better to refer to Zephyr module, and then reserve out-of-tree to something that is completely outside the Zephyr workspace (and maybe things not a Zephyr module).
For anything related to a Zephyr module, let's use the Zephyr module term
so my proposal on this:

@carlescufi proposes sample-oot-project

@gregshue proposes oot_module_example

would be:

zephyr-module-example

as it is an example of how a Zephyr module can be created.
If there will be more example repos, then they can be named accordingly, like zephyr-module-<topic>-example
but I would not prefix other Zephyr modules with this.
That is, hal_nordic, hal_stm32, etc should not be prefixed with zephyr-module-, because the fact that those repos are modules is not important.
What is important is their purpose, which is to provide hal code.
The purpose of:
zephyr-module-example is to showcase how a Zephyr module can be constructed, hence having zephyr-module in the name adds value to the understanding of what this repository does.

I can live with zephyr-module-example.
I suppose zephyr-manifest-example would be the name of a non-module repo that contained the west manifest file(s), top-level documentation, and project files (.prjconf, etc) that simply integrated all the Zephyr Project-hosted modules?  (I expect we will need this to verify that zephyr-module-example can be integrated by an external manifest/project.)

I expect we will need this to verify that zephyr-module-example can be integrated by an external manifest/project.

That's a good question.
Seen from educational point of view, then it would probably be easier to explain to user / easier to understand:

For Zephyr module example, look here: link A
For Zephyr manifest example, that is including A, look here: link B

but from build integration point of view, it technically doesn't matter if the Zephyr module is also a manifest repository.
Cause the build has no knowledge of the concept of a manifest file, it just get a list of projects to examine.

@carlescufi @mbolivar-nordic , Any input?

I think we will end up needing one repository of each of the following scopes in order to have appropriate test coverage. We should end up with a naming pattern that fits these scopes.

A non-module manifest repository containing manifest file(s), top-level documentation content and generation scripts, version information, release notes.  Possible names:

zephyr-example-manifest

A module only for projects integrating other modules downstream of zephyr, in addition to all the content of (1).  This would not contain any top-level CMakeLists.txt or Kconfig files, no include/ or subsys/ folders, and only tests for verifying multi-module integrations.  Possible names;

zephyr-example-module-integrations

A module that is an example of all the extension capabilities of a Zephyr module. This would contain all the files and content of (2) and also contain include/, subsys/, unit and subsystem tests, and boards.  Possible names:

zephyr-example-module

Thoughts?

@tejlmand @carlescufi I can't tell if discussion has stalled or come to a natural conclusion.  What else is needed to create the repositories and have them ready for PRs?

Is anyone else is working on this?
I would be happy to take a crack at it - need to do the same anyway for finishing the Greybus for Zephyr module.

At this point it is stalled waiting for alignment on the repository naming pattern, then for the empty repositories to get created to enable a PR with my draft content.
Feel free to look at it under my Github account and provide early feedback or comment in the eventual PR.

@cfriedt, I just looked at the Greybus for Zephyr staging branch. Before you release this to production you should look at https://github.com/gregshue/oot_module_example.

Ah, interesting - I'll take a look at that. I just hacked something together last night independently of the Greybus repo. It looks  similar-ish to yours with the exception that you have everything within the zephyr directory.
https://github.com/cfriedt/zephyr-example-module
I'll take a look at your repo as well.

Everything Zephyr-unique is kept beneath the zephyr/ subdirectory to allow extending any existing repository to also be a Zephyr module simply by copying this in and filling in the glue.  I already did that in the zephyr branch of https://github.com/bacnet-stack/bacnet-stack and migrated all the unit tests to ztest.  sanitycheck nicely ran with code coverage metrics.

Proposal for CI:

The west.yml in the external repo points to a release tag of zephyr, and the repo itself is only tested against that last release, on PR to the external repo. Who would be responsible for updating the external repo to the latest release when an -rc1` is tagged?
We integrate building the external repo in our on-PR CI in the main zephyr tree, by adding something similar to:

west init -m https://github.com/zephyrproject-rtos/zephyr-example-module
west update
west build app

Since we do not want the external repo to be part of upstream zephyr's west.yml (that would be "cheating"), we need to figure out a strategy of keeping the revision of the last known working external repo revision somewhere, or just testing the external repo master branch against zephyr's master branch.

My suggestion for a name would be either example-application or example-project

dev-review (Dec 17 2020):

Suggestion is to just have a "daily" ci in the new repo
Suggestion is that this repo is setup for multiple "applications"

@galak Right now the Zephyr directory tree structure has conf.prj files (arguably "applications") under tests and samples.  Would it make sense to add a parallel projects tree for non-test, non-sample conf.prj et. al., to live?

Is it appropriate for this repository to also be a regressive test case to verify that the west -m <> --mr <> and --mf <> options continue to work?

Just for illustration of the various use cases:

@nashif are the pictures where module A and module B appear in the zephyr manifest and the product manifest meant to show that those modules are imported, or that they are being overridden?
Also, just for reference, here is a table showing how different repositories that may be involved in the build can be set up and relate to the build system:

West project?
Zephyr module?
Notes or examples

N
N
Manually created application repository

N
Y
Set up via ZEPHYR_MODULES or ZEPHYR_EXTRA_MODULES

Y
N
Does NOT have zephyr/module.yml file or zephyr/CMakeLists.txt+zephyr/Kconfig files

Y
Y
DOES have zephyr/module.yml file or zephyr/CMakeLists.txt+zephyr/Kconfig files

@nashif are the pictures where module A and module B appear in the zephyr manifest and the product manifest meant to show that those modules are imported, or that they are being overridden?

via import, so they are in the zephyr project west yaml file.

oh, I think I should use different names :-)

oh, I think I should use different names :-)

fixed now.

Your pictures still show west projects in a different color than modules, but any repository can be either or both.

I still also see "west project A" in the picture for "a project (product tree) that is a zephyr module as well". It's still a cause for confusion for me. That could mean that the project west.yml overrides that project, or that it imported it.

Your pictures still show west projects in a different color than modules, but any repository can be either or both.

yes, modules can be shaded to signify they are also projects.

@nashif, Thank you for trying to describe this with a graphic.  I assume you are describing the roll of each repository in each use case rather than the capabilities of each repository (since Zephyr always has a manifest file even if it is not the one referenced in the west workspace.  Consider showing both what the repository contains and how it is used.
As I have worked with it, it is quite practical for every downstream module to also have a manifest file for each Zephyr fork it is verified against, and to use separate branches tracking different Zephyr versions.  Perhaps one of the downstream modules in each use case should be noted as manifest module being used as just a module?

As I have worked with it, it is quite practical for every downstream module to also have a manifest file for each Zephyr fork it is verified against, and to use separate branches tracking different Zephyr versions. Perhaps one of the downstream modules in each use case should be noted as manifest module being used as just a module?

if I understand you correctly, this is case (2)

Yes, and no.
When I am working on extending https://github.com/bacnet-stack/bacnet-stack to also be a Zephyr module, the bacnet-stack repository is Product XYZ in Case 2.  When I am integrating the bacnet-stack module into my product, the bacnet-stack is Module C in either Case 2 and Case 3 (whether or not any of bacnet-stack's manifest files are imported).
Part of the need for this new repository is to have a Zephyr Build System testcase for Case 2. Can we verify Module C in Case 2 is properly handled by the Zephyr Build System with only this repository and the Zephyr repository?

I think we will want to document this in terms of the source code topologies supported by west, and be a bit more explicit about module.yml files, DTS files, multiple projects, and Zephyr Project hosted repos vs external ones.  How about this?

Is it appropriate for this repository to also be a regressive test case to verify that the west -m <> --mr <> and --mf <> options continue to work?

Yes, CI for the new repo should do that

Is it appropriate for this repository to also be a regressive test case to verify that the west -m <> --mr <> and --mf <> options continue to work?

Yes, CI for the new repo should do that

https://github.com/zephyrproject-rtos/example-application/pull/1 submitted.

https://github.com/zephyrproject-rtos/example-application/pull/1 submitted.


[KO] Translation of Testing lesson

related: #201
I applied some feedbacks from @dalgona.
You can compare the trasnlated text with the original text at devleoper/elixir-school#1
This PR is ready for review. :rocket:

I mistyped a number of chapter on the commit message, please don't take care of them:oops:

@devleoper it's okay with me.  If for future reference you'd like to learn how to reword a previous commit message (using git rebase -i), I'd be help to walk you through it 😀

@doomspork Now I fixed the commit message. Thank you so much! I'm glad to use awesome things of git.

Great @devleoper!  Feel free to merge this whenever you're happy 👍

@doomspork Basic lessons are almost translated so I'm going to merge when all of the Basic lessons are translated (and reviewed). 😉

Sounds good @devleoper!


the fonts are getting blurred in web version.I feel it is not good

Duplicate of https://github.com/flutter/flutter/issues/32274


myriad small docs fixes

This PR fixes various typos, formatting issues, and broken links, focusing on the FAQ and the 1.2 docs. It isn't comprehensive but I wanted to get  this in as a milestone along the docs review process before I get further, as the diff's already getting large. I'm happy to discuss any of the changes here or on discord (sawtooth-contributors).
This also fixes #188 and fixes https://github.com/hyperledger/sawtooth-core/issues/2448.

Thanks! Looks great. One nit-pick on the commit messages - the project uses https://cbea.ms/git-commit/#seven-rules as the style guide. For example "fix(faq): fix formatting, links, grammar" -> "Fix faq formatting, links, grammar".


Realign process seems to freeze

After starting the Realign command, the terminal gives feedback (via progress bar) for about 15-20 minutes, and then freezes. The size of the temporary files also appears constant after this freeze occurs. The terminal view after the freeze looks like this:

Is this normal behavior?

Sorry, please disregard my earlier question. The program terminated after about 3 hours of processing. It wasn't frozen.
Very interesting program. Thanks.

Dear tchrisboles,
Thank you very much for using Circle-Map and your kind words.
Regarding your issue, this is a known behaviour. It occurs because in the current implementation, the amount of work is not evenly distributed across worker threads. Hence, some threads are processing way more data than others. In the end, this causes that some threads (in your case a single thread) keep processing data while the rest of the threads have already finish.
I have a working prototype that mitigates this problem by distributing the work more evenly across the threads. Furthermore, this prototype is much faster, due to just-in-time compilation of the core python functions of the program using numba.
The new prototype version is in testing phase and I plan to release it within the next couple of weeks. I have reopen this issue, and I will leave like this until I manage to release the new version if it is fine for you.
Thanks for the feedback and feel free to open a new issue in case you encounter any problem.
Best wishes,
Iñigo

Ok I look forward to the new version with more equitable thread distribution.
Do I close this issue or do you (I don't use github very often....?)?

Dear @tchrisboles,
Lets leave the issue open until I release the new version. As that would be the time when I have solve your specific issue.
Best,
Iñigo

Dear @tchrisboles,
I just released a new version of Circle-Map. The version v1.1.1 should address the problem you have observed. Furthermore, this version comes with a speed-up around 50%
To get the new version, you can install Circle-Map using pip or conda.
Best wishes,
Iñigo


[Tests] NFC: Un-XFAIL flow_isolation tests

Resolves: rdar://120849093

@swift-ci please test

@swift-ci please asan test

@swift-ci please ASAN test

preset=buildbot_incremental_asan,tools=RDA,stdlib=RDA
@swift-ci Please test with preset macOS Platform

ASAN had a lot of unrelated tests fail.


T anikda/experimental

The code changes made in this PR primarily revolve around implementing the logic to reorder the wavefunction. It also includes some supporting functions to implement this change. This reordering routine has been added as an effort to optimize the full-state native simulator.

@AniketDalvi
We should keep this on the feature branch until all the bits and pieces have been implemented. I retargeted the PR; could you please resolve the merge conflicts? Thanks!

For performance improvements it's super useful to have tangible numbers that highlight the problem and show the fix is working (and the situations when the fix might not be applicable). Do we have benchmarks for the scenarios you are addressing? Can they be checked-in alongside with your change?
The PR doesn't link to any issues -- is there an issue tracking this perf improvements? Please add benchmark results to this PR's description and to the issue (if it exists).

Without the understanding of the impact of the reordering in the case of multiple fused groups I don't feel comfortable pushing this code into production. If you must merge it, please consider adding a configuration switch that allows running it locally (e.g. with benchmarks) but doesn't enable the code for the end users yet. There are also still a few specific comments that haven't been addressed.
However, assuming you've discussed this with others, I don't want to block the PR so I'm changing my status to "Approve changes" (as there seems to be no way to remove my change request without approving). This doesn't indicate my sign off, though. Please seek a sign off from your lead and/or from the people you worked with on the design of this change.


Re-attach events when the DOM reloads. EG: on ajax pagination

When you load content through ajax (or pjax), and events are registered on elements inside that content. The events registered are not handled anymore. Because the previous DOM elements are 'destroyed'. The events should be re-attached on the DOM elements. A best practice is to attach the events on a global DOM element.
For Example:
<div id="content">
   <!-- this content will be changed with ajax //-->
</div>

Instead of attaching the events on the elements within the content, attach the events on the DOM element which will NOT be loaded or changed through ajax (in this case: #content, or sometimes: body).
$('#content').on('click', 'a', function(e){
    // here the logic when clicking on a link inside the `#content` div
});

I wouldn't necessarily say that the use of delegated events is a best practice - it very much depends on the situation. If it's a parent element that isn't too far up the DOM tree, then great. It gives you the advantage of not having to rebind events in ajax callbacks, and saves memory because you bind the event on one element rather than several.
But, a lot of people use this as a lazy solution by binding the event to the document. Relying on detecting events as they bubble up the DOM tree can cause a significant performance impact (delegated events bound to the document is what the jQuery .live function used to do, but the performance impact is why it was removed from the code base). Also, relying on these events bubbling up to the document level doesn't working on iOS. It only allows events on certain elements (namely anchors and buttons) to bubble up that far for performance reasons.
So this is a good point to make, but the performance impact needs to be considered.


Add support for Subsonic

Adding support for Subsonic. http://www.subsonic.org/pages/index.jsp
It's a media streamer uses JWPlayer.
Probably this is not the best way to do this, but it was the only way that I could get working.

@ALiangLiang
+1
I suggest one modification to ensure this also works for Madsonic (fork of Subsonic).  The Madsonic webplayer will have the same url matchers as the Subsonic webplayer.
function onKeyPress(key) {
  if (this.jwplayer) {
    if (key === NEXT) {

      // Subsonic impl
      var nextButton = document.querySelector('img[onclick="onNext(false)"]');

      // Madsonic impl
      if(!nextButton){
        nextButton = document.querySelector('a[onclick="onNext(false)"]');
      }

      simulateClick(nextButton);

    } else if (key === PLAY) {
      location.href = "javascript:window.jwplayer().play()";
    } else if (key === PREV) {

      // Subsonic impl
      var backButton = document.querySelector('img[onclick="onPrevious()"]');

       // Madsonic impl
      if(!backButton){
        backButton = document.querySelector('a[onclick="onPrevious()"]');
      }

      simulateClick(backButton);
    }
  }
}

Good idea! But I suggest you PR a independent Madsonic version. It's some differense between Subsonic and Madsonic. I think it's will more convenient to maintain.

Madsonic uses the exact same matchers as Subsonic in the manifest.json file so I cannot create a separate Madsonic entry as it would conflict with Subsonic.  Also, I doubt any of these pull requests will get merged by the repo owner anyway.  I just created a fork  that includes some of the less popular music players so people can have the option of installing this plugin in developer mode if they so choose.

Hello, thanks for your contribution!  Sorry for such a long wait, this project is now maintained by another, and we're now working on closing all issues and PRs as much as possible.  ;)  I tested this out and have had no issues with it, would you be willing to fix the conflicts with the manifest file before we accept your PR?


List of Supported Emojis

Where can I find a list of the supported emoji codes? I need to build an emoji keyboard for my app and need to know which emojis will be recognized. It seems most are but some are not.

It uses "node-emoji": "^1.5.1" internally so check out in this library what's available


mention user must checkout submodules

It seems that the behavior changed recently with the addition of a git submodule, and when I upgraded to tmux 2.5, it was broken until I realized to checkout the submodules. This wasn't documented.

Fixed on 0.6.3 with health-check, as well as documented on https://github.com/Morantron/tmux-fingers/blob/master/docs/health-check.md#submodules-not-initialized-properly


Python interface

Have you a Python binding?
Not totally comfortable with JS at the moment.
Have also been using Google speech apis (gRPC version) for live streaming recognition on Raspbian.
It does work and I have written it all in Python but cannot do the wake word yet.
Cheers

I've been considering a python library (and setting up pip), but I'm working on Node first to work out any kinks. I've experimented with the Python gRPC before it was released to the public and there were a few strange bits that weren't working (I'm assuming that since then it's been ironed out).
If you want to take a stab at the interface with a working gRPC and send a PR I'd be happy to add wake word detection.


needs update for string.data changes

After JuliaLang/julia#19449, soon to be merged for Julia 0.6, you will no longer be able to access the raw bytes of a string via string.data; instead, do Vector{UInt8}(string).  For example, this affects:
https://github.com/nalimilan/StringEncodings.jl/blob/e6fd1bfa601a66207afc3061c479678548dd227f/deps/build.jl#L21

Thanks for the notice. See https://github.com/nalimilan/StringEncodings.jl/pull/13.


ObjectExtractor could implement java.io.Closeable

It would be nice if technology.tabula.ObjectExtractor implemented the standard interface java.io.Closeable, since this would work nicely with Java's try-with-resources feature, and similar features in other JVM languages, such as Kotlin's use function.
IDEs or other tools sometimes warn when you fail to close a Closeable object, so this might help to save a resource leak too.

Good suggestion, @seanf. Thanks.
Just implemented it in a6c322e


DEFAULT_PATH_LEAF_TO_NULL did not work with $..path(deep scan)

like the following json
[
{
"name" : "john",
"gender" : "male"
},
{
"name" : "ben"
}
]
when I set DEFAULT_PATH_LEAF_TO_NULL and used $..gender，I got ["male"] ，(["male", null] is expected). how I can get expected value?
Thank you!

It does actually return ["male", null] on http://jsonpath.herokuapp.com/.

I think this can be closed.


Adjust the name of the published artifacts

See: https://electron-builder.slack.com/archives/C3X4YCA14/p1510670327000372


Create record version

This closes #55.

@ldko @somexpert This is ready for review.

@gracieflores Could you also update the CHANGELOG?


Promise returned by getToken fails to reject when getToken passed invalid authorization code

Environment details

OS: macOS 10.13.6
Node.js version: v8.11.3
npm version: 6.7.0
googleapis version: 20.2.0
google-auth-library version: 0.10.0

Steps to reproduce
Run the following program:
'use strict';

const fs = require('fs');
const google = require('googleapis');
const oauth2Client = new google.auth.OAuth2(/* [VALID CREDENTIALS REDACTED ] */);

(async function() {
  // Case 1: fails to throw.
  try {
    const tokens = await oauth2Client.getToken('invalid');
  } catch (err) {
    console.log('ERROR1:', err);  // Never invoked.
  }

  // Case 2: calls callback with truthy err value, as expected.
  oauth2Client.getToken('invalid', (err, tokens) => {
    if (err) {
      console.log('ERROR2:', err);  // Invoked.
    }
  });
})();

Both calls to getToken fail because the authorization code is invalid.  The second one correctly results in console.log('ERROR2:'… being invoked, but the first one fails to call console.log('ERROR1:'….

Greetings @cpcallen!  I am having trouble reproducing this one.  Just to give a more complete script, this is what I'm trying:
'use strict';

const {OAuth2Client} = require('google-auth-library');
const keys = require('./oauth2.keys.json');
const client = new OAuth2Client(
  keys.web.client_id,
  keys.web.client_secret,
  keys.web.redirect_uris[0]
);

async function main() {
  const tokens = await client.getToken('rubbish');
  console.log(tokens);
}

main().catch(console.error);

I get an exception like this:
{ Error: invalid_grant
    at Gaxios.<anonymous> (/Users/beckwith/Code/ttt/node_modules/gaxios/build/src/gaxios.js:72:27)
    at Generator.next (<anonymous>)
    at fulfilled (/Users/beckwith/Code/ttt/node_modules/gaxios/build/src/gaxios.js:16:58)
    at processTicksAndRejections (internal/process/task_queues.js:86:5)
  response:
   { config:
      { method: 'POST',
        url: 'https://oauth2.googleapis.com/token',
        data:
   ...

Can you try this with the latest googleapis and latest google-auth-library and see what happens?

O.K., it appears that this was fixed sometime between 20.2.0 and 39.1.0, and I've wasted your time with an outdated bug report despite my best efforts because, contrary to expectations npm upgrade doesn't actually do what it says on the tin.  TIL but WTF.

All good :) Happy to hear it's working!

Not sure why this has been assigned to me now.  As I noted almost two years ago, it appears to have been previously fixed.
I'm unassigning this for now, but feel free to reassign it to me (with an explanation) if there is some reason it really does need my attention.


feat: generate keys when extension is installed

Context

Closes #92.
Changes proposed in this pull request

Whenever the extension is installed, the key pair is generated, alongside a key ID:

public key is stored as a base64 encoded JWK
private key is stored as hex
key id is stored as a string (UUID v4)

Extension builds preview

Name
Link

Latest commit
4d186d5051226172eeb2428ad61d5c51affe4abb

Latest job logs
Run #7867707839

DownloadDownloadDownloadDownload


Include splunk-otel-dotnet in auto-instrumentation deb/rpm packages

Similar to splunk-otel-java and splunk-otel-js, include splunk-otel-dotnet in the auto-instrumentation deb/rpm packages (amd64/x86_64 only)
Add default config files for systemd and libsplunk with the required env vars
Update tests to verify manual installation and basic instrumentation with a sample .NET app
Add gitlab job to update splunk-otel-dotnet to the latest release (similar to how we already update splunk-otel-java and splunk-otel-js)

TODO: Update installer script and deployment modules after these changes are released.

Q.: why is it necessary to add libicu?

libicu seems to be required by the sample .NET app used in these tests. Otherwise, it fails with:
Couldn't find a valid ICU package installed on the system. Please install libicu using your package manager and try again. Alternatively you can set the configuration flag System.Globalization.Invariant to true if you want to run with no globalization support. Please see https://aka.ms/dotnet-missing-libicu for more information.

So I just install libicu in the test images rather than mucking with the sample app.


Migrate tests and console demo app to .NET 7

Migrate tests and console demo app to .NET 7
This is:

[ ] a bug fix
[x] an enhancement

Related issue: #70
Description
This pull request:

Changes the target framework for VersOne.Epub.ConsoleDemo project from .NET 6 to .NET 7.
Updates all GitHub actions to use .NET 7 instead of .NET 6 or .NET 7 preview.

Testing steps
Build and test actions should pass.

This needs to wait until the windows-2022 GitHub action runner image gets Visual Studio 17.4.


[Event Request] Page 402 - Sales Order Statistics - OnAfterUpdateHeaderInfo

Hi AL team,
please add the following parameters to the event OnAfterUpdateHeaderInfo:
<<<Old
[IntegrationEvent(true, false)]
local procedure OnAfterUpdateHeaderInfo()
>>>

<<<New
local procedure OnAfterUpdateHeaderInfo(var TotalSalesLineLCY: array[3] of Record "Sales Line";
var IndexNo: Integer)
>>>

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability.


Runtime error when calling msg.loading("..")

I run into the following error when trying to run a simple sample snippet using msg.loading with wasabi
RuntimeError:
        An attempt has been made to start a new process before the
        current process has finished its bootstrapping phase.

        This probably means that you are not using fork to start your
        child processes and you have forgotten to use the proper idiom
        in the main module:

            if __name__ == '__main__':
                freeze_support()
                ...

        The "freeze_support()" line can be omitted if the program
        is not going to be frozen to produce an executable.

Here's the code snippet being executed:
from time import sleep
from wasabi import msg, Printer

msg = Printer()
msg.good("Starting")
msg.warn("Warning")
with msg.loading("Loading.."):
    sleep(3)
msg.good("done")

Python Version Information:
Python 3.8.5 (default, Sep 27 2020, 15:45:15)
[Clang 9.0.0 (clang-9<IP_ADDRESS>)] on darwin

wasabi version: 0.8.2
Would be happy to provide any additional info on this. Thanks! :)

Tested and can confirm that's true on my end too.

If you follow the instructions, it will work, however:
Wrap your code in a main function, like so:
from time import sleep
from wasabi import msg, Printer

if __name__ == '__main__':
    msg = Printer()
    msg.good("Starting")
    msg.warn("Warning")
    with msg.loading("Loading.."):
        sleep(3)
    msg.good("done")

Great, thanks! Wrapping my code in main seems to do the trick.


Scroll speed twice faster on Firefox

monaco-editor version: 0.20.0
Browser: Firefox 73
OS: Debian
Tested on several computers (always Linux).
On a Monaco-Editor (eg https://microsoft.github.io/monaco-editor/ ), when I scroll down with the mouse, it scrolls down by 4 lines at a time on Chrome but it's 8 lines at a time on Firefox (which is obviously too fast).

@alexdima it's not a Feature request, it's a bug report.

I confirm that the pull request https://github.com/microsoft/vscode/pull/95967 fixes my issue. Thanks a lot CGNonofr!

There is another aspect to this issue:
Because mouse wheel scrolling is so slow in Firefox by default, a common practice is to increase mousewheel.default.delta_multiplier_y from 100 to something higher (I'm using 500) in the profile settings. Apparently this gets incorporated into the equation currently, which results in crazy mouse scrolling speeds: For me, a single mouse tick scrolls several screen pages.
If the Monaco editor chooses to go for a high default anyway it should ignore any "scrolling speed up settings" to avoid crazy results. Alternatively the default would have to be as slow as default scrolling to lead to similar scrolling speeds.
Some numbers: At delta_multiplier_y 100, scrolling on a normal page is 2 cm on screen. Accordingly, changing it to 500 makes it 10 cm, which works good for whole page contents.
In the Monaco editor the default scroll tick is already ~ 5 cm on screen. Incorporating the multiplier makes it 25 cm, which is simply not usable. Even for whole page scrolling that would be a lot, but the problem gets worse if the editor is embedded into a div of reduced height. Often a single mouse wheel tick can turn into "three pages down".
@CGNonofr Does #95967 already account for that?

With or without my changes, delta_multiplier_y is taken into account. All my PR is doing is making the scroll slower on firefox (by 16/50) which makes, by default, the scroll as fast in Firefox and Chrome. (While removing magic numbers from the code: the 16px comes from firefox defaults, and the 50 is the value by which the result is multiplied in another file, but unfortunately not exported => https://github.com/microsoft/vscode/blob/a7c698ce0c64b6ee83d43fbd7d986df461a1306f/src/vs/base/browser/ui/scrollbar/scrollableElement.ts#L22)

I cannot reproduce this on a mac. I'm trying https://microsoft.github.io/monaco-editor/ with an external mouse with a physical mouse wheel and I'm doing one scroll "flick"

Firefox 81.0b7

Chrome 85.0.4183.83


Bad displaying when run yarn

[x] I am on the latest Hyper.app version
[x] I have searched the issues of this repo and believe that this is not a duplicate (hopefully)

OS version and name: Windows 10 (Microsoft Windows v10.0.15063)
Hyper.app version: Latest - 1.4.2
Link of a Gist with the contents of your .hyper.js: Click Here
The issue is reproducible in vanilla Hyper.app: It exist in vanilla

Issue
When I run yarn or yarn add or whatever the "'Loading dots'" are big and they cover a part of the previous line. This isn't very important issue, but I believe that Hyper will look better after fix...

Any updates? @rauchg

Hey there, please try again with the new Hyper v2 release and open a new issue if the problem stills exists. Thank you!


Create LICENSE.txt

Still need a second review of this PR

@OpenLXP/contributors we need one more review of this PR in order to merge -- @micson-us has provided one.

duplicate, covered within the 'feature/dau-es-ingest' PR