DrawTarget improvements

As previously discussed in #326, the following changes to the DrawTarget trait were suggested:

Replace draw_image by draw_rectangle_iter(&mut self, rect: &Rectangle, iter: Iterator<Item = C>)
draw_rectangle_iter can be used to fill a rectangular region of the target with the colors provided by the iter. This can e.g. be used for images and font rendering.
Add a fill_rectangle(&mut self, rect: &Rectangle, color: C) method
This fills the given rectangle with a single color, which might be more efficient that using draw_rectangle_iter if the display supports filling of memory regions.
Change draw_rectangle to use fill_rectangle or draw_rectangle_iter
For opaque styled rectangles without a stroke the default impl of draw_rectangle can call directly fill_rectangle with styled.primitive as the rectangle.
Styled rectangles without a fill can be drawn using 4 individual fill_rectangle calls.
Drawing rectangles with fill and stroke can be implemented using 2 overlapping fill_rectangle calls, 5 non overlapping fill_rectangle calls or a single draw_rectangle_iter call.
Add docs for driver authors that suggest to implement fill_rectangle and draw_rectangle_iter instead of the other styled primitve draw_... methods.

Open questions:

[ ] draw_rectangle_iter should be able to handle iterators that are shorter than rect.size.width * rect.size.height without leaving the display in an invalid state.
Should we provide any method to make this easier for driver implementations or simply state this in the docs?
[ ] draw_rectangle_iter needs a better name, that can't be easily confused with draw_rectangle
[ ] Decide if draw_rectangle for styled rectangles with fill and stroke should be implemented using fill_rectangle or draw_rectangle_iter
Using 2 overlapping fill_rectangle calls might not be a good idea if we plan to support transparency in the future.
[ ] Would something like draw_bounded_iter(&mut self, bound: Rectangle, iter: Iterator<Item=Pixel<C>>) be useful?
This method would be used for iterators that don't change every pixel in the given rectangle, but are guaranteed to only change pixels inside the given bounding box. This could e.g. be used for lines or transparent text.
I'm not sure if this would provide any benefits for drivers, but maybe it could be used to implement some kind of caching.
[ ] DrawTarget::size -> #263

Thanks for opening a new issue. Some comments:

Decide if draw_rectangle for styled rectangles with fill and stroke should be implemented using fill_rectangle or draw_rectangle_iter
Using 2 overlapping fill_rectangle calls might not be a good idea if we plan to support transparency in the future.

Overlapping rects would also be pretty inefficient, so I'd either go with the now-edited-out 5 rects approach, or the current Rectangle iterator over stroke/fill. Whatever we choose should be able to handle rounded corners when #83 is done.

draw_rectangle_iter needs a better name, that can't be easily confused with draw_rectangle

draw_contiguous_iter, with draw_bounded_iter renamed to draw_sparse_iter? That's about all I've got at the moment.

Add docs for driver authors that suggest to implement fill_rectangle and draw_rectangle_iter instead of the other styled primitve draw_... methods.

Would it be worth adding #[deprecated] notices to the other methods? That would provide a less painful migration path where 0.7 deprecates and 0.8 removes them.

Should we provide any method to make this easier for driver implementations or simply state this in the docs?

Do you have an idea of what that method might look like? I'm leaning towards making driver authors aware of it instead of providing a method.

Would something like draw_bounded_iter(&mut self, bound: Rectangle, iter: Iterator<Item=Pixel>) be useful?

Oh, that's what I thought draw_rectangle_iter did. In any case, differentiating between contiguous and non-contiguous iterators might be a useful optimisation. Would it be dangerous to include it with a default impl to draw_rectangle_iter?

DrawTarget::size -> #263

Did you get any further than the last comment you left on that thread? Is there some Into<> magic we can try?

Overlapping rects would also be pretty inefficient, so I'd either go with the now-edited-out 5 rects approach, or the current Rectangle iterator over stroke/fill.

If communication if the bottleneck and the display provides a hardware accelerated fill command the overlapping rects could be the fastest. But I think one of the other approaches will be better for a larger number of cases.
What do you mean by "now-edited-out 5 rects approach"? It's still mentioned in the OP. Or do you mean something else?

Whatever we choose should be able to handle rounded corners when #83 is done.

Didn't we discuss this and came to the conclusion that the corner radius is a parameter of the shape and not a style property? Which means that RoundedRectangle should be a separate struct.

Would it be worth adding #[deprecated] notices to the other methods? That would provide a less painful migration path where 0.7 deprecates and 0.8 removes them.

I thought you wanted to keep these methods. Deprecating them now to remove them later doesn't make a lot of sense IMO. There are only a few drivers that use these features so this would only affect a very limited number of people. And if we decide to remove them we should just remove them now.

Do you have an idea of what that method might look like? I'm leaning towards making driver authors aware of it instead of providing a method.

I'm not sure yet, but I would prefer this function not to panic if the iterator is to short. We will need to find a solution for the default impl anyway and maybe this could also be exported to be used by the drivers. An iterator adapter that simply repeats the last color could be a possible solution. But the most important aspect is to document the expected behavior when a too short or empty iterator is passed to this function.

Oh, that's what I thought draw_rectangle_iter did. In any case, differentiating between contiguous and non-contiguous iterators might be a useful optimisation. Would it be dangerous to include it with a default impl to draw_rectangle_iter?

draw_rectangle_iter draws all pixels inside the rect, which draw_bounded_iter doesn't. So it's not possible to implement draw_bounded_iter with draw_rectangle_iter, but the other way around would work.

Did you get any further than the last comment you left on that thread? Is there some Into<> magic we can try?

It's been a while since I looked at this. But I think the plan was to change DrawTarget to use an associated type for the color and only support one color format.
One advantage of this approach is that it's easier to support hardware color conversion (like in some STM32) this way. The display driver could use a typestate to represent the currently set up hardware color conversion and make sure that all drawing routines use this color format.
To support software color conversions we would need to provide additional methods, that might be implemented as extension traits on Drawables or the DrawTarget, but I would need to look at the code before suggesting a good solution for this.

If communication if the bottleneck and the display provides a hardware accelerated fill command the overlapping rects could be the fastest. But I think one of the other approaches will be better for a larger number of cases.

This is the default impl, so yeah more cases outweighs ultimate speed.

What do you mean by "now-edited-out 5 rects approach"?

Hm, I saw it disappear. You must've moved it? But yes, I still mean the same thing in the OP :)

Didn't we discuss this and came to the conclusion that the corner radius is a parameter of the shape and not a style property? Which means that RoundedRectangle should be a separate struct.

My sieve-like brain does not recall this lol. Can you find that discussion and add a note to #83? If not, I'll add a note there anyway.

I thought you wanted to keep these methods. Deprecating them now to remove them later doesn't make a lot of sense IMO. There are only a few drivers that use these features so this would only affect a very limited number of people. And if we decide to remove them we should just remove them now.

To get a wider opinion on this, I was thinking of posting a message in the e-g Matrix room. Here's a draft:
For anybody that's written a display driver with e-g support, is it useful having methods to draw primitives like `draw_circle()`, `draw_triangle()`, etc?

We're talking about changing `DrawTarget` to add some more general and hopefully more useful methods, but I'm stuck on whether to remove the primitive-specific methods or not and could use some input.

There are a couple of impls out there for optimised versions `draw_rectangle` but they're pretty complex and are quite easy to get wrong, so it might be better to not have them in favour of letting e-g do more of the work internally for consistent results across drivers.

The proposed additions add methods for:

* Filling a given area with a solid colour
* Filling an area with contiguous colours (no transparency) from an iterator that provides pixel data
* (possibly) Filling an area with non-contiguous colours (on/off transparency) from an iterator that provides pixel data

Anything I should change?

I'm not sure yet, but I would prefer this function not to panic if the iterator is to short.

Couldn't the method just return when the iterator is empty? Framebuffer drivers would leave remaining pixels alone, and immediate mode displays would simply not send the data. I don't see where a panic might come from.

draw_rectangle_iter draws all pixels inside the rect, which draw_bounded_iter doesn't.

Understood, thanks for explaining.

It's been a while since I looked at this. But I think the plan was to change DrawTarget to use an associated type for the color and only support one color format.

So we fix DrawTarget::size() but leave the colour conversions for another PR, right?

Anything I should change?

The problems mentioned in the paragraph about draw_rectangle applies to all draw_... routines for styled primitives. Rectangles might be the easiest example to implement and getting pixel perfect circles and thick lines is much harder.
It should also mention that future versions will add additional styling attributes that could be ignored by driver impls if they aren't carefully ported to the new version.
I would use rectangular area instead of area in the proposed additions section

Couldn't the method just return when the iterator is empty? Framebuffer drivers would leave remaining pixels alone, and immediate mode displays would simply not send the data. I don't see where a panic might come from.

Never mind, I wasn't thinking clearly when I wrote that. You are right that this is something the driver needs to handle and we don't have to care about.

So we fix DrawTarget::size() but leave the colour conversions for another PR, right?

Let's first decide what to do with the drawing methods in DrawTarget and then make a plan on how to implement all changes to DrawTarget.

Thanks for the feedback. Here's a second go:
For anybody that's written a display driver with e-g support, is it useful having the methods
`draw_line`, `draw_triangle`, `draw_rectangle`, `draw_circle`, `draw_ellipse` and `draw_image` for
drawing specific e-g objects?

We're talking about changing `DrawTarget` to add some more general and hopefully more useful
methods, but I'm stuck on whether to remove the primitive-specific methods or not and could use some
input.

There are a couple of impls out there for optimised primitive draw methods, however they're quite
complex, are easy to get wrong and are unlikely to be pixel-perfect with either other hardware impls
or e-g itself. Rectangles are reasonably simple, but pixel perfect lines, circles, etc are very
difficult to make consistent.

There's also the concern that new style properties added to e-g in the future will be silently
ignored or improperly handled by the optimised driver impl, leading to further inconsistency between
displays, or even different primitive styles.

The proposed additions add methods for:

1. Filling a given rectangular area with a solid colour
2. Filling an rectangular area with contiguous colours (no transparency) from an iterator that
   provides pixel data
3. (possibly) Filling an area with non-contiguous colours (on/off transparency) from an iterator
   that provides pixel data

This would then allow the removal of the methods listed in the first paragraph.

If that covers all the bases I'll post it in the e-g matrix room later.

Let's first decide what to do with the drawing methods in DrawTarget and then make a plan on how to implement all changes to DrawTarget.

:+1:

Thanks for the feedback. Here's a second go:

LGTM

Hopefully I've got an accurate account of what came out of the discussion on Matrix. It seems the consensus is that it's fine to remove draw_line, draw_triangle, draw_rectangle, draw_circle, draw_ellipse and draw_image and replace them with the proposed DrawTarget methods as mentioned above:

Filling a given rectangular area with a solid colour
Filling an rectangular area with contiguous colours (no transparency) from an iterator that
provides pixel data
Filling an area with non-contiguous colours (on/off transparency) from an iterator
that provides pixel data

I haven't seen it mentioned either way, but another point that came up was the removal of draw_pixel. I think this might be a good idea. If drawing individual points is desired, perhaps e-g could provide a pixel struct that produces an iterator with one item in it. Another option is to pass in a core::iter::once and the appropriate Size (which is Size::zero() if I understand #182 correctly).
To distill the conversation so far, I believe the complete trait would look something similar to the following (with better names eventually):
trait DrawTarget<C> {
    fn size(&self) -> Size;

    /// Fill a given rectangle with pixels where not all pixels may be set (i.e. has binary transparency)
    ///
    /// E.g, `Circle`, `Triangle`, `Line`, `Text`.
    fn sparse_iter(&mut self, area: Rectangle, pixels: Iter<Item = Pixel<C>>);

    /// Fill a given rectangle with a contiguous list of pixel values (i.e. has no transparency)
    ///
    /// E.g, `Rectangle`, `Image`.
    fn fill_iter(&mut self, area: Rectangle, pixels: Iter<Item = Pixel<C>>);

    /// Fills all pixels inside the given rectangle with a single colour
    fn fill(&mut self, area: Rectangle, color: C);
}

Some other interesting points came out of the Matrix chat:

We have the concept of a block, but what about lines and individual pixels? IMO these are special cases of a block so I don't think we need to specifically cater for them.
[ ] Should fill be removed? The suggestion was that core::iter::repeat could be passed to fill_iter to produce the same end result. Another option is to provide a default impl that falls back to fill_iter but is overrideable. Taking the SSD1331 as an example, it can draw filled rectangles in hardware so having fill as an optimisation path would be useful for at least that display. I'm leaning towards keeping fill in the trait.
[ ] Is there a way to efficiently handle single pixels, or do we even need to? I can't think of a display that can efficiently set individual pixels.

Thanks for bearing with me on this @rfuest :grimacing:.  I think this might be a good idea. If drawing individual points is desired, perhaps e-g could provide a pixel struct that produces an iterator with one item in it. Another option is to pass in a core::iter::once and the appropriate Size (which is Size::zero() if I understand #182 correctly).

Pixel is a Drawable which could generate the appropriate iter for drawing single pixels. This will have a higher overhead than the current implementation, but should be OK because this isn't the preferred way of drawing pixels anyway. We could include an example that uses iter::from_fn to show an relatively easy way of drawing pixels without having to implement a iterator struct.

We have the concept of a block, but what about lines and individual pixels? IMO these are special cases of a block so I don't think we need to specifically cater for them.

For individual pixels I would still keep the draw_iter method (see code below). For lines we should consider using fill to draw lines when they are axis aligned, which can be much faster than using draw_iter, which is necessary for thick slanted lines.

Should fill be removed? The suggestion was that core::iter::repeat could be passed to fill_iter to produce the same end result. Another option is to provide a default impl that falls back to fill_iter but is overrideable. Taking the SSD1331 as an example, it can draw filled rectangles in hardware so having fill as an optimisation path would be useful for at least that display. I'm leaning towards keeping fill in the trait.

Yes, we should definitively keep fill. The can even makes sense if there is no hardware fill support, like in the simulator, which overrides draw_rectangle with an optimized version.
My suggestion for DrawTarget: (don't pay attention to the names, I changed my mind half way through writing this)
trait DrawTarget {
    // using an associated type fixes #263 and color conversion shouldn't be handled here IMO
    type Color : PixelColor;

    fn size(&self) -> Size;

    // We could implement `sparse_iter` as:
    // (for images, circles, unfilled rectangles and text without bg)
    fn fill_from_sparse_iter(
        &mut self, area: &Rectangle, pixels: Iter<Item = Option<Self::Color>>
    );
    // This would guarantee the iteration order from top left to bottom right
    // and return `None` for transparent pixels. That should make it easier to
    // implement bundling of individual pixel updates into blocks.

    // But this wouldn't work for lines or other drawables that don't use the
    // top left to bottom right iteration order, so we also need the good old `draw_iter`:
    fn draw_iter(&mut self, pixels: Iter<Item = Pixel<Self::Color>>);
    // The drivers might still be able to optimize this by generating blocks,
    // but it's harder to implement because the next pixel could be anywhere.

    // If this only fills the given rectangle the item doesn't need to provide a coordinate IMO
    // and this way you could also use `target.fill_iter(&rect, iter::repeat(BinaryColor::On))`.
    // The driver can easily generate the required coordinates by using:
    // `area.points().zip(colors)` which I think is really neat.
    fn fill_from_iter(&mut self, area: &Rectangle, colors: Iter<Item = Self::Color>);

    fn fill_solid(&mut self, area: &Rectangle, color: Self::Color);
}

Pixel is a Drawable which could generate the appropriate iter for drawing single pixels.

... but should be OK because this isn't the preferred way of drawing pixels anyway.

Sounds good to me

For lines we should consider using fill to draw lines when they are axis aligned

This is very true, but I was referring to scanlines. I don't think they're anything we need to specifically cater for at the moment though.

Yes, we should definitively keep fill.

Great, we're on the same page :)

In your proposal, DrawTarget now takes three different impls of iter. How would that work for e-g items? Would they still only need to implement Iterator<Item = Pixel<C>>?

This is very true, but I was referring to scanlines. I don't think they're anything we need to specifically cater for at the moment though.

I agree, a scanline is simply a 1px high rectangle.

In your proposal, DrawTarget now takes three different impls of iter. How would that work for e-g items? Would they still only need to implement Iterator<Item = Pixel<C>>?

The main method items need to implement is Drawable::draw which is responsible for calling the correct methods in DrawTarget.
Some drawable won't technically need to implement iterators at all. A styled rectangle can be drawn by calling fill_solid multiple times in draw, without any custom iterator.

If you want to give it a try go ahead, I don't have much time to work on this at the moment.

If I find a spare moment I want to finish #314 first, before starting to work on something else. But if I should unexpectedly find many spare moments I'll let you know before starting to work on this.

Sounds good. Let me know if I can do anything to help.

FYI, I'm gonna grab this and have a go.


Make "speed inflection point" configurable, in the exponentiated version of the speed transform

My understanding is that the exponentiated nonlinear speed transform in simulator.c (the line
speed = pow(speed, plant->n1);

when nonlinType = 1) will always go through the point (1, 1), which I'm calling the "speed inflection point". Speeds below 1 are slowed down, and speeds above 1 are sped up. From the paper, the relevant equation is s_out = s_in ** p. (p is n1 in the code.)
My understanding is also that the speed inflection point of 1 target distance per sec isn't special, and other speed inflection points might be better. In my own decoder, I introduce the r parameter to make the equation s_out = r * (s_in / r) ** p. Instead of going through (1, 1), it goes through (r, r). Speeds below r are slowed down, and speeds above r are sped up.
I wanted to be able to include the r parameter in this automated simulation / optimization process, and it turned out to be a very simple 1-line change!
speed = plant->n2 * pow(speed / plant->n2, plant->n1);

I utilized the unused field n2 to represent r, which seemed appropriate since makeBciSimOptions.m says:

configures the nonlinearity in different ways depending on nonlinType

=====
Just sharing in case helpful, and lemme know if I'm missing anything.
EDIT: If the goal is for the compiled files to be in-sync with the source code, someone needs to recompile for Windows and Mac.

I've added a bugfix to this PR as well.
nonlinType of 2 or 3 used the speedRatio variable to scale the vel elements, but nonlineType of 1 did not, instead scaling by speed itself. I believe this is not intended.
For example, if n1 (or, p) were 1, the speed transform should not change the speed, but as implemented, it would change the speed.
My fix is to use speedRatio in the nonlinType==1 branch, to match the other branches.


Trivy param security-checks -> scanners

Trivy's Action renamed the security-checks parameter to scanners.

This PR-based workflow isn't great at handling forks, so somebody might be stuck pulling changes to the main repo.  Thankfully it's super small.

Replaced by https://github.com/bcgov/onroutebc/pull/276.


Pod & Container Lifecycle

Hello,
Cross post from kubernetes/kubernetes
Problem:
Insufficient information about the pod lifecycle and how a pod's state maps to the pod's containers' states. Specifically the documentation states that "The phase of a Pod is a simple, high-level summary of where the Pod is in its lifecycle. The phase is not intended to be a comprehensive rollup of observations of Container or Pod state, nor is it intended to be a comprehensive state machine" Pod Lifecycle
Proposed Solution:
Specify the pod lifecycle and how a pod's state maps to the pod's containers' states, exit codes, and liveness probes.
The following statements reflect my understanding of the pod's lifecycle, please do post comments and corrections as appropriate.
Pod Lifecycle

Container Lifecycle

The Kubelet determines a pod's state exclusively based on the pod's

init containers'

state
exit code

main containers'

state
exit code
liveness probe

Pending
When a Pod is in the state Pending then

none of the Pod's Init Containers are in the state Terminated[Failure]
all of the Pod's Main Containers are in the state Waiting

fact {
    all p : Pod |
        p.status = Pending <=> {
            // Init Container
            no  c : p.init_containers | c.status = Terminated_Failure
            // Main Container
            all c : p.main_containers | c.status = Waiting
        }
}

Running
When a Pod is in the state Running then

all of the Pod's Init Containers are in the state Terminated[Success]
at least one of the Pod's Main Containers is in the state Running
none of the Pod's Main Containers are in the state Terminated[Failure]
none of the Pod's Main Containers are dead

fact {
    all p : Pod |
        p.status = Running <=> {
            // Init Containers
            all  c : p.init_containers | c.status = Terminated_Success
            // Main Containers
            some c : p.main_containers | c.status = Running
            no   c : p.main_containers | c.status = Terminated_Failure
            no   c : p.main_containers | isDead[c]
        }
}

Success
When a Pod is in the state Success then

all of the Pod's Init Containers are in the state Terminated[Success]
all of the Pod's Main Containers are in the state Terminated[Success]
all of the Pod's Main Containers were live

fact {
    all p : Pod |
        p.status = Success <=> {
            // Init Containers
            all c : p.init_containers | c.status = Terminated_Success
            // Main Containers
            all c : p.main_containers | c.status = Terminated_Success
            all c : p.main_containers | isLive[c]
        }
}

Failure
When a Pod id in the state Failure then

all of the Pods Init Container are in the state Terminated
all of the Pod's Main Containers are in the state Terminated
and

at least one of the Pod's Init Containers is in the in the state Terminated[Failure] or
at least one of the Pod's Main Containers is in the in the state Terminated[Failure] or
at least one of the Pod's Main Containers was dead

fact {
    all p : Pod |
        p.status = Failure <=> {
            // Init Containers
            all c : p.init_containers | c.status = Terminated
            // Main Containers
            all c : p.main_containers | c.status = Terminated
            // Init & Main Container
            (some c : p.init_containers | c.status = Terminated_Failure) or (some c : p.main_containers | c.status = Terminated_Failure) or (some c : p.main_containers | isDead[c])
        }
}

Caveats
Note that the current state is trailing the genuine state, since Kubernetes in general and the Kubelet in special use polling.

current state at t: Pending, genuine state at t: Running

Is this an accurate reflection of Kubernetes' behavior?

/remove-lifecycle rotten

Pod container updates 11132


"Deprecated Functionality: Use of "parent" in callables is deprecated in /app/vendor/graycore/magento2-graphql-introspection-cache/Executor/ReferenceExecutor.php on line 22",

"Deprecated Functionality: Use of "parent" in callables is deprecated in /app/vendor/graycore/magento2-graphql-introspection-cache/Executor/ReferenceExecutor.php on line 22",
@damienwebdev Is this a weird error to be getting or an expected one? The only place I'm seeing it so far is my local environment, but it definitely sounds like an error which we would expect to see everywhere.

I'm seeing unclear discussions as to whether this was deprecated in PHP 8.1 or in 8.2. Either way, that seems like evidence for it to be an error we will expect to see everywhere once everywhere gets on a high enough php version.

It seems clearer now. The function was deprecated in PHP 8.2. I accidentally updated my local Docker container to run on 8.2, and therefore I'm seeing the error. No one else is, because they're all on 8.1. So this will require updating, but probably not until later.

@jburnumHVT thanks for the notice. I'll work to get support for v8.2 started!

I've made a patch which works for me with PHP 8.3 and webonyx/graphql-php "15.18.1"
From 7efb5634cafe01453384f4d42a092c6fbfffff10 Mon Sep 17 00:00:00 2001
From: Igors Kolcins<EMAIL_ADDRESS>Date: Tue, 3 Dec 2024 15:00:30 +0200
Subject: [PATCH] your message

---
 Executor/ReferenceExecutor.php | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/Executor/ReferenceExecutor.php b/Executor/ReferenceExecutor.php
index a64522b..0aeeb36 100644
--- a/Executor/ReferenceExecutor.php
+++ b/Executor/ReferenceExecutor.php
@@ -4,6 +4,7 @@ namespace Graycore\GraphQlIntrospectionCache\Executor;

 use GraphQL\Executor\ExecutionContext;
 use GraphQL\Executor\ExecutionResult;
+use GraphQL\Executor\Executor;
 use GraphQL\Executor\ExecutorImplementation;
 use GraphQL\Executor\Promise\Promise;
 use GraphQL\Executor\Promise\PromiseAdapter;
@@ -17,9 +18,9 @@ use SplObjectStorage;

 class ReferenceExecutor extends \GraphQL\Executor\ReferenceExecutor
 {
-    protected function __construct(ExecutionContext $context)
+    public function __construct(ExecutionContext $context)
     {
-        if (is_callable('parent::__construct')) {
+        if (method_exists(parent::class, '__construct')) {
             parent::__construct($context);
         } else {
             $this->setExecutorPrivateProp('UNDEFINED', Utils::undefined(), true);
@@ -43,9 +44,10 @@ class ReferenceExecutor extends \GraphQL\Executor\ReferenceExecutor
         DocumentNode $documentNode,
         $rootValue,
         $contextValue,
-        $variableValues,
+        array $variableValues,
         ?string $operationName,
-        callable $fieldResolver
+        callable $fieldResolver,
+        ?callable $argsMapper = null, // TODO make non-optional in next major release
     ) : ExecutorImplementation {
         $reflectionMethod = new ReflectionMethod(\GraphQL\Executor\ReferenceExecutor::class, 'buildExecutionContext');
         if ($reflectionMethod->isPrivate()) {
@@ -61,7 +63,8 @@ class ReferenceExecutor extends \GraphQL\Executor\ReferenceExecutor
             $variableValues,
             $operationName,
             $fieldResolver,
-            $promiseAdapter
+            $argsMapper ?? Executor::getDefaultArgsMapper(),
+            $promiseAdapter,
         );

         if (is_array($exeContext)) {
@@ -84,7 +87,7 @@ class ReferenceExecutor extends \GraphQL\Executor\ReferenceExecutor

         return ObjectManager::getInstance()->create(
             ReferenceExecutor::class,
-            ['context' => $exeContext]
+            ['context' => $exeContext],
         );
     }
 }
--
2.39.5 (Apple Git-154)


The automated release is failing 🚨

:rotating_light: The automated release from the staging branch failed. :rotating_light:
I recommend you give this issue a high priority, so other packages depending on you can benefit from your bug fixes and new features again.
You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can fix this 💪.
Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.
Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the staging branch. You can also manually restart the failed CI job that runs semantic-release.
If you are not sure how to resolve this, here are some links that can help you:

Usage documentation
Frequently Asked Questions
Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

Cannot push to the Git repository.
semantic-release cannot push the version tag to the branch staging on the remote Git repository with URL<EMAIL_ADDRESS>This can be caused by:

a misconfiguration of the repositoryUrl option
the repository being unavailable
or missing push permission for the user configured via the Git credentials on your CI environment

Good luck with your project ✨
Your semantic-release bot :package::rocket:

:rotating_light: The automated release from the staging branch failed. :rotating_light:
I recommend you give this issue a high priority, so other packages depending on you can benefit from your bug fixes and new features again.
You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can fix this 💪.
Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.
Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the staging branch. You can also manually restart the failed CI job that runs semantic-release.
If you are not sure how to resolve this, here are some links that can help you:

Usage documentation
Frequently Asked Questions
Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

Cannot push to the Git repository.
semantic-release cannot push the version tag to the branch staging on the remote Git repository with URL<EMAIL_ADDRESS>This can be caused by:

a misconfiguration of the repositoryUrl option
the repository being unavailable
or missing push permission for the user configured via the Git credentials on your CI environment

Good luck with your project ✨
Your semantic-release bot :package::rocket:


Support view style with layer properties

ex: cornerRadius, borderWidth, borderColor, etc ...

Done with border width, border color & cornerRadius


[Suggestion] Configure Entity Chat Bubbles

It would be great if we could edit what each entity can say with chat bubbles. The villagers dialogue don't really make much sense for my pack and are immersion breaking.

Turns out they're in en_us.lang files, meaning it should be possible to overwrite them using a resource pack.
Create a resource pack with the file structure assets -> dsurround -> dsurround -> data -> chat and inside the chat folder, place a customized en_us.lang file containing whatever entries you want to overwrite.  While I haven't tested this myself, in theory it should work.

Turns out they're in en_us.lang files, meaning it should be possible to overwrite them using a resource pack.
Create a resource pack with the file structure assets -> dsurround -> dsurround -> data -> chat and inside the chat folder, place a customized en_us.lang file containing whatever entries you want to overwrite.  While I haven't tested this myself, in theory it should work.

This feature has been discontinued.

This feature has been discontinued.


Module evdi not found [Arch]

Hello
I was trying the EVDI method, as it's the only method I've found which doesn't require disconnected outputs and dummy plugs, much like the windows virtual monitor driver, cause I'm limited by my laptop's 1 HDMI output.
However upon entering the sudo modprobe evdi command, a fatal error pops up: modprobe: FATAL: Module evdi not found in directory /lib/modules/6.6.41-1-lts

Hello!
Did you install the evdi module?
For faster response, I recommend you use the Immersed discord server and send a message to the Linux-help channel.


Revert "Add Since(t Time) Duration shorthand"

Reverts mixer/clock#10

@connor4312,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot


add fallback for kubeconfig retrieval via endpoints and client config ca

What this PR does / why we need it:
Adds a defaulting for the case the cluster-info configmap does not exist.
In this case, we fetch the first IP from end Kubernetes endpoints and the ca from the pod passed kubeconfig
Which issue(s) this PR fixes:
Fixes #78

Thinking about the issue some more, maybe it would be smart to create a cluster-info configmap and popupate it with the info from endpoints/kubeconfig instead of getting it ad-hoc?

Though about that as well, but that would mean that we set a specific endpoint IP as "final".
I would prefer to take whatever ip is there at the moment.

Okay, you have a point there.
What I find a little annoying, is that it now logs on every healthcheck that the configmap couldn't be found. It would be way better if we only logged that once and then have a log message when we use a new endpoint address or data from the configmap.

Its getting logged with level 6, which shouldn't be used in production.
And as we check everytime if we can find a configmap, i would like to keep it that way

@alvaroaleman PTAL

@alvaroaleman PTAL


Heisenbug prevents adding entries to a specific grouping

There is a bug that appeared once when setting a previously-saved untitled template's "entry images" field options from all on to all off. After doing so, I couldn't add an entry to the Localities -> All group. I didn't test other entry spots. It didn't save as invisible entries either.

Saving changes to the template would disassociate the project instance when using the project copy. This has been fixed in a previous commit.


Theme submission: rocinante

Theme submission
Please make sure that you have read the theme submission guidelines before submitting a theme. The guidelines provide all relevant information and requirements that have to be fulfilled before the submission. Please tick the relevant boxes for your theme in the checklist below:
Link to my theme repository: https://github.com/mavidser/hugo-rocinante
I made sure that...

[x] the repository contains a good README.md describing my theme
[x] an open source license has been added to LICENSE.md
[x] all metadata have been added to theme.toml
[x] screenshots have been added in the images/ folder with the required dimensions
[x] in case I'm using a customized demo via the exampleSite folder that

[x] https://example.com is set as base url in exampleSite/config.{toml, yaml, json} to avoid the abuse of unused domains
[x] I tested that my theme's demo works with the content directory of gohugoio/HugoBasicExample

[x] I tested my theme against the gohugoio/HugoBasicExample

[x] I've checked the developer tools' console in my browser for error messages

[x] in case my theme is using Hugo Pipes features like toCSS and PostCSS that I have committed the /resources directory with all generated assets, for my theme to work in the basic version of Hugo

N.B. By submitting a theme to the Hugo Themes Showcase you understand that you need to maintain your theme. You will need to keep an eye on whether your theme's demo generates on the Hugo website, whenever there is a new release. We are a very small team and we just cannot keep up opening issues in the various theme repositories to notify authors. Whenever a theme demo breaks and remains broken then at some point it will be removed from the list without prior warning. If you no longer wish to maintain a theme please let us know.
New themes will usually be promoted on Hugo's official Twitter account. If you would like to be mentioned in the tweet please add your Twitter username to this submission: @mavidser
Feel free to ask questions. We're glad to help.

Hello @mavidser,
thank you for sharing this theme with the Hugo community. While reviewing your theme I noticed a few issues:

please make sure that the thumbnail and screenshot in the images folder have the right dimensions. You can find them in the README.
To link to your website properly please prefix the corresponding url with http(s)://www.

Fixed those issues, thanks!

Thank you for applying the fixes. One last question: are all pictures in the exampleSite directory taken from picsum.photos or other sources that allow the free usage of them?

Yes, all the photos have been taken from picsum.photos, which are under Unspalsh's free use license.

Your theme should appear soon on Hugo's theme site. Next, I'll promote your theme on Hugo's official Twitter account.


Display stdin more intuitively top-down instead of bottom-up

Split into two commits:

Display stdin top-down instead of bottom-up. This makes using television for browsing shell history more intuitive.
Makes a change to skip empty or whitespace-only lines from showing up. I am not entirely sure this is a good idea especially that it trim()s the lines, which may not be what the user wants for very specific use cases. Feel free to skip this commit of course.

Thanks for the PR, makes sense indeed.
For the trim part, I believe it does make sense to filter out empty lines so let's proceed like that for now. It's a small change we can rollback at some point if people aren't happy with it.


Clarify Differences Between Hooks

I'm confused about the distinction between prepatch, update, postpatch, and post. Could someone please clarify exactly when each of these are triggered? Also, I would suggest adding a practical example (either a code sample or an example scenario that makes it clear why that particular hook should be used) for each of the hooks in the docs.

Hooks are documented in the readme. It doesn't go as far as examples and when-to-use but I'll still close this issue, if you don't mind.

And if you @humeeastmain or anyone else is unsure, please let us know here or in a new issue.


Add Micropolis encoder

I wrote this much earlier this year, but by the time I had tested it on a real machine the protobuf changes were already underway.
I spent time trying to get encodedecodetest working for micropolis, and was successful, but inserting the index at the right place really benefits from an appendInterval() at the end of Fluxmap::appendBits(). It seemed that could maybe mess something up, so I removed it from this PR. For example, the encoders just check that cursor didn't overflow, but there could be a lot of unused bits at the end of bits. It might also confuse some tooling to see an interval without any following pulse. Or it might all be fine. But I decided to get this part in before worrying about it.
CC @hharte

Sorry for the delay --- been on holiday and catching up. Thanks very much for this! Only one quibble: could you add a encoderdecoder test for it, please? This will do a round trip of encoding some random data and decoding it again to make sure you get the same data. Look at the list at the bottom of mkninja.sh and the proto files in scripts.

@davidgiven, did you see my note in the PR description? Basically, for the encodedecodetest the encoder needs to add index marks to the output. Most of the index marks aren't much of a problem, but the last index mark is in the middle of the last sector... in the middle of user data. This isn't so bad, except that means I need to do multiple appendBits() calls per track and that function doesn't appendInterval() for trailing zeros. The fix is easy to code, but harder to determine if something might be accidentally depending on the previous behavior.

Oh, oops --- no, I missed that, sorry. Will merge.
Re appendBits(): that's a nice catch. I'd completely forgotten about the end-of-track index mark being half-way between the sector index marks. Yes, adding appendInterval ought to be the right thing to do but I agree about edge cases. Hopefully there are enough tests to catch most of these, but apparently I never actually got round to writing a Fluxmap test...


Update backend config

Opened backend up outside of backend. Using pull request to show Jeff. May not be the solution

Merging to test it out since not mission critical yet. Will revert if doesn't work.


Prompt Googlebot to request pre-rendered page content from Reflection

As discussed (https://github.com/artsy/collector-experience/issues/533), gene pages aren't rendering effectively for Googlebot. We should probably have Reflection pre-render these pages instead. The genes sitemap has already been added to Reflection, so those pages are now being crawled and pre-rendered.
However when I checked that Reflection was able to render the page, I noticed apparent problems reaching Metaphysics and the main API. Similar requests work fine from other pages, so I assume there's some low-level difference in how this page functions, or maybe another error interfering. This probably shouldn't be merged until that's addressed (though the pre-rendered pages are no worse than what Googlebot is already seeing):
Blocked on: https://github.com/artsy/reflection/issues/63
Fixes: https://github.com/artsy/collector-experience/issues/533

Seeing as the code change is simply removing dead code, I'll go ahead and merge. Sounds like there's more work to get these pages rendering properly to Reflection, but doesn't seem like that should hold this up. 👍  thanks for the fix.


[R][Release] CRAN packaging checklist for 14.0.2

Describe the enhancement requested
Packaging checklist for CRAN release
For a high-level overview of the release process see the
Apache Arrow Release Management Guide.
Before the release candidate is cut

[x] Create a GitHub issue entitled [R] CRAN packaging checklist for version X.X.X and copy this checklist to the issue.
[x] Evaluate the status of any failing nightly tests and nightly packaging builds. These checks replicate most of the checks that CRAN runs, so we need them all to be passing or to understand that the failures may (though won't necessarily) result in a rejection from CRAN.
[x] Check current CRAN check results
[ ] Ensure the contents of the README are accurate and up to date.
[x] Run urlchecker::url_check() on the R directory at the release candidate.
commit. Ignore any errors with badges as they will be removed in the CRAN release branch.
[x] Polish NEWS but do not update version numbers (this is done automatically later). You can find commits by, for example, git log --oneline aa057d0..HEAD | grep "\[R\]"
[ ] Run preliminary reverse dependency checks using archery docker run r-revdepcheck.
[ ] For major releases, prepare tweet thread highlighting new features.

Wait for the release candidate to be cut:
After release candidate has been cut

[x] Create a CRAN-release branch from the release candidate commit

Prepare and check the .tar.gz that will be released to CRAN.

[x] git fetch upstream && git checkout release-X.X.X-rcXX && git clean -f -d
[ ] Run make build. This copies Arrow C++ into tools/cpp, prunes some
unnecessary components, and runs R CMD build to generate the source tarball.
Because this will install the package, you will need to ensure that the version
of Arrow C++ available to the configure script is the same as the version
that is vendored into the R package (e.g., you may need to unset ARROW_HOME).
[ ] devtools::check_built("arrow_X.X.X.tar.gz") locally
[ ] Run reverse dependency checks using archery docker run r-revdepcheck.

Release vote

[x] Release vote passed!

Generate R package to submit to CRAN

[x] If the release candidate commit updated, rebase the CRAN release branch
on that commit.
[x] Pick any commits that were made to main since the release commit that
were needed to fix CRAN-related submission issues identified in the above
steps.
[x] Remove badges from README.md
[x] Run urlchecker::url_check() on the R directory
[x] Create a PR entitled WIP: [R] Verify CRAN release-10.0.1-rc0. Add
a comment @github-actions crossbow submit --group r to run all R crossbow
jobs against the CRAN-specific release branch.
[x] Run Rscript tools/update-checksums.R <libarrow version> to download the checksums for the pre-compiled binaries from the ASF artifactory into the tools directory.
[x] Regenerate arrow_X.X.X.tar.gz (i.e., make build)

Ensure linux binary packages are available:

[x] Ensure linux binaries are available in the artifactory:
https://apache.jfrog.io/ui/repos/tree/General/arrow/r

Check binary Arrow C++ distributions specific to the R package

[x] Upload the .tar.gz to win-builder (r-devel only)
and confirm (with Nic, who will automatically receive an email about the results) that the check is clean.
This step cannot be completed before Jeroen has put the binaries in the MinGW repository, i.e. here, here, and here.
[x] Upload the .tar.gz to MacBuilder
and confirm that the check is clean
[x] Check install.packages("arrow_X.X.X.tar.gz") on Ubuntu and ensure that the
hosted binaries are used
[x] devtools::check_built("arrow_X.X.X.tar.gz") locally one more time (for luck)

CRAN submission

[ ] Upload arrow_X.X.X.tar.gz to the
CRAN submit page
[ ] Confirm the submission email

Wait for CRAN...

[ ] Accepted!
[ ] Tag the tip of the CRAN-specific release branch
[ ] Add a new line to the matrix in the backwards compatability job
[ ] (patch releases only) Update the package version in ci/scripts/PKGBUILD, dev/tasks/homebrew-formulae/autobrew/apache-arrow.rb, r/DESCRIPTION, and r/NEWS.md
[ ] (CRAN-only releases) Rebuild news page with pkgdown::build_news() and submit a PR to the asf-site branch of the docs site with the contents of arrow/r/docs/news/index.html replacing the current contents of arrow-site/docs/r/news/index.html
[ ] (CRAN-only releases) Bump the version number in r/pkgdown/assets/versions.json, and update this on the the asf-site branch of the docs site too.
[ ] Update the packaging checklist template to reflect any new realities of the
packaging process.
[ ] Wait for CRAN-hosted binaries on the
CRAN package page to reflect the
new version
[ ] Tweet!

Component(s)
R, Release

Hi, I have a package which Suggests arrow, and I heard from CRAN that it will be archived soon (Friday) if there is no update provided. Do you have plans to send CRAN an update? If not, I would like to remove arrow from Suggests. Thanks!

Hey @tdhock, which package is this? The arrow R team is aware of the impending archival (see https://github.com/apache/arrow/issues/39806 for more context) and have been working with CRAN with the hopes of preventing it. The package may be archived only to come back at some later point and we're happy to help you stay on CRAN in during that time by filing a PR or reviewing any changes you may need to make.


Should I add options for millisecond and nanosec precision?

The question is in the title

Yes

guess we need to switch to parameterized type then for the ecto stuff?

guess we need to switch to parameterized type then for the ecto stuff?

Does the precision default to nanoseconds?

Does the precision default to nanoseconds?

It's so hard to find info on this.

I've been (low-effort) looking around for this kind of info (without diving too deep) for the last couple of weeks.
iex(7)> :erlang.system_info(:os_system_time_source)
[
  function: :clock_gettime,
  clock_id: :CLOCK_REALTIME,
  resolution: 1000000,
  parallel: :yes,
  time:<PHONE_NUMBER>574298000
]

this suggests my system is microseconds...
but System.system_time(:native) returns a nanosecond timestamp and
iex(9)> :erlang.convert_time_unit(1, :second, :native)
1000000000

is nanoseconds...

Does the precision default to nanoseconds?

It's so hard to find info on this.

Sorry, I meant, does the current implementation default to nanoseconds, not the specification. I would learn on default to highest precision and make it configurable to lower it. Since with higher precision the ordering would be more precise.

Does the precision default to nanoseconds?

It's so hard to find info on this.

Sorry, I meant, does the current implementation default to nanoseconds, not the specification. I would learn on default to highest precision and make it configurable to lower it. Since with higher precision the ordering would be more precise.

The spec is milliseconds default with optional extra granularity up to nanoseconds.
There are other UUID libraries out there but they just use the default milliseconds and I wanted something with more time granularity. I defaulted to microseconds (for now), to be safe without wasting random bits, but now I'm wondering if I should have defaulted to the spec default and make the rest configurable, or just go straight to only nanoseconds....

I want to emphasize that the point of v7, as you know, is to get a stable ordering of UUID to avoid including an inserted_at column in an order by. With that being said, there is nothing saved by excluding nanoseconds; the storage space would be the same, and there would likely not be any gains in cache coherence. But the pain will be felt if records are stored so close that they conflict; in that case, you will lose the order. Precision, in my opinion, is king in this case. We want deterministic ordering of records.

Sorry I lied, it was up to 12 bits of sub-millisecond precision which isn't quite nanoseconds. (I haven't read it in a while)
We can optionally add a counter on top of that, though.

I'm going to work in this, with a counter.


1 New Icon Added

1 New Icon Added

Pharmacy Verification - Used within MAR to indicate verification is needed from the pharmacy

+1


Consider restructuring as a Lerna monorepo

The DynamoDB tooling you guys have written is very useful, but it's spread out over half a dozen packages, and in my experience projects like that can be hard to keep in sync. The monorepo style has been used a lot recently, and it may be a great fit here. You still maintain package-level modularity for the individual tools, but you can pull development tasks (linting, testing), to the top level project, test everything as a complete system, and automate npm-linking of inter-package dependencies.

@darthtrevino Will you be able to support for the initial work?

Sure, if you guys are open to the idea I can set it up for you

@darthtrevino are you planning on doing this? I'd be happy to make a start at merging the libraries together.

I probably won't get to it this weekend. If you have some free time and you're bored, feel free to take a crack at it

@nielsgl would be great if you could start with the work 👍

Two years on any update on this?
This will actually address #218 and related issues.


Availability: Fixes region failover logic on control plane hot path when gateway hangs

If Gateway is a hung state where the HttpRequestException only happens after 60 seconds, the current Hot Path policy was only waiting up to 10 seconds and surfacing a RequestTimeout, and we could not apply the failover mechanics.
This only affected the hot path (address resolution or query plans) and not other Gateway calls.
Introduced in 3.16.0 in PR https://github.com/Azure/azure-cosmos-dotnet-v3/pull/1954
Type of change

[x] Bug fix (non-breaking change which fixes an issue)

Lets please wait merging this change.
Latency is also equally very important as well.
May be we need to revisit basing all fail-over on just ReqeustException

@kirankumarkolli  I don't see any reason to block this PR. If it is decided that we want to revisit fail-over design it should be a separate PR after the current model is fixed.

I don't see how latency is involved here. We are already retrying 3 times, with .5, and 5 seconds, before the 65 seconds. If Gateway has a latency spike, it will be clear.
The 3 retries are to work around Gateway upgrades and try to reach other instances, not for latency (rather availability).


Opening an unsupported text encoding crashes the editor

If you accidentally select an unsupported file type from the File Explorer, such as a binary or PNG file, the editor will become unresponsive and not recover.
Would it be possible to filter based on the file type, and if an unsupported file is selected take a similar method to VSCode and prompt the user?
Currently, VSCode if attempting to open an unsupported file will display the following message.

The file is not displayed in the editor because it is either binary or uses an unsupported text encoding. Do you want to open it anyway?

I believe (well in my tiny 3 file test) that #2187 should have fixed the hang. I know see a bunch of rubbish but opening an image and even when opening the 80MB installer for Oni2 on Windows, after a quick pause it loads in fine.
However, it would be nice to have something like that. I believe (from a quick poke in the VSCode source) that they show that warning for both binary/unsupported files (I couldn't easily find there check for that yet) and for giant files. If we can find what they are doing to determine that, it would make sense.
A file type filter sounds like it would be too much work on our end potentially, so if we could get away with not having to maintain an ever growing list of "don't open these", that would be nice. (I'm just worried that I know like a jpg alone has jpg, JPEG and then the other weirder ones I've seen twitter use like jfif, jfi, jif, so that list would either be giant and a pain, or just annoying since it would have too many gaps to be useful.)

Hi!
I've just downloaded the latest nightly,

Version: <IP_ADDRESS>
Date: 29/07/2020, 14:23:00
Commit: fc8ccb04

I can see from the change log that this includes PR #2187 as you mentioned.
And 🥁 , it works without crashing!
I don't receive a message, but the file is opened without crashing, jibberish and all 😁


[Python] Pydantic vector field does not take default value

Problem Statement
We have provide a vector field for Pydantic based models. However the vector field does not take default value as others default fields.

https://github.com/lancedb/lancedb/pull/474. Would not reproduce the problem in the PR.

@eddyxu i think this can be closed as completed right?


Convolution of zero length input gives junk gradients

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): Yes
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Ubuntu 16.04
TensorFlow installed from (source or binary): source
TensorFlow version (use command below): 1.1
Bazel version (if compiling from source): 0.4.5
CUDA/cuDNN version: N/A
GPU model and memory: N/A
Exact command to reproduce: python3 junk_gradients.py

Describe the problem
When you pass a zero length input to tf.conv1d and then calculate gradients, you will get junk values. I think it's reading from uninitialized memory because it's nondeterministic and can be very small or very large positive or negative values or NaNs.
The expected behavior is that the gradients should all be 0 because the weights aren't making any contribution to the loss.
In the application I am writing the input has a variable length (including 0) but for this minimal example I've set it to a constant (tf.ones([0,2])).
If you force the convolution to always have an input with length > 0 then the bug goes away. I've included that in the reproduction code under the variable 'remove_bug'.
For me, with this reduced example, the gradients are always junk but vary widely. You might see 0s if it happens to read from zeroed out memory. Hopefully the bug will show up if you just run it a few times.
Source code / logs
import tensorflow as tf

remove_bug = False

vals = tf.ones([0,2])

if remove_bug: # hack it to not actually have zero length
    vals = tf.concat([tf.ones([2, 2]), vals], 0)

# At this point 'vals' will either have length 0 or 2 if the bug was removed

filter = tf.Variable(tf.ones([2, 2, 2]))

conv = tf.nn.conv1d(tf.expand_dims(vals, 0), filter, 2, 'SAME')[0]

# At this point 'conv' will either have length 0 or 1 if the bug was removed

if remove_bug:
    conv = conv[1:] # slice off hack, make 'conv' zero length again

# At this point 'conv' will have length 0 whether or not the bug was removed.

optimizer = tf.train.GradientDescentOptimizer(0.01)

grads = [g for g, _ in optimizer.compute_gradients(conv)]

with tf.Session() as sess:
    sess.run(tf.global_variables_initializer())

    gs = sess.run(grads)

print(gs)

Hi @mscheifer, thanks for reaching out. Unfortunately, I am not able to reproduce the problem. Running the code that you provided above seems to return a vector filled with None(s). This is the expected output of tf.gradients(), for None denotes that the outputs have no graph dependency on the specified inputs.

If this continues to be a problem, please consider asking this question on  StackOverflow. The larger community there may be able to help debug. If you do discover a bug, feel free to reopen this issue or open a new one. Thanks!


Bluetooth: controller: Refactor invalid ctrl PDU handling

Refactor the invalid control PDU handling so as to reuse the
switch-case and hence, reduce code size and CPU time used.
Signed-off-by: Vinayak Kariappa Chettimada<EMAIL_ADDRESS>

Looks good, another TODO gone.

Codecov Report

Merging #5986 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #5986   +/-   ##
=======================================
  Coverage   52.51%   52.51%
=======================================
  Files         406      406
  Lines       39683    39683
  Branches     7715     7715
=======================================
  Hits        20839    20839
  Misses      15663    15663
  Partials     3181     3181

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 f09bab9...07e02d9. Read the comment docs.


DefaultDocumentLayout.showCaret is constrained by gestureMode == DocumentGestureMode.mouse

Not sure if this intentional or a leftover from the initial work to support mobile.
Currently we check ComponentContext.showCaret in a component builder, which works as expected on macOS, but on mobile it always returns false.

@miguelcmedeiros can you frame the issue in terms of what is happening, that shouldn't happen, or what isn't happening, that should happen?

@matthew-carroll
We have component builder for a task which aside from the other task gimmicks, returns a TextWithHintComponent for the title of the task. On desktop, the caret is only rendered when TextWithHintComponent.showCaret is true. In this case, we get this boolean as shown in the demo for using text component with hint:
  final showCaret = componentContext.showCaret && componentContext.nodeSelection != null
      ? componentContext.nodeSelection!.isExtent
      : false;

The same logic does not work on mobile since componentContext.showCaret is always false.
After opening this issue (and associated PR) I noticed something else. If on mobile we set TextWithHintComponent.showCaret to true based only on whether the node is selected, then we get 2 carets. I'm guessing one comes from the mobile IOSDocumentTouchInteractor (or AndroidDocumentTouchInteractor) and another one from TextWithHintComponent (SuperSelectableText under the hood). Here's a quick loom on how I reproduce it using super_editor demo app: https://www.loom.com/share/4b81f53d9e6044e4a12021defd166a5f
With these insights we might close this issue and open 2 separate issues which addresses the following:

It should not be possible to render 2 carets
It should be possible to customise the theme of the caret on mobile (similar to what it's possible on desktop), like the width and color, as well as the mobile drag handles

What do you think?

The way super_editor handles carets on desktop and mobile are different, by design.
On desktop, each component is asked to render a caret. This was the most versatile approach and it worked fine for desktop up to this point.
On mobile, carets are indistinguishable from drag handles, and those drag handles need to be able to move anywhere in the document. They can't be confined to any single component. Therefore, on mobile, we turn off component caret rendering and we switch to an overlay. The way that we turn off component caret rendering is by using that condition that you referenced in the original ticket description.

It should not be possible to render 2 carets

Ironically, your team doesn't want this to be true at all! If you want to show other users working in the same document, then you definitely want the ability to render 2+ carets. You just don't want that to happen when it shouldn't.

It should be possible to customise the theme of the caret on mobile (similar to what it's possible on desktop), like the width and color, as well as the mobile drag handles

Yeah, a lot of things in the mobile controls should be theme-able, but aren't. However, I think this is completely distinct from what we're discussing here.
As for this situation, do your task items implement the DocumentComponent contract? https://github.com/superlistapp/super_editor/blob/main/super_editor/lib/src/core/document_layout.dart#L82
The DocumentComponent API is how the document layout maps between logical caret locations and visual caret locations. On mobile, your tasks need to defer to the shared caret solution, because any other approach would make it impossible for the user to drag the caret from the middle of your task, up to the middle of a paragraph.

As for this situation, do your task items implement the DocumentComponent contract?

Nope, we don't have a custom DocumentComponent for our task items. As mentioned before, have a component builder that returns a TextWithHintComponent.
Thanks to your explanation I now get this difference between mobile and desktop on how the caret is handled. That being said, other developers might make the same wrong assumption that I made.
Closing this ticket, since it seems to behave as expected.


cyclic dependencies need grouping

I see that nothing handles cyclic deps. I took a stab at it because it's breaking for me, but I notice that the cyclic dep resolver isn't working properly. When I install es-abstract, I get in the dream lock (trimmed example):
{
    "string.prototype.trimend": {
      "1.0.5": [
        [ "es-abstract", "1.20.1" ]
      ]
    },
    "string.prototype.trimstart": {
      "1.0.5": [
        [ "es-abstract", "1.20.1" ]
      ]
    },
}

Obviously, all cyclic dependencies should be grouped together and a parent dep should be picked (probably the one with the shortest name)
So it should be:
{
  "es-abstract": {
    "1.20.1": {
      ["string.prototype.trimend", "1.0.5"],
      ["string.prototype.trimstart", "1.0.5"]
    }
  }
}

There are different strategies on finding sets of edges to remove to break cycles. I'm not sure if there is a clear right or wrong solution. It always depends on what you try to do afterwards
I think the current algorithm tries to remove the edges with the highest distance from the root.
For the current nodejs builder, this fits really nicely, because it guarantees that the children of removed edges, will at the same time be ancestors.
As the nodejs module resolution also searches ancestors, we can just ignore all removed dependencies during installation, and everything will still work out.
Though I see that problem that we now depend on the preserveSymlinks which is not handled well by default in many build tools.
Therefore, I'm interested in what you manage to achieve with your new build logic. If it is an improvement over the old one, I'm open to have it changed.

Hmm - for nodejs I just group all the modules that are part of a cycle group together. You cannot have eslint without having trimend and trimstart in its package under lib/node_modules.
If you wanted trimend by itself, you would still need eslint, and therefore you would still need trimend. You cannot separate them.
In the end you need a single store package that includes all modules that have cycles between them.
So that's why I think the original resolution is wrong, you should not be able to have a cyclee in multiple groups.

You cannot have eslint without having trimend and trimstart in its package under lib/node_modules.

As long as any of its parents/ancestors contain this dependency, it is fine, which is why the current logic works.
Anyways, I just pasted a flake in another thread, that demonstrates that eslint works just fine with the current dream2nix.
I think we waste our time continuing this discussion. You could prove your point very easily, by just providing a flake with a failing build.

I think we waste our time continuing this discussion. You could prove your point very easily, by just providing a flake with a failing build.

I'll try this later, I encountered the cyclic problem in my branch because it doesn't use the symlink resolving flag, between node-sp-auth and node-sp-auth-config IIRC.
Anyway, the eslint example you gave doesn't have eslint in node_modules:
$ ll
total 4
-rw-r--r-- 1 wmertens 491 Jul 15 12:05 flake.nix

$ cat flake.nix
{
  inputs.dream2nix.url = "github:nix-community/dream2nix";
  inputs.src = {flake = false; url = "github:eslint/eslint";};
  outputs = inp:
    let
      l = inp.dream2nix.inputs.nixpkgs.lib // builtins;
    in
    inp.dream2nix.lib.makeFlakeOutputs {
      # modify according to your supported systems
      systems = ["x86_64-linux"];
      config.projectRoot = ./.;
      source = l.path {
        path = inp.src;
        filter = path: _: ! l.hasInfix "/tests/" path;
      };
    };
}

$ nix develop
warning: creating lock file '/home/wmertens/lkjh/es/flake.lock'
$ tree -a node_modules
node_modules@
`-- .bin/

1 directory, 0 files
$ nix build
$ tree -a result
result@
`-- lib/
    `-- node_modules/
        `-- eslint-config-eslint/
            |-- LICENSE
            |-- README.md
            |-- default.yml
            |-- index.js
            |-- node_modules/
            |-- package.json
            `-- package.json.bak

4 directories, 6 files
$ node -r eslint
internal/modules/cjs/loader.js:905
  throw err;
  ^

Error: Cannot find module 'eslint'
Require stack:
- internal/preload
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:902:15)
    at Function.Module._load (internal/modules/cjs/loader.js:746:27)
    at Module.require (internal/modules/cjs/loader.js:974:19)
    at Module._preloadModules (internal/modules/cjs/loader.js:1244:12)
    at loadPreloadModules (internal/bootstrap/pre_execution.js:475:5)
    at prepareMainThreadExecution (internal/bootstrap/pre_execution.js:72:3)
    at internal/main/repl.js:19:1 {
  code: 'MODULE_NOT_FOUND',
  requireStack: [ 'internal/preload' ]
}

Whereas with #195:
$ ll
total 76
-rw-r--r-- 1 wmertens   341 Jul 15 13:28 flake.nix
-rw-r--r-- 1 wmertens   245 Jul 15 13:19 package.json

$ cat package.json
{
  "name": "es",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "dependencies": {"eslint": "*"},
  "author": "Wout Mertens",
  "license": "ISC"
}

$ cat flake.nix
{
  inputs.dream2nix.url = "github:wmertens/dream2nix/devShells";
  outputs = inp:
    let
      l = inp.dream2nix.inputs.nixpkgs.lib // builtins;
    in
    inp.dream2nix.lib.makeFlakeOutputs {
      # modify according to your supported systems
      systems = ["x86_64-linux"];
      config.projectRoot = ./.;
      source = ./.;
    };
}

$ nix run .#resolveImpure
warning: creating lock file '/home/wmertens/lkjh/es/flake.lock'
Resolving:: Name: es; Subsystem: nodejs; relPath:

up to date, audited 84 packages in 4s

13 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities
adding file to git: dream2nix-packages/es/dream-lock.json

$ nix build

$ tree result/
result//
`-- lib/
    `-- node_modules/
        `-- es/
            |-- dream2nix-packages/
            |   `-- es/
            |       `-- dream-lock.json
            |-- flake.lock
            |-- flake.nix
            |-- node_modules -> /nix/store/64ikwh1156a7lrcfwvn529zgn8gpp3ia-node_modules-es/
            `-- package.json

6 directories, 4 files

$ tree result/lib/node_modules/es/node_modules
result/lib/node_modules/es/node_modules@
|-- eslint -> /nix/store/a8dlwp74bz1lm7mcgl9fp08y5yb1940g-eslint-utils-3.0.0/lib/node_modules/eslint/
|-- eslint-utils -> /nix/store/a8dlwp74bz1lm7mcgl9fp08y5yb1940g-eslint-utils-3.0.0/lib/node_modules/eslint-utils/
`-- null -> /nix/store/0rv6w1bn3sz4fl88qdlgl6diwg6kikdk-null-2.0.0/lib/node_modules/null/

3 directories, 0 files

(the null is a bug, I'll fix it)
As you can see, eslint and eslint-utils are together in the same store path

Anyway, the eslint example you gave doesn't have eslint in node_modules:
$ ll
total 4
-rw-r--r-- 1 wmertens 491 Jul 15 12:05 flake.nix

$ cat flake.nix
{
  inputs.dream2nix.url = "github:nix-community/dream2nix";
  inputs.src = {flake = false; url = "github:eslint/eslint";};
  outputs = inp:
    let
      l = inp.dream2nix.inputs.nixpkgs.lib // builtins;
    in
    inp.dream2nix.lib.makeFlakeOutputs {
      # modify according to your supported systems
      systems = ["x86_64-linux"];
      config.projectRoot = ./.;
      source = l.path {
        path = inp.src;
        filter = path: _: ! l.hasInfix "/tests/" path;
      };
    };
}

$ nix develop
warning: creating lock file '/home/wmertens/lkjh/es/flake.lock'
$ tree -a node_modules
node_modules@
`-- .bin/

1 directory, 0 files
$ nix build
$ tree -a result
result@
`-- lib/
    `-- node_modules/
        `-- eslint-config-eslint/
            |-- LICENSE
            |-- README.md
            |-- default.yml
            |-- index.js
            |-- node_modules/
            |-- package.json
            `-- package.json.bak

All of that is just because eslint-config-eslint is for some reason detected as the default package of this flake, and therefore the default devShell is also for eslint-config-eslint.
That's a bug and we should fix it.
Though the node_modules logic seems just fine if I enter the correct devShell:
> nix develop .#devShells.x86_64-linux.eslint -L
> ls node_modules
ajv           escape-string-regexp           eslint-utils               glob                                   js-yaml                marked                    node-polyfill-webpack-plugin  semver
@babel        @eslint                        eslint-visitor-keys        globals                                karma                  memfs                     npm-license                   shelljs
babel-loader  eslint                         eslump                     glob-parent                            karma-chrome-launcher  metascraper               null                          sinon
chai          eslint-config-eslint           espree                     got                                    karma-mocha            metascraper-description   nyc                           strip-ansi
chalk         eslint-plugin-eslint-comments  esprima                    gray-matter                            karma-mocha-reporter   metascraper-image         optionator                    strip-json-comments
cheerio       eslint-plugin-eslint-plugin    esquery                    @humanwhocodes                         karma-webpack          metascraper-logo          pirates                       temp
common-tags   eslint-plugin-internal-rules   esutils                    ignore                                 levn                   metascraper-logo-favicon  progress                      text-table
core-js       eslint-plugin-jsdoc            fast-deep-equal            import-fresh                           lint-staged            metascraper-title         proxyquire                    v8-compile-cache
cross-spawn   eslint-plugin-node             fast-glob                  imurmurhash                            load-perf              minimatch                 puppeteer                     webpack
debug         eslint-plugin-unicorn          file-entry-cache           is-glob                                lodash.merge           mocha                     recast                        webpack-cli
doctrine      eslint-release                 fs-teardown                jsdoc                                  markdownlint           mocha-junit-reporter      regenerator-runtime           yorkie
ejs           eslint-scope                   functional-red-black-tree  json-stable-stringify-without-jsonify  markdownlint-cli       natural-compare           regexpp

The reason it detects eslint-utils is because it considers eslint a cyclee.

Not sure what you mean. eslint-utils is a direct dependency of eslint. It is installed as it should be.

And actually, eslint-utils should have eslint in its node_modules here and it doesn't. So that's a cyclic bug.

That has nothing to do with cycles.
Upstream NPM does not put eslint inside eslint-utils node_modules as well:
# podman run -it node:16 bash
# git clone --depth 1 https://github.com/eslint/eslint
# cd eslint
# npm install
# ls node_modules/eslint-utils/node_modules/
eslint-visitor-keys

eslint-utils doesn't need to have eslint in its node_modules as eslint already exists in the parent node_modules.
The issue we're running into with the current dream2nix is a peerDependency issue. eslint-utils is declaring eslint as a peerDependency and peer dependenceis are not part of the v1 lockfile which we are parsing.
This is a problem we should think about, but it's not a problem introduced by cycles.

it's a peer dep but also a cycle. Because it's a cycle it's been semi-randomly selected as the default package.
When using a tree of symlinks as we do, all the peer deps have to be present in eslint-utils' node_modules as well.
The alternative is what npm does, creating a full copy of all packages, but that's wasteful in diskspace and time. pnpm does symlinks and it does it similarly as in #195.

ok, here's a breaking cycle test:
node-sp-auth-config can't load node-sp-auth, and both modules require eachother, so both fail to load.
$ ll
total 16
-rw-r--r-- 1 wmertens  336 Jul 15 15:31 flake.nix
-rw-r--r-- 1 wmertens  108 Jul 15 15:41 package.json

$ cat *
{
  inputs.dream2nix.url = "github:nix-community/dream2nix";
  outputs = inp:
    let
      l = inp.dream2nix.inputs.nixpkgs.lib // builtins;
    in
    inp.dream2nix.lib.makeFlakeOutputs {
      # modify according to your supported systems
      systems = ["x86_64-linux"];
      config.projectRoot = ./.;
      source = ./.;
    };
}
{
  "name": "cycle-test",
  "dependencies": {
    "node-sp-auth": "*",
    "node-sp-auth-config": "*"
  }
}

$ npm i --package-lock-only
npm WARN deprecated<EMAIL_ADDRESS>request has been deprecated, see https://github.com/request/request/issues/3142
npm WARN deprecated<EMAIL_ADDRESS>this library is no longer supported
npm notice created a lockfile as package-lock.json. You should commit this file.
npm WARN cycle-test@ No description
npm WARN cycle-test@ No repository field.
npm WARN cycle-test@ No license field.

added 173 packages and audited 173 packages in 2.62s
found 2 moderate severity vulnerabilities
  run `npm audit fix` to fix them, or `npm audit` for details

$ nix develop

$ ll node_modules/
total 8
lrwxrwxrwx 3 root  92 Jan  1  1970 node-sp-auth -> /nix/store/l7jdi0r6q7snv51wiyl0pbdbjhffp0p1-node-sp-auth-3.0.5/lib/node_modules/node-sp-auth/
lrwxrwxrwx 2 root 106 Jan  1  1970 node-sp-auth-config -> /nix/store/ciy6555da7a8kigzp8ikasjmz7z5hpm5-node-sp-auth-config-3.0.2/lib/node_modules/node-sp-auth-config/

$ node -r node-sp-auth-config
internal/modules/cjs/loader.js:905
  throw err;
  ^

Error: Cannot find module 'node-sp-auth'
Require stack:
- /nix/store/xddgcymm08qmcj9cf2a61waapc4m71ag-node-sp-auth-config-3.0.1/lib/node_modules/node-sp-auth-config/dist/index.js
- /nix/store/l7jdi0r6q7snv51wiyl0pbdbjhffp0p1-node-sp-auth-3.0.5/lib/node_modules/node-sp-auth/lib/src/auth/resolvers/FileConfig.js
- /nix/store/l7jdi0r6q7snv51wiyl0pbdbjhffp0p1-node-sp-auth-3.0.5/lib/node_modules/node-sp-auth/lib/src/auth/AuthResolverFactory.js
- /nix/store/l7jdi0r6q7snv51wiyl0pbdbjhffp0p1-node-sp-auth-3.0.5/lib/node_modules/node-sp-auth/lib/src/index.js
- /nix/store/ciy6555da7a8kigzp8ikasjmz7z5hpm5-node-sp-auth-config-3.0.2/lib/node_modules/node-sp-auth-config/dist/index.js
- internal/preload
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:902:15)
    at Function.Module._load (internal/modules/cjs/loader.js:746:27)
    at Module.require (internal/modules/cjs/loader.js:974:19)
    at require (internal/modules/cjs/helpers.js:101:18)
    at Object.<anonymous> (/nix/store/xddgcymm08qmcj9cf2a61waapc4m71ag-node-sp-auth-config-3.0.1/lib/node_modules/node-sp-auth-config/dist/index.js:65:22)
    at Module._compile (internal/modules/cjs/loader.js:1085:14)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1114:10)
    at Module.load (internal/modules/cjs/loader.js:950:32)
    at Function.Module._load (internal/modules/cjs/loader.js:790:12)
    at Module.require (internal/modules/cjs/loader.js:974:19) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    '/nix/store/xddgcymm08qmcj9cf2a61waapc4m71ag-node-sp-auth-config-3.0.1/lib/node_modules/node-sp-auth-config/dist/index.js',
    '/nix/store/l7jdi0r6q7snv51wiyl0pbdbjhffp0p1-node-sp-auth-3.0.5/lib/node_modules/node-sp-auth/lib/src/auth/resolvers/FileConfig.js',
    '/nix/store/l7jdi0r6q7snv51wiyl0pbdbjhffp0p1-node-sp-auth-3.0.5/lib/node_modules/node-sp-auth/lib/src/auth/AuthResolverFactory.js',
    '/nix/store/l7jdi0r6q7snv51wiyl0pbdbjhffp0p1-node-sp-auth-3.0.5/lib/node_modules/node-sp-auth/lib/src/index.js',
    '/nix/store/ciy6555da7a8kigzp8ikasjmz7z5hpm5-node-sp-auth-config-3.0.2/lib/node_modules/node-sp-auth-config/dist/index.js',
    'internal/preload'
  ]
}

$ node -r node-sp-auth
internal/modules/cjs/loader.js:905
  throw err;
  ^

Error: Cannot find module 'node-sp-auth'
Require stack:
- /nix/store/xddgcymm08qmcj9cf2a61waapc4m71ag-node-sp-auth-config-3.0.1/lib/node_modules/node-sp-auth-config/dist/index.js
- /nix/store/l7jdi0r6q7snv51wiyl0pbdbjhffp0p1-node-sp-auth-3.0.5/lib/node_modules/node-sp-auth/lib/src/auth/resolvers/FileConfig.js
- /nix/store/l7jdi0r6q7snv51wiyl0pbdbjhffp0p1-node-sp-auth-3.0.5/lib/node_modules/node-sp-auth/lib/src/auth/AuthResolverFactory.js
- /nix/store/l7jdi0r6q7snv51wiyl0pbdbjhffp0p1-node-sp-auth-3.0.5/lib/node_modules/node-sp-auth/lib/src/index.js
- internal/preload
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:902:15)
    at Function.Module._load (internal/modules/cjs/loader.js:746:27)
    at Module.require (internal/modules/cjs/loader.js:974:19)
    at require (internal/modules/cjs/helpers.js:101:18)
    at Object.<anonymous> (/nix/store/xddgcymm08qmcj9cf2a61waapc4m71ag-node-sp-auth-config-3.0.1/lib/node_modules/node-sp-auth-config/dist/index.js:65:22)
    at Module._compile (internal/modules/cjs/loader.js:1085:14)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1114:10)
    at Module.load (internal/modules/cjs/loader.js:950:32)
    at Function.Module._load (internal/modules/cjs/loader.js:790:12)
    at Module.require (internal/modules/cjs/loader.js:974:19) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    '/nix/store/xddgcymm08qmcj9cf2a61waapc4m71ag-node-sp-auth-config-3.0.1/lib/node_modules/node-sp-auth-config/dist/index.js',
    '/nix/store/l7jdi0r6q7snv51wiyl0pbdbjhffp0p1-node-sp-auth-3.0.5/lib/node_modules/node-sp-auth/lib/src/auth/resolvers/FileConfig.js',
    '/nix/store/l7jdi0r6q7snv51wiyl0pbdbjhffp0p1-node-sp-auth-3.0.5/lib/node_modules/node-sp-auth/lib/src/auth/AuthResolverFactory.js',
    '/nix/store/l7jdi0r6q7snv51wiyl0pbdbjhffp0p1-node-sp-auth-3.0.5/lib/node_modules/node-sp-auth/lib/src/index.js',
    'internal/preload'
  ]
}

Thinking some more about this, it's not that the results are wrong per se, but that they don't get grouped. If A<=>B and B<=>C then the group should be ABC but instead we get AB and BC.
Note also that if A and C are different versions of the same package, the graph is technically speaking invalid but npm doesn't care. This actually happens in my example, it has two versions of node-sp-auth-config.
My v2 branch handles this case and refuses to build; when I fix the versions it builds a correct combined package.

How about this recursive algorithm: (pretend versions are part of dep)

given a package pkg and a set of seen = {dep = true} and a list of cycles = [ [dep...]... ]:

for each dependency, check if it is in seen

if so:

if dep is already in a cycle, add pkg to it (*)
if not, create a new cycle [dep, pkg] (*)
(*) note that due to siblings, pkg could already be in a cycle. In this case, the cycles have to be merged, not just the pkg.
(so this stops recursion)

if not: call this search with pkg=dep, and pass seen = seen // {pkg=true}; the cycles need to be shared between the recursive calls

Call the algorithm on pkg with seen = {}.
Not quite sure how to implement this in Nix, especially the shared cycles list and the cycle merging.
I think this will result in correct set of cycles, and then the packages closest to the start + shortest name should be picked as the set leaders.

Note also that if A and C are different versions of the same package, the graph is technically speaking invalid but npm doesn't care. This actually happens in my example, it has two versions of node-sp-auth-config.
My v2 branch handles this case and refuses to build; when I fix the versions it builds a correct combined package.

I think it should be fine to have different versions of the same package within on dependency tree. NPM is fine with that as well.
Just to make sure, we are talking about the same thing when we talk about cycles:
Our dependency tree consists of nodes of candidates, where each candidate is a (pname, version) tuple, or in other words, a specific version of a specific package. A candidate is the basic element for which we want to prevent cycles. A candidate should not end up depending on itself. But it can depend on another version of the same package without any problem. For example prettier always depends on an older version of itself, because they want to format their code with their own tool. That is completely fine. No cycle here.
I think if you'd force the whole closure to only contain one version of every package, you will loose compatibility to existing lock file formats because they do expect you to be able to install multiple versions of a package. You would have to re-resolve the dependency tree, which is a hard problem as you may know.

Right- I was on mobile and couldn't express subtlety, sorry. Indeed multiple versions of the same package within one tree are completely fine. It's just with the example I gave, node-sp-auth-config=* ends up being version 3.0.2 (C2) and and node-sp-auth (N1) pinned version 3.0.1 (C1).
So requiring N1 would require C1, then requiring C2 requires N1 which requires C1. So then any module scope data you put on C2 wouldn't be visible to C1, and N1 might be misconfigured. Therefore, the complete cycle package N+C can only contain singular versions. It is simply a (rare) configuration error to have 2 versions of this cycled package in a project IMHO.
The only "problem" you get with the fixed builder is that some projects incorrectly expect modules to be visible that they didn't request. This has been a long-standing issue and most projects figured it out, plus, as I understand, you can override dependencies in the flake file to fix these situations, right?

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/how-to-implement-this-recursive-algorithm-in-nix-shared-object-being-built-up/20384/1

I thought of a slightly different way - group cycles after every recursion call.
Since all cycles can be represented by any member, arbitrarily Asian the first member you find as "the name of the cycle".
Then, as you return from a recursive call, return a set of {"dep#ver"="firstdep#ver";} with every dep mentioned and the firstdep pointing to itself.
Then, gather the cycles of all your deps, and merge them by replacing the firstdep in the set you're adding with whatever it might be pointing to in the set you already have.

Another thoought: Having multiple versions of the same package in a cycle isn't necessarily a problem for some languages, so it should be handled in the builder (like in JS)

I got as far as generating a set of cycle members so far. Now I need to merge them to cycles named for the shortest member
{
      mergeCycles = left: right:
        left
        // (b.mapAttrs (dep: firstDep:
          if left ? dep
          then left.${dep}
          else if left ? firstDep
          then left.${firstDep}
          else firstDep)
        right);

      getCycles = pkg: seen: let
        deps = dependencyGraph."${pkg.name}"."${pkg.version}";
        pkgTag = "${pkg.name}#${pkg.version}";
      in
        b.foldl' mergeCycles {}
        (b.map (
            dep: let
              depTag = "${dep.name}#${dep.version}";
            in
              if seen ? "${depTag}"
              then lib.listToAttrs [(lib.nameValuePair depTag depTag) (lib.nameValuePair pkgTag depTag)]
              else getCycles dep (seen // lib.listToAttrs [(lib.nameValuePair pkgTag true)])
          )
          deps);
}

(I updated the example above btw)

:thinking: hmm there's still an error in the algo - es5-ext should be part of the d and es6-sybol cycle.

It is now fully working with https://github.com/nix-community/dream2nix/pull/195/commits/f52019be5595c6d31043496e7d246e0703fcf163
Here's a comparison of the output, as you can see it is backwards compatible.
new:
{
  new = {
    "@babel/helper-compilation-targets" = {
      "7.18.6" = [
        { name = "@babel/core"; version = "7.18.5"; }
      ];
    };
    "@webassemblyjs/ast" = {
      "1.9.0" = [
        { name = "@webassemblyjs/wast-parser"; version = "1.9.0"; }
        { name = "@webassemblyjs/wast-printer"; version = "1.9.0"; }
        { name = "@webassemblyjs/helper-module-context"; version = "1.9.0"; }
      ];
    };
    browserslist = {
      "4.21.2" = [
        { name = "update-browserslist-db"; version = "1.0.4"; }
      ];
    };
    es-abstract = {
      "1.20.1" = [
        { name = "function.prototype.name"; version = "1.1.5"; }
        { name = "string.prototype.trimend"; version = "1.0.5"; }
        { name = "string.prototype.trimstart"; version = "1.0.5"; }
      ];
    };
    es6-symbol = {
      "3.1.3" = [
        { name = "es6-iterator"; version = "2.0.3"; }
        { name = "d"; version = "1.0.1"; }
        { name = "es5-ext"; version = "0.10.61"; }
      ];
    };
    eslint = {
      "8.18.0" = [
        { name = "eslint-utils"; version = "3.0.0"; }
      ];
    };
    jest-resolve = {
      "28.1.3" = [
        { name = "jest-pnp-resolver"; version = "1.2.2"; }
      ];
    };
    listr-update-renderer = {
      "0.5.0" = [
        { name = "listr"; version = "0.14.3"; }
      ];
    };
    resolve-dir = {
      "1.0.1" = [
        { name = "global-modules"; version = "1.0.0"; }
      ];
    };
    slate-react = {
      "0.22.9" = [
        { name = "slate-react-placeholder"; version = "0.2.9"; }
      ];
    };
    styled-components = {
      "5.3.1" = [
        { name = "babel-plugin-styled-components"; version = "2.0.7"; }
      ];
    };
    webpack = {
      "4.44.1" = [
        { name = "terser-webpack-plugin"; version = "1.4.5"; }
      ];
    };
  };

original:
{

  orig = {
    "@babel/helper-compilation-targets" = {
      "7.18.6" = [
        { name = "@babel/core"; version = "7.18.5"; }
      ];
    };
    "@webassemblyjs/helper-code-frame" = {
      "1.9.0" = [
        { name = "@webassemblyjs/wast-printer"; version = "1.9.0"; }
      ];
    };
    "@webassemblyjs/helper-module-context" = {
      "1.9.0" = [
        { name = "@webassemblyjs/ast"; version = "1.9.0"; }
      ];
    };
    "@webassemblyjs/wast-parser" = {
      "1.9.0" = [
        { name = "@webassemblyjs/ast"; version = "1.9.0"; }
      ];
    };
    "@webassemblyjs/wast-printer" = {
      "1.9.0" = [
        { name = "@webassemblyjs/ast"; version = "1.9.0"; }
        { name = "@webassemblyjs/wast-parser"; version = "1.9.0"; }
      ];
    };
    babel-plugin-styled-components = {
      "2.0.7" = [
        { name = "styled-components"; version = "5.3.1"; }
      ];
    };
    es5-ext = {
      "0.10.61" = [
        { name = "es6-symbol"; version = "3.1.3"; }
      ];
    };
    es6-iterator = {
      "2.0.3" = [
        { name = "d"; version = "1.0.1"; }
        { name = "es5-ext"; version = "0.10.61"; }
        { name = "es6-symbol"; version = "3.1.3"; }
      ];
    };
    eslint = {
      "8.18.0" = [
        { name = "eslint-utils"; version = "3.0.0"; }
      ];
    };
    "function.prototype.name" = {
      "1.1.5" = [
        { name = "es-abstract"; version = "1.20.1"; }
      ];
    };
    global-modules = {
      "1.0.0" = [
        { name = "resolve-dir"; version = "1.0.1"; }
      ];
    };
    jest-pnp-resolver = {
      "1.2.2" = [
        { name = "jest-resolve"; version = "28.1.3"; }
      ];
    };
    listr-update-renderer = {
      "0.5.0" = [
        { name = "listr"; version = "0.14.3"; }
      ];
    };
    slate-react-placeholder = {
      "0.2.9" = [
        { name = "slate-react"; version = "0.22.9"; }
      ];
    };
    "string.prototype.trimend" = {
      "1.0.5" = [
        { name = "es-abstract"; version = "1.20.1"; }
      ];
    };
    "string.prototype.trimstart" = {
      "1.0.5" = [
        { name = "es-abstract"; version = "1.20.1"; }
      ];
    };
    terser-webpack-plugin = {
      "1.4.5" = [
        { name = "webpack"; version = "4.44.1"; }
      ];
    };
    update-browserslist-db = {
      "1.0.4" = [
        { name = "browserslist"; version = "4.21.2"; }
      ];
    };
  };
}


Datalist inside Bootsrap Modal

Hi there,
I am using this Data List Look up inside Modal like below :

I modified some z-index in mvc-datalist.css (+2000) so the Data List become on top of my bootstrap modal. Everything is ok except the Search Input, the cursor become disabled. I tried to look into some css/js what caused this problem and I can't find any clue.
Could you give me a possibility caused by this problem so I can try to look into.
Thank you.

Hi there,
Here a sample for this issue. I modify z-index (+2000) in mvc-datalist.css
sample.zip
Thank you.

It's bootstrap preventing the focus on modals with tabindex="-1".

Owh ok. Thank you.


HHH-13000 - Fix for refreshing entities under PESSIMISTIC_WRITE lock

Testcase provided separately in #2550
Issue: https://hibernate.atlassian.net/browse/HHH-13000

If 5.3.x is going to be around for a while (i.e. WF15?) I'd like to see this backported too

@beikov @JWGmeligMeyling I think that we should do this as well:
postRefreshLockMode = currentLockMode;

I want to test it for PESSIMISTIC_READ as well, so I'll add some extra test, and submit a new PR to replace this one afterward.

Ok, thanks! 👍

By the way, I agree with you that postRefreshLockMode = currentLockMode; should be set.

Superseded by this PR.


Client configuration for core

I think this is ready for review.
@yang-g please take the lead on this one.
@dgquintas please take a secondary look at new code, since you'll be writing to this API shortly.

Includes #2229, which should be merged first.

@jboeuf - PTAL at client connection establishment

#1809

Please hold off on merging this one until we get the ASAN problems sorted

Ack.

@murgatroid99 - once this is in I think it's safe to start the -Wconversion work

LGTM for security.

LGTM

Trying to isolate Windows failure.
@jtattermusch @nicolasnoble - any ideas?


https://jitpack.io/com/github/dhaval2404/imagepicker-support/1.7.1/imagepicker-support-1.7.1.pom'. Received status code 521 from server:

Summary

Code to reproduce

Android version

Impacted devices

Installation method

SDK version

Other information

Same issue

@naveedchaudhary300 this was an issue in jitpack and not in Library, I believe it is solved now so its okay to close the issue

jitpack going down happens more often than wanted, why not add mavencentral support?

JitPack might be facing issues. You can check their status page or social media accounts for any announcements or updates.
the  issue is  in jitpack and not in Library,