Migration from GitBook to Docusaurus

Since GitBook is no longer maintained, a lot of projects started their migration to newer solutions. One of the most popular ones is Docusaurus.
What do think about building Spaceship's website using this tool?

I was similarly looking to replace GitBook, and was looking at a Docsaurus alternative: Docsify. It looked like a lighter and less complex solution, but I hadn't gotten to the point of actually testing either.

mdbook also looks like a great alternative

Migrated to mkdocs-material


Workflow minor improvement

Minor workflow improvement intended to allow forked repo build to happen without upstream Sonar access token and Slack notification URL defined.
Helps to stick to proper git workflow on github actions changes.
Docker images may now be pushed to 3rd party image registry to allow debug and testing, not tampering official
docker registry.
DOCKER_REGISTRY action secret can be defined as used in docker login. If absent, docker login will happen
to default dockerhub image registry.
DOCKER_IMAGE_PREFIX action secret can be defined to override default image name prefix in a form of
$registryaddress/$prefix/ (with trailing slash).
Changelog
Changed

build workflow step if clause added for Slack notification
maven build args related to Sonar made to be added conditionally
DOCKER_REGISTRY action secret added to allow login to registry other than default (dockerhub)
DOCKER_IMAGE_PREFIX action secret added to allow docker image path other than dirigiblelabs/

Found some issues with proposed changes, will update PR once they are fixed.

@alexkuklin I've converted the issue to Draft, so once it's ready to be review, please convert it back.

Comment updated

Closing this one in favor of https://github.com/SAP/xsk/pull/1565. Feel free to reopen it if necessary


[Bug] Homepage install button goes to non-existent install page

Get Started button on home page links to https://www.dash-extensions.com/getting-started/installation instead of https://www.dash-extensions.com/pages/getting-started/installation giving a 404 error.

Opened PR #5

PR merged :)


Draft: feat: add semantic release

📝 PR Summary
Add Semantic release to project.
📌 Type of PR
Select the appropriate type from the list below and delete the unsuitable types:

🍕 Feature

⛏ Change Impact

🔥 High

🗒 PR Description
Add semantic release
🎫 Applicable Ticket
Closes #15

@all-contributors
please add @raj19joshi for code.

@all-contributors
please add @raj19joshi for code.


bigquery dryrun mode?

the dryRun needs to be on the configuration object, similar to #2107
https://cloud.google.com/bigquery/docs/reference/rest/v2/jobs#configuration.dryRun

Thank you, I've re-purposed #2107 to include support for this option as well.


Add CSP Tauri rules

Using default CSP rules, page load fails because of

We need to add a worker-src drirective in tauri.conf.json csp
"csp": "default-src blob: data: filesystem: ws: wss: http: https: tauri: 'unsafe-eval' 'unsafe-inline' 'self' img-src: 'self' worker-src 'self' blob:"

or
"csp": "default-src blob: data: filesystem: ws: wss: http: https: tauri: 'unsafe-eval' 'unsafe-inline' 'self' img-src: 'self' worker-src blob:tauri://localhost/71d5375-d12a-49a6-8a24-27882f97900"

@jigneshsolanki There is an open PR for that but it is likely buggy.


ConnectionTimeoutError

Description
I was using version 2.8.0 of redis in an aws lambda with node in version 14.x, when updating redis version to 4.6.7 and node to version 18.x I started getting timeouts in just a few moments.
Redis Client Error ConnectionTimeoutError: Connection timeout
at Socket. (/opt/nodejs/node_modules/@redis/client/dist/lib/client/socket.js:178:124)
at Object.onceWrapper (node:events:627:28)
at Socket.emit (node:events:513:28)
at Socket._onTimeout (node:net:570:8)
at listOnTimeout (node:internal/timers:569:17)
at process.processTimers (node:internal/timers:512:7)
this is my code:
const redis = require('redis')
const client = redis.createClient({
url: redis://${process.env.REDIS_IP}:${process.env.REDIS_PORT},
pingInterval: 2000,
socket: {
connectTimeout: 7000
}
})
client.connect()
client.on('error', err => console.log('Redis Client Error', err))
Node.js Version
18.17.0
Redis Server Version
6.2.6
Node Redis Version
4.6.7
Platform
No response
Logs
Redis Client Error ConnectionTimeoutError: Connection timeout
    at Socket.<anonymous> (/opt/nodejs/node_modules/@redis/client/dist/lib/client/socket.js:178:124)
    at Object.onceWrapper (node:events:627:28)
    at Socket.emit (node:events:513:28)
    at Socket._onTimeout (node:net:570:8)
    at listOnTimeout (node:internal/timers:569:17)
    at process.processTimers (node:internal/timers:512:7)

I have the same issue here, any update to this?

Same issue here... Let's fix this!

Hi everyone,
Debugging a "timeout issue" can be quite challenging as it is often triggered by another underlying error. For instance, if the Redis server event loop gets blocked (which can be simulated using DEBUG SLEEP 10000 – DO NOT run this on your production server), any client attempting to open a socket will experience a timeout. Similarly, if the Node.js event loop gets blocked, timeouts will occur as well (see here for an example). Additionally, it's important to consider the possibility of an actual network issue causing the problem. Lastly, there could be an undiscovered bug in the package; however, I must mention that I personally (and many other users) run servers with the same package version and haven't experienced any timeouts.
If anyone has any insights, please feel free to share them..
Duplicate of #1656

I upgraded to version 4.6.8 and the error dissapeared


Generate BOM entry in generated version catalog

Generating a BOM like below requires specifying the BOM version twice:
generate("jackson") {
            from("com.fasterxml.jackson:jackson-bom:2.18.0")
            aliasPrefixGenerator = GeneratorConfig.NO_PREFIX
            aliasSuffixGenerator = { _, _, artifactId ->
                artifactId.removePrefix("jackson-")
            }
        }

Requires an entry in libs.versions.toml:
jackson-bom = { module = "com.fasterxml.jackson:jackson-bom", version = "2.18.0" }
...to have this in the build script:
    implementation(platform(libs.jackson.bom))
    implementation(jackson.core)
    implementation(jackson.module.kotlin)

Ideally a "bom" entry (alias would be configurable) would be generated indicating the BOM the catalog came from.
This would eliminate the need for a BOM entry in libs.versions.toml and make the build script consistent in terms of library references:
    implementation(platform(jackson.bom))  // no "libs" prefix!
    implementation(jackson.core)
    implementation(jackson.module.kotlin)

Am aware that you can use from(toml("springBootDependencies")) to avoid respecifying the version, but that still leaves a naming inconsistency between the BOM library reference and the other library references.

that still leaves a naming inconsistency between the BOM library reference and the other library references.
do you mean that it would be libs.jackson.bom instead of jackson.bom ?

Yes, the difference between
    implementation(platform(libs.jackson.bom))
    implementation(jackson.core)
    implementation(jackson.module.kotlin)

and
    implementation(platform(jackson.bom)) // generated
    implementation(jackson.core)
    implementation(jackson.module.kotlin)

@cloudshiftchris would you want to be able to use a custom alias for the bom entry, or is the existing logic using the actual artifact id ok?

@austinarbor  the existing logic using the actual artifact id seems Ok, and preferable for consistency.
Perhaps there are some rare cases where a custom alias would be required, nothing seems obvious atm.

I have published 2.1.0 which includes this feature
generate("springLibs") {
      from(toml("springBootDependencies"))
      generateBomEntry = true

Amazing.  Thank you.
Looking good.
This configuration:
        generate("jackson") {
            from("com.fasterxml.jackson:jackson-bom:2.18.0")
            aliasPrefixGenerator = GeneratorConfig.NO_PREFIX
            aliasSuffixGenerator = { _, _, artifactId -> artifactId.removePrefix("jackson-") }
            generateBomEntry = true
        }

Allows for consistent naming in dependencies blocks and removing the BOM entry from libs.versions.toml:
    implementation(platform(jackson.bom))
    implementation(jackson.core)
    implementation(jackson.module.kotlin)
    implementation(jackson.datatype.jsr310)


[SPARK-40580][PS][DOCS] Update the document for DataFrame.to_orc.

What changes were proposed in this pull request?

This PR proposes to update the docstring of DataFrame.to_orc, since pandas.DataFrame.to_orc is supported from pandas 1.5.0, but the behavior is a bit different.
Why are the changes needed?

From pandas 1.5.0, they support writing the DataFrame to ORC files.
In pandas API on Spark, we already support this feature, but the behavior is different.
So, we should mention the difference in the documents.
Does this PR introduce any user-facing change?

Yes, documentation update.
How was this patch tested?

The existing doctest should pass.

Yeah, I think maybe we should also address the other I/O functions if there is behavior differences.
We already document about the difference for almost I/O functions, but seems still some missing docs.
Let me file a separate ticket to address them in a one PR.

This is not the same.
pandas API on Spark
or
pandas-on-Spark
Which one do we use?

pandas-on-Spark is more likely to be a developers' reference in the source code, whereas pandas API on Spark is the official, user-facing name. Hope that helps :) @bjornjorgensen

Yeah, and more specifically, the "pandas-on-Spark" is used when the another noun follows right after "pandas API on Spark".
For example,
"pandas API on Spark DataFrame is distributed"
When reading the above sentence, the readers may confuse between:

is this indicate "pandas API" on Spark DataFrame ?
is this indicate "pandas API on Spark" DataFrame ?

So, we use "pandas-on-Spark DataFrame" in this case.

Merged to master.


[LSP] [WIP] Tests for VerilogLanguageServer class

This PR utilizes the fact that Verilog Language Server is currently wrapped in a class (https://github.com/chipsalliance/verible/pull/1560) and provides a set of GTest-based tests for the class.
Currently, a fixture is implementing initializing VerilogLanguageServer and client mocking, as well as tests previously written in shell script verible-verilog-ls_test.sh

Codecov Report
Base: 92.81% // Head: 92.81% // Increases project coverage by +0.00% :tada:

Coverage data is based on head (9b94a47) compared to base (43bad59).
Patch coverage: 100.00% of modified lines in pull request are covered.

:exclamation: Current head 9b94a47 differs from pull request most recent head 671654b. Consider uploading reports for the commit 671654b to get more accurate results

Additional details and impacted files
@@           Coverage Diff           @@
##           master    #1603   +/-   ##
=======================================
  Coverage   92.81%   92.81%
=======================================
  Files         347      347
  Lines       24555    24557    +2
=======================================
+ Hits        22791    22793    +2
  Misses       1764     1764

Impacted Files
Coverage Δ

verilog/tools/ls/verilog-language-server.h
100.00% <ø> (ø)

verilog/tools/ls/verilog-language-server.cc
98.55% <100.00%> (+0.04%)
:arrow_up:

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

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


add lexer error

Addresses #501

This is also good for WASM, where a simple mistake can cause a panic and break the whole page, needing a reload.

Hi @AaronRocinante thank you for your contribution. Please check the formatting of your code, then we can merge this work.

Codecov Report

Merging #552 into master will decrease coverage by 2.77%.
The diff coverage is 20%.

@@            Coverage Diff             @@
##           master     #552      +/-   ##
==========================================
- Coverage   44.72%   41.94%   -2.78%
==========================================
  Files          72       73       +1
  Lines       15536    16223     +687
  Branches     3964     4261     +297
==========================================
- Hits         6948     6805     -143
- Misses       6676     7496     +820
- Partials     1912     1922      +10

Impacted Files
Coverage Δ

parser/src/lexer.rs
55.35% <20%> (-29.4%)
:arrow_down:

vm/src/obj/objobject.rs
38.42% <0%> (-25.1%)
:arrow_down:

vm/src/obj/objtype.rs
37.17% <0%> (-23.52%)
:arrow_down:

vm/src/obj/objfloat.rs
45.81% <0%> (-20.66%)
:arrow_down:

vm/src/obj/objdict.rs
41.25% <0%> (-16.01%)
:arrow_down:

vm/src/obj/objsequence.rs
29.75% <0%> (-14.54%)
:arrow_down:

vm/src/obj/objiter.rs
61.26% <0%> (-12.74%)
:arrow_down:

vm/src/stdlib/string.rs
21.89% <0%> (-5.86%)
:arrow_down:

vm/src/stdlib/dis.rs
84.21% <0%> (-5.79%)
:arrow_down:

... and 32 more

Continue to review full report at Codecov.

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

@windelbouwman Thanks, it's been fixed.


[network] import libranet specs and cleanup onchain discovery spec

remove mentions of onchain discovery gossip protocol

TODO: need to include encrypted network address spec

@bors-libra r+

:pushpin: Commit 03d99d2 has been approved by mimoo

:hourglass: Testing commit 03d99d28ecbe5ed3ec3f4930136ad8f8e97c4e85 with merge c3b9549aafb45f6c8ed9be578be57f0e7182a81a...

:sunny: Test successful - checks-actions_land_blocking_test, checks-circle_commit_workflow
Approved by: mimoo
Pushing c3b9549aafb45f6c8ed9be578be57f0e7182a81a to master...


#19: Readme update

This PR update the readme to include processes that is involved in setting up the application.

closes #19

thank you so much!


[FLINK-16378][AZP] Disable Docker tests when running with JDK11

What is the purpose of the change
The docker tests are not passing on JDK11. Until this is implemented, we need to skip them
Brief change log

Skip tests using docker somehow in the run-nightly-tests.sh script.

Verifying this change
Set the jdk: jdk11 in azure-pipelines.yml and see the e2e tests passing

I addressed your comments:

ConnectedComponents is executed in all cases
passing the PROFILE is in a separate JIRA

Thank you for your review!


Add an option to disable SVGO completely

Hi,
Would it be possible to add an option to remove SVGO's optimisations from the loader completely?
Currently SVGO manages to strip my style tags, even when I set removeStyleElement: false (it strips the style tag from <defs> even after I've set every svgo plugin to false) 😕

Literally having exactly the same problem and came here to see if anybody else had as well.
Gonna take a look through the source and see if I can make a PR.

@sam3d I created a custom SVG loader and it turns out Vue's vue-template-compiler is the issue. See a relevant comment thread:
https://forum.vuejs.org/t/about-using-style-tags-inside-templates/7275
I've just changed my SVG structure to use attributes where possible and inline the styles where not. 😕

@andreasvirkus disabling SVGO is now included in 0.10.0, just pass svgo: false to loader options.

@andreasvirkus disabling SVGO is now included in 0.10.0, just pass svgo: false to loader options.

Thanks!
Just for example, I used this way in 'vue.config.js' and it worked:
chainWebpack: config => {
    const svgRule = config.module.rule('svg')
    svgRule.uses.clear()
    svgRule.use('vue-svg-loader').loader('vue-svg-loader').options({svgo: false})
},


Update index.html

i have added more images with full details of houses in your index.html file. it will give a better look to your website. please look into it and merge it into your base branch.

Thanks for your contribution.


Can't get the default value for Type

Tried to get the default value of the Type but can't seems to be able to do it. $Default is not available in the intellisense.
       constructor() { $Properties[             this.$Name = this.$Type[//Default value of type];]         }

Hi @jeeshenlee,
$Default is an extension method so you'll need to include the Typewriter.Extensions.Types namespace. e.g.
${
    using Typewriter.Extensions.Types;
}
...
$Properties[
    this.$Name = this.$Type[$Default];
]
...


Sync main with release for RHOAI 2.10

Syncing of main and release branches. Getting ready for RHOAI 2.10 release.
Description

How Has This Been Tested?

Original PRs were tested. Please see the two PRs' body to see testing instructions and results.
Merge criteria:

[x] The commits are squashed in a cohesive manner and have meaningful messages.
[ ] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[x] The developer has manually tested the changes and verified that the changes work

due to conflict, will open a separate PR


Trying to have captions with styled dataframes

Describe the bug
A clear and concise description of what the bug is.
When trying to make a caption for a styled dataframe, all that is shown is a blank caption tag.
<caption>Some caption here</caption>

Datapane table

To Reproduce
Steps to reproduce the behavior:

Make a styled pandas DataFrame
Render it with datapane
The caption tag should be above as raw html.

Thanks for the note @FriendlyUser - we currently don't support this, as we presumed that users would add text captions, but it sounds like this isn't the best behaviour and we can add it as a follow-up (currently only file-type blocks support captions). We'll keep you updated on the progress.
Thanks again!

Thanks for the note @FriendlyUser - we currently don't support this, as we presumed that users would add text captions, but it sounds like this isn't the best behaviour and we can add it as a follow-up (currently only file-type blocks support captions). We'll keep you updated on the progress.
Thanks again!

Yes - this should be a quick fix that we can get out very shortly - thanks for raising

Yes - this should be a quick fix that we can get out very shortly - thanks for raising

Apologies, it appears that styled tables do support captions, just add the caption argument when creating a dp.Table block, e.g.
dp.Table(df, caption="My Caption")

And the caption should appear under your table when viewing the report. See the Blocks page on the Demo report for sample code and demonstration.
Please let us know if that solves your issue - HTH!

Apologies, it appears that styled tables do support captions, just add the caption argument when creating a dp.Table block, e.g.
dp.Table(df, caption="My Caption")

And the caption should appear under your table when viewing the report. See the Blocks page on the Demo report for sample code and demonstration.
Please let us know if that solves your issue - HTH!


Added Nutanix troubleshooting section

Issue #, if available:
Description of changes:
This PR adds a Nutanix troubleshooting section in the documentation
Testing (if applicable):
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/cherry-pick release-0.14


Update table styles

After the HR-fix from last week, there were some tables
that were not updated.

fixed views
updated style to match hide top that was used previously

@mattmb style update


Use default in format targets.cmake

Fixes #108

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 87.15%. Comparing base (7f501e8) to head (9771018).

Additional details and impacted files
@@           Coverage Diff           @@
##           master     #260   +/-   ##
=======================================
  Coverage   87.15%   87.15%
=======================================
  Files          18       18
  Lines         514      514
=======================================
  Hits          448      448
  Misses         66       66

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Typo "@legacy_format"→"@legacy_format"

bold with escape characters
https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-help-alert-transact-sql?view=sql-server-ver15

@hyoshioka0128 : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Thanks.


Zlib version outdated

CARLA version: 0.9.12
Platform/OS: Windows 11
Problem you have experienced:
Zlib version 1.2.11 does not exist anymore and therefore installation script fails for windows
What you expected to happen:
Installation script to be successful
Steps to reproduce:
Other information (documentation you consulted, workarounds you tried):

git clone https://github.com/carla-simulator/carla
git checkout 0.9.12
move the assets downloaded from indicated file to the ../carla/Unreal/CarlaUE4/Content/Carla folder
make launch

Here is the trace log

This is the line that indicated the url in the build bat
https://github.com/carla-simulator/carla/blob/0.9.12/Util/InstallersWin/install_zlib.bat#L57

Hi, the temporary fix for this issue is to go into the file
"%carlaFolder%/Util/InstallersWin" and right click on "install_zlib.bat" and select "edit"
In this file you go to line 50 or search for "ZLIB_VERSION" and change the value from 1.2.11 to 1.2.12
This problem is adresses in #5337, but the Pull request is still in review


Add SSH manifest in README

Can be difficult to find how to enable SSH in CF, so I just add this small information into the README.

Hi, @shinji62,
The generate-bosh-lite-dev-manifest script in cf-release already merges in that SSH stub if it detects that it is present in the conventional location for diego-release, in https://github.com/cloudfoundry/cf-release/blob/master/scripts/generate-bosh-lite-dev-manifest#L26-L39, so including that stub as an explicit argument to the script is redundant. Diego SSH should already be enabled by default in the standard BOSH-Lite manifest. If that isn't the case in your BOSH-Lite deployments, please raise an issue on the cf-release repository about that script.
I agree that we need better documentation about how to configure CF (specifically CC and UAA) correctly to present the correct information for the CF CLI to connect to the Diego SSH proxy and to register an OAuth client for the proxy. I've added a story (https://www.pivotaltracker.com/story/show/107970964) to the Diego tracker to collect that disparate documentation in one place that's more easily discoverable.
Also, I see that the CF Dreddbot isn't able to verify that you're covered by a corporate CLA. You may want to make your membership in the 'pivotal-cf' GitHub organization public (see instructions at https://help.github.com/articles/publicizing-or-hiding-organization-membership/) before submitting other PRs to repositories in the 'cloudfoundry' or 'cloudfoundry-incubator' GitHub organizations.
Thanks,
Eric


Use pluralize instead of just adding 's'

Signed-off-by: Kevin Cormier<EMAIL_ADDRESS>

/cc @RobDolares


Please, provide the separate backport PR.
Thanks


Setup CI pipeline for benchmarking performance

This requires a few steps:

Converting our existing ad-hoc process for performance testing into a GitHub Action
Connecting GitHub Actions to dedicated hardware that can measure performance without noisy-neighbor issues
Formalizing the output of performance tests
Determining how and when these tests run
Determining how to produce action items from tests that are ran

Hi, I work on bencher! If you wanted to try it out (it's free!), it should just take a few clicks to install from the GitHub marketplace
We've got some more-detailed installation instructions (with pictures!) as well.
Let me know if I can help with anything :)

@kirbyquerby I tried enabling it, but we use docker for integration testing in our benchmarks -- this is because we benchmark against various databases.
I see in the bencher configuration you can depend on services based on docker, but can we actually just get access to a docker socket?

@kirbyquerby @odeke-em Are there any rate limits on bencher? I've been playing with things over at https://github.com/jzelinskie/benchpress and half of my pushes don't run. I was pulling my hair out thinking I had an invalid config, but it's not starting builds even without a config.
I'm experimenting with using docker-in-docker so that our test suite can run unmodified.

Hey @jzelinskie, Bencher runs only when there is a code change in .go files or when their is a configuration update. The reason for that is that in a PR, lots of diverse changes can happen but shouldn't be wasting precious machine time and CPU re-benchmarking. We shall document this on https://bencher.orijtech.com/

@odeke-em Thanks for the response -- that makes perfect sense.
Do you have any recommendations on how we could get access to the Docker daemon? Our tests use the Docker API to spin up/down images it needs for end-to-end tests. I've been playing with docker-in-docker, but that hasn't seemed to work.

I'm hesitant to provide direct access to the docker daemon because we run benchmarks on bare metal. This makes it tricky to ensure the state of the machine is reset after a benchmark is run. The current setup provides a intentionally trimmed-down set of docker features to try and minimize the attack surface -- I'm not well-versed enough to understand all the potential pitfalls of allowing arbitrary access to all of docker.
docker-in-docker seems promising, though -- I'll take a look at what it would take to make it work with bencher.


Fix link to options page

The link to the options docs from the setup page was broken because the extension was md not html. Possibly left over from older versions of docs?

Yes, we converted our old md files into html. Must've forgotten to translate some of the links. Though, can you PR this against master instead?


Pressing and holding a key only registers once (Fedora 28 with Wayland)

Which operating system does the issue occur on?
Fedora 28 (Linux x86_64)
If on linux, are you using X11 or Wayland?
Wayland
Alacritty version
shanssian:repos $ alacritty --version
alacritty 0.2.0

Issue
It seems like holding down a key is not obeyed. In vim, when I press and hold "j" to scroll down a file continually, j is only registered once.
In gnome-terminal, pressing and holding "j" behaves as expected, scrolling down the whole way.

Confirmed as a Wayland problem - logging back in with X11 Gnome, everything is fine.

Thanks for posting! This is actually a duplicate of #1257; maybe we should update the title there to be a bit more descriptive.


Update composer.json for symfony 6

Thanks @cedriclombardot ! The PR is failed. Let me merge, then try to fix it.


added x/bridge module

Epic: #7643
Сontinuation of https://github.com/osmosis-labs/osmosis/pull/7658
What is the purpose of the change
Added x/bridge module draft:

Package in the x folder
Proto contracts with queries and txs

Testing and Verifying
This change is is not adding any tests now, but it will be done later.
Documentation and Release Note

[x] Does this pull request introduce a new feature or user-facing behavior changes?
[ ] Changelog entry added to Unreleased section of CHANGELOG.md?

Where is the change documented?

[ ] Specification (x/{module}/README.md)
[ ] Osmosis documentation site
[ ] Code comments
[x] N/A

Sorry I missed that it is a draft...

No problem, your review was quite useful btw :) Thank you!


Performance issue: updateStore blocks rendering during diffing with large arrays in reactive store

While fixing this issue, I noticed another bug (that was happening and is still happening).
When diffing on SPA (or server actions), the actual updateStore function is very slow and blocks rendering badly.
https://github.com/brisa-build/brisa/blob/c172d4c0a6a3301699e85992faaa4a1607327b4f/packages/brisa/src/utils/rpc/resolve-rpc/index.ts#L24-L32
By doing store.set several times, it triggers notifications to update reactively, because it is a reactive map. We need to investigate what is the part that takes the longest, and then try to do this code in a non-blocking way.
It can be reproduced when you have large arrays in the store, which after deserialization always detects it as a new field in the store and is updated even if it is the same value.

We may be doing this operation twice. We have it here too 🤔:
https://github.com/brisa-build/brisa/blob/02286643517d8a6648f064c8e34a3d28b690a341/packages/brisa/src/utils/signals/index.ts#L26-L29


PCSX21.6.0 version 1.6.0

[ ] Have you signed the Contributor License Agreement?
[ ] Have you checked that there aren't other open pull requests for the same manifest update/change?
[ ] This PR only modifies one (1) manifest
[ ] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[ ] Does your manifest conform to the 1.4 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow
Microsoft Reviewers: Open in CodeFlow

Hi @Twig6943,
This package appears to install properly in a Windows 11 VM, but the executable doesn't actually install. Only portable.ini.

I noticed the installer has a portable package option - is it possible that this is being run instead of the normal installer mode?


uiGrid column sorting

I am persisting the column sort information and I am trying to set the grid sorted using the function  $scope.gridApi.grid.sortColumn($scope.gridApi.grid.columns[5], uiGridConstants.DESC, true).
But this is apparently not working. First of all I wanted to see if I am calling this function right. Is there any other way to get this sort working?
Highly appreciate your response on this matter.
Thank you,
BM

Take a look at saveState, which does exactly what you're seeking - it persists some or all of the grid state, and then reloads it on request.  You may find it easier to use that feature than roll your own, or alternatively you could look through how it persists sort.

Finally got that working with adding the sort to the column definition.
Thank you for your response.


Add default configuration override, if present

Adding the ability to pull default configuration, if it exists.

Thanks jeffery, that's helpful!
@PolarFox Could you merge this? I don't have write access to the repository...


Fixing workflow package path calculation in WorkflowPackageManager

This fixes https://github.com/Adobe-Consulting-Services/acs-aem-commons/issues/2416

Pull Request Test Coverage Report for Build 6023

0 of 3 (0.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.002%) to 55.244%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

bundle/src/main/java/com/adobe/acs/commons/workflow/impl/WorkflowPackageManagerImpl.java
0
3
0.0%

Totals

Change from base Build 6017:
-0.002%

Covered Lines:
15659

Relevant Lines:
28345

💛  - Coveralls


[Feat] - Gradle cleanup

There are some small unnecessary or deprecated thing in project's gradle files like:

Since Kotlin 1.4.0, there's no need to add standard library as a dependency
Since AGP 4.1 compileSdkVersion, targetSdkVersion and minSdkVersion are deprecated in favor of shorter properties of compileSdk, targetSdk and minSdk
Since AGP 4.2 java 1.8 support is enabled by default. We could mention this in ReadMe.

See original article for more info. I have these changes ready in my fork and could create a pull request if you are OK with it.

Hey @Alireza-Farahani thanks for raising this, please be free to create a PR so we can improve this ^^
We just need to be sure we keep backward compatibility.


onMessage blocking all other listeners

Somehow when onMessage is attached all other listeners are ignored and only onMessage handler is being executed.

This one is weird.
Televerse now depends on HandlerScope to add listeners to the events. This is to simplify the resource usage and to achieve #84. As this issue was raised  , I tested the flow for the following snippet:
bot.command(...);
bot.command(..);
bot.onMessage(...);

And interestingly found that even though all listeners are added to the handler scopes list using List.add somehow the listeners are added to the first position.
Hence, onMessage listener is always called when an update is occurred, ignoring all other handlers.

Using List.reversed seems to solve this issue simply. But, I need to keep an eye on this.

@im-trisha, knocking your doors, can I get some help here? :)


Update to Jetty 9.4.9

Jetty 9.4.9 includes a large number of bug fixes and improvements. It is recommended that all users upgrade as soon as they are able. A full list of changes for this release is listed at the end of this email.

Fixed in 3ace5453afb49c4281f38fe9cc236793953dcbea


fix multiple devtools issues

What's changed, or what was fixed?

item 1
item 2

Fixes: #6875, #6978, #6979, #6873, #6803, #6980, #6687, #6617
Target Live Date: 2018-12-17

[x] This has been reviewed and approved by @kaycebasques
[x] I have run npm test locally and all tests pass.
[x] I have added the appropriate type-something label.
[x] I've staged the site and manually verified that my content displays correctly.

CC: @petele

Whoops!
There were 54 warnings that will prevent this PR from being merged. Please take a look, and either fix, or provide a justification for why they can't be fixed.
WARNINGS
src/content/en/tools/chrome-devtools/device-mode/index.md#L68 - Line must be at most 100 characters
src/content/en/tools/chrome-devtools/device-mode/index.md#L74 - Line must be at most 100 characters
src/content/en/tools/chrome-devtools/device-mode/index.md#L159 - Line must be at most 100 characters
src/content/en/tools/chrome-devtools/device-mode/index.md#L284 - Line must be at most 100 characters
src/content/en/tools/chrome-devtools/index.md#L53 - Common typo found: 'javascript' Should it be 'JavaScript'?
src/content/en/tools/chrome-devtools/index.md#L111 - Common typo found: 'javascript' Should it be 'JavaScript'?
src/content/en/tools/chrome-devtools/index.md#L112 - Common typo found: 'javascript' Should it be 'JavaScript'?
src/content/en/tools/chrome-devtools/index.md#L115 - Common typo found: 'javascript' Should it be 'JavaScript'?
src/content/en/tools/chrome-devtools/index.md#L30 - Line must be at most 100 characters
src/content/en/tools/chrome-devtools/index.md#L31 - Line must be at most 100 characters
src/content/en/tools/chrome-devtools/index.md#L33 - Line must be at most 100 characters
src/content/en/tools/chrome-devtools/index.md#L41 - Line must be at most 100 characters
src/content/en/tools/chrome-devtools/index.md#L49 - Line must be at most 100 characters
src/content/en/tools/chrome-devtools/javascript/guides/blackbox-chrome-extension-scripts.md#L13 - Common typo found: 'javascript' Should it be 'JavaScript'?
src/content/en/tools/chrome-devtools/javascript/guides/blackbox-chrome-extension-scripts.md#L28 - Common typo found: 'javascript' Should it be 'JavaScript'?
src/content/en/tools/chrome-devtools/javascript/guides/blackbox-chrome-extension-scripts.md#L20 - Line must be at most 100 characters
src/content/en/tools/chrome-devtools/open.md#L47 - Common typo found: 'chrome' Should it be 'Chrome'?
src/content/en/tools/chrome-devtools/open.md#L18 - Common typo found: 'node' Should it be 'Node'?
src/content/en/tools/chrome-devtools/open.md#L68 - Common typo found: 'MacOS' Should it be 'macOS'? See: https://developers.google.com/style/word-list#macos
src/content/en/tools/chrome-devtools/open.md#L51 - Line must be at most 100 characters
src/content/en/tools/chrome-devtools/shortcuts.md#L354 - Common typo found: 'javascript' Should it be 'JavaScript'?
src/content/en/tools/chrome-devtools/shortcuts.md#L182 - Common typo found: 'node' Should it be 'Node'?
src/content/en/tools/chrome-devtools/shortcuts.md#L182 - Common typo found: 'node' Should it be 'Node'?
src/content/en/tools/chrome-devtools/shortcuts.md#L187 - Common typo found: 'node' Should it be 'Node'?
src/content/en/tools/chrome-devtools/shortcuts.md#L187 - Common typo found: 'node' Should it be 'Node'?
src/content/en/tools/chrome-devtools/shortcuts.md#L192 - Common typo found: 'node' Should it be 'Node'?
src/content/en/tools/chrome-devtools/shortcuts.md#L79 - Line must be at most 100 characters
src/content/en/tools/chrome-devtools/shortcuts.md#L80 - Line must be at most 100 characters
src/content/en/tools/chrome-devtools/shortcuts.md#L119 - Line must be at most 100 characters
src/content/en/tools/chrome-devtools/shortcuts.md#L125 - Line must be at most 100 characters
src/content/en/tools/chrome-devtools/shortcuts.md#L151 - Line must be at most 100 characters
src/content/en/tools/chrome-devtools/shortcuts.md#L152 - Line must be at most 100 characters
src/content/en/tools/chrome-devtools/shortcuts.md#L182 - Line must be at most 100 characters
src/content/en/tools/chrome-devtools/shortcuts.md#L187 - Line must be at most 100 characters
src/content/en/tools/chrome-devtools/shortcuts.md#L194 - Line must be at most 100 characters
src/content/en/tools/chrome-devtools/shortcuts.md#L240 - Line must be at most 100 characters
src/content/en/tools/chrome-devtools/shortcuts.md#L241 - Line must be at most 100 characters
src/content/en/tools/chrome-devtools/shortcuts.md#L245 - Line must be at most 100 characters
src/content/en/tools/chrome-devtools/shortcuts.md#L246 - Line must be at most 100 characters
src/content/en/tools/chrome-devtools/shortcuts.md#L255 - Line must be at most 100 characters
src/content/en/tools/chrome-devtools/shortcuts.md#L256 - Line must be at most 100 characters
src/content/en/tools/chrome-devtools/shortcuts.md#L260 - Line must be at most 100 characters
src/content/en/tools/chrome-devtools/shortcuts.md#L261 - Line must be at most 100 characters
src/content/en/tools/chrome-devtools/shortcuts.md#L318 - Line must be at most 100 characters
src/content/en/tools/chrome-devtools/shortcuts.md#L319 - Line must be at most 100 characters
src/content/en/tools/chrome-devtools/shortcuts.md#L323 - Line must be at most 100 characters
src/content/en/tools/chrome-devtools/shortcuts.md#L324 - Line must be at most 100 characters
src/content/en/tools/chrome-devtools/shortcuts.md#L327 - Line must be at most 100 characters
src/content/en/tools/chrome-devtools/shortcuts.md#L328 - Line must be at most 100 characters
src/content/en/tools/chrome-devtools/shortcuts.md#L329 - Line must be at most 100 characters
src/content/en/tools/chrome-devtools/shortcuts.md#L354 - Line must be at most 100 characters
src/content/en/tools/chrome-devtools/shortcuts.md#L364 - Line must be at most 100 characters
src/content/en/tools/chrome-devtools/shortcuts.md#L369 - Line must be at most 100 characters
src/content/en/tools/chrome-devtools/shortcuts.md#L460 - Line must be at most 100 characters

:tada: This has been pushed live to https://developers.google.com/web/


E-Commerce Build

What is the context of this PR?
The schema for latest e-commerce survey.
Trello
Slides
Quick Launch
To do:

External link on intro page when the link is ready.
Change q_code for radio options with playback (Slides show multiple q_codes, radio can only have one). Waiting to hear from Donna.

Notes:

Changed 1 decimal to 2 decimal places.

How to review
Ensure:

Everything matches slides.
Routing is correct (I also changed author routing to reduce the no. of routing/skips, ie where author has inverse logic)

Seems weird that they have section introductions for everything apart from the first?
I can't see any obvious issues at the moment, but will have another quick scan through.

Regarding percentage, Donna will soon confirm, where it should be 1 or 2 decimal places...

Since the JS has no context of the number of decimal places defined by the schema. The totaliser will also default with decimal places.


Option to choose between a Detached Signature and a Clearsigned Signature

Describe the feature …
Currently, when performing a signing cryptography operation, the output is an encrypted message instead of a signed message. It would be beneficial to have the option to choose between a detached signature and a clear-signed signature when clicking 'Sign'.

Currently, when performing a signing cryptography operation, the output is an encrypted message instead of a signed message.

A detached signed message typically starts with '-----BEGIN PGP SIGNATURE-----', while a clear-signed message begins with '-----BEGIN PGP SIGNED MESSAGE-----'. Instead, when clicking 'Sign', the message starts with '-----BEGIN PGP MESSAGE-----', which indicates that it is an encrypted message.


Don't clone shallow for splitting

Q
A

Bug fix?
yes

New feature?
no

BC breaks?
no

Deprecations?
no

Tickets

License
MIT

In some cases this doesn't bring-up all branches, secondly GitHub recommends against using shallow clones.

  ERR  error: The destination you provided is not a full refname (i.e.,
  ERR  starting with "refs/"). We tried to guess what you meant by:
  ERR
  ERR  - Looking for a ref that matches '3.0' on the remote side.
  ERR  - Checking if the <src> being pushed ('69b35477d55bdc5d4dfb3c2afea6c16fde267bee')
  ERR    is a ref in "refs/{heads,tags}/". If so we add a corresponding
  ERR    refs/{heads,tags}/ prefix on the remote side.
  ERR
  ERR  Neither worked, so we gave up. You must fully qualify the ref.
  ERR  hint: The <src> part of the refspec is a commit object.
  ERR  hint: Did you mean to create a new branch by pushing to
  ERR  hint: '69b35477d55bdc5d4dfb3c2afea6c16fde267bee:refs/heads/3.0'?
  ERR  error: failed to push some refs to 'github.com:hubkit-sandbox/docs.git'

This is why we can't have nice things!


Fix fileInfo

Based on the patch that addresses this in TW core: https://github.com/Jermolene/TiddlyWiki5/pull/4630
You must have that patch installed to test this PR.
This fixes a couple of things. The first was to catch a null value in the FileSystemMonitor.js watch functions that would kick a fatal error every once in a while.
Next, we fix a race condition in MultiWikiAdaptor.js where a brand new tiddler was being saved to disk before being saved into server memory and then pushed to any open clients. This caused all filters in the $:/config/FileSystemPaths that relied on querying tags or fields to fail silently. Calling the Internal Save first fixes that.
I also incorporated the flow from the TW fix-fileInfo patch that tests for custom file extensions filters ($:/config/FileSystemExtensions) and a new path-on-disk every time a tiddler is saved, deleting the old file if necessary.
Testing this against my wiki-in-progress now, but this seems to have unblocked me from using Bob for my latest wiki.
Thanks,
Joshua F

I have been trying to track down that race condition for months, thank you. I need to look through all of this so I have a clear idea of the changes before I merge it but all of this looks great.

This took away a "create tiddler" loop in the browser console for me, which I suspect is a good thing :)

I plan on using everything here, but I don't want to merge anything that requires a change to the core so that part is going to wait until the next version of tiddlywiki is released with your changed merged there.
I would like to merge the changes that don't require any core changes. I think that is everything but some of the changes to MultiWikiAdaptor.js.
I can't find a way to merge only specific files, if you can either split this into two pull requests, one that doesn't require core changes and the other with the updates from the next version of tiddlywiki, I can merge the first one now.
If not I am going to try and just manually change the affected files, I am hoping to release a new version of Bob this weekend.

Hi @inmysocks
Wish I had seen this earlier, but work has me slammed this weekend. Looks like you have been importing all the stuff compatible with TW5.1.22 core so far. Awesome! I'll re-factor this PR to just be about the changes for the FileSystemExtensions changes in the TW PR.
If I notice anything else as you incorporate these updates, I'll open a new issue/PR. I'm looking to use Bob to host a few different public projects really soon. Awesome to see this fix going in, and I do want to work with you on the Federation stuff (My RPG wiki edition is going to be killer with that feature). But that project is a few down the list. ;)
Thanks!
Joshua F

Closing and re-targeting against master. I actually think you could merge all my changes here without any dependency on the similar changes in the TW core plugins. I want to make 100% sure tho.


Localdeploy

added local deploy script

@KingYiuWoo the tests for labels are taking too long - can we get a PR to slim them down? 90 minutes is crazy haha


feat: ignoreUseRefValue, ignore token converted to original ref

fixes https://github.com/divriots/style-dictionary-to-figma/issues/17

Yeah nested references in value objects would be quite tricky for sure, glad it works good enough for now. Will release it


Automatically generate API overview documentation

This PR should address #50922. It basically:

Generate \since tags from doxgen and git (it may not be perfect, but it's a fairly comprehensive start);
Manually fix add some based on current information from doc/develop/api.overview.rst;
Add \version (showing stability level) based on information from doc/develop/api.overview.rst;
Use all new info (\since and \version) to generate the new API overview page, which is basically an improved version of doxygen own "Modules index" page.

 Two things that still stand out:

To parse the doxygen XML info, I've used its own "doxmlparser" Python lib, but it needs to be installed from the sources, as there's no package on PyPi. There's an open issue at doxygen repo about it: https://github.com/doxygen/doxygen/issues/8848
The new API overview page points to the doxygen documentation, not for any RST that may exist for it. Since the page now comes from doxygen, we could a) add a new xrefitem tag to reference it, but then we'd have doxygen pointing to RST and RST pointing to doxygen, which could be an issue; or b) have another file to map RST pages for some doxygen groups, but it would be another burden to maintain. Any thoughts about this?

Fixes #50922

What problem are we solving here? What is the benefit of having a long list of when a group of API functions were introduced?

What problem are we solving here? What is the benefit of having a long list of when a group of API functions were introduced?

this replaces the old API table which was manually managed, it will also add stability level, based on version of each API derived automatically as well.

My opinion: I don't see how the new page helps developers. It's just a longer page that will take some more time (and RAM) to get rendered. Imagine, CAN API jumps from 1.0.0 to 2.0.0. What does this tell me, that it has breaking changes? Where are these explained? Also, who will control semantic versioning is properly handled in such long list of APIs/sub-APIs? And as said, @since at an API level is mostly redundant to me, unless @since is tied to the @version field.
IIRC there was a PR deleting that table, I think is what makes more sense. For a complete API table, one can already browse Doxygen pages.

v2:

Using Sphinx extensions to generate the API table;
Rebased.

Looks like adding myself as a reviewer messed up the list of already lost reviewers, maybe because I was on the GH mobile app? Sorry about that - hopefully the bot will re-add folks next time a workflow runs

A quick look at the DT side makes it clear to me that something is wrong with the automation.

Emphasis on quick look: my comments are not meant to be exhaustive. I am not saying "please fix just these issues and all will be well". I am saying "something looks quite wrong here based on a couple of examples I found while spot checking and IMO it should be investigated"

v3:

No more mandatory requiring doxmlparser module - if it's not there, a warning will be produced during documentation build, and the overview table will not be generated, but everything else will be built;
Using doxygen XML build dir from doxyrunner configuration;
Base URL fro doxygen is now a configurable option;
Overview table built from docutils classes instead of hardcoded HTML;
Use black to reformat the api_overview.py file.

v4:

Include doxmlparser code directly.

https://builds.zephyrproject.io/zephyr/pr/61994/docs/develop/api/overview.html

v4:

Include doxmlparser code directly.

can you work with upstream Doxygen to provide them with a CI workflow that publishes the package on PyPI instead? It should be fairly easy. An example workflow https://github.com/nrfconnect/doc-sphinx-ncs-theme/blob/main/.github/workflows/default.yml

v5:

Dropped patch that added since automatically from git log;
Fixed CI issues with doxmlparser code;
Rebased.

we can also look into using pip install -i https://test.pypi.org/simple/ doxmlparser until there is an official release to help with getting populating the versioning information and having something useful by the next release. We do not need updated doxygen version itself, just this python package anyways.

v6:

Instead of including doxmlparser code, use it from TestPyPI for now (will update to use PyPI as soon as it's available there);
Added a simple table to explain the meaning of column "version";
Rebased.

v7:

Removed astray PYTHONPATH from CMakeLists.txt;
Hierarchy of doxygen groups represented via - instead of space indentation, so it works on PDF;
Rebased.

CI failure is unrelated, quick fix at https://github.com/zephyrproject-rtos/zephyr/pull/64807

v9:

Rebased to get the fix for CI issue.

BTW I spotted this "cbvprintf processing flags." group showing up, but it should be internal? Guess there might be others.

BTW I spotted this "cbvprintf processing flags." group showing up, but it should be internal? Guess there might be others.

Maybe - but that would imply some way of marking them internal - a custom tag, defining some directories as internal, etc.  Not sure if it belongs on this PR, or a future one.

BTW I spotted this "cbvprintf processing flags." group showing up, but it should be internal? Guess there might be others.

Maybe - but that would imply some way of marking them internal - a custom tag, defining some directories as internal, etc.  Not sure if it belongs on this PR, or a future one.

Right but the reason I'm pointing it here is that there it is not showing in Doxygen documentation (since it starts with the Z_ prefix, that's the intended behavior as it's currently one of the ways to exclude internal stuff from the doc - https://github.com/zephyrproject-rtos/zephyr/blob/56f73bde0fb086fae38cfb5afb2f2500a340b39b/doc/zephyr.doxyfile.in#L1018), so I just want to make sure the mismatch is looked into.

BTW I spotted this "cbvprintf processing flags." group showing up, but it should be internal? Guess there might be others.

Maybe - but that would imply some way of marking them internal - a custom tag, defining some directories as internal, etc.  Not sure if it belongs on this PR, or a future one.

Right but the reason I'm pointing it here is that there it is not showing in Doxygen documentation (since it starts with the Z_ prefix, that's the intended behavior as it's currently one of the ways to exclude internal stuff from the doc -
https://github.com/zephyrproject-rtos/zephyr/blob/56f73bde0fb086fae38cfb5afb2f2500a340b39b/doc/zephyr.doxyfile.in#L1018
), so I just want to make sure the mismatch is looked into.

Ha, that should make it easier, then =D
But that exclude list also excludes things that start with _, and that would exclude USB-C stuff. Guess I'll skip only when it starts with Z_.

BTW I spotted this "cbvprintf processing flags." group showing up, but it should be internal? Guess there might be others.

Maybe - but that would imply some way of marking them internal - a custom tag, defining some directories as internal, etc.  Not sure if it belongs on this PR, or a future one.

Right but the reason I'm pointing it here is that there it is not showing in Doxygen documentation (since it starts with the Z_ prefix, that's the intended behavior as it's currently one of the ways to exclude internal stuff from the doc -
https://github.com/zephyrproject-rtos/zephyr/blob/56f73bde0fb086fae38cfb5afb2f2500a340b39b/doc/zephyr.doxyfile.in#L1018
), so I just want to make sure the mismatch is looked into.

Ha, that should make it easier, then =D
But that exclude list also excludes things that start with _, and that would exclude USB-C stuff. Guess I'll skip only when it starts with Z_.

Wait I think the reason why the cbprintf group is not showing might not be the Z_ (since the USB-C groups are showing just fine despite their _) after all but rather the fact that it's actually empty. If not too complicated, this might be worth replicating this behavior.

BTW I spotted this "cbvprintf processing flags." group showing up, but it should be internal? Guess there might be others.

Maybe - but that would imply some way of marking them internal - a custom tag, defining some directories as internal, etc.  Not sure if it belongs on this PR, or a future one.

Right but the reason I'm pointing it here is that there it is not showing in Doxygen documentation (since it starts with the Z_ prefix, that's the intended behavior as it's currently one of the ways to exclude internal stuff from the doc -
https://github.com/zephyrproject-rtos/zephyr/blob/56f73bde0fb086fae38cfb5afb2f2500a340b39b/doc/zephyr.doxyfile.in#L1018
), so I just want to make sure the mismatch is looked into.

Ha, that should make it easier, then =D
But that exclude list also excludes things that start with _, and that would exclude USB-C stuff. Guess I'll skip only when it starts with Z_.

Wait I think the reason why the cbprintf group is not showing might not be the Z_ (since the USB-C groups are showing just fine despite their _) after all but rather the fact that it's actually empty. If not too complicated, this might be worth replicating this behavior (after having confirmed the theory)?

It seems the group is not empty: https://github.com/zephyrproject-rtos/zephyr/blob/main/include/zephyr/sys/cbprintf.h#L267
But doxygen generates the group nevertheless, one just need to know where to look: https://docs.zephyrproject.org/latest/doxygen/html/group__Z__CBVPRINTF__PROCESS__FLAGS.html
However, it will be empty because I guess the internal symbols were excluded due the prefix.
This seems to be the only group starting with Z_, and skipping it shall be easy.

v9:

Don't use string formats to join paths or urls
Skip groups starting in Z_, as those shall be internal;
Improve error handling for missing groups;
Formatting issues;
Reword API version meaning description;
Rebased.

-- MCUmgr
---- MCUmgr callback API
------ MCUmgr fs_mgmt callback API
------ MCUmgr img_mgmt callback API
------ MCUmgr os_mgmt callback API
------ MCUmgr settings_mgmt callback API
---- MCUmgr handler API
---- MCUmgr img_mgmt API
---- MCUmgr mgmt API 	1.0.0 	1.11
---- MCUmgr transport SMP API

This looks awful, the whole thing needs to go and just have 2 MCUmgr versions, not 10 - MCUmgr and MCUmgr client (which, apparently, is not even showing right now). Auxdisplay is missing from the list.

Those come from @defgroup , @addgroup and @ingroup definitions - if they don't make sense, maybe refining the groups is the way to go?

-- MCUmgr
---- MCUmgr callback API
------ MCUmgr fs_mgmt callback API
------ MCUmgr img_mgmt callback API
------ MCUmgr os_mgmt callback API
------ MCUmgr settings_mgmt callback API
---- MCUmgr handler API
---- MCUmgr img_mgmt API
---- MCUmgr mgmt API 	1.0.0 	1.11
---- MCUmgr transport SMP API

This looks awful, the whole thing needs to go and just have 2 MCUmgr versions, not 10 - MCUmgr and MCUmgr client (which, apparently, is not even showing right now). Auxdisplay is missing from the list.

Those come from @defgroup , @addgroup and @ingroup definitions - if they don't make sense, maybe refining the groups is the way to go?

It makes sense for how they are laid out in the documentation, it does not make sense at all from an API version perspective.

v10:

Fixed bug on joining urls;
Rebased.

-- MCUmgr
---- MCUmgr callback API
------ MCUmgr fs_mgmt callback API
------ MCUmgr img_mgmt callback API
------ MCUmgr os_mgmt callback API
------ MCUmgr settings_mgmt callback API
---- MCUmgr handler API
---- MCUmgr img_mgmt API
---- MCUmgr mgmt API 	1.0.0 	1.11
---- MCUmgr transport SMP API

This looks awful, the whole thing needs to go and just have 2 MCUmgr versions, not 10 - MCUmgr and MCUmgr client (which, apparently, is not even showing right now). Auxdisplay is missing from the list.

Those come from @defgroup , @addgroup and @ingroup definitions - if they don't make sense, maybe refining the groups is the way to go?

It makes sense for how they are laid out in the documentation, it does not make sense at all from an API version perspective.

About the MCUmgr client, I don't see it here now: https://docs.zephyrproject.org/latest/doxygen/html/group__mcumgr.html
Maybe is missing a defgroup or addtogroup on docs?
In any case, this just shows the hierarchy of groups on doxygen, why would the way the APIs are grouped for documentation not work to show their versions? Moving forward, as more @version and @since tags are added to doxygen docs, the more complete the table will be, and hopefully, the less "awful" it'll look.

-- MCUmgr
---- MCUmgr callback API
------ MCUmgr fs_mgmt callback API
------ MCUmgr img_mgmt callback API
------ MCUmgr os_mgmt callback API
------ MCUmgr settings_mgmt callback API
---- MCUmgr handler API
---- MCUmgr img_mgmt API
---- MCUmgr mgmt API 	1.0.0 	1.11
---- MCUmgr transport SMP API

This looks awful, the whole thing needs to go and just have 2 MCUmgr versions, not 10 - MCUmgr and MCUmgr client (which, apparently, is not even showing right now). Auxdisplay is missing from the list.

Those come from @defgroup , @addgroup and @ingroup definitions - if they don't make sense, maybe refining the groups is the way to go?

It makes sense for how they are laid out in the documentation, it does not make sense at all from an API version perspective.

About the MCUmgr client, I don't see it here now: https://docs.zephyrproject.org/latest/doxygen/html/group__mcumgr.html Maybe is missing a defgroup or addtogroup on docs?

@jheiskan81 please address this

In any case, this just shows the hierarchy of groups on doxygen, why would the way the APIs are grouped for documentation not work to show their versions? Moving forward, as more @version and @since tags are added to doxygen docs, the more complete the table will be, and hopefully, the less "awful" it'll look.

Because they're not APIs, this is not how MCUmgr works, they are services that a remote device e.g. a mobile phone communicates with, they're not something someone calls in an app (i.e. because there are no functions to call)

-- MCUmgr
---- MCUmgr callback API
------ MCUmgr fs_mgmt callback API
------ MCUmgr img_mgmt callback API
------ MCUmgr os_mgmt callback API
------ MCUmgr settings_mgmt callback API
---- MCUmgr handler API
---- MCUmgr img_mgmt API
---- MCUmgr mgmt API 	1.0.0 	1.11
---- MCUmgr transport SMP API

This looks awful, the whole thing needs to go and just have 2 MCUmgr versions, not 10 - MCUmgr and MCUmgr client (which, apparently, is not even showing right now). Auxdisplay is missing from the list.

Those come from @defgroup , @addgroup and @ingroup definitions - if they don't make sense, maybe refining the groups is the way to go?

It makes sense for how they are laid out in the documentation, it does not make sense at all from an API version perspective.

About the MCUmgr client, I don't see it here now: https://docs.zephyrproject.org/latest/doxygen/html/group__mcumgr.html Maybe is missing a defgroup or addtogroup on docs?

@jheiskan81 please address this

In any case, this just shows the hierarchy of groups on doxygen, why would the way the APIs are grouped for documentation not work to show their versions? Moving forward, as more @version and @since tags are added to doxygen docs, the more complete the table will be, and hopefully, the less "awful" it'll look.

Because they're not APIs, this is not how MCUmgr works, they are services that a remote device e.g. a mobile phone communicates with, they're not something someone calls in an app (i.e. because there are no functions to call)

@nordicjm & @edersondisouza https://github.com/zephyrproject-rtos/zephyr/pull/65289 Please check is this fixing

-- MCUmgr
---- MCUmgr callback API
------ MCUmgr fs_mgmt callback API
------ MCUmgr img_mgmt callback API
------ MCUmgr os_mgmt callback API
------ MCUmgr settings_mgmt callback API
---- MCUmgr handler API
---- MCUmgr img_mgmt API
---- MCUmgr mgmt API 	1.0.0 	1.11
---- MCUmgr transport SMP API

This looks awful, the whole thing needs to go and just have 2 MCUmgr versions, not 10 - MCUmgr and MCUmgr client (which, apparently, is not even showing right now). Auxdisplay is missing from the list.

Those come from @defgroup , @addgroup and @ingroup definitions - if they don't make sense, maybe refining the groups is the way to go?

It makes sense for how they are laid out in the documentation, it does not make sense at all from an API version perspective.

About the MCUmgr client, I don't see it here now: https://docs.zephyrproject.org/latest/doxygen/html/group__mcumgr.html Maybe is missing a defgroup or addtogroup on docs?

@jheiskan81 please address this

In any case, this just shows the hierarchy of groups on doxygen, why would the way the APIs are grouped for documentation not work to show their versions? Moving forward, as more @version and @since tags are added to doxygen docs, the more complete the table will be, and hopefully, the less "awful" it'll look.

Because they're not APIs, this is not how MCUmgr works, they are services that a remote device e.g. a mobile phone communicates with, they're not something someone calls in an app (i.e. because there are no functions to call)

@nordicjm & @edersondisouza #65289 Please check is this fixing a problem?

Yes, resolves that problem. @edersondisouza now with that, there will be an additional 3 entries, MCUmgr will have 13 entries when it needs 2!

-- MCUmgr
---- MCUmgr callback API
------ MCUmgr fs_mgmt callback API
------ MCUmgr img_mgmt callback API
------ MCUmgr os_mgmt callback API
------ MCUmgr settings_mgmt callback API
---- MCUmgr handler API
---- MCUmgr img_mgmt API
---- MCUmgr mgmt API 	1.0.0 	1.11
---- MCUmgr transport SMP API

This looks awful, the whole thing needs to go and just have 2 MCUmgr versions, not 10 - MCUmgr and MCUmgr client (which, apparently, is not even showing right now). Auxdisplay is missing from the list.

Those come from @defgroup , @addgroup and @ingroup definitions - if they don't make sense, maybe refining the groups is the way to go?

It makes sense for how they are laid out in the documentation, it does not make sense at all from an API version perspective.

About the MCUmgr client, I don't see it here now: https://docs.zephyrproject.org/latest/doxygen/html/group__mcumgr.html Maybe is missing a defgroup or addtogroup on docs?

@jheiskan81 please address this

In any case, this just shows the hierarchy of groups on doxygen, why would the way the APIs are grouped for documentation not work to show their versions? Moving forward, as more @version and @since tags are added to doxygen docs, the more complete the table will be, and hopefully, the less "awful" it'll look.

Because they're not APIs, this is not how MCUmgr works, they are services that a remote device e.g. a mobile phone communicates with, they're not something someone calls in an app (i.e. because there are no functions to call)

@nordicjm & @edersondisouza #65289 Please check is this fixing a problem?

Yes, resolves that problem. @edersondisouza now with that, there will be an additional 3 entries, MCUmgr will have 13 entries when it needs 2!

The more the merrier =D
On a serious note, I think this is a valid concern, and there are probably other API/stuff being overexposed now. But we need some convention to be able to identify them (starting with Z_ or _, for instance), and this convention need to be applied. As Z_ seems too "Zephyr internal-ish", I'd prefer _, but would need to fix USB-C as well.
I can update this PR to do just that, and after it's in, people could revisit doxygen groups to fix visibility. Thoughts?

v11:

Ignore groups started with _;
Remove leading underscore from some USB doxgen groups (they don't seem to be hidden, if that's the idea, this patch can be reverted);
Rebased.

Build failure seems unrelated, fix at https://github.com/zephyrproject-rtos/zephyr/pull/65941

Still way too many MCUmgr groups. I haven't read the thread to see if there is a discussion about the version numbering but why was it picked? How do you update a version? What does the version reference i.e. how to tell if something is experimental, stable, retired, etc.?

Still way too many MCUmgr groups. I haven't read the thread to see if there is a discussion about the version numbering but why was it picked? How do you update a version? What does the version reference i.e. how to tell if something is experimental, stable, retired, etc.?

The meaning of version is explained at https://github.com/zephyrproject-rtos/zephyr/blob/aca7fdafb2251b529d1cd2dac5367c4ea3fccc67/doc/develop/api/overview.rst?plain=1. The tl;dr is that for this PR, 0.1 is experimental, 0.8 is unstable and 1.0 is stable, replacing previous wording. To change it, it's just change the version tag on the doxygen.
About the MCUmgr groups, there's a way to hide them from this table, which is by having their names starting with _ (or z_). I can patch the MCUmgr in this PR to show the result - then other APIs can be updated later.

About the MCUmgr groups, there's a way to hide them from this table, which is by having their names starting with _ (or z_). I can patch the MCUmgr in this PR to show the result - then other APIs can be updated later.

This is absolutely a no.

Could you please elaborate why? Using the name convention already applies for other doxygen symbols, what's the problem about groups also having them?

-- MCUmgr
---- MCUmgr callback API
------ MCUmgr fs_mgmt callback API
------ MCUmgr img_mgmt callback API
------ MCUmgr os_mgmt callback API
------ MCUmgr settings_mgmt callback API
---- MCUmgr handler API
---- MCUmgr img_mgmt API
---- MCUmgr mgmt API 	1.0.0 	1.11
---- MCUmgr transport SMP API

@nordicjm

Because they're not APIs, this is not how MCUmgr works, they are services that a remote device e.g. a mobile phone communicates with, they're not something someone calls in an app (i.e. because there are no functions to call)

that is funny when each group here ends with a big fat API
putting all of this aside, this same list is here https://docs.zephyrproject.org/latest/doxygen/html/group__mcumgr.html, so if those are no APIs, they should not be advertised as such or they should be moved to some internal category or hidden using some doxygen magic.

About the MCUmgr groups, there's a way to hide them from this table, which is by having their names starting with _ (or z_). I can patch the MCUmgr in this PR to show the result - then other APIs can be updated later.

no, please lets not go there, if something is available via doxygen as an API, it belongs here as well, we should not show it somewhere and hide somewhere else. If some APIs are not to be used by applications etc, they need to be marked as such.

It makes sense for how they are laid out in the documentation, it does not make sense at all from an API version perspective.

we can also live with one single version for the top level  group and the version would apply to all sub-groups.

Skip groups starting in Z_, as those shall be internal;

We should not be doing something like this here, we need to use the official way of excluding some groups or APIs as internal and AFAIK there are many ways where this can be done. This empty group should be a group at all if it only includes some private functions, I would remove that in some other PR. This PR is definitely not about changing hierachies and defining what internal and what is public.

-- MCUmgr
---- MCUmgr callback API
------ MCUmgr fs_mgmt callback API
------ MCUmgr img_mgmt callback API
------ MCUmgr os_mgmt callback API
------ MCUmgr settings_mgmt callback API
---- MCUmgr handler API
---- MCUmgr img_mgmt API
---- MCUmgr mgmt API 	1.0.0 	1.11
---- MCUmgr transport SMP API

@nordicjm

Because they're not APIs, this is not how MCUmgr works, they are services that a remote device e.g. a mobile phone communicates with, they're not something someone calls in an app (i.e. because there are no functions to call)

that is funny when each group here ends with a big fat API
putting all of this aside, this same list is here https://docs.zephyrproject.org/latest/doxygen/html/group__mcumgr.html, so if those are no APIs, they should not be advertised as such or they should be moved to some internal category or hidden using some doxygen magic.

Which they should be, that has the defines that you can then take and use in your software running on your e.g. pc or phone which has the error code defines and names and command ID defines - both of which were used to populate the values in this external code base here: https://github.com/thedjnK/AuTerm/blob/main/plugins/mcumgr/smp_group_img_mgmt.cpp#L36 and here: https://github.com/thedjnK/AuTerm/blob/main/plugins/mcumgr/smp_group_img_mgmt.cpp#L61
They should not have "API version" entries, just doxygen pages with the defines listed which can be linked to and searched for

They should not have "API version" entries, just doxygen pages with the defines listed which can be linked to and searched for

hmm, this is confusing. What is the API status for each of thos APIs (stble, unstable, etc.)? Who defines those API and what type of contract exists for such APIs? Let's say we need to change one of those API calls to fix an issue, do we have to go through the "stable API chanage" process? If there is a change in any of those APIs, breaking or not, will this impact "users" in some way? In short, what promise do we make about those APIs?

They should not have "API version" entries, just doxygen pages with the defines listed which can be linked to and searched for

hmm, this is confusing. What is the API status for each of thos APIs (stble, unstable, etc.)? Who defines those API and what type of contract exists for such APIs? Let's say we need to change one of those API calls to fix an issue, do we have to go through the "stable API chanage" process? If there is a change in any of those APIs, breaking or not, will this impact "users" in some way? In short, what promise do we make about those APIs?

It's not an API as such, it is implementations of the protocol. So looking at the fs mgmt one here: https://docs.zephyrproject.org/latest/services/device_mgmt/smp_groups/smp_group_8.html it implements these, the end user doesn't need to know how it does that, just that it does that, because the whole system is transparent to them. What they do need to know is the possible error codes that it can return so they can decode those (on their non-zephyr side, e.g. mobile phone app) and the command IDs so that they can call the right commands. From their zephyr app, they don't need to know anything about the FS mgmt module or call any FS mgmt functions. There is no stability rating for them because it's not something the user does anything with or has any access to from e.g. their code, it's all internal FS mgmt module and MCUmgr protocol code.

v12:

No more selecting of what appears on listing based on naming conventions (or, _ and z_ are not ignored anymore). If one wants to hide an API from the listing, one can simply wrap that in the already used @cond INTERNAL_HIDDEN.
doxmlparser now comes from PyPI instead of TestPyPI, as there was a doxygen release.

No more selecting of what appears on listing based on naming conventions (or, _ and z_ are not ignored anymore). If one wants to hide an API from the listing, one can simply wrap that in the already used @cond INTERNAL_HIDDEN.

Will this prevent it appearing on doxygen pages or linking to hidden members i.e. enums and structs?

No more selecting of what appears on listing based on naming conventions (or, _ and z_ are not ignored anymore). If one wants to hide an API from the listing, one can simply wrap that in the already used @cond INTERNAL_HIDDEN.

Will this prevent it appearing on doxygen pages or linking to hidden members i.e. enums and structs?

Nope. If, for instance, one wraps \defgroup dac_interface with the conditional, the "dac.h" doxygen file will still be generated and it can be linked from rst files.

v13:

Rebased.

Any comments, @nordicjm and @thedjnK ?

@gmarull @nordicjm please take another look
@kartben could you please review this one?

@gmarull @nordicjm please take another look

I think this is a flawed idea, not going to approve.

DNM while people revisit...

I will spend some time refining the docs for this, stay tuned.

In the current output, the list is just unusable, who's going to look at this https://builds.zephyrproject.io/zephyr/pr/61994/docs/develop/api/overview.html through 625 rows of APIs to find an API to use?

In the current output, the list is just unusable, who's going to look at this https://builds.zephyrproject.io/zephyr/pr/61994/docs/develop/api/overview.html through 625 rows of APIs to find an API to use?

I agree. Having this list in our documentation adds no real, user-oriented value to the project.

In the current output, the list is just unusable, who's going to look at this https://builds.zephyrproject.io/zephyr/pr/61994/docs/develop/api/overview.html through 625 rows of APIs to find an API to use? The existing documentation has 94 so the table size has jumped 7 times

Indenting with -

In the current output, the list is just unusable, who's going to look at this https://builds.zephyrproject.io/zephyr/pr/61994/docs/develop/api/overview.html through 625 rows of APIs to find an API to use? The existing documentation has 94 so the table size has jumped 7 times

Versions also seem to be part of the (0.1.0, 0.8.0 and 1.0.0) set only. I am not sure how has this even decided. This doesn't make any sense.

Indenting with -

yes, not my favorite as well, probably there is a better way to display a tree, suggestions welcome. Change to _ now, looks a bit better.

In the current output, the list is just unusable, who's going to look at this builds.zephyrproject.io/zephyr/pr/61994/docs/develop/api/overview.html through 625 rows of APIs to find an API to use? The existing documentation has 94 so the table size has jumped 7 times

"It is what it is" This is how many APIs we have. If you are interested in 1 API, you can search for it in the table. The table loads juist fine for me.
The fact that the existing list was short is because it was unmaintained and incomplete. This is what we are trying to sovle with this PR among other things.

Indenting with -

yes, not my favorite as well, probably there is a better way to display a tree, suggestions welcome. Change to _ now, looks a bit better.

as a quick hack, I am guessing &nbsp would achieve the same goal without being visible

as a quick hack, I am guessing &nbsp would achieve the same goal without being visible

I tried this, did not work.

But I completely disagree that we should sacrifice the cleanliness of the HTML build to improve the .pdf one. I think the HTML one should come first, and those _ are just very distracting and reflect poorly on the quality of our doc. I suggest @edersondisouza reverts back to spaces.

yes, I am also fine with that, the indentation and table looks bad with the '_'

Ok, found a way to indent with spaces that seems to work both with HTML and PDF.


Update DiscreteSlider.js

Change getAriaValueText to valueLabelFormat to make the example work

[x] I have followed (at least) the PR section of the contributing guide.

Not displaying the °C was done on purpose to replicate https://www.w3.org/TR/wai-aria-practices/examples/slider/slider-2.html


assemble_coeffs function in ./examples/spectrograms.py returns error

Observing c created on line 108, I see it generates objects of dimension 1 x 66 (a 2d array) therefore the function complains that the index [2] is out of range. This error may well be due to my misunderstanding of arguments.
$ ./spectrogram.py /path/to/wav/audio.wav'
Traceback (most recent call last):
  File "./spectrogram.py", line 112, in <module>
    coefs = assemble_coeffs(c, ncoefs)
  File "./spectrogram.py", line 27, in assemble_coeffs
    out = np.empty((ncoefs,cq0.shape[1],cq0.shape[2]), dtype=cq0.dtype)

If it helps, here is info about the wav file being input:
$ soxi 'MASS/sargon-silenci (metal)/sargon-silenci_1-19_with_effects.wav'

Input File     : 'MASS/sargon-silenci (metal)/sargon-silenci_1-19_with_effects.wav'
Channels       : 2
Sample Rate    : 44100
Precision      : 24-bit
Duration       : 00:00:18.00 = 793801 samples = 1350 CDDA sectors
File Size      : 4.76M
Bit Rate       : 2.12M
Sample Encoding: 24-bit Signed Integer PCM

Seeing as the default for --sr is 44100 I thought it would be fine to run with no additional args set.

I've had a crack at diagnosing - struggled with the generators. Running np.array(list(c)).shape returns (3, 2, 66) i.e. c is a generator that produces lists of lists ('shape' (2,66)). Is this as expected or is something going wrong upstream? I'm afraid I've run out of time trying to pick through NSGT_sliced.forward.

The list of lists is on purpose, because the output is not necessarily rectangular (only with —matrixform it is).
I would suggest that you start with a set of trusty command line options, like
myinput.wav
—output=myoutput.h5
--fmin=80
--fmax=14000
--bins=202
--scale=log
--real
--matrixform
--reducedform=2
--fps=100
--downmix-after
and --plot, if you like

Am 15.06.2016 um 17:49 schrieb James Owers<EMAIL_ADDRESS>I've had a crack at diagnosing - struggled with the generators. Running np.array(list(c)).shape returns (3, 2, 66) i.e. c is a generator that produces lists of lists ('shape' (2,66)). Is this as expected or is something going wrong upstream? I'm afraid I've run out of time trying to pick through NSGT_sliced.forward.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/grrrr/nsgt/issues/15#issuecomment-226230976, or mute the thread https://github.com/notifications/unsubscribe/AAJ-JisjRSf-5mS_qIsH7wOibQVIqd7Vks5qMB8jgaJpZM4I2Yv8.

Ok, thanks for the tip. I can get it to run with just the argument --matrixform added. The documented help for this is simply "Use regular time division over frequency bins (matrix form)"; have you any clues as to why running without this doesn't work. Is there a bug here or is this simply expected?


Updating the max page path to 235 characters

@Giridharan2112,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot


SqlServer - ATAN2 bearing calculation fails

I couldn't find any existing issues filed for this. Sorry if it is a duplicate.
I'm using SqlServer at work (grudgingly) and using the standard SomeModel.near method results in this error:
ActiveRecord::StatementInvalid: TinyTds::Error: 'ATAN2' is not a recognized built-in function name.

It looks like it is used to calculate the bearing. I am able to work around the problem by using something like:
MyModel.near('eiffel tower', 20.0, select_bearing: false)

But I had to dig through the source a bit for this. Maybe we should add some documentation about sql server or else change the default select_bearing option to be false when using TinyTds?

I'm also using SQL Server, and am seeing an error undefined method to_f'even when I useselect_bearing: false`:
@parcel = Parcel.first
@parcel.geocoded?
  => true
Cpt.first.geocoded?
  => true
Cpt.near(@parcel)
  => ActiveRecord::StatementInvalid: TinyTds::Error: 'ATAN2' is not a recognized built-in function name
Cpt.near(@parcel, select_bearing: false)
  => NoMethodError: undefined method `to_f' for {:select_bearing=>false}:Hash

Thanks for any advice.

I came across this issue today and worked around it as described below. This is old, but I wanted to leave a note here since this is directly relevant to this issue.
I'm not sure if Alex would be open to a pull request to add such functionality, but generally speaking, the are two changes that should happen to the bearing related sql make this more smooth in SQL Server:

references to ATAN2 should be ATN2 when SQL Server
references to MOD(a,b) should be rewritten as A % B

For my quick fix, I just overwrote the method. But if it were desirable to improve SQL Server support for this gem, here are my notes:
There are already methods for detecting postgres and sqlite, so adding sqlserver detection wouldn't be too intrusive (reference /tinytds|mssql|sqlserver/). Being that the bearing SQL is just a string, it would be easy to template the ATAN2 function from a variable, like sql_atan2 (not sure where this would be best implemented). Regarding modulo, I see that postgres also supports the a % b syntax, but I'm not sure what else this gem supports or it's impact. It could be reasonable to simply rewrite the SQL using the % operator.
Here is how I rewrote the method to accommodate SQL server. I added this to my initializers and it seems to work.
https://gist.github.com/ttilberg/fe5ac60351ad33b865550c08857f612f


[serverless-apollo-contentful] Add database migration

Type of change

[ ] Documentation change
[ ] Bug fix
[x] Feature

Summary of change

Checklist

[x] These changes follow the contributing guidelines
[x] This starter kit has been approved by the maintainers
[x] Changes for this new starter kit are being pushed to an integration branch instead of main
[x] All dependencies are version locked
[x] This fix resolves #873
[x] I have verified the fix works and introduces no further errors

https://www.contentful.com/developers/docs/tutorials/cli/scripting-migrations/

Please explain reason for comment


Internal Python Language Server error

Description
What steps will reproduce the problem?

I was writing the library name (pypcd) and suddenly the error appeared(title: Internal Python Language Server error)
Traceback
  File "/usr/local/lib/python3.5/dist-packages/pyls_jsonrpc/endpoint.py", line 113, in consume
    self._handle_request(message['id'], message['method'], message.get('params'))
  File "/usr/local/lib/python3.5/dist-packages/pyls_jsonrpc/endpoint.py", line 182, in _handle_request
    handler_result = handler(params)
  File "/usr/local/lib/python3.5/dist-packages/pyls_jsonrpc/dispatchers.py", line 23, in handler
    return method(**(params or {}))
  File "/usr/local/lib/python3.5/dist-packages/pyls/python_ls.py", line 295, in m_text_document__completion
    return self.completions(textDocument['uri'], position)
  File "/usr/local/lib/python3.5/dist-packages/pyls/python_ls.py", line 216, in completions
    completions = self._hook('pyls_completions', doc_uri, position=position)
  File "/usr/local/lib/python3.5/dist-packages/pyls/python_ls.py", line 132, in _hook
    return hook_handlers(config=self.config, workspace=workspace, document=doc, **kwargs)
  File "/usr/local/lib/python3.5/dist-packages/pluggy/hooks.py", line 289, in __call__
    return self._hookexec(self, self.get_hookimpls(), kwargs)
  File "/usr/local/lib/python3.5/dist-packages/pluggy/manager.py", line 87, in _hookexec
    return self._inner_hookexec(hook, methods, kwargs)
  File "/usr/local/lib/python3.5/dist-packages/pluggy/_tracing.py", line 80, in __call__
    return outcome.get_result()
  File "/usr/local/lib/python3.5/dist-packages/pluggy/callers.py", line 80, in get_result
    raise ex[1].with_traceback(ex[2])
  File "/usr/local/lib/python3.5/dist-packages/pluggy/callers.py", line 52, in from_call
    result = func()
  File "/usr/local/lib/python3.5/dist-packages/pluggy/_tracing.py", line 78, in <lambda>
    outcome = _Result.from_call(lambda: self.oldcall(hook, hook_impls, kwargs))
  File "/usr/local/lib/python3.5/dist-packages/pluggy/manager.py", line 81, in <lambda>
    firstresult=hook.spec.opts.get("firstresult") if hook.spec else False,
  File "/usr/local/lib/python3.5/dist-packages/pluggy/callers.py", line 208, in _multicall
    return outcome.get_result()
  File "/usr/local/lib/python3.5/dist-packages/pluggy/callers.py", line 80, in get_result
    raise ex[1].with_traceback(ex[2])
  File "/usr/local/lib/python3.5/dist-packages/pluggy/callers.py", line 187, in _multicall
    res = hook_impl.function(*args)
  File "/usr/local/lib/python3.5/dist-packages/pyls/plugins/jedi_completion.py", line 54, in pyls_completions
    return [_format_completion(d, snippet_support and should_include_params) for d in definitions] or None
  File "/usr/local/lib/python3.5/dist-packages/pyls/plugins/jedi_completion.py", line 54, in <listcomp>
    return [_format_completion(d, snippet_support and should_include_params) for d in definitions] or None
  File "/usr/local/lib/python3.5/dist-packages/pyls/plugins/jedi_completion.py", line 61, in _format_completion
    'detail': _detail(d),
  File "/usr/local/lib/python3.5/dist-packages/pyls/plugins/jedi_completion.py", line 93, in _detail
    return definition.parent().full_name or ''
  File "/usr/local/lib/python3.5/dist-packages/jedi/api/classes.py", line 352, in parent
    context = self._name.parent_context
  File "/usr/local/lib/python3.5/dist-packages/jedi/evaluate/names.py", line 256, in parent_context
    import_contexts = self.infer()
  File "/usr/local/lib/python3.5/dist-packages/jedi/cache.py", line 143, in wrapper
    result = method(self, *args, **kwargs)
  File "/usr/local/lib/python3.5/dist-packages/jedi/evaluate/names.py", line 267, in infer
    return Importer(m.evaluator, [self.string_name], m, level=self._level).follow()
  File "/usr/local/lib/python3.5/dist-packages/jedi/evaluate/imports.py", line 296, in follow
    ) for parent_module_context in context_set
  File "/usr/local/lib/python3.5/dist-packages/jedi/evaluate/imports.py", line 296, in <listcomp>
    ) for parent_module_context in context_set
  File "/usr/local/lib/python3.5/dist-packages/jedi/evaluate/__init__.py", line 139, in import_module
    sys_path, prefer_stubs=prefer_stubs)
  File "/usr/local/lib/python3.5/dist-packages/jedi/plugins/flask.py", line 24, in wrapper
    return callback(evaluator, import_names, module_context, *args, **kwargs)
  File "/usr/local/lib/python3.5/dist-packages/jedi/evaluate/gradual/typeshed.py", line 110, in wrapper
    for p in parent_module_contexts
  File "/usr/local/lib/python3.5/dist-packages/jedi/common/context.py", line 32, in from_sets
    for set_ in sets:
  File "/usr/local/lib/python3.5/dist-packages/jedi/evaluate/gradual/typeshed.py", line 110, in <genexpr>
    for p in parent_module_contexts
  File "/usr/local/lib/python3.5/dist-packages/jedi/evaluate/imports.py", line 436, in import_module
    is_package=is_pkg,
  File "/usr/local/lib/python3.5/dist-packages/jedi/evaluate/imports.py", line 457, in _load_python_module
    cache_path=settings.cache_directory
  File "/usr/local/lib/python3.5/dist-packages/jedi/evaluate/__init__.py", line 454, in parse
    return self.parse_and_get_code(*args, **kwargs)[0]
  File "/usr/local/lib/python3.5/dist-packages/jedi/evaluate/__init__.py", line 451, in parse_and_get_code
    return grammar.parse(code=code, path=path, file_io=file_io, **kwargs), code
  File "/usr/local/lib/python3.5/dist-packages/parso/grammar.py", line 78, in parse
    return self._parse(code=code, **kwargs)
  File "/usr/local/lib/python3.5/dist-packages/parso/grammar.py", line 153, in _parse
    cache_path=cache_path)
  File "/usr/local/lib/python3.5/dist-packages/parso/cache.py", line 141, in save_module
    _save_to_file_system(hashed_grammar, path, item, cache_path=cache_path)
  File "/usr/local/lib/python3.5/dist-packages/parso/cache.py", line 146, in _save_to_file_system
    pickle.dump(item, f, pickle.HIGHEST_PROTOCOL)

OSError: [Errno 28] No space left on device  File "/usr/local/lib/python3.5/dist-packages/pyls_jsonrpc/endpoint.py", line 113, in consume
    self._handle_request(message['id'], message['method'], message.get('params'))
  File "/usr/local/lib/python3.5/dist-packages/pyls_jsonrpc/endpoint.py", line 182, in _handle_request
    handler_result = handler(params)
  File "/usr/local/lib/python3.5/dist-packages/pyls_jsonrpc/dispatchers.py", line 23, in handler
    return method(**(params or {}))
  File "/usr/local/lib/python3.5/dist-packages/pyls/python_ls.py", line 295, in m_text_document__completion
    return self.completions(textDocument['uri'], position)
  File "/usr/local/lib/python3.5/dist-packages/pyls/python_ls.py", line 216, in completions
    completions = self._hook('pyls_completions', doc_uri, position=position)
  File "/usr/local/lib/python3.5/dist-packages/pyls/python_ls.py", line 132, in _hook
    return hook_handlers(config=self.config, workspace=workspace, document=doc, **kwargs)
  File "/usr/local/lib/python3.5/dist-packages/pluggy/hooks.py", line 289, in __call__
    return self._hookexec(self, self.get_hookimpls(), kwargs)
  File "/usr/local/lib/python3.5/dist-packages/pluggy/manager.py", line 87, in _hookexec
    return self._inner_hookexec(hook, methods, kwargs)
  File "/usr/local/lib/python3.5/dist-packages/pluggy/_tracing.py", line 80, in __call__
    return outcome.get_result()
  File "/usr/local/lib/python3.5/dist-packages/pluggy/callers.py", line 80, in get_result
    raise ex[1].with_traceback(ex[2])
  File "/usr/local/lib/python3.5/dist-packages/pluggy/callers.py", line 52, in from_call
    result = func()
  File "/usr/local/lib/python3.5/dist-packages/pluggy/_tracing.py", line 78, in <lambda>
    outcome = _Result.from_call(lambda: self.oldcall(hook, hook_impls, kwargs))
  File "/usr/local/lib/python3.5/dist-packages/pluggy/manager.py", line 81, in <lambda>
    firstresult=hook.spec.opts.get("firstresult") if hook.spec else False,
  File "/usr/local/lib/python3.5/dist-packages/pluggy/callers.py", line 208, in _multicall
    return outcome.get_result()
  File "/usr/local/lib/python3.5/dist-packages/pluggy/callers.py", line 80, in get_result
    raise ex[1].with_traceback(ex[2])
  File "/usr/local/lib/python3.5/dist-packages/pluggy/callers.py", line 187, in _multicall
    res = hook_impl.function(*args)
  File "/usr/local/lib/python3.5/dist-packages/pyls/plugins/jedi_completion.py", line 54, in pyls_completions
    return [_format_completion(d, snippet_support and should_include_params) for d in definitions] or None
  File "/usr/local/lib/python3.5/dist-packages/pyls/plugins/jedi_completion.py", line 54, in <listcomp>
    return [_format_completion(d, snippet_support and should_include_params) for d in definitions] or None
  File "/usr/local/lib/python3.5/dist-packages/pyls/plugins/jedi_completion.py", line 61, in _format_completion
    'detail': _detail(d),
  File "/usr/local/lib/python3.5/dist-packages/pyls/plugins/jedi_completion.py", line 93, in _detail
    return definition.parent().full_name or ''
  File "/usr/local/lib/python3.5/dist-packages/jedi/api/classes.py", line 352, in parent
    context = self._name.parent_context
  File "/usr/local/lib/python3.5/dist-packages/jedi/evaluate/names.py", line 256, in parent_context
    import_contexts = self.infer()
  File "/usr/local/lib/python3.5/dist-packages/jedi/cache.py", line 143, in wrapper
    result = method(self, *args, **kwargs)
  File "/usr/local/lib/python3.5/dist-packages/jedi/evaluate/names.py", line 267, in infer
    return Importer(m.evaluator, [self.string_name], m, level=self._level).follow()
  File "/usr/local/lib/python3.5/dist-packages/jedi/evaluate/imports.py", line 296, in follow
    ) for parent_module_context in context_set
  File "/usr/local/lib/python3.5/dist-packages/jedi/evaluate/imports.py", line 296, in <listcomp>
    ) for parent_module_context in context_set
  File "/usr/local/lib/python3.5/dist-packages/jedi/evaluate/__init__.py", line 139, in import_module
    sys_path, prefer_stubs=prefer_stubs)
  File "/usr/local/lib/python3.5/dist-packages/jedi/plugins/flask.py", line 24, in wrapper
    return callback(evaluator, import_names, module_context, *args, **kwargs)
  File "/usr/local/lib/python3.5/dist-packages/jedi/evaluate/gradual/typeshed.py", line 110, in wrapper
    for p in parent_module_contexts
  File "/usr/local/lib/python3.5/dist-packages/jedi/common/context.py", line 32, in from_sets
    for set_ in sets:
  File "/usr/local/lib/python3.5/dist-packages/jedi/evaluate/gradual/typeshed.py", line 110, in <genexpr>
    for p in parent_module_contexts
  File "/usr/local/lib/python3.5/dist-packages/jedi/evaluate/imports.py", line 436, in import_module
    is_package=is_pkg,
  File "/usr/local/lib/python3.5/dist-packages/jedi/evaluate/imports.py", line 457, in _load_python_module
    cache_path=settings.cache_directory
  File "/usr/local/lib/python3.5/dist-packages/jedi/evaluate/__init__.py", line 454, in parse
    return self.parse_and_get_code(*args, **kwargs)[0]
  File "/usr/local/lib/python3.5/dist-packages/jedi/evaluate/__init__.py", line 451, in parse_and_get_code
    return grammar.parse(code=code, path=path, file_io=file_io, **kwargs), code
  File "/usr/local/lib/python3.5/dist-packages/parso/grammar.py", line 78, in parse
    return self._parse(code=code, **kwargs)
  File "/usr/local/lib/python3.5/dist-packages/parso/grammar.py", line 153, in _parse
    cache_path=cache_path)
  File "/usr/local/lib/python3.5/dist-packages/parso/cache.py", line 141, in save_module
    _save_to_file_system(hashed_grammar, path, item, cache_path=cache_path)
  File "/usr/local/lib/python3.5/dist-packages/parso/cache.py", line 146, in _save_to_file_system
    pickle.dump(item, f, pickle.HIGHEST_PROTOCOL)

OSError: [Errno 28] No space left on devic

Versions

Spyder version: 4.0.0b5
Python version: 3.5.2
Qt version: 5.12.4
PyQt5 version: 5.12.3
Operating System: Linux 4.15.0-65-generic

Dependencies
cloudpickle >=0.5.0          :  1.2.1 (OK)
pygments >=2.0               :  2.4.2 (OK)
qtconsole >=4.5.5            :  4.5.5 (OK)
nbconvert >=4.0              :  5.6.0 (OK)
sphinx >=0.6.6               :  2.2.0 (OK)
pylint >=0.25                :  2.3.1 (OK)
psutil >=0.3                 :  5.6.3 (OK)
qtawesome >=0.5.7            :  0.6.0 (OK)
qtpy >=1.5.0                 :  1.9.0 (OK)
pickleshare >=0.4            :  0.7.5 (OK)
zmq >=17                     :  18.1.0 (OK)
chardet >=2.0.0              :  2.3.0 (OK)
numpydoc >=0.6.0             :  0.9.1 (OK)
spyder_kernels >=1.5.0;<2.0.0:  1.5.0 (OK)
qdarkstyle >=2.7             :  2.7 (OK)
atomicwrites >=1.2.0         :  1.3.0 (OK)
diff_match_patch >=20181111  :  20181111 (OK)
watchdog                     :  None (OK)
keyring                      :  None (OK)
pexpect >=4.4.0              :  4.0.1 (NOK)
pympler                      :  None (OK)
sympy >=0.7.3                :  None (NOK)
cython >=0.21                :  None (NOK)
IPython >=4.0                :  7.7.0 (OK)
matplotlib >=2.0.0           :  None (NOK)
pandas >=0.13.1              :  None (NOK)
numpy >=1.7                  :  1.17.0 (OK)
scipy >=0.17.0               :  None (NOK)
pyls >=0.28.2;<0.29.0        :  0.28.3 (OK)
xdg >=0.26                   :  0.25 (NOK)

OSError: [Errno 28] No space left on device
Usually this mean that your hard drive is full.
To check this run df -h in a terminal and check for use% close to 100%

You need to make free space in your hard disk to fix this problem. It's not something we can fix here.


Correct handicap adjustment in daily_windows

Fixes #3
I found the handicap adjustment in daily_windows.py always adjusting the opponents rating as if they are always black.
This PR also fixes the rank discrepancy I found in #3

Whoops, thanks!