I can't find the interface after updating comfyui.

can you cd custom_nodes/comfyui-workspace-manager and git pull? and restart your python server?
if that's not working, can you in your terminal in custom_nodes/comfyui-workspace-manage dir, can you git checkout main and restart server?

let me try try...
PS E:\IMAGE\ComfyUI_test\ComfyUI\custom_nodes\comfyui-workspace-manager> git pull
error: Pulling is not possible because you have unmerged files.
hint: Fix them up in the work tree, and then use 'git add/rm '
hint: as appropriate to mark resolution and make a commit.
fatal: Exiting because of an unresolved conflict.
PS E:\IMAGE\ComfyUI_test\ComfyUI\custom_nodes\comfyui-workspace-manager> git checkout main
error: you need to resolve your current index first
dist/workspace_web/input.js: needs merge

it seems you made some local changes to it...
you can git reset --hard HEAD

if nothing is working, you can delete the comfyui-workspace-manager folder and reinstall, you should still have all your data

fixed afer pull again


TC176: Deploy Mount

If the disk is larges than the original drive (10 GB) fails with:
Error: error waiting deployment: workload 1 failed within deployment 2886 with error no space left on device

How is the original disk related in this case?

@georgeconstantinou please reproduce if this still valid


Update replication retry policy

What changed?
Use a less aggressive rpc replication retry policy

Why?
With the original retry policy, the DB gets flooded when it throws service busy error

How did you test it?
Pre prod env

Potential risks
flood the DB

Coverage decreased (-0.2%) to 67.078% when pulling 13b52e84c8343c2e8a34f84904f998d769987eea on yx_replication into 208c34f4be116928f70e65e76f6a4d6d87af7ce1 on master.


fix money input binding andOffset width error

Fix

In cover-ui I was seeing and error on offSetWidth
in cover-ui I realized the two way binding of value had been broken

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Internet Explorer 8

Hi,
I have been investigating this wonderful library and I am very keen to use it in some future products.  Unfortunately, it does not appear to support IE 8 which is still very much in use in the Corporate environments I deal with.  Can you please advise if you are likely to support version 8 and, if not, if any changes are likely that will at least make it render in a more usable fashion than it currently does (see screenshot)
Many thanks
Sean :-)

<script src="/assets/javascript/elements.html5shiv.js"></script>
<script src="/assets/javascript/elements.html5shiv-printshiv.js"></script>
<script src="/assets/javascript/elements.selectivizr-min.js"></script>
<script src="/assets/misc/css3pie/PIE_IE678.js"></script>

Where download???

Beginning with next year Microsoft will not support IE8 anymore:
http://blogs.msdn.com/b/ie/archive/2014/08/07/stay-up-to-date-with-internet-explorer.aspx?utm_medium=referral&utm_source=pulsenews

2.0 will not support IE9 either


test: run integration tests using workload identity federation for GitHub actions

Uses https://cloud.google.com/blog/products/identity-security/enabling-keyless-authentication-from-github-actions

@Neenu1995 @eaball35 You should be aware of this PR

We're looking into how to scale this for all our repos.

@chingor13 any update on this?


Backward compatibility for Accord Templates v0.6

There should be a way for the new version of Cicero (implementing v0.7 of the accord project template specification) to execute older templates (implementing v0.6 of the accord project template specification).

There are a couple of patches in #113 which should be replaced by a more robust/well tested approach.

Probably the execute call should detect whether it's running a v0.7 or v0.6 template https://github.com/accordproject/cicero/blob/master/packages/cicero-engine/lib/engine.js#L137

@mttrbrts @dselman feedback?

There was some follow up cleaning of the corresponding code. We won't support backward compatibility within the same Cicero engine. Closing.


licensor: add patch to fix tests

Motivation for this change
Fix build (https://hydra.nixos.org/build/166243574)
Things done

Built on platform(s)

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

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

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

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

1 package built:

licensor


Keyboard Events are not created correctly.

I have a failing test to show that this library doesn't actually work because the keyboard events are not created correctly. I'm quite sure simkey is doing it correctly by creating a KeyboardEvent. I'll update this PR with the fix, but wanted to show the failing test (hopefully, I know SauceLabs doesn't run during a PR.)

Isn't this expected behavior? I don't believe the browser will actually change the value of inputs without real user input.

Closing as I believe this is expected behavior. Please reopen with more information if you believe that I'm wrong.


Eslint

Changes

Adds elint support and drops tslint as a dep
Formats all repo files using prettier and eslint (.ts, .json, .md) with reasonable settings
Fixes the hook which was previously broken
Adds linting as part of our CI

@krvajal You might want to have a look but given that these are changes brought by the linting/formatting tools along with normal maintenance work it is not that important. I will be merging this branch soon, once I manage to update the husky git hook from v4 to v7.

I will leave the husky to v4 because I would have to update my local npm version to 7.x. Last time I did that I had problems with compiling the extension and hence I had to revert.
The procedure is highlighted in https://github.com/typicode/husky-4-to-7


Secondary indices for vector search

In #993, I introduce a search index that has to be manually constructed on each edit of a sample. This is optional, and not particularly resource intensive (though should be benchmarked). The same approach could be taken to enable vector search. As this would be quite niche, I think simply using something like https://github.com/asg017/sqlite-vec could work well, and would allow for much more powerful AI agent use.
cc @jdbocarsly

This is also something that could be developed as an "offline" search index in the yellowhammer repo, i.e., download all public data from a deployment, create the index/embedding, then add an sqlite layer on the client-side.


Add note about error you will receive with port 445 closed

Add additional note about receiving "failed to connect to azure storage '' with os error 53" when you do not read the requirements properly.

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

@MashaMSFT, can you review this PR? Thanks.

Hi @felickz , thanks for your contribution! You are correct, this is a nice expansion and can help clarify issues for our customers. #sign-off

@MashaMSFT: I'm sorry - only the author of this article, @allenwux, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.

Is the '' meant to be a placeholder? Can we clarify that? Thanks.

are you referring to the '  ' in the middle of "failed to connect to azure storage  ' ' with os error 53"  ?? If so, yes, that'll be the name of the storage account. We can replace it with failed to connect to azure storage <storage account name> with os error 53.
Thanks!

Thanks, @MashaMSFT. Is this whole string an error message:
"failed to connect to  with os error 53"
Or is the "with os error 53" NOT part of the error message?

Yes, the whole error string is failed to connect to azure storage <storage account name> with os error 53

Great, thanks.

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


Translate the application to French

@mathkruger
hello, Are you interested in adding French as a language to the application?

Hey! Well, I don't speak french, but, if you speak, feel free to create a PR with the translation!

Closing because of the PR #32


Add support for co-located .sface templates

Resolves #22
I patterned this closely off how live view handles the same functionality, but I couldn't figure out how to write tests for it. It should be somewhat straightforward to add support for stylesheets once we add that functionality.
I added the before compile hooks to the individual types of component instead of BaseComponent because MacroComponent uses BaseComponent as well and I figured that shouldn't have a render function automagically defined.
I could see adding support for falling back to a .html.leex, but haven't added that in. WDYT?

Hey @lnr0626!
Fantastic job!

I couldn't figure out how to write tests for it.

You can try to create a component for each type along with their respective .sface templates and save them in the test/support folder, then you can use them your tests just like you'd use any other component. Something like:
defmodule Surface.RendererTest do
  use ExUnit.Case, async: true

  alias Surface.Components.ComponentWithExternalTemplate
  alias Surface.Components.LiveComponentWithExternalTemplate
  alias Surface.Components.LiveViewWithExternalTemplate

  import ComponentTestHelper

  defmodule View do
    use Surface.LiveView

    def render(assigns) do
      ~H"""
      <ComponentWithExternalTemplate/>
      <LiveComponentWithExternalTemplate/>
      <LiveViewWithExternalTemplate/>
      """
    end
  end

  test "Component rendering external template" do
    assert render_live(View) =~ """
           the rendered content of the component
           """
  end

  test "LiveComponent rendering external template" do
    assert render_live(View) =~ """
           the rendered content of the live component
           """
  end

  test "LiveView rendering external template" do
    assert render_live(View) =~ """
           the rendered content of the live view
           """
  end
end

I could see adding support for falling back to a .html.leex, but haven't added that in. WDYT?

I think we could start accepting only .sface files for now. We can then add support for .html.leex in the future.

Thanks! That did it.

@lnr0626 thanks! ❤

This looks great. One question, do you need your top-level component to be inlined in render() as these tests show or can it be external as well? If so what would that look like?

@matthewp you should not need to have the top level component inlined

@lnr0626 great, how would you render it then? (sorry if this seems obvious, I'm new to Phoenix)

This doesn't change how you use the views/components, so you should be able to use them like normal. If you're using the view within the router, the you can do:
defmodule MyRouter do
  ...
  live "/route", MyView
  ...
end

if you're using it within another surface component/view, then you should be able to do something like:
defmodule MyOtherView do
  ...
  def render(assigns) do
    ~H"""
    <MyView />
    """
  end
end

If you're running into issues feel free to create a new issue or join the elixir slack - it's hard to see questions and responses on this PR because it's already closed


As a cook, I can browse recently cooked recipes

so I can have easy access in case I forget.

view by recent not implemented


[flutter_image] Web support

Use case
Use NetworkImageWithRetry to retry certain exceptions when fetching images for web.
Proposal
NetworkImageWithRetry should support web.
Thanks.
Regards.

Duplicate of https://github.com/flutter/flutter/issues/89481.
Kindly see https://github.com/flutter/flutter/issues/89481#issuecomment-914402919 and https://github.com/flutter/flutter/issues/39998 for why this isn't possible yet.
Closing from here as duplicate


Set up periodic runs of presubmit checks (to detect any API regressions)

Tracked in internal bug.


Some sources are not exported to -source.jar

… because of that, we cannot jump to definition in IDEs (ENSIME and IntelliJ tested, see https://github.com/ensime/ensime-server/issues/492#issuecomment-160409525), to e.g. org.scalatest.prop.GeneratorDrivenPropertyChecks defined in https://github.com/scalatest/scalatest/blob/ab3ae78567b6461246ce8b30de08d55a7fbc7df9/project/GenGen.scala#L578.
Cc: @fommil

Thanks for letting us know. That source file is generated, but it would definitely be good to have the generated source in the jar too. I didn't realize it was missing.


[Bug] Time not displayed on profile without restarting Discord after plugin activation

Addon
Timezones
What happened?
If I enable the Timezones plugin, the time of a user with a configured timezone will not be displayed on his profile (profile on the right of the messages or right-click profile) without a restart of Discord, even though the time next to the messages is correctly displayed.
What Discord version do you have this issue on?
Stable, PTB
(I haven't personally tested it on Canary, but I assume that the problem is also present(?))
Code of Conduct
- [X] I agree to follow this project's Code of Conduct

Can you please test with the latest commit

Can you please test with the latest commit

Unfortunately that doesn't seem to work, Stable or PTB.
Re-enabling the plugin doesn't display the timezone on the user's profile, a restart of Discord is still required.

@Lucatir

I am using the plugin version 1.1.1 and I do not see the timezone in the user's profile in any situation (checked both the popup and full profile since I forgot which was supposed to show it), but as the original reporter posted, I can see it just fine in their messages.

Same for me now.

:)

Hello,
In PTB at least, the timezoned time does appear in the general profile, but not in the small profile menu to the right of the messages with the person.

Timezones worked briefly with Timezones 1.1.2 update, but then Discord (main client) pushed out an update, and now timezones do not show again, neither in individual messages, nor in the DM's right-side panel.

Please try again with v1.2.0, if still broken, I will reopen

Please try again with v1.2.0, if still broken, I will reopen

For my part, I'm not sure it works, on PTB.

Thank you,
Lusiiky


Version Release Docs

Is there anywhere you would recommend @bobturneruk to start creating development documentation? I've added this to the main documents for now.

I think the main docs are fine. Perhaps a contributing.md in the docs folder would also be picked up by GitHub and put on the repo. landing page.


App Crashing after updating the <IP_ADDRESS> from <IP_ADDRESS>

I'm using this control and good working with <IP_ADDRESS>
But after I updated it to <IP_ADDRESS>, my app is crashed when first launching, and I can't catch any exception.
I can see only this error on the Output of VS.
Exception thrown: 'Avalonia.Markup.Xaml.XamlLoadException' in Avalonia.Markup.Xaml.dll

I solved this issue.
<StyleInclude Source="avares://Dock.Avalonia/Themes/FluentTheme.axaml" />
to
<StyleInclude Source="avares://Dock.Avalonia/Themes/DockFluentTheme.axaml" />


Consider allowing the publication.zip name which is published to the portal to be altered

I recently used this again to publish a second library (crazy, I know 😅) and I realized in the publishing list it's just a long list of the same name

Making it actually indistinguishable from each other. It literally has a Deployment ID and a date, I have no idea what it is for when I press publish 😅
Probably something for them to fix in some way to make that UI a bit more friendly, but until then this could at least help me name the zip file to the library name, if not even with the version name? Not sure if that'd break anything. And not sure if the nmcp library do something more internally to get the version number or whatever. This should be a great minimal effort -> great benefit change.
I am really really not familiar with working with plugins like this so I'm gonna make a best effort PR, but I am not 100% sure how I could test it locally either. Lmk if I should change something :D
Also this assumes that one can just name this whatever. Not sure if the API would be happy with that 👀

Did https://github.com/GradleUp/nmcp/pull/4 if you could take a look anytime 😊

Fixed by https://github.com/GradleUp/nmcp/pull/4 and https://github.com/GradleUp/nmcp/pull/6


Outdated Content

This page still leverages the classic build and releases vs the new YAML releases. Would be more benefical if it was updated with the new YAML Pipelines. This will better align with the Azure DevOps roadmap. I can provide some YAML of it would be beneficial to the community.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: ea9d58d3-169a-2ffd-5bcf-02daa8d8ac04
Version Independent ID: a4ae226e-1622-fb62-cfb6-d06bc7c35e84
Content: Automating infrastructure deployments in the Cloud with Terraform and Azure Pipelines - Azure Pipelines
Content Source: docs/pipelines/release/automate-terraform.md
Product: devops
Technology: devops-cicd-release
GitHub Login: @ramiMSFT
Microsoft Alias: rabououn

Any update on this?  More than willing to help get it turned around faster to help others out.

@JFolberth Thank you for your feedback. A backlog item has been created to update the article to address the issue you've raised.


Could not reach service1-instance1/private on port 80 or docker run --rm exits with error

docker run --rm -i --net cilium-net -l id.service2 cilium/demo-client curl -si http://service1-instance1/public
A docker run command can be split in 3 separate events: docker create, docker start and docker exec.
For docker create it calls:

docker cilium libnetwork plugin, which calls:

the cilium-agent via PUT /endpoint/{id} request which generates

(1) bpf program build

send response back to docker cilium libnetwork plugin

docker concludes the create step

For docker start it creates a docker event:

cilium-agent receives the event via docker listener

builds a (2) bpf program

replace the program from (1) with this new bpf program.

For docker exec, docker runs the specified command:

curl -si http://service1-instance1/public

some ARP requests are sent, never receive the responses

docker exec errors out with code != 0

Why does docker exec error out if the bpf program is already in place?
Although bpf program (1) is build and attached to the interface by the time the docker create step is complete, that bpf program has no policy loaded, meaning ALL packets will be dropped.
By the time the curl command from docker exec is sending the ARP requests, the bpf program (2) is being build, with the proper policy. While this bpf program is being build and attached to the network interface, docker exec has already exited.

Excellent analysis. We need to have bpf program (1) respond to ARP requests. That should not be difficult.

For future reference, we can read the labels when we receive docker create event, because the labels are sent along with the event since docker 1.10 (IIRC), but that doesn't help us because we also need the IP associated with the container so we can derive the endpoint ID and create an endpoint, and that is only present after we receive the docker start event.

For future reference, we can read the labels when we receive docker create event, because the labels are sent along with the event since docker 1.10 (IIRC), but that doesn't help us because we also need the IP associated with the container so we can derive the endpoint ID and create an endpoint, and that is only present after we receive the docker start event.

We could allocate an IP earlier if we wanted. It takes away the IP allocation feature via Docker though.
In either case, I think we agree that the first step is to enable ARP during the unknown-policy block phase.

@tgraf Could you give be a simple policy file that allows all traffic, I'm not up too speed with the new policy model yet and getting started guide is not yet up-to-date?

Never mind, I used this:
[{
"endpointSelector": ["id.service1"],
"ingress": [{
"fromEndpoints": [
["reserved:host"], ["id.service2"]
]
}]
}]


[Snyk] Security upgrade nuxt from 2.15.8 to 3.0.0

This PR was automatically created by Snyk using the credentials of a real user.![snyk-top-banner](https://github.com/andygongea/OWASP-Benchmark/assets/818805/c518c423-16fe-447e-b67f-ad5a49b5d123)
Snyk has created this PR to fix 1 vulnerabilities in the npm dependencies of this project.
Snyk changed the following file(s):

package.json
package-lock.json

Vulnerabilities that will be fixed with an upgrade:

Issue
Score

Server-Side Request Forgery (SSRF) SNYK-JS-IP-7148531
  718

[!IMPORTANT]

Check the changes in this PR to ensure they won't cause issues with your project.
Max score is 1000. Note that the real score may have changed since the PR was raised.
This PR was automatically created by Snyk using the credentials of a real user.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
📜 Customise PR templates
🛠 Adjust project settings
📚 Read about Snyk's upgrade logic

Learn how to fix vulnerabilities with free interactive lessons:
🦉 Server-Side Request Forgery (SSRF)

👷 Deploy Preview for competent-cray-5c2b99 processing.

Name
Link

🔨 Latest commit
cb2b7c26a55e6c8db6a4a82afb2aff7672fc6696

🔍 Latest deploy log
https://app.netlify.com/sites/competent-cray-5c2b99/deploys/6656577a68d1c900084cca58


Update Question and Game cards according to the new design

Update the existing card design and replace it with the following implementation
The following image may be replaced with another design so refer to the figma here

">

Because of changes made to the Figma design of the Dashboard, the MVP will only have the Games Dashboard (as the Questions Dashboard has been removed for now). The Games Dashboard has already been updated to the current Figma design and merged into sprint1-branch, therefore this issue is currently done.


Identify if a job offer permits remote working

Backgrounds
At this stage, there is not a checkbox to indicate if a job vacancies is a remote job.
Issue
Nowadays, many people need to know if a job is remote. People can apply to a job in another city or country if it's a remote job or just work remotely because it offers a more flexible lifestyle.

Potential approaches
Solution 1
Do nothing. This info can be included on Job Description field.
be free to vote with :-1:
Solution 2
Add "Is remote" on Jobs as a new field:
be free to vote with :+1:
class Job(models.Model):
    # ...
    is_remoting = models.BooleanField("Is remoting", default=False, )

Other alternative solutions.
please, be free to post your own as a new comment.
More screenshots

Great, many thanks @ctrl-alt-d 🍻
I think that this will improve job offer details :)
Just as an idea, maybe is a good approach if we try to identify the list of possible values instead of a boolean flag:

no remote
partially remote
full remote
...

Thoughts?

@ctrl-alt-d @XaviTorello perhaps a better solution could be a percentage where 0% is no remote and 100% is fully remote, allowing values with 10 units steps. Also with a comment if details are needed.


Some quick made suggestions for background and banners

Related to https://github.com/nordic-rse/nordic-rse.github.io/pull/311

Thank you!


chore(deps): update dependency @types/marked to v5

This PR contains the following updates:

Package
Type
Update
Change

@types/marked (source)
devDependencies
major
^4.0.8 -> ^5.0.0

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

⚠ Artifact update problem
Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.
♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

any of the package files in this branch needs updating, or
the branch becomes conflicted, or
you click the rebase/retry checkbox if found above, or
you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:
File name: package-lock.json
npm ERR! code ERESOLVE
npm ERR! ERESOLVE could not resolve
npm ERR!
npm ERR! While resolving<EMAIL_ADDRESS>npm ERR! Found<EMAIL_ADDRESS>npm ERR! node_modules/@types/marked
npm ERR!   dev<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR! node_modules/ngx-markdown
npm ERR<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Conflicting peer dependency<EMAIL_ADDRESS>npm ERR! node_modules/@types/marked
npm ERR!   peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!   node_modules/ngx-markdown
npm ERR<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR!
npm ERR!
npm ERR! For a full report see:
npm ERR! /tmp/renovate/cache/others/npm/_logs/2023-08-01T21_13_22_562Z-eresolve-report.txt

npm ERR!  You will not get PRs for any future 5.x releases. But if you manually upgrade to 5.x then Renovate will re-enable minor and patch updates automatically.
If you accidentally closed this PR, or if you changed your mind: rename this PR to get a fresh replacement PR.


Initial clean up of project statistics popup

Summary of changes
Changes in styling
Pie chart extracted into a separate component to use it for next pie charts
Refactoring
Context and reason for change
Need to prepare for introduction of more pie charts.
Initial fix #1011

For changes in styling, before/after screenshots would be helpful for the reviewer.

Optional remark: The legend for the pie chart is a bit far away from the actual pie chart. One could think about either moving it closer to the pie chart or adding a box around the whole (pie chart + legend) to make it clear to the viewer that the legend belongs to the pie chart.


tiflash can't gc completely after set tiflash replica 0

Bug Report
Please answer these questions before submitting your issue. Thanks!
1. Minimal reproduce step (Required)

2. What did you expect to see? (Required)
3. What did you see instead (Required)
4. What is your TiFlash version? (Required)
master

Since we use a lot of logical split now, the estimated rows and size (which is based on pack statistics) is no longer accurate. The inaccurate rows and size misleads the GC and prevented DTFiles being recycled.

An example is that a segment with range [27192,30593), while the DMFile in stable contains two packs. The first pack contains rows [16994, 23791) ∪ [33991, 35386) and the second pack contains rows [35386, 37381).
No data is valid under the segment, which is generated by logical split, but now we can not execute gc on segment like this. Now the gc routines use the min-max index for decision-making
https://github.com/pingcap/tiflash/blob/6a305d375bcf9827a35d0ff21c938f4ebd32d8ea/dbms/src/Storages/DeltaMerge/DeltaMergeStore_InternalBg.cpp#L391-L400
https://github.com/pingcap/tiflash/blob/6a305d375bcf9827a35d0ff21c938f4ebd32d8ea/dbms/src/Storages/DeltaMerge/StableValueSpace.cpp#L400-L434


This code does not work.

I have followed the instructions, and tried many different programming hacks, yet nothing is successful.  It does nothing.  No functionality, no styling, nothing.

Yes its running here http://hometesterclub.co.id/

Please add information when you report an issue, if not nothing can be done.


About > Doing business with us -- contact info

we have a rule to remove personal contact information and to use contact CMS. we should enforce that rule here in case<EMAIL_ADDRESS>leaves CFPB.

To clarify, we should 1) create a new "doing business with us" contact and then 2) use the primary email for that contact instead of<EMAIL_ADDRESS>right?
Do you have an email to use as the primary email for "doing business with us"?

Yes, you are correct. I do not have another primary email address. This is also something we need to review with James.

move it to jira


C# installation Shell Script

OMG

OMG

@Rupesh282 welcome to the battlefield ! the war has begun ! :sunglasses:

It’s only once you’ve stopped that you realize how hard it is to start again.

OMG

Because sometimes, even if you know how something’s going to end, that doesn’t mean you can’t enjoy the ride. :1st_place_medal:


feat: add json schema validation with ajv

fixes #859

MR should be ready now

@ANGkeith I've approved, I'll test and publish a new version tomorrow, if you have merged this by then.


RangeDateFilter results in a 500 error if we send a date in an invalid format

If we write a date in the DateRangeFilter's text widget and we use an incorrect format, the page returns a 500 error with the following message: ['“06-01-2023” value has an invalid date format. It must be in YYYY-MM-DD format.']

The input that results in a 500 error
Could it be possible to catch this error and display this as an error message on the input field instead of crashing the page? Similarly to how the error is handled in Django's change form

Error being handled in Django's change form.

Hey, I already tried several times to replicate the issue but I was not able to find a way how to do it. Could you provide some minimal example how I can reproduce the issue? Thanks

Hey @lukasvinclav, we ended up writing a custom class to inherit from the Unfold implementation to catch the error.
To cause the original bug, define a model admin with the following filters:
list_filter = (
        ("date_field", RangeDateFilter),
    )

When done, put in any text except the valid format and hit save. The validation error is uncaught and triggers a 500.
Here's our solution which should give you an idea of what needs doing:
class CustomRangeDateFilter(RangeDateFilter):
    def queryset(self, request: HttpRequest, queryset: QuerySet) -> QuerySet:
        """
        Override the queryset method to catch validation errors and display them as messages instead of raising
        exceptions.
        """
        try:
            return super().queryset(request, queryset)
        except ValidationError as e:
            # Remove the hour/minute/second/microsecond/TZ part of the error message from DateTimeFields for
            # readability.
            reformatted_messages = [message.replace("HH:MM[:ss[.uuuuuu]][TZ]", "") for message in e.messages]
            messages.error(request, "\n".join(reformatted_messages))
            return queryset

Thanks for explanation. Now everything is clear with the fix already in main branch.


VictorOps api-key  via file feature

Adding features for inserting VictorOps-api-key secret through file - as suggested in this issue. I haven't tested in local not much familiar with GO, working on that. Any high level review will be really helpful - if I am going in right direction or not. Thanks

@beorn7 could you please help out here a bit, not sure why getting so many test case failure. I followed the same structure as that slack_api_url_file commits.

The first thing to fix is easy: Add the DCO. See https://github.com/prometheus/alertmanager/pull/2554/checks?check_run_id=2426690259 . No Go knowledge required. (o:

You have partially reverted recent changes that added support to read the Slack URL from a file. That's also the reason why the tests and the build fail.
Perhaps you have branched of from the master branch before that feature was merged, and then you did not resolve the merge or rebase properly? I'll add a few comments where this happened.


Create GitHubDemoFileNew

This is an experiment
print('This is an experiment')

Hope it Works...

Hope it Works...


Fix Airtable loader

Airtable loader is throwing an error due to improper array access.

Fixed by #44


Bump kubectl to 1.26.13

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (ee973fb) 37.82% compared to head (ff3611a) 37.82%.
Report is 7 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #534   +/-   ##
=======================================
  Coverage   37.82%   37.82%
=======================================
  Files          50       50
  Lines        3191     3191
=======================================
  Hits         1207     1207
  Misses       1855     1855
  Partials      129      129

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


[Bug?]: Client bundle including imports from "use server" functions

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Current behavior 😯
Vinxi and Vite are bundling dependencies that are only used in "use server"; functions. For example:
import { Resource } from 'sst';

export function getPublicResources() {
  "use server";
  return {
    apiUrl: Resource.APIRouter.url
  } satisfies PublicResources;
}

Vite throws this error during client bundle:
[8:36:13 PM]  ERROR  ../../node_modules/sst/dist/resource.js (1:9): "env" is not exported by "__vite-browser-external", imported by "../../node_modules/sst/dist/resource.js".
file: .../Code/revelationsai/node_modules/sst/dist/resource.js:1:9

1: import { env } from "node:process";
            ^
2: const raw = {
3:     // @ts-expect-error,

Here is my app.config.ts:
import { defineConfig } from '@solidjs/start/config';
import { searchForWorkspaceRoot } from 'vite';
import { cjsInterop } from 'vite-plugin-cjs-interop';
import tsconfigPaths from 'vite-tsconfig-paths';

export default defineConfig({
  middleware: './src/middleware.ts',
  server: {
    preset: 'aws-lambda'
  },
  vite: {
    plugins: [
      tsconfigPaths(),
      cjsInterop({
        dependencies: ['@clerk/clerk-js']
      })
    ],
    server: {
      fs: {
        allow: [searchForWorkspaceRoot(process.cwd())]
      }
    }
  }
});

Workaround
I can get it to bundle successfully by moving the server function to a separate file and put "use server"; at the top.
Expected behavior 🤔
"use server"; dependencies should only be included in ssr and server bundles
Steps to reproduce 🕹
Steps:

In app.tsx create a server function that imports a server-only module like node:async_hooks
Try to build the app

Context 🔦
This is completely blocking my project. I cannot have all my server code sectioned off with my desired design.
Your environment 🌎
No response

So I have narrowed it down to if I use "verbatimModuleImports": "true" that is causing the problem.

Reproduction: https://stackblitz.com/edit/github-fk8exj-eru4op?file=src%2Fapp.tsx

tldr; use dynamic imports so that build tools can analyze and tree-shake correctly
dropping this here to spread awareness


Set Cache-Control headers

Description/Context
Many of our static assets are currently missing a Cache-control header, so requests revalidate with the server and wait for a 304 Not Modified response before using cached resources. Usually the cached assets have not changed and could be used without revalidation. This includes course_v2.<hash>.css, which is hashed and is the only non-cached, render-blocking resource for course sites.

Plan
We should set relevant cache-control headers. It seems to me that there are two cases:

static resources with hashed filenames: These could use Cache-Control: max-age <very large>,
assets that don't have a hashed filename

For assets that don't have a hashed filename (e.g., ocw_logo_white_v2.svg) we could either set a reasonable max-age like 1 week, or we could start hashing them (either with Webpack, or possibly with Hugo's fingerprint. Or something else.

Presumably, adding a cache-control header would have to be done in Fastly. Via the VCL?

Presumably, adding a cache-control header would have to be done in Fastly. Via the VCL?

Based on the Fastly docs, I believe that's correct.

Setting cache-control headers for static hashed resources is simple enough; in src/ol_infrastructure/applications/ocw_site/snippets/ttl_setup.vcl we'd just need to add the header with a pattern matching the resource names.
Possible solutions for non-hashed static assets:
Let's first look at how we are using these assets, eg. in a partial,
 And we're using them like this say around 35 times.
Using Webpack
We would have something like [contenthash] or [fullhash] here in webpack.common.ts:
new CopyWebpackPlugin({
patterns: [
{ from: "./base-theme/assets/static_shared/images/", to: "images/[name][contenthash][ext]" }
]
}),
The problem we would face is, we are directly calling our assets with their names in the partials. If we do this, we would not know the name of our transpiled asset anymore. We'd have to loop through the assets, or search over them, maybe create a mapping of sorts. Would need to look more over possibilities of this.
Using Hugo's FingerPrint
This works directly, like this:

the resources.Get function will only look under directory assets/something and so we'd have a problem if we use: "assets/images" because then in server we'd have the hashed URL: localhost:3000/images/logo_img[hash][ext] and we don't want that. We want it for localhost:3000/static_shared/images/logo_img[hash][ext]
A solution to this is, moving our assets directory, say images, from/assets/images/to /assets/static_shared/images/ and making the appropriate change inside webpack.common.ts. Then our web server will have the correct URL for hashed assets.
Using either of the above approaches allow us to use a large max-age (eg. a month) for cache-control headers.
Not hashing assets
If we do not hash those resources, then we should use a small max-age (eg. a week) as mentioned in the ticket. This is to ensure that if we have stale content, we only have it for maximum of a week.
I'm currently implementing Hugo's Fingerprint solution. Making changes in all the files where we're using those assets to include a Fingerprint.

@ChristopherChudzicki  I wanted to confirm.
Using the Hugo's Fingerprint makes the ticket wide-scoped. As mentioned above, this would require to modify every line of code where /static_shared/images/ or /static_shared/fonts/ is used in order to include the hash. The change itself is simple -- but it's in over 35 places. It's the testing that would require more time -- to ensure every change is working as expected.
However, I do also believe the same we would have to do in case if we go with webpack changes. We'd have to change every line of code where they are used. And the testing would be same.
@pdpinch if we go with this approach, implementing would take only few hours, but testing could take around 2 days (more or less depending on the nature of changes involved).
So I want to confirm should we go with this or just rely alone on setting max-age to 1 week (to unhashed assets).

@ibrahimjaved12 In my opinion, if you change how we load static assets to something like
// Original
<image src="/static_shared/path/to/file.png" >
// Changed to
<image src="{{ partial "hashed_file.html" "/static_shared/path/to/file.png"  >
// with partial hashed_file.html:
{{ $file := resources.Get "/static_shared/path/to/file.png" }}
{{ $hashed := $file | resources.Fingerprint "sha512" }}
{{ return $hashed }}

Notes:

Original is error prone: In the original case, if /path/to/file.png was missing or had a typo, etc, we would only catch the error by visual inspection. 😦😦
New way is better: In the new approach... We get the hashes we need, good. But we also get free error checking. The build will fail if the file is missing. Loud error. Yay. 😁

Because the build will fail if a file is missing, you should, IMO, be very confident in the change after some initial smoke testing. I'm not sure it's worth checking each and every asset individually (though that might not be so hard.).
 If /path/to/file doesn't exist, the error is something like Cannot call fingerprint on resource  nil. It might be worth adding an explicit if resource is nil, panic("useful error message"). 🤷

@ibrahimjaved12 In my opinion, if you change how we load static assets to something like
////////// Original
<image src="/static_shared/path/to/file.png" >

////////// Changed to
<image src="{{ partial "hashed_file.html" "/static_shared/path/to/file.png"  >

//////////  with partial hashed_file.html:
{{ $file := resources.Get "/static_shared/path/to/file.png" }}
{{ $hashed := $file | resources.Fingerprint "sha512" }}
{{ return $hashed }}

Notes:

Original is error prone: In the original case, if /path/to/file.png was missing or had a typo, etc, we would only catch the error by visual inspection. 😦😦
New way is better: In the new approach... We get the hashes we need, good. But we also get free error checking. The build will fail if the file is missing. Loud error. Yay. 😁

Because the build will fail if a file is missing, you should, IMO, be very confident in the change after some initial smoke testing. I'm not sure it's worth checking each and every asset individually (though that might not be so hard.).
 If /path/to/file doesn't exist, the error is something like Cannot call fingerprint on resource nil. It might be worth adding an explicit if resource is nil, panic("useful error message"). 🤷

That's actually a clever way to check for errors. So now we would be implying on Hugo to report error -- otherwise it would be up to img tag and we'd just have a broken image visually. (or broken font)

Is the plan to turn every static file reference into a template? How many are there? Does it make sense to focus on large files, or is it all or nothing?

Is the plan to turn every static file reference into a template?

No. My suggestion was for a reusable "hashed_file" partial:
<image src="{{ partial "hashed_file.html" "/static_shared/first_logo.png"  >

<image src="{{ partial "hashed_file.html" "/static_shared/another_file.png"  >

<image src="{{ partial "hashed_file.html" "/static_shared/one_more.png"  >

How many are there?
I'm not sure how many static file references we have— @ibrahimjaved12 said more than 35.

Does it make sense to focus on large files, or is it all or nothing?
I don't think filesize matters. It's all or nothing in the sense that anything that doesn't get hashed won't update until max-age expires.

This ticket has been completed with the PRs:
https://github.com/mitodl/ol-infrastructure/pull/1857
https://github.com/mitodl/ocw-hugo-themes/pull/1272
https://github.com/mitodl/ocw-studio/pull/2017


Turbo Preloads should not be prevented when using the closest Turbo Frame

I'm reporting what I think is an issue introduced in #1033. The aim of this change as I understand it is to prevent unnecessary preloading of Turbo links where turbo-preload is present. However, I think it goes too far and prevents preloads for Turbo Frame requests that I think should be allowed. I have a practical use-case where this behaviour is desired documented further down.
The preloading behaviour appears to be prevented specifically by this line:
const frame = frameTarget == "_top" ?
  null :
  document.getElementById(frameTarget) || findClosestRecursively(element, "turbo-frame:not([disabled])");

My understanding is:

If the frameTarget is "_top" then frame is set to an explicit null
Otherwise; Attempt to find the element by the data-turbo-frame attribute.
Otherwise; Get the closest <turbo-frame>

Then if it's present and a kind of FrameElement a prefetch will be prevented.
In my example, I have tabbed content within a page containing other content. I wish for users to be able to click the tabs and for the content to be shown instantly since it has been prefetched. See my diagram for more information:

If I set my data-turbo-frame="_top" this causes it to work as expected but does mean that I'm loading and replacing the whole document rather than just the frame I'd like.
In Turbo v7.3.0:

The fetch for the prefetch pages performs as expected
However, upon clicking the link the cache is not used.
Next time the same link is used within in the same page visit the cache is used.

However in Turbo v8.0.0-beta.2 I believe the issue of the prefrech populating the cache to be used upon click has been solved by some other PR all that remains is fixing an issue that this PR has seemed to introduce where the prefetch is not invoked due to the guard introduced.
My suggestion might be nieve as I'm not completely clear on the why this condition was added. I was thinking though that:

If the frameTarget is "_top" then it continues to work
If the frameTarget is not present it allows it to perform the prefetch (a change in behaviour)
If the frameTarget is present
a. If it matches the closest turbo frame it allows it to perform the prefetch (a change in behaviour)
b. Otherwise the prefetch is prevented

The code change in src/core/session.js required would be as such:
    const frame = frameTarget == "_top" ?
      null :
-      document.getElementById(frameTarget) || findClosestRecursively(element, "turbo-frame:not([disabled])");
+      document.getElementById(frameTarget);
+
+    if (frame && frame !== findClosestRecursively(element, "turbo-frame:not([disabled])")) {
+      return false;
+    }

I'd appreciate if you could let me know if this is by design or agree if it's a bug and if so I'd he happy to submit a PR. Alternatively, if there is a different way of solving my problem I'd like to understand this better.

We've got the same issue. We have Frame that contains links which should be preloaded. This does not work anymore since #1033 but has worked without problems before.


macOS builder deadlocking

This issue is to track logs and ideas about why this happens (in opam-repo-ci), thanks @dra27 for the idea! The initial theory was related to #6 this fix has helped I think, but the opam depext -u still causes the builder to be cancelled. It is unclear if it is (a) deadlocking or (b) grinding to a halt essentially taking longer than 60mins to complete the action. To get the ball rolling:
https://opam.ci.ocaml.org/github/ocaml/opam-repository/commit/0f69a6dd3b9b24769c46871066c2f729bbb944b7/variant/opam-2.0,distributions,macos-homebrew,ocaml-variants.4.13.2+trunk
Interestingly all of the timeouts are happening the exact same way at the moment, for example:
https://opam.ci.ocaml.org/github/ocaml/opam-repository/commit/cffa4d801b3e5c76236b6490b5de7db09dc309bd/variant/opam-2.0,distributions,macos-homebrew,pp_loc.1.0.0
During the brew update we get through a whole lot of the packages before:
...
yq
yt-dlp
zeek
zellij
zim
==> Deleted Formulae
ocamlsdl
vavrdiasm
2021-09-30 16:32.14: Cancelling: Timeout (60.0 minutes)
Job cancelled
2021-09-30 16:32.20: Timeout (60.0 minutes)

At this point there are two things in play. obuilder-fs is sitting between the builder and the ZFS file-system that is being written to. I have to assume one of these is interacting badly with this...

Side note
Before #6 we were truly deadlocking (reproducibly elsewhere) whenever a job was cancelled and another immediately started so I do think that bug has been fixed and this is something different.

I just reset mac-sur-3 (wiped the ZFS pool) and reconnected the builder with HOMEBREW_VERBOSE=1 to see if that can illuminate the problematic commands a bit more.

An update! I logged into mac-sur-3 after it hit the same problem, zfs cloned the previous snapshot and ran brew update on its own and it also just got stuck, but it seems a brew cleanup && brew update does the trick! I think... so maybe some stale lock files are getting generate in the previous snapshot and then they're not being removed causing the deadlock. This might make sense if the processes are killed unexpectedly although I assume if they are then the snapshot is also destroyed...

Looks like brew cleanup (which I added into each build step for mac-sur-3) didn't do the trick 😞 ... But, more investigating led to reproducibly showing that the problem is for<EMAIL_ADDRESS>here is the output of doing brew update --debug  --verbose from cloned snapshot: https://gist.github.com/patricoferris/2f8943d174843f051019ddc344c0d097


Add CSRF protection

Requires CORS preflight requests by ensuring that the requests are not 'simple' - e.g. GET request or form-POST requests - or that a specific header has been added to the request.
See similar logic: https://www.apollographql.com/docs/apollo-server/security/cors/#preventing-cross-site-request-forgery-csrf
The chosen default header was based on the current proposal by the GraphQL working group.  See:

https://github.com/graphql/graphql-over-http/pull/303

Pull Request Test Coverage Report for Build<PHONE_NUMBER>9
Details

9 of 33 (27.27%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-1.6%) to 92.933%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/GraphQL.AspNetCore3/GraphQLHttpMiddlewareOptions.cs
0
2
0.0%

src/GraphQL.AspNetCore3/Errors/CsrfProtectionError.cs
0
3
0.0%

src/GraphQL.AspNetCore3/GraphQLHttpMiddleware.cs
9
28
32.14%

Totals

Change from base Build<PHONE_NUMBER>4:
-1.6%

Covered Lines:
1847

Relevant Lines:
1928

💛  - Coveralls


Choice LSP client

when I run navbuddy on typescript file. I seen this error.

when I check my lsp info I found three lsp server running on the typescript file
'tailwindcss','emmet_ls','tsserver'
however, I doesn't help my problem.
the error message is below
E5108: Error executing lua: ....local/share/nvim/lazy/nvim-navic/lua/nvim-navic/lib.lua:257:                                                                                attempt to call field 'request' (a nil value) stack traceback:         ....local/share/nvim/lazy/nvim-navic/lua/nvim-navic/lib.lua:257: in function 'request _symbol'         ...share/nvim/lazy/nvim-navbuddy/lua/nvim-navbuddy/init.lua:164: in function 'make_re quest'         ...share/nvim/lazy/nvim-navbuddy/lua/nvim-navbuddy/init.lua:155: in function 'on_subm it'         ...ee/.local/share/nvim/lazy/nui.nvim/lua/nui/menu/init.lua:281: in function <...ee/. local/share/nvim/lazy/nui.nvim/lua/nui/menu/init.lua:275>

Are you using auto_attach? If so, can you set it to false and try attaching it manually and see.
Also make sure that nvim-navic is also up to date.


PyTorchStepByStep is under advertised.

Danial, I wanted to let you know that I am really finding your Tutorial Series very helpful but you could be selling it a bit better.

I am finding the tutorial a fantastic help in terms of learning numpy.  Yes, the CS231 numpy tutorial give a good starting point but there is very little of practical use compared to what is in PyTorchStepByStep.

Your tutorial provides a good learning point for matplotlib. I was forced to dig through the functions which generated the figures. I got everything working inside and outside of a python notebook.

I just wanted to let you know how much I appreciate this tutorial.
Tom

Hi Tom,
I am happy you're finding my book so helpful :-)
If I understood correctly, you're saying I should highlight more features of my book in its landing page?
I haven't put much thought into the advertisement part yet since there is still a sizeable amount of the content to be written, but any feedback is highly appreciated :-)
Best,
Daniel

Daniel,
Sorry it took so long for me to reply. I think that the best way to
characterize your book is to say that the examples can be used:

For a detailed view of pytorch and pytorch related topics such as
autograd and neural networks, etc.
A refresher for numpy and matplotlib, which are used to aid in the
examples implementing pytorch. (It is not a tutorial for numpy and
matplotlib, but if you follow how the examples are implemented, you can
learn a great deal)

You, personally, know a great deal about numpy and matplotlib but that does
not mean that a lot of your readers do. Truthfully, I have not found
tutorials on those topics that use the functions in as complicated a
fashion as you do. And that is a good thing. Tutorials only go so far.
I only made it into the first chapter before I had to take care of some
other issues. I am currently working on 9 tutorial series and yours is
first on the list.
I am sure that I will have some questions as things proceed.
Regards
Tom
On Tue, Nov 17, 2020 at 9:45 AM Daniel Voigt Godoy<EMAIL_ADDRESS>wrote:

Hi Tom,
I am happy you're finding my book so helpful :-)
If I understood correctly, you're saying I should highlight more features
of my book in its landing page?
I haven't put much thought into the advertisement part yet since there is
still a sizeable amount of the content to be written, but any feedback is
highly appreciated :-)
Best,
Daniel
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dvgodoy/PyTorchStepByStep/issues/8#issuecomment-729091681,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADHGGHEUINEZTNRJL4FYGZDSQKZB5ANCNFSM4TXNROPQ
.


Adapt names to reviewed Kueue documentation

The Kueue documentation has been updated recently.
This PR uses the same ResourceFlavor names than in documentation.
It also gives different names to jobs generated for both teams, so the output of the commands in the tutorial are more descriptive.

FYI @alculquicondor
FYI @alizaidis

(we can review, but do not merge yet)

Oops, nvm. I thought this was about the new API fields. This can merge.

CL created @bourgeoisor


add username and passkey stack parameters

Add FAH client username and passkey stack parameters. Defaults to anonymous user with empty passkey.

I've just tested this branch. No problems with the username or passkey configuration, and the WUs were credited appropriately.


Issue with playing .ts files (via google drive index)

Expected behaviour
Play .ts files without any issues
Actual behaviour
.ts files gives a blank screen
Steps to reproduce
Create a drive index from https://github.com/ParveenBhadooOfficial/Google-Drive-Index
Try to play a .ts file
Get a blank screen
Environment

Browser: Brace, firefox
Version: 1.23.73 , 87.0
Operating System: Ubuntu 20.04, Windows 20H1

Console errors (if any)
Link to where the bug is happening
https://bug.rejected-peice.workers.dev/0:/
I have included sample videos here from https://filesamples.com/categories/video
You may try downloading the video file and play it in you system. It works perfectly fine.

Hey there,
It's an unsupported HTML5 format. You want to be using mp4 for best compatibility:
https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Video_codecs


More tests for kernel finder and refreshing kernels

Codecov Report

Merging #12079 (ab74482) into main (d105a48) will increase coverage by 0%.
The diff coverage is 36%.

@@          Coverage Diff           @@
##            main   #12079   +/-   ##
======================================
  Coverage     63%      63%
======================================
  Files        502      502
  Lines      35967    35952   -15
  Branches    5820     5818    -2
======================================
+ Hits       22703    22715   +12
+ Misses     11115    11093   -22
+ Partials    2149     2144    -5

Impacted Files
Coverage Δ

...rnels/raw/finder/localKernelSpecFinderBase.node.ts
79% <0%> (-2%)
:arrow_down:

.../raw/finder/localKnownPathKernelSpecFinder.node.ts
75% <0%> (ø)

...lPythonAndRelatedNonPythonKernelSpecFinder.node.ts
72% <35%> (+9%)
:arrow_up:

...els/jupyter/finder/remoteKernelFinderController.ts
61% <50%> (-1%)
:arrow_down:

src/kernels/jupyter/finder/remoteKernelFinder.ts
86% <100%> (-1%)
:arrow_down:

...otebooks/controllers/controllerPreferredService.ts
69% <0%> (-6%)
:arrow_down:

src/platform/common/process/baseDaemon.node.ts
47% <0%> (-4%)
:arrow_down:

src/platform/api/pythonApi.ts
70% <0%> (-1%)
:arrow_down:

src/kernels/helpers.ts
66% <0%> (-1%)
:arrow_down:

src/kernels/helpers.node.ts
70% <0%> (ø)

... and 8 more


iOS13: App is showing black window while dismissing SlideLeafViewController

Hello,
I am using this library for showing images in full screen. It was working great on iOS 12. As soon as I updated the app to iOS 13, I am getting a blank window screen while dismissing the SlideLeafViewController.
Is anyone facing the same issue?

Hello,
I am using this library for showing images in full screen. It was working great on iOS 12. As soon as I updated the app to iOS 13, I am getting a blank window screen while dismissing the SlideLeafViewController.
Is anyone facing the same issue?

Resolved this by changing following,
.modalPresentationStyle = .fullScreen //Swift 5.0

Hello,
I am using this library for showing images in full screen. It was working great on iOS 12. As soon as I updated the app to iOS 13, I am getting a blank window screen while dismissing the SlideLeafViewController.
Is anyone facing the same issue?

Resolved this by changing following,
.modalPresentationStyle = .fullScreen //Swift 5.0

add line that to where


[BUG] Weird Issues

VSCode Version: 1.38.1
OS Version: Windows 10 Pro 64bit

Steps to Reproduce:

Writing code or text in any file (JSON config files, classes files, etc.)
Get this annoying error
{  "resource": "/c:/Users/Angel/Documents/Programming/Dart/projects/Test Web/test_routes/test_routes/lib/route_generator.dart",  "owner": "languageErrors441",  "severity": 8,  "message": "Parse error on line 1:\n\n^\nExpecting 'STRING', 'NUMBER', 'NULL', 'TRUE', 'FALSE', '{', '[', got '1'",  "startLineNumber": 1,  "startColumn": 1,  "endLineNumber": 1,  "endColumn": 1 }
Reload VSCode
Error goes away

It happens in every Workspace, every language I'm working with (Dart, C#, Python, AS3, Javascript). Also happens with extensions disabled. This looks like the issue I've been reporting lately that Intelli-Sense just stop auto-completing object members or built-in functions/properties/keywords after a while of working on VSCode. This other issue also gets solved by reloading the workspace.

Does this issue occur when all extensions are disabled?: Yes/No
Yes

It does not look to me that this is caused by VS Code. I suspect an extension is causing this. Please try following:

Disable all installed extensions. Reload window and check if this error occurs
Go to built in extensions view in VS Code and disable extension by extension and reload window. Please check if this error occurs and let us know which extension is causing this.


RFC: Proposal for RFCs for Brick

What is the formal plan and process for continuing development on Brick?
Components

RFCs: proposals for how to extend Brick. This is where the majority of discussion should take place
Pull Requests: implemented extensions to Brick. These can be of several different types:

Implementation of an approved RFC: discussion should focus on the implementation, should involve extensive testing
Bug Fixes: typos, misspellings, inconsistencies: expected minimal discussion

Versioning:

I recommend that Brick stick to Semver:
Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

Debugging help/questions: how people learn how to use Brick and we help with any issues they have

Realization

RFCs:

an RFC will be an issue on GitHub with the "RFC" label. The first post will be the operating RFC document, and discussion will take place in the comments below
New RFCs will be announced by a Project Maintainer on the Brick mailing lists, but discussion should be relegated to GitHub
RFCs will get the ACCEPTED or REJECTED GitHub label after discussion has concluded; adding this label and concluding the discussion is the responsibility of a Project Maintainer
if the RFC involves a change to the Brick ontology, a project maintainer will make a judgement about which release of Brick the implementation will target (see Versioning)

Pull Requests:

Upon the acceptance of an RFC, one or more developers will be assigned to implement the RFC
If the RFC is an extension of Brick, then the Pull Request should include:

editing the Brick generation src to produce the new Brick file
a pointer to which release of Brick the PR is targeting (see Versioning)
changes to the example building files to make them compliant with the new version of Brick (if applicable)
relevant documentation on how these extensions work and how they are meant to be used
TODO: where does this documentation go?

If the RFC is a proposal to change the website, alter documentation, or something other than an edit of the Brick ontology, then a
Pull Request should still be filed on the Brick repository with a pointer to the changes (e.g. if they are on another repo) so that
discussion can be centralized

Versioning:

If we're not careful, versioning can become an Achilles heel for getting started with Brick, because we've made the choice to place the Brick version in the Brick namespace URI.

e.g. https://brickschema.org/schema/1.0.1/Brick#

Brick PATCH version numbers should not appear in the namespace URI:

e.g. https://brickschema.org/schema/1.0/Brick#
PATCHes should not affect how Brick is used, so there is no need to differentiate between them in the URI
TODO: do we even want to use PATCH version numbers?

Brick MINOR version numbers are incremented as the result of a milestone:

a milestone is a set of TODO items decided upon by an RFC
when all of the TODO items for a milestone are complete, the MINOR version is considered finished
this is the most common way of incrementing Brick version numbers

a Brick MAJOR version number (e.g. "Brick 2.0") will involve a fundamental, backwards-incompatible change in how Brick is used.
I don't anticipate we'll see this anytime soon.
put another way, pull requests and RFCs do not automatically result in a MINOR version number increase. Instead, we will decide
upon some set of features that constitute a new MINOR version, which will be implemented by a set of pull requests, and then we will do
a release of that MINOR version once all of those are done.

Thank you Gabe for putting together a comprehensive proposal for RFC.
I’m onboard with all of the changes proposed.
For the two TODOs:

The documentation can go on the Brick website, in a separate page called
Change Log (or a similar name)
I think Patch numbers are still useful to have. The developers working on
these detailed bugs know which version they are working on. However, I
support your suggestion that it doesn’t have to affect the Brick schema
URL. The patch number can be included as a property of the “Brick” class in
the TTL file. We can also add additional details such as last update date
in the properties of Brick class.

Comment:
There may be several different RFCs happening in parallel (e.g. electrical
and water domains). Since they map the versioning sequentially, the
specific version numbers that these RFCs correspond to may be hard to
decide beforehand.
Regards,
Bharath
On Fri, Jul 7, 2017 at 6:01 PM, Gabe Fierro<EMAIL_ADDRESS>wrote:

What is the formal plan and process for continuing development on Brick?
Components

RFCs: proposals for how to extend Brick. This is where the majority
of discussion should take place
Pull Requests: implemented extensions to Brick. These can be of
several different types:

Implementation of an approved RFC: discussion should focus on the
implementation, should involve extensive testing
Bug Fixes: typos, misspellings, inconsistencies: expected minimal
discussion

Versioning:

I recommend that Brick stick to Semver http://semver.org/:
Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a
backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.
Additional labels for pre-release and build metadata are
available as extensions to the MAJOR.MINOR.PATCH format.

Debugging help/questions: how people learn how to use Brick and
we help with any issues they have

Realization

RFCs:

an RFC will be an issue on GitHub with the "RFC" label. The first
post will be the operating RFC document, and discussion will take place in
the comments below
New RFCs will be announced by a Project Maintainer on the Brick
mailing lists, but discussion should be relegated to GitHub
RFCs will get the ACCEPTED or REJECTED GitHub label after
discussion has concluded; adding this label and concluding the discussion
is the responsibility of a Project Maintainer
if the RFC involves a change to the Brick ontology, a project
maintainer will make a judgement about which release of Brick the
implementation will target (see Versioning)

Pull Requests:

Upon the acceptance of an RFC, one or more developers will be
assigned to implement the RFC
If the RFC is an extension of Brick, then the Pull Request should
include:

editing the Brick generation src to produce the new Brick file
a pointer to which release of Brick the PR is targeting (see
Versioning)
changes to the example building files to make them compliant
with the new version of Brick (if applicable)
relevant documentation on how these extensions work and how
they are meant to be used
TODO: where does this documentation go?

If the RFC is a proposal to change the website, alter
documentation, or something other than an edit of the Brick ontology, then a
Pull Request should still be filed on the Brick repository with a
pointer to the changes (e.g. if they are on another repo) so that
discussion can be centralized

Versioning:

If we're not careful, versioning can become an Achilles heel for
getting started with Brick, because we've made the choice to place the
Brick version in the Brick namespace URI.

e.g. https://brickschema.org/schema/1.0.1/Brick#

Brick PATCH version numbers should not appear in the namespace
URI:

e.g. https://brickschema.org/schema/1.0/Brick#
PATCHes should not affect how Brick is used, so there is no
need to differentiate between them in the URI
TODO: do we even want to use PATCH version numbers?

Brick MINOR version numbers are incremented as the result of a
milestone:

a milestone is a set of TODO items decided upon by an RFC
when all of the TODO items for a milestone are complete, the
MINOR version is considered finished
this is the most common way of incrementing Brick version
numbers

a Brick MAJOR version number (e.g. "Brick 2.0") will involve a
fundamental, backwards-incompatible change in how Brick is used.
I don't anticipate we'll see this anytime soon.
put another way, pull requests and RFCs do not automatically
result in a MINOR version number increase. Instead, we will decide
upon some set of features that constitute a new MINOR version,
which will be implemented by a set of pull requests, and then we will do
a release of that MINOR version once all of those are done.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/BuildSysUniformMetadata/Brick/issues/25, or mute the
thread
https://github.com/notifications/unsubscribe-auth/ADFqQhGj_xURFQuc-kK491OZ-ic_XN7eks5sLtUCgaJpZM4ORk-5
.

I agree on the currently proposed opinions.
One comment that haven't discussed:
I see that an RFC is directed by a manager to a version but it is unclear when we should decide a version is ready to be released. I still think a quarterly (or half a year) board meeting will help to decide release versions. It'd better separating out version release and version development like schema.org (http://schema.org/docs/about.html#cgsg). (version development = community group, version release = steering group in schema.org terms.)
In case our group is too small for the separation, a (MAJOR/MINOR) version release can be another RFC that requires discussions/agreements.

I've updated the RFC to include comments about the PATCH numbers (assigned when the PR is merged) and documentation (ChangeLog page on the Brick site)
In terms of how we decide what comprises a minor version, I think we can play it by ear. Someone can have an RFC with a list of proposed changes, and then this gets saved into a GitHub milestone after its accepted. We then use the milestone to track progress. As an example, I can put together an RFC for Brick 1.1

Might as well change this to accepted :)


FeedIterator ReadNextAsync() throws NullReferenceException

Describe the bug
FeedIterator ReadNextAsync() throws a NullReferenceException.
The output CosmosDiagnostics object suggests that the problem is a timeout. If that is the problem, ReadNextAsync() should throw an exception that is more indicative of the problem.
Expected behavior
If that is the problem, ReadNextAsync() should throw an exception that is more indicative of the problem.
Actual behavior
A NullReferenceException is thrown.
Environment summary
SDK Version: 3.19.0
OS Version: Windows
Stack Trace and Cosmos Diagnostics
---> System.Exception: Could not complete method 'GetByIds'
---> System.NullReferenceException: Object reference not set to an instance of an object.
at Microsoft.Azure.Documents.GoneAndRetryWithRequestRetryPolicy1.TryHandleResponseSynchronously(DocumentServiceRequest request, TResponse response, Exception exception, ShouldRetryResult& shouldRetryResult)    at Microsoft.Azure.Documents.RequestRetryUtility.ProcessRequestAsync[TRequest,IRetriableResponse](Func1 executeAsync, Func1 prepareRequest, IRequestRetryPolicy2 policy, CancellationToken cancellationToken, Func1 inBackoffAlternateCallbackMethod, Nullable1 minBackoffForInBackoffCallback)
at Microsoft.Azure.Documents.StoreClient.ProcessMessageAsync(DocumentServiceRequest request, CancellationToken cancellationToken, IRetryPolicy retryPolicy, Func2 prepareRequestAsyncDelegate)    at Microsoft.Azure.Cosmos.Handlers.TransportHandler.ProcessMessageAsync(RequestMessage request, CancellationToken cancellationToken)    at Microsoft.Azure.Cosmos.Handlers.TransportHandler.SendAsync(RequestMessage request, CancellationToken cancellationToken)    at Microsoft.Azure.Cosmos.Handlers.RouterHandler.SendAsync(RequestMessage request, CancellationToken cancellationToken)    at Microsoft.Azure.Cosmos.RequestHandler.SendAsync(RequestMessage request, CancellationToken cancellationToken)    at Microsoft.Azure.Cosmos.Handlers.AbstractRetryHandler.ExecuteHttpRequestAsync(Func1 callbackMethod, Func3 callShouldRetry, Func3 callShouldRetryException, CancellationToken cancellationToken)
at Microsoft.Azure.Cosmos.Handlers.AbstractRetryHandler.SendAsync(RequestMessage request, CancellationToken cancellationToken)
at Microsoft.Azure.Cosmos.RequestHandler.SendAsync(RequestMessage request, CancellationToken cancellationToken)
at Microsoft.Azure.Cosmos.RequestHandler.SendAsync(RequestMessage request, CancellationToken cancellationToken)
at Microsoft.Azure.Cosmos.Handlers.RequestInvokerHandler.SendAsync(RequestMessage request, CancellationToken cancellationToken)
at Microsoft.Azure.Cosmos.Handlers.RequestInvokerHandler.SendAsync(String resourceUriString, ResourceType resourceType, OperationType operationType, RequestOptions requestOptions, ContainerInternal cosmosContainerCore, FeedRange feedRange, Stream streamPayload, Action1 requestEnricher, ITrace trace, CancellationToken cancellationToken)    at Microsoft.Azure.Cosmos.CosmosQueryClientCore.ExecuteItemQueryAsync(String resourceUri, ResourceType resourceType, OperationType operationType, Guid clientQueryCorrelationId, FeedRange feedRange, QueryRequestOptions requestOptions, SqlQuerySpec sqlQuerySpec, String continuationToken, Boolean isContinuationExpected, Int32 pageSize, ITrace trace, CancellationToken cancellationToken)    at Microsoft.Azure.Cosmos.Pagination.NetworkAttachedDocumentContainer.MonadicQueryAsync(SqlQuerySpec sqlQuerySpec, FeedRangeState1 feedRangeState, QueryPaginationOptions queryPaginationOptions, ITrace trace, CancellationToken cancellationToken)
at Microsoft.Azure.Cosmos.Pagination.PartitionRangePageAsyncEnumerator2.MoveNextAsync(ITrace trace)    at Microsoft.Azure.Cosmos.Pagination.BufferedPartitionRangePageAsyncEnumerator2.PrefetchAsync(ITrace trace, CancellationToken cancellationToken)
at Microsoft.Azure.Cosmos.Pagination.BufferedPartitionRangePageAsyncEnumerator2.GetNextPageAsync(ITrace trace, CancellationToken cancellationToken)    at Microsoft.Azure.Cosmos.Pagination.PartitionRangePageAsyncEnumerator2.MoveNextAsync(ITrace trace)
at Microsoft.Azure.Cosmos.Pagination.CrossPartitionRangePageAsyncEnumerator2.MoveNextAsync(ITrace trace)    at Microsoft.Azure.Cosmos.Query.Core.Pipeline.CrossPartition.Parallel.ParallelCrossPartitionQueryPipelineStage.MoveNextAsync(ITrace trace)    at Microsoft.Azure.Cosmos.Query.Core.Pipeline.LazyQueryPipelineStage.MoveNextAsync(ITrace trace)    at Microsoft.Azure.Cosmos.Query.Core.Pipeline.NameCacheStaleRetryQueryPipelineStage.MoveNextAsync(ITrace trace)    at Microsoft.Azure.Cosmos.Query.Core.Pipeline.CatchAllQueryPipelineStage.MoveNextAsync(ITrace trace)    at Microsoft.Azure.Cosmos.Query.QueryIterator.ReadNextAsync(ITrace trace, CancellationToken cancellationToken)    at Microsoft.Azure.Cosmos.FeedIteratorCore1.ReadNextAsync(ITrace trace, CancellationToken cancellationToken)
at Microsoft.Azure.Cosmos.ClientContextCore.RunWithDiagnosticsHelperAsync[TResult](ITrace trace, Func`2 task)
CosmosDiagnostics: {"name":"Typed FeedIterator ReadNextAsync","id":"eb937901-bd4a-4260-98e8-b661971adc47","caller info":{"member":"OperationHelperWithRootTraceAsync","file":"ClientContextCore.cs","line":219},"start time":"05:37:50:255","duration in milliseconds":32134.0886,"data":{"Client Configuration":{"Client Created Time Utc":"2021-09-01T17:37:32.3339345Z","NumberOfClientsCreated":1,"User Agent":"cosmos-netstandard-sdk/3.19.0|3.19.1|02|X64|Microsoft Windows 10.0.14393|.NET Core 3.1.18|N|","ConnectionConfig":{"gw":"(cps:1000, urto:3600, p:False, httpf: False)","rntbd":"(cto: 5, icto: -1, mrpc: 30, mcpe: 65535, erd: False, pr: ReuseUnicastPort)","other":"(ed:False, be:False)"},"ConsistencyConfig":"(consistency: NotSet, prgns:[])"}},"children":[{"name":"Create Query Pipeline","id":"02fe59c2-4ab4-4ece-84b2-d512503bad01","caller info":{"member":"TryCreateCoreContextAsync","file":"CosmosQueryExecutionContextFactory.cs","line":85},"start time":"05:37:50:278","duration in milliseconds":899.3363,"children":[{"name":"Get Container Properties","id":"1d909d6b-f46b-4e1d-9392-4472c84befc1","caller info":{"member":"GetCachedContainerPropertiesAsync","file":"ClientContextCore.cs","line":366},"start time":"05:37:50:282","duration in milliseconds":312.756,"children":[{"name":"Get Collection Cache","id":"f266eb85-5fdd-4f17-b524-bf9df6e41857","caller info":{"member":"GetCollectionCacheAsync","file":"DocumentClient.cs","line":546},"start time":"05:37:50:284","duration in milliseconds":1.5077,"children":[{"name":"Waiting for Initialization of client to complete","id":"edc37e11-0097-40d5-8d07-e6168c04ccbf","caller info":{"member":"EnsureValidClientAsync","file":"DocumentClient.cs","line":1416},"start time":"05:37:50:285","duration in milliseconds":0.1018}]},{"name":"Read Collection","id":"1d112406-161e-4651-90dd-02b93308801d","caller info":{"member":"ReadCollectionAsync","file":"ClientCollectionCache.cs","line":68},"start time":"05:37:50:336","duration in milliseconds":242.168,"data":{"Client Side Request Stats":{"Id":"AggregatedClientSideRequestStatistics","ContactedReplicas":[],"RegionsContacted":[],"FailedReplicas":[],"AddressResolutionStatistics":[],"StoreResponseStatistics":[],"HttpResponseStats":[{"StartTimeUTC":"2021-09-01T17:37:50.5031928Z","EndTimeUTC":"2021-09-01T17:37:50.5031980Z","RequestUri":"https://-cosmosdb-qa-centralus.documents.azure.com/dbs/_QA/colls","ResourceType":"Collection","HttpMethod":"GET","ActivityId":"01c921ec-c36d-4caa-92f6-22453e366691","StatusCode":"OK"}]}}}]},{"name":"Service Interop Query Plan","id":"d9bef0fa-3566-4ddd-b1d0-ed3a9e0d16d9","caller info":{"member":"GetQueryPlanWithServiceInteropAsync","file":"QueryPlanRetriever.cs","line":58},"start time":"05:37:50:617","duration in milliseconds":267.3489},{"name":"Get Partition Key Ranges","id":"20d5fecf-0cbb-4c35-8ef3-c002e048ab16","caller info":{"member":"GetTargetPartitionKeyRangesAsync","file":"CosmosQueryClientCore.cs","line":242},"start time":"05:37:50:891","duration in milliseconds":232.737,"children":[{"name":"Try Get Overlapping Ranges","id":"7d4daaec-3910-4885-bdd6-56d746f0454b","caller info":{"member":"TryGetOverlappingRangesAsync","file":"PartitionKeyRangeCache.cs","line":53},"start time":"05:37:50:905","duration in milliseconds":216.9974,"children":[{"name":"Read PartitionKeyRange Change Feed","id":"2960d40c-e85a-4592-b360-3802cdae3974","caller info":{"member":"ExecutePartitionKeyRangeReadChangeFeedAsync","file":"PartitionKeyRangeCache.cs","line":239},"start time":"05:37:51:014","duration in milliseconds":64.5246,"data":{"Client Side Request Stats":{"Id":"AggregatedClientSideRequestStatistics","ContactedReplicas":[],"RegionsContacted":[],"FailedReplicas":[],"AddressResolutionStatistics":[],"StoreResponseStatistics":[],"HttpResponseStats":[{"StartTimeUTC":"2021-09-01T17:37:51.0691033Z","EndTimeUTC":"2021-09-01T17:37:51.0691039Z","RequestUri":"https://-cosmosdb-qa-centralus.documents.azure.com/dbs/D7hAAA==/colls/D7hAALoL+RM=/pkranges","ResourceType":"PartitionKeyRange","HttpMethod":"GET","ActivityId":"892ef13d-69a7-4050-a127-010d0013d541","StatusCode":"OK"}]}}},{"name":"Read PartitionKeyRange Change Feed","id":"66613cba-67fe-43f0-91f1-f56a1ae5df0a","caller info":{"member":"ExecutePartitionKeyRangeReadChangeFeedAsync","file":"PartitionKeyRangeCache.cs","line":239},"start time":"05:37:51:096","duration in milliseconds":5.7648,"data":{"Client Side Request Stats":{"Id":"AggregatedClientSideRequestStatistics","ContactedReplicas":[],"RegionsContacted":[],"FailedReplicas":[],"AddressResolutionStatistics":[],"StoreResponseStatistics":[],"HttpResponseStats":[{"StartTimeUTC":"2021-09-01T17:37:51.1016316Z","EndTimeUTC":"2021-09-01T17:37:51.1016321Z","RequestUri":"https://-cosmosdb-qa-centralus.documents.azure.com/dbs/D7hAAA==/colls/D7hAALoL+RM=/pkranges","ResourceType":"PartitionKeyRange","HttpMethod":"GET","ActivityId":"e39d1795-e216-46af-92c1-c03b9c25b78c","StatusCode":"NotModified","ReasonPhrase":"Not Modified"}]}}}]}]}]},{"name":"MoveNextAsync","id":"28d9c19c-db43-418d-bc6c-23a63f0906b7","caller info":{"member":"MoveNextAsync","file":"CrossPartitionRangePageAsyncEnumerator.cs","line":113},"start time":"05:37:51:208","duration in milliseconds":31179.8532,"children":[{"name":"Prefetching","id":"23c31a86-45a5-4425-ab21-61eb1ed37e26","caller info":{"member":"PrefetchInParallelAsync","file":"ParallelPrefetch.cs","line":31},"start time":"05:37:51:228","duration in milliseconds":0.1151},{"name":"[05C1D325499320,05C1DBB76DDBB0) move next","id":"8d5b903e-f8b4-487d-a765-299f87d75528","caller info":{"member":"MoveNextAsync","file":"PartitionRangePageAsyncEnumerator.cs","line":49},"start time":"05:37:51:235","duration in milliseconds":31152.9635,"children":[{"name":"Prefetch","id":"65860883-c585-45e4-a977-c9a4bdbbf71c","caller info":{"member":"PrefetchAsync","file":"BufferedPartitionRangePageAsyncEnumerator.cs","line":50},"start time":"05:37:51:240","duration in milliseconds":31147.8341,"children":[{"name":"[05C1D325499320,05C1DBB76DDBB0) move next","id":"28f3da1d-28a8-427f-988c-7dd31150395f","caller info":{"member":"MoveNextAsync","file":"PartitionRangePageAsyncEnumerator.cs","line":49},"start time":"05:37:51:240","duration in milliseconds":31147.6806,"children":[{"name":"Microsoft.Azure.Cosmos.Handlers.RequestInvokerHandler","id":"ec61c478-16cd-4bca-8a4c-09daad13ebd3","start time":"05:37:51:261","duration in milliseconds":31127.1017,"children":[{"name":"Microsoft.Azure.Cosmos.Handlers.DiagnosticsHandler","id":"59c792ed-d8e8-44a1-a30f-93499cd41b7c","start time":"05:37:51:281","duration in milliseconds":31107.3539,"children":[{"name":"Microsoft.Azure.Cosmos.Handlers.RetryHandler","id":"d79abea9-0bbd-4a46-b7f9-9b34bf2b2d49","start time":"05:37:51:374","duration in milliseconds":31014.1586,"children":[{"name":"Microsoft.Azure.Cosmos.Handlers.RouterHandler","id":"860a957a-76b4-4603-b7f1-99301da41618","start time":"05:37:51:506","duration in milliseconds":30881.3802,"children":[{"name":"Microsoft.Azure.Cosmos.Handlers.TransportHandler","id":"0d34dcde-f547-49fa-a82d-abcdd557f99c","start time":"05:37:51:506","duration in milliseconds":30881.3416,"children":[{"name":"Microsoft.Azure.Documents.ServerStoreModel Transport Request","id":"84cac459-5020-42ef-b9a6-183e19c078b2","caller info":{"member":"ProcessMessageAsync","file":"TransportHandler.cs","line":109},"start time":"05:37:51:516","duration in milliseconds":30871.5345,"data":{"Client Side Request Stats":{"Id":"AggregatedClientSideRequestStatistics","ContactedReplicas":[],"RegionsContacted":["https://-cosmosdb-qa-centralus.documents.azure.com/"],"FailedReplicas":["rntbd://cdb-ms-prod-centralus1-fd18.documents.azure.com:14375/apps/88bc3414-7aba-40b2-a5d5-fc6320b6b18a/services/9a34bddb-212a-430b-9e48-dbeb7bd2b566/partitions/9ecaec82-2893-44ba-9a0a-6279557ca707/replicas/132719682054430208s/","rntbd://cdb-ms-prod-centralus1-fd18.documents.azure.com:14332/apps/88bc3414-7aba-40b2-a5d5-fc6320b6b18a/services/9a34bddb-212a-430b-9e48-dbeb7bd2b566/partitions/9ecaec82-2893-44ba-9a0a-6279557ca707/replicas/132746108201566536s/","rntbd://cdb-ms-prod-centralus1-fd18.documents.azure.com:14058/apps/88bc3414-7aba-40b2-a5d5-fc6320b6b18a/services/9a34bddb-212a-430b-9e48-dbeb7bd2b566/partitions/9ecaec82-2893-44ba-9a0a-6279557ca707/replicas/132744354437093518s/","rntbd://cdb-ms-prod-centralus1-fd18.documents.azure.com:14026/apps/88bc3414-7aba-40b2-a5d5-fc6320b6b18a/services/9a34bddb-212a-430b-9e48-dbeb7bd2b566/partitions/9ecaec82-2893-44ba-9a0a-6279557ca707/replicas/132744783805920816p/"],"AddressResolutionStatistics":[{"StartTimeUTC":"2021-09-01T17:37:51.7977234Z","EndTimeUTC":"2021-09-01T17:37:51.7990011Z","TargetEndpoint":"https://-cosmosdb-qa-centralus.documents.azure.com//addresses/?$resolveFor=dbs%2fD7hAAA%3d%3d%2fcolls%2fD7hAALoL%2bRM%3d%2fdocs&$filter=protocol eq rntbd&$partitionKeyRangeIds=2"}],"StoreResponseStatistics":[{"ResponseTimeUTC":"2021-09-01T17:37:57.9564330Z","ResourceType":"Document","OperationType":"Query","LocationEndpoint":"https://-cosmosdb-qa-centralus.documents.azure.com/","StoreResult":{"ActivityId":"ee5771d2-c836-43de-9f29-942c7c606618","StatusCode":"Gone","SubStatusCode":"Unknown","LSN":-1,"PartitionKeyRangeId":null,"GlobalCommittedLSN":-1,"ItemLSN":-1,"UsingLocalLSN":true,"QuorumAckedLSN":-1,"SessionToken":null,"CurrentWriteQuorum":-1,"CurrentReplicaSetSize":-1,"NumberOfReadRegions":-1,"IsClientCpuOverloaded":false,"IsValid":false,"StorePhysicalAddress":"rntbd://cdb-ms-prod-centralus1-fd18.documents.azure.com:14375/apps/88bc3414-7aba-40b2-a5d5-fc6320b6b18a/services/9a34bddb-212a-430b-9e48-dbeb7bd2b566/partitions/9ecaec82-2893-44ba-9a0a-6279557ca707/replicas/132719682054430208s/","RequestCharge":0,"BELatencyInMs":null,"TransportException":"A client transport error occurred: SSL negotiation timed out. (Time: 2021-09-01T17:37:57.9536594Z, activity ID: ee5771d2-c836-43de-9f29-942c7c606618, error code: SslNegotiationTimeout [0x0008], base error: HRESULT 0x80131500, URI: rntbd://cdb-ms-prod-centralus1-fd18.documents.azure.com:14375/, connection: <IP_ADDRESS>:56489 -> <IP_ADDRESS>:14375, payload sent: False, CPU history: (2021-09-01T17:37:34.9247174Z 32.367), CPU count: 2)"}},{"ResponseTimeUTC":"2021-09-01T17:38:03.4471370Z","ResourceType":"Document","OperationType":"Query","LocationEndpoint":"https://-cosmosdb-qa-centralus.documents.azure.com/","StoreResult":{"ActivityId":"ee5771d2-c836-43de-9f29-942c7c606618","StatusCode":"Gone","SubStatusCode":"Unknown","LSN":-1,"PartitionKeyRangeId":null,"GlobalCommittedLSN":-1,"ItemLSN":-1,"UsingLocalLSN":true,"QuorumAckedLSN":-1,"SessionToken":null,"CurrentWriteQuorum":-1,"CurrentReplicaSetSize":-1,"NumberOfReadRegions":-1,"IsClientCpuOverloaded":false,"IsValid":false,"StorePhysicalAddress":"rntbd://cdb-ms-prod-centralus1-fd18.documents.azure.com:14332/apps/88bc3414-7aba-40b2-a5d5-fc6320b6b18a/services/9a34bddb-212a-430b-9e48-dbeb7bd2b566/partitions/9ecaec82-2893-44ba-9a0a-6279557ca707/replicas/132746108201566536s/","RequestCharge":0,"BELatencyInMs":null,"TransportException":"A client transport error occurred: The connection attempt timed out. (Time: 2021-09-01T17:38:03.4172370Z, activity ID: 1685a9bc-e504-4d1f-853f-a974942ccefc, error code: ConnectTimeout [0x0006], base error: HRESULT 0x80131500, URI: rntbd://cdb-ms-prod-centralus1-fd18.documents.azure.com:14332/, connection:  -> rntbd://cdb-ms-prod-centralus1-fd18.documents.azure.com:14332/, payload sent: False, CPU history: (2021-09-01T17:37:34.9247174Z 32.367), CPU count: 2)"}},{"ResponseTimeUTC":"2021-09-01T17:38:11.6796291Z","ResourceType":"Document","OperationType":"Query","LocationEndpoint":"https://-cosmosdb-qa-centralus.documents.azure.com/","StoreResult":{"ActivityId":"ee5771d2-c836-43de-9f29-942c7c606618","StatusCode":"Gone","SubStatusCode":"Unknown","LSN":-1,"PartitionKeyRangeId":null,"GlobalCommittedLSN":-1,"ItemLSN":-1,"UsingLocalLSN":true,"QuorumAckedLSN":-1,"SessionToken":null,"CurrentWriteQuorum":-1,"CurrentReplicaSetSize":-1,"NumberOfReadRegions":-1,"IsClientCpuOverloaded":false,"IsValid":false,"StorePhysicalAddress":"rntbd://cdb-ms-prod-centralus1-fd18.documents.azure.com:14058/apps/88bc3414-7aba-40b2-a5d5-fc6320b6b18a/services/9a34bddb-212a-430b-9e48-dbeb7bd2b566/partitions/9ecaec82-2893-44ba-9a0a-6279557ca707/replicas/132744354437093518s/","RequestCharge":0,"BELatencyInMs":null,"TransportException":"A client transport error occurred: The connection attempt timed out. (Time: 2021-09-01T17:38:11.4389377Z, activity ID: dcc70f16-0ea2-489d-bc4b-b7788bd05235, error code: ConnectTimeout [0x0006], base error: HRESULT 0x80131500, URI: rntbd://cdb-ms-prod-centralus1-fd18.documents.azure.com:14058/, connection:  -> rntbd://cdb-ms-prod-centralus1-fd18.documents.azure.com:14058/, payload sent: False, CPU history: (2021-09-01T17:37:34.9247174Z 32.367), CPU count: 2)"}},{"ResponseTimeUTC":"2021-09-01T17:38:20.6631255Z","ResourceType":"Document","OperationType":"Query","LocationEndpoint":"https://-cosmosdb-qa-centralus.documents.azure.com/","StoreResult":{"ActivityId":"ee5771d2-c836-43de-9f29-942c7c606618","StatusCode":"Gone","SubStatusCode":"Unknown","LSN":-1,"PartitionKeyRangeId":null,"GlobalCommittedLSN":-1,"ItemLSN":-1,"UsingLocalLSN":true,"QuorumAckedLSN":-1,"SessionToken":null,"CurrentWriteQuorum":-1,"CurrentReplicaSetSize":-1,"NumberOfReadRegions":-1,"IsClientCpuOverloaded":false,"IsValid":false,"StorePhysicalAddress":"rntbd://cdb-ms-prod-centralus1-fd18.documents.azure.com:14026/apps/88bc3414-7aba-40b2-a5d5-fc6320b6b18a/services/9a34bddb-212a-430b-9e48-dbeb7bd2b566/partitions/9ecaec82-2893-44ba-9a0a-6279557ca707/replicas/132744783805920816p/","RequestCharge":0,"BELatencyInMs":null,"TransportException":"A client transport error occurred: Sending the request timed out. (Time: 2021-09-01T17:38:20.6605955Z, activity ID: ee5771d2-c836-43de-9f29-942c7c606618, error code: SendTimeout [0x000E], base error: HRESULT 0x80131500, URI: rntbd://cdb-ms-prod-centralus1-fd18.documents.azure.com:14026/, connection: <IP_ADDRESS>:56533 -> <IP_ADDRESS>:14026, payload sent: False, CPU history: (2021-09-01T17:37:34.9247174Z 32.367), CPU count: 2)"}}],"HttpResponseStats":[{"StartTimeUTC":"2021-09-01T17:37:51.7989266Z","EndTimeUTC":"2021-09-01T17:37:51.7989269Z","RequestUri":"https://-cosmosdb-qa-centralus.documents.azure.com//addresses/?$resolveFor=dbs%2fD7hAAA%3d%3d%2fcolls%2fD7hAALoL%2bRM%3d%2fdocs&$filter=protocol eq rntbd&$partitionKeyRangeIds=2","ResourceType":"Document","HttpMethod":"GET","ActivityId":"ee5771d2-c836-43de-9f29-942c7c606618","StatusCode":"OK"}]}}}]}]}]}]}]}]}]}]}]}]}

Please upgrade to 3.20.1. This bug was fixed in the following PR: https://github.com/Azure/azure-cosmos-dotnet-v3/pull/2562


WH linker error when building BRISC with watcher enabled

I'm trying to get the stress test pipeline error-free again and I'm seeing a regression issue pop up with watcher enabled. To reproduce:
TT_METAL_WATCHER=30 ./build/test/tt_metal/unit_tests_fast_dispatch

Error signature:
In file included from ./kernel.cpp:5,
                 from /home/ubuntu/bteng/tt-metal/tt_metal/hw/firmware/src/brisck.cc:23:
/home/ubuntu/bteng/tt-metal/tt_metal/impl/dispatch/kernels/cq_prefetcher.hpp: In function 'void completion_queue_reserve_back(uint32_t)':
/home/ubuntu/bteng/tt-metal/tt_metal/impl/dispatch/kernels/cq_prefetcher.hpp:153:80: warning: suggest parentheses around '&&' within '||' [-Wparentheses]
  153 |         (completion_rd_toggle != cq_write_interface.completion_fifo_wr_toggle) and (cq_write_interface.completion_fifo_wr_ptr == completion_rd_ptr)
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/ubuntu/bteng/tt-metal/tt_metal/third_party/sfpi/compiler/bin/../lib/gcc/riscv32-unknown-elf/10.2.0/../../../../riscv32-unknown-elf/bin/ld: /home/ubuntu/bteng/tt-metal/built/1/kernels/cq_prefetcher/17186141426769429586/brisc/brisc.elf section `.text' will not fit in region `BRISC_CODE'
/home/ubuntu/bteng/tt-metal/tt_metal/third_party/sfpi/compiler/bin/../lib/gcc/riscv32-unknown-elf/10.2.0/../../../../riscv32-unknown-elf/bin/ld: region `BRISC_CODE' overflowed by 1048 bytes
collect2: error: ld returned 1 exit status
                 Always | FATAL    | brisc build failed
                 Always | FATAL    | Failed to generate binaries for cq_prefetcher TT_THROW @ tt_metal/jit_build/build.cpp:372: tt::exception
info:
{} build failed
brisc
backtrace:
 --- tt::tt_metal::JitBuildState::link(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const
 --- tt::tt_metal::JitBuildState::build(tt::tt_metal::JitBuildSettings const*) const
 --- /home/ubuntu/bteng/tt-metal/build/lib/libtt_metal.so(+0x2976ea) [0x7f93e78fc6ea]
 --- /home/ubuntu/bteng/tt-metal/build/lib/libtt_metal.so(+0x2979f4) [0x7f93e78fc9f4]
 --- /home/ubuntu/bteng/tt-metal/build/lib/libtt_metal.so(+0x29fc2d) [0x7f93e7904c2d]
 --- /lib/x86_64-linux-gnu/libpthread.so.0(+0x114df) [0x7f93e76464df]
 --- /home/ubuntu/bteng/tt-metal/build/lib/libtt_metal.so(+0x28fa3c) [0x7f93e78f4a3c]
 --- /home/ubuntu/bteng/tt-metal/build/lib/libtt_metal.so(+0x2af187) [0x7f93e7914187]
 --- std::thread::_State_impl<std::thread::_Invoker<std::tuple<tf::Executor::_spawn(unsigned long)::{lambda()#1}> > >::_M_run()
 --- /lib/x86_64-linux-gnu/libstdc++.so.6(+0xd6df4) [0x7f93e7529df4]
 --- /lib/x86_64-linux-gnu/libpthread.so.0(+0x8609) [0x7f93e763d609]
 --- /lib/x86_64-linux-gnu/libc.so.6(clone+0x43) [0x7f93e7088353]

@abhullar-tt @aliuTT I was able to get the stress test pipeline to pass over the weekend, so this could be related to your recent commits. If not, please re-assign to the right person.
Thanks.

Hmm this doesn't seem related to stress testing. It seems like if we just enable watcher for any test, this code size problem will be there. Are there any watcher tests on post commit?

yes it's not related; only caught it because I turn on watcher

Ill take a look at this

There are wa

Hmm this doesn't seem related to stress testing. It seems like if we just enable watcher for any test, this code size problem will be there. Are there any watcher tests on post commit?

There are watcher tests on post-commit, but they are disabled for fast dispatch remote device currently. I hit this same issue when enabling them for fast dispatch remote device.


rc2.0: Upload manifest files for release branch

Cherry-pick https://github.com/microsoft/FluidFramework/pull/21143 and https://github.com/microsoft/FluidFramework/pull/20722

is this template: tools/pipelines/templates/1ES/build-npm-package.yml part of only rc2.0 release?


Is RaftKeeper just taken from HouseKeeper?

The source code structure is really close, check https://github.com/ClickHouse/ClickHouse/tree/master/src/Coordination.

The framework and ZooKeeper protocol are almost the same as ClickHouse Keeper, but the Log, Snapshot, StateMachine, batch execution, and support for hundreds of thousands of Client connections are developed by ourselves. Of course, the performance difference is relatively large.

Do you have tested with Jespen?

I remember that ClickHouse Keeper has been done before, because they all use the same nuraft framework, so we didn't do it alone, but we plan to do it recently.

@zhanglistar Thanks for your conern about the RaftKeeper project. The flowing is the additional discription of @marising .
As discribed in project ReadME, RaftKeeper is drived from ClickHouse. Some core modules is originally from ClikHouse, such as dispatcher, connection handler, keeper store, acl map.
At the beginning we plan to contribute to ClickHouse. After some contributions such as 4lw command, reconnection(ignored by ClickHouse community),  we found that the goals of two projects are not consistent. HouseKeeper mainly supports ClickHouse, while RaftKeeper is moving towards the direction of being widely compatible with Zookeeper scenarios, such as HBase.
Therefore, we decided to develop the projects independently. We have done a lot of rewriting on the core modules mentioned above and added some differentiated features compared to HouseKeeper, such as NIO network framework, support for reconnecting in session timeout, a new session management module, support read-write-consistency in session and  a new execution pipeline.
And now RaftKeepeer an HouseKeepeer is quite different bouth in functions and internal implementation.

@JackyWoo Thanks for explain, do you have results of keeper-bench vs clickhouse-keeper?

We did not test clickhouse-keeper right now. But I think we shuold do it.


Implemented pop

While I think this patch is nice, I'm not sure I want to add "non-basic" features to the library itself.
@jplana what do you think?

Just checking in, would be a handy shortcut feature to have.

I see no reason not to merge this.


Integrating branch rules

Integrates the repo-branch-settings-page into gitness.
e2e video:

https://github.com/user-attachments/assets/8c10d2b0-210d-42e3-8e97-8d2a26a68eeb

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


[Suggestion] Explanation for CSV format

Hello,
Thank you for your package, it is very helpful.
I make a suggestion: it would be nice to explain a little bit some things about the CSV format (and maybe for others formats).
I made several tests to understand what it was possible to do with CSV format.
So I know now that CSV works only:

with only comma separator (semicolon or other separator are not accepted)

with non-printable control character CRLF (Carriadge Return and Line Feed) and not only LF (Line Feed)

with a specific header : str,en_US,fr_FR, and so on

with or without double quotes

the key can be a keyword or simply the english version... we can mix the 2 ways, for instance:

"str","en_US","fr_FR"
"button to change the language into french","button to change the language into french","bouton pour passer l'application en langue anglaise"
"form.error.client_user.not_valid","please enter a valid user","merci de saisir un utilisateur valide"

and when we change a translation, we need to rebuild the whole application

Personally, with each modification, I redo a sort on the CSV file according to the key to reorder everything in alphabetical order to identify possible duplicates.
Do not forget to put the header back in the 1st line afterwards.

I agree, at least a CRLF instead of LF warning would be appreciated.

More information is always welcome, but I found that the example app has some files, including a csv.
Folder: https://github.com/aissat/easy_localization/tree/master/example/resources/langs


The extension exited instantly. Please check the logs.

After installing cachetools (after typing pip3 install cachetools --user) in the terminal for the wiki search, it states that "The extension exited instantly. Please check the logs."

Hi, which version of python are you using?
Also, can you launch ulauncher from the terminal with the -v flag, and paste the logs here for me to examine?

Hey there :) I am using python version 3.8.
However, I found the issue. I haven't installed the required packages. That solved the problem. Apologies for the concern.
Have a nice day further


tests

Automatic testing is a bigger job than I originally planned for, because it requires actual message requests etc from discord's api. The example projects are used for most testing, the best way I can think of is creating a bot that sends messages asserts messages/actions back from the example bot.
Look for other opensource bots to see how they handle it.