"public static" fields should be constant

This pull request is focused on resolving occurrences of Sonar rule squid:S1444 - “"public static" fields should be constant”. You can find more information about the issue here:
https://dev.eclipse.org/sonar/rules/show/squid:S1444
Please let me know if you have any questions.
Ayman Abdelghany.

@AymanDF - you have  Compilation failure in this PR.

@soninob Sorry for inconvenience, it has been fixed now.

@AymanDF - properties is a dynamic field - we are using Watchdir to identify changes in the properties file, and just might want this object to be changed.
Do you still think that this PR is needed?

@soninob In this case I don't think this PR is needed :)


Update infrastructure

Fixes #16
Also, equalizes infrastructure files with equistore and rascaline.

:books: Documentation preview :books:: https://equisolve--17.org.readthedocs.build/en/17/

@Luthaf could you do me a favor and check if the doc on gh-pages is correctly configured?


Equivalent of trpc's useUtils

https://trpc.io/docs/client/react/useUtils
One of my favorite things about tRPC is that it automatically handles your query keys in a typesafe way:
const utils = trpc.useUtils();
utils.post.all.refetch();

This way you don't have to juggle keys manually.
It looks like that zsa has a few utilities to make query keys more typesafe, but it's still a lot of boilerplate that you have to constantly synchronize:
export const QueryKeyFactory = createServerActionsKeyFactory({
  getPosts: () => ["getPosts"],
  getFriends: () => ["getFriends"],
  getPostsAndFriends: () => ["getPosts", "getFriends"],
  somethingElse: (id: string) => ["somethingElse", id],
  getRandomNumber: () => ["getRandomNumber"],
})

So it would be nice if zsa can provide an equivalent to tRPC's useUtils that would absolve the need for all of this manual work.

Hi, I totally concur that useUtils is awesome and understand your frustration with juggling keys manually.
The current recommended way to do this is you can use React Query and its useQueryClient hook. I assume you have already read the docs about this but linking it here just in case.
As for why zsa can't provide a direct equivalent - it's because you are in some way doing the defining/juggling of keys when you are defining your routes in tRPC. Since server actions aren't typed under a router, there is no way really to do a typesafe useUtils since there are no key/value pairs to work off of. Hopefully that makes sense. If you have an idea happy to hear out how it would work.
I am working on a router for zsa - will think about how maybe zsa can provide a query key factory that automatically gets synchronized based on the router types. For context, when using the router there is only one "active" server action endpoint that takes in the route key and routes the input to the corresponding function/action.
Will keep you posted. Thanks for the feedback.

Is there a reason why this was closed? Was this feature implemented already?


Video features availability limits were improved recently

Currently:
only 30 first participants can cast and see videos of each other, all the later ones will be in a voice-only chat

Improved:
Broadcasting: 30 users
Viewing: 1000 users
Listening: unlimited

Source: https://telegram.org/blog/video-1000

drafting a pull request now


Onchange event not firing when a bind is used

Describe the bug
Adding a bind to the input stops the event from 'firing'?
The example shows three input check boxes that are display.
When 'clicking' each, the onchange with the bind does not 'fire'
the onchange without the bind 'fires'
the onclick with bind 'fires'
        <RowTemplate>

                @* The onchange event does not fire when bind is used for onchange *@
                <input type="checkbox" id="myCheck" bind="context.Selected" onchange="@(e => SelectedLine(e,  context))" />

                @* The following two events fire *@
                <input type="checkbox" id="myCheck" bind="context.Selected" onclick="@(e => SelectedLineClick(e,  context))" />
                <input type="checkbox" id="myCheck" onchange="@(e => SelectedLine(e,  context))" />

<EMAIL_ADDRESS>        </RowTemplate>

Binding uses onchange events. You can read about this here:
https://docs.microsoft.com/en-us/aspnet/core/razor-components/components?view=aspnetcore-3.0#data-binding
Proposed workaround: bind to property and execute whatever code you need in property setter.

Thanks for contacting us. We believe that the question you've raised have been answered. If you still feel a need to continue the discussion, feel free to reopen it and add your comments.

By using OnInput the event is fired with binding in place.
                <RowTemplate>

                        <input type="checkbox" id="myCheck" bind="context.Selected" oninput="@(e => SelectedLineClick(e, context))" />

<EMAIL_ADDRESS>                </RowTemplate>


compact: downsample stopped making progress (compacted blocks migrated from prometheus too small)

Thanos, Prometheus and Golang version used:  Thanos image:tag v0.11.0
Object Storage Provider:  GCS
What happened:  thanos-compact downsample stopped making progress (5m incomplete, no 1h).  The situation has continued for 10 hours.
bucket UI apppears as follows:

What you expected to happen: compactor makes progress towards steady-state of downsampled data
How to reproduce it (as minimally and precisely as possible):
newly deployed compactor job against 5 months of data
compact args:
         - "compact"
         - "--log.level=info"
         - "--log.format=logfmt"
         - "--http-address=<IP_ADDRESS>:10902"
         - "--objstore.config-file=/etc/config/object-store.yaml"
         - "--data-dir=/var/thanos/compact"
         - "--consistency-delay=30m"
         - "--retention.resolution-raw=0d"
         - "--retention.resolution-5m=0d"
         - "--retention.resolution-1h=0d"
         - "--block-sync-concurrency=20"
         - "--compact.concurrency=1"
         - "--wait"

Full logs to relevant components:
Compactor iterations have settled to doing no work.  There are no warnings or errors in the logs.  Compaction operations are still happening normally.
Log for latest iteration:
Logs

E 2020-04-10T23:40:59.535995275Z level=info ts=2020-04-10T23:40:59.535727872Z caller=clean.go:50 msg="cleaning of aborted partial uploads done"

E 2020-04-10T23:40:59.535910379Z level=info ts=2020-04-10T23:40:59.535671469Z caller=fetcher.go:368 component=block.MetaFetcher msg="successfully fetched block metadata" duration=51.342219ms cached=52 returned=52 partial=0

E 2020-04-10T23:40:59.484518859Z level=info ts=2020-04-10T23:40:59.484316539Z caller=clean.go:25 msg="started cleaning of aborted partial uploads"

E 2020-04-10T23:40:59.484512229Z level=info ts=2020-04-10T23:40:59.484300199Z caller=retention.go:41 msg="optional retention apply done"

E 2020-04-10T23:40:59.484473403Z level=info ts=2020-04-10T23:40:59.484219675Z caller=fetcher.go:368 component=block.MetaFetcher msg="successfully fetched block metadata" duration=61.096018ms cached=52 returned=52 partial=0

E 2020-04-10T23:40:59.423193158Z level=info ts=2020-04-10T23:40:59.423100065Z caller=retention.go:20 msg="start optional retention"

E 2020-04-10T23:40:59.423178026Z level=info ts=2020-04-10T23:40:59.423057958Z caller=compact.go:324 msg="downsampling iterations done"

E 2020-04-10T23:40:59.422756013Z level=info ts=2020-04-10T23:40:59.422495525Z caller=fetcher.go:368 component=block.MetaFetcher msg="successfully fetched block metadata" duration=55.296998ms cached=52 returned=52 partial=0

E 2020-04-10T23:40:59.367230069Z level=info ts=2020-04-10T23:40:59.367100699Z caller=compact.go:319 msg="start second pass of downsampling"

E 2020-04-10T23:40:59.366817119Z level=info ts=2020-04-10T23:40:59.366579816Z caller=fetcher.go:368 component=block.MetaFetcher msg="successfully fetched block metadata" duration=51.449956ms cached=52 returned=52 partial=0

E 2020-04-10T23:40:59.315252887Z level=info ts=2020-04-10T23:40:59.315067975Z caller=compact.go:313 msg="start first pass of downsampling"

E 2020-04-10T23:40:59.315221167Z level=info ts=2020-04-10T23:40:59.314961081Z caller=compact.go:910 msg="compaction iterations done"

E 2020-04-10T23:40:59.213787324Z level=info ts=2020-04-10T23:40:59.213601901Z caller=compact.go:872 msg="start of compaction"

E 2020-04-10T23:40:59.195223946Z level=info ts=2020-04-10T23:40:59.195049536Z caller=compact.go:246 msg="deleting outdated block" block=01E59XWF1XDQFG2AY9TR6TVX6P

E 2020-04-10T23:40:59.174106196Z level=info ts=2020-04-10T23:40:59.173935931Z caller=compact.go:246 msg="deleting outdated block" block=01E59Q0N419Y9RAZWG2FKEBEFB

E 2020-04-10T23:40:59.156003984Z level=info ts=2020-04-10T23:40:59.155810736Z caller=compact.go:246 msg="deleting outdated block" block=01E59G5090ZVF1AX61E07W50CJ

E 2020-04-10T23:40:59.135748608Z level=info ts=2020-04-10T23:40:59.135366491Z caller=compact.go:246 msg="deleting outdated block" block=01E59996ZPQWGGQ03M007CNB4P

E 2020-04-10T23:40:59.135736558Z level=info ts=2020-04-10T23:40:59.135351688Z caller=compact.go:864 msg="start of GC"

E 2020-04-10T23:40:59.135674222Z level=info ts=2020-04-10T23:40:59.135304544Z caller=fetcher.go:368 component=block.MetaFetcher msg="successfully fetched block metadata" duration=145.544367ms cached=52 returned=52 partial=0

E 2020-04-10T23:40:58.989982600Z level=info ts=2020-04-10T23:40:58.989582621Z caller=compact.go:858 msg="start sync of metas"

Anything else we need to know:
I have not yet tried restarting the compact job.  I'll wait up to 1 day for advice in case there is something to inspect on the running instance.
I've ruled out it being a Bucket UI issue by comparing increase(thanos_compact_downsample_total) to number of downsampled blocks shown in the UI, and they match as expected.

I found a clue here:  https://github.com/thanos-io/thanos/issues/924#issuecomment-475825690
If it's so that downsample depends on age of block creation rather than time of data in the block, intuitively it is very unexpected.   For a scenario of migration or new thanos deployment, I expect downsample to reach steady-state directly, and not wait for some arbitrary time like 10 days.
output of bucket inspect:
|            ULID            |        FROM         |        UNTIL        |  RANGE   | UNTIL-DOWN |  #SERIES  |    #SAMPLES    |  #CHUNKS   | COMP-LEVEL | COMP-FAILED |    LABELS    | RESOLUTION |  SOURCE   |
|----------------------------|---------------------|---------------------|----------|------------|-----------|----------------|------------|------------|-------------|--------------|------------|-----------|
| 01E5H7MQCQ5Q86095CC1JSJ8AV | 26-12-2019 12:00:00 | 04-01-2020 12:00:00 | 216h0m0s | -176h0m0s  | 842,250   | 1,978,856,089  | 19,461,079 | 6          | false       | replica=main | 0s         | compactor |
| 01E5HEXMNMBB9VD7G9AF2PKYMM | 26-12-2019 12:00:00 | 04-01-2020 12:00:00 | 216h0m0s | 24h0m0s    | 842,250   | 408,680,338    | 3,353,612  | 6          | false       | replica=main | 5m0s       | compactor |
| 01E1JHAT0JSJEH1DY132TQCHSJ | 04-01-2020 12:00:00 | 11-01-2020 06:00:00 | 162h0m0s | -122h0m0s  | 1,283,984 | 1,930,609,501  | 20,408,144 | 5          | false       | replica=main | 0s         | sidecar   |
| 01E5HRE3P8KBGX2YA8A5Y6JG77 | 04-01-2020 12:00:00 | 11-01-2020 06:00:00 | 162h0m0s | 78h0m0s    | 1,283,984 | 400,912,055    | 3,620,979  | 5          | false       | replica=main | 5m0s       | compactor |
| 01E1JHF8SFDH32WHYEWGJFBRSA | 11-01-2020 06:00:00 | 18-01-2020 00:00:00 | 162h0m0s | -122h0m0s  | 1,224,550 | 2,142,473,325  | 21,828,033 | 5          | false       | replica=main | 0s         | sidecar   |
| 01E5HTDCZBAZN5YHRZ2SPM8YK7 | 11-01-2020 06:00:00 | 18-01-2020 00:00:00 | 162h0m0s | 78h0m0s    | 1,224,550 | 443,728,332    | 3,889,660  | 5          | false       | replica=main | 5m0s       | compactor |
| 01E1JHM71AFCVBKBYJ1JKQM527 | 18-01-2020 00:00:00 | 24-01-2020 18:00:00 | 162h0m0s | -122h0m0s  | 1,358,672 | 2,720,154,145  | 27,523,432 | 5          | false       | replica=main | 0s         | sidecar   |
| 01E5HV573WAHQXWK2CA7566BXF | 18-01-2020 00:00:00 | 24-01-2020 18:00:00 | 162h0m0s | 78h0m0s    | 1,358,672 | 561,852,910    | 4,775,070  | 5          | false       | replica=main | 5m0s       | compactor |
| 01E1JHW1SAY9QS1E0Y6SB12H4G | 24-01-2020 18:00:00 | 31-01-2020 12:00:00 | 162h0m0s | -122h0m0s  | 1,475,564 | 3,848,916,262  | 38,437,459 | 5          | false       | replica=main | 0s         | sidecar   |
| 01E5HBMTGQ3TC9KQ6ZDNPMDTRK | 24-01-2020 18:00:00 | 31-01-2020 12:00:00 | 162h0m0s | 78h0m0s    | 1,475,564 | 792,660,956    | 6,432,750  | 5          | false       | replica=main | 5m0s       | compactor |
| 01E1JJJ4C9RES8GA75T0FT0B4C | 31-01-2020 12:00:00 | 07-02-2020 06:00:00 | 162h0m0s | -122h0m0s  | 1,521,411 | 4,468,631,007  | 45,028,218 | 5          | false       | replica=main | 0s         | sidecar   |
| 01E5HKWSJKA18RNBASYHRFG4HM | 31-01-2020 12:00:00 | 07-02-2020 06:00:00 | 162h0m0s | 78h0m0s    | 1,521,411 | 944,979,833    | 7,289,023  | 5          | false       | replica=main | 5m0s       | compactor |
| 01E1JKBAYP4ER0HT6TWVH93RSY | 07-02-2020 06:00:00 | 14-02-2020 00:00:00 | 162h0m0s | -122h0m0s  | 1,626,715 | 5,411,718,898  | 54,148,298 | 5          | false       | replica=main | 0s         | sidecar   |
| 01E5HNHNVQPHWGQ0Y1QQK4YNC8 | 07-02-2020 06:00:00 | 14-02-2020 00:00:00 | 162h0m0s | 78h0m0s    | 1,626,715 | 1,143,461,079  | 8,653,028  | 5          | false       | replica=main | 5m0s       | compactor |
| 01E1JMAA1N4WZBFGD0X5TTV0AC | 14-02-2020 00:00:00 | 20-02-2020 18:00:00 | 162h0m0s | -122h0m0s  | 1,817,925 | 6,389,240,079  | 61,123,519 | 5          | false       | replica=main | 0s         | sidecar   |
| 01E5J2YK8HHAJ2A09VPBBS02G8 | 14-02-2020 00:00:00 | 20-02-2020 18:00:00 | 162h0m0s | 78h0m0s    | 1,817,925 | 1,303,198,496  | 10,177,119 | 5          | false       | replica=main | 5m0s       | compactor |
| 01E23JVTWFA0PZRQ797RRFG7PW | 20-02-2020 18:00:00 | 27-02-2020 12:00:00 | 162h0m0s | -122h0m0s  | 1,864,621 | 6,372,637,808  | 60,632,213 | 5          | false       | replica=main | 0s         | sidecar   |
| 01E5HFVW3ZHT5VYDV74TD7R89S | 20-02-2020 18:00:00 | 27-02-2020 12:00:00 | 162h0m0s | 78h0m0s    | 1,864,621 | 1,301,859,383  | 10,148,335 | 5          | false       | replica=main | 5m0s       | compactor |
| 01E2MZ47TKNCV4FNF4PAR1ZABY | 27-02-2020 12:00:00 | 05-03-2020 06:00:00 | 162h0m0s | -122h0m0s  | 2,175,374 | 7,147,287,810  | 68,169,189 | 5          | false       | replica=main | 0s         | sidecar   |
| 01E5HWDKRCSYS7G7X1MRTSRTW0 | 27-02-2020 12:00:00 | 05-03-2020 06:00:00 | 162h0m0s | 78h0m0s    | 2,175,374 | 1,466,915,641  | 11,461,348 | 5          | false       | replica=main | 5m0s       | compactor |
| 01E2TRA8T53V487JBE0PKNNDWH | 05-03-2020 06:00:00 | 07-03-2020 12:00:00 | 54h0m0s  | -14h0m0s   | 1,795,213 | 2,805,525,349  | 26,627,352 | 4          | true        | replica=main | 0s         | sidecar   |
| 01E5HJTRFBPC2PG44J5BQA170R | 05-03-2020 06:00:00 | 07-03-2020 12:00:00 | 54h0m0s  | 186h0m0s   | 1,795,213 | 572,997,620    | 5,012,678  | 4          | true        | replica=main | 5m0s       | compactor |
| 01E30HRM8FZFT4ZMHQHJSK4M5W | 07-03-2020 12:00:00 | 09-03-2020 18:00:00 | 54h0m0s  | -14h0m0s   | 1,696,303 | 2,744,497,727  | 25,622,591 | 4          | true        | replica=main | 0s         | sidecar   |
| 01E5J4SN7PHQW6Z2WQ3DAZC3Y7 | 07-03-2020 12:00:00 | 09-03-2020 18:00:00 | 54h0m0s  | 186h0m0s   | 1,696,303 | 562,270,851    | 4,858,224  | 4          | true        | replica=main | 5m0s       | compactor |
| 01E36B5J1JNK0DRQZ3KNCZ2ZGB | 09-03-2020 18:00:00 | 12-03-2020 00:00:00 | 54h0m0s  | -14h0m0s   | 1,880,277 | 2,783,596,843  | 26,819,336 | 4          | true        | replica=main | 0s         | sidecar   |
| 01E5HCVWQSC1492701AWVKM0CF | 09-03-2020 18:00:00 | 12-03-2020 00:00:00 | 54h0m0s  | 186h0m0s   | 1,880,277 | 580,895,412    | 5,115,790  | 4          | true        | replica=main | 5m0s       | compactor |
| 01E3QQCX992HCZ4KQYW5TXM1WB | 12-03-2020 00:00:00 | 18-03-2020 18:00:00 | 162h0m0s | -122h0m0s  | 2,582,554 | 8,642,036,503  | 83,457,026 | 5          | false       | replica=main | 0s         | sidecar   |
| 01E5HYZASBDP8XFC1Z7DGDWB3N | 12-03-2020 00:00:00 | 18-03-2020 18:00:00 | 162h0m0s | 78h0m0s    | 2,582,554 | 1,765,821,126  | 13,891,494 | 5          | false       | replica=main | 5m0s       | compactor |
| 01E493WE8BDZAFZG0Q8WM7DE6M | 18-03-2020 18:00:00 | 25-03-2020 12:00:00 | 162h0m0s | -122h0m0s  | 2,538,342 | 10,239,683,945 | 95,931,060 | 5          | false       | replica=main | 0s         | sidecar   |
| 01E5H8S3X6FSZNP1GN6GJMZNRZ | 18-03-2020 18:00:00 | 25-03-2020 12:00:00 | 162h0m0s | 78h0m0s    | 2,538,342 | 2,078,189,078  | 15,928,662 | 5          | false       | replica=main | 5m0s       | compactor |
| 01E4EWZTGKJ83DGRJGS4Y1GFVD | 25-03-2020 12:00:00 | 27-03-2020 18:00:00 | 54h0m0s  | -14h0m0s   | 2,031,452 | 3,528,582,958  | 33,037,601 | 4          | true        | replica=main | 0s         | sidecar   |
| 01E5J1HHD53XG3TC3V6NWAEJ8W | 25-03-2020 12:00:00 | 27-03-2020 18:00:00 | 54h0m0s  | 186h0m0s   | 2,031,452 | 716,804,692    | 6,159,897  | 4          | true        | replica=main | 5m0s       | compactor |
| 01E4MPD9FP16N3G767QBHNS5RD | 27-03-2020 18:00:00 | 30-03-2020 00:00:00 | 54h0m0s  | -14h0m0s   | 1,688,583 | 3,463,723,997  | 31,556,797 | 4          | true        | replica=main | 0s         | sidecar   |
| 01E5HHR9V8NGYBC7CTAVYX766E | 27-03-2020 18:00:00 | 30-03-2020 00:00:00 | 54h0m0s  | 186h0m0s   | 1,688,583 | 701,582,637    | 5,788,266  | 4          | true        | replica=main | 5m0s       | compactor |
| 01E4TFTZ59CS86DGQ80FEFP21J | 30-03-2020 00:00:00 | 01-04-2020 06:00:00 | 54h0m0s  | -14h0m0s   | 2,201,667 | 3,875,817,506  | 36,523,859 | 4          | true        | replica=main | 0s         | sidecar   |
| 01E5HQACS5J0RGANE2D9H40W2V | 30-03-2020 00:00:00 | 01-04-2020 06:00:00 | 54h0m0s  | 186h0m0s   | 2,201,667 | 786,975,870    | 6,748,038  | 4          | true        | replica=main | 5m0s       | compactor |
| 01E5096G1P88MBXNATDFDPNNRG | 01-04-2020 06:00:00 | 03-04-2020 12:00:00 | 54h0m0s  | -14h0m0s   | 2,316,976 | 3,964,484,856  | 37,540,413 | 4          | false       | replica=main | 0s         | sidecar   |
| 01E5HS781NM79E3CT9PBN7GKPR | 01-04-2020 06:00:00 | 03-04-2020 12:00:00 | 54h0m0s  | 186h0m0s   | 2,316,976 | 805,786,196    | 6,953,904  | 4          | false       | replica=main | 5m0s       | compactor |
| 01E526VK93N0JRPNZPR5Y4TNC7 | 03-04-2020 12:00:00 | 04-04-2020 06:00:00 | 18h0m0s  | 22h0m0s    | 1,670,889 | 1,309,978,265  | 11,885,519 | 3          | false       | replica=main | 0s         | sidecar   |
| 01E544MJZP1HD9NCB2YS6SWRKJ | 04-04-2020 06:00:00 | 05-04-2020 00:00:00 | 18h0m0s  | 22h0m0s    | 1,571,817 | 1,250,676,619  | 11,341,306 | 3          | false       | replica=main | 0s         | sidecar   |
| 01E54S5ZMRB4F0SYSX526ZJW2C | 05-04-2020 00:00:00 | 05-04-2020 06:00:00 | 6h0m0s   | 34h0m0s    | 1,470,490 | 431,519,296    | 4,076,913  | 2          | true        | replica=main | 0s         | sidecar   |
| 01E55DS0C1SM84CQ0MBZQHW27Z | 05-04-2020 06:00:00 | 05-04-2020 12:00:00 | 6h0m0s   | 34h0m0s    | 1,489,597 | 414,850,792    | 4,112,792  | 2          | true        | replica=main | 0s         | sidecar   |
| 01E562BSM2MCZZEMT1WWN566QE | 05-04-2020 12:00:00 | 05-04-2020 18:00:00 | 6h0m0s   | 34h0m0s    | 1,307,143 | 415,763,614    | 3,647,737  | 2          | true        | replica=main | 0s         | sidecar   |
| 01E5807BMMTQQQ3606RNFTHAMQ | 05-04-2020 18:00:00 | 06-04-2020 12:00:00 | 18h0m0s  | 22h0m0s    | 1,883,384 | 948,306,057    | 9,699,822  | 3          | false       | replica=main | 0s         | sidecar   |
| 01E5H5RD5F8E8BG1RBR378W0N9 | 06-04-2020 12:00:00 | 08-04-2020 00:00:00 | 36h0m0s  | 4h0m0s     | 2,062,179 | 2,651,552,612  | 24,819,496 | 3          | false       | replica=main | 0s         | compactor |
| 01E5H6MFM2A9QSMCSX2JK441T8 | 08-04-2020 00:00:00 | 10-04-2020 00:00:00 | 48h0m0s  | -8h0m0s    | 2,207,280 | 3,711,359,114  | 34,641,807 | 3          | false       | replica=main | 0s         | compactor |
| 01E5HDVZSCJNRGWJ301YTG4FKT | 08-04-2020 00:00:00 | 10-04-2020 00:00:00 | 48h0m0s  | 192h0m0s   | 2,207,280 | 755,607,249    | 6,784,993  | 3          | false       | replica=main | 5m0s       | compactor |
| 01E5J5K35WTZG3HSZYMKS2359K | 10-04-2020 00:00:00 | 10-04-2020 08:00:00 | 8h0m0s   | 32h0m0s    | 1,835,435 | 650,597,179    | 6,304,551  | 2          | false       | replica=main | 0s         | compactor |
| 01E5JS6ZF9VYXNK7154EJ416B1 | 10-04-2020 08:00:00 | 10-04-2020 16:00:00 | 8h0m0s   | 32h0m0s    | 1,728,608 | 607,543,525    | 5,717,426  | 2          | false       | replica=main | 0s         | compactor |
| 01E5JQD5TQZ5YGXXHD3HKNJCYQ | 10-04-2020 16:00:00 | 10-04-2020 18:00:00 | 2h0m0s   | 38h0m0s    | 1,193,203 | 140,641,986    | 1,193,203  | 1          | false       | replica=main | 0s         | sidecar   |
| 01E5JY8XYT8KXQXW33B8E2TQV8 | 10-04-2020 18:00:00 | 10-04-2020 20:00:00 | 2h0m0s   | 38h0m0s    | 1,177,306 | 138,788,835    | 1,177,306  | 1          | false       | replica=main | 0s         | sidecar   |
| 01E5K54N6SY1CJE6FNM8AVCENF | 10-04-2020 20:00:00 | 10-04-2020 22:00:00 | 2h0m0s   | 38h0m0s    | 1,191,472 | 136,474,581    | 1,191,472  | 1          | false       | replica=main | 0s         | sidecar   |
| 01E5KC0E27VQDVGNZ458NESZ3D | 10-04-2020 22:00:00 | 11-04-2020 00:00:00 | 2h0m0s   | 38h0m0s    | 1,312,200 | 140,390,543    | 1,312,200  | 1          | false       | replica=main | 0s         | sidecar   |

The downsample seems to really be stuck.

there is a period from Apr 3 - 7 for which 5m interval remains unpopulated, after several days (yet 5m downsampling continues normally from Apr 8)
UNTIL duration for 5m buckets remain unchanged, and round values like 24h0m0s, and 78h0m0s

I noticed that the GC cycle deletes the same 4 outdated blocks on every iteration, which seems suspicious
yet there are no errors coming from objstore, GC, or sync meta operations according to the metrics
E 2020-04-12T23:50:59.323245199Z level=info ts=2020-04-12T23:50:59.323137287Z caller=compact.go:864 msg="start of GC"

E 2020-04-12T23:50:59.323341866Z level=info ts=2020-04-12T23:50:59.323238864Z caller=compact.go:246 msg="deleting outdated block" block=01E59996ZPQWGGQ03M007CNB4P

E 2020-04-12T23:50:59.341408518Z level=info ts=2020-04-12T23:50:59.341189056Z caller=compact.go:246 msg="deleting outdated block" block=01E59G5090ZVF1AX61E07W50CJ

E 2020-04-12T23:50:59.359361924Z level=info ts=2020-04-12T23:50:59.35917706Z caller=compact.go:246 msg="deleting outdated block" block=01E59Q0N419Y9RAZWG2FKEBEFB

E 2020-04-12T23:50:59.376171868Z level=info ts=2020-04-12T23:50:59.375934287Z caller=compact.go:246 msg="deleting outdated block" block=01E59XWF1XDQFG2AY9TR6TVX6P

the problem persists after upgrading Thanos to v0.12.0-rc.1

I ran block verify, it is reporting an overlap between one 8h block and four 2h blocks:
level=warn ts=2020-04-13T03:48:30.537002524Z caller=overlapped_blocks.go:43 msg="found overlapped blocks" group=0@4233639831006398026 overlap="
[mint:<PHONE_NUMBER>000, maxt:<PHONE_NUMBER>000, range: 2h0m0s, blocks: 2]:
    <ulid: 01E5RSG6R668NAZESSQZED1TD7, mint:<PHONE_NUMBER>000, maxt:<PHONE_NUMBER>000, range: 8h0m0s>,
    <ulid: 01E5R9Y2FFGXWAKPBQ4BGN925Q, mint:<PHONE_NUMBER>000, maxt:<PHONE_NUMBER>000, range: 2h0m0s>
[mint:<PHONE_NUMBER>000, maxt:<PHONE_NUMBER>000, range: 2h0m0s, blocks: 2]:
    <ulid: 01E5RSG6R668NAZESSQZED1TD7, mint:<PHONE_NUMBER>000, maxt:<PHONE_NUMBER>000, range: 8h0m0s>,
    <ulid: 01E5RGSSSXDTNA379XN3EVQYZ5, mint:<PHONE_NUMBER>000, maxt:<PHONE_NUMBER>000, range: 2h0m0s>
[mint:<PHONE_NUMBER>000, maxt:<PHONE_NUMBER>000, range: 2h0m0s, blocks: 2]:
    <ulid: 01E5RSG6R668NAZESSQZED1TD7, mint:<PHONE_NUMBER>000, maxt:<PHONE_NUMBER>000, range: 8h0m0s>,
    <ulid: 01E5QW6MNFRSQEQ684CBK60CK2, mint:<PHONE_NUMBER>000, maxt:<PHONE_NUMBER>000, range: 2h0m0s>
[mint:<PHONE_NUMBER>000, maxt:<PHONE_NUMBER>000, range: 2h0m0s, blocks: 2]:
    <ulid: 01E5RSG6R668NAZESSQZED1TD7, mint:<PHONE_NUMBER>000, maxt:<PHONE_NUMBER>000, range: 8h0m0s>,
    <ulid: 01E5R32C6EXB1DRE58D4VB70Q4, mint:<PHONE_NUMBER>000, maxt:<PHONE_NUMBER>000, range: 2h0m0s
"

I'm now trying to read the downsample.go code to understand why there might be gaps in 5h data and no 1h data.
Since there are no errors in thanos-compact logs, and since "start first pass of downsampling" is emitted and "downloaded block" is not, it must be due to normal exit of the 2nd loop in downsampleBucket() (or all iterations are continue'd).
https://github.com/thanos-io/thanos/blob/0aa995458671b40b5ce7a10a9741f45230324a60/cmd/thanos/downsample.go#L190-L213
Now I understand it's due to the DownsampleRange check.  Downsample to 5m requires >= 40h source block, and downsample to 1h requires >= 7d source block.
Next, what is preventing compaction to these minimum block sizes?

This comment in the code is concerning.  Does it mean that compactions done externally by prometheus-server and migrated via --shipper.upload-compacted may never meet the block size threshold for downsampling?
@GiedriusS @bwplotka after several days of diagnosing this myself, I ask for some help 🙏
https://github.com/thanos-io/thanos/blob/0aa995458671b40b5ce7a10a9741f45230324a60/cmd/thanos/downsample.go#L204-L207

after more than 8 days, the situation persists
it's not a good story for migration of existing prometheus deployments to Thanos
expected:  deploy sidecar, migrate existing blocks with shipper.upload_compacted, deploy remaining thanos components, enable query.auto-downsampling --> profit
observed:  slow graph queries vs. prometheus-server for long time ranges

What exactly queries you mean? What would help you? Start downsampling quicker?
Are you sure it's a resolution that makes those queries slow?

@bwplotka in the comment above I pointed to the compactor source code which states a bad assumption:  "// NOTE(fabxc): this must match width at which block size the compactor creates downsampled blocks. Otherwise we may never downsample some data."  Note the word "never".   It's a bug in my opinion, or at least something that will hurt users doing migration, which is a common use case.
Is there a technical reason why data from 5 months ago is not downsampled to 1h?  It's only because the code assumes that thanos-compact did the compaction with a certain block size.  So users migrating compacted blocks from prometheus are left without 1h intervals.
Are you saying that 1h interval is not important for graphing queries over long time ranges?

Why migrated data is not compacted to 2w or 8d blocks then?

I'm new to Thanos and details of the compactor strategy don't seem to be documented, so I'm unsure what normal is.
The older compacted blocks came from prometheus as size 7d.  Should I expect compactor to merge those into 2w blocks eventually?  How does compactor determine when to do that?  (I see that block inspect has a UNTIL-DOWN field, but not a UNTIL-COMP field.)

I learned that compaction is done by the Prometheus library.

I opened #2495 about whether thanos can be more helpful to users about compaction.failed blocks.

Awesome! This sounds like bug on Thanos , we never really seen compaction failed blocks, so while we handle them natually as Prometheus would, we might improve the handling of those (:
Can we close this and keep the discussion in the single issue? https://github.com/thanos-io/thanos/issues/2495
This is very useful!

@bwplotka please re-open this issue
even after correcting all compaction.failed blocks, thanos-compact has reached steady state without filling in 1h data
Again, it's because the code is assuming that thanos-compact did the compaction at a certain size.  In our case blocks of size 7d were migrated from prometheus, and they are not being further compacted to reach the 10d minimum.

would it be reasonable to add thanos-compact flags to adjust the downsample minimum block sizes?
Then I can set the minimum size for 1h downsample to 7d, and be done with it.

more detail on the large compaction blocks migrated from prometheus:

duration:  162h
compaction level:  5

It appears that the default compaction strategy of prometheus-server is to compact every 3 adjacent blocks.  Hence 2h original block (level 1) * 3 * 3 * 3 * 3 yields 162h level 5.
(thanos-compact seems to have a different compaction strategy, 2h -> 8h -> 2d -> ...)
162h is 6.75 days, which does not meet the 10d minimum for 1h downsample
thanos-compact is observed not to compact these blocks further (for example, I have a 3 month sequence of these 162h blocks that does not advance to level 6)
I propose lowering the minimum size for 1h downsample from 10d to 6d, to accommodate users migrating compacted blocks from prometheus-server.  (Or else let it be set by a flag.)  @bwplotka

👍
I am also facing the same issue.. There is no compaction failure, but 1h down-sampling is just not happening for 7d blocks that are migrated from prometheus using --shipper.upload_compacted flag
No issues with 5m down-sampling though.

Waiting for https://github.com/thanos-io/thanos/pull/2518 to go through.. It would be great if this issue is fixed


Is there a way to save the current settings to restore when I fiddle with it too much?

I tried the --print-current option, which seemed to be the obvious use, but got this:
hal_j@home ~ % sudo msi-rgb --print-current
Enter Nuclear Launch Code Now:
error: The following required arguments were not provided:
    <RED>
    <GREEN>
    <BLUE>

USAGE:
    msi-rgb <RED> <GREEN> <BLUE> --base-port <BASEPORT> --blink <BLINK> --print-current --duration <STEPDURATION>

For more information try --help
hal_j@home ~ % msi-rgb -V
msi-rgb 0.1.0

--print-current is not for printing the current settings, but rather the current values of registers in the SuperIO for diagnostic purposes.
You can get print-current output something by also applying some changes, but bear in mind that the output is nothing that you can easily recover any information from.
If anything goes awry you can reset the SIO state by draining the power from your system (flip the switch on PSU, hold the power on button for a few seconds, flip the PSU switch back, power on as normal).


Confusing default appear prop on Slide API

Hi, I just spent quite a while attempting to figure out why the animation from <Slide /> was occurring on initial page load. It mentions in the docs that it inherits from the Transition props, so when I followed that link I saw the appear prop, which controls this behavior. But it mentions that the default is false, so I was left confused why it seemed to be set to true. This was because it is getting overridden by MUI in the line below:
https://github.com/mui-org/material-ui/blob/ef822e73bc72ce2cc2c5a0a5ffc8485fd85c7cee/packages/material-ui/src/Slide/Slide.js#L78
I would like to suggest either keeping the defaults from React Transition Group, or documenting in the MUI Docs that the default for MUI is actually true for the appear prop to hopefully mitigate confusion for other developers.

Thanks for the feedback, already fixed in v5: https://next.material-ui.com/api/slide/


[Snyk] Upgrade axios from 0.26.1 to 1.2.0

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to upgrade axios from 0.26.1 to 1.2.0.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

Warning: This is a major version upgrade, and may be a breaking change.

The recommended version is 11 versions ahead of your current version.
The recommended version was released 22 days ago, on 2022-11-22.

Release notes

Package name: axios

1.2.0 - 2022-11-22[1.2.0] - 2022-11-10
Changed

changed: refactored module exports #5162
change: re-added support for loading Axios with require('axios').default #5225

Fixed

fix: improve AxiosHeaders class #5224
fix: TypeScript type definitions for commonjs #5196
fix: type definition of use method on AxiosInterceptorManager to match the the README #5071
fix: __dirname is not defined in the sandbox #5269
fix: AxiosError.toJSON method to avoid circular references #5247
fix: Z_BUF_ERROR when content-encoding is set but the response body is empty #5250

Refactors

refactor: allowing adapters to be loaded by name #5277

Chores

chore: force CI restart #5243
chore: update ECOSYSTEM.md #5077
chore: update get/index.html #5116
chore: update Sandbox UI/UX #5205
chore:(actions): remove git credentials after checkout #5235
chore(actions): bump actions/dependency-review-action from 2 to 3 #5266
chore(packages): bump loader-utils from 1.4.1 to 1.4.2 #5295
chore(packages): bump engine.io from 6.2.0 to 6.2.1 #5294
chore(packages): bump socket.io-parser from 4.0.4 to 4.0.5 #5241
chore(packages): bump loader-utils from 1.4.0 to 1.4.1 #5245
chore(docs): update Resources links in README #5119
chore(docs): update the link for JSON url #5265
chore(docs): fix broken links #5218
chore(docs): update and rename UPGRADE_GUIDE.md to MIGRATION_GUIDE.md #5170
chore(docs): typo fix line #856 and #920 #5194
chore(docs): typo fix #800 #5193
chore(docs): fix typos #5184
chore(docs): fix punctuation in README.md #5197
chore(docs): update readme in the Handling Errors section - issue reference #5260 #5261
chore: remove \b from filename #5207
chore(docs): update CHANGELOG.md #5137
chore: add sideEffects false to package.json #5025

Contributors to this release

Maddy Miller
Amit Saini
ecyrbe
Ikko Ashimine
Geeth Gunnampalli
Shreem Asati
Frieder Bluemle
윤세영
Claudio Busatto
Remco Haszing
Dmitriy Mozgovoy
Csaba Maulis
MoPaMo
Daniel Fjeldstad
Adrien Brunet
Frazer Smith
HaiTao
AZM
relbns

1.2.0-alpha.1 - 2022-11-10[1.2.0-alpha.1] - 2022-11-10
Changed

changed: refactored module exports #5162
change: re-added support for loading Axios with require('axios').default #5225

Fixed

fix: improve AxiosHeaders class #5224
fix: TypeScript type definitions for commonjs #5196
fix: type definition of use method on AxiosInterceptorManager to match the the README #5071
fix: __dirname is not defined in the sandbox #5269
fix: AxiosError.toJSON method to avoid circular references #5247
fix: Z_BUF_ERROR when content-encoding is set but the response body is empty #5250

Refactors

refactor: allowing adapters to be loaded by name #5277

Chores

chore: force CI restart #5243
chore: update ECOSYSTEM.md #5077
chore: update get/index.html #5116
chore: update Sandbox UI/UX #5205
chore:(actions): remove git credentials after checkout #5235
chore(actions): bump actions/dependency-review-action from 2 to 3 #5266
chore(packages): bump loader-utils from 1.4.1 to 1.4.2 #5295
chore(packages): bump engine.io from 6.2.0 to 6.2.1 #5294
chore(packages): bump socket.io-parser from 4.0.4 to 4.0.5 #5241
chore(packages): bump loader-utils from 1.4.0 to 1.4.1 #5245
chore(docs): update Resources links in README #5119
chore(docs): update the link for JSON URL #5265
chore(docs): fix broken links #5218
chore(docs): update and rename UPGRADE_GUIDE.md to MIGRATION_GUIDE.md #5170
chore(docs): typo fix line #856 and #920 #5194
chore(docs): typo fix #800 #5193
chore(docs): fix typos #5184
chore(docs): fix punctuation in README.md #5197
chore(docs): update readme in the Handling Errors section - issue reference #5260 #5261
chore: remove \b from filename #5207
chore(docs): update CHANGELOG.md #5137
chore: add sideEffects false to package.json #5025

Contributors to this release

Maddy Miller
Amit Saini
ecyrbe
Ikko Ashimine
Geeth Gunnampalli
Shreem Asati
Frieder Bluemle
윤세영
Claudio Busatto
Remco Haszing
Dmitriy Mozgovoy
Csaba Maulis
MoPaMo
Daniel Fjeldstad
Adrien Brunet
Frazer Smith
HaiTao
AZM
relbns

1.1.3 - 2022-10-15Added
Added custom params serializer support #5113
Fixed
Fixed top-level export to keep them in-line with static properties #5109
Stopped including null values to query string. #5108
Restored proxy config backwards compatibility with 0.x #5097
Added back AxiosHeaders in AxiosHeaderValue #5103
Pin CDN install instructions to a specific version #5060
Handling of array values fixed for AxiosHeaders #5085
Chores
docs: match badge style, add link to them #5046
chore: fixing comments typo #5054
chore: update issue template #5061
chore: added progress capturing section to the docs; #5084
Contributors to this release

Jason Saayman
scarf
Lenz Weber-Tronic
Arvindh
Félix Legrelle
Patrick Petrovic
Dmitriy Mozgovoy
littledian
ChronosMasterOfAllTime
Salman Shaikh

1.1.2 - 2022-10-07Fixed

Fixed broken exports for UMD builds.

Contributors to this release

Jason Saayman

1.1.1 - 2022-10-07Fixed

Fixed broken exports for common js. This fix breaks a prior fix, I will fix both issues ASAP but the commonJS use is more impactful.

Contributors to this release

Jason Saayman

1.1.0 - 2022-10-06Fixed

Fixed missing exports in type definition index.d.ts #5003
Fixed query params composing #5018
Fixed GenericAbortSignal interface by making it more generic #5021
Fixed adding "clear" to AxiosInterceptorManager #5010
Fixed commonjs & umd exports #5030
Fixed inability to access response headers when using axios 1.x with Jest #5036

Contributors to this release

Trim21
Dmitriy Mozgovoy
shingo.sasaki
Ivan Pepelko
Richard Kořínek

1.0.0 - 2022-10-04 Read more

1.0.0-alpha.1 - 2022-05-31 Read more

0.27.2 - 2022-04-27Fixes and Functionality:

Fixed FormData posting in browser environment by reverting #3785 (#4640)
Enhanced protocol parsing implementation (#4639)
Fixed bundle size

0.27.1 - 2022-04-26Fixes and Functionality:

Removed import of url module in browser build due to huge size overhead and builds being broken (#4594)
Bumped follow-redirects to ^1.14.9 (#4615)

0.27.0 - 2022-04-25

0.26.1 - 2022-03-09

    from axios GitHub release notes

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:
🧐 View latest project report
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

Bumped in a separate PR


Cleanup + missing rust query + wgsl support

Neovim has updated some type signatures, so I updated them too here.
Also regtype = 'c' causes errors for me, so I changed it to regtype = 'v', which seems to be what we want -- see: https://neovim.io/doc/user/builtin.html#getregtype() . I am not sure when this was changed in Neovim recently, or if this code has always been wrong? (Wrong in the sense that it maybe should have been 'v' technically, although it definitely did accept 'c' previously.)
(Note: I haven't yet tested this in older versions of Neovim)
Finally I added a missing rust query and wgsl support in separate commits.

I sure hope this gets merged soon. Have had to disable the plugin completely until then.

@Danielkonge Can you please rebase onto the current master? There have been a couple of changes, including changing the c to v. That part confuses me though. According to the documentation the acceptable values are the same as in setreg(), which has both c and v as synonyms.

I rebased onto the current master now.

Merged, thank you very much.

is true, then we should maybe report this as an issue upstream.

It's a change in master over at Neovim from a few days ago. They changed the opts argument of vim.highlight.range() to where the regtype string conforms to getregtype() instead of  setreg(). I did not test with the nightly builds, so this went past me.


.eh_frame: Add Parca Demo's test cpp binary and output

As discussed in the meeting, the first milestone for the .eh_frame unwinding project is to be able to unwind the cpp binary we use for testing.
I am adding it here to make testing more straightforward, as well as the generated tables. They don't include the offset information yet, but it's still valuable to ensure that the DWARF parsing is correct as we continue developing this feature.
Later on, we can add more test binaries, with their respective tables, generate them in CI and ensure that they are the same that we have committed (this technique is called snapshot/approval tests)

Thanks :+1:


Add an EXCLUDES_LIST param to job generators

Adds a parameter that allows a user to exclude certain configurations from being regenerated
Closes: #2045
Signed-off-by: Morgan Davies<EMAIL_ADDRESS>

Tested this with a test generator

https://ci.adoptopenjdk.net/job/build-scripts/job/utils/job/alpha_pipeline_jobs_generator/17/ tests EXCLUDES_LIST populated with {    "x64Mac": [        "hotspot",        "openj9"    ] }. These platforms were not regenerated as expected

10:18:13  [INFO] Regenerating: x64Mac
[Pipeline] echo
10:18:13  [INFO] Regenerating variant x64Mac: hotspot...
[Pipeline] echo
10:18:13  [INFO] FOUND MATCH! buildConfiguration key: x64Mac and config file key: x64Mac
[Pipeline] echo
10:18:13  [INFO] Excluding mac: hotspot from jdk8u regeneration due to it being in the EXCLUDES_LIST...
[Pipeline] echo
10:18:13  [INFO] Regenerating variant x64Mac: openj9...
[Pipeline] echo
10:18:13  [INFO] FOUND MATCH! buildConfiguration key: x64Mac and config file key: x64Mac
[Pipeline] echo
10:18:13  [INFO] Excluding mac: openj9 from jdk8u regeneration due to it being in the EXCLUDES_LIST...

https://ci.adoptopenjdk.net/job/build-scripts/job/utils/job/alpha_pipeline_jobs_generator/18/console tests EXCLUDES_LIST populated with {    "x64MacXL": [       "openj9"    ] }. This platform also was not regenerated as expected:

10:26:10  [INFO] Regenerating: x64MacXL
[Pipeline] echo
10:26:10  [INFO] Regenerating variant x64MacXL: openj9...
[Pipeline] echo
10:26:10  [INFO] FOUND MATCH! buildConfiguration key: x64MacXL and config file key: x64MacXL
[Pipeline] echo
10:26:10  [INFO] Excluding mac: openj9 from jdk8u regeneration due to it being in the EXCLUDES_LIST...

This is ready for review

@AdamBrousseau @andrew-m-leonard Could I get reviews please?

@AdamBrousseau See https://github.com/AdoptOpenJDK/openjdk-build/issues/2045#issuecomment-685617366. Those are the two use cases I identified that I thought would be most appropriate to resolve your issue. Short of forking/branching your own config files, I'm not sure how else you could keep in sync. Unless I'm missing something or misunderstanding your issue?

run tests

run tests

@AdamBrousseau Could I get your review please?

Couple of changs - also does this need to go in before next week's release?  Else it'll have to wait.

Unless @AdamBrousseau needs to it be in for the OpenJ9 release, it can wait until afterwards

No rush on my side.

@M-Davies I think the comments also need addressing?

@karianna They've been addressed. Just waiting for https://ci.adoptopenjdk.net/job/build-scripts/job/utils/job/alpha_pipeline_jobs_generator/49/console to finish testing the changes to confirm everyone still works ok. Once it finishes (and hopefully passes), I could use a re-review


Discrimination game on Imagenet

A draft of a discrimination game with image data.
Input is passed as a text file with paths to each image. A simple script (get_img_paths.py) task as input a list of folders and generate all the paths to JPEG images in each (sub)folder.
Common vision architecture (resnet, densenet etc) from torchvision models are used as preprocessing modules for Sender and Receiver.
Minimum working command launched from EGG home directory:
python -m egg.zoo.rl.main --data egg/zoo/rl/<path_to_txt_file_with_image_paths> --batch_size=32 --random_seed=1 --vocab_size=15 --max_len=3 --n_epochs=5

python -m torch.distributed.launch --use_env --nproc_per_node=2  egg/zoo/rl/main.py  ... --fp16

to speed up things/unlock larger batches


Autogenerated lua documentation

The disconnect between implementation and documentation is destined to repeatedly get out of sync. Ideally documentation could be attached to the implementation and extracted by a tool. Bonus points are available to a solution that allows the lark command to be used to browse docs (possibly through an embedded interpreter).

[x] collect a list of documentation tools: LuaDoc, annotate, ???
[x] choose an existing tool or decide to hand-roll one: write a simple annotation based dsl.
[ ] switch documentation over.
[ ] setup generation of static HTML/Markdown.

Another desirable result from a documentation solution would be the ability to browse task documentation using the lark command. An annotation based solution seems like it would work the best for this situation.

This issue was closed accidentally by #20.

I've started working on a static html generator for the lua doc module. But I'm realizing that it may be simpler in this regard if #24 did not include the entire "lark.task" module in the lark.task field. I think it should just include an alias to the create() function.
There is a potential problem generating documentation recursively on nested objects/functions. It's not entirely clear how big of a problem this is. And, if lark.task is declared as a variable then it can be omitted from any recursive documentation gathering.


Add an order field to metered feature

When displaying a group of plan with a given set of features, it would be nice if there was an order field for display purposes and perhaps a flag which determines whether that feature is enabled for that.
Plan 1

Feature 1 (Included)
Feature 2 (Included)
Feature 3 (not-included)

Plan 2

Feature 1 (Included)
Feature 2 (Included)
Feature 3 (included)

I see the order field (and perhaps the is_enabled flag field) as a field that could be added to the MeaturedFeature model or a part of the Intermediate table between Plans and Metered Features.

Hi @macmichael01,
I assume you are talking about displaying the group of plans in a custom template / view.
The absence of a metered feature from a plan means it is not included so you can make comparisons between the 2 plans when rendering the template / view. For example mark Feature X as not-included if it only shows up in the first plan.
As for ordering the features, there are many ways you can do this as well when rendering the template / view. It just depends on how you want to order them.
By default I think they are ordered by their id. For example you can sort them by name, unit, product_code etc. by calling order_by on a feature queryset or by using the sorted function.
Hope this helped.

Cool thanks. That should work. Closing this ticket.


Searching In row-column sorted Matrix

Description
In this PR I have solved question to search if a number is present in a sorted array or not using C++.
link:- https://practice.geeksforgeeks.org/problems/search-in-a-matrix-1587115621/1/?category[]=Matrix&category[]=Matrix&page=1&query=category[]Matrixpage1category[]Matrix
Fixes #1831
Type of change
Please delete options that are not relevant.

[x] New feature (non-breaking change which adds functionality)

Checklist:

[x] My code follows the style guidelines(Clean Code) of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have created a helpful and easy to understand README.md
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests/screenshots(if any) that prove my fix is effective or that my feature works

@ravikr126 @Amit366 Please review my PR


Tree View 2 way binding selection on initialization

Bug type
Component
Component name
TreeView
What happened?
The @bind-SelectedValue is a two-way binding and works great when clicking on an element and updating the value.
When initializing the selected value on OnInitialized or OnInitializedAsync the value changes and the TreeView receives the value but not activating an element like an on click event.
Expected behavior
Activating the selected MudTreeViewItem by value, same as on click.
Reproduction link
https://try.mudblazor.com/snippet/ckmwvPFYQiGXflvH
Reproduction steps
Just initialize the string variable for the 2 way binding before rendering.
Relevant log output
No response
Version (bug)
6.0.17
Version (working)
No response
What browsers are you seeing the problem on?
Firefox, Chrome, Microsoft Edge
On what operating system are you experiencing the issue?
Windows, Linux
Pull Request

[ ] I would like to do a Pull Request

Code of Conduct

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

Thats not a final solution about this, but with #5856, we have Select method to select and activate an item programmatically and properly.

Select method only accepts MudTreeViewItem but not value. How to "reselect" node without item reference?

Currently there is no easy way. Need a PR that implements two way bind selection.


Basic @next/font/google integration test

This:

Implements a basic http server to mock returning a stylesheet from the Google Fonts API (Note: This importantly does not mock returning the font resources themselves, which are currently loaded by the browser. We should implement something to do this when we implement caching arbitrary http resources traced from url() and this is no longer loaded by the test browser)
Adds an integration test that asserts the basic shape of the JS object returned by font functions
~Adds an integration test that asserts the browser correctly loads a font for the ascii unicode range, along with the appropriate font-display, variant, etc.~ Unfortunately document.fonts is not reliable with different font-display loading patterns as any of them can fall back.

As noted, this does not mock responses from Google for the font resources themselves, which are currently loaded by the test browser. This means that we'll be dependent on this external service for passing integration tests until we implement caching of url()s in Turbopack. We should monitor the reliability of this test.

@alexkirsz it looks like this test caught a regression from #3184, which made the next-font transform no longer run.


Go ci versions

Removing 1.2 and 1.3 from TravisCI testing.

Seems to be a lot of unrelated commits.

lgtm. thanks.

 Thanks, @stresler!


exploitdb: 2024-07-02 -> 2024-07-05

Diff: https://gitlab.com/exploit-database/exploitdb/-/compare/refs/tags/2024-07-02...2024-07-05
Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.


Rich Text field returns on array for plain text objects instead of html.

I can't seem to get Rich Text to output html in my queries. Instead I only have the option as text, and it renders the text in an array.
Here is my Rich Text field in Prismic:
"copyright" : {
  "type" : "StructuredText",
  "config" : {
    "multi" : "paragraph, preformatted, strong, em, hyperlink",
    "allowTargetBlank" : true,
    "label" : "Copyright"
  }
}

This what I get in return:
"copyright": [
  {
    "text": "© 2019.",
    "type": "paragraph"
  },
  {
    "text": "All rights reserved.",
    "type": "paragraph"
  }
 ]

The strange thing is that this is not happening every time. I have been able to get html text with the exact same setup in other places in the cms.

Hi @zerostyle, which version of gatsby-source-prismic are you using?

I'm using 3.0.0-beta.4.

This might be a result of not updating your custom type schema in your project. Gatsby may be inferring the type since the schema isn't telling the source plugin what kind of field "copyright" is.
Could you update your .json file and check again?

Somewhat related: https://github.com/angeloashmore/gatsby-source-prismic/issues/109
We could potentially have a system that automatically tells you if it suspects the schema is out of date. This can be done by checking if page data contains fields not in the schema.

I double-checked my schema the .json file the schema is up to date. Is there anything to check?

Can you run gatsby develop --verbose and look for somewhere that says:
verbose gatsby-source-prismic - writing out type paths to: [file path here]

That file path contains the types of all fields. Can you post that file here? Or at least the part that contains your copyright field?

I figured this out, and it was missing from the schema. Thanks for your help.

Awesome! Glad to hear it's working now. 🤙


How to share models between server and browser

I'd like to share my models between front and backend so I only have one definition, but that currently appear to be possible since importing any class with the annotations in them brings in all the Nodejs binaries such as dns which cannot be used on the browser

Hey @Toxicable, i think this won't be possible without installing sequelize and sequelize-typescript on the frontend as well, which won't work in a browser.
What about using interfaces instead? These interfaces can then be implemented by your backend- and frontend classes or  maybe you can use interfaces only on frontend?

Yup I'm doing the Interface approach at the moment. Like so
interface Person {
name: string;
}

@Table
class Person implements Person extends Model<Person> {
  @Colunm
  name: string
}

Just would be nice if we could just use the same class on the frontend instead.
Maybe providing a shim for the decorators that can be resolved by the frontend would resolve the sequelize dependency?

Yeah, this would work. But it seems to me that it is not so easy to achieve and I would say it wouldn't be part of this project. But if you want to give it a try, I'm happy if you'll come back with your knowledge :)

fixed by https://github.com/RobinBuschmann/sequelize-typescript/pull/574


Where can I find the config file of cartography?

I am scanning my aws and trying to config which resources to map, which regions etc.
Where can I find the option to filter what to scan?
@achantavy

It's documented in cartography -h:
  --aws-requested-syncs AWS_REQUESTED_SYNCS
                        Comma-separated list of AWS resources to sync. Example 1: "ecr,s3,ec2:instance" for ECR, S3, and all EC2 instance resources. See
                        the full list available in source code at cartography.intel.aws.resources. If not specified, cartography by default will run all
                        AWS sync modules available.

Source: https://github.com/lyft/cartography/blob/3fa62ee2c07b92954ef5a4f4d039d4c94e918e85/cartography/cli.py#L188-L196
cartography.intel.aws.resources: https://github.com/lyft/cartography/blob/3fa62ee2c07b92954ef5a4f4d039d4c94e918e85/cartography/intel/aws/resources.py#L44

Great @achantavy thanks a lot!
And if I want to scan it on daily/hourly basis where can I configure such job?
Will it override/conflict with existing ids?
Thanks in advance!

You can configure one or more cronjobs for that. As long as the same resources aren't being synced at the same time by parallel crons then I don't think you'll have problems. That said, parallel cron management is difficult already. I'd recommend starting with keeping it simple, evaluating later on how frequent your users need the data, and then adjusting.
Here are some ideas regarding deploying cartography in prod:

Ops tips like how we keep data up to date and observability: https://lyft.github.io/cartography/ops.html
You can write custom sync commands to arrange your crons: https://lyft.github.io/cartography/dev/developer-guide.html?highlight=custom sync#implementing-custom-sync-commands
You can also write your own intel module plugin by following these steps: https://lyft.github.io/cartography/dev/writing-intel-modules.html. We'd also happily welcome PRs here too.
A few blogs for ideas: Mapping moving clouds, Tracking moving clouds, IAM whatever you say IAM.

Thanks a lot @achantavy


Component Harness getText should ignore MatIcon content

For convenience!

Duplicate of https://github.com/angular/components/issues/20812.


Hook for replacing user avatar logic

Is your proposal related to a problem?
From @jhrr on https://github.com/wagtail/wagtail/issues/12274#issuecomment-2514281305:

Sorry to mildly necrobump this thread, but there is one issue with cutomizing the Wagtail UserProfile that we've encountered, and that is being able to replace or alias the avatar field on the UserProfile with some other avatar on some other model so it could use that instead.

For example, we have a custom User model and a Profile model, and we keep the avatar on the Profile. We'd prefer to just be able to use the avatar from the Profile everywhere, across all sub-domains/contexts, including inside the CMS itself. Is there any way we can achieve this currently?
Describe the solution you'd like
As per https://github.com/wagtail/wagtail/issues/12274#issuecomment-2517181624 - introduce a new get_avatar_url hook which is called by the {% avatar_url %} tag in wagtailadmin_tags.py, passing the user object and requested size. If any hook returns a non-empty response, return that in preference to the standard avatar URL logic.
The change would be to this function, and would look something like (untested):
@register.simple_tag
def avatar_url(user, size=50, gravatar_only=False):
    """
    A template tag that receives a user and size and return
    the appropriate avatar url for that user.
    Example usage: {% avatar_url request.user 50 %}
    """
    for hook_fn in hooks.get_hooks("get_avatar_url"):
        url = hook_fn(user, size)
        if url:
            return url

    # followed by the existing code

This would need to be accompanied by unit tests - I'd suggest adding a hook function in wagtail/test/testapp/wagtail_hooks.py that returns a custom URL when some specific condition is true, such as the username containing "fred", and adding tests to confirm that both the custom code and the default avatar logic come into play at the appropriate times. The hook will also need to be documented in the hooks reference docs, and ideally we'd mention it in the customising admin templates docs too - this could be a detailed howto, but I expect we can come up with a simple self-contained example snippet on the hooks reference page that's not too long, and just link to that.
Describe alternatives you've considered
On #12274 we considered:

making it possible to customise the value returned for avatar on UserProfile (too invasive)
overriding the wagtailadmin/shared/avatar.html template (too much copy-and-paste, and locks us in to the current template tag approach)
overriding avatar_url in the wagtailadmin_tags tag registry (likewise, locks us in to the template tag approach)

Working on this
@jhrr has first dibs on this, but anyone else is welcome to pick it up :-)

OK excellent, I will claim this then and get started on it pronto. Thanks for the pointers.

I wonder if this overlaps with (or at least compliments) https://github.com/wagtail/wagtail/issues/12659 (which I raised yesterday), which is more focused on better handling of overridden WAGTAIL_GRAVATAR_PROVIDER_URL values.
As an aside (probably needs a different issue), I wonder if we should rename WAGTAIL_GRAVATAR_PROVIDER_URL to WAGTAIL_EXTERNAL_AVATAR_PROVIDER_URL.

See also https://github.com/wagtail/wagtail/issues/4615 for some related discussion on the image sizes for avatars.


Update ncclient to 0.6.2 for verify folder

Updating ncclient in the requirements.txt for this folder, as well, in case some people do the pip install from this folder instead of the root level folder. See #35, #44

Hey @annegentle, I missed that the PR didn't include this copy of the requirements.txt. Sorry!

Good catch! 👀


callHookWithTimeout error and warning timeouts swapped

Description
We have this error originating from vite-plugin-ssr.
Error<EMAIL_ADDRESS>Timeout] The onBeforeRender() hook of /pages/all.page.server.js didn't finish after 4 seconds
    at Timeout._onTimeout (/Users/vedranmilic/Documents/projects/viu-web-site/node_modules/vite-plugin-ssr/dist/cjs/utils/callHookWithTimeout.js:29:50)

I've traced the issue to the file: https://github.com/brillout/vite-plugin-ssr/commit/1f5be92b09a33d290908da0d24913ca556370036#diff-c010b7cf4d0f9933efab99f66a4989d89f1604c491cdcf0107c108cbdbd2e941
It looks like the warning and error timeout logic is replaced.
In the lines between 28 and 39
const t1 = setTimeout(() => {
    const msg = `${errorPrefix}[Slow Hook] The ${hookName}() hook of ${hookFilePath} is taking more than ${humanizeTime(
      timeoutErr
    )}`
    console.warn(msg)
  }, timeoutErr)
  const t2 = setTimeout(() => {
    const err = getProjectError(
      `[Hook Timeout] The ${hookName}() hook of ${hookFilePath} didn't finish after ${humanizeTime(timeoutWarn)}`
    )
    reject(err)
  }, timeoutWarn)

timeoutErr is in the place of the timeoutWarn and vice versa.
Error Stack
Error<EMAIL_ADDRESS>Timeout] The onBeforeRender() hook of /pages/all.page.server.js didn't finish after 4 seconds
    at Timeout._onTimeout (/Users/vedranmilic/Documents/projects/viu-web-site/node_modules/vite-plugin-ssr/dist/cjs/utils/callHookWithTimeout.js:29:50)

Tried to fix it and it was already fixed as I was editing the file.

Btw, in case your company is interested: https://github.com/sponsors/brillout


Issue #1 : Improve documentation for Spark session creation (Databricks etc.)

Issue #1
Why?
The many comments in #1 suggest that users overlook the required installation of JARs when installing Deequ.
What?
Now the documentation clarifies the importance of installing the JARs.

Looks good to me

Perhaps include more description about the type of error obtained which requires this installation of the jar file.
Also, that both pydeequ package from pypi and the jar file from maven central need to be installed.
Thanks.


use matched_count for returned status code

closes #103
@gsfr can you give it a quick review? Thanks!

LGTM!


fan can't go under 2800 even I put curve to boost 0

Discussed in https://github.com/T-Troll/alienfx-tools/discussions/437

Originally posted by xli659 July 29, 2024
When doing the manually fan control, the lowest fan will stay around 2800 RPM (48% fan speed), even when I put the curve boost to zero. It only can control fan speed above 2800 RPM. Is this expected behavior? I am on M16 R2. Is this model supported?

I'm having kind of the same issue.
My fans wont go bellow 2300 rpm no matter which how I configure it, interestingly thought, when I change the power mode to any of the "Level 16X", it drops to 0 rpm
I am not sure if this is a bug or I'm not understanding how this works.

It's a common situation.
This gear doesn't have direct fan control, but indirect. So you can set RPM higher, then BIOS suggest, but not lower.
It's for good, in fact.
All power modes have different PASV (Passive) temperature points, so some of them turn fans off, some not.
Hint: I have a keyboard shortcuts to switch modes (CTRL+ALT+digit).


Committee > meeting edit: Account search field is missing in add Administrator field

Description: If a superadmin or organization admin wants to add another user as an admin for a meeting in the meeting detail view, the search field for users is missing. Only the Account list is visible. As a superadmin it always happens, as organization-admin it happens sometimes. I can't figure out, why it occurs as orga-admin only sometimes. I hope, that the solution for superadmins can fix the orga-admin issue.
See Administrator field:

What is actually displayed:

Reproduction as SUPERADMIN:

open an instance
open accounts: create two new accounts
open committees and create a new committee
create a new Meeting and try to add other users as Administrators.

What should happen:
The add new administrator field should have a search bar.

I cannot reproduce this. I followed the steps and a search bar is shown.

I can reproduce this. The search field is there but seem to be transformed out of view.


Invalid Command Argument

The two references "--to", should be renamed to "--tm".
This was changed in a previous git commit.
--to was trustowncert, which was changed to --tm trustmyself

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

ID: 3d3332c7-1954-6d73-aa09-5424bb7baaeb
Version Independent ID: e47ae8c4-ef55-0d7a-210c-bd37237b712a
Content: How to deploy OPC Twin module for Azure from scratch
Content Source: articles/iot-accelerators/howto-opc-twin-deploy-modules.md
Service: industrial-iot
GitHub Login: @dominicbetts
Microsoft Alias: dobett

@perkops Thanks for the feedback! We are currently investigating and will update you shortly.

@perkops Could you share the Git repo link so that we can review and update the doc accordingly?

@AshokPeddakotla-MSFT,
Sure - it was changed in this commit:
https://github.com/Azure/Industrial-IoT/commit/064da5df292fb6de8c9c5e4fc993ffe9b689dd7c#diff-6de08bae9f9084d0ebde6e3a2a74f3f7

Thanks for sharing the details.  The IoT Solution Accelerators doc sections are being reviewed. Adding author @dominicbetts  to prioritize this bug if possible.

@dominicbetts Could you please check this and update the appropriately.

@dominicbetts Assigned this issue to you since it needs to be verified the change. Please check and update the doc approproately.

Hi @perkops - thanks for pointing this out - I'll update the article. Please note that we're currently reviewing and updating this content, and that currently the most up to date docs are available here: https://azure.github.io/Industrial-IoT/. Thanks!
#please-close


(Nova + Meteor) Is it possible to use Nova with Meteor?

Im trying to use Nova with Meteor, but it looks like addReducers and addLinks dont support using MeteorCollection.rawCollection().
While testing I saw that when creating a collection with
const PostCollection = new Mongo.Collection("test_post");

The output is different than when using
const Post = await MongoInternals.defaultRemoteCollectionDriver().mongo.db.createCollection("Post");

When creating a collection directly with the node driver everything works, but when creating with meteor version it doesnt work.
Any clues on what can be done to use rawCollection or something similar to use Nova inside Meteor?

Interesting, I think I might know the culprit, can you try attaching links in Meteor.startup(() => { addLinks() }) function. I noticed that the references for .rawCollection() change as Meteor starts-up.

I'm closing this because I'm almost sure that's the case, if not feel free to reopen and I'm happy to help to ensure it works with Meteor.


Anchors disappearing

Hi,
I just tried out this plugin, like it much better than other plugins available for gitbook.
However, I noticed that first it shows when I open the book, but if I navigate to another chapter, the anchors no longer appearing, I have to refresh the browser for them to reappear.
Many thanks if you have a look at this.
Cheers,
Imre

Ooh good catch! I will take a look at this asap.

@nagim version 1.0.2 of the plugin should address this. Thanks for the report!

Thanks for the quick fix, I will check it out soon!

It appears to be working, the only small thing I noticed is that at the first load of the page, it displays two anchors. If I navigate to another page, it's fine

Interesting! I think I know what's causing that. 1.0.3 will be out shortly with a fix...

Try now with 1.0.3?

Sorry, I could only test it now. It works fine, great work! :clap:
Thanks!

Adding configuration is something I want to do (see: #1) but don't have time to dive into just yet.
Are you saying you want to be able to link to each paragraph, too?

I see some cases, when it could be useful, I think. In general, I guess it's not a widely wanted feature, that's why I thought it shouldn't be enabled by default, but make is optional instead. I saw examples for that on the anchor.js site, I thought it could be done without much hassle. But I understand if you don't have time for it.
The configuration idea is great (but I'm also happy with the current style :smile:).


Feature: Documentation for version 2

Summary
Provide documentation for version 2 of mui-forms

Version 2 documentation is here:

https://mui-forms.vercel.app/getting-started

Release notes for version 2 release:

https://mui-forms.vercel.app/release-v2


Copy Remote Address to Clipboard

It is very common for developers to share the remote reference of a specific line in a file on the remote. Right now, GitLens has got the "Open File in Remote" contextual menu option that opens the browser in the specific line the contextual menu was issued. It would be also interesting to have the ability of copying the remote address without having to deal with the browser.

@samuelmtimbo if you think this feature should be built, consider adding a reward to this issue using speedoss.com :)


Cloning private repository fails

Hi there,
First, thanks for your great plugin!
I have been running through an issue for 2 days now, which is pretty weird to me.
What I want is to clone a private repository using my SSH key.
When I try running caddy as a service (Debian 8) using: sudo systemctl start caddy
And then query for its status using: sudo systemctl status caddy
Caddy tells me that it could not clone from remote repository because of my public key.
I assumed it was related to my SSH key permissions, so I tried running the exact same command
that my service runs when I start it. Here, Caddy has had no problem cloning my repository.
Unfortunately, I cannot manage to find where the issue is. My caddy.service file is located at
/etc/systemd/system/caddy.service and the user as which the service should run is well set.
My caddy.service file:
[Unit]
Description=Caddy HTTP/2 web server
Documentation=https://caddyserver.com/docs
After=network.target

[Service]
Restart=on-failure

; User and group the process will run as.
User=inad
Group=www-data

; File descriptors limit.
LimitNOFILE=1048576

ExecStart=/usr/local/bin/caddy -agree=true -email=myemail -conf=/etc/caddy/Caddyfile
ExecReload=/bin/kill -USR1 $MAINPID

StartLimitInterval=600

[Install]
WantedBy=multi-user.target

My Caddyfile:
domain.com {
    root /var/www/my-site

    git my-git-repo.git {
        key    /home/inad/.ssh/id_rsa
    }
}

The file /home/user/.ssh/id_rsa has permissions 600, and owner:group is inad:inad.
As I said, when I run manually the ExecStart command from caddy.service in my shell,
it correctly clones the repository, but using systemctl, it does not.
Any help is welcome, thank you in advance!

Firstly, the fact that running the command directly works indicates that this is due to an issue with systemd, not caddy or git.
This is very weird but I still think it is a permission issue. Can you share the exact error message you got ?

I do think the same way, still I do not understand why the service would run as another user,
because I notified it to run as inad, which is my account.
Here is the message:
$ sudo systemctl status caddy.service -l
● caddy.service - Caddy HTTP/2 web server
   Loaded: loaded (/etc/systemd/system/caddy.service; enabled)
   Active: active (running) since Sun 2016-07-03 22:30:02 CEST; 12s ago
     Docs: https://caddyserver.com/docs
 Main PID: 14392 (caddy)
   CGroup: /system.slice/caddy.service
           ├─14392 /usr/local/bin/caddy -agree=true -email=myemail -conf=/etc/caddy/Caddyfile
           ├─14421 /bin/bash /tmp/caddy659591750
           ├─14424 ssh-keyscan -t rsa dsa bitbucket.org
           └─14425 sort -u - /home/inad/.ssh/known_hosts

Jul 03 22:30:02 vps263107.ovh.net caddy[14392]: Activating privacy features... done.
Jul 03 22:30:07 vps263107.ovh.net caddy[14392]: Cloning into '/var/www/php-project-client'...
Jul 03 22:30:13 vps263107.ovh.net caddy[14392]: Permission denied (publickey).
Jul 03 22:30:13 vps263107.ovh.net caddy[14392]: fatal: Could not read from remote repository.
Jul 03 22:30:13 vps263107.ovh.net caddy[14392]: Please make sure you have the correct access rights
Jul 03 22:30:13 vps263107.ovh.net caddy[14392]: and the repository exists.
Jul 03 22:30:13 vps263107.ovh.net caddy[14392]: 2016/07/03 22:30:13 exit status 128

Thanks for your quick answer.

@Falinor Any luck with this ?

Hi,
I'm getting similar problem.
Sep 04 10:09:59 XXXas.com systemd[1]: Stopped Caddy HTTP/2 web server.
Sep 04 10:09:59 XXXXdas.com systemd[1]: Started Caddy HTTP/2 web server.
Sep 04 10:09:59 XXXdas.com caddy[6697]: Activating privacy features... done.
Sep 04 10:10:02 XXXdas.com caddy[6697]: Host key verification failed.
Sep 04 10:10:02 XXXXdas.com caddy[6697]: fatal: Could not read from remote repository.
Sep 04 10:10:02 nXXXXs.com caddy[6697]: Please make sure you have the correct access rights
Sep 04 10:10:02 niXXXas.com caddy[6697]: and the repository exists.
Sep 04 10:10:02 niXXXs.com caddy[6697]: 2016/09/04 10:10:02 exit status 1
Sep 04 10:10:04 XXXas.com systemd[1]: Stopping Caddy HTTP/2 web server...
Sep 04 10:10:04 nXXX.com caddy[6697]: 2016/09/04 10:10:04 [INFO] SIGTERM: Terminating process
Sep 04 10:10:04 niXXXcom systemd[1]: Stopped Caddy HTTP/2 web server.
Sep 04 10:10:04 niXXX.com systemd[1]: Started Caddy HTTP/2 web server.
Sep 04 10:10:04 niXX.com caddy[6746]: Activating privacy features... done.
Sep 04 10:10:07 nirXXcom caddy[6746]: Host key verification failed.
Sep 04 10:10:07 nirXXXom caddy[6746]: fatal: Could not read from remote repository.
Sep 04 10:10:07 nXXXs.com caddy[6746]: Please make sure you have the correct access rights
Sep 04 10:10:07 nXXXdas.com caddy[6746]: and the repository exists.
Sep 04 10:10:07 niXasX.com caddy[6746]: 2016/09/04 10:10:07 exit status 1

root@XXXXas:/var/www/faqify# sudo systemctl status caddy.service -l
● caddy.service - Caddy HTTP/2 web server
   Loaded: loaded (/etc/systemd/system/caddy.service; enabled; vendor preset: enabled)
   Active: active (running) since Sun 2016-09-04 10:11:00 EDT; 7s ago
     Docs: https://caddyserver.com/docs
 Main PID: 7124 (caddy)
    Tasks: 9
   Memory: 3.9M
      CPU: 247ms
   CGroup: /system.slice/caddy.service
           ├─7124 /usr/local/bin/caddy -log stdout -agree=true -conf=/etc/caddy/Caddyfile -root=/var/tmp
           ├─7165 /bin/bash /tmp/caddy396642904
           ├─7168 ssh-keyscan -t rsa dsa gitlab.com
           └─7169 sort -u - /etc/ssl/caddy/.ssh/known_hosts

It says Host key verification failed. and I found a known_hosts file at the above location. From where does this known_hosts file come from? Is that a list of all known keys?

The known host file comes from here https://github.com/abiosoft/caddy-git/blob/master/scripts.go#L116-L120.

Hey!
I managed to solve the problem for a while, fortunately.
In order to let anyone viewing this post understand and get started, I will explain the whole process.
My caddy binary is at /usr/local/bin/caddy.
Create caddy user
$ sudo useradd -m -d /var/lib/caddy -r -G www-data caddy should do the trick
Create caddy service
On my Debian 8 Jessie, I have a file defining my service at<EMAIL_ADDRESS>This file should atleast contain the following:
[Unit]
Description=<your description>
After=network.target

[Service]
Restart=on-failure

; User and group the process will run as.
User=%i
Group=www-data

LimitNoFile=<your limit>

ExecStart=/usr/local/bin/caddy -agree -email <your email> -conf /etc/caddy/Caddyfile -pidfile /var/run/caddy/caddy.pid
ExecReload=/bin/kill -USR1 $MAINPID

PIDFile=/var/run/caddy/caddy.pid

StartLimitInterval=600

[Install]
WantedBy=multi-user.target

This file contains a minimal configuration for caddy@ service.
Let's move on!
The Caddyfile
I wrote in the service that my configuration Caddyfile should be /etc/caddy/Caddyfile.
This is because I like to manage all my sites in one place. Let's create it.
A minimal Caddyfile using git with an ssh key could look like that:
domain.com {
  root    /var/www/domain.com/
  log      /var/log/domain.com/access.log
  errors /var/log/domain.com/errors.log
  gzip

  git <your-git-repo.git> {
    key /var/lib/caddy/.ssh/domain.com.id_rsa
  }
}

I prefer using deployment keys, it has pros and cons. Now, we should create a new ssh key for caddy user. The command could be the following:
$ sudo -Hu caddy ssh-keygen -t rsa -b 4096 -C "domain.com" -f "domain.com.id_rsa"
This command will create a pair of ssh files containing the public and private keys of caddy user. Give them appropriate rights. My private key file has 600 and my public one has 644. Do not create a password, leave it blank. This is a con of deployment keys.
Lastly, verify permissions and ownership on /var/www and try it.
$ sudo systemctl enable caddy@caddy
$ sudo systemctl restart caddy@caddy
$ sudo journalctl -fu caddy@caddy

Wait and see after the last command. Please tell me if that worked for you!

That's good to hear and I think its safe to close this issue.
@nidheeshdas, can you try the instructions above as well.


After Adjusting stake amount the pending stake change disappears after few minutes.

When a adjust stake amount request is submitted, the pending stake change is seen in the staking details and disappears in a minute or two and upon repeating the adjust stake, the same things happens over and over. This makes it impossible to adjust the stake amount for the user as the request gets reject after a few minutes.
This issue is remedied only after changing password and PIN and logging in with the new credentials. This issue has been faced by a few users.

Excellent, thank you for reporting this issue. We will add it to the buglist!

Excellent, thank you for reporting this issue. We will add it to the buglist!
This is the error message in the log:    " ERROR: FindStakeChange : Stake Minter: Invalid public key on stake change request...removing"


Quote path for regex

Windows paths contain backslash which will be interpreted by the regex engine if left unquoted.
Targetting 3.1.x. Should it? Or should this be retargeted?

@cla-bot[bot] check


Unaudited, old crypto (hash) crates in build graph?

Bug Report
If you run cargo tree --insert --package rand:0.3.23 (after installing cargo-tree) you will find this:
hoverbear@Obsidian:~/git/tikv$ cargo tree --invert --package rand:0.3.23
rand v0.3.23
└── rust-crypto v0.2.36
    └── tidb_query v0.0.1 (/home/hoverbear/git/tikv/components/tidb_query)
        ├── test_coprocessor v0.0.1 (/home/hoverbear/git/tikv/components/test_coprocessor)
        │   [dev-dependencies]
        │   └── tikv v4.0.0-alpha (/home/hoverbear/git/tikv)
        │       ├── test_coprocessor v0.0.1 (/home/hoverbear/git/tikv/components/test_coprocessor) (*)
        │       ├── test_raftstore v0.0.1 (/home/hoverbear/git/tikv/components/test_raftstore)
        │       │   └── test_storage v0.0.1 (/home/hoverbear/git/tikv/components/test_storage)
        │       │       └── test_coprocessor v0.0.1 (/home/hoverbear/git/tikv/components/test_coprocessor) (*)
        │       │       [dev-dependencies]
        │       │       └── tikv v4.0.0-alpha (/home/hoverbear/git/tikv) (*)
        │       │   [dev-dependencies]
        │       │   └── tikv v4.0.0-alpha (/home/hoverbear/git/tikv) (*)
        │       └── test_storage v0.0.1 (/home/hoverbear/git/tikv/components/test_storage) (*)
        └── tikv v4.0.0-alpha (/home/hoverbear/git/tikv) (*)

You can see that rust-crypto = "^0.2" is part of our tidb_query crate.
I was curious why this crate, rust-crypto uses such an old version of rand... We have 5 versions of rand in our build graph and this is the oldest:
  rand:0.3.23
  rand:0.4.6
  rand:0.5.6
  rand:0.6.5
  rand:0.7.0

So I took a look at https://github.com/DaGenix/rust-crypto to see if this crate had an update.
This crate, rust-crypto has not been updated in 4 years, and contains code that has not cryptographic code which has been audited formally.
Do we have a policy around which crypto crates we select?
I worry this crate may be vulnerable to timing attacks or other exotic attacks. These attacks could, in theory, impact our users.
We are using the following parts of it:
use crypto::{
    digest::Digest,
    md5::Md5,
    sha1::Sha1,
    sha2::{Sha224, Sha256, Sha384, Sha512},
};

We may get better mileage adopting one or some of these from https://github.com/RustCrypto/hashes. These seem more modern and better maintained. There is also https://github.com/stainless-steel/md5 and https://github.com/mitsuhiko/rust-sha1/ which exist.
What version of TiKV are you using?
Master
What operating system and CPU are you using?
Any
Steps to reproduce
Explore cargo tree --invert --package rand:0.3.23
What did you expect?
What did happened?

@nrc volunteered to ask around if there are any recommendations.

As discussed in https://github.com/tikv/tikv/issues/5145, we could introduce an OpenSSL compatible library such as LibreSSL(supported by grpc-rs now), to replace DaGenix/rust-crypto. Maybe it will be more secure and reduce the count of dependencies.

LibreSSL has some known issues like #5389 and #5340 .

@overvenus Please open a new issue for that because this issue is not regarding SSL. :)

I believe rust-crypto turned into https://github.com/RustCrypto/, so upgrading to those projects is probably an easy step.
Getting off the old rand crates is probably smart too.
Though if we're only using digest functions I think the risk of vulnerabilities is pretty low. I believe those are not the parts of crypto that tend to be susceptible to timing attacks.

Closing due to #3886


404

https://www.prisma.io/docs/#reference
Under database connectors upto editor setup returns 404

Thanks a lot for catching this @nainardev, I just fixed this with this PR: https://github.com/prisma/prisma2-docs/pull/149

Thanks!! :smile:


Piper/remove unused comparison signed property

fixes #86
What was wrong?
Unused code
How was it fixed?
Removed it.
Cute Animal Picture

Merging, doesn't seem like this needs to be reviewed.


Get all the delegated resources by the reportee

Description
Get all the delegated resources (api) by the reportee to others. The new userinterface here requires that the api returns the following details to the frontend

resource(api) title

Name of the organisation the resource was delegated to

Additional Information
No response
Tasks

[x] Create an endpoint to list all the delegated resources
[x] Add integration with sblbridge to get the party information
[x] Test with different input
[x] Create unit tests for the new endpoint

Acceptance Criterias

[ ] The endpoint is accessible /api/v1/delegations/GetDelegatedResources
[ ] The endpoint must return a list of resources and each resource lists the receiver information.

No response

https://github.com/Altinn/altinn-authorization/issues/65

Available for testing after deploy to the test environment


Fix typo in key nameused in Extensions CHANGELOG

Fix typo in key name. See correct name at: https://github.com/Azure/azure-sdk-for-net/blob/ea7dc0d229a404ba85285ec63fe533a94650f051/sdk/extensions/Microsoft.Extensions.Azure/src/Internal/ClientFactory.cs#L91

will this eventually make it to https://azure.github.io/azure-sdk/releases/2023-08/dotnet.html or does someone need to do something? :)

will this eventually make it to https://azure.github.io/azure-sdk/releases/2023-08/dotnet.html or does someone need to do something? :)

On the next release of the package, the docs will pick up the changes here.


mercury_core.h is installed?

HG_Core_ functions there are internal to mercury, right?

Not necessarily, they can be used by somebody who doesn't want to use the mercury_proc routines, i.e., who wants to use another serialization/deserialization mechanism.

Are you referring to HG_Core_get_(input|output)? Perhaps we could remove the need for those by having mercury.h functions HG_Get_(input|output)_raw, which do the equivalent thing.

Well not only, this is the same for forward / respond. If we were to go this way then we'd just have everything in the same source file whereas what we wanted to have is a decomposition of the layers:
-level 0: hc_core operates only on raw buffers
-level 1: hg operates on structs
-level 2+: hg can use boost etc to automatically generate code

That sounds reasonable. The boost bit is really a helper to 1 rather than something that overshadows it, but otherwise that's a good way to think about it.
I guess what's confusing me is that the Core functions for the most part simply shadow their mercury.h equivalents, that is, in mercury.c, most HG_ functions are one-liner forwards to HG_Core functions. In other words, there's no reason for API consumers to use them, and including them leads to confusion about whether to HG_Init or HG_Core_init, for example.

Well actually I also include in 2+ having boost to also generate the client code at least, not only the serialization functions, so that the user can for example replace an open() call by an open_rpc() call.
Yes I see what you mean... I think part of it is because before we didn't have these and you would call both the core and not core functions, which was maybe more confusing though... I would assume we'll need those at some point and for the time being there is only a direct mapping between these routines. I guess what we have is similar to what we'd have if we were using C++. We'd have some virtual definitions and HG would inherit from HG_Core so we'd just need to redefine the ones that we need.

Is there a boost preprocessor way to wrap, say, open (const char *path, int flag, mode_t mode) such that serialization code is generated directly from the inputs? That would be quite useful... I know C++ templates are up to the task (I've done so for forwarding functions to argobots tasks).
Perhaps for now we just drop the HG_Core functions for which the corresponding HG_ functions are no-ops and re-introduce them as needed? If they end up having non-overlapping sets of functionality, they'd probably have different argument lists anyways. Then the API story becomes "use HG_* unless you want to avoid <e.g. default (de)serialization>, then use HG_Core_*".

Yes there is, you can look at mercury_hl_macros.h. MERCURY_GEN_RPC_STUB for example will do that. We ended up having something like that in mercury posix for example.
MERCURY_POSIX_GEN_STUB(fsync,
        hg_int32_t,
        (hg_int32_t),
)


Dependency on angular/material

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report
[ ] Performance issue
[ ] Feature request
[ ] Documentation issue or request
[x] Support request
[ ] Other... Please describe:

Current behavior

Dependency on angular/material errors when compiling
Expected behavior

No such dependency or making it optional.
Minimal reproduction of the problem with instructions
nx workspace
angular 13.1
ngx-errors 3.1.5
Following errors in the console:
./node_modules/@ngspot/ngx-errors/fesm2015/ngspot-ngx-errors.mjs:3:0-45 - Error: Module not found: Error: Can't resolve '@angular/material/core' in '......../node_modules/@ngspot/ngx-errors/fesm2015'

./node_modules/@ngspot/ngx-errors/fesm2015/ngspot-ngx-errors.mjs:9:0-48 - Error: Module not found: Error: Can't resolve '@angular/material/input' in '........../node_modules/@ngspot/ngx-errors/fesm2015'

What is the motivation / use case for changing the behavior?

Environment

Angular version: X.Y.Z

Browser:
- [ ] Chrome (desktop) version XX
- [ ] Chrome (Android) version XX
- [ ] Chrome (iOS) version XX
- [ ] Firefox version XX
- [ ] Safari (desktop) version XX
- [ ] Safari (iOS) version XX
- [ ] IE version XX
- [ ] Edge version XX

For Tooling issues:
- Node version: XX
- Platform:

Others:

Do I really need to install angular/material if I don't need it otherwise? What is that that needs to be imported from angular/material for displaying error messages, please?

I knew this will going to come up!
I moved @angular/material dependencies into a separate package. Try<EMAIL_ADDRESS>and let me know if you run into some issues


Index data write to disk should run on a thread to keep the UI responsive

Writing IndexManager data to the disk can take some time as the IndexManager has to be serialized first.
The serialization process and writing the data to the disk should run on a thread to keep the UI responsive when handling big databases.

kotlinx.coroutines implemented


Gradle deprecation warnings

After upgrading the gradle wrapper to 5.1.1 (in https://github.com/flutter/flutter/pull/33728):
WARNING: API 'variant.getMergeAssets()' is obsolete and has been replaced with 'variant.getMergeAssetsProvider()'.
It will be removed at the end of 2019.
For more information, see https://d.android.com/r/tools/task-configuration-avoidance.
To determine what is calling variant.getMergeAssets(), use -Pandroid.debug.obsoleteApi=true on the command line to display more information.
WARNING: API 'variantOutput.getProcessResources()' is obsolete and has been replaced with 'variantOutput.getProcessResourcesProvider()'.
It will be removed at the end of 2019.
For more information, see https://d.android.com/r/tools/task-configuration-avoidance.
To determine what is calling variantOutput.getProcessResources(), use -Pandroid.debug.obsoleteApi=true on the command line to display more information.

./gradlew app:assembleRelease
WARNING: API 'variant.getMergeAssets()' is obsolete and has been replaced with 'variant.getMergeAssetsProvider()'.
It will be removed at the end of 2019.
For more information, see https://d.android.com/r/tools/task-configuration-avoidance.
To determine what is calling variant.getMergeAssets(), use -Pandroid.debug.obsoleteApi=true on the command line to display more information.
WARNING: API 'variantOutput.getProcessResources()' is obsolete and has been replaced with 'variantOutput.getProcessResourcesProvider()'.
It will be removed at the end of 2019.
For more information, see https://d.android.com/r/tools/task-configuration-avoidance.
To determine what is calling variantOutput.getProcessResources(), use -Pandroid.debug.obsoleteApi=true on the command line to display more information.
/Users/***/p/flutter/bin/cache/artifacts/engine/android-arm64-release/flutter.jar: D8: Type `android.arch.lifecycle.LifecycleRegistry` was not found, it is required for default or static interface methods desugaring of `void io.flutter.embedding.engine.FlutterEngineAndroidLifecycle.handleLifecycleEvent(android.arch.lifecycle.Lifecycle$Event)`
/Users/***/p/flutter/bin/cache/artifacts/engine/android-arm64-release/flutter.jar: D8: Type `android.support.v4.app.Fragment` was not found, it is required for default or static interface methods desugaring of `void io.flutter.embedding.android.FlutterFragment.onAttach(android.content.Context)`
/Users/***/p/flutter/bin/cache/artifacts/engine/android-arm64-release/flutter.jar: D8: Type `android.support.v4.app.FragmentActivity` was not found, it is required for default or static interface methods desugaring of `void io.flutter.embedding.android.FlutterActivity.onCreate(android.os.Bundle)`
/Users/***/p/flutter/bin/cache/artifacts/engine/android-arm64-release/flutter.jar: D8: Type `android.support.v4.app.FragmentActivity` was not found, it is required for default or static interface methods desugaring of `void io.flutter.app.FlutterFragmentActivity.onCreate(android.os.Bundle)`
/Users/***/p/flutter/bin/cache/artifacts/engine/android-arm64-release/flutter.jar: D8: Interface `android.arch.lifecycle.DefaultLifecycleObserver` not found. It's needed to make sure desugaring of `io.flutter.embedding.engine.FlutterEngineAndroidLifecycle$1` is correct. Desugaring will assume that this interface has no default method.
/Users/***/p/flutter/bin/cache/artifacts/engine/android-arm64-release/flutter.jar: D8: Interface `android.arch.lifecycle.LifecycleOwner` not found. It's needed to make sure desugaring of `io.flutter.embedding.engine.FlutterEngine` is correct. Desugaring will assume that this interface has no default method.
32 actionable tasks: 30 executed, 2 up-to-date

I got a scarier one :D
They're slowly pushing the date forward


Add .yaml extension to playbook paths

Please add some description why we are adding that extension to the paths.


Latest version of EKSCTL breaks Role Exports

Cluster Export script located here (https://eksworkshop.com/eksctl/test/) does not work. Fails at
STACK_NAME=$(eksctl get nodegroup --cluster eksworkshop-eksctl -o json | jq -r '.[].StackName')
EKSCTL Reference: https://github.com/weaveworks/eksctl/issues/1164
workaround: Create these exports manually using the Worker Node Role name and Instance Profile ARN of the Worker IAM role

additional workaround: Add nodegroup name to the eksctl get node group command.
If you're following the instructions for an AWS event, the ng is predictable. Use the commands below
STACK_NAME=$(eksctl get nodegroup --cluster eksworkshop-eksctl  -n eksworkshop-ng1 -o json | jq -r '.[].StackName')
INSTANCE_PROFILE_ARN=$(aws cloudformation describe-stacks --stack-name $STACK_NAME | jq -r '.Stacks[].Outputs[] | select(.OutputKey=="InstanceProfileARN") | .OutputValue')
ROLE_NAME=$(aws cloudformation describe-stacks --stack-name $STACK_NAME | jq -r '.Stacks[].Outputs[] | select(.OutputKey=="InstanceRoleARN") | .OutputValue' | cut -f2 -d/)
echo "export ROLE_NAME=${ROLE_NAME}" >> ~/.bash_profile
echo "export INSTANCE_PROFILE_ARN=${INSTANCE_PROFILE_ARN}" >> ~/.bash_profile
If you're running the workshop in your own account, you can get the nodegroup name from the "eksctl.io/v1alpha2/nodegroup-name" tag on the CloudFormation template for the EKSCTL created node group. replace <NODEGROUP_NAME> in the example below
STACK_NAME=$(eksctl get nodegroup --cluster eksworkshop-eksctl  -n <NODEGROUP_NAME> -o json | jq -r '.[].StackName')
INSTANCE_PROFILE_ARN=$(aws cloudformation describe-stacks --stack-name $STACK_NAME | jq -r '.Stacks[].Outputs[] | select(.OutputKey=="InstanceProfileARN") | .OutputValue')
ROLE_NAME=$(aws cloudformation describe-stacks --stack-name $STACK_NAME | jq -r '.Stacks[].Outputs[] | select(.OutputKey=="InstanceRoleARN") | .OutputValue' | cut -f2 -d/)
echo "export ROLE_NAME=${ROLE_NAME}" >> ~/.bash_profile
echo "export INSTANCE_PROFILE_ARN=${INSTANCE_PROFILE_ARN}" >> ~/.bash_profile

I'm working on this and we are aiming to release 0.4.2 with a fix later today.

I'm working on this and we are aiming to release 0.4.2 with a fix later today.

awesome! I'm subscribed on the eksctl issue... I'll go back to latest once the fix is out.


Crashloop on 0.14.1

Hello
Helm chart version: 0.14.1 crashes with following error:
Uses following image: ghcr.io/cloudnative-pg/cloudnative-pg:1.16.1
Error: unknown flag: --enable-leader-election

Hi @rlex
This should be fixed in the latest release 0.14.2, please try
Regards!

Yep, works fine now, thanks!


Automatic help text generation

Hi, thank you for creating this awesome library.
I have one feature request. (it could have already been considered though)
It would be more helpful for users to have automatic help text generation based on configured flags.
Yazap already has a Command.newWithHelpTxt function to set the about field, but currently, it doesn't have any way to output its information except for directly reading about and constructing our own help message by ourselves.

Hey,
It will be definitely implemented 😁 but after v0.1.0  release. The only thing left is to implement arg validation and logging errors plus updating/improving README docs and example after that i will start to implement **generating help ** and others.

Hi, thank you for creating this awesome library.
I have one feature request. (it could have already been considered though)
It would be more helpful for users to have automatic help text generation based on configured flags.
Yazap already has a Command.newWithHelpTxt function to set the about field, but currently, it doesn't have any way to output its information except for directly reading about and constructing our own help message by ourselves.

Now auto help message is implemented on a4df0eb2c953266de8c13a16b6e824f1949f7867. I forget to mention this issue on commit therefore leaving a comment here.


How to access window without calling eval()

It seems that there is no way to get the window object under an environment where eval() is disallowed by Content Security Policy (eg. on Electron).

Add a function like dom-window ?


DOC: add example for stats.mstats.compare_median_ms

Reference issue
#7168
Description
Added example for stats.mstats.compare_median_ms. Provided example usage for method.

Thanks @sudosoph! There are a few CI failures we'll need to fix.
By clicking "Datails" at the scipy.scipy (Main Lint) check and clicking some more until you get to the terminal output, we see
./scipy/stats/mstats_extras.py:435:80: E501 line too long (244 > 79 characters)
./scipy/stats/mstats_extras.py:436:80: E501 line too long (138 > 79 characters)

We need to follow PEP8 line length conventions, so please break those up.
scipy.scipy (Main refguide_asv_check) is telling us:
/home/circleci/repo/build/testenv/lib/python3.7/site-packages/scipy/stats/mstats_extras.py:docstring of scipy.stats.mstats_extras.compare_medians_ms:57: WARNING: Unknown target name: "1".

It doesn't know what you meant when you referenced the target [1]_ in the code on line 412, I think.
If you take a look at references in other files or at the numpydoc standards, you'll see two .. need to come before each reference number (e.g. .. [1]) in the References section. You need those dots to define the reference - otherwise Sphinx thinks that [1] is just normal text.

Previously, the PR referenced "Introduction to Robust Estimation and Hypothesis Testing" and seemed to refer to this part:

but the test shown there:

does not appear to be what is going on in the code. Instead, I added a reference to McKean & Schrader. "A comparison of methods for studentizing the sample median." I'm not sure if it actually suggests this test, but it will at least point the reader in the right direction.
Without a good reference, I decided not to try to add notes about what this function actually does (returns just a p-value, apparently), because although it appears reasonable, I'm not sure how valid the test is. I would open an issue to review this stuff more thoroughly, but I think gh-14651 is leaning toward unifying stats and mstats, at which point we can reconsider these mstats tests that don't have references.

Thanks @sudosoph!