Move runtime/linux/shim -> runtime/shim

There is no code change here (besides imports); just moving the package runtime/linux/shim to runtime/shim.  This is continuing on https://github.com/containerd/containerd/issues/2352.  It moves the shim from the linux specific package to allow for easier future shim integrations.

Codecov Report

Merging #2387 into master will decrease coverage by 4.23%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #2387      +/-   ##
==========================================
- Coverage   49.23%   44.99%   -4.24%
==========================================
  Files          84       92       +8
  Lines        7462     9398    +1936
==========================================
+ Hits         3674     4229     +555
- Misses       3108     4486    +1378
- Partials      680      683       +3

Flag
Coverage Δ

#linux
49.23% <ø> (ø)
:arrow_up:

#windows
41.26% <ø> (?)

Impacted Files
Coverage Δ

oci/spec.go
40% <0%> (-10%)
:arrow_down:

snapshots/native/native.go
43.89% <0%> (-10%)
:arrow_down:

metadata/snapshot.go
45.8% <0%> (-8.96%)
:arrow_down:

archive/compression/compression.go
43.93% <0%> (-8.9%)
:arrow_down:

content/local/writer.go
52.63% <0%> (-7.37%)
:arrow_down:

archive/tar.go
43.05% <0%> (-6.95%)
:arrow_down:

metadata/containers.go
47.97% <0%> (-6.62%)
:arrow_down:

metadata/images.go
58.46% <0%> (-4.7%)
:arrow_down:

metadata/buckets.go
56.33% <0%> (-4.6%)
:arrow_down:

content/local/store.go
51.56% <0%> (-4.29%)
:arrow_down:

... and 53 more

Continue to review full report at Codecov.

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

LGTM


codeowners: Add anaz and sebo as codeowner to zephyr/CMakeLists.txt

The toplevel CMakeLists.txt file is a core build system file akin to
the files in cmake/* and whoever is codeowner for cmake/* should also
be code owner for this file.
Signed-off-by: Sebastian Bøe<EMAIL_ADDRESS>

Codecov Report

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

@@           Coverage Diff           @@
##           master    #6059   +/-   ##
=======================================
  Coverage   52.63%   52.63%
=======================================
  Files         410      410
  Lines       40041    40041
  Branches     7779     7779
=======================================
  Hits        21074    21074
  Misses      15767    15767
  Partials     3200     3200

Continue to review full report at Codecov.

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


Add real-time histogram

This PR added a histogram which is repeatedly redrawn while workload runs on DUT.

I have just implemented a histogram which is redrawn throughout one iteration yet. As we discussed in the weekly mtg, I'm planning it redraws histogram only while workload runs on DUT. But I'm wondering which is better to separate data array (the one is PowerDataList, which contains all data for line graph and the other contains only the data during workload running for histogram) OR to keep the index of the data when "start"/"end" signal and slice PowerDataList every time when redrawing histogram.
I suppose the former method consumes memory but the latter makes codes complicated. Does anyone have advice or comment?


M46 Give markers new titles to describe crimes

This is pretty much the same thing as M45. We made progress towards figuring this out but haven't solved it yet.


add publish artifact task to pipeline for cpp console

Purpose

Add publish artifact task for cpp console

Does this introduce a breaking change?
[ ] Yes
[x] No
Pull Request Type
What kind of change does this Pull Request introduce?
[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Documentation content changes
[ ] Other... Please describe:

Looks good. Merge.


An unhelpful comment could be made helpful

this tools is not to replicate the full 'Developer Command Prompt'

Since this is the primary action that pops up when anyone wants to use msbuild for Visual Studio project builds, it's not exactly helpful to say "well, but don't use it". What should we use? Does Microsoft provide anything that sets up a normal VS developer prompt?
At the moment, the "publisher:microsoft" doesn't yield anything else Visual Studio related. I'm a bit confused, given that GitHub is now a Microsoft product, Visual Studio is a Microsoft product, Actions runners are offered by Microsoft, and so on. You'd hope it'd be a solved problem by now?

Hi @KubaO I'm keen on making this more clear, but I'm wanting to understand the confusion.  The Developer Command Prompt that gets installed with VS does MANY things setting up environment paths for: VSTest, MSBuild, VCVars, other C++ toolsets, etc.  It is not just MSBuild, and that was that comment trying to clarify that it does not fully replicate that batch file, but only serves to setup MSBuild tooling (most requested).  If all you were using in the dev prompt was MSBuild, then yes this is the action for you.  If you expect this action to also setup test/c++ tools it does NOT do that.

If all you were using in the dev prompt was MSBuild, then yes this is the action for you. If you expect this action to also setup test/c++ tools it does NOT do that.

Then perhaps you should provide examples of what CAN and what CAN'T be done with this action.
Example. I am a C++ developer who kinda has distaste for MsBuild itself, but has to build things on Windows in GHA from time to time. I tend to use cmake for project configuration, Ninja as underlying buildsystem, and VS 2019 as a compiler toolset. My local workflow is usually like this:
call C:\Dev\vs2019bt\VC\Auxiliary\Build\vcvarsall.bat x64
cmake -S src -B bld -G Ninja
cmake --build bld

When I go to GHA, I would like to see something like this:
- uses: microsoft/setup-msbuild@v1
  with:
    vs-version: '16.4'
# now I expect to have variables from vcvars.bat provided for all consecutive shells
- run: 'cmake -S src -B bld -G Ninja'
- run: 'cmake --build bld'

Alas, it does not work. And IIRC (as OP noted too), I cannot do this not only via setup-msbuild, but via any Action at all, having to resolve to something manual, like
- run: |
    call c:\secret\github\path\vs2019\VC\Auxiliary\Build\vcvarsall.bat x64
    cmake -S src -B bld -G Ninja
- run: |
    call c:\secret\github\path\vs2019\VC\Auxiliary\Build\vcvarsall.bat x64
    cmake --build bld

As a counter-example, you might provide actual snippets regarding how the Action should be used. From a top of my head:
- uses: microsoft/setup-msbuild@v1
  with:
    vs-version: '16.4'
- run: 'msbuild.exe src\SomeCSharpProject.vcxproj'
- ```

@Artalus I will add a simple case today. But this does not replicate vcvarsall.bat at all. I hope that is clear in the docs. It is single purpose to locate the msbuild.exe component and put it’s directory location in PATH and that is it. I would then allow subsequent steps in a workflow to just call msbuild <someproject> /p:SomeProperties etc. without having to specify the full location of the exe.  Your ending snippet is exactly that sample and the intent of the action to more simply enable.

this does not replicate vcvarsall.bat at all

I understood it the hard way, yes :smile:
In the aftermath, when you add up that "the action is named setup-msbuild" and that the description says "discover and assist with MSBuild and not other tools", it kinda seems obvious. But this Action is literally the first result when you google github actions visual studio - and the description starting with "how handy that 'Visual Studio Developer Command Prompt' is on your local machine? And how it adds several things to PATH" is sliiightly misleading. Seems that people tend to notice the first line of the description more than the notices afterwards.
Lack of real-life examples does not help either :slightly_smiling_face:


Notifications support for DispatchQueue instead of runloop

I'm using Realm Notifications as a means to observe on background queue the collection changes made on main thread.
Currently due to the fact that Realm delivers its notifications only to threads with runloop, I have to implement my own background thread that returns initialised RunLoop instance.
Please implement support for delivering Realm notifications on any DispatchQueue, not only to Thread with RunLoop.

Thanks for this feature request. We'll have someone review this and see what priority it would have. In the meantime, we're happy to review a PR if you want to expedite the process.


Stored procedure reporting multiple result-sets are not displayed in mssql-cli results

Create a database test1

Create  following stored proc
CREATE OR ALTER PROC sp_test_multiple_results
AS
BEGIN
SELECT TOP 10 name,object_id from sys.objects
SELECT TOP 10 name,object_id from sys.columns
END

run mssql-cli and execute this proc

Outcome:
Only first result set is displayed
mssql-cli

Expected:
All resultsets to be displayed to user and should be consistent with other tools like SSMS / sqlcmd
SSMS:

sqlcmd:

Will look into this


Wrong url for Snippets

At the end of your README where the language servers are, the Snippets points to https://github.com/neovim/nvim-lspconfig/wiki/Snippets-support but it have to be https://github.com/neovim/nvim-lspconfig/wiki/Snippets i think. The Snippets-support one is opening a 'Create new page' for snippets.

Thank you! I've fixed it.

Yep, you got it.
Just closed the issue.


Minor QoL change

I think for my 2nd suggestion it's already handled with type=str.upper in the argument's parameters?

Thanks!


Match launcher icon shadow parameters to shadow values in real icons

Currently the launcher icon shadow is a bit blurrier and less opaque than Google apps' launcher icons.

As per the UI terms, is this bug for "Elevation" or "Cast Shadow" or both?

This is specifically for the drop shadow on the entire shape, not the inner shape. So it affects all icons generated by the launcher icon tool. It's pretty subtle though, so not super high priority.

By "drop shadow on the entire shape", I think you mean that this subtle bug is for "Elevation". Thanks for the clarification.


Problem with BigDecimalWithNumericArgument cop

I have the following code in my app:
BigDecimal("1.0")

Latest rubocop autocorrects it to the following:
BigDecimal(1.0)

The problem is it does not work and I get error:
     ArgumentError:
       can't omit precision for a Float.

1.66.1 (using Parser <IP_ADDRESS>, rubocop-ast 1.32.3, running on ruby 3.3.5) [arm64-darwin23]
  - rubocop-factory_bot 2.26.1
  - rubocop-performance 1.22.0
  - rubocop-rails 2.26.1
  - rubocop-rake 0.6.0
  - rubocop-rspec 3.0.5

This issue has been fixed in RuboCop Performance 1.22.1. Thank you for the feedback!
https://github.com/rubocop/rubocop-performance/releases/tag/v1.22.1


📖 Streamline release categorization

Summary
This PR updates the policy docs and website behavior to eliminate the concept of a "stable" release and equate "latest" with the highest semver regular release.
If accepted, this PR will need to be followed up with corresponding PRs to the existing release branches so that their version warning banner will behave as intended.
Related issue(s)
This partly resolves #2019

Successfully tested with pushes to my fork.
BTW, did you know that if you disable the suppression of working on forks as follows, you get your own copy of the website? The one produced by my testing is at https://mikespreitzer.github.io/kcp-edge-mc . The versions main, release-0.25, and release-0.24 were produced in testing this. I produced release 0.24 after 9.25, in order to verify the ordering in mike list output. Here is how to disable the suppression of working on forks:
(venv) bash-3.2$ git diff release-policy-redux
diff --git a/.github/workflows/docs-gen-and-push.yml b/.github/workflows/docs-gen-and-push.yml
index aebecab87..586331f78 100644
--- a/.github/workflows/docs-gen-and-push.yml
+++ b/.github/workflows/docs-gen-and-push.yml
@@ -22,14 +22,14 @@ concurrency:

 jobs:
   generate-and-push:
-    if: github.repository_owner == 'kubestellar'
+    # if: github.repository_owner == 'kubestellar'
     name: Generate and push docs
     runs-on: ubuntu-latest
     steps:
       - uses<EMAIL_ADDRESS>-        with:
-          token: ${{ secrets.GH_ALL_PROJECT_TOKEN }}
-          persist-credentials: 'true'
+        # with:
+          # token: ${{ secrets.GH_ALL_PROJECT_TOKEN }}
+          # persist-credentials: 'true'

       - run: git fetch origin gh-pages

Putting this new policy into effect also requires one manual step: an authorized one of us has to mike set-default latest.

I have done the mike set-default latest.

/cc @clubanderson
/cc @ezrasilvera
/cc @pdettori
/cc @KPRoche

Thanks, looks good.
/lgtm
/approve


ci: detect Spam pull requests in GitHub Actions

This adds a GitHub Action that for the new contributors checks if the PR has a meaningful description and doesn't contain the default text. Otherwise, they are detected as spam and are closed.

This is remarkably petty but it's "rationale" not "rational".

Hey @aminya, thanks for the PR. We I have been discussing this in #5449 and the consensus is we don't want an action for this if we can avoid it. We are still working on a few more important things for the project and will loop back around in that issue when we are ready. I just don't want you wasting your own time in this until we decide if an action is the right way to go.

@ADTC I stand by my comment above. We have a few more important things we will be discussing in tomorrows TC meeting and after we sort that out we can start addressing these more directly.

How about restricting README PRs to core maintainers only?

I would suggest separating the script from the workflow and creating an action to make the code more maintainable. Something like this: https://github.com/animesh-chouhan/github-spamstop/blob/main/index.js
Also the  pull_request_template can be made more extensive if we are adopting it: https://github.com/animesh-chouhan/github-spamstop/blob/main/.github/pull_request_template.md

Closing as we've decided not go to go this direction, see https://github.com/expressjs/express/issues/5449#issuecomment-2020666952


0.3.0

This is my proposal for v0.3.0.
Breaking changes:

Removed the graceTime option from bind, useSubsribe and Subscribe
Subscribe: won't render children until after starting the subscription. I've put @voliva as a co-author of the commit because this was his idea and he also sent me a snippet with the code.

The rest of the changes are different kinds of perf-optimizations.
I'm really happy with this new API 😍 . Thanks a lot @voliva for your invaluable help on this.

Cool! I will merge this, but i will publish at least one pre-release before I publish v0.3.0, let's try to test the pre-release as much as we can in the next day or two.


makefile: build multi-arch image

Build multi-architecture image using buildah and qemu static utilities. Creates an image with manifest which refs amd64 (x86_64) and arm64 (aarch64) architecture-specific sub-images. Using the same Dockerfile regardless of the actual CPU architecture, and let buildah+qemu do all the low-level logic.
Note: typically, qemu would emulate arm64 on x86_64 which yields longer build time.

Also, could we leverage make's typical target based workflows rather than an embedded shell loop? Something like:
.PHONY: image-build-multiarch
image-build-multiarch:  image-build-arch-amd64 image-build-arch-arm64
     $(BUILDAH_CMD) manifest inspect $(IMG)

image-build-arch-%:  qemu-utils image-build-multiarch-manifest
	$(BUILDAH_CMD) bud \
			--manifest $(IMG) \
			--arch $* \
			--tag "$(IMG)-$*" \
			--build-arg=GIT_VERSION="$(GIT_VERSION)" \
			--build-arg=COMMIT_ID="$(COMMIT_ID)" \
			--build-arg=ARCH="$*" .

image-build-multiarch-manifest:
	$(BUILDAH_CMD) manifest create $(IMG)

.PHONY: image-push-multiarch
image-push-multiarch:
	$(BUILDAH_CMD) manifest push --all $(IMG) "docker://$(IMG)"

.PHONY: image-multiarch
image-multiarch: image-build-multiarch image-push-multiarch

(I left out .PHONYs on my added rule names just to be a tad shorter in a gh comment)

Looks pretty good so far, I am a bit curious why it uses buidah directly rather than docker/podman. Were there features of the process that are only supported by buildah?

docker uses the docker buildx to build multi-arch images; unfortunately, this is docker specific sub-command. I used BUILDAH_CMD instead of CONTAINER_CMD as I am not sure those rules will work in case CONTAINER_CMD=docker. But you have a valid point: using BUILDAH_CMD could be confusing more then useful. Hence, will fix.

Removed priority-review label because this is a draft.

I run an ARM-based Kubernetes cluster and would like to integrate the samba-operator. Is there a timeline for when this PR will be merged?

Hi @abachmann I was thinking about this topic recently after watching some devconf.us talks on youtube that were related to this subject. The issue isn't so much the samba-operator itself, as this codebase is golang and Go's got a pretty good cross compliation story. The real work needs to be done in the samba-container project we either need time or volunteers to help get us set up with multi-arch builds and manifest support for the latest and future release tags.
Folks who are not samba experts but know something about docker and/or podman and containers and (probably) github actions could help a lot here. I'm sure eventually one of us current maintainers at samba-containers will get around to it - especially if it becomes relevant to our downstream - but I would not be able to provide a timeline for that.


Add quotes around submake

This allows paths with spaces, and including -conf in the env var.

Anyone?  This is just a quoting issue.

Do any of the other parameters need to be quoted as well?

No idea, but this one does.

Auto-merge toggled on

Thanks!


Cannot add internal users

New Issue Checklist

[x] Updated fastlane to the latest version
[x] I read the Contribution Guidelines
[x] I read docs.fastlane.tools
[x] I searched for existing GitHub issues

Issue Description
I'm trying to figure out how to add internal testers via Fastlane (probably using pilot?). I've read a few threads on the matter and can see support of some kind was added in #9002.
I'm having no luck though. Let's ignore my Fastlane script and output consider that this is reproducible using command-line.
Ideally I would like to provide an email (not yet associated with the account) and add it as a brand new internal tester and then add the new user as a tester of the app, but I would settle for adding an internal tester (already associated with the account) to the app.
I'm using the following command:
pilot add -e<EMAIL_ADDRESS>-a com.potato.app --distribute_external false
Output (after the ITC login prompt)
[15:10:59]: You must provide 1 or more groups (with the `:groups` option)
/usr/local/lib/ruby/gems/2.3.0/gems/fastlane-2.83.0/fastlane_core/lib/fastlane_core/ui/interface.rb:133:in `user_error!': Some operations failed: You must provide 1 or more groups (with the `:groups` option) (FastlaneCore::Interface::FastlaneError)
	from /usr/local/lib/ruby/gems/2.3.0/gems/fastlane-2.83.0/fastlane_core/lib/fastlane_core/ui/ui.rb:16:in `method_missing'
	from /usr/local/lib/ruby/gems/2.3.0/gems/fastlane-2.83.0/pilot/lib/pilot/commands_generator.rb:44:in `handle_multiple'
	from /usr/local/lib/ruby/gems/2.3.0/gems/fastlane-2.83.0/pilot/lib/pilot/commands_generator.rb:101:in `block (2 levels) in run'
	from /usr/local/lib/ruby/gems/2.3.0/gems/commander-fastlane-4.4.6/lib/commander/command.rb:178:in `call'
	from /usr/local/lib/ruby/gems/2.3.0/gems/commander-fastlane-4.4.6/lib/commander/command.rb:153:in `run'
	from /usr/local/lib/ruby/gems/2.3.0/gems/commander-fastlane-4.4.6/lib/commander/runner.rb:476:in `run_active_command'
	from /usr/local/lib/ruby/gems/2.3.0/gems/commander-fastlane-4.4.6/lib/commander/runner.rb:69:in `run!'
	from /usr/local/lib/ruby/gems/2.3.0/gems/commander-fastlane-4.4.6/lib/commander/delegates.rb:15:in `run!'
	from /usr/local/lib/ruby/gems/2.3.0/gems/fastlane-2.83.0/pilot/lib/pilot/commands_generator.rb:166:in `run'
	from /usr/local/lib/ruby/gems/2.3.0/gems/fastlane-2.83.0/pilot/lib/pilot/commands_generator.rb:18:in `start'
	from /usr/local/lib/ruby/gems/2.3.0/gems/pilot-2.0.0/bin/pilot:13:in `<top (required)>'
	from /usr/local/bin/pilot:23:in `load'
	from /usr/local/bin/pilot:23:in `<main>'

Thank you for your suggestion Fastlane Bot lol
To all those that read this - I emphasize that I don't feel the Fastlane environment is necessary given the reproducibility of this from a single command.

I would still appreciate some input on this.
Basically I want to be able to add internal testers to a given app. Is that possible in the current version of Fastlane and, if not, is it a feature that could be added in a future release?


Enhance Error Messages in ModuleLinker

In #96, ModuleLiker is introduced. However, the error messages generated by ModuleLinker need to be improved for better clarity and usability. The current messages are often vague and make debugging difficult.
To improve the debugging experience, error messages generated by ModuleLinker for inconsistent declarations should provide more detailed information. Specifically:

Identify the Modules Involved: Clearly indicate which modules have conflicting declarations.
Describe the Inconsistency: Clearly explain the exact reason for the inconsistency (e.g., the linkage or the type definition is inconsistent).

Hi @Y-Nak
I came across this issue and would like to work on resolving it.  Could you please assign it to me?


updates to the readme

couldn't get the code in the README to work, I think these are the appropriate changes to fix things, but not 100% positive.

Thanks!  In the meantime, want to change the readme back to it re-casts before initializing the CausalEffect class?

will do. let me see if that change gets picked up for this pr or if i need to make a new one

I already merged, so I think you'll want to make a new one. otherwise, I
think you'll have to rebase.
On Tue, Nov 14, 2017 at 1:42 PM, josh attenberg<EMAIL_ADDRESS>wrote:

will do. let me see if that change gets picked up for this pr or if i need
to make a new one
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/akelleh/causality/pull/51#issuecomment-344356425, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABrkQDOTklkC2R7M8aL4vu4DKSyYzmMuks5s2d78gaJpZM4Qdup5
.

--
Adam Kelleher | BuzzFeed | Principal Data Scientist |<PHONE_NUMBER> | tw:
@akelleh | github: akelleh
111 East 18th St., NY, NY 10003
#1 Most Innovative Company In The World – Fast Company
http://www.fastcompany.com/3056057/most-innovative-companies/buzzfeed-for-shaking-up-media-across-the-globe


ember-cli-update to 3.0

The new test syntax doesn't work with Ember 1.13.  I'm willing to try to fix it, but at some point I would think it'd make sense to stop supporting 1.13 given its age at this point.

Thanks.


Radio buttons in overflow menu incorrectly aligned in Firefox

Adding radio buttons to an overflow menu in Firefox causes the buttons to be aligned horizontally instead of vertically.  This seems to happen both when the buttons are dynamically added or hard coded into the HTML file.  Adding a br tag after each element, as well as forcing a new display style doesn't fix the issue.  The radio buttons are aligned correctly in Chrome.

I'm seeing this too when viewing our website on Firefox..

Just checked the component on our site in Firefox and it seems to be working fine. Closing.


FInal translations for front end i18n

I was interested in potentially taking an a dependency on humanize-duration for duration formatting because it seems likely that this solution will have growing pains if we start supporting more languages, but I'm happy to use this for now :)
Also: I don't mind squashing these commits during the merge but it looks like the branch you're building changes off of and main may have diverged at some point which is probably what's causing my commits to show up in this PR too. Something to look into for the next one :)

I will re-branch from upstream/main for next time, which should fix it. I had been merging to keep that up to date, but that may have introduced that issue.
A i18n library for time formatting does make sense. I have used this one: https://date-fns.org/v2.2.1/docs/formatDistance before, which seems to have i18n. So that is another option if you are going to use date-fns anyway in general at some point.


Can not find in cocoapods

Why i cant find the lib in cocoapods by keyword "PNChartSwift"?

Because I haven’t push it to cocoa pods

On Mar 10, 2015, at 1:32 PM, kklldog<EMAIL_ADDRESS>wrote:
Why i cant find the lib in cocoapods by keyword "PNChartSwift"?
—
Reply to this email directly or view it on GitHub
.


Update test data from Generator 1.1.0 to 1.2.0. Includes all regressions...

....

I updated all files regardless if the test fails or not. We should track all failures in separate bug reports.

Ok, it is probably not as bad as the diff makes it look like. I looked over all failing tests.

We actually have 1-2 progressions.
Most of the failing tests actually don't fail but the original PSD file looked different in the past. The tests are now updated to reflect the existing test files.
3 tests are broken because the rectangles were replaced by paths. With Dmitry's fix for issue #136 this should be solved.
text-on-path is the only actually failing test and it fails badly. This is because the Generator JSON format changed. The value numbers were replaced by value objects with the actual number and a unit. Should be an easy fix. Sadly we shipped with the broken behavior.

Unfortunately we just didn't get to fix text on a path, it was known to be busted.  Glad you figured it out!

In the future I think we should probably lean on it.skip instead of recording borked media, but for now we know the 2 issues and have fixes for them that are going to land shortly... so I'm going to merge this expecting #136 and #137 to be fixed after which we can lean on the tests again.


Rpg mlibrary

Fixed hyphenation of database items linked by %{...|...} inclusions.
Fixed Rogue backstab to-hit adjustment.
Fixed Staff of Frost.
A number of database fixes.
Fixed case match error on SpellsPerLevel table.
Fixed doParse() case error
Fixed invalid overwrite of v1.5.03

Please can this new version of pull request #1852 go live ASAP - there are other releases that have gone out that are dependent upon it (#1853, #1854, #1855, & #1856) and the RPGMaster suite might have unintended consequences / crashes without this release. Thanks.

Hey @DameryDad, tying to merge results still is causing a lot of conflicts, mainly with StatusTracker.js

I can't get at the conflict list on GitHub! This makes it really difficult
to resolve them as I can only see code in my current branch.  All I see is
a message saying there is a conflict.
Is there any way I don't know about to get acces to the merge conflict
list?
On Wed, 8 Nov 2023, 15:34 Alice, @.***> wrote:

Hey @DameryDad https://github.com/DameryDad, tying to merge results
still is causing a lot of conflicts, mainly with StatusTracker.js
—
Reply to this email directly, view it on GitHub
https://github.com/Roll20/roll20-api-scripts/pull/1857#issuecomment-1802133595,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AR2BFVFEG7WW56JRDOSO36TYDOQ7ZAVCNFSM6AAAAAA7A7YTVSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBSGEZTGNJZGU
.
You are receiving this because you were mentioned.Message ID:
@.***>


Optimize the gain plugin example

I did some refactoring and optimization on the react side.
Because my purpose was a performance test mainly, this is not a thorough refactor.
I left some components with the older class component, which causes some inconsistency in the coding style.

rewrite some components with functional component using Hooks
extract knob components because the update of mute state causes irrelevant rerender of ParameterSlider.

As Nick's suggestion,  there was a performance issue where each ParameterSlider listens to the event and then setState.
So I did some optimizations with Context API (see e20d5b8), and did some tests with 50 knob copies.
As a result, knobs move more smoothly as we can see in the GIF.
But it didn't show up in the profiler: the CPU usage is always 100%.

knob-test-1

knob-test-2

For curious person, the test codes can be found at:
https://github.com/magnetica-studio/react-juce/tree/knob-test-1
https://github.com/magnetica-studio/react-juce/tree/knob-test-2
And the log file just in case. knob-test.trace.zip

@szk2s looks like some solid wins and practices to follow here. FYI I've also just patched a performance disaster when laying out canvas components:
https://github.com/nick-thompson/react-juce/pull/251
A minor thing I had missed. We tested whacking 10 sliders in the gain plugin example and then resizing the app window and performance fell off of a cliff. The above PR resolves. Combined with your PR we should see sizeable improvement.

💥 🚀
Sorry @szk2s for the delay, but yea @JoshMarler found a huge win in here earlier today. I've got your branch now rebased against his fix and I have 10 knobs rendering super smoothly with ~50% CPU during heavy drag, and 50 knobs rendering smoothly with ~85% CPU during heavy drag.
On my profiles it seems that the heavy lift comes during the dispatching of param values into javascript, which is good news because that means our canvas rendering is quite good ;). Now, to me this actually makes a fair bit of sense because I believe with the context provider at the root of the app, we're doing a lot of re-render in response to new values. See here: https://reactjs.org/docs/context.html#contextprovider

All consumers that are descendants of a Provider will re-render whenever the Provider’s value prop changes. The propagation from Provider to its descendant consumers (including .contextType and useContext) is not subject to the shouldComponentUpdate method, so the consumer is updated even when an ancestor component skips an update.

So I think with context we'll want to focus the provider's scope to only include the knob components, and then we'll want to get very particular with how the knobs handle a state update to avoid reconciliation as much as possible. I've got some ideas here, and will try to look into it some more tomorrow!

Thanks, @JoshMarler and @nick-thompson.
When the parameter change, I think reconciliation is triggered only once because the state change is only in the provider. But I don't know how to make sure it easily as it is hidden in the React inner implementation. Any ideas?

Ok, getting back to this today and, wow, we have some big wins to make here :)

When the parameter change, I think reconciliation is triggered only once because the state change is only in the provider. But I don't know how to make sure it easily as it is hidden in the React inner implementation. Any ideas?

Yes, you're totally right. So, by putting the context up at the top we do guarantee batching, which is helpful, but it comes at the cost of forcing a full-tree reconciliation, even skipping any shouldComponentUpdate operations. I could imagine this being a helpful pattern for some cases, but for something like a parameter which is changing so frequently, a full-tree reconciliation at that rate might be expensive.
I'm exploring an alternative pattern where, at the beginning of a parameter change, I set a value in the ParameterValueStore to say "this value is in a change gesture." All knobs which aim to render that parameter see the state update and mark their respective canvas child into animate={true} mode, which means that without any reactjs intervention, the knob canvases will get repainted at 45Hz. This is neat, because then I don't actually have to involve any react state or tree diffing in this frequent change loop. With this pattern, I've got 50 sliders rendering smoothly with 50% CPU during heavy drag, and hermes doesn't even show up in the profile ;) At that point the work that remains is optimizing exactly when and how we paint, and optimizing our juce paint internals.
Now, there's more here: the tree renders are actually way more expensive than we want them to be, and in part it's because we're doing some naive things in our view implementation. In particular, not throttling our repaints on setProperty calls. I have a change locally for marking a view dirty after a setProperty call instead of calling repaint(). Then during the commitUpdate phase we do a tree traversal and call repaint(area) for any dirty child. I think there's more to do here, but at least this means that we only paint a child once for each batch of property changes.
They're also expensive because we do things like run the react loop, batch our layout into the commit update phase, then dispatch measure events back into js where we then re-run the react loop because we're not yet using shouldComponentUpdate everywhere, and then repeat.
So, long story short, I think you've actually cracked open a great can of worms @szk2s and I very much appreciate it! Showing me we've got quite a bit of low hanging fruit here that I think can drastically (drastically!) improve our performance.
If you don't mind, I'm going to hold off on merging here a little bit longer because I'm not yet convinced that using Context is our best option. I want to dig a little deeper on it still while I pick off some of the unrelated low hanging fruit. Besides that, I quite like the way you've refactored much of this code so I do want to merge at least several parts of it.

Awesome! Adding animate=true sounds a big step to specialize React in audio development. In this field, dragging is much more used than in the web dev, and more performance is required.
Passing props from parent to child can be cumbersome when they are required by many components within an application. Context API only solves this problem. I think this gain example can be written without Context API to keep the state at the top and pass the data as props. This is not so cumbersome in this small example. Context API is powerful in general, but not a minimal solution in this case. I can add some further refactors on top of this PR if this plugin is to show the minimal solution instead of an opinionated solution that might be helpful for the library users.

Awesome! Adding animate=true sounds a big step to specialize React in audio development. In this field, dragging is much more used than in the web dev, and more performance is required.

Totally :) animate=true is actually already supported on <Canvas>, it's just not well-documented yet. (So much to do, so little time!)

Passing props from parent to child can be cumbersome when they are required by many components within an application. Context API only solves this problem. I think this gain example can be written without Context API to keep the state at the top and pass the data as props.

Yea, I agree 100%. I think the Context API is quite elegant for those scenarios too. The only reason I'm suspicious of it in this case is because during a parameter value change we'll post new param values into js at 30Hz (via the GenericEditor's event dispatching), and that means doing a full tree reconciliation at 30Hz during the drag gesture. I could imagine here using Context for values which change less frequently and then using a simple store strictly for the paramter value. I'm going to keep digging in here before drawing any conclusions though, I think we're uncovering a solid set of performance gains!

OK! So, I will wait for your conclusion. Let's hold merging this a little bit longer. 🙂

Ok, back with some more updates:

I think there are some internal optimizations to make, as I mentioned above, but I don't want to hold this PR up on that because I think clearly there are some wins in this PR that make sense to merge as soon as we can.
In my measurements it looks clear that using the Context API helps React batch the whole reconcile into one pass, and after adding some additional shouldComponentUpdate-style fixes to our internal Slider and Canvas I've got 50 sliders rendering smoothly with ~70-75% CPU.
I got maybe 5% CPU improvement by moving the <ParameterValueProvider> to surround just the knobs instead of the whole app, which prevented unnecessary reconciliation
Of that ~70-75% CPU I measure running javascript as ~50% of the work, and painting the juce components ~35%
If I change this instead to not use canvas, and to not pass parameter values as props, but rather set each slider canvas to animate and during onDraw fetch the latest value from the ParameterValueStore, I've got 50 sliders rendering smoothly with ~60-65% CPU, of which 82% is painting the juce components, and 2.8% is running javascript.
For me, this shows just how quickly running the react reconcile step can add up in terms of performance, which confirms my hesitation about Context for quickly-changing values.

So, what I'd like to do here is this: if you're both cool with it @szk2s @JoshMarler I'd like to go ahead and merge this to start, because as-is this does bring performance improvements to the gain example and I think the code here is just much nicer than what I had written :). Then I think we should follow up with some experimental PRs comparing alternative ways to squeeze out more performance improvements (I'll start by opening a PR showing my animate trick), while at the same time tackling some of the internal optimizations that we discovered here (in particular, optimizing our paint strategy and, if we can, our canvas paint procedures)
What do you think?

Super interesting @nick-thompson. This all sounds great. I wonder if the shift in the canvas draw commands approach had anything to do with push of work into JS https://github.com/nick-thompson/react-juce/commit/9103187dd3b0a91326aaae337ae064de84be2ad1. Definitely keen to look into optimising canvas. Would be happy to take a look into some of this.

OK, sounds cool.
If you move the <ParameterValueProvider> to surround just the knobs, I think you won't need Context API. useState should be enough.
It can be discussed in another PR. Go ahead!😄

If you move the  to surround just the knobs, I think you won't need Context API. useState should be enough.

Ah, of course :D I totally missed that.

This all sounds great. I wonder if the shift in the canvas draw commands approach had anything to do with push of work into JS 9103187. Definitely keen to look into optimising canvas. Would be happy to take a look into some of this.

It was actually pretty awesome to see– painting those 50 sliders at 30Hz barely cost anything in terms of javascript time. Assembling those draw commands arrays seems quite cheap. It's actually processing them and painting them on the juce side that gets expensive. Much to dig into there!
Ok awesome, let's go 🚀 . @szk2s do you mind if I squash this into 1 commit on the way in?

actually

Ah OK nice. I might profile the Canvas View tonight and see if I can pull out any cpp gems.

Ok awesome, let's go 🚀 . @szk2s do you mind if I squash this into 1 commit on the way in?

Sure! No problem.

Thank you @szk2s!


fix nix build

fixed the build via nix flakes

haven't actually tried using the libs so it'd be great if someone could try it

added a note to the readme about the submodules
minor other tweaks to flake and shell.nix etc

I was purposely building using the non zig-libxml2 in the flake. But perhaps its broken since I introduced that. The proper fix might be to change the build.zig to not require that exist (depending on the target).
I like your shell.nix/flake-compat changes here though, if you could pull those out I can merge those immediately.

Yeah it's this bit that forces it to look at vendor which is empty since flakes currently ignore git submodules: https://github.com/mitchellh/libflightplan/blob/main/build.zig#L3
If there's a way to make it use either that or normal libxml2 interchangeably that might be good. I'm not familiar enough with zig to know how to do that/if that's possible

I think there is, I'll look into that.

Okay, there is a way to make it interchangeable but its a nightmare so I ended up going your route, but I changed the implementation slightly. Thanks for pointing this out though. https://github.com/mitchellh/libflightplan/commit/475e59c25bba52f91222e11698f9d69e1f5b3448
I ended up using flake.lock as a way to track the revision we want. Then use an overlay to pass that in.
I'll bring in your out changes too. Thank you!


Reproducing COMBO

Hi,
I noticed that your logs and tables are missing the COMBO results. Were you able to reproduce the results in the paper?
Thank you very much for your helpful codebase,
Kaustubh

Thank you for your interest in our codebase! We are currently testing COMBO on the benchmark, and we will release the logs and reproduced results soon.

That sounds great. Please let me know if you need any help. I'd be glad to contribute manpower or even compute (run some hyper params).

We are pleased to inform you that we have added reproduced results of COMBO as well as suggested hyperparameters to our repository!


Calendar - add week numbers

Add showing week numbers and event for week numbers clicks.

4.2.31

[x] Calendar: add attribute data-show-week-number="true|false"
[x] Calendar: add attribute data-week-number-click="true|false"
[x] Calendar: add event data-on-week-number-click="..."

Dear olton,
please, can you add showWeekNumber to the CalendarPickerDefault Options and Transfer the showWeekNumber calendarPicker Option to the calendar-object (around line 6542 in the merged Version), so the calenderpicker can have week numbers to?
thanks and have a nice day
chriss


Collect reverse dependencies

This PR makes the following changes:

extends Shake to collect the reverse dependencies of every 'Result' by performing some bookkeeping on every evaluation. The amount of work done is O(E) on the number of edges in the graph and I have measured it to be around 3% for a very dense graph with 150.000 nodes and 1e8 edges, so it's not bad at all, and could be put behind a flag if desired. Note that in this PR the set of reverse dependencies is overestimated since ephemeral reverse edges are never deleted.

adds a new function shakeRunDatabaseFromKeys which extends shakeRunDatabase by accepting, in addition to a set of actions (the goals), a set D of keys that have changed since the last run.  The transitive closure of D is the set of all keys that have potentially changed since the last run - all keys that do not belong to this set are guaranteed unchanged and can be excluded from the buildRunDependenciesChanged query.

When the set D is small compared to the size of the build graph, this optimisation renders performance gains of one order of magnitude, up to ~70X~ 20X in some cases. I have extended[1] HLS to keep track of what has changed since the last full Shake run and performed several experiments:

Applied the ghcide benchmark suite to the standard Cabal-<IP_ADDRESS> example and obtained the results in the comments below.  The edit experiment runs in 55% of the time . Full results
Applied the ghcide benchmark suite to the standard lsp-1.0 example and obtained the results in the comments below.  The edit experiment runs in 73% of the time. Full results
Applied the ghcide benchmark suite to a very large example involving a module with >17.000 transitive dependencies and measured the performance of the edit benchmark, which runs in 4.75% of the time i.e. >21X faster.

[1] - https://github.com/pepeiborra/ide/tree/keysChanged
Closes #800
EDIT: updated performance numbers

Preliminary results using the standard ghcide benchmark suite are quite encouraging: in the edit benchmark it is approximately 35 times faster, and in the code actions after edit around 12 times faster. I am still reviewing the results. There are some test failures too, but none of note.

There is a tricky issue with async exceptions that I am struggling to solve.
To me, shakeRunDatabaseForKeys is an unsound approximation since it bypasses the version number checks. It is possible that a key K is not up to date and yet, because it doesn't belong to the dirty set, gets reused without updating.
In what cases can this happen? The most common one is when a previous call to shakeRunDatabaseForKeys marked K dirty, but the evaluation didn't touch K so it didn't get recomputed. If the call to shakeRunDatabaseForKeys isn't aware of this, and if the new dirty set doesn't include K but the evaluation uses it, the stale value will be reused.
To avoid this, I have added state to the database to track the dirty set across runs. A key is removed from the persisted dirty set as it is refreshed. The tricky bit with async exceptions is that a call to shakeRunDatabaseForKeys can get interrupted before it has a chance to add the keys to the dirty set.
I'm not sure how to solve this. The obvious solution is to mask, but it seems ugly and out of place in the Shake codebase. We could put the mask in the caller, by changing shakeRunDatabaseForKeys to return an IO (IO ()), but this probably requires some major changes in Shake.

There is a tricky issue with async exceptions that I am struggling to solve.
To me, shakeRunDatabaseForKeys is an unsound approximation since it bypasses the version number checks. It is possible that a key K is not up to date and yet, because it doesn't belong to the dirty set, gets reused without updating.
In what cases can this happen? The most common one is when a previous call to shakeRunDatabaseForKeys marked K dirty, but the evaluation didn't touch K so it didn't get recomputed. If the current call to shakeRunDatabaseForKeys isn't aware of this, and if the new dirty set doesn't include K but the evaluation uses it, the stale value will be reused.
To avoid this, I have added state to the database to track the dirty set across runs. A key is removed from the persisted dirty set as it is refreshed. The tricky bit with async exceptions is that a call to shakeRunDatabaseForKeys can get interrupted before it has a chance to add the keys to the dirty set.
I'm not sure how to solve this. The obvious solution is to mask, but it seems ugly and out of place in the Shake codebase. We could put the mask in the caller, by changing shakeRunDatabaseForKeys to return an IO (IO ()), but this probably requires some major changes in Shake. An alternative solution is to track the dirty set in the caller (ghcide) - the problem is that the caller doesn't know a) the transitive closure, and b) when to undirty elements. While we could expose shakeDatabase functions to compute the transitive closure and to inspect the keys that did evaluate in the last run, the end result will probably not be a nice, user friendly API.

I opted for masking in Shake. The masking minimal and happens in shakeRunDatabaseForKeys.

There is a tricky issue with async exceptions that I am struggling to solve.
To me, shakeRunDatabaseForKeys is an unsound approximation since it bypasses the version number checks. It is possible that a key K is not up to date and yet, because it doesn't belong to the dirty set, gets reused without updating.
In what cases can this happen? The most common one is when a previous call to shakeRunDatabaseForKeys marked K dirty, but the evaluation didn't touch K so it didn't get recomputed. If the current call to shakeRunDatabaseForKeys isn't aware of this, and if the new dirty set doesn't include K but the evaluation uses it, the stale value will be reused.
To avoid this, I have added state to the database to track the dirty set across runs. A key is removed from the persisted dirty set as it is refreshed. The tricky bit with async exceptions is that a call to shakeRunDatabaseForKeys can get interrupted before it has a chance to add the keys to the dirty set.
I'm not sure how to solve this. The obvious solution is to mask, but it seems ugly and out of place in the Shake codebase. We could put the mask in the caller, by changing shakeRunDatabaseForKeys to return an IO (IO ()), but this probably requires some major changes in Shake. An alternative solution is to track the dirty set in the caller (ghcide) - the problem is that the caller doesn't know a) the transitive closure, and b) when to undirty elements. While we could expose shakeDatabase functions to compute the transitive closure and to inspect the keys that did evaluate in the last run, the end result will probably not be a nice, user friendly API.

I opted for masking in Shake. The masking minimal and happens in shakeRunDatabaseForKeys.

I think this masking is not essential and can be removed, since the caller is always able to find out whether a rule was actually evaluated and use this information to keep an up-to-date state of the dirty keys on the caller side.

Closing this since the work has moved on to HLS-graph

Thanks for all the hard work doing this @pepeiborra  - it's very nice work. I think the end conclusion is that HLS-graph and Shake have diverged significantly enough that doing one for both isn't all that helpful. I shared some more thoughts about the size of build systems and where Shake fits in https://neilmitchell.blogspot.com/2021/09/reflecting-on-shake-build-system.html


prepare v1.0.0 release

@Darksonn How do I compile the changelog?

Read the list of commits backwards until the last preparation PR.


rename build artifacts from radar to cda

Renaming of directories/packages will follow in a later PR when active work isn't occurring.


Content-Length header is incorrect for some responses generated with .setBody()

We're seeing an issue with Perfect-HTTP 3.1.6 where the Content-Length header is set incorrectly for some limited amount of responses (generated using response.setBody() ). In each case the reported content length is larger by 8 (for an empty response Content-Length was 8, for an empty json "{}" the reported length was 10).
We use the following code for success and failure cases, unfortunately the issue is very sporadic, hard to reproduce but nonetheless worrisome and trips up the client parsing.
response.setBody(string: error).completed(status: .badRequest)
try response.setBody(json: responseData)
if let responseETag = responseETag {
    response.addHeader(.eTag, value: "\"\(responseETag)\"")
}
response.completed(status: toReponseStatus())

Example client parsing issue:
NetworkManager.swift:141 WARNING: > Server Request Error: Response could not be serialized, input data was nil or zero length.
NetworkManager.swift:142 WARNING: > Request: GET (redacted)
NetworkManager.swift:143 WARNING: > Headers:
NetworkManager.swift:147 WARNING: > Body:
NetworkManager.swift:148 WARNING: > Response: 200
NetworkManager.swift:149 WARNING: > Headers:
NetworkManager.swift:151 WARNING: >   Date: (redacted)
NetworkManager.swift:151 WARNING: >   Server: (redacted)
NetworkManager.swift:151 WARNING: >   Content-Encoding: deflate
NetworkManager.swift:151 WARNING: >   x-request-id: (redacted)
NetworkManager.swift:151 WARNING: >   Content-Length: 8
NetworkManager.swift:153 WARNING: > Body: (empty)
NetworkManager.swift:688 WARNING: Request failed: responseSerializationFailed(reason: Alamofire.AFError.ResponseSerializationFailureReason.inputDataNilOrZeroLength)

I appreciate the response. I wonder if you guys have a stress testing code that could be used to tease this out? Unfortunately the issue is very sporadic on our side so it's hard to reproduce/confirm.
Here are the snippets of code that we use on the server, based on one of the past revisions of https://perfect.org/docs/
allRoutes.forEach {
    routes.add(method: $0.method, uri: $0.uri, handler: $0.getHandler())
}
routes.add(routes)

let compressFilter = try PerfectHTTPServer.HTTPFilter.contentCompression(data: [:])
httpServer.setRequestFilters([(httplogger, .high)])
httpServer.setResponseFilters([(httplogger, .low), (compressFilter, .high)])

Thanks!

The compressor running for empty and very small response bodies is problematic. I have corrected this in HTTPServer 3.0.19 (just now). I'm not sure if this is the cause of your problem, but it may help make things clearer. 8 bytes is the proper length for a "compressed" empty body, but you should no longer see that if you update the package.
Please let me know if you see any change after updating.


Add task management APIs

We store ML tasks for async requests. User should be able to manage task documents in index.

[x] Get task
[x] Delete task
[x] Search task

https://github.com/opensearch-project/ml-commons/pull/146
https://github.com/opensearch-project/ml-commons/pull/149


✨[feature Request]: Sign Up & Login Pages Similar to Each other

Is there an existing issue for this?

[X] I have searched the existing issues

Feature Description

As, both the Sign Up Page &  Login page doesn't align well with each other, due to different designs.
Use Case
I can make them look similar and well, that fits with the website.
Benefits
No response
Add ScreenShots
No response
Priority
High
Record

[X] I have read the Contributing Guidelines
[X] I'm a GSSOC'24EXTD contributor
[X] I have starred the repository

@RohanShrivastava08 make it similar.


ddl2cpp doesnt work if multiple index keys are in the dump.

The script will ommit table from the final result if multiple keys are specified in the ddl like this:
....   'ModifiedByName' varchar(60) DEFAULT NULL,   'ModifiedById' varchar(128) DEFAULT NULL,   'Note' varchar(1000) DEFAULT NULL,   UNIQUE KEY 'Id' ('Id'),   KEY 'IX_UserLogin_email' ('Email'(109)),   KEY 'IX_UserLogin_Name' ('FirstName'(55),'LastName'(55)) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
It also breaks if commas are on the last row/key/definition in the create table parentheses block
A work around is to generate your dump file with this command
mysqldump -d -u $(SQLUSER) -h $(DBHOST) $(DBNAME) | sed -e "/^\s\sKEY/d" | sed -e 's/)\,/)/g' > tmp/dump.ddl

Thanks for the report!
Would you like to try adjusting the script? Your pull request would probably be faster than me right now :-)

Sorry i dont know python. Its no rush, the command above solves the problem

OK, will look into it later (tagged it as "help wanted", hoping for somebody to jump in and do a pull request :-) )

I added "More test cases for DDL files" onto the wish list I am compiling.


added default app ordering

CARD-4680
https://peachworks.leankit.com/Boards/View/267929177/485724855

@darushka please merge

Merged https://github.com/peachworks/ngPeachBootstrap/commit/2e2ab79359742387d3e7a6f24c2465c01c655b66

v1.0.15


bump num-complex and rand

Fixes #32.
No changes needed for the num-complex bump. New rand (used only in test) needs the format of an array changing. I hope there are no objections to my chosen seed.

This also removes the dependency on rustc-serialize allowing this library to be used with the wasm32-unknown-unknown target.

I’m mainly nervous about semver. Is it a breaking change to upgrade a major
version of a public dependency?
I didn’t realize this was a blocker for compiling on wasm, thats definitely
a solid motivation for fixing this
On Fri, Dec 14, 2018 at 8:44 PM Martin Charles<EMAIL_ADDRESS>wrote:

This also removes the dependency on rustc-serialize allowing this library
to be used with the wasm32-unknown-unknown target.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/awelkie/RustFFT/pull/38#issuecomment-447537120, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABGmekjeESJBaJobhQU5qxlLzEjVdhHNks5u5H4ugaJpZM4XAeWo
.

The breaking changes are outlined here. I'd bump the version to be safe. https://github.com/rust-num/num-complex/blob/master/RELEASES.md#breaking-changes

My 2c is that the num people seem to know what they're doing, so if they've bumped, it's probably for a good reason. :)

Done. I was tempted to upgrade rand all the way to 0.6, but my git says it's better to leave it at the same version num-complex uses, so that we have fewer versions of the same crate floating around


Issue/101

@Gerrrr why is python failing again :(((((

Current coverage is 100% (diff: 100%)

Merging #125 into master will not change coverage

@@           master   #125   diff @@
====================================
  Files          25     25
  Lines         470    470
  Methods       445    445
  Messages        0      0
  Branches       25     25
====================================
  Hits          470    470
  Misses          0      0
  Partials        0      0

Powered by Codecov. Last update 9110b86...af6455d


ARROW-17845: [CI][Conan] Re-enable Flight in Conan CI check

@github-actions crossbow submit conan-maximum

cc @kou


Send event data and user traits

Updating the analytics.js-integration-adroll identify method to use window.__adroll.identify which can also receive user attributes.

Calling the window.__adroll.track method on existing events: track (arbitrary events), productViewed, productAdded, orderCompleted to track raw event data.

Hi @eagarcia-adroll, as part of the monorepo migration, this issue has been moved to new issue. Our engineers have been notified and will prioritize and work on it ASAP. Thank you!
For more information, see README.md.


Support lowercase and extra whitespace in search

It's ~mildly~ annoying to have to properly type out items

Thanks, glad someone else is finding the script useful!


Importing named component does not have name in render

Current behavior
If I use a default exported component I can see and select it by name in both shallow rendered and mounted tests.
Default import Header in the App.js
import React, { Component } from 'react';
import Header from './components/Header';

class App extends Component {
  render() {
    return (

    );
  }
}

export default App;

components/Header.js with default export
import React from 'react';

const Header = () => (
Test
)

export default Header // I have default export here

App.test.js
import React from 'react';
import { shallow } from 'enzyme';
import App from './App';

it('renders without crashing', () => {
  const wrapper = shallow(<App />);

  console.log(wrapper.debug())
});

Test output
 PASS  src/App.test.js
  ✓ renders without crashing (1ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        0.536s, estimated 1s
Ran all test suites.

  console.log src/App.test.js:8

But if I use named export on the same component, the shallow render and mount just shows it as <Component /> instead of showing their name.
components/Header.js with named export
import React from 'react';

export const Header = () => (
Test
)  // I have named export here

Named import in App.js
import React, { Component } from 'react';
import { Header } from './components/Header';

class App extends Component {
  render() {
    return (

    );
  }
}

export default App;

Test output:
 PASS  src/App.test.js
  ✓ renders without crashing (1ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        0.547s, estimated 1s
Ran all test suites.

  console.log src/App.test.js:8

      <Component />

Expected behavior
I would see the name of the component for named exported components too. So in both cases the output should show:

Your environment
API

[x] shallow
[x] mount
[ ] render

Version

library
version

Enzyme
3.3.0

React
16.2.0

Adapter

[x] enzyme-adapter-react-16

This is because arrow functions don’t have names, so you’re relying on name inference. Use normal named functions for SFCs and you won’t have any name problems.

@ljharb Anonymous function name inference is part of the specs so that should work.
On the other note, perhaps this could be caused by transpilers - how they handle modules.
For example, depending on the TS config, this:
export const Foo = () => {};

could be transpiled into
"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
exports.Foo = () => { };

and Foo would loose it's name. 🤷♂
While babel would handle that correctly and preserve the name:
"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
exports.Foo = void 0;
var Foo = function Foo() {};
exports.Foo = Foo;

The point is that it’s unintuitive and not exhaustive when inference will happen; I’m quite aware it’s in the spec.

Use displayName attribute
I came across an interesting alternative to writing functions. Its possible to assign a display name attribute to your components like so.
const MyComp = () =>
my comp

MyComp.displayName = 'MyComp';
export { MyComp };

When running jest now you will get the display name.

Indeed. The better alternative, rather than using displayName to hack around having an unnamed function, is to use a normal named function.

@ljharb I didn't realise it was a hacky solution. The project I'm working on has strict rules for declaring components. Cheers for the info.
 They have taught me so much.
Thanks!!

@joeLloyd
const MyComp = () =>
my comp

MyComp.displayName = 'MyComp';
export { MyComp };

Would work even without disaplyName, as you declare the function prior exporting it would have correctly inferred name.

@grundmanise cheers for the tip. didn't realise that would would also work.


Implement texture border for polygon packing

Sprite border is not implemented, it is more difficult to implement.

I'm not entirely sure, but it seems to work correctly, but haven't tested in cocos.

I checked the code and you're right. You can't see that mistake in the preview as there the polygon is moved according to the spriteframe frames position.

I think it would be enough to add the texture border as a offset to the vertices.


Return a rejected promise instead of false on invalid model save

From the discussion in #2345, returning false from a failed save prevents a clean chaining API (model.save().done(...).fail(...)). Using deferreds, we can reject a promise instead to avoid the discrepancy.
This pull doesn't introduce any new options vars (i.e. isValid), instead suggesting a separate event listener for the model's invalid event or querying model.isValid() directly within the failed handler. The invalid event will always be fired before the deferred is rejected and returned. The fail handler is fired for both failed validation as well as any ajax errors which makes it difficult to mutate the options object or keep the two callbacks' arguments consistent.

I still think that this PR is independent of #3582
The only thing that we should agree that
save and destroy should return thenables.
Thus if we combine this PR and #3582 it will look like:

Backbone.newDestroyed = function(model) {
    return Backbone.Deferred().resolve(model);
}

Backbone.notValidated = function(model) {
    return Backbone.Deferred().reject(model.validationError);
}

There also a question, should the obtained xhr be also wrapped into Backbone.Defered().resolve(xhr)? To unify all thenables?

I see this as solving the root problem brought up by #3582. Additionally, it only adds one method onto the Backbone namespace, and it's a well-defined class (deferreds are easy to create from Promise libraries).

There also a question: should the obtained xhr be also wrapped into Backbone.Defered().resolve(xhr)? To unify all thenables?

So that all thenable return values are the same class, yes we should. Imagine overriding Backbone.Deferred to use native promises:
Backbone.Deferred = function() {
    var deferred = {};
    deferred.promise = new Promise(function(resolve, reject) {
        deferred.resolve = resolve;
        deferred.reject = reject;
    });
    return deferred;
};

I'd hate for some return values to be jQuery promises and some to be native promises.

As a side note, I don't think we should return deferred.resolve(). #resolve and #reject return a non-standard value (the deferred, vs undefined), and that the deferred object has #then is non-standard.

So why Deferred? Why not Backbone.Promise?
And use pretty sandard Backbone.Promise.resolve(value) and Backbone.Promise.reject(reason)
?
There is widespread belief that you should avoid using deferreds at all.

So why Deferred? Why not Backbone.Promise?

Because jQuery provides a Deferred class, so we don't have to write a ton of extra code.

There is widespread belief that you should avoid using deferreds at all.

Hm?

Opening for more discussion ... but we'd still need a real patch+proposal.

I would strongly advocate for the Backbone.Promise that should provide only two static methods resolve and reject
declare module Backbone {
    ...
    export interface Thenable<T> {
        then<U>(
             fulfilled: (result: T) => U | Thenable<U>,
             rejected: (reason: any) => U | Thenable<U>
        ): Thenable<U>
    }
    ...
    export class Model<TSync> {
          save(...): Thenable<TSync>
          fetch(...): Thenable<TSync>
          destroy(...): Thenable<TSync>
          sync(...): Thenable<TSync>
    }

    export class Collection<TModel extends Model, TSync> {
          fetch(...): Thenable<TSync>
          sync(...): Thenable<TSync>
    }

    export function sync<TModel, TOpts, TSync>(
          method: string,
          model: TModel,
          options: TOpts
     ): Thenable<TSync>

    export class Promise {
         // lets rely only on those two static methods:
         static resolve<T>(value: T: Thenable<T>): Thenable<T>;
         static reject<T>(reason: any): Thenable<T>;
    }
}

Inside you can use promises created by jQuery.Deferred by default or the same jqXHR
but Backbone itself should rely only on two standard static methods that are place under Backbone.Promise:  resolve and reject.
My motivation:

Those who never want to override methods will get the same jqXHR and JQueryPromises by the default implementation. Note that we do not need to implement promises in Backbone, we will reuse jQuery Deferred.promise() or similar things
Those who wnat to override this, probably want to use Promises/A+ implementation and would be able to do it with single:
Backbone.Promise = MyFavoritePromiseClass

I agree fully with @Artazor here (and thanks for the detailed interface). Do you propose we wrap sync (or ajax) in Backbone.Promise or should the implementing user's ajax method be required to return a thenable?
It'd be awesome to see a pull with this implementation if you have time.


[v2] Relative links on MD files doesn't work as expected

🐛 Bug Report
On v1 it works just fine.
When using the relative links it will work only when there is no / at the end of the URL. That means you will be fine if you navigate in the sidebar menu and open a relative link, however, if you share a link with someone, the browser (using Google Chrome) will add a / at the end of the URL and for this reason, relative links will not open anymore.
Version 2.0.0.alpha43
(Write your answer here.)
To Reproduce
(Write your steps here:)

Create a doc_test.md with a relative link to doc_test_2.md on the same folder.
Open your docusarus website and open the new doc (doc_test) from the sidebar menu
Access the relative link. It will work. The URL will be localhost:3000/doc_test_2
Now, go back, copy and paste the link for the doc_test and open it in a new tab
The page now will have a / and the end for the URL
Try to open again the link to doc_test_2 page
It will return not found. The URL will be localhost:3000/doc_test/doc_test_2

Expected behavior
On v2, if you have a relative link for another MD file in the same folder, we expected that using [link](./anotherFile.md) will open the file/page.
Actual Behavior
The relative links don't work if you are not navigating through the sidebar menu. If you share a link with someone, the relative link will brake.
Reproducible Demo
https://iqmetrix.github.io/hub.docs/docs/guides/configuring-the-sidebar/
If you go to the second paragraph, there is a link in the Have a configured Hub v2 development environment.. Check if you have the / at the end. If you have, the link will not work. Then, navigate back to the Configuring the Sidebar using the sidebar menu (you will see that there is no / anymore in the url) and try to click again the relative link, This time it will work.

I did a temp fix for this issue, but I would love to see what the docusaurus team has to say about this bug.
useEffect(() => {
    if (window && typeof window !== "undefined") {
      const allLinks = document.querySelectorAll("main .markdown a");
      const pathName = window.location.pathname;
      const page = pathName.substr(pathName.slice(0, -1).lastIndexOf('/'))

      if (pathName.substr(-1) === "/") {
        allLinks.forEach(a => (a.href = a.href.replace(page, "/")));
      }
    }
  }, [path]);

@prma85 hmm, I can not reproduce this bug, could you give access to your repo docs to try to check on it?

I've encountered a similar bug before, but in the end the reason was misuse of the path within the Markdown file and not using the right syntax. For the links to work, a file name (along with the extension) has to be used. If you do something like docs, Docusaurus doesn't treat it as a Docusaurus file and doesn't process it. The end result is it becomes a relative link and defaults to the browser behavior.
Are you sure you using the correct syntax here? If you can't share the repo at least share the relevant snippet of Markdown file for us to have a look.

I am sharing here the md file and folder structure
So, I have
\-docs-\
\----- guides-\
\------------- configuring-the-sidebar.md
\------------- configuring-environments.md
\------------- v1 \
\------ design -\
...

this is the content of the configuring-the-sidebar.md
---
id: configuring-the-sidebar
title: Configuring the Sidebar and Settings App
---

The sidebar of the Hub shell is configured using the `applications.json` file.

## Prerequisites

Have a configured [Hub v2 development environment](./configuring-environments.md#hub-v2).

So, the link should redirect to https://iqmetrix.github.io/hub.docs/docs/guides/configuring-environments#hub-v2, and it works when there is no / at the end of the url (if you use the navigation from the sidebar since it doesn't add the / at the end). However, if there is the / at the end (if you click in a shared link), it will navigate to https://iqmetrix.github.io/hub.docs/docs/guides/configuring-the-sidebar/configuring-environments#hub-v2 (will considerer the configuring-the-sidebar page as a folder.

@prma85 Unfortunately, I was not able to reproduce this bug. Can you create a reproducible repo?

Actually, looks like the original file has [Hub v2 development environment](./configuring-environments#hub-v2). and it was changed recently to [Hub v2 development environment](./configuring-environments.md#hub-v2). I don't see the error anymore for this page.
@yangshun you were right, the issue was because the link didn't have the .md at the end since it wasn't needed on v1 (the links on v1 always worked with these docs).
Thanks for your time :)


Bug in setup.py file

A recent update to setuptools breaks our current way of specifying the license as a list -- it must be a string. Fix requires changing the setup.py file to change the license kwarg to setuptools.setup to be license='MIT'.

Fixed in #189, closing.


fix: handle image references with both a tag and digest present

Fixes #749
Description

It is possible for image references to contain both a tag and a digest at the same time. Previously, this was not handled causing the validators to fail.
I'm not sure if what I did is the most idiomatic or even elegant Python, but the changes are at least fairly small.
I've built and pushed the image as ghcr.io/chgl/connaisseur:fix-image-tag-and-digest and testet it using the helm chart by setting
deployment:
  image: ghcr.io/chgl/connaisseur:fix-image-tag-and-digest

The images that were previously causing issues were now correctly validated and accepted.
Checklist

[x] PR is rebased to/aimed at branch develop
[x] PR follows Contributing Guide
[x] Added tests (if necessary)
[ ] Extended README/Documentation (if necessary)
[ ] Adjusted versions of image and Helm chart in values.yaml and Chart.yaml (if necessary)

Draft as long as there is no consensus on whether or not this is actually the right approach in https://github.com/sse-secure-systems/connaisseur/issues/749

@richgerrard with this the tag is preserved and should be visible in the k8s pod description. additionally, what might be possible to do is add the tag and digest as annotations to the mutated resource. that might be more convenient to get information about the resource, without the need to do additional parsing. is that something you deem as useful?

Codecov Report
Base: 96.90% // Head: 96.94% // Increases project coverage by +0.04% :tada:

Coverage data is based on head (5ed6c9b) compared to base (00b6d2a).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files
@@             Coverage Diff             @@
##           develop     #763      +/-   ##
===========================================
+ Coverage    96.90%   96.94%   +0.04%
===========================================
  Files           22       22
  Lines         1226     1244      +18
===========================================
+ Hits          1188     1206      +18
  Misses          38       38

Impacted Files
Coverage Δ

connaisseur/flask_application.py
93.75% <100.00%> (ø)

connaisseur/image.py
100.00% <100.00%> (ø)

...naisseur/validators/notaryv1/notaryv1_validator.py
98.36% <100.00%> (+0.04%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Update module for Exchange 2019 RTM

Pull Request (PR) description
Update module for Exchange 2019 RTM
Task list

[x] Added an entry under the Unreleased section of the change log in the CHANGELOG.md.
Entry should say what was changed, and how that affects users (if applicable).
[x] Resource documentation added/updated in README.md.
[ ] Resource parameter descriptions added/updated in README.md, schema.mof
and comment-based help.
[ ] Comment-based help added/updated.
[ ] Localization strings added/updated in all localization files as appropriate.
[ ] Examples appropriately added/updated.
[ ] Unit tests added/updated. See DSC Resource Testing Guidelines.
[ ] Integration tests added/updated (where possible). See DSC Resource Testing Guidelines.
[ ] New/changed code adheres to DSC Resource Style Guidelines and Best Practices.

This change is

Codecov Report

Merging #341 into dev will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##              dev     #341   +/-   ##
=======================================
  Coverage   32.22%   32.22%
=======================================
  Files          39       39
  Lines        4642     4642
=======================================
  Hits         1496     1496
  Misses       3146     3146

Continue to review full report at Codecov.

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


Missing panels in generated report for large dashboard

Hi,
When generating reports for dashboard with multiple panels (more than 20), some panels are not included in report.
It shows blank space for the missing panels.
We're not excluding any panels from report link (/api/plugins/mahendrapaipuri-dashboardreporter-app/resources/report?dashUid=UID of dashboard). Also no error is seen on grafana logs.
Grafana Version: 11.3.0
Plugin Version: 1.7.0

Could you please share the logs? The panels are rendered using grafana-image-renderer and I assume it is returning empty PNGs.

Attached logs: pdf-reporting.log.
And always the same panels are missed in the report.

Thanks for the logs.
Could you tell me the IDs of the panels that are missing in the report? Are missing panels in a collapsed row? If so, you need to use dashboardMode=full in query parameters or plugin settings in the UI to render those panels

Missed panel is not in part of collapsed row.
Panel ID 44 is missed, same panel is still missed when using dashboardMode=full.

Is is possible to share your dashboard JSON model after removing any sensitive info you have? If not can you try with nightly version?
Cheers

I tried to generated report for the test dashboard, with dashboardMode=full and nightly version, but still panels with id 6 and 18 are missing from report.
I've similar setup as docker-compose.

Whcih OS are you using? And how did you install chromium? Could you try using chromium in a container?

I'm running on Ubuntu 22.04, and running chromium, grafana, grafana-image-renderer as docker container as suggested in docker-compose.yaml.

@soursing I pushed a fix to the main. Could you please re-install nightly release and see if it fixes on your dashboard? Cheers

Thanks a lot for checking and providing a fix. However I agree with the comment that this fix could be improved.
Instead of hardcoding the view height to a large number, it would be better to find a proper fix so it can load the panels even if height of dashboard is larger than the hardcoded value.

Thanks a lot for testing @soursing
The issue is that we need to first get the total window height when all panels are expanded and use that to set view port height to get the panel data. Basically that translates to executing the same JS twice with and without view port set.
Anyways I find it is strange having to set view port height to fetch entire dashboard. It all started with Grafana v11.3 where dashboards are lazily loaded. I need to look into their frontend code to understand what is happening.
For the instant, I will make a hotfix release and I will look more into it bit later.


Add r7iz instances to limits.go

I would like to see the r7iz instance type added to limits.go
This would allow us to use the new instances in our cluster, which uses of security groups for pods.

Closing as fixed by https://github.com/aws/amazon-vpc-resource-controller-k8s/pull/316


[CSL-909] Refactor: move Tx-related utilities out of WALLET_MODE

We used to have MonadBalances, MonadTxHistory, sendTx, etc. only available in WALLET_MODE, even though they didn't depend on wallet and they were useful outside of WALLET_MODE (e.g. for the smartgen). This PR moves them from Pos.Wallet.WalletMode into the following modules (better name suggestions are welcome):

Pos.Balances         – MonadBalances
Pos.TxHistory        – MonadTxHistory
Pos.Util.Tx          – transaction construction (e.g. makePubKeyTx)
Pos.Communication.Tx – TxMode and transaction sending (e.g. submitTx)

This lets us
a) build the smartgen without WALLET_MODE
b) compile ~40 modules less on deployment
c) avoid having linker errors (because otherwise wallet-related modules are compiled even without the wallet)

Pos.TxHistory and Pos.MonadBalances is very bad. Pos.Txp.TxHistory and Pos.Txp.MonadBalances is better, but I still don't like it.
Personally I want client logic to be separated from node's logic. I think it's a different layer on which node itself shouldn't depend. Currently we are doing some refactorings to add more self-contained parts. I think client logic is a good separate part.
What do you think about the following approaches?
• Put all client logic which we want to have in cardano-sl library into Pos.Client.* (e. g. Pos.Client.Txp.MonadBalances, etc.).
• Put client logic of component X into Pos.X.Client (e. g. Pos.Txp.Client.MonadBalances).
Regarding Pos.Util.Tx: I think it's a wrong approach. We had a conversion with Misha long ago and decided that if there is a component X and activity Y (in our case X = Txp and Y = Util), then:
• if X is small, we should have Pos.Y.X;
• otherwise we should have Pos.X.Y.
Txp is definitely big component. Hence it should be at least Pos.Txp.Util I think. Or better (imo) Pos.Client.Txp.Util.

@gromakovsky

Txp is definitely big component. Hence it should be at least Pos.Txp.Util I think. Or better (imo) Pos.Client.Txp.Util.

Okay, I will change it.

Put all client logic which we want to have in cardano-sl library into Pos.Client.* (e. g. Pos.Client.Txp.MonadBalances, etc.).

I like this approach more than the Pos.Txp.Client one. Should I go with it now, or would it be better to leave it for some future refactoring?

I like this approach more than the Pos.Txp.Client one. Should I go with it now, or would it be better to leave it for some future refactoring?

Yes, I like Pos.Client.X more than Pos.X.Client too.
I think moving few modules related to this PR should take about 10 minutes. If I am right, do it now, otherwise it's fine to leave it for another refactoring.


[BEAM-7933] Add job server request timeout (default to 60 seconds)

Add a new option --job_server_timeout that default to 60 seconds. The request timeout is user for all job server requests (with exception to the ones that are expected to last long or hang). The request timeout is also used upon channel creation so that the Beam driver will fail if the job server is not available.
Let me know if the option name looks fine or it needs renaming. Finally, there are other grpc requests (non job service) that I'm not covering as part of this pr. Let me know if I should add the timeout to those as well.

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Choose reviewer(s) and mention them in a comment (R: @username).
[x] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[x] If this contribution is large, please file an Apache Individual Contributor License Agreement.

R: @ibzib @aaltay

Please fix lint errors.

Yeah, sorry about the lint errors. I still need to find a good configuration for PyCharm that actually works for Beam.

Apparently :sdks:python:test-suites:tox:py2:docs failed. I'm locally to check whether related to my pr.

Docs failure is probably https://issues.apache.org/jira/browse/BEAM-8286

Run Python PreCommit

I messed up the rebase. I'll fix it and repush.

Squashed everything to a single commit now.


cpu keep 100 usage

cpu keep 100 usage for production use
code:
uploadFile, err := uploadFileHandler.Open()
excelFile, err := excelize.OpenReader(uploadFile)
if err != nil {
	return
}

firstSheet := excelFile.GetSheetName(0)
if firstSheet == "" {
	return
}

rows, err := excelFile.GetRows(firstSheet)
...

working perfectly on test, but cpu keep 100 usage when online for production use
go pprof profile:

using in docker container, excelize v2.3.2

Thanks for your feedback, could you provide more details or a spreadsheet xlsx attachment without confidential info?

It's run online, many users uploaded excel files to parse, i can not distinguish which excel file cause this problem.
I had test so many times, this issure nerver happened,  so i had to restart the online service, then it can run normaly for several hours or days.

Maybe you have received a spreadsheet containing an amount of data, try to add the limit for received files that can be processed according to your hardware environment.

ok, thanks, I'll have a try.

It seems still not have enough info of code and attachments to reproduce this issue, so I'll close this issue, if you have any questions, please let me know.

Same issues. And also can't find specific file cause this.
Have you find the reason and figure out this problem?


feat(scrolling): Prevent body scrolling and allow to scroll only dial…

…og itself
This should fix #31

@EisenbergEffect CLA check

@PWKad Confirmed. You are good to go.


Deployment error

Deployment ends up with this error. The AWS account has mostly Lambda, Aurora serverless and ECS resources. Any idea what could be causing this?
IemDashboardStack: deploying...
[0%] start: Publishing d6d4f3b9a4d43573e657059eb71cca92c8bc113e612c9f4e97ccf66b9dcbbc4b:current_account-current_region
[100%] success: Published d6d4f3b9a4d43573e657059eb71cca92c8bc113e612c9f4e97ccf66b9dcbbc4b:current_account-current_region
IemDashboardStack: creating CloudFormation changeset...
8:06:57 AM | CREATE_FAILED        | AWS::CloudWatch::Dashboard | MyTestB3FF2C3A
The dashboard body is invalid, there are 1 validation errors:
[
{
"dataPath": "/widgets/0/properties/alarms",
"message": "Should NOT have less than 1 items"
}
] (Service: AmazonCloudWatch; Status Code: 400; Error Code: InvalidParameterInput; Request ID: 432d8488-fbe0-4038-99b7-634d5cc1b446; Proxy: null)

Thanks for the report. I will look into it ASAP. I will follow up with questions if necessary.

This is now fixed. Pull, and let me know if it works better. Let me know if you find other problems. I haven't tested Aurora serverless yet, so let me know if you miss anything there.

Tried it with another account that also has ECS and Lambda. Worked just fine.
Will also try it with the account that uses serverless aurora.
Thanks for the quick fix!

Works just fine with Aurora serverless too!

Fantastic! Thanks!