[RFC] Add a new system shutdown API

Add a new API to perform system shutdown: sys_shutdown(). When
CONFIG_MULTITHREADING is enabled, this function will signal the system
to schedule a shutdown when it goes to idle; otherwise it will shut down
immediately. Shutdown in this context means a power state that "cuts"
the system power, so that any context is lost.
Until now, this functionality has been implemented via the system power
management module, but in a clunky fashion. The way system PM works is
by defining some idle states in devicetree, that, given some properties
(e.g. minimal residency, exit latency, etc.) are automatically selected
when system goes to idle based on the expected next wake-up. However,
system off or shutdown is a power state that one typically wants to
control manually from the application because it implies state loss,
and in most cases, configuring some sort of wake-up source. So in
general, it is not desired to let the system enter this state
automatically. This led to the following stuff in-tree:
from boards/arm/mimxrt595_evk/mimxrt595_evk_cm33.dts:
/*
 * Deep power-down mode is supported in this SoC through
 *  'PM_STATE_SOFT_OFF' state. There is no entry for this in device tree,
 *  user can call pm_state_force to enter this state.
 */

That is, state not being defined in devicetree so that PM subsystem
doesn't pick it automatically, but still implemented in in the PM hooks:
from soc/arm/nxp_imx/rt5xx/power.c, pm_state_set():
case PM_STATE_SOFT_OFF:
	set_deepsleep_pin_config();
	POWER_EnterDeepPowerDown(EXCLUDE_FROM_DEEP_POWERDOWN);
	break;

And to actually make use of this state, users had to do this kind of
abominations:
pm_state_force(0u, &(struct pm_state_info){ PM_STATE_SOFT_OFF, 0, 0 });

/* Now we need to go sleep. This will let the idle thread runs and
 * the pm subsystem will use the forced state. To confirm that the
 * forced state is used, lets set the same timeout used previously.
 */
k_sleep(K_SECONDS(SLEEP_S));

printk("ERROR: System off failed\n");
while (true) {
	/* spin to avoid fall-off behavior */
}

In the case of Nordic, it also allows us to get rid of all PM hooks, resulting in ~1K of ROM savings on all builds.

on ARM64 we introduced the pm_cpu_ops to interface with PSCI, see: https://github.com/zephyrproject-rtos/zephyr/blob/ddd2bc94e2f4b51a3ac6f1f0e63e5665266c0f3f/include/zephyr/drivers/pm_cpu_ops.h#L55-L66
Do you think we can make the two co-exist or at least having the pm_cpu_ops as stardard fallback for ARM64?

Please delete PM_STATE_SOFT_OFF from include/zephyr/pm/state.h.
Please document this change in the release notes.

Please delete PM_STATE_SOFT_OFF from include/zephyr/pm/state.h.

This can only be done after all current implementations are migrated.

Please document this change in the release notes.

Will do, bit this is typically done before the release.

Let's pause for a bit, does this all make sense that we are adding a shutdown.h API to join reboot.h API, what is going to be next? reset.h API? It is worth looking into consolidating all of this.

At this point if we are really going to rework this maybe we can merge and extend pm_cpu_ops API ?

Let's pause for a bit, does this all make sense that we are adding a shutdown.h API to join reboot.h API, what is going to be next? reset.h API? It is worth looking into consolidating all of this.

This is just improving something that is currently unusable, ie
pm_state_force(0u, &(struct pm_state_info){ PM_STATE_SOFT_OFF, 0, 0 });

/* Now we need to go sleep. This will let the idle thread runs and
 * the pm subsystem will use the forced state. To confirm that the
 * forced state is used, lets set the same timeout used previously.
 */
k_sleep(K_SECONDS(SLEEP_S));

printk("ERROR: System off failed\n");
while (true) {
	/* spin to avoid fall-off behavior */
}

Shutdown hooks are also present on other systems, e.g. on Linux, so please, let's not block without a solid reason behind. I'm fine discussing the implementation details, but I'd not want to enter into endless discussions to find the final/eternal solution, as this will just lead to frustration. This has nothing to do with reboot, it's about shutting the system down.

Let's pause for a bit, does this all make sense that we are adding a shutdown.h API to join reboot.h API, what is going to be next? reset.h API? It is worth looking into consolidating all of this.

At this point if we are really going to rework this maybe we can merge and extend pm_cpu_ops API ?

I'm not sure pm_cpu_ops API is the right place for shutdown, I see it more like a system-wide action (same as reset/reboot, for instance). I actually used sys_shutdown to keep a minimal consistency with sys_reboot. Both could probably be merged into a single header, but I didn't want to cause more trauma to people with another breaking change (header rename in this case).

Please document this change in the release notes.

Will do, bit this is typically done before the release.

Whats a good way to ensure we do not miss during release time. Add a RELEASE_NOTES label?

Let's pause for a bit, does this all make sense that we are adding a shutdown.h API to join reboot.h API, what is going to be next? reset.h API? It is worth looking into consolidating all of this.

This is just improving something that is currently unusable, ie

That is really not a clean way, but the snippet is not fair, the intended behavior result is obtained with two calls:
 pm_state_force(0u, &(struct pm_state_info){ PM_STATE_SOFT_OFF, 0, 0 });
 k_sleep(K_SECONDS(SLEEP_S));

pm_state_force(0u, &(struct pm_state_info){ PM_STATE_SOFT_OFF, 0, 0 });

/* Now we need to go sleep. This will let the idle thread runs and
 * the pm subsystem will use the forced state. To confirm that the
 * forced state is used, lets set the same timeout used previously.
 */
k_sleep(K_SECONDS(SLEEP_S));

printk("ERROR: System off failed\n");
while (true) {
	/* spin to avoid fall-off behavior */
}

Shutdown hooks are also present on other systems, e.g. on Linux, so please, let's not block without a solid reason behind. I'm fine discussing the implementation details, but I'd not want to enter into endless discussions to find the final/eternal solution, as this will just lead to frustration. This has nothing to do with reboot, it's about shutting the system down.

Let's pause for a bit, does this all make sense that we are adding a shutdown.h API to join reboot.h API, what is going to be next? reset.h API? It is worth looking into consolidating all of this.

At this point if we are really going to rework this maybe we can merge and extend pm_cpu_ops API ?

Let's pause for a bit, does this all make sense that we are adding a shutdown.h API to join reboot.h API, what is going to be next? reset.h API? It is worth looking into consolidating all of this.

At this point if we are really going to rework this maybe we can merge and extend pm_cpu_ops API ?

I'm not sure pm_cpu_ops API is the right place for shutdown, I see it more like a system-wide action (same as reset/reboot, for instance). I actually used sys_shutdown to keep a minimal consistency with sys_reboot. Both could probably be merged into a single header, but I didn't want to cause more trauma to people with another breaking change (header rename in this case).

I agree, this looks more a system wide api. @carlocaione pm_cpu_ops really make sense in drivers ? we have similar API for intel adsp in SOC level. My point is shouldn't make more sense to have something aligned with what @gmarull is proposing here, for example sys_cpu_off and sys_cpu_on ? Also the pm_ namespace is confusing with the pm subsystem.

I agree, this looks more a system wide api. @carlocaione pm_cpu_ops really make sense in drivers ? we have similar API for intel adsp in SOC level. My point is shouldn't make more sense to have something aligned with what @gmarull is proposing here, for example sys_cpu_off and sys_cpu_on ? Also the pm_ namespace is confusing with the pm subsystem.

No, I strongly disagree here. On ARM64 (and this is definitely not a SOC-specific thing) you need to have some kind of firmware that is usually running in EL3 (monitor) to manage the PM part of the CPU (usually on, off, suspend, shutdown, etc...). This firmware can be PSCI compliant and going through SMCCC or doing its own thing. This is not some kind of platform / SoC custom magic.
We do not want to have some kind of SoC specific stuff for this to introduce some copy-and-paste code all over the ARM64 boards when the boards are compliant to PSCI. Even Linux has an API for this called cpu_operations.
If you want to have the sys_cpu_* ops falling back onto the pm_cpu_ops be my guest, but this is as much as I am available to concede on this topic.
About the name I'm not particularly invested in that.

 Maybe the header could live in pm/, but feels like very much like an exit() to me so a level above seems to make sense.

Last push: I've gone back to the original shape. For SMP, shutdown will be immediate with the latest patch set. After all, a proper shutdown mechanism didn't exist for SMP before this proposal (either the first idle thread would run the PM SOFT_OFF routine, ignoring other cores), or PM CPU ops API could be used, meaning immediate shutdown. I think it's better to wait for a proper SMP implementation rather than quickly coding a naive implementation just to have the false sense of supporting SMP properly. So to summarize, the current proposal is about a new API (this should not change) that solves a real problem for quite a few platforms. Shutdown sequence can be refined later.

Last push: I've gone back to the original shape. For SMP, shutdown will be immediate with the latest patch set. After all, a proper shutdown mechanism didn't exist for SMP before this proposal (either the first idle thread would run the PM SOFT_OFF routine, ignoring other cores), or PM CPU ops API could be used, meaning immediate shutdown. I think it's better to wait for a proper SMP implementation rather than quickly coding a naive implementation just to have the false sense of supporting SMP properly. So to summarize, the current proposal is about a new API (this should not change) that solves a real problem for quite a few platforms. Shutdown sequence can be refined later.

Just to give some context, PSCI states that The caller must place all cores in a known state prior to the call so I'm fine with this change.

I agree, this looks more a system wide api. @carlocaione pm_cpu_ops really make sense in drivers ? we have similar API for intel adsp in SOC level. My point is shouldn't make more sense to have something aligned with what @gmarull is proposing here, for example sys_cpu_off and sys_cpu_on ? Also the pm_ namespace is confusing with the pm subsystem.

No, I strongly disagree here. On ARM64 (and this is definitely not a SOC-specific thing) you need to have some kind of firmware that is usually running in EL3 (monitor) to manage the PM part of the CPU (usually on, off, suspend, shutdown, etc...). This firmware can be PSCI compliant and going through SMCCC or doing its own thing. This is not some kind of platform / SoC custom magic.

It was more a question than a proposal, I don't how it works on arm64, I was checking if it was the same as on intel adsp.

We do not want to have some kind of SoC specific stuff for this to introduce some copy-and-paste code all over the ARM64 boards when the boards are compliant to PSCI. Even Linux has an API for this called cpu_operations (and psci_operations).
If you want to have the sys_cpu_* ops falling back onto the pm_cpu_ops be my guest, but this is as much as I am available to concede on this topic.
About the name I'm not particularly invested in that.

ok

Last push: I've gone back to the original shape. For SMP, shutdown will be immediate with the latest patch set. After all, a proper shutdown mechanism didn't exist for SMP before this proposal (either the first idle thread would run the PM SOFT_OFF routine, ignoring other cores), or PM CPU ops API could be used, meaning immediate shutdown. I think it's better to wait for a proper SMP implementation rather than quickly coding a naive implementation just to have the false sense of supporting SMP properly. So to summarize, the current proposal is about a new API (this should not change) that solves a real problem for quite a few platforms. Shutdown sequence can be refined later.

PM_SOFT_OFF was basically triggered by targets that manually forced this state, so the application responsible to sync, put other cores idle and the last one off. While this transfer a lot of responsibilities to the application it hasn't a race condition (at least not known).

Last push: I've gone back to the original shape. For SMP, shutdown will be immediate with the latest patch set. After all, a proper shutdown mechanism didn't exist for SMP before this proposal (either the first idle thread would run the PM SOFT_OFF routine, ignoring other cores), or PM CPU ops API could be used, meaning immediate shutdown. I think it's better to wait for a proper SMP implementation rather than quickly coding a naive implementation just to have the false sense of supporting SMP properly. So to summarize, the current proposal is about a new API (this should not change) that solves a real problem for quite a few platforms. Shutdown sequence can be refined later.

PM_SOFT_OFF was basically triggered by targets that manually forced this state, so the application responsible to sync, put other cores idle and the last one off. While this transfer a lot of responsibilities to the application it hasn't a race condition (at least not known).

This basically means we do not support shutdown on SMP based systems. The current implementation doesn't have any race conditions either, as it will perform immediate action (so still up to the application to do any necessary prep work). In any case, users of SMP systems should be aware that shutdown is not well-supported on their platforms.

Wow. I'm glad I looked at it, because this does not cover what I expected of "system shutdown". Nothing should prevent end users from tying long duration operations into SYS_INIT() (e.g., reinitialize a file system, read the entire SEEPROM, perform a mechanical initialization).  Each may have an analogous de-initialization that needs to be performed.
Where is the de-init() of each of the SYS_INIT() calls?

Wow. I'm glad I looked at it, because this does not cover what I expected of "system shutdown". Nothing should prevent end users from tying long duration operations into SYS_INIT() (e.g., reinitialize a file system, read the entire SEEPROM, perform a mechanical initialization). Each may have an analogous de-initialization that needs to be performed.
Where is the de-init() of each of the SYS_INIT() calls?

This PR has nothing to do with de-init and SYS_INIT, please read carefully the PR text. Feel free to open a feature request.

This PR has nothing to do with de-init and SYS_INIT ...

The system integrators and downstream subsystem developers like me want to NOT have to look at PR requests to understand the scope of a function.
What I noticed was the naming of the new file (sys/shutdown.h) and new function (sys_shutdown()), made me expect this functionality was a counterpart to SYS_INIT(). I am not confused by the name of the replaced function (pm_system_off()).  Do you have a more apparent name for the counterpart to SYS_INIT()?  If not, then consider renaming sys_shutdown to something that more closely indicates the limited scope of functionality. ;-)

This PR has nothing to do with de-init and SYS_INIT ...

The system integrators and downstream subsystem developers like me want to NOT have to look at PR requests to understand the scope of a function.
What I noticed was the naming of the new file (sys/shutdown.h) and new function (sys_shutdown()), made me expect this functionality was a counterpart to SYS_INIT(). I am not confused by the name of the replaced function (pm_system_off()). Do you have a more apparent name for the counterpart to SYS_INIT()? If not, then consider renaming sys_shutdown to something that more closely indicates the limited scope of functionality. ;-)

I can only suggest to read the PR messages more carefully next time :-)

Architecture WG:

@gmarull introduces the subystem: This is a clean shutdown API that does not require the power management subsystem. The power management subsystem tends to be opinionated, whereas this subsystem is fully controlled by the application. Similar to PM_STATE_FORCE but also blocking.
@bjarki-trackunit likes the solution, also has the same usecase
@nashif asks what "shutdown" means in this context. @gmarull replies that this is "shutting down and never come back". Any actions required to wake up must be done by the application before calling shutdown
@nashif asks whether we really need a new header file instead of trying to consolidate these APIs, just like reboot as well
@carlescufi suggests that we could perhaps have an include/sys/system.h with APIs that are similar: reboot, shutdown.

last push: rebased to fix conflicts

Drop [RFC] from the title?

* @carlescufi suggests that we could perhaps have an `include/sys/system.h` with APIs that are similar: reboot, shutdown

I think this was the main actionable point from the discussion, are you planning on following up on that separately? Does it makes sense to have this as header just to include other sys/ headers?

Drop [RFC] from the title?

* @carlescufi suggests that we could perhaps have an `include/sys/system.h` with APIs that are similar: reboot, shutdown

I think this was the main actionable point from the discussion, are you planning on following up on that separately?

I don't really like sys/system.h (double sys), but I'm open to suggestions here. I don't see current header a problem either, on Linux you have sys/reboot.h with a single function as well (main difference is that reboot takes an argument that can be used to perform shutdown: RB_POWER_OFF).

Does it makes sense to have this as header just to include other sys/ headers?

sys/ is really heterogeneous to make a catch-all header, and I've personally never been a fan of such headers.

After some thinking, keeping shutdown API in its own header makes sense because it is an independent feature (CONFIG_SHUTDOWN). It also has its own internal header (shutdown_internal.h). For reference, on Linux there's sys/reboot.h with a single function as well (note that on Linux reboot can be used for multiple things like reboot, shutdown, etc.)
Thoughts? Other naming suggestions?

Thoughts? Other naming suggestions?

I don't mind separate header, in how many files of the application do you expect that to end up? Probably somewhere between 0 and 1.

I keep the -1 not because the API itself, but because this needs more discussion around the whole picture.

pm_system_off has gone and the new sys_shutdown was included, though, we still have pm_system_reset ... What is the plan ? It is confuse, these functionalities should follow some similar namespace convention.
This is a feature that is related with power management (even if it is available for targets that don't have pm). I think it should have some integration with the power management subsystem when it is enabled. I think we will end up replicating logic when dealing with SMP. Also for targets that are using system power management, it makes sense the shutdown following the system power management flow and suspending devices.
For targets with SOFT_OFF and shutdown enabled, do they need to duplicate the implementation ?

I keep the -1 not because the API itself, but because this needs more discussion around the whole picture.

pm_system_off has gone and the new sys_shutdown was included, though, we still have pm_system_reset ... What is the plan ? It is confuse, these functionalities should follow some similar namespace convention.

I guess the question is why pm_system_reset was introduced out of sys_reboot (https://github.com/zephyrproject-rtos/zephyr/commit/62dbe72cb7ac55d1ae3ce62e5fb1fae47b9b293a). It's basically a clone of an existing API. Anything to say here?

This is a feature that is related with power management (even if it is available for targets that don't have pm). I think it should have some integration with the power management subsystem when it is enabled. I think we will end up replicating logic when dealing with SMP.

First, SMP + shutdown is not supported properly today. Neither with PM/pm_cpu_ops API. There's no need to duplicate code if a future implementation finds commonalities between shutdown/PM, just use some shared code.

Also for targets that are using system power management, it makes sense the shutdown following the system power management flow and suspending devices.

It doesn't on systems using device PM runtime. I'd like to emphasize again that PM_DEVICE has multiple issues, to the point it's broken for many use-cases, so it should be avoided to build something solid and stable (or re-implemented properly). I have yet to hear real use cases that can't be solved in a better way.

For targets with SOFT_OFF and shutdown enabled, do they need to duplicate the implementation ?

sys_shutdown() is a replacement for SOFT_OFF. This PR removes SOFT_OFF from targets implementing sys_shutdown().

pm_system_off has gone and the new sys_shutdown was included, though, we still have pm_system_reset ... What is the plan ? It is confuse, these functionalities should follow some similar namespace convention.

Again, why this keeps being put in the mix? The whole include/zephyr/drivers/pm_cpu_ops.h was introduced as a formalized API / interface for PSCI (well defined standard) and in general for firmware running outsize Zephyr for PM on ARM64 platforms, it was never meant to be used as a general interface for all the Zephyr platforms. We can bridge the two, but for me those are two different separated things.

pm_system_off has gone and the new sys_shutdown was included, though, we still have pm_system_reset ... What is the plan ? It is confuse, these functionalities should follow some similar namespace convention.

Again, why this keeps being put in the mix? The whole include/zephyr/drivers/pm_cpu_ops.h was introduced as a formalized API / interface for PSCI (well defined standard) and in general for firmware running outsize Zephyr for PM on ARM64 platforms, it was never meant to be used as a general interface for all the Zephyr platforms. We can bridge the two, but for me those are two different separated things.

So apparently it's now mixed with sys_reboot... pm_system_reset takes arguments mirrored from sys/reboot.h. And interestingly enough, it accepts SYS_COLD_RESET even though not part of the spec:

This PR removes pm_system_off, but I guess it could be kept and called in the PSCI impl of sys_shutdown.

pm_system_off has gone and the new sys_shutdown was included, though, we still have pm_system_reset ... What is the plan ? It is confuse, these functionalities should follow some similar namespace convention.

The problem, as stated already by @gmarull, is that pm_system_reset should not exist at all. In fact, I've created an issue to remove it:
https://github.com/zephyrproject-rtos/zephyr/issues/60915
This should hopefully clear out the confusion you mention.

This is a feature that is related with power management (even if it is available for targets that don't have pm). I think it should have some integration with the power management subsystem when it is enabled. I think we will end up replicating logic when dealing with SMP. Also for targets that are using system power management, it makes sense the shutdown following the system power management flow and suspending devices.

I see no issue in handling shutdowns via a separate interface (and in fact no one else did during the discussion in the architecture WG meeting) and still share any common code with PM when applicable. This can be achieved by refactoring as necessary. Linux also follows this model where reboot and shutdown are not directly tied to the PM power states, both for the reboot functionality and the shutdown one.

For targets with SOFT_OFF and shutdown enabled, do they need to duplicate the implementation ?

No, because the idea is to migrate all platforms to sys_shutdown and get rid of SOFT_OFF.

pm_system_off has gone and the new sys_shutdown was included, though, we still have pm_system_reset ... What is the plan ? It is confuse, these functionalities should follow some similar namespace convention.

Again, why this keeps being put in the mix? The whole include/zephyr/drivers/pm_cpu_ops.h was introduced as a formalized API / interface for PSCI (well defined standard) and in general for firmware running outsize Zephyr for PM on ARM64 platforms, it was never meant to be used as a general interface for all the Zephyr platforms. We can bridge the two, but for me those are two different separated things.

I never said they are the same my problem is with API consistency

I keep the -1 not because the API itself, but because this needs more discussion around the whole picture.

pm_system_off has gone and the new sys_shutdown was included, though, we still have pm_system_reset ... What is the plan ? It is confuse, these functionalities should follow some similar namespace convention.

I guess the question is why pm_system_reset was introduced out of sys_reboot (62dbe72). It's basically a clone of an existing API. Anything to say here?

This is a feature that is related with power management (even if it is available for targets that don't have pm). I think it should have some integration with the power management subsystem when it is enabled. I think we will end up replicating logic when dealing with SMP.

First, SMP + shutdown is not supported properly today. Neither with PM/pm_cpu_ops API. There's no need to duplicate code if a future implementation finds commonalities between shutdown/PM, just use some shared code.

Also for targets that are using system power management, it makes sense the shutdown following the system power management flow and suspending devices.

It doesn't on systems using device PM runtime. I'd like to emphasize again that PM_DEVICE has multiple issues, to the point it's broken for many use-cases, so it should be avoided to build something solid and stable (or re-implemented properly). I have yet to hear real use cases that can't be solved in a better way.

And I am gonna tell you again, that model may not be the correct for everyone and that is fine they can use DEVICE_RUNTIME but that is something that is working for some targets (Intel ADSP among others). They decided to take this route because drivers can't be suspended due latency and when the main CPU (that controls the DSP power management) asks the DSP to suspend they rely on system PM to suspend their devices. I tell you, that is a real use case, don't assume that you are aware of all use cases, that is a big mistake when starting removing/changing everything.

For targets with SOFT_OFF and shutdown enabled, do they need to duplicate the implementation ?

sys_shutdown() is a replacement for SOFT_OFF. This PR removes SOFT_OFF from targets implementing sys_shutdown().

After some thinking, keeping shutdown API in its own header makes sense because it is an independent feature (CONFIG_SHUTDOWN). It also has its own internal header (shutdown_internal.h). For reference, on Linux there's sys/reboot.h with a single function as well (note that on Linux reboot can be used for multiple things like reboot, shutdown, etc.)
Thoughts? Other naming suggestions?

folding shutdown in reboot and expanding reboot API similar to linux is a good way to move forward. Take this oppertunity to expand the API with reason for operation, If I remember correctly, this was a point of discussion in the past and useful when a system comes back (i.e. by using retention).
APIs for shutdown, reboot available as general interfaces, independent of PM being enable or not is good to have, but looking at this disucssion it seems like we have some existing inconsistency and differnent ways of doing all of this, so it would be could to unify some of the code paths and clean up duplicate APIs along they way.

pm_system_off has gone and the new sys_shutdown was included, though, we still have pm_system_reset ... What is the plan ? It is confuse, these functionalities should follow some similar namespace convention.

The problem, as stated already by @gmarull, is that pm_system_reset should not exist at all. In fact, I've created an issue to remove it: #60915
This should hopefully clear out the confusion you mention.

This is a feature that is related with power management (even if it is available for targets that don't have pm). I think it should have some integration with the power management subsystem when it is enabled. I think we will end up replicating logic when dealing with SMP. Also for targets that are using system power management, it makes sense the shutdown following the system power management flow and suspending devices.

I see no issue in handling shutdowns via a separate interface (and in fact no one else did during the discussion in the architecture WG meeting) and still share any common code with PM when applicable. This can be achieved by refactoring as necessary. Linux also follows this model where reboot and shutdown are not directly tied to the PM power states, both for the reboot functionality and the shutdown one.

For targets with SOFT_OFF and shutdown enabled, do they need to duplicate the implementation ?

No, because the idea is to migrate all platforms to sys_shutdown and get rid of SOFT_OFF.

Why get rid of SOFT_OFF ? My understanding is that sys_shutdown would be something equivalent to Mechanical Off (ACPI G3) some devices may take different approaches for shutdown and SOFT_OFF. I pointed it out because in the replaced cases they were doing the same thing, but there is semantic difference.

I keep the -1 not because the API itself, but because this needs more discussion around the whole picture.

pm_system_off has gone and the new sys_shutdown was included, though, we still have pm_system_reset ... What is the plan ? It is confuse, these functionalities should follow some similar namespace convention.

I guess the question is why pm_system_reset was introduced out of sys_reboot (62dbe72). It's basically a clone of an existing API. Anything to say here?

This is a feature that is related with power management (even if it is available for targets that don't have pm). I think it should have some integration with the power management subsystem when it is enabled. I think we will end up replicating logic when dealing with SMP.

First, SMP + shutdown is not supported properly today. Neither with PM/pm_cpu_ops API. There's no need to duplicate code if a future implementation finds commonalities between shutdown/PM, just use some shared code.

Also for targets that are using system power management, it makes sense the shutdown following the system power management flow and suspending devices.

It doesn't on systems using device PM runtime. I'd like to emphasize again that PM_DEVICE has multiple issues, to the point it's broken for many use-cases, so it should be avoided to build something solid and stable (or re-implemented properly). I have yet to hear real use cases that can't be solved in a better way.

And I am gonna tell you again, that model may not be the correct for everyone and that is fine they can use DEVICE_RUNTIME but that is something that is working for some targets (Intel ADSP among others). They decided to take this route because drivers can't be suspended due latency and when the main CPU (that controls the DSP power management) asks the DSP to suspend they rely on system PM to suspend their devices. I tell you, that is a real use case, don't assume that you are aware of all use cases, that is a big mistake when starting removing/changing everything.

Let me work through this, making it properly optional and letting the target choose which states should trigger it.

For targets with SOFT_OFF and shutdown enabled, do they need to duplicate the implementation ?

sys_shutdown() is a replacement for SOFT_OFF. This PR removes SOFT_OFF from targets implementing sys_shutdown().

No, because the idea is to migrate all platforms to sys_shutdown and get rid of SOFT_OFF.

Why get rid of SOFT_OFF ? My understanding is that sys_shutdown would be something equivalent to Mechanical Off (ACPI G3) some devices may take different approaches for shutdown and SOFT_OFF. I pointed it out because in the replaced cases they were doing the same thing, but there is semantic difference.

Well, sys_shutdown is a shutdown, not a power off. You can wake up from shutdown without user interaction on some platforms (eg. external GPIO stimulus). Regardless, we can keep SOFT_OFF independently of this new API.
What is exactly blocking this PR at this point @ceolin? It's not clear to me at this point. The API makes sense and there's wide agreement on it, we also agreed that the overlap you mentioned will be fixed, in part by @gmarull's #60920.

@carlescufi Nothing from my side now. Thanks @gmarull

Which two idioms? This introduces a single new API, aiming to replace pm_state_force + SOFT_OFF, and for now, it keeps the previous behavior.

Yeah... that's worse and not better, IMHO.  We used to have a simple API that did one thing on some platforms, and a complicated API that did a subtly different thing on different platforms.  Now we have the same call you can use on both platforms, but it still does different things?!
I just don't get it.  What's the advantage to merging this?  Won't it make things harder when we decide that sys_shutdown() needs properly-documented semantics because it will be a breaking change?
Frankly this seems cart-before-the-horse to me.  What we clearly want is a nicely specified shutdown/power-off API that tells the user exactly what they're getting and under what circumstances.  And once we have that we can make it pretty.

Which two idioms? This introduces a single new API, aiming to replace pm_state_force + SOFT_OFF, and for now, it keeps the previous behavior.

Yeah... that's worse and not better, IMHO. We used to have a simple API that did one thing on some platforms, and a complicated API that did a subtly different thing on different platforms. Now we have the same call you can use on both platforms, but it still does different things?!

Well, the idea is to convert remaining platforms, not to keep multiple different ways. We actually have 2 today (PM path and pm_cpu_ops path).

I just don't get it. What's the advantage to merging this? Won't it make things harder when we decide that sys_shutdown() needs properly-documented semantics because it will be a breaking change?

One of the advantages is to offer an API that offers some minimal guarantees (like for example that once called it will never return) and to be decoupled from PM, which in the case of Nordic it allows us to save a bit less than ~1K of ROM on all builds.

Frankly this seems cart-before-the-horse to me. What we clearly want is a nicely specified shutdown/power-off API that tells the user exactly what they're getting and under what circumstances. And once we have that we can make it pretty.

I think this PR addresses some existing problems, other features can be added incrementally. Also, this change is not breaking anything (as soon as we keep the definition of SOFT_OFF in PM). If in ~8y no one has shown interest in implementing a more complex shutdown like e.g. Linux, it's probably because it's not needed or because there's not enough knowledge/man power to do it.

I think we're not really getting each others points?  Stated simply, my position is "No new APIs with inconsistent semantics, period.".  Maybe you could add a sys_shutdown_async() if you really feel we need a function here?  I wouldn't stand in the way there.
And the glitch here isn't remotely theoretical.  Consider a PM-enabled system handling a fatal error of some kind.   It does LOG_ERR("The battery is on fire, state dump:"); ...; sys_shutdown(); and the recovery apparatus comes along later and uploads the telemetry.  Now you port the same system to Nordic and the telemetry is lost, because the shutdown is synchronous.  The previous system worked because the log backend got a chance to flush before shutdown.
Saying things like "well, the system is going to shut down at some point in the future anyway, so what's the difference" makes us look like we don't understand why we have the API in the first place.  I 100% agree that this is an area with complicated platform-dependencies and widely varying requirements.  That should make us more hesitant to wrap it in a pretty API, not less.

Which two idioms? This introduces a single new API, aiming to replace pm_state_force + SOFT_OFF, and for now, it keeps the previous behavior.

Yeah... that's worse and not better, IMHO. We used to have a simple API that did one thing on some platforms, and a complicated API that did a subtly different thing on different platforms. Now we have the same call you can use on both platforms, but it still does different things?!

@andyross I am a bit lost myself here as well. Could you clarify to which two idioms you were referring as well as what the "simple API" and "complicated API" are? It'd help if you referred them by name since we seem to be missing info here in order to understand your points.

Ok guys, here's my new take on this PR:

Action is now immediate, idle thread is no longer involved. The reason the previous solution involved idle thread was to preserve pm_state_force behavior, but eventually, it complicated things for no obvious reason.
Current approach mimics what sys_reboot() does, i.e., an immediate action
I renamed the function to sys_poweroff, I think it makes things less confusing as shutdown may be interpreted as a kind of ordered shutdown.
If in the future we support a proper shutdown sequence, the existing reboot/power off hooks will likely be useful as a last step in the chain. For now, it's application responsibility to make sure it is safe to call the API.

@gmarull  you often complain about missing documentation and this one is lacking documentation, so please add some docs.
Also, there is one thing I dislike here which is the use of z_ for the hook, this is reserved for internal APIs that should never be used outside of the Zephyr tree and zephyr code, so it would be beneficial to to come up with a naming convention for such hooks (also for the reboot PR) that makes it clear those are documented interfaces that can be used out of tree. For example sys_poweroff_hook() instead of z_sys_poweroff() or something along those lines. Such APIS will be part of another class of interfaces we need to document and maintain, but will have a different life cycle and change policy (unlike stable APIs).

Last push: added a page that imports sys_poweroff doxygen group.
I won't change the hook name, as the current convention is to use z_ prefix for internal functions. I never liked this convention, but I prefer consistency to random rules. If this is the only blocker for this PR, I prefer to close it.

Last push: added a page that imports sys_poweroff doxygen group.

and that is what I was asking for, it was not there when I reviewed last.

I won't change the hook name, as the current convention is to use z_ prefix for internal functions (hooks are just internal functions). I never liked this convention, but I prefer consistency to random rules. If this is the only blocker for this PR, I prefer to close it.

Ok, my bad that I mixed whatever is happening here with the reboot PR. This PR does not implement poweroff on different levels (arch -> soc -> ...) and does not have the notion of custom poweroff similar to what we have in the reboot PR where a custom implementation or hook can be implemented to override architecture code. So usage of internal API and naming is fine.
The discussion on hooks vs internal APIs can move to the reboot PR. Sorry about the confusion.


Refactor IO reactor close timeout.

5.1.x refactor reactor close timeout into a new method that accepts a timeout.

@garydgregory All API visible changes should go to master. I see no reason why this change needs to be in 5.1

@garydgregory All API visible changes should go to master. I see no reason why this change needs to be in 5.1

Closing per the above from Oleg.


release: v0.8.1

Description: 概要

Changes: 変更内容

Changes

fix: tag link (74a996d3c6898d504631215cbfa58ee61ab91bd2)
chore: update next config (457a91d5de82c8fee7c6daab322716341afd3b76)
chore: add tests of object value (01865a5dfb26bd90ae555ad5ff6417a7b11a4166)

Expected Impact: 影響範囲

Operating Requirements: 動作要件

Additional context: 補足

Codecov Report

Merging #99 (01865a5) into main (fc69f36) will increase coverage by 1.30%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main      #99      +/-   ##
==========================================
+ Coverage   41.28%   42.58%   +1.30%
==========================================
  Files         150      150
  Lines        1228     1228
  Branches      221      221
==========================================
+ Hits          507      523      +16
+ Misses        699      683      -16
  Partials       22       22

Impacted Files
Coverage Δ

src/components/chip/Tag.tsx
100.00% <100.00%> (ø)

src/packages/domain/shared/valueObject/base.ts
100.00% <0.00%> (+5.55%)
:arrow_up:

src/packages/domain/post/valueObject/id.ts
80.00% <0.00%> (+80.00%)
:arrow_up:

src/packages/domain/post/valueObject/postType.ts
100.00% <0.00%> (+100.00%)
:arrow_up:

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 fc69f36...01865a5. Read the comment docs.


Add locks and baching to task

I want to merge this change because...

Impact

[ ] New migrations
[ ] New/Updated API fields or mutations
[ ] Deprecated API fields or mutations
[ ] Removed API types, fields, or mutations

Docs

[ ] Link to documentation:

Pull Request Checklist

[ ] Privileged queries and mutations are either absent or guarded by proper permission checks
[ ] Database queries are optimized and the number of queries is constant
[ ] Database migrations are either absent or optimized for zero downtime
[ ] The changes are covered by test cases
[ ] All new fields/inputs/mutations have proper labels added (ADDED_IN_X, PREVIEW_FEATURE, etc.)
[ ] All migrations have proper dependencies
[ ] All indexes are added concurrently in migrations
[ ] All RunSql and RunPython migrations have revert option defined

Closing as it is old pr and changes were made in https://github.com/saleor/saleor/pull/16529


Initial commit for Scheduler

This is an initial commit for the new core component, "the scheduler".
This PR supersede the previous PRs, #4507, #4532.
Now we agree with incremental merging into the master.
We will implement modules based on the order defined in this page and add design documents under the page as well:
https://cwiki.apache.org/confluence/display/OPENWHISK/Component+Design
I added the first component design document for the "scheduler" component.
https://cwiki.apache.org/confluence/display/OPENWHISK/Scheduler
I created a new label, "scheduler".
All PRs which are dependent on this PR will be labeled with it.

I think there are supposed to be two checks, jenkins-ci/pr and travis-ci/pr.
I have no idea why there is another check, jenkins-ci/push, but I believe this PR is ready to merge.
jenkins-ci/push is failing because I removed the branch(add-scheduler) in the upstream master.
And that branch is not relevant to this PR.

Kindly review this for subsequent PRs.

Could anyone please review this?

Codecov Report

Merging #4547 into master will increase coverage by 22.85%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           master    #4547       +/-   ##
===========================================
+ Coverage      57%   79.86%   +22.85%
===========================================
  Files         176      176
  Lines        8104     8104
  Branches      535      535
===========================================
+ Hits         4620     6472     +1852
+ Misses       3484     1632     -1852

Impacted Files
Coverage Δ

...whisk/connector/kafka/KafkaConsumerConnector.scala
61.76% <0%> (+1.47%)
:arrow_up:

.../org/apache/openwhisk/core/entity/EntityPath.scala
100% <0%> (+1.88%)
:arrow_up:

...a/org/apache/openwhisk/core/entity/Parameter.scala
95.45% <0%> (+2.27%)
:arrow_up:

...sk/core/containerpool/docker/DockerContainer.scala
96.34% <0%> (+2.43%)
:arrow_up:

.../org/apache/openwhisk/http/PoolingRestClient.scala
91.17% <0%> (+2.94%)
:arrow_up:

...hisk/core/controller/actions/SequenceActions.scala
92.24% <0%> (+3.44%)
:arrow_up:

...pache/openwhisk/core/containerpool/Container.scala
87.5% <0%> (+3.75%)
:arrow_up:

...abase/cosmosdb/CosmosDBArtifactStoreProvider.scala
4% <0%> (+4%)
:arrow_up:

...tainerpool/docker/DockerClientWithFileAccess.scala
96% <0%> (+4%)
:arrow_up:

...rg/apache/openwhisk/core/entity/ExecManifest.scala
97.87% <0%> (+4.25%)
:arrow_up:

... and 101 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 b0d48c8...02f47d3. Read the comment docs.

closing for now.


Fix typos and new lines

Successfully built and erroring on Mac!

 validating resource: Error validating, missing required field. Path: "camera-1" Field: "ttl_ms"	{"resource":"rdk:component:camera/camera-1","model":"rand:velodyne-go-module:vlp-16"}
2024-07-08T21:33:02.397Z	INFO	robot_server	impl/resource_manager.go:606	Now configuring resource	{"resource":"rdk:component:camera/camera-1"}
2024-07-08T21:33:02.398Z	ERROR	robot_server.rdk:component:camera/camera-1	resource/graph_node.go:230	modular resource config validation error: rpc error: code = Unknown desc = error validating resource: Error validating, missing required field. Path: "camera-1" Field: "ttl_ms"	{"resource":"rdk:component:camera/camera-1","model":"rand:velodyne-go-module:vlp-16"}
2024-07-08T21:33:03.448Z	INFO	robot_server	impl/local_robot.go:1183	(Re)configuring robot
2024-07-08T21:33:03.450Z	INFO	robot_server	impl/resource_manager.go:606	Now configuring resource	{"resource":"rdk:component:camera/camera-1"}
2024-07-08T21:33:03.451Z	INFO	robot_server.modmanager	modmanager/manager.go:482	Adding resource to module	{"resource":"camera-1","module":"local-module-1"}
2024-07-08T21:33:03.454Z	INFO	robot_server	impl/local_robot.go:1228	Robot (re)configured
2024-07-08T17:33:24.277-0400	INFO	robot_server.external_signaler	rpc/answerer_stats.go:71	Connection establishment succeeded	{"answerRequestInitReceieved": "2024-07-08T17:33:23.875-0400", "numAnswerUpdates": 5, "localICECandidates": ["at: 2024-07-08T17:33:23.878-0400, candidate: udp4 host <IP_ADDRESS>:61315", "at: 2024-07-08T17:33:23.878-0400, candidate: udp4 host <IP_ADDRESS>:49361", "at: 2024-07-08T17:33:23.878-0400, candidate: udp4 host <IP_ADDRESS>:49595", "at: 2024-07-08T17:33:23.878-0400, candidate: udp4 host <IP_ADDRESS>:54549", "at: 2024-07-08T17:33:24.207-0400, candidate: udp4 srflx <IP_ADDRESS>:4825 related <IP_ADDRESS>:53194"], "remoteICECandidates": ["at: 2024-07-08T17:33:24.261-0400, candidate: candidate:0 1 UDP<PHONE_NUMBER> 37de3ddc-e13a-4926-b4f6-6a06cc6dc1d5.local 64019 typ host", "at: 2024-07-08T17:33:24.263-0400, candidate: candidate:7 1 TCP<PHONE_NUMBER> cbdd9453-9239-4fe1-837b-77854613d29b.local 9 typ host tcptype active", "at: 2024-07-08T17:33:24.264-0400, candidate: candidate:3 1 UDP<PHONE_NUMBER> cbdd9453-9239-4fe1-837b-77854613d29b.local 55764 typ host", "at: 2024-07-08T17:33:24.264-0400, candidate: candidate:6 1 TCP<PHONE_NUMBER> 37de3ddc-e13a-4926-b4f6-6a06cc6dc1d5.local 9 typ host tcptype active"]}
2024-07-08T21:33:25.810Z	ERROR	robot_server	stream/stream.go:89	error getting media	{"error":"rpc error: code = Unknown desc = no config for ProductID(0)","count":1,"sleep":50000}
2024-07-08T21:33:25.811Z	ERROR	robot_server	stream/stream.go:89	error getting media	{"error":"rpc error: code = Unknown desc = no config for ProductID(0)","count":2,"sleep":100000}
2024-07-08T21:33:25.811Z	ERROR	robot_server	stream/stream.go:89	error getting media	{"error":"rpc error: code = Unknown desc = no config for ProductID(0)","count":3,"sleep":200000}
2024-07-08T21:33:25.812Z	ERROR	robot_server	stream/stream.go:89	error getting media	{"error":"rpc error: code = Unknown desc = no config for ProductID(0)","count":4,"sleep":400000}
2024-07-08T21:33:25.813Z	ERROR	robot_server	stream/stream.go:89	error getting media	{"error":"rpc error: code = Unknown desc = no config for ProductID(0)","count":5,"sleep":800000}
2024-07-08T21:33:25.814Z	ERROR	robot_server	stream/stream.go:89	error getting media	{"error":"rpc error: code = Unknown desc = no config for ProductID(0)","count":6,"sleep":1600000}
2024-07-08T21:33:25.816Z	ERROR	robot_server	stream/stream.go:89	error getting media	{"error":"rpc error: code = Unknown desc = no config for ProductID(0)","count":7,"sleep":3200000}
2024-07-08T21:33:25.820Z	ERROR	robot_server	stream/stream.go:89	error getting media	{"error":"rpc error: code = Unknown desc = no config for ProductID(0)","count":8,"sleep":6400000}
2024-07-08T21:33:25.827Z	ERROR	robot_server	stream/stream.go:89	error getting media	{"error":"rpc error: code = Unknown desc = no config for ProductID(0)","count":9,"sleep":12800000}
2024-07-08T21:33:25.842Z	ERROR	robot_server	stream/stream.go:89	error getting media	{"error":"rpc error: code = Unknown desc = no config for ProductID(0)","count":10,"sleep":25600000}
2024-07-08T21:33:25.869Z	ERROR	robot_server	stream/stream.go:89	error getting media	{"error":"rpc error: code = Unknown desc = no config for ProductID(0)","count":11,"sleep":51200000}
2024-07-08T21:33:25.922Z	ERROR	robot_server	stream/stream.go:89	error getting media	{"error":"rpc error: code = Unknown desc = no config for ProductID(0)","count":12,"sleep":102400000}
2024-07-08T21:33:26.026Z	ERROR	robot_server	stream/stream.go:89	error getting media	{"error":"rpc error: code = Unknown desc = no config for ProductID(0)","count":13,"sleep":204800000}
2024-07-08T21:33:26.233Z	ERROR	robot_server	stream/stream.go:89	error getting media	{"error":"rpc error: code = Unknown desc = no config for ProductID(0)","count":14,"sleep":409600000}
2024-07-08T21:33:26.643Z	ERROR	robot_server	stream/stream.go:89	error getting media	{"error":"rpc error: code = Canceled desc = context canceled","count":1,"sleep":50000}
2024-07-08T17:33:27.915-0400	ERROR	robot_server	zap/options.go:212	finished unary call with code Unknown	{"grpc.start_time": "2024-07-08T17:33:27-04:00", "system": "grpc", "span.kind": "server", "grpc.service": "viam.component.camera.v1.CameraService", "grpc.method": "GetPointCloud", "error": "rpc error: code = Unknown desc = no config for ProductID(0)", "grpc.code": "Unknown", "grpc.time_ms": 1.253}
2024-07-08T17:33:33.688-0400	ERROR	robot_server	zap/options.go:212	finished unary call with code Unknown	{"grpc.start_time": "2024-07-08T17:33:33-04:00", "system": "grpc", "span.kind": "server", "grpc.service": "viam.component.camera.v1.CameraService", "grpc.method": "GetPointCloud", "error": "rpc error: code = Unknown desc = no config for ProductID(0)", "grpc.code": "Unknown", "grpc.time_ms": 1.119}

This is the expected behaviour when no physical device is connected.
Now onto the linux builds.

[ ] Builds and errors with linux/arm64
[ ] Buids and errors with linux/amd64

@seanavery
testbot@82d6661232f1:/host/bin$ ./velodyne-go-module-arm64
./velodyne-go-module-arm64: error while loading shared libraries: libjpeg.so.62: cannot open shared object file: No such file or directory

We indeed need to include libjpeg to build go camera modules


Security Alerts

There are security alerts from Github:
https://github.com/tum-ei-esi/wot-marketplace/network/alerts

They don't exist anymore


Link forms through option sets

Hi all,
Congratulations for the excelent work!
Today, ELMO/NEMO can build option sets or import one from a csv or xls file. A nice improvement would be to add a third way, which would be to link to another form, and choose a field from the form.
What do you think about this way of connecting multiple forms?

Our use case is that we have different objects, which are correlated. Each one of these objects is a form, And in some cases, a form has a "select one" question that has, as options, the data from other form. We have, for example, "networks", which are forms. And we have "organisations", which are also forms. An organization can belong to one or more networks. So we want the user to be able to choose network(s) to which the organization belong.
We are working on a solution which we plan to submit as a PR if you think it could be useful.
The proposal is the following: In the "option sets" page, there will be an option "create option set from form", which will lead to a page where the user will create a name for the option set and choose from a dropdown with all published forms which have at least one key text option. That's it.
Let's say the user created an option set "Networks", where she chose the form "Network". Then, she creates a form "Organisation". When creating questions, she creates a Question "To which network does this organisation belong to?", which is of type "select one", and she chooses the option set "Networks".
When she publishes the form, the option set is populated with all answers from the first key text field in "Network" form.
Whenever there is a new answer to the "Network" form, ELMO will unpublish the "Organization" form, update it's options, and publish it again, with a new formVersion, indicating that it was updated.
Do you think this could be of interest for ELMO/NEMO?

Interesting... I like the re-use of the key question concept.
As a slight tweak I'd suggest not having a 'create option set from form' link, but rather just having a "populate from form" checkbox or dropdown in the regular option set form. That would be more consistent with other parts of the app.
But yes I think this could work!

Hi @smoyth : thanks for the suggestion. We'll take it! We've already done part of it. We hope to present very soon a first version of the PR.

We have it already working 100%! But still using the top menu of the option sets, and not directly in the select one/multiple question form. We expect to change it soon to make it a PR.

 If they did support this, it might make this type of feature easier. It's a long way off but hopeful! You can check their forum for more updates.


GSAGH-508 Update the GsaGH code for the load panel to work

NOTE: As discussed with @SandeepArup, 10.2.10 release is a blocker for this to be merged (as it requires the 10.2.10 GSA installer to compile the API code corresponding to Load Panels. CC: @a-tiwari17


Fix to rotate CameraImage

There were two fundamental problems in CameraImage processing.

The rotation parameter of getCameraImagePredictionList() is not used anywhere. Users imagine that the image will be rotated by the amount of value they input to the rotation argument, but it does not actually work.

In _convertCameraImageToBytes() of the image_utils_isolate.dart file, the camera image is forcibly rotated. Based on portrait mode, Android should rotate 90 degrees, and IOS should not rotate. Android has a code that rotates 90 degrees, so it is normal, but IOS has a code that rotates 270 degrees, so it works abnormally.

This is what I modified to fix it.

Comment out the rotation code inserted in _convertCameraImageToBytes().
-> The rotation action is not related to the method name, so it feels like a side effect, and it should rotate by the rotation value entered by the user, not a fixed value.

In the pytorch_lite.dart file, change all rotation arguments of camera_image related methods to named options and provide default values. Also, rotate the image by the rotation value passed.

-> In portrait mode, it works normally without entering a separate value, and the user can enter the rotation value as needed to get the desired result.

done with the changes, thank you for your contribution


plexamp: add ozone platform hint for wayland

Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Plexamp uses appimageTools.wrapType2 which doesn't seem to accept nativeBuildInputs (it forwards its args to buildFHSEnv) - I copied sourcing the setup hook from another app image because of this.
I can change it to source the binary wrapper setup hook, but it seems like it needs set +u before wrapProgram as otherwise I get:
/nix/store/hpdx3zx4jxpk8qw2ggk2aqfa4y1npja0-make-binary-wrapper-hook/nix-support/setup-hook: line 152: flagsBefore: unbound variable

I've done some testing and it doesn't look like we can use makeBinaryWrapper due to #172583 (we need variable expansion at runtime to set the flag only for Wayland).

Can't seem to run this on X? How are you testing this? I am testing this on Hyprland.
Here's what I did.
WAYLAND_DISPLAY= plexamp

Relevant logs:
[274703:1016/165349.425471:ERROR:wayland_connection.cc(193)] Failed to connect to Wayland display: No such file or directory (2)
[274703:1016/165349.425500:ERROR:ozone_platform_wayland.cc(259)] Failed to initialize Wayland platform
[274703:1016/165349.425506:ERROR:env.cc(257)] The platform failed to initialize.  Exiting.

I can't reproduce your issue under Sway:
$ NIXPKGS_ALLOW_UNFREE=1 WAYLAND_DISPLAY= nix run --impure .#plexamp

Makes Plexamp open under Xwayland (confirmed with nix run nixpkgs#xorg.xlsclients). You can confirm what flags are being passed using bash -x plexamp:
$ bash -x ./result/bin/plexamp
+ exec -a ./result/bin/plexamp /nix/store/3s8h2vldw5mg587hjgmmhvkxh9r2cys3-plexamp-4.11.2/bin/.plexamp-wrapped --ozone-platform-hint=auto --enable-features=WaylandWindowDecorations

$ WAYLAND_DISPLAY= bash -x ./result/bin/plexamp
+ exec -a ./result/bin/plexamp /nix/store/3s8h2vldw5mg587hjgmmhvkxh9r2cys3-plexamp-4.11.2/bin/.plexamp-wrapped

Looks like a Hyprland problem then, running on XWayland somehow is buggy and does not work sometimes.
Same thing happened with https://github.com/NixOS/nixpkgs/pull/346189#issuecomment-2391797898. So CC @fufexan, could you take a look?
❯  hyprctl version -j
{
    "branch": "",
    "commit": "6ae89940c761d4ed4317df0af29e8df41d472091",
    "dirty": false,
    "commit_message": "",
    "commit_date": "2024-10-09",
    "tag": "",
    "commits": "5323",
    "buildAquamarine": "0.4.2",
    "flags": []
}

As for this PR, let's merge this.

Looks like a Hyprland problem then, running on XWayland somehow is buggy and does not work sometimes.
Same thing happened with #346189 (comment). So CC @fufexan, could you take a look?
❯  hyprctl version -j
{
    "branch": "",
    "commit": "6ae89940c761d4ed4317df0af29e8df41d472091",
    "dirty": false,
    "commit_message": "",
    "commit_date": "2024-10-09",
    "tag": "",
    "commits": "5323",
    "buildAquamarine": "0.4.2",
    "flags": []
}

Just checked, seems to work for me.
As for the linked issue, I couldn't get it to work
› DISPLAY=:0 NIXOS_OZONE_WL= WAYLAND_DISPLAY= wire-desktop
[613079:1016/225518.938028:ERROR:wayland_connection.cc(196)] Failed to connect to Wayland display: Connection refused (111)
[613079:1016/225518.938077:ERROR:ozone_platform_wayland.cc(264)] Failed to initialize Wayland platform
[613079:1016/225518.938083:ERROR:env.cc(257)] The platform failed to initialize.  Exiting.
zsh: segmentation fault (core dumped)  WAYLAND_DISPLAY= wire-desktop


fix: Remove un-used id and id_in from RankingWhere

These inputs were never handled in rankings query

Need to fix this one first (https://github.com/snapshot-labs/sx-monorepo/issues/366) else it'll break all queries


Custom serializers ignored on map creation

If DB.treeMap(String, BTreeKeySerializer, Serializer) gets called with a specific key and/or value serializer, and the map does not exist in the database yet, then the catalog entries written for this map will have default serializers. Shouldn't the supplied values get written instead?
(As of 2.0-beta1. See DB.java, line 1355.)

Nice catch. It also affects HashMap and both sets.


CSS

CSS
User Story
As a boot camp student
I want the prework notes to be structured on a webpage
So that I can easily find and read the information
Acceptance Criteria
GIVEN a Prework Study Guide website
WHEN I view the study guide
THEN I see a dark blue header and footer, and four boxes with a shadow

https://github.com/PeaFunk3000/prework-study-guide/pull/8
Closed


B-19935

19935
Integration Review
Summary
This task is to remove unused columns from the ppm_shipments table. The move_to_gbloc view also looked at the pickup_post_code column so that had to be updated to use the new address fields.
Verification Steps for the Author
These are to be checked by the author.

[ ] Tested in the Experimental environment (for changes to containers, app startup, or connection to data stores)
[ ] Have the Agility acceptance criteria been met for this change?

Verification Steps for Reviewers
These are to be checked by a reviewer.

[ ] Has the branch been pulled in and checked out?
[ ] Have the BL acceptance criteria been met for this change?
[ ] Was the CircleCI build successful?
[ ] Has the code been reviewed from a standards and best practices point of view?

Setup to Run the Code

Instructions for starting storybook
Instructions for starting the MilMove application
Instructions for running tests

How to test
Customer PPM Tests:

Access the application as a customer
Create a new move
Create a new PPM Shipment for the move
Finalize the shipment
Finish and sign the move

SC Office PPM Tests:

Access the application
Sign is as a service counselor
Find the move you created
Approve the PPM you created
Submit move details

TOO Office PPM Tests:

Sign into the application
Sign in as a TOO
Find the move you created
Edit the ppm details to ensure updating works

Prime PPM Tests: ( I used move code: 648TQB. Some of the moves don't have fully populated test data and don't work for some functions)

Access the application Prime Simulator
Open a move
Create a new PPM Shipment
Edit the PPM Shipment
Delete the PPM Shipment

Frontend

[ ] There are no aXe warnings for UI.
[ ] This works in Supported Browsers and their phone views (Chrome, Firefox, Edge).
[ ] There are no new console errors in the browser devtools.
[ ] There are no new console errors in the test output.
[ ] If this PR adds a new component to Storybook, it ensures the component is fully responsive, OR if it is intentionally not, a wrapping div using the officeApp class or custom min-width styling is used to hide any states the would not be visible to the user.
[ ] This change meets the standards for Section 508 compliance.

Backend

[ ] Code follows the guidelines for Logging.
[ ] The requirements listed in Querying the Database Safely have been satisfied.

Database
Any new migrations/schema changes:

[ ] Follows our guidelines for Zero-Downtime Deploys.
[ ] Have been communicated to #g-database.
[ ] Secure migrations have been tested following the instructions in our docs.

Screenshots

Fails

:no_entry_sign:

Danger failed to run dangerfile.ts.

Error SyntaxError
Unexpected token u in JSON at position 0
SyntaxError: Unexpected token u in JSON at position 0
    at JSON.parse (<anonymous>)
    at checkYarnAudit (dangerfile.ts:58:24)
    at Object.<anonymous> (dangerfile.ts:94:5)
    at Module._compile (node:internal/modules/cjs/loader:1364:14)
    at requireFromString (/home/circleci/transcom/mymove/node_modules/require-from-string/index.js:28:4)
    at /home/circleci/transcom/mymove/node_modules/danger/distribution/runner/runners/inline.js:161:68
    at step (/home/circleci/transcom/mymove/node_modules/danger/distribution/runner/runners/inline.js:52:23)
    at Object.next (/home/circleci/transcom/mymove/node_modules/danger/distribution/runner/runners/inline.js:33:53)
    at /home/circleci/transcom/mymove/node_modules/danger/distribution/runner/runners/inline.js:27:71
    at new Promise (<anonymous>)

Dangerfile
53|   // Require new src/components files to include changes to storybook
54|   const hasComponentChanges = danger.git.created_files.some((path) => path.includes('src/components'));
55|   const hasStorybookChanges = allFiles.some(
56|     (path) => path.includes('src/stories') || !!path.match(/src\/.*\.stories.jsx?/),
57|   );
--------------------------^
58|
59|   if (hasComponentChanges && !hasStorybookChanges) {
60|     warn('This PR does not include changes to storybook, even though it affects component code.');
61|   }

  Generated by :no_entry_sign: dangerJS against e69ef4aeb4da91bc569b46a7f82406e535fc47f0


iFrames - XPath compatibility issue in internal locator creation.

Issue to raise for SitePrism framework
When creating an iFrame using the SitePrism references. It seems as though we assume any String input is a css styling, and not xpath.
Although...? It seems as though we have a feature that tests this. Needs a bit of in-depth checking.
Environment
All
Expected Behavior
The full locator reference passed as a hashable input to the method is :css, *locators due to a hardcoded check here: https://github.com/natritmeyer/site_prism/blob/master/lib/site_prism/element_container.rb#L214-L225
Actual Behavior
Not sure what impact this seems to have, but there needs to be a bugfix made.

Closing as fixed with PR #375


Can't get xdebug to work with PHP7

I am using PHP 7 and have xdebug uncommented in installed_extras.  When I run php --version I get the following response:
PHP 7.0.4-7ubuntu2.1 (cli) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies
with Xdebug v2.4.0, Copyright (c) 2002-2016, by Derick Rethans

The PHP on the browser doesn't have xdebug enabled.
Any suggestions on getting it to work?

I ran into this when I just reprovisioned. When I restarted the box it worked.


Fix Syntax error in alert manager network policy

There is a small syntax error in the api for a network policy. This should make it easier for people to copy and paste in NPs

The file content is templated from /example/networkpolicies/alertmanager.yaml, could you update there as well?


Order By rand() performance

See https://github.com/concrete5/concrete5-5.7.0/blob/4dba02c5dc1c3ccf37e55b8939f4647497656b8b/web/concrete/blocks/page_list/controller.php#L64
One of the more recent issues reported got me wondering... I've had some really bad experiences with ORDER BY rand() MySQL queries. They are especially bad when you have a large result set.
Problem with these are they can't use indexes, so it does a full table scan. which can really become a chore if you're also joining to other tables. It is also going to be really bad because it's going to go to a temp table, and it's going to likely go to disk because the result set is probably large than the allotted temp table size in memory for MySQL.
A sample query I cobbed together:
SELECT *
FROM Pages p
    INNER JOIN Collections c on p.cID = c.cID
    INNER JOIN CollectionVersions cv on p.cID = cv.cID and cvIsApproved = 1
    LEFT JOIN PagePaths pp on (p.cID = pp.cID and pp.ppIsCanonical = true)
    LEFT JOIN PageSearchIndex psi on p.cID = psi.cID
    LEFT JOIN PageTypes pt on p.ptID = pt.ptID
    LEFT JOIN CollectionSearchIndexAttributes csi on c.cID = csi.cID
    WHERE p.cPointerID < 1 and p.cIsTemplate = 0
ORDER BY rand()
LIMIT 1

The query plan:

On my local computer this query runs in about 20ms. That's with the sample content on a stock install of Concrete5. The minute you start tossing collection versions, additional paths, page aliases, etc, we're only going to compound these times and the growth of our temp tables (likely on disk)
TL;DR this won't scale. I suggest we look into some alternative options for grabbing some random page lists. There are quite a few interesting discussions on stackoverflow and other sites about alternatives. I haven't made myself familiar enough with what exactly this is doing yet to get a good feel for which solution would work best, but I may investigate if I get some time.
For others interested in the topic some pre-googling has been done:

http://stackoverflow.com/questions/1244555/how-can-i-optimize-mysqls-order-by-rand-function
http://explainextended.com/2009/03/01/selecting-random-rows/
http://jan.kneschke.de/projects/mysql/order-by-rand/
http://www.warpconduit.net/2011/03/23/selecting-a-random-record-using-mysql-benchmark-results/
http://forums.mysql.com/read.php?20,406218,407394 (not sure this one applies, definitely wouldn't be a complete fix but might be an easy improvement)

Oopen to


documentation typo

https://transcrypt.org/documentation#hello
duplicate "to connect it":
This small example shows the essentials of Transcrypt: how to connect it to connect it to HTML and how to access the DOM, or in fact any JavaScript API.

Thanks!
Will correct this.

Corrected.


Initial plugin design

This is going to be https://github.com/simonw/llm-python but for Datasette - useful for debugging it in environments like Homebrew.

$ datasette python --version
Python 3.10.10
$ datasette python -m pip list | wc -l
      41

Released: https://pypi.org/project/datasette-python/

Blogged it here: https://simonwillison.net/2024/Jul/12/datasette-python/


Added CloudTrail bucket security: encryption, logging, TLS enforcement, and versioning

First go-round on trying to implement AWS best practices for S3 buckets that get created by the provider.

Updated/tested with logic to only create the logging bucket when desired.

Encryption, Access Logging, Versioning are now disabled by default, and I've added the capability for the user to configure KMS encryption.

Great work Alan, I'll test this on our test environment and report back my findings, if everything looks good, I'll approve and merge! 🎉


[9.x] Database session driver SESSION_DRIVER=database flash messages doesn't work in try/catch block.

Laravel Version: 9.30.0
PHP Version: 8.1.0
Database Driver & Version: MariaDB 10.6.11
Session Driver: database

Description:
Hi,
It seems that when the SESSION_DRIVER is set to database. The session flash message doesn't work when using in try/catch block.
    /**
     * Store a newly created resource in storage.
     *
     * @param  \Illuminate\Http\Request  $request
     * @return \Illuminate\Http\Response
     */
    public function store(Request $request, $uuid)
    {
        $wallet = Wallet::where('uuid', $uuid)
            ->firstOrFail();

        $request->validate([
            'code' => [
                'required',
                'string'
            ]
        ]);

        try {
            $this->voucherRedeemingService
            ->redeem($wallet, $request->code);

            return redirect()
                ->route('admin.wallets.show', $uuid)
                ->with('success', 'Voucher has been redeemed.');
        } catch (Throwable $th) {
            if($th instanceof InvalidDataException) {
                throw ValidationException::withMessages([
                    'code' => $th->getMessage()
                ]);
            }
            return redirect()->back()->with('error', 'Something went wrong during redeeming');
        }
    }

But if I take the flash message e.g. the redirect()->back()->with('error', 'Something went wrong during redeeming') outside the try/catch block it works. this issue is only on the database session driver. the file & redis session driver works well (in or out of try/catch block).
Meaning the issue is that the flash message e.g. in my case its error or success is empty when redirected back. whether its blade view or inertiajs (share flash messages prop).
Video demonstration:
https://user-images.githubusercontent.com/92947803/211647879-ca8d53d1-d7c8-4014-9135-3ce59af2bfe5.mp4
Steps To Reproduce:

Create a new Laravel 9 project.
Set your SESSION_DRIVER to database. Of course, you need to have the sessions table. (php artisan session:table)
Do some crud (store resource e.g post) in the controller with try/catch block. and catching an exception then redirecting back with the flash error message.

@driesvints @timacdonald

@driesvints @timacdonald

I don't think this is good style to "push" and cause some feelings of rush to the maintainers.

@driesvints @timacdonald

I don't think this is good style to "push" and cause some feelings of rush to the maintainers.

oh I really sorry about that. my apologies.

The issue was that my redeem service class was also doing try/catch.


Include FEN as part of a DatatypeProperty

Seems like a duplicate of #19, no?

Yes. I didn't see the issue :)


bugfix: upgrade to version 1.0.1 of redactor

pull request takes into account redactor change of callback handling

semicolon added due to jshint warning

Hi, looks that part that prevent collisions with change callback also should be updated.
Code example:
angular.merge(options, redactorOptions, additionalOptions);
  // prevent collision with the constant values on ChangeCallback
  var changeCallback = (additionalOptions.callbacks && additionalOptions.callbacks.change) ||
    (redactorOptions.callbacks && redactorOptions.callbacks.change);
  if (changeCallback) {
    options.callbacks.change = function(value) {
      updateModel.call(this, value);
      changeCallback.call(this, value);
    };
  }


Catch runtime error when creating a Regex from an invalid expression

Giving an invalid regex string to the function 'regex' crashes Elm. This is bad if you want to create a regex from user input. A function safeRegex could be added that tries to create the regex, and returns 'Just Regex' if it succeeds, or Nothing in case of an error.

This is kind of a duplicate of https://github.com/elm-lang/core/pull/380. I suggest closing it, and continuing discussion there (if need for discussion, rather than decision, exists).

Ah I did not see that. Sorry for duplication and the noise!


issue/75 silt

Fixes #75.

We're going to need to switch to a lerna monorepo, imo. We shouldn't ship silt with the main brookjs implementatio. We should also pull the cli in here as well and close out that repo.
Either that or we extract this out to a separate repo.

I really want types for this. Can we do this together with #56 (and #76)?

We started introducing Flow, but we're running into issues with this bug: https://github.com/facebook/flow/issues/4873
We're going to proceed, writing tests as much as possible to cover the code, but we may not be able to take advantage of types if we can't refine the tuples based on the first value. We'd either need to convert the tuples -> Objects and type them or drop types altogether.

We're going to merge this into next, which is where we're going to start getting everything ready for 1.0.0. We'll set that branch up as the monorepo and pull in brookjs-cli, as well as add brookjs-desalinate, brookjs-silt, and brookjs-loader. In this branch, we'll rewrite the rendering process and fully implement a virtual-dom backed rendering process using diffhtml and brookjs-silt as well as flesh out the updated build process with the loader and built into the cli. Finally, we need to implement the testing infrastructure, which we'll need to decide whether we're going to go with mocha, karma, + chrome, or doing it all in node with AVA or jest.
At that point, we should have everything we need for people to build web apps with brookjs and we can push out 1.0.0! In the meantime, we'll rip out the current animation logic so users don't depend on it, and diffhtml is nearing a release candidate.


Two methods for binary search in 2D matrixes in java added

I have created two algorithms in java that searches for a number(target element) in a 2D matrix using Binary search

don't forget to add a star to this repo

don't forget to add a star to this repo

added a Star to the repo


Better handling of dirty attributes names

@rivella50 , I will review code, but the commit messages do not have the proper formatting:
Example:
#701 Setting an attribute to the same value should not set model as dirty  - finishing first version of better handling dirty attribute names
This way, the commit will show up in the right story and the release script will generate proper release notes: http://javalite.io/release-notes-22
Is  there a way you re-submit this PR with properly formatted comments?

Sure, i will resubmit everything today.


[Ci] Default agent isn't accepting jobs

We have a huge backlog at https://dev.azure.com/lowrisc/opentitan/_settings/agentqueues?queueId=1&view=jobs
@asb can you have a look?

The agent has been active and "listening for jobs" since last for the last ~11 hours, with no error output. I'll try to restart it...

Restarting the agent seems to have done the trick. Unfortunately given there was no error message it's not trivial to increase resiliency on our side (as this failure mode was indistinguishable from there just being no jobs to distribute). I don't suppose Azure DevOps lets us set a warning trigger if the job queue gets above a certain length? That would be pretty useful for flagging issues like this early.

Marking this closed, as the agent is happily accepting new jobs now.


Implement an analytic model

Lots of people in DESC have one of these. Francois pointed out this one:

"The 3x2pt pipeline also has an "emulator" module, to make a fake metacalibration catalog from DC2. Code is here: https://github.com/LSSTDESC/TXPipe/blob/master/txpipe/input_cats.py
Any developments/improvements on that piece of code would fit right in the 3x2pt pipeline."

It would be good if TXProtoDC2Mock could somehow inherit from or call derp - the metacal extras could either be handled by the TXPipe code or just be new properties to emulate (we'd need training data though).
Joe Z followed up with:

"Yes - I was imagining we would make several versions of that [TXPipe] module, depending on:

where we are starting from (extragalactic catalog, DRP, completely fake data)
exactly what is being simulated - just shapes, or photometry + shapes
which shape method we are mocking (metacal requires all the variant columns)"

So, this could be a good place to start in implementing a first "analytic" model in derp. We'd want to get the PC and PZ groups looking at it early on, for comparison with their own analytic emulators.

Oops - this is a duplicate of #8 :-)

Actually, scratch that: I think a simple analytic model (including optional modular noise addition) could be seen as a useful first step towards #8. I'm thinking it would already be useful to predict Object table quantities using a deterministic model that is not fitted to any training data, but just captures the wisdom of astronomers to make a set of sensible predictions. The regressor in #8 would presumably then go one step further by automatically tuning the analytic model's magic numbers.


Make the website responsive for mobile phone 🐱🏍 #35 /issue35

made home page responsive to mobiles (414px)
testing device: iPhone 6/7/8 Plus
also fixed some js error in script.js

@SauravMukherjee44
plz review

Hey, Could you just host your site on GitHub Pages and share the link below.

Resolved Conflicts!

yeah sure

resolved all conflicts
check now @SauravMukherjee44

https://github.com/rahulaarora/Aec-Library-Website/tree/rahulaarora/issue35
here is the branch link @SauravMukherjee44
fork it or download the code and
run it live server to preview changes
looking something like this-->

Great, Just resolve the conflicts again !

sure

done @SauravMukherjee44
merge now
conflicts solved


Add trace_config.textproto as supplementary file for DAC

Additional file for
https://developer.android.com/design-for-safety/privacy-sandbox/guides/fledge/profiling

Moved here instead: https://github.com/privacysandbox/dev-tools


Can't generate access token in PHP

Hi,
I've followed the instructions here and on the Facebook getting-started guide but unfortunately, I can't seem to be able to generate a short-lived access token using this (or any other) library in PHP.
I was able to create an access code (needed to generate the short-lived token), but didn't get any further than that; at least not using PHP. I was able to get a bit further by using the cURL in the terminal, but that's more of a workaround.
I can echo the $apiCall URL in the _makeOAuthCall method, copy and paste the URI into a browser and voilà, everything works as expected and I get a short-lived access token. The same goes for generating a long-lived access token or refreshing an existing long-lived token, no dice using PHP and cURL. No problem using HTTP in any browser. I've tried both methods on an entirely different web server (different IP, different location, different hoster) with the same results.
When using PHP and cURL, with or without this library, I always get the following response:
IGApiException: Invalid OAuth 2.0 Access Token with error code 190
When calling any of the three mentioned endpoints in a browser directly, everything works like a charm. What gives?
Here's a link to a post on stackoverflow regarding this issue: https://stackoverflow.com/questions/63601362/refreshing-instagram-long-lived-access-token-works-in-browser-http-but-not-php
Any help is greatly appreciated, thanks!

Wow, after spending several days on the issue, finally posting this issue, merely 40 minutes later I found the solution.
For anyone running into similar issues, in my case the problem was http_build_query in conjunction with the fact that both web servers had the following php.ini setting set:
arg_separator.output = "&"
the default setting is:
arg_separator.output = "&"
To solve the issue, either change http_build_query to use & instead of & like so:
http_build_query($yourParams, null, '&');
or simply revert the changed php.ini setting back to it's default (at your own risk)


ColAccel crashes on startup

I have the downgraded copy of GTA IV from steam to 1070 and ColAccel did work yesterday but now its not working. I have a log of it

https://www.mediafire.com/file/003rtjcds80yz8c/fastman92limitAdjuster.log/file


Implement Deref for LineBuffer

This removes the need for get_buffer() everywhere.

That's definitely cleaner. Much appreciated


[tool_crash] FileSystemException: Failed to decode data using encoding 'utf-8', null

Command
flutter build apk

Steps to Reproduce

...
...
...

Logs
FileSystemException: Failed to decode data using encoding 'utf-8', null
#0      _File._tryDecode (dart:io/file_impl.dart:564:7)
#1      _File.readAsStringSync (dart:io/file_impl.dart:584:7)
#2      ForwardingFile.readAsStringSync (package:file/src/forwarding/forwarding_file.dart:96:16)
#3      AndroidPlugin._getSupportedEmbeddings (package:flutter_tools/src/platform_plugins.dart:158:53)
#4      AndroidPlugin._supportedEmbeddings (package:flutter_tools/src/platform_plugins.dart:112:71)
#5      AndroidPlugin.toMap (package:flutter_tools/src/platform_plugins.dart:104:30)
#6      _extractPlatformMaps (package:flutter_tools/src/flutter_plugins.dart:341:40)
#7      _writeAndroidPluginRegistrant (package:flutter_tools/src/flutter_plugins.dart:357:5)
#8      injectPlugins (package:flutter_tools/src/flutter_plugins.dart:1065:11)
<asynchronous suspension>
#9      FlutterProject.ensureReadyForPlatformSpecificTooling (package:flutter_tools/src/project.dart:338:5)
<asynchronous suspension>
#10     FlutterCommand.verifyThenRunCommand (package:flutter_tools/src/runner/flutter_command.dart:1260:7)
<asynchronous suspension>
#11     FlutterCommand.run.<anonymous closure> (package:flutter_tools/src/runner/flutter_command.dart:1125:27)
<asynchronous suspension>
#12     AppContext.run.<anonymous closure> (package:flutter_tools/src/base/context.dart:150:19)
<asynchronous suspension>
#13     CommandRunner.runCommand (package:args/command_runner.dart:209:13)
<asynchronous suspension>
#14     FlutterCommandRunner.runCommand.<anonymous closure> (package:flutter_tools/src/runner/flutter_command_runner.dart:288:9)
<asynchronous suspension>
#15     AppContext.run.<anonymous closure> (package:flutter_tools/src/base/context.dart:150:19)
<asynchronous suspension>
#16     FlutterCommandRunner.runCommand (package:flutter_tools/src/runner/flutter_command_runner.dart:236:5)

[✓] Flutter (Channel stable, 2.5.3, on Microsoft Windows [Version 10.0.19041.685], locale zh-CN)
    • Flutter version 2.5.3 at D:\flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 18116933e7 (6 weeks ago), 2021-10-15 10:46:35 -0700
    • Engine revision d3ea636dc5
    • Dart version 2.14.4
    • Pub download mirror https://pub.flutter-io.cn
    • Flutter download mirror https://storage.flutter-io.cn

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
    • Android SDK at D:\SDK
    • Platform android-31, build-tools 30.0.3
    • Java binary at: D:\Program Files\Android\Android Studio\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)
    • All Android licenses accepted.

[✓] Chrome - develop for the web
    • Chrome at C:\Program Files\Google\Chrome\Application\chrome.exe

[✓] Android Studio (version 2020.3)
    • Android Studio at D:\Program Files\Android\Android Studio
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)

[✓] VS Code (version 1.62.3)
    • VS Code at C:\Users\chen\AppData\Local\Programs\Microsoft VS Code
    • Flutter extension version 3.28.0

[✓] Connected device (3 available)
    • Redmi K30 Pro Zoom Edition (mobile) • 511fdff5 • android-arm64  • Android 11 (API 30)
    • Chrome (web)                        • chrome   • web-javascript • Google Chrome 93.0.4577.82
    • Edge (web)                          • edge     • web-javascript • Microsoft Edge 96.0.1054.29

• No issues found!

Flutter Application Metadata
Type: app
Version: 1.0.0+1
Material: true
Android X: false
Module: false
Plugin: false
Android package: null
iOS bundle identifier: null
Creation channel: stable
Creation framework version: 18116933e77adc82f80866c928266a5b4f1ed645
Plugins
amap_flutter_map
camera-0.9.4+3
camera_web-0.2.1+1
connectivity-3.0.6
connectivity_for_web-0.4.0+1
connectivity_macos-0.2.1+2
device_info_plus-3.1.1
device_info_plus_macos-2.2.0
device_info_plus_web-2.1.0
flutter_plugin_android_lifecycle-2.0.4
fluttertoast-8.0.8
heic_to_jpg-0.2.0
image_picker-0.8.4+4
image_picker_for_web-2.1.4
jpush_flutter-2.1.5
package_info-2.0.2
path_provider-2.0.7
path_provider_android-2.0.6
path_provider_ios-2.0.6
path_provider_linux-2.1.1
path_provider_macos-2.0.2
path_provider_windows-2.0.4
permission_handler-8.3.0
photo_manager-1.3.10
shared_preferences-2.0.8
shared_preferences_linux-2.0.3
shared_preferences_macos-2.0.2
shared_preferences_web-2.0.2
shared_preferences_windows-2.0.3
sqflite-2.0.0+4
url_launcher-6.0.12
url_launcher_linux-2.0.2
url_launcher_macos-2.0.2
url_launcher_web-2.0.4
url_launcher_windows-2.0.2
video_player-2.2.7
video_player_web-2.0.4
webview_flutter-2.3.1
webview_flutter_android-2.2.1
webview_flutter_wkwebview-2.4.0
wechat_kit-3.0.1

Hi @VencentYChen, thanks for filing the issue, there is already a similar issue describing this case https://github.com/flutter/flutter/issues/65021, You may follow up there for further updates. Closing this issue as a duplicate if you disagree feel free to comment and I will reopen it.
Thank you.


Can Agentless Execute the generated code?

I would like to know:

If, once a fault is localized and the agent enters the repair phase and generates code patches, it can execute the code?
Additionally, if multiple patches are created, what mechanism is used to select the best patch, and on what basis are these patches distinguished?
Finally, does it commit the code changes to the files?

Sorry for the delayed reply,

If, once a fault is localized and the agent enters the repair phase and generates code patches, it can execute the code?

Currently we do not have any implemention that directly execute any arbitary code (We do run previous regression tests as a filtering steps)

Additionally, if multiple patches are created, what mechanism is used to select the best patch, and on what basis are these patches distinguished?

We do generate multiple patches per bug (this is something that be configured). For the selection mechanism we first filter out any patches that do not pass the previous regression tests, apply normalization, and then perform majority voting to select the final patch. Please see the paper for more detailed description.

Finally, does it commit the code changes to the files?

Currently, all patches we generate are in the git diff format. Therefore, one can simply run git apply directly on our generated patch to apply and then commit the code changes.

Sorry for the delayed reply,

If, once a fault is localized and the agent enters the repair phase and generates code patches, it can execute the code?

Currently we do not have any implemention that directly execute any arbitary code (We do run previous regression tests as a filtering steps)

Additionally, if multiple patches are created, what mechanism is used to select the best patch, and on what basis are these patches distinguished?

We do generate multiple patches per bug (this is something that be configured). For the selection mechanism we first filter out any patches that do not pass the previous regression tests, apply normalization, and then perform majority voting to select the final patch. Please see the paper for more detailed description.

Finally, does it commit the code changes to the files?

Currently, all patches we generate are in the git diff format. Therefore, one can simply run git apply directly on our generated patch to apply and then commit the code changes.

I could not find the code doing "regression test", could you please point out its location? Thanks


Create OpenCV.gitignore

Reasons for making this change:
This is help for OpenCV Library.
Links to documentation supporting these rule changes:
http://docs.opencv.org/2.4/doc/tutorials/introduction/linux_install/linux_install.html
Comments:
OpenCV.gitignore is helpful for Mac and Linux users.

-1 This is a CMake gitignore.
The only thing that's different between CMake.gitignore and this is the .DSStore. OpenCV has nothing particularly different about it's build system in ANY language (C/C++, Python, Java) that requires a unique .gitignore

Seconding what @stephengroat said.


Lognormal distribution abnoramilties

Hello I was simulating a simple lognormal distribution with mean of 100 and standard deviation of 10, but when I use the risklognormal distribution I get extremely huge values.
Then I triend using as input to the function mean of 2 and sdev of 1 as if I needed to apply logarithm to the values but still have huge values which, after doing the 1,000 iterations, do not have a mean nor sdev close to what I input.
Do you know what's the problem?
With other software If I simulate lognormal(100,10) i get a mena to the iterations close to 100 and sdev close to 10.

Please see https://github.com/pyscripter/XLRisk/issues/14#issuecomment-1977479723


Optimize nonce validation in inbound channel

This PR resolves the issue https://linear.app/snowfork/issue/SNO-147/optimize-nonce-validation-in-inbound-channels

Resolves SNO-147


PR for Review

What does this PR do?
Opens project for review before merging with master
Description of Task to be completed?
Peer reviews for CP1.
How should this be manually tested?
Run nosetests --with-coverage --with-coverage --cover-erase

Changes Unknown when pulling 86307f5e362b15bdb4daa335b2860df0de7e85dd on develop into ** on master**.

Changes Unknown when pulling 47acc7252a562266d77d5793de4196f8e6733e43 on develop into ** on master**.

Changes Unknown when pulling 02b70ce2432bdc85e9dadf77a5c06df85fbfcbba on develop into ** on master**.

Changes Unknown when pulling 25ec33a64638814d48afa0d566b0f8d4b6061659 on develop into ** on master**.


Integration test

Do you guys feel the need for integration test?
Currently there are individual test per module (lightcycle-lib, lightcycle-processor, lightcycle-api) but there are no integration test.
This time I asked first because I want to make sure there are no special reason for not implementing integration test.
Thanks!

It sounds like a good idea.
What and how would you like to do test ?

So what I imagine is, we can use the basic sample, and modify it a little bit, and verify if the processor working well with the lib.
What to test :
Every Activity/Fragment callback
How to test :
Instrumentation test
For example show a toast on every callback and check if every toast is shown or not.
Unit test
Build the Activity/Fragment using Roboelectric, call the Activity/Fragment lifecycle and make sure every callback is called.
Maybe we can start with Activity first and then Fragment later.
Please let me know if you have any feedback or other idea!

I am concerned with testing on the top of the UI (toasts in this case).
What do you think about testing on an activity/fragment and access to its fields to check in memory states ?
Like assertThat(activity.lightcycle.isOnStartedCalled()).isTrue().
A little similar to https://github.com/JakeWharton/butterknife/tree/master/butterknife-integration-test

Hmmm, Actually I'm not attached to toast, we can change it to other view if you want. Can you give me the reason why are you concerned with testing on the top of the UI?
And yes,  I agree with that like I wrote above, I'm planning to use Roboelectric to do that test. What do you think?
If this looks good to you, I'll implement the callback test first and leave the instrumentation test for later (or might not need to implement it at all)

Hey, I like your idea to implement integration tests with robolectric.
In this case views are not needed, because we can just assert on in memory
(non-ui) states (sharing an API with the activity/fragment).
Using views as a communication layer between the activity and the test is
to me not necessary and more complex.
Does it make sense?
Am 17.11.2016 1:35 vorm. schrieb "Niko Yuwono"<EMAIL_ADDRESS>
Hmmm, Actually I'm not attached to toast, we can change it to other view
if you want. Can you give me the reason why are you concerned with testing
on the top of the UI?
And yes, I agree with that like I wrote above, I'm planning to use
Roboelectric to do that test. What do you think?
If this looks good to you, I'll implement the callback test first and
leave the instrumentation test for later (or might not need to implement it
at all)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/soundcloud/lightcycle/issues/71#issuecomment-261118408,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAhkcdxuVKYzZojYlHkhO0gjCADSgTpSks5q-6EzgaJpZM4KzeKy
.

OK! Let's use roboelectric for the callback check in memory assertion!
Thanks for the feedback!
Will try to get some time this weekends to implement that.
Will send a pull request after that 😃

🔥
Am 17.11.2016 9:54 vorm. schrieb "Niko Yuwono"<EMAIL_ADDRESS>
OK! Let's use roboelectric for the callback check in memory assertion!
Thanks for the feedback!
Will try to get some time this weekends to implement that.
Will send a pull request after that 😃
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/soundcloud/lightcycle/issues/71#issuecomment-261190069,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAhkcfDPJ1KPCQwzxqXFsw6qQ-FYQRiyks5q_BY1gaJpZM4KzeKy
.