Update to 3.1.0 removed every device from Apple Home

Thanks for all the work in updating the plugin, however, I just updated to release version 3.1.0 from 2.0.1 and it removed every Tuya device from my Apple Home, and subsequently created all new devices.  This broke every re-naming, goruping and automation in my Apple Home.
I attempted to restore from a Homebridge backup that I took immediately before the update, and I am still left with all new devices and no functioning automations.
I checked the change log, discussions and issues section before doing the update, and did not see any mention of this issue.
I appreciate all the work that has been done to update the plugin, but can we please do some testing before releasing production updates, and include any warnings in the change log.
I now have several days of re-configuring my lighting, fans and powerpoints and related automations ahead of me.

Hi @justdun. Apologies for any inconvenience caused. On the setup i tested the changes with I did not encounter this issue. There was a similar concern raised in https://github.com/iRayanKhan/homebridge-tuya/issues/445, though upon a re-install the devices did re-appear after a few minutes. I can however only test with the devices that I have on hand and work with feedback raised on the beta versions.
Unfortunately, once the devices have been unregistered from Apple Home, the only way forward is to reconfigure them. I will be looking to ensure that this sort of thing does not happen again in future updates as it is rather inconvenient.
Between this version and the previous live release there has been a large number of changes with the master branch which i based the 3.1.0 version on. Many of the recent issues raised come from changes introduced in the merged PRs that never made a live release. I am working with others to try get these resolved, but I need the help with making changes and testing devices i don't physically have.

I just updated to release version 3.1.0 and I had the same behavior you describe @justdun .
I had to redo many automations and change names for more than 90 of my devices

per semver, what's the actual expected breaking change expected in v2->v3? The release notes aren't clear what's expected to break

Hi @chrisjshull, the reasoning for incrementing a major version was due to the number of changes added since the last release 2.0.1. In this case, main had many changes ahead of the release without any evidence of testing on those.
I incremented the version to 3.1.0 to start clear of any previous beta releases of the plugins. As for the behaviour that we are seeing here. I have seen reports of it, but i am unable to replicate them on my end with the upgrades. The change for 3.1.0 is actually a much easier upgrade than the originally planned "2.1.0" that would changed the name of the plugin internally and would definitely have required repairing of devices in HomeKit.
For the 3.1.1 release (currently in beta) I am looking for testers to help ensure these sorts of issues are found early.

Finally took the plunge to go from 2.x to 3.1.1, and experienced the full reset described in this bug :(


[Feature] Implement automatic partition creation during data loading

What type of PR is this：

[ ] BugFix
[x] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Which issues of this PR fixes ：

Fixes #
Problem Summary(Required) ：

Create Automatic Partition Table
CREATE TABLE ss(
    event_day DATE,
    pv BIGINT
)
DUPLICATE KEY(event_day)
PARTITION BY date_trunc('month', event_day)
DISTRIBUTED BY HASH(event_day) BUCKETS 8
PROPERTIES("replication_num" = "3");

Insert Values
insert into ss values('2023-02-14', 2),('2023-03-01',2);

Show Partitions
mysql> show partitions from ss;
+-------------+---------------+----------------+---------------------+--------------------+--------+--------------+-------+-----------------+---------+----------------+---------------+---------------------+--------------------------+----------+------------+----------+
| PartitionId | PartitionName | VisibleVersion | VisibleVersionTime  | VisibleVersionHash | State  | PartitionKey | Range | DistributionKey | Buckets | ReplicationNum | StorageMedium | CooldownTime        | LastConsistencyCheckTime | DataSize | IsInMemory | RowCount |
+-------------+---------------+----------------+---------------------+--------------------+--------+--------------+-------+-----------------+---------+----------------+---------------+---------------------+--------------------------+----------+------------+----------+
| 14042       | p202302       | 2              | 2023-02-15 11:01:12 | 0                  | NORMAL |              |       | event_day       | 8       | 3              | HDD           | 9999-12-31 23:59:59 | NULL                     | 0B       | false      | 0        |
| 14075       | p202303       | 2              | 2023-02-15 11:01:12 | 0                  | NORMAL |              |       | event_day       | 8       | 3              | HDD           | 9999-12-31 23:59:59 | NULL                     | 0B       | false      | 0        |
+-------------+---------------+----------------+---------------------+--------------------+--------+--------------+-------+-----------------+---------+----------------+---------------+---------------------+--------------------------+----------+------------+----------+
2 rows in set (0.01 sec)

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] This pr will affect users' behaviors
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[ ] I have checked the version labels which the pr will be auto backported to target branch

[ ] 2.5
[ ] 2.4
[ ] 2.3
[ ] 2.2

run starrocks_admit_test

[FE PR Coverage Check]
:disappointed: fail : 2 / 20 (10.00%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/service/FrontendServiceImpl.java
0
18
00.00%
[1563, 1569, 1574, 1581, 1587, 1596, 1602, 1608, 1619, 1625, 1634, 1640, 1646, 1655, 1660, 1671, 1682, 1683]

:large_blue_circle:
com/starrocks/catalog/PartitionKey.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/planner/OlapTableSink.java
1
1
100.00%
[]

[FE PR Coverage Check]
:disappointed: fail : 2 / 20 (10.00%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/service/FrontendServiceImpl.java
0
18
00.00%
[1563, 1569, 1574, 1581, 1587, 1596, 1602, 1608, 1619, 1625, 1634, 1640, 1646, 1655, 1660, 1671, 1682, 1683]

:large_blue_circle:
com/starrocks/catalog/PartitionKey.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/planner/OlapTableSink.java
1
1
100.00%
[]

[FE PR Coverage Check]
:disappointed: fail : 3 / 21 (14.29%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/service/FrontendServiceImpl.java
1
19
05.26%
[1565, 1571, 1576, 1583, 1589, 1598, 1604, 1610, 1621, 1627, 1636, 1642, 1648, 1657, 1662, 1673, 1684, 1685]

:large_blue_circle:
com/starrocks/catalog/PartitionKey.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/planner/OlapTableSink.java
1
1
100.00%
[]

[FE PR Coverage Check]
:heart_eyes: pass : 18 / 22 (81.82%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/service/FrontendServiceImpl.java
16
20
80.00%
[1590, 1673, 1684, 1685]

:large_blue_circle:
com/starrocks/catalog/PartitionKey.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/planner/OlapTableSink.java
1
1
100.00%
[]

run starrocks_admit_test

[FE PR Coverage Check]
:heart_eyes: pass : 18 / 22 (81.82%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/service/FrontendServiceImpl.java
16
20
80.00%
[1590, 1673, 1684, 1685]

:large_blue_circle:
com/starrocks/catalog/PartitionKey.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/planner/OlapTableSink.java
1
1
100.00%
[]

run starrocks_admit_test

[FE PR Coverage Check]
:disappointed: fail : 3 / 21 (14.29%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/service/FrontendServiceImpl.java
1
19
05.26%
[1598, 1604, 1609, 1616, 1622, 1631, 1637, 1643, 1654, 1660, 1669, 1675, 1681, 1690, 1695, 1706, 1717, 1718]

:large_blue_circle:
com/starrocks/catalog/PartitionKey.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/planner/OlapTableSink.java
1
1
100.00%
[]


evince: 3.36.0 -> 3.36.1

Semi-automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/evince/versions.
meta.description for evince is: "GNOME's document viewer"
meta.homepage for evince is: "https://wiki.gnome.org/Apps/Evince"
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 3.36.1 with grep in /nix/store/pj35164awylqnnsgbbbs07hy3wyj5vy1-evince-3.36.1

directory tree listing: https://gist.github.com/838eef5853f63afde3518290d8ba13bb

du listing: https://gist.github.com/72b764b5ae11eed2daf823448408970d

Rebuild report (if merged into master) (click to expand)

21 total rebuild path(s)

7 package rebuild(s)

7 x86_64-linux rebuild(s)
7 i686-linux rebuild(s)
0 x86_64-darwin rebuild(s)
7 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
denemo
evince
glom
gnome3.evince
gnome3.gnome-books
gnome3.gnome-documents
gnome3.sushi

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/pj35164awylqnnsgbbbs07hy3wyj5vy1-evince-3.36.1 \
  --option binary-caches 'https://cache.nixos.org/ https://r-ryantm.cachix.org/' \
  --option trusted-public-keys '
  r-ryantm.cachix.org-1:gkUbLkouDAyvBdpBX0JOdIiD2/DP1ldF3Z3Y6Gqcc4c=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(r-ryantm's Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A evince https://github.com/r-ryantm/nixpkgs/archive/5cf586672a03fe086553240f88c803c27be2954c.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/pj35164awylqnnsgbbbs07hy3wyj5vy1-evince-3.36.1
ls -la /nix/store/pj35164awylqnnsgbbbs07hy3wyj5vy1-evince-3.36.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review 1

6 packages built:
- denemo
- evince
- glom
- gnome3.gnome-books
- gnome3.gnome-documents
- gnome3.sushi

Maintainer pings
cc @hedning @jtojnar @worldofpeace @vcunat for testing.

https://ftp.gnome.org/pub/GNOME/sources/evince/3.36/evince-3.36.1.news
some features require poppler 0.88


"Cookies" library causes a significant increase of vendors bundle size

What problem does this feature solve?
Reducing client bundle size to improve website load time
Hi,
I noticed that the addition of nuxt-i18n increased a lot my vendor.app.js bundle size
I looked for the source of this significant increase.
It seems that it's caused by the import of https://github.com/pillarjs/cookies that calls nodejs functions. (http and crypto)
Due to this, webpack adds many libraries to vendor bundle. Is this really necessary on the client side, just for a cookie library? I didn't dig deeper into the codebase to affirm that.

I dont know if you can do something to prevent this or if we must extend the nuxtjs webpack configuration ? How ?

This feature request is available on Nuxt community (#c251)

@rclement WDYT? I knew that new library was be a bit bigger than the previous one but I wouldn't expect a big difference in bundle size. Would it be worth it keeping the old library and refactoring the code to still address the issue while keeping the bundle size as light as possible?

@paulgv Indeed that’s a bit crazy just for handling cookies properly, I admit I was in a hurry and only checked my project bundle where Cookies may have already been included by another dependency...
Of course, I’m all for a rewrite, as long as the previous bug is not reintroduced. Maybe reusing the ˋcookieˋ package and manually handling the ˋSet-Cookieˋ header properly is the way to go? We can be inspired by the startup of the ˋcookies` package which does just that (handling whethet this is undefined, a string or already a list).
I won’t have time for it this week-end but I can do it next week if needed.

The answer to question in #329 also applies here. cookies library is not needed on the client so it could be required conditionally and then it wouldn't even be included on the client.

@paulgv @remychvn I under-estimated my available time for this week-end, so I manage to send a new PR (#332) hopefully making the best of both worlds:

Revert to using the cookie package to avoid increase of vendor bundle size
Still fixing the original bug by manually handling the Set-Cookie headers, in the same fashion as the cookies package does

Let me know if missed something, again.


fix: Provide more memory to Node in Docker

Description
Add ENV NODE_OPTIONS "--max-old-space-size=4096" to the Dockerfile to prevent Node from running out of memory inside the container
Task Item
Related to #1669
Type of change

[x] Bug fix (non-breaking change which fixes an issue)

Checklist

[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have functionally tested my change

I did some investigation on this previously, and i try to set --max-old-space-size to 2048 because that's the  default size of the allocated memory for docker-compose builder container. and i even don't have a way to change that.
Any size bigger than that, like 4096, will result in a OOF,  because the container is asking more, but the system refuse to provide.
So @benbrown can you test with another machine? see if this will work?

@boydc2014 Are you suggesting that I need to test this on a machine with more RAM?

@boydc2014 Are you suggesting that I need to test this on a machine with more RAM?

I was suggesting testing with a machine with less RAM, :) . I think i figured out

I don't understand how computers work anymore.


Fix CVE-2021-22569

Signed-off-by: Peixin Li<EMAIL_ADDRESS>pre-merge CI is blocked by vulnerability scan https://github.com/advisories/GHSA-wrvw-hg22-4m67
try update protobuf-java version to suggested version

build

Spark runtime use 2.5.0 version, so we use the specific version till now.
NVIDIA blackduck scan does not allow vulnerability of direct dependencies, so I bumped the version here to unblock the pre-merge CI if test could pass.
The real fix will be https://github.com/NVIDIA/spark-rapids/pull/4408 which will remove several direct dependencies including protobuf-java

so I'm not sure I like changing this right before the 22.02 release. #4408 is scheduled for 22.04. It builds and tests run so maybe its ok but we going from a 2.x to a 3.x and I think we should look at compatibility or what exactly we are using this for. #4551

yeah, this should just be a temp fix to unblock CI. We should go for some mature fix


Add static files

In ipython it is possible to add static files to the server at ~/.ipython/profile_default/static/
I would like to do the same here (mainly adding my own css files).
is it possible?
I saw that there is a config manager.resources, but the directories I added there were ignored by the server

(I also flagged it as bug because the props is there)


Make RAND "egd" API be mostly no-op

This API is no longer necessary, so make it a no-op.

Why are we removing functionality in what is supposed to be a compatible release?

I am proposing to remove this because it is no longer needed.  The API's still exist.  But I failed to follow things properly in rand_unix.  Closing this.


moose modules unit testing not occurring

I'm pretty sure i've written a similar idaholab/moose issue in the past few months, but couldn't find it, so sorry for the duplicate if there is one!
CIVET isn't running any of the modules unit tests.  For instance:
BUILD_ROOT/moose/modules/geochemistry/unit/: make -j 12
find: '/opt/civet/build_0/moose/modules/geochemistry/unit/include': No such file or directory
Rebuilding symlinks in /opt/civet/build_0/moose/modules/geochemistry/unit/build/header_symlinks
Compiling C++ with suffix (in dbg mode) /opt/civet/build_0/moose/modules/module_loader/src/ModulesApp.C...
Checking if header needs updating: /opt/civet/build_0/moose/modules/geochemistry/unit/include/Geochemistry-unitRevision.h...
Compiling C++ (in dbg mode) /opt/civet/build_0/moose/modules/geochemistry/unit/src/GeochemicalDatabaseValidatorTest.C...
Compiling C++ (in dbg mode) /opt/civet/build_0/moose/modules/geochemistry/unit/src/GeochemistryActivityCoefficientsDebyeHuckelTest.C...
Compiling C++ (in dbg mode) /opt/civet/build_0/moose/modules/geochemistry/unit/src/GeochemistrySortedIndicesTest.C...
Compiling C++ (in dbg mode) /opt/civet/build_0/moose/modules/geochemistry/unit/src/GeochemicalSystemTest.C...
Compiling C++ (in dbg mode) /opt/civet/build_0/moose/modules/geochemistry/unit/src/GeochemicalDatabaseReaderTest.C...
Compiling C++ (in dbg mode) /opt/civet/build_0/moose/modules/geochemistry/unit/src/MinimalGeochemicalSystemTest.C...
Compiling C++ (in dbg mode) /opt/civet/build_0/moose/modules/geochemistry/unit/src/GeochemistryKineticRateCalculatorTest.C...
Compiling C++ (in dbg mode) /opt/civet/build_0/moose/modules/geochemistry/unit/src/GeochemistrySpeciesSwapperTest.C...
Compiling C++ (in dbg mode) /opt/civet/build_0/moose/modules/geochemistry/unit/src/EquilibriumConstantInterpolatorTest.C...
Compiling C++ (in dbg mode) /opt/civet/build_0/moose/modules/geochemistry/unit/src/GeochemistryIonicStrengthTest.C...
Compiling C++ (in dbg mode) /opt/civet/build_0/moose/modules/geochemistry/unit/src/GeochemistryFormattedOutputTest.C...
Compiling C++ (in dbg mode) /opt/civet/build_0/moose/modules/geochemistry/unit/src/GeochemicalSolverTest.C...
Compiling C++ (in dbg mode) /opt/civet/build_0/moose/modules/geochemistry/unit/src/GeochemistryActivityCalculatorsTest.C...
Compiling C++ (in dbg mode) /opt/civet/build_0/moose/modules/geochemistry/unit/src/main.C...
Linking Library /opt/civet/build_0/moose/modules/module_loader/lib/libmodule_loader_with_gc-dbg.la...
Linking Library /opt/civet/build_0/moose/modules/geochemistry/unit/test/lib/libgeochemistry-unit_test-dbg.la...
Linking Library /opt/civet/build_0/moose/modules/geochemistry/unit/lib/libgeochemistry-unit-dbg.la...
Linking Executable /opt/civet/build_0/moose/modules/geochemistry/unit/geochemistry-unit-dbg...
BUILD_ROOT/moose/modules/geochemistry/unit/: ./run_tests
[==========] Running 0 tests from 0 test cases.
[==========] 0 tests from 0 test cases ran. (0 ms total)
[  PASSED  ] 0 tests.

and similar for all the other modules.  In the geochemistry module there are ~200 tests that really need to be run for every PR.

I'm not in the loop anymore but I still get alerted for civet issues, and since I have nothing better to do with my life, I took a look. :)
This doesn't seem to be a civet issue though. Just building the geochemistry unit test executable and running it manually shows that no tests are run. In fact, it appears that the lib/libgeochemistry-unit-opt.so (where all the tests are) is not even linked to the executable (as verified by ldd) even though it definitely is on the link line. This might be due to nothing actually referencing the symbols in libgeochemistry-unit-opt.so so the linker just silently drops it.
Forcing the linkage by, for example, putting a dummy function in one of the unit test source files and calling it from main(), gets the unit tests running again.
So it seems it is a moose build issue and no way am I going to try to figure that out :)

By the way, moose/unit is not affected by this because it does reference functions in libmoose-unit-opt.so when main() calls
registerApp(MooseUnitApp).  The modules don't have separate unit test apps, so they just call registerApp(<Module>App)

Thanks for this detective work, @brianmoose .   I'm now doing some of my own - will report here if i find anything which is very unlikely since i'm not experienced in this sort of thing.

I can't replicate what i think you're reporting:
moose/modules/geochemistry/unit/> METHOD=dbg make -j 2
moose/modules/geochemistry/unit/> ./geochemistry-unit-dbg

runs my unit tests

What OS are you running? Might just be a linux thing...

MacOS


error calling the az rest to add a user to a directory role

This is autogenerated. Please review and update as needed.
Describe the bug
error calling the az rest to add a user to a directory role from powershell
$miObjectId="id of managed identity"
<EMAIL_ADDRESS>""https://graph.microsoft.com/v1.0/directoryObjects/$miObjectId""}"
$headers="{""Content-Type"": ""application//json""}"
az rest --method POST --uri "https://graph.microsoft.com/beta/directoryRoles/9b895d92-2cd3-44c7-9d02-a6ac2d5ea5c3/members/$ref" --headers $headers  --body $body
Command Name
az rest
Errors:
The command failed with an unexpected error. Here is the traceback:
not enough values to unpack (expected 2, got 1)
Traceback (most recent call last):
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/util.py", line 506, in shell_safe_json_parse
  File "json\__init__.py", line 370, in loads
  File "json\decoder.py", line 337, in decode
  File "json\decoder.py", line 353, in raw_decode
json.decoder.JSONDecodeError: Expecting property name enclosed in double quotes: line 1 column 2 (char 1)

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/util.py", line 815, in send_raw_request
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/util.py", line 531, in shell_safe_json_parse
azure.cli.core.azclierror.InvalidArgumentValueError: Failed to parse JSON: {Content-Type: application//json}
Error detail: Expecting property name enclosed in double quotes: line 1 column 2 (char 1)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\knack/cli.py", line 231, in invoke
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/__init__.py", line 657, in execute
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/__init__.py", line 720, in _run_jobs_serially
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/__init__.py", line 691, in _run_job
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/__init__.py", line 328, in __call__
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/command_operation.py", line 121, in handler
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/command_modules/util/custom.py", line 16, in rest_call
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/util.py", line 818, in send_raw_request
ValueError: not enough values to unpack (expected 2, got 1)

To Reproduce:
Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

Put any pre-requisite steps here...
az rest --method {} --uri {} --headers {} --body {}

Expected Behavior
Environment Summary
Windows-10-10.0.22000-SP0
Python 3.8.9
Installer: MSI

azure-cli 2.26.1

Extensions:
azure-devops 0.17.0

Additional Context

I was able to get past that error by doing this and replace all occurrences of " with ".
<EMAIL_ADDRESS>""https://graph.microsoft.com/v1.0/directoryObjects/$miObjectId""}"
$body = $body -replace """, "\""
$headers="{""Content-Type"": ""application/json""}"
$headers = $headers -replace """, "\""
az rest --method POST --uri "https://graph.microsoft.com/beta/directoryRoles/9b895d92-2cd3-44c7-9d02-a6ac2d5ea5c3/members/$ref" --headers $headers  --body $body
but now I get this error
Bad Request({"error":{"code":"Request_BadRequest","message":"Unsupported resource type 'DirectoryObject' for operation 'Create'.","innerError":{"date":"2021-07-27T20:47:18","request-id":"20ff01b5-8eb6-49f2-8fb2-9d7a63d02297","client-request-id":"20ff01b5-8eb6-49f2-8fb2-9d7a63d02297"}}})

@jiasli for awareness

For including quotes in argument values, please see https://docs.microsoft.com/en-us/cli/azure/use-cli-effectively#pass-arguments
As for calling Microsoft Graph API, please see https://docs.microsoft.com/en-us/graph/api/overview?view=graph-rest-1.0&preserve-view=true to make sure the correct API is used.


perf(docs): update doc file names to standard

Alaska Airlines Pull Request
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Summary:
Update doc names to use latest naming standard
Type of change:
Please delete options that are not relevant.

[ ] New capability
[ ] Revision of an existing capability
[ ] Infrastructure change (automation, etc.)
[x] Other (please elaborate)

Checklist:

[x] My update follows the CONTRIBUTING guidelines of this project
[x] I have performed a self-review of my own update

By submitting this Pull Request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
Pull Requests will be evaluated by their quality of update and whether it is consistent with the goals and values of this project. Any submission is to be considered a conversation between the submitter and the maintainers of this project and may require changes to your submission.
Thank you for your submission!
-- Auro Design System Team

:tada: This PR is included in version 1.2.7 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Presto-Redis connector

The connector allow querying of key/value Redis data where value is of the String type. See doc file for more details.
There's code duplication between Redis and Kafka connector in the decoders. This will be commoned in the subsequent pull request as I prefer not to check in new functionality and code refactoring in single shot.

There is another open PR for a kinesis connector that also duplicates decoder stuff. Might be good to coordinate https://github.com/facebook/presto/pull/2885

Ok, great. I'd recommend to merge these requests and create a separate pull request for code refactoring

I had a couple of conversations to pull out the decoders and the static metadata configuration into presto proper (as I wrote the initial version of that).

I think we should do the refactoring first, as that will make the code easier to review. Could you split this into two PRs, one that refactors the Kafka connector, and then one that adds Redis connector?

cberner, I've added the refactored code. There are many different possibilities where the commoned-up code could live (presto-main, presto-spi, presto-util,....) each with different pros and cons. I've decided to put the common part in the presto-spi since at the moment it's the place where most of the other connector-common parts reside. One of the downsides is that presto-spi now has more dependencies than before.
Please take a look

We should add a new module for this as an optional utility library for connectors.

How does presto-util sound ?

I'd name it "presto-connector-utils", but will defer to @electrum on the naming

@martint, I've pulled decoders into a separate module and removed deprecated classes. Can you look into integrating this PR ? thx

Sorry for the delay on this. We've been really busy and will try to get to it soon.

Merged, thanks!


Report unused compileOnly dependencies as 'should be removed'

Is your feature request related to a problem? Please describe.

If we define dependencies like this but do not use them at all they are not reported.
    compileOnly("androidx.annotation:annotation")
    compileOnly("org.json:json")

The plugin currently discards all advices for dependencies declared as compileOnly. I think this is the right behavior if it is about cases where the dependencies could be implementation or api. Because the plugin cannot know, if a dependency is (not) needed at runtime.
However, the plugin would know if the dependency is not needed at compile time. In this case, the dependency can be safely removed altogether and I think the plugin should give that advice.
Describe the solution you'd like

The plugin should list compileOnly dependencies that are unused in the Unused dependencies which should be removed part of the report.
Describe alternatives you've considered

...
Additional context

A related topic I just thought of (but this is really a very rare case I assume) :

compileOnly dependencies which are detected as api should be recommended as compileOnlyApi
compileOnlyApi dependencies which are detected as implementation should be recommended as compileOnly

I agree with your general idea.
Secondly, I do want to eventually support compileOnlyApi, but care must be taken because only the core Gradle plugins support this currently. At least, I don't think that Kotlin nor AGP support it.


two questions about using Snowflake

Hello, I have two questions about using Snowflake. Can you help answer them?
1st: This is my first time encountering Snowflake ID. Can you explain what the 42 means in gen = SnowflakeGenerator(42)? What guidelines should I follow when setting this value? Also, what are the roles of epoch and seq in the parse method?
2nd: When I ran the following code, I noticed that the displayed times were inconsistent.
from snowflake import SnowflakeGenerator
import datetime

current_time = datetime.datetime.now()
print("current time:", current_time)

gen = SnowflakeGenerator(42)
snow_id = next(gen)
print("generate snowflake id:", snow_id)

from snowflake import Snowflake

sf = Snowflake.parse(snow_id)

print(f"{sf.timestamp = }")
print(f"{sf.instance = }")
print(f"{sf.epoch = }")
print(f"{sf.seq = }")
print(f"{sf.seconds = }")
print(f"{sf.milliseconds = }")
print(f"{sf.datetime = }")
print(f"{int(sf) = }")

result:
current time: 2023-08-30 17:05:43.994868
generate snowflake id:<PHONE_NUMBER>159582209
sf.timestamp =<PHONE_NUMBER>994
sf.instance = 42
sf.epoch = 0
sf.seq = 1
sf.seconds =<PHONE_NUMBER>.994
sf.milliseconds =<PHONE_NUMBER>994
sf.datetime = datetime.datetime(2023, 8, 30, 9, 5, 43, 994000)
int(sf) =<PHONE_NUMBER>159582209

42 is machine_ID,
epoch is start time of your system, and you can choose start_time
You can see an example here

Thanks for your reply. It took several days, but I finally got it completely figured out.🥹


Throw an error if translation strings have not been committed

Trying to fix #1430
We run a pre-commit hook that checks whether the contents of src/locales/translations is dirty (has uncommitted changes). If so, a message is printed and the script exits with an error code of 1.
This ensures that any changes to the translations strings are committed, which reduces the chances of having a missing translation string in a production deployment (this was the cause of the original issue).

@biwano Do you have any initial thoughts on this, before I kick it up to the senior devs?

Hi @0xJem! yarn lingui:extract is really long to execute. I am not a fan of adding it as a precommit hook.
We could run it in the production builds before yarn lingui:compile for instance.

I don't think it takes much longer than the current lint-staged pre-commit hook, but you're right that the two combined would take a lot of time.
I don't see anything related to deployment on Fleek in the repository. Is it kept elsewhere? Or is it done through the interface? Who can we speak to about adding yarn lingui:extract to the deployment steps?

If I remember correctly I worked with @appleseed-iii and @jesus-eff

I don't think it takes much longer than the current lint-staged pre-commit hook, but you're right that the two combined would take a lot of time.
I don't see anything related to deployment on Fleek in the repository. Is it kept elsewhere? Or is it done through the interface? Who can we speak to about adding yarn lingui:extract to the deployment steps?

yarn lingui:extract is not run in the deploy process.
We only run yarn lingui:branch:main && yarn install && yarn build

I agree the pre-commit hook would be slow & that kills me personally.

You're right. It's slow enough as-is.

Can we just make it a github action?

We could, but then we'd need to enable the GitHub Action to commit to the translations repo, which means messing around with SSH keys, etc. Very messy.
If we modify the deploy process (run in CI?) to run yarn:lingui:extract, then it should solve this issue.

If we modify the deploy process (run in CI?) to run yarn:lingui:extract, then it should solve this issue.

cool let's mess with that. I'm going to set up a branch deploy for this.


#4833 ADD: cn function

What does this PR do?
This PR allows custom css addition to CommandInput
Fixes #4833

@DevJobalia so the reason I did not do that is that most of the time, you'd want to add the className to the input (instead of the wrapper). To add to the wrapper you can use arbitrary selectors: [&_[cmdk-input-wrapper]]:some-classes on a parent component. See <CommandDialog />.
Please reopen if you think we can improve this.

@shadcn that was a new learning for me.
Thanks man, Admire and use your work 😂🔥


Failed to connect over Serial (Arch Linux)

I'm trying to connect to the Teensy from Arch Linux (OrangePi CM4 board).
When I list usb devices, I'm able to find the device:
Bus 002 Device 002: ID 16c0:048a Van Ooijen Technische Informatica M8
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Chromium asked me if I'd allow to connect to Teensy, and I confirmed that.
There's no dialout group here, and the equivalent group should be uucp. I added my user to that group, but still nothing.
Btw. the same happend when I tried to connect from RPi 4 with their default OS.
Any ideas what might have went wrong?

Aaaagh.... I had to log out/in after I added a user into the group!

But anyways, you can update the readme with info about Arch - the group to use is definitively uucp


Search aliases added for 404 and 500 pages

Now when you use the search box, you can type in 404 to get the ‘page not found’ page as a result. And 500 to get the ‘There's a problem with the service’ pages.

You can preview this change here:
Built with commit e2a6bf5f510c770c83f54d6cf47b0a2cc3822009
https://deploy-preview-945--govuk-design-system-preview.netlify.com


Add copyright to source files

Signed-off-by: Cari Dean<EMAIL_ADDRESS>

@gcheadle-vmware Please sign the Contributor License Agreement!
Click here to manually synchronize the status of this Pull Request.
See the FAQ for frequently asked questions.

@gcheadle-vmware Thank you for signing the Contributor License Agreement!


build: fix generated version on a tag

Proposed changes

Fix a build issue where the version generation when on a tag.
Before
0.13.1~0.13.0+0.13.0

After
0.13.0

Types of changes

[x] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Improvement (general improvements like code refactoring that doesn't explicitly fix a bug or add any new functionality)
[ ] Documentation Update (if none of the other choices apply)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Paste Link to the issue

Checklist

[x] I have read the CONTRIBUTING doc
[x] I have signed the CLA (in all commits with git commit -s)
[ ] I ran cargo fmt as mentioned in CODING_GUIDELINES
[ ] I used cargo clippy as mentioned in CODING_GUIDELINES
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have added necessary documentation (if appropriate)

Further comments

Forced merging to not block the release


iojs 3.0.0 support

iojs --version
v3.0.0

npm --version
2.13.4

I do this:
npm install --save-dev forever
Part of output:
><EMAIL_ADDRESS>install /Users/dsxack/workspace/src/unpublished/forever-test/node_modules/forever/node_modules/forever-monitor/node_modules/chokidar/node_modules/fsevents
> node-gyp rebuild

gyp: /Users/dsxack/.node-gyp/3.0.0/common.gypi not found (cwd: /Users/dsxack/workspace/src/unpublished/forever-test/node_modules/forever/node_modules/forever-monitor/node_modules/chokidar/node_modules/fsevents) while reading includes of binding.gyp while trying to load binding.gyp
gyp ERR! configure error
gyp ERR! stack Error: `gyp` failed with exit code: 1
gyp ERR! stack     at ChildProcess.onCpExit (/Users/dsxack/.nvm/versions/io.js/v3.0.0/lib/node_modules/npm/node_modules/node-gyp/lib/configure.js:357:16)
gyp ERR! stack     at emitTwo (events.js:87:13)
gyp ERR! stack     at ChildProcess.emit (events.js:172:7)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:200:12)
gyp ERR! System Darwin 14.4.0
gyp ERR! command "/Users/dsxack/.nvm/versions/io.js/v3.0.0/bin/iojs" "/Users/dsxack/.nvm/versions/io.js/v3.0.0/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /Users/dsxack/workspace/src/unpublished/forever-test/node_modules/forever/node_modules/forever-monitor/node_modules/chokidar/node_modules/fsevents
gyp ERR! node -v v3.0.0
gyp ERR! node-gyp -v v2.0.2
gyp ERR! not ok
npm WARN optional dep failed, continuing<EMAIL_ADDRESS>
I found #49, but i dont understand, how to use pangyp for this case

The npm that ships with io.js v3.0.0 is v2.13.3 and it contains a few patches that tell it where to download the io.js tarball.
Going by the fact that the version number is different and that you don't seem to have the sources installed, I speculate that you upgraded npm manually?

@DsXack try this
$ npm install pangyp -g
$ npm install --save-dev forever --node-gyp=pangyp

@fundon, thank! it works!


Use MSTest metapackage to simplify MSTest setup

Use the MSTest metapackage, which includes:

Microsoft.NET.Test.Sdk
MSTest.Analyzers
MSTest.TestAdapter
MSTest.TestFramework

In addition to including the analyzers package, this simplifies the dependencies and setup.

nice. thanks


Narrow from 'any' with all type guards

Fixes #4432.

I was about to submit the same PR yesterday. https://github.com/tinganho/TypeScript/commit/3ea297d3b34bc4dfd62c9f74b4f3004a5f663c19

Sorry you went through that, I didn't mean to step on anyone's feet! Though in the future if you'd like to take an assigned bug on, just post a quick message on the issue saying so.

Oh no problem. I was just thinking it was a small change and that I could quickly submit it. I didn't lose that much time. I will send a small notification next time.

LGTM, a few comments though

please update test comments
please run the RWC tests and verify if there are any unexpected failures/ failures we need to know about
log a spec issue to update the spec.

We should close this one as well.

Is this commit already merged in master? I :heart: this changes.

@vvakame, no, the problem is that instanceof type guards can have bad behavior when you do something like x instanceof Object - now you can access effectively nothing. By extension, user-defined type guards are weakened down to instanceof guards. It's not optimal, but we're still considering the issue.

I understand!


(wip) (feat)add script to scaffold experiment artifacts

Signed-off-by: ksatchit<EMAIL_ADDRESS>
What this PR does / why we need it:
Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #
Checklist

[ ] Does this PR have a corresponding GitHub issue?
[ ] Have you included relevant README for the chaoslib/experiment with details?
[ ] Have you added debug messages where necessary?
[ ] Have you added task comments where necessary?
[ ] Have you tested the changes for possible failure conditions?
[ ] Have you provided the positive & negative test logs for the litmusbook execution?
[ ] Does the litmusbook ensure idempotency of cluster state?, i.e., is cluster restored to original state?
[ ] Have you used non-shell/command modules for Kubernetes tasks?
[ ] Have you (jinja) templatized custom scripts that is run by the litmusbook, if any?
[ ] Have you (jinja) templatized Kubernetes deployment manifests used by the litmusbook, if any?
[ ] Have you reused/created util functions instead of repeating tasks in the litmusbook?
[ ] Do the artifacts follow the appropriate directory structure?
[ ] Have you isolated storage (eg: OpenEBS) specific implementations, checks?
[ ] Have you isolated platform (eg: baremetal kubeadm/openshift/aws/gcloud) specific implementations, checks?
[ ] Are the ansible facts well defined? Is the scope explicitly set for playbook & included utils?
[ ] Have you ensured minimum/careful usage of shell utilities (awk, grep, sed, cut, xargs etc.,)?
[ ] Can the limtusbook be executed both from within & outside a container (configurable paths, no hardcode)?
[ ] Can you suggest the minimal resource requirements for the litmusbook execution?
[ ] Does the litmusbook job artifact carry comments/default options/range for the ENV tunables?
[ ] Has the litmusbooks been linted?

Special notes for your reviewer:

Few more changes pending on this PR:

Fix Travis build to use locally built image for syntax check
Add PR description
More comments on generate_chart.py

Few more changes pending on this PR:

Fix Travis build to use locally built image for syntax check
Add PR description
More comments on generate_chart.py
Move content to a dev guide or contribute folder

These changes have been made. However, the fork was destroyed/recreated in the meanwhile causing the source branch invalid. A new PR will be created for the same.
Apologies @Sanjay1611 @chandankumar4 !


Fix block in e2e test

What type of PR is this?

/kind failing-test
/kind flake
What this PR does / why we need it:
e2e is always blocked (more than 24 hours), which functions simply to get all e2e testcases, but I haven't found the exact reason for this yet. I used a workaround.
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?

NONE

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

NONE

/override pull-kwok-e2e-test-main


Fix to allow Mini Map to use the same baselayer settings as the main map

While MiniMap can't use the exact same TileLayer object as the primary map, it can use the same settings and follow the users selection. This PR adds this as standard behaviour, and exposes createDefaultBaseMapLayers from boot.js.

This will break if additional base layers are added via plugins.


Create Musashi execution context

Currently the Musashi integration is a bunch of callback functions that poke one (and soon several) static variables.
We should gather up the static variables into a single execution context, move logic from Musashi-specific callback functions to functions that handle the execution context, and thereby create a concept of logic+data for a "Musashi when being used to run tests" execution context.
The execution context will be a natural place to gather other information like trace messages as well.

Done!
The implementation is not very pretty; it revolves around a mutable raw pointer, but it ought to work for our purposes.


Drop support for ADTypes 0.2

ADTypes 0.2 doesn't support AutoTapir yet.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
0

Relevant Lines:
1529

💛  - Coveralls

The standard approach for fixing a bug is through a new release instead of reversing a release, right?

People seem to have quite diverse (and strong) opinions on this matter 😄 But some maintainers of the registry are definitely not happy about yanking releases. However, as stated in the README

There is however, a special category of bugged releases that can not be resolved by having a patch release. These also may to be resolved by yanking. That special category is when the compat bounds have been set too wide. i.e. say v2.10.0 was released using a feature not on julia v1.6 but the compat entry for julia was not raised in the release. In this case releasing a v2.10.1 with the corrected julia compat would not solve the issue as on julia v1.6 Pkg would still resolve the broken v2.10.0, and as a minor bump, reverting the code changes would not be valid in a patch bump. In this case one may either submit a PR to retroactively adjust the compat bounds of previous versions (best user-facing results, but slow and error-prone to implement) or yank the offending release.

Great! Approving now then.


Dependecy upgrades

Breaking change

Proposed change

Type of change

[x] Dependency upgrade
[ ] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (which adds functionality to an existing integration)
[ ] Breaking change (fix/feature causing existing functionality to break)
[ ] Code quality improvements to existing code or addition of tests

Additional information

This PR fixes or closes issue: fixes #
This PR is related to issue:
Link to documentation pull request:

Checklist

[x] The code change is tested and works locally.
[x] Local tests pass. Your PR cannot be merged unless tests pass
[ ] There is no commented out code in this PR.
[ ] I have followed the [development checklist][dev-checklist]
[ ] The code compiles without warnings (code quality chek)
[ ] Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

[ ] Documentation added/updated for www.home-assistant.io

Codecov Report

Merging #47 (b34cbca) into dev (b497cc2) will decrease coverage by 0.04%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##              dev      #47      +/-   ##
==========================================
- Coverage   62.63%   62.59%   -0.05%
==========================================
  Files         179      179
  Lines        6667     6667
  Branches      927      927
==========================================
- Hits         4176     4173       -3
- Misses       2157     2158       +1
- Partials      334      336       +2

Flag
Coverage Δ

unittests
62.59% <ø> (-0.05%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...mon.HassClient/Internal/Net/WebSocketClientImpl.cs
72.41% <0.00%> (-3.45%)
:arrow_down:

...pp/NetDaemon.App/Common/Reactive/NetDaemonRxApp.cs
82.20% <0.00%> (-1.70%)
:arrow_down:

...rc/Daemon/NetDaemon.Daemon/Daemon/NetDaemonHost.cs
55.87% <0.00%> (+0.29%)
:arrow_up:

Continue to review full report at Codecov.

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

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
5 unchanged lines in 3 files lost coverage.
Overall coverage decreased (-0.03%) to 63.197%

Files with Coverage Reduction
New Missed Lines
%

src/Client/NetDaemon.HassClient/Internal/Net/WebSocketClientImpl.cs
1
62.16%

src/Daemon/NetDaemon.Daemon/Daemon/NetDaemonHost.cs
1
60.75%

src/App/NetDaemon.App/Common/Reactive/NetDaemonRxApp.cs
3
85.44%

Totals

Change from base Build<PHONE_NUMBER>:
-0.03%

Covered Lines:
4505

Relevant Lines:
6666

💛  - Coveralls


Add complexity report to html output

This PR is with respect to issue discussed at #2046 .
Currently, Complexity report is only printed as part of console output.
This PR attempts to push complexity report as part of the HTML output in a <div> container.

Codecov Report

Merging #2071 into master will decrease coverage by 0.05%.
The diff coverage is 88.88%.

@@             Coverage Diff              @@
##             master    #2071      +/-   ##
============================================
- Coverage     80.59%   80.54%   -0.06%
- Complexity     1988     2006      +18
============================================
  Files           332      336       +4
  Lines          5705     5776      +71
  Branches       1042     1061      +19
============================================
+ Hits           4598     4652      +54
- Misses          554      563       +9
- Partials        553      561       +8

Impacted Files
Coverage Δ
Complexity Δ

...tlab/arturbosch/detekt/cli/out/HtmlOutputReport.kt
91.8% <88.88%> (+1.41%)
17 <4> (+4)
:arrow_up:

...turbosch/detekt/api/internal/SimpleNotification.kt
50% <0%> (-50%)
1% <0%> (ø)

...osch/detekt/rules/style/OptionalAbstractKeyword.kt
83.33% <0%> (-8.34%)
6% <0%> (ø)

...n/kotlin/io/gitlab/arturbosch/detekt/api/Entity.kt
84.61% <0%> (-7.7%)
4% <0%> (-1%)

...tlin/io/gitlab/arturbosch/detekt/api/YamlConfig.kt
82.6% <0%> (-3.76%)
8% <0%> (ø)

...b/arturbosch/detekt/rules/complexity/LargeClass.kt
93.75% <0%> (-3.13%)
12% <0%> (ø)

...rbosch/detekt/rules/complexity/TooManyFunctions.kt
96.77% <0%> (-1.62%)
26% <0%> (ø)

.../io/gitlab/arturbosch/detekt/cli/runners/Runner.kt
87.8% <0%> (-1.49%)
9% <0%> (+3%)

...kotlin/io/gitlab/arturbosch/detekt/api/Findings.kt
60% <0%> (ø)
0% <0%> (ø)
:arrow_down:

...ain/kotlin/io/gitlab/arturbosch/detekt/cli/Main.kt
0% <0%> (ø)
0% <0%> (ø)
:arrow_down:

... and 16 more

Continue to review full report at Codecov.

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

Thanks! This is an awesome contribution.

Nevermind. It was a pleasure 😄


update gpu run instructions to be step-by-step and not narrative

This is narrative

running with a gpu would presumably require a flag along with sinteractive, but it might be possible to invoke it from the compute node -- I'll look into this now
from sinteractive --help I see that the flag you can use for a gpu is --gres=gpu:1 (the full list of flag options is given at sbatch --help, gres is "generic resources")

But, we want there to be step-by-step things that provide instruction and an example

should be better now!


What is the cause of this mistake？

Instructions for updating:
Please use rate instead of keep_prob. Rate should be set to rate = 1 - keep_prob.
Traceback (most recent call last):
File "train.py", line 377, in
main()
File "train.py", line 314, in main
detect_quadrangle=args.detect_quadrangle
File "/home/kxm/EfficientDet-master/model.py", line 241, in efficientdet
class_head = build_class_head(w_head, d_head, num_classes=num_classes, num_anchors=num_anchors)
File "/home/kxm/EfficientDet-master/model.py", line 211, in build_class_head
)(outputs)
File "/home/kxm/anaconda3/lib/python3.6/site-packages/tensorflow/python/keras/engine/base_layer.py", line 538, in call
self._maybe_build(inputs)
File "/home/kxm/anaconda3/lib/python3.6/site-packages/tensorflow/python/keras/engine/base_layer.py", line 1603, in _maybe_build
self.build(input_shapes)
File "/home/kxm/anaconda3/lib/python3.6/site-packages/tensorflow/python/keras/layers/convolutional.py", line 174, in build
dtype=self.dtype)
File "/home/kxm/anaconda3/lib/python3.6/site-packages/tensorflow/python/keras/engine/base_layer.py", line 349, in add_weight
aggregation=aggregation)
File "/home/kxm/anaconda3/lib/python3.6/site-packages/tensorflow/python/training/checkpointable/base.py", line 607, in _add_variable_with_custom_getter
**kwargs_for_getter)
File "/home/kxm/anaconda3/lib/python3.6/site-packages/tensorflow/python/keras/engine/base_layer_utils.py", line 145, in make_variable
aggregation=aggregation)
File "/home/kxm/anaconda3/lib/python3.6/site-packages/tensorflow/python/ops/variables.py", line 213, in call
return cls._variable_v1_call(*args, **kwargs)
File "/home/kxm/anaconda3/lib/python3.6/site-packages/tensorflow/python/ops/variables.py", line 176, in _variable_v1_call
aggregation=aggregation)
File "/home/kxm/anaconda3/lib/python3.6/site-packages/tensorflow/python/ops/variables.py", line 155, in
previous_getter = lambda **kwargs: default_variable_creator(None, **kwargs)
File "/home/kxm/anaconda3/lib/python3.6/site-packages/tensorflow/python/ops/variable_scope.py", line 2488, in default_variable_creator
import_scope=import_scope)
File "/home/kxm/anaconda3/lib/python3.6/site-packages/tensorflow/python/ops/variables.py", line 217, in call
return super(VariableMetaclass, cls).call(*args, **kwargs)
File "/home/kxm/anaconda3/lib/python3.6/site-packages/tensorflow/python/ops/resource_variable_ops.py", line 294, in init
constraint=constraint)
File "/home/kxm/anaconda3/lib/python3.6/site-packages/tensorflow/python/ops/resource_variable_ops.py", line 406, in _init_from_args
initial_value() if init_from_fn else initial_value,
File "/home/kxm/anaconda3/lib/python3.6/site-packages/tensorflow/python/keras/engine/base_layer_utils.py", line 127, in
shape, dtype=dtype, partition_info=partition_info)
TypeError: call() got an unexpected keyword argument 'partition_info'

Hi @kongxm889 , which tf version are you using? You can try under tf 1.15 and tf 2.x.

但是又出现啦以下提示：python: symbol lookup error: /home/kxm/anaconda3/lib/python3.6/site-packages/numpy/core/../../../../libmkl_intel_thread.so: undefined symbol: omp_get_num_procs

However, the following prompt appears:python: symbol lookup error: /home/kxm/anaconda3/lib/python3.6/site-packages/numpy/core/../../../../libmkl_intel_thread.so: undefined symbol: omp_get_num_procs

I have no idea. But you can try this https://github.com/ContinuumIO/anaconda-issues/issues/10195#issuecomment-429544158

i,don't know,this is my mistakes
tensorflow.python.framework.errors_impl.UnknownError: 2 root error(s) found.
(0) Unknown: Failed to get convolution algorithm. This is probably because cuDNN failed to initialize, so try looking to see if a warning log message was printed above.
[[{{node stem_conv/Conv2D}}]]
[[filtered_detections/map/while/Identity/_2790]]
(1) Unknown: Failed to get convolution algorithm. This is probably because cuDNN failed to initialize, so try looking to see if a warning log message was printed above.
[[{{node stem_conv/Conv2D}}]]
0 successful operations.
0 derived errors ignored.

ValueError: Layer #337 (named "box_head"), weight <tf.Variable 'conv2d_3/kernel:0' shape=(3, 3, 64, 108) dtype=float32> has shape (3, 3, 64, 108), but the saved weight has shape (36, 64, 3, 3).
What's the problem

@kongxm889 I had the same problem some time ago. For me it was a problem with cuda and anaconda. For me the post from Bahramudin solved it: https://github.com/tensorflow/tensorflow/issues/24828


API clients send Content-Type even when Content-Length is empty

The generated API clients should remove the Content-Type request header when the request body is empty, (e.g. Content-Length=0) for structured payloads.  The API clients probably should still send Content-Type for operations with streaming inputs.
Protocol test should also be created for this use case for the REST-JSON protocol, and any other protocol that can serialize empty request body for structured payloads.

This issue is no longer needed. There is no direct relationship between content-length=0 and content-type. It would be a potential optimization to not set the content-type request header if the operation is not modeled input parameters.


Configuring with pyproject.toml

Summary
This PR is an extension of #bolt-996 and aims to follow its spirit. It introduces changes that make the pyproject.toml file the default configuration file for python-slack-sdk
The setup.py file is now used as support for "legacy" commands in this project
Requirements File Format pattern is used to import test dependencies. This creates a clear distinction between the project dependencies and the development dependencies.
Category

[ ] slack_sdk.web.WebClient (sync/async) (Web API client)
[ ] slack_sdk.webhook.WebhookClient (sync/async) (Incoming Webhook, response_url sender)
[ ] slack_sdk.socket_mode (Socket Mode client)
[ ] slack_sdk.signature (Request Signature Verifier)
[ ] slack_sdk.oauth (OAuth Flow Utilities)
[ ] slack_sdk.models (UI component builders)
[ ] slack_sdk.scim (SCIM API client)
[ ] slack_sdk.audit_logs (Audit Logs API client)
[ ] slack_sdk.rtm_v2 (RTM client)
[ ] /docs-src (Documents, have you run ./scripts/docs.sh?)
[ ] /docs-src-v2 (Documents, have you run ./scripts/docs-v2.sh?)
[ ] /tutorial (PythOnBoardingBot tutorial)
[ ] tests/integration_tests (Automated tests for this library)

Requirements

[x] I've read and understood the Contributing Guidelines and have done my best effort to follow them.
[x] I've read and agree to the Code of Conduct.
[x] I've run python3 -m venv .venv && source .venv/bin/activate && ./scripts/run_validation.sh after making the changes.

@Jamim thanks a lot for the review, got some good catches 💯

I realized this morning that this PR may change the behavior of of the pip show slack-sdk command
previously
Name: slack-sdk
Version: 3.26.0
Summary: The Slack API Platform SDK for Python
Home-page: https://github.com/slackapi/python-slack-sdk
Author: Slack Technologies, LLC
Author-email<EMAIL_ADDRESS>License: MIT
Location: /Users/wbergamin/Documents/slack/tools/experiments/python_func_handler_mvp/env_3_11_2/lib/python3.11/site-packages
Requires:
Required-by: slack-bolt

New
Name: slack-sdk
Version: 3.26.0
Summary: The Slack API Platform SDK for Python
Home-page:
Author:
Author-email: "Slack Technologies, LLC"<EMAIL_ADDRESS>License: MIT
Location: /Users/wbergamin/Documents/slack/tools/experiments/python_func_handler_mvp/env_3_11_2/lib/python3.11/site-packages
Requires:
Required-by: slack-bolt

I'm not sure who or how developers may use this command but these changes could change their flow

@seratch let me know if the output of this command needs to be maintained, I believe it can be done by adding some fields in a setup.cfg file (this can also be added in a follow up PR)

@WilliamBergamin Yeah, we should keep those metadata too. Can you make the changes for the compatibility?

@seratch I've added the necessary changes to maintain the behavior of the pip show slack-sdk command
here is the output
Name: slack-sdk
Version: 3.26.0b1
Summary: The Slack API Platform SDK for Python
Home-page: https://github.com/slackapi/python-slack-sdk
Author: Slack Technologies, LLC
Author-email<EMAIL_ADDRESS>License: MIT
Location: /Users/wbergamin/Documents/slack/tools/python-slack-hooks/env_3.11.2/lib/python3.11/site-packages
Requires:
Required-by:

I've also deployed to https://test.pypi.org/project/slack-sdk I believe the deploy behavior is maintained


Stretching mechanism

Added new stretching mechanism in the fashion of JWPlayer

Ron, this looks great, and I wanted to merge it with the others, but it can't merge with the changes to the /build/ folder. Could you fix that, so I can do both merges?
Thanks!

@johndyer Thanks for pointing it out. Let me fix it quickly

@johndyer Done. The build folder is now the way it was before

I'm gonna recreate this branch, since it's still giving me conflicts for some reason. I'll let you know when it's ready but shouldn't take me more than 15 min

Thanks!

Might check on the tabbing...


[AIRFLOW-548] Run continously by default and pickup dags immediately

Dear Airflow Maintainers,
Please accept this PR that addresses the following issues:

AIRFLOW-548

Per Apache guidelines you need to create a Jira issue.
Testing Done:

Local testing

Reminders for contributors (REQUIRED!):

Your PR's title must reference an issue on
Airflow's JIRA.
For example, a PR called "[AIRFLOW-1] My Amazing PR" would close JIRA
issue #1. Please open a new issue if required!
Please squash your commits when possible and follow the How to write a good git commit message.
Summarized as follows:

Separate subject from body with a blank line
Limit the subject line to 50 characters
Do not end the subject line with a period
Use the imperative mood in the subject line (add, not adding)
Wrap the body at 72 characters
Use the body to explain what and why vs. how

A recent commit has changed the scheduler behavior that it now
always stops after a specified period of time. The operation scripts
(systemd etc) are not updated for this behavior and many users actually
prefer to run the scheduler continously.
Secondly the default behavior was changed to not pickup new DAGs
immediately, this has lead to confusion with users.
@plypaul @mistercrunch @aoen @r39132 @btallman

Current coverage is 65.97% (diff: 100%)

Merging #1823 into master will increase coverage by 0.06%

@@             master      #1823   diff @@
==========================================
  Files           127        127
  Lines          9674       9674
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           6376       6382     +6
+ Misses         3298       3292     -6
  Partials          0          0

Powered by Codecov. Last update 4d567f4...04005b0

LGTM

LGTM. Tested with both LocalExecutor and SequentialExecutor, the former being much faster than the latter.

Thanks @bolkedebruin! Apologies, I though I had made the changes earlier, but looking back, it seems that the other PR had some issues. The updated comments in the other PR would be good to have at least, so I am going to try to refresh it.


feat: theme with body class instead of document element for unocss compatibility

Hi !
First, thanks for this awesome template, love it :heart_eyes:
I also really like unocss, so I forked your repository to use unocss instead of tailwindcss, here.
I use unocss-preset-shadcn, but this preset doesn't accept theming with color and dark class like it's currently done, ex : <html class="theme-red dark"....
So I had to change how class theme is set in the app. I used body instead of html document.
With this request changes, it will be easier to switch to unocss !

Thanks!


[DO NOT MERGE] Set Whitehall document attachments to be file_attachment_asset

Prior to this being merged https://github.com/alphagov/whitehall/pull/5448 will have to be merged and deployed to production.
Previously all of these documents were set to use the publication attachment schemas, however none of these documents make use of publication specific fields or types. Thus this reduces the options that can apply at a schema level for them.
@barrucadu I've opened this up and marked it as a draft prior to you get your input on this. I'm wondering if there was a reason these document types were set as publication attachment assets in the first place that I've missed and/or if there are consequences to this change? might it break any Whitehall document types.

As long as we're sure that none of these formats (eg) allow HTML or external attachments, this seems fine.

Thanks Michael - turns out all of them were leaking publication data into Publishing API I've opened https://github.com/alphagov/whitehall/pull/5448 to try resolve them. May need to get some tips from you on how to represent everything to clear that up.


Web page not opening

The web page http://react-toolbox.com is not opening, it is only loading a blank page.

It was a problem with react-css-themr. It should work now :)

Thanks (Y)


[release-1.17] Run update_deps.sh

Run update_deps.sh against the 1.17 branch

@johnma14: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio_release-1.17
5d5e10cbb58aebb97226994b3495cd94e025eea2
link
true
/test release-notes

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test release-notes


[Snyk] Security upgrade nuxt from 2.13.3 to 2.15.0

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to fix one or more vulnerable packages in the `yarn` dependencies of this project.
Changes included in this PR

Changes to the following files to upgrade the vulnerable dependencies to a fixed version:

package.json
yarn.lock

Vulnerabilities that will be fixed
With an upgrade:

Severity
Priority Score (*)
Issue
Breaking Change
Exploit Maturity

713/1000  Why? Proof of Concept exploit, Recently disclosed, Has a fix available, CVSS 6.4
Prototype Pollution SNYK-JS-JSON5-3182856
No
Proof of Concept

(*) Note that the real score may have changed since the PR was raised.
Check the changes in this PR to ensure they won't cause issues with your project.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
🛠 Adjust project settings
📚 Read more about Snyk's upgrade and patch logic

Learn how to fix vulnerabilities with free interactive lessons:
🦉 Prototype Pollution

👷 Deploy Preview for compassionate-mclean-280ff5 processing.

Name
Link

🔨 Latest commit
f89c701043ee716bd5784ad942b7ee81ddd9fbb8

🔍 Latest deploy log
https://app.netlify.com/sites/compassionate-mclean-280ff5/deploys/63a87ffb5ceaef000832563c


optic lobe intrinsic neurons missing subclass relationship to lobula intrinsic neurons

lobula plate intrinsic neuron LPi [FBbt_00003910] and its descendants are not optic lobe intrinsic neuron [FBbt_00007577] which would be more useful than unilateral intrinsic neuron [FBbt_00003988] as currently. Can we change this?
Others missing:
‘lobula intrinsic neuron ChaLinew1’
‘lobula intrinsic neuron Li1’
‘lobula intrinsic neuron Li2’
‘lobula plate intrinsic neuron ChaLPinew1’
My preference would be to make general classes for intrinsic neurons of each of the neuropils of the optic lobe with these being subclasses of optic lobe intrinsic neuron.  We can potentially formalise/automate (but shouldn’t let that slow down a fix).

I am reclassifying lobula plate intrinsic neuron LPi as optic lobe intrinsic neuron in #1631.
This indirectly makes lobula plate intrinsic neuron ChaLPinew1 a subclass of [optic lobe intrinsic neuron]s(http://purl.obolibrary.org/obo/FBbt_00007577) as well.
As for lobula intrinsic neuron ChaLinew1, lobula intrinsic neuron Li1, and lobula intrinsic neuron Li2, they are already classified as optic lobe intrinsic neuron through their superclasses lobula intrinsic neuron and optic lobe intrinsic columnar neuron.
Leaving this ticket open to remind us to create the general classes for intrinsic neurons of each optic lobe neuropil (manually or not).


Output format and option enumeration

For any particular file format (or ImageOutput), it should be possible for an app to ask for the list of output data formats that are supported, as well as what compression methods it allows.
Also, ImageInput's and ImageOutput's should perhaps both be able to enumerate all of the special, format-specific, or nonstandard metadata options or configurations that they support.
There are probably more things.  There should be a general query-based API for this kind of thing rather than add one-off API calls every time we think of something like this.
Once it's all in place, oiiotool should have options to print this helpful info about any particular format.

Queries about the formats and extensions were added a long time ago. oiiotool prints it with --help is used. Most of this has been done, closing.


Fix: bower dependency on angular

This fix should avoid unnecessary dependency warning in bower for angular version newer than 1.4.3.

Thanks @roger2hk


Change Kinetic API endpoints to only accept environment and index per header

Currently, the environment is passed in in the PATH of the URL for most of the requests, but it's a bit weird and inconsistent.
A cleaner solution would be to use the kinetic-environment and kinetic-index properties from the header that we already send with any request coming from the SDKs.

The only downside I can think of is that you can't load up an endpoint in your browser, but considering this is not a feature and is easy to replace with a curl request I think it's not a big deal.

@beeman this is interesting. We might want to revisit our current SDK generators and make sure they take in account the headers to generate the code without any issues. I believe all the ones that we are using so far are already stable versions, so it should be there. Perhaps the current ones that we are using support it, but also need to think about some future ones.


Fewer transcripts in IsoSeq3 results

I encountered the similar situation in #9  when using IsoSeq3. Number of output sequences are rather small after running ccs, lima and cluster. Results from four sequenced samples are shown below.

number of cell
ccs
lima output
flnc
cluster output

two Sequel cells
657596
377730
374075
21963

one Sequel cell
477726
339985
335901
24446

eight RSII cells
776341
376000
374706
20564

five RSII cells
431389
103764
102718
4745

I have double checked that there was nothing wrong with primers (recommended Clontech primer were used in the experiments). And following commands were executed.

ccs --minPasses 0 --maxDropFraction 0.8 --minPredictedAccuracy 0.8
isoseq3 lima ccs.bam primers.fasta demux.ccs.bam --isoseq
isoseq3 cluster lima_combined.consensusreadset.xml unpolished.bam --split-bam 12
The first two steps, ccs and lima, were run in parallel and combined lima output was used to run cluster.

It has been stated in FAQ that fewer transcripts are produced with IsoSeq3 compared to IsoSeq1/2. But how much fewer can be considered reasonable? Are the numbers in my results normal?

IsoSeq3 only works with full-length transcripts, thus lima will remove plenty of non full-length transcripts that have less than 1 pass. You can study the *.lima.summary files to get a feeling for that.
Fewer transcript than what? Did you run an older IsoSeq workflow or a different algorithm to compare against or is it a gut feeling? 20k full-length transcripts are very reasonable!

Hi @armintoepfer ,
Thanks for the reply.
I have run IsoSeq2 on the last case with five RSII cells. Clustering output 83334 consensus isoforms and 8851 HQ isoforms were obtained after polishing. Over 70k reads were classified into LQ isoforms because of only having one full-length transcript covered.
The other three cases did not get cluster results with IsoSeq1 or IsoSeq2 due do large cluster (>100k reads) generated at precluster step. It stuck at iceiterative and I could not get it through. However, collapsing using HQ isoforms and corrected LQ isoforms could produce more than 30k unique isoforms with around one million ZMWs (1~2 Sequel cells or 5~8 RSII cells) according to previous projects using IsoSeq1 or IsoSeq2.

There are many factors that play into getting fewer final transcripts for the five RSII cells, but internal benchmarks and beta customer feedback point, similarly to your experience, to the same conclusion: there are fewer but longer transcripts that reconstruct more known splice sites. Our spike-in controls even show a higher recovery rate. If I were you, I'd forget about the old results and focus on the latest version.

Got it! Thanks.


Add a Gitter chat badge to README.md

Azure/azure-documentdb-node now has a Chat Room on Gitter
@aliuy has just created a chat room. You can visit it here: https://gitter.im/Azure/azure-documentdb-node.
This pull-request adds this badge to your README.md:

If my aim is a little off, please let me know.
Happy chatting.
PS: Click here if you would prefer not to receive automatic pull-requests from Gitter in future.

Hi @gitter-badger, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no contribution license agreement is required at this point. Real humans will now evaluate your PR.

TTYL, AZPRBOT;


ResNet giving different outputs in TF and TFLite in C++

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): Yes
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Linux CentOS 8
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device: N/A
TensorFlow installed from (source or binary): binary
TensorFlow version (use command below): 2.3.2
Python version: 3.6.8
Bazel version (if compiling from source): N/A
GCC/Compiler version (if compiling from source): 8.3.1

Describe the current behavior
ResNet36 (and ResNet50) models give different outputs when running inference on TensorFlow and TensorFlow-Lite in C++.
Describe the expected behavior
Outputs should be same across all platforms and across different APIs.
Standalone code to reproduce the issue
Due to certain restrictions, I won't be able to provide fully reproducible code. Following are some snippets :
Model :
base_model = tf.keras.applications.ResNet50(
    include_top=False, weights='imagenet',
    input_shape=[96,112,3])

x = base_model.output
x = tf.keras.layers.Flatten()(x)
x = tf.keras.layers.Dense(128, use_bias=True, name='Bottleneck')(x)

model = tf.keras.models.Model( base_model.input, x )

TFLite inference :
std::unique_ptr<tflite::FlatBufferModel> flat_buffer_model = tflite::FlatBufferModel::BuildFromBuffer((const char*)model_buffer->data(), model_buffer->size(), &err_reporter);
tflite::ops::builtin::BuiltinOpResolver builtins;
std::unique_ptr<tflite::Interpreter> interpreter;
tflite::InterpreterBuilder(*flat_buffer_model, builtins)(&interpreter);

const std::vector<int>& outputs = thread_interpreter.interpreter_->outputs();
TfLiteStatus tf_stat = thread_interpreter.interpreter_->Invoke();

Other info / logs
I have a ResNet36 model trained using TFv1 and saved into a protobuf file format. This is used to generate inference on sample image using TensorFlow C API on windows.
I used tf.compat.v1.lite.converter.from_frozen_graph() to convert this protobuf to a .tflite file.
I ran inference from TFLite using C++ API (on x86_64 architecture).
Additionally, I also ran inference from the TFLite model using Python.
***All the 3 outputs are different.***
Interestingly, I also have an InceptionResNet model (.pb file from TF1 converted into .tflite file using TF2) and it gives the exact same output when I run inference in TF (C) and TFLite (C++). So, this makes me question that something is wrong with tflite converter/API specifically when dealing with ResNet architecture.
Note : I also tested ResNet50 architecture which was trained in TF2 and got similar anomalous results. (This is just to rule out any functionalities that may not have been supported by backwards compatible converter).
I am interested in knowing pointers such as gcc compiler optimizations or anything else that may cause different outputs across TensroFlow and TensorFlow-Lite in C++.
Any help is much appreciated.

@saikumarchalla Let me know if you need any more information.

Hi @suraj-maniyar , can you include the code/command you used to convert the model? In the past, the main source of different outputs in vision models is differences in the preprocessing pipeline for the image (how it is scaled and/or cropped), so if you want to include the representative code you used that would be helpful. You might also try running the TFLite Interpreter from Python with the same input to see if you get different results.

@jdduke
I used this code to convert .pb to .tflite :

import tensorflow as tf
tf.__version__
# 2.3.2

graph_def_file = "resface36_L2Norm128_at_epoch_168.pb"
converter = tf.compat.v1.lite.TFLiteConverter.from_frozen_graph(graph_def_file,
                                              ["input"],
                                              ["resface36/Bottleneck/BiasAdd"],
                                              input_shapes={'input': [1, 96, 112, 3]})
tflite_model = converter.convert()

open("resface36_L2Norm128_at_epoch_168.tflite", "wb").write(tflite_model)

As for the preprocessing pipeline, I am not even using any preprocessing on the image. I simply created a matrix of zeros of dimension 96x112 and fed it to network in TF and TFLite. I have also tested Inception ResNet and it gave exact same output in TF and TFLite. I only have problems with ResNet where the outputs don't match.
And yes, I do get different output when running TFLite interpreter from Python.
So basically, I have 3 different outputs for the same resnet model with the same input (zero matrix) on different configurations (TF on C++, TFLite on C++, TFLite on Python)

Is the output correct when using TFLite via Python? Or does TFLite provide wrong (but different) outputs via C++ & Python? It would be helpful to see the TFLite model (untrained is fine) you have, so I can take a look.
Also I assume you are doing interpreter->AllocateTensors() when using C++, before any invoke?

Hi @suraj-maniyar, can you give us a better idea on how different is different? what scale are we talking about here? These aren't usually direct 1:1 conversions, some optimizations are applied and during the whole process some precision is lost, so any additional information will be great!


New Tileset editor sometimes crashes Godot when clicking "Open in editor" from a tilemap

Godot version:
Godot 3.1 b293dd3
OS/device including version:
Windows 10 64bit
Issue description:
Create a tilemap, and create a new tileset. Add the tileset to the tilemap, and click the "Open in editor" button for the tileset. Sometimes it will open, sometimes it will crash Godot.

Probably the same error #20501. Do you have any log?

I don't have a log for it, but I think it might be related. I do sometimes crash when opening a shder with open in editor as well.

73cf0fd30524a6acc4400ef069210d90eaba29a2
Happens randomly after pressing the button, no matter which editor.
I get identical backtraces, this is from shader editor:
Thread 1 "godot" received signal SIGSEGV, Segmentation fault.
BaseButton::_unpress_group () at scene/gui/base_button.cpp:47
47		for (Set<BaseButton *>::Element *E = button_group->buttons.front(); E; E = E->next()) {
(gdb) l
42
43		if (toggle_mode) {
44			status.pressed = true;
45		}
46
47		for (Set<BaseButton *>::Element *E = button_group->buttons.front(); E; E = E->next()) {
48			if (E->get() == this)
49				continue;
50
51			E->get()->set_pressed(false);
(gdb) bt
#0  BaseButton::_unpress_group () at scene/gui/base_button.cpp:47
#1  0x0000555556997199 in BaseButton::_gui_input () at scene/gui/base_button.cpp:155
#2  0x00005555561eac76 in MethodBind1<Ref<InputEvent> >::call () at core/method_bind.gen.inc:729
#3  0x000055555774122b in Object::call_multilevel () at core/object.cpp:752
#4  0x000055555773f606 in Object::call_multilevel () at core/object.cpp:858
#5  0x0000555556872363 in Viewport::_gui_call_input () at scene/main/viewport.cpp:1439
#6  0x000055555687422c in Viewport::_gui_input_event () at scene/main/viewport.cpp:1785
#7  0x00005555568760b0 in Viewport::input () at scene/main/viewport.cpp:2477
#8  0x00005555568762b4 in Viewport::_vp_input () at scene/main/viewport.cpp:1221
#9  0x0000555555b148c7 in MethodBind1<Ref<InputEvent> const&>::call () at core/method_bind.gen.inc:729
#10 0x000055555774049c in Object::call () at core/object.cpp:918
#11 0x000055555773f56e in Object::call () at core/object.cpp:842
#12 0x00005555568a99d3 in SceneTree::call_group_flags () at scene/main/scene_tree.cpp:262
#13 0x00005555568ac9e5 in SceneTree::input_event () at scene/main/scene_tree.cpp:418
#14 0x00005555557961ad in InputDefault::_parse_input_event_impl () at main/input_default.cpp:417
#15 0x0000555555775dac in OS_X11::process_xevents () at platform/x11/os_x11.cpp:1928
#16 0x0000555555777440 in OS_X11::run () at platform/x11/os_x11.cpp:2635
#17 0x0000555555769a1c in main () at platform/x11/godot_x11.cpp:55

@guilhermefelipecgs
I ran into something that fits this description this afternoon.  Just playing around with Tilesets in 3.1.
I can't be sure, because I haven't had time to go back and test it, but it might have something to do with updating the source PNG of the whole set.  This is at least the last thing I remember doing, but I hadn't saved the scene and re-opened it after immediately after creation.  Currently any scene I make with TileMaps in 3.1 will crash with this error log:

It's still happening to me, on last build from git. Opened a new issue: https://github.com/godotengine/godot/issues/23672


After sorting, an array of same length gets rendered wrong.

Create an array of length n. Sort it. Create an array of length n again. The console logs and the length of the bars do not match.

This happens when the i'th element is in the same position again. Say n = 6 and the order on the first generation is 5 2 3 0 4 1. After sorting and generating again, if the order is, say, 2 5 0 4 3 1, then the last element (which matched with the same sort from before) gets rendered as 5. (Taller, like the sorted version) I believe it happens because it does not re-render the element because it thinks it is the same. Logging the height of the elements gives the proper height that they need to be. Dragging and dropping them onto another place makes them change to the correct height.


AttributeError: 'MosaicDetection_VID' object has no attribute 'dataset_pth'

!! Iteration after 3 epoch. !! Running for yolov_x stopped. !!
But, following the bottom structure could smoothly running for yolov_s.
pytorch 1.20, cuda 11.6.
The 'AttributeError' seems to related the path of dataset ? I am not sure.
But, running for yolov_s is OK.
Does anyone here could give a help ? Thank you so much.

YOLOV -> annotations
-> assets
-> ..........
-> exps
-> ILSVRC -> Annotations
-> Data
-> ImageSets
-> ILSVRC2015 -> Annotations
-> Data
-> ImageSets
-> yolox
-> ........

I checked ./exps/yolov_x.py
I saw these code.
dataset = vid.VIDDataset(file_path='./yolox/data/datasets/train_seq.npy',
img_size=self.input_size,
preproc=TrainTransform(
max_labels=50,
flip_prob=self.flip_prob,
hsv_prob=self.hsv_prob),
lframe=0,  # batch_size,
gframe=batch_size,
dataset_pth=self.data_dir)
For the "train_seq.npy", I had put it as author's guide before running.

I solved this issue.
line 281 self.dataset_path = dataset_path in mosaicidetection.py.
if you want to train yolov_x.py,
please modify this line as  self.dataset_path = dataset_path -->  self.dataset_pth = dataset_path.
OK!!    checking code carefully!

I solved this issue. line 281 self.dataset_path = dataset_path in mosaicdetection.py.
if you want to train yolov_x.py, please modify this line as self.dataset_path = dataset_path --> self.dataset_pth = dataset_path.
OK!! checking code carefully!

Sorry for my poor code and thanks for your debugging. Best wishes.


Deleting users

What's about Project, Organization, Rating and Contests views? How the user will be shown there?

What's about Project, Organization, Rating and Contests views? How the user will be shown there?

After deletion, its name is renamed to Deleted + ID

What's about Project, Organization, Rating and Contests views? How the user will be shown there?

After deletion, its name is renamed to Deleted + ID

and they are not shown?

please make buttons more thin

please make buttons more thin

Fixed


Add (implement) sorting options

Maybe use the "top/new/rising/etc" dropdown for github sort options? e.g. number of star or downloads

You guys can take inspiration from betterdiscord:
Here's the sorting drop-down:

They also have a tag filter:

You guys can take inspiration from betterdiscord :

They also have a tag filter:

@theRealPadster i guess this one can be closed?


Is there a non-animation callback for when the chart completes?

I recognize that I can hook into various callbacks via a chart.js plugin, i.e., all the following callbacks are made available to a plugin: resize, beforeInit, beforeUpdate, afterScaleUpdate, beforeDatasetsUpdate, afterDatasetsUpdate, afterUpdate, beforeRender, afterInit, beforeDraw, beforeDatasetsDraw, afterDatasetsDraw, afterDraw, destroy...
...but...
What if one wants to hook into (for example) afterInit without going to the trouble of creating a plugin. In other words, it seems like many (or all?) of these callbacks ought to be available on any given chart instance.
Right now the only technique I know for checking if the chart has initialized is to hook into the animation progress callback and check for the first loop on the animation, which is complete hackery. So I built a plugin to hook in.
Is there a way to do this without a plugin?
If not can it be a feature request?

The recommended way to do this is to use a plugin. We can add something else if it is heavily requested

Here's another problem with doing it in a plugin. Let's say I have set up multiple instances of a chart, each one doing different things. Sure, I can create a plugin to hook into the afterInit callback. But that callback will do the same thing for each instance. What if I want a different behavior for different charts on afterInit? Do I create a separate plugin for each behavior? It would be easier to have afterInit available as an option, and set different callbacks on each instance. Imagine now that you have hundreds of chart instances...
I currently have this problem, and I've had to do some pretty hacky things to get different callback behaviors without creating multiple plugins...

I agree and I was thinking we could implement inline plugins, which might be a solution to your case:
new Chart(ctx, {
    options: {
        plugins: [{
            afterInit: function() {
            }
        }]
    }
});

It could also be refactor and used for multiple charts:
var pluginA = { afterInit: function() { } };
var pluginB = { afterRender: function() {} };

new Chart(ctx, {
    options: {
        plugins: [pluginA, pluginB]
    }
});

new Chart(ctx, {
    options: {
        plugins: [pluginA]
    }
});

To enable plugins for all charts:
Chart.defaults.global.plugins.push(pluginA, pluginB);

...I suppose that could work...?

@etimberg @zachpanz88 what do you guys think about inline plugins?

I like the idea. Should be relatively easy to implement too since we have a method already for dispatching a generic plugin call

Update on this: started with inline plugins in #3363 but we need to do some thinking on the exact API


Admin Account Management

Admin Account Management
Allow an admin to reset a members username and/or password in the event they forgot their login. Add implementation to work with an email provider.

Implemented as of a0492ab


Remove all legacy/compatibility MN code

The code removed by this PR is unused already (after #2594 was merged), making it safe to remove all of it.
The next PR will refactor the remains of CMasternodeMan into CMasternodeMetaMan.

Looks good, will compile and test a bit.

Also added https://github.com/dashpay/dash/pull/2600/commits/df984f7d0158f7cd79a946460da97908823e49ce, after the discussion we had. Turned out that the whole if/else block got unnecessary now.

Actually, one more thing :) should drop OUTPOINT_SPENT from masternodelist help https://github.com/dashpay/dash/pull/2600/files#diff-2299202f279425882d30bc2300dfbb11R149

Forgot to mention: pushed the last 2 changes requested. Github had issues at that time, so notifications might not be sent out.


refactor(rust): Use terminal for space show

Use Terminal instead println for space show

Current behavior
Uses println for sprint show

Proposed changes
Uses SpaceShowOutput and Terminal for output
closes #6488

Checks

[x] All commits in this Pull Request are signed and Verified by Github.
[x] All commits in this Pull Request follow the Ockam commit message convention.
[x] There are no Merge commits in this Pull Request. Ockam repo maintains a linear commit history. We merge Pull Requests by rebasing them onto the develop branch. Rebasing to the latest develop branch and force pushing to your Pull Request branch is okay.
[x] I have read and accept the Ockam Community Code of Conduct.
[x] I have read and accepted the Ockam Contributor License Agreement by adding my Git/Github details in a row at the end of the CONTRIBUTORS.csv file in a separate pull request to the build-trust/ockam repository. The easiest way to do this is to edit the CONTRIBUTORS.csv file in the github web UI and create a separate Pull Request, this will mark the commit as verified.

Hi @Zapix ! I'm closing this PR in favor of https://github.com/build-trust/ockam/pull/6517. Note that you also appear as a co-author of the commit that will get merged, so you get full credit for your contribution in this PR.
Thanks again!


rubocop: Some more config cleanup

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.

[ ] Have you successfully run brew typecheck with your changes locally?
[ ] Have you successfully run brew tests with your changes locally?

Found on my travels through https://github.com/Homebrew/brew/issues/14685.
Clean up non-existent files/dirs from excludes.
Naming/PredicateName allows is_a? by default.
The test dir is a default exclude for Style/Documentation.

Review period will end on 2023-02-21 at 00:00:00 UTC.

🤔 Why are things in test/**/* failing Style/Documentation on CI? Locally the cop shows no offenses.

🤔 Why are things in test/**/* failing Style/Documentation on CI? Locally the cop shows no offenses.

I think the PWD where you run brew style can affect its output sometimes. (It obviously shouldn't but I have seen it happen nevertheless.)

Thanks again @issyl0!

Review period skipped due to critical label.

Specifically, I think this has to do with whether rubocop is invoked with config https://github.com/Homebrew/brew/blob/master/Library/.rubocop.yml or https://github.com/Homebrew/brew/blob/master/Library/Homebrew/.rubocop.yml
I'm looking into consolidating them into a single file.

We have separate rules for things in Library/Taps and for the Homebrew/brew codebase. As you’ve probably seen in other issues: specifying paths in .rubocop.yml doesn’t seem to be terribly reliable here so we rely on separate configurations. The style varies a fair bit between the two, deliberately, as Library/Taps are formula/cask DSL(s) and Homebrew/brew is a fairly standard Ruby project.

Specifically, I think this has to do with whether rubocop is invoked with config https://github.com/Homebrew/brew/blob/master/Library/.rubocop.yml or https://github.com/Homebrew/brew/blob/master/Library/Homebrew/.rubocop.yml
I'm looking into consolidating them into a single file.

We have separate rules for things in Library/Taps and for the Homebrew/brew codebase. As you’ve probably seen in other issues: specifying paths in .rubocop.yml doesn’t seem to be terribly reliable here so we rely on separate configurations. The style varies a fair bit between the two, deliberately, as Library/Taps are formula/cask DSL(s) and Homebrew/brew is a fairly standard Ruby project.

This is useful context. It's been confusing triggering failures in other repos when making updates to the rubocop config here. Another approach could be to have a centralized, versioned rubocop repo, and each brew repo can independently use that config and a dedicated github action to run rubocop (and this repo could still enable the add'l config options that are currently in a separate file). (It looks like Shopify takes this approach: https://rubygems.org/gems/rubocop-shopify )

@dduugg Yeah, GitHub has the "separate repo, versioned gem" approach too - github/rubocop-github - it's a common pattern. Might be worth an issue to track this separately as a future enhancement us?

I'm going to undo the Style/Documentation test/** exclude removal since it's not working. No amount of massaging
inherit_mode:
  merge:
  - Exclude

works when RuboCop is run from the specific path. 🤔

It's been confusing triggering failures in other repos when making updates to the rubocop config here.

I think given that we don't "use RuboCop" as much as we "use brew style that happens to use RubocCop (and shellcheck): it makes more sense for this to live here.
I appreciate that it's a little confusing to have to change other repos to have CI pass here but I think it's better for us to have this a big more centralised and blocking.

I'm going to undo the Style/Documentation test/** exclude removal since it's not working.

@issyl0 IMO we should just remove it as a requirement and instead flip it to only be required on specific classes that are part of our public API.

@issyl0 IMO we should just remove it as a requirement and instead flip it to only be required on specific classes that are part of our public API.

@MikeMcQuaid Yeah, will do this soon with the metrics stuff too.


subcription-registery: Optimized

This optimizes the subscription registry.

Ping @yasserf #552

_subscriptionsName is a bit of a hack. But I think it is worth the performance gain.

The following places could use a binary search:
https://github.com/nxtedition/deepstream.io/blob/5685ed2ede2a2f0a42c098c2c1e7f8c363f3e0c0/src/utils/subscription-registry.js#L286
https://github.com/nxtedition/deepstream.io/blob/5685ed2ede2a2f0a42c098c2c1e7f8c363f3e0c0/src/utils/subscription-registry.js#L332

@yasserf: Could _subscriptions[x] possible be a Set instead of an array?

@yasserf Another Node 6.9.1. build fail.

I am very interested to see this PR together with the benchmark suite!

This looks really promising, scheduling for 2.2 which will include a bunch of performance improvements once we finish and opensource our performance framework.

There is also the possibility to re-use uniqueSenders and delayedBroadcasts objects instead of re-allocating them every time. I'll leave that to future work.

I think this is pretty solid now.

Listening E2E fails with this branch
  @events @listening
  Scenario: A publisher which accepts two times to a pattern
  √ Given publisher A connects and logs into server 1
  √ And publisher B connects and logs into server 1
  √ And publisher C connects and logs into server 2
  √ And publisher D connects and logs into server 3
  √ And subscriber 1 connects and logs into server 1
  √ And subscriber 2 connects and logs into server 2
  √ And subscriber 3 connects and logs into server 3
  √ When publisher A listens to an event with pattern "event/[a-z0-9]"
  √ And publisher A accepts an event match "event/1" for pattern "event/[a-z0-9]"
  √ And publisher A accepts an event match "event/2" for pattern "event/[a-z0-9]"
  √ And subscriber 1 subscribes to an event "event/1"
  √ And subscriber 1 subscribes to an event "event/2"
  √ And subscriber 1 subscribes to an event "weather"
  × Then publisher A receives 1 event match "event/1" for pattern "event/[a-z0-9]"
  - And publisher A receives 1 event match "event/2" for pattern "event/[a-z0-9]"
  - And publisher A does not receive a event match "weather" for pattern "event/[a-z0-9]"

Failures:

1) Scenario: A publisher which accepts two times to a pattern - test-e2e\features\events\events-listen.feature:80
   Step: Then publisher A receives 1 event match "event/1" for pattern "event/[a-z0-9]" - test-e2e\features\events\events-listen.feature:89
   Step Definition: test-e2e\steps\client\listening-steps.js:48
   Message:
     AssertError: expected spy to be called once but was called 0 times
         at Object.fail (D:\git\core\deepstream.io-client-js\node_modules\sinon\lib\sinon\assert.js:110:29)
         at failAssertion (D:\git\core\deepstream.io-client-js\node_modules\sinon\lib\sinon\assert.js:69:24)
         at Object.assertCallCount [as callCount] (D:\git\core\deepstream.io-client-js\node_modules\sinon\lib\sinon\assert.js:151:21)
         at World.Then (D:\git\core\deepstream.io-client-js\test-e2e\steps\client\listening-steps.js:50:18)
         at _combinedTickCallback (internal/process/next_tick.js:67:7)
         at process._tickCallback (internal/process/next_tick.js:98:9)

closed in favor of #598


Add Image Button UI component

example data input for the image button component:
title: string
image: file
link: string
A semi-transparent layer can be added on top of image. When mouse is hovered on the image, the transparency changes to indicate hover effect.
example:

first item hovered one:

from: http://www.pta.org/

https://github.com/leapon/reactcms/issues/129


Add ability to provide format options

Fixes #25

by upgrading mount-utils to 0.26.4 I was able to use FormatAndMountSensitiveWithFormatOptions and pass -E nodiscard options to it, which made plugin create and mount PV a lot faster.

I expanded that solution to be able to pass any mkfs arguments to the driver via StorageClass parameters:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
  name: synology-iscsi-hdd
provisioner: csi.san.synology.com
parameters:
  fsType: 'ext4'
  formatOptions: "-E nodiscard"
  location: '/volume6'
reclaimPolicy: Delete
allowVolumeExpansion: true

do you have a public available image to test this feature @rtim75 ?

https://hub.docker.com/r/rtim/synology-csi/tags
I've been running the only tag there for 2 months in my home lab with no issues. Let me know if you need anything else and I'll see what I can do

https://hub.docker.com/r/rtim/synology-csi/tags

I hope that it's a public image. Cannot check it right now

perfect it went from an infinite time to provision btrfs to few seconds, good job :+1:
      parameters:
        fsType: 'btrfs'
        formatOptions: "--nodiscard"
        protocol: 'iscsi'


Search is no longer saved at wayback machine at archive.org

see https://web.archive.org/web/20190430161430/https://search.creativecommons.org/ for example

Done with SSR, as you can see here http://web.archive.org/web/20190813023820/https://search.creativecommons.org/