Encountered an error when switching the img_pair_strategy

My dataset folder is located at /DetectorFreeSfM/SfM_dataset/rushan/test_scene/images, which contains images named sequentially like 0.png, 1.png, and so forth.
I have set img_pair_strategy: pair_from_index on line 51 of the configuration file at /DetectorFreeSfM/hydra_configs/demo/dfsfm.yaml; however, I encountered the following error afterward.
`Error executing job with overrides: ['+demo=dfsfm.yaml']
Traceback (most recent call last):
File "/home/a308/Project/DetectorFreeSfM/eval_dataset.py", line 195, in main
globals()cfg.type
File "/home/a308/Project/DetectorFreeSfM/eval_dataset.py", line 153, in eval_dataset
metric_dict = eval_core(scene_paths, cfg)
File "/home/a308/Project/DetectorFreeSfM/eval_dataset.py", line 63, in eval_core
metric_dict = DetectorFreeSfM(
File "/home/a308/Project/DetectorFreeSfM/src/detectorfree_sfm.py", line 50, in DetectorFreeSfM
img_pairs = construct_img_pairs(
File "/home/a308/Project/DetectorFreeSfM/src/construct_pairs/construct_pairs.py", line 17, in construct_img_pairs
img_pairs = pairs_from_index(img_list, args.INDEX_num_of_pair)
File "/home/a308/Project/DetectorFreeSfM/src/construct_pairs/pairs_from_img_index.py", line 19, in pairs_from_index
while j < len(img_ids) and count < num_match:
TypeError: '<' not supported between instances of 'int' and 'NoneType'
Set the environment variable HYDRA_FULL_ERROR=1 for a complete stack trace.`

If you choose to use pair_from_index which performs matching sequentially, the neuralsfm.INDEX_num_of_pair should be set to a int value (e.g., 5) to specify how many pairs to be matched for each image.

If you choose to use pair_from_index which performs matching sequentially, the neuralsfm.INDEX_num_of_pair should be set to a int value (e.g., 5) to specify how many pairs to be matched for each image.

thanks！


Fix package library path on the ressesion.conf file

Description
Missed one bit here to be totally fixed...
How Has This Been Tested?
End to end image testing shows only one folder as expected

Merge criteria:

[ ] 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).
[ ] The developer has manually tested the changes and verified that the changes work

JFTR: this is a followup for #402.

/cherrypick 2023b


Support selector and entrypoints in the kubernetes component

Is your feature request related to a problem? Please describe.
In the Devfile 1.0, there is a way to:

select the components that we want to import from the kubernetes component manifest: selector field => https://www.eclipse.org/che/docs/che-7/end-user-guide/making-a-workspace-portable-using-a-devfile/#_component_type_kubernetes
override the entrypoints of involved containers: entrypoints => https://www.eclipse.org/che/docs/che-7/end-user-guide/making-a-workspace-portable-using-a-devfile/#_overriding_container_entrypoints

Describe the solution you'd like
We'd need to add this to the Devfile 2.0 before the 2.0.0 release if we want to have feature parity with devfile 1.0 Che-wise
Note that this are completely new attributes, so this would not break compatibility rules.

select the components that we want to import from the kubernetes component manifest: selector field => https://www.eclipse.org/che/docs/che-7/end-user-guide/making-a-workspace-portable-using-a-devfile/#_component_type_kubernetes

I'm starting to get a little bit worried that we are starting to make Devfile way complicated.
Is this something that the Devfile author could easily solve by splitting the yaml files into multiple files and using just upset of it?

There is currently no clear use case for this yet. Therefore, we'll remove this from the 2.1 plan.


Changes getCryptoContext to createCryptoContext

The task object that I recieved when I checked out the project and tried to run it only supported "createCryptoContext". I suspect that the API has recently changed.

Hrm, I wonder how that could have happened. Thanks for the report!


Fix face lattice test domain comparison

Here is an edge case where the makeLattice function fails:
[N]->{[i,j,k] : 0<=i,j,k and N<2i+j+3k and i+j+k<2N+3}

The problem is that div constraints involving parameters are retained by the lattice vertex representation, but not by isl. So the check that compares them fails.
One of the vertices has the same expression values:
[N] -> { [(1 + N)/2, (0), (0)] }    <— lattice representation
[N] -> { [(1 + N)/2, (0), (0)] }    <— isl representation

but different domains:
[N] -> {  : (1 + N) mod 2 = 0 and N >= -1 }       <— lattice representation
[N] -> {  : N >= -1 }                             <— isl representation

We should ignore any div constraints involving parameters at least in alpha.model.test. I’m not sure if we need to (or should) change the toBasicSet method in alpha.model.util.Facet to also drop divs involving params. We’d have to be careful to try to differentiate between divs introduced artificially by the lattice construction and divs that the user may have specified in the input program.
Minimally, we can probably ignore these in the tests.

This is no longer needed, given PR #17


[helm install] Kernel headers not found for 4.18.0-147.8.1.el8_1.x86_64 For OpenShift 4.4

Describe the bug
I'm trying to deploy Falco in Openshift 4.4 with Falco version 0.18.0,  and facing the follwing error:

 Setting up /usr/src links from host
* Unloading falco-probe, if present
* Running dkms install for falco
Error! echo
Your kernel headers for kernel 4.18.0-147.8.1.el8_1.x86_64 cannot be found at
/lib/modules/4.18.0-147.8.1.el8_1.x86_64/build or /lib/modules/4.18.0-147.8.1.el8_1.x86_64/source.
* Running dkms build failed, couldn't find /var/lib/dkms/falco/0.18.0/build/make.log
* Trying to load a system falco-probe, if present
* Trying to find precompiled falco-probe for 4.18.0-147.8.1.el8_1.x86_64
Found kernel config at /lib/modules/4.18.0-147.8.1.el8_1.x86_64/config
* Trying to download precompiled module from https://s3.amazonaws.com/download.draios.com/stable/sysdig-probe-binaries/falco-probe-0.18.0-x86_64-4.18.0-147.8.1.el8_1.x86_64-ea6bf7ba7bc281b199cd7bd0fb7866f3.ko
curl: (22) The requested URL returned error: 404 Not Found
Download failed, consider compiling your own falco-probe and loading it or getting in touch with the sysdig community
Thu May 14 12:39:20 2020: Falco initialized with configuration file /etc/falco/falco.yaml
Thu May 14 12:39:20 2020: Loading rules from file /etc/falco/falco_rules.yaml:
Thu May 14 12:39:20 2020: Loading rules from file /etc/falco/falco_rules.local.yaml:
Thu May 14 12:39:21 2020: Loading rules from file /etc/falco/rules.available/application_rules.yaml:
Thu May 14 12:39:22 2020: Unable to load the driver. Exiting.
Thu May 14 12:39:22 2020: Runtime error: error opening device /host/dev/falco0. Make sure you have root credentials and that the falco-probe module is loaded.. Exiting.

How to reproduce it

Falco Chart 1.17
Image: 0.18.0
Expected behaviour
Normal execution of Faclo modules

Screenshots

Environment

Falco version: 0.18.0, 0.19.0, 0.20.0,0.21.0, 0.22.0, master

System info:

Cloud provider or hardware configuration:
OS: RHEL 8

Kernel: 4.18.0-147.8.1.el8_1.x86_64

Installation method: stable/falco chart

Additional context

Without eBPF filter:
* Setting up /usr/src links from host
* Unloading falco module, if present
* Running dkms build failed, couldn't find /var/lib/dkms/falco/96bd9bc560f67742738eb7255aeb4d03046b8045/build/make.log
* Trying to load a system falco driver, if present
* Trying to find a prebuilt falco module for kernel 4.18.0-147.8.1.el8_1.x86_64
Detected an unsupported target system, please get in touch with the Falco community
Thu May 14 13:19:38 2020: Falco initialized with configuration file /etc/falco/falco.yaml
Thu May 14 13:19:38 2020: Loading rules from file /etc/falco/falco_rules.yaml:
Thu May 14 13:19:38 2020: Loading rules from file /etc/falco/falco_rules.local.yaml:
Thu May 14 13:19:39 2020: Loading rules from file /etc/falco/rules.available/application_rules.yaml:
Thu May 14 13:19:40 2020: Unable to load the driver. Exiting.
Thu May 14 13:19:40 2020: Runtime error: error opening device /host/dev/falco0. Make sure you have root credentials and that the falco module is loaded.. Exiting.

Related:
falcosecurity/falco#1188
falcosecurity/falco#1078

Please, note that we're in the process of moving the helm chart here, and refactoring it.

This should be fixed within the latest chart version. Could you confirm pls?

Working with chart 1.2.1 and falco version 0.24.0

still not working with chart 1.2.1 and falco version 0.24.0
`* Setting up /usr/src links from host

Running falco-driver-loader with: driver=module, compile=yes, download=yes
Unloading falco module, if present
Trying to dkms install falco module
Running dkms build failed, couldn't find /var/lib/dkms/falco/85c88952b018fdbce2464222c3303229f5bfcfad/build/make.log
Trying to load a system falco driver, if present
Trying to find locally a prebuilt falco module for kernel 5.6.19-300.fc32.x86_64, if present
Trying to download prebuilt module from https://dl.bintray.com/falcosecurity/driver/85c88952b018fdbce2464222c3303229f5bfcfad/falco_fedora_5.6.19-300.fc32.x86_64_1.ko
curl: (22) The requested URL returned error: 404 Not Found
Download failed, consider compiling your own falco module and loading it or getting in touch with the Falco community
Fri Sep 18 16:31:40 2020: Falco initialized with configuration file /etc/falco/falco.yaml
Fri Sep 18 16:31:40 2020: Loading rules from file /etc/falco/falco_rules.yaml:
Fri Sep 18 16:31:41 2020: Loading rules from file /etc/falco/falco_rules.local.yaml:
Fri Sep 18 16:31:42 2020: Unable to load the driver. Exiting.
Fri Sep 18 16:31:42 2020: Runtime error: error opening device /host/dev/falco0. Make sure you have root credentials and that the falco module is loaded.. Exiting.`

still not working with chart 1.2.1 and falco version 0.24.0
* Running falco-driver-loader with: driver=module, compile=yes, download=yes
* Unloading falco module, if present
* Trying to dkms install falco module
* Running dkms build failed, couldn't find /var/lib/dkms/falco/85c88952b018fdbce2464222c3303229f5bfcfad/build/make.log
* Trying to load a system falco driver, if present
* Trying to find locally a prebuilt falco module for kernel 5.6.19-300.fc32.x86_64, if present
* Trying to download prebuilt module from https://dl.bintray.com/falcosecurity/driver/85c88952b018fdbce2464222c3303229f5bfcfad/falco_fedora_5.6.19-300.fc32.x86_64_1.ko
curl: (22) The requested URL returned error: 404 Not Found
Download failed, consider compiling your own falco module and loading it or getting in touch with the Falco community
Fri Sep 18 16:31:40 2020: Falco initialized with configuration file /etc/falco/falco.yaml
Fri Sep 18 16:31:40 2020: Loading rules from file /etc/falco/falco_rules.yaml:
Fri Sep 18 16:31:41 2020: Loading rules from file /etc/falco/falco_rules.local.yaml:
Fri Sep 18 16:31:42 2020: Unable to load the driver. Exiting.
Fri Sep 18 16:31:42 2020: Runtime error: error opening device /host/dev/falco0. Make sure you have root credentials and that the falco module is loaded.. Exiting.```

Prebuild drivers are provided on a best-effort basis. AFAIK, we are not providing prebuild drivers for Fedora. Feel free to propose that here.


Execution fails when resource is nil

Stop functions fail when resource is nil.
But never affect other resources, and function runs well, if target resource exists.
Expect to run without error, even if there's no target resource.

@yasu-murata If you're solved, can you close this issue?

OK!
Problem is already solved by #3.


Corrected minor typos in README.md for the display libs

Typos prevented compilation if used as a base!

Thank you... I think an unwanted line has crept into the bottom of the README. You might want to rebase out that commit.

Thank you!


Removed parenthisis of empty constructor in object initializer code f…

Removed parenthesis of empty constructor in ObjectInitializerCodeFixProvider.
This prevents a CC0015 warning and fixes #383.
Sorry for not giving a heads up sooner. I was very quick to solve this issue.

Good one.
Found a related bug, just reported it: #396. Maybe you want to tackle it too?


SW-1969 Fix unit name in accession CSV template

The previous version of the template incorrectly told users to use Count
rather than Seeds as the unit name for non-weight-based accessions.

Current dependencies on/for this PR:

main

PR #699   👈

This comment was auto-generated by Graphite.


Remove PDF generation

PDF generation using the LaTeX toolchain has proved to be extremely
fragile, extremely difficult to debug, and thus has consumed numerous
hours debugging and working around its problems.

If PDF generation is to be reintroduced in the future, it must be done
using a toolchain which the average dlang.org contributor is capable
of debugging. The current implementation is nowhere close to meeting
that requirement.

CC @wilzbach @WalterBright @atilaneves and of course @andralex :)

Yah, that bug in listings is a complete bear.
One question would be how many folks are downloading the pdf.

Yah, that bug in the listings package is a complete bear.

If only this was the only problem. See the linked thread for another example. I can try to dig out more instances from my emails, but, historically there have been just so many cases where we need to dance around the CI and doing random shaman dances just to make the PDF generation succeed.

100% for it. I too have spent days fighting the unfriendly monster.

If you really want pdf, it is easier to generate from html than from ddoc anyway.

I've always viewed PDF generation via LaTeX from ddoc as one gigantic hack. LaTeX input syntax has certain peculiar nuances that cannot be mechanically generated from an input that wasn't written with such nuances in view, and it's inevitable that the result would have problems. Ddoc's limited expressiveness does not help things. Furthermore, as Adam said, there are easier tools to use than LaTeX if the goal is just to generate a PDF, such as the various HTML-to-PDF tools out there.

I've always viewed PDF generation via LaTeX from ddoc as one gigantic hack. LaTeX input syntax has certain peculiar nuances that cannot be mechanically generated from an input that wasn't written with such nuances in view, and it's inevitable that the result would have problems. Ddoc's limited expressiveness does not help things.

Not to launch into a side discussion here, but it's been beneficial in terms of fixing bugs and limitations in ddoc. Also, it did work for a large text and for a long time; if it weren't for the absolutely nuts heisenbug in the listings package there would be good steps to take to make it more robust. Conversely, once it gets removed I fear the text would increasingly make unwitting use of html-related particularities, meaning adding other formats later would be more difficult. But a time sink is a time sink and needs to be plugged.

I think it's really little more than a nice coincidence that it's possible to generate HTML and LaTeX with DDoc. If you try to target anything slightly more complicated (e.g. context-sensitive), such as JSON or Markdown or RTF, the limitations of DDoc become apparent. For documentation, a macro system such as DDoc is a rather suboptimal approach. A more correct approach would be using syntax which can unambiguously describe the text in semantic terms, and thus can be easily parsed into some kind of DOM (or AST if you will), and then emitted into whatever arbitrary formats are desired.
Markdown is a nice format for this purpose though, and it's nice seeing progress with adding Markdown to DDoc for this reason. Unfortunately probably our syntax will never be fully compliant with any other Markdown standard out there.

Failed to download package vibe-core from https://code.dlang.org/packages/vibe-core/1.4.0.zip

@wilzbach I don't suppose it would be possible to make Dub or our build scripts to auto-retry this?


Port algorithms from vlearn

[ ]  Normalized Adaptive Gradient

@article{DBLP:journals/corr/abs-1305-6646,
  author    = {St{\'{e}}phane Ross and
               Paul Mineiro and
               John Langford},
  title     = {Normalized Online Learning},
  journal   = {CoRR},
  volume    = {abs/1305.6646},
  year      = {2013},
  url       = {http://arxiv.org/abs/1305.6646},
  timestamp = {Sun, 02 Jun 2013 20:48:21 +0200},
  biburl    = {http://dblp.uni-trier.de/rec/bib/journals/corr/abs-1305-6646},
  bibsource = {dblp computer science bibliography, http://dblp.org}
}

[ ] Generalized Online Mirror Descent

@article{DBLP:journals/corr/abs-1304-2994,
  author    = {Francesco Orabona and
               Koby Crammer and
               Nicol{\`{o}} Cesa{-}Bianchi},
  title     = {A Generalized Online Mirror Descent with Applications to Classification
               and Regression},
  journal   = {CoRR},
  volume    = {abs/1304.2994},
  year      = {2013},
  url       = {http://arxiv.org/abs/1304.2994},
  timestamp = {Thu, 02 May 2013 15:54:11 +0200},
  biburl    = {http://dblp.uni-trier.de/rec/bib/journals/corr/abs-1304-2994},
  bibsource = {dblp computer science bibliography, http://dblp.org}
}

[ ] Online Convex Programming and Generalized Infinitesimal Gradient Ascent

@MISC{Zinkevich03onlineconvex,
    author = {Martin Zinkevich},
    title = {Online Convex Programming and Generalized Infinitesimal Gradient Ascent},
    year = {2003}
}

[ ] ADAGRAD http://jmlr.org/papers/volume12/duchi11a/duchi11a.pdf

More importantly, I think people are interested in adagrad and other sketched versions. But I haven't seen any matrix sketching code in hackage.

@freuk Adagrad, that's a good one. This is basically new ground in Haskell, we'll have to write it ourselves

also see:
https://

Yep, thanks @freuk , I've added some references to the list above


Update coding guidelines

Update coding guidelines to reflect new organisation structure, in which algorithms are implemented as header files.

[x] Read the contribution guidelines

I'm away from my computer but will fix this Tuesday and resubmit.

Done.


Add e2e encryption content for pulsar

Closes https://github.com/dapr/docs/issues/3366.

tiny review

Fixed.


Environment variable not coherent with Docker Compose

Environment data

VS Code version: 1.53.2
Extension version (available under the Extensions sidebar): 2021.1.502429796
OS and version: Windows 10 build 21313
Python version (& distribution if applicable, e.g. Anaconda): 3.8.5
Type of virtual environment used (N/A | venv | virtualenv | conda | ...): conda

Expected behaviour
The value passed in docker compose as environment should serve everywhere in the docker
Actual behaviour
When I use the Python Console, this is indeed the case : os.getenv("DB_HOST") returns the value passed in my docker compose. Note that I am using the following code :
import os
from dotenv import load_dotenv

load_dotenv()
host = os.getenv("DB_HOST")

the .env also contains a DB_HOST variable that I want to erase with the one passed in docker compose.
However, when I run the debugger, the value that is passed to host is the one that can be found in the .env file. I do not understand why. I also tried to add the environment variable in the lauch.json vbut with no succes.
Steps to reproduce:
content of lauch.json (both configuration are not working).
{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "retriever_reader_docker",
            "type": "python",
            "request": "launch",
            "module": "src.evaluation.retriever_reader.retriever_reader_eval_squad",
            "env": {
                "DB_HOST": "elasticsearch",
            }
        },
        {
            "name": "retriever_reader",
            "type": "python",
            "request": "launch",
            "module": "src.evaluation.retriever_reader.retriever_reader_eval_squad"
        }
    ]
}

content of docker-compose :
version: '3'

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
      args:
        # On Linux, you may need to update USER_UID and USER_GID below if not your local UID is not 1000.
        USER_UID: 1000
        USER_GID: 1000
    depends_on:
      - elasticsearch
    init: true
    environment:
      # See rest_api/config.py for more variables that you can configure here.
      - DB_HOST=elasticsearch
    volumes:
      # Forwards the local Docker socket to the container.
      - /var/run/docker.sock:/var/run/docker-host.sock
      # Update this to wherever you want VS Code to mount the folder of your project
      - ..:/workspace:cached

    # Overrides default command so things don't shut down after the process ends.
    entrypoint: /usr/local/share/docker-init.sh
    command: sleep infinity

    # Uncomment the next four lines if you will use a ptrace-based debuggers like C++, Go, and Rust.
    # cap_add:
    #  - SYS_PTRACE
    # security_opt:
    #   - seccomp:unconfined

    # Uncomment the next line to use a non-root user for all processes.
    # user: vscode

    # Use "forwardPorts" in **devcontainer.json** to forward an app port locally.
    # (Adding the "ports" property to this file will not forward from a Codespace.)

  elasticsearch:
    # This will start an empty elasticsearch instance (so you have to add your documents yourself)
    #image: "elasticsearch:7.6.1"
    # If you want a demo image instead that is "ready-to-query" with some indexed Game of Thrones articles:
    image: "elasticsearch:7.6.2"
    ports:
      - 9200:9200
    environment:
      - discovery.type=single-node

Hi @Rob192,
Thanks for the bug report! We investigate issues in order based on priority and severity, which includes the impact it has on your ability to use the extension to do productive work, and the number of people affected. If other users come forward and leave a comment demonstrating they are seeing/reproducing the problem then we will raise this issue's priority.
If you think your issue is more of a question or configuration problem rather than a bug, please ask on Stack Overflow with the visual-studio-code and python labels for help.
Please also note that when you use the Python extension remotely, it is activated last, and as such will overwrite any preexisting environment variables. One workaround could be for you to specify a different value for the env file setting (python.envFile).
Thank you for your understanding and patience!

Hello @kimadeline. Actually your comment helped a lot. From what I understand, I believe that because the python.envFile is set by default to workspace/.env then it erase the env configuration I try to pass through my docker compose. Therefore setting the parameter python.envFile to "None" resolved my problem. Thank you !


Swagger sample. Why MVC services are registered twice?

Could you please explain the reason of using both AddMvcCore() and AddMvc() in SwaggerSample
public void ConfigureServices( IServiceCollection services )
{
    ...
    services.AddMvcCore().AddVersionedApiExplorer( o => o.GroupNameFormat = "'v'VVV" );
    services.AddMvc();
    ...
}

API Versioning only uses the core NuGet package for ASP.NET Core; it doesn't use or depend on the full set of ASP.NET Core. More specifically, it doesn't need or use any of the UI components.  UseMvcCore is in Microsoft.AspNetCore.Mvc.Core, whereas UseMvc is in Microsoft.AspNetCore.Mvc.
In ASP.NET Core, the API Explorer actually allows for multiple providers. Which you can follow that in the AddApiExplorer extension method. This comes from the  Microsoft.AspNetCore.Mvc.ApiExplorer NuGet package, which the core package does not depend on, but the full package does. If you wanted the versioned API explorer without any of the UI stuff, you'd have to reference this package and change your configuration to something like:
services.AddMvcCore().AddApiExplorer().AddVersionedApiExplorer();

Since the full package already does this inside UseMvc, you typically don't need this call. In addition, the providers are registered with dependency injection and a declared order (by the defining types). This generally absolves you having to know or register things in the correct order. As long as things are registered at all, the right thing just happens.
I hope that helps clear things up.

@commonsensesoftware thanks for detailed answer.
Yes, I see now, that methods like AddVersionedApiExplorer are extension methods over IMvcCoreBuilder, not over IMvcBuilder and so we cannot do something like
services.AddMvc().AddVersionedApiExplorer( o => o.GroupNameFormat = "'v'VVV" );


More robust map generation classes

The map generation in RogueSharp is very generic and not suitable for creating maps for real games. They were meant to be more of an example that could be expanded upon.
Consider including something similar to https://github.com/odedw/karcero in RogueSharp

I'm using Karcero with RogueSharp for map creation as it's pretty quick and flexible. I have to create the map using Karcero then map each Karcero cell back to a RogueSharp one. Not difficult but not sure how best to integrate it with RogueaSharp. Maybe a custom IMapCreationStrategy but then that would put a dependency on Karcero in RogueSharp and I don't think you really want that do you?

https://github.com/audinowho/RogueElements seems suitable. It even includes an example that shows integration with RogueSharp.


Add STAC and DX-Metering API doc links to main OGC API doc

Links only added to the OGC doc
Looks like

Build finished.

Build finished.


[ANCHOR-738] Remove unused dependencies

Description
This PR removes the unused dependencies in the project.
Context
Dependency upgrade and clean up.
Testing

./gradlew test

Documentation
N/A
Known limitations
N/A

I can see a lot of dependencies were added, was it peer dependencies?

@Ifropc Yep


Refactor RentNavbar component and add RentNavbar to TotalRentCollected component

🚀 Pull Request
Description
A clear and concise description of the changes introduced in this pull request.
I have created a separate component called the RentNavbar component taking inspiration from the main Navbar component.
Related Issue
If this pull request addresses an issue, link to it here (e.g., Closes #123).
Closes #487
Type of Change
What kind of change does this pull request introduce?

[X] 🐛 Bug fix
[ ] 🚀 New feature
[ ] 📄 Documentation update
[ ] 🛠 Code improvement/refactor
[ ] 🖼 UI/UX update
[ ] Other (please specify)

Screenshots (if applicable)
Add screenshots or screen recordings to demonstrate the new feature or fix.

Checklist
Please ensure the following tasks are complete before submitting the pull request:

[X] I have tested my changes and ensured they work as expected.
[ ] I have added any necessary documentation or comments.
[X] I have checked the existing issues and pull requests to avoid duplicates.
[X] I have starred this repository.
[X] I have reviewed my code for best practices and readability.
[ ] I have included any relevant tests (if applicable).

Additional Context
Add any other relevant information or context about the pull request here.

@gauravsingh1281 Can u pls review my PR.


Upgrade sscg from 2.6.2 to 3.0.5

Merge Checklist

All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)

[x] The toolchain has been rebuilt successfully (or no changes were made to it)
[x] The toolchain/worker package manifests are up-to-date
[x] Any updated packages successfully build (or no packages were changed)
[x] Packages depending on static components modified in this PR (Golang, *-static subpackages, etc.) have had their Release tag incremented.
[x] Package tests (%check section) have been verified with RUN_CHECK=y for existing SPEC files, or added to new SPEC files
[x] All package sources are available
[x] cgmanifest files are up-to-date and sorted (./cgmanifest.json, ./toolkit/scripts/toolchain/cgmanifest.json, .github/workflows/cgmanifest.json)
[x] LICENSE-MAP files are up-to-date (./SPECS/LICENSES-AND-NOTICES/data/licenses.json, ./SPECS/LICENSES-AND-NOTICES/LICENSES-MAP.md, ./SPECS/LICENSES-AND-NOTICES/LICENSE-EXCEPTIONS.PHOTON)
[x] All source files have up-to-date hashes in the *.signatures.json files
[x] sudo make go-tidy-all and sudo make go-test-coverage pass
[x] Documentation has been updated to match any changes to the build system
[x] Ready to merge

Summary

What does the PR accomplish, why was it needed?
The PR upgrades sscg to 3.0.5
For 3.0 package upgrades
Change Log

Upgrade to 3.0.5

Does this affect the toolchain?

NO
Associated issues

#xxxx

Links to CVEs

https://nvd.nist.gov/vuln/detail/CVE-YYYY-XXXX

Test Methodology

Buddy build:

https://dev.azure.com/mariner-org/mariner/_build/results?buildId=489935&view=results

Package installation successful


use storage container role assignment

Purpose
Illustrate a nicer way to do the role assignment, now that this PR is merged
https://github.com/Azure/terraform-azurerm-avm-res-storage-storageaccount/pull/43
Does this introduce a breaking change?
[ ] Yes
[x] No

Pull Request Type
What kind of change does this Pull Request introduce?

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[x] Refactoring (no functional changes, no api changes)
[ ] Documentation content changes
[ ] Other... Please describe:

How to Test

Get the code
Run part 5

What to Check
Verify that the following are valid

Confirm the role assignment exists on the storage container, and part 6 can be completed.

with the release of the storage account AVM module v0.1.1, this now works:
results:

& I can complete up to Part 8

Hi. I'm unsure about this change since is uses less granular permissions and we loose the AVM role assignments example. I appreciate that is simplifies the code and it would be great if that was the intent of this lab. The intent is to showcase AVM modules though, so although there is extra complexity using the role assignments module, it does show how to implement the granular role assignment using AVM if it is not available on the native AVM as in this case. To be fair we should probably have a method to apply these roles directly in the storage AVM.

Hi @jaredfholgate I think you're missing the significance of the storage account module change in v0.1.1.
The AVM spec says that child resources must implement role assignments.  The role assignment is at the correct scope (the container) thus is as granular as current state.
I understand this is designed to showcase AVM, but respectfully suggest a better example is needed for role assignments.
Role assignments should use the module interface if it is available, imo.

Hi. Apologies, I missed the fact it was nested under the containers section. I think the doc update threw me off as it was changed from container to account.

Another reason for following this pattern is it also translates to other resources, E g. For keyvault children, like secrets or certs, and it aligns to the way roles are done with bicep child resources.


Added unittests for CLI

Unit tests for CLI

Docs are failing as expected as they're not merged yet

Docs are failing as expected as they're not merged yet

Looks nice!

Looks nice!


[WATCH__VIRAL]— balthazar video telegram link videos Baltasar ebang engonga Video x Trending

21 seconds ago.
L𝚎aked Video Balthazar Baltasar Ebang Engonga Original Video Viral Video L𝚎aked on X Twitter Telegram
Balthazar Baltasar Ebang Engonga Dark Video Female Balthazar Baltasar Ebang Engonga Dark Video Link Viral On Social Media X TikTok Trending Now
Balthazar Baltasar Ebang Engonga Original Video video took the internet by storm and amazed viewers on various social media platforms. Balthazar Baltasar Ebang Engonga , a young and talented digital creator, recently became famous thanks to this interesting video.
L𝚎aked Video Balthazar Baltasar Ebang Engonga Original Video Viral Video L𝚎aked on X Twitter
Balthazar Baltasar Ebang Engonga Original Video video oficial twitter
L𝚎aked Video Balthazar Baltasar Ebang Engonga Original Video Viral Video L𝚎aked on X Twitter.

kjli


[Improve][Zeta] Optimize sink metrics acquisition

Purpose of this pull request
fix: #7735 question1
metrics using Confirm and Cancel in connectors
Does this PR introduce any user-facing change?
How was this patch tested?
Check list

[ ] If any new Jar binary package adding in your PR, please add License Notice according
New License Guide
[ ] If necessary, please update the documentation to describe the new feature. https://github.com/apache/seatunnel/tree/dev/docs
[ ] If you are contributing the connector code, please check that the following files are updated:

Update plugin-mapping.properties and add new connector information in it
Update the pom file of seatunnel-dist
Add ci label in label-scope-conf
Add e2e testcase in seatunnel-e2e
Update connector plugin_config

[ ] Update the release-note.

cc @hailin0


Nick Color

Hi,
I'm using LuckPerms, Vault and VaultChatFormatter.
Is some way how to have other nick colors for other groups?
Thank you for help. Kuba

Nicknames aren't handled by any of those plugins. Preface a nickname with a colour code from https://wiki.ess3.net/mc/ to change its colour. If it's always red, you need to configure your EssentialsX config. Feel free to ask any more questions on the discord!
https://discord.gg/luckperms


Discussion: Would it make sense to replace file_get_contents with guzzle

Hello,
we've encountered an issue with our robots.txt checks. For sites that are not live yet, we expect the checks to fail, but there is no way to set the timeout and these checks take really long time to finish (in the meantime our monitoring system OhDear fails to fetch healtcheck results because response-time is around 30s). But there is no nice way to lower the response time for only these checks (at least not one that I'm aware off).
I know there is a way to set timeout on guzzle, maybe it is on other php http clients as well, but guzzle is the only one I'm familiar with. curl would be another option since it allows setting timeout as well.
Regards
Lio

I agree that this could/should be more flexible. Currently I have no time for handling this.
I'd be open for a PR that solves this:

clean
extensible
tested
documented

@freekmurze thank you for your quick response. I've played around with replacing file_get_contents with curl but I was not able to achieve any progress due to https://github.com/curl/curl/issues/9272. No matter the timeout I set, all failed reuests to robots-txt were taking nearly 5 seconds.

@freekmurze thank you for your quick response. I've played around with replacing file_get_contents with curl but I was not able to achieve any progress due to https://github.com/curl/curl/issues/9272. No matter the timeout I set, all failed reuests to robots-txt were taking nearly 5 seconds.


Improve/simplify DeepWriteable and FromSchema

This fixes a bug that makes this library completely unusable (Typescript 5.1.6).
I got the unknown type when I tried the library on my straightforward schema. So, I tried to copy and paste the examples into my projects, but they didn't work either. After playing around with the library's types in node_modules, I narrowed down the issue to the last ternary operator in the chain for the default value of RESULT in the ParseSchema type parameters, i.e., SCHEMA extends SingleTypeSchema. I tried changing it to SCHEMA extends {type: "object" }, which also didn't work, which was strange, as my object had to at least match that.
So I tried it directly in my source code:
import type { JSONSchema } from 'json-schema-to-ts'
import type { DeepWritable } from 'json-schema-to-ts/lib/types/type-utils/writable'

const dogSchema = {
  type: "object",
  properties: {
    name: { type: "string" },
    age: { type: "integer" },
    hobbies: { type: "array", items: { type: "string" } },
    favoriteFood: { enum: ["pizza", "taco", "fries"] },
  },
  required: ["name", "age"],
} as const satisfies JSONSchema;

// Dog is `unknown`
type Dog = FromSchema<typeof dogSchema>;

type DogSchemaWriteable = DeepWritable<typeof dogSchema>;

// IDE type tooltip says `Foo1` is `false`, but should be `true`
type Foo1 = DogSchemaWriteable extends { type: 'object' } ? true : false;

This led me to believe the Writeable type wasn't working well, or at least it was too complex that my IDE was bailing early from the type calculation. I noticed there was no short-circuit for simple primitive types, so I prepended the type with TYPE extends number | string | boolean | bigint | symbol | undefined | null | Function ? TYPE :   and  Foo1 was finally true in my previous example (when I hovered my mouse over the type variable).
So I tried the example again, but now Dog was never.
I then analysed the FromSchema type and copied it to my file to play around. I defined these types:
type Dog1 = ParseSchema<DogSchemaWriteable, ParseOptions<DogSchemaWriteable, FromSchemaDefaultOptions>>;
type Dog2 = M.$Resolve<Dog1>;

And Dog2 got the gigantic type definition:
{name: "name" extends keyof DeepMergeUnsafe<{}, {name: "name" extends keyof ObjectValues<Dog1> ? Resolve<ObjectValues<...>["name"], ResolveDefaultOptions> : Resolve<Any, ResolveDefaultOptions>, age: "age" extends keyof ObjectValues<Dog1> ? Resolve<ObjectValues<...>["age"], ResolveDefaultOptions> : Resolve<Any, ResolveDefaultOptions>}> ? ("name" extends keyof If<false, If<false, {[p: string]: Resolve<...<...>, ...>}, {[p: string]: Resolve<Any, ...>}>, {}> ? DeepMergeUnsafe<If<false, If<false, {[p: string]: ...<..., ...>}, {[p: string]: ...<..., ...>}>, {}>["name"], DeepMergeUnsafe<{}, {name: "name" extends keyof ...<...> ? Resolve<...[...], ...> : Resolve<Any, ...>, age: "age" extends keyof ...<...> ? Resolve<...[...], ...> : Resolve<Any, ...>}>["name"]> : DeepMergeUnsafe<{}, {name: "name" extends keyof ObjectValues<...> ? Resolve<...<...>["name"], ResolveDefaultOptions> : Resolve<Any, ResolveDefaultOptions>, age: "age" extends keyof ObjectValues<...> ? Resolve<...<...>["age"], ResolveDefaultOptions> : Resolve<Any, ResolveDefaultOptions>}>["name"]) : ("name" extends keyof If<false, If<false, {[p: string]: Resolve<...<...>, ...>}, {[p: string]: Resolve<Any, ...>}>, {}> ? If<false, If<false, {[p: string]: Resolve<...<...>, ...>}, {[p: string]: Resolve<Any, ...>}>, {}>["name"] : never), age: "age" extends keyof DeepMergeUnsafe<{}, {name: "name" extends keyof ObjectValues<Dog1> ? Resolve<ObjectValues<...>["name"], ResolveDefaultOptions> : Resolve<Any, ResolveDefaultOptions>, age: "age" extends keyof ObjectValues<Dog1> ? Resolve<ObjectValues<...>["age"], ResolveDefaultOptions> : Resolve<Any, ResolveDefaultOptions>}> ? ("age" extends keyof If<false, If<false, {[p: string]: Resolve<...<...>, ...>}, {[p: string]: Resolve<Any, ...>}>, {}> ? DeepMergeUnsafe<If<false, If<false, {[p: string]: ...<..., ...>}, {[p: string]: ...<..., ...>}>, {}>["age"], DeepMergeUnsafe<{}, {name: "name" extends keyof ...<...> ? Resolve<...[...], ...> : Resolve<Any, ...>, age: "age" extends keyof ...<...> ? Resolve<...[...], ...> : Resolve<Any, ...>}>["age"]> : DeepMergeUnsafe<{}, {name: "name" extends keyof ObjectValues<...> ? Resolve<...<...>["name"], ResolveDefaultOptions> : Resolve<Any, ResolveDefaultOptions>, age: "age" extends keyof ObjectValues<...> ? Resolve<...<...>["age"], ResolveDefaultOptions> : Resolve<Any, ResolveDefaultOptions>}>["age"]) : ("age" extends keyof If<false, If<false, {[p: string]: Resolve<...<...>, ...>}, {[p: string]: Resolve<Any, ...>}>, {}> ? If<false, If<false, {[p: string]: Resolve<...<...>, ...>}, {[p: string]: Resolve<Any, ...>}>, {}>["age"] : never)}

So I defined a more concise type to use as a replacement for FromSchema:
type FS<SCHEMA extends JSONSchema, OPTIONS extends FromSchemaOptions = FromSchemaDefaultOptions> = M.$Resolve<ParseSchema<DeepWritable<SCHEMA>, ParseOptions<DeepWritable<SCHEMA>, OPTIONS>>>

type Dog3 = FS<DogSchemaWriteable>;

and Dog3 now had the same big type as Dog2. Meaning, the WRITEABLE_SCHEMA was breaking the types and that changing it to a simpler implementation (now that DeepWritable can handle simple types we don't need that type variable with a default value) made it resolve again, even if it was to a huge type and impossible to debug without letting TS narrow it down more.
HOWEVER!
This, then, made me think that maybe my IDE was not doing a full type compilation when I hovered the mouse over to preview the type, so I went back to testing the original DeepWritable like this:
type FOO = DeepWritable<typeof dogSchema> extends { type: 'object' } ? true : false;
const foo: FOO = false;

My IDE said that type FOO was false, but there was a TS error on the assignment: TS2322: Type  false  is not assignable to type  true (!!!).
In sum:
Clearly, this is a bug with my IDE's simplistic type resolution, but the type is also clearly overly complicated where it doesn't need to be, so there's no harm in simplifying the types, especially in types that drill down so much, and I decided to make this PR anyway.
My guess is that
type DeepWritable<TYPE> = TYPE extends unknown[]
    ? TYPE extends [infer HEAD, ...infer TAIL]
      ? [DeepWritable<HEAD>, ...DeepWritable<TAIL>]
      : TYPE extends (infer VALUES)[]
      ? DeepWritable<VALUES>[]
      : never
    : {
        -readonly [KEY in keyof TYPE]: DeepWritable<TYPE[KEY]>;
      };

eventually narrows down to the primitive types because of the prototype properties, which, later down, get duck-typed back to the primitive. Making the DeepWritable type simpler and faster is a win, IMO, which is why I changed it in this PR!
Unless we want to allow primitive types with custom properties in JSON Schema, which are not even representable in JSON, there's no reason to break down primitives into their prototypes and then build them up again.
Note 1:
This is what I mean by primitives with custom properties:
type BAR = string & {a: number};
const bar: BAR = 'bar' as BAR;
bar.a = 1;

Such an exotic type can't even be represented in JSON, so covering that case at the cost of build time makes no sense.
Note 2:
Allowing a WRITABLE_SCHEMA to be a type parameter makes no sense because its only type restriction is extending WritableJSONSchema7, so it would allow it to be used like FromSchema<DogSchema, FromSchemaDefaultOptions, CatSchema>, and it would basically be the same as FromSchema<CatSchema, FromSchemaDefaultOptions> because the first type parameter is not actually used in the type's body, just in the 3rd type parameter's default value. So simplifying FromSchema also made sense to me!
Note 3:
The tests passed and I also ran prettier and the linter.
P.S.:
Great job on this library and ts-algebra! They are really cool!

Awesome ! Thank you very much @TheDSCPL ! Will have a look !

@TheDSCPL Should be fixed with https://github.com/ThomasAribart/json-schema-to-ts/pull/176


[iOS][RN 0.61.3] Detox selector failing after upgrade

After the RN upgrade, the by.traits(['selected']) stopped working. It seems that Detox doesn't fully support 0.61 and I'm open to helping with this if some sort of guidance can be given to me (where should I change stuff to identify why it fails)

The same error is described at Stackoverflow but I think it may not be just a help request

The suite that is failing has basically two tests:
[PASS] element(by.id('FirstName').withAncestor(by.id('SignUpScreen'));
[FAIL] element(by.id('FirstName').withAncestor(by.id('SignUpScreen')).and(by.traits(['selected'])));

The failing one shows the following "query":
(
    (
        !(kindOfClass('RCTScrollView')) &&
        (
            (
                (
                    (respondsToSelector(accessibilityIdentifier) && accessibilityID('FirstName'))
                    && (
                        (kindOfClass('UIView') || respondsToSelector(accessibilityContainer))
                        && ancestorThatMatches((respondsToSelector(accessibilityIdentifier) && accessibilityID('SignUpScreen')))
                    )
                ) && ((respondsToSelector(isAccessibilityElement) && isAccessibilityElement) && accessibilityTraits: UIAccessibilityTraitSelected))
            && !(kindOfClass('UIAccessibilityTextFieldElement'))
        )
    ) ||
    (
        (
            (kindOfClass('UIView') || respondsToSelector(accessibilityContainer))
            && parentThatMatches(kindOfClass('RCTScrollView'))
        )
        && (
            (kindOfClass('UIView') || respondsToSelector(accessibilityContainer))
            && parentThatMatches(((
                (
                    (respondsToSelector(accessibilityIdentifier) && accessibilityID('FirstName')) &&
                    (
                        (kindOfClass('UIView') || respondsToSelector(accessibilityContainer))
                        && ancestorThatMatches((respondsToSelector(accessibilityIdentifier) && accessibilityID('SignUpScreen')))
                    )
                ) && ((respondsToSelector(isAccessibilityElement) && isAccessibilityElement) && accessibilityTraits: UIAccessibilityTraitSelected)
            ) && !(kindOfClass('UIAccessibilityTextFieldElement'))))
        )
    )
)

And the following hierarchy (cleaned up a bit):
|--<RCTScrollView:0x7f92ab6ee4d0; AX=N; AX.id='SignUpScreen';>
|  |  |--<RCTView>
|  |  |  |--<RCTSinglelineTextInputView>
|  |  |  |  |--<RCTUITextField AX.id='LastName'; AX.traits='UIAccessibilityTraitSelected'>
|  |  |  |  |  |--<_UITextFieldCanvasView>
|  |  |  |  |  |--<UIAccessibilityTextFieldElement AX.id='LastName'; AX.traits='UIAccessibilityTraitSelected'>
|  |  |--<RCTTextView AX.id='Typography'; AX.label='Last name'; AX.traits='UIAccessibilityTraitStaticText'>
|  |--<RCTView AX.label='First name';>
|  |  |--<RCTView>
|  |  |  |--<RCTSinglelineTextInputView>
|  |  |  |  |--<RCTUITextField AX.id='FirstName'; AX.traits='UIAccessibilityTraitSelected'>
|  |  |  |  |  |--<UIFieldEditor>
|  |  |  |  |  |  |--<_UITextFieldCanvasView>
|  |  |  |  |  |  |  |--<UITextSelectionView>
|  |  |  |  |  |  |  |  |--<UIView>
|  |  |  |  |  |--<UIAccessibilityTextFieldElement AX.id='FirstName'; AX.traits='UIAccessibilityTraitSelected'>

Now, it's weird to me that the whole problem is around the .and(by.traits(['selected']))) part, which used to work at 0.59.10.
And, as far as I understand, both query and hierarchy have the UIAccessibilityTraitSelected... so... why exactly it is failing?
What am I missing?

Hello,
We are currently working on a new underlying system to replace Earl Grey, so until that arrives, I don't think we'll invest much time in Earl Grey issues (which this looks like).
If you'd like to assist with debugging, please follow the Xcode integration guide and investigate why Earl Grey fails to match this combination.
Thanks

Is there any timeline for this new tool?

When it’s done. There is a lot of work still, and also it will take a while to stabilize.

Also, hard for me to see why it would work in .59 but not in .61 if the trait is set correctly by RN.

@LeoNatan After further details, it seems that there's some type of delay happening. Some times it works and some times they don't. I'll try to change to selected for now... Maybe it's a RN-related issue.

But if the hierarchy after failure shows that the trait is there, it doesn't make sense that the matcher system in EG would fail to find it...

@LeoNatan The Accessibility Inspector doesn't show anything like "selected" on them. Now, if I change to checked instead, it shows the value as checked. I'll try to dig a bit more over the weekend.
Thanks for the help so far.

Great, looking forward to your findings.

@LeoNatan Seems that the whole problem is around https://github.com/wix/Detox/commit/fd02f1f98f5a2f0789b43aaccf47bb0ce1ba1e4e#diff-63bcd6e377115ee1fcf2d9deec677a51 .
More exactly:
matcher = grey_allOf(matcher, grey_not(grey_kindOfClass(NSClassFromString(@"UIAccessibilityTextFieldElement"))), nil);

I did a test with the same selectors but Text instead of TextInput and they worked.
You can check a bit about the tests here:
https://gist.github.com/sidferreira/ea637de661c710468fc57a1eb997cff9
This issue made me think about changing some of my tests for Focused instead of Selected but seems that Detox matchers are incomplete.
I found https://github.com/wix/Detox/blob/bd96780505ebcdabde45c285bebd4644e46d0091/detox/src/ios/earlgreyapi/GREYMatchers.js#L209 but seems not to be in use.

Anyways, WIP: https://github.com/sidferreira/Detox/tree/toBeFocused

I don't know what "focused" means. No such accessibility trait exists in iOS:
https://developer.apple.com/documentation/uikit/accessibility/uiaccessibility/accessibility_traits?language=objc

In general, "focus" as a term on iOS does not exist. It exists in tvOS, where what Apple calls the "focus engine" is used for the cursor system. That's not in use in iOS.

@LeoNatan https://google.github.io/EarlGrey/Classes/GREYMatchers.html#/c:objc(cs)GREYMatchers(cm)matcherForAccessibilityElementIsFocused

I see that it uses this method to determine selection:
https://developer.apple.com/documentation/objectivec/nsobject/1615190-accessibilityelementisfocused?language=objc
I am not aware what this means. "YES if an assistive technology is virtually focused on the element" tells me nothing. Apple docs are terrible.
Regarding UIAccessibilityTextFieldElement, could you please explain why you think this is the problem?
Even in your example, you can see that this element exists, but is not the one you want:
|--<RCTScrollView:0x7f92ab6ee4d0; AX=N; AX.id='SignUpScreen';>
|  |  |--<RCTView>
|  |  |  |--<RCTSinglelineTextInputView>
|  |  |  |  |--<RCTUITextField AX.id='LastName'; AX.traits='UIAccessibilityTraitSelected'>
|  |  |  |  |  |--<_UITextFieldCanvasView>
|  |  |  |  |  |--<UIAccessibilityTextFieldElement AX.id='LastName'; AX.traits='UIAccessibilityTraitSelected'>

The element you wish to match is RCTUITextField, rather than UIAccessibilityTextFieldElement.

Looking at what is possible to query using the new system we are working on, there is both selected and hasFocus:
https://developer.apple.com/documentation/xctest/xcuielementattributes?language=objc
If you can, could you use the accessibility inspector on your views, and see when focused and selected change?

toBeFocused (or hasFocus, whatever :) )

This is a test we need on a screen. We want to be sure the inputs lose the focus in some cases. I reviewed EarGrey method and seems to be when VoiceOver or something is focusing on that element, not if an input has the focus or not (what I'm looking for).

The query issue

I dug a bit more and I noticed one small detail I missed previously:
|--<RCTUITextField:0x7f9f0600fe00;
        AX=N;
        AX.id='InputSelectedState';
        AX.value='InputSelectedState';
        AX.frame={{65, 119}, {284, 17}};
        AX.activationPoint={207, 127.5};
        AX.traits='UIAccessibilityTraitSelected';
        AX.focused='N';
        frame={{5, 5}, {284, 17}};
        alpha=1;
        text='InputSelectedState'>
|  |--<_UITextFieldCanvasView:0x7f9f05909fb0;
        AX=N;
        AX.frame={{65, 119}, {284, 17}};
        AX.activationPoint={207, 127.5};
        AX.traits='UIAccessibilityTraitNone';
        AX.focused='N';
        frame={{0, 0}, {284, 17}};
        alpha=1;
        UIE=N>
|  |--<UIAccessibilityTextFieldElement:0x6000017def00;
        AX=Y;
        AX.id='InputSelectedState';
        AX.value='InputSelectedState';
        AX.frame={{65, 119}, {284, 17}};
        AX.activationPoint={207, 127.5};
        AX.traits='UIAccessibilityTraitSelected';
        AX.focused='N'>

RCTUITextField has AX=N... Does that mean that (respondsToSelector(isAccessibilityElement) && isAccessibilityElement) returns false?
About your other tests, I'll run them ASAP... But it

seems that the fields with selected doesn't show as selected...

Do you happen to have the same project before upgrading to RN61? Could and probably is a bug on their end.


Fix upload_app client parameters

https://ocd.appscale.com:8080/job/Daily Build/1846/

https://ocd.appscale.com:8080/job/Daily Build/1860/


Chat - Creating a new chat with the same email while offline creates duplicate chats

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Launch New Expensify app.
Disconnect network.
Create a new chat with a new account.
Return to LHN.
Tap + icon > Chat.
Enter the same email used in Step 3.
Tap on the search result.

Expected Result:
User is redirected to the existing chat that is created in Step 3.
Actual Result:
User is redirected to a new chat with the same member. The chat is duplicated.
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android / native
[x] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[x] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number: v1.3.30-5
Reproducible in staging?: y
Reproducible in production?: n
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://github.com/Expensify/App/assets/93399543/1c0aed10-9411-4618-b8ae-a9e4da8506ac

Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:
View all open jobs on GitHub

:wave: Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open StagingDeployCash deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

Identify the pull request that introduced this issue and revert it.
Find someone who can quickly fix the issue.
Fix the issue yourself.

We already had this bug in the previous deploy checklist

Is it being worked on @mountiny?

Looks like this was fixed here https://github.com/Expensify/App/pull/21265. Closing in favor of https://github.com/Expensify/App/issues/21184.

Yep sorry was on mobile so couldnt grab the links fast.


unifi8: init at 8.0.7

Description of changes
The unifi controller was renamed the Unifi Network Server recently, and version 8.0.7 was released on the 20th of November.

Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

Priorities
@globyn @patryk27

Looks alright, but lemme try to deploy it to my server and see if it starts - I'll report back with results 🙂


OCPBUGS-20481: Fix vsphere csi controller pods from getting constantly restarted

Fixes https://issues.redhat.com/browse/OCPBUGS-20481

/jira refresh

/retest

/lgtm

/cherry-pick release-4.14

/cherry-pick release-4.13


ci(dependabot): ignore esm major versions

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
479

Relevant Lines:
479

💛  - Coveralls


Typo in README.

"Highights"

thanks, want to do a pr? or I can fix, thanks

pr is at https://github.com/jonschlinkert/markdown-toc/pull/79 .

#79 has been merged, this can probably be closed.

Thanks @Daniel-Mietchen for the PR.
Thanks @levithomason for the reminder.


refactor(threads): improve panic handling and docs

Description
Add some missing documentation about possible panics in riot-rs-threads when a function is expected to be called only inside a thread context.
Avoid panics where possible through early returns.
Also adds some documentation for Channel.
Issues/PRs references
Extracted from https://github.com/future-proof-iot/RIOT-rs/pull/381#discussion_r1721324000.
Open Questions

@ROMemories you proposed in https://github.com/future-proof-iot/RIOT-rs/pull/381#discussion_r1721324000 to use NOTE(no-panic)-style comments to document why an unwrap can't panic. I've instead used expect, because we a) don't know that it will never panic (it's the callers responsibility) and b) it prints the comment as part of the panic message. Wdyt?

Avoid panics where possible through early returns.

This concerns the functions yield_same and sleep. If called from outside a thread context, the operations are now no-ops, instead of causing panics. Do you agree that we should prefer no-ops over panics as long as it doesn't cause any undefined behavior?

[x] I have followed the Coding Conventions.
[x] I have performed a self-review of my own code.
[x] I have made corresponding changes to the documentation.

maybe it would make sense to add debug_assert!s with a developer-friendly message, and unwrap otherwise

What would be the advantage of this compared to using expect?
According to the Rust docs about Converting Errors into Panics:

Of the two, expect is generally preferred since its msg field allows you to convey your intent and assumptions which makes tracking down the source of a panic easier.

lgtm!


clarify text / add additional info

added some more info and helped to… clarify some of the text.

[ ] I have read freeCodeCamp's contribution guidelines.
[ ] My pull request has a descriptive title (not a vague title like Update index.md)
[ ] My pull request targets the master branch of freeCodeCamp.
[ ] None of my changes are plagiarized from another source without proper attribution.
[ ] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

Closed and Reopened this PR to attempt to resolve a specific Travis build failure.

LGTM


Show timestamps for creation and last modified in task details

Would be nice to have that information somewhere in the details.
(I hope you don't feel pressured by all the issues I'm creating. It's not super urgent, I just want to get it out before I forget)

No problem, I'll try to add those in the major release :)

Implemented it on dev branch, will be available in the next release.


Switch focus to password field with tab key

When trying to log in, after entering the e-mail and pressing tab, the selection changes to "forgot password" field. For better UX, it should switch focus to the password field.

When have delete the forgot password link, so not useful anymore


Import Dropbox Forms data into Open Collective

Require https://github.com/opencollective/opencollective/issues/7300

Script ran successfuly


Mismatch of number of parameters

Hey, the number of parameters in your custom model are not matching with nay of the model here?
https://pytorch.org/vision/stable/models/vision_transformer.html

Hey, the number of parameters in your custom model are not matching with nay of the model here?
https://pytorch.org/vision/stable/models/vision_transformer.html

I have never used torch-vision ViT models before so cannot really tell you why that is the case without without inspecting things in detail. The video is based on timm.
Anyway, I suggest you go module by module and find the first one where the # parameters disagree. It will most likely be related to some different hyperparameter

Hey there @jankrepl (yes I'm trolling) I miss your YouTube videos! Hope you are planning to do another one soon! I hear there's this new thing called Stable Diffusion...

@vgoklani Hehe:) Thanks, I got a bit lazy recently. I will try to go back to more frequent uploads:)


Add a Log handler, to emit metrics via logger; Vagrant setup.

This adds a Log handler that can be used to test metrics collection
without actually sending to a remote service: metrics are outputted as
JSON via the logrus logger.
This also adds a Vagrant config, for local development and testing.

looks pretty good to me. only thing is - hopefully Log name does not cause too many clashes as the code grows, because it is defined and exported.

@mikepea +1 fix and ship

@tsheasha all done, i'll let you take the call to merge.

@mikepea lgtm!


hare: fix data races

Motivation

Closes #3067

Changes

fix sync.Waitgroup data races in hare

Test Plan

Unit tests, system tests
DevOps Notes

[x] This PR does not require configuration changes (e.g., environment variables, GitHub secrets, VM resources)
[x] This PR does not affect public APIs
[x] This PR does not rely on a new version of external services (PoET, elasticsearch, etc.)
[x] This PR does not make changes to log messages (which monitoring infrastructure may rely on)

bors try

@nkryuchkov

It looks like the PR fixes all hare data races seen until now. There are still data races in other packages though (see #2930), but they will be fixed in other PRs

how did you verify this? i still don't know how to locally reproduce this.

@countvonzero

how did you verify this?

By the knowledge that the code I added should remove racy behavior. However, this statement is not true anymore since need to make the requested changes. But why do we need to verify that? If a PR looks like it fixes data races, we can just merge it and if we see data races after that, we can create a new PR. Anyway, there's no guarantee of lack of data races in this and even in other parts of the code because they can happen under certain conditions like on a machine with weak resources.

i still don't know how to locally reproduce this.

It's very flaky, so it's hard to reproduce. I cannot reproduce it anymore as well. I think there're more chances to reproduce it either by restarting the GitHub action in https://github.com/spacemeshos/go-spacemesh/pull/2930 until the race appears or by trying to run hare and app tests in a loop on something like Raspberry Pi with arm64 image. If you want, I can remove the code for fixing this particular data race and create an issue when I see it next time

@nkryuchkov

But why do we need to verify that? If a PR looks like it fixes data races, we can just merge it and if we see data races after that, we can create a new PR.

this is not how bug fixes should work. if we don't verify, and keep merging changes that we think work but don't know for sure, we will end up with crusty code that's difficult for future devs to understand.
granted, there will be cases where it's clear that should be fixed. for example, a variable that's not thread-safe, or simply coding mistakes. in this specific case, you are adding mutex around an already thread-safe variable. say a new member join tomorrow, how are you going to explain to him/her why this mutex is added and what function does it serve?
besides, this fix doesn't make sense. if thread A calls wg.Wait() before thread B calls wg.Add(1), which i think is the issue you are trying to fix, adding mutex around wg doesn't make a difference. this order (Wait() before Add()) can still happen. that's why i want to reproduce this and see exactly what the race condition is.

i still don't know how to locally reproduce this.

It's very flaky, so it's hard to reproduce.

very flaky == easy to reproduce
i think you are trying to say it's difficult to reproduce.

I cannot reproduce it anymore as well. I think there're more chances to reproduce it either by restarting the GitHub action in #2930 until the race appears or by trying to run hare and app tests in a loop on something like Raspberry Pi with arm64 image. Perhaps you can also run it in Docker after limiting CPU resources. If you want, I can remove the code for fixing this particular data race and create an issue when I see it next time

my preference will be to fix this when there is data on the actual race. at this point i am not sure what you are trying to fix.

@countvonzero

this is not how bug fixes should work. if we don't verify, and keep merging changes that we think work but don't know for sure, we will end up with crusty code that's difficult for future devs to understand.

I was going to merge the code that should fix the data races it's intended to fix and I thought that all seen data races were fixed. Also, sometimes, that hard to be sure that a data race is fully fixed. E.g. if it's caused by a log after a test is finished. By fixing one log, there can be another one that's reproduced very rarely on slow machines. It would be kind of another data race, but it's actually the same issue.

besides, this fix doesn't make sense. if thread A calls wg.Wait() before thread B calls wg.Add(1), which i think is the issue you are trying to fix, adding mutex around wg doesn't make a difference. this order (Wait() before Add()) can still happen. that's why i want to reproduce this and see exactly what the race condition is.

I don't argue that it's actually not a good solution and I already agreed that this needs to be fixed.

i think you are trying to say it's difficult to reproduce.

Yes, sorry

my preference will be to fix this when there is data on the actual race. at this point i am not sure what you are trying to fix.

I agree, thanks. I'll remove this particular fix from the PR and will create a new issue when I reproduce this data race.

bors merge

bors merge


Implement GlobalStateEntry for Capnproto

See https://github.com/casper-network/casper-node/compare/dev...feat-capnproto#diff-3932e57afb4602ad0080d518aa60f2c1b4c5a6f50d53176d32d071b0d8527015R36

This particular abstraction is not appropriate for Storage 2.0.  The new trie will not store leaves with values since they are redundant.


rework eslint config

use new explicit config that specifies each rule
upgrade eslint to 7.1.0
add new plugins with selected rules enabled
fix discovered issues, remove global wipPrefixes

Rules are mostly based on my config. Two of the plugins still don't specify eslint 7 compatibilty, but I think it's no issue, they do work fine.

I can undo the config/dependency changes if requested.
There is a certain benefit of depending on a shared config because much less work is required to update the config, even thought we need to disable 20-something rules that are too opinionated in the airbnb config.

Updated eslint and plugins again. eslint-plugin-import is now officially compatible with eslint 7 which only leaves eslint-plugin-sonarjs not officially compatible (but still workes). I'm still quite fond of eslint-plugin-sonarjs because it does provide a few useful rules.

Rebased and fixed one more new violation (detected by eslint-plugin-sonarjs 😉) that came up.

ping LG-TM


Add examples

@linuxlonelyeagle , what is the status of this PR?
Please resolve merge conflicts if you want to move ahead with review process. You might also chose to mark it as a draft if it is still a work in progress.


Add context to unregistered task name to error context

I caused this error during development and having the name of the task on it is helpful for debugging.
Split out from #4435

Is the dist ID enough to distinguish the "task"?

I have also done something like this so very much in favor.

Is the dist ID enough to distinguish the "task"?

For me the problem was package name vs. url so this was sufficient


fix: support proxies for callback

This references standard and pseudo-standard headers for determining the domain so we can properly determine the host and protocol for callback URLs.

Without this, the Epic Stack GitHub auth doesn't currently work: https://www.epicstack.dev/login


API generation - Fix theme naming bug and add output directory to command arg

This is some things needed for phalcon 2 api generation.
I will maybe add more commits, feel free to merge or not, i can open a new PR if you do

Thanks


(PUP-9574) Reword allow_duplicate_certs setting

The setting does not allow a cert request to overwrite a certificate. It's more
that the CA will accept a CSR while there is already a pending CSR or a signed
cert with that name. If it's the former, then the new CSR will overwrite the old
one. If it's the latter, then the CSR will be saved, but the user must still
clean (revoke+delete) the old cert, and sign the new CSR.

CLA signed by all contributors.

need to retarget 6.4.x. There's no real benefit to retargeting earlier branches, because the setting doesn't work (agents always download the old csr or cert, leading to mismatched keys)


[c2cpg] Revisit the kernel benchmark

Is your feature request related to a problem? Please describe.
I can't replicate the parser benchmark with recent Linux kernel versions with the command line arguments available.
https://github.com/joernio/joern/tree/master/joern-cli/frontends/c2cpg#parser-benchmarks
Describe the solution you'd like
We may need to follow the instructions below from CDT and pre-create an index for the tool to finish in a finite time.
https://github.com/eclipse-cdt/cdt/tree/main/FAQ#whats-the-best-way-to-set-up-the-cdt-to-navigate-linux-kernel-source
I suspect some AST creation logic is costly, causing the slowdown.
Describe alternatives you've considered
I tried creating a lighter frontend to parse only the header files and skip method bodies. Tried upgrading to CDT 11.2 and disabled macro expansion completely. These approaches didn't yield the kind of performance promised in the readme.
Additional context
Add any other context or screenshots about the feature request here.

Please note: the benchmark you linked is for parsing only. Ofc, the whole CPG generation takes much longer.
@itsacoderepo has some recent numbers for running c2cpg on the kernel sources. But afair, he was running it on quite some beefy machine.

Also: Sadly, we can not use Eclipse Indexing at all as this is tightly coupled to Eclipse Workspaces and other internals that are not available as standalone libraries.

@max-leuthaeuser below is the code I came up with to enable the index. Also tested with some projects. While it worked I didn't see a huge improvement probably some other setting is missing.
https://github.com/AppThreat/chen/blob/main/platform/frontends/c2cpg/src/main/scala/io/appthreat/c2cpg/parser/CdtParser.scala#L53

I am pretty sure using the index would only be beneficial when doing some reparsing (file changes) which we won't have anyway.

It must help avoid the need for lookups in the include directories as well as expand macros.

I guess one needs to prepopulate the index with the include directories. Last time I tried this it crashed due to missing runtime dependencies.


update readme.md file

issue #23

@thebishaldeb Please review

Before changes:-

After changes :-

THe images need to be updated too. The login page, registration page, comments page (actually all the pagrs currently there) need to be present in the readme in small size and with proper heading.

@thebishaldeb Please review

The headings are wrong. Please check them out. The add, edit comments, registration and login page are different. Also there had been style changes since the prev pictures in the readme. So include the new ones.
You might consider adding a GIF instead too, instead of all the pictures.

Please tell me explain heading of image
On Sat, Dec 7, 2019, 11:00 PM Bishal Deb<EMAIL_ADDRESS>wrote:

The headings are wrong. Please check them out. The add, edit comments,
registration and login page are different. Also there had been style
changes since the prev pictures in the readme. So include the new ones.
You might consider adding a GIF instead too, instead of all the pictures.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/NJACKWinterOfCode/Instances/pull/27?email_source=notifications&email_token=AJ23PLFUEXMYKG3JHN2GB2DQXPMSXA5CNFSM4JXO2PWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGGLR6A#issuecomment-562870520,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJ23PLDQBVTJP7LDDL4J3PDQXPMSXANCNFSM4JXO2PWA
.

You wrote the landing page as login page which is not. Also registration page isn't that.
Those are the ones having forms.

@thebishaldeb Please check

It is still wrong. If you logout, then the page you see for loging in is the login page, similarly the registration page. Also if you click on add comment, you will see the add comments page, similarly edit comments page.
If you click on add new instances, that is add event page, similarly edit event.


Move code relating to the first pass to its module

This splits the massive parse module in two, making a clear distinction what code relates to the first pass exclusively, the second or both. The new firstpass module only exports a single function called run_first_pass. It also makes the simd module a submodule of this new firstpass module, to make it explicit what the SIMD code is used for.
It also moves a number of key (public) types into the crate root.
This PR is the start of my effort to improve the structure and maintainability of the repository.

Closes https://github.com/raphlinus/pulldown-cmark/issues/402.

No logic was changed in the making of this PR :-)


used_bytes keeps growing when query 'v1/db_size/get'

node shutdown by itself after running days.
Database has reached an unsafe level of usage, shutting down to avoid corrupting the database.  Please increase the value set for "chain-state-db-size-mb" and restart the process!
I enabled db_size_api_plugin. After querying 'v1/db_size/get' some times, I notice the 'used_bytes' grows with time while no transactions executed.
Should I persistently monitor this filed and shutdown the node when the size reaches the threshold?
Is it right that the size just grow with no transactions. Or is there a configuration I can modify?
Thank you!

the response of 'v1/db_size/get' looks like this
{
"free_bytes": "10714166784",
"used_bytes": 23251440,
"size": "10737418224",
"indices": [
{
...
}
]
}

It shrinks sometime later. Everything seems to be right.


Perez coeff ModelChain example

[x] Closes #2127
[x] I am familiar with the contributing guidelines
[ ] Tests added
[ ] Updates entries in docs/sphinx/source/reference for API changes.
[x] Adds description and name entries in the appropriate "what's new" file in docs/sphinx/source/whatsnew for all changes. Includes link to the GitHub Issue with :issue:`num` or this Pull Request with :pull:`num`. Includes contributor name and/or GitHub username (link with :ghuser:`user`).
[ ] New code is fully documented. Includes numpydoc compliant docstrings, examples, and comments where necessary.
[x] Pull request is nearly complete and ready for detailed review.
[x] Maintainer: Appropriate GitHub Labels (including remote-data) and Milestone are assigned to the Pull Request and linked Issue.

This PR adds an example of using different Perez coefficients in a ModelChain as discussed in #2127. I wasn't sure where to put it so I stuck it in the irradiance transposition section
Rendering of the gallery example

Thanks @bgpierc!


CVL  much too high

Describe the bug
There is a massive problem with version v1.3.20240705.
The CVL is wrong and almost shot my cells.
Both the latest 1.3.20240705 and the nightly build etc. are affected.
Apparently the software reads CVL from the BMS (max cell voltage).
In Serialbattery I set 3.45V (bulk) and 3.35V (float) as the maximum voltage, but serialbattery still takes the full 3.65V from the BMS. When the cells reach this voltage, the value jumps back and forth. This means that it charges briefly at full power, then overshoots to 3.6V/cell and then immediately discharges again. I'm now reinstalling an old version, the problem didn't exist there.
Or am I doing something wrong?
I have a 16s system and that would be a total of 55.2V CVL at 3.45V. With float it would still be 53.6V.
Here you can see the 58.4V CVL....

How to reproduce
cvl that is too high is constantly displayed...
Expected behavior
What is expected is a cvl similar to the "old" version, i.e. maximum cell voltage * number.... in my case 3.45V * 16 = 55.2V
Driver version
v1.3.20240705
Venus OS device type
Raspberry Pi 3
Venus OS version
3.33
BMS type
JKBMS / Heltec BMS
Cell count
16
Battery count
3
Connection type
Bluetooth
Config file
[DEFAULT]

; --------- Set logging level ---------
LOGGING = INFO

; --------- Battery Current limits ---------
MAX_BATTERY_CHARGE_CURRENT = 80.0
MAX_BATTERY_DISCHARGE_CURRENT = 80.0

; --------- Cell Voltages ---------
MIN_CELL_VOLTAGE   = 3.000
MAX_CELL_VOLTAGE   = 3.450
FLOAT_CELL_VOLTAGE = 3.350

; --------- Bluetooth BMS ---------
BLUETOOTH_BMS = Jkbms_Ble C8:47:80:03:8A:2C, Jkbms_Ble C8:47:80:03:82:4A, Jkbms_Ble C8:47:80:03:89:20,

; --------- Bluetooth use USB ---------
BLUETOOTH_USE_USB = False

; --------- BMS disconnect behaviour ---------
BLOCK_ON_DISCONNECT = True

; --------- Charge mode ---------
LINEAR_LIMITATION_ENABLE = True
LINEAR_RECALCULATION_EVERY = 60
LINEAR_RECALCULATION_ON_PERC_CHANGE = 5

; --------- Charge Voltage limitation (affecting CVL) ---------
CVCM_ENABLE = True
CELL_VOLTAGE_DIFF_KEEP_MAX_VOLTAGE_UNTIL        = 0.010
CELL_VOLTAGE_DIFF_KEEP_MAX_VOLTAGE_TIME_RESTART = 0.015
CELL_VOLTAGE_DIFF_TO_RESET_VOLTAGE_LIMIT        = 0.080
MAX_VOLTAGE_TIME_SEC = 600
SOC_LEVEL_TO_RESET_VOLTAGE_LIMIT = 80

; --------- SOC calculation ---------
SOC_CALCULATION   = False

; --------- Cell Voltage Current limitation (affecting CCL/DCL) ---------
CCCM_CV_ENABLE = True
DCCM_CV_ENABLE = True
CELL_VOLTAGES_WHILE_CHARGING      = 3.55, 3.45, 3.42, 3.38, 3.30
MAX_CHARGE_CURRENT_CV_FRACTION    =    0, 0.07, 0.7, 1, 1
CELL_VOLTAGES_WHILE_DISCHARGING   = 2.70, 2.80, 2.90, 3.10
MAX_DISCHARGE_CURRENT_CV_FRACTION =    0,  0.1,  0.5,    1

; --------- Cell Voltage limitation (affecting CVL) ---------
CVL_ICONTROLLER_MODE   = False
CVL_ICONTROLLER_FACTOR = 0.2

; --------- Temperature limitation (affecting CCL/DCL) ---------
CCCM_T_ENABLE = True
DCCM_T_ENABLE = True
TEMPERATURES_WHILE_CHARGING      =    0,    2,    5,   10,   15,   20,   35,   40,   55
MAX_CHARGE_CURRENT_T_FRACTION    = 0.00, 0.10, 0.20, 0.50, 1.00, 1.00, 1.00, 0.40, 0.00
TEMPERATURES_WHILE_DISCHARGING   =  -20,    0,    5,   10,   15,   45,   55
MAX_DISCHARGE_CURRENT_T_FRACTION = 0.00, 0.20, 0.50, 0.80, 1.00, 1.00, 0.00

; --------- Additional settings ---------
;BMS_TYPE = Jkbms
AUTO_RESET_SOC = False
PUBLISH_CONFIG_VALUES = True
BATTERY_CELL_DATA_FORMAT = 0
MIDPOINT_ENABLE = False
TEMP_BATTERY = 1
TEMP_1_NAME = Temp Akku 1
TEMP_2_NAME = Temp Akku 2
TEMP_3_NAME = Temp Akku 3
TEMP_4_NAME = Temp Akku 4

; --------- BMS specific settings ---------
JKBMS_CAN_CELL_COUNT = 16

Relevant log output
2024-07-08 16:54:31.316384500 *** CCGX booted (0) ***

==> /data/log/dbus-blebattery.0/current <==
2024-07-08 16:55:26.041405500
2024-07-08 16:55:26.041409500 INFO:Bluetooth details
2024-07-08 16:55:26.413926500 Attempting to disconnect from C8:47:80:03:8A:2C
2024-07-08 16:55:26.413934500 Successful disconnected

==> /data/log/dbus-blebattery.1/current <==
2024-07-08 16:55:26.118110500
2024-07-08 16:55:26.118116500 INFO:Bluetooth details
2024-07-08 16:55:26.438130500 Attempting to disconnect from C8:47:80:03:82:4A
2024-07-08 16:55:26.438136500 Successful disconnected

==> /data/log/dbus-blebattery.2/current <==
2024-07-08 16:55:26.114153500
2024-07-08 16:55:26.114157500 INFO:Bluetooth details
2024-07-08 16:55:26.543551500 Attempting to disconnect from C8:47:80:03:89:20
2024-07-08 16:55:26.543557500 Successful disconnected

==> /data/log/dbus-blebattery.0/current <==
2024-07-08 16:55:31.914927500 Device C8:47:80:03:8A:2C (public)
2024-07-08 16:55:31.914935500   Alias: E&H 02
2024-07-08 16:55:31.914937500   Paired: no
2024-07-08 16:55:31.914939500   Trusted: no
2024-07-08 16:55:31.914941500   Blocked: no
2024-07-08 16:55:31.914942500   Connected: no
2024-07-08 16:55:31.914944500   LegacyPairing: no
2024-07-08 16:55:31.914946500   UUID: Device Information        (0000180a-0000-1000-8000-00805f9b34fb)
2024-07-08 16:55:31.914950500   RSSI: -52
2024-07-08 16:55:31.917633500

==> /data/log/dbus-blebattery.1/current <==
2024-07-08 16:55:31.909116500 Device C8:47:80:03:82:4A (public)
2024-07-08 16:55:31.909123500   Alias: E&H 01
2024-07-08 16:55:31.909125500   Paired: no
2024-07-08 16:55:31.909126500   Trusted: no
2024-07-08 16:55:31.909128500   Blocked: no
2024-07-08 16:55:31.909130500   Connected: no
2024-07-08 16:55:31.909132500   LegacyPairing: no
2024-07-08 16:55:31.909134500   UUID: Device Information        (0000180a-0000-1000-8000-00805f9b34fb)
2024-07-08 16:55:31.909138500   RSSI: -57
2024-07-08 16:55:31.913529500

==> /data/log/dbus-blebattery.2/current <==
2024-07-08 16:55:31.979882500 Device C8:47:80:03:89:20 (public)
2024-07-08 16:55:31.979890500   Alias: E&H 03
2024-07-08 16:55:31.979892500   Paired: no
2024-07-08 16:55:31.979894500   Trusted: no
2024-07-08 16:55:31.979896500   Blocked: no
2024-07-08 16:55:31.979897500   Connected: no
2024-07-08 16:55:31.979899500   LegacyPairing: no
2024-07-08 16:55:31.979901500   UUID: Device Information        (0000180a-0000-1000-8000-00805f9b34fb)
2024-07-08 16:55:31.979905500   RSSI: -60
2024-07-08 16:55:31.981098500

==> /data/log/dbus-blebattery.0/current <==
2024-07-08 16:55:39.838524500 INFO:SerialBattery:
2024-07-08 16:55:39.839310500 INFO:SerialBattery:Starting dbus-serialbattery
2024-07-08 16:55:39.841036500 INFO:SerialBattery:Venus OS v3.33
2024-07-08 16:55:39.841611500 INFO:SerialBattery:dbus-serialbattery v1.3.20240705

==> /data/log/dbus-blebattery.1/current <==
2024-07-08 16:55:39.820028500 INFO:SerialBattery:
2024-07-08 16:55:39.820235500 INFO:SerialBattery:Starting dbus-serialbattery
2024-07-08 16:55:39.840325500 INFO:SerialBattery:Venus OS v3.33
2024-07-08 16:55:39.843495500 INFO:SerialBattery:dbus-serialbattery v1.3.20240705

==> /data/log/dbus-blebattery.2/current <==
2024-07-08 16:55:39.873471500 INFO:SerialBattery:
2024-07-08 16:55:39.874267500 INFO:SerialBattery:Starting dbus-serialbattery
2024-07-08 16:55:39.875956500 INFO:SerialBattery:Venus OS v3.33
2024-07-08 16:55:39.876535500 INFO:SerialBattery:dbus-serialbattery v1.3.20240705

==> /data/log/dbus-blebattery.0/current <==
2024-07-08 16:55:57.073464500 INFO:SerialBattery:Init of Jkbms_Ble at C8:47:80:03:8A:2C
2024-07-08 16:55:57.074408500 INFO:SerialBattery:Test of Jkbms_Ble at C8:47:80:03:8A:2C

==> /data/log/dbus-blebattery.1/current <==
2024-07-08 16:55:57.110468500 INFO:SerialBattery:Init of Jkbms_Ble at C8:47:80:03:82:4A
2024-07-08 16:55:57.111283500 INFO:SerialBattery:Test of Jkbms_Ble at C8:47:80:03:82:4A

==> /data/log/dbus-blebattery.2/current <==
2024-07-08 16:55:57.057937500 INFO:SerialBattery:Init of Jkbms_Ble at C8:47:80:03:89:20
2024-07-08 16:55:57.058859500 INFO:SerialBattery:Test of Jkbms_Ble at C8:47:80:03:89:20

==> /data/log/dbus-blebattery.0/current <==
2024-07-08 16:56:03.668248500 INFO:SerialBattery:BAT: JKBMS 11.XW 16 cells (20240408)
2024-07-08 16:56:03.668254500 INFO:SerialBattery:Connection established to Jkbms_Ble

==> /data/log/dbus-blebattery.1/current <==
2024-07-08 16:56:03.697131500 INFO:SerialBattery:BAT: JKBMS 11.XW 16 cells (20240408)
2024-07-08 16:56:03.698739500 INFO:SerialBattery:Connection established to Jkbms_Ble

==> /data/log/dbus-blebattery.2/current <==
2024-07-08 16:56:03.632911500 INFO:SerialBattery:BAT: JKBMS 11.XW 16 cells (20240408)
2024-07-08 16:56:03.634127500 INFO:SerialBattery:Connection established to Jkbms_Ble

==> /data/log/dbus-blebattery.0/current <==
2024-07-08 16:56:06.670696500 INFO:SerialBattery:Found existing battery with DeviceInstance = 3

==> /data/log/dbus-blebattery.1/current <==
2024-07-08 16:56:06.736391500 INFO:SerialBattery:Found existing battery with DeviceInstance = 1

==> /data/log/dbus-blebattery.2/current <==
2024-07-08 16:56:06.718441500 INFO:SerialBattery:Found existing battery with DeviceInstance = 2

==> /data/log/dbus-blebattery.0/current <==
2024-07-08 16:56:07.166763500 INFO:SerialBattery:DeviceInstance = 3
2024-07-08 16:56:07.168158500 INFO:SerialBattery:PID file created successfully: /var/tmp/dbus-serialbattery_3.pid
2024-07-08 16:56:07.168654500 INFO:SerialBattery:Used DeviceInstances = ['2', '1', '3']
2024-07-08 16:56:07.169186500 INFO:SerialBattery:com.victronenergy.battery.ble_c84780038a2c
2024-07-08 16:56:07.170868500 INFO:SerialBattery:BAT: JKBMS 11.XW 16 cells (20240408)
2024-07-08 16:56:07.214254500 INFO:SerialBattery:publish config values = True
2024-07-08 16:56:07.257467500 INFO:SerialBattery:Battery Jkbms_Ble connected to dbus from ble_c84780038a2c
2024-07-08 16:56:07.258670500 INFO:SerialBattery:========== Settings ==========
2024-07-08 16:56:07.259580500 INFO:SerialBattery:> Connection voltage: 54.01 V | Current: -1.5 A | SoC: 100%
2024-07-08 16:56:07.260150500 INFO:SerialBattery:> Cell count: 16 | Cells populated: 32
2024-07-08 16:56:07.260803500 INFO:SerialBattery:> LINEAR LIMITATION ENABLE: True
2024-07-08 16:56:07.261369500 INFO:SerialBattery:> MIN CELL VOLTAGE: 3.000 V | MAX CELL VOLTAGE: 3.450 V| FLOAT CELL VOLTAGE: 3.350 V
2024-07-08 16:56:07.261899500 INFO:SerialBattery:> MAX BATTERY CHARGE CURRENT: 80.0 A | MAX BATTERY DISCHARGE CURRENT: 80.0 A
2024-07-08 16:56:07.262420500 INFO:SerialBattery:> MAX BATTERY CHARGE CURRENT: 130.0 A | MAX BATTERY DISCHARGE CURRENT: 130.0 A (read from BMS)
2024-07-08 16:56:07.262907500 INFO:SerialBattery:> CVCM:     True
2024-07-08 16:56:07.263464500 INFO:SerialBattery:> CCCM CV:  True  | DCCM CV:  True
2024-07-08 16:56:07.269426500 INFO:SerialBattery:> CCCM T:   True  | DCCM T:   True
2024-07-08 16:56:07.269434500 INFO:SerialBattery:> CCCM SOC: False | DCCM SOC: False
2024-07-08 16:56:07.271204500 INFO:SerialBattery:> CHARGE FET: True | DISCHARGE FET: True | BALANCE FET: True
2024-07-08 16:56:07.271493500 INFO:SerialBattery:Serial Number/Unique Identifier:<PHONE_NUMBER>

==> /data/log/dbus-blebattery.1/current <==
2024-07-08 16:56:07.198767500 INFO:SerialBattery:DeviceInstance = 1
2024-07-08 16:56:07.224017500 INFO:SerialBattery:PID file created successfully: /var/tmp/dbus-serialbattery_1.pid
2024-07-08 16:56:07.224951500 INFO:SerialBattery:Used DeviceInstances = ['2', '1', '3']
2024-07-08 16:56:07.226118500 INFO:SerialBattery:com.victronenergy.battery.ble_c8478003824a
2024-07-08 16:56:07.228548500 INFO:SerialBattery:BAT: JKBMS 11.XW 16 cells (20240408)
2024-07-08 16:56:07.267297500 INFO:SerialBattery:publish config values = True
2024-07-08 16:56:07.303810500 INFO:SerialBattery:Battery Jkbms_Ble connected to dbus from ble_c8478003824a
2024-07-08 16:56:07.304502500 INFO:SerialBattery:========== Settings ==========
2024-07-08 16:56:07.305202500 INFO:SerialBattery:> Connection voltage: 54.01 V | Current: -1.5 A | SoC: 100%
2024-07-08 16:56:07.306166500 INFO:SerialBattery:> Cell count: 16 | Cells populated: 32
2024-07-08 16:56:07.308085500 INFO:SerialBattery:> LINEAR LIMITATION ENABLE: True
2024-07-08 16:56:07.308915500 INFO:SerialBattery:> MIN CELL VOLTAGE: 3.000 V | MAX CELL VOLTAGE: 3.450 V| FLOAT CELL VOLTAGE: 3.350 V
2024-07-08 16:56:07.309498500 INFO:SerialBattery:> MAX BATTERY CHARGE CURRENT: 80.0 A | MAX BATTERY DISCHARGE CURRENT: 80.0 A
2024-07-08 16:56:07.312809500 INFO:SerialBattery:> MAX BATTERY CHARGE CURRENT: 130.0 A | MAX BATTERY DISCHARGE CURRENT: 130.0 A (read from BMS)
2024-07-08 16:56:07.313574500 INFO:SerialBattery:> CVCM:     True
2024-07-08 16:56:07.314246500 INFO:SerialBattery:> CCCM CV:  True  | DCCM CV:  True
2024-07-08 16:56:07.314916500 INFO:SerialBattery:> CCCM T:   True  | DCCM T:   True
2024-07-08 16:56:07.315503500 INFO:SerialBattery:> CCCM SOC: False | DCCM SOC: False
2024-07-08 16:56:07.316176500 INFO:SerialBattery:> CHARGE FET: True | DISCHARGE FET: True | BALANCE FET: True
2024-07-08 16:56:07.316689500 INFO:SerialBattery:Serial Number/Unique Identifier:<PHONE_NUMBER>

==> /data/log/dbus-blebattery.2/current <==
2024-07-08 16:56:07.157889500 INFO:SerialBattery:DeviceInstance = 2
2024-07-08 16:56:07.160688500 INFO:SerialBattery:PID file created successfully: /var/tmp/dbus-serialbattery_2.pid
2024-07-08 16:56:07.162338500 INFO:SerialBattery:Used DeviceInstances = ['2', '1', '3']
2024-07-08 16:56:07.163182500 INFO:SerialBattery:com.victronenergy.battery.ble_c84780038920
2024-07-08 16:56:07.164475500 INFO:SerialBattery:BAT: JKBMS 11.XW 16 cells (20240408)
2024-07-08 16:56:07.188155500 INFO:SerialBattery:publish config values = True
2024-07-08 16:56:07.233599500 INFO:SerialBattery:Battery Jkbms_Ble connected to dbus from ble_c84780038920
2024-07-08 16:56:07.234399500 INFO:SerialBattery:========== Settings ==========
2024-07-08 16:56:07.235163500 INFO:SerialBattery:> Connection voltage: 54.01 V | Current: -1.7 A | SoC: 100%
2024-07-08 16:56:07.235814500 INFO:SerialBattery:> Cell count: 16 | Cells populated: 32
2024-07-08 16:56:07.236448500 INFO:SerialBattery:> LINEAR LIMITATION ENABLE: True
2024-07-08 16:56:07.237133500 INFO:SerialBattery:> MIN CELL VOLTAGE: 3.000 V | MAX CELL VOLTAGE: 3.450 V| FLOAT CELL VOLTAGE: 3.350 V
2024-07-08 16:56:07.237859500 INFO:SerialBattery:> MAX BATTERY CHARGE CURRENT: 80.0 A | MAX BATTERY DISCHARGE CURRENT: 80.0 A
2024-07-08 16:56:07.238581500 INFO:SerialBattery:> MAX BATTERY CHARGE CURRENT: 130.0 A | MAX BATTERY DISCHARGE CURRENT: 130.0 A (read from BMS)
2024-07-08 16:56:07.239219500 INFO:SerialBattery:> CVCM:     True
2024-07-08 16:56:07.239871500 INFO:SerialBattery:> CCCM CV:  True  | DCCM CV:  True
2024-07-08 16:56:07.240560500 INFO:SerialBattery:> CCCM T:   True  | DCCM T:   True
2024-07-08 16:56:07.241161500 INFO:SerialBattery:> CCCM SOC: False | DCCM SOC: False
2024-07-08 16:56:07.241817500 INFO:SerialBattery:> CHARGE FET: True | DISCHARGE FET: True | BALANCE FET: True
2024-07-08 16:56:07.248243500 INFO:SerialBattery:Serial Number/Unique Identifier:<PHONE_NUMBER>

Any other information that may be helpful
No response

What I see in your log is:
2024-07-08 16:56:07.235814500 INFO:SerialBattery:> Cell count: 16 | Cells populated: 32

Cells populated: 32 is wrong. Can you check this on an old version, if you have that also? I have many systems with JKBMS, but none gives me that issue.
Please try also the latest nightly and enable GUI_PARAMETERS_SHOW_ADDITIONAL_INFO = True. The reinstall the driver, go to the parameters page and post the screenshots of the items below DCL.

Version v1.2.20240408 is currently running again and here too it says Cell count: 16 | Cells populated: 32
Now that the “old” version is running again, I have reinstalled the current v1.3.20240705.
very interesting, because now CVL is suddenly correct??
I changed several times before and it was always wrong. Maybe there was something else cached?
Tomorrow I'll test the behavior of the nightly build when the battery is full. CVL currently fits.....

Make sure to install the nightly, since it contains a fix in combination with GUI_PARAMETERS_SHOW_ADDITIONAL_INFO, else nothing other changed. See https://github.com/mr-manuel/venus-os_dbus-serialbattery/issues/48.

The nightly is now running with the fix, so far so good. No abnormalities so far. 👍
I'll test this for a few days...
First of all, thank you very much for the quick help =)

The nightly build has been running since yesterday evening in conjunction with GUI_PARAMETERS_SHOW_ADDITIONAL_INFO = True.
Unfortunately the bulk voltage is still much too high, 55.2V would be correct.

I have a guess... my battery was almost full when I updated serialbattery. Since then it hasn't seen the 80% trigger on bulk. Is it possible that the correct CVL value is written when the trigger threshold falls below 80% and the CVL value is only incorrect immediately after installation?

Could you try to change
https://github.com/Louisvdw/dbus-serialbattery/blob/fd0fc1a193427df6ca0fadd141aa57826f761819/etc/dbus-serialbattery/config.default.ini#L46
to 3.50, so we see, if the value is comming from there

Can you also write me on Discord? You find the link by clicking on my profile.

Today one of the three battery blocks went from float to bulk. Unfortunately, again the CVL is too high.
I set SOC_RESET_VOLTAGE = 3,500 in the config and rebooted. Unfortunately also without success.
I don't use Discord, I could offer email or WhatsApp.
Both public because YouTubers ^^

I would need access to your system, please send me your e-Mail, then I contact you.

<EMAIL_ADDRESS>

I deleted your comment for your privacy. I write you.

Did you get my e-Mail?

@.*** Am 10.07.24, 18:44 schrieb Manuel @.***>:
I would need access to your system, please send me your e-Mail, then I contact you.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

The bug was fixed with v1.4.20240712dev.


fix fix inaccurate compaction cnt

bug
Before this bug is fixed, when the rpc of commit compaction job and the rpc of sync tablet meta are parallel and out of order, the compaction cnt may be inaccurate.
for example
1 cumu_compaction_cnt = 10
2 meta service, commit compaction job rpc, cumu_compaction_cnt++
3 meta service, get tablet meta rpc, get cumu_compaction_cnt = 11
4 BE，get tablet meta rpc return，update tablet cumu_compaction_cnt = 11
5 BE，commit compaction job rpc return，update cumu_compaction_cnt = 12

run buildall


bad encapsulated packet length from peer

getting this error when trying to connect to server on tcp port 443
didn't found information online

If you are unable to troubleshoot the issue, at the very least paste the full log and explain if you tried to modify the MTU as the full log will likely suggest.
That said, this can be a sign of other issues, like a filtered network or if you are somehow proxying the traffic on that port (for example, to split for different services).
Go to the OpenVPN forums if you need further assistance.


Swapping appearance for opacity

Using appearance is broken on iOS/Safari - using opacity instead as it works.

Slate has been superseded by Clay.


Import Error

Traceback (most recent call last):
  File "main.py", line 10, in <module>
    from baselines.common.mpi_fork import mpi_fork
ImportError: No module named mpi_fork

How can I fix this problem? THX.

Install from source
Clone the repo, move into it and do pip install -e .

@Amathlog Thx, it works.
But I met another problem when running code when importing mpi_fork as following,
Traceback (most recent call last):
  File "main2.py", line 10, in <module>
    from baselines.common.mpi_fork import mpi_fork
  File "/home/jackie/code/baselines/baselines/common/__init__.py", line 2, in <module>
    from baselines.common.dataset import Dataset
  File "/home/jackie/code/baselines/baselines/common/dataset.py", line 50
    def iterbatches(arrays, *, num_batches=None, batch_size=None, shuffle=True, include_final_partial_batch=True):
                             ^
SyntaxError: invalid syntax

Is it a problem in source code? How can I fix it? THX

I've tried installing from source. Used Virtual env and tried using the same process on Mac and Ubuntu. Error occured only on Ubuntu. Using Python version 3.4.
Any other reason for the error?

Hi @VSNanditha! Could you post the full stacktrace of the error here? Thanks!

This trace is when I run train_cartpole from the sample experiments of deepq.
$ python train_cartpole.py
Traceback (most recent call last):
    File "train_cartpole.py", line 3, in <module>
        from baselines import deepq
ImportError: No module named 'baselines'

I think i need to make changes to init.py but I did the same steps in my Mac and it works fine without any changes to the init files.


What is the advantage over Faker

what is the benefit of using rantly over faker ?!

Having briefly looked at faker it seems better suited to generating random, human-readable values for higher-level concepts (e.g. names, companies, addresses). Rantly helps test application behavior using random data.
Rantly Capabilities

Generate data for core types (boolean, string, integer, float, array, hash, etc..). The generated values fits the domain of the type.

# Returns an Integer within the inclusive range [0, 10].
Rantly.value { range(0,10) }

Compose data generators for more complex types.

# Returns a dictionary with 10 entries. The keys are alphanumeric strings of length and the values are Integers within the inclusive range [0, 10].
Rantly.value {
  dict(10) {
    [
      sized(10) { string(:alpha) },
      range(0, 10)
    ]
  }
}

Extensions to ruby test frameworks (test/unit, minitest, rspec) for property testing. This allows you to test that a property, or behavior, of your application holds for randomly generated data.

# Property test to assert pagination correctly computes current page given start offset of collection, page_size, and total items in collection.
it 'when paging' do
  property_of {
    Rantly.value(1000) {
      start       = range(0, 10000)
      page_size   = range(1, 10000)
      total       = range(1, 10000)

      guard start <= total

      [start, page_size, total]
    }
  }.check(25000, 1000) { |start, page_size, total|
    pager = Pager.new(start, page_size, total)
    expect(pager.current_page).to eql ((start + page_size) / page_size.to_f).floor
  }
end

Hope that helps!

Thanks !! it does


Invalid Token should send 401, not 500

Version where bug was found:
current
Describe the bug
When auth-check is on, and invalid token will result in a 500 response. This should be a 401 with a message that says that the token was invalid.
To Reproduce
Steps to reproduce the behavior:

Turn auth check on
Send in a token that shouldn't work.
Observe the 500 response

Expected behavior
Any bad auth should give a general "not authorized" message with a 401.

QA: passed!