pip fails to install hawc_hal due to pytables

I'm getting the following error installing hawc_hal with pip (this is with python 3.7.8, astromodels 2.0.0 and threeML 2.0.0 from conda):
ERROR: Could not find a version that satisfies the requirement pytables (from astromodels->hawc-hal==1.0) (from versions: none)
ERROR: No matching distribution found for pytables (from astromodels->hawc-hal==1.0)

I was able to work around this by using pip install --no-deps to install hawc_hal (and installing all dependencies manually).
However, the same error is now also causing the automated tests to fail.
Any idea where this is coming from? I do have pytables installed, but pip isn't picking up on it:
(st3ml) √ my3ML/hawc_hal $ pip list | grep pytables                                                                                22:42:50
(st3ml) ?1 my3ML/hawc_hal $ conda list pytables                                                                                22:42:55
# packages in environment at /Users/hfleisc1/opt/anaconda3/envs/st3ml:
#
# Name                    Version                   Build  Channel
pytables                  3.6.1            py37he95298d_3    conda-forge

Also, I don't find pytables mentioned anywhere in the hawc_hal dependencies.

This seems to be a python 3 issue only... See https://travis-ci.org/github/threeML/hawc_hal/jobs/738193405#L1016 (install fails) and https://travis-ci.org/github/threeML/hawc_hal/jobs/738193403#L1121 (install succeeds).

Solved with https://github.com/threeML/astromodels/pull/134


add Windows x64 (WIN64) mode and make buildable for the VS project file

changed .sln and .vcproj files being able to build x64 on MSVC
fixed comparison bug on socket creation failure when using Windows socket API
changed size_t casting for supporting 64bit (gpr_malloc_aligned)

I've created a pull request on your fork: zeliard/grpc#1
This is to solve the sanity failure on travis for that PR.

I already confirmed CLA
:)


[Change Case] Some transformations don't work

Extension
https://www.raycast.com/erics118/change-case
Description
When copying/selecting text in UPPERCASE and then selecting e.g. the Sentence or Title case transformation, the text stays all uppercase. I would expect that it gets transformed according to the selected case action.
Steps To Reproduce

Select or copy uppercase text, e.g. THIS IS A TEXT
Call the extension via Raycast and select the Title Case or Sentence Case actions
Text stays all uppercase

See screenshot:

Current Behaviour
Text stays uppercase, doesn't get transformed.
Expected Behaviour
Text should be transformed to selected action.

@erics118 converting all the characters to lowercase and then using the underlying library to change to title case would work better i guess?

It seems that it could result in some unintended consequences. See https://github.com/blakeembrey/change-case/issues/308.

Okay.

This is the correct behavior. The underlying library keeps text that is capitalized as-is in this case.

Ok, so this is the behavior of the underlying library but it is certainly NOT the behavior the user expects.
I know it now but others won't so I'd like to suggest adding a very simple README.md with one or two sentences explaining the current behavior. Adding a README would display the "About this extension" button in Raycast as well as add the info to the store page; that would ensure that users of your extension don't have wrong expectations or even open a bug, as I did... ;-)

Feel free to PR some more clarification to add to the README.

Yeah.. so this is kinda weird..

You are all fine with numerous bug reports because people don't understand the behaviour but still nobody is able to add a simple sentence to the README? OMG... I'm so happy that I left open-source software 15 years ago...

@raycastbot reopen this issue


Prepare release v0.2.0

Prepare release v0.2.0

Pull Request Test Coverage Report for Build 8c60970270e7155e703ea0625387a0f16d9d28fd-PR-27

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

Totals

Change from base Build a5557b1578fbd5934cdc12918582ffa58e5c2c98:
0.0%

Covered Lines:
103

Relevant Lines:
103

💛  - Coveralls


chore: update flux dependency

Fixes https://github.com/influxdata/influxdb/issues/16810.

Yes, thanks for reminding me.

Both have go.mod files have been updated.


User should not be able to create duplicate/redundant links

See attached screenshot - the user should not be able to create multiple duplicate links:

Thank you for reporting this issue. I will address it.

@ldimaggi / @kwk this has been fixed on the UI. Anything needs to be done on core?

@kwk is the backend handling this? From UI side we are not allowing user to add duplicate link.

As this is not a scenario that we mapped out in the UI, one question I have
is how this event is being realized in the UI and communicated to the user?
A few ideas come to mind quickly, but would need to be vetted.

Don't show links that already exist in the drop down of links
Show the links, but disable them
Show the links, disable them and add a qualifier that indicates the link
is already linked. We could even go so far as to highlight the link below
and bring it into focus if the user hovers or selects it.
Show a dialog stating that "You already have created the same link with
this item... - OK" (not the best wording but the idea :)

I am not sure where the discussions are with this and what decisions might
have already been made, but Sudipta if you can bring me up to date and we
can look at solutions together, that would be great.
Thanks,
Monica
On Wed, Jan 18, 2017 at 3:17 AM, Sudipta Sen<EMAIL_ADDRESS>wrote:

@kwk https://github.com/kwk is the backend handling this? From UI side
we are not allowing user to add duplicate link.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/fabric8io/fabric8-planner/issues/430#issuecomment-273411183,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ARTwq3vHHA2jsiehJtAQm5pvgOKd68Lqks5rTcqbgaJpZM4LEWPD
.


Missing description of input signal from documentation.

Hi,
Description of input "data_err_i" of the data memory interface is missing from documentation. This signal is currently used only for an assertion. Since it is a top level input, I believe it would be better for the user to read about it in the documentation instead of figuring it out from the RTL.
Best,
Ioannis

Absolutely. Would you mind opening a PR adding documentation for that signal?

Actually, I could do that as I am about to create a new PR for letting the core evaluating that signal and trigger exceptions.


Feature Request: Detect unintended tuple creation from trailing commas in boolean expressions

While Ruff currently detects trailing commas that create unintended tuples in direct if statement conditions, it doesn't detect similar issues when the tuple is created in a variable assignment and then used in control flow. This can lead to subtle bugs where boolean expressions become truthy tuples instead of boolean values.
Description
Consider this code pattern:
# Currently detected by Ruff
if (condition1 or condition2(),):  # Ruff warns about this
    ...

# But not detected
should_run_tests = (
    condition1() or condition2(),  # No warning
)
if should_run_tests:  # Bug: should_run_tests is always truthy (it's a tuple)
    ...

The trailing comma creates a single-element tuple, which is always truthy in Python boolean contexts. This is particularly problematic because:

The code appears to be a standard boolean expression at first glance
The pattern is common in multi-line boolean expressions for readability (which is how this manifested in our codebase...)
The bug is subtle and may not be caught by tests (tuple is always truthy)
Type checkers like PyRight only catch this with explicit type annotations (which don't really cover the if True footgun)
The pattern is particularly dangerous in control flow contexts where boolean evaluation is expected

Current Behavior

Ruff detects unintended tuple creation in direct if statement conditions
Does not detect similar issues in variable assignments

Proposed FR
Extend the existing rule, F634 (or create a new one) to:

Detect trailing commas in parenthesized boolean expressions involving:

and, or operators
Function calls that typically return booleans (e.g., methods named is_*, has_*, should_*)
Boolean constants (True, False)

Consider context clues that suggest boolean intent:

Variable names with boolean prefixes (is_*, has_*, should_*)
Usage in control flow contexts (if, while, etc.)
Type annotations (: bool)

Example Cases
# Should trigger warnings:
should_run_tests = (
    is_devbox() or is_local(),  # Trailing comma creates tuple
)

has_permission = (
    check_admin() or
    check_owner() or
    check_write_access(),  # Trailing comma
)

# Should not trigger warnings:
valid_tuple = (
    1,
)

config_values = (
    get_config("a"),
    get_config("b"),
)

Example Error Message
error: Trailing comma creates a tuple in boolean expression context, which is always truthy
   │
12 │     should_run_tests = (condition1() or condition2(),)
   │                                                     ^ trailing comma creates tuple
   │
   = help: Remove the trailing comma to create a boolean expression
   = note: Single-element tuples are always truthy in boolean contexts

Hi @MichaReiser! Sorry to bump, but I was curious whether this seemed feasible to support in F634 or something like that.

I don't think this should be handled by F634. That rule is explicitly scoped around if-conditions,


Priority of  and  query in query chains

I am trying to make a chained query with a or query in it. Here is this model and my query (simplified for statement) :
type Assignment struct {
	User string
	Group string
	Project string
}
db.Where("user = ?", "user1").Or("group = ?", "group1").Where("project = ?", "project1").Find(&assignments)

The sql I expected is:
SELECT * FROM `assignments`  WHERE ((user = 'user1') OR (group = 'group1')) AND (project = 'project1')

But I got:
SELECT * FROM `assignments`  WHERE (user = 'user1') AND (project = 'project1') OR (group = 'group1')

Seems there is not way to increase the priority of Or query above And query in gorm.
Is there any development plan or any method I missed?

You could use the following instead:
db.Where("user = ? OR group = ? OR project = ?", "user1", "group1", "project1").Find(&assignments)

same issue!

same issue!

same issue!

Same issue


How to handle pull based metric exporters like prometheus

Discussed here.
The spec allows pull based metric exporters to be implemented as "just another exporter", which needs to be paired with a metric reader, or as metric readers. This flexibility means that there's not an obvious way to configure pull based metric exporters since what is intuitive for one language ecosystem will not be so for another.
If pull based exporters are paired with a reader, you'd expect something like:
sdk:
  meter_provider:
    exporters:
      prometheus:
        port: 5555
    metric_readers:
      - name: periodic
        args:
          exporter: prometheus

This is nice because prometheus is configured in the sdk.meter_provider.exporters block with the other exporters. But its confusing because its paired with a reader (in this case periodic for lack of a better option) and it clearly does not read periodically.
But if pull based exporters are readers, you'd expect something like:
sdk:
  meter_provider:
    metric_readers:
      - name: prometheus
         args:
           port: 5555

This is nice because prometheus doesn't need to be paired with periodic reader like in the example above. But it may be confusing to see prometheus configuration in the reader configuration instead of in sdk.meter_provider.exporters with the other exporters.
A compromise will have to be made at some level.

I think option 2 makes more sense here, otherwise it won't make sense to anyone who's configued the prometheus reader using the SDK.


Add documentation for each rule

Fixes #65
@danvk

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

This is awesome, thanks @andy-ms!


Multiple Image Selection not working

In version 2.4.0, multiple image selection stopped working. It was working in previous version.

Can you please confirm if it fixed wit last beta release 2.4.1-beta or not?
Thanks


[BUG] Caching does not work with useTable due to the returned loading attribute set to true during re-validation

Describe the bug
With the changes introduced in https://github.com/pankod/refine/pull/1319 useTable properly returns loading as true while loading is being performed on new requests but now also incorrectly returns true while react query revalidates the response.
To Reproduce
Steps to reproduce the behavior:

Go to list page
Click on a new page through pagination
Observe that loader correctly displays
Click on previous page
Observe that loader appears again even though data is already there (react query merely revalidates the cache at this point)

Expected behavior
Loading should not appear when a cached response is ready to be served. This can be achieved by relying either on status or on isSuccess instead of isFetching (which is also true while revalidating cache).
See for solution suggestion https://github.com/pankod/refine/pull/1319#issuecomment-993494500
Screenshots
Also shown in suggestion mentioned above.
Desktop (please complete the following information):

Browser: Edge
Version: 2.4.5
Used dataProvider: Custom Mock Implementation

Additional context
I wasn't sure if I should create a new issue for this but thought it's better to keep track of it separately since it deals with something slightly different from https://github.com/pankod/refine/issues/1316.

Hey @IgnusG,
We tried, but we could not achieve the desired result. Can you take a look too?

Ahh I see. I was wrong with isSuccess, sorry for that. The problem is react-query returns previous data under isSuccess with the flag isPreviousData set to true which is why this "fix" broke the loader again.
I've dug around some more and I think the most correct solution is simply using a negated isFetched:
        tableProps: {
            ...tablePropsSunflower,
            dataSource: data?.data,
            loading: liveMode === "auto" ? isLoading : !isFetched,
        ...

This attribute is false if we are loading new data (so the loading becomes true and the loader is shown), but is set to true if the cached data is already available (while react-query performs a background refetch).

This looks great. Congrats!
I'll send a PR about it on Monday. If you want, you can send it too!

Hey @IgnusG ,
We've released 2.4.11! Thank you


Compatability with vim-lsp

It's unclear from the documentation if this plugin will work with vim-lsp; I've got the following in my .vimrc file as per vim-lsp's documentation, however I'm still not having much luck. Does this plugin have a hard dependency on Rust and/or the LanguageClient-neovim? Because even the syntax highlighting isn't working by default (I need to manually enable it with):
:set syntax=reason
:syn on

This is in my .vimrc file;
au User lsp_setup call lsp#register_server({
    \ 'name': 'reason-language-server',
    \ 'cmd': ['/path/to/reason-language-server/reason-language-server.exe'],
    \ 'whitelist': ['reason', 'merlin'],
    \ 'blacklist': [],
    \ 'config': {},
    \ 'worpskace_config': {},
\})

I should probably mention I'm also using Vundle instead of vim-Plug, though the syntax seems identical (specifically):
" vundle
set rtp+=~/.vim/bundle/Vundle.vim
call vundle#begin()
" reasonml support
Plugin 'prabirshrestha/async.vim'
Plugin 'prabirshrestha/vim-lsp'
Plugin 'reasonml-editor/vim-reason-plus'
call vundle#end()

which I then install with :PluginInstall; Vim --version output in case it's needed;
VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Sep 30 2017 18:21:38)
Included patches: 1-197, 322, 377-378, 550, 703, 706-707
Modified by<EMAIL_ADDRESS>Compiled by<EMAIL_ADDRESS>Huge version without GUI.  Features included (+) or not (-):
+acl             +file_in_path    +mouse_sgr       +tag_old_static
+arabic          +find_in_path    -mouse_sysmouse  -tag_any_white
+autocmd         +float           +mouse_urxvt     +tcl
-balloon_eval    +folding         +mouse_xterm     +termguicolors
-browse          -footer          +multi_byte      +terminfo
++builtin_terms  +fork()          +multi_lang      +termresponse
+byte_offset     +gettext         -mzscheme        +textobjects
+channel         -hangul_input    +netbeans_intg   +timers
+cindent         +iconv           +num64           +title
-clientserver    +insert_expand   +packages        -toolbar
-clipboard       +job             +path_extra      +user_commands
+cmdline_compl   +jumplist        +perl            +vertsplit
+cmdline_hist    +keymap          +persistent_undo +virtualedit
+cmdline_info    +lambda          +postscript      +visual
+comments        +langmap         +printer         +visualextra
+conceal         +libcall         +profile         +viminfo
+cryptv          +linebreak       -python          +vreplace
+cscope          +lispindent      +python3         +wildignore
+cursorbind      +listcmds        +quickfix        +wildmenu
+cursorshape     +localmap        +reltime         +windows
+dialog_con      +lua             +rightleft       +writebackup
+diff            +menu            +ruby            -X11
+digraphs        +mksession       +scrollbind      -xfontset
-dnd             +modify_fname    +signs           -xim
-ebcdic          +mouse           +smartindent     -xpm
+emacs_tags      -mouseshape      +startuptime     -xsmp
+eval            +mouse_dec       +statusline      -xterm_clipboard
+ex_extra        +mouse_gpm       -sun_workshop    -xterm_save
+extra_search    -mouse_jsbterm   +syntax
+farsi           +mouse_netterm   +tag_binary
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
       defaults file: "$VIMRUNTIME/defaults.vim"
  fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H   -Wdate-time  -g -O2 -fdebug-prefix-map=/build/vim-R2d1UQ/vim-8.0.0197=. -fstack-protector-strong -Wformat -Werror=format-security -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: gcc   -L. -Wl,-z,relro -Wl,-z,now -fstack-protector -rdynamic -Wl,-export-dynamic -Wl,-E  -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -o vim        -lm -ltinfo -lnsl  -lselinux  -lacl -lattr -lgpm -ldl  -L/usr/lib -llua5.2 -Wl,-E  -fstack-protector-strong -L/usr/local/lib  -L/usr/lib/x86_64-linux-gnu/perl/5.24/CORE -lperl -ldl -lm -lpthread -lcrypt  -L/usr/lib/python3.5/config-3.5m-x86_64-linux-gnu -lpython3.5m -lpthread -ldl -lutil -lm -L/usr/lib/x86_64-linux-gnu -ltcl8.6 -ldl -lz -lpthread -lieee -lm -lruby-2.3 -lpthread -lgmp -ldl -lcrypt -lm

You can probably close this, Looks like the issue is that either vim-reason-plus doesn't work with Vundle, or LanguageClient-neovim doesn't work with vundle.


python311Packages.google-auth-oauthlib build failure on x86_64-linux as of 8769e848

Issue description
Build of python311Packages.google-auth-oauthlib failed on x86_64-linux as of 8769e84829f202177373676db04ccd8f645c9ece. This is currently breaking python3Packages.flax.
error: builder for '/nix/store/f70x4dhqljx1xgaxyq6ivfr7km6jhkvp-python3.11-google-auth-oauthlib-1.1.0.drv' failed with exit code 1;
       last 10 log lines:
       >
       > tests/unit/test_flow.py:433
       >   /build/google-auth-oauthlib-1.1.0/tests/unit/test_flow.py:433: PytestUnknownMarkWarning: Unknown pytest.mark.webtest - is this a typo?  You can register custom marks to avoid this warning - for details, see https://docs.pytest.org/en/stable/how-to/mark.html
       >     @pytest.mark.webtest
       >
       > -- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
       > =========================== short test summary info ============================
       > ERROR tests/unit/test_flow.py::TestInstalledAppFlow::test_run_local_server_occupied_port - OSError: [Errno 98] Address already in use
       > =================== 36 passed, 4 warnings, 1 error in 1.76s ====================
       > /nix/store/yq9qag5ak3w15nhcqplnhxpny6295l36-stdenv-linux/setup: line 1582: pop_var_context: head of shell_variables not a function context
       For full logs, run 'nix log /nix/store/f70x4dhqljx1xgaxyq6ivfr7km6jhkvp-python3.11-google-auth-oauthlib-1.1.0.drv'.
error: 1 dependencies of derivation '/nix/store/c0df676vkws447cbzsklcwhqwkppisvk-python3-3.11.7-env.drv' failed to build
error: 1 dependencies of derivation '/nix/store/6k1jzx93q184702wfrrf4jp31rwczfw5-python3.11-tensorboard-2.15.1.drv' failed to build
error: 1 dependencies of derivation '/nix/store/40i2slrybfzdr6bvmc807jnsv6zrqpvb-python3.11-tensorflow-gpu-2.13.0.drv' failed to build
error: 1 dependencies of derivation '/nix/store/pyakw0qdzark1982k1b90mhmq3mh4h1f-python3.11-flax-0.7.5.drv' failed to build

full build log
python3Packages.flax maintainers cc: @ndl
python311Packages.google-auth-oauthlib maintainers cc: @terlar
Other cc: n/a
Steps to reproduce

Checkout nixpkgs at commit 8769e84829f202177373676db04ccd8f645c9ece
Run nix-build -A python311Packages.google-auth-oauthlib

Technical details
 - system: `"x86_64-linux"`
 - host os: `Linux 6.2.0-1019-azure, Ubuntu, 22.04.3 LTS (Jammy Jellyfish), nobuild`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.16.1`
 - nixpkgs: `/nix/store/491b8x5f2zvli995wb9dk8226hh42iwk-source`

Contents of ~/.config/nixpkgs/config.nix:
{ allowUnfree = true; cudaSupport = true; cudaCapabilities = ["8.0"]; }

Misc.
This issue was automatically generated by nixpkgs-upkeep.

CI workflow that created this issue.
Internal tags:<PHONE_NUMBER>633614504 -6229576852457539614

I could not reproduce this, when I built the package it worked. Could it perhaps be some impurities in those tests? It seems it is some kind of port conflict (which the test seems to test).


Remove "-dev" suffix from "program" binary packages

This tracks "debbin" separately from "debsrc" so that the "-dev" suffix can be added only when "-type" is not "program" (because if the program name is "foo", then a binary package name of "foo-dev" is usually not going to be correct).

Thanks!

Glad I could find some little stuff to help with! :smile:


Add karma test

@incuna/js
repo is now ready to have karma tests.

@wytrych  i think ive addressed everything now please rereview. thanks

Cool, HWTI


Change plugins manager buttons from disabled/enabled to enable/disable (Trac #92)

Migrated from http://microfluidics.utoronto.ca/microdrop/ticket/92
{
    "status": "closed",
    "changetime": "2014-04-17T19:39:43",
    "description": "",
    "reporter": "ryan",
    "cc": "",
    "resolution": "fixed",
    "_ts": "1397763583719301",
    "component": "microdrop",
    "summary": "Change plugins manager buttons from disabled/enabled to enable/disable",
    "priority": "minor",
    "keywords": "",
    "version": "0.1",
    "time": "2012-04-03T15:05:48",
    "milestone": "Microdrop 1.0",
    "owner": "",
    "type": "defect"
}

Trac update at 20120403T15:10:59:

<EMAIL_ADDRESS>commented:

commit b9008edb2c1a3d1a749c1529f02672d45c735c3d
Author: Ryan Fobel<EMAIL_ADDRESS>Date:   Tue Apr 3 11:07:00 2012 -0400
Change plugin disabled/enabled to enable/disable

Fixes #96.

<EMAIL_ADDRESS>changed resolution from "" to "fixed"
<EMAIL_ADDRESS>changed status from "new" to "closed"

Trac update at 20140417T19:39:43: ryan changed component from "" to "microdrop"


Fix Launcher project rebuilding with no changes

Description
The CopyToOutputDirectory build setting for Python.Runtime.dll.config has been changes from
Always to PreserveNewest.
Motivation and Context
The unnecessary build of Lean Launcher project with no changes.
Requires Documentation Change
No.
How Has This Been Tested?
Local build.
Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Non-functional change (xml comments/documentation/etc)

Checklist:

[x] My code follows the code style of this project.
[x] I have read the CONTRIBUTING document.
[x] All new and existing tests passed.
[x] My branch follows the naming convention bug-<issue#>-<description> or feature-<issue#>-<description>

w
Sent from my iPhone

On May 6, 2019, at 06:27, Stefano Raggi<EMAIL_ADDRESS>wrote:
Description


feat: use forked genawaiter

genawaiter is unmaintained. Forked and published as genawaiter2 https://github.com/arrow-udf/genawaiter https://crates.io/search?q=genawaiter2
now users of arrow-udf macro doesn't need to add genawaiter in their dependencies. Core change: https://github.com/arrow-udf/genawaiter/pull/2

Published arrow-udf-wasm crate, but I don't have the permission for arrow-udf crate. @wangrunji0408 Can you help me? Maybe we can add a team under arrow-udf org.

Published arrow-udf-wasm crate, but I don't have the permission for arrow-udf crate. @wangrunji0408 Can you help me? Maybe we can add a team under arrow-udf org.

I forget to add owner risingwavelabs:crates-io to this crate. However, I don't have permission now. 🤡
Just published this crate and invited you as an owner.


Modify multiple headers with the same content rule

As is, the repeated sections in the Changelog cause the build to break.

Set the allow_different_nesting parameter to true
rule 'MD024', :allow_different_nesting => true
See https://github.com/markdownlint/markdownlint/blob/main/docs/RULES.md#md024---multiple-headers-with-the-same-content

Make sure that Added, Changed, Fixed are a heading level below the version they refer to, i.e.:
[1.2.0]
Added
Changed

Released with version 1.3.0


Report format up

Please add your write-ups as TeX files by subsection in the text_files directory. Organize by topic (question you answered), NOT by the method you used.

[ ] 0 Abstract(Karen)
[x] 1 Introduction (Victor, Karen)
[x] 2 Data (Victor)
[x] 5.1 Discussion of Results
[ ] 5.2 Discussion of Future Work(Karen)

Put your name in parentheses after the bulletpoint to "call dibs" on a section. If there are more than one person working on a section, try to coordinate. Also add your own subsections under 3 Methods and 4 Results.

Don't erase names.

Please write your name too. Don't just check the box.


test: Add integration tests to exercise the Lambda subscriptions

Issue #, if available: DOTNET-6922
Description of changes: Adds integration tests that create actual SQS queues mapped to Lambda functions.
Addressed feedback on https://github.com/awslabs/aws-dotnet-messaging/pull/52 at the time it was closed (due to us stopping and then restarting this ticket now). I couldn't re-open since I rebased the branch on dev.
The majority of this is the scaffolding, right now the tests are just testing either a single successful or single failing message against ProcessLambdaEventAsync and ProcessLambdaEventWithBatchResponseAsync. But it's easier to iterate on tests now that the setup is in place, so open to feedback if you think we should add additional test cases.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Overall I am fine with the testing approach that we are taking. But I'd like to see 2 additional logical pieces being exercised (should be easy to add since the AWSUtilities and TestUtilities does most of the heavy lifting)
* Verify that the message source is correctly resolved from `AWS_LAMBDA_FUNCTION_NAME` environment variable

  * Log the message source to cloudwatch and assert on it.

* Verify FIFO processing of messages

  * Process 3 or more messages (belonging to the same group)  from a FIFO queue and log their `ProcessEnd` times to CloudWatch. Assert that they were processed in the same order in which they were published.

Added FIFO tests in https://github.com/awslabs/aws-dotnet-messaging/pull/71/commits/c416d617262ad4dea9ffd9ebee0905eb6e7fd0c3.
I started going down the path of testing the message source, but currently we're not actually sending any messages from the Lambda function. I started a "bidirectional" test where we'd message the Lambda and then it'd reply with a forwarded message that we can assert the source on the client. But we'd have to expand the IAM permissions given to the Lambda to allow publishing (with the queueURL), as well as run a poller on the client. Overall it was feeling like more effort and setup code/time than it was worth.


Inconsistency with PointwiseMultiplication for SparseMatrix

In-place pointwise multiplication produces different results for DenseMatrix than it does for SparseMatrix.
example:
Matrix x = SparseMatrix.OfDiagonalArray(new double[] {1, 2, 3, 2});
Matrix y = DenseMatrix.OfDiagonalArray(new double[] {2, 1, 3, 2});
y.PointwiseMultiply(x, y);
Console.WriteLine(y);

produces the following output
DenseMatrix 4x4-Double
2  0  0  0
0  2  0  0
0  0  9  0
0  0  0  4

while for SparseMatrix, the output of the following code
Matrix x = SparseMatrix.OfDiagonalArray(new double[] {1, 2, 3, 2});
Matrix y = DenseMatrix.OfDiagonalArray(new double[] {2, 1, 3, 2});
x.PointwiseMultiply(y, x);
Console.WriteLine(x);

is
SparseMatrix 4x4-Double 0.00 % Filled
0  0  0  0
0  0  0  0
0  0  0  0
0  0  0  0

I have only tested this with matrices of doubles.
The root of this seems to be in the implementation of DoPointwiseMultiply() which calls Clear() on the result without checking whether or not the result matrix is one of the operands.
One would expect that the results are the same for SparseMatrix and DenseMatrix or at least an exception be thrown if this behaviour is not supported.

Should be fixed in PR #912

Released in 5.0.0-beta2 - thank you both for reporting and for the patch!


Comprehensive Resting Functionality

As of recently, the invaluable Rest Recovery 5E module by Wasp is no longer being maintained. https://foundryvtt.com/packages/rest-recovery
For quite a while this module has filled the gaps in providing a robust, community guided, set of options and functionality around streamlining the resting process and how class features, feats, items affect and are affected by resting. It also includes food and water consumption tracking for those who like a bit more realism for dungeon/hex crawls.
I'm not sure how feasible it would be just to integrate this into dnd5e as it stands, perhaps even temporarily, to keep this functionality available with the fast-changing system. If not, at least it can maybe provide some guidance around what has proven popular and necessary in this regard – and now that it is potentially winding down that may affect your priorities.

I second this. The module got to be extensive in its functionality, though, so I don't know if it would be a good fit for all of it to be incorporated into the DND5E system. Stuff like the Simple Calendar integration or Food & Water tracking might remain module territory. But basic HP recovery, Hit Dice recovery and expenditure, feature and spell recovery, item recharge, and exhaustion recovery would be most appreciated!

Yea, being able to make features or way to restore x amount of spell slots on rest through some features, for various different classes is something that feels like it should be supported, Rest Recovery did it a bit, but stuff like Song of Rest, Arcane Recovery, Natural Recovery from Land Druid, etc

I agree with the previous exposed points, Rest Recovery fills a lot of gaps even letting you add some homebrew rules on it.
Item charges, food & water, feature and spell recharges are an important part of core that can even help setting a good base for future official adventures/modules

I've had this module for so long that I forgot some of its features weren't part of core, but having the nice hit die ui during rests is something that makes rests in the middle of a session quick to perform and prevents them form derailing gameplay for more than a few moments.
Would be great to also see some form of incorporation of features like arcane recover or land harness divine power to restore spell slots or resources, even if it is nor necessarily part of the short/long rest workflow.

A great module that really should be folded into core!

Definitely a must for this system.

Please, please please please please incorporate this module into core!!!


Airlock allows to submit more than 1 file although it's not supported

Describe the bug
Currently we can upload more than 1 file to the Airlock request container, however, if we submit a request that contains more than 1 file, it will get stuck on "submitted" status.
Steps to reproduce

create an Airlock request
upload 2 files
submit the request - the request status will be stuck on "submitted"

This cannot be checked from the API, import requests can be supported but we need to add a private endpoint to the storage account for them to work.
Export requests are not supported at all, as the API cannot reach the export storage account (which is in the workspace).
see https://github.com/microsoft/AzureTRE/issues/2270


center

How will I get the center pitch and yaw value?

The getPitch() and getYaw() API methods.

No, actually I want if I click any hotspot in 360Image, it should automatically be centered, so that hotspot can't be hidden if hotspot is placed just near by corner.

I achieved it by using lookAt method.
viewer.lookAt(parseInt(hs.pitchValue), parseInt(hs.pitchYaw))


docs: PR#60 – Update README.md(remove front matter layout)

Success with home page after removing 'layout: home' from front matter.
I suspect that may be the problem with the blog posts.


Remove likely and unlikely from intrinsics shim

They are now implemented in MIR interpreter by rust-lang/rust#73778

Thanks. :)
@bors r+

:pushpin: Commit c5b324b031c1152c558737928cb345d07a1e5b82 has been approved by RalfJung

:hourglass: Testing commit c5b324b031c1152c558737928cb345d07a1e5b82 with merge 86a7c555ed5577d08c37fe1a0d7664d105620a29...

:sunny: Test successful - checks-travis, status-appveyor
Approved by: RalfJung
Pushing 86a7c555ed5577d08c37fe1a0d7664d105620a29 to master...


Use temp file as a download target

Using temp files allows avoiding incomplete files, e.g. due to cancelled download process, especially on large video files.

Pull Request Test Coverage Report for Build 142

3 of 3 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 141:
0.0%

Covered Lines:
450

Relevant Lines:
450

💛  - Coveralls

@ndbroadbent any chance to get this PR reviewed and merged soon?

Thanks @AndreyNikiforov and @menkej! Yeah this looks great, I will merge it now

Released in 1.5.1


SwitchNode breaks down after extensive looping

Using an extensive loop over ~1000 elements (batch processing of multiple files) crashes the SwitchNode at seemingly random intervals.
Something bad happened in when executing Switch-5.
Input not set for node.

Timing problem?

Could be a synchronization issue. Can you try switching the comments in line 193 and 194 in runner.py. That way the interpreter will run all nodes in the main thread. If that solves the problem I know synchronization is the problem.

Works perfectly without parallelization! Also, the node setup is done with a few seconds rather than a few minutes!

Interesting. Can you send me a screen shot of the node setup, too. That could be helpful for finding the bottleneck.

Here you go (overview & detailed). As you see, more complex setups are possible :)

:

Thanks. I never tested larger setups.
I am currently on vacation. When I am back, I will probably need a dedicated Floppy fixing week..

I thought about this issue. There are definitively some problems with synchronization in the current version that I need to fix. But I also thought about changing concurrent node execution from 'opt-out' to 'opt-in' meaning that nodes won't be run concurrently by default but only when the node was decorated with an '@parallelNode' decorator. The previous idea was to have a '@sequentialNode' decorator for all nodes that are not supposed to run concurrently.
I consider this because a lot of nodes do trivial things like splitting a string, adding numbers, implement looping, etc. These nodes do not benefit from concurrency at all because the overhead added by creating threads for them is bigger than the benefit of having their own thread. In fact, in many cases there is no benefit at all.
If I choose the 'opt-in' approach, the person writing a node knows whether the global interpreter lock is released within the 'run' method and if it is the person can make that node run concurrently.
I assume this would greatly improve performance for graphs that consist mainly of 'generic' nodes but I would like to get some feedback before changing things.
PS: I guess I could also implement something like a 'force concurrency' and/or 'force sequential execution' option for the interpreter to override node specific behavior.

I gave this some thought and examined my larger setups. Most things run in a sequential manner anyways. There are some computational more expensive things, like breaking down a structure or sorting algorithms, and I think it should be up to the programmer to decide which parts can be reasonably done in parallel. Therefore, I think that the opt-in is probably the better way to go with things.

This should be fixed in newer versions. Older versions had synchronization issues that are fixed now.
New versions allow to switch between parallel and sequential execution mode via the settings menu.


Device Model <=> Device tree? Control model tree <=> class tree <=> control model?

For consistency with MS-05-01 definitions of Device Model and Control Model:
The term "Device tree" is used in this document e.g. https://github.com/AMWA-TV/ms-05-02/blame/359515b1e7be1327271cbbaa21b66d102560d1fc/docs/Blocks.md#L5
For consistency with MS-05-01 should this not be "Device Model"?  If the "Device tree" is different to the "Device Model" it should be defined as such in this doc, otherwise I feel that "Model" should be substituted for "tree" in this doc.
In the Blocks description there is the use of "Control model tree" https://github.com/AMWA-TV/ms-05-02/blame/9323b636ecb1f960e575d3bd364925281f29733d/docs/NcObject.md#L17
Should this be simply "Control Model"?
Also in the WebIDL there are uses of "class tree" which should be "Control Model" I think
https://github.com/AMWA-TV/ms-05-02/blame/359515b1e7be1327271cbbaa21b66d102560d1fc/idl/NC-Framework.webidl#L52

Just checked to see if there were any "trees" remaining and found a couple:
Suggest changing "class tree" to "control model" here:
https://github.com/AMWA-TV/ms-05-02/blob/1b71245e74c486385f3ae48cee2baf47712f4a11/docs/Framework.md?plain=1#L103
Suggest changing "control model class tree" to "control model" here:
https://github.com/AMWA-TV/ms-05-02/blob/1b71245e74c486385f3ae48cee2baf47712f4a11/docs/Framework.md?plain=1#L323
But I think all the others have been dealt with


Cannot use ethers-rs as dependency (E0034)

Version
ethers-rs:
ethers-test v0.1.0 (/home/dev/repos/rust/ethers-test)
└── ethers v0.2.0 (https://github.com/gakonst/ethers-rs#457c6465)
    ├── ethers-contract v0.2.0 (https://github.com/gakonst/ethers-rs#457c6465)
    │   ├── ethers-contract-abigen v0.2.0 (https://github.com/gakonst/ethers-rs#457c6465)
    │   │   ├── ethers-core v0.2.0 (https://github.com/gakonst/ethers-rs#457c6465)
    │   ├── ethers-contract-derive v0.2.0 (proc-macro) (https://github.com/gakonst/ethers-rs#457c6465)
    │   │   ├── ethers-contract-abigen v0.2.0 (https://github.com/gakonst/ethers-rs#457c6465) (*)
    │   │   ├── ethers-core v0.2.0 (https://github.com/gakonst/ethers-rs#457c6465) (*)
    │   ├── ethers-core v0.2.0 (https://github.com/gakonst/ethers-rs#457c6465) (*)
    │   ├── ethers-providers v0.2.0 (https://github.com/gakonst/ethers-rs#457c6465)
    │   │   ├── ethers-core v0.2.0 (https://github.com/gakonst/ethers-rs#457c6465) (*)
    ├── ethers-core v0.2.0 (https://github.com/gakonst/ethers-rs#457c6465) (*)
    ├── ethers-middleware v0.2.0 (https://github.com/gakonst/ethers-rs#457c6465)
    │   ├── ethers-contract v0.2.0 (https://github.com/gakonst/ethers-rs#457c6465) (*)
    │   ├── ethers-core v0.2.0 (https://github.com/gakonst/ethers-rs#457c6465) (*)
    │   ├── ethers-providers v0.2.0 (https://github.com/gakonst/ethers-rs#457c6465) (*)
    │   ├── ethers-signers v0.2.0 (https://github.com/gakonst/ethers-rs#457c6465)
    │   │   ├── ethers-core v0.2.0 (https://github.com/gakonst/ethers-rs#457c6465) (*)
    ├── ethers-providers v0.2.0 (https://github.com/gakonst/ethers-rs#457c6465) (*)
    └── ethers-signers v0.2.0 (https://github.com/gakonst/ethers-rs#457c6465) (*)

rustc:
rustc 1.50.0 (cb75ad5db 2021-02-10)

Platform
Linux dev 5.8.0-43-generic #49~20.04.1-Ubuntu SMP Fri Feb 5 09:57:56 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Description
Adding ethers-rs as dependency to a freshly created Rust project results in an error.
Steps to reproduce

cargo init in an empty directory
add ethers = { git = "https://github.com/gakonst/ethers-rs" } to the dependencies section as instructed
cargo build

Expected result
The project should compile successfully.
Actual result
Compilation fails with errors:
error: aborting due to 43 previous errors

Some errors have detailed explanations: E0034, E0308.
For more information about an error, try `rustc --explain E0034`.
error: could not compile `bitvec`

To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
error: build failed

Note
Instead of installing from GitHub, I've also tried using the published crate by adding ethers = "0.2.0" instead, but resulted in the same errors.
I can compile the ethers-rs repository without issues. However, the same errors show up once I remove the Cargo.lock file. This looks like a dependency issue.

As a temporary measure you can try adding the following to your Cargo.toml
funty = "=1.1.0"

This should be fixed in master: https://github.com/gakonst/ethers-rs/blob/master/Cargo.lock#L825-L829, added the pin to ethers-core, does it work for you?

Thanks for the quick reply!
@prestwich Unfortunately the workaround doesn't seem to work.
@gakonst The library's lock file does fix the build for ethers-rs itself, but it didn't help with the case when it's used as a dependency.
According to the Cargo book, the lock file of a library is ignored when dependent upon, and thus should be ignored from version control.
As for the pin, it's indeed working now. Thanks for the fix. I pulled the repo right before that commit so I missed it :)

Closing the issue since it's been fixed in commit a43299c838db31d050f702087d1eeaf46121ee6a

Thanks! This was tracked here https://github.com/myrrlyn/funty/issues/3

My Cargo.toml:
[dependencies]
ethers = { git = "https://github.com/gakonst/ethers-rs" }

Result after run cargo update
$cargo update
Updating git repository `https://github.com/gakonst/ethers-rs`
error: no matching package named `ethers` found
location searched: https://github.com/gakonst/ethers-rs

Try "rustup update", you might be on old rust version

Try "rustup update", you might be on old rust version

Worked perfectly!
Thank you so much!


Colored on and off states, as well as pan color transition

Optionally the Switch can be created with on and off colors for the background of the switch image (which transparent switch images can take advantage of).
In addition, the colors will transition between one another both on a tap gesture (where the state is animated) as well as the pan gesture (where the color is interactive and reflects the state of the transition between on and off states)

:+1:


Error in step: Install Jest for Component Unit Tests

no matches found<EMAIL_ADDRESS>From what I could google there seems to be some naming issues with Babel 7, but I'm not sure what the solution is. I tried<EMAIL_ADDRESS>as suggested elsewhere, but that didn't work either. Does command suggested here work for anyone?

Thanks, I'll check this in a moment. It worked 2 days ago.

Hey, @jcdescy could you give me reproduction steps and screenshots with your problem. I just rerun steps and this package is downloadable.

I do everything as laid out in the Readme here and everything works fine until I get to this step. Sadly "no matches found<EMAIL_ADDRESS>is really all I get. I'm on a Mac, if this is helpful.
From what I understand, this is a bridge between Babel 6 and Babel 7. Do I even need this, if I haven't worked with Babel before?  I'm a backend guy and pretty new to frontend development.

Hello, @jcdescy
Works fine for me.
MacOS
node -v v14.4.0
yarn -v 1.22.4
Shared screen fo you:

Hello, @jcdescy
I could not reproduce this error and therefore recorded a small video of how to create app step by step https://asciinema.org/a/ArqvGrc6JK6pKzlRTMV3Jotwr?t=8:44

no matches found<EMAIL_ADDRESS>From what I could google there seems to be some naming issues with Babel 7, but I'm not sure what the solution is. I tried<EMAIL_ADDRESS>as suggested elsewhere, but that didn't work either. Does command suggested here work for anyone?

Did you manage to fix that? having the same issue... no matches found<EMAIL_ADDRESS>

No, sorry. I have no idea and sadly have no capacities to look into it any further. I switched to Laravel for several unrelated reasons. If there is something specific you want me to try or look at, I still have the project on my drive and I'd be glad to help. But as I said I currently have neither capacity nor reason to investigate this any further on my own.


Alignment issue in the Header component

Current state

Expected state
If this appears to be a legitimate issue, kindly categorize it under "hacktoberfest" and assign it to me for further attention. @EbonyLouis Thank you in advance!

@captain-Akshay Good find! I've assigned it to you 😄.
I'd like to note that Hacktoberfest officially kicks off on October 1st. Contributions made before the event may not be eligible for the challenge. However, feel free to start working on it, but I'd recommend holding off on submitting your PR until the event begins.

To be eligible for Hacktoberfest's official prizes make sure you're registered, registration is now OPEN.

Reach out if you need any help 🥳

@LynxSumit Hey thank you for the enthusiasm, lets give the original contributor a chance to resolve this issue. We have other open Hacktoberfest tagged issues that you might find interesting.

developer.tbd.website
web5-js
dwn-server
dwn-sdk-js

Also, we'll be adding more issues throughout the month of October, so there will be plenty of opportunities to jump in. If for any reason the current assignee can't proceed with this one, I'll definitely keep you both in mind and reach out. keep an eye on our events-and-updates channel in discord. Thanks for spending Hacktoberfest with us! 🍁

this bug was driving me crazy! thanks for looking into it


CORE-7101 Current sandbox thread local

Create SandboxGroupContextService to set, get and remove the current SandboxGroupContext on a thread.
This service can then be OSGI injected into other services to retrieve the current sandbox. The thead local concept is private to the service.
Rename the existing SandboxGroupContextService to SandboxGroupService.

Closed so I can create another PR that does the rename separately. Will reopen once that is merged.


[Device Support Request] _TZE200_zivfvd7h TS0601 Qiumi/Siterwell QM-GS361A-H04 TRV

Is your feature request related to a problem? Please describe.
I bought a Zigbee TRV off Amazon (https://www.amazon.co.uk/gp/product/B08357D6LJ/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8&psc=1), marketed as a "Qiumi Smart TRV", but is labelled "GS361A-H04" by Siterwell Electronics on the device itself. It joined the network, but it did not pick up a quirk to make it work correctly in ZHA.
Describe the solution you'd like
I added ("_TZE200_zivfvd7h", "TS0601"), to the MoesHY368 signature at line 180 in tuya/valve.py to make the TRV appear in HA. It seems to work fine - I can set the required temperature on the device, and it reports back - so you may want to consider adding this modification to that file.
Device signature - this can be acquired by removing the device from ZHA and pairing it again from the add devices screen. Be sure to add the entire content of the log panel after pairing the device to a code block below this line.
This is the log after I got after the change to valve.py.
[0xcb0b] Extending timeout for 0x06 request
[0xcb0b] Node Descriptor: NodeDescriptor(byte1=2, byte2=64, mac_capability_flags=128, manufacturer_code=4098, maximum_buffer_size=82, maximum_incoming_transfer_size=82, server_mask=11264, maximum_outgoing_transfer_size=82, descriptor_capability_field=0)
[0xcb0b] Discovering endpoints
Tries remaining: 3
[0xcb0b] Extending timeout for 0x07 request
[0xcb0b] Discovered endpoints: [1]
[0xcb0b:1] Discovering endpoint information
Tries remaining: 3
[0xcb0b] Extending timeout for 0x08 request
[0xcb0b:1] Discovered endpoint information: SizePrefixedSimpleDescriptor(endpoint=1, profile=260, device_type=81, device_version=1, input_clusters=[0, 4, 5, 61184], output_clusters=[25, 10])
Unknown cluster 61184
[0xcb0b] Extending timeout for 0x09 request
[0xcb0b:1:0x0000] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=9 command_id=Command.Read_Attributes_rsp>
[0xcb0b:1] Manufacturer: _TZE200_zivfvd7h
[0xcb0b:1] Model: TS0601
Checking quirks for _TZE200_zivfvd7h TS0601 (5c:02:72:ff:fe:c3:e3:7c)
Considering <class 'zhaquirks.tuya.valve.MoesHY368'>
Found custom device replacement for 5c:02:72:ff:fe:c3:e3:7c: <class 'zhaquirks.tuya.valve.MoesHY368'>
device - 0xCB0B:5c:02:72:ff:fe:c3:e3:7c entering async_device_initialized - is_new_join: True
device - 0xCB0B:5c:02:72:ff:fe:c3:e3:7c has joined the ZHA zigbee network
[0xCB0B](TS0601): started configuration
[0xCB0B:ZDO](TS0601): 'async_configure' stage succeeded
[0xCB0B:1:0x0201]: bound 'thermostat' cluster: Status.SUCCESS
[0xCB0B:1:0x0201]: attr reporting for '{'local_temp': (30, 900, 25), 'occupied_cooling_setpoint': (30, 900, 25), 'occupied_heating_setpoint': (30, 900, 25), 'unoccupied_cooling_setpoint': (30, 900, 25)}' on 'thermostat': ConfigureReportingResponseRecord(status=0)
[0xCB0B:1:0x0201]: attr reporting for '{'unoccupied_heating_setpoint': (30, 900, 25), 'running_mode': (30, 900, 25), 'running_state': (30, 900, 5), 'system_mode': (30, 900, 25)}' on 'thermostat': ConfigureReportingResponseRecord(status=0)
[0xCB0B:1:0x0201]: attr reporting for '{'occupancy': (30, 900, 1), 'pi_cooling_demand': (30, 900, 5), 'pi_heating_demand': (30, 900, 5)}' on 'thermostat': ConfigureReportingResponseRecord(status=0)
[0xCB0B:1:0x0201]: finished channel configuration
[0xCB0B:1:0x0001]: bound 'power' cluster: Status.SUCCESS
[0xCB0B:1:0x0001]: reporting 'battery_voltage' attr on 'power' cluster: 3600/10800/1: Result: '[ConfigureReportingResponseRecord(status=0)]'
[0xCB0B:1:0x0001]: reporting 'battery_percentage_remaining' attr on 'power' cluster: 3600/10800/1: Result: '[ConfigureReportingResponseRecord(status=0)]'
[0xCB0B:1:0x0001]: finished channel configuration
[0xcb0b] Extending timeout for 0x0a request
[0xcb0b] Extending timeout for 0x0b request
[0xCB0B:1:0x0000]: bound 'basic' cluster: Status.SUCCESS
[0xCB0B:1:0x0000]: finished channel configuration
[0xCB0B:1:0x0019]: bound 'ota' cluster: Status.SUCCESS
[0xCB0B:1:0x0019]: finished channel configuration
[0xCB0B:1:0x0201]: 'async_configure' stage succeeded
[0xCB0B:1:0x0001]: 'async_configure' stage succeeded
[0xCB0B:1:0x0000]: 'async_configure' stage succeeded
[0xCB0B:1:0x0019]: 'async_configure' stage succeeded
[0xCB0B](TS0601): completed configuration
[0xCB0B](TS0601): stored in registry: ZhaDeviceEntry(name='_TZE200_zivfvd7h TS0601', ieee='5c:02:72:ff:fe:c3:e3:7c', last_seen=1611342996.7547195)
[0xCB0B](TS0601): started initialization
[0xCB0B:ZDO](TS0601): 'async_initialize' stage succeeded
[0xCB0B:1:0x0201]: initializing channel: from_cache: False
[0xCB0B:1:0x0201]: read attributes: Success: {}. Failed: {'abs_min_heat_setpoint_limit': <Status.UNSUPPORTED_ATTRIBUTE: 134>, 'abs_max_heat_setpoint_limit': <Status.UNSUPPORTED_ATTRIBUTE: 134>, 'abs_min_cool_setpoint_limit': <Status.UNSUPPORTED_ATTRIBUTE: 134>, 'abs_max_cool_setpoint_limit': <Status.UNSUPPORTED_ATTRIBUTE: 134>}
[0xCB0B:1:0x0201]: read attributes: Success: {}. Failed: {'max_cool_setpoint_limit': <Status.UNSUPPORTED_ATTRIBUTE: 134>, 'max_heat_setpoint_limit': <Status.UNSUPPORTED_ATTRIBUTE: 134>, 'min_cool_setpoint_limit': <Status.UNSUPPORTED_ATTRIBUTE: 134>, 'min_heat_setpoint_limit': <Status.UNSUPPORTED_ATTRIBUTE: 134>}
[0xCB0B:1:0x0201]: Attribute report 'SiterwellThermostat'[ctrl_seqe_of_oper] = ControlSequenceOfOperation.Heating_Only
[0xCB0B:1:0x0201]: read attributes: Success: {'ctrl_seqe_of_oper': <ControlSequenceOfOperation.Heating_Only: 2>}. Failed: {'local_temp': <Status.UNSUPPORTED_ATTRIBUTE: 134>, 'occupancy': <Status.UNSUPPORTED_ATTRIBUTE: 134>, 'occupied_cooling_setpoint': <Status.UNSUPPORTED_ATTRIBUTE: 134>}
[0xCB0B:1:0x0201]: read attributes: Success: {}. Failed: {'occupied_heating_setpoint': <Status.UNSUPPORTED_ATTRIBUTE: 134>, 'pi_cooling_demand': <Status.UNSUPPORTED_ATTRIBUTE: 134>, 'pi_heating_demand': <Status.UNSUPPORTED_ATTRIBUTE: 134>, 'running_mode': <Status.UNSUPPORTED_ATTRIBUTE: 134>}
[0xCB0B:1:0x0201]: read attributes: Success: {}. Failed: {'running_state': <Status.UNSUPPORTED_ATTRIBUTE: 134>, 'system_mode': <Status.UNSUPPORTED_ATTRIBUTE: 134>, 'unoccupied_heating_setpoint': <Status.UNSUPPORTED_ATTRIBUTE: 134>, 'unoccupied_cooling_setpoint': <Status.UNSUPPORTED_ATTRIBUTE: 134>}
[0xCB0B:1:0x0201]: finished channel configuration
[0xCB0B:1:0x0001]: initializing channel: from_cache: False
[0xCB0B:1:0x0001]: finished channel configuration
[0xCB0B:1:0x0000]: initializing channel: from_cache: False
[0xCB0B:1:0x0000]: finished channel configuration
[0xCB0B:1:0x0019]: initializing channel: from_cache: False
[0xCB0B:1:0x0019]: finished channel configuration
[0xCB0B:1:0x0201]: 'async_initialize' stage succeeded
[0xCB0B:1:0x0001]: 'async_initialize' stage succeeded
[0xCB0B:1:0x0000]: 'async_initialize' stage succeeded
[0xCB0B:1:0x0019]: 'async_initialize' stage succeeded
[0xCB0B](TS0601): power source: Battery or Unknown
[0xCB0B](TS0601): completed initialization
[0xcb0b:1:0x000a] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=False disable_default_response=False> manufacturer=None tsn=107 command_id=Command.Read_Attributes>
[0xcb0b:1:0x000a] ZCL request 0x0000: [[7]]

Additional context
Home Assistant 2021.1.4, FreeBSD 12.2-RELEASE, Python 3.9.1, Zzh! CC2652 Zigbee USB Stick.

I have making on pull request with the change and its going in the dev branch then its being merged.
Thanks for helping adding unsupported device in our systems !!!

I have making on pull request with the change and its going in the dev branch then its being merged.
Thanks for helping adding unsupported device in our systems !!!

That's great, thank you very much!
As aside, I've been looking in my HA logs, and noticed that I get the following warning every now and again:
WARNING (MainThread) [zigpy.zcl] [0xcb0b:1:0xef00] Unknown cluster-specific command 36
After digging around, this appears to be a time synchronisation request by the TRV, as detailed here: https://developer.tuya.com/en/docs/iot/device-development/embedded-software-development/mcu-development-access/zigbee-general-solution/tuya-zigbee-module-uart-communication-protocol?id=K9ear5khsqoty#title-12-Time synchronization. As I understand it, since the quirk only handles commands 0x00, 0x01 and 0x02 in cluster 0xEF00, this command is unhandled.
It doesn't seem to affect the operation, since I'm not intending to use the TRV's built-in automatic mode, but it might be something to consider investigating further in the future. If I can help with that, let me know.

That's great, thank you very much!
As aside, I've been looking in my HA logs, and noticed that I get the following warning every now and again:
WARNING (MainThread) [zigpy.zcl] [0xcb0b:1:0xef00] Unknown cluster-specific command 36
After digging around, this appears to be a time synchronisation request by the TRV, as detailed here: https://developer.tuya.com/en/docs/iot/device-development/embedded-software-development/mcu-development-access/zigbee-general-solution/tuya-zigbee-module-uart-communication-protocol?id=K9ear5khsqoty#title-12-Time synchronization. As I understand it, since the quirk only handles commands 0x00, 0x01 and 0x02 in cluster 0xEF00, this command is unhandled.
It doesn't seem to affect the operation, since I'm not intending to use the TRV's built-in automatic mode, but it might be something to consider investigating further in the future. If I can help with that, let me know.

I have the same TRV but the other model and all commands is not implanted and the dev dont have any TRV so not easy getting it solved. I dont have the time sync problem but i only using the manual mode from AH and changing the temperature.
Its one or 2 more devs starting implanting TRVs with more functions and if there is being merged its easier using there functions and implanting them.
Look on the other not merged PR if you is finding how is done and trying it on yours and its possible you get it working.

I have the same TRV but the other model and all commands is not implanted and the dev dont have any TRV so not easy getting it solved. I dont have the time sync problem but i only using the manual mode from AH and changing the temperature.
Its one or 2 more devs starting implanting TRVs with more functions and if there is being merged its easier using there functions and implanting them.
Look on the other not merged PR if you is finding how is done and trying it on yours and its possible you get it working.

Thank you for pointing me to the PR - I didn't spot that it was already being fixed!
Thanks for your efforts on this.

Thank you for pointing me to the PR - I didn't spot that it was already being fixed!
Thanks for your efforts on this.

Then look on Z2M somewhere I have reading disabling the Time.cluster_id, then the devices dont support the time function for not getting the error in the log.

Then look on Z2M somewhere I have reading disabling the Time.cluster_id, then the devices dont support the time function for not getting the error in the log.


Pressure issues with sediment solver

May relate to #907
Failure of the solver to maintain hydrostatic fluid pressure within the sediment phase. This seems to be a regression as we could do this with a previous version. In the image below, you can see the pressure field with the latest version of Proteus - with Entropy viscosity schemes for the sediment phase (left panel) against an earlier simulation with the ShockCapturing scheme and an earlier version of the code (174420ee70cc965b9b1828dc4982ac4e3fd9e21e)

@cekees @manuel-quezada this is what I get with the shock capturing scheme - running with the master version. I do not think the problem is the EV schemes but rather lies in the VOS / Pressure model.

@cekees @manuel-quezada After further investigation, it seems like it is the pressure friction terms causing these oscillations. Setting the limiter below the max theoretical limits improves things. Further investigating.

By setting the limiting fraction far enough from the theoretical packing density, the solution is much more well behaved. Note that inside the sediment, the hydrostatic pressure gradient is proportional to the weighted density of the fluid and the sediment, not the fluid phase. This is something that we need to look at, although I feel like it is more a convention, rather than a real problem

After looking at 3PSed2D, I am suspicious of the conversion of the sed equation in nonconservative form.
The old version (conservative, terms multiplied with vos) is here https://github.com/erdc/proteus/blob/bd0233c171bb9b122b9c27ddcd13539bacad743f/proteus/mprans/RANS3PSed2D.h
@cekees I have some questions:

Does the hamiltonian correspond to the form of the pressure that we have in the conservative equation? E.g. if the pressure term is multiplied by vos, should this one be too?
Same goes for the hamiltonian gradients
Whilst the drag terms have been divided by vos to be consistent with the nc form, the pressure friction terms do not appear to be

Does the hamiltonian correspond to the form of the pressure that we have in the conservative equation? E.g. if the pressure term is multiplied by vos, should this one be too?

No, I think I consistently divided through by vos. It completely cancels out of the time derivative, acceleration (Hamiltonian), gravitation, and pressure terms. That's basically why I did it, so that the equation remains well-behaved as vos -> 0.

Same goes for the hamiltonian gradients
Whilst the drag terms have been divided by vos to be consistent with the nc form, the pressure friction terms do not appear to be

Can you point me to what you mean by the pressure friction term?

I think when you pushed the conversion to nc form, the drag terms were changed (divided by vos)
https://github.com/erdc/proteus/blob/master/proteus/mprans/RANS3PSed.h#L866,
But the friction terms did not
https://github.com/erdc/proteus/blob/master/proteus/mprans/RANS3PSed.h#L914
https://github.com/erdc/proteus/blob/master/proteus/mprans/RANS3PSed.h#L928

@cekees - Addressed.
There was a term missing in the pressure friction stress which is the solid stress due to its own weight. See #916 that addresses the issue. There is a discussion of what these contact stresses mean - I am not sure that we need the friction "repulsive" stress now as we are limiting it numerically, and the only place where its gradient will have any relevance is at the interface (which is not meaningful as it is a numerical artifact).  Eventually, friction stresses will need update as well.

Will close - but further discussion is needed.


Align the extension according to Gardener's component checklist

How to categorize this PR?

/kind enhancement
What this PR does / why we need it:
This PR covers part of the items from component-checklist listed in #3:
More concretely it:

Defines RBAC roles for the extension controller with minimal privileges
Sets the seccomp profile to RuntimeDefault for the registry and registry-configuration-cleaner Pods
No longer runs the registry-configuration-cleaner Pod in privileged mode
Adds NetworkPolicy labels to the registry cache Pods

Which issue(s) this PR fixes:
Part of #3
Special notes for your reviewer:
N/A
Release note:

TBD

/test pull-gardener-extension-registry-cache-e2e-kind

/test pull-gardener-extension-registry-cache-unit
/test pull-gardener-extension-registry-cache-verify-image-build

/hold

/approve

/hold cancel


Update content/en/docs/concepts/cluster-administration/flow-control.md

Follow up on #34228
Updated the page API Priority and Fairness

Preview: https://deploy-preview-34231--kubernetes-io-main-staging.netlify.app/docs/concepts/cluster-administration/flow-control/#prioritylevelconfiguration:~:text=read in the-,enhancement proposal,-%2C but in short
I checked and confirm that the link works on preview.
/lgtm


How to use x264enc element?

I am trying to output my inference result through a RTSP server.  So my pipeline is something like:  file-source -> h264-parser -> decoder ->   gvadetect -> gvainference -> gvawatermark ->  encoder -> rtppay -> udpsink, where encoder is x264enc. When I executed my pipeline inside the openvino/ubuntu18_data_dev docker container, I got following error:
Traceback (most recent call last):
  File "rtsp_test.py", line 141, in <module>
    pipeline = Gst.parse_launch(gst_launch_string)
GLib.Error: gst_parse_error: no element "x264enc" (1)

I used gst-inspect-1.0 to check :
gst-inspect-1.0 x264enc
result is:
No such element or plugin 'x264enc'
Then, I used apt-get to install gstreamer1.0-plugins-ugly:amd64, which is supposed to comprise the x264enc. However, after installation, gst-inspect-1.0 still cannot find x264enc.
How can I get it work? Thanks in advance.

Can it be assumed that the installation of gstreamer1.0-plugins-ugly:amd64 went fine and you can find the installed files inside of your Docker container?
Then it looks like it's needed to extend the gstreamer plugin search-path - as the DL-Streamer plugins are deployed somewhere else than the binaries installed via apt-get.

Can it be assumed that the installation of gstreamer1.0-plugins-ugly:amd64 went fine and you can find the installed files inside of your Docker container?
Then it looks like it's needed to extend the gstreamer plugin search-path - as the DL-Streamer plugins are deployed somewhere else than the binaries installed via apt-get.

Can it be assumed that the installation of gstreamer1.0-plugins-ugly:amd64 went fine and you can find the installed files inside of your Docker container?
Then it looks like it's needed to extend the gstreamer plugin search-path - as the DL-Streamer plugins are deployed somewhere else than the binaries installed via apt-get.
(see e.g. the issue #173)
Thanks for your quick reply.

How could I make sure the installation went fine?

# dpkg -l | grep x264
ii  libx264-152:amd64                    2:0.152.2854+gite9a5903-2           amd64        x264 video coding library
ii  libx264-dev:amd64                    2:0.152.2854+gite9a5903-2           amd64        development files for libx264
ii  x264                                 2:0.152.2854+gite9a5903-2           amd64        video encoder for the H.264/MPEG-4 AVC standard

dpkg -l | grep gst
ii  gstreamer1.0-alsa:amd64              1.14.5-0ubuntu1~18.04.1             amd64        GStreamer plugin for ALSA
ii  gstreamer1.0-plugins-bad:amd64       1.14.5-0ubuntu1~18.04.1             amd64        GStreamer plugins from the "bad" set
ii  gstreamer1.0-plugins-base:amd64      1.14.5-0ubuntu1~18.04.1             amd64        GStreamer plugins from the "base" set
ii  gstreamer1.0-plugins-good:amd64      1.14.5-0ubuntu1~18.04.1             amd64        GStreamer plugins from the "good" set
ii  gstreamer1.0-plugins-ugly:amd64      1.14.5-0ubuntu1~18.04.1             amd64        GStreamer plugins from the "ugly" set
ii  gstreamer1.0-rtsp:amd64              1.14.5-0ubuntu1~18.04.1             amd64        RTSP plugin for GStreamer
ii  gstreamer1.0-vaapi:amd64             1.14.5-0ubuntu1~ubuntu18.04.1       amd64        VA-API plugins for GStreamer
ii  libgstreamer-gl1.0-0:amd64           1.14.5-0ubuntu1~18.04.1             amd64        GStreamer GL libraries
ii  libgstreamer-plugins-bad1.0-0:amd64  1.14.5-0ubuntu1~18.04.1             amd64        GStreamer libraries from the "bad" set
ii  libgstreamer-plugins-base1.0-0:amd64 1.14.5-0ubuntu1~18.04.1             amd64        GStreamer libraries from the "base" set
ii  libgstreamer-plugins-good1.0-0:amd64 1.14.5-0ubuntu1~18.04.1             amd64        GStreamer development files for libraries from the "good" set
ii  libgstreamer1.0-0:amd64              1.14.5-0ubuntu1~18.04.1             amd64        Core GStreamer libraries and elements
ii  libgstrtspserver-1.0-0               1.14.5-0ubuntu1~18.04.1             amd64        GStreamer RTSP Server (shared library)

Is the output above right?

path has been added, as below:

echo $GST_PLUGIN_PATH
/opt/intel/openvino/data_processing/dl_streamer/lib:/opt/intel/openvino/data_processing/gstreamer/lib/gstreamer-1.0:/usr/lib/x86_64-linux-gnu/gstreamer1.0

But gst-inspect-1.0 still cannot find x264enc...  What should I do?

Can it be assumed that the installation of gstreamer1.0-plugins-ugly:amd64 went fine and you can find the installed files inside of your Docker container?
Then it looks like it's needed to extend the gstreamer plugin search-path - as the DL-Streamer plugins are deployed somewhere else than the binaries installed via apt-get.
(see e.g. the issue #173)
Thanks for your quick reply.

How could I make sure the installation went fine?

# dpkg -l | grep x264
ii  libx264-152:amd64                    2:0.152.2854+gite9a5903-2           amd64        x264 video coding library
ii  libx264-dev:amd64                    2:0.152.2854+gite9a5903-2           amd64        development files for libx264
ii  x264                                 2:0.152.2854+gite9a5903-2           amd64        video encoder for the H.264/MPEG-4 AVC standard

dpkg -l | grep gst
ii  gstreamer1.0-alsa:amd64              1.14.5-0ubuntu1~18.04.1             amd64        GStreamer plugin for ALSA
ii  gstreamer1.0-plugins-bad:amd64       1.14.5-0ubuntu1~18.04.1             amd64        GStreamer plugins from the "bad" set
ii  gstreamer1.0-plugins-base:amd64      1.14.5-0ubuntu1~18.04.1             amd64        GStreamer plugins from the "base" set
ii  gstreamer1.0-plugins-good:amd64      1.14.5-0ubuntu1~18.04.1             amd64        GStreamer plugins from the "good" set
ii  gstreamer1.0-plugins-ugly:amd64      1.14.5-0ubuntu1~18.04.1             amd64        GStreamer plugins from the "ugly" set
ii  gstreamer1.0-rtsp:amd64              1.14.5-0ubuntu1~18.04.1             amd64        RTSP plugin for GStreamer
ii  gstreamer1.0-vaapi:amd64             1.14.5-0ubuntu1~ubuntu18.04.1       amd64        VA-API plugins for GStreamer
ii  libgstreamer-gl1.0-0:amd64           1.14.5-0ubuntu1~18.04.1             amd64        GStreamer GL libraries
ii  libgstreamer-plugins-bad1.0-0:amd64  1.14.5-0ubuntu1~18.04.1             amd64        GStreamer libraries from the "bad" set
ii  libgstreamer-plugins-base1.0-0:amd64 1.14.5-0ubuntu1~18.04.1             amd64        GStreamer libraries from the "base" set
ii  libgstreamer-plugins-good1.0-0:amd64 1.14.5-0ubuntu1~18.04.1             amd64        GStreamer development files for libraries from the "good" set
ii  libgstreamer1.0-0:amd64              1.14.5-0ubuntu1~18.04.1             amd64        Core GStreamer libraries and elements
ii  libgstrtspserver-1.0-0               1.14.5-0ubuntu1~18.04.1             amd64        GStreamer RTSP Server (shared library)

Is the output above right?

path has been added, as below:

echo $GST_PLUGIN_PATH
/opt/intel/openvino/data_processing/dl_streamer/lib:/opt/intel/openvino/data_processing/gstreamer/lib/gstreamer-1.0:/usr/lib/x86_64-linux-gnu/gstreamer1.0

But gst-inspect-1.0 still cannot find x264enc...  What should I do?

Hi @thinkinds,
It seems only installed gstreamer1.0-plugins-ugly might be the problem.
I am not sure in the docker environment, but I refer to the following URL to install the Gstreamer and this seems work for me:
http://lifestyletransfer.com/how-to-install-gstreamer-on-ubuntu/
Since you are using docker, you can also only try to install GStreamer and see if you can get x264enc and then install OpenVINO.
In both paths either install GST or OpenVINO first, also pay attention to remove the local cache before "gst-inspect-1.0":
rm -rf ~/.cache/gstreamer-1.0
Mark Liu

Hi @thinkinds,
It seems only installed gstreamer1.0-plugins-ugly might be the problem.
I am not sure in the docker environment, but I refer to the following URL to install the Gstreamer and this seems work for me:
http://lifestyletransfer.com/how-to-install-gstreamer-on-ubuntu/
Since you are using docker, you can also only try to install GStreamer and see if you can get x264enc and then install OpenVINO.
In both paths either install GST or OpenVINO first, also pay attention to remove the local cache before "gst-inspect-1.0":
rm -rf ~/.cache/gstreamer-1.0
Mark Liu

Hi @thinkinds,
It seems only installed gstreamer1.0-plugins-ugly might be the problem.
I am not sure in the docker environment, but I refer to the following URL to install the Gstreamer and this seems work for me:
http://lifestyletransfer.com/how-to-install-gstreamer-on-ubuntu/
Since you are using docker, you can also only try to install GStreamer and see if you can get x264enc and then install OpenVINO.
In both paths either install GST or OpenVINO first, also pay attention to remove the local cache before "gst-inspect-1.0":
rm -rf ~/.cache/gstreamer-1.0
Mark Liu

Thanks for your help, I got it work at last.

Hi @thinkinds,
It seems only installed gstreamer1.0-plugins-ugly might be the problem.
I am not sure in the docker environment, but I refer to the following URL to install the Gstreamer and this seems work for me:
http://lifestyletransfer.com/how-to-install-gstreamer-on-ubuntu/
Since you are using docker, you can also only try to install GStreamer and see if you can get x264enc and then install OpenVINO.
In both paths either install GST or OpenVINO first, also pay attention to remove the local cache before "gst-inspect-1.0":
rm -rf ~/.cache/gstreamer-1.0
Mark Liu

Thanks for your help, I got it work at last.


Documentation recommends relation-joined instead of relation-created

relation-joined is fired when a remote application is scaled up (i.e. fired for each remote unit that joins the relation)
relation-created is fired once*, when the unit first "learns" about the relation
reference:
https://juju.is/docs/sdk/relation-name-relation-joined-event
https://juju.is/docs/sdk/relation-name-relation-created-event
with that in mind, it seems like this code (which requests a new certificate) should be for relation-created, not relation-joined:
https://github.com/canonical/tls-certificates-interface/blob/f4738be2522552a6da8fa19bf53d65af6547fd0c/lib/charms/tls_certificates_interface/v3/tls_certificates.py#L151
https://github.com/canonical/tls-certificates-interface/blob/f4738be2522552a6da8fa19bf53d65af6547fd0c/lib/charms/tls_certificates_interface/v3/tls_certificates.py#L179-L193
related:
https://github.com/canonical/opensearch-operator/pull/201
https://github.com/canonical/mysql-router-k8s-operator/pull/101

Hi @gruyaume, any particular reason for us to use the joined events instead of created ones?

@phvalguima I don't remember any specific technical reason, it has been a while since we wrote these docs. @saltiyazan wrote this PR which will address this:

#151


Enforce new tensor creation syntax with an exception

🚀 🚀 Pull Request
Checklist:

[x]  My code follows the style guidelines of this project and the Contributing document
[x]  I have commented my code, particularly in hard-to-understand areas
[x]  I have kept the coverage-rate up
[x]  I have performed a self-review of my own code and resolved any problems
[x]  I have checked to ensure there aren't any other open Pull Requests for the same change
[ ]  I have described and made corresponding changes to the relevant documentation
[x]  New and existing unit tests pass locally with my changes

Changes
Outlaws the following syntax with an error:
ds.image = np.array(...)

btw lint is failing (black .)

this tutorial worked for me: https://dev.to/adamlombard/how-to-use-the-black-python-code-formatter-in-vscode-3lo0

this tutorial worked for me: https://dev.to/adamlombard/how-to-use-the-black-python-code-formatter-in-vscode-3lo0

@McCrearyD Thanks, but I already have black working in my IDE. The problem is that I resolve merge conflicts in the github editor, which circumvents the formatting :(


Return incorrect_or_unknown_payment_details if a payment hash cannot be found in the federation

Some services use HTLCs with random payment hashes for probing to figure out fees ahead of time. We currently seem to return an error other than incorrect_or_unknown_payment_details in that case, which makes this fail.

I think the problem here is that the intermediate node (ie, gateway in the routing hint) is returning the error. Since the client created the invoice, this presents some problems. The basic/naive probing method is to make sure the payment made it to the last hop and then checking for incorrect_or_unknown_payment_details, but in the fedimint/breez case, it doesn't go that far.
The proposal on the call today was either:

Pass the client secret to the federation so they can create the onion error.
Go the breez way and make the gateway give the same incorrect_or_unknown_payment_details error.

When I worked for a custodian a few years back, people would hardcode Breez's pubkey for their probing logic. I wonder if this is standard enough now that probers always accept incorrect_or_unknown_payment_details from either the node pubkey from the invoice signature or from any nodes in the route hint. Will try to look at a few FOSS wallets to see how they behave. Might want to talk to a few custodians like Strike or River or to the LN Mailling List to see if there's enough consensus now around probes to LSPs.

When I worked for a custodian a few years back, people would hardcode Breez's pubkey for their probing logic. I wonder if this is standard enough now that probers always accept incorrect_or_unknown_payment_details from either the node pubkey from the invoice signature or from any nodes in the route hint. Will try to look at a few FOSS wallets to see how they behave. Might want to talk to a few custodians like Strike or River or to the LN Mailling List to see if there's enough consensus now around probes to LSPs.

You can draw the conclusion that you are dealing with an interceptor node by looking at the channel ID of the route hint in the invoice. Since the channel ID contains the block height of the funding transaction, you can determine if this is a valid/possible block height.
If you draw the conclusion that the destination is behind an interceptor node, you can also expect the incorrect_or_unknown_payment_details to come from the interceptor node.
But always accepting the error from either the destination or from the route hint might also make sense.

I was told https://github.com/lightningnetwork/lnd/pull/8136 may help with this cc @m1sterc001guy @okjodom

Dev call: LND will help, if custodians change, but the real fix will be to let the gateway generate the invoice which is needed anyways for other reasons.

``###

_****_

Scan the code bos


Use pocket prefix on JSON-RPC response ids

As you know, we know return API errors using the JSON-RPC standard. We created a table for error codes on #495 that don't overlap with current node software JSON-RPC custom errors.
A sample response now would be:
{
    "jsonrpc": "2.0",
    "id": 1,
    "error": {
        "message": "Load balancer not found",
        "code": -32054
    }
}

Since there's no enforcement in the JSON-RPC standard on id property other than returning the same id placed on the request object. I suggest using "pokt" as prefix for the JSON-RPC response. It would look like this:
{
    "jsonrpc": "2.0",
    "id": "pokt-${IdFromReq}",
    "error": {
        "message": "Load balancer not found",
        "code": -32054
    }
}

Disagree; ID is used for ordering by clients. This would throw off the correlation between a request made and the error returned.


Convert catalog logo text to path

The "ICF Study Catalog" text in the catalog logo is converted to path to make the display independent from the fonts installed on the user's computer. Fixes #51 (missing font caused the text to be cut off).
The font used is Hanken Grotesk (OFL-1.1 license), suggested by @christian-monch in #51; it should work nicely alongside the FZJ logo (FZJ's official font is Weissenhof Grotesk, but it is proprietary)
Font (GitHub): https://github.com/marcologous/hanken-grotesk/
Font (Google): https://fonts.google.com/specimen/Hanken+Grotesk
Heading now:

Note that the catalog html template shows the image with style="width: 100%;", and the space on the right is taken by another div (span?) element, so filling the horizontal space is a matter of html and not the image width. I considered using a bitmap file (webp?); but considering that scaling is going to happen anyway (it displays in about 950x80 on fullscreen for me), staying with svg seems to be a safer choice.

This is a change to visuals only and it was discussed in the issue, so I feel justified in merging right away.


feat: docs + solidity frontier merkle

Please read contributing guidelines and remove this line.

Current dependencies on/for this PR:

master

PR #4485   👈

This stack of pull requests is managed by Graphite.


[C#] Could Disk Reads be FASTER?

I've got pretty much every basic operation covered on my POC.
Repo: https://github.com/ThiagoT1/FasterDictionary/tree/unsafe-0.0.3-fastread
Iteration thru the whole KV has ok(ish) performance.
public IAsyncEnumerator<KeyValuePair<TKey, TValue>> GetAsyncEnumerator(CancellationToken cancellationToken = default)
{
	return new AsyncEnumerator(this);
}
class AsyncEnumerator : IAsyncEnumerator<KeyValuePair<TKey, TValue>>
{
	FasterDictionary<TKey, TValue> _fasterDictionary;

	public ValueTask StartTask { get; }

	public AsyncEnumerator(FasterDictionary<TKey, TValue> fasterDictionary)
	{
		_fasterDictionary = fasterDictionary;
		StartTask = _fasterDictionary.AquireIterator();
	}

	KeyValuePair<TKey, TValue> _current;
	public KeyValuePair<TKey, TValue> Current => _current;

	public ValueTask DisposeAsync()
	{
		return _fasterDictionary.ReleaseIterator();
	}

	public async ValueTask<bool> MoveNextAsync()
	{
		await StartTask;

		_current = default;
		var readResult = await _fasterDictionary.IteratePair();
		if (!readResult.Found)
			return false;

		_current = new KeyValuePair<TKey, TValue>(readResult.Key, readResult.Value);
		return true;
	}
}

https://github.com/ThiagoT1/FasterDictionary/blob/96407cf3e476f612eb2eb72e895af4c6f9358850/src/FasterDictionary/FasterDictionary.Iterator.cs#L68-L71
Issue
What's killing me now is the random key read performance. I'm talking "mono-threaded" access to KV where a single reader has to retrieve values for thousands of random keys.
Adding, Updating once and Iterating over 1M keys takes less than 2 minutes:
[InlineData(1_000_000)]
public async Task AddUpdateIterate(int loops)
{
	FasterDictionary<string[], string>.ReadResult result;
	using (var dictionary = new FasterDictionary<string[], string>(TestHelper.GetKeyComparer<string[]>(), GetOptions($"{nameof(AddIterate)}-{loops}")))
	{
		var keys = new List<string[]>();

		for (var i = 0; i < loops; i++)
		{
			keys.Add(new[] { i.ToString() });
			dictionary.Upsert(keys[i], (i + 1).ToString()).Dismiss();
		}

		await dictionary.Ping();

		for (var i = 0; i < loops; i++)
			dictionary.Upsert(keys[i], (i + 10).ToString()).Dismiss();

		await dictionary.Ping();

		var count = 0;
		await foreach (var entry in dictionary)
		{
			count++;
			Assert.Equal((int.Parse(entry.Key[0]) + 10).ToString(), entry.Value);
		}

		result = await dictionary.TryGet(new[] { loops.ToString() });
		Assert.False(result.Found);

		Assert.Equal(loops, count);
	}
}

https://github.com/ThiagoT1/FasterDictionary/blob/026248db7bfca8f5b72c22481f732babd8237c8e/tests/FasterDictionary.Tests/UseCases/ArrayAsKeyTests.cs#L157-L190
However, doing the same while replacing the iteration with a 1M key lookup takes 30 minutes:
		for (var i = 0; i < loops; i += step)
		{
			result = await dictionary.TryGet(keys[i]);
			Assert.True(result.Found);
			Assert.Equal((i + 10).ToString(), result.Value);
		}

https://github.com/ThiagoT1/FasterDictionary/blob/026248db7bfca8f5b72c22481f732babd8237c8e/tests/FasterDictionary.Tests/UseCases/ArrayAsKeyTests.cs#L136-L141
This is a regular SSD, with roughly 500 MB/s read/write:

Looking at CPU time eaters on VS 2019 we see that the culprit is ClientSession<,,,,,>CompletePending, which in turn blames the Thread.Yield() inside FasterKV<,,,,,>.InternalCompletePending.

Replacing the Thread.Yield() with a SpinWait.SpinOnce() maintains functionality while greatly reducing CPU Usage.
Throughput, however, stays low, since the real bottleneck is the granularity of disk reads (the 30 minute mark is with this one):

Use Cases
Theres two scenarios where one of those strategies - mono-threaded iteration or massive random key lookups - will come into play:
1) Iterate thru a subset of the key set (Read Only)

This assumes a function to calculate all keys to iterate thru is in place (given a query or something).

In this case, every key in the subset will have to be passed to KVSession.Read, which will have awful performance. This strategy could be replaced (by the KV user) with a whole KV iteration, dismissing keys not in the subset. Not great, though.
Proposal
The knowledge about multiple keys in need of retrieval should be passed to KV, by means of a Read method that would accept multiple keys, while returning a AsyncEnumerable<ReadResult> that could be used to process all recovered values.
Such KV method would use that key array to optimize disk access (leveraging address and segment locallity), by means of reading larger chunks less often, whenever possible.
2) Massive RMW of Unitary Keys Already on Disk

This assumes that as soon as an RMW operation starts, all reads on the same key should retrieve the new value or wait for it (see below). It's pretty much the same as the tombstone mark, that informs us that the record is gone.

In this case, currently both the RMW'er and the Reader are slow, plus (AFAIK) the reader may get an old value, while we wait for the disk access to complete (and the RMW continuation to complete).
Proposal
RMW`s should atomically mark the record as dirty and cause any Read result of that key to yield a status that means we are waiting on a RMW to complete. The reader could optionally continue the read of a (possibly) old value, or place a continuation for when the RMW completes, which would garantee a fresh read up to that point.
This would also let the RMW'er fastly keep issuing the RMW command for the next keys, since a continuation for the actual RMW operation can be placed and there's a guarantee that any readers can wait for the RMW to complete.
The code that actually does the RMW after the disk read could be provided by a new Functions instance, as per #230.
It should also be noted that FASTER was firstly written without TLP in mind, and full adherence to TLP semantics would see the Functions class callbacks gone. But that's probably for another day, isn't it? :)

Also, please note that the same tests without updates complete under 40 seconds. The detail here is that we are changing the value length on purpose, with those updates. This forces the concurrentwriter call to return false, which in turn causes the need of a new slot on the log.

BTW, all of this is without serializers or object log, using only the unsafe approach with var length types

Thanks a lot!

BTW,
for the sake of science, I tried to see what the read throughput would look like if Read commands were issued in parallel.
var tasks = new Task<FasterDictionary<string[], string>.ReadResult>[2];

for (var i = 0; i < loops; i += step)
{
	var index = i % 2;
	tasks[index] = dictionary.TryGet(keys[i]).AsTask();
	if (index == 1)
	{
		await Task.WhenAll(tasks);

		for (var k = 0; k < tasks.Length; k++)
		{
			result = tasks[k].Result;
			Assert.True(result.Found);
		}

	}
}

https://github.com/ThiagoT1/FasterDictionary/blob/1e3756b905857ceff7c576a1c1f97daff34f3094/tests/FasterDictionary.Tests/UseCases/ArrayAsKeyTests.cs#L178
I relied on ClientSession<,,,,,>.CompletePendingAsync for that.
However, any actual parallelism would leave the tasks permanently incomplete. Getting the batch size to 1 makes the test OK again.

There is a tension between sync and async code here. For sync, the better alternative is Thread.Yield (benchmarked in the past). But for async, the better alternative might be what you suggest (Spin), although I have not benchmarked this yet. Is the observed cost (throughput) with async significantly degraded to justify a change or a config here?

Actually, async code is already avoiding the Thread.Yeild.
So, this could be a left as it is, as I predict async API will be way more popular, even making all sync code obsolete.
The other issues, though, like batching reads and chaining RMW's, are still alive.

Then is this PR still relevant: https://github.com/microsoft/FASTER/pull/241?
Will consider the other comments separately.

I closed the PR.

Closing as we have optimized the main goal of reads. We can create new issues if we plan to work on any other issues/ideas mentioned here.


Race issue

When people send a lot of messages after a race starts, Nadeko was sending the race message again in order to keep it at bottom. But in 1.8.4, it does not bring the race to the bottom in any way.

@Midoriin can you provide a screenshot? I think you can also ping master kwoth then ^~^

Well, I dont think it needs a proof. You can just simply start a race with your friend and spam as much as you can.

Yeh i just tested it, was buzzy. But indeed it doesn't work.. @Kwoth can you label this issue as bug?

@Kwoth tested out the .race, it indeed doesn’t send it again anymore. You can put a label Bug on it :)

@Kwoth is this a bug or intended?

chilllll :emiwot: i'll get to it eventually


raftstore: label based commit algorithm

What have you changed?
Provide a way to postpone committing entries until they are replicated to at least two nodes from different label values.
This is useful for ensuring data consistency over different DCs. It's an alternative to #6578.
What is the type of the changes?

New feature

How is the PR tested?

Integration test

Does this PR affect documentation (docs) or should it be mentioned in the release notes?
Yes.
Does this PR affect tidb-ansible?
Yes.
Refer to a related PR or issue link (optional)
https://github.com/tikv/raft-rs/pull/347

/release

/release

/release

/release

/release

Let's trace it at #7657.


2022/3/4放送分

[x] 募集サイト をconnpassに作る
[ ] URLを貼る
[ ] 放送開始

Breaking changes in the Microsoft Graph Tasks API (beta)

Customizing $filter for patial data in ASP.NET Core OData 8

Early peek at C# 11 features

Requiring two-factor authentication on NuGet.org

Learn from the community: Microsoft AI MVP designs a Microsoft Teams bot to centralize tools for employees

Windows 11 Notepad

PSReadLine 2.2 GA

PyTorch-DirectML: Preview Release 2

Announcing new permissions for Teams chats and tags APIs

Training a ML.NET Model with Azure ML

Azure Cosmos DB API for MongoDB v4.2 is Here - Three Reasons to Upgrade Now

Announcing TypeScript 4.6

Learn from the community: Low-code Q&A bot for Microsoft Teams helps communities provide better onboarding process

Execution and Static Analysis Support for MSVC on Compiler Explorer

Sharing code between ASP.NET and ASP.NET Core

Two Phonetic Scripts: Vietnamese and Korean

Python in Visual Studio Code - March 2022 Update


Prepare Understanding Reflection tutorial in the GT Book

There are some initial pages on “Understanding Reflection” in the GT Book, but they need to be expanded and continued.

This is pretty much done. The only question is whether to add a page or more on Reflectivity ...


SRE-1303: Sync with upstream and rebuild action

Test this changes here https://github.com/finmid/Devops-maintenance-mode/actions/runs/7931996573/job/21657436357#step:5:1
Will merge and create a release ✅


Cannot debug C++ multiple times in a row

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version: 1.89
OS Version: Windows 11

I am able to debug my code successfully by pressing F5, but if I attempt to run it a second time, it will fail with No such file or directory in the terminal output.
This used to work as expected, but I've started experiencing this recently, so I'm wondering if it's related to this?
My launch.json is based on the sample provided, but for reference it is this:
{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(gdb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/build/test.exe",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${fileDirname}",
            "environment": [],
            "externalConsole": false,
            "MIMode": "gdb",
            "miDebuggerPath": "gdb",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                },
                {
                    "description": "Set Disassembly Flavor to Intel",
                    "text": "-gdb-set disassembly-flavor intel",
                    "ignoreFailures": true
                }
            ]
        }

    ]
}

After attempting to run a second time, the terminal looks like this: Note how the second time, the start of the command seems to have been truncated
Alex@Alex_Asus MINGW64 ~/Documents/GameEngine/EngineTest
$  /usr/bin/env c:\\Users\\Alex\\.vscode\\extensions\\ms-vscode.cpptools-1.19.9-win32-x64\\debugAdapters\\bin\\WindowsDebugLauncher.exe --stdin=Microsoft-MIEngine-In-c2axmb5z.gjq --stdout=Microsoft-MIEngine-Out-5qxnf0rp.y1x --stderr=Microsoft-MIEngine-Error-itnz0wk4.tmp --pid=Microsoft-MIEngine-Pid-iod3xchz.rmb --dbgExe=C:\\MinGW\\bin\\gdb.exe --interpreter=mi

Alex@Alex_Asus MINGW64 ~/Documents/GameEngine/EngineTest
$ ^C

Alex@Alex_Asus MINGW64 ~/Documents/GameEngine/EngineTest
$ \\ms-vscode.cpptools-1.19.9-win32-x64\\debugAdapters\\bin\\WindowsDebugLauncher.exe --stdin=Microsoft-MIEngine-In-dob4gqtf.x31 --stdout=Microsoft-MIEngine-Out-r1qtapcf.vwn --stderr=Microsoft-MIEngine-Error-sysmwcem.542 --pid=Microsoft-MIEngine-Pid-s2l523nn.m1i --dbgExe=C:\\MinGW\\bin\\gdb.exe --interpreter=mi
bash: \ms-vscode.cpptools-1.19.9-win32-x64\debugAdapters\bin\WindowsDebugLauncher.exe: No such file or directory

Alex@Alex_Asus MINGW64 ~/Documents/GameEngine/EngineTest
$

Closing the integrated terminal and trying again works fine, but this is annoying.

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.89.0. Please try upgrading to the latest version and checking whether this issue remains.
Happy Coding!

I've realised this is likely an issue with an extension, so I've also opened an issue here

Closing as the issue on cpptools has also been closed


Add version 0.3 upgrade guide

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

Comparison is base (16917f0) 100.00% compared to head (d33bdcc) 100.00%.

Additional details and impacted files
@@            Coverage Diff            @@
##              main      #441   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           73        73
  Lines         2591      2591
  Branches       418       418
=========================================
  Hits          2591      2591

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


refactor: improve poetry packaging

This allows poetry-only builds (i.e. poetry install) and better packaging for distributions.
Additionally this PR adds Nix packaging to allow users of Nix to build and run the app locally.

this looks good to me!
could you please rebase this PR to the features/algorithms branch as this is currently the active dev branch, i will do a full code review + testing later today!

I will be able to reduce the flake.nix once https://github.com/nix-community/poetry2nix/pull/1803 is merged

Okay I changed the structure again. In my local testing, the pyinstaller binary works as well as running it manually (i.e. poetry run eyetrackvr-backend)

Juts did a full test with my ETVR hardware locally and everything looks good!
there seems to be a bug related to the camera process not detecting a new source address when config is changed but i do not believe this PR introduced that bug.


tf branch README

What is the data preparation, training and testing commands for the tensorflow implementation? It seems that the README is still referring to the caffe training and testing.

I also have the same question. Could you please tell us how to ues the code based on the tensorflow framework

I will update the readme soon.

@CRISZJ @tianyudwang
Sorry for the delay. I have updated the readme and tested the tensorflow code just now.
Now you can follow the installation guide and shape classafication guide to have a try.

@CRISZJ @tianyudwang
Sorry for the delay. I have updated the readme and tested the tensorflow code just now.
Now you can follow the installation guide and shape classafication guide to have a try.

thanks. I will try later.


NACL: is private key storage required?

Currently we always store the private key. However it would make our life a lot simpler if this could be more of an opt-in thing, because if we don't need to store the private key, it could just be loaded once into memory, without a required (safe) storage mechanism on FS.

in our use case there should always be a private key? please explain?
its made to be used without interactivity in digitalme, so cannot just be loaded in mem because e.g. service can be restored or can be out of process script

It's an open question, in theory you 3bot itself should just stay loaded forever, so if we can actually achieve that, then it could really just stay in memory.
I get though, that is a utopia. Problem is though, that as soon as you need to store the private key it has to stored either in plain or encrypted. If we can do plain that would keep things easy enough, and if stored in a HW-secured location than it should in theory mean that only those with access to the hardware can access it. However, it remains a point of concern as a potential backdoor.
If we choose to encrypt it, than where does the private key come from. If it is stored on FS or HW-secured environment, then we can just as well just store it plain. Or does it come from the user? In which case storing the PK is useless as anyway the user will need to unlock it. Or does it come from another automated environment? OK that could work, but than how is that one controlled and is it another 3bot?


Wrong flutter_flux code when pulled down from Dart package

Hey all, trying out flutter_flux in a project, but can't seem to get the correct flutter_flux source pulled down. I have defined flutter_flux: 4.0.1 in my pubspec.yaml, but when I look at the Dart Packages in Android Studio the code is not correct when compared to the GitHub repo for flutter_flux 4.0.1. For example, here is a the StoreWatcherMixin signature from my local machine: abstract class StoreWatcherMixin implements State<dynamic> and here is the same on GitHub: abstract class StoreWatcherMixin<T extends StatefulWidget> implements State<T>. I have tried re-installing everything, clearing the cache, cleaning the project... I am out of idea. Any thoughts?

I forgot to bump the version in pubspec.yaml after the last update. Try manually doing a git pull.

Updated version to 4.1 in 8595064cf5d8ad5e638984e0be385866f0ca0cb5