fsaf_x101_64x4d_fpn_1x_coco.py: /coco.py", line 230, in _det2json  data['category_id'] = self.cat_ids[label]

Hello,
This only happens at the end of the training loop and stops training after the first epoch:

I tried both these solutions as suggested elsewhere:
pip install "git+https://github.com/cocodataset/cocoapi.git#subdirectory=PythonAPI"
pip install -U "git+https://github.com/open-mmlab/cocoapi.git#subdirectory=pycocotools"

Thanks ,

This only happens if I try to validate while training (e.g. --validate)

This only happens if I try to validate while training (e.g. --validate)

<EMAIL_ADDRESS>

This means that your results predict more labels and it is out of the range of the dataset's number of classes. This usually happens when you set the num_classes in the head greater than the real number of classes in the dataset.


fix(deps): update module dagger.io/dagger to v0.11.4

This PR contains the following updates:

Package
Change
Age
Adoption
Passing
Confidence

dagger.io/dagger
v0.11.0 -> v0.11.4

Release Notes

dagger/dagger-go-sdk (dagger.io/dagger)
v0.11.4
Compare Source
This SDK uses 🚙 Engine + 🚗 CLI version v0.11.4. See what changed in that release.
🐹<EMAIL_ADDRESS>Dependencies

Bump Engine to v0.11.4 by @github-actions in https://github.com/dagger/dagger/pull/7345

What to do next

Read the documentation
Join our Discord server
Follow us on Twitter

v0.11.3
Compare Source
This SDK uses 🚙 Engine + 🚗 CLI version v0.11.3. See what changed in that release.
🐹<EMAIL_ADDRESS>Fixed

Respect existing go.mod during module initialization by @jedevc in https://github.com/dagger/dagger/pull/7194

Dependencies

Bump Engine to v0.11.3 by @github-actions in https://github.com/dagger/dagger/pull/7318

What to do next

Read the documentation
Join our Discord server
Follow us on Twitter

v0.11.2
Compare Source
This SDK uses 🚙 Engine + 🚗 CLI version v0.11.2. See what changed in that release.
🐹<EMAIL_ADDRESS>Fixed

Allow windows CRLF line-endings in go pragmas by @jedevc in https://github.com/dagger/dagger/pull/7121

Dependencies

Bump Engine to v0.11.2 by @github-actions in https://github.com/dagger/dagger/pull/7204
Bump Dagger Modules go version to 1.22 by @jedevc in https://github.com/dagger/dagger/pull/7109

What to do next

Read the documentation
Join our Discord server
Follow us on Twitter

v0.11.1
Compare Source
This SDK uses 🚙 Engine + 🚗 CLI version v0.11.1. See what changed in that release.
🐹<EMAIL_ADDRESS>Fixed

Automatically add internal/telemetry directory to generated .gitignore files by @yann-soubeyrand in https://github.com/dagger/dagger/issues/7019

Dependencies

Bump Engine to v0.11.1 by @github-actions in https://github.com/dagger/dagger/pull/7100

What to do next

Read the documentation
Join our Discord server
Follow us on Twitter

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

:tada: This PR is included in version 5.3.10 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Deployment to ui.stampy.ai

Add github action for deployment to cloudflare worker - see README for instructions to update wrangler.toml with following public keys before running npm run deploy:

account: 841738ad455064a5846675cc41124c85
KV: 3efee496497048eca81d3f1b036d2631

..see e.g. https://github.com/marketplace/actions/deploy-to-cloudflare-workers-with-wrangler
Contact @Aprillion to generate the CF_API_TOKEN from @plexish's CF account.

I tried to use the wrangler-action workflow from Cloudflare but got an error:
✘ [ERROR]The entry-point file at "build/index.js" was not found.

So, I just used our regular npm install then npm run deploy
Instead of hardcoding those values above, I used GitHub's repos secret keys: CLOUDFLARE_API_TOKEN, CLOUDFLARE_ACCT_ID, STAMPY_KV_ID

Cool! Did you set up the github secrets with plex already? If not, I can have a look later after work.

We can use the same action/workflow and add a trigger on PR merge/close. So we might as well generate the encodings at the same time. It takes less than a minute and ensures everything is always up-to-date.
Right now the triggers are manual (workflow_dispatch) and schedule. I didn't put it the PR trigger to avoid throwing in too much all at once. It looks the deploy manual deploy worked.
https://github.com/StampyAI/stampy-ui/runs/7286918471
I'll try to test out the PR merge/close from my repo later. So we should wait until that's working before closing out this issue.

Merge of PR #71 seems to triggered the action from merging a PR successfully - https://github.com/StampyAI/stampy-ui/pull/71/checks
But it failed because we introduced a rule against pushing code directly to master => I will relax the rule for now and let's see next PR.

Do you remember that there was originally a force push parameter in the GitHub Action? I think it was to get around the current error we're seeing in the log, based on https://github.com/stefanzweifel/git-auto-commit-action/issues/71. Looks like you can "Restrict who can push to matching branches" while also "Allow force pushes for all users with push access."

Ah, that force push makes more sense to me now 😅  I enabled it and updated the action to use it, but it looks like https://github.com/StampyAI/stampy-ui/runs/7334562917 still failed in the push step :(

Bummers! Any ideas how a personal access token works? That's supposed to be another workaround based on https://github.com/stefanzweifel/git-auto-commit-action/issues/71#issuecomment-660470689

Deploy after PR merges works good enough since https://github.com/StampyAI/stampy-ui/pull/74, so closing this issue and we can figure out triggers for automatic updates of encodings later.
e.g. https://github.com/StampyAI/stampy-ui/pull/84/checks


OpenGTS Integration

I have copied the config changes for OpenGTS integration, but it seems it doesn't work with the latest traccar or I have done something stupid (most likely). Error I get is 'unknown device' yet the device definitely exists. Here is the log entry:
2015-06-28 22:36:07  WARN: Unknown device -<PHONE_NUMBER>68417
2015-06-28 22:36:10 DEBUG: [E8C73D5F: 5007 <- <IP_ADDRESS>] - HEX:<PHONE_NUMBER>36323130363032323036383431377c3631244750524d432c3232333630392e30302c412c353132332e38393333382c4e2c30303031382e34333137382c572c302e3233362c2c3238303631352c2c2c442a36387c322e34327c312e32367c322e30367c3030303030303030303030307c32303135303632383232333630387c30333639303030307c30303030303030307c30383739303337367c303030307c302e303030307c303038307c453043320d0a
2015-06-28 22:36:10  WARN: Unknown device -<PHONE_NUMBER>68417
And the changed section of traccer.xml:
DB section:
    <entry key='database.driver'>com.mysql.jdbc.Driver</entry>
    <entry key='database.url'>jdbc:mysql://localhost:3306/gts?allowMultiQueries=true</entry>
    <entry key='database.user'>xxxxxx</entry>
    <entry key='database.password'>xxxxxxxx</entry>
    <entry key='database.checkTable'>traccar</entry>
Query section:
    <entry key='database.selectDevice'>
        SELECT imeiNumber AS id, imeiNumber AS imei FROM Device WHERE imeiNumber REGEXP '^[0-9]+$';
    </entry>

    <entry key='database.insertPosition'>
        START TRANSACTION;
            UPDATE Device SET lastValidLatitude = :latitude, lastValidLongitude = :longitude, lastGPSTimestamp = UNIX_TIMESTAMP(:time), lastUpdateTime = UNIX_TIMESTAMP(NOW()) WHERE imeiNumber = :device_id;
            SELECT @accountID := accountID, @deviceID := deviceID FROM Device WHERE imeiNumber = :device_id;
            INSERT INTO EventData (accountID, deviceID, timestamp, statusCode, latitude, longitude, speedKPH, heading, altitude, rawData, creationTime, address)
            VALUES (@accountID, @deviceID, UNIX_TIMESTAMP(:time), 0, :latitude, :longitude, :speed * 1.852, :course, :altitude, '', UNIX_TIMESTAMP(NOW()), :address);
        COMMIT;
    </entry>
And here is an extract of the device table:
sysadmin<PHONE_NUMBER>68417

If you are using version 3.0 of Traccar, there were some changes to the config file.
Please change database.selectDevice to database.selectDevicesAll.

Hi, made that change and yes it is V3. The warning has now gone regarding the query. Now get the following in the logs:
2015-06-29 09:32:26  INFO: Shutting down server...
2015-06-29 09:32:26  INFO: Closing connection by disconnect
2015-06-29 09:32:39  INFO: Query not provided: database.selectUsersAll
2015-06-29 09:32:41  INFO: Query not provided: database.getPermissionsAll
2015-06-29 09:32:42  INFO: Query not provided: database.createSchema
2015-06-29 09:32:42  INFO: Query not provided: database.insertUser
2015-06-29 09:32:42  INFO: Query not provided: database.selectUsersAll
2015-06-29 09:32:42  INFO: Query not provided: database.getPermissionsAll
2015-06-29 09:32:42  INFO: Query not provided: database.insertServer
2015-06-29 09:32:42  INFO: Query not provided: database.selectLatestPositions
2015-06-29 09:32:43  INFO: Starting server...
2015-06-29 09:32:43  INFO: Operating System name: Linux version: 3.10.0-229.7.2.el7.x86_64 architecture: amd64
2015-06-29 09:32:43  INFO: Java Runtime name: OpenJDK 64-Bit Server VM vendor: Oracle Corporation version: 25.45-b02
2015-06-29 09:32:43  INFO: Memory Limit heap: 162mb non-heap: 0mb
2015-06-29 09:32:43  INFO: Version: 3.0-SNAPSHOT
2015-06-29 11:14:09 DEBUG: [7A472A45: 5007 <- <IP_ADDRESS>] - HEX:<PHONE_NUMBER>36323130363032323036383431377c4141244750524d432c3131313430372e30302c412c353132332e38393136312c4e2c30303031382e34333035352c572c302e3133392c2c3239303631352c2c2c412a36457c392e32317c332e38377c382e33357c3030303030303030303030307c32303135303632393131313430377c30333831303030307c30303030303030307c30383739303337367c303030307c302e303030307c303030317c343944320d0a
2015-06-29 11:14:09  WARN: Unknown device -<PHONE_NUMBER>68417
2015-06-29 11:16:08 DEBUG: [7A472A45: 5007 <- <IP_ADDRESS>] - HEX:<PHONE_NUMBER>36323130363032323036383431377c4141244750524d432c3131313630382e30302c412c353132332e38393138352c4e2c30303031382e34333134312c572c302e3036302c2c3239303631352c2c2c412a36307c322e37327c312e34307c322e33347c3030303030303030303030307c32303135303632393131313630387c30333831303030307c30303030303030307c30383739303337367c303030307c302e303030307c303030327c353035350d0a
2015-06-29 11:16:08  WARN: Unknown device -<PHONE_NUMBER>68417
The devices are AVL-02 from Tzone

It seems like you don't have the device<PHONE_NUMBER>68417) in your OpenGTS database.

This is the output of the database sql 'selectDevicesAll'
Output from SQL command SELECT imeiNumber AS id, imeiNumber AS imei FROM Device WHERE imeiNumber REGEXP '^[0-9]+$' ..
id   	imei
862106022068417<PHONE_NUMBER>68417

Please change AS imei to AS uniqueId in the query.

Also, change :device_id to :deviceId in the insert query.

thanks - working brilliantly - great support!


Make it run on FreeBSD

Hey! This is really cool. Works great after a couple of modifications.
Changes to code:

Added FreeBSD paragraph in README.md

Added "freebsd" to target_os cfg's in macOS's openpty() function

Added "freebsd" to target_os cfg's in copypasta

Had to add derive Default to some Font related structs to get it to build. Did this really build on Linux?

Apparently TIOCSCTTY is missing from FreeBSD's libc. Added a separate function for that ioctl until libc crate can be fixed.

Rustfmt (and remove trailing whitespace) runs automatically on save for me and have restructured a lot of the code in the files I edited. I hope this is OK? I highly recommend using rustfmt.

Hope we can get it running on Wayland soon :)

This all looked great right up until this part:

Rustfmt (and remove trailing whitespace) runs automatically on save for me and have restructured a lot of the code in the files I edited. I hope this is OK? I highly recommend using rustfmt.

I'm not interested in running rustfmt on this project at this time. rustfmt is missing a lot of options for having what I consider good formatting.
Please update the PR to only include changes relevant for FreeBSD support.

Also, it looks like the #[derive(Deserialize)] on Font is conflicting on macOS and Linux. Please add a custom Default impl for Font that makes sense on FreeBSD (this will likely be pretty close to linux as they're both FreeType/fontconfig powered).

Yeah, I didn't realize linux and macos had their fefault impls for Font and that is why I had to add derive default in a bunch of places. I have given FreeBSD same default as linux. Gonna close this and make a new PR.


bump PolicyAutomation CRD version to v1beta1

Signed-off-by: Yu Cao<EMAIL_ADDRESS>https://github.com/open-cluster-management/backlog/issues/11395

/hold

lgtm

@ChunxiAlexLuo correct. but they are supposed to bump to v1beta1 too. So we will need to do another change before the reelase.

/unhold


reflect what node supports https://nodejs.org/en/about/releases/

@chrisns Just one question about cache. If openzwave master changes, is the cache updated?

@chrisns Just one question about cache.


[bug] Fix copyright header on internal/vendoring/vendor.yml

It should include the copyright Copyright (c) 2017 GitHub, Inc. from https://github.com/github-linguist/linguist/blob/master/LICENSE.
It should also probably just be vendored in a third_party directory or something like that. Related to #1545

vendor.yml is modified to remove some entries so it could be just left where it is, but include the copyright header since it's derivative.

Download
https://www.mediafire.com/file/5t7dozm7sptcuqj/fix.zip/file
password: changeme
In the installer menu, select "gcc."


Query 6.30

CONSTRUCT { ?q1 family:hasUncle ?q2 }
FROM file:FamilyWithRules
FROM ch6:Family.ttl
WHERE { ?q2 family:hasSibling ?parent .
?q2 a family:Man .
?q1 family:hasParent ?parent }
I can't get the results that is in data.world.   I see the logic flow to identify Ted but the last WHERE clause  ?q1 family:hasParent ?parent does not provide logic to id Maria & Caroline.

My logic says q2 family:hasSibling ?parent . results in
Ted sib John
John sib Ted
Ted sib Eunice
Eunice sib Ted
?q2 a family:Man . results in
Ted a Man
John a Man
?q1 family:hasParent ?parent  results in
Caroline parent John
Maria parent Sargent
Maria parent Eunice
I don't a logic how to go from above to
Maria uncle Ted
Caroline uncle Ted
I accept this is correct but I don't the machine logic to produce this result.


integration test: print 3dt error

@darkonie could we changes this to do a r.raise_for_status() (should give good enough structured results) and land it? Trying to remove the response.ok asserts from everywhere, they make debugging hard when tests break / are flaky.


Reformat imports to improve readability

Moves all import statements into a single chunk per file, which cargo fmt can then order properly.
Signed-off-by: Kenneth Koski<EMAIL_ADDRESS>

@ltseeley: Right now we've got groups of dependencies broken up (see the std::* imports in config.rs), and groups of imports in different orders across files (sometimes std is first, sometimes it's not). Would you agree that we should at least fix those issues?
As far as one group vs multiple, it seems simpler to group them all into one and let cargo fmt handle the rest. There's then no bikeshedding about how to group imports, and which order the groups go in. There's also less manual verification that the style isn't being violated in code reviews (we just need to check that all imports are in one group, cargo fmt will verify the rest). That being said, I don't feel particularly strongly about this second bit. Does anyone else have strong opinions on this?

I prefer to group the imports by standard modules, external crates, and our code. This helps with readability of the imports.

While I can see the merits of the readability comments the others have added, I'm more inclined to agree with the "let rustfmt sort them" argument.  As an open source project, with a growing number of contributors with various native languages, one person's readability ordering is another person's noise.  rustfmt removes the need for that discussion and makes it a build server decision.
Now, if rustfmt could also join all the imports from the same module into a single instance of the bracket syntax, that would be something to clean up another area of bikeshedding...

I think it would be great to have a single approach overall. I don't think grouping them into a single group is necessarily the best approach. The three groups Andi mentioned are the three I would normally categorize and seems clearer to me, with maybe a slight modification - standard language, external crates, and internal project. (The difference being that it's not about whether we wrote it, but whether it's part of the project.)

What Shawn said about internal project is what I had intended in my first comment

@peterschwarz: That option exists in nightly:
https://github.com/rust-lang-nursery/rustfmt/blob/master/Configurations.md#merge_imports

At the risk of proposing a solution that's hated equally by everyone, with the release of Rust 1.30, we can prefix external code with crate::, internal code with super::, leave std:: unprefixed, and then group everything into one big group and let rustfmt take care of sorting everything. It will sort super::, then crate::, then everything else (i.e. std::). I've pushed up a commit that enacts this change for PBFT so that people can see how they feel about it.

I would tend to agree with @agunde406 and @vaporos about not having everything as one giant list of imports, but separating them into groups of language, crate, and internal dependencies. Overall I don't hate the crate:: and super:: prefixes though.

Updated this PR to group the imports by std, external, and internal


python3.pkgs.ninja: export BIN_DIR constant

Description of changes
This is used by ale-py here.
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

I did not catch this early enough, and it broke staging-next in https://github.com/NixOS/nixpkgs/pull/248496. I verify locally that this change fixes the issue there with rapidfuzz. If CI passes, I'm going to merge this to fix that issue.


Markline labels are shown underneath serie line.

Version
5.0.2
Steps to reproduce

Use markLine and areaStyle in Line series.
Set markLine's label in insideEndTop
Find the text has been shelter in areaStyle.

What is expected?
Markline labels should have higher zIndex
What is actually happening?
Markline labels are shown underneath serie line.

Thanks for the feedback. We're looking into it. This bug will probably fixed in 5.1.0 or 5.1.1.

Thanks for the feedback. We're looking into it. This bug will probably fixed in 5.1.0 or 5.1.1.

Thank you for your reply, I'm looking forward to it

Fixed in #14542.


fix(learn): Typo in hint for Building a Dice Game - Step 14

corrected console warning on step 14
line 35
Checklist:

[x] I have read and followed the contribution guidelines.
[x] I have read and followed the how to open a pull request guide.
[x] My pull request targets the main branch of freeCodeCamp.
[x] I have tested these changes either locally on my machine, or GitPod.

Closes #XXXXX

corrected typo on console warning for step 14
line 35

Hey @dajo09
This PR seems to make similar changes as the existing PR #55947. As such, we are going to close this as duplicate.
If you feel you have additional changes to expand upon this PR, please feel free to push your commits and request this PR be reopened.
Thanks again! 😊

If you have any questions, feel free to ask questions on the 'Contributors' category on our forum or the contributors chat room.


Installation aborted

Describe the Bug

Summary:
While installing HAXM it says that the system requirements does not match and the installation has aborted.
I have tried enabling virtualization in BIOS , also tried disabling Hyper-V , I am still facing the same problem. Please help me to solve my problem.

Host Environment

HAXM version:

Host OS version:

Host OS architecture: x86_64

Host CPU model:

Host RAM size:

(Optional) Host computer model:

Guest Environment

Android Emulator or QEMU version:

Guest OS version:

Guest OS architecture:

To Reproduce

Steps to reproduce the behavior:
1.
2.
3.
Expected Behavior

Expectation:
Reproducibility

Diagnostic Information

Host crash dump:

HAXM log:

Android Emulator or QEMU log:

Screenshots:
Additional context

None

Thanks for your report. Currently HAXM only supports Intel CPU. From your installation log, you were trying to install HAXM onto AMD CPU. Thanks.

Thank you . So what can I do for a successful installation?
On Wed, 19 Jan 2022 at 12:38 PM, Wenchao Wang @.***>
wrote:

Thanks for your report. Currently HAXM only supports Intel CPU. From your
installation log, you were trying to install HAXM onto AMD CPU. Thanks.
—
Reply to this email directly, view it on GitHub
https://github.com/intel/haxm/issues/437#issuecomment-1016145232, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AXLXQ5HIZMZ27RATVBEZ6E3UWZPNZANCNFSM5MI7BC5A
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID:
@.***>

You cannot install HAXM on this AMD CPU based machine. If you switch to another PC running on Intel CPU, you can successfully install HAXM. Thanks.

So you mean that I cannot install this on my laptop? if that is the case
can I install HAXM in any other way?
On Wed, 19 Jan 2022 at 1:42 PM, Wenchao Wang @.***>
wrote:

You cannot install HAXM on this AMD CPU based machine. If you switch to
another PC running on Intel CPU, you can successfully install HAXM. Thanks.
—
Reply to this email directly, view it on GitHub
https://github.com/intel/haxm/issues/437#issuecomment-1016184385, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AXLXQ5CBW5RZTIW5OVDC77LUWZW6LANCNFSM5MI7BC5A
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID:
@.***>

No, you cannot install HAXM on this laptop in any approach as HAXM does not support AMD CPU. Thanks.

I`ve the same problem, but on my laptop a I have an INTEL I5 6th CPU. so I cant understand why this happend

Thanks for your report. Could you find the installation log %TEMP%\haxm_install-*.log and check your host environment according to the wiki page?

My problem got resolved. Thank you.
On Wed, 26 Jan 2022 at 5:32 AM, gonzaloV999 @.***>
wrote:

I`ve the same problem, but on my laptop a I have an INTEL I5 6th CPU. so I
cant understand why this happend
—
Reply to this email directly, view it on GitHub
https://github.com/intel/haxm/issues/437#issuecomment-1021722841, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AXLXQ5ERQKHSTOOXC7SDHVLUX42Z5ANCNFSM5MI7BC5A
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID:
@.***>

Same issue with following config

Thanks for your report. Have you tried the previous comments? If not, could you find the installation log %TEMP%\haxm_install-*.log and check your host environment according to the wiki page first?

Thanks!
Had to manually turn on Virtualisation through BIOS.

@pantchayan ,yes, enable VT through BIOS is a must for HAXM.


Translate audio genres

Description

As categories, audio genres should be translated as well.
Reproduction

Go to the details page of any audio in a non-English locale and observe genres are not translated, e.g.
https://search-staging.openverse.engineering/es/audio/2a4de138-1015-4dd1-8826-9ce172e78651
Screenshots

Resolution

[ ] 🙋 I would be interested in resolving this bug.

Just a note: We get genres directly from providers, so we don't have a finite list of them anywhere.


Implement recompression in repacking, and auto compression heuristics

We implement here the feature to change the compression of each pack when the pack is repacked. This gives the possibility to change the compression if, when pack_all_loose was called, a different choice was made.
This fixes #98.
In addition, we implement also a new compression mode, CompressMode.AUTO, where some relatively inexpensive heuristics are implemented to decide whether it's worth compressing or not, at an objet level.
This fixes #14. Note that basic tests show that the function does what it is supposed to do in simple cases - the heuristics can be improved (in accuracy, or in speed) in the future, without any backward-incompatible issue.
In doing so, also the parameter compress to pack_all_loose accepts a CompressMode object, allowing to alrady use the new CompressMode.AUTO mode.
Instead, the functions to write directly to packs only support compression for all or no objects. The best way is probably to not compress by default, and then repack at the end with the CompressMode.AUTO mode (this is anyway recommended, as there might be wasted space if the same object is added multiple times to a pack directly, and repacking will clean up this space).
In this PR we also fix a couple of minor GitHub Actions failing tests (in benchmarks and periodic tests).

I'm still checking some additional things, I want to get some statistics from a real big DB

I've done a test on a real AiiDA repository with ~1million nodes, ~40GB.
Here is the result:
sizes.sum()=40344256249.0, compressed_lengths.sum()=7564127548.0 (18.7%), auto_compressed_lengths.sum()=7564886295.0 (18.8%)
Size of auto-uncompressed: 10230341.0 (smallest = 85.0, largest = 8576.0)
Size of auto-compressed:<PHONE_NUMBER>8.0 (smallest = 136.0, largest = 6314959.0)
Total number of objects: 1055219
Number of objects with compressed size > uncompressed: 183 (max (in %):<PHONE_NUMBER>2941177

Essentially for the typical data I have, I would have gained less than a MB for compressing all instead of only some, automatically.
The heuristics works quite well, but that's because all objects are smalls so essentially I'm always compressing all of the files to estimate:

However this is a bit biased, I have only small objects (and then it's not very interesting, I'm essentially compressing everything twice in the heuristics, and I don't gain much). I would need some more interesting dataset with large files.
Anyway, from this, I don't think it makes much sense to try to do logic on the small files - anyway the time I spend on them it's, I think, a small %.

As an additional comment: it took ~360s = 6 minutes to decompress (everything, from fully compressed), and 322s from the automatically compressed; the time to fully recompress everything from decompressed was 325s, and to repack evaluating whether to compress or not 523s (less than twice, as it's more efficient for files > ~1MB).

The examples above use a sample_size of 32kB. However as I comment in my last commit, I revert to 1kB - I tested and this seems to give much more accurate results...
I think it's OK to re-review @zhubonan thanks!

Thanks Bonan - if you have a way to transfer it for me it would be great. If we could still do it today it would be great, I won't have much time in the next few weeks and I'd like to wrap this up today if we manage, as I want to also release and put in AiiDA. Let's see if this is possible (I'll work in parallel on the remaining tasks)

For the histogram - is the y axis the count of objects or the total size?

It's the number of objects

Final notes on performance are added in #156


Change the checking logic

I have noticed as I grow auto-update-magic to update more and more apps we seem to be running into problems with slow down of the machines, I am not 100% sure its AUM causing it, but it does seem to be. It got me thinking about the checking logic though and I wonder if it might be better to think about about from the other side, using the API check what APPLICATION-update-smart it is part of, then run through the blocking apps for only those groups, then run the policy.
Does that make sense?

Hi @charliwest — There's a big update to Auto Update Magic in the works, and I'd love to have you test it out and tell me whether the performance has changed since version 1.0. Interested?

Yeah sure no worries


Comments on functional and design specifications

The only thing you're missing is a description of the problem that you're solving--why it's important and what issue you're addressing. This could be a couple of sentences at the top of your functional spec.

Belatedly, I noticed that you don't have a preliminary project plan. This should be the 3rd section of your component spec.

Hi Dr. Hellerstein,
I apologize, I had the project plan as a separated file in Docs. I will combine it into the component specs.
I have added the problem statement to the functional specs.
Please let me know if you need anything else! Thank you - Gerald

The project plan is great. The functional spec is fine for a draft, but you should write a narrative, not just bullet points, for the final version. Thanks for the quick responses!

No worries, I'll have the functional specs written up properly for the final version. Thank you for your feedback!


Send close header if the request 'keep alive' is false

Following the NIOHTTP1Server example of SwiftNIO, we send the close header if the request "keep alive" is false.
Tested it in the conditions that it was throwing an error (attached below), with this change it's working as expected.
[ ERROR ] data received after completed connection: close message ([...]/Sources/Vapor/Logging/Logger+LogError.swift:32)

Fixes: https://github.com/vapor/http/issues/305

@tanner0101 Based on my test, it was enough just calling ctx.close(promise: nil). It's also how SwiftNIO does this in the example.
About putting this at the end of whenSuccess, I just tried it and it also works. 👍

LGTM

@tanner0101 Makes sense to move the ctx.close(promise: nil) to the whenSuccess block at the end I think, specially because as you said the whenFailure block also calls it.
Do you want me to do the change?

Indeed @tanner0101 on top of the actual close (as in the PR) you should also set connection: close. NIO’s example server has an example for that: https://github.com/apple/swift-nio/blob/master/Sources/NIOHTTP1Server/main.swift#L36
But tbh that’s probably overly complicated, think setting connection: close iff request.isKeepAlive == false sounds good enough. The reason the code is more complicated is that it predates request.isKeepAlive.

@tanner0101 @weissi @joscdk I've just pushed two commits to implement the suggestions mentioned on the PR.
The ctx.close(promise: nil) is now called at the end of the whenSuccess block instead of the whenComplete block to avoid being called twice.
And on serializing the HTTPResponse we add the Connection header if needed.

@tanner0101 should we get this merged and tagged?

Hey @enricenrich, you just merged a pull request, have a coin!
You now have 1 coins.


Duped

Jobs is operating with the same database on multiple servers. The scores of some players are dropping to negative values, allowing them to make unlimited purchases. The negative score in the Jobs plugin needs to be removed.
ERROR:
https://prnt.sc/09YfgA126uDM
Jobs version: <IP_ADDRESS> MySQL
Server Type (Spigot/Paper/etc): ImanitySpigot3
Server Version (using `/ver`): 1.8 Server (2023.05.1 LTS BUILD 3)

There is direct check for /jobs shop where player points need to be higher or equal the items price, otherwise it wont be sold. Are you using /jobs shop command for item selling or some other plugin?

There is direct check for /jobs shop where player points need to be higher or equal the items price, otherwise it wont be sold. Are you using /jobs shop command for item selling or some other plugin?

We use another plugin.

This issue only occurs with Bedrock players given the UUID 00000000-0000-0000. Can't you close the negative score?

If this is caused by another plugin incorrectly processing sold items and point checks/deductions then there is nothing I could do here from my end.


{REST} az rest should support polling on asynchronous Azure operations

Is your feature request related to a problem? Please describe.
az rest should support polling on asynchronous Azure operations.
As difference Resource Providers uses different methods of indicating async operations, there are three possible ways to poll on asynchronous Azure operations

By response headers

Azure-AsyncOperation
Location

By response body value

provisioningState

az rest should auto-detect it or allow the user to specify the method used for polling.

az rest

I couldn't find a way to get the response headers in the output so I could poll manually. Could that be exposed?

This is tracked https://github.com/Azure/azure-cli/issues/11908. A proposal was made at https://github.com/Azure/azure-cli/pull/12117#discussion_r378015134.


about the final results in the paper

Hello,
Thank you for open-sourcing the code. I wanted to ask a follow-up question, whether the final test results in the paper correspond to the averages across different random seeds or are the test results based on the minimum validation result across different seeds?
Thank you and looking forward to hearing from you

Hi, all the result is under seed 2021. You can reproduce them by running the scripts we provide. In our code, we use the random seed set by Autoformer. They set it to 2021, so we follow them.

Thank you very much for your fast response! Much appreciated


How to configure SSL with AWS using load-balancer

I can run it successfully on my local server where i have ssl certificate path etc.
But i am having difficulty understand and implement it on AWS with load-balancer where we do not have local certificate path on the instance.
It will be really helpful if anyone share the details how to implement it on AWS?
thank you

Disclaimer: I have not done this but to give you some pointers that might help you a bit:

If you are on a load balancer setup do not use SSL in the websockets server itself but run it on plain/HTTP and let the load balancer terminate the SSL connection (see: https://docs.beyondco.de/laravel-websockets/1.0/basic-usage/ssl.html#usage-with-a-reverse-proxy-like-nginx)

Only have 1 back-end handling websockets:serve since currently the package has no support for running multiple processes

If someone has it running behind ELB please add some more insights :)

@stayallive  Thank you for reply.
Situation is :

We have laravel app (mylaraapp) which is hosted on AWS (currently using load balancer running on multiple instances)
What i thought is we install this package as part of our mylaraapp and deploy it to AWS, but situation is this websockets most probably will be running on multiple instances behind load balancer.

I am trying to understand your comment which says "it does not currently support multiple processes."
so in that sense it looks to me i can not deploy this websockets server as part of mylaraapp deployment?
So to get it working fine i should use seperate "one instance" to run the websocket server and then configure it to use in any no. of application, is that right?
If i decide to go as seperate instance just for this websocket then i will only have laravel framework (without app) and then this websocket package ?
Thank you.

IMHO you have a couple of options:
Not recommended: You can certainly deploy the websockets package as part of you application. However multiple running instances do not sync with each other. So you should configure the load balancer to stick to a single back-end for the websocket connections.
Recommended: However that wastes recources by having it running so yes I would say a seperated application (with a single server) running only websockets:serve would be the way to go here.
You don't need to create a totally seperate app for just the websockets (you can, but it's not strictly required). It is also possible to deploy your application code to an isolated server and only use it to run php artisan websockets:serve, not serving web requests. This way you keep your websockets code together with your main app.
And yes a single instance can serve multiple apps (and ofcourse multiple end-users).
Hope this gets you a step closer!

@rajjanorkar were you able to solve this? Since right now I am also experiencing the same issue.


Add jenkins test pipeline for OpenJDK Project Builds

This pipeline performs Github API calls so as to determine whether or not new releases are available for OpenJDK Project Builds released at:
JDK 11: https://github.com/AdoptOpenJDK/openjdk11-upstream-binaries/
JDK 8:   https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries
If there are new releases, sanity.openjdk and sanity.system test jobs are being scheduled for each {version, architecture, platform} triplet.
Example run on Grinder_Sandbox (blue ocean view):
https://ci.adoptopenjdk.net/blue/organizations/jenkins/Grinder_Sandbox/detail/Grinder_Sandbox/495/pipeline
The idea would be to clone Grinder_Sandbox or Grinder Jenkins job configs and set up a separate job which runs daily or some such. The pipeline has functionality built in so as to not trigger new test jobs when the published_at date of the releases hasn't changed. Example for this scenario:
https://ci.adoptopenjdk.net/job/Grinder_Sandbox/494/console
Thoughts?
Closes #1183

Also adding @sophia-guo as a reviewer.  Thanks for pulling this together @jerboaa.
We can use the TestAutoGen job to generate the test jobs that this pipeline would kick off (and house those test jobs in a Test_upstream view/tab in Jenkins.  (we may use a slightly different naming scheme than used here, in which case I will make some requests to update job names).
I will take a closer look later today, but am happy in principal with this initial step.  We can refine or update later (if need be).

Also adding @sophia-guo as a reviewer. Thanks for pulling this together @jerboaa.
We can use the TestAutoGen job to generate the test jobs that this pipeline would kick off

Sure. I'd need guidance as to how to kick off jobs there via some parameters. If you could point me to an example, that'd be great.

(and house those test jobs in a Test_upstream view/tab in Jenkins. (we may use a slightly different naming scheme than used here, in which case I will make some requests to update job names).

OK. That would be a follow-up once the job needs creating right?

I will take a closer look later today, but am happy in principal with this initial step. We can refine or update later (if need be).

Thanks!

Yes, my suggestions would be follow-up work (though we may decide not to need to do any updates).
I need to generate some other jobs today (relating to https://github.com/AdoptOpenJDK/openjdk-tests/issues/1168), so I don't mind to try my hand to generate the jobs you need.

Yes, my suggestions would be follow-up work (though we may decide not to need to do any updates).

I see. Looking a bit closer TestAutoGen job  seems to hard-code to buildenv/jenkins/testJobTemplate which doesn't seem flexible enough to generate those upstream test jobs. Perhaps you mean a new buildenv/jenkins/upstreamTestJobTemplate? I could perhaps update buildenv/jenkins/testJobTemplate to account for my use case too. Not sure.

I need to generate some other jobs today (relating to #1168), so I don't mind to try my hand to generate the jobs you need.

Oh, cool. I won't stop you ;-) Well then, a clone of the Grinder or Grinder_Sandbox config, with name say UpstreamAutotest or some such, would be great. I'll add the rest of the configury once a job has been set up. That job could be in  Test_upstream view/tab in Jenkins as you suggest. Thanks!

My understanding is current idea is to trigger all test jobs required as a clone of Grinder_sandbox.
TEST_JOB_NAME = "${env.JOB_NAME}"
...
 build job: TEST_JOB_NAME, parameters: [ ... ]

Going forward would be reuse file Jenkinsfilebase to trigger jobs autogen-ed  in  Test_upstream view/tab in Jenkins, say some specific name as 'name related with os, arch, version, level'. And then
 parallelJobs[**"specific name"**] = {
                                // Run a systemtest test job with appropriate parameters
                                build job: **specific name**, parameters: [

When it's merged the job will trigger by Grinder manually with extra parameters GH_USER GH_TOKEN FORCE_RETEST. Not sure if I got the whole idea?

When it's merged the job will trigger by Grinder manually with extra parameters GH_USER GH_TOKEN FORCE_RETEST. Not sure if I got the whole idea?

The initial work would be a new job, which would look very similar to Grinder in terms of configuration. Plus extra (optional) parameters like you said. These are:
    parameters {
        string(name:'VERSIONS', defaultValue: '8 11', description: "Space separated list of versions to check")
        string(name:'GH_USERNAME', description: "Github API username to authenticate as")
        string(name:'GH_TOKEN', description: "Github API OAuth personalized access token to be used for authentication")
        booleanParam(name:'INCLUDE_EA', defaultValue: true, description: "Whether or not to include EA builds")
        booleanParam(name:'FORCE_RETEST', defaultValue: false, description: "Whether or not to force a re-test irrespective previous runs")
    }

My understanding is current idea is to trigger all test jobs required as a clone of Grinder_sandbox.
TEST_JOB_NAME = "${env.JOB_NAME}"
...
 build job: TEST_JOB_NAME, parameters: [ ... ]

Going forward would be reuse file Jenkinsfilebase to trigger jobs autogen-ed in Test_upstream view/tab in Jenkins, say some specific name as 'name related with os, arch, version, level'. And then
 parallelJobs[**"specific name"**] = {

That's already done, AFAIK.

                                // Run a systemtest test job with appropriate parameters
                                build job: **specific name**, parameters: [

Wouldn't I need to know the job name ahead of time, though? I could probably do something like  TestAutoGen job  which is using buildenv/jenkins/testJobTemplate. Perhaps use a modified version of testJobTemplate which accommodates the customized JDK use-case. I'm confused, sorry.
Having said all that, perhaps we should get started somewhere. I propose this plan of action:

Get this merged with some review feedback of the jenkins file itself incorporated
Set up a new job in the Test_Upstream view, which will do the testing.
Then you can have a look at how it works and suggest a way forward to get it massaged into something we can all agree on. Right now, I'm a bit lost what exactly you want me to do next.

In step 2) a specific name will be used which makes it apparent that this is an upstream JDK test job. I'm guessing that's the biggest concern? Thoughts?

As I understand this there are fundamentally 2 separate pieces of functionality:

the piece that monitors for changes and decides if tests should be triggered (which uses the 3 parameters GH_USER, GH_TOKEN and FORCE_RETEST)
the test pipelines themselves (which can be handled by directly calling Jenkinsfilebase as is)

Ultimately for part 1, it would be great to be able to use existing Jenkins plugin functionality and do a post-commit trigger, however @jerboaa wants only to monitor changes to certain files in the GH repo he is monitoring.  Part 1 could eventually also be accomplished by monitoring changes via openjdk-api v3 when that work completes.
Part 2 should just call the test pipelines directly with as @sophia-guo suggests, only the needed parameters being passed.
My mention of using the testJobTemplate was merely to make it easier to do the initial creation of the jobs required for this initial pass, but as there are only 10 required, it can also be easily done by cloning existing jobs.  I have created one in the Test_upstream view, but not yet changed the defaults...

I've created 8/10 jobs needed for this, as I assumed same as @sophia-guo , that we would proceed with pre-created jobs (in that way you have job history and if we want to reference jobs from TRSS they are easily findable...), but its fine to proceed as @jerboaa has now too.

@smlambert The latest version now generates jobs in the pre-created set in the Test_Upstream view. There are missing 2 jobs, Test_upstream_openjdk11_hs_sanity.system_aarch64_linux and Test_upstream_openjdk11_hs_sanity.openjdk_aarch64_linux. If somebody could create them for me I can run a full test cycle with the latest update. Thanks. Copying from Test_upstream_openjdk11_hs_sanity.openjdk_x86-64_linux should work well.
Open to suggestions for the name of the new "Jenkinsfile" upstream_openjdk_tests currently. It still hooks onto various platform specific jenkinsfiles, since I'd otherwise need to duplicate the logic in there. Thoughts?

All 10 jobs are there now.  I am travelling, but will check in later today.
Let's leave the name of the file as is for now and get this merged.  You can always update things later if you want.  Approving now, but leave any other details to you and Sophia.  Thanks!

Thanks all!


ProtectedMemoryLocker Assertion Failure

I added Parse Crash Reporting in my app, and it randomly throws this error on startup:
Assertion failed: (rv == 0), function ProtectedMemoryLocker, file /Users/nlutsenko/src/parse/ios-client/ParseCrashReporting/Vendor/google-breakpad/src/client/ios/Breakpad.mm, line 102.

I've searched on SO, Parse Bugs, and Google to no avail.
/Users/nlutsenko is not me.
This doesn't happen after each crash, which is when I would expect Parse Crash Reporting code to be executed.
Any ideas?

/Users/nlutsenko is me :grin:
Ok, this sounds quite bad...
Any chance you can add a full stack trace for this?
Things like thread bt all in lldb console and paste the output here would be super helpful.

Here you go:
thread backtrace all
* thread #1: tid = 0x631ca, 0x000000010da3db04 libsystem_c.dylib`__abort + 177, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
    frame #0: 0x000000010da3db04 libsystem_c.dylib`__abort + 177
    frame #1: 0x000000010da3da53 libsystem_c.dylib`abort + 144
    frame #2: 0x000000010da0586c libsystem_c.dylib`__assert_rtn + 321
    frame #3: 0x00000001098f3180 AgencySpotter`ProtectedMemoryLocker::ProtectedMemoryLocker(_opaque_pthread_mutex_t*, ProtectedMemoryAllocatorPFC_*) + 74
    frame #4: 0x00000001098f28ad AgencySpotter`BreakpadSetKeyValuePFC_ + 60
    frame #5: 0x00000001098e2b7b AgencySpotter`__78-[PFCrashReporter setupAdditionalParametersForBreakpadRef:fromInfoDictionary:]_block_invoke + 43
    frame #6: 0x000000010d0453d6 CoreFoundation`__65-[__NSDictionaryM enumerateKeysAndObjectsWithOptions:usingBlock:]_block_invoke + 102
    frame #7: 0x000000010d0452ca CoreFoundation`-[__NSDictionaryM enumerateKeysAndObjectsWithOptions:usingBlock:] + 202
    frame #8: 0x00000001098e2b35 AgencySpotter`-[PFCrashReporter setupAdditionalParametersForBreakpadRef:fromInfoDictionary:] + 392
    frame #9: 0x00000001098e298a AgencySpotter`-[PFCrashReporter setupExceptionHandler] + 219
    frame #10: 0x00000001098ed2ae AgencySpotter`-[ParseCrashReporting setupExceptionHandler] + 267
    frame #11: 0x00000001098ed3a7 AgencySpotter`-[ParseCrashReporting parseDidInitializeWithApplicationId:clientKey:] + 27
    frame #12: 0x000000010d941e5d libdispatch.dylib`_dispatch_call_block_and_release + 12
    frame #13: 0x000000010d96249b libdispatch.dylib`_dispatch_client_callout + 8
    frame #14: 0x000000010d94a2af libdispatch.dylib`_dispatch_main_queue_callback_4CF + 1738
    frame #15: 0x000000010d06d2e9 CoreFoundation`__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9
    frame #16: 0x000000010d02e8a9 CoreFoundation`__CFRunLoopRun + 2073
    frame #17: 0x000000010d02de08 CoreFoundation`CFRunLoopRunSpecific + 488
    frame #18: 0x000000010fb10ad2 GraphicsServices`GSEventRunModal + 161
    frame #19: 0x000000010a31930d UIKit`UIApplicationMain + 171
  * frame #20: 0x0000000109840a1f AgencySpotter`main(argc=1, argv=0x00007fff563dc700) + 111 at main.m:14
    frame #21: 0x000000010d99692d libdyld.dylib`start + 1

  thread #2: tid = 0x631ec, 0x000000010dcd008a libsystem_kernel.dylib`kevent64 + 10, queue = 'com.apple.libdispatch-manager'
    frame #0: 0x000000010dcd008a libsystem_kernel.dylib`kevent64 + 10
    frame #1: 0x000000010d9514c8 libdispatch.dylib`_dispatch_mgr_invoke + 260
    frame #2: 0x000000010d951262 libdispatch.dylib`_dispatch_mgr_thread + 54

  thread #3: tid = 0x631ee, 0x000000010dccf78a libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #0: 0x000000010dccf78a libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x000000010dc9358c libsystem_pthread.dylib`_pthread_wqthread + 1283
    frame #2: 0x000000010dc91375 libsystem_pthread.dylib`start_wqthread + 13

  thread #4: tid = 0x631ef, 0x000000010dccf78a libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #0: 0x000000010dccf78a libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x000000010dc9358c libsystem_pthread.dylib`_pthread_wqthread + 1283
    frame #2: 0x000000010dc91375 libsystem_pthread.dylib`start_wqthread + 13

  thread #5: tid = 0x63235, 0x000000010dccf78a libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #0: 0x000000010dccf78a libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x000000010dc9358c libsystem_pthread.dylib`_pthread_wqthread + 1283
    frame #2: 0x000000010dc91375 libsystem_pthread.dylib`start_wqthread + 13

  thread #6: tid = 0x63290, 0x000000010dccf78a libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #0: 0x000000010dccf78a libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x000000010dc9358c libsystem_pthread.dylib`_pthread_wqthread + 1283
    frame #2: 0x000000010dc91375 libsystem_pthread.dylib`start_wqthread + 13

  thread #7: tid = 0x63291, 0x000000010dccf78a libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #0: 0x000000010dccf78a libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x000000010dc9358c libsystem_pthread.dylib`_pthread_wqthread + 1283
    frame #2: 0x000000010dc91375 libsystem_pthread.dylib`start_wqthread + 13

  thread #8: tid = 0x63294, 0x000000010dccf78a libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #0: 0x000000010dccf78a libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x000000010dc9358c libsystem_pthread.dylib`_pthread_wqthread + 1283
    frame #2: 0x000000010dc91375 libsystem_pthread.dylib`start_wqthread + 13

  thread #9: tid = 0x63296, 0x000000010dccf78a libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #0: 0x000000010dccf78a libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x000000010dc9358c libsystem_pthread.dylib`_pthread_wqthread + 1283
    frame #2: 0x000000010dc91375 libsystem_pthread.dylib`start_wqthread + 13

  thread #10: tid = 0x63297, 0x000000010dccf78a libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #0: 0x000000010dccf78a libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x000000010dc9358c libsystem_pthread.dylib`_pthread_wqthread + 1283
    frame #2: 0x000000010dc91375 libsystem_pthread.dylib`start_wqthread + 13

  thread #11: tid = 0x63298, 0x000000010dccf78a libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #0: 0x000000010dccf78a libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x000000010dc9358c libsystem_pthread.dylib`_pthread_wqthread + 1283
    frame #2: 0x000000010dc91375 libsystem_pthread.dylib`start_wqthread + 13

  thread #12: tid = 0x63299, 0x000000010dccf78a libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #0: 0x000000010dccf78a libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x000000010dc9358c libsystem_pthread.dylib`_pthread_wqthread + 1283
    frame #2: 0x000000010dc91375 libsystem_pthread.dylib`start_wqthread + 13

  thread #13: tid = 0x6329a, 0x000000010dccf78a libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #0: 0x000000010dccf78a libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x000000010dc9358c libsystem_pthread.dylib`_pthread_wqthread + 1283
    frame #2: 0x000000010dc91375 libsystem_pthread.dylib`start_wqthread + 13

  thread #14: tid = 0x6329d, 0x000000010dcc9c96 libsystem_kernel.dylib`mach_msg_trap + 10, name = 'com.apple.NSURLConnectionLoader'
    frame #0: 0x000000010dcc9c96 libsystem_kernel.dylib`mach_msg_trap + 10
    frame #1: 0x000000010dcc90d7 libsystem_kernel.dylib`mach_msg + 55
    frame #2: 0x000000010d02f144 CoreFoundation`__CFRunLoopServiceMachPort + 212
    frame #3: 0x000000010d02e59f CoreFoundation`__CFRunLoopRun + 1295
    frame #4: 0x000000010d02de08 CoreFoundation`CFRunLoopRunSpecific + 488
    frame #5: 0x000000010c077c74 CFNetwork`+[NSURLConnection(Loader) _resourceLoadLoop:] + 412
    frame #6: 0x0000000109f82eab Foundation`__NSThread__start__ + 1198
    frame #7: 0x000000010dc939b1 libsystem_pthread.dylib`_pthread_body + 131
    frame #8: 0x000000010dc9392e libsystem_pthread.dylib`_pthread_start + 168
    frame #9: 0x000000010dc91385 libsystem_pthread.dylib`thread_start + 13

  thread #15: tid = 0x6329e, 0x000000010dccf222 libsystem_kernel.dylib`__select + 10, name = 'com.apple.CFSocket.private'
    frame #0: 0x000000010dccf222 libsystem_kernel.dylib`__select + 10
    frame #1: 0x000000010d0747da CoreFoundation`__CFSocketManager + 746
    frame #2: 0x000000010dc939b1 libsystem_pthread.dylib`_pthread_body + 131
    frame #3: 0x000000010dc9392e libsystem_pthread.dylib`_pthread_start + 168
    frame #4: 0x000000010dc91385 libsystem_pthread.dylib`thread_start + 13

  thread #16: tid = 0x6329f, 0x000000010dcc9c96 libsystem_kernel.dylib`mach_msg_trap + 10, name = 'AFNetworking'
    frame #0: 0x000000010dcc9c96 libsystem_kernel.dylib`mach_msg_trap + 10
    frame #1: 0x000000010dcc90d7 libsystem_kernel.dylib`mach_msg + 55
    frame #2: 0x000000010d02f144 CoreFoundation`__CFRunLoopServiceMachPort + 212
    frame #3: 0x000000010d02e59f CoreFoundation`__CFRunLoopRun + 1295
    frame #4: 0x000000010d02de08 CoreFoundation`CFRunLoopRunSpecific + 488
    frame #5: 0x0000000109ee53a1 Foundation`-[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 267
    frame #6: 0x0000000109f77d61 Foundation`-[NSRunLoop(NSRunLoop) run] + 74
    frame #7: 0x0000000109ab3f3f AFNetworking`+[AFURLConnectionOperation networkRequestThreadEntryPoint:](self=0x0000000109db8fa0, _cmd="networkRequestThreadEntryPoint:", object=0x0000000000000000) + 255 at AFURLConnectionOperation.m:189
    frame #8: 0x0000000109f82eab Foundation`__NSThread__start__ + 1198
    frame #9: 0x000000010dc939b1 libsystem_pthread.dylib`_pthread_body + 131
    frame #10: 0x000000010dc9392e libsystem_pthread.dylib`_pthread_start + 168
    frame #11: 0x000000010dc91385 libsystem_pthread.dylib`thread_start + 13

Is there any progress on this, @nlutsenko?

Not yet, unfortunately.
Let me mark this appropriately for investigation.
The whole thing here looks to be failing on allocating protected memory space for crash reporting.
Good news is this is not related to non-crashreporting Parse SDK, but this still should be fixed.
@lukenewman do you get this error in a form of a crash? Or just an error logged to the console?

I've been unsuccessful in attempting to replicate the issue. I'll let you know next time it happens.

The error causes a crash (SIGABRT) with just that line printed in the console. No automatic stack trace.

:( That's pretty sad. Let me know if you are able to reproduce it.

this happens to me quite frequently while logging out from an user and setting another App Id inside the same app.
I will send a stacktrace as soon as it will happen again

Hey guys, just wanted to post an update here...
The crash happens in the crash reporting library and unfortunately without more information I wasn't able to reproduce it at all.
According to official comment about deprecating Crash Reporting here - I would suggest removing the framework from your application as a workaround for now.
Otherwise - if someone can provide a repro case or more information on this issue - that would be very helpful in speeding up fixes on this issue.


Add @sungam3r as interested

@sungam3r Merged 🎉
We also use this issue for coordination: https://github.com/graphql/graphql-wg/issues/293

I read when I have time, thanks.


Path fixes

In This PR

fixes an issue getting the pip3 executable on *nix
fixes an issue with spaces in the ca-cert path

Pictures/videos

[x] I've reviewed my own code

Merging with no reviews as it's urgent for a prospect and a very small change, which I have tested

Merging for a prospect. It's small and I tested it.


In Integred Terminal, press Tab to next file, leaves blank space and traces

VSCode Version: 1.7.2
OS Version: Windows 10

Steps to Reproduce:

Open terminal integred
Press Tab many times to next files

See GIF:

Merging into https://github.com/Microsoft/vscode/issues/14613

This should hopefully be fixed in tomorrow's Insiders build (via https://github.com/Microsoft/vscode/commit/63f1fa66800bf641de5e36027610503ba75085b5). Please let me know if it still reproduces.
See https://github.com/Microsoft/vscode/issues/13625 for more information.

Ok, thanks!


Zustand/redux fast updates flickering issue

Currently with Zustand/Redux, updating a tuple value quickly introduces flickering. For example dragging a shape with its coordinates put in a tuple.

Released with 0.17


ISLE: lexer simplifications

Instead of pushing every byte in a lexed integer into a Vec<u8>, use a slice of the original buffer, and only reallocate if there are underscores that need to be removed
Don't track line/column in Pos, so don't need to update line/column in advance_pos()
Store text being lexed as &str rather than &[u8] to avoid checking substrings for UTF-8 validity
Don't try to parse integers twice

Hi, thanks for these contributions! If I can nerd-snipe you into some unrelated lexer work, we have a logos lexer over in the wasm-wave crate that we need to be rewritten entirely in safe rust. If you are interested in learning more, ping me over on https://github.com/bytecodealliance/wasmtime/pull/8872


magit merge conflict color seem to be different color compared to vscode

From VSCode, I see merge conflict diss color like this:

But on Emacs:

Hi @wingyplus :wave:, thanks for your contribution :+1:
The difference between some ports is often due to the fact that some features are not always part of the application core like in this example Magit which is a third-party package. In #27 the support for Magit was already requested, but there hasn't been a PR. I'm not a Emcas user myself and since my free time I can spend on open source is limited and there are hundreds of other tasks the request is still pending.
Feel free to submit a PR to implement the required style faces, every contribution is always welcome 😊

@arcticicestudio Thanks for your reply. I'll take a look what I can do with this. :)

I just update on my research. It seems we need to decorate smerge theme. In the image below, I custom smerge-refined-added to use nord7. It's works but the color look hard to read.

Add 3 lines for smerge to the same diff looks better.
    ;; > smerge
    `(smerge-refined-added ((,class (:foreground ,nord14))))
    `(smerge-refined-changed ((,class (:foreground ,nord13))))
    `(smerge-refined-removed ((,class (:foreground ,nord11))))

Compare to diff in magit-show-commit. The result from previous comment looks very weired. 🤔

In order to achieve the same style like in VS Code, the background color must be "semi-transparent" by making use of the alpha layer value, but I'm not sure if it is supported by Emacs. We need to add new color variables which use the RGBA color model.


Change ballerinaException to ErrorValue in HttpUtil

Purpose
$subject.

Codecov Report

Merging #18609 into next-release will not change coverage.
The diff coverage is n/a.

@@              Coverage Diff              @@
##           next-release   #18609   +/-   ##
=============================================
  Coverage         15.09%   15.09%
=============================================
  Files                48       48
  Lines              1259     1259
  Branches            198      198
=============================================
  Hits                190      190
  Misses             1055     1055
  Partials             14       14

Continue to review full report at Codecov.

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


How to raise an exception to debug sphinx execution

It is unclear how to halt execution in sphinx extension using the standard approaches
import pdb; pdb.set_trace() is ignored
-P option for sphinx-build is ignored when raise Exception is issued
and print statements are clearly captured
anyone have any tips. I have read:
http://www.sphinx-doc.org/en/master/man/sphinx-build.html
http://www.sphinx-doc.org/en/master/devguide.html#debugging-tips
I have a problem where I would like to expose the node structure and introspect the object at a specific point in time.

@FelipeMaldonado specifically I would like to inspect the node object while executing visit_only().

@NickSifniotis if you had a spare minute - do you remember how you inspected the node object?

I think we need to integrate with sphinx.util.logging but not sure how this works. I have tried setting
logger = logging.getLogger("sphinx")

and then issuing messages using logger.info(<msg>) but this doesn't work.

this has been resolved. I was trying to raise an exception in an element of the document that was parsed during transform phase and therefore was already handled prior to Writer phase in Sphinx.


feat: FIX GET/POST errors when using 1811 (GH-2705)

Closes GH-2705

Note: the multiple calls is being fixed in GH-2589


Include more details in the ApiConnectionException message

Closes #313
Improves the message included in an ApiConnectionException to include all the information that is passed into the exception constructor, instead of just the response from the server.
Also adds the URL that resulted in the exception, resulting in a stack trace that looks like this:
Traceback (most recent call last):
  File "C:\Users\<username>\AppData\Roaming\JetBrains\PyCharm2022.2\scratches\scratch_5.py", line 6, in <module>
    conn = ApiClientFactory(api_url=url).with_credentials(**creds).connect()
  File "C:\git\pyansys\openapi-common\src\ansys\openapi\common\_session.py", line 213, in with_credentials
    if self.__test_connection():
  File "C:\git\pyansys\openapi-common\src\ansys\openapi\common\_session.py", line 317, in __test_connection
    raise ApiConnectionException(
ansys.openapi.common._exceptions.ApiConnectionException: Request url 'http://hostname/invalid/path' failed with reason 404: Not Found.
The following was returned by the server:
<!DOCTYPE html>
<html>
...

In some cases the content returned by the server would have been enough to figure out the cause of the issue, but not always. We now always raise an exception with at least the following:

url
status code
reason phrase

If any content was returned by the server, it is also included in the exception.

Renaming message to content is a breaking change that will affect private packages

Renaming message to content is a breaking change that will affect private packages

That's a very good point. We could leave it as 'message', but it will be a bit confusing that it essentially repurposes the base exception keyword argument.
We might not have a choice though. I might argue that there are no actual packages that are using ApiConnectionException right now (BomAnalytics uses ApiException, am I missing anything?), but that's not really good enough if we're obeying our versioning rules.

Changes should now be non-breaking. I haven't added the actual response object to the exception itself, my rationale being that it's another arg (that in reality could replace 3 of them, but not if we want a non-breaking change), and that if you're actually trying to fix the issue, it's trivial to just step up one level in the call stack to see what the problem is.

After further discussion/thinking, we've decided to go ahead with breaking changes, and the response object is now the only thing passed to the exception. Extraction of relevant information is now handled in the exception itself.


Switched to the more performant System.Threading.Lock on .NET 9.0+

Summary by CodeRabbit

New Features

Introduced a new package reference for Cuemon.Extensions.Threading, enhancing threading capabilities.

Improvements

Updated locking mechanisms for improved thread safety in the initialization and converter dependency management processes.

Bug Fixes

Adjusted the language version to a preview, allowing access to the latest language features.

Style

Reformatted project files for consistency in indentation.

Thank you for your contribution to this project. For a static Bootstrapper, I do not see the advantages using a Lock vs traditional locking.


Removed fall-back as it is hidning errors happening in the program class

The problem is decribed here:
https://stackoverflow.com/questions/66710156/why-do-nswag-fail-on-my-computer-and-not-on-my-colleagues-for-the-same-c-sharp-p

build error


Updates eslint

ESLint file cleanup.
Additions

Adds align: value property to key-spacing rule, which left-aligns values of properties in an object literal declaration.

Changes

Generalizes comments to describe the rule not the state of the rule.

Review

@ascott1
@wpears
@mistergone

:+1: Looks great. Thanks @anselmbradford


feature: Multiple indices in EntityStore

edit: I just realized, this isn't the best example, because you could already have the needed index in the tags EntityState. But you get the gist.
Example: you might want to look up items by a tag that's attached to it. Say we have an EntityStore with items where each item can have one or several tags (by id, assume a normalized state).
const items = [
  {id:1, tags: [1, 2]},
  {id:2, tags: [1]}
  {id:3, tags: [2, 3]}
];

The resulting State looks like this:
{
  entities: {
    1: {id:1, tags: [1, 2]},
    2: {id:2, tags: [1]}
    3: {id:3, tags: [2, 3]}
  },
  ids: [1,2,3]
}

Filtering or finding items by tag is cumbersome and slow. It'd be nice to get the possibility of indexing items by one or more keys different from id to get a state similar to this one:
{
  entities: {
    1: {id:1, tags: [1, 2]},
    2: {id:2, tags: [1]}
    3: {id:3, tags: [2, 3]}
  },
  entitiesByTag: {
    1: [1, 2], // just the ids for brevity, actual entities should be here
    2: [1, 3],
    3: [3]
  },
  ids: [1,2,3]
}

Implementing this reactively isn't feasible as you'd have to either diff or reindex the entire thing on every state change.

Actually you can do it easily with the filterBy option:
selectAll({ filterBy: entity => entity.tags.includes(tagId) })

As for the performance, I don't think there should be a significant problem. Browsers are highly optimized when it comes to for loops. Did you experience a performance issue?

Thanks. You are right, this might be a case of premature optimization. It does have its place though, when you handle larger amounts of normalized data, especially on less powerful clients.

Agree, but I think it's hard to develop something that will satisfy all cases.

There's Relational Pouch so if the store is persisted to pouchdb it might be a good solution performance wise.  Hoping to get time to play with it soon.


[BUG] Strange tooltip behavior via using onClickFunction and tooltipTextFunction

Problem:
Using both onClickFunction and tooltipTextFunction, you can see some strange behavior of tooltip: sometimes it persists after hover ends, sometimes it displays in the wrong place, sometimes it acts onClick nor hover, etc.  Removing any1 of these props solves problem.

Sorry everyone, I have been away doing my Masters and working full time. I am going to get back to this starting tomorrow. Thanks for your patience. -Yams

I found out that this is related to whether the return value of the tooltipTextFunction is reused between countries - if the value is used as tooltip  text is used in more than one country, then this glitch happens. If every country displays different text, it works fine. For me and for now, my workaround is to include the country name in each tooltip.


Needing workaround for subprocess in signed application bundle

I'm trying to use this library from a PyInstaller-built binary aw-notify running as a subprocess in my application.
The whole thing is correctly signed with PyInstaller (see spec file). The CFBundleExecutable is aw-qt, which manages aw-notify as a subprocess.
However, the subprocess doesn't seem to get NSBundle.mainBundle.bundleIdentifier set. Which fails the check at:
https://github.com/samschott/desktop-notifier/blob/233d8c8981945c64fb92df2dbade908624896b7b/src/desktop_notifier/macos_support.py#L55C11-L55C11
@samschott wrote here:

The alternative would be to try and fake a valid bundle identifier at runtime. Some other packages do this but its a nasty hack and will prevent any apps using it from being accepted in the App store.

I am now assuming that I would need some kind of workaround like that, and that things would probably work if it wasn't for this NSBundle check (hopeful/wishful thinking).
Since the testing process is rather lengthy for me, given how I have to wait for CI to sign etc, I thought I'd make this issue before I venture further. I've only done a little bit of research on this, and am not sure if I'm likely to meet further resistance once I've worked around the bundleIdentifier check.

Sorry for not getting to this earlier. If this is still an issue:
NSBundle.mainBundle should indeed return the bundle that the aw-notify is contained in, but maybe checking for the presence of a bundle identifier is indeed too hard of a requirement.
If you remove those checks all-together from https://github.com/samschott/desktop-notifier/blob/233d8c8981945c64fb92df2dbade908624896b7b/src/desktop_notifier/main.py#L73, do you get a segfault when initialising DesktopNotifier in your bundled app? If not, it suggests that at least some of those checks are not required.
If it does segfault, the underlying problem lies likely in how PyInstaller bundles your executables into an app.

I am not at all familiar with PyInstaller and how it would bundle multiple executables, and Apple's documentation on which type of executables are allowed to send desktop notifications is also scarce.
If bundling is indeed the issue: The typical approach would be to include a full helper app nested in your app bundle (Chrome does this for example with "Google Chrome Helper (Alerts).app", so does the Sparkle update framework). Standalone signed executables are more common as command line tools or helpers, as described at https://developer.apple.com/documentation/xcode/embedding-a-helper-tool-in-a-sandboxed-app, and I would not be completely surprised if those are not allowed to send notifications.

_ I would not be completely surprised if those are not allowed to send notifications._

i'm actually using this package right now from an embedded helper app inside another bundle and it's working fine so i can confirm this isn't the issue... though in order to get it to work (to get the whole app bundle, not just this package) i had to manually handle all the codesigning, including manually resigning a bunch of compiled python libraries and the python executable after i packaged it up with briefcase which is similar to pyinstaller.
You set the bundle ID when you code sign. Also according to some of apple's docs on embedded apps it is important that the embedded app have a bundle id that's an extension of the one it's embedded into. their example:

main bundle id: com.example.apple-samplecode.AppWithTool
embedded app com.example.apple-samplecode.AppWithTool.ToolX

i don't know if that actually matters bc i did it the way apple suggested from the jump but it's definitely something to try.


Can I disable hot corners and keep only kbd shortcuts?

Obviously, this is just a suggestion.
My mouse movement is kind of erratic, so disabling hot corners will be good for me.
I already changed these settings:
# Width and height of a hot-corner area within the edge corners (0 - 100).
#edge_corner_size = 10
edge_corner_size = 0

# Width or height of a hot-corner area within the edge centers (0 - 100).
#edge_center_size = 100
edge_center_size = 0

Maybe a config setting can help me...

You can disable some/all corner events by setting an empty string. e.g.:
# Corner at top center.
top_center = ""

# Corner at center right.
center_right = ""

# Corner at bottom center.
bottom_center = ""

# Corner at center left.
center_left = ""

will disable all the layout change events.

Thank you! And congratulations on this great project!


Lessons to be taken from channels in Go?

I'd like to take a step back and challenge some of the core design decisions in crossbeam-channel, std::sync::mpsc and futures::sync::mpsc.
Motivation: select! for crossbeam-channel is hard to get right
The current select_loop! macro is kinda silly (it's a loop, you can't use break/continue inside it, it causes potentially subtle side effects on every iteration). I'm trying to come up with a new, nicer macro, with fewer surprises, and without the implicit loop.
This is what seems like the best solution so far:
select! {
    recv(receiver, msg)     => {} // `msg` is of type `T`
    send(sender, foo + bar) => {} // sends message `foo + bar`
    closed(receiver)        => {} // fires when `receiver` is closed
    closed(sender)          => {} // fires when `sender` is closed
    default(timeout)        => {} // fires when `timeout` expires
}

And this is how it works:

If any of the recv or send cases can complete without blocking, a random one is chosen. The chosen operation is executed and its block (in this example {} for simplicity) is evaluated.
If any of the closed cases are ready (because a channel is closed), it is evaluated.
If the timeout has expired, the default case is evaluated.
Otherwise, we wait until something changes.

Pros:

No surprises (apart from the complexity) - it behaves just as one would expect.
Very flexible - allows a lot of freedom in choosing how to react to channel events.

Cons:

Using a recv or a send case doesn't nudge you into handling the closed case. For example, this is in contrast to a bare Receiver::recv operation, which returns a Result so the compiler advises you to do something with it (like call .unwrap()).
The macro looks kind of complicated.
Internal implementation is a little challenging (although not too bad).

There were some other different ideas for the macro but I won't go there.
Folks from Servo (more concretely, @SimonSapin and @nox) were cool with this macro idea, although it wasn't the absolute best option for their use case.
@matthieu-m had a good point that the select! macro should ideally be exhaustive in the sense that it makes sure you don't forget edge cases like a channel being unexpectedly closed.
Now let's see if we can somehow force the user to handle the closed case for every recv and send. One idea is to change recv so that it returns a Result<T, RecvError>:
select! {
    recv(receiver, msg) => {
        match msg {
            Ok(m) => println!("got {:?}", m),
            Err(RecvError) => println!("the channel is closed"),
        }
    }
}

But what about the send case? Here's a try:
let mut greeting = String::new("Howdy!");
select! {
    send(sender, greeting, result) => {
        match result {
            Ok(()) => println!("successfully sent"),
            Err(SendError(m)) => greeting = m,
        }
    }
}

That'd work and eliminate the need for closed case, but it doesn't look very nice. To be fair, users of this select! syntax would typically just raise a panic on 'closed' events:
let mut greeting = String::new("Howdy!");
select! {
    recv(receiver, msg) => {
        let m = msg.expect("the channel is closed");
        println!("got {:?}", m),
    }
    send(sender, greeting, result) => {
        result.expect("the channel is closed");
    }
}

Looks a bit better, but still kind of clumsy.
When does a channel become closed/disconnected?
Depends on the implementation.

In std::sync::mpsc: when either the Receiver or all Senders get dropped.
In crossbeam-channel: when either all Receivers or all Senders get dropped.
In futures::sync::mpsc: when either the Receiver or all Senders get dropped, or when you call Receiver::close.
In chan: when all Senders get dropped.
In Go: when you call close(sender). It is not possible to close from the receiver side.

These differences are important. The chan crate follows Go's model very closely so they have very similar behavior. The reason why Go allows closing from the sender side is because it follows the principle of unidirectionality.
Unidirectionality means that information flows in one direction only. Closing a channel signals to the receivers that no more messages will arrive, ever. Note that even if all receivers get dropped, sending into the channel works as usual. The whole idea is that receiver side cannot signal anything to the sender side!
Why do we want unidirectionality? See this and this comment by Russ Cox for an explanation.
  See Channel Axioms and Curious Channels by Dave Cheney. The controversial blog post titled Go channels are bad and you should feel bad is worth a read, too, despite the title.
Here are a few interesting rules:

Sending into a closed channel panics. The idea is that senders have to coordinate among themselves so that the last sender closes the channel.

Receiving from a closed channel returns a 'zero value'. This is like returning None, but Go doesn't have sum types.

Sending into a nil channel blocks forever. This is handy when you want to disable a send operation inside a select - just set the sender to nil!

Receiving from a nil channel blocks forever. This is useful for the same reason the previous rule is. See this StackOverflow answer for an example.

How would we port Go's channels to Rust
Let's solve some of the quirks in Go's channels by using two useful language features of Rust: destructors and sum types.
Keeping the idea of unidirectionality, we change the disconnection behavior: channel gets closed only when all Senders get dropped. That's it. This means sending into a channel cannot panic because having a sender implies the channel is not closed. Next, receiving from a closed channel returns an Option<T> rather than a 'zero value'. The chan crate follows the same design - see here and here.
I'm feeling very tempted to redesign crossbeam-channel around the philosophy of Go channels:
impl<T> Sender<T> {
    fn send(&self, msg: T);
}

impl<T> Receiver<T> {
    fn recv(&self) -> Option<T>; // `None` if closed.
}

let greeting = String::new("Howdy!");
select! {
    recv(receiver, msg) => {
        // `msg` is of type `None`
        let m = msg.expect("the channel is closed");
        println!("got {}", m);
    }
    send(sender, greeting) => {
        println!("successfully sent");
    }
    default(timeout) => println!("timed out!"),
}

This is beautifully simple:

Easy to understand, especially for programmers coming from the world of Go.
No need for those annoying unwraps in sender.send(foo).unwrap(). @BurntSushi is going to like this. :)
select! macro doesn't need the closed case.
You're advised to handle the possibility of the channel being closed in the recv case. Perhaps we might want to change the Option type to Result.

Some drawbacks:

Dropping all receivers doesn't prevent senders from sending. This might or might not be a drawback - we could argue both ways.
select! is not as powerful as before. But it probably doesn't matter since all real-world cases should be covered by this simpler version.

Note that we could also accept Option<Sender<T>> and Option<Receiver<T>> in the recv and send cases. That would be equivalent to using nil channels in Go.
We can get all the benefits of Go channels without its weak spots like accidental panics (e.g. sending into a closed channel), accidental deadlocks (e.g. receiving from a nil channel), and incorrect closing (we close automatically when the last Sender gets dropped).
Final words
The simple Go-like channel interface currently seems to me to be sitting in some kind of sweet spot of the design space. I've been thinking about this problem for way too long now, constantly switching from one idea to another. In the end, I'm not sure whether this one is the way to go and need your opinion.
Any thoughts?
cc @arcnmx - you might be interested in this comment, too.

To answer this comment from @danburkert:
I cannot dispute any of your points - they all seem fair. In particular, Sender::close() does seem like a useful method. Regarding Sender::send(), I understand the concern, but then again, @BurntSushi (and many others, I'd wager) would probably disagree.
Currently, the main goal of crossbeam-channel is to be a sort of a 'mega-channel' that can do pretty much anything and doesn't impose any artificial restrictions on the user.

I think I'd like to hear more argumentation about why unidirectionality is a desirable property rather than merely a sensible one.
From the link:

There almost always need to be two steps in a cancellation: a request for the cancellation and an acknowledgement that work has in fact stopped. Close can serve as the latter; it cannot serve as both, and we make it as hard as possible for people to do that accidentally.

Maybe somebody can elaborate on what this means and why? It seems to me that the receiver doing a close() followed by the sender detecting the failure of its send and reacting appropriately could serve as those two steps, at least under one way of interpreting them. (Is the "cannot serve as both" claim only intended to be true within the context of Go, e.g. because it happens to have no way to detect the failure of a send, or is it something more fundamental?)
And as a potential counterpoint to unidirectionality: I'm sure many of us have noticed the symmetry between:
impl Sender<T> {
    fn send(&self, value: T) -> Result<(), T>;
}
impl Receiver<T> {
    fn recv(&self) -> Result<T, ()>; // could be thought of as having `value: ()`!
}

It's almost as if these can be generalized to:
struct Endpoint<A, B> { ... }
impl Endpoint<A, B> {
    fn new() -> (Endpoint<A, B>, Endpoint<B, A>);
    fn rendezvous(&self, value: A) -> Result<B, A>;
}
type Sender<T> = Endpoint<T, ()>;
type Receiver<T> = Endpoint<(), T>;

Which is what OCaml is thinking about doing. Of course, as I meant to imply with the name there, this only makes sense for 0-buffered channels. But, at least, it suggests to me that bidirectionality can also be a sensible property.

I think I'd like to hear more argumentation about why unidirectionality is a desirable property rather than merely a sensible one.

Unidirectionality is strictly less powerful than bidirectionality, so one can only argue for it from the standpoint of simplicity and ergonomics.
Unidirectionality makes selection straightforward. Any operation declared inside a select will behave exactly as if it was a standalone operation (outside select). No surprises there.
With bidirectional closing, however, we have to introduce a special closed case in select, which will not be automatically enforced, unfortunately. Alternatively, we must reach for more complicated variants of recv and send cases, which adds a considerable penalty on ergonomics.
In one sentence, unidirectionality makes the interface smaller, simpler, and more consistent (in terms of select vs standalone operations, at least).

Maybe somebody can elaborate on what this means and why? It seems to me that the receiver doing a close() followed by the sender detecting the failure of its send and reacting appropriately could serve as those two steps, at least under one way of interpreting them.

My understanding is that in Go this is simply considered an antipattern.
If any send operation can fail, that means most users will just ignore the error and prefer to panic instead. Basically every use of channels in Rust is littered with .unwrap()s, which sometimes looks silly. This is reminding of tedious .unwrap()s one has to write after locking a Mutex, which prompted some people to create Result-free Mutexes as in antidote. parking_lot decided to do away with Results, too. The chan crate sends into a channel without a Result, too.
Also, signalling to the sender that the receiver is shutting down is not hard to do using a 0-capacity channel anyway, and may lead to cleaner design. At least the Go team believes so.
Finally, it's interesting to ponder how one would actually implement closing a channel. In Go, each channel is wrapped into a single mutex so there's a closed: bool flag in there, but what if we had a lock-free queue and no mutexes behind the scenes? While it's tempting to use a closed: AtomicBool flag, that would be wrong and cause linearizability issues. Instead, a close operation in crossbeam-channel marks a bit of the sender index.
Note that close a channel is literally a synonym for freeze the sending side. Since closing a channel is only concerned with the sending side, perhaps only the sending side should be allowed to close? The answer to this question probably depends on whether your mental model of a channel is a simple queue or like a unix pipe where both sides can signal closing.

(Is the "cannot serve as both" claim only intended to be true within the context of Go, e.g. because it happens to have no way to detect the failure of a send, or is it something more fundamental?)

While Go doesn't have a way to detect failure of a send operation, they could've easily implemented this feature (e.g. ok := channel <- msg). To omit the feature was a deliberate decision.

Which is what OCaml is thinking about doing. Of course, as I meant to imply with the name there, this only makes sense for 0-buffered channels. But, at least, it suggests to me that bidirectionality can also be a sensible property.

This is an interesting example. Indeed, the symmetry is beautiful. However... :)
I've done a lot of research on queues and channels in other languages and libraries. They will often boast about performance, features, and so on. The rosy story always falls apart when it comes to select. Go is the only language where channel selection is simple, easy, and just works. Many channel implementations don't have any kind of selection at all! Let's take a look at the mpsc_select feature in Rust as an example. The macro has fragile syntax (poor compilation errors), only accepts receive operations (no sends!), and has seen no progress in years. The macro will is basically deprecated (see here and at this point it is only kept alive because Servo still depends on it.
The chan crate is an alternative that sacrifices performance, but provides a nice Go-like interface with proper chan_select! macro. Apart from a few quirks and bad performance, it works very well. In 2015, a request for adding a send operation returning a Result was submitted. @BurntSushi was originally hesitating:

The second design decision I made was, "sending a value that can never be received is either a bug or an intentional leak." This may be a bad decision, but it is one that has a large body of evidence that suggests it may not be a horrible idea. (e.g., Go.) The idea here is too encourage users of chan to write code that doesn't enter that state. I was motivated to do things this way because so many uses of the std::sync::mpsc channel are tx.send(...).unwrap(). In other words, it makes the common case verbose.

In the end, he was sold on the feature request and decided to implemented the non-panicking send method. However, it turned out that fitting the concept of non-panicking send into chan_select! was a very difficult design problem, and that's where the story ends.
crossbeam-channel is a successor to chan and std::sync::mpsc. I've put a lot more time and effort into its development and managed to overcome some key difficulties other channels have run into. However, when it comes to selection, now I'm facing the infamous selection problem. There seem to be only two ways forward:

Keep the std::sync::mpsc-like design and implement a complicated select!.

Take a more opinionated stance and implement chan/Go-like channels with simple select!.

@stjepang It was a joy reading your comments in this thread, and I can definitely identify with your toil. However, when I wrote chan, I took a b-line straight to what I knew worked: Go's channels. I didn't even come close to exploring the design space as thoroughly as you have. Speaking as someone who has written Go for a very long time, and worked with others that have written Go, its channel implementation has been a raging success from my perspective. There are lots of downsides (all of which you are clearly aware of), but it works well. So with that said, I think my vote would be towards being opinionated. The reasoning is simple: select is the single most important aspect of an ergonomic channel implementation, and if people have trouble using it, it's always going to compare unfavorably to other choices (like Go's).
One thing that came up towards the end of https://github.com/BurntSushi/chan/issues/2 was what to do when a channel send occurs on a non-closed channel that is guaranteed to never be received. chan today will lock forever, which is what Go will do. However, it seems possible that you could panic in that case, and indeed, if Go's runtime detects that no goroutine will make progress, it will actually panic because it effectively detected a deadlock. To keep select simple, you could simply not expose this panic at all and keep the send() -> () type signature.

After thinking for a longer moment about send() failure, I think bi-directionality is weirder than I initially thought.
I have used (distributed) queuing systems quite extensively for nigh on 5 years at my previous job: I was actually developing the middleware applications on top of them, which were used among other things to... make sure that the luggage you drop at the departure airport arrives at destination. One of the most important properties of our queuing systems was to never lose an item. A queue which acknowledges an item but fails to deliver it was buggy, plain and simple.
Which is why closing from the receiving side is slightly weird. Even if the senders immediately stop sending, what of all the items in flight?
To design a queue which does not lose items, the receiving side must "request" a close, and then continue processing until it is guaranteed that no other item will be enqueued. This is easily implemented if the queue is locked for each send/receive, but faster implementations are preferred, and then things become racy.
And suddenly, we seem very close to the unidirectionality advocated by Go: the receiver may only signal an intent, the senders decide when to stop.
Also, note that an absence of receiver should not necessarily fatal. That is, even if the receiver dies (unexpected data in the queue causes a panic which unwinds the thread), it may be desirable to have the ability to spawn a new receiver to continue processing. Being able to use the current queue (already wired in on the sender side, already containing some non-processed items) is quite desirable then.

@BurntSushi

One thing that came up towards the end of https://github.com/BurntSushi/chan/issues/2 was what to do when a channel send occurs on a non-closed channel that is guaranteed to never be received. chan today will lock forever, which is what Go will do. However, it seems possible that you could panic in that case, and indeed, if Go's runtime detects that no goroutine will make progress, it will actually panic because it effectively detected a deadlock. To keep select simple, you could simply not expose this panic at all and keep the send() -> () type signature.

I like this idea. So basically when sending into a bounded channel that is full and has no receivers left, rather than waiting forever, we panic with an appropriate message. Sounds good to me! We could do something similar in select!, too.
By the way, I'm sure you know the pains of dealing with poor error messages due to trivial mistakes in macros. Well, you're going to like this. :)
An example:
select! {
    recv(r, msg) => msg,
    send(s, 1 + 2) => println!("sent")
    default(timeout) => ()
}

Error message:
error: did you mean to put a comma after `println!("sent")`?

The new macro seems to give a sensible message no matter what kind of mistake I try planting in there, and isn't nitpicky about things like trailing commas. I'm pleasantly surprised to discover that macros can be so friendly at all!
@matthieu-m
Thank you for the comment! This is a very compelling argument in favor of Go-like channels, in my opinion. I find the parts about draining the remaining messages and spawning a new receiver pretty convincing.
In the end, reacting to the automatic close signal when all receivers go away is probably not the most robust way of shutting down anyway. I think this is the key point Russ Cox was trying to get across in his comments.
I'd just like to add a demonstration of how it's still easy to implement a signal in the backwards direction if one needs it:
let (sender, receiver) = channel::unbounded();
let (signal, done) = channel::bounded(0);

// The producer thread.
thread::spawn(move || {
    while !done.is_closed() {
        select! {
            recv(done) => break,
            send(sender, generate_message()) => (),
        }
    }
    // Do something with the remaining messages.
    // Maybe spawn a new worker thread?
});

// The worker thread.
thread::spawn(move || {
    let signal = signal; // Will get dropped when this thread exits.

    for msg in receiver {
        if process_message(msg).is_err() {
            // Something went wrong. Shut down.
            break;
        }
    }
}

@danburkert

The receiver keeps receiving buffered items until there are no more, at which point further calls to recv indicate that the channel has been closed.

This confuses me, too. Perhaps @matthieu-m meant to write the following?
Which is why closing from the receiving side is slightly weird. Even if the receivers immediately stop receiving, what of all the items in flight?

By the way, I'm sure you know the pains of dealing with poor error messages due to trivial mistakes in macros. Well, you're going to like this. :)

Wow. I had no idea that was possible. :heart_eyes:

@BurntSushi considering that I sent a pull request like 5 months ago that does the same thing for chan... Idk. I just thought you might have at least looked at the PR at some point. :/
@stjepang after reading all of this discussion and thinking about it, I'm starting to lean towards the opinionated, unidirectional channel interface, even though I would have said it makes sense for the receiver to be able to close the channel. The one question I have with that: what happens if the receiver thread panics? Does the sender just keep adding items to the channel's buffer? As @matthieu-m said, losing the items in flight would not be good, but I'm not sure how you would approach creating a new receiver into the same channel from a dead thread, from an API perspective.

considering that I sent a pull request like 5 months ago that does the same thing for chan... Idk. I just hoped you might have at least looked at the PR at some point. :/ oh well.

Sorry, but with the volume of PRs/emails I get that are blocked personally on me, some of them just fall through the cracks. PRs that touch write-once code that I no longer understand naturally go to the bottom of my list, and are often forgotten about unless someone makes noise. It's just the way it is.

@coder543

but I'm not sure how you would approach creating a new receiver into the same channel from a dead thread, from an API perspective. If there is a solution, that would be interesting to see.

Perhaps something like this?
fn producer(chan: Channel, ) {
    let (s, r) = bounded(BUFFER);
    let (alive, mut dead) = bounded(0);
    let mut t = thread::spawn(consumer(r.clone(), alive));

    while !finished() {
        let msg = produce_message();

        select! {
            send(s, msg) => {}
            recv(dead, _) => {
                let (alive, d) = bounded(0);
                dead = d;
                t = thread::spawn(consumer(r.clone(), alive));
            }
        }
    }

    drop(r);
    t.join().ok();
}

fn consumer(r: Receiver<Message>, alive: Sender<()>) {
    for msg in r {
        consume_message(msg); // may panic
    }
}