Two permission can't use

“android.permission.SYSTEM_ALERT_WINDOW”
“android.permission.WRITE_SETTINGS”
@egor-n

They are special permissions so you can't handle these at the same time. Ordinal permissions can be handled.

OK,Thank for you help;Thank you very much.

Why not? And how to circumvent this?

This is a reaction to AOSP's inconsistent handling of permissions in some places. The permission flow for SYSTEM_ALERT_WINDOW doesn't follow the framework's "normal route"; instead PermissionsDispatcher needs to redirect the user to their System Settings to toggle some button. Because of this, we decided not to allow mix-and-matching of this flow with the "Show Runtime Permissions Dialog" flow that usually happens. Working around this, you would need to separate the special permissions from the ordinary ones, and chain them together from two different methods.


Migrate codebase to TypeScript

Functionality is the same, especially checked util function Debounce if it still works as intended, and it seems like it does. Because of different wrapping settings with Prettier it may seem like there were many more changes, but some files needed just an interface types defined.
Removed custom attribute "Discovered" from 1 line in 3 different files (PeriodicTable.tsx - line 194, ExploreData.tsx - line 155, Header.tsx - line 200) because TypeScript threw an error.
Tried to avoid type "any" as much as possible, except for _app.tsx, because here I didn't really know which type would fit best in the interface.
I'm testing everything on my local machine using dev server, and everything looks like it's working fine, no errors in the console and in IDE.
Type safety is improved, here is an example:

When using npm run build however, I'm getting this error:

It's probably not because of my changes, because I cloned the original repository and the error is exactly the same, so it may be something on my side.

@HarshKumarraghav Hey! Just wanted to ask, is there anything wrong with my solution? I would love to get a feedback and review from you :) I'm open minded and if there is anything that should be corrected, or maybe quality of this code is not satisfactory, please let me know!

@HarshKumarraghav Hey! Just wanted to ask, is there anything wrong with my solution? I would love to get a feedback and review from you :) I'm open minded and if there is anything that should be corrected, or maybe quality of this code is not satisfactory, please let me know!

hello @TerroR75  sorry for not replying currently I'm busy with some personal stuff.....
and about the commit the build is not even working
you can see your code deployment here.
https://deploy-preview-49--stellular-kleicha-524289.netlify.app/

hello @TerroR75 sorry for not replying currently I'm busy with some personal stuff..... and about the commit the build does not have a loading state we cant understand if is it even working or not you can see your code deployment here. https://deploy-preview-49--stellular-kleicha-524289.netlify.app/

All good :) Thank you for reply, fixed some issues with updated code, now its loading properly and filtering works as expected, check these changes whenever you can!
Best regards, Kamil


Unmatched double opening braces cause MMM parsing issues

The following script fails:
!mmm combine chat
!mmm   chat: {{foo=
!mmm   if true
!mmm     chat: bar}}
!mmm   end if
!mmm end combine

Error message:

During parse, unexpected block end in script: !mmm end ❌if

Changing the second line to end with }} makes the error go away.

It's what we thought and I couldn't believe: Roll20's parser tries to be smart about these braces, gobbles up chat lines until it finds the closing pair, and passes the entire block of lines to MMM.
This is one message sent to MMM:
!mmm   chat: {{foo=

!mmm   if true

!mmm     chat: bar}}

...with embedded HTML
 tags to boot. (But only when the whole script is sent at once, e.g. as a macro or as a multi-line chat message.)
The most user-friendly solution for this is probably to work around Roll20's misplaced cleverness and break lines like this one apart again before handling them on a per-line basis as MMM commands.


Release should bump Cargo toml version to next

Duplicate of https://github.com/jacek-kurlit/pik/issues/34


Scrolling a ListBox with virtualization messes up the keyboard focus

Describe the bug
Scrolling a ListBox with VirtualizationMode=Simple changes the keyboard focus to another item when the focused item gets out of view. The issue does not occur when VirtualizationMode is None.
To Reproduce
Steps to reproduce the behavior:

Create a new project in Visual Studio using the Avalonia MVVM Application template.
Add an Items property to MainWindowViewModel: public List<int> Items { get; set; } = new(Enumerable.Range(0, 1000));
Replace the greeting TextBlock to a ListBox in MainWindow.axaml: <ListBox Items="{Binding Items}" VirtualizationMode="Simple"/>
Run the application
Click on an item in the ListBox
Press Up Arrow or Down Arrow keys to make the keyboard focus adorner visible
Start scrolling down using the scrollbar or the mouse wheel (not the keyboard), and keep scrolling
Every time the focused item gets out of the viewport, a new item receives the keyboard focus.
Change VirtualizationMode to None to make the issue disappear

The issue is also visible in the VirtualizationDemo sample.
Expected behavior
The keyboard focus should not change while scrolling.
The virtualization code should not recycle the element having the keyboard focus.
Desktop (please complete the following information):

OS: Windows 10
Version: 0.10.18, 11.0.0-preview2

I'm going to create a pull request to fix this

Sorry, I got lost, we need an expert here.

The keyboard focus should not change while scrolling.
The virtualization code should not recycle the element having the keyboard focus.

Not sure how possible it is.
I wonder, if it was solved in WPF or UWP. Can somebody check?

Also, if ItemsRepeater and DataGrid have the same problem (probably have)

It works in WPF.

I know it works in WinUI, if you have one of the WinUI control galleries, it's easy to repro.
If you inspect the Native View of Selector in UWP, you can see they have several fields specifically for holding the current focus information for the items:

And the ViewManager for ItemsRepeater holds focus info too, although I haven't tested that it works:
https://github.com/AvaloniaUI/Avalonia/blob/34d24a0f398c2ade43895004c38694b4613779b2/src/Avalonia.Controls/Repeater/ViewManager.cs#L25

Checking the visual children of a ListBox using the debugger shows that WPF keeps the focused element alive in the visual tree, and does not reuse it for displaying other items.

I cannot reproduce this for ItemsRepeater and DataGrid.

Using ItemsRepeater in ListBox may be a possible solution, see #2594


simple material support (non textures)

Low effort support for metal and plastic Fusion materials.  Just mapping the svf material to gltf  Roughness and metalness parameters.
(Textures support is not required)

The typescript branch contains some initial support for generic ("SimplePhong") materials, also including textures but with no texture transforms.

The branch has been merged into master, so basic materials (and also textures) are now supported.


[Bug Report]: Update Azure DevTest Lab Module to API Version '2018-10-15-preview' failing the Static tests

Description
Current DevTest Lab Module is running on the latest published API version (2018-09-15). Both in the Template Documentation and the API Documentation. However, when attempting to update the module to the latest API version 2018-10-15-preview. We have a couple of things that need to be fixed:

Both the Template Documentation and the API Documentation need to be updated to reference the latest published API version.

Bicep is also complaining about the API for not having types available. So it needs to reference the latest API as well.

Warning BCP081: Resource type "Microsoft.DevTestLab/labs@2018-10-15-preview" does not have types available.

Bug

Our Static tests are failing for the latest API with the following message:

[-] In [Microsoft.DevTestLab/labs] used resource type [labs] should use one of the recent API version(s). Currently using [2018-10-15-preview] 76ms (75ms|1ms)
   Expected '2018-10-15-preview' to be found in collection @('2018-09-15', '2016-05-15', '2015-05-21-preview'), but it was not found.

Requirement
The API that is being used in the Azure Portal is 2018-10-15-preview, which contains a lot more features than the latest published version 2018-09-15. It includes the following:

Support for system assigned managed identities.
Use existing storage account for the Lab Artifacts instead of the default.
Encryption using Customer managed keys using the Disk Encryption set.
Browser Connect via Azure Bastion.
Specifying a custom resource group for VM Creation.
Isolation of lab resources. This changes the Storage accounts and key vaults to 'Selected networks only'
Disabling auto upgrade of custom script extension.

We need to update our module to support the above features.

The API Specs List JSON, contains the Microsoft.DevTestLab resource provider, however it does not contain the latest API Version:
    "Microsoft.DevTestLab": {
        "labs": [
            "2015-05-21-preview",
            "2016-05-15",
            "2018-09-15"
        ],
        "labs/artifactsources": [
            "2015-05-21-preview",
            "2016-05-15",
            "2018-09-15"
        ],
        "labs/costs": [
            "2016-05-15",
            "2018-09-15"
        ],
        "labs/customimages": [
            "2015-05-21-preview",
            "2016-05-15",
            "2018-09-15"
        ],
        "labs/formulas": [
            "2015-05-21-preview",
            "2016-05-15",
            "2018-09-15"
        ],
        "labs/notificationchannels": [
            "2016-05-15",
            "2018-09-15"
        ],
        "labs/policysets/policies": [
            "2015-05-21-preview",
            "2016-05-15",
            "2018-09-15"
        ],
        "labs/schedules": [
            "2015-05-21-preview",
            "2016-05-15",
            "2018-09-15"
        ],
        "labs/servicerunners": [
            "2016-05-15",
            "2018-09-15"
        ],
        "labs/users": [
            "2016-05-15",
            "2018-09-15"
        ],
        "labs/users/disks": [
            "2016-05-15",
            "2018-09-15"
        ],
        "labs/users/environments": [
            "2016-05-15",
            "2018-09-15"
        ],
        "labs/users/secrets": [
            "2016-05-15",
            "2018-09-15"
        ],
        "labs/users/servicefabrics": [
            "2018-09-15"
        ],
        "labs/users/servicefabrics/schedules": [
            "2018-09-15"
        ],
        "labs/virtualmachines": [
            "2015-05-21-preview",
            "2016-05-15",
            "2018-09-15"
        ],
        "labs/virtualmachines/schedules": [
            "2016-05-15",
            "2018-09-15"
        ],
        "labs/virtualnetworks": [
            "2015-05-21-preview",
            "2016-05-15",
            "2018-09-15"
        ],
        "schedules": [
            "2016-05-15",
            "2018-09-15"
        ]
    },

However, it does not contain the latest APIs. @AlexanderSehr .. Is the intent for us to 'manually' update this API specs file when we're adding new API versions? I can see the pipeline running weekly, but not sure on how it works, although I can see it referenced in our doco:
In particular, each resource's API version is compared with those currently available on Azure. This test has a certain level of tolerance (does not enforce the latest version): the API version in use should be one of the 5 latest versions available (including preview versions) or one of the the 5 latest non-preview versions.

To test the API versions, the test leverages the file `utilities/src/apiSpecsList.json` file as a reference for all API versions available for any used Provider Namespace & Resource Type.

The API Specs List JSON, contains the Microsoft.DevTestLab resource provider, however it does not contain the latest API Version:
    "Microsoft.DevTestLab": {
        "labs": [
            "2015-05-21-preview",
            "2016-05-15",
            "2018-09-15"
        ],
        "labs/artifactsources": [
            "2015-05-21-preview",
            "2016-05-15",
            "2018-09-15"
        ],
        "labs/costs": [
            "2016-05-15",
            "2018-09-15"
        ],
        "labs/customimages": [
            "2015-05-21-preview",
            "2016-05-15",
            "2018-09-15"
        ],
        "labs/formulas": [
            "2015-05-21-preview",
            "2016-05-15",
            "2018-09-15"
        ],
        "labs/notificationchannels": [
            "2016-05-15",
            "2018-09-15"
        ],
        "labs/policysets/policies": [
            "2015-05-21-preview",
            "2016-05-15",
            "2018-09-15"
        ],
        "labs/schedules": [
            "2015-05-21-preview",
            "2016-05-15",
            "2018-09-15"
        ],
        "labs/servicerunners": [
            "2016-05-15",
            "2018-09-15"
        ],
        "labs/users": [
            "2016-05-15",
            "2018-09-15"
        ],
        "labs/users/disks": [
            "2016-05-15",
            "2018-09-15"
        ],
        "labs/users/environments": [
            "2016-05-15",
            "2018-09-15"
        ],
        "labs/users/secrets": [
            "2016-05-15",
            "2018-09-15"
        ],
        "labs/users/servicefabrics": [
            "2018-09-15"
        ],
        "labs/users/servicefabrics/schedules": [
            "2018-09-15"
        ],
        "labs/virtualmachines": [
            "2015-05-21-preview",
            "2016-05-15",
            "2018-09-15"
        ],
        "labs/virtualmachines/schedules": [
            "2016-05-15",
            "2018-09-15"
        ],
        "labs/virtualnetworks": [
            "2015-05-21-preview",
            "2016-05-15",
            "2018-09-15"
        ],
        "schedules": [
            "2016-05-15",
            "2018-09-15"
        ]
    },

However, it does not contain the latest APIs. @AlexanderSehr .. Is the intent for us to 'manually' update this API specs file when we're adding new API versions? I can see the pipeline running weekly, but not sure on how it works, although I can see it referenced in our doco:
In particular, each resource's API version is compared with those currently available on Azure. This test has a certain level of tolerance (does not enforce the latest version): the API version in use should be one of the 5 latest versions available (including preview versions) or one of the the 5 latest non-preview versions.

To test the API versions, the test leverages the file `utilities/src/apiSpecsList.json` file as a reference for all API versions available for any used Provider Namespace & Resource Type.

ever, it does not contain the latest APIs. @AlexanderSehr .. Is the intent for us to 'manually' update this API specs file when we're adding new API versions? I can se

Hey @ahmadabdalla, it is as you describe. The Api Specs file is created/updated weekly on a schedule and leverges the APICrawlerModule to find and extract all API versions from the 'official' Azure API specs GitHub repository and it does, in fact, not know this preview version.
Not sure what to do with it now. I also checked the Get-AzResourceProvider -ListAvailable function, it it does know the preview version:
"ApiVersions": [
  "2018-10-15-preview",
  "2018-09-15",
  "2017-04-26-preview",
  "2016-05-15",
  "2015-05-21-preview"
]

We introduced the API crawler explicitely to get a more complete picture as Get-AzResourceProvider sometimes lacks years of API versions (e.g. for Resource Group, Tags, etc.).
What I can try to do to mitigate this is to update the usage of the AzureAPICrawler module to essentially merge the results of both - what the API Specs repository returns, and what the Get-AzResourceProvider function returns. It's not something I'd have expected to happen.
This 'fix' would need to be implemented here and ideally leverage the original code.
I guess this should be handled in a dedicated bug?

Thanks @AlexanderSehr. I've also raised an issue - 22026 in that repo regarding the missing API version for DevTest Labs. It should be in this folder.

@AlexanderSehr . The static tests are still failing due to some child resources not having the API versions published, including in the Get-AzResourceProvider response:

Applicable to both 2018-09-15 version and the latest preview 2018-10-15-preview. The only way to get around this is by downgrading all child resources in our module to the 2018-09-15 version as metadata from both the API specs doc and the external resource you implemented contains it all. I don't think there is much we can do right now as your script has the right logic in place, and the issues are happening elsewhere.
I would suggest keeping the child modules to the old API version but for the parent to use the latest preview version until the issue I raised gets resolved. Then we can uplift our module. Thoughts?

@AlexanderSehr . The static tests are still failing due to some child resources not having the API versions published, including in the Get-AzResourceProvider response:

Applicable to both 2018-09-15 version and the latest preview 2018-10-15-preview. The only way to get around this is by downgrading all child resources in our module to the 2018-09-15 version as metadata from both the API specs doc and the external resource you implemented contains it all. I don't think there is much we can do right now as your script has the right logic in place, and the issues are happening elsewhere.
I would suggest keeping the child modules to the old API version but for the parent to use the latest preview version until the issue I raised gets resolved. Then we can uplift our module. Thoughts?

Dang :-/ let's go with your suggestion, yes. Are we sure the children 'would' have the preview API version too? It happens that they diverge.

@AlexanderSehr .. yep they do use the latest API as I've inspected the payloads when changing the configurations via the Azure portal using the developer tools browser method. It's unfortunate we have these issues. Also there are no feature uplifts on the child modules when using the latest API version so we're not missing out. The only one benefiting is the parent module.


terragrunt aws s3 backend access log issue

Describe the bug
while enabling access log setting  in s3 backend remote config its giving
(excluded: false, assume applied: false, dependencies: []), finished with an error: AccessControlListNotSupported: The bucket does not allow ACLs
To Reproduce
Steps to reproduce the behavior, code snippets and examples which can be used to reproduce the issue.
// paste code snippets here
```remote_state {
  backend = "s3"
  config = {
    encrypt        = true
    bucket         = "test-${lower(local.account_vars.locals.account_name)}-infrastructure-tf-"
    key            = "${path_relative_to_include()}/terraform.tfstate"
    region         = local.aws_region
    dynamodb_table = "infrastructure-live"
    accesslogging_bucket_name  = "prasad-s3-access-logs"
    accesslogging_target_prefix= "logs/"
  }

**Versions**
- Terragrunt version: v1.3.7
- Terraform version: v0.37.1
- Environment details (Ubuntu 20.04, Windows 10, etc.): mac bigsur

**Additional context**
Add any other context about the problem here.

What version of terragrunt are you using?
In April of 2023 AWS made a change to S3 disabling Access Control List by default. The version of terragrunt you are using may be from before that change.
https://aws.amazon.com/about-aws/whats-new/2023/04/amazon-s3-security-best-practices-buckets-default/


assistant

Describe the feature
Hello, can you access the assistant api? It is very helpful to me

This project is undergoing a major revamp; closing out old issues as part of the prep process.
The chatgpt package is pretty outdated at this point. I recommend that you use the openai package or the openai-fetch package.


olm: 3.2.13 -> 3.2.14

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/olm/versions.
meta.description for olm is: "Implements double cryptographic ratchet and Megolm ratchet"
meta.homepage for olm is: "https://gitlab.matrix.org/matrix-org/olm"
meta.changelog for olm is: ""
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 3.2.14 with grep in /nix/store/xxjb2253g458pm3z40k8ipm7gip7cyvr-olm-3.2.14
found 3.2.14 in filename of file in /nix/store/xxjb2253g458pm3z40k8ipm7gip7cyvr-olm-3.2.14

Rebuild report (if merged into master) (click to expand)

26 total rebuild path(s)

26 package rebuild(s)

First fifty rebuilds by attrpath
chatty
fluffychat
go-neb
gomuks
libsForQt5.neochat
matrix-commander
matrixcli
mautrix-facebook
mautrix-signal
mautrix-telegram
mautrix-whatsapp
mirage-im
mtxclient
nheko
olm
opsdroid
pantalaimon
pantalaimon-headless
plasma5Packages.neochat
purple-matrix
python310Packages.matrix-nio
python310Packages.python-olm
python39Packages.matrix-nio
python39Packages.python-olm
weechatScripts.weechat-matrix
weechatScripts.weechat-matrix-bridge

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/xxjb2253g458pm3z40k8ipm7gip7cyvr-olm-3.2.14 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A olm https://github.com/r-ryantm/nixpkgs/archive/eb50ebfe82ff410faed51d45253809810bd984b6.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/xxjb2253g458pm3z40k8ipm7gip7cyvr-olm-3.2.14
ls -la /nix/store/xxjb2253g458pm3z40k8ipm7gip7cyvr-olm-3.2.14/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package failed to build:

fluffychat

24 packages built:

chatty
go-neb
gomuks
neochat (matrique ,spectral)
matrix-commander
matrixcli
mautrix-facebook
mautrix-signal
mautrix-telegram
mautrix-whatsapp
mirage-im
mtxclient
nheko
olm
opsdroid
pantalaimon
pantalaimon-headless
purple-matrix
python310Packages.matrix-nio
python310Packages.python-olm
python39Packages.matrix-nio
python39Packages.python-olm
weechatScripts.weechat-matrix
weechatScripts.weechat-matrix-bridge

Maintainer pings
cc @tilpner @oxzi for testing.

Result of nixpkgs-review pr 208146 run on x86_64-linux 1

1 package failed to build:

fluffychat

24 packages built:

chatty
go-neb
gomuks
libsForQt5.neochat (plasma5Packages.neochat)
matrix-commander
matrixcli
mautrix-facebook
mautrix-signal
mautrix-telegram
mautrix-whatsapp
mirage-im
mtxclient
nheko
olm
opsdroid
pantalaimon
pantalaimon-headless
purple-matrix
python310Packages.matrix-nio
python310Packages.python-olm
python39Packages.matrix-nio
python39Packages.python-olm
weechatScripts.weechat-matrix
weechatScripts.weechat-matrix-bridge

Result of nixpkgs-review pr 208146 run on x86_64-darwin 1

5 packages marked as broken and skipped:

go-neb
mirage-im
mtxclient
nheko
weechatScripts.weechat-matrix-bridge

12 packages built:

gomuks
mautrix-facebook
mautrix-whatsapp
opsdroid
pantalaimon
pantalaimon-headless
purple-matrix
python310Packages.matrix-nio
python310Packages.python-olm
python39Packages.matrix-nio
python39Packages.python-olm
weechatScripts.weechat-matrix


Be consistant with the iteration of arrays

Reason/Context
We should be consistent with the use of array iteration so we don't mix different syntaxes.
Sometimes we use forEach sometimes for of.
Description
We need to keep in mind forEach has a limitation in terms that it cannot handle asynchronous calls and because of this, I suggest we use for of consistently.
The following explains pretty well why we should use for of - https://github.com/github/eslint-plugin-github/blob/main/docs/rules/array-foreach.md

Closing to have everything in a single issue.


Better IO functions

The current IO function (read and write) are not very composable and they expect to use fix-sized buffers. A better API should be provided, maybe something like that:
type reader = unit -> (bytes * int * int) option Lwt.t
type writer = (bytes * int * int) option -> unit Lwt.t

(inspired from nbcodec)

Not sure how to compose these nicely (to have a reader and a writers for each implementations)

No more reader and writer, in 1.0 all these functions are auto-generated from a dynamic type description (See Irmin.Type and depyt)


Showcase Submission for challenges/13-reaction-diffusion

Thank you Ankur Pawar for your contribution! A member of the Coding Train team will review it shortly.

Reaction diffusion heart shape
Ankur Pawar

❤ ❤ ❤ ❤ ❤ ❤ ❤ ❤ ❤ ❤


Change equality requirement to subset in dependency validation

What does this PR do?

Motivation
Fix for bug introduced in #15416.
Additional Notes

Review checklist (to be filled by reviewers)

[ ] Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
[ ] PR title must be written as a CHANGELOG entry (see why)
[ ] Files changes must correspond to the primary purpose of the PR as described in the title (small unrelated changes should have their own PR)
[ ] PR must have changelog/ and integration/ labels attached
[ ] If the PR doesn't need to be tested during QA, please add a qa/skip-qa label.

ftr, caught in this job https://github.com/DataDog/integrations-core/actions/runs/5765688198/job/15632147361?pr=15484
Run ddev validate dep $TARGET
Mismatch for dependency `boto3`:
    Agent: boto3==1.17.112; python_version < '3.0' | boto3==1.27.0; python_version > '3.0'
    Checks: boto3==1.27.0; python_version > '3.0'
Error: Mismatch for dependency `boto3`:
    Agent: boto3==1.[17](https://github.com/DataDog/integrations-core/actions/runs/5765688198/job/15632147361?pr=15484#step:12:18).112; python_version < 3.0 | boto3==1.27.0; python_version > 3.0
    Checks: boto3==1.27.0; python_version > 3.0
Error: Process completed with exit code 1.


chore: active support for Python 3.13

Description
Active support for Python 3.13
Closes https://github.com/ansys/pymapdl/issues/3600
Checklist

[x] I have visited and read Develop PyMAPDL.
[x] I have tested my changes locally
[x] I have added necessary documentation or updated existing documentation.
[x] I have followed the PyMAPDL coding style guidelines.
[x] I have added appropriate unit tests that also ensure the minimal coverage criteria.
[x] I have reviewed my changes before submitting this pull request.
[x] I have linked the issue or issues that are solved to the PR if any.
[x] I have assigned this PR to myself.
[x] I have marked this PR as draft if it is not ready to be reviewed yet.
[x] I have made sure that the title of my PR follows Commit naming conventions (e.g. feat: adding new MAPDL command)

@clatapie

Only VTK 9.4.0 is compatible with 3.13

Thanks @RobPasMue. I updated all the vtk versions, including the ones within .devcontainer.

Seems to me like you are hitting some PyVista 3.13 incompatibilities.

Seems to me like you are hitting some PyVista 3.13 incompatibilities.

Yep. This is on hold until https://github.com/ansys/pymapdl/issues/3611 is fixed.

We are going to need a patch release in ATVI (ansys-tools-visualization-interface).

ATVI

Not another acronym pls 😭

ATVI

Not another acronym pls 😭

We need it! xDDD

By the way, getting Python segfaults when using VTK 9.4.0... so this PR has to wait...
https://github.com/ansys/pymapdl/pull/3615


feat: Support for Angular 16 (Self-Closing-Tags)

bump angular compiler to support components self-closing-tags

So sorry for the missed PR, @marcowuethrich... After transfering this to my current org. I didn't realize that I no longer would receive notifications for PRs and issues. You've probably made the move already, but as of today this package has been deprecated in favour of @vendure/ngx-translate-extract (vendure-ecommerce/ngx-translate-extract).
Thank you though, for contributing! :)


Add canonical_tss distance source to the V2G table

We have added a new source to the V2G data based on the distance from variant to each genes TSS. This should be added as an additional row in the V2G table on the variant page.

Cells for this column should contain the distance in KB
Display label: Distance (Canonical TSS)
Tooltip: Distance from the variant to canonical transcript TSS (Kilobases)

If the table is getting too wide, could be add a new line character between the "source name" and the "author"?
E.g. have:
eQTL
(GTEx V7)

instead of
eQTL (GTEx V7)

Added on dev branch.


!downtimes command

Travis tests have failed
Hey @silasary,
Please read the following log in order to understand the failure reason.
It'll be awesome if you fix what's wrong and commit the changes.
1st Build
View build log

     echo $CMD

python dev.py lint

     $CMD

$ $CMD
CONFIG: production=False
************* Module magic.fetcher
magic/fetcher.py:96: [C4001(invalid-string-quote), ] Invalid string quote ", should be '

------------------------------------
Your code has been rated at 10.00/10

TravisBuddy Request Identifier: dac1d270-5e54-11e9-b5c0-e1325c5e1c10


ERROR: Unknown functions manifest version. Expected 3 but found 4

This build error affects both old and new deployment. Attached a screenshot.

Hi @Anietz, thank you very much for the issues
But I am not able to reproduce this, could you please provide more details? Like what next.js version you're using, what vercel cli version you have, what your code does (only static, uses app dir, etc...), and whatever else you think could be related to the issue.
If possible, if you could provide the code itself in a repo or something that would be extremely helpful 🙏

Also experiencing this on cf pages
▲ Detected Next.js version: 12.1.4
Node is v16.15.1

not a logical default for cf pages to use a version that doesn't immediately build, I think...

yeah... hopefully it'll change at some point soon-ish: https://github.com/cloudflare/pages-build-image/discussions/1

▲ Detected Next.js version: 12.1.4

Sorry could you clarify? is this the log you see on Pages? (and I assume you're using 16.15.1 locally?) have you then changed/set your NODE_VERSION in the dashboard?

▲ Detected Next.js version: 12.1.4

Sorry could you clarify? is this the log you see on Pages? (and I assume you're using 16.15.1 locally?) have you then changed/set your NODE_VERSION in the dashboard?

it is the log from Pages and that was the version of Node I was using in Pages. I had set an env variable for NODE_VERSION but not NEXT_VERSION - setting both fixed the issue as I said

sorry I misread the log and thought you were getting two different node versions 😓  (one locally and one from pages)

I am not sure I know this NEXT_VERSION env variable and what it is used for 😕
anyways, if I understand correctly, are things working and this issue can be closed? 🙂

@dario-piotrowicz I am using NODE_VERSION 16.13.0 and NEXT_VERSION 12.1.4.
Setting this values on the dashboard seems not to fix the issue

@Anietz I'd want to look more into this but as I mentioned I could not reproduce the issue, could you please help me with some more details? some reproduction steps? or even some code? that would be extremely helpful :pray:

@dario-piotrowicz I see that when I changed the build config on the dashboard from npx @cloudflare/next-on-pages --experimental-minify to next build && next export it actually works.
I think this issue can be closed now

Glad to hear you've solved the issue :slightly_smiling_face:
Just to make sure you're aware, next export is going to generate your app as a static site (so no SSR or edge bindings, etc...), hopefully this is what you want :slightly_smiling_face::+1:


Fix background of pagination inside wide tearsheet

This is directly related to #339.
What did you change?
We added two missing classes to the list of selectors that need to be "un-overridden" to get back to the correct look inside the wide tearsheet main area.
How did you test and verify your work?
Copied the list of selectors from https://github.com/carbon-design-system/carbon/blob/ce0662896cb8919f1f11b70a1f4351750b6d7e07/packages/components/src/components/modal/_modal.scss#L49-L50 to add the missing classes.

Thank you @nertzy for the PR. I copied this exact list of cases from Carbon, so I guess pagination has been added since I did that! Good catch. I have suggested one change, because oddly Pagination doesn't seem to have a 'light prop so the two --light variant classes are not currently used by Carbon. If you agree and commit that change (you can do that easily here within github) I'll be happy to approve and merge! Thank you for your contribution.

@nertzy Also, as this PR changes the styles for a released component, there's an extra step needed to enable it to pass the CI check and be merged: we need to refresh the released styles snapshot. If you have a clone of ibm-cloud-cognitive where you can run builds etc, you'll need to run yarn jest styles -u in this branch, commit the updated snapshot file, and push it to update this PR.
PS alternatively I'll be very happy to do this step for you if you like, but you'll need to allow me -- if you look at the bottom right side of this PR and tick the checkbox

then that enables us to adjust PRs for you. It's normally a good idea to leave that checkbox ticked as it can speed things up.

Thanks for the feedback! I'm having trouble getting node-sass compiled with my latest version of NodeJS, so I'll defer to you to make the requested changes.
I don't see the checkbox you mentioned, so I'm going to try putting this PR back into draft mode to see if that allows me to make that change.

I set up nvm on my machine real quick and was able to get the snapshot generated. Let me know if there are any other edits I should make. Thanks!


Minimize to Tray when Game is Run

When I run the launcher via Steam, it tells others that I'm playing the game, but when I click Start on the launcher, it closes completely, therefore I'm running HI3, but Steam says I'm just online. I suggest to add an option to minimize to the system tray when the program is started, so that I can let my Steam friends know that I'm playing HI3.

Actually, I was thinking about this from the start. Originally I made it close so that it doesn't hang around unupdated (and with old metadata) but that's become less relevant by now. Thanks for the suggestion, will change the behavior with the next update.

Actually, I was thinking about this from the start. Originally I made it close so that it doesn't hang around unupdated (and with old metadata) but that's become less relevant by now. Thanks for the suggestion, will change the behavior with the next update.

Addressed in e3de18e

Addressed in e3de18e


real time 1m marker causing issues when viewing transactions...needs to be reverted to 5m

Description

Environment

Pinpoint version:
OS, WAS, affected library, etc:
Additional details (e.g. how your collector/web is set up):

Additional Info

@teambullseye
Hi~
Sorry. I can't understand your issue.
Please explain more detail.
What is 1m marker?

Pinpoint version: 1.6.0
when realtime is selected and drag mouse over the scatter chart, call stack is not retrieved, getting popup with message 'Scatter data of parent window had been changed'

@teambullseye
I can not reproduce your issue.
Do you know your OS, Browser version?

this is on Chrome Version 57.0.2987.133 (64-bit)......resetting the web/src/main/webapp/common/services/url-vo.service.js to 5m as adjusted numbers corrects the issue
readablePeriod = "5m";
minutePeriod = 1;		 +				 minutePeriod = 5;
millisecondPeriod = 1 * 60 * 1000;		 +				 millisecondPeriod = 5 * 60 * 1000;

@teambullseye
https://github.com/naver/pinpoint/commit/c2af632bca887560c66c6c54df427dd4605c5f5a


chore: upgrade to gradle wrapper 6.8

Relates to #734
Summary:
This PR upgrades the gradle wrapper to version 6.8. This is a required step for #933
Expected behavior:
No code change, application should be packaged as usual. Same tests should pass.
Please make sure these boxes are checked before submitting your pull request - thanks!

[x] Run the unit tests with gradle test to make sure you didn't break anything
[x] Format the title like "feat: [new feature short description]". Title must follow the Conventional Commit Specification(https://www.conventionalcommits.org/en/v1.0.0/).
[x] Linked all relevant issues
~[ ] Include screenshot(s) showing how this pull request works and fixes the issue(s)~

@lionel-nj Could you please add the https://github.com/gradle/wrapper-validation-action GitHub Action first to the repository, and then rebase this PR after that is merged?

Yes, please see https://github.com/MobilityData/gtfs-validator/pull/964
This adds additional security/integrity to ensure that any changes to the wrapper match an official Gradle release.
👍🏾

Also, is this PR the result of gradle wrapper --gradle-version 6.8? If not, I'd suggest running the command-line update directly.

That is the case.

Finally - any reason not to go ahead and update directly to 7.2, which is the latest stable release? https://gradle.org/releases/

Indeed - will update in a subsequent commit on this PR.

Closing as we will upgrade to 7.2 in #965.


The error is not caught when trying to update a modal that has exceeded the number of characters.

An error was not caught when a modal was created with more than the maximum number of characters in the "mrkdwn" type text in the modal's section block.
How can I proceed to the catch clause?
Reproducible in:
The Slack SDK version
^3.14.0
Node.js runtime version
v18.17.0
OS info
Windows 10 Pro　22H2
Steps to reproduce:
1.Press the submit button for the modal
2.Create the next modal using "mrkdwn" in the section block (the text must be at least 3000 characters)
3.Pass the created modal as an argument to the ack function to update the modal
Expected result:
An error occurs and processing proceeds in the catch clause
Actual result:
The process does not go into the CATCH clause, and the process ends.
The modal will say, "I can't seem to connect to Slack. Can you please retry?"
Requirements
For general questions/issues about Slack API platform or its server-side, could you submit questions at https://my.slack.com/help/requests/new instead. :bow:
Please read the Contributing guidelines and Code of Conduct before creating this issue or pull request. By submitting, you are agreeing to those rules.

Hi @suzuki-m07! Can you provide a snippet of the code you've described in the issue?

Thanks for your reply.
The following is a simplified version of the relevant code.
`
app.view(callbackId, async ({ ack, body, client }) => {
try {
const metadataObject = {
  keyA: "string",
  keyB: metadataArrA,
  keyC: metadataArrB
}

//Convert a metadataObject to a String type (the length of the String must be at least 3000 characters)
const metadata = JSON.stringify(metadataObject);

const modal = {
  "response_action": "update",
  "view":
  {
    "private_metadata": metadata
    "callback_id": callbackId,
    "title": {
      "type": "plain_text",
      "text": "My App",
      "emoji": true
    },
    "submit": {
      "type": "plain_text",
      "text": "submit",
      "emoji": true
    },
    "type": "modal",
    "close": {
      "type": "plain_text",
      "text": "close",
      "emoji": true
    },
    "blocks": [
      {
        "block_id": "blockId",
        "type": "section",
        "text": {
          "type": "mrkdwn",
          "text": "plain text"
        }
      },
      {
        "type": "section",
        "text": {
          "type": "mrkdwn",
          "text": ArrA.join(`,`)
        }
      }
    ]
  }
}

await ack(modal);

} catch (e) {
  await ack(makeErrorModal(e));
}

});`
When I paste the "modal" created in the above code into block kit builder, I get a character limit error in the private_metadata field.
If private_metadata is removed from "modal", it is displayed correctly.

@suzuki-m07, thank you for providing the details. The ack() method transmits an HTTP response containing the specified JSON data. In the case of Socket Mode, it dispatches a WebSocket message. Hence, your Bolt app does not receive any result in response to the ack() method call. This is why no exception is thrown in this circumstance.
Unfortunately, there is no workaround to avoid the length limit as it is requirement. Thus, the only approach to deal with this situation is to include a reference to the long string data (e.g., only incorporating a primary key string for a database row in your modal view JSON data). I hope this offers some clarification.

I see! I did not know that.
Thank you for your answer.


Some questions about the code

Thanks for your work and code! I have some confusion about the code.

The student loads the pretrained model, which is different from the methods before, is there any results for distillation without the student model?
The optimizer(AdamW) is different from the default configuration(Momentum), did you do the experiments to validate the different optimizer?
For AT or KD and so on, they are trained for 15~20epochs, but TAT is trained for 100epochs, is there any more detailed ablation experiments?
Both the student and teacher just use the stage4 as inner-feature, in which it seems that the student feature is not same as the thesis?

Please forgive me for any misunderstanding. Thank you again for your work and look forward to your reply~

Thanks for your attention.

I don't have the distillation result without pre-trained model.
I think the AdamW optimizer uses the default momentum (beta_1, beta_2) in our config.
I simply used the result from previous publications and didn't run their method on my own.
Using multi-layers for distillation might be the future work as mentioned in the Limitation section.

Unfortunately, I don't have extra GPU hours to provide more results.