Hyperlinks in terminal from ls --hyperlink don't work in vscode

Type: Bug

Use Linux using GNU coreutils to provide ls. I used GNU coreutils 9.1, I don't know if this will work the same in older versions.
ls --hyperlink=auto
VS Code will detect these hyperlinks and make them clickable
Clicking the link however will not open the file or directory, instead resulting in the message "The editor could not be opened because the file was not found".

Examining the path that VS Code attempted to open shows that it tries to open /<hostname>/path/to/file, which does obviously not exist. The spurious <hostname>-part needs to go away.
Tested in both bash and zsh, both exhibited the issue. The Kitty terminal emulator correctly handles the hyperlinks that ls produces.
UPDATE: Some additional analysis
Looking in a hexeditor at what GNU coreutils outputs, it includes the hostname part (e.g. file://<hostname>/some/path. Presumably this is to allow the feature to work properly over ssh if the consumer of the URI is inclined to handle that case.
Looking at the relevant RFC for file URIs (https://datatracker.ietf.org/doc/html/rfc8089) this is entirely valid. The hostname is optional, and if not given it defaults to localhost. VSCode should at least detect and handle the case where an explicit hostname is given to see if it matches the local hostname.
The current behaviour that the host name is part of the path is buggy, as file://some_file is not valid, it has to be either file:/some_file or file:///some_file to refer to the actual local host (so either 1 or 3 slashes in there). Thus there is no ambiguity according to the specification.
However that is not what VSCode actually does (when given a bare URI printed with echo):

URI
According to RFC 8089
What VSCode actually does

file:/etc/fstab
/etc/fstab on current computer
BAD: file: is not part of URI detected by vscode, but it detects /etc/fstab as a path

file://somehost/etc/fstab
/etc/fstab on host somehost
BAD: /somehost/etc/fstab on current computer

file://localhost/etc/fstab
/etc/fstab on current computer
BAD: /localhost/etc/fstab on current computer

file:///etc/fstab
/etc/fstab on current computer
GOOD: /etc/fstab on current computer

It appears that VSCode only handles the final case correctly.
If we add the requsite terminal control codes to turn it into the same type of hyperlink as used by ls --hyperlink=auto:

URI
According to RFC 8089
What VSCode actually does

file:/etc/fstab
/etc/fstab on current computer
GOOD (by accident): Opens correctly

file://somehost/etc/fstab
/etc/fstab on host somehost
BAD: Opens /somehost/etc/fstab on current computer

file://localhost/etc/fstab
/etc/fstab on current computer
BAD: Opens /localhost/etc/fstab on current computer

file:///etc/fstab
/etc/fstab on current computer
GOOD: Opens /etc/fstab on current computer

VS Code version: Code 1.72.1 (129500ee4c8ab7263461ffe327268ba56b9f210d, 2022-10-10T17:23:00.760Z)
OS version: Linux x64 5.15.72-1-lts
Modes:
Sandboxed: No

System Info

Item
Value

CPUs
Intel(R) Core(TM) i9-10885H CPU @ 2.40GHz (16 x 2400)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_renderer: enabled_onvideo_decode: disabled_softwarevideo_encode: disabled_softwarevulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: disabled_off

Load (avg)
1, 1, 1

Memory (System)
30.99GB (24.07GB free)

Process Argv
--unity-launch --crash-reporter-id 6fcb95bd-7026-4cc1-a1c4-e0920e45797a

Screen Reader
no

VM
0%

DESKTOP_SESSION
plasma

XDG_CURRENT_DESKTOP
KDE

XDG_SESSION_DESKTOP
KDE

XDG_SESSION_TYPE
x11

Extensions (23)

Extension
Author (truncated)
Version

vsc-prolog
art
0.8.23

doxdocgen
csc
1.4.0

latex-workshop
Jam
8.29.0

better-cpp-syntax
jef
1.16.1

vscode-graphviz
joa
0.0.6

vscode-docker
ms-
1.22.1

python
ms-
2022.16.0

vscode-pylance
ms-
2022.10.20

jupyter
ms-
2022.9.1202862440

jupyter-keymap
ms-
1.0.0

jupyter-renderers
ms-
1.0.10

vscode-jupyter-cell-tags
ms-
0.1.6

vscode-jupyter-slideshow
ms-
0.1.5

remote-containers
ms-
0.255.3

remote-ssh
ms-
0.90.1

remote-ssh-edit
ms-
0.84.0

remote-wsl
ms-
0.72.0

cmake-tools
ms-
1.12.27

cpptools
ms-
1.12.4

cpptools-extension-pack
ms-
1.3.0

linux-desktop-file
nic
0.0.21

cmake
twx
0.0.17

vscode-ltex
val
13.1.0

(1 theme extensions excluded)

Can repro:

We don't have support for the hostname yet as you suspected

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

Example output from ls --hyperlink=auto:
]8;id=6908-29;file://Ifrit-Work/mnt/c/Github/microsoft/vscode/CONTRIBUTING.md\CONTRIBUTING.md]8;;\  ]8;id=6908-30;file://Ifrit-Work/mnt/c/Github/microsoft/vscode/README.md\README.md]8;;\    ]8;id=6908-31;file://Ifrit-Work/mnt/c/Github/microsoft/vscode/ThirdPartyNotices.txt\ThirdPartyNotices.txt]8;;\  ]8;id=6908-32;file://Ifrit-Work/mnt/c/Github/microsoft/vscode/cglicenses.json\cglicenses.json]8;;\  ]8;id=6908-33;file://Ifrit-Work/mnt/c/Github/microsoft/vscode/cli\cli]8;;\]8;id=6908-34;file://Ifrit-Work/mnt/c/Github/microsoft/vscode/gulpfile.js\gulpfile.js]8;;\   ]8;id=6908-35;file://Ifrit-Work/mnt/c/Github/microsoft/vscode/out\out]8;;\]8;id=6908-36;file://Ifrit-Work/mnt/c/Github/microsoft/vscode/product.json\product.json]8;;\  ]8;id=6908-37;file://Ifrit-Work/mnt/c/Github/microsoft/vscode/resources\resources]8;;\  ]8;id=6908-38;file://Ifrit-Work/mnt/c/Github/microsoft/vscode/src\src]8;;\   ]8;id=6908-39;file://Ifrit-Work/mnt/c/Github/microsoft/vscode/tsfmt.json\tsfmt.json]8;id=6908-40;file://Ifrit-Work/mnt/c/Github/microsoft/vscode/LICENSE.txt\
LICENSE.txt]8;;\      ]8;id=6908-41;file://Ifrit-Work/mnt/c/Github/microsoft/vscode/SECURITY.md\SECURITY.md]8;;\  ]8;id=6908-42;file://Ifrit-Work/mnt/c/Github/microsoft/vscode/build\build]8;;\]8;id=6908-43;file://Ifrit-Work/mnt/c/Github/microsoft/vscode/cgmanifest.json\cgmanifest.json]8;;\  ]8;id=6908-44;file://Ifrit-Work/mnt/c/Github/microsoft/vscode/extensions\extensions]8;;\  ]8;id=6908-45;file://Ifrit-Work/mnt/c/Github/microsoft/vscode/node_modules\node_modules]8;;\  ]8;id=6908-46;file://Ifrit-Work/mnt/c/Github/microsoft/vscode/package.json\package.json]8;;\  ]8;id=6908-47;file://Ifrit-Work/mnt/c/Github/microsoft/vscode/remote\remote]8;;\        ]8;id=6908-48;file://Ifrit-Work/mnt/c/Github/microsoft/vscode/scripts\scripts]8;;\    ]8;id=6908-49;file://Ifrit-Work/mnt/c/Github/microsoft/vscode/test\test]8;;\  ]8;id=6908-50;file://Ifrit-Work/mnt/c/Github/microsoft/vscode/yarn.lock\yarn.lock]8;;\

PowerShell repro:
[Console]::Write("`e]8;id=6908-29;file://Ifrit-Work/mnt/c/Github/microsoft/vscode/CONTRIBUTING.md`e\CONTRIBUTING.md`e]8;;`e\")

Should be fixed in https://github.com/microsoft/vscode/pull/169170, will need to verify in Linux to make sure it works properly there as I tested using Windows URIs.

Using codespaces. Works for files but not for folders
https://user-images.githubusercontent.com/1794099/214308284-708859dc-b777-4000-a6ff-bc883dfd549d.mov

Forking off as this will be on the release notes but folder links don't meet the cut for Jan https://github.com/microsoft/vscode/issues/172577


Bottom of the bridge in TOWN5 invalidly classified as ROAD_LINE by semantic segmentation

Reproduction

I used 0.9.5 release.
I started server with TOWN5
I ran examples/manual_control.py script
In launched application I switched view to semseg using tilde

This is the result I got:

As you can see bottom of the bridge (seen in upper-left part of screen shot) is marked as Road line class.

Hi @Ajk4, There is a problem when imported the mesh from RoadRunner. The bottom of the bridge and lanemarking as the same semantic segmentation.  Thank you for telling us.

Is this still the case @XGodina ?

@germanros1987 @Ajk4 Hi, with the new versions of RoadRunner I haven't been able to try it yet. And for the next release, it will be fixed.


Not enough open issues

Out of nearly a thousand issues, there are only ~5 open issues on this repository. This is abnormal and borderline heresy.

*poofs this issue away*
Magic 😎

I don't really understand what you're asking here - if anything at all.
Just to clarify, issues are closed when:

The bug is fixed
The question is answered
The suggestion is implemented, or deemed to be out of scope

so, one of the above is true in most cases, for all of the closed issues on this repository.

(It's a joke, I'm just commenting on how this repository has a phenomenal closed to open issue ratio)

Oh uh, thanks!
:)


Potential issue with flushing a buffered Sink

I think this might be related to the recent Tokio reform, as I have only noticed on code that uses the new tokio rather than tokio-core, but tracing the code it appears to be a bug when flushing a buffered Sink.
The symptom was that the final few messages being written to a Sink were not being flushed, even when using send_all to feed the Sink, which should have flushed the sink before completing.  Instead, the send_all was never completing and the buffered messages never flushed.
After following the chain of function calls, the issue appears to be here: https://github.com/rust-lang-nursery/futures-rs/blob/master/src/sink/buffer.rs#L47-L61 (although I'm not familiar enough with the codebase to be sure).
    fn try_empty_buffer(&mut self) -> Poll<(), S::SinkError> {
        while let Some(item) = self.buf.pop_front() {
            if let AsyncSink::NotReady(item) = self.sink.start_send(item)? {
                self.buf.push_front(item);

                // ensure that we attempt to complete any pushes we've started
                self.sink.poll_complete()?;

                return Ok(Async::NotReady);
            }
        }

        Ok(Async::Ready(()))
    }

The result of the call to self.sink.poll_complete() was Ok(Async::Ready(())) because the underlying Sink had flushed successfully, but this function returns Ok(Async::NotReady) as this buffer was not fully flushed.
However, since the underlying Sink was flushed successfully, the future was not scheduled for further execution, hence why no more flushes were attempted and my system ground to a halt.
I verified this by creating a custom send_all within my client code, which explicitly rescheduled the future in the event of a Async::NotReady from the poll_complete function of the buffer.  Which did fix the problem, but this is obviously inefficient as it will re-poll the future at the earliest opportunity, rather than when the bottom-level indicates it is ready (in this case a tokio TcpStream).
The simplistic fix would be to check the result of self.sink.poll_complete()? and, if the result was Async::Ready(()) to continue looping through the buffer until either the whole buffer is accounted for or we get a Async::NotReady from the underlying Sink.  But when I attempted this, the buffer test went into an infinite loop, so either the test needs to be updated, or (much more likely) I'm missing information and the simplistic fix isn't a fix after-all.

Aha thanks for the report! I do indeed think this is a bug, currently there's a contract that a failed start_send "otherwise attempted and failed a poll_complete" so we should be able to omit it entirely. Does that work for the use case you ran into? If so, sounds like something we should definitely fix!

Thanks for this, that makes sense.
In my case the underlying sink was a Framed Sink from tokio-io, which, when I traced the call-stack was calling this: https://github.com/tokio-rs/tokio/blob/master/tokio-io/src/framed_write.rs#L159
The implementation of start_send for that sink will call poll_complete before returning Async::NotReady, so it seems to honour the contract.  But it could have been that that poll_complete completed successfully, but the data left in the buffer was still above the threshold, so a Async::NotReady was returned hence causing the problem I've been seeing.  (I'm not familiar with the Tokio codebase either 😀 so I'm probably missing something.)  Does this implementation meet the contract?
I'll try and put together an example that shows this problem happening, and if it looks like a Tokio issue I'll open an issue against that project.

Hm nah I think that's impemented implemented ok and upholds the current contract of Sink because if poll_complete succeeds it'll have drained the internal buffer and the item may be encoded?

I see now, this makes sense.
To demonstrate the bug with real-code, I've pushed a futures-bug branch on one of my projects: https://github.com/benashford/redis-async-rs/tree/futures-bug the problem can be seen when running cargo bench bench_complex_pipeline (warning: it's a Redis client so needs a Redis instance running on localhost - if you already have one running, it'll write nonsense to it).
The only difference between the futures-bug and master branch is that futures-bug buffers the Sink used to send Redis commands and master doesn't.
Using that test case your original suggestion fixed the problem and the test completes reliably with the fix in place.
I'll open a PR with the (very small) fix.


README.md Warning

Add warning to README.md about recursive running.

Also add badge for pre-commit enabled.


Local weather

There is currently no easy way to get the weather that applies to a specific location, maybe something like a getWeatherAt(Vector3d position) in the WeatherUniverse (which is affected by the biome). And on top of this maybe provide a SNOW weather? I don't know how we could handle this because of the global weather system but it would be useful.
Regarding the getWeatherAt method can you also provide a WeatherScope which can give more information about a specific location.

It would be cool if we could replace the entire weather layer of a world, so that we have full control over rain durations and locations or the ability to disable the weather cycle of a world completely.
So that we could have moving patches of rain moving around. It does not matter that the client cannot actually see them unless he is actually in them. (Like in a real world)

As far as I know all weather is a global effect and rendered on the client side depending on the biome. Weather doesn't have a location and the snow variation is just rain but in cold biomes.
This could be done by controlling weather packets sent to each client to make it appear as if it is local, but it would be limited as a player would still see the whole word as raining.

On Dec 20, 2015at 5:10 PM, ST-DDT<EMAIL_ADDRESS>wrote:
It would be cool if we could replace the entire weather layer of a world, so that we have full control over rain durations and locations or the ability to disable the weather cycle of a world completely.
So that we could have moving patches of rain moving around. It does not matter that the client cannot actually see them unless he is actually in them. (Like in a real world)
—
Reply to this email directly or view it on GitHub.

@DDoS is right...weather is a global concept. Until this changes in Vanilla, we can't really do it in Sponge...not without overwriting much of Vanilla's logic (and fundamentally changing the game drastically).


Link to JOSM

Could you add a link to edit in JOSM when the user clicks in a feature. You could show the link in the window that shows the tags and changeset.

Had a look at this, a bit more involved than I thought, postponing.


Adding MIT License

Would love to use this but it needs a proper license, please merge!

Johnathan, thanks for this!


authz: remove more v1alpha1 RBAC code

#22060
This PR removes the istioctl experimental authz conert command and some more related code in pilot for the v1alpha1 RBAC policy.

@yangminzhu: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

lint_istio
36361d573e6d356efb693823ccb4850c008a993a
link
/test lint_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@yangminzhu: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

lint_istio
36361d573e6d356efb693823ccb4850c008a993a
link
/test lint_istio

gencheck_istio
36361d573e6d356efb693823ccb4850c008a993a
link
/test gencheck_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


The server reports any text typed as a variable and adds it to the completion menu

Description
Typing any text at all, such as the letter 'j', and then attempting to complete that text will result in the text appearing in the completion menu as a variable, pointlessly cluttering it.
Steps to reproduce

Open an awk file in a text editor with lsp support
Type anything (without spaces or non-alphabetic characters)
Attempt to complete the text
See that the text typed appears in the completion results

I'm encountering this with vim 9.1.0720, using coc.nvim, and the most up to date awk-language server.
Expected Behavior
When the user types in text, and that text appears nowhere else, it shouldn't be identified as a variable and reported as a completion item.
Additional Info
Server Response
This is the completion response from the server when I typed the letter 'j' in a completely empty file and (auto-)triggered completion:
[Trace - 5:56:29 PM] Received response 'textDocument/completion - (1)' in 11ms.
Result: [
    {
        "label": "j",
        "kind": 6,
        "data": {
            "type": 0,
            "symbolInfo": {
                "name": "j",
                "kind": 13,
                "location": {
                    "uri": "file:///home/john/development/awk/awk_programming_language_2ed/example.awk",
                    "range": {
                        "start": {
                            "line": 0,
                            "character": 0
                        },
                        "end": {
                            "line": 0,
                            "character": 1
                        }
                    }
                },
                "containerName": "awk"
            }
        }
    },
    {
        "label": "OFS",
        "kind": 6,
        "data": {
            "type": 1,
            "jsonPath": "builtins.OFS"
        }
    },
    ---- Many other items ----
]

@Beaglefoot I know you're not spending a lot of time on awk nowadays, but could you give your opinion on how this might be handled? I may have time in the future to make some changes myself, but it would be quite a bit easier if I knew where to start.

According to gawk manual:

VARIABLES, RECORDS AND FIELDS
AWK variables are dynamic; they come into existence when they are first used.

So this is an expected behavior and won't be fixed.

Hey @Beaglefoot, thanks for the response. I do agree; this is technically correct behavior. I didn't mean to dispute that when I opened this issue.
However, there are two points I'll make:

The completion is actually behaving inconsistently. The server does not always report what you type as a user-defined variable. See this recording (you may need to view it full screen):

For some reason, it reports the individual letter b as a variable, but not be, beg, or begi. Similarly, it treats j as a variable, but not jo. It does again treat joj as a variable, but again not jojo.

Even if this behavior is correct (if it were consistent), it's not useful. When would I want to 'complete' something I just fully typed for the first time? (If it's a snippet, then yes, otherwise, no.) If I type the letter b, and I want to complete the word 'begin', I first have to move down past the letter 'b' in my completion menu to get to the 'begin' entry.

It might be possible to remove this entry automatically on the client side, but it seems like it would be prone to accidentally removing other valid variables. Any solution would probably also be quite brittle.


Mosh capabilities

Is there  any plans to connect via mosh  capabilities to prevent "micro disconnections"? Every once in a while I can't pas input to my terminal via the ssh connection and I suspect it is because of latency coupled with my relatively bad Internet connection.

+1
This is a must for remote mobile development


Request for citation of paper: 'Bridging the Gap between Reality and Ideality of Entity Matching: A Revisiting and Benchmark Re-Construction'

Our paper, presented at IJCAI 2022, introduces a new benchmark to assess the generalization of models on unseen entities/records at different levels. We would be grateful if you could cite our paper in your research.

Dear Tianshu,
thank you very much for pointing us at your benchmark which we did not know and will of course cite in the next version of the paper. Where can we download your benchmark?
Best regards, Chris

Dear Chris,
Here is the link to my benchmark. Please note that since our products come from Chinese e-commerce websites, the text is in Chinese.
Best regards, Tianshu

I also tried to crawl images for products in the WDC LSPM, like in Towards Multi-modal Entity Resolution for Product Matching. However, many of the products were quite old and the image quality was low, so I ended up not releasing anything. This was my code at that time.


SNS Consumer

Is your feature request related to a problem? Please describe.
I would want to integrate MIE API to my Media Supply Chain. My workflow manager would have these steps

Upload video asset to S3
Execute workflow POST /workflow/execute
receive the Workflow Execute ID
Be notified by an event to request metadatas and add them to my MAM

Describe the feature you'd like

MIE notifies the status change of execution to a SNS Topic
Customer links SNS topic to SQS queue
the Media Supply chain polls the SQS queue
The Media Supply Chain Workflow Manager acknowledge SQS when metadatas are well integrated to the MAM

Additional context
Add any other context or screenshots about the feature request here.

To clarify, you are asking for an SNS notification when the status of a workflow execution changes not a new MIE data pipeline consumer (this would entail adding a new consumer off the kinesis stream to write to a different datastore than Elasticsearch).
The good news is this is already partially implemented as a prototype feature. The remaining work left to complete this feature is to:

formalize the design (which events do we notify on? what is the content of the SNS message?)
provide the name of the SNS Topic as an output of the top-level MIE Stack
document in the implementation guide

Description of the current implementation:
The SNS Topic is the resource WorkflowExecutionEventTopic created here: https://github.com/awslabs/aws-media-insights-engine/blob/b3ca78607b1943a53d66764aeaa5e95fcd10e1b9/deployment/media-insights-stack.yaml#L890
An event is emitted whenever the execution status for a workflow changes to Complete or Error.
  The message should also contain:
timestamp - current timestamp when event is emitted.

To clarify, I think you are asking for an SNS notification when the status of a workflow execution changes not a new MIE data pipeline consumer (this would entail adding a new consumer off the kinesis stream to write to a different datastore than Elasticsearch). @gmarchand - is this correct?

Correct

A couple blocking issues need to be addressed for this work successfully:

The workflow execution SQS queue that is created and attached to the workflow execution SNS topic needs to have the queue policy adjusted to a principal of "sns.amazonaws.com" instead of the owner account id.

Currently, both the queue and topic use different AWS service provided KMS keys for encryption. This prevents messages from being delivered from the topic to the queue. This means we will need to create a dedicated KMS key that is shared across both of these resources.

Outside of that, the remaining items to do are the following:

General code cleanup / refactoring of the existing workflow execution streaming function
Add the SNS topic / SQS queue info to the stack output
Adjust tests as needed
Document in the IG

Issue related to last comment:
https://github.com/aws-solutions/aws-media-insights-engine/issues/678

Closed as part of PR #694


fix: formalize edge behaviour for nextAbsentValue and previousAbsentValue

The edge cases for nextAbsentValue and previousAbsentValue were undefined.

It just bugs me when we have undefined behaviour.

This will be part of the next release.


mdl-js-layout class breaks css transition

I have page like this:

and styles like this:
.page {
  opacity: 0;
  transition: transform 1s linear;
  transform: translate3d(100%, 0, 0);
}
.page.active {
  opacity: 1;
  transform: translate3d(0, 0, 0);
}

So for showing page i add .active class using js.
When I didn't have .mdl-js-layout class - everything was working, but with .mdl-js-layout class i cannot see slide effect.
Any suggestion how to fix it?

Please use StackOverflow for support. You can use the material-design-lite tag along with any other appropriate tags. The issue tracker is for core MDL issues, not implementation and usage support.


Build size considerations

No doubt build size is an ongoing consideration, for example in #826 and #1078 - so I apologize if this is a bit redundant.
However - I didn't see some of the following specific questions covered in those issues, so figured it's worth opening a new one...
In a basic app using just the minimum of what's needed to render a quad on the screen via webgl, I'm seeing around a 66KB output wasm. That is including some js_sys and web_sys stuff. It's after cargo build --release and wasm_bindgen
So - first question is, what can one expect for a final output using some average requirements from wasm_bindgen, js_sys and web_sys - is this number in the right ballpark?
Secondly - I am structuring things using workspaces. To get it to compile I had to include "rlib" in the local crate dependencies. Will that add bloat? If so - is there a recommended way around it?
Here's some of the Cargo.toml snippets, adapted with generic names (note: I haven't tried wee_alloc - not sure if that will make a major difference)
root: ./Cargo.toml
[workspace]
members = [ "crates/*", "examples/*" ]

[profile.release]
lto = true

library: ./crates/foo/Cargo.toml
[package]
name = "foo"
edition = "2018"

[lib]
crate-type = ["cdylib", "rlib"]

[profile.release]
lto = true

[dependencies]
wasm-bindgen = "0.2.29"
js-sys = "0.3.6"

[dependencies.web-sys]
version = "0.3.6"
features = [
  'CanvasRenderingContext2d',
  'WebGlRenderingContext',
  'WebGl2RenderingContext',
  'HtmlCanvasElement',
  'WebGlProgram',
  'WebGlShader',
  'Window'
]

app: ./examples/foo-demo/Cargo.toml
[package]
name = "foo-demo"
edition = "2018"

[lib]
crate-type = ["cdylib"]

[profile.release]
lto = true

[dependencies]
wasm-bindgen = "0.2.29"
js-sys = "0.3.6"
foo = { path = "../../crates/foo" }

[dependencies.web-sys]
version = "0.3.6"
features = [
    'WebGlRenderingContext',
    'WebGl2RenderingContext',
    'WebGlProgram',
    'WebGlBuffer',
    'HtmlCanvasElement',
    'console',
    ]

Thanks - so neither rlib nor duplication of dependencies is adding anything?

@dakom I don't know, I'll let others weigh in on that.

If possible it'd be best if we could poke around the code

For sure! It's an ongoing spare-time project (and my way of learning Rust - I'm a newbie), so there will be a fair amount of bikeshedding and changes over time, but it'll probably remain fairly basic for the next week or so, at least as far as the overall workspace setup is concerned:
https://github.com/dakom/pure3d
Specifically, "rlib" is included here: https://github.com/dakom/pure3d/blob/master/crates/webgl/Cargo.toml#L16
I also tried moving all the code into one crate which allowed me to remove "rlib" in the list and it unfortunately didn't make a difference to the file size.

Ok cool, thanks! Looks like with the current commit LTO is indeed happening. Following these instructions to analyze the binary we see:
$ twiggy top -n 10 integration_tests_bg.wasm
 Shallow Bytes │ Shallow % │ Item
───────────────┼───────────┼──────────────────────────────────────────────────────────────────────
          7431 ┊    10.67% ┊ data[0]
          7086 ┊    10.17% ┊ core::fmt::float::float_to_decimal_common_shortest::h28e660428e55af7b
          6939 ┊     9.96% ┊ dlmalloc::dlmalloc::Dlmalloc::malloc::hcd84cc7763e958b1
          6014 ┊     8.63% ┊ core::fmt::float::float_to_decimal_common_exact::h09a7972005228cb0
          5801 ┊     8.33% ┊ "function names" subsection
          4609 ┊     6.62% ┊ core::num::flt2dec::strategy::dragon::mul_pow10::h3c162bf0fec5df7c
          3209 ┊     4.61% ┊ load_assets
          2833 ┊     4.07% ┊ data[1]
          2450 ┊     3.52% ┊ <wasm_bindgen::JsValue as core::fmt::Debug>::fmt::ha5bdcf489482357c
          2020 ┊     2.90% ┊ dlmalloc::dlmalloc::Dlmalloc::free::h241af8935332b649
         21213 ┊    30.45% ┊ ... and 219 more.
         69605 ┊    99.92% ┊ Σ [229 Total Rows]

One of the huge parts that stands our here is floats! Printing floats is no easy task (nor parsing!), and it looks like that may be coming through Debug for JsValue (which transitively includes float printing). If you remove instances of debugging JsValue.
After applying a small patch I get:
$ twiggy top -n 10 integration_tests_bg.wasm
 Shallow Bytes │ Shallow % │ Item
───────────────┼───────────┼─────────────────────────────────────────────────────────────────────────────────
          6939 ┊    23.92% ┊ dlmalloc::dlmalloc::Dlmalloc::malloc::h66c8dcaaa3bebf05
          4566 ┊    15.74% ┊ "function names" subsection
          3656 ┊    12.60% ┊ load_assets
          2020 ┊     6.96% ┊ dlmalloc::dlmalloc::Dlmalloc::free::h79fb8feb59e45f48
          1686 ┊     5.81% ┊ dlmalloc::dlmalloc::Dlmalloc::dispose_chunk::h36073841969c5319
          1388 ┊     4.78% ┊ core::fmt::Formatter::pad::hd92048ae484e93e9
           883 ┊     3.04% ┊ data[0]
           761 ┊     2.62% ┊ pure3d_webgl::shader::compile_source::h2d2c462bbaaf0cc7
           545 ┊     1.88% ┊ data[2]
           408 ┊     1.41% ┊ integration_tests::start_ticker::_$u7b$$u7b$closure$u7d$$u7d$::h7d251a52f0e95145
          6104 ┊    21.04% ┊ ... and 165 more.
         28956 ┊    99.81% ┊ Σ [175 Total Rows]

Over a 50% reduction in size!

@dakom my understanding is that calling .unwrap and .expect on JsValue's means that you are including the Debug implementation for JsValue which includes some code to print out floats which was bloating your binary.
By instead just returning the Result JsValue's debug implementation got optimized away as completely unused dead code and was no longer present in your binary.

So, in short, you stopped using JsValue's Debug implementation by no longer calling methods that rely on it.

Oh, very cool - I see now in the wasm_bindgen guide that returning a Result from wasm will throw an exception... so now I moved all the error handling 100% outside of wasm, including getting rid of the "on_error" callback I had.
Shaved another ~1K off the build :D
Not sure if I love this approach since it introduces the need to distinguish between expected errors and bugs on the JS side, but it's cool to know it exists and can help save a few bytes (at least in this example so far)
(as an aside - I also went back to brush up on the ? operator from The Rust Book and that's awesome! I'm still not sure which style I like better, but so far - keeping everything flat is super clean and easy to reason about it, so for now I do prefer the ? - so thanks @alexcrichton for the style hint on that possibility too!)

@dakom would just keep in mind that that ~30Kb was mostly (to my understanding) a one time cost of pulling in some bits of std::format.
That's important to recognize because if the extra Kb aren't an issue for your application you can save a lot of headache on worrying about whether anything you do is pulling in things like float parsing / formatting.
So.. in short.. just calling out that that extra weight should be mostly constant. In case you find yourself in a situation where it's getting cumbersome to avoid std::format.
Cheers!

Similarly, it's really hard to completely avoid formatting in significant apps. At some point you likely will need formatting (in some form or other), and then suddenly you get a big increase in file size.
So developing your app under the assumption that you won't need formatting could give a nasty surprise later.

Ok glad things worked out, and thanks for the assistance as well @chinedufn! Sounds like this is mostly solved now though so I'm going to close.


usteer: fix uchannel.uc script

Once the uchannel.uc script sets its status to waiting, it becomes
defunct. The next invocation of the script will compare uptime to
state.uptime, and if the difference is less than 12h, it will change
state.uptime to the current uptime and return. As the script runs every
5 minutes, the difference will always be less than 12h.
Fix this by comparing uptime against state.changed rather than
state.uptime.
While at it, rename state.uptime to state.executed, to be more
descriptive.

merged, Thanks !


Missing targets when requested from metadata

In https://docs.rs/wgpu/0.19.1/wgpu/index.html and https://docs.rs/wgpu/0.19.0/wgpu/index.html, the Platform menu lists only x86_64-pc-windows-msvc and x86_64-unknown-linux-gnu, even though the Cargo.toml contains
[package.metadata.docs.rs]
targets = [
    "x86_64-unknown-linux-gnu",
    "x86_64-apple-darwin",
    "x86_64-pc-windows-msvc",
    "wasm32-unknown-unknown",
]

The prior version https://docs.rs/wgpu/0.18.0/wgpu/ does have wasm32-unknown-unknown, but still not x86_64-apple-darwin. It seems like in both cases certain targets are being silently ignored (even the build log has no info on this) and this has gotten worse between the two versions.

The issue will be that those targets failed to build, nothing being shown in the build logs is https://github.com/rust-lang/docs.rs/issues/787
Trying cargo rustdoc --target wasm32-unknown-unknown locally gives an explicit compile_error!:
error: webgpu feature used without web_sys_unstable_apis config:
       Here are some ways to resolve this:
       * If you wish to use webgpu backend, create a .cargo/config.toml in the root of the repo containing:
           [build]
           rustflags = [ "--cfg=web_sys_unstable_apis" ]
           rustdocflags = [ "--cfg=web_sys_unstable_apis" ]
       * If you wish to disable webgpu backend and instead use webgl backend, change your wgpu Cargo.toml entry to:
           wgpu = { version = "", default-features = false, features = ["webgl"] }
  --> src/backend/mod.rs:7:1
   |
7  | / compile_error!(
8  | |     "webgpu feature used without web_sys_unstable_apis config:
9  | | Here are some ways to resolve this:
10 | | * If you wish to use webgpu backend, create a .cargo/config.toml in the root of the repo containing:
...  |
16 | | "
17 | | );
   | |_^

while x86_64-apple-darwin appears to fail to cross-compile a dependency
warning<EMAIL_ADDRESS>gcc: error: unrecognized command-line option ‘-arch’
warning<EMAIL_ADDRESS>gcc: error: unrecognized command-line option ‘-mmacosx-version-min=10.7’

error: failed to run custom build command for `objc_exception v0.1.2`

(I've recently noticed that there's now https://github.com/dtolnay/cargo-docs-rs which could be used to test the docs build in CI relatively similarly to how it will run on docs.rs)

Thanks! I've copied this info to the wgpu issue tracker.
I assume there's no reason to keep this issue open.

triggered by this discussion I had another look at logging non-default build targets: https://github.com/rust-lang/docs.rs/pull/2427


Possible to return name with the gmaps object?

We get the formatted address, but is it possible to return the other location details (specifically name) as a part of the gmaps object?

The gmaps object is returned directly from the Google result – there isn’t any data filtered out. To get more information, use the placeId and request more info from Google with a GeocoderRequest.


Bump analyzer in image redactor

Why has the lock file changed but not the pipfile? Is it just re-locking?

@omri374 We defined a relaxed versioning in the pipfile for analyzer, which we bumped this week. Locking again updated the version in the lock file.

@omri374 Implicitly added typing extensions so that it would be included in the lockfile for python 3.9, as I did for analyzer. Can be avoided with a different dependency installation method in the future.


Fails due to execution policy other than "Restricted" or "Unrestricted"

The script checks for an execution policy of "Restricted" and changes it to "Unrestricted" if found. But there are other execution policies (such as "RemoteSigned", "AllSigned", "Bypass") that would not be caught by this check. If the machine's execution policy is set to one of these other policies, the script will fail as it did in my case. The check should ideally be for anything that isn't "Unrestricted".

You're correct -- When I was writing the batch script, my thought was that, anyone that knows about the other execution policies, isn't going to be using the easy install script. However, I just added a workaround to the main PowerShell script, for some old nemesis post IDs that keep generating filesystem syntax errors, so I'm going to release that as 2.2.2, probably tomorrow, and include an updated batch script too. Thanks for your feedback.

Closing as fixed in the 2.2.2 release:
https://github.com/mbarr564/New-SubredditHTMLArchive/releases/tag/2.2.2
Sorry for my delay, I got sidetracked on rebuilding my 3D printer over the last few days.


Monitor dwp

Monitor the last 20 requests and return a state based on the number of 400 Bad Requests received
This is then called from the home controller to display the correct banner.
Update the healthcheck page to call the monitor too.
To do

[x] rebase on master
[ ] front end review of new css
[ ] code review

Front-endy stuff looks :+1: to me.


Finished event is not called when exiting the fuzzy finder for creating a new workspace

As the title says, the finish event doesnt trigger if I create a new workspace from the fuzzy finder. This is just a minor issue since I rarely create a new workspace, but thought I should report it now that I noticed it

Are you sure? I have tested it, and it seems like it is emitting the event even when creating a new workspace?

https://github.com/user-attachments/assets/6d1b0429-edef-43e3-95bf-3159e778287d
When I move to a workspace the event is emitted which updates the tab bar, as seen in the clip. So the tab bar changes back to normal when exiting. But when I create a new workspace visual-computing-fundamentals It does not change back to normal as expected. I would suspect this is an issue with the event, but for all I know it could also be an issue that wezterm is unable to process events when switching to a workspace. What do you think?

Do you depend on the Window to change the tabbar? I've previously had problems with the wrong window being emitted when changing workspaces.

The components depend on the window yes. But since the finish event also provides a window object, it uses that if it can

The components depend on the window yes. But since the finish event also provides a window object, it uses that if it can

So because of complications with the window dependencies, I have replaced the finished event with canceled.
To check if the fuzzy finder has closed then the canceled, choosen and created event can be used.
To check if the fuzzy finder has started, the start event can be used

Ok I understand. I will modify the tabline extension API to support multiple events for closing/starting. Thank you for the clarification

@MLFlexer I am still having issues after implementing with the new events. See: https://github.com/michaelbrusegard/tabline.wez/pull/10.
Regarding the Window object, I have tried commenting out the code that uses the object provided by smart_workspace_switcher but the issue still remains

03:12:22.056 ERROR wezterm_gui::overlay::selector > while processing user-defined-25 event: runtime error: ...stablinesDswez/plugin/tabline/components/window/mode.lua:3: attempt to call a nil value (method 'active_key_table')
stack traceback:
        ...stablinesDswez/plugin/tabline/components/window/mode.lua:3: in function 'tabline.components.window.mode.update'
        ...michaelbrusegardsZstablinesDswez/plugin/tabline/util.lua:102: in function 'tabline.util.extract_components'
        ...elbrusegardsZstablinesDswez/plugin/tabline/component.lua:64: in upvalue 'create_sections'
        ...elbrusegardsZstablinesDswez/plugin/tabline/component.lua:135: in function 'tabline.component.set_status'
        ...elbrusegardsZstablinesDswez/plugin/tabline/extension.lua:11: in upvalue 'set_attributes'
        ...elbrusegardsZstablinesDswez/plugin/tabline/extension.lua:36: in function <...elbrusegardsZstablinesDswez/plugin/tabline/extension.lua:30>
stack traceback:
        [C]: in local 'poll'
        [string "?"]:4: in function 'wezterm.emit'
        ...xersZssmart_workspace_switchersDswezterm/plugin/init.lua:155: in upvalue 'workspace_chosen'
        ...xersZssmart_workspace_switchersDswezterm/plugin/init.lua:178: in function <...xersZssmart_workspace_switchersDswezterm/plugin/init.lua:172>

03:13:02.089 ERROR wezterm_gui::overlay::selector > while processing user-defined-25 event: runtime error: ...elbrusegardsZstablinesDswez/plugin/tabline/component.lua:136: attempt to call a nil value (method 'set_left_status')
stack traceback:
        ...elbrusegardsZstablinesDswez/plugin/tabline/component.lua:136: in function 'tabline.component.set_status'
        ...elbrusegardsZstablinesDswez/plugin/tabline/extension.lua:11: in upvalue 'set_attributes'
        ...elbrusegardsZstablinesDswez/plugin/tabline/extension.lua:36: in function <...elbrusegardsZstablinesDswez/plugin/tabline/extension.lua:30>
stack traceback:
        [C]: in local 'poll'
        [string "?"]:4: in function 'wezterm.emit'
        ...xersZssmart_workspace_switchersDswezterm/plugin/init.lua:133: in upvalue 'zoxide_chosen'
        ...xersZssmart_workspace_switchersDswezterm/plugin/init.lua:181: in function <...xersZssmart_workspace_switchersDswezterm/plugin/init.lua:172>

03:13:11.948 ERROR wezterm_gui::overlay::selector > while processing user-defined-25 event: runtime error: ...elbrusegardsZstablinesDswez/plugin/tabline/component.lua:136: attempt to call a nil value (method 'set_left_status')
stack traceback:
        ...elbrusegardsZstablinesDswez/plugin/tabline/component.lua:136: in function 'tabline.component.set_status'
        ...elbrusegardsZstablinesDswez/plugin/tabline/extension.lua:11: in upvalue 'set_attributes'
        ...elbrusegardsZstablinesDswez/plugin/tabline/extension.lua:36: in function <...elbrusegardsZstablinesDswez/plugin/tabline/extension.lua:30>
stack traceback:
        [C]: in local 'poll'
        [string "?"]:4: in function 'wezterm.emit'
        ...xersZssmart_workspace_switchersDswezterm/plugin/init.lua:133: in upvalue 'zoxide_chosen'
        ...xersZssmart_workspace_switchersDswezterm/plugin/init.lua:181: in function <...xersZssmart_workspace_switchersDswezterm/plugin/init.lua:172>

>

Maybe these error messages help. I got the UI to update by being stricter on the nil checks in regards to obtaining a key table. But based on these errors I dont think that was enough

03:12:22.056 ERROR wezterm_gui::overlay::selector > while processing user-defined-25 event: runtime error: ...stablinesDswez/plugin/tabline/components/window/mode.lua:3: attempt to call a nil value (method 'active_key_table')
stack traceback:
        ...stablinesDswez/plugin/tabline/components/window/mode.lua:3: in function 'tabline.components.window.mode.update'
        ...michaelbrusegardsZstablinesDswez/plugin/tabline/util.lua:102: in function 'tabline.util.extract_components'
        ...elbrusegardsZstablinesDswez/plugin/tabline/component.lua:64: in upvalue 'create_sections'
        ...elbrusegardsZstablinesDswez/plugin/tabline/component.lua:135: in function 'tabline.component.set_status'
        ...elbrusegardsZstablinesDswez/plugin/tabline/extension.lua:11: in upvalue 'set_attributes'
        ...elbrusegardsZstablinesDswez/plugin/tabline/extension.lua:36: in function <...elbrusegardsZstablinesDswez/plugin/tabline/extension.lua:30>
stack traceback:
        [C]: in local 'poll'
        [string "?"]:4: in function 'wezterm.emit'
        ...xersZssmart_workspace_switchersDswezterm/plugin/init.lua:155: in upvalue 'workspace_chosen'
        ...xersZssmart_workspace_switchersDswezterm/plugin/init.lua:178: in function <...xersZssmart_workspace_switchersDswezterm/plugin/init.lua:172>

03:13:02.089 ERROR wezterm_gui::overlay::selector > while processing user-defined-25 event: runtime error: ...elbrusegardsZstablinesDswez/plugin/tabline/component.lua:136: attempt to call a nil value (method 'set_left_status')
stack traceback:
        ...elbrusegardsZstablinesDswez/plugin/tabline/component.lua:136: in function 'tabline.component.set_status'
        ...elbrusegardsZstablinesDswez/plugin/tabline/extension.lua:11: in upvalue 'set_attributes'
        ...elbrusegardsZstablinesDswez/plugin/tabline/extension.lua:36: in function <...elbrusegardsZstablinesDswez/plugin/tabline/extension.lua:30>
stack traceback:
        [C]: in local 'poll'
        [string "?"]:4: in function 'wezterm.emit'
        ...xersZssmart_workspace_switchersDswezterm/plugin/init.lua:133: in upvalue 'zoxide_chosen'
        ...xersZssmart_workspace_switchersDswezterm/plugin/init.lua:181: in function <...xersZssmart_workspace_switchersDswezterm/plugin/init.lua:172>

03:13:11.948 ERROR wezterm_gui::overlay::selector > while processing user-defined-25 event: runtime error: ...elbrusegardsZstablinesDswez/plugin/tabline/component.lua:136: attempt to call a nil value (method 'set_left_status')
stack traceback:
        ...elbrusegardsZstablinesDswez/plugin/tabline/component.lua:136: in function 'tabline.component.set_status'
        ...elbrusegardsZstablinesDswez/plugin/tabline/extension.lua:11: in upvalue 'set_attributes'
        ...elbrusegardsZstablinesDswez/plugin/tabline/extension.lua:36: in function <...elbrusegardsZstablinesDswez/plugin/tabline/extension.lua:30>
stack traceback:
        [C]: in local 'poll'
        [string "?"]:4: in function 'wezterm.emit'
        ...xersZssmart_workspace_switchersDswezterm/plugin/init.lua:133: in upvalue 'zoxide_chosen'
        ...xersZssmart_workspace_switchersDswezterm/plugin/init.lua:181: in function <...xersZssmart_workspace_switchersDswezterm/plugin/init.lua:172>

>

Maybe these error messages help. I got the UI to update by being stricter on the nil checks in regards to obtaining a key table. But based on these errors I dont think that was enough

There is a difference between a MuxWindow object and a Window or GUIWindow object.
It looks like you are trying to call GUI window functions on a MuxWindow, as such you should use the window:gui_window() method on a MuxWindow to get the equivalent GUIWindow, which you can then call these functions on.
Please let me know if that does not work 😄

Are you passing a MUX Window to the emit events? They expect the GUI Window object similar to how update-status works

Yes, I have updated the readme to be fix the update-status and included a note on the different window objects. Please see commit https://github.com/MLFlexer/smart_workspace_switcher.wezterm/commit/c9b2563a9dac9e862df7b9be4f5dccf254eabbd9 and/or updated sections.
TLDR:
The created and chosen events emit MuxWindow objects while the others emit GuiWindow objects. So you have to use window:gui_window() to get the gui window for these events.

https://github.com/michaelbrusegard/tabline.wez/commit/732f58513eaef063d39939aa9987d55d587ee228
I think this should fix the issue regarding mux windows. I still get the same messages in the log though

michaelbrusegard/tabline.wez@732f585 I think this should fix the issue regarding mux windows. I still get the same messages in the log though

Can you paste the logs? Because it seems to emit correctly

stack traceback:
        ...elbrusegardsZstablinesDswez/plugin/tabline/component.lua:21: in upvalue 'create_attributes'
        ...elbrusegardsZstablinesDswez/plugin/tabline/component.lua:134: in function 'tabline.component.set_status'
        ...elbrusegardsZstablinesDswez/plugin/tabline/extension.lua:19: in upvalue 'set_attributes'
        ...elbrusegardsZstablinesDswez/plugin/tabline/extension.lua:46: in function <...elbrusegardsZstablinesDswez/plugin/tabline/extension.lua:39>
stack traceback:
        [C]: in local 'poll'
        [string "?"]:4: in function 'wezterm.emit'
        ...xersZssmart_workspace_switchersDswezterm/plugin/init.lua:133: in upvalue 'zoxide_chosen'
        ...xersZssmart_workspace_switchersDswezterm/plugin/init.lua:181: in function <...xersZssmart_workspace_switchersDswezterm/plugin/init.lua:172>

20:02:28.729 ERROR wezterm_gui::overlay::selector > while processing user-defined-47 event: runtime error: ...elbrusegardsZstablinesDswez/plugin/tabline/component.lua:21: attempt to call a nil value (method 'active_key_table')
stack traceback:
        ...elbrusegardsZstablinesDswez/plugin/tabline/component.lua:21: in upvalue 'create_attributes'
        ...elbrusegardsZstablinesDswez/plugin/tabline/component.lua:134: in function 'tabline.component.set_status'
        ...elbrusegardsZstablinesDswez/plugin/tabline/extension.lua:19: in upvalue 'set_attributes'
        ...elbrusegardsZstablinesDswez/plugin/tabline/extension.lua:46: in function <...elbrusegardsZstablinesDswez/plugin/tabline/extension.lua:39>
stack traceback:
        [C]: in local 'poll'
        [string "?"]:4: in function 'wezterm.emit'
        ...xersZssmart_workspace_switchersDswezterm/plugin/init.lua:155: in upvalue 'workspace_chosen'
        ...xersZssmart_workspace_switchersDswezterm/plugin/init.lua:178: in function <...xersZssmart_workspace_switchersDswezterm/plugin/init.lua:172>

20:49:22.203 ERROR wezterm_gui::overlay::selector > while processing user-defined-28 event: runtime error: ...elbrusegardsZstablinesDswez/plugin/tabline/component.lua:21: attempt to call a nil value (method 'active_key_table')
stack traceback:
        ...elbrusegardsZstablinesDswez/plugin/tabline/component.lua:21: in upvalue 'create_attributes'
        ...elbrusegardsZstablinesDswez/plugin/tabline/component.lua:134: in function 'tabline.component.set_status'
        ...elbrusegardsZstablinesDswez/plugin/tabline/extension.lua:19: in upvalue 'set_attributes'
        ...elbrusegardsZstablinesDswez/plugin/tabline/extension.lua:46: in function <...elbrusegardsZstablinesDswez/plugin/tabline/extension.lua:39>
stack traceback:
        [C]: in local 'poll'
        [string "?"]:4: in function 'wezterm.emit'
        ...xersZssmart_workspace_switchersDswezterm/plugin/init.lua:155: in upvalue 'workspace_chosen'
        ...xersZssmart_workspace_switchersDswezterm/plugin/init.lua:178: in function <...xersZssmart_workspace_switchersDswezterm/plugin/init.lua:172>

I have tried to replicate the errors, but I am unable to, it might be because the configuration I am using is wrong:
local tabline = wezterm.plugin.require("https://github.com/michaelbrusegard/tabline.wez")
config.use_fancy_tab_bar = false
tabline.setup({ options = {}, extensions = { "resurrect" } })

If my configuration is wrong, then please send me one that I can try to replicate the error.

  tabline.setup({
    options = {
      theme = 'Catppuccin Mocha',
      section_separators = {
        left = wezterm.nerdfonts.ple_right_half_circle_thick,
        right = wezterm.nerdfonts.ple_left_half_circle_thick,
      },
      component_separators = {
        left = wezterm.nerdfonts.ple_right_half_circle_thin,
        right = wezterm.nerdfonts.ple_left_half_circle_thin,
      },
      tab_separators = {
        left = wezterm.nerdfonts.ple_right_half_circle_thick,
        right = wezterm.nerdfonts.ple_left_half_circle_thick,
      },
    },
    sections = {
      tabline_a = {
        { 'mode', fmt = string.lower },
      },
      tab_active = {
        { Attribute = { Intensity = 'Bold' } },
        { Foreground = { Color = colors.ansi[6] } },
        'tab_index',
        'ResetAttributes',
        { Foreground = { Color = colors.foreground } },
        { 'parent', padding = 0 },
        '/',
        { Attribute = { Intensity = 'Bold' } },
        { 'cwd', padding = { left = 0, right = 1 } },
        { 'zoomed', padding = 0 },
      },
      tab_inactive = { 'tab_index', { 'process', icons_only = true, padding = 0 } },
      tabline_x = {},
      tabline_y = { 'ram', 'cpu' },
    },
    extensions = {
      'resurrect',
      'smart_workspace_switcher',
      'quick_domains',
    },
  })

This is my personal configuration where the issue does occur. I think based on the error logs that it comes from one of the modules. Most likely a module that needs access to the window object (this is what I am getting from the error at least).
I think something like this may be a good starting point:
  tabline.setup({
    sections = {
      tabline_a = {
        'mode',
        'battery',
        'cpu',
        'ram',
        'datetime',
        'hostname',
        'window',
        'workspace',
      },
      tab_active = {},
      tab_inactive = {},
      tabline_x = {},
      tabline_y = {},
      tabline_z = {},
    },
    extensions = {
      'resurrect',
      'smart_workspace_switcher',
    },
  })

I set all the different sections except the one I am testing (a) to an empty table to overwrite the default config that would be applied for the different sections if they were not defined. In tabline_a I have every component that uses the window object.
Btw the options nil bug should be fixed now, was just an oversight.

I notice that I get the errors with both resurrect and with smart_workspace_switcher but not with quick_domains now with some testing. Now the issue may be with tabline.wez I am not sure

It seems to be a bug within tabline.wez
The correct_window function does not mutate the window object from the calling function. One way to resolve this behavior is to return and overwrite the window object:
local function correct_window(window)
  if window then
    if window.gui_window then
      window = window:gui_window()
    end
  end
  return window -- Newly added line
end
-- ... other code

local function on_hide_event(event, events)
  wezterm.on(event, function(window)
    window = correct_window(window) -- modified line
    if events.delay then
      wezterm.time.call_after(events.delay, function()
        set_attributes(config.opts.sections, config.normal_mode_colors, window)
      end)
    else
      set_attributes(config.opts.sections, config.normal_mode_colors, window)
    end
  end)
end


Remove prelease dependencies on release packages

@fluidframework/protocol-definitions -> ^0.1025.0
  @fluidframework/driver-definitions -> ^0.40.0

@fluidframework/container-definitions -> ^0.40.0
Server -> ^0.1032.0

@tanviraumi @znewton I was updating pre release dependencies in main after 0.49 branch release.
server/tinylicious is not building due to some errors which seems to be due changes in latest server packages. For ex 1 seems due to addition of documentID. Can you please take look at these error in build pipeline or by fetching this branch and building at your local box.
You can either push changes in separate PR or in this PR only. Thanks.


Android app crash when press back button on the appbar in the card number entry screen

Hi,
the problem occures when I am in the card number entry page and I press the back button in the appbar. Then, if I quickly press on the screen to dismiss the payment methods selection popup, the app crashes with the following errors.

This behavior doesn't happen if I come back with the device back button, so it seems to be a backbutton problem from native code
I tried to found a solution but I couldn't.
Please, if someone could help me.
Thanks

The issue has been fixed in the latest version.


move samples to dldt

this is supposed to be assigned to @IRDonch

add to whitelist

For the renamed demo, you should also change the target name.

@Wovchena is it still actual? please rebase and prepare PR to merge to develop

reopened to merge into develop: https://github.com/opencv/open_model_zoo/pull/118


Initial entry of a task query does not render correctly in kanban card

Please check that this issue hasn't been reported before.

[X] I searched previous Bug Reports didn't find any similar reports.

Expected Behavior
When a Tasks query is displayed in a Kanban card, it should always render tasks correctly.
Current behaviour
When I add a new Tasks query to a Kanban card, ala:
```tasks
not done
path includes Project A
```

the resulting card only renders the first task correctly. Subsequent checkboxes and other Tasks decorations are missing. For example, given a note Project A:

On initial entry of the card containing a task query, it's rendered as:

I've confirmed via the inspector that the checkbox and other elements are missing from the DOM on the second (and subsequent) tasks rendered in the card.
IMPORTANT: If the note is closed then reopened and/or if Obsidian is exited and restarted, the rendering (usually?) appears to be correct.  The error state can be restored by editing the task card (no changes needed) and hitting enter (or tapping 'Submit') to exit card edit.
Steps to reproduce
This was reproduced in a pristine vault, created via the following steps:

Create a new vault
Install and enable the Kanban and Tasks plugins
Create a note "Project A" with at least two tasks
Create a kanban board
Add a swimlane to the board
In the lane, add a card with a tasks query:```tasks
not done
path includes Project A
```

Hit return (or tap "Submit") to end card edit mode

Observe that the card rendering is not correct.
On further testing, in-card rendering also gets weird with very simple queries, such as:
```tasks
 not done
```

or an empty "all tasks" query:
```tasks
```

Also render poorly, where tag text and the break element get serialized into monospace in the card ala tasks<br>:

Which Operating Systems are you using?

[ ] Android
[X] iPhone/iPad
[ ] Linux
[X] macOS
[ ] Windows

Obsidian Version
1.1.12
Tasks Plugin Version
1.24.0
Checks

[X] I have tried it with all other plugins disabled and the error still occurs

Possible solution
No response

Hi, thank you very much indeed for a very clear bug report.
I can confirm the following:

That when I follow your instructions in a Kanban card, the checkbox is missing from the 2nd task.
That when I run the same query in an ordinary note, both checkboxes is displayed.

 So the difference in behaviour must be due to the Kanban code, not the Tasks code.
Therefore I do not believe that there is anything that can be done in Tasks to fix the problem, and a report should be logged in the Kanban plugin instead.
Please feel free to @ me in that report so that I see the discussion there.

Wonderful, thanks for the prompt response. I've (re-)filed an issue over on obsidian-kanban. Cheers!

Thank you!


Revisit BQ.1.1 mutation list

From Jenn Knapp (UWaterloo), mutations used by alcov for BQ.1.1:
S:N460K - T22942A
S:K444T - A22893C
ORF1b:Y264H - T14257C
ORF1b:N1191S - A17039G
ORF1a:L3829F - C11750T
ORF1b:M1156I - G16935A
ORF1a:Q556K - C1931A
S:R346T - G22599C
T2954C
C28312T
Another possibility is grouping BQ.1 with BQ.1.1

Jenn's mutation are shared with BQ.1, It might be a great idea to lump them together as BQ.1+

I agree, we're not even calling BQ.1 - but people are specifically interested in BQ.1.1 so those estimates become less informative - so I would rather close #71 before looking at merging lineages

T22942A is already on 100.00% proportion in BQ.1 while the proportion of ORF1b:N1191S is 31.31%

In BQ.1.1 T22942A has a proportion of 100.00%  while ORF1b:N1191S has a proportion  of 99.45%

Differences in coverage are being caused by our previous use of the first position in a codon as an approximation of coverage for an amino acid residue - since we are now looking at the nucleotide level mutations, we are going to see some different coverage levels among nucleotides in a codon.

Closing, please do PR in constellations repo


Only ESC, Up, Down, and ENTER work since #2337 was merged

Newsboat version (copy the output of newsboat -v or the first line of git show): r2.30.1-60-gceacb
Config file is empty.
bind-key ESC quit

Steps to reproduce the issue:

start Newsboat

enter any feed

observe that you can't quit it with q, or do anything else (except scrolling through it with Up and Down keys). Quit the dialog with ESC, which does work.

Other info you think is relevant: this regression is caused by #2337, because it's not present in b53c4f25. I didn't dig deeper.

@dennisschagt, can you please take a look at this? If the problem is not obvious, I think it'd be best to revert #2337 so people who build from Git are not stranded with a broken program.

@Minoru I cannot reproduce the issue.
Is there anything special in your setup? (I did try with my usual newsboat environment and separately with the given config: bind-key ESC quit)
Strange request, but could you retry reproducing after a clean build?
I see some strange build failures whenever switching between branches which contain the changes from https://github.com/newsboat/newsboat/pull/2324 (the logging PR, specifically commit https://github.com/newsboat/newsboat/commit/5d724acdd957), and branches which do not

I can reproduce the same behaviour as @Minoru, what is strange, when viewing feed content it does not highlight which feed entry is chosen so my first impression was that even up/down arrows don't work
Newsboat r2.30.1-60-gceacb - https://newsboat.org/
Copyright (C) 2006-2015 Andreas Krennmair
Copyright (C) 2015-2022 Alexander Batischev
Copyright (C) 2006-2017 Newsbeuter contributors
Copyright (C) 2017-2022 Newsboat contributors

Newsboat is free software licensed under the MIT License. (Type `newsboat -vv' to see the full text.)
It bundles:
- JSON for Modern C++ library, licensed under the MIT License: https://github.com/nlohmann/json
- optional-lite library, licensed under the Boost Software License: https://github.com/martinmoene/optional-lite
- expected-lite library, licensed under the Boost Software License: https://github.com/martinmoene/expected-lite

Newsboat r2.30.1-60-gceacb
System: Linux 6.1.14-1-siduction-amd64 (x86_64)
Compiler: g++ 12.2.0
ncurses: ncurses 6.4.20221231 (compiled with 6.4)
libcurl: libcurl/7.88.1 GnuTLS/3.7.9 zlib/1.2.13 brotli/1.0.9 zstd/1.5.4 libidn2/2.3.3 libpsl/0.21.2 (+libidn2/2.3.3) libssh2/1.10.0 nghttp2/1.52.0 librtmp/2.3 (compiled with 7.88.1)
SQLite: 3.40.1 (compiled with 3.40.1)
libxml2: compiled with 2.9.14

Compiled with
export CARGO_HOME=.cargo; prefix=/home/carno/.local make clean && prefix=/home/carno/.local make -j5 && prefix=/home/carno/.local make install

Looks like Debian (I'm using Siduction based on Debian unstable) is stuck with 0.22 https://tracker.debian.org/pkg/stfl


[FR]: Make pandas, numpy an optional dependency for the Python SDK

Proposal summary
We are using Opik from within AWS Lambda, and numpy impacts the package size significantly. Unfortunately, it's required as a top-level import, and we use the SDK for only tracing purposes. Can we update the SDK to support working without a numpy dependency ?
Motivation
No response

Hi @SanjayBysani!
That's a good suggestion. Yes, we'll exclude pandas from the dependencies (probably next week).

Thanks @alexkuzmik

@aadereiko, @alexkuzmik thank you so much for the quick turnaround! Would it be possible to release this soon?

@AjdinBajric it's released :)


GetChatCompletions stop returning PromptTokens and Completion Token data

Bug Report

import path of package in question: GO AzOpenAI SDK: v0.4.1
SDK version e.g. v0.4.1)
output of go version 1.21.5

What happened?

I've used the sdk for Az Open AI for go for quite a bit. Last night my API was working as expected and on every prompt Az Open AI in azure returned proper data for completion tokens int and prompt tokens int. I didn't make any code changes.  Below is a screenshot with the data in the database.

These are the options I send:
	options := azopenai.ChatCompletionsOptions{
		Messages:         messages,
		DeploymentName:   &modelDeploymentID,
		Temperature:      &temp,
		TopP:             &topP,
		FrequencyPenalty: &freqPenalty,
		PresencePenalty:  &presPenalty,
		MaxTokens:        maxTokens,
		Stop:             stop,
	}

	log.Println("getting chat completion from azure open ai api")
	resp, err := client.GetChatCompletions(ctx, options, nil)

I also see that there are multiple ways to access child data objects, but none work anymore:
Directly from .Usage.~

Or .ChatCompletions.Usage.~

I get back the response but now only the prompt response message, I don't get the usage data back. I wonder if anyone else is experiencing this issue.

Seeing the same on v0.5.0 - CompletionsUsage is nil.

(@rautscode, sorry that I didn't get back to you on this.)
@m-saksena, @rautscode, just want to make sure:

Which model are you using?
@m-saksena, are also using ChatCompletions, as @rautscode is, or just Completions?

Which model are you using?
@m-saksena, are also using ChatCompletions, as @rautscode is, or just Completions?

@richardpark-msft I am using the gpt-4-1106-preview model and the GetChatCompletionsStream API.

I too can confirm this behaviour in the latest 5.0.0, GetChatCompletionsStream no longer returns token metrics, as the property is nil.

I missed that both of you (@m-saksena, @pkrauss-prot) are using the streaming APIs. Like OpenAI itself, we don't provide those values since they're not part of the streaming API.
My understanding is that people will use a package like tiktoken (it appears there are some Go ports for this), to do the token calculation on the client-side.

@rautscode, I'm still unable to reproduce your bug with the non-streaming API.
Looking at the API nothing appears to have changed so this seems like something that's server-related, and not the SDK itself. Your next step should be to file an Azure support request, so they can look at your Azure OpenAI resource and see what is going on.
https://github.com/Azure/azure-sdk-for-go/blob/main/SUPPORT.md#how-to-file-issues-and-get-help
Closing this issue for now, but please re-open if you have any other questions or concerns.

I missed that both of you (@m-saksena, @pkrauss-prot) are using the streaming APIs. Like OpenAI itself, we don't provide those values since they're not part of the streaming API.
My understanding is that people will use a package like tiktoken (it appears there are some Go ports for this), to do the token calculation on the client-side.

I've filed an issue to track this doc update: https://github.com/Azure/azure-sdk-for-go/issues/22624


Adding unitary molecule tests for pxe_stack role

Molecute tests for pxe_stack role.

Create 2 docker containers
Converge
Run unitary tests

The automatic molecule test for rhel8 is failing due to https://bluebanquise.com/repository/releases/1.3/el8/x86_64/bluebanquise/ repository. I am suspecting that the metadata of it is outdated. IMO a createrepo --update . seems necessary.
FYI: I have downloaded all the packages for el8 1.3 , then I created a local repository and the installation has succedded.
Error message:
[root@management1 yum.repos.d]# dnf install atftp ipxe-x86_64-bluebanquise ipxe-arm64-bluebanquise httpd python3-policycoreutils clustershell python3-clustershell policycoreutils
Failed to set locale, defaulting to C
CentOS-8 - AppStream                                                                                1.7 kB/s | 4.3 kB     00:02
CentOS-8 - Base                                                                                1.6 kB/s | 3.9 kB     00:02
CentOS-8 - Extras                                                                                1.9 kB/s | 1.5 kB     00:00
Extra Packages for Enterprise Linux Modular 8 - x86_64                                                                                28 kB/s |  34 kB     00:01
Extra Packages for Enterprise Linux 8 - x86_64                                                                                15 kB/s |  19 kB     00:01
Dependencies resolved.
==========================================================================================================================================================================
 Package                                     Arch                      Version                                                      Repository                       Size
==========================================================================================================================================================================
Installing:
 httpd                                       x86_64                    2.4.37-21.module_el8.2.0+494+1df74eae                        AppStream                       1.7 M
 policycoreutils                             x86_64                    2.9-9.el8                                                    BaseOS                          377 k
 python3-policycoreutils                     noarch                    2.9-9.el8                                                    BaseOS                          2.2 M
 atftp                                       x86_64                    0.7.2-1                                                      bluebanquise                     42 k
 clustershell                                noarch                    1.8.3-1.el8                                                  bluebanquise                    135 k
 ipxe-arm64-bluebanquise                     noarch                    1.0.6-1.el8                                                  bluebanquise                    2.1 M
 ipxe-x86_64-bluebanquise                    noarch                    1.1.2-1.el8                                                  bluebanquise                    4.8 M
 python3-clustershell                        noarch                    1.8.3-1.el8                                                  bluebanquise                    266 k
Upgrading:
 audit-libs                                  x86_64                    3.0-0.17.20191104git1c2f876.el8                              BaseOS                          116 k
 libsemanage                                 x86_64                    2.9-2.el8                                                    BaseOS                          165 k
Installing dependencies:
 apr                                         x86_64                    1.6.3-9.el8                                                  AppStream                       125 k
 apr-util                                    x86_64                    1.6.1-6.el8                                                  AppStream                       105 k
 httpd-filesystem                            noarch                    2.4.37-21.module_el8.2.0+494+1df74eae                        AppStream                        36 k
 httpd-tools                                 x86_64                    2.4.37-21.module_el8.2.0+494+1df74eae                        AppStream                       103 k
 mod_http2                                   x86_64                    1.11.3-3.module_el8.2.0+486+c01050f0.1                       AppStream                       156 k
 vim-filesystem                              noarch                    2:8.0.1763-13.el8                                            AppStream                        48 k
 brotli                                      x86_64                    1.0.6-1.el8                                                  BaseOS                          323 k
 centos-logos-httpd                          noarch                    80.5-2.el8                                                   BaseOS                           24 k
 checkpolicy                                 x86_64                    2.9-1.el8                                                    BaseOS                          348 k
 diffutils                                   x86_64                    3.6-6.el8                                                    BaseOS                          358 k
 libselinux-utils                            x86_64                    2.9-3.el8                                                    BaseOS                          244 k
 mailcap                                     noarch                    2.1.48-3.el8                                                 BaseOS                           39 k
 python3-audit                               x86_64                    3.0-0.17.20191104git1c2f876.el8                              BaseOS                           86 k
 python3-libsemanage                         x86_64                    2.9-2.el8                                                    BaseOS                          127 k
 python3-setools                             x86_64                    4.2.2-2.el8                                                  BaseOS                          601 k
Installing weak dependencies:
 apr-util-bdb                                x86_64                    1.6.1-6.el8                                                  AppStream                        25 k
 apr-util-openssl                            x86_64                    1.6.1-6.el8                                                  AppStream                        27 k
Enabling module streams:
 httpd                                                                 2.4

Transaction Summary
==========================================================================================================================================================================
Install  25 Packages
Upgrade   2 Packages

Total size: 15 M
Total download size: 3.5 M
Is this ok [y/N]: y
Downloading Packages:
[SKIPPED] apr-1.6.3-9.el8.x86_64.rpm: Already downloaded
[SKIPPED] apr-util-1.6.1-6.el8.x86_64.rpm: Already downloaded
[SKIPPED] apr-util-bdb-1.6.1-6.el8.x86_64.rpm: Already downloaded
[SKIPPED] apr-util-openssl-1.6.1-6.el8.x86_64.rpm: Already downloaded
[SKIPPED] httpd-2.4.37-21.module_el8.2.0+494+1df74eae.x86_64.rpm: Already downloaded
[SKIPPED] httpd-filesystem-2.4.37-21.module_el8.2.0+494+1df74eae.noarch.rpm: Already downloaded
[SKIPPED] httpd-tools-2.4.37-21.module_el8.2.0+494+1df74eae.x86_64.rpm: Already downloaded
[SKIPPED] mod_http2-1.11.3-3.module_el8.2.0+486+c01050f0.1.x86_64.rpm: Already downloaded
[SKIPPED] vim-filesystem-8.0.1763-13.el8.noarch.rpm: Already downloaded
[SKIPPED] brotli-1.0.6-1.el8.x86_64.rpm: Already downloaded
[SKIPPED] centos-logos-httpd-80.5-2.el8.noarch.rpm: Already downloaded
[SKIPPED] checkpolicy-2.9-1.el8.x86_64.rpm: Already downloaded
[SKIPPED] diffutils-3.6-6.el8.x86_64.rpm: Already downloaded
[SKIPPED] libselinux-utils-2.9-3.el8.x86_64.rpm: Already downloaded
[SKIPPED] mailcap-2.1.48-3.el8.noarch.rpm: Already downloaded
[SKIPPED] python3-audit-3.0-0.17.20191104git1c2f876.el8.x86_64.rpm: Already downloaded
[SKIPPED] python3-libsemanage-2.9-2.el8.x86_64.rpm: Already downloaded
[SKIPPED] ipxe-arm64-bluebanquise-1.0.6-1.el8.noarch.rpm: Already downloaded
[SKIPPED] ipxe-x86_64-bluebanquise-1.1.2-1.el8.noarch.rpm: Already downloaded
[SKIPPED] python3-clustershell-1.8.3-1.el8.noarch.rpm: Already downloaded
[SKIPPED] libsemanage-2.9-2.el8.x86_64.rpm: Already downloaded
(22/27): policycoreutils-2.9-9.el8.x86_64.rpm                                                                                45 kB/s | 377 kB     00:08
(23/27): python3-setools-4.2.2-2.el8.x86_64.rpm                                                                                60 kB/s | 601 kB     00:10
[MIRROR] atftp-0.7.2-1.x86_64.rpm: Downloading successful, but checksum doesn't match. Calculated: 07568eab8513c5e95cf8a7773c4a991989c7fcf33653ce0f344a55ea818c821d(sha256)  Expected: d615a3087f5fc9dae9f493e6cf8586819940375ab75410e8c7b6cc4baceab47b(sha256)
[FAILED] atftp-0.7.2-1.x86_64.rpm: No more mirrors to try - All mirrors were already tried without success
(25-26/27): clustershell-1.8.3-1.el8.noarch.rpm                   86% [========================================================         ] 183 kB/s |  13 MB     00:10 ETA
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Error downloading packages:
  Cannot download Packages/x86_64/atftp-0.7.2-1.x86_64.rpm: All mirrors were tried
[root@management1 yum.repos.d]#

The automatic molecule test for rhel8 is failing due to https://bluebanquise.com/repository/releases/1.3/el8/x86_64/bluebanquise/ repository. I am suspecting that the metadata of it is outdated. IMO a createrepo --update . seems necessary.
FYI: I have downloaded all the packages for el8 1.3 , then I created a local repository and the installation has succedded.
Error message:
[root@management1 yum.repos.d]# dnf install atftp ipxe-x86_64-bluebanquise ipxe-arm64-bluebanquise httpd python3-policycoreutils clustershell python3-clustershell policycoreutils
Failed to set locale, defaulting to C
CentOS-8 - AppStream                                                                                1.7 kB/s | 4.3 kB     00:02
CentOS-8 - Base                                                                                1.6 kB/s | 3.9 kB     00:02
CentOS-8 - Extras                                                                                1.9 kB/s | 1.5 kB     00:00
Extra Packages for Enterprise Linux Modular 8 - x86_64                                                                                28 kB/s |  34 kB     00:01
Extra Packages for Enterprise Linux 8 - x86_64                                                                                15 kB/s |  19 kB     00:01
Dependencies resolved.
==========================================================================================================================================================================
 Package                                     Arch                      Version                                                      Repository                       Size
==========================================================================================================================================================================
Installing:
 httpd                                       x86_64                    2.4.37-21.module_el8.2.0+494+1df74eae                        AppStream                       1.7 M
 policycoreutils                             x86_64                    2.9-9.el8                                                    BaseOS                          377 k
 python3-policycoreutils                     noarch                    2.9-9.el8                                                    BaseOS                          2.2 M
 atftp                                       x86_64                    0.7.2-1                                                      bluebanquise                     42 k
 clustershell                                noarch                    1.8.3-1.el8                                                  bluebanquise                    135 k
 ipxe-arm64-bluebanquise                     noarch                    1.0.6-1.el8                                                  bluebanquise                    2.1 M
 ipxe-x86_64-bluebanquise                    noarch                    1.1.2-1.el8                                                  bluebanquise                    4.8 M
 python3-clustershell                        noarch                    1.8.3-1.el8                                                  bluebanquise                    266 k
Upgrading:
 audit-libs                                  x86_64                    3.0-0.17.20191104git1c2f876.el8                              BaseOS                          116 k
 libsemanage                                 x86_64                    2.9-2.el8                                                    BaseOS                          165 k
Installing dependencies:
 apr                                         x86_64                    1.6.3-9.el8                                                  AppStream                       125 k
 apr-util                                    x86_64                    1.6.1-6.el8                                                  AppStream                       105 k
 httpd-filesystem                            noarch                    2.4.37-21.module_el8.2.0+494+1df74eae                        AppStream                        36 k
 httpd-tools                                 x86_64                    2.4.37-21.module_el8.2.0+494+1df74eae                        AppStream                       103 k
 mod_http2                                   x86_64                    1.11.3-3.module_el8.2.0+486+c01050f0.1                       AppStream                       156 k
 vim-filesystem                              noarch                    2:8.0.1763-13.el8                                            AppStream                        48 k
 brotli                                      x86_64                    1.0.6-1.el8                                                  BaseOS                          323 k
 centos-logos-httpd                          noarch                    80.5-2.el8                                                   BaseOS                           24 k
 checkpolicy                                 x86_64                    2.9-1.el8                                                    BaseOS                          348 k
 diffutils                                   x86_64                    3.6-6.el8                                                    BaseOS                          358 k
 libselinux-utils                            x86_64                    2.9-3.el8                                                    BaseOS                          244 k
 mailcap                                     noarch                    2.1.48-3.el8                                                 BaseOS                           39 k
 python3-audit                               x86_64                    3.0-0.17.20191104git1c2f876.el8                              BaseOS                           86 k
 python3-libsemanage                         x86_64                    2.9-2.el8                                                    BaseOS                          127 k
 python3-setools                             x86_64                    4.2.2-2.el8                                                  BaseOS                          601 k
Installing weak dependencies:
 apr-util-bdb                                x86_64                    1.6.1-6.el8                                                  AppStream                        25 k
 apr-util-openssl                            x86_64                    1.6.1-6.el8                                                  AppStream                        27 k
Enabling module streams:
 httpd                                                                 2.4

Transaction Summary
==========================================================================================================================================================================
Install  25 Packages
Upgrade   2 Packages

Total size: 15 M
Total download size: 3.5 M
Is this ok [y/N]: y
Downloading Packages:
[SKIPPED] apr-1.6.3-9.el8.x86_64.rpm: Already downloaded
[SKIPPED] apr-util-1.6.1-6.el8.x86_64.rpm: Already downloaded
[SKIPPED] apr-util-bdb-1.6.1-6.el8.x86_64.rpm: Already downloaded
[SKIPPED] apr-util-openssl-1.6.1-6.el8.x86_64.rpm: Already downloaded
[SKIPPED] httpd-2.4.37-21.module_el8.2.0+494+1df74eae.x86_64.rpm: Already downloaded
[SKIPPED] httpd-filesystem-2.4.37-21.module_el8.2.0+494+1df74eae.noarch.rpm: Already downloaded
[SKIPPED] httpd-tools-2.4.37-21.module_el8.2.0+494+1df74eae.x86_64.rpm: Already downloaded
[SKIPPED] mod_http2-1.11.3-3.module_el8.2.0+486+c01050f0.1.x86_64.rpm: Already downloaded
[SKIPPED] vim-filesystem-8.0.1763-13.el8.noarch.rpm: Already downloaded
[SKIPPED] brotli-1.0.6-1.el8.x86_64.rpm: Already downloaded
[SKIPPED] centos-logos-httpd-80.5-2.el8.noarch.rpm: Already downloaded
[SKIPPED] checkpolicy-2.9-1.el8.x86_64.rpm: Already downloaded
[SKIPPED] diffutils-3.6-6.el8.x86_64.rpm: Already downloaded
[SKIPPED] libselinux-utils-2.9-3.el8.x86_64.rpm: Already downloaded
[SKIPPED] mailcap-2.1.48-3.el8.noarch.rpm: Already downloaded
[SKIPPED] python3-audit-3.0-0.17.20191104git1c2f876.el8.x86_64.rpm: Already downloaded
[SKIPPED] python3-libsemanage-2.9-2.el8.x86_64.rpm: Already downloaded
[SKIPPED] ipxe-arm64-bluebanquise-1.0.6-1.el8.noarch.rpm: Already downloaded
[SKIPPED] ipxe-x86_64-bluebanquise-1.1.2-1.el8.noarch.rpm: Already downloaded
[SKIPPED] python3-clustershell-1.8.3-1.el8.noarch.rpm: Already downloaded
[SKIPPED] libsemanage-2.9-2.el8.x86_64.rpm: Already downloaded
(22/27): policycoreutils-2.9-9.el8.x86_64.rpm                                                                                45 kB/s | 377 kB     00:08
(23/27): python3-setools-4.2.2-2.el8.x86_64.rpm                                                                                60 kB/s | 601 kB     00:10
[MIRROR] atftp-0.7.2-1.x86_64.rpm: Downloading successful, but checksum doesn't match. Calculated: 07568eab8513c5e95cf8a7773c4a991989c7fcf33653ce0f344a55ea818c821d(sha256)  Expected: d615a3087f5fc9dae9f493e6cf8586819940375ab75410e8c7b6cc4baceab47b(sha256)
[FAILED] atftp-0.7.2-1.x86_64.rpm: No more mirrors to try - All mirrors were already tried without success
(25-26/27): clustershell-1.8.3-1.el8.noarch.rpm                   86% [========================================================         ] 183 kB/s |  13 MB     00:10 ETA
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Error downloading packages:
  Cannot download Packages/x86_64/atftp-0.7.2-1.x86_64.rpm: All mirrors were tried
[root@management1 yum.repos.d]#

Issue with repo already corrected by @oxedions, thanks !
I ran again the tests and every one of them has succedded.

Dear @osmocl
Thanks a lot for this PR and for the work around automatic testing.
This effort is really appreciated 🙂
Merging.


Cursors ✕ Output Transformations fixes

Transforms pointer events under Wayland backend (see #364)
Fixes broken 180 and flipped transformation under DRM backend (introduced in #188, probably never worked properly)
Fixes disappearing software cursors when applying a 90 or 270 transformation (regression introduced in #352)
Replaces mysterious switches with easy-to-understand calls to wlr_output_transformation_* helpers

Test plan: try all 8 transformations under Wayland and DRM. Open a view, check that the pointer doesn't jump when entering the view. Check (e.g. with a GTK app with buttons) that the view receives pointer events with the right position.
Currently the hardware cursor isn't transformed under the Wayland backend, waiting for #319 to do this.

This PR is ready for review.

LGTM :+1:


Integration tests with peewee ORM

We'll need to assert the ORM usage correctness, which implies database testing: mocks, fixtures and transactions included.

As noted in #9, there will be few changes regarding models, to allow broader chat clients coverage.
Since it's now only a Bot API here, tests will be used to assert whether client-agnostic job is done right.


v0.8.0 release planning

This issue is to centralize the discussion of what will be in the v0.7.3 release. It is the forum for the the community to voice support for certain enhancements to be prioritized for the release that will then inform the milestones.
Please try to centralize your thoughts and discussion about the next release here or by numerical reference from another issue/PR E.g. #XYZ.
The GitHub milestone feature is used as a means of labeling what is planned to go into the next and subsequent releases.
The person assigned to this issue is "release manager". It is their role to track how current issues, PRs and bugfixes will add up to a release and ultimately perform that release.
To start the conversation, please discuss what you think about what's currently listed on the v0.7.3 milestone and if there's a reason to add more or remove something.

Thanks @CameronTStark. We might want to push ahead with an 0.8 release so that API changes don't linger too long.

That sounds good. Can we align what's on the Development Roadmap for v0.8.0 or should we forego that just so it's clear that there are breaking changes happening?

Maybe we should consider using GitHub projects (or Trello) as a segue or go between the roadmap in the wiki and the v0.8 milestones?
Sometimes it helps to have work organized in cards so you can reprioritize, drag them around, group, rank, etc. I believe GH projects links to issues and milestones automatically which could be convenient.
We might need to choose a product manager to curate the project board, it's busy-body work but we can rotate like the release manager.

The module refactoring / argument renaming is planned for v0.8, according to the roadmap.
In my view, some improvements could be:

normalizing the parameter names involved in single diode models, and maintaining the same order. Compare pvlib.pvsystem.calcparams_desoto output with pvlib.pvsystem.singlediode input; we can't pipe the output of the first into the second, although conceptually that's how these two functions are used.
further separating of pvlib.pvsystem, e.g. #886 for inverters, breaking out the DC models.
work on ModelChain to provide multiple entrypoints, #943 may be a start.
rethink (if needed) how pvlib manages model parameters. PVSystem.module_parameters (which is also expected to include IAM model parameters), PVSystem.temperature_model_parameters, PVSystem.inverter_model_parameters, PVSystem.losses_parameters, you get the point. Maybe this is the right design pattern, but I think it's more of an accumulation that's worth a second look.

I'd really like to see #823 in the next release.

And #717 if I can find the time to finish it, so close

Maybe we should consider using GitHub projects (or Trello) as a segue or go between the roadmap in the wiki and the v0.8 milestones?

I setup a v0.8.0 GH Project for our use to try it since it sounds like a good idea. I've disabled most of its automation because it adds new issues and PRs automatically without the ability to do so only if they have the v0.8.0 milestone.
I'm not sure this has utility above just sorting by the milestone in the issues/PRs tabs and centering the discussion there though.
I'll leave the project up for a bit just as an example to let maintainers poke at it to see if they can see a productivity advantage.

Oh no, not another round of API changes!  :(

@CameronTStark are we going to v0.8 or v0.7.3 next?  Either way is fine with me. Please set up a whatsnew file for the next release.

Just to get things moving we should just use the current v0.7.3.rst currently in place (I need to rename it since it's missing the v). If the API breaking changes occur that you've suggested we can easily change it to v0.8 with just a quick git move and a few find/replaces.

OK. #708 and #886 both change the API. #886 we can deprecate, I don't think it's worth deprecating for #708 if it goes in the next release. I'm willing to start on #894 with #958, that will have API changes.

I've changed the milestone for this issue since, per a phone discussion, we've decided to push on to v0.8.0.
Milestones of other issues will change however not all that are currently 0.7.3 will be converted to 0.8.0; some will be untagged.
From now on, tagging a PR/issue with a milestone will show the intention to address it within the given release. If a PR stagnates after being given a milestone, that milestone may be bumped or dropped. This keeps the milestone's ability to communicate fresh rather than an archive of best intentions.
If you find a milestone you disagree with please highlight it. These conversations are what these milestones are meant to drive.

Hello pvlib maintainers, thanks for all the hardwork on this package!
I was just exploring how to use ModelChain starting with POA irradiance measured by a pyranometer and eventually ended up here, so I'd like to put in a vote of support for including #943 in the v0.8 release.

I think it's time for v0.8 issue triage. I'd like to see the items with check boxes completed for v0.8:

[ ] #708, #956, #957
[ ] #943
[ ] #1000
[ ] #980
[ ] #990
[ ] #972
[ ] #939
[ ] #1029
[ ] #1009 and other whats new clean up

The issues marked X were previously mentioned in this thread as candidates for this release but I think they should be pushed to another release unless there's a commitment to finish in the next 2 weeks:
X #894
X #958
X #717
X #823
All other issues/PRs marked 0.8.0 and not discussed here can be pushed off too.

+1 to finishing #708 and related. #708 has had one review (thanks @kanderso-nrel) could use another look, in particular at the API.

I volunteer to pick up the soiling.hsu PRs #980 and #990, they don't need much.  #823 was put on hold until @mikofski and I finished writing up the report on it, which is now done.  Mark, will you have time to finish #823 for v0.8?  If not, I can take a look at it.

Hi @kanderso-nrel I'm not sure what still needs to be done for #823 I thought it was ready for review. We had toyed with changing the rotation matrices to an algebraic approach, but I thought you had backed off of that, right? Maybe update the citations to match the slope aware backtracking report?

I'm okay with postponing #717. I'll put some work into it, but I don't want it to hold up the release

I pushed a 0.8.0-beta release. I'll make a final release once #1052, #1053, and #1054 are reviewed and merged. I'm hoping that can happen tomorrow.

0.8.0 is on PyPI and the pvlib conda channel. It should be available on conda-forge within an hour or so.
Thanks @mikofski @kanderso-nrel @cwhanse for the big push to finish this release over the last few weeks.
The next one will be smaller, right???