OCPBUGS-20654: bump net/http2 to fix CVE-2023-44487 in OCP 4.14

- What this PR does and why is it needed

- Special notes for reviewers

- How to verify it

- Description for the changelog

/lgtm

/jira refresh

/jira refresh

/label backport-risk-assessed

/label cherry-pick-approved


Update Generic Pages “our-mission”

Automatically generated by Netlify CMS

👷 Deploy Preview for anatidaephobia processing.

Name
Link

🔨 Latest commit
db0c408f1398e2fe8b323e057099e7473836cb64

🔍 Latest deploy log
https://app.netlify.com/sites/anatidaephobia/deploys/6244b34d1cfd6d000899fe70


Added Windows  8.1 & 10 OS Support

Since Windows 8.1 Microsoft changed Win32 GetVersionEx that .Net uses for compatibility reasons report latest version app is compiled for.
This PR adds manifest aware of 8.1 & 10 to the Cake.exe, so System.Environment.OSVersion reports correct version up to Windows 10.
Example cake
Information("OSVersion version: {0}", System.Environment.OSVersion);

Before fix it returns 6.2 on 8.1 & 10, after fix it returns 6.3 and 10.0.
Example output on Windows 10 build 10049 before fix
OSVersion version: Microsoft Windows NT 6.2.9200.0

Example output Windows 10 build 10049 after fix
OSVersion version: Microsoft Windows NT 10.0.10049.0

Merged! :+1:


docs: update star history chart using star-history.com

Looks nicer

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

@tianzhou The current one has Y coordinate on the right side, help us read the latest number easier. Also, the current font is boring, but easy to read.

@davies understood. I will close this PR then.


Deprecate use of __INLINED

__INLINED looks like a compiler internal reserved word.

We don't have to remove it for the release, but we should consider removing it in the future. The steps should be:

Make an optimization pass to automatically convert if conditions to compile-time removal
Mark it as deprecated and remove it from the public documentation
Remove it and see if users complain
Remove it entirely.

I did some more thinking about this today, and had some realizations:
Deprecating __INLINE would mean that there would no longer be a way to specify “dead code” in a stencil, and therefore there would be no reasonable situation where passing None as a field value to a stencil makes sense.
Therefore we would also have to deprecate and remove the ability to give fields default values of None in the definition function type hint* and the ability to pass None as for instance this test does.
*: This behavior was “broken”/inconsistent anyway, since the type hint did not specify Optional[Field[...]] = None, rather it took the form Field[...] = None, which is wrong.
I believe this will break @stubbiali's workflow, but it will clean up this very messy business parameter matching after pruning, since there will be no pruning!

Thanks @jdahm for making me aware of this development path. In principle, I don't have anything against dropping the __INLINED construct. Removing the ability to make fields default to None is a surely more problematic for Tasmania, but nothing which cannot be worked-around. At worst, we can always pin GT4Py to an older commit. No problem for FVM though, as we don't make use of either feature.

However, according to your first bullet point above:

Make an optimization pass to automatically convert if conditions to compile-time removal

it sounds like you aim to remove the __INLINED syntax, but not the ability to have and detect dead code, should the if-condition be evaluable at compile-time. So do we really need to prevent fields from defaulting to None? I'm not disputing the usefulness of such a change, but rather the connection between the two features.

Was deprecated in #1068


Make test names consistent

@sagar23sj - would you mind giving me an LGTM+Approval on this one if you agree, please?

Sure @gmlewis
LGTM.

There are few files remaining @gmlewis. I have listed them below

licenses_test.go
orgs_test.go
pulls_reviewers_test.go

would you like me to push the commit for remaining files ??

Sure, @sagar23sj ... Thank you!

If it's ok with you and you have'nt already started working, i can raise PR for the remaining ones @gmlewis

If it's ok with you and you have'nt already started working, i can raise PR for the remaining ones @gmlewis

Perfect... thank you, @sagar23sj !


CHR

@budparr somewhere on the Project website we should have the ABA CHR logo and link to its page. The most logical spot is somewhere on the About the Project page. Let's think of where to put it.

I added this to the copy on the about page


can you kindly tell me admin password, i have changed from adminpanel admin password but still invalid

can you kindly tell me admin password, i have changed from adminpanel admin password but still invalid

@ScorpionGuzel I don't remember there is a way to change admin password from admin panel or not. BTW for admin
USERNAME<EMAIL_ADDRESS>PASSWORD: admin
Thank you.

@ScorpionGuzel  If it has resolved your issue please close this.


Added bower.json allowing library to be managed as a dependency using…

… Bower

Thanks for contributing!


localStorage.setItem inside read?

I can see why you write
localStorage.setItem(source, '{}')

inside your read here but it still feels dangerous as you would expect read accessor to be idempotent side-effect-free.
Perhaps moving it outside into some kind of setDefault function?
EDIT. It is actually idempotent but not side-effect-free.

Good point. Actually I don't even think that's necessary anymore so I'll roll out a change to fix that. Thanks!

@dmitriz
What do you think of this then?
https://github.com/AriaFallah/mobx-store/blob/master/src/index.js#L10

https://github.com/AriaFallah/mobx-store/commit/d0b9e91380f31ee0169e05a76057b66f4907e65e

If I understand it right, the object db sets the default state, which is somewhat confusing to expect from an object ;)
Maybe separately create it and then setDefault? These feel like 2 separate responsibilities.
Ideally you want to make it easy for people to set their store, but at the same time have clever defaults.

@dmitriz Basically if you do
store('test').push(1)

it'll create store('test') for you instead of throwing store('test').push is not a function.
You can set the default state when you first make your store
const store = mobxstore({ test: [1, 2, 3] })

The proposed change is to make
store('test').push(1)

break and first you have to do something like
store.set('test', [])
// now we can do
store('test').push(1)

Does store('test') create or access the store? From its name, I would expect the second.
How about createStore('test') to create and store('test') to access? So I can be safe to know, store is side-effect-free, and createStore will have its explicitly declared side-effect responsibility.
Then createStore will overwrite the store, which I don't expect from an accessor.
So yes, if the store test does not exist, and you do set('store').push(1), I would expect it to throw exception that I can quickly see rather than do some magic silently for me.
That is the general complaint about frameworks "doing magic" vs libraries giving enduser more control.
Also store.set('test', []) feels like applying write accessor to the store already defined.
I still prefer createStore because it is impossible to confuse for anything else:
myDefaults = []
emptyStore = createStore('test')
defaultStore = createStore('test', {defaults: myDefaults })

emptyStore.push(1) // error: undefined not an array
defaultStore.push(1) // [1]


All the role pooltype to be specified by the sgmetadata dict

I've checked the contents of sgmetadata and their respective classes in clusto. Nothing will change in production.


Update Package.swift to swift-tools-version 5.5

Why
Issue: #1147
The current Package.swift is not valid as .macOS(.v12) was introduced in 5.5.
What
Changed the swift-tools-version to 5.5

can someone please take a look and merge this? This is breaking our library builds


Move msi-auth-token-provider-jar to sdk/identity

This PR moves the stand-alone library that was in authroization/msi-auth-token-provider-jar to sdk/identity/microsoft-azure-authentication-msi-token-provider. My proposal is that we build this with the identity library since its a rough analogue to what azure-identity is - but for track 1 library scenarios.

/cc @Azure/azure-sdk-eng

Referencing parent POM tidy up issue for tracking purposes: #4289

Yes, to @weshaggard's comment, I would like @schaabs to weigh in on this before merging.

I'd really prefer not to move any track 1 authentication classes into identity.  The plan is to move all the client libraries onto the Track 2 TokenCredential and the track 1 credential types while possibly still supported will be deprecated in favor of the credential types in azure-identity.  Having track 1 credential types in here will end up being confusing as it will seem there are multiple ways of authenticating with MSI.

Had a chat with @weshaggard - we aren't going to die on this hill :)
I'll relocate it to the authorization folder under SDK so that we keep the status quo - though I'll register my passing protest on this one since it literally does exactly the same thing that ManagedIdentityCredential does ;)

OK - so with that done - could I get an approval or two and I can merge this in (once the builds pass).


Support typing.Union styles of imports

Currently, we only support checking from typing import X. We should expand this to fit other styles of typing imports:
import typing
typing.List

import typing as t
t.List

Resolved in v0.0.3!


Spawn airplanes

Airplanes are spawned on a two second timer along the edge of the map. The implementation makes heavy uses of reference counters to ensure that the map, airplane spawner, and the airplanes themselves use the same nodes in the routing grid. While this is not strictly necessary at this time, it is an important requirement for more dynamic maps in the future (e.g. nodes that change their restriction status while playing).

Codecov Report

Merging #267 (2d37fca) into 0.4.0-dev (c61a2cf) will decrease coverage by 7.66%.
The diff coverage is 28.91%.

@@              Coverage Diff              @@
##           0.4.0-dev     #267      +/-   ##
=============================================
- Coverage      59.36%   51.70%   -7.67%
=============================================
  Files             22       25       +3
  Lines            219      294      +75
=============================================
+ Hits             130      152      +22
- Misses            89      142      +53

Impacted Files
Coverage Δ

game/simulation/src/bus/event.rs
0.00% <ø> (ø)

game/simulation/src/lib.rs
84.61% <ø> (ø)

game/simulation/src/map/mod.rs
30.76% <0.00%> (+30.76%)
:arrow_up:

game/simulation/src/state/mod.rs
85.71% <ø> (ø)

game/simulation/src/entity/spawner.rs
10.71% <10.71%> (ø)

game/simulation/src/map/grid.rs
60.00% <60.00%> (ø)

game/simulation/src/component/flight_plan.rs
100.00% <100.00%> (+50.00%)
:arrow_up:

game/simulation/src/entity/airplane.rs
100.00% <100.00%> (ø)

game/simulation/src/map/loader.rs
85.71% <100.00%> (+0.86%)
:arrow_up:

game/simulation/src/state/running.rs
100.00% <100.00%> (ø)

... and 4 more

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


Box2d shouldn't be as external repo

golang has fairly good tooling to pull external libraries from github, all we need to do is:

run go get -u github.com/ByteArena/box2d
refer to that package in imports: import "ByteArena/box2d"
add that information to README :)

Yep, I and @Yuto3S already discussed this. We should remove that submodule

Submodule removed


TwoBucketPropagationEngine doesn't work in 3.3.2

Hello,
TwoBucketPropagationEngine is unfunctional for my problem in 3.3.2, following exception is thrown. When SevenQueuesPropagatorEngine was used, no problem happened but as in previous versions of choco3 performance is very bad compared to TwoBucketPropagationEngine.
No explicit propagation happened before start of the solver.
Tomorrow I can try to make minimal example for testing of the issue.
Best regards,
Jan
Exception in thread "main" org.chocosolver.solver.exception.SolverException: Cannot schedule coarse event for low priority propagator.
at org.chocosolver.solver.propagation.hardcoded.TwoBucketPropagationEngine.delayedPropagation(TwoBucketPropagationEngine.java:375)
at org.chocosolver.solver.constraints.Propagator.forcePropagate(Propagator.java:316)
at org.chocosolver.solver.constraints.nary.sum.PropSumBoolIncr.propagate(PropSumBoolIncr.java:114)
at org.chocosolver.solver.propagation.hardcoded.TwoBucketPropagationEngine.propagateFine(TwoBucketPropagationEngine.java:257)
at org.chocosolver.solver.propagation.hardcoded.TwoBucketPropagationEngine.propagate(TwoBucketPropagationEngine.java:212)
at org.chocosolver.solver.search.loop.PropagateBasic.execute(PropagateBasic.java:47)
at org.chocosolver.solver.search.loop.SearchLoop.launch(SearchLoop.java:206)
at org.chocosolver.solver.Solver.solve(Solver.java:1099)
at org.chocosolver.solver.Solver.findOptimalSolution(Solver.java:1000)
at org.chocosolver.solver.Solver.findOptimalSolution(Solver.java:1012)

I finally reproduce your case. I let you know when the patch is ready to be released.

Great, thanks for fast response.

This has to do with the incremental version of PropBoolSum which is a low priority propagator, and low priority propagators are not allowed to delayed coarse propagation.
A quick fix is to change Settings.java to disable the use of the incremental version of the propagator:
Solver solver = new Solver();
solver.set(new Settings() {
    @Override
    public boolean enableIncrementalityOnBoolSum(int nbvars) {
        // return nbvars > 10; // default test
        return false;
    }
});

Another patch, closest to the correction I'll bring, would be to allow low priority propagator to schedule coarse propagation :
Solver solver = new Solver();
solver.set(new Settings() {
    @Override
    public short[] getCoarseEventPriority() {
        return new short[]{0, 0, 0, 0, 1, 2, 3};
    }
});

Indeed, I need to re-evaluate the possibility to schedule low priority propagator.

Both quick fixes seem to work.


Fix conditional dependencies in root packages

SwiftPM's build system always build every target that's part of a root package, regardless of its reachability in the graph, supposedly to ensure all the code in the root package will get exercised. This is of course fundamentally incompatible with the idea of conditional dependencies and therefore causes user confusion.
The most reasonable way to resolve this seems to be to exclude any target that's conditionally depended upon with a condition unfullfiled by the current build environment from building automatically because of its presence in the root package. This does not change what gets built based on dependencies, so degenerate cases where a target is depended upon both conditionally and unconditionally will not be affected. Because of this, it seems reasonable to not tie the new behavior to the tools-version.
rdar://97751068

@swift-ci please smoke test

Looks like the older compiler can't actually compile my code, will address
[1103/1135] Compiling PackageGraph PackageGraph.swift
/Users/ec2-user/jenkins/workspace/swift-package-manager-with-xcode-self-hosted-PR-osx/branch-main/swiftpm/Sources/PackageGraph/PackageGraph.swift:86:54: error: generic parameter 'ElementOfResult' could not be inferred
            let unsatisfiedDependencies = $0.targets.flatMap { $0.dependencies.filter { !$0.satisfies(buildEnvironment) } }.compactMap {
                                                     ^
Swift.Sequence:2:28: note: in call to function 'compactMap'
    @inlinable public func compactMap<ElementOfResult>(_ transform: (Self.Element) throws -> ElementOfResult?) rethrows -> [ElementOfResult]
                           ^
/Users/ec2-user/jenkins/workspace/swift-package-manager-with-xcode-self-hosted-PR-osx/branch-main/swiftpm/Sources/PackageGraph/PackageGraph.swift:95:36: error: cannot convert return expression of type 'Set<ResolvedTarget>' to return type 'ResolvedTarget?'
            return Set($0.targets).subtracting(unsatisfiedDependencies)
                   ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/ec2-user/jenkins/workspace/swift-package-manager-with-xcode-self-hosted-PR-osx/branch-main/swiftpm/Sources/PackageGraph/PackageGraph.swift:85:29: warning: 'flatMap' is deprecated: Please use compactMap(_:) for the case where closure returns an optional value
        return rootPackages.flatMap({
                            ^

Hm, 5.6 is crashing for me locally, so not sure how to figure out the issue here. Maybe we should move CI to 5.7 at this point?

Fixed compilation with the 5.6 toolchain.

@swift-ci please smoke test

Added a test now.

@swift-ci please smoke test


Make it interactive

This is assigned as part of the project.  closing this one.

I have added the ability to use a call to call the messaages.

Renan has acheived interactivty and also so has Marco.  Just getting them inline with the app and the progression.


Error when cancelling login

When I tried to login with Facebook provider, the connect user didn't own right to connect (app not released, and user not a tester). So I just click on the back button (android 5), and the app crashed. This happen with other failed or cancelled login process I didn't record.

java.lang.RuntimeException: Failure delivering result ResultInfo{who=null, request=64206, result=-1, data=Intent { (has extras) }} to activity {fr.xxx.app.aaa/fr.xxx.app.aaa.MainActivity}: java.lang.NullPointerException: Attempt to invoke virtual method 'android.view.View android.view.View.findViewById(int)' on a null object reference

    @Override
    protected void onFirebaseLoginProviderError(FirebaseLoginError firebaseLoginError) {
        Log.e("FB Prov", firebaseLoginError.toString());
        resetFirebaseLoginPrompt();
    }

Closing because the 0.4.0 version uses different logic, please open a new issue if the new version does not fit your needs for a situation like this.


Some problems in training

Hello! Thank you very much for your wonderful project! I have solved the problem of the last route. However, I found the training was slow, and it took me about 15 days to run 200 epoch with a v100. What equipment do you use for project training? How long will it take to train? Is there a way to speed up training? Thank you!

Hello! We measured training iterations instead of epochs. All models on VG were trained for 300k iterations and on CLEVR for 40k iterations. Training on an Nvidia RTX 2080 Ti GPU, for images of size 64 × 64 takes about 3 days for Visual Genome and 4 hours for CLEVR.


Mocky.io "503 Service Unavailable"

Hi Everyone!
I'm using nz-upload of Ng-Zorro which POST an API on every file upload to "https://www.mocky.io/v2/5cc8019d300000980a055e76" using its nzAction attribute which produced "503 Service Unavailable" error, almost every time.
I also tried by removing nzAction attribute but nz-upload won't work without it.
Any guesses?

We're not quite sure how this pertains to Prism. We're going to close this for now. Feel free to open this back up with further explanation about how Prism is involved.

I found working mocky url. It worked for me
https://run.mocky.io/v3/530e60ce-f689-4ea8-9f22-57fefa8ec1eb


Add charge unit preference

All platforms
0.7.0
Charge is currently displayed in the SI units of coulombs (C).  However, many applications prefer to use amp-hours (Ah).  We should create a preference that the user can select, and then ensure that it is respected throughout the UI, including the displays for:

Single value
Waveform statistics (right of curve area)
Dual markers

See forum for more details.  This enhancement is now the most requested new feature.


Hydra Boosts

Currently receiving boosts for both TBow and Lance/Fero at Hydra, should be tbow or lance and gloves

`

Also both if training ranged


Add option to ignore files from beeing auto-sorted

System information

OS: Win10
TypeScript Hero version: 2.1.1
VSCode version: 1.19.3

Feature Option to ignore files from beeing auto-sorted
When organizeOnSave is enabled, all files are always auto-sorted. There are files which are structured in a specific way - often with alot of comments and those should not be sorted.
Public example and possibly even a good value for a default is the "polyfill.ts" which is generated by angular-cli
Reason
In order to apply changes to the polyfill.ts without changing it's whole strucutre, organizeOnSave needs to be disabled in settings, changes need to be applied and organizeOnSave needs to be re-enabled again.

Yep.. just encountered this myself.. actually a good idea :-)


colored(x & y, c) gives wrong answer when c has transparency and x and y overlap

I'd love to be able to say that Picture is semantically equivalent to Point -> Color.  Alas, it's not so.  For instance:

blank and colored(anything, RGBA(1, 1, 1, 0)) are identical in colors at each location; but colored(blank, red) is different from colored(colored(anything, RGBA(1, 1, 1, 0)), red).  This could be fixed with a rule that says that coloring a shape completely transparent causes it to forget its shape.
If a and b overlap, then colored(a & b, translucent(blue)) makes the region of overlap visible, even if it wasn't visible in a & b.  The right fix here is probably to declare that colored performs a sort of union of its first parameter using constructive area geometry (see #28), so that the overlap doesn't become visible.
Non-thick outline shapes like circle, rectangle, and polygon have weird behavior where their outlines stay 1 pixel wide regardless of scaling.  It's possible this could be rationalized as being just an artifact of rasterizing a perfectly thin line?  But it's mighty convenient.

The last point might stay the way it is... but I want to at least make an effort to get as close as possible to saying that Picture is just an abstract version of Point -> Color.

See #649 for another issue.

Everything here is basically okay except for the colored overlaps with transparency.  This should be implemented by detecting this case, and drawing to an off-screen buffer, then copying over with transparency.

Actually, I'll put this back and mark it closed, and file a new issue for the specific remaining part.

Closing in favor of specific issues for the remaining parts.


Read from Storage in file source

Description
Closes https://github.com/quickwit-oss/quickwit/issues/3868
How was this PR tested?
Running full test suite with https://github.com/quickwit-oss/quickwit/actions/workflows/coverage.yml

I read the comment for the resolve_streamable method but don't understand it. Why can't the Storage trait have a get_stream method directly?

I read the comment for the resolve_streamable method but don't understand it.

Noted, I'll rephrase it if we move forward in this direction

Why can't the Storage trait have a get_stream method directly?

That's one of the questions (I actually made a typo in my previous comment, sorry!).
Pros: The idea behind composing traits instead of having one big Storage trait that does everything is to avoid leaving methods unimplemented. I believe the Storage trait should already be split into a ReadableStorage and a WriteableStorage, thus avoiding unimplemented methods in BundledStorage and StorageWIthCache. I didn't want to add yet another method that doesn't make sense in all cases. You will usually want to avoid get_stream when the actual data is already backed by a byte array (like the cached storage) as it implies an extra unnecessary copy (I know that's what the RamStorage does, but that's mostly for tests). It's implementation might also be a bit tricky on the BundledStorage, which is a shame because it will actually never be used 😅 .
Cons: the machinery of the supertrait is bit obscure (especially the upcasting but also some generics introduced by it), and most Storage implementations are streamable anyway.

We can add a get_stream method implementation that has a default impl that calls get_all and avoid any unimplemented!().

Ok, thanks for your insight! I'll go with a get_stream method directly on the Storage abstraction then.

This is taking shape. Before moving this PR out of draft, I have a few questions:

Cache implementation: I added a naive implementation that uses get_slice and wraps it into a cursor. This implementation is actually never used. Should we rather leave it un-implemented and let it to the person who will first use it to come up with the implementation they want? (if we leave this dummy implementation, I'll obviously add a unit test for it)
Retry on Azure: the Azure SDK opens a fully lazy stream, so nothing happens until the stream is first polled. This means that we cannot use the usual mechanism here. One workaround to enable the retry mechanism would be to peak into the stream and wrap that into a retry. Do you think it is worth it?
Buffered reader: The S3 SDK documentation seems to suggest that the AsyncRead should be wrapped into a BufReader. The existing file source implementation was also performing this wrapping around the tokio::fs::File. Currently, it is still the file source that performs the wrapping, but my feeling is that it should be the Storage implementation that takes care of this when it is relevant. Any opinion on this?
Debouncer: I'm not sure I fully understand the role of the ins an outs of the debouncer. I added a dummy implementation of get_slice_stream that bypasses it. Does that seem sound?

Started the full test suite: https://github.com/quickwit-oss/quickwit/actions/runs/6341303249

Cache implementation: I added a naive implementation that uses get_slice and wraps it into a cursor. This implementation is actually never used. Should we rather leave it un-implemented and let it to the person who will first use it to come up with the implementation they want? (if we leave this dummy implementation, I'll obviously add a unit test for it)
Yes unimplemented!() is ok here.
 This means that we cannot use the usual mechanism here. One workaround to enable the retry mechanism would be to peak into the stream and wrap that into a retry. Do you think it is worth it?

This means that we cannot use the usual mechanism here.
I'm not entirely sure what is not working in this case. If you want to make sure we poll the stream within the body of the get_stream method,  a simple workaround could be to wrap the async reader in a tokio's async BufReader. It has a fill_buf method. Make sure you comment why you do that for future generations though.

Buffered reader: The S3 SDK documentation seems to suggest that the AsyncRead should be wrapped into a BufReader. The existing file source implementation was also performing this wrapping around the tokio::fs::File. Currently, it is still the file source that performs the wrapping, but my feeling is that it should be the Storage implementation that takes care of this
when it is relevant. Any opinion on this?
Which documentation?
I wonder if this is relevant here. Under the hood the s3 client wraps a stream of large Bytes of object, which size are independent from the way we use the AsyncRead. Does it prevent polling of the next block or something?
Debouncer: I'm not sure I fully understand the role of the ins an outs of the debouncer. I added a dummy implementation of get_slice_stream that bypasses it. Does that seem sound?
Yes that's ok. The debouncer detects that several queries currently in flight are actually fetching the same piece of data, and makes sure we only emit one GET request.

Cache implementation
ok, switching to unimplemented
Buffered reader

Which documentation?

Very sorry for this, I had the link ready but forgot to paste it in:

https://docs.rs/aws-sdk-s3/latest/aws_sdk_s3/primitives/struct.ByteStream.html#method.into_async_read

But now that I think about it, it's probably just for the convenience of having .lines() which comes from [AsyncBufReadExt].(https://docs.rs/tokio/latest/tokio/io/trait.AsyncBufReadExt.html).
I took a deeper look at the code, and the BufReader is actually required in the FileSource for the same reason as in the docs mentioned above: to go through the file line by line (here). So my proposed approach for now is to leave things as they are, i.e return the finer grained AsyncRead from the Storage (exactly as it is returned by the SDKs/tokio::fs::File) and wrap it with BufReader in the file source, if not for performance reasons at least to get the utility of the line by line iterator.
Retry on Azure

If you want to make sure we poll the stream within the body of the get_stream method, a simple workaround could be to wrap the async reader in a tokio's async BufReader. It has a fill_buf method

I feel it would be relevant to ensure the stream is polled at least once on the body, kind of as an equivalent to "opening the file". This should rarely be useful as connectivity checks seem to be usually performed beforehand. To be consitstend with the approach I proposed above for handling BufReader, I'd rather not solve this with a BufReader here. If that's fine, I'll stick to my peek idea as it's pretty simple an zero cost.
Debouncer
:+1:

Codecov Report
Attention: 35 lines in your changes are missing coverage. Please review.

Comparison is base (213b3bf) 81.83% compared to head (a2bc35d) 81.83%.
Report is 21 commits behind head on main.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3869      +/-   ##
==========================================
- Coverage   81.83%   81.83%   -0.01%
==========================================
  Files         401      401
  Lines      100563   100736     +173
==========================================
+ Hits        82300    82433     +133
- Misses      18263    18303      +40

Files
Coverage Δ

quickwit/quickwit-config/src/source_config/mod.rs
96.86% <100.00%> (ø)

quickwit/quickwit-index-management/src/index.rs
81.51% <100.00%> (ø)

.../quickwit-indexing/src/actors/indexing_pipeline.rs
92.23% <100.00%> (+0.05%)
:arrow_up:

...t/quickwit-indexing/src/actors/indexing_service.rs
89.40% <100.00%> (+<0.01%)
:arrow_up:

...uickwit/quickwit-indexing/src/source/ingest/mod.rs
87.83% <100.00%> (+0.06%)
:arrow_up:

quickwit/quickwit-indexing/src/test_utils.rs
98.94% <100.00%> (ø)

quickwit/quickwit-storage/src/debouncer.rs
96.72% <100.00%> (+0.09%)
:arrow_up:

quickwit/quickwit-storage/src/lib.rs
100.00% <100.00%> (ø)

...torage/src/object_storage/s3_compatible_storage.rs
91.23% <100.00%> (+0.20%)
:arrow_up:

quickwit/quickwit-storage/src/ram_storage.rs
92.66% <100.00%> (+0.41%)
:arrow_up:

... and 10 more

... and 14 files with indirect coverage changes

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


Integrate Inventory2 Data with Forseti Storage

This PR follows-up on PR #731:

Inventory2 data will be saved to Forseti DB
Importer will pull Inventory2 data from Forseti DB to build the models
models data will be saved to Explain DB.

I am still getting up to speed on sqlalchemy sessions and how to best manage them.  So, I'm all open to any suggestions for the work in this PR.

@felixbb @jiyunyao : I have only tested this functionally by crawling, importing, and creating the models.  Is there anything else I should test?

This is now superceded by Forseti 2.0 work.

This is now superceded by Forseti 2.0 work.


ChatAnyscale not working because of OpenAI API Key

System Info
Langchain 0.0.329
Python 3.9
Windows 10
Who can help?
No response
Information

[ ] The official example notebooks/scripts
[X] My own modified scripts

Related Components

[X] LLMs/Chat Models
[ ] Embedding Models
[ ] Prompts / Prompt Templates / Prompt Selectors
[ ] Output Parsers
[ ] Document Loaders
[ ] Vector Stores / Retrievers
[ ] Memory
[ ] Agents / Agent Executors
[ ] Tools / Toolkits
[ ] Chains
[ ] Callbacks/Tracing
[ ] Async

Reproduction

import os
from langchain.chat_models import ChatAnyscale

os.environ['OPENAI_API_KEY'] = "mykey"
os.environ['ANYSCALE_API_KEY'] = "mykey"

ChatAnyscale()

     95
     96     def __init__(self, **kwargs: Any) -> None:
---> 97         super().__init__(**kwargs)
     98         self._lc_kwargs = kwargs
     99

/usr/local/lib/python3.10/dist-packages/pydantic/main.cpython-310-x86_64-linux-gnu.so in pydantic.main.BaseModel.__init__()

ValidationError: 1 validation error for ChatAnyscale
openai_api_key
  str type expected (type=type_error.str)

Expected behavior
It shouldn't return an error because my Keys are both correct. For example, ChatOpenAI works fine.

I had the same issue and resolved it by downgrading to v0.0.327
@aidoskanapyanov Can you please recheck your last PR?

Hi @nndnha! Unfortunately, I'm unable to reproduce this issue on both 0.0.329 and 0.0.330. It seems to send api request as expected. Do you get the same behavior?

@aidoskanapyanov You need to test with a real API key to bypass your 401 error first because the issue occurred after this API request succeeded.
Here on my machine:
v0.0.327 worked!

0.0.330 error!

And my pydantic version is 1.10.13

Thanks @nndnha ! I managed to reproduce it. The issue seems to originate from ChatOpenAI, it expects openai_api_key to be a string, while we're passing down a SecretStr. openai_api_key should probably be a Union[str, SecretStr]. I guess the masking of the api key in chat models of openai hasn't been added yet.

I see errors with 0.0.333
I am looking for a fix
os.environ["ANYSCALE_API_KEY"] = "my_api_ke"
--> 150     values["openai_api_key"].get_secret_value(),
    151     values["openai_api_base"],
    152 )
    154 if model_name not in available_models:
    155     raise ValueError(
    156         f"Model name {model_name} not found in available models: "
    157         f"{available_models}.",
    158     )

AttributeError: 'str' object has no attribute 'get_secret_value'

I create a #13237  to fix the bug with call get_secret_value on a str value (values["openai_api_key"])
and added OpenAI v1 support


Autogenerated sidebar items: allow more control on output

🚀 Feature
Several things:

Add exclude option in category metadata to filter out docs;
Add additionalItems option to include more items in autogenerated categories, including link, ref, etc.;
Exclude entire subdirectories when declaring autogenerated sidebar items.

Have you read the Contributing Guidelines on issues?
Yes
Has this been requested on Canny?
No, but there are inline comments asking if they should be allowed, and the answer is yes: I've been asked about this feature.
Motivation
Sometimes we want a fully autogenerated sidebar, but occasionally want to add a few external links in categories. Sometimes we have a legacy directory structure and we only want to generate the sidebar from part of that directory.
API Design
In _category_.json, add the following options:
type CategoryMetadatasFile = {
  label?: string;
  position?: number;
  collapsed?: boolean;
  collapsible?: boolean;
  className?: string;
+ additionalItems?: WithPosition<SidebarItem>[];
+ exclude?: {
+   paths: string[];
+   docIDs?: string[];
+ };
};

paths accepts folder paths (I don't know if file paths would work well; from my experience with the autogenerator code, seems it's not easy since the doc metadata only includes sourceDir?), while docIDs accepts... doc IDs. It's assumed that the members in these two arrays are otherwise included in the category; if they are never included (non-existent IDs/paths not in the autogen dir...), maybe throw an error, or maybe do nothing.
additionalItems accepts doc, ref, link, and even category, but not autogenerated (at least I think it doesn't make much sense, and opens up holes to infinite recursion). Because doc items already come with their own sidebarPosition, they will be sorted well with the rest of the items. However, all items can have an additional sidebarPosition attribute (hence WithPosition<SidebarItem>) to override this behavior.
The autogenerated sidebar item will also accept the exclude and additionalItems properties, because the metadata file in the autogen dir root is not read.

Have you tried building it?
No

Would you design this API the same if autogen sidebars were not implemented?

Hard to say now I do know what's going on behind the scenes:P But even before I went down that rabbit hole, I was hoping for an include and exclude glob pattern; and in order for that to be extensible to links, I changed include to additionalItems. Hence this proposal.

it would allow to completely override the autogen for this specific dir for which you would need to be exhaustive

What if I want some additional links but keep the rest of the 10 categories + 50 doc links auto generated?

My mind always explodes when I work on recursion in our sidebar structure :P E.g. do we process the category's children prior to processing itself?
I'll revisit this proposal later since we recently have/will have quite a few changes with the sidebar architecture. Maybe category metadata would be read ahead of time. After a few weeks we may be in a better position to think about the API

Keeping an eye on this one. Just to help with my understanding:

I have an autogenerated sidebar slice
Inside the directory being pointed to I have an index.md file
Right now that index file is generated in the sidebar (and no way to remove this via the autogenerated sidebar type)
With this feature, I'd be able to add an exclude option (or something similar) to the autogenerated sidebar object to exclude that index.md from being rendered as a child link.

Referencing https://github.com/tauri-apps/tauri-docs/issues/347

@lorenzolewis that looks like a similar case to https://github.com/facebook/docusaurus/pull/5830#issuecomment-1017146250 (except your doc is named index)
You should be able to do something like:
[
  {
    type: "category",
    label: "JS",
    link: {
      type: "doc",
      id: "index"
    },
    items: [
      {
        type: "autogenerated",
        dirName: "js",
        exclude: ["index"]
      }
    ]
  }
];

Eventually, we could figure a way to exclude it automatically, as it looks like a convenient default
We could also allow an include option so that you can generate the sidebar slice one level upper:
[
  {
    type: "autogenerated",
    dirName: ".",
    include: ["js"]
  }
];

Does it make sense?

@slorber makes perfect sense, thanks!

@slorber  I like the idea of being able to add docs too.
I have just had a read through the whole issue. Will there be any way to sort the sidebar items other than using position in the _category_.json? Ideally sidebar_label alpha would be perfect by default!
I have a workflow where kb articles will be scraped into my repo from up to 20 'source' repos and deposited into the kb folder.  It is impossible to get the sidebar_position right and the current default sort is filename alpha which creates 'interesting results' as we have no control over how the teams name their files.

@slorber I like the idea of being able to add docs too.

Add docs where?

I have just had a read through the whole issue. Will there be any way to sort the sidebar items other than using position in the category.json? Ideally sidebar_label alpha would be perfect by default!

I have a workflow where kb articles will be scraped into my repo from up to 20 'source' repos and deposited into the kb folder. It is impossible to get the sidebar_position right and the current default sort is filename alpha which creates 'interesting results' as we have no control over how the teams name their files.

I don't understand what kb is and what you mean exactly here
Please give a very concrete example by providing a file-system tree with files/folders, the config you want to provide, and what the sidebar should look like.
Note that in any case, you can control the sidebar generation logic, including the order, by providing your own generator, or "enhancing" the existing one.
The doc provides an example where the order of the sidebar items is reversed:
https://docusaurus.io/docs/sidebar#customize-the-sidebar-items-generator
// Reverse the sidebar items ordering (including nested category items)
function reverseSidebarItems(items) {
  // Reverse items in categories
  const result = items.map((item) => {
    if (item.type === 'category') {
      return {...item, items: reverseSidebarItems(item.items)};
    }
    return item;
  });
  // Reverse items at current level
  result.reverse();
  return result;
}

module.exports = {
  plugins: [
    [
      '@docusaurus/plugin-content-docs',
      {
        async sidebarItemsGenerator({defaultSidebarItemsGenerator, ...args}) {
          const sidebarItems = await defaultSidebarItemsGenerator(args);

	      // Here, it's up to you to do whatever you want to re-order the sidebar items
          return reverseSidebarItems(sidebarItems);
        },
      },
    ],
  ],
};

Now it's up to you to provide your own ordering logic:

you can create exceptions and decide to reverse only a category that has a specific label
you can invent your own frontmatter and use args.docs + sidebarItems to compute the new order based on your custom frontmatter

Can I suggest we also look at this comment from @slorber:
https://github.com/facebook/docusaurus/issues/3464#issuecomment-820336747
tl;dr
module.exports = {
  mySidebar: [
    {
      type: "autogenerated",
      dirName: "tutorials"
      include: "**/easy-*.md"
    },
    {
      type: "autogenerated",
      dirName: "tutorials"
      include: "**/easy-*.md"
    }
  ]
};

This would be amazing for me - my book Effective Shell uses a folder per article:

Unless I have missed something, this nesting structure means my sidebars have to look like this:
anotherSidebar: [
    'index',
    {
      type: 'category',
      label: 'Transitioning to the Shell',
      link: { type: 'doc', id: 'transitioning-to-the-shell/index'},
      items: [
        'transitioning-to-the-shell/getting-started/index',
        'transitioning-to-the-shell/navigating-your-system/index',
        'transitioning-to-the-shell/managing-your-files/index',
        'transitioning-to-the-shell/clipboard-gymnastics/index',
        'transitioning-to-the-shell/getting-help/index',
        'transitioning-to-the-shell/the-renaissance-of-the-shell/index',
      ],
    },

If instead I could do this:
anotherSidebar: [
    'index',
    {
      type: 'category',
      label: 'Transitioning to the Shell',
      link: { type: 'doc', id: 'transitioning-to-the-shell/index'},
      items: [
        'transitioning-to-the-shell/getting-started/index',
        'transitioning-to-the-shell/navigating-your-system/index',
        'transitioning-to-the-shell/managing-your-files/index',
        'transitioning-to-the-shell/clipboard-gymnastics/index',
        'transitioning-to-the-shell/getting-help/index',
        'transitioning-to-the-shell/the-renaissance-of-the-shell/index',
      ],
    },

If instead I could do this:
      type: 'category',
      label: 'Transitioning to the Shell',
      link: { type: 'doc', id: 'transitioning-to-the-shell/index'},
      include: "**/index.md"

That would be amazing

@dwmkerr I'm not sure to understand: what's the result you currently have, and what's the result you want?
It looks like you display twice the same sidebar in your comment, maybe a typo?

Sorry there was mistake - copy/paste error. I've fixed it now. Because each page is in a subfolder, I cannot autogenerate the pages without each one sitting in it's own category. What I'd like to be able to do is have a single category, such as "Transitioning to the Shell" and have a flat set of pages in this category which are populated using a globbing pattern that finds all of the pages in the child folders

@dwmkerr Have you tried beta.16? In the latest version, a folder containing only an index.md should already generate a single doc link instead of a category.

I would like to see exclude added to either _category_.json or sidebar configs. I have directories in /docs that I want to be excluded from the main sidebar. I link to them in the header and they use their own sidebar once loaded.

@Josh-Cena yes I'm actually on beta 20, but still have the issues of the 'index' file being included when we auto-generate items and then also the subfolder issues, so the wildcard option plus the 'exclude' options could still be a massive improvement for me!

@dwmkerr Are you running into this bug? https://github.com/facebook/docusaurus/issues/7348 Try with canary?

No I'm afraid not - I have a category but it there are also items

Ah, so it's the problem we are talking above. No problem—it will be the top use-case for this feature.

Still actual!

Is the exclude from autogenerated sidebar option already implemented? I tried it, but it doesn't work in the 2.1 version.
I have only a docs-based site, where one of the docs pages is the initial page, which works great.
I only cannot find a way to hide it from the autogenerated sidebar.

If this issue is not closed, this means it's not implemented not released

I have only a docs-based site, where one of the docs pages is the initial page, which works great.
I only cannot find a way to hide it from the autogenerated sidebar.

Interesting use-case to consider, thanks for reporting

We have docs in multiple repos. So we use git submodules
Maybe I'm doing things wrong
This is our folder structure
docs/
├─ guides/
│  ├─ getting-started.md
│  ├─ contributing.md
├─ submodules/
│  ├─ request/
│  │  ├─ README.md
│  ├─ product-analytics/
│  │  ├─ README.md

I am trying to generate a sidebar structure of
Guides
├─ Getting Started
├─ Contributing
Request
Product Analytics

I am just trying to remove the submodules folder from showing up.
My sidebar config looks like this
{ type: 'autogenerated', dirName: '.' },
{
   type: 'doc',
   id: 'submodules/request/README',
   label: 'request,
}

I was hoping for something like
{ type: 'autogenerated', dirName: '.' , exclude: ['./submodules/**/*.md']}

In one of the projects I have a page that should not be visible in a sidebar, but the page still should be associated with it. Allowing a sidebar label to be an empty string in frontmatter of the page perfectly communicates the intent:
sidebar_label: ""

This is not strictly an exclusion, it just makes the corresponding sidebar item invisible while keeping the page <-> sidebar association active.
A use case: some pages should not be indexable or observable in navigation because they are shared by direct links only. At the same time, those "secret" pages belong to a larger resource such as Knowledge Base, meaning that the corresponding sidebar should remain visible for such pages to allow further navigation.

You can implement something like this using a custom sidebar items generator:
async function postProcess({ item, ...args }) {
  if (item.type === 'category') {
    // Recurse through children
    for (const childItem of item.items) {
      await postProcess({ item: childItem, ...args });
    }
    // Add additional items
    if (item.customProps?.additionalItems) {
      for (const { position, ...additionalItem } of item.customProps.additionalItems) {
        if (position !== undefined) {
          item.items.splice(position - 1, 0, additionalItem);
        } else {
          item.items.push(additionalItem);
        }
      }
    }
  }
}

export default async function sidebarItemsGenerator({ defaultSidebarItemsGenerator, item, ...args }) {
  const sidebarItems = await defaultSidebarItemsGenerator({ item, ...args });
  for (const item of sidebarItems) {
    await postProcess({ item, defaultSidebarItemsGenerator, ...args });
  }
  return sidebarItems;
}

See sidebarItemsGenerator.ts for the full code, and this _category_.json file for an example usage. It's not perfect (the position handling is very hacky), but it does the job. 😁


rack-test 0.7.0 breaks Ruby 1.8.7 compatibility

rack-test-0.7.0/lib/rack/test/cookie_jar.rb:99: syntax error, unexpected ')' (SyntaxError)
Would you accept either a PR to restore 1.8.7 compatibility or to update the gemspec with a required_ruby_version?

@segiddins
Thank you for contacting.
We dropped Ruby 1.8.7 from rack-test 0.7.0 intentionally.
Ruby 1.8 has not supported officially.
Rack 2.0 does not support Ruby 1.8 anymore.
https://github.com/rack/rack/blob/2.0.0/.travis.yml
So, I am sorry we do not support Ruby 1.8 right now.
If you are not using Bundler, I recommend you to use it.
You can control use rack-test < 0.7.0 with Gemfile.

What versions of Ruby does 0.7.0 support? I'll send a PR to update the gemspec so others get a clearer error message than a syntax error

We support >= 2.2.2.
https://github.com/rack-test/rack-test/blob/master/.travis.yml
It is same with rack 2.
https://rubygems.org/gems/rack/versions/2.0.1
https://github.com/rack/rack/blob/master/rack.gemspec#L29
Updating the gemspec file is better than current situation.
I would accept the PR.
Thanks.

@junaruga - we should probably also add a note in the README.md saying that people who are stuck on ruby 1.9 or 1.8 (like older versions of JRuby) should stay on 0.6.3. @segiddins - please include that in the PR if possible.
(We also intend to release a version 1.0.0 shortly, but we wanted to push out the 0.7.0 first to kick the wheels a bit, before marking it as 1.0.0 where the API is effectively frozen (well, until 2.x that is.))

@junaruga We should make a 0.7.1 or 0.8.0 release by now. Would you have time to do it?

@perlun Yes, I have a time for that. Let me check the latest update at first. Also I agree with your above comment.

@perlun @scepticulous
I prefer bumping version 0.7.1 from 0.7.0.
Because when I checked new updates, all the issue is minor enhancement or bug fix.

Remove new line from basic auth #185
=> Bug fix
[Gemspec] Add a required_ruby_version of >= 2.2.2 #194
=> s.required_ruby_version = ">= 2.2.2"
=> Bug fix

v0.7.0 already does not support < 2.2.2.

Rubocop fixes #196
=> Minor enhancement (develop)
Add how to install rack-test from github to README. #189
=> Minor enhancement (develop)
Update CodeClimate badges #195
=> Minor enhancement (develop)
Add the ability to create Test::UploadedFile instances without the file system #149
=> Minor enhancement
Add custom_request, remove duplication #184
=> Minor enhancement
README.md: Added note about how to post JSON #198
=> Minor enhancement
Bugfix for Cookies with multiple paths #197
=> Bug fix
README.md: Added version badge #199
=> Bug fix
.travis.yml update versions.
=> Minor enhancement (develop)

Sorry I changed my opinion.
And we added s.required_ruby_version = ">= 2.2.2" because rack-2.0.1, first version of rack-2.x supports it.
In my opinion, we should bump version 0.8.0.

Hey guys,
Just having a slight issue here with this versioning decision, wanted to share some feedback. rack-test is a dependency of something else in one part of our company's sprawling chef setup, running on a chef installed version of ruby, which is 2.1 - so had been working up to 0.6.3 but is now broken because there wasn't a major bump at 0.7.0. I understand the logic behind 0.8.0 being a minor bump because on its own terms it is, but for me 0.7.0 should have been 1.0.0, and because it wasn't 0.8.0 should have been 1.0.0 to fix this error.
Otherwise thanks for your work!


feat: AU-758 Summation component

AU-758

Fix the non-functioning old module. Now summation field can be added to the form.
What was done

Made a new version of the Summation Field module that was a dud before

How to install

Make sure your instance is up and running on correct branch.

git checkout feature/AU-325-table-component
make fresh

Run make drush-cr

How to test

[ ] Log in as admin.
[ ] Go edit KASKO yleisavustushakemus
[ ] Add a new element to the Avustuslaji section of the type Grants Webform Summation Field.
[ ] Select the Avustukset: amount field as the one getting collected
[ ] Select Euro as the type
[ ] Set the title display as invisible.
[ ] Save the element.
[ ] In a different browser, clear browser cache
[ ] go to https://hel-fi-drupal-grant-applications.docker.so/fi/uusi-hakemus/kasvatus_ja_koulutus_yleisavustu and navigate to the second page. Add numbers to the avustuslaji. See that the summation field increases as needed.
[ ] Go back to your admin browser
[ ] Add two new text fields to the first page.
[ ] Add a Grants Webform Summation Field to the first page.
[ ] Select the two new text fields as the ones getting collected
[ ] Select integer as the type
[ ] Save the element
[ ] In your other broswer, reload your page that is on the form page.
[ ] Add numbers to your new fields
[ ] See that the summation field increases in value.
[ ] Check that code follows our standards

Designers review

[ ] This PR needs to be visually reviewed by a designer (Heikki)

New text fields are not available on the summation component?
Adding existing fields works as expected.

Yeah, new fields are not showing up, otherwise ok.

This is interesting, because for me, they are showing up as expected. Sounds like some strange cache issue.


DBZ-4720 Validate Debezium Server configuration properties

Valication connector before attempting to initialize

@ggaborg, please review this PR (this issue was opened by me at the time).

Also, this change only touches the validation for the connector properties, not other configuration dependent components like offset storages, schema history, etc.

For SchemaHistory, each implementation is already validating itself in the configuration method.
For the OffsetBackingStore, perhaps as part of DBZ-1971, validation support could be added.
In terms of tests for each connector, are you thinking that MySqlConnectorConfig as an example needs to be unit tested?

@jeremy-l-ford, hi

"For SchemaHistory, each implementation is already validating itself in the configuration method." - this only validates required properties and is not similar with the connector validation.
"For the OffsetBackingStore, perhaps as part of DBZ-1971, validation support could be added." - I was thinking about a unified mechanism to validate configuration, see 1.
"In terms of tests for each connector, are you thinking that MySqlConnectorConfig as an example needs to be unit tested?" yes


[language][prover] Fixed bugs in Prelude

Fixed the bugs in the constants MAX_U64 and MAX_U128 in Prelude
Removed the (seemingly) deprecated functions: max_u64, and isValidInteger in Prelude
Ported and added the test cases for arithmetic operations
Marked two TODO test cases where Prover seems to give false counterexamples.

Motivation
To fix some bugs in some constants in Prelude
To add tests cases for arithmetic operations
Have you read the Contributing Guidelines on pull requests?
Yes
Test Plan
cargo test
Related PRs

[move-prover] Move Prover test (language/move-prover/cargo test) on commit 9dc3220 did fail. See details.

Test passed after rebasing.

@bors-libra r=wrwg

:pushpin: Commit a60b640 has been approved by wrwg

:hourglass: Testing commit a60b6404fe50e8c16048b8b545ba1df54e5f48cd with merge 4c1e580c1f08d0ed28dc741c3fb2c25888c474cf...

:sunny: Test successful - checks-actions_land_blocking_test, checks-circle_commit_workflow
Approved by: wrwg
Pushing 4c1e580c1f08d0ed28dc741c3fb2c25888c474cf to master...


Enhance the FAQ Section

We can enhance the FAQ section with some smooth animations and icons.
Example 👇
https://user-images.githubusercontent.com/91705825/191686332-777283cc-2299-46f7-abb4-357ac17c4bd5.mp4

It's a good idea.


Page not found error

Besides the homepage, every other page shows the same issue after a refresh. I get a "Page Not Found" error.
At first, I thought it might be caused by Vercel, so I switched to Netlify, but the issue persists.

see the errors in console and also provide some more screenshots of what page are you trying to access. Because it's handled in my code so it should not show the default 404 page of netlify. If you did something wrong while configuring then also it will show the customised /404-not-found-page in the website

https://pnime.vercel.app/
You can visit this website all things works perfectly fine  like streaming, anime search+ details page but if you refresh for onece it will show this error and you have to re-visit the homepage
it's maybe because of caches error or I haven't setup the env properly I am not sure 🙃
To see the error :- just visit the website click on any anime after it loads the player page or details page hit refresh

https://pnime.vercel.app/
You can visit this website all things works perfectly fine like streaming, anime search+ details page but if you refresh for onece it will show this error and you have to re-visit the homepage
it's maybe because of caches error or I haven't setup the env properly I am not sure 🙃
To see the error :- just visit the website click on any anime after it loads the player page or details page hit refresh

check your vercel logs. Usually this type of error should not occur even though you didn't setup env or cache. You don't have to mandatorily setup cache you will get no error for that. But I will suggest to check your vercel logs

.

but in my localost its working just fine with no errors

Then I don't think there is anything wrong in the code maybe try deploying the website with different account in vercel

Ok


Cleanup LICENSE

Summary of the Pull Request
Cleanup LICENSE text
References
N/A
PR Checklist

[ ] Closes #xxx
[X] CLA signed. If not, go over here and sign the CLA
[ ] Tests added/passed
[ ] Requires documentation to be updated
[ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx

Detailed Description of the Pull Request / Additional comments
Github currently does not recognize the license.  It says "View License" in the right side of the top bar.  In MIT-licensed projects that Github does recognize, it will say "MIT".
The tool GH uses seems very sensitive to the formatting of the license text (whitespace, newlines etc).  This PR removes some whitespace and adjusts the wrapping so that the formatting matches the LICENSE file for Vue.js
Validation Steps Performed
N/A

Hi @reviewher
thank you for the contribution!


Documentation for Webpack is outdated or incomplete

Description
This project looks great and I'd like to work with it. I've run into issues integrating it though. While I've been able to work through some of them I'm opening this issue to highlight that the documentation for integrating monaco-kusto using webpack seems to be outdated or incomplete.
Here is an example repository that I've set up according to the docs as best as possible: https://github.com/kevinehosford/monaco-kusto-test. Ideally, I'd like to get this example running to see monaco-kusto bundled using webpack, as well as, determine what parts of the documentation need to be updated.
Thanks

You'll need to merge the runtime chunk of this entry point with this entry point output chunk to one chunk, and have this one call in getWorkerUrl in step 5.

Please adjust this sentence in the process - really confusing way of stating the end-goal.

I'm closing this issue as stale. Please comment if you'd like to see this re-opened.


KV Cache INT8 and INT4 quantization precision reduction

Checklist

[X] 1. I have searched related issues but cannot get the expected help.
[X] 2. The bug has not been fixed in the latest version.

Describe the bug
KV Cache INT8 and INT4 quantization both have noticeable precision decline on vicuna-13b-v1.5 for lmdeploy 0.0.11
It should be noted that quantization for KV Cache INT8 and whole model INT4 is performed separately.

 This means enabling kv_cache int8

Start Service
ervice_name=<IP_ADDRESS>
service_port=8000

python3 -m lmdeploy.serve.openai.api_server \
  ./workspace \
  ${service_name} \
  ${service_port} \
  --instance_num 32 \
  --tp 1

Evaluation
Using Holistic Evaluation of Language Models (helm) to evaluate the model's precision.
The test dataset is as follows:
https://huggingface.co/datasets/cais/mmlu
https://huggingface.co/datasets/andyw0lf/mmlu-id
https://huggingface.co/datasets/Rowan/hellaswag
https://huggingface.co/datasets/piqa
https://huggingface.co/datasets/lighteval/siqa
https://huggingface.co/datasets/gsm8k
https://huggingface.co/datasets/boolq
https://huggingface.co/datasets/narrativeqa
https://huggingface.co/datasets/openbookqa
https://huggingface.co/datasets/commonsense_qa
Environment
- lmdeploy [0.0.11](https://github.com/InternLM/lmdeploy/tree/v0.0.11)
- 2*A30
- 1*V100

Error traceback
No response

受限于资源，我这边测试 vicuna 的量化精度需要的时间会比较久
注意到你使用的是 lmdeploy v0.0.11，我在 v0.0.14 #605 里修复了千问量化精度掉点的问题（权重的异常值太多+pytorch 四舍五入的行为和硬件不一致），可能可以解决 vicuna 量化的问题

Limited by resources, it will take me a long time to test the quantization accuracy of vicuna.
I noticed that you are using lmdeploy v0.0.11. I fixed the problem of Qwen quantization accuracy drop in v0.0.14 #605 (weights contain too many outliers + pytorch’s rounding behavior is inconsistent with the hardware), which may solve the problem of vicuna quantization

Thanks for your response. I will try the 0.0.14 version and give the feedback.

Does the current kv8 kernel support v100 ? @lvhan028 @lzhangzz

From the code block in BaseAttentionLayer, it seems that

if the sm >=75, the AttentionType is FUSED_MHA or FUSED_PADDED_MHA
if the sm < 75, the AttentionType is UNFUSED_MHA or UNFUSED_PADDED_MHA

So the FUSED_MHA or UNFUSED_MHA operator in KV INT8 cased the precision difference on A100 between A30？
@lvhan028 @lzhangzz

BaseAttentionLayer is not used by lmdeploy.
In v0.0.14, there is no saturation op when quantizing the key/value for sm70, this should be the cause of performance degeneration.
https://github.com/InternLM/lmdeploy/blob/7b20cfdf0ac3819dcf6978dc8ddb49b5d2cda5a9/src/turbomind/models/llama/llama_kernels.cu#L315-L339
INT8 quantization/dequantization is re-written in v0.1.x and does not have this problem.

BaseAttentionLayer is not used by lmdeploy.
In v0.0.14, there is no saturation op when quantizing the key/value for sm70, this should be the cause of performance degeneration.
https://github.com/InternLM/lmdeploy/blob/7b20cfdf0ac3819dcf6978dc8ddb49b5d2cda5a9/src/turbomind/models/llama/llama_kernels.cu#L315-L339
INT8 quantization/dequantization is re-written in v0.1.x and does not have this problem.

Thanks for your response. THe problem solved by upgrading the lmdpeloy from 0.0.14 to 0.1.0a2.


filter node for etp service

What this PR does / why we need it:
Which issue this PR fixes(if applicable):
For services with the externalTrafficPolicy type, a better implementation of pool members would be to include only those nodes that have service Pods, ensuring that service requests are properly routed even without configured health checks.
Special notes for reviewers:

Release note:

NONE

/ok-to-test

Thanks for the PR, I assume you want to exclude the nodes that doesn't have the service pod running on when ensure the LB with externalTrafficPolicy  = ServiceExternalTrafficPolicyTypeLocal ?
could you please help create an issue and provide detailed info so we can track why we need such change and use case etc? Thanks

Thanks for the PR, I assume you want to exclude the nodes that doesn't have the service pod running on when ensure the LB with externalTrafficPolicy = ServiceExternalTrafficPolicyTypeLocal ?
could you please help create an issue and provide detailed info so we can track why we need such change and use case etc? Thanks

Oh, I found a fatal bug in my PR:  the controller didn't handle  svc pod's update event。 I'll close this PR and fix it in my fork.
The initial intent of this PR was to:

Ensure that the system can still function as normally as possible without a configured health-monitor.
Mitigate the issue of traffic loss during rolling updates (due to the intervals in health checks).

However, my PR overlooked the logic for handling post-update pods, which requires adding a servicePodInformer and related processing logic in the ingress controller. I will close this PR and attempt to resolve this issue in my fork with additional testing.
Nevertheless, I've noticed that Kubernetes seems to be addressing this issue as well:
https://kubernetes.io/blog/2022/12/30/advancements-in-kubernetes-traffic-engineering
Therefore, I am now unsure whether this should be resolved within OCCM.

@smartwang: It won't be that simple. The Ingress controller is a separate entity that handles Ingress. You'd need to create a whole new controller that will run in the openstack-cloud-controller-manager and would watch for Pods. The code you're modifying is called from the cloud-provider and only gets informed about Service or Node changes.

@smartwang: It won't be that simple. The Ingress controller is a separate entity that handles Ingress. You'd need to create a whole new controller that will run in the openstack-cloud-controller-manager and would watch for Pods. The code you're modifying is called from the cloud-provider and only gets informed about Service or Node changes.

Indeed, "ingress controller" was a typographical error. What I meant to convey is the same as you, that it is somewhat troublesome. I can roughly understand why the health check implementation was continuously used before; it's sufficiently simple and can handle most scenarios. Striving for perfection comes at a cost; it's a matter of whether it's worth it or not.

@smartwang: It won't be that simple. The Ingress controller is a separate entity that handles Ingress. You'd need to create a whole new controller that will run in the openstack-cloud-controller-manager and would watch for Pods. The code you're modifying is called from the cloud-provider and only gets informed about Service or Node changes.

Regardless, thanks for your response and guidance.

@smartwang: It won't be that simple. The Ingress controller is a separate entity that handles Ingress. You'd need to create a whole new controller that will run in the openstack-cloud-controller-manager and would watch for Pods. The code you're modifying is called from the cloud-provider and only gets informed about Service or Node changes.

Indeed, "ingress controller" was a typographical error. What I meant to convey is the same as you, that it is somewhat troublesome. I can roughly understand why the health check implementation was continuously used before; it's sufficiently simple and can handle most scenarios. Striving for perfection comes at a cost; it's a matter of whether it's worth it or not.

The real reason we use healthchecks is pretty simple - other clouds do it the same way. It's far from ideal, but it's an easy way to do it regardless of the cloud K8s is running on. While I'm not opposed to try to hack our way out of this, I'd totally prefer discussing and finding a way to do it in a way that can be supported by other clouds in an unified way. This would probably involve a KEP and broader discussion with SIG Cloud Provider. I wouldn't be surprised if there were similar ideas proposed already.
All that being said, please also check if Gateway API doesn't actually solve what you're looking for.


Trying to use input device api

The Tizen API seems to be failing to load in our application.
I have the following import
import { tvinputdevice } from 'tizen-common-web';
but I am getting this error:
Cannot destructure property 'AlarmAbsolute' of 'window.tizen' as it is undefined
I know this is pretty light on details so let me know what other information you need and I will get it for you.

@lemmaa do you have any ideas on this?

@Peter-Barrett Sorry to late.
I'd like to check your package list. Can you share your package.json?

No problem, thanks for getting back to me.
The commonjs is not work on a Tizen Web App. You need to compile a commonjs to vanilla js.
Here is our sample app with commonjs style with a webpack. Please check a webpack.config.js.
https://github.com/Samsung/tizen-common-web/tree/master/samples/commonjs
If you are enable running a web inspector, can you test run followed code in the inspector?
/* Sets an alarm on January 1st 2014 08:00. */
var date = new Date(2014, 0, 1, 8, 0);
var alarm1 = new tizen.AlarmAbsolute(date);
tizen.alarm.add(alarm1);

In my test app, I got VM124:1 Uncaught WebAPIException {code: 18, name: 'SecurityError', message: 'Permission denied', stack: 'SecurityError: Permission denied\n    at NativeMana….add (<anonymous>:1:2718)\n    at <anonymous>:4:13'} error because of my test app doesn't have a privilege.
I'm not well known about a vue framework. But there is a @types/node package. I just wonder your package contain both server side and client side. And then, did your client launched on a device(emulator or real device)?

Hello @Peter-Barrett
Did you tested on Tizen tv device right?
I think, as your error message, your environment might looks like not be tizen tv device.
Cannot destructure property 'AlarmAbsolute' of 'window.tizen' as it is undefined

@SejoongDeJang thanks, I won't be able to test it today but I will try during the week and let you know what I find out.
@pwsses I'm using the simulator.


[v2] Usage with TypeScript

🐛 Bug Report
Regression of https://github.com/facebook/docusaurus/issues/2675
To Reproduce
npx @docusaurus/init@next init my-website classic

Follow steps https://v2.docusaurus.io/docs/typescript-support#setup.
Rename src/pages/index.js to src/pages/index.tsx.
VSCode displays the following errors:

Cannot find module '@docusaurus/Link' or its corresponding type declarations.
Cannot find module '@docusaurus/useDocusaurusContext' or its corresponding type declarations
Cannot find module '@docusaurus/useBaseUrl' or its corresponding type declarations.
Cannot find module './styles.module.css' or its corresponding type declarations.

Your Environment

Docusaurus version used: 2.0.0-alpha.63
Environment name and version (e.g. Chrome 78.0.3904.108, Node.js 10.17.0): Node v12.18.3
Operating system and version (desktop or mobile): OSX v10.15.6

Hey,
We are still figuring out how to provide the best TypeScript experience in Docusaurus, by trying to use it first on Docusaurus 2 site itself.
@SamChou19815 has done some initial work, and you could probably get started by using a src/types.d.ts file containing:
/// <reference types="@docusaurus/module-type-aliases" />
/// <reference types="@docusaurus/theme-classic" />

We don't have much TS code in our website yet, but hopefully we'll migrate over time and be able to recommend a good TS setup to our users.

I like how CRA works. Including a TypeScript template in the init would be awesome.

Adding the src/types.d.ts didn't work.
The @docusaurus/module-type-aliases is outdated on npm (2.0.0-alpha.51). It doesn't declare those modules.
https://github.com/facebook/docusaurus/blob/v2.0.0-alpha.51/packages/docusaurus-module-type-aliases/src/index.d.ts
It has since been updated but not published to npm. Can someone publish?
https://github.com/facebook/docusaurus/blob/33ecc4bb1750ab00841b0dfeaee525e9f9d89498/packages/docusaurus-module-type-aliases/src/index.d.ts

I see, if you install it at the correct version it works. yarn add -D<EMAIL_ADDRESS>

this problem still appears to exist. Probably because the classic template doesn't have a tsconfig or anything. However, the tutorial that tells you that you can just use a tsx file if you want -uses the classic template and makes no mention of tsconfig

This problem still exists for @site/ or .module.scss: If we use import starting with @site/ or ending with .module.scss in a .tsx file, VSCode will display errors like:

Cannot find module '@site/[some_file]' or its corresponding type declarations.
Cannot find module '[some_file].module.scss' or its corresponding type declarations.

These errors don't appear with .js files.
I looked through the file @docusaurus/module-type-aliases/src/index.d.ts and guess this problem could be solved by adding some declare module for these cases (I'm not sure what to write exactly 😅 so I write an issue here instead of creating a PR).

still actual!

Still having problems with this.

@raphzandrade Consider upgrading your @tsconfig/docusaurus version to 1.0.2, which should make @docusaurus/module-type-aliases and @docusaurus/theme-classic types available by default. (Weirdly, for me it seems it's not, but creating a types.d.ts file, adding the two <reference>, and then removing the file fixed the errors)
Also, I just recently added a classic-typescript template, which will be available in the next release

@Josh-Cena I am using the version you said and added the types.d.ts. Still not working properly. Will do more testing on my end. :(

"It doesn't work" is not very actionable for maintainers.
At least describe the problem and error messages you have.
Or mention it's the same problem as another detailed comment.
Make sure to be up-to-date and provide details of your env.
Ideally, provide a repo/git branch that we can inspect and try to fix.

@slorber Will try to mock up a env close to the one I am experiencing the problem. Since we are inside a monorepo solution, using nx, I am exhausting the possibility of being a problem on our side first.

I am having this issue as well, using @docusaurus/module-type-aliases": "^2.0.0-beta.6" version and tried adding type.d.ts as suggested above in the src folder and still have issue with eslint:

@tiffanynguyen0211 This is because ESLint doesn't understand module definitions. These aren't actual paths, but Webpack aliases which ESLint doesn't know about. We solve this ourselves by disabling it on certain circumstances:

    'import/no-unresolved': [
      ERROR,
      {ignore: ['^@theme', '^@docusaurus', '^@generated', 'unist', 'mdast']},
    ],

@Josh-Cena thank you

@tiffanynguyen0211 This is because ESLint doesn't understand module definitions. These aren't actual paths, but Webpack aliases which ESLint doesn't know about. We solve this ourselves by disabling it on certain circumstances:

This is not working for me:

Do you know what I'm missing?

@matthewmuscat looks like your eslint rule config is not applied (ie the ignore does not take effect). We can't tell why but we just see it's not applied. Maybe you have another rule or config that conflicts with this one?

@matthewmuscat import/no-unresolved is a RULE, so you put it under rules. I don't know where exactly you are putting that but looks suspiciously unlike rules.

For me work this:

src/types.d.ts

declare module '*.module.scss';
declare module '*.module.sass';

tsconfig.json

{
// ...
"include": ["src"]
}

For the module.scss files I “solved” it by adding a type definition like this:

I created a .d.ts file within my src folder. The location does not seem to matter tho’
definitions.d.ts:

declare module '*.module.scss';

I quit vscode fully (ctrl+q)
I re-open it

And Typescript does not complain anymore.
However, I would appreciate this to not complain out of the box with docusaurus+typescript+docusaurus-plugin-sass

Docusaurus does not use sass internally and is modular, and we probably don't want to have any ref to sass in core.
We do have this:
declare module '*.module.css' {
  const classes: {readonly [key: string]: string};
  export default classes;
}

declare module '*.css' {
  const src: string;
  export default src;
}

It is the responsibility of the sass plugin to provide the appropriate declarations and/or install instructions


Demo will not load in Internet Explorer

I was looking through the online sample at akveo.com/ng2-admin.  Today when I tried to show it to a co-worker, the demo would not load in IE 11 or IE 10.  Has something changed?

Closed, because this issue was already reported. This was a duplicate issue to #135


GDB-10752 Add password hash for the security provisioner

The password hash is introduced due to the dynamic nature of the bcrypt algorithm, which generates a new hash each time deployment is initiated.
This resolves potential issues with CI/CD tools that detect these changes and prevent false-positive drift events.
Issue: GDB-10752

This change should be in the 11.2 feature branch.


Update Filesystem exceptions

The exception hierarchy and error reporting could perhaps be re-worked a bit.
For PhysFS errors, the error could be captured inside an exception constructor, simplifying the calling code quite a bit. This may also ease transition from the now deprecated getLastError and help transition to getLastErrorCode and getErrorByCode.
Currently error messages are being dumped to cout. Better would be to report errors to cerr. Best would be to capture the message in the exception itself. If the exception message is logged in caller, it can log it to cerr, or whatever log file it produces.

I believe the exceptions should be more closely tied to the component they are associated with. Currently the filesystem related exceptions are in a generic Exception.h. I think it would be better to keep the filesystem specific exceptions as part of the Filesystem class, perhaps as contained classes.

I believe there should be a common filesystem related base class for all filesystem exceptions. Currently each one derives from runtime_error directly.
I'm uncertain if we need the granular detail of having separate exception classes for each of the possible filesystem errors. Currently we have:

filesystem_backend_init_failure
filesystem_not_initialized
filesystem_already_initialized
filesystem_file_handle_still_open

In particular, the PhysFS library already checks and reports many of these conditions. We could have just a generic exception which captures the PhysFS error and reports that.

I was taking a look at the exception code. It seems filesystem_not_initialized is used the most by far. This makes sense considering the C style Physfs interface, and how pretty much every filesystem method requires the initialization method to be called first.
I was thinking, this check would not be needed if we used a modern C++ style interface with checked exceptions. Within the constructor of Filesystem, we could call PHYSFS_init, throw if it fails, and then assume it has already been called for all member functions. This would require collapsing the two stage initialization (constructor + init) into a single stage initialization (constructor only).
Curiously, the two stage initialization pattern seems to derive from old C code, or early C++ code from before C++ had exceptions. Hard to remember C++ not having exceptions, but yes, there was a time, and things like MFC, and certain classes in the standard library had designs influenced by that.
The standard practice now, is to use single stage initialization, and to throw from the constructor if initialization fails. Throwing from the constructor prevents object creation. That way, you can't have a partially initialized object in some unusable zombie state. The object is either fully initialized and usable, or simply doesn't exist.

There are some challenges with the above suggestion. In particular, the Utility class creates objects on demand by calling the default constructor. This mechanism does not provide a way to specify constructor parameters.
Another challenge might be what happens if someone tries to construct two Filesystem objects, or manually calls PHYSFS_init or PHYSFS_deinit. The Physfs documentation does not address what happens if PHYSFS_init is called multiple times.
Currently the Filesystem object is designed to work as a singleton, and the Utility class ensures this, with cached lazy initialization. As such, we don't need to worry about multiple objects. Though there is still a possibility for manual calls to PHYSFS_init and PHYSFS_deinit. My though is, if Physfs isn't initialized, the other calls will already fail and report errors, so don't worry about it. Such logic errors would be caught very quickly during development.
Additionally, rather than rely on an additional FILESYSTEM_INITIALIZED variable, the check could be based on PHYSFS_isInit instead.

I'm thinking the Filesystem initialization should be done in a more explicit manner, rather than lazily constructed through the Utility class. In particular, the init method is already called explicitly within the Game constructor, which represents a natural place to initialize global game objects.
Anyway, I may need to think about all of this a bit more.

On a related matter, if you want to auto capture Physfs error messages in exceptions, it can be done in the exception's constructor. As many of the checks represent logic errors, which indicate programming bugs, a base type of std::logic_error may make sense there.
Filesystem.h:
class FilesystemLogicError : public std::logic_error {
public:
	FilesystemLogicError();
};

Filesystem.cpp:
Filesystem::FilesystemLogicError::FilesystemLogicError() :
	std::logic_error(PHYSFS_getLastError())
{}

I'm going to close this issue as there is likely to be no further development or support of the object in lieu of using C++17 filesystem functions and making that the problem of the user (see #179 for details).


Add release script

Can download a release and sign with sigstore/pgp, generate hashes and bundle up for release
Releaser can upload this bundle directly to maven central

Signed-off-by: Appu Goundan<EMAIL_ADDRESS>This is just a solution to get us started. I think various improvements can be made to the whole ecosystem for java developers generating slsa attestations, signing with sigstore and pgp. But I'm not addressing those here.

 Lemme fix this.

not quite ready yet, looks like I missed a few comments

done, shellcheck is clean


Browser overlay does not display data

Hello,
First I just want to say thank you, I've been watching this for years and this is an amazing tool. I am finally moving ahead with trying it out and integrating it into my livestreams.
Using the latest build (0.1.0-prerelease.11), I cannot get any data to display in the browser. My devices reflect properly in the main 'Device status' window, show accurate track data and phase status, etc. I am using CDJ-3000s.
When I go to configure/create an overlay, I cannot get it to display 'live' data - it only displays the watermark for DEMO data. Even though the device status reflects players connected and accurate data. I have tried restarting the song during scene configuration and it never hooked.
I can access the locally hosted server through my browser and it's fine - just devoid of data, empty screen and only a single JS file in the source.
I am happy to provide additional data/logs/screenshots if necessary, I feel like there's a simple fix (assuming the implementation of overlay functionality is finished/working).
Cheers!

I see from issue #24 that "there is a bug currently in the OBS overlay preventing track information there" - is this still the case? That post was from August, so I'm not sure if this is the same bug referenced.

What mixer are you using?
I built the now-playing logic with a pretty heavy dependency on the 'on-air' state of the CDJ (the red ring when the fader is up). The 900nxs and up mixers all report on-air state to the CDJs, but you have to make sure the mixer is on the network.

I'm using a V10. I wasn't testing previously using the mixer but I tried again with it online and no real change. I've also tried testing with my old XDJ1000-MK2, same behavior. I believe it sees the player as On-Air (UI element turns red) and it shows the correct track data in the Device Status window.
I can try a few more permutations, unfortunately the V10 is the only mixer I have to test with. I see that you recently added data collection for debugging, any way I can access that information? https://github.com/EvanPurkhiser/prolink-tools/commit/b85ff2c3f9abeaace320cec4f31b0a502ee80525

Well, I don't know what changed but it's working great now :) I'll resolve this issue, thanks for the prompt response


Rio-UI Alpha

An alpha for the RIO-UI should be like an initial sketch that shows off the features we plan to have. Base functionality for all primary features should be implemented, but advanced functionality and advance features are not required. The styling of the website should be a rough sketch too. It should be presentable, but the perfect color scheme and styling does not need to be there.
Current plans for the Alpha:

Hosting figured out
Basic Batting Stats for Player, Leaderboard, and All Characters
Basic Pitching Stats for Player, Leaderboard, and All Characters
Player Records? Basically the Player Leaderboard from Project Figma
Character Data
Design Document detailing this

Closing this epic for clean up, if you want to message us to talk more please feel free.