[5.3] Add full stubbing to policy generator

Running the following command:
php artisan make:policy CompanyPolicy --model=Company

Will generate this policy file:
<?php

namespace App\Policies;

use App\User;
use App\Company;
use Illuminate\Auth\Access\HandlesAuthorization;

class CompanyPolicy
{
    use HandlesAuthorization;

    /**
     * Determine whether the given user can view companies.
     *
     * @param  App\User  $user
     * @return mixed
     */
    public function viewAny(User $user)
    {
        //
    }

    /**
     * Determine whether the given user can view the specified company.
     *
     * @param  App\User  $user
     * @param  App\Company  $company
     * @return mixed
     */
    public function view(User $user, Company $company)
    {
        //
    }

    /**
     * Determine whether the given user can create companies.
     *
     * @param  App\User  $user
     * @return mixed
     */
    public function createAny(User $user)
    {
        //
    }

    /**
     * Determine whether the given user can update companies.
     *
     * @param  App\User  $user
     * @return mixed
     */
    public function updateAny(User $user)
    {
        //
    }

    /**
     * Determine whether the given user can update the specified company.
     *
     * @param  App\User  $user
     * @param  App\Company  $company
     * @return mixed
     */
    public function update(User $user, Company $company)
    {
        //
    }

    /**
     * Determine whether the given user can delete the specified company.
     *
     * @param  App\User  $user
     * @param  App\Company  $company
     * @return mixed
     */
    public function delete(User $user, Company $company)
    {
        //
    }
}

should we use show instead of view and store instead of create to stay consistent with controller method naming? also, this would allows Laravel to automatically determine policy methods.

Wouldn't it be better if this was bound to the model as defined in the auth.providers.users.model config setting instead of directly to the App\User class somehow? I guess this would mean changing things besides just scaffolding this, but would make the scaffolding context aware.

@browner12 a policy defines the abilities throughout your app. Using $this->authorize() in the controller is but one way to query for the user's abilities.
In 5.2, we naively mapped the controller's method names to the policy's. This seemed fine when used directly from the controller, but the convention quickly broke down when used elsewhere.
Here are 2 examples of where this convention breaks down:

If you visit CutomersController@index in 5.2, you'd trigger the index method on your CustomerPolicy. While this may make sense in the controller, imagine you'd want to do this check in one of your views (maybe in a sidebar or whatever):
@can('index', Customer::class)
    // show a list of customers
@endcan

This doesn't make much sense. Instead, you'd intuitively reach for the view ability:
@can('view', Customer::class)
    // show a list of customers
@endcan

Identical abilities for the same resource type had a different name depending on whether it got a specific model.
Once again, imagine you'd want to check if a user may edit/update customers. If you want to check that generally, you'd do $user->can('edit', Customer::class), but if you're checking a given customer you'd use a different ability name: $user->can('update', $customer).

When used directly within the controller via the $this->authorize() calls, all of this is hidden from view. But as you start doing these checks throughout your app, it doesn't make much sense anymore.
So, in 5.3 we're standardizing all this. We have a sensible method-to-abilities mapping , which we use when guessing the ability name from the method name.
Additionally, the gate now intelligently calls these *Any methods on the policy if you don't provide a specific model instance.

thanks @JosephSilber for that explanation.  I had not seen that update happening in 5.3. I agree, the index naming scheme made it very non-descriptive.
is there a reason we use the GET request name for 'create/store' and the PATCH request name for 'edit/update'?   would it make more sense to be consistent and use the either create and edit or store and update?
either way, i like the option to fully stub this.

Those are the default names people use for these operations. It's right there in the CRUD acronym.


Added Destination Service Feature

This PR adds Destination Services available in SAP CP.

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


Method not allowed

When I run it and post a request for scan, I am getting Method not allowed for POST !

Following the README, getting the same error
{"detail":"Method Not Allowed"}
INFO:     <IP_ADDRESS>:57552 - "POST / HTTP/1.1" 405 Method Not Allowed

check ze docs boys / only allows GET, look through the docs as the source of truth on what apis support what methods.  try to line that up against the readme.md insofar as it's possible, tweak that curl example and you might get there.
however, passing in my downloads folder made the server start dumping 401s and eventually curl exited with 500 internal error.  this is more of a POC than something that might be robust and stable.

@bsmartt13 this is from the example on the README.md which people use as their first point of entry into RTFM.

@lightningorb right readme != docs. http://<IP_ADDRESS>:8000/docs let me spell it out POST to /batch not /

Even If I execute the /batch post command at http://<IP_ADDRESS>:8000/docs, am still getting the same error message.
500 | Error: Internal Server Error

@anujmodi1
"Internal Server Error" means the server had an uncaught error, or it entered an unexpected state
this is 100% most likely a bug and should be reported on a new issue

500 Internal server error is not the issue here. This thread should be closed and if truly necessary a different one opened. Please ensure you are using a valid api key before doing that.


Trim headerParams in ApiListener

Current Behavior
headerParams="ApiKey, ApplicationElementId" to
headerParams="ApiKey,ApplicationElementId"

Expected Behavior
trim
Environment Information
FF! 8.3.0-20240925.042333: []
Running on []using Apache Tomcat/10.1.24
Java Version: OpenJDK Runtime Environment (21.0.2+13-LTS)
Up since: 2024-10-01 13:37:55 (21h)
Steps To Reproduce
No response
Configuration
No response
Input
No response
What database are you using?
No response
What browsers are you seeing the problem on?
No response
Relevant Log Output
No response
Anything else?
No response

A similar solution was implemented in https://github.com/frankframework/frankframework/pull/7568


Arc projectiles (Specifically the petrol bomb) seem to trigger early when arced upwards

https://github.com/apetavern/sbox-grubs/assets/11138884/41d7bf28-a48d-450a-909a-a049a0ca6d6b
Not sure why or how it's doing this.

It's because when the arc gadget simulation runs out of segments it defaults to exploding the projectile, ignoring if the explosive component's ExplodeAfter is <= 0. I'll see about fixing it.
https://github.com/apetavern/sbox-grubs/blob/9458d42f8c8b8c0a14041981e7ec80815d350da9/code/Weapons/Gadget/Components/ArcPhysicsGadgetComponent.cs#L68

fixed kinda


Only one detector works for all cameras[BUG]

Describe the bug
In my configuration I have both Deepstack and Copreface and I want them both to detect persons for a cameras. But where Deepstack works for all cameras Compreface seems to work for only one. The first. Is this a bug or a known feature. I would like them to both recognize a person for  all cameras  so I have less false positives.
Version of Double Take
V 1.12.1-35874F3
Expected behavior
detection by all detectors.
Screenshots
If applicable, add screenshots to help explain your problem.
Hardware

OS: Debian 11
Browser (if applicable) [e.g. Chrome, Safari]

Additional context
This is the part of the config that is needed:
`detectors:
  deepstack:
    url: http://192.xxx.xxx.xxx:5000
    key:
    cameras:
      - frontdorr
      - garage
      - livingroom
      - backyard

  compreface:
    url: http://192.xxx.xxx.xxx:8000
    key: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    timeout: 15
    det_prob_threshold: 0.75
    cameras:
      - frontdorr
      - garage
      - livingroom
      - backyard

Can you provide a screenshot and blur out faces if you need to so I can better understand your issue? So you're saying CompreFace only works for the frontdorr camera and not any of the other ones?
Do both detectors show under the image on the matches page? Or are you only seeing one of them?

David,
Does this help?

Op 19 okt. 2022 om 06:17 heeft David Jakowenko @.***> het volgende geschreven:

Can you provide a screenshot and blur out faces if you need to so I can better understand your issue? So you're saying CompreFace only works for the frontdorr camera and not any of the other ones?
Do both detectors show under the image on the matches page? Or are you only seeing one of them?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.

Hello, I have the same issue, only one camera is avalible, but in configuration file frigate.yml i have added two cameras.

I am having this issue. I have 5 cameras in Frigate but only 4 shows up


Add Kim to all contributors. Update Haworku to include doc contributions

Summary

Adds @kimallen to all-contirbutors
Add doc contributions for @haworku

How To Test
Look at the readme
Screenshot from the READEM "rich diff"

@kimallen I assume you're okay being added?

if possible can we add @kylehilltruss and @rswerve as well i dont think i see them

Good call, done!


Copy button

Fixes #19

I added the copy button but it is not finished. I had to use unstable apis in web-sys so it has to be served with RUSTFLAGS=--cfg=web_sys_unstable_apis. I updated the 'just serve' so it serves fine locally but the deployment needs to be updated. The rust analyzer also needs to be updated because 'just check' fails.

Thanks for your changes. Is there a way to access the clipboard without unstable APIs? I will look into that as well.


CASMPET-5961-1.3 : Rebuild spire to pick up cray-service:8.2.3

Summary and Scope
Rebuilds spire to pickup base chart cray-service:8.2.3
Bugfix
Issues and Related PRs
List and characterize relationship to Jira/Github issues and other pull requests. Be sure to list dependencies.

Resolves CASMPET-5961
Change will also be needed in <insert branch name here>
Future work required by [issue id](issue link)
Documentation changes required in [issue id](issue link)
Merge with/before/after <insert PR URL here>

Testing
vshasta
Tested on:

<development system>
Local development environment
Virtual Shasta

Test description:
$ kubectl get cronjob spire-postgresql-db-backup -n spire -o yaml | grep cray-service
    helm.sh/base-chart: cray-service-8.2.3

$ kubectl get cronjob spire-postgresql-db-backup -n spire -o yaml | grep backup | grep image
            image: artifactory.algol60.net/csm-docker/stable/cray-postgres-db-backup:0.2.3

$ kubectl logs spire-postgresql-db-backup-27718110-xq8vg -n spire
2022-09-13 16:30:25,170 - INFO    - root - Exec'ing ['pg_dumpall', '-c', '-h', 'spire-postgres-1']
2022-09-13 16:30:25,171 - INFO    - root - Sending pg_dump file to storage. bucket='postgres-backup', key='spire-postgres-2022-09-13T16:30:25.psql'
2022-09-13 16:30:26,003 - INFO    - root - progress: upload_fileobj sent 195882 bytes.
2022-09-13 16:30:26,004 - INFO    - root - Completed sending pg_dump file to storage.
2022-09-13 16:30:26,004 - INFO    - root - Fetching spire/spire.spire-postgres.credentials secrets
2022-09-13 16:30:26,017 - INFO    - root - Fetching spire/service-account.spire-postgres.credentials secrets
2022-09-13 16:30:26,023 - INFO    - root - Fetching spire/postgres.spire-postgres.credentials secrets
2022-09-13 16:30:26,028 - INFO    - root - Fetching spire/standby.spire-postgres.credentials secrets
2022-09-13 16:30:26,053 - INFO    - root - Completed sending creds file to storage. key='spire-postgres-2022-09-13T16:30:25.manifest'
2022-09-13 16:30:26,053 - INFO    - root - Listing objects in 'postgres-backup' with prefix 'spire-postgres-'
2022-09-13 16:30:26,103 - INFO    - root - Keys for db 'spire-postgres': ['spire-postgres-2022-09-13T16:30:25.manifest', 'spire-postgres-2022-09-13T16:30:25.psql']

ncn-w001-4712e011:~ # python list.py
spire-postgres-2022-09-13T16:40:16.manifest
spire-postgres-2022-09-13T16:40:16.psql

Verified restore from backup -- https://github.com/Cray-HPE/docs-csm/blob/release/1.2/operations/kubernetes/Restore_Postgres.md#restore-postgres-for-spire (after downloading - renamed spire-postgres-2022-09-13T16:40:16.psql to exclude (":") in the name)

Were the install/upgrade-based validation checks/tests run (goss tests/install-validation doc)?
Were continuous integration tests run? If not, why?
Was upgrade tested? If not, why?
Was downgrade tested? If not, why?
Were new tests (or test issues/Jiras) created for this change?

Risks and Mitigations
Low
Pull Request Checklist

[x] Version number(s) incremented, if applicable
[ ] Copyrights updated
[ ] License file intact
[x] Target branch correct
[ ] CHANGELOG.md updated
[ ] Testing is appropriate and complete, if applicable
[ ] HPC Product Announcement prepared, if applicable

Also need to change reference to the image under the annotations in Chart.yaml file: artifactory.algol60.net/csm-docker/stable/cray-postgres-db-backup:0.2.2 (change to 0.2.3)

Thank you Bo - fixed!


[Document] Setup MetaMask

[x] Install MetaMask
[ ] Config the RPC for MetaMask(dev network and test network)
[x] Provide one-click link to add the network

dashboard can automatically add networks

This aa can be turned off

rooch doc https://rooch.network/docs/user-guides/interact-with-metamask
dashboard auto config


Update "Our Team" page

Summary
Closes #1353
Updated "Our Team" page according to the Figma design:  https://www.figma.com/file/vH0gBrC6f6VctocGNhhWSD/Teams-Page?type=design&node-id=301-2112&mode=design&t=Tt9T6EDbk437f5v3-0
Checklist

[ ] On the frontend, I've made my strings translate-able.
[ ] If I've added shared components, I've added a storybook story.
[X] I've made pages responsive and look good on mobile.

Screenshots
Desktop View:

Mobile View:

Steps to test/reproduce

Go to the home page
Click "About" -> "Our Team" in the menu

@hanboyu looks great!! One comment -- we forgot to change the description for the Advisory Board. Can you update it to reflect this:

I've also updated the figma desktop version

Looking good!  Thank you @hanboyu
A few questions, partly for @mvictor55

Do we want to hyperlink (mailto) the email addresses?
Do we want to hyperlink to any of our team/advisor's homepages or to the websites of their affiliated orgs? Not sure if the original bios we collected had links or not.

I think we should try to hyperlink our own emails. But, for now, don’t need
to adjust the links in our advisors’ profiles
On Thu, Oct 26, 2023 at 4:07 PM Nathan E. Sanders @.***>
wrote:

Looking good! Thank you @hanboyu https://github.com/hanboyu
A few questions, partly for @mvictor55 https://github.com/mvictor55

Do we want to hyperlink (mailto) the email addresses?
Do we want to hyperlink to any of our team/advisor's homepages or to
the websites of their affiliated orgs? Not sure if the original bios we
collected had links or not.

—
Reply to this email directly, view it on GitHub
https://github.com/codeforboston/maple/pull/1362#issuecomment-1781823919,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ARANGSCHSHQ75SYXI7TLEV3YBK7HFAVCNFSM6AAAAAA6RXPARCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBRHAZDGOJRHE
.
You are receiving this because you were mentioned.Message ID:
@.***>

@hanboyu looks great!! One comment -- we forgot to change the description for the Advisory Board. Can you update it to reflect this:
I've also updated the figma desktop version

Opps, I just fixed it.

I think we should try to hyperlink our own emails. But, for now, don’t need to adjust the links in our advisors’ profiles
…
On Thu, Oct 26, 2023 at 4:07 PM Nathan E. Sanders @.> wrote: Looking good! Thank you @hanboyu https://github.com/hanboyu A few questions, partly for @mvictor55 https://github.com/mvictor55 - Do we want to hyperlink (mailto) the email addresses? - Do we want to hyperlink to any of our team/advisor's homepages or to the websites of their affiliated orgs? Not sure if the original bios we collected had links or not. — Reply to this email directly, view it on GitHub <#1362 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARANGSCHSHQ75SYXI7TLEV3YBK7HFAVCNFSM6AAAAAA6RXPARCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBRHAZDGOJRHE . You are receiving this because you were mentioned.Message ID: @.>

Currently, the emails in "Steering Committee" are not hyperlinked, I can quickly change that.

:rocket:


Tag Lace wallet as open-source

Lace.io wallet went fully open-source in June 2023, according to their blog post: https://www.lace.io/blog/unleashing-the-power-of-web3-lace-goes-open-source
This should be updated in the wallet overview:
https://developers.cardano.org/showcase/?tags=wallet

Thanks @DominicZ8 for noticing & reporting 🤓 ... fixed by https://github.com/cardano-foundation/developer-portal/pull/1118


Bring back Nix 9.0, 9.2 using magic cache

This demonstrates using the DeterminateSystems/magic-nix-cache-action in place of Cachix for certain builds, and brings back GHC 9.0 and 9.2 in the Nix CI to use it.
It's fast, with a full Nix workflow build taking 2-3 minutes in my tests.
Hopefully this is a satisfactory way to maintain Nix support for these compilers without using too many Cachix resources.

I just made a whole bunch of changes today to get the cache size down and reduce CI times, and this would undo a lot of that work. I'm still unconvinced that this is a good idea, did you explore doing it in a separate repository like I mentioned the last time we discussed this?

Let me do a little experiment to clear the full cache on my fork and run all the workflows, and see how much cache it uses...

But then what? Manually maintain two IHaskell repos going forward?

I was thinking something along the lines of having a workflow in a separate repository that clones this repo and runs the checks you want, which would obviate the need to maintain two separate repositories (the only thing we would have to maintain is that workflow).
It occurs to me that I haven't given you the full context here:

Each repository on GitHub has 10GB of space available for caching. AFAICT there is no way to increase this number.
I'm not willing to spend money on an alternative caching solution, because I don't want to be out of pocket for an open source project where I'm already contributing time and effort. I'm also not willing to implement my own caching on top of something like S3, which would in any case involve paying a cloud provider.
After your recent PR we were routinely blowing past the cache limit, which means inconsistent and long GitHub Actions turnaround times since one evicted cache slows down the whole group of checks. This was due to a bad caching implementation on my part, since caching all of ~/.stack is unnecessary and wasteful, but having extra caches for the stack --nix builds exacerbated the issue.
I spent the vast majority of today on improving the Stack CI, largely through more granular caching (https://github.com/IHaskell/IHaskell/pull/1443), using different keys for stack and stack --nix builds (https://github.com/IHaskell/IHaskell/pull/1439) and avoiding redundant builds on push/pull_request events (https://github.com/IHaskell/IHaskell/pull/1440).
After all this effort, we're sitting at around 8GB of cache utilisation and I would very much like to keep it comfortably under the 10GB limit.
As far as I'm concerned anyone who wants to use a) IHaskell, b) Nix, and c) GHC < 9.4 can write their own expression to do so and there's no reason to add those expressions to this repo

With all that in mind, I really really really really don't want to merge this PR. All day while I was working on this repo I was thinking how nice it would be if I disabled stack --nix CI as well and got that cumulative hour (spent waiting for it) of my life back.

I totally understand the desire to save money and time on IHaskell.

As far as I'm concerned anyone who wants to use a) IHaskell, b) Nix, and c) GHC < 9.4 can write their own expression to do so and there's no reason to add those expressions to this repo

I don't understand why you think GHC 9.0/9.2 (still popular and widely used) and Nix (growing in popularity) don't deserve to be supported. If I had to choose between the stack --nix CI and 9.0/9.2 on the Nix CI, I'd choose the latter. (If I knew it would mean sacrificing Nix support, I wouldn't have suggested running stack --nix at all.) Also, I'm kind of shocked by the suggestion that users would have to come up with these expressions--I'm kind of an expert at this at this point, and it takes me a while to figure it out for each GHC version.
BTW I'm trying to figure out exactly what contribution each of these workflows has on the cache--it's taking forever because clearing the cache entries seems to happen one entry at a time, but I should have results in a day or two.
I think the double repo thing could work. But there might be some easier answers too. What about making certain workflows (maybe the stack --nix and Nix ones) only run on manual dispatch? Then you could have quick feedback during day-to-day work by only running the Stack one. That's probably plenty to test for most regressions. Then, when it comes time to do a release, you can run the extra workflows and wait an hour.

I don't understand why you think GHC 9.0/9.2 (still popular and widely used) and Nix (growing in popularity) don't deserve to be supported.

You don't have to sell me on Nix, I've been using it professionally since 2017 :smile:. What do you mean by "don't deserve to be supported"? We already test IHaskell against both these GHC versions on Stack and Stack+Nix.  And even in that extremely unlikely case I would expect them to raise an issue on the repo.
Also, where does it end? IIRC you mentioned that 23.05 has GHC builds back to 8.6, so to be consistent we would want IHaskell expressions for those too? I've already fallen into the trap of supporting older GHC versions for far too long (you should see the issue someone raised to tell me off when I dropped GHC < 8) and I don't want to make the same mistake again.

BTW I'm trying to figure out exactly what contribution each of these workflows has on the cache--it's taking forever because clearing the cache entries seems to happen one entry at a time, but I should have results in a day or two.

I was going to ask if you can access the https://github.com/IHaskell/IHaskell/actions/caches, but I just had a look at it and it's a mess because the magic nix cache seems to create a different entry for each derivation which makes it impossible to easily determine how much space is being used.
This isn't really about space usage though, although that is a component of it. It seems to me like you're seeing additional ways to build IHaskell as an unmitigated good, and it really isn't. As I have said before, every additional check incurs a cost on each commit and additional code to maintain over time, and it's unclear to me how many people are even e.g. using the Nix expressions we bundle at all. Note that there have been a grand total of 0 issues asking how to migrate from the old release.nix to the flake, which means one of 3 things:

Nobody is using IHaskell
Nobody is using the Nix expressions
Nobody needs help despite the sweeping change
In each of these cases, in my capacity as maintainer I don't think it's appropriate to pile on even more for some hypothetical good when weighed against the very real time I spend watching paint dry as the checks complete.

I think the double repo thing could work. But there might be some easier answers too. What about making certain workflows (maybe the stack --nix and Nix ones) only run on manual dispatch? Then you could have quick feedback during day-to-day work by only running the Stack one. That's probably plenty to test for most regressions. Then, when it comes time to do a release, you can run the extra workflows and wait an hour.

I was thinking along the same lines too, but in the past we used to e.g. run the Docker build on a schedule and it was a huge pain to figure out what went wrong if/when that check failed. I might investigate something similar for the stack --nix builds but the Nix builds make good use of caching and are what I use to develop locally anyway and the Stack builds guard against regressions in older GHCs so I think it makes sense to keep both of those.

IHaskell is normally a fairly stable project, and often sees months go by without a commit. Even if CI did take an hour to complete, is that so bad if it allows IHaskell to provide generous support for different GHC versions and building methods?

Harsh but fair. Have you considered that waiting for an hour for a one-line change would be deleterious to one's motivation to work on a project? I think I've been pretty good about adding support for new GHC versions and merging changes from other contributors, but otherwise I see my role as largely keeping things working smoothly. I've also recently found myself using IHaskell less and in the meantime JupyterLab has changed out from under me with https://github.com/IHaskell/IHaskell/issues/1417 and https://github.com/IHaskell/IHaskell/issues/1419, which means that I foresee myself (or someone else) needing to make substantial changes to get things working correctly again. Yet another reason to prioritise fast CI times.
Anyway, I don't mean to be dismissive, but this PR seems like a white elephant and I don't see it being a good idea to merge.

I'll respond to this tomorrow after some sleep, but for now here's my first results. All tests are using the current state of this PR and an empty cache.
Building the Nix CI workflow takes 1h 2m 19s and puts 436MB in the cache.
Building the Stack --nix CI workflow takes TODO and puts TODO in the cache.
Building the Stack CI workflow takes TODO and puts TODO in the cache.

We already test IHaskell against both these GHC versions on Stack and Stack+Nix.

Stack+Nix is hardly a Nix build. It's only using Nix to obtain native dependencies.  Maybe the reason IHaskell doesn't seem to have many Nix users is because it's been so hard to use thus far?

Also, where does it end? IIRC you mentioned that 23.05 has GHC builds back to 8.6, so to be consistent we would want IHaskell expressions for those too?

I definitely think a common-sense tradeoff can be made. At the current moment in time I think 8.6 or 8.8 might be sensible minimum versions. More support is a good thing for users if the balance of cache time/CI time/code complexity can be managed. I don't think anyone can complain about the project being practical.

in the past we used to e.g. run the Docker build on a schedule and it was a huge pain to figure out what went wrong if/when that check failed

Well scheduled builds definitely sound like a bad idea, for the reasons you mention--and they may pollute the cache.

Harsh but fair. Have you considered that waiting for an hour for a one-line change would be deleterious to one's motivation to work on a project?

It's not an insult! Stable projects are good. Of course we should try to make you as happy as possible with your workflow. FWIW, I rarely use CI for feedback because I can just run the tests on my local machine--for most changes, it's sufficient to test a couple GHC versions that I already have cached, and then check back on CI later on just to confirm it didn't break any random older versions. I find this to be faster than even the best CI.

Anyway: my experiments above are done now and they seem to show we only need 2.5GB out of 10GB to run all the CI workflows. Maybe your recent work on improving cache usage has been more successful than you thought?

Stack+Nix is hardly a Nix build. It's only using Nix to obtain native dependencies. Stack is still running the show.

You're absolutely right, but my point is that we do test that 9.0 and 9.2 build correctly and pass all our tests. I would much rather wait for a third party to ask on the issue tracker for us to provide Nix expressions for these versions before I add them. This also raises another question: what is the value of the Stack+Nix checks if they're doing largely the same thing as the Stack builds?

I definitely think a common-sense tradeoff can be made. At the current moment in time I think 8.6 or 8.8 might be sensible minimum versions.

If you look at other Haskell developer tooling projects, they're extremely conservative with which GHC versions they support: often only 2 or 3 major versions behind the latest one. A good example is HLS, which IIRC only supports 9.2 and above. ghci, which is more similar to IHaskell than HLS is, isn't backwards compatible with older GHC versions at all. In this respect, IHaskell is already an extreme outlier. Given that we already test all the versions that we do I don't want to expand the build matrix even further, especially with no reasonable policy around when to drop support. There's also no concrete evidence that having these expressions will make anyone's lives easier.

FWIW, I rarely use CI for feedback because I can just run the tests on my local machine--for most changes, it's sufficient to test a couple GHC versions that I already have cached, and then check back on CI later on just to confirm it didn't break any random older versions. I find this to be faster than even the best CI.

I hope you don't think I just push code to a branch without running the tests first, but I would also like CI to be fast because especially when making changes to support a newer version of the GHC API I often mess up the CPP stanzas in a way that is difficult for me to test on my local machine.
It's been over 6 years now since I inherited this project, and in that time unfortunately I have accepted contributions that I have later regretted. This very strongly feels like one of those contributions: you contribute some code, I accept it, everything works and we're both happy right now; but in six months, a year, or two years from now I'm stuck maintaining it while you're off to bigger and better things. I'm not willing to put myself in that situation again.
When we first discussed this I said we could do it as a separate repository with a reasonable policy around when to drop support for older GHC builds. The current approach meets neither of those criteria.

what is the value of the Stack+Nix checks if they're doing largely the same thing as the Stack builds?

Their sole purpose is to keep the nix stanza of the stack.yaml from bitrotting. For that reason I think they don't at all need to run on every push. A very easy tweak would be to run them less frequently, perhaps only as part of a release process.

There's also no concrete evidence that having these expressions will make anyone's lives easier.

They would make my life easier... especially with the project to integrate more IHaskell kernels into Nixpkgs.

This very strongly feels like one of those contributions: you contribute some code, I accept it, everything works and we're both happy right now; but in six months, a year, or two years from now I'm stuck maintaining it while you're off to bigger and better things. I'm not willing to put myself in that situation again.

FWIW, I have no plans to stop being invested in IHaskell.
I find this kind of an unfair characterization of this PR:

It is less than 30 lines of actual overlay code, which restores functionality to 2 whole GHC versions with Nix
It shows how to combine Cachix with the magic Nix cache in order to lighten the load on Cachix, which is something I understood that you wanted.
Per the numbers posted above, we're currently using 20% of the available cache before this PR. If accepted, this PR would take it to 25%. Still plenty of headroom if you ask me.
If you combine this with my other two suggestions, you would have an even leaner and faster CI. To be clear, these are

Don't run the Stack+Nix pipelines on every push, and
Drop super old GHC versions from the Stack pipeline

A very easy tweak would be to run them less frequently, perhaps only as part of a release process.

Hackage heavily discourages any sort of automated release process, which is why we don't have one (source: I am a Hackage trustee). This is a non-starter. The only option is to run them on a schedule, which has problems we've discussed above.

They would make my life easier... especially with the project to integrate more IHaskell kernels into Nixpkgs.

I don't really see how: if that project takes off, the additional expressions are going to make it into Nixpkgs. We don't do anything fancy on our end when building IHaskell that would make including the expressions here a priority AFAIK. It's possible I'm missing something here.

FWIW, I have no plans to stop being invested in IHaskell.

That's great to hear, but I can't rely on that. Things change, sometimes suddenly and unexpectedly.

It is less than 30 lines of actual overlay code, which restores functionality to 2 whole GHC versions with Nix

This is disingenuous. As I have pointed out before, these are additional checks that run on every commit, and additional code that someone will have to maintain over time indefinitely.

It shows how to combine Cachix with the magic Nix cache in order to lighten the load on Cachix, which is something I understood that you wanted.

I must have been unclear, I never wanted this. The increase in cache utilisation is one of multiple reasons I was against testing Nix expressions for older GHC versions, as I have been from the beginning.  The magic Nix cache is very cool tech but completely pointless if you want to put the built artifacts in a binary cache for other people to use. I think we have differing opinions on the utility of this, but my position is that if it is generally useful then it should be in a publicly available binary cache. I don't think these additional Nix expressions need to be in the cache, but that is because I don't think they need to be tested at all.

Per the numbers posted above, we're currently using 20% of the available cache before this PR. If accepted, this PR would take it to 25%. Still plenty of headroom if you ask me.

That's only after I spent most of the day yesterday working on this. Not the most compelling argument if you ask me :smile:.
My numbers are substantially different:
gh cache list --order desc --sort size_in_bytes --limit 99999999 --json sizeInBytes | jq -r 'map(.sizeInBytes) | add' | numfmt --to=iec
5.7G

and I would expect this to increase over time, especially if I try other strategies to decrease CI time later.

If you combine this with my other two suggestions, you would have an even leaner and faster CI.

Frankly these are bad suggestions. I've explained above why I can't drop Stack+Nix on every push, and I'm not going to drop old GHC versions from the Stack pipeline because that would effectively mean they are no longer supported.
At one point you mentioned you have your own fork? I think this change is a great candidate for inclusion there. If it gains traction and other people see a need for it I'm happy to revisit including it here, but I think I've made myself clear for now.

All right, I'll just run this stuff in my own fork. A few more responses for what it's worth --

Hackage heavily discourages any sort of automated release process

Automated? When did I say automated? I simply mean that you might run the Stack+Nix workflow via manual dispatch before cutting a new release. Or I don't know, configure it to run only on pushes to release branches. There are so many things you could do here besides test Stack+Nix on every push to master. Frankly I wouldn't have put forward #1429 at all if I had known the cache/CI time was so scarce and it would cause such problems.

As I have pointed out before, these are additional checks that run on every commit, and additional code that someone will have to maintain over time indefinitely.

I'd just like to point out that before I started this recent set of refactors, the Nix expressions were a messy series of copy-paste jobs. According to cloc that single PR #1425 brought the repo's lines of Nix code from 511 to 385, a savings of 25%. I think I am on the side of the angels here.
If I were allowed to keep going, I would reduce the repo's Nix code still further. For example, I notice that you updated to Nixpkgs 23.11, but don't seem to have adjusted the overlays to take into account new package versions. There are likely lines now in the 9.8 overlay that can be removed; I've been meaning to look into this.

That's only after I spent most of the day yesterday working on this. Not the most compelling argument if you ask me 😄.

Well...yes. You did good work and you improved the amount of cache headroom. Now there is room to cache more things.

I'm not going to drop old GHC versions from the Stack pipeline because that would effectively mean they are no longer supported.

You were arguing earlier in this thread that IHaskell shouldn't be expected to support tons of GHC versions, and you've mentioned a couple times the need for a reasonable GHC deprecation policy. I agree with you. I would just suggest that such a policy isn't going to fall out the sky. You have the power to define the reasonable GHC deprecation policy. And at the current moment in time, IMO, such a policy probably would not support GHC 8.0, and probably would support 9.0.

I'd just like to point out that before I started this recent set of refactors, the Nix expressions were a messy series of copy-paste jobs. According to cloc that single PR https://github.com/IHaskell/IHaskell/pull/1425 brought the repo's lines of Nix code from 511 to 385, a savings of 25%. I think I am on the side of the angels here.

This is unfair and a short-sighted way of looking at things. Before your refactors (which weren't purely refactors because they substantially changed how things worked), we had a couple of self-contained release*.nix files and a flake.nix file (an example of an ill-considered external contribution that I did not have the expertise to maintain over time). I could have split things up into multiple files to reduce duplication, but I always considered the newer files temporary workarounds for issues in nixpkgs that I would eventually be able to delete entirely so I didn't see the point (also they would no longer be self-contained).
Now actually using the Nix expressions you've written is more verbose than using the old ones was, so the line count improvement is illusory. I would argue that the new situation is in fact more complicated than the old one because I have to look at multiple files to figure out what is actually happening.
It seems like you have a particular idea of how you want the Nix expressions to work, which is different from mine, and that's completely fine, but saying you are on the side of angels is simply not true.


Allow configuring AMQP Web Sockets usage

This PR aims to fix #396
It also replugs all the event handlers lost on the OptionForm
Screenshots
Amqp setting is now enabled:

Amqp settings and Connectivity mode are now taken from the options:

:white_check_mark: Build ServiceBusExplorer 4.2.0-amqp.59.build.653 completed (commit https://github.com/paolosalvatori/ServiceBusExplorer/commit/95ab4a0c27 by @)

Thanks @Greybird :) We crossed PRs and I already restored event handlers in the new version of the Options form :) See #436

:white_check_mark: Build ServiceBusExplorer 4.2.0-amqp.70.build.677 completed (commit https://github.com/paolosalvatori/ServiceBusExplorer/commit/dd6f989af1 by @)

Sure, here it is. I rebased on borders branch.
I did not recognize your numbers on spacing/locations you gave me, but like in #436, I think it should be consistent.
Note that this PR will conflict with #436, but the merge will impact two files, and be really easy

:white_check_mark: Build ServiceBusExplorer 4.2.0-amqp.60.build.679 completed (commit https://github.com/paolosalvatori/ServiceBusExplorer/commit/d90470c153 by @)

:white_check_mark: Build ServiceBusExplorer 4.2.0-amqp.60.build.680 completed (commit https://github.com/paolosalvatori/ServiceBusExplorer/commit/a3f48e4c49 by @)

We need someone else (@SeanFeldman  or @ErikMogensen) to review and approve. I checked the the OptionsForm.Designer.cs and it looks this version includes my changes :)

Just resolved the merge conflict, sorry @SeanFeldman , @ErikMogensen , @paolosalvatori , reviews have been reset as a consequence...

:white_check_mark: Build ServiceBusExplorer 4.2.0-amqp.62.build.683 completed (commit https://github.com/paolosalvatori/ServiceBusExplorer/commit/37bdd2c67a by @Greybird)


request help: PostResponse not support    ''getBody()" ?

Issue description
    如何可以从接口的响应体中获取数据?

Environment
   apisix: 3.0
   jdk: 11

your apisix-java-plugin-runner 0.4.0

'CHANGELOG.md'  say   version 0.4   support for getting upstream response body.
but PostResponse not support ''getBody()"?

已解决


Service and Operation Handlers

What was changed
This contains the initial version of operation handlers. This is a pretty significant chunk of new code and many design decisions were made during the development that should be reviewed here. This is a follow-on from the now-closed #2 which had a much more primitive form that did not include the actual handling logic.
Note, there are many tests missing that I will add while this PR lives. But it can still be reviewed in the meantime.

Can we define the standard Nexus headers. for the Java SDK I at least need HeaderRequestTimeout

Some changes:

Added OperationHandlerException
Removed OperationNotFoundException and UnrecognizedOperationException in favor of the above
Added Header class with a single string constant for the Request-Timeout header (I don't like this one and would prefer implementers make their own constants for all HTTP headers needed including this one, but did it anyways)

Think this looks good, just trying to use the latest commit in my Nexus POC branch https://github.com/temporalio/sdk-java/compare/master...Quinn-With-Two-Ns:sdk-java:nexus-sdk

:+1: I will hold this PR open for a bit longer. Then we can fix/improve anything post merge

Verified it with my nexus POC branch FWIW

:+1: Merging, but this is more the beginning than the end. We obviously need a lot more tests here, but I think that should come about when a Nexus client and server get added here.


Xtokens Polkadot 1.5 XCM with Different Reserves

As part of https://github.com/paritytech/polkadot-sdk/commit/e7651cf41b2d775dedcc897e17ead16e200a4fff - pallet XCM now allows to send reserve and non-reserve assets in a single XCM message.
Nevertheless,  Xtokens requires that both the asset and feeAsset should come from the same reserve - https://github.com/open-web3-stack/open-runtime-module-library/blob/master/xtokens/src/lib.rs#L549-L554
It would be great if Xtokens supports the scenario that is supported now by pallet-xcm

Yeah we can add this

Actually, can you elaborate a bit more about this issue? In what case that pallet-xcm is supported but xtokens is not?
https://github.com/paritytech/polkadot-sdk/blob/5c79ed37dc6485d2b3f4fc69b8cf8456b86b4e17/polkadot/xcm/pallet-xcm/src/lib.rs#L1479-L1481 it looks to me also doesn't support sending assets with different reserve in a single call.

Hey @xlc  - The PR I referenced in the initial comment adds the new  transfer_asset  function that, from what I understand, supports transferring assets from different reserves.
@Agusrodri tried this already on an internal network, and it worked.
This is the function: https://github.com/paritytech/polkadot-sdk/blob/5c79ed37dc6485d2b3f4fc69b8cf8456b86b4e17/polkadot/xcm/pallet-xcm/src/lib.rs#L1287

I can't find the code in asset_transfer that does the magic. Could you provide an example of the usage in your internal network? What kinds of assets are been transferred?

Hey @xlc! Here is a test that checks the following scenario:

Send two tokens (ParaAToken and ParaBToken) from an account on para A to an account on para B (A -> B).
Chain A is the reserve for ParaAToken.
Chain B is the reserve for ParaBToken.

The new extrinsic transfer_assets allows to actually combine fee assets and non-fee assets in several ways. This use case is just one of them.
In this case, the asset used to pay fees is ParaAToken, and the process of actually "sending" this asset is done by depositing the remaining amount in the destination account after paying for fees with it, so you end up having both ParaAToken and ParaBToken in the destination account.
Of course, for this use case to work, both chains have to support each corresponding foreign asset.

Thanks for the example. I have identified a few improvements that we need to do to support such use case:

Improve fee asset handling for multi-hop transfer. Currently we use MinXcmFee to calculate the dest fee and assume the rest are the fee for the intermediary transfer. We should make it in such way that it to queries the intermediary fee instead and then deposit the rest to dest so we can actually perform transfer of the fee asset.
Use the new trait config in XcmExecutor to detect asset type if is teleport or reserve transfer
Identify the case that we only need a single xcm transfer instead of two

A quick update. I started the refactor work to improve xtokens based on the asset_transfer implementation. However, recently there are also few more issues and improvements have been raised about the asset_transfer. So I will wait a bit and see how it goes.
Also the complexity of this is kinda getting out of control and that means something is wrong. Not sure if there is anything we can do though.

With all the additional complicated requirements, I am considering maybe we should just deprecate xtokens and use pallet-xcm instead. xtokens is built because there was no pallet offers such functionality. Now that pallet-xcm should support all the transfer needs, I don't feel the needs to support an alternative implementation.

I agree. I think Moonbeam is moving away from Xtokens in favor of Pallet XCM.

@albertov19 @xlc is there any update around this?
Note that the incoming 1.2.4 release will implement a new interface from pallet XCM which will allow all the scenarios mentioned above plus many more complex cases.

I think it is best to keep xtokens as it is for compatibility reason and for new use cases, use new features from the pallet-xcm


Changing Xamarin.Forms to support offline sync

Hi @fabiocav, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

In order for us to evaluate and accept your PR, we ask that you sign a contribution license agreement. It's all electronic and will take just minutes. I promise there's no faxing. https://cla.azure.com.

TTYL, AZPRBOT;


Fix wedge coordinate overwrites for Android

My last Color is dominating the pie chart, The last color, in this case green is overriding the rest of the colors, Am i doing something wrong?
this is my android chart

ios chart

const data = [
  [0, 1],
  [0, 1],
  [0, 1],
  [0, 1]
]
...
  <Chart
          style={styles.chart}
          type="pie"
          data={data}
          sliceColors={['blue', 'yellow', 'red', 'green' ]}
          showAxis={false} />

I should have a fix for android pie charts pushed tomorrow. I'm aware there
is an issue with them at the moment :(
Tom
On Mon, Jun 20, 2016 at 4:43 PM, Bryant O<EMAIL_ADDRESS>wrote:

My last Color is dominating the pie chart, The last color, in this case
green is overriding the rest colors, Am i doing something wrong?
this is my android chart
[image: screen shot 2016-06-20 at 2 40 03 pm]
https://cloud.githubusercontent.com/assets/11641048/16209659/477ae7ba-36f5-11e6-9215-6cb7ffe6720e.png
ios chart
[image: screen shot 2016-06-20 at 2 39 55 pm]
https://cloud.githubusercontent.com/assets/11641048/16209668/550484fe-36f5-11e6-85c4-453c44febebe.png
const data = [
[0, 1],
[0, 1],
[0, 1],
[0, 1]
]
...
<Chart
style={styles.chart}
type="pie"
data={data}
sliceColors={['blue', 'yellow', 'red', 'green' ]}
showAxis={false} />
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/tomauty/react-native-chart/issues/85, or mute the
thread
https://github.com/notifications/unsubscribe/ABD7KLvDGkOJaLR_2fcpz54B7m5a7VPxks5qNvuCgaJpZM4I6Guf
.

@tomauty Thanks for being so on top of this. Much appreciated!

Hi
I am also getting this issue. Have you got any solution for this?

@JagdishUpadhyay I have updated to 1.0.7-beta and Im still having the issue, anybody having any luck with this?

@boblad I am also waiting for the solution

Hi, looking into this still. I'm going to see if wedge drawing is fixed in a newer RN version, and what they might've merged to make it work properly.

@boblad how do you make the donut shape for pie chart?

Hi,can I use react-native-chart for android project?It seem some behaviors different form ios,right?

Yes, you can. However this issue is still live on Android.

@doddys I do a position absolute child view with a background color of white, (in this example),
here's some sudo code so you get the idea. fill in variables as you would like.

const chartStyle = {
   width: chartWidth,
   height: chartWidth,
   justifyContent: 'center',
   alignItems:'center'
};

const centerStyle = {
      width: chartWidth - chartThickness,
      height: chartWidth - chartThickness,
      borderRadius: ((chartWidth - chartThickness) / 2),
      backgroundColor: WHITE,
      position: 'absolute',
      top: (chartWidth / 2) - ((chartWidth - chartThickness) / 2),
      left: (chartWidth / 2) - ((chartWidth - chartThickness)/ 2),
      justifyContent: 'center',
      alignItems: 'center'
}

<View style={chartStyle}>
    <Chart
          style={chartStyle}
          type="pie"
          data={some data}
          sliceColors={[list, of, colors]}
          showAxis={false} />
    <View  style={centerStyle}/>
</View>

this is the basic idea, Im sure there are better implementations and i might not need all of the style properties but this was my approach. Hope this helps.

@tomauty Any clues as to what could be causing this?

Any news about this issue? I am having the same problem here on android, while on iOS the pie chart works nicely.

@jplethier @boblad have you got any solution??

Hi,
any update on this?

I'm going to move our ART dependency to react-native-svg. Hopefully this resolves it...

Thanks for your answer, any approximate ETA for this transition? I know this must be a heavy rewrite, good luck for the implementation :-)

No update yet. Probably next week. Line charts on svg are mostly done. Bar,
pie, and multi line are scheduled for next week. Apologies for holding this
lib up for so long. Turns out ART primitives are a bit lacking for a
project of this scope.
On Sunday, August 28, 2016, Michael Lumbroso<EMAIL_ADDRESS>wrote:

Thanks for your answer, any approximate ETA for this transition? I know
this must be a heavy rewrite, good luck for the implementation :-)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tomauty/react-native-chart/issues/85#issuecomment-242969214,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABD7KNE5HYpvUsoHeP4Qi8khjDu2X4kpks5qkW39gaJpZM4I6Guf
.

--
Tom

Hi @tomauty
I couldn't figure out from the commits if you managed to solve the issue. Anything I can do to help you? Some testing or investigation?
Thanks for your great work :-)

Hey, wondering if there's any update on this bug.
Thanks for making this library, It has been extremely helpful!

Other pie modules only have the same issue. Does it have any update?

I published a PieChart component works on both iOS and Android perfectly
https://github.com/nihgwu/react-native-pie

As a generic FYI — I am no longer able to maintain this library. I recommend checking out victory-native as it's much more maintained.


#Fix issue of FAILED CREATE CHS Docs <安全配置检查报告.docx>

fixed bash " pip3 install -r requirements.txt " issue as below

Thanks. Issue is fixed based on your suggestion.


Migrate to new ClinVar XML

ClinVar has announced changes to their XML to better support somatic variants in fall 2023, though support for the current format should continue at least through the end of the year. See here for sample data and explanation of the changes.
We should look into the changes, migrate our pipelines/parsers so they continue to work, and also investigate whether there's anything new that we're interested in extracting.

Date of change will be January 29, 2024

Relevant changes:

FTP path changes - minor but will need to change in the SOP/Nextflow. Interestingly, that page also states that the VCV XML (aggregated by variant rather than variant/condition) is more widely used than the RCV and they encourage us to switch...

Clinical significance - now called classification and reported differently. We will need to update the parsers and probably add new terms to the JSON schema.

Old clinical significance:
<ClinicalSignificance DateLastEvaluated="2018-04-25">
    <ReviewStatus>no assertion criteria provided</ReviewStatus>
    <Description>Benign</Description>
</ClinicalSignificance>

New clinical significance - germline:
<Classifications>
    <GermlineClassification>
        <ReviewStatus>criteria provided, single submitter</ReviewStatus>
        <Description DateLastEvaluated="2019-02-02" SubmissionCount="1">Pathogenic</Description>
    </GermlineClassification>
</Classifications

Germline records should use the same terms as before, just in a different XML element.
New clinical significance - somatic:
<Classifications>
    <SomaticClinicalImpact>
        <ReviewStatus>criteria provided, multiple submitters, no conflicts</ReviewStatus>
        <Description ClinicalImpactAssertionType="diagnostic"
            ClinicalImpactClinicalSignificance="supports diagnosis" SubmissionCount="1"
            DateLastEvaluated="2016-11-05">Tier I - Strong</Description>
        <Description ClinicalImpactAssertionType="therapeutic"
            ClinicalImpactClinicalSignificance="resistance" SubmissionCount="1"
            DateLastEvaluated="2016-12-16">Tier II - Potential</Description>
    </SomaticClinicalImpact>
    <OncogenicityClassification>
        <ReviewStatus>reviewed by expert panel</ReviewStatus>
        <Description DateLastEvaluated="2016-03-01" SubmissionCount="1">Oncogenic</Description>
    </OncogenicityClassification>
</Classifications>

Somatic records use a new set of clinical impact and oncogenicity terms, more details are in the link above. We might want to discuss with OT how we want to incorporate these, e.g. by including them in the same or a separate field in the evidence.

Another potentially relevant change hidden in the last bullet point here, that the aggregated observations might change for somatic records and might be removed altogether in the future. We currently use the RCV/ObservedIn element in two places:

pubmed refs - might be a problem if they get rid of it in the RCV altogether and we have to refer to the SCVs
allele origins - lots of previous discussion around values in this aggregated field, see for example the visualisation and tables of inconsistent values.  Might want to prioritise #286 in light of this.

I don't know if I understand exactly the impact of excluding the somatic SCVs in the aggregation (the example RCVs still just contain somatic as the origin and don't contain any pubmed ids), but we should look into it and perhaps email ClinVar to ask.

For ease of reference...

Somatic clinical impact terms: AMP/ASCO/CAP Tiers (PMID 27993330)

Tier I - Strong
Tier II - Potential
Tier III - Unknown
Tier IV - Benign/Likely benign

Assertion types for clinical impact:

For therapeutic: sensitivity/response; resistance; reduced sensitivity
For diagnostic: supports diagnosis; excludes diagnosis
For prognostic: better outcome, poor outcome

Oncogenicity terms: ClinGen/CGC/VICC recommendation (PMID 36063163)

Oncogenic
Likely oncogenic
Uncertain significance
Likely benign
Benign

@tcezard @DSuveges @ireneisdoomed @tskir
So I know you were all excited to have another notebook to review, but I will have to disappoint you as I did not find any of the new clinical significance terms (now called classifications) in the newly released XML! All the previous clinical significance terms seem to have been renamed to GermlineClassification, no records have somatic or oncogenicity classifications.
I've emailed ClinVar as to whether this is expected but have not heard back yet. Meanwhile I did some more digging around and found this line in their web release notes:

Any data that were previously displayed as "Interpretation" are now displayed as "Germline classification". A small number of those classifications may
truly be classifications in the somatic context; our team will contact the appropriate submitters to offer assistance with updating these records.

So I think this is actually expected: the classifications may be modified for some older records, but otherwise this is mainly to support new somatic submissions. I am still confused by what they mean by a "small number" of classifications being in the somatic context, since we know there are plenty of records that have somatic allele origins yet are being given germline classifications, e.g. RCV000014915. Hopefully they will be able to clarify this.
The other thing I've seen on their blog is that they're extending support of the old XML format till June 2024, which is not unexpected for such a large change...
If the somatic classifications will only be applicable to new submissions, then I guess we'll just have to keep an eye on how the data evolves. One option is to actually update the parsers to produce the same output from the new XML, since the actual data is still the same (no issues with multiplicity and so on), and provide a warning and/or skip records if the new fields show up. This way we'll at least know when we need to start looking into the data, and meanwhile can continue to process all old data and new germline data.
Let me know your thoughts and whether there's anything else worth looking into or asking ClinVar.
(P.S. The only thing relating to this that we should still discuss is how to handle this case from the last submission, as presumably this value no classifications from unflagged records will still occur in the new XML.)


Trigger in source not being dropped

Hi Kamil
I have come across an issue where a trigger does not exist in the source but it isn't being removed from the service after the deployment. It is worth noting that it worked when the trigger in the service was stopped but not when it was started.
Here is the ADF deployment log from Azure DevOps:

When I check the Git repo, the trigger is not there

When I check the service post deployment, the trigger still exists

Thanks a lot

@daveschnee thanks for raising this issue, I will investigate that and back to you soon.

Thanks so much for looking into this so quickly Kamil, really appreciate it
On 6 Jun 2020, at 07:15, Kamil Nowinski<EMAIL_ADDRESS>wrote:

Closed #17https://github.com/SQLPlayer/azure.datafactory.tools/issues/17 via #20https://github.com/SQLPlayer/azure.datafactory.tools/pull/20.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/SQLPlayer/azure.datafactory.tools/issues/17#event-3413664110, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEVIFFQ5TCA7FV4G2EXZKYLRVF37JANCNFSM4NSLAGKQ.

Happy to help and thanks for taking all details. It wasn't easy to find this scenario.


Enums with arbitrary types

Thank you for the great project!
I wanted to create an enum which had a Vec as a parameter:
from borsh_construct import Enum, Vec, U8
EnumWithVec = Enum(
    "VecTag" / Vec(U8),
    enum_name="Instruction"
)

This gives me ValueError: Unrecognized variant type: <class 'construct.core.FocusedSeq'>.
In Rust, this is a perfectly acceptable type.
I'm willing to implement such a feature myself, especially if somebody can guide me with an architectural plan.

@kevinheavey Could you, please, take a look?

@2torus you can just wrap it in a TupleStruct:
from borsh_construct import Enum, Vec, U8, TupleStruct
EnumWithVec = Enum(
    "VecTag" / TupleStruct(Vec(U8)),
    enum_name="Instruction"
)

This is what it's like in Rust too: every enum variant is a struct (either a unit struct, tuple struct or C-like struct).
Though I will concede that writing these enums in Rust is a lot more elegant. I'm trying to think now if it would be good for borsh-construct to automatically wrap things in a TupleStruct when needed so that your initial code would just work.

I'm trying to think now if it would be good for borsh-construct to automatically wrap things in a TupleStruct when needed

My conclusion is that this would be bad as it enables a lot of accidents


Move ext-* to the suggest section

Fixes https://github.com/diablomedia/zf1-soap/issues/3

Codecov Report

Merging #4 into master will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master       #4   +/-   ##
=========================================
  Coverage     90.97%   90.97%
  Complexity      469      469
=========================================
  Files            14       14
  Lines          1263     1263
=========================================
  Hits           1149     1149
  Misses          114      114

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 6f43d9f...50c21bc. Read the comment docs.


Add a Completion note system to Template_Character

Is on hold for awhile, this is a more complicated task than some of the other features.

repentogon now does this by default


cannot open device with vendor id 0x1770 and product id 0xff00

Issue
Trying to run msi-keyboard-gui from 1.4 pre-built binaries on an MSI GE60 laptop(model: MS-16GC) and receiving the following error even when running using sudo:
cannot open device with vendor id 0x1770 and product id 0xff00
System versions:  Manjaro Linux
nodejs: 7.10.0-2
npm: 4.6.1-1
libusb: 1.0.21-1

did you install libusb-dev?

Hi, I have a MSI VR Ready GS43VR Phantom Pro-006 running kali linux and I have all of the requirements installed and I run it as root and get the same error. has anyone found an fix for this ?

I seriously hope that kali is not your main OS. if it is.... yikes...
Did you install libusb-dev?

yes I have libusb-dev? installed

can you install and run the core library and example?
https://github.com/stevelacy/msi-keyboard
https://github.com/stevelacy/msi-keyboard/blob/master/examples/color.js


Issue 129 fix

#129 is fixed
## AUTO-TYPE FEATURE WILL MAKE THE SITE MORE ACTIVE

## GITHUB CONTRIBUTORS IS AUTOMATICALLY SYNCED

## IMAGE DYNAMICALLY CHANGES TO THE THEME

Wow great work, looks amazing in about page


Adding  difference in percentage values for multi-bar chart.

What problem does this feature solve?
The user can see the difference in percentage values between two charts in a multi bar chart.
What does the proposed API look like?
We need to find the difference between the the two bars and find the difference and show it on top of the two bars.

Use https://echarts.apache.org/en/option.html#series-bar.markPoint and set it's data to be the percentage. If you want the shape as in the image, set https://echarts.apache.org/en/option.html#series-bar.markPoint.symbol to be the SVG path value.


[Gekidou] Add performance and code improvements around post_list

Summary
Add several performance and code improvements.
Wait for comments for more details.
Release Note
None

As far as I know, strictMode is not necessary to avoid the re-renders we were experiencing. Not sure if it will have any other upside down the road, but right now is not necessary.

Building app in separate branch.

Successfully building:
https://circleci.com/gh/mattermost/mattermost-mobile/21400
https://circleci.com/gh/mattermost/mattermost-mobile/21399

Building app in separate branch.

Successfully building:
https://circleci.com/gh/mattermost/mattermost-mobile/21406
https://circleci.com/gh/mattermost/mattermost-mobile/21405

Artifact links:
https://output.circle-artifacts.com/output/job/dc7aba89-9740-4ef7-8b55-ff56eb42f9c3/artifacts/0/tmp/artifacts/Mattermost_Beta.ipa
https://output.circle-artifacts.com/output/job/73d04d40-7121-4f77-9d7c-f470893fd087/artifacts/0/tmp/artifacts/Mattermost_Beta.apk

Building app in separate branch.

Successfully building:
https://circleci.com/gh/mattermost/mattermost-mobile/21412
https://circleci.com/gh/mattermost/mattermost-mobile/21411

Artifact links:
https://output.circle-artifacts.com/output/job/c91dbd10-8431-4c07-9aa7-3cf4dead9077/artifacts/0/tmp/artifacts/Mattermost_Beta.apk
https://output.circle-artifacts.com/output/job/30a6a95b-c0e6-4b79-a7ef-2aad39ab0164/artifacts/0/tmp/artifacts/Mattermost_Beta.ipa


BUG🐛: Fixed scale related bugs in LoKr | Added rank_dropout_scale parameter

This PR adds a new parameter rank_dropout_scale and fixes scale related bugs in the LoKr. Please refer to the following function in Lycoris:
https://github.com/KohakuBlueleaf/LyCORIS/blob/258387f586beabfca71646a9671027f75ed34597/lycoris/modules/lokr.py#L347

@BenjaminBossan  Please review the minor corrections to the LoKr. The default initialization of W1 matrix is zeros and I am not sure to change it or not. Also shall I rewrite this LoKr implementation to remove lycoris dependency as I can use most of the LycorisLokr implementation code.

I'm not sure what you mean by this, could you please elaborate.

I meant to say, we still have lycoris_utils dependency. Also the codebase is kind of old for LoKr. Since I have updated the codebase of LoKr w.r.p latest PEFT standards in LycorisLoKr #2133, It would be simple copy paste and we don't need a seperate implementation

Hmm makes sense given LoKr/LoHa is used less frequently. Then I will make the suggested changes and also will once look at LoHa if the same bugs are present in that too or not. The big question is what to do with LycorisLoKr #2133 :sweat_smile: . Shall I close it since we are using very little of lycoris package to have the feature what we thought and rewriting the LoKr also reaps very little benefit.

@BenjaminBossan Done with suggested changes :white_check_mark:

I'd say leave it as is. What I think could be useful is to add a new option to the config that allows users to use the lycoris way of layer initialization, then they have a choice of which one they want. That could be done in a separate PR.

A separate flag is not needed, they can pass init_weight=False to initialize with random weights instead of zero weights.

A separate flag is not needed, they can pass init_weight=False to initialize with random weights instead of zero weights.

What I meant is that we found that lycoris initializes layers a bit differently than PEFT, as I mentioned on the other PR:

In PEFT, at the start, we initialize w1 to zeros and w2_a and w2_b randomly. LyCORIS, however, initializes w2_b to zeros and w1 and w2_a randomly.

We could have an init option like init_weights = {True, False, "lycoris"} and if the latter is chosen, we initialize the same way as lycoris does.

@BenjaminBossan Added the testcases, please review it.

@BenjaminBossan  The doc string changes are Addressed.

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

Again, thanks so much @yaswanth19 for implementing these fixes and enhancements for LoKr. Since there hasn't been any further feedback, I decided to merge now.
LMK if you plan on working on further fixes for LoKr or LoHa. Ideally, we could have them all in the same PEFT release, as users may have to retrain their models, depending on the type of fix.

@BenjaminBossan I don't have any plans to work this immediately, probably it would be best if somebody else can pick this so to have the changes in the same release

All right, thanks for letting me know.


Styling markers

In Chrome I can hide the detail markers using:
details::-webkit-details-marker {
    display: none;
}

Will this script handle a scenario like that?

Being that Chrome is natively supportive of details tags, this script (and associated css) should have no effect in Chrome.

Sorry I should have been more clear - I meant to say "Can we hide the markers in IE as well?" I think I found the answer already, by removing the lines in the CSS that style the markers. Thanks!


fix: allow the functions on Archive to be called multiple times

fix: allow the functions on Archive to be called multiple times


Y24-320 - modify sample sheet behaviour so that Revio sample sheets behave as untagged when the behaviour is set to hidden

Closes #
Changes proposed in this pull request

Instructions for Reviewers
[All PRs] - Confirm PR template filled
[Feature Branches] - Review code
[Production Merges to main]
    - Check story numbers included
    - Check for debug code
    - Check version

I think this is probably fine but it does mean tagged? is no longer just whether the aliquot has a tag or not which might be confusing.
I haven't really looked into this so ignore if irrelevant but could you do something in the sample sheet aliquot concern

I had a look. There is a lot of indirection and obfuscation so there were a few different methods which led to checking whether there is a tag and I couldn't quite work it out. I have created a story #1443 to refactor it.


Implemented properly streams closure after running cmd in JavaScript

Description
After running cmd execution for JS, the received inputStream and errorStream are closed properly.
Fixes #1591
Type of Change

Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?
Manually
Checklist:

[x] The change followed the style guidelines of the UTBot project
[x] Self-review of the code is passed
[x] No new warnings
[x] All tests pass locally with my changes

@rudolf101 @denis-fokin Could you please add corresponding component label? (comp-...)

Fixed remarks, ready for review


Client build tools

Problem description:
The old build tools was using Gulp and only Concat the files.
Suggested solution:
Replace with webpack or rollup.js

Since we are breaking out the Front-End application to status-board-ui.
This issue should be moved to status-board-ui also.


Add version: TopazLabs.TopazPhotoAI version 0.6.0

Pull request has been created with Komac v1.11.0 :rocket:
Microsoft Reviewers: Open in CodeFlow

Automatic Validation ended with:

Installation failed with exit code -1978335226 2024-01-25 13:26:38.983 [FAIL] D:\a_work\1\s\external\pkg\src\AppInstallerCommonCore\DODownloader.cpp(267)\WindowsPackageManager.dll!00007FF8369BA384: (caller: 00007FF8369BAD01) Exception(1) tid(604) 80D02002  2024-01-25 13:27:27.180 [CLI ] ShellExecute installer failed: 1603 CustomAction DownloadModelsAction returned actual error code 1157 (note this may not be 100% accurate if translation happened inside sandbox) MSI (s) (08:A8) [13:27:26:707]: Product: Topaz Photo AI -- Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action DownloadModelsAction, entry: DownloadModels, library: C:\Windows\Installer\MSI3E5F.tmp  Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action DownloadModelsAction, entry: DownloadModels, library: C:\Windows\Installer\MSI3E5F.tmp  Property(S): ErrorDialog = ErrorDlg MSI (s) (08:A8) [13:27:26:895]: Windows Installer installed the product. Product Name: Topaz Photo AI. Product Version: 0.6.0. Product Language: 1033. Manufacturer: Topaz Labs LLC. Installation success or error status: 1603.

(Automated response - build 655.)

Manual Validation ended with:

9:11:44 AM: Product: Topaz Photo AI -- Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action DownloadModelsAction, entry: DownloadModels, library: C:\Windows\Installer\MSIDE7E.tmp

(Automated response - build 655.)


Taidha Covington wrong waypoint code.

Hi guys, when you click on "copy waypoint code" on Taidha event at the event tracker, it gives to you the waypoint code [&BNQCAAA=] but I think it should give you this one [&BKgBAAA=]

Yup. Good catch. I'll have a fix in for the next release.
In the mean time, you're welcome to fix this for yourself as well by editing the AdjustedEventTimeTable.xml or StandardEventTimeTable.xml files (depending on which you use, standard vs adjusted). The waypoint codes used by the program for the world events are stored in these files in the <Waypoint></Waypoint> tags.

Yup. Good catch. I'll have a fix in for the next release.
In the mean time, you're welcome to fix this for yourself as well by editing the AdjustedEventTimeTable.xml or StandardEventTimeTable.xml files (depending on which you use, standard vs adjusted). The waypoint codes used by the program for the world events are stored in these files in the <Waypoint></Waypoint> tags.

El 01/01/2015 23:15, "shurne"<EMAIL_ADDRESS>escribió:

Fixed with commit 9174995
https://github.com/SamHurne/gw2pao/commit/9174995176bd451480726fdf0b50759d19d98898
—
Reply to this email directly or view it on GitHub
https://github.com/SamHurne/gw2pao/issues/8#issuecomment-68500192.

thanks dude, gj!!
El 01/01/2015 23:15, "shurne"<EMAIL_ADDRESS>escribió:

Fixed with commit 9174995
https://github.com/SamHurne/gw2pao/commit/9174995176bd451480726fdf0b50759d19d98898
—
Reply to this email directly or view it on GitHub
https://github.com/SamHurne/gw2pao/issues/8#issuecomment-68500192.


Test workflows for cluster deletion branch

Codecov Report
Base: 61.24% // Head: 8.26% // Decreases project coverage by -52.97% :warning:

Coverage data is based on head (002f21b) compared to base (5476691).
Patch has no changes to coverable lines.

Additional details and impacted files
@@            Coverage Diff             @@
##             main   #1974       +/-   ##
==========================================
- Coverage   61.24%   8.26%   -52.98%
==========================================
  Files         179      93       -86
  Lines       14523   10111     -4412
==========================================
- Hits         8895     836     -8059
- Misses       4525    9220     +4695
+ Partials     1103      55     -1048

Flag
Coverage Δ

acceptance-api
?

acceptance-apps
?

acceptance-cli
?

unittests
8.26% <ø> (ø)

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

 Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

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


Unable to disable sticky scroll

Microsoft PowerToys version
0.81.0
Installation method
Microsoft Store
Running as admin
No
Area(s) with issue?
Peek
Steps to reproduce

Open an coding file (xsd, xml, c#, ...)
Scroll down until the sticky header appears
Right click on it and click on sticky scroll.

✔ Expected Behavior
Sticky scroll should be disabled.
❌ Actual Behavior
The dropdown menu appears behind the text so it's not interactable.
https://github.com/microsoft/PowerToys/assets/80769556/98cf011e-83b3-47db-80a6-1f83aff1ec39
Other Software
No response

@Aaron-Junker maybe something for you?

I updated to 0.83.0
Now the contextmenu shows in front of the window ... but it still isn't working @w@
https://github.com/user-attachments/assets/26b617a3-0e4b-4d76-bc0c-24eaebbb39b8


redirect with cookie and Vuex

Version
6.0
What is expected ?
I expect that when I'm under a language (lets say Spanish) and the cookie is set to 'es', if I change the URL manually to / it redirects me to '/es' which is the last value under the cookie.
What is actually happening?
When I'm under a language (lets say Spanish) and I manually change the URL to / it shows me the website in English and it doesn't changes the cookie which stay with the value of Spanish.
When I add the 'alwaysRedirect: true' under 'detectBrowserLanguage' it works fine that part, bug the content and the cookie are not being changed.
Additional comments?
Hi everyone! Sorry if this is not a bug but I can't get it to work, also I'm a beginner at programming so for sure I must be doing something wrong but can't find the reason.
I'm using the following dependencies:
"nuxt": "^2.8.1",
"nuxt-i18n": "^6.0.0"

I have the following nuxt.config.js file:
[
      'nuxt-i18n', {
        locales: [
          {
            code: 'en',
            iso: 'en-US',
            name: 'English',
            file: 'en.js'
          },
          {
            code: 'es',
            iso: 'es-AR',
            name: 'Spanish',
            file: 'es.js'
          }
        ],
        detectBrowserLanguage: {
          useCookie: true,
          cookieKey: 'i18n_redirected',
          alwaysRedirect: true,
          fallbackLocale: 'en'
        },
        lazy: true,
        langDir: 'locales/',
        vuex: {
          moduleName: 'i18n',
          syncLocale: true,
          syncMessages: true,
          syncRouteParams: true
        }
      }
    ],

Vue component:
<nuxt-link :to="switchLocalePath('en')">English</nuxt-link>
<nuxt-link :to="switchLocalePath('es')">Spanish</nuxt-link>

Here's my CodeSandbox which haves the issues.
Basically I'm trying to achieve the following:

At the beginning get the language of the browser and show that one, if none use English by default (Working)
Always show /en or /es in the URL (Working)
Save locale and messages to Vuex (Working)
If the user deletes manually the /en or /es from the URL get the cookie value and set it to that one, not to redirect showing in English if it was in Spanish when I delete it

Another thing which is not working is the data changing in the CodeSandbox example, it only changes the URL but not the data from Testing:.
Thanks for the help.

I'm with the same issue. Any workarounds?

If the user deletes manually the /en or /es from the URL get the cookie value and set it to that one, not to redirect showing in English if it was in Spanish when I delete it

So you want cookie to be updated on changing the URL manually but respected when opening URL without language prefix?
I feel that would be hard to achieve (I can't think of any way actually) as to make things work that way, it would be necessary to distinguish the case when user manually changes the URL and when user just opens given URL with a link (non SPA link). I don't think it's possible to do that in reliable way.
And if you want both cases to cause the cookie to update then it would probably break some functionality of alwaysRedirect as it wouldn't redirect to saved language if user opened the page from somewhere else (other page for example).

@rchl The point is: how can we change the user language if everytime it redirects to the old one. You suggest that we need to manually change the cookie value? Is there a method ready to use to change locale instead of using switchLocalePath?

You can add language switcher as described here https://nuxt-community.github.io/nuxt-i18n/lang-switcher.html#dynamic-route-parameters

I've did almost all what's described on this page, except for the vuex part. I'll give it a try and let you know. Thanks.

I meant that you would have a language switcher on the site and use this.$i18n.setLocaleCookie(locale) to persist new locale in cookie.

As of latest version you can just use this.$i18n.setLocale('fr') to switch locale, store cookie (if used) and redirect.


cigien: Watch dev.cashfree.com

cigien requests the watch of the watch_keyword dev\.cashfree\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

dev\.cashfree\.com has been seen in 2 true positives, 0 false positives, and 0 NAAs.

Rejected by Mast in Charcoal HQ. Reason: 'The only reason it's spam is because the affiliation is undisclosed. This does not warrant watching the SDK.'


image/png: nearly black pixels under certain conditions with alpha channels

I'm writing a small package for image resizing. While I've had my share of issues with images that have an alpha channel, this time I think that there may be an issue in the image/png package. I'm using Go 1.4.2 with OS X and under certain conditions there will be nearly black pixels in images created by png.Encode. The following code will produce an output that shows the problem:
package main

import (
	"bytes"
	"fmt"
	"image"
	"image/color"
	"image/png"
)

func main() {
	expected := image.NewRGBA64(image.Rect(0, 0, 7, 1))

	expected.SetRGBA64(0, 0, color.RGBA64{64561, 64547, 64541, 64566})
	expected.SetRGBA64(1, 0, color.RGBA64{65535, 65535, 65529, 65535})
	expected.SetRGBA64(2, 0, color.RGBA64{65118, 65535, 65535, 64688})
	expected.SetRGBA64(3, 0, color.RGBA64{42253, 29639, 24962, 46946})
	expected.SetRGBA64(4, 0, color.RGBA64{36967, 14176, 5958, 45390})
	expected.SetRGBA64(5, 0, color.RGBA64{38060, 17046, 9449, 45831})
	expected.SetRGBA64(6, 0, color.RGBA64{37852, 16504, 8790, 45746})

	var buffer bytes.Buffer
	png.Encode(&buffer, expected)

	actual, err := png.Decode(&buffer)
	if err != nil {
		panic(err)
	}

	for i := 0; i < 7; i++ {
		fmt.Printf("\n(%v,0):\n", i)
		fmt.Println(actual.At(i, 0).RGBA())
		fmt.Println(expected.At(i, 0).RGBA())
	}
}

While most color values of actual are about the same as in expected, pixel (2,0) of actual is very different from the one in expected and would show as nearly black in the output image. I didn't test if this is only happening with image.RGBA64 input.

Go's color.RGBA64 type (and color.Color's RGBA method) is alpha-premultiplied, which means that the R, G and B values should all be <= the A value.
You probably want non-alpha-premultiplied instead: replace your "RGBA64"s with "NRGBA64"s.

Thanks for the explanation and sorry for the inconvenience.


Where is "NtsVar" defined?

While reading the code, I find an undefined symbol NtsVar. And I can`t find where it is defined...
Could you please tell me where it is defined?
Thank you so much!!

I finally found it in NtsScheduler header file...


some phones are not responding?

Why do I test Demo, some cell phone requests are correspondingly, some phones are not responding?

HTTP requests no response to the cell phone, and there is no rule of discovery, which has nothing to do with the IOS phone system. Demo test, what else do I need to do?


Update NuGet.Client to get the version the patches expect.

@jaredpar @karajas I plan to merge if this fixes the NuGet patching on CI, unless you have any objections.

LGTM.

👍


Appstudio update mvp-test-component

Pipelines as Code configuration proposal

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

StatusDurationName

✅ Succeeded
6 seconds
init

✅ Succeeded
14 seconds
clone-repository

✅ Succeeded
1 minute
build-container

✅ Succeeded
10 seconds
sanity-inspect-image

✅ Succeeded
10 seconds
deprecated-base-image-check

✅ Succeeded
18 seconds
clair-scan

✅ Succeeded
59 seconds
clamav-scan

✅ Succeeded
11 seconds
sbom-json-check

✅ Succeeded
16 seconds
sanity-optional-label-check

✅ Succeeded
16 seconds
sanity-label-check

✅ Succeeded
6 seconds
show-summary

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

StatusDurationName

✅ Succeeded
6 seconds
init

✅ Succeeded
14 seconds
clone-repository

✅ Succeeded
1 minute
build-container

✅ Succeeded
10 seconds
deprecated-base-image-check

✅ Succeeded
10 seconds
sanity-inspect-image

✅ Succeeded
18 seconds
clair-scan

✅ Succeeded
59 seconds
clamav-scan

✅ Succeeded
11 seconds
sbom-json-check

✅ Succeeded
16 seconds
sanity-optional-label-check

✅ Succeeded
16 seconds
sanity-label-check

✅ Succeeded
6 seconds
show-summary


Not defined GLFW_MOUSE_PASSTHROUGH macro.

my glfw version is: glfw-3.3.8.bin.WIN32
when i include glfw.h i want use GLFW_MOUSE_PASSTHROUGH macro implements mouse passthrogh feature. but when i use GLFW_MOUSE_PASSTHROUGH macro ide tell me this macro not defined.
i search GLFW_MOUSE_PASSTHROUGH macro in glfw.h not found.
but i see glfw website find this marco join in 3.4 version and github repository glfw.h have this macro. so i want know why my 3.3.8 version not this macro.
so what should i do!

It’s not available in 3.3.8. It’s in 3.4 (the master branch).
There’s been 3 other issues with the same problem:
https://github.com/glfw/glfw/issues?q=GLFW_MOUSE_PASSTHROUGH

它在 3.3.8 中不可用。它在 3.4（主分支）中。
同一问题还有其他 3 个问题：https://github.com/glfw/glfw/issues?q=GLFW_MOUSE_PASSTHROUGH

so i need download 3.4 version or i self compile 3.4 master.

No, that’s 3.3.4, not 3.4.
3.4 has not yet been released. You’ll have to compile it yourself, yes.

不，这是 3.3.4，而不是 3.4。
3.4 尚未发布。你必须自己编译它，是的。

thank you for your answer. i think i understand you see.


TYP: special: add type stubs to _basic.py

Reference issue
#11749
What does this implement/fix?
Adding the stubs for _basic.py and enable the type cheking for test_basic

thanks @JPena-code, here is what MyPy is saying in CI:

💻  mypy.api.run --config-file /home/runner/work/scipy/scipy/mypy.ini scipy
scipy/special/tests/test_basic.py:46: error: Module "scipy.special._basic" has no attribute "_FACTORIALK_LIMITS_64BITS"  [attr-defined]
scipy/special/tests/test_basic.py:46: error: Module "scipy.special._basic" has no attribute "_FACTORIALK_LIMITS_32BITS"  [attr-defined]
scipy/stats/tests/test_resampling.py:1140: error: Unsupported operand types for ** ("_SupportsArray[dtype[Any]]" and "int")  [operator]
scipy/stats/tests/test_resampling.py:1140: error: Unsupported operand types for ** ("_NestedSequence[_SupportsArray[dtype[Any]]]" and "int")  [operator]scipy/stats/tests/test_resampling.py:1140: error: Unsupported operand types for ** ("str" and "int")  [operator]
scipy/stats/tests/test_resampling.py:1140: error: Unsupported operand types for ** ("bytes" and "int")  [operator]
scipy/stats/tests/test_resampling.py:1140: error: Unsupported operand types for ** ("_NestedSequence[Union[bool, int, float, complex, str, bytes]]" and "int")  [operator]
scipy/stats/tests/test_resampling.py:1140: note: Left operand is of type "Union[_SupportsArray[dtype[Any]], _NestedSequence[_SupportsArray[dtype[Any]]], int, float, complex, str, bytes, _NestedSequence[Union[bool, int, float, complex, str, bytes]]]"
Found 7 errors in 2 files (checked 858 source files)

Thanks @lucascolley, I added those two private constants that were missing. Additionally, I reviewed other PRs and saw that I also needed to modify the mypy.ini file, also after doing some research I saw that I was incorrectly using ArrayLike from numpy.typing and that the correct one is NDArray

Also seeing one new error after rebasing:
 scipy/special/tests/test_sph_harm.py:4: error: Module "scipy.special._basic" has no attribute "_sph_harm_all"  [attr-defined]

Hi @rgommers, I just made a push with the suggested changes, I look forward to any other feedback you have

Thanks @JPena-code. I had a quick look - much closer to what we want now I think. Next thing: can you replace DecimalNumber and IntNumber by:
_IntegerType = int | np.integer
_FloatingType = float | np.floating

(taken from special/_orthogonal.pyi).

@rgommers done it

I fix the problems, I hope everything is right now.

I did a bit more spot checking - this is starting to look good now - structural issues should be resolved. I don't quite have time for a thorough review before the end of next week though. If someone else wants to review, that'd be welcome.

Let's close this in light of gh-21614 - it sounds like your contribution would be welcome over at scipy-stubs if you would like to return to this @JPena-code !

stub packages like scipy-stubs (I believe it's the only one actually)

Are you aware of https://github.com/microsoft/python-type-stubs/tree/main/stubs/scipy-stubs @jorenham ?

Hi, I am excited to participate in the project and I will gladly move my contributions to scipy-stubs
Thank you very much for all the comments and suggestions


In reference to issue #178

What is a_id

I think using get requests is a bit more elegant, it does not pollute that function. https://github.com/levlaz/braindump/pull/182

@levlaz a_id(i meant active note id) is same as your active_note


eliminate duplicate bugs from different files

Different plist reports may contain the same bug report with the same hash id but on different paths.
The bug in these cases are reported in a .h file which is included by 2 independent .c files.
Frequently the two different bug is the result of the same problem and the ending steps of the 2 bug paths are the same.
Solution Proposal: Generate the bug hash of the uniquing location into the plist file and take this into consideration when improting.

As a further solution, we could also build upon @zporky's idea in counting on how many different paths a bug is present, which could help in the visualisation of the bug's impact. (Either only storing the count or storing Related bug paths too?)

I do not think this is a bug, by design do we this see issue #69 and pull request #89. Using the extra information from clang would definitely improve the current solution.

I think the uniquing should be done based on uniquing location (as string) and check name. Not baes on hash.

With the new bug unique-ing under development, this is no longer relevant.


Workaround for missing offsets in Azure's OffsetFetchResponse

This is a fix for #1540. It adds an entry in the offset table for (consumer group, partition) pairs in the OffsetFetchRequest that are missing from the OffsetFetchResponse.
This is for discussion rather than immediate merge; in particular we aren't sure yet whether Azure plans to revert to their previous behavior (returning an explicit offset entry for new consumer groups), in which case this would be superfluous. However, this fix or something like it is a viable workaround in the event that this behavior persists.

Thanks for your contribution. Could you please add a test for this?

Test added! Sorry for the delay on the CLA -- this will be contributed on behalf of Elastic, we're just trying to figure out who to email to get me put on the official contributor list :-)

@faec any updates about this PR?

@o1egl according to https://github.com/Shopify/sarama/issues/1540#issuecomment-562259978 this PR shouldn't be relevant anymore. Are you still experiencing the issue?

Yes, as far as I'm aware everything is working without the fix again... I've procrastinated on closing this in case the context was still relevant to someone but I think it's safe now, if this problem is still happening anywhere please follow up on #1540.

@bai @faec I still get kafka: response did not contain all the expected topic/partition blocks error without this fix.


Update pt_BR translations

@lbguilherme Apologies for my late response but thank you very much for this. Will merge now ready for next release.


Can't run single thread version

Describe the bug
can't run single thread version
Preview:
https://solid-ffmpeg.pages.dev/
(Only Chrome Desktop, I use origin-trial of chrome to enable SAB),
Try headers setting but  still don't works, unless I add origin-trial so that make it works on Desktop Chrome
cross-origin-embedder-policy: require-corp;
cross-origin-opener-policy: same-origin;

Switch to st
I was hope switch to single threads maybe avoid sharedarraybuffer problem and works for non-chrome desktop but...
Uncaught (in promise) RuntimeError: abort(Assertion failed: Cannot call unknown function proxy_main, make sure it is exported)

To Reproduce
Steps to reproduce the behavior:

check the commit
https://github.com/x7md-lab/solid-js-ffmpeg-wasm/commit/c8f1953bbeada577ae8cd600a90f5d7487ab79e6

git clone https://github.com/x7md-lab/solid-js-ffmpeg-wasm/
git switch single-thread
npm i
npm run dev

14bad67a-4dc5-473f-a8b2-703c304d3fe2:22 Uncaught (in promise) RuntimeError: abort(Assertion failed: Cannot call unknown function proxy_main, make sure it is exported). Build with -s ASSERTIONS=1 for more info.
   at n (14bad67a-4dc5-473f-a8b2-703c304d3fe2:22:397)
   at assert (14bad67a-4dc5-473f-a8b2-703c304d3fe2:15:443)
   at Aa (14bad67a-4dc5-473f-a8b2-703c304d3fe2:16:31)
   at e.cwrap (14bad67a-4dc5-473f-a8b2-703c304d3fe2:186:108)
   at Object.load (createFFmpeg.js:126:21)
   at async Object.fn (home.jsx:17:5)

Expected behavior
normal build of ffmpeg-core works fine locally, so single-thread should works at last on chrome desktop localhost.
Screenshots

Desktop (please complete the following information):

OS: Ubuntu 20.04.4 LTS x86_64
Browser: chrome
Version 104.0.5112.101 (Official Build) (64-bit)

Additional context
Add any other context about the problem here.

You need to use a different mainName:
https://github.com/ffmpegwasm/ffmpeg.wasm#use-single-thread-version

You need to use a different mainName: https://github.com/ffmpegwasm/ffmpeg.wasm#use-single-thread-version

Oh my bad...
https://solid-ffmpeg.pages.dev/singlethread
Now works on mobile too thanks.


feat(cdc): rate limit for cdc backfill

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
Support alter table t1 set backfill_rate_limit = xx for cdc table.

Extend update_mv_rate_limit_by_table_id to modify the rate_limit of StreamCdcScan node

Tested locally.
#17913
Checklist

[ ] I have written necessary rustdoc comments
[ ] I have added necessary unit tests and integration tests
[ ] I have added test labels as necessary. See details.
[ ] I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features #7934).
[ ] My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
[x] All checks passed in ./risedev check (or alias, ./risedev c)
[ ] My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

[ ] My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

[x] My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note
Support altering backfill_rate_limit of cdc table.

Rest LGTM


Spawn New terminal in current working directory, and enhancements for compound Actions

Abstract
Ctrl-Shift-N, i.e., the NewTerminal Action doesn't open a new terminal in the present working directory. In general, there is no way so that a user can define their own Actions. I am thinking something like xterm's translations in .Xresources, for new key bindings.
Motivation

Maybe the NewTerminal action can account for $PWD while spawning a new terminal.
Let the user define and/or override Actions like .Xresources translations, so that compound Actions can be defined.

Specification
Example of translations for UXTerm in .Xresources is as follows:
UXTerm.vt100.translations: #override \n\
  Ctrl <Key> minus:        smaller-vt-font() \n\
  Ctrl <Key> plus:         larger-vt-font() \n\
  Ctrl <Key> 0:            set-vt-font(d) \n\
  Shift <KeyPress> Insert: insert-selection(CLIPBOARD) \n\
  Ctrl Shift <Key>V:       insert-selection(CLIPBOARD) \n\
  Ctrl Shift <Key>C:       copy-selection(CLIPBOARD) \n\
  Ctrl Shift <Key>N:       spawn-new-terminal(-class UXTerm -title uxterm -u8 -ti vt340) \n\
  Ctrl Alt <Key>S:         secure() \n\
  Shift <Btn1Up>:          exec-formatted("xdg-open '%t'", PRIMARY) select-start() select-end()

Is something like this possible for Contour as well, using Actions?

Hey, many thanks for your interest in Contour. So if NewTerminal doesn't spawn in $PWD right now (talking right out of my head here, IIRC it's simply reading that info from the config, right), then this can be trivially implemented. :+1: Thanks for that idea.
For the second part, I might need to give it some thought and reread, because I think I might not fully understand that just yet.
"Compound Actions" to me reads like being able to run multiple actions on a single shortcut, say Ctrl+N. That is already possible and even part of the example config that's being auto-generated IIRC. Simply have two input mapping lines using the same key binds but different actions. They're all invoked sequentially in order.
If that's not what you meant, I am sorry for that (I'm not native English speaker :) ),  I'll try to reread later with some more time :)

@christianparpart Sorry, I had been vague in the second part, as I am not a native English speaker either 😅. What I meant by that is whether it is possible to develop something like xterm's string(string) method, so that we can key-bind it for doing multiple commands, on say, spawning a new terminal.
Some real life example maybe:

Someone wants to run just btop on a newly spawned terminal:

{ mods: [Control, Shift], key: B, action: NewTerminal|RunCommand("btop\n") }

Someone just needs to see the rate of cryptocurrencies:

{ mods: [Control, Shift], key: O, action: NewTerminal|RunCommand("curl rate.sx\n" }

In other words, something like this would lead to a crazy amount of customizability, IMO.
Also, @uspasojevic96, can you direct me to the file/the method in which this functionality was implemented, so that I might also look at it too?

Should be in src/terminal/Process_unix.cpp

There is no RunCommand action in contour currently.

@christianparpart iirc I worked on CWD spawn of new terminal, how did it get broken again?

@Utkarsh-khambra let's see if we can make it testable, so it won't accidentally break then. :)

At the moment contour on NewTerminal action spawns it using pwd

On Windows contour doesn't spawn NewTerminal in CWD is windows, see.

Sounds about right, I did it for macOS