spm with latest version(1.0.1) generated Package.swift looks not correct

by given:
 spm(swiftToolVersion = "5.9") {
        iOS { v("14") }
        macOS { v("13") }
    }

expect:
// swift-tools-version:5.9
import PackageDescription

let packageName = "shared"

let package = Package(
    name: packageName,
    platforms: [
         .iOS(.v14),
         .macOS(.v13)
    ],
    products: [
        .library(
            name: packageName,
            targets: [packageName]
        ),
    ],
    targets: [
        .binaryTarget(
            name: packageName,
            path: "./shared/build/XCFrameworks/debug/\(packageName).xcframework"
        )
        ,
    ]
)

but generated
// swift-tools-version:5.9
import PackageDescription

let packageName = "shared"

let package = Package(
    name: packageName,
    platforms: [
         .macOS(.v13)
    ],
    products: [
        .library(
            name: packageName,
            targets: [packageName]
        ),
    ],
    targets: [
        .binaryTarget(
            name: packageName,
            path: "./shared/build/XCFrameworks/debug/\(packageName).xcframework"
        )
        ,
    ]
)

The logic that builds the Package.swift file checks the apple platforms you've defined for spm against the Kotlin target architectures you've defined. If you have an spm platform definition, but your build isn't actually building for that platform, it isn't written to your Package.swift file.
For example, if your Kotlin gradle config looks like this:
kotlin {
    listOf(
        iosX64(),
        iosArm64(),
        iosSimulatorArm64(),
        macosArm64()
    ).forEach {
        it.binaries.framework {
            isStatic = true
        }
    }
}

kmmbridge {
    gitHubReleaseArtifacts()
    spm(swiftToolVersion = "5.8") {
        iOS { v("14") }
        macOS { v("13") }
    }
}

The relevant part of the Package.swift file will look like this:
let package = Package(
    name: packageName,
    platforms: [
        .iOS(.v14),
        .macOS(.v13)
    ],
    products: [
// Etc

If you remove macosArm64() it'll result in this:
let package = Package(
    name: packageName,
    platforms: [
        .iOS(.v14)
    ],
    products: [
// Etc

It might be confusing, but not an unreasonable solution to the question of what to do in that case. The choices would be:

Ignore it and write whatever's in the Gradle config
Throw an error and fail the build
Filter declared spm targets against the Kotlin architecture targets that are actually being used (which is what it does now)

I don't have a strong feeling either way, TBH. What I don't know is if there are potential downsides for declaring a platform that your framework doesn't actually implement. I don't know if it'll cause build issues, but it is kind of odd to declare it if it isn't supported.

Yes, it can be a bit confusing due to the way SPM depends on Kotlin targets. For instance, when we have a single target like iosX64, alongside iOS and macOS targets in the SPM configuration, it becomes confusing. What if SPM were independent of Kotlin targets? This way, it would always generate the same Package.swift from its configurations.

when we have a single target like iosX64, alongside iOS and macOS targets in the SPM configuration, it becomes confusing.

I don't at all understand the scenario you're suggesting.
I'm going to close both this and the PR for now. This isn't a bug. We are possibly doing some more significant updates in the near future and maybe this part will get some thought, but I'm not entirely sold on the idea that we should declare platform targets in the Package.swift file for platforms we aren't actually exporting. At the same time, I don't know if it's a problem either way.
I can see the argument that there's not much value to filtering the targets. Just print what's declared. However, we'll give it some thought for 1.1.

thx i see your point.


upgrade version + improved install script

added gnmic version upgrade command
removed hardcoded strings in the installation script and made --use-pkg flag that will be able to fetch the package and install it instead of using tar.gz archive

close #151

will add docs


Query Processing Resiliency

To make our query processing pipeline resilient to failures (like server slowness, crashes, etc), we can make some improvements in the broker and server components. I am working on a doc to identify and expand these issues with design and implementation details. The identified improvements are called out below:
Server Selection
When a  broker receives a query, it identifies the list of servers for each segment associated with the query. Among these identified servers, one server per segment is chosen based on a round-robin approach. This approach is light-weight and works for most cases. However, we can add some intelligence to this layer to pick servers more intelligently. Some of the parameters that we could use are:

Server Latency
Number of inflight queries to server
Query cost
Server Load
Server capability (heterogeneous servers).

Fairness in Query Scheduling (Resource isolation)
Currently, there’s no scheduling of queries either at broker or server based on weight of the query or priority assigned to a query. We can introduce a fair scheduling scheme at the broker and server level. Note that we have a PriorityScheduler that schedules queries based on priority but hasn’t been tested. We could improve/test it before working on alternatives.
For example: consider three classes of queries:
C1: high cost queries.
C2: medium cost queries
C3: low cost queries
Broker
Let's say broker receives 3 C1 queries, 3 C2 queries and 3 C3 queries. Now, say there are three available servers that can process these 9 queries that we received. We should ideally be distributing them to the servers as follows:
Server 1 = {1 C1, 1 C2, 1 C3}
Server 2 = {1 C1, 1 C2, 1 C3}
Server 3 = {1 C1, 1 C2, 1 C3}
This heavily overlaps with the “SERVER SELECTION” Section (1) of the document. But adding it as a separate topic because this could be done at each "Server" as opposed to "SERVER SELECTION" which would be done at the broker.
Query Pre-emption at Broker and Server
Currently, the broker pre-empts a query when the timeout is reached.
Our pre-emption logic can be extended to both broker and servers to pre-empt based on a number of factors including

Timeout
Broker currently has logic to return queries that have reached timeout. However, this can be improved at the server
Memory consumption - to avoid out-of-memory errors
This could be a long-pole item because java (AFAIK) does not provide a reliable way of measuring heap usage.

Rate Limiting
Today, queries are rate-limited only based on QPS. We should improve rate-limiting to be based on a number of factors like load on server, latency, etc. Rate-limiting (QoS queue) can be done either at broker or server or both.
Server Circuit Breaker
We should take servers out of rotation (and adaptively bring them back) when servers are failing (n/w partitioned, disk failure, connectivity failures). We currently have a framework built for this in #8490. But we could improve this by adding more trigger points for marking a server unhealthy.

cc: @siddharthteotia  @Jackie-Jiang @jasperjiaguo

@vvivekiyer  has code changes / prototype in progress along with adding those concrete details to the design doc for server selection. Will share for review soon

The plan is to address each section one by one.
As the first step, I've expanded the "Server Selection" section with a focus on two parameters - "Server Latency" and "Number of inflight queries". Here is the design doc - https://docs.google.com/document/d/1w8YVpKIj0S62NvwDpf1HgruwxJYJ6ODuKQLjGXupH8w/edit?usp=sharing
Please review.

@Jackie-Jiang  please review the design doc above.

Some thoughts.
The broker could keep track of a "health score" for serves and rank them. The score could include a variety of dimensions like:

How much thread cpu the server has used up in the last N time units?
What has been the response time of the server for the last M queries (perhaps normalized to the thread cpu used?)
maybe others as well

The servers could also send a score of their own along with each response to the brokers after monitoring their current health. The brokers could include that information in deciding the "weight" of the server for inclusion in a query.
We will need to ensure that the thing does not oscillate wildly, with all brokers backing off for the same server, and then all of them subjecting the server to an onslaught thinking that it is lightly loaded.

Thanks for putting this together. It's very detailed and well explained.
What I am not sure if there is a need for this in Pinot in a real life use case.
Traditionally, these strategies work well for task distribution where a task can be executed on any of the worker nodes and there is a huge variance among the task.. something like one task taking 10 minutes vs 1 minute vs hour etc.note that I explicitly left out millisecond and second because when a task takes such a small amount of time, the feedback loop needs to be really fast.
In case of Pinot, we don't really have a lot of choice since each segment is already assigned to a set of nodes mostly 3 for fault tolerance. There is not much, we can do given that we just have 3 options for a given segment.
It will be great to see a real life example where we could have either seen better latency or throughput based because of this change..

We have seen the following repeatedly in production:

A server slows down:
--  because the queries already running there are taking up huge cpu / GC /
-- or the server indeed happens to be running a lot of  expensive queries
-- or something else is going on the server that is hogging cpu.
-- In one of the cases queries were simply waiting in schedQueue and BPF profiler was taking up CPU
-- Basically latencies observed from a server are spiking

We mitigated this by disabling / enabling instance temporarily and forcing the broker to route queries to other replicas. Helped recover latency spikes that were coming from the slow server. This has happened so many times during oncall etc and almost always we circle back to the fact that "if there was single node/server resiliency, some of the thing could have been avoided or may be there were fewer alerts, latency spikes could have been less worse"
We have also seen the following (this is the 2nd sub-problem outlined in the issue)

A slow query on the server takes up CPU and compromises the other queued up queries that could have finished faster.
Eventually all queries (whether expensive or inexpensive) take up a lot of time.
There is no work stealing or scheduling -- there is no way to forestall a query based on priority / weight and "make slow queries run slower by scheduling them late / giving them few cores" and reduce the cascading impact of expensive queries on other queries.

@vvivekiyer -  please add other notes on the background of problem from the concrete production examples.
The current design doc addresses the first problem as of now and we have a code / impl in progress that we are planning to test this week and also share the PR / discuss feedback etc on the approach.
PS - @vvivekiyer  and I had sync'd up with @Jackie-Jiang  sometime back to tell we are working on it.

@siddharthteotia I added some comments to the design doc. Overall, I feel that the design has some assumptions that having this will result in better latency for the end-user. But the data is missing to back up the assumptions.
I don't remember seeing this problem at LinkedIn. Things might have changed but my concerns expressed in the previous comment still remain the same. I am having a hard time thinking about the practical scenario's where this will be useful.
It will really help if we can see some real production graphs where we can clearly see that this solution will be applicable.

@kishoreg  Thanks for the comments. I'll respond to the comments in the doc.
I just want to reiterate the following - the motivation of this project is to NOT improve latency for users (at least when everything is working fine). It is to improve resiliency so that when some servers are affected, users don't see major degradation in performance.

+1 on what @vvivekiyer mentioned.
I discussed this offline with @kishoreg . I think Kishore thought that proposed design for the server selection problem and the WIP PR are sort of set in stone. That is not the case. We are testing and validating the approach and nothing is going to get merged unless we get confidence in the implementation and get validation before v/s after on a workload that reproduces the problem.
Having said that, the WIP PR is deployed on our internal perf cluster with prod data and we are running validation, gathering data points etc. So, will be sharing all of that.
Things are still up for discussion and brainstorming.

Update on server selection subproblem -- By next week, we will share some of our results from the POC code we had written, improved and been testing on internal perf cluster and tested out a couple of prod use cases.
Along with that we have also written a simulator in Python to model several different scenarios in theory and cross validated that with the new Pinot server selector code
Will share the combined data points and PR
FYI @Jackie-Jiang

So my coworker just pointed me to this issue. I'm an engineer at Stripe and we've just started experimenting with some similar ideas for making Pinot reliable. One thing I had just implemented in our fork and was testing today was a rate limiter for the Pinot broker that measures observed query latency and estimates server queue sizes using the TCP Vegas congestion control algorithm. I'm using this rate limiter implementation from Netflix.
I've only just started testing this but I can provide some data once I've had a chance to do some more comprehensive tests. But initial tests it looks promising.
I had similar thoughts about measuring server latencies and implementing load balanced routing and looks like you guys have already started implementing that which is great to see! We have observed similar issues in our clusters with a server that has degraded performance affecting overall latency.
Also had some ideas about how to meter resource usage on the servers during rebalances as we've noticed this can impact query performance as well.

Along with that we have also written a simulator in Python to model several different scenarios in theory and cross validated that with the new Pinot server selector code

Very curious to hear more about the simulator as well. Is this a simulation of a Pinot cluster?

I had similar thoughts about measuring server latencies and implementing load balanced routing and looks like you guys have already started implementing that which is great to see! We have observed similar issues in our clusters with a server that has degraded performance affecting overall latency.

Thanks. Please feel free to look at the PR and provide your feedback. The results are documented here

Very curious to hear more about the simulator as well. Is this a simulation of a Pinot cluster? @siddharthteotia
This is a simulation of how the pinot brokers and servers would behave with the Adaptive Server Selection algorithm. The results of this simulation are documented here . @jasperjiaguo  helped write this simulator and will be publishing it in a public github repo some time next.

FYI @npawar


bitwarden-desktop: add aarch64-darwin/x68_64-darwin support.

Things done

Built on platform(s)

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

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

[x] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

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

Okay, I'll compile bitwarden for darwin, test it and then update the PR for you to check.

IMO if we wanted to distribute the prebuilt stuff, then it should be as a separate package, something like bitwarden-desktop-bin.
Though we should look into packaging from source before we do that

I have a lot (maybe too much) experience packaging electron apps for nixpkgs, so I don't think it's going to take very long to get it working from source. Will open a PR once it's done.

@TomaSajt Cool go ahead, I need to learn more about building electron apps.


Quick start section is cut off

The quick start section is cut off. Users are not able to copy the full script here.

@rschindlauer @afranklin  I don't have access or a way to fix this issue since I don't handle User Guide would one of you investigate this issue or point me to where I can fix this?

The table in https://github.com/dato-code/userguide/blob/master/install.md just needs a few linebreaks. You can do this in a new userguide repo branch and loop me into the PR.


Evaluate multi-module use cases

Seems like use cases where you want to separate out shared functionality into a library and use it in multiple other libraries or binaries will inevitably come up.
In the simple case, you could have:

multiple crates in a single maven project

In the more complex (and more interesting) case, you could have:
2) multiple crates spread across maven projects with dependencies between them
How do you go about adding dependencies between rust artifacts produced in separate maven projects?  Is this trivial with built-in cargo functionality? Is this a bad idea?
In other words, can you drive a complex, multi-module, mixed language project, that includes rust, entirely using maven (in the presence of cargo)?  This closely matches the use-case for our very large, multi-module java/web application, which currently pulls in c++ binaries and system libraries in a rather convoluted way. We can accomplish what we need using various tools, but baking more of this into our pom.xml files greatly simplifies the surface area developers need to interface with, and ups the likelihood that all dependencies are up-to-date in the final product.
Related Note:
Incremental building capabilities in maven are actually really essential this type of maven first build pipeline: https://maven.apache.org/extensions/maven-build-cache-extension/index.html
I can start looking into this, but wanted to verify it's validity first since my rust experience is rather limited.

I think that this is a no-op:
Rust crates can already do this from this projects point of view.
Shared code would just be built as regular libs without Maven integration.
Any open source shared libs you can upload them crates.io, otherwise you can:

Refer to them by path.
Load them from a git repo.
Start your new registry.

See: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html
As for caching across builds, see:
https://doc.rust-lang.org/cargo/guide/build-cache.html
As that page mentions, there's also https://github.com/mozilla/sccache, but you're only likely to need this once your volume of code  starts getting large.
If there are specific features (e.g. customizing --target-dir) that come off the back of your needs we can re-evaluate, but for now I think we can close this issue as I think that all dependency matters can be dealt with from within Cargo.

Thanks for the feedback.  I agree there is no action item yet. I will test various approaches using built-in cargo functionality.
My objective will be to have a minimal maven project like so:
projP
|___ pom.xml
|____ .. etc
|___ projA
|____ pom.xml
|____ .. etc
|___ projB
|____ pom.xml
|____ .. etc
|___ projC
|____ pom.xml
|____ .. etc
Where projA has a set of library functionality in lib.rs, that is used by rust binaries or dylibs in projB and projC.
I should be able to have java integration tests in projB and projC that are affected by changes in the lib.rs in projA.  I should be able to incrementally change lib.rs and run all tests by invoking: mvn test from the root (projP).  Ideally, this could be done without having to increment lib.rs version and dependency references in projB and projC.  It would also be nice not to have to rely on relative paths (in case modules move), or the installation of additional tools.  At least in this case, I'm trying to keep the rust source fully embedded (possibly hidden) in the java project, and not treated like an external dependency.
Big picture:
As a java developer, I think rust + java is a match made in heaven (especially when you add in maven/maven central and cargo/crates.io).  They both default to memory safety (although by different means).  Java is historically strong in web servers, while rust has wasm-pack. Java is rich in libraries for high level application orchestration, while rust can be optimized for low level performance operations. JNI exists and is supported in rust, etc.
Modularity is key to maintaining long-lasting software projects.  Multi-module maven projects are extremely common these days ("Almost 75% of Maven users work with multi-module projects" link).  Making a use case like the one described above seamless would really make this plugin compelling IMHO.
Sorry if this is not the right place to have high-level discussions like this.  I will certainly take point on any discovery and implementation needed related to this request as I have time over the coming weeks.


[ONNX] Provide support for function in ONNX models [Approach 2]

Moved to the  OpenVino repository.


Authenticity field in DA conforms to Linked Data Proofs

Signed-off-by: George J Padayatti<EMAIL_ADDRESS>

@lalc brown ?

@JanLin Based on your internal comments regarding the proof node. I have submitted an alternative proposal as PR #17

Closing this PR since alternate proposal seems more appropriate.


User Data Management for Transcriptomics

Is this the PD for the Experiments/Samples?  Regardless it seems like we need more details here. @psdehal: Can you iterate on this?


Isha Time Wrong. Rest of them correct.

Brother the time for isha seems a bit off.
Correct time is 20:16 and it is showing 18:50 which is even earlier than maghrib.
Coordinates coordinates = Coordinates(17.3850,78.4867); //Hyderabad Coordinates [Asia/Kolkata]
CalculationParameters calculationParameters = CalculationMethod.Karachi();
PrayerTimes prayerTimes = new PrayerTimes(coordinates, DateTime.now(), calculationParameters);

print(prayerTimes.fajr.toLocal());
print(prayerTimes.dhuhr.toLocal());
print(prayerTimes.asr.toLocal());
print(prayerTimes.maghrib.toLocal());
print(prayerTimes.isha.toLocal());

OUTPUT :
I/flutter (19670): 2020-06-25 04:22:00.000
I/flutter (19670): 2020-06-25 12:20:00.000
I/flutter (19670): 2020-06-25 15:42:00.000
I/flutter (19670): 2020-06-25 18:54:00.000
I/flutter (19670): 2020-06-25 18:50:00.000
Reloaded 1 of 675 libraries in 1,160ms

All timings are correct except isha time. Please look into the matter. Jazkallah

Will do, it was fine while I was testing with custom calc parameters, but haven't yet been able to check the presets yet. Thanks for spotting it.

Will do, it was fine while I was testing with custom calc parameters, but haven't yet been able to check the presets yet. Thanks for spotting it.

I built an application for prayer times called "Timeforsalah" with flutter, you can find it on playstore. I was familiar with java so i used the java version of adhan.js by using platform channels.
I tried to convert it in dart but it was too complex for me. Can't wait to have it in dart so that an IOS version could also be possible. Great work !

I got it, it was an issue with all calculation methods that did not have custom isha angle. Basically a typo in code where ishaAngle was set to ishaInterval. Now it should work for all:
`import 'package:adhan/adhan.dart';
main() {
Coordinates coordinates =
Coordinates(17.3850, 78.4867); //Hyderabad Coordinates [Asia/Kolkata]
CalculationParameters calculationParameters = CalculationMethod.Karachi();
PrayerTimes prayerTimes =
PrayerTimes(coordinates, DateTime.now(), calculationParameters);
int timezoneAdj = (5.5 * 60).toInt();
print(prayerTimes.fajr.add(Duration(minutes: timezoneAdj)));
print(prayerTimes.dhuhr.add(Duration(minutes: timezoneAdj)));
print(prayerTimes.asr.add(Duration(minutes: timezoneAdj)));
print(prayerTimes.maghrib.add(Duration(minutes: timezoneAdj)));
print(prayerTimes.isha.add(Duration(minutes: timezoneAdj)));
}
Result:2020-06-26 05:22:00.000
2020-06-26 12:20:00.000Z
2020-06-26 15:43:00.000Z
2020-06-26 18:54:00.000Z
2020-06-26 20:16:00.000Z`
I had to use timezone adjustment in the above example (as my local time is UTC+1), but of course the proper way would be by using timezone package.

Great job! Cant wait to implement the library !


LinkPager duplicate page (page=1 & without)

What steps will reproduce the problem?
When adding an overview that contains a LinkPager. Make sure there are atleast 2 pages. Click on page 2 and go back to page 1, now the GET parameter contains page=1.
What is the expected result?
The GET parameter should be removed, this because search engines see this as duplicate content (with and without the "page=1" GET parameter).

Q
A

Yii version
2.0.8-dev

PHP version
7.0.2

Operating system
Windows 10

Set forcePageParam to false
http://www.yiiframework.com/doc-2.0/yii-data-pagination.html#$forcePageParam-detail


Wrong link to C# developer reference

The link to C# developer reference points to the Azure Functions C# script (.csx) developer reference:
https://docs.microsoft.com/en-us/azure/azure-functions/functions-reference-csharp
The actual link should be
https://docs.microsoft.com/en-us/azure/azure-functions/functions-dotnet-class-library

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

ID: 7aff040c-9c09-c184-d0e7-fb3bbb80ceec
Version Independent ID: 68d924e7-7b32-fb1b-44eb-efc116da63ab
Content: Guidance for developing Azure Functions
Content Source: articles/azure-functions/functions-reference.md
Service: azure-functions
GitHub Login: @ggailey777
Microsoft Alias: glenga

Hi @leus Thank you for your feedback! We will review and provide an update as appropriate.

@leus I have created the PR for this which will address this. Thanks so much for providing the feedback that help us in improving the documentation. For now I will proceed with closure of this and If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


weird rotation for spots and underlying image

I get this weird rotation between image and spots

this is how I create the Spatial Experiment object
path_adata <- "/data/day3_spatial_transcriptomics"
ad <- readH5AD(paste0(path_adata,"/V10F24-105_A1_destvi.h5ad"))

coords <- as.matrix(reducedDim(ad, "spatial"))
colnames(coords) = c("x","y")
spe <- SpatialExperiment(
    assay = assay(ad,"X"),
    colData = ad@colData,
    spatialCoords = coords,
)
spe[["sample_id"]] <- "V10F24-105_A1"

path_img <- "/home/rstudio/adv_singlecell_2022/day3_spatial_transcriptomics/V10F24-105_A1.png"
spe <- addImg(spe,
    sample_id = "V10F24-105_A1",
    image_id = "V10F24-105_A1",
    imageSource = path_img,
    scaleFactor = 0.04155585,
    load = TRUE)

data is converted with zellkonverter (will ping you over at that repo for start thinking about proper conversion).
The image is also from anndata but it's the same as the spaceranger output. I can provide data easily if needed.

I think the error was in the data storage and didn't ahve to do with ggpsavis. Can be closed

Ok, thank you! Apologies, I hadn't replied to this issue yet.


cmd: refactor tikv server startup

What have you changed?
Refactors server.rs in cmd. There are no functional changes here, just moving code around to hopefully make it clearer what is happening and how components are related. There should be no functional or performance impact.
The main idea is to breakup the huge function into many little ones. To do that I had to use a new object (TiKV) to track the various components.
I think there are some improvements that could be made, by moving some parts of these tasks into the components themselves. There are a few very small changes like that, however, for this PR I tried to avoid it as far as possible and only change the one module.
What is the type of the changes?

Engineering (engineering change which doesn't change any feature or fix any issue)

PTAL @overvenus @BusyJay

/run-integration-tests

ping @NingLin-P @BusyJay PTAL

Comments addressed and rebased. PTAL @BusyJay and @NingLin-P

@BusyJay comments addressed, PTAL

/run-all-tests

/run-all-tests

/merge

/merge

/merge

/merge

/merge

/merge

/merge

/merge

/merge

/merge

/merge

/merge

/merge

/merge

/merge


Compiling Hyprland from git fails

Hi,
I cannot compile the latest git version of Hyprland. I am attaching a log.
hypr-compile-fail.txt

seems like an issue with libdrm...?
At any rate, since the CI does not fail, it means compiling succeeds on all our test platforms.
If you are using any other distro, it's up to you to figure out what you may be missing / what might be outdated.

Hi Vaxry
But I am using Arch - which is supported. Trying to install
from AUR, both the git version and the release version also fails.
Vaxry @.***> wrote:

seems like an issue with libdrm...?
At any rate, since the CI does not fail, it means compiling succeeds on all our test platforms.
If you are using any other distro, it's up to you to figure out what you may be missing / what might be outdated.
--
Reply to this email directly or view it on GitHub:
https://github.com/hyprwm/Hyprland/issues/1404#issuecomment-1397147167
You are receiving this because you authored the thread.
Message ID: @.***>

if that's the case make sure you are up to date and have all the dependencies. You can take a look at the arch CI as well, it does not fail.

Actually, I forgot to update - I had just updated an Arch
system on another computer and forgot it wasn't the one I was
sitting at ...but after the update, it still fails with the
exact same error. When installing from AUR, all the
dependencies are checked automatically and therefore should be
OK.
But I am on my own, I guess.
Vaxry @.***> wrote:

if that's the case make sure you are up to date and have all the dependencies. You can take a look at the arch CI as well, it does not fail.
--
Reply to this email directly or view it on GitHub:
https://github.com/hyprwm/Hyprland/issues/1404#issuecomment-1397159003
You are receiving this because you authored the thread.
Message ID: @.***>


Sim make command

Ran make in sim and got the following error:
gcc -g -DSF_L_ENDIAN  -Wall   -g -m32 -O0  -c randgen.c
In file included from /usr/include/features.h:447:0,
from /usr/include/bits/libc-header-start.h:33,
from /usr/include/math.h:27,
from randgen.c:38:
/usr/include/gnu/stubs.h:7:11: fatal error: gnu/stubs-32.h: No such file or directory
include <gnu/stubs-32.h>
       ^~~~~~~~~~~~~~~~

compilation terminated.
make: *** [Makefile:79: randgen.o] Error 1
Having changed to correct HOST and SUNFLOWERROO

As a temporary workaround (via @z-gu, paraphrased): "Install 32-bit libgcc: sudo sudo apt-get install gcc-multilib. It is likely that apt-get may report an error. In which case, the required library is still installed. However, this will make the apt-get package manager unusable due to a known Ubuntu bug. To fix this: Run sudo dpkg --remove libc6-amd64:i386 libc6-dev-amd64:i386 then run sudo apt-get -f install. Now apt-get should be usable again."

I have a fedora laptop, so I installed gcc glibc-devel according to fedora this is the equivalent. However, now when I run make it says command not found

Have now installed bison.
Make now runs bit with a lot of warnings:
bison -t -v sf.y
sf.y:315.9-14: warning: symbol T_MACL redeclared [-Wother]
%token	T_MACL
^^^^^^
sf.y: warning: 2 nonterminals useless in grammar [-Wother]
sf.y: warning: 4 rules useless in grammar [-Wother]
sf.y:391.17-21: warning: nonterminal useless in grammar: ruimm [-Wother]
%type		ruimm
^^^^^
sf.y:392.17-21: warning: nonterminal useless in grammar: rsimm [-Wother]
%type		rsimm
^^^^^
sf.y:7917.19-7926.17: warning: rule useless in grammar [-Wother]
ruimm		: uimm
^
sf.y:7927.19-7931.17: warning: rule useless in grammar [-Wother]
| rnd
^
sf.y:7934.19-7943.17: warning: rule useless in grammar [-Wother]
rsimm		: simm
^
sf.y:7944.19-7948.17: warning: rule useless in grammar [-Wother]
| rnd
^
sf.y: warning: 104 shift/reduce conflicts [-Wconflicts-sr]
sf.y: warning: 500 reduce/reduce conflicts [-Wconflicts-rr]
sf.y:459.19-25: warning: rule useless in parser due to conflicts [-Wother]
| dotfile
^^^^^^^
sf.y:460.19-27: warning: rule useless in parser due to conflicts [-Wother]
| dotglobal
^^^^^^^^^
gcc -g -DSF_L_ENDIAN  -Wall  -g -m32 -O0  -c sf.tab.c -o sf.o
./mkmantex gawk > commands.tex
gcc -g randgen.o arch-linux.o batt.o bit-utils.o decode-hitachi-sh.o dev7708.o devsim7708.o fault.o fdr.o machine-hitachi-sh.o main.o merror.o mmalloc.o mmu-hitachi-sh.o network-hitachi-sh.o op-hitachi-sh.o pau.o physics.o pic.o pipeline-hitachi-sh.o power.o syscalls.o tokenhandling.o sf.o  -m32 -lm -lpthread  -o sf

This is a result of the -m32 flag which we currently require.


docs(riot-rs): document Cargo features aimed at users

It currently looks like this on the root page of riot-rs:

LGTM!


Dialog.close() does not call the close callback

Describe the bug.
If a close callback (closeFn) has been given when calling Dialog.open(), that callback is not invoked when closing the dialog from code using Dialog.close(). The callback is only called when the user manually closes the dialog using mouse or keyboard.
To Reproduce:
  Dialog.setup("Test");
  Dialog.wiki('<<link "Click Me">><<set Dialog.close()>><</link>>');
  Dialog.open({}, () => {
    alert("Close callback called!");
  });

Expected behavior.
Clicking the "Click Me" link should close the dialog and show the alert message. It only closes the dialog though, so the close callback is not called. Clicking on the "X" close button instead does invoke the callback.
Workaround.
  Dialog.setup("Test");
  Dialog.wiki('<<link "Click Me">><<set jQuery("#ui-dialog-close").trigger("click")>><</link>>');
  Dialog.open({}, () => {
    alert("Close callback called!");
  });

Project details.

SugarCube Version: 2.36.1

It was the intended behavior, so not a bug.
Regardless.  The behavior was changed, back in November 2022, via commit 96ddf9a to align with your feature request.

Aw  sorry, I couldn't find a ticket or discussion about that behavior. Thanks for having changed it then 😁


Is this repository still in progress?

I'm curious.
Since angular 1.5.0-beta.0 came out, I just wonder when can I use the actual version of new router for actual beta angular
Is this router will replace old angular-route in 1.5.0 also, right?

@alanpurple as the readme states, this repository is on hold since a couple of months, since the development of the component router has been moved to the angular projects itself for easier setup.
You can take a look at the current state right here: https://github.com/angular/angular/tree/master/modules/angular1_router


Test Issue Sync to Jira

This is only a test from contracts-js

Exalate commented: GitHub source link is https://github.com/Lumerin-protocol/contracts-js/issues/1

Alan Sorber commented: Test Comment back from Jira


Exclude m/z values during GCMS spectral deconvolution

Dear all,
I would like to know how the m/z exclusion list works during spectral deconvolution of GC/MS data with Hierarchical clustering on MZmine 3.3.0.
When selecting the model peak, I would like to be able to exclude m/z 73 and 147 as possible choices and select the most intense m/z after these two. I tried entering integer m/z values (e.g. 73, 147) or ranges (e.g. 72-75, 146-148) but these m/z are still selected as model peak as soon as the choice is based on intensity.
Thank you for your help
Best,
Nathalie

Maybe @asmirn1 or @tnguy271 could comment they are the experts on GC-MS data.

@NthlLcrmp Could you share your project file so I could test it?
The m/z exclusion list should work with any choice of Model Peak. What parameter do you use for the spectral deconvolution?

@asmirn1 Thank you for taking a look at the problem.
Here is a link with a test project file:
https://filesender.renater.fr/?s=download&token=4117541f-57d1-4e31-980b-4b06f999e11b
The parameters used for spectral deconvolution were

I also try with m/z ranges

I am not really confident in my choices, I may have made mistakes.
Both cases produce the same results with m/z 73 as model peak :

@NthlLcrmp
We've fixed this issue in the development release. Could you try to install it and let us know if it works for you?
https://github.com/mzmine/mzmine3/releases/tag/Development-release

Thank you @asmirn1 for the update.
The exclusion of m/z values works fine with this version.
However, an m/z range must be provided to exclude the unwanted m/z. When choosing only the m/z value 73 the feature list still contains m/z 73 :

What is the tolerance on the m/z value to exclude?

@asmirn1 I agree that a single parameter with ranges is simpler.  It might be useful to point out in the tooltip that a range is needed for non-integer m/z values.
I have a related question regarding the number of significant digits on the m/z value of the model peak.
I process low resolution data with one significant digit on the m/z values. When extracting EICs I use a scan to scan accuracy of 0.5 m/z or 0 ppm and in the resulting feature list the m/z has a precision of 4 significant digits which is maintained throughout the data processing.
Is it possible to produce m/z values with fewer significant digits?
Is this due to a poor choice of parameters?


Support for Numpy BitGenerators PR#1 - Core Generator Support

This PR adds the core BitGenerator implementation from #7900 and adds support for np.random.Generator().random()
cc @esc @stuartarchibald

I just checked the CI logs, it doesn't look like the tests I added are actually being run in the pipeline (probably because of them being in a new file). Where are the configuration files located for registering that ?

You will need to make the test class inherit from TestCase so as to mark it as a test and such that it is picked up by the testing framework. I created a temporary PR at:
https://github.com/numba/numba/pull/8033
Which does that and also deliberately makes the test fail to provide an easy way to tell if it did indeed fail. You can probably just grab the following diff to make it work:
diff --git a/numba/tests/test_np_randomgen.py b/numba/tests/test_np_randomgen.py
index f0830b10c2..9d33d62914 100644
--- a/numba/tests/test_np_randomgen.py
+++ b/numba/tests/test_np_randomgen.py
@@ -1,10 +1,12 @@
 import numpy as np
 import numba
+from numba.tests.support import TestCase

 from numpy.random import MT19937, Generator

-class TestRandomGenerators:
+class TestRandomGenerators(TestCase):
+
     def check_numpy_parity(self, distribution_func,
                            bitgen_instance=None, seed=1):
         distribution_func = numba.njit(distribution_func)

What kind of documentation should we add for this PR ?

What kind of documentation should we add for this PR ?

I would argue that the section in: https://numba.readthedocs.io/en/stable/reference/numpysupported.html#modules
will need an overhaul to describe how the NumPy random number generator state can now traverse the JIT boundary.

@kc611 thank you for the updates. One immediate thing to note is that the doc build seems to be failing. This is because for the public CI in Numba we have elected to treat warnings as errors and so the build fails. The error is
/home/vsts/work/1/s/docs/source/reference/numpysupported.rst:586:Title underline too short.

which ought to be quite straightforward to fix.

I think this might summarise the current issue observed with reference counting for the Generator type. This shows what happens with a NumPy array and what happens with a custom type that does something similar to that required in the case of the Generator type. It might be easier debugging with this than with a full implementation?
from contextlib import ContextDecorator
import gc
import sys
import numpy as np

from numba import njit, types, objmode
from numba.extending import typeof_impl, models, register_model
from numba.extending import box, unbox, NativeValue
from numba.core import cgutils
from numba.core.runtime import rtsys

class Thing(object):
    def __init__(self):
        pass

class ThingType(types.Type):
    def __init__(self):
        super(ThingType, self).__init__(name='Thing')

thing_type = ThingType()

@typeof_impl.register(Thing)
def typeof_thing(val, c):
    return thing_type

@register_model(ThingType)
class ThingModel(models.StructModel):
    def __init__(self, dmm, fe_type):
        members = [
            ('meminfo', types.MemInfoPointer(types.voidptr)),
            ('parent', types.pyobject),
        ]
        models.StructModel.__init__(self, dmm, fe_type, members)

@unbox(ThingType)
def unbox_thing(typ, obj, c):
    thing_struct = cgutils.create_struct_proxy(typ)(c.context, c.builder)
    thing_struct.parent = obj
    NULL = cgutils.voidptr_t(None)
    thing_struct.meminfo = c.pyapi.nrt_meminfo_new_from_pyobject(
        NULL,  # there's no data
        obj,   # the python object, the call to nrt_meminfo_new_from_pyobject
               # will py_incref
    )
    is_py_error = cgutils.is_not_null(c.builder, c.pyapi.err_occurred())
    return NativeValue(thing_struct._getvalue(), is_error=is_py_error)

@box(ThingType)
def box_thing(typ, val, c):
    thing_struct = cgutils.create_struct_proxy(typ)(c.context, c.builder,
                                                    value=val)
    res = thing_struct.parent
    c.context.nrt.decref(c.builder, typ, val)
    return res

class memory_leak_check(ContextDecorator):

    def __init__(self, the_obj):
        self._the_obj = the_obj

    def __enter__(self):
        # Clean up any NRT-backed objects hanging in a dead reference cycle
        gc.collect()
        print(f"Python refcount: {sys.getrefcount(self._the_obj)}")
        self.__init_stats = rtsys.get_allocation_stats()

    def __exit__(self, *exc):
        gc.collect()
        old = self.__init_stats
        new = rtsys.get_allocation_stats()
        total_alloc = new.alloc - old.alloc
        total_free = new.free - old.free
        total_mi_alloc = new.mi_alloc - old.mi_alloc
        total_mi_free = new.mi_free - old.mi_free
        print(f"Allocs: {total_alloc}. Frees: {total_free}")
        print(f"MI Allocs: {total_mi_alloc}. MI Frees: {total_mi_free}")
        gc.collect()
        print(f"Python refcount: {sys.getrefcount(self._the_obj)}")

def np_ty(): return np.ones(3)

for Clazz in (np_ty, Thing):
    print('\n', f"Testing Type: {Clazz}".center(80, '='), '\n')
    print('Testing no-op'.center(80, '_'))

    thing_inst1 = Clazz()
    print(f"Python refcount: {sys.getrefcount(thing_inst1)}")  # should be 2
    with memory_leak_check(thing_inst1):
        thing_inst1  # Python refcount should be 3, the ctxmanager holds 1 more

    @njit
    def foo(x):
        return x

    thing_inst2 = Clazz()

    print('Testing foo'.center(80, '_'))
    with memory_leak_check(thing_inst2):
        initial_id = id(thing_inst2)
        result = foo(thing_inst2)
        result_id = id(result)
        print(f"ID check: {result is thing_inst2}")

    @njit
    def bar(x):
        pass  # x unused

    print('Testing bar'.center(80, '_'))
    thing_inst3 = Clazz()
    with memory_leak_check(thing_inst3):
        bar(thing_inst3)

    @njit
    def baz(x):
        with objmode():
            print(f"In objmode block {sys.getrefcount(x)}")

    print('Testing baz'.center(80, '_'))
    thing_inst4 = Clazz()
    with memory_leak_check(thing_inst4):
        baz(thing_inst4)

If we have the incref for the parent during boxing, the stats seems exactly the same. But does that cause further problems ?
(In the above example that would be equivalent to having c.pyapi.incref(res) during boxing)

So I tried using run_in_new_process_caching, and since we don't yet have support for constructors for Generator inside Jit functions, I modified run_in_new_process_caching to support arguments. Apparently Python's multiprocessing is not happy with it and says (from azure logs):
Traceback (most recent call last):
  File "/home/vsts/work/1/s/numba/tests/test_np_randomgen.py", line 108, in test_randomgen_caching
    res = run_in_new_process_caching(numba_func, func_args=(nb_rng,))
  File "/home/vsts/work/1/s/numba/tests/support.py", line 895, in run_in_new_process_caching
    return run_in_new_process_in_cache_dir(func, cache_dir, func_args, verbose=verbose)
  File "/home/vsts/work/1/s/numba/tests/support.py", line 918, in run_in_new_process_in_cache_dir
    proc.start()
  File "/home/vsts/miniconda3/envs/azure_ci/lib/python3.7/multiprocessing/process.py", line 110, in start
    'daemonic processes are not allowed to have children'
AssertionError: daemonic processes are not allowed to have children

I tried using run_in_new_process_caching, and getting the following error in Azure pipelines (and unable to replicate locally):
Traceback (most recent call last):
  File "/home/vsts/work/1/s/numba/tests/test_np_randomgen.py", line 116, in test_randomgen_caching
    res = run_in_new_process_caching(test_generator_caching)
  File "/home/vsts/work/1/s/numba/tests/support.py", line 895, in run_in_new_process_caching
    return run_in_new_process_in_cache_dir(func, cache_dir, verbose=verbose)
  File "/home/vsts/work/1/s/numba/tests/support.py", line 918, in run_in_new_process_in_cache_dir
    proc.start()
  File "/home/vsts/miniconda3/envs/azure_ci/lib/python3.7/multiprocessing/process.py", line 110, in start
    'daemonic processes are not allowed to have children'
AssertionError: daemonic processes are not allowed to have children

Hi, thanks for this commit, and I checked it worked well on my problems. While it worked well for JIT compilation, I'd like to move my implementation for AOT compilation, but I cannot figure out how to specify the datatype, e.g., I tried
import numpy as np
from numba import njit
from numba.core.types.npytypes import NumPyRandomGeneratorType
from numba import int64 as i8, boolean as b1, uint8 as u1, float64 as f8

@njit
@cc.export('cumsum', f8[:](f8[:]))
def cumsum(p):
    p = np.copy(p)
    for i in range(1, len(p)):
        p[i] += p[i -1]
    return p

@njit
@cc.export('choice', i8(f8[:], NumPyRandomGeneratorType))
def choice(p, rng):
    # Reference: https://github.com/numpy/numpy/blob/main/numpy/random/_generator.pyx#L762-L767
    cdf = cumsum(p)
    return np.searchsorted(cdf, rng.random(), side='right')

but it didn't work. Can I get a way to AOT compile with RNG?
Thanks!.

@wsjeon thank you for testing this patch. RE AOT: As hinted at in the error message, the signature expects type instances not type classes. Something like this should work:
from numba import njit, types
import numpy as np
from numba.pycc import CC

cc = CC('test8031')

# Create a NumPyRandomGeneratorType instance
type_inst = types.npytypes.NumPyRandomGeneratorType('rng')

@njit
@cc.export('foo', types.void(type_inst))
def foo(rng):
    print(rng.random())

cc.compile()

import test8031

x = np.random.default_rng()
test8031.foo(x)

@kc611 @esc wonder if it might be a good idea to create a default type instance for these types, I don't think there's any per-instance specialisation other than the "name"?

@kc611 as discussed OOB, this patch fixes a few issues but it is NOT for use in its current form! I've pasted it as-is as it hopefully conveys the ideas needed to fix the numerical problems:

float constants (like 1.0) are typed as float64 which will cause float32 type promotion in a lot of operations.
ensuring the type of the argument to functions like np.exp and np.log is correct will ensure dispatch to the appropriate libm function. For example log(float32(1.23)) is different to float32(log(1.23)), former calls logf and gets a float32 result, latter calls log and casts the result to float32.
the use if log1p and expm1 is recommended in cases where there's expressions like log(1 + x) and exp(x) - 1 respectively. NumPy fixed up its distribution algs in version 1.21 to do this, suggest looking in NumPy's distributions.c to see precisely where.

Patch:
diff --git a/numba/np/random/distributions.py b/numba/np/random/distributions.py
index d2aa2f2..b216780 100644
--- a/numba/np/random/distributions.py
+++ b/numba/np/random/distributions.py
@@ -87,7 +87,7 @@ def random_standard_exponential(bitgen):
             return x
         else:
             if idx == 0:
-                return ziggurat_exp_r - np.log(1.0 - next_double(bitgen))
+                return ziggurat_exp_r - np.log1p(-next_double(bitgen))
             elif ((fe_double[idx - 1] - fe_double[idx]) * next_double(bitgen) +
                   fe_double[idx] < np.exp(-x)):
                 return x
@@ -105,16 +105,18 @@ def random_standard_exponential_f(bitgen):
             return x
         else:
             if (idx == 0):
-                return float32(ziggurat_exp_r_f -
-                               float32(np.log(1.0 - next_float(bitgen))))
+                # Don't do this, use log1p with a float32 arg.
+                # This is for demonstrative purposes only.
+                f32_one = np.float32(1.0)
+                return float32(ziggurat_exp_r_f - float32(np.log(np.float32(f32_one - next_float(bitgen)))))
             elif ((fe_float[idx - 1] - fe_float[idx]) * next_float(bitgen) +
-                  fe_float[idx] < np.exp(-x)):
+                  fe_float[idx] < np.float32(np.exp(np.float32(-x)))):
                 return x

 @register_jitable
 def random_standard_exponential_inv(bitgen):
-    return -np.log(1.0 - next_double(bitgen))
+    return -np.log1p(- next_double(bitgen))

Also, additional thoughts... given there's branches on floating point values that could well be derived from expressions that have diverged across NumPy releases (e.g. the log1p fixes), some consideration is going to be needed about how to test the bit-wise replication. It may be good to focus on matching a single NumPy version to start with (maybe 1.21) and then look at how much algorithmic churn has occurred against the other versions, if it's not too bad then it might be possible to "port the bugs", else testing against "the most fixed" version might be the thing to do (and declare that in the docs).

/azp run

Running a smoketest at: Build numba_smoketest_cpu_yaml_103 has started.

/azp run

@kc611 @esc wonder if it might be a good idea to create a default type instance for these types, I don't think there's any per-instance specialisation other than the "name"?

@stuartarchibald @wsjeon thanks to the work of @kc611 AOT appears to work now too:
zsh» ls
test_8031.py

zsh» cat test_8031.py
import numpy as np
from numba import njit
from numba.core.types import npy_rng
from numba import int64 as i8, boolean as b1, uint8 as u1, float64 as f8
from numba.pycc import CC

cc = CC('test')
cc.output_dir = "CC_OUTPUT"

@njit
@cc.export('cumsum', f8[:](f8[:]))
def cumsum(p):
    p = np.copy(p)
    for i in range(1, len(p)):
        p[i] += p[i -1]
    return p

@njit
@cc.export('choice', i8(f8[:], npy_rng))
def choice(p, rng):
    # Reference: https://github.com/numpy/numpy/blob/main/numpy/random/_generator.pyx#L762-L767
    cdf = cumsum(p)
    return np.searchsorted(cdf, rng.random(), side='right')

print(choice(np.zeros(23, dtype=np.int64), np.random.default_rng()))

cc.compile()

zsh» python test_8031.py
23

 zsh» ls
CC_OUTPUT  test_8031.py

zsh» cd CC_OUTPUT
zsh» ls
test.cpython-39-darwin.so

zsh» python
Python 3.9.7 (default, Sep 16 2021, 08:50:36)
[Clang 10.0.0 ] :: Anaconda, Inc. on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import test
>>> dir(test)
['__doc__', '__file__', '__loader__', '__name__', '__package__', '__spec__', 'choice', 'cumsum']
>>>

Running a smoketest at: Build numba_smoketest_cpu_yaml_103 has started.

FWIW: this was fine 🟢

Build numba_smoketest_cpu_yaml_105 has started

@kc611 thanks for the patch!

The documentation added in this PR states that

The current Numba support for :py:class:Generator is not thread-safe, hence we
do not recommend using :py:class:Generator methods in methods with parallel
execution logic.

Could you elaborate a bit on this? I understand that if I pass a Generator into a Numba function, Numba will take a reference to its BitGenerator for reading/writing its state - so naturally, one shouldn't use it concurrently from multiple threads. Are there any dangers beyond this type of misuse?
More specifically, is it safe to run multiple nogil=True Numba functions concurrently if each call receives a separate Generator,  e.g. created by Generator.spawn()? Or does the Numba Generator implementation use some sort of global state management that prohibits any sort of parallelism?


Training pipeline of linear probing for semantic segmentation and depth estimation

Dear DINOv2 team, thank you for this amazing work! If I am correct, I only found the whole pipeline of linear probing for classification on ImageNet in https://github.com/facebookresearch/dinov2/blob/main/dinov2/eval/linear.py.
Is it possible for you to also release the training pipeline of linear probing for semantic segmentation (ADE20k, Cityscapes, Pascal VOC 2012) and depth estimation (NYU-Depth V2, KITTI, SUN-RGBD), including dataloader, data augmentation used, training schedule, etc? I believe this will serve as a standard testbed for follow-up works to compare with DINOv2 in a fair setup (i.e. excluding the effect of data augmentation, training schedule, etc). Thank you very much!

Hi, here's an unofficial training and testing pipeline of segmentation using mmsegmentation, based on the configs provided by the authors. The example implements Cityscapes but can be adopted to other datasets
https://github.com/zshn25/DINOv2_mmseg


[Correction] Remove performant

Checklist

[X] I've checked that this correction is valid and accurate.
[X] I've checked that this correction has not already been suggested.

What mod is this correction for?
Performant
What section(s) of the list is this correction for?
Performance
What version(s) does this correction apply to?
1.12.X
What needs correcting?
as of version 1.11 of performant for mc 1.12 the mod does nothing but make a config file, i don't see any need for it to be kept on the list
Input relevant link(s) which can be used to verify the correction.
i have asked someaddon for comment on this but they didnt get back to me, but you can see by the file size and opening the file (as all jar files are zip files) you can see the file has been gutted to remove everything but config file creation
(OPTIONAL) Any extra information about the correction.
No response

I decided to check it out and it really turned out to be as you wrote. Thanks


Suppress initial interface down alarms with config option

Scope and purpose
Closes #257.
This is how I interpreted this issue: We have a config option that if it is set to true the first time a PortStateEvent would be created with the interface down state nothing happens instead.
Contributor Checklist
Every pull request should have this checklist filled out, no matter how small it is.
More information about contributing to Zino can be found in the
README.

[X] Added a changelog fragment for towncrier
[X] Added/amended tests for new/changed code
[X] Added/changed documentation
[X] Linted/formatted the code with black, ruff and isort, easiest by using pre-commit
[X] The first line of the commit message continues the sentence "If applied, this commit will ...", starts with a capital letter, does not end with punctuation and is 50 characters or less long. See https://cbea.ms/git-commit/
[ ] If applicable: Created new issues if this PR does not fix the issue completely/there is further work to be done

Settings this to draft/blocked until we get more concrete specification on how this should work


Can't install

Hi!
I tried to add this as a dependency but I can't manage to get it installed
C:\Windows\System32>pip install PyArr
ERROR: Could not find a version that satisfies the requirement PyArr (from versions: none)
ERROR: No matching distribution found for PyArr

Also from source it doesn't want to :
C:\Windows\System32>pip install -e https://github.com/marksie1988/PyArr.git#egg=PyArr
ERROR: https://github.com/marksie1988/PyArr.git#egg=PyArr is not a valid editable requirement. It should either be a path to a local project or a VCS URL (beginning with svn+, git+, hg+, or bzr+).

I am using python 3.7, any recommandations? Thanks!

Fun fact... Pip search can find it!
C:\Windows\System32>pip search PyArr
pyarr (0.9.4)  - A Sonarr and Radarr API Wrapper

Never mind, I see you need atleast Python 3.8 from now. I will update my python :)


Run clang-format on all files that are not currently open in PRs.

This only touches files that are not currently open in any pending pull requests (except #1912, which needs to be manually rebased anyway). That way merging these will be easier.
This unifies the pointer/reference alignment between all files.

Codecov Report
Patch coverage: 98.90% and no project coverage change.

Comparison is base (cf9afe7) 92.85% compared to head (5837ec9) 92.85%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@           Coverage Diff           @@
##           master    #1963   +/-   ##
=======================================
  Coverage   92.85%   92.85%
=======================================
  Files         355      355
  Lines       26272    26272
=======================================
  Hits        24395    24395
  Misses       1877     1877

Impacted Files
Coverage Δ

common/analysis/line_linter.h
100.00% <ø> (ø)

common/analysis/syntax_tree_linter.h
100.00% <ø> (ø)

common/analysis/syntax_tree_search_test_utils.h
100.00% <ø> (ø)

common/analysis/text_structure_lint_rule.h
100.00% <ø> (ø)

common/analysis/text_structure_linter.h
100.00% <ø> (ø)

common/analysis/token_stream_lint_rule.h
100.00% <ø> (ø)

common/analysis/token_stream_linter.h
100.00% <ø> (ø)

...ommon/formatting/token_partition_tree_test_utils.h
100.00% <ø> (ø)

common/formatting/unwrapped_line_test_utils.h
100.00% <ø> (ø)

common/formatting/verification.cc
100.00% <ø> (ø)

... and 166 more

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Feature: Implement Bottom Navigation with Toolbar using Compose

Feature description
Implement Bottom Navigation with Toolbar using Jetpack Compose UI
👀 Have you spent some time to check if this issue has been raised before?

[X] #4

🏢 Have you read the Code of Conduct?

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

please assign me this task

Done @ismailbohra Go ahead.


PHP8

Hi,
When could we expect PHP8.0 support? This is our last package needing support.
Thanks.

Strange situation… for v 1.2.3
Here on GitHub I see in composer.json "php": ">=7.0", in vendor "php": "^7.0",
$ composer show pragmarx/version
name     : pragmarx/version
descrip. : Take control over your Laravel app version
keywords : laravel, version, versioning
versions : * v1.2.3
type     : library
license  : MIT License (MIT) (OSI approved) https://spdx.org/licenses/MIT.html#licenseText
homepage :
source   : [git] https://github.com/antonioribeiro/version.git 691fd35c94eea9d58a9851f8fdb6c2dcee85af9a
dist     : [zip] https://api.github.com/repos/antonioribeiro/version/zipball/691fd35c94eea9d58a9851f8fdb6c2dcee85af9a 691fd35c94eea9d58a9851f8fdb6c2dcee85af9a
path     : /Users/dostrog/projects/taxbase/vendor/pragmarx/version
names    : pragmarx/version

support
issues : https://github.com/antonioribeiro/version/issues
source : https://github.com/antonioribeiro/version/tree/v1.2.3

autoload
psr-4
PragmaRX\Version\Package\ => src/package
PragmaRX\Version\Tests\ => tests/

requires
laravel/framework >=5.5.33
php ^7.0
pragmarx/yaml ^1.0
symfony/process ^3.3|^4.0|^5.0

requires (dev)
orchestra/testbench 3.4.*|3.5.*|3.6.*|3.7.*|4.*|5.*
phpunit/phpunit ~5|~6|~7|~8|~9

packagist has old version?

Strange situation… for v 1.2.3
Here on GitHub I see in composer.json "php": ">=7.0", in vendor "php": "^7.0",
$ composer show pragmarx/version
name     : pragmarx/version
descrip. : Take control over your Laravel app version
keywords : laravel, version, versioning
versions : * v1.2.3
type     : library
license  : MIT License (MIT) (OSI approved) https://spdx.org/licenses/MIT.html#licenseText
homepage :
source   : [git] https://github.com/antonioribeiro/version.git 691fd35c94eea9d58a9851f8fdb6c2dcee85af9a
dist     : [zip] https://api.github.com/repos/antonioribeiro/version/zipball/691fd35c94eea9d58a9851f8fdb6c2dcee85af9a 691fd35c94eea9d58a9851f8fdb6c2dcee85af9a
path     : /Users/dostrog/projects/taxbase/vendor/pragmarx/version
names    : pragmarx/version

support
issues : https://github.com/antonioribeiro/version/issues
source : https://github.com/antonioribeiro/version/tree/v1.2.3

autoload
psr-4
PragmaRX\Version\Package\ => src/package
PragmaRX\Version\Tests\ => tests/

requires
laravel/framework >=5.5.33
php ^7.0
pragmarx/yaml ^1.0
symfony/process ^3.3|^4.0|^5.0

requires (dev)
orchestra/testbench 3.4.*|3.5.*|3.6.*|3.7.*|4.*|5.*
phpunit/phpunit ~5|~6|~7|~8|~9

packagist has old version?

solved it by use "pragmarx/version": ">=v1.2.3" in composer.json. Loaded
$ c show pragmarx/version
name     : pragmarx/version
descrip. : Take control over your Laravel app version
keywords : laravel, version, versioning
versions : * 9999999-dev, * dev-master
type     : library
…

Thanx!

solved it by use "pragmarx/version": ">=v1.2.3" in composer.json. Loaded
$ c show pragmarx/version
name     : pragmarx/version
descrip. : Take control over your Laravel app version
keywords : laravel, version, versioning
versions : * 9999999-dev, * dev-master
type     : library
…

Thanx!

"pragmarx/version": ">=v1.2.3" is not working for me. Can a new tagged version be published with this fix?

@antonioribeiro Hi, can you tag and publish a new version with the PHP 8 compat? This is a blocker for me with updating our apps for PHP 8 compatibility and I don't want to set the version to look at the master branch.

I could also really do with this being updated!

Can anyone jump in and help make tests pass on Github Actions?
I believe there's still one test to be fixed.

Well... tests are passing fine on PHP 8, so version is tagged.
But I still need help with making them pass on Github actions.


Load and visualize normalized NIFTI data

Hello,
I am trying to visualize a nifti image, its intensity values normalized ranging from [0,1] instead of a T1 image with intensity level 34000,42000, etc... However, I get the image rendered all black. I suspect it is some normalization/range issue... how do you load and visualize normalized images? Specifically I am trying to load this FA Measures image.
and a fiddle ilustrating the issue (based on example 3 but changing the file to mine)
Cheers,

Hi @aalises -  thanks for the report
The issue in this case is that some voxels of the FA MEasurement have invalid intensities ("NaN") after being converted from ArrayBuffer to a typed array. I do not know why, could be many reasons.
It messes up the window level and the data being passed to the shaders among others.
I'll push a fix later today but I am a bit worried about the impact on performance - that may be something we want to look into later on -


Naming for @effect-ts/prelude

With the advent of webpack 5 namespace re-exports are now tree-shakable and we could introduce a @effect-ts/prelude package that re-export modules from the ecosystem core packages (i.e. core, monocle, morphic) let's discuss on the names of those re-exports.
I don't have strong preferences buy:

Full-names are terrible and long import {Effect} from "@effect-ts/prelude" because usage becomes verbose Effect.chain etc
Short-names are conflicted, for example is E Exit or Either

Export long names, let people alias alternative names (like short names) on their own.
Especially considering with current import * as, you can use a short alias but still see a long name in the path.

Given that the @effect-ts/core module itself currently doesn't export anything, it could be great to do theses exports on that level (similar to how Lodash works). This way a user doesn't have to install an additional package.

The idea of having a separated module is to also include packages from ecosystem libraries like morphic but I guess they are not mutually exclusive

https://github.com/Effect-TS/core/pull/583
It is really horrible to use and if the purpose is to re-alias like:
import { Effect as T } from "@effect-ts/core"

then I don't understand the point in the first place

The way how I used to use it was to re export all effect ts modules from a single place in one of my own libraries and then if I wanted to extend a module, I would create an extended version and then in my index replace the original module with my own.
In the meantime I got used to using the import * syntax instead, and just update the paths to my own extended module if the need arises.
Why I think it’s important to have full names available, even to alias it on the spot, provided either by path or by export name is that it provides a lookup table at the top of each file, to help the uninitiated, or to help remind the veterans :)
With the root export of all now, users have the option to go for full name import, or with as alias, or * as with full path, as they desire.

Reason for closing:
exports are in core/index already and feedback is: nobody is using it.
I will keep them in core for now, not guaranteed to stay unless there is a significant benefit presented with sustained usage

I propose gradual tiers of adoption

toolkit module namespace (or default)
Tool Module Namespaces
Tool Module Namespaces Abbreviated

(1) Toolkit Namespace
This can be achieved in one of two ways. A default export or an internal namespace. IIUC we want internal namespace because default export requires building a runtime object and does not work with treeshaking. But for completeness sake here it is:
default export
$ // autoimport kicks in

import $ from '@effect-ts/prelude`

$.<tab> // access to EVERYTHING
$.Effect
$.Option
$.Either
// ...

The const that ETS defines internally and exports as default will be what the auto-import system picks up on. So for example if internally ETS does export default const $ = ... then anywhere in the codebase users can type just three characters:
Now namespace...
module namespace export
$ // autoimport kicks in

import { $ } from '@effect-ts/prelude'

$.<tab> // access to EVERYTHING
$.Effect
$.Option
$.Either
// ...

Identifier Naming
Why $? It is just a convention. We want something distinct and easy to use. At the same time if this usage is designed as the first step in the ramp toward API internalization than we know that its not the primary use-case and just training wheels. So consideration for an ident that isn't useful in other places is also there. Ideas:
$
_
$$

ets
$ets
$$ets

ETS
$ETS
$$ETS

EFF
eff
$eff
$EFF

Tool Module Namespaces
After a while, accessing the API through a single identifier might feel verbose if for no other reason than the extra namespace one has to type through. Instead of $.Effect.<...> users may begin to just prefer typing Effect.<...>
Effect // autoimport kicks in

import { Effect } from '@effect-ts/prelude'

Effect. // access to EVERYTHING inside Effect
Effect.gen
Effect.map
Effect.filter
// ...

Tool Module Namespaces Abbreviated
After a while yet more succinctness may become desirable to experiences users. So singler letter namespaces can be designed. All of these namespaces should be single letters, unless we overflow into 25+ then allow 2. The most common namespaces should be given priority to letters. Lesser used should be given access to unused letters that match their earlier character in their name. Also other conventions can be applied if we know better for certain cases. For example E is for Either while T is for Effect.
E // autoimport kicks in

import { E } from '@effect-ts/prelude/abbreviations'

E. // access to EVERYTHING inside Effect
E.gen
E.map
E.filter
// ...

I think these should come from a sub module so that confusing overlap is avoided. As a user, I want to see one set of the API, not overlapping API sets, e.g. I never want to see the abbreviations and the non-abbrevaitions in the same autocomplete space (autocomplete in import {...} from "@effect-ts/prelude"
Areas for further improvement
I see two things that could significantly improve ergonomics here.

Package name of effect-ts. The @effect-ts packages are confusing because they range in use-case in the hierarchy. The non-scoped privileged package is the perfect entrypoint for consumers, especially newcomers.

import { Effect } from 'effect-ts'

Effect. // access to EVERYTHING inside Effect
Effect.gen
Effect.map
Effect.filter
// ...

Once https://github.com/microsoft/TypeScript/issues/36792 lands <3 <3 <3 then effect-ts can be changed to merge types with module namespaces as is possible with TS namespaces but unlike them WITHOUT LOSING TREE SHAKING SUPPORT <3

Either //autoimport

import { Either } from 'effect-ts'

// use in type position
const foo = (bar: Either) => /* ... */

// access ADT members in type position
const foo = (bar: Either.Left) => /* ... */

// access API members in type position
const foo = pipe(Either.fromOption, /* ... */)

Of course this would apply for the abbreviations too:
Either //autoimport

import { E } from 'effect-ts/abbreviations'

// use in type position
const foo = (bar: E) => /* ... */

// access ADT members in type position
const foo = (bar: E.Left) => /* ... */

// access API members in type position
const foo = pipe(E.fromOption, /* ... */)

Reopening given recent activity

The $ stuff is probably not practical and mostly for discovering the API without losing the current flow. As such maybe there is an alternative solution for this use-case of discovery. But I'm not sure...

Does the effect ts community want a package that includes EVERYTHING? Not just core but also @effect-ts/query etc.?

Does the effect ts community want a package that includes EVERYTHING? Not just core but also @effect-ts/query etc.?
Reason I ask is maybe this shouldn't be prelude (which signals base) but some other name that then takes on exporting all that stuff.
Thanks to tree shaking it seems viabale.
I guess one downside is that the version of such a package would be changing maybe very often.

I think this could be a good idea, we could take effect-ts for that (in the meanwhile I took ownership of the npm package https://www.npmjs.com/package/effect-ts) and if properly structure it could form a good basis for an "always consistent" ecosystem release.
Tree shaking has improved with WP5 so we could use namespace exports export * as X or similar but I think that we would still need to provide alternatives for example import { Query } from "effect-ts" and import * as Query from "effect-ts/query" and import { Request } from "effect-ts/query" and import * as Request from "effect-ts/query/request"

@mikearnaldi personally hate all the naming collisions, I try very hard to hide them in import auto complete for instance, by pushing as much external dependencies to some other package, from there export the things I want, and then use this package as dependency for all other, so that my import sanity remains.
Otherwise an Effect import from 5 different places is just annoying, and especially for new people real DH (devhell).

@patroza seems mostly intellij having fun, how would you propose to structure system & core in a way where no re-export are needed?


Convert the content of our README.adoc into the start of an official spec document

We have been using our README.adoc file as a placeholder for the Concurrency spec doc.
Need to get this converted to official spec doc in a /spec/ folder as the other MicroProfile specs are doing.

Do I understand it correctly that in Opt 53 you blow up if user does the following? Since it violates the rule for default config as qualifier is actually present (...injection point where qualifiers and config annotation are absent.).
@Inject
@NamedInstance("foo")
ManagedExecutor e;

As for Opt 54, I would formulate the last point something like this:

The container creates, per unique name, a new ManagedExecutor instance equivalent to ManagedExecutorConfig() when no ManagedExecutor injection point with given unique name defines custom configuration using @ManagedExecutorConfig.

In order to avoid excessive notions of other qualifiers present on IPs, you could add something like this to spec:
Container provides injectable instances of type ManagedExecutor and ThreadContext for all injection points annotated with either @NamedInstance qualifier or @ManagedExecutorConfig/@ThreadContextConfig annotations respectively, or none of these.
(Although from CDI PoV it is obvious that you won't provide a bean for a qualifier you don't even know beforehand. So I would just discard that altogether and not mention other qualifiers and focus on what spec itself provides.)

Yes, under Option 53, the example you describe is an error case (assuming the foo instance isn't produced elsewhere),

Do I understand it correctly that in Opt 53 you blow up if user does the following? Since it violates the rule for default config as qualifier is actually present (...injection point where qualifiers and config annotation are absent.).
@Inject
@NamedInstance("foo")
ManagedExecutor e;

I've been thinking about how I wrote up Option 54, and I starting to think that my previous representation of it is unfair because I started by trying to make the first and second bullet points match up between both options for a simpler comparison.  However, those two bullet points are biased toward Option 53 because I wrote it up first and then tried to make Option 54 fit.  And this sent us down a path for 54 that causes it to look more complex than it should.
If I abandon that approach, here is another way of stating Option 54 (also omitting discussion about the possibility of other qualifiers), that at least to me, seems much more straightforward conceptually,
Option 54 (revised):

@NamedInstance is a standard CDI Qualifier that identifies the unique name of a ManagedExecutor. Absent @NamedInstance, the unique name is the fully qualified class and field name of the injection point, with . as delimiter.
The container creates, per unique name, a new ManagedExecutor instance, if the application does not produce one.
When @ManagedExecutorConfig annotates an injection point, it customizes the configuration of the ManagedExecutor instance that has the respective unique name. Otherwise, the defaults from @ManagedExecutorConfig() apply for that instance.

The second sentence of bullet point 1 should really be added to both 53 and 54.
Option 53 (revised):

@NamedInstance is a standard CDI Qualifier that identifies the unique name of a ManagedExecutor. Absent @NamedInstance, the unique name is the fully qualified class and field name of the injection point, with . as delimiter.
@ManagedExecutorConfig annotates an injection point for ManagedExecutor such that the container creates a new instance with the specified configuration.
The container creates a new ManagedExecutor instance equivalent to @ManagedExecutorConfig() per injection point where qualifiers and config annotation are absent.

Given this, I am now in agreement that Option 54 can be presented in a clear and concise manner that will be intuitive for users.  I would also like @aguibert to comment on this, who had raised a similar issue in case I am missing anything.

The container creates, per unique name, a new ManagedExecutor instance, if the application does not produce one.
Not sure we need the bit about not producing one if user does.
We simply provide beans (metadata) for all unique names. If user provides their own producer as an enabled alternative, their bean definition (defined as a producer) will be used instead. That's just how CDI works. I think we could just leave it out.

It's fine to omit that if it's obvious to users who know CDI well enough to be defining their own producers.  Although we don't want to force them to use Alternative here.  If they define a producer for the unique name at all, theirs ought to be used.

Using an alternative is the de-facto standard via CDI when you know your container provides the "basic" bean. If you want to replace that, a well known way is to define your own bean which matches the type and qualifiers and use @Alternative to override that.
Other approach users often take is replace it via extension (which they can still do here).
Also note that users can still define their own producers with their custom qualifiers and that won't be affected.
What you suggest is probably doable with yet more CDI extension magic, but doesn't sounds like standard approach to me. I'd say we drop that for 1.0 as you can add that later on without breaking anything as opposed to going your way and withdrawing that behaviour later (that wouldn't be backward compatible). We'll see what people actually do and if indeed this proves useful, then we can add it.

My mental model of ManagedExecutor injection can be described as follows... not sure if it fits exactly with Option 53 or not...

The container provides a single instance of ManagedExecutor for @Default ManagedExecutor injection points, with configuration equivalent to ManagedExecutor.Builder.build()
The container produces an aptly configured ManagedExecutor instance for each @Default ManagedExecutor injection point that is annotated with @ManagedExecutorConfig.
When @ManagedExecutorConfig is used on a ManagedExecutor injection point with one or more CDI qualifiers (such as @NamedInstance), the container will produce an aptly configured ManagedExecutor for all injection points with the corresponding qualifiers.

To me this seems straightforward because it can be fully described in terms of injection points, producers, and qualifiers -- concepts that CDI users will already be familiar with.  No mention of unique names and how they get synthesized.

For option 54, this does not seem completely true:

@NamedInstance is a standard CDI Qualifier...

With this option, @NamedInstance has special meaning and can only be processed by the container -- it cannot be used by app-defined producers, so it's not a standard CDI Qualifier.
The config annotation is clearly for container use only, but the @NamedInstance annotation is a CDI qualifier (provided for convenience by the spec), so I think it would be best if the spec did not impose extra restrictions on it.
Regarding this statement:

The container creates, per unique name, a new ManagedExecutor instance, if the application does not produce one.

Not sure we need the bit about not producing one if user does.
We simply provide beans (metadata) for all unique names. If user provides their own producer as an enabled alternative, their bean definition (defined as a producer) will be used instead. That's just how CDI works. I think we could just leave it out.

I think it's important that the container does not interfere with scenarios where neither @NamedInstance nor @ManagedExecutorConfig are being used.
For example, I would hope the container doesn't interfere with this scenario...
public class MyBean {
  @Produces
  @MyQualifier
  public ManagedExecutor produce() { /* ... */ }

  @Inject
  @MyQualifier
  ManagedExecutor injected;
  // 'com.foo.MyBean.injected' name is synthesized here by the container
  // Does the container try to produce this and does it interfere with the app-defined producer?
}

As long as the container doesn't interfere with the above scenario, I would be OK with Option 54.

With this option, @NamedInstance has special meaning and can only be processed by the container -- it cannot be used by app-defined producers, so it's not a standard CDI Qualifier.

It can be used as qualifier in your own producers.
@Inject
@MyQualifier
@NamedInstance("foo")
ManagedExecutor me;

Even in this case the container doesn't need to interfere and you can do that. Or you can override container provided bean as follows:
@NamedInstance("foo")
@Produces
@Alternative
@Priority(x)
public ManagedExecutor createME() {...}

As long as the container doesn't interfere with the above scenario, I would be OK with Option 54.

Yea it won't interfere. It should only care about cases where there is config, NamedInstance, both or none of them + no other qualifier.

Sounds good to me, lets go with option 54

This latter interpretation of option 54 unfortunately compromises away everything I've been asked to represent by the subject matter experts within my own company with regard to CDI-based configuration for this spec.  There are two opposing viewpoints here, both from experts who know far more about CDI than myself, and I've been trying to bring both toward some sort of compromise.
The first viewpoint, which is well-represented in the various discussions, favors an approach where the container creates instances of ManagedExecutor based on injection points that are annotated with configuration detail (@ManagedExecutorConfig).
The second viewpoint, from my own company's subject matter experts, which I've been struggling to adequately represent, is that CDI injection points are an improper place to specify configuration detail, and that we should instead solve the problem of custom configuration (as well as sharing) with simple copy/pasteable examples of writing a CDI producer that leverages a spec defined qualifier (@NamedInstance).
Specifically, this means the following patterns must be possible:
@Produces @NamedInstance("exec1")
ManagedExecutor createExec1() { return ManagedExecutor.builder().maxAsync(5).build(); }

@Produces @NamedInstance("exec2")
ManagedExecutor createExec2() { return ManagedExecutor.builder().propagated(ThreadContext.SECURITY).build(); }

@Inject @NamedInstance("exec2") ManagedExecutor executor;

My efforts to merge these two approaches together into a compromise solution at first seemed successful. However, our attempt to write it up in the spec has revealed that we were never entirely on the same page about exactly what the compromise solution is.  Option 54 as I most recently wrote it up (including the language "if the application does not produce one") compromises as much away as I possibly could without completely abandoning every one of the goals that I was asked to represent by my company's own experts in the area.  With further concessions beyond this point, the spec becomes entirely aligned with one side and in opposition to the other.  If that happens because I'm completely outvoted, we need to seriously consider whether @NamedInstance should even remain in the spec, because the purpose for which it was wanted in the first place is being eliminated.

On this week's MP Concurrency call, we came up with the resolution of using pull #54 but updating it with the requirement from pull #53 that @NamedInstance is a standard CDI Qualifier that can be used by application-defined producers without needing to specify Alternative.


Fix links

Solves #54

Codecov Report
Attention: Patch coverage is 93.33333% with 1 line in your changes missing coverage. Please review.

Project coverage is 89.92%. Comparing base (a227b93) to head (a51d6e8).

Files with missing lines
Patch %
Lines

src/lib/nostr.js
92.85%
1 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #56      +/-   ##
==========================================
+ Coverage   87.79%   89.92%   +2.13%
==========================================
  Files           8        8
  Lines         680      675       -5
==========================================
+ Hits          597      607      +10
+ Misses         83       68      -15

Flag
Coverage Δ

89.92% <93.33%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

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


exclude "Tutorials" repo from component lists

Why? We use this currently in the dropdown.

it was called when run bin/stats.php, seems working ok now. Closing


pwsh does not support -Command positionals, is incompatible with intended set shell and positional-arguments usage

Looking through various issues, I see a misunderstanding of how pwsh -Command accepts positionals.  Unfortunately, it appears to accept them but actually does not (explained below) which makes it incompatible with the intended usage of set shell and set positional-arguments.
PowerShell Core · Issue #1554
Make positional-arguments default to true next edition · Issue #1367
https://github.com/casey/just/issues/1050#issuecomment-997454354

and powershell doesn't like unused positional arguments.

That assessment is perfectly understandable, but the truth is a bit different.  powershell -Command does not accept positional arguments at all!  Rather, it interprets all positional arguments as being parts of a single command.
A summary of the issues:

positionals are not available by any means.  pwsh equivalent to $@, $args, is empty
positionals are part of the command, are eval'd as powershell syntax (this extends beyond simple issues with the dollar sign)
empty positionals are dropped
workarounds do not solve the above, and also make recipes non-portable (worst of both worlds)

Bash example for comparison
When we do:
$ bash -c 'echo $1' foo bar baz
bar

bash is (roughly) executing "echo $1" as if it were a script named foo passed 2 positionals: bar and baz
$0 is foo
$1 is bar
$2 is baz
$@ is a bash array containing bar and baz
There is clear separation between the command and the positionals.
$ bash -c 'printf "<%s> " "$@"' foo bar baz
<bar> <baz>

$ bash -c 'echo ${#}' foo bar baz
2

because the length of the $@ array is 2.
Powershell is not like that
Powershell does not behave like bash at all.  To illustrate, we'll do the exact same thing we just did in bash, ported to powershell, replacing ${#} with powershell equivalent $args.count:
$ pwsh -nologo -noprofile -command 'echo $args.count' foo bar baz
0
foo
bar
baz

Powershell does not put foo bar baz into an args array and pass it to the script.  Rather, the positionals are part of the command.
So it executes this line of code: echo $args.count foo bar baz
This means powershell is not compatible with intended usage of positional-arguments, unless you want the recipe name and all positionals to be evaluated as powershell syntax.
To get behavior akin to bash, you might try wrapping your command in a script block, making your recipe incompatible with bash:
This powershell syntax:
& { echo $args.count } foo bar baz

will output 3 because positionals after the script block have been passed to the block as $args, equivalent to $@
Note that this still breaks for empty strings.
$ pwsh -nologo -noprofile -command '&{echo $args.count}' '' '' '' 'fourtharg'
1

It also evaluates everything as powershell syntax, because it is all part of the command.
$ pwsh -nologo -noprofile -command '&{echo $args}' '' '([environment])' '' 'fourtharg'

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     False    Environment                              System.Object
fourtharg

or passing to an external executable:
$ pwsh -nologo -noprofile -command '&{node -p process.argv @args}' '' '([environment])' '' 'fourtharg'
[
  '/home/cspotcode/.volta/tools/image/node/18.15.0/bin/node',
  'System.Environment',
  'fourtharg'
]

A more concrete example:
# justfile for a python project
set shell := ["pwsh", "-nologo", "-noprofile", "-command"]
set positional-arguments
test *args:
  pytest foo

$ just test --ignore-glob='*{disabled,skipped}*'
pytest foo
ParserError:
Line |
   1 |  pytest foo test --ignore-glob=*{disabled,skipped}*
     |                                          ~
     | Missing argument in parameter list.
error: Recipe `test` failed on line 4 with exit code 1

This isn't necessarily a bug in just, but I think it's worth understanding.  It might mean changes in the README, or it might mean that positional-arguments cannot become default behavior until just is able to execute commands without going through a shell.  This would be similar to how make invokes commands directly, not calling out to a shell.  Funny enough, after wrestling with these issues, I'm feeling like make is a more reliably option on Windows, since I can scoop install make and write cross-platform makefiles, no need to deal with shell issues.  I would much prefer using just, of course!
yarn, a nodejs package manager, uses its own bash-like shell implementation to execute build scripts.
https://github.com/yarnpkg/berry/tree/master/packages/yarnpkg-shell#yarnpkgshell

Yarn uses a bash-like portable shell to make package scripts portable across of Windows, Linux, and macOS

Not suggesting just should go that far, but it would be nice if there were better ways to avoid dealing with a shell at all.

First, thanks for looking into the issue so deeply. It is much appreciated. 😃
But make does use the shell. The Scoop install of make likely just includes a Bourne/POSIX shell with it. You could simply use Scoop to install a Bourne/POSIX shell, Cygwin, MSYS, Git Bash, etc. for your cross platform experience. When I have to actually do long term dev on a Windows box I install Git Bash anyways so done deal on those rare cases (for me). Or I use PowerShell by default because I regularly need to use Just on Windows systems but do the lion's share of dev on macOS. So I install PowerShell Core on my Mac and use PowerShell Desktop already installed on the Windows systems. In any case cross-platform is, unfortunately, a weakness for both tools.

But make does use the shell.

I stand corrected, you're right.

For open-source, I need a justfile that will work for most strangers wanting to contribute.  My goal is to create a justfile that will work with zero or minimal effort, and hopefully zero modification since it's versioned by git.

You could simply use Scoop to install a Bourne/POSIX shell

Do you know of one on scoop?  I can't find one.  It doesn't have sh or zsh, and I can't use bash since that's already claimed by WSL2's shim.  And it needs to invoke Windows tools, not Linux, so calling into WSL won't work.
I think Git for Windows doesn't put the bundled sh.exe onto PATH by default(?), so most people won't have it there.  I can almost assume it'll live at C:\program files\git\bin\sh.exe and hardcode that into the justfile.  Won't work for Github Desktop users; they'll have to modify the justfile and be careful not to commit the change.
I tried a conditional set shell where I check a couple well-known locations for sh.exe, but that seems not to be supported.

I'm pretty sure Git for Windows/Git Bash does put their sh.exe in the PATH on install. Or maybe that's an install option?
Open Source Projects, that is a tough one...

make is likely your best bet if you're really trying to help users avoid installing project dependencies as they will likely have that already installed for most platforms and is likely on Windows just from other projects.
just is very popular. I have no idea what the numbers are but seems to be up there, so they may already have it. If not the extra step of installing a shell becomes the issue. But they are likely to have Git for Windows/Git Bash or Cygwin, MSYS, etc. already installed or will need it installed for other open source projects as well.
True cross-platform task/command runner. Not likely to support a make like experience. May be configuration only and no scriptability. Less likely to already be installed? Once again I don't know any theoretical numbers on this. Just a guess.

I was about to create my own make-alike when I found Just. It covers most of my bases but there is simply nothing that is like Just and truly cross-platform without also needing to install a scripting language as well such as Node, Ruby, PowerShell, Python, etc. The one task runner to rule them all doesn't exist yet to my knowledge. But Just does have plans to eventually have Python 3 built in. At that point it will be the unstoppable!

Or maybe that's an install option?

Yeah, it's an option with Git for Windows.  Github Desktop doesn't offer the option.

If not the extra step of installing a shell becomes the issue

For open source, the issue is mostly 4 factors:

documentation: can they easily google how to set it up?
support: I can't offer support if they get confused
time it takes to install: if it takes too long, they'll decide it's not worth contributing to the project
risk it will fail: e.g. if it requires mucking with env vars.  Installs should be mistake-proof

Asking someone to install just is good per these criteria, because the process is well documented, fast, and reliable: get scoop, install just, done.
They probably already have git for windows, but without sh on the path.  The issue is, if someone googles "How do I get sh for this justfile?" they should find something.  The just readme says "On Windows, just works with the sh provided by ..." which is technically true, but likely to fail without additional setup.

To be honest if the setup is too tough for a developer then they may not be qualified to contribute. That is a very broad over simplification of course. And eliminating all reasonable barriers to entry should be a goal. But it is tough if the project isn't POSIX only or Windows only. The simple confusion of mixed platform parts (Windows batch files and POSIX shell scripts, etc.) can be very confusing to many who've only ever had experience with one platform. No matter what platform that is. It really is a tough problem.

To be honest if the setup is too tough for a developer then they may not be qualified to contribute.

Or if they're qualified then they can spend their time on any number of projects, and may focus on one with a smoother on-ramp.  You have to make things smooth for people if you want them to contribute.

I completely agreed with you when I said

And eliminating all reasonable barriers to entry should be a goal

@cspotcode Thanks so much for explaining this in depth! It sounds like it would be pretty hard to provide useful and consistent behavior for powershell. It sounds like, for powershell, we would need to both pass arguments to command blocks, and quote them:
& { echo $args.count } "foo" "bar" "baz"

I’m not entirely certain I’ve understood correctly, but it seems to me that script blocks like the one in your example would be enough to provide consistent behaviour; only the arguments need to be escaped for PowerShell, which means adding backticks before a fixed set of characters. That would provide the correct list of arguments and count within the block as well as avoid evaluating each argument as PowerShell.


Advent of code - Day 1 -> 15

More examples with the problems from Advent of Code, day 1 to day 15.

this is nice

move to contrib and pass the tests

I think that the code is in a better place in https://github.com/R4PaSs/advent_of_code_2016
I can even add it as an oot project


Configuring to avoid only unresolvable conflicts

Currently I am using eslint-config-prettier, but after discovering prettier-eslint I'm imagining it would be nice to let style defaults from eg Airbnb override prettier. However, my concern is that if I remove eslint-config-prettier then go the route of prettier then eslint --fix, that there may be some things that eslint won't fix but will error on, which if I try to change prettier would just revert, leaving me stuck.
First off, is this even a realistic concern to begin with? If so, could eslint-config-prettier expose a config which only disables rules which could create this situation? Or could I get the same effect by requiring this config directly and just keeping the rules disabled that can't be auto fixed (ie, removing the changes to rules that can be auto fixed so that my configuration can take precedence)?
Let me know if I'm completely off base here. Thanks in advance for any guidance.

Maybe you want https://github.com/prettier/eslint-plugin-prettier with:
{
  "extends": ["plugin:prettier/recommended"]
}

That just winds up enabling this config, yeah? Which doesn't really address my question...

prettier is just opinionated, maybe you want https://github.com/prettier/prettier-eslint
Please don't post question as issue next time.
https://github.com/prettier/prettier/discussions is for questions.

Oh, sorry! Missed discussions since I've been on mobile... I'll move there for further followup


adding quay image expiration label to image build options

Changes introduced with this PR
Implementing quay expiration as an automatic label for plugin images. This will allow us to automatically set the expiration date to "never" which means they will never delete in quay.  When the template-python repo is updated with changes to the carpenter build and push files, it will split the build steps between branches. This will allow us to overwrite this field of "never" for a chosen time such as 90 days for development branches similar to the image name or version in the carpenter build and push yaml files of the plugins.

By contributing to this repository, I agree to the contribution guidelines.

I have left this as a draft as there is a big PR out by @mfleader for carpenter. This will likely need to be rebased and worked through after that is merged. I wanted to start the conversation of how I am integrating this enhancement though. Any feedback would be welcomed.

To see the quay expiration label being utilized please reference my pr for the template-python dir https://github.com/arcalot/arcaflow-plugin-template-python/pull/14/files