Redesign Lumo variants

Base the size of the handle in sizing properties instead of space properties.
Redesigned “small” variant – now just 1px divider and the handle is only visible on hover. The handle is now always the same size for normal and small, only the splitter part changes.
Rename “subtle” to “minimal” (align with other element variant names). The minimal variant doesn’t have any visible splitter, and the handle is only visible on hover.
Update demos to reflect the changes.
This is a breaking change, so I wanted to discuss this with a pull request before merging. The motivation for doing this change came from the “kitchen sink” test app that I built in the vaadin-lumo-styles repo, and these styles made the most sense for a clean application layout.

This change is

What goals do we pursue by hiding the handle?
The Lumo theme variants demo itself looks now as a couple of geometric shapes and my initial feeling once I opened it was "something looks definitely broken here, do I need to install dependencies etc".
Furthermore, depending on hover makes me sad regarding mobile devices support. 1px gray border does not seem to be something encouraging user to interact with, it is just barely noticeable after all.
I tried this with my android device and I was able to reveal handle on tap but rather occasionally. I clicked the left bar in the "Small" section and managed to do it, when I started clicking on the right one and the handle did not appear, but instead the handle for the left bar persists.
Overall UX impression is rather confusing to me, and the change is probably worth a couple of more UX tests.

Review status: 0 of 2 files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

Agree with @web-padawan. The handle is critical UX feature of this element, hiding it makes the split-layout appear as non-resizable. As mentioned, reveal on hover is unfriendly for touch input devices.

Review status: 0 of 2 files reviewed at latest revision, 2 unresolved discussions.

demo/split-layout-lumo-theme-demos.html, line 19 at r1 (raw file):

          div:first-child {
            background-color: var(--lumo-shade-5pct);

In the demos, style adjustments on top of default look could be confusing. Users might expect this background color in their layouts too.
Please avoid if possible. Maybe use different content in the panels instead, as seen in the other demos?

demo/split-layout-lumo-theme-demos.html, line 47 at r1 (raw file):

          div:first-child {
            background-color: var(--lumo-shade-5pct);

Same here.

Comments from Reviewable

Furthermore, depending on hover makes me sad regarding mobile devices support. 1px gray border does not seem to be something encouraging user to interact with, it is just barely noticeable after all.

Do consider that these are variants, not the default style. The responsibility for using these rely on the developer/designer working on any given app/layout. Touch devices always require different considerations than other pointer devices. But the default style is IMO a good compromise to support both sufficiently.

What goals do we pursue by hiding the handle?

The handle is critical UX feature of this element, hiding it makes the split-layout appear as non-resizable. As mentioned, reveal on hover is unfriendly for touch input devices.

Having an “invisible” split region is very common in many apps. MacOS Finder, Google Drive, browser developer tools, just to name a few. Many business apps tend to have these, as there is a need to try to maximize the number of usable pixels on the screen and to minimize unnecessary visual noise.
So the UX is already established on the desktop. For touch devices, there are less common examples available, and the ones that I know of look pretty much like our default variation.
Usually, there isn’t a visible handle even when hovering, but I thought it would be a nice improvement if someone would end up using those on a touch device, so they would get a hint that yes, you can actually drag this (if they tap on the divider).
--
You can argue we should not have these built-in if you think it should be left for the app developer to handle. But IMO, there are small details to consider when implementing a 1px/0px splitter, so it’s better if we have those already implemented when someone needs to use that.
--
I think you are raising an important topic, which we have discussed recently with Marc, that we should eventually provide design guidelines for all of our UI components so that designers and devs know when some variant is suitable to use and what caveats it possibly has. It’s part of the ongoing design systems/productization opportunity exploration we are doing.

Review status: 0 of 2 files reviewed at latest revision, 2 unresolved discussions.

demo/split-layout-lumo-theme-demos.html, line 19 at r1 (raw file):

The Lumo theme variants demo itself looks now as a couple of geometric shapes and my initial feeling once I opened it was "something looks definitely broken here, do I need to install dependencies etc".

Yeah, true. Any suggestions for the content? Red bg instead? :stuck_out_tongue_closed_eyes:

Comments from Reviewable

OK fine by me then.

Review status: 0 of 2 files reviewed at latest revision, 2 unresolved discussions.

demo/split-layout-lumo-theme-demos.html, line 19 at r1 (raw file):
Previously, jouni (Jouni Koivuviita) wrote…

The Lumo theme variants demo itself looks now as a couple of geometric shapes and my initial feeling once I opened it was "something looks definitely broken here, do I need to install dependencies etc".

Yeah, true. Any suggestions for the content? Red bg instead? :stuck_out_tongue_closed_eyes:

Maybe something like:

First

Second

Comments from Reviewable

Review status: 0 of 2 files reviewed at latest revision, 4 unresolved discussions.

theme/lumo/vaadin-split-layout.html, line 23 at r1 (raw file):

      [part="handle"]::after {
        content: "";
        position: absolute;

Any reason for using absolute here? Can we continue with flexbox instead?
Also, these 45% coord values below look very suspicious. Something like width: 10%; or flex-basis: 10%;` would be more readable IMO.

theme/lumo/vaadin-split-layout.html, line 61 at r1 (raw file):

      /* Small/minimal */

      :host([theme~="small"]) > [part="splitter"] {

DOM level of parts may be subject to change in future. Could you avoid using > combinator here and below?

Comments from Reviewable

Review status: 0 of 2 files reviewed at latest revision, 5 unresolved discussions.

theme/lumo/vaadin-split-layout.html, line 30 at r1 (raw file):

        border-radius: var(--lumo-border-radius);
        background-color: var(--lumo-contrast-30pct);
        transition: 0.1s all;

BTW transitions for all may lead to unexpected results. Would rather keep that assigned to known properties, if possible.

Comments from Reviewable

OK now I can see the point, but let's at least add some descriptions here in the demos, until we can refer to the documentation you mentioned.
One note about the naming: the "minimal" looks good but the "small" could be probably changed to something more descriptive.

Reviewed 2 of 2 files at r1.
Review status: all files reviewed at latest revision, 8 unresolved discussions.

demo/split-layout-lumo-theme-demos.html, line 10 at r1 (raw file):

Small

    <vaadin-demo-snippet id='split-layout-lumo-theme-demos-small'>

nit: please also change from single to double quotes

demo/split-layout-lumo-theme-demos.html, line 38 at r1 (raw file):

Minimal

    <vaadin-demo-snippet id='split-layout-lumo-theme-demos-minimal'>

nit: please also change from single to double quotes

theme/lumo/vaadin-split-layout.html, line 64 at r1 (raw file):

        min-width: 1px;
        min-height: 1px;
        background-color: var(--lumo-contrast-10pct);

consider using border instead. Using the background is risky, for example in desktop Safari 11, I pressed "zoom out" twice and the line disappeared.
FYI, the zoom issue with the background used like this previously existed in for paper-input underline, so we should ensure we do not use it in Material theme.

Comments from Reviewable

The handle styles broken in Firefox:

Review status: all files reviewed at latest revision, 8 unresolved discussions.

Comments from Reviewable

One note about the naming: the "minimal" looks good but the "small" could be probably changed to something more descriptive.

I can’t think of a good name. I could swap ”minimal” for the one with the visible line, and use “invisible” for the other. Not sure if that’s any better. Kept the names as they are for now.

The handle styles broken in Firefox

Can’t reproduce with Firefox 58.0.2, works as expected.

Review status: 0 of 4 files reviewed at latest revision, 8 unresolved discussions.

demo/split-layout-lumo-theme-demos.html, line 10 at r1 (raw file):
Previously, web-padawan (Sergey Kulikov) wrote…
nit: please also change from single to double quotes

Done, for all the demo pages.

demo/split-layout-lumo-theme-demos.html, line 19 at r1 (raw file):
Previously, platosha (Anton Platonov) wrote…
Maybe something like:

First

Second

Done.

demo/split-layout-lumo-theme-demos.html, line 38 at r1 (raw file):
Previously, web-padawan (Sergey Kulikov) wrote…
nit: please also change from single to double quotes

Done.

demo/split-layout-lumo-theme-demos.html, line 47 at r1 (raw file):
Previously, platosha (Anton Platonov) wrote…
Same here.

Done.

theme/lumo/vaadin-split-layout.html, line 23 at r1 (raw file):
Previously, platosha (Anton Platonov) wrote…
Any reason for using absolute here? Can we continue with flexbox instead?
Also, these 45% coord values below look very suspicious. Something like width: 10%; or flex-basis: 10%;` would be more readable IMO.

I was trying to make sure the visible handle element renders evenly on both sides of the split, by using offsets from both directions of the parent element. But I don’t think it had any noticeable effect, so I reverted back to flex container like you suggested. Also fixed the other dimension now to 4px. Let’s see if that becomes a problem, we can always open that up to be affected by Lumo sizing properties later on.

theme/lumo/vaadin-split-layout.html, line 30 at r1 (raw file):
Previously, platosha (Anton Platonov) wrote…
BTW transitions for all may lead to unexpected results. Would rather keep that assigned to known properties, if possible.

Done.

theme/lumo/vaadin-split-layout.html, line 61 at r1 (raw file):
Previously, platosha (Anton Platonov) wrote…
DOM level of parts may be subject to change in future. Could you avoid using > combinator here and below?

Without the combinator, nested split layouts will inherit the theme from their parent in polyfilled browsers.

theme/lumo/vaadin-split-layout.html, line 64 at r1 (raw file):
Previously, web-padawan (Sergey Kulikov) wrote…
consider using border instead. Using the background is risky, for example in desktop Safari 11, I pressed "zoom out" twice and the line disappeared.
FYI, the zoom issue with the background used like this previously existed in for paper-input underline, so we should ensure we do not use it in Material theme.

Done.

Comments from Reviewable

Reviewed 4 of 4 files at r2.
Review status: all files reviewed at latest revision, 3 unresolved discussions.

Comments from Reviewable

OK now looks good in Firefox.

Reviewed 4 of 4 files at r2.
Review status: :shipit: all files reviewed at latest revision, all discussions resolved, all commit checks successful.

Comments from Reviewable

Review status: :shipit: all files reviewed at latest revision, all discussions resolved, all commit checks successful.

Comments from Reviewable

Review status: :shipit: all files reviewed at latest revision, all discussions resolved, all commit checks successful.

Comments from Reviewable


Change Resin application ownership

overview
Resin has modified their billing system such that we have to change which user owns which Resin app. All our robots must be in apps owned by the user associated with our billing account.
This is not a code change, but tracking here for planning purposes.

All resin applications changed ownership to opentrons_mfg. Billing account was also changed to this via resin.


fix: failed build in ARM

Motivation
We had problems building the cryptography package when using alpine3.16, which comes with Rust 1.60
See the error in https://github.com/HathorNetwork/tx-mining-service/runs/6905469491?check_suite_focus=true
Downgrading to alpine3.15, which comes with Rust 1.56, still errors out: https://github.com/HathorNetwork/tx-mining-service/runs/6907057307?check_suite_focus=true
TODO
We still need further investigation.
Since the process apparently suffered a Kill -9, it's possible that it was using too much RAM during compilation and got OOM Killed.
For now, will are just disabling build in ARM, because the one in AMD still works.

I suggest switching the python base image from -alpine to -slim, which is Debian based. Mainly because it's easier and faster to just use the official wheels provided by cryptography, which use manylinux, which, if I'm not mistaken, works on Debian but not on Alpine.
I had a similar issue on hathor-core, however since we recently switched to a Debian base image it is now only affecting pypy+arm builds, because there aren't official wheels for those.
The other alternative I think would be to set-up our own runners, which we can make more beefy and also we can have arm runners that will run the arm tasks (although to make that work with the Docker build we'd have to make a few changes). But even just running our own runners seems like a big undertaking already.

I suggest switching the python base image from -alpine to -slim, which is Debian based. Mainly because it's easier and faster to just use the official wheels provided by cryptography, which use manylinux, which, if I'm not mistaken, works on Debian but not on Alpine.

Yeah, it makes sense to try to use the official wheels. But while learning about this, I saw that apparently they provide wheels for musllinux as well, not only manylinux: https://cryptography.io/en/latest/installation/#static-wheels
musllinux wheels should support Alpine.
Apparently our build was not using them just because Poetry was not prepared yet to use musllinux wheels: https://github.com/python-poetry/poetry/issues/5225
After upgrading to Poetry 1.2.0b2, the build was able to use the wheels as expected.
So I think this is enough to solve it. What do you think?


bug: Unable to scroll when content overflows

Add a scroll bar if the content overflows of the screen, or the window become small to fit the content.

Moved to ShadCN. Issue resolved


Fix Description of Options on Pulsar Admin

Motivation
https://pulsar.incubator.apache.org/docs/en/pulsar-admin/#get-1
https://pulsar.incubator.apache.org/docs/en/pulsar-admin/#getstatus
https://pulsar.incubator.apache.org/docs/en/pulsar-admin/#list-2
All to delete in description of options of the above URLs are unnecessary.
Modifications
Remove to delete.

run cpp tests


docs($interpolate): fix small typo

fix small typo
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
What is the current behavior? (You can also link to an open issue here)
What is the new behavior (if this is a feature change)?
Does this PR introduce a breaking change?
Please check if the PR fulfills these requirements

[x] The commit message follows our guidelines: https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#commit-message-format
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

Other information:

fixed small bug


Logging

See https://gist.github.com/ibeex/3257877 for more info on how to implement this.

Basic support is in there and working. Decisions on where to log other stuff can be made without this issue.


Film Service Additions

Add a section on the benefit of using a 16 bit tiff file in scanning workflow.
Go over the Frontier and the Noritsu: Goal to sell photographers on the Noritsu, why should they give it a try?
Example: "The Frontier came out in 2002, the camera that came out the year was 3MP"
Point: Technology changes over time and gets better, give this Noritsu a try, you just might like it.

updated prices of develop + scan. need to talk about develop + scan + print.

Just a reminder: We still need 'taglines' for the Frontier and Noritsu scanners under Develop + Scan.

A technicality, but... Under Dev + Scan + Print, in the B+W section, it says "All black + white scans arrive converted to true black + whites."
This could mean different things to different readers, escpecially those with enough technical knowledge. The files are still 8bit/channel RGB images. They aren't converted to Grayscale. They are 100% de-saturated RGB images.

Under "Scan Resolutions," should we stipulate dimensions for Noritsu scans? I assume they'll be different than Frontier large scans.

...And another thing... :) (sorry)
We have a 6x9 film gate for the Frontier scanners, so we should probably add 6x9 format scan resolutions to the Scan Resolutions tables.

ask @stephenbwood about Noritsu "scan resolutions" (for "large")
| 135 | 4x6 | xxx |
| 120 / 220 | 6x4.5 | xxx |
| 120 / 220 | 6x6 | xxx |
| 120 / 220 | 6x7 | xxx |
| 120 / 220 | 6x8 | xxx |
| 120 / 220 | 6x9 | xxx |
and
Frontier 6x9 resolution for "normal" and "large"
| 120 / 220 | 6x9 | xxx | xxx |

black and white issue desaturated RBG fixed.
added 6x9 film gate
need to talk with stephen on Noritsu resolutions

Recap of our conversation: No need to mention benefits of 16bit TIFF workflow.

@thisisveryimportant: Please to be also updating the "How large are your scans?" section of common-questions.md to include 6x9 & Noritsu resolutions. 😄

per our last email, completed

Per my eyeball vision, I don't see Frontier 6x9 or Noritsu scan resolutions in the "How large are your scans?" section of common-questions.md as of yet. 🙁 😃


WHICH IS IT!  - is Teams part of Skype for Business Online?  - is Skype for Business Online part of Teams PowerShell module?

the page says...
The latest Teams PowerShell public release is integrated with Skype for Business Online Connector, providing a single module for Teams PowerShell management.
Skype for Business PowerShell Connector: The Skype for Business PowerShell connector is now a part of Teams PowerShell module.
WHICH IS IT!

is Teams part of Skype for Business Online?
is Skype for Business Online part of Teams PowerShell module?
do they both have functionality across both Skype for Business and Teams?

This is terribly ambiguous!

@anwarmahmood1 Thanks for the feedback, could you kindly link the document you are referring to? Thanks!

@anwarmahmood1 We appreciate any feedback that improves the content in the Microsoft docs but we haven't had any response from you so we are going to close this issue.
Please feel free to re-open this issue if there is a specific area of the docs that we can improve or make better. Thank you.


[#16] blog title layout adjustment

Adjusts the title layout to fix issue #16.

Signed-off-by: flynnduism<EMAIL_ADDRESS>

Looks great - one minor question before we merge; do we want to check in the "resources" files as well as the theme, in this case?


Suggestion to improve BraveTraceContextProvider#getTraceContextLater

Feature Request

Is your feature request related to a problem? Please describe
Currently, there is an little issue with TracingContext propagation when using Kotlin Coroutines.
In coroutines, there is a class called ThreadContextElement. This allows for Context propagation with a ThreadLocal-like feel.
If we implement the following class, we can realize the propagation of TraceContext in Coroutines.
class TracingThreadContextElement(
    private val traceContext: TraceContext? = currentTraceContext()?.get(),
) : ThreadContextElement<CurrentTraceContext.Scope?> {
    override val key: CoroutineContext.Key<*>
        get() = KEY

    override fun updateThreadContext(context: CoroutineContext): CurrentTraceContext.Scope? {
        return currentTraceContext()?.maybeScope(traceContext)
    }

    override fun restoreThreadContext(context: CoroutineContext, oldState: CurrentTraceContext.Scope?) {
        oldState?.close()
    }

    companion object {
        val KEY = object : CoroutineContext.Key<TracingThreadContextElement> {}

        fun currentTraceContext(): CurrentTraceContext? {
            return Tracing.current()?.currentTraceContext()
        }
    }
}

withContext(TracingThreadContextElement(...)) {

    // traceContext is propagated in this coroutine scope

}

Coroutines implementation of lettuce is reactor-based. Therefore, a ReactorContext must be set up to propagate the TracingContext.
https://github.com/lettuce-io/lettuce-core/blob/7be77cb8298b456cb68754f71c5eb3fed412c0f9/src/main/java/io/lettuce/core/tracing/BraveTracing.java#L39-L46
Coroutine User needs to be aware of Reactor, which is undesirable.
Describe the solution you'd like
How about fallback to getTraceContext() when there was no ReactorContext in this part?
https://github.com/lettuce-io/lettuce-core/blob/7be77cb8298b456cb68754f71c5eb3fed412c0f9/src/main/java/io/lettuce/core/tracing/BraveTracing.java#L484-L495
@Override
public Mono<TraceContext> getTraceContextLater() {

    return Mono.deferContextual(Mono::justOrEmpty)
               .filter(it -> it.hasKey(Span.class) || it.hasKey(brave.propagation.TraceContext.class)).map(it -> {

                if (it.hasKey(Span.class)) {
                    return new BraveTraceContext(it.get(Span.class).context());
                }

                return new BraveTraceContext(it.get(brave.propagation.TraceContext.class));
            })
            .switchIfEmpty(Mono.justOrEmpty(getTraceContext())); // HERE !
}

This way, the TracingContext can be propagated if the aforementioned TracingThreadContextElement is used.
More to the point, even when using the reactive interface in Spring MVC, it is possible to propagate a TracingContext that is tied to the request thread.
@GetMapping("/reactive")
fun reactive(): String {
    return reactive.set("hoge", "hoge").block()!!
}

Describe alternatives you've considered
The problem can also be solved by lettuce user writing code like the following:
class CustomBraveTracing(delegate: io.lettuce.core.tracing.Tracing) :
    io.lettuce.core.tracing.Tracing by delegate {
    override fun initialTraceContextProvider(): TraceContextProvider {
        return CustomBraveTraceContextProvider.INSTANCE
    }
}

enum class CustomBraveTraceContextProvider : TraceContextProvider {
    INSTANCE;

    override fun getTraceContext(): TraceContext? {
        val tracer = Tracing.currentTracer()
        if (tracer != null) {
            val span = tracer.currentSpan()
            if (span != null) {
                return BraveTraceContext.create(span.context())
            }
        }
        return null
    }

    override fun getTraceContextLater(): Mono<TraceContext> {
        return Mono.justOrEmpty(traceContext)
    }
}

Teachability, Documentation, Adoption, Migration Strategy
NONE

The tracing context propagation code is written in a defensive way to avoid accidental propagation from the thread-local context. It would make sense to explore ways to fall back to the trace context if coroutine types are on the classpath.

The tracing context propagation code is written in a defensive way to avoid accidental propagation from the thread-local context

Yes, there is certainly a probability of accidental propagation. It's gonna be hard to make a decision.

It would make sense to explore ways to fall back to the trace context if coroutine types are on the classpath.

The idea also looks good.
However, depending on the application, there are cases where reactor and coroutines are used together.
(For example, Kotlin and Java mixed application)
Therefore, ideally it seems better to use thread-local only for Coroutines Interface.


RenameProvider & a lot of supporting infrastructure

Objective
Introduced 'F2' renaming functionality. Lisp not having any explicit means of contextually importing functions/variables made any solution sketchy. After a lot of considerations the "@Global" comment documentation keyword is the official "trigger" for what will be a valid cross-document renaming target. With that said, only 1 instance (of @Global) has to exist anywhere in the workspace, project or opened documents to make the keyword applicable across all of them. Do note, any instance using it will be "verified" that the tagged keyword wasn't localized; thus canceling the global flag. Finally, this is all perfectly contextual, a series of nested, but identical variable names are all scoped and acted upon according to their scope.
I will add that this infrastructure supporting F2 was also extremely foundational (new tooling) for cleaning up and/or enhancing Goto, AutoComplete and signature assistance.
Abstractions
Performance was a major obstacle in this PR. The LispContainer parser was reverted to the original non-index targeting version, then it was optimized to death until it was a full 2x faster than the formatting parser. Next I layered on additional value enhancements such as linear indexing, comment linking, non-native symbol aggregation; which caused another round of scavenging for performance. Leading to a StringBuilder class that leaned on character codes instead of character x character assembly of strings and that finally hit a sweet spot of features vs performance.
One important concept introduced in this PR is a "Flat View" of the document tree. Through extensive testing, it was proved to be an exceptionally performant process to flatten a LispContainer. With the current version of the parser pre-tagging every single LispAtom with its flattened index, linear traversal for things such as extracting  "contextual" comments becomes very performant. These flat indexes were also used to store primitive pointers to concrete objects; which has all kinds of memory, garbage collection and performance benefits. These will be the cornerstone of obtaining workspace autocompletion/signature data without major impacts to the user experience.
Configuration was another big change. Our "runTests.ts" was targeting 2 directories back further than it should have, which prevented the extension from loading, which oddly created more results than targeting the right directory. I eventually figured out this was tied to my ongoing issues with command line tests/coverage. Basically, they were running, but with a pre-opened drawing causing a scope conflict with the extension activation. There are now explicit operations in the tests to load a workspace, activate the extension, open files, and most importantly force close them before exit. It now doesn't matter if you run tests/coverage from vscode or from a command line, they should all "act" exactly the same way now...
A lot of things were touched, but I do think I've gone over everything enough times it should be a slam dunk if CI/CD doesn't baulk at my configuration changes.
Tests performed
There is definitively nothing part of this PR that isn't 95%-100% on test code coverage. In fact, the configuration work performed drastically improved the overall coverage of the root 'src' file groups.

Screen shot
Here is a demo of the new feature in action
https://user-images.githubusercontent.com/51800232/125433539-d5c72753-b415-486d-9a1e-4f7f035f04f3.mp4

@Sen-real & @hualin-whl all checks have passed...
This is a large PR, but it is all directly related to the same difficult task... I have not tested this on my Mac yet, but I will fire it up tomorrow, verify all expected tests still pass, and behaves as expected

@Sen-real , I had to update all the path normalizer(s) to favor forward slashes instead of backslashes and addressed all the CodeQL annotations. All of my stuff is passing just fine on the Mac and I did manual testing too.
However, the same 4 LispFormatter tests that have always been a problem on Mac are still failing, but I am not going to dig into why; at least not in this PR.


Duplicate information, please remove.

Duplicate information, please remove what I proposed.

@JohanFreelancer9 Copy editing is needed for this PR. Thanks.


Research API

To Look For

passing inventory in, gets recipes back
would like it to include photos
Catagories

dietary restrictions
ease of making
calories
cuisine type

@katiechurchwell Used download of github package containing 100 recipes. Will use these for now.


why repo name is not used?

As I recall, in the past Reservoir used to display repo name of GitHub. But now it seems to use directory name in list title.
why? I don't understand the merits of this modification.
thank you.

@Seasawher  Reservoir now uses the package name defined in the Lake configuration file of the package for its name (i.e., the foo of a package foo statement). This allows packages to have a different name from their repository on GitHub. This is useful, for example, if the repository has prefixes/suffixes indicating it is a Lean repository that don't really belong as part of the package name on the Lena-only Reservoir (e.g., socket.lean, lean4-cli). It also allows package names to support different character sets than what GItHub does  (e.g., have some unicode in them).
This change was made in #18.

@tydeu
Thanks for the reply. I see, so it refers to the package name rather than the directory name.
I have understood the benefits of the change.


Add support for rollout restart

Overview
Support for rollout restart in verion 0.15.0
Acceptance Criteria
To be able to restart deployments from @botkube
Reason
With automation of botkube coming up, it would be nice to be able to restart deployments automagically from the Botkube bot.

This should be possible once we implement #841 and #675 (initially planned for 0.19), as we won't need to validate each command manually 🙂

Closing as it is already implemented on main. The new Botkube release is coming really soon (next week!) 🚀


[UNR-3503] Check that AutomationTool is up to date when running Schema generation from the editor

Description
There is no dependency between the engine project and the automation tool. So when checking out the new engine version that is supposed to add the automation tool command we use to run schema generation, the user still has the old version. Then, when launching the schema generation from the editor, the command is not found and the generation fails.
With this modification, we check that the AutomationTool has the command we want to run, and asks the user to rebuild them if the command is not found.
It seems to be the cheapest and quickest fix since adding the dependency bewteen the projects would require modifying the Unreal Build Tool, regenerating projects (which users will likely not do), and recompile the engine (since the build tool has been updated).

Would have been nice if the original code was a bit more modular


OVA: workaround for consuming firmware from virt-v2v

The change to use -o kubvirt requires too many adjustments to the virt-v2v pod. For version 2.6, we will continue using -o local and add the firmware type to the created XML after it is detected from the virt-v2v output. Then, this value will be consumed in the controller to determine the missing firmware.

@bkhizgiy please review the changes in the second commit

@ahadas Looking good, I've added another small cleanup based on @bennyz suggestions.


Update README.md

Modify the local run steps to make sure to navigate to the right folder before starting the rushx command
What

Why

How Tested

Process & policy checklist

[x] I have updated the project documentation to reflect my changes if necessary.
[x] I have read the CONTRIBUTING documentation.

Is this a breaking change?

[ ] This change causes current functionality to break.

Unfortunately there is an issue with our build system that is blocking completing PRs from forks.
This PR has been included in #3718.
Closing this PR.


[PR][CLOSED] Fixed license issue that is resulted from scancode

 Issue by geunsik-lim
Thursday Jul 19, 2018 at 04:31 GMT
Originally opened as https://github.sec.samsung.net/STAR/TAOS-CI/pull/139

Resolves: issue #138

This commit is to fix cleanly possible license issues of open-source compliance
that is generated by Scancode.
ScanCode Toolkit is a set of code scanning tools to detect the origin and license
of code and dependencies. It uses a plug-in architecture to run a series of
scan-related tools in one process flow.
Changes proposed in this PR:

Fixed possible open-source license issues

Signed-off-by: Geunsik Lim<EMAIL_ADDRESS>
[Template] PR Description
In general, github system automatically copies your commit message for your convenience.
Please remove unused part of the template after writing your own PR description with this template.
$ git commit -s filename1 filename2 ... [enter]

Summarize changes in around 50 characters or less

More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of the commit and the rest of the text as the body. The
blank line separating the summary from the body is critical;
various tools like `log`, `shortlog` and `rebase` can get confused
if you run the two together.

Further paragraphs come after blank lines.

**Changes proposed in this PR:**
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, preceded
  by a single space, with blank lines in between, but conventions vary here.

Resolves: #123
See also: #456, #789

**Self evaluation:**
1. Build test: [ ]Passed [ ]Failed [*]Skipped
2. Run test: [ ]Passed [ ]Failed [* ]Skipped

**How to evaluate:**
1. Describe how to evaluate in order to be reproduced by reviewer(s).

Add signed-off message automatically by running **$git commit -s ...** command.

$ git push origin <your_branch_name>

geunsik-lim included the following code: https://github.sec.samsung.net/STAR/TAOS-CI/pull/139/commits

:octocat: cibot: Thank you for posting issue #163. The person in charge will reply soon.

 Comment by git-bot-sec
Thursday Jul 19, 2018 at 04:31 GMT

Thank you for submitting PR #139. Your PR has to pass all verificiation processes of cibot before getting a review process from reviewers. We recommend that you read instruction manual in . If you want to monitor the progress status of your PR in detail, visit http://aaci.mooo.com/.

 Comment by geunsik-lim
Thursday Jul 19, 2018 at 04:32 GMT

After PR #139: It's okay.


Feature/3 generate scaffold idempotent

Coverage increased (+0.4%) to 68.622% when pulling ea67eb74ad2353363a83c05b43025300b660f1fa on feature/3-generate-scaffold-idempotent into 3a80e27c2d1c7e7f8c899d6c3220056a510734bd on master.


Applying Theme Color on Server-Side with Identity = Unifinite Authorisation Loop

Hi,
I installed the components and made the team. I have relatively fresh Preview 8 with Server-side Blazor with out of the box Identity installation.  When I insert the theme color according to the guidelines on the page, it goes into an infinite loop while trying to check for Authorization.
My App.razor
<CascadingAuthenticationState>
    <Router AppAssembly="typeof(Startup).Assembly">
        <NotFoundContent>

Sorry, there's nothing at this address.

        </NotFoundContent>
        <NotAuthorizedContent>

Sorry

You're not authorized to reach this page. You may need to log in as a different user.

        </NotAuthorizedContent>
        <AuthorizingContent>

Please wait...

        </AuthorizingContent>
    </Router>
</CascadingAuthenticationState>

this works however. Initially, I placed the MatTheme tag at the top of the MainLayout and it wasn't working. However in the App.razor at the top, works.

Sorry, there's nothing at this address.

Sorry
You're not authorized to reach this page. You may need to log in as a different user.

Please wait...

@functions
{
    MatTheme theme = new MatTheme()
    {
        Primary = MatThemeColors.Indigo._800.Value,
        Secondary = MatThemeColors.Purple._900.Value
    };
}


Version Index

Create a separate memory mapped file that will store all existing versions in Mari as well as their offsets in the main memory mapped file for lookups on specific versions of data within the store

This has been implemented but is not needed as of now


Readme.md example logic error

Hi! There is no important error in readme file:

Please add checker to TopicProducer, so we can check isProducing from outside the topicProducer, cause right now the only way is to catch an Exception - which is the default php \Exception. You should have created your own IMHO.


How do I access the guestbook example?

Hi.
I'm new to Kubernetes (and CoreOS and Docker) and I'd like to see if I can get my Node.js apps running in Pods eventually. Right now I've gotten Kubernetes to run on linux (desktop pc) with this repo. I have ran the guestbook examplebut I'm not sure now how I access the HTTP service / website.

Hey
The key information you need is in the https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/services.md#external-services
This explains the different ways you can expose your service.
Looking at the latest definition for the frontend-service.json -
apiVersion: v1
kind: Service
metadata:
  name: frontend
  labels:
    name: frontend
spec:
  # if your cluster supports it, uncomment the following to automatically create
  # an external load-balanced IP for the frontend service.
  # type: LoadBalancer
  ports:
    # the port that this service should serve on
  - port: 80
  selector:
    name: frontend

The bit you need to pay attention to is the commented out type attribute. I would change this to 'NodePort' which would mean that the guestbook app would be accessible from each of the minions on a random port. Changing the attribute to 'LoadBalancer' would of course do this as well however the service wouldn't be load balanced in our instance.
To find out the port use kubectl and the describe command e.g.
kubectl describe services {servicename}

Hope this helps,
Mark

Thank you @mdevilliers. I find it curious that for the last month, a lot of people come here to understand and use the guestbook example. One should probably open an issue on the official project to make said example easier to test with.

No problem, I agree with you about the issue.
BTW Thanks for all your work


coroot: 1.5.11 -> 1.6.3

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/coroot/coroot/releases.
meta.description for coroot is: Open-source APM & Observability tool
meta.homepage for coroot is: https://coroot.com
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 1.6.3 in filename of file in /nix/store/86ma8xkfyqkmrhyididbv5qvijcbkn1r-coroot-1.6.3

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

coroot

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/86ma8xkfyqkmrhyididbv5qvijcbkn1r-coroot-1.6.3 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A coroot https://github.com/r-ryantm/nixpkgs/archive/4dcfb6a8bb6362c46c87dd0a1f8f05e82750623b.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/4dcfb6a8bb6362c46c87dd0a1f8f05e82750623b#coroot

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/86ma8xkfyqkmrhyididbv5qvijcbkn1r-coroot-1.6.3
ls -la /nix/store/86ma8xkfyqkmrhyididbv5qvijcbkn1r-coroot-1.6.3/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review

x86_64-linux

:white_check_mark: 1 package built:

coroot

Maintainer pings
cc @errnoh for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

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

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 360372

aarch64-darwin

:white_check_mark: 1 package built:

coroot


Gifski error

win10  X64
ScreenToGif v2.19.3

WIN10 1903
NET Framework 4.8

Make sure that you downloaded the Gifski.dll from Options > Extras.
Also make sure that there's no antivirus blocking the dll.

   at ScreenToGif.Util.GifskiInterop.Start(Int32 quality, Boolean looped, Boolean fast)
   at ScreenToGif.Windows.Other.Encoder.<Encode>d__24.MoveNext()

Are you trying to save the gif inside a folder which has non-latin characters? Or maybe the folder where the frames are stored has non-latin chars too.
You could try to download the beta version of 2.20, which is a pinned issue here.

您是否要将gif保存在具有非拉丁字符的文件夹中？也许存储帧的文件夹也具有非拉丁字符。
您可以尝试下载2.20的测试版，这是此处的固定问题。

I didn't set the non-Latin alphabet.

您是否要将gif保存在具有非拉丁字符的文件夹中？也许存储帧的文件夹也具有非拉丁字符。
您可以尝试下载2.20的测试版，这是此处的固定问题。

I didn't set the non-Latin alphabet.

So, you did not save the file to a folder or filename with any Chinese characters?
C:\User\您\动画制作.gif
This example would not work, for example.
Anyway, @boi114514 and @PhilipPino, try using  this version in here:
https://github.com/NickeManarin/ScreenToGif/issues/551

您是否要将gif保存在具有非拉丁字符的文件夹中？也许存储帧的文件夹也具有非拉丁字符。
您可以尝试下载2.20的测试版，这是此处的固定问题。

Thank you very much. The new version you provided solves the problem.

Great. The new version will be release next week.
The version that you downloaded is just a beta release.

For me the new version dont solved the problem.
I tried the gifski command version and I found out that we need some Visual C++ Redistributable.
https://support.microsoft.com/en-ae/help/2977003/the-latest-supported-visual-c-downloads

@PhilipPino
What's the entire error message that you get while trying to run the new version 2.20?
(make sure to delete the old DLL and download the new one while using v2.20)

I tried the gifski command version and I found out that we need some Visual C++ Redistributable. Now it worked.

The command version is not supported by ScreenToGif and it has other problems anyway (no support for variable framerate).

@PhilipPino
What's the entire error message that you get while trying to run the new version 2.20?
(make sure to delete the old DLL and download the new one while using v2.20)
EDIT:
Wait, I missed the part where you said that it worked, do you mean that v2.20 now works after installing the Visual C++ redist?

I only tested it to find the problem why gifski don't work. There was an error that says vcruntime140.dll is missing. After I installed the the vc++2015-2019 it worked also in your screentogif (v19 and v20)
In v20 the error was the same... but I think without vcruntime140.dll screentogif cant even run a gifsky command.

I only tested it to find the problem why gifski don't work. There was an error that says vcruntime140.dll is missing. After I installed the the vc++2015-2019 it worked also in your screentogif (v19 and v20)
In v20 the error was the same... but I think without vcruntime140.dll screentogif cant even run a gifsky command.
So you only need to know what vc library gifski exactly use and put then into the installer or something...

Ohh, now I understood. Thank you. I'm going to add a link so the user can download VC++, since it's a requirement for Gifski.

I mean, after using 2.20 directly, there's no problem. I didn't install Visual C + +.
------------------ 原始邮件 ------------------
发件人: "Philip<EMAIL_ADDRESS>发送时间: 2019年11月13日(星期三) 上午8:42
收件人<EMAIL_ADDRESS>抄送：  “ boi” <2506482048@qq.com>;“提及”<EMAIL_ADDRESS>主题: Re: [NickeManarin/ScreenToGif] Gifski error (#544)
@PhilipPino
尝试运行新版本2.20时收到的完整错误消息是什么？
（确保使用v2.20时删除旧的DLL并下载新的DLL）
编辑：
等等，我错过了您所说的地方，您的意思是说安装Visual C ++ redist后v2.20现在可以工作了吗？
我只测试了它为什么gifski不工作，发现问题。出现错误，提示缺少vcruntime140.dll。安装vc ++ 2015-2019后，它在您的screentogif（v19和v20）中也可以使用
在v20中，错误是相同的...但是我认为，如果没有vcruntime140.dll，screentogif甚至无法运行gifsky命令。

您收到此邮件是因为有人提到您。
直接回复此电子邮件，在GitHub上查看，或取消订阅。


fix: Replace default MainThreadScheduler on UAP

What kind of change does this PR introduce?
This replaces the usage of WaitForDispatcherScheduler and CoreDispatcherScheduler with a scheduler SingleWindowDispatcherScheduler that explicitly dispatches to the main app window regardless of how many windows are created by the application.
What is the current behavior?
See #2092, #2034 for more info. Should also resolve or at least improve the situation in #1001. Every window created by the CoreApplication gets it's own shiny new UI thread and CoreDispatcher. Example of this would be applications which use casting, ShareTarget, ProjectionManager or are just snazzy enough to have an app with multiple windows.
Because WaitForDispatcherScheduler uses a factory to get an instance of CoreDispatcherScheduler and CoreDispatcherScheduler uses Window.Current to obtain a CoreDispatcher there are multiple ways for MainThreadScheduler to be hijacked by a second window. For instance, if the thread being used by that window is returned to the thread pool (e.g. - by that window being closed or launching your main window from a ShareTargetActivated) then forever that [ThreadStatic] instance of MainThreadScheduler will attempt to dispatch to an non-existent window. This will surface in thread marshaling exceptions which will very likely crash the user's application (or cause nasty UI issues like controls which no longer update).
Of course, in these situations most devs will simply inject a scheduler into their view models for anything that used on a separate window. But this still won't block the hijacking because if code from the main window is ever executed on the thread separate window and then attempts to get an instance of MainThreadScheduler you could still have this problem. An example of this is code executing from the UI thread of window 2 updates an observable which is subscribed to on a view model or service being used in window 1. If in that code now in window 1 attempts to ObserveOn(RxApp.MainThreadScheduler) and MainThreadScheduler does not have an instance for that thread (which it likely wouldn't since we aren't using it on our other window in this example) it will grab the wrong dispatcher because for that thread Window.Current.Dispatcher is not in fact null, but is the dispatcher for window 2.
Since that is a very likely scenario in Rx, the problem should be solved in ReactiveUI.
What is the new behavior?
SingleWindowDispatcherScheduler does not use CoreDispatcherScheduler as its underlying scheduler, but does use code and patterns from that implementation.
It also does not use Window.Current to find the correct dispatcher. Instead it uses CoreApplication.Views to find the dispatcher. This has several advantages: 1) It is always available and you can get the correct dispatcher from any thread, 2) It is not possible to get the wrong dispatcher because your app's main window will always exist at CoreApplication.Views[0]
What might this PR break?
If for some reason a user was expressly relying on RxApp.MainThreadScheduler being of a specific type they will be discouraged from doing that ever again.
Please check if the PR fulfills these requirements

[] Tests for the changes have been added (for bug fixes / features)
[] Docs have been added / updated (for bug fixes / features)

Other information:
Unfortunately this code is not testable in a unit test, but then again neither are other platform schedulers (see NSRunloopScheduler). Since most of the actual dispatching code is taken from CoreDispatcherScheduler I think we are ok.
A separate PR will be added to the website documentation to make it VERY clear that ReactiveUI supports one window UWP environments only out of the box and suggest appropriate workarounds for multiple windows.
Also tested that this will not cause a regression on fixes from c5b9462 (original issue: #1221)

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

@glennawatson I did give a multiple window scheduler the good ole' college try but after about a week of testing I do not think it's possible. See an attempt here: https://gist.github.com/hinterlandsupplyco/c8e0396f6d837fdc9cd2a5b00688b451

I'm going to get multiple reviewers on this one who have some uwp experience. So hang in there.

Thanks for this one @hinterlandsupplyco sure it will assist others.

@glennawatson happy to contribute! :-)

this fix does not work in the constellation WPF +  WindowsXamlHost + UWP content.
CoreApplication.Views.Count is > 0, yet accessing CoreApplication.Views[0].Dispatcher throws an Exception. I'm looking into it, maybe I can implement a fallback for XamlIslands...

Hey @jasomwurzel if you can make a new issue even linking back to this one that would be great.

Hello. I have tested new SingleWindowDispatcherScheduler and found bug. One of my view models has such code
Observable.Interval(TimeSpan.FromSeconds(.5)).Select(_ => State)
.DistinctUntilChanged()
.SubscribeOn(RxApp.MainThreadScheduler)
.Subscribe(_ => this.RaisePropertyChanged(nameof(State)))
.DisposeWith(DisposableOnDestroy);
My app allows user to create new view by ProjectionManager.StartProjectingAsync. Sometimes when my app executes
await CoreApplication.CreateNewView().Dispatcher.RunAsync(CoreDispatcherPriority.Normal, () => {...});
COMException "Element not found" is fired, and execution is broken on this.RaisePropertyChanged(nameof(State) or outside my code (somewhere in System.Private.CoreLib.dll).
In first situation stack trace leads to
SingleWindowDispatcherScheduler.ScheduleOnDispatcherNow(TState state, Func<IScheduler, TState, IDisposable> action) line 152, where scheduler tries to get CoreApplication.Views[0].Dispatcher, but it cannot do it. I do not know why?
In second situation i cannot get stack trace but i think the problem is the same.
Can you help me?


renovate: Attempt to group GHA updates

It will never work to try to bump e.g. the upload and download actions as separate PRs.

Cool that worked in https://github.com/containers/bootc/pull/353

The renovate configuration for this repo is not consuming the global renovate configuration. I should be able to fix it.


[Add] Downloading button

Details
Animated downloading button
Screenshots

Type of Contribution

[ ] Update to an existing Animated Button
[X] Adding a new Button
[ ] Resolving a bug
[ ] Proposal to the Repository
[ ] Changes related to documentation or README.md
[ ] Other Changes

Checklist

[X] I have checked the existing issues
[X] I have read the Contributing Guidelines
[X] I am willing to work on this issue
[X] I am a GSSoC'23 contributor

Please check #1346


Routing problem

🐞 Bug report
Scully just finds, one route not others,

Hello, please provide further information in order to help you :

the steps you used
a repo to the project to test it

Closing due to inactivity

Hi, I'm facing the same issue. The way I'm using it is according to getting started page https://scully.io/docs/getting-started/.
Here is my AppRoutingModule
const routes: Routes = [
  { path: '', loadChildren: () => import('./home/home.module').then(m => m.HomeModule) },
  { path: 'docs', loadChildren: () => import('./docs/docs.module').then(m => m.DocsModule) },
];

@NgModule({
  imports: [RouterModule.forRoot(routes)],
  exports: [RouterModule]
})
export class AppRoutingModule { }

and this is my scully config
import { ScullyConfig } from '@scullyio/scully';
export const config: ScullyConfig = {
  projectRoot: './src',
  projectName: 'TestScully',
  outDir: './dist/static',
  routes: {
    docs: {
      type: 'default'
    }
  }
};
```

However, there is only one route showing in scully-routes.json and im not able to access /docs page.

Can you reopen this issue? Or briefly guide us through this?

Did you add the second route later on? did you try running npm run scully -- --scanRoutes?

Thank you @SanderElias! it works!


DO NOT MERGE Make VirtualIRFiles async

Needs benchmarks.

Updated with async I/O.
Benchmarks speak slightly in favor of keeping non-async I/O for the JVM side (I also expect it to be less memory heavy).

What do the 4 categories in the benchmark refer to?

full-async: this PR
pseudo-async: this PR w/o the last commit
direct: this PR which allocateDirect

I believe ScalaJSIRContainer.version should also become a Future[Option[String]] in the last commit.

I hoped to address this in the commit message. Maybe the new commit makes it clearer. LMK if it is still unclear.

Are the deserialize overloads taking InputStreams still used? If not I believe we could reverse the normal mode of serialize/deserialize to always use ByteBuffers, and potentially reclaim a bit more performance for that case.

Are the deserialize overloads taking InputStreams still used? If not I believe we could reverse the normal mode of serialize/deserialize to always use ByteBuffers, and potentially reclaim a bit more performance for that case.

This is an excellent idea. However, ByteBuffer doesn't have readUTF support, so we'd have to build it ourselves (or use a different format). Not sure what to do :S

We can build it ourselves. We already have it anyway in our implementation of DataInputStream.

Seems we have an endiannes problem: Node.js reads 534afeca instead of cafe534a.

According to the JavaDoc, ByteBuffers are always BIG_ENDIAN by default. Did we mess up something in our implementation of TypedArrayBuffers, perhaps?

No. The usage is messed up: TypedArrayBuffer have the endianness of the system but the SJS serialization is big endian. So we have to explicitly set the buffer to big endian (or require a big endian buffer).

Hum, looks like TypedArrayBuffer.wrap sets the endianness to the native endianness of typed arrays, which correspond to the native endianness of the CPU, so typically LITTLE_ENDIAN:
https://github.com/scala-js/scala-js/blob/ff7c2a5b625aca42b96ac3f07c86f57362cf2505/javalib/src/main/scala/java/nio/TypedArrayByteBuffer.scala#L234-L238
You could fix it by adding .order(java.nio.ByteOrder.BIG_ENDIAN) at https://github.com/scala-js/scala-js/pull/3578/commits/1996b7273207404eee2590c0b07cf4edf9d90bd4#diff-d76a1cead44ae0221c6eb29111c9f774R148

Yeah, I put it in Serializers instead. LMK if you have preferences.

Also, this is ready for review. Just needs another round of benchmarks :)

Benchmarks:

Updated. Note that in FileVirtualIRFiles the calls to Future should not be replaced by calls to Future.successful, because they actually do work. I have made this explicit by adding blocking markers (that should probably be there anyways).

Updated

Updated (removed whitespace).


Do not remove just created Docker image

docker image prune -f command removes just created spliit2 Docker image. We probably want to keep the image.
Fixes #151

The command docker image prune only removes dangling images, ie images that are not tagged.
The command is there to clean up previous builds of the image, as they are no longer tagged with the latest tag
While I disagree that removing this will fix #151, I also think that running prune every time is good practice, as it also removes any other dangling images (not only for spliit).
TLDR: I would be completely OK with this removal, but I doubt that it will solve the issues


Add icons for the 'CanvasGroup' and 'CodeEdit' nodes

This covers the 2D side of things for now. And yes, the CanvasGroup icon is just the grouping icon painted blue, and honestly, with the little space that icons have, I can't see a better icon to describe its function than one that people already see as "thing that groups stuff".

Thanks!


update readme for windows with new repository path

in https://github.com/magic-lang/rock/blob/master/Compile-Rock-on-Windows.md

Add cogneco as a remote  git remote add cogneco https://github.com/cogneco/rock
Fetch from and checkout the master branch from cogneco  git fetch cogneco   git checkout cogneco/master

I guess it should be `magic-lang``

Will be fixed in #35


BLE GATT Service and Characteristics ESP_UUID_LEN_128 issues (IDFGH-12682)

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.
1.7.1 Espressif IDF gatt_security_client demo
Espressif SoC revision.
esp32
Operating System used.
Windows
How did you build your project?
Command line with Make
If you are using Windows, please specify command line type.
PowerShell
Development Kit.
esp32
Power Supply used.
External 3.3V
What is the expected behavior?
before complete I (12337) GATTC_DEMO: ESP_GATTC_SEARCH_CMPL_EVT
expecting esp_ble_gattc_search_service(gattc_if, param->cfg_mtu.conn_id, &remote_filter_service_uuid);
case ESP_GATTC_SEARCH_RES_EVT: {
ESP_LOGI(GATTC_TAG, "SEARCH RES: conn_id = %x is primary service %d", p_data->search_res.conn_id, p_data->search_res.is_primary);
ESP_LOGI(GATTC_TAG, "start handle %d end handle %d current handle value %d", p_data->search_res.start_handle, p_data->search_res.end_handle, p_data->search_res.srvc_id.inst_id);
What is the actual behavior?
I (11547) GATTC_DEMO: 15 9b b3 48 a1 3d
I (11547) GATTC_DEMO: searched Adv Data Len 31, Scan Response Len 0
I (11557) GATTC_DEMO: searched Device Name Len 0
I (11557) GATTC_DEMO:
00:18:80:7c:27:2b
I (11617) GATTC_DEMO: 00 18 80 7c 27 2b
I (11617) GATTC_DEMO: searched Adv Data Len 7, Scan Response Len 21
I (11617) GATTC_DEMO: searched Device Name Len 19
I (11627) GATTC_DEMO: MAXREFDES104/HSP
I (11627) GATTC_DEMO: 3.0
I (11627) GATTC_DEMO:
I (11657) GATTC_DEMO: searched device MAXREFDES104/HSP3.0
I (11667) GATTC_DEMO: connect to the remote device.
I (11677) GATTC_DEMO: stop scan successfully
I (11687) GATTC_DEMO: 15 9b b3 48 a1 3d
I (11687) GATTC_DEMO: searched Adv Data Len 31, Scan Response Len 0
I (11687) GATTC_DEMO: searched Device Name Len 0
I (11697) GATTC_DEMO:
I (11887) GATTC_DEMO: ESP_GATTC_CONNECT_EVT conn_id 0, if 3
I (11887) GATTC_DEMO: REMOTE BDA:
I (11887) GATTC_DEMO: 00 18 80 7c 27 2b
I (11887) GATTC_DEMO: open success
I (12327) GATTC_DEMO: discover service complete conn_id 0
I (12337) GATTC_DEMO: Get service information from remote device
I (12337) GATTC_DEMO: ESP_GATTC_SEARCH_CMPL_EVT
I (12357) GATTC_DEMO: ESP_GATTC_CFG_MTU_EVT, Status 0, MTU 241, conn_id 0
Steps to reproduce.
#define REMOTE_SERVICE_UUID        {0x9E,0xCA,0xDC,0x24,0x0E,0xE5,0xA9,0xED,0x93,0xF3,0xA3,0xB5,0x00,0x00,0x40,0x6E}
#define REMOTE_NOTIFY_CHAR_UUID    {0x9E,0xCA,0xDC,0x24,0x0E,0xE5,0xA9,0xED,0x93,0xF3,0xA3,0xB5,0x01,0x00,0x40,0x6E}
using this UUID basis of below hardware details
BLE GATT Service and Characteristics
This document covers the main service consisting of two characteristics. The notify data characteristics is used during data streaming, where the device is
actively collecting data and transmitting raw data back to the master. The read/write configuration characteristics is used to setup the system and to
perform low level read/write operations.
UUID Type Description
6E400000-B5A3-F393-E0A9-E50E24DCCA9E Service Service Declaration
6E400001-B5A3-F393-E0A9-E50E24DCCA9E Characteristic Notify Data Characteristic
6E400002-B5A3-F393-E0A9-E50E24DCCA9E Characteristic Read/Write Configuration Characteristic
Debug Logs.
No response
More Information.
the same module work with manufacture's windows application
https://www.analog.com/en/resources/reference-designs/maxrefdes104.html

The Bluedroid host supports 128-bit UUIDs. It's important to note that 128-bit UUIDs are divided into base 128-bit UUIDs and non-base 128-bit UUIDs. For base 128-bit UUIDs, Bluedroid converts them into 16-bit UUIDs. The conversion rules can be found in "BLUETOOTH CORE SPECIFICATION Version 5.4 | Vol 3, Part B page 1181."
I can provide you with a patch to demonstrate the use of 128-bit UUIDs. You can test it with the following two examples:
esp-idf/examples/bluetooth/bluedroid/ble/gatt_client
esp-idf/examples/bluetooth/bluedroid/ble/gatt_server
0001-fix-bt-bluedroid-Debug-for-ble-service-change-charac.zip

If you have any further questions regarding the use of 128-bit UUIDs, please contact us.

Hello
Thanks for your reply
I am facing another strange problem with your GPIO pins,
when nearest any appliance switch  on/off time trigger my inputs also, what
i can do for this ?
#define IGNITION_SWITCH     4
#define HANDLE_SWITCH       12
#define GPIO_INPUT_PIN_SEL  ((1ULL<<HANDLE_SWITCH) | (1ULL<<IGNITION_SWITCH
))
what i can do for this issue
Thanks
VN Rajesh Kumar
+91<PHONE_NUMBER>
On Wed, Apr 24, 2024 at 2:34 PM zhp-espressif @.***>
wrote:

The Bluedroid host supports 128-bit UUIDs. It's important to note that
128-bit UUIDs are divided into base 128-bit UUIDs and non-base 128-bit
UUIDs. For base 128-bit UUIDs, Bluedroid converts them into 16-bit UUIDs.
The conversion rules can be found in "BLUETOOTH CORE SPECIFICATION Version
5.4 | Vol 3, Part B page 1181."
I can provide you with a patch to demonstrate the use of 128-bit UUIDs.
You can test it with the following two examples:
esp-idf/examples/bluetooth/bluedroid/ble/gatt_client
esp-idf/examples/bluetooth/bluedroid/ble/gatt_server
0001-fix-bt-bluedroid-Debug-for-ble-service-change-charac.zip
https://github.com/espressif/esp-idf/files/15091577/0001-fix-bt-bluedroid-Debug-for-ble-service-change-charac.zip
—
Reply to this email directly, view it on GitHub
https://github.com/espressif/esp-idf/issues/13673#issuecomment-2074457624,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAXF34RIK3ZZJSIOLMESINLY65YS3AVCNFSM6AAAAABGTYRQCOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZUGQ2TONRSGQ
.
You are receiving this because you authored the thread.Message ID:
@.***>

@rajeshktym
This is a new issue(GPIO). Please create another GitHub issue, and our more experienced colleagues will help you with the GPIO problem.

Hello @rajeshktym were you able to get 128 bit UUID's?


1 File Of pure C?

 The description says "in one file of pure c" but it clearly has more than one file, and uses python too.

come on man, be nice. you can inference the model in one file of pure c, which is the run.c file.

Sorry but it says one file, there is way more. You can run almost all games in one fil


examples: Add RBAC ClusterRole, binding, and namespace

Define an RBAC ClusterRole for update-operator and update-agent
Create a separate namespace "reboot-coordinator" for components
Previously, CLUO would run in the kube-system namespace, where it had admin privilege to do anything on most clusters.

Testing
I've used these examples to do some simulated cluster upgrade tests. I think I've included each permission we need, but its hard to be certain.
update-operator
I1004 20:47:06.408558       1 main.go:77] /bin/update-operator running
I1004 20:47:06.504233       1 leaderelection.go:179] attempting to acquire leader lease...

I1004 21:02:15.497952       1 operator.go:517] Found 0 rebooted nodes
I1004 21:02:45.535740       1 operator.go:517] Found 0 rebooted nodes
I1004 21:03:15.575713       1 operator.go:517] Found 0 rebooted nodes

update-agent
I1004 20:56:47.848041       1 main.go:42] /bin/update-agent running
I1004 20:56:47.848152       1 agent.go:79] Setting info labels
I1004 20:56:47.875615       1 agent.go:90] Setting annotations map[string]string{"container-linux-update.v1.coreos.com/reboot-needed":"false", "container-linux-update.v1.coreos.com/reboot-in-progress":"false"}
I1004 20:56:47.953218       1 agent.go:101] Marking node as schedulable
I1004 20:56:47.992487       1 agent.go:111] Waiting for ok-to-reboot from controller...
I1004 20:56:47.992637       1 agent.go:220] Beginning to watch update_engine status
I1004 20:56:47.993483       1 agent.go:175] Updating status
I1004 20:59:06.247778       1 agent.go:175] Updating status
I1004 20:59:06.247802       1 agent.go:185] Indicating a reboot is needed
I1004 20:59:55.685095       1 agent.go:125] Setting annotations map[string]string{"container-linux-update.v1.coreos.com/reboot-in-progress":"true"}
I1004 20:59:55.725304       1 agent.go:137] Marking node as unschedulable
I1004 20:59:55.740044       1 agent.go:142] Getting pod list for deletion
I1004 20:59:55.766850       1 agent.go:151] Deleting 3 pods
I1004 20:59:55.766934       1 agent.go:154] Terminating pod "container-linux-update-operator-3421875347-454lm"...
I1004 20:59:55.784403       1 agent.go:154] Terminating pod "iperf"...
I1004 20:59:55.833088       1 agent.go:154] Terminating pod "container-linux-update-operator-3421875347-l7611"...
I1004 20:59:55.886383       1 agent.go:161] Node drained, rebooting
....
I1004 21:02:19.906335       1 main.go:42] /bin/update-agent running
I1004 21:02:19.906381       1 agent.go:79] Setting info labels
I1004 21:02:19.944694       1 agent.go:90] Setting annotations map[string]string{"container-linux-update.v1.coreos.com/reboot-in-progress":"false", "container-linux-update.v1.coreos.com/reboot-needed":"false"}
I1004 21:02:19.971217       1 agent.go:101] Marking node as schedulable
I1004 21:02:19.979572       1 agent.go:111] Waiting for ok-to-reboot from controller...
I1004 21:02:19.979764       1 agent.go:220] Beginning to watch update_engine status
I1004 21:02:19.980468       1 agent.go:175] Updating status

Later: It would be possible to define separate service accounts for the update-operator and update-agent, but to do this incrementally, let's start by just defining a namespace with the appropriate access for both.
Closes: #128

We should remove endpoints and add configmaps for #140


Possibility to perform upsampling

Dear mainteners, we tested autoprognosis with one of our dataset with class highly imbalanced (event proportion =16%). Autoprognosis returned values of sensitivity to 0 and specificity to 1(classification of all patients as non event). Would it be possible to add an upsampling step in the AutoML solution for these specific case or to change the optimisation metrics?
Thanks in advance
All the best
jb

This is not currently planned unfortunately but you can use other open source libraries like sklearn, imblearn to perform this on your dataset before using autoprognosis


irc: do not bridge CTCP commands other than ACTION

CTCP commands other than ACTION are designed for client-to-client interaction on IRC networks. Drop such messages when we receive them.
Also get rid of a "CTCP_ACTION" handler in the handler registration. The registration

can't do anything (if anything, we wanted the string constant
girc.CTCP_ACTION, which is "ACTION")
doesn't do anything in this context, because CTCP handlers are
registered separately:
https://github.com/lrstanley/girc/blob/f47717952bf9258e02eac14f1b9723bcf084e618/ctcp.go#L205

The PRIVMSG handler already listens to all CTCPs.
Thanks to @lexande for the bug report (found on a live instance).

Thanks 👍


SD-1537 As a Admin on Integrations -> Webhooks I can manage Webhook subscribers

Issues:

Spree.t(:shipping_rates) returns some kind of a hash
When you are subscribed only to variant.create -> on edit page the checkbox for all variants events is checked an on save you will be subscribed to all variant events
Translations

This needs to be merged first: https://github.com/spree/spree/pull/11489

Also blocked by https://github.com/spree/spree/pull/11495

@aleksandarpetrushev The two auto generated spree_dashboard javascript files should not be in the PR.

@damianlegawiec  @MatthewKennedy Translations need to be added. Especially because Spree.t(:shipping_rates) returns a hash.

There are several missing translations, please add them
Default checked option should be subscribed to all events
Let's not list the events under the models, it makes the view very cluttered

Not sure where to add the translations TBH, should it be config/locales/en.yml or in spree_i18n?

There are several missing translations, please add them
Default checked option should be subscribed to all events
Let's not list the events under the models, it makes the view very cluttered

@damianlegawiec Not sure where to add the translations TBH, should it be config/locales/en.yml or in spree_i18n?

https://github.com/spree/spree_backend/blob/main/config/locales/en.yml

@aleksandarpetrushev

There are still some missing migrations (please see screenshot attached)
Checkboxes for selecting events - please use the same markup I did for the active checkbox, also when clicking on the label it should check/uncheck the checkbox/toggle

@damianlegawiec Boostrap issue, checkboxes are 3 by 3 in rows. Not sure how to make them be 2 in a row for smaller screen

I put them 6 in each row. Because when you want 2 columns it can evenly divide the row into 3 and when you want 3 columns it can divide the row in 2. 6 is divisible by 3 and by 2.
#engineering


Harmony: fix EstimateQuarter alias view

PR includes

[x] Bug Fix

Related issues
Resolve #1019
QA Instructions, Screenshots, Recordings

/canary

/canary

/canary

/canary

/canary


RUMM-825 allow configuration of Batch Window Duration

What does this PR do?
This allows customers to choose the batch window duration which will impact the size of the upload requests

Codecov Report

Merging #453 (04e639e) into master (4971944) will decrease coverage by 0.14%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##             master     #453      +/-   ##
============================================
- Coverage     90.29%   90.15%   -0.14%
- Complexity     1287     1291       +4
============================================
  Files           154      155       +1
  Lines          4314     4333      +19
  Branches        488      488
============================================
+ Hits           3895     3906      +11
- Misses          259      265       +6
- Partials        160      162       +2

Impacted Files
Coverage Δ
Complexity Δ

...oid/src/main/kotlin/com/datadog/android/Datadog.kt
86.57% <ø> (-1.49%)
29.00 <0.00> (-1.00)

.../datadog/android/core/configuration/Credentials.kt
100.00% <ø> (ø)
6.00 <0.00> (?)

...in/com/datadog/android/core/internal/SdkFeature.kt
100.00% <ø> (ø)
20.00 <0.00> (ø)

...dog/android/log/internal/domain/LogFileStrategy.kt
100.00% <ø> (ø)
1.00 <0.00> (ø)

...dog/android/rum/internal/domain/RumFileStrategy.kt
100.00% <ø> (ø)
1.00 <0.00> (ø)

...oid/tracing/internal/domain/TracingFileStrategy.kt
100.00% <ø> (ø)
1.00 <0.00> (ø)

...c/main/kotlin/com/datadog/android/DatadogConfig.kt
94.87% <100.00%> (-0.49%)
12.00 <0.00> (-1.00)

...om/datadog/android/core/configuration/BatchSize.kt
100.00% <100.00%> (ø)
3.00 <3.00> (?)

...atadog/android/core/configuration/Configuration.kt
92.93% <100.00%> (ø)
6.00 <0.00> (?)

...n/com/datadog/android/core/internal/CoreFeature.kt
98.31% <100.00%> (+0.07%)
42.00 <2.00> (+2.00)

... and 12 more


onSealed never stops polling

Problem
When I call const transaction = await fcl.tx(transactionId).onceSealed(); the polls keep happening even after the transaction has resolved. This happens both with valid transaction IDs as well as non-existent transaction IDs.
const nonExistentTransactionId =
      'f0271658fa435e8xxxxxxfa8366f8263d88a9f615488ac42a096031d40849ixa';
// On testnet
const validTransactionId =
      'f0271658fa47535e856062afa8366f8263d88a9f616488ac42a096031d40849a';

It keeps polling:
...

Configure flow with config.
Load a transaction.

const [isFetchingTransaction, setIsFetchingTransaction] = useState(true);
const [transaction, setTransaction] = useState<
  fcl.TransactionObject | undefined
>();

useEffect(() => {
  async function loadTransaction() {
    try {
      const transaction = await fcl.tx(transactionId).onceSealed();
      setTransaction(transaction);
    } catch (error) {
      console.warn(error);
    } finally {
      setIsFetchingTransaction(false);
    }
  }

  loadTransaction();
}, [transactionId]);

Acceptance Criteria
The polls actually stop.
Context
Nothing is blocked as I'm still in dev mode and its okay that the app is overpolling.

@janhesters I haven't been able to reproduce this issue. Did you find a problem with your React code or a solution?

@janhesters Closing for now, please reopen if this issues re-appears!


[doc] "View in Store" has incorrect link when reverseProxy is enabled

Description:
-When we enable reverseProxy in site.json for store or/and publisher, it doesn't update the "View in Store" button's link in publisher pages and still uses value from api-manager.xml.
<API-M_HOME>/repository/deployment/server/jaggeryapps/store/site/conf/site.json
<API-M_HOME>/repository/deployment/server/jaggeryapps/publisher/site/conf/site.json
"reverseProxy" : {
        "enabled" : true,
        "host" : "apistore.com", // If reverse proxy do not have a domain name use IP
        "context":"/apimanager/store",
        "regContext":"" // Use only if different path is used for registry
    }

We have to update  URL under APIStore in <API-M_HOME>/repository/conf/api-manager.xml file.
<APIStore>
    <URL>https://apistore.com/apimanager/store</URL>
</APIStore>

[1] https://docs.wso2.com/display/AM210/Configuring+the+Proxy+Server+and+the+Load+Balancer
[2] https://docs.wso2.com/display/AM191/Adding+a+Reverse+Proxy+Server
[3] https://docs.wso2.com/display/AM200/Configuring+a+Single+Node
[4] https://docs.wso2.com/display/AM210/Configuring+the+Proxy+Server+and+the+Load+Balancer
[5] https://docs.wso2.com/display/AM200/Configuring+an+Active-Active+Deployment
Suggested Labels:
Doc, Improvement

None of the above documents describes about the change to be done in api-manager.xml

I’m closing this issue because it has been inactive for more than two years. Please reopen if you still encounter this issue with the latest version.


chore: use ads icons

Description
Why did this PR appear? I wanted to replace the icons from ads-old with the icons from ads. After that, I had to fix some affected components in ads-old and in the main app. In the process, I discovered that a large amount of code is simply not being used.
Automation
/ok-to-test<EMAIL_ADDRESS>:mag: Cypress test results

[!CAUTION]
🔴 🔴 🔴 Some tests have failed.
Workflow run: https://github.com/appsmithorg/appsmith/actions/runs/10406057728
Commit: 8047bfa066a3d120596155793903e5766ab4ee6f
Cypress dashboard.
Tags: @tag.All
Spec:
The following are new failures, please fix them before merging the PR:
cypress/e2e/Regression/ClientSide/Workspace/UpdateWorkspaceTests_spec.js
List of identified flaky tests.
Thu, 15 Aug 2024 23:15:40 UTC

Communication
Should the DevRel and Marketing teams inform users about this change?

[ ] Yes
[x] No

Summary by CodeRabbit

New Features

Introduced email and non-empty validation utilities for enhanced form handling.
Added the IconCollection export, providing more flexible icon management.

Improvements

Simplified and streamlined component props across various components for better readability.
Updated loading indicators using a dedicated Spinner component for improved user experience.

Bug Fixes

Fixed issues with icon type handling, enhancing type safety across components.

Refactor

Removed unused imports and simplified conditional rendering logic in multiple components.

Style

Updated icon class names to align with the new design system (.ads-v2-icon).

Chores

Cleaned up commented-out code and unnecessary dependencies to enhance maintainability.

/build-deploy-preview skip-test=true


fvm list[BUG]

fvm version form  3.1.7
FVM_USE_GIT_CACHE ?
FVM_GIT_CACHE_PATH?
FVM_FLUTTER_URL?
FVM_PRIVILEDGED_ACCESS?
how to config?

@yjt1216 have you taken a look at https://fvm.app/documentation/getting-started/configuration?


Bundle pre-migrated empty database into installers to reduce load time

The first time the server is started, it takes a long time to load (see https://github.com/learningequality/installers/issues/78), and the longest-running task is the database migration. When the setup was run from the command line, at least the user saw that something was happening, but now it just seems like it's hanging.
If we can bundle a pre-migrated (but empty) database in (like we do in the Android app), this should cut down the load time very significantly. Steps to create such a database:

Delete any existing database
Run bin/kalite manage syncdb and then bin/kalite manage migrate --merge
Do not run setup, or start the server (as that will start adding data)

This is a great idea! What about shipping it as a data file in the source directory? It seems useful to all new deployments...

Now done in the KA Lite. See https://github.com/learningequality/ka-lite/pull/4656. Empty db included if it exists, which it does if you build a distributable using our handy-dandy makefile.

Just to clarify: This won't happen until 0.16, right? At least, that's how it is for the .debs where it's the ka-lite source dist that's responsible for this....

Right.


[Theme] support for 'on' colors?

The Material Design docs advocate for theme palette values for "on" colors like onPrimary, onSurface, etc. Are there plans to support these in the theme.palette object?

[x] I have searched the issues of this repository and believe that this is not a duplicate.

Summary 💡

I'm just looking to understand the philosophy and if this is on the roadmap. I'm working on a white label application that needs to support a robust theming solution. We have embraced the (newer) MD theme model where svg strokes and typography are colored based on these "on" colors. If text appears on top of a primary colored surface, it uses the onPrimary color.
We have also extended this to the color prop on small components. E.G. our Button can take color="primary" or color="onPrimary".

When I look through Material UI's default theme, it looks like the palette shape hasn't changed since MD1. The palette still supports accent colors, for example, which are no longer part of the MD2 color palette recommendations. I assume that the palette.primary.contrastText value is supposed to represent this?
Can we expect to see support for these 'on' colors in the theme.palette object or in the component APIs in the future?
Examples 🌈

Yes, contrastText is supposed to serve this exact purpose, as far as I understand the specification. So, I think that we are all good.

contrastText is supposed to serve this exact purpose

It is, (although it predates the spec having such a concept), but it isn't possible to apply it to typography. Also, while the v2 spec doesn't distinguish between primary and primary variant when it comes to the contrast color, it may be that it needs to be different for main / light / dark.
We could add theme.palette.primary.onMain', theme.palette.primary.onLight', `theme.palette.primary.onDark' etc to the theme, and where it makes sense, to the component color API (principally typography, but the button example is interesting).
@petegivens For the moment you have access to theme.palette.getContrastText, and to set the the related theme.palette.contrastThreshold if needed. And of course you can always add the on colors to the palette yourself, but you would still have to wrap Typography to take advantage of it.

Also, while the v2 spec doesn't distinguish between primary and primary variant when it comes to the contrast color, it may be that it needs to be different for main / light / dark.

This is true. There's no way to know in advance which level of the primary palette will require white or black text on top of it. Even MaterialUI's system of having primary.main, primary.light, and primary.dark doesn't really work for us. In some of our clients' color palettes, their main primary color is primary900. MaterialUI seems to assume that all color palettes will use primary500 as the main primary so you can always step 2 levels lighter or darker.  But that's a bit of a digression I suppose.

@petegivens For the moment you have access to theme.palette.getContrastText, and to set the the related theme.palette.contrastThreshold if needed. And of course you can always add the on colors to the palette yourself, but you would still have to wrap Typography to take advantage of it.
That's the approach we'll take in the interim. I think adding the on colors to the typography and icon component APIs (<Typography variant="h1" color="onPrimary" />) is an idea worth exploring as it will ensure tighter alignment with the MD spec. The Button example I listed above is not part of MD spec AFAIK--they seem to only advocate using on colors for typography and svg strokes.

Even MaterialUI's system of having primary.main, primary.light, and primary.dark doesn't really work for us. In some of our clients' color palettes, their main primary color is primary900

Light and dark do work with 900 colors. You can try it in the docs. If the calculated light and dark values don't work for you, you can adjust theme.palette.tonalOffset, or you can provide all three colors directly.

Light and dark do work with 900 colors. You can try it in the docs. If the calculated light and dark values don't work for you, you can adjust theme.palette.tonalOffset, or you can provide all three colors directly.

I don't understand how that's working. If I set my primary.main color to primary900, it does indeed generate a "darker" primary color, but it won't be a color that exists in my primary color palette (p50-p900). Does it just auto generate a color that's some percentage darker than primary.main?

Looked up the source code and it seems that my assumption is correct. The color tool calls theme.palette.augmentColor to create the dark and light variants. augmentColor itself calls lighten and darken on primary.main. So my concern is that generating a dark primary color in this way won't work for us since it won't be an approved theme palette color. I wonder if our understanding of the material color palette is wrong, and our main primary color should always be primary500?

it won't be an approved theme palette color

Even if you provide a 500 color for main, light and dark won't be "approved" colors, as they are calculated rather than using the palette colors. You have to provide specific colors for light, main and dark if you want to strictly follow the v1 spec colors.
Google have opened up to non v1 palette colors anyway:

2014 Material Design color palettes
These color palettes, originally created by Material Design in 2014, are comprised of colors designed to work together harmoniously, and can be used to develop your brand palette. To generate your own harmonious palettes, use either the palette generation tool or Material Theme Editor.

Custom colors in the palette tool: https://material.io/resources/color/#!/?view.left=0&view.right=1&primary.color=7f2644

@mbrookes Great point. I did a quick fuzzy search for primary.dark and primary.light in the MUI repo and it seems that they aren't used nearly as frequently as I would have guessed. The way that MD's color picker tool displays them, it seems like they are meant to serve as accent colors (or what they are not calling primary variant / secondary variant?). So I think my whole understanding of their purpose was flawed.
I appreciate the discussion. I don't have any more questions at this point so feel free to close this issue. I do think that adding onPrimary, onSecondary, onBackground, etc. might be a good addition to the typography and icon APIs, but this is easily accommodated on my end by thinly wrapping those components.

I have no objection to them being added.

I do think that adding onPrimary, onSecondary, onBackground, etc. might be a good addition to the typography and icon APIs, but this is easily accommodated on my end by thinly wrapping those components.

@petegivens The latest strategy is to allow people to use any color from their palette: https://material-ui.com/system/palette/#color. I would imagine that primary could be aliased to primary.main? 🤔 In the case of these colors, I would propose primary.contrastText to reflect the theme structure.

This issue is outdated (MD2 related). We aim to have a fresh look for Material UI in the near future, so I’m closing this.


Better openwhisk emulation: response doesn

the server tests for a response object inside the result from the action invocation. but this is a left over from the pipeline. it should only test for the same result as the action would return.


pls update depandency

bitsdojo_window ^0.0.9 requires plugin_platform_interface ^1.0.1, which is not compatible with other plugins that depend on plugin_platform_interface ^2.0.0

Fixed by https://github.com/bitsdojo/bitsdojo_window/commit/3fd4412c7b071e257b3ff33c863438ad358049ab


python310Packages.homematicip: 1.0.13 -> 1.0.14

Diff: https://github.com/hahn-th/homematicip-rest-api/compare/refs/tags/1.0.13...1.0.14
Changelog: https://github.com/hahn-th/homematicip-rest-api/releases/tag/1.0.14
Description of changes

Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 219595 run on x86_64-linux 1

3 packages built:

home-assistant-component-tests.homematicip_cloud
python310Packages.homematicip
python311Packages.homematicip


k8s rbac: moving network policies away of extensions

With kubernetes network policy changed to GA we also need to change
RBAC accordingly.
Signed-off-by: André Martins<EMAIL_ADDRESS>@tgraf do we need to create networkpolicies with cilium?

examples/minikube/l3_l4_policy.yaml is still using v1beta1 NetworkPolicy

Closing in favor of #1188


Original response in FinalHandler

Maybe it's a good thought to mark the original response as mandatory in https://github.com/zendframework/zend-stratigility/blob/develop/src/FinalHandler.php#L45? Otherwise, if an original response is null then in an invocation, even if some middleware had handled the request correctly, without errors, always will be created 404 error.

Also I guess the documentation for FinalHandler contains some mistakes
Internally, FinalHandler does the following on invocation:

    If $error is non-null, it creates an error response from the response provided at invocation, ensuring a 400 or 500 series response is returned.
    If the response at invocation matches the response provided at instantiation, it returns it without further changes. This is an indication that some middleware at some point in the execution chain called $next() with a new response instance.
    If the response at invocation does not match the response provided at instantiation, or if no response was provided at instantiation, it creates a 404 response, as the assumption is that no middleware was capable of handling the request.

For example, if the response at invocation matches the response provided at instantiation it doesn't mean that some middleware  in the execution chain called $next() with a new response instance. It mean that the response provided at instantiation is the same.

#46 adds a setOriginalResponse() method to the FinalHandler, allowing you to inject it after instantiation. I think that addresses one aspect of the issue you're reporting.
Could you provide some sample unit tests showing the behavior you expect, by any chance?

The FinalHandler was deprecated in 1.3.0, and will be removed in the upcoming 2.0.0, resolving this issue.


Parameterize image in makefile

It's currently hard-coded to quay.io/osb-starter-pack/servicebroker

Closing as was solved in https://github.com/pmorie/osb-starter-pack/pull/34 and https://github.com/pmorie/osb-starter-pack/pull/38


Controller container is bind to 8080 port

Version

Karpenter Version: v0.20.0

Kubernetes Version: v1.22.15-eks-fb459a0
Expected Behavior
upon modifying the containerPort for the controller container service able to run on the new port
spec:
  template:
    spec:
      containers:
        ports:
        - containerPort: 8088
          name: http-metrics
          protocol: TCP
        - containerPort: 8081
          name: http
          protocol: TCP
        - containerPort: 8443
          name: https-webhook
          protocol: TCP

Actual Behavior
instead of honoring the new containerPort service is binding to port 8080
panic: failed to setup manager: error listening on :8080: listen tcp :8080: bind: address already in use

goroutine 1 [running]:
github.com/samber/lo.must({0x233b3c0, 0xc0002fe700}, {0xc000a3f9e0, 0x1, 0x1})
	github.com/samber/lo@v1.36.0/errors.go:51 +0x1cd
github.com/samber/lo.Must[...]({0x0?, 0x0}, {0x233b3c0, 0xc0002fe700?}, {0xc000a3f9e0?, 0x1?, 0x274e2e0?})
	github.com/samber/lo@v1.36.0/errors.go:65 +0x45
github.com/aws/karpenter-core/pkg/operator.NewOperator()
	github.com/aws/karpenter-core@v0.0.2-0.20221205173459-064a52f2f9e1/pkg/operator/operator.go:127 +0x999
main.main()
	github.com/aws/karpenter/cmd/controller/main.go:34 +0x2e

Steps to Reproduce the Problem
Modify the karpenter deployment file , it can be any other port
spec:
  template:
    spec:
      containers:
        ports:
        - containerPort: 8088
          name: http-metrics
          protocol: TCP
        - containerPort: 8081
          name: http
          protocol: TCP
        - containerPort: 8443
          name: https-webhook
          protocol: TCP

Resource Specs and Logs
here is the log showing service trying to bind 8080 irrespective of the custom port which was passed in
Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

Sounds like you are expecting the kubernetes deployment configuration to automatically change the port that the application is starting up on? If I'm following, I think the current behavior is expected.
It looks like karpenter-core does have environment variable support for swapping the metrics port from 8080 to another port: https://github.com/aws/karpenter-core/blob/main/pkg/operator/options/options.go#L59
Maybe try setting the environment variable METRICS_PORT=8088 in addition to your changes to the deployment spec.

I was able to get around this with couple of changes, added the below things to helm chart values
controller:
  env:
  - name: METRICS_PORT
    value: "8088"
  - name: HEALTH_PROBE_PORT
    value: "8089"

and for the containerPort is mapped to these values using kustomize. can we have the imputs available for the chart similar to what we have for webhook.port?, so dont have to use the post-rendering of the chart

yeah @toscott found that setting with some help and was able to get it deployed. it would be much simple if the chart values accept something like
controller:
  metrics_port: 8080
  health_probe_port: 8080

and map these internally in the chart.


[5.5] Validation bypass for 'before' and 'after' rules when paired with 'date_format' rule.

When using the validation rules 'before' and/or 'after' together with the 'date_format' rule, it is possible to have what should be considered invalid data be accepted by the validator as valid.
My understanding from reading the code is that the 'before' and 'after' rules, when used without de 'date_format' rule, will compare two fields relative to each other. e.g. given the rules:
$rules = ['start' => 'before:finish', 'finish' => 'after:start'];

The 'start' field must have a date which is less than the 'finish' field, and the 'finish' field must have a date which is greater than the 'start' field.
But, when the 'date_format' rule is also used, you can compare a field to another field or a specific date. And therein lies the problem. If you know what date the field is being compared to (You can easily guess that through the error message) and all fields from the request is being passed directly to the validator as data to be validated (This is quite common, Laravel itself does that in the 'ValidatesRequests' trait[1]). You can then send an extra field in the request with the same name as that date and a value of your choosing. The validator will then give preference to compare the field being validate relative to the bogus field, which can have an arbitrary date. (the tests added illustrate this more clearly)
I honestly have no idea how to fix this without breaking backwards compatibility, so this pull request only adds tests that should pass but are now failing.
[1] https://github.com/laravel/framework/blob/e90a6bf785d740e88789700ad34e901238a45b16/src/Illuminate/Foundation/Validation/ValidatesRequests.php#L24

We don't merge broken tests. Please re-submit with fix.

@tillkruss - to be fair - the contribution documents explicity state he's done the right thing:

"Bug reports" may also be sent in the form of a pull request containing a failing test.

Maybe the docs just need to be reworded though because Taylor consistently says the same about not merging failing tests.

@devcircus I didn't expect this to be merged. It's just bug report with tests attached. Tests are a better way of reporting a bug than simple creating a new issue.

Sure but the common response to these PRs can be confusing. "We can't do anything with this" doesn't quite reflect the suggestion that this is a legitimate way to report bugs(though it may be true). So maybe the docs could be clarified as to how these cases should be handled.

Could we create an issue for this PR and create label for the issue like "development needed"?

@taylorotwell: Thoughts?

I think I've fixed it. Added another commit.


feat: support oidc auth

What type of PR is this?
/kind feature

What this PR does / why we need it
feat: support oidc auth.
Which issue(s) this PR fixes

Fixes # https://github.com/kubeagi/arcadia/issues/152
Special notes for your reviewer

@CodiumAI-Agent /review

PR Analysis

🎯 Main theme: Adding OpenID Connect (OIDC) authentication support to the GraphQL server.
📝 PR summary: This PR introduces OIDC authentication to the GraphQL server. It adds new dependencies, updates existing files, and adds new files to handle OIDC authentication. The PR also modifies the server to accept OIDC tokens and use them for authentication when interacting with Kubernetes.
📌 Type of PR: Enhancement
🧪 Relevant tests added: No

How to use

Tag me in a comment '@CodiumAI-Agent' and add one of the following commands:
/review [-i]: Request a review of your Pull Request. For an incremental review, which only considers changes since the last review, include the '-i' option.
/describe: Modify the PR title and description based on the contents of the PR.
/improve [--extended]: Suggest improvements to the code in the PR. Extended mode employs several calls, and provides a more thorough feedback.
/ask <QUESTION>: Pose a question about the PR.
/update_changelog: Update the changelog based on the PR's contents.

To edit any configuration parameter from configuration.toml, add --config_path=new_value
For example: /review --pr_reviewer.extra_instructions="focus on the file: ..."
To list the possible configuration parameters, use the /config command.

@CodiumAI-Agent /improve


[Bug][UI] Click Project Management / workflow relationship to report an error

Search before asking

[X] I had searched in the issues and found no similar issues.

What happened
Click Project Management / workflow relationship to report an error

What you expected to happen
Click normal
How to reproduce
Click Project Management / workflow relationship
Anything else
No response
Version
2.0.4
Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

I checked the functionality of this part in the latest code, but did not find this error, if I can't continue to provide some error information, I will close this issue.

The display is now normal


Trapezoid width is now fully controlled by width param

Should address https://github.com/gumyr/build123d/issues/380
zz = Trapezoid(10,10,70)
print(zz.bounding_box().size)

zz2 = Trapezoid(10,10,90)
print(zz2.bounding_box().size)

zz3 = Trapezoid(10,10,110)
print(zz3.bounding_box().size)

zz4 = Trapezoid(10,10,110,90)
print(zz4.bounding_box().size)

zz5 = Trapezoid(10,10,90,110)
print(zz5.bounding_box().size)

returns:
Vector: (10.0, 10.0, 0.0)
Vector: (10.0, 10.0, 0.0)
Vector: (10.0, 10.0, 0.0)
Vector: (10.0, 10.0, 0.0)
Vector: (10.0, 10.0, 0.0)

Now is the time to make breaking changes.  After we get to v1.0.0 we'll need to put more process into this to give folks a heads up.  Hopefully there aren't too many changes like this to come.


Getpodlogs kubeaction api

Which issue this PR addresses:
This to add an API in RP to get logs from any pod in the cluster.
ADO Card -
https://msazure.visualstudio.com/AzureRedHatOpenShift/_workitems/edit/12884832

/azp run ci

Looks like some style checks are failing -- @anshulvermapatel can you run make validate-go and make sure it's happy, then push up again?

/azp run e2e

/azp run ci

Ok last request, could you update docs with an example or any other useful info?
curl -k "https://localhost:8443/admin/subscriptions/$AZURE_SUBSCRIPTION_ID/resourceGroups/$RESOURCEGROUP/providers/Microsoft.RedHatOpenShift/openShiftClusters/$CLUSTER/kubernetespodlogs?api-version=admin&namespace=$NAMESPACE&name=$PODNAME&container=$CONTAINERNAME" --header "Content-Type: application/json"