-
Updated
Sep 13, 2021 - Swift
networking
Here are 4,691 public repositories matching this topic...
Currently we use a pretty naive removal of testing dependencies for SwiftPM by setting an environment variable. We should be able to use Rocket and update our Rakefile
script to just remove testing dependencies on each release, and keep it in the development process thanks to that.
The idea came from this PR that I saw RxSwiftCommunity/RxOptional#83, which sounds reall
-
Updated
Sep 15, 2021 - Rust
-
Updated
Sep 15, 2021 - Go
-
Updated
Sep 5, 2021 - Cython
-
Updated
Sep 15, 2021 - C++
If you want to work with a complete socket address type including port, we have a helper in SocketAddress
. However, the moment you want to talk only about an IP address we force you to hold an in_addr
or in_addr6
structure: hardly the friendliest versions of these data types.
We should provide a helpful wrapper IPAddress
type that can be converted into those types as needed. This would
It would be useful to be able to toggle/flag into a process-level mode to group by pid and display more process-level information like the full command line.
- For the "Utilization by process name" window, we could group by pid rather than process name so that it's easier to find specific heavy network resource consumers.
- For the "Utilization by connection" window, including the pid + cmdlin
-
Updated
Sep 15, 2021 - Python
All of the CI builds are flavors of linux. It'd be great to add some Windows / Mac ones.
Anybody know github actions and want to help out?
-
Updated
Sep 7, 2021 - C
-
Updated
Jul 2, 2021 - Java
-
Updated
Sep 9, 2021 - Go
-
Updated
Sep 12, 2021 - HTML
-
Updated
Aug 16, 2021 - C
RustScan has an accessible mode, rustscan --accessible
which should promise not to have any weird ASCII text in it.
Write CI that runs RustScan with --accessible
a few times, with different flags / options and check the terminal output to see if it contains one of these:
[!]
[~]
[>]
| {}
If any of these characters appear in any of the tests, fail the CI. E
What should happen if deliver_cancel raises an exception? In the current implementation, the shielded cancel scope will prevent it from propagating until the process exits, which might take a while if the crash occurred before signaling the process in any way. Maybe on exception from a user-specified deliver_cancel we should call the default deliver_cancel to kill the process? Or just kill() since
-
Updated
Sep 4, 2021 - Kotlin
-
Updated
Sep 13, 2021 - C++
/area API
/kind good-first-issue
Describe the feature
For flagged fields like kubernetes.podspec-fieldref
the validation should include the name of the feature flag to toggle in the error message it surfaces. The validation logic is roughly here: https://github.com/knative/serving/blob/644798277d9fe6715e4f638281141356df46d7e1/pkg/apis/serving/k8s_validation.go#L246
Cloud Providers
Add following Contents to Cloud Providers - https://github.com/Tikam02/DevOps-Guide/tree/master/Cloud_providers
- Add basic concepts of following providers:
- AWS
- GCP
- Azure
- Add tips & tricks
- Add commands
-
Updated
Sep 9, 2021 - Go
-
Updated
Sep 13, 2021 - Swift
-
Updated
Aug 24, 2021 - C++
Improve this page
Add a description, image, and links to the networking topic page so that developers can more easily learn about it.
Add this topic to your repo
To associate your repository with the networking topic, visit your repo's landing page and select "manage topics."
See original issue and associated discussion in Node.js issue tracker here: nodejs/node#36158
/cc @asklar, @aduh95, @bzoz