Enable CONFIG_USB_STORAGE by default

Is your feature request related to a problem? Please describe.
See issue #8541. We need this to be able to see block devices of USB connected storages (e.g : micro sd connected through and USB reader).
Describe the solution you'd like
Enable CONFIG_USB_STORAGE on the kernel
Describe alternatives you've considered
I believe supporting USB devices with partitions whose format Windows does not recognize for the --mount is being discussed and might be an alternative but I'm not an expert on this topic.
Otherwise one can just manually compile the kernel but it is not as handy as baked in WSL by default.

CONFIG_USB_STORAGE is useful in case Linux based tool is needed for USB masstorage, for example to partition, format it, etc.

This and bluetooth support is highly wanted. If people are using it and it works, it should be enabled so rebuilds aren't necessary.

Please, this is a required feature... My Linux laptop motherboard failed, and I need to access an external EXT4 drive for backup and recovery (currently attaching the drive with usbipd, but usb_storage is still required), and it feels wrong to start using a custom kernel on WSL2... I won't even know how to follow back the official kernel if I begin to diverge.
It has been a default feature of all Linux distributions for years and years... if there's a blocker in adding this feature in the default WSL2 kernel, please let's try to discuss it

Is this feature still under consideration? Or is it too difficult to implement this feature?This issue has been there for at least one year...

This is a matter of changing the configuration file, why it is not enabled by default? It is a must for having direct access to USB storage devices using usbipd.
`--- Microsoft/config-wsl.old    2024-03-21 17:19:43.529102058 -0300
+++ Microsoft/config-wsl        2024-03-21 17:25:12.299095636 -0300
@@ -1,15 +1,15 @@

Automatically generated file; DO NOT EDIT.
-# Linux/x86 <IP_ADDRESS> Kernel Configuration
+# Linux/x86 <IP_ADDRESS> Kernel Configuration

-CONFIG_CC_VERSION_TEXT="gcc (Ubuntu 11.1.0-1ubuntu1~20.04) 11.1.0"
+CONFIG_CC_VERSION_TEXT="gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0"
CONFIG_CC_IS_GCC=y
-CONFIG_GCC_VERSION=110100
+CONFIG_GCC_VERSION=110400
CONFIG_CLANG_VERSION=0
CONFIG_AS_IS_GNU=y
-CONFIG_AS_VERSION=23400
+CONFIG_AS_VERSION=23800
CONFIG_LD_IS_BFD=y
-CONFIG_LD_VERSION=23400
+CONFIG_LD_VERSION=23800
CONFIG_LLD_VERSION=0
CONFIG_CC_CAN_LINK=y
CONFIG_CC_CAN_LINK_STATIC=y
@@ -17,7 +17,7 @@
CONFIG_CC_HAS_ASM_GOTO_TIED_OUTPUT=y
CONFIG_CC_HAS_ASM_INLINE=y
CONFIG_CC_HAS_NO_PROFILE_FN_ATTR=y
-CONFIG_PAHOLE_VERSION=121
+CONFIG_PAHOLE_VERSION=125
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_TABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y
@@ -464,6 +464,7 @@
CONFIG_HAVE_LIVEPATCH=y
end of Processor type and features
+CONFIG_CC_HAS_SLS=y
CONFIG_CC_HAS_RETURN_THUNK=y
CONFIG_SPECULATION_MITIGATIONS=y
CONFIG_PAGE_TABLE_ISOLATION=y
@@ -472,6 +473,7 @@
CONFIG_CPU_UNRET_ENTRY=y
CONFIG_CPU_IBPB_ENTRY=y
CONFIG_CPU_IBRS_ENTRY=y
+# CONFIG_SLS is not set
CONFIG_ARCH_HAS_ADD_PAGES=y
CONFIG_ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE=y
@@ -2820,7 +2822,22 @@

also be needed; see USB_STORAGE Help for more info

-# CONFIG_USB_STORAGE is not set
+CONFIG_USB_STORAGE=y
+# CONFIG_USB_STORAGE_DEBUG is not set
+CONFIG_USB_STORAGE_REALTEK=y
+CONFIG_USB_STORAGE_DATAFAB=y
+CONFIG_USB_STORAGE_FREECOM=y
+CONFIG_USB_STORAGE_ISD200=y
+CONFIG_USB_STORAGE_USBAT=y
+CONFIG_USB_STORAGE_SDDR09=y
+CONFIG_USB_STORAGE_SDDR55=y
+CONFIG_USB_STORAGE_JUMPSHOT=y
+CONFIG_USB_STORAGE_ALAUDA=y
+CONFIG_USB_STORAGE_ONETOUCH=y
+CONFIG_USB_STORAGE_KARMA=y
+CONFIG_USB_STORAGE_CYPRESS_ATACB=y
+CONFIG_USB_STORAGE_ENE_UB6250=y
+CONFIG_USB_UAS=y

USB Imaging devices`

Alright I think there is no point in adding comments endlessly to ask why it's not done yet. If you are interested in the issue you can subscribe to it to be notify and you can add a thumb up to my original post.
I will tag some maintainers because they seem to not have this issue under the radar despite the fact we've been waiting for almost 2 years @OneBlue @craigloewen-msft @CatalinFetoiu
It's making tens of swe losing a lot of precious time. If you believe it's relevant to add CONFIG_USB_STORAGE please add the option otherwise please make a feedback telling why it's not relevant.
Also #11335 is a duplicate and maybe should be closed.


Clarify ExpressRoute limits concerning private peering

Please clarify ExpressRoute limits concerning private peering:

Maximum number of routes advertised from Azure private peering from the VNet address space for a connection between an ExpressRoute gateway and an ExpressRoute circuit.

This would make clear that scaling of a hub and spoke vnet topology is possible by connecting more ER gateways to the same ER circuit beyond the 200 route limit to 2000 - 20000 vnets overall.

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

ID: 3cdb32c0-628d-0be2-f514-477d46dfa1b8
Version Independent ID: fa096059-2d16-30a2-1e8b-8b9671afcaa4
Content: FAQ - Azure ExpressRoute
Content Source: articles/expressroute/expressroute-faqs.md
Service: expressroute
GitHub Login: @jaredr80
Microsoft Alias: jaredro

@jensmora Let me get some clarity on this limit and get back to you.

#assign-to:duongau


[FEATURE]Add iplocation function to PPL for IP address geolocation

Description:
We propose adding an geoip function to OpenSearch's Piped Processing Language (PPL) and SQL to provide built-in IP address geolocation capabilities.
This feature would be similar to functionality used in OpenSearch's geospatial feature, enhancing PPL's ability to enrich log data with geographical information based on IP addresses.
Proposed Functionality:

The 'geoip' function should take an IP address as input and return geographical information.
It should support both IPv4 and IPv6 addresses.
The function should return multiple fields including country, region, city, latitude, longitude, and others as available.
It should allow users to specify which geolocation fields to include in the output.
The function should use a regularly updated IP geolocation database for accuracy.

Example Usage:
... | eval geolocation = geoip(ip_field)

This would add a new field 'geolocation' with all available location information for the IP address in 'ip_field'.
... | eval country = geoip(ip_field, "country")
... | eval lat = geoip(ip_field, "lat"), lon = iplocation(ip_field, "lon")

This would add new fields with specific geolocation information.
... | eval location_info = geoip(ip_field, "country,region,city,lat,lon")

This would add a new field 'location_info' with multiple pieces of geolocation data.
Additional considerations

Allow for registering a DB table that allows resolving the IP to Geo
Adding a generic way to register the IP to Geo location resolving mechanism / service

Adding auth tokens for calling such service

Support for PPL iplocation function is required for both:
OpenSearch based PPL engine

https://github.com/opensearch-project/sql/issues/3038

Spark based PPL engine

https://github.com/opensearch-project/opensearch-spark/issues/672

Related resources

https://github.com/opensearch-project/geospatial?tab=readme-ov-file

[Catch All Triage - 1, 2,  3,  4]

For the community awareness, I'm working on this.


[Feature] 请问每个任务的分是怎么计算的呢？比如OS任务中得到的只是一个准确率，但是在论文中Table3每个任务对应的都是分数，这中间的映射过程我在文中并没有找到，可以提示一下吗

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

hi, @lonerFarea 分数的计算方式就是根据Table2的权重进行加权平均


Proposal: Split up matchmaker_config.yaml

The matchmaker_config.yaml has grown to be a very large file and Open Match is a set up different servers with different context. We should consider splitting up the configuration so that each server is only provided the context necessary to run properly.
This should improve reliability because it'll force users to have multiple ConfigMaps for each configuration so if there's a bad config change it'll only impact a subset of server types instead of all of them.

I believe the ConfigMap could still remain single, but instead it will contain several entries in "data" section. Some pieces of configuration should be shared by services, some are independent, isn't it?

Thought about this for a bit.  There are definitely some per-component configs, where every component can have different values for these without issues. In fact, in many situations it would be preferred.  In particular, having the logging config and debug flags on a 'per component' basis would be nice.
However, the majority of the parameters in the configs are there specifically for sharing - so that the values aren't baked into the code and when a change needs to be made, every component gets the same values (and hopefully avoid a situation where multiple components could accidentally have different values). To be honest, it would probably be a good idea to isolate the ones of those that we don't want beginners accidentally changing, like service names  and port numbers.  I still wouldn't want them baked directly into the code, but maybe move them back to being in a config location built into the container images by default.  We could then update the OM config loading module to 'override' the defaults with values from a configmap if it exists.  That way expert users (people deploying OM to a K8s cluster with many other apps and potential port conflicts, for example) could configure those sorts of things, but beginners aren't exposed to all that extra complexity that they probably don't need to mess with at all.  Some other things, like the list of properties to index, need to be kept in sync between the component writing the index (FE API) and the component deleting the index (BE API), but also should absolutely be modified by someone coding a matchmaker against OM.
Right now based on 0.4.0 WIP branch, and leaving out things that are getting deprecated and should be removed in future versions:
I see the first group ('per component' config) as containing:
debug: true
logging:
  level: debug
  format: text
  source: true
redis:
  pool:
    maxIdle: 3
    maxActive: 0
    idleTimeout: 60
  queryArgs:
    count: 10000
  results:
    pageSize: 10000

The second group ('we should hide this but allow overrides for experts' config):
api:
  backend:
    hostname: om-backendapi
    port: 50505
  frontend:
    hostname: om-frontendapi
    port: 50504
  mmlogic:
    hostname: om-mmlogicapi
    port: 50503
  functions:
    port: 50502
metrics:
  port: 9555
  endpoint: /metrics
queues:
  proposals:
    name: proposalq
ignoreLists:
  proposed:
    name: proposed
  deindexed:
    name: deindexed
  expired:
    name: OM_METADATA.accessed

And the third ('expose to users but any change should go to all components by default' config):
api:
  backend:
    backoff: "[2 32] *2 ~0.33 <30"
  frontend:
    backoff: "[2 32] *2 ~0.33 <300"
evalutor:
  intervalMs: 10000
  pollIntervalMs: 1000
metrics:
  reportingPeriod: 5
ignoreLists:
  proposed:
    offset: 0
    duration: 800
  deindexed:
    offset: 0
    duration: 800
  expired:
    offset: 800
    duration: 0
redis:
  expirations:
    player: 43200
    matchobject: 43200
playerIndices:
- char.cleric
- char.knight
- char.paladin
- map.aleroth
- map.oasis
- mmr.rating
- mode.battleroyale
- mode.ctf
- mode.demo
- region.europe-east1
- region.europe-west1
- region.europe-west2
- region.europe-west3
- region.europe-west4
- role.dps
- role.support
- role.tank

Note, if we did split these out into these categories, it would probably be a good idea to change some of the hierarchies, which don't make as much sense if not all the values are in the same config.

Anybody working on this? I'd like to take it.

I can't seem to assign this issue to you.

We have revisiting the configuration for Open Match on v0.7 roadmap (exploring ways to change  application level configuration such as indexes more dynamically). This task will likely merge into that work. Not in scope for v0.6

Closed by #652 and #667


[WIP]: CI: Build musllinux aarch64 and x86_64 wheels, and native macOS arm64 wheels

Description
This PR addresses the following:

Adds macos-14 GitHub Actions runners to target macOS arm64 wheels natively, without cross-compilation
Configures the build_linux_aarch64_wheels and build_linux_x86_64_wheels jobs to include MUSL wheels (which were previously being skipped).

Footnotes
This PR:

closes gh-718,
closes gh-623, and
is a follow-up to gh-710 and gh-712.

This should be ready for review now, please check the logs here: https://github.com/agriyakhetarpal/pywt/actions/runs/8255410993/job/22581797957
All job produce a singleton wheel, except for the GNU/Linux jobs that produce two – both musllinux and manylinux wheels.

All wheels are getting built, please see this workflow run: https://github.com/agriyakhetarpal/pywt/actions/runs/8262339804


[AutoPR network/resource-manager] [Portal Generated] Review request for Microsoft.Network to add version 2018-10-01

Created to sync https://github.com/Azure/azure-rest-api-specs/pull/4361

(message created by the CI based on PR content)


press enter to send chat

In online chats, users will generally expect to be able to use the enter key to send messages (e.g. WhatsApp, Facebook Messenger). The chat function on couchers should allow this behavior.
I have created a pull request here: https://github.com/Couchers-org/couchers/pull/2048

This needs input from the design team (I will ask). We want to encourage long-form messages (though I agree the current "bubble" design doesn't lend itself to that) so I'm not sure we should do this.

That makes sense, yes, hence the use of textarea instead of input. I agree that whether this is a good idea depends on how the chat is intended to be used. I got to the chat feature just by playing around, presumably users would have another purpose in mind.

Further comment on the PR


Error in Flutter1.20

When I update my Flutter version to 1.20, i can‘t run my project，because error
../../../../../../development/flutter/.pub-cache/hosted/pub.dartlang.org/flutter_datetime_picker-1.3.8/lib/src/datetime_picker_theme.dart:6:28: Error: Type 'DiagnosticableMixin' not found.
class DatePickerTheme with DiagnosticableMixin {
^^^^^^^^^^^^^^^^^^^
../../../../../../development/flutter/.pub-cache/hosted/pub.dartlang.org/flutter_datetime_picker-1.3.8/lib/src/datetime_picker_theme.dart:6:7: Error: The type 'DiagnosticableMixin' can't be mixed in.
class DatePickerTheme with DiagnosticableMixin {
^
Any help?

yes, i am face same issues

Edit the source code (for now, awaiting the release) and replace DiagnosticableMixin with DiagnosticableTreeMixin

@carmas123 That solution works as well, however the source actually notes that it will be switching to "Diagnosticable" and not the *TreeMixin variant. Not sure if this will have any consequences once it is updated. But figured it was worth mentioning. 🤷♂
// Migrate DiagnosticableMixin to Diagnosticable until
// https://github.com/flutter/flutter/pull/51495 makes it into stable (v1.15.21)
class DatePickerTheme with Diagnosticable {
...
}

same issues

Thanks @carmas123 ,I have already fixed it by replacing DiagnosticableMixin  with DiagnosticableTreeMixin

same issues

You might want to try flutter clean and flutter upgrade.
Can you provide more insight into your issue?

Same build issue after upgrading to Flutter 1.20.1 today.
is there any side effect to change DiagnosticableMixin to the other one?

Thanks for your help. I've fixed this issue


Enabling access for a user

I'm unable to access covid-modeling.org -- should I be able to? Assuming so, I get a message saying "access has not been enabled for [my] user". Details can be seen here.

Thanks for your interest in our model-runner. We are currently in a limited alpha release and invitations are currently only for the model owners and developers.


Sf4 bin/console error

Hello,
i added to my bundle
Rewieer\TaskSchedulerBundle\RewieerTaskSchedulerBundle::class => ['all' => true],
and when i try command bin/console i got 2 errors
In ListCommand.php line 21:                                                                                Too few arguments to function Rewieer\TaskSchedulerBundle\Command\ListCommand::__construct(), 0 passed in /home/app/api/var/cache/dev/Container21wWpWf/getTs_ListCommandService.php on line 12 and exac     tly 1 expected
In RunCommand.php line 21:                                                                                Too few arguments to function Rewieer\TaskSchedulerBundle\Command\RunCommand::__construct(), 0 passed in /home/app/api/var/cache/dev/Container21wWpWf/getTs_RunCommandService.php on line 12 and exactl     y 1 expected
Please help me

@NicoHaase would this be linked to your last PR ? In which case this is solved in next release :)

Yes, this should be resolved in 0.2.1 - I'm sorry that the last PR did not contain all neccessary stuff.
@Pawel9903 can you check whether 0.2.1 solves your problem?

Its work 0.2.1 i make composer update
Thanks!


bin/setup script to setup development environment

Description
As a developer, I want to be able to start a development server on my machine.  All the default configuration / seed data should be copied into place when I type bin/setup so that I can next type rails server and have a working application running
Acceptance criteria

[ ]  bin/setup copies all configuration templates.
[ ] runs rake db:migrate
[ ] runs rake db:seed

ADDITIONAL ACCEPTANCE CRITERIA

[ ] After I run bin/setup, I can run rails server and access the application at localhost:3000


Serenity/JS should contain  templates with Selenium

What's the problem you're trying to solve?
I want to use serenity js with Selenium, but I can´t find nothing related
How would you like to solve it?
Making templates with selenium with properly documentation
Are there any alternatives?
No response
How can we make it happen?

[ ] work on this myself (with Serenity/JS team guidance)
[ ] hire the Serenity/JS team to build it for me
[ ] add it to the Serenity/JS backlog and wait for a volunteer

Hi @juanduarte1927!
At the moment, Serenity/JS supports integration with WebdriverIO. Similarly to Selenium JavaScript, WebdriverIO supports the WebDriver protocol, as well as the Selenium Grid, but also offers local testing and mobile automation, not to mention the test runner.
I think that long-term it would be great for Serenity/JS to also integrate with Selenium JavaScript, especially when Bi-Di is ready. However, to address your immediate need, is there anything that Selenium JS offers that WebdriverIO doesn't?


Newly created forces do not have cease_fire set up

Listen to on_force_created and set it.

Resolved by 36b8910d3ca70110ac7dd9663505c9f03bf5aebd.

Resolved by 36b8910d3ca70110ac7dd9663505c9f03bf5aebd.


return the parsed message if processMessage is successful

this will make it easier for clients (e.g. web5-js) to use the actual class object instead of having to manipulate JSON

I'd try to tag on the message outside of individual handlers, in one place (perhaps somewhere in Dwn.processMessage()) so that the handlers don't have to know about it and there is one place that this takes place.
Above said, @frankhinek seems to have ideas already planned for web5-js so we should probably hold off until this work is confirmed necessary.
Also, I am aware that MessageReply is becoming polluted..., there is a separate discussion to refactor processMessage() altogether, see #289.

I'd try to tag on the message outside of individual handlers, in one place (perhaps somewhere in Dwn.processMessage()) so that the handlers don't have to know about it and there is one place that this takes place.

my concern with this is that outside only has the raw JSON payload, not the class instance result of parse
giving the developer access to the class makes it much nicer to access relevant fields (e.g. we could add a get recordId to all of RecordsWrite, RecordsRead, and RecordsDelete so that it's a similar API)

Closing, since there hasn't been any movement or discussion on this PR in over a month. If anyone is still interested in this proposal and wants to track it, feel free to open an issue.


"Schedule Job" - Don't repeat job if user didn't want it repeated

If the user skips the "repeat" field, don't call the line .repeatEvery(jobRepeatEvery) in createJob method.

Actually if the jobRepeatEvery is empty the job won't repeat. No need to skip the call.

With this input:

I get this output:

I would like to remove the "repeat" circle-arrow label.

Yes, you are right. The job doesn't repeat but the UI shows the "repeat" circle-arrow label.

Should be fixed in 0.3.2


Daily update

Automated changes by create-pull-request GitHub action

Build failed because of:
No cached entry, and Saaras, Inc. has issues with logo: saaras_inc.svg, SVG file embeds a png. Please use a pure svg file
No cached entry, and GraphCMS has issues with logo: graphcms.svg, This logo cannot be autocropped because of an unusual interaction with its viewbox. Please find a different logo or convert again from the original to SVG.
No cached entry, and Sollers College has issues with twitter: https://twitter.com/SollersEdu, 401 - {"request":"/1.1/statuses/user_timeline","error":"Not authorized."}
Empty twitter for CSIRO/DATA 61: https://twitter.com/CSIROnews
Empty twitter for TYNYBAY Inc: https://twitter.com/tynybayinc
Empty twitter for Truepic, Inc.: https://twitter.com/truepicinc
Empty twitter for Tectonic Labs Ltd.: https://twitter.com/cloud_ridge
Empty twitter for SVA System Vertrieb Alexander GmbH: https://twitter.com/SvaGmbh
Empty twitter for Surge: https://twitter.com/surgetech
No cached entry, and Mellanox Technologies, Ltd has issues with twitter: https://twitter.com/mellanoxtech, 404 - {"errors":[{"code":34,"message":"Sorry, that page does not exist."}]}
Empty twitter for Rancher Federal: https://twitter.com/RancherFederal
No cached entry, and JVC KENWOOD Corporation has issues with twitter: https://twitter.com/JVCKENWOOD_SR, 401 - {"request":"/1.1/statuses/user_timeline","error":"Not authorized."}
Empty twitter for eBaoTech International Pte Ltd: https://twitter.com/Ebaotech
Empty twitter for China Telecommunications Corporation: https://twitter.com/chinatelecom1
Item GraphCMS has no image_data
Item Saaras, Inc. has no image_data


Added a code to merge linkedlist using python

Have you read the Contributing Guidelines on Pull Requests?
Yes
Description
Added a code that merges two sorted linked list into the single linked list using python
Checklist

[x] I've read the contribution guidelines.
[x] I've checked the issue list before deciding what to submit.

Related Issues or Pull Requests
Merge two sorted linked list using python
Issue: #836
Fill up the DCP form
If you are a part of DCP 21, fill up this form after the PR is merged.
The links provided in the form will be checked thoroughly, if someone tries fooling around, strict actions will be taken against the individual.

Add some comments in between to explain your code logic.
Also, add the space-time complexity of the program,

@noviicee Done 👍🏻


[Question] How to prefix DB tables

Hi,
Twill creates a twill_users table, which is absolutely fine :)
However, it doesn't take this liberty with other tables, e.g. tags, files etc
This causes problems for adding Twill to pre-existing projects that already use those tables for domain entities.
Is it be possible to make sure all twill tables are namespaced correctly to prevent conflicts?
Thanks

That's a very good suggestion @OwenMelbz, I'll add the ability to provide custom table names from configuration like for the twill_users table. We'll keep defaults in 1.2.2 to the current non prefixed names but when it is time for 1.3 we can definitely change all table names to prefixed.

Resolved by 7fced6057183e624b0acdf0805f4513b1d9b9623.


Explicitly mention Free Apps are not supported

Explicitly mention Free Apps are not supported

@MarkvanMents FYI upon return.


userAttributes "fullname" doesn't show up in amplify_outputs.json

Environment information
System:
  OS: macOS 14.4
  CPU: (10) arm64 Apple M1 Pro
  Memory: 145.38 MB / 16.00 GB
  Shell: /bin/zsh
Binaries:
  Node: 20.12.2 - /private/var/folders/h8/0sklzj9n1pz2zjt34vl3t15w0000gn/T/xfs-67f2acff/node
  Yarn: 4.1.1 - /private/var/folders/h8/0sklzj9n1pz2zjt34vl3t15w0000gn/T/xfs-67f2acff/yarn
  npm: 10.5.0 - ~/.nvm/versions/node/v20.12.2/bin/npm
  pnpm: undefined - undefined
NPM Packages:
  @aws-amplify/backend: 1.0.0
  @aws-amplify/backend-cli: 1.0.1
  aws-amplify: 6.2.0
  aws-cdk: 2.139.0
  aws-cdk-lib: 2.139.0
  typescript: 5.4.5
AWS environment variables:
  AWS_STS_REGIONAL_ENDPOINTS = regional
  AWS_NODEJS_CONNECTION_REUSE_ENABLED = 1
  AWS_SDK_LOAD_CONFIG = 1
No CDK environment variables

Description
export const auth = defineAuth({
  loginWith: {
    email: true,
  },
  userAttributes: {
    fullname: { required: true },
    givenName: { required: true },
    familyName: {},
    email: { required: true, mutable: false },
  },

amplify_outputs.json
{
  "auth": {
    "user_pool_id": "",
    "aws_region": "",
    "user_pool_client_id": "",
    "identity_pool_id": "",
    "standard_required_attributes": [
      "email",
      "given_name" // should have full_name or name
    ],
    "username_attributes": [
      "email"
    ],
    "user_verification_types": [
      "email"
    ],
    "password_policy": {
      "min_length": 8,
      "require_numbers": true,
      "require_lowercase": true,
      "require_uppercase": true,
      "require_symbols": true
    },
    "unauthenticated_identities_enabled": true
  },

Attributes did not conform to the schema: name.formatted: The attribute name.formatted is required

Hey, thank you for reaching. Was able to reproduce the behavior. Marking as bug.


Feature/payone ideal pwa

PR Type

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no API changes)
[ ] Build-related changes
[ ] CI-related changes
[ ] Documentation content changes
[ ] Application / infrastructure changes
[ ] Other:
What Is the Current Behavior?
Payone iDeal payment method is not supported.

Issue Number: Closes #
What Is the New Behavior?
Payone iDeal payment method is supported.
Does this PR Introduce a Breaking Change?

[ ] Yes
[x] No
Other Information

Can you rebase this branch onto develop please? Meanwhile we have integrated eslint and some other stuff, so pls check if  your  changes still work and will be linted without problems.


Markdown links CI check

This adds a CI check to make sure Markdown links are valid.
There are currently failures in this CI check, but the idea is to merge the PR as is and then ask the respective teams to fix the invalid links.
Depends on:

https://github.com/input-output-hk/cicero/issues/67
https://github.com/input-output-hk/cardano-ledger/pull/3245
https://github.com/input-output-hk/cicero/issues/67

bors r+


Rather than using 'latest' JOSM cask now has version and sha256 hash

Please squash your commits.

Squashed


Trim equilibration during analysis

Description
The main objective behind these changes is to perform the "trimming" of the trajectories during the analysis step, rather than by submitting the parts which were removed for equilibration as a separate set of jobs.
The purpose behind those changes are twofold:

Remove input parameter for a lot of the submission functions to clarify what they are doing.
Simplify submission such that the calculations don't need to be broken down into too many sub-jobs.

Todos
Notable points that this PR has either accomplished or will accomplish.

[ ] test code

Codecov Report

Merging #90 (34944b9) into main (33ef630) will increase coverage by 0.00%.
The diff coverage is 32.35%.

@@           Coverage Diff           @@
##             main      #90   +/-   ##
=======================================
  Coverage   15.72%   15.72%
=======================================
  Files          51       51
  Lines        5534     5532    -2
=======================================
  Hits          870      870
+ Misses       4664     4662    -2

Flag
Coverage Δ

unittests
15.72% <32.35%> (+<0.01%)
:arrow_up:

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

Impacted Files
Coverage Δ

...s/function_libs/analysis/parameter_optimization.py
0.00% <0.00%> (ø)

...cripts/analysis_workers/RE_EDS_general_analysis.py
0.00% <0.00%> (ø)

...ipts/analysis_workers/RE_EDS_optimization_final.py
0.00% <0.00%> (ø)

...s/function_libs/optimization/eds_energy_offsets.py
74.35% <62.50%> (+0.40%)
:arrow_up:

...s/function_libs/file_management/file_management.py
9.55% <100.00%> (+0.40%)
:arrow_up:

...nction_libs/optimization/src/sopt_Pathstatistic.py
95.23% <100.00%> (-0.08%)
:arrow_down:

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


Not able to configure radio

I'm having trouble with configuring my transceiver. I'm using an E07-M11010 just like the one in the hardware guide (except it's the v2.0), and I am using the same pinout. Maybe the pinout for the v2.0 is different? But as far as I could find out, it is the same (as in the hardware guide). However, if I boot my ESP32 with the transceiver connected, the ESP Somfy RTS homepage does not load (webserver not reachable) and it appears to be stuck in a boot loop, as this serial ouput repeats over and over again:
rst:0x10 (RTCWDT_RTC_RESET),boot:0x32 (SPI_FAST_FLASH_BOOT)
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
inv⸮ets Jul 29 2019 12:21:46

When I connect the transceiver after the ESP32 has booted, configure the radio and hit the Save Radio Button, it get's stuck on a loading screen and ESP Somfy RTS is not responsive anymore. The serial output while trying to configure the radio is:
Deserialize Radio JSON SCK:23 MISO:13 MOSI:19 CSN:18 RX:5 TX:12
Save Radio Settings SCK:23 MISO:13 MOSI:19 CSN:18 RX:5 TX:12
Applying radio settings Setting Data Pins RX:5 TX:12
Setting SPI Pins SCK:23 MISO:13 MOSI:19 CSN:18
Radio Pins Configured!

I think it might be a hardware problem, maybe a faulty transceiver? Or I am using the wrong pinout?
Did someone else experience this behavior?
Thanks!

Recheck your wiring.  If the hardware is locking up it is most likely a wiring problem.

@LorisSchmit did you get your issue resolved?

I am going to close this for now.  Feel free to re-open it if your problem has not been resolved.


Blank space for units

Many parameters have blank space for units in master CDFs. Nand reports the units for these parameters as blank spaces.
For example, FAULT in WI_K0_SPHA
My understanding is that a blank space in a master CDF GlobalAttribute is a signal to CDAWeb that the value should be obtained from a raw CDF (usually because it varies across files).
Does a blank space for units mean "dimensionless" or does it mean either dimensionless or "I don't know the unit or don't want to enter the unit but I want to pass validation?"
Also, some parameters have an empty string for UNITS (for example, SYMM of WI_ELM2_3DP). Nand gives these parameters units of null.

I don't know about UNITS but for CATDESC, VAR_NOTES, and VARIABLE_PURPOSE, a single period character in the master also means to look in the data CDF for the value.  A single period seems to be equivalent to a single blank character but I guess it's easier to see.

I see. I was not expecting that based on https://cdaweb.gsfc.nasa.gov/pub/software/cdawlib/0MASTERS/00readme.txt, which only mentions spaces for global attributes.
Why would one not want to put CATDESC in the master CDF? Does it ever vary with time?


Just added the images of  the graphs

I am closing this one since it is better not to add image files to the repository. It can be easily regenerated by rerunning the scripts.


How do I automatically re-render on resize when using components?

I am trying to trigger a re-render when resizing so that components update, but I am not seeing an example of how to do that idiomatically.
What is the best way to go about doing this?

@haveamission  All user resize events are automatically checked against your media queries - components get re-rendered when the media query is matched or unmatched.


Repository Files Don't Work

To onboard, this page indicates that we need to create three Configuration Profiles for Full Disk Access, Network Filter, and Notifications. I downloaded the items from the linked GitHub Repository:
https://github.com/microsoft/mdatp-xplat/tree/master/macos/mobileconfig/profiles
When creating these configuration profiles, they all return an error when adding the repository files: "Must be a well formed XML string" and I cannot continue creating these profiles. So, how do we proceed with these three configurations??

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

ID: cd66a255-36e5-29dc-7610-d50ef8bca3f3
Version Independent ID: 17375473-bc07-f8e5-a85f-d732bbba3d71
Content: Intune-based deployment for Microsoft Defender for Endpoint on Mac
Content Source: microsoft-365/security/defender-endpoint/mac-install-with-intune.md
Product: m365-security
Technology: mde
GitHub Login: @Dansimp
Microsoft Alias: dansimp

@Dansimp Please help us in resolving this issue. Thanks

I think backward slash is missing at the end of the each url

Negative. I also tried forward slashes, but no luck.

This issue is closed. For whatever reason, trying to save the mobileconfig files from GIT got me a source code for the GIT site. This doesn't make sense since it automatically offered the file name. In any case, right-clicking the links in the instructions on this page got me an XML file that worked.


support for resizeMethod

Hi,
I have a list of rather large images, and I want smooth scroll behavior. If I use react native's Image with resizeMethod set to resize, I get a performance boost over FastImage but I lose the caching and loading optimizations of FastImage.
Is there a reason why FastImage doesn't support resizeMethod prop?
thanks.

@mrafei are you loading big images, but showing them in a smaller format? Could you load the smaller images first, and only load the big image when needed (like maybe after someone presses/clicks the small image)

@mrafei Have you checked the https://github.com/DylanVann/react-native-fast-image#resizemode-enum property?

I haven't tried forked version, but I have allied  "dirty fix" in FastImageViewManager.java
Just for test I have changed this line
.apply(FastImageViewConverter.getOptions(source)) to
.apply(FastImageViewConverter.getOptions(source).override(600, 400) )
And on performance was night and day. I was testing feed feature with a lot of images, and it was crashing on the first "page" on Galaxy S6 edge.  After changing single line as described above, not only that it wasn't crashing anymore, but I could scroll like crazy and everything was working 👌
So I really think your PR should get pulled. 🤞
In the mean time, switching from FastImage to regular Image  also fixed issue (but performance wise solution described above was better). My image component looks like this now:
 <Image
            style={style.media}
            source={{ uri: backgroundImage }}
            source={{ uri: backgroundImage, cache: "force-cache" }}
            resizeMode={"cover"}
            resizeMethod={"resize"} // <-------  this helped a lot as OP said
            progressiveRenderingEnabled={true} <---- as well as this
          />

@mralj your solution work for me, thanks, But could you please tell me why did you define source twice ?

@andru1989 that is a mistake and the second declaration will overwrite the first.

@andru1989 that is a mistake and the second declaration will overwrite the first.

@andru1989  @allthetime Is correct, I have mistakenly left this line.
Also please accept my apologies for not replying, I have completely missed notification :/


Use INVALID_CREDENTIALS instead of INVALID_PASSWORD error

I want to merge this change because...
We introduce AccountErrorCode.INVALID_CREDENTIALS which is less restrictive and can be used in any field.

fixes #5467
Impact

[ ] New migrations
[ ] New/Updated API fields or mutations
[ ] Deprecated API fields or mutations
[ ] Removed API types, fields, or mutations

Pull Request Checklist

[ ] Privileged queries and mutations are guarded by proper permission checks
[ ] Database queries are optimized and the number of queries is constant
[ ] Database migration files are up to date
[ ] The changes are tested
[ ] GraphQL schema and type definitions are up to date
[ ] Changes are mentioned in the changelog

@koradon Can we drop INVALID_PASSWORD then? I think it won't be used anymore.

@maarcingebala I believe so. Should we depreciate it somehow before droping?

@koradon Actually it is used in saleor-dashboard now so we would have to first migrate to INVALID_CREDENTIALS there to remove this from the core. I'm not sure if we can deprecate enum values, if yes that we should do that. So let's not remove it yet and open an issue in saleor-dashboard to migrate to the new enum value.

@maarcingebala done https://github.com/mirumee/saleor-dashboard/issues/483


Use of default SlotConfig in awaitTime of PAB ContractInstance requestHandler

Summary
The use of the default SlotConfig in awaitTime function defined in Plutus.PAB.Core.ContractInstance.STM may impact script validation when running PAB with a private testnet such that, the beginning of slot zero and the slot length may not correspond to the default public testnet configuration. Indeed, pscSlotConfig specified in the nodeServerConfig must be considered instead.
Steps to reproduce the behavior

Define an endpoint calling awaitTime 0 and perform a tell on the result
Invoke the endpoint with a PAB context running a fresh instance of a local testnet
Check the observable state of the corresponding contract instance.

Actual Result
The produced POSIXTime will differ from the local testnet slotconfig.
Expected Result
The produced POSIXTime should be in conformity with the local testnet slotconfig.
Describe the approach you would take to fix this
Any BlockchainEvent request to a contract instance must be parameterized with the node configuration.
A current workaround is to explicitly pass the slotConfig to the invoked endpoint and replicate what awaitTime does.
System info
plutus commit : 51da951ee2a7b8f05bde624bc9da4ce9a1f81ea1

FYI: Here is the approach the Marlowe team has temporarily taken to work around the POSIXTime issues: https://github.com/input-output-hk/plutus-apps/commit/0a19f754c4799c13f0177ae54aebd6d1770a197e.

Yes that's the main idea, but instead of using a global reference, I've implemented a wrapper function that passes the node parameters (e.g., protocol parameters, slotConfig and networkId) to each invoked endpoints. This allows to have customized libs without disruption anything.

Thanks for reporting!


Workflow View: Collapse / Expand all

Summary
A collapse and expand all button for workflow states would make it easier to work with workflows.

https://github.com/direktiv/direktiv-ui/commit/8804127ee38c7234458e67394e5bf7bd44a13640


Fragments

At least the fragment of type NEWS is not working, when activated through the JSON API.

Fixed in efcc88fee055fbdee35be9663efbe79bab601717


Deny missing docs

Diesel should have a thoroughly documented API, and I'd like it to compile with #[deny(missing_docs)]. Even harder, I'd like it to have an example for each major¹ public item.
Here's a list² of the items that currently miss documentation: https://gist.github.com/killercup/baf6975ea40d70cd278823a6af9bc05d

¹ definition of 'major public item' pending 😄
² generated with
cargo +nightly rustc --features 'postgres sqlite chrono unstable' \
  -- -D missing_docs --error-format json 2>&1 | \
  grep '^{' | \
  rq -jH 'filter [level, error] |
    flatMap spans |
    map (s) => { {file: `${s.file_name}:${s.line_start}`, text: s.text[0].text.trim()} } |
    uniqBy file |
    map (x) => { `${x.file} ${x.text}` }'

first commit in Rust

Wow, that's amazing, @mattjmcnaughton!
Adding the deny itself will just make it not compile any more until all items in that list have doc comments. So we'll have to wait a bit before we can add this. :) Locally, you could also use #[warn(missing_docs)] to let the compiler give you a warning for all the undocumented public items in the code base (basically my list).
That's a lot of items to write documentation for, so I it makes sense to have a lot of smaller PRs adding docs for singular modules or traits.
Oh, and I totally forgot to link to these guidelines to keep the doc comment style consistent. (Not that I want each doc comment as extensive as the examples in there, though! Please let me know if you have suggestions to improve these guidelines.)

Were you also envisioning this diff fixing all of those items missing documentation as well?

Definitely don't submit one PR fixing all of the documented items. One PR per file is about the right size. We can't accept a PR that adds #![deny(missing_docs)] until after the documented items are fixed.

Sounds like a plan (and thank you for the quick response)! As I understand the code, and as I get the change, I'll make some separate prs with the documentation changes, and when the documented items are fixed, I'll make a pr that adds #![deny(missing_docs)].

Exactly. And thank you!
Since there are a lot of items to document, this does not need to (and
probably should not) be a one person job. If more people want to help, I'll
add a check list here to track what has already been documented.
If you have any questions regarding the code or the API to document, feel
free to drop by our Gitter room :)
Matt McNaughton<EMAIL_ADDRESS>schrieb am Sa. 7. Jan. 2017 um
03:41:

Sounds like a plan (and thank you for the quick response)! As I understand
the code, and as I get the change, I'll make some separate prs with the
documentation changes, and when the documented items are fixed, I'll make a
pr that adds #![deny(missing_docs)].
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/diesel-rs/diesel/issues/563#issuecomment-271057314,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABOXxNUaUBr9jJUyekDKsLrBQW5Yvd7ks5rPvt1gaJpZM4LYwv1
.

I'm new to Rust, but I'd be happy to help with this.

I just added a few more details on how contribute to the issue description: https://github.com/diesel-rs/diesel/issues/563#issue-198278768

@killercup - Thank you for that.
@mattjmcnaughton - FWIW, I think that I'll start with just CONTRIBUTING.md and README.md files before trying anything more in-depth myself.

Just to say that I am not going to be able to work on this, unfortunately (too many projects, something has to give).

Sent a very simple (and probably wrong) PR #592

Thank you! Every small contribution counts! Don't worry if it's not perfect
at your first try; that's what code review is for! We'll get there together
:)
Erich Cordoba<EMAIL_ADDRESS>schrieb am Do. 26. Jan. 2017 um
07:36:

Sent a very simple (and probably wrong) PR #592
https://github.com/diesel-rs/diesel/pull/592
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/diesel-rs/diesel/issues/563#issuecomment-275317797,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABOX1kJnAqU8PzmyYqmzlwtx_3sNFEtks5rWD7sgaJpZM4LYwv1
.

Y'all need to review my open PRs so I can close this. ;P


cmd/go: drop support for binary-only packages

Binary-only packages are increasingly hard to support safely. There is no guarantee that the compilation of the binary-only package used the same versions of the dependencies that the final link does (and it would probably be too onerous to insist on that). As a result, the binary-only package may have been compiled using escape analysis results or inline function bodies for dependencies that are no longer accurate. The result can be silent memory corruption.
My memory is that we added binary-only packages originally so that a professor could hand out binary solution sets so that a student who didn't finish lab 2 could still move on to lab 3. I don't know why else anyone uses them anymore, but they're probably going to break more and more as the compiler gets more sophisticated.
Should we just remove them? If not, why not? What do people need them for?
See also #28146 (less severe).
/cc @bcmills

I'd like to see them removed, mostly for code simplicity.
For the professor use case, perhaps source obfuscation of some form would be sufficient.

Looking for people who use binary-only-package and might be able to explain what they use it for.
@ianlancetaylor filed #23473 (but presumably passing along another report).
@triztian filed #26590.
@hilyjiang filed #24318.
@motomux filed #26875.
@joshlf filed #16841.
@jerrybean filed #21451.
/cc @dneil @dsnet for knowledge of any potential Google-internal usage.

I'm not aware of anyone using binary-only packages inside Google. Doesn't mean someone isn't, of course.

I'm in favor of the proposal, nonetheless I guess the important property of binary packages is they make some closed source package vendors feel "safe" about their IP.

That or plugins need to not panic (when loading) and complain about different versions of the same package and also offer unloading support (i.e: find a way to severe the link with the runtime and free evreything).
Vendoring binary packages is useful if you're selling an SDK or toolkit.

Hi there, thank you for considering us!,
In our case we use it as part of our offering to Enterprise customers. Being able to provide non-source distributions and as a way to hide some of our I.P clears us with the IT departments of such companies.
Our biggest use is being able to provide a static library (the BOP package) to third parties without providing our source, we provide an SDK that should work without any connection to our Servers, hence we package the SDK as binary-only-package that includes some proprietary I.P. that is licensed.
While that approach is not the most secure way to protect our source, it is the right balance right now, we just don't include more sensitive functionality in what we distribute.
Another important characteristic is that being able to have a higher level of friction of preventing modification to what we distribute; i.e. even if we provide non-IP that has to function in a specific way, not having BOP's would make easier for third parties to modify the SDK.
I'm not entirely in favor of dropping support for binary-only-packages because I believe that many other languages support a way of distributing packages that don't have the original source in them:

Java/Android - Jar/aar files
Swift - Frameworks
C/C++ - static libs + headers

#23473 was for an internal Google use case (internal reference number 72160357) that was resolved by changing to not use binary packages.

Posted to golang-nuts to cast a wider net for use cases.
https://groups.google.com/d/msg/golang-nuts/juPzaRDVB9c/6PYP56-0CAAJ

In general I'm in favour of giving incentive to provide source.  But there are legitimate binary-only cases related to not only IP but security.
What relationship would removing support for BOPs this have to plugins and related build modes (shared/c-shared/c-archive)? Could one still provide a binary in any of these forms and be able to use that?  If so, then a simple solution for at least some BOP use cases would be to use a wrapper package that loads a plugin, or uses -linkshared or a c-archive via cgo  and the plugin or c-archive would be outside of go get/modules and distributed separately as binary.
I have no plans to distribute such things, but would like to be able offer the capacity to others in some form.  If something like the above workarounds worked, then that would provide a way to drop BOP
support and say "use workaround ..." for those who want it.
At the same time I understand there are still some issues with these other binary distribution mechanisms and modules.

Thanks for asking about plugins. There are no plans to remove plugin support, and suggesting the use of plugins as binary blobs instead of binary-only packages makes sense to me. Plugins have many of the same concerns, but they already have a proper check for mismatched API (avoiding the silent memory corruption problem) and it's always better to have one mechanism than two.

Are there any performance concerns for plugins? E.g., I would imagine that you can certain link-time optimizations with binary-only packages that aren't available for dynamically loaded code?

I agree that binary-only-packages are problematic and should be removed.
I tried to use plugins but you can't unload them.
I decided to live with that and restart the process in case the plugin had to be reloaded but then:
You can't load a plugin if you vendor your dependencies and one of this dependency is shared with the host.
Right now I'm using go tools (compile and link) and reuse the .a but that's kinda ugly

@joshlf It's hard for me to imagine any real case in which plugins are noticeably less efficient than binary-only packages.  It's possible to construct an artificial case, but I doubt that would match any real implementation.

Thanks for asking about plugins. There are no plans to remove plugin support, and suggesting the use of plugins as binary blobs instead of binary-only packages makes sense to me. Plugins have many of the same concerns, but they already have a proper check for mismatched API (avoiding the silent memory corruption problem) and it's always better to have one mechanism than two.

Great to hear.  It seems to me it wouldn't be too much to adapt the source stubs from a BOP to wrap a plugin and an init() to load it from somewhere, and well worth it to both BOP users and Go maintenance.

Will leave this open for another week but it sounds like we can retire binary-only packages in favor of using plugins. We could advertise in the Go 1.12 release notes that it will be the last release to support binary-only packages and they will be removed in Go 1.13.

Accepted since we waited a week and nothing came up/no objections were raised.
Per discussion with @golang/proposal-review

As a corporate programmer, the closed-source use case is very important.  A language that is so RMS idealism friendly that it doesn't even allow one to use closed-source dependencies is a very hard sell in many corporate environments.

@edburns see the discussion above; using compiled binaries will still be possible via plugins. binary-only packages are harder to develop, maintain, and use, as can be seen above.
The later stages of this thread were about finding any reason why plugins aren't a good replacement for binary-only packages, to which there wasn't a clear answer.

@edburns Thanks for the comment.  Do you have direct experience of this?  How do those corporate environments handle languages like Python or Javascript?

Consider the case when a corporation is using a licensed closed-source software package as a dependency on an internal project.  Right now, if the vendor of a closed-source package wanted to make their licensed package useful to go programmers, their only option is to author it as a plugin.  As stated elsewhere, this has drawbacks: complexity of .so linking, lack of non Linux support, etc.

make their licensed package useful to go programmers

I'd argue that using a binary-only package was never really an option. The binary would require an exact version of Go, as well as an exact version of all the packages it depends on. It's certainly possible, but I wouldn't say it's ever been a good or easy way to distribute software. The intended purpose, the professor scenario, is a much more restricted use case.

complexity of .so linking

Please expand on this. If you believe there's a bug or something to improve in the plugin package or the go tool, you should open a separate issue.

lack of non Linux support

What particular platform is noticeably missing plugin support? Assuming you mean Windows, that's being tracked in #19282. I believe effort would be better invested in issues like that one, instead of on maintaining binary-only package support.

@edburns Thanks.  Personally I am more interested in direct experience than in hypotheticals.  We can construct a number of hypothetical situations, but in the end they won't tell us what to do.

It is possible to use vendoring with plugins (without set package import path)? The use of multiple plugins is hard because they need to use exactly the same version of common dependencies. Would it be possible to use the latest minor version for each dependency otherwise?

I have one file in /root/work/go/src/say named say.go
package say
import "fmt"
func Say(s string) string {
return fmt.Sprintf("hello %s", s)
}

I try to build it to .a file go build -i -o $GOPATH/pkg/linux_amd64/say.a

change /root/work/go/src/say/say.go to

//go:binary-only-package
package say

another file /root/work/go/src/say/work/v1.go
package v1
import (
"fmt"
"say"
)
func SayToBob() {
fmt.Println(say.Say("Bob"))
}

the main file /root/work/go/src/say/work/main.go
package main
import (
"say/work/v1"
)
func main() {
v1.SayToBob()
}

run main.go go run /root/work/go/src/say/work/main.go
go run main.go
hello Bob
that's right

7.but in fact, i need to build SayToBob as plugin to hot reload,run
go build -buildmode=plugin -o /root/work/go/src/say/work/v1/plugin.so /root/work/go/src/say/work/v1/v1.go
missing or invalid package binary for binary-only package say

@twyvip, how does your comment relate to this proposal?

FWIW, I have a "convenience" use case for binary-only packages: cross compiled cgo packages that are inconvenient to compile on the host because everybody would have to install the relevant C cross compiler (for the target).
Concrete case: I am starting to write a go wrapper for the librobotcontrol C library for the beaglebone blue.
That C library makes no sense on the host (be it windows, mac or linux).
AFAIK to cross compile the wrapper I'd need to copy the relevant header files and libraries on the host, and also provide cgo a C cross compiler.
I was strongly considering building the wrapper natively on the beaglebone (very easy to do), and just redistribute the compiled object file so that users do not need to set up the cgo cross compilation environment.
In this case "users" would be a group of 15 years old highschool students I am mentoring for a school-related robotics project.
Anyway I can probably do this cgo wrapper as a plugin, with a bit of boilerplate code to export a type safe interface to the wrapped functions.
Do you still think to deprecate binary-only packages?
If yes I'll go the plugin way, since that would be the only supported option in the future.

@massimiliano-mantione, a plugin sounds like the right approach for your use-case.

@massimiliano-mantione Another approach you can use is .syso files.  Compile all the C code into a single object file per support platform, and name it something like c_GOOS_GOARCH.syso.  Then the Go code can be the same as always, and can use cgo to call into the C code provided as a .syso file.

Using plugin is total different with binary-only packages.
The good case is i want to protect framework source code like beego there is noway to archive the samething with plugin, it's paintful to archive the goal.
Imagine your code since:
import (
	"framework"
	"framework/config"
	"framework/server/middleware"
	"framework/util"
)

framework.Abc()
util.Xyz()
config.Read()

turns to this for using some simple shared methods
all_plugins, err := filepath.Glob("frameworks/*.so")
if err != nil {
    panic(err)
}

for _, filename := range (all_plugins) {
    p, err := plugin.Open(filename)
    if err != nil {
        panic(err)
    }

    symbol, err := p.Lookup("Sort")
    if err != nil {
        panic(err)
    }

    sortFunc, ok = symbol.(func([]int) *[]int)
    if !ok {
        panic("Plugin has no 'Sort([]int) []int' function")
    }

    sorted := sortFunc(numbers)
    fmt.Println(filename, sorted)
}

Your code will be 100 times longer !!!

@aaveidt I'd argue if protecting your IP is that important to you, why wouldn't you maintain a proxy package to include the boilerplate required to load your plugin on behalf of your customers?
If the IP is locked up inside the precompiled plugin, it doesn't seem like providing your customers easy to use interfaces should be that much trouble.

@gen0cide i'm not argue about plugin isn't capable to protect my IP.
I'm telling you that using plugin and binary package are like comparing an axe and a knife.
Both can be used for chopping tree but would you use a knife for it?
It takes so much time to convert one framework to a plugin.
And we have to check for each symbol in each plugin, redeclare interfaces and types ... Plugin is suitable for using one/few package(s) or CLI app not a whole framework.
[quote]Plugins have many of the same concerns, but they already have a proper check for mismatched API (avoiding the silent memory corruption problem) and it's always better to have one mechanism than two.[/quote]
@rsc taking away an axe and left the knife is the drawback, you should remake or sharpen an axe.

This change will disrupt my distribution pipeline beyond belief.
Distributing binary packages is crucial to any commercial SDK-style use case and insisting on using plugins is going to force a JNI-like wrapper, abstracting structs and more.
Plugins are, by their very nature, supposed to be entirely self contained with few exports. SDKs are by nature not and are supposed to heavily integrate with application logic throughout. Forcing these to effectively use reflection and a generated proxy layer is absurd.
Why not just integrate binary-only builds with go modules? Just include the go.mod file in the zip and assert that the versions are the same? It can't be more than a 20 minute job.
Failing that, why not distribute all the specific version dependencies as binaries? And allow multiple packages to exist within one compiled zip build.
There's so many possible solutions. Jumping to "get rid of it and don't replace it" is absurd, and is the kind of executive decision that will lead to diverging forks.
Suggesting that this feature only has uses in education is like suggesting that JAR files are only used by people using Guava. It's silly.
Nobody has objected yet because most people don't pay attention to the issue tracker. The first I'm hearing about this is in 1.12 changelog.

@fabian-f This was discussed on the golang-nuts mailing list, as mentioned above.  We tried to raise awareness of this issue.
Note that binary packages continue to work.  What will stop working in the 1.13 release is binary-only packages.  That is, you can distribute a package binary, but you also need to distribute source that tools can use to rebuild when appropriate.  Can you describe your requirement for binary-only packages?  Because right now they don't really work.

@ianlancetaylor I distribute an SDK which runs as a server (started by the clients main package) and allows clients to hook events and interact with exported methods and struct fields.
Binary-only packages are used so that my licensing model can work since the SDK itself runs independently, and distributing source would allow clients to continue using the SDK indefinitely with slight modification.
I haven't noticed any issues functionality wise.

@fabian-f please show an example of an application which can use binary-only packages, but not plugins. This thread is getting more and more critical replies, but none have explicitly said why they can't use plugins, as best as I can tell.
Yes, plugins require a bit more boilerplate, but that's also why they're much easier to support and maintain in the toolchain. Like previous comments in the thread explain, binary-only packages are vastly more complex, so it makes little sense to keep supporting them when we have plugins.

@mvdan I will put the concept I described into code a bit later.
The thing isn't that plugins "can't" be used, it's just that it's a performance hit. To get full functionality you need to use reflection far too much and it turns trivial code into really complex code. (Create a struct and set a field for example).
Maybe the plugin system could, one day, be a swap in replacement - if they're changed to be "real go" instead of reflection.

@mvdan the examples are above, don't know what you ask for.
Using plugin isn't only a bit more boilerplate, code shown above too.
Its 100 times longer

@mvdan
Consider the following:
`//go:binary-only-package
package test_binary
import "log"
type HelloRequest struct {
Name string
}
func SayHello(req HelloRequest) {
log.Println("Hello,", req.Name)
}`
Accessing this via binary-only packages is seamless
test_binary.SayHello(test_binary.HelloRequest{Name: "Fabian"})
By contrast, I don't even know if this can be done in plugins without first creating a factory method for HelloRequest?
I can't test it since I'm on Windows, which plugins don't support.

I don't know if this matter anymore at all, but we planned an entire year of development for a commercial SDK which was entirely protected by the binary only package. We got two customers using the beta (and paying for using it) and now we are basically forced to abandon a project which cost us in excess of 120K so far (cost, not revenue opportunity).
The plugin option is not even remotely attainable (as other as observed).
I wonder how those features get deprecated, that's why this year we are sticking with the standards (C, C++) which are backed by stronger governance.

Thanks for the input.  We'll consider it.
The main reason for deprecating this feature is as outlined above: it does not work reliably.

Is it true that Go can't distribute lib without source code? If then, please write it on first page of golang.org not to start golang. I think it's non-sense not supporting binary lib distribution.

I'm in a similar, albeit of lower magnitude, situation to @cpipero.
@ianlancetaylor I totally get the need to burn a bad code base to the ground, but there needs to be a suitable drop-in (or close to) replacement that A) has the same functionality and B) works in a similar way.
Whilst plugins provide, on an abstract level, similar functionality, they are lacking completely when it comes to type definitions. It's just not there at all. Then there's the objectively horrible syntax which is just begging to be generated (which is a possible but not ideal workaround).

Would the "plugin" package eventually be able to at least support loading structs declared in the plugin. I think that would further make plugins a replacement for binary-only-packages

We looked at plugin and it's not so practical for our use.
You need to call plugin.Lookup("FooType") and then cast the result to FooType to be able to construct a  type.  We've got a lot of types (we are selling an SDK).
Again, it's all in the economics: this issue is costing us a lot...

Today, I studied plugin.
I think plugin concept is very similar to swig.
All sharing types should be treated as interface.
func main() {
shared.LoadGreetingPlugin("plugin/hello.so")
greeter1 := shared.NewGreeting("test1")
greeter2 := shared.NewGreeting("test2")
greeter2.SetName("test3")
greeter1.SayHello()
greeter2.SayHello()
}
plugin_test source
In my case, plugin will be a good option for replacing binary-only-package.

In my case, plugin will be a good option for replacing binary-only-package.

@yslim Have you used binary-only package? Its 100 times shorter.
https://github.com/yslim/go_plugin_test/blob/master/shared/greeting.go
Your main.go and shared/greating.go files have 45-50 lines of code to call only 1 SayHello() method.
Using binary-only package only costs 4
package main
import hello
greeter := hello.NewGreeting("test1")
greeter.SayHello()

Then i can call any exported methods effortlessly without writing any line of code: greeter.A() , greeter.B() ...
What would you do with plugin, you have to redeclare each of them in your Greeting interface.
One framework or big package can have hundred types, and exported methods.
Try to port any package like gin, chi, gorm, beego to plugins to see the difference.
Using plugin isn't practical at all.

I completely disagree with your position @aaveidt and @fabian-f for a number of reasons.
You're continuing to assert that binary-only packages are the only option because they allow your users easy access to code that you write, but that you will not share with them. Where I struggle to sympathize is in that you're doing this exclusively for Go packages. This isn't for c-shared libraries that have symbols exported and documented. You're asking Go developers to implement your binaries under the following conditions:

No access to the underlying source code.  Not a day goes by that I don't click through an Anchor into code in Godoc. And I think that's a paradigm that has made Go successful - it has the best documentation story of any language.

Very poor compatibility. As has been noted by many issues here, I'd be extremely upset as a developer if my vendor continues to provide me libraries that suffer from inconsistent, buggy behavior.

What I'm getting at is that while it is 100% your choice to decide that theoretical intellectual property protection is more important than your developers experience, I do not understand how somehow removing BOPs when Go has provided you with a much more stable Plugin system[1].
Your biggest complaints about the Plugin system relate to "effort". It definitely will require some work to evolve your codebases to comply with the new supported standards, but repeatedly arguments have been made about how this would be an undue burden on your users.  If you valued their experience above all else, writing some go/ast, go/parser and go/printer code to programmatically generate intermediate plugin interfaces that you could share with users doesn't seem like too much to ask.
Especially when the result will be more stability, better documentation and usability, and easier forward compatibility. I support @ianlancetaylor and @rsc on the job done. As much as they value API stability and compatibility, this is the type of deadweight that drives poor developer experiences in the ecosystem. They recognized it and it's time for it to deprecate into the past.
[1] I realize that right now that Go doesn't have Plugin support for Windows. But so far, a significant amount of push back has been from people talking about "web frameworks" which overwhelmingly are developed and deployed on Linux.

@gen0cide thank you for the valid points, which speak to ultimate stability and developer well-being.
Our problem is more of a practical nature, where a known feature was the base for us to lay out a legal and commercial framework for the distribution of a product.
That framework ceased to exist once no equivalent feature could be provided by us to our customer.
Again, I did not pay for golang development so I am not going to blame the ultimate decision. I just voiced the reason why I would vote for keeping a feature that works for us without any issue, understanding the risks but not having a whole lot of choices given the significant investment.
You say that writing a go/ast, go/parser, etc. is no big ask. In our case, we would probably refactor our entire API into a language that 1) supports the legal agreements in place (for us and our users), and 2) eliminates the risk of similar decisions by enforcing a more formal ISO/IEC process to make changes.
And in doing that (or if I were to follow your advice) it means to come up with a lot of money (of course, that subjective but for me anything more than 20K is a big ask).
Therefore, the point here is how to deal with existing SLA's.
With all that said, all I can do was to relate a real world scenario.
Thanks again for the advice.

@gen0cide Writing some AST magic to generate a proxy layer is no big ask. I've already started it in anticipation of this change. The problem is plugins aren't ready to act as a replacement yet. They're only supported on Linux and Mac (3 of my larger clients have to deploy to Windows), and don't support struct type definitions. I don't get why a handful of people are so eager to deprecate this feature without a single full replacement.

@fabian-f I want to express again that, as we've said, the reason to deprecate binary-only packages is that they are not reliable.  If accidentally misused, they can lead to silent memory corruption during execution.  That is both unfortunate and difficult to fix.

Let me add that I do understand that you have a use case for binary packages.  Months ago @rsc asked for people to give examples of use cases that were not supported by plugins.  Only in the last few days have they come forward.  I understand that not everybody can track the Go mailing lists.  Now that a couple of use cases have come forward, we will re-evaluate the decision and see if we can find a way to move forward.  If anybody wants to address the technical issues that make binary packages difficult to support, that would be very helpful.

Again,
I’m very grateful for the consideration
On Feb 27, 2019, at 8:59 AM, Ian Lance Taylor <notifications<EMAIL_ADDRESS>wrote:
Let me add that I do understand that you have a use case for binary packages. Months ago @rschttps://github.com/rsc asked for people to give examples of use cases that were not supported by plugins. Only in the last few days have they come forward. I understand that not everybody can track the Go mailing lists. Now that a couple of use cases have come forward, we will re-evaluate the decision and see if we can find a way to move forward. If anybody wants to address the technical issues that make binary packages difficult to support, that would be very helpful.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/golang/go/issues/28152#issuecomment-467870845, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABwUt_2UEnzR7fdXDkuXgXEKN0xNoWqCks5vRo8qgaJpZM4XXyuW.

@cpipero and @aaveidt, from a "code hiding" point of view, the compiled .a file has a lot of source information embedded in it. A LOT. It might be equally practically effective just to run a code obfuscator on your code and distribute source. Perhaps much better, since it would hide more of the internal names.
If such a code obfuscator tool existed, would that work as a replacement for binary-only packages for you?

If such a code obfuscator tool existed, would that work as a replacement for binary-only packages for you?

I don't know about the current cases, but the malware community would be very happy with such a tool to make reverse engineers' tasks slightly more difficult. cf. https://blog.malwarebytes.com/threat-analysis/2019/02/new-golang-brute-forcer-discovered-amid-rise-e-commerce-attacks/

We ran that option to the customers (two) and both legal teams came back with “no”.
On Feb 27, 2019, at 2:53 PM, mirtchovski <notifications<EMAIL_ADDRESS>wrote:
If such a code obfuscator tool existed, would that work as a replacement for binary-only packages for you?
I don't know about the current cases, but the malware community would be very happy with such a tool to make reverse engineers' tasks slightly more difficult. cf. https://blog.malwarebytes.com/threat-analysis/2019/02/new-golang-brute-forcer-discovered-amid-rise-e-commerce-attacks/
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/golang/go/issues/28152#issuecomment-468005459, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABwUtxNqITLOdHZt5-6U23TDQ_as8-jcks5vRuI_gaJpZM4XXyuW.

@cpipero, you might need to help explain things to your legal team, then. You can't expect them to know how all (or any) compilers work.

@rsc, I'm supportive of exploration of Go obfuscation in general, but curious if it isn't trending a more broadly applicable solution near @fabian-f and @cpipero's comments regarding auto-generation of plugin scaffolding.
I spent years reverse engineering obfuscators for MMORPGs who used a wide variety of Java obfuscators, open source and commercial alike. Bytecode is easily represented in source - so in effect, even the best Java obfuscator is basically what you're proposing - a source obfuscator. Reversing these obfuscation techniques were common practice by myself and other teenagers. Also, at the end of the day, much of the obfuscation techniques that work well will deminish the optimizations of the compiler from doing, as well as negatively effect performance of the compiled binary. This is now how most enterprise mobile obfuscators work today.
Nowadays, I work in information security and actively research and develop techniques of binary obfuscation using Go. I've spent a lot o time leveraging the power of go/ast and go/parser to this end. I love the theory of a richly featured obfuscation utility, but having gone down that road, I would anticipate supporting such a utility would be more cost than the benefits in this particular issue. Basically, this boils down to the fact that to really check the boxes for anti-introspection, anti-tampering, and preventing reverse engineering (especially in a situation where you're distributing obfuscated source), you'd need to write rules governing the re-implementation of every ast.Node in the tree. Note that to be effective, you'd need a wide library of these rules to look at not just individual nodes, but parent nodes and reference calling. Then, the obfuscator must randomly (or keyed with an secret IV) select strategies at every level, wrapping, rinsing, and repeating. This "code mixing" is all for not if the reverse engineer can simply document your re-write rules to perform the inverse on identified nodes.
I still believe the stability of the language ecosystem and compiler requires BOPs to be deprecated, but I do think there is room to innovate something on behalf of those who have use cases. How do you feel @rsc and @ianlancetaylor about the concepts of some sort of plugin scaffolding generator? I don't know where this lives, but I see the feature working something like this:

DeveloperA develops a plugin using currently recommended practices.
DeveloperA marks through a comment //plugin:export the types and functions they wish to expose.
DeveloperA runs builds the plugin but with an additional -export flag. The compiler produces 2 files - plugin.so (the compiled plugin), and plugin_export.go.

What happened? The compiler walked the AST looking for plugin exports, then generated a scaffolded export that implements those exported types and function calls using a standardized entrypoint. This go code, along with the plugin, could then be distributed to developers.
Thoughts?

Not my legal team: the customer’s.
You base your project on a set of documented features that keep all their IP concerns at bay. Then you go to them one year later saying “we can do two out three but we can’t keep the code in binary form as previously stated “.
Believe me, at those companies the last thing you want to do is to school their lawyers on computer science.
But we are getting off track. I don’t think people who are pushing back are questioning the technical reason for the decision. More than anything we are hoping for a more structured approach to change. And I have seen a few good ideas in the last hour or so.
Success is often a compromise
On Feb 27, 2019, at 3:15 PM, Brad Fitzpatrick <notifications<EMAIL_ADDRESS>wrote:
@cpiperohttps://github.com/cpipero, you might need to help explain things to your legal team, then. You can't expect them to know how all (or any) compilers work.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/golang/go/issues/28152#issuecomment-468013039, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABwUt1djKESR4JKOt4xDAAEEiXhGlhKzks5vRudogaJpZM4XXyuW.

If such a code obfuscator tool existed, would that work as a replacement for binary-only packages for you?

I don't know about the current cases, but the malware community would be very happy with such a tool to make reverse engineers' tasks slightly more difficult. cf. https://blog.malwarebytes.com/threat-analysis/2019/02/new-golang-brute-forcer-discovered-amid-rise-e-commerce-attacks/

I would encourage you to try and separate the deficiencies of the security industry from the needs of software engineering as a whole. The information security industry is a billion dollar industry that by in large, is filled with vaporware. The cognitive dissidence is on full display when technology is discouraged due to "what it will mean in the hands of hackers". This same mindset fueled anti-encryption sentiment in the 80s and 90s, and continues today around the need to invade user privacy more and more.
Hackers do not need this hypothetical obfuscator to lay waste to even the most sophisticated anti-malware systems. Those system's are ineffective, not because the hackers have magic tools, but because they are attempting to solve a non-sequiter. They have to be flexible enough to not cause false positive detection/prevention, but also detect nefarious behavior. Since the possible permutations of this is different not just from company to company, but from employee to employee, and even day to day per employee, heuristics based detection will never be the primary defensive strategy.
Good security is about empowering the user to be inherently secure. Go does a great job of this in their x/crypto/ssh package, as well as attempting to make certificate validation default in net/http.
Sorry for the long position, but as a security professional and an avid Go user, I've got an interest in not letting security theater discourage innovation.

@gen0cide I believe this code generator idea to be a good workaround, and was my plan for when this change goes ahead anyway. It being part of Go's core tools would definitely soften the impact of losing BOPs. However, plugins need to work on all main platforms before they can ever be considered an alternative.
Also aside from trimpath is there any more complete ways to remove source information from the compiled binary?

I think we should focus on the technical arguments against adopting plugins. So far, it seems like the only missing critical features in plugins are Windows support and the ability to expose type definitions. Is that correct?
If so, perhaps we should move the discussion towards looking at those issues, and perhaps even blocking this proposal until they've been considered.
I don't think verbosity is nearly as important as the other issues, nor do I think it's a stopgap. Having to write an extra 50 lines is certainly not ideal, but there are many factors at play here. Perhaps Go2 type parameters would allow getting rid of some of the reflect boilerplate.

@mvdan I agree. Plugins combined with a command line tool could replace BOPs, if plugins have the OS limitation fixed, support type definitions, and provide an option to export constant values (although the command line tool could simply copy constant definitions to the shared code).
All of the boilerplate code is so generic that it could be generated.

I'm not terribly worried about the "malware community" one way or another. In the page you linked, the binary hadn't even been stripped.

The fact is binary-only packages do not work with Go 1.12 except in limited circumstances. (And I understand that some people are working within those limited circumstances successfully, if luckily.) In Go 1.13 they won't work at all. The limited cases that do work in Go 1.12 will continue to work in Go 1.12 - we aren't going to retroactively remove them from Go 1.12. People who need extra time to move to what's next can keep using Go 1.12 as long as they like, of course.
It seems like there are two paths forward. First, people could work on an obfuscator of sorts. Second, people could work on improving plugin support.

@rsc Why not wait until plugins are at a sensible point before deprecating a solution that does work?

@fabian-f The unfortunate fact is that it doesn't work today, as described earlier.  And it's going to break even worse with future changes such as module support.

@ianlancetaylor But you've heard from 3 different people who have clients who successfully use them in a production environment, so it does work, today.

@fabian-f There are several options that the client could pass to go build or go install that will break the build with binary-only packages.  So, yes, it works in limited circumstances.

Reading through all of these comments, it seems the question has evolved to "Can plugins replace binary-only packages?" and "What is needed to make binary-only packages viable?" Given that I am hoping my comments are off-topic, but if they are please forgive me and feel free to mark the comment as off-topic like one of the ones above.
We are not actually using binary-only packages but very recently explored using plugins to allow a 3rd party extension mechanism for a product we are building that would be marketed to people who are not-Go developers. IOW, we are looking for an extensibility mechanism that would allow 3rd parties to build and deliver binary "add-ons" for our product to our mutual customers.  Unfortunately we found plugins lacking, for two reasons:

They do not work for Windows (although I do understand that is supposed to be resolved.)

Plugins evidently require being built by the same version of the compiler that the main application is built using, and that unfortunately is a non-starter given we won't always be coordinating with 3rd party developers nor would we want to have to.

So, I understand that plugins possibly — by design — will always require version parity between the main app and the plugin(s).  But if that is the case then I think Go really needs a standardized extensibility mechanism that allows Go apps to load 3rd party extensions that were compiled with any compiler, maybe with communication over named pipes — can you do (something like) that in Windows? — or via protobuf over TCP/IP?
We can, of course, develop our own, but I think this really should be a widely applicable use-case — imaging 3rd party extension for Docker? — and I doubt our team and many others would have the expertise and experience to envision all the edge cases that might be experienced, so I am asking that the Go team consider creating a "blessed" standard library for extensibility that does not have the limitations that I understand plugins have.
That said, if I am misunderstanding anything about how plugins work, please forgive me for that as well.  I have only been actively coding in Go for less than 6 months.

I prefer not remove the feature, for protect some source code.

@shuxiao9058 Protect source code from what?

I thought this whole issue was closed and the decision was made to just drop the binary packages, and maybe, possibly, hopefully improve the plugins to replace with the same value proposition (that is, it solves a hairy business issue not a technical one -- and no, I cannot force legal teams to go through sufficient computer science training to change their ways).
I understand your motivation and support your decision.
We accepted this fact, but we also accepted the fact that basically the binary-only package option was a golang failure (among many successes of course).
Our solution was to go back to good old C++ because of their stricter governance that prevents failures like this to have such short term impact.
Of course, we will use and enjoy golang whenever the customer IP is not involved in the deliverable agreement.

I think a big difference between binary only packages and plugins are the structs themselves. With BOP you can hide package level details in the struct, when you move to plugins, you need to create public only structs and then copy and extend to the internal structs. This is a lot of work.


Merge timeout_prevote_delta & timeout_precommit_delta into a single timeout_vote_delta

timeout_prevote & timeout_precommit into a single timeout_vote

https://github.com/cometbft/cometbft/issues/2873#issuecomment-2100848781 looks like it's not advisable to do that as per @cason comment


[Hub Generated] Review request for Microsoft.Network to add version stable/2021-03-01

This is a PR generated at OpenAPI Hub. You can view your work branch via this link.
Changelog
Please ensure to add changelog with this PR by answering the following questions.

What's the purpose of the update?

[ ] new service onboarding
[x] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When you are targeting to deploy new service/feature to public regions? Please provide date, or month to public if date is not available yet.
When you expect to publish swagger? Please provide date, or month to public if date is not available yet.
If it's an update to existing version,  please select SDKs of specific language and CLIs that require refresh after swagger is published.

[ ] SDK of .NET (need service team to ensure code readiness)
[ ] SDK of Python
[ ] SDK of Java
[ ] SDK of Js
[ ] SDK of Go
[ ] PowerShell
[ ] CLI
[ ] Terraform
[x] No, no need to refresh for updates in this PR

Contribution checklist:

[x] I commit to follow the Breaking Change Policy of “no breaking changes
[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

[x] Ensure to check this box if one of the following scenarios meet updates in the PR, so that label “WaitForARMFeedback” will be added automatically to involve ARM API Review. Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs, all “removals” and “adding a new property” no more require ARM API review.

Adding new API(s)
Adding a new API version
Adding a new service

[x] Please ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[x] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If there are following updates in the PR, ensure to request an approval from API Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in stable version
[ ] Removing properties in stable version
[ ] Removing API version(s) in stable version
[ ] Updating API in stable version with Breaking Change Validation errors
[ ] Updating API(s) in preview over 1 year

Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.

Please review Linter errors. systemdata is needed.

Please review Linter errors. systemdata is needed.

Is something absolutely needed? I don't see any service under Microsoft.Network has ever has this attribute. It does not appear my change relates to this.

Please review Linter errors. systemdata is needed.

Is something absolutely needed? I don't see any service under Microsoft.Network has ever has this attribute. It does not appear my change relates to this.

Yes systemdata is a required property going forward. Please confirm if this work is planned and we can unblock this PR


A way to get results with highlighted content?

Hello @DomDew,
I wonder if there is a way to get results with highlighted content?
(like in https://github.com/farzher/fuzzysort#fuzzysorthighlightresult-openb-closeb)
Thanks!

Hey @maximelebreton ,
Sadly not at the moment, would be a cool feature though.
I sadly do not have too much time on my hands right now with work getting in the way.
Would you be up for making a PR that includes this feature? Would be awesome! 😄


Get this added to the celery core

<asksol> celery-redis-unixsocket I haven't heard about, what is it?
<ThiefMaster> https://github.com/piquadrat/celery-redis-unixsocket
<asksol> ok, I guess you could lobby the author to submit it as a pull request instead
<asksol> and I can add it or merge it into the existing redis backends

Hello @beniwohli .
It is added support for unix socker as a broker, but what about result backend? Will it work for result backend?
Will be appreciated for your answer.

Hi @DmytroLitvinov
Unfortunately, I no longer maintain or use this module (or celery), so I'm unsure about the status of using unix socket connections to Redis as a result backend.

Thank, @beniwohli .
Maybe you could help @blaze33 ?
Really need help about supporting unix socket for result backend.
I saw you added support for transport layer, but did not find any notes about result backend via socket.