 This makes the circuit easier for a routing pass to work with.
Details and comments
TODO:

[ ] Add more testing
[ ] Add final layout tracking and composition with routing.

The main question that I have (and this is more general than this PR) is that (if I understand correctly) this star-to-line pass will run before routing, with the intuition that for sparsely connected architectures we will find better layout + routing when the circuit consists of linear pieces rather than star pieces. If the circuit consists of a single star and the coupling graph contains a line of the right size, then VF2 will even find a perfect layout and no routing would be needed. However if there are two or more stars (or there are more 2-qubit gates), then even if the first star is mapped perfectly, Sabre might need to do many swaps before the second star, and it's not clear that the line connectivity of the second star will help. What do you think?

I was thinking we would run this before the layout stage as part of init stage. In my local full path testing I was using the pre_layout stage but if we were to add it to the preset pass managers I'd use init. I called it prerouting but in my head I was thinking like you and we'd definitely want to do this before VF2Layout in case vf2 can find a line in the connectivity graph. Prerouting to me at the time I wrote this was a initial lighter routing pass, not intended to be right before the routing stage (like what was done in sabre pre-layout), but yeah it's a poor name choice as it's meaning is ambiguous and overloaded.

There might be some problems with treating single-qubit gates. For example, the following circuit
     ┌───┐     ┌───┐     ┌───┐     ┌───┐
q_0: ┤ H ├──■──┤ H ├──■──┤ H ├──■──┤ H ├──■──
     └───┘┌─┴─┐└───┘  │  └───┘  │  └───┘  │
q_1: ─────┤ X ├───────┼─────────┼─────────┼──
          └───┘     ┌─┴─┐       │         │
q_2: ───────────────┤ X ├───────┼─────────┼──
                    └───┘     ┌─┴─┐       │
q_3: ─────────────────────────┤ X ├───────┼──
                              └───┘     ┌─┴─┐
q_4: ───────────────────────────────────┤ X ├
                                        └───┘
q_5: ────────────────────────────────────────

gets transformed into
     ┌───┐             ┌───┐┌───┐┌───┐
q_0: ┤ H ├──■────■───X─┤ H ├┤ H ├┤ H ├───
     └───┘┌─┴─┐  │   │ └───┘└───┘└───┘
q_1: ─────┤ X ├──┼───┼───────────────────
          └───┘┌─┴─┐ │
q_2: ──────────┤ X ├─X───■────X──────────
               └───┘   ┌─┴─┐  │
q_3: ──────────────────┤ X ├──X────■───X─
                       └───┘     ┌─┴─┐ │
q_4: ────────────────────────────┤ X ├─X─
                                 └───┘
q_5: ────────────────────────────────────

Intuitively, this is because the pass only collects sequences of 2-qubit gates while ignoring 1-qubit gates (which is probably fine, since 1-qubit gates pose no problems for routing), but then forgets to take these 1-qubit gates into account.

Another random thought is that star-to-line translation may create gate cancellation opportunities, i.e. we may want to rerun passes like inverse cancellation after star-to-line but before layout or routing.

Another random thought is that star-to-line translation may create gate cancellation opportunities, i.e. we may want to rerun passes like inverse cancellation after star-to-line but before layout or routing.

Yeah, that's a good point. I think when we're adding the pass to the preset pass managers we can determine the best place to add this. I'm wondering if we'll want to have a do while loop for initial optimization like we do for final optimization

Intuitively, this is because the pass only collects sequences of 2-qubit gates while ignoring 1-qubit gates (which is probably fine, since 1-qubit gates pose no problems for routing), but then forgets to take these 1-qubit gates into account (see how all of the Hadamard gates got pushed out to the end of the circuit).

This was a good catch, I've pushed up a fix for this here: https://github.com/Qiskit/qiskit/pull/11387/commits/8cc0587a6aad7e7b1b9bfe92090643e6a517add6

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: mtreinish:x: Sebastian BrandhoferSebastian Brandhofer seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

StarPreRouting works now but depends on #12057 and FinalizeLayouts in #9523 being merged (parts of this pass are adapted from #11614 ). If you have any suggestions/comments - I would love to hear them even before these two items are merged. :-)
Executed on a 6-qubit QFT quantum circuit, StarPreRouting yields the following mapped circuit:
                                                                          ░ ┌───┐                                                  ░ ┌───┐                                     ░ ┌───┐                         ░ ┌───┐          ░       ░
q_4 -> 0 ──────■──────────────────────────────────────────────────────────░─┤ H ├─■────────X───────────────────────────────────────░─┤ H ├─■────────X──────────────────────────░─┤ H ├─■────────X──────────────░─┤ H ├─■────────░───────░─
         ┌───┐ │P(π/2)                                                    ░ └───┘ │P(π/2)  │                                       ░ └───┘ │P(π/2)  │                          ░ └───┘ │P(π/2)  │              ░ └───┘ │P(π/2)  ░ ┌───┐ ░
q_5 -> 1 ┤ H ├─■────────■────────X────────────────────────────────────────░───────■────────X──■────────X───────────────────────────░───────■────────X──■────────X──────────────░───────■────────X──■────────X──░───────■────────░─┤ H ├─░─
         └───┘          │P(π/4)  │                                        ░                   │P(π/4)  │                           ░                   │P(π/4)  │              ░                   │P(π/4)  │  ░                ░ └───┘ ░
q_3 -> 2 ───────────────■────────X──■────────X────────────────────────────░───────────────────■────────X──■────────X───────────────░───────────────────■────────X──■────────X──░───────────────────■────────X──░────────────────░───────░─
                                    │P(π/8)  │                            ░                               │P(π/8)  │               ░                               │P(π/8)  │  ░                               ░                ░       ░
q_2 -> 3 ───────────────────────────■────────X──■─────────X───────────────░───────────────────────────────■────────X──■─────────X──░───────────────────────────────■────────X──░───────────────────────────────░────────────────░───────░─
                                                │P(π/16)  │               ░                                           │P(π/16)  │  ░                                           ░                               ░                ░       ░
q_1 -> 4 ───────────────────────────────────────■─────────X──■─────────X──░───────────────────────────────────────────■─────────X──░───────────────────────────────────────────░───────────────────────────────░────────────────░───────░─
                                                             │P(π/32)  │  ░                                                        ░                                           ░                               ░                ░       ░
q_0 -> 5 ────────────────────────────────────────────────────■─────────X──░────────────────────────────────────────────────────────░───────────────────────────────────────────░───────────────────────────────░────────────────░───────░─
                                                                          ░                                                        ░                                           ░                               ░                ░       ░

whereas SabreLayout yields:
                                                                    ░ ┌───┐                                               ░                                     ░ ┌───┐                         ░                   ░       ░
q_2 -> 0 ──────────────────X────────────────────────────────────────░─┤ H ├─X───────────■─────────────────────────────────░───────■─────────────────────────────░─┤ H ├─X───────────────────────░───────────────────░───────░─
                           │                                        ░ └───┘ │           │P(π/4)                           ░ ┌───┐ │P(π/2)                       ░ └───┘ │                       ░                   ░ ┌───┐ ░
q_4 -> 1 ──────■───────────X─────■──────────────────────────────────░───────X──■────────■────────X────────────────────────░─┤ H ├─■────────■───────────■────────░───────X──X───────────■────────░──────────■────────░─┤ H ├─░─
         ┌───┐ │P(π/2)           │P(π/8)                            ░          │P(π/2)           │                        ░ └───┘          │P(π/4)     │P(π/8)  ░          │           │P(π/4)  ░          │P(π/2)  ░ └───┘ ░
q_5 -> 2 ┤ H ├─■────────■────────■────────X─────────────────────────░──────────■─────────────────X──■────────X────────────░────────────────■────────X──■────────░──────────X──■────────■────────░───────X──■────────░───────░─
         └───┘          │P(π/4)           │                         ░                               │P(π/8)  │            ░                         │           ░             │P(π/2)           ░ ┌───┐ │           ░       ░
q_3 -> 3 ───────────────■─────────────────X──■─────────X────────────░───────────────────────────────■────────X──■─────────░───X─────────────────────X───────────░─────────────■─────────────────░─┤ H ├─X───────────░───────░─
                                             │P(π/16)  │            ░                                           │P(π/16)  ░   │                                 ░                               ░ └───┘             ░       ░
q_1 -> 4 ────────────────────────────────────■─────────X──■─────────░───X───────────────────────────────────────■─────────░───X─────────────────────────────────░───────────────────────────────░───────────────────░───────░─
                                                          │P(π/32)  ░   │                                                 ░                                     ░                               ░                   ░       ░
q_0 -> 5 ─────────────────────────────────────────────────■─────────░───X─────────────────────────────────────────────────░─────────────────────────────────────░───────────────────────────────░───────────────────░───────░─
                                                                    ░                                                     ░                                     ░                               ░                   ░       ░

A comparison on a 100-qubit QFT was done by running:
qc = qft(100)
cm = CouplingMap.from_line(100)

pm = generate_preset_pass_manager(optimization_level=3, coupling_map=cm, basis_gates=['rz', 'sx', 'cx'])
pm.pre_layout = PassManager([StarPreRouting()])
pm.post_scheduling = PassManager([FinalizeLayouts()])
start_ts = time()
result_star_prerouting = pm.run(qc)
end_ts = time()
print('star pre-routing done in {}s.'.format(end_ts-start_ts))
print('star pre-routing ops:', result_star_prerouting.count_ops())
print('star pre-routing depth:', result_star_prerouting.depth())

pm = generate_preset_pass_manager(optimization_level=3, coupling_map=cm, basis_gates=['rz', 'sx', 'cx'])
start_ts = time()
result_sabre = pm.run(qc)
end_ts = time()
print('sabre done in {}s.'.format(end_ts-start_ts))
print('sabre ops:', result_sabre.count_ops())
print('sabre depth:', result_sabre.depth())

This yielded the following data when barriers are included between the different 'stars' of a QFT instance:
star pre-routing done in 23.116374969482422s.
star pre-routing ops: OrderedDict([('cx', 14848), ('sx', 28635), ('rz', 26707), ('barrier', 100)])
star pre-routing depth: 39790

sabre done in<PHONE_NUMBER>1941223s.
sabre ops: OrderedDict([('cx', 26635), ('sx', 6362), ('rz', 11522), ('barrier', 100)])
sabre depth: 27714

quite a larger decrease in cx gates! - and without barriers:

star pre-routing done in 23.750023126602173s.
star pre-routing ops: OrderedDict([('cx', 14848), ('sx', 20084), ('rz', 29150)])
star pre-routing depth: 1573

sabre done in 37.29286193847656s.
sabre ops: OrderedDict([('cx', 17510), ('sx', 4064), ('rz', 9848)])
sabre depth: 1764

which yields a 16% decrease in cx gates.
Interestingly, the cp-swap combination of gates apparently gives a (re)synthesis solution with 3 cx gates - intuitively I expected that only 2 cx gates are required given that swapping can be conducted along any axis...

I've moved this out of draft since @sbrandhsn finished this up! But it still has dependencies on open PRs and will need to be rebased so I've marked this as on hold to indicate this.

Thanks @mtreinish and @sbrandhsn for getting this completed, this is definitely going to be a super-useful pass. And thanks @jakelishman for doing this review (somehow I forgot that I was assigned to review this PR). I also looked at the code, and it looks great. In the future, we should probably refactor the star collection part of the pass into the more general block collection (i.e. finalize #11614) and replace the virtual_permutation_layout/FinalizeLayouts by final_permutation.

Thanks @mtreinish and @sbrandhsn for getting this completed, this is definitely going to be a super-useful pass. And thanks @jakelishman for doing this review (somehow I forgot that I was assigned to review this PR). I also looked at the code, and it looks great. In the future, we should probably refactor the star collection part of the pass into the more general block collection (i.e. finalize #11614) and replace the virtual_permutation_layout/FinalizeLayouts by final_permutation.

Makes sense, thanks Jake, Matthew and Sasha for reviewing this! :-)


use https on support link in composer.json

Description
Use https on support link in composer.json
Checklist:

[x] Securely signed commits

Thank you @totoprayogo1916


ENH: keyword to specify where to insert level with stack/unstack?

unstack/stack does insert the new level as the inner-most level (last level). Would it be useful to have a keyword to specify where to insert the new level. E.g to have it as the first level you now have to do a reorder_levels and sort_index:
In [47]: df = pd.DataFrame({'A': np.zeros(5), 'B': np.zeros(5)}, index=pd.date_range('2012-01-01', periods=5, freq='D'))
    ...: df = pd.concat([df]*3, keys=['x1', 'x2', 'x3'])

In [48]: df
Out[48]:
               A  B
x1 2012-01-01  0  0
   2012-01-02  0  0
   2012-01-03  0  0
   2012-01-04  0  0
   2012-01-05  0  0
x2 2012-01-01  0  0
   2012-01-02  0  0
   2012-01-03  0  0
   2012-01-04  0  0
   2012-01-05  0  0
x3 2012-01-01  0  0
   2012-01-02  0  0
   2012-01-03  0  0
   2012-01-04  0  0
   2012-01-05  0  0

In [49]: df.unstack(0)
Out[49]:
             A           B
            x1  x2  x3  x1  x2  x3
2012-01-01   0   0   0   0   0   0
2012-01-02   0   0   0   0   0   0
2012-01-03   0   0   0   0   0   0
2012-01-04   0   0   0   0   0   0
2012-01-05   0   0   0   0   0   0

In [50]: df.unstack(0).reorder_levels([1,0], axis=1).sort_index(axis=1)
Out[50]:
            x1     x2     x3
             A  B   A  B   A  B
2012-01-01   0  0   0  0   0  0
2012-01-02   0  0   0  0   0  0
2012-01-03   0  0   0  0   0  0
2012-01-04   0  0   0  0   0  0
2012-01-05   0  0   0  0   0  0

closing as stale. pls reopen if still an issue.


Change the firestore timestamp setting?

Noticed while working on #199
Currently if you update a card, you get the first provisional update... and then later, an update of just the timestamp. But that invalidates all of hte downstream caches of cards, doubling the amount of recalcs. We almost never need the accurate update timestamp, can't we just use the local synthesized one?

https://firebase.google.com/docs/reference/js/firestore_.snapshotoptions

https://medium.com/firebase-developers/the-secrets-of-firestore-fieldvalue-servertimestamp-revealed-29dd7a38a82b


Fixed https://github.com/Lightsnap/flutter_better_camera/issues/38

Flutter automatically updated pubspec.lock and .flutter-plugins-dependencies. I am not sure whats that. Never made myself a plugin before.
I was the reported of the original issue. After seeing no activity, I thought, I can fix this myself. The fix is working on my end. And I do not think it should cause any other side effect.
I had debated the approach of adding remove handler function to plugin repository. But it would have required us to create a custom class implementing both those methods and using that class as parameter in maybeStartListening. The method I chose was the easiest to implement with least effect on the functionality and code. Every comment appreciated

We have not experienced this issue and it has not been reported by any other users, so I will close this PR :-)

Did you try on android or ios? Cause I experienced this issue on my Android 8.1 phone and Android 11 emulator. I have opened an issue detailing the steps if you missed. The issue does not occur when I refuse the permission once. But if I go back to the camera screen and refuse permission again, the app crashes. I have also attached a Minimum, Viable, Example in my issue which demonstrates the issue on my emulator


Add documentation for the SMTP output binding

What content needs to be created or modified?
Documentation on how to use the new SMTP output binding (see https://github.com/dapr/components-contrib/pull/646).
Where should the new material be placed?
Operations/Components/Bindings/Supported bindings/SMTP
Additional context
I created a proposal for this binding in the components-contrib repo (still to be approved).

Closed, fixed


chore: prepare afgo for 1.8.0 release

this change updates all AFGO dependencies to latest commit.
It also removes temporary Go1.17 out of memory temporary fix as 1.17.6 has this fixed now.
Signed-off-by: Baha Shaaban<EMAIL_ADDRESS>

We need to update https://github.com/hyperledger/aries-framework-go/blob/main/test/bdd/fixtures/agent-rest/.env#L118


Can you explain the license?

I am worried about the license of this plugin. Kindly add MIT license so that we can use this great plugin.

It is already MIT licensed - look in the JavaScript files :)


Middle click close ev

Mind testing, @Kommynct?

Okay, i'm at work right now, but when I get home, i'll definitely give this a shot, thank you so much!

Thanks for testing :)

Merged on Gitlab.


Learn More Button 404

The Learn More button on the Harbor plugin goes to a 404

Example URL is:  https://TLD/harbor/projects/5/repositories//artifacts/

What Harbor version are you using @billabongrob?
According to latest Harbor version (2.9.4), it should be https://TLD/harbor/projects/100/repositories/bitnami%2Fpostgresql/artifacts-tab/artifacts/12-debian-9

This does appear to be working in our production environment.  Apologies for the confusion - we've reverted to an older version of the plugin.


useThemVars function not returning updated theme values

TuSimple/naive-ui version (版本)
2.31.0
Vue version (Vue 版本)
3.2.16
Browser and its version (浏览器及其版本)
Version 102.0.5005.115 (Official Build) (arm64)
System and its version (系统及其版本)
MacOS(12.4)
Node version (Node 版本)
16.15.1
Reappearance link (重现链接)
https://codesandbox.io/s/billowing-darkness-ks57b6?file=/src/App.vue
Reappearance steps (重现步骤)

Create a file to keep theme customizations e.g. naive-ui.ts
Create & Export themeOverrides object in naive-ui.ts, which the object is including common.primaryColor: '#FF0000' customization
Import themeOverrides object from naive-ui.ts in a vue file, where it has your NConfigProvider, and use themeOverrides
Import useThemeVars from naive-ui and check the primaryColor value

Expected results (期望的结果)
useThemeVars function should return the updated theme variables, so useThemeVars().value.primaryColor should be equal to '#FF0000'
Actual results (实际的结果)
useThemeVars function is returning default values and not merging default values with override values. So useThemeVars().value.primaryColor is equal to '18a058'
Remarks (补充说明)

Sorry for late response, I'm busy at work last week.
In you reproduction, the behavior is expected. Vue's inject on works for ascendant component.
For example you have a component A provide something. You can only got provided value if the component is inside A.
<A>
  <B />
</A>

You can get provided in component B but not in current component.


Can IiteDb be used for Blazor PWA

Hi Mr George Kosmidis,
I want to find out whether LiteDb can be used for blazor web assembly projects especially PWA

Hello @aboah,
I think you will find this helpful: https://blazorlitedb.herokuapp.com/

I am going to close this issue since there is no other response. Feel free to reopen it!


Supporting SQL Server in Migration Engine

Migration engine should know how to migrate Microsoft SQL Server. Some gotchas:
What string type we use by default?
We can choose from the following string types:

varchar would allow us to use UTF-8 encoding, but only on SQL Server 2019. Older versions allow only ASCII characters in this column type.
nvarchar is the original column type, allowing other than just the basic ASCII. Uses UCS-2 encoding, meaning instead of Vec<u8> it holds Vec<u16>, doubling the space usage.

Both variants can either be varchar(n) or nvarchar(n), where n is the maximum length of the string. The maximum n for varchar is 8000 and for nvarchar 4000. When having larger strings, one should use the max variants varchar(max)/nvarchar(max), which changes the storage type out from the row and allows maximum of two gigabytes of data.
What binary size we use by default?

varbinary(n) where n can be maximum of 8000 bytes. Data stays in the row.
varbinary(max) for two gigabytes of storage, data is not kept in the row.

Part of the epic: https://github.com/prisma/prisma/issues/2430

It looks like this has been merged in the prisma-engines repo, but I imagine it would need to be updated to the latest commit in the prisma repo as well before using this?

Just wait for tomorrow's release, or install the latest dev version to try this out. The whole migrate platform is changing now, and we'll announce it tomorrow with the docs and all.

Closing this due to the JavaScript side working with SQL Server now.


cmd/gofmt: remove plus operator before variable

In the following program:
package main

import "fmt"

func main() {
	a := 3
	b := 7
	a = +b
	a += +b
	fmt.Println("a", a, "b", b)
}

I believe the +b is extraneous and does not modify command operation, in both cases. Could go fmt simplify this by removing the plus operator? Similarly we remove things like braces and semicolons when they are unnecessary and do not affect program operation.
Running go tip.

Could go fmt simplify this by removing the plus operator?

gofmt is not a tool that simplifies arithmetic expressions, though. It's a code formatter. Should gofmt also remove the addition in b = a + 0 ? What about a = b + c*0 ? This kind of things belong in a static checker, IMO.

Similarly we remove things like braces and semicolons

Braces and semicolons are syntactic tokens. Elide an unnecessary token and simplify an arithmetic expression are two very different things.

I agree that this is out of place for plain gofmt. Perhaps it could be considered for gofmt -s, but I still think it would be a bit too much.
In fact, gofmt already has some examples to remove unnecessary syntax nodes in arithmetic expressions and slice expressions: https://golang.org/cmd/gofmt/#hdr-Examples
If those aren't part of gofmt -s, why should +expr be?
/cc @griesemer

While we do certain rewrites (and in fact just introduced new ones to canonicalize the formatting of number literals for Go 1.13), we don't want to change what a programmer intended to express in the code. But I admit I don't have a good example except that perhaps one wanted to emphasize a +x next to a -x on separate lines.
You are correct that removing a unary + will not affect the expression's value (explicitly stated by the spec for complex and floating-point numbers); for ints +x is the same as 0+x which is x in all cases; for strings a unary + is not permitted).
In fact, one could remove the unary + from the language - it's never needed and only added for symmetry; which is why we probably don't want to remove it with a rewrite.
As an aside, note that we cannot easily simplify 0 + x without type information: If x is the floating-point value -0.0, than 0 + x results in 0.0 (not -0.0); that is 0 + x cannot be simplified w/o changing the program for floating-point or complex numbers.
I'm leaving this open for now for the wider proposal committee to make a decision, but I am leaning against this change.

If x is the floating-point value -0.0

Ironically, the floating-point value -0.0 is a case where gofmt arguably should remove the leading operator, since the language spec defines that constant to result in +0.0 instead of -0.0 as one might expect.
(https://play.golang.org/p/HJcHuXKuWL2)


function hoisting not allowed

Dear Mr. Crockford,
I'm aware that there is already an issue concerning this topic (it's #33 ) but it's 9 years old and in the meantime the language and JSLint have evolved.
Specifically, JSLint requires all the functions to be declared before their usage, which leads to two consequences in the coding style:

the first wun is that the code must be read in a bottom-up manner, instead of a more natural top-down.

the second wun is that JSLint does not allow two functions to reference each other (using only function declarations - which is the style you're using in "how javascript works"), unless breaking the "equality" between the two functions (i.e., passing the second function as a parameter of the first wun).

function foo() {
   console.log("foo");
   setTimeout(bar, 1000);
}

function bar() {
   console.log("bar");
   setTimeout(foo, 1000);
}

foo();

So, only for the function declarations, can you reconsider to relax this constraint?
Anyway, many thanks for your software!
Cheers

Reading is a concern. When we’re talking about code it is less confusing to read it as an article on a complex topic—further concepts are based on the ones described at the beginning—as opposed to a novel with several plot twists.
A function though could reference another one declared below in case the latter one calls the former.
function first() {
    return second;
}

function second() {
    return first();
}

I’ve stumbled upon it while reading include.js.

the following kludge will pass jslint (which i've used in past).
/*jslint browser devel*/
let foo;
let bar;

foo = function () {
    console.log("foo");
    setTimeout(bar, 1000);
};

bar = function () {
    console.log("bar");
    setTimeout(foo, 1000);
};

foo();

i say kludge, b/c having functions cyclically call each other is error-prone and difficult to debug/trace.
jslint eventually trained me to avoid it and look for better-ways that are easier to qa, e.g.:
/*jslint browser devel*/
function foo() {
    let ii = 0;
    setInterval(function () {
        ii += 1;
        console.log(
            ii === 1
            ? "bar"
            : "foo"
        );
    }, 1000);
}

foo();

I agree, it's a kludge, you're tricking JSLint. The main issue is in the impossibilty to have a top-down style of writing, though; the two functions calling each other are a secondary issue. You can usually (but not always) refactor. Anyway, a switch-case (or if-else) as an alternative is IMHO even worse, since you're basically writing two functions inside one - resorting to some kind of polymorphism (if possible, of course) should be preferred.

A function though could reference another one declared below in case the latter one calls the former.

By inspecting jslint code, I see that line 3947 is the one that allows such kind of declaration and this exception was added in June 2018. It looks to me  really like an ad hoc exception in order to allow some edge case codes...

You could declare an initialize/main/run function, and put it at the top, and run it at the bottom.

i just noticed jslint.js has 2 functions recursively calling each-other,  with no warnings.  suspect its a bug, but maybe could be turned into a feature as well.
// https://github.com/jslint-org/jslint/blob/v2021.5.30/jslint.js#L4573
function walk_expression(thing) {
    if (thing) {
        if (Array.isArray(thing)) {
...
        } else {
...
                // walk_statement() seems to be magically hoisted by jslint
                walk_statement(thing.block);
...
}

// https://github.com/jslint-org/jslint/blob/v2021.5.30/jslint.js#L4613
function walk_statement(thing) {
    if (thing) {
        if (Array.isArray(thing)) {
...
        } else {
            preamble(thing);
            walk_expression(thing.expression);
...
}

JSLint allows
function a() {
    return b();
}

function b() {
    return a();
}

oh nice to know : )
but if calls are wrapped in setTimeout (in original poster's example) jslint gives out-of-scope-warning.  verified behavior in both current and old version v2020.11.6 @ https://www.jslint.com/branch-v2020.11.6/index.html
/*jslint browser*/
function a() {
    return b();
}

function b() {
    setTimeout(a);
}

// warning
// 1 'b' is out of scope. // line 3, column 12
//     return b();


Incorrect moniker. Fixed.

This addresses and closes #8544

@MikeRayMSFT
Can you review the proposed changes?
When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#sign-off

#sign-off


⚠ Bofrost.at has degraded performance

In 1e9828f, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 946 ms

Resolved: Bofrost.at performance has improved in 6d17c0c after 8 minutes.


[New game]: Schulte it Hard !

🎮 Game Request
Game logic and basic description

Point down the features
Game points
Easy to play
Select program in which you are contributing
GSSoC24
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINE of this project.

Hey @Parth20GitHub , You can't have another issue before completing the previous one 😀
you already have the following 1 open issues 👀 ! :
#4156

Hey @Parth20GitHub ! Thank you so much for your raising the issue💗
It’s all yours, you can come anytime again and make some contributions! 🚀
Alone, we can do little, but together we can do so much! 😇

Hey @Parth20GitHub !
Thank you for raising an issue 💗
You can self assign the issue by commenting /assign in comment 😀
Make sure you follow CODE OF CONDUCT and CONTRIBUTING GUIDELINES 🚀
Don’t Forget to ⭐ our GameZone🎮
Make sure you join our Discord🕹

/assign

Please check and merge it


🐞 Update DN404.sol

Description
a -> an
Checklist
Ensure you completed all of the steps below before submitting your pull request:

[ ] Ran forge fmt?
[ ] Ran forge snapshot?
[ ] Ran forge test?

Pull requests with an incomplete checklist will be thrown out.

Wtf... thanks for finding this critical bug. Big thanks!

This one definitely deserves a payout


mysql driver does not handle composite foreign key "magic indexes"

As of b7bb1df, the mysql driver creates "magic indexes" for single-column foreign keys, to match how MySQL handles foreign keys/indexes.
Once #87 is done, expand this behavior to composite foreign keys by looking for foreignKey elements.

moving this to 1.4.1 milestone to get existing changes out there for mysql users


Branch add font

Closes #98

Codecov Report

Merging #99 into master will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master      #99   +/-   ##
=========================================
  Coverage     25.42%   25.42%
  Complexity      144      144
=========================================
  Files            83       83
  Lines          1282     1282
  Branches         96       96
=========================================
  Hits            326      326
  Misses          935      935
  Partials         21       21

Continue to review full report at Codecov.

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


fix double calculation of total stats

fixes #5486 (Actually not sure but hopefully) @amaltaro, Alan please review

sounds good to me Seangchan! Hopefully it will fix the issue :-)


Introduce logging support

So far, when we start engula service, it prints nothing due to we don't add any logging supports.
For interacting with users on healthy and problematic state, I suggest we introduce basic logging support before v0.3 release.
Questions to be answers include:

What logging library to use? I prefer tracing, but slog can be an alternative.
What should be logged? The original requirement is I'd like to prompt users that the server has been ready to response. However, you can follow this question and use cases may change the choice we make on logging library.

cc @huachaohuang @breeswish

How about the log crate?

Regarding when and what should be logged, we could start from the perspective of troubleshooting:

Critical status changes
First time an error occuried
The user/other components input is not as expected

@w41ter-l log crate contains thin API definitions and we should choose an implementation. Also log doesn't support structure logging stably, I tend to use a de-facto solution then a semi-manufactures even it's provided by rust-lang.

tracing used widely in tokio ecosystem.
slog used in tikv for a long time.

BTW, the crates proposed above can bridge to log for API compatibility.

There is tokio-metrics and tokio-tracing. I recommend to give them a try.

I would recommend tokio-tracing for both tracing and logging. For metrics, rust-prometheus may help a lot.

We can start with tokio-tracing. It is very active and has a good ecosystem. Log whatever you think it's necessary for now. These things will be changed frequently in early development. We can make some rules when integrating with other ecosystems in the future.

tracing should be the first choice, with rich support and an increasingly robust ecosystem, while also experiencing experimental tools including tokio-console and tokio-metrics.

I write a small PR for introducing the deps and setups #471. You may give it a review.


Microsoft.AspNetCore.Authentication.Salesforce

Hi.  Just wanted to check if anyone is working on some OAuth 2.0 Salesforce authentication for asp.net core?

It's here https://github.com/aspnet-contrib/AspNet.Security.OAuth.Providers/tree/dev/src

Specifically https://github.com/aspnet-contrib/AspNet.Security.OAuth.Providers/tree/dev/src/AspNet.Security.OAuth.Salesforce

Thanks davidfowl.  I'm looking for something that can support a salesforce connected app and can implement a callback handler for the oauth token.  I was imagining something that would follow a similar pattern to Microsoft.AspNetCore.Authentication.Google etc.

@dallasclement FYI all the aspnet-contrib social providers are based on the OAuth2 generic middleware and follow exactly the same approach as the FB/Google/MSFT providers maintained by the ASP.NET team.

Got it.  Thanks @PinpointTownes.

@PinpointTownes how about obeying the new .NetStandard versioning for those packages in nuget? Don't you think your answer is rather unfair?

@karyaevsm unfair? Not sure I understand what you mean...


Usage of Self in impl blocks

I tried to use Self in a method in the following manner and could not get it to work
struct Circle {
    radius: float
}

impl Circle {
    fn larger_circle() -> Self {
        return Self {
            radius: self.radius()+10
        }
    }
}

I think there are two issues here.

Self cannot be used as return type.
Self cannot be used in call expressions.

Solutions:

Add a new variable to parser to keep track of the struct which the current impl block points to. We could call it current_struct_decl maybe, and it can be an optional. It must be set whenever we come across an impl block, and reset once out of the impl block.

struct Circle {...}
impl Circle {
// set current_struct_decl to Circle
}
// set current_struct_decl to None

Update consume_type to support Self. We need to add a check for Self and return the appropriate struct_decl in case we are in an impl block. If we are not in an impl block, then Self does not make sense, and we need to raise an error.
In call_expr , currently, only the lexeme is being checked if it is present in the structs. impl has the lexeme "impl", and therefore is not matched in the structs array. A match for Self also must be checked in this case.

Please let me know if I'm missing anything in these issues and their proposed solutions. I can take this issue up once you approve. Very cool project btw! :)

Hello! Thanks for taking the time to test and improve things!
Yes, as of now Self usage is limited  to Self:: call expressions only (similar to self. but for statics).
The solution you came up with is a very reasonable one, I am amazed at how well you spotted the exact locations to make improvements.

That's a very good approach. At first I would have thought that it should be done in the interpreter instead, but I think you're actually right, there is no reason to involve interpreter when all can be resolved in the parser. Frankly, I might reconsider my current implementation of Self:: resolving, once your approach is implemented :)
Correct.
Correct.

I don't think you missed anything to be honest and I would be very glad to see contributions.

Implemented in #3


examples: Remove duplicate docker-compose example

We already have an example for docker-compose at examples/getting-started/docker-compose.yml.
Keep a single example to reduce the maintenance burden.

This change is

test-docs-please

Coverage increased (+0.006%) to 42.975% when pulling b693b0fe3bbfaff0613d853b6347bd73d7949fb6 on pr/brb/uniq-docker-compose into ba9798c3a97815f962b3ab9356d1cd741e68d233 on master.

test-me-please

@brb This PR doesn't appear to be currently pending a v1.4 backport. Did you intend it to be backported?


How to solve this problem: You have missing dependencies jedi >0.9.0:None(NOK)

Description
What steps will reproduce the problem?

I use miniconda
When I open the spyder, the spyder shows "error You have missing dependencies jedi >0.9.0:None(NOK)"

What is the expected output? What do you see instead?

Please provide any additional information below
plugin = mod.PLUGIN_CLASS(self)

AttributeError: '_ModuleMock' object has no attribute 'PLUGIN_CLASS'
WARNING:traitlets:kernel died: 6.006259202957153
Version and main components

Spyder Version: 3.2.3
Python Version: 3.6.5
Qt Versions: 5.6.2, PyQt5 5.6 on Windows

Dependencies
pyflakes >=0.6.0 :  1.6.0 (OK)
pycodestyle >=2.3:  2.3.1 (OK)
pygments >=2.0   :  2.2.0 (OK)
pandas >=0.13.1  :  0.23.3 (OK)
numpy >=1.7      :  1.15.0 (OK)
sphinx >=0.6.6   :  1.7.6 (OK)
rope >=0.9.4     :  0.9.4-1 (OK)
jedi >=0.9.0     :  None (NOK)
nbconvert >=4.0  :  5.2.1 (OK)
sympy >=0.7.3    :  None (NOK)
cython >=0.21    :  None (NOK)
qtconsole >=4.2.0:  4.3.1 (OK)
IPython >=4.0    :  6.1.0 (OK)
pylint >=0.25    :  1.7.2 (OK)

If you want to go the hard way and use miniconda, you really need to know how to solve this problem:
conda install jedi.

AttributeError: '_ModuleMock' object has no attribute 'PLUGIN_CLASS'
WARNING:traitlets:kernel died: 6.006259202957153

This is fixed in our latest version:
conda update spyder

I see a very similar issue when I try to run spyder under winpython, I can open the spyder main window, but the spyder is eating 8% cpu always.
I just checked the dependency, and see some modules are missing.
See this comment:
https://github.com/winpython/winpython/issues/816#issuecomment-601012939
but the strange thing is all the modules are already bundled in the winpython installer.


blue_portal constructed via setblock fix

An aether portal created using /setblock now correctly teleports you to the aether.
(Although, using /setblock, the swirl color is still the default gray. This is a problem with CustomPortalApi.)

(Technically both of these issues are due to CustomPortalApi. But when they fix it, this code I've written will likely still work.)

Pull #191 instead


Implement missing schema support for mssql dialect

implement schema support in tablecompiler
add unit tests for hasTable, hasColumn and renameTable

Fixes the mssql part of #2591

Any feedback on this? Should I cleanup the commit history or can it stay this way?
I also have a small script that tests this against a database, but the integration tests do not seem to cover schema support at all, so I wasn't sure if I should implement the MSSQL specific case there...

@Fabi2607 I'm not familiar enough with mssql to make a good call here, is there anything backward incompatible about this change / anything that would break the existing use?

All of this should be backwards compatible, as this should only affect calls using withSchema syntax.
Also none of the existing tests needed to be adjusted.
The only thing that could break is, if someone worked around this issue using withSchema('schema').hasTable('schema.tableName') which is explicitly discouraged in the documentation.

@Fabi2607 Prettier was merged, so make sure to pull changes from master and run prettier :)

Rebased on master and ran prettier.

@tgriesser any idea why the test is failing?

@Fabi2607 just random flakiness. Try closing and reopen8ng pr.


Remove dashboards, prometheus, grafana to a lodestar-metrics repo

We should reduce the PRs and noise in the main repo
cc @dapplion

-1 for moving dashboards, we would lose the ability to atomically rename metrics in a single commit and update the dashboard when adding new metrics in a single MR.
If we remove dashboards this would also warrant to move the docs to a separate repository which is also not a decoupling I would be in favor of.
To reduce noise for something like release notes could think of a concept similar to conventional commits to better categorize commits, things like refactoring code, docs, dashboard updates, CI/CD updates, etc. should not show up in the release notes.

We had previously discussed moving toward conventional commits around EthDenver in 2022... not sure if this was still a consideration. That would at least organize it better for us in the main repo. Would keep this discussion open for further thoughts, but continued maintenance and ease of workflow for something as critical as metrics should be taken into consideration.

Our dashboards are very specific to us. There are now an unknown number of dashboards that use our metrics. So alreadt we should not change the name of metrics to prevent downstream breaking changes anyway.

Renaming metrics is definitely not ideal and should be avoided.
If we move the dashboards need to also keep in mind tho that there are projects might get the dashboard from this repo, e.g. eth-docker fetches it from stable branch. There are further unknown amount of references we would probably break but might not be a big deal and would be fixed sooner or later.
Could maybe consider to publish an image (chainsafe/lodestar-dashboards) which includes all dashboards and other projects can get them from there. This would also be a possible solution to our local metrics setup as mentioned in this comment.

Are there still any strong opinions to support this idea? If not, we should close it.

We aren't planning on removing the dashboards.


Interleave Value when using Storage Bus Cache

Hey,
Just a little confused about how to set the interleave property when using Storage Bus Cache. New Volume doesn’t take it and after that SBC creates the virtual disk for me. Is there a way to tune it for my workload?

We hugely appreciate your contribution, feedback, and support to our technical documentation.
We’ve phased out GitHub Issues on this repository as the feedback mechanism for content and have replaced it with a new feedback system. For more information see, Content User Feedback. As part of this rollout, we are migrating your issue where our team will use your comments to improve the documentation experience. Unfortunately, this does mean you won't be able to access this issue after the migration is complete.
All issues will be migrated by Thursday 29th August 2024.
Once again, thank you for your valuable feedback, we hope you’ll continue to contribute using our new feedback system.


Downloads: what do people do in the UV?

As download options in the universal viewer (library site) we currently track the following:

Entire document PDF
High res image
low res image
Download current view
document as text

Between October and December 2018 we collected the following data. The % conversion is based on number of downloads (of each type) divided by number of sessions in that period.

PDF = 4831 (5%)
high res = 4523 (4%)
low res = 1693 (1.6%)
current view = 613 (<1%)
doc as text = 164 (<1%)

Based on the data, PDF and high res are top choices for users.

Download options based on number of downloads/number of item pageviews:

PDF = 6%
high res = 5.7%
low res =  2%
current view= 0.7%
doc as text = 0.2%


Alaska is collecting/reporting based on "economic regions" not counties

AK is only reporting 6 “economic regions” which may or may not map to collections of counties. These regions seem important in their normal governance beyond covid19. We might want to consider adding these regions geographical features.
These pages probably have the GIS shapes for the economic regions:
https://dcra-cdo-dcced.opendata.arcgis.com/datasets/alaska-economic-regions (edited)
http://live.laborstats.alaska.gov/cen/maps.cfm#gis

Thanks for implementing this!


New feature to save a thumbnail for a generated network

From @georgiana-b on October 16, 2017 6:45
From @nightsh on January 5, 2017 13:15
We need to show thumbnails for networks, but we need a way to send them to the API.
Options:

Generate the image client side, upload it to a 3rd party and send the link to the API (a bit insecure)
Generate the image client side, PUT it on an API route, then get back the link to it.
Same as 2, but instead of making the images available through a link, send them as blobs with the appropriate Content-Type (my fav so far).

@georgiana-b can we have a complexity estimate for this?
Copied from original issue: tenders-exposed/elvis-backend#31
Copied from original issue: tenders-exposed/elvis-backend-py#17

From @zufanka on October 13, 2017 14:53
@georgiana-b @nightsh also something for when the new backend is ready?

I think this needs to be closed, as we dropped the idea of network thumbnails on the grounds of not being very helpful or relevant for our users. @zufanka can you confirm this?


Refactor Plugin management

This PR started out as an attempt to address this comment. In short: as of #556, BaseIsolatedPlugins receive a context where context.event_bus == None. This caused problems: some plugins directly accessed self.context.event_bus (which did not exist) instead of accessing self.event_bus (which does exist). The simple fix would have been to fix those accesses, but this PR is the result of an experiment where I tried to make that bug impossible.
This resulted in me pulling at a thread for a while, after each change another small change appeared. For example: First I removed event_bus from PluginContext, but that left PluginContext holding nothing but TrinityBootInfo, so the next step was to remove PluginContext. I'm not married to any of these changes, I'm happy to walk out one that you disagree with! But I think that most of these help a little with clarity, and it's nice that this ends up removing 64 lines in exchange for almost no functionality.
Changes:

Plugins are no longer instantiated during import, before any startup.

BasePlugin.configure_parser is now a classmethod, because the parser is configured before plugin instantiation.

BasePlugin.__init__() accepts a TrinityBootInfo, BaseAsyncStopPlugin.__init__() accepts an additional event_bus parameter. Previously plugins started in an uninitialized state until set_context had been called on them. They now accept their context during construction, such that it's now impossible to create an uninitialized Plugin.
This required changes to a few of the plugins:

AttachPlugin and DbShellPlugin now always use ipython, when it's available.
SyncerPlugin now hard-codes the strategies which it uses, although a subclass could easily change them.
In general, it's no longer possible to configure plugins by passing information into their constructor.

PluginContext no longer exists. It was a wrapper around (boot_info, endpoint), now each of those parameters are passed in separately. This is done because BaseAsyncStopPlugin is the only subclass which uses an event bus so it can now be the only subclass which accepts one.

PluginManager.register() was dropped. Previously PluginManager() returned an object that was uninitialized until .register(Iterable[BasePlugin]) was called. Now those plugins are passed into the constructor and it's impossible to create an uninitialized PluginManager.

BaseManagerProcessScope.create_plugin_context is now create_plugin. Now that the implementation is so simple there's probably room to simplify this class further, but I think this PR might be at a good checkpoint and that can be saved for later.

Cute Animal Picture

I'm pretty sure the tests are failing because https://github.com/ethereum/trinity/commit/a9d69d37fc860aab9139bf179deaca6d6ee2434a#diff-bcb3f875bb745a964ec62cfb0d9ac188 added a plugin.

I had a lot of fun here, this PR started failing today after a logging change because in python 3.6 it's not possible to pickle a logger. It took me a while to figure out what was causing the problem (The exception complained that RLocks couldn't be pickled, but there was no indication of where that RLock was coming from). In order to diagnose the problem I found the Pickler which multiprocessing uses and changed it's dispatch table to print when the Pickler did any lookups. This gave me enough information to figure out that loggers were causing the issue. Dropping a note here for future reference!

@ChihChengLiang, this PR changes NetworkGeneratorPlugin, which you recently added. I think that it still works but I didn't test it manually; if this change causes you any problems please tell me and I'll make it right.


URI signing renewed tokens should have configured identity as value of issuer

The iss claim in renewed tokens should contain the identity of the cache that
reissued the token rather than the original issuer. This identity is configured in
the id field in the uri_signing config. This is the same value that is used to
validate the aud claim.

[approve ci]

This was a misinterpretation of the specs.


A way to figure out version from within the WSL environment?

In providing user guidance and possibly adjust behavior of our tool when running under WSL, we would like to be able to discover what "version" of WSL we are under.  I could find only the "major build" number since it is included in "kernel build" information available from uname.

So we can deduce that it is a built 17134 but not that the OS "version" 1803 which is what I guess we should consult/look for to e.g. instruct users to update their Windows (and thus WSL)?
Thank you in advance for guidance
Attn: @kyleam

The "OS build" is the right version number to look for.

ok, thanks @benhillis . we could do that I guess, extracting it from uname.
I guess we could use smth like https://changewindows.org/build/redstone4/17134/pc to see the set of changes related to the build.    Is there some mapping available for "build" (17134) -> "version" (1803) since ppl seems to refer to versions quite often as well

@yarikoptic - Uname is probably the easiest, but you could also use /proc/version or /proc/version_signature as well.
Wikipedia has a helpful table.


Overflow Issue after start recording

When I start recording it show button overflow by 40 pixel
Please fixed the issue.
and please check the attached snapshot

.

i will fix it and tell you when done

Dear Subhi-Khalife I am still waiting for your reply
Please fixed it I need it urgent.....


don't load package registry unless there are pkg deps to solve

So uh, what happens if my source deps have transitive package deps? Are they not going to work anymore?

No, they still work. They aren't resolved until after all are gathered. So source deps with package deps gather them at line 137 (combined with top level package deps) and then all of them are used to find the solution.


Simple GroupBy statement still evaluated locally

Hello,
We've just upgraded to EF 2.2 and the only GroupBy statement, which so far had been evaluated locally, is still evaluated locally. Is this something you are aware of or should I create a separate solution for you? Please note that the produced Group By contrains not only integer but entity itself as part of GroupBy parameters.
return _context.StockOperations
    .Where(so => so.Date >= from.Date && so.Date <= to.Date)
    .GroupBy(so => so.ConsumableId)
    .ToList();

public class StockOperation : IAuditEntity
{
    public int StockOperationId { get; private set; }
    public DateTime Date { get; private set; }
    public decimal Quantity { get; private set; }
    public StockOperationType Type { get; private set; }

    public int ConsumableId { get; private set; }
    public int? OrderId { get; private set; }
}

warn: Microsoft.EntityFrameworkCore.Query[20500]
      The LINQ expression 'GroupBy([o].ConsumableId, [o])' could not be translated and will be evaluated locally.

SELECT so."StockOperationId", so."ConsumableId", so."CreatedAt", so."Date", so."OrderId", so."Quantity", so."Type", so."UpdatedAt"
FROM "StockOperation" AS so
WHERE (so."Date" >= @__from_Date_0) AND (so."Date" <= @__to_Date_1)
ORDER BY so."ConsumableId"

Further technical details
EF Core version: 2.2.0
Database Provider: Npgsql 2.2.0
Operating system: macos
IDE: VS Code / Rider

In order to generate grouping of IGrouping<int, StockOperation>, client eval is must. The SQL Group By only corresponds to when using some aggregate operation on the grouping to get a scalar value out of it. In other words, there is not other way to process above group by other than doing partial client eval like that.


Airdrop Not working on 2011 MacBook Pro El Capitan With Wifi Module Upgrade

After upgrading to OS X El Capitan I can no longer use the new airdrop. I have installed the correct module for this to be compatible and it was working before upgrading to El Capitan.
MacBook Pro 8,2 with internal airport card upgraded.
People can see and transfer to me, I just can't see or transfer to other people. If anyone needs something in order to track down this bug, please just let me know and I will try to provide it.

Hi,
I uninstalled CAT before to install El Capitan.
I reboot on recovery mode (cmd R) and I disabled SIP, I reboot, and I installed CAT v2.2
All is ok, wifi, bluetooth, airdrop and handoff.
I reboot on recovery mode to enable SIP. I reboot.
Wifi bluetooth airdrop and handoff work perfectly.
I hope this steps will help you
MBP 8,2 15" late 2011 2,4GHz with BCM94331PCIEBT4CAX wireless card

I don't know where to get version 2.2. All I can find is 2.1.3. Can you point me in the right direction?

When you click on the "Download link" on the master page you download the version 2.2 automatically, not the version 2.1.3
the link is https://github.com/dokterdok/Continuity-Activation-Tool/archive/master.zip

Okay. I completed the following steps but it rendered no juice.
1.) uninstalled CAT 2.1.4
2.) rebooted
3.) Replaced CAT 2.1.4 with 2.2 in Applications
4.) opened CAT2.2
5.) Installed CAT2.2
6.) Reboot
7.) No Dice
8.) logged in a Guest- it worked. crap.
9.) logged in as myself and signed out of iCloud- it works so long as everyone is set. If I change visibility to contacts only, no dice.
Still a bug but at least I can airdrop in some capacity again

Update
Today I have this message "no harware installed" about the wifi card.
I reboot (cmd+R) and disables SIP, all works fine.
I enable SIP, wifi not work.
I uninstalled CAT v2.2.2
Wifi works but no handoff and no continuity :-(
However continuity worked until today

I had a similar problem caused by file permissions recovery.
Solved this by disabling sip, uninstalling (recovering) and reinstalling CAT. Then I was able to reenable SIP without any problem.


How to use a local llm or open source model

I saw the research paper mentioned "The local LLM Vicuna-7B [6] is deployed on the smartphone
based on Machine Learning Compilation for LLM (MLCLLM)". How to setup the local llm and run the ./scripts with local llm?

We deployed Vicuna-7B on smartphone only to evaluate its per-step inference latency, and did not run the whole pipline of AutoDroid on it, as we believe this requires only engineering efforts. You could refer to our artifacts repo https://github.com/autodroid-sys/artifacts/tree/main/Fastchat for fine-tuning Vicuna-7B.

the local llm can be hosted on computer instead of the smartphone.


Evaluation script

It looks that method argument is missing in the run evaluation.  Also, I was wondering how to run the evaluation for TM mode because the script shows an error about "images_best.pt".  How do I get that file?

Hi,
sorry for the late reply, I uploaded the condensed dataset to the shared drive:
https://drive.google.com/drive/folders/1trp0MyUoL9QrbsdQ8w7TxgoXcMJecoyH?usp=sharing
Feel free to send me an email if you have any further questions.


THRIFT-4295: reworked docker images to resolve build issues

I reworked docker images and travis build jobs, omitting debian for now because it's quite similar to ubuntu.
Notes:
For the D language I have openssl and libevent disabled in the xenial image for now.  I ran into issues with the deimos for openssl and the version in the image; deimos supports 1.0.1g and xenial has 1.0.2g in it.  Will address in a separate PR.  The centos/7.3 image still has the demios extensions enabled for openssl and libevent.
For php7 in xenial I had to make a TCP_NODELAY set conditional.  The required methods didn't seem to exist in the OS provided php7 packages.  This didn't affect tests, apparently, as they all passed.  Seems pretty weird to me.. centos/7.3 uses php 5.x.
I removed the Python 2.6 build job with the old CentOS 6.x image.
I added versions to every language in the configure output summary.
I removed a generated file that was checked in (mock_handler.go).

Travis CI build failure was environmental (unable to download a module from the dart module service).  Otherwise this is good to go.


Server connection test updates actively selected server not the origin server

What you were trying to do
Look at servers accurately on the Join Game screen showing multiple servers
What actually happened
Clicked a bad server (offline) first by accident, then selected a working server. When the failed ping test came back from the bad server it showed the result (being unable to connect to the server) on the good server, despite the other stats showing online and all is well.
Some threaded check holding that call probably needs to pick its update target better. Maybe at present it just updates the field regardless of the selected server, when perhaps it should be a call-back with the specific server queried? And if that isn't visible /selected then don't show it.
How to reproduce

Make sure there's both a working and not-working server in the join game list
Select the broken server (should start a server query that'll time out)
Quickly select a working server and wait a second or two, the connection to the good server will show that it "failed"

I will try taking a look at this as a first PR.

@raisinrand great, good luck!


Fix From: header parsing

GitGitGadget had a problem parsing the From: header in https://github.com/gitgitgadget/git/pull/1076. The cause was an incorrect regular expression, which this PR fixes.

Good catch.
Trying to figure out why the duplicate cc: entries were added to the PR description (with a newline?).   There seems to be some encoding changes in the emails.  If you have already accounted for this please say so to save me some time.

If you have already accounted for this please say so to save me some time.

I haven't even noticed, and I am running out of time today before I can work on GitGitGadget :-(

The end result is a failure in PatchSeries::parsePullRequestBody with a submit not including all the cc:.  Want to make sure you are aware of this while I research a solution.  Manual edits of the PR description may introduce empty lines that need to be ignored/trimmed when parsing for the footer.
Both PatchSeries::parsePullRequestBody  and GithubGlue::addPRCc may need changes.
Have not found a way to easily see the raw edits of changes to the PR description that would make it easier to replicate the problem.

@webstech thank you for the update, I have not had a chance to focus on this because there have been issues I needed to address before I could release Git for Windows v2.34.1 (which is still not published).


[pipelines] Ensure ClusterRoleBindings and ServiceAccount cleanuped after execution

The ServiceAccount and RoleBinding are now being cleaned up when the notebook finishes. This is good to merge from my end.

great, thanks @drewrip , mergin


Bjorncs/conscrypt

@vekterli please review
@gjoranv please review Maven exclusions

@bjorncs Close ?

We will wait for improved TLS performance in Java 11 instead. Closing.


[Network] firewall with firewall policy

Fix Azure/azure-cli#11834

This checklist is used to make sure that common guidelines for a pull request are followed.

For new extensions:

[ ] My extension description/summary conforms to the Extension Summary Guidelines.

If this PR is for a new extension or change to an existing extension, use the following to try out the changes in this PR:
docker run -it microsoft/azure-cli:latest
export EXT=<NAME>
pip install --upgrade --target ~/.azure/cliextensions/$EXT "git+https://github.com/MyronFanQiu/azure-cli-extensions.git@fix-11834-firewall-with-firewall-policy#subdirectory=src/$EXT&egg=$EXT"


Spec should have a reference to RFC2119

For clarity purposes the words like MUST should be defined by the spec. For example:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.. link: http://tools.ietf.org/html/rfc2119

On Tue, Nov 24, 2015 at 02:36:55PM -0800, Mike Brown wrote:

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.. link:
http://tools.ietf.org/html/rfc2119

+1.

+1. We should probably have some huge flag day where we agree to make these
changes.
On Tue, Nov 24, 2015 at 10:31 PM W. Trevor King<EMAIL_ADDRESS>wrote:

On Tue, Nov 24, 2015 at 02:36:55PM -0800, Mike Brown wrote:

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.. link:
http://tools.ietf.org/html/rfc2119

+1.
—
Reply to this email directly or view it on GitHub
https://github.com/opencontainers/specs/issues/256#issuecomment-159509599
.

:+1:

This can probably be closed now that #260 has landed.


make -j parallel support ?

curious any plans to fix openssl source compiles with make -j http://openssl.6102.n7.nabble.com/parallel-make-broken-td45613.html ?

The patch mentioned there is specific to GNU make which is why we won't take it.

thanks @richsalz so there's no other work or plans for parallel support besides that patch ?

no, we're looking at a big overhaul of the make "systems" for the next release.  I hope something will show up in master in a couple of months.

Sounds great looking forward to that as source compilations for openssl running pretty slow i.e. when trying to statically compile openssl for Nginx source compiles.


Extend the Rancher/Docker and k8s providers to support custom Error pages

Vis a vis:
https://github.com/containous/traefik/issues/2035
It looks like the only way to use custom Error pages right now is via file configuration, which isn't feasible for the Rancher/Docker provider (including k8s provider too as a courtesy).
Can we get these configurable in labels please? I'd really like to use them.

Thanks for your interest in Traefik !
Every question in the issues means features less 😉.
The issue tracker is for reporting bugs and feature requests only.
For end-user related support questions, refer to one of the following:

Stack Overflow using the "traefik" tag
the Traefik community Slack channel

This is a feature request.

Sorry, this was closed a bit too quickly

@dbsanfte Every time someone does not respect the issue's template, a little bunny dies.

Please edit your issue description to respect the issue template as much as possible.


Adds first iteration of logs2webhook service

Addresses #1811

[ ] Affected Issues have been mentioned in the Closing issues section
[ ] Documentation has been written/updated
[ ] PR title is ready for changelog and subsystem label(s) applied

Explain the details for making this change. What existing problem does the pull request solve?
We've found that the notifications system could fruitfully be used to also drive webhooks. This PR introduces a copy-pasta'ed service sends data to an arbitrarily defined webhook url.

@tobybellwood - added you to review.
Still need to test this in context (I've been injecting events into the broker to test) - so let's do that together.

so, to make this tie in with the service addition in lagoon-charts, it's a multi-step process:

Update the references in the Makefile in https://github.com/uselagoon/lagoon-charts/pull/246 to set
IMAGE_REGISTRY = testlagoon and
IMAGE_TAG = pr-2593 to grab the images built from this PR
Push the branch in https://github.com/uselagoon/lagoon-charts/pull/246 to uselagoon/lagoon-charts directly (i.e at feature/adds_logs2webhooks)
Reference that branch in the ./Makefile in this repo as CHARTS_TREEISH=feature/adds_logs2webhooks
Push this change up to the PR here to run it through Jenkins.
Work out how to revert all these changes when it comes time to merge (I think this one first???)

General notes - adding a new service isn't easy at the moment, and strongly favours pushing non-forked branches.  It also obviously gets more complicated when this branch also runs tests that require the new service!


Unable to follow the steps.. need help

Hi
I want to download the pdf from hub i try to follow the steps but not clear how to do it. As i have no experience in javasccript, so unable to run it. Can you please help me.
Followed these steps
I have installed NodeJS in my window pc.
I have chrome.
In Config. json i have set the path and the user details.
Now whats the next step? How to execute it?

If you have no experience, you should probably use the GUI version ; https://github.com/AZn5ReD/saplearninghub-pdf-downloader-gui

If you have no experience, you should probably use the GUI version ; https://github.com/AZn5ReD/saplearninghub-pdf-downloader-gui


Add descriptions to the README.md file.

Added descriptions about the project and instructions on how to setup the project and run it

I added the description to the README.md file. You can try setting the project in another computer to see if it works

ok sir, thank you so much


Fix some typos

Codecov Report

Merging #783 into master will not change coverage.

@@          Coverage Diff           @@
##           master    #783   +/-   ##
======================================
  Coverage    54.1%   54.1%
======================================
  Files          95      95
  Lines        7310    7310
======================================
  Hits         3955    3955
  Misses       2775    2775
  Partials      580     580

Impacted Files
Coverage Δ

src/restic/snapshot.go
44.04% <ø> (ø)
:white_check_mark:

src/restic/backend/sftp/sftp.go
67.04% <ø> (ø)
:white_check_mark:

src/restic/id.go
73.58% <ø> (ø)
:white_check_mark:

src/cmds/restic/cmd_forget.go
33.94% <ø> (ø)
:white_check_mark:

src/restic/repository/index.go
69.78% <ø> (ø)
:white_check_mark:

Continue to review full report at Codecov.

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

Cool, thank you very much for your contribution! Did you read all the code, or was that some automatic script or so?

Just hunspell -l -d en_US | sort -u and looking through the list.


chore: cherry pick for v4

Description
Cherry picked these commits/PRs (oldest to newest):

https://github.com/vitejs/vite/commit/86cbf6977d259cfbe87b287f42cf20668014aef3 https://github.com/vitejs/vite/pull/14117

https://github.com/vitejs/vite/commit/bd9b749fe5c7d390a48368ca3a2f4ac55e730607 https://github.com/vitejs/vite/pull/14127

https://github.com/vitejs/vite/commit/387a6e875a77d9c2e515c1b56d9172493916d64d https://github.com/vitejs/vite/pull/14152

https://github.com/vitejs/vite/commit/c39e6c1ccfcb37ff3328a6f5487e11a8f753cec1 https://github.com/vitejs/vite/pull/14013

https://github.com/vitejs/vite/commit/91a18c2f7da796ff8217417a4bf189ddda719895 https://github.com/vitejs/vite/pull/14094

https://github.com/vitejs/vite/commit/627159d59b7ed03de4f283ad5240c949ef0487a0 https://github.com/vitejs/vite/pull/14232

https://github.com/vitejs/vite/commit/245d186544a660afa7ec835f7ebed8766dca0361 https://github.com/vitejs/vite/pull/14241

https://github.com/vitejs/vite/commit/6f86de356985b2604eb757897e039520195dcc23 https://github.com/vitejs/vite/pull/14217

https://github.com/vitejs/vite/commit/34826aae015ed16dc9b9096c0f778154ca6981a6 https://github.com/vitejs/vite/pull/14283

https://github.com/vitejs/vite/commit/2b80089491eb028468c54b3f1e7cf375c94a4432 https://github.com/vitejs/vite/pull/14290

https://github.com/vitejs/vite/commit/66a97bec6ea66e1fd9a4e047c3d47d65a9077647 https://github.com/vitejs/vite/pull/14296

https://github.com/vitejs/vite/commit/c5f65587569f8dd7ef083261021c572e02248b29 https://github.com/vitejs/vite/pull/14285

https://github.com/vitejs/vite/commit/19bf0f1d0be03572d8303bc71e6d6df6a0b29e0e https://github.com/vitejs/vite/pull/14326

https://github.com/vitejs/vite/commit/4bf31e5c6071b87ecf754b496dc14b3d90d73608 https://github.com/vitejs/vite/pull/14297

https://github.com/vitejs/vite/commit/9884308228d3c918d973c08a84f4cca5251cf23a https://github.com/vitejs/vite/pull/14379

https://github.com/vitejs/vite/commit/c3e4791beb647661d81a4a36fd94d92ece965e19 https://github.com/vitejs/vite/pull/14394

https://github.com/vitejs/vite/commit/99b0645c4cc0ed9cab8362f0627dc27b8ccdb5d5 https://github.com/vitejs/vite/pull/14465

https://github.com/vitejs/vite/commit/ec7ee22cf15bed05a6c55693ecbac27cfd615118 https://github.com/vitejs/vite/pull/14458

https://github.com/vitejs/vite/commit/f80ff77a4326669a07f76df3a2ccd66f9e0cafa5 https://github.com/vitejs/vite/pull/14489

Additional context
Focused on downstream blockers and minor bug fixes, and a bit relaxed with picking these. The only commits I'm unsure of are the sourcemap fixes since we changed sourcemap handling quite a bit, so I didn't picked those.
Let me know if there's more to pick, or commits that you think shouldn't be picked.
Also make sure to rebase and merge!

/ecosystem-ci run

Looks like there's some CI fails. Gonna check that. I'm not sure if we need to wait till ViteConf though, they are mostly bug fixes. If ecosystem-ci is mostly passing I think we can cut a new patch soon.

Looks like Rakkas is the only one failing. I re-ran it just in case it's a fluke. I'll also cherry-pick the node 18.17 pin to v4 directly so that this PR's CI will pass when merged.

Thanks!
I think it's safer to restore this part

Given that the ecosystem-ci is passing, I think we can release the patch when it's ready.

Good catch! I forgot there's a partial breaking change there. Will push another commit to bring it back.


Add question contextual help

Many questions would benefit from additional guidance being available to guide the user in answering them. This proposal is for adding an optional link or icon next to each question (tooltip / contextual help) that would open up contextual help (could be inline, dialog, footnote, etc.). The optional link should only be present if help text is available for that particular question.
The additional help should be defined declaratively (e.g. in survey_enfr.js), and be localized (french/english). Bonus points if it can be styled, e.g. basic HTML or markdown.
This may help: https://github.com/surveyjs/survey-library/issues/260

This is what it looks like :)

You can register a custom title action and display a descriptive text within a custom popup or a question description. For more information, please refer to Context Actions in Element Titles.


Testing Trained Models

Users should be able to test trained models through the web UI with varied data sets

https://github.com/dfst/deepforge/issues/10


Visual feedback on correct/incorrect guess

Describe the problem
When most people start playing, they will get confused when they press the check/enter button when nothing happens. In reality they might have gotten the answer wrong but have no clue if it's that or just a bug.
Describe the proposed solution
The user should receive some sort of visual feedback when they get an answer wrong. Extra credit for feedback on correct answer.
I was thinking that either the board or the check button wiggle a little bit and have a quick red glow/flash. Open to other ideas.
Alternatives considered
No response
Additional Information
No response

Reference for glow: https://tailwindcss.com/docs/box-shadow-color


xyz filename fix

closes #172

Codecov Report

Merging #173 (2fa897c) into master (cd020bb) will decrease coverage by 0.00%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #173      +/-   ##
==========================================
- Coverage   93.71%   93.71%   -0.01%
==========================================
  Files           8        8
  Lines         971      970       -1
==========================================
- Hits          910      909       -1
  Misses         61       61

Impacted Files
Coverage Δ

src/crystal.jl
94.69% <ø> (-0.02%)
:arrow_down:

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


[PastePlain]Can't use Ctrl+V as the activation key

Microsoft PowerToys version
0.68.0
Installation method
GitHub
Running as admin
No
Area(s) with issue?
General
Steps to reproduce
Set Ctrl+V as the activation shortcut for Paste as Plain text.
✔ Expected Behavior
To paste as plain text when I press Ctrl+V.
❌ Actual Behavior
V gets written instead.
Other Software
No response

Fixed in 0.69 which was released in the start of April 2023.


Fix plugin syntax error

Found this little sucker during woocommerce implementation.

huh nice find!! Not sure how this wasn't causing issues for me
Thanks!


Prevent linter configs from "leaking" between projects

build_review_config mutates the Flask app config object when setting
review_config. A side effect of this is that the linters dict in the
Flask app config object holds state between process_pull_request task
executions. This can cause projects to be linted by linters configured
for other projects
A quick fix, since the Flask Config class behaves like a dict, is to
create a copy

Codecov Report

Merging #207 into master will increase coverage by <.01%.
The diff coverage is 50%.

@@            Coverage Diff             @@
##           master     #207      +/-   ##
==========================================
+ Coverage   89.27%   89.28%   +<.01%
==========================================
  Files          41       41
  Lines        2173     2174       +1
==========================================
+ Hits         1940     1941       +1
  Misses        233      233

Impacted Files
Coverage Δ

lintreview/tasks.py
30.43% <50%> (+1.54%)
:arrow_up:

Continue to review full report at Codecov.

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

Thanks!


Rename Conduct.md to CODE_OF_CONDUCT.md

Renames the code of conduct file so that GitHub can find it.

Hooray Jenkins reported success with all tests good!


RFP - NaChat

Portable desktop chat client for Matrix.
https://github.com/Ralith/nachat

Is discontinued.


update install method to pip

following the coda-forge recommendations, switch to installing the package via pip install rather than setup.py

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


test: add test_utils crate and move test_valid_config_body to it

This change is

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#116
#115
#114  👈
#113
#111
#110
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @ArniStarkware and the rest of your teammates on  Graphite

Codecov Report
Attention: Patch coverage is 73.68421% with 5 lines in your changes are missing coverage. Please review.

Project coverage is 44.68%. Comparing base (0fc31c4) to head (0f7ff43).

Files
Patch %
Lines

crates/test_utils/src/config.rs
73.68%
3 Missing and 2 partials :warning:

Additional details and impacted files
@@                                         Coverage Diff                                         @@
##           arni/config/gateway_network_connection/generalize_test_util/pt2     #114      +/-   ##
===================================================================================================
+ Coverage                                                            43.75%   44.68%   +0.93%
===================================================================================================
  Files                                                                   16       17       +1
  Lines                                                                  592      611      +19
  Branches                                                               592      611      +19
===================================================================================================
+ Hits                                                                   259      273      +14
- Misses                                                                 325      328       +3
- Partials                                                                 8       10       +2

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


Label numbers generated by flow_from_directory

I'm using flow_from_directory to get the training set from a folder with the following structure:
train
  class1
  class2
  class3
  ...

The generator is called as it follows:
train_generator = train_datagen.flow_from_directory(
        train_data_dir,
        target_size=(img_height, img_width),
        batch_size=32,
        class_mode='categorical')

I am not setting the argument classes, but I was expecting to get the labels in alphabetical order.

classes: optional list of class subdirectories (e.g. ['dogs', 'cats']). Default: None. If not provided, the list of classes will be automatically inferred (and the order of the classes, which will map to the label indices, will be alphanumeric).

However, when I classify the training images (for checking which labels are being returned), I'm don't get any specific ordering. The training goes well (accuracy of ~85%), and there is a consistency with the output labels when classifying images from the same class.
How can I infer the labels numbers generated by flow_from_directory and map them to the classes?

This was fixed by https://github.com/fchollet/keras/pull/3052.

how to resolve ?

Just use the most recent version of Keras.

Yes,I have resoved. Thanks
2017年1月25日 06:04，"Fábio Perez"<EMAIL_ADDRESS>
Just use the most recent version of Keras.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/fchollet/keras/issues/3054#issuecomment-275080049,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AQqDjyFR46xDsr7NJ27GJe8Ge9vgZM9Yks5rVywhgaJpZM4I82D-
.

how to resolve?


Dev

When reviewing, found that filenames for the downloaded SVGs are sometimes incorrect
To reproduce:

Search for lineage B.1.573 through the search interface
Click SVG button to download beadplot
Filename for the downloaded file is B.1.601.svg

temporarily suspend cron job
do dry run to validate backend and frontend
restart cron job

Ran in about 10 hours.  All checks out.


Hydrogen cannot read triple quotes

Description:
I have issues to print strings that are created with three quotes, """.
Steps to Reproduce:

Here is the code I am using, and the error message:

snake_string = """Welcome to Python3!
             ____
            / . .\\
            \  ---<
             \  /
   __________/ /
-=:___________/
"""

When I hit shift + enter, there is what I get:

I tried single triple quotes ''' and double """, but neither of them works.

It is OK to run using Script.

Versions:
I am using macOS Version 10.12. Atom is 1.18

Thanks for reporting. Seems we need to parse what the last statement or expression is rather than running the last line.
For now at least it looks like you'll have to select the entire block of code you want to execute.

Thanks for the reply! Sometimes, it has problem parse a function if I hit shift+enter at the last line. Script doesn't have similar issue. I will select the block for now.

@rachelfu the other thing you can do (at least for now) is use the run cell functionality.

@BenRussert
This works too. Thanks!

I'll close this since it looks resolved. Let me know if you have any questions!


Ubuntu trusty install instructions are missing a dependency

Trusty requires libssl-dev to be installed via apt-get in order to build machida.

Fixed by #1654


Loss Class is always zero

I'm using your framework for images with only 1 label and 1 anchor box.
The class loss is ALWAYS zero. Is that for purpose?
2017-12-21 14:46:50.722959: I tensorflow/core/kernels/logging_ops.cc:79] Loss XY 	[0.188059166]
2017-12-21 14:46:50.722978: I tensorflow/core/kernels/logging_ops.cc:79] Loss WH 	[0.0108934361]
2017-12-21 14:46:50.722994: I tensorflow/core/kernels/logging_ops.cc:79] Loss Conf 	[0.0540329479]
2017-12-21 14:46:50.723009: I tensorflow/core/kernels/logging_ops.cc:79] Loss Class 	[0]

Because you have only one label, there is no way for it to go wrong with the class; it will always guess the only label.

Ah, I thought there is a implicit class "background". Thanks!


test: Update Fabric GHA workflow

Upload coverage artifacts in html format to see Go coverage details for each run
Add empty test sweepers for Fabric to avoid failing jobs on sweepers that aren't related to Fabric tests

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

Comparison is base (34b256e) 44.83% compared to head (ae242a4) 43.58%.
Report is 10 commits behind head on main.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #540      +/-   ##
==========================================
- Coverage   44.83%   43.58%   -1.25%
==========================================
  Files          96       96
  Lines       19857    19857
==========================================
- Hits         8902     8654     -248
- Misses      10922    11187     +265
+ Partials       33       16      -17

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


Add quirk for Sonoff SWV Smart Water Valve

Proposed change

Adds support for Sonoff SWV Smart Water Valve custom cluster, which exposes a new attribute called valve_status for querying if the valve is leaking or if the water supply to the valve has stopped.
Code should hopefully should be self explanatory, the only complication is the overridden _is_manuf_specific() property in SonoffFC11Cluster class. This is required, as if the device receives an attribute read or notify zigbee command which has manufacturer_specific = True set (default if cluster's ID is within manufacturer specific range which this is), it will return UNSUPPORTED_ATTRIBUTE.
This feature was requested as part of https://github.com/zigpy/zha-device-handlers/issues/3298
Additional information

zha pull request for Home Assistant Sensors: https://github.com/zigpy/zha/pull/189
Home Assistant core pull request for language strings for sensor: https://github.com/home-assistant/core/pull/124989

Checklist

[x] The changes are tested and work correctly
[x] pre-commit checks pass / the code has been formatted using Black
[x] Tests have been added to verify that the new code works

Nice! I was testing a similar change using the Quirks Builder v2 and exposing the state as a sensor.
I'll probably open a PR on Monday, as I wrote most of the code already, but I've left some comments in this PR.

Hi @fgsch
Thanks for your review comments, much appreciated! Given you've gone to the work of writing yours, I would definetly push it up. I wasn't aware of Quirks Builder v2 (with this being my first quirk), but looking at API it looks very nice and I guess it allows you to avoid a ZHA change also? What might be a pain is exporting two not one sensors like I have (which in my personal opinion makes more sense for these sensors).

Hi @fgsch
Thanks for your review comments, much appreciated! Given you've gone to the work of writing yours, I would definetly push it up. I wasn't aware of Quirks Builder v2 (with this being my first quirk), but looking at API it looks very nice and I guess it allows you to avoid a ZHA change also? What might be a pain is exporting two not one sensors like I have (which in my personal opinion makes more sense for these sensors).

My original plan was to expose the valve status as a sensor, but I've been struggling to do so as I envisioned.
I don't know if it's me or if it's just not possible, but unfortunately, no other zha quirks are using this.
Might be a good time to ask around.
As for my PR, I sort of ran out of time today. I will try to do it tomorrow.

And finally, here's my PR: https://github.com/zigpy/zha-device-handlers/pull/3346
I managed to get the sensor working as I wanted with help from some devs in discord. Unfortunately, it is not yet possible to do the same with binary sensors.

Hi, does this feature work? Where can I get the full file?

Hi @fgsch
Apologies for the big delay in getting back to you since you posted your pull request.
Based on your commit, I think I've come up with a clean way of handling the binary sensors instead of enum approach. Please let me know what you think.
Looks like there are still some issues with test line coverage - need to work out how to write a test for V2 quirk interface next.

I left some comments, but it looks good. I won't be able to test it until this weekend, though.

I'm doing something wrong, because with the quirk file, it doesn't show me the water flow. What could it be?

Hi @RogerSero
To clarify, this PR/quirk only adds the sensors for diagnostic of the valve (e.g. water supply or leak). I can see from your screenshot that this appears to be working. If you want to see the sensor names to appear correctly, then https://github.com/zigpy/zha/pull/234 will also be required.
As it sounds like you are looking for water flow rate in particular, there is a separate PR implementing that on ZHA repository, please see here: https://github.com/zigpy/zha/pull/187. I likely confused you with my screenshot above - as I had both patches locally when testing this. This implements the whole Flow cluster (with it being a Zigbee standard cluster) and therefore we don't require any special device side quirk like this patch does for the additional sensors.

I've tested this quickly, and it works as expected.
If you could address https://github.com/zigpy/zha-device-handlers/pull/3340#discussion_r1802032875 I think I'd be ready to go from my POV.


global write-lock held for two minutes by RPC next_receiving_address.

I've begun experimenting with logging duration that the GlobalState write-lock is held for and I encountered a behavior I can't yet explain.
Anything that holds the write-lock effectively blocks processing for all other tasks until it completes, including the RPC server.  So shorter is always better.
Some of the rpc timeout behavior observed and documented in issue #219 made me think that the write-lock is probably being held too long.  To find out where, I modifed the AtomicRw to log a duration and the caller location when the write-lock-guard gets dropped, but only if the duration exceeds 100 milliseconds.  So we only log slow processes.
I then followed the steps in issue #219 and observed an rpc timeout after visiting the Receive screen.   Some time later, I found in the log this warning:
2024-11-02T21:41:48.416065456Z  WARN ThreadId(126) RPC{rpc.trace_id=00 rpc.deadline=2024-11-02T21:39:56.658040570Z otel.kind="server" otel.name="RPC.next_receiving_address"}: neptune_core::locks::tokio::atomic_rw: write-lock held for 121.75746 seconds. (exceeds max: 100 milli)  location: /home/danda/neptune-core/src/rpc_server.rs:621:64

The referenced code that acquires the write-lock is:
    async fn next_receiving_address(
        mut self,
        _context: tarpc::context::Context,
        key_type: KeyType,
    ) -> ReceivingAddress {
        let mut global_state_mut = self.state.lock_guard_mut().await;

        let address = global_state_mut
            .wallet_state
            .next_unused_spending_key(key_type)
            .to_address();

        // persist wallet state to disk
        global_state_mut.persist_wallet().await.expect("flushed");

        address
    }

It is very strange to me that this code is holding the write-lock for 2 minutes.
(note: after an hour running a node and mining 2 blocks and attempting to send a tx there are less than 10 warnings in the log, and the rest are under 1 sec, so 2 minutes is a huge anomaly).
Observations:

The elapsed 2 minutes occurs after we already acquired the lock.  So it does not include any time spent waiting to acquire.  It only includes actual processing time (or sleeps) until it is released.  And it should take only a few milliseconds, if that.
the write-lock is held across a call to next_unused_spending_key() and persist_wallet(), so seemingly one of those is the offender.
The primary work in next_unused_spending_key() is deriving a Generation address at index 0.  This is done over and over again in tests and never takes 2 minutes (that I have ever observed).
persist_wallet() may be a suspect.  Perhaps the DB could be doing some kind of compaction or maintenance?   strange though for a DB that has just been created and should be tiny.
If we acquired the lock separately for both calls then it would be obvious which causes it.  (If we can ever recreate)
hypothesis: perhaps a proving task was executing at this time and hogging so much CPU that this task didn't make progress.   2 minutes seems awfully long though and machine (mjolnir) did not seem to be in any kind of frozen state.

For now my plan is to complete development of the lock logging feature and just monitor logs for any slow-write-lock warnings.  Maybe this is not repeatable.
also: I noticed that this particular RPC call logged warnings of up to 0.3 secs on the other 2 nodes.   Maybe deriving the generation address is somehow more expensive than I would think.

The persist_wallet() call is seeming more likely to be the culprit.
I jut ran:
cargo +nightly test  --features log-slow-write-lock rpc_server -- --nocapture
The output includes this warning:
2024-11-04T02:31:47.278758Z  WARN send_to_many_test:Constructing transaction: neptune_core::locks::tokio::atomic_rw: write-lock held for 2.04554 seconds. (exceeds max: 0.001 secs)  location: src/models/state/mod.rs:196:31
The code at indicated line is:
self.lock_guard_mut().await.flush_databases().await
So here we have an isolated instance where flushing the databases took 2 seconds during the rpc server send_to_many_test.   This is much less than 2 minutes, but still unexpectedly long for a nearly empty db.

related:
2024-11-04T04:29:17.582661159Z ERROR ThreadId(127) RPC{rpc.trace_id=00 rpc.deadline=2024-11-04T04:26:29.418856282Z otel.kind="server" otel.name="RPC.send"}:Constructing transaction:RPC{rpc.trace_id=00 rpc.deadline=2024-11-04T04:29:17.579245784Z otel.kind="server" otel.name="RPC.next_receiving_address"}: tarpc::server::in_flight_requests: DeadlineExceeded
2024-11-04T04:29:20.446725646Z ERROR ThreadId(02) RPC{rpc.trace_id=00 rpc.deadline=2024-11-04T04:29:20.443506379Z otel.kind="server" otel.name="RPC.next_receiving_address"}: tarpc::server::in_flight_requests: DeadlineExceeded
2024-11-04T04:29:21.564633677Z ERROR ThreadId(127) RPC{rpc.trace_id=00 rpc.deadline=2024-11-04T04:29:21.562294527Z otel.kind="server" otel.name="RPC.dashboard_overview_data"}: tarpc::server::in_flight_requests: DeadlineExceeded

note that tarpc cancels tasks on the server when a client-provided deadline is exceeded.  By default that deadline is 10 seconds.
observations:

these rpc calls should not be exceeding 10 secs on the server, especially since I am not seeing warnings about write-lock being held for that long.
somehow next-receiving-address was able to execute 2 minutes as reported in OP.  That exceeds the 10 secs.  I guess this is possible because the rpc task did not call an await during those 2 mins, and thus no chance to be cancelled.

A specific cause has not been identified and this has not been duplicated, but the fixes for #244 make the system overall faster and more responsive for RPC requests.  closing this, and we can open new issues for any further perf issues observed.


Add fallback modifier

Closes #24
I have yet to test this deeply (I intend to build a PoC Noise Channel), this is tested with XXfallback and it seems to work correctly.
This is implemented by transferring the first message pattern into Alice pre-message (if empty), then reversing the patterns to be Bob-initialized. The other implementation option would be to have something track whether the connection is Alice or Bob initialized, but this seems like the simpler way.
In my github fork I'm working on other changes (Elligator2 support and message overhead/simulation), but this seems like the simplest one to upstream as it does not add any strange API.

Thanks for the PR! Will check out when I have a free moment, just got back from a trip.

Don't worry! I'm also quite occupied with exams and vacations so I might be quite slow to answer.


Plugin DSL should provide the ability to define a target Play platform of compatible Scala and Java versions

The old plugin allows users to provide a target Play platform. A target Play platform automatically determines compatible Scala and Java versions and uses them for the project.
model {
    components {
        play {
            targetPlatform 'play-2.4.0'
        }
    }
}

The logic that determines the compatible Scala and Java versions is available in PlayPlatformResolver and PlayMajorVersion. The Gradle user guide for the Play plugin doesn't document the feature so I am not sure if it was intended for end users.
Should the new plugin provide similar functionality or do we want users to explicitly provide the Play, Scala and Java version through the DSL without trying to be too smart? At the moment the new plugin only uses the default Scala and Java versions independent of the assigned Play version.

For the specific targetPlatform 'play-2.4.0' sort of syntax, I think, no, we don't need to support that.
I would suggest moving
https://github.com/gradle/play/blob/c1bfd9546bda50cec4ac8829691cd1016e281db4/src/main/java/com/playframework/gradle/plugins/PlayApplicationPlugin.java#L81-L88
into the extension's constructor. It's possible (but unlikely) that someone can set the default value of the property before that particular bit of code runs.
I believe the old plugin always used the current JVM as the version of Java, regardless of the version of Play, unless explicitly selected.  The new plugin doesn't need to do any better than that.
I've gone back and forth on it.  Since we need it for testing anyways, I think we should keep a short mapping of major playVersion -> specific scalaVersion and change the initial value of scalaVersion to:
scalaVersion.set(playVersion.map(play -> lookupVersionOfScalaFor(play))
Where lookupVersionOfScalaFor looks at the mapping and picks the best choice.  When we don't know which version to use with Play, we should pick some default value.
This means for users they would do:
play {
   platform.playVersion = "2.6.2"
}

And scalaVersion would automagically be selected.
How does that sound?

I've gone back and forth on it. Since we need it for testing anyways...

I implemented a simple solution for testing purposes but let me look into your comments here.

Implementation: https://github.com/gradle/play/commit/9e918652c32afb0d061b950ed708d64bdd36b012, https://github.com/gradle/play/commit/8bc6c327c93695683201b70f1e5d0332978df2d9


Restore state representation

We need to restore the state representation.
Maybe add slip the leftover time between maximum left over time and minimum one. Or do an average?

Greedy state rep is okay now