[Installation]: M2 Mac Dependency Torch 2.1.2 (Incompatible)

Your current environment
PyTorch version: 2.3.1
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A
OS: macOS 14.1.1 (arm64)
GCC version: Could not collect
Clang version: 15.0.0 (clang-15<IP_ADDRESS>)
CMake version: version 3.29.5
Libc version: N/A
Python version: 3.12.3 | packaged by Anaconda, Inc. | (main, May  6 2024, 14:46:42) [Clang 14.0.6 ] (64-bit runtime)
Python platform: macOS-14.1.1-arm64-arm-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True
CPU:
Apple M2 Max
Versions of relevant libraries:
[pip3] numpy==1.26.4
[pip3] torch==2.3.1
[pip3] transformers==4.41.2
[pip3] transformers==4.41.2
[conda] numpy                     1.26.4                   pypi_0    pypi
[conda] torch                     2.3.1                    pypi_0    pypi
[conda] transformers              4.41.2                   pypi_0    pypi
ROCM Version: Could not collect
Neuron SDK Version: N/A
vLLM Version: N/A
vLLM Build Flags:
CUDA Archs: Not Set; ROCm: Disabled; Neuron: Disabled
GPU Topology:
Could not collect
How you are installing vllm

git clone https://github.com/vllm-project/vllm.git
cd vllm
git fetch origin pull/2244/head:pr-2244
git checkout pr-2244

VLLM_TARGET_DEVICE=cpu python3 setup.py build
VLLM_TARGET_DEVICE=cpu python3 setup.py install
# Seems to give an error the first time.
# error: CUDA_HOME environment variable is not set. Please set it to your CUDA install root.

# I can't reproduce the error if I run it again. It does seem to run.
VLLM_TARGET_DEVICE=cpu python3 setup.py install

# note that the following error message occurs

ERROR: Could not find a version that satisfies the requirement torch==2.1.2 (from versions: 2.2.0, 2.2.1, 2.2.2, 2.3.0, 2.3.1)
ERROR: No matching distribution found for torch==2.1.2

# i have also found issues with installing triton so I have built it from source but similarly run into issues with "sentencepiece" requiring "ray" which requires "torch=2.1.2".

I am installing vLLM to install SGLang.

According to the logs, you currently have torch=2.3.1 installed. The latest version of vLLM (v0.5.0) requires torch==2.3.0, so you'll have to downgrade PyTorch to that version.

According to the logs, you currently have torch=2.3.1 installed. The latest version of vLLM (v0.5.0) requires torch==2.3.0, so you'll have to downgrade PyTorch to that version.
Edit: I see that you're trying to use vLLM at #2244 specifically. In that case you can check the required PyTorch version in pyproject.toml.

Thank you for this suggestion. I have downgraded my python version to 3.9 and am working on the installation again currently. I will see if any other issues pop up.

Following the downgrade I have encountered a new issue regarding packaging. Is this a problem with my environment?
Traceback (most recent call last):
File "/Users/velocity/Documents/Holder/Business/Saleri.ai/vllm/setup.py", line 12, in
from packaging.version import parse, Version
ModuleNotFoundError: No module named 'packaging'

Try downgrading setuptools to setuptools<70.

Running setuptools 69.0.3 within my conda environment now. Unfortunately, same error.

Try updating your pip version
python -m pip install --upgrade pip

Try updating your pip version
python -m pip install --upgrade pip

Im running the latest pip version, 24.0. What is odd is that this was not an issue prior to downgrading python

Try updating your pip version
python -m pip install --upgrade pip

Im running the latest pip version, 24.0. What is odd is that this was not an issue prior to downgrading python

Downgrading to etuptools==69.5.1 specifically solved this issue

Odd that you had to use this specific version. In any case, glad that it has been solved.


No in-game config

I'm running MC 1.14.4, Forge 28.1.26, and BiomeInfo 1.2.4, and there doesn't seem to be any in-game config available despite the CurseForge page saying there should be. The mods menu config button is grayed out, and nothing seems to have been added to my normal options menu.

Forge for 1.14 does not have a configuration GUI yet. I cannot do anything about this.

I'm also using HWYLA and it has a config menu in the mods menu, is that what you're referring to? Either way, thanks!

Yes, there are ways around Forge's restriction and it is possible to have a working configuration GUI in the mod list menu, but I'd rather wait for them to implement it properly.

Understood, I was just curious. Thanks again!


AP Token

Token Address
https://scan.testnet.tomochain.com/tokens/0x131182311876f423c3710da0add6d58eec4df848
Token Symbol
APT
Token Name
AP Token
Token Logo

Token Description
Become a millionaire for everyone
Website
Under construction
Social links
https://twitter.com/Airdropplatinum
https://t.me/airdropsplatinum_official
https://t.me/airdropsplatinum_channel

it is testnet version?


Build and host docker images of the tutorials

Description
Beginners to MoveIt that are familiar with Docker may prefer to use a pre-built image rather than set up a workspace, install ROS, MoveIt, and their dependencies as well as completing the steps of the tutorial.
This PR will build and host images on the GHCR such that a user can pull the image and skip all the tutorial instructions other than the ros2 launch commands.
How to test
The documentation has been updated to include instructions, but they can be summarized as follows:
wget https://raw.githubusercontent.com/ros-planning/moveit2_tutorials/main/.docker/docker-compose.yml
OR (since the images are not available on the ros-planning ghcr yet):
wget https://raw.githubusercontent.com/mikewrock/moveit2_tutorials/PR-prep/.docker/docker-compose.yml
DOCKER_IMAGE=rolling-tutorial docker compose run --rm --name moveit2_container gpu
Test Planning Around Objects:
ros2 launch moveit2_tutorials demo.launch.py rviz_config:=panda_hello_moveit.rviz &
ros2 run hello_moveit hello_moveit
Test Pick and Place with MoveIt Task Constructor:
ros2 launch moveit2_tutorials mtc_demo.launch.py &
ros2 launch mtc_tutorial pick_place_demo.launch.py
(alternatively you can open a second terminal and use docker exec -it moveit2_container bash, source /opt/ros/rolling/setup.bash, source install/setup.bash, and ros2 launch mtc_tutorial pick_place_demo.launch.py)
Checklist

[ ] Required by CI: Code is auto formatted using clang-format
[ ] While waiting for someone to review your request, please consider reviewing another open pull request to support the maintainers

@sea-bass Thanks for the review, really helpful feedback. A few responses here:

As someone without a GPU, it look me a little while to find that there was a CPU instruction.

I added a bit more to the docker-compose example, but I'm mainly hoping people will see the line in the docker guide

More importantly, I ran into the race condition at startup with the robot's state which is solved by installing and using Cyclone DDS.

Why is it that I constantly see this being a solution to so many difficult to diagnose problems? What indicators did you see that helped you identify the race condition?

Also, I'm generally wary about recommending people run multiple commands in one terminal with the & character as it makes it really hard to kill lingering processes

I completely agree and wrote that for ease of use for the reviewers, but its probably best not to mention it and leave that usage to someone who's comfortable with it

Finally, why is it that docker exec -it moveit2_container bash requires sourcing stuff? Is this not part of the entrypoint, or does that only happen with docker run?

Thank you for asking this, I've always just accepted it as a minor inconvenience but it doesn't need to be. The entrypoint only gets executed during docker run, but I added some source commands to the bashrc so that entering the container using -it will automatically source the opt and install setup.bash as well as set RMW implementation to Cyclone DDS

Why is it that I constantly see this being a solution to so many difficult to diagnose problems? What indicators did you see that helped you identify the race condition?

Fun, isn't it? The indicator was the Panda showing in RViz as starting "upright" in the zero configuration rather than at its home position.


Support changes to the Checks REST API

This PR updates CheckService and CheckSuiteAnnotation to account for the recent changes to the GitHub API:

filename is being renamed to path
blob_href is no longer necessary (no changes required, as responses continue to provide this value)
warning_level is being renamed to annotation_level
POST /repos/:owner/:repo/check-suite-requests is being removed
POST /repos/:owner/:repo/check-suites/:check_suite_id/rerequest is being added

Fixes https://github.com/google/go-github/issues/980

Thanks for the review, @gmlewis! I've pushed up changes that I believe address your comments.

Thank you, @gauntface!
Merging.


[Question] How do I get the request object in the context function?

I want to add things like the current user and the user's language to the context by grabbing some values from the HTTP request headers. But when I set a context function (using $serverConfig->setContext(function() { ... })), that function only receives instances of OperationParams, DocumentNode and the operation type, but nothing that gives me access to the current ServerRequestInterface object.
I took a look at how this is done in apollo, and it passes an object containing the request to the context function.

You don't need to make it a callable.
You can set it to anything (a class/object) on your own, initialized with whatever you need, having access to whatever you need.
Somewhere in your app / controller / etc. you call \GraphQL\GraphQL::executeQuery and as the 4th arg you simply pass whatever you will need.

Thank you for the quick response.
So there is no way to do it using the StandardServer?

We are in a bit different position than Apollo because the StandardServer supports two kinds of requests - PHP Globals and PSR-7 request. I guess the best thing you could do at the moment is to pass the $request separately into context closure (via  use ($request)).
In one of the future versions, we will deprecate PHP globals support and stick with PSR-7 to make it consistent.


Data Privacy/ storage question

Does the report analyzer store the analysis logs ?
Are the analysis logs / company data visible to the vendor?

@m-kovalsky Could you please assist


[Enhancement] Proposal for organization of iroha repositories

Introduction
Iroha is big project. It contains of the following modules:

irohad - main binary for Iroha daemon
iroha-cli - command line interface for peer operator and client
shared_model - C++ library, which is used by irohad, iroha-cli and potentially many other modules.
python client lib - autogenerated by swig
java client lib- autogenerated by swig
c# client lib - autogenerated by swig.

Potentially we may have lots of other modules, like client lib for iOS, Haskell or Rust.
Currently all modules reside inside main hyperledger/iroha repository.
Problem
We need to maintain every module:

must be versioned with semver
must have CI
good to have bug tracker
language-specific client libraries must be posted to library repositories (java - maven, python - pip, etc). Every lib must be versioned with semver.

Solution
Here I will describe steps we need to do, to make good development process for all modules:

[x] 1. Define list of modules, their names and dependencies between them
[ ] 2. Assign maintainer for every module. Clarify responsibilities.
[ ] 3. For shared_model:
1. rename to libiroha to be consistent with naming of UNIX libs
2. extract it to separate repository hyperledger/libiroha
3. remove dependencies on irohad / libs
4. fully move libs to libiroha
[ ] 4. For client libraries:
1. clear (?) the legacy code in existing repositories (hyperledger/iroha-ios, hyperledger/iroha-javascript and so on)
2. for libs where we generate bindings (C#, Python, Java):
1. generate them once
2. create branches as in git flow: tagged versions, master = latest stable code, develop = latest code
3. declare version 1.0.0
4. push with this version to according library repository (mvn, pip).
5. setup CI
6. write tests and documentation
[ ] 5. For irohad create separate repository hyperledger/irohad, put irohad code there, add libiroha as dependency
[ ] 6. For iroha-cli:
1. rename to iroha - to be consistent with naming, as in Docker (docker + dockerd)
2. use hyperledger/iroha for cli only.
3. it will be "official" and "maintainable" CLI. Since iroha is an opensource project, people may create other CLIs, using even other programming languages.
[ ] 7. for libs: remove this folder and move contents to libiroha
[x] 8. Eventually merge warchant/ed25519 to hyperledger/libiroha.

This will help to make code segregation (changes in one module does not affect other), better management, creates separate issue tracker for every module (github issues), separate versioning.
Dependency graph:
client[hyperledger/iroha-*language] --> |if binding| libiroha
client[hyperledger/iroha-*language] --> |if native|  ed25519
libiroha[hyperledger/libiroha]      --> ed25519[warchant/ed25519]
iroha[hyperledger/iroha]            --> libiroha
irohad[hyperledger/irohad]          --> libiroha

Vote with :+1: or :-1: for this proposal. If you voted :-1: please, comment why.

We have decided to extract shared_model classes to a separate repository and eventually to store client libraries that depend on it and are stored in a separate repository for simplification of CI pipeline. Also, we have decided to rename shared_model to libiroha for better consistency with UNIX naming style

In the future, I hope that iroha-cli is going to be rewritten and not dependent on iroha repo

Issue seems pretty stale and it's pretty well-known, but the fixes are not coming soon probably


Evaluate and remove unit tests that are no longer needed

Due to the change of how modals are handled, some unit tests are no longer needed or need editing. Mainly the rendered as closed tests.

In general, when I wrote snapshot tests, I did a quick boolean count of all possible prop values and tried to make a snapshot for each.
This isn't really helpful for most, and we should focus on snapshots with meaningful data given as props.

The other issue is that we had tests for modals rendering closed, but now they're removed from the dom if they're closed so they don't render and that results in the tests automatically attempting to rewrite the snapshots everytime.

Also need to adjust mocks / stubs


assume-no-moving-gc warning on simple example

With this example https://github.com/diamondburned/gotk4-examples/blob/master/gtk4/simple/main.go I get the following error:

panic: Something in this program imports go4.org/unsafe/assume-no-moving-gc to declare that it assumes a non-moving garbage collector, but your version of go4.org/unsafe/assume-no-moving-gc hasn't been updated to assert that it's safe against the go1.21 runtime. If you want to risk it, run with environment variable ASSUME_NO_MOVING_GC_UNSAFE_RISK_IT_WITH="go1.21" set. Notably, if go1.21 adds a moving garbage collector, this program is unsafe to use.

How do I try out gotk4 without "risking it"?

Sorry, a version bump of this dependency in gotk4-examples is probably needed.

How do I do that? Sorry I'm also new to Go. It looks like the dependencies are just github links to the main gotk repo
https://github.com/diamondburned/gotk4-examples/blob/2b6b92a2057fa1021fd979e60ff0bd14937d8c6a/gtk4/simple/main.go#L6-L7

All good, I can update it. It's just running go get go4.org/unsafe/assume-no-moving-gc@latest.


bazel run //tools:generate_reserved_tokens

Stack:

#194
#193 ⬅

⚠ Part of a stack created by spr. Do not merge manually using the UI - doing so may have unexpected results.


[Relayer] refactor: simplify RelayerSessionsManager

Summary
Human Summary
(See the AI summary, it's actually decent)
AI Summary

Summary generated by Reviewpad on 09 Nov 23 15:50 UTC
This pull request introduces three changes.
The first patch adds a new observable operator called MapExpand to the pkg/observable/channel/map.go file. This operator takes an input observable and applies a transform function to each notification received from the observable. The transform function returns a slice of output notifications for each input notification.
The second patch refactors the RelayerSessionsManager struct in the pkg/relayer/session/session.go file to make it more reactive. It replaces the goListenToCommittedBlocks method with the mapBlocksToSessionsToClaim method, which is used as the transform function in the MapExpand operator.
The third patch adds a godoc comment to the MapExpand function in the pkg/observable/channel/map.go file, explaining its purpose and usage.
Overall, these changes enhance the functionality and readability of the code.

Issue

#{ISSUE_NUMBER}

[Explain the reasoning for the PR in 1-2 sentences. Consider adding a link or a screenshot.]
Type of change
Select one or more:

[ ] New feature, functionality or library
[ ] Bug fix
[x] Code health or cleanup
[ ] Documentation
[ ] Other (specify)

Testing

[ ] Run all unit tests: make go_develop_and_test
[ ] Verify Localnet manually: See the instructions [here](TODO: add link to instructions)

Sanity Checklist

[ ] I have tested my changes using the available tooling
[x] I have performed a self-review of my own code
[x] I have commented my code, updated documentation and left TODOs throughout the codebase

(See the AI summary, it's actually decent)

😆


Add gallery plot for radial average power spectrum

We need a gallery plot for the code implemented in #303. Can use the new Hawaii gravity data from #355.

@santis19 would you like to take a shot at this?

Hi @leouieda. I can get this done by next week if that's ok for you.

There's no hurry, whenever you can do this is fine. It's all volunteer time :smile:


Dynamic Commitment Fees

Currently there's a hard-coded fee of 5k satoshis on the commitment transaction. This sufficed for initial tests but needs to be made dynamic for real-world use in order to maintain the invariant that the current commitment transaction is able to be included in the next block.
In the Lighting Summit, we agreed that for now the initiator pays all fees on the commitment transaction. Therefore any additional fees due to added HTLC's should be subtracted from the initiator's balance if necessary. Additionally messages need to be added to the wire protocol to allow the initiator to signal that they wish to change their desired fee rate on the commitment transaction.
This section within the v1 specification is still being fleshed out. As the specification becomes more concrete, this issue will be updated to detail the requirements as laid out by the spec.
A related issue if the lack of any dynamic fee estimation in lnd currently. In order to robustly implement dynamic commitment fees, we'll also need an internal model which predicts the fee required to make it into the Nth block.
type FeeEstimator interface {
    // EstimateFee takes in a target for the number of blocks
    // until an initial confirmation and returns the estimated fee
    // expressed in satoshis/byte.
    EstimateFee(numBlocks uint32) uint64

    EstimateConfirmation(satPerByte int64) uint32
}

As a placeholder, the above interface can be created with a concrete implementation which simply returns our current hard-coded fee "5000 satoshis". This will allow for a two-step migration, with the first step being simply a move-only refactoring.
See these relevant areas within the spec:

https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#fees
https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#updating-fees-update_fee

Relevant btcd PR:

https://github.com/btcsuite/btcd/pull/735

will take this one

Closed by #199!!!
Still a few more edge cases to be handled (incorporation of fee_update messages, and corner cases related to zero valued outputs, but can handled later).


fix: turn off selection mode if search result become empty

Details

Fixed Issues

$ https://github.com/Expensify/App/issues/46374
PROPOSAL: https://github.com/Expensify/App/issues/46374#issuecomment-2254886628
Tests

Prerequesite: There is only one unpaid expense and no other expeneses in the account

Launch New Expensify app
Go to Search
Long press on the expense
Tap Select
Tap on the dropdown
Tap Delete
Delete the expense

Verify that: The select mode will exit because there is no more expense

[x] Verify that no errors appear in the JS console

Offline tests

QA Steps

Prerequesite: There is only one unpaid expense and no other expeneses in the account

Launch New Expensify app
Go to Search
Long press on the expense
Tap Select
Tap on the dropdown
Tap Delete
Delete the expense

Verify that: The select mode will exit because there is no more expense

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

https://github.com/user-attachments/assets/f9596a32-04b9-4a23-be17-d0a5f5f26825

Android: mWeb Chrome

https://github.com/user-attachments/assets/8d579a37-eda8-42f7-9c9d-d86df6599edf

iOS: Native

https://github.com/user-attachments/assets/58572859-97fd-40ae-9df2-01c330596cc3

iOS: mWeb Safari

https://github.com/user-attachments/assets/167ae216-c439-4b57-80c4-992957ac25ee

MacOS: Chrome / Safari

https://github.com/user-attachments/assets/fa1aee6d-a43a-45b9-9bc5-b2f2d330e582

MacOS: Desktop

https://github.com/user-attachments/assets/a996d0df-6249-4558-bc7b-3093f9f4cbad

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/NikkiWines in version: 9.0.18-0 🚀

platform
result

🤖 android 🤖
failure ❌

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/mountiny in version: 9.0.18-10 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Language tutorial "Writing a Template" is confusing sometimes

This whole section talks about pklTutorialPart3.pkl which had not been defined up to that point. Additionally, it's talking about types and classes and then shows an example of amending that has no classes (TutorialPart.pkl and pklTutorialPart3.pkl).
It goes on to say:
This now behaves exactly like our pklTutorialPart3: TutorialPart = (pklTutorialPart1) {… before. pklTutorialPart3 is now defined as the value we get by amending tutorialPart and giving it a name and a part

Ok, it behaves exactly like that so then what's the point of using a class (I know the point, I don't understand why the tutorial is going down this path).

Thanks for the feedback! We'll look to improve the tutorial. But, also, feel free to submit a pull request with changes that you think would be more helpful.


strange file-specific 3D rendering (but works in fiji/clearvolume/spimagine)

🐛❓  Buguestion
This may or may not be a napari bug... but it's very strange, and it seems limited to napari.  I have an image (download here) that gives me messed up visuals in napari's 3D rendering, the gif below pretty much sums it up, but here are the bullet points:

looks/behaves fine in 2D
in 3D, shows something that almost looks like a GL-type indexing error (see gif), I tried forcing np.ascontiguousarray, and other things, but nothing worked.
strangely, if you roll the axes to ZX or YZ, it looks fine in both 2D and 3D.
it renders fine in spimagine and clearvolume
if you roll the axes enough while in 3D view, you eventually get a segmentation fault.
i have tried opening and resaving multiple different ways, but it still looks weird in napari XY 3D volume view.

this is obviously very low priority... but it is mysterious and may indicate an issue perhaps with our volume layer with certain data? (but of course could just be something about this image that doesn't seem to affect any other program?).  If anyone loads the file and has any thoughts, would be very curious to hear them!
FWIW, the image was processed with pycudadecon (my wrapper on the janelia cuda deconvolution library)

@tlambert03 do you think this might be related to #576?

@sofroniewn that was my thought as well.

oh, yep it's exactly the same.  Sorry I never downloaded @VolkerH's dataset and looked at the bug myself there, but I just did (side note: @VolkerH, that's a really fun image).  It's definitely the same thing, complete with the roll observation (works fine if you roll axes) and segfault from above.  I will close this comment, catch up on the discussion in #576 and try some of the debugging mentioned there.


a way to verify body sha256 of small files on SplitStreamReader

We currently read the container config JSON without any sort of validation of the content.  We can know the fsverity hash of the stream from when we create it, but assuming we don't make note of that, then when we go to open the config via its sha256 ID, we perform no checking at all.
We could fix this by adding an optional sha256 verification layer to the reader similar to the one we have in the writer.  We could also read the entire (small) json document into a vec and checksum it there.  We could also try to think about a reasonable way to make use of fsverity, but this seems to cut a little bit against how containers work today...
Solving this is important to the "mount verified container rootfs" goal.

This kinda-sorta got slightly addressed in 9c5fde531676bdb6f72d753b5a86dad012c17d78 with Repository::check_stream() and oci::open_config().  It's not part of the reader API, but it's a start.

I'm reusing this issue that's about splitstream to ask something tangentially related but much bigger picture.
I don't quite understand the "centrality" of splitstream for this project. I think what we should have as the "root" is composefs metadata blobs that we both read and write. In particular, the compose_filesystem function I think should be parsing composefs-info dump, not splitstreams.
In an ideal world, we have "canonical tar" and for "verified OCI images" then there is no splitstream - we can reliably reproduce a canonical tar from a composefs.

(The reason I bring this up is I was just replying something similar in https://github.com/containers/storage/pull/2155#discussion_r1831332889 )

We talked about this before, but got caught up on two issues:

we don't live in a world where all of the existing container engine implementations have produced canonical tar files, and we need to continue to support those images, including being able to re-push them.  We need something like tar-split, but with the data chunks stored in the composefs object storage.  That's essentially what splitstream is — it was designed for precisely this purpose.
when creating the composefs-per-layer there was the question of how we should handle whiteouts:

do we leave them as is and write a literal .wh. file to the composefs; or
do we do the thing that overlayfs would expect and convert .wh. files to 0:0 chardevs and .wh..wh.opq into the opaque directory xattr?

we don't live in a world where all of the existing container engine implementations have produced canonical tar files, and we need to continue to support those images, including being able to re-push them.

Yes, I agree. However, I think where we disagree is on whether it should be the canonical on-disk form for an OCI layer (or equivalent) or whether it should be an optional lookaside only consulted if the use case needs to reassemble the original tar/cpio/whatever.
In particular, for "verified OCI" I think we do want to put the canonical composefs digest of each layer in the manifest as annotations.
Under our working assumption that the manifest or configuration can be verified externally (e.g. via well known signature mechanisms) and if we represent OCI layers (or RPMs, whatever) as individual composefs on disk, then we have the ability to check the fsverity digest of those layers in addition to the final merged trees.
Of course we could try to put the splitstream digest into OCI and sign that, but that's making it load bearing for security. Don't get me wrong, I think splitstream is a nicely designed format - but I think the technological heart of what we do should be composefs.

when creating the composefs-per-layer there was the question of how we should handle whiteouts: do we leave them as is and write a literal .wh. file to the composefs; or

We have a choice, but this is what I think we should do - the composefs should represent the tar stream.

Splitstream is not currently directly involved in the security aspects of anything that we might do with a composefs container, but:
A lot of the repository APIs take an optional fs-verity digest parameter.  If this is known then we take this to be the verity digest of the splitstream object in question.  If we know this then we trust the references that are inside of that splitstream, which lets us recursively open the streams it refers to (ie: config refers to layers, layers refer to content files) without further checking.  If we don't do this then we are forced to check everything for on-disk consistency to ensure that nothing got corrupted.  This is done as a manual scan (the above-mentioned Repository::check_stream()).
This is all only relevant when performing transformation operations on the image, such as when "sealing", ie: creating the composefs for the first time for a new container image.  In this case we absolutely do need to verify that the layers actually contain the sha256 data that they say they do in order to avoid a situation where they were corrupted or tampered on disk.  If we have the fs-verity digest of the splitstream of the container config then we don't need to do that checking because we effectively already did (when doing the original pull).
We also have the option to play fast and loose with the data involved during the "create image" stage, assuming that our builders are immune to these kinds of issues, and only defend against tampering/corruption once on end user machines, but since we have this powerful data integrity technique at our disposal, why not use it in both places?

This is all only relevant when performing transformation operations on the image, such as when "sealing", ie: creating the composefs for the first time for a new container image. In this case we absolutely do need to verify that the layers actually contain the sha256 data that they say they do in order to avoid a situation where they were corrupted or tampered on disk.

Yes that's a fair point. However I would also say that sealing is basically a form of "push" which is certainly a feature we need in the general case, but I would still consider optional - for an "appliance system" it's not going to re-push its containers, so we don't need splitstream there. The client system should just be reading verified composefs.

A lot of the repository APIs take an optional fs-verity digest parameter. If this is known then we take this to be the verity digest of the splitstream object in question.

Yes but that's my point - how is it known? I don't see how it's "known" unless it's rooted in something we agree is a signing or verification target.
I would like to investigate having something like a "splitstream-from-composefs" that is just the delta from a composefs. For example I bet in many cases that splitstream could literally be just a single byte per entry that says "create a ustar or gnu formatted entry from the metadata we find in composefs". Or really even in many cases that'd just be "the input tar was ustar" hopefully. And in the limit of course with canonical tar, the splitstream is empty. (Again though I think we're agreed that we can't rely on canonical tar, but it's something to aspire to)

Yes but that's my point - how is it known? I don't see how it's "known" unless it's rooted in something we agree is a signing or verification target.

It is known in exactly one case: if you saved it from a previous operation (like a pull, or a previous container-mutation operation).  This is really only useful to the local user.
We might talk about adding it as an extra form of digest in the manifests or something but this feels very premature.  I'd definitely be against doing that right now.

It is known in exactly one case: if you saved it from a previous operation (like a pull, or a previous container-mutation operation). This is really only useful to the local user.

Yes, we can have local state that at one point we proved that a given tar-sha256 ("diffid") was equivalent to a given splitstream with a specific fsverity digest. I don't have any problem with that inherently.

We might talk about adding it as an extra form of digest in the manifests or something but this feels very premature. I'd definitely be against doing that right now.

I am talking about adding the composefs digests (not splitstream) in manifests which you are carefully not replying to 😉  But it's OK for now, we can just think about this issue and don't need to take any immediate action.
In the immediate short term I'd like actually to pick back up the https://github.com/containers/composefs/issues/294 issue and get a "spec" that just targets what we agreed on in "composefs as label in config for final merged tree" and documenting our reference implementation.  We can leave standardizations of the layer digests to an updated draft later.


MKL-DNN Convolution result is unstable with C API

Description
After issue https://github.com/apache/incubator-mxnet/issues/16143 was fixed, further testing revealed that the numerical result of the same example is unstable: evaluating the op multiple times can give different results.
Environment info (Required)
----------Python Info----------
Version      : 3.7.2
Compiler     : GCC 7.3.0
Build        : ('default', 'Dec 29 2018 06:19:36')
Arch         : ('64bit', '')
------------Pip Info-----------
Version      : 19.0.1
Directory    : /opt/Anaconda/lib/python3.7/site-packages/pip
----------MXNet Info-----------
Version      : 1.5.0
Directory    : /home/matteo/Git/mxnet/python/mxnet
Commit hash file "/home/matteo/Git/mxnet/python/mxnet/COMMIT_HASH" not found. Not installed from pre-built package or built from source.
Library      : ['/home/matteo/Git/mxnet/python/mxnet/../../lib/libmxnet.so']
Build features:
✖ CUDA
✖ CUDNN
✖ NCCL
✖ CUDA_RTC
✖ TENSORRT
✔ CPU_SSE
✔ CPU_SSE2
✔ CPU_SSE3
✔ CPU_SSE4_1
✔ CPU_SSE4_2
✖ CPU_SSE4A
✔ CPU_AVX
✖ CPU_AVX2
✖ OPENMP
✖ SSE
✔ F16C
✔ JEMALLOC
✖ BLAS_OPEN
✔ BLAS_ATLAS
✖ BLAS_MKL
✖ BLAS_APPLE
✖ LAPACK
✔ MKLDNN
✖ OPENCV
✖ CAFFE
✖ PROFILER
✖ DIST_KVSTORE
✖ CXX14
✖ INT64_TENSOR_SIZE
✖ SIGNAL_HANDLER
✖ DEBUG
----------System Info----------
Platform     : Linux-4.15.0-55-generic-x86_64-with-debian-buster-sid
system       : Linux
node         : mongolius
release      : 4.15.0-55-generic
version      : #60-Ubuntu SMP Tue Jul 2 18:22:20 UTC 2019
----------Hardware Info----------
machine      : x86_64
processor    : x86_64
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              8
On-line CPU(s) list: 0-7
Thread(s) per core:  2
Core(s) per socket:  4
Socket(s):           1
NUMA node(s):        1
Vendor ID:           GenuineIntel
CPU family:          6
Model:               94
Model name:          Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz
Stepping:            3
CPU MHz:             2700.253
CPU max MHz:         3500,0000
CPU min MHz:         800,0000
BogoMIPS:            5184.00
Virtualization:      VT-x
L1d cache:           32K
L1i cache:           32K
L2 cache:            256K
L3 cache:            6144K
NUMA node0 CPU(s):   0-7
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d
----------Network Test----------
Setting timeout: 10
Timing for MXNet: https://github.com/apache/incubator-mxnet, DNS: 0.0117 sec, LOAD: 0.8935 sec.
Timing for Gluon Tutorial(en): http://gluon.mxnet.io, DNS: 0.0599 sec, LOAD: 2.1901 sec.
Timing for Gluon Tutorial(cn): https://zh.gluon.ai, DNS: 0.1028 sec, LOAD: 0.9832 sec.
Timing for FashionMNIST: https://apache-mxnet.s3-accelerate.dualstack.amazonaws.com/gluon/dataset/fashion-mnist/train-labels-idx1-ubyte.gz, DNS: 0.0657 sec, LOAD: 1.2597 sec.
Timing for PYPI: https://pypi.python.org/pypi/pip, DNS: 0.0380 sec, LOAD: 0.8543 sec.
Timing for Conda: https://repo.continuum.io/pkgs/free/, DNS: 0.0395 sec, LOAD: 0.4625 sec.

Build info (Required if built from source)
Compiler: gcc
MXNet commit hash: c5007ea01ad1b88e43cc669385a4a76b7020ce94
Build config: plain config.mk except USE_OPENCV = 0
Minimum reproducible example
#include <stdio.h>
#include <stdlib.h>

#include "mxnet/c_api.h"
#include "nnvm/c_api.h"

#define checkedMXCall(func, ...)                              \
  {                                                           \
    if (func(__VA_ARGS__) != 0) {                             \
      printf("MX call %s failed at line %d:\n%s",             \
            #func, __LINE__, MXGetLastError());               \
      exit(1)               ;                                 \
    }                                                         \
  }
#define N_TRIES 10

void NDArraySet(NDArrayHandle arr, mx_float val){
  mx_uint rank;
  const mx_uint *shape;
  checkedMXCall(MXNDArrayGetShape, arr, &rank, &shape);
  int n_elements = 1;
  int i = 0;
  for(i = 0; i < rank; i++) n_elements *= shape[i];

  void *data;
  checkedMXCall(MXNDArrayWaitToRead, arr);
  checkedMXCall(MXNDArrayGetData, arr, &data);

  mx_float *data_float = (mx_float*) data;
  for(i = 0; i < n_elements; i++) data_float[i] = val;
}

void NDArrayCopy(NDArrayHandle arr, mx_uint n_elements, mx_float* copy){
  void *data;
  checkedMXCall(MXNDArrayWaitToRead, arr);
  checkedMXCall(MXNDArrayGetData, arr, &data);

  int i;
  mx_float *data_float = (mx_float*) data;
  for(i = 0; i < n_elements; i++) copy[i] = data_float[i];

  // printf("\n---- Copy Outcome:\n");
  // for(i = 0; i < 8; i++) printf("%f %f\n", copy[i], data_float[i]);
}

int main() {
  int i, j; // for loops

  /* Create symbol variables */
  SymbolHandle in_sym;
  SymbolHandle w_sym;
  SymbolHandle b_sym;
  checkedMXCall(MXSymbolCreateVariable, "in", &in_sym);
  checkedMXCall(MXSymbolCreateVariable, "w", &w_sym);
  checkedMXCall(MXSymbolCreateVariable, "b", &b_sym);

  /* Create convolution op */
  OpHandle op;
  NNGetOpHandle("Convolution", &op);
  SymbolHandle sym;
  const char *keys1[2] = {"kernel", "num_filter"};
  const char *vals[2] = {"(1,1)", "40"};
  checkedMXCall(MXSymbolCreateAtomicSymbol, op, 2, keys1, vals, &sym);

  /* Compose op and variables */
  const char **keys2 = NULL;
  SymbolHandle vars[3] = {in_sym, w_sym, b_sym};

  checkedMXCall(MXSymbolCompose, sym, "Conv", 3, keys2, vars);

  /* Create NDArrays for arguments */
  int dev_type = 1;
  int dev_id = 0;

  mx_uint in_shape[4] = {1, 3, 10, 10};
  NDArrayHandle in_arg_arr;
  checkedMXCall(MXNDArrayCreateEx, in_shape, 4, dev_type, dev_id, 0, 0, &in_arg_arr);
  mx_uint w_shape[4] = {40, 3, 1, 1};
  NDArrayHandle w_arg_arr;
  checkedMXCall(MXNDArrayCreateEx, w_shape, 4, dev_type, dev_id, 0, 0, &w_arg_arr);
  mx_uint b_shape[1] = {40};
  NDArrayHandle b_arg_arr;
  checkedMXCall(MXNDArrayCreateEx, b_shape, 1, dev_type, dev_id, 0, 0, &b_arg_arr);

  /* Set NDArrays */
  NDArraySet(in_arg_arr, 1.);
  NDArraySet(w_arg_arr, 1.);
  NDArraySet(b_arg_arr, 1.);

  /* Create and bind executor */
  ExecutorHandle ex;
  NDArrayHandle arg[3] = {in_arg_arr, w_arg_arr, b_arg_arr};
  NDArrayHandle grad[3] = {NULL, NULL, NULL};
  NDArrayHandle *aux = NULL;
  mx_uint req[3] = {1, 1, 1};
  checkedMXCall(MXExecutorBind, sym, dev_type, dev_id, 3, arg, grad, req, 0, aux, &ex);

  /* Get executor output handle */
  mx_uint out_size;
  NDArrayHandle *out_arr_p;
  checkedMXCall(MXExecutorOutputs, ex, &out_size, &out_arr_p);
  NDArrayHandle out_arr = *out_arr_p;

  /* Get output shape */
  mx_uint out_rank;
  const mx_uint *out_shape;
  checkedMXCall(MXNDArrayGetShape, out_arr, &out_rank, &out_shape);
  int n_elements = 1;
  for(i = 0; i < out_rank; i++) n_elements *= out_shape[i];

  /* Forward */
/*  checkedMXCall(MXExecutorForward, ex, 0);*/

  /* Copy output */
/*  mx_float *res1 = (mx_float *) malloc(sizeof(mx_float) * n_elements);
  NDArrayCopy(out_arr, n_elements, res1);*/

  mx_float *outputs[N_TRIES];
  for(i = 0; i < N_TRIES; i++){
    checkedMXCall(MXExecutorForward, ex, 0);
    outputs[i] = (mx_float *) malloc(sizeof(mx_float) * n_elements);
    NDArrayCopy(out_arr, n_elements, outputs[i]);
  }

  mx_float temp;
  mx_float max = 0;
  for(i = 0; i < N_TRIES - 1; i++){
    for(j = 0; j < n_elements; j++){
      temp = outputs[0][j] - outputs[i][j];
      if(temp < 0) temp = (-1)*temp;
      if(temp > max) max = temp;
    }
  }

  printf("%f\n", max);
  return 0;
}

Steps to reproduce
The above program evaluates the same convolution op in https://github.com/apache/incubator-mxnet/issues/16143 N_TRIES (10) times, copies its output (expected to be an array with all elements equal to 4) and then checks if all the copies are equal by printing the maximum absolute difference between the first copy and the others. So the expected outcome is zero, but every time the program is ran the max is either 4 or a very large number.
This is an equivalent example in python which works correctly:
import mxnet as mx
import numpy as np

sym = mx.sym.Convolution(
	mx.sym.Variable('in'),
	mx.sym.Variable('w'),
	mx.sym.Variable('b'),
	kernel=(1, 1),
	num_filter=40
)
args = {
	'in': mx.nd.ones([1, 3, 10, 10]),
	'w': mx.nd.ones([40, 3, 1, 1]),
	'b': mx.nd.ones([40]),
}

ex = sym.bind(mx.cpu(), args)

outs = []
for i in range(10):
	ex.forward()
	outs.append(ex.outputs[0].asnumpy())
print(
	max([np.max(np.absolute(outs[0] - out)) for out in outs[1:]])
)

A bonus:
Uncommenting these two lines in the function NDArrayCopy
// printf("\n---- Copy Outcome:\n");
// for(i = 0; i < 8; i++) printf("%f %f\n", copy[i], data_float[i]);

shows that not even copying the output is safe. Elements of the output array apparently get changed right after being copied, so this looks some sort of problem with the asynchronous engine I would guess. The 8 there is not random: apparently there is never any difference after element 8.

I should also mention that the problem disappears if running with MXNET_MKLDNN_ENABLED=0

@matteosal Thanks for reporting this. It turns out that the fix for https://github.com/apache/incubator-mxnet/issues/16143 has a bug that, a unreliable data pointer would be returned which points to a  released memory sometime. We will provide another fix to improve this. Sorry about this.

@matteosal As https://github.com/apache/incubator-mxnet/pull/16289 is merged, this issue should be fixed. Can you try again to see if your real case get fixed? Thanks.

Yes it's fixed, we don't see this problem in our test suite anymore


Sort threads and goroutines by ID

The output of threads is in a different order every time you run it. The goroutines output order is consistent, but I added sorting to those just to keep it consistent.

Thanks!


CMakeLists.txt fix

Description:
This PR introduces several updates to improve the build and configuration process for the project:

CMake Configuration: Updated CMakeLists.txt to allow easier switching between ROS 1, ROS 2, and stand-alone builds.
CMake Configs: Added CMake configuration files to enable find_package functionality, making integration with other projects smoother.
Global Script Installation: Modified the installation process to ensure scripts are installed globally, allowing them to be accessed from any directory.
README Update: I expanded the README to provide more detailed instructions, as the previous version lacked sufficient information for new users.
Fix for Stand-alone Build: The stand-alone build previously failed due to existing ament references. This has now been addressed, ensuring successful stand-alone builds without ROS dependencies.

Additional Notes:

No breaking changes are introduced.
Tested with both ROS 1 and ROS 2 environments to ensure smooth switching.
Stand-alone builds are now working after addressing the ament issue.

Hi @HesamTaherzadeh
I'm not entirely convinced about having the rolling branch code to compile the project for noetic, especially when ROS 1 will be EOL soon. I suggest making a "noetic" branch and redirecting the PR there, just for ROS 1. What do you think?

Hi @HesamTaherzadeh
I have created the noetic branch and changed the base of this PR. Please, resolve conflicts for merging this.
Thanks!!

Hey professor,
Sure will do as soon as possible, tnx.
On Mon, Dec 2, 2024 at 13:26 Francisco Martín Rico @.***>
wrote:

Hi @HesamTaherzadeh https://github.com/HesamTaherzadeh
I have created the noetic branch and changed the base of this PR. Please,
resolve conflicts for merging this.
Thanks!!
—
Reply to this email directly, view it on GitHub
https://github.com/fmrico/yaets/pull/1#issuecomment-2511067308, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AVJYF5S4POVELRIJBVXZI2T2DQVFPAVCNFSM6AAAAABQSANVNCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMJRGA3DOMZQHA
.
You are receiving this because you were mentioned.Message ID:
@.***>

Any chance to review the new commits?

Hi @HesamTaherzadeh
LGTM!! Please, resolve the conflicts for merging
Thanks!!


have separate datetime types

fixes #75

All changed packages have been documented.

You can try these changes at https://cadlplayground.z22.web.core.windows.net/typespec-azure/prs/295/
Check the website changes at https://tspwebsitepr.z22.web.core.windows.net/typespec-azure/prs/295/


[Bug]: Wifi Door Lock not working

What happened?
Unable to control the smart wifi lock from Eufy with the plugin, it worked once or twice then the response is timing out.
Device Type
Doorbell (Supported)
Plugin Version
v2.0.x (Supported)
HomeBridge Version
v1.6.x (Supported)
NodeJS Version
v18 (Supported)
Operating System
Raspbian 10+ (Supported)
Relevant log output
[03/20/2024, 04:19:11]  [EufySecurity]  INFO    Registering new accessory: Retreat
[03/20/2024, 04:19:11]  [EufySecurity]  INFO    Registering new accessory: Alfresco Main
[03/20/2024, 04:19:11]  [EufySecurity]  INFO    Registering new accessory: Games Room
[03/20/2024, 04:19:11]  [EufySecurity]  INFO    Registering new accessory: Retreat
[03/20/2024, 04:19:11]  [EufySecurity]  INFO    Registering new accessory: Upstairs Passage
[03/20/2024, 04:19:11]  [EufySecurity]  INFO    Registering new accessory: Laundry
[03/20/2024, 04:19:11]  [EufySecurity]  INFO    Registering new accessory: Entryway
[03/20/2024, 04:19:11]  [EufySecurity]  INFO    Registering new accessory: Games Room
[03/20/2024, 04:19:11]  [EufySecurity]  INFO    Registering new accessory: Manhole
[03/20/2024, 04:19:11]  [EufySecurity]  INFO    Registering new accessory: Alfresco Side
[Front Door@Front Door@Battery Level] Characteristic not in required or optional characteristic section for service LockMechanism. Adding anyway.
[03/20/2024, 04:19:11]  [EufySecurity]  INFO    Registering new accessory: Front Door
[03/20/2024, 04:19:11]  [EufySecurity]  INFO    Doorbell is set to handle snapshots with cloud images. Snapshots might be older than they appear.
[03/20/2024, 04:19:11]  [EufySecurity]  INFO    Registering new accessory: Doorbell
[03/20/2024, 04:19:44]  [EufySecurity]  INFO    Looking for old cached accessories that seem to be outdated...
[03/20/2024, 04:19:44]  [EufySecurity]  INFO    No outdated cached accessories found.
[20/03/2024, 04:19:49] [homebridge-eufy-security] This plugin generated a warning from the characteristic 'Administrator Only Access': characteristic value expected boolean and received function. See https://homebridge.io/w/JtMGR for more info.
[20/03/2024, 04:19:49] [homebridge-eufy-security] Error:
    at AdministratorOnlyAccess.Characteristic.characteristicWarning (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:3011:105)
    at AdministratorOnlyAccess.Characteristic.validateUserInput (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:2887:12)
    at AdministratorOnlyAccess.<anonymous> (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:2405:24)
    at step (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:195:27)
    at Object.next (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:176:57)
    at fulfilled (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:166:62)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
[20/03/2024, 04:19:50] [homebridge-eufy-security] This plugin generated a warning from the characteristic 'Administrator Only Access': characteristic value expected boolean and received function. See https://homebridge.io/w/JtMGR for more info.
[20/03/2024, 04:19:50] [homebridge-eufy-security] Error:
    at AdministratorOnlyAccess.Characteristic.characteristicWarning (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:3011:105)
    at AdministratorOnlyAccess.Characteristic.validateUserInput (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:2887:12)
    at AdministratorOnlyAccess.<anonymous> (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:2405:24)
    at step (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:195:27)
    at Object.next (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:176:57)
    at fulfilled (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:166:62)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
[20/03/2024, 04:19:53] [homebridge-eufy-security] This plugin generated a warning from the characteristic 'Administrator Only Access': characteristic value expected boolean and received function. See https://homebridge.io/w/JtMGR for more info.
[20/03/2024, 04:19:53] [homebridge-eufy-security] Error:
    at AdministratorOnlyAccess.Characteristic.characteristicWarning (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:3011:105)
    at AdministratorOnlyAccess.Characteristic.validateUserInput (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:2887:12)
    at AdministratorOnlyAccess.<anonymous> (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:2405:24)
    at step (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:195:27)
    at Object.next (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:176:57)
    at fulfilled (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:166:62)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
[20/03/2024, 04:20:23] [Homebridge UI] [nbhuta] Accessory layout changes saved.
[20/03/2024, 04:20:33] [Homebridge UI] [nbhuta] Accessory layout changes saved.
[20/03/2024, 04:20:38] [homebridge-eufy-security] This plugin generated a warning from the characteristic 'Administrator Only Access': characteristic value expected boolean and received function. See https://homebridge.io/w/JtMGR for more info.
[20/03/2024, 04:20:38] [homebridge-eufy-security] Error:
    at AdministratorOnlyAccess.Characteristic.characteristicWarning (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:3011:105)
    at AdministratorOnlyAccess.Characteristic.validateUserInput (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:2887:12)
    at AdministratorOnlyAccess.<anonymous> (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:2405:24)
    at step (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:195:27)
    at Object.next (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:176:57)
    at fulfilled (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:166:62)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
[20/03/2024, 04:20:40] [homebridge-eufy-security] This plugin generated a warning from the characteristic 'Administrator Only Access': characteristic value expected boolean and received function. See https://homebridge.io/w/JtMGR for more info.
[20/03/2024, 04:20:40] [homebridge-eufy-security] Error:
    at AdministratorOnlyAccess.Characteristic.characteristicWarning (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:3011:105)
    at AdministratorOnlyAccess.Characteristic.validateUserInput (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:2887:12)
    at AdministratorOnlyAccess.<anonymous> (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:2405:24)
    at step (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:195:27)
    at Object.next (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:176:57)
    at fulfilled (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:166:62)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
[20/03/2024, 04:21:30] [homebridge-eufy-security] This plugin generated a warning from the characteristic 'Administrator Only Access': characteristic value expected boolean and received function. See https://homebridge.io/w/JtMGR for more info.
[20/03/2024, 04:21:30] [homebridge-eufy-security] Error:
    at AdministratorOnlyAccess.Characteristic.characteristicWarning (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:3011:105)
    at AdministratorOnlyAccess.Characteristic.validateUserInput (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:2887:12)
    at AdministratorOnlyAccess.<anonymous> (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:2405:24)
    at step (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:195:27)
    at Object.next (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:176:57)
    at fulfilled (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:166:62)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
[20/03/2024, 04:22:38] [homebridge-eufy-security] This plugin generated a warning from the characteristic 'Administrator Only Access': characteristic value expected boolean and received function. See https://homebridge.io/w/JtMGR for more info.
[20/03/2024, 04:22:38] [homebridge-eufy-security] Error:
    at AdministratorOnlyAccess.Characteristic.characteristicWarning (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:3011:105)
    at AdministratorOnlyAccess.Characteristic.validateUserInput (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:2887:12)
    at AdministratorOnlyAccess.<anonymous> (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:2405:24)
    at step (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:195:27)
    at Object.next (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:176:57)
    at fulfilled (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:166:62)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
[20/03/2024, 04:23:03] [homebridge-eufy-security] This plugin generated a warning from the characteristic 'Administrator Only Access': characteristic value expected boolean and received function. See https://homebridge.io/w/JtMGR for more info.
[20/03/2024, 04:23:03] [homebridge-eufy-security] Error:
    at AdministratorOnlyAccess.Characteristic.characteristicWarning (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:3011:105)
    at AdministratorOnlyAccess.Characteristic.validateUserInput (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:2887:12)
    at AdministratorOnlyAccess.<anonymous> (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:2405:24)
    at step (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:195:27)
    at Object.next (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:176:57)
    at fulfilled (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:166:62)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
[20/03/2024, 04:23:14] [homebridge-eufy-security] This plugin generated a warning from the characteristic 'Administrator Only Access': characteristic value expected boolean and received function. See https://homebridge.io/w/JtMGR for more info.
[20/03/2024, 04:23:14] [homebridge-eufy-security] Error:
    at AdministratorOnlyAccess.Characteristic.characteristicWarning (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:3011:105)
    at AdministratorOnlyAccess.Characteristic.validateUserInput (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:2887:12)
    at AdministratorOnlyAccess.<anonymous> (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:2405:24)
    at step (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:195:27)
    at Object.next (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:176:57)
    at fulfilled (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:166:62)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
[20/03/2024, 04:23:36] [homebridge-eufy-security] This plugin generated a warning from the characteristic 'Administrator Only Access': characteristic value expected boolean and received function. See https://homebridge.io/w/JtMGR for more info.
[20/03/2024, 04:23:36] [homebridge-eufy-security] Error:
    at AdministratorOnlyAccess.Characteristic.characteristicWarning (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:3011:105)
    at AdministratorOnlyAccess.Characteristic.validateUserInput (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:2887:12)
    at AdministratorOnlyAccess.<anonymous> (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:2405:24)
    at step (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:195:27)
    at Object.next (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:176:57)
    at fulfilled (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:166:62)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
[20/03/2024, 04:24:14] [homebridge-eufy-security] This plugin generated a warning from the characteristic 'Administrator Only Access': characteristic value expected boolean and received function. See https://homebridge.io/w/JtMGR for more info.
[20/03/2024, 04:24:14] [homebridge-eufy-security] Error:
    at AdministratorOnlyAccess.Characteristic.characteristicWarning (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:3011:105)
    at AdministratorOnlyAccess.Characteristic.validateUserInput (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:2887:12)
    at AdministratorOnlyAccess.<anonymous> (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:2405:24)
    at step (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:195:27)
    at Object.next (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:176:57)
    at fulfilled (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:166:62)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
[20/03/2024, 04:24:29] [homebridge-eufy-security] This plugin generated a warning from the characteristic 'Administrator Only Access': characteristic value expected boolean and received function. See https://homebridge.io/w/JtMGR for more info.
[20/03/2024, 04:24:29] [homebridge-eufy-security] Error:
    at AdministratorOnlyAccess.Characteristic.characteristicWarning (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:3011:105)
    at AdministratorOnlyAccess.Characteristic.validateUserInput (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:2887:12)
    at AdministratorOnlyAccess.<anonymous> (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:2405:24)
    at step (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:195:27)
    at Object.next (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:176:57)
    at fulfilled (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:166:62)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
[20/03/2024, 04:26:43] [homebridge-eufy-security] This plugin generated a warning from the characteristic 'Administrator Only Access': characteristic value expected boolean and received function. See https://homebridge.io/w/JtMGR for more info.
[20/03/2024, 04:26:43] [homebridge-eufy-security] Error:
    at AdministratorOnlyAccess.Characteristic.characteristicWarning (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:3011:105)
    at AdministratorOnlyAccess.Characteristic.validateUserInput (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:2887:12)
    at AdministratorOnlyAccess.<anonymous> (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:2405:24)
    at step (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:195:27)
    at Object.next (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:176:57)
    at fulfilled (/var/lib/homebridge/node_modules/homebridge/node_modules/tslib/tslib.js:166:62)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)

config
{
    "username": "*********@*******",
    "password": "********",
    "country": "AU",
    "deviceName": "",
    "platform": "EufySecurity",
    "stations": [
        {
            "hkAway": 0,
            "hkNight": 3,
            "serialNumber": "T8010P13203108C9",
            "hkHome": 63
        }
    ],
    "ignoreStations": [],
    "ignoreDevices": [
        "T8960P0020280085"
    ],
    "cleanCache": true,
    "cameras": [
        {
            "serialNumber": "T8960P0020280085",
            "rtsp": false,
            "talkback": false
        }
    ],
    "_bridge": {
        "username": "0E:6B:2D:AA:C4:1B",
        "port": 43821
    }
}

Yes

Hello what is the plug-in version used in your setup ?
Did you tried with the 2.3.14 ? (streaming issue has been reported but the rest works)

My version is v2.2.21
No updating now and will inform

Still the same unable to open or close the lock

can you provide logs ? see the wiki for the how to.

[22/03/2024, 10:50:24] [homebridge-eufy-security] Restarting child bridge...
[22/03/2024, 10:50:24] Got SIGTERM, shutting down child bridge process...
[03/22/2024, 10:50:24]  [EufySecurity]  INFO    Finished shutdown!
[22/03/2024, 10:50:29] [homebridge-eufy-security] Child bridge process ended
[22/03/2024, 10:50:29] [homebridge-eufy-security] Process Ended. Code: 143, Signal: null
[22/03/2024, 10:50:36] [homebridge-eufy-security] Restarting Process...
[22/03/2024, 10:50:37] [homebridge-eufy-security] Launched child bridge with PID 122911
[22/03/2024, 10:50:38] Registering platform 'homebridge-eufy-security.EufySecurity'
[22/03/2024, 10:50:38] [homebridge-eufy-security] Loaded homebridge-eufy-security v2.3.14 child bridge successfully
[22/03/2024, 10:50:38] Loaded 15 cached accessories from cachedAccessories.0E6B2DAAC41B.
[03/22/2024, 10:50:38]  [EufySecurity]  WARN    warning: planned changes, see https://github.com/homebridge-eufy-security/plugin/issues/1
[03/22/2024, 10:50:38]  [EufySecurity]  INFO    ffmpegPath set: /var/lib/homebridge/node_modules/homebridge-eufy-security/node_modules/ffmpeg-for-homebridge/ffmpeg
[03/22/2024, 10:50:38]  [EufySecurity]  INFO    Country set: AU
[03/22/2024, 10:50:38]  [EufySecurity]  INFO    Finished initializing!
[22/03/2024, 10:50:38] Publishing bridge accessory (name: homebridge-eufy-security, publishInfo: {
username: '0E:6B:2D:AA:C4:1B',
port: 43821,
pincode: '--**',
category: 2,
bind: undefined,
mdns: undefined,
addIdentifyingMaterial: true,
advertiser: 'bonjour-hap'
}).
[22/03/2024, 10:50:38] Homebridge v1.7.0 (HAP v0.11.1) (homebridge-eufy-security) is running on port 43821.
[03/22/2024, 10:50:47]  [EufySecurity]  INFO    Updating existing accessory: NGRR_Base
[03/22/2024, 10:50:47]  [EufySecurity]  WARN    Front Door looks station but it's not could imply some errors! Type: 51
[03/22/2024, 10:50:47]  [EufySecurity]  INFO    Updating existing accessory: Front Door
[03/22/2024, 10:50:50]  [EufySecurity]  INFO    Updating existing accessory: Living Room
[03/22/2024, 10:50:50]  [EufySecurity]  INFO    Updating existing accessory: Retreat
[03/22/2024, 10:50:50]  [EufySecurity]  INFO    Updating existing accessory: Alfresco Main
[03/22/2024, 10:50:50]  [EufySecurity]  INFO    Updating existing accessory: Games Room
[03/22/2024, 10:50:50]  [EufySecurity]  INFO    Updating existing accessory: Retreat
[03/22/2024, 10:50:50]  [EufySecurity]  INFO    Updating existing accessory: Upstairs Passage
[03/22/2024, 10:50:50]  [EufySecurity]  INFO    Updating existing accessory: Laundry
[03/22/2024, 10:50:50]  [EufySecurity]  INFO    Updating existing accessory: Entryway
[03/22/2024, 10:50:50]  [EufySecurity]  INFO    Updating existing accessory: Games Room
[03/22/2024, 10:50:50]  [EufySecurity]  INFO    Updating existing accessory: Manhole
[03/22/2024, 10:50:50]  [EufySecurity]  INFO    Updating existing accessory: Alfresco Side
[03/22/2024, 10:50:50]  [EufySecurity]  INFO    Updating existing accessory: Front Door
[03/22/2024, 10:50:51]  [EufySecurity]  INFO    Doorbell is set to handle snapshots with cloud images. Snapshots might be older than they appear.
[03/22/2024, 10:50:51]  [EufySecurity]  INFO    WARNING: Motion detection and HomeKit Secure Video provide overlapping functionality. Only HomeKit Secure Video, when event recording is enabled in the Home app, will be used to trigger motion event notifications for this camera.
[03/22/2024, 10:51:01]  [EufySecurity]  ERROR   NGRR_Base handleSecuritySystemCurrentStateGets: Wrong return value
[03/22/2024, 10:51:01]  [EufySecurity]  ERROR   NGRR_Base handleSecuritySystemTargetStateGet: Wrong return value
[03/22/2024, 10:51:11]  [EufySecurity]  ERROR   NGRR_Base handleSecuritySystemCurrentStateGets: Wrong return value
[03/22/2024, 10:51:11]  [EufySecurity]  ERROR   NGRR_Base handleSecuritySystemTargetStateGet: Wrong return value
[03/22/2024, 10:51:26]  [EufySecurity]  INFO    Looking for old cached accessories that seem to be outdated...
[03/22/2024, 10:51:26]  [EufySecurity]  INFO    No outdated cached accessories found.

can you enable debug mode and redo the test ? see wiki for the how to enable debug

Sorry I am away from home, will do it today when I get back.

can you try with the latest version ?


ci plotting

we should add the option to use error bars instead of a ribbon. it is somewhat misleading with the ribbon since it is a point-wise confidence interval.

this is implemented but needs to be updated in the readme. i didn't make it an option, just chose bars


Add multiline method chain syntax

This syntax allows
x.foo().bar().baz(y)

to be rewritten as
x
    .foo()
    .bar()
    .baz(y)

Indentation is important,
x
.foo()

is invalid (this means sequential execution of x and .foo()).

How about making this work with |> instead? Makes things a bit more "functional pipeline"-ey to use.
x
    |> (_.foo())
    |> (_.bar())
    |> (_.baz(y))

I guess it sacrifices readability a lot more...
Also see https://github.com/fsharp/fslang-suggestions/issues/506 for a similiar discussion

The pipeline operator already exists in Erg.
assert -1 + -1 |> .abs() == 2

It might be a good to add the rule regarding this operator.

Oh cool! Ignore me then :P

@zetashift This isn't entirely related to Erg, but for what it's worth since this issue was linked to an F# issue, F# actually allows method chaining.
type Test() =
    member this.A () = this
    member this.B () = this
    member _.C () = ()

let test = Test()

test.A()
    .B()
    .C()

// or

test.A().B().C()

The linked feature of allowing _ is to support other different use cases and probably wouldn't be recommended just for method chaining using |>.
While strange indentation like
test
    .A()
    .B()
    .C()

is allowed in F#, it isn't recommended. That might be relevant to the original proposal here for Erg.


When multiple Database backends are used in ActiveRecord, DatabaseCleaner fails to truncate tables

When both MySQL and Postgres ActiveRecord models are used, and when testing MySQL-backed code, Truncation strategy includes BOTH ::DatabaseCleaner::ActiveRecord::MysqlAdapter and ::DatabaseCleaner::ActiveRecord::PostgreSQLAdapter into ::DatabaseCleaner::ActiveRecord::AbstractAdapter, which, in turn, gets included into ActiveRecord::AbstractAdapter.
Since PostgreSQLAdapter gets included last, even when ActiveRecord::Base.connection is a MySQL connection, DatabaseCleaner attempts to execute Postgres-specific truncations, resulting in errors:
NameError: undefined local variable or method `postgresql_version' for #<ActiveRecord::ConnectionAdapters::Mysql2Adapter:0x0000000692feb8>
  occurred at /usr/local/rvm/gems/ruby-1.9.2-p290/gems/database_cleaner-1.1.1/lib/database_cleaner/active_record/truncation.rb:123:in `db_version'

Problem there:
class Deletion < Truncation
    if defined?(ActiveRecord::ConnectionAdapters::Mysql2Adapter)
      include SelectiveTruncation
    end
    ...
end


Replaces /places/search and /places/ with calls to Geoserver for improved speed

This PR is a major rework of the way in which our vector data is brought into the API. The major changes are that the functionality in routes/vectordata.py has changed from utilizing shapefiles and GeoPanda GDFs to calls to our production Geoserver to return the geometries and metadata about all of our places for the NCR application.
This change provides a dramatic speedup in returned JSON data without losing any of the expected data! A clear example of that is to run something like on the current main branch vs this branch:
http://localhost:5000/places/search/64.28/-144
For testing, I would recommend that you point a local version of the NCR application at this local API on the use_gs_for_search branch:
export SNAP_API_URL=http://localhost:5000
Try many different clicks on the map and confirm that you are getting the same data back from the production NCR website. In addition, use the search bar to try search for different communities and area types to confirm those are all working in this branch.

I verified that the fixes to the issues I mentioned work as expected. Thanks, @BobTorgerson ! I was still having some trouble with the flammability and vegetation type endpoints, but they went away when I pointed my local API to Zeus instead of Apollo, so that may have been part of the original problem.
I did notice one more thing, however: Yukon Territory Protected Areas (YTPA*) and British Columbia Protected Areas (BCPA*) are also now returned from the /places/all endpoint. These are not available from the current production version of /places/all. The YTPA* areas tend to work okay in NCR, but the BCPA* areas tend not to have any meaningful data in NCR. We may want to just remove both YTPA* and BCPA* to avoid introducing more uncertainty into the tool, but I defer to you on this. Thanks!

@cstephen Yes, the beetle risk is only on Apollo and the ALFRESCO coverage is only on Zeus. We need to rectify that and when we move to have NCR update with the new Beetle Risk section, we will have to do so.
I've gone ahead and removed the Canadian protected areas as well, those should no longer cause issues.

Thanks for removing the Canadian protected areas, @BobTorgerson.
One last thing I noticed (sorry!), I think we want to add the area_type property back to the /places/all output. If you search for, for example, "Alagnak Wild River" on your local NCR running against this data-api branch vs. the production NCR, you'll notice that the area type decorative text (gray text) is missing because area_type is missing. This impacts all areas available from the place selector, I think.

Good catch @cstephen! I need to include that as part of the requested metadata fields to pull from Geoserver and then remove it from all areas that don't utilize that field. The latest commit fixes that if you want to confirm that!

I've confirmed that the latest commit fixes the place name decorative/gray text issue. Everything looks great to me and I don't have any more suggestions. Awesome work, @BobTorgerson!


Moving paw

Hello do you reckon is it possible to change the mowing paw like a normal human hand? as i do see some streamers having like a cartoon character but the moving hand is changed isn't like this. thank you

It's a duplicate of #27 . Sadly I don't think I will implement this, because it is too much work and I am not motivated to do so :(


No charges after and including a charge with charge_energy_used  = 0

Describe the bug
I'm not seeing new charges in Grafana.
To Reproduce
Steps to reproduce the behavior:

Make sure you have a charge with charge_energy_used = 0 , the rest of the charge must satisfy the WHERE clause in the grafana Charges query
Observe you don't have any charges after the charge with charge_energy_used = 0
Go to Query inspector > Generated SQL. Execute the SQL in pgsql manually. Observe you get a ERROR:  division by zero

Expected behavior
Charges.
Looks like a fix (or at least a workaround) is to change the Charges query line from
CASE WHEN charge_energy_used IS NULL THEN NULL ELSE LEAST(charge_energy_added / charge_energy_used, 1.0) END as charging_efficiency,
to
CASE WHEN charge_energy_used IS NULL THEN NULL ELSE LEAST(charge_energy_added / NULLIF (charge_energy_used, 0), 1.0) END as charging_efficiency,
Relevant entries from the logs
N/A
Screenshots
N/A
Data
charges.txt
Operating environment

TeslaMate Version: 1.16
Type of installation: Mixed
OS: Fedora

This was already fixed in b67b6e6f43145def4443e7d71c3d32d99aa304a5 and released with 1.16. Make sure to re-import the dashboards after each update :)


Multiple Grid, Same Razor page

I'm currently working on an app with a couple of tabs. Each tab makes use of a grid however, if I choose to have a grid per tab it throws the following error:
grid requires data or dataprovider not both.
The grids are almost identical except different models use them as such:
            <Grid TItem="grid1data" Data="@grid1data" Class="table table-hover table-bordered table-striped" AllowPaging="true" PageSize="100" ItemsPerPageText="100" PageSizeSelectorItems="new int[] {20}" PaginationItemsTextFormat="">
                <GridColumn TItem="grid1data" HeaderText="#">
                    @GetTeamRowNumber(context)
                </GridColumn>
                <GridColumn TItem="grid1data" HeaderText="heading1" PropertyName="heading1" SortKeySelector="item => item.heading1">
                    @context.heading1
                </GridColumn>
                <GridColumn TItem="grid1data" HeaderText="heading2" PropertyName="heading2" SortKeySelector="item => item.heading2">
                    @context.heading2
                </GridColumn>
            </Grid>

The second grid is the same except that everything uses grid2data. I thought this would be allowed but throwing the error indicates otherwise. Can you advise?

@talanw Thank you for using BlazorBootstrap. Please share the sample code or GitHUB repo with minimal steps to reproduce the issue. Also provide the below details:
.NET Version:
Blazor Web Assembly/Server:
BlazorBootstrap Version:
OS:
Browser:


fix(Firefox): Add 'Select/Unselect tabs in the same container'

It can be triggerred by alt+x, alt+click, and click Tab Menu

Coverage decreased (-0.1%) to 28.941% when pulling e42ad23a754ddf9e3a6bb8461b1c47a0aba91d91 on select-tabs-in-same-container into 1abcd7c55b773146c3c91b3773d5a682286559d6 on master.


Adding a Barb on the filter housing on the tube side.

What has to be done
A barb has to be added to the filter housing to hold the tube firmly as the tube is getting slipped from the filter housing.
Files of the new design should be updated in the repository:

Original CAD files (or link to web-based CAD)
exported stl or step files

How do you know it has to be done
While assembling the enclosure we faced an issue of the tube gets slipped off from the filter housing so form the next revision we are planning to add a barb on the housing so that it will help in holding the tube firmly.

Code pointers
This is the page that needs to be updated:
https://github.com/RespiraWorks/Ventilator/tree/master/manufacturing/filter_holder

Question about the shape of the barb. Could it not instead be like this type of barb that we have on most of tube fittings?

I am concerned that width of the "notch" must be compatible with whatever clip we use to attach the tubing, so this may be making too much of at assumption at this stage in prototyping?

This issue is superseded by #917


Wip begin transaction

This add the the logging of an metadata from the transaction to the WAL, and recover on open/restore and allow to access the last logged metadata, the current implementation do not support concurrent operations for the transactions metadata, there is just a callback to let the high level know that the current metadata is logged so a newer transaction can be sent, this is more then enough for what is needed today.

Codecov Report

:exclamation: No coverage uploaded for pull request base (develop@d9b558a). Click here to learn what that means.
The diff coverage is 41.17%.

@@            Coverage Diff             @@
##             develop    #9147   +/-   ##
==========================================
  Coverage           ?   52.27%
  Complexity         ?    36041
==========================================
  Files              ?     2517
  Lines              ?   197352
  Branches           ?    35350
==========================================
  Hits               ?   103157
  Misses             ?    79229
  Partials           ?    14966

Impacted Files
Coverage Δ
Complexity Δ

...orage/impl/local/paginated/wal/WALRecordTypes.java
0% <ø> (ø)
0 <0> (?)

...ore/storage/memory/ODirectMemoryOnlyDiskCache.java
65.05% <ø> (ø)
42 <0> (?)

...pl/local/paginated/wal/OAbstractWriteAheadLog.java
26.92% <ø> (ø)
3 <0> (?)

...rientechnologies/orient/core/storage/OStorage.java
100% <ø> (ø)
0 <0> (?)

...ache/local/aoc/AppendOnlyCompressedWriteCache.java
0% <ø> (ø)
0 <0> (?)

...ies/orient/core/storage/cache/local/OWOWCache.java
45.65% <0%> (ø)
112 <0> (?)

...ent/core/storage/impl/local/OMicroTransaction.java
69.18% <0%> (ø)
93 <0> (?)

...impl/local/paginated/wal/OMemoryWriteAheadLog.java
31.25% <0%> (ø)
9 <0> (?)

...ntechnologies/orient/core/db/OrientDBEmbedded.java
74.05% <0%> (ø)
91 <0> (?)

...d/wal/cas/OFuzzyCheckpointStartMetadataRecord.java
0% <0%> (ø)
0 <0> (?)

... and 9 more

Continue to review full report at Codecov.

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


Add children to folder metadata for intra_move and intra_copy

Purpose:
SVCS-229
WB API: OSFStorage intra_move/_copy does not return children
Changes:
update  waterbutler/providers/osfstorage/provider.py

def intra_move update to return children
def intra_copy update to return children

Side effects:
None
[#SVCS-229]

I spent some time looking at possible tests for this. If I understand what I was looking at, there is a waterbutler.io API for prod osfstorage. I'm not sure how to properly test against that.

Test created. It turns out that a call to intra_copy does do one call each to src_prov._children_metadata and src.validate_v1_path, so the test is a little different then you requested.


Add October 2023 patch releases

This PR adds patch releases that went out in October 2023. I'll create another PR to add release dates for 2024. 1.25 will be marked as EOL after 2023-10-28 (I'll prepare a PR for that too)
/assign @saschagrunert @cpanato @Verolop
cc @kubernetes/release-engineering

/lgtm


Nothing happens when editComment returns null

Issue Type: Bug
Testing #59278
It looks like the operation is still running. (Similar to #59348.)
VS Code version: Code - Insiders 1.28.0-insider (fe8d9d2470ddffb9dc2da604b23f5bd8a185cd66, 2018-09-25T07:29:33.175Z)
OS version: Darwin x64 17.7.0

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz (8 x 2200)

GPU Status
2d_canvas: enabledchecker_imaging: disabled_offflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: enabledrasterization: enabledvideo_decode: enabledvideo_encode: enabledwebgl: enabledwebgl2: enabled

Load (avg)
2, 2, 2

Memory (System)
16.00GB (3.83GB free)

Process Argv
--user-data-dir /Users/chrmarti/Development/repos/tmp/user2 --extensions-dir /Users/chrmarti/Development/repos/tmp/ext2

Screen Reader
no

VM
33%

Extensions: none

I'm not sure I understand what returning null is meant to signify in this context - that there was no update? What is the expected behavior in that case?

It's a extension's error. I'd expect it to be handled in a way that does not leave the UI in that intermediate state like it is still updating. Maybe handle it similarly to when an error is thrown.

Based on feedback of https://github.com/Microsoft/vscode/issues/59460, I changed the return type of editComment to Promise<void>. So the extension should now either return nothing and succeed, or throw


OpenSFF Best Practices Badge Program for Chains

Achieve the OpenSFF Best Practices Badge.
Add the badge to the main project README.

FYI @tektoncd/chains-maintainers - is anyone available to drive this to completion?

OpenSSF badge passing.
Added to the REAME in https://github.com/tektoncd/pipeline/pull/5586


h-net integration

Hello,
Can you please tell if you have integrated Hnet with lanenet yet?

@singaporv No I have not integrated with HNet. The ipm module is replaced with my own module. You can refer https://github.com/MaybeShewill-CV/Easy-Ipm-Client if you're interested with the ipm module:)

@MaybeShewill-CV
Thanks for the information, I'll look into it.
Also, one more thing - in file Lanenet_cluster.py
you have defined a function --> def _lane_fit(lane_pts):
But, in your implementation you are not calling it, to fit a line.
Can you please tell where to integrate this in our function call, or if not possible, can you please tell how can I fit a line on the points in mask_image?

@singaporv The fit line function was not used. If you want to fit a line you need to cluster to determin which lane points belong to the same lane and then you can apply a ploy line fit function on those points:)


WIP: Store inline equations

For inline equations, I have added a new node type in the frontend, which will be POSTed to the backend in the following form:
{
  "type": "equation-inline",
  "isInline": true,
  "children": [
    {"text": "e=mc^2}
  ]
}

With the changes in this PR and when I POST a document containing an inline equation, I get a success response but the inline equation is not returned with the document in the response. Likewise when I reload the page after saving the inline equation is not present.
I'm sure I'm missing something, could you point me in the right direction.

@oliverroick you were just missing a line including the EquationInlineNode type as a possible member of the Section type.
I'm surprised that you were getting a success response from the POST, if you were using a node-type that wasn't explicitly allowed in the Section type. My guess is that Pydantic is ignoring the type value that it doesn't recognize and either:

Discarding the element all together
Formatting it as an Equation type

I can look into that, but you should be good to go on this PR (for just inserting and retrieving the values from the DB). You still have to add handling for the inline equations to the documentation generation.
I can look into that quickly

It also look like Abstract and Plain Language Summary have to be handled as rich text in the PDF generation

Thanks @leothomas , but this doesn't seem to work yet.
Just to add a bit more detail, here's the full payload, I'm sending for the abstract field:
{
  "abstract": {
    "children": [
      {
        "children": [
          {
            "text": " Lorem ipsum dolor sit amet, "
          },
          {
            "bold": true,
            "text": "consectetur"
          },
          {
            "text": " porttitor. "
          }
        ],
        "type": "p"
      },
      {
        "children": [
          {
            "text": "e=mc^2"
          }
        ],
        "isInline": false,
        "type": "equation"
      },
      {
        "children": [
          {
            "text": "Lorem ipsum dolor sit amet, consectetur "
          },
          {
            "children": [
              {
                "text": "latex~empty~equation"
              }
            ],
            "isInline": true,
            "type": "equation-inline"
          },
          {
            "text": " adipiscing elit. Vestibulum volutpat fermentum nisi feugiat mollis. Donec tristique sem vel felis semper tincidunt vel in sapien. Nunc ut tortor quis sem dictum imperdiet vitae sed tellus. Aliquam ultrices id risus vitae posuere. Nullam magna purus, tincidunt egestas dignissim et, varius consequat nisi. Donec eu leo mi. Duis sed nulla odio. Vivamus pharetra. "
          }
        ],
        "type": "p"
      }
    ]
  }
}

And the response I'm getting for the abstract field is:
{
  "abstract": {
    "children": [
      {
        "type": "p",
        "children": [
          {
            "text": " Lorem ipsum dolor sit amet, "
          },
          {
            "text": "consectetur",
            "bold": true
          },
          {
            "text": " porttitor. "
          }
        ]
      },
      {
        "type": "equation",
        "children": [
          {
            "text": "e=mc^2"
          }
        ],
        "isInline": false
      },
      {
        "type": "p",
        "children": [
          {
            "text": "Lorem ipsum dolor sit amet, consectetur "
          },
          {
            "text": ""
          },
          {
            "text": " adipiscing elit. Vestibulum volutpat fermentum nisi feugiat mollis. Donec tristique sem vel felis semper tincidunt vel in sapien. Nunc ut tortor quis sem dictum imperdiet vitae sed tellus. Aliquam ultrices id risus vitae posuere. Nullam magna purus, tincidunt egestas dignissim et, varius consequat nisi. Donec eu leo mi. Duis sed nulla odio. Vivamus pharetra. "
          }
        ]
      }
    ]
  }
}

The inline is the second element of the third child. We're sending it as:
{
  "children": [
    {
      "text": "latex~empty~equation"
    }
  ],
  "isInline": true,
  "type": "equation-inline"
}

But it comes back as:
{
  "text": ""
}

Is it possible that I need to structure inline elements in a different way? For example, does the text field need to sit at the same level as the type key?

@oliverroick thanks for all the clarifications. Just added a few more edits, you should be good to go now!
Note - I removed the boolean isInLine field since the type field already denotes between equation and equation-inline.
The reason why the inline equations were showing up as {"text":""} is because of a peculiar behaviour in Pydantic (described here): the div type's children field is defined as List[Union[linkNode, refNode, textLeaf, equationInline]] - so pydantic will build the object that first matches the input rather than the object that best matches the input (in this case textLeaf rather than equationInline). The fix is to switch the order of the possible child nodes and let textLeaf act as a catch for all the inputs that don't already match to something else.
The payload should look like:
"document": {
    "abstract": {
        "children": [
            {
                "type": "p",
                "children": [
                    {
                        "text": "A brief and interesting overview of the themes presented in this document are as follows: At vero eos et accusamus et iusto odio dignissimos ducimus qui blanditiis praesentium voluptatum deleniti atque corrupti quos dolores et quas molestias excepturi sint occaecati cupiditate non provident, similique sunt in culpa qui officia deserunt mollitia animi, id est laborum et dolorum fuga."
                    },
                    {
                        "type": "equation-inline",
                        "children": [
                            {
                                "text": "\\delta = \\sum_{n=1}^{\\infty} 2^{-n} = 1"
                            }
                        ],
                    },
                ],
            }
        ]
    }
}

Screen shots of generated documents:
regular:

journal:

@leothomas I've adapted the front-end accordingly and this works fine now. Can we get this approved?