Nothing listed under "Current Connections"

I'm using snippet mode, and I have two browsers connected. When I hit RELOAD ALL (for example), it works correctly, but there is nothing listed under "Current Connections". Am I missing something?
Browsersync [ 2.12.5 ]
Node [ 5.11.0 ]
Npm [ 3.8.6 ]

Win10

I am also having a similar issue. Reload All works, however, there are no entries listed under "Current Connections". I am using lite-server with a basic server config. Using:
Browsersync [ 2.12.8 ]
Node [ 6.0.0 ]
Npm [ 3.8.6 ]

Same as above, using:

win 7
browsersync 2.13.0
node 4.4.7
npm 3.5.3

I use it as a gulp plugin, reload all and injecting css etc. works fine.
But I have the same problem, not seeing the connected devices.
I use the following setup:
OS X 10.10.5
node 4.2.1
npm 2.14.7
browsersync 2.14.0

I updated now (via homebrew) to:
node 6.3.1
npm 3.10.3

Still not working.

I also have the same issue, all other functionality is working just fine, but current connections is empty

I also have the same issue, all other functionality is working just fine, but current connections is not working
Ubuntu 16.04
node v6.3.1
npm 3.10.3
browsersync 2.14.0

I experience the same thing. BrowserSync.io synchronizes the clients as expected but no connections shows up under Current Connections.
OSX 10.11.5
node v.5.4.0
npm 3.3.12
browsersync 2.2.0

Same here:
Windows 7 node 4.4.5 npm 2.1.5 browsersync 2.15.0

I still have this issue. There are no browsers listed in current connections.

Same problem
Ubuntu 14.04
npm 3.10.2
node 5.9.1
browsersync 2.2.0

@trompx you are using an old version that did not include the fix

@blowsie my bad, that was my grunt-browser-sync version which uses v2.14.0 of browsersync. I am stuck with grunt atm, so I will see if the maintainer of the repo is willing to upgrade the version.

I have a similar issue, using:

<EMAIL_ADDRESS>(latest)
<EMAIL_ADDRESS>(latest, but a year old at this point)
npm 3.10.10
Windows 10

Not sure what changed. It was working, now sadly it is not. The symptoms I have now are:

Does say say "Browsersync: connected" in the corner
Will no longer inject CSS changes
Nothing at all in the console log on the page
UI: Current connections area is empty
UI: History is empty

However, oddly enough, it will refresh the page whenever other files change (e.g. html). I'm a fairly new user and pretty baffled about what could cause it to suddenly stop working 😞

@patricknelson there was a fairly big rewrite of the client-side code for 2.24.0 - it seems like a bug may have surfaced - I'm looking into it

Ok thanks @shakyShane - it may be worth noting that I did attempt to install an older version of browser-sync, roughly 2.23.x, and it seemed to have the same effect as long as I was using grunt. I’m not at a computer at the moment so I can’t find the exact version, but it didn’t affect the  version reported by the UI web interface, which was still at the latest version of 2.24.1. Interestingly, everything did seem to work as expected when I launched a separate CLI and I recall it working normally (ran that one first, of course, so it could bind to :3000 before grunt’s version of browser-sync)
The best I could deduce from that was maybe it had to do with some combination of how it integrated with grunt-browser-sync but I have absolutely no clue at all. I resigned myself to defeat and decided that if I couldn’t figure it out tomorrow that I’d just resort to limping along with watch until it’s fixed or I can move our massive Gruntfile.js over to gulp!

Ok, I fixed my issue by reverting to an older version. I found the exact version of local browser-sync installed: 2.23.7.
I was confused initially but forgot that browser-sync was being installed under grunt-browser-sync (not at the root level duh, /facepalm). Everything is totally fixed for me after shrink wrapping it, or with yarn:
  "resolutions": {
    "grunt-browser-sync/**/browser-sync": "~2.23.0"
  }


Prevents SQL Error when either subtract_stock field is NULL

Moved over from https://github.com/tastyigniter/TastyIgniter/pull/950
This might only affect me?
Upgrading a development env kept failing due to $menuItem->subtract_stock and $optionValue->subtract_stock both being nullable, while is_tracked is not, throwing an error
SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'is_tracked' cannot be null (SQL: insert into `ti_stocks` (`location_id`, `stockable_id`, `stockable_type`, `quantity`, `is_tracked`, `created_at`, `updated_at`) values (2, 4, menu_option_values, 10, ?, 2022-03-08 14:07:37, 2022-03-08 14:07:37))

though it's possible that in the regular course of operation, these fields won't ever actually be null.

Thank you!


mantle: DigitalOcean image removal

Description
Somehow our kola tests ended up creating same-named images, and ore do delete-image --name= can't delete them if more than one exists.
Impact
Tests can't be run and we scatter the images.
Not sure if even the garbage collection is affected.

This quite happens during the release, I usually use delete both the images using doctl and start the new job.


regression Add regression testing and modify description text for s3load

Proposed changes
Add regression testing and modify description text for s3load

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall

related case seems failed

run buildall

run buildall

run buildall

run buildall

run buildall

run buildall

LGTM


Docs: Move NSM adapter from beta to stable

Current State:
The NSM adapter is currently listed as "beta".
Desired State:
The NSM adapter should now be a "stable" adapter.
See https://meshery.layer5.io/docs/installation/adapters

Contributor Resources

Meshery documentation site
Meshery documentation source
Instructions for contributing to documentation

Completed.


Update caddy-logs.yaml to include http_version

Adds HTTP version parsing to Caddy parser, resolving an unintended conflict with the http-dos-invalid-http-versions scenario.
I think I still need to add some tests for this, but wanted to get a PR going.

Hey 👋🏻
I just merged #943 which should stop false triggers, however, I still welcome your PR as we need parser to set the version.
I dont feel the need to have a specific test for the scenario, however, just re running the parsers will add the version to the test.

Sorry for not getting back to to you right away. Just to confirm, are there any other changes I need to make with this PR?

Sorry for not getting back to to you right away. Just to confirm, are there any other changes I need to make with this PR?

You need to regenerate the parser tests. I can do it for you in a little while.

Thanks @LaurenceJJones!


Dynamic Updating

So, does S.js automatically watches for changes on S objects inside DOM?
For example, I believe something like this should work:
var icon = 'fas fa-check'
var iconData = S.data(icon)

const loggedInLabel = S.root(() =>
  <label class={iconData()}/>
)
document.body.appendChild(loggedInLabel)
setTimeout(() => {icon = 'fas fa-cross'}, 1000)

But  even if I assign the value of iconData again after changing the value of icon the DOM doesn't update. What am I doing wrong?

Found out what I was doing wrong, should've updated iconData by calling: iconData(newValue) instead of a manual way.


Need mapping of pre-1.13 to post 1.13 iptables handling

File: engine/userguide/networking/default_network/container-communication.md, CC: @mstanleyjones
It seems like this document is out of sync with the recent changes to the iptables handling in version 1.13. It would be useful to have clear examples of different configuration option sets that yield a system with equivalent rules to the pre-1.13 behavior.

I'll take a shot at this one, claimed


Change Ska.Sun to ska_sun w/ back-compatibility

Description
This is a proof of concept to change the Ska.Sun package to natively be named ska_sun. The key here is adjusting three setup() inputs so that setuptools makes a complete duplicate of ska_sun within the Ska.Sun namespace for full back-compatibility. This seems to work reliably, the downside being duplication of files and data in the ska_sun distribution.
I played around with some ideas to make a lightweight virtual copy using dynamic import management / hacking, but I could not make this work.
Although not strictly necessary, the hope would be to change the repo name to ska_sun as well.
This strategy would then be applied to all the Ska.* and Chandra.* repos.
Interface impacts

Adds a new alias for importing packages. Changing the repo name should not impact users but will require corresponding changes in skare3.
Testing

Unit tests

[x] Mac

Independent check of unit tests by [REVIEWER NAME]

[ ] [PLATFORM]:

Functional tests

$ pip install --user .
$ cd $HOME
$ ipython
(ska3) ➜  ~ ipython
Python 3.8.12 (default, Oct 12 2021, 06:23:56)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.29.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import Ska.Sun

In [2]: Ska.Sun.__version__
Out[2]: '3.8.2.dev0+g1b92f8b.d20221211'

In [3]: Ska.Sun.test()
============================================================================ test session starts ============================================================================
platform darwin -- Python 3.8.12, pytest-6.2.5, py-1.10.0, pluggy-1.0.0
rootdir: /Users/aldcroft/.local/lib/python3.8/site-packages
plugins: remotedata-0.3.3, doctestplus-0.11.2, arraydiff-0.3, anyio-2.2.0, mock-3.6.1, filter-subpackage-0.1.1, openfiles-0.5.0, astropy-header-0.1.2, cov-3.0.0
collected 8 items

Ska/Sun/tests/test_sun.py ........                                                                                [100%]

============================================================================= 8 passed in 0.05s =============================================================================
Out[3]: False

In [4]: import ska_sun

In [5]: ska_sun.__version__
Out[5]: '3.8.2.dev0+g1b92f8b.d20221211'

In [6]: ska_sun.test()
============================================================================ test session starts ============================================================================
platform darwin -- Python 3.8.12, pytest-6.2.5, py-1.10.0, pluggy-1.0.0
rootdir: /Users/aldcroft/.local/lib/python3.8/site-packages
plugins: remotedata-0.3.3, doctestplus-0.11.2, arraydiff-0.3, anyio-2.2.0, mock-3.6.1, filter-subpackage-0.1.1, openfiles-0.5.0, astropy-header-0.1.2, cov-3.0.0
collected 8 items

ska_sun/tests/test_sun.py ........                                                                                [100%]

============================================================================= 8 passed in 0.04s =============================================================================
Out[6]: False

I don't know if this will be an issue for us, but I note that while Ska.Sun.version is defined, Ska.Sun.file is not.

I don't know if this will be an issue for us, but I note that while Ska.Sun.version is defined, Ska.Sun.file is not.

That doesn't match what I'm seeing. How did you test that? In particular, /Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/Ska/Sun/__init__.py does get installed.
(ska3-dev) ➜  Ska.Sun git:(de-namespace) python setup.py install --single-version-externally-managed --record=record.txt
running install
running build
running build_py
copying ska_sun/sun.py -> build/lib/ska_sun
copying ska_sun/__init__.py -> build/lib/ska_sun
copying ska_sun/sun.py -> build/lib/Ska/Sun
copying ska_sun/__init__.py -> build/lib/Ska/Sun
running install_lib
copying build/lib/Ska/Sun/sun.py -> /Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/Ska/Sun
copying build/lib/Ska/Sun/__init__.py -> /Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/Ska/Sun
creating /Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/ska_sun
copying build/lib/ska_sun/sun.py -> /Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/ska_sun
creating /Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/ska_sun/tests
copying build/lib/ska_sun/tests/__init__.py -> /Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/ska_sun/tests
copying build/lib/ska_sun/tests/test_sun.py -> /Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/ska_sun/tests
copying build/lib/ska_sun/__init__.py -> /Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/ska_sun
creating /Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/ska_sun/data
copying build/lib/ska_sun/data/pitch_roll.fits.gz -> /Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/ska_sun/data
byte-compiling /Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/ska_sun/sun.py to sun.cpython-38.pyc
byte-compiling /Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/ska_sun/tests/__init__.py to __init__.cpython-38.pyc
byte-compiling /Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/ska_sun/tests/test_sun.py to test_sun.cpython-38.pyc
byte-compiling /Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/ska_sun/__init__.py to __init__.cpython-38.pyc
running install_egg_info
running egg_info
writing ska_sun.egg-info/PKG-INFO
writing dependency_links to ska_sun.egg-info/dependency_links.txt
writing top-level names to ska_sun.egg-info/top_level.txt
adding license file 'LICENSE.rst'
writing manifest file 'ska_sun.egg-info/SOURCES.txt'
Copying ska_sun.egg-info to /Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/ska_sun-3.8.2.dev2+g05fe28e-py3.8.egg-info
running install_scripts
writing list of installed files to 'record.txt'
(ska3-dev) ➜  Ska.Sun git:(de-namespace) cat record.txt
/Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/ska_sun/sun.py
/Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/ska_sun/__init__.py
/Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/ska_sun/tests/__init__.py
/Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/ska_sun/tests/test_sun.py
/Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/Ska/Sun/sun.py
/Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/Ska/Sun/__init__.py
/Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/Ska/Sun/tests/__init__.py
/Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/Ska/Sun/tests/test_sun.py
/Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/ska_sun/data/pitch_roll.fits.gz
/Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/Ska/Sun/data/pitch_roll.fits.gz
/Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/ska_sun/__pycache__/sun.cpython-38.pyc
/Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/ska_sun/__pycache__/__init__.cpython-38.pyc
/Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/ska_sun/tests/__pycache__/__init__.cpython-38.pyc
/Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/ska_sun/tests/__pycache__/test_sun.cpython-38.pyc
/Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/Ska/Sun/__pycache__/sun.cpython-38.pyc
/Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/Ska/Sun/__pycache__/__init__.cpython-38.pyc
/Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/Ska/Sun/tests/__pycache__/__init__.cpython-38.pyc
/Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/Ska/Sun/tests/__pycache__/test_sun.cpython-38.pyc
/Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/ska_sun-3.8.2.dev2+g05fe28e-py3.8.egg-info/PKG-INFO
/Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/ska_sun-3.8.2.dev2+g05fe28e-py3.8.egg-info/not-zip-safe
/Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/ska_sun-3.8.2.dev2+g05fe28e-py3.8.egg-info/SOURCES.txt
/Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/ska_sun-3.8.2.dev2+g05fe28e-py3.8.egg-info/top_level.txt
/Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/ska_sun-3.8.2.dev2+g05fe28e-py3.8.egg-info/dependency_links.txt
(ska3-dev) ➜  Ska.Sun git:(de-namespace) cd
(ska3-dev) ➜  ~ ipython
Python 3.8.12 (default, Oct 12 2021, 06:23:56)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.29.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import ska_sun

In [2]: import Ska.Sun

In [3]: Ska.Sun.__file__
Out[3]: '/Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/Ska/Sun/__init__.py'

In [4]: ska_sun.__file__
Out[4]: '/Users/aldcroft/miniconda3/envs/ska3-dev/lib/python3.8/site-packages/ska_sun/__init__.py'

I'd done this
ska3-jeanconn-fido> pip install --user .
Processing /proj/sot/ska/jeanproj/git/Ska.Sun
  DEPRECATION: A future pip version will change local packages to be built in-place without first copying to a temporary directory. We recommend you use --use-feature=in-tree-build to test your packages with this new behavior before it becomes the default.
   pip 21.3 will remove support for this functionality. You can find discussion regarding this at https://github.com/pypa/pip/issues/7555.
Building wheels for collected packages: ska-sun
  Building wheel for ska-sun (setup.py) ... done
  Created wheel for ska-sun: filename=ska_sun-3.8.2.dev2+g05fe28e.d20221217-py3-none-any.whl size=120988 sha256=7f89e6bf866e957293799366ae535e9642626c7071000844bd106ea5b6b57ecb
  Stored in directory: /tmp/pip-ephem-wheel-cache-u_iv0n06/wheels/f7/19/98/a310debe4f30dcf198399a33fc13dd2e63ae6b388bf04355d4
Successfully built ska-sun
Installing collected packages: ska-sun
Successfully installed ska-sun-3.8.2.dev2+g05fe28e.d20221217
ska3-jeanconn-fido> cd
ska3-jeanconn-fido> ipython
Python 3.8.12 (default, Oct 12 2021, 13:49:34)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.29.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import Ska.Sun

In [2]: import Ska.Sun.__file__
---------------------------------------------------------------------------
ModuleNotFoundError                       Traceback (most recent call last)
<ipython-input-2-5775e1be7a26> in <module>
----> 1 import Ska.Sun.__file__

ModuleNotFoundError: No module named 'Ska.Sun.__file__'

Works now so I'm not sure what happened.  I assumed it generalized but I guess I was mistaken.

pip install is a hard fail with namespace packages in my experience. Just don't do that.

I'd just copied from the functional tests above.

Oops. The hard fail is that pip removes every other package in that namespace. I guess for a --user install that normally doesn't matter, except maybe you discovered some other problem.

Yeah, I didn't discover much just because I did the same thing (as far as I can tell) and now have a different result.  So I'll assume something weird with "pip" in this case.

I tried both with our standard:
python setup.py install --single-version-externally-managed --record=record.txt

and a typical way I like to test things:
pip install -e .

The first one is ok. In the second one the namespace package is not installed. Not an issue, but good to know.
I went over the skare3 building, and I think the only thing we will have to do is to add testr and ska_helpers to the recipes. While checking that, I noticed that many packages have the following in setup.py:
try:
    from testr.setup_helper import cmdclass
except ImportError:
    cmdclass = {}

but not a single recipe includes testr as a build dependency, so this is never used in the actual builds.

But we also don't run the tests when we build, so does it matter?

But we also don't run the tests when we build, so does it matter?

This PR adds this line:
from testr.setup_helper import cmdclass

and this will fail in the conda build unless testr is a build dependency. It could add it like the other packages (what I pasted above) and then testr will not be required as a build dependency. In either case, ska_helpers will need to be added as a build dependency in all recipes.

I wasn't sure about making that change to always require testr. I mostly got fed up with it looking ugly. :smile:. Is it better if I revert that or bite the bullet and change the build recipes?
Presumably for ska_helpers we only need to change the build recipes for namespace packages that use it?

We can do whatever you prefer. I already changed all the recipes for namespace packages (https://github.com/sot/skare3/pull/977). I don't mind either way

FYI I haven't gotten to it yet but we agreed to leave the package name and repo name as Ska.Sun to minimize other disruptions. But I'm still fully open to ideas on this.

@javierggt @jeanconn - I updated the description to reflect testing using the correct install method and with the latest commit. I think this is ready for final review.


Bunch of stuff, like a lot updated compared to latest version in the master branch

Add new features, API now using and supporting PostgreSQL!
Too lazy to write stuff here... It's a lot of stuff that should work, who knows.

I belive I pushed stuff alrd that included this pr, so I'll close it now


Updated update.js for fixing old dependencies remaining in the local npm cache

Added a warning msg for fixing old dependencies remaining in the local npm cache
Description
As a short term solution added a warning msg for fixing old dependencies remaining in the local npm cache
Related Issue
https://github.com/adobe/aio-cli/issues/269
Motivation and Context
See above
How Has This Been Tested?

cloned aio-cli repo
ran node ./bin/run update

Screenshots (if appropriate):

Types of changes

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

Checklist:

[x] I have signed the Adobe Open Source CLA.
[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[x] All new and existing tests passed.

@kelvinxzf linter failure: formatting issues related to your space changes. see https://github.com/adobe/aio-cli/runs/2661741352?check_suite_focus=true

@kelvinxzf linter failure: formatting issues related to your space changes. see https://github.com/adobe/aio-cli/runs/2661741352?check_suite_focus=true

this should be fixed now.


add toMatchSpecificSnapshot

Clear and concise description of the problem
We use storybook in our vue project, and we used jest and storyshots (automated snapshot testing)
We are migrating to vitest for multiple reasons, and we are trying to replace storyshots which works only with jest (https://github.com/storybookjs/storybook/issues/17578)
After playing with vitest, we are able to generate on test for each storybook case, and snapshot the associated html.
Our only issue is that all our storybook are run by the same test file, and the toMatchSnapshot generate a lot of snapshots in the same file.
We would like to create a snapshot file by storybook file, and to do that we would need the jest equivalent toMatchSpecificSnapshot
Suggested solution
I don't really know how to implement it, I know the signature should be something like
toMatchSpecificSnapshot<T>(pathToSnapshotFile: string,shape?: Partial<T> | string, message?: string)
Alternative
We wanted to play with inlinesnapshot and programmatically write/retrieve the file, but we lose all the automatic update from vitest
Additional context
No response
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

Can't you use resolveSnapshotPath?

That could be a good idea, but I think we don't have enough context to know which storybook is getting tested, since the test we wrote is a meta test, that load all the storybooks, render each story in a test, snapshot the rendered html
In almost pseudocode, our test does this:
describe('Storybook Smoke Test', async () => {
  // We load all the storybook files
  const modules = await Promise.all(
    Object.values(import.meta.glob<StoryFile>('../**/*.stories.ts')).map(fn =>
      fn()
    )
  )

  describe.each(modules)('%s', (module) => {
   // for each module, we create a test for each story
    test.each(Object.values(composeStories(module)))('%s', story) => {
      const mounted = render(story())
      expect(mounted.html()).toMatchSnapshot()
    })
  })
})

Am I missing something in resolveSnapshotPath that could tell us which test file/describe is being executed?

Am I missing something in resolveSnapshotPath that could tell us which test file/describe is being executed?

No, currently it doesn't know. There was a discussion to add context to it, which has this information in https://github.com/vitest-dev/vitest/pull/1620 but it is not implemented and will require some refactoring and will be a breaking change (instead of function, users will need to provide a string path, like with setupFiles, which is fine, I think)

Thanks for your answer!
If I wanted to try and implement it, I should look at similar stuff here right? #43

If I wanted to try and implement it, I should look at similar stuff here right? #43

No, I don't think it is related. If you want to implement it in Vitest, I would look into #1620. The only change is needed there is initiating resolveSnapshotPath inside a worker thread instead of using RPC.

The newly added File Snapshots feature seems to resolve this 🙌


Which page will the metadata-origins menu option jump to

In the latest version, A new menu option has been added to the page, which is not yet available. I am curious what function entry is this?

Hey, looks like it's supposed to be a Q&A page. Will have an option to remove this if no such Q&A exists

The new React application does not have this link.
@shirshanka Let's close this ticket?


Typo in i18n/en.toml

In i18n/en.toml the plural of photo is kept as photo, instead of photos.

Thanks!


Can version dependency be used ~ or ^

This repo seems abandoned.
I have opened a PR for similar request in the @antony-k1208 fork and i'm waiting for the merge: antony-k1208/vue3-xml-viewer/pull/1

Awesome, thanks @g-scalvini! Accepted the PR and released a new version on npm.


temporarily disable pytest-docker entirely on py<3.10

pytest-docker deps cannot be pip installed on 3.10+. Issue is with pyyaml<6/Cython install (which comes from pytest-docker): https://github.com/yaml/pyyaml/issues/724
Collecting PyYAML<6,>=3.10 (from docker-compose<2.0,>=1.27.3->pytest-docker==0.12.0->scmrepo==1.0.5.dev4+gd3f663a)

Codecov Report
Patch coverage has no change and project coverage change: -1.05 :warning:

Comparison is base (34280a5) 81.26% compared to head (01b1412) 80.22%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #254      +/-   ##
==========================================
- Coverage   81.26%   80.22%   -1.05%
==========================================
  Files          27       27
  Lines        4020     4020
  Branches      709      709
==========================================
- Hits         3267     3225      -42
- Misses        630      660      +30
- Partials      123      135      +12

see 7 files with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Bug when calling builtins.next on builtins.map

When calling builtins.next on a builtins.map object, we get unexpected behavior.
With the current implementation of map in tag v0.2.0-2-g0838055, we have:
    def f(_a):
        return _a

    m = map(f, [1, 2, 3])
    print(next(m))      # 1
    print(next(m))      # 1
    print(next(m))      # 1

While in Python, the expected behavior is the following:
>>> def f(a):
...     return a
...
>>> m = map(f, [1, 2, 3])
>>> next(m)
1
>>> next(m)
2
>>> next(m)
3

The issue seems to be due to two factors:

next will call iterable.Iterate() upon each call.
map will create a new slice of iterators upon call to Iterate.

Since 1. seems like the correct implementation for next, i.e. we shouldn't be storing states of iterators globally so the current implementation seems correct, the issue probably has to do with map.
One solution is to extract all iterators for map in func map_ and store them as a reference copy to the map object.
Any thoughts :)?

Also, I have an implementation for islice but since it is subject to the same issues as described above for map, I will hold off until we find a solution to this issue before making a PR.

I think map object should store iterator values, not iterable.

One solution is to extract all iterators for map in func map_ and store them as a reference copy to the map object.

I think this is the only solution.
Thank you for finding this bug!


Add command to list products and variants

This Pull Request introduces the following changes:

New Command that can query the Lemon Squeezy API for products and variants;
Command can list all products and their variants or an argument can also be passed to query the variants of a specific product;

Note: The products query can only show 100 products since I am doing only 1 request to the endpoint using a page size of 100 (maximum), can be changed to do a recursive request to show 100, I just was thinking if It makes sense to show so many products or a message with a link to the Lemon Squeezy Dashboard.
I think at some point we should introduce a class to query products and variants as it would be nice to make that affordance available for users to query the products and variants from Lemon Squeezy, maybe even import them to a table somehow idk...
There is an decision that I made after reading the Lemon Squeezy API Docs, on the product variants I only render the pending variants if the count of variants in a products is 1.
From LemonSqueezy API Docs (https://docs.lemonsqueezy.com/api/variants):

Note: If a variant has a pending status and its product has no other variants, it is considered the “default” variant and is not shown as a separate option at checkout.

Closes #12

thank you @DinisEsteves for the help

Sorry it took me this long to review this. Thanks a bunch for this one!


⚠ ClamAV has degraded performance

In 942466b, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 169 ms

Resolved: ClamAV performance has improved in 1cc324b.


docker-compose up

network tool-server-network was found but has incorrect label com.docker.compose.network set to "tool-server-network"

Please delete the old tool-server-network bridge first.


Are open pipes cleared and correctly closed when quiting juci?

I quit juci during in app compilation on windows. I found the cplusplus process working some time after shutdown "~1 min".

pipes are, but libclang may continue to work. There is no way to force libclang to stop as far as I know.

Or, when I think about it, Windows processes are abit strange, there might be a pipe or something I do not close in terminal_win.cc, but most likely its a Windows issue.
Did you run alot of run commands? Did they all return?

When I think some more about it, there is an issue on Windows when killing processes, this is done when juci quits, but Windows may or may not do this. Its a Windows issue, not a jucipp one.

How did you quit juci btw? Destroying it in terminal might have a different outcome than clicking control-q or clicking on the exit button on the window.

I quit using the menu, Juci++/quit.

Tried killing compilation on Windows, and that didn't work. It's a Windows issue.

It did get killed after a while though.


Configure replication slots on PG 9.5 and up

Using a replication slot ensures the primary will not delete data that
a secondary still needs, preventing secondaries from going out of sync,
and ensuring that queries can complete on secondaries without recovery
conflicts.

cc @fancyremarker @UserNotFound - for now, I'm just opening this to run tests on it. there's at least 3 things we need to consider before moving forward with this:

Leaving replication slots behind when a replica is deleted will cause problems (e.g. running out of disk eventually)
If a --initialize-from operation fails halfway (that is less likely with this PR though!), it'll leave a replication slot behind (causing the same issue).
We probably want to make sure that restoring from a backup does not reuse the replication slot (or replication in general). I've included this in this PR (see: --initialize-backup-.

All right, so one main blocker here is that max_replication_slots defaults to 0 on all versions before PG 10 (where it's 10), and this can only be configured at startup. So, we probably need to make this configurable / optional.


Customize Favorites

Is your feature request related to a problem? Please describe.
I would like to remove a few of the default Favorites.
Describe the solution you'd like
This could be solved through right-clicking on one of the default items in the navigation bar and choosing "unpin item".
Describe alternatives you've considered
Alternatively this could be solved through right-clicking on one of the big default Buttons with the items inside when first opening the app. and also selecting "unpin item".
Additional context
Probably showing the option to open the item in a new window (or tab) could also be useful, when right-clicking on one of the Favorites.

This is something we should definitely do and have plans for in the future.

This has been implemented in v0.10 and will be rolling out to all users in the coming days.


DIE Character Sheet NPC Stat Bugfix

Raised NPC Stat Limits and updated Image URLs

Submission Checklist
Required

[X] The pull request title clearly contains the name of the sheet I am editing.
[X] The pull request title clearly states the type of change I am submitting (New Sheet/New Feature/Bugfix/etc.).
[X] The pull request makes changes to files in only one sub-folder.
[X] The pull request does not contain changes to any json files in the translations folder (translation.json is permitted)

New Sheet Details

The name of this game is: <   >  (i.e. Dungeons & Dragons 5th Edition, The Dresden Files RPG)

The publisher of this game is: <   > (i.e. Wizards of the Coast, Evil Hat)

The name of this game system/family is: <   > (i.e. Dungeons & Dragons, FATE)

[X] I have followed the Character Sheets Standards when building this sheet.

[ ] This sheet has been made on behalf of, or by, the game's publisher.
[ ] This game is not a traditionally published game, but a copy of the game rules can be purchased/downloaded/found at: <   >
[ ] This sheet is for an unofficial fan game, modification to an existing game, or a homebrew system.

Changes / Description

Character Sheet Info Roll20 Internal Use only.

Updated the NPC stat limits from 4 to 20, and updated the Image URLs to the Roll20 Repository


Documentation: Matrix class (#157)

Do the checklist before submitting the PR:

[Y] Have you read the guidelines mentioned in CONTRIBUTING.md?
[Y] Have you squashed your commits?

Q: What version of Node.js you've used in the project? (e.g. Node v10.11.0)
A: v8.11.4
Q: Mention the Issue Number! (e.g. Fixed #8)
A: #157

Give additional information regarding the PR below:

Codecov Report

Merging #174 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master   #174   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files          78     78
  Lines        1378   1378
=====================================
  Hits         1378   1378

Continue to review full report at Codecov.

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


Added nullable modifier to prevent crashes in track function from calling from Swift (closes #713)

Addresses issue https://github.com/snowplow/snowplow-objc-tracker/issues/713 By making the UUID returned by the track function nullable, which was previously assumed to be non-null by NS_ASSUME_NONNULL. This will prevent crashes when calling track after event tracking has been paused.

Thanks for your pull request. Is this your first contribution to a Snowplow open source project? Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).
:memo: Please visit https://docs.snowplowanalytics.com/docs/contributing/contributor-license-agreement/ to learn more and sign.
Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

Thanks for your pull request. Is this your first contribution to a Snowplow open source project? Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).
📝 Please visit https://docs.snowplowanalytics.com/docs/contributing/contributor-license-agreement/ to learn more and sign.
Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

Signed

Confirmed! @mylifeasdog has signed the Contributor License Agreement. Thanks so much.


jaeger-all-in-one pod invalid memory address panic during test suite

We're attempting to integrate the jaeger all-in-one pod in our development environments and are experiencing shutdowns during our test suite, with the jaeger-all-in-one pod reporting the following the following during the test:
all-in-one logs:
{"level":"info","ts":1530582648.1951566,"caller":"healthcheck/handler.go:99","msg":"Health Check server started","http-port":14269,"status":"unavailable"}
{"level":"info","ts":1530582648.1964855,"caller":"tchannel/builder.go:89","msg":"Enabling service discovery","service":"jaeger-collector"}
{"level":"info","ts":1530582648.196542,"caller":"peerlistmgr/peer_list_mgr.go:111","msg":"Registering active peer","peer":"<IP_ADDRESS>:14267"}
{"level":"info","ts":1530582648.1970081,"caller":"standalone/main.go:179","msg":"Starting agent"}
{"level":"info","ts":1530582648.1976883,"caller":"standalone/main.go:219","msg":"Starting jaeger-collector TChannel server","port":14267}
{"level":"info","ts":1530582648.1977384,"caller":"standalone/main.go:229","msg":"Starting jaeger-collector HTTP server","http-port":14268}
{"level":"info","ts":1530582648.214731,"caller":"standalone/main.go:290","msg":"Registering metrics handler with jaeger-query HTTP server","route":"/metrics"}
{"level":"info","ts":1530582648.2148683,"caller":"standalone/main.go:296","msg":"Starting jaeger-query HTTP server","port":16686}
{"level":"info","ts":1530582648.2148962,"caller":"healthcheck/handler.go:133","msg":"Health Check state change","status":"ready"}
{"level":"info","ts":1530582649.1985323,"caller":"peerlistmgr/peer_list_mgr.go:157","msg":"Not enough connected peers","connected":0,"required":1}
{"level":"info","ts":1530582649.198617,"caller":"peerlistmgr/peer_list_mgr.go:166","msg":"Trying to connect to peer","host:port":"<IP_ADDRESS>:14267"}
{"level":"info","ts":1530582649.199323,"caller":"peerlistmgr/peer_list_mgr.go:176","msg":"Connected to peer","host:port":"[::]:14267"}
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x8bd634]

goroutine 122 [running]:
github.com/jaegertracing/jaeger/cmd/agent/app/reporter/tchannel.(*Reporter).EmitBatch(0xc420200180, 0x0, 0x0, 0x0)
	/home/travis/gopath/src/github.com/jaegertracing/jaeger/cmd/agent/app/reporter/tchannel/reporter.go:119 +0x84
github.com/jaegertracing/jaeger/thrift-gen/jaeger.(*agentProcessorEmitBatch).Process(0xc420326170, 0xc400000000, 0xe863c0, 0xc4201b17c0, 0xe863c0, 0xc4201b17c0, 0xc42065ff28, 0xc420432f80, 0xc4203261f0)
	/home/travis/gopath/src/github.com/jaegertracing/jaeger/thrift-gen/jaeger/agent.go:137 +0xc9
github.com/jaegertracing/jaeger/thrift-gen/jaeger.(*AgentProcessor).Process(0xc4202a2040, 0xe863c0, 0xc4201b17c0, 0xe863c0, 0xc4201b17c0, 0x0, 0x0, 0x0)
	/home/travis/gopath/src/github.com/jaegertracing/jaeger/thrift-gen/jaeger/agent.go:111 +0x2fd
github.com/jaegertracing/jaeger/cmd/agent/app/processors.(*ThriftProcessor).processBuffer(0xc4200812c0)
	/home/travis/gopath/src/github.com/jaegertracing/jaeger/cmd/agent/app/processors/thrift_processor.go:110 +0x179
created by github.com/jaegertracing/jaeger/cmd/agent/app/processors.(*ThriftProcessor).Serve
	/home/travis/gopath/src/github.com/jaegertracing/jaeger/cmd/agent/app/processors/thrift_processor.go:82 +0x62

The pod is implemented via helm using a slightly modified version of the all-in-one chart template found at https://github.com/jaegertracing/jaeger-kubernetes/blob/master/all-in-one/jaeger-all-in-one-template.yml
Following are our deployment and service configurations.
all-in-one deployment:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "1"
  creationTimestamp: 2018-07-02T21:00:27Z
  generation: 1
  labels:
    app: jaeger-all-in-one
    chart: jaeger-all-in-one-0.1.00
    component: all-in-one-deployment
    heritage: Tiller
    jaeger-infra: jaeger-all-in-one
    release: tjb-jgr-allinone-stability-v2-1
  name: tjb-jgr-allinone-stability-v2-1-jaeger-all-in-one
  namespace: default
  resourceVersion: "73847"
  selfLink: /apis/extensions/v1beta1/namespaces/default/deployments/tjb-jgr-allinone-stability-v2-1-jaeger-all-in-one
  uid: f2662b0a-7e3a-11e8-ac4d-42010a8e0fe3
spec:
  replicas: 1
  selector:
    matchLabels:
      app: jaeger-all-in-one
      chart: jaeger-all-in-one-0.1.00
      component: all-in-one-deployment
      jaeger-infra: jaeger-all-in-one
      release: tjb-jgr-allinone-stability-v2-1
  strategy:
    type: Recreate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: jaeger-all-in-one
        chart: jaeger-all-in-one-0.1.00
        component: all-in-one-deployment
        jaeger-infra: jaeger-all-in-one
        release: tjb-jgr-allinone-stability-v2-1
    spec:
      containers:
      - env:
        - name: COLLECTOR_ZIPKIN_HTTP_PORT
        image: jaegertracing/all-in-one:1.5.0
        imagePullPolicy: IfNotPresent
        name: tjb-jgr-allinone-stability-v2-1-jaeger-all-in-one
        ports:
        - containerPort: 5775
          protocol: UDP
        - containerPort: 6831
          protocol: UDP
        - containerPort: 6832
          protocol: UDP
        - containerPort: 5778
          protocol: TCP
        - containerPort: 16686
          protocol: TCP
        - containerPort: 9411
          protocol: TCP
        readinessProbe:
          failureThreshold: 3
          httpGet:
            path: /
            port: 16686
            scheme: HTTP
          initialDelaySeconds: 5
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 1
        resources:
          limits:
            cpu: 750m
            memory: 1Gi
          requests:
            cpu: 250m
            memory: 1Gi
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
status:
  availableReplicas: 1
  conditions:
  - lastTransitionTime: 2018-07-03T11:53:59Z
    lastUpdateTime: 2018-07-03T11:53:59Z
    message: Deployment has minimum availability.
    reason: MinimumReplicasAvailable
    status: "True"
    type: Available
  observedGeneration: 1
  readyReplicas: 1
  replicas: 1
  updatedReplicas: 1

all-in-one services:
---
apiVersion: v1
kind: Service
metadata:
  creationTimestamp: 2018-07-02T21:00:27Z
  labels:
    app: jaeger-all-in-one
    chart: jaeger-all-in-one-0.1.00
    component: all-in-one-agent
    heritage: Tiller
    jaeger-infra: jaeger-all-in-one
    release: tjb-jgr-allinone-stability-v2-1
  name: tjb-jgr-allinone-stability-v2-1-jaeger-all-in-one-agent
  namespace: default
  resourceVersion: "834"
  selfLink: /api/v1/namespaces/default/services/tjb-jgr-allinone-stability-v2-1-jaeger-all-in-one-agent
  uid: f2815108-7e3a-11e8-ac4d-42010a8e0fe3
spec:
  clusterIP: None
  ports:
  - name: agent-zipkin-thrift
    port: 5775
    protocol: UDP
    targetPort: 5775
  - name: agent-compact
    port: 6831
    protocol: UDP
    targetPort: 6831
  - name: agent-binary
    port: 6832
    protocol: UDP
    targetPort: 6832
  - name: agent-configs
    port: 5778
    protocol: TCP
    targetPort: 5778
  selector:
    app: jaeger-all-in-one
    component: all-in-one-deployment
    jaeger-infra: jaeger-all-in-one
    release: tjb-jgr-allinone-stability-v2-1
  sessionAffinity: None
  type: ClusterIP
status:
  loadBalancer: {}
---
apiVersion: v1
kind: Service
metadata:
  creationTimestamp: 2018-07-02T21:00:27Z
  labels:
    app: jaeger-all-in-one
    chart: jaeger-all-in-one-0.1.00
    component: all-in-one-collector
    heritage: Tiller
    jaeger-infra: jaeger-all-in-one
    release: tjb-jgr-allinone-stability-v2-1
  name: tjb-jgr-allinone-stability-v2-1-jaeger-all-in-one-collector
  namespace: default
  resourceVersion: "832"
  selfLink: /api/v1/namespaces/default/services/tjb-jgr-allinone-stability-v2-1-jaeger-all-in-one-collector
  uid: f27c80fd-7e3a-11e8-ac4d-42010a8e0fe3
spec:
  clusterIP: <IP_ADDRESS>
  ports:
  - name: jaeger-collector-tchannel
    port: 14267
    protocol: TCP
    targetPort: 14267
  - name: jaeger-collector-http
    port: 14268
    protocol: TCP
    targetPort: 14268
  - name: jaeger-collector-zipkin
    port: 9411
    protocol: TCP
    targetPort: 9411
  selector:
    app: jaeger-all-in-one
    component: all-in-one-deployment
    jaeger-infra: jaeger-all-in-one
    release: tjb-jgr-allinone-stability-v2-1
  sessionAffinity: None
  type: ClusterIP
status:
  loadBalancer: {}
---
apiVersion: v1
kind: Service
metadata:
  creationTimestamp: 2018-07-02T21:00:27Z
  labels:
    app: jaeger-all-in-one
    chart: jaeger-all-in-one-0.1.00
    component: all-in-one-query
    heritage: Tiller
    jaeger-infra: jaeger-all-in-one
    release: tjb-jgr-allinone-stability-v2-1
  name: tjb-jgr-allinone-stability-v2-1-jaeger-all-in-one-query
  namespace: default
  resourceVersion: "827"
  selfLink: /api/v1/namespaces/default/services/tjb-jgr-allinone-stability-v2-1-jaeger-all-in-one-query
  uid: f270e4b3-7e3a-11e8-ac4d-42010a8e0fe3
spec:
  clusterIP: <IP_ADDRESS>
  ports:
  - name: query-http
    port: 80
    protocol: TCP
    targetPort: 16686
  selector:
    app: jaeger-all-in-one
    component: all-in-one-deployment
    jaeger-infra: jaeger-all-in-one
    release: tjb-jgr-allinone-stability-v2-1
  sessionAffinity: None
  type: ClusterIP
status:
  loadBalancer: {}
---
apiVersion: v1
kind: Service
metadata:
  creationTimestamp: 2018-07-02T21:00:27Z
  labels:
    app: jaeger-all-in-one
    chart: jaeger-all-in-one-0.1.00
    component: all-in-one-zipkin
    heritage: Tiller
    jaeger-infra: jaeger-all-in-one
    release: tjb-jgr-allinone-stability-v2-1
  name: tjb-jgr-allinone-stability-v2-1-jaeger-all-in-one-zipkin
  namespace: default
  resourceVersion: "846"
  selfLink: /api/v1/namespaces/default/services/tjb-jgr-allinone-stability-v2-1-jaeger-all-in-one-zipkin
  uid: f2927bd1-7e3a-11e8-ac4d-42010a8e0fe3
spec:
  clusterIP: None
  ports:
  - name: jaeger-collector-zipkin
    port: 9411
    protocol: TCP
    targetPort: 9411
  selector:
    app: jaeger-all-in-one
    component: all-in-one-deployment
    jaeger-infra: jaeger-all-in-one
    release: tjb-jgr-allinone-stability-v2-1
  sessionAffinity: None
  type: ClusterIP
status:
  loadBalancer: {}

Could you just confirm what you see when you run the version command for the backing container image? Like:
$ kubectl exec -it POD_NAME -- /go/bin/standalone-linux version
{"gitCommit":"c8d514c4b45e32fb037497ae2ef4042b3005f902","GitVersion":"v1.5.0","BuildDate":"2018-06-30T22:11:21Z"}

POD_NAME look like this to me when I run kubectl create -f ....../jaeger-all-in-one-template.yml: jaeger-deployment-8648cb84d5-cg82n

@jpkrohling standalone-linux version on my pod reports the following:
─ k exec -it tjb-jgr-allinone-stability-v2-1-jaeger-all-in-one-6786d849hr2ml -- /go/bin/standalone-linux version
{"gitCommit":"ab77ac7efdabbcdce9e53628681ec45421f05e58","GitVersion":"v1.5.0","BuildDate":"2018-05-28T15:24:54Z"}

Thanks, I'll try to reproduce it on my side. Is the test failure happening consistently, or is it intermittent? If it's consistent, are you able to share a code that would trigger this condition?

Unable to share code, the failure occurs consistently during our pytest suite of our smart contract modules although at varying points in the tests. I've had it get nearly through the entire suite of tests before failing, sometimes in the first 50 or so out of a total of 200+.
We have a total of four modules reporting into the all-in-one pod for tracing across python, go, and haskell modules if thats helpful at all.

That's helpful, thanks! It sounds like a concurrency issue to me, which will make it a bit harder to reproduce. In any case, we'll need your help again during the validation of the fix!

Closing due to this being stale.


chore: zeebe-cloud-events-router to 0.0.3

chore: Promote zeebe-cloud-events-router to version 0.0.3

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers:
If they are not already assigned, you can assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


SW-4761 Create RedirectsRouter that contains all the '$path/' -> '$path' redirects

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

Current dependencies on/for this PR:

main

PR #2050

PR #2061

PR #2062

PR #2063

PR #2064

PR #2065

PR #2066

PR #2067

Merge activity

Jan 25, 3:38 PM: @sgrimm started a stack merge that includes this pull request via Graphite.


updated requirements, warnings and errors

user may not use -force when installing modules
user may not use MSA in Azure (this could be the first user that created the Azure tenant, but must use an Entra AD account.

@alkohli
Can you review the proposed changes?
Important: When the changes are ready for publication, adding a #sign-off comment is the best way to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

@Karl-WE Thanks so much for your valuable contribution. Thomas and I carefully went through the suggestions. We feel that if
a customer follows the steps we currently have there, they should be successfully able to register their servers with Arc. While your suggestions are insightful, we can't document the negative scenarios here.
@troettinger - Karl, in case you want to reach out to Thomas for further discussion. For now, we will be closing this PR. Thanks again!

#please-close


Cannot delete new photos added to an existing observation

Describe the bug
When you try to take new photos and add them to an existing observation, you can't delete them from the MediaViewer
To Reproduce
Steps to reproduce the behavior:

Make a new observation without evidence and save it without uploading
Edit the observation
Tap on the "+" button to add evidence and choose the camera option
In the StandardCamera, take a new photo
Tap on the preview of that photo in the top row to enter the MediaViewer
In the MediaViewer, tap the trash icon in the lower right; nothing happens

Expected behavior
When you tap the trash icon, the photo should be deleted, the MediaViewer should close, and you should be back in the StandardCamera.
Context (please complete the following information):

Device: iPhone SE (3rd gen)
OS: iOS 17.2.1
App version: 0.22.0 (71)

Angie ran into a bunch of possibly related bugs while working on this, FYI.


Improve keyring for EVM

Overview
The current implementation for unlocking and using an EVM account for sign data or transactions:

Unlock the keyring (with password)
Export account => convert to the private key
Use the private key for sign data or transactions
This implementation way requires the password every time we need the private key. We need to add more features to the ui-keyring to support EVM interaction in a convenient way.
Get private key when the keyring is unlocked
Direct export without export full account data

Solution

Create new package for for modify ui-keyring packages
Get the private key when the keyring is unlocked
Replace the current ui-keyring with modified keyring

Solution is included in new design of package SubWallet-Base


Uf docs errai4

@paulovmr @karreiro as you guys  were the last one's that made the tutorial, could you please review it?
I've removed the gwt widgets from all screens.
(perspectives should be addressed after this ticket https://issues.jboss.org/browse/UF-358)

And this -> https://github.com/uberfire/uberfire-tutorial/pull/17

+1

@ederign Great improvement! I've commented only some minor issues, I think that's all.

@paulovmr  @karreiro thanks for the review.
Recent changes are here https://gist.github.com/ederign/3a6fc3bc5c662abddd9c173f68b72a97

@ederign Great!
+1 to merge (when the build passes).


Replace react-router-dom v6.x.x peer dependency for ^5.3.4

Not sure why, but ^6.22.0 of react-router-dom is set as a peer dependency for this plugin while strapi v4 specifies ^5.3.4

This is now resolved


Rewrite history to follow upstream

We're making a 1:1 fork of the driver to introduce a subtle change.
In this PR there isn't significant changes but we're rewriting history.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 10 committers have signed the CLA.:white_check_mark: adolsalamanca:x: k8s-ci-robot:x: maaoBit:x: torredil:x: ConnorJC3:x: sebastianlzy:x: jukie:x: jsafrane:x: tporeba:x: AndrewSirenkoYou have signed the CLA already but the status is still pending? Let us recheck it.


Vanilla cleanup - first pass

Closing as Imma split this feature branch off to pull out Prettier changes.


[ammo-request]: Rounds (Dueling Pistol) Silver (10 rounds per Purchase)

Weapon Type
Dueling Pistol
Material
Silver
Reference
https://2e.aonprd.com/Weapons.aspx?ID=201

Added in version 1.0.8.


Release as UPM/VPM Package

would be nice to have, also later down the line maybe VRC could even have the package in the VCC, making quick and easy optimization more popular and accessible.
I personally would like to use the UPM, but the formats should be compatible either way. If you need help setting up a package manifest or the assembly definition I'd be happy to help, I could even PR this myself if you like.

Next version will be VPM compatible.


Jerky behavior

I am showing the message bar with the following code. I wanted to close any previous message bar shown before a new message bar is added so to achieve this i am closing it forcefully as shown below in the code before showing a new message,
func showMessageBar(title: String, message: String, type: SwiftMessageBar.MessageType) {         SwiftMessageBar.SharedMessageBar.cancelAll(force: true)  _ = SwiftMessageBar.showMessageWithTitle(title, message: message, type: type, duration: 1.5, dismiss: true, callback: nil)     }
It shows jerky behavior in a scenario when a user taps repeatedly on a button that triggers the message bar. Means a new message bar is triggered before the previous had not completed its dismissal.

@woweez Try updating to the latest version and check if it happens again.

Closing due to inactivity


Include git as run dependency

It's used here

Good catch! The build number needs to be increased though

ah yeah, we would re-release upon merge. I was thinking about just waiting for v0.0.3. I've renamed this PR to indicate that.


Add test to make sure that ListFile and sharding work well with each other

i.e. a shard can always get to its inputs via ListFile
This is approximately the test that would've caught the GF ListFile bug. I don't want to add a test for that behavior specifically since a) we didn't fix the bug, so the test would fail, and b) the API that the bug was part of (block sharding) is going away, so there's no reason to test it. However, this tests that we get the behavior we want with file sharding.

LGTM


Sending data to a peer that is not nearby

Hi @dingwilson,
I like your wrapper for MultiPeer and I was thinking what if we store a particular peerID when it is nearby (for instance in userDefaults) and when they are not nearby, try sending a message to that peerID.
For example peer A wants to send a msg to Peer C but they are not nearby but B is nearby to A and also nearby to C.
A-----B-------C

I believe you can solve this by manually assigning an ID for each user that can not be changed unless they create a new account or delete the app or something.


Use work item link categories to identify children

fixes https://github.com/fabric8io/fabric8-planner/issues/1263

Codecov Report

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

@@            Coverage Diff            @@
##             master    #1048   +/-   ##
=========================================
  Coverage          ?   60.82%
=========================================
  Files             ?      104
  Lines             ?     9046
  Branches          ?        0
=========================================
  Hits              ?     5502
  Misses            ?     2971
  Partials          ?      573

Impacted Files
Coverage Δ

workitem/link/category.go
100% <ø> (ø)

migration/migration.go
61.59% <0%> (ø)

workitem/link/link_repository.go
73.57% <100%> (ø)

Continue to review full report at Codecov.

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

@kwk So, there should be yet another generic "category" which can be used for both WIT & WILT, right? And this new category should be used for identifying children?

@kwk So, there should be yet another generic "category" which can be used for both WIT & WILT, right? And this new category should be used for identifying children?

I think so.

Out dated.


Runner/GeneratedPluginRegistrant.m:10:9: Module 'apple_sign_in' not found  showing this error in xcode

Hi @umairali4433
From what I can see, the issue is related to a 3rd party plugin rather than to Flutter itself. Please open the issue in the dedicated repository.
Closing, as this isn't an issue with Flutter itself.
If you disagree, please write in the comments,
providing your flutter doctor -v, your flutter run -v,  your pubspec.yaml
a minimal reproducible code sample that does not use 3rd party plugins,
and I will reopen it.
Thank you


Optimized matrix math

Added non-tilt projections
Added quaternions
Added test framework
Created logo

Thank you for your work on improving citro3d.


Putting the clock forwards causes cron to catch-up and run multiple times

If you set a job to run @every 5s and start it works perfectly within my test program. However if you put the clock fowards an hour it will run approximately 720 times as the effective time will be playing catch-up with the current time (now). This can happen when laptops goes to sleep and then wake up. This is the issue I'm facing and my maintenance tasks to run multiple times on laptop resume.
By quickly taking a look I think the fix is to change line 161 from:
e.Next = e.Schedule.Next(effective)

To
e.Next = e.Schedule.Next(now)

I don't want to patch my code with this before you agree that this fix is correct. Please let me know.

I think that the reason I used 'effective' instead of 'now' is to avoid missing jobs in case of random pauses.  I agree that your use case seems pretty motivating to adjust things.  All of the tests pass when I make the change you describe, so at least I doesn't break anything in the typical case.
Want to give it a shot and report back how it goes?

Yeah will do. I have tested messing around with the clock and everything works fine with the change. Normal behaviour seems ok so I think it will be fine. I will report back in few weeks and let you know how it goes.

Hi @robfig, thought I'd report back.
I've been using my patch now in production for few days and this has solved my problems and doesn't seem to have had any regression effects. Should we push this fix to master?

Good to hear!  My only concern is the behavior during daylight savings transitions.  I'm not sure how to test that though..

Is this fix currently under consideration for v2?

Sure, I'm happy to merge it

Lovely! :)

I believe this was merged and all good. Closing


feat(platform): frontend vue3, vite node18

Before submitting a pull request, please ensure the following:
Description
Please explain the changes you made.
Add a link to the design (if applicable).
Checklist

[x] Code compiles correctly
[x] Relevant tests were added (unit / contract / integration)
[x] Relevant logs were added
[x] Linting run locally successfully
[x] All tests pass
[x] UA review
[x] Design is documented
[x] Extended the README / documentation, if necessary
[x] Open source is approved

When I migrated to vite.js it wasn't enough to test the change locally - but to run the vsix itself in a real dev space and verify. I had to change the backend code that loads the html code because vite not generates it differently..  If it doesn't work in VSCode you can see here the change: https://github.com/SAP/cloud-foundry-tools/pull/271. I see it happens also in the task explorer here: https://github.com/SAP/task-explorer/blob/c4bb635f412f69051c47494ec0d69d308250d546/packages/tasks_panel/src/panels/abstract-webview-panel.ts#L70-L77

@nprijic I tried to take the branch and build the vsix locally but I get errors and couldn't build the vsix, I get:

Anyway I wanted to take the vsix artifact into some dev space and compare the UI after this change.

@nprijic yarn ci still doesn't work for me locally.
I bumped the version in the package.json of vscode-tasks-explorer-tasks-panel and did yarn ci:artifacts_only in the root to build an updated vsix.
This vsix doesn't work - As mentioned you have to update the code in task-explorer/packages/tasks_panel/src/panels/abstract-webview-panel.ts similar to what I did here:
https://github.com/SAP/cloud-foundry-tools/blob/main/packages/backend/src/loginTargetView/loginTargetView.ts#L76-L92
(you can just copy/paste this section with cheerio as it should be generic enough.
The reason is that now vite generates the UI artifacts differently and the string manipulation that loads them to the webview just doesn't work anymore.
Anyway in my opinion a final test that your PR works as expected would be to generate the vsix as mentioned above, install it in a dev space and test the task explorer there, in comparison to a dev space where it is not installed.

Hi @nprijic - when taking this branch to BAS, with node 18 it seems to have an issue when building yarn ci:


Added getloadavg for Linux, the BSDs and Solaris.

Sadly Android's bionic lacks this functionality.

r? @alexcrichton
(rust_highfive has picked a reviewer for you, use r? to override)

@bors: r+ 72f1fb68d8235c92c4ed6fe94b3d4150af8dba49

:hourglass: Testing commit 72f1fb6 with merge 6598e2c...

:sunny: Test successful - status-appveyor, travis


Greeting Check constantly failing, i dont know the issue!

 Maximum call stack size exceeded
npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2020-10-24T12_38_52_536Z-debug.log
The command '/bin/sh -c npm install --production' returned a non-zero code: 1
Warning: Docker build failed with exit code 1, back off 3.935 seconds before retry.
/usr/bin/docker build -t 1e5c35:7bc77f1a00b242128d8728a402cdae9c -f "/home/runner/work/_actions/actions/first-interaction/v1/Dockerfile" "/home/runner/work/_actions/actions/first-interaction/v1"
Sending build context to Docker daemon  180.2kB
Step 1/4 : FROM node:slim
---> 922b09b21278
Step 2/4 : COPY . .
---> Using cache
---> e7ffa4544a8c
Step 3/4 : RUN npm install --production
---> Running in fb5c4560f188
npm notice
npm notice New patch version of npm available! 7.0.3 -> 7.0.5
npm notice Changelog: https://github.com/npm/cli/releases/tag/v7.0.5
npm notice Run npm install -g<EMAIL_ADDRESS>to update!
npm notice
npm ERR! Maximum call stack size exceeded
npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2020-10-24T12_38_57_936Z-debug.log
The command '/bin/sh -c npm install --production' returned a non-zero code: 1
Warning: Docker build failed with exit code 1, back off 6.7 seconds before retry.
/usr/bin/docker build -t 1e5c35:7bc77f1a00b242128d8728a402cdae9c -f "/home/runner/work/_actions/actions/first-interaction/v1/Dockerfile" "/home/runner/work/_actions/actions/first-interaction/v1"
Sending build context to Docker daemon  180.2kB
Step 1/4 : FROM node:slim
---> 922b09b21278
Step 2/4 : COPY . .
---> Using cache
---> e7ffa4544a8c
Step 3/4 : RUN npm install --production
---> Running in 57be650f49ce
npm notice
npm notice New patch version of npm available! 7.0.3 -> 7.0.5
npm notice Changelog: https://github.com/npm/cli/releases/tag/v7.0.5
npm notice Run npm install -g<EMAIL_ADDRESS>to update!
npm notice
npm ERR! Maximum call stack size exceeded
npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2020-10-24T12_39_06_115Z-debug.log
The command '/bin/sh -c npm install --production' returned a non-zero code: 1
Error: Docker build failed with exit code 1

@cclauss Cloud you please help in fixing this?

Open an issue at https://github.com/actions/first-interaction

Build container main to action use:
Integer V1;
Integer fs;
Integer babf97a3f00a;
Integer npm;

"/home/runner/work/_actions/actions/first-interaction/V1/Docker file /user/bin/docker build -t 1e5c35:7bc77f1a00b242128d8728a402cdae9c - f /home/runner/work/_actions/actions/first-interaction/V1/Docker file";
"/home/runner/work/_actions/actions/first-interaction/V1";
Sending build context to Docker daemon 180.2kB

Step 1/4 : FROM node: slim; slim: Pulling from library/node babf97a3f00a: Pulling fs layer d81eb1809d95: Pulling fs layer dbaab951a9fa: Pulling fs layer cb915c1b28b9: Pulling fs layer 7c72cd70a544: Pulling fs layer cb915c1b28b9: Waiting 7c72cd70a544: Waiting d81eb1809d95: Verifying Checksum d81eb1809d95: Download complete cb915c1b28b9: Verifying Checksum cb915c1b28b9: Download complete babf97a3f00a: Verifying Checksum babf97a3f00a: Download complete dbaab951a9fa: Verifying Checksum dbaab951a9fa: Download complete 7c72cd70a544: Verifying Checksum 7c72cd70a544: Download complete babf97a3f00a: Pull complete d81eb1809d95: Pull complete dbaab951a9fa: Pull complete cb915c1b28b9: Pull complete 7c72cd70a544: Pull complete Digest: sha256:bf39db19ac53a635030d5db569cab912322147139fbf929c252359f3c50c4207 Status: Downloaded newer image for node:slim —> 922b09b21278 Step 2/4 : COPY . . —> e7ffa4544a8c Step 3/4 : RUN npm install —production —> Running in 5f0039d32d9c npm notice npm notice New patch version of npm available! 7.0.3 -> 7.0.5 npm notice Change log: https://github.com/npm/cli/releases/tag/v7.0.5 npm notice Run "npm install — g<EMAIL_ADDRESS>to update! npm notice maximum call stark size exceeded.
A complete log of this run can be found in: /root/.npm/_logs/2020-10-24T12_38_52_536Z-debug.log The command "/bin/sher — c npm install — production" returned a non-zero code: 1
Warning: Docker build failed with exit code 1, back off 3.935 seconds before retry. /user/bin/docker build — t;
1e5c35:7bc77f1a00b242128d8728a402cdae9c — f;
"/home/runner/work/_actions/actions/first-interaction/v1/Docker file" "/home/runner/work/_actions/actions/first — interaction/v1" Sending build context to Docker daemon 180.2kB
Step 1/4 : FROM node:slim ---> 922b09b21278 Step 2/4 : COPY .  ---> Using cache ---> e7ffa4544a8c Step 3/4 : RUN npm install --production ---> Running in fb5c4560f188 npm notice npm notice New patch version of npm available! 7.0.3 -> 7.0.5 npm notice Change log: https://github.com/npm/cli/releases/tag/v7.0.5 npm notice Run "npm install — g<EMAIL_ADDRESS>to update! npm notice maximum call stark size exceeded.
A complete log of this run can be found in: /root/.npm/_logs/2020-10-24T12_38_57_936Z-debug.log The command '/bin/sher — c npm install --production' returned a non-zero code: 1
Warning: Docker build failed with exit code 1, back off 6.7 seconds before retry. /user/bin/docker build — t;
1e5c35:7bc77f1a00b242128d8728a402cdae9c — f; "/home/runner/work/_actions/actions/first-interaction/v1/Docker file".
"/home/runner/work/_actions/actions/first-interaction/v1".
Sending build context to Docker daemon 180.2kB.
Step 1/4 : FROM node:slim ---> 922b09b21278 Step 2/4 : COPY . . ---> Using cache ---> e7ffa4544a8c Step 3/4 : RUN npm install --production ---> Running in 57be650f49ce npm notice npm notice New patch version of npm available! 7.0.3 -> 7.0.5 npm notice Change log: https://github.com/npm/cli/releases/tag/v7.0.5 npm notice Run "npm install<EMAIL_ADDRESS>to update! npm notice Maximum call stark size excepted.
A complete move of this run can be found.
/root/.npm/_logs/2020-10-24T12_39_06_115Z-debug.log The command "/bin/sher — c npm install — production" returned a non-zero code: V1.
Docker build longer with exit code V1.


test-backend: Raise zerver/views/auth.py test coverage to 100%.

Automated message from Dropbox CLA bot
@robot-dreams, it looks like you've already signed the Dropbox CLA. Thanks!

Oops, it looks like I added a test that depends on Python 2 functionality--looking into a fix...

Also you've got a merge conflict with zproject/backends.py having reached 100% coverage :)

Thanks for the review!  Hopefully the most recent change addresses the issues, though I'm not sure what's going on with the "coveralls" build.

That's happening with coveralls consistently; I complained to their support a few days ago with no reply :(.

Merged, thanks @robot-dreams!  This is a super exciting milestone, 100% coverage for our views code!


Enforce inherent calls to go before other extrinsics.

Currently nothing prevent the block builder to put inherents call at the end of the block (after the other extrinsics).
We could enforce the inherent calls to go first by:

making ProvideInherent::create_extrinsic returning not an option.
check that for each pallet which provide an inherent there is an unsigned extrinsic at the beginning of the block. We would also call the pallet implementation of ProvideInherent::check_inherent for its related extrinsics.

Thus we will ensure inherent calls are in front of the block and in some specified order.
Downside: pallet cannot optionally provide an inherent.
This is what is implemented in https://github.com/paritytech/substrate/pull/7712

* making `ProvideInherent::create_extrinsic` returning **not** an option.

Why do we require this?
I would really like to have some way to call.is_inherent() to just check if a call is an inherent. Than we could panic in execute_block if there is an inherent after we applied the first normal extrinsic.

ah indeed I didn't think we could differentiate between inherent extrinsic and unsigned transactions. This opens possibilities


[BUG] The project folder remains with no content after command yo kube-microservice-node

Describe the bug
After running yo kube-microservice-node and answering to requested inputs, the project folder remains with no content.
Expected behavior
The yo kube-microservice-node command should receive the expected inputs and create the project structure.
Additional context
node version v4.17.6
npm version 6.14.15
OS Ubuntu 20.04.3 LTS ( 5.11.0-34-generic )

Debugging the generation process we can find out this issue is related to package.jsonpath, for some reason the path /home/${user}/.nvm/versions/node/v14.17.6/lib/node_modules/generator-kube-microservice-node/app/templates/package.json seems to be replaced by /home/${user}/.nvm/versions/node/v14.17.6/lib/node_modules/generator-kube-microservice-node/app/index.js/package.json ( not the right folder path ).


MQTT Bridge: encapsulate bridged traffic when transporting through IPC

Feature Description
Our company needs separation of concerns when it comes to transporting messages over IPC. MQTT-topics and IPC-topics serve two different purposes.
Use Case
Devices communicating over arbitrary manufacturer-specific MQTT topics need to be routed to a common Greengrass Component via IPC, where the IPC input/output topics are independent of the MQTT topics.
Proposed Solution
The MQTT payload (including it's topic) could be encapsulated within the IPC payload and transmitted over a separately-configured IPC topic. This way, the original MQTT context is preserved, but the IPC transport can be managed separately.
Current MQTT Bridge Configuration
"mqttTopicMapping": {
  "ClientDevice1Mapping": {
    "topic": "clients/MyClientDevice1/hello/world",
    "source": "LocalMqtt",
    "target": "IotCore"
  },
  "ClientDevice2Mapping": {
    "topic": "clients/MyClientDevice2/hello/world",
    "source": "LocalMqtt",
    "target": "IotCore"
  }
}

Conceptual proposed MQTT Bridge Configuration
"mqttTopicMapping": {
  "ClientDevice1Mapping": {
    "sourceTopic": "clients/MyClientDevice1/hello/world",
    "source": "LocalMqtt",
    "targetTopic": "connector/mqtts/message/input",
    "target": "Pubsub"
  },
  "ClientDevice2Mapping": {
    "sourceTopic": "clients/MyClientDevice2/hello/world",
    "source": "LocalMqtt",
    "targetTopic": "connector/mqtts/message/input",
    "target": "Pubsub"
  }
  "OutboundMapping": {
    "sourceTopic": "connector/mqtts/message/output",
    "source": "Pubsub",
    "targetTopic": "clients/MyClientDevice2/command",
    "target": "LocalMqtt"
  }
}

But then, rather than just message.getPayload() being transported, the IPC payload would be something like:
{
  "mqttTopic": "clients/MyClientDevice2/hello/world",
  "mqttPayload": message.getPayload()
}

This would only apply to source/target = Pubsub, if Pubsub isn't involved, then proceed as implemented today.
Other

[x] :wave: I may be able to implement this feature request
[x] :warning: This feature might incur a breaking change

The payload interface changes. A configuration parameter like encapsulatePayload or transformIpcTopic could be added to allow users to choose whether or not the mqttPayload is nested within the IPC payload, or it's just the raw payload.
I plan to implement this myself in a fork, but would appreciate any feedback or guidance that would increase the likelihood it gets merged into the product.

Very soon you will be able to subscribe to wildcard topics using local PubSub. It sounds like that would address your need too?
So you can subscribe to clients/+/hello/world for example. The pubsub message will also include the original topic which it was sent to.

@MikeDombo It's a step in the right direction, but it doesn't quite suite our use-case. Our problem is we're trying to make a generic connector which can process messages from an arbitrary MQTT topic (where we don't want to have to specify the multitude of potential incoming topics like acme/widgetA/temperature, otherCompany/sensor/pn1234/vibration and so on).
Ultimately, the target configuration, I'm shooting for is something like:
{
  "sourceTopic": "#",
  "targetTopic": "connector/mqtts/messages/input",
  "source": "LocalMqtt",
  "target": "Pubsub",
}

So all MQTT broker traffic gets echo'ed to IPC, ultimately to our downstream processing component. Without the ability to specify "targetTopic", I'd have to subscribe to IPC "*", which isn't acceptable.
I did just find this in the source, though, so somebody's thinking about it on your end:
// src/main/java/com/aws/greengrass/mqttbridge/MessageBridge.java:151
// Add destinations for each source topic
// TODO: Support more types of topic mapping.
// Currently we are only mapping to the same topic on which the message is received (this is specified by
// an empty string)
// Still keeping the value as a pair of topic string and target type because we want to support mapping
// to different topics in the future.

Understood, yes we've definitely thought about it, just wanted to give you more options which I know are coming soon.
With an upcoming Nucleus release, you will be able to use pubsub to subscribe to wildcards, including #. Your component may then do whatever processing it wants based on the original topic. Likewise, in Bridge you can use a wildcard to just re-publish everything from local MQTT into local pubsub.
Aside from that, I think that we'd be happy to get this as a pull request. The primary thing we'd need is that it is entirely backwards compatible and any breaking changes are strictly opt-in.

The PR I just submitted, is just the surface-change, adding targetTopic (and renaming topic to sourceTopic -- with backwards compatibility, assuming topic => sourceTopic).
I'm thinking for the second part of my "conceptual" solution above, I'll add another configuration parameter like:
"mqttTopicMapping": {
  "ClientDevice1Mapping": {
    "sourceTopic": "clients/MyClientDevice1/hello/world",
    "source": "LocalMqtt",
    "targetTopic": "connector/mqtts/message/input",
    "target": "Pubsub"
    "targetPayload": {
      "mqttTopic": "{sourceTopic}",
      "mqttPayload": "{sourcePayload}"
  },
}

This provides a clean "opt-in" (targetPayload == null) results in the same behavior as currently implemented) and also provides some flexibility in how the target-payload is constructed. Not sure how possible this will be yet, but it's what I'm going to shoot for. I was going to try and find some other examples of template replacements in gg-v2 config and see what patterns are available and try to stay consistent with them.
The templating could also be extended to other configuration:
{
  ...
  "targetTopic": "some-prefix/{thingName}/{sourceTopic}/some-suffix",
  ...
}

Thank you for the PR! I'm wondering if we can simplify this a bit and still address your use case.
If we exposed a targetTopicPrefix configuration instead, it would be possible to map wildcarded MQTT source topics without needing a data transformation. Is that something you'd be open to?
For example:
"mqttTopicMapping": {
  "acmeTemperature": {
    "sourceTopic": "acme/+/temperature",
    "source": "LocalMqtt",
    "targetTopicPrefix": "external",
    "target": "Pubsub"
  },
  "vibrationMapping": {
    "sourceTopic": "otherCompany/sensor/+/vibration",
    "source": "LocalMqtt",
    "targetTopicPrefix": "external",
    "target": "Pubsub"
  }
}

Then your processing component only needs to subscribe to external/# and can extract the original topic from the PubSub topic itself by stripped off external/

@jbutler No problem! Yep, that would solve our current use-case.
I was moving in the transform direction as, in our current solution, the component listening to these IPC messages is just a simple transformer which adds one field to the context (source) and then puts the all the data in a local Stream (so something like {"topic": "my/mqtt/topic", "payload": bytes..., "source": "connector.mqtt"}). If we could do that basic transform and eventually target Streams, I could eliminate a Component.
My next contribution was probably going to be adding Stream as a potential target/source.
Using the suggested prefix-approach, we'll have to keep this little utility Component, but it's not the end of the world, and I understand the desire to keep the bridge simple.
I haven't done any work yet on this second stage, and I'm open to whichever approach you guys would rather go forward with.

@cBiscuitSurprise For now I'd prefer the prefix approach. As you said, it keeps things simple. I'd be comfortable merging in that change without needing a formal design + review and we could likely get that feature shipped pretty quickly.
That said, I can definitely see the usefulness of a component which is able to do more complex data transformations. I'd want to take a look at other customer use cases and spend a bit more time on a design for that, though.
Thanks again for contributing. This is great

Cool, I'll do the prefix thing first thing tomorrow. Should I just put it in the current PR, or open a separate one just for the prefix? They're relatively independent from an implementation point of view, but also both pretty small.

If you'd like to keep the current work, then feel free to open a new PR. We'll probably close it out, for now, but can always revisit in the future.

@jbutler As I'm working on my downstream component, I'm realizing that the IPC Stream Handler (in my case, the python sdk SubscribeToTopicStreamHandler) doesn't provide the IPC channel as part of it's on_stream_event, so it's not possible for me to know what topic the message was received on on the IPC listener side (reference SubscriptionResponseMessage).
Is this being handled at all as part of the IPC wildcard feature? Speaking of which, what's the timeline for the IPC subscription patterns feature?

@cBiscuitSurprise yes, as part of wildcard support, the message you receive in the subscription callback will include the original topic. Cannot share a precise timeline with you right now or make commitments, but it should be soon (before the end of the month).

If anyone is interested, I created a reference implementation for the target-payload-template idea here: cBiscuitSurprise:addTargetPayloadTemplate. It combines the targetTopic with a new targetPayloadTemplate string which expects a template-string like "{\"mqttTopic\": \"${sourceTopic}\", \"mqttPayload\": \"${sourcePayload:base64}\"}". I couldn't figure out where the current template engine exists (for things like {artifacts:path} and the like), so for a POC-level implementation, I'm just using StringSubstitutor from org.apache.commons.text.
I'm probably going to use this as a custom component at least until the IPC-pattern-matching is released.

The change in Bridge and the wildcard support for local pubsub has now been released publicly.


DOCS-6080 Platform Offerings Topic

@sleslie23 @fermujica I'm not sure why the table cell contents are not top justified. Isn't the valign default set to top? If you have any thoughts on what is happening, please let me know - thanks in advance! Please note that I didn't update the nav topic since we're not sure where this will go.
@kbostrom - I added an edit request in docs-edit-requests. You edited this a couple weeks ago, but there have been some wording updates.


Added new Domain for Ratsgymnasium Peine

My School switched to using Iserv, so we got a new domain, both are currently active. Feel free to delete the old one.
The old one is ratsgymnasium-peine.de

@DeinAlbtraumTV Pull request merged. Thank you!


Refectoring code

Have you considered refactoring the channel-config code? The file is nearly 2000 lines and a bit difficult to work with.

I mean it's not not going to happen eventually. But these things come when it's time for them to come. Eventually all of the tools will be moved to endpoints so a refactor is kind of inevitable there.


Translate docs/source into Korean

Signed-off-by: Jerry Park<EMAIL_ADDRESS>
What type of PR is this?
/kind content
/kind translation
Any specific area of the project related to this PR?
/area documentation
What this PR does / why we need it:
Translate docs/source into Korean.
Which issue(s) this PR fixes:

Fixes #278
Special notes for your reviewer:
@jmyung

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign leogr
You can assign the PR to them by writing /assign @leogr in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Preview page: https://deploy-preview-282--falcosecurity.netlify.app/ko/docs/source/

LGTM label has been added.  Git tree hash: fb546fe8c4209a9a49afc40ef953d32a20d76cd4

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: leodido
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [leodido]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


[FIX] Favorites List Overrided When Sharing Configs

I manage a mod pack for my friends and me to play with. I share my configs with them so we all have the same settings.
The issue is every time I update the modpack, I share the new modpack with them (along with each mods' config files). Even if I don't update the config for the suitsTerminal mod, it still overwrites it and essentially replaces their favorite suits list with mine.
Do you have any solutions for this? Or maybe a different way to store the favorites suits list for each user? Or maybe consider only allowing suits to be favorited in-game?
Any suggestions is much appreciated!

Sorry I've been under the weather for the past week or so. I have an Idea on how I'd like to implement your request while still maintaining functionality for the current favorite system being saved between profile shares.

Thanks for getting back to me! I look forward to your solution.

Hello,
I've introduced a new config item called PersonalizedFavorites in the latest update (version 1.5.4). Once you enable this your favorites will be stored in a text file located in the following folder: 'AppData\LocalLow\ZeekerssRBLX\Lethal Company\suitsTerminal'
Hopefully this resolves your issue!


The debug function disabled, when I connect to linux server.

when I connect to the linux server, the debug function is disabled.

Linux server system info:  Linux kylin 4.4.58-20170818.kylin.5.desktop-generic #5 SMP Fri Aug 18 10:19:03 CST 2017 aarch64 aarch64 aarch64 GNU/Linux

How do you connect to the linux server?

How do you connect to the linux server?


Remove unnecessary semi-colons

Here is a link to the related issue.

Brilliant, thanks @HawkiesZA! LGTM :)


Search api doesn't accept sort_by and sort_order

This query returns []
Zendesk.client.search(query: "type:ticket sort_by:created_at sort_order:asc")

But docs had these params. If Zendesk can't maintain a consistent state with docs, just expose a method we could use to send direct queries to these APIs
If this isn't a great solution, should we go this route instead?
search = Zendesk.client.search(query: "type:ticket)
search.sort_by('created_at').sort_order('asc')

Am asking because I could take time to implement this feature.

The intended way of using the order params is:
@ts = []
client.search(query: "type:ticket", sort_by: :created_at, sort_order: :asc).all { |t| @ts << t.created_at }
# @ts will be ordered

Have a good day,
wherever you are now.


Excessive import warnings from New Horizons

Importing NH volumes gives a large number of duplicate warnings like:
2024-02-09 12:07:14 | pds.opus_import.main |--| WARNING | Retrieving viewable shape: C:/Users/runner/Dropbox (SETI Institute)/Shared-OPUS/pdsdata/holdings/documents/NHxxLO_xxxx/LORRI-responsivity-plot.png
2024-02-09 12:07:14 | pds.opus_import.main |--| WARNING | Retrieving viewable shape: C:/Users/runner/Dropbox (SETI Institute)/Shared-OPUS/pdsdata/holdings/documents/NHxxLO_xxxx/NH-Boresight-FOVs.png

At the very least, we shouldn't see these over and over again. At best, whatever is causing the warning should be fixed.

This was fixed as part of #1346


Chem: hamburger substructure search doesn't work

Substructure filter on the column via the column’s humburger menu is not working

Fixed in PR #1349 and #4(labs repository)


FinRL_PaperTrading_Demo.ipynb - Alpaca 403 Client Error

in FinRL_PaperTrading_Demo.ipynb, on executing
data = DP.download_data(start_date = '2021-10-01',
                        end_date = '2021-10-05',
                        ticker_list = ticker_list,
                        time_interval= '1Min')

getting error:
HTTPError                                 Traceback (most recent call last)
 in ()
2                         end_date = '2021-10-05',
3                         ticker_list = ticker_list,
----> 4                         time_interval= '1Min')
6 frames
/usr/local/lib/python3.7/dist-packages/finrl/finrl_meta/data_processor.py in download_data(self, ticker_list, start_date, end_date, time_interval)
37             start_date=start_date,
38             end_date=end_date,
---> 39             time_interval=time_interval,
40         )
41         return df
/usr/local/lib/python3.7/dist-packages/finrl/finrl_meta/data_processors/processor_alpaca.py in download_data(self, ticker_list, start_date, end_date, time_interval)
35             for tic in ticker_list:
36                 barset = self.api.get_barset(
---> 37                     [tic], time_interval, start=start_time, end=end_time, limit=500
38                 ).df[tic]
39                 barset["tic"] = tic
/usr/local/lib/python3.7/dist-packages/alpaca_trade_api/rest.py in get_barset(self, symbols, timeframe, limit, start, end, after, until)
511         if until is not None:
512             params['until'] = until
--> 513         resp = self.data_get('/bars/{}'.format(timeframe), params)
514         return self.response_wrapper(resp, BarSet)
515
/usr/local/lib/python3.7/dist-packages/alpaca_trade_api/rest.py in data_get(self, path, data, api_version)
191         base_url: URL = get_data_url()
192         return self._request(
--> 193             'GET', path, data, base_url=base_url, api_version=api_version,
194         )
195
/usr/local/lib/python3.7/dist-packages/alpaca_trade_api/rest.py in _request(self, method, path, data, base_url, api_version)
137         while retry >= 0:
138             try:
--> 139                 return self._one_request(method, url, opts, retry)
140             except RetryException:
141                 retry_wait = self._retry_wait
/usr/local/lib/python3.7/dist-packages/alpaca_trade_api/rest.py in _one_request(self, method, url, opts, retry)
158         resp = self._session.request(method, url, **opts)
159         try:
--> 160             resp.raise_for_status()
161         except HTTPError as http_error:
162             # retry if we hit Rate Limit
/usr/local/lib/python3.7/dist-packages/requests/models.py in raise_for_status(self)
958
959         if http_error_msg:
--> 960             raise HTTPError(http_error_msg, response=self)
961
962     def close(self):
HTTPError: 403 Client Error: Forbidden for url: https://data.alpaca.markets/v1/bars/1Min?symbols=AXP&limit=500&start=2021-10-01T09%3A30%3A00-04%3A00&end=2021-10-01T15%3A59%3A00-04%3A00

If you are running it now and getting errors, then markets are closed. Try again tomorrow.

I got this error earlier in the day when markets were open.  I had heard that Market Data API v1 endpoints will sunset on March 15, 2022 and will be removed from the Alpaca documentation. After March 15, 2022, systems using v1 endpoints will no longer work.

You should check what version of the processor_alpaca.py you are using, it may be outdated.
Look into /finrl/finrl_meta/data_processors/processor_alpaca.py
In particular at line 13, you should see that the version of the app used is ‘v2’
The latest alpaca_trade_api uses their v2 api that’s why it’s surprising that you have a call to the old v1 api.
L

On Feb 3, 2022, at 5:36 PM, vrangayyan6 @.***> wrote:
I got this error earlier in the day when markets were open. I had heard that Market Data API v1 endpoints will sunset on March 15, 2022 and will be removed from the Alpaca documentation. After March 15, 2022, systems using v1 endpoints will no longer work.
—
Reply to this email directly, view it on GitHub https://github.com/AI4Finance-Foundation/FinRL/issues/460#issuecomment-1029531164, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABC5C55H27RUTF36JOERSDUZMNQFANCNFSM5NQKPUMA.
You are receiving this because you are subscribed to this thread.

Thanks!  I'll update my repo.


SOLID Principles refactoring👨💻

IN This PR we present SOLID Principles refactoring🚀 :
Below are some of my implementations as well as going over the project requirements 🤝 .
Requirements

Setup ruby workflow and linters 🔍.
use GitFlow 🌊.
Make sure YAGNI, KISS, and DRY rules and Ruby style guide are respected. 🔯
Follow SOLID principles. 🧱
Pay special attention to the Single-responsibility Principle.🥼
- Make sure that the role of main.rb is only to start your code and ask the user for the initial choice of options (or to quit).
- Extract some pieces of logic into separate class(es).

Achievements

Setup ruby workflow and linters 🔍.✅
use GitFlow 🌊.✅
Make sure YAGNI, KISS, and DRY rules and Ruby style guide are respected. 🔯 ✅
Follow SOLID principles. 🧱 ✅
Pay special attention to the Single-responsibility Principle.🥼 ✅

Conclusion
We are looking forward to hearing 👂  from you Our CR in terms of what can be better implemented 👨💻  for the project thankyou!. And we look forward to hearing from you soon.  🙇

IN This PR We present Changes♻ to SOLID Principles refactoring👨💻:
Below are some of my implementations as well as going over the Required Changes 🤝 .
Changes Required ♻

Bring all Input & input Validation techniques to the Main.rb file as requested here
Remove clustering commented out # code snippets from the codeBase⛓

Achievements

Bring all Input & input Validation techniques to the Main.rb ✅
Remove clustering commented out # code snippets from the codeBase⛓  ✅

Conclusion
We are looking forward to hearing 👂  from you The CR in terms of what can be better implemented 👨💻  for the project thankyou!. And we look forward to hearing from you soon.  🙇


Sign & Release Pipeline

A github action cd.yml to build, sign, notarize, and release xchtmlreport binaries built against xcode 12.5 & 13.
Requires the following secrets:

BUILD_CERTIFICATE_BASE64 - A b64 encoded string for the app identity cert
P12_PASSWORD - The password for the above cert
KEYCHAIN_PASSWORD - hardcoded pw for the builder keychain
AC_USERNAME - apple dev account application username
AC_PASSWORD - apple dev account application pw

@nacho4d PTAL in regards to #213. I tested this out on my fork and the signing/notarization works. The only blocker here is that I don't have access to adding secrets (assuming admin) to this main repo. Feel free to configure/add env vars per my above description (generating an app id signing cert), or we can work out the best way to get the one-time creds that I used added over here.
Thanks!

@tylervick Thank you for doing all this work!
I have a question...

I saw BUILD_CERTIFICATE_BASE64 , P12_PASSWORD,  AC_USERNAME , etc. XCTestHTMLReport is a young organization and we don't have a Apple Account specially for this organization. We need one right? A paid account one?

@nacho4d Np! We do need a signed cert from a paid account. However, Developer Organizations require a registered entity/DUNS so it likely makes more sense to use a personal account.
I have a paid account and a cert for this (the one I used on my fork). I'm happy to pass it over here if you're comfortable - it won't have any impact on the distribution of the binary itself.

@tylervick
Thank you for the info.
XCTestHTMLReport is an organization but I don't think we quality as a company now. (We don't have a DUNS, etc).
It would be terrific if you can setup the certs with your account! (I have granted admin right to you too just now 👍 )
The PR looks great. I added some comments for some details I found.