[Unpolished prototype] 3 way merge for Git

This PR is a prototype of 3 way merge with basic Git integration. The original issues are #37350 and #146091.
The purpose of this PR is only to share ideas & code. The code is not polished.
Summary
The prototype adds an inline icon to the “Merge changes'' group in the source control view provided by Git extension. When clicked, it opens up a 3 way merge editor.
Screencast
https://user-images.githubusercontent.com/15076498/170299131-6e77b304-d71f-468f-8d55-d835a1f196b8.mp4
Details about the prototype
Directions when prototyping

Follow the existing pattern of side-by-side diff editor wherever possible

Reuse existing computeDiff API from editor (web) worker for heavy lifting

Minimize the dependency on different source control systems (e.g. Git)

Key design choices

Rely only on the resource URIs - To use the feature, an extension (or contribution) only needs to provide the URIs pointing to each of the merge participants: common ancestor, left, right. We do not rely on conflict markers provided by source control systems. As a result it has little dependency on the source control system, all together <20 lines of code in the above Git example.
In each of the 3 sub-editors, show diff with the common ancestor version - We think it’s important to be clear about what has changed since the common ancestor, in each branch.
Minimize computational cost when editing - When the content is changed, only the diff between the middle editor and the common ancestor needs to be re-computed. The cost (and responsiveness) is therefore comparable with a normal diff editor.
For now, only the 3 column layout with arrows is implemented, because it was used in our former IDE, and is by far the most preferred version to our users. We have also developed a way to accept both (simple changes only) using arrows with some visual cues.

Any manual changes to a conflict region will make all arrows of the current region disappear. Undo (Ctrl+Z) can bring those back.
We didn’t have the bandwidth to implement the mixed / horizontal layouts. But they can be added later.
Checkboxes can be a configurable future work, especially for mixed layout.

Alternative considered
Nothing fundamental. Most of the alternatives should be covered above.
Current limitations

Merge navigator - This should provide the functionality to navigate between conflicts / diffs in the file easily. It may also allow users to jump to the first conflict when they open the editor. It’s not implemented yet (but is in the plan), but users can see the regions in the overview on the right.
View zones due to line wrapping - When the user enables line wrapping (instead of horizontal scrollbar), one code line may take up several actual lines. View zones need to be adjusted so that the versions are correctly aligned in this case. It’s not implemented yet (but is in the plan).
Branched / Deleted / Adding files - In this Git example we didn’t consider alternative file operations like branching / deleting / adding.
Editor banner - In our version, we show details about each branch on top of the sub-editors (e.g. commit message, author, link, etc.). This Git prototype does not have it, but should be easily available via IMergeEditor.updateBanner API in the code shared above.

User feedback

Our users like the 3 column layout the most, probably also because our former IDE uses it.
Discoverability issue - The merge view and merge actions from the source control view on the sidebar / bottom are not very discoverable. Users want to have more visible ways (e.g. buttons) to review and perform merge changes.
Users would like to have better ways to navigate inside the merge editor (diffs, merges), possibly also via keyboard shortcuts.
Users like the detailed information about each branch shown on the banner on top of the sub-editors.
Users would like to see the view automatically expanded when opening a merge editor, since it requires a lot of horizontal real estate.

Mixed layout could solve this as well.

Users would like to have the ability to bulk resolve conflicts by accepting all ours / all theirs.

Next steps

(If required) Change from exposing a command to a proposed API.
(If required) Support branching / deleting / adding files.
(If required) Get rid of the “confirm to replace” dialog when saving the merge result.

The dialog is theoretically accurate (since the merge editor is a layer on top of the current file), but nevertheless an additional step for users, so we can allow users to configure to skip it.

Bulk resolving conflicts.
Merge navigator with keyboard shortcuts.
View zones due to line wrapping.
Intra-region code line alignment - It’s not implemented yet (but is in the plan). Currently the code is only aligned up to the level of conflict regions. Within each conflict region, the prototype does not try to align code lines further.
Toolbar buttons to navigate, accept, and mark the file as resolved - Our experience shows that source control view on the sidebar / bottom is not very discoverable by users unfamiliar with the tool. We think the highly visible toolbar buttons can help. Of course we can make this configurable in settings.
Design an API that simplifies for most source control users (e.g. Git). Currently there’s still work to do to add banners to the editor.
Allow partially resolved states to be saved, so that one can resolve part of a file, save, close, then come back later.
Smart merge feature - We can look into providing some suggested resolve ways to users, e.g. when they hover over / put the cursor in a conflict region, and provide ways to accept / reject them.

@Mingpan thank you very much for this PR, we appreciate your openness to collaborate and share ideas.
As we have discussed we already started on the 3 way merge implementation, and we have an initial version that we just merged yesterday. It lacks tests and probably does not cover all the corner-cases for viewzones, so there is still a lot of work to be done. This work is captured in this PR https://github.com/microsoft/vscode/pull/150391
Having said that, we have tried out your great PR and there are definitely things we can learn from. The best next step would be for @hediet to meet with @Mingpan so you can go into technical details. I will try to setup something for next week.
Apart from that I really appreciate that you shared the User Feedback, we take this very seriously fyi @daviddossett
I am very excited about this collaboration and am looking forward to bring the 3-way merge editor to all our users out there.

Thank you again for the PR 👏  I know that you and @hediet have synced on this approach and it inspired our implementation.
I will go ahead and close this PR since as we agreed we do not have plans to merge it in directly.


Strange lfs_file_write() return value

Hi!
I'm using LFS v2.0.0 for storing some 16MB firmware files on an SPI NAND flash. I experienced no problems on known good flash devices, but now I'm testing it on a chip with a few bad blocks.
I have assertions and all kinds of logs enabled. Sometimes I see block relocations in the log, but the file system works fine. But sometimes writes are failing for no apparent reason.
For testing I have tried to write the files in 32 byte operations (yes, terribly small buffer, I'm working on it).
At about 1 MB lfs_file_write() returns 50 for a 32 byte write. The log is empty. If I ignore this and keep writing and read the file back, there are some missing parts in the file and the size is about 400 bytes smaller than it should be.
Do you have any suggestions on debugging this issue?
Flash chip info:

Page size: 2176 bytes (2048 + 128 bytes)
Block size: 64 pages (128K + 8K bytes)
Plane size: 1Gb (1 plane, 1024 blocks per plane)
Erasable per block. Should be written by page for the on-chip ECC to work

LFS config

Read size: 1
Program size: 2048
Block size: 64*2048
Block count: 1024
Block cycles: 10
Cache size: 2048
Lookahead size: 64
Max file size: 20*1024*1024 (20 MB)
The others are default, and the buffers are allocated manually

EDIT:
I forgot to mention that my SPI flash driver didn't report any errors during the tests, and I am fairly confident that it works fine.

My SPI flash driver works fine indeed, but the erase wrapper function did not convert its error code correctly, so LFS did not receive LFS_ERR_CORRUPT. I'm sorry for bothering you.

Out of curiosity, was your SPI flash driver returning positive error codes? Currently LittleFS breaks if that happens, as it only expects negative error codes (related https://github.com/ARMmbed/littlefs/issues/169).

Yes, it does.
The problem was that I forgot to convert it to LittleFS compatible codes in my erase function.


Add applyVars to dev websocket

Support applyVars endpoint which is used to preview variable changes on test devices.
This is similar to https://github.com/Leanplum/Leanplum-Android-SDK/pull/91 and relies on https://github.com/Leanplum/Leanplum/pull/209

Fixed indentation and removed extra line.

To enable your commits show up in the release notes properly, I would recommend rebasing, and renaming your commit messages in the style of https://leanplum.atlassian.net/wiki/spaces/ENG/pages/70851932/Commit+Message+Style (first line is sufficient for us :))

Rebased and amended.

@milos1290 Do we have unit tests for sockets? I wasn't able to locate them when I glanced it.

test this please

Please use 'Squash and merge'. Make sure the title is feat(websocket): Add applyVars


feat(button): update variant lined to line

Checklist

[ ] Fix linting errors
[ ] Tests have been added / updated (or snapshots)

Change information

This change is

:tada: This PR is included in version 1.0.0-alpha.17 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Fluid renderer: Don't dispose of effects when disposing of fluid objects

That's because effects are cached by the engine.
This means that if the same effect is used in different places in the code (which is the case in the fluid renderer, if you add several particle systems, for example), disposing of the effect in one place will cause the code to crash in all other places.
Example of PG that generates errors: https://playground.babylonjs.com/#9NHBCC#63
If you wait a few seconds, you will see these errors in the console log:
WebGL: INVALID_OPERATION: useProgram: attempt to use a deleted object
[.WebGL-0000223000726A00] GL_INVALID_OPERATION: Active draw buffers with missing fragment shader outputs.

Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s).
To prevent this PR from going to the changelog marked it with the "skip changelog" label.

WebGL2 visualization test reporter:
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/15211/merge/testResults/webgl2playwright/index.html

Visualization tests for WebGPU (Experimental)
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/15211/merge/testResults/webgpuplaywright/index.html


FancyZones add position-only "zones" (points)

Provide a description of the new feature / enhancement
Sometimes I'd like to have a "zone" that just snaps a Window to a preferred location without changing the window size.

Do you mean to onky define the x and y coordinate of the wibdow?

Do you mean to onky define the x and y coordinate of the wibdow?

Correkt.

can you explain the use case?  Understanding the why's are super important


More Meaningful Test Time Results

🚀 Feature Proposal
Problem:
Test run time for a dozen simple low-level functions is shown as '2.155 s', whereas functions run in a few milliseconds.
The millisecond precision that is currently shown implies that the precision is meaningful and related to code run time, whereas in this case it is actually mostly related to Jest run time.
Millisecond precision could only possibly be useful if it was actually strongly correlated to code run time.
Total test time is only useful to know when you want to come back to check on the test—do you have time to grab a coffee, go for a walk, go for groceries; or should you just check for an email you were waiting for?  For total test time, tenth-of-a-second precision is not necessary or useful: although it provides a flashy interface, it is distracting to an operator looking for information about when to check on the test result.
Proposed Solution:
Separate the two concerns by reporting two separate values:
1. First concern: "How long does my code take to run?"
Provide total run time of actual code, by summing runtimes of individual test runs.  Large number of short-running functions could lead to inaccuracies, so show precision based on possibly losing or gaining 1 ms for each test that is run: (6 ms in the example below thus implies that 6 tests have been run; each of those tests could be off by 1 ms in either direction).
Code run: 7.513 s ± 65 ms

or:
Code run: 3 ms (± 6 ms?)

Note:  When the reported margin is greater than the total reported code run as shown in the second example above, place the margin in parentheses, add a question mark as shown, and darken the console color, to avoid distracting the operator with the apparently absurd value.
2. Second concern: "How long did my test take to run last time—when should I come back to check on it?"
Provide total test time in human-optimized time units:

Provide largest two adjacent time units: [days, hours] or [hours, minutes] or [minutes, seconds] or [seconds]
Always round smaller unit to nearest whole number

Operators don't need to distinguish tenths of an hour if testing is a matter of days
Operators don't need to distinguish tenths of a minute if testing is a matter of hours
Never need to distinguish tenths of a second

This information is mostly useful to know long the test can be expected to take in the future.  Avoiding unnecessary implied precision will help humans to remember the value, and will avoid implying that the test will have exactly the same duration every time it is run.  (Consider also saving this output line and outputting at the beginning of the test on subsequent test runs)
Motivation
Motivation is to avoid distracting the operator with non-useful or even misleading metrics, but to answer the two questions the operator is likely to have.
Example
Operator does not need to opt in. Sample output:
Test Suites: 3 passed, 3 total
Tests:       25 passed, 25 total
Snapshots:   0 total
Code Run:    3 ms (± 25 ms?)
Total Time:  2 s

Ran all test suites.

or: (I don't know what these numbers would look like)
Test Suites: 313 passed, 313 total
Tests:       2,438 passed, 2,438 total
Snapshots:   0 total
Code Run:    76 m, 43 s (± 2 sec)
Total Time:  1 h, 23 m

Ran all test suites.

Pitch
The proposed feature adjustment directly answers the two questions the operator is likely asking about test time, in a manner that suits long-run and short-run tests, and in a non-distracting and human-optimized manner, rather than providing a time report that needs to be interpreted and which may have missing information.

I'm happy to take a PR tweaking this output


Filipino translations page required.

How to add Filipino translations? Wanted to add one.
Since there is no file for that at the moment.
I can create one but what to name the file - free-programming-books-??.md
Regards.

@eshellman What should be done for this new addition?

So there is no 2 character code for Filipino (No 639-1 code) but a 3 character code (639-2) for Filipino as "fil".
Requesting to allow me to make the aforementioned changes.

do you mean tagalog? that would be tl

Am talking about Filipino language.
For eg.
For French, we got fr. (free-programming-books-fr.md)
For Russian we got ru. (free-programming-books-ru.md)
How to name the Filipino document?

TL;DR: I'm not a linguist, but I think...

Tagalog can be used for the language code if we're keen on using ISO 639-1, or 2 character long language codes.
Alternatively, as Filipino is officially a language, it could be nice to use the ISO 639-2 or ISO 639-3, but if this happens it might be worth considering if existing files should be changed to use ISO 639-3 character long language codes as well for consistency, for example, eng instead of en.

I checked Weblate which is a cloud translation platform, they appear to use ISO 639-1, unless the language doesn't have one, then it uses 639-3 instead, for example for Filipino.

Since the repository currently has all languages with 2 characters, it looks like we're using ISO 639-1 language codes.
I just gave it a peek, I don't see an ISO 639-1 code for Filipino. :thinking:
The list of ISO 639-1 codes on Wikipedia note under the language "Tagalog":

Note: Filipino (Pilipino) has the code [fil]
- https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes

It seems Filipino and Tagalog are separate languages on paper, however they're practically the same if not synonyms?

While the official view (shared by the government, the Komisyon ng Wikang Filipino, and a number of educators) is that Filipino and Tagalog are considered separate languages, in practical terms, Filipino may be considered the official name of Tagalog, or even a synonym of it.
- https://en.wikipedia.org/wiki/Filipino_language#Filipino_versus_Tagalog

Filipino does have its own ISO 639-2 / ISO 639-3 code though of fil as @kakashi215 has pointed out.
The following is a list of ISO 639-2 codes on Wikipedia:
https://en.wikipedia.org/wiki/List_of_ISO_639-2_codes

As an addition, regardless of the conclusion of this.
May I suggest whatever standard is being used for the language, that it gets documented in the contribution guide?

yes, we use iso language codes. so, for example, german is "de" and spanish is 'es'

What I was pointing out though is that it looks like we're using ISO 639-1 though, but Filipino which is an official language, doesn't have a ISO 639-1 code; only a ISO 639-2 and ISO 639-3 code.
So, in other words, should the repository use an ISO 639-3 code (3 characters) if a language doesn't have an ISO 639-1 code (2 characters)?

I think we should use 639-3 codes. It is important to officially support all languages.
Using closest similar language (like Tagalog for filipino) isn't a scalable approach.
Hence I'd like to work with 639-3 codes as well.

I'll defer to a Filipino speaker on this. either fil of tl is ok, but I don't want Filipinos complaining about the choice! https://en.wikipedia.org/wiki/Tagalog_language#Controversy

I copy some feedback made by natives
Originally posted by @genepride, @petemadis, @cjjp-sushi in https://github.com/EbookFoundation/free-programming-books/issues/6504#issuecomment-956519688

If you label the language of the Filipinos you can just use the .fil (Filipino). Tagalog is where the Filipino language was derived from, lets just say the Tagalog language is the old version and the Filipino language is the new version.
In a sense, the Filipino language is just an upgraded 2.0 version of Tagalog.
Filipino is the national language of the Philippines. Are "Tagalog," "Pilipino" and "Filipino" different languages? No, they are mutually intelligible varieties, and therefore belong to one language.


Cherry-pick changes for ComputeClangResourceDirectory on Windows

This is useful for having swift debugging on a Windows host, so I'd like to cherry-pick them into stable.
cc @compnerd @adrian-prantl

@swift-ci please test

@swift-ci please test

CC: @dcci @adrian-prantl @fredriss

ping! @adrian-prantl

Can you also add r356057 and r355994? I had to fixup the macOS implementation a little bit to get all tests to pass.

Ah, you did!

@swift-ci please test


Using make_writer_for instead of make_writer

Issue #, if available:
#15
Description of changes:
This pr change the use of make_writer to make_writer_for so the writer could access metadata info. This enable the use case of having to filter on writer level while still getting the context from other tracing level. Previously if using filter on registry level, the context wont be propagate.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

I have two example usage why make_write_for is needed.
use tracing_bunyan_formatter::BunyanFormattingLayer;
use tracing_bunyan_formatter::JsonStorageLayer;
use tracing_subscriber::{
    filter::LevelFilter, fmt::writer::MakeWriterExt, layer::SubscriberExt, util::SubscriberInitExt,
};

#[tokio::main]
async fn main() {
    tracing_subscriber::registry()
        .with(LevelFilter::TRACE)
        .with(JsonStorageLayer)
        .with(BunyanFormattingLayer::new(
            "testing".into(),
            std::io::stdout.with_max_level(tracing::Level::ERROR),
        ))
        .init();

    let span = tracing::span!(tracing::Level::INFO, "new span", foo = "bar");
    let _enter = span.enter();
    tracing::error!("error");

}

in this example, if I want to filter out ERROR level log only, the error log won't vet data from span context.
This this the formated output that I get
[2023-08-15T09:38:07.306Z] ERROR: testing/2417477 on mustafa-pc: error (file=src/main.rs,line=20,target=rust_test)
but if i filter the output on writer level, i could get the context.
use tracing_bunyan_formatter::BunyanFormattingLayer;
use tracing_bunyan_formatter::JsonStorageLayer;
use tracing_subscriber::{
    filter::LevelFilter, fmt::writer::MakeWriterExt, layer::SubscriberExt, util::SubscriberInitExt,
};

#[tokio::main]
async fn main() {
    tracing_subscriber::registry()
        .with(LevelFilter::TRACE)
        .with(JsonStorageLayer)
        .with(BunyanFormattingLayer::new(
            "testing".into(),
            std::io::stdout.with_max_level(tracing::Level::ERROR),
        ))
        .init();

    let span = tracing::span!(tracing::Level::INFO, "new span", foo = "bar");
    let _enter = span.enter();
    tracing::error!("error");

}

this is the formated output
[2023-08-15T09:40:40.764Z] ERROR: testing/2420917 on mustafa-pc: [NEW SPAN - EVENT] error (file=src/main.rs,foo=bar,line=20,target=rust_test)
Another usecase that I have it to use make_writer_for for writing error and warn log to stderr and the rest on stdout This functionality requires make_writer_for. This usecase is described in tracing-subscriber docs https://docs.rs/tracing-subscriber/latest/tracing_subscriber/fmt/trait.MakeWriter.html#method.make_writer_for
@LukeMathWalker I hope this example is convincing enough for you to merge this pr.

Definitely compelling and it helped me understand the difference quite clearly. Thanks for the contribution!


cannot find module providing packages(ackhandler, congestion, qerr, h2quic...) with go1.17.5 when executing go get -t -u ./...

Hi Dear developers,
I've tried to run the quic-go codes on my Ubuntu 20.04 Machine, the go version is 1.17.5, and the module was initiated by
go mod init quic-go
But when I tried:
go get -t -u ./... to fetch the dependencies, I got logs below, indicating that many packages can't be found in any modules.
I tried to search these packages on GitHub but no results were found. Could anyone offer precious help?
packages:

github.com/lucas-clemente/quic-go/ackhandler
github.com/lucas-clemente/quic-go/congestion
github.com/lucas-clemente/quic-go/internal/crypto
github.com/lucas-clemente/quic-go/qerr
github.com/lucas-clemente/quic-go/h2quic
github.com/lucas-clemente/quic-go/internal/mocks/mocks_fc
github.com/lucas-clemente/quic-go/integrationtests/tools/testlog
github.com/lucas-clemente/quic-go/integrationtests/tools/testserver

logs:
quic-go imports
	github.com/lucas-clemente/quic-go/ackhandler: cannot find module providing package github.com/lucas-clemente/quic-go/ackhandler
quic-go imports
	github.com/lucas-clemente/quic-go/congestion: cannot find module providing package github.com/lucas-clemente/quic-go/congestion
quic-go imports
	github.com/lucas-clemente/quic-go/internal/crypto: cannot find module providing package github.com/lucas-clemente/quic-go/internal/crypto
quic-go imports
	github.com/lucas-clemente/quic-go/qerr: cannot find module providing package github.com/lucas-clemente/quic-go/qerr
quic-go/example imports
	github.com/lucas-clemente/quic-go/h2quic: cannot find module providing package github.com/lucas-clemente/quic-go/h2quic
quic-go tested by
	quic-go.test imports
	github.com/lucas-clemente/quic-go/internal/mocks/mocks_fc: cannot find module providing package github.com/lucas-clemente/quic-go/internal/mocks/mocks_fc
quic-go/benchmark tested by
	quic-go/benchmark.test imports
	github.com/lucas-clemente/quic-go/integrationtests/tools/testlog: cannot find module providing package github.com/lucas-clemente/quic-go/integrationtests/tools/testlog
quic-go/integrationtests/chrome tested by
	quic-go/integrationtests/chrome.test imports
	github.com/lucas-clemente/quic-go/integrationtests/tools/testserver: cannot find module providing package github.com/lucas-clemente/quic-go/integrationtests/tools/testserver

If my issue is not in a good manner, please tell me how to modify it, please!

You might want to use a different name for your module than the one of the library you’re importing.

@marten-seemann Thanks so much for the quick reply! however, after deleting all the local repositories, cloning, and naming the module as vm-mpquic, the problem still exists.
logs:
vm-mpquic imports
	github.com/lucas-clemente/quic-go/ackhandler: cannot find module providing package github.com/lucas-clemente/quic-go/ackhandler
vm-mpquic imports
	github.com/lucas-clemente/quic-go/congestion: cannot find module providing package github.com/lucas-clemente/quic-go/congestion
vm-mpquic imports
	github.com/lucas-clemente/quic-go/internal/crypto: cannot find module providing package github.com/lucas-clemente/quic-go/internal/crypto
vm-mpquic imports
	github.com/lucas-clemente/quic-go/qerr: cannot find module providing package github.com/lucas-clemente/quic-go/qerr
vm-mpquic/example imports
	github.com/lucas-clemente/quic-go/h2quic: cannot find module providing package github.com/lucas-clemente/quic-go/h2quic
vm-mpquic tested by
	vm-mpquic.test imports
	github.com/lucas-clemente/quic-go/internal/mocks/mocks_fc: cannot find module providing package github.com/lucas-clemente/quic-go/internal/mocks/mocks_fc
vm-mpquic/benchmark tested by
	vm-mpquic/benchmark.test imports
	github.com/lucas-clemente/quic-go/integrationtests/tools/testlog: cannot find module providing package github.com/lucas-clemente/quic-go/integrationtests/tools/testlog
vm-mpquic/integrationtests/chrome tested by
	vm-mpquic/integrationtests/chrome.test imports
	github.com/lucas-clemente/quic-go/integrationtests/tools/testserver: cannot find module providing package github.com/lucas-clemente/quic-go/integrationtests/tools/testserver

My commands to load and add dependencies for the repository is: (in my GOPATH/src/github.com/lucas-clemente/)
git clone https://github.com/lucas-clemente/quic-go.git
cd quic-go
git remote add mp-quic https://github.com/qdeconinck/mp-quic.git
git fetch mp-quic
git checkout conext17
go mod init vm-mpquic
go get -t -u ./...

Could there be any other possible reasons for this problem?

Maybe it's not a good idea to close the issue so fast.. We didn't even get to where the problem lies...

I have no idea what you’re trying to do, but this is definitely not a quic-go problem. You could ask the mpquic guys for help.

@marten-seemann I know this is closed out, but I just recently ran into a similar issue and my standard golang debugging led me nowhere. I'm not asserting it is an issue with this library, but at least hoping you can help nudge me in the right direction.
How to reproduce
$ go install github.com/caddyserver/xcaddy/cmd/xcaddy@latest
$ xcaddy build --with github.com/pyed/ipfilter

Error
2022/02/07 22:15:23 [INFO] exec (timeout=0s): /usr/bin/go get -d -v github.com/pyed/ipfilter
github.com/pyed/ipfilter imports
	github.com/caddyserver/caddy/caddyhttp/httpserver imports
	github.com/lucas-clemente/quic-go/h2quic: cannot find module providing package github.com/lucas-clemente/quic-go/h2quic
2022/02/07 22:15:24 [FATAL] exit status 1

@marten-seemann I ended up posting here instead: https://github.com/caddyserver/caddy/issues/2560 since it seemed more appropriate.


How to build on OpenBSD

From issue#633 it appears that stack is required from building postgrest, but I can't seem to find any direction on building stack from source at http://docs.haskellstack.org/en/stable/install_and_upgrade/
Is there a tutorial available for building postgrest on platforms that don't have the pre-built Haskell prerequisites?
I'm using ghc-7.10.3

why stack from source?
why not install it like here http://docs.haskellstack.org/en/stable/install_and_upgrade/#freebsd

oh, openbsd ... nevermind, too complicated to try and manually download and install all the packages without stack

try reading here https://github.com/commercialhaskell/stack/issues/416

it seems you are in luck
there is a vagrant image that has stack installed
https://github.com/commercialhaskell/stack/blob/master/etc/vagrant/openbsd-5.9-amd64/Vagrantfile
boot it up and compile postgrest there

cabal install stack (from commercialhaskell/stack#416) almost works. I'll take a look at what tricks are used in the vagrant file

I ran an OpenBSD image on EC2 (OpenBSD 5.9 Release P0 (ami-221a0748)) as a t2.medium instance. I was able to build it with these commands:
pkg_add ghc cabal-install git postgresql-server
cabal update
cabal install -j --disable-documentation stack

git clone https://github.com/begriffs/postgrest.git
cd postgrest
~/.cabal/bin/stack setup
git checkout v<IP_ADDRESS>
~/.cabal/bin/stack build

I put the binary here for you to use http://bin.begriffs.com/temp/postgrest-<IP_ADDRESS>-openbsd.tar.xz


update strapi to the latest version

Hi, there where a few changes necessary to update to the latest version of strapi.
This variable had to be added to config/admin.js:
https://github.com/render-examples/strapi-sqlite/commit/e1b8a50b5ce525e972506056b04d43ac1f61fe15
and it also needs to get autogenerated by the render.yaml:
https://github.com/render-examples/strapi-sqlite/commit/a17579f17c9f14d201c9aa4546ee42d3d2e44e3a
I made a short video to explain how this template can be used: https://www.youtube.com/watch?v=d1o8xqTAWio
Thanks,
Spirobel

Any updates on this?


[core-xml] prepare for 2024 October release

update version and date in CHANGELOG

API change check
API changes are not detected in this pull request.

template test timeout is known and unrelated.

/check-enforcer override


Android notifications are always persistent/locked

Since recent versions notifications on android are persistent and can't be dismissed/removed from notifications center. This used to be fine before. Looks like a regression bug. Does anyone face this issue or is it only me?

Just found out this happens since v0.6.19 and onward. Works fine in v0.6.18+2

Having the same issue. All dimiss methods not working.

Hi! Sorry for taking so long to respond to your issue on GitHub. I was focused on releasing the new 0.7.0 version of awesome_notifications and awesome_notifications_fcm and i didn't had time enough to do both. But now I can answer all your questions.
So now i'm asking you to recreate this topic using the new issue template. There's a lot of missing informations that i need to understand your problem, and all the instructions are already in the new issue template. Also, remember to check beforehand if your issue was posted by another user.
So I will automatically close all previous issues so far.
Sorry for the inconvenience and i will be waiting for your new issue request.
Thank you so much for your support!


Various fixes

Consistency in parameter naming
Fix the typo in the code example

#sign-off

Hello, is anything else needed for the merge?

@zikato no, it is good to go. Thanks for your contribution.
@Jak-MS I'm not sure if you're the right address, but please note that @shsagir signed off on this PR and it is ready to be merged.
#sign-off


Untag discovery as an allowed dependency

Breaking change

Proposed change

Discovery integration was marked as an always available integration. This is no longer the case and this caused some integrations to import from it, and breaking on missing requirement netdisco.
This untags discovery to be always installed and fixes the missing manfiests.
Fixes #31919
CC @springstan
fixes #31612
fixes #30617
fixes #30120
fixes #29866
Type of change

[ ] Dependency upgrade
[ ] Bugfix (non-breaking change which fixes an issue)
[ ] New integration (thank you!)
[ ] New feature (which adds functionality to an existing integration)
[ ] Breaking change (fix/feature causing existing functionality to break)
[ ] Code quality improvements to existing code or addition of tests

Example entry for configuration.yaml:

# Example configuration.yaml

Additional information

This PR fixes or closes issue: fixes #
This PR is related to issue:
Link to documentation pull request:

Checklist

[ ] The code change is tested and works locally.
[ ] Local tests pass. Your PR cannot be merged unless tests pass
[ ] There is no commented out code in this PR.
[ ] I have followed the development checklist
[ ] The code has been formatted using Black (black --fast homeassistant tests)
[ ] Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

[ ] Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

[ ] The manifest file has all fields filled out correctly.
Updated and included derived files by running: python3 -m script.hassfest.
[ ] New or updated dependencies have been added to requirements_all.txt.
Updated by running python3 -m script.gen_requirements_all.
[ ] Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

[ ] No score or internal
[ ] 🥈 Silver
[ ] 🥇 Gold
[ ] 🏆 Platinum

Should we update the manifest documentation to include after_dependencies?

It has been updated for the next release of the dev docs: https://developers.home-assistant.io/docs/en/next/creating_integration_manifest.html#after-dependencies


Envoy Gateway logo design

Description:
As we maintainers discussed in Slack, eg needs a logo built on top of envoyproxy logo.
This might need some helps from CNCF artwork.
cc @envoyproxy/admins , @envoyproxy/gateway-maintainers

reopening this issue since we dont have a dedicated envoy gateway logo yet

as a temporary measure I propose we use the Envoy logo with the gateway text below similar to the image shared below (w/o the pink) . This allows us to have a logo for now and we can contnue iterating to find a better one

wdyt @envoyproxy/gateway-maintainers @envoyproxy/gateway-reviewers

+1, better than nothing

+1

+1
Nit gateway -> Gateway

+1
Thanks

+1

Here are some logos designed by CNCF Service Desk:

like the second one, share the same design language as envoyproxy.

raised a new issue with CNCF https://cncfservicedesk.atlassian.net/servicedesk/customer/portal/1/CNCFSD-2420
based off the comment in https://github.com/envoyproxy/gateway/issues/2147#issuecomment-2207706188
@MB-Designs helped create these logos (thanks !) attaching them here, everyone please share your thoughts ( 👍  / 👎 )

3 looks overall best IMO and good for places where there is enough horizontal room to include it such as on page headers, 4 as a nice option for things that take up a circular/square frame so that there is less white space.

This one from above I really like the skewed/stacked icon and it looks good, but I think we should stick with the flat design as that is what the main envoy website/project uses.

+1 for 3 or 4

thanks everyone for sharing your preference ! looks like 3 & 4 is the preferred option here for the short term, hopefully we can iterate and build another logo out in the long term
@MB-Designs chatted with @@nate-double-u , and you should be able to raise a PR in https://github.com/envoyproxy/artwork/ , Nate suggested creating another dir inside https://github.com/cncf/artwork/tree/main/projects/envoy

@arkodg @nate-double-u
I don't have upload rights. Could you give me access?
I also generated a logo overview presentation and the final logo source files.
Envoy Gateway Logo Final Source.zip
Envoy Proxy Logo Final Source.zip
envoy-gataway-logo-final.pdf
envoy-proxy-logo-final.pdf

Hi, thanks for this @MB-Designs!
Could you package this like we do over in cncf/artwork?
I'd like to create a folder under the existing envoy stuff for this.
Here's the format we use:
├── envoy-logo-final.pdf
├── horizontal
│   ├── black
│   │   ├── envoy-horizontal-black.png
│   │   └── envoy-horizontal-black.svg
│   ├── color
│   │   ├── envoy-horizontal-color.png
│   │   ├── envoy-horizontal-color.svg
│   │   ├── envoy-horizontal-white-text.png
│   │   └── envoy-horizontal-white-text.svg
│   └── white
│       ├── envoy-horizontal-white.png
│       └── envoy-horizontal-white.svg
├── icon
│   ├── black
│   │   ├── envoy-icon-black.png
│   │   └── envoy-icon-black.svg
│   ├── color
│   │   ├── envoy-icon-color.png
│   │   └── envoy-icon-color.svg
│   └── white
│       ├── envoy-icon-white.png
│       └── envoy-icon-white.svg
└── stacked
    ├── black
    │   ├── envoy-stacked-black.png
    │   └── envoy-stacked-black.svg
    ├── color
    │   ├── envoy-stacked-color.png
    │   ├── envoy-stacked-color.svg
    │   ├── envoy-stacked-white-text.png
    │   └── envoy-stacked-white-text.svg
    └── white
        ├── envoy-stacked-white.png
        └── envoy-stacked-white.svg

@nate-double-u what naming convention and structure do you prefer here ?

should we rename the envoy proxy logos or let them be as is ?
should the envoy gateway logos be prefixed with envoy-gateway?

should we rename the envoy proxy logos or let them be as is?

Let's leave those as is, there may be links to them around and making a redirect in a github repo is hard.

should the envoy gateway logos be prefixed with envoy-gateway?

I think we should create a new folder for this work in the cncf/artwork repo.
The exsting envoy logos are in the artwork/projects/envoy folder, so I suggest either:

artwork/projects/envoy/envoy-gateway
artwork/projects/envoy-gateway

(I don't think I have a strong preference for either option)

thanks for the response +1 to artwork/projects/envoy/envoy-gateway

horizontal

@nate-double-u I will generate a logo package.

@nate-double-u @arkodg Envoy gateway logo package has been generated.
envoy-gateway-logo-final.zip

Thanks @MB-Designs, i've opened a PR over in cncf/artwork: https://github.com/cncf/artwork/pull/505 (and do have a question for you over there 🙂)

https://github.com/cncf/artwork/pull/505 has merged in, I think this means we can close this issue :)
Thanks for all the work @MB-Designs!

great, thanks @MB-Designs @Xunzhuo @nate-double-u !


Updates Vessel to use newer IP command instead of IFCONFIG.

Many newer Linux systems are moving away from ifconfig in favor of newer ip command for networking functions.
This changes XDEBUG_HOST line to use this newer command.
Granted, I don't use XDEBUG, but it was causing the command not found error every time vessel is run.
Tested on OpenSUSE Tumbleweed only but ip is a pretty universal command.

Thanks, this will be an important step for future-proofing the project! I may edit it to attempt to use ip first and, if it doesn't find it, use ifconfig as a backup.


Redirected to http:// after adding watch on https:// BASE_URL

Version
v0.39.5
To Reproduce

  image: ghcr.io/dgtlmoon/changedetection.io
  environment:
   - BASE_URL=https://foobar

Add a watch
Be redirected to http://foobar

Expected behavior
2. Be redirected to https://foobar
Screenshots

https://github.com/dgtlmoon/changedetection.io/wiki/Configurable-BASE_URL-setting

tested using a self-signed certificate and the -s option, works fine, no problems

dgtlmoon/changedetection.io/wiki/Configurable-BASE_URL-setting

Thanks, I did not notice the notice. I don't remember visiting the wiki page. Pardon for troubles.

dgtlmoon/changedetection.io/wiki/Configurable-BASE_URL-setting

Thanks, I did not notice the notice. I don't remember visiting the wiki page. Pardon for troubles.


segfault when looking up "index" in libaig

This is no longer reproducible on dac6d0b7077e691e972e871501f612e606ec199a. Closing as FIXED.


Switch ObjC Bazel target for the core library to use the secure version

Part of #2120.
Tested with a non-publishable Bazel package for OpenSSL iOS.

What is //external:libssl_objc?

Technically, it refers to whatever library the user configures with that name in her WORKSPACE file. Practically, an objc_library or objc_import target for OpenSSL. Cf. https://github.com/grpc/grpc/blob/master/BUILD#L372


Appstudio update mvp-test-component

Pipelines as Code configuration proposal

Pipelines as Code CI/mvp-test-component-on-pull-request has successfully validated your commit.

StatusDurationName

✅ Succeeded
6 seconds
init

✅ Succeeded
13 seconds
clone-repository

✅ Succeeded
1 minute
build-container

✅ Succeeded
11 seconds
deprecated-base-image-check

✅ Succeeded
11 seconds
inspect-image

✅ Succeeded
18 seconds
clair-scan

✅ Succeeded
57 seconds
clamav-scan

✅ Succeeded
11 seconds
sbom-json-check

✅ Succeeded
16 seconds
optional-label-check

✅ Succeeded
16 seconds
label-check

✅ Succeeded
5 seconds
show-summary


Add --dump-shards to flank android|ios run

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@66a3a77). Click here to learn what that means.
The diff coverage is 23.52%.

@@            Coverage Diff            @@
##             master     #571   +/-   ##
=========================================
  Coverage          ?   78.29%
  Complexity        ?      585
=========================================
  Files             ?       79
  Lines             ?     2175
  Branches          ?      281
=========================================
  Hits              ?     1703
  Misses            ?      287
  Partials          ?      185


All filters in board view are fixed

@sanbornsen fabric8/fabric8-ui:SNAPSHOT-PR-2282-1 is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-2282-fabric8-planner.badger.fabric8.io

@sanbornsen fabric8/fabric8-ui:SNAPSHOT-PR-2282-3 is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-2282-fabric8-planner.badger.fabric8.io

@sanbornsen Can you please tag the issue this PR fixes?

@sanbornsen fabric8/fabric8-ui:SNAPSHOT-PR-2282-4 is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-2282-fabric8-planner.badger.fabric8.io

@sanbornsen fabric8/fabric8-ui:SNAPSHOT-PR-2282-5 is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-2282-fabric8-planner.badger.fabric8.io

@jarifibrahim this PR fixes
https://openshift.io/openshiftio/openshiftio/plan/detail/1561
https://openshift.io/openshiftio/openshiftio/plan/detail/1563

@nimishamukherjee @sanbornsen Does this PR also fixes:

https://openshift.io/openshiftio/openshiftio/plan/detail/1594
https://openshift.io/openshiftio/openshiftio/plan/detail/1595

@sanbornsen said he'll address them as part of this PR itself.

@sanbornsen @nimishamukherjee @rgarg1 Looks like
https://openshift.io/openshiftio/openshiftio/plan/detail/1561
https://openshift.io/openshiftio/openshiftio/plan/detail/1563
https://openshift.io/openshiftio/openshiftio/plan/detail/1567
https://openshift.io/openshiftio/openshiftio/plan/detail/1594
have been fixed.
https://openshift.io/openshiftio/openshiftio/plan/detail/1595 does not appear to be fixed in this PR. The workitems added via quick-add in board view still vanish in requirements/iteration/portfolio context. The filters should be triggered after creating a workitem which doesn't appear to be working.

https://openshift.io/openshiftio/openshiftio/plan/detail/1595

So I will merge this PR and @sanbornsen will raise another PR for 1595.

@sanbornsen fabric8/fabric8-ui:SNAPSHOT-PR-2282-6 is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-2282-fabric8-planner.badger.fabric8.io


Fix RequestProcessor connection reuse with unconsumed requests

Fixes #6924
This removes the skip_to_end call from HTTP::Content#close, which would involuntary consume a large (or infinite) HTTP body.
Instead, the logic is moved to RequestProcessor and it closes the connection if the body is too large (in this case >16kb).
I'm not entirely sure if it should skip any body at all automatically. I'm more leaning towards making this the responsibility of the handler. And the rule would just be if the handler doesn't entirely consume the request body, the connection can't be reused. It's probably fine to leave some leeway, though. That's why I included this into the PR. But we can easily remove it and break if the body contains any data at all.
I'll leave that up for discussion.
The handler can also tell the request processor to close the connection by setting Connection: close header.

I didn't see this PR's diff yet, but I'm now thinking we should change HTTP::Client to be concurrent by default, kind of similar to what Go does.
I found this article
which mentions this stackoverflow question.
In short, it seems that when you create a client, do a request but you don't read the whole response and close it then keep-alive won't be used. But it still works: internally I guess it creates a new socket, connects and performs a separate request. If you then don't read and close the connection I guess it's closed after some time. So I'm pretty sure there's a connection pool going on.
We must do this change. Right now everything's fine if you use the http client in a single fiber, but if you use it in multiple fibers then there's a change that requests are intermixed and this should work by default, it's not good to have to wait for other responses to be read and closed.

Now I read the diff. The change seems fine, except that I'd like HTTP::Client to succeed performing a request even if another request is currently being processed (it's body was not yet consumed). I'm not sure we should merge this because it might break existing code... right? If you perform two consecutive requests and the response body is larger than the maximum skippable size.

@asterite It took my a while to understand why you're mentioning HTTP::Client so much. Might have been me being tired. But yes, this affects client side response consuming as well.

I'm now thinking we should change HTTP::Client to be concurrent by default, kind of similar to what Go does.

That's #6011
We might consider using an auto-consuming IO wrapper for client response.
But I think I'd actually prefer to be strict in both server and client. If the request/response is not entirely consumed, the connection can't be reused. That transfers responsibility for deciding what should be consumed entirely to the user - instead of using some guesswork in the general implementation saying that maybe some amount of unconsumed data could be skipped.

@straight-shoota Right. For me the logic should be:

I make a request and get a response
If I don't consume that response and make another request, that opens another connection (but still works)
If I did consume the response and make another request, reuse the connection using keep-alive

The only problem here is having to eventually close that connection that never consumed the response to avoid leaks.

having to eventually close that connection that never consumed the response to avoid leaks.

This could be implemented in HTTP::Client::Response#close. Users would need to call this method when finished.  If the request body was consumed, the connection is returned to the pool. Otherwise it is simply closed. Yielding methods would automatically take care of this.

I added a commit which removes skipping some minor amount of bytes and instead always closes the connection if the request was not entirely consumed.

Yes, the socket is always closed at the end of the loop in the ensure block. It's a bit convoluted, maybe there could be some more refactoring.

I'll also add docs about this to HTTP::Server::Handler when we're settled on the behaviour.

I like the behaviour, personally.

I've added a section about reusing connections to the API docs of HTTP::Server. I figured this was the right place, because RequestProcessor is entirely undocumented (and should probably be removed #7248) and most of the documentation about behaviour of server handlers was already in HTTP::Server.
See also #7251 for more changes to the existing docs.

Yes, RequestProcessor is just a helper class, it's just public to be able to test it.

Rebased and ready to ship.


Add an AFK timer

Currently on LoA/vacation, did plan on picking this back up, will update PR
next week when I'm back :)

Did some more thinking/research on this - I think what we (I?) really want is /away.
https://bisqwit.iki.fi/jutut/away.html has some good arguments against the pre|AFK 'away nick' @Zarel suggested. I think it would be useful if we added an /away command to toggle an 'away' state for a user (I don't know if we'd want to actually support /away messages, because they could potentially be inappropriate). The server can automatically set /away for a user based on inactivity (this change).
My ideal design:

when a user is /away, their name turns gray and they are sorted to the bottom of the room's user list, but they keep their rank, and clicking on their grayed out name shows a tag/indicator that they are away/AFK.
if the server detects a user as inactive they can set them to the /away state
I can manually set /away on my desktop without waiting for the server to timeout my client
a user can leave the /away state by using the /away command again, or if a user makes a non-passive action (replies publicly in chat, makes an action in battle/starts a challenge etc. simply joining a room or battle as an observer should not alter the away state IMO, neither should something like /help or /dt etc).

I'd want to get some consensus here though, and its a broader change than what you originally envisioned in this PR.

Your link is for IRC, and there's no reason we'd have to carry over the flaws mentioned in that article.
Also, my suggestion of |AFK was purely protocol-level; I definitely don't want it to be a literal name change.
Anyway, your outline matches my vision, except /back is the command to remove the away state, and the away state is set by /away with or without any description.

Gotcha. Works for me! @bumbadadabum - LMK if what I laid out is out of scope for what you were planning to do when you get back (no rush!) and I will take on anything you're not interested in :)

I dread the client work immensely lol. I'll message you on Discord when I
get the time.

It's not out of scope though, sounds like a way more solid thought out idea
than the basically spur of the moment quick and dirty solution I have here
lol.

Talked to pre and this is how we plan to implement the protocol for the away state:
For broadcasting to chatrooms: |a|username when a user is marked as away and |b|username when the user is back. We considered putting this into |n| but that would break the format of that protocol message, which would mess with bots.
When a user joins a room, users marked as away will have a at the end of their username in the|users|part of the|init|message. We thought made the most sense, as it is not allowed in usernames, and using pipes would make the whole message hell to parse. This seemed like the most compact way to indicate people being AFK in this message while retaining backwards compatibility.
Of course, it should also show up on /query userdetails but this uses JSON and would be trivial to add this to.
The final point is whether we show this to users in the top right. My idea for making that work is to change the NAMED field in the |updateuser| to be 0 if a user is a guest, 1 if a user is named, and 2 if a user is away. This still allowed boolean checks for named to work as they did before, while adding an easy way to check whether the user got marked as away without looking at chatrooms.

As for the client side, I think I need to:

change the parsing logic to understand the ` and, and this.users needs to store not just the name string but also away status. I assume we'd want to parse the away state out of the ID as soon as possible, but then we're stuck passing the two together everywhere, like to UserList.add etc. It would make more sense to have a User object to pass around/store in this.users, but I don't think we have the full details for that, just the ID + away bit pair?
observe |a| and |b| in the same way we do joins and leaves (which brings up the question - will we want |A| & |B| along with |a|& |b| and |away| & |back|? How frequent do we expect away to occur?
change the color in constructItem. Ideally I'd be able to add an 'away' class or something similar the the li, but because the color is an inline style it wouldn't apply thanks to cascade rules so I'd need apply it inline as well.

we also need to add something to the id of the li to represent 'away', because we pull it out in the elemComparator

change the comparator logic to sort away users at the bottom (though still staff above regular users etc)

Probably missing some things, but thats my initial guess at what might be required. I'd actually probably update the Preact client at the same time, because the code looks to already be there as well and be pretty much identical.

I don't like |a| and |b|; I think |n| should work fine.
I don't like the ` sigil. | shouldn't require that much parsing complexity.

PS already hardcodes how many pipes to split on, anyway:
https://github.com/Zarel/Pokemon-Showdown-Client/blob/62c01a0216057730acbe4a50d0c48baa6606f52a/src/client-main.ts#L510-L535

But it would 1. Break every ps bot 2. Require you to parse a highly
variable amount of pipes.
Also how exactly do you want it sent in |n|?

PS already requires parsing variable amounts of pipes. I linked to the modern way this is achieved in client.
I would probably make the AFK state the third argument of |n|.

Yes variable per message type. But not an init message containing anything
from 8 to 500 pipes. Also, pipes are used to separate parts of the message,
and this usage is not that. It is used here to add a little identifier to
the end of usernames to signify they're afk, and it seems weird and out of
place to use the same character we used to separate the userlist itself
from the other parts of the init. Confusing to read and confusing to parse.

Ok talked to Zarel, he wants @ to be banned from usernames, and we could use that in the |init| message.

Ok implemented the new protocol.

Travis tests have failed
Hey @bumbadadabum,
Please read the following log in order to understand the failure reason.
It'll be awesome if you fix what's wrong and commit the changes.
TravisBuddy Request Identifier: 1d786d50-5c88-11e9-8db0-bbda51d68b34

More design questions (this is why I tend to prefer design docs...):

Is there a length limit to the STATUS message? I believe we set a limit on user name length, presumably we also want one of the STATUS length (and to make sure our existing checks for NAME length aren't constraining the new NAME@STATUS length incorrectly to the limit for NAME)
Presumably, if we're going to let user's set their STATUS, it's going to be a human readable string like NAME is and not an ID. This PR is currently using '!away' and '!afk' - I think they should probably be '!Away' and '!AFK' (I prefer '!Idle' for the second one, FWIW)

I really didn't want users to set their own status and prefer having a few set ones. Idk about Away vs away in that case. This was all rather just picked arbitrarily so uhh feel free?

I have no strong opinions about users being able/unable to set custom messages. I just wanted to support more states than just away vs not away, hence the spec allowing a string after @. The rest I'll leave up to you guys.

I don't see a strong reason not to allow custom messages, though. We have a chat feature, access to which is gated by locking and chatfilters, so I'd expect status messages to work the same way.

OK. Allowing users to set their custom message is out of scope for this, but we will support it in the future in the protocol. In that case, I think we should:

allow an 18 character status message (same as the 18 character limit on usernames). this makes for a total possible 'name' length of 38 characters (18 characters for the username portion, @, optional ! and 18 characters for the status).
do not allow status messages to begin with !. I don't think this is relevant yet because we don't allow for custom statuses, but when we do I wouldn't want users to need to know about ! at all - in the same place where they can set their status there should be a checkbox/toggle for them to indicate their status is an 'away' status.
other than the ! restriction, statuses should have the exact same characters restrictions on them as username currently does (in essence, its really a second name that you can change arbitrarily while keeping the same identity).

I was originally going to do 'Away' as a tag, but now I think the status should be displayed under the username in the popup (and 'OFFLINE' should just be another auto-status, like 'AFK'). I think the greying of the username (in addition to whatever the status message is) should be sufficient to convey that the user is away.
@bumbadadabum: What I need from you in this PR:

[ ] capitalize 'Away' and 'AFK' so that I can just display whatever the status is directly on the client

[ ] resolution on when /back gets automatically applied. @Zarel, do you have opinions here? For someone who has timed out and been marked 'AFK' automatically I'm OK with almost any command restoring them to active, but I would really like to have on of:

the literal /away command either never be removed until /back is sent
the literal /away command only be removed by a public action (PMs, non-broadcast commands, etc are not public, so would not trigger /back)
a new '/permaway' command (name obviously up for suggestions) which has the behavior proposed for (i) if we don't want to change the behavior of the /away command.

look at this, 3 different list bullet styles! i'm a poweruser! ;)

@Zarel - this should be ready to go now that the client changes are in?

...lol OK good call. Thinking it through more fully, I imagine your plan is to merge the client and let it bake for a bit because of the dependencies between these two PRs and the messiness of attempting to roll both back

I honestly didn't have enough time to code review, but also it's worth testing this with the client changes in, before merging.

I mean, thats how I've been writing the client PR (and why I've gone back and forth with bumba several times on this one). I patch in this server PR and point my client at it and any issues that come up we've been fixing (and then I point my client PR at master when im done and poke around, but clearly not enough because it broke things anyway). I'm more confident about this PR than the client changes, but this definitely wont fly without the client because it would result in pretty bad UX.

Ho @bumbadadabum, sorry for the delay on this! I noticed two things we'll probably want to change in this PR from more extensive client testing:

Leaving (or joining?) should wipe the away state.
Participating in a battle (though not spectating) should wipe the away state.

@scheibo does that look correct?

Definitely the changes around battling look good. I'm not sure about the joinRoom/leaveRoom change - I'd personally like to be able to lurk rooms or spectate battles without returning from away (but obviously I said above that |j| and |l| should trigger these things, which you implemented, so it was my poor spec which is to blame). I think what I intended to capture was when a connection is created/destroyed (I assume thats what happens on a refresh or login/logout)?

Connections being destroyed and created seems rather niche. Most of the time the user in that case is offline or gets a new user object.

Iunno, I don't think the refresh case is that infrequent? I'm not a fan of it being in joinRoom/leaveRoom, so I'd remove it there for sure.
Maybe handling it on connect/disconnect is the wrong approach though, maybe I can just  make the client smarter on refresh so that the UI doesn't look off in that scenario. I'll look into that.

Connections being destroyed is not enough anyway. With the current protocol I do in fact need join or leave to set back, which is really unfortunate. The only way to avoid that requirement would be to extend the join protocol to optionally include the username instead of just user id (so that it could include the @!Away data). This only matters for ! (the away bit), because it changes how we display things in the user list

I could make it set back in User.merge? That would (iirc) cover the refresh case. Removing the join/leaveRoom regardless.

Removing the join/leaveRoom regardless.

I think as we discussed we need to leave it in the join/leave room unless we adjust the protocol for join.

What is the state of this PR? Can it be merged now that the client changes are in?

I suppose so if there's nothing that needs to be changed still.

I heard you talking about room-battle so I'm not surprised there's a conflict there. :p

/home/travis/build/Zarel/Pokemon-Showdown/server/chat-commands.js
  633:18  error  'toId' is not defined  no-undef

$ git grep -l toId | xargs sed -e 's/toId/toID/g' -i ''

So, one actual thing we may have forgotten: @ is both a possible rank symbol and a possible status delimiter. Are we accounting for that?

You can't promote someone without a username to mod can you

Even a user without a name would show up as  @status because first char
of the identity is the rank so I doubt there are potential issues

https://github.com/Zarel/Pokemon-Showdown-Client/blob/bf9c163c52a2586ee4991d2b6fef741edc8eee5d/src/battle-text-parser.ts#L65
Good, it's > 0 here. I can see this tripping up bots if they use >= 0, though.

Are the two places I could find where this breaks.

Some more thoughts:

I think we should be including a way to set non-away statuses as part of this change (/status ?) because it seems inconsistent to allow custom away statuses but not statuses in general. It was one thing if we were using precanned (Away) only, but if we're allowing personalization and given it should be trivial to implement I think we should actually land non-away statuses as well. In both cases the client could be updated to allow setting status (and toggle away) in the UI as opposed to only through a command, but I think that would be more reasonable to land at a later date.

How do we plan to handle abuse (ie. inapprop statuses). With names we can forcerename/namelock, what about statuses? And do we want a status monitor similar to names, etc. Or the ability to prevent users from having a custom status if they abuse it etc. A lot can likely all be repurposed from names, but I think that because we decided to include custom message away statuses as part of this PR, I think we should consider also landing the tooling around their misuse.

How do we plan to handle abuse (ie. inapprop statuses). With names we can forcerename/namelock, what about statuses? And do we want a status monitor similar to names, etc. Or the ability to prevent users from having a custom status if they abuse it etc. A lot can likely all be repurposed from names, but I think that because we decided to include custom message away statuses as part of this PR, I think we should consider also landing the tooling around their misuse.
Why not just disallow anything that isn’t allowed in names? I think that list would suffice ?

Why not just disallow anything that isn’t allowed in names? I think that list would suffice ?

bumba already has this:
awayMessage = Chat.namefilter(target, user);

I was mainly concerned with the other infrastructure for handling cases which skirt the filter

I can clear status when a user is forcerenamed or namelocked. Regarding a
/status command I was going to do a followup at some point but I suppose it
can be added in here as well.

I'll double check and test will let you know

Whoops

This should be ready to ship, but I believe there are some things we will need to do first:

[ ] Make sure the latest client code has been deployed so the statuses display correctly (@Zarel). Can this just be done with the server restart below, or does it need to happen first?
[ ] Merge the code (@Zarel), then reach out to <<botdev>> etc (@bumbadadabum?) to give them a heads up and time to handle the protocol changes. I think we also probably want to disable /hotpatch-ing chat at this time? (@Zarel / @bumbadadabum / etc)
[ ] After N days (hopefully a short time), restart the server (@Zarel?). We probably want to announce the change in 'News' as well, given its fairly large (but its also pretty discoverable given users names are going to start graying out suddenly)

My concern is that we're already closing in on a month of uptime, and waiting for a client push + server push + a grace period for bot developers etc might be unrealistic? If we can push client and server at the same time and are OK with just breaking bots in the short term then maybe that concern isn't important, but otherwise we might be too far gone into this server release to realistically land this.

I already have how I want to deploy this planned out (I've had enough time to think it over) so it's really just waiting for a merge. Was going to disable hotpatching and make an announcement to bot owners.

I like leaving messages for when people get back.

Tests failed? I'll re-run, but it doesn't look like a merge conflict or Travis downtime.


Regression in Hexstring Parsing (Throwing Syntax Error)

When running the following rule in Yara 3.4.0 no error is generated, but it fails to compile in the latest version of Yara (3.5.0)
The rule is here -> https://github.com/mattulm/sfiles_yara/blob/master/malware/RomeoFoxtrot.yara
Commands are posted below
Yara version
$ yara -v
yara 3.4.0

Running the rule
$yara -s RomeoFoxtrot.yar file
$

And with Yara 3.5
$ yara -v
yara 3.5.0

Running the rule
$yara -s RomeoFoxtrot.yar file
RomeoFoxtrot.yar(50): error: invalid hex string "$connect": syntax error, unexpected '|', expecting _BYTE_ or _MASKED_BYTE_ or '(' or '['

Same than #481


Some editing: spaces to Ledger, cleaned up TPS, added modifers to pro…

…jects and some description. Nothing big, just trying to do a little work a bit at a time and get the git workflow down. Also, used mg for this one. Hopefully, it solves the weird space/tab issue emacs was introducing. Let me know.

re: faq.py line #91: Or, each string can be personalized to the exchange.
Might be harder to maintain but I am opening up to the idea of having more specific calls for each dapp/project/etc.
For example: instead of .listing coinbase .listing kraken it would just be .coinbase .kraken.
Another example: .projects ergopad .projects skyharbor .projects azorus it would just be .ergopad .skyharbor .azorus
Pro: easier to remember, good for mobile
Con: could get messy if we need to edit two files faq.py and sigmabot.py...especially if we add modifiers


std::abs() in metrics::imbalance() to account smaller parts in final imbalance value

Without std::abs() parts which smaller than perfect_block_weight gives negative imbalance and so always smaller than any positive max_imbalance.

Hi, I'm not sure whether this is right. We define the imbalance of a partition as the heaviest block weight divided by the average block weight perfect_block_weight (offset by -1), thus blocks that are lighter than the average block weight shouldn't matter.


LoS condition

Sorry i cant merge this, please re-create it cleanly.
It includes a bunch of older commits


[GH-27] Added support for sortlist resolv.conf option.

Description

added Support for sortlist option in resolv.conf.

Released as: 4.2.0


Example

https://github.com/kubescape/github-action/pull/33#issuecomment-1494279001
As GitHub doesn't support making reviews on a content that is not related to that specific PR.

In addition, I just checked and found the error at https://github.com/kubescape/github-action/actions/runs/4596346433/jobs/8118910909 Error: GitHub Actions is not permitted to create or approve pull requests.
So remember to allow GitHub Actions to create and approve pull requests like https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#preventing-github-actions-from-creating-or-approving-pull-requests to get it work. But after all we don't want to see another PR gets opened unless we commit to the main branch directly.

Examples available at my fork:

https://github.com/HollowMan6/github-action/pull/1
https://github.com/HollowMan6/github-action/pull/2

Thanks @HollowMan6 !


Bug when using pagination

Steps to reproduce:

open filters
scroll the the bottom, and click next page
on reload, filters will "re-roll" out, over columns
height is not changed, so it looks very odd
this only happens to filters, and not columns.

Tested on firefox/chromium.

I fixed something related to pagination on latest version.. perhaps this got fixed as well?

Not an issue anymore


RMI documentation

Is there any documentation on setting up the RMI part?

The only documentation I have is located on the github page.
https://github.com/Garrett92/WurmWebRMI
All you need for the map viewer is point 'includes/rmi.php' to the RMI tool.
The default is set to $GLOBALS['RMI_ADDRESS'] = "localhost:8080";

Thanks for the link! It took me a bit of figuring out but I got it working, and I was able to finish that part of the GUI update as well. See PR #4.


Parse outer attributes on StructPatternEtCetera

We do not currently parse the following snippet:
struct Foo { x: u32 }

let Foo { #[cfg(any()) .. ] };

This requires a change in the ungrammar file here https://github.com/rust-analyzer/ungrammar/blob/222f4d2891459e37b358930a0e608fdf5eed6da0/rust.ungram#L611-L615 and then a parsing change here https://github.com/rust-analyzer/rust-analyzer/blob/70fe7a4515ebdc6222a6565cd4cd1c5fd0c77350/crates/parser/src/grammar/patterns.rs#L206

@Veykril don't forget the E-has-instructions tag -- imo, that's the most imapctful one for new contributors

The example should have been let Foo { #[cfg(any())] .. };, right?

Oh ye that was meant to be like that


Uncaught Error: Invalid repo

Hi,
I tried to add utterances for my static github pages blog in this repository: https://github.com/skranz/skranz.github.com. I think I followed all steps described here https://utteranc.es/
When loading the blog the JavaScript console shows the following error:
utterances.1a7a085f.js:1 Uncaught Error: Invalid repo: "https://github.com/skranz/skranz.github.com"
    at $ (utterances.1a7a085f.js:1)
    at utterances.1a7a085f.js:1
    at utterances.1a7a085f.js:1
    at utterances.1a7a085f.js:1

I added the utterance app to my repository (and it is shown there as installed Github app) and included the following generated code in my blog:
  <script src="https://utteranc.es/client.js"
        repo="https://github.com/skranz/skranz.github.com"
        issue-term="title"
        label="utterance"
        theme="github-light"
        crossorigin="anonymous"
        async>
  </script>

Could it perhaps be that the fix https://github.com/utterance/utterances/commit/ef9e9bd4d1613a85999f6b16bc37bb30f7f702e9
does not yet help for repositories with two dots in their name? (I am not so fast in decrypting a regex). Utterance seems like a really great tool. It would great if you have some idea how I could fix this problem.

 I needed to define
repo="skranz/skranz.github.com"
instead of
repo=""https://github.com/skranz/skranz.github.com"
Now it works.


Terraform 0.14 upgrade

what

Upgrade to support Terraform 0.14 and bring up to current Cloud Posse standard

why

Support Terraform 0.14

/test all

/test all

/test all

/test all

@maximmi looks like an issue with codeowners --

@maximmi looks like an issue with codeowners --

/test all


Releases info not correct

See:
https://github.com/Jumpscale/developer/releases
9.0.1, 9.0.2 and 9.0.3 all have the same release notes

That's because I did something wrong with the releases. But 9.0.1 and 9.0.2 are not used.


Completion without LSP

Hi,
thank you for a great plugin :)
I have a question is it possible to set up compe to show completion menu even for files which are not covered by any LSP?
Particularly I have an issue triggering it in .md files.

You can set up to use buffer source completion via following config.
let g:compe = {}
let g:compe.source = {}
let g:compe.source.buffer = v:true

I have that option already enabled :) This is the config I am using.
require'compe'.setup {
  enabled = true;
  autocomplete = true;
  debug = false;
  min_length = 1;
  preselect = 'enable';
  throttle_time = 80;
  source_timeout = 200;
  incomplete_delay = 400;
  max_abbr_width = 100;
  max_kind_width = 100;
  max_menu_width = 100;
  documentation = true;

  source = {
    path = true;
    buffer = true;
    calc = true;
    vsnip = true;
    nvim_lsp = true;
    nvim_lua = false;
    spell = true;
    tags = true;
    snippets_nvim = false;
    treesitter = true;
    omni = true;
  };
}

Also tried setting up setl omnifunc=v:lua.vim.lsp.omnifunc.

@JoeyGrajciar And what is it exactly that doesn't work for you? I have compe working in every single buffer, regardless to whether LSP is attached to it or not.

Your config seems to correct to me.
Don't you get the buffer completion with your config?

@cloggier @hrsh7th The issue is I don't get any completion currently. Default  completion works.

you are invoking omnifunc manually, right?
If so, compe will do nothing.
You should invoke compe#complete instead of omnifunc(<C-x><C-o>)

inoremap <silent><expr> <C-x><C-o> compe#complete() will be done as you expected.

So I guess I found the issue :) In config I have treesitter = true, but I do not have nvim-treesitter installed so that was probably breaking the chain :)
inoremap <silent><expr> <C-x><C-o> compe#complete() uncovered the issue.


Tag VXL release, and match with ITK

Update VXL tag to 2.0.1 for requirement in ITK, and create a 2.0.1 release of VXL so that we can capture the requirements.
VXL should have a tag generated once all the ITK builds verify that the feature set is complete without compiler warnings for VNL.

This is completed.


bugfix: 修复单个进程实例下发配置时一直提示需要生成新版本的问题 (fixed #121)

Codecov Report

Merging #125 (fd71ea6) into v1.0.9-rc (5661aae) will not change coverage.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           v1.0.9-rc     #125   +/-   ##
==========================================
  Coverage      53.77%   53.77%
==========================================
  Files            180      180
  Lines           8731     8731
==========================================
  Hits            4695     4695
  Misses          4036     4036

Impacted Files
Coverage Δ

apps/gsekit/configfile/handlers/config_instance.py
17.85% <0.00%> (ø)

apps/gsekit/configfile/views/config_instance.py
44.00% <ø> (ø)

Continue to review full report at Codecov.

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


Can you put the complete training code of ESRGAN in this repo? BasicSR is too complex and not very friendly for beginners

Can you put the complete training code of ESRGAN in this repo? BasicSR is too complex and not very friendly for beginners

True the BasicSR code is very complex and I have tried to train the ESRGAN model for 2x but the model takes 4x RDDBNet architecture and shows error.

did you trained the model for 2x or 4x @shashikantdeepak


chore:fixing sign-in and removed jwt logs

when the user's logs in. After referesh it's logs out. This or corrects this.

Not able to work on Arc browser limitations(will have to fix it soon), @Aditya-eddy if you could attach a video that would be great


chore(deps): upgrade dependencies

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade" workflow

@dependabot rebase


How to make the popup display below the target control

Great component.  When using it near the edge of a display area (e.g. on a popup window) having it popup above the target control causes it to be hidden.  Is there any way we can control the popup direction relative to the target control as you can with the bootstrap Tooltip (https://getbootstrap.com/docs/3.3/javascript/#tooltips-examples) ?
Thanks

Thanks for the reply.  Yes I have tried that.  Example usage:
{{ editCtrl.sourceValue || "empty" }}

The tag has no effect.

That doesn't look right.
Which popover are you trying to use?
Editable Popover
or
Bootstrap UI Popover
Using the Boostrap UI Popover, adding the popover-placement works for me

    {{ user.name || 'empty' }}

I am using the Editable popover which is working in every way but does not respond to popover-placement.  I will investigate further.


Add Value Substitution via Function

Description
it would be helpful, if one can
substitute value, via "Function Calls"

feature will be implemented in  138


Compile Error with CUDA 12.6.1 due to NVTX

First off, thanks for the implementation! I think this is awesome work.
Using ArchLinux on a RTX 4060 (for now)
CUDA version 12.6.1
Code compiles without error on CUDA 12.5.1
Modifying Makefile to remove (undefine) -DUSE_NVTXsolves the compile issue for now, but the compile errors appear to result from competing NVTX versions, and should be fixed? Not sure.
$ make
rm -rf bin
mkdir -p bin
nvcc -c -arch=native -m64 -O3 -rdc=true -lnvToolsExt src/commons/functions.cu -o bin/functions.o
nvcc -Xcompiler="-fopenmp -DUSE_NVTX" -arch=native -m64 -O3 -rdc=true -lnvToolsExt bin/functions.o src/main.cu -o bin/main.bin
In file included from src/commons/common.cuh:9,
                 from src/main.cu:7:
/opt/cuda/bin/../targets/x86_64-linux/include/nvToolsExt.h:187: warning: "NVTX_DECLSPEC" redefined
  187 |     #define NVTX_DECLSPEC
      |
In file included from /opt/cuda/targets/x86_64-linux/include/cub/detail/nvtx3.hpp:635,
                 from /opt/cuda/bin/../targets/x86_64-linux/include/cub/detail/nvtx.cuh:49,
                 from /opt/cuda/bin/../targets/x86_64-linux/include/cub/device/device_adjacent_difference.cuh:41,
                 from /opt/cuda/bin/../targets/x86_64-linux/include/cub/cub.cuh:62,
                 from src/main.cu:4:
/opt/cuda/bin/../targets/x86_64-linux/include/nvtx3/nvToolsExt.h:207: note: this is the location of the previous definition
  207 | #define NVTX_DECLSPEC NVTX_INLINE_STATIC
      |
/opt/cuda/bin/../targets/x86_64-linux/include/nvToolsExt.h:223: warning: "NVTX_VERSION" redefined
  223 | #define NVTX_VERSION 2
      |
/opt/cuda/bin/../targets/x86_64-linux/include/nvtx3/nvToolsExt.h:184: note: this is the location of the previous definition
  184 | #define NVTX_VERSION 3
      |
/opt/cuda/bin/../targets/x86_64-linux/include/nvToolsExt.h(248): error: invalid redeclaration of type name "nvtxStringHandle_t" (declared at line 292 of /opt/cuda/bin/../targets/x86_64-linux/include/nvtx3/nvToolsExt.h)
  typedef struct nvtxStringHandle* nvtxStringHandle_t;
                                   ^

/opt/cuda/bin/../targets/x86_64-linux/include/nvToolsExt.h(258): error: invalid redeclaration of type name "nvtxDomainHandle_t" (declared at line 278 of /opt/cuda/bin/../targets/x86_64-linux/include/nvtx3/nvToolsExt.h)
  typedef struct nvtxDomainHandle* nvtxDomainHandle_t;
                                   ^

/opt/cuda/bin/../targets/x86_64-linux/include/nvToolsExt.h(273): error: enum "nvtxColorType_t" has already been defined (previous definition at line 302 of /opt/cuda/bin/../targets/x86_64-linux/include/nvtx3/nvToolsExt.h)
  typedef enum nvtxColorType_t
               ^

/opt/cuda/bin/../targets/x86_64-linux/include/nvToolsExt.h(275): error: "NVTX_COLOR_UNKNOWN" has already been declared in the current scope
      NVTX_COLOR_UNKNOWN = 0,
      ^

/opt/cuda/bin/../targets/x86_64-linux/include/nvToolsExt.h(276): error: "NVTX_COLOR_ARGB" has already been declared in the current scope
      NVTX_COLOR_ARGB = 1
      ^

/opt/cuda/bin/../targets/x86_64-linux/include/nvToolsExt.h(277): error: invalid redeclaration of type name "nvtxColorType_t" (declared at line 306 of /opt/cuda/bin/../targets/x86_64-linux/include/nvtx3/nvToolsExt.h)
  } nvtxColorType_t;
    ^

/opt/cuda/bin/../targets/x86_64-linux/include/nvToolsExt.h(282): error: enum "nvtxMessageType_t" has already been defined (previous definition at line 311 of /opt/cuda/bin/../targets/x86_64-linux/include/nvtx3/nvToolsExt.h)
  typedef enum nvtxMessageType_t
               ^

/opt/cuda/bin/../targets/x86_64-linux/include/nvToolsExt.h(284): error: "NVTX_MESSAGE_UNKNOWN" has already been declared in the current scope
      NVTX_MESSAGE_UNKNOWN = 0,
      ^

/opt/cuda/bin/../targets/x86_64-linux/include/nvToolsExt.h(285): error: "NVTX_MESSAGE_TYPE_ASCII" has already been declared in the current scope
      NVTX_MESSAGE_TYPE_ASCII = 1,
      ^

/opt/cuda/bin/../targets/x86_64-linux/include/nvToolsExt.h(286): error: "NVTX_MESSAGE_TYPE_UNICODE" has already been declared in the current scope
      NVTX_MESSAGE_TYPE_UNICODE = 2,
      ^

/opt/cuda/bin/../targets/x86_64-linux/include/nvToolsExt.h(288): error: "NVTX_MESSAGE_TYPE_REGISTERED" has already been declared in the current scope
      NVTX_MESSAGE_TYPE_REGISTERED = 3
      ^

/opt/cuda/bin/../targets/x86_64-linux/include/nvToolsExt.h(291): error: invalid redeclaration of type name "nvtxMessageType_t" (declared at line 320 of /opt/cuda/bin/../targets/x86_64-linux/include/nvtx3/nvToolsExt.h)
  } nvtxMessageType_t;
    ^

/opt/cuda/bin/../targets/x86_64-linux/include/nvToolsExt.h(293): error: type "nvtxMessageValue_t" has already been defined (previous definition at line 328 of /opt/cuda/bin/../targets/x86_64-linux/include/nvtx3/nvToolsExt.h)
  typedef union nvtxMessageValue_t
                ^

/opt/cuda/bin/../targets/x86_64-linux/include/nvToolsExt.h(481): error: enum "nvtxPayloadType_t" has already been defined (previous definition at line 368 of /opt/cuda/bin/../targets/x86_64-linux/include/nvtx3/nvToolsExt.h)
  typedef enum nvtxPayloadType_t
               ^

/opt/cuda/bin/../targets/x86_64-linux/include/nvToolsExt.h(483): error: "NVTX_PAYLOAD_UNKNOWN" has already been declared in the current scope
      NVTX_PAYLOAD_UNKNOWN = 0,
      ^

/opt/cuda/bin/../targets/x86_64-linux/include/nvToolsExt.h(484): error: "NVTX_PAYLOAD_TYPE_UNSIGNED_INT64" has already been declared in the current scope
      NVTX_PAYLOAD_TYPE_UNSIGNED_INT64 = 1,
      ^

/opt/cuda/bin/../targets/x86_64-linux/include/nvToolsExt.h(485): error: "NVTX_PAYLOAD_TYPE_INT64" has already been declared in the current scope
      NVTX_PAYLOAD_TYPE_INT64 = 2,
      ^

/opt/cuda/bin/../targets/x86_64-linux/include/nvToolsExt.h(486): error: "NVTX_PAYLOAD_TYPE_DOUBLE" has already been declared in the current scope
      NVTX_PAYLOAD_TYPE_DOUBLE = 3,
      ^

/opt/cuda/bin/../targets/x86_64-linux/include/nvToolsExt.h(488): error: "NVTX_PAYLOAD_TYPE_UNSIGNED_INT32" has already been declared in the current scope
      NVTX_PAYLOAD_TYPE_UNSIGNED_INT32 = 4,
      ^

/opt/cuda/bin/../targets/x86_64-linux/include/nvToolsExt.h(489): error: "NVTX_PAYLOAD_TYPE_INT32" has already been declared in the current scope
      NVTX_PAYLOAD_TYPE_INT32 = 5,
      ^

/opt/cuda/bin/../targets/x86_64-linux/include/nvToolsExt.h(490): error: "NVTX_PAYLOAD_TYPE_FLOAT" has already been declared in the current scope
      NVTX_PAYLOAD_TYPE_FLOAT = 6
      ^

/opt/cuda/bin/../targets/x86_64-linux/include/nvToolsExt.h(491): error: invalid redeclaration of type name "nvtxPayloadType_t" (declared at line 378 of /opt/cuda/bin/../targets/x86_64-linux/include/nvtx3/nvToolsExt.h)
  } nvtxPayloadType_t;
    ^

/opt/cuda/bin/../targets/x86_64-linux/include/nvToolsExt.h(570): error: type "nvtxEventAttributes_v2" has already been defined (previous definition at line 548 of /opt/cuda/bin/../targets/x86_64-linux/include/nvtx3/nvToolsExt.h)
  typedef struct nvtxEventAttributes_v2
                 ^

/opt/cuda/bin/../targets/x86_64-linux/include/nvToolsExt.h(663): error: type "nvtxEventAttributes_t" has already been defined (previous definition at line 550 of /opt/cuda/bin/../targets/x86_64-linux/include/nvtx3/nvToolsExt.h)
  typedef struct nvtxEventAttributes_v2 nvtxEventAttributes_t;
                                        ^

/opt/cuda/bin/../targets/x86_64-linux/include/nvToolsExt.h(1091): error: enum "nvtxResourceGenericType_t" has already been defined (previous definition at line 978 of /opt/cuda/bin/../targets/x86_64-linux/include/nvtx3/nvToolsExt.h)
  typedef enum nvtxResourceGenericType_t
               ^

/opt/cuda/bin/../targets/x86_64-linux/include/nvToolsExt.h(1093): error: "NVTX_RESOURCE_TYPE_UNKNOWN" has already been declared in the current scope
      NVTX_RESOURCE_TYPE_UNKNOWN = 0,
      ^

/opt/cuda/bin/../targets/x86_64-linux/include/nvToolsExt.h(1094): error: "NVTX_RESOURCE_TYPE_GENERIC_POINTER" has already been declared in the current scope
      NVTX_RESOURCE_TYPE_GENERIC_POINTER = ((((uint32_t)(1))<<16)|((uint32_t)(1))),
      ^

/opt/cuda/bin/../targets/x86_64-linux/include/nvToolsExt.h(1095): error: "NVTX_RESOURCE_TYPE_GENERIC_HANDLE" has already been declared in the current scope
      NVTX_RESOURCE_TYPE_GENERIC_HANDLE = ((((uint32_t)(1))<<16)|((uint32_t)(2))),
      ^

/opt/cuda/bin/../targets/x86_64-linux/include/nvToolsExt.h(1096): error: "NVTX_RESOURCE_TYPE_GENERIC_THREAD_NATIVE" has already been declared in the current scope
      NVTX_RESOURCE_TYPE_GENERIC_THREAD_NATIVE = ((((uint32_t)(1))<<16)|((uint32_t)(3))),
      ^

/opt/cuda/bin/../targets/x86_64-linux/include/nvToolsExt.h(1097): error: "NVTX_RESOURCE_TYPE_GENERIC_THREAD_POSIX" has already been declared in the current scope
      NVTX_RESOURCE_TYPE_GENERIC_THREAD_POSIX = ((((uint32_t)(1))<<16)|((uint32_t)(4)))
      ^

/opt/cuda/bin/../targets/x86_64-linux/include/nvToolsExt.h(1098): error: invalid redeclaration of type name "nvtxResourceGenericType_t" (declared at line 985 of /opt/cuda/bin/../targets/x86_64-linux/include/nvtx3/nvToolsExt.h)
  } nvtxResourceGenericType_t;
    ^

/opt/cuda/bin/../targets/x86_64-linux/include/nvToolsExt.h(1177): error: type "nvtxResourceAttributes_v0" has already been defined (previous definition at line 1121 of /opt/cuda/bin/../targets/x86_64-linux/include/nvtx3/nvToolsExt.h)
  typedef struct nvtxResourceAttributes_v0
                 ^

/opt/cuda/bin/../targets/x86_64-linux/include/nvToolsExt.h(1236): error: type "nvtxResourceAttributes_t" has already been defined (previous definition at line 1123 of /opt/cuda/bin/../targets/x86_64-linux/include/nvtx3/nvToolsExt.h)
  typedef struct nvtxResourceAttributes_v0 nvtxResourceAttributes_t;
                                           ^

/opt/cuda/bin/../targets/x86_64-linux/include/nvToolsExt.h(1502): error: cannot overload functions distinguished by return type alone
   nvtxDomainHandle_t nvtxDomainCreateA(const char* name);
                      ^

/opt/cuda/bin/../targets/x86_64-linux/include/nvToolsExt.h(1503): error: cannot overload functions distinguished by return type alone
   nvtxDomainHandle_t nvtxDomainCreateW(const wchar_t* name);
                      ^

35 errors detected in the compilation of "src/main.cu".
make: *** [Makefile:21: bin/main.bin] Error 2

I updated the inclusion of the header to NVTX3. This should solve the issue.

Issue has been fixed.


Publish Signed Standalone Executables from archetype-tool-dotnet

I didn't have a very good way to pipe the targeted dll etc through to the net-release template that includes signing.
After waffling and coming up with automation that had varying levels of overcomplication, I'm going to go with the following.

Binaries are published separately not in packages
We are actually publishing a binary. @weshaggard originally I was a bit leery of this but I spent some more time this afternoon and I'm pretty confident that we can do the single file publish as long as we don't do any trimming. The only place that was critically broken is fixed in this PR.
If a standalone executable matrix is defined and ReleaseBinaries parameter is set to true, the executables will be signed as appropriate for the platform and attached to the github release!

/azp run tools - test-proxy - ci

I cancelled the internal build. No reason for auto-trigger when I've already tested on manual run.

That identity-resolution error is merely an error because we are publicizing an issue that has already been present. It has not been properly producing artifacts.
If you go back into history, the Sign and Publish step has been failing repeatedly because we don't actually produce a package from it.
Along those lines, I think it's actually wrong that we've been allowing this to skate by with no error, so I'm going to check-enforcer override and merge with the error on this pipeline. It should be fixed in that project itself.

/check-enforcer override

The APIView failure is a common one already on the pipeline. Nothing to do with this change I don't think. I'm going to squash and merge.


Use short link for german matrix room

Use short link for consistency as suggested by @jbelien in #376 .

Thank you @duncanturk 👍


Run Pkg.update on Manifest.toml files before PR

When a package repository tracks in test/Manifest.toml, docs/Manifest.toml, benchmark/Manifest.toml, etc., those files must be updated for the CI to run against newly available upstream packages.  It would be great if CompatHelper.jl can automate this workflow as well.  Is it in the scope of CompatHelper.jl?

I’m not 100% sure I understand why this is necessary.
Why not check in test/Project.toml instead of test/Manifest.toml, docs/Project.toml instead of docs/Manifest.toml, and benchmark/Project.toml instead of benchmark/Manifest.toml.
And then, in those Project.toml files, either don’t have any compat entries, or if you do have compat entries, make them of the form >= x.y.z.
Then the test, docs, benchmark projects will automatically use the latest versions of their dependencies.
The only reason that the CompatHelper.jl bot is necessary is because we strongly recommend having upper-bounded compat entries in your package’s main Project.toml file. We don’t have a similar recommendation for the test, docs, benchmark projects, so I don’t think you needed upper-bounded compat entries in those projects.

You need to check in subproject manifests {test,docs,benchmark}/Manifest.toml if

you are using non-registered packages as dependencies
you want reproducible test, documentation build, and benchmarks

OK, technically, I can write a build script for each subproject to achieve those goals.  But it'd be great if I don't have to re-implement what Pkg already does.

I guess this is doable. CompatHelper would cd into the docs folder and run julia --project -e 'import Pkg; Pkg.instantiate(); Pkg.update()'. And then repeat that for all of the folders.
You would provide a vector ["test", "docs", "benchmark"] to let me know which projects you want me to update.

That sounds great.  Or maybe even add another API CompatHelper.main(precommit_hook) so that I can just do
run: |-
  julia -e '
  using CompatHelper
  CompatHelper.main() do
      run(`julia --project=test -e 'import Pkg; Pkg.instantiate(); Pkg.update()'`)
      run(`julia --project=docs -e 'import Pkg; Pkg.instantiate(); Pkg.update()'`)
  end
  '

and you can avoid dealing with similar feature requests?

Not a terrible idea

@tkf Can you try the feature out? You'll need to use the da/precommit_hook branch.
So you'd have to change the Pkg.add step in your .github/workflows/CompatHelper.yml file to something like this:
julia -e 'using Pkg; Pkg.add(Pkg.PackageSpec(name = "CompatHelper", url = "https://github.com/bcbi/CompatHelper.jl.git", rev = "da/precommit_hook"))'

@tkf It would be great to add a section to the README documenting the precommit_hook feature. Would you be willing to write up a brief explanation, along with the example YAML snippet? And make a PR?

I'll send a PR :+1:


Strange LspStop arguments, not matching doc

LspStop only working like:
:LspStop (1)

putting id between parenthesis.

in my test LspStop 1 or LspStop lua_ls both works.

in my test LspStop 1 or LspStop lua_ls both works.

Maybe stopping all servers.

it also works fine. so what's your problem ? did you try the min config ?

it also works fine. so what's your problem ? did you try the min config ?

Reading the old code only server name with parent is accepted:
    if v:find '%(' then
      server_name = v
    end

and get_clients_from_cmd_args only accepts ids:
    for _, client in ipairs(get_clients_from_cmd_args(server_name)) do
      client.stop(force)
    end

then only :LspStop (1) works

in my test LspStop 1 or LspStop lua_ls both works.

stop all servers because of
  if vim.tbl_isempty(result) then
    return require('lspconfig.util').get_managed_clients()
  end

code inside get_clients_from_cmd_args function

right i got your point.

squash commit and change the commit message like title then force push will better.

Done :-)


FIX: Property "float" must be followed by a ':'

I'm following your course and using SASS stylesheets and webpack-dev-server for my live reloading needs. The module build fails with the : missing.
Module build failed:
    float left;
   ^
      Property "float" must be followed by a ':'
      in /Sandbox/flashcard-app/src/styles.scss (line 107, column 5)

already exists a pending pull request for the same thing


fix(calavera): Remove sass and styleint from commonjs

Remove sass and stylelint entries from commonjs bundle. This now only adds babeljs
Fix #27

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Refactor find_app_id in ZendeskAppsTools::Deploy

:v:
/cc @zendesk/vegemite
Description
While working on a sprint task, I came across some ruby code that doesn't look great. Thought I'd clean it up abit before working on that sprint task. This change follows the Ruby Style Guide.
Prior to the refactoring, I created a test for the code that is to be refactored. Then made sure that the test passes after refactoring
Tasks

Write Test for method

Refactor method

Run test for new method

Explicitly declare external dependencies (modules)

Implementation Notes

Better way to write .empty? condition

  response_json = ""

  app_json =  response_json.empty? ? nil : 'method_name' <--(!!!)

  app_json = 'method_name' unless response_json.empty? <---(Better way)

  (because app_json will be nil otherwise anyway)

get_connection was extracted into a private method, and then converted into alias_method

References

StackExchange: Why write tests for code that I will refactor?
Alias Method
Original PR
 Ruby Style Guide

Risks

[low] Refactored method by first creating the test, then refactor code to pass test.

See minor comments, otherwise 👍


Pipeline() constructor needs parameters for loading models/weights from local filesystem

I'm trying to use Keras_ocr in an environment that does not permit outbound traffic to external web sites. The default Pipeline initialization ("pipeline = keras_ocr.pipeline.Pipeline()") fails with an access forbidden error. Can it be made possible to specify local files containing the pre-trained models and weights? Thank you.

As a workaround, I have found you can set the environment variable KERAS_OCR_CACHE_DIR to be where you hold the local files.


Type annotations for "struct of arrays" ?

I love equinox and jaxtyping and would like to figure out a nice way to annotate stacked or batched eqx.Modules but so far I've failed. For example, I'll often do something like the following:
class SE3(eqx.Module):
    U: Float[Array, "3 3"]
    t: Float[Array, "3"]

# probably wouldn't construct this in this way but it gets the point across
batched_elements = jtu.map(lambda *v: jnp.stack(v), *[SE3(jnp.eye(3), jnp.zeros(3)) for _ in range(10)])

# ridiculous function but also useful to get the point across!
def sum_translations(batch: ???):
    return vmap(lambda F: F.t)(batch).sum()

sum_translations(batched_elements)

Is there a reasonable type annotation for batch above? I would love to be able to say something like SE3["n"], possibly by modifying the SE3 class.
Thanks so much,
Nick
p.s. I think there's a chance this is related to https://github.com/patrick-kidger/jaxtyping/issues/84 but I have to admit I don't understand python well enough to figure this out!

I don't think we have a way to annotate that at the moment!
FWIW the following is allowable:
Foo = Float[Array, "foo"]
BatchFoo = Float[Foo, "batch"]

and in this case the shapes are concatenated so that this is equivalent to BatchFoo = Float[Array, "batch foo"].
Maybe we should extend this to allow you to write BatchSE3 = Shaped[SE3, "batch"]? Basically by having the jaxtyping logic for the array part of dtype[array, shape] also accept PyTrees-of-arrays, and have it automatically distributed the Shaped[..., "batch"] call over such a PyTree.
I'd be happy to take a PR on that over in jaxtyping! :)