Merge FieldLists postdata with objectdata

This patch fixes #509, and replaces #510 and #511.
Let us consider this code. It is a simple Form containing a FieldList with a minimum size of 5:
>>> from wtforms import Form, StringField, FieldList
>>> from tests.common import DummyPostData
...
>>> class F(Form):
...     a = FieldList(StringField(), min_entries=5)
...
>>> a  = F().a
...
>>> pdata = DummyPostData({"a-1": "foo"})
>>> data = ["bar0", "bar1", "bar2"]
>>> a.process(pdata, data)
>>> a.data
["foo", None, None, None, None]

From one hand we have object data with a list containing 3 elements. From the other hand we have some post data for that FieldList but providing only 1 index, and not even the first one.
What should happen here?

Should the post data overwrite the object data? That would mean here creating a new list, with only one element, then fill the list with empty values to reach the minimum size: ["foo", None, None, None, None] This is how WTForms currently behaves.
Should the post data update the object data? That would mean take the object data, replace indices provided by the form data, then fill the list with empty values to reach the minimum size: ["bar0", "foo", "bar2", None, None].

I am in favor of merging data, this is what this PR does.

explicit is better than implicit so:

object data explicitly passed to the form should be used
if you do not send data for one index, then it should not be modified

If you handle a ListField of FileField and have files already present in you object data, you just cannot send them back in the post data just to keep them in the list.
it seems consistent with the general behavior for forms: If you send post data but forget one field, the forgotten fields are not resetted:

>>> class G(Form):
...     a = StringField()
...     b = StringField()
...
>>> class Obj:
...     a = "A"
...     b = "B"
...
>>> F(DummyPostData({"a": "foo"}), Obj()).data
{'a': 'foo', 'b': 'B'}

If think this behavior should be the default, but if you think it is too controversial, maybe we can make it an option?

My comment from the first PR:

You're passing in form data with one value, then manually processing some other data and expecting the two to be merged, which doesn't seem correct.

I'll try to explain a bit better.
data is only default data, this is true in general of fields. Users regularly mix this up and are confused when some fields no longer have data after they process formdata that doesn't include that field. Despite this confusion, this is the intended behavior and the only one that makes sense, otherwise you couldn't clear a field with existing data.
So despite FieldList being a more complex field, this change still seems to be break the intended behavior. For example, if you initially have three fields filled out, there's no way to cut that down to one field with this change.

Your comment on FileField is true, but this isn't the solution. I think that's a case where we need better documentation. "If you're using a FieldList of FileField, existing files won't be re-sent, so you'll want to update the existing data with any new posted data manually."
That problem exists with plain FileFields too, a field won't have any existing data. File inputs are just weird in general. It would be interesting to explore a more complex ClearableFileField like what Django provides. This would actually be three fields, a hidden input with a marker for existing data, a file input for new data, and a checkbox for deleting the data.

I thought a bit about this topic, and I think the main issue I have is with FileField, so indeed, it is another subject.
I guess we could document ListField a bit more on that matter. I saw several tickets where people seem to not always find this behavior intuitive.


Add Sidecar Containers

It would be useful to add extra sidecar containers to the deployment, needed for sock access like fail2ban.sock
I need to deploy extra containers to access the sock at /var/run/fail2ban/ for example.
Should be same as initContainers - most of the template code is probably there

Do you want to submit a PR?


Fixed the promise version of the require statement

Hi @ytechie, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no contribution license agreement is required at this point. Real humans will now evaluate your PR.

TTYL, AZPRBOT;


Run with apprtc with https

Hello,
I've installed certificates(https) with letsencrypt/certbot
I've configured collider to use tls=true and turnserver, they are working fine.
Now, how i can configure apprtc to use https?
Usually i run the app like that
googleapp/dev_appserver.py --port=8083 --host=********** ./apprtc/out/app_engine
Buit it still starts with http
If i try to connect to https://myip:8083 i get the following error:
ERR_SSL_PROTOCOL_ERROR
How i should fix it?
I'm working on a VPS, i can't just run it in localhost

You have only setup secure websocket (WSS) for the signalling server (Collider), not for the actual Google App Engine AppRTC app, it's still running HTTP.
Currently AppRTC is designed to run Google App Engine and letting it handle HTTPS proxying. It is possible to use stunnel in front of dev_appserver.py but it requires modification of the AppRTC code. Also dev_appserver.py is meant for testing, not production hosting.

What should i've to use for production mode? There is some readme about it ?

This is a Google app engine app, it should run on Google app engine. Details at https://cloud.google.com/appengine/.

Thank you, i'll study that


feat(CLI): Support envd-server in conext

Description
Now we introduced a hidden command envd k8s to launch pods on Kubernetes with envd server. It should be removed. The feature should be moved to envd up or envd up --detach && envd attach with the help of envd context.

Message from the maintainers:
Love this enhancement proposal? Give it a 👍. We prioritise the proposals with the most 👍.

envd uses buildkitd container in the local docker host to build the images by default. context command will be introduced to support remote build.
NAME:
   envd context - Manage envd contexts

USAGE:
   envd context command [command options] [arguments...]

COMMANDS:
   create   Create envd context
   ls       List envd contexts
   rm       Remove envd context
   use      Use the specified envd context
   help, h  Shows a list of commands or help for one command

OPTIONS:
   --help, -h  show help (default: false)

The structure of the envd context is:
type Context struct {
	Name          string      `json:"name,omitempty"`
	Builder       BuilderType `json:"builder,omitempty"`
	BuilderAddr   string      `json:"builder_addr,omitempty"`

	Runner     RunnerType `json:"runner,omitempty"`
	RunnerAddr *string    `json:"runner_addr,omitempty"`
}

type BuilderType string

const (
	BuilderTypeDocker     BuilderType = "docker-container"
	BuilderTypeKubernetes BuilderType = "kube-pod"
)

type RunnerType string

const (
	RunnerTypeDocker     RunnerType = "docker"
	RunnerTypeKubernetes RunnerType = "server"
)

The default envd context is:
Context{
    Name:          "default",
    Builder:       BuilderTypeDocker,
    BuilderSocket: "unix:///var/run/docker.sock",
    Runner:        RunnerTypeDocker,
    RunnerAddr:    nil,
}

Users may use envd context create to create new context and use it:
$ envd context create --name my-context --builder-type docker-container --runner-type docker --docker-host unix:///var/run/docker.sock

envd-server runner
envd CLI registers the local public key to the envd server, and request the address of the ssh proxy server containerssh if the user use the envd-server runner.
User registration is not supported in the current design. envd CLI sends a POST request to the envd server.
POST /v1/auth
request: {
	"public_key": CONTENT
}
response: {
	"identity_token": "sadasfafd",
	"port": "2222",
	"status_message": "Login successfully"
}

The server returns an identity token, to identify the user. The identity token will be persisted in ~/.config/envd/auth. The port of the containerssh will be returned too. It should be kept in the context.


New analyzer: Structured logging tokens cannot be repeated

Disallows logging statements such as:
logger.InfoFormat("{0} - {0}", value);

Targets parameterized logging methods on both the NServiceBus logger as well as a direct Microsoft.Extensions.Logging logger.
While repeating a formatting string key works just fine with string.Format(…) not all structured loggers allow this. NLog and the Microsoft.Extensions.Logging.Console implementation are known to throw exceptions in this circumstance.
This analyzer would have prevented the following issue from occurring:

https://github.com/Particular/NServiceBus.Gateway/issues/529

@ramonsmits I added additional semantic logging cases rather than replace all the existing ones.


Add getGroups method to ElementDefinitions

It would be useful to add a getGroups method to ElementDefinitions that returns the union of getEntityGroups and getEdgeGroups. This allows code that is filtering Elements by checking that the group of the Element is in the View to avoid having logic that tests whether it's an Entity or an Edge.

Merged into develop.


DS-3436 5x Sharding SOLR cores corrupts multivalued fields for master

Port Tom Desair's fix in https://github.com/DSpace/DSpace/pull/1613/files to 5x
https://jira.duraspace.org/browse/DS-3436

@terrywbrady : crud, this one seems to now have a (minor) code conflict. If you can rebase this one, I'll merge it.

@tdonohue , the merge is resolved.

Thanks @terrywbrady , merging.


CC-11 # accurate ContentType detection; deploy --no-skip

Added

CC-11: deploy --skip (default) and deploy --no-skip options (#13, @jokeyrhyme)

Changed

CC-11: update to blinkmobile/aws-s3.js 1.2.0 (#13, @jokeyrhyme)

made documentation a bit more like blinkmobile/bmp-cli, which means CLI --help and README.md are synchronised via copy-paste (simpler than 2 versions)

Code Review Notes

you may also want to review upstream: https://github.com/blinkmobile/aws-s3.js/pull/1

lgtm :+1:


chore: add lnav definitions and install

I found lnav useful during development on ftl so I put together a quick definition for others that might find value with it (i.e. when there are multiple verbs in play).

It looks like there are statically linked binaries - can you make a Hermit package for it please?

Interesting, but what are you thinking we'd use this for in FTL? I don't think I ever merge multiple logs during day-to-day development.

It looks like there are statically linked binaries - can you make a Hermit package for it please?

sure! i can make it a hermit package but do we want to add it as a dependency? i was thinking of keeping it optional since it's personal preference.

Interesting, but what are you thinking we'd use this for in FTL? I don't think I ever merge multiple logs during day-to-day development.

for me most of the time it's in the background for me to see colorized/formatted/filtered logs. since i get lost in monochromatic logs. but to your point, definitely the collation of logs isn't standard, just a bonus feature!

Okay, well while it sounds useful, I think we want to keep tools/scripts in the FTL repo specific to FTL itself. Thanks for the thought though!

for posterity: moved to here https://gist.github.com/lamchau/e6e61c7dec8d6400a4fac42f9726cb11


New package: SoilWater_ToolBox v1.0.0

Registering package: SoilWater_ToolBox
Repository: https://github.com/manaakiwhenua/SoilWater_ToolBox.jl
Created by: @joseph-pollacco
Version: v1.0.0
Commit: 5c001420d4299447438b18a3c0b364cdd8a34339
Git reference: HEAD

First SoilWater_ToolBox package

julia> @time using SoilWater_ToolBox  # for 1.7-beta3, could do with some work to reduce startup time, still ok to register I guess:
 16.239895 seconds (24.72 M allocations: 1.530 GiB, 5.25% gc time, 0.07% compilation time)

I'm not sure what's happening with JuliaRegistrator, but I think it's you @joseph-pollacco who blocked registration. FYI, what you need to do if you do not want block (and I'm not sure if too late or if you need to do an intervention):
[no block]

Hallo Páll Haraldsson,
A greeting from New Zealand. Thanks for your time for kindly looking at my first large package SoilWater_ToolBox which I hope will be useful to the hydrological community.
Q1)  When I add the package SoilWater_ToolBox  in Julia environment it does not work:
_`ERROR: The following package names could not be resolved:

SoilWater_ToolBox (not found in project, manifest or registry)`_

So the question is how can I unblock the registration as I did not receive any messages indicating that my package was blocked?
Q2) Yes indeed it will be great if I can reduce the startup time, or else my colleagues will not believe in the power of Julia!
When I start SoilWater_ToolBox I include all the packages I need for the simulation in the following file:
https://github.com/manaakiwhenua/SoilWater_ToolBox.jl/blob/master/src/Including.jl
I call the subroutine which include all the packages from:
https://github.com/manaakiwhenua/SoilWater_ToolBox.jl/blob/master/src/SoilWater_ToolBox.jl
I will be ever so delighted if you can provide me some tips how to decrease the starting time?
Thanks for your kindness and dedicated for making Julia such a joy to use,
Joseph

@joseph-pollacco I'm a bit lost: can this be merged?

Dear Giordano,
Many thanks for you help. May I suggest you that you delete the New package: SoilWater_ToolBox and I resubmit a fresh package.
It is to be noted that the SoilWater_ToolBox is a very large package and I had many attempts to get all the 8 all checks
Many thanks for your kind help,
Joseph

May I suggest you that you delete the New package: SoilWater_ToolBox and I resubmit a fresh package.

That's ok, I'm going to close this pull request and you can submit a new registration whenever you want.  However, please note that if you write a message in a pull request without writing [noblock] you're effectively blocking registration.  The best thing you can do is to just not write anything.  If you really want to leave a comment you must use [noblock] if you don't want to stop registration.

Dear Giordano,
Thanks for your very kind help and dedication and for informing me about the [noblock] I was not aware of this subtility.
Great day,
Joseph


Update BUILDING and CONTRIBUTING docs after the svn->git migration.

I'm opening this PR for some review/help. There are a couple of references to SVN left in the documentation (MERGE.txt and BUILDING.txt) that I'm not sure how to adjust. Anyone have thoughts on that?

The svn:eol-style is what I'm unsure of in BUILDING.txt. I don't see an obvious equivalent in git, but didn't want to trash the note because it's important.
For MERGE.txt, should that be left alone? It looks like that's a more generic file than something specific to Tomcat.

Agreed, I tried looking at the dev archives for opinions of git EOL ending settings (core.autocrlf) and didn't see anything. I'd be tempted to add something to the FAQ with respect to this.  (Assuming there is consensus on what those settings might be)

It gets a mention at the end of https://wiki.apache.org/general/GitAtApache
Probably worth a dev@ discussion

Test ping.

Do we want to accept this commit so that the docs mostly reflect our current state and fire off a discussion re: svn:eol-style?

+1

I've accepted the PR and will follow up on the dev@ list with a discussion on an svn:eol-style equivalent.


Remove unnecessary include in GDScriptWorkspace

The gdscript_parser.h is already included inside gdscript_extend_parser.h so no need to include it multiple times.

Could you amend the commit message to be more explicit? E.g. the PR's title is good. Otherwise it's hard to know which part of the codebase this is affecting.


[type:fix] fix trie match error

Make sure that:

[ ] You have read the contribution guidelines.
[ ] You submit test cases (unit or integration tests) that back your changes.
[ ] Your local test passed ./mvnw clean install -Dmaven.javadoc.skip=true.

Codecov Report

Merging #4504 (01eea6c) into master (2699e26) will decrease coverage by 0.07%.
The diff coverage is 59.61%.

@@             Coverage Diff              @@
##             master    #4504      +/-   ##
============================================
- Coverage     68.07%   68.01%   -0.07%
- Complexity     7568     7579      +11
============================================
  Files          1029     1029
  Lines         29372    29401      +29
  Branches       2652     2656       +4
============================================
+ Hits          19994    19996       +2
- Misses         7797     7818      +21
- Partials       1581     1587       +6

Impacted Files
Coverage Δ

...g/apache/shenyu/common/cache/WindowTinyLFUMap.java
38.63% <11.11%> (+38.63%)
:arrow_up:

...pache/shenyu/plugin/base/AbstractShenyuPlugin.java
59.00% <16.66%> (-0.23%)
:arrow_down:

...apache/shenyu/plugin/base/trie/ShenyuTrieNode.java
69.23% <66.66%> (+0.48%)
:arrow_up:

...org/apache/shenyu/plugin/base/trie/ShenyuTrie.java
69.94% <80.76%> (-0.82%)
:arrow_down:

...pache/shenyu/plugin/base/cache/MatchDataCache.java
100.00% <100.00%> (ø)

... and 9 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Renamed file cannot be shown properly

Description
When a file is renamed (similar to #715), the Renamed session in Neogit seems broken.
Neovim version
NVIM v0.9.5
Build type: Release
LuaJIT 2.1.1703358377
Operating system and version
macOS 14.2.1 23C71 arm64
Steps to reproduce
I'm trying this on my neovim config repo, but it seems to me that this can be reproduced regardless of the actual repo.

Rename any file (in this case, lsp/config/rust_analyzer.lua) and stage. This will lead to a git status like the following:

> git status
On branch master
Your branch is up to date with 'origin/master'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        renamed:    lsp/config/rust_analyzer.lua -> lsp/config/rust-analyzer.lua

Launch magit.

Expected behavior
The Renamed line and the diff are showing properly.
Pressing enter on the Renamed line will lead to the just-renamed lsp/config/rust-analyzer.lua.
Actual behavior
In my case Neogit gives:
v Staged changes (1)
> Renamed        a -> lsp/config/rust-analyzer.lu

> Recent commits (10)

In this state not only is it impossible to see the diff, but pressing enter on the Renamed line will lead to an inexistent lsp/config/rust-analyzer.lu file.
Minimal config
{
  "NeogitOrg/neogit",
  opts = {
    signs = {
      item = { ">", "v" },
      section = { ">", "v" },
    },
  },
}

I think I may have found out the problem.
https://git-scm.com/docs/git-status says:
Renamed or copied entries have the following format:

2 <XY> <sub> <mH> <mI> <mW> <hH> <hI> <X><score> <path><sep><origPath>
...
<sep>       When the `-z` option is used, the 2 pathnames are separated
	    with a NUL (ASCII 0x00) byte; otherwise, a tab (ASCII 0x09)
	    byte separates them.

Aha! This is a combination of 2 separate issues so fixing only one of them (with #1165) won't work.

It's actually fixed in https://github.com/NeogitOrg/neogit/pull/1167 rather than #1165, at least for a while...

Just for the record, the same issue keeps happening with the latest version ( c0b1d4d ), and Neovim version 0.9.5

I'm on c0b1d4d + nvim 0.9 as well and it seems that I can't reproduce this issue 👀

@rami3l The issue seems to happen when there are staged changes in renamed file, and unstaged changes to it's content.
Steps to reproduce, in an example repo without unstaged changes:
echo "example" > test.txt

git add -A && git commit -m "..."

mv test.txt test_2.txt

git add -A

echo "change" >> test_2.txt

Open neovim and neogit status buffer and the bug happens.

Given that maybe we should reopen this issue. @CKolkey what do you think?


pip_audit: Add skipped dependencies to audit summary

Closes #141

@woodruffw
I liked the idea you described in https://github.com/trailofbits/pip-audit/issues/141#issuecomment-981785372 so I've modelled this PR after that.


[1.10.2] Light level overlay not working?

Hey there im using NEI, everything is fine except that the light levels (F7) function seems to not work.
any ideas?
Mods:
Forge.1.10.2 - <IP_ADDRESS>1
NotEnoughItems-1.10.2-<IP_ADDRESS>-universal.jar
jei_1.10.2-<IP_ADDRESS>0.jar

1.10 Is not supported anymore, please update. Only thing i can think of is keybinds, make sure NEI's keybinds are setup properly.


feat(initContainer): Tune start-up process

Previous implementation used initialDelaySeconds set to 120s which might be fine for standard (default resource allocation), first-time starting (with empty database) instances. Mentioned fact is problematic for:

instances that are "under-resourced" and start-ups might be longer and 120s might not be enough
instances that are "over-resourced" and start-ups might be much shorter and 120s might be wasting of time (to wait until the instance is marked as Ready)
instances that are already deployed and just need upgrade (with no or only just a couple of migrations). In this case, it  is wasting of time again.
instances with multiple replicas when each replica needs to wait 2 minutes without the reason. Waisting of time again.

This solution does not solve #10197 but at least do not silently allow full rollout until the database is fully migrated.
This solution might be solved as well #10141

I believe you forgot to add the startupProbe to the deployment. I was expecting to see the startupProbe just after https://github.com/DefectDojo/django-DefectDojo/blob/dev/helm/defectdojo/templates/django-deployment.yaml#L210-L223, along with default values for it.
As far as I understand, this PR tries to solve two different issues that are unrelated: probes and migration. I'd suggest to split it into two different PRs, this one looks good for migration, I'd just revert https://github.com/DefectDojo/django-DefectDojo/pull/10454/files#diff-62fee928ffe25d7f0d884b137db6f0ad7ffd1fb15d4fb217b922e3ef201f2e37L223-R223 and leave the whole probes modification to a new PR.

I believe you forgot to add the startupProbe to the deployment. I was expecting to see the startupProbe just after https://github.com/DefectDojo/django-DefectDojo/blob/dev/helm/defectdojo/templates/django-deployment.yaml#L210-L223, along with default values for it. As far as I understand, this PR tries to solve two different issues that are unrelated: probes and migration. I'd suggest to split it into two different PRs, this one looks good for migration, I'd just revert https://github.com/DefectDojo/django-DefectDojo/pull/10454/files#diff-62fee928ffe25d7f0d884b137db6f0ad7ffd1fb15d4fb217b922e3ef201f2e37L223-R223 and leave the whole probes modification to a new PR.

@fcecagno, thank you for your feedback.
TBH, originally, I planned to use startupProbe. However, during testing, I found out it is not the best approach in my opinion.
Based on my experience, until now, probes have been failing because the application has not been ready (mandatory migrations have not been finished).
The previous implementation was trying to "solve" it with 2 minutes long initial period. However, this is not the best  (check the reasoning in the description of this PR)
Using startupProbe would be usable however it would be necessary to add it to both containers. I wanted to avoid starting redundant probes and using initContainer has the same outcome = liveness and readiness probes are not started until initContainers are not Completed.
But please tell me if you see it otherwise. Or if you have a different experience.

Hi @kiblik , thanks for your reply. IMO this PR improves the current state.

@kiblik Got a new/different opinion of this one? Wanted to double check since we're getting close to 4 approvals.

@kiblik Got a new/different opinion of this one? Wanted to double check since we're getting close to 4 approvals.

I still see it as useful. I saw also @fcecagno's proposal #10506 and I believe that both of them are beneficial, they can coexist and help to improve smoother deployments.


Unsure if the calibration calculation used in the code is correct

 calib = round(0.04096 / (_current_LSB * shunt));

You use round in your calculation for the calibration but the datasheet says to use truncate. I don't know if this is an oversight or intentional. I'm nitpicking I know.
Thank you for the nice library. 👍

Thank you for pointing to this bug.
This would be a systematic error (in 50% of the cases) so needs to be fixed.
Have you an indication about the impact, in absolute sense?

I'm nitpicking I know.

I would call it a decent review, I assume I missed it when implementing and it just stayed in the library since then.

Created a develop branch for version 0.3.0
includes the fix + some edits and build-CI update that were pending.

There is a problem with the pull request build-CI, one version just builds correctly, the other blocks/freezes.
DO not know the cause, however given that one build is OK you could try the develop branch if you want to.

Merged into master and released as 0.3.0


Missing metadata.ctProjectKey for some transactions.

I found that a small percentage of notifications that our integration got from Adyen does not have metadata.ctProjectKey field.
It breaks the process, as the notification module can not correctly handle such notifications.
In the documentation:
https://github.com/commercetools/commercetools-adyen-integration/blob/master/docs/adr/0003-matching-adyen-notification-in-multitenancy.md
Additionally, I contacted Adyen support. They inform me that sometimes when the notification is sent, they do not have access to transaction meta yet. Therefore, they would need to wait for it, even a few minutes.
In our system, every minute is essential, as we provide services to our customer's houses in 10-30 minutes.
Maybe you can propose something to avoid this issue?
We always use dedicated notification service instances per given Adyen environment. Maybe you can add some optional configuration options, e.g. defaultAdyenProjectKey that will automatically assume Adyen project if it is not available in the notification?

Hi @wiktor-obrebski,
Thank you for contacting us about this problem.
From what I understood, sometimes with the first notifications they don't contain metadata.ctProjectKey, but for the same notifications later on you get with metadata.ctProjectKey? And when you test locally, everything is working fine or can you reproduce this problem?

It's sporadic. For around ~1 thousand transactions per day, it happens 1-2 times.
There is an example log from notification service (with obscured ids etc.):
{..., "level":50,"notification":[{"eventCode":"AUTHORISATION","eventDate":"2022-03-16T22:57:01+01:00","pspReference":"...","success":"true"}],"cause":{"message":"Notification can not be processed as \"metadata.ctProjectKey\"  was not found on the notification.","name":"Error","stack":"Error: Notification can not be processed as \"metadata.ctProjectKey\"  was not found on the notification.\n    at getCtpProjectConfig (/app/src/utils/parser.js:9:11)\n    at handleNotification (/app/src/api/notification/notification.controller.js:24:32)\n    at runMicrotasks (<anonymous>)\n    at processTicksAndRejections (node:internal/process/task_queues:96:5)\n    at async Server.<anonymous> (/app/src/server.js:14:9)"},"msg":"Unexpected exception occurred.","time":"2022-03-16T21:57:02.408Z","v":0}
--

A repeated message later probably has the proper ctProjectKey, as some of these transactions are handled by our system later. But this creates delay, which sometimes takes too long.
Our app can give up with the payment, as from CommerceTools perspective, the payment is still not authorized.
The customer can manipulate his cart later, as the cart has not been ordered yet (as payment has not been confirmed).
Then, even if the transaction is authorised correctly after a few minutes, the value can be not enough to pay for the current cart.
Additionally, the customer can be confused as the app already let him know about payment failure.
I feel that such a default project key for a single-tenant environment could fix the issue.

Thank you for clarification. Your suggestion sounds good for your case, but we might need to find a solution that fits also multi-tenant cases. We will check the problem with the team internally and also with Adyen and get back to you with more info within next week.

We have exactly the same issue. In our case our prod env only has a single metadata.ctProjectKey so, assuming the HMAC is valid it could just use that.

Hi everyone,
I have clarified the issue with Adyen and we will add the workaround as suggested by @wiktor-obrebski. The feature should be available in April.

Hi @wiktor-obrebski
Sorry for the delay. We discussed this topic again in our team and come up with a solution that would also fit the multi-tenant case. We agreed to get the project key from the notification webhook URL in case metadata.ctProjectKey is missing. It means that the user has include in the notification URL the project key as part of the path. We want to release this feature sometimes next week. Does the solution sound good to you?

sounds reasonable, we can migrate notification url if you provide documentation with details.

I see the change has been merged few days ago. Can a release be prepared?

Hi @wiktor-obrebski we already implemented the feature and tested successfully as self-deployed server and deployment on GCP. However, we need to make sure that it works on AWS before releasing. This will be finished during next week and then we will release it.
If you want, you can prepare the URL for notification module according to the new structure: https://github.com/commercetools/commercetools-adyen-integration/blob/880f9fb7a92bb80b7d84d10a5af4514a6fb286f8/notification/docs/IntegrationGuide.md#fallback-in-case-metadata-is-not-available. When we release the feature next week, it will work for you out of the box.

Hi @wiktor-obrebski today we finished testing on AWS and made a new release. Please have a look: https://github.com/commercetools/commercetools-adyen-integration/releases/tag/v9.8.0

Applied fix should handle the issue until Adyen ensures that metadata is always provided in all the notifications (work in progress on Adyen side). Therefore I am closing this issue. If you have further concerns, please do not hesitate to reopen/create new issue.

thank you, I will try to check it this week.


Fix unbranded template

Updates the unbranded template to extend the main layout, which allows users to use Prototype Kit specific patterns such as the task list and step-by-step patterns.
Closes https://github.com/alphagov/govuk-prototype-kit/issues/841

lib/v6/govuk_template_unbranded

I think... we should keep that the same for compatibility reasons, but could be wrong.

One thing is that this is quite a large breaking change.

What do you think this would break for users?

I think... we should keep that the same for compatibility reasons, but could be wrong.

Happy to pair on this, the v6 stuff can be a bit weird.

What do you think this would break for users?

Okay the word "breaking" was a bit misleading, I meant it in the sense that users have to manually do something. When there are changes to /app they won't be automatically applied on kit update. Or did you think we'd mention the changes users have to make in the release notes but mark them as optional? Happy to chat about this.

Happy to pair on this, the v6 stuff can be a bit weird.

I don't think V6 compatibility should expect to have features available in the current release, seems weird to me to update V6 so it works differently to how it used to work.

When there are changes to /app they won't be automatically applied on kit update.

I think if users don't make these changes when they update it wont break anything with their existing code, they just wont get the fixes for the unbranded stuff?

Spoke with Hanna and we need to make sure the CHANGELOG explains how to upgrade

Assigned this blocked as will need a review from Mark.


kdeFrameworks.plasma-framework: aligned with QtQuick 2.12

Motivation for this change
A less invasive remedy for #98536
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[x] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/go-no-go-meeting-nixos-20-09-nightingale/9169/24

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/what-should-stable-nixos-prioritize/9646/1


ability to shade background

My wallpaper changes every hour (photos) and the widget font sometimes matches the wallpaper.  While shading text can help a bit, it would be nice to be able to select a degree of shading the background of the widget itself. With shading the background of the widget the wallpaper is still visible but can contrast with the widget text to make said text visible no matter what the wallpaper is.

I've just checked and it's not possible to be notified when the wallpaper changes.
Which app are you using?

Hello again,
I was wondering if the "Show Wallpaper" command, with choices of "Visible" and "Hidden" might be intended to do what I want.
If so, please be advised that on Samsung S10+ from Verizon in the US, on the latest updates, using the Nova Launcher Prime v6.2.12 UI rather than Samsung UI, the "Show Wallpaper" command does not appear to do anything.
If "Show Wallpaper" is supposed to do what I'm asking for, then perhaps being able to set the degree of transparency and the colour would be helpful.  In fact, wasn't that available in the prior version of your app?
Thank you for making this app available and working to make it even better.
Michael

"We're all stories in the end.  Just make it a good one, eh?"
On Monday, May 4, 2020, 5:28:43 PM PDT, michael.butler<EMAIL_ADDRESS>wrote:

Hello,
Thank you for the quick response.
I use wallpaper changer, but that's irrelevant to the request.
What I thought I was asking was the ability to select a background shading for the screen area of just the widget and being able to define the percentage of transparency of the wallpaper thru the widget background.
Having your app adjusting to the wallpaper colours dynamically would seem to require quite a lot of work on your part compared to doing something like overlaying the area occupied by the widget with a shade of grey (or user selectable colour) allowing XX% transparency to the wallpaper underneath would be easier.  The background would provide the contrast to the text of the widget.
Many thanks for providing a really great widget.
Regards,
Michael
----------------------------"It stands to reason. I've never understood that. It sits to reason sounds much more comfortable."
-------- Original message --------From: Tommaso Berlose<EMAIL_ADDRESS>Date: 5/4/20 16:34 (GMT-08:00) To: tommasoberlose/another-widget<EMAIL_ADDRESS>Cc: lmb02<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [tommasoberlose/another-widget] ability to shade background (#52)
I've just checked and it's not possible to be notified when the wallpaper changes.
Which app are you using?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

The "show wallpaper" feature enables the launcher wallpaper inside the preview in the application.
You can set a background in the widget with the newest update of the beta version of the app.


Request to add features 'only' and 'skip' test case execution

Is your feature request related to a problem? Please describe.
Testing framework like jest provide features of only and skip. Requesting similar feature is specmatic. This will help in running only selective test cases during development period.
Describe the solution you'd like
Examples names can support like xsuccess and ffailure.
Describe alternatives you've considered
NA
Additional context
NA

@piyush2206 Thanks for reaching out.
The capability that you are asking for already exists in Specmatic. Please refer to below documentation on filterName and filterNotName. These arguments can be sent as part of the variable arg parameter for Node and Python wrappers.
Hope this helps. cc @jaydeepk

@harikrishnan83 When i am passing multiple --filter-not-name it gets stuck. How can i filter multiple paths?


Fix go vet reported bad code

There wasn't much. :)
Note that I removed the passing of resErr (chan error) to a few functions since it was only a component of the unreachable code found, making passing the arg superfluous.

Should be resolved now.

LGTM

LGTM


Added toast messages in the base template

Related Issuse or bug
To show toast messages to the users
Fixes: #61
Screenshots

Original
Updated

@Kajol-Kumari Yes we can do that. I will do the changes

@Kajol-Kumari I have created another template for the message.

@diyajaiswal11 plz remove conflicts.

@ymaheshwari1 plz remove conflicts then it is good to go.

@harsh-9in Done


center-block

Shouldn't the center-block utility class have a definition of width: 100% ?

Why should it?

AIUI, its existing display: block basically already has that effect.
In most cases, the element .center-block is being used on should have an explicit width set by the user; for example, see http://www.w3resource.com/twitter-bootstrap/center-a-div.php

If the element it is assigned also has a property of position: fixed it doesn't follow the width of the parent—even if it's a block element, or am I wrong to assume that this utility class can be used with those types of elements?

Well, if you have two objects of the same dimensions at exactly the same location, then by definition they are already centered within each other (this being an edge-case where the centering is trivial).
So in normal non-fixed-position cases, I'm not sure why one would (need to) use .center-block on a width: 100% element in the first place, although I am admittedly not a CSS expert.
Let me put it another way: In your case, if you remove .center-block and just put width: 100%, what problem do you encounter?

That utility is for centering an element within another element. It knows nothing of what the parent is, so if you've got some position: fixed parent, you'll need to account for width there as well.


Facial Emotion Detection

Deep Learning Simplified Repository (Proposing new issue)
:red_circle: Project Title : Facial Emotion Detection
:red_circle: Aim : Create a DL model which will detect the emotions from the facial activities.
:red_circle: Dataset : https://www.kaggle.com/datasets/mhantor/facial-expression
:red_circle: Approach : Try to use 3-4 algorithms to implement the models and compare all the algorithms to find out the best fitted algorithm for the model by checking the accuracy scores. Also do not forget to do a exploratory data analysis before creating any model.

📍 Follow the Guidelines to Contribute in the Project :

You need to create a separate folder named as the Project Title.
Inside that folder, there will be four main components.

Images - To store the required images.
Dataset - To store the dataset or, information/source about the dataset.
Model - To store the machine learning model you've created using the dataset.
requirements.txt - This file will contain the required packages/libraries to run the project in other machines.

Inside the Model folder, the README.md file must be filled up properly, with proper visualizations and conclusions.

:red_circle::yellow_circle: Points to Note :

The issues will be assigned on a first come first serve basis, 1 Issue == 1 PR.
"Issue Title" and "PR Title should be the same. Include issue number along with it.
Follow Contributing Guidelines & Code of Conduct before start Contributing.

:white_check_mark: To be Mentioned while taking the issue :

Full name :
GitHub Profile Link :
Email ID :
Participant ID (if applicable):
Approach for this Project :
What is your participant role? (Mention the Open Source program)

Happy Contributing 🚀
All the best. Enjoy your open source journey ahead. 😎

please assign this task to me— Facial Emotion Detection
FullName: Satwik Reddy Katukuri
Github Profile Link: https://github.com/KSatwik
Email ID<EMAIL_ADDRESS>Approach for this Project:
Load and preprocess the facial expression dataset.
Split the dataset into training and testing sets.
Choose 3-4 deep learning algorithms suitable for image classification, such as CNN, RNN, or their combinations.
Implement each selected model separately.
Train each model using the training dataset.
Adjust hyperparameters for optimal performance.
Evaluate the trained models using the testing dataset.
Compare the performance of different models based on accuracy.
Select the model with the highest accuracy as the best-fitted algorithm.
What is your participant role? -contributor at Social Summer of Code (SSOC), Season-2

Hi @KSatwik  nice to have you here. I like your approach for solving this issue. This issue will be assigned to you once the program starts officially.
Till then, star the repository and explore more in open source.

Issue assigned to @KSatwik

@abhisheks008 Is this issue available for SWOC-4? If yes, please assign it to me.

Full name : Siddhant Tiwari

GitHub Profile Link : https://github.com/siddhant4ds

Email ID<EMAIL_ADDRESS>

Participant ID (if applicable): N/A

Approach for this Project :

Baseline model using a simple CNN
Explore techniques for improving image quality (since they are very low-resolution)
Transfer-learning using different architectures as feature-extraction backbone
Fine-tuning the best performing transfer learning model

What is your participant role? (Mention the Open Source program) SWOC-4 (2024)

Suggestion: Try to use atleast 2-3 different Deep learning techniques/methods for this project and compare them using the accuracy scores to find out the best fitted model for this dataset.
Issue assigned to you @siddhant4ds


Idea: Add optional minimal favicon.ico

Most of Browsers request automatically the favicon.ico even if you use it or not
(I dunno if thats standard compliant or not but still),
most of times produces several failed HTTP GETs,
what if we add the option to use the smallest possible syntactically valid ICO file (70 Bytes)
logs for 1 request from browser (it request it twice the first time):
DEBUG GET /favicon.ico
DEBUG   404 Not Found {"content-type": @["text/html;charset=utf-8"]}
DEBUG GET /favicon.ico
DEBUG   404 Not Found {"content-type": @["text/html;charset=utf-8"]}
DEBUG GET /favicon.ico
DEBUG   404 Not Found {"content-type": @["text/html;charset=utf-8"]}

Just adding a staticRead("favicon.ico") with this file will fix it.
it can be disabled if the user has a favicon.ico on the static folder or can be done with a parameter somewhere.
AFAIK it can not be disabled, browsers still request it anyways, is like hardcoded on them.
File is cached, so it will be requested once if it works.
Question: Should we try to report this idea to Jester instead ?.
:thinking:

On what pages do you get the 404?
Standard ico
NimWC provides a favicon.ico located here: https://github.com/ThomasTJdev/nim_websitecreator/blob/master/public/images/logo/favicon.ico
Include icons
favicon.ico is not requested on my system in either Firefox and Chromium, so I don't see the 404. The core also uses  favicon-16x16.png, favicon-32x32.png and favicon-192x192.png for the Admin pages (settings).
The user currently needs to handle this buy them self, except if the use the standard data, where the same code is standard in the <head>.
# main.tmpl - genMainAdmin()
  <link rel="shortcut icon" href="/images/logo/favicon.ico">
  <link rel="icon" type="image/png" href="/images/logo/favicon-16x16.png" sizes="16x16">
  <link rel="icon" type="image/png" href="/images/logo/favicon-32x32.png" sizes="32x32">
  <link rel="icon" type="image/png" href="/images/logo/favicon-192x192.png" sizes="192x192">
  <link rel="apple-touch-icon" sizes="180x180" href="/images/logo/favicon-180x180.png">

Remove or ..
I would prefer to let the user handle it by them self. Currently they can remove the <link> tag from header or change it to a icon file they uploaded.
Otherwise we could provide some guidance with either the ico you linked to or
<link rel="icon" href="data:;base64,iVBORw0KGgo=">

Jester
I think Jester needs to stay as a webserver, where the user has to manage the surroundings.

I think this one is Fixed on last version :grey_question:

Fixed in 4.0.5


WIP: Gets Credentials from a Pivotal Cloud Foundry environment

Fixes #255

This is a rough proof of concept for getting credentials from a PCF environment that is yet completely untested.
I just wanted to validate the initial design that I think the other services will follow.
Someone might also pick this up while I'm away on vacations.
@mkjelland @boparp-pivotal FYI

Added Cloud SQL credentials with a little bit of hacking, due to the existing restrictions.
Let me know what you think from https://github.com/spring-cloud/spring-cloud-gcp/pull/449/commits/ab3d9475315dae0fdbf5dc12ee3ec0d6d07f768c

I'm not sure why nobody familiar with Cloud Foundry review this yet, but I would say all those System ENV and properties manipulations are not Spring Boot friendly...

@artembilan I agree. That being said, I explained in https://github.com/spring-cloud/spring-cloud-gcp/pull/449#discussion_r174920421 why the Spring Boot way is unfeasible.
If anyone suggests a working alternative, I'm happy to follow. Otherwise, this is the only approach I know works...

@boparp-pivotal it would be great if you could review this PR!
If you know anyone else who has a strong knowledge of CF and could help with the review, that would be very helpful too!

This PR is still lacking some tests, but is ready for a good pass.
@snicoll @balopat @ChengyuanZhao FYI

@artembilan knowing you're not fully familiar with CF, would be nice to get another pass from you here.
I think @snicoll is providing the CF expertise here later, when he's got the free cycles.

@artembilan as mentioned earlier, I believe that the post processors kick in after the context is built, whereas we need this envvar during context construction, to provide our own beans. Let me know if I'm wrong.
The problem with the existing VCAP parsing is that it uses user-provided keys that we can't guess.
Since this has been brought up so many times before, let me know if it's worth having a VC to discuss the issue.

Right, I think we need to have a call with appropriate people.
I still believe that custom EnvironmentPostProcessor does the trick here when we parse some env vars and build others. We do that in many other places and it works well.

user-provided keys that we can't guess.

Well, that's not how Spring Boot works. One of its purpose is Configuration on Convention.
So, we require some particular properties end-user must provide to kick off auto-configuration.
If end-user doens't follow that convention we back up and he/she is on their own!

Thanks a lot, @dsyer.
Another option would be to merge this PR as is and file a new issue to consider swapping the explicit parsing by an EnvPP, assuming there is nothing else wrong with this PR. @artembilan wdyt?
We would really like to ship CF support with our next M3 release, which we expect should happen within a week or two.

My position do not merge and do not ship the feature in M3 if we don't agree on the solution.
This PR brings a lot of breaking changes, which I somehow feel should gone when we come up with the EnvironmentPostProcessor solution.
I won't mind if someone else will express opposite position and this will be merged and EnvironmentPostProcessor way will be forgotten.
Unfortunately my CF knowledge is too low so I can't hit the table to show how things should work...

What do you mean with "breaking changes"?
I might be missing something, but I don't think anything will break moving from manual parsing to an EnvPP.
It should be invisible to a user -- they won't need to change anything to get CF credentials support.
It's just an implementation detail, which is why I'm suggesting this feature gets merged, and we optimize later.

Well, I admit that I didn't reviewed it properly because I'm not familiar with the feature, but I see 23 files changes and most of them are about existing classes. That's how I make a conclusion that is about breaking changes.
On the other hand if you agree about EnvPP, why don't do that already now? You said we still have one-two weeks - sounds like a plenty of time to experiment.
That's not about optimization, that's about how properly to design API once and mix concerns to break your head in the future.
Just remember how we reworked everything recently because of wrong direction for design from the Spring Boot perspective...
I guess I'm not a right person to help you here, since we don't have consensus.

@joaoandremartins and I had a meeting about this PR that helped a lot.
Here's a brain dump on my side, none of that is blocker IMO and we can refine later.
Credentials provider
It would be nice if CredentialsProvider handling was such that the CF piece didn't show up in the regular auto-config at all. Currently, the logic works as follows:
. If the service is bound in CF, we use the information from VCAP
. If the user has set a property, we use that
. Otherwise, we use the global CredentialsProvider from the context
If the mapping between 1. and 2. is one-to-one, one idea is to create a special PropertySource that sets the property that is expected in 2. with the information from VCAP. This has several advantages:

The code isn't aware of the CF specific bits
The Environment clearly states why credentials are configured this way (you can see the property source using /actuator/env)

If that's not possible, then we need some sort of Provider<CredentialsProvider> where the implementation would apply the logic above. In this scenario, it would be beneficial that the CF pieces was registered independantly so that the provider doesn't have to know about it. An advantage of that is that if the application doesn't run in CF, then that piece isn't registered at all and we don't have to play with @Autowired(required=false). Unrelated but ObjectProvider<T>.getIfAvailable() is what we use nowadays for this.
CF checks
Rather that having a @ConditionalOnProperty we could use @ConditinalOnCloudPlatform(CloudPlatform.CLOUD_FOUNDRY)
SqlCredentialFactory
The factory needs to be configured using system properties at the moment. We have a piece of code that does that for the non CF use case and this PR adds somewhat the same code when reading stuff from VCAP.
I'd like us to consider applying the same strategy as for the credentials provider. Setting that information using the regular keys seem quite appealing to me. If that's not possible, that code should be extracted from the main auto-config.

Superseded by #509


dev: improve kustomize.sh (auto indent)

This patch contains some further improvements of the dev script kustomize.sh adding back autoindentation of the multiline variables.
This also cleans the variables used for templating
Signed-off-by: Nathan Skrzypczak<EMAIL_ADDRESS>

we can remove deprecated interface config from DEVELOPER_GUIDE

Changed the DEVELOPER_GUIDE content to
# ---------------- interfaces ----------------
export CALICOVPP_INTERFACES='{
  "uplinkInterfaces": [
    {
      "interfaceName": "eth0",
      "vppDriver": "af_packet"
    }
  ]
}'


Executing powershell script from unc path

Last 0 Keys:
16:52:38Info
Exception:
16:52:38Info
System.IO.IOException: The handle is invalid.
16:52:38Info
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
16:52:38Info
at System.Console.GetBufferInfo(Boolean throwOnNoConsole, Boolean& succeeded)
16:52:38Info
at Microsoft.PowerShell.Internal.ConhostConsole.get_CursorLeft()
16:52:38Info
at Microsoft.PowerShell.PSConsoleReadLine.Initialize(Runspace runspace, EngineIntrinsics engineIntrinsics)
16:52:38Info
at Microsoft.PowerShell.PSConsoleReadLine.ReadLine(Runspace runspace, EngineIntrinsics engineIntrinsics)
16:52:38Info

Task ID:        ServerTasks-12
Task status:    Executing
Task queued:    Monday, May 16, 2016 5:09 PM
Task started:   Monday, May 16, 2016 5:09 PM
Task duration:  1 minute
Server version: 3.3.12+Branch.master.Sha.0474f72915626d6dd344060fa5d54c919b1a1ebc
                | == Running: Deploy ECP Windows App release <IP_ADDRESS> to Dev ==

17:09:52   Verbose  |   Guided failure is not enabled for this task
|
|   == Running: Step 1: Uninstall ==
|
|     Running: Eric
17:09:52   Verbose  |       Octopus Server version: 3.3.12+Branch.master.Sha.0474f72915626d6dd344060fa5d54c919b1a1ebc
17:09:52   Info     |       Executing script on 'Eric'
17:09:52   Verbose  |       Octopus Deploy: Calamari version 3.3.12+Branch.master.Sha.5c60c9a9a96c3991cf8f8f3c1f28fe131d8648a4
17:09:53   Verbose  |       Name                           Value
17:09:53   Verbose  |       ----                           -----
17:09:53   Verbose  |       PSVersion                      5.1.14328.1000
17:09:53   Verbose  |       PSEdition                      Desktop
17:09:53   Verbose  |       PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
17:09:53   Verbose  |       CLRVersion                     4.0.30319.42000
17:09:53   Verbose  |       BuildVersion                   10.0.14328.1000
17:09:53   Verbose  |       WSManStackVersion              3.0
17:09:53   Verbose  |       PSRemotingProtocolVersion      2.3
17:09:53   Verbose  |       SerializationVersion           <IP_ADDRESS>
17:09:53   Info     |       Windows PowerShell
17:09:53   Info     |       Copyright (C) 2016 Microsoft Corporation. All rights reserved.
17:09:54   Info     |       Oops, something went wrong.  Please report this bug with the details below.
17:09:54   Info     |       Report on GitHub: https://github.com/lzybkr/PSReadLine/issues/new
17:09:54   Info     |       -----------------------------------------------------------------------
17:09:54   Info     |       Last 0 Keys:
17:09:54   Info     |       Exception:
17:09:54   Info     |       System.IO.IOException: The handle is invalid.
17:09:54   Info     |       at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
17:09:54   Info     |       at System.Console.GetBufferInfo(Boolean throwOnNoConsole, Boolean& succeeded)
17:09:54   Info     |       at Microsoft.PowerShell.Internal.ConhostConsole.get_CursorLeft()
17:09:54   Info     |       at Microsoft.PowerShell.PSConsoleReadLine.Initialize(Runspace runspace, EngineIntrinsics engineIntrinsics)
17:09:54   Info     |       at Microsoft.PowerShell.PSConsoleReadLine.ReadLine(Runspace runspace, EngineIntrinsics engineIntrinsics)
17:09:54   Info     |       -----------------------------------------------------------------------
|


how to set the tab width?

First of all, thank you very much for your work！
I'm very like the theme, but i hava a problem , that's how can i set the tab width?
look at the img

please tell me，thanks！

@swinL Currently it's only possible via manual customization. See:

https://github.com/ihodev/sublime-boxy/wiki/Settings#advanced
https://www.sublimetext.com/docs/3/themes.html

for details. However I've started work on the new theme which will allow you to do this, so keep in touch, I'll be back when I'll have some news :wink:

@ihodev  thanks, Looking forward to your new work

DA UI beta is already released.
So now you can change width and min-width of the tabs:

Try it.
Choose Command Palette › DA UI: Theme Settings.
Find "Tab" settings section.
Change everything you need.


Fix deprecated location for default_store

Putting default_store in the [DEFAULT] section has been deprecated since Juno. We verified this was causing failures in starting the glance service with ceph or swift enabled. Moved to the correct location under [glance_store].

:+1:


--assign-identity flag being ignored when running aks create

Describe the bug
We have a pre-made managed identity in our resource group. We want to assign this managed identity during the cluster creation process. We are running the following command to create the AKS cluster:
az aks create --name $clusterName
    --resource-group $resourceGroup
    --subscription $subscription
    --enable-managed-identity
    --assign-identity /subscriptions/$subscription/resourcegroups/$resourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/$miName
    --node-vm-size Standard_D2_v3
    --node-count 1
    --location eastus2
    --generate-ssh-keys
    --load-balancer-sku basic

The issue being when we run the command the --assign-identity flag is ignored and the az cli attempts to create the cluster with the service principle anyway.
To Reproduce
Run the previous command.
Expected behavior
For the cluster to be created with the assigned managed identity and not attempt to create a new service principal.
Or at least some output notifying us why it's resorting to create the cluster with the service principal rather than the managed identity.
Environment summary
az:
{
"azure-cli": "2.15.1",
"azure-cli-core": "2.15.1",
"azure-cli-telemetry": "1.0.6",
"extensions": {
"aks-preview": "0.4.68"
}
}

aks

I think the issue can be found in the Azure Extension for AKS. The _ensure_aks_service_principal function is always called even if enabled_managed_identity is passed:
principal_obj = _ensure_aks_service_principal(cmd.cli_ctx,
                                                  service_principal=service_principal, client_secret=client_secret,
                                                  subscription_id=subscription_id, dns_name_prefix=dns_name_prefix,
                                                  location=location, name=name)

It works in some environments for me because it loads a cached version of the service principal from disk:
 principal_obj = load_acs_service_principal(subscription_id, file_name=file_name_aks)

It is not validating the client_secret of the service principal. It just wants it to be in the request body. I will try uninstalling the extensions and previews to see if this resolves the error.

This is working. Please upgrade to latest version of az cli 2.39.0


Update status endpoint to properly handle errors

What Are We Doing Here
Adding better error handling to the status endpoint.

This will make us sad once we want to add stuff to this endpoint, but for now it's good.


[BUG] Query with nested property that contains spaces causes invalid parameter name

Describe the bug
Issuing a query using custom Criteria through a CosmosTemplate in cases where the underlying document has a nested key with spaces results in an error because of the way the query parameter name is generated.
The library, as is, supports the execution of queries with nested properties, but only with the use of the dot notation (e.g. c.someCollection.someKey.value). When the nested property has spaces, though, this will break, which is expected (for instance, c.someCollection.key with spaces.value).
The docs here mention that in such cases the ["..."] notation should be used (or ['']), which I tried, but results in an error because of how the query parameter name is rendered.
Exception or Stack Trace
Getting java.lang.reflect.UndeclaredThrowableException when catching the exception , but after a bit of digging found that the underlying error is the following:
{
  "Errors": [
    "Invalid query. Specified parameter name '@someCollection['key with spaces']['value']1ac16075_dd7a_4eab_bb2d_287dabbd9b7a' is invalid. Parameter names should be in the format of symbol '@' followed by a valid identifier. E.g. @param1"
  ]
}

Which is part of
{
  "ClassName": "CosmosException",
  "userAgent": "azsdk-java-cosmos/4.13.0 MacOSX/10.15.7 JRE/11.0.5",
  "statusCode": 400,
  "resourceAddress": "...",
  "error": "{\"code\":\"BadRequest\",\"message\":\"Gateway Failed to Retrieve Query Plan: Message: {\\\"Errors\\\":[\\\"Invalid query. Specified parameter name '@someCollection['key with spaces']['value']1ac16075_dd7a_4eab_bb2d_287dabbd9b7a' is invalid. Parameter names should be in the format of symbol '@' followed by a valid identifier. E.g. @param1\\\"]}\\r\\nActivityId: 50810215-87ed-4b30-b684-d5764efdaf66, Microsoft.Azure.Documents.Common/2.14.0, Microsoft.Azure.Documents.Common/2.14.0, StatusCode: BadRequest\",\"additionalErrorInfo\":null}",
  "innerErrorMessage": "Gateway Failed to Retrieve Query Plan: Message: {\"Errors\":[\"Invalid query. Specified parameter name '@someCollection['key with spaces']['value']1ac16075_dd7a_4eab_bb2d_287dabbd9b7a' is invalid. Parameter names should be in the format of symbol '@' followed by a valid identifier. E.g. @param1\"]}\r\nActivityId: 50810215-87ed-4b30-b684-d5764efdaf66, Microsoft.Azure.Documents.Common/2.14.0, Microsoft.Azure.Documents.Common/2.14.0, StatusCode: BadRequest",
  "causeInfo": null,
  "responseHeaders": "{Transfer-Encoding=chunked, Strict-Transport-Security=max-age=31536000, Server=Microsoft-HTTPAPI/2.0, x-ms-gatewayversion=version=2.14.0, Date=Fri, 16 Jul 2021 16:04:10 GMT, x-ms-activity-id=50810215-87ed-4b30-b684-d5764efdaf66, Content-Type=application/json}",
  "requestHeaders": "[Accept=application/json, x-ms-cosmos-is-query-plan-request=True, x-ms-date=Fri, 16 Jul 2021 16:04:09 GMT, x-ms-cosmos-supported-query-features=Aggregate, CompositeAggregate, MultipleOrderBy, MultipleAggregates, OrderBy, OffsetAndLimit, Distinct, GroupBy, Top, NonValueAggregate, x-ms-cosmos-query-version=1.0, Content-Type=application/query+json]",
  "cosmosDiagnostics": {}
}

PS Redacted some info from the Cosmos Exception payload to not expose sensitive information. If the whole response is required along with the cosmos diagnostics let me know & I'll provide in a private channel.

To Reproduce

Set up a cosmos-managed database and a container which holds JSON documents that have nested keys with spaces/special characters - example shown in the Code Snippet section right below.
From a Java-based application that uses the azure-spring-data-cosmos-3.8.0 library, use Criteria to formulate and issue a query with an equality CriteriaType via a CosmosTemplate.
When the subject of the enforced Criteria contains square brackets to specify nested keys with spaces (["..."] or ['...']) then the query results in an error due to the illegal generated parameter name (library code).

Code Snippet

Data

Java class (constructors, accessors, mutators etc. excluded for brevity reasons)...
@Container(containerName = "...", ru = RECEIPT_RU_LIMIT, autoScale = true, timeToLive = RECEIPT_TIME_TO_LIVE)
public class CosmosReceiptDocument {

    @Id
    private String someId;

    @PartitionKey
    private String somePartitionKey;

    private Map<String, SomeValue> someCollection;

    public static class SomeValue {

        private String value;
    }
}

JSON{
    "someId": "document-id",
    "somePartitionKey": "document-partition-key",
    "someCollection": {
        "key with spaces": {
            "value": "some value"
        },
        "keyWithoutSpaces": {
            "value": "some other value"
        }
    }
}

Codepublic Slice<CosmosReceiptDocument> getReceiptsByCriteria() {

    String subject = String.format("%s['%s']['%s']",
            "someCollection", "key with spaces", "value");

    /*  Same behaviour as above
        String alternativeSubject = String.format("%s[\"%s\"][\"%s\"]",
                "someCollection", "key with spaces", "value"); */

    /*  This will work but only for nested keys that don't have spaces, otherwise breaks due to syntax error
        String subjectThatWorks = String.format("%s.%s.%s",
                "someCollection", "keyWithoutSpaces", "value"); */

    Criteria criteria = Criteria.getInstance(CriteriaType.IS_EQUAL, subject,
            Collections.singletonList("some value"), Part.IgnoreCaseType.NEVER);

    Pageable pageRequest = CosmosPageRequest.of(0, 20, null, Sort.unsorted());
    CosmosQuery query = new CosmosQuery(criteria).with(pageRequest);

    return cosmosTemplate.sliceQuery(query, CosmosReceiptDocument.class, Constants.CONSENT_RECEIPTS);
}

Expected behavior
When querying the container for documents that match the specified Criteria for the nested properties that may contain spaces I would expect that the query isn't flagged because of the generated parameter name. As this is based on the SQL API, my expectation is that this should work using the Java SDK just as it does from data explorer.
Screenshots
N/A
Setup (please complete the following information):

OS: macOS Catalina V 10.15.7 (19H114)
IDE: IntelliJ IDEA 2021.1.2 (Community Edition)
Library/Libraries: azure-spring-data-cosmos-3.8.0.jar

Additional context
I came across an older bug (has been resolved) that is similar here: issue 221
Information Checklist

[✅] Bug Description Added
[✅] Repro Steps Added
[✅] Setup information Added

@backwind1233 could you please follow up with @gogopavl?

I will be working with @gogopavl on this issue, assigning it to me.

@kushagraThapar issued a PR that should resolve this bug - https://github.com/Azure/azure-sdk-for-java/pull/23341

@gogopavl - thank you for your contribution, I will review it soon.


Ifc Test Changes

Okay, this is the set of tests I recommend using.  You'll have a couple of build errors (because you don't override a method for the return type), need to change one constructor (so that `of(year, month, day) can take leap day/year day), and then work all the failing tests (100+, although some of this is API changes, not actual problems in your code).
This is to bring how your tests look in line with existing efforts, and to make the API better behaved.

Actually, the correct answer was to make the line:
{InternationalFixedDate.of(5, 1, 1), LocalDate.of(5, 1, 1)},

This is because what I'm really testing at that point is year changeover, from 4 to 5, so making the start of year 4 isn't helpful.
That commit is old though - it's fixed in the last one ("Correct errors in test data/code").
I don't have time at the moment, but I'll work the change for leap-day later.

While I'll fully admit to not running the tests at the point I made those commits, it's a little... unusual to comment on old, superseded commits.  You never know, the problems may have been fixed in another one.
Like I did.
The whole point was to pass you a set of tests where any failures were significant (ie, something you needed to change in your implementation code, not the test code).  So _of course_ I ran the tests before submitting the PR, to make sure that any failures that resulted were significant.
While I'm not so arrogant as to think that what I gave you was completely without error (given I was handing you something that was failing anyways...and I actually did find more errors during the checks this time), I am confident (and arrogant) enough to think it's _significantly_ without error.
About get(DAY_OF_WEEK) (and I think you meant Thursday, not Friday, but...) -
that wasn't a mistake in the sense that it was an accident.  That choice was deliberate.
My read of java.time.DayOfWeek and java.time.temporal.ChronoField.DAY_OF_WEEK, coupled with the fact that Year Day and Leap Day aren't an actual day of week, was that it meant that Iso and Fixed weren't aligned in terms of days of the week, and that renumbering should probably take place.  After all, Iso Thursday only matches Fixed Thursday every 5~6 years (and even then, only for half the year...).  The days share the same name, but that's unimportant compared to the fact that they aren't really aligned.
Now, that's my interpretation.  I could be wrong here - my recommendation, if you still think they should be aligned is to ask the main Stephen for clarification, and then change/leave the relevant tests yourself.

Patches were applied manually, while files were changed, too.

Uh, I get you were applying patches manually.  What I can't figure out is why you'd bother.
You need to override with(TemporalAdjuster), so the return type matches the behavior-required implementation override of with(TemporalField, newValue).  You should also be overriding minus(...), for the same reason.
Changing all instances of date to fixed resulted in things being changed that shouldn't have.
Even ignoring the whole DAY_OF_WEEK thing (you'll need to convince me of your interpretation, or get owner approval), you're still failing some of the tests.
You also seem to be operating under a misconception.  I'm providing this file as a drop-in replacement, not as a list of suggestions.  Your current approach tests some things more often than they needed to be, and some things less often than they should have been (and some not at all, which is where you're still getting failures).  I changed the tests specifically to make it closer to the existing tests for other calendars, for two reasons:

To make it easier for reviewers to spot differences, making it easier to spot what's special about this calendar.
To help present a unified look to the library code.

I've resynced my code, fixed a couple more errors (that were easier to spot now that you've fixed some things), added one test (look for a TODO:, please), and reuploaded it.  If you can reopen this pull request, do so, or just pull the changes into your branch.  Work everything that isn't DAY_OF_WEEK (ALIGNED_DAY_OF_WEEK_IN_MONTH, etc, are not DAY_OF_WEEK), and then either convince me your interpretation of that value is correct (and change the tests yourself), or bring your code in line with my interpretation.

The reason for the manual patch application is that the PR cannot be automatically merged.
This is what it states:
We can’t automatically merge this pull request.
Use the command line to resolve conflicts before continuing.

And it states the same now that I reopened the PR.
The icon "Merge pull request" is grayed out, so the CLI is the only option.

Okay, ready for review.
Your test class was taken verbatim; 4 parts had to be changed.
I misinterpreted the DAY_OF_WEEK part - they are not week-days such as Monday, Tuesday etc, but instead "day 1 of the week", "day 2 of the week" etc.
Checked all the changes in my branch; how is your verdict ?
Thanks for your dedication and constructive criticism, must have been hard.

First, I need to apologize for some things:

I've been heading towards viewing some aspects of this more as a "need to be right", rather than actually making sure I am right.  I'm sorry I've been confrontational and bullheaded over some of this.
I'm sorry for passing a test file with more errors than there should have been (less than 10/10%, but still more than it should have been).  My hubris made me overlook some things.

Now then ...
I've resynced and updated my file again, and force-pushed so a simple merge pull should work.  Most of this was to bring some formatting and comments in line with other examples (I'm afraid my autoformatter got away from me when I gave you the original file).  I'm curious to know what your usual process is, because most of the command line results I'm aware of seem to work on the final file differences, rather than on individual commits.  About your comments:

I'm kicking myself over missing the .equals() problem, as the summary view I use displays it nicely.  I was getting too focused on failures.
You're correct about line 436
You're probably correct about line 439 (I mean, the one included in java.time doesn't, which means it was probably intended as an extreme upper-bound value, and not something specific, but it's reasonable to get a more concrete value).
I think we were both wrong about 440: The correct result should be ValueRange.of(-1, 0, 13, 13), as the upper bound of months for any year is always 13 (this keeps throwing me, too).
Proleptic year/invalid era tests have been split, meaning two different errors need to be thrown, one of which is ClassCastException.  (Side note, I know what you meant by that comment, but the specific wording seems a bit off: like that was the result you - potentially accidently - ended up with, so that's what you made the test look for, which would be somewhat backwards.  Instead of having deliberately made it throw that error).
Right about 1031/1032, nice catch.

This file was meant to be a replacement... at the time I created the pull request.  Once you started working the errors and updating your tests, it became less of an issue, especially sometime in the second round.  Once you finally caught on to what some of the tests were really looking for (like 1031/1032), you actually had some decent additions, including some comment tweaks.  I've gone back and put some of them back in, because I think they help make certain details more obvious.
I also added one test that's currently failing (besides updating 440), as there's a slight weakness in your current implementation.  You should be able to spot it.
Oh, why'd you change away from 'Leap Day'/'Year Day' in toString()?  I thought that was fine.  I didn't touch that as part of the formatting updates, but you might consider putting it back in
After this, the fun stuff starts - next level of review of the date/chronology code!
Oh, I've been using these settings for the Eclipse formatter for this project (somewhat different than what I'm used to, which is why it got away from me this time around - I forgot to change to these settings!), if you're able to make use of the file.

InternationalFixedDate#toString() is English-only, whereas the numeric current solution covers many more "Locale"s.
And the switch of separators ('-' -> '/') is to avoid 'N--1--1' or 'N-0-1-0-1'; the last one is when I let AbstractDate deal with it. Does not look appealing.  The new code now always uses two digits for month and day-of-month, except for Year Day.  that way, Leap and Year day stick out.
Of all the other descendants of AbstractDate, only DiscordianDate overrides #toString(), to distinguish St. Tib's Day from other dates.  How you given it some thought how to handle different Locales ?
(Jour de S. Tib, Dia de S Tib, St. Tib-Tag, S. Tib, ....).
In light of missing Locale support in toString() - I have no solution yet, it is a good thing to look as close as possible to what AbstractDate#toString() renders.  You sold me the idea of implementing the special days as -1 and 0, to be interpreted in the constructors - I originally rejected the idea.
Have been using Eclipse when it was VisualAge for Java; have been refocussing on IntelliJ IDEA now.
Haven't tweaked the code formatter yet, but I will next.
Thanks again for the review.

Oh no, I agree with the separator change, if you switch to numeric-only.
toString() (in general, not just for this project) is usually meant for debugging related output, not localized/formatted output.  For one thing, localization and formatting is usually orthogonal to the underlying type - dates shouldn't know about kanji (Chinese characters), and which one represents MONTH, after all.
In the base library, you'd probably normally instantiate java.time.format.DateTimeFormatterBuilder, then provide a custom map for any relevant fields. (although from the look of things, that might give problems with parsing year/leap day in this case...)

My wish is to pass an InternationalFixedDate to SimpleDateFormat and either using the JVM's current Locale or accepting a Locale, to then render it.  With a hack it works in Java 8.

...hack indeed, given SimpleDateFormat won't take any of the new date/time types, beyond its other inherent problems (like not being concurrent-access safe).  You'd have to convert to java.util.Date first, which at minimum would eat any non-hour offset (if you had one attached).

The hack I implemented is a lot simpler.
Say I wanted to support English Locales.
For each one of them, I have to provide a class FormatData_{LOCALE}.
So I invent a Locale en_ifc -> sun.text.resources.en.FormatData_en_ifc.
The class has to look like this:
public class FormatData_en_ifc extends ListResourceBundle {
    @Override
    protected Object[][] getContents() {
        return new Object[][] {
                { "NumberPatterns",
                        new String[] {
                                "#,##0.###;-#,##0.###", // decimal pattern
                                "\u00A4#,##0.00;-\u00A4#,##0.00", // currency pattern
                                "#,##0%" // percent pattern
                        }
                },
                { "DateTimePatternChars","GyMdkHmsSEDFwWahKzZ" },
                { "MonthNames",
                        new String[] { "January", "February", "March", "April", "May", "June", "Sol", "July", "August", "September", "October", "November", "December" } },
                { "MonthAbbreviations",
                        new String[] { "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Sol", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" } }

        };
    }
}

However, the solution is in crafting something along the lines of
   sun/util/resources/cldr/en/CalendarData_en_Dsrt_US.class

Yepp, undocumented, not to be messed with ...


Remove deprecated Task APIs

Per @bradrydzewski, in the bolt branch, the Task, TaskList and SetTask methods in the datastore are deprecated and can be probably be removed. We need to make sure we aren't still using those functions anywhere else in the code.

cc @oliveiradan

I already talked to @benschumacher and will start looking into this issue to get an idea about where these api's are being used (if/in case they still are) and replace them if that is the case.

@oliveiradan quick Go tip. You can try commenting out the function in the database.go file. This is where we define the database interface. If something in the codebase is using that function you will see a compiler error.

Great, Thanks!

I just tested this and was able to build the code with no problems, so I will go ahead and clean those up and then get a new PR created.


[Discussion] Support some (or maybe all?) non-integer values passed to theme.spacing()

N.B.: This issue is a continuation of the discussion in #29526, as requested by @siriwatknp and @oliviertassinari

Summary
Should we allow positive, non-integer values to be passed to theme.spacing()? And, if so, should we only allow "half-values" (e.g. 0.5, 1.5, 2.5)? Or should we allow all positive non-integer values (e.g. 0.05, 1.2, etc.)?

Original issue
In #29526, we addressed and resolved an issue (#29479) with non-integer values (e.g. 0.5, 1.2, etc.) being passed as parameters to theme.spacing(). Such values are invalid when spacing is an array, and their use in some MUI components was resulting in errors.
The fix was to replace all instances where MUI components were trying to pass decimal values to theme.spacing() with string interpolation and CSS calc().
So, something like this...
paddingLeft: theme.spacing(1.2),

...was changed to this:
paddingLeft: `calc(${theme.spacing(1)} * 1.2)`,

Current behavior
As per the documentation, spacing can be defined as:

a number

createTheme({
  spacing: 2,
});

a function

createTheme({
  spacing: (n) => `${0.25 * n}rem`,
});

or an array

createTheme({
  spacing: [0, 4, 8, 16, 32, 64, 128, ...],
});

If spacing is defined as a number, non-integer decimal values can be safely passed to theme.spacing() and work as expected. The number in question is a coefficient. If, for instance, this coefficient is K, theme.spacing(1.2) calculates to 1.2 × K. The same can more or less be said for spacing when it is defined as a custom function, as shown above.
If, however, spacing is defined as an array, the parameters passed to theme.spacing() must be valid array indexes. Non-integer numbers are not valid indexes. When spacing is an array, and decimal values are provided to theme.spacing(), the values are ignored and an error message is displayed:
MUI: The `theme.spacing` array type cannot be combined with non integer values.You should either use an integer value that can be used as index, or define the `theme.spacing` as a number.

The origin of this error message is another previous issue, #23187.

Suggested change
@siriwatknp suggested that, while the fix resolves the existing issue, it might make more sense to simply allow non-integer values to always be passed to theme.spacing(), even if spacing is an array. This would involve changing the logic in createSpacing.ts to do the calculation there, instead of forcing devs to write out the css calc() implementation each time.

2 solutions that I see

all of the components should never use theme.spacing(decimal) because we force the warning
remove the warning and fix createSpacing to support decimal if spacing array is specified.

option 1 will hurt us in the long term because we might miss it in other components and some people will open the same issues, so I favor option 2.

@oliviertassinari responded that non-integer parameters passed to theme.spacing() make sense for "half values" (e.g. 0.5, 1.5, 2.5), but not for any other values (e.g. 1.2, 2.35, 0.075)

👍 for supporting half values: e.g. 0.5, 1.5. It's very handy when you have to split the spacing in two between margin-top and margin-bottom. It's also easy to compute when spacing is an array, the logic can be: theme.spacing[value * 2] / 2.
👎 for supporting 1.2. I personally think that theme.spacing() could warn against (in all the cases). To me, it doesn't make sense. It's probably better for the developers to hard code the value or uses calc in this case.

I like the simplicity of the approach @oliviertassinari suggested (with regards to half values)

when spacing is an array, the logic can be: theme.spacing[value * 2] / 2.

It works as expected, but the results may be a little un-intuitive. Suppose spacing is defined as an array, like so:
createTheme({
  spacing: [0, 4, 8, 16, 32, 64, 128, 256],
});

Integer values passed to theme.spacing() are, effectively, array indexes. Therefore...

...theme.spacing(0) => theme.spacing[0] => 0
...theme.spacing(1) => theme.spacing[1] => 4
...theme.spacing(2) => theme.spacing[2] => 8
...theme.spacing(3) => theme.spacing[3] => 16

Now let's see what happens if we use the suggested formula for "half-values", namely: theme.spacing[value * 2] / 2

...theme.spacing(0.5) => theme.spacing[1] / 2 => 2
...theme.spacing(1.5) => theme.spacing[3] / 2 => 8
...theme.spacing(2.5) => theme.spacing[5] / 2 => 32
...theme.spacing(3.5) => theme.spacing[7] / 2 => 128

The specific use case mentioned makes a lot of sense.

It's very handy when you have to split the spacing in two between margin-top and margin-bottom.

Suppose some variable n determines the amount of margin or padding, which needs to be equally split between top and bottom. This approach allows us to easily do something like theme.spacing(n / 2) to get the split values. Whatever theme.spacing(n) would have yielded is simply split in half.
In other words, the following...
marginTop: ({ spacing }) => `calc(${spacing(7)} / 2)`,
marginBottom: ({ spacing }) => `calc(${spacing(7)} / 2)`,

...could instead simply become this:
marginTop: 3.5`,
marginBottom: 3.5`,

That said, it does seem a little strange that...

...theme.spacing(1.5) === theme.spacing(2)
...theme.spacing(2.5) > theme.spacing(3)
...theme.spacing(3.5) > theme.spacing(4)

I'm a little torn on this, but part of me thinks that theme.spacing(2.5), for instance, suggests a value that is "half-way" between theme.spacing(2), and theme.spacing(3). I wonder if this could be confusing to some devs. When spacing is defined as an array, I think of it as a "series of numbers", discrete points on a continuum. If I ask for a value at an "index" that is "between" the indexes of two neighboring points, why is the result not a value that is between its two nearest neighbors?

If we only allow positive integer values and positive "half-values", we will have to perform some kind of check and throw an error / warning when invalid values are passed in (in all cases, regardless of whether spacing is a number, function, or an array). This could be as simple as:
// Given spacing(value)...
if (Number.isInteger(value)) {
  // use current functionality...
}
if (Number.isInteger(value * 2)) {
  // use formula for half-values, i.e. spacing(value * 2) / 2
}
// warn of invalid value; must be an integer or half-value

I found this workaround that is good enough for me.
Until this problem is solved by MUI you can use this as well:
    /**
   * Due to a bug in MUI we have to use this function instead of the array like this:
   * spacing: [0, 4, 8, 16, 24, 32, 64, 128, 256, 512, 1024],
   *
   * Source:
   * https://github.com/mui/material-ui/issues/29677
   *
   * Reason:
   * Some components will use non-integer values for spacing and this breaks the spacing array.
   *
   * Solution:
   * Use a function instead of an array and calculate the spacing based on the factor
   *
   * Result:
   * theme.spacing(1)   // 4px
   * theme.spacing(1.5) // 6px
   * theme.spacing(2)   // 8px
   * theme.spacing(2.5) // 12px
   */
  spacing: (factor: number) => {
    const values = [0, 4, 8, 16, 24, 32, 64, 128, 256, 512, 1024, 2048];
    const index = Math.floor(factor);
    const currentSpace = values[index];
    const nextSpace = values[index + 1] || currentSpace * 2;
    const space = currentSpace + (nextSpace - currentSpace) * (factor - index);
    return `${space}px`;
  },

Any official update on this?


Documentation update: add "ChromeHeadless" to list of possible browsers

See: https://github.com/karma-runner/karma-chrome-launcher/pull/111#issuecomment-298700314.

thanks


maven slave v3.6 centos image has incorrect version of oc

This caught me out when I lost context on a maven slave; thought I was logged into a project but oc reported I was on the prior project. Thus I updated the v3.6 slave image with the correct oc version and it fixes the issue for me. Testing:
$ docker run -it openshift/jenkins-slave-maven-centos7:v3.6 bash
Using 64 bit Java since OPENSHIFT_JENKINS_JVM_ARCH is not set
bash-4.2$ oc version
oc v1.5.0+031cbe4
kubernetes v1.5.2+43a9be4
features: Basic-Auth GSSAPI Kerberos SPNEGO
bash-4.2$ ^C
bash-4.2$ exit

$ docker run -it openshift/jenkins-slave-maven-centos7:v3.6u1 bash
Using 64 bit Java since OPENSHIFT_JENKINS_JVM_ARCH is not set
bash-4.2$ oc version
oc v3.6.0+c4dd4cf
kubernetes v1.6.1+5115d708d7
features: Basic-Auth GSSAPI Kerberos SPNEGO
bash-4.2$

I did a pull on the image to see if it had been updated.

yeah, in the 3.6 timeframe we were manually managing the oc binary included in the images.  starting with 3.7 the images are built on top of the origin base image so they always include a matched oc binary.
Since the v3.5 oc binary is compatible w/ openshift v3.6, we aren't going to go back and publish a new v3.6 image to fix this (we generally don't backport fixes to origin releases).

This caught me out when I lost context on a maven slave; thought I was logged into a project but oc reported I was on the prior project. Thus I updated the v3.6 slave image with the correct oc version and it fixes the issue for me

What issue did you actually have?  If there is a legitimate problem w/ the v3.5 binary talking to your v3.6 cluster we might consider updating the image, but i haven't heard of any to date (and again for origin we'd more likely just encourage you to update to v3.7)

/cc @gabemontero

that's pretty weird and not sure how that would be caused by a v1.5 client talking to a 3.6 cluster, short of a straight up bug in 1.5.
anyway if you can move up to 3.7 i'd recommend that.  if it's really blocking you we can consider updating the v3.6 image but i'd rather avoid that.

(also would be interested to see your full Jenkinsfile)

Its no blocker; I created a Dockerfile to add the 3.6.0 client to the v3.6 image and tagged it as v3.6u1. We use our own internal docker registry hosted on jfrog artifactory and pull images from there. No big drama. But with the testing I have done, you need to stick to the oc client version for the version of openshift you are running, otherwise you will get some strange behaviour/incompatibilities.
Jenkinsfile is has quite a few steps. code checkout, deploy zookeeper, kafka and local dynamodb, then a  build config to perform multiple scala builds (and tests; hence the zookeeper/kafka/dynamodb to test against). That runs for master and PR's using the github organisation jenkins plugin. If its a master build, further build configs pull built artifacts out of the builder image and generate docker images. There is a custom build to generate an nginx gateway, then a oc login to a dev environment to reimport imagestreams so the freshly built images are deployed to dev via imagestream triggers. The first big builder could do with a volume; docker is horribly slow extending its filesystem and an external volume would make it much quicker (confirmed this using s2i and docker natively; a docker volume makes the build much faster). Could share the Jenkinsfile.

yeah i was interested to see the jenkinsfile just in case there was something obvious in there tripping up oc.
Anyway we agree about trying to align your oc client w/ your cluster, though there is supposed to be guaranteed N-1 compatibility (as long as you aren't trying to use new apis w/ an old client of course)
Since you have a workaround i'm going to close this.  Hopefully this problem becomes a non-issue as people move up to v3.7+

We are going live soon with an app and have multiple cluster across different data centers. Thus there is very little chance we will upgrade any time soon. So 3.6.0 it is.


'PosixPath' object has no attribute 'endswith'

Hi. First of all my congrats. Your work is awesome. I'm trying to use the package. I have latest version of keras (2.3.0) and 2.2.x version of Tensorflow. But when I try to run he code I got the following error:
  File "/home/rootdebian/.local/lib/python3.7/site-packages/tensorflow/python/keras/engine/network.py", line 1616, in _is_hdf5_filepath     return (filepath.endswith('.h5') or filepath.endswith('.keras') or AttributeError: 'PosixPath' object has no attribute 'endswith'
Wait for your answers. Thanks for reading.

I had the same problem, this is due to the loading of the weights that are in h5 format, it is because when using path the class is not text and therefore it does not have the "ends_with" attribute (which str have) because of this, the solution is to put
** self.loaded_model.load_weights (str (self.parent_path / "saved_model / model.h5")) **
@HugoJBello I don't have much idea of git fixes, but it worked for me.

Thank you very much @giaccomgl for the question and @naveranoc for the solution.
@naveranoc I implemented your solutions, it seems to me that you are right and there was a problem sometimes when loading the weight file. I created a new version in pypi.
Tell me if you still have any problems


The export-area-drawing needs to follow the width flag

resvg foo.svg foo-out.png --width=900 --export-area-drawing

The size of the currently(resvg 0.16.0) generated png is not 900px. I hope that it can always follow the width or height flag, then internally crop the transparent pixels and scale to fill to the specified size.

Yes, it scales first and then crops. It cannot be done backward.

Usually, it is quite common to generate screenshots of a specified size through resvg. Is there a way to achieve it?

Just don't use --export-area-drawing. It simply removes the transparency. And I don't know the real image size before rendering. For example, blur effect will expand the image size, but I don't know how much. It is hard to calculate and it is not implemented.

We have initially achieved post-cropping zooming here, but there are more special cases that need to be dealt with.
https://github.com/zimond/rusty-svg/blob/16815de84cb4b38bbc36b80a0ad6e0020543c068/src/lib.rs#L237


FYI: Ensure that relay always compiles before a build

This fixes an issue that I’d missed where buildkite/buildkite will run a build, this PR ensures that relay is always compiled out before a build runs.

Wow, does npm/yarn magically run “pre*” commands?

Yep, also “post”
On Sat, 13 Oct 2018 at 12:43 am, Samuel Cochran<EMAIL_ADDRESS>wrote:

Wow, does npm/yarn magically run “pre*” commands?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/buildkite/frontend/pull/625#issuecomment-429330050,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABGnAWOsdabVUORgJlZTdZ0BOYy5eQ9ks5ukJxrgaJpZM4XY-hy
.


Goto feed by name

Many times when I open newsboat I know exactly what feed I want to catch up on but that feed is buried with the others. For small url files there is the goto command but if that feed is not directly visible it can be hard to locate it.
Proposed solution: Add a feed search or an equivalent to the goto feature that jumps to the closest matching feed.

I did not realize that goto can take a substring as an argument when filing this! I guess this is another instance of "I should've searched the docs better!".

Gotta love issues that resolve themselves :)

I guess this is another instance of "I should've searched the docs better!".

It can also be seen as "our docs could be better". I think I know what to improve here, will make a PR in a moment. Thanks for raising the issue!


create_covariates  -- error checking

Need to add to this function to confirm that the desired covariates were actually generated.

complete


How much memory do I need to run the demo?

Hi, I'd like to run the demo on a 4090 with 24G VRAM, is that enough?

Hi, as we have two VLMs, the default setting will require around 28G memory. If you do need to run it on a single 4090, you might try to load and run the vqa model and visual search model separately.

Thanks! I enabled the load_8bit here: https://github.com/penghao-wu/vstar/blob/d10c0537b754ee14e33744c55649301e854aebd4/LLaVA/llava/model/builder.py#L26
Now it runs fine in my 24G memory.
Thanks for your awesome work and open source!


Increase the page size for array/dictionary editors to 50

With smaller arrays/dictionaries, this makes it possible to view all of an array/dictionary's items on a single page.
Larger values could be used, but make switching between node selections quite slow, especially on low-end CPUs. They could also be problematic with complex resource inspectors for arrays/dictionaries that contain Resources.
The change is trivially cherry-pickable to 3.2 and has been tested there.
This closes https://github.com/godotengine/godot-proposals/issues/2058.

Why not an editor setting? I know they are a bit bloated atm but this seems like a good one to have actually.

Why not an editor setting? I know they are a bit bloated atm but this seems like a good one to have actually.

@EricEzaM I added a setting for it, which you can configure between 10 and 100 (defaults to 50).

@EricEzaM I added a setting for it, which you can configure between 10 and 100 (defaults to 50).

I'm fine with making this configurable, but isn't 50 a lot? I'm not concerned about performance but about usability, if you have an exported array or dictionary and expand it, it will push all other node properties very far to the end of the scroll bar. I'm not sure that's better than the current experience to have a paged editor with 10 entries per page, which still lets you access other properties in the same/next "screen".

I'm fine with making this configurable, but isn't 50 a lot? I'm not concerned about performance but about usability, if you have an exported array or dictionary and expand it, it will push all other node properties very far to the end of the scroll bar. I'm not sure that's better than the current experience to have a paged editor with 10 entries per page, which still lets you access other properties in the same/next "screen".

I'm fine with making this configurable, but isn't 50 a lot? I'm not concerned about performance but about usability, if you have an exported array or dictionary and expand it, it will push all other node properties very far to the end of the scroll bar. I'm not sure that's better than the current experience to have a paged editor with 10 entries per page, which still lets you access other properties in the same/next "screen".

Discussed it with @reduz, we agree that 20 would be a better default value.
If you need to edit arrays with more than 20 items, chances are that using the inspector is not the best workflow and it would be better to edit them nicely formatted in GDScript or have them serialized in JSON or ConfigFile resources.

I've changed the default to 20 (it can still be increased up to 100 in the Editor Settings).

Thanks!

Cherry-picked for 3.2.4.


Closes #122 - split up unit and integration test runners and coverage

Use surefire for unit tests in main module.
Use failsafe for integration tests in main module.
Use separate JaCoCo report for unit tests.
Use separate JaCoCo report for integration tests.
Rework mutation test skippage annotation in main module.
Instruct JaCoCo to run on verify phase as well as test phase.
Implement codecov feature flags for integration and unit tests individually.
Skip running test runner at all for Manifold when on <jdk>(11,)</jdk> similar to what Spring does for <jdk>[,15)</jdk>
Rewrite parts of prepare-test-outputs-for-merge.sh to cope with new report locations.

Closes #122.

Codecov Report

Merging #217 (4b86d22) into main (e633882) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #217   +/-   ##
=======================================
  Coverage   67.68%   67.68%
=======================================
  Files          70       70
  Lines        2448     2448
  Branches      226      226
=======================================
  Hits         1657     1657
  Misses        723      723
  Partials       68       68

Spotted and reported https://github.com/fabriciorby/maven-surefire-junit5-tree-reporter/issues/29 as part of this PR, but this is not impacting builds currently.