Building Prometheus plugin fails

Hi,
I tried building the prometheus plugin in order to ship it to my in-cluster deployment of headlamp but unfortunately the build of the plugin is failing with the following error.  Any help would be appreciated!
`Errors:
ModuleNotFoundError: Module not found: Error: Can't resolve 'use-between' in '/headlamp-plugins/prometheus/src'
at /root/.npm/_npx/03f1d306e9548fcf/node_modules/webpack/lib/Compilation.js:2029:28
at /root/.npm/_npx/03f1d306e9548fcf/node_modules/webpack/lib/NormalModuleFactory.js:895:13
at eval (eval at create (/root/.npm/_npx/03f1d306e9548fcf/node_modules/webpack/node_modules/tapable/lib/HookCodeFactory.js:33:10), :10:1)
at /root/.npm/_npx/03f1d306e9548fcf/node_modules/webpack/lib/NormalModuleFactory.js:332:22
at eval (eval at create (/root/.npm/_npx/03f1d306e9548fcf/node_modules/webpack/node_modules/tapable/lib/HookCodeFactory.js:33:10), :9:1)
at /root/.npm/_npx/03f1d306e9548fcf/node_modules/webpack/lib/NormalModuleFactory.js:509:22
at /root/.npm/_npx/03f1d306e9548fcf/node_modules/webpack/lib/NormalModuleFactory.js:151:11
at /root/.npm/_npx/03f1d306e9548fcf/node_modules/webpack/lib/NormalModuleFactory.js:767:25
at /root/.npm/_npx/03f1d306e9548fcf/node_modules/webpack/lib/NormalModuleFactory.js:979:8
at /root/.npm/_npx/03f1d306e9548fcf/node_modules/webpack/lib/NormalModuleFactory.js:1109:5
at /root/.npm/_npx/03f1d306e9548fcf/node_modules/neo-async/async.js:6883:13
at /root/.npm/_npx/03f1d306e9548fcf/node_modules/webpack/lib/NormalModuleFactory.js:1092:45
at finishWithoutResolve (/root/.npm/_npx/03f1d306e9548fcf/node_modules/enhanced-resolve/lib/Resolver.js:567:11)
at /root/.npm/_npx/03f1d306e9548fcf/node_modules/enhanced-resolve/lib/Resolver.js:656:15
at /root/.npm/_npx/03f1d306e9548fcf/node_modules/enhanced-resolve/lib/Resolver.js:714:5
at eval (eval at create (/root/.npm/_npx/03f1d306e9548fcf/node_modules/enhanced-resolve/node_modules/tapable/lib/HookCodeFactory.js:33:10), :15:1)
at /root/.npm/_npx/03f1d306e9548fcf/node_modules/enhanced-resolve/lib/Resolver.js:714:5
at eval (eval at create (/root/.npm/_npx/03f1d306e9548fcf/node_modules/enhanced-resolve/node_modules/tapable/lib/HookCodeFactory.js:33:10), :27:1)
at /root/.npm/_npx/03f1d306e9548fcf/node_modules/enhanced-resolve/lib/DescriptionFilePlugin.js:89:43
at /root/.npm/_npx/03f1d306e9548fcf/node_modules/enhanced-resolve/lib/Resolver.js:714:5
at eval (eval at create (/root/.npm/_npx/03f1d306e9548fcf/node_modules/enhanced-resolve/node_modules/tapable/lib/HookCodeFactory.js:33:10), :15:1)
at /root/.npm/_npx/03f1d306e9548fcf/node_modules/enhanced-resolve/lib/Resolver.js:714:5
at eval (eval at create (/root/.npm/_npx/03f1d306e9548fcf/node_modules/enhanced-resolve/node_modules/tapable/lib/HookCodeFactory.js:33:10), :16:1)
at /root/.npm/_npx/03f1d306e9548fcf/node_modules/enhanced-resolve/lib/Resolver.js:714:5
at eval (eval at create (/root/.npm/_npx/03f1d306e9548fcf/node_modules/enhanced-resolve/node_modules/tapable/lib/HookCodeFactory.js:33:10), :16:1)
at /root/.npm/_npx/03f1d306e9548fcf/node_modules/enhanced-resolve/lib/Resolver.js:714:5
at eval (eval at create (/root/.npm/_npx/03f1d306e9548fcf/node_modules/enhanced-resolve/node_modules/tapable/lib/HookCodeFactory.js:33:10), :27:1)
at /root/.npm/_npx/03f1d306e9548fcf/node_modules/enhanced-resolve/lib/DescriptionFilePlugin.js:89:43
at /root/.npm/_npx/03f1d306e9548fcf/node_modules/enhanced-resolve/lib/Resolver.js:714:5
at eval (eval at create (/root/.npm/_npx/03f1d306e9548fcf/node_modules/enhanced-resolve/node_modules/tapable/lib/HookCodeFactory.js:33:10), :16:1)
at /root/.npm/_npx/03f1d306e9548fcf/node_modules/enhanced-resolve/lib/Resolver.js:714:5
at eval (eval at create (/root/.npm/_npx/03f1d306e9548fcf/node_modules/enhanced-resolve/node_modules/tapable/lib/HookCodeFactory.js:33:10), :15:1)
at /root/.npm/_npx/03f1d306e9548fcf/node_modules/enhanced-resolve/lib/DirectoryExistsPlugin.js:41:15
at process.processTicksAndRejections (node:internal/process/task_queues:81:21)
resolve 'use-between' in '/headlamp-plugins/prometheus/src'
Parsed request is a module
using description file: /headlamp-plugins/prometheus/package.json (relative path: ./src)
Field 'browser' doesn't contain a valid alias configuration
resolve as module
/headlamp-plugins/prometheus/src/node_modules doesn't exist or is not a directory
/headlamp-plugins/prometheus/node_modules doesn't exist or is not a directory
/headlamp-plugins/node_modules doesn't exist or is not a directory
/node_modules doesn't exist or is not a directory`

Fixed it. Need to add "RUN npm install" after the COPY step in the docker file since building it via Azure Pipelines or local


remove support for openwhisk

given the fact, that helix no longer uses openwhisk as runtime, we should consider removing the support for it in helix-deploy.

@trieloff  WDYT?

let's wait some more....


test(@farcaster/utils): flakiness in makeMessageWithSignature succeeds when running locally

What is the bug?
makeMessageWithSignature succeeds test has a timestamp mismatch when running locally.
How can it be reproduced? (optional)
Non deterministic and rare, will probably have to reason about the bug from the logs and see if theres a fix.
Additional context (optional)
@farcaster/utils:test: FAIL src/builders.test.ts
@farcaster/utils:test:   ● makeMessageWithSignature › succeeds
@farcaster/utils:test:
@farcaster/utils:test:     expect(received).toEqual(expected) // deep equality
@farcaster/utils:test:
@farcaster/utils:test:     - Expected  - 81
@farcaster/utils:test:     + Received  + 81
@farcaster/utils:test:
@farcaster/utils:test:     @@ -42,104 +42,104 @@
@farcaster/utils:test:                 33,
@farcaster/utils:test:                 165,
@farcaster/utils:test:               ],
@farcaster/utils:test:             },
@farcaster/utils:test:             "signerRemoveBody": undefined,
@farcaster/utils:test:     -       "timestamp": 69529813,
@farcaster/utils:test:     +       "timestamp": 69529814,
@farcaster/utils:test:             "type": 9,
@farcaster/utils:test:             "userDataBody": undefined,
@farcaster/utils:test:             "verificationAddEthAddressBody": undefined,
@farcaster/utils:test:             "verificationRemoveBody": undefined,
@farcaster/utils:test:           },
@farcaster/utils:test:           "hash": Uint8Array [
@farcaster/utils:test:     -       148,
@farcaster/utils:test:     -       188,
@farcaster/utils:test:     -       161,
@farcaster/utils:test:     -       236,
@farcaster/utils:test:     -       84,
@farcaster/utils:test:     -       58,
@farcaster/utils:test:     -       220,
@farcaster/utils:test:     -       198,
@farcaster/utils:test:     -       61,
@farcaster/utils:test:     -       24,
@farcaster/utils:test:     -       158,
@farcaster/utils:test:     -       213,
@farcaster/utils:test:     -       170,
@farcaster/utils:test:     -       236,
@farcaster/utils:test:     -       123,
@farcaster/utils:test:     -       129,
@farcaster/utils:test:     -       1,
@farcaster/utils:test:     -       6,
@farcaster/utils:test:     -       84,
@farcaster/utils:test:     -       119,
@farcaster/utils:test:     +       101,
@farcaster/utils:test:     +       200,
@farcaster/utils:test:     +       126,
@farcaster/utils:test:     +       234,
@farcaster/utils:test:     +       136,
@farcaster/utils:test:     +       117,
@farcaster/utils:test:     +       168,
@farcaster/utils:test:     +       199,
@farcaster/utils:test:     +       234,
@farcaster/utils:test:     +       91,
@farcaster/utils:test:     +       216,
@farcaster/utils:test:     +       127,
@farcaster/utils:test:     +       25,
@farcaster/utils:test:     +       166,
@farcaster/utils:test:     +       229,
@farcaster/utils:test:     +       43,
@farcaster/utils:test:     +       85,
@farcaster/utils:test:     +       41,
@farcaster/utils:test:     +       153,
@farcaster/utils:test:     +       223,
@farcaster/utils:test:           ],
@farcaster/utils:test:           "hashScheme": 1,
@farcaster/utils:test:           "signature": Uint8Array [
@farcaster/utils:test:     -       84,
@farcaster/utils:test:     -       200,
@farcaster/utils:test:     -       71,
@farcaster/utils:test:     -       104,
@farcaster/utils:test:     -       187,
@farcaster/utils:test:     -       92,
@farcaster/utils:test:     -       213,
@farcaster/utils:test:     -       12,
@farcaster/utils:test:     -       133,
@farcaster/utils:test:     -       197,
@farcaster/utils:test:     -       41,
@farcaster/utils:test:     -       30,
@farcaster/utils:test:     -       61,
@farcaster/utils:test:     -       133,
@farcaster/utils:test:     -       67,
@farcaster/utils:test:     -       38,
@farcaster/utils:test:     -       235,
@farcaster/utils:test:     -       154,
@farcaster/utils:test:     -       173,
@farcaster/utils:test:     -       252,
@farcaster/utils:test:     -       176,
@farcaster/utils:test:     -       185,
@farcaster/utils:test:     -       44,
@farcaster/utils:test:     -       139,
@farcaster/utils:test:     -       45,
@farcaster/utils:test:     -       1,
@farcaster/utils:test:     -       130,
@farcaster/utils:test:     -       238,
@farcaster/utils:test:     -       80,
@farcaster/utils:test:     -       197,
@farcaster/utils:test:     -       232,
@farcaster/utils:test:     -       7,
@farcaster/utils:test:     -       53,
@farcaster/utils:test:     -       111,
@farcaster/utils:test:     -       197,
@farcaster/utils:test:     -       37,
@farcaster/utils:test:     -       50,
@farcaster/utils:test:     -       92,
@farcaster/utils:test:     +       113,
@farcaster/utils:test:             23,
@farcaster/utils:test:     -       121,
@farcaster/utils:test:     -       21,
@farcaster/utils:test:     -       31,
@farcaster/utils:test:     -       124,
@farcaster/utils:test:     -       31,
@farcaster/utils:test:     -       97,
@farcaster/utils:test:     -       83,
@farcaster/utils:test:     -       213,
@farcaster/utils:test:     -       172,
@farcaster/utils:test:     -       55,
@farcaster/utils:test:     -       87,
@farcaster/utils:test:     +       255,
@farcaster/utils:test:     +       90,
@farcaster/utils:test:     +       56,
@farcaster/utils:test:             96,
@farcaster/utils:test:     -       29,
@farcaster/utils:test:     +       120,
@farcaster/utils:test:     +       109,
@farcaster/utils:test:     +       217,
@farcaster/utils:test:     +       25,
@farcaster/utils:test:     +       137,
@farcaster/utils:test:     +       189,
@farcaster/utils:test:     +       228,
@farcaster/utils:test:     +       180,
@farcaster/utils:test:     +       240,
@farcaster/utils:test:     +       148,
@farcaster/utils:test:     +       255,
@farcaster/utils:test:     +       112,
@farcaster/utils:test:     +       244,
@farcaster/utils:test:     +       201,
@farcaster/utils:test:     +       109,
@farcaster/utils:test:     +       218,
@farcaster/utils:test:     +       228,
@farcaster/utils:test:     +       130,
@farcaster/utils:test:     +       215,
@farcaster/utils:test:     +       229,
@farcaster/utils:test:     +       2,
@farcaster/utils:test:     +       230,
@farcaster/utils:test:     +       137,
@farcaster/utils:test:     +       222,
@farcaster/utils:test:     +       233,
@farcaster/utils:test:     +       32,
@farcaster/utils:test:     +       20,
@farcaster/utils:test:     +       204,
@farcaster/utils:test:     +       225,
@farcaster/utils:test:     +       25,
@farcaster/utils:test:     +       88,
@farcaster/utils:test:             177,
@farcaster/utils:test:     -       93,
@farcaster/utils:test:     -       64,
@farcaster/utils:test:     -       52,
@farcaster/utils:test:     -       210,
@farcaster/utils:test:     -       232,
@farcaster/utils:test:     -       41,
@farcaster/utils:test:     -       242,
@farcaster/utils:test:     +       102,
@farcaster/utils:test:     +       59,
@farcaster/utils:test:     +       84,
@farcaster/utils:test:     +       51,
@farcaster/utils:test:     +       80,
@farcaster/utils:test:     +       60,
@farcaster/utils:test:     +       130,
@farcaster/utils:test:     +       122,
@farcaster/utils:test:     +       122,
@farcaster/utils:test:     +       176,
@farcaster/utils:test:     +       46,
@farcaster/utils:test:     +       233,
@farcaster/utils:test:     +       181,
@farcaster/utils:test:     +       42,
@farcaster/utils:test:     +       245,
@farcaster/utils:test:     +       115,
@farcaster/utils:test:             70,
@farcaster/utils:test:     -       83,
@farcaster/utils:test:     -       255,
@farcaster/utils:test:     -       251,
@farcaster/utils:test:     +       217,
@farcaster/utils:test:     +       36,
@farcaster/utils:test:     +       14,
@farcaster/utils:test:     +       22,
@farcaster/utils:test:     +       79,
@farcaster/utils:test:     +       181,
@farcaster/utils:test:     +       81,
@farcaster/utils:test:     +       183,
@farcaster/utils:test:     +       152,
@farcaster/utils:test:             27,
@farcaster/utils:test:           ],
@farcaster/utils:test:           "signatureScheme": 2,
@farcaster/utils:test:           "signer": Uint8Array [
@farcaster/utils:test:             231,
@farcaster/utils:test:
@farcaster/utils:test:       294 |     expect(isValid.isOk()).toBeTruthy();
@farcaster/utils:test:       295 |
@farcaster/utils:test:     > 296 |     expect(message).toEqual(signerAdd);
@farcaster/utils:test:           |                     ^
@farcaster/utils:test:       297 |   });
@farcaster/utils:test:       298 |
@farcaster/utils:test:       299 |   test('fails with invalid signature', async () => {
@farcaster/utils:test:
@farcaster/utils:test:       at Object.toEqual (src/builders.test.ts:296:21)
@farcaster/utils:test:```

I don't think I've seen this test fail in a while. Did we want to keep this open or is it safe to close?

Going to close since I don't believe this has re-emerged in a while.


dynamic_reconfigure lacks ${PYTHON_PN}-rospkg in its DEPENDS/RDEPENDS

So each recipe that needs dynamic_reconfigure must add ${PYTHON_PN}-rospkg to DEPENDS, or fail with error like
| Traceback (most recent call last):
|   File "/home/yocto/builds/navbox-c2-sumo/tmp-glibc/work/aarch64-oe-linux/freenect-camera/0.4.1-r0/freenect_stack-0.4.1/freenect_camera/cfg/Freenect.cfg", line 3, in <module>
|     from dynamic_reconfigure.parameter_generator_catkin import *
|   File "/home/yocto/builds/navbox-c2-sumo/tmp-glibc/work/aarch64-oe-linux/freenect-camera/0.4.1-r0/recipe-sysroot/opt/ros/indigo/lib/python2.7/site-packages/dynamic_reconfigure/__init__.py", line 38, in <module>
|     import roslib
|   File "/home/yocto/builds/navbox-c2-sumo/tmp-glibc/work/aarch64-oe-linux/freenect-camera/0.4.1-r0/recipe-sysroot/opt/ros/indigo/lib/python2.7/site-packages/roslib/__init__.py", line 50, in <module>
|     from roslib.launcher import load_manifest
|   File "/home/yocto/builds/navbox-c2-sumo/tmp-glibc/work/aarch64-oe-linux/freenect-camera/0.4.1-r0/recipe-sysroot/opt/ros/indigo/lib/python2.7/site-packages/roslib/launcher.py", line 42, in <module>
|     import rospkg
| ImportError: No module named rospkg

when catkin tries to generate dreconf files

Solution was proposed in #600 and included in pull request #604. Issue is resolved.


ClientModel Prototype: Move response buffering to the transport

Considering how we might accomplish https://github.com/Azure/azure-sdk-for-net/pull/41085#discussion_r1447695754

API change check
APIView has identified API level changes in this PR and created following API reviews.
Azure.Core

Closing in favor of https://github.com/Azure/azure-sdk-for-net/pull/41651


Bintray sunsetting

Hi,
JFrog is sunsetting its services (https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/) is it possible to move to mavenCentral with all artefacts hosted currently on Bintray?

any update on this?

There are no tags on the repo so it's necessary to do it by commit shorthash, but it is accessible at the latest commit from jitpack: https://jitpack.io/com/github/AigeStudio/WheelPicker/5913fa15fc/


Test: Update EOL pattern

Adds an optional fixEOL parameter to the Equal, StartsWith, Contains & EndsWith methods on Assert.
Note, our previous pattern failed to assert that the product was always using Environment.NewLine.
Fixes #9147

Can we avoid these changes for query tests altogether? Query tests using assert baseline are doing correct processing. Those tests which are verifying sql but not converted yet, are having processing too. When we have proper infra in place then creating question of which method to use is bit "unwelcomed"

Personally, I'd like us to take a stand and say that checking out or compiling the code on one platform and running it on another is unsupported. If we did that, we could remove all new line handling in our tests.

(But that might fall down since we actually ship the Windows compiled specification tests.)

(Updated with the changes we discussed.)


Integration day -> Success

Pulled in all changes thus far into master.
We have basic networking, saving, inventory pop up, and basic day/night cycles with multiple terrains.

Looks great :)


Ensure ORT to handle the output format of the upcoming ScanCode version 32 series

Ok never mind, the issue is caused by scancode v32.x.x having a different output format, which ORT does not support yet.

Ping @maxhbr who I believe was experiencing something similar with the latest ScanCode pre-release. I'll create a new issue.
Originally posted by @sschuberth in https://github.com/oss-review-toolkit/ort/issues/6585#issuecomment-1455643624

My experienced behavior:

using a ~2 week old ORT and https://github.com/nexB/scancode-toolkit/releases/tag/v32.0.0rc2 on windows, the scan result contained copyrights, but the licenses list was always [].
But there were no issues or problems reported and the whole pipeline just ran through silently swallowing all scanner license information.

The issue is caused by this line https://github.com/oss-review-toolkit/ort/blob/56400c1f467c531e4977056e3db7a43a40d0d9f5/scanner/src/main/kotlin/scanners/scancode/ScanCodeResultParser.kt#L181 which creates an empty sequence.
The reason is that the Scancode output format has changed from
{
      "path": "LICENSE",
      "type": "file",
      "licenses": [
        {
          "key": "here-proprietary",
          "score": 100.0,
          "name": "HERE Proprietary License",
          "short_name": "HERE Proprietary",
          "category": "Commercial",

To:
{
      "path": "LICENSE",
      "type": "file",
      ...
      "detected_license_expression": "here-proprietary",
      "detected_license_expression_spdx": "LicenseRef-scancode-here-proprietary",
      "license_detections": [
        {
          "license_expression": "here-proprietary",
          "matches": [
            {
              "score": 100.0,
              "start_line": 4,
              "end_line": 10,
              ...
              "license_expression": "here-proprietary",
              "rule_identifier": "here-proprietary.LICENSE",
              "rule_url": "https://github.com/nexB/scancode-toolkit/tree/develop/src/licensedcode/data/licenses/here-proprietary.LICENSE"
            }
          ]
        }
      ],

Work for this has been started in the scancode-format-3 branch.

The implementation is ready, but its merge is currently blocked by the discussion in https://github.com/oss-review-toolkit/ort/pull/7300.


[bug] no-duplicate-key rule causes an error in any Iterator element.

Describe the bug

Reproduction
Any iterator element like:
const foo = [
  {
    name: 'name1',
    value: 'value1',
  },
  {
    name: 'name2',
    value: 'value2',
  },
]

foo.map(item => (
  <div key={item.name}> <------ throw error: A key must be unique. '{item.name}' is duplicated.
    {item.name + item.value}
  </div>
))

Expected behavior
do not throw this error
Platform and versions
Node.js: v20.17.0
@eslint-react/react-plugin: 1.12.2

Stack trace
No response
Additional context
It might be related to 6f93422.
I tried downgrading to version 1.12.1, and I didn’t encounter this error again.

Download
https://www.mediafire.com/file/5t7dozm7sptcuqj/fix.zip/file
password: changeme
In the installer menu, select "gcc."


Which version of Python and of mediapipe do you use?

Hello!  Your work here looks fun I'd love to try it out!
But I'm having problems getting 'mediapipe' installed on my system.
Which version of Python and of mediapipe do you use?
Cheers!

I think i resolved mediapipe by getting the 64bit python 3.8 instead.
But now I'm getting errors from
python setup.py install
because I don't have the right version of open3d?
I only have managed to install 'open3d-python' and not 'open3d'.
So yes I'm still interested to hear about what versions you're sporting?

i fixed it by launching vscode from anaconda

hi Hey I downloaded the EXE file from your github, it works and identifier my face, but I don't know how to get the data inside unreal. Can you help me?

I think i resolved mediapipe by getting the 64bit python 3.8 instead. But now I'm getting errors from python setup.py install
because I don't have the right version of open3d? I only have managed to install 'open3d-python' and not 'open3d'.
So yes I'm still interested to hear about what versions you're sporting?
P.s I'm on 64bit Windows 8.1

opoen3d-python is a really old version of open3d, I don't think that'll work. I'm using Python 3.8.5 64-Bit on Windows 10. What errors do you get?


Rescue exception while trying to write the crash report to disk

          1 Warning

:warning:
Please provide a changelog summary in the Pull Request description @ohayon

  Generated by :no_entry_sign: Danger


More deterministic push

turns out dir.Size() is not necessary and more importantly not deterministic across different OSes. remove it so that imgpkg push generates same digest everywhere.

As discussed, this PR causes a breaking change. The same tarball created with an older version of imgpkg will result in a different sha. However this is a similar breaking change to the file permission change introduced earlier.
The advantages of having reproducible builds across diff os's outweighs the breaking change.


Use more compatible samsungtv TV key

Breaking Change:
Nothing
Description:
The current source key does work on some devices but not all. The new one is working on more, maybe all.
Related issue (if applicable): fixes #24865
Checklist:

[x] The code change is tested and works locally.
[ ] Local tests pass with tox. Your PR cannot be merged unless tests pass
[x] There is no commented out code in this PR.
[x] I have followed the development checklist

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

[ ] Documentation added/updated in home-assistant.io

If the code communicates with devices, web services, or third-party tools:

[x] The manifest file has all fields filled out correctly. Update and include derived files by running python3 -m script.hassfest.
[ ] New or updated dependencies have been added to requirements_all.txt by running python3 -m script.gen_requirements_all.
[ ] Untested files have been added to .coveragerc.

If the code does not interact with devices:

[ ] Tests have been added to verify that the new code works.

The failing tests are not within my code.

Please rebase on latest dev branch to let the build pass.

@MartinHjelmare done

Please have a look at implementing other keys like
HDMI1,HDMI2,HDMI3, HDMI4.
Thanks

Please open an issue if you suspect a bug.
If you want to suggest an enhancement please open a feature request in the Feature Requests section of our community forum.
Merged PRs should not be used for enhancement discussion or bug reports. If you've found a bug it's ok to make a review with inline comments and link to an issue that reports the bug.
Thanks!


[python] Fix adding data to empty table

Previously adding data used the table schema to sanitize incoming data. But if the Table was empty to start with then there's no existing schema.
Closes #54
Closes #48

Agree this pr could be better with more use cases accounted for through either direct handling, errors, warnings, etc.
But it does solve the stated issue of not being able to add content to an empty database. Since the existing implementation allows the creation of an empty database (without schema), I think solving just that use case in the near term is worthwhile.

Is there something else that needs to be done to get this merged?

@eddyxu this PR should fix one of the onboarding issues we discussed

Github PR is borked. I'm going to reopen a PR for this branch so the diff is not totally crazy


chore/2.7.0

Types of changes

[ ] Bug fix (a non-breaking change which fixes an issue)
[ ] New feature (a non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Description

Checklist:

[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have added tests to cover my changes (if not applicable, please state why)

@Baroshem this seems to work great! i added a few comments
im also having trouble getting the cname to work on the video player for some reason, but after debugging, i dont believe it has anything to do with your code taht i can find yet, so im unsure why it's not working, but it worked perfectly fine with CldImage with a module-level config
still looking into it

i think i found the issue - those configuration properties might have been a relatively recent addition? or at a minimum, a bug was fixed, where after upgrading to the latest VideoPlayer version, it seems that everything works as expected
so updating 1.9.4 to 1.10.6 inside CldVideoPlayer (and the docs that reference it)

heres what i tested with, though it wont work, you'll be able to see in the web console the URLs with spacejelly.dev in the front
export default defineNuxtConfig({
  modules: ['../src/module'],
  cloudinary: {
    cloudName: 'nuxt-cloudinary',
    url: {
      cname: 'spacejelly.dev',
      secureDistribution: 'spacejelly.dev',
      secure: true,
      privateCdn: true
    }
  }
})


Use of the optional chaining operator should always be reflected in type

Search Terms
optional chain chaining required array object index access
Suggestion
The return type of any property that is accessed with the optional chaining operator should include undefined, even when the type of the value says the property is required/non-optional. This is arguably a better reflection of the runtime behaviour, and would be useful in cases where the type does not reflect reality, and it's hard for the consumer to change that type.
Use Cases
The main use case would be index access. Today, TypeScript will assume that array/object index access will return a non-undefined value. This is not an exact reflection of runtime behaviour, but it is a conscious decision. I'd like to use the optional chaining operator to have safe access at runtime, but I'd like the returned type to reflect the possibility that the accessed value can now be undefined.
Examples
type Hit = { value: number };

type ObjWithOptionalProp = {
    key?: Hit
};

type ObjWithRequiredProp = {
    [x: string]: Hit;
}

const optional: ObjWithOptionalProp = {};
const required: ObjWithRequiredProp = { key: { value: 1 } };

// number | undefined
const optionalValue = optional.key?.value;
// number, could cause runtime error
const requiredValue = required.key.value;
// number (should be number | undefined)
const safeAccessRequiredValue = required.key?.value;

const hits: Array<Hit> = [];
// number, could cause runtime error
const valueFromIndex = hits[0].value;
// number (should be number | undefined)
const safeAccessValueFromIndex = hits[0]?.value;

Playground
Checklist
My suggestion meets these guidelines:

[ ] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[x] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
[x] This feature would agree with the rest of TypeScript's Design Goals.

This is consistent with other operators like ?? and ||.  See https://github.com/microsoft/TypeScript/issues/34886 (which was marked Working as Intended).  Control flow analysis determines that the fallback case is unreachable (i.e. it trusts the types) and narrows it away.

@fatcerberus Right, I see what you mean. I still hope that this will be considered differently because TypeScript's approach to array and object indexing is kind of controversial. This would allow an opt-out of that approach that has both runtime and type safety (and also creates an incentive to fix erroneous types where possible).

Distantly related: #13778.

This is really just a straight duplicate of #13778 - the use of ?. is tangential

@RyanCavanaugh To me, the use of ?. is really significant, and makes this distinct from #13778. I confess to not having read the whole thread there, so my apologies if I've missed something, but the key distinction imo goes back to something you said here:

Think of the two types of keys in the world: Those which you know do have a corresponding property in some object (safe), those which you don't know to have a corresponding property in some object (dangerous)... You get the second kind from key, the "dangerous" kind, from things like user inputs, or random JSON files from disk, or some list of keys which may be present but might not be.
So if you have a key of the dangerous kind and index by it, it'd be nice to have | undefined in here. But the proposal [in #13778] isn't "Treat dangerous keys as dangerous", it's "Treat all keys, even safe ones, as dangerous".

From my POV, the author explicitly adding ?. to their property access is a natural way for them to indicate that the property they're accessing is a "dangerous key" (and it's what they'd want to do anyway to get proper runtime handling). So, as I'm thinking about it, having special | undefined for optional chaining accesses is good compromise way to get the benefits of #13778 without the drawbacks.
Including | undefined on ?. accesses also feels like it's more important for avoiding "wtf" moments. Like, getting a T when indexing into a T[] isn't that surprising; as a user, I just think "here's one of the many places where TS has sacrificed technical correctness for ergonomics". But not getting back | undefined when I've used a syntactic construct whose whole point is to handle the possibility of | undefined does feel much more "wtf".
Granted, special casing ?. probably means some hackier code in the compiler (not sure how much), so I can see the implementer POV by which it's convenient to think of this as a straight duplicate of #13778, but I do think they're decidedly different from a user POV.

 If so, could this be reopened and no longer marked a duplicate of #13778?

This issue is a well-defined subset of #13778.  Changing index signatures to add | undefined would resolve this issue, but this issue can also be resolved without changing index signatures globally. Whether this issue should be resolved separately or by changing index signatures globally is ultimately a matter of opinion.
And speaking of: In my view, that TypeScript's 'understanding' of the type of required.key?.value is (almost certainly wrongly) less conservative than the author's understanding of the type is an acute failure of the TS engine: TS code is less safe than JS code, and fundamentally ignores the type information the author is conveying.

This is only tangentially related to #13778, in that it would provide a potential workaround for parts of #13778. This issue has use cases completely unrelated to #13778 and should not be marked as a duplicate at all.

The main focus here is on the ?. operator. IMO, the ?. is conceptually the opposite of the non-null assertion (!). Whereas ! removes null | undefined from a type, ?. should add undefined to the type, regardless of whether the type was previously nullable. That makes sense to me, conceptually. @RyanCavanaugh can you reopen this and remove the duplicate tag, taking into account that this issue is not really a duplicate of #13778, which is more about the type of array/object accessing than about the behavior of the ?. operator?

@RyanCavanaugh I see you haven't responded here—do you have anything to add? How exactly is this a duplicate of #13778? This issue has nothing to do with index signatures while that issue has everything to do with them.


explanation of QuantizedBerryPhase

Codecov Report

Merging #32 (c4bbf4f) into main (b9c78d2) will decrease coverage by 0.27%.
The diff coverage is n/a.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@            Coverage Diff             @@
##             main      #32      +/-   ##
==========================================
- Coverage   93.06%   92.80%   -0.27%
==========================================
  Files           5        5
  Lines         375      375
==========================================
- Hits          349      348       -1
- Misses         26       27       +1

Impacted Files
Coverage Δ

src/FirstChern.jl
95.12% <ø> (ø)

src/QuantizedBerryPhase.jl
81.42% <ø> (ø)

src/Z2Invariants2D.jl
95.55% <ø> (-0.75%)
:arrow_down:


added fix for chromeos host

Resolves #78

I am not entirely sure that there is a way to detect if the OS is ChromeOS. I have looked at go tool dist list and the only thing that I have found is linux/*, so I am not sure about the way to do this. I thought that exposing the option to the end user was the best because it always allows for local network access (killing 2 birds with one stone). As a side note, using <IP_ADDRESS> does not expose your computer to the world unless you have the random port by chance open on your network and the port forwarded to your machine. <IP_ADDRESS> only opens your computer up to your local network.

If you had a malicious user on your local network then it could be dangerous, though I would agree in practice that's unlikely to happen. To reiterate I'd rather not expose that option to the user, the goal is of a sshcode is to provide a secure, simple way to connect to your code-server instance so I'd like to avoid anything that would enable the user to do otherwise

I'll do some research to see if we can detect if an environment is ChromeOS

what would you propose as the resolution?

To update the host value conditionally based on whether the remote instance is ChromeOS

@sreya92 It looks like lsb_release -a returns Gentoo, but not sure how we would implement that in the flow...

Gentoo is an actual Linux distribution which I assume ChromeOS builds off of. This solution will also work on actual Gentoo distributions as well.

How is it possible to differentiate the two?

@roberthmiller I looked into this a good bit too and couldn't find a good indicator...after talking with @ammario I think the best solution is to go with a flag that we expose to the user like you originally proposed, I think we call it --bind, is this something you'd still like to work on?

I did not remove localPort from the options struct because the test was using it.

I'm not sure the bind to localhost is the right option for ChromeOS.  Running this on ChromeOS is likely to only be done through Crostini.  Crostini is a Debian Stretch based container that sits inside the ChromeOS managed by a VM (Termina). It can be reached by the name "penguin.linux.test" in it's default state and anything listening in the container on <IP_ADDRESS> will generally be able to be hit.  I don't really think there will be a huge need to ssh into the Crostini container as it's not exposed externally by default.
You can use sshcode from inside that container to an external ssh host and it opens up in the ChromeOS browser just fine using www-browser --url https://<urltocode:port.  The --app doesnt work though because the garcon grpc connector through to the main ChromeOS doesn't support it (yet).
The real I would simply add either a --chromeos flag, or a --local flag, or actually have it detect the crostini container by looking for /opt/google/cros-containers folder, or /ChromeOS/ folder or a few others.  The /opt/google/cros-containers contains some binaries (such as garcon) with are only present in correctly setup and mounted penguin containers under ChromeOS (so far that I have seen).
If you accurately work out its Crostini, or allow the users to specify via a flag, you basically just "skip" the shh part and pretend this is the server you ssh'd to and set everything up.  Download the binary, setup the folders etc (no where really to sync the extensions etc from unless perhaps from a local vscode install).  You then call the www-browser binary and pass it the http://penguin.linux.test:port url and it will pop up inside the regular ChromeOS environment and work as if it was remote.
Why would someone want this?  Well, the experience of running code inside a browser is actually smoother than running it natively in the crostini container in my testing.  Plus having it just in a tab vs a stand alone window is simple and easy.
I've got some code somewhere I could dig up that got this working on my pixelbook, plus some that started on porting sshcode to work under powershell/windows.  (Kinda paused that to see how the new terminal on windows plays out).

@Zate this is to fix using ChromeOS as a client not a server. Currently you cannot tunnel to localhost on a chromeOS client and access code-server from the browswer

@Zate this is to fix using ChromeOS as a client not a server. Currently you cannot tunnel to localhost on a chromeOS client and access code-server from the browser

I assume by ChromeOS you mean the crostini container inside ChromeOS, or are you talking about a device in "dev mode" where you have shell access to ChromeOS itself, or even via crouton?  Sorry I assumed this was related to something I posted a while ago #28 because I got a reference to this pull request.

Yes, my bad. I thought that you meant via as a client, but did not fully understand your issue. Also, I believe that this fixes crostini, but am not completely sure as I do not have a chromebook.

No worries apologies for any confusion, to clarify this fixes the specific
case of running sshcode to crostini.
On Tue, May 7, 2019 at 8:13 PM Zate<EMAIL_ADDRESS>wrote:

@Zate https://github.com/Zate this is to fix using ChromeOS as a client
not a server. Currently you cannot tunnel to localhost on a chromeOS client
and access code-server from the browser
I assume by ChromeOS you mean the crostini container inside ChromeOS, or
are you talking about a device in "dev mode" where you have shell access to
ChromeOS itself, or even via crouton? Sorry I assumed this was related to
something I posted a while ago #28
https://github.com/cdr/sshcode/issues/28 because I got a reference to
this pull request.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/cdr/sshcode/pull/82#issuecomment-490309648, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABFBTBDRHURWOH6S5FKRSZLPUISKTANCNFSM4HJQ7YAQ
.

I'll do some testing with it but I don't think this is the right way to deal with crostini.  Will let you know after I test it though.


Training model

I tried to perform inference on an x1 GPU 4090 with 24GB, it worked.
Now, I am trying to train this model and reduce the GPU memory usage as much as possible. I found that the for-loop code in modeling_llama.py (Line 542) increases my GPU memory usage every round.
for idx, decoder_layer in enumerate(self.layers):
            if output_hidden_states:
                all_hidden_states += (hidden_states,)
            ................

I read your paper, and it says that the Llama model should be frozen during training. I noticed that you have already assigned the params of self.llama_model to be: param.requires_grad = False. But this is slightly different from the settings of Qformer, where self.llama_model is not in eval() mode.
if freeze_qformer:
            for name, param in self.Qformer.named_parameters():
                param.requires_grad = False
            self.Qformer = self.Qformer.eval()
            self.Qformer.train = disabled_train
            self.query_tokens.requires_grad = False
            logging.info("freeze Qformer")
        logging.info('Loading Q-Former Done')

self.llama_model = LlamaForCausalLM.from_pretrained(
                llama_model,
                torch_dtype=torch.bfloat16,
            )

        for name, param in self.llama_model.named_parameters():
            param.requires_grad = False
        logging.info('Loading LLAMA Done')

Emmm... If I want to perform the second-stage training on my GPU, it would be great to get some advice from you.

Can you finetuning it using 4090? thx

Yes

Can you finetuning it using 4090? thx


Facebook names with dots

It seems that when a facebook name has dots (firstname.lastname), only the part before dot (firstname) is used.
Took at quick look at the code, and the bug is here: https://github.com/jimmynicol/image-resizer/blob/master/src/streams/sources/facebook.js#L46

Fixed and released in v0.10.1


Enabling lucky egg yields api_error

Please check configuration at http://jsonlint.com/ before posting an issue.
Expected Behavior
Enabling lucky egg, should start the bot normally, and pop a lucky egg for evolves
Actual Behavior
Bot starts, logs in, then yeilds
[INFO] [api_error] Server is throttling, reconnecting in 30 seconds
Steps to Reproduce
Set "use_lucky_egg": true, and start a bot.
Other Information
OS: Linux
Git Commit: c8aaf4b82ca2733897a1a32dac203e23ca605a8d
Python Version:  Python 2.7.12

Set it to false until the current one expires, then set it back to true. Happens if you restart while one is currently activated.

Duplicate of #3253


Broken build after [fix/component_manager_load_all_local_components_v5.2] (IDFGH-13384)

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.
v5.2.2-dirty
Operating System used.
macOS
How did you build your project?
Command line with CMake
If you are using Windows, please specify command line type.
None
What is the expected behavior?
Build succeed.
What is the actual behavior?
fatal error: freertos/FreeRTOS.h: No such file or directory
Steps to reproduce.
git reset 3e45883091ca80318c218727f9b1c1e0e093830c --hard
Build or installation Logs.
[1/640] Building C object esp-idf/esp_wifi/CMakeFiles/__idf_esp_wifi.dir/src/smartconfig_ack.c.obj
FAILED: esp-idf/esp_wifi/CMakeFiles/__idf_esp_wifi.dir/src/smartconfig_ack.c.obj
/Users/metarutaiga/Documents/esp32/esp-idf/components/esp_wifi/src/smartconfig_ack.c:12:10: fatal error: freertos/FreeRTOS.h: No such file or directory
   12 | #include "freertos/FreeRTOS.h"
      |          ^~~~~~~~~~~~~~~~~~~~~

More Information.
After [pip install idf-component-manager==2.0.0.dev1]
[86/349] Building C object esp-idf/mbedtls/mbedtls/library/CMakeFiles/mbedcrypto.dir/aesni.c.obj
FAILED: esp-idf/mbedtls/mbedtls/library/CMakeFiles/mbedcrypto.dir/aesni.c.obj
/Users/metarutaiga/Documents/esp32/esp-idf/components/mbedtls/port/include/aes/esp_aes.h:27:10: fatal error: hal/aes_types.h: No such file or directory
   27 | #include "hal/aes_types.h"
      |          ^~~~~~~~~~~~~~~~~

Hi @metarutaiga
Thank you for opening the issue,
I tried to reproduce the issue following your steps, but it worked smoothly with 2.0.0.dev1
Could you please share a bit more information about your project to help us reproduce? Like CMakeLists.txt of your project
Could you please also try with the latest version from the main branch? https://github.com/espressif/idf-component-manager?tab=readme-ov-file#installing-a-development-version-of-the-component-manager

I also tried the same but in linux Linux ubuntu-ThinkPad-T14s-Gen-1 6.8.0-40-generic #40~22.04.3-Ubuntu SMP PREEMPT_DYNAMIC Tue Jul 30 17:30:19 UTC 2 x86_64 x86_64 x86_64 GNU/Linux and it doesn't allow me to run a build after running pip install idf-component-manager==2.0.0.dev1. When I try to build it shows this message:
The following Python requirements are not satisfied:
Requirement 'idf-component-manager~=1.2' was not met. Installed version: 2.0.0.dev1
To install the missing packages, please run "install.sh"
Diagnostic information:
    IDF_PYTHON_ENV_PATH: /home/ubuntu/.espressif/python_env/idf5.2_py3.11_env
    Python interpreter used: /home/ubuntu/.espressif/python_env/idf5.2_py3.11_env/bin/python
Constraint file: /home/ubuntu/.espressif/espidf.constraints.v5.2.txt
Requirement files:
 - /home/ubuntu/esp/esp-idf/tools/requirements/requirements.core.txt
Python being checked: /home/ubuntu/.espressif/python_env/idf5.2_py3.11_env/bin/python

ESP-IDF v5.2.2-143-g3e45883091

@cristianfunes79
The final version of the component manager 2.0 was released last week for the master branch and we will update the constraint files today to make it work.
The current work around is to disable the checks fist:
export IDF_PYTHON_CHECK_CONSTRAINTS=no
pip install -U idf-component-manager

The installed version should be 2.0.1

Hello @cristianfunes79, did you manage to solve the issue?


[OSPO Book] Scenarios & Recommendations - CH 4

Based on discussions from the past contributors' call: https://docs.google.com/document/d/1lbq_EfpAS3B7ygh8LkqLXiheAFwKWx3gYORAB7Aggio/edit
Two main scenarios were discussed:

Social Engineering Attack on Upstream xz/liblzma
License Changes and Software Trustworthiness (Redis use case)

Several best practices were raised during the call (see meeting notes for reference)

@anajsana I think that this PR and the google doc have become out of sync. At least, I believe there is more input on the google doc since this PR has been created!
This PR could be merged and the next round of changes added later, or we could abandon this PR and go back to editing - what do you prefer?

@anajsana I think that this PR and the google doc have become out of sync. At least, I believe there is more input on the google doc since this PR has been created!
This PR could be merged and the next round of changes added later, or we could abandon this PR and go back to editing - what do you prefer?

Good point, @alice-sowerby. It seems that this PR was created in the past and is now far behind the live version / main branch (see here). I noticed that the Google Doc is more aligned with the structure / content of the main branch of chapter-4.md, not the branch in this PR. +1 to close this PR without merging and open a new PR based on the g Doc

Included the changes from this PR in a new PR that contains the review of chapter 4 here: https://github.com/todogroup/ospology/pull/500


Rename the ServerWorld#getSurface method to getLightningPos

Fixes #2890

I suggest findLightningPos as this is computation than getting a property

IMO both find and get are fine, world methods can't generally be expected to be pure getters anyway.

sure, isn't a major confusion either


[FLINK-16864][metrics] Add IdleTime metric for task.

What is the purpose of the change
This pr adds an IdleTime metric which measures idle time of a task including the time cost for mail processor to wait for new mail and the time cost in record writer to waiting a new buffer.

when a job can not catch up with the speed of data generating, the vertex which idle time is near to zero is the bottle neck of the job.
when a job is not busy, idle time can be used to guide user how much he can scale down the job.

Brief change log
A meter metrics named idleTimeMsPerSecond is added in TaskIOMetricGroup:

*idleTime contains time waiting mail and time waiting output buffer. *
waiting mail time is collected when mail processor is trying to process a new mail but no mail submitted.
waiting output buffer time is collected when record writer is trying to request a new buffer from result partition but no buffer available.

Verifying this change
This change is already covered by existing tests, such as

TaskIOMetricGroupTest
RecordWriterTest
TaskMailboxProcessorTest

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): no
The public API, i.e., is any changed class annotated with @Public(Evolving): no
The serializers: no
The runtime per-record code paths (performance sensitive): no
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn/Mesos, ZooKeeper: no
The S3 file system connector: no

Documentation

Does this pull request introduce a new feature? yes
If yes, how is the feature documented? docs

hi, @pnowojski thanks for the review, all of the comments addressed except for  non-blocking getBufferBuilder, because I think it is unnecessary for collecting idle metric now.

@flinkbot run travis

@flinkbot run travis

@flinkbot run azure

@flinkbot run travis

@pnowojski thanks for the nice review and great suggestions. I will ping you once the CI turns green.

@flinkbot run travis

@flinkbot run azure

@pnowojski I rebased the code from master because of conflicts. Currently the travis is failing because of https://issues.apache.org/jira/browse/FLINK-17040, other tests passed.

@flinkbot run azure

Yep, I agree. Both Azure and Travis failed with same issue. Merging :)

Ops, before I merge, can you @wenlong88 squash all of the commits together and can you copy the PR description
This pr adds an IdleTime metric which measures idle time of a task including the time cost for mail processor to wait for new mail and the time cost in record writer to waiting a new buffer.

1. when a job can not catch up with the speed of data generating, the vertex which idle time is near to zero is the bottle neck of the job.
2. when a job is not busy, idle time can be used to guide user how much he can scale down the job.

to the commit message and
[FLINK-16864][metrics] Add IdleTime metric for task

as the commit's title? If do it from github, you would unfortunately loose authorship of the commits.

@pnowojski Thanks, I have squashed the commits and refine the commit message.


add event filter and set rabbitmq args

fix error: Pika connection lost Error: pika.exceptions.StreamLostError: Stream connection lost: ConnectionResetError(104, 'Connection reset by peer') set heartbeat=0
2)
fix incorrect method calendar.search
create custom generator event_filter which yield Conference instance if dtstart and dtend in between search 3)
3)
rewrite mistake in words .example.env

ok


BUG: fix the main page footer non res. #406

BUG: fix the main page footer non res. #406
Closes: #406
Fixes :

Fixed the footer , and drastically imporved code of footer by removing redundancy.
fixed the light mode color subscribe newsletter was not visible.
Fixed it for mobile screens.
Even fixed the misalignments of Social, Contact Us section.

Screenshot:

Summary by CodeRabbit

New Features

Redesigned footer layout for improved responsiveness, featuring a two-column design on larger screens.
Enhanced styling for the newsletter form and navigation components for better visual appeal.

Bug Fixes

Improved visual spacing and hierarchy within the footer for better readability across devices.

if you are upgrade the level, as i spent alot of time to imporve code, that would be good. rest your decision.
Happy to contribute.

@make the component little bit smaller

@RamakrushnaBiswal can you please specify you want the newsletter component to be a little more smaller for mobile devices right?

@RamakrushnaBiswal i made changes and make newsletter section a bit more smaller. hoping to get my PR merged. thank you.

@AE-Hertz good work

@RamakrushnaBiswal thank you.


Failed to call service husqvarna_automower.calendar. Command not allowed.

 Command not allowed." I followed the exact example in the Readme. The only thing I modified is the target entity. The same result occurs even with hardcoded times instead of templates.
Expected behavior
I think it should be able to set a calendar using this service call.
Screenshots
This is the call service I used:

And this is the error:

Additional context
Log extract:
2023-06-06 01:20:21.484 INFO (MainThread) [homeassistant.helpers.script.websocket_api_script] websocket_api script: Running websocket_api script
2023-06-06 01:20:21.485 INFO (MainThread) [homeassistant.helpers.script.websocket_api_script] websocket_api script: Executing step call service
2023-06-06 01:20:21.607 ERROR (MainThread) [custom_components.husqvarna_automower.vacuum] Command couldn't be sent to the command que: 400, message='Bad Request', url=URL('https://api.amc.husqvarna.dev/v1/mowers/f75221ab-24d7-49d2-b7b0-089bf6031439/calendar')
2023-06-06 01:20:21.612 ERROR (MainThread) [homeassistant.helpers.script.websocket_api_script] websocket_api script: Error executing script. Error for call_service at pos 1: Command not allowed
2023-06-06 01:20:21.617 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [547707877024] Error handling message: Command not allowed (unknown_error) Roberto from <IP_ADDRESS> (Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36)

Hi,
There are some possible reasons:

Have you checked, whether the sun entities exist on your system?

Yes. The templates produce the desired output.

Maybe your living above the polar circle, so there is no sunset and sunrise right now?

Creative troubleshooting. Love it!
But no. Don't live above the polar circle and the sun entities have values.

Some mowers, which are on mission don't support changing the schedule. See #452 . Which mower do you have and is it using mission?

This might be the reason. Same as in the referenced issue, I have a 415x with a single zone configured but, as the referenced issue mentions, maybe it's a matter of my mower supporting missions. Maybe you want to mark this as a duplicate and I'll keep an eye out for the linked issue instead.

Duplicate to #452


Increase default CLI gas from 200k to 350k

Currently the CLI defaults gas used to 200k if nothing is provided. Not really sure why its defaulting to a constant vs gas=auto.
But given that it is defaulting to something, and cases will likely persist where it defaults, we should bump the default imo. Its an unnecessary headache for CLI folks first interacting with the chain.
I suggest we bump the default 200k to 350k.

This happens to be set as a constant in the sdk side. Will create a PR in the cosmos SDK in osmosis repo and address issue for it


instance(watchout): Network error: connect ECONNREFUSED

I am getting the following error with the Watchout Module.
I open up Companion, and choose Local Host. (Watchout and Companion are running on the same Windows PC)
Once Companion has load and said its running i open up the GUI. I add in the Watchout Production PC IP address (instance(watchout): Network error: connect ECONNREFUSED <IP_ADDRESS>:3040)
I tried this on onother PC on the same network as Watchout and Running Companion and I get same error.

Have you gone into the WO preferences and enabled TCP/IP control for the project?

No I didnt do that. Have turned that on. Now issue has been solved. Thanks!


org: add github repo owner

Add "events"-github group as owner.

done

Thank you for adding it, but it is only "read" access.

too many buttons!


wrap: Avoid trailing whitespace for empty lines

What type of PR is this?

bug

What this PR does / why we need it:
Linter tools are picky about trailing whitespace, which creates problems when --help output is used in documentation and tests (https://github.com/sourcegraph/scip/pull/97).
Which issue(s) this PR fixes:
(REQUIRED)

Testing
(fill-in or delete this section)

Release Notes
(REQUIRED)

@julian7 any hints why test stared to fail after implementing the last suggestion? There is an extra line generated with that code.
Got:
        NAME:

         - add a task to the list

        USAGE:
           this is an even longer way
           of describing adding a task
           to the list

        DESCRIPTION:
           and a description long
           enough to wrap in this test
           case

        OPTIONS:
           --help, -h  show help (default: false)

Expected:
        NAME:
            - add a task to the list

        USAGE:
           this is an even longer way
           of describing adding a task
           to the list

        DESCRIPTION:
           and a description long
           enough to wrap in this test
           case

        OPTIONS:
           --help, -h  show help (default: false)

My only guess that something passes string that is not trimmed to wrap. But I don't see how wrap trimmed the string before. What changes though, is that if an empty string is passed to it, now the newline is returned. Could it be the case?

I refactored code to use slice instead of string buffer. PTAL.

@abitrolly Thank you for the PR. Help output is extremely fragile due to the newlines and white spaces etc. The wrap along with the template generates the output and even a slight change in template can create different outputs. If the tests pass that is good enough to merge. Just a heads up though that I have a PR #1506 which fixes a "similar" issue. Please review that as well. Thanks


Updating requirements for SLE

[x] This contribution adheres to CONTRIBUTING.md.

What does this Pull Request accomplish?
Update the minimum requirements for SystemLink Enterprise based on early estimates.
Why should this Pull Request be merged?
These changes reflect the resources needed by SystemLink Enterprise documented in this spreadsheet.
What testing has been done?
NA

I just saw #59. I'm closing this PR in favor of the new process.

I just saw #59. I'm closing this PR in favor of the new process.

You still need to submit template changes here.


[AMD] Restructure ReorderInstructions pass

This commit restructures the ReorderInstructions pass to be
more modular and cleaner with utility functions and guard
rule applications against their intended usage rather than
always being globally on. Along the way, dropped some
unnecessary local_load sink given it's later hoisted again.
Fixes https://github.com/ROCm/triton-internal/issues/280

@zhanglx13: first commit is basically NFC with some IR mutation robustness improvements. the second and third commit is meaningful changes. i'd suggest to view the diff with "Hide whitespace" toggle on.


Crashlytics Veracode Issue on FABNetworkClient.m

Hello,
I am using Veracode Tool for code static analysis
https://www.veracode.com
and I am facing one security issue on Crashlytics component
Xcode version: 10.3
Firebase SDK version: 6.13.0
Firebase Component: Crashlytics
Version: 3.13.2
The issue says:
File - FABNetworkClient.m: 189
"Description: In this call to FABNetworkClient.completionHandler:(), host-specific certificate data is not validated or is incorrectly validated. Failing to validate the certificate makes the SSL session susceptible to a man-in-the-middle attack.
Remediation: Verify that the certificate is valid, matches the requested site, and is signed by a trusted root authority. Generate an error and destroy the connection if any of these conditions are not met."

See https://github.com/firebase/firebase-ios-sdk/issues/4478#issuecomment-564728528


Cache problem in the load_dataset method for local compressed file(s)

Describe the bug
Cache problem in the load_dataset method: when modifying a compressed file in a local folder load_dataset doesn't detect the change and load the previous version.
Steps to reproduce the bug
To test it directly, I have prepared a Google Colaboratory notebook that shows this behavior.
For this example, I have created a toy dataset at: https://huggingface.co/datasets/SaulLu/toy_struc_dataset
This dataset is composed of two versions:

v1 on commit a6beb46 which has a single example {'id': 1, 'value': {'tag': 'a', 'value': 1}} in file train.jsonl.gz
v2 on commit e7935f4 (main head) which has a single example {'attr': 1, 'id': 1, 'value': 'a'} in file train.jsonl.gz

With a terminal, we can start to get the v1 version of the dataset
git lfs install
git clone https://huggingface.co/datasets/SaulLu/toy_struc_dataset
cd toy_struc_dataset
git checkout a6beb46

Then we can load it with python and look at the content:
from datasets import load_dataset

path = "/content/toy_struc_dataset"
dataset = load_dataset(path, data_files={"train": "*.jsonl.gz"})
print(dataset["train"][0])

Output
{'id': 1, 'value': {'tag': 'a', 'value': 1}} # This is the example in v1

With a terminal, we can now start to get the v1 version of the dataset
git checkout main

Then we can load it with python and look at the content:
from datasets import load_dataset

path = "/content/toy_struc_dataset"
dataset = load_dataset(path, data_files={"train": "*.jsonl.gz"})
print(dataset["train"][0])

Output
{'id': 1, 'value': {'tag': 'a', 'value': 1}} # This is the example in v1 (not v2)

Expected results
The last output should have been
{"id":1, "value": "a", "attr": 1} # This is the example in v2

Ideas
As discussed offline with Quentin, if the cache hash was ever sensitive to changes in a compressed file we would probably not have the problem anymore.
This situation leads me to suggest 2 other features:

to also have an load_from_cache_file argument in the "load_dataset" method
to reorganize the cache so that we can delete the caches related to a dataset (cf issue #ToBeFilledSoon)

And thanks again for this great library :hugs:
Environment info

datasets version: 1.12.1
Platform: Linux-5.4.104+-x86_64-with-Ubuntu-18.04-bionic
Python version: 3.7.12
PyArrow version: 3.0.0

The problem is still present.
One solution would be to add the download_mode="force_redownload" argument to load_dataset.
However, doing so may lead to a DatasetGenerationError: An error occurred while generating the dataset. To mitigate, just do:
rm -r ~/.cache/huggingface/datasets/*


Alembic export

This pull request adds alembic support in openMVG, providing the ability to export points with colors and cameras with their image plane.
I am not sure which branch we should merge with, please don't hesitate to switch branch if needed.
Cyril

Hi @cpichard ,
sorry there is a bit of a mess now with the Alembic support. I actually refactored the code and added Import/Export class inside the library (as we did for cameraLocalization and mockUp) If you want to take a look
https://github.com/poparteu/openMVG/tree/voctree_localizer/src/openMVG/dataio
And then I use them for the exporter.
For what i see the main difference with your version is that you added the colored cloud and the image plane. But I think it can be easily integrated in the class I made (adding a new method and refactoring a bit i guess). What do you think?
Also @fabiencastan @caymard are about to work on that
S.

Hi Simone,
sure, this would be more convenient to have this code inside the library, do you want to merge it yourself in your branch ? it's only a matter of several lines. Let me know !
C

Code imported manually.


Fix influxd help usage

Fix influxd help usage.

This makes sense.  @s7v7nislands can you rebase this and then likely all the tests should pass.  Thanks!

rebased!

+1

+1


Question: Can connect from a halcyon grid/standalone to another halcyon grid / standalone ?

Hello ;D
I Know that Inworldz is no hypergrid compatible, but can I connect from a halcyon grid/standalone to another halcyon grid / standalone ?
Greetings
Bogus

Besides running all the regions under the same grid there isn't yet a cross-grid travel option. We're keeping options open on that.

ahh ok .. thanks for the answer ;D


new file:   exercises/lesson02/1/avenito/Makefile

new file:   exercises/lesson02/1/avenito/build.bat
new file:   exercises/lesson02/1/avenito/build.sh
new file:   exercises/lesson02/1/avenito/include/arm/sysregs.h
new file:   exercises/lesson02/1/avenito/include/mini_uart.h
new file:   exercises/lesson02/1/avenito/include/mm.h
new file:   exercises/lesson02/1/avenito/include/peripherals/base.h
new file:   exercises/lesson02/1/avenito/include/peripherals/gpio.h
new file:   exercises/lesson02/1/avenito/include/peripherals/mini_uart.h
new file:   exercises/lesson02/1/avenito/include/printf.h
new file:   exercises/lesson02/1/avenito/include/utils.h
new file:   exercises/lesson02/1/avenito/src/boot.S
new file:   exercises/lesson02/1/avenito/src/config.txt
new file:   exercises/lesson02/1/avenito/src/kernel.c
new file:   exercises/lesson02/1/avenito/src/linker.ld
new file:   exercises/lesson02/1/avenito/src/mini_uart.c
new file:   exercises/lesson02/1/avenito/src/mm.S
new file:   exercises/lesson02/1/avenito/src/printf.c
new file:   exercises/lesson02/1/avenito/src/utils.S
new file:   exercises/lesson02/2/avenito/Makefile
new file:   exercises/lesson02/2/avenito/README.md
new file:   exercises/lesson02/2/avenito/build.bat
new file:   exercises/lesson02/2/avenito/build.sh
new file:   exercises/lesson02/2/avenito/dis_with.txt
new file:   exercises/lesson02/2/avenito/dis_without.txt
new file:   exercises/lesson02/2/avenito/include/arm/sysregs.h
new file:   exercises/lesson02/2/avenito/include/mini_uart.h
new file:   exercises/lesson02/2/avenito/include/mm.h
new file:   exercises/lesson02/2/avenito/include/peripherals/base.h
new file:   exercises/lesson02/2/avenito/include/peripherals/gpio.h
new file:   exercises/lesson02/2/avenito/include/peripherals/mini_uart.h
new file:   exercises/lesson02/2/avenito/include/printf.h
new file:   exercises/lesson02/2/avenito/include/utils.h
new file:   exercises/lesson02/2/avenito/src/boot.S
new file:   exercises/lesson02/2/avenito/src/config.txt
new file:   exercises/lesson02/2/avenito/src/kernel.c
new file:   exercises/lesson02/2/avenito/src/linker.ld
new file:   exercises/lesson02/2/avenito/src/mini_uart.c
new file:   exercises/lesson02/2/avenito/src/mm.S
new file:   exercises/lesson02/2/avenito/src/printf.c
new file:   exercises/lesson02/2/avenito/src/utils.S
new file:   exercises/lesson02/3/avenito/Makefile
new file:   exercises/lesson02/3/avenito/README.md
new file:   exercises/lesson02/3/avenito/build.bat
new file:   exercises/lesson02/3/avenito/build.sh
new file:   exercises/lesson02/3/avenito/include/arm/sysregs.h
new file:   exercises/lesson02/3/avenito/include/mm.h
new file:   exercises/lesson02/3/avenito/include/peripherals/base.h
new file:   exercises/lesson02/3/avenito/include/peripherals/gpio.h
new file:   exercises/lesson02/3/avenito/include/peripherals/uart.h
new file:   exercises/lesson02/3/avenito/include/printf.h
new file:   exercises/lesson02/3/avenito/include/uart.h
new file:   exercises/lesson02/3/avenito/include/utils.h
new file:   exercises/lesson02/3/avenito/src/boot.S
new file:   exercises/lesson02/3/avenito/src/config.txt
new file:   exercises/lesson02/3/avenito/src/kernel.c
new file:   exercises/lesson02/3/avenito/src/linker.ld
new file:   exercises/lesson02/3/avenito/src/mm.S
new file:   exercises/lesson02/3/avenito/src/printf.c
new file:   exercises/lesson02/3/avenito/src/uart.c
new file:   exercises/lesson02/3/avenito/src/utils.S

Lesson 2 exercises. Thank you for your work


Conflict with pycurl (async code)

Hi!
Code:
    import asyncio
    import pycurl # code work whitout this import
    from bonsai import LDAPClient, LDAPSearchScope

    async def do():
        LDAP_SERVER = ''
        LDAP_USER = ''
        LDAP_PASSWORD = ''

        client = LDAPClient(LDAP_SERVER)
        client.set_credentials("SIMPLE", (LDAP_USER, LDAP_PASSWORD))

        async with client.connect(is_async=True) as conn:
            await conn.search(
                base="cn=users_catalog,ou=users,dc=<DC>",
                scope=LDAPSearchScope.SUBTREE,
            )

    loop = asyncio.get_event_loop()
    loop.run_until_complete(do())

Output:
Assertion failed: (LDAP_VALID( ld )), function ldap_set_option, file options.c, line 456.

Platform:
$ python -V
Python 3.6.3

$ uname -a
Darwin MacBook-Pro-admin.local 17.0.0 Darwin Kernel Version 17.0.0: Thu Aug 24 21:48:19 PDT 2017; root:xnu-4570.1.46~2/RELEASE_X86_64 x86_64

$ clang -v
Apple LLVM version 9.0.0 (clang-900.0.38)
Target: x86_64-apple-darwin17.0.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

Thanks for reporting it. I've successfully reproduced the bug. It doesn't even have to be an asynchronous connection, just importing pycurl.
It looks very odd. I'll look into it thoroughly, as soon as I can.

I think I've found the source of the problem:

The pycurl module uses the libcurl library that's shipped with Mac. Of course, this libcurl library is linked with the libldap that can be found on the OS by default.
On the other side, bonsai uses a newer version of libldap which is distributed with the module itself.

So when importing both modules, the interpreter loads two different versions of the libldap library causing this weird assertion failure that you've experienced.
To prove my theory I built curl on a Mac without LDAP/LDAPS support, built and installed the pycurl module (linked with my LDAPless libcurl library) then I was able to import both pycurl and bonsai and ran the example.
But unfortunately, I don't have a fix that can solve this. The best solution that I read so far was rebuilding the libcurl to also use the newer libldap library. I haven't come across any other solution that can solve this somehow with code or configuration.


[ENGOPS-3650] change Pentaho to Hitachi Vantara and update copyright date

WARNING!  FOR MERGE BY PROCESS ONLY PLEASE!

Build Completed
:x: This pull request has errors. They will need to be addressed before it can be accepted. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
ant -Dtestreports.dir=bin/reports/unit-test -f build.xml clean-all resolve jacoco && ant -f build.xml checkstyle publish-local

Cleanup Commands
rm -r ~/.ivy2/local || echo no publish local to remove

Build Sensitive Files Changed
  build-res/subfloor.xml

Changed files
  build-res/subfloor.xml


⚠ Bofrost.de has degraded performance

In 4a79a2f, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1572 ms

Resolved: Bofrost.de performance has improved in 401798a after 6 minutes.


WiLY problem + naive softmax model (with Trainable Params: 762411675!!)

This pull request introduces 1 alert when merging 2a0f239e406c01a6849d18f30ff17fe296a126c5 into b9926fe18606c3a7f24050895d57de49b0c3057b - view on LGTM.com
new alerts:

1 for Unused import

Comment posted by LGTM.com

This pull request introduces 1 alert when merging 0d5ac4cf64d667b56bde12968aa4bc971b2a2a72 into b9926fe18606c3a7f24050895d57de49b0c3057b - view on LGTM.com
new alerts:

1 for Unused import

Comment posted by LGTM.com

This pull request introduces 3 alerts when merging 3484716fb887d8f42844cd5ac5509e9bbad4d4d4 into b9926fe18606c3a7f24050895d57de49b0c3057b - view on LGTM.com
new alerts:

1 for Unused import
1 for Mismatch between signature and use of an overriding method
1 for Wrong number of arguments in a class instantiation

Comment posted by LGTM.com

This pull request introduces 1 alert when merging 62e9cc81b0103a87d2bf397d9353d6c47181bbcf into b9926fe18606c3a7f24050895d57de49b0c3057b - view on LGTM.com
new alerts:

1 for Unused import

Comment posted by LGTM.com

This pull request introduces 1 alert when merging 4def2f035c2d9b292ccbed7d6ed2f580d292d6d8 into b9926fe18606c3a7f24050895d57de49b0c3057b - view on LGTM.com
new alerts:

1 for Unused import

Comment posted by LGTM.com

This pull request introduces 2 alerts when merging 41ec1659fc37970cd40315d1fb54b8ba25a15f47 into b9926fe18606c3a7f24050895d57de49b0c3057b - view on LGTM.com
new alerts:

1 for Unused import
1 for Mismatch between signature and use of an overriding method

Comment posted by LGTM.com

This pull request introduces 1 alert when merging 13ca3717ed2617909124ee2943cc1dc50e442f44 into b9926fe18606c3a7f24050895d57de49b0c3057b - view on LGTM.com
new alerts:

1 for Mismatch between signature and use of an overriding method

Comment posted by LGTM.com


added "ignores" option to be passed in as an option when instantiating CodeMirror

A lot of those changes were generated by your gulp build process. The only relevant file I changed was spell-checker.js
Didn't know you had a build env - my bad for not reading!
PS: This is just a start! But I'm planning on adding extra options, like a support emoji option where it will test for UTF16 codepoints and won't attempt to spell check in the specific emoji ranges. Let me know what you think.

Here's the JSFiddle
Not sure why that build failed, since it failed when globally installing gulp into the VM. The other's passed though.

Thanks


Warn instead of trace when errors happen in the spin_redis_engine

Changes the tracing level to warn as otherwise it leads to cases where the module errored and it looks like Spin hanged. I ran into this while using an invalid component. I could not understand its cause until @dicej recommended switching from debug to trace.

@dicej what would be the recommended way of handling it? add some tracing there?

I would suggest doing a tracing::warn in the RedisTrigger::run loop instead of dropping the error (which would make the change you already made unnecessary).  Either that, or stick with your current change and remove the Result<()> return types from RedisTrigger::handle and RedisExecutor::execute since they're just ignored anyway.

@dicej @itowlson - I have updated the PR.


cargo build -p prqlc isn't really cached after cargo build

What's up?
cargo clean
cargo build # takes 30 seconds
cargo build -p prqlc # takes 17 seconds — *not 0 seconds!*

cargo clean
cargo build -p prqlc # takes 22 seconds.

So the really curious thing is why running cargo build hardly helps with cargo build -p prqlc given it presumably builds prqlc as part of its build.
This hits us in the CI runtime of building prqlc.
Is it something to do with the dependencies being slightly different — e.g. features being different?

I tried aligning the dependency features etc, but it didn't seem to help.
diff --git a/crates/prql-compiler/Cargo.toml b/crates/prql-compiler/Cargo.toml
index 4b6745e2..e0748a90 100644
--- a/crates/prql-compiler/Cargo.toml
+++ b/crates/prql-compiler/Cargo.toml
@@ -11,15 +11,15 @@ version.workspace = true
 metadata.msrv = "1.65.0"

 [features]
-default = []
+default = ["serde_yaml"]
 # Technically tokio could be limited to external tests, but its types are in
 # signatures which would require lots of conditional compilation.
 test-dbs = ["duckdb", "rusqlite", "tokio"]
 test-dbs-external = ["chrono", "duckdb", "mysql", "pg_bigdecimal", "postgres", "rusqlite", "tiberius", "tokio", "tokio-util"]

 [dependencies]
-prql-ast = {path = "../prql-ast", version = "0.9.2" }
-prql-parser = {path = "../prql-parser", version = "0.9.2" }
+prql-ast = {path = "../prql-ast", version = "0.9.2"}
+prql-parser = {path = "../prql-parser", version = "0.9.2"}

 anstream = {version = "0.3.2", features = ["auto"]}
 anyhow = {version = "1.0.57", features = ["backtrace"]}
@@ -39,7 +39,7 @@ sqlparser = {version = "0.36.0", features = ["serde"]}
 strum = {version = "0.25.0", features = ["std", "derive"]}
 strum_macros = "0.25.0"

-serde_yaml = {version = "0.9", optional = true}
+serde_yaml = {version = "0.9.1", optional = true}

 [target.'cfg(not(target_family="wasm"))'.dependencies]
 # For integration tests. These are not listed as dev-dependencies because
diff --git a/crates/prqlc/Cargo.toml b/crates/prqlc/Cargo.toml
index 9623942a..f99603d0 100644
--- a/crates/prqlc/Cargo.toml
+++ b/crates/prqlc/Cargo.toml
@@ -12,7 +12,7 @@ metadata.msrv = "1.65.0"

 [target.'cfg(not(target_family="wasm"))'.dependencies]
 anstream = {version = "0.3.2", features = ["auto"]}
-anyhow = {version = "1.0.57"}
+anyhow = {version = "1.0.57", features = ["backtrace"]}
 ariadne = "0.3.0"
 clap = {version = "4.3.0", features = ["derive", "env", "wrap_help"]}
 clap_complete_command = "0.5.1"
@@ -23,10 +23,10 @@ colorchoice-clap = "1.0.0"
 env_logger = {version = "0.10.0", features = ["color"]}
 itertools = "0.11.0"
 notify = "^6.0.0"
-prql-ast = {path = '../prql-ast', version = "0.9.2" }
-prql-compiler = {path = '../prql-compiler', features = ["serde_yaml"], version = "0.9.2" }
+prql-ast = {path = '../prql-ast', version = "0.9.2"}
+prql-compiler = {path = '../prql-compiler', features = ["serde_yaml"], version = "0.9.2"}
 regex = {version = "1.9.0", features = ["std", "unicode"]}
-serde = "^1"
+serde = {version = "1.0.137", features = ["derive"]}
 serde_json = "1.0.81"
 serde_yaml = "0.9.1"
 walkdir = "^2.3.2"

I've noticed this even in smaller project without features and a bunch of dependencies. This might help: https://stackoverflow.com/questions/70174147/how-do-i-make-cargo-show-what-files-are-causing-a-rebuild

A description consistent with https://github.com/PRQL/prql/pull/3115#issue-1823056908 is here

However, one drawback is that this can increase build times because the dependency is built multiple times (each with different features). When using the version "2" resolver, it is recommended to check for dependencies that are built multiple times to reduce overall build time. If it is not required to build those duplicated packages with separate features, consider adding features to the features list in the dependency declaration so that the duplicates end up with the same features (and thus Cargo will build it only once). You can detect these duplicate dependencies with the cargo tree --duplicates command. It will show which packages are built multiple times; look for any entries listed with the same version. See Inspecting resolved features for more on fetching information on the resolved features. For build dependencies, this is not necessary if you are cross-compiling with the --target flag because build dependencies are always built separately from normal dependencies in that scenario.

Closing as "a known problem which we can't do much about". The description at the top of the previous comment explains it well.


Split View

Let's add an emacs style split view so we can add tabs like that. We don't add browser tabs in a tab bar, we add it like emacs split view. This enables us to map across many pages at once.
Having all the pages there at the same time isn't even necessary since the map preserves its data independent of what any tab is doing.
Also each split van be chosen to "split off" an existing tab ( and so it will inherit the same partition for cookies etc ), or it can create a new context. Super easy and very powerful.
An elegant and simple solution to a complex and big problem.
Definite 90/10.

https://www.gnu.org/software/emacs/manual/html_node/emacs/Split-Window.html

Unnecessary, confusing.


Add S3 ring/sector mult, tweaked ChiSq for CsI fits in TPulseAnalyzer, add TIGRESS fwd/back positions

Added some more S3 functionality to make checking sector/rings easier.
Tweaked TPulseAnalyzer to fix some problems with the ChiSq values in the TIP CsI fitting.

I've also added backwards positions for the TIGRESS crystals so we can easily flip between suppressed and high-efficiency modes, and filled in the downstream lampshade positions in the forward (high-efficiency) configuration which were missing previously.


Document different ways go.sum is populated

What version of Go are you using (go version)?

$ go version
go version go1.11.4 darwin/amd64

Does this issue reproduce with the latest release?
1.11.4 is the latest release
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/lukasz/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/lukasz/Go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/qs/6r1dd8md22bggtghnmmhlf9m0000gn/T/go-build246619765=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

This was noticed via https://github.com/renovatebot/renovate/issues/3017, I didn't manage to find any details of what should be in go.sum.
go get -d populates go.sum file with different content if a dependency present in go.mod is used or not
Dependency used
go.mod:
module github.com/prymitive/test

require gopkg.in/yaml.v2 v2.2.2

main.go
package main

import _ "gopkg.in/yaml.v2"

func main() {}

Running go get creates a go.sum file:
$ GO111MODULE=on go get -d
$ cat go.sum
gopkg.in/check.v1 v0.0.0-20161208181325-20d25e280405/go.mod h1:Co6ibVJAznAaIkqp8huTwlJQCZ016jof/cbN4VW5Yz0=
gopkg.in/yaml.v2 v2.2.2 h1:ZCJp+EgiOT7lHqUV2J862kp8Qj64Jo6az82+3Td9dZw=
gopkg.in/yaml.v2 v2.2.2/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI=

If I remove import _ "gopkg.in/yaml.v2" line from main.go so that it contains:
package main

func main() {}

Remove go.sum and re-run go get:
$ rm go.sum
$ GO111MODULE=on go get -d
$ cat go.sum
gopkg.in/check.v1 v0.0.0-20161208181325-20d25e280405/go.mod h1:Co6ibVJAznAaIkqp8huTwlJQCZ016jof/cbN4VW5Yz0=
gopkg.in/yaml.v2 v2.2.2/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI=

I'll get one line less in go.sum file (gopkg.in/yaml.v2 v2.2.2 h1:ZCJp+EgiOT7lHqUV2J862kp8Qj64Jo6az82+3Td9dZw=).
What did you expect to see?
I expected go.sum to be created in a consistent way, which would help with reproducible builds.
Having documentation around it would help manage expectations around the behavior of how go.sum is populated under different scenarios.
One reason that know this is useful is that it was mentioned that go.sum is "kinda like a lockfile" and one should commit it to the vcs. Because it gets populated differently under different scenarios it's not clear to me when should I commit it. After reading that go mod tidy ensures that dependecies for all possible OS/arch combos are preset it seems to me that ideally one should commit go.sum only after running go mod tidy, otherwise some commands might generate local changes in that file.
What did you see instead?
go.sum is created with different content depending on which dependencies from go.mod are imported.

/cc @bcmills

We should wait to document this until #25530 is resolved, since that will change when and how go.sum is populated.
In general, though, you can commit the go.sum file at any point: entries may be added or deleted as you run go mod tidy and various build/test commands, but the entry for a given version will not change.
go mod tidy should populate go.sum with an essentially complete set of entries.


Index is not being created in Elasticsearch

Hi,
I've been trying to transport a mongodb collection to an index in Elasticsearch. It seems that my config is correct; in fact, transport exits with no errors (I tested some debug like passthrough_and_log.js, and it shows what is supposed to), problem is, when I list the available indexes in Elasticsearch, they were not created. I've been trying this from yesterday, and nothing works.
Some important notes:

I tried the same with /tmp/foo as output sink and it worked flawlessly.
When I use the same names for db.collection -> index.type e.g.: foo.bar -> foo.bar, transport process is slow (I was able to note this because I also tried to transport a custom collection which is larger - it took hours!). But today I tried: foo.bar -> foo.type1, and it worked ridiculously fast (11secs) compared to the former.
I am using the transporter 0.1.1 binary release for linux x86_64 on RHEL7
I am using Elasticsearch 5.1.1 (maybe elasticgo does not support this version?)

@rcastill can you provide the yaml and js files used (with any credentials removed)? We're working on getting the elasticsearch adaptor stabilized due to all of the changes between ES 1.7->2.X->5.X.

Sigh, I realized a problem thanks to your answer: I was not passing credentials.
Now, I passed credentials for the test under "simple" directory in your tests and it worked.
New things to consider:

It looks like "foo.type1" won't work because data is not indexed in Elasticsearch.
I'm currently running transport to index a personal collection (91268 documents) and it is slow as I stated before (very slow :c)
In the latter indexing process I'm getting multiple:

transporter: CRITICAL: elasticsearch error (Bulk Insertion Error. Failed item count [N])
Where N has taken as values 67, 68, 69 so far
Do you still need my config files?

It looks like "foo.type1" won't work because data is not indexed in Elasticsearch.

if you want to change the type/collection part, you'd need to use a transform function to change the namespace, something like the following should work:
module.exports = function(doc) {
  doc.ns = "foo.type1";
  return doc
}

and make sure you have the namespace set properly in the app.js file.

I'm currently running transport to index a personal collection (91268 documents) and it is slow as I stated before (very slow :c)

it's hard to say what could be the cause here but I assume you're running transporter locally? and trying to send data to a remote elasticsearch?
re: performance, it's something we hope to solve with https://github.com/compose/transporter/issues/209
re:
transporter: CRITICAL: elasticsearch error (Bulk Insertion Error. Failed item count [N])

That looks to be an error on the elasticsearch side so would possibly need to look at the logs there.

In fact both elasticsearch and mongo are local.
I finally gave up, since it may be a version incompatibility issue and started working in a tool in Python using elasticsearch and pymongo libs.
Nevertheless I'll be following this project for any update that may come.
Greetings!

@rcastill Bulk Insertion is most likely due to malformed _id.
You need to handle it like so:
module.exports = function(msg) {    msg.data._id = msg.data._id.$oid;     return msg;  }
This maintains the same _id in both ES and Mongo.

I tried that already with no success

Okay, well if you still have your configs you can attach them and we can take a look. (If you haven't fully moved on yet)

Exact same problem here. There are no error in the output anywhere and I see no indexes getting created in ES.
Here are my files:
nodes:
  mongo:
    type: mongo
    uri: mongodb://dadhx03.interno:27018/TecnicoVirtual
    namespace: TecnicoVirtual.Logging
    debug: true
  es:
    type: elasticsearch
    uri: http://dadhx03.interno:9201/
    namespace: tecvirt.logging
    debug: true
  debug:
    type: file
    uri: stdout://
  stdout:
    type: file
    uri: stdout://

pipeline = Source({name:"mongo", namespace:"TecnicoVirtual.Logging", tail:true, bulk:true}).transform({filename: "transformers/passthrough_and_log.js", namespace: "Tecni
coVirtual.Logging"}).save({name:"es", namespace:"tecvirt.logging"});

@cdechery what version of elasticsearch are you testing with and also what version of transporter?

@jipperinbham ES version 2.4;, transporter 0.1.0.
I downloaded a docker image that contained a mongo, an elasticsearch and transporter, all setup to work, but it didn't. I got version problems.  So I updated ES to try, and now I can see on my output all the documents from mongo being printed out (as they run through the transform) but nothing gets created on ES and I see no error messages.

gotcha, there was a bug fix that went out with 0.1.1, would you be able to try that version?
also, we're planning on publishing official packages and images in the near future

hello, I got the same problem like @cdechery case.
My ES version is 5.1.1 and transporter is 0.1.1
all documents can be printed out from mongo
but nothing created on ES too

I'm finally getting the data in the index. After updating to version 0.11 and changing some settings on the transporter JS files. But it is still not perfect.
I'm getting several messages like this transporter: CRITICAL: elasticsearch error (Bulk Insertion Error. Failed item count [45]) and oddly enough, the number of documents loaded into ES is bigger than the number of documents on the source database.
Also, the process doesn't END. It gets stuck after theses error messages.

@cdechery @SYTF @rcastill @JherezTaylor please try out the latest release, v0.1.2. I'm going to close this issue out but please feel free to re-open it or create a new one if you're seeing a problem.


add documentation

@david-dd-amar please expand on the documentation for the following objects in R/data.R, marked with TODO:

[ ] METHYL_FEATURE_ANNOT
[ ] METHYL_RAW_DATA
[ ] METHYL_RAW_COUNTS
[ ] GRAPH_STATES details (can be copy-paste from landscape paper methods)

@pierremj please expand on the documentation for the following objects in R/data.R, marked with TODO:

[ ] METAB_SAMPLE_DATA_NESTED details, i.e., how the version of normalized data was picked for each dataset
[ ] PROTEOMICS_META

@nicolerg finish documentation for the following objects in R/data.R, marked with TODO:

[ ] METAB_FEATURE_ID_MAP details
[ ] ATAC_RAW_COUNTS
[ ] ATAC_NORM_DATA_05FDR
[ ] ATAC_DA

use branch documentation

only remaining documentation is for METAB_DA_METAREG. @david-dd-amar can you add some details before submission?


GKE Requires "--cluster-version=1.10.4-gke.2" in docs

Describe the bug
Following the GKE instructions for quick starting Istio, the following command fails:
From here:
Create a new cluster.
gcloud container clusters create <cluster-name> \
    --cluster-version=1.9.7-gke.1 \
    --zone <zone> \
    --project <project-name>

Throws
ERROR: (gcloud.container.clusters.create) ResponseError: code=400, message=master version "1.9.7-gke.1" is unsupported.

GKE no longer supports 1.9.7-gke.1 according to these release notes
Expected behavior
Running with the updated --cluster-version:
root@dblb:~# gcloud container clusters create istio --cluster-version=1.10.4-gke.2 --zone us-central1-b
WARNING: Currently node auto repairs are disabled by default. In the future this will change and they will be enabled by default. Use `--[no-]enable-autorepair` flag  to suppress this warning.
WARNING: Starting in Kubernetes v1.10, new clusters will no longer get compute-rw and storage-ro scopes added to what is specified in --scopes (though the latter will remain included in the default --scopes). To use these scopes, add them explicitly to --scopes. To use the new behavior, set container/new_scopes_behavior property (gcloud config set container/new_scopes_behavior true).
Creating cluster istio...done.

Steps to reproduce the bug
The documentation as is fails to launch.
Version
What version of istio and Kubernetes are you using? Use istioctl version and kubectl version
istioctl version:
Version: 0.8.0
GitRevision: 6f9f420f0c7119ff4fa6a1966a6f6d89b1b4db84
User: root@48d5ddfd72da
Hub: docker.io/istio
GolangVersion: go1.10.1
BuildStatus: Clean

kubectl version:
Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.7", GitCommit:"dd5e1a2978fd0b97d9b78e1564398aeea7e7fe92", GitTreeState:"clean", BuildDate:"2018-04-19T00:05:56Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"10+", GitVersion:"v1.10.4-gke.2", GitCommit:"eb2e43842aaa21d6f0bb65d6adf5a84bbdc62eaf", GitTreeState:"clean", BuildDate:"2018-06-15T21:48:39Z", GoVersion:"go1.9.3b4", Compiler:"gc", Platform:"linux/amd64"}

Is Istio Auth enabled or not?
N/A
Environment
Ubuntu 16 with GKE as the Kubernetes provider.

Duplication of #6520


Release notes automation

Automate the generation of release notes for all the Legend components.

Closing this issue as stale. Please re-open if still relevant.


Mult-file multiple-line find (& replace)

Enhance multiple-line find (& replace) to work for multiple files.
Steps which explain the enhancement

Press meta-shift-f
Enter your desired multiple-line find and replace values
Hit find (or replace/replace all) to complete the appropriate actions across all relevant files

Current and suggested behavior
Currently find (& replace) supports multiple-line entries in the currently open file, however no results will be returned if this is attempted for a multi-file search.
It would be very valuable to be able to do this... I find myself wishing this behavior was offered more than I would hope.
Why would the enhancement be useful to most users
Find & Replace is an invaluable tool in a multitude of scenarios, but one concrete example is when modifying multiple JSON files which contain the same, outdated schema.
If course this is only one of many possible use cases.
Atom Version: 1.5.4
OS and Version: All

I just encountered this issue and would find the enhancement described here useful.


[samba] Unmaintained image with security flaws

Details
Helm chart name and version:
samba

Container name and tag:
dperson/samba

The docker image suffers from security issues like https://github.com/dperson/samba/issues/407.
I have't found a better docker image yet, this looks promising but there are k8s issues:
https://github.com/crazy-max/docker-samba
I think a special docker image and a configmap for the smb.conf and secrets for the users might be a better longterm solution.

I'd be fine with switching it out for a more maintained image.
Could you be more specific about the k8s issues with the alternative you provided?
It seems that it can be configured with ENV vars and a yaml file (can be provided by either configMap or Secret). That would make it work pretty well I'd think?

I have seen this issue but I haven't double checked it:
https://github.com/crazy-max/docker-samba/issues/12

This person has mounted a configMap to the /data folder. But configMaps are always read-only. If the configuration has to be mounted to a path inside /data, ideally a subPath should have been  used.

/data should be emptydir and the configfile a subpath

Sounds about right 👍🏻


Add check to protect memcpy(3) from using NULL pointer.

The ntlm_construct_challenge_target_info function can potentially pass NULL as
argument to the ntlm_av_pair_add function (for example DnsDomainName.Buffer).
This NULL finally lands in the CopyMemory (which is macro to the memcpy(3)
function) which can't handle NULL.
Sponsored by: WHEEL Systems (http://www.wheelsystems.com)

@freerdp-bot test.

@oshogbo  For later reference -  in which context did you find this problem?

@bmiklautz It seems that real problem was here: #2613.

@oshogbo so we can close it can't we ?

@hardening Good question.
It's depend about FreeRDP politic. Do FreeRDP want to handle boundary cases?

If not we can close it.
If FreeRDP want it should be merged.
In feature developing passing a null values to the memcpy(3) could cause more problems.

But its depend about politic and I will be happy with any decision. :)

@oshogbo I think the question is more "where do we have to put the checks". ntlm_av_pair_add is clearly not supposed to be called with a NULL value, so either we treat the callers (which has been done by https://github.com/FreeRDP/FreeRDP/pull/2613), or we must do something more agressive than silently returning as in your patch (assert or close the connection)

@Hardening: I'm not a big fun of supposing that otter program will not do
somthing. In my opinion bather assumption is he could do it.
Assertion is the best idea, but not sure if FreeRDP is using it.
On Mon, May 18, 2015 at 02:29:43PM -0700, Hardening wrote:

@oshogbo I think the question is more "where do we have to put the checks". ntlm_av_pair_add is clearly not supposed to be called with a NULL value, so either we treat the callers (which has been done by https://github.com/FreeRDP/FreeRDP/pull/2613), or we must do something more agressive than silently returning as in your patch (assert or close the connection)

Reply to this email directly or view it on GitHub:
https://github.com/FreeRDP/FreeRDP/pull/2608#issuecomment-103217815

--

@hardening I change my commit to use assert.


[WIP] - Feat deployment recreate

Implemented initial code and performed basic testing.
Outstanding:

[ ] Perform more live testing
[ ] Provide tests
[ ] Documentation
[ ] Understand differences between kubctl [replace, apply, patch]

closes #878

Current coverage is 81.73% (diff: 66.66%)

Merging #958 into master will decrease coverage by 0.13%

@@             master       #958   diff @@
==========================================
  Files            28         28
  Lines          3055       3060     +5
  Methods           0          0
  Messages          0          0
  Branches        510        511     +1
==========================================
  Hits           2501       2501
- Misses          405        408     +3
- Partials        149        151     +2

Powered by Codecov. Last update 77dbf94...04c4d36

@lachie83 Do you want to try to bring this over the line?

@lachie83 is this still in progress, or should we close it?

Hi @mboersma. We had a user at the time that was looking at using this which is why I started work on it. Do you think it's a useful feature to have? If so I can commit to getting the testing done.

Yes! I think this would be useful to others for sure. If you have some spare time and want to hack on the rest of the work we'd be happy to get it in.

Fantastic. I'll try and knock it out after the holidays.

I'm going to close this since it's almost a year old, but @lachie83 please re-open if this code gets resurrected.


Refactoring

[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?
[ ] 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.

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

Addresses https://github.com/Homebrew/brew/pull/4210#discussion_r190975988 and https://github.com/Homebrew/brew/pull/4209#discussion_r190977979.

Can you always add a pull request body and links to previous relevant comments/issues? Thanks!

Thanks again @reitermarkus!


Add Blacklist

Fixes #476
Changes

add UI to manage blacklist by abstracting the existing Highlight Dialog implementation

Checklist

[x] My change builds
[x] I tested my change
[x] I use the "bttv_" prefix for all resources I propose
[x] When adding a string I also added it to the bttv.Res.strings Enum and res/values/strings.xml (in mod) and res/values/public.xml (in disass)
[x] If my change is significant enough, I added it to the CHANGELOG.md under master
[ ] I'll add myself and everyone else who contributed to this change to the contributors list using all-contributors
[x] I license my changes according to the MIT License.

@all-contributors please add @moonMan8 for Idea