[1.12-rc] docker should have a way to pull/update service images

It's currently not possible to force updating a service's image, for example, if a service uses nginx:1.11.1-alpine, and an updated version is available for that tag, it's not possible to force pulling the latest version.
Related; when deploying a service, we want to be sure that each node uses the exact same version of the image.
We briefly discussed this yesterday, and are thinking of having Docker determine the sha256/digest of the specified image, and use that to deploy the service. When updating a service, the sha256/digest of the image is checked again, to know if an updated version is available and should be pulled.
/cc @mgoelzer @aluzzardi @tonistiigi @tiborvass

We briefly discussed this yesterday, and are thinking of having Docker determine the sha256/digest of the specified image, and use that to deploy the service. When updating a service, the sha256/digest of the image is checked again, to know if an updated version is available and should be pulled.

If registry supports schema2 we should add the image ID to the service spec as well. This will remove unneeded pulls when image was pushed again or moved between registries.
For better error reporting, maybe we should also force it to offline images as well. So if we can't pull the manifest on the current manager node, there is a check to see if the image exists on this same node. If it exists we fix it to a specific image ID, if not then service creation will fail.

If registry supports schema2 we should add the image ID to the service spec as well. This will remove unneeded pulls when image was pushed again or moved between registries.

We already have digests to support this. We should actually use them.
The bug here is that auto-pull wasn't added into the exec/container implementation integrated with the daemon.

@thaJeztah Could you clarify?
Looking at the code, we should already be auto-pulling on task execution. Is the problem that you, as a user, have no way to forcing a re-pull to ensure the latest image?
You can force this by scaling down, then up. That will force all the tasks to be redistributed, pulling the new image.

Is the problem that you, as a user, have no way to forcing a re-pull to ensure the latest image?

That's the primary issue; scaling down, then up feels like a really hacky way to ensure I get the latest image, also (I think) only the instances that were replaced will actually be updated, unless I scale down to zero.
The other discussion (but perhaps I should open that as a separate one), that, without using digest, there's no guarantee that all my replicas run the same version of an image. For example, docker service create --name foobar nginx:123 then, after a while docker service scale foobar=5, then the newly created replicas may be running on a different version than the old ones.

The other discussion (but perhaps I should open that as a separate one), that, without using digest, there's no guarantee that all my replicas run the same version of an image. For example, docker service create --name foobar nginx:123 then, after a while docker service scale foobar=5, then the newly created replicas may be running on a different version than the old ones.

That is the whole point of digests. They provide this guarantee, unless you don't change your tags. If you change the value of your tags, you don't get any guarantee that instances across nodes are running the same thing.

@thaJeztah @stevvooe i'm confused. What about service update --image foo ? That will force a reevaluation of foo, resolving it on manager to a digest, and then all workers have the newly resolved digest. Best of both worlds everyone is happy.

@tiborvass looks like service update --image foo doesn't trigger a pull;
/# docker service create --name bla nginx
59mh7b6i8mamagr1kb1r93led

docker service ls
ID            NAME  REPLICAS  IMAGE  COMMAND
59mh7b6i8mam  bla   1/1       nginx
/ # docker service update --image nginx bla
bla
/ # docker service ls
ID            NAME  REPLICAS  IMAGE  COMMAND
59mh7b6i8mam  bla   1/1       nginx

I think the issue is that no changes are detected, so it doesn't re-deploy the service. These are the daemon logs when running the docker service update;
DEBU[0071] Calling GET /v1.24/services/bla
DEBU[0071] Calling POST /v1.24/services/59mh7b6i8mamagr1kb1r93led/update?version=12
DEBU[0071] form data: {"EndpointSpec":{"Mode":"vip"},"Mode":{"Replicated":{"Replicas":1}},"Name":"bla","TaskTemplate":{"ContainerSpec":{"Image":"nginx"},"Placement":{},"Resources":{"Limits":{},"Reservations":{}},"RestartPolicy":{"Condition":"any","MaxAttempts":0}},"UpdateConfig":{}}
DEBU[0080] 11ce7aed4932: Initiating bulk sync with nodes []

@aaronlehmann @stevvooe wouldn't you consider that as a bug?

@tiborvass Nothing actually changes in the configuration, so no updates are made.
There are two things we should look at here:

Let's use a digest from the client side to set the image name. That will ensure the updates are really updates. We've discussed this and I think this is the right way to go.
We should also have a way to force a redeploy. This could be done with a counter or random field. If you set it another value, it will force a redeploy of the whole task set without any actual changes. I think this will have general applicability for debugging and other undetectable changes. cc @aaronlehmann
The output should make it clear whether or not there will be updates based on the changes.

Let me know what you think and I can start filing bugs.

We are conflating two issues here. I consider this issue to be resolved by:

keeping current behavior of always pulling on service create
changing behavior of service update, so that it always pulls when --image is specified
making sure that the tag is resolved to a digest as early as possible, which for a 1.12 timeframe it means resolving on the manager the user is talking to. Client-side resolving is strictly equivalent to DOCKER_CONTENT_TRUST being set by default, which is orthogonal to this discussion.

What you're mentioning is an additional issue, which is having a way of forcing the rescheduling, when the environment changed or a node was added. I'm not sure we can have that for 1.12 but it is orthogonal to this issue that thaJeztah opened.
I put this in P2 because it can be considered a bug. The current behavior will never be the expected one.
@stevvooe feel free to open an issue for forcing rescheduling

I think this will have general applicability for debugging and other undetectable changes

Could be useful to force a re-balance (e.g. after adding a new node)

I have had to put the hash of the image at the end when doing service update --image. This make it use the new image but I have had to go to each swarm node and manually pull that image first.
# On all my nodes
docker pull mysite.com:4567/image

#Then on one node, get the hash
docker images mysite.com:4567/image
docker service update --image mysite.com:4567/image:7791fb4 my_service

Really annoying. It would be much better to have it work this way.
docker service update --image mysite.com:4567/image:latest my_service

docker service ps my_service
>>> ID                         NAME               IMAGE                       NODE     DESIRED STATE  CURRENT STATE               ERROR
dzu508odhb63ird37bxxoyojc  my_service.1      mysite.com:4567/image:7791fb4    host        Running   Running 1 minutes ago

However, what I do not want is that when I do any other type of update it updates my image. I want to have to tell it directly to update the image no matter what. Even when scaling up/down the new nodes should take after whatever image was specified when I ran the update.

@mackeyja92 While the rest of your comment makes sense, I am confused why you have to go to each node to pull the image. On startup, tasks will always try to pull the latest for a given tag. Does that registry require a login? What error do you get when you don't pull all the images?

@stevvooe @mackeyja92 I think mysite.com:4567/image:7791fb4 here is the repo:id syntax that we really should remove (see #22112). That reference is local only and not pullable.  Note that you only have these references for images pulled-by-digest or pulled with docker v1.12+.

@stevvooe The first time I start the service it pulls the image fine, however when doing an update I have to go pull the latest images and then update.
@tonistiigi I will look into that.

@mackeyja92 If you have the image set to mysite.com:4567/image:7791fb4, it is never going to update, since it is fixed to that image id. If you want it to update when a new task is created (during service creating or scaling), you'll have to specify the image as mysite.com:4567/image or simply get the new image id and use that.
If you're using the method suggested by @tonistiigi, you'll to run that command each time you want the repo to update. The workflow would be something like this:
docker pull mysite.com:4567/image # get the latest version of mysite.com:4567/image
docker service update --image $(docker inspect -f '{{index .RepoDigests 0}}' mysite.com:4567/image)

That will force all instances to be on the same version using a rolling update, verified by digest.

@stevvooe Sorry, I think you may have misunderstood why I was using the ID. I understand that if I manually set it to a ID it will never update. I was only doing that because after going to every node and pulling the image and running the following it still would be on the old image.
docker service update --image mysite.com:4567/myimage my_service
What I was doing was essentially exactly the same as you were doing except that I was using the image ID instead of the digest hash. The problem that I wanted fixed is having to go to every machine and pull it before running the update command. I am perfectly happy using the RepoDigest instead of the ID if the machines will pull it if they don't have it automatically when running the update.

The problem that I wanted fixed is having to go to every machine and pull it before running the update command.

Ok, I'm very confused by this behavior. Do you have log messages from the node during the pull?

@stevvooe Just to clarify, you are saying that I should only have to pull it on one node and then run the update command and it should pull it on the other nodes automatically? I am on a authenticated registry but all the nodes are logged in.

Are you using the --with-registry-auth flag to service update to propagate the credentials? We don't transmit the credentials by default to prevent them from being spread accidentally by a client that happens to be logged into the registry (also, to avoid clearing them when manipulating the service from a client that's not logged in).

@aaronlehmann No, but they are logged in already. Do I still need to do that?

Yes, because being logged in is a property of the docker client. It keeps a file in your home directory that has the registry credential information. Every time you run a docker pull or docker push command, the docker CLI consults this file and sends the relevant credentials to the docker daemon, where the actual pull or push operation happens. With services, the client is not involved in starting up a task, so it's necessary for the credentials to be included in the service definition.

This is a showstopper. What is a workaround? Scaling to zero and scaling back?
The primary use case for docker swarm mode is zero-downtime updates. It is currently impossible to do without introducing a new tag.

Currently, what I've been doing is pulling manually and adding/removing :latest.
docker service update --image username/image:latest service
...
docker pull username/image
docker service update --image username/image service
...
docker pull username/image
docker service update --image username/image:latest service

So I was able to do it using the hash but it still does not automatically pull on every node. Once I pull the update part works fine using the RepoDigests.

@mackeyja92 Did you try --with-registry-auth like @aaronlehmann suggested? If you did and it still doesn't work then please create a new issue with full report data including the daemon logs and description of the registry setup you are using. You definitely do not need to manually pull when you use digest references in services.

@tonistiigi My apologies, seemed to have missed that piece. Working now. Thanks everyone.

Suggesting that we change the default behaviour to that if the latest tag image have change, we do update. This way it's so much simpler to update with latest, rather than building CI to specify versions/tags.

@tsoikkel One of the problems in my opinion is that :latest is a tag that is standardized for representing the last version of an image, and I think most people (me included until very recently), thought that the semantics of latest are different than with other tags. This should be much better explained on the docs, but even an explanation will not suffice since it creates a natural expectation and behaviour.

I've been able to confirm that adding or updating a container label will trigger a redeployment and pull down the latest image. So this example will deploy an updated image without needing to change the tag, just by using an arbitrary label:
docker service update --container-label-add last_deployed="<timestamp>" service_name

That being said, I'd like to add my vote for making the default behavior to pull down the latest version when running docker service update --image username/image service. I expected this to be the case and was disappointed to find that it did nothing unless you changed the tag.

@kingjared hmm, wouldn't that behaviour be a bug? Lets say that I have actually not the :latest image but :1.0.0, I certainly wont like to have all my nodes to download again that same image just because I changed a label.

@manast My example above just causes Swarm to redeploy the containers for a service (since I made an arbitrary change to the container spec). If the image you're using hasn't updated it won't re-download anything.

@kingjared aha, thats quite interesting. I will integrate this tomorrow to see how it goes.

This should be default for all tags. If the image have changed for 1.0, it should be pulled and deployed.

@stevvooe @tonistiigi @tiborvass where are we on this one; I was thinking along these lines;

digests are the best (only?) option when deploying a service, because you want every replica/task to be on the same image version (to prevent surprises where different replicas/tasks show different behavior)
digests are not very friendly to read (foo@sha256:deadbeef has no meaning, whereas foo:v2.0.x does)
using digests, and updating services should be easy

My suggestion would be to;

Store both what's specified by the user ("friendly" / "human-readable" tag) and the digest in the Service specs. The "friendly" tag can be used for presentation (foo:v2.0.x (foo@sha256:deadbeef)), and to resolve the current digest for that tag, as tags are mutable
If the user/client specifies a digest for the image instead of a tag (e.g. if content-trust is enabled), both "friendly" and "digest" contain the same value. The image is never updated automatically, unless the service is updated to a different image / tag /digest.
the digest is resolved by the manager when creating or updating a service, and stored in the Spec; if the digest is updated, tasks need to redeployed (which should happen automatically, since the Spec is updated)

Does this sound right?

Seeing latest@timestamp while using  would be great. As far as I understand, tags can be changed. So storing timestamp when the tag was last fetched with an ability to force fetching new version is essential.

Although I see where you're coming from, I don't think we should introduce additional concepts of @timestamp. The service definition already shows the created/updated timestamps (see docker service inspect);
        "CreatedAt": "2016-09-30T12:09:13.91371889Z",
        "UpdatedAt": "2016-09-30T12:09:13.91371889Z",

But it doesn't work very well for continuous deployment.

For continuous deployment, and if this is important to you , I'd recommend generating a tag that works for your use case.

I'm coming from Docker Hub automated builds.
My workflow is the following:

merge something to a "stable" branch
wait for hub to build a new "latest"
trigger docker service update

Are there any other recommended workflows?

cc @nishanttotla, who is working on having Docker resolve image digests when creating or updating a service

My workaround atm:
Add random metadata during deployment like container tags:
docker service update --container-label-add deploy=$(date -u +%Y-%m-%dT%H:%M:%S) --image repo:5000/image service-name'

@Vanuan @tsoikkel In order to have a guaranteed, reproducible deployment you should use digests.
Tags can change, however, digests are immutable - they're basically the checksum of a particular image build and will force docker to pull that exact version.
You can see digests during push and pull, example:
$ docker pull redis
Using default tag: latest
latest: Pulling from library/redis
Digest: sha256:38e873a0db859d0aa8ab6bae7bcb03c1bb65d2ad120346a09613084b49185912
Status: Image is up to date for redis:latest

You can also get it by inspecting:
$ docker inspect -f '{{ .RepoDigests }}' redis:latest
[redis@sha256:38e873a0db859d0aa8ab6bae7bcb03c1bb65d2ad120346a09613084b49185912]

Then you use it to deploy:
$ docker service create --name cache 'redis@sha256:38e873a0db859d0aa8ab6bae7bcb03c1bb65d2ad120346a09613084b49185912'

This guarantees that the same exact version gets pulled all the time.
If you make changes to the image then push it, just get the new digest and do a:
$ docker service update cache --image redis@sha256:NEW_DIGEST

Note for the future: We (specifically, @nishanttotla) are working on performing the digest resolution automatically for you from the CLI.
Which means that in 1.13 (hopefully), whenever you do a docker service update --image my-image, the CLI will automatically translate that to image@sha256:current_digest which will force a rolling update if the digest is different from the current one (but will result in a no-op otherwise).

I recommend not just using "latest" as you can't roll back to a previous
image or pull it for testing. You really need a unique tag for every image
you put into production.
I don't think there are well documented best practises here, will try to
write something up.
On 30 Sep 2016 3:04 p.m., "John Yani"<EMAIL_ADDRESS>wrote:

I'm coming from Docker Hub automated builds.
My workflow is the following:

merge something to a "stable" branch
wait for hub to build a new "latest"
trigger docker service update

Are there any other recommended workflows?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/docker/docker/issues/24066#issuecomment-250752568,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAdcPKqSiH3IeILM6TzNmXV8l5TQL66uks5qvRbpgaJpZM4JAiYw
.

@justincormack I have a workflow where one of the differences between production and development is the use of the latest tag. It is very handy to deploy to the dev environment the latest code without needing to create tags for it...

I'm looking for the similar workflow with the @Vanuan ...

@marcellodesales @Vanuan there will be a --force option in docker 1.13; https://github.com/docker/docker/issues/27596 which will force updating the service (and pulling the latest version of the image)

@thaJeztah sounds great!! thanks for keeping us posted!

After https://github.com/docker/docker/pull/28173 was merged, it is now possible to pin service images by digest. That is, creating a service with an image and tag will always resolve to a digest, and all tasks will use exactly the same image.
For a running service, doing an update with the --image tag such as docker service update --image name:latest will result in a re-resolution of the tag to digest, and a pull will occur if a new image was pushed under the same tag. On the other hand, if the --image tag is not specified, then an updated image will not be pulled, ensuring that all service tasks continue to run with exactly the same image. We'll work on improving the UX before the 1.13 release.
Please test out the master branch, or the upcoming RCs. Looking forward to feedback.
cc @marcellodesales @Vanuan @manast

fixed by #28173

Hurrah. Just what I was looking for - thanks! :)

Great, thanks :)


The interaction or interaction type (primary/copy) is missing in the output

Description
The NHS 111 does have associated interaction in the ITK envelope, but they are not getting passed to the message queue (and also not passed in the queue header). So it is impossible to know whether the transaction is for the primary/copy recipient. The way the document is rendered on the screen, or how the document is treated in the workflow also depending on whether that the document recipient is the copy / primary recipient.
The indication of primary or copy can be extracted from the itk handling message spec value for key 'urn:nhs-itk:ns:201005:interaction', eg. in the example below itk:interaction:primaryEmergencyxxxx), which indicate a primary
 <!-- handlingSpecification contains the interaction id from the 111 specification - key is always fixed; value varies depending on recipient -->
                <itk:handlingSpecification>
                    <itk:spec value="urn:nhs-itk:interaction:primaryEmergencyDepartmentRecipientNHS111CDADocument-v2-0"
                              key="urn:nhs-itk:ns:201005:interaction"/>
                </itk:handlingSpecification>

Component
NHS111 adapter
Version
0.1.0
Step to Reproduce

Put the valid a CDA in the payload, and send
Inspect the message queue, nowhere to know if it is for copy/primary recipient.

Test Data
Any data
Preconditions
None
Environment
local environment
Severity
High, impact on supplier integration
Priority
Not urgent
Expected Behavior
The ITK interaction (or copy/primary recipient type) is output in the queue header or somewhere.

This requirement was not visible to us. I will raise this with NHS to confirm

This can be derived from the participant in the 111 Report where the typeCode is 'REFT'.  If the participant is populated with the GP practice, then this is 'FOR ACTION', otherwise this is 'FOR INFORMATION'
In the Encounter Report, this recipient should have been mapped to ReferralRequest.recipient as a HealthcareService

My understanding is CDA is created once with primary and copy recipients. But the ITK envelope decides which destination of the message. So for one CDA, you may send multiple times to a different destination, thus using different ITK interactions (copy and primary). So, the issue I raised is not about what is in the CDA document, but in the ITK envelope. However, the comments you put seems to be relevant to my other issue.

I don't understand why this matters?  Looking at your expected behaviour, what is the queue header?  Why would this be there?  How does this impact system behaviour?

Hi, the queue header thing is just a suggestion. Sori, I am just delayed in my thinking, I think the solution you suggest should work as well. However, I think Kainos already have some work to put the ITK envelope in the FHIR message header resource instead. I think that would solve this issue (if they output the interaction as well).

after the 0.2.0 release, the FHIR message header output does not contain interaction so, it seems to need to rely on the REFT participation, as suggested, to decide whether for ACTION or for INFORMATION.

@davidwaters33  just a question: is the participant REF can be used reliably in this case because PRCP (primary recipient) is mandatory (1..n)  while REFT (participant) is optional (0..n). I have not seen any documentation that mandates the REFT must match with the PRCP. What happens is NHS111 refer back patient to both GP and some other surgery clinic, both as primary, and the participant only have surgery clinic. Is this scenario is likely and do we need to consider? I just wonder if this mechanism will be more robust than using the ITK interaction?

MessageHeader.reason will be populated with these codes, will aim to implement this in the next release.


typo

to test

@yegor256/z this pull request is too small, just 2 lines changed (less than 10), there will be no formal code review, see §53 and §28; in the future, try to make sure your pull requests are not too small; @yegor256/z please review this and merge or reject


added pytorch implementation of UNet and UNet++

Change the parent folder name to semantic_segmentation.

I have done the required changes and added my training results as well. Perhaps this should do.


Permalink URL to Pull Request Comment

No duplicates.

A permalink URL to a pull request comment made on a pull request accessible via the vscode interface.
Currently to access a permalink to a comment the link must be generated when having the pull request open on the remote. Having access to a permalink URL from vscode will allow for easy communication with a team when referring to a specific comment.
The comments panel provided by vscode would be a great place for this functionality to exist with a right click on the comment of mention.

This PR in the vscode github repo seems to suggest something similiar
https://github.com/microsoft/vscode/issues/156885

Added with https://github.com/microsoft/vscode-pull-request-github/pull/4330

I was just looking for this issue to add it if it didn't exist. Glad to see that it'll be landing soon!


OpenAPI 3.0 default response not suported

Describe the bug
I make use of the OpenAPI 3.0 default response feature on every handler: https://swagger.io/docs/specification/describing-responses/#default however this is unsupported by the codegen tool currently.
OpenAPI Spec File
https://github.com/Southclaws/storyden/blob/main/api/openapi.yaml
Desktop (please complete the following information):

OS: Windows 11, Mac OS
Python Version: 3.12.4
openapi-python-client version: 0.21.2

Additional context

Please upvote https://github.com/openapi-generators/openapi-python-client/discussions/832


English!

This looks like a great framework. Would be awesome to get english docs!

In progress. Will be available soon.


bug: local image doesn't load

(It's possible this is already covered; please close if you know this.)

i believe you need to put the image in a static dir, https://github.com/axodotdev/oranda/blob/219a8316c515b2156b2679ef0d0a6f09fc9cba43/src/site/mod.rs#L60
it's not yet documented, and we should do that.


Add audio player

Add audio player to  play mp3 ,falc and various
other  audio format file.

I had a prototype for this a while ago, it's about time I properly implement this.
P.S: this will be pretty low on the priority list, apologies.

waiting for this one ....


fix: Update module dependencies for TF 0.14 support

Description
This PR updates module dependencies to provide support for Terraform 0.14.
Motivation and Context
The versions of module dependencies that are used now set the required_version parameter as < 0.14.0, which means we cannot use the module with Terraform 0.14.
Breaking Changes
Does not break compatibility: the new versions are all backwards-compatible.
How Has This Been Tested?
Tested with terraform validate on Terraform 0.14.

Thanks @bryantbiggs for the review!
v2.28.0 has been just released.

Thank you!


Tidy up

Motivation and Context
Missed a couple of PR review comments.
What has changed
Addressed those comments.
How to test?
Not really needed.
Links
Trello: https://trello.com/c/tatlZ3ZJ

 ROps Repo tidy couple of little bits


Third party docs

Adds docs for partners and customers using third party extensions.

@sbenedicadb I'll be making another PR with an update to our README/table of contents to make other docs more discoverable.


Adding verification to packageTask

Verification added to packageTask to avoid errors in execution for tasks that don't have common dependencies.

Hi @FernandoMorais, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

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

TTYL, MSBOT;

@bryanmacfarlane can you accept/close as appropriate.

closing since we're going to create shared modules for others to build tasks ....


{Storage} Fix issue#9948: 'az storage container create' required '--connection-string'

Description

Fix #9948
After discussion with cx, there is an issue in documentation. So we need to refine the doc.
Testing Guide

History Notes

[Component Name 1] BREAKING CHANGE: az command a: Make some customer-facing breaking change.
[Component Name 2] az command b: Add some customer-facing feature.

This checklist is used to make sure that common guidelines for a pull request are followed.

[ ] The PR title and description has followed the guideline in Submitting Pull Requests.

[ ] I adhere to the Command Guidelines.

[ ] I adhere to the Error Handling Guidelines.

Storage


feat: use mutate context hook

This PR

New hook for mutating context instead of using the global object
Related Issues

Fixes #968
Notes

Follow-up Tasks

How to test

Could you please sign off on your commits? It's basically a way to tell the CNCF that you're willing and able to donate this code.
To add your Signed-off-by line to every commit in this branch:

Ensure you have a local copy of your branch by checking out the pull request locally via command line.
In your local branch, run: git rebase HEAD~5 --signoff
Force push your changes to overwrite the branch: git push --force-with-lease origin wichopy/968

For future commits, you can add -s when running git commit.

I'll look into the licensing issue.


X11: Popup menu issues

I've been testing dlangui and figuring out how to use the library as a whole, and I've found a few issues with using the x11 backend in regards to right click events and/or popup menu(s).
Building example1 with the following command (build can be release or debug, doesn't matter):
dub run dlangui:example1 --config=x11
When I move into the editor tab and right click the first editor, nothing happens. Instead, when I middle click, the context menu pops up. Interestingly, I can create two context menus at the same time this way.
This does not happen when using the de-facto SDL2 backend (right click functions normally / only one context menu pops up).
Running on ArchLinux 64 bit (x86_64) with openbox window manager.

I would not consider x11 backend as ready to use. It needs development.

@FenixFyreX  I think it's fixed now by fd6940c18413ac5747a457b4f67febd42210cc67 and 4c6cc85481ddbe1f6d8ebb873af5728ceddb3ee9. Please test and close when version 0.9.162 will be released.
@buggins Please test latest X11 changes and make release :)

Solved, thanks much :)


upgrade cfssl installations

Change cfssl installations from "https://pkg.cfssl.org" to their new page "https://github.com/cloudflare/cfssl/releases" and upgrade them to newtest 1.5.0.
Because the old source http://pkg.cfssl.org/ (https doesn't work the other day) only has versions from 2018, newer + current versions are available at https://github.com/cloudflare/cfssl/releases.
Detail:https://github.com/kubernetes/kubernetes/issues/97929
/cc @dims @gnufied

/assign @irvifa
/approve

/assign @irvifa
/approve

/assign @irvifa

/assign @irvifa

@Haleygo, would you be willing to change just the one localization (English) in this PR? Once that merges, it's OK to open PRs (one per localization) to update the other pages.
This is because different localization teams each have their own process for deciding how to develop their localization.

@Haleygo, would you be willing to change just the one localization (English) in this PR? Once that merges, it's OK to open PRs (one per localization) to update the other pages.
This is because different localization teams each have their own process for deciding how to develop their localization.

Got it!
Done,I will only change content under en in this pr.@sftim

Got it!
Done,I will only change content under en in this pr.@sftim

/remove-language fr
/remove-language id
/remove-language it
/remove-language pt
/remove-language zh

/remove-language fr
/remove-language id
/remove-language it
/remove-language pt
/remove-language zh

/lgtm

/lgtm

/lgtm

/lgtm

/approve

/approve


⚠ gorzdrav.org has degraded performance

In 3c57578, gorzdrav.org (https://gorzdrav.org) experienced degraded performance:

HTTP code: 200
Response time: 2615 ms

Resolved: gorzdrav.org performance has improved in 29db3f9.


narrow: Allow searching by emoji

Closes #2994
I implemented it by:

Making the highlighter aware of HTML tags (hopefully the algorithm there is good, though I tested it well)
Rendering the search query as markdown (not necessary for emoji search with pgroonga)

This means that now one can search for, e.g. **bold text** to get all messages with bold text in bold
Note that while pgroonga can find emojis that are incomplete (e.g. :office), tsearch can't (e.g. only :office: would be accepted by it)

Add tag and entity parsers, so that tsearch works fine as well

Sidenote: Searching for br with pgroonga would find all kinds of br tags here and there... (even on current master)

Automated message from Dropbox CLA bot
@bojidar-bg, it looks like you've already signed the Dropbox CLA. Thanks!

@bojidar-bg, looks good. I have not really looked at your algorithm in detail yet.

@umairwaheed Ok, I think I handled all comments above, or replied :+1:

@bojidar-bg Looks like some of the tests are failing. Can you see what's the problem and make them pass?

@hackerkid Well, problem was that since python3, bytes.rfind(...) can't use a str for a first parameter, but requires another bytes object there :smiley:

Aw, just noticed there are conflicts, will rebase :smiley:

I merged the search fix commit.

Great!  I just merged that prep commit as well.

Can you respond to my various questions above @bojidar-bg?

@timabbott, I am thinking of approving the GCI task of @bojidar-bg. I guess he has resolved the main issue.

That sounds good.  I am not yet confident I'm happy with merging the current parsing logic, which is why I haven't merged the last bit, but I think this is definitely solid work for a GCI task and we can approve the task so he can start working on another.

@timabbott and @showell, this PR is stuck.

@timabbott Ah sorry, didn't see your comments -- replied now.

Just to make sure, are there changes I should do in the logic, or should I just fix the merge conflict?

I think @HarshitOnGitHub has picked this up and is rebasing it as a new PR, so I'm going to close this.  Thanks for your work on this @bojidar-bg!
@HarshitOnGitHub correct me if I'm wrong!


Workaround for helm3 compatibility

Description of your changes
Helm 3 introduced some breaking changes one of which is deprecating crd-install hook and skipping CRDs with this annotation which causes some of the existing helm charts to fail. We need these hooks for stackinstall and clusterstackinstall CRDs to be able to install infrastructure stacks with helm.
Ideally we should drop helm2 support and specify helm3 as minimum version as suggested by @soorena776 here as potential fix. However, there are still users (like gitlab) who depend on helm2 and we need to support it at least for some more time.
One workaround could be using some sort of built-in variable which lets us to understand it is helm 3 and we do not put annotation if so, however there seems to be no such variable yet.
As a workaround, this PR copies the two crds, without crd-install hook annotation, under <chart>/crds directory which is introduced with helm3 but ignored in helm2.
So, with this change, we will have clusterstackinstalls and stackinstalls CRD yamls:

with hook under <crossplane-chart>/templates/crds: for helm2 skipped in helm3
without hook under <crossplane-chart>/crds: for helm3 ignored in helm2

Fixes #943, #1062, #1064
Checklist

I have:

[x] Run make reviewable to ensure this PR is ready for review.
[x] Ensured this PR contains a neat, self documenting set of commits.
[ ] Updated any relevant documentation, examples, or release notes.
[ ] Updated the RBAC permissions in clusterrole.yaml to include any new types.

@turkenh Thanks for the quick fix! As for backward compatibility, my understanding is that Gitlab is using an already tagged version of Crossplane (e.g. v0.4), so not supporting helm2 going forward shouldn't break their existing flow. Isn't that the case @prasek and @jbw976?

@soorena776 I thought GitLab managed apps was using whatever the latest is from the alpha charts repo, but you might be right that they are actually always using v0.4.1 from the alpha repo.  I'm confirming with @mahendrabagul in this note on the MR: https://gitlab.com/gitlab-org/gitlab/merge_requests/18797/diffs#note_245343086

@turkenh any update on this PR? Does is need further review?

@hasheddan PR is ready from my POV.
But from the discussions above it looks like we can also drop helm 2 support and adapt the chart only for helm 3, so we wouldn't need this workaround. @jbw976, I see that Gitlab using a hardcoded version of  Crossplane Helm chart, does this mean we can drop Helm 2 support? Wouldn't they need to update Crossplane version to get new feature and bug fixes?
In any case, my suggestion would be to merge this workaround ASAP and follow dropping Helm 2 support with another issue.

@jbw976, I see that Gitlab using a hardcoded version of Crossplane Helm chart, does this mean we can drop Helm 2 support? Wouldn't they need to update Crossplane version to get new feature and bug fixes?
Right, in GitLab I imagine they will update to v0.5 and v0.6 over time, which could very well be before GitLab moves to Helm 3.  I think we need to maintain compatibility with Helm 2 for an undetermined amount of time going forward still.

I assume you tested this for both helm2 and helm3?

Yes, tested with both versions (v2.15.1 & v3.0.0) with/without cluster stacks.

On helm3, is the /templates/crds directory ignored? How does helm3 know not to just render everything under /templates?

No, helm3 already renders everything under <chart>/templates/crds but skips the two with crd-install hook. Those two comes from <chart>/crds as helm3 recognizes this directory.

When this is merged, what will the end state be regarding installation from alpha when using either Helm 2 or 3?  Will the docs need a new section describing how to install with Helm 3 changes (e.g. generating the namespace prior to running helm, and how to get pull down the workaround for /templates/crds)?  When I do brew install helm, I am now on helm 3 by default, so I have to decide whether to pin myself to the older version.

When this is merged, what will the end state be regarding installation from alpha when using either Helm 2 or 3? Will the docs need a new section describing how to install with Helm 3 changes (e.g. generating the namespace prior to running helm?

There should be no difference regarding installing with helm 2 or helm 3, except:

With helm3, namespace to be created prior to install as you pointed out, but I see it is already documented here.
With helm3, Following two lines of log which would be totally harmless:

manifest_sorter.go:175: info: skipping unknown hook: "crd-install"
manifest_sorter.go:175: info: skipping unknown hook: "crd-install"


[html] for anchor tags, on enter, put the end tag directly on the next line

When I have this:
|

and I press Enter, I get this:

    |

but I would like this instead:

    |

Trailing whitespace within the anchor tag is significant, so I always want the end tag to immediately follow the link text.

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

:slightly_frowning_face: In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.
Happy Coding!


Feature request: no-side flag

Hey @mhinz,
First of all, thanks for this plugin, it looks great and it make grepping work better for me.
I would like an option to use a flag of noside, like the other no-flags in the plugin (for example, noopen). In my configuration, I would like to use the side option by default, but sometimes have some queries in which I wouldn't like to open the new window at the side. I didn't find a way to do it with the current flags available.
If you could guide me through adding this feature, I might be able to add it myself if you would like, but from first look at the code it seems quite complicated to me, since I am not very familiar with vimscript yet.

Hi and thanks! :)
You'd just need to change this line to look like these lines (and then also move it above the -cword check for cleaner grouping).
Then, for :Grepper -nos<tab> to work, add -noside here as well (alphabetically sorted with the -no* options at the end).

Merged!


Error in "Appending content' section of  https://docs.perl6.org/language/io-guide

The "Appending content" section has a short 4 line example, and then two paragraphs down, describes it as:
"On the next couple of lines, we use the usual .print
 method on that IO::Handle to print ten lines of text."

But this is $fh.print, without any explicit newlines. It winds up all on one line, certainly with my 2017.01 version of Rakudo, and same with 2017.04.3 / MoarVM version 2017.04-53-g66c6dda.

Thank you for the report. This is now fixed in https://github.com/perl6/doc/commit/1a5ee4fd396b86d6de0b4bb7f744fef38cf0e13f


What is grad_norms in AC_Network?

Hi,
I come across your A3C implementation and find the following 2 lines in AC_network.py:
self.var_norms = tf.global_norm(local_vars)
grads,self.grad_norms = tf.clip_by_global_norm(self.gradients,40.0)

I wonder what's grad_norms for? It seems to me that it is not used.
Thanks!

This is the norm value of gradients of the network, by monitoring this value, we know how much changes are applied to the network parameters during training
In case of gradient explosion, we usually use a simple trick, namely gradient clipping, to prevent too huge changes to the network parameters.
In the case above, 40.0 is used for clipping
Try to use different values (10, 20, 50, 80) and see the effect on the training and share the results if  you like :)

Thanks @IbrahimSobh , it helps!


Updated Readme- grammatical and typo fixes

Hi!  Upon review, I found a couple more typos and some other grammar issues.  This proposed change fixes them.  TY!

I am publish new version 5.2.2 and change readme.
For now branch has conflict Maybe you can fork from master and apply changes again?
It will be cool!


Translate "\r\n" line endings to "\n" in skim.Scanner

This is motivated by the "\r\n" line endings in the logs currently generated by MinGW Zeek. That behavior might change, but this is probably a good idea regardless.

I forgot to mention that I added zio/zeekio.TestReaderCRLF to make anyone think twice before removing the skim.Scanner change.


Disable foldenable in Snippet preview popup/float

Snippet with multiple lines are folded. This issue happened with vsnip snippet, but I think it maybe happen with ultisnip snippet as well.
Before:

After:

Please help to review this PR, thanks.

cool


[Feature Request]: Logit Bias for Hugging Face

Is your feature request related to a problem? Please describe.
This is a continuation of #352 for Hugging Face. We previously added logit biasing for Open AI and since have found it fairly useful in increasing the control users have over the LLM outputs.
Describe the solution you'd like
Implement logit biasing for Hugging Face pipelines using Sequence Bias Logits Processor.

Seems like this is not possible yet due to how Hugging Face pipelines are implemented in langchain right now.
We would need to pass in generate_kwargs as shown here to use sequence biasing.


Rename master branch to main

Creating issue to track work item of renaming the default branch from master to main to follow the naming convention we have set in other RNW repositories.

Looks like this has been completed.


image_size during inference?

Can I do inference with original image size instead of 320x320?

i figured.


Support netcdf file

Description
As geemap has supported the netcdf file (https://github.com/giswqs/geemap/issues/285), it's better to add it to leafmap like https://github.com/davidbrochart/xarray_leaflet/issues/12.
Source code
Anyway, I use xarray_leaflet temporarily:
import leafmap
import xarray as xr
import xarray_leaflet

m = leafmap.Map(center=(40, -100), zoom=4)

data = xr.open_dataset('../data/tropomi_regrid/monthly/S5P_OFFL_L2__NO2____qa50_qa75_csd_202001-202108.nc')['tropospheric_NO2_column_number_density'].isel(time=0)

l = data.leaflet.plot(m, x_dim='longitude', y_dim='latitude', colormap='vidiris')

m.add_tile_layer(l, name="TROPOMI NO2", attribution="Test")

Error:
Exception: The 'url' trait of a TileLayer instance expected a unicode string, not the LocalTileLayer LocalTileLayer(name='tropospheric_NO2_column_number_density', options=['attribution', 'detect_retina', 'max_native_zoom', 'max_zoom', 'min_native_zoom', 'min_zoom', 'no_wrap', 'tile_size', 'tms']).

Is it possible to add the LocalTileLayer to map?

Use m.add_layer() rather than m.add_tile_layer() to add LocalTileLayer. See https://ipyleaflet.readthedocs.io/en/latest/api_reference/local_tile_layer.html
Adding netCDF support is on my to-do-list. I don't have a timeline to implement it yet. Contributions are welcome.

@zxdawn Leafmap now supports NetCDF data. See notebook example https://leafmap.org/notebooks/52_netcdf/

@giswqs Thanks a lot for your hard work!


[BOT PR] to update dependencies of istio

This PR will be merged automatically once checks are successful.
none

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: istio-testing
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: linsun
If they are not already assigned, you can assign the PR to them by writing /assign @linsun in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@istio-testing: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-simpleTests-cni.sh
66fdcea1ccb03c93874a5d733c2ea21b1fd42ff0
link
/test e2e-simpleTests-cni

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@istio-testing: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-simpleTests-cni.sh
66fdcea1ccb03c93874a5d733c2ea21b1fd42ff0
link
/test e2e-simpleTests-cni

prow/istio-integ-k8s-tests.sh
66fdcea1ccb03c93874a5d733c2ea21b1fd42ff0
link
/test istio-integ-k8s-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@istio-testing: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-simpleTests-cni.sh
66fdcea1ccb03c93874a5d733c2ea21b1fd42ff0
link
/test e2e-simpleTests-cni

prow/istio-integ-k8s-tests.sh
66fdcea1ccb03c93874a5d733c2ea21b1fd42ff0
link
/test istio-integ-k8s-tests

prow/istio-pilot-multicluster-e2e.sh
66fdcea1ccb03c93874a5d733c2ea21b1fd42ff0
link
/test istio-pilot-multicluster-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@istio-testing: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-simpleTests-cni.sh
66fdcea1ccb03c93874a5d733c2ea21b1fd42ff0
link
/test e2e-simpleTests-cni

prow/istio-integ-k8s-tests.sh
66fdcea1ccb03c93874a5d733c2ea21b1fd42ff0
link
/test istio-integ-k8s-tests

prow/istio-pilot-multicluster-e2e.sh
66fdcea1ccb03c93874a5d733c2ea21b1fd42ff0
link
/test istio-pilot-multicluster-e2e

prow/e2e_pilotv2_auth_sds.sh
66fdcea1ccb03c93874a5d733c2ea21b1fd42ff0
link
/test istio_auth_sds_e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@istio-testing: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-simpleTests-cni.sh
66fdcea1ccb03c93874a5d733c2ea21b1fd42ff0
link
/test e2e-simpleTests-cni

prow/istio-integ-k8s-tests.sh
66fdcea1ccb03c93874a5d733c2ea21b1fd42ff0
link
/test istio-integ-k8s-tests

prow/istio-pilot-multicluster-e2e.sh
66fdcea1ccb03c93874a5d733c2ea21b1fd42ff0
link
/test istio-pilot-multicluster-e2e

prow/e2e_pilotv2_auth_sds.sh
66fdcea1ccb03c93874a5d733c2ea21b1fd42ff0
link
/test istio_auth_sds_e2e

prow/istio-pilot-e2e-envoyv2-v1alpha3.sh
66fdcea1ccb03c93874a5d733c2ea21b1fd42ff0
link
/test istio-pilot-e2e-envoyv2-v1alpha3

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


Fixed PropTypes codemod bug that left invalid variable references

While running this codemod against some FB source I discovered a case that wasn't handled correctly:
const React = require('react');
const ReactPropTypes = React.PropTypes;
const string = ReactPropTypes.string;

Would get incorrectly converted to:
const React = require('react');
// ReactPropTypes is not defined
const string = ReactPropTypes.string;

This PR contains a fix as well as an added test case. Now the codemod only removes pointers that have names that conflict with the import, eg:
const React = require('react');
const ReactPropTypes = React.PropTypes;
const string = ReactPropTypes.string;

Will now be converted to:
const PropTypes = require('prop-types');
const React = require('react');
const ReactPropTypes = PropTypes;
const string = ReactPropTypes.string;

I think this makes sense. Nice catch!


Publish updated Nuget

Publish an updated Nuget with the changes from PR's #2, #3, & #4
https://github.com/sushihangover/Cake.AppleSimulator/issues/9
https://github.com/sushihangover/Cake.AppleSimulator/issues/10

@sushihangover @ghuntley just a thought as well...
Since there are now two of you working on this project, would it make sense to move it under the Cake-Contrib Organisation?
http://cakebuild.net/blog/2016/08/cake-contribution-organization

@gep13 , I have no problem with that, but it is @ghuntley 's repo so I'll defer any decision regarding this to him

@sushihangover CI issues have been resolved v0.1.0 has been published to NuGet.org; if it lets us down again then yeah let's look at moving to the Cake-Contrib organization.
See https://github.com/ghuntley/Cake.AppleSimulator/releases for release notes. Can you please unlist your package?


Onboarding key

Describe the bug
A clear and concise description of what the bug is.
My device is not recognize on the network, missing the onboarding key.
How can it be fixed ?
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

Contact<EMAIL_ADDRESS>This is not a support forum.


Stress test NegativeBinomial

Occasionally, I hit errors on using Distributions.NegativeBinomial when I think that logpdf = -Inf would be more stable.
This issues is about determining more precisely the failure mode here, and negative interactions with compiled reverse passes (e.g. using AutoReverseDiff(true)).

We should have an overflow safety here.


LiteDB collections become corrupted

Dear mbdavid,
I use v4.11 in a secure mode - single threaded, encrypted with exclusive access.
However, after a certain volume of usage, certain collections of the database become corrupted and selecting records from them raises the following exception:
Excpetion=System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.
   at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
   at LiteDB.IndexService.<FindAll>d__13.MoveNext()
   at LiteDB.LinqExtensions.<>c__DisplayClass2_0`2.<<DistinctBy>g___0>d.MoveNext()
   at LiteDB.QueryCursor.Fetch(TransactionService trans, DataService data, BsonReader bsonReader)
   at LiteDB.LiteEngine.<Find>d__9.MoveNext()
   at LiteDB.LiteEngine.<Find>d__13.MoveNext()
   at LiteDB.LiteCollection`1.<Find>d__17.MoveNext()
   at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
   at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)

When I try to open the database in LiteDB viewer and click on the corrupted collection, I get this error:
LiteDB.LiteException: Datafile is not a LiteDB database.
   **at LiteDB.HeaderPage.ReadContent(ByteReader reader)
   at LiteDB.BasePage.ReadPage(Byte[] buffer)
   at LiteDB.PageService.GetPage[T](UInt32 pageID)
   at LiteDB.QueryCursor.Fetch(TransactionService trans, DataService data, BsonReader bsonReader)
   at LiteDB.LiteEngine.<Find>d__9.MoveNext()
   at LiteDB.LiteEngine.<Find>d__13.MoveNext()
   at LiteDB.LiteCollection`1.<Find>d__17.MoveNext()**
   at LiteDBViewer.MainForm.FillDataGridView(IEnumerable`1 documents)
   at LiteDBViewer.MainForm.listBox_SelectedIndexChanged(Object sender, EventArgs e)
   at System.Windows.Forms.ListBox.OnSelectedIndexChanged(EventArgs e)
   at System.Windows.Forms.ListBox.WmReflectCommand(Message& m)
   at System.Windows.Forms.ListBox.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

I would be happy for your assistance, thank you!!

Hi @tabtile, sorry about that. I get some issues about data consistency last days and I will investigate this weekend. So, can you tell about your environment so I will have a start point.

Is Windows 10? Are you using .NET full or .NET core?
You tell that you are using single thread. I presume that your application is WinForms (as stacktrace/namespace says). So, there is no concurrency? No 2 threads works in same datafile (using same LiteDatabase instance or in 2 distinct database instances)
Are you using LiteDatabase inside a using statment? Like every command you do you open/execute/close? Or you have a single open LiteDatabase instance and execute all command over this instance (in this case, when you call .Dispose())

I think can be a bug/problem when save data into disk and but not all page are saved....  that is quite hard to detect.
Also, to recovery data, try use master branch version.... I wrote a code to read data-only and re-create datafile.

Dear mbdavid,
Thank you for your kind and detailed email!
Regarding your questions:

I'm using Windows 10 running .NET full.
I'm using a single thread, my app is a windows service (the winforms stack trace derives from litedb viewer app). Only one thread works on a data file at once using a continuously opened connection that is disposed and recreated only when there is an error in the query execution.
I'm not using litedatabase in a using statement because I want to keep an open connection, and (as I've mentioned) I'm executing all my commands within the same instance (unless an exception is thrown, then I'm disposing and recreating the connection)
my workflow is that I'm using collections with indexes and inserting entries to them over time. At some point I'm cleaning up old entries from the collection (which might affect the index structure) and then continue to insert to new entries to it... maybe it creates a problem with the indexes structure which corrupts the entire collection?)

Just a thought following your direction- If I will create/dispose the connection for every query, will it persist the pages and solve the problem?
Regarding compiling the master branch, is it stable in your opinion for operational use?
Thank you for your time and effort!

BTW - your recovery method needs to accept a password for encrypted databases.

I've debugged your master branch with my corrupted database, here is the exception:

I have the same problem like @tabtile. How we can recover the Database?

i'm with the same problem... any solution?

I have the same problem. How we can recover the Database?

Dear mbdavid ,
Gratulations first for this lightweight useful and performant library.
I regrettably encounter same issue
No way to protect that part of code ? May I help you ?

We started receiving this issue with larger LiteDB datasets.  I mean, quick larger I had to remove Compact() cause it would take 5+ minutes to finish.


readonly is not documented

You can make properties read-only by using the "readonly: true" option. Actually it's not even used under options, you can use it like this:
some_prop: {
  type: 'boolean',
  readonly: true
}

This could be documented IMHO, it was useful for us.

This repo is no longer maintained (see also #800)
Development is continued at https://github.com/json-editor/json-editor
For details please visit json-editor/json-editor#5


[SPARK-34326][CORE][SQL] Fix UTs added in SPARK-31793 depending on the length of temp path

What changes were proposed in this pull request?
This PR proposes to fix the UTs being added in SPARK-31793, so that all things contributing the length limit are properly accounted.
Why are the changes needed?
The test DataSourceScanExecRedactionSuite.SPARK-31793: FileSourceScanExec metadata should contain limited file paths is failing conditionally, depending on the length of the temp directory.
Does this PR introduce any user-facing change?
No.
How was this patch tested?
Modified UTs explain the missing points, which also do the test.

cc.ing @gengliangwang @cloud-fan @HyukjinKwon @maropu who are author/reviewers of #28610

Test build #134770 has started for PR 31435 at commit 36943c6.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/39354/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/134770/

Nice catch!

retest this, please

Just retriggered Github Action as well.

Test build #134782 has started for PR 31435 at commit 36943c6.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/39369/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/39369/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/39369/

Test build #134782 has finished for PR 31435 at commit 36943c6.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/134782/

Merging to master/3.1.

Hm, the tests started to fail:
[info] - SPARK-31793: FileSourceScanExec metadata should contain limited file paths *** FAILED *** (265 milliseconds)
[info]   1 was not greater than or equal to 2 (DataSourceScanExecRedactionSuite.scala:154)
[info]   org.scalatest.exceptions.TestFailedException:
[info]   at org.scalatest.Assertions.newAssertionFailedException(Assertions.scala:472)
[info]   at org.scalatest.Assertions.newAssertionFailedException$(Assertions.scala:471)
[info]   at org.scalatest.Assertions$.newAssertionFailedException(Assertions.scala:1231)
[info]   at org.scalatest.Assertions$AssertionsHelper.macroAssert(Assertions.scala:1295)
[info]   at org.apache.spark.sql.execution.DataSourceScanExecRedactionSuite.$anonfun$new$9(DataSourceScanExecRedactionSuite.scala:154)
[info]   at org.apache.spark.sql.execution.DataSourceScanExecRedactionSuite.$anonfun$new$9$adapted(DataSourceScanExecRedactionSuite.scala:123)
[info]   at org.apache.spark.sql.catalyst.plans.SQLHelper.withTempPath(SQLHelper.scala:69)
[info]   at org.apache.spark.sql.catalyst.plans.SQLHelper.withTempPath$(SQLHelper.scala:66)
[info]   at org.apache.spark.sql.QueryTest.withTempPath(QueryTest.scala:34)
[info]   at org.apache.spark.sql.execution.DataSourceScanExecRedactionSuite.$anonfun$new$8(DataSourceScanExecRedactionSuite.scala:123)
[info]   at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:23)

https://github.com/apache/spark/runs/1818352990
https://github.com/apache/spark/runs/1818908589
@HeartSaVioR, please let me revert this for now since it targeted to fix the test but it started to fail in any event.

Ah thanks for the check. Looks odd... I'll check it.

Raised a new PR #31449

Raised a new PR #31449


LWM2M: Add SOL_LWM2M_RESOURCE_INT_INIT() macro.

This macro will prevent some problems that might occur when
reading the int value with va_args in some platform.
The macro will automatically cast the value to int64_t.
Signed-off-by: Guilherme Iscaro<EMAIL_ADDRESS>

looks ok

seems cool

merged


[feature request] Extend dfdaemon's proxy mode

Why you need it?

It would be great if we can set HTTP_PROXY=http://dfdaemon and speed up HTTP requests for any third party tools that respects the HTTP_PROXY environment variable out of the box.
A good example would be speeding up package managers like yum, apt, npm, maven and others that can use HTTP download.
The current registry proxy can be implemented with this too.
HTTPS requests are more tricky, the best we can do at the moment might be just proxying it over HTTP, without looking at the content. This will handle cases where the client needs both HTTPS and HTTP requests like #449
How it could be?

We need a way to describe the proxy rules like registries in dfdaemon's config, for example:
proxy:
  # a regexp that will be checked against the url, probably without the scheme since
  # we can only actually handle http requests
- match: regexp
  # change the proxy target and scheme, as the current registry proxy does.
  # maybe we can also provide a way rewrite host like the nginx rewrite syntax
  change_host: example.host
  change_scheme: https
  # like the urlfilter parameter, but works for individual rules, merged with global settings
  query_filters:
    - Signature
    - Expires
    - OSSAccessKeyId
  # whether to use p2p to download, like the rule cli parameter
  p2p: true

We can first read the rules from config file, and maybe provide apis to dynamically change the rules later.
Other related information

It's a great idea for Dragonfly and I think it's not difficult to implement this feature. We will put it in Dragonfly roadmap and welcome to open a pull request to implement if you feel free.
Proxy rules changing dynamically through API you mentioned above, we can make it more generic to change configuration of dfdaemon dynamically on runtime.


chore: remove protoc.sh

Signed-off-by: Gaius<EMAIL_ADDRESS>
Description

Remove build/protoc.sh file.

Related Issue
#340

Motivation and Context
N/A

Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Documentation Update (if none of the other choices apply)

Checklist:

[x] Code compiles correctly.
[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.

Codecov Report

Merging #341 (e27146c) into main (a28a812) will decrease coverage by 0.16%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #341      +/-   ##
==========================================
- Coverage   41.12%   40.95%   -0.17%
==========================================
  Files          61       61
  Lines        4832     4832
==========================================
- Hits         1987     1979       -8
- Misses       2595     2605      +10
+ Partials      250      248       -2

Flag
Coverage Δ

unittests
40.95% <ø> (-0.17%)
:arrow_down:

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

Impacted Files
Coverage Δ

pkg/util/net/iputils/ip_utils.go
61.22% <0.00%> (-4.09%)
:arrow_down:

client/daemon/peer/peertask_stream.go
55.09% <0.00%> (-3.02%)
:arrow_down:

client/daemon/peer/peertask_base.go
33.25% <0.00%> (+0.48%)
:arrow_up:


Add :age_restricted? to Content Details.

Perfect. For future reference, this supports https://github.com/Fullscreen/yt/commit/394d41b89e66b609c7a44f3110a4840269aa72c2


About the status of this project

we need some doc like this:
### Status

This **** is currently considered experimental.

fixed


PyWavelets vs. nigma Github repo

I noticed that the "fork on Github" button at http://pywavelets.readthedocs.org/ still points to https://github.com/nigma/pywt
So I wanted to change it to point to https://github.com/PyWavelets/pywt and use Github search to find the location in the code / docs where this is set.
But code search in forked repos doesn't work: https://help.github.com/articles/searching-code/#search-by-the-number-of-forks-the-parent-repository-has
I'm not sure ... maybe this could be resolved by deleting https://github.com/nigma/pywt and then forking it from https://github.com/PyWavelets/pywt ?
https://help.github.com/articles/what-happens-to-forks-when-a-repository-is-deleted-or-changes-visibility/
cc @nigma @rgommers

I have solved a number of similar issues by contacting github support, explain the situation and ask them to detach the repository from the original one.

@cdeil good spot, thank you. Agreed, it's annoying that you can't search in forks!

This issue was closed, but is only partly adressed.
I think what @jenshnielsen proposed, that you ask Github to detach this fork (or revert which is the fork) would be a good solution.

@cdeil sorry, I was overeager. I think I understand now - the problem is that the code in this repository is unsearchable in the browser (the links were a separate problem), right?
This is caused by this repo being a fork of nigma/pywt.

@aaren – Yes.

I've contacted github support.

Ok, Pywavelets/pywt added to index and code is now searchable.

Something else we could do: make PyWavelets the root repository so that future forks show up as forks of PyWavelets/pywt rather than nigma/pywt.

Nice quick resolution of this issue.

Something else we could do: make PyWavelets the root repository so that future forks show up as forks of PyWavelets/pywt rather than nigma/pywt.

I think forks that are made from PyWavelets/pywt will anyway show up as forked from there, see https://github.com/PyWavelets/pywt/network and https://github.com/aaren/pywt for example. So I don't think it's a major issue that this repo says it's forked from @nigma's repo - because that is the actual history of the project.

It's still confusing to have the active repo shown as a fork.
Also https://github.com/nigma/pywt currently has 133 stars, but https://github.com/PyWavelets/pywt only 23, so I think Google (and Github?) search will point people there.
One other thing you could do is close the issue tracker on the old repo: https://github.com/nigma/pywt/issues
And close the PRs on the old repo (https://github.com/nigma/pywt/pulls), leaving a comment pointing to the new repo.

Good points. I can update https://github.com/nigma/pywt, so its README points here and I can close the issue tracker (assuming Github lets me do that without deleting the issue history).

@nigma had already updated the README on https://github.com/nigma/pywt, it now points prominently to this repo

All PRs on https://github.com/nigma/pywt are closed, and I've only left a single issue open (https://github.com/nigma/pywt/issues/13) which is titled "Continuing PyWavelets development on PyPi" and still needs resolving.


Update

Version 5.18, try switching to giza.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


Update rbac-and-directory-admin-roles.md

I'm new to Azure so i might be wrong here!

@tamiromara : Thanks for your contribution! The author(s) have been notified to review your proposed change.


CAN ID bit layout Figure 4.3

Figure 4.3 Shows the CAN ID bit layout.
There's is a typo in the first table table stating "Service, not message" whereas it's a Message, thus it should note "Message, not service"

This is the logic:

Bit
State

0
Message

1
Service

So the diagram is correct.


process timed out

Hi,
If i use https it works fine.
When i use ssh it doesn't work and i get a process timed out in the logs.
This is the error that i'm getting in the log:
2017-01-05 11:01:28,994 DEBUG [threadpool:thread-703] pmfonseca @MQ10L8x652x915x3 13sq5fn <IP_ADDRESS> SSH - git-receive-pack '/test/svc-fon.git' com.atlassian.stash.scm.BaseCommand Executed C:\Git\bin\git.exe push --prune ssh://git@pre-bitbucket.xxx.pt:7999/visioncenter/test.git --force +refs/heads/:refs/heads/ +refs/tags/:refs/tags/
2017-01-05 11:01:29,001 ERROR [threadpool:thread-703] pmfonseca @MQ10L8x652x915x3 13sq5fn <IP_ADDRESS> SSH - git-receive-pack '/test/svc-fon.git' c.e.stash.hook.MirrorRepositoryHook Failed to mirror repository SVC-FON after 5 attempts.
com.atlassian.stash.exception.ServerException: An error occurred while executing an external process: process timed out
at com.atlassian.stash.scm.git.common.command.GitCommandExitHandler.evaluateThrowable(GitCommandExitHandler.java:113) ~[na:na]
at com.atlassian.stash.scm.git.common.command.GitCommandExitHandler.onError(GitCommandExitHandler.java:159) ~[na:na]
at com.atlassian.stash.scm.DefaultCommandExitHandler.onExit(DefaultCommandExitHandler.java:33) ~[stash-spi-3.7.1.jar:na]
at com.englishtown.stash.hook.PasswordHandler.onExit(PasswordHandler.java:46) ~[plugin.640321809486732222.stash-hook-mirror-1.9.0_1483467141180.jar:na]
at com.atlassian.stash.scm.BaseCommand.callExitHandler(BaseCommand.java:138) ~[stash-spi-3.7.1.jar:na]
at com.atlassian.stash.scm.BaseCommand$CommandFuture.internalGet(BaseCommand.java:251) ~[stash-spi-3.7.1.jar:na]
at com.atlassian.stash.scm.BaseCommand$CommandFuture.get(BaseCommand.java:220) ~[stash-spi-3.7.1.jar:na]
at com.atlassian.stash.scm.BaseCommand.call(BaseCommand.java:75) ~[stash-spi-3.7.1.jar:na]
at com.englishtown.stash.hook.MirrorRepositoryHook$1.call(MirrorRepositoryHook.java:127) [plugin.640321809486732222.stash-hook-mirror-1.9.0_1483467141180.jar:na]
at com.englishtown.stash.hook.MirrorRepositoryHook$1.call(MirrorRepositoryHook.java:115) [plugin.640321809486732222.stash-hook-mirror-1.9.0_1483467141180.jar:na]
at com.atlassian.stash.internal.concurrent.StateTransferringExecutorService$StateTransferringCallable.call(StateTransferringExecutorService.java:147) [stash-platform-3.7.1.jar:na]
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) [na:1.7.0_17]
at java.util.concurrent.FutureTask.run(Unknown Source) [na:1.7.0_17]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(Unknown Source) [na:1.7.0_17]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source) [na:1.7.0_17]
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [na:1.7.0_17]
at java.lang.Thread.run(Unknown Source) [na:1.7.0_17]
... 1 frame trimmed
Caused by: com.atlassian.utils.process.ProcessTimeoutException: process timed out
at com.atlassian.utils.process.ExternalProcessImpl.wrapUpProcess(ExternalProcessImpl.java:656) ~[atlassian-processutils-1.6.0-m2.jar:na]
at com.atlassian.utils.process.ExternalProcessImpl.finish(ExternalProcessImpl.java:161) ~[atlassian-processutils-1.6.0-m2.jar:na]
at com.atlassian.stash.scm.BaseCommand$CommandFuture.get(BaseCommand.java:218) ~[stash-spi-3.7.1.jar:na]
... 11 common frames omitted
Any thoughts?
Thanks in advance

Does it work if you manually run the git mirror command?
C:\Git\bin\git.exe push --prune ssh://git@pre-bitbucket.xxx.pt:7999/visioncenter/test.git --force +refs/heads/:refs/heads/ +refs/tags/:refs/tags/
Is the ssh key added for the user bitbucket runs as?

i forgot to mention that i've already tryed the steps on #18.
Running manually it was showing the certificate error. Then i fixed it and it now runs manually.
Then i tried using the mirror hook and that's when it started to show this process timed out error in the logs.

Experiencing the same issue. Appears to be tied to the size of the repository. I was able to mirror using HTTPS from the same Bitbucket server to CodeCommit, but our largest repo which is around 15GB is not Mirroring.


Paket 5.x references NETStandard.Library twice

Description
While testing it I tried: Paket 5.1.0, 5.1.3, 5.1.4, 5.1.5 and 5.1.6
When using Paket 5.x it references NETStandard.Library twice (kind of).
Repro steps
mkdir solution && cd solution && dotnet new sln
curl -L -o paket.cmd http://bit.ly/2ooaInt
paket init
echo framework: netcoreapp1.1 >> paket.dependencies
echo nuget Grpc >> paket.dependencies
mkdir project && cd project && dotnet new classlib --framework netstandard1.6 && cd ..
dotnet sln solution.sln add project\project.csproj
echo Grpc > project\paket.references
paket install && dotnet restore

Now open this solution with Visual Studio, and:

Unfold "Dependencies", "Nuget" and "SDK". "NETStandard.Library" is in both, but in "Nuget" has yellow warning triangle;
All dependencies of NETStandard.Library as also referenced twice (from "Nuget" and "SDK");
Visual Studio show warning on "Error List" tab: A PackageReference for 'NETStandard.Library' was included in your project. This package is implicitly referenced by the .NET SDK and you do not typically need to reference it from your project. For more information, see https://aka.ms/sdkimplicitrefs

Expected behavior

Only "Grpc" in "Nuget" dependencies ("NETStandard.Library" should be in SDK). This is also how Paket 4.8.8 behaves.

Actual behavior
Dependecies are referenced twice.
Known workarounds
Use Paket 4.8.8.

can you please upload a zip before the step where things go wrong?

This is a zipped folder with solution (note: bin/obj/packages has been removed).
This is Windows batch files actually building this solution (note: requires curl somewhere on PATH)

Oops, missed that:
build.zip - Windows batch file
solution.zip - zipped folder, but bin/obj/packages folders removed

now I have 4 zips?! I just need one and a commad ;-)

Safest (no dependencies):

Upzip solution
Open command prompt inside
Run 'paket.cmd install && dotnet restore'
Open Visual Studio

thx

@MiloszKrajewski What Visual Studio version are you using?

I can repro.
cc @enricosada for ideas

VS 2017 community

Hi,
I've just found this:

[...] Since Microsoft.NETCore.App or NetStandard.Library metapackages are implicitly referenced, the following are our recommended best practices: Never have an explicit reference to the Microsoft.NETCore.App or NetStandard.Library metapackages via a  item in your project file. [...]

and I think this is a reason. When paket generates list of dependencies during build it returns Microsoft.NETCore.App and/or NetStandard.Library so effectively they get referenced twice (implicitly and explicitly).
I guess, those meta-packages do not need to be referenced nor followed.

https://github.com/fsprojects/Paket/pull/2516
@enricosada would this already work for dotnet cli 1.0.4?

we're discussing #2516 with @enricosada - he want's to think about it for a little longer. so I won't merge #2516 for now

The source: https://docs.microsoft.com/en-us/dotnet/core/tools/csproj

I'm also running into this when referencing YoloDev.Expecto.TestSdk, which basically breaks everything.
warning : A PackageReference for 'Microsoft.NETCore.App' was included in your project....

warning MSB3277: Found conflicts between different versions of "System.Runtime" that could not be resolved.

(...).AssemblyInfo.fs(6,12): error FS1108: The type 'IComparer`1' is required here and is unavailable. You must add a reference to assembly 'netstandard, Version=<IP_ADDRESS>

error FS0074: The type referenced through 'System.IDisposable' is defined in an assembly that is not referenced. You must add a reference to assembly 'netstandard'.

Is this an issue with YoloDev.Expecto.TestSdk or Paket?

What was the reasoning behind closing https://github.com/fsprojects/Paket/pull/2516?
Also I seemed to hit the same issue that altemann has.

I'm seeing this with a netstandard dll project which is referenced by two netcore exes.


[zh-cn]sync setup-ha-etcd-with-kubeadm apparmor

content/zh-cn/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md
content/zh-cn/docs/tutorials/security/apparmor.md

/lgtm
/approve


download bytes question

thank you for fixing the download error,
now when downloading using

the perenctage is always 100 %

i think the problem is the total bytes is not the actual total bytes
should i get the real total bytes from the file.info.size?

yes, because in another issue in logs i'm found this
flutter: [2024-05-16 11:42:53.238135] <IP_ADDRESS>:15114> SIZE /Download/Anime_here/One Piece/One Piece ep 968 1920x1080.ts.mkv
flutter: [2024-05-16 11:42:53.541526] <IP_ADDRESS>:15114< 550 No directory traversal allowed in SIZE param

Okay thank you for your awesome work❤


feat(typings): add StrictUnknownQueryResponseResult for libraries

Extracted from @groqz/json. Every time I work on a GROQ typing POC I find myself reaching for this in the core.
This PR also sets up type checking testing suites using vitest and uses it to demonstrate the runtime safety of the new strict response type. We should keep adding more typing test suites so it becomes really easy to avoid introducing unintentionally breaking changes to the TS definitions in the future 🙌

Closing as this ain't it


Configure aceptance test to be run by jenkins

add @RunWith(classOf[JUnitRunner]) annotation and rename test name suffix to IT
ISocketOMongoOperatorsIT is already run by jenkins.

This issue cannot be resolved due to Jenkins freezes when running all tests


Fix typo

prefered -> preferred

@eltociear : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@eltociear Thanks for the typo fix.

@ktoliver Thanks too!


How to access this inside an event function in vue

Using Vue apex charts, i need to access the vue "this" context inside the function. the chart events functions set the "this" keyword to the function scope and i cant figure out how to access the vue "this"
 events: {
            dataPointSelection(event, chartContext, config) {
                   // how to use this within an event function?
                   this.vueData = event
            }
          },

I was able to workaround with this, does anyone have a better method?
  mounted() {
    const that = this
    this.$refs.chart.updateOptions({
      chart: {
        events: {
          dataPointSelection(event, chartContext, config) {
            that.selectedDate = event
          }
        }
      }
    })
  },

Use an arrow function
mounted() {
  this.$refs.chart.updateOptions({
    chart: {
      events: {
        dataPointSelection: (event, chartContext, config) => {
          // you can call Vue methods now as "this" will point to the Vue instance when you use ES6 arrow function
        }
      }
    }
  })
}


IPAM: provider implementation

This is complete: https://github.com/nokia/k8s-ipam, next step is integration which is captured in #18


Update apiserver crd and cert manager images location

@lpbinh can you check?

Thanks, I don't have rights to merge, can you merge it?


KNOX-2762

What changes were proposed in this pull request?
Whitespaces around delimiters were causing problems while specifying composite auth provider names. The parseProviderNames function has been modified to trim provider names before passing it to the Deployment Contributor function.
How was this patch tested?
Ran automated unit/integration tests to ensure provider names did not contain whitespaces. Also ran manual tests to ensure no malfunctions.
Knox Contributing Process reviewed.

Sure, thanks for the comments @smolnar82!

@harshiljhaveri can you post a followup PR with suggested changes?


build: fix release

Coverage remained the same at 100.0% when pulling e11af13ff63091137d0e33342f114d4bc6ec55fa on fix-release into a8eb0d2ca21cf3ad2cb46c7e00b8a15e94c02a4b on main.

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

GitHub release
npm package (@latest dist-tag)

Your semantic-release bot :package::rocket:


Python building Dockerfiles link results in 404 on https://dagger.io/blog/dockerfiles-with-dagger

What is the issue?
Thanks for the great work on Dagger! I noticed that the link for building Dockerfiles under the Python section on https://dagger.io/blog/dockerfiles-with-dagger results in a 404. The 404 link is: https://dagger-io.readthedocs.io/en/latest/api.html#dagger.api.gen.Directory.docker_build .

Thanks so much for the bug report @d33bs!
@mircubed could we fix this in Framer?
We need to replace https://dagger-io.readthedocs.io/en/latest/api.html#dagger.api.gen.Directory.docker_build with this link: https://dagger-io.readthedocs.io/en/latest/client.html#dagger.Directory.docker_build

Thanks for reporting @d33bs! I have updated the blog post link, and the changes will be reflected tomorrow when we push it to production again.


[Phase 2 - Tools] Usability validation to support Static Extension Methods

If usability tests haven't been done earlier, do at least some informal testing on users to see if the limitations on the syntax are frustrating and if there are improvements we should consider.

Closing, we have nothing additional planned here


nativeZip behavior changed

nativeZip complains that it can't resolve  cscore-1.0.2-athena-uberzip.zip, we used to be able to placate it with a copy in libs/ and using --offline but it now complains again.

I have confirmed using wget and curl that GET works for the repository.

You shouldn't be placing any WPI core library in your own libs/ file. GradleRIO manages this for you

Could that be the problem? Cause gradlerio also stalls getting the appropriate library, all others download fine.

Does the same issue occur if you remove your cscore loaded in libs/, and set wpi.cscoreVersion="1.0.1" ?

Also a proper log would be useful


Release Wasmtime 4.0.1

This is an automated pull request from CI to create a patch
release for Wasmtime 4.0.1, requested by @alexcrichton.
It's recommended that maintainers double-check that RELEASES.md
is up-to-date and that there are no known issues before merging this
PR. When this PR is merged a release tag will automatically be
created, crates will be published, and CI artifacts will be produced.

This version bump is being performed for the recent security release announcement and the purpose of putting this up early is to run everything through CI and make sure that CI is in a clean state ahead of time.


GPU memory for training

Hi,
Thanks for sharing the code of this interesting work.
I am trying to run the training on the fastMRI dataset and I got CUDA out of memory issue even with batch size=1.
My GPU is NVIDIA A5000, which has 24G memory.
Could you please tell me how much GPU memory is required to train with batchsize=1?
BTW, I noticed that the memory is gradually increasing for each iteration (batch).
Is that normal? Maybe this is somehow related to the code itself and I didn't notice.
Many thanks! looking forward to your reply.

Hi @ChongWang1024 ,
Approximately 26 GB of GPU memory is required for training on the FastMRI knee dataset. You can decrease the feature dimension to accommodate your GPU.
I haven't observed any gradual increase in memory usage from my end. Could you provide more details about this issue?

Hi @ChongWang1024 ,
Please update the code and then add --low_mem in the training command. This will enable you to use only ~22GB of memory without modifying the model.

the potential reason for memory leakage is the h5py package:
reference:
https://github.com/facebookresearch/fastMRI/pull/217
https://github.com/facebookresearch/fastMRI/issues/215


[5.1-06-12-2019][Runtime] Fix a race with dlopen and libobjc.

Cherry-pick #25150 to 5.1-06-12-2019.
We need to register the macho sections in newly loaded images after ObjC is done doing its thing with them.
rdar://problem/49742015

@swift-ci please test


Use string substitution to avoid translating trademarked text

Hi, this is my first contribution to an open source app.  Please let me know if I'm doing anything incorrectly!
This is meant to address https://github.com/commons-app/apps-android-commons/issues/397.  In the English strings.xml I replaced "Wikimedia Commons" with a placeholder and added a separate string holding the trademarked name.  I added a method to HtmlTextView.java so the html string could be updated programmatically (without being set to the raw text).  In AboutActivity.java I added code to set the the license text.
I'm very unclear on how the translation process works.  For example, is marking the trademarked string with translatable="false (i.e. <string name="trademarked_name" translatable="false">Wikimedia Commons</string>) sufficient?  How do I document the fact that the about_license string has changed and needs translation?
I appreciate any feedback.

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@44d294e). Click here to learn what that means.
The diff coverage is 0%.

@@           Coverage Diff            @@
##             master    #785   +/-   ##
========================================
  Coverage          ?   6.59%
========================================
  Files             ?      99
  Lines             ?    5139
  Branches          ?     466
========================================
  Hits              ?     339
  Misses            ?    4773
  Partials          ?      27

Impacted Files
Coverage Δ

...va/fr/free/nrw/commons/ui/widget/HtmlTextView.java
0% <0%> (ø)

...c/main/java/fr/free/nrw/commons/AboutActivity.java
0% <0%> (ø)

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 44d294e...10637f4. Read the comment docs.

Thanks! :-)

@misaochan What is the process for closing issues (https://github.com/commons-app/apps-android-commons/issues/397 in this case) that have merged PRs associated with them?  I've been looking at open issues and run across some like this (e.g. https://github.com/commons-app/apps-android-commons/issues/670 and https://github.com/commons-app/apps-android-commons/issues/503).  It's not clear to me if an issue remaining open means that more development is required (I should investigate working on it) or just that it hasn't been closed yet (I should skip over it).

@mwoguri Yeah, sorry, those issues should be closed. Sometimes we forget to do so, as this is a community-maintained project so no one is actually tasked with keeping an eye on issues. :) If you are unsure about a particular issue, please feel free to ping one of the core developers (those with "Collaborator" roles) and ask. Thanks!


[Fix](multi catalog)Fix nereids context table always use internal catalog bug (#21953)

The getTable function in CascadesContext only handles the internal catalog case (try to find table only in internal catalog and dbs). However, it should take all the external catalogs into consideration, otherwise, it will failed to find a table or get the wrong table while querying external table. This pr is to fix this bug.
Proposed changes
Issue Number: close #xxx

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

Please link the master PR