Make CookieJar.filter_cookies() accept plain string parameter

What do these changes do?
If parameter passed to CookieJar.filter_cookies() is a string, the method fails.
Convert the request_url to expected URL object. If URL object is
passed as a parameter, everything still works as expected.
Documentation suggests that passing a raw string to filter_cookies should work, but as of 1.3.0 it does not.
Are there changes in behavior for the user?
It is now possible to pass a string as a parameter to filter_cookies() method. Passing a URL object still works.
Related issue number
#1636
Checklist

[x] I think the code is well written
[ ] Unit tests for the changes exist
[x] Documentation reflects the changes
[x] Add yourself to CONTRIBUTORS.txt

The format is <Name> <Surname>.
Please keep alphabetical order, the file is sorted by names.

[x] Add a new entry to CHANGES.rst

Choose any open position to avoid merge conflicts with other PRs.
Add a link to the issue you are fixing (if any) using #issue_number format at the end of changelog message. Use Pull Request number if there are no issues for PR or PR covers the issue only partially.

Not sure why the test failed on Python 3.6 on Travis, this had nothing to do with my PR.

thanks!


Redactions should preserve the notifications key on power levels

Backstory: Notification power levels were added after redactions and hashes were introduced. This results in  a protocol version bump being needed to change the redaction rules otherwise hashes would be wrong for servers, making the event fairly conflicted.

Apart from for symmetry with the other power_levels settings, why is it important that redactions do not redact notifications? It doesn't make any difference to the authorization of events in the room (unlike the other power_levels settings: arguably, notification permissions should have gone in a different event type.)

Because of similar reasons for https://github.com/matrix-org/matrix-doc/issues/1996#issuecomment-511238768
Let's keep the argument of convenience vs protocol in one place please.

(discussion now moved to #2176)


Release 4.10.0 rc12 custom

@paritshivani Please use the standard git commit and MR subject format.


Camera move + tiledmap + running mobile

I've tried make a game with tiledmap and camera following just like many examples. It worked beautifully in my pc. The problem is that the camera really doens't work when running mobile. Is there an easy way to fix it? If not, please do it soon as possible

This looks like a duplicate of this issue

Actually, the problem is not just lagging, but the camera completely stops. So I thought it would be good to open a new issue report

This is a different issue. My camera is in the top left corner to start

So do mine

Interesting. For me, on scroll, the fps drops to about 5. This occurs no matter where in the map the camera is. I'm going to try the same code against recent (but older) versions of Phaser to hopefully see when the regression took place.

I'm using phaser 2.4.4, android lollipop

Is your code using the WebGL renderer, or Canvas? I find that WebGL on mobile with tilemaps can have some slowdown. I think this is due to the way Phaser and PIXI.js cache tilemaps.

Hmmmm... I'm almost sure I was using WebGL. But I think Canvas it's not as fast as WebGl, specially when running with Cordova in a mobile device.

Closing this because it's subjective, with no code example to test against, and no test environment details provided.


Support building/running Foundation.UnitTests on OSX

Fixes OSX build errors
Makefile for easy build
Documentation on how to build+run/current failures

Fixes #633

//******************************************************************************

File seems like internal gtest stuff? If so, please add clang-format ignores here and try to not unduly reformat external code in case we ever upgrade our version or whatever.

Refers to: tests/frameworks/gtest/include/gtest-api.h:1 in eacd9d9. [](commit_id = eacd9d92b9b917fefeaea7451529678b6cf234da, deletion_comment = False)

:clock1:

:clock1:

Not a big fan of private_include, this needs a little bit more offline discussion.

:clock1:

:shipit:


Update Iotics API to v1.3.2

Updates IOTICS API to v1.3.2
Adds circles support

LGTM - see minor comments (+ what Andy said I think needs fixing)
I have not tested it against the unreleased circles.
The only other thing I'd say is that we should probably require min Python 3.10 for this (rather than 3.8) - but that would also require updating of the pipelines which target Python 3.8. Given it works for now and nyx SDK doesn't need it, it's probably not worth it.

Merging this now after discussion earlier today. Will not update the python for now from 3.8 but will keep in mind :+1:


Prisma Query Engine has a panic

Below is the bug description I saw from logs.
It seems to happen when I pull lots of data from postgres db.
And It happens intermittently.
Error loading stock data: GraphQL error: Invalid prisma.stock_data.findMany() invocation in /var/task/src/api/dist/services/stock_data/stock_data.js:14:28
Started http server This is a non-recoverable error which probably happens when the Prisma Query Engine has a panic.
Hi Prisma Team! My Prisma Client just crashed. This is the report:
Versions

Name
Version

Node
v12.18.2

OS
rhel-openssl-1.0.x

Prisma
2.3.0

Description
Started http server

Logs
A%0A%23%23+Logs%0A%60%60%60%0A2020-08-09T23%3A26%3A23.093Z+prisma-client+%7B%0A++engineConfig%3A+%7B%0A++++cwd%3A+%27%2Fvar%2Ftask%2Fsrc%2Fnode_modules%2F.prisma%2Fclient%27%2C%0A++++enableDebugLogs%3A+false%2C%0A++++enableEngineDebugMode%3A+undefined%2C%0A++++datamodelPath%3A+%27%2Fvar%2Ftask%2Fsrc%2Fnode_modules%2F.prisma%2Fclient%2Fschema.prisma%27%2C%0A++++prismaPath%3A+undefined%2C%0A++++engineEndpoint%3A+undefined%2C%0A++++generator%3A+%7B%0A++++++name%3A+%27client%27%2C%0A++++++provider%3A+%27prisma-client-js%27%2C%0A++++++output%3A+%27%2Fopt%2Fbuild%2Frepo%2Fnode_modules%2F%40prisma%2Fclient%27%2C%0A++++++binaryTargets%3A+%5BArray%5D%2C%0A++++++previewFeatures%3A+%5BArray%5D%2C%0A++++++config%3A+%7B%7D%0A++++%7D%2C%0A++++showColors%3A+false%2C%0A++++logLevel%3A+undefined%2C%0A++++logQueries%3A+undefined%2C%0A++++flags%3A+%5B%5D%2C%0A++++clientVersion%3A+%272.3.0%27%2C%0A++++enableExperimental%3A+%5B+%27aggregations%27+%5D%0A++%7D%0A%7D%0A2020-08-09T23%3A26%3A23.926Z+plusX+Execution+permissions+of+%2Fvar%2Ftask%2Fsrc%2Fnode_modules%2F.prisma%2Fclient%2Fquery-engine-rhel-openssl-1.0.x+are+fine%0A2020-08-09T23%3A26%3A24.162Z+prisma-client+Client+Version+2.3.0%0A2020-08-09T23%3A26%3A24.162Z+prisma-client+Engine+Version+e11114fa1ea826f9e7b4fa1ced34e78892fe8e0e%0A2020-08-09T23%3A26%3A24.305Z+prisma-client+Error%3A+Attempted+to+serialize+scalar+%27null%27+with+incompatible+type+%27String%27%0A++++at+NodeEngine.graphQLToJSError+%28%2Fvar%2Ftask%2Fsrc%2Fnode_modules%2F%40prisma%2Fclient%2Fruntime%2Findex.js%3A1%3A130698%29%0A++++at+%2Fvar%2Ftask%2Fsrc%2Fnode_modules%2F%40prisma%2Fclient%2Fruntime%2Findex.js%3A1%3A129258%0A++++at+processTicksAndRejections+%28internal%2Fprocess%2Ftask_queues.js%3A97%3A5%29%0A++++at+async+PrismaClientFetcher.request+%28%2Fvar%2Ftask%2Fsrc%2Fnode_modules%2F%40prisma%2Fclient%2Fruntime%2Findex.js%3A1%3A208913%29%0A2020-08-09T23%3A26%3A27.546Z+prisma-client+Error%3A+Attempted+to+serialize+scalar+%27null%27+with+incompatible+type+%27String%27%0A++++at+NodeEngine.graphQLToJSError+%28%2Fvar%2Ftask%2Fsrc%2Fnode_modules%2F%40prisma%2Fclient%2Fruntime%2Findex.js%3A1%3A130698%29%0A++++at+%2Fvar%2Ftask%2Fsrc%2Fnode_modules%2F%40prisma%2Fclient%2Fruntime%2Findex.js%3A1%3A129258%0A++++at+processTicksAndRejections+%28internal%2Fprocess%2Ftask_queues.js%3A97%3A5%29%0A++++at+async+PrismaClientFetcher.request+%28%2Fvar%2Ftask%2Fsrc%2Fnode_modules%2F%40prisma%2Fclient%2Fruntime%2Findex.js%3A1%3A208913%29%0A2020-08-09T23%3A31%3A32.124Z%2Bprisma-client%2BError%253A%2BStarted%2Bhttp%2Bserver%250A%250AThis%2Bis%2Ba%2Bnon-recoverable%2Berror%2Bwhich%2Bprobably%2Bhappens%2Bwhen%2Bthe%2BPrisma%2BQuery%2BEngine%2Bhas%2Ba%2Bpanic.%250A%250Ahttps%253A%252F%252Fgithub.com%252Fprisma%252Fprisma-client-js%252Fissues%252Fnew%253Fbody%253DHi%252BPrisma%252BTeam%252521%252BMy%252BPrisma%252BClient%252Bjust%252Bcrashed.%252BThis%252Bis%252Bthe%252Breport%25253A%25250A%252523%252523%252BVersions%25250A%25250A%25257C%252BName%252B%252B%252B%252B%252B%25257C%252BVersion%252B%252B%252B%252B%252B%252B%252B%252B%252B%252B%252B%252B%25257C%25250A%25257C----------%25257C--------------------%25257C%25250A%25257C%252BNode%252B%252B%252B%252B%252B%25257C%252Bv12.18.2%252B%252B%252B%252B%252B%252B%252B%252B%252B%252B%252B%25257C%252B%25250A%25257C%252BOS%252B%252B%252B%252B%252B%252B%252B%25257C%252Brhel-openssl-1.0.x%252B%25257C%25250A%25257C%252BPrisma%252B%252B%252B%25257C%252B2.3.0%252B%252B%252B%252B%252B%252B%252B%252B%252B%252B%252B%252B%252B%252B%25257C%25250A%25250A%252523%252BDescription%25250A%252560%252560%252560%25250AStarted%252Bhttp%252Bserver%25250A%252560%252560%252560%25250A%25250A%252523%252523%252BLogs%25250A%252560%252560%252560%25250A2020-08-09T23%25253A26%25253A23.093Z%252Bprisma-client%252B%25257B%25250A%252B%252BengineConfig%25253A%252B%25257B%25250A%252B%252B%252B%252Bcwd%25253A%252B%252527%25252Fvar%25252Ftask%25252Fsrc%25252Fnode_modules%25252F.prisma%25252Fclient%252527%25252C%25250A%252B%252B%252B%252BenableDebugLogs%25253A%252Bfalse%25252C%25250A%252B%252B%252B%252BenableEngineDebugMode%25253A%252Bundefined%25252C%25250A%252B%252B%252B%252BdatamodelPath%25253A%252B%252527%25252Fvar%25252Ftask%25252Fsrc%25252Fnode_modules%25252F.prisma%25252Fclient%25252Fschema.prisma%252527%25252C%25250A%252B%252B%252B%252BprismaPath%25253A%252Bundefined%25252C%25250A%252B%252B%252B%252BengineEndpoint%25253A%252Bundefined%25252C%25250A%252B%252B%252B%252Bgenerator%25253A%252B%25257B%25250A%252B%252B%252B%252B%252B%252Bname%25253A%252B%252527client%252527%25252C%25250A%252B%252B%252B%252B%252B%252Bprovider%25253A%252B%252527prisma-client-js%252527%25252C%25250A%252B%252B%252B%252B%252B%252Boutput%25253A%252B%252527%25252Fopt%25252Fbuild%25252Frepo%25252Fnode_modules%25252F%252540prisma%25252Fclient%252527%25252C%25250A%252B%252B%252B%252B%252B%252BbinaryTargets%25253A%252B%25255BArray%25255D%25252C%25250A%252B%252B%252B%252B%252B%252BpreviewFeatures%25253A%252B%25255BArray%25255D%25252C%25250A%252B%252B%252B%252B%252B%252Bconfig%25253A%252B%25257B%25257D%25250A%252B%252B%252B%252B%25257D%25252C%25250A%252B%252B%252B%252BshowColors%25253A%252Bfalse%25252C%25250A%252B%252B%252B%252BlogLevel%25253A%252Bundefined%25252C%25250A%252B%252B%252B%252BlogQueries%25253A%252Bundefined%25252C%25250A%252B%252B%252B%252Bflags%25253A%252B%25255B%25255D%25252C%25250A%252B%252B%252B%252BclientVersion%25253A%252B%2525272.3.0%252527%25252C%25250A%252B%252B%252B%252BenableExperimental%25253A%252B%25255B%252B%252527aggregations%252527%252B%25255D%25250A%252B%252B%25257D%25250A%25257D%25250A2020-08-09T23%25253A26%25253A23.926Z%252BplusX%252BExecution%252Bpermissions%252Bof%252B%25252Fvar%25252Ftask%25252Fsrc%25252Fnode_modules%25252F.prisma%25252Fclient%25252Fquery-engine-rhel-openssl-1.0.x%252Bare%252Bfine%25250A2020-08-09T23%25253A26%25253A24.162Z%252Bprisma-client%252BClient%252BVersion%252B2.3.0%25250A2020-08-09T23%25253A26%25253A24.162Z%252Bprisma-client%252BEngine%252BVersion%252Be11114fa1ea826f9e7b4fa1ced34e78892fe8e0e%25250A2020-08-09T23%25253A26%25253A24.305Z%252Bprisma-client%252BError%25253A%252BAttempted%252Bto%252Bserialize%252Bscalar%252B%252527null%252527%252Bwith%252Bincompatible%252Btype%252B%252527String%252527%25250A%252B%252B%252B%252Bat%252BNodeEngine.graphQLToJSError%252B%252528%25252Fvar%25252Ftask%25252Fsrc%25252Fnode_modules%25252F%252540prisma%25252Fclient%25252Fruntime%25252Findex.js%25253A1%25253A130698%252529%25250A%252B%252B%252B%252Bat%252B%25252Fvar%25252Ftask%25252Fsrc%25252Fnode_modules%25252F%252540prisma%25252Fclient%25252Fruntime%25252Findex.js%25253A1%25253A129258%25250A%252B%252B%252B%252Bat%252BprocessTicksAndRejections%252B%252528internal%25252Fprocess%25252Ftask_queues.js%25253A97%25253A5%252529%25250A%252B%252B%252B%252Bat%252Basync%252BPrismaClientFetcher.request%252B%252528%25252Fvar%25252Ftask%25252Fsrc%25252Fnode_modules%25252F%252540prisma%25252Fclient%25252Fruntime%25252Findex.js%25253A1%25253A208913%252529%25250A2020-08-09T23%25253A26%25253A27.546Z%252Bprisma-client%252BError%25253A%252BAttempted%252Bto%252Bserialize%252Bscalar%252B%252527null%252527%252Bwith%252Bincompatible%252Btype%252B%252527String%252527%25250A%252B%252B%252B%252Bat%252BNodeEngine.graphQLToJSError%252B%252528%25252Fvar%25252Ftask%25252Fsrc%25252Fnode_modules%25252F%252540prisma%25252Fclient%25252Fruntime%25252Findex.js%25253A1%25253A130698%252529%25250A%252B%252B%252B%252Bat%252B%25252Fvar%25252Ftask%25252Fsrc%25252Fnode_modules%25252F%252540prisma%25252Fclient%25252Fruntime%25252Findex.js%25253A1%25253A129258%25250A%252B%252B%252B%252Bat%252BprocessTicksAndRejections%252B%252528internal%25252Fprocess%25252Ftask_queues.js%25253A97%25253A5%252529%25250A%252B%252B%252B%252Bat%252Basync%252BPrismaClientFetcher.request%252B%252528%25252Fvar%25252Ftask%25252Fsrc%25252Fnode_modules%25252F%252540prisma%25252Fclient%25252Fruntime%25252Findex.js%25253A1%25253A208913%252529%25250A%252560%252560%252560%2526title%253DStarted%252Bhttp%252Bserver%2526template%253Dbug_report.md%250A%250AIf%2Byou%2Bwant%2Bthe%2BPrisma%2Bteam%2Bto%2Blook%2Binto%2Bit%252C%2Bplease%2Bopen%2Bthe%2Blink%2Babove%2B%25F0%259F%2599%258F%250A%250A%2B%2B%2B%2Bat%2BNodeEngine.handleRequestError%2B%2528%252Fvar%252Ftask%252Fsrc%252Fnode_modules%252F%2540prisma%252Fclient%252Fruntime%252Findex.js%253A1%253A115776%2529%250A%2B%2B%2B%2Bat%2Basync%2BPrismaClientFetcher.request%2B%2528%252Fvar%252Ftask%252Fsrc%252Fnode_modules%252F%2540prisma%252Fclient%252Fruntime%252Findex.js%253A1%253A208913%2529%250A%2560%2560%2560%26title%3DStarted%2Bhttp%2Bserver%26template%3Dbug_report.md%0A%0AIf+you+want+the+Prisma+team+to+look+into+it%2C+please+open+the+link+above+%F0%9F%99%8F%0A%0A++++at+NodeEngine.handleRequestError+%28%2Fvar%2Ftask%2Fsrc%2Fnode_modules%2F%40prisma%2Fclient%2Fruntime%2Findex.js%3A1%3A115776%29%0A++++at+async+PrismaClientFetcher.request+%28%2Fvar%2Ftask%2Fsrc%2Fnode_modules%2F%40prisma%2Fclient%2Fruntime%2Findex.js%3A1%3A208913%29%0A%60%60%60&title=Started+http+server&template=bug_report.md%20If%20you%20want%20the%20Prisma%20team%20to%20look%20into%20it,%20please%20open%20the%20link%20above%20%F0%9F%99%8F

Hello! Can you please provide a minimal reproduction for the above crash? Unfortunately the automatically collected information in the issue does not give us much to go with here - we will need a bit more information. What were you doing? Can you share the code and schema that was active?

Hello! we had this problem and solved it with:

a singleton class as connection manager to ensure just one prisma instance
remove disconnect() (we were using after any execution of prisma promise)

Are you using disconnect?

Closing due to inactivity


Kitt4SME Demo Cluster deployment

Not sure this is the right place to post this type of technical question: We’re the responsibles for the Open Call action TA08 AIGreenWaste.
We’re trying to install a demo Kitt4SME cluster following the instructions at the link
https://github.com/c0c0n3/kitt4sme/blob/master/poc/deployment/install.md
as suggested by Elena Minisci in view of the incoming technical meeting in mid-April.
Unfortunately, we are having problem in following the steps in the above page.
When arrived at the istioctl install step, this failed with a series of errors (please see the attached files).
Attached you’ll find:

provision history.sh with the list of commands executed up to the failed step

provision history.sh.txt

versions.txt the version of the installed components (docker, minikube, kubectl, istio)

versions.txt

istioctl install error.txt the log of the error

istioctl install error.txt
Could you tell us if we’re following all the steps right?
Manu thanks,

Hi, I'm Riccardo from GoatAI, AI4SWD
I had the same problem and I solved it installing exactly the same version described in the readme.md.
If I am correct you installed minikube via apt-install, you should install this one: https://github.com/kubernetes/minikube/releases/download/v1.15.1/minikube_1.15.1-0_amd64.deb
One more thing, to use kubectl you don''t have to install it, you have it already, just run "minikube kubectl" and not only "kubectl".
BUT, solving this one is not enough, that same line of code:
"istioctl install -f poc/deployment/manual/istio/demo-profile.yaml -y --verify"
doesn't work anyway xD
giving us:
Detected that your cluster does not support third party JWT authentication. Falling back to less secure first party JWT. See https://istio.io/v1.9/docs/ops/best-practices/security/#configure-third-party-service-account-tokens for details.
✔ Istio core installed
✘ Istiod encountered an error: failed to wait for resource: resources not ready after 5m0s: timed out waiting for the condition
Hope I helped you, and hope someone help will me/us on this :)
Bye

Thanks Riccardo: I confirm that by using the new version  my problem is solved.
“unfortunately” I’m not getting the other error you mentioned  (meaning, I can’t help with this), but instead this brought me up to almost the end of the tutorial steps.
Now, I’m stuck at the steps "argocd app create kitt4sme", where I got the following errors - when launching;
xdg-open http://$(minikube ip -p kitt4sme):8080
I get:
/usr/bin/xdg-open: 778: /usr/bin/xdg-open: www-browser: not found
/usr/bin/xdg-open: 778: /usr/bin/xdg-open: links2: not found
/usr/bin/xdg-open: 778: /usr/bin/xdg-open: elinks: not found
/usr/bin/xdg-open: 778: /usr/bin/xdg-open: links: not found
/usr/bin/xdg-open: 778: /usr/bin/xdg-open: lynx: not found
/usr/bin/xdg-open: 778: /usr/bin/xdg-open: w3m: not found
xdg-open: no method available for opening 'http://<IP_ADDRESS>:8080'
and the "argocd app create kitt4sme" instruction itself ends with the following FATAL error:
FATA[0017] rpc error: code = InvalidArgument desc = application spec is invalid: InvalidSpecError: repository not accessible: Get "https://github.com/c0c0n3/kitt4sme/info/refs?service=git-upload-pack": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

Finally found the solution to "my problem", just follow this other guide and all will work perfectly lol https://github.com/c0c0n3/kitt4sme.live/blob/main/docs/bootstrap.md

Thanks, Riccardo, I also followed the other guide and managed to install the microk8s cluster.
With one issue, though, since the guide mentions in the "Post-install steps" that "The only unhappy service should be Keycloak" which pod should show a CreateContainerConfigError. In my case the keycloak pod doesn't even appear in the list of the pods returned by "kubectl get pods --all-namespaces" command. I hope this doesn't mean I'm skipping some important step; I searched again through the guide but found no previous mention of keycloak...


[CMAKE] Modify pkgconfig install path

pkgconfig was being installed on the wrong path.
now, pkgconfig path is CMKAE_INSTALL_PREFIX/lib/pkgconfig

:memo: TAOS-CI Version: 1.5.20200925. Thank you for submitting PR #169. Please a submit 1commit/1PR (one commit per one PR) policy to get comments quickly from reviewers. Your PR must pass all verificiation processes of cibot before starting a review process from reviewers. If you are new member to join this project, please read manuals in documentation folder and wiki page. In order to monitor a progress status of your PR in more detail, visit http://ci.nnstreamer.ai/.

INFO: You can read if there are misspelled characters at our misspelling check report. Please read http://ci.nnstreamer.ai/nnstreamer-edge/ci/repo-workers/pr-checker/169-202307121407520.81353902816772-de89658a88d905007c0a58dea891909c3cc8ab9b/report/misspelling_result.txt.

:octocat: cibot: @songgot, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://ci.nnstreamer.ai/nnstreamer-edge/ci/repo-workers/pr-checker/169-202307121407520.81353902816772-de89658a88d905007c0a58dea891909c3cc8ab9b/.

INFO: You can read if there are misspelled characters at our misspelling check report. Please read http://ci.nnstreamer.ai/nnstreamer-edge/ci/repo-workers/pr-checker/169-202307121434390.7088770866394-5449b36328ed92b40c10d64c06154dfc6da8768c/report/misspelling_result.txt.

:octocat: cibot: @songgot, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://ci.nnstreamer.ai/nnstreamer-edge/ci/repo-workers/pr-checker/169-202307121434390.7088770866394-5449b36328ed92b40c10d64c06154dfc6da8768c/.

INFO: You can read if there are misspelled characters at our misspelling check report. Please read http://ci.nnstreamer.ai/nnstreamer-edge/ci/repo-workers/pr-checker/169-202307121458240.99977588653564-43d324baed28accac1bfc32142d86299e6e71110/report/misspelling_result.txt.

INFO: You can read if there are misspelled characters at our misspelling check report. Please read http://ci.nnstreamer.ai/nnstreamer-edge/ci/repo-workers/pr-checker/169-202307121500450.016513109207153-c330feb8f8ff7227912389e33f10e8667e80eb53/report/misspelling_result.txt.

:octocat: cibot: @songgot, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://ci.nnstreamer.ai/nnstreamer-edge/ci/repo-workers/pr-checker/169-202307121500450.016513109207153-c330feb8f8ff7227912389e33f10e8667e80eb53/.

INFO: You can read if there are misspelled characters at our misspelling check report. Please read http://ci.nnstreamer.ai/nnstreamer-edge/ci/repo-workers/pr-checker/169-202307121539300.83065104484558-c330feb8f8ff7227912389e33f10e8667e80eb53/report/misspelling_result.txt.

INFO: You can read if there are misspelled characters at our misspelling check report. Please read http://ci.nnstreamer.ai/nnstreamer-edge/ci/repo-workers/pr-checker/169-202307121808370.68113899230957-36d30b93d6aebee6f82042e0d3d6b3bf174b72a7/report/misspelling_result.txt.

:octocat: cibot: @songgot, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://ci.nnstreamer.ai/nnstreamer-edge/ci/repo-workers/pr-checker/169-202307121802360.57719588279724-7b59a794bf3aa2e6355976bf10f729dcf2e9c594/.

INFO: You can read if there are misspelled characters at our misspelling check report. Please read http://ci.nnstreamer.ai/nnstreamer-edge/ci/repo-workers/pr-checker/169-202307121809430.34503197669983-9a3be89d433ad9c4b491102c3d1000c496205f43/report/misspelling_result.txt.


fix: fix server side instance of file invocation

:tada: This PR is included in version 1.11.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Travis Trusty doesn't support apparmor

AppArmor is disabled in travis trusty, it means that all apparmor tests are skipped in travis.
It's fine for now, because I run the test myself, and they do pass on OS distro supporting AppArmor.
However, we may still want to track this issue, and we should be able to fix after we start testing in Kubernetes test infrastructure.

Ref https://github.com/kubernetes-incubator/cri-containerd/pull/267

Thanks for testing and tracking this!

@mikebrow Yeah, we'll be testing this on the ubuntu image and COS image used in Kubernetes test infra.

yeah, should probably move CI up to a later distro

I think we could close this one now. We already run node e2e in Kubernetes test infrastructure, and the images used there both have apparmor support.


Updated account experience URL  Notes

As per current design, if the MO specifies APPID, Account experience URL will not be displayed.

HI @smchet , thanks for the PR. I've merged it for you and the changes should be live later today.

Awesome, thanks @duncanmacmichael !


Extract data from Terms of References

Need to extract the data in a scalable manner from the ToRs to more easily parse and compare it.
The integrated Governance agenda provides a glance as to the level of coordination/tracking is required overall. To properly provide advice, will need more than a spreadsheet.

[ ] CIOEC
[ ] DG Comm
[ ] DMPC
[ ] ADMPC
[ ] DGPC
[ ] EARB
[ ] ARC
[ ] PPRC
[ ] CIPSC
[ ] PPOC
[ ] OCMC
[ ] CAB
[ ] SLF
[ ] TDAC
[ ] NUMCC
[ ] WHSC
[ ] TAWG
[ ] ITAM CB
[ ] CEWG
[ ] EDC
[ ] Exec ACAB

Extract and normalize data to compare apples to apples.


[ENG-266] Add percy snapshots to test collections.

Purpose
Add percy snapshots to test collection discover, submission and update views.
Summary of Changes
Added acceptance tests.
QA Notes
No QA is expected for this ticket.
Ticket
https://openscience.atlassian.net/browse/ENG-266
Reviewer Checklist

[ ] meets requirements
[ ] easy to understand
[ ] DRY
[ ] testable and includes test(s)
[ ] changes described in CHANGELOG.md

Pull Request Test Coverage Report for Build 3095

6 of 7 (85.71%)  changed or added relevant lines in 6 files are covered.
18 unchanged lines in 2 files lost coverage.
Overall coverage increased (+3.1%) to 75.718%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

lib/collections/addon/components/collections-submission/component.ts
0
1
0.0%

Files with Coverage Reduction
New Missed Lines
%

lib/collections/addon/components/collection-item-picker/component.ts
7
68.64%

lib/collections/addon/components/collections-submission/component.ts
11
70.0%

Totals

Change from base Build 3083:
3.1%

Covered Lines:
6799

Relevant Lines:
7907

💛  - Coveralls

Close in favor of #712


fix: dropdown render under the account items on chrome

This PR should close #664. Even though the solution is not the most exciting, I tried to do it using another kind of positioning but the issues still persist.
Regarding the tests, we already have tests that 2 wallets, but "playwright" just selects the HTML element. Unsure how to create a click event inside the dropdown.

@tibi77, please just add an empty changeset to this PR. changeset add --empty.

still getting that issue @luizstacio and did the changeset thing

@tibi77 thanks for the first contribution ⚡


JVM_EXTRA_OPTS

Created a new Unifi docker image on my Synology wont let me Save and Launch the Docker image because it keeps asking me to enter information for the Environment variables: JVM_EXTRA_OPTS and JVM_INIT_HEAP_SIZE
Leaving both variables values empty is not allowed. Removing them and start the docker image result in Docker container: Unifi stopped unexpectedly. error.
Filling JVM_INIT_HEAP_SIZE with 512M  also result in Docker container: Unifi stopped unexpectedly. error.

@goofball222 What must i fill in for JVM_EXTRA_OPTS? leaving it empty is excepted.

@sampl3x are you running this container on a Synology NAS?
I got the same errors (plus that the local ports seem to be taken). I think this is an error introduced in the latest Synology update.
When I run the container from the command line on my NAS, like noted in the documentation for this container, I have no problems (“sudo su -“ first to become root).

@lancer73 You are correct. DSM was updates and the Docker package i can see. So it has to do with one of those updates.
Fixed it by deleting the files in the directory /var/lib/docker/network/files

This is something specific to the way that Synology is handling Docker containers. I haven't been able to replicated this problem on a standard Linux host running the latest versions of Docker. I might be able to fix it on the container side by pulling those variables but I'd rather not impact functionality for others for an OS/device issue.

Hi guys,
I fixed the problem on my DSM by doing that :
JVM_EXTRA_OPTS = " " (1 space)
JVM_INIT_HEAP_SIZE = "512M"
Worked without any other problem ... but I sent a message to the Synology support team.

Closing, not a container issue.

For information, Synology replied me and they are saying :
a) Empty values have been blocked by the dev team
b) They can't provide any explanation regarding why they blocked them
c) If there is any security justification they will publish a press release
d) They can't confirm if they will allow empty values in the future, but the request has been submitted to the dev team.
May I ask you to check in your future containers that declaring an " " (space) value will work ? This will allow us to "fix" the problem whatever Synology is doing in the next update.
Thanks

When i'm adding a space the container starts also.
When i remove the JVM_EXTRA_OPTS then Docker on synology wont allow me tp run the  containter :(
When removing the option JVM_EXTRA_OPTS bij Goofball222 on his container would solve our problem.

When removing the option JVM_EXTRA_OPTS bij Goofball222 on his container would solve our problem.

He will not change his container for something 100% Synology related ... and this is normal. This is Synology which is not implementing Docker like is should ... not Goofball which is doing something wrong in his container ;)

Setting JVM_EXTRA_OPTS to a space will work and shouldn't break anything. I'm extremely hesitant to remove that ENV variable as it is there to allow fine-tuning adjustments to the JVM process inside the container to suit individual deployment needs.
Since it sounds like it can't be blank in the Synology Docker implementation JVM_INIT_HEAP_SIZE can be set to a reasonable number like 128M, 256M, or 512M depending on resources available on the host system. This affects the minimum amount of memory that the Java process inside the container allocates so setting it too high may waste resources.
I'll keep the issues with Synology and blank variables in mind when approving/making changes in the future.

Thanks ! Keep you inform if Synology is giving me any useful info ;)

Thank you Goofball222

Synology updated the Docker package to accept "empty" values.
Version 17.05.0-0366


Getting Error Message: Inconsistent column data: Conversion failed: premature end of input

Bug description
I have a simple schema:
datasource db {
  provider = "sqlite"
  url      = "file:./dev.db"
}

generator client {
  provider = "prisma-client-js"
}

model Action {
  ActionWithMultiplier ActionWithMultiplier[]
  lnr String @id
  createdAt         DateTime            @default(now())
  updatedAt         DateTime            @updatedAt
  name    String
}

model Schedule {
  id String @id @default(uuid())
  createdAt         DateTime            @default(now())
  updatedAt         DateTime            @updatedAt
}

model Mission {
  id String @id @default(uuid())
  actionWMs ActionWithMultiplier[]
  createdAt         DateTime            @default(now())
  updatedAt         DateTime            @updatedAt
}

model ActionWithMultiplier {
  id       String @id @default(uuid())
  quantity Int
  Action   Action @relation(fields: [actionLnr], references: [lnr])
  actionLnr String
  missionId String?
  mission  Mission? @relation(fields:[missionId], references: [id])
  createdAt         DateTime            @default(now())
  updatedAt         DateTime            @updatedAt
}

How to reproduce
import { PrismaClient } from "@prisma/client";
import { connect } from "node:http2";

const prisma = new PrismaClient();

async function main() {
  console.log("Los");
  const newMission = await prisma.mission.create({
    data: {},
  });

  console.log(newMission);

  let ret;

  ret = await prisma.actionWithMultiplier.create({
    data: {
      quantity: 1,
      Action: {
        connect: { lnr: "1" },
      },
      mission: { connect: { id: newMission.id } },
    },
  });

  console.log(ret);

  ret = await prisma.actionWithMultiplier.create({
    data: {
      quantity: 2,
      Action: {
        connect: { lnr: "2" },
      },
      mission: { connect: { id: newMission.id } },
    },
  });

  console.log(ret);

  ret = await prisma.mission.findMany({
    orderBy: { createdAt: "desc" },
    include: { actionWMs: true },
  });

  console.log("Mission with Actioms");

  console.log(ret);

  const action1 = ret[0].actionWMs[0];

  console.log("first action");

  console.log(action1);

  const newAction = { ...action1, quantity: 99 };

  console.log("new action");
  console.log(newAction);

  ret = await prisma.actionWithMultiplier.update({
    where: {
      id: newAction.id,
    },
    data: { quantity: newAction.quantity },
  });

  console.log("after Update");
  console.log(ret);

  console.log('Find all action')

  ret = await prisma.action.findMany({})

  console.log(ret);

}

main()
  .catch((e) => {
    throw e;
  })
  .finally(async () => {
    await prisma.$disconnect();
  });

The script run until the last step prisma.action.findMany({})
The following Error is thrown:
(node:92152) UnhandledPromiseRejectionWarning: Error:
Invalid `prisma.action.findMany()` invocation:

  Inconsistent column data: Conversion failed: premature end of input
    at cb (/home/holger/Documents/prisma-data-model-test/node_modules/@prisma/client/runtime/index.js:34774:17)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
(Use `node --trace-warnings ...` to show where the warning was created)
(node:92152) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:92152) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Expected behavior
Everything was compiled without error:
´yarn prisma generate´
´yarn prisma migrate dev´
I would expect a list of data or an Error in advance, If my schema is wrong.
Content of Action in database:
´

3
2021-03-23 21:42:24

Trinken

2
2021-03-23 21:42:18

Essen

1
2021-03-23 21:42:06

Singen

´
Prisma information

Environment & setup

OS: Linux holger-bugie-dev 5.4.0-67-generic #75-Ubuntu SMP Fri Feb 19 18:03:38 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Database: Sqlite
Node.js version: node v14.5.0
Prisma version:

prisma               : 2.19.0
@prisma/client       : 2.19.0
Current platform     : debian-openssl-1.1.x
Query Engine         : query-engine c1455d0b443d66b0d9db9bcb1bb9ee0d5bbc511d (at<EMAIL_ADDRESS>Migration Engine     : migration-engine-cli c1455d0b443d66b0d9db9bcb1bb9ee0d5bbc511d (at<EMAIL_ADDRESS>Introspection Engine : introspection-core c1455d0b443d66b0d9db9bcb1bb9ee0d5bbc511d (at<EMAIL_ADDRESS>Format Binary        : prisma-fmt c1455d0b443d66b0d9db9bcb1bb9ee0d5bbc511d (at<EMAIL_ADDRESS>Studio               : 0.358.0

I found the solution:
I have created the entries in Action manually. The field ´updatedAt ´ was empty. This causes the error.


[SQL Migration] Add additional checks for multiple database backups in same folder

A common top error is that backups for multiple databases are present in the same folder, which is not supported by MI / VM LRS. A change was added in https://github.com/microsoft/azuredatastudio/pull/21952 to allow the selection of individual folders in blob containers, but the occurrence of this error has not decreased significantly. This PR:

adds an info box which instructs users to place backups from multiple databases into separate folders

public facing documentation still needs to be updated

adds a check where, if migrating multiple databases at a time, each database backup location (combination of storage account, blob container, and folder name) should be unique, since this is not a normal scenario. The user sees a warning banner until each database has a unique backup location provided.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage increased (+0.001%) to 42.401%

Files with Coverage Reduction
New Missed Lines
%

extensions/notebook/src/dialog/configurePython/configurePathPage.ts
1
57.02%

Totals

Change from base Build<PHONE_NUMBER>:
0.001%

Covered Lines:
30869

Relevant Lines:
67520

💛  - Coveralls

Shouldn't we block moving forward if we know it will fail under this condition

Shouldn't we block moving forward if we know it will fail under this condition. Instead of a warning it's almost more apt to be an error

@austincraigbryan
hmm, yeah I guess so. My last PR (https://github.com/microsoft/azuredatastudio/pull/22410) I did as a warning because in that case you can't be 100% certain technically, but I guess in this case it should be safer. The only valid case I can think of is migrating the same database multiple times at once (in fact, like my screenshot), which is why I left it as non blocking, but that's about it. If that's it then is that good enough to call it a blocker?

Shouldn't we block moving forward if we know it will fail under this condition. Instead of a warning it's almost more apt to be an error

@austincraigbryan
hmm, yeah I guess so. My last PR (#22410) I did as a warning because in that case you can't be 100% certain technically, but I guess in this case it should be safer. The only valid case I can think of is migrating the same database multiple times at once (in fact, like my screenshot), which is why I left it as non blocking, but that's about it. If that's it then is that good enough to call it a blocker?

Hmm guess I would leave something like that up to a PM I'm not sure the validity of the scenario. Maybe David would have some input. I would be worried customers would just see they can go next once selecting their folders and move on without even paying attention

be sure not to block the ability to migrate the same database backups to multiple targets.


Update wireguard version

Bump to the latest version of golang.zx2c4.com/wireguard/wgctrl.

Background
The release process fails to update the submariner version in the submariner-operator and subctl repos due to a failure retrieving the wireguard dependency:
[19:20:10.103] [dir=submariner-operator; fn=_update_go_mod]$ GOPROXY=direct go get [github.com/submariner-io/submariner<EMAIL_ADDRESS>go: downloading [github.com/submariner-io/submariner](http://github.com/submariner-io/submariner) v0.14.0-m2
go: downloading [github.com/go-ping/ping](http://github.com/go-ping/ping) v0.0.0-20210506233800-ff8be3320020
go: downloading [github.com/vishvananda/netlink](http://github.com/vishvananda/netlink) v1.1.1-0.20210518155637-4cb3795f2ccb
go: downloading [golang.zx2c4.com/wireguard/wgctrl](http://golang.zx2c4.com/wireguard/wgctrl) v0.0.0-20211215182854-7a385b3431de
go: downloading [golang.zx2c4.com/wireguard](http://golang.zx2c4.com/wireguard) v0.0.0-20211129173154-2dd424e2d808
go: downloading [golang.org/x/sync](http://golang.org/x/sync) v0.0.0-20220722155255-886fb9371eb4
go: downloading [github.com/vishvananda/netns](http://github.com/vishvananda/netns) v0.0.0-20200728191858-db3c7e526aae
go: downloading [honnef.co/go/tools](http://honnef.co/go/tools) v0.2.2
go: downloading [github.com/mdlayher/genetlink](http://github.com/mdlayher/genetlink) v1.1.0
go: downloading [github.com/mdlayher/netlink](http://github.com/mdlayher/netlink) v1.4.2
go: downloading [github.com/josharian/native](http://github.com/josharian/native) v0.0.0-20200817173448-b6b71def0850
go: downloading [github.com/mdlayher/socket](http://github.com/mdlayher/socket) v0.0.0-20211102153432-57e3fa563ecb
go: downloading [github.com/BurntSushi/toml](http://github.com/BurntSushi/toml) v0.4.1
go: [golang.zx2c4.com/wireguard<EMAIL_ADDRESS>requires
	[golang.zx2c4.com/go118/netip@v0.0.0-20211111135330-a4a02eeacf9d](http://golang.zx2c4.com/go118/netip@v0.0.0-20211111135330-a4a02eeacf9d): unrecognized import path "[golang.zx2c4.com/go118/netip](http://golang.zx2c4.com/go118/netip)": reading https://golang.zx2c4.com/go118/netip?go-get=1: 404 Not Found

It's unclear why this happens during release and not when building submariner but the latest wireguard version doesn’t pull in golang.zx2c4.com/go118/netip so hopefully this will fix it. Either way, it's beneficial to keep third party libs up-to-date with latest versions.

Do we know why Dependabot didn't send this upgrade?

I'm not sure but where it's hosted on golang.zx2c4.com doesn't appear to be a "normal" github repo so I suspect Dependabot doesn't know how to handle it.

Dependabot doesn’t suggest Wireguard bumps because the dependency has never been tagged upstream; Dependabot copes fine with git repositories outside GH.

Dependabot doesn’t suggest Wireguard bumps because the dependency has never been tagged upstream;

The dependabot.yml  config does not seem to ignore the wireguard. Can you please elaborate where the dependency is not tagged?

Dependabot doesn’t suggest Wireguard bumps because the dependency has never been tagged upstream;

The dependabot.yml  config does not seem to ignore the wireguard. Can you please elaborate where the dependency is not tagged?

https://golang.zx2c4.com/wireguard/wgctrl leads to https://github.com/WireGuard/wgctrl-go which has no tags (https://github.com/WireGuard/wgctrl-go/tags). Dependabot only bumps to tags (or GH releases, which end up being the same thing in git).

Got it, thanks for the details.


[GOBBLIN-1130] Add API for adding proxy user to azkaban project

Dear Gobblin maintainers,
Please accept this PR. I understand that it will not be reviewed until I have checked off all the steps below!
JIRA

[ ] My PR addresses the following Gobblin JIRA issues and references them in the PR title. For example, "[GOBBLIN-XXX] My Gobblin PR"

https://issues.apache.org/jira/browse/GOBBLIN-1130

Description

[ ] Here are some details about my PR, including screenshots (if applicable):

Add method in AzkabanClient that adds given user as a proxy user in given azkaban project
Tests

[ ] My PR adds the following unit tests OR does not need testing for this extremely good reason:

Commits

[ ] My commits all reference JIRA issues in their subject lines, and I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "How to write a good git commit message":

Subject is separated from body by a blank line
Subject is limited to 50 characters
Subject does not end with a period
Subject uses the imperative mood ("add", not "adding")
Body wraps at 72 characters
Body explains "what" and "why", not "how"

@arjun4084346 please review

+1 LGTM

@sv2000 please merge


Imp: add merge action for branchs

What this PR does:
Which issue(s) this PR fixes:
Fixes #
You should pay attention to items below to ensure your pr passes our ci test
We do not merge pr with ci tests failed

[ ] All ut passed (run 'go test ./...' in project root)
[ ] After go-fmt ed , run 'go fmt project' using goland.
[ ] Golangci-lint passed, run 'sudo golangci-lint run' in project root.
[ ] After import formatted, (using imports-formatter to run 'imports-formatter .' in project root, to format your import blocks, mentioned in CONTRIBUTING.md above)
[ ] Your new-created file needs to have apache license at the top, like other existed file does.
[ ] All integration test passed. You can run integration test locally (with docker env). Clone our dubbo-go-samples project and replace the go.mod to your dubbo-go, and run 'sudo sh start_integration_test.sh' at root of samples project root. (M1 Slice is not Support)

Codecov Report

Merging #17 (e2608b4) into 3.0 (b79a016) will increase coverage by 0.03%.
The diff coverage is n/a.

:exclamation: Current head e2608b4 differs from pull request most recent head 58bd0d8. Consider uploading reports for the commit 58bd0d8 to get more accurate results

@@            Coverage Diff             @@
##              3.0      #17      +/-   ##
==========================================
+ Coverage   47.61%   47.64%   +0.03%
==========================================
  Files         262      262
  Lines       15098    15098
==========================================
+ Hits         7189     7194       +5
+ Misses       7123     7119       -4
+ Partials      786      785       -1

Impacted Files
Coverage Δ

...tocol/rest/server/server_impl/go_restful_server.go
44.82% <0.00%> (+3.44%)
:arrow_up:

filter/metrics/filter.go
100.00% <0.00%> (+15.00%)
:arrow_up:

Continue to review full report at Codecov.

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


Elastic Net

First implementation of elastic net regression, which encompasses Lasso and Ridge regression. Uses coordinate descent optimisation algorithm.
This contains PR #46 adapted to new datasets

Codecov Report

Merging #76 (b08eed2) into master (8e81a6d) will increase coverage by 0.77%.
The diff coverage is 75.00%.

@@            Coverage Diff             @@
##           master      #76      +/-   ##
==========================================
+ Coverage   54.03%   54.80%   +0.77%
==========================================
  Files          57       60       +3
  Lines        4053     4231     +178
==========================================
+ Hits         2190     2319     +129
- Misses       1863     1912      +49

Impacted Files
Coverage Δ

linfa-elasticnet/src/lib.rs
0.00% <0.00%> (ø)

src/dataset/mod.rs
93.33% <ø> (ø)

linfa-elasticnet/src/hyperparameters.rs
11.11% <11.11%> (ø)

linfa-elasticnet/src/algorithm.rs
89.03% <89.03%> (ø)

linfa-trees/src/decision_trees/algorithm.rs
52.12% <0.00%> (-1.55%)
:arrow_down:

...fa-clustering/src/appx_dbscan/counting_tree/mod.rs
46.37% <0.00%> (-1.45%)
:arrow_down:

linfa-linear/src/ols.rs
68.62% <0.00%> (-1.19%)
:arrow_down:

linfa-logistic/src/lib.rs
73.35% <0.00%> (-0.73%)
:arrow_down:

linfa-linear/src/glm.rs
49.07% <0.00%> (-0.47%)
:arrow_down:

...infa-clustering/src/appx_dbscan/cells_grid/cell.rs
47.95% <0.00%> (ø)

... and 6 more

Continue to review full report at Codecov.

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

Codecov Report

Merging #76 (b08eed2) into master (8e81a6d) will increase coverage by 0.77%.
The diff coverage is 75.00%.

@@            Coverage Diff             @@
##           master      #76      +/-   ##
==========================================
+ Coverage   54.03%   54.80%   +0.77%
==========================================
  Files          57       60       +3
  Lines        4053     4231     +178
==========================================
+ Hits         2190     2319     +129
- Misses       1863     1912      +49

Impacted Files
Coverage Δ

linfa-elasticnet/src/lib.rs
0.00% <0.00%> (ø)

src/dataset/mod.rs
93.33% <ø> (ø)

linfa-elasticnet/src/hyperparameters.rs
11.11% <11.11%> (ø)

linfa-elasticnet/src/algorithm.rs
89.03% <89.03%> (ø)

linfa-trees/src/decision_trees/algorithm.rs
52.12% <0.00%> (-1.55%)
:arrow_down:

...fa-clustering/src/appx_dbscan/counting_tree/mod.rs
46.37% <0.00%> (-1.45%)
:arrow_down:

linfa-linear/src/ols.rs
68.62% <0.00%> (-1.19%)
:arrow_down:

linfa-logistic/src/lib.rs
73.35% <0.00%> (-0.73%)
:arrow_down:

linfa-linear/src/glm.rs
49.07% <0.00%> (-0.47%)
:arrow_down:

...infa-clustering/src/appx_dbscan/cells_grid/cell.rs
47.95% <0.00%> (ø)

... and 6 more

Continue to review full report at Codecov.

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

Thanks for completing this! Great work 👏🏾

Thanks for completing this! Great work 👏🏾


Scala 2.12

Blocked by https://issues.apache.org/jira/browse/SPARK-14220

@gr211 https://github.com/amient/affinity/releases/tag/0.11.0


Replaced UEFI chapter numbers with function identifiers in the docs

This is because the chapter numbers can change often in the UEFI specification, while identifiers do not.
Also added error documentation and UEFI spec references to other BootServices functions.
Checklist

[x] Sensible git history (for example, squash "typo" or "fix" commits). See the Rewriting History guide for help.
[ ] Update the changelog (if necessary)

awesome, thanks for the contribution!


Do not stop on first JSP containing a compile error

It would be really helpful, if the compiler would not stop on the first JSP with compile errors, but continue until the last has been compiled---within the same maven module, of course.
If some users prefer the old way (stop on first compile error), an option like "jspc.failFast" should be introduced.
Additionally, a line showing some statistics would be really nice, like
total: 127 (JSP files) errors: 42 (JSP files)
Also see https://issues.apache.org/bugzilla/show_bug.cgi?id=53011

@akram @Lynorics would either of you be interested in updating #19 so this feature could be merged in?

Hey there! :wave:
Thanks for opening an issue with jspc-maven-plugin. :+1: :bowing_man:
At the moment, the jspc maven plugin does not have an active maintainer to process your request. :no_entry:
While the Jasig jspc maven plugin is without an active maintainer, we recommend the Apache Sling jspc maven plugin and the Jetty jspc maven plugin as alternatives that are actively maintained. :white_check_mark:
If you are interested in becoming a project maintainer, there is a uPortal-dev list post where you can register your interest. :email:
Thanks again for contributing to the  jspc-maven-plugin! :sparkles:


updated README with correct way to display AdMobInterstitial

I've updated the docs with the correct way to call AdMobIntersitial.requestAd

Hi @TarCode, thanks for your contribution. From the function signature I'd say the documented way should work, although I also can remember that I encountered issues with it before.
But if this happens with the interstitial, I expect the rewarded video to have the same issue.
However, a v2 of the library is currently being developed, which changes the API of requestAd() to return a promise instead of using a callback, which should avoid this problem altogether.
If you like you can check out the development here: https://github.com/sbugert/react-native-admob/pull/165, and try the alpha release.

Now that master tracks version 2 of this library I mark this resolved

Awesome!


Add validation to migstage reconcile loop

Add Conditions to MigStage Status field
Adds validation of MigPlan Ref

Derek and I talked about down the line refactoring the validation work to take in a generic interface since MigStage and MigMigration share so many fields. I figured that was lower priority so will come back to address this.

Issue to come back to refactoring validation code to have a common plan validation function: https://github.com/fusor/mig-controller/issues/50


changes to support conda-build 2.0's new config

I'm not sure you should merge this yet.  The biggest change that conda-build-all sees in conda-build 2.0 is the no-longer-global configuration.  This simplifies conda-build-all - you no longer need context managers to change and then revert the global state.
Quite a bit of this PR seems unnecessary to me, though.  If you want much greater flexibility, then plumbing the config through like I do here makes sense.  Otherwise, it seems like too much effort.
I am going to experiment with how much I can make conda-build 2 be backwards compatible here.  Conda-build-all can adapt this PR if you want to take advantage of the non-global config somehow, but otherwise it seems easy enough to have some global instance like there used to be, and people can use it, but they don't have to.

This is blocked by https://github.com/conda/conda/issues/3342, because you currently can't install conda-build without also installing the new conda.

I can't seem to kill the build.  I'm sorry.

Conda-build 2 builds should be available on defaults soon. When that happens, it will be easier to test this PR.
Sorry it isn't 100% backwards compatible. I tried, but the global state stuff was pretty hard to get right, and ultimately I gave up.

@pelson @jakirkham this should now be compatible with both conda-build 1.x and 2.0.  Please review and deploy as time allows.

Thanks @msarahan.
I wonder if it would be worthwhile to add conda-build versions to the CI matrix.

I have tested this with both conda-build 2.* and 1.* and both pass 👍 .
I'll submit a followup PR to test both in CI.
Thanks for doing this @msarahan. The non-global config is a huge boon and makes the conda-build-all codebase much neater - I hope that vindicates the hard work you have put into conda-build 2. 🎉

Thanks @pelson.  I'm glad that the work is paying off here.  The greater testing that it is facilitating will really pay off in future work (like the more flexible build customization stuff) - we can move forward with less concern about breaking unseen functionality.


Support new Figma typography variables in styles

Figma recently introduced typography variables during their framework event. These variables are exported accurately in the JSON, which is great. However, it's still necessary to use styles as they support additional type settings such as textCase and textDecoration, and act as a helpful container for multiple variables associated with a particular text style.
It's important to use the new typography variables in styles without resolving the aliases, so that variable modes can have an impact on styles. For instance, if font size variables are created with Desktop and Mobile modes, styles should reference those variables. This way, if a specific mode is selected, the style will adjust accordingly.
Current available typography variables are:
Font family
Font weight
Font size
Line height
Letter spacing
Paragraph spacing
Styles tokens should then be expanded to support paragraphSpacing as part of this enhancement.

@pws-pm thanks, I'll check it out next week 🙂

@pws-pm just published a new release. Added alias support for typography and effects


PROD-362 Ignore sentry error

Description
Error: Cannot destructure property 'address' of '(intermediate value)' as it is undefined. doesn't impact the user experience. It appears to be related to a browser extension, which is beyond our control. Ignoring this sentry error would be better option unless it starts causing any real issues.
What are the steps to test that this code is working?
Monitor sentry board for similar errors
Screen shots or recordings for UI changes
NA

Does it comes if user initiate the wallet connection but ends up cancelling it?

No, it triggers without any user interaction even before user click on the connect wallet button

Does it comes if user initiate the wallet connection but ends up cancelling it?

No, it triggers without any user interaction even before user click on the connect wallet button

It occurred around 1.1k for 7 users any thoughts why or which extension may be causing this issue.


Creating Project from Template Causes Application to Close

Downloaded Phaser Editor 2D All-in-One V3.30 for Windows 10 from official website. Unzipped and pressed the PhaserEditor2D.exe file. Application opens as expected. New Project and select a project template. Create new folder and Select Folder as project destination and the Application then closes. Trying to reopen Application with the PhaserEditor2D.exe file again results in a blank window showing for a brief amount of time and closing again. The only solution to open Application again is to remove the folder that was created for the project that has the template files copied into it.

Hi,
Please, can you try with this fix: http://updates.phasereditor2d.com/v3.30.0-fix-1/PhaserEditor2D-allInOne-3.30.0-windows-fix-4.zip
Also, please, try opening it from the CMD and show me here the output.
Thanks


Fix dry run endpoint when ClinVar returns an empty 204 response

This PR adds | fixes:

Fix #23

According to the ClinVar documentation, a successful dry run submission returns empty content ({}) and 204 code.

My code tries to return json data from this empty response and that's why the bug happens
How to test:

Try the dry run endpoint with a valid api key and submission object

Expected outcome:

The endpoint should now return 200 (success) with a message

Review:

[ ] Code approved by
[ ] Tests executed by
[ ] "Merge and deploy" approved by

This version is a:

[ ] MAJOR - when you make incompatible API changes
[ ] MINOR - when you add functionality in a backwards compatible manner
[x] PATCH - when you make backwards compatible bug fixes or documentation/instructions

Tested locally: 🆗

Codecov Report

Merging #24 (71c54a9) into main (db25514) will increase coverage by 1.78%.
The diff coverage is 96.49%.

@@            Coverage Diff             @@
##             main      #24      +/-   ##
==========================================
+ Coverage   93.86%   95.65%   +1.78%
==========================================
  Files           7        8       +1
  Lines         163      207      +44
==========================================
+ Hits          153      198      +45
+ Misses         10        9       -1

Flag
Coverage Δ

unittests
95.65% <96.49%> (+1.78%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

preClinVar/csv_parser.py
97.97% <92.30%> (ø)

preClinVar/main.py
89.09% <95.65%> (+5.30%)
:arrow_up:

preClinVar/build.py
100.00% <100.00%> (ø)

preClinVar/constants.py
100.00% <100.00%> (+100.00%)
:arrow_up:

preClinVar/demo/__init__.py
100.00% <100.00%> (ø)

tests/test_main.py
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


fix broken link for ${{Object}}

Hi,
In the summary, the link for ${{Object}} is broken!

TOC is generated automatically, so even if we fix it this time it'll be overridden in future. This PR is not the first one. Reasonable, but I have to close this, since it's a tilting at windmills.

Oh my bad I didn't knew about https://github.com/thlorenz/doctoc repository!


Don't set CloudEvents tracing extensions when tracing is disabled

Contributing to the Azure SDK
Please see our CONTRIBUTING.md if you are not familiar with contributing to this repository or have questions.
For specific information about pull request etiquette and best practices, see this section.

API change check
API changes are not detected in this pull request.


Base vs finetuned model perplexity

I've been fine-tuning on top of the alpaca dataset (e.g. resuming from the tleon/alpaca-lora-7b adapter weights) and in turn trying to debug largely low quality generations. While doing so, I'd been keeping track of approx perplexities as a sanity check, but have another but probably clearer confusion..
Here's the calculation. When I run this on 25k of the 50k+ samples in alpaca-cleaned (ofc I don't have the exact splits), I end up with a better score for the base model. Is my oversight here obvious? Thanks

python evaluate.py --base_model "decapoda-research/llama-7b-hf" --data_path "yahma/alpaca-cleaned" --batch_size 32 => 5.875
python evaluate.py --base_model "decapoda-research/llama-7b-hf" --lora_weights "tloen/alpaca-lora-7b" --data_path "yahma/alpaca-cleaned" => 7.339

I believe there is something wrong with the decapoda-research version of the base model. Have you tried this same command with "yahma/llama-7b-hf" as your base model instead? With the yahma version, I am getting a perplexity of around 2 for the fine-tuned version; have not compared that to just the base model yet though.


Question on the Role of Text Encoder in Bunny MLLM Architecture

Thanks for your impressive work! The idea of integrating a text encoder before the large language model caught my attention. Could you share the specific benefits this approach provides? Also, were any ablation studies performed to quantify the impact of this component on overall performance?

The text encoder in our architecture figure represents for the tokenizer of LLM.


Initial support of Objective-C.

See October's [llvm-dev] Is it possible to execute Objective-C code via LLVM JIT?
and
November's [llvm-dev] Is it possible to execute Objective-C code via LLVM JIT?.
See also similar 2012's thread: [LLVMdev] Running Objective-C in the JIT.
And StackOverflow placeholder: All selectors unrecognised when invoking Objective-C methods using the LLVM ExecutionEngine.

I have updated the description here. cc @AlexDenisov @JDevlieghere @Quolyk

I have made some progress on this and it is time to share a knowledge: LLVM JIT, Objective-C and Swift on macOS: knowledge dump.


Update README.md and add 's' to Resource

Added 's' to resource.
PR Summary

PR Checklist

[x] PR has a meaningful title
[x] Summarized changes
[x] Change is not breaking
[x] This PR is ready to merge and is not Work in Progress
Rule changes

[ ] Unit tests created/ updated
[ ] Rule documentation created/ updated
[ ] Link to a filed issue
[ ] Change log has been updated with change under unreleased section

Other code changes

[ ] Unit tests created/ updated
[ ] Link to a filed issue
[ ] Change log has been updated with change under unreleased section

@lukemurraynz Thanks for your contribution. All good.


clang-tidy: check casing on class names

Description: verify CamelCase for class names.
Risk Level: low
Testing: existing
Docs Changes: N/A
Release Notes: N/A
Signed-off-by: Derek Argueta<EMAIL_ADDRESS>

I might need to revisit this check another time - clang-tidying source/common/common/fmt.h in isolation has an issue with #include "absl/strings/string_view.h" because the bazel target is an envoy_basic_cc_library, a thin wrapper around native.cc_library which doesn't know of abseil. Trying to move it to an envoy_cc_library causes a circular dependency ¯_(ツ)_/¯
This isn't an effect of clang-tidy, just an issue in the build system that seems to have relied on transitive dependencies for getting abseil.

@derekargueta I think you may add abseil_strings deps to envoy_basic_cc_library, that shouldn't introduce circular dependency.


[BUGFIX] Fix links of installation documents

Coverage remained the same at 24.045% when pulling eebd574e32701c4189f48df2d56ca194f128bd8d on afoeder:master into 88970bb8fd7d1163c6686861539839dadcbeb027 on prooph:master.


Add setuptools for pkg_resources module missing

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 66.447%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1915

Relevant Lines:
2882

💛  - Coveralls


helm CLI not using credHelpers from DOCKER_CONFIG

Output of helm version:
version.BuildInfo{Version:"v3.15.3", GitCommit:"3bb50bbbdd9c946ba9989fbe4fb4104766302a64", GitTreeState:"clean", GoVersion:"go1.22.5"}

Output of kubectl version:
Client Version: v1.29.7
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.29.6-gke.1038001

Cloud Provider/Platform (AKS, GKE, Minikube etc.): Not applicable
The issue:
The only way I can get helm to use the gcloud credHelper defined in ~/.docker/config.json is by pointing to that file on the command line using the --registry-config option.
According to what I've read (both in the oras-go code and in 3rd-party documentation about helm and Docker credential helpers) this is meant to work by default.
$ cat ~/.docker/config.json
{
	"auths": {},
	"credsStore": "desktop",
	"credHelpers": {
		"us-central1-docker.pkg.dev": "gcloud"
	},
	"currentContext": "desktop-linux",
	"plugins": {},
	"features": {
		"hooks": "true"
	}
}

$ unset DOCKER_CONFIG
$ env | grep DOCKER_CONFIG
$ helm pull oci://us-central1-docker.pkg.dev/dnastack-container-store/helm-charts/collection-service --version=1.0-922-g486d1a9
Error: failed to authorize: failed to fetch oauth token: unexpected status from GET request to https://us-central1-docker.pkg.dev/v2/token?scope=repository%3Adnastack-container-store%2Fhelm-charts%2Fcollection-service%3Apull&service=us-central1-docker.pkg.dev: 401 Unauthorized

$ export DOCKER_CONFIG=$HOME/.docker/
$ env | grep DOCKER_CONFIG
DOCKER_CONFIG=/Users/dsjfuerth/.docker/
$ helm pull oci://us-central1-docker.pkg.dev/dnastack-container-store/helm-charts/collection-service --version=1.0-922-g486d1a9
Error: failed to authorize: failed to fetch oauth token: unexpected status from GET request to https://us-central1-docker.pkg.dev/v2/token?scope=repository%3Adnastack-container-store%2Fhelm-charts%2Fcollection-service%3Apull&service=us-central1-docker.pkg.dev: 401 Unauthorized

$ helm pull --registry-config=/Users/dsjfuerth/.docker/config.json oci://us-central1-docker.pkg.dev/dnastack-container-store/helm-charts/collection-service --version=1.0-922-g486d1a9
Pulled: us-central1-docker.pkg.dev/dnastack-container-store/helm-charts/collection-service:1.0-922-g486d1a9
Digest: sha256:5674146a135b5663bb2da2391e4e25f61f87b7628c195e28af34665852886259

Using ktrace on the scenarios that end in the 401 error, I was able to verify that the helm process did execute docker-credential-osxkeychain which is not in my config.json, but is the oras-go platform default credHelper on MacOS.

It works for me: helm pull will fail when I don't have the file (~/.docker/config.json), but when I create the file it works:
[builder@61fe81a773f0 ~]$ helm pull --version 0.1.0 oci://europe-north1-docker.pkg.dev/XXXXXXXXXXXX-cf3f4d7/schedin-docker-test/helm/dummy-chart
Error: failed to authorize: failed to fetch anonymous token: unexpected status from GET request to https://europe-north1-docker.pkg.dev/v2/token?scope=repository%3AXXXXXXXXXXXX-cf3f4d7%2Fschedin-docker-test%2Fhelm%2Fdummy-chart%3Apull&service=europe-north1-docker.pkg.dev: 403 Forbidden

[builder@61fe81a773f0 ~]$ mkdir -p ~/.docker
cat > ~/.docker/config.json  << 'EOF'
{
  "credHelpers": {
    "europe-north1-docker.pkg.dev": "gcloud"
  }
}
EOF
[builder@61fe81a773f0 ~]$ helm pull --version 0.1.0 oci://europe-north1-docker.pkg.dev/XXXXXXXXXXXX-cf3f4d7/schedin-docker-test/helm/dummy-chart
Pulled: europe-north1-docker.pkg.dev/XXXXXXXXXXXX-cf3f4d7/schedin-docker-test/helm/dummy-chart:0.1.0
Digest: sha256:ffa3feb2d1a169266de269764a43b5f608a628867f816e8d7fed4647384e6370
[builder@61fe81a773f0 ~]$ ls
dummy-chart  dummy-chart-0.1.0.tgz

[builder@61fe81a773f0 ~]$ helm version
version.BuildInfo{Version:"v3.13.3", GitCommit:"c8b948945e52abba22ff885446a1486cb5fd3474", GitTreeState:"clean", GoVersion:"go1.20.11"}

I also upgraded to helm version.BuildInfo{Version:"v3.15.3", GitCommit:"3bb50bbbdd9c946ba9989fbe4fb4104766302a64", GitTreeState:"clean", GoVersion:"go1.22.5"} and that also worked for me.
I tested this inside my custom build-container that don't have docker installed. My container has podman/skopeo installed, but those tools are probably not used by the above commands.

Thanks for checking on your side. Glad it's working for you :)
I infer from your mention of a build-container that you tested this in a Linux-like environment. Is that true? Have you tried it on MacOS at all?
This issue has been affecting an increasing number of people on my team (all on Mac laptops). At first, it worked fine for me, and was only broken for one teammate. Weeks later, it started affecting another teammate. I was third, and just this week another teammate has reported the same issue started for him.
We haven't been able to isolate the issue, but if anyone with access to MacOS could try reproducing this, it might help shed light on the issue.

(Note: I'm not part of the Helm project maintainers, I'm only a user).
Yes, I used a Linux container in my previous test. I now tried on a Mac Mini M2 I had:
coreu@coreu-mac-mini /tmp % helm create dummy-mac-chart
Creating dummy-mac-chart
coreu@coreu-mac-mini /tmp % helm package dummy-mac-chart --version 1.2
Successfully packaged chart and saved it to: /tmp/dummy-mac-chart-1.2.tgz

coreu@coreu-mac-mini /tmp % helm push dummy-mac-chart-1.2.tgz oci://europe-north1-docker.pkg.dev/XXXXXXXXXXXX-cf3f4d7/schedin-docker-test/helm
Error: failed to authorize: failed to fetch anonymous token: unexpected status from GET request to https://europe-north1-docker.pkg.dev/v2/token?scope=repository%3AXXXXXXXXXXXX-cf3f4d7%2Fschedin-docker-test%2Fhelm%2Fdummy-mac-chart%3Apull&scope=repository%3AXXXXXXXXXXXX-cf3f4d7%2Fschedin-docker-test%2Fhelm%2Fdummy-mac-chart%3Apull%2Cpush&service=europe-north1-docker.pkg.dev: 403 Forbidden

coreu@coreu-mac-mini /tmp % mkdir -p ~/.docker
cat > ~/.docker/config.json  << 'EOF'
{
  "credHelpers": {
    "europe-north1-docker.pkg.dev": "gcloud"
  }
}
EOF
coreu@coreu-mac-mini /tmp % helm push dummy-mac-chart-1.2.tgz oci://europe-north1-docker.pkg.dev/XXXXXXXXXXXX-cf3f4d7/schedin-docker-test/helm
Pushed: europe-north1-docker.pkg.dev/XXXXXXXXXXXX-cf3f4d7/schedin-docker-test/helm/dummy-mac-chart:1.2
Digest: sha256:5ef49daed67659607c55d557b70786507407a1def18de79710f9570542d8fb90

coreu@coreu-mac-mini /tmp % sw_vers

ProductName:            macOS
ProductVersion:         14.2
BuildVersion:           23C64

coreu@coreu-mac-mini /tmp % helm version
version.BuildInfo{Version:"v3.15.4", GitCommit:"fa9efb07d9d8debbb4306d72af76a383895aa8c4", GitTreeState:"clean", GoVersion:"go1.22.6"}

That is: when I create the ~/.docker/config.json with the credHelpers I can successfully push (but not without it) on a Mac.
I installed Helm via brew and gcloud from a tar.gz-file.
Perhaps there is some interaction with your "credsStore": "desktop",? Or some other environment variable? Perhaps you can create a new MacOS user and test if it works with a "clean" environment?

I suspect the underlying library (oras or docker, etc) has changed its behavior here. Helm doesn't directly read DOCKER_CONFIG itself. I agree, if it doesn't use standard docker configuration for registry configuration, it should (like other tools including docker itself do).

Thanks for trying on MacOS, @schedin. It sounds like docker auth is working for you the same as it did for me and my team up until recently.
I tried with a barebones ~/.docker/config.json:
{
	"credHelpers": {
		"us-central1-docker.pkg.dev": "gcloud"
	}
}

And I still get the same 401 error unless I include an explicit --registry-config=$HOME/.docker/config.json on the command line.

I'm having the same issue on Mac OS, helm v3.16.1
$ sw_vers
ProductName:            macOS
ProductVersion:         13.6.9
BuildVersion:           22G830
$ helm version
version.BuildInfo{Version:"v3.16.1", GitCommit:"5a5449dc42be07001fd5771d56429132984ab3ab", GitTreeState:"dirty", GoVersion:"go1.23.1"}

helm pull oci://<base_url>/<registry> --version ${VERSION} --untar --untardir ${CHART_DIR}
Error: failed to authorize: failed to fetch oauth token: unexpected status from GET request to https://<oauth_url>: 401 Unauthorized

If I add the --registry-config=$HOME/.docker/config.json (which contains a definition for the credentials helper for my registry) to the helm pull invocation, it works.


Backup path?

I see paths can be added with a state of up, backup, and down. I added a path in the backup state, thinking it would only pass traffic when the path in the up state became degraded. This does not seem to be the case though... the backup path seems to act just like the up path. Is this by design? Is there a way to have a backup path that only passe traffic when the path(s) in the up state are degraded?

Hi,
The backup mode was supported in 0.0.x.
Since 0.1.x this option is no longer available due to many changes in the code.
I was waiting for an issue to work on it :)

Awesome, thanks!

Great! :) waiting for the feature to come back! :) nice software! keep up the good work :)

I just commited the new backup code in mud -> https://github.com/angt/mud/commit/e56abf5eaaa90fd7a7b5d5019ce9fdc9871e10a1

This is an iperf3 with one 20mbit path and one 10mbit backup path.

Merged in master, confirmed for the next release.


Bug: modded structures and mobs of overworld spawn in aether

What happened?
Nothing game breaking really. I just noticed structures of the following mods spawn in the aether:

repurposed structures (e.g. witches hut and underground (overworld) bastion)
Mo' structures volcanic vents (this is a known bug of the mod, they also spawn in the end)
the graveyard (e.g. large graveyards, haunted houses, etc.)

Additionally, i've found mobs of the "better animals plus" mod spawning, e.g.:

butterflies
boars
As well as hostile mobs of "The Graveyard" mod (same as the one the structures originate from).

Also, not sure if related, but none of the three structures can be located via /locate. They all return "Could not find that structure nearby".
It can be replicated by installing the fabric mods:

The Graveyard
Mo' Structures
Repurposed Structures
And then simply visiting the aether.

Images of proof below:
better animals plus mobs:

graveyard:

volcanic vent:

underground bastion:

Mod Version
Beta 1.6.8
Fabric API Version
0.46.6
Relevant log output
No response
Other mods
https://drive.google.com/file/d/1r4I4QMsvz4-tNxpQaQd6B2l72oBO_mzq/view?usp=sharing
hope that download via google drive works...
it's ALL the mods in my modpack, most of them are probably not relevant.
Additional Information
No response

Oh sh*t… sorry about that! I must have overlooked it :)

You're all good. We appreciate the report :)


Nextcloud MySQL credentials changed to variable for the security paranoid.

What this PR does / why we need it:
Very small pull request to change the MySQL creds from a static string to variable that can be overridden by the user if desired. Whilst a minor security change, something I've been doing when exposing my Nextcloud instances to the internet as a potential damage limitation piece.
Default behavior remains as before, only affects implementation if overridden by the user.
Which issue (if any) this PR fixes:
None.
Fixes #
Any other useful info:

Thanks for the contribution! I like the idea, but you've (accidentally?)  changed the defaults which will break anyone with an existing install. If you can set the default values to what they were, I'll get this merged :+1:

Thanks and well spotted! You're right, copy paste error facepalm
That should all be back to default now, thanks for helping me out with it :)

Finally got this merged, thanks for the contribution!

Finally got this merged, thanks for the contribution!

More than happy to help, thanks for the project!

More than happy to help, thanks for the project!


Email Validation during registration blocks valid emails

Reproduction Steps:

Navigate to /register
Enter an email address that either:

has a domain with a 5 character long or longer TLD (e.g., user@example.online), or
has a username that uses the + character (e.g<EMAIL_ADDRESS>

Fill out the other fields, then click "Register."

Expected Result:
An email is sent and the "Please check your e-mail for verification link" message is shown onscreen.
Actual Result:
No email is sent, and a different message, "Invalid email address" is shown onscreen.

I believe the culprit is https://github.com/Yureien/YABin/blob/main/src/lib/server/validate.ts#L1:
const emailRegex = /^[\w-\.]+@([\w-]+\.)+[\w-]{2,4}$/g;

Some other valid addresses that are considered invalid (that someone might theoretically want to be able to register with, particularly if YABin is deployed on their own network) include:

username@localhost
<EMAIL_ADDRESS><EMAIL_ADDRESS>
There are also a ton of "valid" addresses that it does not allow, but that are so rare as to probably not worth accounting for, like "user<EMAIL_ADDRESS>Addressing the specific issues I ran into, with minimal changes, could be achieved with the following three character change (NOTE: The removal of the g flag is because the regex is stateful when it is set, and that is undesirable):
const emailRegex = /^[\w-+.]+@([\w-]+\.)+[\w-]{2,}$/;

Alternatively, here's a more complex regex that correctly handles more types of invalid addresses:
const emailRegex = /^([\w%+-]+\.)*[\w%+-]+@([A-Z0-9-]+\.)+[A-Z0-9-]{2,}$/i;

This doesn't validate the @[IP address ending in a single digit octet] or @localhost emails, but my understanding is those are extremely rare, anyway, and they're not validated by the current regex, anyway, so it isn't a regression. It correctly prohibits the username part from ending with a period and allows % in the username portion, which is technically allowed (but I've never seen it used). It also correctly prohibits underscores in the domain portion.
Yet another option would be to use an established library like validator, email-validator, isemail, etc.. It looks like the validator library is the most used, very configurable, and seems to be actively developed, but it also has a decent number of open issues related to email validation. It also provides several other validators that you don't need. The other two libraries haven't had a new version pushed in 5+ years, but they still get 500k downloads weekly. From my perspective, that's probably overkill.

Thank you very much! An email-validator library can be used but seems overkill. I'll see if those are lightweight enough to be used. In the meanwhile, I'll use your 2nd regex.


subtree-push nightly-2024-12-02

Bumping the toolchain version as part of a git subtree push
current toolchain (nightly-2024-09-10):

1.83.0-nightly (c2f74c3f9 2024-09-09)

latest toolchain (nightly-2024-12-02):

1.85.0-nightly (5e1440ae5 2024-12-01)

r? @calebcartwright
Here's the link to the Diff Check Job

There were formatting difference in the diff-check related to nightly formatting implemented in the compiler.

#![feature(generic_const_items)] d03d33865b3b3d19ce047ebb0b8ab96f3bafa06c:
#![feature(unsafe_fields)] b116480c2f317643d7a048583bd22e6c333ad672

#![feature(generic_const_items)] Changes d03d33865b3b3d19ce047ebb0b8ab96f3bafa06c

Details
Input
#![feature(generic_const_items)]

const GENERIC<N, const M: usize>: i32 = 0;

const WHERECLAUSE: i32 = 0
where
    i32:;

trait Foo {
    const GENERIC<N, const M: usize>: i32;

    const WHERECLAUSE: i32
    where
        i32:;
}

impl Foo for () {
    const GENERIC<N, const M: usize>: i32 = 0;

    const WHERECLAUSE: i32 = 0
    where
        i32:;
}

Output (master rustfmt)
Drops the generics.
#![feature(generic_const_items)]

const GENERIC: i32 = 0;

const WHERECLAUSE: i32 = 0;

trait Foo {
    const GENERIC: i32;

    const WHERECLAUSE: i32;
}

impl Foo for () {
    const GENERIC: i32 = 0;

    const WHERECLAUSE: i32 = 0;
}

Output (subtree-push-nightly-2024-12-02 rustfmt)
Output left unchanged.
#![feature(generic_const_items)]

const GENERIC<N, const M: usize>: i32 = 0;

const WHERECLAUSE: i32 = 0
where
    i32:;

trait Foo {
    const GENERIC<N, const M: usize>: i32;

    const WHERECLAUSE: i32
    where
        i32:;
}

impl Foo for () {
    const GENERIC<N, const M: usize>: i32 = 0;

    const WHERECLAUSE: i32 = 0
    where
        i32:;
}

#![feature(unsafe_fields)] Changes b116480c2f317643d7a048583bd22e6c333ad672

Details
Input
struct Foo {
    unsafe
    field: (),
}

enum Bar {
    Variant {
        unsafe
        field: (),
    },
}

union Baz {
    unsafe
    field: (),
}

Output (master rustfmt)
Outputs parse errors:
error: expected identifier, found keyword `unsafe`
 --> <stdin>:2:5
  |
1 | struct Foo {
  |        --- while parsing this struct
2 |     unsafe
  |     ^^^^^^ expected identifier, found keyword

error: expected identifier, found keyword `unsafe`
 --> <stdin>:8:9
  |
7 |     Variant {
  |     ------- while parsing this struct
8 |         unsafe
  |         ^^^^^^ expected identifier, found keyword

error: expected identifier, found keyword `unsafe`
  --> <stdin>:14:5
   |
13 | union Baz {
   |       --- while parsing this union
14 |     unsafe
   |     ^^^^^^ expected identifier, found keyword

output
Formats structs using unsafe fields as expected.
struct Foo {
    unsafe field: (),
}

enum Bar {
    Variant { unsafe field: () },
}

union Baz {
    unsafe field: (),
}


docs: update DataTable docs to reflect current state

Coverage remained the same at 88.895% when pulling 4f15f0fee856fe6e6450921a9e45c61fcc66050d on lbirch/data-table-docs into ed4fb38ceacc82c3b5de82ad3d0962de04dbb923 on master.

:tada: This PR is included in version 13.11.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Accept When Panel Does Not Come Up

So when I start typing I get these inline suggestions, but not sure how to accept them

Here is my config for lazyvim that I am using
return {
  "zbirenbaum/copilot.lua",
  cmd = "Copilot",
  build = ":Copilot auth",
  -- event = "InsertEnter",
  config = function()
    require("copilot").setup({
      panel = {
        enabled = true,
        auto_refresh = false,
        keymap = {
          jump_prev = "[[",
          jump_next = "]]",
          accept = "<CR>",
          refresh = "gr",
          open = "<M-CR>",
        },
        layout = {
          position = "bottom", -- | top | left | right
          ratio = 0.4,
        },
      },
      suggestion = {
        enabled = true,
        auto_trigger = true,
        debounce = 75,
        keymap = {
          accept = "<TAB>",
          accept_word = false,
          accept_line = false,
          next = "<M-]>",
          prev = "<M-[>",
          dismiss = "<C-]>",
        },
      },
      filetypes = {
        yaml = false,
        markdown = false,
        help = false,
        gitcommit = false,
        gitrebase = false,
        hgcommit = false,
        svn = false,
        cvs = false,
        ["."] = false,
      },
      copilot_node_command = "node", -- Node.js version must be > 16.x
      server_opts_overrides = {},
    })
  end,
}

Your <Tab> mapping might be overridden by some other plugin.
Run :verbose imap <Tab> to see what it's mapped to.
Either fix that, or use another mapping.

Ah, you are right, need to figure out what in lazy vim is using tab


Consider using georust docker images in ci

https://github.com/georust/docker-images
This might be more useful once we have proj integration

Note that these images include proj but not gdal


Prevent node from not advancing in case block was rejected during FV

@noescape00 can you post the link to the issue on the board?

@fassadlr not sure there is an item. This PR is a result of the investigation of @ianfrew 's logs

@noescape00 can you explain how this enables the CM to continue advancing? If there are 100 headers downloaded and it fails on one in the collateral, what will happen next?

If there are 100 headers downloaded and it fails on one in the collateral, what will happen next?

Peers that claim invalid chain will be banned.
In case we are talking about wrong clock we would expect a small ban of a few minutes. When the ban happens chain that has invalid block will be removed. Then when ban expires and we reconnect we will redownload the chain that has now became valid.

This relates to https://dev.azure.com/Stratisplatformuk/StratisBitcoinFullNode/_workitems/edit/4083

These changes has been tested by a community member and the fixes resolved his issue.

This is a change in consensus code can you elaborate on the tests and who is the community dev?
Also what exactly was the issue?

Syncing on Cirrus would hang roughly about 34 to 38 blocks from the tip because of this issue. The problem for whatever reason would not resolve after deleting the data folder and re-syncing from scratch. I had tested and confirmed this fix worked.


Clean up

A clean up is currently undergoing in development branch (v0.3) to facilitate development, maintenance and dissemination (and to finally merge the new "floating position/velocity/acceleration/torque" logic.

[x] Get a basic example (compiled out of the superbuild and of iDynTree source tree) to work
[x] Get the codyco-superbuild to build and work with v0.3 (check that all test pass)
[ ] Get the walkman superbuild to build and check that all tests are passing
[x] Restore the iDyn / iDynTree consistency checks, use them also for check urdf export.
[ ] Correctly compile and install useful tools:
[ ] urdf2dh
[ ] par2urdf
[ ] urdf_get_mass

Restored the iDyn/iDynTree consistency checks, there was a bug in assuming that the ft sensor frame was the one of parent link instead of the child link.

move all inclusions to .cpp files and use forward declarations
transform all intra-library header inclusions to use quotes instead of angular brackets
all intra-library inclusions should be "direct", i.e. #include "myHeader.h" vs #include "folder/myHeader.h"

@francesco-romano (not worth doing that for things in the yarp directory, ok for everything else).

@francesco-romano namespace of what? C++ namespace?

@traversaro yes (and also some folder restructuring).
e.g.
kdl_codyco => idyntree/core
anyway I saw you already did some work on regressors, etc..

Yes, most of the libraries are already in a namespace, we just need to appropriately change the name of the namespace.

Update: most of the headers now use forward declarations when possible.
All code in the library should be contained in the iDynTree namespace.
Using additional namespaces have been discarded for being to complex and to match the package structure of Matlab and Python bindings.
Legacy code ( former kdl_codyco, kdl_format_io) will not be updated because it will be deprecated by the pure-iDynTree (and thus with native bindings) implementations.


Using (real) keyboard in demo, Build improvements (as per email discussion)

This patch contains:

Build improvements as per our email discussion: DEBUG, no parallel build race condition, allow cross-compilation of demo.
Using (real) keyboard in demo.
Illustrating proper usage of hal_deinit in main.c.

Hi,
Is is possible to add SDL_deinit to monitor.c directly?

I just saw the related Pull request in lv_drivers and I see the full picture now.
So my question is: what is the advantage of the proposed solution to the current one? For me it seems more complicated because the user need to deal with driver related things and need to know SDL too. Currently it is hidden in monitor.c.

You are right, the solution is not perfect, and yes, I agree that it would be best if HAL initialization specifics (in this case SDL calls) were not in main.

However ... At present the user already has to "know SDL" because main.c includes SDL2.h and calls SDL functions such as SDL_CreateThread and SDL_Delay.

In this context, the proposed merge does not make the situation worse, and even slightly improves it, because:

it shows that board-level 'hardware' init calls (SDL_Init in this case) belong in hal_init;
it improves the code logic, because it moves the SDL initialization from monitor.c where it did not belong (because it is related to the entire SDL usage, not just the monitor);
it improves the code functionally because, now, if the user decided, inside hal_init to swap the order of calls, and initialize the mouse or the keyboard first, and then the monitor - we would end up using a non-initialized SDL :)

Seeing how we both agree that HAL initialization should not be in main I would like to propose the following (which would have been my next pull request :)  I just did not want to throw at you everything at once! )

Based on knowledge about the system and the build options that the user chooses, we will use a specific hal_init implementation. I think that an SDL2-based impl and a fbdev impl can be added by default.
Then, in main.c, where we currently have this:
	void hal_init(void)
	{
		<some HAL specific code, curently SDL2-based>
	}

	int main(void)
	{
		hal_init();
		...
	}

, we would have this:
	void hal_init(void);

	#if USE_FBDEV
	#include hal_init_fbdev.cc
	#else
	#include hal_init_SDL2.cc
	#endif

	int main(void)
	{
		hal_init();
		...
	}

This way main will be clean and equally structured for all implementations, and particular HAL init code will be kept in it's own place where users can examine it and use as example of their own implementation.
The above assumes SDL2 is the default and does not require the user to select it explicitly. If you want we can be strict and do this:
	#if USE_FBDEV
	#include hal_init_fbdev.cc
	#elif USE_SDL2
	#include hal_init_SDL2.cc
	#else
	#error "You need to specify your system HAL layer."
	#endif

I wanted to update this pull request but it seems I have created a new one which has all of the changes in this one + what I proposed in my previous comment...I am not sure how to correct this, hope it's not a huge problem, because the new pull request has all the code?  It's  just missing the comments/discussion above

Everything that's here is already in pull request 18. Closing.


Frases sin traducir

Your password has been reset.

A new verification link has been sent to your email address.


Issues with TypeScript

I have added like stated in docs this type definition:
declare module '*.html' {
  import Vue from 'vue';
  interface WithRender {
    <V extends Vue>(options: Vue.ComponentOptions<V>): Vue.ComponentOptions<V>
    <V extends typeof Vue>(component: V): V
  }
  const withRender: WithRender;
  export = withRender
}

But then, using an import with style definition fails because it doesn't ends with .html
import ViewRender from './home.html?style=./home.scss';

It works properly when using ./home.html only.
My current workaround is to add another wildcard module declaration with *.scss.
Any idea to enhance the library to avoid this workaround ? Note that a single wildcard is allowed in typescript module declaration.
I also have another issue: I need to place @Component before @ViewRender. If I use ordering from the docs (reverse), it fails with this error :
[Vue warn]: invalid template option:function (_exports) {
  var options = _exports
  if (typeof _exports === "function") options = _exports.options

  options.render = render
  options.staticRenderFns = staticRenderFns
  if (module.hot && api) {
    api.createRecord("data-v-1", options)
  }
  return _exports
}
(found in <App>)
warn @ vue.esm.js:558
./node_modules/vue/dist/vue.esm.js.Vue$3.$mount @ vue.esm.js:9195
init @ vue.esm.js:2892
createComponent @ vue.esm.js:4581
createElm @ vue.esm.js:4524
createChildren @ vue.esm.js:4649
createElm @ vue.esm.js:4557
patch @ vue.esm.js:5017
Vue._update @ vue.esm.js:2019
updateComponent @ vue.esm.js:2139
get @ vue.esm.js:2448
Watcher @ vue.esm.js:2431
mountComponent @ vue.esm.js:2143
./node_modules/vue/dist/vue.esm.js.Vue$3.$mount @ vue.esm.js:7178
./node_modules/vue/dist/vue.esm.js.Vue$3.$mount @ vue.esm.js:9224
Vue._init @ vue.esm.js:3710
Vue$3 @ vue.esm.js:3791
./src/index.ts @ index.ts:7
__webpack_require__ @ bootstrap 378744f…:659
fn @ bootstrap 378744f…:83
0 @ class-component-hooks.ts:8
__webpack_require__ @ bootstrap 378744f…:659
./node_modules/ansi-html/index.js.module.exports @ bootstrap 378744f…:708
(anonymous) @ bootstrap 378744f…:708
vue.esm.js:4657Uncaught TypeError: Cannot read property 'componentInstance' of null
    at isPatchable (vue.esm.js:4657)
    at initComponent (vue.esm.js:4602)
    at createComponent (vue.esm.js:4588)
    at createElm (vue.esm.js:4524)
    at createChildren (vue.esm.js:4649)
    at createElm (vue.esm.js:4557)
    at Vue$3.patch [as __patch__] (vue.esm.js:5017)
    at Vue$3.Vue._update (vue.esm.js:2019)
    at Vue$3.updateComponent (vue.esm.js:2139)
    at Watcher.get (vue.esm.js:2448)

My current workaround is to add another wildcard module declaration with *.scss.

I think there are no work around other than this and practically it just works.

I need to place @Component before @ViewRender

I'm afraid I could not reproduce this, can you share the reproducible code by github repository?

I'll create a repo with my template asap, currently it's only a hello world.

I have created a vue-cli template using this loader and TypeScript, but can't reproduce the issue finally. I must have something wrong before.
FYI, here's the template : https://github.com/Toilal/vue-ts-hmr-std-files

Here's another template which is a fork of official webpack template, replacing vue-loader with vue-template-loader.

Nice! I've added links to your templates in README :)


Reflecting Cross-site Scripting (XSS) Bug

Unsanitized input from the request body r.body flows into fmt.Fprintln, where it is used to render an HTML page returned to the user. This may result in a Reflected Cross-Site Scripting attack (XSS).
https://github.com/hyperledger/fabric/blob/f4ea5f79593000f278100654f530f2ca52194676/internal/configtxlator/rest/protolator_handlers.go#L50

An error is returned rather than unsanitized input.


Remove deprecated jQuery event dispatching

Fixes #10356
CC: @redmunds

This looks good on startup. But I selected a few different files, then switch to another project and see an exception:
 Uncaught TypeError: Cannot read property 'trigger' of undefined Pane.js:1125
(anonymous function) Pane.js:1124
Pane._reset MainViewManager.js:1385
(anonymous function) lodash.js:9
h lodash.js:23
St MainViewManager.js:480
_forEach PaneOrPanesMainViewManager.js:1379
_closeAll ProjectManager.js:836
_load ProjectProjectManager.js:985
(anonymous function) jquery-2.1.1.min.js:2
 j jquery-2.1.1.min.js:2
k.add ProjectManager.js:982
open Projectmain.js:287
(anonymous function) jquery-2.1.1.min.js:3
n.event.dispatch jquery-2.1.1.min.js:3

Also seeing 23 of 54 Main View unit tests fail.

Done with initial review.

@redmunds fixed instances of trigger inside a callbacks.

Merging.


Use max_methods and improve inferability

use @max_methods for performance insensitive modules
try to clean up line axis code and make it more inferable and use less double updates

Compile Times benchmark
Note, that these numbers may fluctuate on the CI servers, so take them with a grain of salt.
using time
master:  10.83 < 10.99 > 11.14, 0.10+-
pr:      9.38 < 9.44 > 9.55, 0.05+-
speedup: 1.15 < 1.16 > 1.18, 0.01+-
median:  -14.18% => improvement

This PR improves the using time.
ttfp time
master   27.16 < 27.26 > 27.50, 0.13+-
pr       27.69 < 27.83 > 28.20, 0.17+-
speedup: 0.97 < 0.98 > 0.99, 0.01+-
median:  +2.09% => invariant

This PR does not change the ttfp time.

@IanButterworth, you may want to check this PR out, as I turned quite a lot of observables into "change observables" while at it...
I don't have a benchmark setup right now, so not 100% sure if I hit the right observables and how much it makes a difference.

Does max_methods just shift compile time to run time? It kinda seems that way from the benchmarks

It kinda seems that way from the benchmarks

What benchmarks? We don't have run time benchmarks and both using + ttfp times are an improvement

Does max_methods just shift compile time to run time

Depends on the code, fully typed + inferable code shouldn't change. Only code which calls functions, where the arguments aren't fully inferable may get slower runtime dispatch.

Iirc the first compile time benchmark I saw here had around -15% on using and maybe 1% more or less on ttfp. With all the other changes now I don't know what's actually improving things. If the ttfp improvements are mostly from change observables it might not be worth having the experimental stuff. Especially since "experimental" hints that it may break soon.

specially since "experimental" hints that it may break soon.

It was regarded as a bad move to name the module Experimental, because in hindsight, it wasn't really meant like that... So I think we can safely us it for now.
Some more detailed benchmarks:

branch
using
ttfp
runtime

this
4.8
14
19.8, 3.5mb

this, no max_method
5.6
14
19.8ms, 3.5mb

master
5.7
15.2
21ms, 3.68 MiB

I think this shows nicely, that max_methods gives us significant less using times, without influencing ttfp or runtime, while the net improvement of the other changes are pretty nice on top.

Oh I thought ttfp would include using time as well. So then this is really just a straight up improvement