[FEATURE] Auth Management

Is this a unique feature?

[X] I have checked "open" AND "closed" issues and this is not a duplicate

Is your feature request related to a problem/unavailable functionality? Please describe.
Tasks :

As of now, after the logins, or signups, nothing happens, just the success/failure response.

Proposed Solution

So, on successful Login, save the Auth Data to localstorage with the key "authData" and navigate the user to Home Page
Create a Logout button in the top-right corner of the Navbar in PWA to Logout the user
Clear the local storage on Logout.

Screenshots
Use this Logout button,
https://icons.getbootstrap.com/icons/box-arrow-left/
Do you want to work on this issue?
No
If "yes" to above, please explain how you would technically implement this
No response

i can work on this .
i will be using jwt to generate access token and save it on cookies as well as localStorage
in backend i have to add some routes like for logout and some controllers having all the things that is required .
can you assign me this issue??

i can work on this . i will be using jwt to generate access token and save it on cookies as well as localStorage

Doing both jwt based auth and again saving cookies for session based doesnot seem right. I guess it will be better if we do either token or session. your views on this? @sristy17

i can work on this . i will be using jwt to generate access token and save it on cookies as well as localStorage

Doing both jwt based auth and again saving cookies for session based doesnot seem right. I guess it will be better if we do either token or session. your views on this? @sristy17

also i don't think we need to create an extra route for logout, we can just clear the session/token to achieve Logout.

no no i was telling you that using jwt i can create the token, and that token i can store it in browser cookies and once token is stored in cookies than for further use we can store in localStorage.
and if you dont want to create me a extra route for logout no problem i will handel this on frontend by removing token in localStorage
this is what i will be doing:-

After login/signup: Store the JWT in localStorage and navigate the user to the Home Page.
Logout: Add a button to clear localStorage and redirect the user to the login page.

Okay so basically the token based Authentication. Please don't forget to clear the data while logging out.
I wanted session based authentication tbh, but token will also do. Go ahead with jwt then. all the best. @theCodeCrusaderX

please all mongo connection network to <IP_ADDRESS>
i am facing this issue

please all mongo connection network to <IP_ADDRESS>
i am facing this issue

It's already set to <IP_ADDRESS>. Please check the creds and env vars.


Support --kube-context parameter for helm ls

This is necessary to run helm ls against a specific cluster.
@adibenmat Would it make sense to also add it to the other commands?

Hi Nicolas.
Yes it make sense.
My future plan is to create some parent options scheme that would be added to all of the commands by default.
For now what you did is good enough...
Thanks a lot!

Thanks. Could you release it on npm?
If you want to automate it at some point I would recommend semantic-release

Hi,
I released the new version with the parent options support.
Thanks for the recommendation!
Good day!
On Mon, Feb 18, 2019 at 6:13 PM Nicolas Trésegnie<EMAIL_ADDRESS>wrote:

Thanks. Could you release it on npm?
If you want to automate it at some point I would recommend
semantic-release https://github.com/semantic-release/semantic-release
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/adibenmat/node-helm/pull/1#issuecomment-464793630,
or mute the thread
https://github.com/notifications/unsubscribe-auth/APDhZ-IJCzTSc_dXaQQJWs_1eZJklgP_ks5vOtEcgaJpZM4bBBLX
.

Thanks!


asset-import-meta-url cant resolve non existing paths

Describe the bug
When using import.meta.url with URL and an invalid path, the asset-import-meta-url plugin tries to open the file and errors out. This also happens when the line of code is commented out.
//no validation should be done to find out if this is actually a file or not.
const url = new URL('some/non/existant/path.js', import.meta.url)

// This also gets transformed and errors even though its commented out
// new URL('some/non/existant/path.js', import.meta.url)

console.log(url)

Reproduction
Clone this then do yarn & yarn run build (or npm equiv)
https://gitlab.com/brandonryan/example/-/tree/main/bugs/vite-asset-import-meta-url-bug
System Info
System:
    OS: macOS 11.4
    CPU: (8) x64 Intel(R) Core(TM) i5-8257U CPU @ 1.40GHz
    Memory: 65.06 MB / 16.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 16.4.2 - /usr/local/bin/node
    Yarn: 1.22.10 - /usr/local/bin/yarn
    npm: 7.18.1 - /usr/local/bin/npm
  Browsers:
    Chrome: 91.0.4472.114
    Firefox: 89.0.2
    Safari: 14.1.1
  npmPackages:
    vite: ^2.4.2 => 2.4.2

Used Package Manager
yarn
Logs
vite v2.4.2 building for production...
✓ 0 modules transformed.
[asset-import-meta-url] ENOENT: no such file or directory, open '/Users/smidget/Development/example/bugs/vite-asset-import-meta-url-bug/src/some/non/existant/path.js'
file: /Users/smidget/Development/example/bugs/vite-asset-import-meta-url-bug/src/index.js
error during build:
Error: ENOENT: no such file or directory, open '/Users/smidget/Development/example/bugs/vite-asset-import-meta-url-bug/src/some/non/existant/path.js'

Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/vue-next instead.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.

I don't think that pr fully addresses the problem.
It shouldn't try to resolve the file at all. There are going to be many times when files don't exist at build time that exist at runtime.


Fix placeholder names in diagnostics_region_center toolbar

https://bugzilla.redhat.com/show_bug.cgi?id=1406806

@mzazrivec to get this backported to euwe, will need a BZ link in the top comment.

@dclarizio bug added.

Closing in favor of https://github.com/ManageIQ/manageiq-ui-classic/pull/46


Add Passthrough to SpanNames

Used on https://github.com/AzureAD/ad-accounts-for-android/pull/2377

How often do we think these spans/operations run?

How often do we think these spans/operations run?

Passthrough rarely.
BrokerRequestDispatcher, will run for every broker operation we perform, WPJ API, Broker API, and MSAL broker services.
so probably we need to reduce the sampling from this one. if possible.

How often do we think these spans/operations run?

Passthrough rarely. BrokerRequestDispatcher, will run for every broker operation we perform, WPJ API, Broker API, and MSAL broker services. so probably we need to reduce the sampling from this one. if possible.

Okay, can you add the flight / default sampling rate for this one and hook it in the AndroidBrokerTelemetrySampler as part of your PR.


[AIRFLOW-130] Fix ssh operator macosx

Dear Airflow Maintainers,
Please accept this PR that addresses the following issues:

_https://issues.apache.org/jira/browse/AIRFLOW-130_

Testing Done:

Unit tests previously did not pass on Mac OS X, now pass.

Current coverage is 65.50% (diff: 100%)

Merging #1778 into master will decrease coverage by 0.01%

@@             master      #1778   diff @@
==========================================
  Files           143        143
  Lines          9887       9887
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
- Hits           6477       6476     -1
- Misses         3410       3411     +1
  Partials          0          0

Powered by Codecov. Last update 0bdcdbe...07dff6b

Please also see: https://github.com/apache/incubator-airflow/pull/1782. This is a change in behavior -t != --tmpdir .

I think git's diff algorithm doesn't show this, but the --tmpdir -> -t fix is already in master

@jbhsieh please rebase against master.
after rebasing, the --tmpdir -> -t change should not show up in the PR anymore, since it's already in master
also please move the import os to the top of file
also can you explain why the env=test_env change is needed?

@jbhsieh as part of cold-case cleanup, please respond within the next 5 days.

thanks for rebasing, can you explain why the env=test_env change is needed?

The env=test_env change is required because on MacOS X, the test was failing with airflow.exceptions.AirflowException: Bash command failed.
Something from the existing command is needed for the command to succeed.

Something from the existing environment is needed for the command to succeed.
Hide all checks

hmm do you mind pinpointing which are needed?
If it's possible to add 1 or 2 envars to env I think that would be better, otherwise if a lot are needed (and we understand why they are), then we can make the ssh command inherit the existing envars

I'm not sure which ones are needed, but from the python3 docs for subprocess.Popen:

If env is not None, it must be a mapping that defines the environment variables for the new process; these are used instead of the default behavior of inheriting the current process’ environment.

@zodiac because the default behavior when not specifying env inherits the current process' environment, I believe inheriting the existing envs in this case makes for a less brittle test.

LGTM


[helm chart][k8s] Connections from connections.local_production_json are ignored

Problem:
I'm not able to configure Redis connection through helm chart via connections.local_production_json. I wanted to use connections.local_production_json so I can configure multiple connections with passwords.
Context:

I used the helm chart v0.6.0 to deploy Redis Commander.

I set the values.yaml file based on the example like so:

 Click to toggle values.yaml

replicaCount: 1

serviceAccount:
  create: true

connections:
  local_production_json:
    noSave: false
    noLogData: false
    # ui:
    #   foldingChar: "|"
    redis:
      readOnly: true
    # server:
    #   clientMaxBodySize: "500kb"
    #   httpAuth:
    #     username: "the-user"
    #     password: "is-secret"
    connections:
      - label: "redis"
        host: "redis-master.redis.svc.cluster.local"
        port: "6379"
        password: 'MY_PASSWORD'
        dbIndex: 0

I confirmed that the configmap resource was successfully created

I confirmed that the configmap was successfully mounted

At this point, the UI was showing only connection local (localhost:6739:0). This is NOT the connection I defined in local_production_json.

I verified that the connection in my values.yaml file was correct by manually adding it:

After I manually added the connection, it was added to the local-production.json

And here's example what the logs look like at the point where I manually added the connection. All the connection errors are coming from trying to conenect to localhost:6739:0, which I did NOT configure:

Ok, I found that the config file is loaded depending on the NODE_ENV env var, and that currently NODE_ENV env var is NOT used for anything else in this project. So I was able to fix this by explicitly setting NODE_ENV=production-docker, so that the config file generated by helm chart is used.
So my updated values.yaml file looks like so:
replicaCount: 1

serviceAccount:
  create: true

# THIS WAS ADDED!
env:
  - name: NODE_ENV
    value: "production-docker"

connections:
  local_production_json:
    noSave: false
    noLogData: false
    # ui:
    #   foldingChar: "|"
    redis:
      readOnly: true
    # server:
    #   clientMaxBodySize: "500kb"
    #   httpAuth:
    #     username: "the-user"
    #     password: "is-secret"
    connections:
      - label: "redis"
        host: "redis-master.redis.svc.cluster.local"
        port: "6379"
        password: 'MY_PASSWORD'
        dbIndex: 0

So, now that there's a solution, how can we fix this?
Could we at minimum add this information to the Helm chart README?
Or better yet, update the chart to configure the NODE_ENV env var automatically?
Let me know your thoughts and I can make the changes if it's simple changes.


chore: Release Noir(0.19.5)

:robot: I have created a release beep boop
0.19.5
0.19.5 (2023-11-30)
Features

Add FieldElement::from<usize> implementation (#3647) (8b7c5aa)
Add package version to Nargo.toml metadata (#3427) (9e1717c)
Add special case for boolean AND in acir-gen (#3615) (824039b)
Aztec-packages (#3599) (2cd6dc3)
Aztec-packages (#3626) (e0a96ea)
Complex slice inputs for dynamic slice builtins (#3617) (8b23b34)
Copy on write optimization for brillig (#3522) (da29c02)
Implement integer printing (#3577) (6601408)
Implement raw string literals (#3556) (87a302f)

Bug Fixes

Corrected the formatting of error message parameters in index out of bounds error (#3630) (3bba386)
Docker builds (#3620) (f3eac52)
Flatten public inputs according to their index in numerial rather than ascii order (#3605) (a1f6343)
Restrict fill_internal_slices pass to acir functions (#3634) (0cad9aa)

0.36.0
0.36.0 (2023-11-30)
⚠ BREAKING CHANGES

Move circuit serialization circuit into acir (#3345)
expose pedersen hash in acir and bb solver (#3269)
Switch to new pedersen implementation (#3151)
Pass ACIR to ACVM by reference rather than passing ownership (#2872)
wasm: improve and simplify wasm compiler interface (#2976)
Maintain shape of foreign call arguments (#2935)

Features

acvm_js: Export black box solver functions (#2812) (da8a98e)
acvm: Separate ACVM optimizations and transformations (#2979) (5865d1a)
Add FieldElement::from<usize> implementation (#3647) (8b7c5aa)
Add ACIR serializer C++ codegen (#2961) (7556982)
Add conditional compilation of methods based on the underlying field being used  (#3045) (2e008e2)
Add debugger commands to introspect (and modify) the current state (#3391) (9e1ad85)
Aztec-packages (#3599) (2cd6dc3)
Expose pedersen hash in acir and bb solver (#3269) (0108b6c)
Extract Brillig VM to allow step debugging (#3259) (f6431f9)
Implement euclidean division and signed division in terms of AcirVars (#3230) (b8b7782)
Maintain shape of foreign call arguments (#2935) (f7869e6)
Pass ACIR to ACVM by reference rather than passing ownership (#2872) (b3a9c34)
Pass brillig bytecode to VM by reference (#3030) (4ee290b)
Refactor debugger and separate core from UI (#3308) (8466810)
Replace boolean range constraints with arithmetic opcodes (#3234) (949222c)
Save Brillig execution state in ACVM (#3026) (88682da)
Solve fixed_base_scalar_mul black box functions in rust (#3153) (1c1afbc)
Switch to new pedersen implementation (#3151) (35fb3f7)
wasm: Improve and simplify wasm compiler interface (#2976) (1b5124b)

Bug Fixes

ACIR optimizer should update assertion messages (#3010) (758b6b6)
acvm: Return false rather than panicking on invalid ECDSA signatures (#2783) (155abc0)
Determinism of fallback transformer (#3100) (12daad1)
Fix method program_counter, change method signature (#3012) (5ea522b)
Minor problems with aztec publishing (#3095) (0fc8f20)
Prevent duplicated assert message transformation (#3038) (082a6d0)
Return error rather than panicking on unreadable circuits (#3179) (d4f61d3)

Miscellaneous Chores

Move circuit serialization circuit into acir (#3345) (122119b)

This PR was generated with Release Please. See documentation.

Please don't merge before #3571

@kevaundray This isn't doing what we want. We're already updating the version numbers in the individual cargo.tomls, the issue is that the workspace Cargo.toml needs to be in sync.

from https://github.com/noir-lang/noir/pull/3646


docs: Update links to Argilla HF Spaces in documentation

Description
Please include a summary of the changes and the related issue. Please also include relevant motivation and context. List any dependencies that are required for this change.
Closes #4193
Type of change
(Remember to title the PR according to the type of change)

[x] Documentation update

How Has This Been Tested
(Please describe the tests that you ran to verify your changes.)

[x] sphinx-autobuild (read Developer Documentation for more details)

Checklist

[ ] I added relevant documentation
[ ] I followed the style guidelines of this project
[ ] I did a self-review of my code
[ ] I made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I filled out the contributor form (see text above)
[ ] I have added relevant notes to the CHANGELOG.md file (See https://keepachangelog.com/)

@ignacioct I have quickly updated the URLs, so could you please check if they are correct? Also, in the huggingface-spaces.md file (or any other similar file), could you check if the explanation needs improvement or if the image requires an update?

@sdiazlor , I believe the URL should be? https://huggingface.co/new-space?template=argilla%2Fargilla-template-space
https://huggingface.co/new-space?template=argilla/argilla-template-space does not seem to work for me

@sdiazlor , I believe the URL should be? https://huggingface.co/new-space?template=argilla%2Fargilla-template-space https://huggingface.co/new-space?template=Argilla/argilla-template-space does not seem to work for me

@davidberenstein1957 the links that Sara pushed are working for me though. They are

closing this because it was handled from the side of HF @sdiazlor @ignacioct

@davidberenstein1957 nevertheless in this PR, as you mentioned in the issue, I also commited the reference to private HF Spaces, should I create a new PR for that?

@sdiazlor, good catch! Could you create a separate PR for that?

@ignacioct, could you also add this private space usage reference to the publication ideas as a post?

@ignacioct, could you also add this private space usage reference to the publication ideas as a post?

Like a tutorial on how to use private spaces with Argilla? I think Dani talked about it in a community meeting you sent me

@ignacioct, correct. The idea could be just showing a brief code snippet.

@sdiazlor, good catch! Could you create a separate PR for that?

yes, no problem


Metadata form layout tweak #1

I'm pretty sure the <p> tags in the Abstract come directly from the DOI data

Should I make similar changes to the ISSN related fields?

@jabrah please see if the layout of the pubtype layout could be addressed?

I can simply have the button toolbar appear only when the user hovers over the row.
Having the publication type options display horizontally is also possible.
Should I also get rid of the "None" option?


26 Recruiter Page- Upcoming Career Fair w/ Create and Edit Event Components

Updated path to recruiter page from home page.
Created component cards for recruiter profile, live career fairs, upcoming career fairs, and past career fairs.

Next to do: update path to recruiter live career fair with student queues from 'Join Now' button.

When you finally merge, click the dropdown and choose squash and merge - will squash the commits into 1 - making a cleaner main commit history

@sjoshi804 Got it, will do.


Add a link for interpreter.md to navbar menu

What is this PR for?
Currently, /docs/manual/interpreters.md file can not be found in anywhere. So I add a link for this file to the navbar menu.
What type of PR is it?
Improvement
Todos

[x] - Add a link for interpreter.md to navbar menu.

Is there a relevant Jira issue?
No
How should this be tested?
We don't have link for interpreter.md yet, so can not reproduce it  : (
Screenshots (if appropriate)

Before

After

Questions:

Does the licenses files need update? No
Is there breaking changes for older versions? No
Does this needs documentation? No

Thanks for finding missing doc!
LGTM


Setup the server

Login in to the server (instance). The person who spins up the EC2 instance will only have access to the server as he only got the private key. If someone else wants to log in to that instance, you need to get hold of that private key.

Setup a common data folder to download data, and this folder should be accessible by all users in the JupyterHub. Following commands make a folder and make it accessible to everyone. Want to learn more about basic UNIX commands?
sudo mkdir -p /srv/data/my_shared_data_folder
sudo chmod 777 /srv/data/my_shared_data_folder/

If you want a sharing notebook environment, then check out this. if you plan to do this, make sure you install the "members" package in your server run sudo apt-get install members."

Install AWS CLI. More details here.

NOTE:We are installing this in our EC2 instance, but we can install this anywhere to interact with s3. Say you can install it in your local machine and move data to s3.
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
sudo apt install unzip
unzip awscliv2.zip
sudo ./aws/install

Setup your access key and secret. Do it from your AWS console. Make sure you keep your "Access key ID" & secret key somewhere safe.

Use these credentials to configure AWS CLI (aws configure). More details here. "Default region" and "output format" you can leave empty.

AWS cli can be used to interact with a lot of services. Check this out. To get a feel, we will use CLI to interact with s3 and wait for step Wrangle the data in preparation for machine learning

Please attach this screen shots from your group for grading
Make sure you mask the IP address refer here
https://github.ubc.ca/MDS-2020-21/DSCI_525_web-cloud-comp_students/blob/master/images/3_result.png

Done by @Andrew-Tan!.


Usage of Cognito id-token changed in v1.1.0

Describe the bug
The library changed from using the Cognito id-token to the access-token, this breaks our AppSync backend which relies on a custom user attributes which is only in the id-token. There by our AppSync resolver can not distinguish between clients making the calls to our backed.
This MR did the change
https://github.com/aws-amplify/amplify-ios/pull/690
To Reproduce
Try to access $ctx.identity.claims['custom:orgId'] in an AppSync resolver. custom:orgId stand for our specific custom attribute, but can be replaced by your own logic.
Expected behavior
Either keep using the id-token as default or provide a way to set the library to use the id-token, as it is possible in the JS library.
Screenshots
iOS AppSync call made with the access-token with out the Cognito claims

JS AppSync call made with the id-token including the Cognito claims

Additional context
Our multi-tentant setup relies on the custom attributes to separate between organizations without our application.
Thanks for you help

@LaszloDev
The change to use accessToken was made to bring the iOS Amplify client in line with the other platforms. If your app relies on custom values only present in the idToken, you can get to them from a custom interceptor. I'm asking @lawmicha to provide more info on this, in relation to his docs PR https://github.com/aws-amplify/docs/pull/2211

Hi @LaszloDev
Currently a workaround to add the idToken on iOS is to have a custom interceptor, however we haven't finalized on this design and will be working on a feature request across iOS and Android to build parity for this use case with JS. Please keep this in mind that the mechanism for adding custom request data may change in future versions.
After configuring API and Auth plugins, add your custom interceptor to the interceptor chain for the API
try Amplify.add(plugin: AWSCognitoAuthPlugin())
try Amplify.add(plugin: AWSAPIPlugin(modelRegistration: AmplifyModels()))
try Amplify.configure()
try Amplify.API.add(interceptor: CustomRequestInterceptor(), for: "[API_FRIENDLY_NAME]")

API_FRIENDLY_NAME corresponds to the API endpoint cofigured in amplifyconfiguration.json
"[API_FRIENDLY_NAME]": {
    "endpointType": "GraphQL",
   "endpoint": "
   "region": "us-west-2",
   "authorizationType":  ...
},

In your custom interceptor, you can retrieve the IdToken from Amplify.Auth and update your request
struct CustomRequestInterceptor: URLRequestInterceptor {
    init() { }
    func intercept(_ request: URLRequest) throws -> URLRequest {
        var modifiedRequest = request
        let semaphore = DispatchSemaphore(value: 0)
        Amplify.Auth.fetchAuthSession { result in
            defer {
                semaphore.signal()
            }
            do {
                let session = try result.get()
                if let cognitoTokenProvider = session as? AuthCognitoTokensProvider {
                    let tokens = try cognitoTokenProvider.getCognitoTokens().get()
                    modifiedRequest.addValue(tokens.idToken, forHTTPHeaderField: "authorization")
                }
            } catch {
                print("Fetch auth session failed with error - \(error)")
                semaphore.signal()
            }
        }
        semaphore.wait()
        return modifiedRequest
    }
}

bring the iOS Amplify client in line with the other platforms.

Appreciate your efforts @palpatim @lawmicha

Currently a workaround to add the idToken on iOS is to have a custom interceptor

Personally I'm developing on JavaScript only and been working with iOS only to manage the external development firm who builds our iOS app.
In JavaScript changing the header token used for AppSync/GraphQL requests, it's more or less a few lines of code:
Amplify.configure({
  API: {
    graphql_headers: async () => {
      const session = await Auth.currentSession();
      return {
        Authorization: session.getIdToken().getJwtToken(),
      };
    },
  },
});

As I'm not that familiar with the concepts of Swift, my question is, would there be any chance to have an flag to switch between the tokens? The logic before version 1.1 did had the code for it and it would make the library much user friendly.
Alternatively an approach like the JS lib for injecting different headers.
Thanks for your work 💪🏼

Hi @LaszloDev, thanks for the feedback, will take the flag option and JS's headers into consideration and will follow up on this and mark as feature request. The code that had the logic before was a mistake on our end and if we go with the flag option, this would be something we add to all platforms

Thanks @lawmicha.
I have been only working with Amplify for two months, but the JS version does seams a lot more stable and mature, would love to see that also for the iOS version. Initializing subscriptions with attributes for example is a pain compared to the JS SDK.
What I generally do not get about Amplify with AppSync, is how authorization is done in the resolvers without the id-token's user identity claims, if the access-token is the default one to use, which does not have that information encoded?
As this is not an edge case but actively referenced in the AWS AppSync dev guide for Security / Authorization Use Cases to use the $context.identity.claims which are only in the id-token:
https://docs.aws.amazon.com/appsync/latest/devguide/security-authorization-use-cases.html
Thanks for your work guys 🙏

I have a slightly different use case. In my iOS app, I simply started receiving 401s for all my requests after upgrading to 1.1.0. I am not using AppSync at all. My API uses a Cognito authorizer (with a user pool) for all protected requests. So I decided to simply change the getTokenString() method in AmplifyPlugins/Core/AWSPluginsCore/Auth/AWSAuthService.swift from returning the accessToken to idToken and everything suddenly started working again. So I don't exactly understand how the accessToken is supposed to work in my case and it clearly doesn't. I am also not relying on custom values only present in the idToken.
The custom interceptor does seem like an acceptable workaround, but that does not really address the issue with using the accessToken as intended.

I have a slightly different use case. In my iOS app, I simply started receiving 401s for all my requests after upgrading to 1.1.0. I am not using AppSync at all. My API uses a Cognito authorizer (with a user pool) for all protected requests. So I decided to simply change the getTokenString() method in AmplifyPlugins/Core/AWSPluginsCore/Auth/AWSAuthService.swift from returning the accessToken to idToken and everything suddenly started working again. So I don't exactly understand how the accessToken is supposed to work in my case and it clearly doesn't. I am also not relying on custom values only present in the idToken.
The custom interceptor does seem like an acceptable workaround, but that does not really address the issue with using the accessToken as intended.

Hi @zpodolyak, the reason why the change in this PR to use accessToken https://github.com/aws-amplify/amplify-ios/pull/690 and released in 1.1.0 was to match what JS and Android platforms were doing. We saw confusion before when customers built their app on multiple platforms against the same backend and iOS was intercepting the requests with idToken while JS and Android used the accessToken.

Thanks @lawmicha.
I have been only working with Amplify for two months, but the JS version does seams a lot more stable and mature, would love to see that also for the iOS version. Initializing subscriptions with attributes for example is a pain compared to the JS SDK.
What I generally do not get about Amplify with AppSync, is how authorization is done in the resolvers without the id-token's user identity claims, if the access-token is the default one to use, which does not have that information encoded?
As this is not an edge case but actively referenced in the AWS AppSync dev guide for Security / Authorization Use Cases to use the $context.identity.claims which are only in the id-token:
https://docs.aws.amazon.com/appsync/latest/devguide/security-authorization-use-cases.html
Thanks for your work guys 🙏

If the recommendation from AppSync is to use idToken, then perhaps the developers building on JS were simply all using the customHeader mechanism and providing an idToken from their auth provider. There has been some confusion around which one to use and which token has what information. When you said it does not have the information encoded, what information is in the idToken and what is in the accessToken? I read from here that they are interchangable.

Recently, we released a change to support getting a token from the developer when their use case is any ODIC provider. If you perform to treat your cognito user pool auth provider as an OIDC provider, you can follow this to return the idToken and set the API as an ODIC use case: https://github.com/aws-amplify/docs/pull/2613
So the developer would replace their custom request interceptor with their custom OIDC token provider instead

I have a slightly different use case. In my iOS app, I simply started receiving 401s for all my requests after upgrading to 1.1.0. I am not using AppSync at all. My API uses a Cognito authorizer (with a user pool) for all protected requests. So I decided to simply change the getTokenString() method in AmplifyPlugins/Core/AWSPluginsCore/Auth/AWSAuthService.swift from returning the accessToken to idToken and everything suddenly started working again. So I don't exactly understand how the accessToken is supposed to work in my case and it clearly doesn't. I am also not relying on custom values only present in the idToken.
The custom interceptor does seem like an acceptable workaround, but that does not really address the issue with using the accessToken as intended.

@zpodolyak Amplify is just a wrapper. When you are using the Ampilfy.API from the SDK, in the background your client is using the AppSync GraphQL API. Your API authentication is probably relying on authentication information like Cognito Groups, which are encoded into the id-token but not the access-token. There are different use cases and yours might be a bit different. But you get the idea.

If the recommendation from AppSync is to use idToken, then perhaps the developers building on JS were simply all using the customHeader mechanism and providing an idToken from their auth provider.

@lawmicha I would not say that AppSync is specifically recommending the idToken, but if you want to utilize the Cognito authentication mechanisms thats the way from my understanding.
It's well documented by this time, how the JS client needs to be configured to use the idToken instead of the accessToken. As Im mainly a JS developer and not working with iOS directly. See here for example
The JS Rest documentation specifically mentions

The ID Token contains claims about the identity of the authenticated user such as name, email, and phone_number. It could have custom claims as well, for example using Amplify CLI. On the Amplify Authentication category you can retrieve the Id Token using:
https://docs.amplify.aws/lib/restapi/authz/q/platform/js#note-related-to-use-access-token-or-id-token

Also the JS GraphQL documentation:

https://docs.amplify.aws/lib/graphqlapi/authz/q/platform/js#api-key

There has been some confusion around which one to use and which token has what information. When you said it does not have the information encoded, what information is in the idToken and what is in the accessToken? I read from here that they are interchangable.

It took me also bit to understand the differences and I hope my infos will help you also. Both tokens allow the basic authorization regards being valid / not expired, besides its additional claims/properties being different.
I understand that you try to be more aligned with all frameworks, which is really great. Just this change was a breaking change and it seams like just hardcoding&replacing one token with another would not get you in alignment with the JS SDK. Which does provides the flexibility with a configuration API for the header tokens.
We are basically stuck on the v1.0 until the iOS framework has the same configuration APIs as the JS has.

We are working on a way to support using idToken for authorizers. We'll update this issue when we have more info

Thanks for all the details and patience. As mentioned, the custom request interceptors (https://github.com/aws-amplify/amplify-ios/issues/780#issuecomment-702926246) has an issue with subscriptions. The chain of request interceptors are not used for subscription connection requests.
For the use case to use Cognito user pool's ID Token instead of accessToken, you can treat the Cognito user pool as your OIDC provider and update the authorizationType to OPENID_CONNECT
{
    "awsAPIPlugin": {
        "<YOUR-GRAPHQLENDPOINT-NAME": {
            "endpointType": "GraphQL",
            "endpoint": "[GRAPHQL-ENDPOINT]",
            "region": "[REGION]",
            "authorizationType": "OPENID_CONNECT",
        }
    }
}

Create a subclass of APIAuthProviderFactory
class MyAPIAuthProviderFactory: APIAuthProviderFactory {
    let myAuthProvider = MyOIDCAuthProvider()

    override func oidcAuthProvider() -> AmplifyOIDCAuthProvider? {
        return myAuthProvider
    }
}

Create the token provider to return the ID Token:
class MyOIDCAuthProvider : AmplifyOIDCAuthProvider {
    func getLatestAuthToken() -> Result<String, Error> {
        let semaphore = DispatchSemaphore(value: 0)
        var result: Result<String, Error> = .failure(AuthError.unknown("Could not retrieve Cognito token"))
        Amplify.Auth.fetchAuthSession { (event) in
            defer {
                semaphore.signal()
            }
            switch event {
            case .success(let session):
                if let cognitoTokenResult = (session as? AuthCognitoTokensProvider)?.getCognitoTokens() {
                    switch cognitoTokenResult {
                    case .success(let tokens):
                        result = .success(tokens.idToken)
                    case .failure(let error):
                        result = .failure(error)
                    }
                }
            case .failure(let error):
                result = .failure(error)
            }
        }
        semaphore.wait()
        return result
    }
}

Then instantiate it with AWSAPIPlugin
try Amplify.add(plugin: AWSAPIPlugin(apiAuthProviderFactory: MyAPIAuthProviderFactory()))
try Amplify.configure()

This mechanism also supports GraphQL subscription requests, which is something that when using a custom request interceptor is currently lacking. Although this isn't exactly like how JS does it, you should be able to achieve the same result. Please let me us know if this works for you.
Related documentation update: https://github.com/aws-amplify/docs/pull/2211


Introduce support for multivalue reads

Modified the reads to support multivalues.
The 'where' attribute of the read object can can take an array of strings, representing the keys
Ex:
Response from 'request url' is:
{
    'metadata': {
        title: 'Title'
    },
    'body': {
        'kind': 'widget'
    }
}

Before read:
{
    'kind': ['__read', 'scene'],
    'uri': '<request url>',
    'where': ['metadata', 'body']
  }

After read:
{
     'kind': ['scene'],
     'uri': '<request url>',
     'where': ['metadata', 'body'],
     'metadata': {
         title: 'Title'
    },
    'body': {
         'kind': 'widget'
    }
}

Coverage increased (+0.5%) to 82.075% when pulling 86775855d2b2d36b183e67f6f92f87e370d83478 on feature/multivalue_read into 10807261bd1cd510b9cb78ea30db7de1a7966105 on master.

But, how do you define which properties go under which 'where'?

My proposal is actually to drop the where property entirely and simplify: the read result just replaces the read element entirely. @andon thoughts?
If the server responds with a scene:
// before
{
  kind: ['__read', 'scene'],
 uri: "...",
}

// response
{
  kind: 'scene',
  children: [  ], // ...
  metadata: { } // ...
 // ...
}

// after  == response

Alternatively, if the server returns something else, e.g. a kind document:
// before
{
  kind: ['scene'],
  content: {
      kind: ['__read', 'document'],
      uri: "...",
  }
}

// response
{
  kind: 'document',
  children: [  ], // ...
  metadata: { } // ...
 // ...
}

// after
{
  kind: ['scene'],
  content: {
    kind: 'document',
    children: [  ], // ...
    metadata: { } // ...
    // ...
  }
}

You would adjust your scene to read the metadata in a cascading way:

['content', 'metadata'] path
if it is not present, then just 'metadata'

This way, you can already have some 'default' metadata, e.g.; the title in the scene object that is shown while the document is loading.

How reads are working at the moment is that what is received from the server is placed under either content property, or what is specified in the where. In my use-cases, to be honest, we haven't used it much, except to change the property where there response will be written (usually we change it to children).
Still, the current idea with where was for it to allow to be written in a different place, by providing a path. Now that implementation is broken. What was previously a path is now used in a bit unintuitive way (@ognen had to ask) to split the response writing in different place (still only as a prop and not a path).
What @ognen is proposing, will certainly need to move the implementation to actually merge the data that comes from the server. The client state can contain additional client-related properties.
In general, I think that will simplify the whole read contract.
As for the implementation, we need to check. The whole read implementation is unfortunately spread around in the read reducer / saga, loading and read elements... If merge is used instead of set, we might need to work it out a bit. You either need to have access to the parent element or implement a more complex merging logic (maybe its simple, I might just not see it)


split .json files under nested directories not recognized

Hello, thank you for your plugin. It's great help me, thanks a lot.
Would it be possible to support split .json files under nested directories?
for example, my file directories is like this:
locales:
  en-US:
    common.json
    views:    ----> views is a directory
        child.json
  zh-CN:
    common.json
    views:
        child.json

here is my config:

it's just Identify common.json，but child.json is not。

Is there any way to fix it?
Thanks

nice work 👍

I have a monorepo with 2 Angular projects. I would love this feature 👍 Otherwise I always need to switch.


moved topic to appropriate location

@pyronicide what do you think about this suggestion?

@joel-hamill it doesn't make much sense to me. In the doc, we're showing how tasks are named and how you can figure that out. It doesn't have anything to do with nodes.

@pyronicide as I understand it, the purpose of this feature is so that users can figure out which node their installed services are running on. the current title "Discovering running service DNS entries" is very implementation-specific (and has back to back gerunds).
CC: @sargun

No, the purpose of this feature is to figure out what DNS name your service has. Once you've figured out the DNS name, then you'd eventually use it to figure out the IP that your service has. That doesn't have anything to do with hosts though ... especially in an IP/container world.

@pyronicide how about Discovering Service DNS Names, or similar?

That's getting closer. @sargun ?

Looks good.

@pyronicide ready to go


No support to query repositories on a workspace?

Sorry, if I'm being stupid here, but it doesn't seem you support the workspace repositories query.
see https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/{workspace}
Doing this seems to work fine, but shouldn't this be supported in the client itself?
class WorkspaceRepositories extends \Bitbucket\Api\Repositories {
    public function listWorkspace(string $workspace, array $params = [])
    {
        $path = $this->buildRepositoriesPath($workspace);

        return $this->get($path, $params);
    }
}
$workspace_repositories = new WorkspaceRepositories($c->getHttpClient());
print_r($workspace_repositories->listWorkspace('bitbucket'));

Am I missing something clever, or is this what I should do for now?

This is already supported. Please see my comment via ->users($workspaceName)->list();.


Align types and names of ports in emitted Verilog

I'm thinking padding the directions may be a little enthusiastic since there are exactly 3 and they aren't going to change. Perhaps I should get rid of stringify for Direction and instead just turn the directions into strings (with padding) in build_ports?

@colinschmidt I believe I have addressed your feedback


dependency check

running npx depcheck  reveals some unused and missing dependencies
Unused dependencies

@radix-ui/react-popover
@radix-ui/react-separator
@radix-ui/react-tabs
@reach/dialog
downshift
remix-auth-socials
spin-delay

Missing dependencies

esbuild: .\other\build-server.ts

there are also report for Unused devDependencies but i don't sure how to check if those are really unused

Unused devDependencies

@remix-run/testing
@testing-library/dom
@testing-library/jest-dom
@testing-library/react
@testing-library/user-event
@types/eslint
@types/testing-library__jest-dom
@types/uuid
@vitest/coverage-c8
autoprefixer
c8
postcss
prettier-plugin-sql
prettier-plugin-tailwindcss
tailwindcss
tailwindcss-radix
tsconfig-paths
vitest-mock-extende

Outdated dependencies
@faker-js/faker                ^7.6.0  →   ^8.0.1 🔴
@remix-run/router              ^1.6.1  →   ^1.6.2
@testing-library/dom           ^9.2.0  →   ^9.3.0
@types/cookie                  ^0.5.0  →   ^0.5.1
@types/glob                     7.2.0  →    8.1.0
@types/node                  ^18.16.3  →  ^20.2.1
@vitest/coverage-c8           ^0.31.0  →  ^0.31.1
chalk                          ^4.1.2  →   ^5.2.0 🔴
glob                           ^7.2.3  →  ^10.2.5 🔴
lru-cache                     ^7.18.3  →   ^9.1.1 🔴
prettier-plugin-tailwindcss    ^0.2.8  →   ^0.3.0
vite                           ^4.3.5  →   ^4.3.8
vitest                        ^0.31.0  →  ^0.31.1
we can upgrade to chalk 5.2.0 now that we are using ESM
why you are still using year old glob?

there are some breaking changes
@faker-js/faker ^7.6.0 → ^8.0.1
upgrading faker to v8
faker deprecate helpers.unique #1785 for removal in version 9.0, we need to find a replacement or write the code
chalk ^4.1.2 → ^5.2.0
chalk 5.2.0 does not work for me on development mode npm run dev, the script just hang after Mock server installed.
using npm run build  and npm start work ok.
@kentcdodds , can you check lru-cache?

Done in #116

@onemen
I created an npm package to be used as a replacement to unique.
https://github.com/MansurAliKoroglu/enforce-unique
https://www.npmjs.com/package/enforce-unique

Thanks! I'd definitely accept a pull request to use that module.


add more integration with std::time::Duration?

There are two different use cases to untangle here.
The first use case is something like this:

I use Rust's standard library std::time::Duration type, and I'd like to use it directly to add and subtract elapsed/absolute time to Jiff's datetime types. I would also like to be able to compute the absolute durations between datetime types using APIs like Zoned::since, but with std::time::Duration as the result returned.

The second use case is something like this:

I like Jiff's high level Span data type for representing both calendar and absolute durations, but this necessarily requires a lot of overhead when performing operations. For example, adding a Span to a Timestamp is not just a simple ~single integer addition. The implementation collapses all allowed units (hours and lower) into a single integer nanosecond (an i128), then converts the Timestamp into an i128 as a number of nanoseconds, then adds them and finally converts the integer number of nanoseconds as an i128 back to Timestamp's internal 96-bit integer representation. All of this overhead means that adding a simple count of integer seconds to a Timestamp is not as fast as I expect it to be.

The second use case is perhaps related to #17, but it is somewhat intertwined here, because one (but not the only) obvious way to address that is to satisfy the first use case: we provide alternative APIs that use std::time::Duration (hereafter just called Duration). This works because a Duration is itself just a 96-bit integer. And it always represents absolute time. That is, it is logically an integer number of nanoseconds. Therefore, adding a Duration to something like a Timestamp should be a very fast operation. Certainly faster than the existing Span focused APIs that we have today.
At present, I believe it is correct to say that Duration appears in the public API exactly zero times. This was not an accident, because I was unsure of how to integrate it. I think there are two challenges:
The first is that Duration is unsigned. There is some discussion in the issue tracking the addition of Duration (and SystemTime) to the standard library, and the related RFC has this to say:

Finally, many APIs that take a Duration can only do something useful with positive values. For example, a timeout API would not know how to wait a negative amount of time before timing out. Even discounting the possibility of coding mistakes, the problem of system clock time travel means that programmers often produce negative durations that they did not expect, and APIs that liberally accept negative durations only propagate the error further.

I was on libs (now libs-api) at the time, and I'm not sure if this was a mistake or not. Maybe the world really does need both unsigned and signed durations. The main issue with an unsigned duration type in Jiff is that it isn't nearly as flexible. For example, if you do ts1.until(ts2) and ts1 refers to a point in time after ts2, then Jiff will happily return a negative span. But what happens if you want to return a Duration? What is the result? One choice is to just return the duration between them such that ts1.until(ts2) and ts2.until(ts1) are equivalent. The other is to return an error. I would probably lean towards "return an error"... This doesn't come up as much with things like ts.checked_add(duration) since there is a ts.checked_sub(duration), and because it's up to caller in this case to apply the right operation. It isn't on Jiff to interpret the duration as anything other than unsigned.
The second problem with Duration integration is that it's not clear how to, well, actually integrate it. Does this mean Jiff should grow checked_add_duration and since_duration methods? I think so... And I think this is probably a requirement to satisfying the second use case above, even if we use a different duration type. I do personally find the names with a _duration suffix quite clunky, but perhaps it's fine because these will be considered "niche" APIs IMO.
It would perhaps be possible to satisfy the first use case without satisfying the second while simultaneously not adding a bunch of clunky _duration APIs to all of the datetime types. This could be accomplished by providing APIs to convert between a Span and a Duration. So callers would still need to use Span, but they would at least have a paved path for using Duration.
I think the main alternative point in the design space here is for Jiff to define its own absolute duration type that is signed. We'd still need things like checked_add_duration and since_duration, but the awkwardness with an unsigned duration type would go away. And then once we have our own absolute duration type, we could define conversions to and from std's unsigned Duration type. And we could deal with the peculiarities of signedness in a very focused and deliberate way.

I don't know how much you've already considered this, but for me the biggest overhead with Span is not the performance overhead but the mental overhead. For example having to deal with potential errors and edge cases caused by the fact that Span can contain calendar units and having to keep in mind that some functions treat 90 seconds and 1 minute 30 seconds as different spans.

I don't know how much you've already considered this, but for me the biggest overhead with Span is not the performance overhead but the mental overhead. For example having to deal with potential errors and edge cases caused by the fact that Span can contain calendar units and having to keep in mind that some functions treat 90 seconds and 1 minute 30 seconds as different spans.

Have you tried writing any code with Jiff yet? If so, would it be possible to share that code and your journey in figuring out how to write it?
It's worth noting that you can only get non-uniform units in your spans if you specifically put them there or request them.

having to keep in mind that some functions treat 90 seconds and 1 minute 30 seconds as different spans.

I think it is only the PartialEq and Eq impls that do this, and I think I'm going to have to remove them for this reason. (There is an open issue about it.) Is there another place where they are treated differently that I'm missing?

Have you tried writing any code with Jiff yet? If so, would it be possible to share that code and your journey in figuring out how to write it?

Nothing substantive, just some small experiments. I've mostly been reading API docs and thinking about how this might work for some projects I've previously worked on. Sidenote: My opinions are probably somewhat by the fact that most of the use cases I'm thinking of work with timestamps, so I would rarely want or need to use calendar units in spans.

It's worth noting that you can only get non-uniform units in your spans if you specifically put them there or request them.

True, but since this isn't enforced at the type level I have to manually keep track of how the span was created and if it might have some kind of problematic units (e.g. calendar units when working with timestamps) in it. I suspect this could get quite tricky if the span is created from user supplied data and/or in a different component of the system.

I think it is only the PartialEq and Eq impls that do this, and I think I'm going to have to remove them for this reason. (There is an open issue about it.) Is there another place where they are treated differently that I'm missing?

The field accessors (get_seconds, get_minutes, etc) as well as serialization and formatting functions. Though these seem mostly useful for introspection and moving data around, so offhand I can't think of any cases where they could cause trouble like Eq and PartialEq can.

I suspect this could get quite tricky if the span is created from user supplied data and/or in a different component of the system.

I think it should be okay? Jiff won't panic in these cases, it will return an error. So if you're adding a Span to a Timestamp and the Span came from user input, you'd just use it like normal and bubble the error up to the user. It will give an error message if, for example, the span contains any non-zero year units.

The field accessors (get_seconds, get_minutes, etc) as well as serialization and formatting functions. Though these seem mostly useful for introspection and moving data around, so offhand I can't think of any cases where they could cause trouble like Eq and PartialEq can.

I'm not sure the getters really apply here because they don't give you a Span. They are giving you its components.
And yes, indeed, PT120s and PT2m are two different serializations of the same span. I don't think this can lead to issues though. And it is permitted by the standard.

Nothing substantive, just some small experiments. I've mostly been reading API docs and thinking about how this might work for some projects I've previously worked on. Sidenote: My opinions are probably somewhat by the fact that most of the use cases I'm thinking of work with timestamps, so I would rarely want or need to use calendar units in spans.

Aye. Any details you can share about your journey would be helpful. Thanks!

I think it should be okay? Jiff won't panic in these cases, it will return an error. So if you're adding a Span to a Timestamp and the Span came from user input, you'd just use it like normal and bubble the error up to the user. It will give an error message if, for example, the span contains any non-zero year units.

Maybe it will be okay. Hard to say without more practical experience. Depending on what you're building you might not have a direct user to bubble the error to (e.g. if you're doing some kind of background processing on a server or a daemon service).

Yeah but there should always be an error channel of some kind. Most of Jiff's API fallible, e.g., due to overflow.

Yeah but there should always be an error channel of some kind. Most of Jiff's API fallible, e.g., due to overflow.

Still, it would be good to catch errors early. A span with calendar units is effectively invalid in some contexts (e.g. working with timestamps) and in those cases the ability to enforce at compile time that calendar units aren't present seems like a useful thing that would reduce mental overhead.

I think adding support for std::time::Duration would fix that right? That's what this issue is for. :-)
But I am really looking for more concrete experiences as opposed to design philosophy. Compile time errors are great, but they must be considered in the context of trade offs.

I think the main alternative point in the design space here is for Jiff to define its own absolute duration type that is signed.

I personally favour defining a signed duration type, because of the clunkiness and complexity that the standard library unsigned duration type brings, but I agree that without concrete experience it is hard to be evaluate the tradeoffs.

Adding my own (limited) experience porting my hobby sensor data platform to jiff.
I have a tui app showing a graph of sensor values from history (can be a year can be a minute). That history length is currently a core::time::Duration. The app fetches data from a custom data-store. The API for that looks like this:
fn get_data(&mut self,
  start: jiff::Timestamp,
  end: jiff::Timestamp,
  reading: protocol::Reading,
  n: usize,
) -> Result<(Vec<jiff::Timestamp>, Vec<f32>), Error>;

Now I would like to use that from a function that gets an core::time::Duration. For that I would ideally call it like this:
api.get_data(
  jiff::Timestamp::now() - length, // length is a core::time::Duration
  jiff::Timestamp::now(),
  reading.clone(),
  300,
)

Alternatively Span::from(length) would work too. I see no way to subtract a core::time::Duration from a Timestamp right now. So currently I am converting to millis then to Span.

Yeah I think #21 will help here. And adding a TryFrom<Duration> for Span should be straight-forward and not have any footguns. A TryFrom<Span> for Duration is somewhat more questionable, but justifiable.

Off topic, does the cat tax apply to docs?

:-( https://x.com/burntsushi5/status/1708169161459855608

The second problem with Duration integration is that it's not clear how to, well, actually integrate it. Does this mean Jiff should grow checked_add_duration and since_duration methods? I think so... And I think this is probably a requirement to satisfying the second use case above, even if we use a different duration type. I do personally find the names with a _duration suffix quite clunky, but perhaps it's fine because these will be considered "niche" APIs IMO.

I think having the APIs similar to:
let duration: Duration = timestamp2.since_duration(timestamp1).unwrap("the difference was negative");
let duration: Duration = timestamp2.until_duration(timestamp1).unwrap("the difference was negative");

let duration: (i8, Duration) = timestamp2.since_duration_signed(timestamp1);
let duration: (i8, Duration) = timestamp2.until_duration_signed(timestamp1);

let duration = Duration::from_secs(1);

let timestamp: Timestamp = timestamp.checked_add_duration(duration).unwrap("overflow");
let timestamp: Timestamp = timestamp.saturating_add_duration(duration);

let timestamp: Timestamp = timestamp.checked_sub_duration(duration).unwrap("overflow");
let timestamp: Timestamp = timestamp.saturating_sub_duration(duration);

Should cover majority of use-cases where simpler "Span" might be enough. For services/libraries working with UTC timestamps, above is really what's needed and we don't need to deal with complexities of relative units in the Span.
Difference between two timestamps. Usually, negative difference means that something is expired, and do no-op. For cases where we are interested in negative values, one can just use since_duration_signed or until_duration_signed.

above is really what's needed and we don't need to deal with complexities of relative units in the Span.

Can you share some code that is more complex than you would like when dealing with Timestamp and Span? There shouldn't be any need to deal with relative units there.
My main gripe is that I'm not a huge fan of vomiting a new group of four methods for every single possible duration type supported.

Can you share some code that is more complex than you would like when dealing with Timestamp and Span? There shouldn't be any need to deal with relative units there.

If we omit the relative spans, I think current API is clean and understandable. It's just that we use std::time::Duration on lot of places and would be nice to use it directly without the overhead and roundtripping through Span.

My main gripe is that I'm not a huge fan of vomiting a new group of four methods for every single possible duration type supported.

Do you foresee any other types for which this would have to be done?

If we omit the relative spans, I think current API is clean and understandable. It's just that we use std::time::Duration on lot of places and would be nice to use it directly without the overhead and roundtripping through Span.

Right, okay, that's what I'm trying to understand. I laid out what I believe are two buckets of user stories: the first is "I already use Duration everywhere and I want to keep using it for ergonomic reasons." The second is, "Span has too much overhead and my performance requirements demand something cheaper." The former specifically calls for integration with std::time::Duration, but the latter actually does not! So it's important to understand where you are here. To be clear, you could be in both camps.
It's not the "relative" aspect of Span that is tripping you up here, since a Timestamp only deals with uniform units on Span. So you should never have to deal with any relative aspects of it. Even if a Span only contains uniform units, it would likely be a problem for you.

Do you foresee any other types for which this would have to be done?

Yes. I mentioned Jiff defining its own signed duration type in the OP. A (i8, std::time::Duration) is pretty unwieldy. We're in a tough spot here because we want integration with std, but std doesn't have a signed duration. So we could make our own signed duration, add one group of additional methods for the signed duration, and then add conversions to and from std::time::Duration on the signed duration type.

OK, I've taken my first crack at integration with std::time::Duration by introducing conversion routines between it and Span. I suspect we still need to do more (like on the datetime arithmetic APIs), but there are thornier questions there. This, by comparison, was pretty straight-forward I think. The new APIs are:

impl TryFrom<Duration> for Span: always works as you'd expect except for failure on overflow.
impl TryFrom<Span> for Duration: errors when the Span is negative or contains non-zero units greater than days. Basically, once you go above days, you need a relative date to fully "resolve" the Span. And there is no way to pass in a relative date for the TryFrom API.
Span::to_duration accepts a relative date and can convert all non-negative spans to durations (excepting overflow). The examples show how to find the number of seconds in 1.year().

These routines aren't difficult for callers to implement on their own, but they're subtle enough with enough failure scenarios that it's definitely worth it for Jiff to provide them for you. And I designed them in such a way that I believe they are impossible to misuse.

Right, okay, that's what I'm trying to understand. I laid out what I believe are two buckets of user stories: the first is "I already use Duration everywhere and I want to keep using it for ergonomic reasons." The second is, "Span has too much overhead and my performance requirements demand something cheaper." The former specifically calls for integration with std::time::Duration, but the latter actually does not! So it's important to understand where you are here. To be clear, you could be in both camps.

I think we are in both camps, with the first one being the bigger concern :)

My main gripe is that I'm not a huge fan of vomiting a new group of four methods for every single possible duration type supported.

I looked at the implementation of how Spans are added to Timestamp:
https://github.com/BurntSushi/jiff/blob/3c3b810dbd82cc37fb75e895d91ad94d7c136240/src/timestamp.rs#L1271
Basically, we could see it as anything that can produce seconds/nanoseconds pair could be added to Timestamp. Can the signature of checked_add (and saturating_add, saturating_sub, checked_sub) be changed to something akin to:
pub fn checked_add(self, span: impl Into<TimestampSpan>) -> Result<Timestamp, Error>

Where TimestampSpan is something similar to:
pub struct TimestampSpan(i64, i32);

Maybe even reuse Timestamp since it can be used for the same concept? Then both Span and Duration can implement From for TimestampSpan:
pub struct TimestampSpan(i64, i32);

impl From<Duration> for TimestampSpan {
    fn from(duration: Duration) -> Self {
        let seconds = duration.as_secs();
        let nanos = duration.subsec_nanos();
        TimestampSpan(seconds as i64, nanos as i32)
    }
}

Now one can use the same set of methods for adding/subtracting both Span and Duration with Timestamp. Wdyt?

Although I would probably use std::time::Duration for it?

Wouldn't std::time::Duration be constraining since it does not support negative values?

The problem is that doesn't work for the since/until methods, which return a Span.

I checked the usage and it does support rounding directly when calling since/until.  Can this be simplified and anyone who wants to round can just do it on the resulting Span?

I talked about signed durations further up. This is part of the problem of the API design here.

I checked the usage and it does support rounding directly when calling since/until. Can this be simplified and anyone who wants to round can just do it on the resulting Span?

I don't see how that would help here? Otherwise, see: https://docs.rs/jiff/latest/jiff/_documentation/design/index.html#what-are-the-zonedifference-and-zonedround-types-for

Here is what I'm currently leaning towards:

Adding a new signed duration type that represents absolute time. Basically, an exact copy of std::time::Duration, but signed instead of unsigned.
Adding support for this new type, and std::time::Duration, to the existing add/subtract APIs on all datetime types. Today, these methods accept a concrete Span. But I think I can make them polymorphic such that they accept any of Span, std::time::Duration or the new signed duration type I mentioned above. This will mean adding a new public target type for each datetime type like ZonedArithmetic. But we already have a bunch of those, so I don't think it's a big deal.
As new since_duration and until_duration APIs that return the new signed duration type. But none for std::time::Duration.
Provide nice ways of covering between the new signed duration type and std::time::Duration.

I think this will cover everything. It provides nearly maximal integration with std and also provides a way to do "just add nanoseconds please" without going through the chunkier Span type that should help with perf.
So... What do we call the signed duration type? I suppose the obvious choice is SignedDuration, but it's kind of a mouthful in my opinion. But maybe that's the best name since it's the least likely to lead to confusion. Another name I kind of like is Elapsed, but it doesn't really help folks understand why it exists, its relationship with std::time::Duration or how it's different from Span. Plus, my hope is that most folks will use a Span most of the time.

Adding a new signed duration type that represents absolute time. Basically, an exact copy of std::time::Duration, but signed instead of unsigned.

Personally, I love this idea and it's exactly what's was missing to me. Span is powerful, but  also comes with lot's of gotchas.

Adding support for this new type, and std::time::Duration, to the existing add/subtract APIs on all datetime types. Today, these methods accept a concrete Span. But I think I can make them polymorphic such that they accept any of Span, std::time::Duration or the new signed duration type I mentioned above. This will mean adding a new public target type for each datetime type like ZonedArithmetic. But we already have a bunch of those, so I don't think it's a big deal.

Perfect!

I think this will cover everything. It provides nearly maximal integration with std and also provides a way to do "just add nanoseconds please" without going through the chunkier Span type that should help with perf.

Should also cover a lot in #17
I suppose the obvious choice is SignedDuration, but it's kind of a mouthful in my opinion. But maybe that's the best name since it's the least likely to lead to confusion.
I like SignedDuration, it explains its purpose pretty well. It's just that, a signed duration. The Elapsed name gives me the vibe of it only being positive, on glance to seems the same thing as Duration.

Yeah, I think I am likely to go with SignedDuration. If folks have any better names, please chime in.
I'll probably also change the Timestamp APIs too. So Timestamp::from_duration will accept a SignedDuration and Timestamp::as_duration will return a SignedDuration. And then drop Timestamp::from_signed_duration. And I'll make Span::to_duration return a SignedDuration. I'll leave the TryFrom impls between std::time::Duration and Span, but add corresponding impls for SignedDuration as well.
So we'll add direct integration with std::time::Duration where feasible, but otherwise insist on the caller using conversion routines between std::time::Duration and SignedDuration.
I think everything above should work. But it will a be a breaking change. I might try to get a slightly tweaked form into a semver compatible release with some deprecations.

but also comes with lot's of gotchas.

I hopefully think the only gotchas are perf related. Otherwise, it should be very hard to misuse.


Some HYMAP2 arrays are not deallocated

Bug Description
Some of the allocated arrays in the HYMAP2 router code are not deallocated.
The good news is that this does not appear to cause an issue in running the code now.
However, to prevent possible future issues, these deallocate statements should be added.
I already have a fix ready to go, and can submit a pull request as needed.
@jvgeiger - should this go into the master branch, or one of the support branches?

If this issue exists in the support/lisf-public-7.4 branch, then I suggest adding this fix there.

Resolved by #1293


Implement a zoom and pan gizmo for the 3d editor

This implementation features the addition of 2 new gizmos on the 3D editor view on the top right. These 2 gizmos that can be dragged on either with a mouse or touch to either zoom in or out (for the first gizmo) or pan the camera vertically or horizontally (for the second gizmo) depending on the direction of the drag. These can be enabled and disabled in the Editor Settings in the tab Editors/3D/Navigation.

Check out this project: https://github.com/7AXEL/Web2APK

You need a rebase, you're very far behind on your branch

Some kind of screenshot would be nice for discussion.

Some kind of screenshot would be nice for discussion.

Sure, should I send it in this conversation?

Can you write a proposal? Typically you would attach the screenshot either in the proposal or in the pull request.
https://docs.godotengine.org/en/stable/contributing/workflow/pr_workflow.html
https://github.com/godotengine/godot-proposals


Update bot yaml

Summary
In #9835 Manoel was removed from codeowners. This removes him from the bot yaml file and for algorithms replaces him by @ElePT
Details and comments

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.02%) to 85.408%

Totals

Change from base Build<PHONE_NUMBER>:
-0.02%

Covered Lines:
67552

Relevant Lines:
79093

💛  - Coveralls


fix: small deprecation issue

Houston looks like react-native ^0.70 in the market and has a lot of braking changes.
Here is a little push-up for the library

can anyone having the access merge this and release this 1.0.2 version ?


我的信息修改完了 但是没有输出那些信息  请问该怎么做 ？

—
Reply to this email directly, view it on GitHub
https://github.com/ARC-MX/sgcc_electricity_new/issues/74#event-15715445318,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AWCZAGGX6PAYAXDCNE2MHSD2GKPBRAVCNFSM6AAAAABT4KVIIKVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJVG4YTKNBUGUZTCOA
.
You are receiving this because you authored the thread.Message ID:
@.***>


Exporting v4 Middleware

I am in the process of upgrading to v4.1.1 and I was wondering if there was a way to export the validation middleware.
My app.js looks something like this
const { check, validationResult } = require('express-validator/check');
const { matchedData } = require('express-validator/filter');

const userController = require('./controllers/user');
app.get('/login', userController.getLogin);
app.post('/login',[check('email').isEmail().withMessage('Email is invalid'), check('password', 'passwords must be at least 5 chars long and contain one number').isLength({ min: 5 })], userController.postLogin);

With the controller just being a simple validation.
exports.postLogin = (req, res, next) => {
  try {
    validationResult(req).throw();
 } catch (err) {
	if(err.mapped().email){
		req.flash('errors',{ msg:  err.mapped().email});
		return res.redirect('/login');
	}
}
  ...

I was wondering if there was a way to export the middleware and define it in the controller. Looking something like this:
exports.validateEmail = [check('email').isEmail().withMessage('Email is invalid'), check('password', 'passwords must be at least 5 chars long and contain one number').isLength({ min: 5 })];

Thanks for any help.

+1
I followed the migration doc, IMO this is not intuitive as v3

This should be perfectly fine. This is express-supported syntax, so it should just work!

I mean, the "reuse" aspect of express-validator v4 is that check and oneOf functions return middlewares, so you can use them anywhere express accepts a middleware function.
// shared-validators.js
exports.login = [
  check('email').isEmail().withMessage('blabla'),
  check('password').exists(),
  (req, res, next) => {
    try {
      validationResult(req).throw();
      next();
    } catch (err) {
      res.json(422).json({ errors: err.mapped() });
    }
  }
];

// controllers.js
app.post('/login', sharedValidators.login, proceedNormalLogin);
app.post('/admin/login', sharedValidators.login, proceedAdminLogin);

Thanks for the response. I finally realized that the reason it was not working was that I was submitting a multipart/form-data, which needed a middleware that I called later.


Styled-theming them function/object passed to attrs is now invalid with version 4.3.2

This code works very well using version 3
import { List, ListItem } from 'material-ui/List';
import theme from 'styled-theming';

const menuHoverColor = theme('mode', {
  midnight: colors.menuHoverBgMidnight,
  florida: colors.menuHoverBgFlorida,
  goldenstate: colors.menuHoverBgGoldenState,
  salmon: colors.menuHoverBgSalmon,
  gogo: colors.menuHoverBgGogo,
  darkmatter: colors.menuHoverBgDarkMatter
});

const innerDivStyle = {
  padding: '0px 0px 0px 50px',
  fontFamily: 'Lato, sans-serif',
  fontSize: '12px',
  fontWeight: '700',
  textTransform: 'uppercase',
  position: 'relative',
  lineHeight: '41px'
}

const hoverColor = menuHoverColor;

const StyledListItem = styled(ListItem).attrs({
  innerDivStyle,
  hoverColor
})`

Since I switched to 4.3.2, I changed syntax of attrs method.
const StyledListItem = styled(ListItem).attrs(props => ({
  innerDivStyle,
  hoverColor
}))`

However, I'm getting an error now.
proxyConsole.js:56 Warning: Failed prop type: Invalid prop hoverColor of type function supplied to ListItem, expected string.

@c0debreaker I just looked at the docs for styled-theming and it doesn't mention anything about composing it via attrs: https://github.com/styled-components/styled-theming
I'd recommend using it in the way it was designed...

Got it. It was the solution that Max told me two years ago. I'll see what I can find. Thanks.

Gotcha, maybe invoke the function instead of just passing it?
hoverColor: hoverColor(props)

I removed .attrs and got it to work. I moved it as a component now. Not sure how code looks but I feel it's more customizable. I'm not sure if it's acceptable to call it composable.
import React from "react";
import { ListItem } from 'material-ui/List';
import styled from 'styled-components';

export default styled(({ menuColor, hoverColor, innerDivStyle, ...otherProps }) => (
  <ListItem {...otherProps}/>
))`
  > div > div {
    ${props => props.innerDivStyle};
  }
  :hover {
    background: ${props => props.hoverColor} !important;
  }
  color: ${ props =>  props.menuColor } !important;
  border-bottom: 1px solid #60606033 !important;
`;


⚠ Bofrost.be has degraded performance

In 427fe1b, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1828 ms

Resolved: Bofrost.be performance has improved in 83b68ba.


Implementation of triangle counting (TC) algorithm in DAPHNE DSL

Issue to follow the development of triangle counting (TC) in DAPHNE DSL. An initial code is available in daphne/scripts/algorithms/tc.daph. However, it requires sparse to sparse matrix multiplication to be available in DAPHNE.

A possible reference implementation can be found at: https://github.com/sbeamer/gapbs
Also, implementations of TC in C++, Python, and Julia will be available in daphne/scripts/algorithms/alternative-implementations/tc/


How do I get the native binaries for a Managed-only build?

I'm trying to do a managed-only build by following the instructions here since I wasn't able to get the externals/skia native builds to complete without compilation errors (in GrAHardwareBufferImageGenerator.cpp, line 217, GrBackendTexture backendTex: no matching constructor).
However, I don't know how to get the correct Azure Build IDs. If I go to the Azure build page and pick one of the builds from SkiaSharp (Public) that appears to have built successfully with a green tick (e.g., build 3348) ) and copy the buildId from the URL (e.g., 3348), and use that with the bootstrapper,
./bootstrapper.sh -t externals-download --azureBuildId=3348

(Also tried "3348" in quotes.)
I get the following error:
========================================
externals-download
========================================
An error occurred when executing task 'externals-download'.
Error: One or more errors occurred. (One or more errors occurred. (404 (Not Found)))
	404 (Not Found)

I found the AZURE_BUILD_URL that the SkiaSharp/build.cake and SkiaSharp/cake/BuildExternals.cake build scripts use to download the native binaries in a zip file. Using that URL with the buildId and "native" for the artifactName field, I get the following error:
{"$id":"1","innerException":null,"message":"Artifact native was not found for build 3348.","typeName":"Microsoft.TeamFoundation.Build.WebApi.ArtifactNotFoundException, Microsoft.TeamFoundation.Build2.WebApi","typeKey":"ArtifactNotFoundException","errorCode":0,"eventId":3000}

I've tried several of the other builds and also the ones from SkiaSharp.Extended (Public) and they all return the same error.
Is there a way I can figure out which builds contain the native binaries without guessing?
Thank you.

You can download them from here https://dev.azure.com/xamarin/public/_build/results?buildId=3348

https://dev.azure.com/xamarin/public/_build/results?buildId=3348

Do I click on the Artifact button and just select any/all of the options? When I tried that, I get the following error:
{"$id":"1","innerException":null,"message":"TF400813: The user '<github user id>' is not authorized to access this resource.","typeName":"Microsoft.TeamFoundation.Framework.Server.UnauthorizedRequestException, Microsoft.TeamFoundation.Framework.Server","typeKey":"UnauthorizedRequestException","errorCode":0,"eventId":3000}

You should be able to download the nuget.zip

You should be able to download the nuget.zip

Ah, thank you! I was able to download just that file, which contains all the built nupkgs.
My partially built output folder seems to have a different layout with nuget subfolders:
output/
    HarfBuzzSharp/
        nuget/
    SkiaSharp/
        nuget/
    SkiaSharp.HarfBuzz/
        nuget/
    SkiaSharp.Views/
        nuget/
    SkiaSharp.Views.Forms/
        nuget/

so I'm guessing I have to unzip the contents of the nupkgs into their respective nuget subfolders in order to get the Managed-only build to be able to use them?
Thanks again and apologies for all the questions as I'm rather new to SkiaSharp.

For example: SkiaSharp\output\native\windows\x64

Thanks! I wouldn't have known to add a native subfolder under output.
I found runtime//native subfolders with the binaries (dll, dylib, so, no pdbs), so I'll try that tomorrow.
Really appreciate your help!

Unfortunately, the nuget.zip seems to be missing the android, ios, tvos, watchos binaries and it's quite hard to figure out all the subfolder names that the binaries should go into. e.g., For tizen, the build appears to look for i386, while the nuget has the binaries in tizen-armel, tizen-x86 folders, etc.
Is there another way to get the native.zip or to get the "externals-download" target to work for people without access to the Azure Build pipeline so that this line in the documentation works?
./bootstrapper.ps1 -t externals-download --azureBuildId=<build-id>

Thanks.

You can also download the package from Nuget.org https://www.nuget.org/api/v2/package/SkiaSharp/1.68.0

You can also download the package from Nuget.org https://www.nuget.org/api/v2/package/SkiaSharp/1.68.0
But downloading the externals directly from CI is probably the best.
To test things added to the binding you don't need to use the bootstrapper.ps1 you can just build the projects directly

This doesn't seem to have the android, ios, etc folders and binaries as well. The nuget.zip that I managed to download for build 3348 has a similar structure as this (except it's a later version 1.68.1).
If there is a way to download the externals (I'm guessing native-default, native-*, under Artifacts) from CI without contributor permissions, please let me know how.
My goal is actually to try to update the SkiaSharp and SkiaSharp.Views.Forms managed libraries for netstandard 2.0 and Xamarin.Forms 4.0 for use with Fabulous (F#), which is still on SkiaSharp 1.60.3 and is missing the SKGLView, but I wanted to learn to build the whole project from scratch if possible.
I'll try building just the ones I need without the bootstrapper then. Just running into a lot of issues especially with Android.

@danien you can download the native-default artifacts to just get all the native assets, and the nuget artifact to get all the nupkgs.
For example, it you are getting the bits for build 3425, you can go to that build:
https://dev.azure.com/xamarin/public/_build/results?buildId=3425
And then download the native-default artifact:

Once this PR is merged (https://github.com/mono/SkiaSharp/pull/889), you should be able to access the artifacts.
So we will have 2 public artifacts:

native-default - for accessing all the native assets from all the platforms
nuget - for accessing all the packaged NuGets for all the platforms

If you need a REST endpoint, you can use:
https://dev.azure.com/xamarin/public/_apis/build/builds/BUILD_ID/artifacts?artifactName=ARTIFACT NAME&%24format=zip

Where:

BUILD_ID is the build ID (eg: 3425)
ARTIFACT NAME is the artifact name (eg: nuget or native-default)

Confirmed that it works. Also confirmed that it works with building the rest of the project using
.\bootstrapper.ps1 -t everything --skipExternals=all

after unzipping the contents into the output/native folder.
Should the "externals-download" task in cake/BuildExternals.cake be updated from "native" to "native-default" for the artifact name as well?
Task ("externals-download")
    .Does (() =>
{
    ...
    var url = string.Format(AZURE_BUILD_URL, AZURE_BUILD_ID, "native-default");
    ...
});

(For convenience, here's the Azure build Id #3459.)

Should the "externals-download" task in cake/BuildExternals.cake be updated from "native" to "native-default"

Good catch, yes it should be native-default.
And the rename should just be a matter of moving the dir after extraction:
MoveDirectory ("./output/native-default", "./output/native");

Do you want to edit the file? Then you can join the ranks as a SkiaSharp contributor.

Do you want to edit the file? Then you can join the ranks as a SkiaSharp contributor!

Cool. I've submitted a pull request #892 for your review but if it's easier, I've added the code from the BuildExternals.cake file here.
I'm new to Github contributions, so let me know if I'm doing anything wrong. Thanks again!
Task ("externals-download")
    .Does (() =>
{
    if (string.IsNullOrEmpty (AZURE_BUILD_ID))
        throw new Exception ("Specify a build ID with --azureBuildId=<ID>");

    var artifactName = "native-default";
    var artifactFilename = $"{artifactName}.zip";
    var url = string.Format(AZURE_BUILD_URL, AZURE_BUILD_ID, artifactName);

    var outputPath = "./output";
    EnsureDirectoryExists (outputPath);
    CleanDirectories (outputPath);

    DownloadFile (url, $"{outputPath}/{artifactFilename}");
    Unzip ($"{outputPath}/{artifactFilename}", outputPath);
    MoveDirectory ($"{outputPath}/{artifactName}", $"{outputPath}/native");
});

@danien you did everything right! Merging!


python scripts/preload_models.py  warning     python scripts/dream.py    error

/Users/jc/miniforge3/envs/invokeai/lib/python3.9/site-packages/torchvision/models/_utils.py:208: UserWarning: The parameter 'pretrained' is deprecated since 0.13 and will be removed in 0.15, please use 'weights' instead.
warnings.warn(
/Users/jc/miniforge3/envs/invokeai/lib/python3.9/site-packages/torchvision/models/_utils.py:223: UserWarning: Arguments other than a weight enum or None for 'weights' are deprecated since 0.13 and will be removed in 0.15. The current behavior is equivalent to passing weights=None.
warnings.warn(msg)
from ._greenlet import _C_API # pylint:disable=no-name-in-module

ImportError: dlopen(/Users/jc/miniforge3/envs/invokeai/lib/python3.9/site-packages/greenlet/_greenlet.cpython-39-darwin.so, 0x0002): tried: '/Users/jc/miniforge3/envs/invokeai/lib/python3.9/site-packages/greenlet/_greenlet.cpython-39-darwin.so' (mach-o file, but is an incompatible architecture (have (x86_64), need (arm64e)))

The deprecation warnings are annoying but not a fatal problem. The bad part is the ImportError, which appears to be a broken python and/or system library install. There are two libraries built for different architectures fighting each other.

It looks like some libraries are x86. Did you update the existing environment to arm64 or did you create a new environment from scratch?

@nickraimondi There is a similar issue here https://github.com/invoke-ai/InvokeAI/issues/730#issuecomment-1254903003
Maybe pip cache purge would help, but if you got it to work, I wouldn't want to mess around and try :)
Anyway, glad it's solved!

While the resolution isn't clear, the issue is indeed resolved; closing.

Had the same issue, managed to solve it in the same way as @nickraimondi
Just go over that process a few times.
I also included pip cache purge as @Any-Winter-4079 suggests


Update doc

Add in the doc the images of the new UI
Update README
Add image explaining the how the bridge works
Remove unused EventCreator.js
Fix transfer.js for local tests
Record the lastestBlock searched for events, even if there weren't any events. This was done because the number of blocks that we where asking to the getLogs rpc method was getting too big.

Added @owans to check also the documentation

I'm on it😀 @jonathansmirnoff
On Thu, Apr 30, 2020 at 5:19 PM Jonathan Smirnoff<EMAIL_ADDRESS>wrote:

@jonathansmirnoff commented on this pull request.
LGTM.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rsksmart/tokenbridge/pull/113#pullrequestreview-403676948,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJTZB3Y3MSLRW6OIN3MGO53RPGQJ5ANCNFSM4MT5E6HQ
.

Removed all of this documentation from the


Provide map() and map_mut() for par_iter_mut()

What problem does this solve or what need does it fill?
For when you need to iterate through a query and generate some sort of result from each of the parallel iterators. e.g. reading websockets of sessions and then returning the locally collected requests, flattening it and collecting them all into a single requests list for further processing.
What solution would you like?
I would like map() and map_mut() (because websocket readers require mutable access). They should be used like so:
fn read_ws(mut query: Query<(&mut WsReader)>) {
  let reqs = query
    .par_iter_mut()
    .map_mut(|(mut ws_reader)| {
      let mut reqs = Vec::new();
      // ... reading from the ws reader
      reqs
    })
    .flatten()
    .collect::<Vec<_>>();
}

What alternative(s) have you considered?
The alternative is cumbersome, but doable:
let len = query.iter().len();
let mut i = AtomicUsize::new(0);
let mut reqs = Arc::<Vec<MaybeUninit<Vec<wire::Req>>>>::default();
reqs.resize_with(len, || MaybeUninit::uninit());
query.par_iter_mut().for_each_mut(|(mut ws_reader)| {
  let local_i = i.fetch_add(1, std::sync::atomic::Ordering::AcqRel);
  let mut local_reqs = Vec::new();
  // ... read from ws
  reqs[local_i] = MaybeUninit::new(local_reqs);
});

let reqs = unsafe { std::mem::transmute::<_, Vec<Vec<Req>>>(results) };
// do something with reqs

As you can see, not very pretty.

Fully on board with this. Do we want filter and fold as well?

Might as well!

note that for this specific use case it's probably better to do what bevy is doing internally and use the thread_local crate and store the thread local inside of a Local<T>, so that you can reuse the allocations. https://github.com/bevyengine/bevy/blob/6f2a5cb862d747c9068bf83996c6c1a9f9d3b901/crates/bevy_render/src/view/visibility/mod.rs#L385-L386
We have this PR to make that pattern more ergonomic https://github.com/bevyengine/bevy/pull/7348.
For more parallel iterator methods, we have a bunch of traits in bevy_tasks that used to be implemented on queries, but were not ported over with the ecs v2 rewrite. I'm not sure if we should use those or just throw them away and write something else.


dds-stream-sensor-bridge and on-demand streaming, with very basic ROS2 compatibility

Just to gather initial feedback/questions at this point.

I still don't completely understand the bridge, and lots of the names are not clear enough.
There are public methods like add_implicit_profiles and commit that even with the comments I don't feel like I understand when to call them and if it is needed to call them at all.
Aren't stream_bridge::is_explicit and stream_bridge::is_implicit opposites?
I kind of feel like the bridge should be dds_sensor_based_device_sensor inheriting from dds_device_sensor, and maybe even in the application level not realdds.

I don't have any more comments at the moment.
I still don't like the name dds_stream_sensor_bridge and the naming of some of it's methods but I don't have better names.


Update README.md

My neme is a akashmitha deneth
My school is a kotte ananda shaththralaya
I am 13 years old

Hi my name is a akashmitha deneth
My school kotte ananda shaththralaya
My like game free fire ❤


Draw features style example

See #14912 for the history of this. I accidentally closed #14912.

Thanks, @celia1020