feat!: introduce new conventions

Description
Both the constant and interface are exported, but currently use the same naming. This makes is difficult to use the name as a constant. I faced this issue when using the type Entry and extending it based on my custom one. Even though, I ended up using a different approach, I think it might be better if we use a different name for the interface and constant.
I tested it on my own project generating the types and it works. If you think is a good change, feel free to merge it. However, please ensure to do some additional testing using the script before merging (running the script).
Additionally, I think it would be nice if we add a test to this script, to ensure it does what is expected. However, I left that out of scope of this pull request.
Current situation:

Expected:

Changes
BREAKING CHANGE: Changed naming convention so that both the exported constant name and interface can be used

rename toInterfaceName to toPascalCase
introduced getInterfaceName method to prefix interface names with I
introduced getConstantName method to postfix constants with Name

There's already a --prefix option for Interface name which allows the output to differ between the constant and the interface.
I guess more flexibility could be useful so that we could have separate prefix and suffix for both constants and interfaces and not just a prefix for interface.

There's already a --prefix option for Interface name which allows the output to differ between the constant and the interface.
I guess more flexibility could be useful so that we could have separate prefix and suffix for both constants and interfaces and not just a prefix for interface.

My personal opinion is that having satisfying defaults has the upper hand over providing additional options.


Custom element arrows

Closes #36. Inspired by the work done on pull request #85.
What's Changing

Added a Storybook example to support passing the arrow HTMLElement to the Glider component.
Updated Glider typings to support HTMLElement as arrow

Change Type
Indicate the type of change your pull request is:

[x] documentation
[x] patch
[ ] minor
[ ] major

:rocket: PR was released in v3.0.0 :rocket:


Merge in golang/groupcache changes, test travis-ci

Will remove golang/groupcache .travis.yml
Other changes to upstream repo are minimal

 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.0 out of 7 committers have signed the CLA.:x: kevinburke:x: EdwardBetts:x: bradfitz:x: luciferous:x: HaraldNordgren:x: Daniel Smith:x: lorneliDaniel Smith seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Conditionals are allowed in parsers

Fixes #1092

Since this is a bug fix I think we should merge it right away.


Provide workspace configuration for IntelliJ

Classpath for projects
JUnit test

This request is out of scope for current plans.


Add ability to zoom image product while add or update

Please see this as a option!
Also, this merge will fix the cropped image issues too.
#53

Thanks.
Really smooth zoom effect


DRILL-6294: Changes to support Calcite 1.16.0

@amansinha100, @chunhui-shi could you please take a look?

@chunhui-shi, I have addressed all CR comments, could you please take a look again?

+1. Thank you for making the fix.


TalosReturnError: Make sure that input model returns 'out, model' where out is history object from model.fit()

I am facing this issue. Please let me know how to resolve


[Suggestion] "Export Selected Node to GDScript" Feature!

Cannot believe I just finally thought of this!
Basically, the option ("Export Node to GDScript") could be listed in the context menu when right clicking a node:

This would generate the GDScript, then show it in a selectable text Popup menu.

For example, the c_player -> label is a marker for the minimap. I have to generate that node dynamically when players join the world anyway. So instead of just copying all those inspector field values (texture region for sprite, etc) manually, the developer can just click on "Export Node to GDScript", then use the code his AddPlayerToMiniMap method.
You might be wondering... well just export it as a scene and instance it. You're not wrong... however I still think this would be something really unique & useful!  Too many issues I think the devs better off to work on tbh :X I'm just being silly hehe.

You could make this as a plugin and put it in the AssetLib :)


feat: multi currency trade support

Description

Notice

[x] Have you followed the guidelines in our Contributing guide?
[x] Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Pull Request Type

[ ] :bug: Bug fix (Non-breaking Change: Fixes an issue)
[ ] :hammer_and_wrench: Chore (Non-breaking Change: Doc updates, pkg upgrades, typos, etc..)
[x] :nail_care: New Feature (Breaking/Non-breaking Change)

Issue (if applicable)
closes #1995
Risk
It's related to the trade-card, so there's a risk.
Testing
Screenshots (if applicable)

closing in favor of #2235


Add Image.save_exr()

Added a function to complement save_png(), because 16-bit and 32 bit float formats can't be saved from Godot.
This notably allows to save terrain data as a proper image format and eases interoperability with other software (although if we want terrain EXR to be efficient for use in Godot, we'll have to make it support single-channel properly).
The following formats can be saved:
RH
RGH
RGBH
RGBAH
RF
RGF
RGBF
RGBAF

All tested with this project:
TestExrSave.zip
Results come up correct when checked in Gimp and RenderDoc.
Closes https://github.com/godotengine/godot/issues/17450

Could you add the relevant documentation for the new method? It should likely mention that the method returns [constant ERR_UNAVAILABLE] if the tinyexr module is disabled.

Added license header
Added grayscale parameter
Reversed channels as TinyEXR examples recommend
Support 8-bit pixel types by converting them to half
Added documentation

Updated test project:
TestExrSave.zip

Thanks!


change title name

Fixes Issue
359

Changes proposed

Check List (Check all the applicable boxes)

[x] My code follows the code style of this project.
[x] My change requires changes to the documentation.
[x] I have updated the documentation accordingly.
[x] All new and existing tests passed.

Ok maam
On Thu, 25 May, 2023, 23:28 Monalika Patnaik, @.***>
wrote:

Closed #365 https://github.com/MonalikaPatnaik/UMatter/pull/365.
—
Reply to this email directly, view it on GitHub
https://github.com/MonalikaPatnaik/UMatter/pull/365#event-9342994262,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AYEWXYQ2JO3JCYMQQFXOTCLXH6MURANCNFSM6AAAAAAYO7XI3I
.
You are receiving this because you authored the thread.Message ID:
@.***>


mmap_released still flaky

https://github.com/quickwit-oss/tantivy/actions/runs/3117622662/jobs/5056401756
FAIL [   0.455s]               tantivy directory::mmap_directory::tests::test_mmap_released

--- STDOUT:                            tantivy directory::mmap_directory::tests::test_mmap_released ---

running 1 test
test directory::mmap_directory::tests::test_mmap_released ... FAILED

failures:

failures:
    directory::mmap_directory::tests::test_mmap_released

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 687 filtered out; finished in 0.45s

https://github.com/quickwit-oss/tantivy/pull/1592

https://github.com/quickwit-oss/tantivy/actions/runs/3232638417/jobs/5293495502

Thanks fro reopening.
Attempting to put a nicer fix.


It is currently not working.

If you enter a passphrase, it will exit with not bounded.
Passkey Input of GAP seems to be fired after accepting l2cap, but the code assumes that the authentication is done when accepting l2cap is completed.
Is it maybe that the behavior changed around Linux 1.54?

I'll refactor it a bit.


Allow ISO Upload from Local Machine

ISSUE TYPE

Enhancement Request

COMPONENT NAME

UI

CLOUDSTACK VERSION

4.11.3

CONFIGURATION

N/A
OS / ENVIRONMENT

N/A
SUMMARY

In CloudStack 4.11, it's possible to upload VM templates directly from the web interface, without requiring an upload to an intermediate web server first.
This should also be implemented for ISO uploads.
STEPS TO REPRODUCE

N/A

EXPECTED RESULTS

N/A

ACTUAL RESULTS

N/A

this has been fixed by #3251

Woops I think I even saw that PR, but didn't realise what it did. Mea culpa.


Hue dimmer is missing.

Version: 4.0.4
Hue dimmer is missing.

Please read the version hint in the README of the v4.

When button 1 is pressed, 2 msg.payload.

msg.payload.action initial_press
msg.payload.action short_release

For a long press on a key
msg.payload.action initial_press
msg.payload.action repeat
There will be a msg.payload every second until the key is released.

This is indeed the behaviour of the new CLIP/V2 API by Philips Hue. The initial press is always fired by the bridge. You may want to respond only to this message and filter out the other ones.
HueMagic will only fire out a message when it differs from the previous one.


Add note to data dictionary about why archived patient data is null before 2019-10-21

https://codefordc.slack.com/archives/C0E6APB36/p1571703212151600

Context
We had a bug in the archive & export code leading to all patients being marked as having special circumstances (hint: 1/0 are not truthy/falsey, they're both truthy :sob:).
Because of this we bug we had every archived patient flagged as having special circumstances. We decided to mark all those patients as not having, instead, since we have no way of discovering this after archiving.
Work to do
Add this note to the Data Dictionary:

Archived Patients prior to 2019-10-21 will always have had_special_circumstances set to null due to a bug in the archiving processing not preserving the value. Archived patients after that date correctly reflect whether or not they had special circumstances. See issue #1836 for further context.


MacOS Big Sur "dlsym(RTLD_DEFAULT, GetMacOSStatusCommentString): symbol not found"

This is a duplicate of #24.

Although this is technically a duplicate of #24, the original issue there was due to a different root cause from what I can tell.  This relates to the more recent discussion and this issue probably should be used to track the newer issue as there are two different issues being discussed in #24 now.

Although this is technically a duplicate of #24, the original issue there was due to a different root cause from what I can tell.  This relates to the more recent discussion and this issue probably should be used to track the newer issue as there are two different issues being discussed in #24 now.

The solutions that I could probably support here are:

Compiled module for macOS using probably the NSFileManager as that seems to be the way to interact with the file system without creating an internal finder. Although might have to go the finder route to fix the "put back" issue... from the looks of it.
Use PyObjC instead to accomplish the same thing.

@BoboTiG, @HWiese1980,  @acheronfail, or anyone else not sure if there is a preference here or any other opinions as it seems like a change like that is most likely needed to better support these systems.  I would probably set this up similar to the windows implementation in that it would attempt to fall back (and in some cases it would ultimately error if on a system/ python version that has some of the different issues that combine to produce this result).
I might take a look at a quick PyObjC implementation in the next week or so to see how that works out in general as that is probably the fastest for me to get pulled together.

The solutions that I could probably support here are:

Compiled module for macOS using probably the NSFileManager as that seems to be the way to interact with the file system without creating an internal finder. Although might have to go the finder route to fix the "put back" issue... from the looks of it.
Use PyObjC instead to accomplish the same thing.

@BoboTiG, @HWiese1980,  @acheronfail, or anyone else not sure if there is a preference here or any other opinions as it seems like a change like that is most likely needed to better support these systems.  I would probably set this up similar to the windows implementation in that it would attempt to fall back (and in some cases it would ultimately error if on a system/ python version that has some of the different issues that combine to produce this result).
I might take a look at a quick PyObjC implementation in the next week or so to see how that works out in general as that is probably the fastest for me to get pulled together.

Thanks for tagging me here, @arsenetar. I've no explicit preference other than "that it works" and can be installed and used without further ado (except of course pip install send2trash). That's basically all I need. Plus love. ;-)

Thanks for tagging me here, @arsenetar. I've no explicit preference other than "that it works" and can be installed and used without further ado (except of course pip install send2trash). That's basically all I need. Plus love. ;-)

@arsenetar:  I've tried using PyObjC for trashing a file but it will not solve the "Put Back" problem.
Here the code:
import Cocoa
import objc

with open("foo", "a+"):
    pass
path = "foo"
fm = Cocoa.NSFileManager.defaultManager()
fileUrl = Cocoa.NSURL.fileURLWithPath_(path)
result = fm.trashItemAtURL_resultingItemURL_error_(fileUrl, objc.nil, objc.nil)
print(repr(result))

To be run with:
pip3 install pyobjc-framework-Cocoa
python main.py

@arsenetar:  I've tried using PyObjC for trashing a file but it will not solve the "Put Back" problem.
Here the code:
import Cocoa
import objc

with open("foo", "a+"):
    pass
path = "foo"
fm = Cocoa.NSFileManager.defaultManager()
fileUrl = Cocoa.NSURL.fileURLWithPath_(path)
result = fm.trashItemAtURL_resultingItemURL_error_(fileUrl, objc.nil, objc.nil)
print(repr(result))

To be run with:
pip3 install pyobjc-framework-Cocoa
python main.py

Any good news here so far? @arsenetar

Any good news here so far? @arsenetar

Got an initial implementation, still need to finish cleaning things up and getting the unit tests updated to test the new implementation as well as the fallback.

Got an initial implementation, still need to finish cleaning things up and getting the unit tests updated to test the new implementation as well as the fallback.

Would also like to know when this is going to be fixed :)

Actually back to working on this, found a bunch of issues in the unit tests across a couple platforms, working on fixing the testing and cleaning it up so that I know there are good tests to validate this against.  Discovered there were more issues there than I had expected.

I'm still running into this issue on send2trash 1.5.0, macOS 11.2.3, and Python 3.9.2 on an M1 Mac.

@johnmcc3 There hasn't been a new release yet, AFAIK.

I'm impacted by this transitively through https://github.com/jupyterlab/jupyterlab/issues/9863 There is an unmerged workaround for it https://github.com/jupyter/notebook/pull/6016
Any news on the fix in this repo? Anything I can do to assist?

@groodt I haven't gotten back to this, need to find time to finish this up, my mac system since installing 3.9.2 does not seem to be throwing this issue anymore so I wont be able to 100% validate the solution on my system.  I should be able to have an update this week.

I got some code put together for the dual method approach like I have for the windows version its over in the https://github.com/arsenetar/send2trash/tree/feature/%2351 branch at the moment.  I will probably merge this in and package an alpha version in the next day or two. This seems to be working fine on my machine, again mine stopped showing the issue even without the workaround.  If you want to test the workaround you would have to build from that branch and install the pyobjc-framework-Cocoa package (with python >= 3.6).

An alpha labeled package is available now on pypi can install with pip install Send2Trash==1.7.0a0 if testing out the pyobjc option need to also install pyobjc-framework-Cocoa as well.  I'm going to wait on some feedback on this before marking this as a normal release.

Cool! I'll see if I can give it a shot hopefully within the remaining days this week. Can't promise though... If anyone has already, I'll be happy to hear a report ;-)

@HWiese1980, @groodt, @johnmcc3, @doogo8 have any of you had a chance to verify the alpha version?  I am needing feedback since I cannot reproduce on my system.

Not yet, unfortunately. I'll see if I can squeeze it in tomorrow, can't promise though...

Can confirm that 1.7.0a0 works on macOS 11.2.3 with python 3.8.5 but only if pyobjc-framework-Cocoa is also installed. Using version 1.5.0 failed with the same setup.
Is the plan to add pyobjc-framework-Cocoa as a dependency (or at least an extra) prior to the final release?

Stumbled over this similar to the other jupyter users, @ITProKyle mentioned it working with 1.7.0a0, but for me it didn't work (3.9, MacOS 11.3.1, didn't matter whether I installed pyobjc-framework-cocoa or not).

@ITProKyle I am planning on marking pyobjc-framework-Cocoa as an extra for macOS since it is not always required.
@ctheune what was the output when running?

Thanks @arsenetar, here's the traceback:
Traceback (most recent call last):
  File "/private/tmp/asdf/bin/jupyter-lab", line 5, in <module>
    from jupyterlab.labapp import main
  File "/private/tmp/asdf/lib/python3.9/site-packages/jupyterlab/__init__.py", line 7, in <module>
    from .labapp import LabApp
  File "/private/tmp/asdf/lib/python3.9/site-packages/jupyterlab/labapp.py", line 15, in <module>
    from jupyterlab_server import slugify, WORKSPACE_EXTENSION
  File "/private/tmp/asdf/lib/python3.9/site-packages/jupyterlab_server/__init__.py", line 4, in <module>
    from .app import LabServerApp
  File "/private/tmp/asdf/lib/python3.9/site-packages/jupyterlab_server/app.py", line 7, in <module>
    from jupyter_server.extension.application import ExtensionApp, ExtensionAppJinjaMixin
  File "/private/tmp/asdf/lib/python3.9/site-packages/jupyter_server/extension/application.py", line 21, in <module>
    from jupyter_server.serverapp import ServerApp
  File "/private/tmp/asdf/lib/python3.9/site-packages/jupyter_server/serverapp.py", line 75, in <module>
    from jupyter_server.services.contents.filemanager import AsyncFileContentsManager, FileContentsManager
  File "/private/tmp/asdf/lib/python3.9/site-packages/jupyter_server/services/contents/filemanager.py", line 21, in <module>
    from send2trash import send2trash
  File "/private/tmp/asdf/lib/python3.9/site-packages/send2trash/__init__.py", line 12, in <module>
    from .plat_osx import send2trash
  File "/private/tmp/asdf/lib/python3.9/site-packages/send2trash/plat_osx.py", line 17, in <module>
    GetMacOSStatusCommentString = Foundation.GetMacOSStatusCommentString
  File "/nix/store/hmmqqj3hn6d4lsb3nm07c4pa8qdvvfml-python3-3.9.2/lib/python3.9/ctypes/__init__.py", line 387, in __getattr__
    func = self.__getitem__(name)
  File "/nix/store/hmmqqj3hn6d4lsb3nm07c4pa8qdvvfml-python3-3.9.2/lib/python3.9/ctypes/__init__.py", line 392, in __getitem__
    func = self._FuncPtr((name_or_ordinal, self))
AttributeError: dlsym(RTLD_DEFAULT, GetMacOSStatusCommentString): symbol not found

@ctheune That trace by the location and content of the issue in plat_osx.py seems to indicate you are not using the 1.7.0a0 version of send2trash as the file is now different.

Ouch, sorry, my bad. I just redid the jupyter-install and forgot to do the 1.7.0a0 update. Here it is again:
/tmp/asdf $ bin/pip freeze | grep Send
Send2Trash==1.7.0a0
ctheune@chazzzzz /tmp/asdf $ bin/jupyter lab
Traceback (most recent call last):
  File "/private/tmp/asdf/bin/jupyter-lab", line 5, in <module>
    from jupyterlab.labapp import main
  File "/private/tmp/asdf/lib/python3.9/site-packages/jupyterlab/__init__.py", line 7, in <module>
    from .labapp import LabApp
  File "/private/tmp/asdf/lib/python3.9/site-packages/jupyterlab/labapp.py", line 15, in <module>
    from jupyterlab_server import slugify, WORKSPACE_EXTENSION
  File "/private/tmp/asdf/lib/python3.9/site-packages/jupyterlab_server/__init__.py", line 4, in <module>
    from .app import LabServerApp
  File "/private/tmp/asdf/lib/python3.9/site-packages/jupyterlab_server/app.py", line 7, in <module>
    from jupyter_server.extension.application import ExtensionApp, ExtensionAppJinjaMixin
  File "/private/tmp/asdf/lib/python3.9/site-packages/jupyter_server/extension/application.py", line 21, in <module>
    from jupyter_server.serverapp import ServerApp
  File "/private/tmp/asdf/lib/python3.9/site-packages/jupyter_server/serverapp.py", line 75, in <module>
    from jupyter_server.services.contents.filemanager import AsyncFileContentsManager, FileContentsManager
  File "/private/tmp/asdf/lib/python3.9/site-packages/jupyter_server/services/contents/filemanager.py", line 21, in <module>
    from send2trash import send2trash
  File "/private/tmp/asdf/lib/python3.9/site-packages/send2trash/__init__.py", line 12, in <module>
    from .plat_osx import send2trash
  File "/private/tmp/asdf/lib/python3.9/site-packages/send2trash/plat_osx.py", line 20, in <module>
    from .plat_osx_ctypes import send2trash  # noqa: F401
  File "/private/tmp/asdf/lib/python3.9/site-packages/send2trash/plat_osx_ctypes.py", line 17, in <module>
    GetMacOSStatusCommentString = Foundation.GetMacOSStatusCommentString
  File "/nix/store/hmmqqj3hn6d4lsb3nm07c4pa8qdvvfml-python3-3.9.2/lib/python3.9/ctypes/__init__.py", line 387, in __getattr__
    func = self.__getitem__(name)
  File "/nix/store/hmmqqj3hn6d4lsb3nm07c4pa8qdvvfml-python3-3.9.2/lib/python3.9/ctypes/__init__.py", line 392, in __getitem__
    func = self._FuncPtr((name_or_ordinal, self))
AttributeError: dlsym(RTLD_DEFAULT, GetMacOSStatusCommentString): symbol not found

@ctheune That does look like 1.7.0a0 now, Did you also install pyobjc-framework-Cocoa looks like it is falling back to the ctypes version.

Sorry, not enough coffee this morning. So this was without pyobjc-framework-Cocoa. Here's when I install it:
/tmp/asdf $ bin/pip install pyobjc-framework-Cocoa
Collecting pyobjc-framework-Cocoa
  Using cached pyobjc_framework_Cocoa-7.2-cp39-cp39-macosx_10_9_x86_64.whl (273 kB)
Collecting pyobjc-core>=7.2
  Using cached pyobjc_core-7.2-cp39-cp39-macosx_10_9_x86_64.whl (293 kB)
Installing collected packages: pyobjc-core, pyobjc-framework-Cocoa
Successfully installed pyobjc-core-7.2 pyobjc-framework-Cocoa-7.2
WARNING: You are using pip version 20.2.3; however, version 21.1.1 is available.
You should consider upgrading via the '/private/tmp/asdf/bin/python3 -m pip install --upgrade pip' command.
/tmp/asdf $ bin/jupyter lab
Traceback (most recent call last):
  File "/private/tmp/asdf/bin/jupyter-lab", line 5, in <module>
    from jupyterlab.labapp import main
  File "/private/tmp/asdf/lib/python3.9/site-packages/jupyterlab/__init__.py", line 7, in <module>
    from .labapp import LabApp
  File "/private/tmp/asdf/lib/python3.9/site-packages/jupyterlab/labapp.py", line 15, in <module>
    from jupyterlab_server import slugify, WORKSPACE_EXTENSION
  File "/private/tmp/asdf/lib/python3.9/site-packages/jupyterlab_server/__init__.py", line 4, in <module>
    from .app import LabServerApp
  File "/private/tmp/asdf/lib/python3.9/site-packages/jupyterlab_server/app.py", line 7, in <module>
    from jupyter_server.extension.application import ExtensionApp, ExtensionAppJinjaMixin
  File "/private/tmp/asdf/lib/python3.9/site-packages/jupyter_server/extension/application.py", line 21, in <module>
    from jupyter_server.serverapp import ServerApp
  File "/private/tmp/asdf/lib/python3.9/site-packages/jupyter_server/serverapp.py", line 75, in <module>
    from jupyter_server.services.contents.filemanager import AsyncFileContentsManager, FileContentsManager
  File "/private/tmp/asdf/lib/python3.9/site-packages/jupyter_server/services/contents/filemanager.py", line 21, in <module>
    from send2trash import send2trash
  File "/private/tmp/asdf/lib/python3.9/site-packages/send2trash/__init__.py", line 12, in <module>
    from .plat_osx import send2trash
  File "/private/tmp/asdf/lib/python3.9/site-packages/send2trash/plat_osx.py", line 20, in <module>
    from .plat_osx_ctypes import send2trash  # noqa: F401
  File "/private/tmp/asdf/lib/python3.9/site-packages/send2trash/plat_osx_ctypes.py", line 17, in <module>
    GetMacOSStatusCommentString = Foundation.GetMacOSStatusCommentString
  File "/nix/store/hmmqqj3hn6d4lsb3nm07c4pa8qdvvfml-python3-3.9.2/lib/python3.9/ctypes/__init__.py", line 387, in __getattr__
    func = self.__getitem__(name)
  File "/nix/store/hmmqqj3hn6d4lsb3nm07c4pa8qdvvfml-python3-3.9.2/lib/python3.9/ctypes/__init__.py", line 392, in __getitem__
    func = self._FuncPtr((name_or_ordinal, self))
AttributeError: dlsym(RTLD_DEFAULT, GetMacOSStatusCommentString): symbol not found

@ctheune Looks like the conditional to use pyobjc might be problematic here what do you get if you run the following in the python interpreter in your environment:
from platform import mac_ver
from sys import version_info

print(version_info)
print(mac_ver())

Here you go:
/tmp/asdf $ bin/python
Python 3.9.2 (default, Apr  8 2021, 23:35:33)
[Clang 7.1.0 (tags/RELEASE_710/final)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from platform import mac_ver
>>> from sys import version_info
>>> print(version_info)
sys.version_info(major=3, minor=9, micro=2, releaselevel='final', serial=0)
>>> print(mac_ver())
('10.16', ('', '', ''), 'x86_64')
>>>

Ah yes @arsenetar the condition here https://github.com/arsenetar/send2trash/blob/c8bcaea1e8c082d391325834e286bb6b30f25201/send2trash/plat_osx.py#L12 should take into account 10.16.
For compatibility with older binaries, macOS 11.x may report itself as '10.16' rather than '11.x.y'.

Sources:

https://github.com/python/cpython/blob/bb3e0c240bc60fe08d332ff5955d54197f79751c/Mac/BuildScript/build-installer.py#L1638-L1640
https://github.com/python/cpython/blob/bb3e0c240bc60fe08d332ff5955d54197f79751c/Lib/test/test_platform.py#L333-L334

Maybe doing a check as done here could be good enough: https://github.com/python/cpython/blob/bb3e0c240bc60fe08d332ff5955d54197f79751c/Lib/test/test_posix.py#L1960-L1968

@BoboTiG Thanks for that information, I did not realize that macOS 11.x did that.  Since this check was mainly just to preserve the existing behavior except when needed I will probably just open up the conditional to allow using the pyobjc interface on any supported version of the OS instead as send2trash itself does not really need to impose any further restrictions.  This would update the conditional to check for 10.9 or newer for the macOS version.
@ctheune Thanks for trying out the new version and helping work through the issue.  I will try to get an updated pre-release package in the next day or two.

Sure. I'm subscribed here and can test whenever you have something ready. I can test from a branch if you like.

@ctheune I have updated the pypi package with another pre-release, as with the previous version it is on pypi and can be installed with pip install Send2Trash==1.7.0a1.

Aaaand we have liftoff. I've updated my existing instance and now it runs fine. Just to make sure: pyobjc-framework-Cocoa is still required and uninstallting it will fall back to the ctypes version which still fails but - but that's intentional, right?

Yes pyobjc-framework-Cocoa is still required on systems running into the issue, I let it fall back to the ctypes version just in case it does work on the platform (as is the case on mine for some reason...).  I need to update some of the documentation to make this clearer.

I'll be moving this to a stable release in the next week since it seems this solution is working.

Yeah, doing the following fixed the problem for me:
pip install pyobjc-framework-Cocoa==7.3 send2trash==1.7.0a1

Finally published as 1.7.1 on pypi.


Updated Rotten Tomatoes

Hello @MacSteini ,
This repo is not being maintained anymore, but we are trying to keep it alive on a fork here, would you kindly submit your PR there and close this one here? :)

Damnit. Updated the wrong one. Beg my pardon.


Possibility to "subscribe" to existing requests by other users

Description
Add the option for third users to "subscribe" to existing requests, in order to get notified about the availability. Most of my users use Jellyseerr's email notifications to get informed when an upcoming movie is available - however, if another user already requested it, they miss being notified.
Desired Behavior
User has the option to "Also request" or "Subscribe" to an existing request by another user. This perhaps adds the movie to their profile and gives them notifications regarding its availability.
Additional Context
No response
Code of Conduct

[X] I agree to follow Jellyseerr's Code of Conduct

Duplicate of #696

Duplicate of #696

I disagree, as the issue referenced is for a totally different request. The linked feature request wants to add another notifications provider to Jellyseerr, I'd like for some kind of logic implemented for multiple users to be notified about (yet) unavailable requests.
Do you implement features like this if they're added to Overseerr, or do you add your own features to Jellyseerr as well, seeing as Jellyseerr was forked from it?

Asking because this feature request from overseerr does exactly what I'm looking for. You already pointed to that issue in #375, I just saw

Sorry I meant to say #375

Do you implement features like this if they're added to Overseerr, or do you add your own features to Jellyseerr as well, seeing as Jellyseerr was forked from it?

We implement our own features. Jellyseerr can no longer pull features from overseerr as easily as it used to as we are on a different for a lack of a better word, "stack" than them given that jellyseerr now runs on nextjs 14, nodejs 20, pnpm, swc, and etc.


Option for no Art on main action bar.

This is something that you can do in Dragonflight. Basically just remove the art in the boxes for the main action bar to make it look like the reset of the bars
Thank you for your hard work, its very appreciated

If you mean the Gryphons, you can deactivate those through the Interface Options ->

But maybe you mean the grey box background of each actionbutton? Then theres not really an option right now.
(You could comment out 'Module.DrawActionbarDeco()' in Actionbar.lua, but its not really great)
I'm working an a new and way better customization menu, so maybe i will add this as an option.

Sorry, I should've added a picture!
I mean this bar down the bottom. Mainly because in SOD we don't have enough spells to fill the entire bar (at least I don't) so it looks a bit mismatched having the empty buttons. Plus this is an option available in Dragonflight.

Next major version includes more options:

Buttonstyle etc was more like a temporary solution from one of the first versions, but after the holidays i will overhaul the complete system and match the retail aesthetics.


support for custom endpoints

Is there any option to support custom endpoints atm?
Thanks
Calvin

Sorry for the late reply @xpluscal, what exactly do you mean by custom endpoints? Can you post a link to the offical docs for that feature?

Custom endpoints are documented here.
For me, the inability to have a working Python wrapper for the Wordpress API without custom endpoints is a dealbreaker. I want to merely inspect the storage of a custom field that is apparently not being stored as post meta.


Get-DbaDatabaseEncryption.Tests fixed wording of Context

Type of Change

[X] Bug fix (non-breaking change, fixes #)
[ ] New feature (non-breaking change, adds functionality)
[ ] Breaking change (effects multiple commands or functionality)
[ ] Ran manual Pester test and has passed (`.\tests\manual.pester.ps1)
[ ] Pester test is included

Purpose

Context was 'testing pester' from when I created it and was testing... pester :) Changed to match the actual purpose of the test.
Approach

Context "Test Retriving Certificate"

Merci 💵


Field aliasing via delegated schema not remapping field names

api: https://cardano-graphql-mainnet.daedalus-operations.com/
query test {
  blocks (limit: 1, order_by: { createdAt: desc}) {
    blockHash: id # alias id to blockHash
    epochNo
    slotWithinEpoch
    slotNo
    createdAt
  }
}

{
  "errors": [
    {
      "message": "Cannot return null for non-nullable field Block.id.",
      "locations": [
        {
          "line": 3,
          "column": 5
        }
      ],
      "path": [
        "blocks",
        0,
        "blockHash"
      ],
      "extensions": {
        "code": "INTERNAL_SERVER_ERROR",
        "exception": {
          "stacktrace": [
            "Error: Cannot return null for non-nullable field Block.id.",
            "    at completeValue (/application/node_modules/graphql/execution/execute.js:560:13)",
            "    at completeValueCatchingError (/application/node_modules/graphql/execution/execute.js:495:19)",
            "    at resolveField (/application/node_modules/graphql/execution/execute.js:435:10)",
            "    at executeFields (/application/node_modules/graphql/execution/execute.js:275:18)",
            "    at collectAndExecuteSubfields (/application/node_modules/graphql/execution/execute.js:713:10)",
            "    at completeObjectValue (/application/node_modules/graphql/execution/execute.js:703:10)",
            "    at completeValue (/application/node_modules/graphql/execution/execute.js:591:12)",
            "    at completeValueCatchingError (/application/node_modules/graphql/execution/execute.js:495:19)",
            "    at /application/node_modules/graphql/execution/execute.js:618:25",
            "    at Array.forEach (<anonymous>)"
          ]
        }
      }
    }
  ],
  "data": {
    "blocks": [
      null
    ]
  }
}

Sorry for the delay in response @islishude
Reopening, as it's a bug I need to investigate. The expectation is for the aliases to be remapped after the delegated response is returned from Hasura, since makeRemoteExecutableSchema should handle this.
On a side-node, the specific alias you're making here should be addressed in #175

Hello, @islishude and @rhyslbw. It seems that this issue still persists for<EMAIL_ADDRESS>Here is a sample query to reproduce it.
query (
  $where: Epoch_bool_exp
){
  epochs( where: $where ) {
    protocolParams {
      feeFixed: minFeeA
      feePerByte:minFeeB
    }
  }
}

The error message is the following.
{
  "errors": [
    {
      "message": "Cannot return null for non-nullable field ShelleyProtocolParams.minFeeA.",
      "locations": [
        {
          "line": 4,
          "column": 7
        }
      ],
      "path": [
        "epochs",
        0,
        "protocolParams",
        "feeFixed"
      ],
      "extensions": {
        "code": "INTERNAL_SERVER_ERROR",
        "exception": {
          "stacktrace": [
            "Error: Cannot return null for non-nullable field ShelleyProtocolParams.minFeeA.",
            "    at completeValue (/app/node_modules/graphql/execution/execute.js:560:13)",
            "    at completeValueCatchingError (/app/node_modules/graphql/execution/execute.js:495:19)",
            "    at resolveField (/app/node_modules/graphql/execution/execute.js:435:10)",
            "    at executeFields (/app/node_modules/graphql/execution/execute.js:275:18)",
            "    at collectAndExecuteSubfields (/app/node_modules/graphql/execution/execute.js:713:10)",
            "    at completeObjectValue (/app/node_modules/graphql/execution/execute.js:703:10)",
            "    at completeValue (/app/node_modules/graphql/execution/execute.js:591:12)",
            "    at completeValueCatchingError (/app/node_modules/graphql/execution/execute.js:495:19)",
            "    at resolveField (/app/node_modules/graphql/execution/execute.js:435:10)",
            "    at executeFields (/app/node_modules/graphql/execution/execute.js:275:18)"
          ]
        }
      }
    }
  ],
  "data": {
    "epochs": [
      {
        "protocolParams": null
      }
    ]
  }
}

This issue may be the culprit. ardatan/graphql-tools#3267

I will close this issue since it doesn't have any activities any more.
IF YOU NEED IT, PLEASE FILE A NEW ONE.


Animal brain templates can be applied to human races

As-is, an alpaca's brain template can be applied to a clone. The clone will get the hidden 'Brain Templated' hediff, and their brain won't be able to be modified in the future.

Also, human brain templates can be applied to animals. Fun!


Careers content

Perform the following tasks for the Careers page:

[ ] Review for content design principles
[ ] Get final accuracy approval from Christina/Alex
[ ] Load into CMS

This page has been eliminated per Christina.


Make python typing and linting errors be displayed in the PR review tab

Right now, if python linting/type checking fails, we need to go to the report in the workflow.
It would be ideal to have github formatted output showing up to files in the PRs on the lines that are not ok.

Hey @mihaimaruseac, I'd like to pick this up

We don't block issues on who declares to work on them, we just look at the PRs. Please feel free to work on it and I'm looking forward to the PR. Thank you

Hello @mihaimaruseac. I would like to work on this issue!

Awesome. Please see #293 and #295 as starting points, as those were made to make the test coverage visible in the PR review, something very similar to this.


Update Account.php for check redirect page after Register

I want use Register Modal in header page and after calling onRegister() method with ajax not refresh happened and i can see 'check your mail' message instead of redirect page, this change allow user
check 'redirect to' in user widget and if this field set to -no redirect- remain in modal and not redirect to any page.

I have no idea what you're saying. Please clearly explain exactly what this is doing and why it is required in more than one sentence.

in the case of my authentication-registeration works  via bootstrap modal in separated tabs and in  Account widget under  'Redirect to' select --no redirect-- option i expect the behavior no refresh page after register to show "check your mail" message to user in modal but when my register page is in separated  .htm page this works properly.

Closing as it has been over a month since any activity on this occurred and we are trying to figure out what issues are still relevant. If this is still something that you would like to see through to fruition please respond and we can get the ball rolling.


Suggested actions are not showing up after publishing to Microsoft Teams

Describe the bug
We designed a bot on Bot Framework Composer and we published the bot with EN-US local. It is successfully working on Teams. Nevertheless, we cannot see the suggested actions at any point on Teams. We can see and use suggested actions successfully on Composer WebChat and the Emulator.
Version
Version:  2.0.0
Electron: 8.2.4
Chrome: 80.0.3987.165
NodeJS: 12.13.0
V8: 8.0.426.27-electron.0
Browser

[ ] Edge

OS

[ ] Windows

To Reproduce
Steps to reproduce the behavior:

Create suggested actions on bot
Try on WebChat and Emulator, it will work properly with suggested actions
Publish your bot and add to Teams
Try on Teams.

Expected behavior
When tried on Teams, suggested actions are not showing up on our case. We want to be able to use them in Teams.
Screenshots
On Composer WebChat:

On Emulator:

On Teams:

Additional context

hi @eda-ayan
Suggested Actions aren't supported by Teams:
https://docs.microsoft.com/en-us/azure/bot-service/bot-service-channels-reference?view=azure-bot-service-4.0#action-support-by-channel


AADSTS50020: User account ... from identity provider 'live.com' does not exist in tenant and cannot access the application

I have created an app in Azure, set up the necessary callback URL, and selected accounts from any organizational directory (any Azure AD directory - multi-tenant) and personal Microsoft accounts (such as Skype, Xbox). However, when I try to log in to Azure AD from Casdoor, it still prompts me with the following message:
Message: AADSTS50020: User account<EMAIL_ADDRESS>from identity provider 'live.com' does not exist in tenant 'Default Directory' and cannot access the application '...' (Casdoor) in that tenant. The account needs to be added as an external user in the tenant first. Sign out and sign in again with a different Azure Active Directory user account.

casdoor version:   docker image: casbin/casdoor:v1.324.0

@AlgoLaser-Developer can you try the demo site at: https://door.casdoor.com/login ? I tried and it worked. 你可以试试演示网站：https://door.casdoor.com/login？我试过了，成功了。

You can also see docs about how to configure it: https://casdoor.org/docs/provider/oauth/azureAD您还可以查看有关如何配置它的文档：https://casdoor.org/docs/provider/oauth/azureAD

I have tried login your url by myself microsoft account, but i failed.

I think you are useing a build in account to login the abover url : https://door.casdoor.com/login


Automated cherry pick of #6616

Cherry pick of #6616 on release-5.28.
/cc  @lieut-data

Will try to auto merge this PR once all tests and checks are passing. This might take up to an hour.


Browser add request

Can you please add iOS browser called snowhaze? This browser is focused on privacy

duplicate of #104


[Game Crash] Crash when right clicking on an item tag group.

crash-2022-07-30_12.00.56-client.txt

Can not reproduce with just EMI, likely a mod compability issue.

This seems to only possible to occur if something prevented EMI from initializing, in which case EMI probably shouldn't have been able to interact with. Do you have any clue what scenario caused this?

Fixed in 0.3.1


Windows freeze

Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
go version go1.7.5 windows/amd64
What operating system and processor architecture are you using (go env)?
i3 CPU , 2 core, 2ghz
4gb mem
set GOARCH=amd64
set GOBIN=
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=F:\projects\go
set GORACE=
set GOROOT=C:\Go
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set CC=gcc
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0
set CXX=g++
set CGO_ENABLED=1
What did you do?
Run this code:
package main
import "fmt"
func counter(n int) {
for i := 0; i <= n; i++ {
println("i = ", i, " for n = ", n)
}
}
func main() {
for n := 0; n < 1000000; n++ {
	go counter(n)
}
var input string
fmt.Scanln(&input)

}
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
What did you expect to see?
Program crash or termination with an error
What did you see instead?
Windows/machine freeze
Must reset the computer

Hello @amienel, it looks like you exhausted your system's resources by running
1,000,000 goroutines that altogether count and print to standard output
500,001,500,001 times ie [x * (x+1)]/2 where x=1,000,001.
Just like almost every resource, goroutines aren't free and their control is left at the discretion of the programmer to pick from using synchronization primitives provided by Go, like sync.WaitGroup https://golang.org/pkg/sync/#example_WaitGroup or a buffered/bounded channel.
We use the issues page to track actual bugs in the standard library and family's code. For questions about Go, please see https://github.com/golang/go/wiki/Questions.
You can learn more about concurrency in Go and how to use/control it here https://tour.golang.org/concurrency. This might help you resolve your problem and get solutions
to taming and using concurrency in your code.


Added a new way to parse floats as a string

I noticed if you read a file with a high precision double in it like 0.094369298521547657, if you read a file into a JToken and then dump it back to a file, the value will be different. I'm working on building a library that reads and writes json files and it would be very nice if I could count on these values not changing. Because double and decimal don't have high enough precision, I propose that we add a new FloatParseHandling value of String so that we can support reading and writing these values without modifying them.
Is this change ok?
If so should I add some testing for this or make the modifications elsewhere?

@JamesNK Does this suggested change look ok and how do I get it approved? Thanks.

I found a better way to do this by reading everything in as a decimal and being careful to never try to convert it to a double, without needing changes to the library. Closing this PR.


Remove TARGET_NUMBER_OF_PEERS config variable

As implementor TARGET_NUMBER_OF_PEERS has been an awkward config variable that does not align with how the client's peer count is managed and controlled by the user. I understand its strong relevance in the context of DAS but it should not translate into it becoming a network config variable IMO.
The spec can recommend a safe peer count with words on the p2p section, which is what this PR switches to. Client devs are free to implement a warning log if users select a peer count that is less than this safe value.

closing in favor of #3870


TFCainClient: Send tokens API is broken

Installation information

jumpscale version: development_simple branch
operating system: ubuntu 18.04

Detailed description
The send_money API on the tfchain wallet is broken
Steps to reproduce
# open existing wallet or use create_wallet to create a new one
tftwallet = j.clients.tfchain.open_wallet('tftwallet')
In [7]: tftwallet.send_money(2, '012bdb563a4b3b630ddf32f1fde8d97466376a67c0bc9a278c2fa8c8bd760d4dcb4b9564cdea6f'
   ...: )
[Sun07 18:57] - RivineWallet.py   :182 :in.rivine.rivinewallet - INFO     - Current chain height is: 130528
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
/vagrant_data/threefoldtech/jumpscale_core/cmds/js_shell in <module>()
----> 1 tftwallet.send_money(2, '012bdb563a4b3b630ddf32f1fde8d97466376a67c0bc9a278c2fa8c8bd760d4dcb4b9564cdea6f')

/vagrant_data/threefoldtech/jumpscale_lib/JumpscaleLib/clients/blockchain/rivine/RivineWallet.py in send_money(self, amount, recipient, data, locktime)
    318                                                 sign_transaction=True,
    319                                                 custom_data=data,
--> 320                                                 locktime=locktime)
    321         self._commit_transaction(transaction=transaction)
    322         return transaction

/vagrant_data/threefoldtech/jumpscale_lib/JumpscaleLib/clients/blockchain/rivine/RivineWallet.py in _create_transaction(self, amount, recipient, minerfee, sign_transaction, custom_data, locktime)
    508
    509
--> 510         input_results, used_addresses, minerfee, remainder = self._get_inputs(amount=amount)
    511         for input_result in input_results:
    512             transaction.add_coin_input(**input_result)

/vagrant_data/threefoldtech/jumpscale_lib/JumpscaleLib/clients/blockchain/rivine/RivineWallet.py in _get_inputs(self, amount, minerfee)
    406         if minerfee is None:
    407             minerfee = self._minerfee
--> 408         wallet_fund = int(self.current_balance.unlocked_balance * HASTINGS_TFT_VALUE)
    409         required_funds = amount + minerfee
    410         if required_funds > wallet_fund:

/vagrant_data/threefoldtech/jumpscale_lib/JumpscaleLib/clients/blockchain/rivine/RivineWallet.py in unlocked_balance(self)
    760     @property
    761     def unlocked_balance(self):
--> 762         return sum(int(value.get('value', 0)) for value in self._unspent_coins_outputs.values()) / HASTINGS_TFT_VALUE
    763
    764     @property

AttributeError: 'WalletBalance' object has no attribute '_unspent_coins_outputs'

Fixed by: https://github.com/threefoldtech/jumpscale_lib/pull/183

Verified
In [27]: wallet = RivineWallet(seed=seed, bc_networks=['https://explorer.threefoldtoken.com/'],bc_network_password='test123',nr_keys_per_seed=5,minerfee=100000000)

In [28]: wallet.current_balance
[Mon08 13:03] - RivineWallet.py   :182 :in.rivine.rivinewallet - INFO     - Current chain height is: 120363
Out[28]:
Unlocked:

        2.0
In [30]: wallet.send_money(1,'01ab964983a59fa4efd4abca4c0576c4ad42dd40832f768551f9de829656e41cf0772d2287172c')                                                                               │···············································
[Mon08 13:08] - RivineWallet.py   :182 :in.rivine.rivinewallet - INFO     - Current chain height is: 120366                                                                                │···············································
[Mon08 13:08] - RivineWallet.py   :555 :in.rivine.rivinewallet - INFO     - Signing Transaction                                                                                │···············································
[Mon08 13:08] - utils.py          :244 :lockchain.rivine.utils - INFO     - Transaction committed successfully                                                                               │···············································
Out[30]: <JumpscaleLib.clients.blockchain.rivine.types.transaction.TransactionV1 at 0x7f4930f917b8>


Created Dataset Acknowledgement SOP

Related to #140

I'm just going to merge it and make any edits as I go


Add Huawei dongle

Needs connect delay and delay:
meters:
- name: grid # Huawei grid power import export (when smart power sensor is present)
  type: custom
  power:
    source: modbus
    timeout: 10s
    connectdelay: 5s
    delay: 2s
    model: huawei
    uri: <ip>:502
    id: 2
    register:
      address: 37113 # Grid import export power
      type: holding
      decode: int32
    scale: -1
  energy:
    source: modbus
    timeout: 10s
    connectdelay: 5s
    delay: 2s
    model: huawei
    uri: <ip>:502
    id: 2
    register:
      address: 37121 # Grid active energy
      type: holding
      decode: int32
    scale: 0.01
  currents:
  - source: modbus
    model: huawei
    uri: <ip>:502 # inverter port
    id: 2
    register:
      address: 37107 # Huawei phase A grid current
      type: holding
      decode: int32
    scale: -0.01
  - source: modbus
    model: huawei
    uri: <ip>:502 # inverter port
    id: 2
    register:
      address: 37109 # Huawei phase B grid current
      type: holding
      decode: int32
    scale: -0.01
  - source: modbus
    model: huawei
    uri: <ip>:502 # inverter port
    id: 2
    register:
      address: 37111 # Huawei phase C grid current
      type: holding
      decode: int32
    scale: -0.01
- name: battery
  type: custom
  power:
    source: modbus
    timeout: 10s
    connectdelay: 5s
    delay: 2s
    model: huawei
    uri: <ip>:502
    id: 2
    register:
      address: 37001
      type: holding
      decode: int32
  soc:
    source: modbus
    timeout: 10s
    connectdelay: 5s
    delay: 2s
    model: huawei
    uri: <ip>:502
    id: 2
    register:
      address: 37004
      type: holding
      decode: uint16
    scale: 0.1

Huawei grid power import export (when smart power sensor is present)

Das können wir nicht erkennen? Dann müssten das wohl ein extra Template werden

Smart power sensor is in essence a smart power meter, that has to be orderred and installed separately, so user would know if it is present or not.

I was tuning my config all night, and with this config EVCC runs fairly fast and no errors.
I am not using Energy meter at the moment, as I think its not needed for me, also please see here - Im not sure if thats the right register for it https://github.com/evcc-io/evcc/discussions/1928#discussioncomment-1976158
If currents is not utilised by evcc at the moment, probably good idea to not use it also, to speed everything up - perhaps advice users about it in template ?
Huawei grid and pv meters via Huawei Sdongle Modbus TCP connection:
meters:

- name: grid # Huawei grid import export power
  type: custom
  power:
    source: modbus
    timeout: 10s
    connectdelay: 1s
    model: huawei
    uri: <ip>:502
    rtu: false
    id: 1
    register:
      address: 37113 # Huawei import/export active power / IF Huawei smart power sensor is installed
      type: holding
      decode: int32
    scale: -1

#  energy:
#    source: modbus
#    delay: 1s
#    model: huawei
#    uri: <ip>:502
#    rtu: false
#    id: 1
#    register:
#      address: 37119 #  Grid active energy ???
#      type: holding
#      decode: int32
#    scale: 0.01

  currents:
    - source: modbus # Huawei phase A grid current
      timeout: 10s
      model: huawei
      uri: <ip>:502
      rtu: false
      id: 1
      register:
        address: 37107 # Huawei phase A grid current / IF Huawei smart power sensor is installed
        type: holding
        decode: int32
      scale: -0.01

    - source: modbus # Huawei phase B grid current
      timeout: 10s
      model: huawei
      uri: <ip>:502
      rtu: false
      id: 1
      register:
        address: 37109 # Huawei phase B grid current / IF Huawei smart power sensor is installed
        type: holding
        decode: int32
      scale: -0.01

    - source: modbus # Huawei phase C grid current
      timeout: 10s
      model: huawei
      uri: <ip>:502
      rtu: false
      id: 1
      register:
        address: 37111 # Huawei phase C grid current / IF Huawei smart power sensor is installed
        type: holding
        decode: int32
      scale: -0.01

- name: pv1 # Huawei Solar generation power
  type: custom
  power:
    source: modbus
    timeout: 10s
    connectdelay: 1s
    model: huawei
    uri: <ip>:502
    rtu: false
    id: 1
    register:
      address: 32080 # Active generation power
      type: holding
      decode: int32

Muss man die ID bearbeiten können? Was ist der Default?

My experience is with dongle - I have tried to set a different Inverter id in its menu, but it does not change, always goes back to default 1
It may change in the future though, as Huawei pumps out firmware updates often, and many of the updates have some sort of improvement for modbus.
Also, some people have more than one inverter, in that case dongle would issue next id number in line (my guess)

Ich gehe davon aus dass das SM (als Grid) spätestens mit Batteriespeicher obligatorisch ist.
currents werden spätestens für Lastmanagement interessant, daher durchaus überall schon rein damit wo einfach möglich.

 Nicht unbedingt. Für 70%-Abregelung kann das ja auch gebraucht werden.

Ne, ich meine das Template ohne Dongle, das braucht dann nur "PV". Denn die Batterie kann ja ohne nicht geregelt werden

Dongle is not needed to have battery in the system.
Power sensor (aka Grid meter) is necessary for the battery.

Yeah, but this configuration is for using Huawei inverters with the Sdongle only. At least this is what I understood

I think two separate templates make sense : grid (with power sensor) and pv (without power sensor)


Is there a way to switch between item programmatically?

I need to switch between bottom nav items programmatically. Has this feature been implemented?
I couldn't find anything about this.

just use setSelectedIndex() on the menu layout


Is the old version of protobuf-java (3.25.1) a hard requirement?

Basic information

Axon BOM version: 4.10

I have a problem with 3.25.1 being old, and other dependencies are starting to use 4 (com.netflix.graphql from the dgs framework)... is there a plan to upgrade, or can I pull in other deps to have it solved right now (since i noticed that there are some newer releases available than what the bom pulls).
Right now it seems that pinning the version to 3.25.1 solves it, but I guess one day it will be too old for other deps...

Thanks for nudging us the descrepancy you're facing with other dependencies, @magnusheino.
As you already show in your graph, Axon does not depend on the mentioned dependency, protobuf-java.
We use grpc-protobuf to do the communication between Axon Server and Axon Framework, and I would not recommend anybody change the protobuf-java version.
We simply cannot vouch for the workings of the grpc-protobuf version if you do, making it a decision we cannot make for others.
Although I understand protobuf-java is already at version 4.29.1, the latest grpc-protobuf version (1.69.0) is still on the latest 3.x version of protobuf-java, being 3.25.5.
So, if you're using Axon Server, there isn't that much I can suggest you to do, @magnusheino.
If you're not using Axon Server, you're free to exclude the axonserver-connector-java module from the dependencies.
Besides the rightful, yet unresolvable remark, I have changed the type of this issue from "bug" to "dependency upgrade," is this isn't a bug issue.
Furthermore, I'll keep this issue open, as we (obviously) do desire to go to a newer version.
We just have to wait until grpc-protobuf chooses to upgrade.
Concluding, sorry for any inconvenience here, @magnusheino, but I am afraid we're tied here.
If you do figure out, or know, a way around this, your input would be very much appreciated.

Ah nice, that's a relief to hear, @magnusheino!
And, of course, glad to help out!!
Given that the issue's resolved for you and (I agree with you hear) the likely chance that grpc-protobuf will eventually upgrade as well, I trust that our dependabot settings will do the rest.
As such, I feel comfortable enough to close the issue for now.
If something changes concerning this topic, I'll be sure to reopen this ticket.


Overlay / ingress network routing breaks on service restart

Description
Overlay / ingress network routing breaks on service restart. I was able to reproduce this on in docker swarm mode on a swarm with 5 nodes and on a different swarm with 3 nodes, both running Ubuntu 16.04 and docker  1.12.1.
Steps to reproduce the issue:
When deploying a service for the first time for a port, the service is available from all nodes in a swarm
docker service create -p 84:80 --name httpd4 httpd

root@swarm2 ~ # curl http://swarm1:84

It works!

root@swarm2 ~ # curl http://swarm5:84

It works!

(works as expected)
However, now when I do
root@swarm2 ~ # docker service rm httpd4
and then
root@swarm2 ~ # docker service create -p 84:80 --name httpd4 httpd

root@swarm2 ~ # docker service ps httpd4
ID                         NAME      IMAGE  NODE              DESIRED STATE  CURRENT STATE               ERROR
6avk26h1ks9xs7ovywas0klta  httpd4.1  httpd  swarm5            Running        Running about a minute ago

root@swarm2 ~ # curl http://swarm1:84
curl: (7) Failed to connect to swarm1 port 84: Connection timed out

root@swarm2 ~ # curl http://swarm5:84

It works!

Describe the results you received:
root@swarm2 ~ # curl http://swarm1:84
curl: (7) Failed to connect to swarm1 port 84: Connection timed out

Describe the results you expected:
root@swarm2 ~ # curl http://swarm1:84

It works!

Additional information you deem important (e.g. issue happens only occasionally):
Output of docker version:
Client:
 Version:      1.12.1
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   23cf638
 Built:        Thu Aug 18 05:33:38 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.1
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   23cf638
 Built:        Thu Aug 18 05:33:38 2016
 OS/Arch:      linux/amd64

Output of docker info:
Containers: 3
 Running: 2
 Paused: 0
 Stopped: 1
Images: 5
Server Version: 1.12.1
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 43
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: overlay bridge null host
Swarm: active
 NodeID: dvj6xuikc39a6it98sywz7ckk
 Is Manager: true
 ClusterID: 389htp3t8ruwg4e1cjzg0pg3b
 Managers: 5
 Nodes: 5
 Orchestration:
  Task History Retention Limit: 5
 Raft:
  Snapshot Interval: 10000
  Heartbeat Tick: 1
  Election Tick: 3
 Dispatcher:
  Heartbeat Period: 5 seconds
 CA Configuration:
  Expiry Duration: 3 months
 Node Address: <IP_ADDRESS>
Runtimes: runc
Default Runtime: runc
Security Options: apparmor seccomp
Kernel Version: 4.4.0-36-generic
Operating System: Ubuntu 16.04.1 LTS
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 62.75 GiB
Name: swarm2.ascora.eu
ID: UPSO:UJ57:XQVJ:VU7M:GP7Q:XP5O:VPLR:FEYH:AXHX:ZNWC:WVAJ:UDOV
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Insecure Registries:
 <IP_ADDRESS>/8

Additional environment details (AWS, VirtualBox, physical, etc.):
5 physical nodes (all master) in docker swarm mode. I also reproduced this in a swarm mode with 3 other physical nodes. All running Ubuntu 16.04LTS

I think it's the same problem https://github.com/docker/docker/issues/24496

Yes, indeed it looks like being the same problem. :-(

@ascora I have another suggestion.
The way you are instantiating the service it is using the default ingress network.
Instead try first to create another overlay network
docker network create --driver overlay my_net
Then create your services in it (same as you did) but just add --network my_net in the service create.
Then you will be able to access your services/replicas on their names in it.
The ingress is just for handling -p (e.g the NAT between the external world and your service) and not for intraservice or interservice communication.
In ingress the interservice communications works only if you have two containers from two different services on the same swarm node. I assume the restart just shuffle that pattern in your case (e.g moved some containers on another node) and thus it stopped working.

This may be a duplicate of https://github.com/docker/docker/issues/25395.
/cc @mrjana

@niau Yes I know this but this is also what I want to do. The httpd should be available via port 84 to the outside world. even if I do a curl from another PC using the full domain name, I havbe the same results and also from a webbrowser.

@ascora the way I am telling you to set it up will indeed allow you to have :84 available from the outside world. It will attach the ingress and also your new network to your containers. It will create you also two VIPs.
However I agree that the fact that from outside you can reach the VIP of one of the services and you can't reach the same on another does not look good.
Just curious have you checked your iptables nat table rules? Do they you look the same for both of your services?
Also why do you have two different services publishing the same external port or those are two replicas of the same service?

Hi @niau
I just tried it with
docker network create --driver overlay my_net
docker service create -p 84:80 --network my_net --name httpd4 httpd
but the result is the same.
I only executed the command
docker service create -p 84:80 --name httpd4 httpd
(without the additional overlay network)
on one of the master nodes in the docker swarm and without a replica number or a global service. the
docker service ps httpd4
also shows that it's only running on 1 node:
However, my understanding is that the ingress network should still make it awaylable from all external URLs, i.e.
http://swarm1.domain.com:84 or http://swarm2.domain.com:84 ... or http://swarm5.domain.com:84
no matter where the service is physically running.
This also worked fine in the beginning when I used docker network create  the first time and I also got 2 old containers which are still running (1 with kibana deployed), which work perfectly fine this way on exactly the same docker swarm mode cluster.
I just executed
iptables -t nat -L
and
netstat --tcp --udp --listening --program | grep dockerd
on all 5 nodes on the swarm.
"docker service ps httpd4" shows that the service is currently deployed on swarm2. As before http://swarm2.domain.com:84 works fine and the others give a timeout.
Results:
Both iptables and netstat have different lines on almost all nodes and show ports from services running and from swervices that I have removed days ago via "service rm ..."
The netstat command contains
tcp6       0      0 [::]:84                 [::]:*                  LISTEN      6085/dockerd
on 4 of the 5 nodes but not for "swarm5".  "docker node ls" shows me that swarm 3 is the leader
The iptables command contains
DNAT       tcp  --  anywhere             anywhere             tcp dpt:84 to:<IP_ADDRESS>:84
on 4 of the 5 nodes but not for "swarm5".

A short update: I restarted the docker service on swarm5 and the
tcp6 0 0 [::]:84 [::]:* LISTEN 6085/dockerd
and
DNAT tcp -- anywhere anywhere tcp dpt:84 to:<IP_ADDRESS>:84
are now shown on all services. However, the availability of the service from the outside world did not change.

@ascora I by mistake interpreted the different names of your swarm nodes as different services. So yes your assumption to expect port 84 to be available everywhere is correct.
Without the iptables rule being created it simply won't work.
For the fact that swarm did not cleaned up the iptables rules I can't comment. It might be per design or simply a bug.
My previous suggestion would improve your inter service connectivity inside the swarm.
I have also tested #26530 the service got removed and iptables rules disappeared after a couple of seconds. Obviously recreating the service and accessing it from the outside also pass without any issue. If that helps I did the test with 1.13 build from the master a couple of days ago.

@niau When you performed your test described in "...tested #26530 the service got removed and iptables rules disappeared...," what did the cluster look like? How many nodes / managers / workers? What OS?
For context, I spent the morning testing #26530 on a bunch of different swarm configurations using different numbers of nodes in different states and on different operating systems.

@tnbeatty
Environment:
In short Ubuntu 16.04 with iptables and inactive ufw. The docker build I am using is identical to that pull request https://github.com/docker/docker/pull/25437 done by our team. I would say that in terms of what you are dealing with here you can consider it as quite a recent build close to the current MASTER with minor change unrelated to this test.
niau@docker-swarm-head-1:~$ docker version
Client:
 Version:      1.13.0-dev
 API version:  1.25
 Go version:   go1.7
 Git commit:   047edcd
 Built:        Fri Sep  2 09:29:13 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.13.0-dev
 API version:  1.25
 Go version:   go1.7
 Git commit:   047edcd
 Built:        Fri Sep  2 09:29:13 2016
 OS/Arch:      linux/amd64

niau@docker-swarm-head-1:~$ docker info
Containers: 5
 Running: 1
 Paused: 0
 Stopped: 4
Images: 7
Server Version: 1.13.0-dev
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 33
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local azurefile
 Network: bridge host null overlay overlay
Swarm: active
 NodeID: 7p1ab5vhjax085liyxlrrkfl6
 Is Manager: true
 ClusterID: b9sxgfffc4pk274xhyylvyeqg
 Managers: 1
 Nodes: 2
 Orchestration:
  Task History Retention Limit: 5
 Raft:
  Snapshot Interval: 10000
  Heartbeat Tick: 1
  Election Tick: 3
 Dispatcher:
  Heartbeat Period: 5 seconds
 CA Configuration:
  Expiry Duration: 3 months
 Node Address: <IP_ADDRESS>
Runtimes: runc
Default Runtime: runc
Security Options: apparmor seccomp
Kernel Version: 4.4.0-36-generic
Operating System: Ubuntu 16.04.1 LTS
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 27.48 GiB
Name: docker-swarm-head-1
ID: CZFA:OXKQ:K6OD:4TMK:BRT6:5FXD:6NUE:JG5I:XKNV:J6AJ:5DLA:QK3R
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Insecure Registries:
 <IP_ADDRESS>/8
Live Restore Enabled: false

niau@docker-swarm-head-1:~$ docker node ls
ID                           HOSTNAME             STATUS  AVAILABILITY  MANAGER STATUS
7p1ab5vhjax085liyxlrrkfl6 *  docker-swarm-head-1  Ready   Active        Leader
d2ey7oaxba1o6bqlwnavomb7p    docker-swarm-node-1  Ready   Active

Experiment start:
0.  Create a new service. It is equal to my production setup.
docker service create -e PARENT_DOMAIN=%.%.nms_net --mount type=volume,source=volnms1,target=/vol,readonly=false --network nms_net --name nms1 --hostname nms1 -p 8081:80/tcp -p 2221:22/tcp nms:hostanme

As a result in iptables I got that on both nodes.
Chain DOCKER-INGRESS (2 references)
target     prot opt source               destination
DNAT       tcp  --  <IP_ADDRESS>/0            <IP_ADDRESS>/0            tcp dpt:2221 to:<IP_ADDRESS>:2221
DNAT       tcp  --  <IP_ADDRESS>/0            <IP_ADDRESS>/0            tcp dpt:8081 to:<IP_ADDRESS>:8081
RETURN     all  --  <IP_ADDRESS>/0            <IP_ADDRESS>/0
niau@docker-swarm-head-1:~$ telnet <IP_ADDRESS> 8081
Trying <IP_ADDRESS>...
Connected to <IP_ADDRESS>.
Escape character is '^]'.
Connection closed by foreign host.
niau@docker-swarm-head-1:~$ telnet <IP_ADDRESS> 8081
Trying <IP_ADDRESS>...
Connected to <IP_ADDRESS>.
Escape character is '^]'.

Otherwise the container went to the node and is not on the manager
niau@docker-swarm-node-1:~$ docker ps
CONTAINER ID        IMAGE                         COMMAND                  CREATED             STATUS              PORTS                               NAMES
0cf27f65e95d        nms:hostanme   "/bin/sh -c /sbin/..."   2 minutes ago       Up 2 minutes        22/tcp, 80/tcp, 162/tcp, 9996/udp   nms1.1.5gwxrm44zvsue2mgj7ttb56gs

Delete the service. Iptables were deleted from the tables on both nodes after approximately 10-15 seconds.
2. Repeat the experiment by recreating the service.
This time lets also kill the container just for curiosity.
niau@docker-swarm-node-1:~$ docker kill 0cf27f65e95d
0cf27f65e95d
niau@docker-swarm-node-1:~$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

The container went to head-1 (master).
niau@docker-swarm-head-1:~$ docker ps
CONTAINER ID        IMAGE                         COMMAND                  CREATED              STATUS              PORTS                               NAMES
2fd295ddb211        nms:hostanme   "/bin/sh -c /sbin/..."   About a minute ago   Up About a minute   22/tcp, 80/tcp, 162/tcp, 9996/udp   nms1.1.cvqoddbmqkz1ywnyrw14545gv

Iptables stayed intact on both nodes. Connectivity internally to the service from other services and from external to the VIP was fine.
Then I moved the container to the node again by killing it.  Everything worked as expected.
I have deleted the service. Iptables rules disappeared after 10-15 seconds from both nodes.

Same but do a reboot on the node with the active container. This time I have rebooted the whole node.

Once it came back up iptables rules were good and same as before. Connectivity was also fine.
Then delete the service and watch the iptable rules
watch sudo iptables -L -t nat -n

The result was that the rules disappeared from the head node and remained on the other node....
---> Strange (that might be the issue you sow )...
However was it service affecting and will it cause me trouble if I try to recreate the service?

Repeat the same (create the service, try to access it from outside, checked the iptables rules) etc. All worked well and looked good. Then delete the service again. This time the iptables rules disappeared from both nodes.

Cool let's repeat the same with the restart of the node with the active container. Create a service, reboot the second node. Verify that it works before and after keep an eye on iptables rules. All is good.
Move the container to the rebooted node by killing it from the active.

AGAIN iptables VIP rules got deleted from the head and stayed on the rebooted node. ->> So that most likely is a bug.
So in the end if I can summarize. In normal operations service removal deletes the iptables rules. If the node got restarted and then a service is deleted iptables rules might disappear from the master node but will stay on the rebooted node. If then a service is recreated this is not affecting it. The container from it will work on that node also on other nodes.

@niau Thanks for your thorough writeup. This is very helpful. I followed your procedure exactly using Ubuntu 16.04 and again on 14.04, each with the following environment:
tnb@ubuntu-01:~# docker version
Client:
 Version:      1.12.1
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   23cf638
 Built:        Thu Aug 18 05:33:38 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.1
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   23cf638
 Built:        Thu Aug 18 05:33:38 2016
 OS/Arch:      linux/amd64

tnb@ubuntu-01:~# docker node ls
ID                           HOSTNAME            STATUS  AVAILABILITY  MANAGER STATUS
3vd7gk28h9df85y7zv938l4r6    ubuntu-1gb-nyc1-02  Ready   Active
evr8ilg0pctvw0xsmhfq6rkyo *  ubuntu-1gb-nyc1-01  Ready   Active        Leader

The system with two nodes (one swarm manager, one swarm worker) functions exactly as you described above. Creating and removing services and publishing and un-publishing ports create and remove iptables results appropriately.
I wrote up the following description / ticket to corroborate @ascora's ticket and confirm that it is, indeed, an issue on a large swarm similar to his infrastructure, but not an issue on two-node experimental swarms as you described above.
NOTE: I have not ruled out the possibility of the issue being fixed in 1.13. I have no evidence to suggest that it might be fixed on a 5 or 6 node cluster, although that is certainly possible.
My Experiment
I encounter the problem that @ascora described when running his experiment on a larger swarm, with 6 nodes (3 managers, 3 workers).
Steps to reproduce
I ran the following experiment, similar to what he wrote above:

Create three services:

web frontend with option --publish 80:8080
node backend with option --publish 4000
mongo database with option --publish 27017

Inspect the services to see what port mappings were created with docker service inspect <name>

Discover that Docker had mapped port 30000 to my node backend and 30001 to my database

Remove each service with docker service rm <name>

Describe the results you received
After following the series of steps similar to what he described above and then coming back to my computer a long time later (hours - after a few meetings at the office), I performed the following:
root@ivr:~# docker node ls
ID                           HOSTNAME         STATUS  AVAILABILITY  MANAGER STATUS
2esbylk9a1uyu3zilbxdsm4gw    ivr.swworker.1   Ready   Active
2mdmm24c9rla37jmy3m254f5d    ivr.swmanager.2  Ready   Active        Reachable
8ckmxhkxivy0sshdqhaif47ye    ivr.swmanager.1  Ready   Active        Leader
ayoy8jhk5t4jv9ahaylyhqm3l *  ivr.swmanager.0  Ready   Active        Reachable
dc0nn2fixi3jcwowghru1c5nh    ivr.swworker.2   Ready   Active
empyhmijk34iewdeb3kj3diu0    ivr.swworker.0   Ready   Active

root@ivr:~# docker service ls
ID  NAME  REPLICAS  IMAGE  COMMAND

root@ivr:~# sudo iptables -L -n -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
DOCKER-INGRESS  all  --  <IP_ADDRESS>/0            <IP_ADDRESS>/0            ADDRTYPE match dst-type LOCAL
DOCKER     all  --  <IP_ADDRESS>/0            <IP_ADDRESS>/0            ADDRTYPE match dst-type LOCAL

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
DOCKER-INGRESS  all  --  <IP_ADDRESS>/0            <IP_ADDRESS>/0            ADDRTYPE match dst-type LOCAL
DOCKER     all  --  <IP_ADDRESS>/0           !<IP_ADDRESS>/8          ADDRTYPE match dst-type LOCAL

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  <IP_ADDRESS>/0            <IP_ADDRESS>/0            ADDRTYPE match src-type LOCAL
MASQUERADE  all  --  <IP_ADDRESS>/16        <IP_ADDRESS>/0
MASQUERADE  all  --  <IP_ADDRESS>/16        <IP_ADDRESS>/0

Chain DOCKER (2 references)
target     prot opt source               destination
RETURN     all  --  <IP_ADDRESS>/0            <IP_ADDRESS>/0
RETURN     all  --  <IP_ADDRESS>/0            <IP_ADDRESS>/0

Chain DOCKER-INGRESS (2 references)
target     prot opt source               destination
DNAT       tcp  --  <IP_ADDRESS>/0            <IP_ADDRESS>/0            tcp dpt:30000 to:<IP_ADDRESS>:30000
DNAT       tcp  --  <IP_ADDRESS>/0            <IP_ADDRESS>/0            tcp dpt:80 to:<IP_ADDRESS>:80
DNAT       tcp  --  <IP_ADDRESS>/0            <IP_ADDRESS>/0            tcp dpt:30001 to:<IP_ADDRESS>:30001
RETURN     all  --  <IP_ADDRESS>/0            <IP_ADDRESS>/0

Describe the results you expected
The concerning lines in the output above are:
Chain DOCKER-INGRESS (2 references)
target     prot opt source               destination
DNAT       tcp  --  <IP_ADDRESS>/0            <IP_ADDRESS>/0            tcp dpt:30000 to:<IP_ADDRESS>:30000
DNAT       tcp  --  <IP_ADDRESS>/0            <IP_ADDRESS>/0            tcp dpt:80 to:<IP_ADDRESS>:80
DNAT       tcp  --  <IP_ADDRESS>/0            <IP_ADDRESS>/0            tcp dpt:30001 to:<IP_ADDRESS>:30001

which indicate that the ports allocated to my services were never removed. I expected those lines to be absent.

ping @aboch @mrjana PTAL

A short follow-up information to my test: I just left the swarm with 4 nodes and then forced the final node to leave. I then flushed all ip table rules because they still existed using "iptables -t nat -F".
Afterwards I created a new swarm wich "docker swarm init" and joined with all nodes.
Now having a "fresh" swarm I can create the service again with the same command:
"docker service create -p 84:80 --name httpd4 httpd"
This works fine now and the service is available via http from all nodes.
I assume that it would break again as soon as one of the nodes needs to reboot as this seems to cause the problem (as described in https://github.com/docker/docker/issues/24496 )

@ascora It seems to be that you are getting into this problem after a node reboot. If that is so, this issue is fixed in docker master. If you can, can you try docker master and see if your problem is gone?

@mrjana That's not so easy in this case because the servers also run some "traditional" / non-swarm containers as productive systems so I'm a bit scared to use the master. I assume that it will be included into 1.12.2? Do you have an idea on when 1.12.2 will probably be released?

@ascora Yes this fix will be included in 1.12.2 whenever that happens. We don't have a good release date for that yet.

It seems to be that you are getting into this problem after a node reboot. If that is so, this issue is fixed in docker master.

@mrjana do you mind sharing what is the change merged into master that fix the restart issue? I would like to backport it on top of 1.12 branch if possible.

@dangra #25962 brought the fix to master but it may not be easy to back port that particular change on top of 1.12

@mrjana I have now tested it with the current master but the problem still exists. I used 3 fresh servers.
Here is my test:

I got 3 servers from digitalocean with fresh ubuntu 16.04 LTS installed.
I then installed docker 1.12.1 on it and created a new swarm with docker swarm init with all 3 servers
I then did a docker service create -p 84:80 --name httpd4 httpd. This worked fine and I was able to reach the httpd via port 84 from all node addresses. The request was routed to the service correctly
docker node ls shows that swarmtest1 was the master so I rebooted this node.
After the node came back online I did a docker service rm httpd4 and checked the iptables. the NAT rule  tcp dpt:84 to:<IP_ADDRESS>:84 still existed altough the services had been removed.
I tried a new docker service create -p 84:80 --name httpd4 httpd. The service was deployed but not eachable from the outside world via port 84.

Now I tested it with the current master. I stoped the old v1.12.1 service and removed all iptable rules with iptables -t nat -F
Then installed and started this one:
`# docker version
Client:
Version:      1.13.0-dev
API version:  1.25
Go version:   go1.7.1
Git commit:   61639bf
Built:        Fri Sep 16 20:01:11 2016
OS/Arch:      linux/amd64
Server:
Version:      1.13.0-dev
API version:  1.25
Go version:   go1.7.1
Git commit:   61639bf
Built:        Fri Sep 16 20:01:11 2016
OS/Arch:      linux/amd64
`

I then did a docker service create -p 84:80 --name httpd4 httpd. This worked fine and I was able to reach the httpd via port 84 from all node addresses. Hooray.
I rebooted one node
I stoped the service with docker service rm.
I checked the NAT rules. Again, tcp dpt:84 to:<IP_ADDRESS>:84 is still there
I can create a  docker service create -p 84:80 --name httpd4 httpd but it's not reachable from any IP address.

What surprises me: I now tried cresting the service on a new and unused port:
docker service create -p 86:80 --name httpd6 httpd
However, again, I cannot reach it via port 86 from any of the 3 IP addresses. docker service ps shows me that it's running on one of the nodes.

@mrjana I was able to re-produce the problem even without the restart of a node. I only deployed a new httpd service and executed
wrk -t30 -c400 -d30 http://...
several times.

A new follow up: I created 3 new servers. This time with a fresh CoreOS 1163.1.0 on it from Digitalocean. I then created a swarm init and did the following:
docker service create -p 80:80 --name httpd httpd
wrk -t30 -c400 -d30 http://138....
docker service rm httpd
Now sudo iptables -t nat -L still lists the ports on 1 of the 3 servers.
docker service create -p 80:80 --name httpd httpd
This works but is not reachable on 1 server via http

@ascora If you are seeing a problem even without a node restart this is probably not the same issue as the one fixed by #25962. Do you mind post a gist of daemon logs or just attach here from the nodes where you are having a problem? Also when you said you had a 3 node cluster how many of them were managers ?

@ascora I suspect that you are undergoing a gossip failure and the nodes aren't recovering properly. This will be confirmed by looking at the daemon logs on the nodes which are having routing issues. There is a PR in the works to fix this here docker/libnetwork#1446 if that is indeed your issues.
Nevertheless we need to understand the reason for the gossip to fail in the first place. Is your DO nodes in the same region or different region? What would be your packet latency between these nodes?

Sure. I've attached them. They also contain the corresponding output of iptables.
Since my last post I launched 2 more servides on them:
log.swarmnode3.txt
log.swarmnode1.txt
log.swarmnode2.txt

@mrjana I forgot to mention that all 3 nodes are managers. They are all in the same region of digitalocean (all in frankfurt) with a ping <2ms between them

@ascora Yes as I suspected you are having network issues in your cluster
Sep 19 16:44:00 coreosswarm1 dockerd[1268]: time="2016-09-19T16:44:00.549263678Z" level=error msg="Bulk sync to node coreosswarm3 timed out"
Sep 19 16:44:00 coreosswarm1 dockerd[1268]: time="2016-09-19T16:44:00Z" level=info msg="Firewalld running: false"
Sep 19 16:44:20 coreosswarm1 dockerd[1268]: time="2016-09-19T16:44:20.515949534Z" level=warning msg="2016/09/19 16:44:20 [ERR] memberlist: Failed TCP fallback ping: read tcp <IP_ADDRESS>:47296-><IP_ADDRESS>:7946: i/o timeout\n"
Sep 19 16:44:28 coreosswarm1 dockerd[1268]: time="2016-09-19T16:44:28.554542372Z" level=info msg="2016/09/19 16:44:28 [INFO] memberlist: Marking coreosswarm2 as failed, suspect timeout reached\n"
Sep 19 16:44:30 coreosswarm1 dockerd[1268]: time="2016-09-19T16:44:30Z" level=info msg="Firewalld running: false"
Sep 19 16:46:10 coreosswarm1 dockerd[1268]: time="2016-09-19T16:46:10.515188602Z" level=warning msg="2016/09/19 16:46:10 [ERR] memberlist: Failed TCP fallback ping: read tcp <IP_ADDRESS>:47320-><IP_ADDRESS>:7946: i/o timeout\n"
Sep 19 16:46:10 coreosswarm1 dockerd[1268]: time="2016-09-19T16:46:10.516121525Z" level=info msg="2016/09/19 16:46:10 [INFO] memberlist: Suspect coreosswarm3 has failed, no acks received\n"
Sep 19 16:46:12 coreosswarm1 dockerd[1268]: time="2016-09-19T16:46:12.515281125Z" level=warning msg="2016/09/19 16:46:12 [ERR] memberlist: Failed TCP fallback ping: read tcp <IP_ADDRESS>:47324-><IP_ADDRESS>:7946: i/o timeout\n"
Sep 19 16:46:12 coreosswarm1 dockerd[1268]: time="2016-09-19T16:46:12.517969412Z" level=info msg="2016/09/19 16:46:12 [INFO] memberlist: Suspect coreosswarm3 has failed, no acks received\n"

Even TCP pings are timing out. That is the source of your trouble. We need to understand why this is happening.

@mrjana Can I do anything to provide more info about this?
Essentially I can reproduce it when putting a lot of http load to the new servers:
wrk -t60 -c800 -d30 http://...
I can even reproduce this with full new servers on both Ubuntu and CoreOS.
Would the docker/libnetwork#1446 fix this once released?
I assume that for the time being it's better to have only 1 manager in the production swarm?

@ascora  would be interesting to monitor the amount of traffic gossip is creating in your production cluster with one and with multiple managers under the test you are doing.
A good way to do that is to try to export sflow from the linux box or maybe simpler to capture a dump with full snaplength and use the IO Graph of wireshark.
Btw very good finding for the test I did above there was no traffic involved at all. Soon we will also load our clusters. In our case it might be quite a lot of incoming and outgoing UDP so I guess life will be interesting :)

@ascora docker/libnetwork#1446 definitely fixes a problem in cluster recovery after a gossip failure has happened. But I am trying to characterize what is causing the failure. From your logs I can see that, at the same time gossip failed, the managers under went leader election as well so something became flaky in the underlying network. I am just not sure if swarm cluster is causing this flakiness or is it inherent in the infrastructure you are using. One way to get more data point is to run the same test with a single manager configuration and see how it goes.

@ascora I missed the fact that you are in fact doing http load testing. That may be causing the network flakiness your are experiencing. Do you know how much overall network bandwidth utilization it creates? Actually I will try to do some http load testing in my cluster as well.

@mrjana Yes, that's right. The problem is easily reproducable for me if I do the load testing with wrk using 60 threads and 800 connections over a period of 30 seconds. I do the test against 2 nodes of the 3 node cluster and after 1 or 2 times, the problem appears.
I'm not sure what the best way is to measure the bandwith utilization but since the servers are fresh, there should only be the 2 wrk network loads (i.e. 2 times 60 threas and 800 connections)

@mrjana you wrote:

One way to get more data point is to run the same test with a single manager configuration and see how it goes.

I did this now with a fresh set of 3 servers and I was able to reproduce the problem again. I have attached the logs. It only has 1 manager and I only deployed a fresh httpd service via
docker service create -p 80:80 --name httpd httpd
I then did 3  parallel
wrk -t70 -c800 -d30 http://...
from an external server to each of the 3 nodes.
Afterwards I did a docker service rm httpd and then I waited a few seconds and re-created the service.
I can invoke the service now on 2 IPs but not on the third.
logs.coreos-newswarm1-manager.txt
logs.coreos-newswarm2-worker.txt
logs.coreos-newswarm3-worker.txt

@ascora Yes, I do see gossip failures again this time and that is still the cause of your problem.

However, this should of course not make the whole swarm unstable - at least not after the wrk load test is finished. ;-)

Yeah there is a problem with gossip which fails to recover properly after a failure and is fixed already in docker/libnetwork#1446 but I was trying to see why you are getting into that situation. From your logs even TCP pings fail. Even with the kind of http load testing that you are doing it should not consume that much bandwidth.
I tried myself on a DO cluster repeating exactly your sequence of tests and wasn't able to reproduce. But I was using docker/docker master code with the above fix included and I was using nodes in San Francisco region. I might try Frankfurt region nodes today.
One thing I noticed (which I also did to make the problem reproducible but still could not) is that you are using DO's public network IPs to form the cluster. I am not sure how DO sets up its networking but using the public network for raft and gossip traffic could cause more flakiness in general. If you move your cluster to a private network within DO datacenter may be the flakiness will disappear. I can't confirm any of this because I wasn't able to reproduce the flakiness at all in my end.

@mrjana For my quick tests I used the frankfurt one with CoreOS alpha which includes docker v1.12.1 and I have chosen 3 of the 10$ machines.

@ascora I gave Frankfurt ones a try and I couldn't repro the problem there as well. What I was hoping for is to be able to see the gossip failures which we recover from with the fix in docker/libnetwork#1446 but I didn't even see the gossip failures even after trying the http load test several times.

@mrjana What's the best way to provide you access to 3 test machines?

@mrjana I created 3 new machines and was able to re-produce it. I emailed you the access to them. Please let me know if you received my email.

@ascora Would you be able to retry on a 1.12.2-rc1 when it comes out? Thanks

Yes, sure.

I am seeing this problem now too with 1.13 dev builds. I have not seen it in my setup in older versions. At least not consistently.
With a fresh 1.13.0-dev build from today I see it very reproducable that the port is not open on some hosts.
Setup is 3 nodes and all 3 nodes are manager nodes. If I reduce it to 1 manager only, it looks much better. In the few tests with 1 manager only, it was working without problems and the port was always up on all 3 nodes.

ping @mrjana PTAL ^^

@mschirrmeister I was checking logs from your machine(thanks to you providing access) and you are not having any gossip failures in your nodes(which you were having before) so you are probably not having the same issue.
However if you are still seeing issues can you give me more details. When you say the port is not open on some hosts are saying that because you are not able to connect to those ports in those nodes? If yes, if you try to connect to those ports (using tools like curl if it is http) do you see Connection refused` error or some other error?
If you are seeing Connection refused error can you please execute the following command in all of your nodes and try again:
sudo nsenter --net=/var/run/docker/netns/ingress_sbox ipvsadm -L

Can you please let me know if running these commands make the problem go away? If yes, it may be a totally different issue in a Centos 3.10 kernel with some backported patches.

@mrjana Yes, I am not able to connect to the ports on those hosts. Yes, when I do a curl I get Connection refused. That is because nothing is listening on the port.
I recreated the problem again. Promoted the 2 none managers to managers again, so that all 3 nodes are managers. Rebooted all hosts, started docker and created a service. And also scaled it to 3.
docker service create --name service1 -p 30000:8000  jwilder/whoami

I could run nsenter --net=/var/run/docker/netns/ingress_sbox ipvsadm -L only on the current leader node, because /var/run/docker/netns/ingress_sbox only exists on the leader.
The output of that command was the following.
[root@azeausdockerapps303t ~]# nsenter --net=/var/run/docker/netns/ingress_sbox ipvsadm -L
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
FWM  256 rr
  -> <IP_ADDRESS>:0                 Masq    1      0          0
  -> <IP_ADDRESS>:0                 Masq    1      0          0
  -> <IP_ADDRESS>:0                 Masq    1      0          0

I left it in this state now. You can look at it, if you want.

@mschirrmeister Thanks. Found the issue for what is causing ingress-sandbox creation to not happen in your cluster. Will fix it. If you destroy your swarm cluster and recreate a fresh swarm cluster it will most likely work for you. But a fix for your issue will be available soon.

@mrjana I destroyed the swarm cluster yesterday already. Basically I wiped /var/lib/docker. I did then a few promotions and demotions of managers. Was doing this as tests for this and my other ticket. Maybe related to those things?

@mschirrmeister The specific sequence I believe led to this is you promoted all workers to managers and then you rebooted all the nodes and they all booted and started docker at more or less the same time which resulted in this race.

@mrjana You are right. I was always trying to start the daemon at the same time. Manually.
I was hoping or trying to figure out if the cluster mechanisms can handle that.
I guess you now know how to fix this race condition.
You can do btw whatever you want in the nodes. In case you want to experiment.

This is not critical for me at this time, however I can confirm that I have what appears to be the same issue. Docker version 1.12.1, build 23cf638.

Still seeing the issue (not being able to connect containers on different machines when there are 3 managers) in 1.12.2.rc3
Demoting 2 managers helps.

@Vanuan Can you attach the daemon logs from where you are seeing the problem?

I'm having this issue as well with Docker version 1.12.2, build bb80604, experimental
Two nodes, one master one worker. Two services, one is web, one is redis. I've created them using the recent docker deploy mydabfile, but I suspect this has nothing to do with it.
The nodes have been created in mac like so :
docker-machine create -d virtualbox node-1
eval $(docker-machine env node-1)
docker swarm init --advertise-addr=eth1
docker-machine create -d virtualbox node-2
eval $(docker-machine env node-2)
docker swarm join --token <token> <ip>:<port>

I have this :
% docker service ls                                                                     playground/composetest MacBook-Pro-de-Michael
ID            NAME               REPLICAS  IMAGE                                                                                COMMAND
0w105zrjlna1  composetest_web    2/2       gobadiah/web@sha256:5b61b055ac795f59fe4b5b44d0fd86b7eea0b1c4b13a55a2248e76be38fb31c9
3yzgdw7bq6dg  composetest_redis  1/1       redis@sha256:38e873a0db859d0aa8ab6bae7bcb03c1bb65d2ad120346a09613084b49185912

web is on both nodes, redis is only on the master. If I connect to the other node, and ping redis, it's unreachable.
If I do docker service update --replicas 2 composetest_redis, after a few seconds ping redis works (the new replicas exists now on the same node as the ping command).
If I do docker service update --replicas 1 composetest_redis, the ping becomes unreachable again.
Here is docker version and docker info :
Client:
 Version:      1.12.2
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   bb80604
 Built:        Tue Oct 11 05:27:08 2016
 OS/Arch:      darwin/amd64
 Experimental: true

Server:
 Version:      1.12.2
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   bb80604
 Built:        Tue Oct 11 17:00:50 2016
 OS/Arch:      linux/amd64

Containers: 4
 Running: 2
 Paused: 0
 Stopped: 2
Images: 16
Server Version: 1.12.2
Storage Driver: aufs
 Root Dir: /mnt/sda1/var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 29
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: overlay bridge null host
Swarm: active
 NodeID: 92vfyv3de82uocjrhvmtvp1rp
 Is Manager: true
 ClusterID: 6uwx6a4b6pkkpk9a73nuznlwg
 Managers: 1
 Nodes: 2
 Orchestration:
  Task History Retention Limit: 5
 Raft:
  Snapshot Interval: 10000
  Heartbeat Tick: 1
  Election Tick: 3
 Dispatcher:
  Heartbeat Period: 5 seconds
 CA Configuration:
  Expiry Duration: 3 months
 Node Address: <IP_ADDRESS>
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 4.4.24-boot2docker
Operating System: Boot2Docker 1.12.2 (TCL 7.2); HEAD : 9d8e41b - Tue Oct 11 23:40:08 UTC 2016
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 995.9 MiB
Name: node-1
ID: GI2E:B7TB:5GCW:YWT7:RTOJ:ZYTD:MTJJ:CY6Q:BUIT:2RT7:GHX7:4LSU
Docker Root Dir: /mnt/sda1/var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 52
 Goroutines: 160
 System Time: 2016-10-12T15:32:56.984481575Z
 EventsListeners: 2
Username: gobadiah
Registry: https://index.docker.io/v1/
Labels:
 provider=virtualbox
Insecure Registries:
 <IP_ADDRESS>/8

And just in case, the dab file :
{
  "Services": {
    "redis": {
      "Image": "redis@sha256:38e873a0db859d0aa8ab6bae7bcb03c1bb65d2ad120346a09613084b49185912",
      "Networks": [
        "default"
      ]
    },
    "web": {
      "Image": "gobadiah/web@sha256:5b61b055ac795f59fe4b5b44d0fd86b7eea0b1c4b13a55a2248e76be38fb31c9",
      "Networks": [
        "default"
      ],
      "Ports": [
        {
          "Port": 5000,
          "Protocol": "tcp"
        }
      ]
    }
  },
  "Version": "0.1"
}

@gobadiah Pinging the VIP is not something that is expected to work in this release.

FYI, running Docker 1.12.2 swarm with 4-6 nodes, this networking issue disappeared when I made sure the ntp service was running on all swarm nodes and all clocks were synced. Maybe this is a sync issue in the raft because of server time drift.

Any news for this issuer please ?

@saiaman the original issue reported here was fixed in docker 1.12.2, if you're still having issues, please open a new issue with details and steps to reproduce


Rust macro for defining terms

punc!( λ⟨x:X. y⟩ )

https://github.com/andrew-johnson-4/PunCalculus/commit/55db4c6916c3c046b0ad2e0fdbb7449da134394e


Get Relay-Modern unit tests passing

Koistya was having issues with unit tests not passing on the Relay Modern branch because of the Relay's context not found issue
Original pull request that is failing: https://github.com/kriasoft/react-starter-kit/pull/1250
resources to look at: https://github.com/airbnb/enzyme/issues/398

Won't be needing this once migration to React-static and nodejs-api starter happens.  Relay doesn't have the same issues with that boilerplate


[3.x] Improve string formatting (%f) for inf and nan

3.x version of #64833
Could be cherry-picked to 3.5 bugfix releases.

Marked as draft as I'll fix the errors later today

Thanks!

Cherry-picked for 3.5.2