Sluggable tables won't generate unique slugs.

If a record is created with a NULL slug that would otherwise conflict with another slug in the database (i.e. when you add the "sluggable" behavior to an existing dataset.), a unique slug will never be stored unless it is explicitly defined.
This code WILL create a new slug on a record whose slug is NULL, UNLESS that record's slug conflicts with another record.
$entity = MyEntityQuery::create()->findOne();
$entity->save();

Found out why the slug isn't being updated. See #981.

Pretty sure I've got this one figured out. PR pending feedback #981.

PR open. Just needs to get finished and merged.


SEO Optimization

@anuragverma108
Enhance SEO practices by optimizing meta tags, descriptions, and content for better visibility on search engines.
I can suggest few methods to optimise the SEO and tools.
I am participating in Hactoberfest for first time hope so I can give optimised solution.

Thanks for creating the issue in WildGuard! The issue has been assigned to you.
Before you start working on your PR, please make sure to:

⭐ Star the repository if you haven't already.
Pull the latest changes to avoid any merge conflicts.
Attach before & after screenshots in your PR for clarity.

We're excited to see your contribution as part of Hacktoberfest 2024! 🎉
Don't forget to follow me on GitHub for more updates.
Happy open-source contributing! 🚀


Sound crackles

Environment: PC, UE
I came across a peculiar problem where a packaged UE project with Steam Audio runs fine on multiple testers' machines, but one person experienced voice crackling which sounded like sample rate/ driver problem to me.
https://github.com/user-attachments/assets/3142085b-afa1-45af-b1a9-125f3385ba4a
(This is Play In Editor but I tried sending him a packaged build that worked on my end but same issue on his)
The weird thing is that while the reverbs through SA is problematic, the zombie sounds in the game was fine (they're ran through Wwise and didn't touch SA), and the person isn't using any audio interfaces and special audio programs. How could I go about debugging this?

restart pc


allow to use testing-environment like http://s3ninja.net/ / allow to set url

For local development, it makes sense to have a test-environement, instead of a real s3.
http://s3ninja.net/ provides such a test environement. For that you just need to change the url to point to your local test-server. How can you do that in slingshot?

I'm having the same problem, I want to use a different url than amazons. The only way I currently see is to rewrite aws-s3.js.

Did you have a solution for that reason


Support spatialJoin when the join clause contains unequal conditions

Expected behavior
Support spatialJoin when the join clause contains unequal conditions
Actual behavior
When there are spatial relationship conditions and non equivalence conditions in the join clause, spatialjoin is not effective and BroadcastNestedLoopJoin is used
Steps to reproduce the problem
Settings
Sedona version = 1.4.0
Apache Spark version = 3.3.0
Apache Flink version = ?
API type = Scala
Scala version = 2.12
JRE version = 1.8
Python version = ?
Environment = Standalone

Can you provide an example query to reproduce this problem? I've tried queries like this and it was planned as a RangeJoin.
SELECT * FROM df1 JOIN df2 ON ST_Contains(df1.geom, df2.geom) AND df1.dist > df2.dist

Like this，
SELECT a.*
FROM a
JOIN b ON st_contains(a.geometry, b.geometry)
JOIN c ON st_contains(b.geometry, c.geometry)
WHERE a.id !=b.id
  AND b.id != c.id


Cleaned branch

@Abby-Wheelis Adding only the relevant files here. Please let me know if anything is amiss.

@rahulkulhalli please do not remove files that you haven't touched. I cannot merge this PR; it will remove files that we need for the public dashboard. It also has merge conflicts on every single file. If you haven't touched any files, please just have them be unchanged. They will not show up in the PR


Migrate msal-browser VanillaJS tests from mocha to jest

Changes:

Migrate VanillaJS tests from mocha to jest
Bind ports dynamically for SAMPLE_HOME_URL.
Derive instance of browser from e2eTestUtils instead of instantiating it manually.
Split customizable-e2e-test test suite to avoid concurrent updates on testConfig.json file.
Remove @babel/* and mocha dev dependencies.
Remove mocha testRunner.

Split customizable-e2e-test test suite to avoid concurrent updates on testConfig.json file.

Regarding this point: the "customizable" aspect was that it was 1 sample that could test many different scenarios. The benefit being when we needed to make an update to the sample we only had to make that update in one place rather than for each individual scenario. I'd prefer to keep that pattern, in fact I'd love it if we could roll some of the other samples into this one as well (not in this PR necessarily but that's my personal sample app north star).
The idea I had to make this work was to serve each "scenario" on a separate route that could be used in the relevant test (i.e. http://localhost:3600/localStorage). This is roughly what we did in the React samples and it's worked pretty well. Given that's a bit more work than what this PR aims to address, an interim solution to your concurrency problem would be to configure Jest to not run tests concurrently for now. Thoughts?

Split customizable-e2e-test test suite to avoid concurrent updates on testConfig.json file.

Regarding this point: the "customizable" aspect was that it was 1 sample that could test many different scenarios. The benefit being when we needed to make an update to the sample we only had to make that update in one place rather than for each individual scenario. I'd prefer to keep that pattern, in fact I'd love it if we could roll some of the other samples into this one as well (not in this PR necessarily but that's my personal sample app north star).
The idea I had to make this work was to serve each "scenario" on a separate route that could be used in the relevant test (i.e. http://localhost:3600/localStorage). This is roughly what we did in the React samples and it's worked pretty well. Given that's a bit more work than what this PR aims to address, an interim solution to your concurrency problem would be to configure Jest to not run tests concurrently for now. Thoughts?

Makes sense to me. I am fine with keeping customizable test suite intact and running the whole test suite with --runInBand flag enabled. That was my initial approach actually. However, the huge downside would be that tests will take 3+ times longer to complete: ~90 seconds against ~300 seconds. Can make a huge difference considering some of those tests are flaky.

Makes sense to me. I am fine with keeping customizable test suite intact and running the whole test suite with --runInBand flag enabled. That was my initial approach actually. However, the huge downside would be that tests will take 3+ times longer to complete: ~90 seconds against ~300 seconds. Can make a huge difference considering some of those tests are flaky.

I think I'm ok with that for now until we update the sample to properly support concurrency. Curious if anyone else has opinions

Makes sense to me. I am fine with keeping customizable test suite intact and running the whole test suite with --runInBand flag enabled. That was my initial approach actually. However, the huge downside would be that tests will take 3+ times longer to complete: ~90 seconds against ~300 seconds. Can make a huge difference considering some of those tests are flaky.

I think I'm ok with that for now until we update the sample to properly support concurrency. Curious if anyone else has opinions

Merged customizable-e2e-test back together since there were no additional comments from anyone else.


doubled color class selector, like important

#34 The goal of this branch is to increase lcars color selector specificity.
Reading a bit more, it is recommended that the selector simply repeat the same class name. That means it will match "twice as much" as any other color rule with only one class name or any element types.
I recommend we try this to see if it can be accepted into the project.

OK. I've tested this on desktop and mobile. Seems to be working as expected. Using double selector names is powerful. It takes selectors with three class name matches or any id to override color now. But is still reasonable. For the .button:active I doubled up 'button', even though it naturally had two matching classes for being both .lcars-element and .button. So now button :active matches 3-classes, 1-element match. The style inspector showed in some cases the browser gave pseudo states priority by forcing the pseudo class selector to be important, but I seen no reason to trust it.
Checked on
Firefox
Chromium
Mobile Chrome
Mobile Android webview

Fascinating. I was not aware of the technique, indeed I wasn't even aware of the concept of doubling the class selector as a valid selector expression at all. Good work, @xenziffen . For the convenience of more casual consumers, would you please perform the Stylus compile and commit that as well? I know its a bit messier in terms of diffs and PRs, but  the trade off is sort of works-as-advertised-out-of-the-box, even for folks who will just be grabbing the CSS and throwing away the Stylus.

Sure thing. Didn't know if you guys had a different process for builds in place, so I only touched what was necessary.
The cloned build is kinda annoying for me me. It's not using the latest Gulp 4, so I have to switch anytime I want to build in the branches from this project.
For my own stuff I refactor gulpfile.js to Gulp4 easy enough. But there's a pretty big breaking change between Gulp 3 and Gulp 4, having to do with callbacks for the serial and parallel setups Gulp4 requires. The question then is, should I maybe create the issue and a branch to update the gulpfile.js? Do you think upgrading Gulp is in the cards?

I have to admit that I'm totally new to gulp and the whole nodejs world, really. I'm glad you mentioned this. I wasn't aware of the obstacles. If gulp 4 is the future and has wide adoption, I would support that upgrade.
Let's pose the question to Jörn through a new issue. Would you create a new issue with that same explanation?

it looks like the color correction merge slightly collided with this PR. But the gulp upgrade should now be in place. would you rebase and commit to clear up the conflict ? I think we'll be in a place to merge this in.

I think we are really close to our first release. Would you merge/rebase from master, recompile the CSS and commit, @xenziffen ? This is a really excellent pull request, but some other commits that got in ahead of it created minor conflicts.

Hey Justin,
I'm just getting my environment setup again. Switched distros. So all that
is needed is someone to build the CSS files and check them in from a
repository that is down-tree from the previous accepted commits?
On Thu, Apr 16, 2020 at 10:27 AM Justin Warwick<EMAIL_ADDRESS>wrote:

I think we are really close to our first release. Would you merge/rebase
from master, recompile the CSS and commit, @xenziffen
https://github.com/xenziffen ? This is a really excellent pull request,
but some other commits that got in ahead of it created minor conflicts.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/joernweissenborn/lcars/pull/40#issuecomment-614788510,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AG3PFB7224FA7BQKFKWTV43RM45YHANCNFSM4K6NAODQ
.

Although I'm not totally familiar with that terminology, it's a descriptive
match for what I see in the conflict report. So I'll give a weak
"affirmative".
--Justin
On Fri, Apr 17, 2020, 16:46 xenziffen<EMAIL_ADDRESS>wrote:

Hey Justin,
I'm just getting my environment setup again. Switched distros. So all that
is needed is someone to build the CSS files and check them in from a
repository that is down-tree from the previous accepted commits?
On Thu, Apr 16, 2020 at 10:27 AM Justin Warwick<EMAIL_ADDRESS>wrote:

I think we are really close to our first release. Would you merge/rebase
from master, recompile the CSS and commit, @xenziffen
https://github.com/xenziffen ? This is a really excellent pull
request,
but some other commits that got in ahead of it created minor conflicts.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<
https://github.com/joernweissenborn/lcars/pull/40#issuecomment-614788510>,
or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/AG3PFB7224FA7BQKFKWTV43RM45YHANCNFSM4K6NAODQ
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/joernweissenborn/lcars/pull/40#issuecomment-615512804,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AALAR5FZCQVFNMVKFDBP2RLRNDS5JANCNFSM4K6NAODQ
.

I couldn't find the "right way" to just do this compile myself and commit to the PR. I was able to use the web interface to make direct edits to the conflicting files, though. The edits will clear the conflicts, but they will be slightly out of sync and not contain all the appropriate rules resulting from merge. But I think this is ok as a work around. I will just recompile in the course of a subsequent PR.


⚠ Processors has degraded performance

In 277d88d, Processors ($STATUS_URL) experienced degraded performance:

HTTP code: 200
Response time: 96 ms

Resolved: Processors performance has improved in 62e2390.


[bugfix] Pass the jobid when raising a 'JobError'

Fixes #1632

Hello @teojgo, Thank you for submitting the Pull Request!

In the file reframe/core/schedulers/slurm.py:

Line 435:80: E501 line too long (81 > 79 characters)

Do see the ReFrame Coding Style Guide

Codecov Report

Merging #1662 (8e91e94) into master (8134945) will not change coverage.
The diff coverage is 40.00%.

@@           Coverage Diff           @@
##           master    #1662   +/-   ##
=======================================
  Coverage   87.55%   87.55%
=======================================
  Files          45       45
  Lines        7494     7494
=======================================
  Hits         6561     6561
  Misses        933      933

Impacted Files
Coverage Δ

reframe/core/schedulers/slurm.py
53.91% <0.00%> (ø)

reframe/core/schedulers/pbs.py
47.94% <50.00%> (ø)

reframe/core/schedulers/__init__.py
97.77% <100.00%> (ø)

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 8134945...8e91e94. Read the comment docs.

@jenkins-cscs retry daint


WIP: Add Acario themes

WIP Status

[ ] The palette (especially the light one) is not totally over
[ ] 256-colors should probably only use color-xxx colors ? Unsure
[ ] No idea if there is something to do regarding treemacs et al.
[ ] Remove dependencies to the "central" acario-doom-themes package (only helper functions to switch between light and dark variants quickly and other settings)

Themes
These themes are my personal themes, going in pair to switch easily between the 2 styles.
Dark variant
The dark variant is a very dark blueish background with a pretty saturated palette for foreground colors.
The foreground palette is a little skewed towards blue as well
Light variant
The light variant is light cold background with a pretty saturated palette as well for foreground colors.
Specific highlights
I changed a lot of the magit faces, but I think I still need to work on those to finish the faces in hunks (apparently I forgot something)

I'm never merging this. This theme will never see the light. I'll merge this theme just to delete it before the next MELPA update. I'll prevent this theme from being seen from any other human being's eyes.
.
.
.
@gagbo just kidding, will you upload a couple of screenshots? also, could you test it outside of doom? I'm getting a reference to free variable ‘doom-serif-font’ error

I'll do the screenshots soon-ish :)
The free variable doom-serif-font is something I should work on as well (probably using a boundp)

Current versions look like this (elisp, Python, Rust and C++)

It looks awesome! I'm just not a fan of the modeline (It gives me anxiety jaja)

Yeah I don't like it either, I need to find something else for the modeline (active, and inactive)

I'd advise going for the classical lightened/darkened bg color for the modeline

This seems pretty ready to merge. Is it @gagbo?

Yeah I think it's pretty okay now, I won't have time to tweak it soon. Worst case PRs will come.
Quick screenshots with the more muted active modeline :

Perfect!


May require new example code

The current example code fails at run. Previous versions worked OK. The options don't seem to work properly.
Message 'ValueError: not enough values to unpack (expected 2, got 0)

the example is correct, the problem was that the user agent used is outdated and duckduck go blocked the requests, the user agent has been updated in v2.0.8, there the example should work again

i'll take a look

it seems that duckduckgo has made a change on how it works, for some reason you need to actually made a search on duckduckgo via your browser to made the example and all the other features work for some time, i'll be investigating what was this change to upload a fix, but in the meantine, before running your code, make a search on your browser on duckduckgo.

I am getting the same error messagem
type error:  not enough values to unpack (expected 2, got 0)
I did the search in duckduckgo via browser and it is working.

it seems that duckduckgo has made a change on how it works, for some reason you need to actually made a search on duckduckgo via your browser to made the example and all the other features work for some time, i'll be investigating what was this change to upload a fix, but in the meantine, before running your code, make a search on your browser on duckduckgo.

It does not help to search "kittens" in the browser to make the python api work. At least not in Colab.


Feature/nicolaswl/1016726271 passport auth

Administrative Info
Monday Board ID: 851212620
Changes
What changes did you make?

Implemented authentication using passport.js local and jwt strategies

Created a User model
Added a new /login route
Restructured backend to have a middleware directory that includes authentication logic
All routes now must be validated through passport (see note at end)

Created a login page based on the styles from the Community Kitchen project
Added logic to handle login request

POST to /login route
Added helper methods to manage JWT in local storage
Dynamically render navbar to have a logout button

NOTE ABOUT REQUESTS
All request must now be authenticated via jwt to work as they did before. This is as simple as adding the bearer token to the header of all requests (accessed via the helper methods)
Testing
How did you confirm your changes worked?

Created a test user in the database and used it to go through our new login/auth flow, logging and verifying each step

Confirmation of Change

Remove .DS_Store and backend/.DS_Store -- they are already in the .gitignore, but they need to be removed before that takes effect

Fixed the failing tests! One of you will have to check the redirect etc. still works as expected though


Fix data collision in caching in InferRequestWrapper

What does this PR do?
InferRequestWrapper collects inputs data and use dict tensor_cache to avoid extra data copying. Value of each item of inputs is converted to hash as hash(input_tensor.tobytes()), hash set as key of tensor_cache and deepcopy of value set as value. If inputs has several items with same tensor value, but different structure, for example {'input0': tensor([[11]]), 'input1': tensor([11])}, they would have same hash and one of this value would be collected with wrong shape. This pr fixes it.
Find and checked on https://github.com/openvinotoolkit/openvino_notebooks/blob/latest/notebooks/whisper-subtitles-generation/whisper-subtitles-generation.ipynb

Fixes # (issue)
Before submitting

[ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
[ ] Did you make sure to update the documentation with your changes?
[ ] Did you write any new necessary tests?

@eaidova  please, review

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.


Update Android target API level to 26

Google Play now gives me the following warning when I upload a new release for Android:

Target API level requirements from August 2018
Warning:
Your app currently targets API level 22 and must target at least API level 26 to ensure it is built on the latest APIs optimized for security and performance.
From August 2018, new apps must target at least Android 8.0 (API level 26).
From November 2018, app updates must target Android 8.0 (API level 26).

So we have a deadline of November -- but this is a bit of housekeeping it'd be good to do anytime. Updating means we'll adapt our app to use certain new APIs when on newer Android versions, in order to make friendlier use of system-level resources like permissions, notifications, and background execution. (This won't affect our ability to keep running on older versions.)
Detailed documentation here:
https://developer.android.com/distribute/best-practices/develop/target-sdk
The steps I'd follow to do this are

Go one version at a time, following that doc: level 23, then 24, then 26. (25 was a minor version.)
For each version, try bumping targetSdkVersion in android/app/build.gradle. Build the app and test manually, especially the areas called out in the upgrade docs.
Make any needed updates, following the docs.

A good PR to begin with would be an update to level 23, including any needed changes. For that one, we will need to make sure we request needed permissions at runtime. It's possible our dependencies take care of this; we'll need to check.

Hi! I am a newbie and I would like to work on this.

This will come along as part of upgrading to RN v0.56 (#2789).

does it mean existing app bellow target 26 will be band?

Targeting a higher API version simply means that we can take advantage of new stuff offered in it.
We do not have any immediate plans to reduce the Android versions we support (currently 4.4 and newer)

Tracking this in detail at #3075 ; closing this issue in favor of that one.


[Ziro] Can't View Playlist Without Album Art Showing

Describe the bug
When going to something like a playlist the current songs album cover takes up the area where the playlist and its songs would be.
To Reproduce
Steps to reproduce the behavior:

Go to any playlist/album or smilar

Screenshots
When clicked on playlist to view it:

Setup

OS: Windows 11
spicetify Version: 2.10.1
Spotify Version: <IP_ADDRESS>2.gf8d110e2

I forgot to disable an extension when switching between themes. 🤦


Foundaion for emails' files name are conflicted with Foundation for sites

The files name dist/foundation.css and dist/foundation.min.css of Foundation for emails are conflicted with Foundation for sites files when they are located in the same app's folder. Therefore, I would suggest to change them to:
dist/foundation-emails.css
dist/foundation-emails.min.css

Would you typically have these files in the same folder?

Added a v2.2 branch to commit features to!

I would appreciate it if you could review this #429

Thanks for the PR!


Can't craft some items

I'm using Too Many Items mod and I have noticed that I can't find some items there i.e scuba tank and universal cable, its small issue becouse I can craft them. On the other hand paxel is not craftable but I can get it from TMI

TMI? I don't notice this issue with NEI? A lot of the recipes are using a custom NEI crafting handler under Mekanism Shaped..

Right, Mekanism does not support TMI.


Fix portlet content alignment

Purpose
fix #235
Changes
Adjust the margin of the respective layouts such as OfferOverviewView and others

 Fix issue #235 (Portlet content alignment - fix margins and padding)

also fixes #215

nicely done, I'm glad it worked :)


compression in mongodb server

What is the default/recommended compression scheme for the MongoDB server, assuming we might run into space issue?

In our experience at NSLS-II the size of the data in mongo is small compared to the scale of the image data being collected.   The beamline with the most data in mongo at ~5 years of operation is ~250GB (not including the indexes).
@gwbischof has been looking at tools that will store compressed time series in mongo (this is related to the "event page" or "embedded" work at ,https://github.com/bluesky/suitcase-mongo/tree/master/suitcase/mongo_embedded) but I think that is more driven by making the reads faster rather than reducing disk space.
For the most part we suggest having AD write to a shared file system and putting resource/datum into the database.  If we want to move to a model where we are serializing "filled" documents into the database I think the compression question could be handled at "how do we serialize this blob to mongo" level or we should look at other technology (like https://github.com/TileDB-Inc/TileDB or hdf5) as the backing store.


thread: set mxcsr bit 6 DAZ to zero to disable denormals-are-zeros

Currently we are using mxcsr register settings with the bit 6 DAZ register
enabled. When the denormals-are-zeros flag is set, the processor
converts all denormal source operands to a zero with the sign
of the original operand before performing any computations on them.
It causes bugs in the SIMD XMM registers computation like #38646
I suggest to disable Denormals-Are-Zeros flag.
Fix will let all x86 boards perform SIMD computation using XMM
registers in the correct way.
Fixes #38646
Signed-off-by: Maksim Masalski<EMAIL_ADDRESS>

Looks reasonable.
It would be nice to add an x86 arch test that verifies this in the future.

Do we need to mask division-by-zero exception? Because I see Linux by default sets MXCSR to 0x1f80, it sets bit mask 9 ZM to 1.

Could we set the initialized value of mxcsr register as 0x1f80? because according to the sse initialization guideline in software developer manual section 11.6.4, it  set the initialized value of mxcsr registers as 0x1f80.

The SSE and SSE2 state is contained in the XMM and MXCSR registers. Upon a hardware reset of the processor, this
state is initialized as follows (see Table 11-2):
• All SIMD floating-point exceptions are masked (bits 7 through 12 of the MXCSR register is set to 1).
• All SIMD floating-point exception flags are cleared (bits 0 through 5 of the MXCSR register is set to 0).
• The rounding control is set to round-nearest (bits 13 and 14 of the MXCSR register are set to 00B).
• The flush-to-zero mode is disabled (bit 15 of the MXCSR register is set to 0).
• The denormals-are-zeros mode is disabled (bit 6 of the MXCSR register is set to 0). If the denormals-are-zeros
mode is not supported, this bit is reserved and will be set to 0 on initialization.
• Each of the XMM registers is cleared (set to all zeros).

Registers
Power-Up or Reset
INIT

XMM0 through XMM7
+0.0
Unchanged

MXCSR
1F80H
Unchanged

Do we need to mask division-by-zero exception? Because I see Linux by default sets MXCSR to 0x1f80, it sets bit mask 9 ZM to 1.

Although it may not necessarily be a bad idea to enable the divide-by-zero exception by default, from consistency perspective, we should mask it and set MXCSR to 0x1f80.
The rationale is as follows:

x86(-32) implementation does it:
https://github.com/zephyrproject-rtos/zephyr/blob/27f36bda51a68de8af542dbcda06e737a75aed1d/arch/x86/core/ia32/crt0.S#L277-L280
x87 FPU (in both x86-32 and x86-64 implementations) has all exceptions (including divide-by-zero) masked by default (note that fninit sets control word to 0x37f, which masks all exceptions):
https://github.com/zephyrproject-rtos/zephyr/blob/45bd3dee08ef9804fd4684ae20fde4e53af2c0f2/arch/x86/core/intel64/locore.S#L304


Updating the upgrade test file after fixing the typmod for CASE expression

Description
Updating the upgrade test file after fixing the typmod for CASE expression. Need to change the 15_9 schedule file in BABEL_4_X_DEV, as PR for 4_X is merged first, Which includes before files in
15_9 schedule file. But as these changes need to be merged in BABEL_3_X_DEV, we need to add after files in place of before files as 15_9 corresponds to BABEL_3_X_DEV.
Issues Resolved
BABEL_4_X_DEV code changes PR: https://github.com/babelfish-for-postgresql/babelfish_extensions/pull/2931
[List any issues this PR will resolve]
Test Scenarios Covered

Use case based -

Boundary conditions -

Arbitrary inputs -

Negative test cases -

Minor version upgrade tests -

Major version upgrade tests -

Performance tests -

Tooling impact -

Client tests -

Check List

[ ] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is under the terms of the Apache 2.0 and PostgreSQL licenses, and grant any person obtaining a copy of the contribution permission to relicense all or a portion of my contribution to the PostgreSQL License solely to contribute all or a portion of my contribution to the PostgreSQL open source project.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>4
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 74.487%

Totals

Change from base Build<PHONE_NUMBER>0:
0.0%

Covered Lines:
45159

Relevant Lines:
60627

💛  - Coveralls


Service to restart Home Assistant doesn't work

Home Assistant release (hass --version):
0.49
Python release (python3 --version):
3.4.2
Component/platform:
N/A
Description of problem:
When using "Service" as part of the "Developer Tools" to restart Home Assistant:
Domain: homeassistant
Service: restart
it doesn't restart.
sudo systemctl status<EMAIL_ADDRESS>-l provides:
●<EMAIL_ADDRESS>- Home Assistant
   Loaded: loaded<EMAIL_ADDRESS>enabled)
   Active: failed (Result: signal) since Mi 2017-07-19 23:11:36 CEST; 43s ago
  Process: 9211 ExecStart=/home/pi/.local/bin/hass (code=killed, signal=SEGV)
 Main PID: 9211 (code=killed, signal=SEGV)

Jul 19 23:11:34 smartmirror hass[9211]: 2017-07-19 23:11:34 INFO (MainThread) [homeassistant.core] Bus:Handling <Event service_executed[L]: service_call_id=1975496144-263>
Jul 19 23:11:34 smartmirror hass[9211]: 2017-07-19 23:11:34 INFO (MainThread) [homeassistant.core] Bus:Handling <Event homeassistant_stop[L]>
Jul 19 23:11:34 smartmirror hass[9211]: 2017-07-19 23:11:34 INFO (MainThread) [hbmqtt.broker] Broker closed
Jul 19 23:11:34 smartmirror hass[9211]: 2017-07-19 23:11:34 INFO (MainThread) [hbmqtt.broker] Listener 'default': 1 connections acquired
Jul 19 23:11:35 smartmirror hass[9211]: 2017-07-19 23:11:35 INFO (MainThread) [homeassistant.core] Bus:Handling <Event homeassistant_close[L]>
Jul 19 23:11:36 smartmirror systemd[1]<EMAIL_ADDRESS>main process exited, code=killed, status=11/SEGV
Jul 19 23:11:36 smartmirror systemd[1]: Unit<EMAIL_ADDRESS>entered failed state.

Expected:
It's expected that Home Assistant restarts.
Additional info:
I don't know since when it doesn't work anymore, but it definitly used to work.
To solve or to avoid the problem I use:
sudo systemctl restart<EMAIL_ADDRESS>

Same issue here. Running 0.49

I have been dealing with this same issue all night. 0.49 here as well.

Same issue here. Running 0.49 as well.


Dask dataframe from_map uses too much scheduler memory when enforce_metadata=True

Hello everyone.
We use dask to process datasets that might have tens of millions of rows and thousands of columns. In this case, we can have thounds of partitions and we noticed that the scheduler was using too much memory to process this dataset, being the bottleneck of our computation.
By running some tests, we've found that the memory usage follows something like a multiplicative relation of O(number of partitions * number of columns) as if the meta was being copied for each partition. But we would expect that every partition uses the same metadata object since they all share the same meta.
We found out that by turning enforce_metadata to False, scheduler memory usage drops considerably (see MCVE below). Maybe _PackedArgCallable that has a meta attribute object and needs to be sent to the workers is being copied somewhere? Since ParquetFunctionWrapper also has a meta attribute, we expect dd.read_parquet to have the same behavior.
Minimal Complete Verifiable Example:
import dask.dataframe as dd
import numpy as np
import pandas as pd
from dask.distributed import Client
from dask.base import tokenize

client = Client()

class BuildDataframeFromNumberColumns:

    def __init__(
        self,
        nb_columns,
        nb_rows=5,
    ):
        self.nb_columns = nb_columns
        self.nb_rows = nb_rows

    @property
    def meta(self):
        return pd.DataFrame([], columns=[f'this_is_a_big_column_name{i}' for i in range(self.nb_columns)], dtype=np.int64)

    @property
    def columns(self):
        return self.meta.columns

    def __call__(self, path):
        frame_size = self.nb_rows * self.nb_columns
        data = np.arange(path * frame_size, (path + 1) * frame_size).reshape((self.nb_rows, self.nb_columns))
        return pd.DataFrame(data, columns=self.columns).astype(self.meta.dtypes)

def build_df(nb_paths, nb_columns, enforce_metadata=True):
    token = tokenize(nb_paths, nb_columns)
    read_func = BuildDataframeFromNumberColumns(nb_columns)
    df = dd.from_map(
            read_func,
            range(nb_paths),
            meta=read_func.meta,
            label="read-parquet-file",
            token=token,
            enforce_metadata=enforce_metadata,
        )
    return df

Running build_df with 10k partitions, 10k columns and enforce_metadata=True, uses ~3.3GiB of scheduler memory:
ddf = build_df(10000, 10000)
ddf.mean().compute()

With enforce_metadata=False, the scheduler uses ~380MiB:
ddf = build_df(10000, 10000, enforce_metadata=False)
ddf.mean().compute()

We tried to analyze the dask_graph for ddf but it seems that the subgraphs are all using the same function instance. So I'm not sure what is really happening here. What do you think?
Environment:

Dask version: 2023.8.1
Python version: 3.11.4
Operating System: Ubuntu 22.04
Install method (conda, pip, source): conda

Thank you for the great work.
Milton

Hello everyone.
I just tested it with dask distributed version 2023.10.1 and it seems that this issue has been solved.
So I'll close this issue.
Thanks


[Draft] Adding docs, scripts etc. for ProblemChild

This PR adds all the supplemental documents and scripts that will be mentioned in the ProblemChild blog. The official documentation that will go along with the release package in the detection-rules repo will also reference these docs.

As suggested by you @bfilar , I have removed the PUTs and changed the formats of all the files to json.


[Done] Create polygons from indices

This build onto #322

@caspervdw note: I think there is a known issue in GEOS (at least on IRC) with ambiguity around ownership transfer of inputs in cases that raise exceptions; this came up in discussions around #306.  I think this might impact your fix in c11b1c8: in the short term there will be memory leaks because of this, but in the long term handling those ourselves will cause segfaults.  Sorry that I haven't had a chance to log a more complete error report to GEOS; wanted to itemize the different cases...

With https://github.com/pygeos/pygeos/commit/c11b1c8fe28d27bfae35b2c4d101ab7cbb6c5a2d, there are no segfaults taking place, so I conclude that cleaning up after a failed Polygon construction is necessary. Still, even with this cleanup, I observe memory leaks coming from the polygon constructor. So I think there is something intermediate that is not cleaned up properly by GEOS.
So I also added a pre-emptive check on the input type, so that it can't fail. Now we still have one left:
___________________ test_polygons[holes0-indices0-expected0] ___________________
[VALGRIND LEAK]

Valgrind has detected a memory leak:

**1**
**1** **********************************************************************
**1** pygeos/test/test_creation_indices.py::test_polygons[holes0-indices0-expected0]
**1** **********************************************************************
==1== 65 (+65) (32 (+32) direct, 33 (+33) indirect) bytes in 1 (+1) blocks are definitely lost in loss record 6,856 of 17,475
==1==    at 0x4C2BBAF: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1==    by 0xF40E3DD: _buffer_get_info (in /usr/local/lib/python3.6/site-packages/numpy/core/_multiarray_umath.cpython-36m-x86_64-linux-gnu.so)
==1==    by 0xF40EB74: array_getbuffer (in /usr/local/lib/python3.6/site-packages/numpy/core/_multiarray_umath.cpython-36m-x86_64-linux-gnu.so)
==1==    by 0x37D890FE: __pyx_memoryview___pyx_pf_15View_dot_MemoryView_10memoryview___cinit__ (_geometry.c:11849)
==1==    by 0x37D890FE: __pyx_memoryview___cinit__ (_geometry.c:11781)
==1==    by 0x37D890FE: __pyx_tp_new_memoryview (_geometry.c:22650)
==1==    by 0x4F7BB84: type_call (typeobject.c:895)
==1==    by 0x37D7F519: __Pyx_PyObject_Call (_geometry.c:24783)
==1==    by 0x37D7F519: __pyx_memoryview_new (_geometry.c:15923)
==1==    by 0x37D7F765: __Pyx_ValidateAndInit_memviewslice.constprop.75 (_geometry.c:28115)
==1==    by 0x37D7FBBA: __Pyx_PyObject_to_MemoryviewSlice_ds_object.constprop.74 (_geometry.c:28178)
==1==    by 0x37D90054: __pyx_pf_6pygeos_9_geometry_6polygons_1d.isra.44 (_geometry.c:7478)
==1==    by 0x37D929EA: __pyx_pw_6pygeos_9_geometry_7polygons_1d (_geometry.c:6887)
==1==    by 0x4F6C9FB: _PyCFunction_FastCallDict (methodobject.c:231)
==1==    by 0x4FB12D9: call_function (ceval.c:4851)
==1==
==1== 65 (+65) (32 (+32) direct, 33 (+33) indirect) bytes in 1 (+1) blocks are definitely lost in loss record 6,857 of 17,475
==1==    at 0x4C2BBAF: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1==    by 0xF40E3DD: _buffer_get_info (in /usr/local/lib/python3.6/site-packages/numpy/core/_multiarray_umath.cpython-36m-x86_64-linux-gnu.so)
==1==    by 0xF40EB74: array_getbuffer (in /usr/local/lib/python3.6/site-packages/numpy/core/_multiarray_umath.cpython-36m-x86_64-linux-gnu.so)
==1==    by 0x37D890FE: __pyx_memoryview___pyx_pf_15View_dot_MemoryView_10memoryview___cinit__ (_geometry.c:11849)
==1==    by 0x37D890FE: __pyx_memoryview___cinit__ (_geometry.c:11781)
==1==    by 0x37D890FE: __pyx_tp_new_memoryview (_geometry.c:22650)
==1==    by 0x4F7BB84: type_call (typeobject.c:895)
==1==    by 0x37D7F519: __Pyx_PyObject_Call (_geometry.c:24783)
==1==    by 0x37D7F519: __pyx_memoryview_new (_geometry.c:15923)
==1==    by 0x37D7F765: __Pyx_ValidateAndInit_memviewslice.constprop.75 (_geometry.c:28115)
==1==    by 0x37D7FBBA: __Pyx_PyObject_to_MemoryviewSlice_ds_object.constprop.74 (_geometry.c:28178)
==1==    by 0x37D900A8: __pyx_pf_6pygeos_9_geometry_6polygons_1d.isra.44 (_geometry.c:7490)
==1==    by 0x37D929EA: __pyx_pw_6pygeos_9_geometry_7polygons_1d (_geometry.c:6887)
==1==    by 0x4F6C9FB: _PyCFunction_FastCallDict (methodobject.c:231)
==1==    by 0x4FB12D9: call_function (ceval.c:4851)
==1==
==1== LEAK SUMMARY:
==1==    definitely lost: 2,936 (+64) bytes in 30 (+2) blocks
==1==    indirectly lost: 1,579 (+66) bytes in 20 (+4) blocks
==1==      possibly lost: 6,933,057 (-1,740) bytes in 67,170 (-1) blocks
==1==    still reachable: 16,390,388 (+7,563) bytes in 114,529 (+67) blocks
==1==                       of which reachable via heuristic:
==1==                         newarray           : 853 (+0) bytes in 40 (+0) blocks
==1==                         multipleinheritance: 2,632 (+0) bytes in 45 (+0) blocks
==1==         suppressed: 0 (+0) bytes in 0 (+0) blocks
==1== Reachable blocks (those to which a pointer was found) are not shown.
==1== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==1==
**1**
**1** **********************************************************************
=========================== short test summary info ============================
FAILED pygeos/test/test_creation_indices.py::test_polygons[holes0-indices0-expected0]
============== 1 failed, 13 passed, 7 xfailed in 65.79s (0:01:05) ==============

Sorry I wasn't very clear.  See https://trac.osgeo.org/geos/ticket/1111.
What I meant was that once that issue is fixed, freeing passed-in geometries ourselves will segfault.  Right now they don't, and they lead to a memory leak if the call to GEOS returns NULL.
If you'd like, you can version-guard this against GEOS, and cleanup ourselves for versions known to leak.  Note that there may be an intermediate GEOS version where this is leaking, but older ones may be OK (not sure: one would need to test or check the GEOS implementation at that version).

I'm not seeing the memory leak on Python 3.9 / GEOS 3.7  (Dockerfile.valgrind bumped to python:3.9-slim-buster base image):
============================= test session starts ==============================
platform linux -- Python 3.9.2, pytest-6.2.2, py-1.10.0, pluggy-0.13.1 -- /usr/local/bin/python
cachedir: .pytest_cache
rootdir: /code
plugins: valgrind-0.1.0
collecting ... collected 8 items

pygeos/test/test_creation_indices.py::test_polygons[holes0-indices0-expected0] PASSED [ 12%]
pygeos/test/test_creation_indices.py::test_polygons[holes1-indices1-expected1] PASSED [ 25%]
pygeos/test/test_creation_indices.py::test_polygons[holes2-indices2-expected2] PASSED [ 37%]
pygeos/test/test_creation_indices.py::test_polygons[holes3-indices3-expected3] PASSED [ 50%]
pygeos/test/test_creation_indices.py::test_polygons[holes4-indices4-expected4] PASSED [ 62%]
pygeos/test/test_creation_indices.py::test_polygons[holes5-indices5-expected5] PASSED [ 75%]
pygeos/test/test_creation_indices.py::test_polygons[holes6-indices6-expected6] PASSED [ 87%]
pygeos/test/test_creation_indices.py::test_polygons[holes7-indices7-expected7] PASSED [100%]

============================== 8 passed in 20.10s ==============================

Also not seeing leaks on Python 3.6 / GEOS 3.5 (current Dockerfile.valgrind)
============================= test session starts ==============================
platform linux -- Python 3.6.12, pytest-6.2.2, py-1.10.0, pluggy-0.13.1 -- /usr/local/bin/python
cachedir: .pytest_cache
rootdir: /code
plugins: valgrind-0.1.0
collecting ... collected 8 items

pygeos/test/test_creation_indices.py::test_polygons[holes0-indices0-expected0] PASSED [ 12%]
pygeos/test/test_creation_indices.py::test_polygons[holes1-indices1-expected1] PASSED [ 25%]
pygeos/test/test_creation_indices.py::test_polygons[holes2-indices2-expected2] PASSED [ 37%]
pygeos/test/test_creation_indices.py::test_polygons[holes3-indices3-expected3] PASSED [ 50%]
pygeos/test/test_creation_indices.py::test_polygons[holes4-indices4-expected4] PASSED [ 62%]
pygeos/test/test_creation_indices.py::test_polygons[holes5-indices5-expected5] PASSED [ 75%]
pygeos/test/test_creation_indices.py::test_polygons[holes6-indices6-expected6] PASSED [ 87%]
pygeos/test/test_creation_indices.py::test_polygons[holes7-indices7-expected7] PASSED [100%]

============================== 8 passed in 28.61s ==============================

Makes it a bit challenging to help identify the source of the leak...  I'm assuming you are using the Python 3.6 / GEOS 3.5 image?

@brendan-ward Your remark about cleaning up after a GEOS Exception got me started on the original polygon creators.
A generic solution to this is preventing GEOS Exceptions to occur in the first place. This we can do by pre-emptively check the type of the input. We already did this for the collections, but for the polygons we did not. I added this check in the original polygons ufunc. Because this was not possible for the polygons_without_holes, I removed that function and routed everything through the polygons (formerly: polygons_with_holes). While I was at it, I noticed that polygons(None, [None]) segfaulted. I fixed that too. Also, I removed the GIL in polygons and create_collection.
Sorry for the big heap of changes, it was all so alike that I just went with the flow... I hope you can bear with me on this.

In contrast to the other creation functions, when using indices, with polygons(..) your input needs to be split between shells and holes (exterior and interior rings).
Personally I find this a bit strange (or inconvenient, for the use case I was trying it out with).
Using the example from https://github.com/pygeos/pygeos/issues/343, if starting with a single 1D array of linearrings and indices:
import pygeos

# 1D array of rings with shape (10, )
rings = pygeos.linearrings(np.random.randn(10, 3, 2))
polygon_indices = np.array([0,1,1,2,2,2,3,4,4,5])

with the current API, I need to do:
polygon_indices_shell = np.insert(np.diff(polygon_indices), 0, 1)
shells_mask = polygon_indices == 1
holes_mask = polygon_indices == 0

shells = rings[shells_mask]
holes = rings[holes_mask]
hole_indices = polygon_indices[holes_mask]

result =  pygeos.polygons(list(shells), list(holes), indices=hole_indices)

but alternatively (and what I initially expected to pass), it could also be an option to pass the shells/holes as a single array, so it would look like (for this starting data):
pygeos.polygons(rings, indices=polygon_indices)

(one constraint with this is that the shell always needs to come before the holes in the array)
Of course, it depends on your actual use case (and what your starting data is) which API would be most convenient. So there might be good use cases for both ways.
One thing is that the alternative with a single array of shells/holes combined would be more similar with eg the reverse of get_parts (or if a get_rings would be added as in https://github.com/pygeos/pygeos/pull/342, this would provide an exact reverse operation).

What you propose is the same as I originally wrote in #241.
So I agree with you on this, the API that you describe (with a single array of rings) is cleaner.
In a way, the polygons are 'just' collections of linearrings. We should treat them as such in the collections_1d and get_parts functions.


Allow playback speed change in player

Is there a way to change the playback speed while a show is playing, or only in the launch screen?
If there isn't, I would like to request it.
Excellent work!

update to latest stable and use html5 player in settings.


Fix adding to unmodifiable Set

Closes: #114

I don't think test failures are related to this patch.


Add files via upload

@SuperCyBug stjoes.txt I am sorry, I have to close the request without merging, because you made a mistake in a request and did not specify any filepath. Please ensure that you are familiar with this repository rules located at the bottom of this page and make a new correct request. Thank you for your understanding!


Update go-zfs to last version

FreeBSD build requires last updates to go-zfs to be included

LGTM

LGTM


Any plan to release Cypher 10?

It has been four years since the first release of Cypher 9.
Do you have any plan to release a newer version of Cypher? aka Cypher 10.
BTW, we are working on the implementation of Cypher 9.
It would be nice to know the new features of Cypher 10.

A lot of activity is currently happening around ISO GQL (http://gqlstandards.org). Cypher is one of the main input languages into this process for the creation of a graph query language standard by the same committee that has been working on SQL for 30 years. If you're interested in getting involved, please look into joining your local national standards body (more formal participation, possibly including voting rights) or alternatively, consider becoming a member of LDBC (easier, more lightweight participation). Both memberships provide you with access to all relevant documents regarding the ongoing development of GQL.

The LDBC home page is here: http://ldbcouncil.org

You can contact LDBC via<EMAIL_ADDRESS>there are other Cypher implementers in the LDBC membership.
There is also a Wikipedia article on GQL, which describes how GQL draws on and extends Cypher, which was one of the main inputs and inspirations for GQL.


Movie Browser

This will show a browserable list of Movies.
Current design is a Detail Screen at the top and horizontal scrolling list at the bottom.  The currently focused item gets the Detail information updated.    We can keep this design or go to a more Grid based view, and take to a detail screen for the movie.
I'm open to new ways to do this screen.

Selecting the Movie displayed will take to detail screen.  List Row design implemented on the main screen.


some attempts on analyzer of MGC

API change check
API changes are not detected in this pull request.


Rename repository to SimpleCAVIPlugin

This will be a CAVI plugin. If we want to later make an RTS version later (which will likely require minor changes to the names of the libraries) we can do that.

Under the hood the namespacing is identical between CAVI and RTS. No changes are necessary that I know of.


Registration: Vitals Form-Display alerts for abnormal values  and Validation of max and Min values

Actual Results
When one inputs values that are outside the normal ranges, the system does not flag with the different color codes. For example, if the value is low the field should be flagged in a yellow color.
Secondly, for some of the fields when one inputs values that are either greater than max value or less than the min value, the system does not flag the fields. This is on both test and dev server.
Expected results
Since it is the whole functionality that is not working for, kindly refer to the described workflow as described here.
For the min or max value: when a value exceeds the max value the field is highlighted and if the value is less than the min value the field is also highlighted.
Steps to reproduce
Login to eSaude POC->Vitals->search for a patient->click on the vital form->add the information as shown in the image below.
This both on the test(v1.2.8) and dev(v1.2.9) server.
Screenshot/Attachment (Optional)
Abnormal values(issue on both dev and test server)

Validation of max and min values(issue on both dev and test server)

@wanjikuchristine and @Benilde this issue is not clear to me so is the requirements for vitals alerts.
If we take width for example, we have: Absolute High, Absolute Low, Normal high and Normal low.
The Absolutes should be used for input validation, don't allow values above high and bellow low.

The Normals should be used in decision support tools (alerts, summaries and charts): to inform the provided that the width is above or bellow the normal, using color codes.
Please let me know if I'm misunderstanding anything

@valvijo this validation is more for know is the patient has a normal, minimum or high value. The validation with the red alert remais there. It is an aditional thing.

In the current PR it has the following behavior:

Value outside range: red;
Value withing range but not normal: orange;
Normal value: no color;

I guess this covers what @Benilde mentioned. Can we go ahead with this implementation? (@valvijo )

Discussed with Valério and the recommendation is to cancel this issue.


Test commit testing

Testing to see if travis identifies bad intermediary commits

@loosebazooka @elharo Travis integration seems to have broken when we went public.


Remove: yetone.OpenAITranslator version 0.0.22

Reason for removal: This version is older than what has been set in max-versions-to-keep by the publisher.
Pull request has been automatically created using 🛫 WinGet Releaser.
Microsoft Reviewers: Open in CodeFlow

Remove: yetone.OpenAITranslator version 0.0.22 #100278


Bugs/fyne cross s3

I am not sure what this PR is fixing - there are a lot of changes but the title is "Bugs/fyne cross s3".
And some commits relate to unreleased work in other pull requests.

I am not sure what this PR is fixing - there are a lot of changes but the title is "Bugs/fyne cross s3". And some commits relate to unreleased work in other pull requests.

I think I messed up this PR and ended up pushing 3 branch into one. I have done a rebase to clean things up and make sure that the 3 other PR are independent as much as possible.


Unhandled exception when trying to run in W11

Traceback (most recent call last):
  File "main.py", line 38, in <module>
  File "<frozen importlib._bootstrap>", line 1176, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1147, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 690, in _load_unlocked
  File "PyInstaller\loader\pyimod02_importers.py", line 391, in exec_module
  File "bin\sysinf.py", line 55, in <module>
  File "subprocess.py", line 466, in check_output
  File "subprocess.py", line 548, in run
  File "subprocess.py", line 1026, in __init__
  File "subprocess.py", line 1538, in _execute_child
FileNotFoundError: [WinError 2] The system cannot find the file specified

W11 Sandbox, antivm enabled but i don't think its AntiVM Here.

I Uninstalled current python & installed 3.11.5 As it was suggested for a similar error to mine, recompiled,  but it did nothing, same error.

send log file

send log file

https://paste.ee/p/yP92W

wrong log file. send roselog.log and just upload it here

wrong log file. send roselog.log and just upload it here

wrong log file. send roselog.log and just upload it here

https://paste.ee/p/pYdAx

wrong log file. send roselog.log and just upload it here

Too long to upload here, https://paste.ee/p/pYdAx

This looks towards a file which doesn't exist on the system. I'll look into it further.

It's possible the file was never created but yet you tried to open it anyways, as the error no longer occurred after you compiled it.
Regardless, the issue is resolved. I will make a bug-fix in the coming days.


Add tests of two contexts

I have added an example to xios_examples demonstrating the ability to use XIOS contexts to stop output part way through the model run.
Brief description
There are two identical contexts defined in the main_stop_*.xml files, stopping after 5 and 10 timesteps respectively. The only difference is the name of the output files differ.
The program is controlled from the namelist file context.nml where we can have up to 4 different stop points in this case (although in the example there are currently two). They need a name, and a timestep on which we want to load the context.
These are then read into a list of "context_struct" types, (defined in custom_type_mod.F90) in context_def_mod.F90
The actual test code is in context_def_test.F90, where we call the load_contexts subroutine from context_def_mod. We then initialize the contexts in a loop, to ensure that they are self consistent, and place their handles into the context_struct type, along with setting a flag is_avaliable to .true., to show that these can be used.
When we timestep, again we loop over the contexts, check that it is available to us, send fields as we normally would. I haven't, but it may be worth using the xios functionality to check the field is available on this context and this timestep to make sure we aren't trying to send too much data around. If the context has reached its end point, we close it, and set the is_available flag to .false. to make sure we dont attempt to use it again.

@harry-shepherd
this is ready to merge (which i'll do)
i just wanted to check how valuable the separate commits are here.
it looks like it's valid to Squash & Merge into a single coherent change to me, are you content with this?

@harry-shepherd this is ready to merge (which i'll do)
i just wanted to check how valuable the separate commits are here.
it looks like it's valid to Squash & Merge into a single coherent change to me, are you content with this?
I am happy for you to Squash & Merge, Thanks


Jenkins agent networking issues

We have constant issues with network connectivity from jenkins agent to external resources such as git repos, aws api, gcp api, etc.
We should find out the root cause and fix the issue.

Fixed


pdksync - (IAC-973) - Update travis/appveyor to run on new default branch main

(IAC-973) - Update travis/appveyor to run on new default branch main
pdk version: 1.18.1

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@63b1f71). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #438   +/-   ##
=======================================
  Coverage        ?   16.66%
=======================================
  Files           ?        1
  Lines           ?        6
  Branches        ?        0
=======================================
  Hits            ?        1
  Misses          ?        5
  Partials        ?        0

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 63b1f71...b43fedd. Read the comment docs.


Add ability to use different TSIG algorithms

This makes it possible to fix #549 and support GSS-TSIG (or in theory any other TSIG algorithms aside from HMAC-MD5, etc.). There is one breaking change in that the TsigSecret field is now a map of value interface{} rather than string. I've added two new functions TsigGenerateByAlgorithm() and TsigVerifyByAlgorithm() which allow an algorithm-specific callback and refactored the existing TsigGenerate() and TsigVerify() to just call these with callback functions that perform the HMAC-specific bits.
With this, GSS-TSIG can be done with something like the following:
const (
        GssTsig = "gss-tsig."
)

func main() {
        ...

        ctx, keyname, err := negotiateGssapiCtx(hostname)
        if err != nil {
                ...
        }

        client := &dns.Client{
                Net:           "tcp",
                TsigAlgorithm: map[string]*dns.TsigAlgorithm{GssTsig: {TsigGenerateGssapi, TsigVerifyGssapi}},
                TsigSecret:    map[string]interface{}{*keyname: ctx},
        }

        msg := new(dns.Msg)

        // Set dynamic DNS, etc.

        msg.SetTsig(*keyname, GssTsig, 300, time.Now().Unix())

        rr, _, err := client.Exchange(msg, net.JoinHostPort(addr, "53"))

        ...
}

negotiateGssapiCtx does the TKEY exchange to establish the GSSAPI context and my TsigGenerateGssapi & TsigVerifyGssapi are pretty much the same as in https://github.com/miekg/dns/issues/549#issuecomment-355545424 the only difference is that the generate callback is now also passed the TSIG algorithm.

Anything I can do to progress this?

Sorry, just coming back to this after much work on CoreDNS.
Why do we need *TsigAlgorithm? That's still a breaking change...
I though in the long discussion we have about this that we could get away with a non-breaking backwards compat change and just having some closures?
I also (apparently) made it not clear enough that backward breaking changes for just this feature are not going to happen. I.e. new members in Client and Server can work, but changing existing fields and types will not fly.

Can you show me where I've broken backwards compat? I don't believe I have (now). Originally I did by changing the tsigSecret map but I merged in @tmthrgd's PR which reverted that and made it work another way so all I've done is add the tsigAlgorithm member (which itself uses *TsigAlgorithm) which didn't exist previously.

@miekg, can you possibly confer with @tmthrgd as I think he's happy there's no compat breakage. Other than that, I'd just like to know what to do with the server code I pointed out and if I should relax the secret check as suggested in https://github.com/miekg/dns/pull/626#issuecomment-357478464

Can this be reopened? I'd still like to get this functionality in and @tmthrgd seemed happy with it. I'm not sure how many times I could point out that I'm only adding new members and not changing existing ones.

Sure. Didn't recall we where still discussing this...
On Fri, 4 Jan 2019, 09:15 Matt Dainty<EMAIL_ADDRESS>wrote:

Can this be reopened? I'd still like to get this functionality in and
@tmthrgd https://github.com/tmthrgd seemed happy with it. I'm not sure
how many times I could point out that I'm only adding new members and not
changing existing ones.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/miekg/dns/pull/626#issuecomment-451391439, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAVkWyxbB53_GLw-W1AcCnnbO8d58WXsks5u_xuUgaJpZM4RZ6I_
.

I'm trying to but you keep ignoring my requests for feedback 🤷♂
I'm happy to bend this into whatever shape is necessary so it works, I'm not changing any existing members or types, only adding new ones. So the only other question is regarding using closures, can you give me an example of how you think that would work that's better than how I've currently done it with callbacks?

Can this get reopened? Would like to get GSS-TSIG support

[ Quoting<EMAIL_ADDRESS>in "Re: [miekg/dns] Add ability to use ..." ]

Can this get reopened? Would like to get GSS-TSIG support

yes, sure, with these caveats:

NO BACKWARDS INCOMPATIBLE changes
NO BLOATING of current datastructures to accommodate the changes

Once you have a PR that does that, we can discuss further. If not, then no

NO BACKWARDS INCOMPATIBLE changes

I've asked you repeatedly to show me where such changes were in the latest version of the code, not in the first commits which were subsequently fixed thanks to @tmthrgd.

NO BLOATING of current datastructures to accommodate the changes

Quoting yourself:

I.e. new members in Client and Server can work, but changing existing fields and types will not fly.

So can I add new members, or is that bloating things? Please make your mind up.
The problem is the generation and verification of TSIG is done inside the library so there needs to be some way of being able to inject additional TSIG algorithms because as it currently stands if the algorithm used is not one of MD5, SHA1, SHA256 or SHA512 the library will always return ErrKeyAlg which breaks the standard usage of the client. In case it's not perfectly clear, GSS-TSIG does not use one of those algorithms.

I'm done with this feature. Sorry.


🎮 Game Request
A playable HTML + CSS + JavaScript remake of a space-based "shoot-'em-up" arcade game for Atari / Commodore 64 from 1982, including a level editor and design tool.

How To Play
The goal : Destroy The bases by shooting out the turrets attached to them. When all Turrets are destroyed the base will explode.
Avoid Crashing into "spaceballs' (green Slime Ball Like Things), And shoot or steer of bad guys
Select program in which you are contributing
GSSoC23
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINE of this project.

Hey @AbhishekPSingh07 !
Thank you for raising an issue 💗
You can self assign the issue by commenting /assign in comment 😀
Make sure you follow CODE OF CONDUCT and CONTRIBUTING GUIDELINES 🚀
Don’t Forget to ⭐ our GameZone🎮
Make sure you join our Discord🕹

/assign

Hey @AbhishekPSingh07 ! Thank you so much for your raising the issue💗
It’s all yours, you can come anytime again and make some contributions! 🚀
Alone, we can do little, but together we can do so much! 😇


[vcpkg] Fix missing VCPKG_ROOT_PATH in create command

closes #8193

LGTM, thanks for fixing this so quickly!


Update README with link to technical report

This will be done as soon as the technical report appears as a MIMS eprint.

Done in the last update.


Can we replace the PyReshaper with Xreshaper?

There are requests for future releases of PyReshaper and the need for the PyReshaper to support Python 3.  While I believe that should be prioritized, I am wondering if future versions of the PyReshaper should be based on Xreshaper.  Can we do this?  Can we build all of the functionality necessary into Xreshaper so that is matches the functionality of the PyReshaper?  What will it take?

No.


discoverCharacteristics empty results

Often a discoverCharacteristics results in a empty array, even though the related service contains some.
My guess is a non-reentrant implementation, b/c repeating the call, the expected result will come.
This is more evident in my application, who triggers a GATT content change (here there can be due to additional issues lied to GATT caching, but I'm not so sure).
It can be possible investigate a such problem, without the need of a retry pattern as workaround?
I can explain further if necessary, with code examples/app logs, of course.

@gtedone can you pleas share logs and , Expecting result vs what you are getting

I'm working on an client application which provides an OTA firmware update for a peripheral.
The peripheral normally runs in application mode, with a certain GATT server content.
flutter: {_type: response, _id: 2, result: [{00001801-0000-1000-8000-00805f9b34fb}, {00001800-0000-1000-8000-00805f9b34fb}, {0000180a-0000-1000-8000-00805f9b34fb}, {544e326b-5b72-c6b0-1c46-41c1bc448118}, {1d14d6ee-fd63-4fa1-bfa4-8f47b42119f0}]}
When the client wants to start an update, by writing to "OTA Control" [f7bf3564-fb6d-4e53-88a4-5e37e0326063] characteristic, the status of the peripheral switches to DFU mode (Device Firmware Upgrade), which causes the device to disconnect and the GATT content to change.
The first step is ok, since OTA Control is found and can be written:
flutter: {_type: response, _id: 3, result: [{uuid: {f7bf3564-fb6d-4e53-88a4-5e37e0326063}, properties: {broadcast: false, read: false, writeWithoutResponse: false, write: true, notify: false, indicate: false, authenticatedSignedWrites: false, reliableWrite: false, writableAuxiliaries: false}}]}
But once the DFU mode is triggered, the device re-connected and its services are discovered again, this is the result:
flutter: 2022-07-11T14:24:34.249571	V	LogsCubit.printConsoleLog:	 Initializing OTA Service
flutter: {_type: response, _id: 7, result: [{00001801-0000-1000-8000-00805f9b34fb}, {00001800-0000-1000-8000-00805f9b34fb}, {0000180a-0000-1000-8000-00805f9b34fb}, {544e326b-5b72-c6b0-1c46-41c1bc448118}, {1d14d6ee-fd63-4fa1-bfa4-8f47b42119f0}]}
flutter: 2022-07-11T14:24:34.339573	V	LogsCubit.printConsoleLog:	 Discovered OTA Service [1d14d6ee-fd63-4fa1-bfa4-8f47b42119f0]
flutter: 2022-07-11T14:24:34.339573	D	LogsCubit.printConsoleLog:	 Discovering OTA Characteristics...
flutter: {_type: response, _id: 8, result: []}
flutter: 2022-07-11T14:24:34.440570	E	LogsCubit.printConsoleLog:	 Update fails: Exception: initOtaService fails: Exception: OTA Characteristics: empty set
While at the same time, a third-party application, i.e. nRF Connect, will got the result as in the attached picture

.

Yes, after going in DFU mode using nRF Connect, the discovering works (also in my application) but, at the end of the file upload (made by writing chunks of the file to OTA Data characteristic), I have a similar issue trying to finalize the process (writing to OTA Control characteristic again): an "Unreachable" error is thrown. The strange here is that sometimes reapeating the entire process it works, but not always. A note: a similar flutter app is working on both Android and iOS platforms, I was hoping for a similar result on Windows too, using this package... :-/

@gtedone are you using any plugin for Dfu ?

No @rohitsangwan01, any other plugin: the DFU application + BLE stack is provided by Silicon Labs.
The workflow is:

Advertisement > Local name: MyDevice
Connect to MyDevice
Discovering:

OTA Service >
	OTA Control

Write "0" to OTA Control to switch to DFU mode > [disconnection]
Advertisement > Local name: changed to OTA
Connect to OTA
Discovering (content changed):

OTA Service >
	OTA Control
	OTA Data
	OTA Version
	... other characteristics ...

MTU negotiation (with WinBle is fixed since a requestMtu() is not available)
Write "0" to OTA Control again (to start the update)
Write firmware file to OTA Data (chunked by size of max MTU)
Write "3" to OTA Control to finalize the process > [disconnection]

The above is working in another Android/iOS flutter app (using flutter_ble_lib and flutter_reactive_ble) and, hopefully, I wish to get it working with WinBle too... :-)

@gtedone strange , can't really figure out without actually debugging with the hardware , if you are on telegram , you can contact me there for easy discussion , TG username => @rohitsangwan01

@gtedone am working on a Dfu update library for all platforms, need some help in it , can you share your email or any contact way or you can contact me ??


Update Dependabot configuration under /typespec/

Description
Updating  Dependabot configuration under /typespec/ so that versions will be ignored till 1.0.0. Once a version is 1.0.0 or higher, Dependabot should resume suggesting updates and then we observe. We expect it to adhere to the ~ constraint set for the dependencies.
ref link: Dependabot ignore
Type of change

This pull request is a minor refactor, code cleanup, test improvement, or other maintenance task and doesn't change the functionality of Radius (issue link optional).

Fixes: #issue_number
Contributor checklist
Please verify that the PR meets the following requirements, where applicable:

[ ] An overview of proposed schema changes is included in a linked GitHub issue.
[ ] A design document PR is created in the design-notes repository, if new APIs are being introduced.
[ ] If applicable, design document has been reviewed and approved by Radius maintainers/approvers.
[ ] A PR for the samples repository is created, if existing samples are affected by the changes in this PR.
[ ] A PR for the documentation repository is created, if the changes in this PR affect the documentation or any user facing updates are made.
[ ] A PR for the recipes repository is created, if existing recipes are affected by the changes in this PR.

Per discussion, I have tested updated configuration on a test repo. The updated configuration will ignore major and minor regular version updates. All security updates (major, minor, patch) should create PRs for these dependencies.


Investigate advance/fetch as a RESTful endpoint

tmpreiss commented on Dec 13, 2016
Advance and fetch are stateless in that the protocol allows for missed packets and missed requests so this lends itself to a stateless RESTful endpoint.

I'm not sure the value of this considering our recent REST implementation. @narinearraul


Issue/11: Implement CMV condition 9

feat: added the code for both CMV9 and the test for it. Ran the test successfully.

don't forget test cases for the helper function

Add some tests for the helper function angleBetweenPoints to make sure it is correct, otherwise the rest looks sensible.

I added a test now and it seems to be working correctly.


Week10/renovate website

View the updated website at https://richarddominick.me/tp (incognito preferred).
Closes #236.
Closes #237.

Codecov Report

Merging #238 (c57c701) into master (722e878) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head c57c701 differs from pull request most recent head a769231. Consider uploading reports for the commit a769231 to get more accurate results

@@            Coverage Diff            @@
##             master     #238   +/-   ##
=========================================
  Coverage     64.80%   64.80%
  Complexity      541      541
=========================================
  Files           109      109
  Lines          1901     1901
  Branches        188      188
=========================================
  Hits           1232     1232
  Misses          601      601
  Partials         68       68

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Linode node template option is missing

What kind of request is this (question/bug/enhancement/feature request): bug
Steps to reproduce (least amount of steps as possible):
On latest master - commit id: 6d6199121

Go to Node Template page --> Add Node template

Error is seen on the UI and Linode node template option is NOT available

Navigate to add cluster page

Error seen in console: Uncaught (in promise) Event {isTrusted: true, type: "error", target: link#driver-ui-css-linode, currentTarget: null, eventPhase: 0, …}

Expected Result:
Linode node template Option should be available
Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI): master head   commit id: 6d6199121
Installation option (single install/HA): HA

The backend serving the assets is currently broken, turn off the driver in settings if it's in the way.

Verified on master-head commit id: d19f179c4
Linode option is available while creating a node template
User is able to deploy a linode cluster using this node template


Added new publication on website

Added the "Assessment of the Political Feasibility of Developing a GCC Power Market" paper on publication page.

Will re-open pull request, Travis on GitHub is stuck on pending even when the original CI run in the website is successful
https://travis-ci.org/KAPSARC/KTAB/builds/442191101?utm_source=github_status&utm_medium=notification


Add battery usage/charge in watts token %consumption%

I pretty much just reused existing mechanisms to add the ability to show battery drain/charge in watts. The new token is %consumption%

Hi and thank you for contributing. Will create a review with a few minor remarks.

Changes made, sorry about that.

CI build timed out downloading cmake


Extra CPU usage when not enough work in par_bridge

On a particular workload I noticed that Rayon uses all available CPU, but doesn't do its best, i.e.  does better when the number of threads is reduced. The workload involves work that is easy to parallelize (essentially order-insensitive stream processing using par_bridge() with almost no mutable shared state) running on a 64-CPU server. On my laptop the it nicely parallelizes to 4 cores, running approximately 4x faster than sequentially. But on the 64-CPU server the work definitely doesn't proceed with speed anywhere near 64x of the sequential version on the same machine, while all the CPUs are churning at 100% the entire time.
Experimenting with RAYON_NUM_THREADS shows that performance peaks around 8-16 CPUs and gets worse with 32 and 64:

1 thread: 6.5s / million records
2 threads: 3.5s
4 threads: 1.9s
8 threads: 1s
16 threads: 0.9s
32 threads: 1.7s
64 threads (default): 1.7s

Measurements were done with release build and Rayon 1.4.0. The interesting thing is that in all tests all cores were at 100%, as measured by htop.
I was unable to reproduce the issue with simpler minimal examples, where Rayon seemed to distribute the load nicely. So I rewrote the code to use a crossbeam_channel to distribute the work to 64 manually created threads instead. Using that, it took 3.8s to process a million records, but all cores were only at 15-20% of CPU usage. I then added some batching (a thousand records in a batch) and sent the batches over the channel to reduce the overhead. With this change I got the speed of the channel version to 0.65s/million records, with CPUs averaging about 25% usage.
Of course, now I had to implement similar batching in Rayon, which I did, bringing the numbers to:

1 thread: 6.4s/million records
2 threads: 3.4s
4 threads: 1.76s
8 threads: 0.91s
16 threads: 0.77s
32 threads: 0.77s
64 threads (default): 0.85s

With batching Rayon is no longer able to outperform channel-based dispatch, although it comes close at its best numbers. Note that Rayon is always using 100% of the cores it runs its threads on, and in case of 64 threads it uses 100% of all cores, despite being slower than channel variant, which only uses about 25% of the cores.
Given the large number of CPUs and the low utilization in the channel variant, I believe that the work-giving thread (the one that reads the stream and uses par_bridge()) is limited by IO and is not providing work fast enough to saturate all 64 CPUs. This means that this workload will never utilize full 64 CPUs - and that's fine. The thing that bugged me was that Rayon seemed to be using all cores while getting less done than with a reduced number of threads - this seemed like a bug. Googling similar issues I found  #642 and thought that maybe I stumbled upon that bug. I reasoned that the IO thread was providing just enough work to keep Rayon threads in busy-wait much of the time, making all cores report 100% usage, but wasting enough time in busy-wait to affect their ability to do useful work. Reducing the number of threads would improve performance because #642 doesn't appear when there is enough work. The bug wouldn't appear on my laptop for the same reason - it doesn't have enough CPU horsepower to outmatch the IO bandwidth of the reader thread.
But alas, upgrading to Rayon 1.4.0 didn't fix things, so I guess it must be a different problem.
A slightly simplified version of the main loop of the code looks like this:
// Deserialize lines from FILE into Obj and call PROCESS on the object.
// Deserialization and processing is performed in parallel when possible.

fn read_jsonl<Obj: DeserializeOwned>(
    file: impl AsRef<Path>,
    process: impl Fn(Obj) -> () + Sync,
) {
    let file_disp = file.as_ref().display().to_string();
    let reader = BufReader::with_capacity(
        1024 * 1024,
        File::open(file.as_ref()).unwrap_or_else(|e| panic!("opening {}: {}", file_disp, e)),
    );
    reader
        .lines()
        .map(Result::unwrap)
        .enumerate()
        .par_bridge()
        .for_each(|(lineno, line)| {
            if log_enabled!(Level::Info) {
                if lineno != 0 && lineno % 1_000_000 == 0 {
                    info!("{}: processed {} records", file_disp, lineno);
                }
            }
            match serde_json::from_str(&line) {
                Ok(rec) => {
                    process(rec);
                }
                Err(e) => warn!("{}: {}: {}", file_disp, lineno + 1, e),
            }
        });
}

The input file is a multi-gigabyte jsonl, one-object-per-line json, with lines of about 2K in length. In production code there are additional minor optimizations to iterate over Vec<u8> instead of strings to speed up the IO thread, but they make no difference regarding parallelism.
The process closure passed to the function does some processing of the deserialized object, re-serializes it into JSON, and stores it in a shared vector. The mutation of the vector (assignment and the extremely rare resize) are inside a parking_lot::Mutex, but the vast majority of the time is spent in processing, so the mutex is uncontended. I experimented with finer-grained locking, using a mutex for each row and an upgradeable rwlock for the vector, but there was no effect on performance whatsoever.
If someone is curious, I can show the channel version and the chunked version of the code.

Note that in this case utmost processing efficiency is not a requirement, so I can afford to retain more elegant code (e.g. avoiding chunking) even if it is somewhat slower. The reason I investigated the issue was that I was curious why a 64-CPU server didn't bring a greater speedup compared to my 4-core laptop on what I considered highly parallelizable workload.

Hello, this is exactly my problem:
https://github.com/rayon-rs/rayon/issues/762
@hniksic I would be very curious to know how you improve performance with more than 16 threads and if I can implement what you did for your project.

@lakwet Using Rayon I wasn't yet able to improve performance at 16+ threads. I did manage to make a version that outperformed Rayon by combining batching and crossbeam_channel for work distribution. The performance improvement is slight, but the CPUs spend much less power. (This may be specific to my use case, where my IO performance is the bottleneck.)

I managed to reproduce the problem on a small example, at least on the 32-core (num_cpus::get() reporting 64 due to hyperthreading) server I have access to. I expect the example could be simplified further, but I prefer to keep the workload similar to what I work with, so that optimizations or workarounds still apply to my problem.
Running the program below results in peak preformance at around 16 threads:
$ ./target/release/parallel-bench
done 1000000 in 2.583879913 s
$ RAYON_NUM_THREADS=1 ./target/release/parallel-bench
done 1000000 in 17.34046454 s
$ RAYON_NUM_THREADS=2 ./target/release/parallel-bench
done 1000000 in 9.265604026 s
$ RAYON_NUM_THREADS=4 ./target/release/parallel-bench
done 1000000 in 4.717856639 s
$ RAYON_NUM_THREADS=8 ./target/release/parallel-bench
done 1000000 in 2.565539363 s
$ RAYON_NUM_THREADS=16 ./target/release/parallel-bench
done 1000000 in 1.926309717 s
$ RAYON_NUM_THREADS=32 ./target/release/parallel-bench
done 1000000 in 2.213428796 s
$ RAYON_NUM_THREADS=64 ./target/release/parallel-bench
done 1000000 in 2.625233038 s

In all cases all cores, as reported by htop, are at 100% utilization. The program:
use serde::de::DeserializeOwned;
use std::io::{BufRead, BufReader, Cursor, Read};
use std::sync::atomic::{AtomicUsize, Ordering};

const TEST_DATA: &str = r#"{"field0":0,"field1":2,"field2":2,"field3":0,"field4":2,"field5":7,"field6":2,"field7":2,"field8":7,"field9":0,"field10":5,"field11":1,"field12":[0],"field13":0,"field14":0,"field15":0,"field16":0,"field17":0,"field18":0,"field19":[9],"field20":2,"field21":17,"field22":1,"field23":2,"field24":1,"field25":1,"field26":4,"field27":0,"field28":1,"field29":1,"field30":1,"field31":3,"field32":"25Cs/5s09fCaccJ1KEkflg==","field33":2,"field34":1,"field35":0,"field36":[0],"field37":1,"field38":0,"field39":0,"field40":0,"field41":0,"field42":1,"field43":1,"field44":0,"field45":3,"field46":1,"field47":0,"field48":2,"field49":1,"field50":1,"field51":1,"field52":0,"field53":1,"field54":9,"field55":2,"field56":2,"field57":[0],"field58":2,"field59":14412114,"field60":0,"field61":1,"field62":2,"field63":0,"field64":2,"field65":0,"field66":0,"field67":0,"field68":0,"field69":1,"field70":0,"field71":0,"field72":1,"field73":7,"field74":0,"field75":0,"field76":7,"field77":2,"field78":0,"field79":5,"field80":0,"field81":0,"field82":0,"field83":6,"field84":2,"field85":2,"field86":2,"field87":2}
{"field17":0,"field18":0,"field59":14412114,"field60":0,"field82":0,"field57":[0],"field66":0,"field67":0,"field68":0,"field32":"25Cs/5s09fCaccJ1KEkflg==","field36":[0],"field39":0,"field70":0,"field41":0,"field74":0,"field75":0,"field12":[0],"field49":1,"field52":0,"field13":0,"field80":0,"field15":0,"field51":1,"field25":1,"field16":0,"field53":1,"field3":0,"ts":0}
{"field0":0,"field1":2,"field2":2,"field3":0,"field4":2,"field5":7,"field6":2,"field7":2,"field8":7,"field9":0,"field10":5,"field11":1,"field12":[0],"field13":0,"field14":0,"field15":0,"field16":0,"field17":0,"field18":0,"field19":[9],"field20":2,"field21":17,"field22":1,"field23":2,"field24":1,"field25":1,"field26":4,"field27":0,"field28":1,"field29":1,"field30":1,"field31":3,"field32":"Iw9ohtZ7t0+hBKUKhViqG50yjv3uSlnXtWSIi0G1cJgDAxg16+4Ekie3WieUPOZp","field33":2,"field34":1,"field35":0,"field36":[0],"field37":1,"field38":0,"field39":0,"field40":0,"field41":0,"field42":1,"field43":1,"field44":0,"field45":3,"field46":1,"field47":0,"field48":2,"field49":1,"field50":1,"field51":1,"field52":0,"field53":1,"field54":9,"field55":2,"field56":2,"field57":[0],"field58":2,"field59":8880866,"field60":0,"field61":1,"field62":2,"field63":0,"field64":2,"field65":0,"field66":0,"field67":0,"field68":0,"field69":1,"field70":0,"field71":0,"field72":1,"field73":7,"field74":0,"field75":0,"field76":7,"field77":2,"field78":0,"field79":5,"field80":0,"field81":0,"field82":0,"field83":6,"field84":2,"field85":2,"field86":2,"field87":2}
{"field17":0,"field18":0,"field59":8880866,"field60":0,"field82":0,"field57":[0],"field66":0,"field67":0,"field68":0,"field32":"Iw9ohtZ7t0+hBKUKhViqG50yjv3uSlnXtWSIi0G1cJgDAxg16+4Ekie3WieUPOZp","field36":[0],"field39":0,"field70":0,"field41":0,"field74":0,"field75":0,"field12":[0],"field49":1,"field52":0,"field13":0,"field80":0,"field15":0,"field51":1,"field25":1,"field16":0,"field53":1,"field3":0,"ts":0}
"#;

fn full_test_data() -> Vec<u8> {
    let mut full = vec![];
    for _ in 0..250_000 {
        full.extend_from_slice(TEST_DATA.as_bytes());
    }
    full
}

pub fn read_jsonl_rayon<Obj: DeserializeOwned>(
    input: impl Read + Send + Sync,
    process: impl Fn(Obj) -> () + Sync,
) {
    use rayon::prelude::*;
    let r = BufReader::new(input);
    r.lines()
        .map(Result::unwrap)
        .par_bridge()
        .for_each(|line| process(serde_json::from_str(&line).unwrap()));
}

fn main() {
    let data = full_test_data();
    let t0 = std::time::Instant::now();
    let cnt = AtomicUsize::new(0);
    read_jsonl_rayon(Cursor::new(&data), |obj: serde_json::Value| {
        serde_json::to_string(&obj).unwrap();
        cnt.fetch_add(1, Ordering::Relaxed);
    });
    println!("done {} in {} s", cnt.into_inner(), t0.elapsed().as_secs_f64());
}

Cargo.toml:
[package]
name = "parallel-bench"
version = "0.1.0"
authors = ["Hrvoje Niksic<EMAIL_ADDRESS>edition = "2018"

[dependencies]
serde = "1.0.115"
serde_json = "1.0.57"
rayon = "1.4.0"

excerpt from /proc/cpuinfo:
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 23
model           : 49
model name      : AMD EPYC 7502P 32-Core Processor
stepping        : 0
microcode       : 0x8301034
cpu MHz         : 1890.943
cache size      : 512 KB
physical id     : 0
siblings        : 64
core id         : 0
cpu cores       : 32
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 16
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate sme ssbd mba sev ibrs ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr wbnoinvd arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif umip rdpid overflow_recov succor smca
bugs            : sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass
bogomips        : 4990.77
TLB size        : 3072 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 43 bits physical, 48 bits virtual
power management: ts ttp tm hwpstate cpb eff_freq_ro [13] [14]

Thanks a lot for your answer.
I also notice that with more than 16 threads, performance decrease.
And I also notice that when I set my radix sort with 10 threads, it seems to use the 32 threads of my Ryzen 9.
At first I believe it was because my CPU has 16 physical cores, but apparently with 32 physical cores, there is the same threshold for performance.
There might be a bug indeed.
Apparently, when there is not much to compute, but a lot of data to move, we have this problem. In my radix sort, there is not much to compute, but most of the work is to move element from one place to another.
I tried to look at the code in rayon, but I am not familiar enough with Rust to fully understand everything. I may need to spend more time on it.

And I also notice that when I set my radix sort with 10 threads, it seems to use the 32 threads of my Ryzen 9.

@lakwet Can you elaborate on this? In my investigations Rayon always respects the number of threads specified through RAYON_NUM_THREADS.

I don't use RAYON_NUM_THREADS but the builder:
let pool = ThreadPoolBuilder::new().num_threads(thread_n).build().unwrap();

I have a CPU with 16 physical cores and 32 threads and I wrote this crate:
https://crates.io/crates/voracious_radix_sort
The peek of performance is a 16 threads.
If I put more than 16 threads, performance decreases.
But If set between 10 and 16 threads, I got the same results. Which is weird. Clearly, it should be faster with 16 threads than with 10.
When I look at my htop, (which is not very rigorous), I can see that my multithread sort use all the 32 threads.

@lakwet I see, thanks for the explanation. I haven't needed to limit the number of threads like that in my code yet, I just used the env var for testing. Ideally I'd like Rayon to utilize all cores by creating the appropriate number of threads, which is why I reported this issue.
Is it possible that you are not using the API correctly (not a criticism, just thinking out loud), or that you accidentally create multiple thread pools? In either case, I think the issue of Rayon not respecting ThreadPoolBuilder::num_threads() should probably be discussed in a different issue to avoid spreading this one to too many topics.

I tested using RAYON_NUM_THREADS instead of the builder.
RAYON_NUM_THREADS and the builder give the same runtimes for my radix sort depending on the number of threads I set.
So the "htop" method is not accurate at all.

Some citations on the issue:

LWN: The consensus, however, seems to be that applications that loop on sched_yield() are simply broken and should be fixed.
Microsoft: On multicore computers, when wait times are expected to be short and when contention is minimal, SpinLock can perform better than other kinds of locks.
Linus Torvalds: I repeat: do not use spinlocks in user space, unless you actually know what you're doing. And be aware that the likelihood that you know what you are doing is basically nil.

I feel that this problem is a real footgun.
For example, if my Iterator is blocking or slow, par_bridge is basically contraindicated. This is unfortunately not documented.
A stopgap would be documenting par_bridge that it is only appropriate when the user is assured that the processing of items is slower than the rate at which they can be received.

@cuviper I guess you can mark this as closed!

Ah, yes, I didn't notice that GitHub hadn't properly linked the issue to the PR. Thanks again for your change, it was published in rayon 1.6.1!

Thanks for fixing this! I checked my minimal example from this comment on a 32/64 core machine, and it indeed seems to fix the issue. With Rayon 1.6.0 I get the following numbers:
$ RAYON_NUM_THREADS=8 ./target/release/test
done 1000000 in 2.219801246 s
$ RAYON_NUM_THREADS=16 ./target/release/test
done 1000000 in 1.931417055 s
$ RAYON_NUM_THREADS=32 ./target/release/test
done 1000000 in 2.395053222 s
$ RAYON_NUM_THREADS=64 ./target/release/test
done 1000000 in 2.844460551 s
$ ./target/release/test
done 1000000 in 2.753685914 s

With 1.6.1 I get better times across the board and, most importantly, not setting RAYON_NUM_THREADS simply gives optimal performance:
$ RAYON_NUM_THREADS=8 ./target/release/test
done 1000000 in 1.8929853859999999 s
$ RAYON_NUM_THREADS=16 ./target/release/test
done 1000000 in 1.772770773 s
$ RAYON_NUM_THREADS=32 ./target/release/test
done 1000000 in 1.765792873 s
$ RAYON_NUM_THREADS=64 ./target/release/test
done 1000000 in 1.593089524 s
$ ./target/release/test
done 1000000 in 1.599067426 s

Also, checking htop shows that Rayon 1.6.1 allows the CPUs to go to sleep when doing nothing, as the machine is not wildly spinning.


 documentation comments are mishandled

Using latest version (5.5.1).

<see cref="PropertyName" /> in code is written as the fully-qualified <see cref="P:Fully.Qualified.Namespace.Of.PropertyName" /> in the documentation XML, which is rendered as-is (excluding the leading "P:") into the outputted HTML i.e. "Fully.Qualified.Namespace.Of.PropertyName"
<see langword="x" /> is not rendered into outputted HTML at all
<see langword="x">x</see> is rendered, but without the curly braces that are inserted around <c></c> elements (i.e. "false" instead of "{false}")

By design, Swashbuckle only supports a very small subset of the standard XML Comments tags - specifically <summary>, <remarks>, <param> and <example>. The goal is to provide a simple and convenient way to provide multi-line descriptions for operations, parameters, responses and schemas. The intention has never been to support all of the tags and map to HTML/markdown accordingly, and frankly that's a level of complexity that I'm not willing to take on.
What I might suggest, if someone was willing, would be to create a separate project that extends Swashbuckle using the various filters and offers a much richer integration with the XML Comments tags.

By design, Swashbuckle only supports a very small subset of the standard XML Comments tags - specifically <summary>, <remarks>, <param> and <example>. The goal is to provide a simple and convenient way to provide multi-line descriptions for operations, parameters, responses and schemas. The intention has never been to support all of the tags and map to HTML/markdown accordingly, and frankly that's a level of complexity that I'm not willing to take on.
What I might suggest, if someone was willing, would be to create a separate project that extends Swashbuckle using the various filters and offers a much richer integration with the XML Comments tags.


I know why my alarm is different in the widget

Is your feature request related to a problem? Please describe.
Yes. The alarm displayed in the widget is never the same as the one i set in my Clock app.
I have a Xiaomi and I spotted out 2 cases :

When the option ''Notification before ringing'' is on (screenshot 1), the Xiaomi's Clock app send a notification 1 hour before the actual alarm time.
This is why the alarm displayed in the widget was 1 hour before the actual alarm time (screenshot 2). It is logical.

When this option is off (screenshot 3), the alarm displayed in the widget is 15 minutes before the actual alarm time (screenshot 4).
I don't understand why... MAYBE the Xiaomi's Clock app send a hidden notification 15 minutes before to the system to activate the alarm and to take the Clock app out of battery saver?

Describe the solutions you'd like
(easy to code and universal to all devices)
Add an option in the widget to let the user adjust the alarm that is displayed in the widget (image 5).
Describe alternatives you've considered
(hard to code and can lead to more problems depending on device brand)
Change the way you collect the alarm info.
Now: i think you collect notifications.
Future: you will have to collect alarm info depending on each device brand, because it might be coded differently in each Clock app.
Additional context

@Moutony I actually use this API to get the next alarm set on the device. I thought about your ideas but I think that would be impossible to check if the information I get is from the API during the option "1h before", "5 minutes before", or when it shows the exact alarm time...
It would be hard just to filter the device ROM.

@Moutony I actually use this API to get the next alarm set on the device. I thought about your ideas but I think that would be impossible to check if the information I get is from the API during the option "1h before", "5 minutes before", or when it shows the exact alarm time...
It would be hard just to filter the device ROM.

@tommasoberlose I understand that it is hard to adapt the API to the device ROM.
This is why i suggested to let the user adjust the alarm time himself (last screenshot).

@tommasoberlose I understand that it is hard to adapt the API to the device ROM.
This is why i suggested to let the user adjust the alarm time himself (last screenshot).

@Moutony that could be a feasible idea if the difference between the correct and the wrong times would always be the same. The user could just adjust that, as you said, but in most cases, this would be the situation:
Device clock alarm set to 8:30

AW calls the API before 8:10 and gets 8:25 (adjust the alarm to 8:30 with 5 mins of difference)
AW check the alarm at 8:28 and gets 8:30 (adjust the alarm and shows 8:30)

I can actually access the next alarm without knowing if there are more, this obviously drives me crazy but I can't find an easy solution.

@Moutony that could be a feasible idea if the difference between the correct and the wrong times would always be the same. The user could just adjust that, as you said, but in most cases, this would be the situation:
Device clock alarm set to 8:30

AW calls the API before 8:10 and gets 8:25 (adjust the alarm to 8:30 with 5 mins of difference)
AW check the alarm at 8:28 and gets 8:30 (adjust the alarm and shows 8:30)

I can actually access the next alarm without knowing if there are more, this obviously drives me crazy but I can't find an easy solution.

If I don't have alarms tomorrow, the widget says that it will be at midnight, and the settings say "Alarm clock set by Calendar".
Redmi 8A, Android 10, MIUI 11.

If I don't have alarms tomorrow, the widget says that it will be at midnight, and the settings say "Alarm clock set by Calendar".
Redmi 8A, Android 10, MIUI 11.


Updated ICD10 code list per @amy.zipursky and @alon.geva and reviewed…

… by @andy.mcmurry. https://docs.google.com/spreadsheets/d/16xBfGqclOufbSCtbpa2C8JwL10R64Xf0BDfuuUMF2TE/edit#gid=0
@dogversioning please let me know if you see any obvious errors, otherwise this has been QA'd by 2 Emergency Dept doctors

Thanks @mikix , can you do this version/release part?
I dont know how, I dont see even see a version number in pyproject.toml and pypi is black magic to me