Components should play nicely with Rails caching mechanisms

Feature request
Components should provide a digest to Rails views, or be able to use Rails explicit caching directive comments or be able to provide a cache_key.
Essentially we should be able to invalidate a cache based on whether the Component class or template has changed.
Motivation
I'm just building on some previous reports primarily around where templates live and the filenames of the template/s. My concerns come down to integrating with Rails caching basics.
The issue that we run into is basically summed up by
## In any view/partial
cache[object, another_object] do
  render(MyComponent.new(attribute: value))
end

In this case if the template for MyComponent is changed the cache will not be invalidated. I tried to add MyComponent to the array used by cache and provide a self.cache_key method that used ActionView::Digestor but without having some further mechanism to invalidate the digestor's cache for the template/s when the template changes this didn't work.
Rails allows for explicit directives to be used (https://guides.rubyonrails.org/caching_with_rails.html#explicit-dependencies) but by default this will only look inside app/views. You can add a view path append_view_path("app/components") but the digestor is expecting a partial and so a template filename would have to be prefixed with underscore.
The way we are currently working around this is to have an ApplicationComponent that our components inherit from and where we override ActionView::Component::Base.matching_views_in_source_location so that templates are now found in app/views/component_templates and where the files are prefixed with underscore.
  def self.matching_views_in_source_location
    return [] unless source_location

    *path, file_name = source_location.chomp(File.extname(source_location)).split("/")
    path.pop # remove components
    path.concat(["views", "component_templates"])
    path_to_template = path.push("_#{ file_name }").join("/")

    Dir["#{ path_to_template }.*{#{ActionView::Template.template_handler_extensions.join(',')}}"]
  end

Then in the above example where cache invalidation does not work via template digest changes we can do
## In any view/partial
# Template Dependency: component_templates/my_component %>
cache[object, another_object] do
  render(MyComponent, attribute: value)
end

I think if AV::C is going to be core or integrate with Rails it would need a way to expose template digests nicely, or provide cache_key probably at the class level. If not then as a last resort we would need a way to use explicit directives in templates that use ActionView::Components internally.
I'd also be all 👂 to people who have solved this already or if I've missed something about the features ActionView::Component provides!

Happy to see another report on caching! Issue 42 also opened up this question in the early days and is marked with the V3 tag.
I'll start doing some research on my end based on your research @ozzyaaron and try to see if I can take a stab at it 🤘🏽
@joelhawksley , anything I'd need to do or know before starting? All help is welcome!

@pinzonjulian I don't know if there's much I can add here, as my experience with caching is fairly minimal. Anything we can do to improve our compatibility with Rails gets a big 👍 from me 😄

@pinzonjulian Not sure if you're still researching this, but I was interested and did some digging on my own. Here's what I found:

Caching starts with the cache method (or it's variants, cache_if, cache_unless, etc)
From there, a couple steps down, there's a call to Digestor.digest, passing in a lookup_context
From what I can tell, lookup_context is used to look up where a given view file is, given a string. So if it's given "posts/post", it might resolve that to app/views/posts/_post.html.erb. We can append paths to that lookup context via eg append_view_path
Stepping back up and down into that Digestor.digest call, we end up here. From what I can tell, this class's job is to build up a dependency tree and convert it to a digest key. I think the only important part here (for us) is the call to DependencyTracker.find_dependencies, which lands us here
A few more steps down and we end up here. This is pretty well documented by the "Template digest" docs here. "Implicit dependencies" is render_dependencies and "Explicit dependencies" is explicit_dependencies. I think we're interested in the render_dependencies, though there might be a workaround worth exploring with explicit_dependencies maybe.
render_dependencies is interesting. It splits the template file's source code based on the render keyword, then calls add_dependencies, which tries to determine if the method is being called with a string (eg "posts/post") or a variable (eg @post). I think this is the part we'd want to behave differently. We'd want that to support a ViewComponent.new somehow.

So, in summary, I think there's two things we'd need to change to get caching working for ViewComponent:

I think we need to add our ViewComponent files (at least the template, but ideally also the ruby class file, though I'm not sure if Digestor.digest is set up to handle non-template files) to lookup_context, maybe via append_view_path.
We need to update DependencyTracker to handle a ViewComponent instance as the argument to render.

I'm not sure how much of that I misunderstood, but hopefully it helps! @joelhawksley perhaps you know of someone at Github with more experience in this area that could spend some time looking over this and make a recommendation? I'd be happy to make a PR to ViewComponent and/or Rails, but I want to make sure I'm on the right track before I dive in over my head.

Hey @dkniffin ! I've been working on and off on this and I've been documenting my progress here.
https://www.notion.so/View-Component-07d8bef1ed3342498b5805cc3166a82a
I'd like to bring my findings into Github somehow so we can build upon it together but not sure how. Any ideas @joelhawksley ?

@pinzonjulian that's awesome! We both followed through it all and came to nearly the same conclusion. The bit that I think you missed was the part where Digestor.digest builds up a dependency tree. I think the dependencies that's passed in there is a red herring and the actual important dependency building is in the call to tree

Yeah I definitely remember the dependency tree being built but that's where I started slipping a little. I couldn't understand how to register a new location for Rails to look for dependencies. I'm curious to see if fixing that would unblock all of the possible ways for caching (there's a comprehensive list in my notion page).
I'd really like to help and keep learning about this so count me in in any further development if possible!

@dkniffin @pinzonjulian thank you for all of the time you've spent researching this issue! Perhaps one of you could provide a PR with a failing test for us to work against? I'd love to set up some time to pair on a solution.

@joelhawksley I would be glad to do that, but I'm not quite sure how that test would look. This is the template I'd want to test:
<%= cache do %>
  <%= render MyComponent.new %>
<% end %>

and the result I'd be testing for is that if the code for MyComponent.new changes, the cache gets invalidated. But I'm not sure how to do that. Specifically, I guess I don't know how I'd change out the code for MyComponent (the template and/or the class).

@jhawthorn I hope you'll forgive me for summoning you to a random repo you haven't contributed to before, but I saw you made a somewhat recent change to ActionView::DependencyTracker, so I'm hoping you might have a better idea of how this works and/or how to make a test for this and/or how we might get this working. 😅
My team and I would really like to use this library, but I'm afraid that this lack of caching support may be a blocker for us

@joelhawksley Any progress on this?

@joelhawksley I definitely empathize :/ I haven't had much time to dedicate to this either. I would love to create a PR with a failing test, but I honestly don't know what that failing test would look like. I can't wrap my head around a proper way to test that changing the contents of a file busts the Rails cache, unless I use File.open or something, but that seems brittle. But maybe it'll work? 🤷♂
However, a team member and I have thought a little about how this feature could be implemented. As stated above, I think there's two things that need to change:

We need to ensure that Rails knows to look for template files in the app/components directory. (I still haven't thought through this a lot, but I think this should be an easy problem to solve)
We need to update DependencyTracker to handle a ViewComponent instance as the argument to render. I think that means updating ERBTracker#add_dependencies to look for a regex like /.*Component.new/.

I hope to find some time at some point to test the idea in 2 out. I think that would make more sense as a PR to Rails, but I'm not sure how to have that regex not be dependent upon how ViewComponent classes are named. Maybe I could make it generically "look for any instances of a .new call" or something. 🤷♂  If anyone has thoughts on that, I'm all ears!

@dkniffin we have tests that change files, see https://github.com/github/view_component/blob/master/test/view_component/integration_test.rb#L48 for an example.
Perhaps you could build off that?

@joelhawksley Oh, awesome! I didn't know there was something like that in the codebase already. Yes, that should make writing that test a bit easier. I'll see if I can take a stab at it sometime this week.

@joelhawksley Alright, I've created that PR: https://github.com/github/view_component/pull/476
Now for the solution. I don't think there's a way to accomplish #2 above without some changes to Rails, specifically in ERBTracker. I have a rough idea of what needs to change there, so I'll take a stab at it. Hopefully the Rails team is receptive to the change.

Bump

@joelhawksley A few of my teammates suggested a possible "workaround" to the problem here. We could add a new ViewComponent#md5 method that returns a hash of the contents of the files for the component, so that if the component changes in any way, the hash does to. Then, that method could be used in the cache call from Rails.
For example:
cache([other_cache_keys, MyComponent.md5]) do
  render(MyComponent.new(attribute: value))
end

It's still not perfect because users will have to remember to do that, and if there's a cache call at the top of many layers of abstraction, it would have to be aware of the component call deep below to include it, but it's a start.
What do you think?

I'm pretty sure #cache_key is called by the cache call on each element in the array. We attempted to create a cache_key method on the Component (functionally the same as having to call md5) but the issue is that you either need to make an opinionated choice like do a full run of templates every time in development OR you need to hook into the existing Rails mechanisms which are or are not watching for file changes. I think it would be nicer if ViewComponent tracked with the Rails configuration.
Further what we're seeing in the latest release (2.20.0) the way templates are found is becoming harder to interact with (we used to override .matching_views_in_source_location in our base ApplicationComponent < ViewComponent::Base) and is becoming less configurable. We moved our templates into a more standard Rails location so we could use explicit cache hinting but we're now locked on a previous version until we can figure out how to use these hints again.
I think it would be great if in the short term the class itself (derived from ViewComponent::Base) had a simple method to return its template location, or if ViewComponent could have its base template location changed.

I think it would be nicer if ViewComponent tracked with the Rails configuration including things like prepended view paths and whether classes are being cached or not.

Agreed. We've already moved in that direction with https://github.com/github/view_component/pull/509.

I think it would be great if in the short term the class itself (derived from ViewComponent::Base) had a simple method to return its template location [...]

I'd be 👍🏻  to this change, and have started work on implementing Base.template_locations. @ozzyaaron what would you be willing to suggest what the return value of this method should look like?

We moved our templates into a more standard Rails location so we could use explicit cache hinting

I'm sad that this was necessary for you, and hope we can improve ViewComponent so it no longer is ❤

Hi @joelhawksley thanks for the questions! We're getting a lot out of using ViewComponent thus far and its free, so please don't take my opinions negatively, we're thankful for what we get 😄 🦀

Agreed. We've already moved in that direction with #509.

Thanks! IMO a great move :)
I have to do a bit more testing but I think when I was looking at 2.20.0 the issue I saw was that matching_views_in_source_location was no longer being called on our own superclass but on ViewComponent::Base so 2.21.0 may fix that for us. I need to check :)
On the ability to have a method template_locations I think it may need a bit more consideration to make it easier to people. To me there are 2 concerns that we have found to be a bit difficult to override hence we had completely re-written matching_views_in_source_location for our own purposes including being able to use inherited templates.
This is just my opinion based on our use so far. I personally think there are 2 concerns

base path (where the templates can be found)
template file name or pattern

I think you could probably get away with just allowing people to define both together (e.g. template_location which might be app/components/component and then it would find the right variant and postfix the extension like html.js) but having the two concepts be separated may make it more customisable to users and probably allow easier hooks to Rails wrt prepend base_path to view paths, and adding base_path to the ActionView::LookupupContext and so on which should aid in being able to monitor that for updating template digests as required. For use we'd probably just do def template_path; Rails.root.join("app/views/component_templates").to_s; end
The reason I separately suggest a template filename is for the concern of users and formats/variants. As a user I'd far prefer to just deal with a template name (perhaps as simple as a template_name method on Base that can be overridden by inheritors) and then ViewComponent would use that to find the correct variant. Largely I don't see people using something like render "action_name.js" so I think being able to have a def template_name; #{ self.class.underscore }; end which then ViewComponent uses later with the appropriate format would be cool! For us we may just do def template_name; "_#{ super }"; end
For most users I'd imagine they'd never notice and not have to change anything with changes like the above as ViewComponent::Base can easily provide the same defaults it has assumed up until now. For us we'd just override the template_name and base_path in our ApplicationComponent superclass.

I'm sad that this was necessary for you, and hope we can improve ViewComponent so it no longer is ❤

Hey man, don't worry! We used a couple component frameworks previously and they all had major flaws even for our meager use cases. ViewComponent is one we have jumped into feet first though and have only had to override 1 method thus far. I'd love to be able to help out but have a couple other outside-work projects I'm already helping on. I do think if ViewComponent were able to get the template path exposed and then add an effective watcher to the Rails cache digestor mechanism it would sort out most of our current concerns. Even with the small issues, ViewComponent is making our code easier and more robust for sure!
Thanks to all the contributors! 💙

@ozzyaaron thanks for your detailed feedback!
Can you provide more context on why you're choosing to locate templates in a separate directory from the component objects? If it's just for the sake of caching, I feel like we should pursue supporting caching properly with the existing template organization structure.
FWIW, we did have a version of ViewComponent a while back that used templates from app/views, but it made it easy to break the encapsulation ViewComponent provides, as the templates were then accessible in other Rails views outside the context of their associated component.

@joelhawksley you're absolutely right that we have just chosen to change the location and template prefix to work with Rails caching. I think if we were able to have ViewComponent support caching normally through calls like cache(current_user.locale, object, Component) that would be ideal for us and probably for everybody :) I am certain we could then just revert the modifications we've made to template finding.
In some places I've been there were some use cases for sharing templates outside of the Rails or server-side framework. With a pretty small bridge/adaptor we've rendered template via multiple mechanisms. For example writing templates that would be rendered by Node and Ruby systems. I'm not suggesting that as a use case for ViewComponent just as an interesting outcome I've seen really investing in component templates previously.

Has there been any progress made on this in the past year? I see it's been marked for the V3 release

@dkniffin not to my knowledge. We don't do much view caching at GitHub, so we aren't able to prioritize this work internally. We tagged this issue with the v3 label as we view it as a blocker on the v3 release.

I'm still keeping an eye on this thread, hoping for something to get added 🤞
I wanted to mention that #980 implemented a POC of how this could work, since it's not linked in this thread.

@joelhawksley Is there anything you can do to unblock this on the Rails side of things? You seem to have been able to guide the initial commit to Rails 6.1 that enabled ViewComponent in the first place, so maybe you have some tricks? From an outside view it seems like the PR needed at the Rails side is stalled and it is a bit unclear to me why: https://github.com/rails/rails/pull/42850

@erikaxel I'm sorry to say that I don't think I have much sway here. Caching support for ViewComponents is likely a fairly significant effort that we (GitHub) don't currently have the resources to take on.
I'm guessing @Matt-Yorkley would be keen for someone to step up and try to land that PR, for what it's worth. Perhaps you and @dkniffin could resurrect it? I'd be happy to provide pairing support as needed ❤

I dropped it because there seemed to be zero interest on the Rails Core side and a strong reluctance to allow the proposed changes to some of the relevant ActionView classes that handle creating/mapping the digests for each fragment. I don't think it's feasible to do it without some of those changes.

@joelhawksley I'm still unclear on why the Rails PR (https://github.com/rails/rails/pull/42850) won't be accepted. Is there more work required to make it acceptable in Rails Core? imo, a complete re-write of the rails caching system would be great, but short of that happening, it seems like the changes @Matt-Yorkley made are a reasonable short-term solution.

@dkniffin I don't have any context beyond what you can read on the PR 💔 I wish I had a better answer for you 😞

We don't do much view caching at GitHub, […]

@joelhawksley Forgive me if this is slightly off-topic, but would you mind elaborating on why GitHub doesn't need view caching? How do you ensure a speedy response without the popular Russian-doll caching approach?
Perhaps there are useful insights here for other View Components users to side-step this whole caching issue.

@marckohlbrugge we cache at the request level for logged-out traffic. For logged-in traffic, we cache RPC calls vs. view rendering as view rendering is generally not a bottleneck for us but RPC calls are.
Much of GitHub's UI changes based on a user's permissions so it is difficult to get a high cache hit rate. We do cache rendered markdown though, as it is more or less viewer-agnostic. It's also tricky to do view caching in combination with feature flags that modify the DOM, which we do quite a bit of.

I think https://github.com/ViewComponent/view_component/pull/1650 might make components and caching play well together. It would be nice to have a test that can be run against that PR, but I likely won't tackle that any time soon. If anyone is interested in writing a test for that and opening a PR, please do!

@Matt-Yorkley would you be up for helping @BlakeWilliams validate if #1650 improves caching compatibility?

It looks like a great PR, but I don't think it'll directly resolve the issues with fragment caching...

Yes, #1650 definitely doesn't improve the caching problem.
ActionView::DependencyTracker::ERBTracker#render_dependencies

still includes "news/new" this is from scanning MyComponent.new and deciding (via regex) that new was the dynamic part.  Then it plurarlizes it to make "news" and prepends that to make news/new.  We need a way for ActionView::DependencyTracker.find_dependencies to recognize that MyComponent.new is a renderable, not some sort of ERB template.

@joelhawksley I would be interested in taking this on
here are some of my thoughts that I plan to implement
I plan on adding a cache_on macro to each component that accepts a method name/proc that uses these attributes to build a cache digest
I feel this is the best way as it allows the component to control its own caching dependant on its own local state wich I feel is a better fit than caching on external global state that the component has no context on, it will also be easier to debug by just trowing a binding.irb in the cache methods


How to change Time unit to days

How to make booking price according to day

Hi @deviprasad97 ,
You just have to set in Cocorico/CoreBundle/Resources/config/parameters.yml this parameter:
cocorico.time_unit: 1440

Thank you it worked

Is it possible to set for the user the option of hour or day? Both options?
Thank you!


Playing with the GH API and had an incorrect ID


New tool tag / GTN webhook

In support of https://github.com/galaxyproject/galaxy/pull/10024, we can now annotate training materials with the precise tool ID and optionally version.
We will add this to planemo so most people won't care about it, but for the older tutorials we can migrate them or encourage authors to, in order to take advantage of the webhook.
Please see https://github.com/galaxyproject/galaxy/pull/10024 for more information on what the tool tag will be used for.
I have converted a couple of training materials, but we should focus on doing the rest of the introductory ones before merging.

We've taken the opportunity to indicate if just a tool ID is specified:

Or if a tool version is specified as well:

awesome!


[VS Code] [Audio] Request startOrJoinCall failed unexpectedly without providing any details.

Error:
Request startOrJoinCall failed unexpectedly without providing any details.
Steps to Reproduce:
1.
2.

Version Data

extensionName
VSLS-Audio

extensionVersion
0.1.91

applicationName
VSCode

applicationVersion
1.65.2

platformName
Windows

platformVersion
10.0.19042

Closing and marking as a duplicate of #4076. This could be caused by a corrupt install, so please try running the command Live Share: repair audio installation as well. You can also disable the extension so you can continue using Live Share without audio.


klipper: unstable-2022-09-11 -> unstable-2022-09-16

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for klipper is: "The Klipper 3D printer firmware"
meta.homepage for klipper is: "https://github.com/KevinOConnor/klipper"
meta.changelog for klipper is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found unstable-2022-09-14 in filename of file in /nix/store/gqqnrbrkfb7qp3xxbl5sqaza4d38jpxv-klipper-unstable-2022-09-14

Rebuild report (if merged into master) (click to expand)

4 total rebuild path(s)

4 package rebuild(s)

First fifty rebuilds by attrpath
klipper
klipper-firmware
klipper-flash
klipper-genconf

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/gqqnrbrkfb7qp3xxbl5sqaza4d38jpxv-klipper-unstable-2022-09-14 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A klipper https://github.com/r-ryantm/nixpkgs/archive/94af33f71eb8f22e45ae444da5b048aedc60fca9.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/gqqnrbrkfb7qp3xxbl5sqaza4d38jpxv-klipper-unstable-2022-09-14
ls -la /nix/store/gqqnrbrkfb7qp3xxbl5sqaza4d38jpxv-klipper-unstable-2022-09-14/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

4 packages built:

klipper
klipper-firmware
klipper-flash
klipper-genconf

Maintainer pings
cc @lovesegfault @zhaofengli @cab404 for testing.

this needs to stop D:

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for klipper is: "The Klipper 3D printer firmware"
meta.homepage for klipper is: "https://github.com/KevinOConnor/klipper"
meta.changelog for klipper is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found unstable-2022-09-15 in filename of file in /nix/store/bhi41srd0gbh5f3p9naagj2bj7fyd15r-klipper-unstable-2022-09-15

Rebuild report (if merged into master) (click to expand)

4 total rebuild path(s)

4 package rebuild(s)

First fifty rebuilds by attrpath
klipper
klipper-firmware
klipper-flash
klipper-genconf

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/bhi41srd0gbh5f3p9naagj2bj7fyd15r-klipper-unstable-2022-09-15 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A klipper https://github.com/r-ryantm/nixpkgs/archive/5b1feadc7891214435501e2da336ac74caee5e79.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/bhi41srd0gbh5f3p9naagj2bj7fyd15r-klipper-unstable-2022-09-15
ls -la /nix/store/bhi41srd0gbh5f3p9naagj2bj7fyd15r-klipper-unstable-2022-09-15/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

4 packages built:

klipper
klipper-firmware
klipper-flash
klipper-genconf

Maintainer pings
cc @lovesegfault @zhaofengli @cab404 for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for klipper is: "The Klipper 3D printer firmware"
meta.homepage for klipper is: "https://github.com/KevinOConnor/klipper"
meta.changelog for klipper is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found unstable-2022-09-16 in filename of file in /nix/store/v268ncpab7pzx9h15q5a44spwn8z62ak-klipper-unstable-2022-09-16

Rebuild report (if merged into master) (click to expand)

4 total rebuild path(s)

4 package rebuild(s)

First fifty rebuilds by attrpath
klipper
klipper-firmware
klipper-flash
klipper-genconf

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/v268ncpab7pzx9h15q5a44spwn8z62ak-klipper-unstable-2022-09-16 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A klipper https://github.com/r-ryantm/nixpkgs/archive/e32e337bcbd5b373963cb0c9c61bc5e752f4f8e7.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/v268ncpab7pzx9h15q5a44spwn8z62ak-klipper-unstable-2022-09-16
ls -la /nix/store/v268ncpab7pzx9h15q5a44spwn8z62ak-klipper-unstable-2022-09-16/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

4 packages built:

klipper
klipper-firmware
klipper-flash
klipper-genconf

Maintainer pings
cc @lovesegfault @zhaofengli @cab404 for testing.

Who set this up with automatic updates, and why? Nixpkgs is kind of not fit for daily updates of packages. @SuperSandro2000 or is it?

@lovesegfault Can we at least set it up to do monthly updates?

Who set this up with automatic updates, and why?

Because we want automatic updates but until recently r-ryantm did not update open PRs which limited the amount of updates a bit.
I think the unstable-git-updater should get an option to only create updates every X days.

well, I am all for automatic updates, but yeah, limiting

Because we want automatic updates
Yeah, but klipper's automatic ones are machine gun we knew we can't keep up with)

I think the unstable-git-updater should get an option to only create updates every X days.
That would've been nice


[SPARK-20656][CORE]Support Incremental parsing of event logs in SHS

What changes were proposed in this pull request?
Currently loading application page from history server is time consuming, if the eventlog size is high. (Eg: ~47 minutes for a 18GB eventlog file). Currently, when there is any changes in event log, history server parses the entire eventLog even for smaller changes in eventLog. In this PR, we are supporting incremental parsing of event log by storing the in memory store to a hash map and will not close the store until it is valid.
Why are the changes needed?
To speed up loading history server page

Does this PR introduce any user-facing change?
No

How was this patch tested?
Added UT, Manual tests and existing tests.
Created an eventLog of size ~2GB. Added a few more events. Loading time without the PR is ~1 minute and after the PR, it is around 2 secs.

Merged build finished. Test PASSed.

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

Test build #115049 has started for PR 26821 at commit db79fdd.

cc @vanzin @squito Kindly review

Test build #115049 has finished for PR 26821 at commit db79fdd.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
class SQLAppStatusListenerData(
class HiveThriftserver2ListenerData(

Merged build finished. Test PASSed.

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

Test build #115051 has started for PR 26821 at commit 1889b53.

Test build #115051 has finished for PR 26821 at commit 1889b53.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

Merged build finished. Test PASSed.

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

cc @HeartSaVioR

Test build #115052 has started for PR 26821 at commit b6b2c5a.

Merged build finished. Test PASSed.

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

Thanks for cc.ing me, @dongjoon-hyun . I'll take a look.
Btw, I think we have another JIRA issue for supporting incremental parsing SPARK-28870 which has broader goal - run with any implementation of KVStore.
At first glance, this patch could cover SPARK-29261 and with SPARK-29111 it may resolve SPARK-28870 altogether - though we struggled on the details previously so I need some time to go through deeply.
@shahidki31
I guess you've been following through the previous discussions/efforts @Ngone51 and me, and @vanzin, @squito have been made. (#25577 and #25943, and relevant google docs in relevant JIRA issues/PRs) If not, it would worth to go through, as we've discussed in details.

Test build #115052 has finished for PR 26821 at commit b6b2c5a.

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

Merged build finished. Test PASSed.

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

Thanks @HeartSaVioR , I will go through it.
It seems, I haven't used snapshot/checkpoint for storing the underlying kvstore. Instead, in this PR, I am not closing the store, whenever there are changes in event logs or invalidate cache. Currently it supports InMemory store, but we can easily extend to disk store as well.

Instead, in this PR, I am not closing the store, whenever there are changes in event logs or invalidate cache.

This patch is simpler because this doesn't take "restarting SHS" into account. Restarting SHS will lose the information. And for now we may not want to tracking line offset in SHS's KV store (listing) since the line offset is only effective during single run of SHS.
When you consider restoring KV store & state of listeners during restarting of SHS, you will have to store the snapshot of KV store into somewhere (that's why SPARK-29111 came in) and then you have to concern about compatibility of snapshot (entities in KV store including live entities on listeners) across Spark versions. That's why I had to change the design and introduce SPARK-29779 instead of snapshotting.
We've already gone through bunch of discussions because it is not that simple in reality as it seems; so please go through these PRs as well as design docs.
I guess the patch can be reviewed right now if the community prefers to have a solution which works within single SHS run first (though this may conflict with compaction #26416 which needs some arrangement), but if the community wants to have a solution which covers more cases, SPARK-28870 seems to be the way to go. (It doesn't mean this patch will not be valid - this patch could cover SPARK-29261 with some modification.)

I was also working on a PR for incremental parsing in SHS as well, and there are 2 ways to skip the parsed content: filtering by lines (the approach in this PR) and skipping by bytes (see mergeApplicationListing). From what I tested locally, filtering by lines roughly takes about 30 seconds for file sizes ranging from 10MB to 400MB, while skipping by bytes only takes 2 ms for a 400MB file.

there are 2 ways to skip the parsed content: filtering by lines (the approach in this PR) and skipping by bytes (see mergeApplicationListing).

Yeah if possible we should deal with latter approach. I guess that brings more changes as ReplayListener just relies on Scala API which provides lines (no offset information) so we should get our hands be dirty, but it definitely worths to do.

From what I tested locally, filtering by lines roughly takes about 30 seconds for file sizes ranging from 10MB to 400MB, while skipping by bytes only takes 2 ms for a 400MB file.

Hi @oopDaniel , Actually I tried with both the approach, and it seems skipping bytes seems more complicated as we need to handle more edge cases. Also, I tested this PR with 2GB event log file and I think the time to load UI took around 2 seconds (?) including filtering and replaying. Also it is not difficult to add the skipping bytes, as all we need to do is add the bytes read parameter instead of lines read parameter and handle the edge cases. @HeartSaVioR I think the approach which you guys are doing is great, as it handles restarting SHS. But, if we can review this PR related to incremental parsing, extending to snapshotting would be easier I guess.. If there is a working PR for that, I can close this.

@shahidki31
No I didn't intend to persuade you to close this. I'd just wanted to make sure we get a clear picture of full implementation before dealing with each part, but it's OK for me if you'd like to deal with current solution as I think I can deal with extending the solution with snapshotting.
I could take a look with current solution, but you still need to persuade at least one committer to push this forward.
Btw, we'd be better to clarify the performance test in details. It should include at least...

size of event log file for initial load
elapsed time for initial load
count/size of events for addition (mostly about size)
elapsed time for loading additional events

For me, your statement in PR description sounds to me as skipping (via read and drop) 2G takes around 2 secs which is still not ideal (as we know how to do it better), though I agree that's still a huge improvement.

Btw, we'd be better to clarify the performance test in details. It should include at least...
size of event log file for initial load
elapsed time for initial load
count/size of events for addition (mostly about size)
elapsed time for loading additional events

Thanks @HeartSaVioR , I'll try more performance testing based on size and initial load.

Thanks @HeartSaVioR for the review. I will update the PR as well as post the performance reports.

Test build #119604 has started for PR 26821 at commit b6b2c5a.

Test build #119604 has finished for PR 26821 at commit b6b2c5a.

This patch fails build dependency tests.
This patch does not merge cleanly.
This patch adds no public classes.

Build finished. Test FAILed.

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

Test build #120468 has started for PR 26821 at commit b6b2c5a.

Test build #120468 has finished for PR 26821 at commit b6b2c5a.

This patch fails build dependency tests.
This patch does not merge cleanly.
This patch adds no public classes.

Build finished. Test FAILed.

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


How can I get email of other people

How can I get email of other people

@sithu-go Currently there is no way to do that. A scrapping function could be implemented but keep in mind that not all users show by default their email.


Update VideonDownloader download logic to download in parallel only when its available

fix YoutubeDLWrapper downloading
Update VideoDownloader download logic

Codecov Report

Merging #46 (6d90783) into master (7783e35) will decrease coverage by 0.56%.
The diff coverage is 22.22%.

@@            Coverage Diff             @@
##           master      #46      +/-   ##
==========================================
- Coverage   35.38%   34.82%   -0.57%
==========================================
  Files          11       11
  Lines         308      313       +5
==========================================
  Hits          109      109
- Misses        199      204       +5

Impacted Files
Coverage Δ

twitter_video_tools/video_downloader.py
46.15% <22.22%> (-10.99%)
:arrow_down:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Dynamic entry support

What kind of change does this PR introduce?
feature

Did you add tests for your changes?
yes

If relevant, link to documentation update:

Summary
Enable to change the value of the entry option during watch mode.
Related: https://github.com/webpack/webpack/pull/3354, https://github.com/webpack/webpack/issues/2874

Does this PR introduce a breaking change?
No.

Other information

@sokra @TheLarkInn Let me know if there are anything else I should work on.

@sokra Fixed identifier and readableIdentifier. Please check.

Sync master and I think we are looking good.

@TheLarkInn fixed conflicts.

Sorry we've been merging a lot lately. Mind syncing again and I'll.merge right away.

@TheLarkInn done.

Thanks!!


Replacing eval with fromJSON/toJSON in clone method

Use of eval in JavaScript is generally discouraged (see here) and many projects (including our own) hope to avoid it in our code bases. Also I believe, but haven't thoroughly tested, that the current clone method will not work in many cases when JSRealB is rolled up into a single JS file as a dependency of another module, as the imports of the constituent class functions in Terminal.js, Phrase.js, and Dependent.js are removed during tree-shaking as the roll up tool doesn't believe those functions are used and ignores the presence of eval.
This PR replaces the use of eval in the clone methods of Terminal, Phrase, and Dependent with the use of fromJSON and toJSON. This change also means that a single definition of clone on Constituent is possible. This PR does not touch the uses of eval in the demos in this repo which are not built into the JSRealB module.
Testing this change did raise a pre-existing issue which I noted here: https://github.com/rali-udem/jsRealB/issues/52
Please let me know if I can pass on any more details or make any changes. Thanks so much for JSRealB!

Simon thanks very much for this improvement removing eval.  I will look into the bug about ".ow" that you found.


feat: Command Click for nested properties

Description
Building on top of Command Click we are now adding more links for entities where navigation is possible.
This is mainly JS Objects where function and variable names are part of the code itself. Clicking on the link will navigate to the JS Object and set the cursor on the item you clicked on.
We are also enabling this for Form Widget where in Form1.data.Input1 the "Input1" link will take you to that widget

TLDR;
You can now command click on nested properties of an entity

Fixes #18636
Media
https://user-images.githubusercontent.com/12022471/208083276-e92cef34-f3bc-4822-8dd6-c53b21aad587.mov
Type of change

New feature (non-breaking change which adds functionality)

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions, so we can reproduce.
Please also list any relevant details for your test configuration.
Delete anything that is not important

Manual
Jest
Cypress

Test Plan

Add Testsmith test cases links that relate to this PR

Issues raised during DP testing

Link issues raised during DP testing for better visiblity and tracking (copy link from comments dropped on this PR)

Checklist:
Dev activity

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] PR is being merged under a feature flag

QA activity:

[ ] Test plan has been approved by relevant developers
[ ] Test plan has been peer reviewed by QA
[ ] Cypress test cases have been added and approved by either SDET or manual QA
[ ] Organized project review call with relevant stakeholders after Round 1/2 of QA
[ ] Added Test Plan Approved label after reveiwing all Cypress test

/ok-to-test sha=feb476b

/ok-to-test sha=928b694

/ok-to-test sha=a069baf

/ok-to-test sha=4267646

/ok-to-test sha=981447b

/ok-to-test sha=5631988


fix(context): c.json() allows object and returns JSONParsed

Fixes #1800
Author should do the followings, if applicable

[x] Add tests
[x] Run tests
[x] yarn denoify to generate files for Deno

@DeanMauro Thank you for reviewing.
I'll merge it now.


Remove LIKEs feature

The new Dashboard doesn't have LIKES (it has favorites instead), and the feature doesn't really make sense now, so we've decided to remove this feature from the UI. LIKES are currently in different places:

Public pages:

/me (example)
/maps (example)
/datasets (example)

Actual Dashboard: Maps (Ordering / Filtering / Liking)

Actual Dashboard: Datasets (Ordering / Filtering / Liking)

Since we're reusing LIKES to implement FAVORITES we need to remove LIKES before we release the new Dashboard to everyone. As part of the release, we have to "reset" LIKES so that New Dashboard users don't have any favorites.

Ok, thank you to @csubira and @jesusbotella we've found that I didn't raise the version number for editor assets so now it should work.
Also, we have to do a new acceptance test which is. Add users that share likes but they aren't from the same organization and then we test that case with these changes in order to verify that we don't have problems with the current data system.

@ethervoid @csubira, not sure if https://github.com/CartoDB/product/issues/239 is related to this or not. Other than that... is there anything else missing here? Thank you!

@alonsogarciapablo Hi again! @csubira did an amazing job and everything is :green_heart: now. I've deployed the likes branch in our staging env so you can test everything again. I know this is a bit burdensome but I want to be sure everything is backward compatible :)
Thank you

Vamos @ethervoid and @csubira! Team work! I will deploy a dedicated a give it a try again. Thank you!

@ethervoid should we DROP * FROM likes as part of this? Is there any point on keeping the likes given that we're removing the feature?

@alonsogarciapablo as the first part with backward compatibility and to avoid possible side effects I want to keep the data as it is and tests without touching the database. So I just want to be sure that even having those "illegal" likes the app behaves correctly. After that we are going to do the phase two which is create/run the rake to remove the likes and start from the scratch with favorites

Hola! I just deploy this to staging (http://deploy.int.cartodb.net/job/carto-deploy-to-a-new-staging-dedicated-instance/1324/) and I'm seeing the ❤ in the actual Dashboard:

I'm also seeing "something" in the /me public page:

Apparently, de assets version (1.0.0-assets.39) was not modified so the changes were not included. I just updated it (1.0.0-assets.39-test) to be tested and deployed a new dedicated instance with it. Let's check it out when ready!

Thank you @csubira!

I tried this again. I didn't see a single trace of ❤s.
Old Dashboard:

Builder user

Dashboard:

Maps ✅
Datasets ✅

Public Profile

/me ✅
Maps ✅
Datasets ✅

Editor user

Dashboard:

Maps ✅
Datasets ✅

Public Profile

/me ✅
Maps ✅
Datasets ✅

New Dashboard:

Favoriting my own maps ✅
Favoriting maps shared with me ✅
Favoriting my own datasets ✅
Favoriting datasets shared with me ✅

@alonsogarciapablo did you give a try to have users with likes from before to see if there is a problem?

No. The dedicated server already had the new code.

I've tested with likes for compatibility (having old likes in the new) and it's working. Tomorrow I'll deploy this changes

Closing this issue as this has been merged already!

Ole! 🚀


first class functions

First-class functions - treating functions as variables.
Renamed lib struct Calc to YAIWR

Examples of first-class functions and closures applications:
1.
// Run-time:
//    stdout: 1
//    stderr:

fun f() {
  let x = 0;
  fun g() {
    x = x + 1;
    return x;
  }
  return g;
}

let a = f();
println(a());

// Run-time:
//    stdout: 1001
//    stderr:

fun f() {
  let x = 1;
  fun g(num) {
    if (num == 0){
      return x + 1;
    } else {
      x = x * num;
      return g;
    }
  }

  return g;
}

let a = f();
a(10);
a(10);
a(10);
println(a(0));

Are the hashes important for correctness?

Hashing is not essential for correctness. I used it as a mechanism to translate String to numeric representation.
From what I've read, this hashing function should perform well, but I could've used incremental numeric values instead or leave Strings. YAIWR correctness shouldn't be affected either way.
That's what I understood by "compile the variable names to integers" from:
https://chat.soft-dev.org/softdev/pl/maqe6cwi83bk8gxm6zwk5cprdo
Added it to my TODO list in https://github.com/softdevteam/pavel.yaiwr/pull/13 PR.

I used it as a mechanism to translate String to numeric representation.

Well, yes :) What do you use the numeric representation for?

I use it for variables and function id store.
If I have an AST node: Declare { id: "pavel", value: 1 }
It will be stored it in scope hashmap as: { "5953638110699698698":  1 } instead of { "pavel":  1 } where<PHONE_NUMBER>699698698 is a hash of "pavel" string.

Is it a bad idea?

Not necessarily, although I didn't expect you to have to teach Rust how to hash a string from scratch. What's up with HashMap<String, ...>?
Another approach is to convert all variables into a unique integer ID in your bytecode. You would have to do extra work to get the variable name back if you need it (e.g.) to print a human-readable error.

I guess I'm also surprised that you had to change the structure of your variable store to implement first-class funcs.

Well, I didn't have to. I just did.
Nothing fundamental was changed - instead of using String as keys in variables and function hashmaps, now it's u64.
I can remove the hashing bit. It's not really important.
What's confusing? That I changed the stores to have u64 keys or the fact that I used the hash function to convert Strings to u64?

bors try

Please squash

squashed :point_right: eab98cedd21f5c588e20bea24953ccc7ecc3020c


Add core profiles for fedora

Our profiles concepts works perfectly with the machine-readable fedora guidelines. See:
https://communityblog.fedoraproject.org/important-changes-to-software-license-information-in-fedora-packages-spdx-and-more/
And:
https://gitlab.com/fedora/legal/fedora-license-data
We should consider adding in a profile or at least a script to build those. Maybe we need a general mechanism to host a profile (or config) and know when it's out of date...

This is also related to #26


regexp attribute for String properties

Add regular expression attribute strings must comply with. If None (default), any string is accepted.

Current coverage is 96.23% (diff: 100%)

Merging #117 into feat/cleanup will increase coverage by 0.03%

@@           feat/cleanup       #117   diff @@
==============================================
  Files                10         10
  Lines              1369       1380    +11
  Methods               0          0
  Messages              0          0
  Branches              0          0
==============================================
+ Hits               1317       1328    +11
  Misses               52         52
  Partials              0          0

Powered by Codecov. Last update 6779033...fa91d32

This isn't quite ready yet - just checking if match is not None is insufficient: if regex=r'a', 'aa' should not pass.

Shouldn't it? I mean, if it was "^a$", then presumably not.

@fwkoch: Thoughts on 2701a92?

@bsmithyman - Regarding my a/aa comment above, I think you are right. Do you agree with using match(...) (as opposed to search(...) I guess)? Is it ok to just disallow position/end-position arguments with match?
Regarding your commit, a few things:

Is there any reason to save both the pattern and the compiled r.e. as opposed to just the compiled? The pattern is always accessible with regex.pattern, so no need to save both, I don't think.
Also, we should probably allow compiled r.e. as input (rather than just strings), right?

I'll take a pass at these changes and see what you think.

@bsmithyman - thoughts on https://github.com/3ptscience/properties/pull/117/commits/ca2a405ffd25416d1f646345a5e0bef39eb359c8 ? This tackles my two bullet points from above. Also it allows anything with match callable attribute to be used for regex. This could allow for some clever duck typing... Do you think that is a good idea or too risky?

@fwkoch: Re: your comments above
I guess I would tend to lean towards switching to re.search(...), since users can always implement re.match(...) by passing in a search string that starts with a ^. For example, you could imagine a case when the regex part of the validation just checked that a string contains an email address, or something similar, but didn't require that the string be just an email address. Not sure what the use case is, but it seems like re.match is unnecessarily limiting it...?
Also, I wonder if we add an option to expose the matched group dictionary? Not sure what the interface to that is, though. I can see it being useful, but perhaps that is too complicated and should be saved for user code. An example would be (?<account>[a-zA-Z0-9_.+-]+)@(?<domain>[a-zA-Z0-9-]+\.[a-zA-Z0-9-.]+), running on<EMAIL_ADDRESS>yielding {'account': 'someone', 'domain': 'gmail.com'}.

re match vs search - I agree with your comments. match seems arbitrary, especially since we don't allow position to be specified.
I do like the matched group dictionary, but the interface is difficult. String properties should just behave like strings to a user, there isn't really any way to add extra attributes (ie the group dictionary) that can be accessed. It seems like this would almost be part of a (currently non-existant) Dict property. Like, pass a string into the Dict validate function, it is coerced to matched group dict... That's quite a different angle though (and maybe too specific...?).

Yeah, or a subclass of String that just overrides the getter, perhaps. But then the get/set behaviour is iffy. Wondering about something similar for urlparse; maybe we need to give some thought to what that interface would look like. One possible implementation would be to do it w/ an immutable wrapper (i.e., expose it as a separate property...)?


Migrate to Jason

I know that Jason was recently removed from this library in favor of Poison, but has there been any discussion around moving to Jason vs. Poison?
The larger Elixir community seems to have decided on Jason (namely the Phoenix library moving to Jason) as the parser of choice.
I'm currently using ex_twilio in production (thanks, btw!) and it's the only consumer of Poison for me. If the community doesn't want to move to Jason, could the parser be made configurable?

@derekbrown ExTwilio still uses Poison because it makes heavy use of Poison's decode(string, as: struct) feature, which to my knowledge, Jason doesn't implement. I'd happily accept pull requests to make the library configurable, but it would require bringing some version of this feature into this library's code on top of the parser.
https://github.com/danielberkompas/ex_twilio/blob/ee4b61149cb052b1cc5a96353c5c16b98cc13f8a/lib/ex_twilio/parser.ex#L87

See #143

The switch to Jason happened in November of last year.  Can we get a new release that includes this switch please?  Thanks!

@doughsay done! I released v0.9.0 just now.


Update

I have deleted the file.zip file.

@PhD-MU I am sorry, the domain kocaeli.edu.tr is removed from our trusted domains list because it was abused in the past. If you are the student of this school, please enroll to GitHub Student Developer Program. Then apply for JetBrains educational subscription with your GitHub account (GitHub tab at https://www.jetbrains.com/shop/eform/students).


Catch changes to test group

Catch changes to test group
Add test to catch changes to test group.

Land this PR after this: https://github.com/hwchase17/langchain/pull/4803


feat: add ability to bookmark modules

It would be nice if there was a feature on JSR to bookmark modules then we had a page where we could see all our bookmarked modules and a list of new versions of them being released recently.
If you don't follow all of your dependencies on GitHub or something then it can be hard/tedious to keep track on what code should be updated for breaking changes.

I 2nd this


Reference docs for internal models

[x] Page (some methods missing)
[x] Site
[x] PageRevision
[x] PageViewRestriction
[x] GroupPagePermission
[ ] Image
[ ] Filter
[ ] Rendition
[ ] Document
[ ] UserProfile
[x] Embed
[x] Redirect
[x] Query
[ ] QueryDailyHits
[ ] SearchPromotion

Reference docs for Embed added in https://github.com/wagtail/wagtail/pull/2127

I see we’re about halfway through the list after 8.5 years. It seems to me like each of those remaining items could warrant its own ticket so it’s more actionable, so I’ll close this now.


CosmosDb graph partitioning

Azure documentation issue guidance
Thanks for opening an issue in the Azure technical documentation repository.
We use GitHub issues as the primary channel for customer and community feedback about the Azure documentation.
Creating an issue
We prefer that you create documentation feedback issues using the Feedback link on the published article - the feedback control on the doc page creates an issue that contains all the article details so you can focus on the feedback part.
You can also create a feedback issue here in the repo. If you do this, please make sure your issue lists:

[ ] The relevant Azure service or technology.
[ ] A link to the published documentation article that you have feedback about.
[ ] Clear, specific feedback that the author can act on.

Pull requests and article contributions
If you know the change that is needed in an article, we encourage you to submit the changes directly using a pull request. If the change is large, or if you want to contribute an entire article, follow these guidelines:

[ ] Don't surprise us with a big pull request or a pull request with a new article! Submit an issue that describes the details of the proposed large change or new article.
[ ] Include the service or technology area.

We'll route the issue to the appropriate content team for review and discussion.
Tech support and product feedback
If you would like to contact Microsoft about other things, such as product feedback or tech support, please review these guidelines:

If you need technical support using Azure, the paid and free support options are described here: https://azure.microsoft.com/support/options/.

Each article in the Azure technical documentation contains a product feedback button - it's best to submit product feedback directly from a relevant article. Otherwise, you can submit product feedback for most Azure products in the following product feedback forum: https://feedback.azure.com/forums/34192--general-feedback.

Hello,
I have been going through the documentation on partitioning a cosmos db graph here:

I am using the recommended Gremlin.Net 3.4.0rc2 client, but the behavior I'm seeing does not match the documentation.  From my testing, there doesn't appear to be a way to prevent a traversal from going across partitions, even when specifying the partition keys as indicated in the documentation.  This is also the case with the graph explorer in the azure portal.  This is a problem because I'm seeing RU usage increase up to 50%+ over that same traversal (and identical graph) in a non-partitioned collection...and that is with only 2 partitions.  None of my traversals are meant to be cross partition and I'm incurring a pretty large performance hit when I partition.
Is there something that can be clarified in the documentation? Thanks.

@papa-pep Thank you for the valuable feedback,we are investigating the issue.

@papa-pep Are you following an exisitng tutorial, or making a general product statement based upon your project?

@papa-pep I am going to provide this document as a reference: Using a partitioned graph in Azure Cosmos DB

I'm following the best practices according to the cosmosdb graph
partitioning documentation.  This works differently than it did previously
where you had to opt in to cross partition queries.  Is there still a way
to opt in?
On Mon, Feb 4, 2019, 6:12 PM Mike Ubezzi<EMAIL_ADDRESS>wrote:

@papa-pep https://github.com/papa-pep Are you following an exisitng
tutorial, or making a general product statement based upon your project?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/azure-docs/issues/24204#issuecomment-460464411,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMdrygcJ4B2_FUJmc6wFmAlWVtOWlZGdks5vKMxZgaJpZM4ahZbA
.

That is the document I'm commenting on. Is there a way to disable cross
partition traversals? If not, that would be a good thing to document
because it affects how the traversals need to be written and it also has
performance implications.
On Mon, Feb 4, 2019, 6:17 PM Mike Ubezzi<EMAIL_ADDRESS>wrote:

@papa-pep https://github.com/papa-pep I am going to provide this
document as a reference: Using a partitioned graph in Azure Cosmos DB
https://docs.microsoft.com/en-us/azure/cosmos-db/graph-partitioning
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/azure-docs/issues/24204#issuecomment-460465488,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMdryoyVgnfTfAetPYpBmYBrmsHqd9lzks5vKM2mgaJpZM4ahZbA
.

I understand that. I have more than 10gb of data AND I never want to query
across partitions. Is there a solution to this that does not involve
rewriting all of the traversals to specify partition keys at every step?
On Mon, Feb 4, 2019, 6:28 PM Mike Ubezzi<EMAIL_ADDRESS>wrote:

@papa-pep https://github.com/papa-pep Create a fixed collection. Per
the documentation:
The following are details that need to be understood when creating a
partitioned graph container:

Partitioning is required if the container is expected to store more
than 10 GB in size or if you want to allocate more than 10,000
request units per second (RUs).

If your solution does not require >10GB or >10k RUs, then you can stay
with a fixed collection and avoid partitioning.
[image: screenshot 216]
https://user-images.githubusercontent.com/37126106/52246193-b6977f80-2899-11e9-95a9-d11c38a4a320.png
If you already ahve a partitioned collection, you will need to redeploy
and migrate data.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/azure-docs/issues/24204#issuecomment-460467743,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMdryjxkrwA2sTm29hI8TjdHERmszoyOks5vKNAggaJpZM4ahZbA
.

@papa-pep Please reach out to askcosmosdb at Microsoft.com. This is a means to ask the product group directly for product feedback and guidance. This is not for support issues but, they are happy to help you be successful in utilizing the service as best as possible. Thanks!

@papa-pep
We will now proceed to close this thread. If there are further questions regarding this matter, please comment and we will gladly continue the discussion.


Use transferLatch to wait until the item or a failure is emitted

The 'responseUni.await().atMost()' does not work because it wait for item to be available but not the function in with(...) to finish. I use a latch to control the wait.

LGTM.


Initialize currentUser state in redux store when necessary

There is a problem in current behavior:

at the moment of user logging in, currentUser state is established in redux store. Authtoken is saved to local storage. Then it is load the component protected by <PrivateRoute>. <PrivateRoute> checks that currentUser is present in state and has isLoggedIn. So everything works.
However, when the page is refreshed, there is no code to re-establish currentUser state  in redux store (unless redux-persist is used), even though the token is still in local storage. When  <PrivateRoute> tries to check currentUser, it can't find it. So it rejects the route.

This PR is to initialize currentUser state in redux store from local storage  upon page reload.
This PR is to address #16

Oh, I ran into errors when running yarn test. So I didn't test it. But the similar code works on my current project.


reset initial values on destroy

As a WebsocketTracker is destroyed and reconnects after the specified/default interval some initial values are removed (which causes an errors e.g. as .peers is not an object anymore).

It's better to just set all this state in openSocket(). Will do that.

7.5.8


AWS RACI meeting with CP and ISB

Describe the issue
Understand the current and future responsiblities in AWS between ISB and CP.
Additional context

Questions around responsibilites and future responsiblities have come up.
By building on a shared understanding, it will help to know how systems are supported and how they will move over time.

Definition of done

setup upto two meetings with CP and ISB for the evolution of a RACI (current and future state)
Focus of RACI is between ISB and CP team
understand that the space can change/evolve
RACI is a snapshot in time.

The Cloud Pathfinder Team is working on the RACI matrix for Security and Privacy for AWS SEA and will send it to CITZ ISB for review when it is finished. This work is tracked in a different ticket.


Update Mesosphere docs to reflect support for newer cockroach versions

I don't know whether to include the doc in v2.0 or not - you can't
actually run unstable releases using the DC/OS package we provide, but
is it weird if we don't have the doc for it? Will we forget to add it
later? Let me know what you'd like.
The first commit is just https://github.com/cockroachdb/docs/pull/2319.

This change is

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/645a829802a0ed901af284923547532becae18d3/

You can hold off on reviewing this for now. My update got merged but I still need to verify I can install the new version from the real package manager and figure out how to specify that you want the old version for the v1.0 doc.

This is now ready for review, but not ready for merge because I managed to mess up the S3 URLs in the package definition (https://github.com/mesosphere/universe/pull/1587)

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/857f7c2f5bdf405d4d12ae54b4618a18bf1cbb13/

This is ready for both review and merge now that https://github.com/mesosphere/universe/pull/1587 is in.

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/113da465ebac38e387a971ded487dfb2a6d8b776/

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/b01da7c3791fbeeeb70b70a004d692ae6c5390c8/

The docker run command wouldn't work because it'd try to pull cockroachdb/cockroach:v2.0-alpha.20171218, which doesn't exist. That's a good catch -- I've changed all versions of the doc to use the docker_image variable you added recently.

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/33f917d04fda6095742422ee1d101312593aeaf9/

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/bd39c8ccb6f194eb85999d720141e93ae8f97e5f/

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/367efbee51a2fb71a8cea272172c13a61867e105/

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/73a5cdaf7cdb820eb3dc8f7450fd98f507ff98c8/


Can the project run under the window?

Hello, can this project run under window? how to run

Hi @ddy-ding
What do you mean by running under the window?
Anyway, please use users@ovirt org for support, not github issues.
Thanks


Adjust modulefile according to the requirements

The PR addresses the most recent changes in the modulefile.

/intelci: run

Can this be closed now that it is resolved in release branch?

we need some fix here anyway as we can't drop this internally with current state.
If there is no simple fix now we can just don't have ARM modulefiles for now

Duplicate of https://github.com/oneapi-src/oneDAL/pull/2823


Add a monitoring page for the ci status

Currently it's hard to figure out why packages fail. One can randomly look at failures but it is not efficient.
This PR adds a current web page to display which packages are not displayed on the documentation website and gives an overview of at which stage it went wrong.

I have also added a minimal example using the monitor module to test its behaviour.
warning
I needed to expose ocurrent's executor module to obtain this feature.
module Executor : sig
    val run : 'a Current.t -> 'a Output.t Current_incr.t
end

The rationale is that I don't want to maintain the monitor's state using ocurrent because it would require tracking a lot of nodes. Instead it's better to query the ocurrent state occasionally (when the page is requested) using this function.
It's done in this commit: https://github.com/TheLortex/ocurrent/commit/c9f5f9a882d02426937988dccdd7ba291185be29
@talex5 what do you think ? it's low level but would it be possible to have that somewhere in the ocurrent api ?

what do you think ? it's low level but would it be possible to have that somewhere in the ocurrent api ?

I guess we could have a Current.observe that does that.
A general purpose show-failed-nodes feature sounds useful too.
(and if the failed nodes are always cluster jobs then the Query page will find them already)


Archive channel name length bug

If an channel being archived has too long a name, it'll cause "Too long path name" errors.
Very likely simple fix by forcing image length as well as channel length to a reasonable size restriction. (And maybe some way to check for duplicate image names? If it doesnt exist)

Merging into #6


Notification Design

Currently, PowerApps solution does not have any notification set up.  We should define some events for notification.  Some in my mind

When product launch date is deferred.
When primary PM,  milestone owner of a release plan has been changed
when SDK release date is closing, say within 8 working days
when SDK launch date arrives, but SDK release plan is not complete.
When SDK release plan is complete
etc.

Besides defining notification events, we also need to define notification level, and who to notify.

there should be a central notification framework for Release Planner. bring this requirement to engineer triage

Suggestion from @ccbarragan:
For app-level error notifications, I would recommend using a message bar. This is a common thing we see in lots of Microsoft experiences. There’s a good write-up here: Message bar (coherence-portal.azurewebsites.net)
The takeaway is that we should make sure that notifications appear below the most relevant section that the user is interacting with. Because the built-in Power Apps notifications appear alllll the way to the top, far away from the area that I’m actually working in (and they disappear without giving me the option to have them persist), we will continue to get similar feedback.
Here’s an example on how this could look in Power Apps. The message bar appears at the top of the view and pushes down the main content to maintain spacing. Note that there are several different kinds of notifications that work best in different situations – we have message bars like this one, inline validation for input fields in a form, toast notifications, notifications in a side panel vs. a pop-up dialog. This page has some really great guidance we can built on.

This will be covered in https://github.com/Azure/azure-sdk-tools/issues/5631


Multilingual, closing #168

Firstly:
I'll make a draft-PR for now so we can discuss this alongside me coding...
Secondly:
Sorry, I'm kind of a newbie to git - and I might need your help with this:
Why is the commit history such a mess? I only want it to show 1c47308, as this is the only commit which differs from your master... 🙁
If you'll look in the "Network", you'll see this branch is branching of a fresh merge from your master into mine...
This fixes #168 btw.

 Then when you pull in new changes from this repo, it creates these extra merge commits. Especially when contributing to other repositories, it's generally best to work on feature branches and submit PRs from those, and keep your own master branch in sync with the upstream one. You can clean this up by:

Pulling in the master branch from upstream (this repo)# may have to add a git remote for it
git remote add upstream git@github.com:goto-bus-stop/wikibattle.git
git pull upstream

Resetting your local master branch to the upstream one (you'll have to be on another branch to do this)git branch -f master upstream/master

Force-push that to your own repo for completenessgit push origin master -f

And then you can get rid of the extra commits in this PR by rebasing your multilingual branch on your fixed master branch using
git rebase -i master

(that will open an editor with lines like pick $commithash $message, you can remove everything except the final commit which is the one specific to this branch)
and finally force-push the multilingual branch using git push origin multilingual -f.
let me know if you run into any trouble w that! :)

Tada! 🎉
Thanks a lot. 😊 I'll definitely stick to that feature branch thing. 😅

Oops, the PRs closed because I changed the default branch name … I don't think I can retarget your PRs, so if you want to pick these up again please create a new PR 🙏

Oh I thought it'd be because they've been inactive for so long. Yeah, I lately got quite busy but I didn't forget about it!
At some point I'll pick it up again. 😊


GEOMESA-960, GEOMESA 1011 Added stat iterator

Removed TemporalDensityIterator
Added Stats Iterator
Added MinMax, IteratorStackCounter, EnumeratedHistogram, and RangeHistogram statistics

Signed-off-by: Alex Tatusko<EMAIL_ADDRESS>

@Afterglow375 Looks good. I had mainly stylistic comments. I'll see if I can refactor the iterator setup a bit...

So seems like the temporal density iterator is still kind of partially around? We should probably just remove it completely...

I've rebased this, but can't push to @Afterglow375's repo, so opening new PR #816


BitMEX exchange (100x leverage)

Any plans to integrate BitMEX exchange (100x leverage) ?

Fees here are amazingly good.

Ready to pay someone who can integrate BitMEX exchange in zenbot.

@muditgrover how much?

Any updates here?
@muditgrover still interested?


azcopy using managed identity and piping does not seem to do anything

Which version of the AzCopy was used?
Note: The version is visible when running AzCopy without any argument
10.1.2
Which platform are you using? (ex: Windows, Mac, Linux)
Ubuntu
What command did you run?
Note: Please remove the SAS to avoid exposing your credentials. If you cannot remember the exact command, please retrieve it from the beginning of the log file.
(pg_dumpall -g | /usr/local/bin/azcopy cp "${BLOB}${BACKUP_MEMBER}/pgdumpallg.sql") 2>&1
What problem was encountered?
azcopy using managed identity and piping does not seem to do anything, we are using pg_dumpall to pipe to blob storage and do not want to unnecessarily write to disk first
How can we reproduce the problem in the simplest way?
azcopy login --identity
cat ~/aaa.txt | azcopy cp "https://.blob.core.windows.net/backup/aaa.txt"
Have you found a mitigation/solution?
azcopy login --identity
azcopy cp ~/aaa.txt "https://.blob.core.windows.net/backups/aaa.txt"

Possibly related to #413

Logged for investigation

Hi @JohnRusk , would it be possible to get an update on that issue?  I'm using 10.4.3 and azcopy fails to copy a file to the lake using OAuth&pipe:
export AZCOPY_SPA_CLIENT_SECRET="${CLIENT_SECRET}"
azcopy login --tenant-id ${TENANT_ID} --service-principal --application-id ${CLIENT_ID}

# The following works:
azcopy cp test https://mystorageaccount.blob.core.windows.net/data/test

# The following does NOT work:
cat test | azcopy cp https://mystorageaccount.blob.core.windows.net/data/test

# The following works using SAS, to prove the problem is isolated to OAuth&pipe and not pipe in general
azcopy logout
azcopy cp test https://mystorageaccount.blob.core.windows.net/data/test?${SAS_TOKEN}
cat test | azcopy cp https://mystorageaccount.blob.core.windows.net/data/test?${SAS_TOKEN}

We have been using SAS tokens, but we want to move to OAuth, so it would be nice to have azcopy support this use case.
Thanks for looking into this.

cccs-eric, I've handed this issue over to @zezha-msft , @adreed-msft , @nakulkar-msft  and @amishra-dev .

Any updates on this?
I am experiencing the exact same issue.  Piping with SP Login does definitly not work.
The command just returns with an exit-status of 1, but there is no error message (which makes this even harder to debug).


Add way of getting multiple mutable references from storages

Add API that allows getting multiple mutable references from a storage in a way that preserves correctness.
If we had integer generics we could provide generic API:
fn get_muts<const N: usize>(&mut self, [Entity; N]) -> Option<[&mut T; N]>;

Right now we could provide more specific instances of it.
The API should be restricted to DistinctStorages and should check that parameter indices are different.

@mjadczak May I add your source code (the roboter following the other one) here so that we have a real-world example?

Hey, I hadn't noticed your comment until now. I don't know if this is still relevant / helpful, but the relevant code is here - I have to collect up all the changes I want to apply and only then apply them.

Thanks @mjadczak! I'm still looking for a good solution here.

Commenting to keep open (presumably hasn't been solved yet)

Ditto?


Update snapshotting-freshness-for-one-source.md

I believe this is missing "source:" syntax
Description & motivation

To-do before merge

Hey @runleonarun would you be able to review this? This is my first time contributing so if I'm missing anything please let me know :)

@runleonarun good call, I just did a search and found other references which I just added. I also looked through our documentation and found that this only applies to v 0.21.0 and later according to https://docs.getdbt.com/reference/commands/source.

@jeremyholtzman Thanks for updating! Being that .20 is almost EOL I think it's OK to merge this PR without versioning the old syntax for .20.
We can add a note similar to the one on the Source page:

:::info As of dbt Core v0.21, you need to prefix sources with the source: selection method. In previous versions of dbt, sources were specified by name only. :::

@runleonarun, sure thing, I just added the note you mentioned on both pages


Connect transform dialect passes into IREE.

This revision provides a first connection between IREE and the transform dialect by
allowing the orthogonal specification of a linalg_transform file (policy) that is
parsed and applied on the fly.

@benvanik could you please comment on at least the extra dependencies ?
I had to thread dependencies on PDL and PDLInterp though a few layers and I am unclear this is the best way.
OTOH, in order to create a more contained unit test for this PR, I also had to do the same for the Bufferization dialect.
The nested pass structure make the additional changes less than ideal but maybe there is a better / more automated way to achieve the same?


Accessing repository credentials via T.env

Supported all implemented repositories: sonatype, bintray, artifactory. Now it is possible not to pass credentials directly and they will be retrieved from approptiate environment variables (SONATYPE_USERNAME, SONATYPE_PASSWORD, BINTRAY_USERNAME, BINTRAY_PASSWORD, ARTIFACTORY_USERNAME, ARTIFACTORY_PASSWORD).
Fixes https://github.com/com-lihaoyi/mill/issues/2015.
I'm not sure everything done correctly so point me if I did something wrong.

This looks reasonable to me. Having the checkSonatypeCreds method covered by some test would be nice.

Covered in mill.scalalib.HelloWorldTests.publish


[sw/silicon_creator] Import RSA assembly from sw/otbn/crypto

On top of #9422; only the last commit is part of this change. Draft until #9422 is merged. Part of #9303.
Removes the duplicate RSA-3072 OTBN assembly files from the crypto library and imports them from sw/otbn/crypto instead.
CC @alphan

Rebased on top of #9422, and updated to include the .balign directives @rswarbrick suggested there


GPU usage problem when training

When training on new corpus, I used three gpus. While training, the video memories of the cards were all occupied, but one of the video card has usage of 0% all the time. How to solve the problem?

Did you set this here: https://github.com/allenai/bilm-tf/blob/master/bin/train_elmo.py#L16 ?

Did you set this here: https://github.com/allenai/bilm-tf/blob/master/bin/train_elmo.py#L16 ?

Did you set this here: https://github.com/allenai/bilm-tf/blob/master/bin/train_elmo.py#L16 ?

You are right. I set CUDA_VISIBLE_DEVICES and forget to reset the n_gpu. Thanks~

:-)


Fix prometheus and citadel connection tests (#12747)

Cherrypicked as requested in https://github.com/istio/istio/pull/12747#issuecomment-477800936

Fix test-prometheus-connection.yaml: test never failed

Co-authored-by: Ralf Pannemans<EMAIL_ADDRESS>
Fix test-citadel-connection.yaml: test never failed

Co-authored-by: Ralf Pannemans<EMAIL_ADDRESS>

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

Needs approval from an approver in each of these files:

install/OWNERS

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

Hi @phil9909. Thanks for your PR.
I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test label.
I understand the commands that are listed here.

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

/assign @sdake

/ok-to-test

@phil9909: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-simpleTests.sh
d978655d310460b39d1be968b3c9ba15e6989888
link
/test e2e-simpleTests

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

@phil9909: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-integ-k8s-tests.sh
d978655d310460b39d1be968b3c9ba15e6989888
link
/test istio-integ-k8s-tests

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

@phil9909: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-integ-k8s-tests.sh
d978655d310460b39d1be968b3c9ba15e6989888
link
/test istio-integ-k8s-tests

prow/istio-pilot-multicluster-e2e.sh
d978655d310460b39d1be968b3c9ba15e6989888
link
/test istio-pilot-multicluster-e2e

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

/retest

/test istio-pilot-multicluster-e2e

@phil9909: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-multicluster-e2e.sh
d978655d310460b39d1be968b3c9ba15e6989888
link
/test istio-pilot-multicluster-e2e

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

@costinm @mandarjog Could you have a look at this please?

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: phil9909, sdake
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

install/OWNERS [sdake]

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

/assign @duderino

@jsPlachetka this PR is ready for merge - awaiting review by the release managers now.
Cheers
-steve

LOL I had an extremely perverse thought while reviewing this:  "if I merge this won't it be more likely to see test failures"
Must not be evil....
Merging....

@phil9909: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-multicluster-e2e.sh
d978655d310460b39d1be968b3c9ba15e6989888
link
/test istio-pilot-multicluster-e2e

prow/e2e-mixer-no_auth.sh
d978655d310460b39d1be968b3c9ba15e6989888
link
/test e2e-mixer-no_auth

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

@phil9909: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-multicluster-e2e.sh
d978655d310460b39d1be968b3c9ba15e6989888
link
/test istio-pilot-multicluster-e2e

prow/e2e-mixer-no_auth.sh
d978655d310460b39d1be968b3c9ba15e6989888
link
/test e2e-mixer-no_auth

prow/istio-unit-tests.sh
d978655d310460b39d1be968b3c9ba15e6989888
link
/test istio-unit-tests

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

@phil9909: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-mixer-no_auth.sh
d978655d310460b39d1be968b3c9ba15e6989888
link
/test e2e-mixer-no_auth

prow/istio-unit-tests.sh
d978655d310460b39d1be968b3c9ba15e6989888
link
/test istio-unit-tests

prow/istio-pilot-multicluster-e2e.sh
d978655d310460b39d1be968b3c9ba15e6989888
link
/test istio-pilot-multicluster-e2e

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


Fix metadata build error "'Runtime' object has no attribute 'candidat…

…e_brew_tag'"
Fix this error when building a operator metadata:
  File "/home/jenkins/.local/lib/python3.6/site-packages/doozerlib/operator_metadata.py", line 781, in get_all_builds
    cmd = 'brew list-tagged --quiet {} {}'.format(self.brew_tag, self.metadata_component)
  File "/home/jenkins/.local/lib/python3.6/site-packages/doozerlib/operator_metadata.py", line 793, in brew_tag
    return self.runtime.candidate_brew_tag if self.runtime.candidate_brew_tag else '{}-candidate'.format(self.operator_branch)
AttributeError: 'Runtime' object has no attribute 'candidate_brew_tag'

https://saml.buildvm.openshift.eng.bos.redhat.com:8888/job/aos-cd-builds/job/build%252Fappregistry/6196/console

Codecov Report

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

@@            Coverage Diff            @@
##             master     #227   +/-   ##
=========================================
  Coverage          ?   25.82%
=========================================
  Files             ?       26
  Lines             ?     5653
  Branches          ?     1121
=========================================
  Hits              ?     1460
  Misses            ?     4145
  Partials          ?       48

Impacted Files
Coverage Δ

doozerlib/olm/bundle.py
0.00% <0.00%> (ø)

doozerlib/operator_metadata.py
80.75% <0.00%> (ø)

doozerlib/runtime.py
27.55% <100.00%> (ø)

doozerlib/metadata.py
33.12% <0.00%> (ø)

doozerlib/brew.py
47.72% <0.00%> (ø)

doozerlib/dotconfig.py
0.00% <0.00%> (ø)

doozerlib/source_modifications.py
68.29% <0.00%> (ø)

doozerlib/rpmcfg.py
12.09% <0.00%> (ø)

doozerlib/gitdata.py
18.51% <0.00%> (ø)

doozerlib/cli/__main__.py
0.00% <0.00%> (ø)

... and 19 more

Continue to review full report at Codecov.

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

/lgtm


Preview changes to layouts

This is a tracking issue for updating Whim to use immutable ILayoutEngines. Each child issue of this issue from Stage 1 will be merged into the branch for this. Upon completion of the initial implementation, the branch will be merged into main (not a squash merge, so that the history is preserved).
Initial Implementation

[x] #426
[x] #436
[x] #439
[x] #430
[x] #432
[x] #435
[x] #448
[x] #450
[x] #452
[x] #429

Follow-on Features

[x] #454
[x] #458
[x] Split tree nodes in any direction, when dragging windows (done in #439)

Finally completed in #434


error during add domain

Hi, I followed your quickstart example and from the line,
shaman add -d nanopack.io -A <IP_ADDRESS>
I got this error.
Could not contact shaman - Post https://<IP_ADDRESS>:1632/records: x509: cannot validate certificate for <IP_ADDRESS> because it doesn't contain any IP SANs

And the server says
2018/03/11 10:27:48 http: TLS handshake error from <IP_ADDRESS>:40514: remote error: tls: bad certificate
2018/03/11 10:27:48 http: TLS handshake error from <IP_ADDRESS>:40516: tls: oversized record received with length 21536

Do I missing something? Thanks.

Try adding -i
On Mar 10, 2018 6:38 PM, "kim yongbin"<EMAIL_ADDRESS>wrote:

Hi, I followed your quickstart example and from the line,
shaman add -d nanopack.io -A <IP_ADDRESS>
I got this error.
Could not contact shaman - Post https://<IP_ADDRESS>:1632/records: x509: cannot validate certificate for <IP_ADDRESS> because it doesn't contain any IP SANs
And the server says
2018/03/11 10:27:48 http: TLS handshake error from <IP_ADDRESS>:40514: remote error: tls: bad certificate
2018/03/11 10:27:48 http: TLS handshake error from <IP_ADDRESS>:40516: tls: oversized record received with length 21536
Do I missing something? Thanks.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/nanopack/shaman/issues/32, or mute the thread
https://github.com/notifications/unsubscribe-auth/ACh7tdZ_LafvO_bIKF2g5ZC_sXnOEyJvks5tdIAQgaJpZM4SlhQT
.

Thanks, it works.


Change proxy localhost to I<IP_ADDRESS> for windows

Node on windows has issue which effects proxy to localhost when there is no internet. #1116
Added a check for windows host and changed localhost to <IP_ADDRESS> as discussed.

Confirmed working https://github.com/facebookincubator/create-react-app/issues/1116#issuecomment-265429586.
Can you please test this, @vikasaditya?

@FrankenSteinxD can you please test this exact approach? I currently don't have a Windows machine to test on.

@Timer @bunshar
It worked fine, but I should mention that I've changed my windows version.
In that last version it was working fine until I un/installed something, since that it didn't work with localhost, and now I am currently on new version, tried with and without changes and works fine with localhost :\

No. Please, fix your OS or configure your app correctly. localhost can be mapped to IPv4 <IP_ADDRESS> or IPv6 ::1.
You are throwing IPv6 away here.

@langpavel if this is true, can you please write a relevant documentation entry for this and submit a PR please? 😄 We can then see if it fixes it for others.

Ok @Timer my apologies

Thank you!
I will be looking forward to that documentation pull request if you're up to it. 😄

Let's actually follow suit with chromium. We want it to resolve to the correct address (IPv4 or 6).

@Timer I looked st the chromium file you linked. What exactly are we looking at? A little pointer will be great help.

On Windows, DNS lookup happens without flags (per Chromium's reasoning). Let's DNS.lookup localhost with the flags set to 0 and replace it with that instead of <IP_ADDRESS>.

@Timer  I checked and the tests fail have nothing to do with the current code. Can someone help me to understand what's to be done to make these pass

Travis looks fine to me, it was just a Jest bug.
I'll have more time to take a closer look at this (and other issues) this coming weekend.

This is great, @bunshar! Thanks for all your hard work.
I went ahead and cleaned a few things up, but 100% based on your solution. 😄

It is a bit unfortunate that so much "systems" code would now become part of user's ejected setup. We should really find a way to move some parts into react-dev-utils.

Great point. We should probably do that before we release this.

Best to do it on top of https://github.com/facebookincubator/create-react-app/pull/1790 since it's changing the same parts again.


Some quote embeds aren't displaying in logged out view until you click the post

Describe the bug
Opening this feed in the logged out view: https://bsky.app/profile/did:plc:oio4hkxaop4ao4wz2pp3f4cr/feed/aaag2mdct6ntq
There are some posts that quote some other post with just the text "👀", but they're displaying as just a "👀" without any quote embed. If you click on the post, then the quote is shown.
To Reproduce
Steps to reproduce the behavior:
Open the feed in the logged out view: https://bsky.app/profile/did:plc:oio4hkxaop4ao4wz2pp3f4cr/feed/aaag2mdct6ntq and scroll down.
Screenshots
In the feed:
Details:
In the feed:
Details:
Details

Platform: Webkit (Orion), macOS Monterey

I'm able to reproduce this in Safari on iPadOS.
Also, looking at which embeds show up in that feed and which don't, it seems like the ones that show up are embeds of small to medium size (in terms of number of lines) rather than the larger ones? Maybe that has something to do with it? 🤔

I was thinking it were the ones where the quote text was literally one emoji, although I haven't spent much time analysing this (since like I mentioned it was 3 am ;)

I was thinking it were the ones where the quote text was literally one emoji, although I haven't spent much time analysing this (since like I mentioned it was 3 am ;)

That's a good working theory for 3am 😅
That might be part of the issue, but I think it might be wider than that. Because these two embeds don't show up, which aren't a single emoji:

and this embed does show up, even though it's just a single emoji:

Ah, ok, so not that

It seems like this also affects Discover:
https://bsky.app/profile/surfdude29.ispost.ing/post/3l2bfdyz7l52f

This seems fixed, presumably by #5329, and I can now see the embeds for all the examples here in the feed on main.bsky.dev.