Created image to pencil sketch script

Solved #112
Used flake linting and added all required files.

whitespace error

@codePerfectPlus  Done with that!!

@codePerfectPlus
Can you please label this PR with hacktoberfest-accepted. because new guidelines are changed now.

there is no need for any label for hacktober, Hacktober label is only to encourage people for participating.

@codePerfectPlus
checkout this link - https://hacktoberfest.digitalocean.com/hacktoberfest-update


[A11y] Address A11y issues in Header

Is there an existing issue for this?

[X] I have searched the existing issues
https://issues.redhat.com/browse/RHODS-7491

Current Behavior
Certain Aria roles must contain particular children:

Expected Behavior
Resolve critical a11y header violation.

Closing for now as this is raising the same axe error in PF. Related issue: https://github.com/patternfly/patternfly-react/issues/8939.


[ARCH] Normal Form of SeqExpr

Right now we allow Call to appear in places that are not bound to Var or dataflow var.
The possible appearance include: function.body, if.then/else, SeqExpr.body.
While it is OK to have this normal form, it limits the pass writing style that we can have, since not every call corresponds to a VarBinding. Writing needs to happen to consider both Call and VarBinding. It is also a common source of bug when ppl choose to write passes assuming every call is bound to var(e.g. use Var as the key)

Most passes needs to override VisitExpr(Call)
When we try to write passes that in the form of VarBinding, and vars, there is usually missing cases.

We had a similar discussion before and the overall summary is that it boils down to the programming style of normal forms. Imperative style designs like MLIR enforces a strcutured construct(Region) to indicate a sub-control block, while enforcing every call binds to a Var. See previous post from @YuchenJin for an accurat summary https://github.com/tlc-pack/relax/issues/52#issuecomment-982182840
We did not take action so we can wait to write more passes and get more lessons.
More recently we start to write more passes on relax, we have start to feel more lessons which indicates always having Call bound to var would be extremely helpful for pass writing. This is because the corresponding var can serve as key to maps, which enables richer pass writing styles.
On the Expr side, we have two kinds of expressions:

Those that must be bound to vars in ANF:

Call and TupleGetItem

Those expressions that can appear on the call arguments without bound to a var (LeafExpr,):

Right now they are Tuple, ShapeExpr, Const, Var

So this post we discuss structualization normal form of SeqExpr. Specifically:

Control flow sub-scopes, such as function.body, if.then always contain a SeqExpr
SeqExpr.body is always a LeadExpr that refers to its binding block for vars that bound to call.
Call can only appear in Binding block and bind to a var.

This can be enforced through well formness check, and further type restrictions.

SeqExpr.body is always a Var that refers to its binding block
Can SeqExpr.body be a Tuple?

And there is another question:  Is Tuple a leaf node, which can be used in binding value (rhs), SeqExpr.body and If condition, etc?

@Hzfengsy this is a great question. I think your pt also generalizes to other possible constant nodes, such as ShapeExpr and Const.
The pt of consistency here is that for those Expr that requires to be normalized by ANF(right now we call them non-leaf expr), we cannot put them in body -- so they always have a VarBind. Updated to clarify this

T-ANF: TVM-Enhanced A-Normal Form
Principles. In short, the language is designed to mimic a dataflow graph as much as possible, including:

Convenient producer/consumer retrieval
Minimized alias if possible

Recap: in an NNVM-like dataflow graph, any intermediate tensor could be represented by a (o, i) where o is the operation that produces the tensor, and i means it’s the i-th output of o.
Design. Expressions are categorized as the following types:

Leaf nodes: relax.Var with certain internal structures:

Tensor
Parameter (generalizes and deprecates Constant)
Shape
Tuple
Homogeneous list

RValues: temporary values that are usually used as intermediate parameter passing

TupleMake(t0, …)
TupleGetItem(t, i)

Non-leaf expressions:

Call
SeqExpr
IfExpr
Function

T-ANF. Slightly different than standard ANF, it is required that:

The body of Function/IfExpr must be be SeqExpr.
The body of SeqExpr must be leaf nodes or RValue.
Leaf nodes & RValues are not allowed to be bound to any leaf nodes;

Its implications are:

If a relax.Var is a Tuple, it must be the return value from Call or SeqExpr

One-hop producer-consumer retrieval.

producers: given a var binding v = OP(v0, v1, ...), where v0, v1, ... are all leaf nodes or RValues, by looking up what expressions they are bound to, we can find their producers without extra hops.
consumers: given a var binding v = OP(v0, v1, ...), i.e. var v is produced by OP, by looking up where v is used, all its consumers can be found without extra hops.

No-alias guarantee. If Call does not produce any alias to inputs, then there is no alias in the graph.

The case of Tuple is interesting. Because we have quite a few intrinsics that leverages tuple in args, such as call_tir. Enforcing Tuple to not bound to vars might be helpful in our cases, so we could do direct pattern matching without extra hop.

Could you give some examples of such usage?

For example, we have  call_tir(tir_func, arg_tuple, shape) where arg_tuple is a tuple. As a matter of fact, we require the arg_tuple to be an explicit Tuple that can be unpacked, it enables us to do pattern match easily, so we can do
auto args = call->args[1].as<TupleNode>

Could we just make it a variadic function? It seems inconsistent with the rest of the design to require an argument to not only be of tuple type but also a tuple literal.

Having such structural grouping itself is actually helpful. Because we have arg_tuple being grouped separated as shape, making it less of a variadic function case (because seperation of shape and arg_tuple here). As a part of the intrinsic behavior.
As part of possible motivating factors that we recently encountered.
def call_dps_with_explicit_rw(func, read_tensors, write_tensors):
    func(*read_tensors, *write_tensors)

call_dps_with_explicit_rw(add, [x, y], [z])
call_dps_with_explicit_rw(split, [x], [y, z])

Where effectively the semantics of the intrinsic is to call func by passing read_tensors, and write tensors that are grouped separately. The tuple can be useful to inform such grouping. We might have a similar case for call_tir with tuple return values
t = call_tir(func, (x,), (shape0, shape1))

Where we are returning a tuple with tensor[shape0], tensor[shape1]. Here the tuple is used to group the shape arguments(to indicate the outputs)

I see, those are curious applications. I'm not sure it's much of an advantage to have special handling for these cases in ANF when you could just use BlockBuilder::LookupBinding to get the tuple definition (not much more verbose). If we want to require structurally that these must be tuple literals, maybe making this operation a separate AST node would be simpler, as that way, we would not need to have special cases for how we treat the call node depending on the op that's being called.

These are intrinsics, which are normally embedded in calls. Normally we would like to keep AST stable while maintaining some flexibility in introducing new intrinsics. Most of the rewriting themselves still follows the same convention of call, so common rewriting that pass through them still works fine. They carry some extra information, and lowering/analyis can benefit from some op specific behavior.
Coming back to complexity bought to pass writing. One thing to note is that every op usually have a fixed type signature, so if we rewrite by detecting ops, we usually know what to expect. e.g. if we look at add(x, y), we know that we are expecting no nesting in x or y. If we look at concact(arg_tuple), we know that we are expecting a tuple(one level of nesting). So most of the op-specific rewriting pass do not need to worry about handle un-nesting/nesting case.

I think having lots of op-specific conventions could actually become more complex for passes to deal with, especially if these become invariants that other passes rely on. For example, it might mean that passes would have to have lots of special cases when handling call nodes because of specific operators. However, if tuples in calls are the only such case, then it might be reasonable to leave only that one (we might have to figure out what to do about tuples nested in tuples, though).
For printing, we might want to have different rules/flags. I think, though, that having a simple and consistent representation would ultimately simplify pass-writing.

Agree about less special casing but instead state things as general simple rule(eg tuple can appear in call args).
This was the normal form in the current way that we can have generic code that handles tuple rewriting that are op independent, while allowing quick local pattern matching for specific op that we know signature.


Exception: SNlM0e token value not found. Double-check cookies dict value or pass it as Gemini(cookies=Dict())

hello i`m have this issue
Exception: SNlM0e token value not found. Double-check cookies dict value or pass it as Gemini(cookies=Dict())

same problem

I'm experimenting with the feasibility of this package. If it's not possible, I'll document the official API usage via Google AI Studio.
Thank you for the issue. Although it's likely that it still won't work for you, you should not encounter this error in version 0.1.3.

Usercodersystem, sapycola
Please, try to use 1.0.4 or above!
We are currently modifying the package with a focus on extensive code refactoring and future maintainability, so errors may occur. We are also in the process of making adjustments to the returned dictionary for easier access in the future.
We appreciate your understanding. Thank you!!!
python uninstall python-gemini-api

python install python-gemini-api==1.0.4


ExamSessionManager.create() cannot return next question pool

both create() and resume() are not capable of returning only the next question pool with unanswered questions, but this is the most desirable behavior.  I propose that if fetch_all == False, we then return the next question pool only.
Basically, we will always return results from _get_next_questions(), and the passed value of 'include_answered' will be equal to the value of 'fetch_all'.

Basically, we will always return results from _get_next_questions(), and the passed value of 'include_answered' will be equal to the value of 'fetch_all'.

Are you saying then that fetch_all==False implies that include_answered==False (which is now include_responses to prevent ambiguity) and in the case where it is False, only the next question pool (and its questions) should be returned?
This whole routine might benefit from a makeover as you noted in #86 I believe

I think my quoted assertion is incorrect.  I propose this:

For create(), it will call _get_next_questions(include_responses=False)
For resume(), it will take a parameter "include_responses" that will be passed to _get_next_questions()
In all cases, as noted in the original issue description, a call to create() or resume() where fetch_all==False will return the results of a call to _get_next_questions().

Looking at the code, I'm not convinced that fetch_all is doing what is advertised.  We should make sure that if fetch_all==True, we get all questions for the whole exam.  And if fetch_all==False, only questions for the next incomplete question pool.
This definitely could use a makeover, but I don't think we can invest in that at the moment since this feature is oh-so-close to being done.


Hlint fails to parse code with TypeApplications

/home/syd/cs-syd/code/open-source/zifter/zifter/test/Zifter/ZiftSpec.hs:17:5: Error: Parse error in expression: eqSpec@(ZiftResult Int)
Found:
    spec = do
        eqSpec @(ZiftResult Int)
  >     genValiditySpec @(ZiftResult Double)
        functorSpec @ZiftResult
        applicativeSpec @ZiftResult

Using HLint 1.9.39 with haskell-src-exts-1.19.0 the fragment:
{-# LANGUAGE TypeApplications #-}

spec = do
        eqSpec @(ZiftResult Int)
        genValiditySpec @(ZiftResult Double)
        functorSpec @ZiftResult
        applicativeSpec @ZiftResult

Works for me, giving no hints, but no parse error. Can you check your versions? Do you have TypeApplications turned on in your file? If all that matches, can you attach a complete file that allows you to reproduce the error?

@ndmitchell, upgraded to those versions and everything was fine.
Thank you for helping. Sorry to waste your time here.

Hey sorry to comment on an old thread but seems I'm running into this issue too. Currently I just have HLint installed with Nix and am calling it from Neomake. In this thread and in others I see you recommend people use HLint with an updated version of haskell-src-exts - what does this mean?

@adelbertc - how did you install hlint (cabal or stack)? which version are you on?

Installed it through Nix, hlint --version gives v1.9.41

Nix (according to Stackage) has HLint 2.0.9 and haskell-src-exts 1.19.1. If you can install those with whatever upgrade/update command Nix supplies, I think it will fix itself.


feat: add unloadClusterRelated in ReferenceConfig which can uninstall…

What is the purpose of the change
In mesh mode, all traffic governance capabilities can be sunk into sidecar, such as retry, timeout, and load balancing.
Therefore, I added the unloadclusterrelated configuration in ReferenceConfig. This configuration is used to determine whether to integrate Cluster, Directory and Router when building the invoker of this call.
Delegate retry, load balancing, timeout and other traffic management capabilities to Sidecar.

Brief changelog
Verifying this change

Checklist

[x] Make sure there is a GitHub_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GitHub issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[x] Each commit in the pull request should have a meaningful subject line and body.
[x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Check if is necessary to patch to Dubbo 3 if you are work on Dubbo 2.7
[ ] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
[ ] Add some description to dubbo-website project if you are requesting to add a feature.
[ ] GitHub Actions works fine on your own branch.
[ ] If this contribution is large, please follow the Software Donation Guide.

Codecov Report

Merging #10498 (d1232dd) into 3.1 (64c928a) will decrease coverage by 0.10%.
The diff coverage is 42.85%.

@@             Coverage Diff              @@
##                3.1   #10498      +/-   ##
============================================
- Coverage     65.49%   65.39%   -0.11%
- Complexity      296      318      +22
============================================
  Files          1275     1275
  Lines         55045    55050       +5
  Branches       8296     8298       +2
============================================
- Hits          36053    36000      -53
- Misses        15073    15113      +40
- Partials       3919     3937      +18

Impacted Files
Coverage Δ

...apache/dubbo/common/constants/CommonConstants.java
100.00% <ø> (ø)

...a/org/apache/dubbo/config/ReferenceConfigBase.java
62.22% <33.33%> (-0.66%)
:arrow_down:

.../java/org/apache/dubbo/config/ReferenceConfig.java
74.18% <50.00%> (-0.16%)
:arrow_down:

...nt/metadata/ServiceInstanceHostPortCustomizer.java
65.78% <0.00%> (-21.06%)
:arrow_down:

...che/dubbo/registry/client/NopServiceDiscovery.java
44.44% <0.00%> (-11.12%)
:arrow_down:

...va/org/apache/dubbo/remoting/TimeoutException.java
22.22% <0.00%> (-11.12%)
:arrow_down:

...dubbo/common/status/support/LoadStatusChecker.java
58.33% <0.00%> (-8.34%)
:arrow_down:

...dubbo/remoting/exchange/support/DefaultFuture.java
80.17% <0.00%> (-7.76%)
:arrow_down:

.../common/threadpool/serial/SerializingExecutor.java
70.37% <0.00%> (-7.41%)
:arrow_down:

...ava/org/apache/dubbo/rpc/proxy/InvocationUtil.java
84.84% <0.00%> (-6.07%)
:arrow_down:

... and 30 more

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

Please also submit a pr to dubbo-website to enhance the related docs

Please also submit a pr to dubbo-website to enhance the related docs

OK, I will do it.


uninitialized constant DeviseTokenAuth::Concerns in development.

When posting issues, please include the following information to speed up the troubleshooting process:

Version: 1.1.0
Request and response headers: NA
Rails Stacktrace:
class User < ApplicationRecord
include DeviseTokenAuth::Concerns::User
end
Environmental Info: only in DEV for some reasons

Gems: are you using MongoDB, Grape, RailsApi, ActiveAdmin, etc.? yes

it happens like 50%, startup rails server is fine but going to any route gives the error

That happens when the gem isn't installed, otherwise, it would be very weird that is only happening to you. Do you have mount_devise_token_auth_for in the routes?

@MaicolBen I'm currently running into this same issue, though the app never successfully boots at all in dev/test environments unlike the @wongy91's 50% success rate.

@wongy91 were you ever able to solve this?

That happens when the gem isn't installed, otherwise, it would be very weird that is only happening to you. Do you have mount_devise_token_auth_for in the routes?

I guess you have this okey, can you post the backtrace?


[libpqxx]Update to version 6.4.3

Related issue: #5899
We blocked by a known VS bug about adding template <typename T> before [[deprecated]]. This bug has been fixed in VS2019 when updating version to 6.4.3. See bug here: https://developercommunity.visualstudio.com/content/problem/139521/compilation-error-on-deprecated-template-construct.html, so remove [[deprecated]] temporarily as a workaround to update to the latest source version.

Awesome. Thanks, @wangli28!


Setup Rails-React app

What I did ♻
In this project's branch, I connect Rails with react in order to have the backend of my app in Ruby-On-Rails and the frontend with React-redux.
Project requirements 📗

Create a new Rails app called 'hello-rails-react'.

Use the command rails new -j webpack my_new_rails_app as described in the previous lesson's tutorial.

Verify that the jsbundling-rails gem is added to your Gemfile.
Initialize your project with Git.
Install needed node dependencies as described in the previous lesson's tutorial.
Create a babel.config.js in the root folder of your project as described in the previous lesson's tutorial.
Update webpack.config.js to include the babel-loader as described in the previous lesson's tutorial.
Make sure that your project has a Postgres database set up.
Create a table for storing your messages and create 5 different greetings.
Create an API endpoint that selects a random greeting from your table (you will need a controller with an action and Rails route).
Create a static view that will be the root of your app.

Create the App component with react-router and render it in your static view.
Create the Greeting component that will display a greeting. Set it up as a route in your App component.
Create a store, an action, and a reducer that will connect to your API endpoint to get the random greeting.
Display the random greeting in your Greeting component.

Thank you @gemmen29


Implement CONCAT_WS

Implement CONCAT_WS.
Example: concat_ws(',', 'abcde', 2, NULL, 22) => abcde,2,22
Reference:
https://www.postgresql.org/docs/9.1/functions-string.html
#112

convert non-null Datums in the row into strings, concat all strings with separators

You may assume that concat_ws will always have string as parameter, and let the SQL frontend to insert the cast function for you. I guess this would make things easier.

convert non-null Datums in the row into strings, concat all strings with separators

You may assume that concat_ws itself will always have string as parameter, and let the SQL frontend to insert implicit cast function for you. I guess this would make things easier.

Apologies, I realized my original comment was ambiguous with regards to how I handle NULL values as arguments to concat_ws.
With the suggested approach, how do I handle null values as arguments to concat_ws? These might only surface during runtime, SQL frontend can only remove literal NULL values.
I'm thinking of just using Datum, then within the eval function we can check if Datum is NULL or not, and skip it if it is, otherwise concatenate it, after casting it into a String.

Datum is a nullable value of any type. The comment above suggests to simplify this problem into handling nullable values of string, which are Option<&str> from Utf8Array. The frontend can generate sub-exprs (Expr::Cast) to make sure all arguments (ArrayImpl) passed to concat_ws in backend are always Utf8Array.
No matter it is Datum (Option<ScalarImpl>) or Option<&str>, the handling of null is the usual way of handling Option::None is rust.
In the non-null case, it is easier this way because the conversion from ScalarImpl to String is just reusing cast (which is yet to be implemented). To keep PRs small, we can support concat of strings first and add those casts in a follow up.

Datum is a nullable value of any type. The comment above suggests to simplify this problem into handling nullable values of string, which are Option<&str> from Utf8Array. The frontend can generate sub-exprs (Expr::Cast) to make sure all arguments (ArrayImpl) passed to concat_ws in backend are always Utf8Array.
No matter it is Datum (Option<ScalarImpl>) or Option<&str>, the handling of null is the usual way of handling Option::None is rust.
In the non-null case, it is easier this way because the conversion from ScalarImpl to String is just reusing cast (which is yet to be implemented). To keep PRs small, we can support concat of strings first and add those casts in a follow up.

Need some further clarification. Am confused by the term "implicit cast". It was mentioned here that I will still need to explicitly call cast_explicit on all the arguments. Is it called implicit because that the type we are casting to is not explicitly a varchar, but a function call which will do a cast in runtime?
On the backend, is the idea to:

evaluate argument expressions to an ArrayImpl i.e. expr.eval(input).
Convert ArrayImpl into Utf8Array
Call concat_ws on the Utf8Arrays?

If so, how should I go about converting ArrayImpl to Utf8Array, is there a safer way than just unwrapping the ArrayImpl?
Is there an idiomatic way to transpose a vector of Utf8Array? My understanding is that each Utf8Array is a column, and we want to transpose to pass rows into concat_ws.
Thanks for your patience in answering my questions :pray:

implicit vs explicit is from the database user's perspective: CAST(123 AS varchar) and 123::varchar are explicit, while substr(123, 2) and concat(123, 'foo') are implicit. As mentioned above, implicitly casting to varchar reports an error in most cases (e.g. substr here) except for concat. So we need to use the call cast_explicit (rather than cast_implicit) although the cast expr is implicitly added by us (db developer) rather than explicitly written by db user.
The high level idea of backend 1&2&3 is correct.

To convert from ArrayImpl to Utf8Array, there is as_utf8 and into_utf8.
As for vector transpose... There is currently no utilities to convert between column-major and row-major. Just use nested for-loops to make it working first, and see if it is possible to improve from there.

may put "closes #XXXX" in the PR to close the related issue automatically after the PR is merged.

Not closed yet, because still have frontend changes to be made.

FYI casting from numbers is WIP: #2522


Replace pods with nodes.

Fixes #
Description
How was this change tested?

Does this change impact docs?

[x] Yes, PR includes docs updates
[ ] Yes, issue opened: #
[x] No

Release Note

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

If you think there is some other clarification, feel free to reopen


Fix scoring on score board

If you only enable a few checks, you get maximum points for others. Maybe this is expected?

https://github.com/pwnbus/scoring_engine/pull/28


French translation update

I'm sorry about that. But I don't have a Git client installed on my PC.
So, I only use the possibilities offered by the github.com site. More
specifically, I use the "Edit" button on the "fr.json" page. It is this
functionality which systematically removes the last character from the
file (new line).
I do not know how to do otherwise. If there is better to do, don't
hesitate to tell me.
------ Message d'origine ------
De: "CraigD"<EMAIL_ADDRESS>À: "CDrummond/lms-material"<EMAIL_ADDRESS>Cc : "Franck-Berry"<EMAIL_ADDRESS>"Author"
<EMAIL_ADDRESS>Envoyé : 22/06/2020 16:29:47
Objet : Re: [CDrummond/lms-material] French translation update (#299)

@CDrummond commented on this pull request.

In MaterialSkin/HTML/material/html/lang/fr.json
https://github.com/CDrummond/lms-material/pull/299#discussion_r443600550:

\ No newline at end of file

+"Do not crossfade successive tracks from the same album.":"Do not crossfade successive tracks from the same album.":"Ne pas effectuer de fondu enchaîné entre les pistes successives d'un même album.",
Hmmm... this line is messed up - but I'll fix.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/CDrummond/lms-material/pull/299#pullrequestreview-434979597,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AMWTCQPP7DNUIW3T5RSGNGTRX5TFXANCNFSM4OEQTWFQ.


Implemented a typewriter effect for the quote display

Created a function that handle the event and tweaked the newQuote function a little to make it work

Nice, Solving issue #6


Create astar.degens.vote custom domain

Trying to create a custom domain for astardegens.eth to astar.degens.vote
Hi! What is your PR about?

[ ] Add or edit a skin
[X] Add a custom domain for your space
[ ] Add an alias to migrate your space

Closing this PR for now, feel free to open it again once you've done the changes.


Static IP address

How do you assign static ip address to the VM.
I copied VM MAC address to my DHCP server, assigning ip address to MAC address, then restarted the VM but VM's ip address is not what is assigned by DHCP

There might be an active DHCP lease for that MAC address still in the router. Try shutting down the VM and then reboot the router after changing DHCP reservations. This should clear all DHCP leases on the router. Start the VM after the router is back to normal operation.

@01kbpatel I have made changes to the repo which should solve your problem. If there is nothing further, I will close this issue after 48 hours.


add support for azure resources integration TF resource

Issues
https://github.com/OpsLevel/team-platform/issues/414
https://github.com/OpsLevel/opslevel-go/pull/430
Changelog

[x] Add resource
[x] Make a changie entry

Completed by this PR


Bug : When remuxing dolby atmos mkv to mp4, complexity index is not present.

Here is a Dolby Atmos sample file with an EAC3-JOC audio stream : https://we.tl/jxvi4Pgwz9
source : https://thedigitaltheater.com/dolby-trailers/
From this, if I demux the EAC3-JOC, as you can see the complexity index is set correctly.

However, when I remux MKV to MP4, the complexity index is not present.

The reason this bug needs to be resolved is that, in the case of a smartphone that supports Dolby Atmos, the Dolby Atmos virtualizer is automatically activated only when the complexity index is presented.

That doesn't look like an issue with these builds to me.
Please raise issues with ffmpeg itself in the ffmpeg bugtracker.

That doesn't look like an issue with these builds to me.

Does that mean my problem is not happening with this build? : Latest Auto-Build (2022-10-28 12:38)

It's still not an issue of these builds.
Please only report issues specifically with the builds here. I cannot take care of all ffmpeg related issues. FFmpeg has its own bugtracker and support channels.
If this would be happening only with my builds, but not with something you or someone else built, then it'd be a valid issue here.
But to me this looks like it's an issue with ffmpeg itself, not specifically these builds.

Okay. Thank you for the information.


Fix scraping issues due to recent changes on forvo.com

Fixes #64.
I tried to be robust against minor structural changes, which is why the fix looks kinda funky and complicated.

Thanks a lot!


@GW_USE_DEVICE_ALLOCATOR_FILE@

Set @GW_USE_DEVICE_ALLOCATOR_FILE@ based on gw_enable_caching_allocator, to include only one DefaultDeviceAllocator for a given installation.
This way, after the library is built and installed, the user does not need to specify -DGW_ENABLE_CACHING_ALLOCATOR,
which would currently select the DefaultDeviceAllocator to use.
I have not tested this yet. (I think we will need to add the build-directory to the include path.) I wanted to get opinions on this idea first.
To be clear, here is the error that can hit if we fail to use the same compilation flags as when the library was installed:
src/libpancake.so.1.1.0: undefined reference to
`claraparabricks::genomeworks::cudaaligner::create_aligner(
    claraparabricks::genomeworks::cudaaligner::AlignmentType, int, CUstream_st*, int,
    claraparabricks::genomeworks::CudaMallocAllocator<char>, long)'

Can one of the admins verify this patch?

HI @pb-cdunn , thanks for submitting this PR. This certainly is a problem that needs to be addressed. We are evaluating your PR and will get back to you soon.

ok to test


Options icon missing

Describe the bug
The options icon(three dots) are missing in the code editor on the azure portal terminal. The button exists there and works when clicked in the region, but the icon that is supposed to indicate that is missing.
To Reproduce
Steps to reproduce the behavior:

Open terminal in azure portal
Open the code editor using code .

Expected behavior
The icon is supposed to appear to let the users know where the options menu is.
Screenshots

Desktop (please complete the following information):

OS: Windows 11
Browser Edge
Version 110.0.1587.49

Additional context
Add any other context about the problem here.

🎓 Add a tag to this issue for your current education role: student, Student Ambassador or educator.
Student Ambassador

Hello, can you point the learn module this error is from?


Add Model for Mozilla's SSL configuration guidelines

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

[x] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
[x] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Is your feature request related to a problem? Please describe.
Currently, different plugins maintain separate standards regarding TLS practices.
Different plugins allow different ways to set certain TLS versions or even specific cipher suites.
Describe the solution you like
In my contribution to mail/postfix (https://github.com/opnsense/plugins/commit/bfdc07de980df2076a8d9a2dac0044c83e65d491) I have used Mozilla's SSL configuration guidelines to improve the quality of TLS version and cipher specification.
Since then, OPNsense's mail/postfix plugin offers a simple choice between an 'Old', 'Intermediate' and 'Modern' configuration.
Using Postfix as an example, I have to be critical regarding my own implementation choice, because Mozilla's recommendations are hard coded into the main.cf Jinja template and have to be updated on a per-plugin basis.
It would be better if I have had a more general way of implementing good TLS practices.
Mozilla maintains their TLS recommendations in JSON, which could trivially included as an OPNsense model that can be used in different templates.
OPNsense components and plugins could implement their TLS settings through this.
Again with the Postfix example there would no need to implement TLS cipher suites like
tls_low_cipherlist = ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA

instead it could work something like
tls_low_cipherlist = {{ OPNsense.ssl.configurations.old.openssl | join(':') }}

Additional context
In case this suggestion would be favored by the project, I may find the time to contribute this. What do you think about this?

Although I do like the Mozilla standards, I'm a bit struggling on how this should work in a way that it's both maintainable and doesn't break existing setups.  Ideally one would be able to choose between the Mozilla standards or "custom" in which case all settings should be mapped accordingly.
Persisting the settings in a model wouldn't make much sense in that case, some sort of standard settings collections which one could map into the jinja template would be more logical in that case.
functionally one would be able to do something like this in the template (pseudo code):
{% set tls_choice = 'intermediate' %}
tls_low_cipherlist =  {{ helpers.get_default_setting('mozilla_tls', 'configurations.' + tls_choice + '. ciphers. openssl'}}|join(':') }}

The question is how much reuse we would eventually offer with this given the amount of work needed to implement this, building the facility, making sure it's globally used in all available components (the webgui doesn't use a new template yet for example) and keeping the development documentation aligned.

Thanks for adding your perspective to my suggestion. I think you are absolutely right, that we would need to allow configurations other than Mozilla's. (Even though they probably cover all of the more reasonable use cases.)
I can offer that I will write a module core/src/opnsense/service/modules/addons/tls_policies.py that accepts Mozilla's policies and similarly structured data.
We could include Mozilla's policies in opnsense/core and allow to add community contributed TLS policies for uncovered use cases through opnsense/plugins.
Writing a full blown TLS policy editor for the web-based user interface is probably not worth it or necessary, then.

The question is how much reuse we would eventually offer with this given the amount of work needed to implement this, building the facility, making sure it's globally used in all available components

You are of course right. Mozilla offers various hbstemplates for various components that OPNsense uses, that would just need to be transformed into Jinja.

making sure it's globally used in all available components (the webgui doesn't use a new template yet for example) and keeping the development documentation aligned.

I think that it is better to ship most of the components with 'Mozilla Intermediate' as default, but allow reconfiguration on a per-plugin basis. The reasoning behind this is, that different components are to be expected to have different types of clients. An OPNsense operator may for example:

Set the administrative web user interface to 'Mozilla Modern' because he does not require TLS 1.2 compatibility.
while using 'Mozilla Old' for Postfix, because he still wants to maintain encryption with older peers.

I think it is not necessary that every component would use tls_policies.py. I would understand it as an offer towards the maintainers of OPNsense components to upstream the question of which TLS configuration is reasonable and/ or abolish the need to implement their own mechanism for user configurable TLS settings.
Long story short: Are you interested in a tls_policies.py as a basic proof of concept?


Adding expandAll property on ExpandingTable

This flag is useful when searching on the child elements of the ExpandingTable and you want to expand the entire table to make the items accessible. This should not discard the current selected item state.

The code looks good, but let's get some tests

Going to merge this, and let's handle the tests in a separate PR


Are namespace actions really important?

There are 3 actions to CRUD namespaces in K8s present in the charms. At this point in time, beside the fact they fail, I am wondering if they are really so important?

I am also not sure what purpose these actions serve. We are not supposed to wrap all kubectl commands but we do so with namespace CRUD actions. There might be some other reason why we have these actions, if not, +1 for removing them.

I think these are useful and I vote for keeping them. They were contributed by @jacekn from Canonical IS, who are Real Users of CDK. Maybe they seem out of place b/c we don't have many actions yet, but that will change once we start implementing user-management actions.

Here are tests so we do not break these actions again. https://github.com/juju-solutions/bundle-canonical-kubernetes/pull/334


Add Bearer Authentication

I can work on that tomorrow. Thanks for the quick reply!

I've pushed new commits, let me know what you think.
An Endpoint now has a Security object.
The Security object has a list of Polices.

@alexcampana, what are your thoughts on this commit? Should we update the openapi spec file to have an example of using a Bearer Authentication?
https://github.com/alexcampana/ApiFirstMediatR/pull/60/commits/4c3c051d6730e7d2c9015cb26b58516b4a8414ed

I've added unit test for the Security mapper, and updated the Endpoint mapper unit test.

@alexcampana, what are your thoughts on this commit? Should we update the openapi spec file to have an example of using a Bearer Authentication?
4c3c051

I definitely like it, at some point I'd like to use that policy check in the actual integration tests, but definitely not a problem that needs to be solved now.

Looks good, I'll get a new nuget package out shortly!


Meta-analytic algorithms

Here's a list of the methods we plan to support and their current statuses in my branch:

Kernel-based coordinate-based meta-analyses:

[X] ALE
[X] SCALE
[X] MKDA Density Analysis
[X] MKDA Chi2 Analysis (Neurosynth speed-optimized version)
[X] MKDA Chi2 Analysis with empirical null
[X] KDA

Model-based coordinate-based meta-analyses:

[ ] BHICP Available implementation only in C++
[ ] HPGRF/BHPGM Available implementation only in C++
[ ]  SBLFR
[X] SBR Cannot currently be run on a full brain. No source code available.

 Sorry I haven't had time to keep up with all the changes; will try to get to it later this week.

Also looping @nicholst in in case he can think of other methods that are relatively straightforward to implement and are missing from the list. Tom, NiMARE is the better-named successor to the "PyCIBMA" package we proposed in our grant. @tsalo is a grad student working with Angie who's taking the lead on developing this.

SCALE and MKDA Chi2 analysis with FWE correction seem to be working as of c237ff4, although when I tried to test them on the full Neurosynth database my computer ran out of application memory... They're also pretty slow in general, so there's still a fair amount of optimization to be done, I'm sure.

I think I fixed the IBMA empirical nulls in 96aa5d2. Hopefully KDA is now working as well.

I ran all of the meta-analyses on the 21 pain studies dataset. The results, thresholded at p<0.05 with a variety of corrections, are shown in the following image. The MFX GLM used FSL's cluster, with a cluster-defining threshold of p<0.01. RFX GLM, Z MFX, FFX GLM, Fisher's, Stouffer's, and Weighted Stouffer's all use Bonferroni correction. Contrast Permutation and Z Permutation use FDR correction because Bonferroni correction doesn't really work for the empirical null distributions. The MKDA and KDA density analyses use voxel-level FWE correction, and ALE and SCALE both use uncorrected thresholds. SCALE can't use multiple comparisons correction, but I chose to only plot the uncorrected map for ALE because the voxel-level and cluster-level FWE corrected maps were empty.
The only thing that seems off at this point (barring more quantitative checks) is the MKDA Chi2 analysis with FWE. I'm pretty sure I messed something up with that one.

Very nice! The chi2 map is definitely messed up; I'll try to look at that soon.
Have you tried to reproduce these results with @cmaumet's Matlab IBMA package? For at least the algorithms implemented in both packages, the results should presumably look (almost) identical, and quantitative comparison of the maps would provide a nice sanity check.

Good thinking. I was able to compare the Fisher's, Stouffer's FFX, Stouffer's RFX, Weighted Stouffer's, and FFX GLM IBMAs, and even caught a couple of mistakes I made in the Fisher's and FFX GLM implementations. The RFX GLM implementation in the MATLAB toolbox seems kind of complicated (i.e., I won't be able to use it without completely setting up the toolbox), so I haven't tested that yet. The MFX GLM, Contrast Permutation, and Z Permutation IBMAs are not implemented in the MATLAB package, though there is Python code for the MFX GLM in the nidmresults-paper repo.
I converted the MFX GLM Python code to use Nipype (still need to make it an actual workflow), which is what is in the figure. A couple of things that I changed for that one are that I didn't rescale the FSL maps, nor did I take the square roots of the varcope images. I wasn't sure if either step was necessary. The scaling didn't affect the results at all and it seemed like the varcopes were already in the right units in the released datasets.
The only weird thing in the IBMA toolbox code was that the tests all appear to be one-tailed (or at least the ones I've checked). I assumed that these tests (e.g., the Stouffer's t-test on z-values) should be two-tailed and that's how I had them implemented. I can change that, but I'm not sure it makes sense to do so.

I can't speak to the first question (though I don't see why it wouldn't be okay), but assuming the z or t scores on the colorbars are correct for all analyses, it sure looks like there's a bug somewhere. The general idea that all or nearly all voxels would be significant in an FFX analysis is not intrinsically problematic (since the null is surely false everywhere in the brain, so at the limit, if you had enough data, all of these maps would be significant everywhere). But it's pretty weird that there's so little spread in the values, especially given that the max is not very large. I'll take a look at the code.
BTW, I think you can go ahead and merge your branch into master--it'll be easier to work with that way.

Thanks for taking a look. @cmaumet was kind of enough to offer her expertise as well, so hopefully someone will be able to figure out what's happening.
It's possible that everything really should be significant, although there are only 21 studies, so I doubt it. My guess is that there's a bug, although the Python code (except when two-sided inference is turned on) produces equivalent results to the MATLAB version, which shows in the last two cells of this notebook. Well, there is one odd voxel with very different results, but other than that the two results are equivalent.
I'll merge into master now to make things easier.

@cmaumet Thank you for your help! Your responses really clarified some things for me.

For one-tailed versus two-tailed, my understanding is that we could do both.

Awesome! I’ll add an argument to the IBMA functions to switch between one- and two-tailed versions.

Which method did you use to compute the degrees of freedom for FFX GLM? In our analyses, we had used a wrapper around FSL’s FFX model, maybe that’s also something you could also use via nipype?

I translated the MATLAB code from the IBMA toolbox and adapted it to be two-tailed, so I didn't change anything in the degrees of freedom calculation. It's definitely a good idea to just use FSL, especially since we already have everything set up for the MFX GLM function. I’ll open a PR with a new version of the FFX GLM that is pretty much the same as the MFX GLM with FSL’s flameo, but using fixed effects (fe) run mode.

As far as I remember, for RFX GLM we reused SPM’s implementation of one-sample t-tests which you could maybe also do through nipype?

I’m currently using scipy.stats.ttest_1samp, but I can compare the results to SPM output.

For MFX GLM, we reused FSL’s flameo function with ‘flame1’ option. Not computing the rescaling will probably not affect the results much (this is to compensate for different solutions used by SPM and FSL to scale the data, leading to different unit scales in the contrast maps). But if you are also using flameo then the contrast variance maps should be passed as inputs rather than standard error maps which is why we squared (-sqr) the standard error maps form NIDM-Results. Does that make sense or did I miss something?

Ohhh, I didn’t realize that flameo did use a different unit than provided by the NIDM Results. That makes sense. I’ll add the squaring back into the MFX GLM/FFX GLM code.

It's unclear if we'll every take a crack at SDM, but as far as model-based CBMA methods go, per a discussion with @nicholst it's likely that one frequentist approximation of a Bayesian approach will be developed and implemented, as well as possibly one of the three above models. Closing this issue now that most methods have been implemented.


[Bug][Github Plugin] API call to remote-scopes returns a list of 1 and no github data

Search before asking

[X] I had searched in the issues and found no similar issues.

What happened
When calling plugins/github/connections/[github_conn]/remote-scopes?groupId=[github_org] with a connection enabled with a GithubApp the response returns a page size of 1 and the returning result is missing data.
{
    "children": [
        {
            "type": "scope",
            "parentId": "org",
            "id":  [some_id],
            "name": "repo",
            "fullName": "org/repo",
            "data": null
        }
    ],
    "nextPageToken": "eyJwYWdlIjoyLCJwZXJfcGFnZSI6MTAwfQ=="
}

When calling the same API with the github connection setup with a token I a full response with the data populated correctly.
What do you expect to happen
I expected to see the same result as with a token.
How to reproduce
I have recently upgraded from v0.20 to v1.0.0 beta 5.
Setup two github connections one using an API key and the other using a token.  They are both enabled to use the graphql API.
Anything else
No response
Version
v1.0.0-beta5
Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Sounds like some essential permissions are missing.
Did you following this guide and set up the required permissions?


Support basic operations when using "psql"

Hi there,
by giving psql a little spin with respect to basic operations on CrateDB, I discovered some flaws. While I don't know what it would take to fill in those gaps, I nevertheless wanted to share my observations with you. Maybe you can do something about it without much effort.
I used Docker to quickly spin up instances of PostgreSQL and CrateDB and then connected to them by using psql like
# PostgreSQL
docker run -it --rm --env "POSTGRES_HOST_AUTH_METHOD=trust" --publish 5432:5432 postgres:13.1
psql postgres://postgres@localhost

# CrateDB
docker run -it --rm --publish 5432:5432 crate:4.3.3
psql postgres://crate@localhost

When using PostgreSQL, this workflow works well:
# Create database.
postgres=# CREATE DATABASE testdrive;

# List databases.
postgres=# \l

# Connect to database.
postgres=# \c testdrive
You are now connected to database "testdrive" as user "postgres".

# Create table.
testdrive=# CREATE TABLE testdrive (foobar int);

# List tables.
testdrive=# \d

However, on CrateDB, the outcome is
# Create database.
crate=> CREATE DATABASE testdrive;
ERROR:  line 1:8: no viable alternative at input 'CREATE DATABASE'

# List databases.
crate=> \l
ERROR:  Unknown function: pg_catalog.pg_encoding_to_char(d.encoding)

# Create table.
crate=> CREATE TABLE testdrive (foobar int);

# List tables.
crate=> \d
ERROR:  Unknown function: pg_catalog.pg_table_is_visible(c.oid)

Thanks already and with kind regards,
Andreas.

I well recognize that CrateDB implements namespaces for tables in the form of schemas [1]. Thus, listing schemas by using the \dn command works flawlessly on both PostgreSQL and CrateDB.
postgres=# \dn
  List of schemas
  Name  |  Owner
--------+----------
 public | postgres

crate=> \dn
  List of schemas
    Name    | Owner
------------+-------
 blob       | crate
 doc        | crate
 pg_catalog | crate
 sys        | crate

[1] https://crate.io/docs/crate/reference/en/4.3/general/ddl/create-table.html#schemas

I well recognize that CrateDB implements namespaces for tables in the form of schemas [1]. Thus, listing schemas by using the \dn command works flawlessly on both PostgreSQL and CrateDB.
postgres=# \dn
  List of schemas
  Name  |  Owner
--------+----------
 public | postgres

crate=> \dn
  List of schemas
    Name    | Owner
------------+-------
 blob       | crate
 doc        | crate
 pg_catalog | crate
 sys        | crate

[1] https://crate.io/docs/crate/reference/en/4.3/general/ddl/create-table.html#schemas

On top of my findings outlined above, CrateDB actually treats databases as schemas to some extent. That can be revealed by connecting to a database using the \c command like
crate=> \c testdrive
testdrive=> CREATE TABLE foobar (bazqux int);

That will implicitly create "testdrive" as a schema:
testdrive=> \dn
  List of schemas
    Name    | Owner
------------+-------
 blob       | crate
 doc        | crate
 pg_catalog | crate
 sys        | crate
 testdrive  | crate

On top of my findings outlined above, CrateDB actually treats databases as schemas to some extent. That can be revealed by connecting to a database using the \c command like
crate=> \c testdrive
testdrive=> CREATE TABLE foobar (bazqux int);

That will implicitly create "testdrive" as a schema:
testdrive=> \dn
  List of schemas
    Name    | Owner
------------+-------
 blob       | crate
 doc        | crate
 pg_catalog | crate
 sys        | crate
 testdrive  | crate

Could you create a dedicated issue for pg_catalog.pg_encoding_to_char and one for pg_catalog.pg_table_is_visible?
Not sure about the other points.
The schema/database difference is expected. CrateDB does not support database objects.
The explicit schema creation is also kinda expected. Not sure if that is a problem?
I guess it could be with tools which implicitly try to create a schema. But for psql it shouldn't be as you manually invoked the CREATE SCHEMA statement.
I think we'd need a more concrete use-case and incentive to add support for explicit schema creation.

Could you create a dedicated issue for pg_catalog.pg_encoding_to_char and one for pg_catalog.pg_table_is_visible?
Not sure about the other points.
The schema/database difference is expected. CrateDB does not support database objects.
The explicit schema creation is also kinda expected. Not sure if that is a problem?
I guess it could be with tools which implicitly try to create a schema. But for psql it shouldn't be as you manually invoked the CREATE SCHEMA statement.
I think we'd need a more concrete use-case and incentive to add support for explicit schema creation.

Hi Mathias,
thank you for looking into this.

Could you create dedicated issue(s) for...

Sure, I've just created #10963 and #10964 for being able to follow up on the specific error messages coming from attempts to list available databases and tables. Thanks!

The schema/database difference is expected. CrateDB does not support database objects.

I hear you.

The explicit schema creation is also kinda expected. Not sure if that is a problem? I think we'd need a more concrete use-case and incentive to add support for explicit schema creation.

Sure, no worries. I just tried to give us the full perspective on some potential gaps. More specific use-cases might attach to this later if this is really a problem.
With kind regards,
Andreas.

Hi Mathias,
thank you for looking into this.

Could you create dedicated issue(s) for...

Sure, I've just created #10963 and #10964 for being able to follow up on the specific error messages coming from attempts to list available databases and tables. Thanks!

The schema/database difference is expected. CrateDB does not support database objects.

I hear you.

The explicit schema creation is also kinda expected. Not sure if that is a problem? I think we'd need a more concrete use-case and incentive to add support for explicit schema creation.

Sure, no worries. I just tried to give us the full perspective on some potential gaps. More specific use-cases might attach to this later if this is really a problem.
With kind regards,
Andreas.

Closing this here as https://github.com/crate/crate/issues/10963 was resolved via https://github.com/crate/crate/pull/11808 and we've another issue to track pg_table_is_visible: https://github.com/crate/crate/issues/7988


The token is not required for Public page

Can you support token optional?

I'm sorry, but the notion-py that this project depends on is supposed to enter ID and password of notion if don't have token.


logo_added

#17

@Kajol-Kumari  as you said ! sorry but im having issues with reverting and rebase of commit

@Kajol-Kumari Now!!

You are so helpful @Kajol-Kumari  Thank you so much For Help

@Kajol-Kumari  Label ??


Option to use vim.notify instead of the built-in system

Is your feature request related to a problem? Please describe.
Currently, neogit uses its own custom notification system. It's a bit jarring when happening alongside other notifications from other sources that get displayed very differently. It's also not really customizable.
Describe the solution you'd like
Use the standard vim.notify() interface so that the user can use the notification engine they prefer. At least offering this as an option would go a long way.

You can use disable_builtin_notifications = true to disable those builtin notifications. But I do feel like that functionality could be removed. It was added before vim.notify() was a thing (from what I remember) and since it would be breaking change it could be bundled with the rest of upcoming breaking changes. :)

Not opposed to removing it - low priority to me, but PRs are always welcome :)

Yes. I would also be ok with removing it.
I'll close this issue for now as using vim.notify is currently possible


fix(plugin-vue): enable ts in template when using tsx in dev mode

Description
TS is not supported in template when lang is tsx in dev mode. It is supported in prod mode.
transformWithEsbuild should be called when lang is tsx
Additional context

What is the purpose of this pull request?

[x] Bug fix
[ ] New Feature
[ ] Documentation update
[ ] Other

Before submitting the PR, please make sure you do the following

[x] Read the Contributing Guidelines.
[x] Read the Pull Request Guidelines and follow the Commit Convention.
[x] Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
[x] Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
[ ] Ideally, include relevant tests that fail without this PR but pass with it.

Isn't it already supported by plugin-vue-jsx?

Isn't it already supported by plugin-vue-jsx? plugin-vue only supports .vue files.

It's not about plugin-vue-jsx。
For example
<template>
  {{ a as any }}
</template>
<script lang="tsx" setup>
const a = 1
</script>

In dev mode,  browser will throw a error,  because it was compiled to
function _sfc_render(_ctx, _cache, $props, $setup, $data, $options) {
  return _toDisplayString($setup.a as any)
}

TS grammar is not converted.
If lang=ts,  it was compiled to
function _sfc_render(_ctx, _cache, $props, $setup, $data, $options) {
  return _toDisplayString($setup.a);
}

TS grammar is converted.
The key code is
https://github.com/vitejs/vite/blob/43b7b78b1834a4c7128d8a5d987f66a4defcbd93/packages/plugin-vue/src/main.ts#L214-L233
It lacks tsx's judgment

Can you please review this PR，there is still no reviewer @antfu

@patak-dev
Vue SFC Playground only support lang="ts"，but when you use vite,  you can use @vite/plugin-vue-jsx to support tsx.
And the @vite/plugin-vue has some code to support it, such as https://github.com/vitejs/vite/blob/c4489ea193f4d2f703882cb03490980aa5174040/packages/plugin-vue/src/template.ts#L157-L163
@vite/plugin-vue-jsx tranform jsx syntactic，but the template is still handled by @vite/plugin-vue. And as I said above, it lacks tsx's judgment in https://github.com/vitejs/vite/blob/43b7b78b1834a4c7128d8a5d987f66a4defcbd93/packages/plugin-vue/src/main.ts#L214-L233


Initial version of ClickHouse extension for Liquibase

Looks good. For the shading, I think we should provide both (with shadedArtifactAttached).


Out of memory error for parallelised runs for whole of GBR domain

When running 8192 runs for the whole of GBR Domain with 20 cores a ECCONRESET error is triggered at https://github.com/open-AIMS/ADRIA.jl/blob/533d47885607d0f810561322b271429146d16613/src/scenario.jl#L163
Trying the same runs with fewwer cores and an increased connection time (300s) results in an OutofMemory error at the same position (L163).

Just loading up data with a single core can take up to ~6GB of ram when working with whole of GBR datasets.
Doing some back of the envelope calculations, the workstation we have has 128GB of ram but some of that will be taken up by the operating system and background processes. With 20 workers using ~6GB each, 128GB itself is cutting it close: 128 / 6 $\approx$ 21.33, so doesn't leave much headroom to begin with not even considering the fact we don't have the full 128GB.
On top of that I've found several places where memory use could be more efficient.
Will look into what can be done here.

Thanks @ConnectedSystems . So should it be possible to run as is on the HPC or should this be resolved before I try there?


git clone takes long time

if this topic have been already discussed somewhere, so sorry.
when I clone this repo. i take so long time.
the reason is this repo has a large amount of .git file (~2GB)
I just wanted to report you this info
thank you

You're right, the repository clocks in at about 1.83GB (compressed?). It most certainly should not be this large - a much larger repository nltk/nltk is only 110MB, while it has 40 times as many commits. Even the huggingface/transformers repository is only 106MB.
I ran git-sizer on SetFit:
> git-sizer --verbose
Processing blobs: 6401
Processing trees: 3880
Processing commits: 562
Matching commits to trees: 562
Processing annotated tags: 8
Processing references: 68
| Name                         | Value     | Level of concern               |
| ---------------------------- | --------- | ------------------------------ |
| Overall repository size      |           |                                |
| * Commits                    |           |                                |
|   * Count                    |   562     |                                |
|   * Total size               |   288 KiB |                                |
| * Trees                      |           |                                |
|   * Count                    |  3.88 k   |                                |
|   * Total size               |   813 KiB |                                |
|   * Total tree entries       |  20.5 k   |                                |
| * Blobs                      |           |                                |
|   * Count                    |  6.40 k   |                                |
|   * Total size               |  2.26 GiB |                                |
| * Annotated tags             |           |                                |
|   * Count                    |     8     |                                |
| * References                 |           |                                |
|   * Count                    |    68     |                                |
|     * Branches               |    25     |                                |
|     * Tags                   |     8     |                                |
|     * Remote-tracking refs   |    34     |                                |
|     * Git stash              |     1     |                                |
|                              |           |                                |
| Biggest objects              |           |                                |
| * Commits                    |           |                                |
|   * Maximum size         [1] |  2.63 KiB |                                |
|   * Maximum parents      [2] |     3     |                                |
| * Trees                      |           |                                |
|   * Maximum entries      [3] |   100     |                                |
| * Blobs                      |           |                                |
|   * Maximum size         [4] |  12.4 MiB | *                              |
|                              |           |                                |
| History structure            |           |                                |
| * Maximum history depth      |   267     |                                |
| * Maximum tag depth      [5] |     1     |                                |
|                              |           |                                |
| Biggest checkouts            |           |                                |
| * Number of directories  [6] |  1.78 k   |                                |
| * Maximum path depth     [7] |    10     | *                              |
| * Maximum path length    [6] |   142 B   | *                              |
| * Number of files        [6] |  4.47 k   |                                |
| * Total size of files    [8] |  2.90 GiB | ***                            |
| * Number of symlinks         |     0     |                                |
| * Number of submodules   [9] |     1     |                                |

[1]  43dbaf1a914a08ff8ef8ec836ddd51586d7881bb
[2]  bf45d6ba83c2810cf9f98fa4b75ecf10a74f103f (refs/stash)
[3]  509d9665e9fcd57ae9076de8538c1d2a97300312 (ab1dfea0f6c2f05dfdfd60ece755da8a6c488453:scripts/tfew/results/t011b_pretrained_ag_news)
[4]  d208ea649f272df23223ca53d60b4a0f2cc0514e (refs/heads/refactor_v2:final_results/tfew/t011b_pretrained-v2.tar.gz)
[5]  016b9505b528f6641cf43e4fbe41dff2d1c92edf (refs/tags/v0.0.1)
[6]  5a27edfe11d843b1ccb70865a6ef44f5b8188a0d (bb856cb42d3954362cd452b7bf930159e7318a74^{tree})
[7]  e9210bdc0d15cf5dcb3ea401222931cee7bf89d3 (e7366a37ff8e225dd3d5a779589f3594164dbe6f^{tree})
[8]  5f77f0b95db1f1d9063ac1c090e4c94c6205c4c5 (e5e7ef46e88f17fe439175b5292ad8b661cef4b5^{tree})
[9]  3ece7af03ca6ef52e83f40a66a9ebd8bd037c284 (refs/heads/refactor_v2:scripts/tfew)

As is clear from these results, the Total size of files is the culprit. It points to e5e7ef46e88f17fe439175b5292ad8b661cef4b5 in particular, which is indeed a carelessly big commit. There seem to be several commits that are simply way too large:

e5e7ef46e88f17fe439175b5292ad8b661cef4b5
d3341e277c822772cc066937c3c0ba70325a8c24
1c92763a74b2a9c0f5d55e9acdb71152e96e6265

I suspect that these few commits have increased the size requirement of this repository by ~2.5GB for anyone who wishes to clone it.
These files are later removed in e.g.

b52fc63423df27d3ff6b54ec39eda73137de1002
9c3b1c84f8ef2ad6c9a362e81d993ec41a0efc06

But the damage has already been done.
To the best of my knowledge, this can be resolved in several ways, for example with git filter-branch or git rebase, but both methods involves rewriting the entire git tree (or at least, the last 200+ commits). I could do it, but I'm concerned that it will mess up the existing pull requests and everyone's local repository, because everyone will still have the outdated git tree.
With other words, I won't try and fix it today due to the potential hastle, but I'd like to hear what @lewtun thinks rather than already closing this as "wont fix".
Thanks for reporting!

Tom Aarsen

Yes indeed, that was a commit that should never have been pushed 😬
I'm taking a look to see if we can solve this without breaking everyone's local copies / PRs. If there's no solution, I think the choices are:

Review + merge / reject all open PRs, do the rebase and live with some annoyance on the user side
Treat this as "wontfix" and live with the large repo size.

Given the nature of this project (most people are users rather than contributors), I think option (1) might be doable but let's see if there's a less drastic solution

We can try for option 1 after one of the big upcoming releases.


6.2 LTS concatenateCss description must be extended

Depending on the concatenateCss documenation of 6.2LTS I thought it would be possible to concatenate all my css files depending on its media attribute, but later I found this issue: https://forge.typo3.org/issues/33137, which said that only media type all and none are really concatenated and nothing more. The fix of it was in TYPO3 7.x . So the description of the 6.2LTS concatenateCss must define that only media type all and css files without media attribute are concatenated.

The place here is about the development of the THEME that we're now using to render TYPO3 documentation. The issue you're mentioning is about the TYPO3 documentation. Probably you're talking of https://docs.typo3.org/typo3cms/TyposcriptReference/6.2/Setup/Config/Index.html#concatenatecss !?
Can you provide a sentence as a proposal there ("Edit me on Github") or in the issue tracker? https://github.com/TYPO3-Documentation/TYPO3CMS-Reference-Typoscript/issues
Thank you.


Fixed the hover-effect bug in dark-mode under navbar section

I encountered a bug that whenever we toggle dark mode and then hover our mouse on navbar then its list items get disappear. This happened because earlier I didn't updated the hover effect css  for the same in dark mode.
Now I have updated it and now it's working fine.
Here is a screenshot of the bug which is now resolved :
You can see how opportunities section got disappear when we hover on it, this was due to its color was set to black when we hover on it, now I have changed it to white whenever we hover on it.

@DeveloperAshish8 you can merge this pull request successfully ! It will fix the bug.

Sorry @Aman-0604 already done this.


Loading/Error handling for Authenticated landing page

Closes #121
Closes #157
Closes #158
Closes #159
Changes

Enables "full content loading"

Provide /loading route for easy examination of Loading state
Addresses flexbox page-width issues on Privacy Act, etc
Creates LoadingContent (to be used by subpages) and LoadingPage (for use with React.Suspense) components
Refactors generation of Header authentication links into a custom hook (useHeaderAuthLinks) to avoid flashing during loading
Does not display Header Auth links until Auth is fully loaded to avoid flickering
Displays Loading... text and the associated icon in an H1

Implements Loading for the Authenticated Landing page

Refactors data fetching in AuthenticatedLanding to live at the top level, so that we can show the whole page as loading while we wait for details to download
Replaces all loading instances of <LoadingOrError> with <LoadingContent />

Implements Loading and Error handling for the View User Profile and View Institution Profile pages

Replaces all loading instances of <LoadingOrError> with <LoadingContent />
Redirects to /500 for data fetching errors

Updates error handling, where it already exists, to use the /500 route

Provides a useError500 hook to encapsulate error routing logic
Replaces all error instances of <LoadingOrError> with useError500
Route users to /500 when a server/fetch error occurs

Display field

Render Not available for any field that does not have a value to display

How to test this PR

Loading: Open http://localhost:8899/loading
Error - Unable to fetch: Set ReviewInstitutions.tsx line 23 to true
Warning - No associated institutions: Set ReviewInstitutions.tsx line 32 to false

Screenshots
Institution states
All Good

Warning - No associated institutions

Error - Unable to fetch

Financial profile
Not available for any field without a value

Full content loading

TODO

[x] Verify with team that top-level fetching is the approach we want to follow
[x] Figure out what to do about "unknown" type for useQuery's TError

Via test I've determined that TError.message will provide some text content but ultimately, based on the presence of the error and the context, we'll have to provide our own messaging.

[x] Verify with Design team that the Alert's used to show "No institutions" and "Fetch error" look good

Question about "No associated institutions" scenario:

Is this even technically possible?
Could a user remove all of their associated institutions?
Could our Support team accidentally remove all of a user's associated institutions?

@dan-padgett @angelcardoz
If @meissadia confirms that these warnings or errors are possible we will have to decide how to handle the language in the text block above this field-level alert, the language in the alert, and also identify and present the next step a user should take.
The current language is contradictory:

Your user profile has been successfully associated with the following financial institutions...
You have no associated institutions

I really appreciate this discussion @natalia-fitzgerald and @meissadia! I think we might need to clarify a bit about what problems are possible and the issues with trying to guess what errors we should convey to the user.

When @meissadia, @shindigira, and I were first brainstorming the different error states that were possible due to API calls failing in various ways, it was great to think about "if an institution came back from getAssociatedInstitutions with an LEI but not a name, could we still render this link to their View Financial Institution Details page on their Authenticated Landing page?" I think that error brainstorming was very helpful, but as this PR discussion is surfacing, from a user and design perspective it might be good to take a step back.
If an institution comes in from a successful GET from the getAssociatedInstitutions endpoint and the institution has a LEI but not a name, could we render that link to their View Financial Institution Details page? Totally. But since someone with an LEI in GLIEF must register with a name also, then not having a name come back from that endpoint speaks to a server error or an error in how we're interacting with the backend. To a user who has an LEI but no name associated with their institution, they should probably just see a "Error loading institution details; please contact SBL Help" with a link to SBL Help's salesforce form.
Similarly and speaking to @meissadia's point about "Is this even technically possible.", if a user gets to the authenticated landing page and doesn't have any associated institutions coming back from getAssociatedInstitutions that means that somehow their institutions array on Get Me is populated which is a requirement to get to this page, but that data is not being returned in getAssociatedInstitutions . That's another server error or error with how we're communicating with the backend so probably the user should just see: "Error loading institution details; please contact SBL Help".
I chatted a bit with @natalia-fitzgerald about this, but this speaks to a general pattern I'd like to adopt for these components that depend on API calls to render. Let's generalize all errors coming from this component into one message, preferably in a red alert error box that draws the user's attention with: "Error loading institution details; please contact SBL Help" with a link to SBL Help.
One way we could do this technically for all use cases, would be to put the dependent API call getAssociatedInstitutions into the component itself, and then wrap the component in a react Error Boundary that renders the red alert error box if it catches an error. Then if any errors occur inside the component, they get caught and people see the generalized error message. If later in testing we find that we want to be more specific with error text, then after MVP we could adjust the Error Boundary to render different messages as necessary.
Seems like a pretty good pattern that's repeatable across components? Let me know what you think y'all, and thanks for the discussion! 👍

TL;DR:

I think some non-critical components that depend on API calls to meaningfully render should be wrapped in Error Boundaries. These Error Boundaries should display fairly generic error text in red alert error boxes that direct users to SBL Help.
Errors that happen on the page level or unexpected errors go to 500 pages.
For later when we're working in the filing app: individual form pages in the filing app should use zod to verify form content before continuing onto the next page on the frontend. The backend should also send back errors if the form content contains errors as we submit each page of the draft filing to the backend to be saved.

@billhimmelsbach
Thanks for your notes. I went ahead and mocked this up for the authenticated landing page and the View your user profile page. I tried out two positioning locations - top of the page versus specific page location where the data didn't load.
Top of the content area

Authenticated landing page
View your user profile

Specific page location

Authenticated landing page
View your user profile

If we want to provide further details we can include body copy in the alert.

@meissadia Is this one good to go?

@meissadia @natalia-fitzgerald The latest is currently on the dev environment to aid review. 👍

Discussed with team and we will work on developing the error states in a separate ticket.  For now, we want to get the Loading states integrated.

Development of Error state handling moved to [Design] Error states for failed API calls


orm_mode = True for v1.9.0a1 (2021-12-18) is causing 422

Checks

[ x] I added a descriptive title to this issue
[ x] I have searched (google, github) for similar issues and couldn't find anything
[ x] I have read and followed the docs and still think this is a bug

Bug
When remove orm_mode = True I can POST data.
With orm_mode = True in place i get 422
from uuid import UUID

from pydantic import BaseModel, Field

class StuffSchema(BaseModel):
    name: str = Field(
        title="",
        description="",
    )
    description: str = Field(
        title="",
        description="",
    )

    class Config:
        orm_mode = True
        schema_extra = {
            "example": {
                "name": "Name for Some Stuff",
                "description": "Some Stuff Description",
            }
        }

class Stuff(Base):
    __tablename__ = "stuff"
    id = Column(UUID(as_uuid=True), unique=True, default=uuid.uuid4, autoincrement=True)
    name = Column(String, nullable=False, primary_key=True, unique=True)
    description = Column(String, nullable=False)

    def __init__(self, name: str, description: str):
        self.name = name
        self.description = description

router = APIRouter(prefix="/v1/stuff")

@router.post("", status_code=status.HTTP_201_CREATED, response_model=StuffResponse)
async def create_stuff(payload: StuffSchema, db_session: AsyncSession = Depends(get_db)):
    stuff = Stuff(**payload.dict())
    await stuff.save(db_session)
    return stuff

Thanks for highlighting this. Can you help make your test-case a bit more minimal? For example, maybe remove the database / HTTP server?
I’d love to be able to reproduce this with just Pydantic and some example JSON.

@christianbundy please find below minimal set where I was able reproduce. I'm not sure for 100% if this exists only in context of HTTP server. In this case FastAPI / Starlette
from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class StuffSchema(BaseModel):
    name: str
    description: str

    class Config:
        orm_mode = True
        schema_extra = {
            "example": {
                "name": "Name for Some Stuff",
                "description": "Some Stuff Description",
            }
        }

@app.post("/", response_model=StuffSchema)
async def create_stuff(payload: StuffSchema):
    return payload

if __name__ == '__main__':
    uvicorn.run(app='http_orm:app')

and my Pipfile
[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"

[packages]
pydantic = "~=1.9.0a1"
fastapi = "==0.70.1"
uvicorn = "==0.16.0"

[dev-packages]

[requires]
python_version = "3.10"

with this I can get below 422 error message
{
  "detail": [
    {
      "loc": [
        "body",
        "name"
      ],
      "msg": "field required",
      "type": "value_error.missing"
    },
    {
      "loc": [
        "body",
        "description"
      ],
      "msg": "field required",
      "type": "value_error.missing"
    }
  ]
}

next when comment orm_mode = True I can get expected response.
Thx

What payload are you sending? Here's a minimal test-case:
import json
from pydantic import BaseModel

def test_my_bug():
    class StuffSchema(BaseModel):
        name: str
        description: str

        class Config:
            orm_mode = True
            schema_extra = {
                "example": {
                    "name": "Name for Some Stuff",
                    "description": "Some Stuff Description",
                }
            }

    my_json = json.dumps({"name": "Pydantic", "description": "Cool"})

    StuffSchema.parse_raw(my_json)

When I run pytest on this file, it doesn't raise a ValidationError. Could you edit my_json to reproduce the problem you're seeing?

@christianbundy looks it giving me 422 only in context of HTTP server. Should I raise is with fastapi ? I sending exactly what I have in Config example

Best to move this to fastapi.

looks already fixed with https://github.com/samuelcolvin/pydantic/commit/93faefb4a9c711d3fcaaa916fc60163d125a5a8c
so no need to rise with fastapi ;)


Symbol ">" on the right side of the list item is not centered vertically

This is a (multiple allowed):

[x] bug

[x] enhancement

[ ] feature-discussion (RFC)

Framework7 Version: 1.5.3

Platform and Target: iOS and Android

I think that the correct position of the symbol ">" on the right side of the list item is centered vertically.
I tried to edit the files "framework7.ios.css" and "framework7.material.css"in this way:

delete
background: none;
from block
.list-block.media-list .item-link .item-inner, .list-block li.media-item .item-link .item-inner

delete items
background
background-image
background-size
from block
.list-block.media-list .item-link .item-title-row, .list-block li.media-item .item-link .item-title-row

In this way the result is surely better.
BEFORE:

AFTER:

Are you sure? I think the upper ("before") version corresponds to the official Apple UI guidelines. Does someone have a screenshot of an official Apple app that uses lists like this?

The HIG is a tad unconclusive

Yes, it is inconclusive. But even here it
http://stackoverflow.com/questions/31368335/tableviewcell-disclosure-indicator-position
it is reported that the default position in Xcode is:

I have a custom tableviewcell with the standard disclosure indicator positioned in the centre vertically by default. How can I move this standard disclosure indicator vertically like in the iOS mail app?

I did it near the "title" line because it was what we can see in few native iOS apps (like Mail). Also it has some real advantage, because moving it bottom (center) will "eat" additional 20px width from "item-subtitle" and "item-text" elements, and space is what is really expensive on small screens. So i won't change it to center by default. If you need it, just add few custom CSS rules to achieve it, what you already did.


Fix 'Do not leave a blank line after "private:"' issue in mainwindow.h

CodeFactor found an issue: Do not leave a blank line after "private:"
It's currently on:
mainwindow.h:53

https://github.com/Paracetamol56/Observeur2/pull/9


[qmf-notifications-plugin] Avoid playing multiple email tones. JB#62613

The feedbacks are messed up with email vs email_exists, latter having sounds set etc.
Those should be cleaned up, but for quick fix for avoiding multiple email tones played at the same time we could just ensure the feedback is set once per set. Even if the feedback declarations would be more sane, we might not want tones played for each separate email in case there are some 50 of them.
@dcaliste maybe something like this for small fix, ref: https://github.com/sailfishos/qmf-notifications-plugin/pull/2

I'm still wondering why my proposition to play the notification only for the summary and not for each emails is not enough ?

The other PR is removing the "email" feedback altogether when it should still contain the vibra feedback part. And then the "email_exists" is having led which shouldn't be stopped when a transient notification popup disappears from the screen and removes its feedback items, so in its current form that shouldn't be used in the summary.
Would be nice to clean up the feedback items to be saner, but thought this could be the minimal changes now which wouldn't risk in making it even more broken.
One comment to myself on the PR though:

Sure there's some redundancy if we assume what the feedbacks do, but then again "exists" should be there as long as some of the email notifications exist, right? Thus it would need to be set for all.

No, we don't want to have vibra or sound for each item and the leds turn on/off regardless of how many items have it. The email plugin should be in some control in how many sounds it wants to be played, being 1, 2 or even 50. The notification list handling is quite a natural place to handle that.

The other PR is removing the "email" feedback altogether when it should still contain the vibra feedback part. And then the "email_exists" is having led which shouldn't be stopped when a transient notification popup disappears from the screen and removes its feedback items, so in its current form that shouldn't be used in the summary.

Thanks for the reminder. I forgot about these reasons that required changes in the ngfd ini files. I agree that's a good reason not to change it locally like that but would be deserve a global overview.
So far your solution will fix the issue with minimal risk of breaking something else.


Support for floating point textures

Use case
This is an extension to #136025.
Fragment shaders sometimes need lookup tables, for example for color transformations. These tables usually use floating point, since that's the natural way math works on GPUs. GLSL handles this transparently, and APIs like OpenGL have support for this via floating point textures (GL_RGBA32F, GL_R32F, etc).
Proposal
If Flutter adds support for sync texture construction, this should also allow supplying a floating point texture to enable these kinds of operations in fragment shaders.

As far as I know SkSL does not support this so we cannot add support (yet).


Retry Refactoring | Expr.let

Code Coverage Summary [using JaCoCo]

Coverage Type
Coverage

Coverage:
15.80%

Branches:
21.74%


fix: update typings

this gives us typescript optional param support

:tada: This PR is included in version 1.9.5 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


connectivity: Make detected Cilium Agent version available for feature detection

Make detected Cilium Agent version available for feature detection and use it instead of trying to detect Cilium version from the agent image reference. This helps avoid failures like this when the image tag is not a semantic version (in this case image tag is "test"):
  connectivity test failed: unable to determine if KNP feature is enabled: failed to parse Cilium version test to semver

Cilium agent version was already detected, this PR moves the detection a bit earlier to make it available for feature detection.
Fixes: #1470

@sayboras This is why the tests fail to run on cilium/proxy now, see https://github.com/cilium/proxy/actions/runs/4683593671/jobs/8298837689?pr=142 for an example.


Gms feature

I think gms feature is usefull but why when i google play service has disable by gms feature i cant open appopps too,

I don't think you should apply appops to disabled apps.


CRIMAP-379 Simplified prometheus exporter approach

Description of change
As we are not running Puma in multi process mode (instead we can scale horizontally with more threads and pods), there is a simplified approach to prometheus exporter.
In this version, we don't need a separate process running in a separate pod (meaning no need for having another deployment manifest, or deal with hosts to connect client to server etc.)
The prometheus exporter server instead runs in each pod, in the rails application itself. This have the advantage, we can add custom metrics more easily as we have access the the full rails environment (models, activerecord, etc.) whereas if running the process separately, we don't have it, or we have to load it defeating the purpose.
Added active record and puma instrumentation. That's why the configuration lines have increased.
We can see how this approach works and if we consider it is easier, once we implement some custom metrics (next PR). It is relatively easy to change to previous approach.
Link to relevant ticket
https://dsdmoj.atlassian.net/browse/CRIMAP-414
Notes for reviewer
How to manually test the feature
Can also be tested easily on local, by running docker-compose up and checking the /metrics endpoint (in port 9394) or by setting the local env variable ENABLE_PROMETHEUS_EXPORTER to true.
If you want some verbose output in the console, set PROMETHEUS_EXPORTER_VERBOSE to true.

I remember we used this approach in a previous team - good plan. Worked well for us


Implement tracer logic

The UserOperation simulation needs Geth debug_traceCall js tracer to collect custom evm operations.
And we need to implement this tracer logic for the simulations.
Here are some other implementations for reference:

https://github.com/eth-infinitism/bundler/blob/f5af738e7f95f53b8954d98e777b2c76c6ea9b1f/packages/bundler/src/GethTracer.ts#L18-L37
https://github.com/stackup-wallet/stackup-bundler/blob/main/pkg/tracer/types.go#L48-L54

Goal

implement Rust serde types for custom json output (Done in https://github.com/Vid201/aa-bundler/blob/feat/uopool/src/contracts/tracer.rs)
implement TracerTest.js

Blocked by https://github.com/gakonst/ethers-rs/pull/2088 or https://github.com/gakonst/ethers-rs/pull/2064

The first goal is done in https://github.com/Vid201/aa-bundler/blob/feat/uopool/src/contracts/tracer.rs


RFC: New wormhole API

What happened?
Recently I lost quite a few hours debugging an issue in a thunk that looked more or less like:
const fetchData = (id) => (dispatch, getState, api) => {
  if (Object.keys(getState()).length === 0) {
    api.get(id).then((data) => dispatch({ type: 'FETCHED_DATA', data })
  }
}

Essentially, the idea here was to only fetch the data only if the state didn't already have any keys.
The reducer looked something like:
const reducer = (state = {}, action) => {
  if (action.type === 'FETCHED_DATA') {
    return { ...state, ...action.data }
  }

  return state
}

This worked fine when developing and testing the component, but would never attempt to fetch the data once it was integrated into a parent component.
Eventually I tracked it back to the use of wormholes in the root application.  The wormholes added additional keys to the state, so when checking the length of the keys, it was never empty.
What should have happened?
In the above scenario, I would have preferred if the state was unchanged, particularly as this component did not care about any of the wormholed values.  That way, the component would not need to be modified to work within the root app.
Any Ideas?
The issue I see here is the way wormholes get globally applied to all subspaces.  This can lead to difficult to find bugs in child components that had no control over what the wormholes, if any, are being applied to their state.  The scenario above is an example of this.
I propose changing the wormhole API to be an opt in addition to the components state.  In the new API, components would nominate which wormholes, if any, they want to receive, and if no wormholes are nominated the components state is unchanged.
I'm thinking that this could work similarly to React's Context feature where higher in the tree, a component can add values into context, and descendants of the components can opt into received one or more of those values.  There is also potential here to improve the developer experience here by providing dev time warnings if the requested wormhole values are not provided by the parent.
Translating this concept to subspaces, the wormhole middleware would be the point higher in the tree to add the values.  Currently, multiple wormholes are added a seperate calls to the wormhole middleware.  In this proposal the api will change to an object of key to wormhole selector, i.e.:
const store = createStore(reducer, applyMiddleware(
  wormhole((state) => state.value1, 'key1'),
  wormhole((state) => state.value2, 'key2'),
  wormhole((state) => state.value3, 'key3')
))

would become:
const store = createStore(reducer, applyMiddleware(
  wormholes({
    key1: wormhole((state) => state.value1),
    key2: wormhole((state) => state.value2),
    key3: wormhole((state) => state.value3)
  })
))

This is arguably a nicer API than the existing one if there are lots of wormholes, but it does remove the ability to use the selector shorthand that has been adopted in many of the subspace feature (i.e. wormhole((state) => state.value, 'value') can be shortened to just wormhole('value')).  I'd like to investigate ways to maintain backwards compatibility with the existing API on this end, but my feeling is that it won't be possible if we want to provide warnings when requested keys are missing.
On the sub-component side placeholder values would be added to it's state to select the values the component wants to be included from the wormholes.
This could be done as a higher-order reducer:
const reducer = combineReducers({ reducer1, reducer2)
const enhancedReducer = withWormholes('key1', 'key3')(reducer)

or as a reducer to combine with others:
const reducer = combineReducers({
  reducer1,
  reducer2,
  wormholes: wormholesReducer('key1', 'key3')
)

There are advantages and disadvantages to both approaches, so I would be keen to hear how you would prefer to use it.
When it comes to using the subspaces, the wormhole middleware would inspect the state of the subspace and replace any of the placeholder values with the actual values from the wormhole selectors (and warn about any that can't be found).  There is also potential here to add shape validation (e.g. prop-types) to the wormholed values to ensure the parent is providing them in a usable format for the child, again improving the developer experience.
Pros

Declarative
Component state is closer to runtime expectations
Better developer experience

Cons

Inspecting the state in the dev tools would display the placeholder values in their raw format
It is (probably) not backwards compatible with the current implementation

One of the biggest differences I see in philosophy between the current implementation and explicit nature of this proposal is that currently, the components don't have to care where the extra values in their state come from.  They can be from wormholes, added when mapping the component state in a SubspaceProvider or any other kind of magic you can pull off the get the values there when getState is called, but with the new approach, they can only come from a wormhole.  There is a whole series of questions this philosophical change brings in, but I don't have time to go into those now.  Perhaps I'll add a following post to ask those soon.
Anyway, how does all this sound?  Let me know what you think, ask any questions you want, suggest changes to the proposal, or propose your own changes.

There is a whole series of questions this philosophical change brings in, but I don't have time to go into those now. Perhaps I'll add a following post to ask those soon.

As promised...
There are currently two main ways to add global state to a child subspace:

Mapping additional state from the rootState parameter when creating the subspace
<SubspaceProvider mapState={(state, rootState) => ({
  globalValue: rootState.globalValue,
  ...state.childState
})}>
  <ChildComponent />
</SubspaceProvider

Using wormholes
const store = createStore(reducer, applyMiddleware(
  wormhole((state) => state.globalValue, 'globalValue')
))

The main difference between the two is that wormholes are applied to all subspaces, but mapState method only applies to the subspace being created.  The other important thing to note is that wormholes were only introduced in version 2, with the mapState method being the only option prior to that.
The biggest issue with the mapState method is that if you have a truely global piece of state, e.g. an auth token, then the mapping should be done at all levels, for every subspace, which can be quite repetitive and easy to forget in intermediate subspaces that don't require the global value themselves.
This whole proposal is about fixing one of the biggest issues with wormholes (forcing the global values values into the component's state whether they want them or not), but there is another as well.
The other issue with wormholes is that currently they can only be created when the store is created in the root application.  This means that any wormholes must be known up front and can't change (although there is no penalty for having a wormhole to an undefined value until it is available).
If redux-subspace was being created from scratch today, I do not believe the mapState method would be a thing.  By this I mean that the rootState parameter would not be supplied to the mapState function.
So here are my questions

How would you all feel about removing the rootState parameter from mapState?
If it wasn't removed, should it also be opt in?
If it is opt in, should it be seperate from the wormhole reducer (withWormholes or wormholesReducer from the previous post) or should they become more generic (e.g. withExternal or externalReducer)

For me, it would alleviate one of my biggest concerns with this proposal which is that having the wormhole specific placeholders in the component's state feels a bit weird if there are other legitimate ways to inject additional state.  If the only supported way was to use wormholes, then this feels better to me.
The only other bit of functionality I would want before being comfortable in removing rootState is the ability to add additional wormholes at arbitrary points in the hierarchy, where they would only apply to subspaces created from that point and below.  The easiest way I can think of to achieve this is to expose an enhancer parameter when creating a subspace to compose with the other enhancers used to create the subspace, then use the existing applySubspaceMiddleware enhancer to add additional wormholes.  This new parameter would need to be exposed through all the packages that create subspaces as well.
<SubspaceProvider
  mapState={(state) => state.childState)}
  enhancer={applySubspaceMiddleware(wormhole((state) => state.someValue, 'someValue'))}
>
  <ChildComponent />
</SubspaceProvider

Some care would need to be taken with the new parameter to ensure it is passed down for subsequent subspaces to use as well, and to ensure it doesn't override anything in the subspaceOptions and accidentally leak back up the tree, but all that is just implementation details.
This approach means the only time new wormholes can be created is when a subspace is created.  This may lead to situations where an unnecessary subspace layer is introduced purely to create a wormhole, e.g.
<SubspaceProvider
  mapState={(state) => state) /* note: no state change or namspacing applied */}
  enhancer={applySubspaceMiddleware(wormhole((state) => state.someValue, 'someValue'))}
>

    { /* ... /* }
      <SubspaceProvider mapState={(state) => state.childState}>
        <ChildComponent />
      </SubspaceProvider
    { /* ... /* }

</SubspaceProvider

Alternatively, we could provide an new mechanism for expanding the enhancer used when creating subspaces.  Really, all we really need to do is change the store that is used to create the subspace which is relatively easy in the React use case, but not so straight forward in other use cases (e.g. sagas).
const newStore = enhanceSubspace(applySubspaceMiddleware(
  wormhole((state) => state.someValue, 'someValue')
))(store)

<SubspaceEnhancer
  enhancer={applySubspaceMiddleware(wormhole((state) => state.someValue, 'someValue'))}
>

    { /* ... /* }
      <SubspaceProvider mapState={(state) => state.childState}>
        <ChildComponent />
      </SubspaceProvider
    { /* ... /* }

</EnhanceSubspace

More questions:
4. Which of these two approaches do you prefer?
5. Can you think of a better API for adding new wormholes?
This is all I can think of for now, but I'll post more if it comes to mind.

Closing due to inactivity.  Happy to repoen if there is more discussion to be had.