init: specify dependencies between init entries

Introduce a mechanism to specify dependencies between struct init_entry instances, which includes both SYS_INIT macros and struct device instances. This allows code to specify that devices depend on a certain SYS_INIT instance, or vice-versa.
Removes the old, undocumented, unused mechanism of injecting dependencies to devices via devicetree ordinals.
Being able to specify dependencies between all init entries is progress towards https://github.com/zephyrproject-rtos/zephyr/issues/22545 and https://github.com/zephyrproject-rtos/zephyr/issues/34518

Sorry, a few days late getting to this.  I hate to say it, but this hits my -1 threshold absent someone convincing me that this is really the best way to do this.  It seems like a half solution that we're going to regret.
Putting the dependencies into the init records seems clumsy (there's no "object" with a "name" in the API) when what we really want is to track dependenciues between devices (which are objects and do have clear names) anyway.  Basically, no one asked for SYS_INIT() dependency management, and this seems complicated to me.
And I especially don't like that it's putting those dependencies into the runtime image, when by definition the order is going to be invariant at runtime (they're SYS_INIT calls, they can only depend on build state because nothing has run yet!).
Can't we structure this as a "compiler" or something that takes a set of SYS_INIT() calls (or some other intermediate) and a device tree (or similar representation) and just "sorts" it correctly?
(Or if we absolutely must have runtime-inspectable dependency data, let's at least make sure it's identical with whatever we need on struct device, because as I see this we'd end up storing the same info twice.)

This is technically an API breaking change.  Not sure if anyone was aware or using this API, since I didn't even realize you could do the old behavior.

Putting the dependencies into the init records seems clumsy (there's no "object" with a "name" in the API) when what we really want is to track dependenciues between devices (which are objects and do have clear names) anyway. Basically, no one asked for SYS_INIT() dependency management, and this seems complicated to me.

The reasoning in my head is that #22545 essentially requires that the (LEVEL,PRIORITY) pair provided to DEVICE_DEFINE is ignored/removed. Personally, managing these pairs for SYS_INIT macros is no nicer or easier than doing so for DEVICE_DEFINE. If there was a mechanism to say "Don't run SYS_INIT(mcumgr) until DEVICE(lf_clock) and SYS_INIT(system_workqueue) are initialized", then (LEVEL,PRIORITY) could be removed entirely (pending the build system correctly ordering the init entries). I haven't seen anyone disagree with this high level goal in the various PRs and issues I read, but maybe I'm looking in the wrong places.

And I especially don't like that it's putting those dependencies into the runtime image, when by definition the order is going to be invariant at runtime (they're SYS_INIT calls, they can only depend on build state because nothing has run yet!).

The init entry dependencies are only present in the image created in the first linker pass, and discarded afterwards. No increase in final image size should be possible. There is no runtime ability to query which SYS_INIT calls another entry depends on.

Can't we structure this as a "compiler" or something that takes a set of SYS_INIT() calls (or some other intermediate) and a device tree (or similar representation) and just "sorts" it correctly?

That is future steps from this PR.

Make SYS_INIT instances globally visible (like devices) so they can be referenced by other code
Provide a way for headers to declare the SYS_INIT calls they run
Add dependency information to existing SYS_INT and DEVICE_DEFINE calls

At this point elf_parser.py has all the information it needs to generate the order that everything should be initialised in, minus some edge cases (current transition from PRE_KERNEL to KERNEL).

(Or if we absolutely must have runtime-inspectable dependency data, let's at least make sure it's identical with whatever we need on struct device, because as I see this we'd end up storing the same info twice.)

It's not runtime, but by definition the information in this PR is identical with the struct device information because both devices and SYS_INIT use the same structure.

The reasoning in my head is that #22545 essentially requires that the (LEVEL,PRIORITY) pair provided to DEVICE_DEFINE is ignored/removed. Personally, managing these pairs for SYS_INIT macros is no nicer or easier than doing so for DEVICE_DEFINE. If there was a mechanism to say "Don't run SYS_INIT(mcumgr) until DEVICE(lf_clock) and SYS_INIT(system_workqueue) are initialized", then (LEVEL,PRIORITY) could be removed entirely (pending the build system correctly ordering the init entries). I haven't seen anyone disagree with this high level goal in the various PRs and issues I read, but maybe I'm looking in the wrong places.

To expand on this point, its not just that managing priorities for SYS_INIT is annoying as well. The current solution allows for sequencing devices relative to SYS_INIT and the opposite, and therefore any updated solution also needs to support this. This cannot be resolved without a way of linking init entries to each other, as done in this PR.

Putting the dependencies into the init records seems clumsy (there's no "object" with a "name" in the API) when what we really want is to track dependenciues between devices (which are objects and do have clear names) anyway. Basically, no one asked for SYS_INIT() dependency management, and this seems complicated to me.

The reasoning in my head is that #22545 essentially requires that the (LEVEL,PRIORITY) pair provided to DEVICE_DEFINE is ignored/removed. Personally, managing these pairs for SYS_INIT macros is no nicer or easier than doing so for DEVICE_DEFINE. If there was a mechanism to say "Don't run SYS_INIT(mcumgr) until DEVICE(lf_clock) and SYS_INIT(system_workqueue) are initialized", then (LEVEL,PRIORITY) could be removed entirely (pending the build system correctly ordering the init entries). I haven't seen anyone disagree with this high level goal in the various PRs and issues I read, but maybe I'm looking in the wrong places.

I agree here. Any solution needs to consider SYS_INIT; otherwise we'll just remove the headache from devices and actually make things worse. How to decide what runs first? Devices or sys_inits? If we just remove priorities from devices, there'll be no way to make such a decision. We have a lot of sys_inits that depend on devices being initialized first (see in boards/), but we also have some others that need to be called at early stages of the boot process before devices come in (see in soc/). IMO, everything that is automatically initialized has to be part of the solution.
One feature I could think of sys_init is to add the capability of creating groups so that you can impose dependencies on a particular group of sys_inits being called first, instead of doing it on a per-sys_init basis. But not sure if feasible/useful at this stage.

This is getting bikesheddy.  But... no, this isn't the right way to do this.  SYS_INIT() is not what you'd call a "good" application API.  But it is a simple API and it's easy to tell what it's doing.  If you have things running out of order you can look at zephyr.map to see the array and check what is running when, then ask "why is this here?" and move it.
This API doesn't have that property.  It has relatively more complicated behavior and semantics that.... don't actually match what applications want!  I repeat again, no one asked for this.  What apps want is device dependencies.  Let's give them device dependencies.
If we can implement device-ordered initialization on top of the existing SYS_INIT array, that seems ideal to me.  If we need to do it via separate callbacks (e.g. have PRE_KERNEL_1 devices initialized underneath a single SYS_INIT function that runs with minimum priority at the end of the list, something like that), that seems fine to me.
But let's not pollute simple/obvious things at the bottom of the kernel with requirements that stem from complications much higher up in the abstraction stack.

This is getting bikesheddy. But... no, this isn't the right way to do this. SYS_INIT() is not what you'd call a "good" application API. But it is a simple API and it's easy to tell what it's doing. If you have things running out of order you can look at zephyr.map to see the array and check what is running when, then ask "why is this here?" and move it.
This API doesn't have that property. It has relatively more complicated behavior and semantics that.... don't actually match what applications want! I repeat again, no one asked for this. What apps want is device dependencies. Let's give them device dependencies.
If we can implement device-ordered initialization on top of the existing SYS_INIT array, that seems ideal to me. If we need to do it via separate callbacks (e.g. have PRE_KERNEL_1 devices initialized underneath a single SYS_INIT function that runs with minimum priority at the end of the list, something like that), that seems fine to me.
But let's not pollute simple/obvious things at the bottom of the kernel with requirements that stem from complications much higher up in the abstraction stack.

So then, considering we remove init priorities from devices (no control) how do you decide what runs first? sys inits? devices?

My (vague) proposal would be to associate an init level (e.g.  PRE_KERNEL_1, APPLICATION, etc...) with a device, with no priority.  Each device gets its init function called at the end of the relevant SYS_INIT level (i.e. all "normal" init functions run first, so that devices can depend on legacy initialization), in an order that respects dependencies (and with some compile-time checking to be sure that devices don't depend on devices in later levels).
Then the python script enumerates the device DAG at build time and emits a sys init array that follows the rules, with no changes to API or runtime code needed.

My (vague) proposal would be to associate an init level (e.g. PRE_KERNEL_1, APPLICATION, etc...) with a device, with no priority. Each device gets its init function called at the end of the relevant SYS_INIT level (i.e. all "normal" init functions run first, so that devices can depend on legacy initialization), in an order that respects dependencies (and with some compile-time checking to be sure that devices don't depend on devices in later levels).
Then the python script enumerates the device DAG at build time and emits a sys init array that follows the rules, with no changes to API or runtime code needed.

There are many SYS_INIT that depend on devices being ready (see e.g. boards/), meaning on such systems we'd need a kind of sys_init -> devices -> sys_init init chain. Not saying that all boards are doing the right thing, but some use cases seem legitimate and can't be ignored.

Bare drivers (i.e. init calls) having "dependencies" is the problem being solved by devices in the first place, though!
If we have a function that needs to know a particular device is operating before being called, let's turn it into a device[1] where we can express that dependency explicitly.  Let's not complicate the system initialization API to make it do something we already created an abstraction to fix.
[1] Mapping a SYS_INIT() to a tiny stub device is trivial, and IMHO an easier task than using this new API.

Bare drivers (i.e. init calls) having "dependencies" is the problem being solved by devices in the first place, though!
If we have a function that needs to know a particular device is operating before being called, let's turn it into a device[1] where we can express that dependency explicitly. Let's not complicate the system initialization API to make it do something we already created an abstraction to fix.
[1] Mapping a SYS_INIT() to a tiny stub device is trivial, and IMHO an easier task than using this new API.

I'm not sure devices are either the best solution because:

Creating devices means more resources (struct device) for nothing. SYS_INITs are single-shot calls, which means at least device.{api, data, pm} == NULL, and some other fields like name are pointless.
Dependencies will only be solved if using DT-based devices. Using DEVICE_DEFINE will still require capturing dependencies manually (same as SYS_INIT)

I'm convinced that many cases can be solved by having better driver support (and they should be fixed properly), but some will be trickier and should not block progress.

Can you call out a specific issue here?  Like, what's the init call that can't be supported with the existing API and that would be an intolerable hardship to express as a device?

Can you call out a specific issue here? Like, what's the init call that can't be supported with the existing API and that would be an intolerable hardship to express as a device?

First, using devices is possible, question is if it adds any value in certain scenarios. By devices, I mean any kind of device, DT (DEVICE_DT_DEFINE) and non-DT (DEVICE_DEFINE). When using non-DT devices, you're like in SYS_INIT on your own with dependencies.
Take for example https://github.com/zephyrproject-rtos/zephyr/blob/main/samples/boards/nrf/dynamic_pinctrl/src/remap.c. The init sequence needs to be GPIO -> SYS_INIT(remap_pins_init) -> UART. Can I use DT devices here? No. Assuming we live in a priority-less world, I'd need something like:
SYS_INIT_NAMED(remap_pins, remap_pins_init);
SYS_INIT_AFTER_DEVICE(remap_pins, DEVICE_DT_NAME_GET(DT_NODELABEL(gpio0)));
SYS_INIT_BEFORE_DEVICE(remap_pins, DEVICE_DT_NAME_GET(DT_NODELABEL(uart0)));

If using devices:
DEVICE_DEFINE(remap_pins, "remap_pins", remap_pins_init, NULL, NULL, NULL, NULL);
DEVICE_INIT_AFTER_DEVICE(remap_pins, DEVICE_DT_NAME_GET(DT_NODELABEL(gpio0)));
DEVICE_INIT_BEFORE_DEVICE(remap_pins, DEVICE_DT_NAME_GET(DT_NODELABEL(uart0)));

(more verbose, uses more memory)

Isn't that kind of a weird app, though?  It's demonstrating a "dynamic" pinctrl API by... hooking PRE_KERNEL_1 init calls?  I guess the idea is to have some kind of "hold this button at boot" state change, so it tries to squeeze in a call between to very (!!) early drivers to fool the UART into using a different input source[1].
Seems to me like that's exactly the kind of trickery where we should be tolerant of some API weirdness and/or inefficiency.
I'll be honest: I'm still not seeing it.  This is taking a dead-simple API at the bottom of the kernel and significantly complicating it for the benefit of apps that... just don't seem to need it?   Again, if this was implemented as a "compiler" on top of existing SYS_INIT(), I don't think I'd have bothered with the -1.  But it's not, it's going in and changing the straightforward API, mostly needlessly.  And to repeat for the third time: if we want a data structure that tracks dependencies between "things initialized at system startup", we already have one!  We just need to make it work.
[1] Though even then: why is there a dependency here?  You could just as easily do this trick after the UART was initialized and just reset the device at the start of main() before reading bytes, right?

Sorry.  I appreciate the effort.  I recognize the desire.  I just don't think it belongs here.  Please implement a compiler on top of the existing init call layer if we really need this.
And I continue to strongly recommend that we have only one mechanism for tracking initialization dependencies and not two, but the device model is out of my -1 space.

Sorry. I appreciate the effort. I recognize the desire. I just don't think it belongs here. Please implement a compiler on top of the existing init call layer if we really need this.
And I continue to strongly recommend that we have only one mechanism for tracking initialization dependencies and not two, but the device model is out of my -1 space.

That doesn't really provide a solution, so I fear we'll be stuck for a few more years with init priorities.

That doesn't really provide a solution,

Implementing this API as a library (really just a precompiler) on top of the existing sys init mechanism seems very doable to me?  And I have very limited authority to NAK changes in lib/os. :)
Think of this as me trying to territorially protect a bottom-layer API deep under the kernel and trying to prevent pollution from the ever-increasing complexity higher up the stack.  As extra evidence, note that SYS_INIT() is one of the very few Zephyr APIs we allow when CONFIG_MULTITHREADING=n.  Do we really want those apps to be inflicted with this?

Btw, another example:
https://github.com/zephyrproject-rtos/zephyr/blob/main/boards/arm/arduino_nano_33_ble/arduino_nano_33_ble-common.dtsi#L87
Devices connected to the I2C bus can't operate without enabling the pull-up (don't tell me why they thought this was a good idea). The pull-up needs to be initialized after GPIO and before any I2C device (e.g. a sensor). So, again, we need something like GPIO -> SYS_INIT() -> I2C devices.

This could be solved using regular device inter-dependencies by adding a pull-up-enable-gpios (or similar named) property to the I2C controller devicetree node.

That doesn't really provide a solution,

Implementing this API as a library (really just a precompiler) on top of the existing sys init mechanism seems very doable to me? And I have very limited authority to NAK changes in lib/os. :)

I'd like to see some more details on the precompiler idea. It'd help to make some progress.

Think of this as me trying to territorially protect a bottom-layer API deep under the kernel and trying to prevent pollution from the ever-increasing complexity higher up the stack. As extra evidence, note that SYS_INIT() is one of the very few Zephyr APIs we allow when CONFIG_MULTITHREADING=n. Do we really want those apps to be inflicted with this?

Why would init order conflict with CONFIG_MULTITHREADING=n? We're just talking about sorting init order calls based on dependencies instead of manually crafted priorities (which need to encode dependencies...)

Btw, another example:
https://github.com/zephyrproject-rtos/zephyr/blob/main/boards/arm/arduino_nano_33_ble/arduino_nano_33_ble-common.dtsi#L87
Devices connected to the I2C bus can't operate without enabling the pull-up (don't tell me why they thought this was a good idea). The pull-up needs to be initialized after GPIO and before any I2C device (e.g. a sensor). So, again, we need something like GPIO -> SYS_INIT() -> I2C devices.

This could be solved using regular device inter-dependencies by adding a pull-up-enable-gpios (or similar named) property to the I2C controller devicetree node.

That's indeed a solution, but requires modifying controller code, not sure if worth to cover one case. If we need to fix all such cases in-tree to get automatic priorities, I think it'll take a long time to get this feature in. I'd rather introduce a mechanism that allows to keep the same existing behavior and document clearly when it should/not be used.

no one asked for SYS_INIT() dependency management

I will.  This is not limited to drivers.  The same issue exists across all components in all modules. Years ago I recognized the problem of lacking general initialization dependency management. I just haven't raised awareness of the issue.

This is taking a dead-simple API at the bottom of the kernel and significantly complicating it for the benefit of apps that... just don't seem to need it?

The "apps" need it too, especially when looking at mechatronic devices.

Can't we structure this as a "compiler" or something that takes a set of SYS_INIT() calls (or some other intermediate) and a device tree (or similar representation) and just "sorts" it correctly?

The initialization order depends on information not available in the SYS_INIT() calls and device tree files (e.g., which subsystems does this subsystem call?).  I like the "compiler" idea.  It just needs more dependency information to sort it correctly.  In addition, it would be very beneficial to also push long-duration init calls (e.g., running Settings storage integrity check) as early in the process as possible.

no one asked for SYS_INIT() dependency management

I will. This is not limited to drivers. The same issue exists across all components in all modules. Years ago I recognized the problem of lacking general initialization dependency management. I just haven't raised awareness of the issue.

We need zephyrd 😉

An alternate solution to this problem:
Since there is only one instance of a subsystem, it is referenced by a unique name, and it is needed by all instances of a specific type of driver, say all zephyr,gpio instances depend on zephyr,pinmux subsystem, this binding could be made in a YAML file instead of using the rather complicated elf_parser / gen_handles scripts.
Using this example dependency problem GPIO -> SYS_INIT(remap_pins_init) -> UART
/ {
  &gpioa {
    compatible="zephyr,gpio";
  };
  &uart1 {
    compatible="zephyr,uart";
    tx
  };
};

The devicetree is able to determine that the UART depends on the GPIO if used correctly, from this dependency, the ordinals would be ordered with gpioa before uart1. However, the subsystem remap_pins is hidden from the devicetree, since it is just a piece of code, not directly tied to hardware (otherwise, it should be a node in the devicetree, and there would be no issue here).
In the YAML for the "zephyr,gpio" compatible, we could list this dependency:
compatible: "zephyr,gpio"
depends-on: "remap_pins"

Now, a parser can combine the devicetree data from edtlib and the explicit bindings contained in the "software" bindings files to inject the dependencies into the ordinals, from which a complete list in init order can be created, which incorporates both devices and sys_inits.
before injecting sys dependency:
dts_ord_0 (gpioa)
dts_ord_1 (uart1)

after injecting sys dependency:
init_ord_0 (gpioa)
init_ord_0 (gpioa)

Since there is only one instance of a subsystem,

This assumption does not scale, is not valid downstream.  The init solution must be able to handle multiple instances of any arbitrary component or driver.

An alternate solution to this problem:
Since there is only one instance of a subsystem, it is referenced by a unique name, and it is needed by all instances of a specific type of driver, say all zephyr,gpio instances depend on zephyr,pinmux subsystem, this binding could be made in a YAML file instead of using the rather complicated elf_parser / gen_handles scripts.
Using this example dependency problem GPIO -> SYS_INIT(remap_pins_init) -> UART
/ {
  &gpioa {
    compatible="zephyr,gpio";
  };
  &uart1 {
    compatible="zephyr,uart";
    tx
  };
};

How does this DT snippet solve the problem? I can't see any dependency chain between gpioa/uart1 (e.g. being a child or referencing phandle).

The devicetree is able to determine that the UART depends on the GPIO if used correctly, from this dependency, the dts ordinals would be ordered with gpioa before uart1. However, the subsystem remap_pins is hidden from the devicetree, since it is just a piece of code, not directly tied to hardware (otherwise, it should be a node in the devicetree, and there would be no issue here). In the YAML for the "zephyr,gpio" compatible, we could list this dependency:
compatible: "zephyr,gpio"
depends-on: "remap_pins"

Bindings are really the schema for DT, nothing else. This proposal means bindings would vary depending on the application being built. So, I think dependencies don't fit in the bindings space.

How does this DT snippet solve the problem? I can't see any dependency chain between gpioa/uart1 (e.g. being a child or referencing phandle).

A more complete picture
/ {
    pinctrl {
      compatible="zephyr,pinctrl";
      gpioa {
        compatible="zephyr,gpio";
      };
   };
};

&uart {
  compatible="zephyr,uart";
  location-rx <gpioa 1, ...>;
  location-rx <gpioa 2, ...>;
}

Bindings are really the schema for DT, nothing else. This proposal means bindings would vary depending on the application being built. So, I think dependencies don't fit in the bindings space.

The software bindings are tied to compatibles, just like dts/bindings, they will not vary by application. These extra software bindings files bind Zephyr specific meta data to devices in the devicetree, like what api they support and other future Zephyr specific properties a device might have.

How does this DT snippet solve the problem? I can't see any dependency chain between gpioa/uart1 (e.g. being a child or referencing phandle).

A more complete picture
/ {
    pinctrl {
      compatible="zephyr,pinctrl";
      gpioa {
        compatible="zephyr,gpio";
      };
   };
};

&uart {
  compatible="zephyr,uart";
  location-rx <gpioa 1, ...>;
  location-rx <gpioa 2, ...>;
}

Bindings are really the schema for DT, nothing else. This proposal means bindings would vary depending on the application being built. So, I think dependencies don't fit in the bindings space.

The software bindings are tied to compatibles, just like dts/bindings, they will not vary by application. These extra software bindings files bind Zephyr specific meta data to devices in the devicetree, like what api they support and other future Zephyr specific properties a device might have.

The snippet shown above implies UART driver uses gpioa (it has some physical connection with it), however, in the pinctrl sample this is not really the case. It's basically re-routing UART pins at runtime based on user input (gpioa), so the UART code stays unchanged. On Linux, you'd probably do that at bootloader time by choosing one or another dtb (or overlay) based on user input, so no Devicetree representation changes required.

I would expect SYS_INIT to be used for highly abstracted high level pieces of code, not as small pieces of code mixed in with the device drivers.

Understandable, but not realistic. Downstream uses are free to use SYS_INIT as fits there FW architecture. The common problem is sequencing the initializations based on dependencies. The only mechanism currently provided by Zephyr is via SYS_INIT. In order to make my architecture scalable and composable, every component (sometimes smaller than a subsystem) has its own call to SYS_INIT, and I have to set system-wide prioritizations to reflect the dependencies.

If this is the case, why are we not placing the subsystems in the devicetree like we already do for fstab, leds-gpio and other subsystems that depend on device instances directly, and can be depended upon by devices.)

I am glad you recognize that drivers can call subsystem. That does not seem to be understood by many. I hope you also understand that "drivers" is just a run-time binding mechanism and is available to be applied at any interface between components. This is distinct from devicetree, which is "a construct called a devicetree to describe system hardware." (from devicetree-specification-v0.4-rc1, section 2.1). In Zephyr documentation the wording is "A devicetree is a hierarchical data structure that describes hardware." In other words, it describes the (part of the) constraints on the execution environment run on that hardware. The executable is free to only a subset of the resources and interfaces available. On the other hand, the organization and abstractions of the code running on the hardware are independent of that environment. I can make as many buttons as I like on the GUI or instantiate as many network stack instances as I like and shouldn't have to modify the aggregate devicetree files/overlays.

The point i am making is that if you need to point from a specific instance of a device/subsystem to another specific instance of a device/subsystem at compile time, you need a tree like structure or list. The best mechanism we currently have that can describe this structure is the devicetree, which can and already does include subsystems like fstab.
What other mechanism can describe the interdependencies between all specific device and subsystem instances at compile time, and can show this information intuitively? It seems like the definition of "devicetree" is corrupting any notion that it is a viable option for describing hardware dependent subsystems. We already have leds, chosen nodes etc. which are binding specific devices to subsystems, it is not a new idea.

API meeting:

@henrikbrixandersen We probably need to solve the whole level problem first instead of patching it. A full solution is required, that supports:

Dependencies between software and devices
Multi-instance for devices and software

@andyross mentions this might be fixing the problem at the wrong level: this should probably be on top of SYS_INIT
@bjarki-trackunit mentions that we should use a tree-like structure (not necessarily DT) that is parsed and then injects the necessary data into the build image

@bjarki-trackunit mentions that we should use a tree-like structure (not necessarily DT) that is parsed

The tree-like structure needs to be generated from the dependencies of each component implementation.  The component implementation depends on used APIs being provided (not on other components or subsystems). When trying to apply this to a composable system like Zephyr each component describes what APIs it provides and what APIs it depends upon.  Explicitly configuring this in an executable-specific tree description is impractical to create and worse to sustain.
All that needs to be provided at the executable configuration level is the instance-to-instance mapping for the components with multiple instances.  It may be useful to also indicate any ordering preferences between independent components in support of an agent that runs independent initializations in parallel.

describing hardware dependent subsystems.

In multi-function printers, many subsystems are hardware independent, fit together with a tree of dependencies, and some of which are multi-instance (e.g., formatters, GUIs). Solving the initialization order issue for these will cover the needs for hardware-dependent subsystems.

It seems like the definition of "devicetree" is corrupting any notion that it is a viable option for describing hardware dependent subsystems.

Use devicetree to describe software structures is a violation of the design principle of Decompose to Single Responsibility (https://en.wikipedia.org/wiki/SOLID). A different mechanism needs to be created.

Okay, zephyr has subsystems for shell and console which are hardware dependent. To get a reference to the specific device instance to use for the subsystem, the devicetree is used. The devicetree has a predefined node named chosen for this. chosen is not part of the DT schema, and is not describing hardware, it is a binding between a submodule and a device instance. The same is the case for partitions, partitions are not hardware, they are software constructs, which are then referenced by another chosen node, zephyr,flash, entirely software subsystem pointing to entirely software construct, in the devicetree.
    chosen {
        zephyr,shell = &uart0;
        zephyr,flash = &flash0;
        zephyr,code-partition = &slot1_partition;
    };

This puts an inherent constraint on the subsystems, only one subsystem instance possible pr chosen node. It is not a far stretch to rewrite the chosen node to a more honest graph, which allows for multiple instances of subsystems, as you demanded.
    shell {
        compatible = "zephyr,shell";
        uart = &uart0;
    };
    flash {
        compatible = " zephyr,flash";
        flash = &flash0;
    };
    code {
        compatible = "zephyr,code-partitionl";
        code = &slot1_partition;
    };

It has already been decided that this was the way to link hardware and software in a system with a static kernel and hardware; a tree like structure which shares hardware and software constructs which shares their dependencies.
I don't think introducing SOLID into this discussion entirely appropriate, given it is intended for object oriented software. I prefer KIS(Superman). Why introduce multiple mechanisms spread across the system to solve an issue that is naturally described with a tree like structure. If you really insist on SOLID, the single responsibility of the tree is to graph the subsystems and their dependencies (and yes, devices are just subsystems tied to hardware, they are otherwise functionally identical).

Okay, zephyr has subsystems for shell and console which are hardware dependent.

I disagree.  They depend on a driver API, but the API could be implemented through a purely software construct.  The lowest layer UART driver is "hardware" dependent (where "hardware refers to an execution agent interfacing through the memory map and processing in parallel to the executable).  The vast majority of Zephyr code is intentionally hardware independent.  Just look at how much code we are testing independent of hardware or hardware simulation.

I don't think introducing SOLID into this discussion entirely appropriate, given it is intended for object oriented software.

To be composable, scalable, and extensible the Zephyr architecture/ecosystem needs to and largely does follow object-oriented concepts (from https://en.wikipedia.org/wiki/Object-oriented_design#Object-oriented_concepts):

Object/Class:  The components themselves are responsible for configuration/allocation and hiding of their own OS constructs including threads, mutexes, and queues.  The Zephyr API Design guidelines support multi-instance of the API provider and multi-instance of the API caller.
Information hiding: This is largely achieved by the avoidance of globally scoped data.
Inheritance: Though not provided yet, the ability to wrap/extend a driver implementation has already been requested.
Interface: By putting subsystem/driver interface definitions in a separate tree from the implementation and not including the implementation source tree in the general include paths Zephyr is already promoting (enforcing?) programming to an interface.  Also, the test suites are testing to interfaces.
Polymorphism: There are two types of polymorphism.  One is holding any/all of the possible subtypes (not generally available).  The other is providing alternate interfaces to an object.  Any component providing an interface in addition to SYS_INIT is providing alternate interfaces.  (BTW, the Composite reuse principle states that "classes should achieve polymorphic behavior and code reuse by their composition rather than inheritance from a base or parent class" (https://en.wikipedia.org/wiki/Composition_over_inheritance)

A similar pattern of composability and encapsulation occurs when looking at integration with multiple downstream repositories.
The centralized tree-like structure is not composable or extensible.  It doesn't meet the platform needs.

devices are just subsystems tied to hardware

I disagree. Devices are hardware.  Drivers are runtime-bound interfaces.  Subsystems are configurable building blocks of logic + OS constructs + ... that implement and/or use one or more interfaces.

It has already been decided that this was the way to link hardware and software in a system with a static kernel and hardware;

All the design decisions will need to be revisited when Zephyr shifts over to requirements-driven design (needed for safety-critical and secure solutions).  I am simply pointing out that the current policy does not meet the scalability, composability, and extensibility inherent in the Zephyr Project mission statement.


Deployment succeeds but action log says it failed

HI.
The setup in my .yml file is:
name: Deployment

on:
  push:
    branches:
  - master

jobs:
 deploy:
 runs-on: ubuntu-latest
 steps:
  - uses: actions/checkout@v2
  - name: 'Set build id'
    id: build_id
    run: echo "::set-output name=id::$(date +%s)"

  - name: Deploy master branch
    if: github.ref == 'refs/heads/master'
    uses<EMAIL_ADDRESS>    with:
      vercel-token: ${{ secrets.ZEIT_TOKEN }}
      vercel-args: '--prod -b BUILD=${{ steps.build_id.outputs.id }} -b BUILD_BRANCH=master -b ENVIRONMENT=production'
      vercel-org-id: ${{ secrets.ZEIT_ORG_ID }}
      vercel-project-id: ${{ secrets.ZEIT_PRODUCTION_PROJECT_ID }}

On push to master the action gets triggered but when it finishes action log says it failed (even tho code gets deployed and logs on vercel.com confirm succesful deployment)
Action logs:
https://*****************.vercel.app- Queued

- Queued

- Building

- Building

Production: https://***************** [3m]
Due to "builds" existing in your configuration file, the Build and Development Settings defined in your Project Settings will not apply. Learn More: https://vercel.link/unused-build-settings

set preview-url output
/usr/local/bin/npx vercel inspect https://*****************.vercel.app -t ***
Vercel CLI 19.2.0

Vercel CLI 19.2.0
- Fetching deployment "https://*****************.vercel.app" in *****

- Fetching deployment "https://*****************.vercel.app" in *****

Error! Failed to find deployment "https://*****************.vercel.app" in *****

Error! Failed to find deployment "https://*****************.vercel.app" in *****
##[error]The process '/usr/local/bin/npx' failed with exit code 1

Any ideas?

same issue with such logs:

I encountered the same:
Error! An unexpected error occurred in inspect: TypeError: Cannot read property 'split' of undefined
    at /usr/local/lib/node_modules/vercel/dist/index.js:2:650065
    at Array.reduce (<anonymous>)
    at A (/usr/local/lib/node_modules/vercel/dist/index.js:2:650029)
    at inspect_main (/usr/local/lib/node_modules/vercel/dist/index.js:2:655310)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at he (/usr/local/lib/node_modules/vercel/dist/index.js:2:375059)

However, the deployment was succesfully done. Retrying the same action results in the same error, so it's reproducable.

The same:
Error! An unexpected error occurred in inspect: TypeError: Cannot read property 'split' of undefined
91
    at S (/usr/local/lib/node_modules/vercel/dist/index.js:2:649236)
92
    at C (/usr/local/lib/node_modules/vercel/dist/index.js:2:649365)
93
    at Array.sort (<anonymous>)
94
    at A (/usr/local/lib/node_modules/vercel/dist/index.js:2:649999)
95
    at inspect_main (/usr/local/lib/node_modules/vercel/dist/index.js:2:655310)
96
    at runMicrotasks (<anonymous>)
97
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
98
    at he (/usr/local/lib/node_modules/vercel/dist/index.js:2:375059)
99
##[error]The process '/usr/local/bin/npx' failed with exit code 1

Same:
Error! An unexpected error occurred in inspect: TypeError: Cannot read property 'split' of undefined
    at /usr/local/lib/node_modules/vercel/dist/index.js:2:650065
    at Array.reduce (<anonymous>)
    at A (/usr/local/lib/node_modules/vercel/dist/index.js:2:650029)
    at inspect_main (/usr/local/lib/node_modules/vercel/dist/index.js:2:655310)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at he (/usr/local/lib/node_modules/vercel/dist/index.js:2:375059)

Error! An unexpected error occurred in inspect: TypeError: Cannot read property 'split' of undefined
    at /usr/local/lib/node_modules/vercel/dist/index.js:2:650065
    at Array.reduce (<anonymous>)
    at A (/usr/local/lib/node_modules/vercel/dist/index.js:2:650029)
    at inspect_main (/usr/local/lib/node_modules/vercel/dist/index.js:2:655310)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at he (/usr/local/lib/node_modules/vercel/dist/index.js:2:375059)
##[error]The process '/usr/local/bin/npx' failed with exit code 1

I'm getting a similar error with a different property name:
Error! An unexpected error occurred in inspect: Error: val is not a non-empty string or a valid number. val=null
    at Object.e.exports [as default] (/usr/local/lib/node_modules/vercel/dist/index.js:2:1212562)
    at elapsed (/usr/local/lib/node_modules/vercel/dist/index.js:2:25757)
    at inspect_main (/usr/local/lib/node_modules/vercel/dist/index.js:2:655267)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at he (/usr/local/lib/node_modules/vercel/dist/index.js:2:375059)

Error! An unexpected error occurred in inspect: Error: val is not a non-empty string or a valid number. val=null
    at Object.e.exports [as default] (/usr/local/lib/node_modules/vercel/dist/index.js:2:1212562)
    at elapsed (/usr/local/lib/node_modules/vercel/dist/index.js:2:25757)
    at inspect_main (/usr/local/lib/node_modules/vercel/dist/index.js:2:655267)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at he (/usr/local/lib/node_modules/vercel/dist/index.js:2:375059)
##[error]The process '/usr/local/bin/npx' failed with exit code 1

The actual deployment on Vercel's end succeeds for me, too.

I'm getting the same error

but the weird part is that the deployment in vercel finishes succesfully.

Looks to be similar to issue #28

So the GitHub Actions docs says I can set the secret ACTIONS_STEP_DEBUG to true and re-run actions to get more details. I did and then saw that this is the command being ran right before the error:
vercel inspect https://my-site.vercel.app --scope team_ABC123

Running that locally gives me the same error:
Error! An unexpected error occurred in inspect: TypeError: Cannot read property 'split' of undefined

I tried to update to the latest cli<EMAIL_ADDRESS>but had same error.

So this is happening during the vercel inspect usage - which happens after the vercel deploy so that's why deploys are still successful. This step is most likely used to get all the useful GitHub actions outputs like deploy url (which I love BTW!). When I ran this locally, it fails right before listing the "Builds" out - I'm guessing that is an array and the cli is basically trying to run builds.split('\n') but builds is undefined. Probably an API data structure change. PS This is why optional chaining is amazing b/c then builds?.split('\n') wouldn't crash the whole thing.

I've contacted Vercel Support about this, as I believe this is an upstream issue.

@simonhaenisch did you get any update? contacted them as well, but didn't get any response yet.

Yeah they said it's an issue with the inspect command but they haven't updated me since.

Is there a GitHub issue on the https://github.com/vercel/vercel repo anyone has a link to?

Nope because they don't do bug tracing publicly anymore.

Well that's a convenient way to appear less buggy 😠

That's annoying, I have to do manually deployment.

I've got a fork that is working for me (use EvanLovely/vercel-action@506f39d in GitHub Actions config to use/test) and have made a PR for it: #29

I've filled an issue about this as well, got in response:

Hello,
There is an issue with vercel inspect which we are currently fixing as we speak.
We will get back to you as soon as that is fixed.

It works for me now.

I've got a response from the Vercel support team

The issue has been fixed for all new deployments. We are working to make it compatible with old deployments as well.

vercel inspect seems to be working now but this vercel action still fails with Error! Failed to find deployment xxx in xxx.

Got the same response from support as well, and new deployments with this action are working again for us.

@simonhaenisch
By

new deployments

do you mean new pull requests (assuming you're using this action for deploying PR previews?)
It seems to be still broken for me when I'm triggering new workflow runs within the same PR.

We use it to manually deploy master to a staging environment. It works for new commits on master now. PR previews are done by the Github Integration.


Update smcdsb.txt

change county to catholic. County is incorrect.

@TallGuysFreeADMIN Thank you for the update! Pull request merged.


Publish guide returns an error when overview is not filled in

but doesn't show that error in the form. It should show that error in the form.

I don't think this is an issue anymore.


Git repo on did change event not fired on first selection change in multiroot workspace

Issue Type: Bug

Create an extension with the following code, making sure to list vscode.git as an extension dependency in the package.json and copying the git.d.ts from vscode:

export async function activate(context: vscode.ExtensionContext) {
	const gitExtension = vscode.extensions.getExtension<GitExtension>('vscode.git')!.exports;
	const gitApi  = gitExtension.getAPI(1);

	gitApi.repositories.forEach(repo => {
		console.log(repo.rootUri.path, repo.ui.selected);
		repo.ui.onDidChange(() => {
			console.log(repo.rootUri.path, repo.ui.selected);
		});
	});

	gitApi.onDidOpenRepository(repo => {
		repo.ui.onDidChange(() => {
			console.log(repo.rootUri.path, repo.ui.selected);
		});
	});
}

Run the extension and open a multiroot workspace with two repos
In the SCM viewlet, select the second folder

Expected:
onDidChange is fired for the repo that is deselected and the repo that is now selected
Actual:
onDidChange gets fired for the first repo which now has selected false, but no onDidChange is fired for the second, now selected repo
VS Code version: Code - Insiders 1.41.0-insider (7cf4cca47aa025a590fc939af54932042302be63, 2019-12-02T05:26:29.458Z)
OS version: Darwin x64 18.7.0

Pushing out due to not being regression or severe.


Integrate with Altair Unisight

Goal: Support more databases
Altair Unisight uses a MongoDB database and provides GraphQL interface for querying the data. This is used as a datasource in NavOps. We should create a new plug-in for forwarding data to the Unisight data loader interface.
The interface accepts data over HTTP, and expects JSON data. We need to provide a schema of the data (as you'd expect), so that the GraphQL interface works.
We have the installation files for unisight and I'll get it installed on a VM. The install files are in astronomix:/ellexus/installs/unisight/unisight-linux-x86_64-4.6.0.tar.gz.
Kornelija Veseli is our contact in charge of unisight, should you require any help. One gotcha is that dates should be formatted as follows (this is how MongoDB formats dates):
"YourDateField" :  { "$date": "YYYY-MM-DDTHH:mm:ss.SSSZ" }
e.g.
"Timestamp" :  { "$date": "2014-01-22T14:56:59.301Z" }

In order to install unisight Kornelija recommended running the unisight-single-server-install.sh script to install the software, but you need to modify the script and set INSTALL_UDL=yes before running. This will install the data loader component that we need. The install scripts target systemd, so CentOS 7 or newer is recommended.

Unisight Administration Guide

Unisight Administration Guide

No longer a priority


Update Dutch translation

coverage: 60.061%. remained the same when pulling cdcbd1b2fcb3d6890cc27ebd969b437a114630cf on dennisschagt:update-nl-translations into d57de6828f382997c697159261c5ae16e7305f4d on newsboat:master.


Simple header/footer

The documentation I've added to the README explains my approach pretty thoroughly, but in essence I didn't want to make any presumptions about what the Header or Footer components would look like. All I wanted to solve was whether they were "fixed" or not, depending on the previous route's header/footer and the current route's header/footer. You'll notice that I created a new example application called "App", as I was having a hard time getting the older dependencies of the other example apps working with my version of Expo.

If the Header/Footer is the same between the two routes, then it will not be included in the transition animation (note how the header and footer do not animate when I tap on the "wallet" link below):

If a given route has a different Header/Footer, then said different element will be included in transition animation (I admit this looks weird below because I'm not doing any nice fading in/out upon mount/unmount of the tab navigation footer itself, but it's just for illustrative purposes):

It's worth noting this is a pretty common pattern. For example it's what WhatsApp does when transitioning between List view and Convo view: as each view has a different footer, the footer is included in the transition. The below screenshot was taken mid-swipe-back:

Finally, if a given route has no Header/Footer, then of course none is rendered for that route and the previous route's Header/Footer will be included inside its transition area (meaning they won't suddenly appear/disappear):

Once https://github.com/Traviskn/react-router-native-stack/pull/34 is merged, then the yarn.locks won't show up in the diff here

Thanks for putting this together! I have a few thoughts on the API for adding a header/footer to the Stack.
Firstly, if you need a "fixed" header/footer you can actually already do that by rendering it outside of the stack, either above or below it.
So the only benefit you could get by having the header or footer rendered inside the stack is access to the same animated value that is driving the Stack's animation. If the header or footer could receive the internal animatedValue from the StackTransitioner component as a prop, then they could build any sort of animation they need an keep it in sync with the Stack's animated transitions. Would you mind passing down the animatedValue as a prop to the header/footer components as part of this patch?
Someday I think it would be nice to provide some standard header animations out-of-the-box similar to react-navigation, but this first step of just passing in a custom component is great.

Hi @Traviskn thanks for your comments! Glad you like the general idea of this PR 😄
Firstly, if you need a "fixed" header/footer you can actually already do that by rendering it outside of the stack, either above or below it.
^That's what I did initially, but then the header/footer will be present for every route. It doesn't take into account routes where I don't want said header/footer. So what I tried next was to continue to render the header/footer outside the stack and hook into the history via withRouter and then use some conditional logic to determine whether or not the component (the header or footer) should render itself, based on the current path. That works well enough if you don't have route transition animations. But the minute you're transitioning from a route with a header/footer to one without then AND there's a route transition animation in place, it makes the animation "jump" because the following happens:

new child starts sliding in from the right (the animation area is still constrained within previous route's header/footer)
header/footer suddenly disappear
new child continues to slide in the from the right, but it "jumps" as the Stack suddenly has more vertical space to occupy

So I guess maybe I shouldn't have used the word "fixed" really! 😂 Because it's more like I'm trying to cater for situations where the header/footer is fixed between certain routes but not all of them.
Anyway, that's ^ why I couldn't render the header/footer outside the stack in my situation. And what inspired this PR. Maybe I shouldn't call it a "fixed" header/footer, because you're totally right in that a truly fixed (for the whole app) header/footer can be easily rendered outside the stack.

LOVE ❤ the idea of passing down the internal animatedValue to the header/footer components so that you can build up your own animations in sync with the transition animation itself. I'll add that in now 😄

@Traviskn done!

Thanks! Sorry for my delayed response
I think this is a great step towards supporting more dynamic headers/footers, thanks for all the work you've put in! 👍


Added S3 URI output to package generation upload

Description
This PR adds an S3 URI output in the Wazuh dashboard package generation to comply with an objective requisite
This output is standardized and used on all package generation workflows
This output is used by the stage generation script to obtain the S3 object URI
This PR also improves the checksum upload
Issues Related

https://github.com/wazuh/wazuh-jenkins/issues/6371

Check List

[ ] All tests pass

[ ] yarn test:jest
[ ] yarn test:jest_integration

[ ] New functionality includes testing.
[ ] New functionality has been documented.
[ ] Update CHANGELOG.md
[ ] Commits are signed per the DCO using --signoff

Workflow functionality

https://github.com/wazuh/wazuh-dashboard/actions/runs/9372989192
https://github.com/wazuh/wazuh-dashboard/actions/runs/9372989188

 Completed 166.1 MiB/166.1 MiB (98.3 MiB/s) with 1 file(s) remaining
upload: dev-tools/build-packages/output/deb/wazuh-dashboard_4.9.0-99_amd64.deb to s3://packages-dev.internal.wazuh.com/development/wazuh/4.x/main/packages/wazuh-dashboard_4.9.0-99_amd64.deb
S3 URI: s3://packages-dev.internal.wazuh.com/development/wazuh/4.x/main/packages/wazuh-dashboard_4.9.0-99_amd64.deb

Run echo "Uploading checksum"
Uploading checksum
Completed 165 Bytes/165 Bytes (481 Bytes/s) with 1 file(s) remaining
upload: dev-tools/build-packages/output/deb/wazuh-dashboard_4.9.0-99_amd64.deb.sha512 to s3://packages-dev.internal.wazuh.com/development/wazuh/4.x/main/packages/wazuh-dashboard_4.9.0-99_amd64.deb.sha512
S3 sha512 URI: s3://packages-dev.internal.wazuh.com/development/wazuh/4.x/main/packages/wazuh-dashboard_4.9.0-99_amd64.deb.sha512

LGTM :green_circle:


updated highlight code to properly escape regex characters. closes #195

This commit escapes regex characters in search text, this was noted in issue #195

This PR seems to be obsolete. Moreover UI.Utils modules was split in individuals repositories. If still valid, please consider re-submitting on the dedicated repository.
See the README for details.


Can I make "Rendered Notes" counter using lua?

What is your question?
Hi I just wanna ask how to make a "Rendered Notes" counter if possible in Psych. BTW I'm using 0.7.3
I even tried it using lua but it counts opponent notes too I want just bf's notes to be counted.
Here is my code:
function onCreate()
    makeLuaText("renderedNotes", "Rendered Notes: 0", 0, 0, 0.0)
    screenCenter("renderedNotes", 'y')
    setTextSize("renderedNotes", 69)
    addLuaText("renderedNotes")
end

---
--- @param elapsed float
---
function onUpdate(elapsed)
    setTextString("renderedNotes", "Rendered Notes: " ..getProperty("notes.length"))
end

you just iterate over notes and check their mustPress property, it's true for bf's notes

you just iterate over notes and check their mustPress property, it's true for bf's notes

I'm no professional so how do I do this?

there is no professional stuff involved, it's just basics
for i = 0, getProperty('notes.length')-1 do
    if getPropertyFromGroup('notes', i, 'mustPress') then
        noteCount = noteCount + 1
    end
end
setTextString('renderedNotes', 'Rendered Notes: '..noteCount)

having "rendered notes" only count player notes is also kind of misleading


State windows

Pull request
Description
Adds a new window type, state windows, that allow to define windowing borders based on a script
Related

RFC
Related Issues: fixes #000, closed #000
Related docs PR

Checklist

[ ] The RFC, if required, has been submitted and approved
[ ] Any user-facing impact of the changes is reflected in docs.tremor.rs
[ ] The code is tested
[x] Use of unsafe code is reasoned about in a comment
[ ] Update CHANGELOG.md appropriately, recording any changes, bug fixes, or other observable changes in behavior
[ ] The performance impact of the change is measured (see below)

Performance

superseeded by https://github.com/tremor-rs/tremor-runtime/pull/2099 (For rebase)


dlangspec.pdf: too much whitespace/padding around some paragraphs

Seb reported this on 2017-12-15T03:05:09Z
Transferred from https://issues.dlang.org/show_bug.cgi?id=18080
CC List

Andrei Alexandrescu (@andralex)
berni44 (@WalterBright)

Description
See e.g. in chapter 33 (interfacing to C++)

> it's critical to ensure that the referenced memory will not be collected by the D garbage collector

https://imgur.com/a/yNqGf

andrei (@andralex) commented on 2017-12-15T05:53:39Z
This will be tricky in general. It's caused by tables inserted in running text as non-floats (floats can be moved around the doc allowing LaTeX to format text nicely). At some point we'll need to convert put tables in floats, but then we need to change text to eliminate reference such as "... as shown in the table below."


2 instances of WSL in same machine

I've used Windows subsystem for Linux since it was released and when the new version came out (Windows Store Version) I installed it and now I have 2 different instances of Ubuntu in my computer and now when I want to open the terminal using bash.exe it uses the old one instead of the new one. Anyone know how can I at least change it to the new version?

Wslconfig.exe is used to manage your distributions.

Wslconfig.exe is used to manage your distributions.


[PW-5181] Minimum order value is not processed correctly

When the order is placed with a test credit card a warning that the minimum order value is not reached is shown. The order is not placed and the cart is empty.
Steps to reproduce the behavior:

Configure the minimum order value for 20euros in Shopware basis settings
Add products to reach over minimum order value
Start the checkout
Payment with Adyen test credit card
Submit order
Error is shown

Expected:
The warning should only be shown if the minimum order value is not reached. If it is reached the order should be normally processed.

OS: Windows 10
Browser Chrome
Version 91.0.4472.124
Shopware 5.6.6
Adyen Plugin 2.0.0

Additional info:
Minimum order value is 20€, actual order value is 30€

Please find attached a screenshot how to configure this feature

Thanks for this report @anothaNj @cyborgii. We've opened an internal ticket to investigate this and come up with a solution.

Adding more info to this issue: This seems to be caused by a session mismatch. When the order minimum amount is set the sCheckMinimumCharge function will call sGetAmount which will try to use the sessionId to fetch the basket data, but the sessionId does not match the rows in s_order_basket.

Hello @anothaNj, could you confirm if #184 solves this issue for you?


feat(): update-readme

Update README
What does this PR do?
Update readme file
How should this be tested?

check readme file and see the new structure

@tetogomez  let's add content about the UAL authenticator.


Like with small delay (less 1 sec)

(x) checked /updated
(x) question
how do i get very small delays when liking, e. g. 2likes per second?
When i put a value smaller than 10 i  the delay it seems like there is no effect on the delay, just as if the value was still 10. I did have python print the delay and it is indeed set supersmall (even tried 1e-35)

ps: i would change it myself in source , bit i want to use this trick on my phone without access to the source


DisplayListener will update ViewFinder on the change of ... other display?

In the DisplayListener callback for onChanged(), I see that you will update the transform of TextureView if the change is for other logical display. Can I know why? I guess that if I attach my phone to an external display, and when that display is changed, my ViewFinder on the phone need to be adjusted as well. Is this correct?

Thanks for flagging. I'll take a second look at AutoFitTextureView so we can fix this as well as #10.


[WIP] Adding support for resource_settings

Adding support for resource_settings

added resource_settings virtual attribute to servers and zones
available to /api/servers via --attributes=resource_settings
available to /api/zones via --attributes=resource_settings
added new api controller mixin for settings
leverage the settings whitelisting code that handles partial categories
return all settings for admin users
whitelists the settings for non-admin users

WIP:
todo:

[ ] filter based on user
[ ] rspecs

With this enhancement, we return:

all settings for administrative users
whitelisted settings for non-admin users.

supported GETS:
  GET /api/settings
  GET /api/settings/<setting_path>
  GET /api/servers/:id?attributes=resource_settings
  GET /api/zones/:id?attributes=resource_settings
  GET /api/regions/:id?attributes=resource_settings

ping @Fryguy @imtayadeway please review, Thanks.

@Fryguy @imtayadeway bump

Closing this here, newer and improved coming in on the manageiq-api repo.


TestCafe hangs when running with Node LTS (v10.15.1)

What is your Test Scenario?

Download the provided test repo and execute the tests with node v10.15.1 (LTS) or or v10.14.2
What is the Current behavior?

TestCafe hangs when trying to execute tests and won't proceed to next tests. TestCafe will sometimes automatically restart & retry the test but most of the time it stays stuck during the execution. This is 100% reproducible all the time. Note: There is also another related issue where page styles/CSS won't load when running with Node LTS - https://github.com/DevExpress/testcafe-hammerhead/issues/1920
What is the Expected behavior?

TestCafe should run all tests without any issues.
What is your web application and your TestCafe test code?

Download this repo - https://github.com/sijosyn/testcafe-syntests and run the test suite.

Run the full test suite.
Your Environment details:

testcafe version:                    1.0.0
node.js version:                     v10.15.1 or  v10.14.2
command-line arguments:   * npm run aperture   or   testcafe chrome desktop -e
browser name and version:  Chrome 72
platform and version:           macOS 10.14
other:

@sijosyn,
I've reproduced this issue here: https://github.com/DevExpress/testcafe-hammerhead/issues/1920#issuecomment-463155015.
Our team will research it and check for a suitable solution.


scalable data

Need something like Sphinx to make it reasonable to maintain a large library of articles.

https://github.com/11ty/eleventy/issues/845 is about 11ty support for Sphinx


CI scripts to install olm  should use same versions as mentioned in testing document.

Testing Operator document uses OLm release version 0.10.0
but
CI script uses 0.8.1
Files
https://github.com/operator-framework/community-operators/blob/master/scripts/ci/install-olm-local
Try twice, since order matters
kubectl apply -f https://github.com/operator-framework/operator-lifecycle-manager/releases/download/0.8.1/olm.yaml
kubectl apply -f https://github.com/operator-framework/operator-lifecycle-manager/releases/download/0.8.1/olm.yaml

The Testing document suggests using 0.10.0
2. Install OLM
Install OLM into the cluster in the olm namespace:
kubectl apply -f https://github.com/operator-framework/operator-lifecycle-manager/releases/download/0.10.0/crds.yaml
kubectl apply -f https://github.com/operator-framework/operator-lifecycle-manager/releases/download/0.10.0

Updating this to 0.10.1


introduce k8s-infra chart

Introducing K8s-Infra chart to install DaemonSet for log collection and capturing K8s metrics, as discussed in internal Google Docs.
The newly introduced chart will be installed with SigNoz chart by default and can be disabled.
It can also be installed to any external K8s cluster from where we can send logs and other infra metrics to SigNoz.

Resolved by https://github.com/SigNoz/charts/pull/80


Complete freeze V20.6.1

I'm not used to report bugs but I'll do my best.
The process went like this:
Steam login
Launch ALVR
Click on launch steamVR
Oculus quest 2: open ALVR app
PC after a few seconds completely freezes... Even the mouse doesn't work anymore, just a complete freeze and the only solution is to shut it down the hard way.
My PC isn't vr ready, but there was a similar issue if not the same, with another bug report, with their much more performing PC, so I'm not sure if this is a hardware issue or not.
The only thing I'm sure of is that my PC decided to isekai itself after I launched ALVR on my Oculus quest 2.

Completely gone... It's a laptop so usually it should go in sleep mode when the screen is closed, but it was still running lol... Had to shut it down manually again


Fast chunk compression

🚀 🚀 Pull Request
Checklist:

[ ]  My code follows the style guidelines of this project and the Contributing document
[ ]  I have commented my code, particularly in hard-to-understand areas
[ ]  I have kept the coverage-rate up
[ ]  I have performed a self-review of my own code and resolved any problems
[ ]  I have checked to ensure there aren't any other open Pull Requests for the same change
[ ]  I have described and made corresponding changes to the relevant documentation
[ ]  New and existing unit tests pass locally with my changes

Changes
Speed up chunk compression by predicting length of compressed bytes using an adaptive compression ratio.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


eslint errors kill index.html bundling

It seems that any eslint error now prevents index.html from from ending up in the bundled files and you get a resource not found error (from express?). To recreate, just add a semicolon at the end of a line anywhere, run or restart dev, and you'll get a Cannot GET / error in the browser (and you won't see index.html in the bundle asset list).
If this was intentional, I think it goes too far. While eslint errors should paint red all over your console so you'll fix it, it shouldn't stop a valid codebase from running (as it didn't before). For one, it blocks quick and dirty things like throwing in a quick debugger statement.
If it was unintentional, any ideas on how to fix it so things don't just blow up? Might this be a side-effect of switching to express with middleware over the webpack-dev-server? (Sorry for being a bit behind on catching up with recent changes).

No eslint errors:
                         Asset       Size  Chunks             Chunk Names
vendor.9acd1bc49dacc181d997.js    2.27 MB       0  [emitted]  vendor
   app.9acd1bc49dacc181d997.js    1.07 MB       1  [emitted]  app
                    index.html  461 bytes          [emitted]
webpack: bundle is now VALID.

Any eslint errors (note the missing index.html):
                         Asset     Size  Chunks       Chunk Names
vendor.9acd1bc49dacc181d997.js  2.27 MB       0       vendor
   app.9acd1bc49dacc181d997.js  1.07 MB       1       app

ERROR in ./src/app.js

.../src/app.js
  19:55  error  Extra semicolon  semi

✖ 1 problem (1 error, 0 warnings)

webpack: bundle is now VALID.

Ah! It started when the eslint-loader was added. This loader causes eslint errors to count as webpack errors. One of the gotchas is using it with the NoErrorsPlugin, because now even eslint errors will prevent a build.
This is a conundrum because the NoErrorsPlugin is important to keep hot reloading robust to small errors, but, as I said, I think preventing a build on eslint errors is a bit heavy-handed. Any ideas on how you want to handle this?

@neverfox that snuck in in a PR and I haven't had a chance to remove it yet, it's definitely not intentional.

This can be fixed by adding webpackConfig.eslint.emitWarning = true; to build/webpack/_development.js
On 13 Dec 2015, at 07:46, David Zukowski<EMAIL_ADDRESS>wrote:

@neverfox that snuck in in a PR and I haven't had a chance to remove it yet, it's definitely not intentional.
—
Reply to this email directly or view it on GitHub.

@mtsr Ah, I had assumed that turned eslint errors into warnings (thereby making them indistinguishable from eslint warnings), but trying it, I see that's not the case. Rather it making eslint errors into Webpack warnings. I consider that an acceptable solution. and I'll put in a PR for it.


Errors in SCNet.py

Hello, there is a small bug in SCNet.py.
In Downloading URLs, the 'scnet50' link is provided as 'scnet101'. It's a small mistake, since I can't access the AliYunCS due to the Permission Deny, I hope you can fix this.
And by the way, would 'scnet154' pretrained model be available in up-coming days?

Thank you for pointing out the mistake, and the link for scnet-50 has been updated.
For whether providing the scnet-154 model, it is still under consideration.

Thanks, this issue will be closed.


Actualize CS Fixer config update CI

What was changed
Updated Code Style config
Optimize CI pipeline
Why?

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: roxblnfk:x: github-actions[bot]You have signed the CLA already but the status is still pending? Let us recheck it.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: roxblnfk:x: github-actions[bot]You have signed the CLA already but the status is still pending? Let us recheck it.


[WIP] Enhanced Video Streaming APIs (#469)

This PR is to add the VirtualDisplayEncoder class to the sdl_android library. Motivated by an evolution proposal explained in #469.
The branch has been heavily modified to the original PR #471 as it attempts to create better scoping of features and classes that will work better with defined modules rather than a monolithic central class.
TODO

[ ] Allow streaming manager to have reference to remote window
[ ] Move touch conversions to private streaming manager
[ ] Cleanup SdlProxyBase
[ ] Add unit tests

Codecov Report

Merging #631 into develop will decrease coverage by 0.91%.
The diff coverage is 0.65%.

@@              Coverage Diff              @@
##             develop     #631      +/-   ##
=============================================
- Coverage      41.39%   40.47%   -0.92%
  Complexity      2608     2608
=============================================
  Files            357      359       +2
  Lines          15269    15627     +358
  Branches        1592     1631      +39
=============================================
+ Hits            6320     6325       +5
- Misses          8694     9046     +352
- Partials         255      256       +1

Impacted Files
Coverage Δ
Complexity Δ

...evicelink/streaming/audio/AudioStreamingCodec.java
0% <ø> (ø)
0 <0> (?)

...link/streaming/audio/AudioStreamingLPCMParams.java
0% <ø> (ø)
0 <0> (?)

...vicelink/streaming/audio/AudioStreamingParams.java
0% <ø> (ø)
0 <0> (?)

...tdevicelink/streaming/video/RTPH264Packetizer.java
72.95% <ø> (ø)
29 <0> (?)

...n/java/com/smartdevicelink/proxy/SdlProxyBase.java
5.64% <0%> (-0.12%)
6 <0> (ø)

...link/streaming/video/VideoStreamingParameters.java
0% <0%> (ø)
0 <0> (?)

...va/com/smartdevicelink/protocol/WiProProtocol.java
26.94% <0%> (ø)
17 <0> (ø)
:arrow_down:

...rtdevicelink/streaming/video/SdlRemoteDisplay.java
0% <0%> (ø)
0 <0> (?)

...smartdevicelink/encoder/VirtualDisplayEncoder.java
0% <0%> (ø)
0 <0> (?)

.../com/smartdevicelink/SdlConnection/SdlSession.java
12.43% <60%> (+0.24%)
15 <0> (ø)
:arrow_down:

... and 4 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bf2f2b4...de67f86. Read the comment docs.


[MacOS] vscode didn't clean up child processes on exit

Issue Description
On launching .net core project on MacOS, vscode didn't clean up child processes on exit
Steps to Reproduce
On MacOS, launch a typical (c#) .net core project (either .net 5 or 6), observing that several 'dotnet' processes are created in Activity Monitor
Expected Behavior
all 'dotnet' processes are removed after stopping the debugging session or exiting vscode program
Actual Behavior
few 'dotnet' processes remained after stopping the debugging session or exiting vscode program
on Activity Monitor, parent of those processes is null, may be only child processes have not been cleaned up.
 Correct?

Thanks for confirming!


fix: Append atSign to the enrollment key to fix functional tests

- What I did

Fix the failing enrollment functional test.

- How I did it

The failure is because of the missing atSign to the enrollment key received via the notification from the server. Added currentAtSign to the expected result.

- How to verify it

All functional tests should pass.

- Description for the changelog

@sitaram-kalluri thank you


After approving the recovery key that contact is again showing QR scanner in F&F list.

When I click on the contact who has approved the recovery key of Keeper, the screen is again showing me the QR scanner modal that was visible at the time of the approval key. And if I scan the approval key again it is showing the message "Scan correct QR or try again sometime."

Unable to reproduce his issue.


link fixed

fixed link in "Assets in Train-The-Trainer kit" section for Master PowerPoint file (including notes for each slide)

👍 thanks @pierreroman