How to refresh the content in UI when validation fails?

[PropertyGridOptions(SortOrder = 14)]
public float RG { get; set; }=1; // positive integer
RG <----> txt.Text
When user typed -1 into  txt, an validation will return false. Then RG won't change to -1.
Is it possible to refresh the text("-1") to the correct value of RG when validation return false?

The only thing that's built-in is the user can do a CTRL-Z to revert to the original text. Other than that you would have to write a custom editor for this property/type of property. All that depends on how you want to do it in terms of UI/UX.

So each property needs a customized editor？

It depends how you want to do the "refresh the text" action. Is it automatic? when? Is it manual? how? All properties are not the same, some can be very custom types that have no concept of "text", etc. The whole thing is open source so you can always change its default behavior.
If you only want it on some properties, the easiest is to declare a custom editor (usually in app.xaml) and add it to PropertyGridOptions like the WebSite property in model.cs :
    [PropertyGridOptions(EditorDataTemplateResourceKey = "CustomEditor")]
    public string WebSite
    {
        get { return GetProperty<string>(); }
        set { SetProperty(value); }
    }

WOW... Thanks very much!


ace_mode documentation URL out of date?

I'm attempting to follow the documentation for adding a new language. It says:
https://github.com/github/linguist/blob/5c40ebba637fc2ef49d24148ab1b5844fe026399/lib/linguist/languages.yml#L9-L11
That URL http://git.io/3XO_Cg goes to https://github.com/ajaxorg/ace/tree/master/lib/ace/mode and I don't see anything in that directory listing that helps me understand the valid values for ace_mode.
Are the filenames you were wanting me to see the ones that were moved in https://github.com/ajaxorg/ace/commit/bd8581c77249fc5a35fb3726b6c7b9ad5a4eb3c9 to https://github.com/ajaxorg/ace/tree/master/src/mode? If so please update the URL in the documentation.

Are the filenames you were wanting me to see the ones that were moved in ajaxorg/ace@bd8581c to https://github.com/ajaxorg/ace/tree/master/src/mode? If so please update the URL in the documentation.

Yes. Fix coming in https://github.com/github/linguist/pull/6344


add consul provider.

#4

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

Thank you for the contribution! We will make sure to review this PR.


Dockerize godns and push it to the DockerHub registry

SSIA

We want to link this container to an actual resolver container.


Normalisation of the key-point residual loss for integration with PVNET

Hello @BoChenYS and @jonbakerfish ,
First of all, Thanks for publishing code for your insightful paper.
I am trying to train pvnet along with the loss function defined in you demoPoseEst.py. However, the loss is way too high in value compared to the other two losses in PVNET. I tried to normalise it by dividing it by Σ(y - y_mean)² where y is the batch of ground truth key_points and y_mean is the mean Keypoint.
Normalized RSS = RSS / Σ(y - y_mean)²
However, the value is still too high in the range of 1 to 100. Meanwhile other losses are less than 0.01 generally.
How do I solve this? Or is there any other way I can incorporate BPNP in Clean-Pvnet.
Thanks!

Okay, makes sense!
A constant coefficient would do?  Or is there an adaptive method to go about it?

Constant coefficients will do.

Thanks for the advice and swift response. @BoChenYS
I tried training the Clean-Pvnet model with a the loss multiplied by the constant coefficients.
However, after few steps the Bpnp loss increases from a magnitude in the range of 1 to 10 to 20k-40k. I have used the co-efficient to be 0.0001.
Due to this the overall loss results in either NaN or INF.
I tried different values of the coefficients but the same this persists. the gradient either exploded or vanishes.
# Key - point Voting Loss
        weight=batch['mask'][:, None].float()
        vote_loss=self.vote_crit(output['vertex'] * weight, batch['vertex'] * weight, reduction='sum')
        vote_loss = vote_loss / weight.sum() / batch['vertex'].size(1)
        loss += vote_loss

# Segmentation Loss
        mask = batch['mask'].long()
        seg_loss = self.seg_crit(output['seg'], mask)
        loss += seg_loss

        scalar_stats.update({'loss': loss})
        image_stats = {}

        kpt_2d_pd = output['kpt_2d']
        kpt_2d_gt = batch['kpt_2d']

# BPNP - Loss
        P_out = self.bpnp(kpt_2d_pd, self.Kpt_3D, self.K)
        pts2d_pro = BPnP.batch_project(P_out, self.Kpt_3D, self.K)
        loss_bpnp = ((pts2d_pro - kpt_2d_gt)**2).mean()  + ((pts2d_pro - kpt_2d_pd)**2).mean()
        loss += loss_bpnp*0.00002

I have added the function which calculates all the three losses. Any insights or conceptual errors would really help!
Thank you


jps: Watch blastgrit.com

jps requests the watch of the watch_keyword blastgrit\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

blastgrit\.com has been seen in 0 true positives, 0 false positives, and 0 NAAs.


[Event Request] Page 9092 "Approval FactBox" - procedure UpdateApprovalEntriesFromSourceRecord

Describe the request
procedure UpdateApprovalEntriesFromSourceRecord(SourceRecordID: RecordID)
var
    ApprovalEntry: Record "Approval Entry";
begin
    FilterGroup(2);
    SetRange("Record ID to Approve", SourceRecordID);
    ApprovalEntry.Copy(Rec);
    if ApprovalEntry.FindFirst() then
        SetFilter("Approver ID", '<>%1', ApprovalEntry."Sender ID");
    FilterGroup(0);
    OnUpdateApprovalEntriesOnAfterApprovalEntrySetFilter(ApprovalEntry); //CustPub
    if FindLast() then;
    CurrPage.Update(false);
end;

[IntegrationEvent(false, false)]
local procedure OnUpdateApprovalEntriesOnAfterApprovalEntrySetFilter(var ApprovalEntry: Record "Approval Entry") //CustPub
begin
end;

Additional context
Publisher request marked with //CustPub tag.
Internal work item: AB#494005

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: 14693.


Any possibility to share yml configuration file?

Is there any possibility to share the lutris configuration file for rhino?
It's awesome step by step guide, but into the folder "/home/username/.config/lutris/games" there is an ".yml" file called for example:
rhino-lotofnumbers.yml
In this file there are all configuration you've setted.
It will doesn't work if I download your file and copy paste it into this folder, because lutris set an ID (lotofnumbers)... so we have to create an empty new Game, open your yml file with text editor and copy paste all text into this empty file (and this method will work)
More easy to share and modify!
Thanks! Awesome work!!!

The idea is not bad! :+1:


Merge C and K commands

After aws removal we need only one set of command
Fixes https://github.com/ambiata/mismi/issues/160

:+1:

After streaming :boom:


MSID: 99990 Version: 1 DOI: 10.1101/2<IP_ADDRESS>1083

MSID: 99990
Version: 1
Preprint DOI: https://doi.org/10.1101/2<IP_ADDRESS>1083
Step 1. Awaiting reviews
Editorial to post reviews via hypothesis
Useful links:

DocMap: https://data-hub-api.elifesciences.org/enhanced-preprints/docmaps/v2/by-publisher/elife/get-by-manuscript-id?manuscript_id=99990
New model tracking: https://docs.google.com/spreadsheets/d/1_fHaoOy7hjyocptKtVJRijeNpUY4hBS7Ck_aVmx6ZJk/
Reviews on sciety: https://sciety.org/articles/activity/10.1101/2<IP_ADDRESS>1083

For trouble shooting (e.g. no Docmaps available):

DocMap issue addressing: https://miro.com/app/board/uXjVNCwK6EI=/
Explore DataHub DocMaps API: https://lookerstudio.google.com/reporting/4c2f0368-babb-4beb-b5b3-497e7e7b0f08/page/ejphD
Unmatched submissions and preprints: https://lookerstudio.google.com/u/0/reporting/9f86204f-3bf7-477c-9b18-5c5ef141bf69/page/p_gxi57ha93c
Unmatched manuscripts spreadsheet: https://docs.google.com/spreadsheets/d/15QcK8w-ssB7109RQEDtFpJPZ0J5HTGxoHa_2TtpMBbg/edit#gid=1336081641

Step 2. Preview reviewed preprint
Production QC content ahead of publication
Instructions:

QC preview: https://prod--epp.elifesciences.org/previews/99990v1
Update ticket with any problems (add blocked label)
When QC OK, add QC OK label to ticket and add publication date and time to https://docs.google.com/spreadsheets/d/1amAlKvdLcaDp5W8Z8g77NmkwbMF5n_u89ArSqPMO8jg
Move card to next column
(At end of the day post link in #enhanced-preprint and ask for PDF to be generated)

Useful links:

Preprint DOI :  https://doi.org/10.1101/2<IP_ADDRESS>1083
Confirm reviews returned by EPP: https://prod--epp.elifesciences.org/api/reviewed-preprints/99990/v1/reviews
To update the MECA path in the docmap: https://docs.google.com/spreadsheets/d/1mctCQuNFBjSn97Lihy7_vBO6z7-N-oqyLv4clyi6zHg

Step 3: Awaiting search reindex
This step adds the reviewed preprint to the homepage: https://elifesciences.org
The search reindex is triggered once an hour. We need the reviewed preprint to be indexed as the search application serves the journal homepage.
Useful links:

Jenkins pipeline to reindex search can be triggered sooner or monitored here: https://alfred.elifesciences.org/job/process/job/process-reindex-reviewed-preprints/

Step 4: Published! PDF requested
Waiting for PDF to be generated
Useful links:

PDF tracking: https://docs.google.com/spreadsheets/d/106_XeDjmuBae7gexOTNzg60lapeqjl2aRn9DzupGyS8/

Step 5: Introduce PDF to data folder and git repo
Upload PDF to relevent folder in git repo https://github.com/elifesciences/enhanced-preprints-data/
Step 6: Done!

[ ] Kettle is on!

warn: [mixed-citation-other-publication-flag] mixed-citation in reference (id=c15) has a publication-type='other'. Is that correct?
warn: [mixed-citation-other-publication-flag] mixed-citation in reference (id=c42) has a publication-type='other'. Is that correct?
warn: [mixed-citation-other-publication-flag] mixed-citation in reference (id=c52) has a publication-type='other'. Is that correct?
warn: [mixed-citation-other-publication-flag] mixed-citation in reference (id=c73) has a publication-type='other'. Is that correct?
error: [junk-character-presence-3] p element contains a junk character '□' which should be replaced or deleted.

Hi @acollings, author response heading doesn't appear to be formatted, please can this be fixed?

Hi @rkcook312 -- yes, of course! I've edited that.


Planetary projection fixes

Following up on #67, I tested the changes merged in #68 and found them to almost work, except that the private _geographic_crs attr wasn't properly initialized (apparently that has to happen manually in __init__). So I fixed that, and added two tests:

Create a Mars equivalent to the global web mercator TMS
Create a localized TMS centered around the Perseverance landing site

Thanks for your quick action on these suggestions. This is helpful for planetary scientists!

🥳 Woot thanks so much @davenquinn I'll cut a new release once the test pass


Logic: flawed logic in eruption_in_range() function (match.py)

The td_eruption_thresh_cross variable was compared to -0.15 hours instead of -0.25 hours (15 minutes, 1/4 of an hour).

Fixed in reporting branch.


fix(fetch): respect "abort" event on the request signal

This discussion pointed out that fetch request are not aborted if the user abort them using an AbortController.
This PR fixes it.

I've updated the tests a little, but what you wrote was really good. The abort controller tests now pass but I think we need to take a look at the test/modules/fetch/fetch-exception.test.ts to see if I got the original intention there wrong.
During my tests with Undici, network errors would result in a TypeError: Failed to fetch where the original thrown exception is set in the cause by Undici (I don't believe that happens in the browser). In other aspects, a network error also results in TypeError in the browser.
Here's the reference: https://github.com/nodejs/undici/blob/111fd2388094270259814ca7ea5da7d07b2126f6/lib/fetch/index.js#L227
Note that Unidici treats response (?) abort and network errors differently:
https://github.com/nodejs/undici/blob/111fd2388094270259814ca7ea5da7d07b2126f6/lib/fetch/index.js#L211-L221
Maybe we should do the same in the resolverResult.error handling.

@JesusTheHun, hi! The changes look great from my side, is there anything else we should consider before publishing this?

LGTM 👌 Now #398 😁💪

There's an issue with the automated releases in this repo, I will look into it and see if I can figure it out before releasing this. If I notice it taking much time, I will release manually but I'd pretty much love to solve the automation issue.

Released: v0.24.1 🎉
This has been released in v0.24.1!

📄 Release notes
📦 npm package

Make sure to always update to the latest version (npm i @mswjs/interceptors@latest) to get the newest features and bug fixes.

Predictable release automation by @ossjs/release.


Staxus matching based on first search result, but not right video

So, this one is pretty much Staxus' website and how it returns searches, but not sure how to resolve it.
The video is "Smooth toned body" and the file is named Smooth toned body.mp4 so there should be no issues.  This is the URL for the correct video.  http://staxus.com/trial/gallery.php?id=111
http://staxus.com/trial/search.php?st=advanced&qall=Smooth+toned+body&qany=&qex=&none=&tadded=0  Returns 3 matches where the first two have those terms inside the description, but not the clip name.  The scraper is matching to Foot wank and spunk session!! which as mentioned is the first search result.  http://staxus.com/trial/gallery.php?id=1505
Don't know if it's possible to make it work similar to some of the other scrapers where using the Fix Incorrect Match shows everything that the search found and lets the user pick.

I am a bit busy to trouble shoot code for adding new features. Just have enough time to do bugs. I will be free in two weeks.
You can try coding it yourself. Most of the code you are talking about is in helix studio agent. You will have to view the source code of Staxus site to find the correct location of the title, which is also already in the staxus agent. Just reply to here with a pull request. Make a fork of this project and I will verify it works in every situation and accept it or make slight modifications, and use this "Github desktop"
If you need help understand how to code this make a state transition diagram.


cherry-pick changes for build systems manually

I am going to close this in favor of #295
Will pick the changes in this PR up if we actually end up implementing the Ray runner for Acto in the future


Upgrade to WGPU 22

This currently doesn't pass the tests, I think because naga removed the PartialEq implementation on a bunch of types (https://github.com/gfx-rs/wgpu/pull/5818)

I haven't ran it locally, but the test output tends to change a bit on wgpu/naga upgrades.

I put up https://github.com/gfx-rs/wgpu/pull/6045 that will be backported and part of the 22.1 release.

Naga 22.1 has released with PartialEq back on types.

I've updated some failing tests - to me it looks like just the numbering in the error message is different

The test failures are assertions that were never hit before because they used #[cfg(debug)] instead of #[cfg(debug_assertions)]


fix the filter_groups keys non-string BUG

I met the same problem as issue #245, and I notice the fix. But the new 'filter_groups' stuff in commit d851c420019df6212d576f31301519cfb12104dc seems did nothing to it's non-string keys for 'tojson' function in the template/admin/model/list.html .
this is my PR based on the previous fix, hope you can find a better way to solve this, Thanks.

Looks like @torotil is also trying to fix this issue in #994.

@pawl I don't think this fix will make babel translations work: There is still the issue with _LazyString being non-hashable - so we can't use it as key for the BaseModelView._filter_group in the first place.


Only write 1 conformer for box packing?

Perhaps worth discussing: should packmol only write out 1 conformer for the components in a box? Relevant function: https://github.com/openforcefield/openff-interchange/blob/8d2cee156c8a6763fde0e1938809a96b688325da/openff/interchange/components/_packmol.py#L416-L441
I think I've tracked some differences I was seeing between box packing in a larger Evaluator workflow, vs when I tried packing separately, to a step where I was generating multiple conformers for the molecules in question. Using the same triethanolamine + water example as in #1106, I found that Packmol worked when the triethanolamine had only 1 conformer/PDB model written out, but did not when there were 8. The first conformers were the same in both cases.
Multiple conformers doesn't necessarily guarantee that Packmol will fail to pack. However, across 1412 test systems that worked with old Evaluator, 313 failed with error 173 with Interchange when multiple conformers are included. When only 1 conformer was generated, 1411 succeeded within 15 minutes. The last is still going, although I'm guessing that it might be stuck in a loop and eventually fail (which will take hours). Nevermind, the last one finished successfully in 25 min.
I think this is highly related to https://github.com/openforcefield/openff-interchange/issues/1062, which also runs a generate_conformers call with default arguments (i.e. n_conformers=10). Running the example failure in that issue again succeeded within 4 min when 1 conformer was generated. I'm also running another test with multiple conformers generated, but again I expect this to take hours to ultimately fail.

Reasons this might be a bad idea: I'm not sure how Packmol uses the multiple conformers. If it treats each as separate molecules, this would be a great way to place a molecule into a pre-equilibrated box of solvent. Writing out 1 conformer only would prevent this.
If Packmol tries to incorporate all structures into the solvent and the user wants to specify a specific mix of structures, this would also prevent that.
Instead, it might be sufficient to just have docs telling users not to carelessly pre-generate multiple conformers by default.

This is a funky surprise. I can't see any benefit to writing multiple conformers

Tag https://github.com/openforcefield/openff-toolkit/issues/1967

I have a somewhat naive fix merged in with #1111
In combination with #1106 it'd be nice to isolate failing tests which cause issues like #1062, but without needing to run MD in CI

Packing a box wouldn't necessitate running MD since you could just check the packmol output, but at the same time it would still be quite a slow test since I was seeing 4-10 minute times for the systems I was looking at (up to 25 min I think). If that's acceptable I have some systems that fail to pack with multiple confs but succeed with one, e.g. the one in #1106.
Thanks for the fix!

Runtimes on that scale is something I have been afraid of - it makes wonder if it's worth exploring other tools for this


Clarification on the way extends work

I have just found that there was extends added to theming which is awesome (My 6 themes would become much easier to support)
But I am not sure how it should work. There is a clause in theming-guide:
## Extends
....
Currently, the base theme is always loaded first.
Then, the files referenced by the extends key are loaded in order.
Finally, the keys in the current file are loaded.
Each time a theme is loaded, the keys are overlaid onto the keys from the previous theme.

Reading this I imagine it should apply MY basic-theme first then whatever it extends and then the current theme.
But in my case it doesn't work this way.
I have a basic-theme.yml in my themes folder and a sample file:
= Test Asciidoctor: Various stuff
:author: Maxim Kim

== test 1
привет

if no pdf-style is set up I expect it to use my basic-theme from my themes folder (I pass it to asciidoctor-pdf) -- asciidoctor-pdf tries to use default theme and fails

If I add a blank default-theme.yml to my themes folder -- asciidoctor clearly uses some other basic-theme as it fails to convert russian text due to lack of characters in supplied font which is set up on bundled themes (in my basic-theme I use different fonts).

If I add extends: basic to the default-theme.yml then everything works

So it kind of doesn't match to what documentation says or I misread it?
I end up making all my themes to extends: basic which I was thinking/reading you don't have to do.

When using extends, you almost always want to use a relative path like this:
extends: ./basic-theme.yml

That will relative relative to the current file.
The exception is if you want to extend a built-in theme, like base or default. Then, you just use the keyword:
extends: default

It's very important to be explicit since there are so many different paths involved, it makes it less confusing.

if no pdf-style is set up I expect it to use my basic-theme from my themes folder

How would it know this?
It should be:
asciidoctor-pdf -a pdf-themesdir=./themes -a pdf-theme=basic

Now, if you want to extend basic, then you would first make a theme named actual-theme.yml like:
extends: ./basic-theme.yml
base:
  font-color: 'ff0000'

Then you can load it like:
asciidoctor-pdf -a pdf-themesdir=./themes -a pdf-theme=actual

If there is no extends keyword, it implies extends: base. (You can force it to not extend anything using extends: ~.

When using extends, you almost always want to use a relative path like this:

Here it was not the case -- without any pdf-styles with only pdfstylesdir setup I was expecting that my base-theme would be loaded instead of built in. But it turns out that it tries to load default theme from this path instead of basic one
PS, non relative path works for me for extends: basic -- it uses my own theme from my path, but I will change it as you suggest just to be on the safer side.

without any pdf-styles with only pdfstylesdir setup I was expecting that my base-theme would be loaded instead of built in.

How does it know to load your theme if you don't specify pdf-theme (or pdf-style)?

without any pdf-styles with only pdfstylesdir setup I was expecting that my base-theme would be loaded instead of built in.

How does it know to load your theme if you don't specify pdf-theme (or pdf-style)?

Well it tries to load my default-theme from my path and I probably I misread the doc then :) thinking:

Currently, the base theme is always loaded first.

would also load base theme from my path.

Anyway, now it is clear for me that I don't have to have basic-theme, I need default-theme instead (that will be used if no pdf-style is provided to asciidoctor-pdf) and all other themes should extend default one.

would also load base theme from my path.

No, the special keywords "default" and "base" should always load from the gem. If it works otherwise, that is a bug.

I need default-theme instead (that will be used if no pdf-style is provided to asciidoctor-pdf) and all other themes should extend default one.

Please don't do this. I'm going to change Asciidoctor PDF so this doesn't work because that is not the intended behavior. It should either load the default theme from the gem or you should have to specify a theme to load.

would also load base theme from my path.

No, the special keywords "default" and "base" should always load from the gem. If it works otherwise, that is a bug.

Aha! I didn't know this is unexpected behavior and used it for quite some time :)

And I didn't realize that was working ;)

And I didn't realize that was working ;)

And for me it was quite expected behaviour :)
Anyway, will update my templates, thank you!

:+1:


Entity Directive

This Directive creates both: Dynamic Entity and Session Entity based on a generic structure, which depends on the platform.

There's still platform specific code in the shared functions


Demo doesn't work on Android 5.1.1

The provided demo APK just exhibits a static image, without any other action that uses the sensor.
The used device is a Moto G3.

@haskellcamargo Works fine here. Please inform your device too.

Same issue on 6.0 + Nexus 5 / 5x
Just changed SENSOR_DELAY_FASTEST to SENSOR_DELAY_GAME and it works fine.
[Issue] (https://code.google.com/p/android/issues/detail?id=189681&q=-has%3Amilestone attachments%3D1 label%3AType-Defect&colspec=ID Type Status Owner Summary Stars)

On Moto G3, it didn't work neither with SENSOR_DELAY_FASTEST nor SENSOR_DELAY_GAME.

Moto G3 doesn't have a gyroscope, right?
In that case, i think that Sensor.TYPE_ROTATION_VECTOR is the problem, could you try with Sensor.TYPE_GAME_ROTATION_VECTOR?

I've already done this. Neither of them work. Both fail with the same E/SensorManager: sensor or listener is null error.

can we make this work for lower android versions like kitkat.

same here.


bundix: add final newline patch, gemset*.nix: add final newline

Motivation for this change
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[x] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

cc @Mic92

I also merged the bundix pull request.

I also merged the bundix pull request.


Periodic article review

Consistent format of links (article-name.md rather than ../service-fabric/article-name.md)
More friendly tone ("communication listener" rather than code-style noun "CommunicationListener")

Hi @jessebenson, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

It looks like you're working at Microsoft (jesseb). If you're full-time, we DON'T require a contribution license agreement.

If you are a vendor, or work for Microsoft Open Technologies, DO please sign the electronic contribution license agreement. It will take 2 minutes and there's no faxing! https://cla.azure.com.

TTYL, AZPRBOT;


enhancing the buttons

What would you like to share?
Can I enhance the buttons in nav bar?

🥦 Browser
Google Chrome
Checklist ✅

[X] I checked and didn't find similar issue
[X] I have read the Contributing Guidelines
[X] I am participating in JWOC
[ ] I am participating in IWOC
[ ] I am willing to work on this issue (blank for no)

Hi there thanks for being willing to contribute however we are not looking forward to changing our theme as of now so we'll have to close this idea for now. There are more bugs and fixes that we can do on !


feat(Analysis/SpecialFunctions/Complex/Arg): add definition for slit plane and API, and use it

In preparation of future PRs dealing with estimates of the complex logarithm and its Taylor series, this introduces Complex.slitPlane for the set of complex numbers not on the closed negative real axis (in Analysis.SpecialFunctions.Complex.Arg), adds a bunch of API lemmas, and replaces hypotheses of the form 0 < x.re  ∨ x.im ≠ 0 by x ∈ slitPlane in several other files.
(We do not introduce a new file for that to avoid circular imports with Analysis.SpecialFunctions.Complex.Arg.)

I generalized the "star shaped" lemma and moved it to a new file. I also dropped in a lemma I wrote a few days ago but forgot to PR. Also, I added some lemmas and golfed proofs using ComplexOrder.

OK, nice. There is still a broken proof, though.

LGTM but I contributed too much to merge it myself. Thanks!
maintainer merge

Thanks :tada:
bors merge


[PE-D][Tester B] Find command returns incorrect results for n/ finds

Currently in CampusConnect, I have 3 individuals. Named Bon, Hans Bo and Bo Hans respectively. When I input the command find n/bo, I end up getting all 3 individuals. According to the User Guide, I should only expect Hans Bo and Bo Hans.
All contacts:

After running find n/bo:

Labels: severity.High type.FeatureFlaw
original: Vatinius/ped#16

Should I close this issue? It seems that the reviewer didn't read the UG carefully.

Ya close this mf dk what he saying


hw1-1.electricity.works went away around 7 PM 2023-01-27?

Almond log just reports many mqtt disconnect messages (1/minute), and doesn't connect. Ear is reporting nothing has been heard for an hour. Haven't checked orange yet. mosquitto_sub doesn't fail, but just seems to sit there. MQTT Explorer connect takes a long time then reports disconnected. gwd events show has last report at around 3PM.

When I cleared the dummy_ear_queue (which had something like 800,000 messages) everybody started talking again. Unfortunately I did not first go to the overview page to inspect memory, but it seems likely that the dummy_ear_queue had clogged up our memory.
queues are not meant to be long on rabbit. The dummy ear queue is just for debugging, so maybe we could leave it in with a short queue if we want to take the time to figure out how to do that. For now I am deleting that queue

Its interesting that gwd events show stopped at 3 pm but the ear didn't generate a nothing heard for the last hour until 7 pm. We should dig into that perhaps.


PhaseEstimation --> PhaseEstimationCircuit for clarity of functionality

Summary
Refactored PhaseEstimation component into PhaseEstimationCircuit affecting QPE and AE.
Details and comments
In order to avoid confusion, we now call PhaseEstimationCircuit the Aqua component creating the Phase Estimation Circuit reused by various algorithms (QPE, AE, HHL, etc.).

@pistoia quick question: was the intention to keep the filename phase_estimation.py as is or also change to phase_estimation_circuit.py?

@woodsp-ibm pointed out that the PhaseEstimationCircuit class has an extra field _ret that should've been removed when initially extracted from the QPE class.
@pistoia could you help with this in your next commit? thx!

Ok will do


Condition evaluation in Multi-stage YAML

If the first stage in a multistage pipeline has a condition that evaluates to false, the second stage will skip as well by default.  You must include condition: always() on the second stage to force it to run when the first stage is skipped for a condition evaluation.

This times a hundred. I've got a huge deployment pipeline that has jobs that should wait for the success of some dependent jobs but i would like them to run if the previous stage has been skipped. Now i need to add the condition: always() so they will get triggered.

Only one behavior here can be default, unless they add some sort of global config. Is always() really a more reasonable default than succeeded()? Maybe it is, but it's not obvious.

In my case:
Stage B is dependent on Stage A
If Stage A succeeds, Stage B is triggered
If Stage A fails, Stage B is not triggered
If Stage A is skipped, Stage B is not triggered. If I want it to be, i need to add always() to the conditions, then it will wait for Stage A but will run regardless of Stage A's outcome.

Only one behavior here can be default, unless they add some sort of global config. Is always() really a more reasonable default than succeeded()? Maybe it is, but it's not obvious.

Totally agree on that. I honestly would like to keep succeeded() as default, just because I don't want to handle conditions on every stage (or every job, and I have so many) that gets executed after the one that can be skipped.
What I really need in this scenario is either:

A new skipped() state that I can check with a custom condition on a later stage/job
A way to set the stage as succeeded() if skipped (using global config, a stage/job level decision or both)

Moved into Developer Community: https://developercommunity.visualstudio.com/content/problem/1007468/condition-evaluation-in-multi-stage-yaml.html
Please use "Follow" button on the right to track it

@TroySchmidt: Please go to this link and answer Microsoft team: https://developercommunity.visualstudio.com/content/problem/1007468/condition-evaluation-in-multi-stage-yaml.html


Have same margin for  as a  on .card-headers

Related #18726
When you use a <hN> as .card-header there is margin-bottom: .5rem added. The changes set the margin-bottom to 0

Merged this for now, but I may come back to revert this and similar changes in favor of margin utilities that can easily remove the margin-bottom for you.

Hey, @mkroeders & @mdo, given the default appearance seems to require zero margin, might it be preferable to just set all margins with margin: 0;?


Where do I put options zfs ?

Could you please clarify. Overview of the Boot Process says

After a boot environment is selected for boot (automatically or manually), load the selected kernel and initramfs, unmount all ZFS filesystems, and boot the system.

That sounds like setting zfs_arc_(min|max) via /etc/modprobe.d/zfs.conf and update-initramfs in the "root-on-zfs" OS should work. But it doesn't, not for me anyways. Also, the Readme here seems to imply the parameter should be set via zfsbootmenu KCL. Is that the only way it would work?

I believe setting them in a modprobe.d configuration file should work. Are you sure that you regenerates the initramfs for the kernel you're actually booting?
If you want to set this parameter on the command line instead, you can add it to the org.zfsbootmenu:commandline property. On the command line, the properties may have to be prefixed with zfs., e.g., zfs.zfs_arc_max.

Dracut will only add /etc/modprobe.d/*.conf files to an initramfs if you build in hostonly mode. Otherwise it always pulls in files from /lib/modprobe.d/*.conf regardless of the build mode.


fix: upgrade fetch polyfill to support large files

Following https://github.com/lucacasonato/deno_local_file_fetch/pull/10, files larger than 32kb were sometimes scrambled because the buffer wasn't copied and was overwritten
Upgrading to latest release should fix this issue and make large local files load correctly

blocked by #59


[#4386] ByteToMessage.decodeLast(...) should not call decode(...) if …

…buffer is empty.
Motivation:
If the input buffer is empty we should not have decodeLast(...) call decode(...) as the user may not expect this.
Modifications:

Not call decode(...) in decodeLast(...) if the input buffer is empty.
Add testcases.

Result:
decodeLast(...) will not call decode(...) if input buffer is empty.

@nmittler @Scottmitch @trustin PTAL

lgtm

@normanmaurer LGTM

@normanmaurer - Did you verify that HttpObjectDecoder is the only "child class" which requires a change? if so LGTM.

Yes I did

Am 29.02.2016 um 17:48 schrieb Scott Mitchell<EMAIL_ADDRESS>@normanmaurer - Did you verify that HttpObjectDecoder is the only "child class" which requires a change? if so LGTM.
—
Reply to this email directly or view it on GitHub.

Cherry-picked into 4.0 (d2d5bd5501e5b2ad91f5c835c8882d3a55495343) and 4.1 (9aac6dac2e934c7fdcca234607afbd2595b4aebe)


solved step 59 new js course

Checklist:

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the main branch of freeCodeCamp.
[x] I have tested these changes either locally on my machine, or GitPod.

Closes #48865

Welcome to FCC and thanks for trying to contribute. This doesn't appear to be correct though — it does not address the issue you linked.

What's wrong here can you explain to me more clearly

Well look at the expected behaviour, the issue is well documented. It's not clear at all what you're trying to achieve with your code change and how you came to the conclusion that it fixes the bug and not actually causes further problems.

HI @AnshPhirani !
This issue wants you to update the hint text.
Here is a quote from the original issue:

Expected behavior
The hint should say:
Your update function should set text.innerText to You are in the town square. You see a sign that says "Store".

Hope that clears up your confusion.

So in this string
You are in the town square. You see a sign that says \"Store\".
\"  is not an escape sequence ?

@AnshPhirani

" is not an escape sequence ?

The issue with your PR is that you have made changes to the wrong section.
This issue is about updating the hint text which is found in this section here

It also looks like another contributor starting working on this issue so you can take a look at what they did to better understand the issue
https://github.com/atnakayrus/freeCodeCamp/commit/78ca43575e9f4addb316dc5ce61c4f6c4de3e359
Hope that helps!

@jdwilkin4 I have created a new pull request
please review


Account re-use example?

Could you give an example of how to request a certificate using an existing account (rather than creating a new one)?

If you have your account key in DER, you may load it in to AcmeClient
using (var client = new AcmeClient(WellKnownServers.LetsEncrypt))
{
    var key = new KeyInfo { PrivateKeyInfo = Convert.FromBase64String("MIIEvgIBA...kmMx9v") };
    client.Use(key);

    // ...
 }

Check this test, which is reusing the account key.

Thank you!

You are welcome.
close #17


[CLEANUP] Standardize names #1

This is a first pass of standardizing names.
The first commit renames the fields in the st_key_buffer_t struct to match our current vocabulary:
typedef struct
{
    st_key_action_t * const data;        // array of keycodes
    const int               capacity;        // buffer size (TODO: rename to capacity)
    int                     size; // number of current keys in buffer (TODO: rename to size)
    int                     current_head;     // current head for circular access
} st_key_buffer_t;```

Each commit will contain all the renames that fall out from fixing the names in everything defined in that header.

The second commit is a big one, because I renamed everything in the python generator, which really touched everything.
@kamih  I'm going to stop here to let you take a look. I honestly don't think any more changes should be made in this PR, except possibly re-renaming things, if you disagree with anything.
The one last bit of unfinished business is that we have a couple different names for the "right" side of a rule used internally in the generator. Sometimes it is referred to as a "transform", "transformation", or "output". I'm the one who used the "output" naming originally, and I will get rid of it, but I want to refactor most of that code, so I don't want to rename it yet, so that it sticks out. "Transformations" is your code. And "transformations", being the noun form of "transforms" is probably the most correct name, but we have frequently been taking advantage of the ability to "noun a verb" and using "transform" as a noun, and that is shorter.


Map search bug fixes

IMPORTANT: Where possible all PRs must be linked to a Github issue
Fixes #3517
Fixes #3518
Engineer Checklist

[ ] I have written Unit tests for any new feature(s) and edge cases for bug fixes
[ ] I have added any strings visible on UI components to the strings.xml file
[ ] I have updated the  CHANGELOG.md file for any notable changes to the codebase
[ ] I have run ./gradlew spotlessApply and ./gradlew spotlessCheck to check my code follows the project's style guide
[ ] I have built and run the FHIRCore app to verify my change fixes the issue and/or does not break the app
[ ] I have checked that this PR does NOT introduce breaking changes that require an update to Content and/or Configs? If it does add a sample here or a link to exactly what changes need to be made to the content.

Code Reviewer Checklist

[ ] I have verified Unit tests have been written for any new feature(s) and edge cases
[ ] I have verified any strings visible on UI components are in the strings.xml file
[ ] I have verifed the CHANGELOG.md file has any notable changes to the codebase
[ ] I have verified the solution has been implemented in a configurable and generic way for reuseable components
[ ] I have built and run the FHIRCore app to verify the change fixes the issue and/or does not break the app

@dubdabasoduba do we need a unit test for this?


Change volume repository to use media router

This is for conversation for now. I believe that we need to move the volume repository to the media router too, in order to support non-system routes in the future. The api is a bit different though:

no minimum volume, I'm assuming 0 is min
no mute state
the volume adjustment is based on a delta int, not sure if 1/-1 is the right way here, or a fixed size increment based on max is more appropriate

There's also a few interesting behaviours observed:

The media router doesn't update its volume state immediately, but the new volume is returned with a callback. This is different from how the implementation using the AudioManager is, and currently breaks the tests
Running an app that's playing audio on bluetooth and then running another app that changes the route to the speaker doesn't affect the playing app. This makes sense to me, it's the route for the other app that's changed. However, when updating volume on the speaker route on the non-playing app the bluetooth volume is the changed one. I guess this is a matter of what app has audio focus, but I would at least expect the volume API not to work, not for it to change the incorrect device. This would have to be investigated further.

Let me know if you have any thoughts on the above, or the code

 com.google.android.horologist.audio.SystemAudioRepositoryTest > testVolumeRepository[test(AVD) - 9] FAILED
	expected to be greater than: 11
	but was                    : 11
Tests on test(AVD) - 9 failed: There was 1 failure(s).


appDetails Needs HTTPS to work

Hi, I tried the appDetails() method and got "connecttion reset by peers" response from cURL, then I tried to set the HTTP request to HTTPS and it works out. It seems that steam require this API to be HTTPS only now.

Strange. But no reason not to use HTTPS afaik.

Strange. But no reason not to use HTTPS afaik.


UF-8560: Adjusted API tests

Modified API success tests to use Spring WebTestClient
Replaced old validation tests with API failure tests using Spring WebTestClient
Extracted mapping logic from resource classes to mapper class
Updated documentation for API resources that throws bad request
Updated to latest version of Dept-44

Fixed review comments


Move compiler_stub to intrinsiclib

Fix: #1354
Signed-off-by: Wenxing Hou<EMAIL_ADDRESS>

Have you tested AARCH64 (ARM_DS2022, ARM_GNU, ARM_GCC) ?


sig_failover test: Reply caching on startup of test topology is problematic

sciond and the PS cache replies they got from remote server for a certain amount of time (5min configurable). During the startup of the test topology it might be that no all paths are yet registered. If some paths are taken down, it could be that connectivity is lost.
For example in build https://buildkite.com/scionproto/acceptance/builds/365#96eaca46-463a-49df-99c0-bead1f3cd73c
The path via br2 is initially registered and cached. Then sciond doesn't receive a revocation therefore it never hands out a new path, just the broken cached one.

This also applies to the path manager.
The path manager does not receive a revocation, thus it will not bother querying sciond for new paths.

also see https://github.com/scionproto/scion/issues/1390


Slime boss and VQ search

Preliminary search terms to use for the new blob boss and Susan refs
Thanks to fragile and Joshie

Thanks for the PRs!


anchor-based permalink should not erase the query string

Problem: When using an address with a query string and a Permalink
with useAnchor=true, the href of the Permalink does not contain the
query string of the current location.
This behavior is correct when the Permalink has useAnchor=false. See
commit 9d708a24938d778ffb2e3d445b4804e6e9056c55.

Thx for the patch :)


Where is the Swarm Master?

I created a swarm environment with 2 nodes.
I don't see any concept of a Swarm master node and there no mention of this concept in the docs - http://docs.rancher.com/rancher/latest/en/swarm/
I just want to be clear. When the Docker CLI will work (issue here), I expect the CLI to talk to my Swarm Master Host. Make sense?
Is Swarm master install on the Rancher Server?
EDIT: At the moment, the only container running on the Rancher Server host is rancher/server.
Cheers!
https://twitter.com/_pascalandy

I'm just reading up about swarm now and would you be able to point out the concept of this swarm master in the swarm docs itself?

@deniseschannon:

I'm just reading up about swarm now and would you be able to point out the concept of this swarm master in the swarm docs itself?

See https://docs.docker.com/swarm/install-manual/#step-5-create-swarm-cluster - "Swarm master" appears to be a deprecated term, in favor of "primary manager," but the question is the same. I think it would be helpful to clarify in the Rancher documentation how the Swarm created by Rancher is configured. In addition, there's the concept of "replica" masters that could optionally be created in the swarm for a high-availability setup, and that may be helpful for Rancher to support in the future.
At a minimum, though, I think it would be good to improve the README on rancher/swarm-agent to explain how these containers work. It doesn't appear to follow the Docker Swarm docs on setting up a swarm, since if you go to the host running the agent containers and do a docker info, none of the Node data is shown. However, clicking the "CLI" tab in the web UI gives you a terminal in the swarm-agent container not running the manage command. Running docker info in that container reveals the nodes.
So if I can re-phrase the question, what is the purpose of the two swarm-agent containers that get created, and how do they differ in function?

+1 NOTE: I am trying to introduce Rancher into the company I work for, and here is the use case I am presented with:
My boss wants a way to ssh into the swarm (manager, master, etc) and query the swarm cluster directly, like he was able to do when he setup the swarm cluster himself... (before I came along and messed up his world).

There is a big update with docker 1.12 that supports natively Swarm.
root@pi6 $ docker swarm
Usage:  docker swarm COMMAND
Manage Docker Swarm
Options:
--help   Print usage
Commands:
init        Initialize a Swarm.
join        Join a Swarm as a node and/or manager.
update      update the Swarm.
leave       Leave a Swarm.
inspect     Inspect the Swarm
Run 'docker swarm COMMAND --help' for more information on a command.
I can understand how hard is it for Rancher's team to follow along.

Thanks @pascalandy - I bet it is very hard to keep up with the Docker releases. However since Docker 1.12 is only a Release Candidate, I wouldn't expect the Rancher team to have already been working on that integration yet. Especially since 1.12 RC1 and RC2 both seem to have been released in the future (2016-07-14) - thats very hard to keep up with...

@todd-alexion I was just at Dockercon and after talking to the Rancher folks at their booth, it sounds like they will work with the 1.12 Swarm features as they roll out, but it indeed is still RC and probably needs to bake a while before rolling into production.
At the moment, though, you can get a CLI at the swarm master inside the web UI (Swarm > CLI) and you'll see the container ID as the hostname in the shell. Admittedly the web shell isn't always enjoyable to use, but that's how to do it, now.
Theoretically you can also set DOCKER_HOST and use some self-signed keys at a remote node, but #4145 seems to be an issue for myself and others when using that generated config.

@bradjones1 Thanks for the info. The Rancher folks have always been very responsive, so I am not worried. However in this case, that Rancher Swarm CLI really is lacking as a drop in replacement for the guys at my company. I will wait, or experiment with rolling my own cluster.
And yes, I saw that #4145 was still open...

@todd-alexion You can always SSH to the node the manager is running on, and exec in. But yes, it's not particularly straightforward, and 1.12 will make a lot of these issues less pressing.

@pascalandy Please re-open if you have further questions.
@bradjones1 @todd-alexion Yes, we plan on supporting what's in 1.12 when it's officially released.


added  new link

as per user report #3012, so i added correct link.

Docs Build status updates of commit 548d01e:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docset/winserver2022-ps/international/New-WinUserLanguageList.md
:white_check_mark:Succeeded
View (WindowsServer2022-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit 404855e:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docset/winserver2022-ps/international/New-WinUserLanguageList.md
:white_check_mark:Succeeded
View (WindowsServer2022-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Hello @RAJU2529
I am not sure about linking a SharePoint 2010 article from a Windows Server one, was that link the original destination of the now broken link?
@tseward @dariomws thoughts?

Docs Build status updates of commit 2dd154d:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docset/winserver2022-ps/international/New-WinUserLanguageList.md
:white_check_mark:Succeeded
View (WindowsServer2022-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

I would agree, I don't think this is the intended link. The SharePoint article itself contains many broken links, as well.

We appreciate any feedback that improves the content in the Microsoft docs but we haven't had any response from you so we are going to close this issue.
Please feel free to re-open this issue if there is a specific area of the docs that we can improve or make better. Thank you.


CI/CD Jobs failing on all projects starting last week at some point.

I'm getting the following error and warnings on several AL-Go projects starting at some point last week while out of the office.  So far, it appears that only the CICD workflows are impacted.  Other workflows such as UpdateGitHubGoSystemFiles work just fine.

CI/CD GitHub Actions has encountered an internal error when running your job.
InitializationSkip output 'environmentsMatrixJson' since it may contain secret.
InitializationSkip output 'deploymentEnvironmentsJson' since it may contain secret.
InitializationSkip output 'projectDependenciesJson' since it may contain secret.
InitializationSkip output 'buildOrderJson' since it may contain secret.

I am assuming this is related to an AL-Go update since it impacted numerous projects within the same timeframe.

Appears similar to #1039
logs_23018261293.zip
In the Initialization / Complete Job step, I see the following warnings that are not easily seen in the logs.
Evaluate and set job outputs
Set output 'telemetryScopeJson'
Warning: Skip output 'environmentsMatrixJson' since it may contain secret.
Set output 'environmentCount'
Warning: Skip output 'deploymentEnvironmentsJson' since it may contain secret.
Set output 'generateALDocArtifact'
Set output 'deployALDocArtifact'
Set output 'deliveryTargetsJson'
Set output 'githubRunner'
Set output 'githubRunnerShell'
Set output 'projects'
Warning: Skip output 'projectDependenciesJson' since it may contain secret.
Warning: Skip output 'buildOrderJson' since it may contain secret.
Set output 'workflowDepth'
Cleaning up orphan processes

It appears that having any secret with "pretty" Azure credentials in GitHub, even secret names not used by AL-Go, will cause CICD to fail.
We recently added a secret related to other projects, and that is what broke CICD.  Using the Troubleshooting workflow was a tremendous help to discover why this was happening.  Our IT staff will follow up on the original #1039 issue.

It appears that having any secret with "pretty" Azure credentials in GitHub, even secret names not used by AL-Go, will cause CICD to fail.
We recently added a secret related to other projects, and that is what broke CICD. Using the Troubleshooting workflow was a tremendous help to discover why this was happening. Our IT staff will follow up on the original #1039 issue.

In general, AL-Go projects should only have secrets available to them that they need/use - but yes, the way we retrieve secrets, we are subject to this problem.


[summary] Info-Theory-Traceability

Time: 13:00 -14:00
Purpose:  To discuss results and organization of the paper in information theory for traceability
Attendees: Denys Poshyvanyk, Kevin moran, and David Nader
Summary: In the meeting, it was introduced the importance of having a robust statistical method based on information theory to analyze traceability data. Usually, Software Researchers have been focusing only on evaluating models or algorithms to assess the effectiveness of traceability techniques, paying little attention to the data performance. However, using information transmission analysis on software artifacts allow us to identify inconsistencies or imbalances in the traceability data.  We hypothesized that using standard Neural Unsupervised approaches, which captures concepts or semantic entities from artifacts, might not generate reliable trace-links.  This research proposes a robust data science methodology to be employed in future empirical research for software traceability evaluations.
Main Discussion Points:

David made a quick recap of Information Theory for the analysis of traceability datasets. He states that information metrics can be measured for all text-based documents and they give us an idea to what extent a corpus is good enough for traceability. If the mutual information levels are low, then recovering a trace link would be more difficult than recovering with a high level of mutual information.  Neural unsupervised techniques are based on data compression. If the pattern does not exist, then the link cannot be established.
Kevin mentioned two key aspects to enhance the research evaluation: 1) introducing a statistical analysis where all possible correlations among information measures and traceability effectiveness are exhibit and contextualized. The idea of this part of the evaluation is to show how the information theory measures complement the accuracy analysis of traceability algorithms. And 2) after observing how information measures behave under certain conditions, we are able to introduce some type of prescriptive info-traceability guidelines to inspect the traceability process. For example, if we observe that source and target artifacts are extremely imbalanced in terms of information content, then we can affirm that there is no traceability algorithm that can create reliable links until the information is balanced.  We want to introduce some qualitative analysis on specific SE case studies.
Denys highlighted the fact that we need to position this research as an approach rather than an empirical study since we are not actively making interventions on the datasets. However, we must find a way of defending the statistical methodology by showing how useful could be with concrete cases.

Open Questions and Action Items:

[ ] What would be exactly the research questions that will link correlation analysis of entropy and the effectiveness of traceability algorithms?
[ ] Organize a first draft of the paper with Kevin's recommendations for the evaluation section
[ ] Check out recent traceability research that we should consider for this research
[ ] Check out robust statistical methods and how they were introduced in software empirical analysis (i.e., Kitchenham )

Hi David, thanks for this summary. I think the most important thing to emphasize from the meeting is measuring, quantitatively, how well these information theory measures predict traceability performance. Then for certain patterns that we observe, we can prescribe some recoomendations. Just wanted to say this in my own words so I didn't forget my line of thinking ;-)

Paper writing task

[ ] Related work review and update
[ ] Explain the methodology - empirical design [David]
[ ] Show why to use descriptive, predictive, and causal inference for info-transmission [David]
[ ] Organize results as a summary excel
[ ] Organize benchmarking results and identify special cases
[ ] Benchmarking examples identification and explanation
[ ] Define what is a benchmark
[ ]

Tasks Week 7.13.2021 @danielrcardenas

[ ] Where are the boxplots?
[ ] Answer Research Question with Results supported on real data (boxplots)
[ ] Organize Case Studies (e.g., orphan links, min-max loss, min-max noise, etc)

Please Edit this in overleaf


Secrets page does not mention the role of fsGroup

The https://kubernetes.io/docs/concepts/configuration/secret/ page does not explain how the securityContext.fsGroup config impacts the file system permissions on mounted Secret volumes. Specifically, it appears that the group is set and read access is granted to that group. This can cause undesirable situations with files that are expected to be readable only by the owner (not by the group), and are therefore ignored.
It's unclear if there's any way to work around this situation, if fsGroup is in use. Other than perhaps copying the mounted secret file into another file, and running chmod on that copy...?
It would be helpful to mention this in the documentation about the "defaultMode" field of Secret volumes. And if there is any workaround, that would be helpful to know about too.

/language en
/kind support
/sig docs


Upgrading to 2023.11.0 Breaks Publishing

Describe the bug
It appears that after upgrading from 2023.08.0 to 2023.11.0, MQTT publishing stopped working. Downgrading to 2023.08.0 restores previous behavior.
To Reproduce
verbose: false
precision: 2
gateways:
  # GW2000B
  42B109437ED4E644FFF2DF549A1A0DAB:
    hass_entity_id_prefix: ecowitt_gw2000b
  # GW1100B
  55585D938764215B37D52CA7AD96E8F9:
    hass_entity_id_prefix: ecowitt_gw1100b

Environment variables:
  - name: ECOWITT2MQTT_MQTT_BROKER
    value: mqtt
  - name: ECOWITT2MQTT_MQTT_PORT
    value: "1883"
  - name: ECOWITT2MQTT_HASS_DISCOVERY
    value: "true"
  - name: ECOWITT2MQTT_PORT
    value: "8080"
  - name: ECOWITT2MQTT_CONFIG
    value: /config.yaml

Expected behavior
MQTT messages continue to publish.
Additional context
Logs similar to the following can be found:
2023-11-05 16:50:28,652 | WARNING | There are 444 pending publish calls.

ecowitt2mqtt.log

I'll need more info on what "breaks publishing" means. I'm running 2023.11.0 and my gateway continues to publish.

@bachya not sure what info I can provide - HA defined the MQTT device as unavailable. I'm assuming all MQTT communication stopped (from the the log that MQTT calls were starting the queue up). My MQTT broker, Emqx (running in high availability mode), didn't note any issues.

Okay—I'll dig in and see what I can find.

Yeah, sorry, I'm notoriously bad at debugging MQTT communication.
Looking at the broker though, I do see ecowitt2mqtt connected to a broker node - just nothing appears to be published. The client stays connected though.
I double checked HA, no new devices appear (was looking to see if ids changed or something).
So the only thing that I can see out of whack is that warning There are X pending publish calls, which I'm guessing is coming from aiomqtt - which was upgraded. So my guess is that aiomqtt changed something.

No worries! 👍🏻 Are you using the Docker image?

Yep!
bachya/ecowitt2mqtt:2023.11.0

Having trouble reproducing this locally. I spun up a new instance of the 2023.11.0 image and published a 40-sensor payload 10 times in rapid succession and never saw this warning. I can see where this arises in aiomqtt:
https://github.com/sbtinstruments/aiomqtt/blob/019bc26af79209dc45d86b6ff0fd0dd8a2e199d8/aiomqtt/client.py#L885-L886
...but nothing about that has changed from 2023.08.0 to 2023.11.0.

Silvenga might not be the only one. I did experience the same/something similar after updating to 2023.11.0 via pip install upgrade. I have Mosquitto as a MQTT-broker, also not experienced in MQTT-communication. Downgrading back to 2023.08.0 resolved it back to normal. I use Domoticz. Since I quickly went back to the old version I am not able now to give logs that provide more info, it is just that the sensors in Domoticz did not update anymore after the upgrade.

I upgraded to 2023.11.0 and have the same issue: after a while sensors go to unavailable state and never recover. I'll dig deeper, but reverting to previous version for now. I think it's the changes to MQTT Discovery that had a negative impact. Will provide more info...

First thing I noticed: sensors in autodiscovery topic are missing the config topic.

I restarted the container and finally I see the config topic:

And sensors in HA are finally available again:

@alexdelprete Curious. To make sure I understand:

When you first upgraded the container, the config topic was empty.
When you restarted the container again, the config topic suddenly had data.

Is that correct?

Is that correct?

Yesterday I upgraded, was doing maintenance on HA components/integrations, after 1h I found out all entities were unavailable. I checked MQTT and found that config topic was missing, I restarted the container and everything was set. I thought it was just me messing too much with HA restarts.
This morning (15h after) I found that entities were unavailable again, I might have restarted HA because of an upgrade to a component in that time-frame. So I checked the repo for issues and I wrote about my experience.
When entities go unavailable, the only way to recover is to restart the container, but I don't know why it happens, I'm sure it's due to the missing config topic in autodiscovery, and since I don't believe in coincidences, I thought the latest fix to autodiscovery might have caused this.
Plus, in the log I'm seeing those pending publish calls...I don't remember seeing those before.

@bachya Restarted HA 15m ago for upgrades, and it happened again: entities unavailable and missing config topic in mqtt.

I restarted the container, and after 60s entities were back online. Then after some minutes, they went unavailable again, without me doing any activity on HA (no restarts etc.):

I'll revert to previous version until the bug is corrected.

Thanks, @alexdelprete. That definitely is a bug (and may be the real issue, vs. the pending calls warnings).

@bachya Happened again last night. I just discovered when I came back home. It stopped around 3am, and now I checked MQTT and not only there were no config topics again, but there was not the root topic (the one with the big s/n of the device. Obviously I'm on 11.1. I guess there's something else that causes this.
I was thinking to enable the retain flag option, what do you suggest?

Interesting. @Silvenga Are you experiencing this after upgrading, too?

Interesting

I enabled retain now. Let's see what happens...

Sorry @bachya, been away. I just deployed 2023.11.1 to my cluster and it looks much happier - I'm seeing updates published at the expected interval - no more pending calls warning messages. (😹 Woot! Thanks!)
I'll continue to monitor for behavior that @alexdelprete reported.

@bachya I can confirm the behavior @alexdelprete reported on my cluster (occurred about 2 hours ago). The topic in MQTT is no-longer present and HA considers the device off-line. No errors are reported by the container. Restarting the container (same image) restores the MQTT topic.

Thanks for the confirmation, @Silvenga.

I can confirm the behavior @alexdelprete reported on my cluster

Retain flag option seems to help here. But I see it as a workaround for this specific issue.

I've done some digging and have found one scenario in which I can consistently replicate this: when ecowitt2mqtt loses connection to the MQTT broker for some reason (the broker going down, network issues, etc.) and the broker hasn't set retain.
Here's what happens:

ecowitt2mqtt starts up.
When the first payload arrives, it connects to the MQTT broker and publishes the payload.
ecowitt2mqtt detects that it hasn't sent MQTT Discovery info before, so it does; this creates the config topic + underlying data.
In this scenario, at some point, ecowitt2mqtt loses connection to the MQTT broker. Without retain set, this effectively wipes all ecowitt2mqtt data from the broker's memory.
ecowitt2mqtt reconnects.
Another payload arrives. Because ecowitt2mqtt has been running this whole time, it sees this payload and says, "I've already published config info for these entities, so I won't do it again." This means that it fails to republish the config topic.

So, although retain is a bit more than a workaround (broaching "reasonable solution"), I don't want to force a personal configuration on every user. To address this, I need to republish the config topic when an MQTT broker reconnect happens.

Okay, I think #777 should fix this. @alexdelprete and @Silvenga, if you are Docker users, I'd appreciate your testing once the images build (you'll be able to pull ghcr.io/bachya/ecowitt2mqtt:pr-777).

Sorry for the delay Aaron, just installed pr-777, I disabled retain and also deleted all existing topics in the broker so to start in a clean state.
It's working for now, I'll monitor it and let you know how it behaves.

ecowitt2mqtt reconnects.
Another payload arrives. Because ecowitt2mqtt has been running this whole time, it sees this payload and says, "I've already published config info for these entities, so I won't do it again." This means that it fails to republish the config topic.

So, although retain is a bit more than a workaround (broaching "reasonable solution"), I don't want to force a personal configuration on every user. To address this, I need to republish the config topic when an MQTT broker reconnect happens.

On connect/reconnect it is mandatory that config has to be republished. You can't assume config is retained
In any case, I think for this use-case retain is the best configuration, if the broker supports it.

@Silvenga @alexdelprete Checking in—how are things looking?

@Silvenga @alexdelprete Checking in—how are things looking?

No issues at all, these 3 days (where before it would break at least daily). I'm thinking your latest fix effectively solved the root problem!
Thanks again!

how are things looking?

Not good, it has been down (no config) for 22h and I just found out, I was away for a couple of days:

@alexdelprete Can you verify that you're using the right image? I've been running #777 for three days, as well, and all looks good; curious what your outlier might be.

Can you verify that you're using the right image?

Can you also confirm that your MQTT broker is running and ecowitt2mqtt is connected to it?

EMQX broker is a critical service in my homelab, many automations depend on it, so I closely monitor it. No unplanned downtime in latest 30 days (I upgraded it, that's why it's only 99.92% up):

Can't tell you if ecowitt2mqtt was connected, I restarted the container to solve the issue.

@alexdelprete Appreciate that. I'd recommend letting this new restart run, and as best you can, try to tell when it fails (if it fails again). Ideally, you'd have verbose logging on and we could look at the logs during that time.

Ideally, you'd have verbose logging on and we could look at the logs during that time.

If you check the screenshot of my docker compose file, verbose is on.
Does the old log get overwritten when restarting the container or can I check yesterday's events if possible?

Does the old log get overwritten when restarting the container or can I check yesterday's events if possible?

That's up to your Docker configuration: https://sematext.com/blog/docker-logs-location/

That's up to your Docker configuration: https://sematext.com/blog/docker-logs-location/

it's journald. unfortunately it rotated, last event was 5-6h AFTER the issue that caused the unavailability.
Meanwhile I'm very tempted to turn retain on again...
BTW: sematext is interesting...will check it tomorrow.

@alexdelprete Checking in: any news?

Checking in: any news?

Yes, bad news: happened 11h ago. But I got the log this time (from journald), it stopped at 14.17.00, I cut the log from 14.10.00 to 14.30.00. Find it attached, hope it helps.
ecowitt2mqtt-log.zip

Tagging on to this. Just upgraded to image pr-777 and have ECOWITT2MQTT_DIAGNOSTICS enabled.
I've noticed mine failing when HA gets rebooted. My Eclipse Mosquitto (2.0.18) has been up for 24 days, and I've had 3 ecowitt2mqtt failures in the past two weeks which seem to coincide with HA reboots.

@JvdMaat Let me know whether pr-777 resolves the issue.

BTW: I checked how weatherflow2mqtt manages the config topic, and surprise suprise:

Excellent troubleshooting, @alexdelprete! Much appreciated, and agreed: that sounds like the right approach. Glad to see validation from weatherflow2mqtt. I'll update #777 and once a new image builds, would love for you (and any other Docker users monitoring this thread) to test.

Excellent troubleshooting, @alexdelprete! Much appreciated, and agreed: that sounds like the right approach.

sorry for not doing the analysis before, it only took 30m actually to understand the problem, but last time I had other things going on and I simply said there was an issue, but didn't do proper troubleshooting. We could have saved a couple of weeks. :)

I'll update #777 and once a new image builds

so I'll pull again with same tag pr-777?

Excellent troubleshooting, @alexdelprete! Much appreciated, and agreed: that sounds like the right approach.

sorry for not doing the analysis before, it only took 30m actually to understand the problem, but last time I had other things going on and I simply said there was an issue, but didn't do proper troubleshooting. We could have saved a couple of weeks. :)

No apologies! We got there in the end; that's all that matters. 👍🏻

I'll update #777 and once a new image builds

so I'll pull again with same tag pr-777?

That's correct.

Looks like the images are done building: https://github.com/bachya/ecowitt2mqtt/pkgs/container/ecowitt2mqtt/150063299?tag=pr-777
@alexdelprete, @Silvenga, @JvdMaat, and any other Docker users: appreciate you testing.

Already pulled the new one 2 minutes ago. Will keep you posted

Deployed ghcr.io/bachya/ecowitt2mqtt@sha256:cdc9ad7bef62b50c3504eafdacf8f62ca2a5bba7aedb8025d2be60a55d8df1b2 to my cluster. Will report any issues!

Pulled it now. Will test and report back.

Uptime Kuma just lost connection to ecowitt2mqtt (It can no longer open port 8080. Heartbeat is set to 1 minute with 20 second retries. So it's been unavailable for 10 minutes now)
Looking at the docker console log, it is still doing something. It seems to push to HA once a minute. Here's a filtered log (removed most of the posting spam) (It just came back up while creating this post after being down 15 minutes)

2023-11-21 16:22:41,426 | DEBUG | Calculator found for interval: <ecowitt2mqtt.helpers.calculator.time.UpdateIntervalCalculator object at 0x7efd1608e650> (key: interval, value: 16.0)
2023-11-21 16:22:41,427 | DEBUG | Relative Strain Index is only valid for temperatures above 26°C and below 35°C
2023-11-21 16:22:41,427 | DEBUG | Relative Strain Index is only valid for temperatures above 26°C and below 35°C
2023-11-21 16:22:41,427 | DEBUG | Safe exposure only valid for non-zero UV indices (current: {'runtime': 182977.0, 'tempin': 69.1, 'humidityin': 52.0, 'baromrel': 30.434, 'baromabs': 30.144, SNIP
2023-11-21 16:22:41,429 | DEBUG | Wind Chill Temperature is only defined for temperatures at or below 50 F and wind speeds above 3 mph. (current temperature: 35.2, current wind speed: 0.0)
2023-11-21 16:22:41,429 | DEBUG | Publishing discovery info for 771SNIPF9FB_runtime
SNIP
2023-11-21 16:22:41,453 | DEBUG | Publishing discovery info for 7719ASNIPF9FB_windchill
2023-11-21 16:22:41,454 | DEBUG | Sending PUBLISH (d0, q0, r1, m1), 'b'homeassistant/sensor/771SNIP9FB/runtime/config'', ... (830 bytes)
SNIP
2023-11-21 16:22:41,537 | DEBUG | Sending PUBLISH (d0, q0, r0, m312), 'b'homeassistant/sensor/771SNIPF9FB/windchill/state'', ... (4 bytes)
2023-11-21 16:22:41,547 | INFO | Published to Home Assistant MQTT Discovery
2023-11-21 16:22:41,547 | DEBUG | Published data: {'runtime': CalculatedDataPoint(data_point_key='runtime', value=182977.0, unit='s', attributes={}, data_type=<DataPointType.NON_BOOLEAN: SNIP CalculatedDataPoint(data_point_key='windchill', value=None, unit='°F', attributes={}, data_type=<DataPointType.NON_BOOLEAN: 2>)}
2023-11-21 16:22:41,548 | INFO | *** DIAGNOSTICS COLLECTED
2023-11-21 16:22:41,548 | DEBUG | Stopping runtime
ERROR:    Traceback (most recent call last):
  File "/venv/lib/python3.11/site-packages/uvloop/__init__.py", line 105, in run
    return runner.run(wrapper())
           ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/asyncio/runners.py", line 118, in run
    return self._loop.run_until_complete(task)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "uvloop/loop.pyx", line 1517, in uvloop.loop.Loop.run_until_complete
  File "/venv/lib/python3.11/site-packages/uvloop/__init__.py", line 61, in wrapper
    return await main
           ^^^^^^^^^^
  File "/venv/lib/python3.11/site-packages/ecowitt2mqtt/core.py", line 71, in async_start
    await self.runtime.async_start()
  File "/venv/lib/python3.11/site-packages/ecowitt2mqtt/runtime.py", line 186, in async_start
    await self._rest_api_server_task
  File "/venv/lib/python3.11/site-packages/uvicorn/server.py", line 81, in serve
    await self.main_loop()
  File "/venv/lib/python3.11/site-packages/uvicorn/server.py", line 232, in main_loop
    await asyncio.sleep(0.1)
  File "/usr/local/lib/python3.11/asyncio/tasks.py", line 649, in sleep
    return await future
           ^^^^^^^^^^^^
asyncio.exceptions.CancelledError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "/venv/lib/python3.11/site-packages/starlette/routing.py", line 686, in lifespan
    await receive()
  File "/venv/lib/python3.11/site-packages/uvicorn/lifespan/on.py", line 137, in receive
    return await self.receive_queue.get()
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/asyncio/queues.py", line 158, in get
    await getter
asyncio.exceptions.CancelledError
2023-11-21 16:22:41,552 | DEBUG | Sending DISCONNECT
Traceback (most recent call last):
  File "/venv/bin/ecowitt2mqtt", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "/venv/lib/python3.11/site-packages/ecowitt2mqtt/__main__.py", line 450, in main
    uvloop.run(ecowitt.async_start())
  File "/venv/lib/python3.11/site-packages/uvloop/__init__.py", line 105, in run
    return runner.run(wrapper())
           ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/asyncio/runners.py", line 118, in run
    return self._loop.run_until_complete(task)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "uvloop/loop.pyx", line 1517, in uvloop.loop.Loop.run_until_complete
  File "/venv/lib/python3.11/site-packages/uvloop/__init__.py", line 61, in wrapper
    return await main
           ^^^^^^^^^^
  File "/venv/lib/python3.11/site-packages/ecowitt2mqtt/core.py", line 71, in async_start
    await self.runtime.async_start()
  File "/venv/lib/python3.11/site-packages/ecowitt2mqtt/runtime.py", line 186, in async_start
    await self._rest_api_server_task
  File "/venv/lib/python3.11/site-packages/uvicorn/server.py", line 81, in serve
    await self.main_loop()
  File "/venv/lib/python3.11/site-packages/uvicorn/server.py", line 232, in main_loop
    await asyncio.sleep(0.1)
  File "/usr/local/lib/python3.11/asyncio/tasks.py", line 649, in sleep
    return await future
           ^^^^^^^^^^^^
asyncio.exceptions.CancelledError
2023-11-21 16:23:43,181 | DEBUG | Input CLI options/environment variables: {'config': '/config/config.yaml', 'diagnostics': 'true', 'hass_discovery': 'true', 'mqtt_broker': 'mqtt.domain.com', 'mqtt_password': 'pwd', 'mqtt_username': 'user', 'verbose': True}
SNIP
2023-11-21 16:23:43,184 | INFO | Starting ecowitt2mqtt (version 2023.11.1)
2023-11-21 16:23:43,184 | DEBUG | Starting runtime
INFO:     Started server process [1]
INFO:     Waiting for application startup.
INFO:     Application startup complete.
INFO:     Uvicorn running on http://<IP_ADDRESS>:8080 (Press CTRL+C to quit)
2023-11-21 16:23:44,993 | DEBUG | Received data payload: {'PASSKEY': 'E262SNIPE1F4', 'stationtype': 'GW1100B_V2.2.7', 'runtime': '3894991', 'dateutc': '2023-11-21 21:23:44', 'tempinf': '62.60', 'humidityin': '54', 'baromrelin': '30.469', 'baromabsin': '30.150', 'tempf': '35.42', 'humidity': '68', 'winddir': '136', 'windspeedmph': '1.12', 'windgustmph': '1.34', 'maxdailygust': '10.74', 'solarradiation': '0.47', 'uv': '0', 'rainratein': '0.000', 'eventrainin': '0.000', 'hourlyrainin': '0.000', 'dailyrainin': '0.000', 'weeklyrainin': '0.004', 'monthlyrainin': '0.622', 'yearlyrainin': '30.240', 'totalrainin': '30.240', 'rrain_piezo': '0.000', 'erain_piezo': '0.000', 'hrain_piezo': '0.000', 'drain_piezo': '0.000', 'wrain_piezo': '0.000', 'mrain_piezo': '0.413', 'yrain_piezo': '21.134', 'ws90cap_volt': '5.3', 'ws90_ver': '132', 'temp1f': '66.56', 'humidity1': '51', 'temp2f': '61.70', 'humidity2': '56', 'soilmoisture1': '33', 'pm25_ch1': '2.0', 'pm25_avg_24h_ch1': '5.9', 'lightning_num': '3', 'lightning': '14', 'lightning_time': '1700553234', 'leak_ch1': '0', 'wh40batt': '1.7', 'wh26batt': '0', 'batt1': '0', 'batt2': '0', 'soilbatt1': '1.7', 'pm25batt1': '5', 'wh57batt': '5', 'leakbatt1': '4', 'wh90batt': '3.28', 'freq': '915M', 'model': 'GW1100B', 'interval': '16'}
2023-11-21 16:23:44,994 | DEBUG | Creating MQTT loop: adc83c0af0e7432585cadf8962e3783d
INFO:     <IP_ADDRESS>:57362 - "POST /data/report/ HTTP/1.1" 204 No Content
2023-11-21 16:23:44,996 | DEBUG | Sending CONNECT (u1, p1, wr0, wq0, wf0, c1, k60) client_id=b''
2023-11-21 16:23:44,997 | DEBUG | Received CONNACK (0, 0)
2023-11-21 16:23:44,997 | DEBUG | Publishing payload: {'PASSKEY': 'E26SNIPF4', 'stationtype': 'GW1100B_V2.2.7', 'runtime': '3894991', 'dateutc': '2023-11-21 21:23:44', 'tempinf': '62.60', 'humidityin': '54', 'baromrelin': '30.469', 'baromabsin': '30.150', 'tempf': '35.42', 'humidity': '68', 'winddir': '136', 'windspeedmph': '1.12', 'windgustmph': '1.34', 'maxdailygust': '10.74', 'solarradiation': '0.47', 'uv': '0', 'rainratein': '0.000', 'eventrainin': '0.000', 'hourlyrainin': '0.000', 'dailyrainin': '0.000', 'weeklyrainin': '0.004', 'monthlyrainin': '0.622', 'yearlyrainin': '30.240', 'totalrainin': '30.240', 'rrain_piezo': '0.000', 'erain_piezo': '0.000', 'hrain_piezo': '0.000', 'drain_piezo': '0.000', 'wrain_piezo': '0.000', 'mrain_piezo': '0.413', 'yrain_piezo': '21.134', 'ws90cap_volt': '5.3', 'ws90_ver': '132', 'temp1f': '66.56', 'humidity1': '51', 'temp2f': '61.70', 'humidity2': '56', 'soilmoisture1': '33', 'pm25_ch1': '2.0', 'pm25_avg_24h_ch1': '5.9', 'lightning_num': '3', 'lightning': '14', 'lightning_time': '1700553234', 'leak_ch1': '0', 'wh40batt': '1.7', 'wh26batt': '0', 'batt1': '0', 'batt2': '0', 'soilbatt1': '1.7', 'pm25batt1': '5', 'wh57batt': '5', 'leakbatt1': '4', 'wh90batt': '3.28', 'freq': '915M', 'model': 'GW1100B', 'interval': '16'}
2023-11-21 16:23:44,998 | DEBUG | Calculator found for runtime: <ecowitt2mqtt.helpers.calculator.time.RuntimeCalculator object at 0x7ffb517abe50> (key: runtime, value: 3894991.0)
SNIP
2023-11-21 16:23:45,006 | DEBUG | Calculator found for interval: <ecowitt2mqtt.helpers.calculator.time.UpdateIntervalCalculator object at 0x7ffb51795d50> (key: interval, value: 16.0)
2023-11-21 16:23:45,007 | DEBUG | Relative Strain Index is only valid for temperatures above 26°C and below 35°C
2023-11-21 16:23:45,007 | DEBUG | Relative Strain Index is only valid for temperatures above 26°C and below 35°C
SNIP
2023-11-21 16:23:45,009 | DEBUG | Wind Chill Temperature is only defined for temperatures at or below 50 F and wind speeds above 3 mph. (current temperature: 35.42, current wind speed: 1.12)
2023-11-21 16:23:45,009 | DEBUG | Publishing discovery info for E26SNIPF4_runtime
SNIP
2023-11-21 16:23:45,031 | DEBUG | Publishing discovery info for E26SNIP1F4_windchill
2023-11-21 16:23:45,032 | DEBUG | Sending PUBLISH (d0, q0, r1, m1), 'b'homeassistant/sensor/E26SNIP1F4/runtime/config'', ... (812 bytes)
SNIP
2023-11-21 16:23:45,113 | DEBUG | Sending PUBLISH (d0, q0, r0, m296), 'b'homeassistant/sensor/E2SNIP1F4/windchill/state'', ... (4 bytes)
2023-11-21 16:23:45,127 | INFO | Published to Home Assistant MQTT Discovery
2023-11-21 16:23:45,127 | DEBUG | Published data: {'runtime': CalculatedDataPoint(data_point_key='runtime', value=3894991.0, unit='s', attributes={}, data_type=<DataPointType.NON_BOOLEAN: SNIP
CalculatedDataPoint(data_point_key='windchill', value=None, unit='°F', attributes={}, data_type=<DataPointType.NON_BOOLEAN: 2>)}
2023-11-21 16:23:45,128 | INFO | *** DIAGNOSTICS COLLECTED
2023-11-21 16:23:45,129 | DEBUG | Stopping runtime
ERROR:    Traceback (most recent call last):
  File "/venv/lib/python3.11/site-packages/uvloop/__init__.py", line 105, in run
    return runner.run(wrapper())
           ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/asyncio/runners.py", line 118, in run
    return self._loop.run_until_complete(task)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "uvloop/loop.pyx", line 1517, in uvloop.loop.Loop.run_until_complete
  File "/venv/lib/python3.11/site-packages/uvloop/__init__.py", line 61, in wrapper
    return await main
           ^^^^^^^^^^
  File "/venv/lib/python3.11/site-packages/ecowitt2mqtt/core.py", line 71, in async_start
    await self.runtime.async_start()
  File "/venv/lib/python3.11/site-packages/ecowitt2mqtt/runtime.py", line 186, in async_start
    await self._rest_api_server_task
  File "/venv/lib/python3.11/site-packages/uvicorn/server.py", line 81, in serve
    await self.main_loop()
  File "/venv/lib/python3.11/site-packages/uvicorn/server.py", line 232, in main_loop
    await asyncio.sleep(0.1)
  File "/usr/local/lib/python3.11/asyncio/tasks.py", line 649, in sleep
    return await future
           ^^^^^^^^^^^^
asyncio.exceptions.CancelledError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "/venv/lib/python3.11/site-packages/starlette/routing.py", line 686, in lifespan
    await receive()
  File "/venv/lib/python3.11/site-packages/uvicorn/lifespan/on.py", line 137, in receive
    return await self.receive_queue.get()
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/asyncio/queues.py", line 158, in get
    await getter
asyncio.exceptions.CancelledError
2023-11-21 16:23:45,133 | DEBUG | Sending DISCONNECT
Traceback (most recent call last):
  File "/venv/bin/ecowitt2mqtt", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "/venv/lib/python3.11/site-packages/ecowitt2mqtt/__main__.py", line 450, in main
    uvloop.run(ecowitt.async_start())
  File "/venv/lib/python3.11/site-packages/uvloop/__init__.py", line 105, in run
    return runner.run(wrapper())
           ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/asyncio/runners.py", line 118, in run
    return self._loop.run_until_complete(task)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "uvloop/loop.pyx", line 1517, in uvloop.loop.Loop.run_until_complete
  File "/venv/lib/python3.11/site-packages/uvloop/__init__.py", line 61, in wrapper
    return await main
           ^^^^^^^^^^
  File "/venv/lib/python3.11/site-packages/ecowitt2mqtt/core.py", line 71, in async_start
    await self.runtime.async_start()
  File "/venv/lib/python3.11/site-packages/ecowitt2mqtt/runtime.py", line 186, in async_start
    await self._rest_api_server_task
  File "/venv/lib/python3.11/site-packages/uvicorn/server.py", line 81, in serve
    await self.main_loop()
  File "/venv/lib/python3.11/site-packages/uvicorn/server.py", line 232, in main_loop
    await asyncio.sleep(0.1)
  File "/usr/local/lib/python3.11/asyncio/tasks.py", line 649, in sleep
    return await future
           ^^^^^^^^^^^^
asyncio.exceptions.CancelledError

This is just a sample. But even though my two Ecowitt devices should report every 16 seconds, this shows one of them reporting (or rather the info being pushed to HA) at 16:22:41, and the other one at 16:23:44.
I think some of this is due to the ECOWITT2MQTT_DIAGNOSTICS, so I am going to disable that, as it's obviously not allowing normal operation.

After removing the ECOWITT2MQTT_DIAGNOSTICS, it seems to be uploading at a normal rate:

(two sets, each about every 16 seconds)

@JvdMaat Thanks for the update. That prior comment looks like a separate issue; I'll look into it.

@JvdMaat Thanks for the update. That prior comment looks like a separate issue; I'll look into it.

Yeah, that's a Diagnostics issue. I'll open a new issue for that.

@bachya Aaron, while digging into this issue, I checked HA docs, and everything was in there: we used option 2, but option 1 is even more elegant, but it requires more code, probably that's why many integrations use retain method. (source)

Good find, @alexdelprete! Birth and Will Messages are definitely the right way to tackle this. What I have now is only half complete by the above reckoning (I'm not subsequently publishing retained state messages, nor do I always want to do that). I'll start tinkering.

Birth and Will Messages are definitely the right way to tackle this
I'll start tinkering

I wouldn't say LWT is the right way, because retained config topics work fine too, numerous integrations use that method, and they work fine. But the LWT way is far more elegant and efficient, because it relies on a tighter integration with HA MQTT integration through the subscription to the HA MQTT LWT topic (default is homeassistant/status).
The only problems with LWT approach are:

HA MQTT LWT is user configurable: users can disable LWT, so if you rely on that, you need to ask users to make sure it's on

since HA MQTT LWT topic is also user configurable, you need a configuration option for that.

Once those 2 pre-requisites are satisfied, on startup ecowitt2mqtt should subscribe to HA LWT topic, send the config topic, then when it receives an online for HA LWT topic (it means HA MQTT integration was restarted, could be for HA rstart or integration reload), it has to republish the config topics again.
The only other event that triggers config republishing is when config changes, obviously.
Another note: HA recommends that everytime you publish config topic, state topic has to be updated too, for consistency obviously.
My $0.02 for your tinkering...:)

So basically the con of the LWT approach is that involves the user configuring things, while retain is pretty much transparent.

Good point. We already have a lot of config options, and I'm reticent to add a more elegant approach only to still need an alternate if users turn off LWT.
Out of curiosity, has your current pr-777 image continued to run okay?

Out of curiosity, has your current pr-777 image continued to run okay?

Yes, but I didn't yet restart HA. :)
I saw the retain flag on config topics, I think you can release it.


API Response to the MVC Action Output?

I have an Interface to API definitions (Contracts)
public interface IGuidelineApi : IBaseApi
{
    ApiResult Operation(int i, string s, long l);
}

and Server Side API implementation prototype is like that:
[Route("api/[controller]")]
public class GuidelineController : IGuidelineApi
{
    [HttpGet]
    public ApiResult Operation([FromQuery]int i, [FromQuery]string s, [FromQuery]long l)
    {
    	// ApiResult inherits ActionResult
        return new ApiResult(new { intVal = i, strVal = s, longVal = l });
    }
}

To execute any API method from any client ( MVC client app or mobile ) that using DispatchProxy can Invoke them via (API Interface) Dependency Injection
private readonly IGuidelineApi _guidelineApi;
public AccountController(IGuidelineApi guidelineApi)
{
    _guidelineApi = guidelineApi;

     // DispatchProxy magic here!
    _guidelineApi.Operation(1, "hello", 617);
}

So question is that, can I transfer the API Response to the MVC Client output (IActionResult) as directly without serialization.
Trying just replace - override the actual response (StreamContent of Client)

@gencebay we generally do not recommend controllers (or anything) directly calling other controller actions. The problem with directly calling the methods is that it bypasses middleware, filters, model binding, action result processing, and a lot of other components.
Instead we recommend these two approaches:

Do another web request to the URL of the other controller and have the full request processing run (auth, caching, filters, model binding, etc.).
Put all the app logic/model in a separate class and call that class from all the controllers.

Both of these options indicate good layering of an application.
Controllers directly calling other controllers is generally bad layering because controllers are designed to respond to HTTP requests, not direct method calls.

@Eilon  thanks! We have already done that as you said! DispatchProxy -> Invoke method doing a request with HttpClient via generated proxy:
protected override object Invoke(MethodInfo targetMethod, object[] args)
{
    if (CallBeforeInvoke != null)
        CallBeforeInvoke(targetMethod, args);

    // HttpClient
    using (var proxy = _proxyHelper.CreateProxy())
    {
        try
        {
            // Prepare request
            RequestDescriptor descriptor = _proxyHelper.Request(targetMethod, args, _underlyingType);

            // Call and get HttpResponseMessage from DMZ API call
            response = proxy.SendAsync(descriptor.Request).Result;

            // trying response override here its working like that
            // but need custom ActionFilterAttribute to set Result property as NoContentResult
            // Direct stream transport
            if (response.Content is StreamContent)
            {
                descriptor.ActionContext.HttpContext.Response.ContentType = Globals.ContentTypeWithEncoding;
                descriptor.ActionContext.HttpContext.Response.Headers.Add(Globals.MetadataInnerHeader, metadataInner);
                descriptor.ActionContext.HttpContext.Response.Headers.Add(Globals.MetadataHeader, metadata);

                // Sync call wait all response!
                ((StreamContent)response.Content).CopyToAsync(descriptor.ActionContext.HttpContext.Response.Body).Wait();

                // Action filter will handle the Response actual result!
                return null;
            }
        }
        catch (Exception ex)
        {
            // TODO logging, trace etc...
            throw ex;
        }
        finally
        {
            if (CallAfterInvoke != null)
                CallAfterInvoke(targetMethod, args);
        }
    }
}

This method getting result object from API layer (DMZ - local network) to the MVC 6 client web app then it takes care of the rest (serializations, validations and respond to browser)


doesnt have a valid metadata.json file (found solution)

im trying to make a new keyboard but every time i try to install the libary on kicad it says that that the file doesent have a valid metadata.json file edit: i am using kicad 6.0

i am new to kicad and was usine the library editor to get the footprint from the zip file


Demo app broken when using the adapter with SvelteKit >= 1.0.0-next.356

While investigating why the integration tests in #29 continued to fail I saw that the /todos endpoint of the demo app is broken when using the svelte-adapter-appengine on SvelteKit versions >= 1.0.0-next.356.
Steps to reproduce:
yes "" | npm init svelte@next example-app
cd example-app
npm install
npm install --save-dev svelte-adapter-appengine
sed -i 's/@sveltejs\/adapter-auto/svelte-adapter-appengine/' svelte.config.js
npm run build
node .appengine_build_output/index.js

Afterwards open http://localhost:8080/todos in the browser. The browser will try to load the page but it will never complete. I tested this with Chrome and Firefox on Linux. Interestingly when using curl to fetch the same URL the response arrives immediately.
I also tried the same using the official SvelteKit node adapter but with the node adapter the page loads fine.
From the behavior I suspect the issue may be related to sveltejs/kit#5291 but I'm not exactly sure why this would lead to problems with the adapter.

I'm also really puzzled by this. I've been trying to identify where the difference might lie between the standard node-adapter and this adapter, and the only difference that really makes sense to me is that esbuild is used to bundle the code. esbuild is also used in other adapters (like vercel and netify), but in those, polka isn't used for serving I think, making it slightly different setup.

Figured out the reason, its the compression middleware that does it. Not sure why its not giving issues in the node adapter, but i'm guessing it has to do with the bundling. But regardless, i dont think compression is needed. Appengine should be handling it automatically.


chore: add --v8-flags option to dcore

useful for investigating v8 things, enabling tracing, etc.
basically ripped verbatim from the cli

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

Project coverage is 81.32%. Comparing base (0c7f83e) to head (5eeea0d).
Report is 202 commits behind head on main.

Files with missing lines
Patch %
Lines

dcore/src/main.rs
0.00%
58 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1009      +/-   ##
==========================================
- Coverage   81.43%   81.32%   -0.12%
==========================================
  Files          97       99       +2
  Lines       23877    26119    +2242
==========================================
+ Hits        19445    21241    +1796
- Misses       4432     4878     +446

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


Push fails for complex directory structure

While trying to push images which has a different directory structure, it doesn't work and helmper throws error :
for eg : while pushing charts for aws-ebs-csi-driver_2.32.0 the associated images like "public.ecr.aws/eks-distro/kubernetes-csi/node-driver-registrar:v2.11.0-eks-1-30-8" where more than one directory resides , in such case image does not get pushed to OCI registry.
{"time":"2024-10-08T05:51:03.840155299Z","level":"INFO","msg":"Image not available. will be excluded from import...","image":""}
{"time":"2024-10-08T05:51:04.782997215Z","level":"INFO","msg":"Image not available. will be excluded from import...","image":"public.ecr.aws/eks-distro/kubernetes-csi:v8.0.1-eks-1-30-8"}
{"time":"2024-10-08T05:51:04.785323639Z","level":"INFO","msg":"Image not available. will be excluded from import...","image":"public.ecr.aws/eks-distro/kubernetes-csi:v2.11.0-eks-1-30-8"}
{"time":"2024-10-08T05:51:04.7874143Z","level":"INFO","msg":"Image not available. will be excluded from import...","image":"public.ecr.aws/eks-distro/kubernetes-csi:v5.0.1-eks-1-30-8"}

Thanks for opening an issue. Will investigate and get back shortly


[Docs] Fix Documentations rendering issues

Description
Here is an example where examples were rendered incorrectly. The task should be inspecting the docs and applying fixes accordingly.

Link

Good catch @fnhirwa. Feel free to open a PR.


[DOC] - Develop end user checklist for integrations

Preliminary Checks

[X] This issue is not a question, feature request, RFC, or anything other than a bug report. Please post those things in GitHub Discussions: https://github.com/nebari-dev/nebari/discussions

Summary
Walk through actually using each of the integrations
Steps to Resolve this Issue

...

We essentially need a simple walkthrough for each integration.

[ ] vs code https://github.com/Quansight/qhub/issues/1384

Closing this META issue, we already have issue for some integrations and can open new ones for specific tools. :)