[BUG] - "required" prop does not get passed to input element

NextUI Version
2.0.16
Describe the bug
Hi there!
I'm running into some weird behaviour with the "Input" component. When I pass required={true} to the component, the input element itself does not obtain the property.
Your Example Website or App
No response
Steps to Reproduce the Bug or Issue

Import the "Input" component from @nextui-org/input
Create a component in your code and specify the required={true} prop
Check your dev tools tab

Expected behavior
Expected behaviour: The required property gets added to the <input> element and prevents a form from being submitted when empty/invalid.
Actual behaviour: The property does not get added and a form with this component can be submitted even when the input is emptry/invalid.
Screenshots or Videos

Operating System Version

OS: Windows

Browser
Chrome

Hey @codedotspirit you have to use isRequired prop https://nextui.org/docs/components/input#required


Use a fork channel for Counter and Lock protocols

We shouldn't add protocols to the JGroups stack used by Infinispan.
Instead, we should use a ForkChannel,
so that counter and lock message do not interfere with Infinispan messages.

The PR should go to upstream project


Add script for copying resource

This is helper script which allow to copy resources between two clusters.
I've developed it as a help tool for side-by-side deployment of Openshift (where user has to manually copy CA secret abd csr signer configMap)

recheck ha


Updated lots of links

Issue #, if available: None
Description of changes:  Some minor stuff in readme, most importantly added a link to the website. Also changed all links to relative in the index notebook.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Codecov Report

Merging #136 into develop will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           develop     #136   +/-   ##
========================================
  Coverage    84.29%   84.29%
========================================
  Files           90       90
  Lines         2363     2363
  Branches       231      231
========================================
  Hits          1992     1992
  Misses         327      327
  Partials        44       44

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 c4a238f...fbc0199. Read the comment docs.

Codecov Report

Merging #136 into develop will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           develop     #136   +/-   ##
========================================
  Coverage    84.29%   84.29%
========================================
  Files           90       90
  Lines         2363     2363
  Branches       231      231
========================================
  Hits          1992     1992
  Misses         327      327
  Partials        44       44

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 c4a238f...fbc0199. Read the comment docs.

In the README.md there is still '[coming soon]' for BQ. Could you also delete that in this PR?
I clicked on some links in the index notebook and I can not open them in a new tab which is a bit annoying. Is that related to the relative links?

Good catch on the note about BQ, removed.
Relative links shouldn't behave any different to absolute ones in this regard. Also, when browsing on GitHub, say here, if I open a link it loads in the same tab.

@mmahsereci spotted an issue: when you "open in a new tab" a link from the index notebook while browsing in github, that gives an error. As a compromise we agreed to give link nbviewer website in README. So this issue will still be there in github, but only if you browse sources. If you, on the other hand, just follow link in README, notebook navigation will work


Start MakeCode Simulator command should only appear in editor context menu if in a MakeCode project

Install MakeCode extension
Open microsoft/vscode repo
Open a TS file and right click to open context menu
:bug: see Start MakeCode Simulator in context menu

I would also suggest putting this command in a different group as currently it is grouped with unrelated go to definition actions. If there's only one MakeCode command it may make sense to group it with the other run/debug actions in the debug group, otherwise it could go into a dedicated MakeCode group.

Thanks for the suggestion! I added these changes into https://github.com/microsoft/vscode-makecode/pull/150


required readOnly fields are required in request body when they shouldn't be

Description
When an API object has a field that is required but has readOnly: true, a request containing an object without that field fails to validate.
OpenAPI spec says:

You can use the readOnly and writeOnly keywords to mark specific properties as read-only or write-only. This is useful, for example, when GET returns more properties than used in POST – you can use the same schema in both GET and POST and mark the extra properties as readOnly. readOnly properties are included in responses but not in requests, [...]

If a readOnly or writeOnly property is included in the required list, required affects just the relevant scope – responses only or requests only. That is, read-only required properties apply to responses only, [...]

This is a regression from Connexion 2.x.
Expected behaviour
Object validates successfully.
Actual behaviour
Object fails to validate, because it is missing a read-only field:
ERROR:connexion.validators.json:Validation error: 'objectId' is a required property
ERROR:connexion.middleware.exceptions:BadRequestProblem(status_code=400, detail="'objectId' is a required property")

Presumably Connexion 3.x fails to use jsonschema validation properly here.
Steps to reproduce

Use the openapi.yaml and testcontroller.py from below
Start with connexion run openapi.yaml --stub
Attempt to do the following request: PUT .../objects/45d2847a-ed55-440a-bfa7-5e759d0d671f, with body

{
    "name": "abc"
}

Minimal example:
openapi.yaml
openapi: 3.0.3
info:
  title: test
  version: '1.0'
paths:
  '/objects/{objectId}':
    parameters:
      - schema:
          type: string
          format: uuid
        name: objectId
        in: path
        required: true
    put:
      summary: Create or update object
      operationId: object_put
      x-openapi-router-controller: testcontroller
      responses:
        '200':
          description: OK - Object updated
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Object'
      requestBody:
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/Object'
components:
  schemas:
    Object:
      title: BaseObject
      type: object
      properties:
        objectId:
          type: string
          format: uuid
          readOnly: true
        name:
          type: string
      required:
      - objectId
      - name

testcontroller.py
from connexion import FlaskApp, request

app = FlaskApp(__name__)

def object_put(objectId, body):
    return {"objectId": objectId, **body}

app.add_api("openapi.yaml")

Additional info:
Output of the commands:

python --version

Python 3.11.3

pip show connexion | grep "^Version\:"

Version: 3.0.6

Thanks for the report @sampoh0523.
Seems like we need to reinclude this validator. Do you mind submitting a PR for this?

@RobbeSneyders I'm surprised people are able to use connexion 3 without this working correctly. Opened a PR to fix this issue.


Make sure GetDeviceByID when data doesnt exist yet on our database

Description
Make sure GetDeviceByID when data doesnt exist yet on our database
Fixes # (issue)
Type of change
What is it?

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Documentation update
[ ] Tests update
[x] Refactor

Checklist:

[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] I run go fmt ./... to check that my code is properly formatted
[x] I run go vet ./... to check that my code is free of common Go style mistakes

Codecov Report

Merging #526 (6fd74ce) into main (0a3836d) will decrease coverage by 0.63%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main     #526      +/-   ##
==========================================
- Coverage   31.83%   31.19%   -0.64%
==========================================
  Files          33       33
  Lines        3229     3295      +66
==========================================
  Hits         1028     1028
- Misses       2093     2159      +66
  Partials      108      108

Impacted Files
Coverage Δ

pkg/routes/devices.go
29.90% <0.00%> (-0.57%)
:arrow_down:

pkg/services/devices.go
60.14% <ø> (ø)

pkg/routes/updates.go
5.13% <0.00%> (-1.43%)
:arrow_down:

pkg/clients/imagebuilder/client.go
33.94% <0.00%> (-0.16%)
:arrow_down:

pkg/services/repobuilder.go
2.87% <0.00%> (-0.10%)
:arrow_down:

pkg/services/images.go
13.66% <0.00%> (ø)

pkg/services/commits.go
0.00% <0.00%> (ø)

Continue to review full report at Codecov.

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


change run deletion (session/synchronize)

use separate sessions for each run deletion
wich the synchronize_session=False deletion can be speed up
because we do not need the runs in the session anymore,
just cleaning up everything

What is the reason to use separate sessions? I am not against it, just curious.

@Xazax-hun I prefer to do the database modification in smaller chunks instead of building one big session with a lot of modifications.
Closing the session after each delete will release transaction and connection resources, it might increase the performance but I did not measure that separately (less states to manage in the session, database can cleanup transaction related data).
However performance improvement is done with the usage of the synchronize_session=False flag which we can use here because we do not need the data in the session anymore.

Having a separate transaction for each delete is definitely a good idea. But I wonder if reconnecting for each delete is good. But I am fine with that.


Pouchdb client usage

First off, this really looks like a great solution and the first library I have seen to support all thèse features. Nice job!
Do you have an idea how this could work with pouchdb in the browser? Maybe as a better replacement to pouchdb-authentication?

The difference between SuperLogin and pouchdb-authentication, is that SuperLogin creates sessions with throw-away credentials so you have more control. When you log out of the session, those credentials no longer work. It also coordinates those credentials across multiple databases that you have permissions for.
I am finishing up a demo app that shows exactly how to coordinate the SuperLogin server with PouchDB in the browser. After you login, the session information returned contains a field called userDBs. Simply pass the URLs provided into the PouchDB constructor.

@colinskow Thanks, sounds awesome!

The SuperLogin Demo is now LIVE! Source code here.


Work on the Hero section of the view event page

https://www.figma.com/design/w1Hoj9ESFonR8tDl5WLedU/Event-Management?node-id=0-1&node-type=canvas&t=I68O6UxtKMLgmDE4-0

I'll start working on this ASAP.

@Jaybee-1 Thank you for picking this up. You're assigned already

@Jaybee-1 any update on this please?


Upgrade golang.org/x/net-v0.4.0 to 0.7.0

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
Please see https://github.com/advisories/GHSA-vvpx-j8f3-3w6h - need to update dependancy in question.
Expected Behavior
This should help pass vulnerability scan.
Steps To Reproduce
Scan with Anchore CVE

Kong Ingress Controller version
2.8.1

Kubernetes version
NA

Anything else?
No response

Thanks for the report! Given that 2.9 is bound to happen in relatively near term future, the fact that we don't tend to release patch releases and that it's fixed on main I'm inclined to close this.
Is there a real concern there or just a scan result?
Also given that
go mod why -m golang.org/x/net
# golang.org/x/net
github.com/kong/kubernetes-ingress-controller/v2/internal/manager
k8s.io/client-go/rest
golang.org/x/net/http2

and the only thing that's being used from k8s.io/client-go/rest package in github.com/kong/kubernetes-ingress-controller/v2/internal/manager is *rest.Config, it doesn't look like a real concern to me.

Many thanks.  There is no concern for this to wait until 2.9.


feat(vs): do a better job at setting up the correct route

fixes #153
This requires some update to the API between Locators and Mutator/Revertors as Subset is missing.

As for e2e_test failure - it seems telepresence package is not reachable...
E: Unable to locate package telepresence

We might want to think about the fallback plan to avoid such roadblocks.

We might want to think about the fallback plan to avoid such roadblocks.

Package cache?

I just wonder what do we benefit having funcs defined in the mutateVirtualService vs making them entities on their own. They seem not to rely on any struct passed to "owning func".

That was primarily done  for two reasons:

to make the changes clear 'at the bottom of the method' as opposed to a long bunch of loops etc
and kept in inside the func to indicate they are not intended to be reusable and not to "polute" the namespace.

We might want to think about the fallback plan to avoid such roadblocks.

Package cache?

Opened an issue for that one #201


Making svgo compatible with webpack web bundling.

I'm currently creating a pure client side website which tries to use svgo.
When bundling my project using webpack, I kept receiving the following error:
"Module not found: Error: Can't resolve 'fs'".
After some googling and learning, I realised bundling node.js code and web code, requires 2 different bundles. However, that didn't help me much as my website is entirely client side.
So I inspected svgo's source and I realised only very minor changes (a re-shifting of 'fs' dependencies) have to be made.
How/
The only uses of 'fs' that we care about occur in config.js and tools.js.
As coa.js will never be called.

In tools.js the use of 'fs' can be removed, as the only use for the function checkIsDir is in coa.js. We also remove the function checkIsDir and add it to coa.js.
In config.js, we can remove the use of 'fs', by .svg.yml, by creating a new file list-config.js.
This file exports an object storing the plugins.

Now svgo remains a fully working node.js application, whilst also being friendly for web bundling.
This fork contains my minimal changes, which have been tested and work. (I do realise a lot of code could be pruned).
https://github.com/trozler/svgo
Disclaimer, this is the first time I'm contributing to some open source. So I apologies if I'm going about this the wrong way somehow.  I do realise this may not even be classed as an issue as svgo is a node.js application after all.
Nevertheless, maybe someone will find this code useful at some point.
Best,
Tony

@trozler: Also, how could SVGO process a SVG file in webpack, emit the resources inside, like inlined images for optimization by e.g. imagemin, and then assemble everything back? Can webpack do such things?

@strarsis You can inline svg files in your bundle quite easily using webpack. For example, using loaders such as "svg-url-loader" or if you want to use svgo to optimise the image and then inline you can use the svgo-loader.
Check out this link for how to inline images using webpack. Personally I don't use these loaders, as I prefer to optimise the image myself using the svgo CLI or svgomg.
So yes, loaders in webapck can be used to optimise your static SVG files and inline them in your bundle. However, these loaders are no help when you have to dynamically optimise svgs. For example, when you are dealing with user generated content.
In that case you would have to use the svgo library yourself, which is the issue at hand.

@trozler: Right, what I mean is that webpack can extract resources inside the SVG file for further processing (like optimization).
Embedded/inline images in the SVG can be extracted and made external images, or optimized and re-embedded.

"webpack can extract resources inside the SVG file for further processing (like optimization)."
As mentioned before this is done using webpack loaders. For example, the svgo loader which looks for .svg files in your project and performs svgo optimisations. These files are then embedded in your bundle (.js) and the images can be inlined using simple javascript.
"Embedded/inline images in the SVG can be extracted and made external images, or optimized and re-embedded."
Inline images in the SVG? Do you mean we have a .svg file, and it has two or more <svg>  images within it? By inlining I usually think of putting an image between some <svg> tags in a html document, either directly referencing the image in my workspace or referencing a base64/utf-8 encoded string.
If this is the case, then you could use the aforementioned svgo-loader to optimise the image. I'm not sure about "extracting and making external images", if by that you mean dividing a single .svg file into many .svg files. In theory this could be done through a loader, but I'm not sure it makes much sense as it seems unnecessary. Could just write a short script, to filter out the <svg> tags yourself, before adding the images to your project.

@trozler: SVGs can contain raster images (like PNGs), this often happens when exporting a SVG from a vector format/program (like Illustrator) that supports more features than the currently supported SVG standard or what the exporter can manage.
In that case it can be really useful to extract all those raster images and make them external images of the SVG file,
so they can be reused and further optimized.

@strarsis Ohh I understand now. Yeh don't think there currently is a loader for that use case, would have to write your own.
But yes you could use the svgo-loader to optimise these images, and it should behave the same way the svgo CLI does.

Added browser-compatible es module in svgo/dist/svgo.browser.js in v2.


Search does not seem to work with Jekyll 3.0.0

When using the search page, a search.son document is requested, which does not seem to get generated, as the server returns a 404 error and the document does exist in the generated tree (nor somewhere else).
Maybe this is my fault, since I do not have taken any additional steps to create it.

Hi @mwmahlberg , thanks for pointing it out. I missed out a whole file named search.json. I have added the template in the latest commit! This should solve the problem :)

Put the file into the wrong directory. Send pull request #42 to fix this and another minor issue with backwards compatibility


Create AYS template for etcd cluster

Goal:
Beeing able to deploy a cluster of etcd on top of zero-os
Requirements:
Cluster size can be 1, 3 or 5.

Is the etcd cluster like the storage cluster but with etcd instead of ardb?

Not really,  etcd is a distributed key-value store not like ardb.
So in order to create a cluster of etcd you have to give the address of the other instance when starting an etcd.
See for more detail : https://github.com/coreos/etcd/blob/master/Documentation/op-guide/clustering.md#static

For cluster size, will the size be derived based on the number of nodes found or it should be specified through the blueprint?

I add an initial implementation for the etcd_cluster service and he approach taken in it is

Like storage_cluster nodes should be passed through blueprint to the etcd_cluster service
Deployment of one etcd server per node. Therefore, size < #nodes is not allowed
If #nodes is larger than the size, random sample of nodes would be chosen and etcd servers would be deployed to those nodes.

Like storage_cluster nodes should be passed through blueprint to the etcd_cluster service

perfect

Deployment of one etcd server per node. Therefore, size < #nodes is not allowed

Make sure you only allow odd number of node in the cluste, otherwise cluster can't take decision


ENH: update package version

Hi! This is the friendly automated conda-forge-webservice.
I've started a version update as instructed in #41.
I'm currently searching for new versions and will update this PR shortly if I find one! Thank you for waiting!
Fixes #41

@conda-forge-admin, please restart ci


Feat: Add caching support for dependencies

Why do we need this change?
When running across multiple projects with github actions, the current behaviors are downloading the plugins each time for each project. This pr adds in a behavior to add a caching directory for the terraform and opentofu related behaviors. This should result in a improvement where multiple projects have the same dependency. Between run's as well we'll restore a cache and should prevent the needs to download again across multiple behaviors.
There's a few catches in this initial mvp pr. There's no cleanup of old version of plugins from the cache so it can grow. Multiple executions could fail to write to the cache if they result in the same hash, but as potential issues come up we can address them separately
This work is based on request in #811
What effects does this change have?

Creates a cache dir
Adds in support for creating and restoring caches using action/cache
Sets environment variables for digger's execution to pass to the terraform/opentofu setup to leverage the single cache dir for all plugin needs.

We have an issue with our other PR event listerns I need to fix, going to close and re-open the PR to trigger rest of tests

So my initial basic test in this repo was not successful: https://github.com/motatoes/test-digger-caching
The first job managed to save the cache successfully. However the subsequent job failed to save the cache with already exists error: https://github.com/motatoes/test-digger-caching/actions/runs/8789860900/job/24120563671
I wonder if we are missing a flag to override the cache?


ci: add codeql for code analysis

Codecov Report

Merging #299 (c7ad021) into master (f8945c5) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #299   +/-   ##
=======================================
  Coverage   44.86%   44.86%
=======================================
  Files          50       50
  Lines        3040     3040
  Branches      531      531
=======================================
  Hits         1364     1364
  Misses       1499     1499
  Partials      177      177

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 f8945c5...c7ad021. Read the comment docs.


⚠ TL-dev has degraded performance

In 9c9fed0, TL-dev (https://devtl-gcp.fahorro.com/) experienced degraded performance:

HTTP code: 504
Response time: 28260 ms

Resolved: TL-dev performance has improved in 0c71f3d.


Remove IEvent and IAggregate interface to prevent tight coupling

Issue #270

It's in w/ a rebase and some little fixes on top of it.


menu page inserted

#16  issue 16 resolved , created a decent menu page with hover effects to resolve the error page loading issue
@khushi-joshi-05  please review and merge it its been done since 4 days already

@kairveeehh a menu page is already there

@kairveeehh a menu page is already there

@khushi-joshi-05 but it was assigned to me by you only

@kairveeehh a menu page is already there

@khushi-joshi-05 but it was assigned to me by you only

And also I have done the work 4 days before itself

@kairveeehh a menu page is already there

@khushi-joshi-05 but it was assigned to me by you only

And also I have done the work 4 days before itself

@khushi-joshi-05  what should I do now??

@kairveeehh can u attach the screenshot of menu page created by you.
Menu page was already there but it wasn't linked.

@khushi-joshi-05  here it is , I had worked on it 3 day before and my PR was also raised but the later ones got merged first so..

@kairveeehh it is really nice. can u just update its navbar and starting part like this
And also link the add to cart and price section to javascript. Go through the existing files and in the about section a link is also attested, so you can check the working . If you can make these changes then surely i will merge it. Make sure it is working.

@khushi-joshi-05  ok I will try my best to achieve it

@khushi-joshi-05  can u please label the PR as according to the announcements it is necessary

@khushi-joshi-05 can you please attach labels , it wont be counted elsewise , please do it
@khushi-joshi-05


Fix StartPartitionSessionSettings.Builder methods return value, add comments

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

Comparison is base (e07f483) 51.90% compared to head (45907c2) 51.90%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             develop     #190   +/-   ##
==========================================
  Coverage      51.90%   51.90%
  Complexity      1139     1139
==========================================
  Files            179      179
  Lines           7233     7233
  Branches         723      723
==========================================
  Hits            3754     3754
  Misses          3213     3213
  Partials         266      266

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


Embed rust example not working.

When compiling trying to run the example https://github.com/bytecodealliance/wasmtime/blob/master/docs/embed-rust.md it fails with the attached error message. It seems the API has changed since the documentation was written. I am using 0.11.0. Can anyone verify this?
   Compiling wasmtime_hello v0.1.0 (/Users/gustaveiman/rust_projects/wasmtime_hello)
error[E0061]: this function takes 2 parameters but 3 parameters were supplied
  --> src/main.rs:10:20
   |
10 |     let instance = Instance::new(&store, &module, &[]).expect("wasm instance");
   |                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected 2 parameters

error[E0599]: no method named `find_export_by_name` found for type `wasmtime::instance::Instance` in the current scope
  --> src/main.rs:12:27
   |
12 |     let answer = instance.find_export_by_name("answer").expect("answer").func().expect("function");
   |                           ^^^^^^^^^^^^^^^^^^^ method not found in `wasmtime::instance::Instance`

error: aborting due to 2 previous errors

Some errors have detailed explanations: E0061, E0599.
For more information about an error, try `rustc --explain E0061`.
error: could not compile `wasmtime_hello`.

To learn more, run the command again with --verbose.```

I created a pr for  a propsed solution. https://github.com/bytecodealliance/wasmtime/pull/968

We should really find a way to automatically test the example, rather than manually noticing when it gets out of date.

I believe this has since been fixed, so closing


has no respond to delegate method when I tapped empty data set view

has no respond to delegate method (- (void)emptyDataSet:(UIScrollView *)scrollView didTapView:(UIView *)view) when I tapped empty data set view,whene I add  "hitView isEqual:self]" in method( - (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event) , it is OK.

(UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event
{
UIView *hitView = [super hitTest:point withEvent:event];
// Return any UIControl instance such as buttons, segmented controls, switches, etc.
if ([hitView isKindOfClass:[UIControl class]]) {
return hitView;
}
// Return either the contentView or customView
if ([hitView isEqual:self] || [hitView isEqual:_contentView] || [hitView isEqual:_customView]) {
return hitView;
}
return nil;
}

can you update a new version to fix this bug?


Implement IHttpRequestFeature.RawTarget.

aspnet/HttpAbstractions#596
Needs https://github.com/aspnet/HttpAbstractions/pull/639 to be merged to work.
cc @halter73 @mikeharder @Tratcher @davidfowl

:+1:

Added test for paths not starting with '/'.

Checked in some unintended changes, reverting.

Updated with a small perf detail.

Squirrel?

:bell: I'd like to merge this tonight.

Would it be so bad to merge tomorrow? The build's broken.

Squashed.

This make only the second usage of FunctionalTests.TestConnection. I want to remove that class, so can we please not use it?

@halter73 Removed TestConnection (the FunctionalTests one).

:bell:

:shipit:


Refactor to fix #20

Refactor to fix #20 issue

better aproche next PR and unnintended extra commit


[TF2.0] Error Logging for GradientTape

Hello everyone,
I was wondering if there is an option for error logging / or could we have tf output error message for gradient calculation. In the example below, the below will output None values in the current setting but will output correct gradients when the tf.Variables are a float type. My question is, could we please add an error message stating something like gradient calculation supports only float types?
Best Regards,
Seung-jae Bang
def forward(a, b):
    """f = a * b"""
    return a * b

params = [tf.Variable(1), tf.Variable(2)]

with tf.GradientTape() as tape:
    result = forward(*params)

tape.gradient(result, params)

System information

Linux
TensorFlow installed from pip install -U tf-nightly-2.0-preview - "2.0.0-dev20190226"
Python version: 3.6

ccing: @random-forests

I'd love to approve a PR adding this test. Feel like giving it a shot?

I would be happy to give it a shot - I haven't contributed to TF before, would you have any pointers?
Also, would tensorflow/python/eager/backprop.py be the right place to make this change?
cc: @random-forests

Yes, the change would be to add some logging to that particular file.
If you need any more pointers, happy to help.
On Mon, Mar 4, 2019 at 5:58 PM lazysjb<EMAIL_ADDRESS>wrote:

I would be happy to give it a shot - I haven't contributed to TF before,
would you have any pointers?
Also, would tensorflow/python/eager/backprop.py be the right place to make
this change?
cc: @random-forests https://github.com/random-forests
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/tensorflow/tensorflow/issues/26143#issuecomment-469502963,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAATxdlUmDjQehdKpLmQuotUBd4yku7iks5vTc9VgaJpZM4bTIcM
.

--

Alex

i would also like to contribute can you please help me where i can add logging in backprop.py

You probably want to add the warning in tape.watch here https://github.com/tensorflow/tensorflow/blob/d280d3d9b951063bf9e02ac79e248d729d33a29c/tensorflow/python/eager/backprop.py#L804 and tape.gradient here https://github.com/tensorflow/tensorflow/blob/d280d3d9b951063bf9e02ac79e248d729d33a29c/tensorflow/python/eager/backprop.py#L890

Hi,
I wish to start contributing to TensorFlow and hence would like to know if someone is already working on this issue.

@achalagarwal I think @shashvatshahi1998 is already working on this. @shashvatshahi1998 can you confirm?

Ya I am working on that, but anyone else who is interested can start working.

Hey, This would be my first contribution to tf and i would like to know whether this issue is open and if anybody is contributing to this.

Closing this out since I understand it to be resolved by the PR. I have checked the code which output warning as expected. Thanks!


Contact Form - Thank You Page

When someone contacts me, the thank you page still has the original text, in addition to the thank you information. I would like for the page to only display the thank you information, because it's confusing.
Here is the screenshot:

@marisamorby This is done. I created a new page, and edited the form to send people to that page rather than displaying a message. You can edit this if you want through the dashboard.


Mm 37816

Summary
Update the images for feature discover as per the design doc. In the doc, the current images are shown above, and the corresponding updated images are seen below.
Ticket Link
https://mattermost.atlassian.net/browse/MM-37816
Related Pull Requests
None
Screenshots
AD/LDAP:

SAML 2.0:

OpenID Connect:

Groups:

Data Retention:

Compliance Export:

System Roles:

Channels:

Custom Terms of Service:

Announcement Banner:

Guest Access:

Release Note
Update feature discovery images.

Hello @neallred,
Thanks for your pull request! A Core Committer will review your pull request soon. For code contributions, you can learn more about the review process here.

Cherry pick is scheduled.

Error trying doing the automated Cherry picking. Please do this manually
+++ Updating remotes...
Fetching upstream
Failed to add the RSA host key for IP address '<IP_ADDRESS>' to the list of known hosts (/app/.ssh/known_hosts).
From github.com:mattermost/mattermost-webapp
   3a04ce49e..891dadbf2  MM-32342_remove-legacy-sidebar -> upstream/MM-32342_remove-legacy-sidebar
 * [new branch]          MM-33930-apps-modal-loading-indicator -> upstream/MM-33930-apps-modal-loading-indicator
 * [new branch]          MM-34899-fix-dark-theme-in-purchase-modal -> upstream/MM-34899-fix-dark-theme-in-purchase-modal
 * [new branch]          MM-37021_separate-channel-unreads -> upstream/MM-37021_separate-channel-unreads
 * [new branch]          MM-37159_tips-next-steps-imagery-updates -> upstream/MM-37159_tips-next-steps-imagery-updates
 * [new branch]          MM-37351-split-settings -> upstream/MM-37351-split-settings
 * [new branch]          MM-37472_product_switcher_tip-e2e -> upstream/MM-37472_product_switcher_tip-e2e
   21f8dd531..e48cb936a  MM-37473_settings-tip  -> upstream/MM-37473_settings-tip
 * [new branch]          MM-37657-migrate-cloud-purchase-screens-to-new-branding -> upstream/MM-37657-migrate-cloud-purchase-screens-to-new-branding
 * [new branch]          MM-37682               -> upstream/MM-37682
 * [new branch]          MM-37725               -> upstream/MM-37725
 * [new branch]          MM-37726               -> upstream/MM-37726
 * [new branch]          MM-37862_product-registration-update -> upstream/MM-37862_product-registration-update
 * [new branch]          MM-37932               -> upstream/MM-37932
 * [new branch]          MM-37956               -> upstream/MM-37956
 * [new branch]          MM-37961-update-invite-members-image-to-new-branding -> upstream/MM-37961-update-invite-members-image-to-new-branding
   a857a814c..100c7bb1c  ParserOnProp           -> upstream/ParserOnProp
 * [new branch]          Update-in-product-conversation-strings -> upstream/Update-in-product-conversation-strings
 * [new branch]          add-websockets-to-products -> upstream/add-websockets-to-products
 + ea1c43d20...1dafb6429 amyblais-patch-1       -> upstream/amyblais-patch-1  (forced update)
   d5493f50d..841a03e6e  apps-form-clear-select -> upstream/apps-form-clear-select
 * [new branch]          bugfix/MM-37784_integration-takes-up-full-view -> upstream/bugfix/MM-37784_integration-takes-up-full-view
 * [new branch]          bugfix/MM-37829        -> upstream/bugfix/MM-37829
 * [new branch]          bugfix/MM-37916_close-proiduct-switcher-on-click -> upstream/bugfix/MM-37916_close-proiduct-switcher-on-click
   a6af7633b..dc0a9450b  cert-auth-check        -> upstream/cert-auth-check
   e85b4b216..9d463da42  cloud                  -> upstream/cloud
 * [new branch]          cloud-2021-08-16       -> upstream/cloud-2021-08-16
 * [new branch]          feature/MM-37363-hide-integration-and-marketplace -> upstream/feature/MM-37363-hide-integration-and-marketplace
 * [new branch]          feature/MM-37600       -> upstream/feature/MM-37600
 * [new branch]          feature/MM-37821_remove-global-header-option -> upstream/feature/MM-37821_remove-global-header-option
   4faf03a86..66f296580  master                 -> upstream/master
 * [new branch]          polish-global-header   -> upstream/polish-global-header
   949bafc5a..b479e0b33  release-5.38           -> upstream/release-5.38
 * [new tag]             cloud-2021-08-12-1     -> cloud-2021-08-12-1
 * [new tag]             v5.38.0                -> v5.38.0
Fetching origin
Failed to add the RSA host key for IP address '<IP_ADDRESS>' to the list of known hosts (/app/.ssh/known_hosts).
+++ Updating remotes done...
+++ Creating local branch automated-cherry-pick-of-mattermost-webapp-#8579-upstream-release-6.0-1629214056
Switched to a new branch 'automated-cherry-pick-of-mattermost-webapp-#8579-upstream-release-6.0-1629214056'
Branch 'automated-cherry-pick-of-mattermost-webapp-#8579-upstream-release-6.0-1629214056' set up to track remote branch 'release-6.0' from 'upstream'.

+++ About to attempt cherry pick of PR #8579 with merge commit 66f296580b3e9fea474b6db3d7e25e1b073fd553.

[automated-cherry-pick-of-mattermost-webapp-#8579-upstream-release-6.0-1629214056 86bbe8e42] Mm 37816 (#8579)
 Author: Nathaniel Allred<EMAIL_ADDRESS> Date: Tue Aug 17 10:27:32 2021 -0500
 11 files changed, 4086 insertions(+), 2911 deletions(-)
 rewrite components/admin_console/feature_discovery/features/images/announcement_banner_svg.tsx (92%)
 rewrite components/admin_console/feature_discovery/features/images/channels_svg.tsx (96%)
 rewrite components/admin_console/feature_discovery/features/images/compliance_export_svg.tsx (90%)
 rewrite components/admin_console/feature_discovery/features/images/custom_terms_of_service_svg.tsx (93%)
 rewrite components/admin_console/feature_discovery/features/images/data_retention_svg.tsx (94%)
 rewrite components/admin_console/feature_discovery/features/images/groups_svg.tsx (96%)
 rewrite components/admin_console/feature_discovery/features/images/guest_access_svg.tsx (98%)
 rewrite components/admin_console/feature_discovery/features/images/ldap_svg.tsx (92%)
 rewrite components/admin_console/feature_discovery/features/images/saml_svg.tsx (98%)
 rewrite components/admin_console/feature_discovery/features/images/system_roles_svg.tsx (92%)

+++ I'm about to do the following to push to GitHub (and I'm assuming origin is your personal fork):

  git push origin automated-cherry-pick-of-mattermost-webapp-#8579-upstream-release-6.0-1629214056:automated-cherry-pick-of-mattermost-webapp-#8579-upstream-release-6.0

Failed to add the RSA host key for IP address '<IP_ADDRESS>' to the list of known hosts (/app/.ssh/known_hosts).
remote:
remote: Create a pull request for 'automated-cherry-pick-of-mattermost-webapp-#8579-upstream-release-6.0' on GitHub by visiting:
remote:      https://github.com/mattermost-build/mattermost-webapp/pull/new/automated-cherry-pick-of-mattermost-webapp-%238579-upstream-release-6.0
remote:
To github.com:mattermost-build/mattermost-webapp.git
 * [new branch]          automated-cherry-pick-of-mattermost-webapp-#8579-upstream-release-6.0-1629214056 -> automated-cherry-pick-of-mattermost-webapp-#8579-upstream-release-6.0

+++ Creating a pull request on GitHub at mattermost-build:automated-cherry-pick-of-mattermost-webapp-#8579-upstream-release-6.0
Error creating pull request: Unprocessable Entity (HTTP 422)
Invalid value for "base"

+++ Returning you to the master branch and cleaning up.

Performed manually, successfully.

@neallred Is this a requirement for v6.0? If yes, can you help cherry-pick to the cloud branch? https://community.mattermost.com/core/pl/cmqefh9ue7dnxgfm1cirbcj9se

It is a requirement for v6.0. It was cherry-picked earlier, manually, before the fast forward was completed. I thought fast-forward had already completed, so this went in earlier on accident. You can see it in the cloud branch here: https://github.com/mattermost/mattermost-webapp/commits/cloud


Error getting container from driver devicemapper during build

Trying to build from https://github.com/rednil/openstreetmap-tiles-docker, I am getting the following output:
Step 19 : RUN cd /usr/local/src/mapnik-style/inc && cp fontset-settings.xml.inc.template fontset-settings.xml.inc
---> Running in a464b257e6f9
---> 908810edf323
Removing intermediate container a464b257e6f9
Step 20 : COPY mapnik-style/inc/datasource-settings.sed /tmp/
---> a1c9d7174f01
Removing intermediate container 5803d4a43019
Step 21 : RUN cd /usr/local/src/mapnik-style/inc && sed --file /tmp/datasource-settings.sed  datasource-settings.xml.inc.template > datasource-settings.xml.inc
---> Running in 395637437e3b
---> 83b535bc37a1
Removing intermediate container 395637437e3b
Step 22 : COPY mapnik-style/inc/settings.sed /tmp/
---> fe01a8f86ecd
Removing intermediate container bb2e0579ea3f
Step 23 : RUN cd /usr/local/src/mapnik-style/inc && sed --file /tmp/settings.sed  settings.xml.inc.template > settings.xml.inc
---> Running in 9827ede1fbe2
INFO[1930] Error getting container 9827ede1fbe256ee46fc94334e021dae246a549f3e4757445dec5118eb0d0c59 from driver devicemapper: open /dev/mapper/docker-252:1-16193242-9827ede1fbe256ee46fc94334e021dae246a549f3e4757445dec5118eb0d0c59: no such file or directory
When I log into fe01a8f86ecd and execute step 23 manually it works. Is this some race condition I am reading about elsewhere?
docker version
Client version: 1.4.1
Client API version: 1.16
Go version (client): go1.3.3
Git commit (client): 5bc2ff8
OS/Arch (client): linux/amd64
Server version: 1.4.1
Server API version: 1.16
Go version (server): go1.3.3
Git commit (server): 5bc2ff8
docker info
Containers: 43
Images: 87
Storage Driver: devicemapper
Pool Name: docker-252:1-16193242-pool
Pool Blocksize: 65.54 kB
Data file: /var/lib/docker/devicemapper/devicemapper/data
Metadata file: /var/lib/docker/devicemapper/devicemapper/metadata
Data Space Used: 10.96 GB
Data Space Total: 107.4 GB
Metadata Space Used: 17.84 MB
Metadata Space Total: 2.147 GB
Library Version: 1.02.82-git (2013-10-04)
Execution Driver: native-0.2
Kernel Version: 3.13.0-44-generic
Operating System: Ubuntu 14.04.1 LTS
CPUs: 4
Total Memory: 3.468 GiB
Name: ThinkPad
ID: BGDR:G2CV:JKG6:2WA6:OQ2G:5FTX:2ISX:BO6W:DSLD:LEJ2:U7N3:F2UC
WARNING: No swap limit support

Seems the same as https://github.com/docker/docker/issues/4036

ping @vbatts

duplicate of #4036


Dont know why  code stop at an unknow break point when i am run dev in debug mode

Describe the bug
in title
To Reproduce
git clone this project
yarn install
config intellij idea with npm

press the debug run button

and then the code  stoped at an unknow  point
"未知" = ”unknow“

only if i press the contiue button the window is render ，every time
Expected behavior
code only stop at break point i added
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: Win10
Browser Chrome
node 16
ide intellij idea

Additional context

Solved by change node version to
nvm install v18.17.0
nvm use 18.17.0


Best practice to store Refresh token and access token

I am new to jsforce
I am trying to set up access/refresh token flow as per the document.
Refresh token and access token is getting generated successfully and able to use them to subscribe platform events. How to ensure I have valid connection through out my application since I have to use the connection object for multiple actions like subscribing platform events sending email task etc.
I have added script like this
	createConn(): Promise<any> {
		try {
		  var conn = new jsforce.Connection({
			oauth2 : {
			  clientId : <SF_CLIENT_ID>,
			  clientSecret : <SF_CLIENT_SECRET_ID>,
			  redirectUri : <SF_REDIRECT_URL>
			},
			instanceUrl : <SF_INSTANCE_URL>,
			accessToken : <SF_ACCESS_TOKEN>,
			refreshToken : <SF_REFRESH_TOKEN>
		  });
		  conn.on("refresh", function(accessToken, res) {
			console.log('Access token refreshed');
			// Refresh event will be fired when renewed access token
			// to store it in your storage for next request
	});
           logger.info('Connection to salesforce established successfully');
           return conn;
     }

When and how jsforce will execute conn.on("refresh", function(accessToken, res)  to refresh accesstoken?
What is best practice to store tokens for next use?
Do we need to make sure we have valid connection? Because it is not throwing any exception when I just use connection object with invalid tokens.
Can you please help me on these?
@stomita
Thanks in Advance!

refresh is happening when I do sobject query.
For testing purpose I just added below code:
`let conn: Connection ;
try {
let oauth2 = new jsforce.OAuth2({
loginUrl : process.env.SF_LOGIN_URL,
clientId : process.env.SF_CLIENT_ID,
clientSecret : process.env.SF_CLIENT_SECRET_ID,
redirectUri : 'http://localhost:3000/getAccessToken'
});
app.get('/oauth2/auth', function(req, res) {
res.redirect(oauth2.getAuthorizationUrl({ scope : 'api id web refresh_token' }));
});
app.get('/getAccessToken', function(req, res) {
conn = new jsforce.Connection({ oauth2 : oauth2 });
const code = req.param('code');
conn.authorize(code, function(err, userInfo) {
if (err) { return console.error(err); }
// Save them to establish connection next time.
logger.info(conn.accessToken);
logger.info(conn.instanceUrl);
logger.info(conn.refreshToken);
logger.info("User ID: " + userInfo.id);
logger.info("Org ID: " + userInfo.organizationId);
res.send('success');
  conn.on("refresh", function(accessToken, res) {
    logger.info('New accessToken');
    // Refresh event will be fired when renewed access token
    // to store it in your storage for next request
  });
});

});
app.get('/query', async function(req, res) {
if(conn){
logger.info(conn.accessToken);
const recs = conn.sobject('Opportunity').find({
Id: '0060p000005F0kHAAS'
});
for (const rec of await recs) {
console.log(rec.Id);
}
}
res.send('success');
});
} catch (error) {
logger.error(error.message);
}`
Here after I revoke the accesstoken and try to hit http://localhost:3000/query refresh is happening.
So is there any limitation in streaming api? We are stuck with the implementation.
@stomita can you please help me on this?

This ticket contains a little more information about the auth flow: https://github.com/jsforce/jsforce/issues/824
By that answer, the whole accessToken is managed by JSForce, and you only have to worry about invalidation of refreshToken.


Publish to https://cdnjs.com/

Please host static assets on a content delivery network such as CDNJS.com, so that developers can integrate Textures.js more easily into our applications!

Hi, thanks for the suggestion. I just added a comment in the readme. Please have a look at https://github.com/riccardoscalco/textures/commit/c1a3e80f1b605ccacee8999949559f5d4275bea1.


crypto.subtle is undefined on React Native

crypto.subtle is undefined here (and everywhere else even later on) on both iOS and Android.
I'm running<EMAIL_ADDRESS>and it was created with react-native init. Tried looking around to find some culprit but haven't managed to find anything.
Found the culprit, seems that it doesn't work while remotely debugging. Might have something to do with the code being executed in Chrome.
It seems that msrcrypto runs in a web worker while in remote debugging which causes this to be set to true, which in turn causes this (msrcryptoSubtle) not to be instantiated, ergo undefined everywhere while remotely debugging.

If I remember correctly React Native passes the bundle to be executed by Chrome while remotely debugging and msrCrypto tries to run in browser mode so it makes sense that it tries to use Web Workers.
JS execution environment in React Native, more specifically:

When using Chrome debugging, all JavaScript code runs within Chrome itself, communicating with native code via WebSockets.`

I have another little issue, it's more related to documenting the usage in React Native and I can open another issue with it so others can properly search for it. msrCrypto only uses jwt keys and using raw will always throw an error. Haven't had the time to actually try a jwt key yet and most probably will do it on Monday.

Just running msrCrypto in a browser shouldn't be enough for it to use Web Workers. It should be in a browser and forceSync should be false. I set forceSync to true, so I think the entire bundle is running in a Web Worker. Unless:

My forceSync modification isn't changing anything
There's some other craziness I'm unaware of in msrCrypto

re: raw - Yeah, there's another mention of this issue in this comment. I think this is one of the limitations I'll need to include with this change, until it includes a raw to jwk converter.

Well that's what I was saying in the issue description, your forceSync does nothing (actually it crashes the app) while remote debugging because crypto.subtle is undefined. It never gets initialized in msrCrypto because it's in the browser, at least that's what I figured out while debugging and trying to find the issue.

@bunea does importKey work for you without Chrome attached? It's undefined for me

@vladikoff It worked without Chrome attached (actually no remote debugger should be attached in order to work) but even so I made a fork in which I set runningInWorkerInstance to false so I can use the library. If you want you can use the fork as it will be up for a long while there, you just need to set a resolution option in package.json.
    "resolutions": {
        "msrcrypto": "git+https://github.com/bunea/msrCrypto"
    }

With that option it will work even while remotely debugging.

@vladikoff This is the list or algorithms supported by msrCrypto :
Supported Algorithms:

	msrCrypto supports the following algorithms:

		Encryption/Decryption:
			RSA-OAEP, RSA-PKCSv1.15, AES-CBC, AES-GCM

		Signature/Verify
			RSA-PSS, RSA-PKCSv1.15, HMAC, ECDSA

		Hash
			SHA-1, SHA-224, SHA-256, SHA-384, SHA-512

		Derive Key/Bits
			Concat-KDF, ECDH

		Supported ECC curves:
			P-256, P-384, P-512, BN-254, NUMSP256D1, NUMSP256T1, NUMSP384D1, NUMSP384T1

		KeyWrap
			AES-GCM

@bunea ah I am using AES-KW, might need to find a different library then or something

@bunea's fork works for me.  I recommend putting it into the main branch

@vladikoff did u find solution for AES-KW

@biboukat if you look at the updated compatibility table it looks like it was added.

A128KW
AES Key Wrap with default initial value using 128-bit key

A192KW
AES Key Wrap with default initial value using 192-bit key

A256KW
AES Key Wrap with default initial value using 256-bit key

Unfortunately anything not listed in @bunea's msrCrypto list above isn't supported. The AES-KW algorithms are listed in the legend, but haven't been tested. The support grid below the legend shows everything that's tested.
The original issue seems to be fixed, but comment if this is still an issue. Closing for now.


the directory where the dotnet command is executed, not the directory of its DLL.

See this comment

@Perustaja The working directory of the application is determined by the directory where the dotnet command is executed, not the directory of its DLL. In this case, the dotnet command should be executed in the publish folder so published files can be discovered by the application (static assets, appsettings.json, etc).
Maybe it's worth documenting this detail in the Host and deploy docs.

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

ID: 62fb594f-04bf-c4d7-c94b-6cd6d8b12d75
Version Independent ID: 64e973ac-838d-4459-06b0-4e943bff936e
Content: Host and deploy ASP.NET Core
Content Source: aspnetcore/host-and-deploy/index.md
Product: aspnet-core
Technology: aspnetcore-hostdeploy
GitHub Login: @Rick-Anderson
Microsoft Alias: riande

Associated WorkItem - 34774

@Perustaja when you get your app running, would you be able to add this info to the doc?
At the top right of the article, select the Edit pen icon:

Select the pen icon again. Save.


[PE-D][Tester E] Confusing Error messages

Error messages for different commands follows different formats
Error message for add_applicant:

Error message for applicant_status:

[Phone] and [Status] are optional according to the notation stated in the UG. But it is not
Error message for filter_by_status:

The error message doesn't show how to use the command for this
Error message for filter_interviews_by_date:

The error message does not help the user

Labels: type.FeatureFlaw severity.Low
original: yorklim/ped#20

UG issue

Cannot fix in v1.4


Add PolicySet to the policy framework

Treat multiple policies as a group using a new CRD called PolicySet.

This has been completed.


Installation issue with pre-installed Serverless

I'm starting with an OCP Cluster that has serverless (1.12.0) installed - I am installing kafka and then kourier and kourier fails to start.
Script (nabbed from Matthias) for adding Kafka:
https://raw.githubusercontent.com/rhdemo/2021-demo-cluster-setup/master/backend/strimzi.sh
Script (nabbed from Matthias) for adding Kourier:
https://raw.githubusercontent.com/rhdemo/2021-demo-cluster-setup/master/backend/kourier.sh
The 3scale-kourier-gateway-xxx Pod hangs with:
[2021-02-12 11:24:50.340][1][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:92] StreamAggregatedResources gRPC config stream closed: 14, upstream connect error or disconnect/reset before headers. reset reason: connection failure

If you'er using Openshift Serverless, you shouldn't setup Kourier manually at all anyway. That's done for you via the Serverless Operator already.

This is for provisioning Brokers for knative with Kafka channels rather than in-memory; I installed the serverless operator, instantiated the eventing and serving components and now want to replace my in memory Brokers with Kafka based ones; AFAIK this functionality is not installed as part of the serverless operator?

That piece I don't know of. Kourier (where this issue has been opened) though, is definitely installed already.

Right - like Markus says: If Openshift Serverless (especially knative-serving) is already installed, no need to install Kourier again.
/close


#84 parameterless atom listener

This PR is related to #84 Just last commit

I cherrypicked the one commit for this PR and force pushed it onto the the branch (based on current canary). pls verify that everything is alright.
thanks

Thanks for the PR!
Could you do the following changes:
In AtomListener.cs and in the method(s) OnEventRaised, please use this syntax if (_unityEventResponse != null) { _unityEventResponse.Invoke(first, second); } instead of the null conditional. See https://github.com/dotnet/csharplang/issues/2020
Remove the [EditorIcon("atom-icon-purple")] attribute in  AtomAction. This was actually never needed in the first place in this file. Needs instead to exist in the final implementation of an AtomAction.
After the above is fixed I will merge the PR.

See dotnet/csharplang#2020

UnityEvent inherits from UnityventBase (which inherits from nothing).  it does not inherit from UnityEngine.Object and should not be affected from the null-propagation problematic.
just saying. I actually don't care whether its an if or the propagation syntax.

UnityEvent inherits from UnityventBase (which inherits from nothing). it does not inherit from UnityEngine.Object and should not be affected from the null-propagation problematic.
just saying. I actually don't care whether its an if or the propagation syntax.

Aha, that makes sense! Disregard that particular change then :)

Done. I thought we need it because you got EditorIcon in every AtomAction<T> and etc. Anyway it's done.


show loader when the component waits for the first load

loader prop not rendered at first load.
I am looking for a way, where I can show the loader when the component waits for the first load of data. As the API takes some time to respond, I want to show the loader in the first load. It is working for the second set of data, not the first one.
Is there any way to achieve the same?
Thanks

Please watch this video for this library
https://youtu.be/c0nKjMnDfG4


Fixed KubeCon NA Banner mobile layout

Closes #43622
This fix should work for other announcements as well

Hi @Gauravpadam , since this PR has needed a rebase for more than a few months, I'm closing this PR for now.
When you have to rebase this PR, you can reopen this PR with /reopen in a comment
/close


Not implemented function call: LoadImmutable required for integration with Remix IDE

Name::LoadImmutable => todo!(), is not implemented in revive but used in Remix unit tests
Error message from Remix:
Contract `remix_tests.sol:Assert` compiling error: thread 'main' panicked at crates/solidity/src/yul/parser/statement/expression/function_call/mod.rs:504:36:
not yet implemented
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Will be fixed with #16 :)


Pagination, phase 1: Add unit tests for :core module with coverage.

Add unit tests for :core module with coverage. Uncovered: toCursor, because it is will be changed soon. Merge target: #226
Description
Completely pass :core:checkstyleTest. Partial pass for :core:test :core:jacocoTestReport :core:jacocoTestCoverageVerification:
* What went wrong:
Execution failed for task ':core:jacocoTestCoverageVerification'.
> Rule violated for class org.opensearch.sql.planner.physical.PhysicalPlan: lines covered ratio is 0.7, but expected minimum is 1.0
  Rule violated for class org.opensearch.sql.planner.physical.PhysicalPlan: branches covered ratio is 0.5, but expected minimum is 1.0
  Rule violated for class org.opensearch.sql.planner.physical.ProjectOperator: lines covered ratio is 0.9, but expected minimum is 1.0
  Rule violated for class org.opensearch.sql.planner.physical.ProjectOperator: branches covered ratio is 0.8, but expected minimum is 1.0
  Rule violated for class org.opensearch.sql.planner.PaginateOperator: branches covered ratio is 0.9, but expected minimum is 1.0

Issues Resolved
N/A
Check List

[ ] New functionality includes testing.

[ ] All tests pass, including unit test, integration test and doctest

[ ] New functionality has been documented.

[ ] New functionality has javadoc added
[ ] New functionality has user manual doc added

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

CI run for this PR: https://github.com/Bit-Quill/opensearch-project-sql/actions/runs/4247173319
No unit tests or checkstyle validations failed for :core:test

@Yury-Fridlyand any reason this can't be merged?

No reasons, just waited for more reviews. Going to merge, it is not the last step and last opportunity to review.


Update http4s-blaze-server, http4s-dsl to 0.21.17

Updates

org.http4s:http4s-blaze-server
org.http4s:http4s-dsl

from 0.21.15 to 0.21.17.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.http4s" } ]

labels: library-update, semver-patch

Superseded by #76.


Run complete test suite (unit + integration) on merge to master.

Integration tests are becoming more powerful than unit tests for our codebase. Run complete test suite on merge to master.

Will merge this once #365 is submitted.


Current module manifest schema is not adequate to properly support cross-platform modules

It is not going to be uncommon for module authors to want to provide slightly different functionality on different operating systems e.g. the module provides 30 commands, two of which only work on Windows PowerShell.  Right now, there is no good way to declare "conditional" module exports in the manifest where the condition is the OS platform.
In fact, even PowerShellVersion is problematic if you design your module to load into both Windows PowerShell and PowerShell Core.  Which PowerShell version does that refer to? Windows PowerShell? PowerShell Core?  What if at some point, on PS Core I require 6.1.0?  Does that mean my module can't load into Windows PowerShell 5.x anymore - probably.  But I may not be providing that functionality when I'm loaded into Windows PowerShell (runtime decision) so Win PS 5.1 should be allowed when loading into Windows PowerShell.
AFAICT all of these field's values may be conditional upon the OS platform and/or the PowerShell platform (Win or Core)

PowerShellVersion
PowerShellHostName / Version
RequiredAssemblies
RequiredModules
ModuleList
NestedModules
FormatsToProcess
ScriptsToProcess
TypesToProcess
ClrVersion
DotNetFrameworkVersion
AliasesToExport although CompatiblePSEditions might mitigate this one
CmdletsToExport
FunctionsToExport
VariablesToExport
Tags

In order to make any changes backwards compatible with existing Windows PowerShell instance, we could put all the conditional declarations in PrivateData.  This implies that fields not in PrivateData inherently apply to Windows PowerShell when module is loaded by Windows PowerShell.  PowerShell Core could be modified to process the conditional fields in PrivateData.  What might those look like?  Maybe this?
    PrivateData = @{
        PSManifestEx = @{
            PowerShellVersion = "6.1.0" # fields at this level apply to all OS platforms for PS Core
            Linux = @{
                RequiredModules = @(...)
                CmdletsToExport = @(...)
            }
            MacOS = @{
                RequiredModules = @(...)
                CmdletsToExport = @(...)
            }
            Windows = @{ # this is for PowerShell Core on Windows
                RequiredModules = @(...)
                CmdletsToExport = @(...)
            }
        }

This doesn't take into account Nano server which I don't have enough experience with to take it into account.  Anyway, this is just something to get the conversation started.
Long term, this approach seems less than ideal - burying so much important metadata under PrivateData.

I originally proposed allowing variables like $IsLinux in the module manifest so you could write:
ExportedCmdlets = @(
    'Get-Thing'
    if ($IsLinux) { 'Get-LinuxThing' }
)

Untested, but I think all that is needed is to add to this list.

A complementary aspect is how to restrict a module to an edition / a (set of) platform(s):

From what I can tell, setting CompatiblePSEditions to one edition  isn't being enforced at module load-time.

It seems that there is no key at all to limit support to a given (set of) platform(s).

(Note that edition support and platform support are independent dimensions; conceivably, modules can run on both editions while requiring Windows as the platform.
Conversely, though, limiting support to non-Windows platforms implies the Core edition.)

I would like to contribute and make a PR for this issue :

Add IsLinux, IsMacOS and IsWindows to ModuleCmdletBase.cs#L448
Write pester tests

Anything else ?

That sounds like a good start, go for it! 😄

I would like to add PSVersionTable too, someone again that ?
Architecture is still a missing information in PSVersionTable but can be added later #8047


Implementation of TensorPad pass to align shared meme transpose operands

TensorPad applies the TransposePadOpPattern. This pattern finds transpose linalg operations and pads their input/output values to the shared mem transpose tile size of 32x32. Right now this pass is only used in a test. Will be developed further in followup PRs.
Limitations:

This pads all operands (input/output) even if not necessary
Only supports 2D transposes and assumes tile size of 32x32 (will be addressed in followup)

Part of  https://github.com/iree-org/iree/issues/10005

Broad comment here. This is doing a lot of the same things that had already been tried upstream with respect to padding. If this is all happening at the tensor level this seems to be re-inveting a lot of things that have already been looked at. @hanhanW who looked at it in quite a lot of detail.

What part in particular? I assume you are talking about rewriteAsPaddedOp as the rest is really just boilerplates. As far as I understand the upstream logic doesn't work out of the box which is why some logic is duplicated there. It would be good to unify that upstream but I'm not sure we have enough knowledge to do it at this point.
What would you suggest?

What part in particular? I assume you are talking about rewriteAsPaddedOp as the rest is really just boilerplates. As far as I understand the upstream logic doesn't work out of the box which is why some logic is duplicated there. It would be good to unify that upstream but I'm not sure we have enough knowledge to do it at this point. What would you suggest?

I think we should use the upstream method -- rewriteAsPaddedOp. I skim through two methods and found that the main difference is finding the bounding box. We can maybe passing a control function to the method.
Before doing that, I have a question. The upstream one looks into the producer chain until getting a slice op. It then extract the value if possible. I looked into the test IR, and would like to know if it's possible to generate similar IR that fits the upstream need.
    %4 = affine.min affine_map<(d0) -> (-d0 + 48, 32)>(%arg0)
    %5 = affine.apply affine_map<()[s0] -> (s0 * 32)>()[%workgroup_id_x]
    %6 = affine.apply affine_map<()[s0] -> (s0 * 32)>()[%workgroup_count_x]
    scf.for %arg1 = %5 to %c32 step %6 {
      %7 = flow.dispatch.tensor.load %1, offsets = [%arg0, %arg1], sizes = [%4, 32], strides = [1, 1] : !flow.dispatch.tensor<writeonly:48x32xf32> -> tensor<?x32xf32>
      %8 = flow.dispatch.tensor.load %0, offsets = [%arg1, %arg0], sizes = [32, %4], strides = [1, 1] : !flow.dispatch.tensor<readonly:32x48xf32> -> tensor<32x?xf32>
      %9 = linalg.generic {indexing_maps = [affine_map<(d0, d1) -> (d1, d0)>, affine_map<(d0, d1) -> (d0, d1)>], iterator_types = ["parallel", "parallel"]} ins(%8 : tensor<32x?xf32>) outs(%7 : tensor<?x32xf32>) attrs =  {lowering_config = #iree_codegen.lowering_config<tile_sizes = [[32, 32]]>} {
      ^bb0(%arg2: f32, %arg3: f32):
        linalg.yield %arg2 : f32
      } -> tensor<?x32xf32>
      flow.dispatch.tensor.store %9, %1, offsets = [%arg0, %arg1], sizes = [%4, 32], strides = [1, 1] : tensor<?x32xf32> -> !flow.dispatch.tensor<writeonly:48x32xf32>
    }
  }

The operands of generic op are %7 and %8. The unknown sizes are all %4. Instead of hard-coded paddedShape = {32, 32};, we should extract the value from %4 right? It would be easier if we make the input IR like below. In this form, we'll be able to use upstream method.
%x = flow.dispatch.tensor.load %0 = [%arg0, %arg1] ... // full tensor
%y = tensor.extract_slice %x[0, 0][32, %4] ....
%z = linalg.generic .. ins(%y ..)

@hanhanW and I did discuss the upstream patterns. I tried using them directly as intended but they did not work out of the box. I scrapped the IR examples once I moved on to my own implementation so going from memory:

upstream patterns don't accept our IREE::Flow::DispatchTensorLoadOp. instead they depend on extract slice for the input.
as HanHan mentioned, you can't pass padding shapes directly, only specify the dimensions to pad and the values to pad with. In the case of transpose, I wanted to pad directly to the tile size, currently hard coded to 32x32 for this simple example. But this will change in followup to support more dimensions for padding.

Padding transpose is a bit different in the sense that the padding applies to specific dimensions of the transpose for each operand. I didn't see a way to make this distinction with the upstream pass, though its likely part of its bounding box calculation. The padded tile size must match the transpose tile size determined by the transpose order in https://github.com/iree-org/iree/blob/main/compiler/src/iree/compiler/Codegen/LLVMGPU/KernelConfig.cpp/#L535
Re @hanhanW question: the %4 is the dimension of the tile that is incomplete due to the input not aligning exactly with the tile size. Normally we set the tile size to 1 for unaligned shapes, but I'm forcing it to be a fixed value and then using this code to pad up to it. You can see that its determined by  %4 = affine.min affine_map<(d0) -> (-d0 + 48, 32)>(%arg0) which comes from the workgroup index and tile size. Not sure what you mean by:

we should extract the value from %4 right?

Not sure about your second question either. The flow.dispatch.tensor.load are introduced by tiling to workgroup and they stick around until bufferization. If I replaced them with an extract slice just to run the upstream pattern, I suspect I'd need to do a similar transformation to get them back for subsequent passes?
I spent quite a bit of time digging through https://github.com/iree-org/iree-llvm-fork/blob/main/mlir/lib/Dialect/Linalg/Transforms/Transforms.cppto understand if this could be used, but there is prolly something I missed. The similarities born from some of the useful upstream functions that I am reusing, like makeComposedPadHighOp.  But ultimately the pattern seems to specific to a different focus for padding and not modular enough to reuse bits without extra transformations applies before and after it? I'd question the value of using them with the added code/complexity.

currently hard coded to 32x32 for this simple example. But this will change in followup to support more dimensions for padding.
You can see that its determined by %4 = affine.min affine_map<(d0) -> (-d0 + 48, 32)>(%arg0) which comes from the workgroup index and tile size.

We should not hardcoded the values.. The tiling size is 32. That's why we're seeing %4 = affine.min affine_map<(d0) -> (-d0 + 48, 32)>(%arg0). Basically, we should look into the affine.min op and extract the tiling value (i.e., 32 in this case) out. We should not just hard-code 32. There is a method for doing this -- getConstantUpperBoundForIndex.
To achieve what I said, we can look into the actual examples. I'm wondering if we can make the input IR
%4 = affine.min affine_map<(d0) -> (-d0 + 48, 32)>(%arg0)
%7 = flow.dispatch.tensor.load %1, offsets = [%arg0, %arg1], sizes = [%4, 32], strides = [1, 1] : !flow.dispatch.tensor<writeonly:48x32xf32> -> tensor<?x32xf32>
%8 = flow.dispatch.tensor.load %0, offsets = [%arg1, %arg0], sizes = [32, %4], strides = [1, 1] : !flow.dispatch.tensor<readonly:32x48xf32> -> tensor<32x?xf32>
%9 = linalg.generic {...} ins(%8 : tensor<32x?xf32>) outs(%7 : tensor<?x32xf32>)

to be
%x = flow.dispatch.tensor.load %0 = [%arg0, %arg1] ... // full tensor
%y = flow.dispatch.tensor.load %0 = [%arg1, %arg0] ... // full tensor
%sz = affine.min affine_map<(d0) -> (-d0 + 48, 32)>(%arg0)
%sub_x = tensor.extract_slice %sub_x[0, 0][%4, 32] ....
%sub_y = tensor.extract_slice %sub_y[0, 0][32, %4] ....
%9 = linalg.generic {...} ins(%sub_y : tensor<32x?xf32>) outs(%sub_x : tensor<?x32xf32>)

If we can do it, the upstream version should work. The upstream version would get the slice, and call getConstantUpperBoundForIndex to get 32.
I suspect we can move ConvertToDestinationPassingStylePass to an earlier stage, then we can get the IR I mentioned.

I am not following all the details here, but if the issue is that it is looking for a tensor.extract_slice instead of a flow.dispatch.tensor.load, then we've actually hit this a few times now... One way forward would be to prioritize adding the SubsetExtractOpInterface that Nicolas has mentioned a few times needed in the fullness of time. We could help with creating this interface, with the tensor.extract_slice and tensor.insert_slice implementing this interface. We move the implementations upstream that are looking for tensor.extract_slice and tensor.insert_slice to use this interface instead.
We've hit this a couple of times. Instead of duplicating the upstream implementation to get around this, thats a better convergence point... I dont think we want to keep ownership of all of this code in IREE... we want to rely/build all such things upstream.
Also, eventually we will probably stop using flow.dispatch.tensor.load/flow.dispatch.tensor.store this way... so anything built on that is going to be an issue....

Hanhan and Thomas and I just discussed this a bit. Several things going on here so I'll try to summarize and and answer your question:
First off, I'll remove the hardcoded tile size and implement Hanhan's suggestion in https://github.com/iree-org/iree/pull/10655#issuecomment-1269026636. Based on the affine maps providing the sizes, this should extract the tile sizes already set distribute to workgroups.
Regarding flow tensor load. I have a gist of the IR from this work in-progress pipeline using the TensorPadPass after tileAndDistributeToWorkgroup: addGPUTransposePassPipeline
From what I'm understand, with the latest changes to move Vectorization before Bufferization, we're left with flow.dispatch.tensor.load/flow.dispatch.tensor.store after distribute to workgroup. The extract slice ops aren't introduced until tiling on the GPU. The TensorPadPass is going in place of the existing TesnorAllocPass to handle the allocation and copying of data into shared memory, but with padding this time. According to Hanhan, upstream expects pure tiling to be applied before padding, but in we're doing it the other way around here.
Even if this were addressed, I still have the separate issue noted above about the inflexibility to apply padding to select operands. In this simple example I have, the input IR is actually a 'mhlo.transpose" that takes in one operand:
 %0 = "mhlo.transpose"(%ins) {permutation = dense<[1,0]> : tensor<2xi64>} : (tensor<32x48xf32>) -> tensor<48x32xf32>

The output shape persists as an linalg.init_tensor  in the IR past distribution to workgroups  until ConvertToDestinationPassingStyle which replaces it with a flow.dispatch.tensor.load from a hal subspan, hence the two loads when there is only one input shape.  In practice, this is loading form an empty tensor, padding is unnecessary: introduces an allocation, fill, then copy when in reality, only the allocation is necessary. We don't have a concrete solution to this. Hanhan has suggested using the upsteam [populatePadOpVectorizationPatterns] (https://github.com/llvm/llvm-project/blob/074fcec1eabfc992c46c95df215b1caf5cf58970/mlir/lib/Dialect/Linalg/Transforms/Vectorization.cpp#L1095) which will vectorize this and then hopefully optimize it out, but not sure if this can work for similar reasons I ran into with padding.
Ideally I can get to a point where I can fully use the upstream pattern, though they handle way more than I need. At the moment, they're not applicable. For this change which is just a step towards handling non-aligned, I think it should be a concern of a separate PR down the line (and will definitely need more discussion on SubsetExtractOpInterface). I'm going to modify this pass further in following PRs. Hanhan is fine addressing the size calculation for now while we figure out other issues.
@ThomasRaoux can chime in if I'm missing anything else?

Hanhan and Thomas and I just discussed this a bit. Several things going on here so I'll try to summarize and and answer your question:
First off, I'll remove the hardcoded tile size and implement Hanhan's suggestion in #10655 (comment). Based on the affine maps providing the sizes, this should extract the tile sizes already set distribute to workgroups.
Regarding flow tensor load. I have a gist of the IR from this work in-progress pipeline using the TensorPadPass after tileAndDistributeToWorkgroup: addGPUTransposePassPipeline
From what I'm understand, with the latest changes to move Vectorization before Bufferization, we're left with flow.dispatch.tensor.load/flow.dispatch.tensor.store after distribute to workgroup. The extract slice ops aren't introduced until tiling on the GPU. The TensorPadPass is going in place of the existing TesnorAllocPass to handle the allocation and copying of data into shared memory, but with padding this time. According to Hanhan, upstream expects pure tiling to be applied before padding, but in we're doing it the other way around here.
Even if this were addressed, I still have the separate issue noted above about the inflexibility to apply padding to select operands. In this simple example I have, the input IR is actually a 'mhlo.transpose" that takes in one operand:
 %0 = "mhlo.transpose"(%ins) {permutation = dense<[1,0]> : tensor<2xi64>} : (tensor<32x48xf32>) -> tensor<48x32xf32>

The output shape persists as an linalg.init_tensor in the IR past distribution to workgroups until ConvertToDestinationPassingStyle which replaces it with a flow.dispatch.tensor.load from a hal subspan, hence the two loads when there is only one input shape. In practice, this is loading form an empty tensor, padding is unnecessary: introduces an allocation, fill, then copy when in reality, only the allocation is necessary. We don't have a concrete solution to this.

The fact the bufferization does an allocation, fill and copy is an implementation detail.
Hanhan has suggested using the upsteam [populatePadOpVectorizationPatterns]<EMAIL_ADDRESS>which will vectorize this and then hopefully optimize it out, but not sure if this can work for similar reasons I ran into with padding.

That would be ideal....

Ideally I can get to a point where I can fully use the upstream pattern, though they handle way more than I need. At the moment, they're not applicable. For this change which is just a step towards handling non-aligned, I think it should be a concern of a separate PR down the line (and will definitely need more discussion on SubsetExtractOpInterface). I'm going to modify this pass further in following PRs. Hanhan is fine addressing the size calculation for now while we figure out other issues.
@ThomasRaoux can chime in if I'm missing anything else?

There is a lot going on here. My concern is that we are building a whole amount of tech that is in IREE. Instead of that we should be biasing on moving things so that we can use things from upstream directly. I see that having the flow.dispatch.tensor.load/flow.dispatch.tensor.store after tile + distribute is causing an issue. So we should prioritize getting to a stage away from that and re-prioritize work instead of replicating tech from upstream in IREE.

Switched to getConstantUpperBoundForIndex.

There is a lot going on here. My concern is that we are building a whole amount of tech that is in IREE. Instead of that we should be biasing on moving things so that we can use things from upstream directly. I see that having the flow.dispatch.tensor.load/flow.dispatch.tensor.store after tile + distribute is causing an issue. So we should prioritize getting to a stage away from that and re-prioritize work instead of replicating tech from upstream in IREE.

Do you mean that there is bunch of work being done by others around padding? This PR is duplicating a fairly small amount of logic. Since we are still in the exploring phase I would rather not upstream things just for this case. If you think there are other usages and supporting flow.dispatch.tensor.load/flow.dispatch.tensor.store is important for some other work it could make sense to tackle it now. If this is just related to this PR I don't think it is a good idea as I expect that there will be more back and forth coming up while we get padding working for the GPU.

There is a lot going on here. My concern is that we are building a whole amount of tech that is in IREE. Instead of that we should be biasing on moving things so that we can use things from upstream directly. I see that having the flow.dispatch.tensor.load/flow.dispatch.tensor.store after tile + distribute is causing an issue. So we should prioritize getting to a stage away from that and re-prioritize work instead of replicating tech from upstream in IREE.

Do you mean that there is bunch of work being done by others around padding? This PR is duplicating a fairly small amount of logic. Since we are still in the exploring phase I would rather not upstream things just for this case. If you think there are other usages and supporting flow.dispatch.tensor.load/flow.dispatch.tensor.store is important for some other work it could make sense to tackle it now. If this is just related to this PR I don't think it is a good idea as I expect that there will be more back and forth coming up while we get padding working for the GPU.

I mean that there is a lot of tech being built in IREE with no clear plan of upstreaming it. The divergence point seems to be the difference between IREE using flow.dispatch.tensor.load/flow.dispatch.tensor.store instead of tensor.extract_slice and tensor.insert_slice. (I think this has come up before). If this is a repeating occurence, I would rather prioritize moving to using scf.foreach_thread (and by proxy use tensor.extract_slice/tensor.insert_slice, etc.) and build/iterate over these things upstream. Duplicating the logic/independently evolving such things invariable make these IREE specific and harder to generalize. Is this really a blocker in terms of performance to achieve on models and driven by that?

I mean that there is a lot of tech being built in IREE with no clear plan of upstreaming it. The divergence point seems to be the difference between IREE using flow.dispatch.tensor.load/flow.dispatch.tensor.store instead of tensor.extract_slice and tensor.insert_slice. (I think this has come up before). If this is a repeating occurence, I would rather prioritize moving to using scf.foreach_thread (and by proxy use tensor.extract_slice/tensor.insert_slice, etc.) and build/iterate over these things upstream.

Here flow.dispatch.tensor.load/flow.dispatch.tensor.store is one difference but for experimentation it is convenient to not be bound by the opinion of the upstream pattern. Regarding flow.dispatch.tensor.load/flow.dispatch.tensor.store, scf.foreach_thread would solve it - as you mentioned - which is why I'm not a big fan about adding special support upstream to handle.

Duplicating the logic/independently evolving such things invariable make these IREE specific and harder to generalize. Is this really a blocker in terms of performance to achieve on models and driven by that?

Yes, this is also needed sometime to be able to experiment. It's not a blocker at the time but supporting padding for the GPU is part of the roadmap and is an important piece of generalizing the performance of the compiler.
To summarize based on the discussion I see different solutions:

Not land this PR and have Kojo continue the work on his own branch until everything is put together and we have more confidence on how padding should be handled
Re-evaluate the roadmap and decide that we need scf.foreach_thread transition before doing the padding work. Then we need to make sure we have a timeline for scf.foreach_thread and re-evaluate what we are working on at the time on the GPU side.

This should be part of the roadmap while planning GPU work as well. Outside of the GPU related work, this transition is not a blocker. If there was work like padding, (specialization from earlier, and there was one more) that all would benefit from moving to scf.foreach_thread, then that should have been part of the roadmap to start with? It isnt on my radar cause it is not a blocker for things that I am looking at right now, so I dont have this prioritized, planned etc. I dont know the details of padding implementation upstream to make the link that this is needed as a precursor.

Adding more control upstream to handle flow.dispatch.tensor.load/flow.dispatch.tensor.store but it feels like this is a side-effect of out current implementation.

I am not sure I follow what more control upstream implies. Broadly tensor.extract_slice/tensor.insert_slice are very similar in function as flow.dispatch.tensor.load/flow.dispatch.tensor.store(at least AFAICS for the analysis here, but there are also some very real differences w.r.t side-effects). Upstream implementations are very tied totensor.extract_slice/tensor.insert_slice. I think that would benefit with moving to using SubsetExtractOpInterface(which btw, doesnt exist, so if this was needed should have been prioritized appropriately based on discussion with Nicolas). Then the analysis/transformation would work without moving toscf.foreach_thread`. So between (2) and (3) we could have picked one way forward.

Any other changes that would make this PR acceptable?

Did I miss any other solution? What do you think is the path forward?

We seem to have painted ourselves into a corner. I am very concerned that we will end up building tech islands that we wont be able to get out of. Without building things upstream in "a clean environment" to start with, it is inevitable that we will have some shortcuts, assumptions baked in. Given Kojo has already spent time working on this, of course I don't want it to go to waste, but seeing a lot of things being built "for CUDA" based on the current state of the common parts will just result in divergence from other backends that we might not be able to reconcile. We might/will end up in a situation where all backends end up in a state where progress on one is hampered due to issues with other backends (explicitly a non-goal for IREE). In all these cases the preferred way forward is

Adapt/generalize upstream implementation, and/or
Adapt IREE to allow using upstream implementation.
Least desirable is

Copy/mimic implementation from upstream to get around representational issue due to expediency (we are explicitly telling other folks to not do this, so us doing it is a bit hypocritical).

Having raised the issue, I am not going to delve into implementation aspects here. I really hope we can avoid such situations with better ordering of tasks.

We seem to have painted ourselves into a corner. I am very concerned that we will end up building tech islands that we wont be able to get out of. Without building things upstream in "a clean environment" to start with, it is inevitable that we will have some shortcuts, assumptions baked in. Given Kojo has already spent time working on this, of course I don't want it to go to waste, but seeing a lot of things being built "for CUDA" based on the current state of the common parts will just result in divergence from other backends that we might not be able to reconcile. We might/will end up in a situation where all backends end up in a state where progress on one is hampered due to issues with other backends (explicitly a non-goal for IREE). In all these cases the preferred way forward is

Adapt/generalize upstream implementation, and/or
Adapt IREE to allow using upstream implementation.

Least desirable is

Copy/mimic implementation from upstream to get around representational issue due to expediency (we are explicitly telling other folks to not do this, so us doing it is a bit hypocritical).

Having raised the issue, I am not going to delve into implementation aspects here. I really hope we can avoid such situations with better ordering of tasks.

The logic duplicated is ~50 lines of code and we have been doing this kind of work in IREE that we later generalize and upstream in the past.
Therefore I assume your concern goes much beyond just the scope of this PR. I think we need to rework the expectations we have with regard to the work going in IREE. It sounds like you have serious concerns about the state of the backend. Let's solve that offline so that we don't bump into that at every PR.

We seem to have painted ourselves into a corner. I am very concerned that we will end up building tech islands that we wont be able to get out of. Without building things upstream in "a clean environment" to start with, it is inevitable that we will have some shortcuts, assumptions baked in. Given Kojo has already spent time working on this, of course I don't want it to go to waste, but seeing a lot of things being built "for CUDA" based on the current state of the common parts will just result in divergence from other backends that we might not be able to reconcile. We might/will end up in a situation where all backends end up in a state where progress on one is hampered due to issues with other backends (explicitly a non-goal for IREE). In all these cases the preferred way forward is

Adapt/generalize upstream implementation, and/or
Adapt IREE to allow using upstream implementation.

Least desirable is

Copy/mimic implementation from upstream to get around representational issue due to expediency (we are explicitly telling other folks to not do this, so us doing it is a bit hypocritical).

Having raised the issue, I am not going to delve into implementation aspects here. I really hope we can avoid such situations with better ordering of tasks.

The logic duplicated is ~50 lines of code and we have been doing this kind of work in IREE that we later generalize and upstream in the past. Therefore I assume your concern goes much beyond just the scope of this PR. I think we need to rework the expectations we have with regard to the work going in IREE. It sounds like you have serious concerns about the state of the backend. Let's solve that offline so that we don't bump into that at every PR.

Sounds good. Thats why I removed my blocker. I am not saying there is a dire need to fix here. Its more about a death by a thousand cuts (50 lines of code here, 100 lines of code there... these add up). Mostly looking to nip it in the bud. Happy to discuss offline.


use yarn

use yarn to make accurate dependency management.
@Romakita

Coverage remained the same at 99.045% when pulling 971818af205dcb38a0a93f1de9b1ab39dd31dc8c on use-yarn into fae5de269e395f3ece8051eae61b6a07ae934c24 on master.


Confusion in the paper [FastMoE: A Fast Mixture-of-Expert Training System]

Dear authors,
I like your project and find it is very useful. I am reading your paper and trying to catch some basic concepts in MOE.
However, I have some confusion in the paper.

Figure 4. should input 5 be sent to expert 2, according to the gate output? In the paper, it is sent to the expert 0.
Page 6, you mentioned the load balance problem. Was it solved in this project? or it is inherent in the model parallelism.

Sorry for the mistake. It should be sent to expert 0, or the last number of the gate output should be 2.
We have introduced GShard and Switch's policy in FastMoE v0.2, which provides better load balance. The gate API is also open to developers to develop customized balanced gate modules.


[WIP] Update gate.control() to return AnnotatedOperation

Summary
Details and comments

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Warning: This coverage report may be inaccurate.
We've detected an issue with your CI configuration that might affect the accuracy of this pull request's coverage report.
To ensure accuracy in future PRs, please see these guidelines.
A quick fix for this PR: rebase it; your next report should be accurate.

12 of 17 (70.59%)  changed or added relevant lines in 6 files are covered.
92 unchanged lines in 4 files lost coverage.
Overall coverage increased (+0.01%) to 87.527%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

qiskit/circuit/annotated_operation.py
2
3
66.67%

qiskit/circuit/gate.py
4
5
80.0%

qiskit/circuit/library/generalized_gates/mcmt.py
1
2
50.0%

qiskit/transpiler/passes/synthesis/high_level_synthesis.py
3
5
60.0%

Files with Coverage Reduction
New Missed Lines
%

qiskit/transpiler/passes/basis/basis_translator.py
2
98.32%

qiskit/circuit/bit.py
3
91.49%

crates/qasm2/src/lex.rs
4
91.92%

qiskit/circuit/quantumcircuit.py
83
91.44%

Totals

Change from base Build<PHONE_NUMBER>:
0.01%

Covered Lines:
59149

Relevant Lines:
67578

💛  - Coveralls

These are really great questions.
Longer-term I would indeed like to see Gate.control, QuantumCircuit.control and UnitaryGate.control return AnnotatedOperations by default.
I have now run local tests to see what would break if we were to set annotated=True in the three methods above, and there are 76 failing tests (a bit more than I have hoped). On a quick inspection:

Some of these are related to QPY and should hopefully be fixed by #11505.
Some of these are related to visualization. Most of the visualization problems were solved in #11202 and #11466, but apparently there are still some corner-cases remaining.
Many of these are related to testing controlled gates, and fail because the returned object has no definition, label, inverse or is not an instance of ControlledGate. Though the inverse would be fixed by the follow-up PR on inverse gates. A simple fix would be to change the tests for controlled gates that explicitly mention label, definition or inverse to call control with annotated=False.
And there might be a few more problems (out of these 76 ones). I will take a deeper look.

I am up to making this breaking change for Qiskit 1.0 provided that we can quickly resolve all the problems above.
Regarding controlled gates with defined controlled variants. At the moment I can't think of a convincing use-case when having an X-gate with a control modifier representing a single control might be better than just having a CX-gate (or an MCX-gate in case of multiple controls), however I do agree that this possibly opens a door to some optimizations.
Update: after thinking about the above, I think that always returning a CX/MCX-gate for X.control() might indeed be a better option, as this does not prevent the possibility of a transpiler pass that translates MCX-gates to AnnotatedGates (if the goal is to maybe combine gates with similar control modifiers).

I have taken a close look at all tests that would fail if we changed the default to control(annotated=True).
As I wrote before, most of the failing tests pertain to testing controlled gates, as annotated operations do not have methods label or definition. These tests would be easy to adapt.
There are failing tests related to the Unroller pass as it does not support circuits with AnnotatedOperations (as these have no definition), however the pass is being deprecated, so these tests can probably be simply removed.
There are some failing visualization tests: thanks to #11202 the annotated operations with control modifiers are printed very nicely and quite similarly to controlled gates, but still there are some minor differences in circuit_test_drawer: the following code
ghz_circuit = QuantumCircuit(3, name="ghz")
ghz_circuit.h(0)
ghz_circuit.cx(0, 1)
ghz_circuit.cx(1, 2)
ghz = ghz_circuit.to_gate()
cghz = ghz.control(1, ctrl_state="0")
circuit = QuantumCircuit(4)
circuit.append(cghz, [3, 1, 0, 2])

used to print
     ┌──────┐
q_0: ┤1     ├
     │      │
q_1: ┤0 ghz ├
     │      │
q_2: ┤2     ├
     └──┬───┘
q_3: ───o────

and now it's exactly the same picture except that the first letter in ghz is capitalized. There are also some difference with (not) printing parameters of the base operation.
The two remaining failing tests are test.python.circuit.test_controlled_gate.TestControlledGate.test_assign_nested_controlled_cu and test.python.circuit.test_circuit_operations.TestCircuitOperations.test_control and they point to a real problem for annotated gates over parameterized gates (and I now recall that @jakelishman mentioned at some point that this may be an issue). For example the following code
theta = Parameter("t")
qc_c = QuantumCircuit(2)
qc_c.crx(theta, 1, 0)
custom_gate = qc_c.to_gate().control()
qc = QuantumCircuit(3)
qc.append(custom_gate, [0, 1, 2])
assigned = qc.assign_parameters({theta: 0.5})

does not currently assign parameters to the base operation of an annotated operation.


Use apt-get instead of apt

We currently get a warning in the logs, when we use apt:
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

From the apt man page:

SCRIPT USAGE AND DIFFERENCES FROM OTHER APT TOOLS
All features of apt(8) are available in dedicated APT tools like apt-get(8) and apt-cache(8) as well.  apt(8) just changes the default value of some options (see apt.conf(5) and specifically the Binary scope). So you should prefer using these commands (potentially with some additional options enabled) in your scripts as they keep backward compatibility as much as possible.

This pr exchanges uses of apt with apt-get

@shahmishal Updated all nightly-main, nightly-5.5 and ci images to use apt instead of apt-get. I'm not sure what we want to do with images that are already released. My intuition would be to keep them as is. WDYT?

@swift-ci test

@swift-ci test


Add Author, Description and WorldSeed settings pt2

Part 2!
Author and description for /tc worldinfo console command and WorldSeed for Forge world creation menu.
Now if only I could figure out how to add more than 1 commit to a fork before creating a pull request, doh ><. More changes incoming..

Merged!


Docs: Autofocusing on search field in search dialog

Description

When clicking on the search icon in the upper right corner of the documentation start page, the input field in the opening dialog is now autofocused. The field not being autofocused is sometimes annoying when you already start typing a search query, but you forgot to click on the input field. Solves #8012
How Has This Been Tested?

I built the Docs.Server project opened the dialog and the field was autofocused
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

https://github.com/MudBlazor/MudBlazor/assets/76198980/67c7cdc4-5a96-4084-b828-e6b6e0028691
Checklist:

[x] The PR is submitted to the correct branch (dev).
[x] My code follows the code style of this project.
[ ] I've added relevant tests.

Thanks @LuisThe0ne 👍