lsp-hover kills the underlying rust-analyzer process

Everything works except lsp-hover and lsp-hover-buffer.
Whenever those commands are issued, the rust-analyzer process dies; no messages in the *debug* buffer.
How do I approach debugging this issue?

Anything interesting in the debug log?
Can you find steps to reproduce, ideally with a small project, the default Kakoune/kak-lsp configuration and the latest version of rust-analyzer (I'm using 2022-07-09).
Here's the debug log for a working lsp-hover:
Jul 22 09:11:33.991 DEBG From editor:
session  = "2563626"
client   = "client0"
buffile  = "/home/johannes/git/kak-lsp/src/main.rs"
filetype = "rust"
version  = 1
method   = "textDocument/hover"
[params]

selectionDesc = "66.18,66.26"
, module: kak_lsp::editor_transport:129
Jul 22 09:11:33.992 DEBG Searching for vars starting with KAK_LSP_PROJECT_ROOT_RUST, module: kak_lsp::project_root:58
Jul 22 09:11:33.992 INFO Found project root "/home/johannes/git/kak-lsp" because it contains "Cargo.toml", module: kak_lsp::project_root:41
Jul 22 09:11:33.992 DEBG Routing editor request to Route { session: "2563626", language: "rust", root: "/home/johannes/git/kak-lsp" }, module: kak_lsp::session:102
Jul 22 09:11:33.992 DEBG To server: {"jsonrpc":"2.0","method":"textDocument/hover","params":{"position":{"character":25,"line":65},"textDocument":{"uri":"file:///home/johannes/git/kak-lsp/src/main.rs"}},"id":21}, module: kak_lsp::language_server_transport:182
Jul 22 09:11:33.994 DEBG From server: {"jsonrpc":"2.0","id":21,"result":{"contents":{"kind":"markdown","value":"\n```rust\nclap::args::arg::Arg\n```\n\n```rust\npub fn with_name(n: &'a str) -> Self\n```\n\n---\n\nCreates a new instance of [`Arg`](https://docs.rs/clap/2.34.0/clap/args/arg/struct.Arg.html) using a unique string name. The name will be used to get\ninformation about whether or not the argument was used at runtime, get values, set\nrelationships with other args, etc..\n\n**NOTE:** In the case of arguments that take values (i.e. [`Arg::takes_value(true)`](https://docs.rs/clap/2.34.0/clap/args/arg/struct.Arg.html#method.takes_value))\nand positional arguments (i.e. those without a preceding `-` or `--`) the name will also\nbe displayed when the user prints the usage/help information of the program.\n\n# Examples\n\n```rust\nArg::with_name(\"config\")\n```"},"range":{"start":{"line":65,"character":17},"end":{"line":65,"character":26}}}}, module: kak_lsp::language_server_transport:156
Jul 22 09:11:33.995 DEBG To editor `2563626`: evaluate-commands -client client0 -verbatim -- lsp-show-hover 66.26 %§{InfoBlock}clap::args::arg::Arg

Additionally, rust-analyzer has its own troubleshooting facilities. The docs mostly expect the VSCode extension, but the RA_LOG env var and the --log-file flag should be usable from kak-lsp.

Me executing lsp-hover yielded this:
Jul 22 14:55:01.584 DEBG From editor:
session  = "17646"
client   = "client0"
buffile  = "/home/kirusfg/.local/cargo/registry/src/github.com-1ecc6299db9ec823/tui-0.18.0/src/backend/mod.rs"
filetype = "rust"
version  = 1
method   = "textDocument/hover"
[params]

selectionDesc = "19.11,19.11"
, module: kak_lsp::editor_transport:129
Jul 22 14:55:01.584 DEBG Searching for vars starting with KAK_LSP_PROJECT_ROOT_RUST, module: kak_lsp::project_root:58
Jul 22 14:55:01.584 INFO Found project root "/home/kirusfg/.local/cargo/registry/src/github.com-1ecc6299db9ec823/tui-0.18.0" because it contains "Cargo.toml", module: kak_lsp::project_root:41
Jul 22 14:55:01.584 DEBG Routing editor request to Route { session: "17646", language: "rust", root: "/home/kirusfg/.local/cargo/registry/src/github.com-1ecc6299db9ec823/tui-0.18.0" }, module: kak_lsp::session:94
Jul 22 14:55:01.584 ERRO panic: panicked at 'called `Result::unwrap()` on an `Err` value: Error { inner: ErrorInner { kind: Custom, line: None, col: 0, at: None, message: "missing field `position`", key: [] } }', src/language_features/hover.rs:28:54, module: kak_lsp:268
Jul 22 14:55:01.584 INFO Waiting for Messages to language server to finish..., module: kak_lsp::thread_worker:19
Jul 22 14:55:01.584 DEBG Received signal to stop language server, closing pipe, module: kak_lsp::language_server_transport:188
Jul 22 14:55:01.584 DEBG Waiting for language server process end, module: kak_lsp::language_server_transport:87

"missing field position",

we used to send position but changed it to selectionDesc in 5461c141 (lsp-hover: show diagnostics from anywhere on a line touched by main selection, 2022-04-30)
This is probably because you have updated rc/lsp.kak (via git pull) but haven't recompiled the binary (or you are using the wrong kak-lsp binary).

Yes, thank you.
I use plug and had an older version of kak-lsp installed alongside the one pulled and compiled via plug. The issue is resolved now.


Master Rank Weekly Kits + Homes Issues

When Master Rank was first decreased to the 90% threshold, I was able to claim my one time rewards but since that time I was unable to collect the weekly kit. The other thing I noticed was that homes were broken. This was broken since I first obtained Beast Rank but I had asked for that to be fixed and I was able to get some extra homes, this was increased to 11 homes later with a combination from my newer ranks and Jade Rank. I was able to set more homes but for some reason the maximum decreased to 6 homes.
IGN: NueNight
Server: Atlas

This should now be working as expected, closing.


COBOL support?

Hi,
I might be a bit naive but is it possible to add COBOL support to this package?
If so: how can I help? What needs to be done?
best
Dietmar

VS Code already has built in COBOL support, doesn't it?

Hmm I only have a bit of experience with IBM z/OS COBOL in a little side project. But, I've never touched COBOL on the iseries so I'm unsure if there's a ton of difference. I would try out an existing COBOL VS Code extension like this one before diving into recreating a syntax highlighter.
If there's a ton of syntax difference, another grammar could be added. A great example was in this pull request for PNLGRP


Error during redisplay:

Hi,
Recently, elfeed stopped to work . When i start elfeed i see blank buffer. In the Message i get:
elfeed-db-load: End of file during parsingError during redisplay: (eval (funcall elfeed-search-header-function)) signaled (end-of-file)
Could you help me to fix the problem

It sounds like your database index is corrupt. This could happen if
fsync writes are disabled (or unavailable for your platform). Elfeed
should probably handle this situation more gracefully, since it comes up
often enough.
Try deleting your ~/.elfeed/index file (or whatever you've got set for
elfeed-db-directory).

I deleted the file and elfeed works.


Add support for Google Cloud Storage with Json keyfile as auth

Edited helm and ansible to support GCS settings
Added doccumentation for GCS
Added mounts for new Json file as Secrets
Edited hadoop-scripts.yaml, hive-scripts-configmap.yaml, and presto-common-config.yaml to copy the Json keyfile if it is mounted

/retest

Ideally a fork, but it doesn't really matter, it's already open. But @commanderchewbacca should be pushing to his fork instead of origin.

/retest

/lgtm
/approve


Trying to send a wav file from JS script but get Error 422: Unprocessable entity

Backend
model = Model()
app = FastAPI()

origins = ["http://<IP_ADDRESS>:5500", "http://<IP_ADDRESS>:8000"]
app.add_middleware(
    CORSMiddleware,
    allow_origins=origins,
    allow_credentials=True,
    allow_methods=["*"],
    allow_headers=["*"],
)

@app.post("/save")
def save(file: UploadFile = File(...)):
    audio_bytes = file.file.read()
    signal, sr = sf.read(io.BytesIO(audio_bytes))
    return f'{sr}'

Frontend
function sendData(file) {
    const XHR = new XMLHttpRequest();
    FD = new FormData()

    // FD.append("username", "kareem");
    FD.append('uploadedfile', file, 'uploadedfile');
    XHR.open('POST', "http://<IP_ADDRESS>:8000/save", true);
    XHR.send(FD);

Description

The file argument in the js part is actually a blob which contains wav audio recorded from the browser.
The backend is supposed to recieve the data but it throws Error 422: Unprocessable entity.
It works fine however when pushing directly a wav file say through Postman to the endpoint.

Environment

OS: Linux
FastAPI version: 0.61.1
Python version: 3.8.2

Hmmm, the API form data expects a key named file, but on your frontend side, you're sending it as 'uploadedfile'.
Can you try changing it to file?

Thank you.

Thanks for the help here @ycd ! :clap: :bow:
Thanks for reporting back and closing the issue @kareemamrr  :+1:


Is it possible to use the shell app angular version @12 & other child/shared mfe's @v13

I am using child mfe which needs to be updated to the angular version 13 but the shell app is still in angular version 12 which will be updated later on is this possible. it's throwing some console error "Cannot read properties of undefined ( reading 'init' )

I tried shell app with angular app version 13 and remote app with angular 12 that works absolutely fine. But other way is throwing same error as you mentioned.

Hi,
yes, that should be possible. Just make sure, you have the newest version of this Plugin. However, if you have Angular 12, you need to install ngx-build-plus version 12 (if you have Angular 13, you need to install ngx-build-plus version 13).
Also, for loading Angular 12, use type: 'script' and for loading Angular 13 use type: 'module'.
Please note, in this case you have also to bootstrap both Angular versions. This can come with some difficulties. This package can help here:
https://www.npmjs.com/package/@angular-architects/module-federation-tools
Best wishes,
Manfred


Google link

https://docs.google.com/spreadsheets/d/1LfNSnOTxWZOO2ki2HLYYUDtGXpzhSbaR/edit?rtpof=true

Dropping adjectives - too much of a work for it to make sense


Intercepting links from the browser to open my app

On stackoverflow i saw this:
https://stackoverflow.com/questions/1609573/intercepting-links-from-the-browser-to-open-my-android-app
I can write the part of manifest file also in flutter:
<intent-filter>
            <action android:name="android.intent.action.VIEW" />
            <category android:name="android.intent.category.DEFAULT" />
            <category android:name="android.intent.category.BROWSABLE" />
            <data android:scheme="http"
                  android:host="flickr.com"
                  android:pathPrefix="/photos/" />
            <data android:scheme="http"
                  android:host="www.flickr.com"
                  android:pathPrefix="/photos/" />
        </intent-filter>

But how i can write the activity part with dart/flutter for get params?
final Intent intent = getIntent();
    final String action = intent.getAction();

    if (Intent.ACTION_VIEW.equals(action)) {
        final List<String> segments = intent.getData().getPathSegments();
        if (segments.size() > 1) {
            mUsername = segments.get(1);
        }
    }

Is there anything similar to do it in ios?
Thanks

@romaluca you closed this issue but you didn't provide us a solution or result ? Have you succeeded ? If yes how ? Can you give us a link ? Many thanks in advance

Yea I want to know "solution" also...


Heading selection UX improvements

So glad to see headings landed! There's one slightly weird thing about the UX here.
Let's say you've got a Heading 2:

When I click Heading 1, it toggles all headings off instead of switching the heading 2 to a heading 1. That interaction should select the Heading 1, not toggle off a heading 2. :v:
🤔

Good catch. I'd go so far as to call that a bug, rather than an enhancement. I started on some tests for this area to catch things like this, but apparently I should have finished them rather than leaving them in a TODO state...


changing format makes table wider

every time i use change the precision of a table by typing a digit,
the table gets wider.  if i keep changing them, it gets wider and wider.

can no longer reproduce


Fortunately, I was able to recover the file form VS Code rather. It has a Local History option that allows you to access deleted files


Fix install c test

Issue fix #3649
Now passes tests/install/install-C.sh

Fixed printing 'removed <file>' message
Added permissions comparing on -C options
The test also contains check for inconsistency of -C with some other options, added these checks, too

bravo:
Warning: Congrats! The gnu test tests/install/install-C is no longer failing!


Test for unaligned instruction load

Use a JR to jump to unaligned. Probably will see an exception

https://github.com/lemmy-64/n64-systemtest/pull/49


Support Rocket

Rocket looks to be well planned, if a bit young, and I think they have the right ideas.  Especially when it comes to leaving the kitchen sink out of containerization.
Let's add Rocket support to Kubernetes as a first class citizen.  It might greatly simplify things like networking.

Is anyone working on this? I'm very interested in rocket + kubernetes as well, in fact this was one of the reasons I started working on a rkt list subcommand.

AFAIK nobody is working seriously on this yet.
On Jan 24, 2015 6:07 AM, "Pierre Beaucamp"<EMAIL_ADDRESS>wrote:

Is anyone working on this? I'm very interested in rocket + kubernetes as
well, in fact this was one of the reasons I started working on a rkt list
subcommand https://github.com/coreos/rocket/issues/162.
--
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/2725#issuecomment-71318304
.

Actually, I believe the CoreOS folks are working on it.  Kelsey Hightower
tweeted something about it yesterday.  I'll try to find the tweet.
Brendan
On Jan 24, 2015 7:44 AM, "Tim Hockin"<EMAIL_ADDRESS>wrote:

AFAIK nobody is working seriously on this yet.
On Jan 24, 2015 6:07 AM, "Pierre Beaucamp"<EMAIL_ADDRESS>wrote:

Is anyone working on this? I'm very interested in rocket + kubernetes as
well, in fact this was one of the reasons I started working on a rkt list
subcommand https://github.com/coreos/rocket/issues/162.
--
Reply to this email directly or view it on GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/2725#issuecomment-71318304
.

—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/2725#issuecomment-71323061
.

@pierrebeaucamp @brendanburns Yep, we have started on the research side of things and allocating internal resources to make this happen. Over the next couple of weeks we should see a proposal from CoreOS regarding rocket integration.

Looking forward to it!
On Jan 24, 2015 11:08 AM, "Kelsey Hightower"<EMAIL_ADDRESS>wrote:

@pierrebeaucamp https://github.com/pierrebeaucamp @brendanburns
https://github.com/brendanburns Yep, we have started on the research
side of things and allocating internal resources to make this happen. Over
the next couple of weeks we should see a proposal from CoreOS regarding
rocket integration.
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/2725#issuecomment-71332617
.

Awesome!  Count me in to have an opinion, er I mean provide guidance on api
and abstractions.  :)
On Jan 24, 2015 11:08 AM, "Kelsey Hightower"<EMAIL_ADDRESS>wrote:

@pierrebeaucamp https://github.com/pierrebeaucamp @brendanburns
https://github.com/brendanburns Yep, we have started on the research
side of things and allocating internal resources to make this happen. Over
the next couple of weeks we should see a proposal from CoreOS regarding
rocket integration.
--
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/2725#issuecomment-71332617
.

That's good news! I'm looking forward to hear more about this soon.

I have enumerated the initial two design considerations for doing this in a Google Doc here:
https://docs.google.com/a/coreos.com/document/d/1NVEIQPU23eRlwXBn62VR3Sl4RthEnZvJUmlnpusDFDQ/edit#
Feel free to discuss on that doc. I am personally leaning towards the initial integration being the kubelet talking systemd to launch rkt processes.

I would prefer that approach as well.  Are you thinking transient units or creating actual units?

@smarterclayton It will have to create actual units with a naming scheme, I think. A restarted kubelet will need to rebuild the "what is running right now" state somehow.

We needed something like that anyway, the metadata on the units will let us recreate our state on restart.  It does mean that we would need to push that state function under the DockerInterface (or whatever it becomes now - ContainerInterface).
You can traverse the transient units, but for the naive host reboot case I think there's a lot of value in letting systemd own the "what is truth" and the kubelet brings it into sync with what the master thinks is truth.
----- Original Message -----

@smarterclayton It will have to create actual units with a naming scheme, I
think. A restarted kubelet will need to rebuild the "what is running right
now" state somehow.

Reply to this email directly or view it on GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/2725#issuecomment-72952403

Agree, I'd like to keep as much state as I can outside of the kubelet.
--brendan
On Wed, Feb 4, 2015 at 2:27 PM, Clayton Coleman<EMAIL_ADDRESS>wrote:

We needed something like that anyway, the metadata on the units will let
us recreate our state on restart. It does mean that we would need to push
that state function under the DockerInterface (or whatever it becomes now -
ContainerInterface).
You can traverse the transient units, but for the naive host reboot case
I think there's a lot of value in letting systemd own the "what is truth"
and the kubelet brings it into sync with what the master thinks is truth.
----- Original Message -----

@smarterclayton It will have to create actual units with a naming
scheme, I
think. A restarted kubelet will need to rebuild the "what is running
right
now" state somehow.

Reply to this email directly or view it on GitHub:

https://github.com/GoogleCloudPlatform/kubernetes/issues/2725#issuecomment-72952403
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/2725#issuecomment-72953639
.

@smarterclayton Do you know off the top of your head if systemd lets you get the [X-Foobar] sections out via dbus? We could serialize any state to [X-Kubelet].

It doesn't, I asked Lennart to put it on his list a while back but haven't checked recently.  He was open to adding it - agreed that it provided value.
----- Original Message -----

@smarterclayton Do you know off the top of your head if systemd lets you get
the [X-Foobar] sections out via dbus? We could serialize any state to
[X-Kubelet].

Reply to this email directly or view it on GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/2725#issuecomment-73107194

Awesome! Can't wait for this, especially after https://github.com/docker/docker/pull/10776#issuecomment-74346219

Hi folks,
Recently I did a rocket container runtime support for the k8s.
The branch is now in the coreos's k8s fork: https://github.com/coreos/kubernetes/pull/5
Basically in the PR, it defines the container runtime interface, and provids a rocket implementation for the interface. Since I haven't fully the abstract the existing docker code into the interface yet, I added a different code path for the container runtime/rocket.
Really eager to hear your opinions on the interface!
@dchen1107 @thockin @bgrant0607 @brendanburns

And here is an overview for that PR:
OVERVIEW
This PR is an initial attempt at adding support for Rocket to Kubernetes. It is largely functional but not fully complete. We are seeking feedback on the approach and for some of the outstanding issues. More details below.
CURRENT STATE

The kubelet is able to launch/stop/reconcile pods via Rocket (also with specified mount volumes)
Pods/Containers are managed by systemd: the pod and container info is stored in unit files as a JSON string, which can be fetched to do comparison and reconciliation.

TODO

[ ] Health Probing:
Exec in container, via nsenter directly, we have code in k8s doing this, seems to only need minor changes.
Or we can use rkt enter.

[ ] Restart Policy:
Since we use systemd to supervise container process, we can bake the restart policy in the unit file (which simplifies the sync pod logic). Unfortunately this solution is not generic for other container runtimes like docker or other future runtimes.

[ ] Image Puller and Security Configuration:
Implement the image puller/throttled image puller interface for Rocket. Also need to add command line options to allow Rocket to trust image sources.

[ ] Port Mappings
This needs support from Rocket: https://github.com/coreos/rocket/issues/624

[ ] Support More docker run Options:
Such as capability add/drop (which is approachable now).

[ ] Inspect the Pod/Container, Get status:
Get more runtime information about the container, like the creation time, the exit code, etc. I think most of them can be done via systemd.

[ ] Add e2e tests for the K8S/Rocket:
TBD.

ISSUE
TheVolumeMounts([{Name, Readonly, MountPath}, ...]) in a kubernetes container should also appear in ACI, otherwise we cannot mount the volumes to the path in the rkt container.
NEXT PLAN
Add the missing features for the current rocket implementation.
Refactor on the existing docker code to make it convergent with the new container runtime.

can't that be closed? isn't it implemented in upstream kubernetes?

@ibotty I believe so, CC @yifan-gu

Yes


ci(travis): Add Windows image

This PR tries to run the existing tests on a Windows image on Travis (additionally to AppVeyor). It investigates what adaptions might be necessary and what errors or blockers we hit along the way.

C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\VisualStudio\v15.0\AppxPackage\Microsoft.AppXPackage.Targets(2519,5): warning APPX0105: Cannot import the key file 'CordovaApp_TemporaryKey.pfx'. The key file may be password protected. To correct this, try to import the certificate manually into the current user’s personal certificate store. [C:\Users\travis\build\apache\cordova-windows\temp\platforms\testcreate 応用\CordovaApp.Windows10.jsproj]
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\VisualStudio\v15.0\AppxPackage\Microsoft.AppXPackage.Targets(2519,5): warning APPX0107: The certificate specified is not valid for signing. For more information about valid certificates, see http://go.microsoft.com/fwlink/?LinkID=241478. [C:\Users\travis\build\apache\cordova-windows\temp\platforms\testcreate 応用\CordovaApp.Windows10.jsproj]
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\VisualStudio\v15.0\AppxPackage\Microsoft.AppXPackage.Targets(2638,5): error APPX0002: Task 'ValidateAppxManifest' failed. Retrieving the COM class factory for component with CLSID {5842A140-FF9F-4166-8F5C-62F5B7B0C781} failed due to the following error: 8007045a A dynamic link library (DLL) initialization routine failed. (Exception from HRESULT: 0x8007045A). [C:\Users\travis\build\apache\cordova-windows\temp\platforms\testcreate 応用\CordovaApp.Windows10.jsproj]
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\VisualStudio\v15.0\AppxPackage\Microsoft.AppXPackage.Targets(2638,5): error APPX0002:  [C:\Users\travis\build\apache\cordova-windows\temp\platforms\testcreate 応用\CordovaApp.Windows10.jsproj]

windows is now deprecated, thanks for your contribution

2019 Jan would be very sad.


feat(Data/Matroid/Map): maps between matroids

This PR creates a new file with the machinery for transferring matroid structures between types. The most important definitions are Matroid.map, which pushes a M : Matroid α along f : α → β to give an N : Matroid β, and
Matroid.comap,  which pulls N : Matroid β back along f : α → β to get an M : Matroid α. The former requires f to be injective on the ground set of M, but the latter doesn't.
The original decision to define matroids with an embedded ground set within a type rather than just a structure on a type came with tradeoffs, and it is in places like this that they show up the most. For this reason, the file also defines several variants of map where the range/domain of the function in question is a coerced set rather than a type.
There is nothing mathematically interesting going on with these definitions, and maps and comaps are not central to matroid theory in actual research, but they are very useful in making formalization painless, as they save the work of painstakingly checking matroid axioms in many cases. They will be used in future PRs to define things like direct sums and linearly representable matroids.

bors r+


A-763/errors

This PR handles

connection and sending errors in TCP and TLS
message size errors in UDP and DTLS
client handshake errors
failed connection events reports to servers.
(There is also a little bit of test refactoring in preparation for the test pack story).

Merged via command line.


Add a new shared/cmd package with initial command I/O logic

This is a proof of concept of some unit-testable code that I'd like
to later use for making cmdInit testable (as per #2834).
It's small so should it be easy to review and because I wish to have
some feedback on the approach before moving forward. I hope that the
branch gives a feel of what further branches would look like.
As a general note, I feel it'd be important to improve coverage of the
parts that can be unit tested easily (so basically most higher-level
application logic except for system-level interactions). An advantage
of this type of approach is of course the possibility to work and test small
fragments of logic in isolation while developing them. I think this
can be done incrementally without too much disruption, if we agree.
Signed-off-by: Free Ekanayaka<EMAIL_ADDRESS>

New package should be golint clean and so added to the appropriate section in the static analysis test.

One code comment for this, stderr should be added to Context and used for errors. lxd_init.go can then set stdout and stderr to stdout to avoid the split in interactive mode, but errors should still generally be sent to stderr.

Now for the discussion on adding unit tests :)
I'm not against unit tests, far from it. I am however strongly opposed to "meaningless" unit tests, so those that are there pretty much exclusively to increase your code test coverage but won't help you find bugs or even worse, will be relying on buggy behavior.
So I'd like to see an increase in coverage for some of our more obscure code, things like the handling of the various security profiles (apparmor, seccomp, ...), id shifting (though we have some already), ... as those are areas where the code is very complex and a very minor change can have very significant consequences (regressing our security story).
I would however ask to stay away from code which merely string compares function output to existing output. I've seen such patterns in many other projects I contribute to and it means that changing one line of code requires you to change a dozen tests, which you'll usually do without any serious thinking about whether it's the right thing to do or not (so may in fact end up with a test that's checking for a bug).
I'd also recommend we don't try to implement complex mocking in Go. Mocking just isn't well suited for Go and usually requires you to define a ton of interfaces and alternative implementation of those to achieve anything. So while it's possible, my experience is that it makes it near impossible for newcomers to understand how anything gets called. I'd just stick to our system tests for such things.
As far as this branch, it's definitely borderline to what I think is useful unit testing. The things it checks for are pretty trivial and would stand out in a code review before the test even gets run (for those who forget to run the Go tests prior to Jenkins that is).
I'm however not against splitting those functions into a separate "cmd" package as at least the AskBool one can be used from the command line client too (lxc/remote.go) and so not against having a few tests for them since they'll be quick and won't needlessly break.

@brauner what do you think?

Stéphane Graber<EMAIL_ADDRESS>writes:

Now for the discussion on adding unit tests :)
I'm not against unit tests, far from it. I am however strongly opposed
to "meaningless" unit tests, so those that are there pretty much
exclusively to increase your code test coverage but won't help you
find bugs or even worse, will be relying on buggy behavior.

Agreed. As said, it's not just formal coverage, but about a way to make
it possible to run a tiny bit of code in isolation, and check for
errors. It makes it easier to develop, and let's not understimating the
self-documenting effect: if you are trying to understand a particular
piece of code in the middle of a stack, having tests for it and the
ability to tweak them and modify them is very useful (as opposed to make
those chances and trying to see their effect by recompiling the lxd
server and figure how to trigger that certain code path you want).
I'll keep you're point in mind when experimenting around this.

So I'd like to see an increase in coverage for some of our more
obscure code, things like the handling of the various security
profiles (apparmor, seccomp, ...), id shifting (though we have some
already), ... as those are areas where the code is very complex and a
very minor change can have very significant consequences (regressing
our security story).

I'm not familiar with that part, but I'll surely look when the occasion
comes.

I would however ask to stay away from code which merely string
compares function output to existing output. I've seen such patterns
in many other projects I contribute to and it means that changing one
line of code requires you to change a dozen tests, which you'll
usually do without any serious thinking about whether it's the right
thing to do or not (so may in fact end up with a test that's checking
for a bug).

Okay, if this happens I consider this bad testing. You really shouldn't
change tests mechanically since it means the same thing gets tested a
number of times, or you get some factoring problem either in the code or
the tests themselves.

I'd also recommend we don't try to implement complex mocking in
Go. Mocking just isn't well suited for Go and usually requires you to
define a ton of interfaces and alternative implementation of those to
achieve anything.

I don't think there's a need to mock anything in LXD except for the
boundaries, e.g.:
1 - priviliged system calls
2 - external executables (e.g. zfs tools)
These will be the tricky parts, but we can reason about a story if and
when needed. At this I'm mainly
I agree that staying away from mocks and interfaces as much as possible
is good.

So while it's possible, my experience is that it makes it near
impossible for newcomers to understand how anything gets called. I'd
just stick to our system tests for such things.

Yes, I'm not advocating complicating life. If it feels more complicated,
just shout.

As far as this branch, it's definitely borderline to what I think is
useful unit testing. The things it checks for are pretty trivial and
would stand out in a code review before the test even gets run (for
those who forget to run the Go tests prior to Jenkins that is).

Sure, but relying on machines is better than relying on
humans. Expecially when you get to change some code (as opposed to
introducing it anew).

I'm however not against splitting those functions into a separate
"cmd" package as at least the AskBool one can be used from the command
line client too (lxc/remote.go) and so not against having a few tests
for them since they'll be quick and won't needlessly break.

Thanks. I'm going to polish the branch a bit to also address your
comments.

Now for the discussion on adding unit tests :)

I'm not against unit tests, far from it. I am however strongly opposed to "meaningless" unit tests, so those that are there pretty much exclusively to increase your code test coverage but won't help you find bugs or even worse, will be relying on buggy behavior.

Yes, I agree.

So I'd like to see an increase in coverage for some of our more obscure code, things like the handling of the various security profiles (apparmor, seccomp, ...), id shifting (though we have some already), ... as those are areas where the code is very complex and a very minor change can have very significant consequences (regressing our security story).

I would however ask to stay away from code which merely string compares function output to existing output. I've seen such patterns in many other projects I contribute to and it means that changing one line of code requires you to change a dozen tests, which you'll usually do without any serious thinking about whether it's the right thing to do or not (so may in fact end up with a test that's checking for a bug).

I'd also recommend we don't try to implement complex mocking in Go. Mocking just isn't well suited for Go and usually requires you to define a ton of interfaces and alternative implementation of those to achieve anything. So while it's possible, my experience is that it makes it near impossible for newcomers to understand how anything gets called. I'd just stick to our system tests for such things.

As far as this branch, it's definitely borderline to what I think is useful unit testing. The things it checks for are pretty trivial and would stand out in a code review before the test even gets run (for those who forget to run the Go tests prior to Jenkins that is).

Yeah, I'm not sure that the testing this branch aims at is super useful to us. For example, the lxd init tests can already be tested by Jenkins itself. They just need to be improved. When I implemented them I left them in a bare state but they can easily be expanded to be way more precise and pedantic about what we expect. And this could all be done in shell. So for instance, I'm thinking about testing whether a network we requested via lxd init or a storage pool actually got created and so on. This is currently not checked for.

I'm however not against splitting those functions into a separate "cmd" package as at least the AskBool one can be used from the command line client too (lxc/remote.go) and so not against having a few tests for them since they'll be quick and won't needlessly break.

Yep.
So what I think we would very much profit from is to implement unit tests for individual helper functions that are quite important to us.  One example that springs to mind is e.g. GetErrno() and other functions in util.go and util_linux.go. They could gain some tests whether they actually do what they promise to do. There are a lot of those actually. Of course, some of them can't be tested that easily (e.g. ExecReaderToChannel() and so on. At least I don't see a good way. But if you do it would be good to have tests for them as well.).

One comment to fix, then please squash into a single commit (as the other two are review fixes) and we can merge.

@stgraber should be all good. I extracted Context.readAnswer since it will be common to other similar code.


poke for NetworkInfo is not implemented

If it is on purpose I'd appreaciate a
--- a/network-info-<IP_ADDRESS>/src/Network/Info.hsc
+++ b/network-info-<IP_ADDRESS>/src/Network/Info.hsc
@@ -53,6 +53,8 @@ instance Storable NetworkInterface where
         mac  <- (#peek struct network_interface, mac_address) ptr
         return $ NetworkInterface name ipv4 ipv6 mac

+    poke = error "poke @NetworkInferface: not implemented due ..."
+

 -- | Gets the address information for each of the network interfaces on
 --   the local computer.

kind of change.

Ping. The poke is still unimplemented.


Cloud Provider OpenStack: Instance snapshots

Instance snapshots are available to be created via Horizon, but not via ManageIQ. Once the instance image is created in Horizon, ManageIQ sees the image and gives the user the option to create a new instance from it. However, the initial instance snapshot creation request does not exist in ManageIQ, if we could work on getting that added.

@miq-bot move-issue manageiq-providers-openstack


Notifications iOS

Fell free to change the manifest texts.
We also need to add the icons.

@charleslavon @shelegdmitriy Please review the changes, thank you.


(SP: ) Sonar warning_investigate the reason of error

UPD:
Sonar docs

Set develop at sonar-project.properties (sonar.branch.name)

Completed


Symbols

When transcribing things, I need to be able to enter symbols. The most common ones are the symbols for female, male, and degrees.

duplicate of another issue


Add roles to allow agency admins and officers to view Agency documents

All users should be able to view all agencies.
An agency admin should be able to edit documents for their agency.

 Add roles to allow officers and agency admins to access Agency collection


(UnsupportedOperation) when calling the ModifyInstanceAttribute operation: Modifying 'disableApiTermination' is not supported for spot instances

When a terminate action has "force:true" attribute attempts to take action on an ec2 spot instance, the following error is received.  CloudCustodian should be modified to only attempt to call ModifyInstanceAttribute if disableApiTermination=true for the instance it should terminate.
An error occurred (UnsupportedOperation) when calling the ModifyInstanceAttribute operation: Modifying 'disableApiTermination' is not supported for spot instances.: ClientError
Traceback (most recent call last):
File "/var/task/custodian_policy.py", line 4, in run
return handler.dispatch_event(event, context)
File "/var/task/c7n/handler.py", line 109, in dispatch_event
p.push(event, context)
File "/var/task/c7n/policy.py", line 712, in push
return mode.run(event, lambda_ctx)
File "/var/task/c7n/policy.py", line 470, in run
results = action.process(resources)
File "/var/task/c7n/resources/ec2.py", line 1049, in process
self.disable_deletion_protection(instances)
File "/var/task/c7n/resources/ec2.py", line 1076, in disable_deletion_protection
list(w.map(process_instance, instances))
File "/var/runtime/concurrent/futures/_base.py", line 641, in result_iterator
yield fs.pop().result()
File "/var/runtime/concurrent/futures/_base.py", line 462, in result
return self.__get_result()
File "/var/runtime/concurrent/futures/thread.py", line 63, in run
result = self.fn(*self.args, **self.kwargs)
File "/var/task/c7n/utils.py", line 410, in _f
return f(*args, **kw)
File "/var/task/c7n/resources/ec2.py", line 1069, in process_instance
Value='false')
File "/var/task/c7n/utils.py", line 348, in _retry
return func(*args, **kw)
File "/var/runtime/botocore/client.py", line 317, in _api_call
return self._make_api_call(operation_name, kwargs)
File "/var/runtime/botocore/client.py", line 615, in _make_api_call
raise error_class(parsed_response, operation_name)
ClientError: An error occurred (UnsupportedOperation) when calling the ModifyInstanceAttribute operation: Modifying 'disableApiTermination' is not supported for spot instances.

the issue is partly that determining if disable api termination is enabled that requires another api call per resource. we could probably just detect that its a spot instance and not bother to modify it on force


Upsampling mode should apply during normal resampling

Currently --upsampling_mode=0 will only take effect with --already_downsampled, forcing you to downscale the image beforehand if it was previously enlarged rather than simply using --resampling=4 --upsampling_mode=0

I don't know could be 55% and 58% more sharp or 6% 8% less sharp in the medium frequencies.

I had forgotten about this issue, although while I'm here I realised nearest neighbour upsampling would only work if the downsampling is also nearest neighbour too, for pixel art at least. So it may be a more complex issue than I thought


3D Canvas

Don't work with 3d canvas addon

Are there errors in the console (F12 -> Console tab)? This module won't affect the 3D view, in case that is what your expecting.

Very likely needs changes on 3D Canvas side. If this is still an issue. Not sure if this issue was reported for V11 or V12. Closing because stale.


Port Lookup Integration

https://www.speedguide.net/port.php?port=22

https://whatismyipaddress.com/ip/<IP_ADDRESS>

Resolved in 1.1.3 release
https://github.com/Trippik/PfSense_Dashboard-Frontend/releases/tag/1.1.3


Fix constant epsilon bug and normalize readings to improve learning

Epsilon will never decrease as this is currently a division of integers. Changing dividend type to float fixes the issue.

Thanks @carriojazz!


[SPARK-37053][CORE] Add metrics to SparkHistoryServer

What changes were proposed in this pull request?
Add metrics system to history server.

Add metrics to History Server, with this patch we can plugin these metrics to any Dropwizard supported monitoring infra and get insights into the performance of SHS.
Does this PR introduce any user-facing change?
User can use history server monitor data
How was this patch tested?
Added UT

Test build #144400 has started for PR 34326 at commit ac64269.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/48873/

Test build #144404 has finished for PR 34326 at commit 719dda2.

This patch fails to build.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/144404/

Test build #144409 has started for PR 34326 at commit 719dda2.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/48879/

Test build #144409 has finished for PR 34326 at commit 719dda2.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Why are the changes needed?
Add metrics to History Server

Let's describe why. Why do we need this matrix?

Does this PR introduce any user-facing change?
User can use history server monitor data

How can users monitor which data?

Yeah, I know, still under organization, so add WIP tag

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/48912/

Test build #144439 has finished for PR 34326 at commit 719dda2.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

@AngersZhuuuu This would be helpful and is a clean implementation. Any chance to complete work on this ?
We can plugin these metrics to any Dropwizard supported monitoring infra and get insights into the performance of SHS.

@AngersZhuuuu This would be helpful and is a clean implementation. Any chance to complete work on this ?
We can plugin these metrics to any Dropwizard supported monitoring infra and get insights into the performance of SHS.

Yea,  will start this this week.

Test build #145304 has started for PR 34326 at commit 7bcb63c.

Test build #145304 has finished for PR 34326 at commit 7bcb63c.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
public class JavaModuleOptions
class SparkConf(object):
class ProbabilisticClassifier(Classifier, _ProbabilisticClassifierParams, metaclass=ABCMeta):
class ProbabilisticClassificationModel(
class _JavaProbabilisticClassifier(ProbabilisticClassifier, _JavaClassifier, metaclass=ABCMeta):
class _JavaProbabilisticClassificationModel(
class _LinearSVCParams(
class LinearSVCModel(
class _LogisticRegressionParams(
class LogisticRegression(
class LogisticRegressionModel(
class BinaryLogisticRegressionSummary(_BinaryClassificationSummary, LogisticRegressionSummary):
class BinaryLogisticRegressionTrainingSummary(
class DecisionTreeClassifier(
class DecisionTreeClassificationModel(
class RandomForestClassifier(
class RandomForestClassificationModel(
class RandomForestClassificationTrainingSummary(
class BinaryRandomForestClassificationTrainingSummary(
class GBTClassifier(
class GBTClassificationModel(
class NaiveBayes(
class NaiveBayesModel(
class _MultilayerPerceptronParams(
class MultilayerPerceptronClassifier(
class MultilayerPerceptronClassificationModel(
class MultilayerPerceptronClassificationTrainingSummary(
class FMClassifier(
class FMClassificationModel(
class _GaussianMixtureParams(
class GaussianMixtureModel(
class _KMeansParams(
class KMeansModel(
class _BisectingKMeansParams(
class BisectingKMeansModel(
class PowerIterationClustering(
class BinaryClassificationEvaluator(
class RegressionEvaluator(
class MulticlassClassificationEvaluator(
class MultilabelClassificationEvaluator(
class ClusteringEvaluator(
class RankingEvaluator(
class Binarizer(
class BucketedRandomProjectionLSH(
class BucketedRandomProjectionLSHModel(
class Bucketizer(
class ElementwiseProduct(
class FeatureHasher(
class HashingTF(
class _OneHotEncoderParams(
class PolynomialExpansion(
class QuantileDiscretizer(
class _StringIndexerParams(
class StopWordsRemover(
class VectorAssembler(
class VectorSizeHint(
class VarianceThresholdSelector(
class VarianceThresholdSelectorModel(
class UnivariateFeatureSelector(
class UnivariateFeatureSelectorModel(
class _LinearRegressionParams(
class LinearRegressionModel(
class IsotonicRegression(
class IsotonicRegressionModel(JavaModel, _IsotonicRegressionParams, JavaMLWritable, JavaMLReadable):
class DecisionTreeRegressor(
class RandomForestRegressor(
class _AFTSurvivalRegressionParams(
class AFTSurvivalRegression(
class AFTSurvivalRegressionModel(
class _GeneralizedLinearRegressionParams(
class GeneralizedLinearRegression(
class GeneralizedLinearRegressionModel(
class _FactorizationMachinesParams(
class FMRegressionModel(
class CrossValidator(
class TrainValidationSplit(
               + \"class name
class MultivariateGaussian(NamedTuple):
class PandasAPIOnSparkAdviceWarning(Warning):
class ResultIterable(Iterable[T]):
class ArrowStreamUDFSerializer(ArrowStreamSerializer):
class SparkJobInfo(NamedTuple):
class SparkStageInfo(NamedTuple):
public class NumericHistogram
   * The Coord class defines a histogram bin, which is just an (x,y) pair.
 public static class Coord implements Comparable
trait ExpressionBuilder
trait FunctionExpressionBuilder
case class ExpressionStats(expr: Expression)(var useCount: Int)
case class HistogramNumeric(
trait ExtractValue extends Expression with NullIntolerant
trait PadExpressionBuilderBase extends ExpressionBuilder
case class StringLPad(str: Expression, len: Expression, pad: Expression)
case class BinaryLPad(str: Expression, len: Expression, pad: Expression, child: Expression)
case class BinaryRPad(str: Expression, len: Expression, pad: Expression, child: Expression)
case class PythonMapInArrow(
case class CreateIndex(
case class DropIndex(
public class ColumnIOUtil
public class OrcColumnStatistics
public class OrcFooterReader
case class ParquetColumn(
case class CreateIndexExec(
case class DropIndexExec(
case class PushedDownOperators(
case class TableSampleInfo(
trait MapInBatchExec extends UnaryExecNode
case class PythonMapInArrowExec(
class RatePerMicroBatchProvider extends SimpleTableProvider with DataSourceRegister
class RatePerMicroBatchTable(
class RatePerMicroBatchStream(
case class RatePerMicroBatchStreamOffset(offset: Long, timestamp: Long) extends Offset
case class RatePerMicroBatchStreamInputPartition(
class RatePerMicroBatchStreamPartitionReader(
class SparkUDFExpressionBuilder extends FunctionExpressionBuilder

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/145304/

Test build #145305 has started for PR 34326 at commit 7015710.

Test build #145305 has finished for PR 34326 at commit 7015710.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/145305/

Test build #145307 has started for PR 34326 at commit 13af762.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/49774/

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/49775/

Test build #145307 has finished for PR 34326 at commit 13af762.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/49774/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/49775/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/49774/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/145307/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/49775/

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/49778/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/49778/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/49778/

Test build #145323 has started for PR 34326 at commit c8cb0fc.

@thejdeep @HyukjinKwon Update pr desc and add unit test to show the result. Hope for your review and can suggest if I have miss some thing that can be added to metrics.

Test build #145326 has started for PR 34326 at commit f2670c0.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/49794/

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/49797/

Test build #145323 has finished for PR 34326 at commit c8cb0fc.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/145323/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/49794/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/49797/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/49797/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/49794/

Test build #145326 has finished for PR 34326 at commit f2670c0.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/145326/

Test build #145330 has started for PR 34326 at commit 0daf56b.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/49801/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/49801/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/49801/

Test build #145330 has finished for PR 34326 at commit 0daf56b.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/145330/

Test build #145376 has started for PR 34326 at commit e173b55.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/49849/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/49849/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/49849/

Test build #145376 has finished for PR 34326 at commit e173b55.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/145376/

Test build #145395 has started for PR 34326 at commit 818eba6.

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/49868/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/49868/

Test build #145395 has finished for PR 34326 at commit 818eba6.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/145395/

Test build #145430 has started for PR 34326 at commit 06ae18f.

ping @HyukjinKwon  also ping @mridulm

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/49903/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/49903/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/49903/

Test build #145430 has finished for PR 34326 at commit 06ae18f.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/145430/

+CC @shardulm94, @zhouyejoe

Any suggestion?  Also ping @cloud-fan

cc @HeartSaVioR too FYI

Gentle ping on this, thanks.

Can any committer review this?

Gentle ping @dongjoon-hyun @HyukjinKwon @tgravescs @HeartSaVioR @srowen

Gentle ping on this, thanks.

It is great to see that more metrics are being added to History server.
Updating the listing.ldb is one of the major factors impacting the History server performance, there are several new metrics tracked for listing.ldb. But there is also another factor, which is generating each individual application levelDB when there is a user request. There are some metrics tracking the LevelDB generating time and loading time in this PR. Can you help add some more metrics, such as how many applications are being parsed to generated their own LevelDBs, and how many LevelDBs are currently stored in Disk, and what is the total size of them. Thanks.

It is great to see that more metrics are being added to History server. Updating the listing.ldb is one of the major factors impacting the History server performance, there are several new metrics tracked for listing.ldb. But there is also another factor, which is generating each individual application levelDB when there is a user request. There are some metrics tracking the LevelDB generating time and loading time in this PR. Can you help add some more metrics, such as how many applications are being parsed to generated their own LevelDBs, and how many LevelDBs are currently stored in Disk, and what is the total size of them. Thanks.

Update a change. And I want confirm with you that:

If we don't set spark.history.store.path, it will use memory to store app info and it's not belong to LevelDB metrics, right?
Only when support hybrid store disk backend,  then we have in-memory LevelDBs, right?

at a high level seems fine, I need to take a more detailed look at a few parts. It also needs docs.

Doc added.

ping @tgravescs

Gentle ping on this. Thank you!

If we don't set spark.history.store.path, it will use memory to store app info and it's not belong to LevelDB metrics, right?

Yes, correct. In this case, it will only use the in memory key value store.

Only when support hybrid store disk backend,  then we have in-memory LevelDBs, right?

I don't quite get the question here. When hybrid mode is enabled, the in-memory store used during parsing is called InMemoryStore, not the actual LevelDB.

gentle ping @tgravescs

Any suggestion? @tgravescs


Dynamically generate chart config based on place's stats vars

Move chart config generation to server side.
Do not show chart sections if not available.
Better handle child and parent places in dropdown menu.
Remove places types from config since chart display is based on statsvars.

I will fix the codacy lint issues in next PR where i will ad tslint


Improvements

Some (maybe opinionated) improvements to this project in order to obtain a full "double repl" workflow.

Love this work, I really appreciate it!
I'm not entirely sure about the serve task though. My thinking has been that the server would serve any assets that the frontend task created.
This isn't so clear on master, as we have an empty system, but the yada branch does handle this kind of serving.
Is there a use case I am missing for the serve task?

You are definitely right, this is a left over of my project, which has been largely inspired by edge, especially the part for having the nRepl start inside a pod.
I will remove that commit and push force.


Regularly reconcile validation CNAME record for ACM certificate of irsa.<basedomain>

See chat about expiring certificate. The irsa-operator code may not be correct.
Seems the irsa-operator takes action only if the certificate is not existing yet, same one-time action is take if the certificate is not validated yet.

related ticket: https://github.com/giantswarm/giantswarm/issues/29986

There were two problems with this:

We didn't perform the validation on renewal, only if the certificate hasn't been issued at all yet.
We weren't checking properly for validation. Once the initial certificate is validated, the validation status will always be successful on the resource. For renewal there is a separate renewal status which shows PENDING_VALIDATION.

Once https://github.com/giantswarm/irsa-operator/pull/232 is merge and release this issue should be closed

Fixed in https://github.com/giantswarm/irsa-operator/releases/tag/v0.26.1


M1.5: Fix eslint and add it to Github actions

We need to fix eslint and add it to github actions
AC

Fix eslint
Github needs to check eslint before merge

All the ACs are done


Verify pin for create wallet,change spending PIN and start up PIN

This fixes:
https://github.com/raedahgroup/dcrios/issues/154
the app now asked users for confirmation PIN.

closes #167


Adjust jenkins plugin affected ranges on GHSA-62jv-j4w7-5hh8

https://github.com/advisories/GHSA-62jv-j4w7-5hh8 cannot currently be contributed to directly because it uses a > which violates the OSV spec (https://github.com/github/advisory-database/discussions/166)
The current version range on the advisory cuases the full release version 1371.1373.v4eb_fa_b_7161e9 which fixes CVE-2024-47805 to show as affected because it falls into the > 1371.1373.v4eb, < 1381.v2c3a range.
I think the ranges should be something like:

>= 1372, < 1381.v2c3a_12074da_b_
< 1371.1373.v4eb_fa_b_7161e9

Hi @westonsteimel, I just changed > 1371.1373.v4eb, < 1381.v2c3a to >= 1372, < 1381.v2c3a. The system throws an error when I try to include underscores in version numbers, so I've stopped at the last character before the first underscore in each number.
It appears to me the affected versions for the advisory came from the Jenkins Public tab of https://mvnrepository.com/artifact/org.jenkins-ci.plugins/credentials?repo=jenkins-public. This tab lists unaffected versions 1371.1373.v4eb_fa_b_7161e9 and 1381.v2c3a_12074da_b_, so one might even be able to use >= 1378.v81ef4269d764, < 1381.v2c3a as a VVR, but I think >= 1372, < 1381.v2c3a is the optimal solution for alerting potentially affected users.


Inconsistent Formatting in Header Links

Kind of issue
Design
Description
Brand names in the header are inconsistently formatted. I would assume, given they're titles or brand names, that they should be capitalized as below, except when stylized a certain way:

[ ] Repository (currently 'repository')
[x] npm (correctly formatted, name is stylized lowecase)
[ ] Packagist (currently 'packagist')
[x] jsDelivr (correctly formatted)
[ ] UNPKG (currently 'Unpkg')
[ ] Legal Disclaimer (currently 'Legal disclaimer')

I agree with all of your formattings @adamrusted, thanks for noticing!


Fix analyzer error

Analyzer appears to have become more strict.

LGTM! Please merge.

did you see #702 ?

@a14n I did now. Thanks!


stock_alarm, fixes #1842

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

感谢提交 Pull Requests！
Thanks for submitting a pull request.

start build

手动触发！
感谢 Pull Requests！
Thanks for submitting a pull request.

Security Check : d3b6a948b78659d042756e0567db37bb0507c92f

auto build success,number:230

autotest fail,number:1724


Deselecting on mountain label should use small close-cross

Hovering the  label or the mountain, the small cross Circle should show up to the right of the Label in the mountain chart. By clicking a selected country´s shape, you can deselect it. And by clicking the label you also deselect it. I just want the cross sign to show up so that it's clear that you can get rid of the selection.
On touch screen, there must be a DESELECT button popping up. So the first click is like HOVER and then you select or deselect by explicitly clicking buttons with those words.

Make the same style of the cross as we have in bubblechart-component.js labels

https://github.com/Gapminder/vizabi/pull/595

https://github.com/Gapminder/vizabi/pull/614

https://github.com/Gapminder/vizabi/pull/626

done


test: add pytest-snapshot tests for TPC-H outputs

Merging in b/c/ the branch protection rules are out-of-date (and were a tad premature)


Not able to run manage.py file

In the sandbox, and in setting file, there is already  'compressor', 'django_simple_forum',  present. Then why in readme.md file it is written for doing it again. As manage.py present in sandbox and when I am going there and trying to run.
python manage.py runserver
Then is showing me some random error.
OSError: [Errno 20] Not a directory: '/home/ankur/anaconda/lib/python2.7/site-packages/django_simple_forum-0.0.5-py2.7.egg/django_simple_forum/migrations'
When i am making virtual environment then also there is problem in running this Django Project.

I to got the same error try moving the contents of that sandbox outside that folder and make the project structure look like this.

This worked for me, and if you still have problems then try checking the urls.py file inside that test_django_simple_forum folder.


Spotify can't play this right now. If you have the file on your computer you can import it.

Describe the bug
I have setup librespot-java (via spocon https://github.com/spocon/spocon)
I set the output to pipe and setup both the music pipe and the metadata pipe.
Not sure if it matters but the other end of the pipes is owntone.
On starting playing the first time I get the error message "Spotify can't play this right now. If you have the file on your computer you can import it." however the song still plays.
The error message also comes back on pausing tracks.
To Reproduce
As above
Expected behavior
I don't expect the error message.
Screenshots/Stracktraces/Logs
Screenshots if applicable, stacktrace and log is a crash occurred.

Version/Commit
v1.6.2

This also happens on playing / pausing. Checkign the SPOCON log there isn't anything obvious.


feat(tooltip): added marker options. close #13413

Brief Information
This pull request is in the type of:

[ ] bug fixing
[ x ] new feature
[ ] others

What does this PR do?

Adds a new feature to adjust tooltip radius, height, and width.
Fixed issues

Details
Before: What was the problem?

There should be a configuration option for the tooltip marker size.

After: How is it fixed in this PR?

radius: "10px",
height: "10px",
width: "10px"

Usage
Are there any API changes?

[ ] The API has been changed.

Related test cases or examples to use the new APIs
NA.
Others
Merging options

[ ] Please squash the commits into a single one when merge.

Other information

Hi, thanks a lot for your first contribution!
We only need to commit the changed source files which are in the src directory. It's unnecessary to commit the distribution files which are in the dist directory. And it would be better if some test cases can be provided.
Please make some changes to this pull request accordingly. Thank you.

I will do this. Sorry it's my first time doing these things.

Take it easy. You are welcome to do this. We appreciate any forms of contribution.


Link to queries available through API points to current page

Looking at our API page, the link
 points to the current page.

Where does this link actually need to point to? To here?

Perhaps @antw has other ideas but that would be my guess. It would be even better if we had an overview page with a list of queries. Something like
here but with some explanations (I realise that last thing is a lot of work)


new issue

Windows Version
11
WSL Version
11
Are you using WSL 1 or WSL 2?

[X] WSL 2
[ ] WSL 1

Kernel Version
No response
Distro Version
No response
Other Software
Error: 0x800701bc WSL 2 requires an update to its kernel component. For information please visit https://aka.ms/wsl2kern
Repro Steps
Error: 0x800701bc WSL 2 requires an update to its kernel component. For information please visit https://aka.ms/wsl2kern
Expected Behavior
Error: 0x800701bc WSL 2 requires an update to its kernel component. For information please visit https://aka.ms/wsl2kern
Actual Behavior
Error: 0x800701bc WSL 2 requires an update to its kernel component. For information please visit https://aka.ms/wsl2kern
Diagnostic Logs

no

/logs


[v1.7.2rc2c] No QR codes on LCD

The display device seems to have changed.
The LCD is not on /dev/fb1 any more, but on /dev/fb0
And it is not writable with admin:
$ sudo ls -la /dev/fb0
crw-rw---- 1 root video 29, 0 Feb 12 20:40 /dev/fb0

Will need sudo for /dev/tty1
ls -la /dev/tty1
crw------- 1 root root 4, 1 Feb 12 20:52 /dev/tty1

Need to test HDMI

Right, it seems that the script was taking care of this behaviour, the original problem is caused by the lack of sudo with fbi.

OK PR merged.


Support a Prometheus metrics endpoint

Enable metrics collected from the Jaeger client, and the service (application) being instrumented, to be reported to a prometheus compatible metrics system.
Initial suggestion is to record some generic metrics related to any Spans of certain span.kind, such as client, server, producer, consumer.
Metrics names could be based on service, operation and span.kind.
A counter could be reported for the invocation of the service\operation\spankind. A counter could also be recorded for any span that has an error tag of true.
Protocol specific scenarios should also be considered - for example with HTTP we may want to record counters regarding the status code categories, e.g. 4xx, 5xx.

Is the goal to observe the behavior of the tracer, or behavior of the application? We already have internal metrics for the tracer, and in Go we have a model for reporting (inbound) RPC metrics that we were planning to extend to other languages (but we need to make it less HTTP specific).
As for Prometheus, I think it's a different issue of implementing StatsFactory.

Is the goal to observe the behavior of the tracer, or behavior of the application?

I think having both would be useful, as you have demonstrated in the Go client.
Would be great if a consistent approach can be used across all languages to record app metrics for inbound and outbound communications in a protocol independent way, although as mentioned, we may want some protocol specific metrics.

I agree, we need to get all clients to use the same metrics naming scheme, which is not the case today.
For RPC metrics, the latest discussion we had internally was to use the following scheme (first is the metric name, the rest are tags):
name:       jaeger-rpc.{requests, request_latency}
service:    myservice
endpoint:   fooendpoint
result:     {ok,err}
error:      {4xx,5xx,app-error,sys-error,rate-limit,timeout,...}
transport:  {http,tchannel,...}
direction:  {inbound,outbound}

Some of these tags require additional help from instrumentation
The actual tracer behavior is, I think, already well captured in the metrics, but they do differ in the naming scheme between languages (in some languages we did not use tagged metrics)

Looks a good start. Some suggestions:

name - possibly just jaeger rather than jaeger-rpc - to avoid RPC specific
name value - just latency, and maybe something more generic other than requests to cater for messaging as well
endpoint - could this be operation to more directly relate to the span data
transport - is this because the same endpoint may use multiple protocols?
what about adding a location based tag - either hostname or ipaddr - so when multiple instances of the service it would be possible to isolate the metrics related to a particular instance that may be having problems?

name - possibly just jaeger rather than jaeger-rpc - to avoid RPC specific

Can do.

endpoint - could this be operation to more directly relate to the span data

Also can do.

transport - is this because the same endpoint may use multiple protocols?

Technically, yes. However, there is currently no standard tag that identifies the transport, so the only one we can reliably detect is HTTP, by the presence of other tags like http.url and http.status_code

what about adding a location based tag - either hostname or ipaddr

Our practice has been to leave these to the application itself. I.e. when initializing the tracer with metrics factory, the factory can already be created with some tags like the hostname. This way the tracer does not need to worry about it. Attaching the host name by default is not a great behavior, because it multiplies the number of all time series by the number of hosts, putting a lot of extra pressure on the metrics backend.

Question directly related to the issue title - is there some Java framework similar to go-kit that provides abstraction over different metrics implementations?

We are not aware of one.

Wouldn't dropWizard metrics be the "standard" ?

Not to mention I don't personally understand the Prometheus part at all, given that Java has a standard way of exposing metrics already (JMX). But DropWizard metrics allows exporting to multiple different formats by just dropping a different library to the classpath (without any need for modifications to the original library)

Dropwizard metrics are popular, but they are not an abstraction but rather a specific opinionated implementation.
Microprofile has a proposal (https://github.com/eclipse/microprofile-evolution-process/pull/26) but it wasn't approved yet.

One reason for the Prometheus suggestion is it is polyglot so can provide a consistent solution across all the supported clients.

Prometheus is still a lock-in to a specific metrics format. Our current approach is to write metrics to an internal API, and implement adapters from that API to other metrics APIs, like Dropwizard and Prometheus Java client.

Agree need an abstraction to support other formats. But this issue is specifically about providing a Prometheus impl. So not suggesting it should be the one and only impl.

Have created an issue https://github.com/opentracing-contrib/java-metrics/issues/1 to discuss a possible naming scheme.
The proposal defines a small set of standard labels with the ability to add/override where necessary, which I believe should meet Jaeger's requirements.

Wondering whether there could be further naming alignment with opentracing terms, e.g.

result and error - possibly either error as a boolean field (as in OT) with error_type to represent more specific value - or just collapse into single field error with value false or no for no error, and other values representing the error type

direction - use span kind instead where inbound is effectively represented now by server/consumer, and outbound is client/producer

http://micrometer.io/ this seems promising. Part of spring boot 2.0 so it will be widely used.

@mabn - lgtm. The documentation is a bit weird, considering that the lib claims to provide abstraction over different metrics implementation, but all documentation is actually split by implementation. But it looks like the CompositeMeterRegistry is what we'd need.
The Jaeger libraries are always defining their own metrics API anyway, but we can have a module that binds that API to micrometer API.

Done as part of #335.


hugo main build incorrect path for css

incorrect path in public/index.html
line 19

and after deployment, my github page look like this

after I fix the path, everything is ok

Hey, Thanks for opening the issue. Can you share your config file.

https://github.com/supercaizehua/blog-resources/tree/master/supercaizehua

Just add a trailing /   to your baseURL
https://github.com/supercaizehua/blog-resources/blob/d3bd36db7929acb8558afb6cf314c4f429bb0496/supercaizehua/config.toml#L1

problem solved


Postgres FDW / Sqlite Virtual Table for PartitionMsgpackDataFile

Write a Foreign Data Wrapper for that can read and query PartitionMsgpackDataFile format files. The goal is to be able to attach these files to a warehouse without actually loading them in. It should be possible to write queries with them, and combine them together into views.
There should also be code that will generate the FDW creation DDL (CREATE FOREIGN TABLE), including the proper schema for the table for the specific data file.
Also implement the Qual object to do efficient filtering on the returned values.
Pay particular attention to the lifesystem of the FDW, and the creation of server processes associated with them. The system must be able to handles hundred to thousands of  wrappers simultaneously.
Make sure it works with Sqalchemy: http://multicorn.org/sqlalchemy_fdw/. Use the sqalchemy FDW support for creating the FDW in the warehouse.
Create the FDW servers in a schema in the library database, parallel to the ambrylib schema, in a schema named 'partitions'
Similarly, there virtual tables can be developed for Sqlite, using http://apidoc.apsw.googlecode.com/hg/vtable.html

Q. How can I find schema of the partition? PartitionMsgpackDataFile has data only (header and rows).
A. The schema is the partitions table and columns. For partition p, p.table and p.table.columns. The table schema is available after running the meta phase.
Q. What is Qual object?
A. It’s referenced in the documentation for Multicorn. http://multicorn.org/implementing-an-fdw/
Q. I can't find any *.msg files. Where will those files be located?
A. After building a bundle,
        partitions = list(b.partitions)
        p0 = partitions[0]
        datafile  = p0.datafile
        system_path = datafile.syspath

p0.datafile will only work if the partition is fetched from the bundle, and specifically, if bundle.wrap_partition() is called on the partition.
Q. What is the typical use case of the feature?
A. The typical case will be user creates a VIEW in the warehouse that uses table data, and rather than installing the data in the warehouse as was done pre 1.0, in this case, the view uses the partition data from a FDW.
A lot of the time, we’ll create a MATERIALIZED VIEW that references the foreign table, and users will use the materialized view, to allow faster access, and ( I hope ) indexes.
Q. Where should I put new code?
A. Delete everything under ambry/warehouse and put it as a module there.

Q. How can FDW recognize compressed file? Should it read compressed or raw or both?
A. For now, just assume they are compressed

Both implementations moved to https://github.com/CivicKnowledge/ambry_sources . See CivicKnowledge/ambry_sources#1 for further progress.


feat: Add dependencies field to ComputedFieldInfo

Change Summary
Allows the model creator to give a hint as to which other fields a computed_field depends on:
    class Model(BaseModel):
        width: float
        height: float

        @computed_field(dependencies=['width', 'height'])
        @property
        def area(self) -> float:
            return self.width * self.height

Related issue number
closes #9893
Checklist

[ ] The pull request title is a good summary of the changes - it will be used in the changelog
[ ] Unit tests for the changes exist
[ ] Tests pass on CI
[ ] Documentation reflects the changes where applicable
[ ] My PR is ready to review, please add a comment including the phrase "please review" to assign reviewers

cc @sydney-runkle, this really was all i was proposing for now.  I stopped short of adding dependentRequired to the JSON schema output, since i'm not sure it's a perfect semantic match.  but I could add that if you or others would like

I stopped short of adding dependentRequired to the JSON schema output, since i'm not sure it's a perfect semantic match

Indeed seems like dependentRequired makes more sense a a validation schema (and computed_fields are only relevant during serialization), as in "if foo is provided, bar should be provided as well). It could make sense during serialization as well ("if foo is present, bar is guaranteed to be there as well), although this does not really apply here, as I don't think there's a native way with Pydantic to express this conditional presence of a field during serialization.

Tentatively looks good to me, but I have a feeling that folks will want to extend the functionality of this beyond just JSON schema. This is a great place to start though!

@sydney-runkle note that this PR does not add anything related to JSON Schema yet, and as discussed in the previous comments dependentRequired isn't truly related

Going to chat with the team about this at our oss meeting tomorrow - will follow up after that!

Alright, after thinking more about this, I think @Viicos has a good point here: https://github.com/pydantic/pydantic/issues/9893#issuecomment-2228091121

So perhaps a metadata generic argument, typed as dict[str, Any]. I'll note that this isn't specific to computed_field, it could be used for normal fields as well.

I think it'd make sense to take this approach here and also sets us up well for future requests like this one.
I'd be more inclined to introduce dependencies independently if we reflected said info directly in the JSON schema, or if we could enforce the dependency. @adriangb had a good point here about the difficulties of that approach: https://github.com/pydantic/pydantic/issues/6085#issuecomment-1599092334. Basically, enforcing dependencies between fields is difficult, and not something we're planning on doing.

I think it'd make sense to take this approach here and also sets us up well for future requests like this one.

that approach was basically to leave it up to end users to come up with their own conventions for expressing what fields a computed field may depend on, correct?  In other words, to make a generic, unstructured key value field for arbitrary data that can be used for anything?
If I'm understanding that correctly, then I think that leaves us with a problem.  When considering computed fields, the docs say:

The computed_field decorator can be used to include property or cached_property attributes when serializing a model or dataclass. This can be useful for fields that are computed from other fields, ...

What fields, you may ask?   That's exactly what I'd like to establish an answer for, and I'd like to do it in a way such that little pockets of the community don't solve with their own incompatible conventions.
As a bit of background, I maintain libraries (like psygnal, magicgui, and others) that support pydantic models and provide runtime event-based GUIs.  If someone uses computed fields, it becomes very hard to know whether those values have become "stale" without knowing which fields those computed fields depend on.
Can you help me understand what your current recommendation would be for that issue?  Is it indeed to come up with your own convention and encourage people to use it?

I think it'd make sense to take this approach here and also sets us up well for future requests like this one.

I suppose more so what I meant here is that if we add a metadata attribute, folks can add all sorts of data to that depending on their varied needs, and that prevents us from the sort of bloating that we see with ConfigDict and Field, where we've catered to perhaps too many use cases.
I think you make a good point in general, I'm just hesitant to introduce a dependencies attribute. It feels to me like this implies either enforcement or some sort of reflection in the JSON schema, which is currently lacking.
I can see the value in having an endorsed way to communicate said dependencies, though. I'm torn.
@samuelcolvin is currently ooo, but should be back soon, and I can ask his opinion on this change when he returns? Then we could move forward from there?

Yep sounds good.  I understand the hesitation to be sure. 👍

It is true indeed that with a metadata field instead of an explicit dependencies argument, there's no way to "enforce" the structure (at least from a documentation pespective). However, the primary (if not the only) feature computed_field fulfills is to be able to dump the property value (and thus having it included in JSON schema).
This dependencies concept is also applicable for plain<EMAIL_ADDRESS>I could have the following plain dataclass defined:
from dataclasses import dataclass

@dataclass
class A:
    a: int

    @property
    def prop(self) -> int:
        return self.a * 2

And a similar request to have dependencies specified would be valid as well.

You are currently supporting Pydantic models in your libraries but it could be very much possible to have someone requesting support for dataclasses, msgspec, (c)attrs, etc. One alternative way to specify these dependencies would be with a decorator:
from pydantic import BaseModel

class Model(BaseModel):
    ...

    @property  # or `@computed_field`
    @depends_on("...")
    def prop(self): ...

That way you enforce yourself how dependencies should be specified, and it could be used in the future for other dataclass-like libraries.

Thanks @Viicos I agree on all cases.  I don't actually just support pydantic, I support arbitrary dataclass-likes via fieldz: https://github.com/pyapp-kit/fieldz
I recognize that this could be a general pattern, but so too is "computed_field" in general.  Pydantic didn't really need to add the computed_field decorator in the first place, simply supporting plain properties would have worked fine.
I am definitely always considering ways that I can do this stuff on my own, but inasmuch as a library like pydantic begins to formalize these concepts that I've generally made my own workarounds for, I'm interesting in discussing these formalizations in such a way that not everyone has to roll their own decorator solutions.  I get that it doesn't immediately solve the entire ecosystem problem, but given pydantics place in that ecosystem, it does seem like a good place to discuss these conventions in a way such that we can possibly all unify.  That's my interest here.

So, to perhaps summarize/clarify the state of things here, if the pydantic core devs wish to avoid getting involved in any way in a specification/recommendation for declaring relationships between a computed_field and other fields (which I can definitely understand), we can close this issue and encourage third party libraries to just create their own solutions

I am definitely always considering ways that I can do this stuff on my own, but inasmuch as a library like pydantic begins to formalize these concepts that I've generally made my own workarounds for, I'm interesting in discussing these formalizations in such a way that not everyone has to roll their own decorator solutions. I get that it doesn't immediately solve the entire ecosystem problem, but given pydantics place in that ecosystem, it does seem like a good place to discuss these conventions in a way such that we can possibly all unify. That's my interest here.

This is such a great point, it's almost worth putting it up on our contributors page as a model open source perspective. We very much appreciate your encouraging discussions regarding such formalizations.

So, to perhaps summarize/clarify the state of things here, if the pydantic core devs wish to avoid getting involved in any way in a specification/recommendation for declaring relationships between a computed_field and other fields (which I can definitely understand), we can close this issue and encourage third party libraries to just create their own solutions

We would like to avoid the dependencies argument for now, so I'm going to close this as not planned.

edit: if a metadata field was added, I'd be somewhat satisfied even with just a note in the pydantic documentation "recommending" a format for including dependencies in the metadata. Mostly just want to avoid a bunch of roll-your-own solutions to indicating relationships between computed and other fields

@tlambert03, could you please open an issue with the metadata concept as a feature request? I'd love to move forward with that approach.


build: publish dart on release, fix semver for kt and dart

This fixes two issues:

publish-dart.yml wasn't being triggered because it was waiting for a new v#.#.# tag which was being pushed by the release.yml workflow. But GH actions generally can't trigger other GH actions (to avoid infinite robot dance loops)
the kotlin build was publishing artifacts with the prior version because it wasn't waiting for the JS build to first calculate the new v

This fixes both by moving dart publishing into the release.yml workflow and sequencing both the dart and kotlin jobs to run after the js job publishes the new v#.#.# tag.

Blarg, this failed (pub.dev rejects GH actions that aren't directly triggered by a tag push -- so it can't come from this workflow. I'm going to manually publish for now and revisit this later.


Update Dockerfile.template

@shaunmulligan

LGTM

@shaunmulligan amended, you'll have to merge because I don't have correct permissions to that repo for some reason.


refactor(theme-translations): update Russian translations

Motivation
Translation update
Have you read the Contributing Guidelines on pull requests?
Yes

@lex111 Could you review this?

Yes, can confirm, this translation is fine, thanks.


[CELEBORN-1056] Introduce Rest API of listing dynamic configuration

What changes were proposed in this pull request?
Introduce Rest API of listing dynamic configuration /listDynamicConfigs to list the dynamic configs. The result of /listDynamicConfigs is as follows:
=========================== Dynamic Configuration ============================
celeborn.master.ha.ratis.raft.server.snapshot.auto.trigger.threshold          100000
celeborn.worker.flusher.buffer.size                                           64k
=========================== SYSTEM ============================
celeborn.master.ha.ratis.raft.server.snapshot.auto.trigger.threshold          200000
celeborn.worker.flusher.buffer.size                                           128k
=========================== TENANT ============================
=========================== Tenant: tenantId1 ============================
celeborn.master.ha.ratis.raft.server.snapshot.auto.trigger.threshold          300000
celeborn.worker.flusher.buffer.size                                           256k
=========================== TENANT_USER ============================
=========================== Tenant: tenantId1, Name: user1 ============================
celeborn.master.ha.ratis.raft.server.snapshot.auto.trigger.threshold          400000
celeborn.worker.flusher.buffer.size                                           512k

Why are the changes needed?
Celeborn supports dynamic configuration with ConfigService at present. It's recommend to introduce Rest API of dynamic configuration management.
Does this PR introduce any user-facing change?

Introduce Rest API of listing dynamic configuration: /listDynamicConfigs?level=[system|tenant|tenant_user]&tenant=tenantId1,tenantId2&name=user1,user2.

How was this patch tested?

HttpUtilsSuite#CELEBORN-1056: Introduce Rest API of listing dynamic configuration

Introduce Rest API of listing dynamic configuration management ? Since we may support setting restful API later

@AngersZhuuuu, thanks for detailed review. I have addressed above comments and updated the title and description of this pull request. PTAL.

@AngersZhuuuu, thanks for detailed review. I have addressed above comments and updated the title and description of this pull request. PTAL. cc @RexXiong.

Merge to main(v0.5.0).


Galaxy bias as cobaya theory

This will implement a cobaya theory class to calculate power spectra with a bias term (e.g. linear galaxy bias).
To begin with this will just be a constant linear bias
Pk_gg = b_lin**2. Pk_mm
but other subclasses can contain more sophisticated bias models (including ones calculated by external codes such as velcileptors or fastpt).
Merging will close #33.

I guess your calculate function always gets the Pk even if the class isn't actually asked to calculate anything.
Rather than sampling a mock, you could call get_model() and then add_requirements (https://cobaya.readthedocs.io/en/latest/models.html?highlight=get_model#model.Model.add_requirements) to tell it something that you need to compute. There's an example at https://cobaya.readthedocs.io/en/latest/cosmo_model.html
Or maybe you can add a "requires" argument for Pkgg to the likelihood in the yaml (not tried it).

That works, thanks! I had tried add_requirements but hadn't forced the model computation.

@damonge just re-requested a review before I meant to... sorry.


Not upload file to release

My config as follow:
name: Release
on:
  push:
    tags:
      - "release-v*"

jobs:
  release-to-gitHub:
    name: Release to github
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v1
      - name: Set up JDK 1.8
        uses: actions/setup-java@v1
        with:
          java-version: 1.8
      - name: Asseble release
        run: |
          ./gradlew app:assembleRelease --info
          cp app/build/outputs/apk/release/app-release.apk ${GITHUB_REF:10}.apk
      - name: Upload
        uses: softprops/action-gh-release@v1
        with:
          files: ${GITHUB_REF:10}.apk
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Runtime log:
Run softprops/action-gh-release@v1
👩🏭 Creating new GitHub release for tag release-v1.0.2...
🎉 Release ready at https://github.com/stefanJi/dots365/releases/tag/release-v1.0.2

But release not file. See https://github.com/stefanJi/dots365/releases/tag/release-v1.0.2

Hi @stefanJi I'm not sure if I'm reading this right but when I look at your https://github.com/stefanJi/dots365/releases/tag/release-v1.0.2 I see the release.apk asset uploaded.


why the hell is axios a dependency

xorraxraxret,
Your account has been blocked from contributing to is-odd-ai due to recent abusive comments directed at other community members. This behavior violates our project's standards for respectful and constructive communication.
We encourage you to reflect on this and consider how you can engage more positively in open-source communities. If you wish to contribute in the future, please ensure your interactions align with our community guidelines.

xorraxraxret,
Your account has been blocked from contributing to is-odd-ai due to recent abusive comments directed at other community members. This behavior violates our project's standards for respectful and constructive communication.
We encourage you to reflect on this and consider how you can engage more positively in open-source communities. If you wish to contribute in the future, please ensure your interactions align with our community guidelines.

good thing i wasnt contributing


Custom Task controller for testing

In order to write better integration/e2e tests for custom Tasks, it would be useful to have a controller that watches for Runs of some kind we just use for testing, and install this controller when running e2e tests. This controller could do any of:

wait indefinitely
set the status to "succeeded"
set the status to match some boolean succeeded/failed set in the spec.

This controller shouldn't be packaged with Tekton releases.

planning to reuse https://github.com/tektoncd/experimental/tree/main/wait-task for this

/assign XinruZhang

Thanks for writing the issue Lee! I may need some extra clarifications:

set the status to match some boolean succeeded/failed set in the spec.

Do you mean we define some boolean fields in the spec and set those fields in status as what are set in the spec.

This controller shouldn't be packaged with Tekton releases.

Will codes under test/ be packaged with Tekton release?

Hi @lbernick what do we need for the wait infinitely?  Is the current wait-task controller enough?

This was just a suggestion of what we could write the controller to do-- I was just brainstorming simple behaviors that are easy to understand for testing. It really depends on what tests we want to add and what controller behavior would be most helpful for those tests. It seems to me like the wait task has given us what we need? So I'm going to close this as completed in #5332.

Thanks for the quick reply! I guess we still need the second and third to simulate the behavior of a the controller with CRD defined, Let's keep this issue open and mark it closed after finishing tasks in https://github.com/tektoncd/pipeline/issues/5156#issuecomment-1221042052. wdyt?


BUG: ndimage: fix origin handling for {minimum, maximum}_filter

Reference issue
closes #20652
What does this implement/fix?
fixes incorrect assumption that len(origin) should match ndim. It should have instead been len(axes) with a value of 0 inserted afterwards for any non-filtered axis. This same solution was already previously implemented for rank_filter.
New test cases were added that fail with the error mentioned in #20652 prior to this change (they did not fail previously for rank_filter, median_filter or percentile_filter, but it was easy to add those to the test parameters).

Would you like for this to be reviewed by someone else who spends more time with this code (or at lest another set of eyes, since I didn't notice the bug originally)?

Thanks for checking it. I think the test case covers the issue well enough so that additional review is probably not needed.
Apparently this is a pretty uncommon code path as no bug has been raised for it since the 1.11 release


Missing line breaks in @signatures{x, y, z}

If a @signature{x, y, z} block has multiple terms being shown, it looks like they are shown without linebreaks?
https://share.unison-lang.org/latest/terms/@m8f0e2vgpbkse357h6r7f0ejf8v2gem65adfek2plnlugj13cbjjufolulgme7pjrhopjeqktpk8mnn651tk38qq3o3o9tukc64k4do
Confirmed that display command renders this as expected, and the Signature constructor of the doc is giving a [SyntaxText], so pretty sure it’s just a rendering tweak that’s needed.

This has been fixed :D