Redundant adaptation commands not always skipped

This bug has been identified in the discussion of #588. This block in _adapt_light is supposed to skip adaptation commands if the current state of a light already equals a desired state (called service_data):
https://github.com/basnijholt/adaptive-lighting/blob/9caf64509349958a340f8cef9207fdb0ea35dbef/custom_components/adaptive_lighting/switch.py#L1176-L1186
Unfortunately, this does not always work and can be reproduced by

turning on a light,
awaiting adaptation,
turning off the light,
turning the light back on and noticing (e.g. in Z2M logs) that an adjustment command is sent even though the light is already in the desired state (since it was just adapted in step 2).

I can't post meaningful AL logs, since this issue is only noticeable through the absence of the Cancelling adapt to light log messages that signal that an adaptation is skipped. In this example, adding a log for last_service_data to the block cited above would print None. There are more situations in which it happens, and looking at the implementation, the issues seem to be:

last_service_data is only updated by _adapt_light(), hence only by adaptation commands from AL
last_service_data is deleted by reset(), e.g., when lights are turned off, the configuration is updated, or manual control is changed
the comparison includes the transition time

In summary, every initial turn-on of a light, and every turn-on call (e.g., to adjust unrelated state) after a regular adaptation command (which sets the transition to an unusual duration, e.g., the default 45 seconds) potentially lead to unnecessary adaptation commands. It happens because the state isn't tracked over the complete lifetime of the lights, and transitions times interfere with state comparisons.
This might seem like a minor issue, but unnecessary messages in an active Zigbee network can negatively affect it, and also some lights do not handle multiple parallel messages very nicely, resulting in a suboptimal user experience. For example, transitions of Tradfri lights might get jittery or skipped, or the lights even end up in an invalid state (on, but reported off). It gets twice as worse with separate_turn_on_commands enabled.
As a solution, I think that the last_service_data should be updated by any changes, no matter if from AL or from elsewhere. What's important is that we know the current state of a light to be able to decide whether an adaptation command is necessary, and that's independent of who set it. This could be done in state_changed_event_listener. Also, it should never be deleted, because the lights always have a state. With separate_turn_on_commands enabled, it should only send the subset of command that actually changes state (e.g., skip the brightness command but send the color command). I implemented a proof of concept and it works nicely.

The only times that a light will be adapted to the same values as the last_service_data are in the following situations:

When the force argument is true which happens for various events such as a user manually turning off and on their light, flipping the adaptive switch in the UI, calling adaptive_lighting.apply, etc.
reset() is only called when lights are turned off or when manual control is disabled(?)
When the transitions differ

This was a relatively new feature we added in a recent release and as transitions do not differ very often it wasn't worth fixing. We were originally trying to quickly put out a major hotfix for the accursed 1.10.0 bug, which caused this feature to sneak its way in. Actually, I believe there's still a PR in progress that is awaiting review to include the transition check.
You need to stabilize your configuration elsewhere.  The last_service_data check was never added to prevent any and all light.turn_on commands, it was supposed to be a simple performance improvement. The short is your bulbs should be able to handle a simple light.turn_on command a few times a minute and you shouldn't need to be relying on this check as heavily as you seem to be. With that said we need to look at your configuration to find the core problem.
I do remember a few years back when I set up adaptive lighting initially that I would get z2m spam, but how I fixed it is long since forgotten. It wasn't even caused by AL; just exacerbated. I believe I modified my z2m configuration and never had the problem again. You can verify this problem with these resources: https://github.com/basnijholt/adaptive-lighting#spider_web-zigbee-z-wave-and-other-mesh-networks and https://github.com/basnijholt/adaptive-lighting/discussions/506
I realize you question the validity of your AL logs but please know that I understand how difficult it is to provide them. Sometimes there's a bug so sinister and sneaky you just can never capture it at the right time (see #448). But your logs and config do help us try to reproduce the issues.  I personally own the tradfri bulbs and would like to find out why you're experiencing these issues that I am not. I suspect it's a Zigbee configuration setting we've overlooked.
You could try increasing the adaptive-lighting interval or setting your transition to the same as the initial transition. Alternatively, you perhaps might want to try the Adaptive-Lighting Edge version which includes the transition check. You can find it as an optional version in your HACS.

I'm sorry if I wasn't clear enough. I don't care about a few unnecessary commands, what I care about is a smooth user experience. The root of the problem is that my Tradfri bulbs do not apply a fade-in transition to brightness if a command also includes the color temperature. See this example HA service call:
service: light.turn_on
data:
  transition: 2
  color_temp: 414
  brightness: 255

With this call, which is exactly what AL sends by default after any turn-on command, my bulbs turn on immediately at full brightness, and only the color temperature fades over the transition duration. Maybe that's a Z2M issue, maybe not handled nicely by the bulb's firmware, or maybe even required by the Zigbee standard, but either way, it's out of my hands. To fix this, AL offers the separate_turn_on_commands which sends separate commands for brightness and color temperature, but that leads to issue #410 for which I proposed a partial fix in #590.
So how is this related to skipping redundant commands? Whenever commands are skipped,

it wouldn't even have the chance to interfere with transitions from regular turn-on commands (e.g. from automations), and
separate_turn_on_commands wouldn't trigger issue #410.

The issue obviously remains in cases where an adaptation is necessary, but it reduces AL's invasiveness and improves the UX of all the turn-on commands that don't need adaptation. The reduction of network load I mentioned above is a nice side effect which comes for free.

The title of your post is 'Redundant adaptation commands not always skipped' so I tried to answer that specific issue with the details you provided. If you'd like help fixing #410 with separate_turn_on_commands I think my reply is still valid. I'm also using the tradfri bulbs and I am not getting these same issues that you are. This tells me that there is something different between our Zigbee setups or our adaptive lighting configs, which is why I provided those details and suggestions in my last post.
It seems that you're not referring to the code we talked about that compares the previous values to the current values. Again some logs of Adaptive Lighting specifically calling light.turn_on redundantly would be helpful. Sorry if you find this unhelpful I just don't know how to help without any diagnostics here.

I initially got the wrong impression that the code block cited in my initial post was supposed to skip all unnecessary commands (in this context, an unnecessary command is one that sets a state which is already set). You made it clear that this code wasn't meant to do this and that it only handles one specific case.
So the rest of the text was just me trying to argue for actually implementing a mechanism that skips all redundant commands. The Tradfri bulbs were an example where I know from experience that this yields a worthwhile improvement, but generally this has the potential of positively impacting all setups, e.g., by reducing #410. I also mentioned that I have a working POC, which was a gentle way of suggesting that I could contribute if this idea was accepted.
Your point is that a correct setup should be able to handle all those messages, and an optimization is unnecessary. That's fine, but if anybody else has an opinion on this, I'd still be interested to read it :)


Added Debug Message Data Block

Closes #11
Added Debug Message Block initialize.

Closing due to inactivity!


params: fix range check when converting double to uint64_t.

Found in #15815

[ ] documentation is added or updated
[ ] tests are added or updated

Merged to master, thanks for the reviews.


attach a basic variable provider

#14821

initial implementation for a variable provider
only makes one python call per request (all variables at that level)

No inspect requests to the kernel as those were significantly slower than just calling python code

values are very simple at this point

raw types are displayed as is
collections are displayed as [...], objects as {...}

The data pipe is separate from the jupyter variable viewer since the types didn't mesh, and this way they can be removed cleanly when we get around to fully replacing the current view.
No caching yet, but can be implemented for the execution count

Still need to fix a DI error in the tests

initial implementation for a variable provider
only makes one python call per request (all variables at that level)
No inspect requests to the kernel as those were significantly slower than just calling python code
values are very simple at this point - raw types are displayed as is, collections are displayed as [...], objects as {...}
The data pipe is separate from the jupyter variable viewer since the types didn't mesh, and this way they can be removed cleanly when we get around to fully replacing the current view.


tests: Unit tests exiting non-zero doesn't fail the build

Noticed this build that was marked as successful, but didn't have any test counts from junit:
http://ci.kurma.io/viewLog.html?buildId=12219&buildTypeId=Kurma_UnitTests_2&tab=buildLog#_state=34,49&focus=73
Need to correct it to fail on non-zero. Logging since won't get to it today...

Fixed in CI configuration. Needed set -o pipefail so make test | tee foo would exit non-zero.


regressiont-test support run cases multiple times in regression-test

… reporting correctly to TeamCity (#26606)
Proposed changes
Issue Number: close #xxx

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

run buildall


Add a timeout when searching for draggable element

Latest commit in master makes the timeout unnecessary by applying draggable.handle on click instead of during initialization

Thanks, it's working fine on master


Ubuntu: [process exited with code 11 (0x0000000b)]

Windows Version
Microsoft Windows [Version 10.0.19044.3086]
WSL Version
<IP_ADDRESS>
Are you using WSL 1 or WSL 2?

[X] WSL 2
[ ] WSL 1

Kernel Version
<IP_ADDRESS>
Distro Version
Ubuntu 20.04
Other Software
VSCode 1.79.2
WSL extension v0.79.5
Windows Terminal 1.17.11461.0
Repro Steps
The issue occurs at random when trying to start a WSL session, and when it does, it does so every time you try to start WSL anew; haven't tested if it only persists until system reboot.
One possible cause of the problem was that a power shortage occurred while my computer was running and WSL was running in the background.
Expected Behavior
You should see you user's command prompt on Ubuntu
Actual Behavior
The terminal displays the error message [process exited with code 11 (0x0000000b)]
Diagnostic Logs
None of the steps from the CONTRIBUTING.md file generate any crash logs.

same problems for me

Same problem for me too. I ran a random command (source something), WSL exited, and now if any WSL app in the terminal opens, it gives me this error.


Add __cplusplus guards to headers

This commit adds them to almost every header. There are a few that don't have any normal header include guards because they don't define anything.

Hmm not exactly encouraging contributions...

Tim, I believe this PR was merged.  We just didn't properly attribute it as closed in the commit message.  If that's not true, please correct, and we'll reopen.

And I should clarify: the reason merges don't happen through GH interface, is that we can't do it, because ASF GIT is mirrored to GH.  So we have to merge the PR using git command line tool, and then in the commit message reference "This closes #110" (for example.)  If we forget to do that, the PR remains open, even if the PR itself is merged.  The attempt here was to clean that up, for precisely the reason here: it's confusing as to which PRs we merged, and which ones we didn't - if we're not on top of this.  Again, I do think we actually merged your PR - but if not, please let us know, and we'll correct.

Ah right you are - apologies for the attitude! :-)

Sorry Tim, this was my mistake.  I really should have indicated the reason for closing each ticket.  I wasn't actually very confident that the commit would even successfully close the pull requests, so I got lazy.  And as far as attitude goes, I'm not too impressed :).  I would have been a lot worse!


Fixing nested model update

Related with: https://github.com/CartoDB/cartodb/issues/12386
cc @nobuti

I can see any flaws in staging, it's working 200% better than before ✨

Nice!, thanks for giving a try man.


Add @types/jquery as dependency

I am using timeago.js in a TypeScript project. When compling the code, I get the following error:
$ tsc --noEmit
node_modules/timeago.js/timeago.d.ts:1:23 - error TS2688: Cannot find type definition file for 'jquery'.

1 /// <reference types="jquery" />
                        ~~~~~~

Adding @types/jquery as a dependency instead of a devDependency in this library should fix this problem. This is also what was suggested in an earlier comment.

add as peer dependence is better.

Is your error solved with this fix @samuelmeuli ?

Yes, it is, thanks!

@tofra add @types/jquery into your package.json.


Exo Traits - Strength misspelling

"Ability Score Increase. Increase your Constitution and Strenght Modifier by 1."

Found another one:
"Quick Build
You can make a Guardian quickly by following these suggestions. First, Dexterity should be your highest ability score, followed by Charisma (Hunter), Strenght (Titan) or Intelligence (Warlock). Second, chose the Blank background."

Hey there. Looks like you were trying to give feedback to somebody's brew and accidentally submitted a bug report to the maker of the website instead. If you found that brew on Reddit or something I would recommend sending your feedback there instead.


Update year in conf.py

What
Change 2016 to 2017 in conf.py template (https://github.com/googleapis/toolkit/blob/master/src/main/resources/com/google/api/codegen/py/docs/conf.py.snip#L65).
Why
It's 2017. P2 priority because we are not currently generating docs.

Also, in index.rst, google is duplicated on the proto path.


Adjusted config of codeclimate.

Values may need more tuning though.
https://docs.codeclimate.com/v1.0/docs/maintainability#section-checks + https://docs.codeclimate.com/v1.0/docs/advanced-configuration#section-default-check-configurations

This change is

Please mark such PRs with [skip ci], we have quite short queue on Circle.
odeclimate — 524 fixed issues - nice score as for single PR! :D

Reviewed 1 of 1 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved, some commit checks broke.

Comments from Reviewable

 again ;)

Reviewed 1 of 1 files at r2.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


Keys are no longer asked for if not passed in the CLI

Default behaviour would be to ask the user for keys. This no longer happens.

Keys are actually asked for, but there is no statement shown that that is the state.


Migrate to govuk-frontend V3

https://trello.com/c/5FhjhxMd/139-3-migrate-user-frontend-to-govuk-frontend-v3

This looks awesome. New focus styles are there, the secondary action link highlights look much better too, and I love the way the page doesn't move around when loading!

### Visual changes

This is an example of the output of the visual regression tests against this commit. Most of the changes are related to colour, although there are a few shifts due to size changes as well.


Removed breadcrumbs package dependency

Removed breadcrumbs package dependency because it was moved to core package

Coverage decreased (-0.08%) to 69.519% when pulling 16a472aeaf19ad125c7cd6b7cc059e0e84d170b1 on remove_breadcrumbs into 04a1129d31c924e5fb39be65eb81e3e8250b91eb on master.


Incorrect acknowledgments

Some agents are performing tasks without notifying the server. We can have 1/1 positive acknowledgments but should have more than 1.
Possible problem: matching pattern on the server is wrong and discards more possible acknowledgments.

fixed in #16


Specify platform for CDK Docker Images

Description
TBD
Issues Resolved
[List any issues this PR will resolve]
Is this a backport? If so, please add backport PR # and/or commits #
Testing
[Please provide details of testing done: unit testing, integration testing and manual testing]
Check List

[ ] New functionality includes testing

[ ] All tests pass, including unit test, integration test and doctest

[ ] New functionality has been documented
[ ] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@lewijacn Is this still being worked on? Hasn't seen changes in a while.

@lewijacn Is this still being worked on? Hasn't seen changes in a while.

In my quick testing this small PR change made it so we could store OTEL images for both ARM and X86 in the same ECR repo.  I think it may still be valuable (as I assume we still have this issue) but need to spend some time to further verify this

@lewijacn I'm going to close out this PR this since it isn't seeing any progress in the past month.  Please reopen if you want to pick this back up


Refactor CEM to make it more readable

Also add more documentation, e.g. docstrings.

clean up get_counterfactuals. Lots of unneeded code.


Popgun Attribute: disableClickOff

<div popgun popgun-disable-click-off="true">
...
</div>

LGTM! super straightforward, just the way i like it ^_^


Add Num zeros and Num negatives feature

Hi. I have added both the Count Zeros (num_zeros) and Count Negatives (num_negatives) in the NumericalStatsMixin Class. I also added Profiler Options for both of these as well. Finally, I have made some unit tests and modified some other tests to include these two new features. Please review this and let me know anything that needs to be further implemented, such as more test cases.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

I also suggest updating test_numerical_options.py for the additions.

You also will probably have to go through test cases that assert equality on expected profiler reports and add these 2 new statistics to them, as they currently won't be present in the previous "expected output" but will now be present in the actual output.


bootkube: add calico-kube-controllers

Closes #99
I wonder if we should add some tests to it.
Signed-off-by: Mateusz Gozdek<EMAIL_ADDRESS>

Do you plan on removing the hostendpoint controller in this PR or subsequent PR?

It cannot be removed until next version of Calico is released...


is there any sample for MSI-X interrupt demo?

on win10 platform,
Is there have any msi-x sample demo?

I also need same MSI/MSI-X interrupt demo for PCIe driver develop...


Allows embedded IPFS node to be configured

resolves #394
Simply adds a field in the options (if node type is embedded) that allows you to paste some JSON config. This allows the savvy user to configure their js-ipfs node as they like.

I've also removed the is-js-ipfs-enabled module as it is always enabled now (sorry that should probably be in another PR but is a small change so hopefully not too distracting).
This PR also upgrades choo to fix this problem with textareas: https://github.com/choojs/choo/issues/632

@lidel can we deal with the linting warning as a separate issue please?

@lidel @olizilla I added this because I needed to enable pubsub on the js-ipfs node, but this is real power user stuff and is error prone for new users. Would it be better to just have a checkbox to enable pubsub instead and leave the JSON config to the power users who are probably running their own daemon anyway?

Linter
Rule of thumb: we should never break build of master. It introduces friction for other people that want to work on own PRs.
I propose we park this PR until linting is fixed in separate PR, and then you can rebase this PR on top of that.
JSON and UX
Indeed, a field with JSON in it is error prone.
But I am not sure if we want to create a precedent of adding control for pubsub.
Let's keep JSON-based config, but make sure the "Reset Everything" button restores config to safe defaults.
That way of user breaks it, there is a way of fixing it.
We should also either add "(for Power Users)" to label description, or move it to "Experiments" section.

On the subject of config... I say keep it simple. It's be helpful as a dev to know that I can build an app that will run if the user installs ipfs-companion as it has a fairly predictable config. They don't have to install a local go node or desktop, the defaults in companion will work.
I'm not sure who we are catering for in making an easy to use embedded node also be "power-user" configurable. A simpler story would be "embedded node with defaults" for the casual user, "external node with custom config" or just, "create an app that bundles it's own custom ipfs node" if your app or use case has custom requirements.
I'd be happy to start in that direction, and then see if anyone starts demanding more configurability of the embedded node and review.

@lidel I'm happy for this PR to be blocked by the lint issue 👍
I appreciate that I opened this PR but I agree with @olizilla on this one - I think the stories should be casual -> embedded, expert -> external. I think JSON config is at odds with the casual embedded story.
Here's the thing. If we don't have JSON config and we don't have an enable pubsub checkbox then people can't use pubsub with window.ipfs.
Why?
Pubsub is disabled in js-ipfs-api when used in browsers.
Embedded js-ipfs is not configured to enable the pubsub experiment by default.

Hm.. now that I think about it, I'd say pubsub is marked as an experiment by js-ipfs for a reason :)
I propose we keep the "embedded node JSON config field" field in current form, but move it to  to "Experiment" section (and update label to explicitly state that the config is for embedded node only).
That way that there will be no confusion that this feature is an opt-in experiment that can changed removed in future.

@lidel rebased and lint error is now gone 😄

Not sure if related to this PR, but also found: #407

Ok so, you're saying that "rekt" as a swarm value throws when we create a new IPFS instance?
We can code around that particular issue, but it's going to be difficult to guard against all config issues. I can imagine a situation where users accidentally stop their node from communicating on the network or even cause it to error when particular methods are called due to the config they've copy/pasted from the internet or changed themselves. I don't think that's something we can, or even should be trying to guard against...like I said above, it's error prone and I think a checkbox to enable pubsub would be a safer option for casual users.
As a side note, is the reset button not working for you? It should reset back to the default config.

I agree we can't (and we should not) guard against broken config.
My point was that Reset button does not work as expected (the real expectation is "make it all work again"). I am sorry, should emphasize that better :)
Replication steps

Set config with invalid "Swarm": [ "rekt" ] → node breaks
Press Reset Everything → the config is restored  to defaults
(Swarm value on Preferences screen is restored to [ ] )
.. but the node does not work. Even if you toggle between embedded and external node API client does not start correctly (logs) and user is left with broken extension without  a way of fixing it.

I would really like to keep this "full config" feature, as it encourages playful experimentation, but we need to make it possible to self-heal.

@lidel ok I'm on it! 👍
btw, how do you format a button in gfm?

<kbd>K</kbd> → K :)

Blocked by https://github.com/ipfs/js-ipfs/issues/1193#issuecomment-368843378

@alanshaw hi there! it looks like this won't be blocked anymore thanks to your work in R ipfs/js-ipfs#1239 (though not upstreamed to a patch release yet). just wanted to make sure I'm following everything correctly. is that all correct? nice work, btw!

Thanks, I think we're just waiting on it to be released now @cvan

@lidel I've taken another look at this, updated the IPFS dependency and fixed the stability issues you were seeing.
There is now validation of config and feedback to the user and there's always a way to reset config and the extension acts gracefully when it fails to start an IPFS node.
I'm happy for this to merge if you are.

@lidel looks good to you?

:ok_hand:
Thanks!


iOS 14.5 / Xcode 12.5 Build Issue:  Semantic Issue (Comparison of distinct pointer types)

There is a compiler error when building the scheme dynamic with Xcode.
Tested against:

Version 12.5 (12E262) released on Apr 20, 2021
Version 12.5 beta 3 (12E5244e) released on Mar  2, 2021.
Version 12.5 beta 2 (12E5234g) released on Feb 16, 2021.
Version 12.5 Beta (12E5220o) released on Feb 1, 2021.

This same file (NSExpression+MGLAdditions.mm) compiles fine with Xcode Version 12.4 (12D4e) & Xcode Version 11.7 (11E801a)

Xcode reports Semantic Issue

Comparison of distinct pointer types ('NSString *' and 'Class')

https://github.com/maptiler/maplibre-gl-native/blob/72692d6305bb4df1d64dab450e0d49e2c8d5c943/platform/ios/platform/darwin/src/NSExpression%2BMGLAdditions.mm#L1272

Error in Xcode 12.5 Beta

Other parameters of note:

SDK iOS 14.5 (released as Beta on Feb 1, 2021)

New type of error when attempting to build with Version 12.5 beta 3 (12E5244e) when testing with master: dba5d968b21a05d52ad5aa7b261804f032d0736f

Cast to smaller integer type 'unsigned int' from 'MGLReachability *'

This issue still exists & is a blocker for anyone intending to upgrade to Xcode 12.5 RC for MapLibre development.  I recommend sticking with Xcode 11.7 or 12.4 to build MapLibre.

If you are keen to upgrade to Xcode 12.5, you can help investigate or make a test case to ensure that the following is the right fix and/or a proper workaround.
//                           (NSString *) // Fixing the error by casting.  TODO verify it doesn't break something else
            } else if (op == (NSString *) [MGLColor class] && [function isEqualToString:@"colorWithRed:green:blue:alpha:"]) {

Diff from within Xcode 12.5

Regarding the error in MGLReachability.m and Cast to smaller integer type 'unsigned int' from 'MGLReachability *' warning:
I think we should replace
    NSString *description = [NSString stringWithFormat:@"<%@: %#x (%@)>",
                             NSStringFromClass([self class]), (unsigned int) self, [self currentReachabilityFlags]];

with
    NSString *description = [NSString stringWithFormat:@"<%@: %p (%@)>",
                             NSStringFromClass([self class]), (void *) self, [self currentReachabilityFlags]];

The first warning Comparison of distinct pointer types ('NSString *' and 'Class'):
} else if (op == [MGLColor class] && [function isEqualToString:@"colorWithRed:green:blue:alpha:"]) {

It looks like a bug in Mapbox source code to me: op == [MGLColor class] the left variable is NSString * and the right one is Class. I can't figure out how it supposed to work.
Probably it should be something like [op isEqualToString:NSStringFromClass([MGLColor class])]

@glyuck — thanks for the contribution!
With this commit we now support Xcode 12.5 & Xcode 13-beta.  And as a bonus MapLibre runs on the simulator on Apple Silicon with the latest Xcode release & beta.
Commit https://github.com/maplibre/maplibre-gl-native/commit/19b86f750dd829a1122a1df928709c70e62cbeeb been has tested on:

both flavors of Big Sur (Intel & arm)
a couple of Xcode versions that I had lying around

Xcode Version
c++ version
Catalina
Big Sur (Intel)
Big Sur (arm)

12.4 (12D4e)
<IP_ADDRESS>00032
✅Xcode 12.4 runs on Catalina & Big Sur
✅
Not tested

12.5.1 (12E507)
<IP_ADDRESS>50022
❌Xcode 12.5 requires Big Sur
✅
✅

13.0 (13A5192i)
<IP_ADDRESS>00025
❌Xcode 13-beta requires Big Sur
✅
✅


Preset for blood donor centers

Preset for healthcare=blood_donation :heart::droplet:, as promised in #3285.
I didn't even think about adding the part about which compensation you receive, because we already had problems enough with the blood components. :stuck_out_tongue:
Some mini golf changes ended up here as well, due to executing make.

Sure this looks good, thank you!


Replace @types/rdf-js with @rdfjs/types

@types/rdf-js in https://github.com/jacoscaz/quadstore/blob/6e33be85f51230a15128cff61aaa67b0bde265b8/package.json#L76 should be @rdfjs/types instead. See https://github.com/rdfjs/types?tab=readme-ov-file#what-about-typesrdf-js

Impressive turnaround @jacoscaz !

I was just about to respond @jeswr - lucky coincidence that I was already working on quadstore :)
Thanks for flagging this! I'm making sure that other packages like quadstore-comunica are up to date with this. May I ask you how you came to notice this? Are you using quadstore?

May I ask you how you came to notice this? Are you using quadstore?

I was trying to pin down some warnings that I was getting from components.js building the Community Solid Server so I ran the following search to see what uses of @types/rdf-js were still in use
https://github.com/search?q="\"%40types%2Frdf-js\"%3A+\""+language%3AJSON&type=code

Cool stuff! Thanks again @jeswr , this is now on NPM in<EMAIL_ADDRESS>(and quadstore-comunica@4.0.1).


allow updating royalty fee

Contract should allow to update royalty fees no more than the initial royalty_fee (immutable).

open question: should creators also update other aspects of collection info?

I think this is already done right ?

oh yea it's done already. let's close this


[iOS][Weex Ui][wxc-swipe-action] Swiping the wxc-swipe-action component on the iOS phone did not respond

Describe the bug
No matter WeexPlayground or our own app, using wxc-swipe-action component on iOS mobile phone, left swipe did not respond
To Reproduce
After starting the weex project locally, scan the qr code with WeexPlayGround and open the page written with wxc-swipe-action component
Environment

App:[WeexPlayground]
Device: [All iphones]
OS: [All OS]
Version [20]
Build from source [yes]

Expected behavior
Hopefully, all iphone systems will be able to use this component
Code
Use the Weex Ui official case code，reference：wxc-swipe-action

Our app has been solved by adding BindgingX, but WeexPlayground is not available. It is estimated that the problem is the weex SDK version


(ui) Animated Cooking Pot

Second Task of #767
Objective of the PR:

[x] Makes an SVG component file named JamCookingPot.tsx
[x] Uses CSS keyframes to achieve animation of the cooking pot
[x] Animation works in Dark and White mode

PR is ready to merge and awaits review from mentors.

@theborakompanioni do we want the sprite to be removed in this PR if the animation is implemented.


Extend 48 and 64 bit instruction length unary encoding style to 128 bits

At present 48 bit and 64 bit instructions are encoded in the first 16 bit parcel as:
xxxxxxxxxx011111 48 bits
xxxxxxxxx0111111 64 bits
This is a good scheme. Each extra 16 bits of opcode gets 15 bits of usable new space.
But then:
x000xxxxx1111111 80 bits
x001xxxxx1111111 96 bits
x010xxxxx1111111 112 bits
x011xxxxx1111111 128 bits
...
x110xxxxx1111111 176 bits (22 bytes)
While this works out well for the longer sizes it leaves the 80 bit encoding definitely too tight to include a 64 bit literal -- if you wanted both int64 and fp64 literal loads to an arbitrary register then that's the entire 80 bit opcode space used (except perhaps rd = 0).
I propose:
xxx0xxxxx1111111 80 bits
xx01xxxxx1111111 96 bits
x011xxxxx1111111 112 bits
0111xxxxx1111111 128 bits
1111xxxxx1111111 reserved for >= 144 bits (18 bytes)
Pros and Cons
Pro: 80 bits gets two more bits of encoding space, and 96 bits gets one more bit of encoding space.
Con: 128 bits gets one bit less of encoding space
Con: 144, 160, 176 bits and 192 bits and higher lose three bits of encoding space (assuming a counting scheme using two bits in the next 16 bit bundle for 144, 160, and 176) Note that 128 bits (16 bytes) is already a byte longer than the maximum allowed instruction length on AMD64.
Pro: postpone more complex decoding logic for longer?
Pro: loading int64 and fp64 immediates to an arbitrary int or fp (as appropriate) register can be done in an 80 bit instruction, while still leaving 3x more unused 80 bit opcodes than with the current scheme. There would even be room for jal64 and destructive addi64, andi64, ori64 .. just as an example .. while still leaving as much unused space as with the present scheme.
To me, encoding space at 80 bits especially still feels precious. Being able to load a double precision floating point value from the instruction stream seems like it's probably a significant win.

I don't think we're proposing to ratify the >32-bit instruction-length encoding scheme at this time, since there are no proposed instructions longer than 32 bits.  So, we can continue this discussion past the base-ISA ratification period.
I understand the desire to extend the unary instruction-length encoding pattern.  OTOH, two more considerations countervail your proposal: (a) no one really wants to build instruction-fetch units that can't determine the instruction length from the first parcel, so "reserved for >= 144 bits" means "max. 144 bits" in practice; (b) bit 15 would ideally not participate in the length encoding scheme, because it already serves as part of the rs1 field.
(We could perhaps split the difference and extend the unary encoding by only one notch, which would accomplish your goal of expanding the 80-bit encoding space, but still supporting up to 144-bit instructions and avoiding eating bit 15.)

Wild and crazy idea...
Instead of having some binary encoded "number of 16 bit packets" field in the next (2nd) 16 bit packet ... what about if  1111xxxxx1111111 means the instruction is 128 bits long (just like 0111xxxxx1111111) plus what looks like the next instruction, encoded in the normal way.
So, for example, a 144 bit (18 byte) instruction is  1111xxxxx1111111 followed by seven arbitrary 16 bit chunks, followed by xxxxxxxxxxxxxxaa with aa != 11 (standard 16 bit encoding)
Pro: supports arbitrarily long instructions with a finite encoding scheme.
Pro: some tools (and maybe even some parts of instruction fetch/decode) could be slightly simpler.
Con: serial decoding of very long instructions.

We should optimize the encoding under the assumption that it will be unpopular to define instructions whose length cannot be encoded within the first parcel.

My reading of the spec is that the encoding scheme for 48- and 64-bit instructions is fixed. If that is not the intent, the spec should be updated to make that clear.

@aswaterman I certainly agree with that. We want to leave the door unlocked, but maybe a bit sticky...
What is going to make an instruction longer than 16 bytes -- that is 14 bytes, plus maybe 1 bit, of useful payload? OK, put a 64 bit literal in a 128 bit instruction and you've still got 48 (49, with your compromise) bits of space for register fields -- let's say four of those for 20 bits. So 28 (29) bits left. That's a heck of a lot of opcodes, rounding modes, negations of operands etc.
What are you going to do to exceed a 128 bit instruction, other than including multiple big literals (not very RISCy). Ok, there are 128 bit literals one day. A 144 bit instruction will let you do basically load immediate and nothing else.
You could say that basically 144 bits is it, but make rd = 0 the escape hatch to longer instructions if someone really really wants them.

@asb which text suggested 48- and 64-bit encodings are fixed, but 80+-bit encodings are not?  (Not disputing your interpretation; I just don't recall having read that recently.)

@brucehoult I'm not making a case for longer instructions; I'm just observing that instruction-length reach is a resource being traded here.

OK, I was confused by the 48-/64-bit part.
We should make it clear which parts of the Introduction, and which aspects of the instruction-length encoding scheme, are up for ratification.

@aswaterman yes, but if maximum length instruction possible encoded in the first 16 bit packet (leaving room for rd and rs1) was the overriding criterion then you'd skip the unary encoding for 48 and 64 and go straight to a 5 bit binary count of packets for everything past 32 bits, giving a maximum of 48 + (16 * 31) = 544 bits (68 bytes) entirely specified in the first packet and leaving bits 15 and 7-11 untouched.
 If you've build hardware already then you know (or should have known) that at some level you're taking a risk.
More practically, I imagine it would take pretty extraordinary circumstances to cause a change that breaks already-shipped hardware.
But things that no one has implemented yet are surely still up for discussion and re-evaluation?

@asb I'd think technically everything is subject to change, as nothing has been ratified yet. If you've build hardware already then you know (or should have known) that at some level you're taking a risk.
More practically, I imagine it would take pretty extraordinary circumstances to cause a change that breaks already-shipped hardware.
But things that no one has implemented yet are surely still up for discussion and re-evaluation?

Yes, I think there's probably flexibility there though I would have a lot of sympathy for anyone who had a WIP design and was stung by an encoding scheme change. Really I meant that if the intent is not to ratify the current proposed encoding schemes then that should be made clear in the manual.

@aswaterman what about extending by 32 bits at a time after 96?
xxxxxxxxxx011111 48 bits
xxxxxxxxx0111111 64 bits
xxx0xxxxx1111111 80 bits
x001xxxxx1111111 96 bits
x011xxxxx1111111 128 bits
x101xxxxx1111111 160 bits
x111xxxxx1111111 reserved OR 192 bits if rd = 0 is the escape mechanism

We will add clarification to the introduction that only the 16- and 32-bit encodings are being ratified at this time.

Closing this for now, as I don't think there's anything actionable until more use cases for 80-bit instructions emerge.

Bruce Hoult just mentioned this issue to me in a private email and I have an alternative suggestion for the instruction length encoding:
x FFF RRRRR ??bbb11 32-bit (bbb != 111)
x FFF RRRRR 0011111 48-bit
x FFF RRRRR 0111111 64-bit
x FFF RRRRR 1011111 80-bit
x FFF RRRRR 1111111 96-bit and more

Legend:
x     = bit 15, aka rs1[0]
FFF   = funct3
RRRRR = Rd field

For insns with >= 96-bit the length would be 96 + 16*FFF, with N=111 reserved.
For instructions with up to 80 bits length we could call funct3 the "major opcode" and funct7 the "minor opcode" in this format.
This would cost one bit of encoding space in 48-bit instructions, but we would gain a bit in the 80-bit encoding space, and we would streamline the instruction format for the whole range from 32-bit instructions to 80-bit instructions. That would allow us to use the same instruction encodings for load immediate instructions with 32-bit immediate, 48-bit immediate, and 64-bit immediate.
For long load-immediates instructions I would propose something like the following encoding for the LSB 16-bit of the instruction:
E000RRRRRSS11111

E     .... 1 = ones-extend the immediate to XLEN, 0 = zero-extend the immediate to XLEN
RRRRR .... destination register
SS    .... size of the immediate (00=32-bit, 01=48-bit, 10=64-bit)

I'd propose that the immediate for those instructions would just follow in the next bytes, LSB first, without any bit permutations.
This would mean we'd spend 1/8th (12.5%) of the 48/64/80 bit encoding space on integer load-immediate instructions. I think that's absolutely justified, given the general importance of load-immediates. (I would expect that for many cores large load-immediate instructions will be the only instructions >32 bits they will support. So we might as well make sure they have a straight-forward streamlined encoding.)

I generally like @cliffordwolf's scheme It has the benefit's he mentions, plus allows up to 192 bit instructions with the length encoded purely in the first 16 bit packet.
One point is there is no explicit mention of what to do with FP literals which I think are at least as important as integer ones. One option is to use a 2nd value in the FFF field for them, 100 say, or 001.
Perhaps it's useful to be able to specify expanding a 32 bit FP value to the 64 bit encoding instead of NAN-boxing it, in which case the E bit can be used for this.
It's a bit annoying that 48 bit FP values aren't a standard thing, so that combination might go unused, but we'd like to be able to load FP16 literals but there's no obvious way to do that with less than a 48 bit instruction.

This proposal also seems OK, but I don’t think we should commit to anything until we have a clearer idea of how the 48-bit space will be used. Instructions that load FP/int literals seem attractive but I do wonder if their quantitative benefit is being assumed to be greater than it actually is. We should employ a quantitative approach to this problem. (I realize there are considerations beyond total program size, like I$/ITLB pressure being lower for some apps, or load-use delay, but those can be quantified, too. There are also situations where the constant pool is slow to access, but that can usually be worked around with extra effort at load/boot time.)
If FP16 literal loads actually prove important enough, they could be provided with a new 32-bit instruction that needs 21 operand bits, or instead with a LUI plus a new 32-bit R-type instruction that copies the literal from bits 31:16 of an integer register into bits 15:0 of a float register.

One point is there is no explicit mention of what to do with FP literals which I think are at least as important as integer ones. One option is to use a 2nd value in the FFF field for them, 100 say, or 001.

Of the top of my head, I think there are only three candidates for instructions with a single large immediate and just a destination register:

Load integer immediate
Load FP immediate
Jump-and-link

I don't think there is a need for a large-immediate-variant of AUIPC, but maybe I just don't see the obvious use-case right now..
That would leave space for 635 instructions using funct3 as "major" and funct7 as "minor" opcode.

Perhaps it's useful to be able to specify expanding a 32 bit FP value to the 64 bit encoding instead of NAN-boxing it, in which case the E bit can be used for this.

If you implement "Q" then maybe you actually want three instructions:

NaN box as 32-bit float
Convert to 64-bit float and NaN box as that
Convert all the way to a 128-bit float

But since I wouldn't know what to do with the E bit for jump-and-link we could fit the third load fp-immediate into the other half of the jump-and-link opcode encoding space.

Another obvious use for a "major opcode" would be mirrors of the 32-bit OP and OP-FP opcode spaces, with large immediates. Theres a neat encoding for this that I really like:

Store the original "rs1" field in the rs? field for immediate.
Then set rs1[4:2] to the funct3 of the original opcode
Use rs1[1:0] to indicate which operand is the immediate (with 11=reserved)

For OP-FP with large immediate the immediate would be converted into the precision the instruction expects, as indicated by funct7[1:0].
Furthermore I'd reserve the major opcode "111" for an "escape" mechanism into larger instruction encoding spaces. Here opcode E=1 would always be reserved for custom extensions, and with E=0 the rd field would select one of 32 "pages", and we start new with an opcode[6:0] field in the next 16 bit word. This guarantees we'll never run out of encoding space for instructions of any length, if they are rare enough that the 16 bit prefix can be afforded.
Including those we'd have the following major opcodes used:
For 48-bit instructions:

Load integer immediate
Load FP immediate
Jump-and-link
Escape to 32 more "pages"

For 64-bit instructions:

Load integer immediate
Jump-and-link
"OP" with 32-bit immediate
"OP-32" with 32-bit immediate
"OP-FP" with 32-bit immediate
Escape to 32 more "pages"

For 80-bit instructions:

Load integer immediate
Load FP immediate
Jump-and-link
"OP" with 48-bit immediate
Escape to 32 more "pages"

Starting with 96-bit instruction length, where funct3 is being use to indicate the length, the first 16-bit word would just select a "page" in rd. Thus "OP" and "OP-FP" with 64-bit immediate would be a 112 bit instructions. But they would live in a vast encoding space.

plus allows up to 192 bit instructions with the length encoded purely in the first 16 bit packet.

After that I'd just use the rd field to indicate the remaining length in 16-bit units. And the whole first 16 bit word would just be a prefix into a single "page". E=1 would always be reserved for custom extensions.
I think that would enable instructions of up to 864 bits. (Modulo off-by-one errors in my math. :)
Finally 7FFF (E=0) would be reserved as a prefix for longer instructions and FFFF (E=1) would be reserved as a guaranteed illegal instruction.

This proposal also seems OK, but I don’t think we should commit to anything until we have a clearer idea of how the 48-bit space will be used.

Yes, but: I think it makes sense to set a tentative roadmap for this now, as this roadmap can inform how instructions are allocated in the 32-bit encoding space. (Because of things like that mirrors of OP and OP-FP instructions.)
Also, I would assume that there is a bit of a chicken-egg problem going on here. In order to get a better idea of how the 48-bit space will be used, it seems necessary, or at least useful, to put out a concrete suggestion that people can then criticize.

Instructions that load FP/int literals seem attractive but I do wonder if their quantitative benefit is being assumed to be greater than it actually is. We should employ a quantitative approach to this problem.

Absolutely. But I think the best way to do that is to throw out a suggestions that then can be discussed and implemented in compilers and benchmarked accordingly.

I realize there are considerations beyond total program size, like I$/ITLB pressure being lower for some apps, or load-use delay, but those can be quantified, too.

Yes, but this not only depends on the app but also on microarchitectural choices. And maybe CPU projects with this kind of requirements simply don't like RISC-V so much, not take the charge to lead the standardization effort for larger RISC-V instructions.
Consider for example large processors with many hearts and many many hyperthreads for GPU-like applications. There you really want to avoid random memory access for loading constants, because that memory bus is a highly contested resource on those machines.
Or, on the other end of the spectrum, processors that use very slow ROM (such as a QSPI flash) where random memory access for loading constants can be a huge performance killer.
I think to a large degree there's a "If you build it, they will come." aspect here. Where nothing will happen until we first throw out a proposal.
And it's not like the current spec simply says that the prefix "11111" is reserved for longer instructions. No, it contains a concrete proposal for the length encoding. If we can improve on that, then I think we should do that. And if we create some structure where opcodes can be allocated, then chances are higher that people will start using larger instructions, even if maybe only for custom extensions.

I've expanded a bit on the above ideas and posted the resulting proposal here:
http://svn.clifford.at/handicraft/2019/rvlonginsn/README


Question about the speed of tiny-chat

Hi,
Thanks for your outstanding work. I have see the results about tiny-chat using LLaMA2-7b.

I have reproduced LLaMA2-7b on a single A100, here is my results.

My best result is 20.89ms/token, can not reach the 12.44ms/token, and the A100 should be better than the A6000. I wonder what's
wrong.

@benyang0506 I have an explanation to offer you. The benchmarks provided by this repository are correct but they fail to mention the CPU used to measure the latency, which plays a big part. I am not exactly sure where the overhead occurs in Tinychat but it is confirmed to be CPU slowing down things, partly because it runs single-threaded.
For example, I was able to get the following:

RTX 4090 + Intel i9 13900K: 7.46-8.52ms
RTX 4090 + AMD EPYC 7-Series: 17.71-18.6ms
H100: 10.82ms

In essence, a larger GPU will not speed up the inference unless your single-threaded CPU can follow along.


BadFormat for message/cookie: 74686368 is invalid magic cookie (should be 2112a442)

09:34:10.096773 server.go:229: turn ERROR: Failed to handle datagram: failed to create stun message from packet: BadFormat for message/cookie: 74686368 is invalid magic cookie (should be 2112a442)

What is your question?

Yes, there is no head. We want to reduce the amount of data transfer, will it affect

Well, the TURN server needs a valid TURN packet to work with, and that will need the TURN protocol header...

What is the meaning of this log? Do I need to care about it:
No Permission or Channel exists for <IP_ADDRESS>:47104 on allocation <IP_ADDRESS>:58632 (suppressed 175 log events)

Well, the TURN server needs a valid TURN packet to work with, and that will need the TURN protocol header...

In fact, I did not find this problem when using cotrun tests before. I would like to ask if this is in the rfc protocol? I want to study

By the way, although this is wrong, I can still see the real-time picture on my live stream. (I don't use a streaming server)

Closing this since, judging from the below, you must be working with STUNner:
`No Permission or Channel exists for <IP_ADDRESS>:47104 on allocation <IP_ADDRESS>:58632 (suppressed 175 log events)
file_client.go:214: config-file-client WARNING: Waiting for config file "etc/stunnerd/stunnerd.conf"

This is the issue tracker of pion/turn, the TURN implementation that underlies STUNner. Please reopen the issue there.


Add support for target wasm32-unknown-unknown

I like to add support for wasm32-unknown-uknown target (aka browser support)
Someone already created a client
Without changing much code and using #[cfig.(..)] macro will allow compiling to wasm target.

What is your use case for WASM support in this repo? The other WalletConnect client you linked doesn't depend on this repo, and we are not planning to create an official WalletConnect Rust client soon.

The repo/crate I reference copied a bunch of code from this repo, e.g. ProjectId
No need to release any official rust client or publish a javascript package.
With respect to use case, rust wasm is gaining momentum. There are several competing and great  web frameworks.
The PR is the foundation I  need to build webapps/browser extensions that only support reown protocol.
Side note and personal opinion, the rust ecosystem for web developer is more robust and hassle free when compared to javascript/typescript.


Unable to update Service Principals using Azure.ResourceManager.Models types

Library name and version
Azure.ResourceManager.Authorization v1.0.1
Describe the bug
I am trying to write a block that will allow me to assign a Service Principal to a specific role in Azure. This seems to work more consistently with Groups but still fails even there.
The code is such:
        var tcs = new TaskCompletionSource();
        Task.Run(() =>
        {
            try
            {
                var roleAssignmentResourceId = RoleAssignmentResource.CreateResourceIdentifier(assignPath, roleDefinitionId);
                var roleAssignmentResource = _armClient.GetRoleAssignmentResource(roleAssignmentResourceId);
                var operationContent = new RoleAssignmentCreateOrUpdateContent(roleAssignmentResource.Id, groupId)
                {
                    PrincipalType = RoleManagementPrincipalType.Group
                };

                var operationOutcome = roleAssignmentResource.Update(Azure.WaitUntil.Completed, operationContent);
                tcs.TrySetResult();
            }
            catch (Exception ex)
            {
                tcs.TrySetException(ex);
            }
        });

        return tcs.Task;

When this code is run, it will, almost always, fails with the following exception:
{"Tenant ID, application ID, principal ID, and scope are not allowed to be updated.\r\nStatus: 400 (Bad Request)\r\nErrorCode: RoleAssignmentUpdateNotPermitted\r\n\r\nContent:\r\n{"error":{"code":"RoleAssignmentUpdateNotPermitted","message":"Tenant ID, application ID, principal ID, and scope are not allowed to be updated."}}
Expected behavior
I would expect the code to make the role assignment and ignore irrelevant fields
Actual behavior
This fails pretty consistently with Service Prinicpals and sometimes with Group principles
Reproduction Steps
Use the code above. Create any type of SPN, execute
Environment
No response

Thank you for your feedback.  Tagging and routing to the team member best able to assist.

This is a behavior change from service backend, loop service team for help.

Hi @xximjasonxx , I want to know if the parameter groupId in RoleAssignmentCreateOrUpdateContent() is principalId

Here is a sample of assign permission, may it be helpful to you.
    // Assign permission
    var roleCollection = umi.GetRoleAssignments();
    var roleData = new RoleAssignmentCreateOrUpdateContent(
        new ResourceIdentifier("/subscriptions/<subid>/providers/Microsoft.Authorization/roleDefinitions/<roleid>"),
        (Guid)umi.Data.PrincipalId
        );
    var assign = (await roleCollection.CreateOrUpdateAsync(WaitUntil.Completed, Guid.NewGuid().ToString(), roleData)).Value;


How bind accordion open

Using CollapsibleCard is possible to bind open property using bind:open, like:
{ #each cards as card }
    <CollapsibleCard bind:open={card.open}>

{ card.header }

{ card.body }

    </CollapsibleCard>
{ /each }

With Accordion and AccordionItem it is not possible.
Do you guys think that it's a problem to export the open property of AccordionItem? Or is there a different way of doing this?

I'm not sure exactly what you are trying to achieve.
Try binding the key on the Accordion, it will be null when the accordion is closed.

<Accordion bind:key>
</Accordion>

The correct way is binding the key prop and not the open.


Bundle CSS changes

@bbuske How's this look?

@nabeelio Looks goos. I have not yet pushed the new update on the server. I am a bit busy this week, flying... I will push ASAP and let you know.

No problem, thanks! If there's a problem we can address it

Sounds good! Just another fresh install on dev making sure it's working still. I'll probably cut the next beta soon barring anything major. I know there's a few small things you brought up which I'm going to try to get to today/tomorrow. But then I'm also out until Sunday.

No worries @nabeelio.
No rush... :)


Add resource log endpoint (#3188)

Pull request opened by the merge tool on behalf of #3188

Pull request rejected by merge tool. The tests for this branch did not succeed.

The Logline class wasn't there on the iso4 branch

Merged into branches iso4 in 6164cd00865ecddad85f6fcacd1c1d4ec744a3a9


CLOUD-870 remove stack status update to avoid optimistic locking exceptions

@martonsereg please take a look!

Optimistic locking exception should not be occurred when cluster and stack stops are requested at almost the same time
Integration tests are checked and no modification is required
Tested with stop requests at the same time and requests in a row when stopping of cluster is in progress and after it has been finished.

Jenkins build finished, all tests passed.
Refer to this link for build results: http://ci.sequenceiq.com/job/cloudbreak-pull-request/1364/


Bug Report - empty swagger sections after usage of @tag

If i have a route defined for "one-two" and for that controller action I set "@tag One Two", swagger will show a section for "ONE-TWO" that is empty

please post your controller comments

/admin/user -> will produce ADMIN-USER
@tag Admin User-> it will produce ADMIN USER (without a dash) and will display /admin/user under this tag
then,. the first tag autocreated from route will be displayed without any content inside

router.get('/z', [SlotslaunchController, 'test']) -> this will create a section in swagger called "Z everything related to Z"
adding a different @tag like this

will create a section called "ZZ everything related to Z"
this will leave the previous section "Z" to be left empty


When a funding TX takes a long time to confirm, channels get stuck in syncing

I funded new channels with 1 sat/byte and as expected they took nearly a day to clear. A peer using Eclair has informed me that once cleared the channel was stuck in SYNCING. He had to manually disconnect to get the channel unstuck.
This open issue in ECLAIR repo mentions that it could be related ChannelReestablish. Because the peer already fixed this, I'm uncertain if restarting my LND node would have forced a reestablish, but a restart shouldn't be required in any case.
https://github.com/ACINQ/eclair/issues/1444

I'm the counter party for that channel. Here are the logs after the tx got a sufficient amount of confirmations:
2020-06-09 20:55:50,257 INFO  f.a.eclair.Diagnostics SYN n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - IN msg=AnnouncementSignatures(4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152,633911x2048x1,0d2c8a2b7d8e5cb04456b34d68484de0eb1c5ce92906e9477f0196933fd5add933cc6f04136d655474872ae16d347b2b2677d7848675c69bb2a3bd4666023646,ba5b5226feb283df4ed0f49b2990db11a00776912831b8059ac46e137f1346283d9b51ef7a4efd3cf6a8e7d33900e264128d42f8d719fc681350b35aaf6ec9e0)
2020-06-09 20:55:50,257 INFO  f.a.e.i.Peer$MessageLogs SYN n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - IN msg=AnnouncementSignatures(4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152,633911x2048x1,0d2c8a2b7d8e5cb04456b34d68484de0eb1c5ce92906e9477f0196933fd5add933cc6f04136d655474872ae16d347b2b2677d7848675c69bb2a3bd4666023646,ba5b5226feb283df4ed0f49b2990db11a00776912831b8059ac46e137f1346283d9b51ef7a4efd3cf6a8e7d33900e264128d42f8d719fc681350b35aaf6ec9e0)
2020-06-09 20:55:50,257 WARN  f.a.e.channel.Channel SYN n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - unhandled event AnnouncementSignatures(4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152,633911x2048x1,0d2c8a2b7d8e5cb04456b34d68484de0eb1c5ce92906e9477f0196933fd5add933cc6f04136d655474872ae16d347b2b2677d7848675c69bb2a3bd4666023646,ba5b5226feb283df4ed0f49b2990db11a00776912831b8059ac46e137f1346283d9b51ef7a4efd3cf6a8e7d33900e264128d42f8d719fc681350b35aaf6ec9e0) in state SYNCING

and here is when I manually disconnected to get the channel unstuck:
2020-06-10 00:52:15,521 INFO  fr.acinq.eclair.io.Peer CON n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda - disconnecting
2020-06-10 00:52:15,521 INFO  fr.acinq.eclair.io.Peer CON n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda - connection lost
2020-06-10 00:52:15,522 INFO  f.a.e.i.ReconnectionTask CON n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda - peer is disconnected
2020-06-10 00:52:16,374 INFO  f.a.e.io.PeerConnection SYN n:039eca59b1fe20fd725b11ae1d6bae8bbf91f09366534db2bedf6d1a123d9b127f - sent announcements: channels=0 updates=15 nodes=1
2020-06-10 00:52:17,377 INFO  f.a.e.io.PeerConnection SYN n:0301b4bd53dcf2363da523469e4888e7453e242995788efe8efc51f0d476fc3ef1 - sent announcements: channels=0 updates=15 nodes=1
2020-06-10 00:52:17,542 INFO  f.acinq.eclair.io.Server CON - connected to /<IP_ADDRESS>:34898
2020-06-10 00:52:17,989 INFO  f.a.e.io.PeerConnection CON - connection authenticated with 031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda@<IP_ADDRESS>:34898 direction=incoming
2020-06-10 00:52:17,989 INFO  f.a.e.io.PeerConnection CON n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda - using features=000010000000101010001010
2020-06-10 00:52:17,990 INFO  f.a.e.io.PeerConnection CON n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda - peer is using features=000000101010001010100001, networks=
2020-06-10 00:52:17,990 INFO  f.a.e.io.PeerConnection CON n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda - sending sync channel range query with flags_opt=None
2020-06-10 00:52:17,990 INFO  f.a.e.io.PeerConnection CON n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda - rebroadcast will be delayed by 29 seconds
2020-06-10 00:52:17,990 INFO  f.a.eclair.router.Router n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda - sending query_channel_range=QueryChannelRange(6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000,0,2147483647,TlvStream(List(),List()))
2020-06-10 00:52:17,990 INFO  f.a.e.i.ReconnectionTask CON n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda - peer is connected
2020-06-10 00:52:17,990 INFO  f.a.e.i.Peer$MessageLogs CON n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - OUT msg=ChannelReestablish(4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152,1,0,PrivateKey(0000000000000000000000000000000000000000000000000000000000000000),02da536a8a1156da3449e452cf7024b40631a43e8a4ad60d695fd8f03f6f8da7e9)
2020-06-10 00:52:17,991 INFO  f.a.eclair.Diagnostics CON n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - OUT msg=ChannelReestablish(4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152,1,0,PrivateKey(0000000000000000000000000000000000000000000000000000000000000000),02da536a8a1156da3449e452cf7024b40631a43e8a4ad60d695fd8f03f6f8da7e9)
2020-06-10 00:52:18,306 INFO  f.a.eclair.Diagnostics SYN n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - IN msg=AnnouncementSignatures(4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152,633911x2048x1,0d2c8a2b7d8e5cb04456b34d68484de0eb1c5ce92906e9477f0196933fd5add933cc6f04136d655474872ae16d347b2b2677d7848675c69bb2a3bd4666023646,ba5b5226feb283df4ed0f49b2990db11a00776912831b8059ac46e137f1346283d9b51ef7a4efd3cf6a8e7d33900e264128d42f8d719fc681350b35aaf6ec9e0)
2020-06-10 00:52:18,306 INFO  f.a.eclair.Diagnostics CON n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - IN msg=ChannelReestablish(4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152,1,0,PrivateKey(0000000000000000000000000000000000000000000000000000000000000000),024e15e12457d747d318f4d42ad3e135f2f107ce484ad700e05c714c3ef7e4ac84)
2020-06-10 00:52:18,307 INFO  f.a.eclair.Diagnostics n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - IN msg=FundingLocked(4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152,02449c86ea4e6d8a6f486c49bf84921f9fa950578db78cab7204d46a62f69b536c)
2020-06-10 00:52:18,307 INFO  f.a.e.i.Peer$MessageLogs SYN n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - IN msg=AnnouncementSignatures(4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152,633911x2048x1,0d2c8a2b7d8e5cb04456b34d68484de0eb1c5ce92906e9477f0196933fd5add933cc6f04136d655474872ae16d347b2b2677d7848675c69bb2a3bd4666023646,ba5b5226feb283df4ed0f49b2990db11a00776912831b8059ac46e137f1346283d9b51ef7a4efd3cf6a8e7d33900e264128d42f8d719fc681350b35aaf6ec9e0)
2020-06-10 00:52:18,307 INFO  f.a.e.i.Peer$MessageLogs CON n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - IN msg=ChannelReestablish(4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152,1,0,PrivateKey(0000000000000000000000000000000000000000000000000000000000000000),024e15e12457d747d318f4d42ad3e135f2f107ce484ad700e05c714c3ef7e4ac84)
2020-06-10 00:52:18,307 INFO  f.a.e.i.Peer$MessageLogs n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - IN msg=FundingLocked(4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152,02449c86ea4e6d8a6f486c49bf84921f9fa950578db78cab7204d46a62f69b536c)
2020-06-10 00:52:18,307 WARN  f.a.e.channel.Channel SYN n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - unhandled event AnnouncementSignatures(4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152,633911x2048x1,0d2c8a2b7d8e5cb04456b34d68484de0eb1c5ce92906e9477f0196933fd5add933cc6f04136d655474872ae16d347b2b2677d7848675c69bb2a3bd4666023646,ba5b5226feb283df4ed0f49b2990db11a00776912831b8059ac46e137f1346283d9b51ef7a4efd3cf6a8e7d33900e264128d42f8d719fc681350b35aaf6ec9e0) in state SYNCING
2020-06-10 00:52:18,307 INFO  f.a.e.io.PeerConnection SYN n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda - setting up gossipTimestampFilter=GossipTimestampFilter(6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000,1591743140,4294967295)
2020-06-10 00:52:18,310 INFO  f.a.e.channel.Channel n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - received their FundingLocked, deferring message
2020-06-10 00:52:18,374 INFO  f.a.e.b.b.ZmqWatcher - triggering WatchConfirmed(Actor[akka://eclair-node-gui/user/$l/switchboard/peer-031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda/$a#1046684304],53418039d79fb0650d6d435b602d779c3e66d341070ab4f60a116310fed2cd4a,ByteVector(34 bytes, 0x0020e91a7c0337f49ebafae520cfe1d5ca3651eb6867dba781129b08346dc0042a78),3,BITCOIN_FUNDING_DEPTHOK)
2020-06-10 00:52:18,377 INFO  f.a.e.io.PeerConnection SYN n:03cd75b4da2dcb7d1f3267f647ee5d17be436f10f02809351f191d37959a4cf290 - sent announcements: channels=0 updates=15 nodes=1
2020-06-10 00:52:18,380 INFO  f.a.e.channel.Channel n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - channelId=4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 was confirmed at blockHeight=633911 txIndex=2048
2020-06-10 00:52:18,388 INFO  f.a.e.i.Peer$MessageLogs n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - OUT msg=FundingLocked(4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152,02afa92cc399725f5fc90e35c441d55755d859bd1e8889bdb2bb596d40eedcb7de)
2020-06-10 00:52:18,389 INFO  f.a.eclair.Diagnostics n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - OUT msg=FundingLocked(4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152,02afa92cc399725f5fc90e35c441d55755d859bd1e8889bdb2bb596d40eedcb7de)
2020-06-10 00:52:18,461 INFO  f.a.e.b.b.ZmqWatcher - triggering WatchConfirmed(Actor[akka://eclair-node-gui/user/$l/switchboard/peer-031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda/$a#1046684304],53418039d79fb0650d6d435b602d779c3e66d341070ab4f60a116310fed2cd4a,ByteVector(34 bytes, 0x0020e91a7c0337f49ebafae520cfe1d5ca3651eb6867dba781129b08346dc0042a78),6,BITCOIN_FUNDING_DEEPLYBURIED)
2020-06-10 00:52:18,589 INFO  f.a.e.db.BackupHandler - database backup triggered by channelId=4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 took 200ms
2020-06-10 00:52:18,592 INFO  f.a.e.channel.Channel n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - emitting channel_update=ChannelUpdate(4a3b8ca6cbc3f01ffb1cdb4479b9ccf710750f2618b50e505bb49ebb83a351392e4d88773d008671fae7f4de10d24cdeb11e1a798c27bc0bbd1400bccdb60777,6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000,633911x2048x1,1591743138,1,2,CltvExpiryDelta(120),1 msat,1000 msat,500,Some(400000000 msat),ByteVector(empty)) enabled=false
2020-06-10 00:52:18,593 INFO  f.a.e.channel.Channel n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - funding tx is deeply buried at blockHeight=633911 txIndex=2048 shortChannelId=633911x2048x1
2020-06-10 00:52:18,603 INFO  f.a.eclair.router.Router SYN n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda - received reply_channel_range with 8000 channels, we're missing 4150 channel announcements and 16000 updates, format=UNCOMPRESSED
2020-06-10 00:52:18,709 INFO  f.a.e.i.Peer$MessageLogs SYN n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - OUT msg=AnnouncementSignatures(4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152,633911x2048x1,60913f52d6f22ccfce295a9d0ba019a19eb0463798515518651c7874f467f57452839761f9ec1d0849eb54f6d1346115fe76df6067e8ec301777a3bb60cc3d77,593e4559719e3c5192fd92c8111b855b9e6a6b08a494e397a369bc9ec03d59cc7430116d64a0c11885bd4c791806bcc0cbdbec895e4e58d802bb54aa365a8d53)
2020-06-10 00:52:18,709 INFO  f.a.eclair.Diagnostics SYN n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - OUT msg=AnnouncementSignatures(4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152,633911x2048x1,60913f52d6f22ccfce295a9d0ba019a19eb0463798515518651c7874f467f57452839761f9ec1d0849eb54f6d1346115fe76df6067e8ec301777a3bb60cc3d77,593e4559719e3c5192fd92c8111b855b9e6a6b08a494e397a369bc9ec03d59cc7430116d64a0c11885bd4c791806bcc0cbdbec895e4e58d802bb54aa365a8d53)
2020-06-10 00:52:18,814 INFO  f.a.eclair.router.Router SYN n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda - received reply_channel_range with 8000 channels, we're missing 793 channel announcements and 16000 updates, format=UNCOMPRESSED
2020-06-10 00:52:18,826 INFO  f.a.e.db.BackupHandler - database backup triggered by channelId=4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 took 234ms
2020-06-10 00:52:18,962 INFO  f.a.e.db.BackupHandler - database backup triggered by channelId=4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 took 136ms

seems like my node is at fault and refusing to take the channel out of syncing. It shouldn't be in syncing and rather stay in wait_for_funding_locked or wait_for_confirmation
The channel was already stuck in syncing long before the first confirmation.

Ok so it looks like at some point you got disconnected before the funding tx confirmation (this is why the channel is in SYNCING state).
The channel is still SYNCING because we're waiting for a channel_reestablish (since we were disconnected). It looks like we follow this requirement from the spec:
- upon reconnection:
    - if a channel is in an error state:
        - (...)
    - otherwise:
        - MUST transmit channel_reestablish for each channel.
        - MUST wait to receive the other node's channel_reestablish message before sending any other messages for that channel.

So we ignore the announcement_signatures because we didn't receive (or didn't correctly handle) a channel_reestablish to make us go back to the wait_for_funding_locked state.
Could you look for logs before 2020-06-09 20:55:50,257 to verify that 1) there was indeed a disconnection and 2) check that we didn't miss the channel_reestablish message for some reason?
Maybe @STAWKEYE's logs can also help check what was seen from the other side of the channel (if a disconnection was observed, if a channel_reestablish was attempted or not, etc).

In the logs, here is the portion at the creation of the funding tx, and then after the "..." is the first instance of "re-establish" many hours later, possibly when peer forced it to reconnect?
Theseus_Log.txt

I think it would be useful to see the truncated part of the logs, can you look for:

a disconnection
whether funding_locked was sent/received
whether channel_reestablish was sent/received

This is what came up:
2020-06-09 14:43:29.441 [ERR] FNDG: unable to report short chan id: link 4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 not found
2020-06-09 14:43:29.445 [INF] FNDG: Peer(02e9046555a9665145b0dbd7f135744598418df7d61d3660659641886ef1274844) is online, sending FundingLocked for ChannelID(4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152)
2020-06-09 14:43:29.446 [INF] CHBU: Updating on-disk multi SCB backup: num_old_chans=1, num_new_chans=1
2020-06-09 18:52:20.173 [INF] HSWC: ChannelLink(633911:2048:1): resending FundingLocked message to peer
2020-06-09 18:52:20.173 [INF] HSWC: ChannelLink(633911:2048:1): received re-establishment message from remote side
2020-06-09 18:52:20.173 [INF] DISC: GossipSyncer(02e9046555a9665145b0dbd7f135744598418df7d61d3660659641886ef1274844): applying gossipFilter(start=2020-06-09 18:52:20.1730941 -0400 EDT m=+35855.866903401, end=2156-07-17 00:20:35.1730941 -0500 EST m=+4295003150.866903401)
2020-06-09 18:52:20.190 [INF] DISC: GossipSyncer(02e9046555a9665145b0dbd7f135744598418df7d61d3660659641886ef1274844): sending final chan range chunk, size=5327
2020-06-09 18:52:20.633 [INF] PEER: Already have ChannelPoint(53418039d79fb0650d6d435b602d779c3e66d341070ab4f60a116310fed2cd4a:1), ignoring.
2020-06-09 18:52:20.633 [INF] PEER: Processing retransmitted FundingLocked for ChannelPoint(53418039d79fb0650d6d435b602d779c3e66d341070ab4f60a116310fed2cd4a:1)
2020-06-09 18:52:20.778 [INF] DISC: GossipSyncer(02e9046555a9665145b0dbd7f135744598418df7d61d3660659641886ef1274844): fetching chan anns for 100 chans
2020-06-09 18:52:20.866 [INF] DISC: Received new remote channel announcement for 633911:2048:1
2020-06-09 18:52:20.884 [INF] DISC: Fully valid channel proof for short_chan_id=696992515609329665 constructed, adding to next ann batch
2020-06-09 22:17:11.944 [INF] DISC: GossipSyncer(02e9046555a9665145b0dbd7f135744598418df7d61d3660659641886ef1274844): sending final chan range chunk, size=5405
2020-06-09 22:17:12.014 [INF] HSWC: ChannelLink(633911:2048:1): received re-establishment message from remote side
2020-06-09 22:17:12.148 [INF] DISC: Received new remote channel announcement for 633911:2048:1
2020-06-09 22:17:12.439 [INF] DISC: GossipSyncer(02e9046555a9665145b0dbd7f135744598418df7d61d3660659641886ef1274844): fetching chan anns for 100 chans

hmmm... sorry for the newbie question, but how do you guys format the pasted logs so that they scroll and don't spam up the thread with wrapped text?

2020-06-09 10:07:15.247 [INF] PEER: disconnecting 02e9046555a9665145b0dbd7f135744598418df7d61d3660659641886ef1274844@<IP_ADDRESS>:9735, reason: Peer 02e9046555a9665145b0dbd7f135744598418df7d61d3660659641886ef1274844@<IP_ADDRESS>:9735 no answer for 5m0s -- disconnecting
2020-06-09 10:07:15.248 [INF] PEER: unable to read message from 02e9046555a9665145b0dbd7f135744598418df7d61d3660659641886ef1274844@<IP_ADDRESS>:9735: read tcp <IP_ADDRESS>:50436-><IP_ADDRESS>:9050: use of closed network connection
2020-06-09 10:07:15.348 [INF] DISC: Removing GossipSyncer for peer=02e9046555a9665145b0dbd7f135744598418df7d61d3660659641886ef1274844
2020-06-09 10:07:15.348 [INF] DISC: GossipSyncer(03eb4425070e2d1f3ce13c550e8e02307270039aca1a0603b9c56193923cf66324): applying gossipFilter(start=2020-06-09 10:07:15.3483808 -0400 EDT m=+4351.042190101, end=2156-07-16 15:35:30.3483808 -0500 EST m=+4294971646.042190101)
2020-06-09 10:07:16.945 [INF] SRVR: Established connection to: 02e9046555a9665145b0dbd7f135744598418df7d61d3660659641886ef1274844@<IP_ADDRESS>:9735
2020-06-09 10:07:16.946 [INF] SRVR: Finalizing connection to 02e9046555a9665145b0dbd7f135744598418df7d61d3660659641886ef1274844@<IP_ADDRESS>:9735, inbound=false
2020-06-09 10:07:17.205 [INF] PEER: NodeKey(02e9046555a9665145b0dbd7f135744598418df7d61d3660659641886ef1274844) loading ChannelPoint(53418039d79fb0650d6d435b602d779c3e66d341070ab4f60a116310fed2cd4a:1)
2020-06-09 10:07:17.206 [WRN] PEER: Unable to find our forwarding policy for channel 53418039d79fb0650d6d435b602d779c3e66d341070ab4f60a116310fed2cd4a:1, using default values
2020-06-09 10:07:17.207 [INF] SRVR: Negotiated chan series queries with 02e9046555a9665145b0dbd7f135744598418df7d61d3660659641886ef1274844
2020-06-09 10:07:17.207 [INF] DISC: Creating new GossipSyncer for peer=02e9046555a9665145b0dbd7f135744598418df7d61d3660659641886ef1274844
2020-06-09 10:07:18.379 [INF] CRTR: Processed channels=0 updates=12 nodes=0 in last 59.9983834s
Also
2020-06-09 18:52:17.686 [INF] PEER: unable to read message from 02e9046555a9665145b0dbd7f135744598418df7d61d3660659641886ef1274844@<IP_ADDRESS>:9735: EOF
2020-06-09 18:52:17.688 [INF] PEER: disconnecting 02e9046555a9665145b0dbd7f135744598418df7d61d3660659641886ef1274844@<IP_ADDRESS>:9735, reason: read handler closed

So we ignore the announcement_signatures because we didn't receive (or didn't correctly handle) a channel_reestablish to make us go back to the wait_for_funding_locked state.

AnnouncementSignatures and ChannelReestablish in lnd are not synchronized as tightly as the current version of the spec suggests, it's not uncommon to send AnnouncementSignatures before  ChannelReestablish. This behavior has existed as long as I can remember but only recently did this stricter ordering receive clarification in the spec, I presume Eclair had a way of handling this in the past? Curious if the processing might have changed on your end in this regard.
In Theseus_Log.txt I see
2020-06-09 18:52:17.686 [INF] PEER: unable to read message from 02e9046555a9665145b0dbd7f135744598418df7d61d3660659641886ef1274844@<IP_ADDRESS>:9735: EOF
2020-06-09 18:52:17.688 [INF] PEER: disconnecting 02e9046555a9665145b0dbd7f135744598418df7d61d3660659641886ef1274844@<IP_ADDRESS>:9735, reason: read handler closed

2020-06-09 18:52:20.172 [INF] HSWC: ChannelLink(633911:2048:1): attempting to re-resynchronize
2020-06-09 18:52:20.173 [INF] HSWC: ChannelLink(633911:2048:1): resending FundingLocked message to peer
2020-06-09 18:52:20.173 [INF] HSWC: ChannelLink(633911:2048:1): received re-establishment message from remote side
2020-06-09 18:52:20.633 [INF] PEER: Processing retransmitted FundingLocked for ChannelPoint(53418039d79fb0650d6d435b602d779c3e66d341070ab4f60a116310fed2cd4a:1
2020-06-09 18:52:20.866 [INF] DISC: Received new remote channel announcement for 633911:2048:1

So from LND's PoV we have
XX Disconnect XX

ChannelReestablish -->
FundingLocked -->
 <-- ChannelReestablish
 <-- FundingLocked
 <-- AnnouncementSignatures

These logs don't show when LND sends its AnnouncmentSignatures, but according to the Eclair logs it was received before the ChannelReestablish.
@STAWKEYE thanks for the logs! you can use single back ticks for inline, and
triple back ticks to do blocks

So from LND's PoV we have [...]

Can you clarify where you see that from the lnd logs?
I can't see where lnd says it's sending its channel_reestablish...and from what I understand of the eclair logs, eclair doesn't seem to receive it.
@viaj3ro @STAWKEYE this is really hard to debug with only a partial view of the messages exchanged. It would be really helpful if you could both share the logs for what happened before @viaj3ro manually disconnected/reconnected (which seemed to happen at 2020-06-10 00:52:15,521 UTC). What happens after this reconnection isn't very interesting because it's the part that worked correctly (the channel was back up and working after the manual reconnection).

@t-bast Here's the full logs up until the above mentioned time. Unfortunately my logs appear to be in local time (EST) and so your timestamp corresponds to 2020-06-09 20:52 EST if I did that correctly.
Theseus_Log_Full.txt

Can you clarify where you see that from the lnd logs?

It's a little tough to infer, the logs aren't showing PEER which shows the actual wire ordering, they're a bit higher level.
That said, this line is logged before sending channel reestablish:
2020-06-09 18:52:20.172 [INF] HSWC: ChannelLink(633911:2048:1): attempting to re-resynchronize

Also ignore my prior ordering diagram, just noticed that the logs on LND's side is actually out of order with the actual message sequence (we should fix that). We log that we received ChannelReestablish after deciding whether to retransmit FundingLocked, so actually the exchange looked like this, which seems correct apart from not showing when/if LND sent AnnouncementSignatures:
XX Disconnect XX

ChannelReestablish -->
 <-- ChannelReestablish
FundingLocked -->
 <-- FundingLocked
 <-- AnnouncementSignatures

I don't think this should be an issue. If AnnouncementSignatures is received before ChannelReestablish we simply ignore it, it will only delay the moment where the channel will be announced but shouldn't be blocking.

Cool, also considering that the above looks correct, i think we can rule out issues related to ChannelReestablish and focus on the initial, unbroken connection.
@STAWKEYE are you able to upload a more complete section of logs to pastebin? I'm happy to grep through them for the relevant info. As @t-bast notes it'd be useful to have older logs, ideally as early as the channel funding (if that's possible).

@cfromknecht The prior linked logs (Theseus_Log_Full.txt) was full from the initial setup of LND up until 2020-06-10 00:52:15,521 UTC at which point  @viaj3ro manually disconnected/reconnected (which seemed to happen at 2020-06-10 00:52:15,521 UTC).

Here is what I can understand from the lnd logs:

Funding initiated around 2020-06-09 09:07:32 EST by lnd
Disconnection around 2020-06-09 10:07:15 EST
Reconnection right after that
Unclear from the lnd logs if channel_reestablish was sent by lnd
Funding locked happened around 2020-06-09 14:43:29 EST, sent from lnd to eclair
Disconnection around 2020-06-09 18:52:17 EST (manual disconnect by @viaj3ro)
Reconnection right after that
Channel reestablish received by lnd
Funding locked re-sent from lnd to eclair
Unclear from the lnd logs if channel_reestablish was sent by lnd

One notable difference is that after the second disconnect/reconnect (which happened around 2020-06-09 18:52:17 EST) there is this log line in lnd that wasn't there for the first disconnect/reconnect:
2020-06-09 18:52:20.173 [INF] HSWC: ChannelLink(633911:2048:1): received re-establishment message from remote side

Eclair should have sent a channel_reestablish at that point, it would be interesting to verify that.
If @viaj3ro could post the logs from the eclair side it would be really helpful, we log all incoming/outgoing messages so it will be easy to check.

I'm traveling atm. Will try to get you the logs asap

@t-bast thanks the details, in grepping through the logs I came to the same conclusions and I think I've pinpointed the issue.
After disconnecting/reconnecting with a pending channel, LND doesn't immediately send ChannelReestablish. Instead it waits on another subsystem to process the FundingLocked message as if the connection had never been broken.
The interaction enters a message-level deadlock because LND is waiting for Eclair to send FundingLocked, but Eclair won't send FundingLocked until it receives a ChannelReestablish from LND. LND-to-LND channels never experience this issue because they always resend FundingLocked if they detect the channel in a pending state, and can handle either ordering of FundingLocked and ChannelReestablish.
The "simple" solution is for LND to move it's funding locked handling into the htlcswitch rather than the fundingmanager, which is a change I've been wanting to make for some time. In 0.10 we did a bit of refactoring in this area in order to prepare for the transition, so it is on the radar.
In practice though this refactor turns out to be somewhat difficult since fundingmanager coordinates two or three other independent subsystems in making a channel active. We also need to consider how to do make the change in backwards compatibility with older LND nodes, otherwise newer LND nodes will enter this same deadlock with older ones as they upgrade.
For some time this coordination logic will be need to be spread across two different locations,  further complicated by differing subsystem lifetimes, locking precedence, etc. The amount of effort and testing required to make the change properly is relatively high compared to the gain, which is why it tends to sit pretty low on the list of priorities. That being said, it has been a part of my agenda to prioritize more incremental improvements in this area, but it's probably not going to happen overnight sadly.

Gotcha, thanks for the details! I totally get that refactoring these parts of the code always take more time than expected. This bug is in no way critical, a simple reconnection after the FundingLocked fixes it which is acceptable.

Thanks for all the help in investigating 🥂

yeah, as long as the channel can get unstuck manually it's not really a big deal.
 So far I wasn't able to reproduce this behavior though. Will keep an eye on it and report here, if it happens again.

 So far I wasn't able to reproduce this behavior though. Will keep an eye on it and report here, if it happens again.

 So far I wasn't able to reproduce this behavior though. Will keep an eye on it and report here, if it happens again.

Unfortunately I was finally able to reproduce this bug:
https://github.com/ACINQ/eclair/issues/1444#issuecomment-768892483


I hope to add concurrency settings in OpenAIEmbedding

引用 #250
The following is the official source code
 async embedDocuments(texts: string[]): Promise<number[][]> {
    const subPrompts = chunkArray(
      this.stripNewLines ? texts.map((t) => t.replace(/\n/g, " ")) : texts,
      this.batchSize
    );

    const embeddings: number[][] = [];

    for (let i = 0; i < subPrompts.length; i += 1) {
      const input = subPrompts[i];
      const { data } = await this.embeddingWithRetry({
        model: this.modelName,
        input,
      });
      for (let j = 0; j < input.length; j += 1) {
        embeddings.push(data.data[j].embedding);
      }
    }

    return embeddings;
  }

You can see that this is executed sequentially, although adding batchSize
But embedding is often used in conjunction with splitters, with splitter chunkSize: 1000
Is the default value of batchSize 512?
So I hope to add concurrency, although I know there is an openai frequency limit, I still hope to have concurrency parameters to control concurrency.
I am using gitbook loader -->splitter -->embedding -->qdrant
This made me wait for 30 minutes, it's too slow, I can't accept it

This would be great! Would love a PR.


Feature request: login using Google

The client.login() method only supports user login using NitroType native username and password.  But Nitro Type supports login via Google as well as Facebook and Clever.  How about adding 3rd party login support?

Hey @happywisepaul! I'm not actively developing this anymore, but feel free to make a PR to add this feature.


Fix Prolog file detection regex

Problem: filetype: .pro file detection for Prolog is broken
Solution: fixed the regex to only match on the tested cases (igna_martinoli)
Fixes: https://github.com/vim/vim/issues/10835
Closes: https://github.com/vim/vim/pull/15206

thanks!

included as of<PHONE_NUMBER>eb2de23a78c51a4388c9080440eec4


fix: run go serve load env use Overload

What's the benefit of this change?

change .env file in project root dir in docker ; if environment variables has defined in sys, can't to load  those in the .env file; just use  environment variables which defined in .env file...........

change .env file in project root dir in docker container ; if environment variables has defined in sys user mode, can't to load those in the .env file; just use environment variables which defined in .env file.

Does source .env work for you?

@wangyoucao577 yes, is work,  need set  vars in .env
AGORA_APP_ID=***
AGORA_APP_CERTIFICATE=***

if not set those env, use user mod defined vars $AGORA_APP_CERTIFICATE,
if vars both in .env and defined vars; so  want use Overload  use vars in .env; :)

@wangyoucao577 yes, is work, need set vars in .env
AGORA_APP_ID=***
AGORA_APP_CERTIFICATE=***

if not set those env, use user mod defined vars $AGORA_APP_CERTIFICATE, if vars both in .env and defined vars; so want use Overload use vars in .env; :)

OK. So use overload to force to use .env seems a little bit no sense here. export XXX should has higher priority than .env, which is more intuitive. On the other hand, the godotenv also warns that use the Overload if needed with caution. So use Overload instead of Load here may not a good choice.

..... but just change the Secrets(such as api key, app token) in .env file, don't to use in user mode defined vars.  unsafe.


[ie/NYTimes] - Extractor overhaul - Article, Cooking Recipes and Guides

IMPORTANT: PRs without the template will be CLOSED
Description of your pull request and other information

This is the first PR of my attempt to overhaul the existing, non working, extractor.
I'm pretty sure there is a lot to optimize on the code I'm submitting.
To try and facilitate the process, I decided to break all the adjustments I made in different PRs.
This first PR covers:

General Articles
Cooking Recipes
Cooking Guides

Fixes #8605 #2899
Future PRs will cover the extraction of:

Video Playlist (and single video)
Podcasts / Audio / Book Review

Template

Before submitting a pull request make sure you have:

[X] At least skimmed through contributing guidelines including yt-dlp coding conventions
[X] Searched the bugtracker for similar pull requests
[X] Checked the code with flake8 and ran relevant tests

In order to be accepted and merged into yt-dlp each piece of code must be in public domain or released under Unlicense. Check all of the following options that apply:

[X] I am the original author of this code and I am willing to release it under Unlicense
[ ] I am not the original author of this code but it is in public domain or released under Unlicense (provide reliable evidence)

What is the purpose of your pull request?

[X] Fix or improvement to an extractor (Make sure to add/update tests)
[ ] New extractor (Piracy websites will not be accepted)
[ ] Core bug fix/improvement
[ ] New feature (It is strongly recommended to open an issue first)

I made an edit to one of the review comments just now. Please make sure to work from the latest version of the comments before applying suggestions locally

Side note: I'm using the 👍 in the comments to track the changes I applied in the local code.

I made an edit to one of the review comments just now. Please make sure to work from the latest version of the comments before applying suggestions locally

I believe I got everything. Thank you.

It was trivial to (mostly) fix NYTimesIE with the code we already had, so I went ahead and did so. We are missing the timestamp/upload_date, though


feature: ExecutableExpression

This pull request adds a new utility class, called ExecutableExpression:

ExecutableExpressions are syntaxes that can act like expressions and stand-alone effects.
A great example of this would be the replace all {x} in {y} with {z}-effect. Other examples could be the peek/poll/offer methods in Queues, which I'm also going to implement later.
Basic implementation of the Effect part: just call getValues() while ignoring the results.
Implements SelfRegistrable, allowing an easy registration process.

Currently, there isn't any implementation for this, but after my Number API PR (#75) is merged, I am going to add some String syntaxes, one of which is the replace-effect from Skript.
(Messed up so needed to remake my pull request)

I'm going to merge this despite the ongoing discussion because I think it's a nit-pick. This is all very simple code and I think major flaws would have been detected by now.


[WFLY-13579] adjust testsuite waiting times with the timeout factor

https://issues.redhat.com/browse/WFLY-13579
Making the Thread.sleep and other timeout calls in testsuite to be parametrized by timeout factor (defined in {{TimeoutUtil}} shared testsuite config class).

@kabir @bstansberry could this change be considered for merging or is it something that's not suitable?

@ochaloup Adding TimeoutUtil to test classes that get deployed means you also have to add permissions.xml settings to the deployment to allow TimeoutUtil to do its thing (i.e. read system properties.) I assume needing this is why there are lots of failures in the security manager job.
Please ask @chengfang or @tadamski to review the EJB bits and @ehsavoie to look at the messaging ones.  That's the bulk of it.

@bstansberry my bad. thanks Brian for pointing that. I fixed the permissions and hopefully the security manager tests will pass.
@chengfang thank you for the review

Regarding the test failures there are only for Windows JDK11. Those seems not to be caused by these changes.

Thanks, @ochaloup


Remove PartitionResolutionRequestTimeout from Backend

This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process.
PR information

[x] The title of the PR is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
[x] Except for special cases involving multiple contributors, the PR is started from a fork of the main repository, not a branch.
[x] If applicable, the PR references the bug/issue that it fixes.
[x] Swagger files are correctly named (e.g. the api-version in the path should match the api-version in the spec).

Quality of Swagger

[x] I have read the contribution guidelines.
[x] My spec meets the review criteria:

[x] The spec conforms to the Swagger 2.0 specification.
[x] The spec follows the guidelines described in the Swagger checklist document.
[x] Validation tools were run on swagger spec(s) and have all been fixed in this PR.

@fearthecowboy can you take a look. This is a minor edit to our spec. We have not published our .net client yet.

No modification for AutorestCI/azure-sdk-for-ruby

No modification for AutorestCI/azure-sdk-for-python

No modification for AutorestCI/azure-sdk-for-node


[TODO] Remove some redundancy from the app

There's currently a number of redundant things in the app.
There are currently two settings items.  The gear icon to the right of the (R) and it's menu should be removed.  The one in the (R) User Icon menu is the one we want to keep.
However, there is no settings modal or anything that opens when the one in the (R) User Icon menu is clicked.
Create a new modal that opens in the center of the screen when the Settings icon is clicked on in the User Icon drop down context menu.
I haven't really decided on what this modal should contain but open to suggestions here.

This also needs removed.


Fix bits_per_byte metric in PerplexityTask

bits_per_byte was calculated as average per-byte loglikelihood, which would work if loglikelihood was base-2 log,
but it is natural log. To correct for that, bits_per_byte should be divided by math.log(2).
Also, it should be true that 2^bits_per_byte == byte_perplexity, which is true after the fix.

This change looks good, we just need to bump all of the versioning for all PerplexityTask deriving tasks before merge for backwards compat

This change looks good, we just need to bump all of the versioning for all PerplexityTask deriving tasks before merge for backwards compat

Bumped!
I'm not sure what testing is necessary to validate the version bump. I validated hand-tested the bits_per_byte calculation prior to the version bump. Let me know if you want me to run anything in particular to validate.


Renew user id after order has been successfully completed

If two different users make an order in the same session without refreshing the browser, they will share the same userId. We should clear the client (redux) state after an order has been successfully completed to prevent multiple orders with the same user Id.
Resolves all3dp/printing-engine#212

User acceptance test:
User ordered two individual orders on the 21st of September, he received the same email for both orders.


provide show/hide keyboard functionnality

it will be really usefull

I'm pretty sure you can't trigger a keyboard to show or hide without specifying a FirstResponder. In other words, to get a keyboard to show, you must trigger a focus event on an input box, and trigger a blur event to hide it. Reopen if you see another way, or please submit a pull request.


Typo in euclidean division code

For example, 15 = 4 * 4 + (-1) = 3 * 4 + 3, quotient was 4 now is 3, remainder was -1 now is 3, so it should be quotient -= 1.

In our tutorial, the remainder is always positive