Added the AutoClose property to the Accordion.

Added the AutoClose property to the Accordion. By default, it is true. If the user clicks on an already open item, it closes. If it is false, if the user clicks on an already open item, it remains open.

Thanks for the pull request @marcelaopimenta however I don't remember any other users needing such feature. Can you provide a bit more details? You don't want already expanded item to be collapsed?

Hi Vladimir, how are you!?
In my case I need one item of the accordion to always be open. Here is an
example. In a payment form the user must choose one. Credit Card or PIX
(Braziian Payment)
[image: image.png]
Or
[image: image.png]
Another user needed this, but for another business rule.
https://forum.radzen.com/t/prevent-accordian-component-from-closing/3662
Best Regards
Marcelo Fernandes
Gtalk ou Email: @.***
Skype: marcfsp
On Wed, Dec 18, 2024 at 8:53 AM Vladimir Enchev @.***>
wrote:

Thanks for the pull request @marcelaopimenta
https://github.com/marcelaopimenta however I don't remember any other
users needing such feature. Can you provide a bit more details? You don't
want already expanded item to be collapsed?
—
Reply to this email directly, view it on GitHub
https://github.com/radzenhq/radzen-blazor/pull/1861#issuecomment-2551128371,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAYYAHW3EFTJHIRBHYKLVLD2GFO5LAVCNFSM6AAAAABTZBUCSCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJRGEZDQMZXGE
.
You are receiving this because you were mentioned.Message ID:
@.***>


Multi-hop graph relationships

In building multi-hop queries, is there currently a method to retrieve the node ids along with the attributes?
i.e for the query
MATCH (A{id: "Vikings"})-[R*0..3]->(B{id: "England"})
RETURN A, R, B
LIMIT 1

The source and target nodes could be added as attributes. In looking at the code, it's also straightforward to add those in all cases or with multi-hop relationships. Lastly, the openCypher standard has startNode and endNode functions.
Curious if there are any thoughts on this use case.

I think we have a lot of the heavy lifting already set up for this (#24), but we don't currently implement it!
Linking #23 and #26 for cross-reference!

Interesting, I'll take a look. I'm happy to submit a PR for this feature. It sounds like you'd like it to behave like what was proposed in #26?

That would be so awesome!! I'd need to take a look at the openCypher spec again; the ideal functionality is 1-to-1 feature parity with how this is handled in existing implementations. Which I think is what we mentioned in #26...

Sounds great.
In reading the openCypher spec here - https://s3.amazonaws.com/artifacts.opencypher.org/openCypher9.pdf
And it looks like for a query like this (page 65).
MATCH p = (charlie:Person)-[* {blocked:false}]-(martin:Person)
WHERE charlie.name = 'Charlie Sheen' AND martin.name = 'Martin Sheen'
RETURN p

It returns a list like this for each row.
[Node[0]{name:"Charlie
Sheen"},:X[20]{blocked:false},Node[20]{},:X[21]{blocked:false},Node[1]{name:"Martin Sheen"}]

I think most of the work is already done for this. It looks to just be a matter of changing the parser spec to handle the path definition <var> =  and returning the path. In looking at the example though, it's hard to see how that maps to a Python structure. Is it a list of single element dictionaries?

Hm weird — yeah, I'd interpret that as an iterable of Vertex elements, like
[
# Node
{id: 0, name:"Charlie Sheen"},
# Edge:X
{id: 20, blocked:false},
# Node
{id: 20},
# Edge:X
{id: 21, blocked:false},
# Node
{id: 1, name:"Martin Sheen"}
]

There is the issue that we don't really have a good way of distinguishing vertex and edge entities as dictionaries... In our graph repr, we have the __labels__ attr that we're more or less standardizing kinda just by virtue of using it in a lot of places now (https://github.com/aplbrain/grand-cypher/pull/25) (gc-io), which is maybe a way to do this...
{id: 1, name:"Martin Sheen", __labels__=["Vertex"]}

though I really don't like the idea of a vertex having a different number of attributes than it has in the db...
Curious what you think @davidmezzetti! Also tagging @khoale88 who has had a lot of good insight on this in the past :)

Adding an attribute that notes the type seems to make sense to me.

I haven't touched this for quiet sometime, but luckily I'm still be able to recall something. Here are my 2 cents. The decision can depend on how the information is used.

If we don't want to touch the core code for now and accessing path entity type is not mandatory, a custom structure can work as the 1st iteration. Something like this would be enough for the human readability.

class NodePathView(dict):
  def __repr__(self):
    return f"Node{super().__repr__()}"

To go further, I think that putting additional attribute in the labels might not be as friendly as having a separated attributes, both in code clarity and performance wise. I perfer to have a dedicated attribute for this, since this attribute is static. Though, I rekon that reusing labels can save us some development effort. Using labels is definitely a good beginning. One note is that try to make it the same for both vertex and edge so that we don't have to remember 2 different things.

Fixed with #37


[release-1.27] [occm] Use standard service account name in OCCM helm chart

What this PR does / why we need it:
This is a cherry-pick of:

#2332
#2347

Which issue this PR fixes(if applicable):
fixes #2440
Special notes for reviewers:
At the time #2332 was merged the CI was sadly somewhat broken and missed a spurious space. This has been fixed in #2347 which is also included here to ensure that CI is passing.
As discussed, I bumped the helm chart version to 2.27.6.
I've also tested this helm chart version in a new 1.27 cluster and was unable to reproduce the bug fixed in #2332.
Please let me know if you'd like me to combine (i.e. squash/fixup) both commits in here into a single, correct, one.
Release note:
ACTION REQUIRED: Please note that you might have to delete the `cloud-controller-manager` service account in the `kube-system` namespace if it exists, as upgrading with helm would fail otherwise.

/lgtm

/approve


Add embedding fix

Description
Blanks in the same sequence accumulate changes to embedding from other blanks (previously, they just added their embeddings to preblank)
Checklist

[x] Is this PR focused on a single feature without the possibility of being divided into smaller PRs?
[x] Are all variables set with logical defaults that are backward compatible?
[x] I attached link to neptune if it was necessary
[x] Have you successfully executed the linter and tests?
[x] Are all functions concise and don't require splitting?
[x] Is there documentation for arguments and complex logic?
[x] Are there no temporary solutions in the code? Should a task be added to Trello to refine the code?
[x] Are all functions placed in appropriate files?
[x] Is the PR name meaningful and descriptive?
[x] Is PR description provided, or unnecessary?

Other questions:

[x] If I made changes to the requirements or anything related to the Singularity image I did generate new image and upload a new image to the clusters
[x] If this change is significant enough I notified all individuals working with this repository (@channel in slack channel)
[x] If there is a need for a second reviewer I requested additional review

Reviewer's checklist:

[ ] Does the Neptune link work and does it actually compare the situation before and after the PR?
[ ] Do I understand the code?
[ ] Do I think another reviewer is not needed or I commented that this PR need another reviewer?

Looks like it's working: https://app.neptune.ai/o/pmtest/org/llm-random/runs/compare?viewId=9a15aa36-1063-49c4-807d-53393abb118a&dash=charts&query=&sortBy=["sys%2Fcreation_time"]&sortFieldType=["datetime"]&sortFieldAggregationMode=["auto"]&sortDirection=["descending"]&lbViewUnpacked=true&compare=MwFgrGA0CMkOxA

It's probably alright, but we'd like to focus on fixing the residual blank, not adding to embedding.


Chrome resize issue: data-sizes="auto" in multi grid

Hi.
I am experiencing a weird behavior when I shrink the browser window using Chrome. The image sits in a column of a simple grid which changes its width based on mediaQueries. I am using following markup for the responsive image:
<!--
Styles set in CSS:
.img {
    max-width: 100%;
    max-height: 100%;
    width: auto;
    height: auto;
}
-->
<img src=data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==
     alt="foo"
     data-src="orig.jpg"
     data-sizes="auto"
     class="lazyload img"
     data-srcset="300.jpg 300w, 1000.jpg 1000w, orig.jpg 1900w">

The calculated sizes attribute makes the image not spanning across the whole parent (which is a square) – I have to reload the page to get it fit again. The sizes value somehow decreases throughout the shrinking of the window. When I reload the page in the shrunken state, the images (and the sizes value) display at correct sizes. There sometimes a difference of 100px for the sizes value between the resized and reloaded state.
Any ideas? I will try to setup a Codepen to make this obvious.

The problem is documented in the readme. The data-sizes="auto" has no big magic it simply allows you to move the presentational markup (content of the sizes attribute) into your CSS. For this you need to define at least the width of your images. Using width: auto won't work, because lazysizes needs to guess what you want.
I always advice to use the aspect ratio CSS, so that width and height of the images are defined. This might be more work but it really pays off. (https://github.com/aFarkas/lazysizes#tip-specifying-image-dimensions-minimizing-reflows-and-avoiding-page-jumps)
If you don't want, you can also modify how the sizes attribute is calculated by using the lazybeforesizes event. There is also the parent-fit plugin, which does just that.
See also:
http://jsfiddle.net/trixta/w96o9xm5/
Please close, if this helps.

Hi @aFarkas.
Sorry for my late response.
Just to be clear, the outer container of the <img> has a defined ratio with ::after, like in your example. This ratio just do not reflect the ratio of the image (thus height/width auto and max-width/max-height as needed). All works good on page load, just not when the browser is resized. I will investigate further and keep you posted.

This is still an issue with the fact, that width: auto is set on the image.
You can try this for example:
$(document).on('lazybeforesizes', function(e){
    //use width of parent node instead of the image width itself
    (e.originalEvent || e).detail.width = $(e.target).closest(':not(picture)').innerWidth() || (e.originalEvent || e).detail.width;
});

Optionally, what would help is just to use the initial sizes calc, and disable it on resize.

If you don't want, you can also modify how the sizes attribute is calculated by using the lazybeforesizes event. There is also the parent-fit plugin, which does just that.

Does the event fire before every resize?

This is still an issue with the fact, that width: auto is set on the image.
Thanks! Do you have a vanilla JS example somewhere in the docs?

Oh, I also forgot to mention …
img {
  &.lazyload {
    backface-visibility: hidden;
    opacity: 0;
    transition: opacity 400ms;
    width: 100%;
    height: 100%;
    display: block;
  }

  &.lazyloaded {
    backface-visibility: hidden;
    opacity: 1;
    transition: opacity 400ms;
    width: auto !important;
    height: auto !important;
  }
}

//if you use a modern browser/or a closest polyfill:
document.addEventListener('lazybeforesizes', function(e){
    //use width of parent node instead of the image width itself
    e.detail.width = e.target.closest(':not(picture)').offsetWidth || e.detail.width;
});

//if you use a legacy browser and no closest polyfill:
document.addEventListener('lazybeforesizes', function(e){
    //use width of parent node instead of the image width itself
    var parent = e.target.parentNode;

    if(parent.nodeName == 'PICTURE'){
        parent = parent.parentNode;
    }
    e.detail.width = parent.offsetWidth || e.detail.width;
});


Handle fcm endpoints

As gcm is being deprecated, Chrome 74+ is now using fcm endpoints when subscribing to notifications. fcm endpoints need the Authorization header as well, but do not need to change the url.

Great, thanks a lot!

I just pushed the new version to hex. Thanks again.

Thanks!


Show the required dependency in the documentation

For example, https://armeria.dev/docs/advanced-logging needs:
<dependency>
    <groupId>com.linecorp.armeria</groupId>
    <artifactId>armeria-logback</artifactId>
    <version>x.y.z</version>
</dependency>

We are going to define a new React component which shows the dependency statements with switching tabs that show Maven and Gradle(perhaps groovy and Kotlin).


not working after NCU

Hi
i did a NCU and now the project is not starting anymore
can you fix this

@crivera what's NCU, what error message do you see?

i used npm-check-updates to get all the latest versions of the dependencies...
https://www.npmjs.com/package/npm-check-updates
but after running it i get some babel errors etc

Yea, the main reason seems to be the changes in babel 6, it's a major version upgrade with plenty of breaking changes from babel 5 (babel-cli, presets etc).

All the project dependencies have been updated to the most recent versions (Babel 6, React Hot Loader 3 etc.)


Lua config file for game and output resolution

I made a config struct in cpp that is used for now, will prob still want to make it a lua scrip in the future


"Week" view organization

(1) Put textual description with temperature on right side. Similar to point (4) in issue #3.
(2) Combine all data for each day into one row. Having two lines for each day makes it hard to scan, it would be nice if reading down on the left side was just days of the week, like "Today Thursday Friday Saturday . . . ".  To do that, you might consider combining each day into one row, so for example left side is "Thursday" and right side is "Day" superscript over "71 °F, Partly Sunny" and "Night" superscript over "56 °F, Mostly Cloudy".

Another possibility on (2), instead of merging day and night into one row, would be to alternate the background colors of the rows -- probably making nighttime a darker color. It might be that my original suggestion would create a combined row that looks too cluttered.

Hello @xenotropic,
I tried the background solution and i didn't liked the result .. the page was too cluttered ; i mean in my opinion.
I added the icon served from the api to differentiate the daytime and nighttime.. as shown here :


permissions after restart

After restarting, all the files in /var/mail seem to get chowned to postfix?
This results in:
cannot update mailbox /var/mail/root for user root. destination /var/mail/root is not owned by recipient

Hi, can you give some more details about your setup? on error message it sounds a bit like your using postfix to deliver mail to user inboxes etc? is so maybe some other docker image if more suitable?
The chmod postfix https://github.com/wader/postfix-relay/blob/master/run#L54 has been there since the first commit but i have no memory of why it was needed, but i can guess volumes etc messes up owner or permissions somehow


Prepare 0.4 release with tokio 1.0

I was looking around to find an indicator when tokio 0.3 will be released (roughly). Do you have any reference to for that?

@saschagrunert soon, we are currently working on it, there should be a milestone in the tokio repo for it.

Tokio 0.3 has been released!

Work will be going into hyper to get that upgrade so it will be a few days at a min before a new version of tonic, but we are working hard to get there!

See https://github.com/hyperium/hyper/issues/2302 for further information

@LucioFranco
prost v0.7 also released with bytes v1.0

Is the intention still to support tokio 0.3, or to jump straight to the 1.0 release?

Imho it would be better if we switched directly to tokio 1.0

Imho it would be better if we switched directly to tokio 1.0

Hey all sorry for the delay, the plan is this:

Update to the newer version of hyper
Update to utilities in tower when that is released (should be soon)
Refactor the server to fix a couple open bugs (I don't want to release a new version that still has those issues).
Update to prost 0.7

This is what is planned, but its not trivial atm. That said, my focus the last few months (even longer tbh) has been on tokio since we have needed a solid foundation there. Now that my work there is mostly complete (it was to help get it to 1.0), I can now focus on other areas of the stack.
Writing this as of the 28th of Dec and I am on vacation till the new year, so won't get started on this until then. Hopefully, this gives some context on why things have been a bit slow here but now that tokio 1.0 is out there is a lot of planned work that I will finally get too in 2021.

@LucioFranco thank you!
Your contribution to the Rust community is crucial and impressive.
Keep up the good work!

Okay so a little update here, most deps have been updated. I have a PR open to fix the blocking bug. I don't currently have much time to fix all the transport issues so I will release 0.4 that is basically a few important bug fixes + tokio 1.0 upgrade. Then in the following months the transport will be extracted into its own crate and redone. The goal for that rewrite is to really fix a lot of the bug/issues/usability problems with the current transport.

Okay so a little update here, most deps have been updated. I have a PR open to fix the blocking bug. I don't currently have much time to fix all the transport issues so I will release 0.4 that is basically a few important bug fixes + tokio 1.0 upgrade. Then in the following months the transport will be extracted into its own crate and redone. The goal for that rewrite is to really fix a lot of the bug/issues/usability problems with the current transport.

tonic 0.4 has been released! enjoy!

tonic 0.4 has been released! enjoy!


Annotator PR

I reset all the changes to the classifier files in https://github.com/fractal-napari-plugins-collection/napari-feature-classifier/pull/22 and created this new branch to merge in the annotator changes and do a bit of cleanup

Codecov Report

Merging #23 (d478492) into main (4d1ee28) will decrease coverage by 11.95%.
The diff coverage is 2.14%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@             Coverage Diff             @@
##             main      #23       +/-   ##
===========================================
- Coverage   47.77%   35.82%   -11.95%
===========================================
  Files           5        7        +2
  Lines         427      561      +134
===========================================
- Hits          204      201        -3
- Misses        223      360      +137

Impacted Files
Coverage Δ

...napari_feature_classifier/annotator_init_widget.py
0.00% <0.00%> (ø)

src/napari_feature_classifier/annotator_widget.py
0.00% <0.00%> (ø)

...pari_feature_classifier/_tests/test_dock_widget.py
100.00% <100.00%> (ø)

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


fix(all): correct errors preventing pypi publication

AWS CodeBuild CI Report

CodeBuild project: githubautobuild-for-cdk-v2
Commit ID: a245861c436435c893acb53cf53b0442c62f2321
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository


[IOS][French][Chrome][Firefox] I can't write letters with circumflex

IOS OS X El Capitan 10.11.6
Chrome 61.0.3163.100
Firefox 56.0
Inputmask 3.3.8
https://jsfiddle.net/y4g3sfdx/2/
I pressed keys, first [ then q, result should be â. (Key names from English keyboard)
Chrome

Firefox

I will look into it

@FireVolkhov ,
Browserstack doesn't allow me to type the accent circonflexe even in either input  ;-( .  I have a belgian keyboard so finding the character is no problem ;-)
I will try on a real mac.


Documentation missing: Bloodhound remote response format

Hi,
I'm very sure that I'm just blind, but I can't any info on the response format the remote data fetcher expects.
I have unsuccesfully tried a JSON array and a object containing a JSON array. Where can I find the documentation?

@robjbrain My JSON looks like this now, just an array of objects with "label" and "value":


Updates to Model Fields

Oh it looks like everything is an AddField for the migration. That's good. I thought certain names changed. @MattHJensen is it the case that the changes in https://github.com/open-source-economics/Tax-Calculator/pull/1109 were just additions to the current_law_policy.json? Did any field change names?

That's right, @talumbau. Here's the relevant comment: https://github.com/open-source-economics/Tax-Calculator/pull/1109#issuecomment-267736621

I'l fix that quickly.

Yes, I'm looking at it closely because there are a number of changes. It actually looks good to me, except for the STD_Dep parameter. It appears to be a multi-valued parameter in current_law_policy.json, but in this PR, it's still the single value STD_Dep. I think STD_Dep should be removed and  STD_Dep_0, STD_Dep_1, STD_Dep_2, STD_Dep_3,  should be added along with STD_Dep_cpi as a NullBooleanField like the other CPI flags. Does that sound right @MattHJensen ?

@talumbau, _STD_Dep has a single value per year (unlike _STD)
https://github.com/open-source-economics/Tax-Calculator/blob/master/taxcalc/current_law_policy.json#L429-L434

Oops, my fault. Right, so this PR is correct with STD_Dep as just a single attribute on the model.

@talumbau @MattHJensen do you think this is ready to merge?

I'll run this locally, including the migration to see how it goes.

Ran this locally. Migration looked good. Let's merge and I will push up to production tonight


Simplifies the Circle request source

No tests yet, need my morning run
/cc @jamtur01

          2 Errors

  :no_entry_sign:
  Please include a CHANGELOG entry.

You can find it at CHANGELOG.md.

:no_entry_sign:
Tests have failed, see below for more information.

          1 Warning

  :warning:
  Tests were not updated

Tests:

File
Name

circle_spec.rb
Danger::CircleCI doesnt get a PR id when it has a bad PR url

circle_spec.rb
Danger::CircleCI gets out a repo slug, pull request number and commit refs when PR url is not found

circle_spec.rb
Danger::CircleCI uses Circle CI API token if available

  Generated by :no_entry_sign: danger

          2 Errors

  :no_entry_sign:
  Please include a CHANGELOG entry.

You can find it at CHANGELOG.md.

:no_entry_sign:
Tests have failed, see below for more information.

          1 Warning

  :warning:
  Tests were not updated

Tests:

File
Name

circle_spec.rb
Danger::CircleCI doesnt get a PR id when it has a bad PR url

circle_spec.rb
Danger::CircleCI gets out a repo slug, pull request number and commit refs when PR url is not found

circle_spec.rb
Danger::CircleCI uses Circle CI API token if available

  Generated by :no_entry_sign: danger

Nice! They appeared at the exact same time, so we got double-danger'd.

Nice! Much simpler.

I've created https://github.com/orta/show_circle_env which has examples of all env vars, in all of the types of API calls

+1.


docs(operators): Fix typo in Operators guide documentation.

Description:
Fix typo.
Related issue (if exists):
None.

Thank you! :)


Bootstrapping

Need a bootstrap script that would integrate the analyser into an existing/new Cuckoo Sandbox repository clone automatically.
Here're the steps required so far:
# $ git clone https://github.com/cuckoobox/cuckoo/ ~/projects/cuckoo
$ cd ./cuckoo-osx-analyzer
$ ln -s ./analyzer/darwin/ ~/projects/cuckoo/analyzer/

This is pretty much what I do myself as well to test the Windows monitor. Alternatively you might want to use a symlink to make the "process" of bootstrapping transparantly :)

@jbremer ah, symlinking is a great idea! Actually, without it I'll have to run the script after every change to the analyser.
Thanks!

Well, I guess since there're few steps required for integrating, there's no need for a script.
P.S. I wrote a little helper for bootstrapping a guest machine instead: https://github.com/rodionovd/cuckoo-osx-analyzer/blob/master/scripts/bootstrap_guest.sh


problems with pairing

Hi and thank you for this great add-on.
First of all, I would like to highlight that the default device name is wrong, as the wording "Becker Antriebe" is not written in uppercase characters (anymore).
Maybe this is something new from HA and/or OS update?
This is how it is right now (and I have read from others that they have the same issue):
/dev/serial/by-id/usb-Becker-Antriebe_GmbH_CDC_RS232_v125_Centronic-if00
Anyway, by providing the device path at HA config I solved it myself.
Second, the pairing does not seem to work properly.
When using the becker.pair service, the cover only confirms with one "clac". This is the same for all covers I have tried.
When I try to control the cover on the paired channel from HA, nothing happens. I also enabled the debug mode and I see HA sending a command (which does nothing on the cover). I also see the received messages from my master control and added the channels to HA config. I see the cover movements now when using the master control, but still can't control any cover via HA.
Thank you very much,
Best regards.

Could you please try to run the Becker pair service twice. Let me know if this helps.

Sorry, I forgot to mention that I already tried to execute it multiple times. Only the first execute results in one "clac". Any further have no effect.
Here are the HA logs. I did put the cover in pairing mode and then executed the becker.apit three times.
2024-02-17 18:05:42.690 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 7BF49, channel: 4, command: TRAIN, argument: 0, packet: b'\x020000000002010B00000000007BF490210204008031\x03'
2024-02-17 18:05:42.691 DEBUG (Thread-5) [custom_components.becker.rf_device] Received packet for dispatcher
2024-02-17 18:05:42.692 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts received a packet from dispatcher
2024-02-17 18:05:45.576 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 7BF49, channel: 4, command: TRAIN, argument: 1, packet: b'\x020000000002010B00000000007BF490210204008130\x03'
2024-02-17 18:05:45.576 DEBUG (Thread-5) [custom_components.becker.rf_device] Received packet for dispatcher
2024-02-17 18:05:45.578 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts received a packet from dispatcher
2024-02-17 18:05:46.056 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 7BF49, channel: 4, command: RELEASE, argument: 0, packet: b'\x020000000002010B00000000007BF4902102040000B1\x03'
2024-02-17 18:05:46.056 DEBUG (Thread-5) [custom_components.becker.rf_device] Received packet for dispatcher
2024-02-17 18:05:46.058 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts received a packet from dispatcher
2024-02-17 18:05:47.589 INFO (MainThread) [homeassistant.helpers.script.websocket_api_script] websocket_api script: Running websocket_api script
2024-02-17 18:05:47.590 INFO (MainThread) [homeassistant.helpers.script.websocket_api_script] websocket_api script: Executing step call service
2024-02-17 18:05:47.605 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: TRAIN, argument: 1, packet: b'\x020000000002010B00480000001737E02101010081DB\x03'
2024-02-17 18:05:47.708 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: RELEASE, argument: 0, packet: b'\x020000000002010B00490000001737E021010100005B\x03'
2024-02-17 18:05:47.811 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: TRAIN, argument: 1, packet: b'\x020000000002010B004A0000001737E02101010081D9\x03'
2024-02-17 18:05:50.445 INFO (MainThread) [homeassistant.helpers.script.websocket_api_script] websocket_api script: Running websocket_api script
2024-02-17 18:05:50.445 INFO (MainThread) [homeassistant.helpers.script.websocket_api_script] websocket_api script: Executing step call service
2024-02-17 18:05:50.460 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: TRAIN, argument: 1, packet: b'\x020000000002010B004B0000001737E02101010081D8\x03'
2024-02-17 18:05:50.563 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: RELEASE, argument: 0, packet: b'\x020000000002010B004C0000001737E0210101000058\x03'
2024-02-17 18:05:50.666 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: TRAIN, argument: 1, packet: b'\x020000000002010B004D0000001737E02101010081D6\x03'
2024-02-17 18:05:53.090 INFO (MainThread) [homeassistant.helpers.script.websocket_api_script] websocket_api script: Running websocket_api script
2024-02-17 18:05:53.090 INFO (MainThread) [homeassistant.helpers.script.websocket_api_script] websocket_api script: Executing step call service
2024-02-17 18:05:53.098 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: TRAIN, argument: 1, packet: b'\x020000000002010B004E0000001737E02101010081D5\x03'
2024-02-17 18:05:53.201 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: RELEASE, argument: 0, packet: b'\x020000000002010B004F0000001737E0210101000055\x03'
2024-02-17 18:05:53.304 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: TRAIN, argument: 1, packet: b'\x020000000002010B00500000001737E02101010081D3\x03'

Could you send me a link to your motors manual for reference.
I have some idea. Are you familiar with (python) programming?
There would be a few things to try.

Hi Rainer,
I am not really very familiar with Python but several other coding languages... so should not be a big problem if you tell me what I need to do.
About the motors, the company which installed them did not mention the exact part number, so I will remove the metal cover to see the motor and hopefully grab the number/model.
We can continue via email if you want, probably better to share code and results?
My email is<EMAIL_ADDRESS>Best regards.

If you haven't got a manual it's fine. There's no need to open the cover.
I will send you a file to try later.

I created the develop2 branch with changed training sequence. Please switch to this branch and download the files. Then replace the files in your custom_components/becker folder with these files.
Let me know it it works and provide the HA logs.

Hi Rainer,
I downloaded "develop2", replaced all files and restarted HA.
Then I have put one cover in pairing mode and executed becker.pair three times.
The first time I did hear one "clac" like before, the other two times nothing.
Here are the logs:
2024-02-18 21:58:33.840 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 7BF49, channel: 4, command: TRAIN, argument: 0, packet: b'\x020000000002010B00000000007BF490210204008031\x03'
2024-02-18 21:58:33.840 DEBUG (Thread-5) [custom_components.becker.rf_device] Received packet for dispatcher
2024-02-18 21:58:33.843 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts received a packet from dispatcher
2024-02-18 21:58:36.832 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 7BF49, channel: 4, command: TRAIN, argument: 1, packet: b'\x020000000002010B00000000007BF490210204008130\x03'
2024-02-18 21:58:36.832 DEBUG (Thread-5) [custom_components.becker.rf_device] Received packet for dispatcher
2024-02-18 21:58:36.834 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts received a packet from dispatcher
2024-02-18 21:58:37.362 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 7BF49, channel: 4, command: RELEASE, argument: 0, packet: b'\x020000000002010B00000000007BF4902102040000B1\x03'
2024-02-18 21:58:37.363 DEBUG (Thread-5) [custom_components.becker.rf_device] Received packet for dispatcher
2024-02-18 21:58:37.365 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts received a packet from dispatcher
2024-02-18 21:58:38.853 INFO (MainThread) [homeassistant.helpers.script.websocket_api_script] websocket_api script: Running websocket_api script
2024-02-18 21:58:38.853 INFO (MainThread) [homeassistant.helpers.script.websocket_api_script] websocket_api script: Executing step call service
2024-02-18 21:58:38.862 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: TRAIN, argument: 0, packet: b'\x020000000002010B00510000001737E02101010080D3\x03'
2024-02-18 21:58:38.967 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: TRAIN, argument: 1, packet: b'\x020000000002010B00520000001737E02101010081D1\x03'
2024-02-18 21:58:39.070 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: RELEASE, argument: 0, packet: b'\x020000000002010B00530000001737E0210101000051\x03'
2024-02-18 21:58:39.173 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: TRAIN, argument: 0, packet: b'\x020000000002010B00540000001737E02101010080D0\x03'
2024-02-18 21:58:39.276 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: TRAIN, argument: 1, packet: b'\x020000000002010B00550000001737E02101010081CE\x03'
2024-02-18 21:58:42.272 INFO (MainThread) [homeassistant.helpers.script.websocket_api_script] websocket_api script: Running websocket_api script
2024-02-18 21:58:42.273 INFO (MainThread) [homeassistant.helpers.script.websocket_api_script] websocket_api script: Executing step call service
2024-02-18 21:58:42.287 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: TRAIN, argument: 0, packet: b'\x020000000002010B00560000001737E02101010080CE\x03'
2024-02-18 21:58:42.390 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: TRAIN, argument: 1, packet: b'\x020000000002010B00570000001737E02101010081CC\x03'
2024-02-18 21:58:42.493 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: RELEASE, argument: 0, packet: b'\x020000000002010B00580000001737E021010100004C\x03'
2024-02-18 21:58:42.596 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: TRAIN, argument: 0, packet: b'\x020000000002010B00590000001737E02101010080CB\x03'
2024-02-18 21:58:42.699 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: TRAIN, argument: 1, packet: b'\x020000000002010B005A0000001737E02101010081C9\x03'
2024-02-18 21:58:45.186 INFO (MainThread) [homeassistant.helpers.script.websocket_api_script] websocket_api script: Running websocket_api script
2024-02-18 21:58:45.187 INFO (MainThread) [homeassistant.helpers.script.websocket_api_script] websocket_api script: Executing step call service
2024-02-18 21:58:45.205 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: TRAIN, argument: 0, packet: b'\x020000000002010B005B0000001737E02101010080C9\x03'
2024-02-18 21:58:45.313 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: TRAIN, argument: 1, packet: b'\x020000000002010B005C0000001737E02101010081C7\x03'
2024-02-18 21:58:45.416 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: RELEASE, argument: 0, packet: b'\x020000000002010B005D0000001737E0210101000047\x03'
2024-02-18 21:58:45.519 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: TRAIN, argument: 0, packet: b'\x020000000002010B005E0000001737E02101010080C6\x03'
2024-02-18 21:58:45.624 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: TRAIN, argument: 1, packet: b'\x020000000002010B005F0000001737E02101010081C4\x03'
2024-02-18 21:58:49.306 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 7BF49, channel: 4, command: RELEASE, argument: 0, packet: b'\x020000000002010B00000000007BF4902102040000B1\x03'
2024-02-18 21:58:49.307 DEBUG (Thread-5) [custom_components.becker.rf_device] Received packet for dispatcher
2024-02-18 21:58:49.308 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts received a packet from dispatcher
2024-02-18 21:58:50.305 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 7BF49, channel: 4, command: RELEASE, argument: 0, packet: b'\x020000000002010B00000000007BF4902102040000B1\x03'
2024-02-18 21:58:50.306 DEBUG (Thread-5) [custom_components.becker.rf_device] Received packet for dispatcher
2024-02-18 21:58:50.308 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts received a packet from dispatcher
2024-02-18 21:58:50.978 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 7BF49, channel: 4, command: HALT, argument: 0, packet: b'\x020000000002010B00000000007BF4902102040010A1\x03'
2024-02-18 21:58:50.979 DEBUG (Thread-5) [custom_components.becker.rf_device] Received packet for dispatcher
2024-02-18 21:58:50.981 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts received a packet from dispatcher
2024-02-18 21:58:50.981 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts stopped at position 100
2024-02-18 21:58:50.981 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts update ha-state now
2024-02-18 21:58:51.063 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 7BF49, channel: 4, command: RELEASE, argument: 0, packet: b'\x020000000002010B00000000007BF4902102040000B1\x03'
2024-02-18 21:58:51.063 DEBUG (Thread-5) [custom_components.becker.rf_device] Received packet for dispatcher
2024-02-18 21:58:51.065 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts received a packet from dispatcher
2024-02-18 21:58:51.685 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 7BF49, channel: 4, command: UP, argument: 0, packet: b'\x020000000002010B00000000007BF490210204002091\x03'
2024-02-18 21:58:51.685 DEBUG (Thread-5) [custom_components.becker.rf_device] Received packet for dispatcher
2024-02-18 21:58:51.687 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts received a packet from dispatcher
2024-02-18 21:58:51.688 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts is travelling from position 100 to 100 in 0.0 seconds
2024-02-18 21:58:51.688 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts update ha-state now
2024-02-18 21:58:53.110 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 7BF49, channel: 4, command: HALT, argument: 0, packet: b'\x020000000002010B00000000007BF4902102040010A1\x03'
2024-02-18 21:58:53.110 DEBUG (Thread-5) [custom_components.becker.rf_device] Received packet for dispatcher
2024-02-18 21:58:53.112 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts received a packet from dispatcher
2024-02-18 21:58:53.113 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts stopped at position 100
2024-02-18 21:58:53.113 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts update ha-state now
2024-02-18 21:58:53.213 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 7BF49, channel: 4, command: RELEASE, argument: 0, packet: b'\x020000000002010B00000000007BF4902102040000B1\x03'
2024-02-18 21:58:53.214 DEBUG (Thread-5) [custom_components.becker.rf_device] Received packet for dispatcher
2024-02-18 21:58:53.216 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts received a packet from dispatcher

I still have some ideas, but they need some more time to change the code.
Maybe it would be helpful to get the motor model/number.

Hi and thank you for the support!
How to get the motor number best? I removed the cover already but only see the end of the motor and the switch to trigger pairing. I guess the number is on the part which is covered by the blind?
I searched a bit on the Becker website and Google and it seems, that I have the classical Centronic system with C01-Motors.
They work on 868,3 MHz and I am using the remote control Becker TC445-II.
If this helps, I have trained all motors also to the mediola AIO-Gateway (which I am trying to replace by HA).

If your mediola is still working, please control the motors from there and issue also a training (without putting the motor into training mode) and send me the HA Becker debug log.

Hi Rainer,
I executed the following from mediola Gateway:

TRAIN (without any motor in pairing mode) -> executed twice
one cover down
in total three covers up (it was triggered from a mediola scene I have confogured)

2024-02-25 17:18:58.343 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 3126C, channel: 2, command: TRAIN, argument: 0, packet: b'\x020000000002010B00000000003126C021000200803B\x03'
2024-02-25 17:18:58.343 DEBUG (Thread-5) [custom_components.becker.rf_device] Received packet for dispatcher
2024-02-25 17:18:58.640 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 3126C, channel: 2, command: TRAIN, argument: 1, packet: b'\x020000000002010B00000000003126C021000200813A\x03'
2024-02-25 17:18:58.640 DEBUG (Thread-5) [custom_components.becker.rf_device] Received packet for dispatcher
2024-02-25 17:18:58.936 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 3126C, channel: 2, command: RELEASE, argument: 0, packet: b'\x020000000002010B00000000003126C02100020000BB\x03'
2024-02-25 17:18:58.937 DEBUG (Thread-5) [custom_components.becker.rf_device] Received packet for dispatcher
2024-02-25 17:19:08.219 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 3126C, channel: 2, command: TRAIN, argument: 0, packet: b'\x020000000002010B00000000003126C021000200803B\x03'
2024-02-25 17:19:08.219 DEBUG (Thread-5) [custom_components.becker.rf_device] Received packet for dispatcher
2024-02-25 17:19:08.516 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 3126C, channel: 2, command: TRAIN, argument: 1, packet: b'\x020000000002010B00000000003126C021000200813A\x03'
2024-02-25 17:19:08.516 DEBUG (Thread-5) [custom_components.becker.rf_device] Received packet for dispatcher
2024-02-25 17:19:08.814 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 3126C, channel: 2, command: RELEASE, argument: 0, packet: b'\x020000000002010B00000000003126C02100020000BB\x03'
2024-02-25 17:19:08.814 DEBUG (Thread-5) [custom_components.becker.rf_device] Received packet for dispatcher
2024-02-25 17:19:44.094 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 3126C, channel: 1, command: DOWN, argument: 0, packet: b'\x020000000002010B00000000003126C021000100407C\x03'
2024-02-25 17:19:44.095 DEBUG (Thread-5) [custom_components.becker.rf_device] Received packet for dispatcher
2024-02-25 17:19:44.299 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 3126C, channel: 1, command: DOWN, argument: 1, packet: b'\x020000000002010B00000000003126C021000100417B\x03'
2024-02-25 17:19:44.300 DEBUG (Thread-5) [custom_components.becker.rf_device] Received packet for dispatcher
2024-02-25 17:19:44.494 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 3126C, channel: 1, command: RELEASE, argument: 0, packet: b'\x020000000002010B00000000003126C02100010000BC\x03'
2024-02-25 17:19:44.495 DEBUG (Thread-5) [custom_components.becker.rf_device] Received packet for dispatcher
2024-02-25 17:19:44.853 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 3126D, channel: 1, command: UP, argument: 0, packet: b'\x020000000002010B00000000003126D021000100208C\x03'
2024-02-25 17:19:44.853 DEBUG (Thread-5) [custom_components.becker.rf_device] Received packet for dispatcher
2024-02-25 17:19:45.048 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 3126D, channel: 1, command: UP, argument: 1, packet: b'\x020000000002010B00000000003126D021000100218B\x03'
2024-02-25 17:19:45.048 DEBUG (Thread-5) [custom_components.becker.rf_device] Received packet for dispatcher
2024-02-25 17:19:45.244 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 3126D, channel: 1, command: RELEASE, argument: 0, packet: b'\x020000000002010B00000000003126D02100010000AC\x03'
2024-02-25 17:19:45.244 DEBUG (Thread-5) [custom_components.becker.rf_device] Received packet for dispatcher
2024-02-25 17:19:45.612 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 3126E, channel: 1, command: UP, argument: 0, packet: b'\x020000000002010B00000000003126E021000100207C\x03'
2024-02-25 17:19:45.612 DEBUG (Thread-5) [custom_components.becker.rf_device] Received packet for dispatcher
2024-02-25 17:19:45.846 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 3126E, channel: 1, command: UP, argument: 1, packet: b'\x020000000002010B00000000003126E021000100217B\x03'
2024-02-25 17:19:45.846 DEBUG (Thread-5) [custom_components.becker.rf_device] Received packet for dispatcher
2024-02-25 17:19:46.033 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 3126E, channel: 1, command: RELEASE, argument: 0, packet: b'\x020000000002010B00000000003126E021000100009C\x03'
2024-02-25 17:19:46.034 DEBUG (Thread-5) [custom_components.becker.rf_device] Received packet for dispatcher
2024-02-25 17:19:46.407 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 3126F, channel: 1, command: UP, argument: 0, packet: b'\x020000000002010B00000000003126F021000100206C\x03'
2024-02-25 17:19:46.407 DEBUG (Thread-5) [custom_components.becker.rf_device] Received packet for dispatcher
2024-02-25 17:19:46.612 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 3126F, channel: 1, command: UP, argument: 1, packet: b'\x020000000002010B00000000003126F021000100216B\x03'
2024-02-25 17:19:46.612 DEBUG (Thread-5) [custom_components.becker.rf_device] Received packet for dispatcher
2024-02-25 17:19:46.807 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 3126F, channel: 1, command: RELEASE, argument: 0, packet: b'\x020000000002010B00000000003126F021000100008C\x03'
2024-02-25 17:19:46.808 DEBUG (Thread-5) [custom_components.becker.rf_device] Received packet for dispatcher

Thanks, the main difference between your mediola gateway and the HA implementation is the timeout between the packets. Mediola uses 0.3 seconds instead of 0.1 seconds.
To change this timeout was easy.
Again I updated the develop2 branch. Please switch to this branch and download the files. Then replace the files in your custom_components/becker folder with these files.
Let me know it it works and provide the HA logs.

Hi Rainer,
I updated the files but unfortunately I still only get one "clac".
2024-02-27 18:42:49.283 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 7BF49, channel: 4, command: TRAIN, argument: 0, packet: b'\x020000000002010B00000000007BF490210204008031\x03'
2024-02-27 18:42:49.284 DEBUG (Thread-5) [custom_components.becker.rf_device] Received packet for dispatcher
2024-02-27 18:42:49.287 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts received a packet from dispatcher
2024-02-27 18:42:52.236 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 7BF49, channel: 4, command: TRAIN, argument: 1, packet: b'\x020000000002010B00000000007BF490210204008130\x03'
2024-02-27 18:42:52.236 DEBUG (Thread-5) [custom_components.becker.rf_device] Received packet for dispatcher
2024-02-27 18:42:52.238 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts received a packet from dispatcher
2024-02-27 18:42:52.980 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 7BF49, channel: 4, command: RELEASE, argument: 0, packet: b'\x020000000002010B00000000007BF4902102040000B1\x03'
2024-02-27 18:42:52.980 DEBUG (Thread-5) [custom_components.becker.rf_device] Received packet for dispatcher
2024-02-27 18:42:52.982 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts received a packet from dispatcher
2024-02-27 18:42:54.891 INFO (MainThread) [homeassistant.helpers.script.websocket_api_script] websocket_api script: Running websocket_api script
2024-02-27 18:42:54.891 INFO (MainThread) [homeassistant.helpers.script.websocket_api_script] websocket_api script: Executing step call service
2024-02-27 18:42:54.907 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: TRAIN, argument: 0, packet: b'\x020000000002010B00600000001737E02101010080C4\x03'
2024-02-27 18:42:55.213 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: TRAIN, argument: 1, packet: b'\x020000000002010B00610000001737E02101010081C2\x03'
2024-02-27 18:42:55.517 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: RELEASE, argument: 0, packet: b'\x020000000002010B00620000001737E0210101000042\x03'
2024-02-27 18:42:55.826 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: TRAIN, argument: 0, packet: b'\x020000000002010B00630000001737E02101010080C1\x03'
2024-02-27 18:42:56.132 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: TRAIN, argument: 1, packet: b'\x020000000002010B00640000001737E02101010081BF\x03'
2024-02-27 18:42:59.481 INFO (MainThread) [homeassistant.helpers.script.websocket_api_script] websocket_api script: Running websocket_api script
2024-02-27 18:42:59.481 INFO (MainThread) [homeassistant.helpers.script.websocket_api_script] websocket_api script: Executing step call service
2024-02-27 18:42:59.496 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: TRAIN, argument: 0, packet: b'\x020000000002010B00650000001737E02101010080BF\x03'
2024-02-27 18:42:59.802 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: TRAIN, argument: 1, packet: b'\x020000000002010B00660000001737E02101010081BD\x03'
2024-02-27 18:43:00.106 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: RELEASE, argument: 0, packet: b'\x020000000002010B00670000001737E021010100003D\x03'
2024-02-27 18:43:00.412 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: TRAIN, argument: 0, packet: b'\x020000000002010B00680000001737E02101010080BC\x03'
2024-02-27 18:43:00.719 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: TRAIN, argument: 1, packet: b'\x020000000002010B00690000001737E02101010081BA\x03'
2024-02-27 18:43:06.062 INFO (MainThread) [homeassistant.helpers.script.websocket_api_script] websocket_api script: Running websocket_api script
2024-02-27 18:43:06.062 INFO (MainThread) [homeassistant.helpers.script.websocket_api_script] websocket_api script: Executing step call service
2024-02-27 18:43:06.070 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: TRAIN, argument: 0, packet: b'\x020000000002010B006A0000001737E02101010080BA\x03'
2024-02-27 18:43:06.376 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: TRAIN, argument: 1, packet: b'\x020000000002010B006B0000001737E02101010081B8\x03'
2024-02-27 18:43:06.682 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: RELEASE, argument: 0, packet: b'\x020000000002010B006C0000001737E0210101000038\x03'
2024-02-27 18:43:06.989 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: TRAIN, argument: 0, packet: b'\x020000000002010B006D0000001737E02101010080B7\x03'
2024-02-27 18:43:07.295 DEBUG (Thread-5) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737E, channel: 1, command: TRAIN, argument: 1, packet: b'\x020000000002010B006E0000001737E02101010081B5\x03'

Seems to be quite complicated. Sorry for that.
Just to ensure:

there is the 1st clack when you enter training mode by your master remote
there is the 2nd clack when you run becker pair from HA
but the clack clack is missing.
Is this correct?

There's one more thing. I found that the RELEASE command was missing after 2nd training sequence. Maybe this helps. Please give the latest version in develop2 branch a try.
One more thing, if the above code is not working:

remove all remotes except master using your master remote
enter training mode using master remote
try to issue becker pair from HA

Downside: your mediola remote will be removed as well for this motor.
One more options to try if you have a Linux system:
Try centroniy-py from ole:
One more option if you have a Windows system with python installed:
Try pybecker:

Hi Rainer,
I feel a bit stupid now, but I managed to pair the covers now.
I formerly thought the HA configured channel is related to the USB stick, so I used channel 1... but seems this is the channel at the cover?
As it was not working, I tried channel 2 with units 1, 2... and all paired successfully now. At least I have heard three clacks now.
However, I still can't control the covers from HA (I moved back to github "main" branch).
What also seems strange is that when using the master control, while it was moving up, HA did not update the final position even if a RELEASE was received from the motor (you see it at the logs at the end).
2024-03-01 18:36:10.082 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen Mitte Test is travelling from position 0 to 100 in 0.0 seconds
2024-03-01 18:36:10.082 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen Mitte Test update ha-state now
2024-03-01 18:36:10.093 DEBUG (Thread-6) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737D, channel: 4, command: UP, argument: 0, packet: b'\x020000000002010B00090000001737D0210104002088\x03'
2024-03-01 18:36:14.842 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen Mitte Test stopped at position 50
2024-03-01 18:36:14.842 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen Mitte Test update ha-state now
2024-03-01 18:36:14.857 DEBUG (Thread-6) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737D, channel: 4, command: HALT, argument: 0, packet: b'\x020000000002010B000A0000001737D0210104001097\x03'
2024-03-01 18:36:15.752 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen Mitte Test is travelling from position 50 to 0 in 0.0 seconds
2024-03-01 18:36:15.752 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen Mitte Test update ha-state now
2024-03-01 18:36:15.759 DEBUG (Thread-6) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737D, channel: 4, command: DOWN, argument: 0, packet: b'\x020000000002010B000B0000001737D0210104004066\x03'
2024-03-01 18:36:23.560 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen Mitte Test stopped at position 50
2024-03-01 18:36:23.561 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen Mitte Test update ha-state now
2024-03-01 18:36:23.576 DEBUG (Thread-6) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737D, channel: 4, command: HALT, argument: 0, packet: b'\x020000000002010B000C0000001737D0210104001095\x03'
2024-03-01 18:37:38.610 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts is travelling from position 0 to 100 in 23.0 seconds
2024-03-01 18:37:38.610 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts update ha-state now
2024-03-01 18:37:38.611 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts setup update ha-state callback in 23.0 seconds
2024-03-01 18:37:38.629 DEBUG (Thread-6) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737C, channel: 4, command: UP, argument: 0, packet: b'\x020000000002010B00480000001737C0210104002059\x03'
2024-03-01 18:37:42.997 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts stopped at position 20
2024-03-01 18:37:42.998 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts update ha-state now
2024-03-01 18:37:43.013 DEBUG (Thread-6) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737C, channel: 4, command: HALT, argument: 0, packet: b'\x020000000002010B00490000001737C0210104001068\x03'
2024-03-01 18:37:43.886 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts is travelling from position 20 to 0 in 4.52 seconds
2024-03-01 18:37:43.886 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts update ha-state now
2024-03-01 18:37:43.887 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts setup update ha-state callback in 4.52 seconds
2024-03-01 18:37:43.907 DEBUG (Thread-6) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737C, channel: 4, command: DOWN, argument: 0, packet: b'\x020000000002010B004A0000001737C0210104004037\x03'
2024-03-01 18:37:47.711 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts stopped at position 4
2024-03-01 18:37:47.711 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts update ha-state now
2024-03-01 18:37:47.720 DEBUG (Thread-6) [custom_components.becker.pybecker.becker_helper] Sent packet: unit_id: 1737C, channel: 4, command: HALT, argument: 0, packet: b'\x020000000002010B004B0000001737C0210104001066\x03'
2024-03-01 18:37:48.930 DEBUG (Thread-6) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 7BF49, channel: 4, command: DOWN, argument: 0, packet: b'\x020000000002010B00000000007BF490210204004071\x03'
2024-03-01 18:37:48.931 DEBUG (Thread-6) [custom_components.becker.rf_device] Received packet for dispatcher
2024-03-01 18:37:48.934 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts received a packet from dispatcher
2024-03-01 18:37:48.934 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts is travelling from position 4 to 0 in 0.904 seconds
2024-03-01 18:37:48.934 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts update ha-state now
2024-03-01 18:37:48.935 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts setup update ha-state callback in 0.904 seconds
2024-03-01 18:37:49.035 DEBUG (Thread-6) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 7BF49, channel: 4, command: RELEASE, argument: 0, packet: b'\x020000000002010B00000000007BF4902102040000B1\x03'
2024-03-01 18:37:49.035 DEBUG (Thread-6) [custom_components.becker.rf_device] Received packet for dispatcher
2024-03-01 18:37:49.037 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts received a packet from dispatcher
2024-03-01 18:37:49.840 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts update ha-state now
2024-03-01 18:37:52.712 DEBUG (Thread-6) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 7BF49, channel: 4, command: HALT, argument: 0, packet: b'\x020000000002010B00000000007BF4902102040010A1\x03'
2024-03-01 18:37:52.713 DEBUG (Thread-6) [custom_components.becker.rf_device] Received packet for dispatcher
2024-03-01 18:37:52.715 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts received a packet from dispatcher
2024-03-01 18:37:52.715 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts stopped at position 0
2024-03-01 18:37:52.715 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts update ha-state now
2024-03-01 18:37:52.795 DEBUG (Thread-6) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 7BF49, channel: 4, command: RELEASE, argument: 0, packet: b'\x020000000002010B00000000007BF4902102040000B1\x03'
2024-03-01 18:37:52.795 DEBUG (Thread-6) [custom_components.becker.rf_device] Received packet for dispatcher
2024-03-01 18:37:52.797 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts received a packet from dispatcher
2024-03-01 18:37:53.521 DEBUG (Thread-6) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 7BF49, channel: 4, command: UP, argument: 0, packet: b'\x020000000002010B00000000007BF490210204002091\x03'
2024-03-01 18:37:53.522 DEBUG (Thread-6) [custom_components.becker.rf_device] Received packet for dispatcher
2024-03-01 18:37:53.524 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts received a packet from dispatcher
2024-03-01 18:37:53.524 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts is travelling from position 0 to 100 in 23.0 seconds
2024-03-01 18:37:53.524 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts update ha-state now
2024-03-01 18:37:53.525 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts setup update ha-state callback in 23.0 seconds
2024-03-01 18:37:53.696 DEBUG (Thread-6) [custom_components.becker.pybecker.becker_helper] Received packet: unit_id: 7BF49, channel: 4, command: RELEASE, argument: 0, packet: b'\x020000000002010B00000000007BF4902102040000B1\x03'
2024-03-01 18:37:53.696 DEBUG (Thread-6) [custom_components.becker.rf_device] Received packet for dispatcher
2024-03-01 18:37:53.698 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts received a packet from dispatcher
2024-03-01 18:38:16.527 DEBUG (MainThread) [custom_components.becker.cover] Wohnzimmer Rolladen rechts update ha-state now

Could you please send me the configuration

cover:

platform: becker
device: "/dev/serial/by-id/usb-Becker-Antriebe_GmbH_CDC_RS232_v125_Centronic-if00"
covers:
Use unique names for each cover like kitchen, bedroom or living_room
bedroom:
friendly_name: "Schlafzimmer Rolladen"
# Becker Centronic USB stick provides up to five units (1-5) with up to seven (1-7) channels
channel: "2:1"
remote_id: "7BF49:1"
livingroom1:
friendly_name: "Wohnzimmer Rolladen links"
channel: "2:2"
remote_id: "7BF49:2"
livingroom2:
friendly_name: "Wohnzimmer Rolladen mitte"
channel: "2:3"
remote_id: "7BF49:3"
livingroom3:
friendly_name: "Wohnzimmer Rolladen rechts"
channel: "2:4"
remote_id: "7BF49:4"
travelling_time_down: 22.6
travelling_time_up: 23
tilt_intermediate: off

Good to hear that it is working now. If you don't receive the commands from the remotes, then there is maybe a range issue.
Have you placed the HA Becker USB Stick at the same place of the mediola box?
Maybe placing the Becker USB Stick with an extension cable at a better position might help.


When dragging multiple cards in outline mode, the outline does not look consistent

This is how it should look.


Purpose of the scale parameter

Currently presence of scale property in configuration - does almost nothing,
The only way how it's using in the code at the moment - it's passing it into exporter template.
In my opinion - it should affect textures scale (resize them) and their positions in the atlas (as it described in readme).
May be I've missed something or it is intended to be so?

Yes ... This property has been added for the internal rendering framework of the PlayToMax company. It really was needed just as a constant to indicate the scale of the graphics package.
It does not make sense now.
I see 2 options:
1 - delete as deprecated
2 - scale texture and properties (size, position etc) by scale value
I’m not sure what will be better :)

From my point of view - it would be better to implement scale (it's very useful for creating atlases for different resolutions), but we need to introduce another parameter for such capability and deprecate scale.
Also along with the introduction of a new parameter it's would be perfect to add resize method parameter: bilinear, trilinear, nearest, in another words - whole spectre provided by jimp.

I agree. Will be implemented.

Done :)

Wow, thank you! That's great!


GUI overlapping

When used with Curios API (Forge), and when its GUI is opened the recipe book is shown where the Curio GUI button should be.
This doesn't crash the game or cause any harm (you can still get out of Curio GUI), but should still be fixed as it doesn't look very pretty and is most probably not the intended behaviour.
Pretty simple issue. If you need pictures of the issue in game, I could send some here.

Can you post an image please?

Here they are! Sry it took me so long...

Same happens w only the Curios API and this mod. Also, the same happens in survival.

Fixed in v.1.3.2.


Lightbulb sends empty lsp.Diagnostic in code action requests

Describe the bug
Following the fix to https://github.com/nvimdev/lspsaga.nvim/issues/1478, Lightbulb now sends an empty diagnostic as an array to the language server, which is also bug:
LSP[hls] Error condition, please check your setup and/or the [issue tracker](https://github.com/haskell/haskell-language-server/issues):
LSP: incoming message parse error:
Error in $.params.context.diagnostics[0]: parsing Diagnostic failed, expected Object, but encountered Array
when processing
{
  "id": 76,
  "params": {
    "context": {
      "diagnostics": [
        []
      ]
    },
    "textDocument": {
      "uri": "file:///Users/grzesiek/Code/findata/transcoder/test/Test/Transcoder/CharlesSchwab.hs"
    },
    "range": {
      "end": {
        "character": 0,
        "line": 22
      },
      "start": {
        "character": 0,
        "line": 22
      }
    }
  },
  "jsonrpc": "2.0",
  "method": "textDocument/codeAction"
}

The problem stems vim.diagnostic.get returning an empty lsp field:
{ {
    bufnr = 1,
    col = 37,
    end_col = 29,
    end_lnum = 34,
    lnum = 19,
    message = "• \"Could not parse : REDACTED",
    namespace = 36,
    severity = 1,
    source = "typecheck",
    user_data = {
      lsp = {}
    }
  } }

Steps to reproduce
I believe the description describes the cause and how to fix it well.
Expected behavior
I believe the description describes the cause and how to fix it well.
Neovim version (nvim -v)
0.10.0
lspsaga commit
42eb7b26eebf5221a4ae9e4e7a49a95b50202daa
Terminal name/version
kitty

how about now ?

Looks good. I don’t get any errors from HLS and lightbulb seems to work fine.


Implement exercise: diamond

I finally got around to trying this exercise out. Didn't solve it by myself, but your example is neat! That's good enough for me to include it.
I would like to ask before, whether nrows really has to be copied into the function as rows. How do you feel about omitting that copy?

Oh cool - thanks.
Yes you're right. Looking at it now I don't know why I included that rows argument in the function since it is redundant. It should be removed.

Thanks @katrinleinweber!


cmd/compile: SSA sometimes generates far more write barriers

I did a comparison of the write barriers produced when compiling cmd/compile with and without SSA. Sometimes it generates dramatically more write barriers than the old backend. Here are the top movers:
+235 cmd/internal/obj/ppc64.buildop(SB)
+72 cmd/internal/obj/mips.buildop(SB)
+55 cmd/internal/obj/arm.buildop(SB)
+14 cmd/compile/internal/amd64.ssaGenBlock(SB)
+10 cmd/compile/internal/ssa.rewriteValuegeneric_OpStructSelect(SB)
+9 cmd/compile/internal/ssa.decomposeBuiltIn(SB)
+8 cmd/compile/internal/ssa.nilcheckelim(SB)
+6 runtime.getitab(SB)
+5 runtime.(*TypeAssertionError).Error(SB)
+4 runtime.assertI2T(SB)
+4 reflect.Value.MapKeys(SB)
+4 fmt.(*pp).printReflectValue(SB)
+4 cmd/compile/internal/ssa.(*Value).LongString(SB)
+4 cmd/compile/internal/ssa.(*edgeState).setup(SB)
+3 runtime.assertE2T(SB)
+3 reflect.(*structType).FieldByNameFunc(SB)
+3 cmd/internal/obj.Linknew(SB)
+3 cmd/compile/internal/gc.typecheck1(SB)
+3 cmd/compile/internal/gc.Main(SB)
I looked into a few of these and it looks like the old backend is generating one call to typedmemmove in cases where SSA is generating a huge number of calls to writebarrierptr. In the smaller movers like runtime.getitab this may actually be the right thing; if there are just a few pointers, writebarrierptr is better. But 235 more write barriers is probably not the right thing.
This was generated with the following script:
#!/bin/bash

awk '
function dump() {
  if (fn != "")
    counts[fn][file] = n
}
/^TEXT/ { dump(); fn=$2; n=0 }
/CALL runtime.writebarrierptr/ { n++ }
END {
  dump();
  for (fn in counts) {
    printf("%+d %s\n", counts[fn]["b"] - counts[fn]["a"], fn)
  }
}
' file=a <(go tool objdump "$1") file=b <(go tool objdump "$2") | sort -gr

/cc @khr @dr2chase

For cmd/internal/obj/ppc64.buildop at least, we're using writebarrierptr instead of typedmemmove for a slice assignment.
With ssa, that function uses 237 writebarrierptrs and 0 typedmemmove.
Without ssa, the same function uses 2 writebarrierptrs and 235 typedmemmoves.
There is no bug in this function, at least.  Did you see many writebarrierptrs substituted for a single typedmemmove anywhere else?  I believe the worst the SSA code does currently is 4 for 1.

You're right. Second column is diff in typedmemmove calls:
+235 -235 cmd/internal/obj/ppc64.buildop(SB)
+72 -72 cmd/internal/obj/mips.buildop(SB)
+55 -55 cmd/internal/obj/arm.buildop(SB)
+14 -7 cmd/compile/internal/amd64.ssaGenBlock(SB)
+10 -10 cmd/compile/internal/ssa.rewriteValuegeneric_OpStructSelect(SB)
+9 +0 cmd/compile/internal/ssa.decomposeBuiltIn(SB)
+8 -4 cmd/compile/internal/ssa.nilcheckelim(SB)
+6 -6 runtime.getitab(SB)
+5 -5 runtime.(*TypeAssertionError).Error(SB)
+4 -4 runtime.assertI2T(SB)
+4 -4 cmd/compile/internal/ssa.(*Value).LongString(SB)

Looks like SSA is doing much better than the old backend in general. The only weird one is decomposeBuiltIn, where SSA generating two writebarrierptrs for each mapaccess/append/mapassign line instead of one.

Looks like decomposeBuiltIn is generating a write barrier for a write to the stack.  I'll see if I can repro in an independent test case.

I'm going to close this issue, follow along with the remaining write barrier optimizations at #14969 (no pointer writeback for non-growing appends) and #15023 (extra write barrier for map access+append).


mesheryctl: mesheryctl version not aligned

adding additional tab to aligned the mesheryctl
version command.
Signed-off-by: subhamkrai<EMAIL_ADDRESS>Description
This PR fixes #
Notes for Reviewers
Signed commits

[x] Yes, I signed my commits.

for now, used tweak needs discussion on this.

@anirudhjain75  any suggestions?

Yea I did share formatting tools / tips for you to have a look on. What's your progess with that ?

Yea I did share formatting tools / tips for you to have a look on. What's your progess with that ?

yes, I saw that but I'm not sure that how that will resolve in this case as for both client and server version we have same logging method but we are getting different formats in  GITSHA.

@subhamkrai one item that needs to be addressed is the missing "v" in the release tag in the Client Version line. Will you have this "v" added back?

@subhamkrai one item that needs to be addressed is the missing "v" in the release tag in the Client Version line. Will you have this "v" added back?

@anirudhjain75 will you create a new issue to track this request?

Yea I did share formatting tools / tips for you to have a look on. What's your progess with that ?

yes, I saw that but I'm not sure that how that will resolve in this case as for both client and server version we have same logging method but we are getting different formats in  GITSHA.

You'll have make it in such a way to print both server version and client version at once using formatting method

@subhamkrai one item that needs to be addressed is the missing "v" in the release tag in the Client Version line. Will you have this "v" added back?

I don't understand what you mean by it

@anirudhjain75 no sweat. If you will run mesheryctl version, you’ll see.

@anirudhjain75 here you go:
➜  meshery git:(myMeshMap) mesheryctl version
Client Version: 0.4.3 	  GitSHA: 51fa5e6626f024aa3bd914efd0d0c34fa136021a
Server Version: v0.4.3 	  GitSHA: 51fa5e6

See the missing "v" in the Client Version line?

Okay Yea... This can be added after the formatter task is done

@subhamkrai let me know if you're still on this :)

@anirudhjain75 will you breakout the addition of "v" in the Client Version into a separate issue/PR, so that it can be uncoupled and move forward?

Yea it would make a beginner issue.

Marking issue as stale, assuming @subhamkrai won't be able to finish off this PR.

Stale bot removed the label. @subhamkrai quick question - do you foresee finishing this off or is it best to close this PR and unassign the issue for the time being?

Stale bot removed the label. @subhamkrai quick question - do you foresee finishing this off or is it best to close this PR and unassign the issue for the time being?

okay, lets close this PR or if @anirudhjain75  wants to takeover fell free to do.

I have some other work to be done. Hopefully someone else comes up and picks this... I dont see an open issue for this 🤔. I'm reopening this for other contributors to pick up from here.

@vijcheru this PR is inactive. You might want to have a look around this issue to see if a fix is possible.


Mistake

Hello,
I've been trying to use react-carousel in my project, while it works in development, it doesn't when I try to build.
Error log below:
 ERROR #95312

"window" is not available during server side rendering.

See our docs page for more info on this error: https://gatsby.dev/debug-html

> 1 | !function(e,t){"object"==typeof exports&&"object"==typeof module?module.exports=t(require("react")):"function"==typeof define&&define.amd?define("react-carousel",["react"],t):"object"==typeof exports?exports["react-carousel"]=t(require("react")):e["react-carousel"]=t(e.React)}(window,(function(e){return r={},t.m=n=[function(t,n){t.exports=e},function(e,t,n){var r;
    |                                                                                ^
  2 | /*!
  3 |   Copyright (c) 2017 Jed Watson.
  4 |   Licensed under the MIT License (MIT), see

  WebpackError: ReferenceError: window is not defined

  - react-carousel.js:1<EMAIL_ADDRESS>    node_modules/@brainhubeu/react-carousel/lib/react-carousel.js:1:278

@starvasos
could you use Next.js as described in https://github.com/brainhubeu/react-carousel#ssr ?

I will take a look, thanks.

Now it doesn't work in development, nor the build.

@piotr-s-brainhub It worked in both dev and build with:
const ReactCarousel = dynamic({
	loader: async () => {
		const { default: Carousel } = await import("@brainhubeu/react-carousel");
		return props => <Carousel {...props} />;
	},
	ssr: process.env.NODE_ENV === "production",
});


[question] runtime-hooks: disable standalone mode when use proxy mode

What happened:
https://github.com/koordinator-sh/koordinator/blob/main/docs/design-archive/koordlet-runtime-hooks.md#working-mode
When runtime-proxy is installed and the proxy mode is used, it seems that the standalone mode will still run and do repeated work. Is there any way to turn off standalone mode when using proxy mode？
What you expected to happen:
There is a flag of koordlet to turn off the standalone mode.
Environment:

Koordinator version: - v1.1.1
Kubernetes version (use kubectl version): v1.24.2
docker/containerd version: containerd 1.6.18
OS (e.g: cat /etc/os-release): Ubuntu 20.04.4 LTS
Kernel (e.g. uname -a): Linux 5.10.112-11.al8.x86_64 #1 SMP Tue May 24 16:05:50 CST 2022 x86_64 x86_64 x86_64 GNU/Linux

Anything else we need to know:

Standalone mode is still necessary since the cgroup files in kubepods/ dir still needs to be reconciled, which also for the final  consistency.
Is there any problems to both run the reconciler and the proxy mode?

emm... I ignored kubeqos level by mistake. It made me think that proxy mode and standalone mode are exactly the same in function. Thanks @zwzhang0107 for the clarification.


Process to roll out functionality changes

I'll use this issue to iterate on the below process (updating this first post) . Please discuss.
Stage: WIP, Draft, Proposed
Process to roll out functionality changes
In scope
Any changes that would affect existing Allstar users, such as:

New settings default to on
Deprecating policies or settings
Changing how existing logic works

Out of scope
Any change that does not affect existing Allstar users, such as:

Entirely new policies
New settings default to off

Process

If adding a new setting, or changing how a setting works:

Introduce the new (or separate, if changing) setting, default to off, prefix with "testing"

Add description of feature / change to the whats-new.md under the upcoming release seciton.
Monthly, an email will be sent to the allstar-announce list, all changes from whats-new.md will be included in the email. This will notify all users of the upcoming change.
After one month (next month's email), the changes can be made: ("testing" removed, default on, etc.). They will be communicated again in that email.

The release cadence will be synchronized with these monthly changes/emails. We can use GitHub milestones to keep track of what needs to be moved (from testing, default on, etc.) when.

Updated, moved to draft stage.


Finals Week

Runtime Links:
Frontend
Backend API
Technical Achievements/Accomplishments (Frontend):

At the top of the page, the entries already present in the API and shown to the user with the read function
Next, the user has the option to enter a city and the city and the nearest airport to it to the database to be stored
The JavaScript code I created converts the city inputted by the user with the use of 2 APIs from RapidAPI

The first API takes in the city as an input and finds the city's latitude and longitude coordinates
The second API uses the latitude and longitude coordinates of the city to find the nearest airport to the city

Also, if the user inputs a city that doesn't exist or isn't present in the RapidAPI API that stores all the cities, a message will be displayed to the user telling them that the city could not be found

Technical Achievements/Accomplishments (Backend):

Using the create and read functions from CRUD, I was able to display the entries stored in the API to the user (read) and add new entries to the API (create)
For my API in our group's flask repo, I also made a model for it containing the CRUD operations and setter and getter methods
I also was able to use Postman to test my API and make sure I was able to post new data into the API and get existing data from the API

Challenges I Faced:
At first I wasn't sure how I would be able to find the nearest airport with the name of a city. I later figured out that I might be able to use RapidAPI to complete this task. After searching and looking through many different RapidAPI APIs, I wasn't able to find a single API that could perform the task I wanted. I was, however, able to find 2 APIs that could be used in tandem to reach my goal of finding the nearest airport with an input of a city. Another challenge I faces was that I wasn't sure how to make an API in flask and I didn't really understand how to use Postman. With some help of a few other people, I was able to make my API that was based on a model. I also learned how to use Postman to test my API. I also figured out how to use CSS to make my page look better. After all these challenged that I faced, made my page into something that I am proud of.
Guides for Review Blog
Github Analytics:
Github Analytics (Frontend)
Github Analytics (Backend)

Runtime Links
Frontend
Backend


Fix crash on ws close

Fixes: #39
Note this is currently not clang-formatted since I don't think thats been done yet, so the clang-format check will fail

Okay so mingw + tls fails at this with boost 1.74.0 due to "file too big". I'm not sure what tripped it, I assume it must be the callback to async_close + the ssl_stream stuff. I'm really not sure what to do about this, since main.cpp is going to have to include the definitions no matter. I could try switching to std::function rather than template callback but that has the type-erasure overhead.
I'm a bit busy today so I may not get back to this for a few hours but any thoughts @Tectu?

I'm a bit busy today so I may not get back to this for a few hours but any thoughts @Tectu?

I don't know... I really really don't know. I do understand that this library is pushing file sizes - especially with underlying boost.beast. I mean the boost.beast examples themselves already don't compile without the corresponding big-obj option(s) so adding stuff on top like malloy does is certainly not improving the situation - but it's necessary 🙈.
As you mentioned main.cpp is going to have to include all the necessary definitions no matter how much we shuffle things around.

From the string that apparently caused the overflow I would guess this is mostly a beast issue. Looks like the typename of the asio executor for the ssl websocket stream is simply too much. Just a guess though. I wonder, does it work with -Os?

I consider this a bug in mingw tbh. MSVC can compile it fine, and so can gcc (but that's a different format)

Yeah... I've been (forcefully) working for the better part of a decade with MinGW on Windows. It's just a big pain.
The projects that consume malloy could be changed to a clang based toolchain. However, clang 12.0 doesn't seem to provide enough C++20-ness to compile malloy (I didn't investigate properly, just switched to clang and got a bunch of lambda errors etc.

Yeah looks like clang 12 doesn't properly support some part of concepts: godbolt. trunk can manage though, so I guess the CI could build from source if we did that, although I'm guessing thats not really an acceptable requirement to put on users :p.

I wanted to pull your branch to build this locally.
This needs some updating/merging tho. Should I handle that or are you by any chance highly motivated to handle this? :p

I just did a quick merge in githubs web editor. Feel free to force push it if you've done it locally though, I don't mind :p

Force pushing is not something I like to do if avoidable in pretty much any situation as a human being :p
+1 lazy points for using the web editor tho :p

Well thats what you get for being lazy I guess, missed the fact that underlying_conn_ had been renamed. now it should work :p

Not my fault that you don't adhere to the coding style guidelines 7098f8eb0563d279bf29be0407e2269cb25b50c4 😝😜


Fix minor typos

CC: @petele

Whoops!
There were 2 warnings that will prevent this PR from being merged. Please take a look, and either fix, or provide a justification for why they can't be fixed.
WARNINGS
src/content/en/updates/2018/05/nic67.md#L8 - Common typo found: 'chrome' Should it be 'Chrome'?
src/content/en/updates/2018/05/nic67.md#L42 - Line must be at most 100 characters

Pro tip: Making a plural or possessive out of a code term is ugly because it requires mixing type faces. I try to avoid constructions that require that. So your sentence would be like:
And a BigInt makes dealing with big integers way easier. I won't hold up this PR for that. Just an FYI.


README: Migrate Travis badge to travis-ci.com.

This looks like it comes from this discussion. LGTM, merging. Thanks!


Integration tests

These tests ensure that FormatterKit can be added to iOS and OSX projects using CocoaPods or Carthage. They also ensure that FormatterKit properly references localization strings.
To run all integration tests locally: rake integration_tests.

Coverage remained the same at 38.013% when pulling f800976b15a86d0ae2261ad2f75f51392622df06 on integration-tests into 71732fc38ccaa7a6e505fa22f59e443e2da63f48 on master.

Coverage remained the same at 38.013% when pulling 68675db10b6c1a031e79e5dad1c8f339f9fd5e7c on integration-tests into 71732fc38ccaa7a6e505fa22f59e443e2da63f48 on master.

Coverage remained the same at 38.013% when pulling 68675db10b6c1a031e79e5dad1c8f339f9fd5e7c on integration-tests into 71732fc38ccaa7a6e505fa22f59e443e2da63f48 on master.