fix(PeriphDrivers): Fix Pulldown/Pullup Configuration for ME30

This commit updates MXC_GPIO_Config according to GPIO hardware design
Pull Request Template
Description
Please include a summary of the changes and related issues. Please also include relevant motivation and context.
Checklist Before Requesting Review

[x] PR Title follows correct guidelines.
[x] Description of changes and all other relevant information.
[ ] (Optional) Link any related GitHub issues using a keyword
[ ] (Optional) Provide info on any relevant functional testing/validation.  For API changes or significant features, this is not optional.

PR Title Guidelines
The MSDK repo follows a custom rule set based on the Conventional Commits standard. The pull request titles will follow this format:
type(scope)<!>: Subject
Types
The list of possible types are:

fix – a bug fix has occurred
feat – a new feature was introduced
chore – changes that do not relate to a fix or feature, or a catch-all type for changes that don’t really fit under any of the other types
refactor – refactored code that neither fixes a bug nor adds a new feature
docs – updates to documentation
style – code styling changes (linter or clang-format)
test – changes involving test code (not changes like deleting a line of code to test if your application works or not)
perf – performance improvements
ci – changes related to continuous integration
build – changes that affect the build system, toolchain, or any other external dependencies
revert – reverts a commit

Appending an ! at the end of the title prefix signifies the PR is a breaking or major change. The <!> is optional in the PR format.
NOTE: The type is case-sensitive and must match one of the listed types.
Scopes
The scopes are dependent on the changes based on their location in the MSDK. The list of possible scopes are:

BLE – Any Bluetooth related changes (i.e. Cordio)
Documentation – Any changes in msdk/Documentation folder
Examples – Any changes in msdk/Examples
Tools – Any changes in msdk/Tools
Boards – Any board file changes
CMSIS – Any CMSIS/Register file changes
MiscDrivers – Any MiscDrivers changes (e.g. TFT Display, PB, LED, External Flash Drivers)
PeriphDrivers – Any changes in msdk/Libraries/PeriphDrivers
ThirdParty – Any third-party library changes (e.g. FreeRTOS, LVGL, lwIP)
MAXUSB – Any MAXUSB changes
SDHC – Any SDHC changes
Build – Any changes involving the build system
ignore – Small and quick miscellaneous fixes (should not be used often)
workflow – Any GitHub workflow-related changes
Other – Any changes that may not fit in the other scopes

NOTE: The scope is case-sensitive and must match one of the listed scopes.
Subject Rules

Use the imperative mood in the Subjects - meaning the tone of the Subject should be like giving an order or request.
The Subject should have useful and concise wording.
The Subject should include what parts are affected in numerical order, if any. Only the parts’ CHIP NAME should be used in the Subject. No die names are allowed.
If the PR title is related to a Jira ticket or an issue, the Subject should begin with the ticket designation.
The first letter must be capitalized and the subject must not end with any punctuation.

More Info
Please refer to the CONTRIBUTING.md for more information regarding the PR Title.

@sihyung-maxim should we merge this into main or feat/ME30?

Thanks @mertekren, just need to format and lint
Done thanks

Target branch shall be feat/ME30 not main.
And description shall be cleared, remove template description.

Agreed. Target branch should be feat/ME30.

Note: i couldn't test this, there's no hardware for the test. (pulldown/pullup is not supported in fpga as I was informed)


[WIP] add AppVeyor badge

@DonnchaC
Could you provide URL of badge from page https://ci.appveyor.com/project/DonnchaC/oniongateway/settings/badges please? I do not have access to it.

@starius  The badge URL is https://ci.appveyor.com/api/projects/status/i98wvpauvnrbvemw

Fixed.

Travis failure

main_test.go:32: Mismatch in bytesRead. Expected 3, got 2

has nothing to do with this PR. Probably it is fixed in #4


sd card write and MongoDB logging

Right, I don't think I've uploaded the new code to the test demo yet.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-10.2%) to 56.55%

Totals

Change from base Build<PHONE_NUMBER>:
-10.2%

Covered Lines:
216

Relevant Lines:
353

💛  - Coveralls


Docs: "Read more about FocusZone." leads to 404

Bug Report
The "Read more about FocusZone." link in the https://stardust-ui.github.io/react/accessibility#focus-zone docs leads to a 404 link: https://stardust-ui.github.io/focus-zone
As do the "read more" links for Focus Trap Zone and Auto Focus Zone
Version
0.29.1

Will be fixed by #1283.


Jd tests

Added more boost tests.
Cleaned up the API.cpp file, so all lines are less than 80 characters for the most part, plus changed some styling. Pretty much follows cpplint now.
Added method names to error calls, makes debugging easier so you know where an error is coming from.

In the future, will make functions for the error checking, since I noticed I repeat the same checks for HTTP codes and for empty values (email / contributor key / project ID / etc).
Will also work on adding a few more API calls, like editing datasets.

@stowellm I made the changes you suggested.

Good to pull!  Great job, this code looks awesome.


BackendData provider fix

Summary
Fixes a small bug in the provider method of BackendData which causes integration tests to fail
Details and comments

Where is the actual AttributeError because I don't see that in the failing job logs here:
https://github.com/Qiskit/qiskit-experiments/runs/7665408639?check_suite_focus=true

Where is the actual AttributeError because I don't see that in the failing job logs here:
https://github.com/Qiskit/qiskit-experiments/runs/7665408639?check_suite_focus=true

I'm guessing that's the cause of this?

qiskit_ibm_experiment.exceptions.IBMApiError: 'Failed to process the request: The server responded with '400 Client Error: Bad Request for url: https://resultsdb-dev.quantum-computing.ibm.com/experiments. {"errors":["hub_id is required","group_id is required","project_id is required"]}''

which then causes cascading failures saving plots (why does qiskit-experiments try to save a plot if it fails to save the experiment, it should know that won't work - maybe that's latent behavior though):

qiskit_ibm_experiment.exceptions.IBMExperimentEntryNotFound: 'Figure hello_world.svg creation failed. The server responded with \'404 Client Error: Not Found for url: https://resultsdb-dev.quantum-computing.ibm.com/experiments/a44aff49-7d50-4e11-ab72-31549d32b985/plots/upload/hello_world.svg. {"errors":["Experiment a44aff49-7d50-4e11-ab72-31549d32b985 is not accessible"]}\''

Where is the actual AttributeError because I don't see that in the failing job logs here:
https://github.com/Qiskit/qiskit-experiments/runs/7665408639?check_suite_focus=true

The source of the problem was in the way BackendData attempted to get the provider from a BackendV1 object. It should have used the provider() method and did not, resulting in the function returning None and disabling the automatic setting of hub/group/project from the backend, leading to create_experiment() failing and leading to the other errors.


代码跑不起来  AlipayZeroSdk:1.1

Could not resolve moe.feng:AlipayZeroSdk:1.1.
Required by:
project :app
Could not resolve moe.feng:AlipayZeroSdk:1.1.
Could not get resource 'http://repo.spring.io/libs-release/moe/feng/AlipayZeroSdk/1.1/AlipayZeroSdk-1.1.pom'.
Could not GET 'http://repo.spring.io/libs-release/moe/feng/AlipayZeroSdk/1.1/AlipayZeroSdk-1.1.pom'. Received status code 401 from server: Unauthorized
Could not resolve moe.feng:AlipayZeroSdk:1.1.
Could not get resource 'https://jitpack.io/moe/feng/AlipayZeroSdk/1.1/AlipayZeroSdk-1.1.pom'.
Could not GET 'https://jitpack.io/moe/feng/AlipayZeroSdk/1.1/AlipayZeroSdk-1.1.pom'.
Connect to jitpack.io:443 [jitpack.io/<IP_ADDRESS>, jitpack.io/<IP_ADDRESS>] failed: Connection timed out: connect

mistake

v2版本已重构


Language Server: implement textDocument/definition , textDocument/declaration, textDocument/references

This will require the project set-up to know which are all the relevant files to pull symbol information from #1188
For this, we then need to build a symbol table (and fix issues in https://github.com/chipsalliance/verible/labels/project-tool ) to have all the relevant information available to know how to find definitions and references of a particular symbol, which is then trivial to implement.

textDocument/definition implemented in #1530


nixos/sddm: add option to set pathes of plugins for theme

Motivation for this change
Some sddm themes need extra qt plugin when loading. And these plugin should be in the path environment variables for sddm. I add a new option to config this.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes

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

[ ] Fits CONTRIBUTING.md.

I found users can add plugins into environment packages so that all them are added into /run/current-system/sw


JAMES-1614 Move SieveRepository to data

Can one of the admins verify this patch?

test this please

:+1:


How to use middleware with multiple auth provider?

Q
A

Bug?
no

New Feature?
no

Framework
Laravel

Framework version
7.x.y

Package version
3.x.y

PHP version
7.x.y

Actual Behaviour
I wrote about two service providers，then set to config/api.auth,
'auth' => [
        'custom' => App\Providers\ApiAuthProvider::class,
        'admin => App\Providers\AdminAuthProvider::class
  ],

now, I want to use admin, but how to use middleware? Use api.auth middleware?

Can you please clarify what you mean?
If you are asking how can you use this list of auth providers, then yes it is by using the api.auth middleware as you mentioned. For example, put all authenticated routes under a group with this middleware like so:
    $api->group(['middleware' => ['api.auth']], function (Router $api) {
    });

Can you please clarify what you mean?
If you are asking how can you use this list of auth providers, then yes it is by using the api.auth middleware as you mentioned. For example, put all authenticated routes under a group with this middleware like so:
    $api->group(['middleware' => ['api.auth']], function (Router $api) {
    });

Thank you！My mean is that I want to use AdminAuthProvider, because of some interfaces need to use AdminAuthProvider, other interfaces need to ApiAuthProvider。So How to differentiated to use different of provider.

Can you please clarify what you mean?
If you are asking how can you use this list of auth providers, then yes it is by using the api.auth middleware as you mentioned. For example, put all authenticated routes under a group with this middleware like so:
    $api->group(['middleware' => ['api.auth']], function (Router $api) {
    });

Thank you！My mean is that I want to use AdminAuthProvider, because of some interfaces need to use AdminAuthProvider, other interfaces need to ApiAuthProvider。So How to differentiated to use different of provider.


Documentation body text is hard to read

Issue Type
[x] Bug
[ ] Feature Request
Priority
[x] Minor
[ ] Major
[ ] Critical
[ ] Blocker
Environment

OS: Arch Linux
Browser: Chromium

Description
As much as I love the Raleway typeface, it was designed as a display typeface for headlines and such, and is much too thin to be used as body text. Combine this with the pale base colour of #333, and the result is needlessly hard to read.  And that's for someone with decent eyesight.
A straightforward fix would be to use one of the heavier Raleway weights. Alternatively, switch to a typeface more suited for body text; from Google Fonts's suggestions, Open Sans, Lato and Montserrat are all suitable.

I wasn't able to reproduce this issue with Chrome, Firefox or Safari on macOS. For me, the website looks exactly the same as for @janpio. Text in the documentation body does not seem to be low-contrast.
You may wanna check if this has been reported as a bug in Chromium issues list. They could have some unexpected rendering issue on their end.
However, I've ran Lighthouse audit and noticed that some of h2, a and span elements do not have a sufficient contrast ratio and might difficult or impossible for many users to read.

I have since encountered this on several other sites. It's definitely a Chrome issue, although I couldn't find any actual bug report. This StackOverflow thread seems to be about a different issue, which was fixed years ago.
I wonder if Chrome isn't actually doing the right thing here and all the other browsers are wrong. Raleway is, after all, very thin, so it makes sense to make lines lighter than #000 if they are less than a pixel wide.
Regardless of where the blame lies, this can probably be fixed in Cordova docs with a few well-placed lines of CSS.

The contributor that built that site is most probably not around any more.

I’m around, and I watch. :) @janpio Not sure I understand the problem though. Is it just to make the font bigger?

@dblotsky No, it's to use a different font for body (paragraph) text. Raleway is fine for headings and such, but it was never designed for large text blocks.

@ttencate which font do you propose instead of Raleway for the body of text in the docs?

@ttencate @GedasGa @janpio for reference, this is what my page looks like in Safari.

@dblotsky The really thin Raleway seems to be a Chrome + Linux issue. Suggestions for alternative fonts are in the original issue report.

@ttencate would you like to propose a PR with a higher font weight here, and post screenshots of the result on Chrome + Linux, and on other platforms?

I was going to do that, but instead I stumbled upon the root cause of the issue. My system has a version of Raleway installed that already contains "weight 400", but with much lighter contents. Perhaps this is the "original" Raleway, rather than the 2012 multi-weight remake. And for weight 400, this takes precedence over the Raleway hosted by Google Fonts. This leads to the strange situation that both 300 and 500 look heavier than 400 on my system (and both are quite readable).
To fix this, we'd need to force the browser to use the web font. Here's how we can do this: give the font in the @font-face rule a custom name, so it doesn't match anything that might be installed on the user's system. To do that in Cordova Docs, we'd need to copy the CSS that Google serves up (carefully, because they do browser detection).
Because that CSS points to WOFF files etc. whose URLs might change (unlikely but possible), we might also want host the fonts ourselves; here's how to download them.
I can make the PR, but I need some input: do we...

... host the fonts ourselves, incurring extra traffic, as well as browser cache misses because many folks will have Google's fonts cached, or...
... hotlink the font files from Google, with the slight risk that the URLs stop working at some point?

Confirmed: I uninstalled the Arch Linux AUR package otf-raleway (because it also made other sites unreadable) and it has resolved this issue for me.
The solution outlined above could still be applied, but if I was the only one complaining then it's not worth the trouble.

Thanks for finding the root cause of the issue, @ttencate!

No one has complained since 2019, and I don't encounter the same issue on Ubuntu 20, so I'll be closing this issue.


Add Istio into addons

Feature Request

Add CNCF Project Istio into Tanzu Packages
Describe alternatives you've considered
Regarding to Istio has applied to become one of CNCF projects, as a Tanzu Community Edition developer, we may need to use Istio  on TCE or TKG in the future.
Additional context

Istio has applied to become a CNCF project
Support status of Istio releases

It is better to support 1.13 because EOL issue.


⚠ Rumah123 has degraded performance

In a07a90b, Rumah123 (https://www.rumah123.com) experienced degraded performance:

HTTP code: 200
Response time: 5336 ms

Resolved: Rumah123 performance has improved in d9a0b81 after 12 minutes.


Parse IDL while has default value will throw exception

idl code as follow:
"package tutorial;" +
"option java_package = "com.example.tutorial";"
"option java_outer_classname = "AddressBookProtos";"
" message PhoneNumber {"
"required int32 number = 1 [default = 1];"
"}";
while call field.getDefault(); will throw cast exception due to integer can not cast to String
public String getDefault() {
  Option defaultOption = Option.findByName(options, "default");
  return defaultOption != null ? (String) defaultOption.getValue() : null;
}

test version 3.1.5

This has been fixed on master and we're hoping for a 4.0.0 release this month! Sorry about the trouble, I believe 3.1.4 should work if you want to downgrade to it temporarily.


Re-export engine creation function

I was really interested about this backend-agnostic wasm api idea, but I was kind of thrown back when I noticed this line in the example:
let engine = Engine::new(wasmi::Engine::default());

This is kind of bad, because I have to add wasmi to my dependencies, making it less "backend agnostic" then I would like. Ideally, if only one backend feature is selected, it should be possible to "just create the engine" and not care about from which backend that engine comes from.
If I then want to change the backend from wasmi to wasmtime, for example, I should be able to just replace the feature flag in my Cargo.toml and not touch anything else, and it should just use the new backend. That is the truly backend-agnostic way.
However, there are situation when that is not desired. You could, for example, want both backends at the same time, each for a different module. Activating both features and "just creating the engine" in this way would obviously not work, you would have to specify which engine you want.
But there is a better way. Instead of adding the backend dependency to your Cargo.toml and doing god-knows-what to hunt for the correct version for it, you could just re-export the engine creation methods. So for example, instead of wasmi::Engine::default() you would write wasm_runtime_layer::wasmi::Engine::default(). You are still "choosing" the wasmi backend, but without the need to add wasmi to your dependencies.
But returning to the "just make the engine" approach, if exactly one backend feature is active, it would be nice to be able to do just Engine::default() and have it work with that backend.

For example, here I need to do this annoying "function fork" depending on target:
#[cfg(not(target_arch = "wasm32"))]
fn get_engine() -> impl backend::WasmEngine {
    wasmtime::Engine::default()
}

#[cfg(target_arch = "wasm32")]
fn get_engine() -> impl backend::WasmEngine {
    web::Engine::default()
}

It's not the end of the world, but it would be better if there was one single function that would work with any engine.
Also, I don't know if this is related or not, but the sys (non-wasm) version of the code doesn't work. I get an the trait 'WasmEngine' is not implemented for 'wasmtime::Engine' error message, even though I wrote the code based on one of the test examples.
This could be becase it doesn't work with wasmtime version 16, which, again, how I am supposed to know which versions of wasmtime it works with and doesn't work with? If it simply re-exported wasmtime, I could use wasm_runtime_layer::wasmtime and have a 100% guarantee that I am using the correct version.

Hey @kajacx, thanks for the feedback. This is helpful and I appreciate your perspective. There are a couple reasons that the API is designed the way that it is.

First off, it's impossible to implement Engine::default since Engine is a generic type, and the user would be required to specify it. But it would be possible to create a fn default_engine() -> impl WasmEngine to do the same thing.
However, this breaks the rule that features should be additive. The Cargo book states that "enabling a feature should not disable functionality, and it should usually be safe to enable any combination of features." Imagine this: you are using wasm_runtime_layer with the backend_web crate, so the default engine functionality is available. Now, one of your dependencies releases a Semver-compatible update which also pulls in wasm_runtime_layer and enables another backend. This causes your code to no longer compile. Overall, I don't think that the extra convenience of a default implementation is worth allowing situations like this.
So that leaves us with re-exportation. The reason that the end-user is required to manually bring in a dependency is because I wanted them to be able to specify and control the backend crate version themselves. If you look at the project's Cargo.toml, the wasmtime and wasmi crates only have a minimum version specified. This gives increased flexibility to the end user. Albeit, this does come at the expense of future updates to wasmtime or wasmi breaking things, so maybe we should specify the version.

For the reasons detailed above, I don't think that I want to introduce a default implementation. I am open to adding re-exports, but I still think it's good to have the user manually specify/import the backend crate version themselves since this crate does not impose strong version requirements. What do you think?
Regarding your trait implementation example, that's very surprising. I will clone your wasm-playground example and take a look.

I am able to build wasm-playground/host just fine on Windows. I would recommend checking cargo tree -p wasmtime and running cargo update -p wasmtime if there are multiple versions of it in your project.
I guess maybe the best thing to do would be to have multiple feature flags (like wasmtime_0_16 and wasmtime_0_17) so that it's clear to the end user what version is being re-exported and the user still has version control. Would this solution be acceptable to you @kajacx?

You are right about the additive features thing. You still can put the engine selection behind feature flags of your own, and then enable wasm_runtime_layer's features based on that as well, so in the end you would still be able to switch which backend you use simply by using a different feature, without changing a single line of code. But that would make your code not feature-additive-proof, unless you prioritize which backend is used in case of multiple features enabled. But that is for the user of the wasm_runtime_layer crate to decide, and not something that should be in the crate itself.
With the "not compiling" example, I deleted my Cargo.lock and target folders, and now it runs fine. The joys of non-reproducible errors.
The "re-export" feature is the one that deserves most consideration. It depend on what is the "philosophy" of the crate. You could:

Make it a complete package with multiple built-in backends that the user can choose from (or add their own custom one)
Make it a "conversion" layer that users can put on top of the backend(s) which they are already using

In the first case, it makes sense to re-export the engine creation methods, so that the users don't have to add anything more to their Cargo.toml files. In second case, it makes more sense to already have the backend in your Cargo.toml anyway and pass that crate's engine to the "conversion" engine.
I personally like the first approach more, the more something works out of the box with minimal configuration, the better.
When it comes to the "users not having enough control over the backend crate", they can still add it to their Cargo.toml and have control over it's version and features, it's just an optional thing they can do if they need that more control, and not something they have to do, regardless of whether they need that extra control or not.

I am closing this issue, because I believe that the main concerns have been addressed in #9 (or, at least, we've chosen the philosophy of the project). Each WASM backend is now its own crate. This has the following advantages:

There will be no more issues with different backend versions or non-reproducible compilation issues. Backend crates are versioned based upon the underlying implementation (for instance, wasmi_runtime_layer has version 0.31.0, which corresponds to wasmi version 0.31.0). This gives the user ultimate control over which backend versions they are choosing.
Each of the WASM backend crates re-export their runtime. So you can do wasmi_runtime_layer::Engine::default() without having to add wasmi itself to your dependencies.

Ultimately, the goal of this project is to facilitate writing libraries like my wasm_component_layer or wings crates, which work with multiple WASM runtimes. Having the user specify which backend they want (wasmi, wasmtime, etc.) seems inevitable to me for building binaries, but libraries can be built agnostically. I think that this approach will best support that goal!


404 when using wildcard gateway with ingress

If you are reporting any crash or any potential security issue, do not
open an issue in this repo. Please report the issue via ASRC(Alibaba Security Response Center) where the issue will be triaged appropriately.

[x] I have searched the issues of this repository and believe that this is not a duplicate.

Ⅰ. Issue Description
Encountering a 404 error when using a wildcard gateway in conjunction with ingress rules. It appears that the wildcard Gateway may be overriding specific non-wildcard ingress rules.
Ⅱ. Describe what happened
When creating a gateway with the following configuration, I intermittently receive a 404 error when accessing specific routes defined by ingress resources.
If there is an exception, please attach the exception trace:
No trace for this behavior.

Ⅲ. Describe what you expected to happen
I expected the wildcard gateway to coexist with the non-wildcard ingress rules without causing conflicts, allowing access to both wildcard and specific routes without resulting in 404 errors.
Ⅳ. How to reproduce it (as minimally and precisely as possible)

Create a Gateway using the following YAML configuration:apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: test-gateway
  namespace: test-gateway
spec:
  selector:
    higress: test-gateway
  servers:
    - hosts:
        - '*.example.com'
      port:
        name: https
        number: 443
        protocol: HTTPS
      tls:
        cipherSuites:
          - ECDHE-ECDSA-AES128-GCM-SHA256
          - ECDHE-RSA-AES128-GCM-SHA256
          - ECDHE-ECDSA-AES256-GCM-SHA384
          - ECDHE-RSA-AES256-GCM-SHA384
        credentialName: test-gateway-certificate
        minProtocolVersion: TLSV1_2
        mode: SIMPLE

Define a non-wildcard ingress rule for a specific host (e.g., test.example.com).
Attempt to access both the wildcard and non-wildcard routes and observe the 404 errors.
restart higress gateway pod every time when you change related to this gateway virtualservices or ingresses .

Ⅴ. Anything else we need to know?
It would be beneficial to understand if there are any existing mechanisms to resolve priority issues between wildcard gateways and specific ingress rules automatically.
Ⅵ. Environment:

Higress version:  1.4.1
OS: Cloud Provider deployed Linux k8s distro (Ubuntu)
Others: works inside istio 1.19.3 mesh

Is istio CRD enabled in Higress?
https://higress.io/docs/latest/ops/deploy-by-helm/#支持-istio-crd可选

Does the selector of your Gateway resource match the labels of the higress-gateway pods? By default, when installed, the label for higress-gateway is higress: {install-namespace}-higress-gateway.

Istio CRD enabled in higress. gateway selector is correct - virtualservices binded to that gateway work as expected, but, if gateway works, then ingress doesn't untill i restart higress pods. looks like after pod reloading the ingresses getting higher priority than wildcard gateway and work as expected.

higress: test-gateway

@nbragin4 Does your higress-gateway pod have this label? Higress standard installation mode does not add this label, did you modify the helm chart to add it yourself? In that case, did you modify anything else?

方便的话，可以进 higress-controller 容器执行以下命令，我确认下控制面的配置:
curl localhost:15014/debug/configz

higress: test-gateway

@johnlanni i redacted sensitive data before submitting issue, it's just redacted sample, original sample consists with higress: {install-namespace}-higress-gateway labeling.

curl localhost:15014/debug/configz

i'll gather debug info when problem shows up again and will send it here. thanks for patience


Superposition of Atomic Potentials (SAP) initial guess implementation for HF-SCF calculations

Added VSAP (superposition of atomic potentials) initial guess implementation for Hartree-Fock SCF calculations (described by S. Lehtola here: https://doi.org/10.1021/acs.jctc.8b01089)
Modified fakemol_for_charges to be usable for SAP 3C2E (three-center two-electron) integrals.
Supplied sap_grasp coefficients computed by S. Lehtola to the basis sets.

@susilehtola do you think this PR good to merge after your comment is addressed?

You also need to

[ ] add the guess to scf/dhf.py
[ ] add the guess to scf/ghf.py
[ ] add the guess to scf/rohf.py
[ ] add the guess to scf/uhf.py
[ ] check the guess works in all of the above
[ ] add an example to examples/scf/15-initial_guess.py

@susilehtola do you think this PR good to merge after your comment is addressed?

@sunqm I am happy with it now, the only question is the role of nbas in the integrals routines. Another question is on how the integrals should be computed.
The $N_{\rm bf}^2$  repulsive corrections to the Fock matrix over the core guess are obtained by tracing out the nuclear index in the $N_{\rm bf}^2 N_{\rm nuc}$ integrals, which are computed all at once; one could also accumulate on the fly, computing the contributions one nucleus at a time. Which is better, in your opinion? I think @Jondesan's code is easy to change either way, since his function already creates the auxiliary basis for an atom at a time; these basis sets are then just concatenated before doing the integrals.

@susilehtola do you think this PR good to merge after your comment is addressed?

@sunqm I am happy with it now ~, the only question is the role of nbas in the integrals routines~.
The only question is how should the integrals be computed. The Nbf2 repulsive corrections to the Fock matrix over the core guess are obtained by tracing out the nuclear index in the Nbf2Nnuc integrals, which are computed all at once; one could also accumulate on the fly, computing the contributions one nucleus at a time. Which is better, in your opinion? I think @Jondesan's code is easy to change either way, since his function already creates the auxiliary basis for an atom at a time; these basis sets are then just concatenated before doing the integrals.

@susilehtola Thank you for the careful review of the PR! I think either way works. There is a small difference in memory consumption, but I think this should not be a problem unless the system has more than 1000 atoms. That is an unusual case that can be considered later.

Please add unit tests for the new initial guess

Added unit tests for RHF, ROHF, UHF, DHF and GHF.


[v0.16.0] Failed to fetch nodes and gpu info

OpenPAI Environment:

OpenPAI version: v0.16.0
Cloud provider or hardware configuration:
OS (e.g. from /etc/os-release): ubuntu16.04
Kernel (e.g. uname -a):
Hardware (e.g. core number, memory size, storage size, GPU type etc.):
Others:

I deploied the k8s version with v0.16.0, but the total gpu count and node number is 0 in dashboard. Actually, There should be 2 gpus and 1 work node.

the hardware page:

Are there any instructions I can follow to check this problem? thanks.

dashboard is obsoleted in 0.16. and this is an internal release.

Ok. When will the official version be released?

@edenbuaa - please stay tune with https://github.com/microsoft/pai/issues/3872, release related info will be posted on top pinned issues like #3872.
BTW, would you mind share more about your org's info (name, deployment scale, how PAI is used, etc.) for our reference? thanks.


Added Room functions and some more

Hi. I have been using your libary to coomunicate with EWS. I have added the functions I peronally needed that was missing, and want to contribute them back to you and everyone that uses the libary.

Is there something wrong with my commit?

These methods and types were added in a different commit that has already been merged into master.


Bottom navigation items disappear when I click a mentors profile

Back button at the top left solved this issue just fine.


service/state: Expose state endpoints via RPC

TODO

Codecov Report

Merging #591 (0c4c13c) into main (1802ecf) will decrease coverage by 1.32%.
The diff coverage is 54.65%.

:exclamation: Current head 0c4c13c differs from pull request most recent head fc668fd. Consider uploading reports for the commit fc668fd to get more accurate results

@@            Coverage Diff             @@
##             main     #591      +/-   ##
==========================================
- Coverage   62.80%   61.48%   -1.33%
==========================================
  Files          92       93       +1
  Lines        5009     4956      -53
==========================================
- Hits         3146     3047      -99
- Misses       1531     1587      +56
+ Partials      332      322      -10

Impacted Files
Coverage Δ

cmd/init.go
80.00% <ø> (ø)

node/p2p/bitswap.go
86.36% <ø> (ø)

node/p2p/host.go
81.25% <ø> (ø)

node/p2p/pubsub.go
70.00% <ø> (ø)

node/p2p/routing.go
66.66% <ø> (ø)

service/share/light_availability.go
91.66% <ø> (ø)

service/state/core_access.go
31.48% <0.00%> (ø)

service/state/rpc.go
5.06% <5.06%> (ø)

node/config_opts.go
36.00% <40.00%> (-6.31%)
:arrow_down:

libs/fxutil/fxutil.go
44.44% <44.44%> (ø)

... and 21 more

Continue to review full report at Codecov.

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


how to get current row number or cell index  in laravel excel

currently i working on excel import , importing excel data to the database , i want to know how to retrieve the current row number because i want to produce some error message like "the name cannot be numeric at 'row 51' or ' A51'  " if that row are wrong data type input   for example

Please show us your code. It's difficult to answer your question without knowing how you're using it.

in simple way, how can i get the name of current cell name,
like getCellName or getCurrentRowIndex / getCurrentColumnIndex ????
any tips ?


result is nondeterministic

Using go-unused on my large project (about 130 packages) the result is nondeterministic. It returns on of two sets of results.

Is it an open-source project that you can share? And if it isn't, are you at least able to share the two result sets?

FTR, I've seen this behaviour, too, but I cannot reliably reproduce it and even dozens of runs are identical. Only very rarely do I get a different, wrong result, that includes exported identifiers that it shouldn't complain about.

Unfortunately the project is not open-source so I am not able to share it with you. I had the same symptoms as you described. Please check my fix.


Docs typos

Address a few typos in the docs.

Well, half the docs refer to "file system" and the other half refer to "filesystem". We have to pick one. It could be "file system" if that's preferred.

Ah. Yea, I agree that consistency would be better.

consistency is great, I think "file system" is a bit more standard English, though "filesystem" shows up as a tech term sometimes.

Not that Wikipedia is the definitive source, but:

In computing, a file system or filesystem...

I think either is fine, let's just be consistent.

Note that after that, wikipedia goes on to use "file system" everywhere in the article, though, because "political system" not "politicalsystem"! . If its tons of work, "filesystem" is fine, but I think its a trivial search-n-replace, might as well go with actual English in our docs instead of technical slang.

Alright, 4964a50 takes care of the "file system"/"filesystem" debate. Any other concerns?

Landed in https://github.com/libuv/libuv/commit/eb8509210df264d30644a93d83d5fbdf5d580231 with the commits squashed and the commit message reworded. Thanks!


Using Formik with Next JS and TypeScript to design a registration page

Proposed title of article
Using Formik with Next JS and TypeScript to design a registration page
Proposed article introduction
Jared Palmer authored the Formik library out of frustration when building React forms. He needed a way to standardize the input components and the flow of form submission. Formik helps you to write the three most annoying parts of building a form:

Getting values in and out of form state
Validation and error messages
Handling form submission

In this article, we will learn how to construct a form using Next, TypeScript and Formik . A simple registration form will be created, and it will undergo some basic validation before being submitted. In React and React Native, you can use the Formik library to create dynamic forms.
Key takeaways

Creating the registration form
Showing errors in the forms using formik.errors
Integrating Formik to a Next project in Typescript

Article quality
In this article we will create a unique project on how to build a registration page using Formik with Next and TypeScript.
References
N/A

Seems like a helpful topic @Terripha Let's ensure that it adds value to the community. Thanks

I'm going to close this issue due to inactivity. It can be re-opened.


Fix validator waiting on start

Currently validator has some recursive method call to wait for chain start.
Solution:

modify rpc/rest client to be event emmiter

rest api will poll x seconds for chain status and on start emit event

validator should listen on start event

I'm working on this.


fix jacoco local report

Change-Id: I9bad46fbc7527df5d59d10023820ee0bb118fa89
from offical documentation
Another way is to define "argLine" as a Maven property rather than as part of the configuration of maven-surefire-plugin:

  <properties>
    <argLine>-your -extra -arguments</argLine>
  </properties>
  ...
  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <configuration>
      <!-- no argLine here -->
    </configuration>
  </plugin>

after the change, jacoco working, output dir traget/site/jacoco

Pull Request Test Coverage Report for Build 508

0 of 0   changed or added relevant lines in 0 files are covered.
598 unchanged lines in 306 files lost coverage.
Overall coverage increased (+0.1%) to 65.939%

Files with Coverage Reduction
New Missed Lines
%

sharding-core/sharding-core-api/src/main/java/org/apache/shardingsphere/api/config/sharding/strategy/NoneShardingStrategyConfiguration.java
1
0.0%

sharding-core/sharding-core-common/src/main/java/org/apache/shardingsphere/core/constant/properties/ShardingProperties.java
1
83.33%

sharding-core/sharding-core-common/src/main/java/org/apache/shardingsphere/core/constant/ShardingConstant.java
1
0.0%

sharding-core/sharding-core-common/src/main/java/org/apache/shardingsphere/core/database/DatabaseTypes.java
1
95.45%

sharding-core/sharding-core-common/src/main/java/org/apache/shardingsphere/core/rule/EncryptRule.java
1
8.06%

sharding-core/sharding-core-common/src/main/java/org/apache/shardingsphere/core/spi/NewInstanceServiceLoader.java
1
90.0%

sharding-core/sharding-core-common/src/main/java/org/apache/shardingsphere/core/strategy/route/complex/ComplexShardingStrategy.java
1
95.45%

sharding-core/sharding-core-common/src/main/java/org/apache/shardingsphere/core/strategy/route/hint/HintShardingStrategy.java
1
0.0%

sharding-core/sharding-core-common/src/main/java/org/apache/shardingsphere/core/strategy/route/ShardingAlgorithmFactory.java
1
50.0%

sharding-core/sharding-core-common/src/main/java/org/apache/shardingsphere/core/strategy/route/ShardingStrategyFactory.java
1
70.0%

Totals

Change from base Build 433:
0.1%

Covered Lines:
10870

Relevant Lines:
16485

💛  - Coveralls


Rotation option

Hello could you add the option and examples of how to rotate images and texts? Thank you.

FYI - this is a quick hack I used to set rotation of e-paper display with @jarek319 EPD215 based on Adafruit documentation:

https://github.com/pdp7/EPD215/commit/f4e22660877759e53a3a83ed35c6e7a54616d285

kicad-teensy-epaper badge:

Landscape mode:

_rotation = 1

Portrait mode:

_rotation = 2

TODO: library should be modified to accept rotation parameter

Thanks @zkarcher the rotate option already wo4ks, only that it presents the ghost effect from time to time.
Video
Picture
@pdp7


video conference mute and virtual camera

Description of the new feature / enhancement
It would be really usefull a virtual screen that could be customized with text. Something able to generate a wallpaper with text filled in the setup menù of the "video conference mute" utility
Scenario when this would be used?
during the break of a conference this feature would be useful to show quick info for the audience
Supporting information
No response

I think there are countless programs that can do this already. Creating this again requires a lot of time and effort we honestly don't have.
(OBS is free and quite powerful, to give a random example)

I'd recommend OBS here, i don't see PowerToys building this utility out.


Validation error message validating from previous value/previous piped value is not as expected

Expected behaviour
Must display a validation error:  Enter an answer less than or equal to £12.00.
On the summary page Total turn over was displayed as £1 but the piped values is displayed as £12
Actual behaviour
Displaying a validation error: Enter an answer less than or equal to £1.00.
Steps to reproduce the behaviour
Login into RRM
click on an RSI 0102 survey which is already in progress where all the questions are answered (not submitted)
In this case Total retail turnover: was £12
Try entering £13 as internet sales
Must trigger a validation error message saying 'Enter an answer less than or equal to £13.00.'
Technical information
Browser
Operating System
Screenshot

@ajmaddaford should this still be open?

This was caused by old data on the answer store. It looks like an answer that had previously been provided was moved to another location. This meant that there were two answers for the same answer id in the answer store.
The reason that different answers are displayed to the user is that validation (https://github.com/ONSdigital/eq-survey-runner/blob/master/app/forms/fields.py#L233) and summary values (https://github.com/ONSdigital/eq-survey-runner/blob/master/app/templating/summary/question.py#L26) take the first answer returned from the answer store filter method whereas piping (https://github.com/ONSdigital/eq-survey-runner/blob/master/app/templating/schema_context.py#L27) takes into consideration the routing path.
While this isn't an issue that should affect respondents (as we don't move answers during collection periods), the application should be more resilient to this. We should discuss:

Not allowing duplicate answer id's in the answer store (unless they are repeating)
Should we error if there are multiple answers returned when we expect one?
What can be done to rationalise getting answers from the answer store e.g. always considering if the answer is on the routing path.

This occurred again recently with a test account. Although it manifested itself differently. A 500 was raised because app.questionnaire.rules.get_answer_store_value explicitly checks if there are multiple values are throws if so.
It seems that we're only experiencing this in test accounts that are holding onto very old data. I can't see how a duplicate answer would ever be able to get into the answer store now as the application only ever calls AnswerStore.add_or_update which will overwrite any existing value.
With that in mind, this seems like something that is unlikely affecting many/any real users.
Perhaps the solution therefore should be to make the code more resilient to this unlikely situation and just take the first result (because all overwrites of the answer will replace the first result).


Filter tri-allelic sites.

Need to ensure that tri-allellic sites get filtered when obtaining data.

Fixed this in the latest version.


Autotests: #3184 S-Group Tool

added 6 tests;
added expected snapshots;
added function 'setAttachmentPoints'

How the feature works? / How did you fix the issue?
(Screenshots, videos, or GIFs, if applicable)
Check list

[ ] unit-tests written
[x] e2e-tests written
[x] documentation updated
[x] PR name follows the pattern #1234 – issue name
[x] branch name doesn't contain '#'
[x] PR is linked with the issue
[ ] base branch (master or release/xx) is correct
[x] task status changed to "Code review"
[x] reviewers are notified about the pull request


PHPCS/Composer: update PHPCompatibility

Composer:

wimg/php-compatibility has been abandoned for over a year. Use phpcompatibility/php-compatibility instead.
Use the latest version of PHPCompatibility.
You were missing out on a lot of new checks, including the checks to make sure your code is compatible with PHP 7.4.
As of PHPCompatibility 8.0, the directory layout of the PHPCompatibility standard has been updated to work correctly with Composer, so no need for the custom scripts moving the files anymore.
Add the DealerDirect Composer PHPCS plugin.
This plugin will handle setting the PHPCS installed_paths automatically.
This also allows for referencing the rulesets by name instead of via the path in the ruleset, which is generally more stable.
Update the minimum PHP version required, which based on commit https://github.com/Limenius/ReactRenderer/commit/5446eee99b36c88a7e4199f838667f7ff8520f70 is now PHP 7.2.

PHPCS ruleset:

Rename the ruleset to phpcs.xml.dist which will allow PHPCS to automatically pick up on it.
No need to pass the --standard=... command-line argument anymore.
Includes removing the argument from the Travis script.
Check for cross-version compatibility for the PHP versions officially supported.
According to the composer.json file, this code should be compatible with PHP 5.5 and above. Based on the above mentioned commit, however, the minimum supported PHP version is PHP 7.2.
PHPCompatibility was checking against PHP 5.5 up to PHP 7.0.
The new testVersion actually checks against PHP 7.2 up to the latest version (7.4 at this moment).

Refs:

https://github.com/PHPCompatibility/PHPCompatibility#sniffing-your-code-for-compatibility-with-specific-php-versions
https://github.com/PHPCompatibility/PHPCompatibility/releases/
https://github.com/Dealerdirect/phpcodesniffer-composer-installer

Additional suggestions:

You may also want to update the Symfony standard dependency which is currently at version 3.10.0 3.11.0
Ref: https://github.com/djoos/Symfony-coding-standard/blob/master/UPGRADE-3.0.md
Note: the ruleset name has been changed in version 3 from Symfony2 to Symfony.
And consider updating (or removing) the PHP_CodeSniffer dependency, of which the latest release is version 3.5.3 3.5.6
I'd suggest removing it as it is not your dependency, but a dependency of the PHPCompatibility and the Symfony coding standards, so let those dependencies manage the version rather than doing that yourself.
Ref: https://github.com/squizlabs/php_codesniffer/releases
Enabling the PHPCS check in Travis would also help.

Note: PHPCompatibility 10.0.0 will be released in the near future and contain quite some code checks related to PHP8.
Some preliminary scan results to be aware of:
FILE: src\Limenius\ReactRenderer\Renderer\AbstractReactRenderer.php
------------------------------------------------------------------------------------------
FOUND 0 ERRORS AND 2 WARNINGS AFFECTING 2 LINES
------------------------------------------------------------------------------------------
 33 | WARNING | Declaring a required parameter after an optional one is deprecated since
    |         | PHP 8.0. Parameter $registeredStores is optional, while parameter $trace
    |         | is required.
 91 | WARNING | Declaring a required parameter after an optional one is deprecated since
    |         | PHP 8.0. Parameter $registeredStores is optional, while parameter $trace
    |         | is required.
------------------------------------------------------------------------------------------

FILE: src\Limenius\ReactRenderer\Renderer\ExternalServerReactRenderer.php
------------------------------------------------------------------------------------------
FOUND 0 ERRORS AND 2 WARNINGS AFFECTING 2 LINES
------------------------------------------------------------------------------------------
 31 | WARNING | Declaring a required parameter after an optional one is deprecated since
    |         | PHP 8.0. Parameter $failLoud is optional, while parameter
    |         | $contextProvider is required.
 56 | WARNING | Declaring a required parameter after an optional one is deprecated since
    |         | PHP 8.0. Parameter $registeredStores is optional, while parameter $trace
    |         | is required.
------------------------------------------------------------------------------------------

FILE: src\Limenius\ReactRenderer\Renderer\PhpExecJsReactRenderer.php
------------------------------------------------------------------------------------------
FOUND 0 ERRORS AND 2 WARNINGS AFFECTING 2 LINES
------------------------------------------------------------------------------------------
 53 | WARNING | Declaring a required parameter after an optional one is deprecated since
    |         | PHP 8.0. Parameter $failLoud is optional, while parameter
    |         | $contextProvider is required.
 94 | WARNING | Declaring a required parameter after an optional one is deprecated since
    |         | PHP 8.0. Parameter $registeredStores is optional, while parameter $trace
    |         | is required.
------------------------------------------------------------------------------------------

Ah thanks! Long overdue, merged. Taking care of the optional parameters problem in a separate PR.

You're welcome.


174/add popout for GitHub and digitalocean oauth

closes #174
changes proposed in the pull request:

Add component for oauth
Store oauth code in cookies
Do async call to services

@thetonymaster

Coverage decreased (-0.7%) to 95.302% when pulling d43a6f6d27a4858f9da38dd897e2d00622b6ef0a on 174/add-popout-for-github-and-digitalocean-oauth into 94f92d3217106509cf65ac027b3d6333caafedeb on master.

Coverage decreased (-0.05%) to 95.918% when pulling 397ab49a495ad4babcb3e37c442d482036c9881b on 174/add-popout-for-github-and-digitalocean-oauth into 94f92d3217106509cf65ac027b3d6333caafedeb on master.


clicking on the github logo is not taking to the github repository of eduhub

when clicking on the github logo it should take us to the github page of the eduhub community
link to where it should take us on clicking on the github logo:
https://github.com/Eduhub-Community/eduhub-website

Hey, @ShlokMohanty is this issue is still opened,
if yes, then can i work on this issue.


EpubViewer doesn't re-render when 'epubOptions' & 'style' prop changes

Describe the bug
When passing a different value to epubOptions & style props, EpubViewer doesn't re-evaluate and render with the new props
To Reproduce
Steps to reproduce the behavior:

Render simple viewer using the EpubViewer
Pass the required props and both (epubOptions & style) props
Make a toggle to change the value of epubOptions & style prop

Expected behavior
EpubViewer should re-render and display changes with the new passed in props
Screenshots
N/A
Desktop (please complete the following information):

OS: Windows 10 Single Language 64-bit
Browser: Firefox
Version: 88.0.1

Additional context
        useEffect(() => {
             // some effect to change the value of props
             setTimeout(() => {
                setBookOption({...})
                setBookStyle({...})
             },500)

             // should re-render the viewer after the delay
        },[])

	<EpubViewer
		ref={viewerRef}
		url={url}
		epubFileOptions={epubFileOptions}
		epubOptions={bookOption} // doesn't re-render
		style={bookStyle} // doesn't re-render
		rendtionChanged={renditionChange}
		loadingView={loadingView || <LoadingView />}
		bookChanged={onBookInfoChange}
		pageChanged={onPageChange}
		tocChanged={onTocChange}
		selectionChanged={onContextMenu}
	/>

corrected this issue!
Thank you for trusting and waiting!


consideringInsets:YES results in no scrolling at all.

When I use consideringInsets:YES, my text view does not scroll at all in iOS 8.4.

@jacklink01 The included sample app works fine in iOS 8.4. I'm also using ICTextView in a production application, and it's scrolling fine with consideringInsets:YES in 8.4.
Are you setting ICTextView's contentInsets correctly? See the sample app for a working example.


cpu-features: Apple Silicon not supported

I'm submitting a...

[X] Bug report
[ ] Feature request
[ ] Question

Summary
When installing on Apple Silicon (arm64) with yarn I get the following error. Is this something that can safely be ignored, or do you actually need the cpu-features package?
[1/2] ⠂ cpu-features
warning Error running install script for optional dependency: "/Users/justin/Sites/foo/server/node_modules/cpu-features: Command failed.
Exit code: 1
Command: node-gyp rebuild
Arguments:
Directory: /Users/justin/Sites/foo/server/node_modules/cpu-features
Output:
gyp info it worked if it ends with ok
gyp info using<EMAIL_ADDRESS>gyp info using<EMAIL_ADDRESS>| darwin | arm64
gyp info find Python using Python version 2.7.18 found at \"/System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python\"
gyp info spawn /System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
gyp info spawn args [
gyp info spawn args   '/Users/justin/.nvm/versions/node/v14.17.6/lib/node_modules/npm/node_modules/node-gyp/gyp/gyp_main.py',
gyp info spawn args   'binding.gyp',
gyp info spawn args   '-f',
gyp info spawn args   'make',
gyp info spawn args   '-I',
gyp info spawn args   '/Users/justin/Sites/foo/server/node_modules/cpu-features/build/config.gypi',
gyp info spawn args   '-I',
gyp info spawn args   '/Users/justin/.nvm/versions/node/v14.17.6/lib/node_modules/npm/node_modules/node-gyp/addon.gypi',
gyp info spawn args   '-I',
gyp info spawn args   '/Users/justin/Library/Caches/node-gyp/14.17.6/include/node/common.gypi',
gyp info spawn args   '-Dlibrary=shared_library',
gyp info spawn args   '-Dvisibility=default',
gyp info spawn args   '-Dnode_root_dir=/Users/justin/Library/Caches/node-gyp/14.17.6',
gyp info spawn args   '-Dnode_gyp_dir=/Users/justin/.nvm/versions/node/v14.17.6/lib/node_modules/npm/node_modules/node-gyp',
gyp info spawn args   '-Dnode_lib_file=/Users/justin/Library/Caches/node-gyp/14.17.6/<(target_arch)/node.lib',
gyp info spawn args   '-Dmodule_root_dir=/Users/justin/Sites/foo/server/node_modules/cpu-features',
gyp info spawn args   '-Dnode_engine=v8',
gyp info spawn args   '--depth=.',
gyp info spawn args   '--no-parallel',
gyp info spawn args   '--generator-output',
gyp info spawn args   'build',
gyp info spawn args   '-Goutput_dir=.'
gyp info spawn args ]
gyp info spawn make
gyp info spawn args [ 'BUILDTYPE=Release', '-C', 'build' ]
  ACTION Configuring dependencies /Users/justin/Sites/foo/server/node_modules/cpu-features/deps/cpu_features/build/Makefile
-- The C compiler identification is AppleClang <IP_ADDRESS>00029
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /Library/Developer/CommandLineTools/usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Looking for dlfcn.h
-- Looking for dlfcn.h - found
-- Looking for getauxval
-- Looking for getauxval - not found
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/justin/Sites/foo/server/node_modules/cpu-features/deps/cpu_features/build
  TOUCH Release/obj.target/config_deps.stamp
  ACTION Building dependencies /Users/justin/Sites/foo/server/node_modules/cpu-features/deps/cpu_features/build/libcpu_features.a
[ 11%] Building C object CMakeFiles/utils.dir/src/filesystem.c.o
[ 22%] Building C object CMakeFiles/utils.dir/src/stack_line_reader.c.o
[ 33%] Building C object CMakeFiles/utils.dir/src/string_view.c.o
[ 33%] Built target utils
[ 44%] Building C object CMakeFiles/unix_based_hardware_detection.dir/src/hwcaps.c.o
[ 55%] Building C object CMakeFiles/unix_based_hardware_detection.dir/src/unix_features_aggregator.c.o
[ 55%] Built target unix_based_hardware_detection
[ 66%] Building C object CMakeFiles/cpu_features.dir/src/cpuinfo_arm.c.o
In file included from /Users/justin/Sites/foo/server/node_modules/cpu-features/deps/cpu_features/src/cpuinfo_arm.c:15:
/Users/justin/Sites/foo/server/node_modules/cpu-features/deps/cpu_features/include/cpuinfo_arm.h:118:2: error: \"Including cpuinfo_arm.h from a non-arm target.\"
#error \"Including cpuinfo_arm.h from a non-arm target.\"
 ^
1 error generated.
make[3]: *** [CMakeFiles/cpu_features.dir/src/cpuinfo_arm.c.o] Error 1
make[2]: *** [CMakeFiles/cpu_features.dir/all] Error 2
make[1]: *** [all] Error 2
make: *** [/Users/justin/Sites/foo/server/node_modules/cpu-features/deps/cpu_features/build/libcpu_features.a] Error 2
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/Users/justin/.nvm/versions/node/v14.17.6/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:194:23)
gyp ERR! stack     at ChildProcess.emit (events.js:400:28)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:277:12)
gyp ERR! System Darwin 21.1.0
gyp ERR! command \"/Users/justin/.nvm/versions/node/v14.17.6/bin/node\" \"/Users/justin/.nvm/versions/node/v14.17.6/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js\" \"rebuild\"
gyp ERR! cwd /Users/justin/Sites/foo/server/node_modules/cpu-features
gyp ERR! node -v v14.17.6
gyp ERR! node-gyp -v v5.1.0
gyp ERR! not ok"

Environment / Setup
MacBook-Pro ➜  server git:(worker) ✗ node --version
v14.17.6

MacBook-Pro ➜  server git:(worker) ✗ which node
/Users/justin/.nvm/versions/node/v14.17.6/bin/node

MacBook-Pro ➜  server git:(worker) ✗ file /Users/justin/.nvm/versions/node/v14.17.6/bin/node
/Users/justin/.nvm/versions/node/v14.17.6/bin/node: Mach-O 64-bit executable arm64

MacBook-Pro ➜  server git:(worker) ✗ yarn --version
1.22.15

MacBook-Pro ➜  server git:(worker) ✗ which yarn
/Users/justin/.yarn/bin/yarn

db-migrate version: 0.11.12
plugins with versions: "db-migrate-pg": "1.2.2"

npm ls cpu-features
<EMAIL_ADDRESS>/home/tobi/serious_projects/db-migrate/test
└─┬<EMAIL_ADDRESS>  └─┬<EMAIL_ADDRESS>    └─┬<EMAIL_ADDRESS>      └──<EMAIL_ADDRESS>
It is a dependency of ssh2. So no ssh tunneling for you :/ .  So this means I also don't have any such hardware available, and wont have, so you're on your own if you want to fix this issue. The SSH Tunnel feature is especially important in enterprise environments with tight security constraints, so you might or might not need it.
If you want this fixed, please go upstream to tunnel-ssh, ssh2 and https://github.com/mscdex/cpu-features and see if they either already fixed that issue (kindly report me if this is the case then we can give it a bump) or open tickets there respectively.

I ran into the same gyp on my Intel MacBook Pro. Perhaps the ssh tunneling features could be moved into a separate package so those that don't need it have a simpler set of dependencies?

Same issue as above. Maybe ssh could be made an optional or peer dependency?

Also have the issue, +1 for optional peer dep.

We won't make this an optional peer dependency because this would be a breaking change.

Another option is to extract a core npm package without the dependency which this package uses. That wouldn't be a breaking change. I can understand it's more work to maintain two packages so not ideal.

I repeat what I wrote already earlier. Check with the upstream module to get it working with m1, and then we will happily bump the package. Unfortunately, it is what you buy in when you buy an m1, an incomplete ecosystem, this is something you have to deal with, not everyone else. So no +1 in this issue will ever help it get resolved, only your brainpower can help and would be very appreciated, by us, by the maintainer of the packages mentioned and the open source community.

I'm on an Intel Mackbook Pro and ran into this error. It's not specific to M1.
Thanks for your time considering this issue.

As far as I see, macOS(intel), Windows, docker image node:14 neither support to install.

nah that is wrong. works on intel just fine, works on docker image node:14 just fine (never use alpine and slim images, they can't work when native addons are implied, if you need it slim in total put together a proper build pipeline). windows was never on the supported so not sure.


fastmoe是否支持微调，page-attention，flasahattention和kvcache，混合精度等

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

是, 是, 是和是, 是...

没有找到微调的case,  能帮忙引导一下吗

我们没有在仓库中包含微调的例子. 请您自行实现.

好的，谢谢


Feature: Open VSX Registry

Describe the feature
Hi,
Is there any plan to add it also to the Open VSX Registry https://open-vsx.org/ ?
e.g. to install it on VSCodium
Best,
Additional comments
No response
Validations

[X] Check that there isn't already an issue that reports the same feature to avoid creating a duplicate.

Hi, Thank you for your issue. I will read the Open VSX Registry documentation and make a release today.

Added in e7f3e7c1af0c0d3f9867e30e58f70a41ef98fcb8.


Fixed Packaing Setup Issue.

Fixes #8
Fixes #9

You can run make format here.

CI has passed, please @michaelhly take a look. Many thanks!

Thank you!


moves docs to new repo

This moves the docs to a new repo. It breaks the two headless tests. This also removes the /docs dir, since we should move this to be a site on aws-s3 and deploy with @optoolco.

CI fails because its trying to run npm run build which doesnt exist. Just need to update the github actions yaml to remove the build step.

CI fails because its trying to run npm run build which doesnt exist. Just need to update the github actions yaml to remove the build step.


[libhydrogen] Update version to latest commit

Fix #21798
Update [libhydrogen] to the latest version commit
Note: No feature needs to test.

Thanks for the update and modernization!


Allow retrieval of pombe genes based on cerevisiae and human gene lists

Since we can already search on SGD locus and HGNC IDs, how easy would it be to be able to add them in the list upload (clearly would need to toggle to say which species because of name overlaps).
(Have we discussed this before?)

It wouldn't be too much work but I think the menu on the advanced search page is getting too long.  Could we change the Uniprot accessions tab to be "External identifiers" or something?  Then allow UniProt, human and SGD IDs on that page?

I forgot we had the UniPRot accessions tab!
Yes  we could make people select the appropriate 'type' from the box
Or we could do all from here

default pombe than have toggles for UniProt, HGNC and S.c locus?
Uniprot will only work for pombe  so that should be clear too?

Also,  we can't really do this within the query builder, because  of the many to on, none many mappings.
People would really need to know what mapped to what before proceeding to  load the output into the query builder.
More thinking required!

People would really need to know what mapped to what before proceeding to load the output
into the query builder.

Good point.  Perhaps we need a separate ID mapping tool.  It could have a link to the query builder once the user has the pombe IDs they're after.

Yes OK this is a 'longer term' project ;)

While we're talking about this, do you think we should change "Gene IDs" to "Gene names and IDs to be explicit about where to upload gene names?

This would be better
we probably put IDs because IDs are preferred as more stable and  unambiguous

It's now "Gene name and IDs".  It's easy to change back if we don't like it.

For looking up using orthologs we need to decide what to do if a non-pombe ID matches more than one pombe gene.  Should we keep all matching genes in that case, or allow the user to select the genes to keep?
To see how InterMine handles these cases, follow this link:
https://www.flymine.org/flymine/bag.do?subtab=upload
then click "(click to see an example)" and then "Create list"

This is a bit different from the intermine situation, I think, when people may be using synonyms etc.
I think in this case users will want both paralogs. But they may be confused that their output list is a different length form the input list.
We should provide a message "the following genes in your list had mapped to multip;e genes (paralogs) in fission yeast. All paralogs were included)
In the place where you usually get a message if identifiers are not matched.
Then the user can, if necessary  delete these, (but I can't think of a reason that they would only want to select one of the fission yeast copies, so this would be a reasonable default behaviour)
If the user has duplicates in their input list for some reason, only the official name would be recognised so they would get the 'not found' message for one of their IDs...

This is a bit different from the intermine situation, I think, when people may be using synonyms etc.

Good point.

We should provide a message "the following genes in your list had mapped to multip;e genes (paralogs) in fission yeast. All paralogs were included)
In the place where you usually get a message if identifiers are not matched.

That makes sense.
I've done a bit of work on this and it won't take too much more to finish.

I've done a bit of work on this and it won't take too much more to finish.

There is a prototype here: https://www.pombase.org/identifier-mapper
It definitely needs work:

[ ] improve the look of things overall
[ ] improve the labels and headers
[ ] a short blurb at the top
[ ] fix the browser "back" button to do the right thing
[ ] documentation

But it's a start.

nice start.
Here is a test list that includes
1:1
1:many
many:1
many to many.
YPR191W
YPR121W
YPL258C
YPR165W
YOL055C
YPR141C
YPR159W
YBR104W
YPR058W
Maybe we want  to have 4 sections? to make it clear? and how to deal with redundancy.
We can chat about this on a call if you like.

many to many.

I'm not sure that's needed.  Maybe 1:many and many:1 would be clear enough?

yes, you are right.

I did a little bit on this today as a break from Canto.

Maybe 1:many and many:1 would be clear enough?

I've added a many-to-one section but I'll need help with the wording:

Looks good to me!

Val spotted that the "Lookup" button remains disabled if you upload an ID list from a file:
https://github.com/pombase/curation/issues/2905#issuecomment-747984756

Val spotted that the "Lookup" button remains disabled if you upload an ID list from a file:

That's fixed now.

Still to do:

[ ] improve the look of things overall
[ ] improve the labels and headers
[ ] a short blurb at the top
[ ] documentation
[ ] fix the browser "back" button to do the right thing

I'm working on the "back" button problem.  I need help (in January) with the other items.

I forgot to say, it's live here but there is no link to it: https://www.pombase.org/identifier-mapper

OK, all seems to be working fine.

fix the browser "back" button to do the right thing

That's done and works quite smoothly now: https://www.pombase.org/identifier-mapper
I've also changed the link to the advanced search to be a button to make it more obvious.

improve the look of things overall

I was wondering if it would be better to not show the matches initially or to have the three result types (1-1, 1-many, many-1) in different tabs.  I'm worried that in the current implementation, users will not scroll down and see all three sections.
Here's what it looks like if we only show headings and counts:

From pombase/curation#2905:

Is this ID form acceptable?
HGNC:10001
(should specify in the drop down)

I've done that.  The drop down is quite wide now though.  Let me know if you'd like it changed.

I think it is OK, best to be explicit...

I was wondering if it would be better to not show the matches initially or to have the three result types (1-1, 1-many, many-1) in different tabs. I'm worried that in the current implementation, users will not scroll down and see all three sections.

What do you think about this change?
Here's an example of how it could look:

I was wondering if it would be better to not show the matches initially or to have the three result types (1-1, 1-many, many-1) in different tabs. I'm worried that in the current implementation, users will not scroll down and see all three sections.

What do you think about this change?
Here's an example of how it could look:

I don't have a strong preference. Just let me know when it's ready for documenation, and I'll write some.

I don't have a strong preference. Just let me know when it's ready for documenation, and I'll write some.

I agree this is clearer.

I agree this is clearer.

I've changed the code to initially hide the results.  It will be live in the morning.
If there is only a single result in the one-one or one-many section, it shows it straight away.

I've changed the code to initially hide the results.  It will be live in the morning.
If there is only a single result in the one-one or one-many section, it shows it straight away.

Once the new ID mapper is in production the "UniProt accessions" tab on the a bit redundant.  Should we remove it?
I suggest we add the ID mapper to the "Search" menu and we could also have a link to it from the default tab in the Advanced Search like this:

Once the new ID mapper is in production the "UniProt accessions" tab on the a bit redundant.  Should we remove it?
I suggest we add the ID mapper to the "Search" menu and we could also have a link to it from the default tab in the Advanced Search like this:

From the Zoom call:

change the text for UniProt in the type selector to: "S. pombe UniProt accessions (eg. ...)"
add "Hide ..." or "Hide matches ..." to do the opposite of "Show matches ..."

Anything else?

From the Zoom call:

change the text for UniProt in the type selector to: "S. pombe UniProt accessions (eg. ...)"
add "Hide ..." or "Hide matches ..." to do the opposite of "Show matches ..."

Anything else?

That's all I remember.
Tiny picky copy-editing thing: it's e.g. i.e. with dots after both e and g.

That's all I remember.
Tiny picky copy-editing thing: it's e.g. i.e. with dots after both e and g.

From the Zoom call:

I've made those changes and changed to using "e.g."
I haven't made the changes in this screenshot yet: https://github.com/pombase/website/issues/1539#issuecomment-759837388
And I haven't changed the menu.
It's still only available via a direct link: https://www.pombase.org/identifier-mapper
Midori, I'll email next week so we can pick a day to release all the changes in the test tool for doing screenshots and documentation .

From the Zoom call:

I've made those changes and changed to using "e.g."
I haven't made the changes in this screenshot yet: https://github.com/pombase/website/issues/1539#issuecomment-759837388
And I haven't changed the menu.
It's still only available via a direct link: https://www.pombase.org/identifier-mapper
Midori, I'll email next week so we can pick a day to release all the changes in the test tool for doing screenshots and documentation .

Midori, I'll email next week so we can pick a day to release all the changes in the test tool for doing screenshots and documentation.

Sounds good. At the moment next week looks relatively sane, so any day will probably do.

Midori, I'll email next week so we can pick a day to release all the changes in the test tool for doing screenshots and documentation.

Sounds good. At the moment next week looks relatively sane, so any day will probably do.

I'll email next week so we can pick a day to release all the changes in the test tool for doing screenshots and documentation.

Sorry Midori, I forgot about this last week.
I've just added two sentences at the top of the main ID mapper page as a placeholder:
https://www.pombase.org/identifier-mapper
Would you be able to have a look and make any edits you think it needs?  The file is here:
https://github.com/pombase/website/blob/master/src/app/identifier-mapper/identifier-mapper.component.html#L7
Thanks!
And if there are any changes to make or text to add on the mapper results page, please let me know.

I'll email next week so we can pick a day to release all the changes in the test tool for doing screenshots and documentation.

Sorry Midori, I forgot about this last week.
I've just added two sentences at the top of the main ID mapper page as a placeholder:
https://www.pombase.org/identifier-mapper
Would you be able to have a look and make any edits you think it needs?  The file is here:
https://github.com/pombase/website/blob/master/src/app/identifier-mapper/identifier-mapper.component.html#L7
Thanks!
And if there are any changes to make or text to add on the mapper results page, please let me know.

Thanks - I committed a couple of small edits, and the tests passed. When that goes live I'll write up some documentation, and ping again when it's done.

Thanks - I committed a couple of small edits, and the tests passed. When that goes live I'll write up some documentation, and ping again when it's done.

Thanks for the edits.  That's now live: https://www.pombase.org/identifier-mapper
I haven't committed the changes to add links to the ID mapper, but it's ready to go.  Here's what I've got.  Please let me know what to edit.  Rather than removing the "UniProt accessions" tab from the advanced search I though it would be better to add a link to the ID mapper for users that have used that tab before.  Is that sensible?  We could remove it add some point in the future.

Thanks for the edits.  That's now live: https://www.pombase.org/identifier-mapper
I haven't committed the changes to add links to the ID mapper, but it's ready to go.  Here's what I've got.  Please let me know what to edit.  Rather than removing the "UniProt accessions" tab from the advanced search I though it would be better to add a link to the ID mapper for users that have used that tab before.  Is that sensible?  We could remove it add some point in the future.

I like all of that :)
I'll make a start on the documentation.

I like all of that :)
I'll make a start on the documentation.

I like all of that :)

Great.  Those changes are now in the dev site: http://dev.pombase.kmr.nz/

I'll make a start on the documentation.

Thanks!

I like all of that :)

Great.  Those changes are now in the dev site: http://dev.pombase.kmr.nz/

I'll make a start on the documentation.

Thanks!

I have committed some documentation, and the checks look OK.

I have committed some documentation, and the checks look OK.

Thanks!  I've added a link to the documentation from the ID mapper.  It's all now deployed on the main site.
I think the second screenshot on the documentation page might need some trimming.  There is a bit of white space at the top and bottom.

Thanks!  I've added a link to the documentation from the ID mapper.  It's all now deployed on the main site.
I think the second screenshot on the documentation page might need some trimming.  There is a bit of white space at the top and bottom.

Great stuff. I'm sure this will be v. popular.

Great stuff. I'm sure this will be v. popular.

Ooh one more thing, sorry! (can still be announced)
Could we  make it clearer if all the genes mapped, maybe with a message at the top
Input list of  12 human IDs, 12 IDs mapped to 11 pombe proteins, 0 not found (or something similar)
Because, with a list like this, where all IDs map, this is not completely obvious:
PEX12
RAD52
PSTPIP1
PSTPIP2
NSFL1C
UBXN2B
UBXN2A
STX8
HLTF
RAD1
MAP3K2
MAP3K3

Ooh one more thing, sorry! (can still be announced)
Could we  make it clearer if all the genes mapped, maybe with a message at the top
Input list of  12 human IDs, 12 IDs mapped to 11 pombe proteins, 0 not found (or something similar)
Because, with a list like this, where all IDs map, this is not completely obvious:
PEX12
RAD52
PSTPIP1
PSTPIP2
NSFL1C
UBXN2B
UBXN2A
STX8
HLTF
RAD1
MAP3K2
MAP3K3

Once you introduce unmapped IDs this becomes more obvious
CEP85L
CEP104
CEP95
but it is difficult to figure out because the multi-multi does not have numbers, and users might not  size of their input list in their head.

Once you introduce unmapped IDs this becomes more obvious
CEP85L
CEP104
CEP95
but it is difficult to figure out because the multi-multi does not have numbers, and users might not  size of their input list in their head.

Oh, hang on, I found a bug!
PSTPIP1 and PSTPIP2 appear in many-to-one and many-to-many

Oh, hang on, I found a bug!
PSTPIP1 and PSTPIP2 appear in many-to-one and many-to-many

I think a better order would be
one to one
one to many
many to many

I think a better order would be
one to one
one to many
many to many

we have
one to one
one to many
many to one
but not many to many
This might be a bit confusing  because  "many to many" appear in bot "one to many" and "many to one".
"Many to many"  should be in a separate section (because they aren't 1:many or many:1)
Sorry I didn't spot this before.

we have
one to one
one to many
many to one
but not many to many
This might be a bit confusing  because  "many to many" appear in bot "one to many" and "many to one".
"Many to many"  should be in a separate section (because they aren't 1:many or many:1)
Sorry I didn't spot this before.

Oh, hang on, I found a bug!
PSTPIP1 and PSTPIP2 appear in many-to-one and many-to-many

That's working as I'd expect.  They are both one-many and many-one.

"Many to many" should be in a separate section (because they aren't 1:many or many:1)
Sorry I didn't spot this before.

We discussed many-many and decided against it: https://github.com/pombase/website/issues/1539#issuecomment-719159557
Should we add it?

Oh, hang on, I found a bug!
PSTPIP1 and PSTPIP2 appear in many-to-one and many-to-many

That's working as I'd expect.  They are both one-many and many-one.

"Many to many" should be in a separate section (because they aren't 1:many or many:1)
Sorry I didn't spot this before.

We discussed many-many and decided against it: https://github.com/pombase/website/issues/1539#issuecomment-719159557
Should we add it?

I think the second screenshot on the documentation page might need some trimming.

Thanks - I've committed an update that should crop off the extra.

I think the second screenshot on the documentation page might need some trimming.

Thanks - I've committed an update that should crop off the extra.

Should we add it?

Sorry I didn't think that through.
The problem is that  in orthology- jargon many-to-many is a separate class to many to one and one to many.
It is useful to see many to many separately because they tend to be different types of gene products.
Many-to-one and one-to-many  are often a single duplication in one species, but are otherwise  often in single copy.
For example pombe has 2 copies of the proteasome complex subunit rpn5 (rpn501 and rpn502) but all other species have one copy and all other proteaxome sununits are in one copy. These single copy duplicates pop up but are often removed by selection (although sometimes retained).
The many to many class  either

Highly conserved copies of gene products that are needed in high copy number (mainly histones, ribosomal proteins)
or
Proteins that are not necessarily conserved members of complexes, transcription factors, signalling molecules and transporters.

These aren't hard and fast rules, but there are definitely biological differences between these list. I can see that people might want only  1:1,  1:many and many:1 but  might want to exclude many:many.

Should we add it?

Sorry I didn't think that through.
The problem is that  in orthology- jargon many-to-many is a separate class to many to one and one to many.
It is useful to see many to many separately because they tend to be different types of gene products.
Many-to-one and one-to-many  are often a single duplication in one species, but are otherwise  often in single copy.
For example pombe has 2 copies of the proteasome complex subunit rpn5 (rpn501 and rpn502) but all other species have one copy and all other proteaxome sununits are in one copy. These single copy duplicates pop up but are often removed by selection (although sometimes retained).
The many to many class  either

Highly conserved copies of gene products that are needed in high copy number (mainly histones, ribosomal proteins)
or
Proteins that are not necessarily conserved members of complexes, transcription factors, signalling molecules and transporters.

These aren't hard and fast rules, but there are definitely biological differences between these list. I can see that people might want only  1:1,  1:many and many:1 but  might want to exclude many:many.

I can see that people might want only 1:1, 1:many and many:1 but might want to exclude many:many.

Do we need an option to exclude many to many matches from the results?

I can see that people might want only 1:1, 1:many and many:1 but might want to exclude many:many.

Do we need an option to exclude many to many matches from the results?

Do we need an option to exclude many to many matches from the results?

No, I think people would need to look at the results, having them in separate lists in the download will be good. They can combine them how they like then.  I don't think users will necessarily be aware of the subtleties, but in some list they might clearly want to leave the many to many out once they look at them, because they are not as meaningful for functional transfer.

Do we need an option to exclude many to many matches from the results?

No, I think people would need to look at the results, having them in separate lists in the download will be good. They can combine them how they like then.  I don't think users will necessarily be aware of the subtleties, but in some list they might clearly want to leave the many to many out once they look at them, because they are not as meaningful for functional transfer.

SH3GL1 is an ortholog of mug137 (SPCC1919.11)
SH3GL2 is an ortholog of mug137 and SPBC19C2.10

(Sorry my previous comment wasn't finished - I've deleted it)
I've added a many-to-many section and that's on the main site.  The wording needs work and it doesn't handle every case yet.
Here's an example problem:
mug137 has three human orthologs: SH3GL1, SH3GL2 and SH3GL3
SPBC19C2.10 has one human ortholog: SH3GL2
If you put SH3GL1 and SH3GL2 in the ID mapper it doesn't put either of the two IDs in the many-to-many section.  Maybe that's the right behaviour?  But unfortunately SH3GL2 and mug137 appear in both the one-to-many and many-to-one sections which is a little confusing.

Hi Kim
These are wrong:
mug137 has three human orthologs: SH3GL1, SH3GL2 and SH3GL3
SPBC19C2.10 has one human ortholog: SH3GL2
I have been meaning to do a sanity check of the human orthologs to see if there are any cases like this, I will need to check them manually and add the missing paralogs.
I think I  checked that all of the cerevisiae ones agreed a few years ago, but I have never checked human.
Could you send me lists of anything which appear in more than one list and I will fix them. Might be worth checking S.c again too.
Val

I fixed this one.

I'm going to call this done because I'd like to close an issue today.  :-)
I'll open a separate issue for the many-to-many problem (https://github.com/pombase/website/issues/1539#issuecomment-771321265) if needed later.
If you spot any bugs please open new issues.

good idea! this issue  has 55 comments I detest the issues this long.
I have an issue on the curation tracker, I am working through it now:
https://github.com/pombase/curation/issues/2950
I don't think I will finish tonight, I'm going to call it a day soon...

I fixed these.
https://github.com/pombase/curation/issues/2950

So the mapping tool can go live now?
I just did a bit more testing  and it seems to work well

So the mapping tool can go live now?

It's been live for a week or so.

I just did a bit more testing and it seems to work well

Thanks for testing.

I thought I had seen it, then I got confused :)

@mah11 it probably makes sense for you to do this news and pombelist announcement since you wrote the dics.


Added in comment to docblock for linux docker users

This is a PR to just satisfy my own annoyance within the ray.php file. It lists options for Docker on Mac or Windows but not on Linux.
Now <IP_ADDRESS> won't work 100% of the time if you're doing custom networking with Docker, but by that point, you'll know to update that IP.
Feel free to dismiss this PR if it's irrelevant, it's more just to satisfy me.

Thanks!


Add MSC directive to prevent cppcorecheck build failures on non-VS builds

Simple fix for #1550 -- Only include cppcorecheck headers when compiling with MS toolchain.

Thank you!


move the protobufjs dep to dev deps

The protobuf.js and long typedef are only needed for building not for runtime.

This change is

Checking out this change now, I also don't see how this could work. Have you tried also deleting the node_modules folder and remove the lock? protobufjs needs a runtime.
Also, Long is a type, so it won't show up in JS.
Can you try this as a third party user (clean client, brand new package.json)?

Checking out this change now, I also don't see how this could work. Have you tried also deleting the node_modules folder and remove the lock? protobufjs needs a runtime.
Also, Long is a type, so it won't show up in JS.
Can you try this as a third party user (clean client, brand new package.json)?

I am bit surprised as well, but in our rollup.config.google.js file, we seem to create the transformation that
removed the dependencies in the rolled up js.

Now that I think about it dev deps will show up in node_modules. The problem is packages that depend on this through NPM will not install the dev deps of this library if they are bundling their project. Try doing that, you will see protobufjs is not defined.

closing this PR due to direct package.json deps will not install devDeps, and we don't want to use rolled up js file as the main entry for the package.


Set database directory permissions in init container

PostgreSQL requires the /var/lib/postgresql/data directory to have 0700 permissions.
When the pod is restarted the file system permissions are reset and the database always crashes.
The permissions for the directory need to be set in the init container every time the pod is started.
Fix #444
See also: goharbor/harbor#8224

Wrong base branch 😆


Support for Redis v5.0.3?

Hi. I noticed on the docs that aioredis does not appear to officially support Redis v5.0.3 yet. I use Redis for an automoderator bot on Discord and planning to update the Redis server version (it's on 3.2.10 right now), and just wondering: will aioredis work just fine with the latest stable build, or might I experience errors doing this? Thanks for the help in advance!

I have been using aioredis with redis 5.0.3 without issue.

@f0ff886f I missed your post but yep, aioredis works fine on all current versions of Redis. I'm on v6.0.8 atm and no issues. I was just curious about whether the library will support all newer features that Redis are implementing, but presumably it will in time 👍


Use cards instead of a list of links

Description
Updates blockchain.mdx and guides.mdx to use cards with brief descriptions / groupings for easier navigation.
Also updates one tutorial with a link to the coin move module so that context from the original link isn't lost.
Checklist

Do all Lints pass?

[ ] Have you ran pnpm spellcheck?
[x] Have you ran pnpm fmt?
[x] Have you ran pnpm lint?

@hariria Updated :)


🐛 Terminal apps won't run from the pcmanfm context menu

branch
stable
Architecture
x86_64
Description
Any application with a .desktop file that has Terminal=true set, like neovim, does nothing when you click it from the pcmanfm context menu.
Apparently this issue is due to foot not being on the hardcoded (!) list of terminals that glib looks for when launching terminal applications.
Reproduction steps
1. Install neovim on a fresh manjaro-sway system.
2. Right click a text file in pcmanfm.
3. Select the neovim option from the context menu.
4. Nothing happens.

Screenshots

Logs
~ $ gio launch /usr/share/applications/nvim.desktop lazyvim.json
gio: Unable to launch application ‘/usr/share/applications/nvim.desktop’: Unable to find terminal required for application

Understood. So probably we should reopen this one to keep track of adding an appropriate .desktop file for foot.

I just removed /usr/bin/xdg-terminal-exec and installed xdg-terminal-exec-git. For me it seems to "just work" out of the box with the gio-command you posted earlier. Can you confirm?

Ah, I think I understand why it "just works": foot also listens to foot -e [CMD]. The only thing "foot.sh" achieves is picking up the default config when starting the foot server - so just starting foot via foot -e might be just fine afterwards.

Should land in 16.2.0


Expose ReadOnlyResources featuregate in ACK helm chart

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

/lgtm

/retest

/retest


Added npm to readme

Surprisingly, the existence of an npm package is not mentioned in the readme.

Thanks. We just added that.


Removed case-insensitive variables

Starting from Asterisk 12, variables are case-sensitive.
This PR remove case-insensitive variables allowing to set the right variable name in Asterisk >= 12.

Hi @thomasvargiu!
Could you fix the build and add just for reference, a quote of the changelog item that changes this behavior in Asterisk?
Thanks :)

Coverage decreased (-5.07%) to 91.726% when pulling 35b3f2475111194b8de6d93524c45c0ac8cfae58 on thomasvargiu:fix/case-insensitive-variables into 31b052e0bc1fefe2853a2024bc3b2e4a0e7b3d9f on marcelog:master.

@marcelog Done!

Thank you @thomasvargiu!


Fixed regression introduced by issue fix #118

Fixed regression introduced by issue fix "Color field added to image element. #118" where a colored image can no longer use the alpha value of the element.

Wow that's a pretty old regression bug that's gone unnoticed.... nice work spotting it, and thanks for the fix! Looks good :+1:


Rework N*

N* is expected to be a low-level abstract assembly language, i.e. it should be able to run on most architectures without major modifications (mainly related to calling conventions) to the code.
Because of this, it is mandatory to abstract away some specific details.
At the moment, N* is simple enough to allow a subset of C to compile to it. However, things get really complicated when we consider more complex features, e.g. higher order functions.
Currently (speaking as of the first version), N* disallows manipulating code addresses (basically function entry points). Higher order functions (or pointer to instructions, as used in C) cannot be expressed if this limit exists.
The branch-checker (which is supposed to check whether jumps are safe etc) currently works under the assumption that this is impossible to manipulate code addresses, therefore cannot work if we allow jumping to un-trusted code via a register (which is in fact useful when working with lambdas, higher order functions in general, making a JIT compiler, etc).
Looking back to FunTAL, they achieve some sort of “jump safety” using continuations.
While this works, I'd like to be a little less restrictive, and allow jumping back to an address on the top of the stack (which in fact serves the same purpose, just in a different way).
There are also some design problems that I'd like to fix by re-designing the language itself.

This second version of N* should:

allow jumping/pushing/popping code addresses (e.g. found in registers, from registers to other registers, etc)
get rid of the branch-checker which is basically meaningless if we allow manipulating code addresses
have some syntactical changes
allow handling some labels as "inner" labels, allowing for type-safe fallthroughs

The new syntax will be inspired from FunTAL (at least a bit), while still being simple enough to be used and understood by a human-being (N* will be used in the Zilch project as a compiler back-end, but it has to be able to be used as a standalone programming language).
It could look like:
section data {
  x: u64 = 0xDEADBEEF
}

section code {
  main: ∀(σ: Ts).{| (∀().{ %r0: u64 | σ })∷σ } = [
    mov 0, %r0
    ret
  ]
}

This example is of course just a draft, and will most likely be changed in the future.

FunTAL (the TAL part) uses continuations to "return" values from functions, using the end continuation to exit the program.
This is a good idea, because it makes jumps safe (no need to compute the new context after a call, which cannot be always determined unless we can't manipulate code addresses).
The stack seems to also be completely infered in FunTAL (which doesn't change much, mainly only one forall bind).
Considering those aspects, I propose this syntax for the example above:
section data {
  x: u64 = 0xDEADBEEF
}

section code {
  main: ∀(ϵ).{%r5: ∀().{%r0: u64 | σ → ϵ} | σ → %r5} = [
  #       ^ we can also add `σ` here
    mov 0, %r0
    ret
  ]
}

∀(ϵ).{%r5: ∀().{%r0: u64 | σ → ϵ} | σ → %r5} means:

the type is generic in the continuation ϵ of the function pointer stored in %r5 (functions are automatically boxed)
it works with any stack, but also doesn't know anything about the stack
to be able to jump to this function, we need to have a code address in %r5 (how can this be extended to work with the stack?)
to jump to the continuation (using ret), we have to set %r0 to an unsigned 64 bit integer

And we also no longer need our branch-checker! :tada: (changing the return continuation does not prevent the type-checker from working, compared to before where we needed to compute the return context after a call)

Taking a deeper look into FunTAL (which is a very good resource, but a bit hard to understand), there are a few things that I would also like to add to N*, namely:

[ ] Allowing indexing the stack using integer numbers (where 0 maps to the entry on top of the stack, 1 the second entry in the stack, etc)
[ ] Extending the stack index feature to also work for continuations: → 0 means that the continuation lies on top of the stack when escaping from the current scope
[ ] Those = [ i... ] are ugly when defining code objects (“functions”); using the same syntax as FunTAL (I ::= i; I | ret | other terminal instructions... where i is a simple instruction) seems to be a much better choice
[ ] Maybe extend the indexing feature to arrays, therefore introducing arrays in N*. This will most probably be hard to use (e.g. using VLAs without some sort of variable) but can be worth having


Enable duplicate selection

I'm using DAL in my Django form to generate select multiple field. The problem is I can't able to select one item multiple time. Whenever I try to select one item multiple times it got vanished from the selection.

I don't think that is supported by select2

Is there any alternative to Select2, that supports duplicate selection?

Not that I know of, have you considered using a formset?


ansible warns when importing the role

[DEPRECATION WARNING]: The comma separated role spec format, use the yaml/explicit format instead..

the documentation does not mention the preferred format, but the source can be found at:
https://github.com/ansible/ansible/blob/devel/lib/ansible/playbook/role/requirement.py#L154

add pending as not all ansible versions in the Jenkins environment support the new format.

the commas that caused the warnings has been removed


Hhh

Issue type
Bug
Have you reproduced the bug with TensorFlow Nightly?
Yes
Source
source
TensorFlow version
U
Custom code
Yes
OS platform and distribution
Hhhh
Mobile device
H
Python version
Hhhjk ko
Bazel version
Uuuu
GCC/compiler version
Hh
CUDA/cuDNN version
No response
GPU model and memory
Ughyt
Current behavior?
Bbjjk
Standalone code to reproduce the issue
Hhh

Relevant log output
Hhhh

J

Jyghjg

Huuj

Kluhh

hh

Closing this issue as a spam.


[Suggestion] Downloading and installing old UI in linux

Like in spotx for windows, which downloads older version of Spoitfy from uptodown and patches it, can the same be applied with this.
Source for older version:
http://repository.spotify.com/pool/non-free/s/spotify-client/spotify-client_<IP_ADDRESS>1.ga588f749_amd64.deb
(although 404)
But there archive of it
https://web.archive.org/web/20230629002409if_/http://repository.spotify.com/pool/non-free/s/spotify-client/spotify-client_<IP_ADDRESS>1.ga588f749_amd64.deb
And the link works, maybe this deb can be archived in this repository and downloaded/installed supporting the old version like the ones for macos and windows.

SpotX for Windows does not download old versions from 3rd party file hosts, all Windows installations are still hosted directly on the Spotify servers where SpotX grabs them. The same is true for SpotX-Bash and the macOS releases.
Spotify only hosts the current stable and experimental versions of Spotify for Linux so therefore those are the only options available in SpotX-Bash. We will never use a 3rd party file host to pull files from. Users are free to download and install older versions or the app from other sources and then patch with SpotX-Bash.