Parameter Content Schemas

Initial Checks

[X] I have searched Google & GitHub for similar requests and couldn't find anything
[X] I have read the docs and still think this feature is missing

Description
Current version requires parameters to have either have a schema target or described schema. See https://github.com/commonism/aiopenapi3/blob/55b200da7bb3c8b39ee2e71c5a15a25acef81962/aiopenapi3/openapi.py#L500-L504
This does not follow the secondary prescribed serialization strategy for parameters. See https://spec.openapis.org/oas/latest.html#fixed-fields-9

media type mappings for parameters is not implemented.
try
                    for parameter in op.parameters + obj.parameters:
                        if parameter.schema_:
                            if isinstance(parameter.schema_, ReferenceBase):
                                schema = parameter.schema_._target
                            else:
                                schema = parameter.schema_
                            name = schema._get_identity("I2", f"{path}.{m}.{parameter.name}")
                            byname[name] = schema
                        else:
                            for key, mediatype in parameter.content.items():
                                schema = mediatype.schema_
                                name = schema._get_identity("I2", f"{path}.{m}.{parameter.name}.{key}")
                                byname[name] = schema

to get over the None access.
Encoding of the parameter won't work either.
If possible -requires some unused fields in the https://spec.openapis.org/oas/v3.1.0#mediaTypeObject and content type application/json- use a plugin to change the document, move the schema from the media type object to the parameter.
I'll investigate how to address this properly.
My current understanding is the content type has to be aligned with the request body content type, and you can have multiple parameters with different distinct content-type,media type object mappings.
If you want to get into this …
https://github.com/commonism/aiopenapi3/blob/55b200da7bb3c8b39ee2e71c5a15a25acef81962/aiopenapi3/v30/glue.py#L304
https://github.com/commonism/aiopenapi3/blob/55b200da7bb3c8b39ee2e71c5a15a25acef81962/aiopenapi3/v30/parameter.py#L45
https://github.com/commonism/aiopenapi3/blob/55b200da7bb3c8b39ee2e71c5a15a25acef81962/aiopenapi3/v30/glue.py#L335
Can you provide an example section of your description document featuring this?

Yeah, the work around for this isn't unmanageable. It's just more gnarliness from the Microsoft Graph API:
{
  "paths": {
    ...
    "/deviceManagement/getRoleScopeTagsByIds(ids={ids})": {
      "description": "Provides operations to call the getRoleScopeTagsByIds method.",
      "get": {
        "tags": ["deviceManagement.Functions"],
        "summary": "Invoke function getRoleScopeTagsByIds",
        "operationId": "deviceManagement.getRoleScopeTagsByIds",
        "parameters": [
          {
            "name": "ids",
            "in": "path",
            "description": "Usage: ids={ids}",
            "required": true,
            "content": {
              "application/json": {
                "schema": { "type": "array", "items": { "type": "string" } }
              }
            }
          },
        }, ...
      ], ...
    }, ...
  }, ...
}

This is a valid parameter with media type and additional header specified as encoding.
The additional header can specify another header.
  parameters:
    EmptyFormQuery:
      in: query
      name: empty
      required: true
      content:
        "application/json":
          schema:
            type: number
          encoding:
            "*":
              style: form
              explode: false
              headers:
                X-hrm:
                  description: hrm header
                  content:
                    "*":
                      schema:
                        type: string
                        format: date-time
                      encoding:
                        "application/x-www-form-urlencoded":
                          style: form

As yours can be remapped without loosing information, I'd go with it as a start.
Doing this properly won't be as easy/fast/…
When doing this as plugin - after Cull.

Yep, that's why I put this under the feature requests. I considered putting under issues since it's a deviation from the OpenAPI spec, but it's optional, seems to be a rarity, and is going to take some effort to implement.
I've got my work around, but wanted to document this.


High CPU usage if there is no Internet connection

Hi!
 It seems the plugin can cause this. When I disable the plugin, CPU/disk usage goes down. Here is a snapshot created with Yourkit 2016.2.
It is reproducible both in IDEA and Rider on Windows and MacOS.

Thanks for reporting.  Will investigate.

Fixed in current release 1.119.0


Link to the page for managing service principals as admins?

At first glance, the documentation seems to be missing the steps for adding service principals as server admins, though it is covered over in How-To / Server / Add a service principal to the server administrator role; a link to said page, maybe in the 'When adding a security group, use..' paragraph, would make it much clearer.

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

ID: eccbe004-2ce2-9010-92c5-c9b2718bdd69
Version Independent ID: f48b5510-b6af-0063-b02f-700c3af0bc93
Content: Manage server admins in Azure Analysis Services
Content Source: articles/analysis-services/analysis-services-server-admins.md
Service: azure-analysis-services
GitHub Login: @Minewiskan
Microsoft Alias: owend

@kensmith-li Thanks for the feedback!
I have assigned the issue to the content author for further review and update the doc as appropriate.

#in-progress

Agreed. Not sure why there wasn't a link there. There is now.
Thanks for letting me know.
#please-close


Support regex matching for HTTP header

Currently, only the exact matching is supported for HTTP header.
https://github.com/kubernetes-sigs/service-apis/blob/31cbedd591ab43d2750ee1dd1f151b13f95dc1bd/api/v1alpha1/httproute_types.go#L91-L93
Therefore, I would like to propose support of regex matching on HTTP header.
If the regex matching is supported here, it would be very helpful to greatly increase flexibility.

xref this doc for add'l use case details.

@danehans The doc is restricted. Can you open it up to the world?

If the regex matching is supported here, it would be very helpful to greatly increase flexibility.

Are you looking for regex matching on the header value or header key or both?

Oh. the regex matching for the header value works for me :)

@hbagdi you need to join group https://groups.google.com/g/knative-users to get the permission for access the doc.

HeaderMatchType of "ImplementationSpecific" can now achieve this.
Given the variety of regex engines that exist in implementations, it is unlikely that this will make into the core API.
Please re-open if needed.
/close

x matching for the header value

is there an example that can show how regex matching works for the header value? Does the expression below work for all the headers with name "Sec-WebSocket-Protocol" and value start with "test"?
headers:
- type: RegularExpression
name: Sec-WebSocket-Protocol
value: "test*"
and how about multiple values, does it work something like below?
headers:
- type: RegularExpression
name: Sec-WebSocket-Protocol
value: "test*,prod*"


Testing: Impersonate Account API

Overview

Currently, mainnet-fork capabilities are limited by not having a way to unlock accounts. We should add a method to the TestProviderAPI for unlocking accounts.

I am trying to make my tests have accounts that start off with ERC20s.
Specification
def impersonate_account(address):
    ....

def stop_impersonating_account(address):
    ....

Dependencies
Include links to any open issues that must be resolved before this feature can be implemented.
Will also require updating Hardhat plugin

What do you think of this?
def impersonate_account(address: Union[str, AddressType]) -> AddressAPI:
    """
    Returns an `AddressAPI` subclass (only for testing purposes) that the `TestProviderAPI`
    will allow to make arbitrary transactions
    """

I'm not sure if stop_impersonating_account is even needed, the variable should just go out of scope
Also curious if this should be under the ChainManager for the user-facing portion of it (since chain ends up in our fixtures, but provider does not)

Yes, I think that all makes sense and works out nicely.
So would this be a usage example?
@pytest.fixture
def my_account(accounts, chain):
    dev_account = accounts[0]
    impersonated_account = chain.impersonate_account("0xwhatever")
    impersonated_account.transfer(dev_account, "100 DAI")

How do all the cool kids fund their test accounts with DAI?
Is there a way to do this by impersonating the contract itself (I can't really think of how)?
Or is there some known "faucet" accounts that are reliable to use in tests?

How do all the cool kids fund their test accounts with DAI?

When I did it, I liked to impersonate an account I always knew would have lots of it. Or, even better, one with minting authority.

Is there a way to do this by impersonating the contract itself (I can't really think of how)?

You should be able to impersonate any contract the same as an account.
However, you can't make arbitrary self-calls like that, you'd need the ability to modify storage directly (which is also something I want to add the ability to do e.g. token.storage["balanceOf"][acct] += int(1e20))

Is it possible to make this return Union[ContractInstance, ImpersonatedAccount] where ImpersonatedAccount is an AccountAPI that does not care about signing. Reasons:

Right now, I am not sure how to get the ContractType from an impersonated contract (unless I use etherscan or something).

I can't use the transfer() method unless it is the AccountAPI (not AddressAPI). I believe impersonated accounts just simply don't requiring signing? So we can send raw transactions without needing sign or can put whatever there?

I am really not sure if what I am trying to do is possible! I just want some DAIIIIIII. I was going to impersonate vitalik and fund my test accounts that way.

Is it possible to make this return Union[ContractInstance, ImpersonatedAccount] where ImpersonatedAccount is an AccountAPI that does not care about signing.

I don't think we'd need that to return ContractInstance at all, you would just create a contract variable at that address instead.

Right now, I am not sure how to get the ContractType from an impersonated contract (unless I use etherscan or something).

This wouldn't be the use case for it, you should load a contract type at that address instead. ImpersonatedAccount is just there to let you send assets from that account, or make other types of calls for testing purposes.

I can't use the transfer() method unless it is the AccountAPI (not AddressAPI). I believe impersonated accounts just simply don't requiring signing? So we can send raw transactions without needing sign or can put whatever there?

Yep! That's how it would work!

I am really not sure if what I am trying to do is possible! I just want some DAIIIIIII. I was going to impersonate vitalik and fund my test accounts that way.

Honestly, the easiest way is probably to mint yourself some Dai by finding a caller that is auth'd:

I think the Vat contract is one such auth'd contract: 0x35D1b3F3D7966A1DFe207aa4514C12a259A0492B. So, you would impersonate Vat and mint yourself however much Dai you wanted.
Note: I found this by looking for ERC20 Transfer events coming from 0x0 account, and then got a transaction trace of the vent to see what address triggered the transaction, something eventually our Query system can handle?

Overview

Currently, mainnet-fork capabilities are limited by not having a way to unlock accounts. We should add a method to the TestProviderAPI for unlocking accounts.

I am trying to make my tests have accounts that start off with ERC20s.
Specification
def impersonate_account(address):
    ....

Also have config-driven impersonated accounts, something like :
test:
    unlocked_accounts:
      - name: DaiHolder
         address: 0x12..45

Also, change the accounts test fixture to include key-accessible unlocked accounts:
def test_accounts(accounts):
    acct = accounts[0]
    dai_acct = accounts["DaiHolder"]

Dependencies
Include links to any open issues that must be resolved before this feature can be implemented.
Will also require updating Hardhat plugin

Also have config-driven impersonated accounts, something like :
test:
    unlocked_accounts:
      - name: DaiHolder
         address: 0x12..45

Also, change the accounts test fixture to include key-accessible unlocked accounts:
def test_accounts(accounts):
    acct = accounts[0]
    dai_acct = accounts["DaiHolder"]

I think this type of feature fits better with #306


upgrade questionnaire-to-survey package

see latest version changes  https://github.com/asbi-cds-tools/questionnaire-to-survey/pull/8

@achen2401  what do you make of https://github.com/asbi-cds-tools/questionnaire-to-survey/pull/8/files#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5R79
"As of Version 2.3.0, Questionnaire to Survey exports a function for converting the output of SurveyJS into QuestionnaireResponse resources." ?
Also, it looks like he doesn't have 2.3.0 (this new version?) at yarn yet?
https://registry.yarnpkg.com/questionnaire-to-survey

@achen2401 what do you make of https://github.com/asbi-cds-tools/questionnaire-to-survey/pull/8/files#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5R79
"As of Version 2.3.0, Questionnaire to Survey exports a function for converting the output of SurveyJS into QuestionnaireResponse resources." ?
Also, it looks like he doesn't have 2.3.0 (this new version?) at yarn yet? https://registry.yarnpkg.com/questionnaire-to-survey

what do you make of https://github.com/asbi-cds-tools/questionnaire-to-survey/pull/8/files#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5R79
"As of Version 2.3.0, Questionnaire to Survey exports a function for converting the output of SurveyJS into QuestionnaireResponse resources." ?

From what I can tell, the new function responser works similar to what is in the codebase here  except it is now a standalone function.
Yeah, doesn't look like 2.3.0 is in the yarn package manager.   I guess I will check back when that is available.  Making this a draft PR for now


ZXingScannerFragment slow performance in tabs

My app has three tabs, and one of the tabs is the QR code scanner. All the tab headers remains at the top.
The problem is that when I swipe between the tabs, each tab has its own fragment, it is slow to render the QR Scanner tab.
I am using a framelayout which is replaced by ZXingScannerFragment for the scanner tab.
Is this the right way or right component to do it?
Does anyone know any similar kind of app setup in Github?
Thank you very much.

Is someone else dealing with this? Serious problem.

Thanks for reporting this issue!  Unforunately it took me way too long to respond 😭.  Sorry, I apologize!  Recently the source code for this project was completely refactored to modernize it.  Many PR's were included in this effort, and many bugs were hopefully fixed.  Please try out the latest 3.x series of NuGet packages (currently in prerelease).  To try and make the project more maintainable in my spare time going forward, I've decided to close all existing issues to start with a clean slate.  If you're still experiencing this issue on the newest version, please open a new issue with as much detail as possible.  Thank you for your patience and understanding!  Happy scanning!


Quick find bar - sometimes clearing the text box doesn't clear the error background

Type something in the quick find bar, which doesn't match anything. The background of the text box changes to QuickFind.ErrorBack color. Clear the search query using Backspace, if after removing some characters some matches are found, the error background changes back to normal. But if even the first character of the search query doesn't match anything, the error background stays even when the search box is now empty. Same happens when clearing it using Ctrl-A then Delete, error background and "no matches found" stays. I think if the quick find box normally updates live while typing, it should also clear while deleting. So with an empty search box, the quick find bar shouldn't show "no matches found" and error background

Should be fixed now.

I don't see it fixed, trying with the last dev build. And noticed an extra bug (I believe I've seen same or similar in the output panel when using the "clear results" button).

Open a new blank document
Write "message"
Ctrl-F, type "zzz", nothing found, observe "ErrorBack" background color
Use backspace to clear "zzz", still have error bg.
Type "ssa" - get matching "ssa" selected in the editor. Type "z" after "ssa" (result is "ssaz"), error bg appears. use Ctrl-A to select the whole search text, then Del or Backspace to clear the search box. Error bg still there.
Type "ss" - get matching "ss" selected in the editor. Press backspace once, editor shows "s" selected. Press backspace another time, nothing in search box now, but editor still shows that "s" selected (and "Showing results 1 of 2." in the quick find box status).

Ok with the latest dev build most of the problems are gone, only one remains, I'll post as separate issue then.


Inception-V3 model

Thanks for the great work. I am reading your recent papers on Arxiv, and you used Inception-V3 network for better performance. I was just wondering, for Inception-V3, the input size requirement is 299x299. So may you explain more on how did you pre-process the video frames? Thanks a lot.
Specifically, like your multi-scale cropping method. Before, you scale the image to 256x340, then scale ratio is set to [1, 0.875, 0.75, 0.66], which means the image size is [256, 224, 180, 158], then resize to 224x224. Now if the input size is 299x299, how do you do the multi-scale cropping in your experiments. Thanks a lot.
Another side question is, in data_transformer.cpp line 93 here I don't quite get it why it is less than 3, and why 3? Thank you very much for your help.
abs(crop_h - net_input_height) < 3
crop_w - net_input_width) < 3
Thanks a lot.

Multi-scale cropping does not rely on the network input size. The cropped images will finally be resized to fit the network's input size.
That 3 used to save some corner case handling when crop_h is close to raw image size. You can remove it if needed.


Add L1NormViewAsReal Functional

The L1NormViewAsReal Functional from #295

The meaning of a complex weight is slightly different here (mentioned in the docstring)
A complex weight will also be viewed-as-R2 and element-wise multiplication is performed.
This felt more natural in the context of view-as-R2 than complex multiplication and greatly simplified the code (To be honest, I am not 100% sure what the prox would be for a complex weight otherwise)


feat: Support newer API namespace for open-telemetry/api >= 1.0.0beta10

Closes https://github.com/open-telemetry/opentelemetry-php/issues/1056
This pull request resolves undefined class references caused by 1.0.0beta10 release including moving classes in OpenTelemetry\API\Common to OpenTelemetry\API.

Oh, just superseded by #172 ?

Thankyou for finding and fixing this so quickly, @siketyan
I've released new versions of the packages that you fixed.


Validation of local package does not work on Windows

Hello,
I've got this issue when I try to validate a local package :
(env) D:\dev\datapackagebug>python validation.py
Traceback (most recent call last):
  File "validation.py", line 4, in <module>
    dp.validate()
  File "D:\dev\datapackagebug\env\lib\site-packages\datapackage\datapackage.py",
 line 230, in validate
    self.schema.validate(self.to_dict())
  File "D:\dev\datapackagebug\env\lib\site-packages\datapackage\schema.py", line
 54, in validate
    self._validator.validate(data)
  File "D:\dev\datapackagebug\env\lib\site-packages\jsonschema\validators.py", l
ine 122, in validate
    for error in self.iter_errors(*args, **kwargs):
  File "D:\dev\datapackagebug\env\lib\site-packages\jsonschema\validators.py", l
ine 98, in iter_errors
    for error in errors:
  File "D:\dev\datapackagebug\env\lib\site-packages\jsonschema\_validators.py",
line 291, in properties_draft4
    schema_path=property,
  File "D:\dev\datapackagebug\env\lib\site-packages\jsonschema\validators.py", l
ine 114, in descend
    for error in self.iter_errors(instance, schema):
  File "D:\dev\datapackagebug\env\lib\site-packages\jsonschema\validators.py", l
ine 98, in iter_errors
    for error in errors:
  File "D:\dev\datapackagebug\env\lib\site-packages\jsonschema\_validators.py",
line 199, in ref
    scope, resolved = validator.resolver.resolve(ref)
  File "D:\dev\datapackagebug\env\lib\site-packages\jsonschema\validators.py", l
ine 336, in resolve
    return url, self._remote_cache(url)
  File "D:\dev\datapackagebug\env\lib\site-packages\functools32\functools32.py",
 line 400, in wrapper
    result = user_function(*args, **kwds)
  File "D:\dev\datapackagebug\env\lib\site-packages\jsonschema\validators.py", l
ine 346, in resolve_from_url
    raise RefResolutionError(exc)
jsonschema.exceptions.RefResolutionError: <urlopen error [Error 2] Le fichier sp
ÚcifiÚ est introuvable: u'\\definitions.json'>

To reproduce it, create a tiny datapackage.json file :
{
  "name": "test",
  "resources": []
}

And run this python code :
import datapackage
dp = datapackage.DataPackage('datapackage.json')
dp.validate()

This code works perfectly well under linux.

Thanks for your report. This is related to #64. We need some help around Windows support, if you have some time to try and fix it, please ping me on that issue. Closing this so we can keep discussions on a single place.


Cat npm-debug.logs on failure

#280 and #294 are plagued by failures that I can't repro locally.  Dump every npm-debug.log in the monorepo to stdout so they're available in the travis logs.

Here's a build that includes the result https://travis-ci.org/redfin/react-server/builds/139049381

Awesome.


Ingress

📚 Context
The Ingress domain name uses the release name pattern
✔ Solution
We should make it independant from the release name
🎯 Definition of Done
Define the domain/subsomain separately.

It could use the release name as default, and allow to be ovewritten.
The same we have with subDomain.


Added example for sending mail through mailgun

Hi @lakshitaverma
This is a pretty good feature, thank you.
I think it would be better if the MailGun client is injected to the service, instead of instantiating it on the SendEmail method.
By doing that way, we'll able to change from Email Provider to any other with the least amount of changes, and will be easier to mock for unit tests.
Here is what I mean
src/loaders/dependencyInjector.ts
import * as mailgun from 'mailgun';
import config from '../config'
...
Container.set('emailClient', mailgun({ apiKey: config.emails.apiKey, domain: config.emails.domain }))
...

@Service()
export default class MailerService {
 constructor(
  @Inject('emailClient') private emailClient,
  ) {
    ...
  }
  public SendWelcomeEmail(email) {
   ...
   this.emailClient.messages().send(data)
  }
}

What do you think ?

Yes, good idea. Implemented it. Have a look.


Baskerville requires TensorFlow 2.15, but Borzoi requires TensorFlow 2.12. How should I install them?

Hi, we updated to tensorflow 2.15. I believe everything from 2.12-2.15 will work fine.


Home page updates

Add "." between react and framework in logos. The period should be in the same color as the library color. This will be consistent across libraries.

Change tagline to
“Search, compare, and discover top React libraries and community driven resources in React.”
Change three panels (currently Browse, Search, Compare) to Search, Compare, Discover
Make all three linked to https://react.framework.dev/categories/libraries
(this will get updated later after a design update)

This is not correct branding-wise. We don't want that period.


Front-end Build system

Everytime we deploy, a good part of our users (even in the team, actually ;)) complains it's broken.
We need to have a build system that allows us to

[ ] minify
[ ] concatenate
[ ] Version the ressources so that cache is refreshed

I'd go with grunt since we already have it used, but open for suggestions as by experience it can get messy (no pipelines). It must work with our actual AWS/CircleCI workflow (probably executed by CircleCI then)

We can also generate our CSS from LESS at build time, instead of through hapi.
I'll throw my vote in for gulp as a build system.

min & concat can be both js & css :))

a grunt or gulp task would be easily added to the build procedure on circle before deployment.
Id also say use grunt since we already use it and dont really want to have people install both

@DanielBrierton Can we close this one? :)

@Wardormeur Whoops, meant to respond last week. Yes, yes we can.


infra::IntrusiveList<>(and others) wrongly accept temporary references when adding elements

The documentation states: "Another approach for storing elements in a container is to not allocate additional storage for an object, but to make the user of a container responsible for storage allocation. [...] For instance, objects used in an infra::IntrusiveForwardList each have a next pointer, so that when the container keeps track of its first element it can enumerate all its elements by following the next pointer.".
To me, this implies you must use a non-temporary argument whenever adding it to any type of intrusive container.
To my surprise, the following code compiles. It does not work, however, resulting in a failing test:
TEST(IntrusiveListTest, Whoops)
{
    infra::IntrusiveList<ListInt> list;
    list.push_back({3});
    EXPECT_TRUE(list.has_element(3));
}

The same holds for the IntrusiveForwardList<>, which causes a segfault on my system (gcc version 10.2.1 20210110 (Debian 10.2.1-6)):
TEST(IntrusiveForwardListTest, Whoops)
{
    infra::IntrusiveForwardList<ForwardListInt> list;
    list.insert_after(list.begin(), {1});
    EXPECT_TRUE(list.has_element(1));
}

(I have not checked the other intrusive containers)
I was surprised to find that both push_back and insert_after take a const_reference type for their value argument. It does explain why the code compiles. I would argue this is wrong, though: they need to modify the argument due to the intrusive-ness of the container. It also explains why there are so many const_cast-s in the container implementation, which is rarely a good sign.
Thus, I'd recommend not using const_reference for functions that modify the element. This would cause the code above not to compile, which feels like a much better approach than using freed storage.

Hi Rink, thanks for your detailed issue report. We will look into it as soon as possible.


maths : add TAU constants and rework code

Expected Behavior
Use a constant for PI * 2, i.e. TAU
https://tauday.com/tau-manifesto
Actual Behavior
There are many many calculations of PI * 2 in the code.


ENH : adding parallel implementations of all_pairs_ algos

Please do "Squash and merge" while merging this PR
Added the following :

all_pairs_dijkstra
all_pairs_dijkstra_path_length
all_pairs_dijkstra_path
all_pairs_bellman_ford_path_length
all_pairs_shortest_path
all_pairs_shortest_path_length - no speedups(the standard sequential implementation is already really fast, and even when the graph size was increased till 4000 nodes, there were negligible speedups, and it only took a minute or 2 to generate its heatmap)
all_pairs_node_connectivity1
approximate_all_pairs_node_connectivity1
all_pairs_all_shortest_paths

[1] here, default chunking means having chunks of at most 10 nodes, because otherwise, it was taking too long with bigger node_chunks; and I also reduced the number of nodes while timing, but the speedups are pretty consistent(i.e. around 3). This heatmap alone took 2.5 hrs, and ran successfully after several tries. Also no heatmap for approximate_all_pairs_node_connectivity because for a random graph, it will result in the same heatmap as all_pairs_node_connectivity

Tests / test (macos-latest, 3.11) is running for more than 4 hrs. It is stuck at:
algorithms/centrality/tests/test_group.py ........................       [ 50%]

That happened to me yesterday too.  I don’ think it has anything to do with the backend, but I’m not sure.

Where does this PR stand? Is there more to do here?
Do you feel the improvements here are what you expect -- or are there other questions/issues you want to explore with this PR?

I think we can merge this. The only algo not showing any speedups is all_pairs_shortest_path_length and its sequential implementation is already really fast. But, we should think about how to handle such functions in the whole of nx-parallel, i.e the functions that don’t show any speedups for the general random graphs we use in the current timing script and/or whose sequential networkx implementation is already really fast(like number_of_isolates, all_pairs_shortest_path_length, global_reaching_centrality and local_reaching_centrality(https://github.com/networkx/nx-parallel/pull/44), etc.). For some such algos setting the minimum chunk size to be really large might help(this didn't work for all_pairs_shortest_path_length), but then the input graph should also be really big. Just a thought, but having something like should_run = True only when the graph is really big might be helpful.


getSymbols throws when using roundingIncrement >= 2

Provide a general summary of the issue here
When a roundingIncrement >= 2 is used, getSymbols throws when creating symbolFormatter:
https://github.com/adobe/react-spectrum/blob/bebc9764ab07ac86f54ce0c2982da5baa17cbb50/packages/%40internationalized/number/src/NumberParser.ts#L258
🤔 Expected Behavior?
It should not allow the NumberFormat constructor to throw if the user's options are correct.
😯 Current Behavior
The constructor throws because the options are incompatible, as the function forcefully overrides minimumSignificantDigits and maximumSignificantDigits.
The error thrown (in Chrome) is:
Uncaught TypeError: RoundingType is not fractionDigits

Which seems to be a V8 internal error (?).
💁 Possible Solution
Setting roundingIncrement to undefined solves the issue, but I'm unsure if it has any side effects or causes any other issues. I've tried running the Jest test suite locally and the results are fine.
I've also tried spreading intlOptions at the end, so that minimumSignificantDigits and maximumSignificantDigits can get overridden, but the can still get all plural literals with minimum significant digits test fails when doing that.
🔦 Context
No response
🖥 Steps to Reproduce
https://stackblitz.com/edit/vitejs-vite-ku6pdw?file=src%2FApp.tsx
Change roundingIncrement to 2, 5, or some other allowed value in src/App.tsx.
Version
main
What browsers are you seeing the problem on?
Chrome
If other, please specify.
No response
What operating system are you using?
macOS
🧢 Your Company/Team
No response
🕷 Tracking Issue
No response

Thanks for the issue. It would appear that those values (roundingIcrement etc) were added recently to Chrome and didn't make it into Node 18, which is what we run our tests against right now.
I think that it's fine to restore those to default values for the line which is blowing up because that's a function to find all possible symbols which might appear in a formatted number, which doesn't really matter if we set rounding. Finding a few extra symbols won't hurt anything.


hang after pressing 'q' from deploy status screen

after waiting for a while in the deploy status screen after filing #72, I pressed 'q' to exit, and the urwid UI cleared back to the prompt, but the program hasn't exited.
if I ^C, I get this traceback:

^CError in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/usr/lib/python3.5/concurrent/futures/thread.py", line 39, in _python_exit
    t.join()
  File "/usr/lib/python3.5/threading.py", line 1054, in join
    self._wait_for_tstate_lock()
  File "/usr/lib/python3.5/threading.py", line 1070, in _wait_for_tstate_lock
    elif lock.acquire(block, timeout):
KeyboardInterrupt

We need to be able to force kill a juju deploy/bootstrap if someone hits 'q' otherwise this future waits until those operations are done


ARM emulator keeps on crashing

Flutter Doctor
[✓] Flutter (on Linux, channel alpha)
• Flutter at /home/nb/flutter
• Framework revision 9a0a0d9903 (4 weeks ago), engine revision f8d80c4617
[✓] Android toolchain - develop for Android devices (Android SDK 24.0.2)
• Android SDK at /home/nb/Android/Sdk
• Platform android-24, build-tools 24.0.2
• Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
[✓] Atom - a lightweight development environment for Flutter
• flutter plugin version 0.2.4
• dartlang plugin version 0.6.38
flutter run -v
6 ms • /home/nb/Android/Sdk/platform-tools/adb devices -l
0 ms • Exit code 0 from: /home/nb/Android/Sdk/platform-tools/adb devices -l
14 ms • List of devices attached
emulator-5554          device product:sdk_phone_armv7 model:sdk_phone_armv7 device:generic
523 ms • /home/nb/Android/Sdk/platform-tools/adb -s emulator-5554 shell getprop
5 ms • Running build command.
0 ms • APK up to date; skipping build step.
2 ms • Stopping app 'app.apk' on sdk phone armv7.
9 ms • /home/nb/Android/Sdk/platform-tools/adb -s emulator-5554 shell am force-stop com.yourcompany.myfluttapp
0 ms • Running install command.
3 ms • /home/nb/Android/Sdk/platform-tools/adb version
0 ms • Exit code 0 from: /home/nb/Android/Sdk/platform-tools/adb version
1 ms • Android Debug Bridge version 1.0.36
Revision 8f855a3d9b35-android
3 ms • /home/nb/Android/Sdk/platform-tools/adb start-server
0 ms • Exit code 0 from: /home/nb/Android/Sdk/platform-tools/adb start-server
37553 ms • /home/nb/Android/Sdk/platform-tools/adb -s emulator-5554 install -r build/app.apk
0 ms • Exit code 0 from: /home/nb/Android/Sdk/platform-tools/adb -s emulator-5554 install -r build/app.apk
36 ms • [  0%] /data/local/tmp/app.apk
[  1%] /data/local/tmp/app.apk
[  2%] /data/local/tmp/app.apk
[  2%] /data/local/tmp/app.apk
[  3%] /data/local/tmp/app.apk
[  4%] /data/local/tmp/app.apk
[  5%] /data/local/tmp/app.apk
[  5%] /data/local/tmp/app.apk
[  6%] /data/local/tmp/app.apk
[  7%] /data/local/tmp/app.apk
[  7%] /data/local/tmp/app.apk
[  8%] /data/local/tmp/app.apk
[  9%] /data/local/tmp/app.apk
[ 10%] /data/local/tmp/app.apk
[ 10%] /data/local/tmp/app.apk
[ 11%] /data/local/tmp/app.apk
[ 12%] /data/local/tmp/app.apk
[ 12%] /data/local/tmp/app.apk
[ 13%] /data/local/tmp/app.apk
[ 14%] /data/local/tmp/app.apk
[ 15%] /data/local/tmp/app.apk
[ 15%] /data/local/tmp/app.apk
[ 16%] /data/local/tmp/app.apk
[ 17%] /data/local/tmp/app.apk
[ 18%] /data/local/tmp/app.apk
[ 18%] /data/local/tmp/app.apk
[ 19%] /data/local/tmp/app.apk
[ 20%] /data/local/tmp/app.apk
[ 20%] /data/local/tmp/app.apk
[ 21%] /data/local/tmp/app.apk
[ 22%] /data/local/tmp/app.apk
[ 23%] /data/local/tmp/app.apk
[ 23%] /data/local/tmp/app.apk
[ 24%] /data/local/tmp/app.apk
[ 25%] /data/local/tmp/app.apk
[ 25%] /data/local/tmp/app.apk
[ 26%] /data/local/tmp/app.apk
[ 27%] /data/local/tmp/app.apk
[ 28%] /data/local/tmp/app.apk
[ 28%] /data/local/tmp/app.apk
[ 29%] /data/local/tmp/app.apk
[ 30%] /data/local/tmp/app.apk
[ 30%] /data/local/tmp/app.apk
[ 31%] /data/local/tmp/app.apk
[ 32%] /data/local/tmp/app.apk
[ 33%] /data/local/tmp/app.apk
[ 33%] /data/local/tmp/app.apk
[ 34%] /data/local/tmp/app.apk
[ 35%] /data/local/tmp/app.apk
[ 36%] /data/local/tmp/app.apk
[ 36%] /data/local/tmp/app.apk
[ 37%] /data/local/tmp/app.apk
[ 38%] /data/local/tmp/app.apk
[ 38%] /data/local/tmp/app.apk
[ 39%] /data/local/tmp/app.apk
[ 40%] /data/local/tmp/app.apk
[ 41%] /data/local/tmp/app.apk
[ 41%] /data/local/tmp/app.apk
[ 42%] /data/local/tmp/app.apk
[ 43%] /data/local/tmp/app.apk
[ 43%] /data/local/tmp/app.apk
[ 44%] /data/local/tmp/app.apk
[ 45%] /data/local/tmp/app.apk
[ 46%] /data/local/tmp/app.apk
[ 46%] /data/local/tmp/app.apk
[ 47%] /data/local/tmp/app.apk
[ 48%] /data/local/tmp/app.apk
[ 48%] /data/local/tmp/app.apk
[ 49%] /data/local/tmp/app.apk
[ 50%] /data/local/tmp/app.apk
[ 51%] /data/local/tmp/app.apk
[ 51%] /data/local/tmp/app.apk
[ 52%] /data/local/tmp/app.apk
[ 53%] /data/local/tmp/app.apk
[ 54%] /data/local/tmp/app.apk
[ 54%] /data/local/tmp/app.apk
[ 55%] /data/local/tmp/app.apk
[ 56%] /data/local/tmp/app.apk
[ 56%] /data/local/tmp/app.apk
[ 57%] /data/local/tmp/app.apk
[ 58%] /data/local/tmp/app.apk
[ 59%] /data/local/tmp/app.apk
[ 59%] /data/local/tmp/app.apk
[ 60%] /data/local/tmp/app.apk
[ 61%] /data/local/tmp/app.apk
[ 61%] /data/local/tmp/app.apk
[ 62%] /data/local/tmp/app.apk
[ 63%] /data/local/tmp/app.apk
[ 64%] /data/local/tmp/app.apk
[ 64%] /data/local/tmp/app.apk
[ 65%] /data/local/tmp/app.apk
[ 66%] /data/local/tmp/app.apk
[ 67%] /data/local/tmp/app.apk
[ 67%] /data/local/tmp/app.apk
[ 68%] /data/local/tmp/app.apk
[ 69%] /data/local/tmp/app.apk
[ 69%] /data/local/tmp/app.apk
[ 70%] /data/local/tmp/app.apk
[ 71%] /data/local/tmp/app.apk
[ 72%] /data/local/tmp/app.apk
[ 72%] /data/local/tmp/app.apk
[ 73%] /data/local/tmp/app.apk
[ 74%] /data/local/tmp/app.apk
[ 74%] /data/local/tmp/app.apk
[ 75%] /data/local/tmp/app.apk
[ 76%] /data/local/tmp/app.apk
[ 77%] /data/local/tmp/app.apk
[ 77%] /data/local/tmp/app.apk
[ 78%] /data/local/tmp/app.apk
[ 79%] /data/local/tmp/app.apk
[ 79%] /data/local/tmp/app.apk
[ 80%] /data/local/tmp/app.apk
[ 81%] /data/local/tmp/app.apk
[ 82%] /data/local/tmp/app.apk
[ 82%] /data/local/tmp/app.apk
[ 83%] /data/local/tmp/app.apk
[ 84%] /data/local/tmp/app.apk
[ 85%] /data/local/tmp/app.apk
[ 85%] /data/local/tmp/app.apk
[ 86%] /data/local/tmp/app.apk
[ 87%] /data/local/tmp/app.apk
[ 87%] /data/local/tmp/app.apk
[ 88%] /data/local/tmp/app.apk
[ 89%] /data/local/tmp/app.apk
[ 90%] /data/local/tmp/app.apk
[ 90%] /data/local/tmp/app.apk
[ 91%] /data/local/tmp/app.apk
[ 92%] /data/local/tmp/app.apk
[ 92%] /data/local/tmp/app.apk
[ 93%] /data/local/tmp/app.apk
[ 94%] /data/local/tmp/app.apk
[ 95%] /data/local/tmp/app.apk
[ 95%] /data/local/tmp/app.apk
[ 96%] /data/local/tmp/app.apk
[ 97%] /data/local/tmp/app.apk
[ 97%] /data/local/tmp/app.apk
[ 98%] /data/local/tmp/app.apk
[ 99%] /data/local/tmp/app.apk
[100%] /data/local/tmp/app.apk
pkg: /data/local/tmp/app.apk
Success
119 ms • /home/nb/Android/Sdk/platform-tools/adb -s emulator-5554 shell echo -n b64eab958e6baf6bba9410a7769395158e0683de > /data/local/tmp/sky.com.yourcompany.myfluttapp.sha1
4 ms • Exit code 0 from: /home/nb/Android/Sdk/platform-tools/adb -s emulator-5554 shell echo -n b64eab958e6baf6bba9410a7769395158e0683de > /data/local/tmp/sky.com.yourcompany.myfluttapp.sha1
188 ms • /home/nb/Android/Sdk/platform-tools/adb -s emulator-5554 logcat -v time -t 1
0 ms • Exit code 0 from: /home/nb/Android/Sdk/platform-tools/adb -s emulator-5554 logcat -v time -t 1
1 ms • --------- beginning of main
09-11 23:24:54.035 I/AndroidRuntime( 1497): VM exiting with result code 0.
362 ms • /home/nb/Android/Sdk/platform-tools/adb -s emulator-5554 logcat -g -T 09-11 23:24:54.035
0 ms • Exit code 0 from: /home/nb/Android/Sdk/platform-tools/adb -s emulator-5554 logcat -g -T 09-11 23:24:54.035
1 ms • main: ring buffer is 256Kb (247Kb consumed), max entry is 5120b, max payload is 4076b
system: ring buffer is 256Kb (74Kb consumed), max entry is 5120b, max payload is 4076b
crash: ring buffer is 256Kb (2Kb consumed), max entry is 5120b, max payload is 4076b
0 ms • Running lib/main.dart on sdk phone armv7...
0 ms • /home/nb/Android/Sdk/platform-tools/adb -s emulator-5554 logcat -v tag -T 09-11 23:24:54.035
4 ms • /home/nb/Android/Sdk/platform-tools/adb version
0 ms • Exit code 0 from: /home/nb/Android/Sdk/platform-tools/adb version
0 ms • Android Debug Bridge version 1.0.36
Revision 8f855a3d9b35-android
4 ms • /home/nb/Android/Sdk/platform-tools/adb start-server
4 ms • Exit code 0 from: /home/nb/Android/Sdk/platform-tools/adb start-server
315 ms • /home/nb/flutter/bin/cache/artifacts/engine/linux-x64/sky_snapshot --packages=/home/nb/Desktop/myfluttapp/.packages --snapshot=build/snapshot_blob.bin --depfile=build/snapshot_blob.bin.d --build-output=build/snapshot_blob.bin /home/nb/Desktop/myfluttapp/lib/main.dart
401 ms • --------- beginning of main
438 ms • Building build/app.flx
7 ms • which zip
22 ms • Encoding zip file to build/app.flx
181 ms • zip -q /home/nb/Desktop/myfluttapp/build/app.flx fonts/MaterialIcons-Regular.ttf AssetManifest.json FontManifest.json LICENSE snapshot_blob.bin
0 ms • Exit code 0 from: zip -q /home/nb/Desktop/myfluttapp/build/app.flx fonts/MaterialIcons-Regular.ttf AssetManifest.json FontManifest.json LICENSE snapshot_blob.bin
0 ms • Built build/app.flx.
2 ms • Starting bundle for sdk phone armv7.
0 ms • sdk phone armv7 startBundle
918 ms • /home/nb/Android/Sdk/platform-tools/adb -s emulator-5554 push build/app.flx /data/local/tmp/dev.flx
0 ms • Exit code 0 from: /home/nb/Android/Sdk/platform-tools/adb -s emulator-5554 push build/app.flx /data/local/tmp/dev.flx
0 ms • [  8%] /data/local/tmp/dev.flx
[ 17%] /data/local/tmp/dev.flx
[ 26%] /data/local/tmp/dev.flx
[ 35%] /data/local/tmp/dev.flx
[ 44%] /data/local/tmp/dev.flx
[ 53%] /data/local/tmp/dev.flx
[ 62%] /data/local/tmp/dev.flx
[ 71%] /data/local/tmp/dev.flx
[ 80%] /data/local/tmp/dev.flx
[ 89%] /data/local/tmp/dev.flx
[ 98%] /data/local/tmp/dev.flx
[100%] /data/local/tmp/dev.flx
4738 ms • /home/nb/Android/Sdk/platform-tools/adb -s emulator-5554 shell am start -a android.intent.action.RUN -d /data/local/tmp/dev.flx -f 0x20000000 --ez enable-background-compilation true --ez enable-checked-mode true com.yourcompany.myfluttapp/org.domokit.sky.shell.SkyActivity
0 ms • Exit code 0 from: /home/nb/Android/Sdk/platform-tools/adb -s emulator-5554 shell am start -a android.intent.action.RUN -d /data/local/tmp/dev.flx -f 0x20000000 --ez enable-background-compilation true --ez enable-checked-mode true com.yourcompany.myfluttapp/org.domokit.sky.shell.SkyActivity
0 ms • Starting: Intent { act=android.intent.action.RUN dat=/data/local/tmp/dev.flx flg=0x20000000 cmp=com.yourcompany.myfluttapp/org.domokit.sky.shell.SkyActivity (has extras) }
7012 ms • Waiting for observatory port to be available...
21 ms • I/flutter : [INFO:GrGLUtil.cpp(211)] nullptr GLSL version string.
8 ms • I/flutter : [INFO:../../flutter/sky/shell/gpu/direct/ganesh_canvas.cc(47)] Failed to setup GL context. Aborting.
0 ms • I/flutter : [INFO:../../flutter/sky/shell/gpu/direct/ganesh_canvas.cc(48)]
0 ms • I/flutter :          Vendor: Google (Intel Open Source Technology Center)
0 ms • I/flutter :        Renderer: Android Emulator OpenGL ES Translator (Mesa DRI Intel(R) Ivybridge Mobile )
0 ms • I/flutter :         Version: 2.0 (3.0 ES
0 ms • I/flutter :  Shader Version: Unknown
0 ms • I/flutter :      Extensions: 18 Available
0 ms • I/flutter :                  ANDROID_EMU_CHECKSUM_HELPER_v1
0 ms • I/flutter :                  GL_EXT_debug_marker
1 ms • I/flutter :                  GL_OES_EGL_image
0 ms • I/flutter :                  GL_OES_EGL_image_external
0 ms • I/flutter :                  GL_OES_compressed_ETC1_RGB8_texture
0 ms • I/flutter :                  GL_OES_compressed_paletted_texture
0 ms • I/flutter :                  GL_OES_depth24
0 ms • I/flutter :                  GL_OES_depth32
0 ms • I/flutter :                  GL_OES_depth_texture
0 ms • I/flutter :                  GL_OES_element_index_uint
0 ms • I/flutter :                  GL_OES_packed_depth_stencil
0 ms • I/flutter :                  GL_OES_rgb8_rgba8
0 ms • I/flutter :                  GL_OES_texture_float
0 ms • I/flutter :                  GL_OES_texture_float_linear
0 ms • I/flutter :                  GL_OES_texture_half_float
0 ms • I/flutter :                  GL_OES_texture_half_float_linear
0 ms • I/flutter :                  GL_OES_texture_npot
0 ms • I/flutter :                  GL_OES_vertex_half_float
29 ms • I/flutter :
0 ms • E/flutter : [ERROR:rasterizer_direct.cc(59)] Could not create the GL interface
3 ms • E/flutter : [ERROR:rasterizer_direct.cc(67)] WARNING: Flutter will be unable to render to the display
7207 ms • I/flutter : [INFO:GrGLUtil.cpp(211)] nullptr GLSL version string.
7 ms • observatory port = 44288
6 ms • /home/nb/Android/Sdk/platform-tools/adb -s emulator-5554 forward tcp:8102 tcp:44288
0 ms • Exit code 0 from: /home/nb/Android/Sdk/platform-tools/adb -s emulator-5554 forward tcp:8102 tcp:44288
0 ms • Observatory listening on http://<IP_ADDRESS>:8102
1 ms • diagnostic port = 56791
4 ms • /home/nb/Android/Sdk/platform-tools/adb -s emulator-5554 forward tcp:8103 tcp:56791
0 ms • Exit code 0 from: /home/nb/Android/Sdk/platform-tools/adb -s emulator-5554 forward tcp:8103 tcp:56791
6478 ms • Diagnostic server listening on http://<IP_ADDRESS>:8103
7206 ms • Connected to service protocol on port 8102
0 ms • E/flutter : [ERROR:../../lib/tonic/logging/dart_error.cc(16)] '/home/nb/Desktop/myfluttapp/lib/main.dart': error: line 27: unexpected token 'void'
0 ms • E/flutter :   void _incrementCounter() {
0 ms • E/flutter :   ^
0 ms • E/DartVM  : ../../dart/runtime/vm/dart_api_impl.cc: 1456: error: Dart_SetStickyError expects the error to be an unhandled exception error.
0 ms • E/DartVM  : Dumping native stack trace for thread 61f
0 ms • E/DartVM  : Stack dump aborted because GetAndValidateIsolateStackBounds.
3245 ms • --------- beginning of crash

It looks like you have an error in your dart code?
0 ms • E/flutter : [ERROR:../../lib/tonic/logging/dart_error.cc(16)] '/home/nb/Desktop/myfluttapp/lib/main.dart': error: line 27: unexpected token 'void'

I'm not sure that that's causing the crash, just noting.

FYI @jason-simmons re: emulators and arm.

Note also your flutter version is 4 weeks old.  I'd try a flutter upgrade.

Also, the GL context could not be setup. Is GPU acceleration in the emulator enabled?

@eseidelGoogle  even after correcting the error the emulator still crashes and my flutter version is the latest.

@chinmaygarde @abarth mentioned over chat the other day that we now have a software backend?  Should we use that in emulators (--debug only) when no gpu is found?  Maybe with some warning?

@eseidelGoogle That's will be better. Is that ready yet?

I'm going to close this in favor of https://github.com/flutter/flutter/issues/5839.  We're actually finally adding a software backend. :)  Starting initially for iOS simulators, but once that's working should be easy to expand to Android emulators which would solve this bug.


Many packages from aur-pkgs file didnt installed by the installation script

I noticed that many packages from the aur-pkgs file didnt installed by the installatin procedure. In the past with the first scritps all were fine and all the packages were there.
Some missig packages were the nordic themes (all the nordic packages), zoom, snap-pac.
So when you login to the Arch is missing the Nodic login screen.

I see this issue too, I just get yay installed and nothing else from the 2-user.sh script.

Fixed in latest overhaul.


Packets after handshake arrive too early

Description
The problem is that packets sent after the handshake, usually as a follow-up by the client, are sent very quickly by the client, and the handshake handler can't switch to the new handler fast enough to handle the next packet in the new state.
Expected behaviour
Packets should be handled synchronously per connection, as in one connection should only be handling one packet at a time.
Details

Server version: Krypton 0.70
Java version: 17

Other information
Unsure if this affects the master branch, but it definitely affects the latest 1.19 branch version.

Fixed in 063cdd4a77ca3a3010b60d9e0e02e96890509ccf


Added skipChangeCommits support for Delta Sharing

Description
We have added a skipChangeCommits flag for Structured Streaming with Delta source (Here is the PR for Delta). This PR aims to bring parity to Delta Sharing as a streaming source. Below is the description of skipChangeCommits flag and how it differs from existing ignoreChanges flag:
Added skipChangeCommits flag to entirely skip commits that contain removeFiles in Delta Sharing source for structured streaming. The purpose for this change is to replace the current ignoreChanges flag that could result in data duplication issues when using Delta Sharing as a structured streaming source with DELETE/UPDATE/MERGE INTO operations (e.g. GDPR)
Behavior for existing ignoreChanges flag:

When there's removeFile detected in a commit, the removeFile would be ignored. And if addFile exists as well, the addFile would be processed by structured streaming.

Behavior for new skipChangeCommits flag:

When there's removeFile detected in a commit, both removeFile and addFile (if exists) would be ignored by structured streaming to prevent duplication in the sink.

We will deprecate the ignoreChanges flag once skipChangeCommits is available.
Testing
Added new tests under DeltaSharingSourceSuite, also verified that existing tests were running well.
[info] Run completed in 2 minutes, 20 seconds.
[info] Total number of tests run: 25
[info] Suites: completed 1, aborted 0
[info] Tests: succeeded 25, failed 0, canceled 0, ignored 0, pending 0
[info] All tests passed.

So this doesn't apply to CDF Streaming right?

No, it doesn't apply to CDF.


feat: data intake module

Issue #, if available: n/a
Notes
Testing
Before you submit a pull request, please make sure you have to following:

[x] Your code contains tests that cover all new code and changes
[x] All new and existing tests passed
[x] I have read the Contributing Guidelines and agree to follow the Code of Conduct)

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Also, one more comment which I have noticed in the Github workflow. Could you take the time to update this line to include the newly created Dataplane for intake component?

https://github.com/aws-solutions-library-samples/guidance-for-processing-overhead-imagery-on-aws/blob/dev/scripts/dev_destroy.sh#L43


[v3.7-branch] Bluetooth: Failures in unit tests

Bluetooth unit tests under tests/bluetooth/host/id/ either fail to build due to triggering a build assert, or fail to pass on some tests. E.g:
===================================================================
START - test_bt_id_set_adv_private_addr_fails

    Assertion failed at /__w/zephyr/zephyr/tests/bluetooth/host/id/bt_id_set_adv_own_addr/src/test_suite_invalid_inputs.c:111: bt_id_set_adv_own_addr_invalid_inputs_test_bt_id_set_adv_private_addr_fails: (err < 0 is false)
Unexpected error code '0' was returned
 at test function
 FAIL - test_bt_id_set_adv_private_addr_fails in 0.000 seconds
===================================================================

Fixed by https://github.com/zephyrproject-rtos/zephyr/pull/77580


RFC: No (opsem) Magic Boxes

Summary
Currently, the operational semantics of the type alloc::boxed::Box<T> is in dispute, but the compiler adds llvm noalias to it. To support it, the current operational semantics models have the type use a special form of the Unique (Stacked Borrows) or Active (Tree Borrows) tag, which has aliasing implications, validity implications, and also presents some unique complications in the model and in improvements to the type (e.g. Custom Allocators). We propose that, for the purposes of the runtime semantics of Rust, Box is treated as no more special than a user-defined smart pointer you can write today[^1]. In particular, it is given similar behaviour on a typed copy to a raw pointer.
[^1]: We maintain some trivial validity invariants (such as alignment and address space limits) that a user cannot define, but these invariants only depend upon the value of the Box itself, rather than on memory.
Rendered

the rendered link is broken

It feels odd that one of the clear options is left out: why not expose a Unique<T> that has the same semantics as Box<T>, so any smart pointer type can use it?
Like, I definitely agree that Box shouldn't have special semantics that you can't reproduce elsewhere. But among the options, it feels pretty limiting to come to the conclusion that we should eliminate those semantics, rather than just making them reproducible elsewhere.
I agree that whatever happens shouldn't be specific to the Global allocator, though.

I, at least, fully expect us to have some way of writing alignment-obeying raw pointers in Rust in some way. If nothing else, slice::Iter is less good than it could be because of the lack of them, and optimizing that type is super-important.

That's my hope for the future as well, but to avoid the RFC becoming too cluttered, I am refraining from defining such a type in this RFC.

Is there a list of optimisations that depend on noalias being emitted for Box’es?

The RFC seems pretty clear that noalias hasn't really provided many benefits compared to being an extra burden to uphold for implementers, but maybe it is worth seeing if there are any sources that can provide a bit more detail on that.

My general take:
The two "endpoints" here are

Efficient end-user abstractions: this allows most safe code to run faster. This would have strong alias requirements and would not expose raw/unsafe details. This permits non-obvious optimizations (e.g., small string optimization or 0-length capacity).
Building blocks for unsafe code: this exposes raw/unsafe details.

From what I can tell, we current orient Box as the former but Vec and String as the latter. That seems backwards, since if anything those are far more useful as abstractions than Box is.
If I could go back in time, I think I would favor end-user abstractions and offer different types (e.g., RawVec or RawBuffer or something) that exposed their innards,  but I think that ship has sailed, and we might as well embrace the current situation (which is nice in some ways too).

The RFC would benefit from some attempt to quantify the impact on performance, though our lack of standardized runtime benchmarks makes that hard.

@rust-lang/opsem: We were curious in our discussions, does this RFC represent an existing T-opsem consensus?

We were curious in our discussions, does this RFC represent an existing T-opsem consensus?

It does not represent any FCP done by T-opsem, which is why I've included them here. The claims I make, including those about the impact on the operation semantics, are included in the request for comment and consensus.

The RFC would benefit from some attempt to quantify the impact on performance, though our lack of standardized runtime benchmarks makes that hard.

I recall some perf PR's being done to determine the impact, which showed negligible impact. I can probably pull them up at some point in the RFC's lifecycle.

It feels odd that one of the clear options is left out: why not expose a Unique that has the same semantics as Box, so any smart pointer type can use it?

Agreed.

I agree that whatever happens shouldn't be specific to the Global allocator, though.

There are patterns of using a custom per-Box allocator that are incompatible with the aliasing requirements, at least under our current aliasing models. See https://github.com/rust-lang/miri/issues/3341 for an example. So if we always make Box be unique, we have to declare those allocators to be UB.

Is there a list of optimisations that depend on noalias being emitted for Box’es?

It's "every LLVM optimization that looks at alias information". The question is how much that matters in practice, which is hard to evaluate.

We were curious in our discussions, does this RFC represent an existing T-opsem consensus?

As Connor said, not in any formal sense. Several opsem members have expressed repeatedly that they want to see noalias on Box go, but I don't know whether we have team consensus on this.
My own position is that I love how this simplifies the model and Miri, I am just slightly concerned about this being an irreversible loss of optimization potential that we might regret later. Absence of evidence of optimization benefit is not evidence of absence. Our benchmarks likely just don't have a lot of functions that take Box<T> by value. Maybe that in itself should be a sign...
Is there a way we can query the ecosystem for functions taking Box<T> by value?

Just to follow up on some of the discussion, it wasn't immediately clear to me that types similar to Box, like Vec, genuinely don't have these semantics, even though it is implied by the fact that Box is unique in this regard. I think this is worth emphasising more in the text of the RFC, since in a very real sense, we've been going without these semantics for most[citation needed] parts of Rust totally fine, which further emphasises less will be lost by removing it for Box.
I would still love if there's more data showing the lack of returns on noalias optimisations, since it feels wrong that something with a lot of history and usage isn't helping that much, but the fact that Vec and other types don't have this optimisation at least helps us understand that it's not going to cause any performance issues if removed.

I am just slightly concerned about this being an irreversible loss of optimization potential that we might regret later

FTR, speaking right now as one of the main developers of lccc, my opinion is that the best way to mitigate any loss of future optimization potential is to just be far more granular with &mut.  I don't think spamming extra noalias on parameters is necessary if we just emit more metadata on derefs (llvm's scoped noalias and dereferenceable, and lccc's unique and dereferenceable type attributes). If there are problems with doing that, I don't think this is a place where we should necessarily bend the whole language to this one attribute on one backend, especially given the complexity of maintaining the feature as-is, where we keep running into fundamental issues with the special treatment of Box. If there are legitimate optimizations lost as a result of the function level noalias, that can't be made up with more granular scoping on dereferences, that may be a different consideration.

Just to follow up on some of the discussion, it wasn't immediately clear to me that types similar to Box, like Vec and Arc, genuinely don't have these semantics, even though it is implied by the fact that Box is unique in this regard. I think this is worth emphasising more in the text of the RFC, since in a very real sense, we've been going without these semantics for most parts of Rust totally fine, which further emphasises less will be lost by removing it for Box.

I mentioned Vec<T> in particular, and also mentioned std::unique_ptr<T> from C++, which is the most closely equivalent type, and lacks the same semantic implications (and also optimizations).

would still love if there's more data showing the lack of returns on noalias optimisations, since it feels wrong that something with a lot of history and usage isn't helping that much

It helps for references. I suspect people added it for Box because "why not".

As an example of an optimization that noalias can enable: Optimizations can assume that writing to one Box can't change the value of a second Box. This means that if values from that second Box needs to be read repeatedly, then the program can be optimized to read the value only once, even if we write to the first Box in between.
As a concrete example, here's a Godbolt link of artificial code that gets optimized better if Box is noalias.
To test how making Box not noalias affects the optimization of your program, you can run the following command to build your program (requires nightly):
RUSTFLAGS='-Zbox-noalias=no' cargo +nightly build --release -Z build-std --target $(rustc +nightly -vV | sed -n 's|host: ||p')

I wonder whether this is common in real code. I don’t think I’ve seen functions accepting boxes as arguments that often: usually it makes more sense to just pass a reference. Maybe it happens in some generic impl AsRef<_> code?

would still love if there's more data showing the lack of returns on noalias optimisations, since it feels wrong that something with a lot of history and usage isn't helping that much
It helps for references. I suspect people added it for Box because "why not".

I guess that the confusion here is how things should propagate. Like, the assumption that references are unique should extend directly from the assumption that the data they're referencing is unique. Otherwise, it feels like a disaster of UB?

I guess that the confusion here is how things should propagate. Like, the assumption that references are unique should extend directly from the assumption that the data they're referencing is unique. Otherwise, it feels like a disaster of UB?

It's currently unclear whether the existence of a &mut Box<T> even implies that there's an initialized non-null Box<T>. See https://github.com/rust-lang/unsafe-code-guidelines/issues/412

Probably we should mention somewhere, in favor of adding a separate type like AliasableBox, that if we did that, we could then align other operations on that type to match in a way we can't do with Box.  E.g., making a reference from an AliasableBox would be unsafe.

Like, the assumption that references are unique should extend directly from the assumption that the data they're referencing is unique. Otherwise, it feels like a disaster of UB?

I don't understand either of these sentences, sorry.

I believe noalias has been associated with Box since https://github.com/rust-lang/rust/pull/11538. Note that the justification given at that time was
// `~` pointer parameters never alias because ownership is transferred

I think people are and have been reading way too much into the decision to put noalias on Box. That PR also added noalias to ~ returns, and that was probably unsound for 9 years until https://github.com/rust-lang/rust/pull/106371. And justified with the same comment.

@RalfJung Your comment about vec surprised me a bit. I want to check my understanding. I think that the reason that Vec<T> has a more "low-level" API is basically people using Vec<u8> as a kind of convenient byte-buffer to implement things like arenas etc. It'd be helpful if you can point to some kind of summary of the sorts of issues encountered by stacked/tree borrows.

Like, the assumption that references are unique should extend directly from the assumption that the data they're referencing is unique. Otherwise, it feels like a disaster of UB?

I don't understand either of these sentences, sorry.
&mut T references are unique because we say so, because we make the borrow checker and unsafe code enforce this, because it is part of their safety invariant.

Yeah, but if the pointers inside boxes aren't unique, then how can we guarantee that the mutable references are unique?
I'm sure I'm just misunderstanding what noalias means in these two different contexts, but what I'm wondering is, wouldn't aliasable boxes mean you could have two boxes pointing to the same memory, then unsoundly get a mutable reference to both at the same time?

wouldn't aliasable boxes mean you could have two boxes pointing to the same memory, then unsoundly get a mutable reference to both at the same time?

As per my understanding: Yes, having aliasing Boxes would let you get aliasing &muts in safe code. Therefore even under this RFC it sould still be a safety requirement (or library requirement) that Boxes not alias, i.e. you must not expose aliasing Boxes to arbitrary safe code, as opposed to the status quo where it is a validity requirement (or language requirement) that Boxes not alias, and is just immediate UB even if it only happens in localized unsafe code.

Indeed - it is not the intent of the RFC to require that arbitrary code remain valid in the presence of alised Box values, such a thing would be a breaking change - the library contract of Box isn't changed and still must be upheld. The proposal simply is to remove some UB from the language, when you do certain operations with Boxes in unsafe code.
Most collections act like this already, with Box being the outlier. It is possible, for example, to hold duplicate Vec<i32> values (with capacity > 0), but such values can't be fully used (including by dropping them implicitly or explicity) and can't be given to arbitrary code (safe or unsafe).

To give a simple example:
let mut v: Vec<i32> = Vec::with_capacity(128);
v.push_within_capacity(0);
let elem0: &mut i32  = unsafe { &mut *v.as_mut_ptr().add(0) };
*elem0 = 12; // write to elem0 so that reference becomes "Active" in TB
let mut v = v; // retag v
v.push_within_capacity(1);
// Carefully *not* using `v[1]` as that would create a slice conflicting with `elem0`.
let elem1: &mut i32  = unsafe { &mut *v.as_mut_ptr().add(1) };
mem::swap(elem0, elem1);

This is UB under Stacked Borrows and Tree Borrows semantics (if Vec is defined via Box<[_]>) because when v gets moved, there is a retag that conflicts with elem0.
However, LLVM noalias is fine with this program because noalias only exists on function arguments and is only active while the function runs. (In fact LLVM is even fine with using &mut v[1] instead of going via as_mut_ptr().)

So, elaborating on Allocators in the Motivation section got me thinking.
How does GlobalAlloc play in. Would GlobalAlloc not suffer similar issues if you wrote the allocator in Rust?

How does GlobalAlloc play in. Would GlobalAlloc not suffer similar issues if you wrote the allocator in Rust?

Global allocators involve some magic anyway that adds extra UB, so this could potentially be justified via that.

Just catching up with things. I wanted to share that for automatic differentiation (and likely GPU Kernels written in pure Rust) noalias is very relevant. At the llvm-dev meeting I've been presenting 5 benchmark that showed Performance Penalties in 4/5 Benchmarks ranging from 30% - 10x by removing noalias from the Rust code. Removing noalias from the C++ version of the benchmark also had large performance impacts (up to 4x), so it's not a pure Rust problem, and noalias is just generally very valuable for AutoDiff and GPU support. The only benchmark not suffering didn't had enough pointers/references for noalias to be valuable.
For now I have to admit that  I have written all benchmarks using slices or arrays and not box, but both autodiff and GPU offload work on llvm-ir, and there are logical reasons about why noalias has such a big performance impact. So I don't see any reason why the penalty for noalias should be smaller for box. I will try to get at least some of these Benchmarks ported to use a Box instead of slices to prove my point, but for now I can share the existing slice/array versions that I used for my talk: https://github.com/EnzymeAD/Enzyme/pull/1797
That being said, both autodiff and gpu-offloading are of course only experimental project goals, and noalias on box is of course less relevant than noalias on say slices. However, I think especially efficient GPU support is valuable beyond the scientific Computing/HPC/ML crowd and of interest for a lot of people. It might still be worth dropping it if it causes too many compiler issues, I haven't read up on the whole discussion yet. But we should at least be aware then that it likely will have relevant performance impact for these targets. If desired, I can also reach out to some of the LLVM people involved in GPU programming, they surely can provide more numbers/examples on noalias usage there.

So I don't see any reason why the penalty for noalias should be smaller for box.

The idea is that box doesn’t get passed around that much: you usually just pass a reference, and mutable references have noalias.
(This is distinct from passing a box behind a reference / a reference to a box, which would have noalias on the reference, but not on the box)

Agree, but in our case the existence of 2+ Box types inside of a function (with at least one write to it) would often force us to cache the data behind all Boxes for autodiff (instead of just the one we modified), so it's not only about passing it to other functions. Vectors also don't have noalias iirc so I think also any combination of 2+ vec/box types existing in one function could then cause unnecessary copies.
I want to be clear that the average IR from Rust is still miles ahead of the average IR we get from C++ (since people rarely use restrict), but the difference would be that people manually could fix C++ by adding restrict, whereas Rust users wouldn't be able to add noalias to Rust's builtin types. It might still be worth to sacrifice performance in some niche cases for easier correctness, I'll try to write up in more detail under which cases lacking noalias would have an impact for the HPC/etc. community so people can decide if it's worth it. I just wanted to share this as an FYI, while I'm working out more details on it.

Within a function you already don't get noalias, due to limitations of llvm and what code rustc emits.

You're talking about sret, right? Yes, we're following the work on the llvm side too, e.g. https://discourse.llvm.org/t/restrict-noalias-for-struct-members/78568, so we hope to increase the number of locations where llvm can use noalias info. I however don't have precise insights on how many of these llvm noalias improvements will later be useable by Rust and where we e.g. already allow unsafe code to alias and thus won't be able to add noalias.

Are you talking about sret preventing noalias?

No, he's talking about the fact that syntactically noalias only exists for function arguments, not inside a function.

Agree, but in our case the existence of 2+ Box types inside of a function (with at least one write to it) would often force us to cache the data behind all Boxes for autodiff (instead of just the one we modified), so it's not only about passing it to other functions.

This can't be happening today since, as Connor said, noalias in LLVM is only for arguments. So are you speculating here about what benefits there might be in a hypothetical future where Box has noalias and also LLVM has a way to represent this inside a function, and Rust uses it?
Would be good to know which parts of your comments are based on concrete data and which are speculative.

and noalias is just generally very valuable for AutoDiff and GPU support

That's a good point that I had not considered. Would be good to get some data on the GPU side here, too.

This can't be happening today since, as Connor said, noalias in LLVM is only for arguments. So are you speculating here about what benefits there might be in a hypothetical future where Box has noalias and also LLVM has a way to represent this inside a function, and Rust uses it?

Just to clarify, LLVM does have something called noalias that is not for arguments, namely the metadata).  rustc will not directly produce this metadata, but it arguably could and should.  Also, this metadata can end up in Rust code anyway because LLVM converts function-argument-noalias to scoped-noalias upon inlining.

Yeah noalias metadata exists but it's largely a separate system from noalias arguments, as far as I can tell. If the semantics of noalias arguments are poorly understood, then the semantics of noalias metadata are a complete mystery -- I don't know anyone who has even the faintest clue of what the actual rules for the metadata are (in an operational sense).

@rustbot labels +I-lang-nominated

Thus I think it's better that we not have a big footgun of code that's sound with Vec<T> being unsound with Box<[T]>

Is this footgun actually big, though?  It gave me a lot of pause about doing this when @RalfJung said:

I am not aware of a single real-world usage of Vec that actually breaks the noalias rules.

If that's true, maybe we should consider whether we can in fact go the other way somehow.
As a rule, I would like to make things less magic.  But here -- I don't know -- I wonder whether it's an improvement to lose this optimization and to, in some situations, have to suggest that people write inner functions like this:
// Without the inner function, this would take a long long time with
// `-Zbox-noalias=no`.
pub fn f_box(mut x: Box<[u64; 1]>, y: Box<[u64; 1]>) -> u64 {
    fn inner(x: &mut [u64; 1], y: &[u64; 1]) -> u64 {
        let mut z: u64 = 0;
        for i in 0..const { 2u64.pow(40) } {
            x[0] = i;
            z = z.wrapping_add(y[0]);
        }
        z
    }
    inner(&mut *x, &*y)
}

It's particularly kind of odd here since there's still of course the library invariant that a Box exposed to safe Rust must not alias other live things.  Obviously that constrains potential use cases rather dramatically.
The stated motivation for this RFC leans a lot on the ManuallyDrop<Box<T>> case, but we fixed that in a different way in RFC 3336 (MaybeDanging).
So I just wonder whether there's a strong enough reason to do this, given (quoting @RalfJung again):

I am just slightly concerned about this being an irreversible loss of optimization potential that we might regret later. Absence of evidence of optimization benefit is not evidence of absence.

I am not aware of a single real-world usage of Vec that actually breaks the noalias rules.

What is this based on? I'm not aware of any checker that we have for the noalias rules that would enable a systematic search like this.

It is based on so far none of the proponents of this RFC having produced even an artificial example of code that violates noalias in Vec.
It is often claimed that examples like the above are UB under noalias:
let mut v = Vec::with_capacity(10);
v.push(0);
let ptr0 = &raw mut v[0];
let mut v = v; // move the Vec
v2.push(1);
let ptr1 = &raw mut v[1];
ptr::swap(ptr0, ptr1);

That's just not true.  Stacked Borrows and Tree Borrows rule out patterns like this, but noalias is less restrictive than that. Specifically, noalias on an argument is only relevant inside the function; once the function has returned, there are no more aliasing restrictions on pointers derived from such an argument. In contrast, Stacked Borrows and Tree Borrows remember "where the returned reference comes from" and keep enforcing non-aliasing.
We don't have any systematic testing. But we also don't have a single, even contrived example of remotely realistic code
that would have UB. All we have is a vague uneasiness that maybe there's some UB out there, or maybe there is not.

 We could access other elements in f just fine, and even push_within_capacity to the vector. Only accessing the same element is an issue.
OTOH, also note that we could currently not even compile this to a noalias on the LLVM side since v is passed indirectly. We'd need to some some work on our ABI so that the three Vec fields are passed as three separate arguments.

There’s always an option of having a Box<_> be noalias but not dereferenceable. That both doesn’t lose the optimizations in the @traviscross’s example and fixes the ManuallyDrop<_> issue. I am guessing (but I don’t have a proof) that actually dereferencing the Box<_> inside of a function body would lead LLVM to infer dereferencability anyway.

There’s always an option of having a Box<_> be noalias but not dereferenceable_on_entry.

That would have to be a weaker noalias than SB/TB, since their noalias requires dereferenceable_on_entry. SB doesn't support such a weaker noalias at all, would TB support it by treating Box<T> like a ZST pointers.

Rust doesn't yet have an aliasing model, only several WIP proposals. If there's some good benefit from having noalias on Vec arguments, it would be reasonable to say that the proposals should be extended to be able to support that.


Add more Applications tests

Deploy an app with replacing the default route.
Deploy an app with env variables.
Deploy an app with a mix of all units tests.

Successfully tested on my lab.


Getting Default Page, instead of Portfolio Website

Getting Default Page
I am getting a page as shown in the screenshot. And, It's telling me to add my own index.php file.

Expected behavior
I expected your portfolio website to open. But instead, I am getting the above screenshot.

Solved, thanks!


Product list functional changes

Fetch all versions and releases for active products,
even disabled ones,
Assume users don't want inactive versions or releases,
but allow them to query them using disabled=True when
passed to get_versions() and get_releases()
Allow users to drop certain releases if they want,
Don't muck with async releases by default.

Product table version bumped since 'enabled' is now part
of version/release information.
Signed-off-by: Lon Hohberger<EMAIL_ADDRESS>

awesome, thanks


Core-model-construct is failing due to Internal Server Error in testbed

Issue Description :
While trying to fetch control construct of deployed application in testbed server it is failing with Internal server Error.
Root cause:
In server code we are using replaceAll function which is effective from node 16 version . But , in docker file which is used to create the image node 14 version is used .
Solution:
To replace docker file that supprots node 16 version.

Note: this issue should be in ApplicationPattern (the only occurrence of replaceAll I see is is ElasticsearchService).
Maybe simpler solution would be to use 'replace' instead of 'replaceAll' with regexp and 'g' flag.
key.replaceAll("_", "-")     =>   key .replace(/_/g, '-')

Though the replaceAll function in present in AP , the reason for raising the issue in EaTL is changes are required in dockerfile of the application .
Yeah , agree we can also use the solution mentioned . But woudn't it be more feasible if we shift docker file to node 16 in future . Please, suggest  on how to proceed.

Yes, moving to newer version is definitely a good option, but that should be a coordinated effort to upgrade all the applications to node 16, as having some on 14 and some on 16 can cause unknown issues. Upgrading all the applications might be a bigger task (I honestly cannot estimate that) so I thought a code workaround might be a simpler solution for the 2.0.1 release. I am in favor of doing the upgrade after release.


YouTube Premium

If a user has YouTube Premium (or YouTube Red) will they be able to see videos without ads through this api?
Thanks

Hi, no. The player doesn't support authentication.


host <IP_ADDRESS> doesn't set ViteRuby.instance.dev_server_running? to true

Description 📖
When host is set to <IP_ADDRESS> in config/vite.json ViteRuby.instance.dev_server_running? is set to false because  of this line : Socket.tcp(config.host, config.port, connect_timeout: config.dev_server_connect_timeout).close trying to connect to <IP_ADDRESS>
Reproduction 🐞
Platform: Windows
vite.json:
{
  "all": {
    "sourceCodeDir": "app/javascript/",
    "watchAdditionalPaths": []
  },
  "development": {
    "autoBuild": true,
    "publicOutputDir": "vite-dev",
    "port": 3035,
    "https": true,
    "host": "<IP_ADDRESS>"
  },
  "test": {
    "autoBuild": true,
    "publicOutputDir": "vite-test",
    "port": 3037
  }
}

when starting vite/dev:
  vite v2.9.1 dev server running at:

  > Network:  https://<IP_ADDRESS>:3035/vite-dev/
  > Network:  https://<IP_ADDRESS>:3035/vite-dev/
  > Network:  https://<IP_ADDRESS>:3035/vite-dev/
  > Local:    https://localhost:3035/vite-dev/

  ready in 2100ms.

In ruby server, check ViteRuby.instance.dev_server_running? it shall be false

Hi Antoine!
This problem is related to the local resolution of the <IP_ADDRESS> IP address.
In systems that can resolve <IP_ADDRESS> correctly, it works as expected:
irb(main):003:0> ViteRuby.config.host
=> "<IP_ADDRESS>"
irb(main):004:0> ViteRuby.instance.dev_server_running?
=> true

You can configure your system to resolve that address, or as a workaround, specify server.host in your vite.config.ts file instead.


Focus on the settings tabs does not follow the applications focus.

Description:  When navigating the setting tab panel with the the left and right arrow keys focus follows the applications focus and the currently active tab panel, but if I use the up and down arrow keys the focus doesn’t move to the currently active tab panel and even though the menu is changing. Expected behavior would be that the up and down arrow keys work just as the left and right arrow keys and keyboard focus moves to the currently selected tab item.
WCAG Criteria: 2.1.1 Keyboard - A
Screenshot: Screen Recording

This was fixed in #4091


[BUG] Copy-PnPList -> Attempted to perform unauthorized operation

Reporting an Issue
We are getting "Attempted to perform unauthorized operation" error when trying to run CopyPnPList even though the account running this has Full Control permissions on the site
Expected behavior
List to be copied as per the command
Actual behavior
We are getting "Attempted to perform unauthorized operation" error when trying to run CopyPnPList even though the account running this has Full Control permissions on the site
Steps to reproduce behavior
https://gist.github.com/sandeepvootoori/817161e0a0c2a62060b44aed7ed0b267
What is the version of the Cmdlet module you are running?
1.10.0
Which operating system/environment are you running PnP PowerShell on?
Windows

I have this issue as well from a Mac, tried uninstalling and running 1.9.0 as well, same result.

We have the same issue.  Also using version 1.10.0.

Something must have changed on the SharePoint Online side causing this to no longer work. Let me see if I can find another way to make this work again for non admin users.

Should be fixed by referenced PR

Thanks for the update, we're hearing reports that this was resolved with 1.11.

hi.. im using VS code.. can you tell me how to install the updated version there?


⚠ Bofrost.lu has degraded performance

In 8044072, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1504 ms

Resolved: Bofrost.lu performance has improved in 9bf061e after 7 minutes.


add new read-functions for binary-files

Feature-request
Description
Similar to issue #198 there should also be a function to read data to a normal pointer instead of a data-buffer
Related Issue

#198

Also fixed some broken length-checks in the binary-files-class I found while implementing


[Energy] add radio states and energy consumption

Contribution description
This PR is part of the process of breaking PR #235 into small steps. These small modifications will lead to the whole improvement started on March 2022. At the end of these steps, OT-NS will be capable of precisely estimating energy consumption, collision events (channel aware), and plot all the data in real-time as the simulation progress.
At the moment, OT-NS can not estimate energy, collisions, nor transmission energy. Also, even though OT is working well in simulation, many of its recovery properties are not correctly simulated as they would happen in real devices due to its incorrect timing events at the simulated radio part.
This PR adds functions to handle the radio state pushed by each simulated device.
It is still compatible to the current implementation of the OT.
This PR also introduces:

A new CLI called energy save [output name], allowing the user to store the energy results obtained out of their simulation;

This energy simulation is based on the STM32WB55rg at 3.3V:
	RadioDisabledConsumption float64 = 0.00011 //To be confirmed
	RadioTxConsumption       float64 = 0.01716 //5.2 mA
	RadioRxConsumption       float64 = 0.01485 //4.5 mA
	RadioIdleConsumption     float64 = 0.01485 //4.5 mA

Main modifications

A new energy analysis module (Go);

NodeEnergy struct is implemented from the gRPC to avoid redundant information in the code and keeping the standard around the system. For now, it could be implemented in another point of the code, but in the next PRs, we will use this same code in the web visualization, which is why it makes sense to centralize it in the PROTO.
Requirements
None (if intended to be used with current Openthread repository). But, this is a walk to the road of PR #7500 in Openthread repository that will allow all the new features in the simulation to work.
Testing procedure
Just install OTNS the same way as before, using the "OTNS=1" for the building parameter.
To obtain the energy results, just use the command energy save, but if you want a specific name for the files, use energy save "name"
This is part 2 of the steps to #235

Codecov Report

Merging #359 (f2d7703) into main (c616148) will decrease coverage by 1.58%.
The diff coverage is 16.36%.

@@            Coverage Diff             @@
##             main     #359      +/-   ##
==========================================
- Coverage   49.97%   48.39%   -1.59%
==========================================
  Files          38       40       +2
  Lines        4608     4794     +186
==========================================
+ Hits         2303     2320      +17
- Misses       2123     2290     +167
- Partials      182      184       +2

Impacted Files
Coverage Δ

cli/CmdRunner.go
22.62% <0.00%> (-0.51%)
:arrow_down:

cli/ast.go
66.66% <ø> (ø)

types/types.go
65.38% <ø> (ø)

web/site/bindata.go
99.00% <ø> (-0.01%)
:arrow_down:

visualize/grpc/pb/visualize_grpc.pb.go
18.77% <3.63%> (-0.66%)
:arrow_down:

energy/core.go
7.31% <7.31%> (ø)

dispatcher/dispatcher.go
56.25% <13.33%> (-0.86%)
:arrow_down:

energy/node.go
40.00% <40.00%> (ø)

dispatcher/Node.go
26.98% <44.82%> (-3.30%)
:arrow_down:

simulation/simulation.go
57.94% <50.00%> (-0.31%)
:arrow_down:

... and 2 more

@Vinggui This looks good, very useful that the new code works with the existing OT node. (I just updated my own radiomodel PR in such a way that existing OT nodes can work with it.)  And the radio_state event here is new, so it won't be emitted yet by the legacy OT nodes right?   I'll give it a try, did not see anything to comment on yet in the code, it follows the design cleanly.
The "Develop" Github action seems to have the same strange error that I had, as detailed in:  https://github.com/openthread/ot-ns/actions/runs/3041189606/jobs/4898059950#step:5:3534

@Vinggui This looks good, very useful that the new code works with the existing OT node. (I just updated my own radiomodel PR in such a way that existing OT nodes can work with it.) And the radio_state event here is new, so it won't be emitted yet by the legacy OT nodes right? I'll give it a try, did not see anything to comment on yet in the code, it follows the design cleanly.

@EskoDijk Actually, the radio_event is already implemented as a // TODO in the main/OT-NS branch. I made that in a previous PR trying to break the chicken and the egg problem of using both repositories so tightly implemented. However, as development went on, I saw that many more changes were necessary (which are now ready). I hope that our codes will still be very compatible, since your transmission model looks interesting.

The "Develop" Github action seems to have the same strange error that I had, as detailed in: https://github.com/openthread/ot-ns/actions/runs/3041189606/jobs/4898059950#step:5:3534

Don't bother about it, it is something else not related to these PRs. Soon, they'll fix that, and we can merge it. Right @simonlingoogle ?

Out of curiosity I did a merge of this PR with PR #316 - with some manual merging, it works ok: https://github.com/openthread/ot-ns/pull/359 .  As a future improvement, I think the radiomodel could output events to the queue about radio state as well. These flow back to the dispatcher and could be handled as reports/updates to the energyAnalyser to have some further fine-grained energy use tracking.  For example while the radio is doing the mandatory wait periods or during "turn around time" it may have different power consumption from regular Rx/Tx states?

Maybe here, we should fix the Issue 272. It seems like the best PR to do it.


:up: Shimmers

Issue Reference
For customer page,
For Catalog Rule page, create and edit page.

checked and found that the issue has been fixed. Checked the same concern in RTL and LTR view.
Video
https://github.com/bagisto/bagisto/assets/92721837/24e63a85-bb40-41d9-9b5c-d03f1275b396
https://github.com/bagisto/bagisto/assets/92721837/c72da4e4-1f6b-48dd-ad88-b576c4caea0f

Conflicts


Define settings as SettingKey, not TaskKey

Having assemblyJarName defined as TaskKey[String] instead of SettingKey[String] causes "A setting cannot depend on a task" errors when I want to use the name of the jar in a setting (for example preinitialize a console session's initialCommands with the info derived from the jar name).

jar name used to be a setting but it got changed to a task here - #74
It says:

We use git describe for jar names, so it's nice to not have to restart
SBT after a new commit.

I don't know in the hindsight if this was a good call, but I think we're sort of stuck with this decision.


Always Waiting for shard to be ready... rank=0!!! Is it due to the lack of flash attention???

System Info
2023-11-29T05:27:50.762649Z  WARN text_generation_launcher: trust_remote_code is set. Trusting that model /home/nas1/chk/pretrain/Qwen-14B-Chat do not contain malicious code.
2023-11-29T05:27:50.762772Z  INFO download: text_generation_launcher: Starting download process.
2023-11-29T05:27:54.011685Z  INFO text_generation_launcher: Files are already present on the host. Skipping download.
2023-11-29T05:27:54.565256Z  INFO download: text_generation_launcher: Successfully downloaded weights.
2023-11-29T05:27:54.565434Z  INFO shard-manager: text_generation_launcher: Starting shard rank=0
2023-11-29T05:27:58.422843Z  WARN text_generation_launcher: Could not import Flash Attention enabled models: Flash Attention is not installed.
Use the official Docker image (ghcr.io/huggingface/text-generation-inference:latest) or install flash attention with cd server && make install install-flash-attention
2023-11-29T05:27:58.428124Z  WARN text_generation_launcher: Could not import Mistral model: Flash Attention is not installed.
Use the official Docker image (ghcr.io/huggingface/text-generation-inference:latest) or install flash attention with cd server && make install install-flash-attention
2023-11-29T05:28:04.571372Z  INFO shard-manager: text_generation_launcher: Waiting for shard to be ready... rank=0
2023-11-29T05:28:14.576635Z  INFO shard-manager: text_generation_launcher: Waiting for shard to be ready... rank=0
2023-11-29T05:28:24.582021Z  INFO shard-manager: text_generation_launcher: Waiting for shard to be ready... rank=0
2023-11-29T05:28:34.587600Z  INFO shard-manager: text_generation_launcher: Waiting for shard to be ready... rank=0
2023-11-29T05:28:44.593226Z  INFO shard-manager: text_generation_launcher: Waiting for shard to be ready... rank=0
2023-11-29T05:28:54.598975Z  INFO shard-manager: text_generation_launcher: Waiting for shard to be ready... rank=0
2023-11-29T05:29:04.605873Z  INFO shard-manager: text_generation_launcher: Waiting for shard to be ready... rank=0
2023-11-29T05:29:14.611630Z  INFO shard-manager: text_generation_launcher: Waiting for shard to be ready... rank=0
2023-11-29T05:29:24.617344Z  INFO shard-manager: text_generation_launcher: Waiting for shard to be ready... rank=0
2023-11-29T05:29:34.623042Z  INFO shard-manager: text_generation_launcher: Waiting for shard to be ready... rank=0
2023-11-29T05:29:44.628621Z  INFO shard-manager: text_generation_launcher: Waiting for shard to be ready... rank=0
2023-11-29T05:29:54.634577Z  INFO shard-manager: text_generation_launcher: Waiting for shard to be ready... rank=0
2023-11-29T05:30:04.641337Z  INFO shard-manager: text_generation_launcher: Waiting for shard to be ready... rank=0
2023-11-29T05:30:14.648434Z  INFO shard-manager: text_generation_launcher: Waiting for shard to be ready... rank=0
2023-11-29T05:30:24.654137Z  INFO shard-manager: text_generation_launcher: Waiting for shard to be ready... rank=0
Information

[ ] Docker
[X] The CLI directly

Tasks

[X] An officially supported command
[ ] My own modifications

Reproduction
CUDA_VISIBLE_DEVICES=1 text-generation-launcher --model-id /home/nas1/chk/pretrain/Qwen-14B-Chat --trust-remote-code --port 8030 --cuda-memory-fraction 0.5
Expected behavior
I hope the model can be successfully deployed

hi, did you solve this?

Facing same issue but with llama-70b-chat-hf model.

Can you add the --env argument and paste the nvidia-smi output?


[WIP] Define a package with which to support duck typed definitions.

This also sketches out the skeletons for Targettable, Subscribable, and Conditions.
cc @vaikas-google WDYT?

cc @n3wscott

Looks like a great start, need to figure out the deets, but I can't wait to try this out in Subscription.

/lgtm

Ok, I removed the hold.  Excited to see some of these get schemas and in particular blend with the Conditions work.


How to provision dashboard automatically?

Hi,
how can I provision a dashboard automatically after setting up influxdb 2.0?
Ideally, I would create & export a dashboard as JSON on my local dev machine and somehow import that dashboard in a new influx instance provisioned e.g. in a docker container or on a VM.
The CLI apparently only offers listing existing dashboards (https://docs.influxdata.com/influxdb/v2.0/reference/cli/influx/dashboards/)
Via CLI I can do the initial setup with "influx setup" which createas a new bucket as well.
How can I add / import the dashboard after the setup?
Is there a file/folder that would automatically be picked up?
Thanks
Jochen

@jo-me This is what InfluxDB templates are for. You create the dashboard, then export it as a template. You can then programmatically apply that template to any other InfluxDB instance.

Ahhh, that piece was missing. Thanks!


Fix the issue of cancelling jobs

A job from the scheduler was not cancelled after its switch was off. After auto-cancelling lot of jobs in OCaml-CI, the solver-service get stuck and can't start solving new request until finish the oldest.

The structure was :

ocluster <--> solver-worker <--> solver-service
There was, 3 differents processes communicating via capnp-rpc.

The new structure is :

ocluster <--> solver-worker(solver-service).
Now, the solver-worker is in the same process as solver-service,
to share a job's switch.

This is part of solving https://github.com/ocurrent/solver-service/issues/53

This is already tested with #52.

Is there any other suggestion before the merge ?

However, it can still be nice to have another review from someone else :)

Thanks for your review, it was very helpful. I don't know how else would be interested for further review.
For extend, I'm cleaning the stress tests https://github.com/ocurrent/solver-service/pull/52 to however would like to test the differences.
cc @tmcgilchrist