[Proposal] clang format for initializer list

preivious initialization list was hard to read when it gets too long.
eg) layers initialization list
before:
  Layer()
    : last_layer(false), init_zero(false), type(LAYER_UNKNOWN),
      activation(NULL), activation_prime(NULL), activation_type(ACT_UNKNOWN),
      bn_follow(false), weight_decay(), weight_ini_type(WEIGHT_UNKNOWN) {}

after:
  Layer()
    : last_layer(false),
      init_zero(false),
      type(LAYER_UNKNOWN),
      activation(NULL),
      activation_prime(NULL),
      activation_type(ACT_UNKNOWN),
      bn_follow(false),
      weight_decay(),
      weight_ini_type(WEIGHT_UNKNOWN) {}

Self evaluation:

Build test: [ ]Passed [ ]Failed [x]Skipped
Run test: [ ]Passed [ ]Failed [x]Skipped

Signed-off-by: Jihoon Lee<EMAIL_ADDRESS>

:memo: TAOS-CI Version: 1.4.20191203. Thank you for submitting PR #203. Please a submit 1commit/1PR (one commit per one PR) policy to get comments quickly from reviewers. Your PR must pass all verificiation processes of cibot before starting a review process from reviewers. If you are new member to join this project, please read manuals in documentation folder and wiki page. In order to monitor a progress status of your PR in more detail, visit http://nnsuite.mooo.com/.


Support deploying nexodus

Deploy a nexodus service running on KIND and local nexd pods in the Submariner clusters, when creating clusters with using=nexodus.

Closing this, we can implement Nexodus support properly, this was just a quick POC


tutorial

we'll have to figure out what to do in this situation:

either way need to hide the ` character or we need to turn it into <code>. i prefer the first option, <code> will be a CSS nightmare

we'll have to figure out what to do in this situation:

either way need to hide the ` character or we need to turn it into <code>. i prefer the first option, <code> will be a CSS nightmare

I just removed the backticks, they aren't necessary and not styled either in the title

I'd really like if the menu showed all the pages. E.g. it just says "Errors And Redirects", but there are many different pages within that section

@benmccann I'm not sure what this means? This is what I see

Menu looks fine to me now. The sections weren't appearing expandable to me for some reason before if I recall

had you searched? it filters by search term

don't think so, but it was last week. in any case, it looks good to me now, so I wouldn't worry about it

I see you renamed "rendering options" to "page options" - which reminds me that I wanted to advocate for changing the section to be named "rendering options" in the kit docs, too. "page options" to me sounds like it's tied to a page, but you can also set those on layouts. Moreover, they all relate to rendering, so I think that "rendering options" is the more fitting term.

Do we want to remove "WARNING: this content is a work in progress and may be out of date" at the beginning?
I figured out the issue I was having with the menu last week as I just hit it again. I expected to be able to click the > button and thought the menu was broken or didn't expand when it didn't do anything. If you hadn't told me earlier that the menu expanded, I'm not sure I would have figured it out this time around
Also, the menu isn't expanded to show the current page. E.g. I'm currently on "Part 1 / Bindings / Group inputs" and the section that's expanded is the one above it: "Events"
The "new file" vs "new folder" icons are nearly indistinguishable to me. I had to move way closer to the monitor to see them. Maybe we could make them slightly bigger?

Do we want to remove "WARNING: this content is a work in progress and may be out of date" at the beginning?

Done, though we will need to do a proper run-through to make sure that everything is up to date 😆

I figured out the issue I was having with the menu last week as I just hit it again. I expected to be able to click the > button and thought the menu was broken or didn't expand when it didn't do anything

Not sure I follow?

Also, the menu isn't expanded to show the current page. E.g. I'm currently on "Part 1 / Bindings / Group inputs" and the section that's expanded is the one above it: "Events"

Ah yeah, the state persists — whatever you had open before remains open. We should reset it whenever you open the menu

The "new file" vs "new folder" icons are nearly indistinguishable to me. I had to move way closer to the monitor to see them. Maybe we could make them slightly bigger?

Can probably make them a smidge bigger but I wonder if we need to tweak the icons themselves. These are the VSCode icons...

...and these are ours:

I think if the folder icon was slightly shorter, and the page icon didn't have a fold (or at least had a smaller fold) then the icons would be a more recognisably different shape

I figured out the issue I was having with the menu last week as I just hit it again. I expected to be able to click the > button and thought the menu was broken or didn't expand when it didn't do anything
Not sure I follow?

These things don't do anything when you click them. I expected them to expand the corresponding menu item and when it didn't I assumed the menu was broken

i've been running thru today (better late than never!) and found that theres a small bug: when you toggle between "solve" and "reset" on some pages, the "reset" button sometimes fails to go back to "solve" https://www.loom.com/share/d5d18025f9fb4ddb98b4eec65b832db7

another bug - this src/error.html customization doesnt work as advertised: https://learn-svelte-mt5f8s1ev-svelte.vercel.app/tutorial/fallback-errors

 screenshot

yeah there's definitely lots of WIP stuff still — some broken/undesigned UI, some content that isn't done yet, missing default styles etc

(which isn't to discourage bug reports!)

Show me/reset state toggle fixed
the error.html not triggering anything is a bug inside SvelteKit itself, we need to watch these files, I'll send a fix


Proposed: particleState record

Some particles in a bunch may get lost (EG hit the vacuum chamber wall) and it may be desirable to record their "final" positions along with the rest of the particles. I therefore propose an optional particleStatus record in the Particle Root Group. I'm thinking this could be an integer with 0 indicating the particle is "alive" and anything else means "dead".
For Bmad, at least, it is useful to be able to distinguish different ways in which a particle can die (for example, hit the upper part of the vacuum pipe verses got reflected backwards in a RF cavity). Unfortunately I cannot think of a "universal" way to express this so just leaving it up to the program writing the file exactly what a non-zero value means in terms of mode of death I think is an acceptable solution.

I would make ParticleState optional.

Thanks for the proposal!
We have a similar case in PIConGPU on which we record particle leaving the simulation domain for virtual detectors.
Wouldn't you just add such particles in a special ("left-the-box") particle species (group)? Practically, that's how we do it. Additionally, one could add a scalar particle record remembering the time when a specific particle in such a particle was moved to the "dead"/"lost" species.
So there might be two relevant particle records here: current state (left box / normal / absorbed / ...) and when the last state change happened temporally. In the example I described in the paragraph above, I would then store the first usually as constant record for the whole "special" particle species group and keep the second (time when this happend) variable per particle as a regular record.

@ax3l

Wouldn't you just add such particles in a special ("left-the-box") particle species (group)?

This is possible but if there are multiple bunches it simplifies the bookkeeping to not create separate groups.

So there might be two relevant particle records here: current state (left box / normal / absorbed / ...) and when the last state change happened temporally. In the example I described in the paragraph above, I would then store the first usually as constant record for the whole "special" particle species group and keep the second (time when this happend) variable per particle as a regular record.

The absolute time is already a per particle record.

Reminds me of: #42

I do not understand what information we gain by defining a particle state. The list of possible particle states ("left the box", "annihalated", "recombined with atom A", "recombined with atom B", "left the box on top",...) is a open list. Therefore I do not see a benefit in standardizing it and everything else is exactly what the comments section is for.
Also I do not understand less groups simplify bookkeeping. Having all particles sorted into groups allows easy bookkeeping and disabled particles can be skipped in one step instead of checking every particle on its own. I think the standard supports disabled particles already, so I really dont understand why there should be the same functionality twice. This would just lead to multiple ways of doing one thing, making things unnecessary complicated.

I do not understand what information we gain by defining a particle state. The list of possible particle states ("left the box", "annihalated", "recombined with atom A", "recombined with atom B", "left the box on top",...) is a open list.

Correct. Therefore there is no proposal to standardize this list. The only thing that is proposed is to standardize the name particleStatus.

Therefore I do not see a benefit in standardizing it and everything else is exactly what the comments section is for.

Carful. "it" in this case is the name particleStatus not the list. Here is an example of how this could be useful: Program A saves coordinates of both living and dead particles. Program B reads in this file and, since particleStatus is part of the standard, program B can tell which particles it can ignore if it only wants to consider the living particles.

Also I do not understand, why less groups simplify bookkeeping. Having all particles sorted into groups is easy and disabled particles can be skipped in one step instead of checking every particle on its own.

Yes this will be simpler in some cases and the standard will support that. In other cases, where there are multiple bunches, it can be more convenient to keep all the particles, alive and dead, in one group.

I think the standard supports disabled particles already, so I really dont understand why there should be the same functionality twice. This would just lead to multiple ways of doing one thing, making things unnecessary complicated.

There are always tradeoffs here. Actually at this point the standard does not have anything about marking a particle state so this is not a multiple way of doing things.

I do not understand what information we gain by defining a particle state. The list of possible particle states ("left the box", "annihalated", "recombined with atom A", "recombined with atom B", "left the box on top",...) is a open list.

Correct. Therefore there is no proposal to standardize this list. The only thing that is proposed is to standardize the name particleStatus.

Consequently a particleStatus==5 can mean the same as another codes particleStatus==7 or particleStatus==9. IMHO I totally prefer comments over this. They would be at least human readable.

Therefore I do not see a benefit in standardizing it and everything else is exactly what the comments section is for.

Carful. "it" in this case is the name particleStatus not the list. Here is an example of how this could be useful: Program A saves coordinates of both living and dead particles. Program B reads in this file and, since particleStatus is part of the standard, program B can tell which particles it can ignore if it only wants to consider the living particles.

Also I do not understand, why less groups simplify bookkeeping. Having all particles sorted into groups is easy and disabled particles can be skipped in one step instead of checking every particle on its own.

Yes this will be simpler in some cases and the standard will support that. In other cases, where there are multiple bunches, it can be more convenient to keep all the particles, alive and dead, in one group.

I tend to disagree. It is not about convenience here, otherwise we would not need OpenPMD, because every code would just write data as it is "convenient". It is about having standard information in a standard format. Furthermore, whats wrong with electons_bunchX_alive and electrons_bunchX_deadforreasonY? Many codes already do this if the particle left the box. Why reinvent the wheel? Having a few 100 particle groups is totally legit, it is not "inconvenient" (whatever that is supposed to mean), nor does it imply mayor performance degradation.

I think the standard supports disabled particles already, so I really dont understand why there should be the same functionality twice. This would just lead to multiple ways of doing one thing, making things unnecessary complicated.

There are always tradeoffs here. Actually at this point the standard does not have anything about marking a particle state so this is not a multiple way of doing things.

I just do not see the necessity  as there is no list of possible particle states. Its just another field which contains number and the meanings of the numbers are not clear. Therefore the number can safely be written in the comments, because you need a human for its interpretation. You cannot automate it.
Besides: If all other particleStates remain undefined, lets at least define particleState==0: What exactly is an "alive" particle? A particle which takes part in all simulation steps? Certainly! What about a particle which takes part in charge calculations, but does not move (fixed ion background)? Or the opposite: A particle which moves, but does not take part in current deposition (tracer particles)? Are tracers "half-alive", because some steps during one iteration are skipped? What about particles which do move and deposit currents, but which are excluded from QED or collision calculations?
If you feel that there is the need for another "general purpose per particle property", then there should be reason, why groups cannot handle it. A good reason for that may be that the particleState is a vector or a float.
I think we need to be careful, that introducing too many options of how information could possibly be provided does not lead to too many different "flavours" of OpenPMD. That would counteract the first idea of the standard: To be able to automate the information flow unambiguously and with minimal effort [see README]

Consequently a particleStatus==5 can mean the same as another codes particleStatus==7 or particleStatus==9. IMHO I totally prefer comments over this. They would be at least human readable.

Provision for a translation table could be made to make things human understandable.

I tend to disagree. It is not about convenience here, otherwise we would not need OpenPMD, because every code would just write data as it is "convenient". It is about having standard information in a standard format. Furthermore, whats wrong with electons_bunchX_alive and electrons_bunchX_deadforreasonY? Many codes already do this if the particle left the box. Why reinvent the wheel? Having a few 100 particle groups is totally legit, it is not "inconvenient" (whatever that is supposed to mean), nor does it imply mayor performance degradation.

There are several things to consider here. Convenience is one factor but not the only one. The bottom line is will this be useful. Maybe having a few 100 particle groups with different states would be fine for your purposes but for for simulations I run this would not be.

I just do not see the necessity as there is no list of possible particle states. Its just another field which contains number and the meanings of the numbers are not clear. Therefore the number can safely be written in the comments, because you need a human for its interpretation. You cannot automate it.

Not true. Bmad based programs can use particleStatus to transmit information without human intervention.

Besides: If all other particleStates remain undefined, lets at least define particleState==0: What exactly is an "alive" particle? A particle which takes part in all simulation steps? Certainly! What about a particle which takes part in charge calculations, but does not move (fixed ion background)? Or the opposite: A particle which moves, but does not take part in current deposition (tracer particles)? Are tracers "half-alive", because some steps during one iteration are skipped? What about particles which do move and deposit currents, but which are excluded from QED or collision calculations?

This is a valid point. But consider this: For simulations of accelerators, most of the time, "dead" means hit the vacuum chamber wall and "alive" means the particle is still moving and that is the only information that is needed. So for many simulations, particleStates will be useful as is.

If you feel that there is the need for another "general purpose per particle property", then there should be reason, why groups cannot handle it.

Yes I feel there is need for this. And right now the standard does not have anything that can take its place. The standard has no convention for designating dead particle groups.

I think we need to be careful, that introducing too many options of how information could possibly be provided does not lead to too many different "flavours" of OpenPMD. That would counteract the first idea of the standard: To be able to automate the information flow unambiguously and exchange data with minimal effort [see README]

Again, currently there is no other option. By the way, after talking to Remi and Axel, the plan is to put particleState into the beam physics extension and not the base standard. So if you do not plan to use the beam physics extension you do not have to bother about this.

In fact, there is another option, which is particle groups. Anyways, if you guys are all convinced, that this is not only useful, but necessary to represent information, that cannot be represented by the current version, keep going. Just for the record: I strongly vote against this change as it does not simplify the exchange of information between different programs (meaning programs, which have been developed interdependently) or visualization tools.

I think indeed taking numbers & translation tables is not ideal but we want to make it a record (constant or not) putting strings is not great, because each entry has a different length if non-constant.
If we, on the other hand, don't want to label individual particles but whole particle species (groups) for now, a comment, reserved new a string attribute (instead of a magic number) or a group-label #163 would do as well. @DavidSagan do you need it for particles inside a species group or for full species groups for now? If the latter, I would recommend an optional species group string attribute in EXT:BeamPhysics.

@ax3l I need it particle-by-particle and not on a per-group basis so a species group string is not helpful. My experience is that by far most simulations simply care about the particle being "alive" versus "not alive" so using an integer will generally not be problematic.

I could not stop thinking about it and in my perspective, there are two things which need to be clarified:

Why can the information not be provided within the possibilities of the current standard? I.e. What is the argument, that this is really needed on a per-particle basis and and not on per-particle group?
How does the change enhance interoperability with other simulations? Of course meaning other simulations which have been developed independently. If this is specific to Bmad based programs (as mentioned earlier), other software might not be able understand the meaning correctly. I am wondering if you could please add some specific examples from Bmad and other software packages? What states do they distinguish, why and how is it implemented? That might be very much helpful. Thank you!

@skuschel

There currently is nothing in the standard saying how to specify a "dead" particle group. If you believe otherwise please provide an example or pointer to where in the standard this is discussed.

As I mentioned earlier, my experience is that by far most simulations simply care about the particle being "alive" versus "not alive" and the proposed "particleState" standard is unambiguous on this. Thus this will be useful outside of Bmad. In Bmad the particle states are:

alive
lost_neg_x_aperture
lost_pos_x_apertue
lost_neg_y_aperture
lost_pz_aperture
lost     !  Catchall used if not one of the above lost states is appropriate

I am in favor of adding the per-particle particleStatus(integer), with a list of common statuses enumerated in the standard. Particle status is used by many codes, and sometimes this list can be long. See, for example, the Astra manual:
http://www.desy.de/~mpyflo/Astra_manual/Astra-Manual_V3.2.pdf
Alive (track) and dead (don't track) could be standardized, with more added as the common needs are identified.

Implemented in Beam Physics extension.


Bump abstract char limit to 5000

I've left the suggested limit to 1500, maybe we should improve the wording, something like:
Suggested size: 1500 chars. Max size: 5000
@alanderex what do you think?

Yes, good idea! 👍


test: implement test cases for closing and reconnecting WebSocket

@pokryfka I'll review properly later this week, I've been sick for a couple days.
I also appreciate that you've included tests, but why in a separate PR? I'd prefer this was self-contained tbh.

@pokryfka I'll review properly later this week, I've been sick for a couple days.

No worries, I am happy to help to add momentum to the project but I dont think I will start using it in production any time soon, so none of it is urgent.
FYI I will be offline for 1.5 weeks from Oct 28, will check your comments after I am back.

I also appreciate that you've included tests, but why in a separate PR? I'd prefer this was self-contained tbh.

I think additional tests add value regardless if and when WebSocket refactoring is merged.
Ideally test cases should be implemented before any refactoring (and arguably even before implementation is finished), not after or during, to make sure the expected behaviour remained the same.
I can merge it to #180 if you prefer.

I think additional tests add value regardless if and when WebSocket refactoring is merged.

Of course.

Ideally test cases should be implemented before any refactoring (and arguably even before implementation is finished), not after or during, to make sure the expected behaviour remained the same.

I respectfully disagree. That's just one approach (TDD I guess you're referring to), its not he only or even necessarily "ideal" approach. It's very much a personal approach in my 25 years of experience I've seen various approaches and have no evidence in practice of any approach leading to more testable or more important reliable and robust code.
Generally the issue is a lack of understanding how to write quality tests, not "when" you wrote the tests 👍
Just my two cents 😉

I can merge it to #180 if you prefer.

100% I think that's the right way to review this. I 100% agree with you, adding tests here is extremely important 👍
Thanks again!

If you can merge these changes into the other branch that would be great, I'll close this here since you can sort that separately thank you!


Add block countries

Allow to block a whole country easily to avoid spammers or unwanted users from countries the website don't target.

I will look how you've done this and change what I've done to have it on the same model of design.
Question, you told me to make a branch and push onto the repo I've forked or this one?
Thx
Le 20 mai 2018 15:38:55 EDT, "♚ PH⑦ Soria ♛"<EMAIL_ADDRESS>a écrit :

Allow to a whole block country easily to avoid spammers or unwanted
users from countries the website don't target.

You can view, comment on, or merge this pull request online at:
https://github.com/pH7Software/pH7-Social-Dating-CMS/pull/206
-- Commit Summary --

Change comment to better one
Make comments shorter; More readable
Add block countries tables to SQL files
Add BlockCountry Model
Add migration script for BlockCountry SQL queries
Add Block Country page
Integrate Block Country (if any are found) to the Core Controller
Add BlockCountry link on admin Tool drop-down menu
Add PFBC BlockCountry form (and process form)

-- File Changes --
M _install/data/sql/MySQL/pH7_Core.sql (10)
M _install/data/sql/PostgreSQL/pH7_Core.sql (14)
M _protected/app/configs/bans/bank_account.txt (3)
M _protected/app/configs/bans/email.txt (4)
M _protected/app/configs/bans/ip.txt (4)
M _protected/app/configs/bans/username.txt (2)
M _protected/app/configs/bans/word.txt (2)
M _protected/app/includes/classes/DbTableName.php (1)
M _protected/app/system/modules/admin123/controllers/ToolController.php
(8)
A _protected/app/system/modules/admin123/forms/BlockCountryForm.php
(49)
A
_protected/app/system/modules/admin123/forms/processing/BlockCountryFormProcess.php
(42)
A
_protected/app/system/modules/admin123/views/base/tpl/tool/blockcountry.tpl
(3)
M _protected/framework/Mvc/Controller/Controller.class.php (23)
A _protected/framework/Mvc/Model/BlockCountry.class.php (78)
A _repository/upgrade/12.1.0-12.6.0/data/sql/MySQL/upgrade.sql (15)
A _repository/upgrade/12.1.0-12.6.0/data/sql/PostgreSQL/upgrade.sql
(20)
A _repository/upgrade/12.1.0-12.6.0/info/conclusion.php (22)
A _repository/upgrade/12.1.0-12.6.0/info/config.ini (7)
A _repository/upgrade/12.1.0-12.6.0/info/introduction.php (22)
M templates/themes/base/tpl/top_menu.inc.tpl (1)
-- Patch Links --
https://github.com/pH7Software/pH7-Social-Dating-CMS/pull/206.patch
https://github.com/pH7Software/pH7-Social-Dating-CMS/pull/206.diff
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/pH7Software/pH7-Social-Dating-CMS/pull/206

--
Polyna-Maude R.-Summerside

Hey PM, great if that can help :)
The best is always to create a separated branch (and now this one has already been merged ^^).

Just clone it git clone git@github.com:pH7Software/pH7-Social-Dating-CMS.git
Create a new branch (never push changes on master).
Push it
Open a PR

P.S. If you use your fork, please always update the repo first  (git pull), before starting changes to avoid conflicts.

Good ! You confirm what I believed.
PM
Le 20 mai 2018 16:36:20 EDT, "♚ PH⑦ Soria ♛"<EMAIL_ADDRESS>a écrit :

Hey PM, great if that can help :)
The best is always to create a separated branch (and now this one has
already been merged ^^).

Just clone it git clone git@github.com:pH7Software/pH7-Social-Dating-CMS.git
Create a new branch (never push changes on master).
Push it
Open a PR

P.S. If you use your fork, please always update the repo first  (git
pull), before starting changes to avoid conflicts.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/pH7Software/pH7-Social-Dating-CMS/pull/206#issuecomment-390510516

--
Polyna-Maude R.-Summerside

👍 😃

Hi Ph,
Did the Pull Request and recejved 36 messages about style violation. Find that great to have automatic code validation. I'll give a check at what is said but probably a fotmatting mode that I've set wrong or a CR/LF conversion from Windows.
Cheers !
PM
Le 20 mai 2018 17:08:38 EDT, "♚ PH⑦ Soria ♛"<EMAIL_ADDRESS>a écrit :

👍 😃
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/pH7Software/pH7-Social-Dating-CMS/pull/206#issuecomment-390512890

--
Polyna-Maude R.-Summerside


Run wamr wasi-thread tests with AOT

Okay, now it's working https://github.com/bytecodealliance/wasm-micro-runtime/actions/runs/4425593675/jobs/7760970727?pr=2026
In fact only thread_spawn-simple was run before this PR for AOT

In fact only thread_spawn-simple was run before this PR for AOT

I don't think so, it was enabled for the all the tests in the proposal, but not the others (in core/iwasm/libraries/lib-wasi-threads/tests)
https://github.com/bytecodealliance/wasm-micro-runtime/actions/runs/4421417435/jobs/7752335202?pr=2028

You're right, in last successful build on main it ran https://github.com/bytecodealliance/wasm-micro-runtime/actions/runs/4421453274/jobs/7752345299 . Probably I confused it with one earlier commits in this PR


Get access to CERN's REANA instance and run first example

[x] Go to https://reana.cern.ch/ and login with your CERN Single Sign On credentials
[x] From your profile (https://reana.cern.ch/profile) record your REANA_ACCESS_TOKEN in a secure manner (recommendation: a password manager application)

You'll need your REANA_SERVER_URL as well, but that's public information (https://reana.cern.ch) that doesn't need to be protected

[x] Create a new Python virtual environment for testing REANA
[x] Run through the "first example" in the REANA "Getting started" docs using that Python virtual environment

(This Issue is unrelated to Issue #1 and is just to get used to working with REANA. Once we reach a point where we can understand how to turn https://github.com/Cisneros-Galaxy/RCFM into something we can implement in a workflow language then we can use a similar workflow to the one you learn here to implement the analysis on REANA.)

#4


feat: resizable sidebar

Implementation for sfeir-open-source/xlayers#43.

TEST

Preview: $PREVIEW_BUILD_URL

Preview: $PREVIEW_BUILD_URL

Preview: $PREVIEW_BUILD_URL

Preview: https://xlayers-5f3b8d2.angular.run

Preview: https://xlayers-663979c.angular.run


bug(MatExpansionPanel): Panel Expanded in MatStepper regardless of [expanded]

Is this a regression?

[X] Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was
6
Description
Expansion panels currently render with a flash of content when nested in MatStepper -- they always temporarily appear as expanded, regardless of what the "expanded" attribute is set to. After a moment, all expansion panels that have been explicitly set to closed collapse.
Reported fixed by #13870
However this is just when opened in a dialog without any other nesting
Reproduction
StackBlitz link: https://angular-issue13870-stepper-dialog.stackblitz.io
Steps to reproduce:

Create a MatStepper component to contain an expansion panel
Add a MatExpansionPanel
Set [expanded]="false"

Expected Behavior
MatExpansionPanels currently render with a flash of content when nested -- they always temporarily appear as expanded, regardless of what the "expanded" attribute is set to. After a moment, all expansion panels that have been explicitly set to closed collapse.
Actual Behavior
MatExpansionPanels should appear as collapsed when the dialog opens when expanded=false instead of briefly appearing as expanded, then collapsing after a delay.
Environment

Angular: 14.2
CDK/Material: 14.2
Browser(s): Chrome
Operating System : Windows

@crisbeto Thanks for the quick turn around on this issue. Assuming this will only be fixed in the next major release?

The fix should be in 16.1.2 later this week.


Test methods must be in test classes

As of Summer '13,  test methods ought to be in their own test classes. From the release notes:

Starting in Summer ‘13, test methods can be defined only in test classes (classes annotated with @isTest). You can no longer add a test method in a non-test class. This change applies to new Apex code saved using Salesforce.com API version 28.0 and later. Apex code saved using earlier API versions isn’t affected. This change is in line with the Apex coding best practice of including test methods in test classes. Test classes don’t count toward your organization’s code size limit, so separating the test code from the product code enables you to write more Apex code. Also, Apex testing will be enhanced in future releases and this is a prerequisite for those planned enhancements.

V4SF has many test methods inlined into classes. I discovered this while trying to deploy from MavensMate.

Note: this is likely very low priority and I realize that.

Somehow, I pulled one commit below head, and this actually isn't true at all... Not sure at all how I managed to do that, but please ignore me.


documents for "Subcharts" built-in object

I do not find any document for "Subcharts" object, not released yet ?

@chuckliu1979 Can you provide more details on what you are referring to?

@chuckliu1979 Can you provide more details on what you are referring to?

sure.
i see ".Subcharts" object here: https://github.com/helm/helm/blob/main/pkg/engine/engine.go#L360
but no document found: https://helm.sh/docs/chart_template_guide/builtin_objects/

@chuckliu1979 Would you please file an issue in the documentation repo?


Generic Query Conventions Need Defining

Right now, we have a lot of SearchWhateverRequest objects, each of which contains some number of search parameters.
The enrage idea seems to be that most parameters take arrays of acceptable values (but interpret the empty array as any value being acceptable), and that results are supposed to satisfy all of these constraints. However, this isn't actually stated anywhere as a principle of the APIs' design, and many parameters of query objects do not follow this convention (for example, you can only supply a single assemblyId when issuing a SearchReferenceSetsRequest). We should figure out when the array semantics are appropriate and when the single-value semantics are appropriate, and produce a design document that tells us how to add any particular query constraint in the future.
This is related to #247 and #253 (as they are addressing the issue of standardization for some fields), as well as #256 (as the design documentation would probably go in whatever that produces). It also touches on some line note discussions we were having on #250 with @fnothaft, @jeromekelleher, and @pgrosu.

Definitely +1 on this idea. Hopefully this will be clearer when we resolve #247.


Update README.md

Per MS style guide, Avoid please except in situations where the customer is asked to do something inconvenient or the application or site is to blame for the situation.

Thanks @Rick-Anderson !


define variable in a js block

I put jinjia2 variable in a js block。as below:

and {{tmp_cnt}} = 2 , {{res_detail_interface}} is a list。but res_detail_interface[debug_cnt] is null。{{res_detail_interface[debug_cnt]|tojson}} show:

I try to defind {{tmp_cnt}} out the js block。the result is good。why?
##Environment

Python version:2.7.13
Jinja version:2.10

OK.next time,i'll post the actual code.
the above question:
##actual code
去调试

2 and '2' are different things. Use foo|int to convert a variable foo to an integer in case it's a string.

var tmp_cnt = Number($("tr:eq(" + trSeq + ")>td:eq(0)").text());
{% set debug_cnt = "+tmp_cnt" %}

Unless you define tmp_cnt in Jinja as well,, this obviously cannot work BTW. Jinja runs on the server, JavaScript on the client.


updated PR #5

this is not ready, and I have no time for it, just opening it to signal that #5 is not the most recent. Help to ensure correctness of the changes would be very welcome.

I've rebased this PR to the latest master: https://github.com/undu/ISO8601.ml/tree/wip-merge-pr-5
The new ounit tests are failing, messing with the local timezone I can see that their results depend on the local timezone. I don't think many of this should depend on the local timezone. and more effort is needed to compensate the timezone from the system calls or remove the system calls completely.
An example with GMT + Daylight Summer Time (London, today):
==============================================================================
Failure: ISO8601:0:[PARSER]:4:[DATETIME WITH TIMEZONE]:2:1979-05-27T00:32:00.999999-07:00

expected: 1979-05-27T09:32:00 but got: 1979-05-27T10:32:00
------------------------------------------------------------------------------
==============================================================================
Failure: ISO8601:0:[PARSER]:4:[DATETIME WITH TIMEZONE]:1:1979-05-27T00:32:00-07:00

expected: 1979-05-27T09:32:00 but got: 1979-05-27T10:32:00
------------------------------------------------------------------------------
==============================================================================
Failure: ISO8601:0:[PARSER]:4:[DATETIME WITH TIMEZONE]:0:1979-05-27T07:32:00Z

expected: 1979-05-27T09:32:00 but got: 1979-05-27T10:32:00
------------------------------------------------------------------------------
Ran: 64 tests in: 0.02 seconds.
FAILED: Cases: 64 Tried: 64 Errors: 0 Failures: 10 Skip:  0 Todo: 0 Timeouts: 0.

An using Central time + DST (Mexico City, today):
==============================================================================
Failure: ISO8601:0:[PARSER]:4:[DATETIME WITH TIMEZONE]:2:1979-05-27T00:32:00.999999-07:00

expected: 1979-05-27T09:32:00 but got: 1979-05-27T10:32:00
------------------------------------------------------------------------------
==============================================================================
Failure: ISO8601:0:[PARSER]:4:[DATETIME WITH TIMEZONE]:1:1979-05-27T00:32:00-07:00

expected: 1979-05-27T09:32:00 but got: 1979-05-27T10:32:00
------------------------------------------------------------------------------
==============================================================================
Failure: ISO8601:0:[PARSER]:4:[DATETIME WITH TIMEZONE]:0:1979-05-27T07:32:00Z

expected: 1979-05-27T09:32:00 but got: 1979-05-27T10:32:00
------------------------------------------------------------------------------
Ran: 64 tests in: 0.03 seconds.
FAILED: Cases: 64 Tried: 64 Errors: 0 Failures: 10 Skip:  0 Todo: 0 Timeouts: 0.

There are a lot of alcotests failing, but I haven't looked into that


Fix employee demo

When I tested the results of the employee pipeline I found it wasn't working

I'd forgotten to declare the bonusAmount and Pay rate columns as floats in the 2nd phase
Detecting that the pay type was "Year" wasn't working because of a space in the CSV, so the unrecognized pay type was causing the salary to be set to 0
calculating the bonus percentage was just skipped because salary seemed to be zero

So it was all passing, but a combination of bugs made the bonus percent stuff just not get done.
While doing this I added a FloatColumn test just for safety, and a test for the problem where a space in the CSV combined with a quoted string meant that a string was double-quoted with the space in the row_data

It will probably also make sense to have a DecimalColumn because dealing with money should not use floats. Maybe we even declare a MoneyColumn type to make that explicit.

Yes - another reason to use a more basic CSV parser and clean values
ourselves, and not use pandas.  I guess in this case we could do value
cleaning after loading with pandas but I'm not sure what to commit to yet.
On Mon, Feb 26, 2024 at 2:15 PM Jeff Kolesky @.***>
wrote:

@.**** approved this pull request.
In tests/fixture_files/employees.csv
https://github.com/lisad/phaser/pull/56#discussion_r1503373239:

\ No newline at end of file
+1,Benjamin,Sisko,"salary","Year","188625","30000"

Can we configure the csv parser to handle spaces between headers and
fields? Seems reasonable, though it may not be "to spec."
—
Reply to this email directly, view it on GitHub
https://github.com/lisad/phaser/pull/56#pullrequestreview-1902143022,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADWH4MRCUYF3BYAFK5JRV3YVUCOTAVCNFSM6AAAAABDXXYXXWVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTSMBSGE2DGMBSGI
.
You are receiving this because you authored the thread.Message ID:
@.***>


Sdk 8.10.0

This upgrades firebase remote config to C++ SDK to 8.10.0 / iOS SDK to 8.13.0 in line with similar upgrades to extension-firebase and extension-firebase-analytics in 2022.
Resolves https://github.com/defold/extension-firebase-remoteconfig/issues/6

Thank you!


Avoid crash on malformed json.

Avoid crash repl on malformed json.
Is we just pass the string direct after a unsuccessful parser the fastest-validator will handle properly.

We made this at the exact same time.
I think it would be more intuitive and safe if it gave us an error and stopped the call from happening, rather than continue on with the call.

If the call needs a string, the inner call will handle, if not fastest-validator will tell us and get raiser a error.
There's other possibility?

I'm just trying to think if you're trying to put in some kind of optional parameter, would cause behavior the user does not expect.
For example, users.list '{deleted: true}' would still continue to list all users (but not deleted users, as the default for deleted might be false) and the user would not know that they are viewing users normally. So some error needs to be there or we can go with my PR.

Yes, you are right. Just update the PR.


Provide a paper project template

 Issue by blois
Originally opened as dart-lang/sdk#20531

Currently there's no good starting point for creating a QP-styled application. Would be great if there was a pub run generator for this.

 Comment by jakemac53

Removed Type-Defect, Priority-Unassigned, Pkg-Polymer labels.
Added Type-Enhancement, Priority-Medium, Pkg-PolymerDevExp labels.


[docs] V3 Migration Guide: Include notes about withMobileDialog vs useMediaQuery

I followed the upgrade guide from v3 to v4 last week:
https://material-ui.com/guides/migration-v3/
There was no mention of withMobileDialog being deprecated. Looks like it's mentioned in #22074, but it looks to have been deprecated after v3. Searching for the function yields no results.
I found out about useMediaQuery after reading thru related react-testing-library issues, and poking around the MUI docs themselves. Seems like it's the preferred way to handle responsive dialogs. But again, not mentioned in the upgrade guide.
https://material-ui.com/components/dialogs/#responsive-full-screen
I did find that, if you wanted to keep withMobileDiaglog in your app, you just need to adjust your test setup like so:
https://material-ui.com/components/use-media-query/#testing
I don't mind opening a pull request to update the guide, but am unsure of desired format. Seems like the guide is pretty minimal in descriptions, showing upgrade strategies (like for component refs) in other pages.

[x] The issue is present in the latest release.
[x] I have searched the issues of this repository and believe that this is not a duplicate.

withMobileDiaglog is getting removed in v5. We are still working on the deprecation in #23570.

@oliviertassinari Thank you, but even though it's not removed, it's not even searchable on the MUI v4 docs. And not mentioned in Dialogs anymore. The fact others had issues with Dialog mounting in react-testing-library (including myself), and I can't find the function in the current docs, tells me the upgrade docs are missing important info.

We have hidden the module from the documentation somewhere in v4. The assumption is that if you are already using it, you don't need the documentation for it.

When I upgraded to v4, there was no warning or notice about using withMobileDialog though. I was in the dark for a couple of days as to why my tests failed. I happened to stumble and put the pieces together myself that this function is losing support, and to move to a hook instead. Like I said, this was not mentioned in the upgrade docs. And IMO, somewhere should mention the drop of the HOC from docs, and point to the recommended way to perform responsive UIs now

Oh, that's a different issue. You are talking about how withMobileDialog uses media queries instead of the window's width.

@oliviertassinari  There seems to be a misunderstanding. This is not about testing. It is in fact about docs. (Please re-add the tag)

I am on v 4.11.0 of material-ui
After upgrading, my Dialog instances were wrapped in withMobileDialog()
I found that all tests touching these components, in Jest/React-Testing-Library failed

I understand MUI is not responsible for test failures from upgrades

Migration Guide, or anywhere in the docs, mention how useMediaQuery is preferred over withMobileDialog
In fact, withMobileDialog is no where in the docs anymore, making it difficult to know, without reading every related doc, that MUI v4 has a different preferred pattern for responsive dialogs

Proposal: Update somewhere in the docs how useMediaQuery is now preferred over the old withMobileDialog. Preferably in the migration docs, as this was no problem in v3.
Reason: I am not alone in finding problems after the upgrade. I am sure more folks will continue to run into the same problem as me, until v5 is fully released. Even then, people may try to upgrade v3 -> v4 -> v5, and then still run into my issue.

I found that all tests touching these components, in Jest/React-Testing-Library failed

You need https://material-ui.com/components/use-media-query/#testing to solve the issue. withMobileDialog uses withWidth that uses useMediaQuery.

@oliviertassinari Yes, I linked that exact in my original post. Can you just include that in the migration guide, or somewhere that's easy to spot, for folks currently using withMobileDialog? I've been very clear, and not sure what's up

@onebree Sorry, we are focusing on the migration from v4 to v5, anything past that is not a priority.


Ability to link to Props or other tabs

Link to the Page
No response
Describe the Issue
It would be handy if you could link to https://www.skeleton.dev/components/app-bar#props rather than having to tab every time.
Are you able to create a Pull Request with the fix?
Yes

Yep, wanting this as well. Fairly easy to implement too!


Constructor for collections.set from list

Something like:
echo collections.set([1, 2, 3])

should give use set(1,2,3).

Added in v0.11.6


Borrowing code for doc generation.

Hi @patrick-kidger,
Just wanted to check-in with you first if it is ok to reuse the code from equinox for generating docs for eqxvision?
While making changes to color theme, contents etc.
Thanks.

Yep, that's totally fine.


async api core dump when in multi thread sisuation

Env:
hiredis: 0.14.0
libevent: 2.0.21-stable

Situation:
In my program, use redisAsycnCommand to send redis command(e.j. set/get), multi threads works separately, that means every worker threads holds a independent redisAsyncContext object.
As we all known, the libevent function "event_base_dispatch" is a block api, which a thread call this api will block the thread to execute conitinue until there'are no events to proccess or call exit function to terminate.
So, I create a independent thread to start the event_base_dispatch, and i can run stable in a low pressure request, but encountered segment fault when lots of requests call.
My demo code is :

redisAsyncContext *c = redisAsyncConnect("<IP_ADDRESS>", 6379);
redisLibeventAttach(c, base);
redisAsyncSetConnectCallback(c, connectCallback);
redisAsyncSetDisconnectCallback(c, disconnectCallback);
pthread_t tid;
pthread_create(&tid, NULL, raw_async_thread_func, (void*)param);
pthread_create(&ttid, NULL, start_event_base_func, (void*)base);

Question:
I review the hiredis code, and found that every async api operate the buf of redisAsyncContext, so when in the above sisuation, two thread may modify the buf at the same time, and the sds is not thread safty object, so segment fault can happen.
The demo of the official wiki is:

struct event_base *base = event_base_new();

    redisAsyncContext *c = redisAsyncConnect("<IP_ADDRESS>", 6379);
    if (c->err) {
        /* Let *c leak for now... */
        printf("Error: %s\n", c->errstr);
        return 1;
    }
    redisLibeventAttach(c,base);
    redisAsyncSetConnectCallback(c,connectCallback);
    redisAsyncSetDisconnectCallback(c,disconnectCallback);
    redisAsyncCommand(c, NULL, NULL, "SET key %b", argv[argc-1], strlen(argv[argc-1]));
    redisAsyncCommand(c, getCallback, (char*)"end-1", "GET key");
    event_base_dispatch(base);

but, this cannot recieve any other command using redisAsyncCommand, because of event_base_dispatch block current thread to run continue.
So this is unreasonable usage code, I think we want to send redis commands to server work with event loop together, that means one worker produce task and libevent consume it.
I think if the we add lock before operate the buf object, the sdscatlen will not cause segment fault again.
some related issue list :

https://github.com/redis/hiredis/issues/460
https://github.com/redis/hiredis/issues/493
https://github.com/redis/hiredis/issues/480
https://github.com/redis/hiredis/issues/490

Mybe someone encounter the same sisuation, really hope can share the correct code
Thanks.

Let me understand this.. you want to be able to send commands from different threads, while having it wait for replies on a blocking thread?

Hi @jackycchen ,
Even I have faced this exact situation, no problem if the load is less. But when the requests are bombarded it dumps core due the reasons you mentioned.
Please let me know do you have any solution to this?
Need some inputs on design approach to properly integrate hiredis async into real world application.
Is it unsafe to use async API in such situation?
Thanks & Regards.

Dit it add a lock to redisAsyncContext work?

You can always try, but I don't suggest that strategy.  My suggestion would be to not share redisContext structures across threads to avoid headaches.
There are also hiredis wrappers that have been made thread safe although I've not used them myself.
Closing as I don't think there's a hiredis bug here.


Add logger.

Only use Logger.debug for CLI.

:+1:

:+1: seems strange that you don't have any usage of the module in this PR, but I know you want it for the lint project


ts: Fix program upgrade event crashes existing listeners

Problem is described here #1685 .
I've added try/catch to ExecutionContext class and created callback error with name $error (because in rust you can't have struct which starts with $). Also provided tests where it fails if you don't handle it.
I'm open for any other solution, as I'm not sure where and how I should have handled it.

If Im understand your issue correctly, he fix shouldnt be to handle the error gracefully but to not error in the first place. Anchor should be able to handle events from updated programs. Please see my comment in the issue

If Im understand your issue correctly, he fix shouldnt be to handle the error gracefully but to not error in the first place. Anchor should be able to handle events from updated programs. Please see my comment in the issue

I've replied there. Also, I can change regex if it will be better handling of the issue.


[modules] Simplify PartialFunction

remove PartialFunction from io.vavr.core, especially Function1 should not depend on PartialFunction
move PartialFunction to io.vavr.match because pattern matching is our only use-case for partial function (I think collect does not work at all)
let PartialFunction stand on its own, it should not extend Function1 or j.u.Function

Reason: Scala has PartialFunction deeply integrated into the language (e.g. pattern matching and the case literal). We can't do that in Java. Trying to integrate it on our own seems artificial and it does not scale well regarding future versions of Java (which will come with native pattern matching).

We have another use-case: Value.collect(PartialFunction)
Therefore we should keep PartialFunction as part of the core.


Avoid -SNAPSHOT dependencies

Using SNAPSHOT versions of dependencies makes it tricky to figure out which version to build with. If you really have to do it, it would be nice to have the corresponding commit hash of upstream written down.

Yes, it's a bad practice, but needed in this case for the release.
Egit GitHub sees very little activity lately, and each release has only a few commits (most of the mine), so a snapshot is almost the same as the final release and shouldn't affect the build.
I'll remove it ASAP.


Mobilefirst toolbar headline section

Update README File
Add linters.yml file
Add HTML and CSS for the Toolbar
Add HTML and CSS for Headline Section.

Converted all the px sizes to rem so the layout might not be pixel-perfect for some elements.


Refactor passkey owner

Refine PasskeyOwner interface to let sign return only general WebAuthn data

The original signature abi encoding is specific to our PasskeyAccount contract implementation, so it should be the account's responsibility to encode.

Refine packages/webAuthn importing path.

Note: Test passed using the following account:

PasskeyAccount v0.6 on Sepolia
PasskeyAccount v0.7 on Sepolia
PasskeyAccount v0.7 on Polygon Amoy


More support for deprecated fields/models

Initial Checks

[X] I have searched Google & GitHub for similar requests and couldn't find anything
[X] I have read and followed the docs and still think this feature is missing

Description
https://github.com/pydantic/pydantic/pull/8237 implemented support for deprecated fields. While doing so, we encountered/postponed some extra features that could be nice to have:

When using the deprecated decorator class, extra information (such as the category and stacklevel) can be passed. It would be great if Pydantic could support such attributes when emitting the runtime warning. For reference, this commit implements the feature: https://github.com/pydantic/pydantic/pull/8237/commits/cf06a7322d59aefc2e3ca607f0c5ee66d28f6757 (extra care should be taken with the typing-extensions version -- Only 4.9.0 and greater support the class implementation of the deprecated decorator).

When instantiating a model with a deprecated field explicitly specified (Model(deprecated_field=...)), the runtime warning could be emitted.

Support for Pydantic/stdlib dataclasses: not sure if there are any technical limitations for this one?

Support for deprecated models:

With the @deprecated decorator:@deprecated("deprecated model")
class Model(BaseModel):
    pass

The decorator takes care of the runtime warning (tested locally and doesn't seem to cause any issues with the model metaclass). However, the JSON Schema should reflect the deprecation.
via a config option, in a similar fashion to the argument to Field:class Model(BaseModel):
    model_config = {"deprecated": "deprecated model"}

I wouldn't really recommend the second option, as type checkers won't be aware of the deprecation (same for computed_field)

These were the ideas I had while implementing support for deprecated fields. Some of them requires some discussion, as I'm not sure whether it should be supported or not. Happy to hear your opinions
Affected Components

[ ] Compatibility between releases
[X] Data validation/parsing
[ ] Data serialization - .model_dump() and .model_dump_json()
[X] JSON Schema
[ ] Dataclasses
[ ] Model Config
[ ] Field Types - adding or changing a particular data type
[ ] Function validation decorator
[ ] Generic Models
[ ] Other Model behaviour - model_construct(), pickling, private attributes, ORM mode
[ ] Plugins and integration with other tools - mypy, FastAPI, python-devtools, Hypothesis, VS Code, PyCharm, etc.

Agreed. PRs welcome for parts or all of the above features. Ping me if you want to chat more about implementation details :).

@sydney-runkle @Viicos I had started to look into implementing point 4, and from my testing, the @deprecated decorator on a model does emit a runtime warning when using the model.
My question is, should a warning also be emitted in the following scenario?
@deprecated
class DeprecatedModel(BaseModel):
    pass

class NewModel(BaseModel):
    field: DeprecatedModel

Do you think that in this case Pydantic should emit a warning along the lines of Usage of deprecated model `DeprecatedModel`?

That's great to hear!

Do you think that in this case Pydantic should emit a warning along the lines of Usage of deprecated model `DeprecatedModel`?

Do you mean the warning should be emitted during class creation? (And thus whenever the model's module is imported).
That might be too invasive, although I can't think of a use case where a user would be constrained to use a deprecated model as a field in the model he is defining. Let's maybe here what the maintainers think of it

Do you mean the warning should be emitted during class creation? (And thus whenever the model's module is imported). That might be too invasive, although I can't think of a use case where a user would be constrained to use a deprecated model as a field in the model he is defining. Let's maybe here what the maintainers think of it

I actually meant to emit a warning when a user defines a model with one of its fields being a deprecated model, not when the deprecated model is created/imported.
In my examples above, when creating NewModel, we could check to see if a field is defined with the type of another subclass of BaseModel and then check if has the __deprecated__ attribute.

Also, just a side note, I don't think we should support the config based deprecation above, but the deprecated decorator approach is great.

Has any progress been made on:

When instantiating a model with a deprecated field explicitly specified (Model(deprecated_field=...)), the runtime warning could be emitted.

I'm currently doing this with a validator, but this would be nice to have.

Nope, not yet @allenlawrence94. Feel free to open a PR with support this!

I'd like to get some comments here for David's comment: https://github.com/pydantic/pydantic-core/pull/1551#issuecomment-2505791080
There is some concern about this new deprecation warning breaking users' existing code. To address this, I think we can add one new model config like suppress_deprecation_warning which allows users to ignore warnings due to deprecated fields being filled or accessed. Essentially, this new model config is equivalent to disabling/nullifying any support for deprecated fields because the only difference between deprecated fields and regular fields is the warning. One important thing here, in my opinion, is to either keep all warnings or raise nothing at all. We shouldn't allow users to partially suppress warnings, e.g. "no warning at model instantiation please but we want warnings when fields are accessed." I don't think there's any use case that really makes sense -- it's kind of strange to me that one needs such specific control for deprecation warning.
Meanwhile, unlike what David mentioned in his comment, I think this "suppress_deprecation_warning" thing should be opt-out rather than opt-in. This being opt-in basically means turning off support for deprecation fields by default and that this feature needs one additional step to be enabled. For instance, if one wants to use deprecated fields, this user needs to not only annotate those fields as deprecated but also set something like enable_deprecated_fields in model config, which is like double opting in. This is awkward and definitely leads to bad user experience in my opinion. Also, since the support for deprecation fields is already released, making this whole warning suppression thing opt-in will possibly break some other users' code as well. On the other hand, if we go for opt-out, some users' code might break after they upgrade pydantic, but they can then set this model config to opt out so that they can either completely ignore these errors or buy some time to fix the warnings. As what I said above, I think it's unlikely that users are okay with deprecation warnings at some specific spots only, so eventually they will probably just fix the warnings or handle them somehow and remove the model config. Another thing about making this opt-out by default is that this matches what one gets with the @deprecated decorator, e.g. deprecated models -- users opt in and get warnings from whatever is decorated. There isn't even an option for opting out, which is natural (why opt out? Either remove references to the model or remove the decorator!)
Overall, I think we are thinking too much about this warning breaking anything. If a deprecation warning does break something, that thing should have been handled properly. We can provide users with an option to suppress such warnings, but that should be a temporary solution.
Please let me know what you think. Thanks!

e.g. "no warning at model instantiation please but we want warnings when fields are accessed." I don't think there's any use case that really makes sense -- it's kind of strange to me that one needs such specific control for deprecation warning.

Actually, I think there is. It all depends on who is consuming/using the model. If as a library, you provide instances of a model you control (say consumers of the library make use of a model as an annotation in a FastAPI route, and the route function implementation makes use of the model fields), you want to warn on attribute access, but you may not want the warning to be raised when you instantiate the model (because you are the "owner", you control the fields being defined, so you know you can safely instantiate a model with a deprecated field, and when you change the model definition, you are a able to not provide the field value anymore).
It also depends on the reason why the field is deprecated. I can see two scenarios for a field to be deprecated:

replaced by a new one. In that case, it would make sense to warn on instantiation, as you can just provide the value for the new field.
planned for deletion. In that case, you will still have to provide a value, the deprecation warning is just here to warn consumers of the model.

Instead of introducing a new config value, we were thinking about introducing a new Deprecation helper class, so that you can use it this way:
class Model(BaseModel):
    a: int = Field(deprecated=Deprecation("'a' is deprecated", mode='warn-on-instantiation'))

But this gets pretty complex.

I see. You are right. I only thought about the cases where users instantiate models and consumes the instances and completely missed out common uses cases as you described, like client libraries. Though in such cases, if users somehow instantiate the models themselves rather than consuming from library methods, they won't get warnings. I guess this is beyond what we can do here since model initialisers are always public.
What about using something like "warning bits" for mode? For example, mode=WarningMode.Get | WarningMode.Set means warnings will be raised when the field is accessed (calling getter) and updated (calling setter). I was thinking that maybe we can simplify the cases to fields being set and fields being accessed and include model instantiation in the former, but this is possibly not enough for the client library case where warnings can be ignored at instantiation but should definitely be raised afterwards, so we might need at least one additional bit, something like WarningMode.Create. Expressing mode in these bits gives users full flexibility in a rather easy to understand and relate way.


Rosetta PoS Support

Current dependencies on/for this PR:

main

PR #56   👈

PR #57

PR #58

This stack of pull requests is managed by Graphite.


Start new engine

Hi @davidecaroselli,
I recently completed the EN->FR engine. Engine position in:/MT-work/Corpus/en-US_fr-FR/Output,
I use the command: ./mmt start -e /MT-work/Corpus/en-US_fr-FR/Output. The order will be stuck in
“Starting MMT engine '/MT-work/Corpus/en-US_fr-FR/Output'...”.
But，i moved the engine to the MODERNMMT default directory. This command can be executed successfully.
So have you ever met a problem like this? Or is there a suggestion for me to try.
Thanks

@sdlmw thanks for having spotted this bug!


calculate feature without given protocal

Hi. I would like to use existing external packages (e.g, ta) to calculate features, so I no longer need to define formulas in the example given here. Is there anyway I can feed features using calculated numbers, instead of formulas?

You can query the raw data and then feed it into other packages.

You can query the raw data and then feed it into other packages.
Yes. The documentation already have example for extracting data from .bin files. The problem is how to feed the calculated numbers to be a feature in the dataset to be trained.

The dataset , datahandler, and dataloader layer didn't force user to create dataset from qlib's .bin files directly.
You can create your own dataloader for your data.
You can reference to https://github.com/microsoft/qlib/blob/main/qlib/data/dataset/loader.py#L183
It requires some modification to make it suit your requirements.

The dataset , datahandler, and dataloader layer didn't force user to create dataset from qlib's .bin files directly.
You can create your own dataloader for your data.
You can reference to https://github.com/microsoft/qlib/blob/main/qlib/data/dataset/loader.py#L183
It requires some modification to make it suit your requirements.

Thank you. Is there any way to append these data to existing data loaded from .bin files?

Sorry,
In our current workflow, users have to start from loading data from dataloader to get latest data..
Updating the data in the memroy will consider a lot of things,  such as preprocessing,  different version of data (raw data, data for inference , data for learning).  So we think that the most convient solution to get new data is starting from loading original data.
Do you have suggestions about current design?
Thanks.


Add backlink to rancher.com to header

Per feedback from the web team, we should have a link back to https://www.rancher.com for branding/SEO purposes similar to what Rancher Manager has done. The link's label should be "Rancher Home".

Ref: https://github.com/epinio/docs/blob/main/docusaurus.config.js#L59-L85


extract "find .ruby-version and return its value" to private method

Do you feel something for extracting "finding .ruby-version and reading its content" into a separate function like __ruby_version_content, and using that in the public chruby_auto function?
There is only the minor upside to chruby in that it creates a better separation of concern in auto.sh (which currently is basically one big public function), but it does create a more friendly "api" where other implementations can use this function to get the content of a ruby-version file without reimplementing the functionality.
This request stems from the remark: https://github.com/JeanMertz/chruby-fish/issues/9#issuecomment-42643013, and my conclusion: https://github.com/JeanMertz/chruby-fish/issues/9#issuecomment-42644497.
Of course, it's not a very useful change for chruby, and I doubt many others will use it, but it never hurts to ask, and I feel like it could increase the readability of the source code for chruby as well.

I finally got around to this in ccae75a26017bfdb2e4ef499c8a6ed5aea00db38.

@postmodern any reason that specific commit was never merged? I wanted to make use of it right now, but turns out it never made it into master, which is a pity.


migrate test-infra to testify for cdc/sink/dispatcher pkg

closed by https://github.com/pingcap/tiflow/pull/5386


Heartbeat failed

Since the new release I've been experiencing a lot of error messages with the component.
Logger: custom_components.remote_homeassistant
Source: custom_components/remote_homeassistant/__init__.py:458
Integration: Remote Home-Assistant (documentation)
First occurred: 17:06:19 (111 occurrences)
Last logged: 21:26:35

heartbeat failed

Any advise what to do ?

How often does it happen? What versions of Home Assistant are you using? Are they on the same network?

@postlund As you can see I have restarted my machine at 5 PM and since then I got 111 occurrences. I have the latest release installed, version 2020.12.6. Both machines are on the same network.

Today I got another error message which I never got previously.
`Logger: custom_components.hacs
Source: custom_components/hacs/operational/factory.py:37
Integration: HACS (documentation, issues)
First occurred: 12:08:34 (2 occurrences)
Last logged: 12:08:34
lukas-hetzenecker/home-assistant-remote - GitHub Ratelimit error
hacs/integration - GitHub Ratelimit error`

@Jens-Wymeersch Can you enable debug logs so we can see if anything is interesting comes from there? Don't need to see everything, just around the time of the exception (include a bit before it happens).
logger:
  default: error
  logs:
    custom_components.remote_homeassistant: debug

The other exception is from HACS, which makes to many GitHub calls. Not related to us.

Here you go : https://paste.ubuntu.com/p/v8BbdB6BYs/

Can you include a few lines above the error message as well, so I can see what's going on?

From N= 51 to 2
2020-12-16 13:32:01 DEBUG (MainThread) [custom_components.remote_homeassistant] received: {'id': N, 'type': 'pong'}
2020-12-16 13:32:01 DEBUG (MainThread) [custom_components.remote_homeassistant] Got pong: {'id': N, 'type': 'pong'}

With every heartbeat failure it creates a problem with https://www.home-assistant.io/integrations/person/  integration of the owner somehow

I'm not sure why this would fail to be honest. The log has expired, can you upload another one? I would like to look a bit at the response times. Maybe I should increase the timeout and maybe make another retry before failing.

Pierre,
Thank you you for all your help. I decided to delete and reinstall HACS and the CC to see if this would do the trip. I expected a better outcome as the heartbeat errors remain which is obviously a disappointment.
https://paste.ubuntu.com/p/KZm28GvkD3/
Regards,
Jens

@Jens-Wymeersch Thanks for the log! In the first case I don't see any response at all to thing ping, which explains why the heartbeat fails. In the second failure, the response is received just after the timeout time so even if it was received, the timeout happens and you get a heartbeat failure.
2020-12-22 16:50:12 DEBUG (MainThread) [custom_components.remote_homeassistant] Sending ping
2020-12-22 16:50:17 DEBUG (MainThread) [custom_components.remote_homeassistant] received: {'id': 60, 'type': 'pong'}
2020-12-22 16:50:17 DEBUG (MainThread) [custom_components.remote_homeassistant] Got pong: {'id': 60, 'type': 'pong'}
2020-12-22 16:50:17 ERROR (MainThread) [custom_components.remote_homeassistant] heartbeat failed

Timeout is currently five seconds to make that clear. It should be more than enough, but I can double that to 10s and add that two heartbeats need to fail in order to trigger a re-connect. Hopefully that will help, assuming the connection is really working as intended. I do however suspect that your remote instance isn't doing quite well if it sometimes take more than five seconds to respond. Do you see any other errors in the log, like the "took longer than X to update"?

Hi Pierre, just to give you a bit of context. I have 6 A/Cs that need to be connected to HA via a Custom Component. This one almost breaks HA. Hence putting it in a separate HA instance.
I now killed the instance and set it back up in a new Proxmox VM. For the moment, this seems to help. Lets see by tomorrow !

Talked to soon :
2020-12-22 21:47:09 ERROR (MainThread) [custom_components.remote_homeassistant] heartbeat failed 2020-12-22 21:47:09 DEBUG (MainThread) [custom_components.remote_homeassistant] websocket connection is closing 2020-12-22 21:47:10 INFO (MainThread) [custom_components.remote_homeassistant] Connecting to ws://<IP_ADDRESS>:8123/api/websocket 2020-12-22 21:47:10 INFO (MainThread) [custom_components.remote_homeassistant] Connected to home-assistant websocket at ws://XX.YY.ZZ.UU:8123/api/websocket

Ok, that would be the reason for this. Home Assistant becomes unresponsive and fails to respond. I kinda want to say that this is what should happen in that case. What component are you using for your A/Cs? Maybe it can be improved?

Hi Pierre,
I'm using this component : https://github.com/atxbyea/samsungrac
This is a fork from someone else. I talked to the owner a few times but in most cases, the folks using this component don't have as many A/Cs as we do. Hence they don't have performance problems...
One of the folks was building a component based on MQTT but then basically stopped with it. Tried to convince him multiple times but got a firm No, a week ago.
But the thing is, that I'm using the remote UI now for a while and never had these issues (or maybe didn't notice it - that might also be the case).

Are you using the platform in polling mode (poll: true)? As that implementation is broken. It has a built-in "update delay" defines as 1.5s and uses synchronous sleep (time.sleep) instead of the async version (asyncio.sleep). This means that when an update is performed (every 15s), it will start by blocking the entire event loop so that nothing (and I mean nothing) will run before updating. Since you have 6 A/Cs it summarizes to 6*1.5=9s, which means that your Home Assistant is blocked for 60% of the time. But yeah, only if you run in polling mode. I haven't looked at non-polling yet.

I responded in your issue as well.

I wasn't aware of this issue with the polling. But the component has always been quite heavy on HA. I hope that someone will actually go through the code totally and clean it up.

Profiling is probably needed, but you could try my suggested change and see if it improves your situation here.

I just change the code ? As you describe in https://github.com/atxbyea/samsungrac/issues/5

Yep!

By the way, even without the polling line - I still get the error message 2020-12-23 00:27:41 ERROR (MainThread) [custom_components.remote_homeassistant] heartbeat failed

Regarding the code change
in your opinion, I need to change line 259 by

The device config for your device says to use poll so I think that will be default anyway:
https://github.com/atxbyea/samsungrac/blob/0e4ffd9f7111243d92d531439b2efca07f95fa9f/custom_components/climate_ip/samsung_2878.yaml#L3
Yes, you should replace the existing async_update method with that code.

I've added the poll again and changed the code as you indicated. Looks like it is still working. Now the next question is if we need 15 seconds ? Can it be lower with the change ?

Hopefully it will work a lot better. You should probably notice that the UI works a lot snappier than before (if you try to use that) as it doesn't get locked up now.
It can probably be lowered but it's a balance between strain on the system and how often it updates. Since you don't run anything else on that system, it probably doesn't matter from performance perspective. But some devices tend to handle many requests poorly though. Unless you see problems with current update rate, I would leave it as-is.

Well it is sometimes a bit annoying to push a button and see that it only updates seconds later. If I would like to change it, what should I look for ?

Right. Ultimately Home Assistant would trigger an update after doing something that changes remote state, but there's no logic for that (Home Assistant doesn't know which methods that potentially update state). Best workaround is to implement polling in the protocol library (as that knows when such a method is called) and provide a state update to a callback. That way all devices appear to provide push updates, yielding the result you desire.
You can just add scan_interval: X to the config as it's a built in feature. X is seconds.

Based on what you wrote, it's unclear if reducing the scan interval will sort my problem. Can you confirm ? And if you were me, you would leave as is ?

I had to take a look at the code again and it seems to be appropriately written to trigger an update after changing something. Now I understand that the problematic sleep mentioned earlier is a cool off time used to wait for the device to update its state. So it basically goes:

You press a button to change "something"
Request is sent to device to update "something"
An update is scheduled to update the state again
Before an update is performed, a sleep is made for 1,5s
State is updated

So, if you are not seeing updates to the state within let's say 2s, then it takes much longer for the device to change state and make it available via the API. Changing the scan interval won't make any difference here. If the delay is around 2s from changing something to state is updated, then it's because of this delay. I'm not sure how long it has to be (or if it's even needed), but you can experiment with update_delay in the config. Try disabling it (update_interval: 0) and see if it works. Otherwise try like 1 and increase/decrease depending on result.

Hi Pierre,
You won't believe it but now another problem appears and don't know why. The state is current in the slave but isn't changed in the primary somehow.
So I can't control the A/Cs via the primary but it doesn't update the state. Any ideas why ?

That said, what you have done allowed me to integrate the A/Cs directly in my primary and eliminating to have a slave HA running. Thank you so much,
Jens

I was almost expecting that outcome 😉 Did you see anything at all in the log on master instance that seemed suspect when state changes didn't come? Which version are you running by the way and have you specified subscribed _events in your config?

I'm at the latest release of Home Assistant. Moved HA around from RPI to Virtual Box and landed with ProxMox. No i didn't see any errors in the logs.
At some point I subscribed to some events because I had defined the same user in both slave and primary which resulted in conflict.

Sorry about the confusion, I meant version of the component. If you are using the latest released version, you need to make sure you have state_changed in subscribed_events if you have that in your config. Otherwise you will see no updates. This is no longer needed if you run from master in git. No release out with that fix yet.

I was using HACS and the latest version of the component. Liked that I could install via the integration UI

Yeah, that's the good thing with HACS. But still, make sure you add state_changed and hopefully it should work.

Hi Pierre,
For the moment, just killed the component as I only used it for this HVAC use case. I'll keep this in mind.
YOU ARE AMAZING TO FIX THE HVAC component... I was waiting for this for half a year !

Ok, we'll leave it at that. If you ever encounter it again (if you decide to use the component), just open a new issue 👍
No worries! I hope they merge the fix soon so you don't have to make changes yourself.

Good afternoon I had a similar problem. The log also says heartbeat failed.
Two copies are located on two different networks, connected via VPN. Each one has a remote server and a client, i.e. HA-1 takes part of the data from HA-2 and at the same time gives it part of its data.
The problem appeared only on HA-1 - data does not arrive from HA-2, at the same time there are no problems on HA-2 - data from HA-1 arrives and even remote devices are controlled normally

2024-03-07 06:35:03.519 DEBUG (MainThread) [custom_components.remote_homeassistant] Sending ping 2024-03-07 06:35:08.521 ERROR (MainThread) [custom_components.remote_homeassistant] heartbeat failed 2024-03-07 06:35:08.521 DEBUG (MainThread) [custom_components.remote_homeassistant] websocket connection is closing 2024-03-07 06:35:08.699 INFO (MainThread) [custom_components.remote_homeassistant] Connecting to ws://<IP_ADDRESS>:8123/api/websocket 2024-03-07 06:35:08.794 INFO (MainThread) [custom_components.remote_homeassistant] Connected to home-assistant websocket at ws://<IP_ADDRESS>:8123/api/websocket 2024-03-07 06:35:09.250 DEBUG (MainThread) [custom_components.remote_homeassistant] received: {'type': 'auth_required', 'ha_version': '2024.2.5'} 2024-03-07 06:35:09.344 DEBUG (MainThread) [custom_components.remote_homeassistant] received: {'type': 'auth_ok', 'ha_version': '2024.2.5'} 2024-03-07 06:35:09.425 DEBUG (MainThread) [custom_components.remote_homeassistant] received: {'id': 5, 'type': 'result', 'success': True, 'result': None} 2024-03-07 06:35:28.795 DEBUG (MainThread) [custom_components.remote_homeassistant] Sending ping 2024-03-07 06:35:33.795 ERROR (MainThread) [custom_components.remote_homeassistant] heartbeat failed 2024-03-07 06:35:33.796 DEBUG (MainThread) [custom_components.remote_homeassistant] websocket connection is closing 2024-03-07 06:35:33.986 INFO (MainThread) [custom_components.remote_homeassistant] Connecting to ws://<IP_ADDRESS>:8123/api/websocket 2024-03-07 06:35:34.087 INFO (MainThread) [custom_components.remote_homeassistant] Connected to home-assistant websocket at ws://<IP_ADDRESS>:8123/api/websocket 2024-03-07 06:35:34.087 DEBUG (MainThread) [custom_components.remote_homeassistant] received: {'type': 'auth_required', 'ha_version': '2024.2.5'} 2024-03-07 06:35:34.175 DEBUG (MainThread) [custom_components.remote_homeassistant] received: {'type': 'auth_ok', 'ha_version': '2024.2.5'} 2024-03-07 06:35:34.275 DEBUG (MainThread) [custom_components.remote_homeassistant] received: {'id': 9, 'type': 'result', 'success': True, 'result': None} 2024-03-07 06:35:34.561 ERROR (MainThread) [homeassistant.components.mqtt.select] Invalid option for select.0x5c0272fffec955d8_power_on_behavior: '' (valid options: ['off', 'previous', 'on']) 2024-03-07 06:35:54.088 DEBUG (MainThread) [custom_components.remote_homeassistant] Sending ping 2024-03-07 06:35:59.089 ERROR (MainThread) [custom_components.remote_homeassistant] heartbeat failed 2024-03-07 06:35:59.089 DEBUG (MainThread) [custom_components.remote_homeassistant] websocket connection is closing 2024-03-07 06:35:59.255 INFO (MainThread) [custom_components.remote_homeassistant] Connecting to ws://<IP_ADDRESS>:8123/api/websocket 2024-03-07 06:35:59.336 INFO (MainThread) [custom_components.remote_homeassistant] Connected to home-assistant websocket at ws://<IP_ADDRESS>:8123/api/websocket 2024-03-07 06:35:59.337 DEBUG (MainThread) [custom_components.remote_homeassistant] received: {'type': 'auth_required', 'ha_version': '2024.2.5'} 2024-03-07 06:35:59.426 DEBUG (MainThread) [custom_components.remote_homeassistant] received: {'type': 'auth_ok', 'ha_version': '2024.2.5'} 2024-03-07 06:35:59.504 DEBUG (MainThread) [custom_components.remote_homeassistant] received: {'id': 13, 'type': 'result', 'success': True, 'result': None} 2024-03-07 06:36:19.338 DEBUG (MainThread) [custom_components.remote_homeassistant] Sending ping 2024-03-07 06:36:24.339 ERROR (MainThread) [custom_components.remote_homeassistant] heartbeat failed 2024-03-07 06:36:24.339 DEBUG (MainThread) [custom_components.remote_homeassistant] websocket connection is closing 2024-03-07 06:36:24.530 INFO (MainThread) [custom_components.remote_homeassistant] Connecting to ws://<IP_ADDRESS>:8123/api/websocket 2024-03-07 06:36:24.625 INFO (MainThread) [custom_components.remote_homeassistant] Connected to home-assistant websocket at ws://<IP_ADDRESS>:8123/api/websocket 2024-03-07 06:36:24.625 DEBUG (MainThread) [custom_components.remote_homeassistant] received: {'type': 'auth_required', 'ha_version': '2024.2.5'} 2024-03-07 06:36:24.775 DEBUG (MainThread) [custom_components.remote_homeassistant] received: {'type': 'auth_ok', 'ha_version': '2024.2.5'} 2024-03-07 06:36:24.855 DEBUG (MainThread) [custom_components.remote_homeassistant] received: {'id': 17, 'type': 'result', 'success': True, 'result': None} 2024-03-07 06:36:44.627 DEBUG (MainThread) [custom_components.remote_homeassistant] Sending ping 2024-03-07 06:36:49.628 ERROR (MainThread) [custom_components.remote_homeassistant] heartbeat failed 2024-03-07 06:36:49.628 DEBUG (MainThread) [custom_components.remote_homeassistant] websocket connection is closing 2024-03-07 06:36:49.832 INFO (MainThread) [custom_components.remote_homeassistant] Connecting to ws://<IP_ADDRESS>:8123/api/websocket 2024-03-07 06:36:49.916 INFO (MainThread) [custom_components.remote_homeassistant] Connected to home-assistant websocket at ws://<IP_ADDRESS>:8123/api/websocket 2024-03-07 06:36:49.916 DEBUG (MainThread) [custom_components.remote_homeassistant] received: {'type': 'auth_required', 'ha_version': '2024.2.5'} 2024-03-07 06:36:50.006 DEBUG (MainThread) [custom_components.remote_homeassistant] received: {'type': 'auth_ok', 'ha_version': '2024.2.5'} 2024-03-07 06:36:50.114 DEBUG (MainThread) [custom_components.remote_homeassistant] received: {'id': 21, 'type': 'result', 'success': True, 'result': None} 2024-03-07 06:37:09.918 DEBUG (MainThread) [custom_components.remote_homeassistant] Sending ping 2024-03-07 06:37:14.919 ERROR (MainThread) [custom_components.remote_homeassistant] heartbeat failed 2024-03-07 06:37:14.919 DEBUG (MainThread) [custom_components.remote_homeassistant] websocket connection is closing 2024-03-07 06:37:16.236 INFO (MainThread) [custom_components.remote_homeassistant] Connecting to ws://<IP_ADDRESS>:8123/api/websocket 2024-03-07 06:37:16.326 INFO (MainThread) [custom_components.remote_homeassistant] Connected to home-assistant websocket at ws://<IP_ADDRESS>:8123/api/websocket 2024-03-07 06:37:16.327 DEBUG (MainThread) [custom_components.remote_homeassistant] received: {'type': 'auth_required', 'ha_version': '2024.2.5'} 2024-03-07 06:37:16.458 DEBUG (MainThread) [custom_components.remote_homeassistant] received: {'type': 'auth_ok', 'ha_version': '2024.2.5'} 2024-03-07 06:37:16.690 DEBUG (MainThread) [custom_components.remote_homeassistant] received: {'id': 25, 'type': 'result', 'success': True, 'result': None} 2024-03-07 06:37:36.328 DEBUG (MainThread) [custom_components.remote_homeassistant] Sending ping 2024-03-07 06:37:41.329 ERROR (MainThread) [custom_components.remote_homeassistant] heartbeat failed 2024-03-07 06:37:41.329 DEBUG (MainThread) [custom_components.remote_homeassistant] websocket connection is closing 2024-03-07 06:37:41.505 INFO (MainThread) [custom_components.remote_homeassistant] Connecting to ws://<IP_ADDRESS>:8123/api/websocket 2024-03-07 06:37:41.596 INFO (MainThread) [custom_components.remote_homeassistant] Connected to home-assistant websocket at ws://<IP_ADDRESS>:8123/api/websocket 2024-03-07 06:37:41.596 DEBUG (MainThread) [custom_components.remote_homeassistant] received: {'type': 'auth_required', 'ha_version': '2024.2.5'} 2024-03-07 06:37:41.677 DEBUG (MainThread) [custom_components.remote_homeassistant] received: {'type': 'auth_ok', 'ha_version': '2024.2.5'} 2024-03-07 06:37:41.765 DEBUG (MainThread) [custom_components.remote_homeassistant] received: {'id': 29, 'type': 'result', 'success': True, 'result': None}

I conducted another experiment - added the remote home assistant add-on on the NA-3 instance (also in a different subnet, also VPN access). The connection HA-1 + HA-3 works, the connection HA-3 - HA-2 also does not work. Conclusion - there is some problem in the HA-2.
There the server is in a rather bad channel, but there were no problems before. Data from HA-2 used to be lost. But then it either recovered on its own, or restarting the add-on helped.
At the moment the channel is relatively good:
Speedtest:
Download: 8.95 Mbit/s
Upload: 1.14 Mbit/s
21% ICMP loss with packet size 1024 bytes
@postlund Can you please tell me which direction I should look?


Clear Backup CR Reconciling condition when backup completes

What kind of request is this (question/bug/enhancement/feature request): bug
Steps to reproduce (least amount of steps as possible):

Create a Backup CR, by specifying the an incorrect credential in S3 spec. (credential does NOT exist in rancher setup yet)
The status of the CR is "Error"
Now create a credential in rancher setup.
Backup happens.
But the state of the backup shows "Error"
View in YAML of the backup CR status is:

status:
  conditions:
  - lastUpdateTime: "2020-08-29T20:39:44Z"
    message: secrets "creds2" not found
    reason: Error
    status: "False"
    type: Reconciling
  - lastUpdateTime: "2020-08-29T20:39:46Z"
    status: "True"
    type: Uploaded

Expected Result:
Backup should be seen in "Active" state
Other details that may be helpful:
Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI): master-head - commit id: 8d9cedde93
Installation option (single install/HA): HA rke

State of the backup is not "Error", it's showing the reason for the "Reconciling" condition. Whereas the "Uploaded" condition is true and Backup won't have an "Active" state

Verified on master-head commit id: c428bc9feb with backup-restore operator tag: v0.0.1-rc7

Create a Backup CR, by specifying the an incorrect credential in S3 spec. (credential does NOT exist in rancher setup yet)
The status of the CR is "Error"
Now create a credential in rancher setup.
Backup happens successfully and the backup is in Active state.


Error 502 for Nigeria and Mali

I have noticed that for nigeria & mali this query e.g https://healthsites.io/api/v1/healthsites/search?search_type=placename&format=csv&name=nigeria
more often returns a 502 error
I have also tried with the iso3 in place of the whole country name and get results ( excepts for nigeria and mali ).

The right url is (note the format=geojson) : https://healthsites.io/api/v1/healthsites/search?search_type=placename&format=geojson&name=nigeria
It has returned results for the 2 countries one time, after that nothing but bad gateway Error 502.

fix by : https://github.com/healthsites/healthsites/releases/tag/version-1_9_5


Allow specifying extra options for the various backup commands

So I need to add the option --default-character-set=utf8mb4 to the mysqldump command but others will not want this option. It would be awesome if I could specify custom options for the backup commands.
The reason I need this is described in the Nextcloud docs (backups wont work for utf8mb4 unless specified on the dump command):
https://docs.nextcloud.com/server/stable/admin_manual/configuration_database/mysql_4byte_support.html#mariadb-support
Thanks!

Interesting - I haven't seen those types of issues when restoring to Nextcloud. Am a very heavy user- but I agree, some additional arguments would be useful. Give me a few days to finish off an update to all of the images and I can easily integrate this.


gsagh-168 clear cache when new guid model

Codecov Report

Merging #252 (8e488cd) into main (9a268ee) will decrease coverage by 0.00%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main     #252      +/-   ##
==========================================
- Coverage   55.37%   55.37%   -0.01%
==========================================
  Files         227      227
  Lines       27414    27416       +2
==========================================
  Hits        15181    15181
- Misses      12233    12235       +2

Flag
Coverage Δ

gsagh
42.57% <0.00%> (-0.01%)
:arrow_down:

integration
42.76% <0.00%> (-0.01%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

GsaGH/Components/5_Results/SelectResults.cs
61.99% <0.00%> (-0.57%)
:arrow_down:

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


Minor: Http2SolrClient cleanups

Just a few small matters; no material changes.

I'll merge this in a couple days if I don't hear anything back.
CC @jdyer1


Version 0.0.6 version bump & changelog update

v0.0.6 - 2024-01-30 - Known your zones

ZoneFileProvider assumes zone files don't exist when used as a
target. This avoids the need to --force root NS changes when
re-writing files.
Fix list_zones behavior with file_extension=''

/cc https://pypi.org/project/octodns-bind/0.0.6/