Add a Prometheus metric for current HVAC action

Proposed change

Add a Prometheus metric that indicates current HVAC action (heating, cooling, idle, etc).
Example output:
# HELP action Current HVAC action ({'off': 0, 'heating': 1, 'cooling': 2, 'drying': 3, 'idle': 4, 'fan': 5})
# TYPE action gauge
action{domain="climate",entity="climate.guest_room",friendly_name="Guest Room"} 1.0
action{domain="climate",entity="climate.bedroom",friendly_name="Bedroom"} 1.0
action{domain="climate",entity="climate.bathroom",friendly_name="Bathroom"} 1.0
action{domain="climate",entity="climate.ensuite",friendly_name="Ensuite"} 4.0
action{domain="climate",entity="climate.living_room",friendly_name="Living Room"} 1.0

Type of change

[ ] Dependency upgrade
[ ] Bugfix (non-breaking change which fixes an issue)
[ ] New integration (thank you!)
[x] New feature (which adds functionality to an existing integration)
[ ] Breaking change (fix/feature causing existing functionality to break)
[ ] Code quality improvements to existing code or addition of tests

Additional information

This PR fixes or closes issue: fixes #
This PR is related to issue:
Link to documentation pull request:

Checklist

[x] The code change is tested and works locally.
[ ] Local tests pass. Your PR cannot be merged unless tests pass
[x] There is no commented out code in this PR.
[x] I have followed the development checklist
[x] The code has been formatted using Black (black --fast homeassistant tests)
[ ] Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

[ ] Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

[ ] The manifest file has all fields filled out correctly.
Updated and included derived files by running: python3 -m script.hassfest.
[ ] New or updated dependencies have been added to requirements_all.txt.
Updated by running python3 -m script.gen_requirements_all.
[ ] Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

[ ] No score or internal
[ ] 🥈 Silver
[ ] 🥇 Gold
[ ] 🏆 Platinum

Hi @knyar,
It seems you haven't yet signed a CLA. Please do so here.
Once you do that we will be able to review and accept this pull request.
Thanks!

What do I need to do to get this merged?

The proposal in https://github.com/home-assistant/core/pull/31945/files#r380970673 is what is used for systemd unit state and it works pretty well. I would go that route.
I'm not happy about the metric name. Neither action nor current_action (current is just wrong in a metrics name) is properly namespaced. If it it is part of a climate state shouldn't it be climate_action?
In fact, why call it action at all? In homeassistant/components/climate/const.py it's called HVAC_MODES. So maybe climate_mode?
# Only the fan is on, not fan and another mode like cool
HVAC_MODE_FAN_ONLY = "fan_only"

HVAC_MODES = [
    HVAC_MODE_OFF,
    HVAC_MODE_HEAT,
    HVAC_MODE_COOL,
    HVAC_MODE_HEAT_COOL,
    HVAC_MODE_AUTO,
    HVAC_MODE_DRY,
    HVAC_MODE_FAN_ONLY,
]

Thanks for your comments, @mweinelt! I just wanted to confirm: are you one of the maintainers of this repo and would be able to approve and merge this PR?

The proposal in https://github.com/home-assistant/core/pull/31945/files#r380970673 is what is used for systemd unit state and it works pretty well. I would go that route.

I believe that's exactly how it's implemented (following @balloob's comments from Feb). I've adjusted the PR description as well.

I'm not happy about the metric name. Neither action nor current_action (current is just wrong in a metrics name) is properly namespaced. If it it is part of a climate state shouldn't it be climate_action?

I don't feel strongly about the name. I chose current_action to be consistent with other metric names (for example, current_temperature_c). I am not sure climate needs to be part of the metric name, since there are domain and entity labels that make it clear this is climate-specific (for example, domain="climate",entity="climate.bedroom").
Would you be happy with the metric just being called action?

In fact, why call it action at all? In homeassistant/components/climate/const.py it's called HVAC_MODES. So maybe climate_mode?

You would notice that "HVAC mode" (ATTR_HVAC_MODE) is different from "HVAC action" (ATTR_HVAC_ACTION). This metric is designed to track "HVAC action".

Thanks for your comments, @mweinelt! I just wanted to confirm: are you one of the maintainers of this repo and would be able to approve and merge this PR?

No, I'm just another contributor trying to submit changes to the prometheus module. A maintainer asked me to review this commit. See https://github.com/home-assistant/core/pull/35216.

The proposal in https://github.com/home-assistant/core/pull/31945/files#r380970673 is what is used for systemd unit state and it works pretty well. I would go that route.

I believe that's exactly how it's implemented (following @balloob's comments from Feb). I've adjusted the PR description as well.

I'm not happy about the metric name. Neither action nor current_action (current is just wrong in a metrics name) is properly namespaced. If it it is part of a climate state shouldn't it be climate_action?

I don't feel strongly about the name. I chose current_action to be consistent with other metric names (for example, current_temperature_c).

Then the other metrics should be fixed up as well, because current is a function that can be applied to a metric. The metric has history, it can't be current.

I am not sure climate needs to be part of the metric name, since there are domain and entity labels that make it clear this is climate-specific (for example, domain="climate",entity="climate.bedroom").

I've skimmed the prometheus component and the climate handler is the only obvious oddball not namespacing the metric and using the current_ prefix. This should be fixed.

Would you be happy with the metric just being called action?

In fact, why call it action at all? In homeassistant/components/climate/const.py it's called HVAC_MODES. So maybe climate_mode?

You would notice that "HVAC mode" (ATTR_HVAC_MODE) is different from "HVAC action" (ATTR_HVAC_ACTION). This metric is designed to track "HVAC action".

Wouldn't action just be the intended state, while mode represents the actual state?
You seem to have pushed unrelated commits into this branch now.

hvac_mode is what the user has set the climate device to, eg auto, heat, cool, while hvac_action is what the device is doing at any one time, eg heating, idle, cooling.

Then the other metrics should be fixed up as well, because current is a function that can be applied to a metric. The metric has history, it can't be current.

Sounds good. I am happy to work with you on fixing existing metric names, but I don't think it should be part of this PR.

I know this might be redundant wrt labels, but those labels have a low cardinality anyway.

I've renamed the metric to climate_action.

Wouldn't action just be the intended state, while mode represents the actual state?

Reading https://github.com/home-assistant/architecture/issues/22, I believe it's the other way around: 'mode' represents configuration (user intent), while 'action' is what's happening right now.

You seem to have pushed unrelated commits into this branch now.

Oh sorry, I rebased this against master instead of dev by mistake. Fixed now.

LGTM. Can you still check why the CI checks are failing?

One of the failures was caused by a formatting check, and I've adjusted the code to conform.
azure-pipelines tests are still failing, but they seem to be doing that consistently, so I don't think the failures are related to this change.

The plex test is unrelated to this PR and has been fixed on the dev branch.

@knyar as I mentioned to @mweinelt it would be good if the prometheus integration contributors can band together and discuss the current state of the integration and what changes you would like to do and document this in an architecture issue. The core team can help advice on home assistant best practices if there are questions about that.
Another way of helping moving this integration forward is to become a codeowner. We welcome contributors that volunteer for this role. Codeowners will get mentioned on issues tagged with the integration label and on PRs for the integration. It's good if there are multiple codeowners per integration to spread the workload and the codeowners can then review each other PRs too.

Thanks for merging this, @MartinHjelmare.
I am happy to be one of the codeowners. I don't have any other perssing changes I'd like to make, but I've started a discussion about plans in https://github.com/home-assistant/architecture/issues/391

Please make a PR adding yourself as codeowner to the manifest.json file. Run python3 -m script.hassfest to update the codeowners file.


where is the "cleaned.csv"

You need to run load_data.py in order to generate this file. It's referenced as aspect_terms_path which is defined in project.cfg.

Updated readme with instructions on using load_data.py


[HIGH] Problems_OneProblem_Problem

Acces to the workitem (go to ....)

[ ] Add functionality in ARA
[ ] Add NRT

Delete the problem (Delete the problem)

[ ] Add functionality in ARA
[ ] Add NRT

Edit the problem properties (Save)

[ ] Add functionality in ARA
[ ] Add NRT

Close the problem (Assign Root Cause & Close problem)

[ ] Add functionality in ARA
[ ] Add NRT

Refresh status from workitem now

[ ] Add functionality in ARA
[ ] Add NRT

Open actions menu

[ ] Add functionality in ARA
[ ] Add NRT

Moved to another project


Possibility for prepaid charges

Hi,
Would it be possible to add a "virtual" payment method like prepaid. So we could somehow specify, that if the user has balance, the user does not need to have a mandate etc.
Or better, the ability, to tell mollie that this subscription should be handled as a prepaid until further notice.
If @sandervanhooft could just write if this would be a feature that would be ok to implement, I would be willing to create this feature. This would also include a better way to handle balance, eg. ma built in method for buying charge.
The background is, that most of our customers are private and are more likely to use prepaid.
A small sketch on how I imagine this:
Now:
Create subscription:
-> either mandated or first
Then:
Create subscription
-> wither normal way or prepaid
-> prepaid by either specifying this as a payment method or, by having a separate function.
-> after x time before next cycle, a event would be fired to remind the user to extend the subscription; But the user should also be able to switch to a normal subscription.
-> buyiing balance through a similar way how charges work
thanks

Hi @GunniBusch ,
I think many of the elements you're looking for are already available.
If you implement a way to (periodically) top up the billable's balance, Cashier will use the existing balance to pay for renewals automatically and only charge the customer for the remainder.
What else would you need from this package to succeed?

I.e. you could create a Mollie payment manually and then register the balance here:
https://github.com/mollie/laravel-cashier-mollie/blob/ff8a0b82fd98a50549f63a8a362ffae085aa4394/src/Credit/Credit.php#L24

Thanks I will look into it and inform you about the status!


Snackbars can be auto-hid.

Addresses #958.
If a duration is set and the snackbar is dismissed by means other than the timer, the timer will be cleared so that a second dismiss call is not made.

@jkruder Just found a small issue with the text-field. When you hit backspace, the parseInt fails.

@hai-cea Good catch, fixed.

Thanks @jkruder !


Add utility functions to easily extract values from metadata

Codecov Report
Attention: Patch coverage is 0% with 35 lines in your changes missing coverage. Please review.

Project coverage is 0.44%. Comparing base (5cd0186) to head (f15059d).

Files with missing lines
Patch %
Lines

src/userutils.jl
0.00%
35 Missing :warning:

Additional details and impacted files
@@           Coverage Diff            @@
##            main      #3      +/-   ##
========================================
- Coverage   0.52%   0.44%   -0.09%
========================================
  Files          5       6       +1
  Lines        191     226      +35
========================================
  Hits           1       1
- Misses       190     225      +35

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Where are v2 docs - I'd like to help improve...

I see a few broken links and I'd like to help improve. Where do these exist?
http://ionicframework.com/docs/v2/api/components/modal/Modal/

Ahh thanks for the reminded. We just moved over v2 to here, so we haven't had a chance to update the site. Will take care of

Fixed via https://github.com/driftyco/ionic/commit/3e5a36a15f1f2f3b27e4228d388bfdb1f69d8a9f but we're still adjusting our build process to generate the new docs. Could be a day or two.

Perfect, thanks!


Simplify cmake build by providing hints on how to install dependencies

Check whether all the necessary dependencies are installed, if not notify the user accordingly.
Also, display how to install the respective packages in DEB/RPM environments.
The absolutely required dependencies libuuid and libjsonc if not found will throw a fatal error in the end with details on how to install them.
Other dependencies like Python which are only required for certain tools will give out messages that they are not present and the respective components will not function.
Basic dependencies like C/C++ compiler will throw out messages on how to install them and CMake will leave the configuration incomplete automatically.

I tried to remove compiler_config.cmake from the commits but the issues is I had edited the file in a commit and then removed the edited code in a later commit. Hence the file shows up.

So some files show up in this PR but there seem to be no real diffs.  Is it because these were opened from Windows? Are the deltas carriage returns?

@r-rojo yes, that is the case for two of the files. Do you know how I can fix them? I thought of rebasing but it will not solve this issue.
When I checked out the files, they got converted to CRLF on windows and that is the reason they were overwritten by a merge from master.

At the very least, you can remove the files that are really unmodified from the change. About the other files, you can probably run dos2unix on them to remove the line endings. You may also want to change your editor preferences on Windows to use unix style line endings so this doesn't happen again in the future.


#139 graph is Map<T, Set>

As per #139

@rultor merge

@rultor merge

@vssekorin OK, I'll try to merge now. You can check the progress of the merge here

@rultor merge

@vssekorin Done! FYI, the full log is here (took me 9min)


Code updates on comments

Updated e2e tests *Still fixing tbColumnDateTimeFilter non-HTML5 functionality issues
Added a tbForm test
Code for HTML5 datepicker substitute is pending to complete and clean

Coverage remained the same at 97.753% when pulling 8452b0338ca58e633ab2cb023bce80edb9573f5d on roberttapia:master into 677d147c6767eaee30d05604b69fdf95b860f122 on unosquare:master.

Coverage remained the same at 97.753% when pulling e5c71e48a9ef54ff4f6bbb8b7e792c749ab4481d on roberttapia:master into 677d147c6767eaee30d05604b69fdf95b860f122 on unosquare:master.

Please fix Travis.yml before.


Improve UI for adding members to new stream

We currently have two very different UIs for adding members to streams -- one for new streams, and one for existing streams. The UI for new streams presently has a bug (#20356), is not very polished (#20357), and is difficult to use in an organization with a large number of users. Moreover, this is a part of the app that users encounter early on, so polish is especially important.
To improve the UI for adding users to new streams, we should Copy the "Add subscribers" UI (screenshot below) with the following changes:

Have the user table get live-updated as you add/remove pills.
Rename the buttons "Unsubscribe" -> "Remove".
Make the input box 2 lines tall to be more encouraging of adding a bunch of users.

Additionally, we should:

Rename "People to add" --> "Add subscribers".
Make that heading have the same font as the headings above.

CZO discussion thread

@zulipbot claim

@alya I have changes the Unsubscribe button to remove and changed the height of the input box.
Should we also change the height of the Add button ?

@zulipbot abandon

In progress

@showell may I know if you are still working on this?

Here are some edge cases that I think we should look at in the final version of the UI:

is it still easy to add everybody from the realm to a new stream?
is it easy to add all the users from a large stream like Verona but then remove Hamlet?
can I see the final list of participants easily?
if I accidentally add a wrong group of people, how do I back out?

still in progress (#21233)


Generated code is missing imports

https://github.com/Azure/azure-sdk-for-java/pull/2172
[ERROR] COMPILATION ERROR :  [INFO] ------------------------------------------------------------- [ERROR] /home/travis/build/Azure/azure-sdk-for-java/applicationinsights/resource-manager/v2015_05_01/src/main/java/com/microsoft/azure/management/applicationinsights/v2015_05_01/implementation/WorkItemConfigurationsInner.java:[337,50] cannot find symbol   symbol:   method items()   location: class com.microsoft.azure.management.applicationinsights.v2015_05_01.implementation.WorkItemConfigurationInner [ERROR] /home/travis/build/Azure/azure-sdk-for-java/applicationinsights/resource-manager/v2015_05_01/src/main/java/com/microsoft/azure/management/applicationinsights/v2015_05_01/implementation/ApplicationInsightsComponentFavoriteImpl.java:[37,75] cannot find symbol   symbol:   method id()   location: variable inner of type com.microsoft.azure.management.applicationinsights.v2015_05_01.implementation.ApplicationInsightsComponentFavoriteInner [ERROR] /home/travis/build/Azure/azure-sdk-for-java/applicationinsights/resource-manager/v2015_05_01/src/main/java/com/microsoft/azure/management/applicationinsights/v2015_05_01/implementation/ApplicationInsightsComponentFavoriteImpl.java:[38,70] cannot find symbol   symbol:   method id()   location: variable inner of type com.microsoft.azure.management.applicationinsights.v2015_05_01.implementation.ApplicationInsightsComponentFavoriteInner [ERROR] /home/travis/build/Azure/azure-sdk-for-java/applicationinsights/resource-manager/v2015_05_01/src/main/java/com/microsoft/azure/management/applicationinsights/v2015_05_01/implementation/ApplicationInsightsComponentFavoriteImpl.java:[39,68] cannot find symbol   symbol:   method id()   location: variable inner of type com.microsoft.azure.management.applicationinsights.v2015_05_01.implementation.ApplicationInsightsComponentFavoriteInner [ERROR] /home/travis/build/Azure/azure-sdk-for-java/applicationinsights/resource-manager/v2015_05_01/src/main/java/com/microsoft/azure/management/applicationinsights/v2015_05_01/implementation/ApplicationInsightsComponentFavoriteImpl.java:[69,28] cannot find symbol   symbol:   method id()   location: class com.microsoft.azure.management.applicationinsights.v2015_05_01.implementation.ApplicationInsightsComponentFavoriteInner [INFO] 5 errors  [INFO] -----------------

Storage SDKs are also noticing this issue. The only missing import for us is OffsetDateTime in the Generated clients. Once I manually import it, everything works fine, but it is consistently left off every time we generate.

Please open new issue with more details if this is still an issue.


Less an issue, more of a question.

Hi, I'm looking to build this project soon, it looks really cool! I just have a few questions about the battery.

Can you use a higher capacity battery with this circuit?
If yes, do you need to change any code or components to make it work?
Does it need to be a Lipo battery or could it be Li-ion?
Can it be physically larger in size if I just modify the STL files to make it fit?

Thanks in advance, really excited to build this!

Yes, you can use a higher capacity battery. I built a PiPod_ePaper (check out that repository if you haven't seen it yet) using a 2000 mAh battery (Adafruit product #2011).

You do not NEED to, but you can change the value of R6 (connected to the TP4056 IC). This resistor (connected to the PROG pin) sets the charging current: 10k = 130mA, 5k = 250mA, 4k = 300mA, 3k = 400 mA, 2k = 580 mA.
The schematic value of 3.8k sets charging current to just over 300 ma.
To keep the battery life long, I like to keep the charging current around 0.25C.
Charging current of 300 mA is 0.25C for a 1200 mAhr battery, but is only 0.15C for a 2000mAh battery. (Very slow charging.)
So changing it to around 2k would be fine for a 2000 mAHr battery (0.29C charge rate).

Li-ion battery would be fine.

The 2000 mAHr battery is slightly thicker than the 1200 mAHr battery. I will be modifying the case of the PiPod_ePaper version soon, for that battery in the next week or two. I will not be modifying the PiPod_Zero2W case, because I am only working on the ePaper version right now.
So, yes, just modify the case to fit any battery you want.

Have fun!

Awesome, thanks so much for all the info! Really excited to build this, and I'm very glad to hear that a larger battery will be just fine!

Popping back here because I checked out the ePaper version and it looks great, but I'm already getting the PCB made for the one with a TFT display.
I see that the ePaper version has more bug fixes and some software changes, I have a few questions about that, sorry for being such a nuisance.

Is the software for the ePaper version compatible with the TFT version?
Is it worth it for me to consider using that software if it is compatible, is it better than the TFT version?
I assume the ePaper version has a different PCB, but just to confirm- can you put an ePaper display on the TFT PCB or no?

I might just build the TFT version first and make an ePaper one later on if I feel the need to.
Would you say that there are any software files that are directly compatible that may improve the experience of the TFT version? Or some that are easy-ish for a newbie like me to figure out how to "port" them over?
If I do end up doing the ePaper version I will definitely hit you up on that offer, as long as nobody beats me to it!

All of the files for the ePaper version started as the files for the Pi Zero 2 W, but then got modified. I would say a 2nd year (or bright 1st year) college student could diff the files and figure it out. You have to understand how images are created for the non-ePaper version, and how they are created for the ePaper version, and think through all of the differences, and be willing to understand the Python library files and interfaces involved. Not easy, but do-able.
Good luck. Have fun!

Hmm alright, I might not be quite at that level yet, especially not with programming. I may try my luck but I'm not going to get my hopes up for any success.
Thanks so much for your quick responses, and for the awesome work you've done creating these two projects to make the original design just that much better! It really is super cool.


Wildcard ignore

flake8 and pep8 interprets values passed to 'ignore' as prefix to ignore. So one can:
pep8 --ignore=W

That will ignore any pep8 ignore.
I wanted to have pep257 to ignore any missing docstrings (D10{1,2,3,4}) by using:
pep257 --ignore=D10

But that would only ignore D10 errors and let D101 and others flow in.
pep8 handles it via startswith():
 def ignore_code(self, code)
 "check if code should be ignored"
    return (code.startswith(self.options.ignore) and
        not code.startswith(self.options.select))

In my opinion it should be done explicitly, maybe with an asterisk? something like --ignore=D10*?

I think we should support an API similar to pep8 / flake8.

Addressed in #210 since this is a minor change.

Addressed in #212


EnsureProperty Documentation

EnsureProperty API/feature is undocumented;
didnt seen an original Issue re-open so creating this.

I believe this feature will be superseded by Ensure Oak Index in 2.1.0; removing undocumented flag


Regularization bugged?

I know it's weird and that somebody should have noticed, but regularization only seems to help when I override the defaut settings and use negative values. With negative values, regularization indeed does seem to make the network work better most of the time, (this is even more noticeable with deeper networks) but with any but the lowest positive values, the neural network usually malfunctions and fails to learn.

I am curious to know if progress has been made on this issue as I also feel the regularisation is not working properly. I started with a small training set (10%) , no regularisation and a network with 3 layers of 8 neurons each in order to encourage overfitting. ThenI I started increasing the regularisation parameter but not much is happening. Then the optimisation gets stuck for regularization parameters values say above 0.03. I am also curious how you can override the default settings with negative values with the current interface. Olivier

I've gotten regularization to reliably work at typical values by making a small tweak to allow changing the regularization hyperparams on-the-fly (forked playground env). Starting the training with 0 regularization and then turning on L1/L2 reg after a short warm-up period (say, ~5-100 epochs depending on other hypers) works very well. I'm not sure why this is the case, but I suspect a combination of sub-optimal initialization as well as regularization being generally more useful after a short warm-up period. As an heuristic, regularization seems to work best after letting the network fit the data first (overfitting is no problem, then after turning on L1/L2 reg, you can observe overfitting diminish - especially salient with L1 "killing" redundant nodes). I've just submitted PR here - hopefully it will be added to this official repo soon!


[10.x] Adds Eloquent User Provider queryCallback setter from model

In the current project, I need a comprehensive user check before authorizing it.
In the EloquentUserProvider, I found the necessary functionality - $queryCallback - however, there is no convenient functionality for to use it.
The best place for the $queryCallback logic , in my opinion, in the Model.

Thanks for your pull request to Laravel!
Unfortunately, I'm going to delay merging this code for now. To preserve our ability to adequately maintain the framework, we need to be very careful regarding the amount of code we include.
If possible, please consider releasing your code as a package so that the community can still take advantage of your contributions!
If you feel absolutely certain that this code corrects a bug in the framework, please "@" mention me in a follow-up comment with further explanation so that GitHub will send me a notification of your response.


Imports missing from "nmigen.cli" compatibility wrapper: rtlil, verilog

$ python
Python 3.7.3 (default, Jan 22 2021, 20:04:44)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from amaranth.cli import rtlil, verilog
>>> from nmigen.cli import rtlil
__main__:1: DeprecationWarning: instead of nmigen, use amaranth
__main__:1: DeprecationWarning: instead of nmigen.cli, use amaranth.cli
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: cannot import name 'rtlil' from 'nmigen.cli' (/home/cstrauss/src/nmigen/nmigen/cli.py)
>>> from nmigen.cli import verilog
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: cannot import name 'verilog' from 'nmigen.cli' (/home/cstrauss/src/nmigen/nmigen/cli.py)

Amaranth version: commit b1f5664b05725676cafa6c9313096c6fba0a47be (main)

So these are just nmigen.back.verilog; they were never intentionally exported from nmgien.cli, and so aren't present in the wrapper.
There are probably hundreds of other names like that. I consider this a substantial weakness of the Python import system; the module interface and the module implementation are conflated, which makes it quite hard to maintain backwards compatibility as people end up depending on unintentionally exported names,

Got it, thanks.


Object has been deleted or invalidated.

SDK and version
SDK : Swift
Version:
Realm: 10.28.6
RealmDatabase: 12.5.1
App crashes when this code runs.
let realm = try Realm()
let fetchResult = realm.objects(HLAsset.self).filter("assetCollection=%@", hlAssetCollection)

for i in 0 ..< fetchResult!.count {
    print(fetchResult![i].identifier) // => crash (not crashed for all object. explained below)
}

App was working well (database was OK).
Added some objects to database. (nothing special)
Exited an app.
App runs => crash

You can see something is wrong with this screenshot.
When I open the realm file with Realm Studio, there are objects have same identifier(Primary Key).
I don't know how this can happen.
When reading other objects, there is no problem. But when reading objects like this (some objects have same identifier), app crashes.

When I tried to save data as JSON, it failed.
When I tried to save data as Local Realm, it saved .realm file(size changed from 167.1MB to 23.1MB) but it is not opened with Realm Studio nor an app.

Transferring to realm-swift as this seem to be happening above the Core line.

I'm not sure this is true, @jedelbo. I have seen this kind of crash/report also on Android and traced it down to lines that basically did nothing more than shown in this report.

@xiles Can you reduce this issue into a small sample app that reproduces the crash?

@leemaguire I sent an email to<EMAIL_ADDRESS>with a broken database file.
I cannot make a sample app to break a database file.. I don't know why and when it happened.
But if you open a broken database file then select several objects has same identifier(Primary Key) and delete, Realm Studio says "Object is invalid. Either it has been previously deleted or the Realm it belongs to has been closed.”

We will investigate why such a scenario occurs.

@leemaguire I can investigate.

The database has some references pointing in the wrong direction. So it is clearly broken. I will take the issue back to core and make some further analysis on the file.


Manual Capture create invoice on Capture notification if there is none

It could be that the capture is done on Adyen platform instead of magento (forexample a specific order or Manual Review) if it contains a full capture create a invoice automatically when the capture notification is received.

Fixed here: https://github.com/Adyen/magento/commit/532dd6749e08c644419c663ad9364c22be2dad55


Use calculateMetadata() to fetch the durations

The previous solution did not work because of a weird behavior with R3F where each components useState() function got called multiple times (bug?).
This does not happen with normal React components but R3F uses a custom renderer.
There is a better way to do it anyway: Using calculateMetadata(), the duration only needs to be fetched once and we can remove the useEffect().

Second commit:
Make the bucket appear from the beginning.

useGLTF is not wrapped in delayRender(), so fetching it in a useEffect
Doing the fetching outside the canvas for the same reason
Cannot do it in calculateMetadata() because the data there needs to be JSON serializable
Cannot do an early "return null" because waiting for Suspense to finish is supported, but not if Suspense gets added later on

IMO this is all messy, but also due to weirdness inherited from React Suspense and R3F. Hope to show that we can work around it nonetheless!

This is great! Thank you so much for the example.
Can I do something so that it works like in normal React components? My project has an array of scenes like in this example, but some scenes may contain a video that I want to show as a video texture.
Suppose I'm using useVideoTexture or useOffthreadVideoTexture at the top level. In that case, I need to determine my current scene shown in the <Series.Sequence> and then dynamically pass the video src to this hook. Also, delayRender is called only once in this hook :(


Update router docs with EVM Signer option

Resolved in https://github.com/paraspell/docs/commit/f6066f02bf10ce4043be2319f8ce265865fec8a3


MM-39690: Clarify worker settings if ES starts later

https://mattermost.atlassian.net/browse/MM-39690

/release-note-noen


Provide ability to disable/limit retries in batch listener when using DefaultAfterRollbackProcessor

Expected Behavior
Configuration to disable/limit retries in the batch listener when using DB transactions and DefaultAfterRollbackProcessor
Example of listener @KafkaListener(topics = BATCH_TOPIC, batch = "true") {}
Current Behavior
Currently, the DefaultAfterRollbackProcessor retries the failing message infinitely if using batch listener with DB transactions.
Context
The main problem if we forget to handle the failing message inside the listener then the failed message will stuck until we take some manual action to skip this message. That's why we would like to have a config to disable/limit retries at the configurations level.
I tried to find a way to disable retries for batch listeners but unsuccessfully.
new FixedBackOff(0, 0)
new DefaultAfterRollbackProcessor<>(deadLetterPublishingRecoverer, backOff);
The workaround can be to force to use recoverable=true always  in order to limit retries
return new DefaultAfterRollbackProcessor<>(deadLetterPublishingRecoverer, backOff) {
            @Override
            public void process(
                    @NotNull List<ConsumerRecord<Object, Object>> consumerRecords,
                    @NotNull org.apache.kafka.clients.consumer.Consumer<Object, Object> consumer,
                    MessageListenerContainer container,
                    @NotNull Exception exception,
                    boolean recoverable,
                    @NotNull ContainerProperties.EOSMode eosMode) {
                // Force all messages to be recoverable.
                super.process(consumerRecords, consumer, container, exception, true, eosMode);
            }
        };

Forcing it to be recoverable will not do what you expect. We don't know which record in the batch failed, the whole batch is passed in and the "recovered" record will just be the first one in the batch and not necessarily the one that is causing the failure.
To solve this problem, we should probably enhance the DARP to understand BatchListenerFailedException s (like the DefaultErrorHandler now does) so the app can indicate which record caused the failure and only recover that one.
Note that if you are only using DB transactions (and not publishing to Kafka as well as updating the DB in the listener), there is no need to make the container transactional.

Forcing it to be recoverable will not do what you expect. We don't know which record in the batch failed, the whole batch is passed in and the "recovered" record will just be the first one in the batch and not necessarily the one that is causing the failure; that's why batch failures are not recoverable.

Yes, you are right. It will just limit retries. It will not be infinite

Note that if you are only using DB transactions (and not publishing to Kafka as well as updating the DB in the listener), there is no need to make the container transactional.

we always update DB in RecordFilterStrategy to save processed messages into DB in order to implement an idempotent consumer pattern. That's why we can't use DefaultErrorHandler

You don’t need Kafka transactions if you are not producing to Kafka in your listener. It has nothing to do with idempotent consumers, only exactly once semantics for consume->process->produce scenarios.

You don’t need Kafka transactions if you are not producing to Kafka in your listener. They have nothing to do with idempotent consumers, only exactly once semantics for consume->process->produce scenarios.
Or, for atomically producing multiple records.

We don't use Kafka transactions at all. We use DB transactions instead to implement idempotent consumer. Anyway, it does not matter which transactions to use there, the behavior of retries will be the same. So it would be nice to have proper retries in the batch listener with DefaultAfterRollbackProcessor or an option to disable retries to avoid the infinite loop

I agree; hence my comments above about enhancing the rollback processor.
However, adding a transaction manager to the container is only intended for the use of Kafka transactions.
You can use @Transactional on the listener method or, to include the listener adapter (including any RecordFilterStrategy) in the scope of the transaction, add a TransactionInterceptor to the container's adviceChain property.
The container should never have a transaction manager if Kafka transactions are not being used.

Hi, @garyrussell  may i pick it up?

@Wzy19930507 ,
sure you can!
This is an Open Source project, so any contribution is welcome!
I cannot advice anything for you what exactly to do at the moment, but let's see first if you have anything in mind how to fix it.
Don't hesitate to open Pull Request: https://github.com/spring-projects/spring-kafka/blob/main/CONTRIBUTING.adoc !

@artembilan @garyrussell @sobychacko Thanks for review, this issue could not have been closed without your guidance.


bulk import of users

Faster import for users using the mass_import API. Tested for smaller data sets; with bigger data I run into problems as described in #4356. Error feedback in that case would be still open (server not responding at all, for quite a while).

this is most likely a timing issue (and I'm unsure yet how to handle this). Mass_import gives no success feedback; so I have to look into the dataStore afterwards if the entries are there. It seems that they don't arrive 'on time'.

There is an undocumented feature in the view: add "importTrackId" (the key) to each user. The value may be the index of the list or so. The server returns an array of trackIds, that were imported successfully. In the ui, you can mark imported users with this information.
I will try to check, where the bottleneck is during the import.

@FinnStutzenstein  Thanks, it occurred to me this morning (you told me before, a while back), I did not yet come to implement it.

I updated with the trackId feedback, results should be valid now.
Still not happy with the performance. On initial parsing, we lose 90%ish of the time to some cdK table render events; on import we don't lose that much time, but a feedback 'please wait, doing import' would be nice.

The performance should be improved a bit now:

only send 100 requests at once (avoiding timeouts)
trying to make the initial table rendering less painful (a bit of cargo cult magic here, could probably be improved; paginating did not work as I thought it would).


Issue with flutter cloud_firestore

Compiler message:
Warning: Tried to initialize from a previous compilation (build/app.dill.track.dill), but the file was not self-contained. This might be a bug.
please find the attached file 'initialize_from.dill.gz'
initialize_from.dill.gz
Flutter doctor results:
√] Flutter (Channel dev, v1.2.0, on Microsoft Windows [Version 10.0.17134.523], locale en-US)
• Flutter version 1.2.0 at D:..\flutter
• Framework revision 06b979c4d5 (11 days ago), 2019-01-25 14:27:35 -0500
• Engine revision 36acd02c94
• Dart version 2.1.1 (build 2.1.1-dev.3.2 f4afaee422)
[√] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
• Android SDK at \AppData\Local\Android\sdk
• Android NDK location not configured (optional; useful for native profiling support)
• Platform android-28, build-tools 28.0.3
• Java binary at: Android\Android Studio\jre\bin\java
• Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1248-b01)
• All Android licenses accepted.
[√] Android Studio (version 3.3)
• Android Studio at C:\Program Files\Android\Android Studio
• Flutter plugin version 32.0.1
• Dart plugin version 182.5124
• Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1248-b01)
[√] VS Code (version 1.30.2)
• VS Code at \AppData\Local\Programs\Microsoft VS Code
• Flutter extension version 2.22.3
[√] Connected device (1 available)
• Android SDK built for x86 • emulator-5554 • android-x86 • Android 8.1.0 (API 27) (emulator)
• No issues found!
Process finished with exit code 0

Can you add some more context?  What were you doing when this error was triggered?

Thank you for your reply, issue closed


Could not build Objective-C module 'Cely'

I'm working on Xcode 10.2.1 and after install through CocoaPod and import Cely I got an error Could not build Objective-C module 'Cely'

Thanks for the report. I should be able to take a look at this today.

@thunpisit What version of Swift are you targeting?

I'm using Swift 5

resolved with #35


Not working with Sandeep's Lora Library

This library seems to be incompatible with Sandeep's Lora library - https://github.com/sandeepmistry/arduino-LoRa
As soon as I use the Led functions I no longer receive message on Lora. Might be an interrupt thing?

JLed does not use interrupts, it relies on an Update() method being called from the main event loop() function. Besides that, only pinMode() and analogWrite() are used. No hidden magic.
Is it possible that you are using GPIO pins with JLed that are already in use by LoRa hardware? Try changing the pins the LEDs are connected to.
In general this defect report is too generic as to be accepted. Please provide further details like hardware used, test setup, example code etc. so there is a chance of getting the observed behaviour reproduced.

Thanks, I'll refine my tests and see if I can distil the essence of the problem! I'll re-open if needed.


Special chars iussue

I'm using this component but I got troubles when I insert special chars like accented letters, because they got rendered bad.
How can I work this out?
UTF-8 charset is set.
EDIT: I got it if the local model is empty. If the local model is yet valorized, there's no accent troubles.
Cheers,
Francesco Bruni

Is this still an issue?

I tried using UTF-8 characters on the demo site and I don't see any issues.  Maybe you didn't properly set your page encoding to UTF-8.

@eugef There has been no follow up, please close.


Fix spelling errors in comments and strings.

I focused primarily on comments, but several strings were corrected.

Thanks @jbcrail -- have you signed the CLA?

Closed in error.

I signed it yesterday. I couldn't find a public link to it to confirm this.

Great, thanks @jbcrail

Verified cosmetic changes only, merging now.
Thanks again @jbcrail


Ros2 lights tests

Add:

APA102 tests
Lights Driver Node tests
renaming front_panel -> chanel_1 & rear_panel -> chanel_2

There is one error with the Publish Success test that I do not understand. For some reason, when this test is performed before other tests, the error shown in the screenshot below appears.

I don't see any reason why this would happen because with each test all objects in the DriverNodeFixture class are destroyed.

I also added this line because it also caused an error similar to the one above. I don't know yet whether I should replace true -> false in this line

  std::vector<panther_gpiod::GPIOInfo> gpio_info_storage = {panther_gpiod::GPIOInfo{
    panther_gpiod::GPIOPin::LED_SBC_SEL, gpiod::line::direction::OUTPUT, true}};

It shouldn't be, but it would be good if you ran this test once (you can use panther-81b2-rpi:~/rafal_ws$ colcon test --packages-select panther_lights) to check if the panther doesn't light up for a split second like a Christmas tree during the tests.


fix(client): cert project help post sans editable region

Checklist:

[x] I have read and followed the contribution guidelines.
[x] I have read and followed the how to open a pull request guide.
[x] My pull request targets the main branch of freeCodeCamp.
[x] I have tested these changes either locally on my machine, or GitPod.

Closes #49141
Seems like something Naomi did - forgot optional chaining
I had hoped to just add unit tests, but then fell down the redux/rxjs unit test rabbit hole, and never came out.

@ojeytonwilliams Actually, I am just wondering. I grabbed those values from GraphQL (Gatsby). So, the editableRegions property should exist, it should just be an empty array?

It starts off as one, but gets overwritten
https://github.com/freeCodeCamp/freeCodeCamp/blob/0b6ba2cf736b8fdfd055bf64ab1ce7b9c93862c3/client/src/templates/Challenges/classic/editor.tsx#L816-L822
It seems fine to me to set it to [] rather than undefined.  Might as well keep the tests and ?, though.


go get<EMAIL_ADDRESS>

go get<EMAIL_ADDRESS>With current<EMAIL_ADDRESS>depedency, our
generated json from weave-net setup return witout the newly required
cniVersion.
For<EMAIL_ADDRESS>such cniVersion is now
required or else will fall as default version number 0.1.0.
This PR update the vendor folder as below:

Update dependency with go get<EMAIL_ADDRESS>Update vendor directory with go mod verndor
Update API interface to current "github.com/containernetworking/cni/pkg/types/100"
Update QEMU with QEMU_VERSION=v6.1.0-8
Update build plan with golang:1.17.9-buster
Update base image with alpine:3.15

Test images could be found from:

https://hub.docker.com/r/alvistack/weave-kube
https://hub.docker.com/r/alvistack/weave-npc

See https://github.com/containernetworking/cni/blob/v1.0.1/Documentation/spec-upgrades.md
See https://github.com/containernetworking/cni/commit/27a5b994c2a55d1fceca08ec88139b61d4ad55fd
See https://github.com/containerd/containerd/issues/6575#issuecomment-1057043822
Fixes https://github.com/weaveworks/weave/issues/3936
Fixes https://github.com/weaveworks/weave/issues/3938
Signed-off-by: Wong Hoi Sing Edison<EMAIL_ADDRESS>

Image temporarily upload as below:

docker pull alvistack/weave-kube:2.8.1-20220413fb7016bb (see https://hub.docker.com/r/alvistack/weave-kube)
docker pull alvistack/weave-npc:2.8.1-20220413fb7016bb (see https://hub.docker.com/r/alvistack/weave-npc)

FYI, that's what I tried as well (but just v0.6.0) and the resulting plugin just crashes on start (https://github.com/weaveworks/weave/issues/3936#issuecomment-1083047473)

With current github.com/containernetworking/cni/pkg/types/100 we have following error in live kubernetes 1.23 cluster:
  Warning  FailedCreatePodSandBox  2m13s (x83 over 20m)  kubelet            (combined from similar events): Failed to create pod sandbox: rpc error: code = Unknown desc = failed to create pod network sandbox k8s_coredns-64897985d-h5wft_kube-system_f701b74c-34d0-4994-bcc9-a75a2054d7e7_0(833caabdd1f92a56a8ef540054216b5d3d06aa811f41f317c9cfca58ea7a07a0): error adding pod kube-system_coredns-64897985d-h5wft to CNI network "weave": plugin type="weave-net" name="weave" failed (add): netplugin failed: "panic: interface conversion: types.Result is *types100.Result, not *types040.Result

I am now trying with current github.com/containernetworking/cni/pkg/types/040 see if could match ;-S

I am now trying with current github.com/containernetworking/cni/pkg/types/040 see if could match ;-S

Yes, that's pretty much API compatible and what I did as well.

Yes, that's pretty much API compatible and what I did as well.

IMHO the dependency packages should upgrade into latest stable, where we could still pin the API with legacy version in this PR.

The images from https://github.com/weaveworks/weave/commit/6b4cadfccbb68d2d4aec6af28e71f310710d9fed looks functioning:

docker pull alvistack/weave-kube:2.8.1-202204146b4cadfc
docker pull alvistack/weave-npc:2.8.1-202204146b4cadfc

But with some limitation:

PASSED: For a newly installed 3 node k8s, start upgrading from 1.21 -> 1.22 -> 1.23 (which originally failed), where runing k8s-conformance with sonobuoy run --mode=certified-conformance for each version, are all ok
FAILED: For an existing cluster with weave v2.8.1 and upgrade with above 2.8.1-202204146b4cadfc, the CNI looks crazy with existing interface and not able to upgrade it, so all pod stop working...

To whom it may concern about a modern CNI with rich community support, try https://github.com/cilium/cilium with my https://github.com/alvistack/ansible-role-kube_cilium, or simply install as below:
helm template cilium cilium/cilium \
    --version 1.11.4 \
    --namespace kube-system \
    --set bpf.preallocateMaps=true \
    --set cni.chainingMode=portmap \
    --set cni.exclusive=false \
    --set endpointRoutes.enabled=true \
    --set hostPort.enabled=true \
    --set hubble.enabled=false \
    --set ipam.mode=cluster-pool \
    --set ipam.operator.clusterPoolIPv4MaskSize=24 \
    --set ipam.operator.clusterPoolIPv4PodCIDRList=<IP_ADDRESS>/18 \
    --set ipv4.enabled=true \
    --set ipv4NativeRoutingCIDR=<IP_ADDRESS>/8 \
    --set ipv6.enabled=false \
    --set k8s.requireIPv4PodCIDR=true \
    --set kubeProxyReplacement=probe \
    --set nodePort.enabled=true \
    --set nodeinit.enabled=true \
    --set operator.replicas=1 \
    --set tunnel=vxlan \
    > cilium.yml
kubectl apply -Rf cilium.yml

This come with vxlan + cluster-pool == k8s podCIDR + portmap (hostport) support, most likely portable and similar as Flannel or Weave default installation.
P.S. don't spend your time for a project that original author even no longer consider about it, but just shift their development and business focus to GitOps :-(

Looks like the main guy was working on this project is now at Grafana Labs, unless I'm mistaken the latest commit he did on the latest version tag is more than one year ago. I dont like it but on our side I think we have no choice but to consider this project shelved and look into a replacement network overlay. Thanks for your efforts @hswong3i .

I am sorry for the lack of reply on this, I use weave net and I appreciate that you've done this work. It is a mega-PR!
I should be able to complete this by the end of KubeCon next week. I'm only able to promise that I will try what you've contributed and check if it works with the next K8s release for me, I can't promise a release; I want to participate and help but I have limited time that I can spend on Weave net, it is not what I was hired to do here.
As you've correctly noted we are definitely more focused on GitOps as a company at this point. I would expect a lot of people to have noticed that development on Weave net has stopped and for most of those people to have moved on by now, as there haven't been any releases here in over a year.
I really do appreciate you. It will be great to get a release out that supports containerd and K8s 1.24. I cannot promise that, I'm not certain that I'm qualified to certify a next release given the time that has passed and potential that bit-rot will have set in one way, and I cannot comment on the status of the project with respect to being shelved, but if you still have any interest in collaborating on a next release, I can try to connect the dots and get your fix merged if it turns out that it is viable to produce another release. I don't want to lead anyone on in the wrong direction though. If you have already moved on, there will be no hard feelings about it.
Again I'm sorry that no one has been by to look at your contribution here, please do not consider this a personal slight! We have been very busy getting Flux to GA and working on graduation from the CNCF.

From business value point of view I am totally agree with focusing on GitOps rather than a CNI plugin, which could solve the customers real pain point with paid addon service.
From technical point of view Weave had done a good job from the early day of Kubernetes and CNI: it is simple stupid and elegant for both installation and maintenance, with network policy and multicast support, also with vxlan that most likely always work for every environment.
BTW when compare Cilium kernel space eBPF implementation with traditional sidecar-based (e.g. istio and linkerd) or user space iptables implementation (e.g. flannel and weave) ,

I figured out how to adjust my testing so that neither node tries to install using docker shim, rather than migrating the node from docker shim (set --cri-socket at kubeadm join time) and I see the same behavior now with both nodes. (I use docker for something important on this machine outside of Kubernetes, such that I can't just uninstall docker.)
Both nodes start in NotReady and report that CNI is not configured in their status information.
  Ready                False   Wed, 11 May 2022 15:40:25 -0400   Wed, 11 May 2022 15:35:01 -0400   KubeletNotReady              container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized

FWIW, when I use the cilium config that you specified (and adapt the pod subnets for my preferred configuration) both nodes register as ready and things do not come up as normal either. I tested this to verify that my containerd configuration is correct and not the issue. So it looks like there IS something wrong with my node configurations that will have to be fixed,
I have used this cilium config on the same machines with docker shim earlier today, so I'm sure it's not a problem with that configuration.
It is likely not an issue with the changes you made at all, but some step I skipped in the containerd configuration guide from kubeadm. If you have any idea how to help me test this, or what else I might have missed building the images, I'm all ears.
I will have to take another stab at it next week. I'll need to bring this cluster back up using docker shim for now, I think.

The only way I was able to make this cluster stable again was to move it back to Docker Engine
(dockershim, not cri-dockerd)
I guess this is not the prescribed method for 1.23.x, so that's probably why you say that weave net does not work with 1.23.x anymore. I could not get either cilium or weave net to work reliably on containerd, I guess there is some misconfiguration with my cluster. Like I said, I'll try to follow this up next week.

@kingdonb at the risk of taking over the OP's issue..   docker uses containerd.. you may have two containerd's and/or the containerd config.toml you are using from docker's install may not be setup right. We (containerd and cni are working on the issue with starting pods on the older version of weave issue). Suggest sticking with containerd 1.5.11 if you want to use the older weave.. until you hear reports of weave being fixed on containerd 1.6.(5? when it comes out) or 1.6.4 if weave does an update. Cheers!

I appreciate the interjection, I am not caught up on these issues.
I saw some of the discussion about backwards compatibility. I am at Weaveworks and I'm trying to deploy the update from this branch, (ostensibly so I can verify this release will be suitable to print, and then push the big red button to publish an update.) But I do not know which versions of containerd it will work with. And I'm not sure if there are other critical issues besides this one that need to be resolved to get this CNI working with modern Kubernetes beyond the Docker Shim.
I'll move my docker containers to another host (pi-hole, dd-warden) and get them out of here, so I can uninstall Docker and for sure have just one containerd. Maybe that is what's wrong with my setup. Thanks!

I appreciate the interjection, I am not caught up on these issues.
I saw some of the discussion about backwards compatibility. I am at Weaveworks and I'm trying to deploy the update from this branch, (ostensibly so I can verify this release will be suitable to print, and then push the big red button to publish an update.) But I do not know which versions of containerd it will work with. And I'm not sure if there are other critical issues besides this one that need to be resolved to get this CNI working with modern Kubernetes beyond the Docker Shim.
I'll move my docker containers to another host (pi-hole, dd-warden) and get them out of here, so I can uninstall Docker and for sure have just one containerd, then also perhaps I can try the earlier version of containerd. Maybe one of those are what's wrong with my setup. Thanks!

Thanks for the explanation :-) Feel free to grab me on slack or what not anytime for a discussion ..
I looked over this PR that is moving up the weave plugin to the latest library release of CNI. Looks good to me, but I did not pull it down and to a build/test. containerd 1.6.4 is our latest release, it is on the latest CNI library and should work well with weave once this PR is merged. If you have a "service" release you might also want to refresh the older version of the plugin with just a fix for inserting the config version in the response, as that would be a smaller change. Once we (cni/containerd) have a fix rolled out into 1.6.5 containerd that version of containerd should work with your older version. If you have a plugin that is ahead of the cni containerd is using there may be a mismatch on pod setup or tear down.  A tricky part of this is changing config / or plugins while pods are still running.. can cause issues in network tear down. So caution and testing is definitely suggested. Cheers, Mike

Thanks, so I understand now there is an issue where the Weave net CNI plugin does not respond with the version of CNI, and there's a backwards-compatibility fix coming for CNI that should enable old Weave net versions to work on newer CNI versions, which should work anyway. Weave net should fix this variance from the spec, and also upgrade CNI to v1.0.1 – but those are separate issues, and I am likely seeing issues with the latest version from this branch because CNI hasn't yet made the backwards compatibility fix, and because Weave net hasn't yet fixed its own variance from the spec.
Either one of these changes could unblock the issue. We should upgrade the CNI to the latest version, and make the config change to the response, but these could either be made independently.
I think a service release will probably necessarily include the dependency upgrades, unless it gets a prerelease marker. Any new release of weave net will need to provide for the expectation that it fixes all known security issues. But we could make incremental progress in a prerelease, and that way at least we'd be moving the ball forward.
I do not know if the release machinery provides for prereleases. I'll have to check my notes and get back to us here.

Which backwards-compatibility fix are you referring to? Because it's such a fix which actually broke weave-net in the first place. The CNI plugin did not respond with a version, so CNI before the fix assumed it was the latest, while with recent CNI it now assume it's an older one.

@Vogtinator This is the other discussion that I've been following to try to come up to speed on what's needed here:
https://github.com/containernetworking/cni/issues/895
I still have to plead ignorance about what fixes are needed and where. (I haven't been able to provision a proper CRI environment that I can use to test the proposed changes to Weave CNI.)

Sorry that I haven't been able to give any attention to this yet. I will check in next week with this thread and other relevant threads, to figure out whether a release is again viable. 👍

https://github.com/containernetworking/cni/pull/896 merged and https://github.com/containernetworking/cni/releases/tag/v1.1.1 now released, so ideally the impact to weave may somehow improved...
BTW with the merge of this PR or any else additional enhancement with CVE fixes should be a good idea, especially weave didn't receive any else update since https://github.com/weaveworks/weave/commit/e3712152d2a0fe3bc998964c948e45bdf8ff6144 (2021-09-01...), and latest official release https://github.com/weaveworks/weave/releases/tag/v2.8.1 since 2021-01-25...
Personally I had move all of my client to cilium since https://github.com/weaveworks/weave/pull/3939#issuecomment-1115715994...

(It looks like containernetworking/cni#895 has moved ahead, so perhaps a change is no longer necessary?) Still it would be nice to publish a release with fixes for any outstanding CVEs, I cannot commit to it at this time.

Honestly, perhaps it's time to consider retiring Weave Net entirely? It doesn't seem like Weaveworks derives much (if any) business value from keeping Weave Net alive by doing requisite maintenance on it (such as updating dependencies, updating to new Golang releases, fixing ecosystem issues and adapting to ecosystem changes), all of which is required before one even looks at adding new features or fixing bugs.  Looking into pull requests and issues opened over the last year it doesn't really seem like there is enough community critical mass for the community to take on those tasks either.
I think the best thing that you could do would be to have a discussion internally at Weaveworks whether the company wants to commit dev hours to Weave Net maintenance/development and if not you should make a post in the Github Issues asking if there is any community interest in partially or completely taking over development of the project (at minimum you would need community members with push access, ability to merge PRs, and to make releases) with announcements in whatever other discussion forums you may have (such as Slack, no idea what you are using nowadays) to create as much awareness of that discussion issue as you possibly can. Then after a few months you'll have a much better idea of the state of the community and can make a more informed decision on the future of the project. Who knows, maybe there's a company out there that provides a managed Kubernetes product that's heavily dependent on Weave for whatever reason and they'd be more than happy to take over primary development.
Now if this was a different kind of project (like a personal project or an open source game or whatever) I would have a very different perspective and would probably not be suggesting to end the project but as a networking plugin Weave Net is a critical part of peoples infrastructure and is by nature security critical. Yes, it's a sad day when open source projects die but it's far better to be explicit about it with a notice and suggested alternatives than allow it to go a year plus without any signs of life. It would frankly be the wrong decision to fix this MR, merge it and then release a new version if there's no real change in commitment to future development from Weaveworks or the community.

Reilly, thanks for your comment.  We are interested in moving this project to a 100% community model, and would welcome a bit of help rallying folks around that.  I have spent quite a bit of time looking for help from vendors but they would want to see a community model first.  What are your thoughts?
alexis

Why not donate Weave Net to CNCF as sandbox project, and so asking for community support and maintenance?

@rajch yes - something like this would work well.  agree 100%.  previously @dholbach shepherded Kured this way.  but weave net is bigger and needs more help.  I have tried and tried to get the cilium folks to see how much value weave-cilium can add!  maybe you could help me convince them
@hswong3i -- needs a plan first

Document the design and technical decisions that have got us to v2.8.1.

This would be asking a lot of people who are no longer employed at Weaveworks, the reality is we do not have most of those people on board anymore and would need to continue on without their leadership in order for this project to remain viable.

donate Weave Net to CNCF as sandbox project

This is not really how it works, the CNCF does not make resources available to maintain a project which is not already under their umbrella and they will not accept projects who are not vibrant and already stocked with active maintainers. I have seen some very helpful PRs from folks who would like to see Weave Net maintained and viable into the future, but so far none of those interested have risen to the level of assuming ownership that we'd expect to see from potential maintainers.
To some extent this may be due to lack of response on our part when PRs are submitted, and I am sorry about that. If there is anyone who would like to make an affirmative commitment to pursue supporting Weave net but feels disenfranchised or blocked by our lack of participation to-date over the past year, please consider this an open invitation to raise PRs to my attention and I will help you get them merged.

containernetworking/cni#896 merged and https://github.com/containernetworking/cni/releases/tag/v1.1.1 now released, so ideally the impact to weave may somehow improved...

I ran checks using Kubernetes 1.24, 1.23 and 1.22 with containerd 1.6.6 running on Debian 11.3. Weave once again works, as-in.
Still, I think merging this PR is a good idea.

@kingdonb @rajch maybe you two could sync about expanding maintainers.

In principle I agree that merging this PR is a great idea, but #3936 seems like a higher priority now if there is a backward-compatible fix for containerd and CNI upstream. I do not have a good understanding of which versions are broken and what components were responsible, @rajch if you know the details of this I'd definitely appreciate it if you can send a PR for the docs.
I'd love to merge a PR that ensures Weave net works on all versions of Kubernetes again (even those running with components that had this backward-incompatible change, since it sounds like the change on our end needed is relatively trivial).
This PR on the other hand is not trivial. Merging it as a drive-by with no maintainer commitment for more releases going forward seems like a poor plan. I really appreciate the work, I'm just not sure who should own it. (I think I can't own it.)
I am happy to R.O. with anyone via CNCF Slack or Weaveworks community slack who is interested in more information about becoming a Weave net maintainer. We've already received at least one private reply about it.
The call-outs in this thread about our priorities with respect to other products are all correct. We haven't prioritized putting resources into Weave net because it's not driving our business. But I find the one-liner install experience with zero config very compelling to this day, I expect that even without a maintainer Weave net will remain very popular until it does no longer work anymore.
My first interest from a triage perspective is updating the docs to reflect the current maintenance status and versions which are known not to work together.
The second priority which is critical before other priorities can be addressed, broadly, is expanding the maintainer pool. (To that end, we should figure out where we are going to rally this cause, somewhere other than inside of this PR thread.)

If the solution really is just to skip up to containerd v1.6.6, this would be the most anticlimactic resolution I've ever seen.

It's a solution, thanks to helpful reporting by a number of people, and fast work over at containernetworking/cni and /containerd/containerd. The concerned issues/PRs mention weave by name, so looks like weave is actively used in a lot of places.
Thank you, @hswong3i. Your work on this PR helped me understand the issue clearly.

thank you @rajch

My recommendation is to move the discussion on the future of the Weave Net project to a separate Github issue (and probably pin it). This PR is not really the place for it and has low visibility. Perhaps amend the Github readme to point it out so it's even more visible. It's been years since I've been a part of it but I think there was a channel for weave net on the Weaveworks Slack? Could probably post an announcement there.
At this point I think the best approach is to try to get as much visibility as possible so as to draw as many people who might be interested in becoming maintainers out of the woodworks as you can.

good idea @ReillyBrogan
@kingdonb would you mind doing this (GH+Slack) -- I'm happy to help offline

Shall we back to the origin or this PR?

Verify if the changes do help? e.g. Replace v2.8.1 with image provided from https://github.com/weaveworks/weave/pull/3939#issuecomment-1099812129 and test the result?
Commit this PR as hotfix for v2.8.1
Release a new version and image, e.g. v2.8.2?

We could dream big with community based support (later...), but at least please proof that someone have right to accept the PR and create a new release.... Else how could we believe that Weave Net is ready and able for re-activate?

My recommendation is to move the discussion on the future of the Weave Net project to a separate Github issue (and probably pin it).

+1
@monadic I have some ideas regarding vendors that can approached. Cilium is probably not a good idea, as they have a functionally equal product using different underlying technology. But let's not hijack this discussion - we'll continue elsewhere.

Shall we back to the origin of this PR?

I just ran some tests, as follows:

Modified the weave manifest downloaded with the one-line instruction to use the  images you provided, listed above.
Created two two-node clusters. On one, ensured containerd is at v1.6.4 (where the unmodified weave manifest causes problems). On the other cluster, ensured that containerd is at v1.6.6 (where the weave manifest works unmodified)
Applied the modified manifest on both clusters

I can confirm that the modified manifest works on both clusters, with containerd 1.6.4 and 1.6.6. So yes, the changes do help.
Here is the modified manifest in case anyone else wants to test.
apiVersion: v1
kind: List
items:
  - apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: weave-net
      annotations:
        cloud.weave.works/launcher-info: |-
          {
            "original-request": {
              "url": "/k8s/v1.16/net.yaml",
              "date": "Fri Jun 10 2022 16:07:14 GMT+0000 (UTC)"
            },
            "email-address"<EMAIL_ADDRESS>          }
      labels:
        name: weave-net
      namespace: kube-system
  - apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: weave-net
      annotations:
        cloud.weave.works/launcher-info: |-
          {
            "original-request": {
              "url": "/k8s/v1.16/net.yaml",
              "date": "Fri Jun 10 2022 16:07:14 GMT+0000 (UTC)"
            },
            "email-address"<EMAIL_ADDRESS>          }
      labels:
        name: weave-net
    rules:
      - apiGroups:
          - ''
        resources:
          - pods
          - namespaces
          - nodes
        verbs:
          - get
          - list
          - watch
      - apiGroups:
          - networking.k8s.io
        resources:
          - networkpolicies
        verbs:
          - get
          - list
          - watch
      - apiGroups:
          - ''
        resources:
          - nodes/status
        verbs:
          - patch
          - update
  - apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRoleBinding
    metadata:
      name: weave-net
      annotations:
        cloud.weave.works/launcher-info: |-
          {
            "original-request": {
              "url": "/k8s/v1.16/net.yaml",
              "date": "Fri Jun 10 2022 16:07:14 GMT+0000 (UTC)"
            },
            "email-address"<EMAIL_ADDRESS>          }
      labels:
        name: weave-net
    roleRef:
      kind: ClusterRole
      name: weave-net
      apiGroup: rbac.authorization.k8s.io
    subjects:
      - kind: ServiceAccount
        name: weave-net
        namespace: kube-system
  - apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: weave-net
      annotations:
        cloud.weave.works/launcher-info: |-
          {
            "original-request": {
              "url": "/k8s/v1.16/net.yaml",
              "date": "Fri Jun 10 2022 16:07:14 GMT+0000 (UTC)"
            },
            "email-address"<EMAIL_ADDRESS>          }
      labels:
        name: weave-net
      namespace: kube-system
    rules:
      - apiGroups:
          - ''
        resourceNames:
          - weave-net
        resources:
          - configmaps
        verbs:
          - get
          - update
      - apiGroups:
          - ''
        resources:
          - configmaps
        verbs:
          - create
  - apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: weave-net
      annotations:
        cloud.weave.works/launcher-info: |-
          {
            "original-request": {
              "url": "/k8s/v1.16/net.yaml",
              "date": "Fri Jun 10 2022 16:07:14 GMT+0000 (UTC)"
            },
            "email-address"<EMAIL_ADDRESS>          }
      labels:
        name: weave-net
      namespace: kube-system
    roleRef:
      kind: Role
      name: weave-net
      apiGroup: rbac.authorization.k8s.io
    subjects:
      - kind: ServiceAccount
        name: weave-net
        namespace: kube-system
  - apiVersion: apps/v1
    kind: DaemonSet
    metadata:
      name: weave-net
      annotations:
        cloud.weave.works/launcher-info: |-
          {
            "original-request": {
              "url": "/k8s/v1.16/net.yaml",
              "date": "Fri Jun 10 2022 16:07:14 GMT+0000 (UTC)"
            },
            "email-address"<EMAIL_ADDRESS>          }
      labels:
        name: weave-net
      namespace: kube-system
    spec:
      minReadySeconds: 5
      selector:
        matchLabels:
          name: weave-net
      template:
        metadata:
          labels:
            name: weave-net
        spec:
          containers:
            - name: weave
              command:
                - /home/weave/launch.sh
              env:
                - name: HOSTNAME
                  valueFrom:
                    fieldRef:
                      apiVersion: v1
                      fieldPath: spec.nodeName
                - name: INIT_CONTAINER
                  value: 'true'
              image: 'docker.io/alvistack/weave-kube:2.8.1-202204146b4cadfc'
              readinessProbe:
                httpGet:
                  host: <IP_ADDRESS>
                  path: /status
                  port: 6784
              resources:
                requests:
                  cpu: 50m
                  memory: 100Mi
              securityContext:
                privileged: true
              volumeMounts:
                - name: weavedb
                  mountPath: /weavedb
                - name: dbus
                  mountPath: /host/var/lib/dbus
                - name: machine-id
                  mountPath: /host/etc/machine-id
                  readOnly: true
                - name: xtables-lock
                  mountPath: /run/xtables.lock
            - name: weave-npc
              env:
                - name: HOSTNAME
                  valueFrom:
                    fieldRef:
                      apiVersion: v1
                      fieldPath: spec.nodeName
              image: 'docker.io/alvistack/weave-npc:2.8.1-202204146b4cadfc'
              resources:
                requests:
                  cpu: 50m
                  memory: 100Mi
              securityContext:
                privileged: true
              volumeMounts:
                - name: xtables-lock
                  mountPath: /run/xtables.lock
          dnsPolicy: ClusterFirstWithHostNet
          hostNetwork: true
          initContainers:
            - name: weave-init
              command:
                - /home/weave/init.sh
              image: 'docker.io/alvistack/weave-kube:2.8.1-202204146b4cadfc'
              securityContext:
                privileged: true
              volumeMounts:
                - name: cni-bin
                  mountPath: /host/opt
                - name: cni-bin2
                  mountPath: /host/home
                - name: cni-conf
                  mountPath: /host/etc
                - name: lib-modules
                  mountPath: /lib/modules
                - name: xtables-lock
                  mountPath: /run/xtables.lock
          priorityClassName: system-node-critical
          restartPolicy: Always
          securityContext:
            seLinuxOptions: {}
          serviceAccountName: weave-net
          tolerations:
            - effect: NoSchedule
              operator: Exists
            - effect: NoExecute
              operator: Exists
          volumes:
            - name: weavedb
              hostPath:
                path: /var/lib/weave
            - name: cni-bin
              hostPath:
                path: /opt
            - name: cni-bin2
              hostPath:
                path: /home
            - name: cni-conf
              hostPath:
                path: /etc
            - name: dbus
              hostPath:
                path: /var/lib/dbus
            - name: lib-modules
              hostPath:
                path: /lib/modules
            - name: machine-id
              hostPath:
                path: /etc/machine-id
                type: FileOrCreate
            - name: xtables-lock
              hostPath:
                path: /run/xtables.lock
                type: FileOrCreate
      updateStrategy:
        type: RollingUpdate

Totally agree with the on going roadmap, but sorry that I couldn’t spare extra time for waiting it.
I will close the PR. Anyone would like to follow up please feel free to reuse my code (may not need to credit my contribution).
Wish Weave Net could have a better future:-)

Let's continue the conversation here: https://github.com/weaveworks/weave/issues/3948


Explain how to define group memberships with client cert authentication.

Pretty self-explanatory. Explains how to specify a user's groups when using client certs for auth.

This change is

lgtm


no-unused-variable tsLint fails on the seed

I'm submitting a ...  (check one with "x")
[x ] bug report => search github for a similar issue or PR before submitting
[ ] feature request
[ ] support request => Please do not submit support request here, instead see use [gitter](https://gitter.im/mgechev/angular2-seed) or [stackoverflow](https://stackoverflow.com/questions/tagged/angular2)

Current behavior
We added no-unused-variable to our tslint.json file.  It failed on  tools/tasks/seed/copy.prod.rollup.aot.ts.
Next I forked angular-seed with the plan to fix the problem (it was an unused const).
I fixed the tslint.json file to reproduce the problem in angular seed.  And ran npm run lint.  I received this warning and the lint wasn't run:
[15:53:04] Starting 'tslint'...
Warning: The 'no-unused-variable' rule requires type checking
[15:53:09] Finished 'tslint' after 5.48 s

I'm not sure what this means.  I ran tslint --type-check --project tsconfig.json though that turned up a whole lot of errors.
Expected behavior
npm run lint should run successfully without the warning.
The following line is removed from  tools/tasks/seed/copy.prod.rollup.aot.ts so linting passes:
const replace = require('gulp-replace');

Since replace is no longer used.
I can do this after the linting problem is fixed.
Minimal reproduction of the problem with instructions
described above
What is the motivation / use case for changing the behavior?
Our builds will fail after we pull in the next version of angular seed.
Please tell us about your environment:
Linux, node 7.7.3, npm 4.1.2

Angular Seed Version: aaaaf75
Our project's last Seed commit was a26407968cf5b7270e75b6bdfec46bdbe415fa09 (the lint failure for tools/tasks/seed/copy.prod.rollup.aot.ts)

But I forked the seed yesterday and the last commit is 0e1c1b579479485af779c68e3033783883457dae (Also has lint failure as that const replace is still there and has the Warning: The 'no-unused-variable' rule requires type checking linting failing to run issue.)

Most tslint rules provide linting per-file (also called shallow linting). Such rules do not require type checking since they take the content of specific file, build an AST and traverse it afterwards.
On the other hand, other rules require type checking because they perform "deep linting". Since I haven't found necessary to enable type checking for linting (in this case linting takes more time to complete), I haven't added the --type-checking flag.
This is not an issue in the seed, shallow linting works as intended. In case you want to allow linting with type checking we can discuss further in this issue and open a PR if we agree that it is needed.


fixed NVM installation issue

While install on a fresh Mojave installation I ran into two issues: 1) NVM was getting skipped and 2) installation did  work because ~/.bash_profile did not exist.
This fix resolves both issues by checking for existance of NVM_DIR to see if nvm is installed and creating the ~/.bash_profile if it doesn't already exist. It also loads nvm for the session to insure that node and the npm packages get installed gets installed. Also NVM gets a version bump
Fixes #7

It still is skipping the NVM install


Does it handle cloudflare?

Can it beat cloudflare in 2021? In comparison to pupeteer-stealth?

Yes, but not out of the box. Custom fingerprints are needed. We will hopefully add this feature before the end of this year.


correct service name on fpm pool template

Installing a php_fpm_pool resource fails if the php-fpm package name is different from the service name.

Hi. I am an automated pull request bot named Curry. There are commits in this pull request whose authors are not yet authorized to contribute to Chef Software, Inc. projects or are using a non-GitHub verified email address. To become authorized to contribute, you will need to sign the Contributor License Agreement (CLA) as an individual or on behalf of your company. You can read more on Chef's blog.
Non-GitHub Verified Committers
There are 1 commit author(s) whose commits are authored by a non-GitHub verified email address. Chef will have to manually verify that they are authorized to contribute.
Please sign the CLA here.

Hi. I am an automated pull request bot named Curry. There are commits in this pull request whose authors are not yet authorized to contribute to Chef Software, Inc. projects or are using a non-GitHub verified email address. To become authorized to contribute, you will need to sign the Contributor License Agreement (CLA) as an individual or on behalf of your company. You can read more on Chef's blog.
Non-GitHub Verified Committers
There are 1 commit author(s) whose commits are authored by a non-GitHub verified email address. Chef will have to manually verify that they are authorized to contribute.
Please sign the CLA here.

The typo fix has already been pulled in and I pulled in the fix for the notifies.  Thanks for pointing this out.


Custom Error Serializer

Describe the bug
I'm trying to write a custom snapshot serializer for Error. I want to strip an absolute path in the error so that the test is portable beyond my local dev machine. The error is being snapshotted with code that looks like:
expect(fn).rejects.toThrowErrorMatchingSnapshot();

By the time the Error makes it to my custom serializer it is a string, so I need to match on string values in my serializer. This isn't currently easy to do without causing infinite recursion, because the printer passed to my serializer results in my serializer being called again.
An example of a generic string serializer is:
expect.addSnapshotSerializer({
  serialize(val, config, indentation, depth, refs, printer) {
    return `Pretty: ${printer(val, config, indentation, depth, refs)}`;
  },
  test(val) {
    return typeof val === 'string';
  },
});

To avoid the infinite recursion we can do a workaround to detect when our snapshot serializer has already run, to avoid reentry:
expect.addSnapshotSerializer({
  serialize(val, config, indentation, depth, refs, printer) {
    return `Pretty: ${printer(val, config, indentation, depth, refs)}`;
  },
  test(val) {
    return typeof val === 'string' && !val.startsWith('Pretty');
  },
});

What I expect to happen instead:
printer(...) should run all serializers OTHER than the one we're currently in.
Reproduction
https://stackblitz.com/edit/node-wtwbyd?file=test-setup.js,vite.config.js,test%2Fstring.test.ts,test%2Ferror.test.ts
When the tests run they will fail with the error PrettyFormatPluginError: Maximum call stack size exceeded
System Info
From stackblitz:

  System:
    OS: Linux 5.0 undefined
    CPU: (4) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Memory: 0 Bytes / 0 Bytes
    Shell: 1.0 - /bin/jsh
  Binaries:
    Node: 16.14.2 - /usr/local/bin/node
    Yarn: 1.22.10 - /bin/yarn
    npm: 7.17.0 - /bin/npm
  npmPackages:
    vite: ^2.7.10 => 2.7.10
    vitest: ^0.0.136 => 0.0.136

### Used Package Manager

npm

### Validations

- [X] Follow our [Code of Conduct](https://github.com/vitest-dev/vitest/blob/main/CODE_OF_CONDUCT.md)
- [X] Read the [Contributing Guidelines](https://github.com/vitest-dev/vitest/blob/main/CONTRIBUTING.md).
- [X] Read the [docs](https://vitest.dev/guide/).
- [X] Check that there isn't [already an issue](https://github.com/vitest-dev/vitest/issues) that reports the same bug to avoid creating a duplicate.
- [X] Check that this is a concrete bug. For Q&A open a [GitHub Discussion](https://github.com/vitest-dev/vitest/discussions) or join our [Discord Chat Server](https://chat.vitest.dev).
- [X] The provided reproduction is a [minimal reproducible example](https://stackoverflow.com/help/minimal-reproducible-example) of the bug.

We don't control this API. Please, check pretty-format repo.


Calculation Error In rounding amount

@wes4m
sample JSON
{
"uuid":"6f4d20e0-6bfe-4a80-9389-7dabe6620f12",
"custom_id":"EGS1-886431145",
"model":"IOS",
"CRN_number":"454634645645654",
"VAT_name":"Wesam Alzahir",
"VAT_number":"301121971500003",
"location":{
"city":"Khobar",
"city_subdivision":"West",
"street":"King Fahahd st",
"plot_identification":"0000",
"building":"0000",
"postal_zone":"31952"
},
"branch_name":"My Branch Name",
"branch_industry":"Food",
"invoice_counter_number":"1",
"invoice_serial_number":"EGS1-886431145-1",
"issue_date":"2022-03-13",
"issue_time":"14:40:40",
"previous_invoice_hash":"NWZlY2ViNjZmZmM4NmYzOGQ5NTI3ODZjNmQ2OTZjNzljMmRiYzIzOWRkNGU5MWI0NjcyOWQ3M2EyN2ZiNTdlOQ==",
"line_items":[
{
"id":"1",
"name":"TEST NAME",
"quantity":5,
"tax_exclusive_price":10,
"VAT_percent":0.15,
"other_taxes":[
{
"percent_amount":1
}
],
"discounts":[
{
"amount":0,
"reason":"A discount"
},
{
"amount":0,
"reason":"A second discount"
}
]
}
]
}
Below is the xml generated from the sample json
cac:TaxTotal
<cbc:TaxAmount currencyID="SAR">57.50</cbc:TaxAmount>
cac:TaxSubtotal
<cbc:TaxableAmount currencyID="SAR">50.00</cbc:TaxableAmount>
<cbc:TaxAmount currencyID="SAR">7.50</cbc:TaxAmount>
cac:TaxCategory
<cbc:ID schemeAgencyID="6" schemeID="UN/ECE 5305">S</cbc:ID>
cbc:Percent15.00</cbc:Percent>
cac:TaxScheme
<cbc:ID schemeAgencyID="6" schemeID="UN/ECE 5153">VAT</cbc:ID>
</cac:TaxScheme>
</cac:TaxCategory>
</cac:TaxSubtotal>
cac:TaxSubtotal
<cbc:TaxableAmount currencyID="SAR">50.00</cbc:TaxableAmount>
<cbc:TaxAmount currencyID="SAR">50.00</cbc:TaxAmount>
cac:TaxCategory
<cbc:ID schemeAgencyID="6" schemeID="UN/ECE 5305">S</cbc:ID>
cbc:Percent100.00</cbc:Percent>
cac:TaxScheme
<cbc:ID schemeAgencyID="6" schemeID="UN/ECE 5153">VAT</cbc:ID>
</cac:TaxScheme>
</cac:TaxCategory>
</cac:TaxSubtotal>
</cac:TaxTotal>
cac:TaxTotal
<cbc:TaxAmount currencyID="SAR">57.50</cbc:TaxAmount>
</cac:TaxTotal>
cac:LegalMonetaryTotal
<cbc:LineExtensionAmount currencyID="SAR">50.00</cbc:LineExtensionAmount>
<cbc:TaxExclusiveAmount currencyID="SAR">50.00</cbc:TaxExclusiveAmount>
<cbc:TaxInclusiveAmount currencyID="SAR">107.5</cbc:TaxInclusiveAmount> ?? On what basic this value is coming
<cbc:AllowanceTotalAmount currencyID="SAR">0</cbc:AllowanceTotalAmount>
<cbc:PrepaidAmount currencyID="SAR">0</cbc:PrepaidAmount>
<cbc:PayableAmount currencyID="SAR">107.5</cbc:PayableAmount>--??
</cac:LegalMonetaryTotal>
cac:InvoiceLine
cbc:ID1</cbc:ID>
<cbc:InvoicedQuantity unitCode="PCE">5</cbc:InvoicedQuantity>
<cbc:LineExtensionAmount currencyID="SAR">50.00</cbc:LineExtensionAmount>
cac:TaxTotal
<cbc:TaxAmount currencyID="SAR">57.50</cbc:TaxAmount>
<cbc:RoundingAmount currencyID="SAR">107.50</cbc:RoundingAmount>     ????
</cac:TaxTotal>
cac:Item
cbc:NameTEST NAME</cbc:Name>
cac:ClassifiedTaxCategory
cbc:IDS</cbc:ID>
cbc:Percent15.00</cbc:Percent>
cac:TaxScheme
cbc:IDVAT</cbc:ID>
</cac:TaxScheme>
</cac:ClassifiedTaxCategory>
cac:ClassifiedTaxCategory
cbc:IDS</cbc:ID>
cbc:Percent100.00</cbc:Percent>
cac:TaxScheme
cbc:IDVAT</cbc:ID>
</cac:TaxScheme>
</cac:ClassifiedTaxCategory>
</cac:Item>
cac:Price
<cbc:PriceAmount currencyID="SAR">10</cbc:PriceAmount>
cac:AllowanceCharge
cbc:ChargeIndicatorfalse</cbc:ChargeIndicator>
cbc:AllowanceChargeReasonA discount</cbc:AllowanceChargeReason>
<cbc:Amount currencyID="SAR">0.00</cbc:Amount>
</cac:AllowanceCharge>
cac:AllowanceCharge
cbc:ChargeIndicatorfalse</cbc:ChargeIndicator>
cbc:AllowanceChargeReasonA second discount</cbc:AllowanceChargeReason>
<cbc:Amount currencyID="SAR">0.00</cbc:Amount>
</cac:AllowanceCharge>
</cac:Price>
</cac:InvoiceLine>
Correct me if I am wrong
I think there is miscalculation, I have mention the spots in bold in the above xml which show the miscalculation.
Kindly help me to understand on that basis the value 107.50 is calculated and what should be the value inside
cbc:RoundingAmount
     <cac:TaxTotal>
        <cbc:TaxAmount currencyID="SAR">57.50</cbc:TaxAmount>
        _**<cbc:RoundingAmount currencyID="SAR">??</cbc:RoundingAmount>**_     ????
    </cac:TaxTotal>

ok Got it .
The problem was with how we are passing the "percent_amount"
After passing 0(zero) to percent_amount in the object of other_taxes like below
"other_taxes":[
{
"percent_amount":0
}
]
I received an error from zatca response
"errorMessages": [
{
"type": "ERROR",
"code": "BR-O-08",
"category": "EN_16931",
"message": "In a VAT breakdown (BG-23) where the VAT category code (BT-118) is " Not subject to VAT" the VAT category taxable amount (BT-116) shall equal the sum of Invoice line net amounts (BT-131) minus the sum of Document level allowance amounts (BT-92) where the VAT category codes (BT-151, BT-95) are "Not subject to VAT".",
"status": "ERROR"
}
]
  When I removed the object itself like
   "other_taxes":[],

The invoice is getting reported with no calculation error.


Multiple controller views not appear for base view

Hi,
My Dashboard view has been created by multiple view controller views. How I can perform snapshot testing for such view. If I use baseviewcontroller then only base view appears, but there are 3 others subviews added to baseview from 3 others controllers. How to capture full dashboard snapshot at reference folder.

I think you can just capture your window or put your view in a window.


Include git alias to clean up local branches that are no longer on remote

A common workflow is to do the following:
Note: all references of "web ui" refers to either Github or Gitlab web sites. Everything listed can also be done using CLI but most people tend to use the web ii

(on web ui)

Create issue (issue-123)
From the issue create a branch (issue-123)

(laptop)

git pull will get the remote branch
Do your work, commit, push to remote branch

(on web ui)

merge back to master (or other active dev branch)

The problem is that on your laptop branch issue-123 still exists but is not required anymore as it doesn't exists on remote. To date this is a manual cleanup job that can become tedious when lots of issues and branches are created (especially with larger projects). Need ability to quickly and easily remove local branches that no longer exists locally.
Idea:

Create a git alias to handle this command

git branch -r | awk '{print $1}' | egrep -v -f /dev/fd/0 <(git branch -vv | grep origin) | awk '{print $1}' | xargs git branch -d

Source: https://coderwall.com/p/up1qma/git-remove-local-branches-not-on-remote

To create the git alias automatically see: https://www.reddit.com/r/git/comments/32s8fr/how_to_store_gitconfig_as_part_of_the_repository/ and https://stackoverflow.com/questions/18329621/how-to-store-a-git-config-as-part-of-the-repository

We could add this as an automatic function in the helper.sh so that it will always add the .gitshared file into the local .gitconfig file

[ ] Need to think of a name for this git alias. Some ideas: https://medium.com/better-programming/useful-configs-and-aliases-for-git-and-local-development-environments-b7a0822591a6

@rimblas @neilfernandez any recommendations for alias name for this functionality?

Prune?
But I wonder if it would be confused with git remote prune origin

@rimblas yea want to avoid prune as it'll conflict.

In Spanish "podar"? 😬


Inquiry About Minimum VRAM Requirement for ReLoRA Model Training

I recently came across your paper on "ReLoRA: Low-Rank Training for Efficient Neural Networks" but I'm unsure about the technical details, especially when it comes to hardware requirements. Could you provide some guidance on the minimum VRAM needed for implementing ReLoRA effectively?

If pre-training a 7B model, what type of graphics card with a large amount of gpu memory is probably needed?

Hi! Most of the experiments in the paper (including 1B) used 2x3090 or 8x4090 setup with 24Gb RAM on each GPU.
However, a more precise answer to this question would depend on your existing hardware setup and training hparams, such as model size, amount of data to train on, distributed type used (DDP vs FSDP vs DDP + TP), and others.
My rule of thumb recommendation for a 7B model is at least 4 or 8 nodes of 8xA100 and additional non-trivial code optimizations such as ZeRO stage 3 or tensor parallel to increase training efficiency. You can find ZeRO stage 1 and other some other optimizations in a non-stable dev branch of the repository. However, my practical recommendation to train 7B models using ReLoRA would be to reimplement ReLoRA in an existing LLM training framework such as GPT-NeoX or LLM Foundry. The current repository was not built to scale to more than 1B parameters + 20B tokens.


scripts/fix.sh in CI

This is probably a bad idea, we should do this like linting on pre-commit. See #50


Log httpd log_error to stderr

This patch set fixes issue #72.

LGTM

@ppisar nice patch :clap: ! Thanks! :)
@mfojtik the original issue was left open. BTW we need this for PHP and perhaps other httpd-based images as well...

Well, too late, but worth asking: could we get the tests for both image versions? (5.16 is missing)

On Wed, Mar 02, 2016 at 02:51:41PM -0800, Rodolfo Carvalho wrote:

Well, too late, but worth asking: could we get the tests for both image
versions? (5.16 is missing)

The 5.20 has different test "frame work". 5.16 tests are not extendable.
Actually the tests should be rewritten to something more suitable for testing
that supports nesting subtests, reporting failure reason, parallel testing
etc. E.g. Perl's Test::More. But I don't know if that were acceptable for
OpenShift. I've never seen what OpenShift test environment provides,
guarantees or expects.
-- Petr

Actually the tests should be rewritten to something more suitable for testing
that supports nesting subtests, reporting failure reason, parallel testing
etc.

I totally agree :+1:
The tests in this repository are OpenShift-agnostic, they require just docker.
However, we need to take a more holistic view when talking about a change like rewriting.
Historically, they started as a "common" "framework" that is generated by s2i create. That command creates a scaffolding for creating new S2I builder images.
Through the past year, when working on the builder images and trying to improve the tests, I was reminded to keep the consistency among the images we provide, which is good in one hand, but hard to maintain over time. And as you just pointed out, Perl tests for 5.16 and 5.20 went out of sync...
(and there is really another problem in there, copy-paste...)
IMHO Bash is great for short scripts, but is a very poor tool for writing the day-after-day more complex scripts that empower the images, and very poor for writing tests.
Even though Perl's Test::More is very cool, I doubt we have enough Perl know-how across the team to make it the "new language" for the scripts in all images.
Given what's in the base OS image, I'd say our choices are Bash, Perl, Python.

@rhcarvalho the tests also depend on s2i binary.

@rhcarvalho also as you said, few of us have confidence in perl or python or ruby to start writing tests for images. We do all do Go, but that leaves SCL folks out of loop because that is something they don't do. So even it sound silly, the "bash" is the only common framework we share currently :-) And I'm OK improving it or making the testing framework better.


csv files doesn't exist

I'v downloaded the data, but there is no csv file, can you give a simple instruction for it?
Thanks!

I have the same question...

I have the same question...

I'v downloaded the data, but there is no csv file, can you give a simple instruction for it?
Thanks!
I have the same problem, just change the data's file name suffix to CSV/TSV and try again

you can to generate the csv files and the augmented data

you can to generate the csv files and the augmented data

How to generate csv files?
Thanks!

just process the the datas the author uses，named the column as the code needs. and the code uses pandas to load it
label    text
1       xxxxxx
2       xxxxxx
and you can run the code if you use the vitural augment with this csv file.
if you want to use the augment the paper uses， u have to use the augment package.
---Original---
From: @.>
Date: Tue, Jan 18, 2022 10:42 AM
To: @.>;
Cc<EMAIL_ADDRESS>Subject: Re: [amazon-research/sccl] csv files doesn't exist (Issue #16)
you can to generate the csv files and the augmented data
How to generate csv files?
Thanks!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you authored the thread.Message ID: @.***>

Thanks for the detailed explanation, it helped me a lot! ^_^

FileNotFoundError: [Errno 2] No such file or directory: '$path-to-your-data/searchsnippets.csv'
No corresponding data found in the web address
There is no form of label-text , all of them label-label-text

Hello, I have a question about the details when generating .csv files:
How do you process the comma ',' in the text?
If you did not deleted these commas, how do you load the .csv files?


Make layer ids optional and make tile layer name optional (like object layers)

Follow-up for #111
Layer id defaults to 0 if missing, which is normally unused.
Tile layer name defaults to an empty String if missing, same as object layers.

I would lean towards a missing name meaning empty string since that's how Tiled represents it, but I could change it to an Option if you really want (would make this breaking).

It's alright, the no-name case is not common enough to consider. Merging then.


update CDH version to 4.6.0 to solve leak in DFSClient (HDFS-5671)

The socket leak in DFSInputStream will cause a Presto node to finally run out of socket buffer space and freeze. CDH 4.6.0 has included the patch for it.

Merged, thanks! Will update Presto to use this.