Hyprctl keyword broken?

Hyprland Version
 System/Version info
Hyprland, built from branch main at commit 6c4e2489a0a153ac2a92744ecb2985280c97fc89 dirty (layout: Fix toggling fullscreen special workspace on different monitor (5000)).
Date: Thu Mar 7 20:27:58 2024
Tag: v0.36.0-69-g6c4e2489

flags: (if any)

System Information:
System name: Linux
Node name: Murmaider
Release: 6.6.21-1-lts
Version: #1 SMP PREEMPT_DYNAMIC Wed, 06 Mar 2024 16:59:55 +0000

GPU information:
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA104 [Geforce RTX 3070 Ti Laptop GPU] [10de:24a0] (rev a1) (prog-if 00 [VGA controller])
06:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Rembrandt [Radeon 680M] [1002:1681] (rev c7) (prog-if 00 [VGA controller])

os-release: NAME="EndeavourOS"
PRETTY_NAME="EndeavourOS"
ID="endeavouros"
ID_LIKE="arch"
BUILD_ID="2023.11.17"
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://endeavouros.com"
DOCUMENTATION_URL="https://discovery.endeavouros.com"
SUPPORT_URL="https://forum.endeavouros.com"
BUG_REPORT_URL="https://forum.endeavouros.com/c/arch-based-related-questions/bug-reports"
PRIVACY_POLICY_URL="https://endeavouros.com/privacy-policy-2"
LOGO="endeavouros"

plugins:

Bug or Regression?
Bug
Description
$ hyprctl devices | grep touch
		asue120a:00-04f3:319b-touchpad
$ hyprctl keyword "device:asue120a:00-04f3:319b-touchpad:enabled" false
special category's first value must be the key. Key for <device> is <name>

This command used to work at some point before, but on the current version it seems not to be.
If I use getoption instead of keyword, it always says no such option (I do not think it is understanding the name key either)
How to reproduce
use hyprctl keyword to try to change a property of a device (such as disabling it)
Crash reports, logs, images, videos
No response

yeah , i'm facing same issue.
i need to toggle my touchpad more often , and there's no way in wayland to toggle it except through Hyprland.
it's so annoying , is is too much to ask for just disabling an input device ??
anyway, in the mean time you can use hyprctl keyword "general:sensitivity" 0

$ENABLE_MOUSE = true

device {
    name = mouse
    enabled = $ENABLE_MOUSE
}

hyprctl keyword '$ENABLE_MOUSE' "false"

it's not working,
hyprctl is unable to modify the variable's value

make sure you have hyprlang >0.4.0 and use single quotes around the variable name

$ENABLE_MOUSE = true

device {
    name = mouse
    enabled = $ENABLE_MOUSE
}

No worky...

And I do have hyprlang 0.4.1.
Also the old way was way better, this is kind of a lame change, it was nice to be able to reliably toggle devices this way without a special config.

my bad, you need to pass the -r flag to hyprctl.

Edit: Actually even if I set it to false in the config file directly (without hyprland keyword) it still doesn't do anything, this straight up just does not work.

Nothing besides the config parser changed, so this is not related if true

ah, your bug is I believe a dupe of https://github.com/hyprwm/hyprlang/issues/29 which was fixed in hyprlang 0.4.2

Seems like it yeah.

this update looks superfluous...
now i have to interact with hyprland.conf for making my touchpad toggle script work.
sigh....

you don't, just update hyprlang, arch's been very behind on updates recently.

no, i mean i've updated and all , and it's working by creating that variable.
all i was saying that,
now i can't automatically grep out my touchpad device and just create a oneliner/script for toggling touchpad (like before),
now i have to explicitly put my device name in hyprland config , create a variable and then create a script to toggle it.
it's problematic when i share my script to someone who is less experienced in linux and hyprland.

Indeed, that's why i said the old way is better, this just seems like a poor design choice.

you can report official packages as out-of-date, they've been reported as such for weeks.


Fix readme to install node

Summary
Updating readme to install Node
Changelist

Testing Done

Resolved Issues

Checklist
Please change [ ] to [x] when you are ready.

[x ] I have read and followed the code conventions detailed in README.md (This will save time for both you and the reviewer!).
[x ] If this pull request is longer then 500 lines, I have provided explicit justification in the summary above explaining why I cannot break this up into multiple pull requests (Small PR's are faster and less painful for everyone involved!).

Looks good to me, fixed to help with integration for Linux devices.


          > > ```dart

CarouselView.weighted

This is currently available on Master channel only. See https://main-api.flutter.dev/flutter/material/CarouselView-class.html
Closing for now.

I don't understand why it works like that. CarouselView was presented like a part of last flutter sdk update (3.24.0). Also CarouselView.weighted method available in documentation here https://main-api.flutter.dev/flutter/material/CarouselView-class.html... for what reason? to be unavailable in Stable channel?

Originally posted by @torindev in https://github.com/flutter/flutter/issues/153002#issuecomment-2291025996
I would also like to understand why,
if this Widget is not yet 100% stable I don't see the logic in implementing it in this version.

CarouselView.weighted was implemented a bit later than the original CarouselView was implemented which is why it didn't make it into the stable release. It doesn't mean the widget is not stable. See https://github.com/flutter/flutter/pull/148094 & https://github.com/flutter/flutter/pull/149775 for the timeline of the implementation
If you are facing any specific issues with the widget, please file an issue. You may try requesting a cherry-pick of the .weighted option but the cherry-picks are usually reserved for bugs that break flutter/dart.
Closing from here.
Thank you


Support Variable Binding

If I have a variable x = "#HelloWorld", I'd like to be able to get that rendered too... Its not possible currently.. I tried this:
<markdown-to-html>
{{ x }}
</markdown-to-html>

Hi @yashsriv,
Sorry for the delay, I was in Las Vegas for the last few days. You are right this feature is not currently supported by this has been on my plate for a while now ... I'll try to work on it this weekend.
I'll come back to you shortly.

@yashsriv variable binding has been implemented (#16).
Please update to v1.2.0 to get the new feature.


Browse: What selection you've made is not obvious

You may not be able to tell it from the screenshot, but I have currently filtered on Provider="npmjs."
That is not obvious after the filter is applied. The background on the Provider dropdown lit up and the list is only displaying npms. But I could easily see a user forgetting they've applied a filter on this page and not understanding how to un-apply it.

We can show the value of the selected provider in the Button, as well as show a 'x' icon to clean the selection, as part of #573


[Spec Impl] Implement Connection Re-establishment from spec

Background
The connection re-establishment section of spec says - In case of a lost connection a full flow is conducted again.
What to do
TBD

This requirement has been moved to Jira.
Link to Jira ticket: https://mosip.atlassian.net/browse/MOSIP-26909


identity is not usable when the ctrl/edge PKI are not the same

see discourse for more details https://openziti.discourse.group/t/ziti-edge-enrol-identity-not-inserting-ca-bundle/814/30
It seems that if you have a PKI for the edge controller API, and a DIFFERENT PKI for the edge data plane, the enrollment of an identity will succeed but the logic that determines if the ca bundle needs to be pulled down will not trigger, and then when the identity tries to connect it will not be able to successfully connect to the routers.
code is at https://github.com/openziti/sdk-golang/blob/main/ziti/enroll/enroll.go#L232-L258

The prevailing thought will be to pull the CA bundle regardless. Looking at the code, it sure seems like it was "done this way" on purpose a while ago, but I no longer remember exactly why.


[GOBBLIN-1309] Abort when registration is happening against a view

Dear Gobblin maintainers,
Please accept this PR. I understand that it will not be reviewed until I have checked off all the steps below!
JIRA

[ ] My PR addresses the following Gobblin JIRA issues and references them in the PR title. For example, "[GOBBLIN-XXX] My Gobblin PR"

https://issues.apache.org/jira/browse/GOBBLIN-1309

Description

[ ] Here are some details about my PR, including screenshots (if applicable):
A small changes that avoid hive registrations against a view.

Tests

[ ] My PR adds the following unit tests OR does not need testing for this extremely good reason:

Commits

[ ] My commits all reference JIRA issues in their subject lines, and I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "How to write a good git commit message":

Subject is separated from body by a blank line
Subject is limited to 50 characters
Subject does not end with a period
Subject uses the imperative mood ("add", not "adding")
Body wraps at 72 characters
Body explains "what" and "why", not "how"

Codecov Report

Merging #3146 into master will increase coverage by 4.28%.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##             master    #3146      +/-   ##
============================================
+ Coverage     41.75%   46.03%   +4.28%
- Complexity     8741     9588     +847
============================================
  Files          1986     1986
  Lines         75819    75824       +5
  Branches       8446     8447       +1
============================================
+ Hits          31656    34905    +3249
+ Misses        41145    37639    -3506
- Partials       3018     3280     +262

Impacted Files
Coverage Δ
Complexity Δ

...lin/hive/metastore/HiveMetaStoreBasedRegister.java
10.27% <0.00%> (-0.15%)
5.00 <0.00> (ø)

.../limiter/RedirectAwareRestClientRequestSender.java
84.88% <0.00%> (-2.33%)
17.00% <0.00%> (-1.00%)

...src/main/java/org/apache/gobblin/runtime/Task.java
67.04% <0.00%> (+0.22%)
83.00% <0.00%> (+1.00%)

.../org/apache/gobblin/runtime/SafeDatasetCommit.java
50.00% <0.00%> (+0.51%)
29.00% <0.00%> (ø%)

...ache/gobblin/cluster/GobblinHelixMultiManager.java
53.64% <0.00%> (+0.52%)
17.00% <0.00%> (+1.00%)

...main/java/org/apache/gobblin/util/ConfigUtils.java
58.86% <0.00%> (+0.63%)
41.00% <0.00%> (+1.00%)

...ain/java/org/apache/gobblin/runtime/fork/Fork.java
75.72% <0.00%> (+0.82%)
71.00% <0.00%> (ø%)

.../apache/gobblin/runtime/api/JobExecutionState.java
80.37% <0.00%> (+0.93%)
24.00% <0.00%> (ø%)

...e/gobblin/util/filesystem/FileSystemDecorator.java
13.07% <0.00%> (+1.96%)
13.00% <0.00%> (+2.00%)

...rg/apache/gobblin/runtime/AbstractJobLauncher.java
61.55% <0.00%> (+2.07%)
38.00% <0.00%> (+2.00%)

... and 151 more

Continue to review full report at Codecov.

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


Sending notifications in parallel gives incorrect response

Hey,
I'm having an issue where if I send two notifications in parallel, one to an ID of a device I know exists and one to a dummy ID, I get an 'InvalidRegistration' error from both .send() functions. The device does receive the 1st notification.
This causes an issue because when I get an error I want to remove that particular device token from the users tokens on the server. Currently it removes both the invalid token and the valid one resulting in the user having zero tokens and not receiving any future notifications.
Here's a gist of the script to cause this error:
https://gist.github.com/alexfoxy/1e8cdb7c3f127e6594e8e963e39224e6
You should get an output of:
FCM.send
FCM.send
{"multicast_id":8969037943863178607,"success":0,"failure":1,"canonical_ids":0,"results":[{"error":"InvalidRegistration"}]}
{"multicast_id":8969037943863178607,"success":0,"failure":1,"canonical_ids":0,"results":[{"error":"InvalidRegistration"}]}

If you send them in series it works correctly [ i.e. by moving send2() into the callback of send1() ] - output:
FCM.send
{"multicast_id":7502545296558413858,"success":1,"failure":0,"canonical_ids":0,"results":[{"message_id":"0:1470046298701173%108c2029108c2029"}]}
FCM.send
{"multicast_id":8933073754773609814,"success":0,"failure":1,"canonical_ids":0,"results":[{"error":"InvalidRegistration"}]}

This might be a bug in Firebase itself so I'm also raising this as an issue with them.
A

@alexfoxy I reproduced it and I'm already looking for a fix (or a workaround or a new implementation for parallel calls in case this is a google's fault). I'll let you know when I push a fix

@jlcvp awesome thanks. I have temporarily fixed by doing it in series which is fine for testing as we  only have a few users. Firebase said:

Thanks for bringing up this concern. I really wanted to help you here but I think this issue suits better on the that github thread. I saw that you already posted the issue there so let them check it first.

Feels like a bit of a palm off. If you find out any info about the problem, let me know and I'll pass it on to Firebase.

@alexfoxy, thanks again for reporting this. The problem was the logic of event emitter used by send function. It was also causing a memory leak in scenarios with 10+ parallel calls.
Pushed a fix and published a new version 1.0.12 on NPM.

@jlcvp excellent thanks. I can confirm it's fixed. It was quite a nasty one to track down, great job on fixing it so fast :)

Thanks! I'm going to switch from a fork (fcm-push) to this.
Also, did you take a look at the modifications of the forks in your repo's network?

@antoinerousseau Yes, I took a look at eFishery's fork. They've implemented the topic messages too and refactored the send function to use promises instead of callbacks.


Add internal IDs to forms

This adds a whole bunch of zeros.

While checking the existing practice wrt internal_id/game_index I found a typo, so I'm including that as well :)

Magical fount some problems with Arceus form IDs, so don't pull just yet...

Okay, now I add even more zeros.


MNT: rerender

Hi! This is the friendly automated conda-forge-webservice.
I've rerendered the recipe as instructed in #85.
Here's a checklist to do before merging.

[ ] Bump the build number if needed.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


Search input freezes all input under certain conditions

With some text in the search input and the text cursor at the end of the string, then selecting text with Shift + Home, all input events are ignored afterwards, including Esc, mouse clicks, etc, leaving no other option except killing the game process externally.

Thank you for the feedback, but I can't reproduce it.

I don't know if useful, but more info on my setup:

os: Windows 11
languages:

English US (selected)
English UK

region settings:

region: UK
regional format: English UK

keyboard layouts:

English US (default)
English US-International


Web version not supported!!

Will this package support the web project?

It works great w/ web projects. What issues are you having?


Support multiple entries in jestrunner.configPath

We are running our project as a monorepo with multiple modules, each having their own Jest configuration. Running tests works awesome, but we always need to change jestrunner.configPath in the root-level, shared .vscode/settings.json.
I wonder if vscode-jest-runner could be made support multiple config paths, so that we would not need to change the configuration whenever running tests from a different package than currently?

I support the idea. We currently have a Jest configuration for unit and one for integration tests in a project. However, I can only configure one in the settings. This means that I can only execute either unit or integration tests using the plugin.
As a workaround: We can create another Jest configuration, so we then have a Jest unit, a Jest integration and another one that combines the properties of both, in particular testMatch. This way we can set the combined file for the plugin jestrunner.configPath and run the tests using CodeLens. However, this only works as long as the settings are not mutually exclusive.


Attendance updates

Split admin into settings, users, and attendance
Add a list of past attendance codes to admin, along with deleting codes and number of attendees.
Split code generation and showing past codes into a common directive for small and large group.
Smallgroups can create bonus daycodes

small fixes! looks good then!

after removing the attendance daycode it doesn't reshow the generate daycode or generate bonus daycode
Show full screen doesn't hide everything and still shows a useless button

Think I got everything


Problem with redirection after uploading image (json response)

Hi, im having an issue with the filemanager, when i upload an image via the upload tab, it does not redirect me back to the home tab with the url, it just gives back the url. It's very weird. I tried downgrading to 2.0, and even changing the ckeditor version but still no luck.
Operating system : Linux
Laravel version : 6.2
Package version : 2.1
CKEditor version : 4.9.0

I would appreciate any help. Thanks

Someone to help?

Someone?

@Hi, this is because of this guy https://github.com/UniSharp/laravel-filemanager/commit/990d163d346cf1c2baf45d7fd2bec3d1c3daa0fe who commited to the master :(
Use my version of this package, I try to maintain as it possible

I have same issue today, and solved according to this guide : Uploading Dropped or Pasted Files.  it seems CKEditor 4 needs additional response from server which is 'uploaded' and 'fileName'.
composer.json
"unisharp/laravel-filemanager": "^2.1",
package.json
"ckeditor4": "github:ckeditor/ckeditor4-releases#full/stable",
edited src/Controllers/UploadController.php  line #57 into this:
                $response = [
                    'uploaded' => 1,
                    'fileName' => $new_filename,
                    'url' => $url
                ];

and now it's working properly.

Can anyone commit this change?


update container-lifecycle-hooks.md for third hook handler i,.e. TCP

unless I am missing something TCP handler is missing

/lgtm

/lgtm

/lgtm cancel

/lgtm cancel

Page preview:
https://deploy-preview-25733--kubernetes-io-master-staging.netlify.app/docs/concepts/containers/container-lifecycle-hooks/#hook-handler-implementations
:wave: @leventogut .
Is this change waiting on upstream changes?

Hi,
Sergey Kanzhelev did "lgtm cancel" on Fri, 22 Jan, 23:00. After looking at
the source code. As the code he did look at doesn't show TCPSocket.
However, these three including TCPSocket is configurable.
I am not sure how to proceed?
On Fri, 19 Feb 2021 at 23:43, Karen Bradshaw<EMAIL_ADDRESS>wrote:

Page preview:
https://deploy-preview-25733--kubernetes-io-master-staging.netlify.app/docs/concepts/containers/container-lifecycle-hooks/#hook-handler-implementations
👋 @leventogut https://github.com/leventogut .
Is this change waiting on upstream changes?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/website/pull/25733#issuecomment-782333637,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAG2VFCVHXTEVTNZGPJDCVDS73EOPANCNFSM4VDELBIQ
.

I am not sure how to proceed?

short of actually implementing this in product, I suggest to mention that this can be configured, but will not work as it is currently not supported.
Ot just close the PR

Sergey it does work, I have tested this so there must be a code somewhere.

this is a good news. Do you have an example you can share?

Here is a sample configuration running:
apiVersion: apps/v1
kind: Deployment
metadata:
name: k8s-probes
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
readinessProbe:
initialDelaySeconds: 1
periodSeconds: 2
timeoutSeconds: 1
successThreshold: 1
failureThreshold: 1
tcpSocket:
port: 80
root@knarr:~/k8s# kubectl describe po k8s-probes-57bdbfbfff-pr7kx | grep
Readiness
Readiness:      tcp-socket :80 delay=1s timeout=1s period=2s #success=1
#failure=1
root@knarr:~/k8s#
On Sat, 20 Feb 2021 at 07:58, Sergey Kanzhelev<EMAIL_ADDRESS>wrote:

Sergey it does work, I have tested this so there must be a code somewhere.
this is a good news. Do you have an example you can share?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/website/pull/25733#issuecomment-782560630,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAG2VFGLF3VP2WXD4W4JFQTS746NTANCNFSM4VDELBIQ
.

Hi @leventogut .
Just checking whether this PR needs further review or updating?

Hi Karen,
Apologies for the late reply. I am not sure where we are:
I am sure TCP probes exist and they are documented elsewhere as well.
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
I sent also a sample configuration that shows how to configure.
I am not sure who is picking up at this point? Someone should review and
accept/reject really.
On Sun, 28 Feb 2021 at 05:33, Karen Bradshaw<EMAIL_ADDRESS>wrote:

Hi @leventogut https://github.com/leventogut .
Just checking whether this PR needs further review or updating?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/website/pull/25733#issuecomment-787222250,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAG2VFCCVH54XNIJ6NE5NTTTBGTPPANCNFSM4VDELBIQ
.

Kicking this in, assuming @leventogut has verified that the TCP option works, just that the code comment is not updated.
/approve

TCP definitely works
Thanks
On 26 Mar 2021 Fri at 17:06 Qiming Teng @.***> wrote:

Kicking this in, assuming @leventogut https://github.com/leventogut has
verified that the TCP option works, just that the code comment is not
updated.
/approve
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/website/pull/25733#issuecomment-808247309,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAG2VFHVX6PZ5MWOVPNNMITTFSIFTANCNFSM4VDELBIQ
.

Sorry for coming back late for this.
@leventogut this docs page is talking about pre-stop lifecycle hooks, not the liveness and readiness probes. Can you give example of a pod with tcp pre-stop hook that works?
Pod spec will contain something like:
        lifecycle:
          preStop:

Example you gave is probes, not hooks. TCP works fine for probes.

PR to revert: https://github.com/kubernetes/website/pull/27494

Sergey you are right I am mistaken. I do apologize.
Let’s revert back. Is there anything I can do to help?
On 9 Apr 2021 Fri at 23:37 Sergey Kanzhelev @.***>
wrote:

PR to revert: #27494 https://github.com/kubernetes/website/pull/27494
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/website/pull/25733#issuecomment-816958532,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAG2VFFS4KKLALMDZWTY4ADTH5QRXANCNFSM4VDELBIQ
.

No worries. You can lgtm the revert PR https://github.com/kubernetes/website/pull/27494
As I commented earlier you are correctly identified that TCP can be configured, but would not work. Short of actually implementing this in product, one possible follow up may be to mention that this can be configured, but will not work as it is currently not supported.

/lgtm
On 9 Apr 2021 Fri at 23:37 Sergey Kanzhelev @.***>
wrote:

PR to revert: #27494 https://github.com/kubernetes/website/pull/27494
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/website/pull/25733#issuecomment-816958532,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAG2VFFS4KKLALMDZWTY4ADTH5QRXANCNFSM4VDELBIQ
.

/lgtm

can you please lgtm here: https://github.com/kubernetes/website/pull/27494 Thank you!


Add backlog parameter to the listen method

Backlog is a TCP protocol parameter determining how many unaccepted connections the kernel will keep in a queue before refusing new connections. IO::Socket::Async already supported the parameter, so only forwarding the parameter was necessary.
I believe this is the last bit of ground work for the IO::Socket::SSL look-alike on top of IO::Socket::Async::SSL that I'm working on. I named it IO::Socket::TLSViaAsync. It's mostly done, but not on the ecosystem yet.
Also, once this is merged, can you make a release allowing me to use this (and the other already merged PR).

Wow. That was fast. Thank you!


Add example "Allow guest users for a specific group"

I would like to contribute an example to the cmdlet.
May somebody guide me how and where I can contribute?
I wanted to update a setting for a specific group based on this template:
Block guest users from a specific group. In contrary to this example I wanted to set ["AllowToAddGuests"]=$True for a specific group.
However, I received the following error:
PS C:\Users\<username>> New-AzureADObjectSetting -TargetType Groups -TargetObjectId $groupID -DirectorySetting $settingsCopy
New-AzureADObjectSetting : Error occurred while executing NewObjectSetting
Code: Request_BadRequest
Message: A conflicting object with one or more of the specified property values is present in the directory.
At line:1 char:1
+ New-AzureADObjectSetting -TargetType Groups -TargetObjectId $groupID  ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [New-AzureADObjectSetting], ApiException
    + FullyQualifiedErrorId : Microsoft.Open.MSGraphBeta.Client.ApiException,Microsoft.Open.MSGraphBeta.PowerShell.NewObjectSetting

I had previously applied a setting to this Azure AD group already. Therefore I had to adjust the present setting by the Set-AzureADObjectSetting cmdlet which required to retrieve the setting Id first.
As this may happen to other users, I'd like to contribute my code as an example:
# Enter Group Name
$GroupName = "<GroupName>"

# Connect to Azure AD
Connect-AzureAD

# Lookup Azure AD group
Get-AzureADGroup -SearchString $GroupName

# Set AzureADObjectSetting to ["AllowToAddGuests"]=$True for Azure AD group
$template = Get-AzureADDirectorySettingTemplate | ? {$_.displayname -eq "Group.Unified.Guest"}
$settingsCopy = $template.CreateDirectorySetting()
$settingsCopy["AllowToAddGuests"]=$True
$groupID = (Get-AzureADGroup -SearchString $GroupName).ObjectId

# Check if there is already a present AzureADObjectSetting for that Azure AD group
Get-AzureADObjectSetting -TargetType Groups -TargetObjectI $groupID

# Get Id from present AzureADObjectSetting for that Azure AD group
$GroupsUnifedGuestId = (Get-AzureADObjectSetting -TargetType Groups -TargetObjectI $groupID).Id

# Set / Apply new AzureADObjectSetting from $settingsCopy to Azure AD group
Set-AzureADObjectSetting -TargetType Groups -TargetObjectId $groupID -Id $GroupsUnifedGuestId -DirectorySetting $settingsCopy

# Verify
(Get-AzureADObjectSetting -TargetType Groups -TargetObjectI $groupID).Values

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

ID: 9f5592e2-3fee-9034-5b33-2d1687d60ba2
Version Independent ID: 5b8dee58-e383-9a26-570a-47f5c81121cb
Content: Manage guest access in Microsoft 365 groups - Microsoft 365 admin
Content Source: microsoft-365/admin/create-groups/manage-guest-access-in-groups.md
Service: o365-administration
GitHub Login: @MikePlumleyMSFT
Microsoft Alias: mikeplum

I would like to contribute an example to the cmdlet.
May somebody guide me how and where I can contribute?

@Markus-Hanisch Markus, if you want to upload a contribution yourself, please read this readme at the repository's root here

@Markus-Hanisch  - Thank you for submitting feedback.
From our understanding, the issue you raised has been answered by @get-itips so we will close this issue.
Thank you for your contribution to make the docs better! Much appreciated!


BUG: Search-All Top Results song play button working

Is there an existing issue for this?

[X] I have searched the existing issues

What happened?
When the all section of search component is rendered for the first time . The play button doesn't work for the first time for the top song that appears below Top Results section.
This button does not work for the first song this happens, after changing to another song then using this button to play top song work.

Cause: We are currently using setCurrSong to switch between the songs in the music player. However, when this page is loaded for the first time the MusicPlayer load with the top song. So, in the onClick handler of this button we are using setCurrSong with same song again, which leads to no update in the currSong's state, preventing re-render.
https://github.com/Satyam1923/Spring-Music-Player/blob/f090341b00e24162391bf873370255ff972b1799/frontend/src/components/Search/Search.jsx#L142-L146
Record

[X] I agree to follow this project's Code of Conduct
[X] I have checked the existing issues
[X] I'm a GSSOC'24 contributor
[X] I want to work on this issue

Hey @Satyam1923 @saurabhsingh720
Can you please assign me this issue under GSSoC'24 and kindly review the PR?


"You found an error" error

You Found An Error
Battery Percentage Icon version 2.1.3 has run into an error. You can help to fix this by:

Press Ctrl+C on this message

Report the copied error at https://github.com/soleon/Percentage/issues

System.Runtime.InteropServices.ExternalException (0x80004005): A generic error occurred in GDI+.
at Wpf.Ui.Tray.Hicon.FromSource(ImageSource source)
at Wpf.Ui.Tray.Controls.NotifyIcon.OnIconChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
at System.Windows.FrameworkElement.OnPropertyChanged(DependencyPropertyChangedEventArgs e)
at System.Windows.DependencyObject.NotifyPropertyChange(DependencyPropertyChangedEventArgs args)
at System.Windows.DependencyObject.UpdateEffectiveValue(EntryIndex entryIndex, DependencyProperty dp, PropertyMetadata metadata, EffectiveValueEntry oldEntry, EffectiveValueEntry& newEntry, Boolean coerceWithDeferredReference, Boolean coerceWithCurrentValue, OperationType operationType)
at System.Windows.DependencyObject.SetValueCommon(DependencyProperty dp, Object value, PropertyMetadata metadata, Boolean coerceWithDeferredReference, Boolean coerceWithCurrentValue, OperationType operationType, Boolean isInternal)
at Percentage.App.Extensions.NotifyIconExtensions.SetIcon(NotifyIcon notifyIcon, FrameworkElement textBlock)
at Percentage.App.Extensions.NotifyIconExtensions.SetBatteryFullIcon(NotifyIcon notifyIcon)
at Percentage.App.NotifyIconWindow.UpdateBatteryStatus()
at System.Reactive.AnonymousSafeObserver`1.OnNext(T value)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
OK

You Found An Error
Battery Percentage Icon version 2.1.3 has run into an error. You can help to fix this by:

Press Ctrl+C on this message

Report the copied error at https://github.com/soleon/Percentage/issues

System.Runtime.InteropServices.ExternalException (0x80004005): A generic error occurred in GDI+.
at Wpf.Ui.Tray.Hicon.FromSource(ImageSource source)
at Wpf.Ui.Tray.Controls.NotifyIcon.OnIconChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
at System.Windows.FrameworkElement.OnPropertyChanged(DependencyPropertyChangedEventArgs e)
at System.Windows.DependencyObject.NotifyPropertyChange(DependencyPropertyChangedEventArgs args)
at System.Windows.DependencyObject.UpdateEffectiveValue(EntryIndex entryIndex, DependencyProperty dp, PropertyMetadata metadata, EffectiveValueEntry oldEntry, EffectiveValueEntry& newEntry, Boolean coerceWithDeferredReference, Boolean coerceWithCurrentValue, OperationType operationType)
at System.Windows.DependencyObject.SetValueCommon(DependencyProperty dp, Object value, PropertyMetadata metadata, Boolean coerceWithDeferredReference, Boolean coerceWithCurrentValue, OperationType operationType, Boolean isInternal)
at Percentage.App.Extensions.NotifyIconExtensions.SetIcon(NotifyIcon notifyIcon, FrameworkElement textBlock)
at Percentage.App.Extensions.NotifyIconExtensions.SetBatteryFullIcon(NotifyIcon notifyIcon)
at Percentage.App.NotifyIconWindow.UpdateBatteryStatus()
at System.Reactive.AnonymousSafeObserver`1.OnNext(T value)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
at System.Windows.Threading.DispatcherOperation.InvokeImpl()
at MS.Internal.CulturePreservingExecutionContext.CallbackWrapper(Object obj)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location ---
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
at MS.Internal.CulturePreservingExecutionContext.Run(CulturePreservingExecutionContext executionContext, ContextCallback callback, Object state)
at System.Windows.Threading.DispatcherOperation.Invoke()
at System.Windows.Threading.Dispatcher.ProcessQueue()
at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)
at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
at MS.Win32.UnsafeNativeMethods.DispatchMessage(MSG& msg)
at System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame frame)
at System.Windows.Application.RunDispatcher(Object ignore)
at System.Windows.Application.RunInternal(Window window)
at Percentage.App.App.Main()
OK

Hi @leckert123 this issue is already fixed in version 2.1.4. Please update the app to the latest version in Microsoft Store to solve this problem.
Closing, duplicated with issue #25.

I have 2.14 installed from the MS store and have the same issue still.

Hi @leckert123 when the error happens again, can you copy the full error details which should begin with something like “ Battery Percentage Icon version 2.1.4 has run into an error”.
The full detail can help me to determine the root cause of the issue.
Thanks.

My mistake. I was sleep-typing, apparently.:)  I'm no longer getting this error, with the pop-up as described.
I'm still getting the other issue, where the app disappears after some time. Typically it's when the machine goes to sleep.


return 400 on uploadMedia laravel 5.4

i have 400 error when attempting to upload video but work with image.
here the error:
(1/1) RuntimeException[400]
in Twitter.php (line 304)

I am also getting this error when trying to use an image from Giphy

I am getting the same error.  Any solution?

Well here is what I did and maybe it will work for anyone else.
$giphy = new Client();
$res = $giphy->get('https://api.giphy.com/v1/gifs/randomapi_key=xxxxxxxx&tag=xxxxxxxxx&rating=PG-13')->getBody();
$data = json_decode($res);
$image = (! str_contains('https', $data->data->fixed_width_downsampled_url) ? $data->data->fixed_width_downsampled_url : str_replace('http', 'https', $data->data->fixed_width_downsampled_url));
$file = file_get_contents($image);
$tweetedImage = Twitter::uploadMedia([
    'media' => $file,
]);
$postTweet = Twitter::postTweet([
    'status'    => $tweet,
    'media_ids' => $tweetedImage->media_id_string,
});

Thanks for the reply Kyle.  I also finally got it to work.  Pretty lacking API docs on Twitters part - IMO.

Just in case someone else finds this thread, I've forked this package and added video support (docs for video near the bottom of the readme): https://github.com/scottybo/twitter

Can we do this in 3.x @reliq?

Sorry, closing in favour of #62


[Feature Request] Support InternLM

Dear Video-LLaMA developer,
Greetings! I am vansinhu, a community developer and volunteer at InternLM. Your work has been immensely beneficial to me, and I believe it can be effectively utilized in InternLM as well. Welcome to add Discord https://discord.gg/gF9ezcmtM3 . I hope to get in touch with you.
Best regards,
vansinhu

Thanks for your information.


General performance audit

I will be logging my efforts to improve the UAVCAN driver, especially in the sense of CPU load, in this pull request. Please do not merge it yet.
Considerable time has been spent on my fruitless attempts to squeeze the driver into the FMUv2 build by switching some optimization flags and removing some not-so-critical components. Unfortunately, during my experiments the system tended to either overflow ROM, fail in a confusing way during boot, or just refuse to perform basic functions such as connecting to QGC. At some point I gave up (with much regret) and replaced FMUv2 with FMUv4.
According to the reports from @LorenzMeier, a system consisting of Zubax GNSS + a Sapog ESC + FMUv1 creates a 12% CPU load in the UAVCAN driver. I am observing a slightly different number of 7.6% with my FMUv4 setup, perhaps the difference can be explained by a higher clock rate of the newer board.
Looking at the CAN bus traffic I noticed that the ESC command messages carry six values, whereas my setup requires only four. It turned out that the default CAN quadrotor mixer is configured to generate 6 outputs rather than 4, the extra 2 serving some obscure purpose I couldn't understand. In order to validate this, I defined a new mixer and made the CAN quadrotor vehicle config refer to it. Expectedly, this change reduced the number of values per command message from 6 to 4, which allowed the UAVCAN stack to send only one frame per message. This change has dropped the CPU usage from 7.6% to 5.7%.
@LorenzMeier @AndreasAntener I strongly advice to review your VTOL mixer files and make sure that no unnecessary outputs are being generated, they slow things down.
I also added a check in the UAVCAN ESC output bridge that removes the trailing zero setpoint values from the output. This should help to somewhat improve performance even when buggy mixing is afoot.
My next step is to let the system run for several hours under a sampling profiler in order to find bottlenecks. Has this ever been done before?

Looking at preliminary profiling results (profiling is still in progress) I noticed that the system performs a lot of 64-bit floating point arithmetic computations. I understand that in some cases it is intentional and perfectly valid, since the resolution of 32-bit float is really limited. However, certain cases look like a smoking gun to me. Have a look at this instance:

Observe that a call stack rooted in the class Vector<float> (notice that the template is instantiated with the float type argument) ends up in the 64-bit square root computation routine. I checked the source and found this:
    Type norm() const {
        const Vector &a(*this);
        return Type(sqrt(a.dot(a)));
    }

It looks like the author of this code intended to use std::sqrt(), since the version from the C++ standard library is overloaded for float and double, unlike the version available from the C standard library. The alleged mistake caused the compiler to convert float to double, compute square root using emulated FP, and then convert the result back to float. Note that the M4 core has a hardware support for floating point root finding, so the difference in performance could be drastic.
One might argue that if such an error took place, the compiler would trigger the carefully enabled warning -Wdouble-promotion. Correct me if I'm wrong, but as I understand the documentation, this flag will only report implicit promotion to double, but not implicit conversion. The example above features an implicit conversion rather than promotion, so no warning should be expected. Note that -Wconversion, were it enabled, probably would not have helped here either, although for different reasons.
There are dozens of similar suspicious instances where 64-bit soft FP routines are invoked (not only sqrt but also add, asin, mul, etc.) from where they probably shouldn't be. Have a look at this preliminary interactive SVG to get an idea: pmpn-flamegraph.tar.gz (tomorrow I will upload a higher resolution file - sampling is still in progress and it is slow).
Paging @davids5.

@jgoppert
@pavel-kirienko has done some really good sleuthing here in. Can we look at avoiding the conversions and emulated FP overhead.

Good stuff. Happy to make changes to matrix. Can you submit a PR if you get it pinned down?

@pavel-kirienko I've changed the startup on our side so the CAN mixer only ever receives the multirotor component. So we should not have any overhead there. I'll check with @eyeam3 how many values the bus transports in our case.

We have an octocopter setup, so the bus transports eight values.

@pavel-kirienko Could you please fix the routines in matrix and send a PR?

@LorenzMeier Already doing so.

Here's the high resolution output: pmpn-flamegraph.tar.gz
Here's some of the most common endpoint functions:
 17.6%    os_start
  6.7%    up_idle
  4.0%    spi_readword
  2.3%    memset
  2.2%    __aeabi_dadd
  1.9%    exception_common
  1.9%    __muldf3
  1.8%    <unknown symbol>
  1.6%    __ieee754_sqrtf
  1.6%    __ieee754_sqrt

In this list, all routines prefixed with double underscore perform 64-bit floating point arithmetic.

Way too much memset going on there. We might need to revisit our defensive programming strategies.

Does anybody else find the 4% of spi_readword alarming? I checked the sources and found that the driver does a polling wait from an interrupt handler. I also ventured to make sure that the bus is clocked at the proper rate of 11 MHz (yes it is).
Can DMA or at least an IRQ-driven logic be an option?

A simple test shows that the system, indeed, spends about 5% of its run time doing nothing in the SPI polling loop (notice the duty cycle estimate in the bottom right corner):

The high level is held while the SPI driver is waiting for completion of the current transfer.

That's a design decision originally done for a single sensor and lower-rate reads. The reason this is not an immediate concern from a controls perspective is that if you're not running at 100% load there is nothing you can do before that SPI update - you are waiting for a total system state update and unless you have new accel and gyro data there is no actionable information.
No sensor data, no controller output and if there is no controller output to execute on there is nothing high-priority to do. For the same reason UART has RX DMA so that this prioritisation does not lead to communication drops.
However, work is under way to longer-term replace this with SPI DMA. That will allow to run more CPU load on house-keeping tasks, but it will not improve the flight performance on current setups - because the actionable information does not become available before.
Please focus on the CPU load related aspects. These are the ones that delay executing actionable information.

For the record here, the best performance can be achieved with -O2, which is already the default. -O3 adds about 8K of code and no noticeable performance gain, -Os shrinks the code by 2K and adds about 1% of CPU load.

Fixing the Matrix library brought CPU usage down by 10%.

N.B.: This is the second instance when a serious issue was discovered by way of profiling. The first happened 2 years ago, when we removed profiling instrumentation calls that were used for stack checking, which dropped CPU usage down by 40%: https://github.com/PX4/Firmware/pull/1660. I suspect the project could really benefit from adopting the practice of regular profiling.

The conclusion that stack checking was a performance issue is incorrect. We removed an early stage safety net because the system was stable - it was a design intent to trade CPU load for safety. We might very well re-add it on the F7.
In the case of Matrix lib it's a whole different story as it should not have promoted to double.
I agree on the benefit of regular profiling. Could you create a page in the PX4 dev guide for it?

The conclusion that stack checking was a performance issue is incorrect.

It was an issue in the sense that the actual performance hit (40%) was way above the expected penalty (20%). Profiling helped to discover that.

I agree on the benefit of regular profiling. Could you create a page in the PX4 dev guide for it?

Yes, but I will have to push back on it now a bit.

I will sum up my findings here, apart from what has been already said above.
Poll is very slow
About half of the run time of the UAVCAN driver is spent in the poll() system call. This issue doesn't affect many other modules using poll as hard because they typically run at lower update frequencies. Besides UAVCAN, optimization of the poll function will also improve some other components, especially sensors, attitude control, position control, and all other modules running at high update rates.
The poll system call must be optimized, I will report this as a separate issue.

Performance counters are slow
Many performance counters in the system do not worth the performance impact they introduce. I removed them from the UAVCAN driver, which lowered the CPU usage by 0.7%. I would advice to either review their implementation, or just remove them from all high frequency modules. My estimate is that this change alone would drop the CPU usage by up to 5%.
MAVLink
About 1% of the total run time is spent in this check in MavlinkStream::update(const hrt_abstime) which is mostly useless:
	if (dt > (interval - (_mavlink->get_main_loop_delay() / 10) * 4)) {

The performance impact can be seen here on the right, it is significant:

I wouldn't venture to fix it myself, so I propose to register this as a separate issue.
FPU is misbehaving
See the previous post. I propose to move this issue into a separate ticket, too.
UAVCAN stack
The UAVCAN stack itself does not have any detectable performance issues.

New report; note that it was collected before perfcounters were removed from the UAVCAN module: pmpn-flamegraph.tar.gz

Just talked with @davids5 about this, @pavel-kirienko Can you update matrix in this PR so we can check it passes and we can make sure the build size looks good.

@jgoppert it is already updated here

@pavel-kirienko we could look at enabling this clang-tidy check in the builds.
https://clang.llvm.org/extra/clang-tidy/checks/performance-type-promotion-in-math-fn.html

@dagar That would be useful.

I don't see a significant change in build size, so will merge the changes to matrix.
build size of master
Building sizes
   text	   data	    bss	    dec	    hex	filename
 891596	   5228	  15208	 912032	  deaa0	build_aerofc-v1_default/src/firmware/nuttx/firmware_nuttx
1317136	   5912	  20412	1343460	 147fe4	build_auav-x21_default/src/firmware/nuttx/firmware_nuttx
 787668	   3816	   9116	 800600	  c3758	build_crazyflie_default/src/firmware/nuttx/firmware_nuttx
1216616	   5844	  20636	1243096	 12f7d8	build_mindpx-v2_default/src/firmware/nuttx/firmware_nuttx
 997252	   4952	  10084	1012288	  f7240	build_px4fmu-v1_default/src/firmware/nuttx/firmware_nuttx
 967696	   5884	  18340	 991920	  f22b0	build_px4fmu-v2_default/src/firmware/nuttx/firmware_nuttx
 907220	   5884	  18340	 931444	  e3674	build_px4fmu-v2_lpe/src/firmware/nuttx/firmware_nuttx
1442236	   6140	  20724	1469100	 166aac	build_px4fmu-v3_default/src/firmware/nuttx/firmware_nuttx
1350776	   5944	  23820	1380540	 1510bc	build_px4fmu-v4_default/src/firmware/nuttx/firmware_nuttx
 774912	   5332	  15568	 795812	  c24a4	build_tap-v1_default/src/firmware/nuttx/firmware_nuttx

build size of this branch:
Building sizes
   text	   data	    bss	    dec	    hex	filename
 891356	   5228	  15208	 911792	  de9b0	build_aerofc-v1_default/src/firmware/nuttx/firmware_nuttx
1316616	   5912	  20412	1342940	 147ddc	build_auav-x21_default/src/firmware/nuttx/firmware_nuttx
 787316	   3816	   9116	 800248	  c35f8	build_crazyflie_default/src/firmware/nuttx/firmware_nuttx
1216088	   5844	  20636	1242568	 12f5c8	build_mindpx-v2_default/src/firmware/nuttx/firmware_nuttx
 996756	   4952	  10084	1011792	  f7050	build_px4fmu-v1_default/src/firmware/nuttx/firmware_nuttx
 968832	   5884	  18340	 993056	  f2720	build_px4fmu-v2_default/src/firmware/nuttx/firmware_nuttx
 907276	   5884	  18340	 931500	  e36ac	build_px4fmu-v2_lpe/src/firmware/nuttx/firmware_nuttx
1441580	   6140	  20724	1468444	 16681c	build_px4fmu-v3_default/src/firmware/nuttx/firmware_nuttx
1350128	   5944	  23820	1379892	 150e34	build_px4fmu-v4_default/src/firmware/nuttx/firmware_nuttx
 774896	   5332	  15568	 795796	  c2494	build_tap-v1_default/src/firmware/nuttx/firmware_nuttx

@jgoppert - Thank you - at least  it went in the right directions.

This is ready for merge.

@pavel-kirienko

This is ready for merge.

Apparently not yet.
Please have a log at the submode commit. See Revert "UAVCAN performance audit" #6846

This probably happened because I merged the PR on matrix and deleted the old branch and he just needs to update the matrix submodule again.

Yes, it's fixed already.


remove node-sass version note from README.md

this should be fixed in the latest releases of node-sass

thanks :)


docs: api documentation generation is not coherent

What were you initially searching for in the docs?
nothing specific. Just browsing through the API docs and looks like there are some classes that are exposed but not everything. Looking into the code looks like it's only generating docs for public classes and methods - which is fine - as long as it is coherent.
Example: IXrayRecorder is generated for Tracing.Internal namespace but the actual implementation is not.
Is this related to an existing part of the documentation? Please share a link
https://sturdy-umbrella-97433f53.pages.github.io/api/api/AWS.Lambda.Powertools.Tracing.Internal.IXRayRecorder.html is an example but there might be others.
Describe how we could make it clearer
Make it coherent across utilities.
If you have a proposed update, please share it here
Decide whether to expose only classes and APIs to be used by end customers (developers) or expose everything since the code is all open source either way.

Thanks for raising this. We are evaluating api docs and will review this. If this remains an issue please reopen. Thanks.


Tweak the #[cfg()] statements in sys/ioctl/linux a little

This should give Nix a better chance of building on architectures that aren't specifically-supported.
Supersedes #2096

cc @dirreke

Extremely appreciative of it!

Could we merge it in r0.26


Move Spark session code outside of this repo

There's a class that creates a SparkSession that's used by the test suite: https://github.com/MrPowers/quinn/blob/master/quinn/spark.py
The quinn methods don't depend on this SparkSession, which is good.  We want quinn to be easily runnable on all different types of platforms and we generally want the execution platform to define the SparkSession, not quinn.
It's probably best to simply move this class to the tests/ directory.  That way we can still access it and use it as a good example for the community, but it'll be clear that we shouldn't use it for code in the quinn/ directory.
It might be cool to monkey patch a transform method on the SparkSession class so it's easier to write code that leverages the existing SparkSession without creating a new one (or running getOrCreate).  Passing the spark session as an argument and solving the problem with dependency injection is always an option, but if we go this route, we should make conventions, like always having the spark session as the first argument when it's injected.

Is this issue still open for contributions?


minor space cleanup

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@1b073e4). Click here to learn what that means.
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff           @@
##             main      #36   +/-   ##
=======================================
  Coverage        ?   69.78%
=======================================
  Files           ?        1
  Lines           ?      278
  Branches        ?        0
=======================================
  Hits            ?      194
  Misses          ?       84
  Partials        ?        0

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


Sorald's classes that are not recorded at build step, but are invoked at runtime

Command to reproduce:
java -javaagent:/home/aman/personal/who-are-you/watchdog-agent/target/watchdog-agent-0.1.0-SNAPSHOT.jar=sbom=/home/aman/spoonlabs/sorald/sorald/target/classfile.md5 -jar sorald-0.8.6-SNAPSHOT-jar-with-dependencies.jar mine --source App.java

classfile.md5.txt
App.java
public class App {
int x;
}

See classes_javaagent.txt for all the missing classes loaded. I have ignored some internal classes, but they may have seeped in too so ignore that.

@MartinWitt have a look at it. It is interesting.

Will have a look.

Since https://github.com/ASSERT-KTH/terminator/releases/tag/v0.5.0, we are getting some fine differences. I tired running sorald with the fingerprint, but it fails by throwing Class sorald/rule/RuleViolation has been modified.
Apparently, I checked that the maven resolver is resolving this class from .m2 and that was updated sometime ago. I recorded the difference in the class files using javap -version -l -v -p -c -s -sysinfo <Classfile>.
temp_correct.txt
temp_incorrect.txt
I see some minute differences in the constant pool, but I am unsure of their cause.

Even after including the external jar sorald.jar, the application has the following classes that were not in the fingerprint:
[NOT WHITELISTED]: org/sonarsource/sonarlint/shaded/org/springframework/core/$Proxy29

And these were modified
[MODIFIED]: org/eclipse/jdt/core/dom/AST
[MODIFIED]: org/eclipse/jdt/core/dom/ASTNode
[MODIFIED]: org/eclipse/jdt/internal/compiler/parser/Scanner
[MODIFIED]: org/eclipse/jdt/internal/compiler/parser/TerminalTokens
[MODIFIED]: org/eclipse/jdt/core/compiler/IProblem
[MODIFIED]: org/eclipse/jdt/core/dom/ASTVisitor
[MODIFIED]: org/eclipse/jdt/core/dom/DefaultASTVisitor
[MODIFIED]: org/eclipse/jdt/internal/core/dom/util/DOMASTUtil
[MODIFIED]: org/eclipse/jdt/core/JavaCore
[MODIFIED]: org/eclipse/jdt/core/JavaCore$2
[MODIFIED]: org/eclipse/jdt/core/IClasspathEntry
[MODIFIED]: org/eclipse/jdt/internal/core/JavaModelManager
[MODIFIED]: org/eclipse/jdt/core/IClasspathContainer
[MODIFIED]: org/eclipse/jdt/internal/core/JavaModelManager$20
[MODIFIED]: org/eclipse/jdt/internal/core/CompilationUnit
[MODIFIED]: org/eclipse/jdt/internal/core/JavaProject
[MODIFIED]: org/eclipse/jdt/internal/compiler/impl/CompilerOptions
[MODIFIED]: org/eclipse/jdt/internal/compiler/lookup/TypeBinding
[MODIFIED]: org/eclipse/jdt/internal/compiler/lookup/ReferenceBinding
[MODIFIED]: org/eclipse/jdt/internal/compiler/lookup/Scope
[MODIFIED]: org/eclipse/jdt/core/formatter/DefaultCodeFormatterConstants
[MODIFIED]: org/eclipse/jdt/core/dom/Modifier
[MODIFIED]: org/eclipse/jdt/internal/compiler/batch/Main
[MODIFIED]: org/eclipse/jdt/internal/compiler/lookup/TypeConstants
[MODIFIED]: org/eclipse/jdt/internal/compiler/batch/Main$Logger
[MODIFIED]: org/eclipse/jdt/internal/compiler/batch/FileSystem
[MODIFIED]: org/eclipse/jdt/internal/compiler/batch/ClasspathJep247
[MODIFIED]: org/eclipse/jdt/internal/compiler/batch/ClasspathJrt
[MODIFIED]: org/eclipse/jdt/internal/compiler/batch/FileSystem$Classpath
[MODIFIED]: org/eclipse/jdt/internal/compiler/batch/ClasspathJep247Jdk12
[MODIFIED]: org/eclipse/jdt/internal/compiler/batch/ClasspathJar
[MODIFIED]: org/eclipse/jdt/internal/compiler/batch/ClasspathMultiReleaseJar
[MODIFIED]: org/eclipse/jdt/internal/compiler/util/JRTUtil$JrtFileVisitor
[MODIFIED]: org/eclipse/jdt/internal/compiler/parser/Parser
[MODIFIED]: org/eclipse/jdt/internal/compiler/parser/ParserBasicInformation
[MODIFIED]: org/eclipse/jdt/internal/compiler/batch/ClasspathJrt$2
[MODIFIED]: org/eclipse/jdt/internal/compiler/util/JRTUtil
[MODIFIED]: org/eclipse/jdt/internal/compiler/util/RuntimeIOException
[MODIFIED]: org/eclipse/jdt/internal/compiler/util/JrtFileSystem
[MODIFIED]: org/eclipse/jdt/internal/compiler/util/JrtFileSystemWithOlderRelease
[MODIFIED]: org/eclipse/jdt/internal/compiler/util/JrtFileSystem$1
[MODIFIED]: org/eclipse/jdt/internal/compiler/util/JRTUtil$AbstractFileVisitor
[MODIFIED]: org/eclipse/jdt/internal/compiler/util/JrtFileSystem$2
[MODIFIED]: org/eclipse/jdt/internal/compiler/problem/ProblemReporter
[MODIFIED]: org/eclipse/jdt/internal/compiler/ast/ASTNode
[MODIFIED]: org/eclipse/jdt/internal/compiler/ast/Expression
[MODIFIED]: org/eclipse/jdt/internal/compiler/ast/AbstractMethodDeclaration
[MODIFIED]: org/eclipse/jdt/internal/compiler/lookup/MethodBinding
[MODIFIED]: org/eclipse/jdt/internal/compiler/lookup/LookupEnvironment
[MODIFIED]: org/eclipse/jdt/internal/compiler/lookup/ParameterizedTypeBinding
[MODIFIED]: org/eclipse/jdt/internal/compiler/lookup/BinaryTypeBinding
[MODIFIED]: org/eclipse/jdt/internal/compiler/lookup/UnresolvedReferenceBinding
[MODIFIED]: org/eclipse/jdt/internal/compiler/lookup/TypeConstants$CloseMethodRecord
[MODIFIED]: org/eclipse/jdt/internal/compiler/lookup/BlockScope
[MODIFIED]: org/eclipse/jdt/internal/compiler/lookup/MethodScope
[MODIFIED]: org/eclipse/jdt/internal/compiler/lookup/ParameterizedGenericMethodBinding
[MODIFIED]: org/eclipse/jdt/internal/compiler/ast/SingleTypeReference
[MODIFIED]: org/eclipse/jdt/internal/compiler/ast/TypeDeclaration
[MODIFIED]: org/eclipse/jdt/internal/compiler/ast/ArrayAllocationExpression
[MODIFIED]: org/eclipse/jdt/internal/compiler/ast/BinaryExpression
[MODIFIED]: org/eclipse/jdt/internal/compiler/ast/CaseStatement
[MODIFIED]: org/eclipse/jdt/internal/compiler/ast/InstanceOfExpression
[MODIFIED]: org/eclipse/jdt/internal/compiler/ast/TypePattern
[MODIFIED]: org/eclipse/jdt/internal/compiler/ast/Pattern
[MODIFIED]: org/eclipse/jdt/internal/compiler/ast/GuardedPattern
[MODIFIED]: org/eclipse/jdt/internal/compiler/ast/SwitchStatement
[MODIFIED]: org/eclipse/jdt/internal/compiler/ast/LambdaExpression
[MODIFIED]: org/eclipse/jdt/internal/compiler/ast/UnaryExpression
[MODIFIED]: org/eclipse/jdt/internal/compiler/parser/Parser$1ResultExpressionsCollector
[MODIFIED]: org/eclipse/jdt/internal/compiler/parser/Parser$1TypeVisitor
[MODIFIED]: org/eclipse/jdt/internal/compiler/parser/Parser$1MethodVisitor
[MODIFIED]: org/eclipse/jdt/internal/compiler/parser/Parser$1
[MODIFIED]: org/eclipse/jdt/internal/compiler/classfmt/ClassFileConstants
[MODIFIED]: org/eclipse/jdt/internal/compiler/parser/JavadocParser
[MODIFIED]: org/eclipse/jdt/internal/compiler/parser/AbstractCommentParser
[MODIFIED]: org/eclipse/jdt/internal/compiler/parser/JavadocTagConstants
[MODIFIED]: org/eclipse/jdt/internal/compiler/ast/LambdaExpression$LocalTypeSubstitutor
[MODIFIED]: org/eclipse/jdt/internal/compiler/impl/JavaFeature
[MODIFIED]: org/eclipse/jdt/internal/compiler/util/Messages
[MODIFIED]: org/eclipse/jdt/internal/compiler/lookup/CompilationUnitScope
[MODIFIED]: org/eclipse/jdt/internal/compiler/lookup/Scope$MethodClashException
[MODIFIED]: org/eclipse/jdt/internal/compiler/lookup/MethodScope$1
[MODIFIED]: org/eclipse/jdt/internal/compiler/lookup/BinaryTypeBinding$VariableBindingInitialization
[MODIFIED]: org/eclipse/jdt/internal/compiler/lookup/BinaryTypeBinding$1
[MODIFIED]: org/eclipse/jdt/internal/compiler/lookup/BinaryTypeBinding$2
[MODIFIED]: org/eclipse/jdt/internal/compiler/lookup/SplitPackageBinding
[MODIFIED]: org/eclipse/jdt/internal/compiler/lookup/BinaryTypeBinding$ExternalAnnotationStatus
[MODIFIED]: org/eclipse/jdt/internal/core/Member
[MODIFIED]: org/eclipse/jdt/core/dom/ASTConverter
[MODIFIED]: org/eclipse/jdt/core/dom/GuardedPattern
[MODIFIED]: org/eclipse/jdt/core/dom/Pattern
[MODIFIED]: org/eclipse/jdt/core/dom/TypePattern
[MODIFIED]: org/eclipse/jdt/internal/compiler/ast/ConditionalExpression
[MODIFIED]: org/eclipse/jdt/core/dom/NullPattern
[MODIFIED]: org/eclipse/jdt/core/dom/IMethodBinding
[MODIFIED]: org/eclipse/jdt/core/dom/DocCommentParser
[MODIFIED]: org/eclipse/jdt/core/dom/TagElement
[MODIFIED]: org/eclipse/jdt/internal/core/dom/NaiveASTFlattener
[MODIFIED]: org/eclipse/jdt/core/dom/ASTNode$NodeList
[MODIFIED]: org/eclipse/jdt/core/dom/Modifier$ModifierKeyword
[MODIFIED]: org/eclipse/jdt/core/dom/TextElement
[MODIFIED]: org/eclipse/jdt/core/dom/ASTNode$NodeList$Cursor
[MODIFIED]: org/eclipse/jdt/core/dom/MethodBinding

Seems interesting. @MartinWitt

Let's investigate:
{"groupId":"org.eclipse.jdt","artifactId":"org.eclipse.jdt.core","version":"3.32.0","className":"org/eclipse/jdt/core/dom/ASTNode","classFileVersion":"55.0","hash":"026c962e622c71e916d23ecf37f1149d6be9de311a2aacab23c9498c112373cf","algorithm":"SHA256"}

Expected Hash: 026c962e622c71e916d23ecf37f1149d6be9de311a2aacab23c9498c112373cf
Mismatched Hash on my system: 8767b0e9cd402b7b61dc5fe30bb955835d35d8d9c565ad159265c649f6e5648c
I am unable to track its provenance as well. It seems that the fingerprint is built using /home/aman/.m2/repository/org/eclipse/jdt/org.eclipse.jdt.core/3.32.0/org.eclipse.jdt.core-3.32.0.jar and apparently the same classfile is also packaged into sorald-jar-with-dependency.
Maybe this classfile is not loaded from a transitive dependency?

Maybe this classfile is not loaded from a the direct dependency?

Indeed. It comes from https://github.com/SonarSource/sonar-java/blob/e985f2c7431e1c87421a0443e943ec8e80fa05e8/jdt/pom.xml#L16-L19.

We have an integration test taking care of this now.


Make apps in MCF configurable per-MC, instead of per-provider, so that we can have more granular upgrade scenarios

Make apps in MCF configurable per-MC, instead of per-provider, so that we can have more granular upgrade scenarios
related: Pull based app collections

@uvegla @ljakimczuk could one of you check if this issue is still valid?

@weatherhog  Well, I believe this may still be valid as a general improvement, but also I am not sure doing this is easily possible - we can re-evaluate it. I think it is about collection being the place where configuration for apps is generate at, and if something gets there, it gets to all clusters using given collection. If we wanted to deploy a new version of an app only to selected cluster(s), we need to apply patches inside fleet repository / repositories, where we tell clusters to use collection, or suspend Flux in these target cluster(s) and then change versions, what we usually do for testing, but none of these probably feel like a structured approach to the problem. But I have gut feeling we cannot make it more granular and structure without incurring some costs, like code duplication or sacrificing maintainability, but who knows.

Potentially related to: https://github.com/giantswarm/giantswarm/issues/31342? 🤔


Gitpod-like plugin for Meltano users

Migrated from GitLab: https://gitlab.com/meltano/hub/-/issues/245
Originally created by @aaronsteers on 2022-04-22 16:33:31

After we add support for Utility plugins (https://gitlab.com/meltano/hub/-/issues/202), it would be interesting to explore something like https://www.gitpod.io/ as a Meltano Plugin.
One challenge we face when running Meltano remotely in a containerized production or test environment is that we can't easily modify code and commit it back to the repo. And for this reason meltano ui actually runs in read-only mode within containers.
To solve for the use case of wanting to remotely modify the project and still participate in the CI/CD flow, what about a Gitpod-esque service "plugin" which could host an interface similar to Gitlab's "Visual IDE" and GitHub's GitHub.dev online IDE?
cc @pandemicsyn, @tayloramurphy
User Stories this would address:

Ability to edit the project in the cloud.
If running on the same container as Meltano UI, allow user an interface to view edits made in the Web UI: reviewing, tweaking, commit, and push the result back to the repo.
Allow a means of creating branches, switching branches, and pushing updates back to the main repo.

If a viable open source option is available as a service plugin, and especially if this could be combined with a meltano ui interface running on the same container, this opens up a bunch of use cases that just aren't possible today.

View 11 previous comments from the original issue on GitLab


Make array resuable in merge

Improve merge so that the array can be reused to produce the final result

Thanks!

@calvinlfer just FYI I’m working on multiple pieces of code on this branch, LMK if you want to continue with and I’ll figure out how to split it


TypeScript compilation error: "Generic type 'Array' requires 1 type argument(s)"

Since version 9.3, the TypeScript compiler (in my case the latest 2.4.x) throws two errors regarding a missing generic for Arrays. In particular:
First error:
node_modules/github/lib/index.d.ts(1463,24): error TS2314: Generic type 'Array<T>' requires 1 type argument(s).

Here the line:
https://github.com/mikedeboer/node-github/blob/f34f59e2ea8d0c03c0a449e1c9f65de2fe2bb413/lib/index.d.ts#L1463
Second error:
node_modules/github/lib/index.d.ts(1471,24): error TS2314: Generic type 'Array<T>' requires 1 type argument(s).

Here the line:
https://github.com/mikedeboer/node-github/blob/f34f59e2ea8d0c03c0a449e1c9f65de2fe2bb413/lib/index.d.ts#L1471
Solution:
I assume using string[] or Array<string> in both cases should fix the issue.

Opened a PR with the solution described above; also tested it within my project and it seems to fix the TypeScript compilation issue.

I think this is a result of adding a team_reviewers param in routes.json and then running node lib/generate.js. I'll look into changing the default from Array to string[]. There's another block of code in the file that has Array that I'll look into:
export type ReposReplaceTopicsParams =
    & Owner
    & Repo
    & {
      names: Array;
    };

I've updated my PR, fixing the issue in the generate.js file instead (as @kaizensoze mentioned). Also, it now uses the correct type for ReposReplaceTopicsParams.

Can this fix be published as 9.3.2? I need the TypeScript support but am not in a position to upgrade major versions.


ndk-glue does not handle NativeWindow lifecycle correctly

As far as I understand, ndk-glue's NativeActivity callbacks make it impossible or at least very hard to handle the NativeWindow lifecycle in a manner that conforms with the Android documentation. The chief offending callback is on_window_destroyed.
ANativeActivityCallbacks documentation seems to demand that NativeWindow cleanup code be executed in a synchronized manner, i.e. before the callback returns. For example, one might wish to ensure OpenGL is done drawing and destroy the associated EGLSurface.
NDK android_native_app_glue appears to follow this guideline, cf. especially how lifecycle event handling is split into pre-user-callback and post-user-callback parts (lines 89 and 146 respectively).
EDIT: for added context, compare example usage of NDK android_native_app_glue feature.

Correct!
I think the most interesting lines are 306-308 though, showing that android_app_set_window (called from  onNativeWindowDestroyed) indeed blocks and waits for the application to terminate.
At the same time it seems unfair to pull NATIVE_WINDOW from under the application, native_window() would panic in that case.
I've been thinking about fixing this before, and it probably comes down to delivering this event to the application in a different way that allows us to make sure their cleanup handler has ran, surrounded by similar synchronization primitives.

Correct!
I think the most interesting lines are 306-308 though, showing that android_app_set_window (called from  onNativeWindowDestroyed) indeed blocks and waits for the application to terminate.
At the same time it seems unfair to pull NATIVE_WINDOW from under the application, native_window() would panic in that case.
I've been thinking about fixing this before, and it probably comes down to delivering this event to the application in a different way that allows us to make sure their cleanup handler has ran, surrounded by similar synchronization primitives.

Interesting to note that their on_window_created handler first checks if the previous window was cleaned up, and sends a destroy message for it otherwise.

Interesting to note that their on_window_created handler first checks if the previous window was cleaned up, and sends a destroy message for it otherwise.

Thanks for the quick confirmation! I'd love to try to put a pull request together, but: I'm pretty new at Rust, and as you say, it would be necessary to come up with better synchronization with user code, impacting e.g. winit. I'd probably need a fair amount of hand-holding.

Thanks for the quick confirmation! I'd love to try to put a pull request together, but: I'm pretty new at Rust, and as you say, it would be necessary to come up with better synchronization with user code, impacting e.g. winit. I'd probably need a fair amount of hand-holding.

Interesting to note that their on_window_created handler first checks if the previous window was cleaned up, and sends a destroy message for it otherwise.

That is interesting! Is it just me, or does it seem to imply that it's possible for two on_window_created callbacks to fire without an intervening on_window_destroy? I suppose it raises the question whether the Android devs “know something we don't” and so one should cargo-cult it just in case.

Interesting to note that their on_window_created handler first checks if the previous window was cleaned up, and sends a destroy message for it otherwise.

That is interesting! Is it just me, or does it seem to imply that it's possible for two on_window_created callbacks to fire without an intervening on_window_destroy? I suppose it raises the question whether the Android devs “know something we don't” and so one should cargo-cult it just in case.

Interesting to note that their on_window_created handler first checks if the previous window was cleaned up, and sends a destroy message for it otherwise.

I'm not sure that's the case. It seems that the function android_app_set_window() just gets reused both for on_window_created and on_window_destroyed, relying on some undocumented invariants to do the right thing. It's just unnecessarily dense code.

Interesting to note that their on_window_created handler first checks if the previous window was cleaned up, and sends a destroy message for it otherwise.

I'm not sure that's the case. It seems that the function android_app_set_window() just gets reused both for on_window_created and on_window_destroyed, relying on some undocumented invariants to do the right thing. It's just unnecessarily dense code.

As far as solutions for ndk-glue go — assuming there is no actual black magic involved: might it not suffice to add a one-shot channel / fence of some kind that user code must notify when done with NativeWindow cleanup? There are actually only two types of events that need this kind of synchronization (on_window_destroyed and on_save_instance_state), so ad-hoccing them in one way or another seems like a passable choice.

As far as solutions for ndk-glue go — assuming there is no actual black magic involved: might it not suffice to add a one-shot channel / fence of some kind that user code must notify when done with NativeWindow cleanup? There are actually only two types of events that need this kind of synchronization (on_window_destroyed and on_save_instance_state), so ad-hoccing them in one way or another seems like a passable choice.

@maciejgodek Correct, in hindsight it seems more of a simplification than an actual paranoid attempt to make sure no window is leaked. For the same reasons I'd either like to see the same behaviour (clean up the window if non-null before assigning), or an assertion.
No matter the implementation it seems like onInputQueueDestroyed and onNativeWindowRedrawNeeded need synchronization as well; we might want to spend some time flushing out a high-level representation of these rather than applying a simple hack. I don't want to restrict API users too much; at the same time I don't want an application to deadlock because someone forgot to signal ndk-glue that one of the few "synchronous" events has been processed. That usually ends in some closure running within some locked context, though.

@maciejgodek Correct, in hindsight it seems more of a simplification than an actual paranoid attempt to make sure no window is leaked. For the same reasons I'd either like to see the same behaviour (clean up the window if non-null before assigning), or an assertion.
No matter the implementation it seems like onInputQueueDestroyed and onNativeWindowRedrawNeeded need synchronization as well; we might want to spend some time flushing out a high-level representation of these rather than applying a simple hack. I don't want to restrict API users too much; at the same time I don't want an application to deadlock because someone forgot to signal ndk-glue that one of the few "synchronous" events has been processed. That usually ends in some closure running within some locked context, though.

It took me an evening or three to get a minimal "hello triangle" app running on Android to have a basic debugging environment & get a better handle on EGL behavior. (I hacked bits of glutin together with glow-rs.) I can now try to implement your suggestion, should have something to share in a few days.
My basic idea is to give up on the UNIX pipe of single byte enums as event queue (as simple and low-overhead as it is). Instead I suggest a queue of Rust enums, much like what winit uses for user events. For events providing a new resource and/or requiring synchronization with the callback, the enum variant will contain a SyncEventContext, something along the lines of:
pub struct SyncEventContext<T> {
    done_notifier: Sender<()>,
    payload: Arc<Mutex<T>>
}

impl<T> SyncEventContext<T> {
    pub fn handle<F: FnOnce(&T)>(self, f: F) {
        {
            let lock = self.payload.lock().unwrap();
            f(&lock);
        }
        let _ = self.done_notifier.send(());
    }
}

Any thoughts?

@maciejgodek The advantage of the pipe is that can easily integrate with Androids Looper, immediately making the source clear. With this approach you'll need to .wake() the Looper and figure out where that wake came from; similar to the issue discussed in https://github.com/rust-windowing/winit/pull/1822#issuecomment-760769960.
At this point we should probably create a higher-level wrapper in ndk-glue around .wake() and retrieving event source + possible extra data, taking generics that can be passed through an atomic queue or channel.
Otherwise these events might be triggered by a single-byte write on the original UNIX pipe (or a new one with distinct ident) in the form of a new Event::SyncEvent that the consumer should retrieve/process from that queue. From an ndk-glue perspective that could be wrapped in a struct that signals done_notifier when dropped. You could possibly mix the Mutex with a Condvar to achieve this.

Ok, so a higher-level wrapper with a queue, wake(), and identifiable event source.
Here's what I've been thinking: all you need to plug into the Looper is a file descriptor that can be slept on/polled, right? I thought we could build it around eventfd instead of pipe.  As for the queueing mechanism, you could use Arc<Mutex<VecDeque>> to start with and then maybe something cleverer / more tightly integrated with the waking mechanism.

I've put together something matching the above description in PR  #121. Not sure if it's changing too much in the API. I also accidentally added a new method of building another event queue attached to the looper (e.g. user event queue in winit) and a method of sending redraw events.
I've got a winit branch that works with this API, will push it tomorrow, and try to adapt glutin for it next week.

Why is there a problem? native_window returns a guard and on_window_destroyed takes a write lock, which will block until all read locks are dropped.
I think the problem is with glutin when trying to write correct code (no one seems interested in the new glutin that fixes these issues in the next branch) or people trying to cheat the very clear api in some way (keeping raw dangling pointers to native window around)

Huh. That... might work. I'm not (yet) sure it does.
Just to be clear, for that to work the way you describe, the user (e.g. glutin) would have to hang on to their ReadLockGuard from the time they first started using the NativeWindow for as long as they wish to continue using it or any objects derived from it, such as EGLSurface.
But in that case the user needs a way of knowing that the NativeWindow is about to go away. Currently, on_window_destroyed sends the Destroyed event after trying to obtain write access to the RwLock. What's worse, it sends the notification to the winit even loop, which does not seem to notify glutin in any way (at least on master).
But let me dig around some more, I might be fundamentally misunderstanding something about the whole ecosystem. :smile:

goddessfreya the previous glutin maintainer last made contact in feb 2020, never to be heard from again, and taking the glutin improvements with her to the graveyard of dead code.

https://github.com/rust-windowing/glutin/tree/v0.23_reworks
https://github.com/rust-windowing/glutin/pull/1274
https://github.com/rust-windowing/glutin/issues/1271

Ok, I'm going to read it all carefully and close my PR for now to reduce confusion.
FWIW I still think there's either a race condition or a potential deadlock in on_window_destroyed. The notification should be sent before obtaining a write lock, so clients have a chance to drop their long-lived read locks, which they should be holding if they have created new objects dependent on NativeWindow.

@maciejgodek Did you manage to look into this yet?
I indeed agree that the notification should be sent before grabbing the write lock. Winit should hold on to the read lock as soon as raw_window_handle is called, and drop it on WindowDestroyed after it finished handling that event in user code. Alternatively Winit can grab and cache the lock in WindowCreated and serve from there if raw_window_handle is called. At that point we can only assume user code stops using the window and any implicit dependencies like Vulkan surfaces/swapchains. Reworking Winit to serve the window in ::Resumed and coming up with complicated structures to prevent using it after ::Suspended probably isn't worth it, nor really possible.

I've tried digging into last year's attempted glutin rework but it seems sufficiently different from what master that it's mostly a curiosity. :( I'm still not sure how exactly it allows users to keep an EGLContext alive while windows come and go. I'll give it another read some day — I had trouble locating all the dependencies.
As for the more immediate problem, I agree. The reasonable thing is for winit to extend the lifetime of the native window until after the user handles its Suspended event. In that case, android-ndk-rs just needs to make that possible without a race or deadlock, which should require changing approximately two lines of code. :) I will try to put together the two PRs this weekend.
What worries me is whether various winit wrappers (including but not limited to glutin) are currently capable of intercepting the Suspended event and correctly destroying the implicit dependencies of the NativeWindow without forcing the user to recreate the entire graphics context, which can be quite expensive. But that should probably be discussed elsewhere.


[8.x] Fix bug where columns would be guarded while filling Eloquent models during unit tests

Versions
laravel/framework: v8.74.0 (affects versions in 6.x and up)
PHP: 7.4.21
Description
https://github.com/laravel/framework/pull/33777 introduces a change that caches Eloquent model database table columns in memory to determine whether they should be guardable attributes or not.
This change does not consider whether or not a database connection is available. If it is unavailable, an empty list of columns will be cached for that model, resulting in subsequent tests that do have a database connection treating all columns as unfillable.
Example to reproduce
Create a unit test, and an integration test:
<?php

namespace Tests\Unit;

use MyProject\Product;
use Tests\TestCase;

/**
 * @group guardedbug
 */
class EloquentModelFillingTest extends TestCase
{
    public function testFillModel()
    {
        $foo = new Product(['name' => 'testing', 'price' => 10]);
        $this->assertSame('testing', $foo->name);
    }
}

<?php

namespace Tests\Feature;

use MyProject\Product;
use Illuminate\Foundation\Testing\RefreshDatabase;
use Tests\TestCase;

/**
 * @group guardedbug
 */
class EloquentSavingTest extends TestCase
{
    use RefreshDatabase;

    public function testFillAndSaveModel()
    {
        $foo = new Product();
        $foo->fill(['name' => 'testing', 'price' => 10]);
        $foo->save();
        $this->assertSame('testing', $foo->name);
    }
}

When you run these tests individually, the unit test fails, and the integration test passes:
# --filter EloquentModelFillingTest
1) Tests\Unit\EloquentModelFillingTest::testFillModel
Failed asserting that null is identical to 'testing'.

# --filter EloquentSavingTest
.                                                                   1 / 1 (100%)
OK (1 test, 1 assertion)

When you run them in the same test suite, they both fail. This is because the unit test run caches the empty list of columns in memory:
# --group guardedbug
Tests: 2, Assertions: 1, Errors: 1, Failures: 1.

(The error is because my environment has name as a non-nullable column in my table).
Proposal
This pull request proposes that we do not cache the column list when it is empty. This means that when running tests that don't have access to a database, it won't interfere with the rest of a suite where tests may in future have access to a database.
With this patch both of these tests pass:
# --group guardedbug
OK (2 tests, 2 assertions)

I realise this change was made to address some security issues (https://blog.laravel.com/security-release-laravel-61834-7232, https://blog.laravel.com/security-release-laravel-61835-7240).
My workaround for now is to put Model::unguard() in TestCase::setUp(), however I thought I'd propose a fix here as well.

The forceFill method can also be used by unit tests to bypass database column checks:
https://github.com/laravel/framework/blob/dba65befd443b760b48014afd6c84fad674641c7/src/Illuminate/Database/Eloquent/Model.php#L449-L454
Product::make()->forceFill([
    'name' => 'testing',
    'price' => 10,
]);


Loan request- disable the checkout button

When dealing with a loan request, we anyway scan the barcode to register the loan. The checkout button can be a source of error, because you can select the wrong line.
It would be better to disable this button.

discussed in person, closing


spelling error with executor

I found out that executor was misspelled in a lot of places,such as

https://github.com/apache/incubator-dubbo/blob/6e4ff91dfca4395a8d1b180f40f632e97acf779d/dubbo-remoting/dubbo-remoting-api/src/main/java/org/apache/dubbo/remoting/transport/dispatcher/all/AllChannelHandler.java#L41

https://github.com/apache/incubator-dubbo/blob/6e4ff91dfca4395a8d1b180f40f632e97acf779d/dubbo-remoting/dubbo-remoting-api/src/main/java/org/apache/dubbo/remoting/transport/dispatcher/all/AllChannelHandler.java#L51

https://github.com/apache/incubator-dubbo/blob/6e4ff91dfca4395a8d1b180f40f632e97acf779d/dubbo-remoting/dubbo-remoting-api/src/main/java/org/apache/dubbo/remoting/transport/dispatcher/all/AllChannelHandler.java#L61

https://github.com/apache/incubator-dubbo/blob/6e4ff91dfca4395a8d1b180f40f632e97acf779d/dubbo-remoting/dubbo-remoting-api/src/main/java/org/apache/dubbo/remoting/transport/dispatcher/all/AllChannelHandler.java#L84

https://github.com/apache/incubator-dubbo/blob/6e4ff91dfca4395a8d1b180f40f632e97acf779d/dubbo-remoting/dubbo-remoting-api/src/main/java/org/apache/dubbo/remoting/transport/dispatcher/WrappedChannelHandler.java#L113

and some other places

Can you create pull request for this issue ?
kexianjun<EMAIL_ADDRESS>于2019年3月25日周一 上午9:34写道：

I found out that executor was misspelled in a lot of places,such as
https://github.com/apache/incubator-dubbo/blob/6e4ff91dfca4395a8d1b180f40f632e97acf779d/dubbo-remoting/dubbo-remoting-api/src/main/java/org/apache/dubbo/remoting/transport/dispatcher/all/AllChannelHandler.java#L41
https://github.com/apache/incubator-dubbo/blob/6e4ff91dfca4395a8d1b180f40f632e97acf779d/dubbo-remoting/dubbo-remoting-api/src/main/java/org/apache/dubbo/remoting/transport/dispatcher/all/AllChannelHandler.java#L51
https://github.com/apache/incubator-dubbo/blob/6e4ff91dfca4395a8d1b180f40f632e97acf779d/dubbo-remoting/dubbo-remoting-api/src/main/java/org/apache/dubbo/remoting/transport/dispatcher/all/AllChannelHandler.java#L61
https://github.com/apache/incubator-dubbo/blob/6e4ff91dfca4395a8d1b180f40f632e97acf779d/dubbo-remoting/dubbo-remoting-api/src/main/java/org/apache/dubbo/remoting/transport/dispatcher/all/AllChannelHandler.java#L84
https://github.com/apache/incubator-dubbo/blob/6e4ff91dfca4395a8d1b180f40f632e97acf779d/dubbo-remoting/dubbo-remoting-api/src/main/java/org/apache/dubbo/remoting/transport/dispatcher/WrappedChannelHandler.java#L113
and some other places
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/apache/incubator-dubbo/issues/3724, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AD5mbI-bo8jqVPJmfoHbiG0w_RwnCPuNks5vaCe5gaJpZM4cF5tw
.

--
Best Regard!
cvitory

I can help with this issue

I can help with this issue

you are welcome to contribute

I can help with this issue


Hotkey response time is slower in 1.1.0

When I type a hotkey, khd 1.1.0 takes a long time to perform its action. In 1.0.1, hotkeys took effect immediately. I reproduce this on two machines running Sierra.
For instance, my left command + O is bound to simulate the left arrow key. When I press and hold those keys, I expect my text editor's insertion point to move at the key repeat rate, just like if I held the left arrow key. But while I hold the keys, I see slow and staggered motion.
I can even type a hotkey, then immediately hit another key that is not a hotkey, and the second key will take effect before the hotkey does.
My config: https://gist.github.com/kconner/9c7d3c89d187e091a65b67ec398c5e0a

Same issue here on El Capitan--don't know when exactly it started, but definitely within the last week. Happens with the default configuration as well. Even, e.g., the example config's cmd - 8 for khd -w "{" exhibits this significant delay. The delay is consistently about a second or a bit less, for every khd command. As noted above, keypresses during the delay can be lost: e.g., entering a window-resizing mode and pressing h to increase the window size to the west will bypass khd if h is pressed during the delay and h was not bound in the prior mode. khd.err contains no errors. And nothing in khd.out jumps out at me.
That being said, I tried to rollback to 1.0.1 to test for the delay, but ran into some kind of path error. khd.err was full of:
/bin/bash: khd: command not found
/bin/bash: kwmc: command not found

I can confirm that I have the same issue on Sierra.

I seem to be at least getting the command not found errors that @braham-snyder mentioned in Sierra.

I've been having the same issue since updating to Sierra a month or so ago. I've just removed Homebrew and moved to MacPorts, I'm yet to figure out why but response times are suddenly 2-3x times quicker.

Got a chance to get 1.0.1 working again--it does not exhibit this key delay for me either.
For those looking to temporarily downgrade to 1.0.1:
brew unlink khd
brew install https://github.com/koekeishiya/homebrew-khd/raw/06750f0876fea87ea2f9905f4370bbcd837c91ac/khd.rb  # url for khd v1.0.1 formula

You can easily switch later using brew switch.
@blissdev for those path errors, see issue #9--and perhaps note that, elsewhere, someone mentioned that homebrew services was overwriting their manually-edited plist file (though there are other, easier ways to circumvent the problem, mentioned in #9):

Edit/Update: Ah, and if you're using brew services to start and stop it, it will overwrite the plist so you need to update the plist file in homebrew!

@braham-snyder Thanks, I got it working by manually updating the path for the service.

Uh, I'm unable to reproduce this on my machine at this moment using the config provided by @kconner. The speed is the same when running on version 1.1.0 and 1.0.1.
@braham-snyder

Even, e.g., the example config's cmd - 8 for khd -w "{" exhibits this significant delay.

I did run into this a long time ago, but has since not been able to reproduce the problem.
Any additional information regarding this issue would be great.
Note: I am still running El Capitan 10.11.6

@koekeishiya I downgraded to 1.0.1 and that solved my problem. I'm running OS Sierra 10.12.2.
I'm not sure if I changed anything in my current config to get 1.0.1 set up, but here it is:
.khdrc - https://www.pastiebin.com/586c8a3766079
.kwm/kwmrc - https://www.pastiebin.com/586c8b3b61c2d

I think it's 643ac20ff238e744b8f06bb3e58b2cd33f56f4d5 combined with fish -- when $SHELL is fish, I see the delay, when $SHELL is anything else, I don't

How long does it take you do launch an instance of $SHELL?
You should be able to roughly test that with time $SHELL -c exit.

@dominiklohmann thanks! I'd wondered when I'd have to actually worry about the distinction between non- and login/interactive shells. In my particular case, source (conda info --root)/etc/fish/conf.d/conda.fish in my config.fish was the main offender. if status --is-interactive around it was all I needed.

I still can't reproduce this on my end.
Is this confirmed to be caused by users shell config (#10) and not directly related to Khd?
The only other changes that I remember between 1.0.1 and 1.1.0 (except for #10), is the addition of modifier only binds. I just want to make sure before any future changes are made to the codebase, that this is in fact not caused by modifier only bindings.

I'm gonna consider this issue resolved, given the new information in the previous posts.
I'm also unable to reproduce this issue on my end.

I confirm that switching my Mac OS user account shell from /usr/local/bin/fish to its default, /bin/bash, fixed slow hotkey response times. Indeed the amount of time it takes to open a new Terminal tab is about the same as the hotkey response time I was seeing.
Is there a way I can configure the khd service with brew to use a $SHELL that I specify? I'd like to keep using fish in the terminal and bash as my user.
For now I'm configuring the Terminal app to use fish and leaving my system default shell as bash. Maybe that will be fine.

Assuming you installed via Homebrew.
Stop running it via Homebrew.
brew services stop khd

Save this file as a .plist in $HOME/Library/LaunchAgents/.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>homebrew.mxcl.khd</string>
  <key>ProgramArguments</key>
  <array>
  <string>/usr/local/Cellar/khd/2.0.0/bin/khd</string>
  </array>
  <key>EnvironmentVariables</key>
  <dict>
      <key>PATH</key>
      <string>$PATH:/usr/local/Cellar/khd/2.0.0/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin</string>
      <key>SHELL</key>
      <string>/bin/bash</string>
  </dict>
  <key>KeepAlive</key>
  <true/>
  <key>StandardOutPath</key>
  <string>/tmp/khd.out</string>
  <key>StandardErrorPath</key>
  <string>/tmp/khd.err</string>
  <key>Sockets</key>
  <dict>
    <key>Listeners</key>
    <dict>
      <key>SockServiceName</key>
      <string>3021</string>
      <key>SockType</key>
      <string>dgram</string>
      <key>SockFamily</key>
      <string>IPv4</string>
  </dict>
</dict>
</dict>
</plist>

Make it load on login via launchctl.
launchctl load $HOME/Library/LaunchAgents/<filename>.plist

When updating Khd you will have to manually update the path to the Khd binary.
Alternatively you can configure launchctl to always have SHELL=/bin/bash set, but that might mess up other applications.

I can confirm this problem, and also the workaround. When login shell is zsh, khd is super slow (like 1 second + to respond). When I switch my login shell to bash, khd is as snappy as I expect it to be.
zsh in itself may not be the problem. I'm also using oh-my-zsh with extensions/plugins, so one of those could be the cause. For now, I'm going to follow @dominiklohmann's advice and create a custom LaunchAgent.
@koekeishiya can this issue be re-opened? I'm happy to help debug by sharing my zsh config, etc.

I ran into this issue on High Sierra after I installed khd.
I tried all the solutions listed in this thread but none solved the issue. I eventually uninstalled khd and the problem persisted. This led me to believe that the problem was actually a OS problem, not a khd problem.
Solution
Open System Preferences > Keyboard > Keyboard Tab and adjust:

"Key Repeat" to "Fast" (Far right)
"Delay Until Repeat" to "Short" (Far right).

This solved the issue. I believe installing khd might have tweaked these issues without me knowing.


文档有一段错误了

for employment in people.employments:
if 'company' in education:
data += employment.company.name
if 'job' in education:
data += employment.job.name'
后面的if里面应该是employment

确实是写错了，谢谢提醒！


Add test helpers

#PATCH#
CHANGELOG

Added some test helpers for consumers to use in their tests.

Changes Unknown when pulling f6303211f7970b83049194c288ad4bce3c3d6101 on sandersky:master into ** on ciena-frost:master**.

:+1:


Multi-system project

VS Code supports multi-root projects which allows adding separate folders into a project. Similarly, it would be nice to have multi-system project. I have a project where I have to work in a local folder, a remote folder and a docker container. I have three different windows open when working on this project. It would be nice to have this in one VS code project.

Yes, I think its really a design limitation we have that in one window you cannot have a mix of local and remote workspace folders.
//cc @aeschli

This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

:slightly_frowning_face: In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.
Happy Coding!