Standard library RFC

standard library design document, very brief at the moment but covers some of the basic implementation details and the module layout.
Any criticisms, etc...?
@vnev @kiljacken @MovingtoMars @raoulvdberge

Oh yah and @Acconut

Well, a first thing I spot is that you call for SipHash for a hashmap, while saying this is a slow hash. We do not need a cryptographically secure hash for a hashmap, we need a hash that is fast and provides results that are "good enough".
Other than that I don't really have many comments for how to proceed with the stdlib at the current point, but as I start actually using the language things will probably crop up.

Do we really want to provide crypto libraries in the std?

@kiljacken I think that we should provide both a secure/slow implementation, alongside a fast and sufficient implementation.

@raoulvdberge Well yeah, it's better we have a main place for the crypto (especially the big crypto algorithms) than various implementations that could be sketchy

Ah, I think I missed out the string library + allocation stuff and maybe an encoding thing for utf8 and eventually other encodings?

@felixangell No, we really don't need a slow hash for a hash table. The whole point of a hash table is to be a fast lookup structure. Something like murmurhash (or whatever it goes by nowadays) should be plenty good for a hashtable.
We should also consider letting the user specify the hashing algorithm, e.g. by implementing an interface on the type.

@kiljacken Hmm, I guess I can live with that... maybe we could provide some hash implementations for them to specify too.. like.. maybe... SipHash?

I just read up on SipHash, and I really wouldn't call it a slow hash. Also what is up with you and SipHash, is the author paying you or something? lol

@kiljacken Lol, no sponsor I promise ;) And yeah it's not slow at all, but in certain cases with small keys like an integer, its noticeably slower.

Oh yeah, and with regards to Arc, I think we agreed it would be a part of the standard library, or... ?

I don't think we decided on that yet.

I think this plan looks reasonable. I am in favour of keeping the stdlib small but focused.

lol, who's gonna write the crypto library? Us? That's a good way have insecure code. Best to just make it a wrapper for a C library.

@MovingtoMars Yeah we could do that, though it's the lowest of priorities when it comes to the standard library, so maybe by the time we get round to it, there might be someone more knowledgeable on implementing this.

:-1: on wrapping an external c library for use in the standard lib.

Either wrap a C lib, or don't have cryptography.

 Cryptography is delicate work.

I'm just saying, that if our crypto is going to be wrapping an external c library, it doesn't belong in the stdlib.

I agree with the 2 above posts.

Sure. We can have it as an official external lib.

@MovingtoMars I'm not saying we have to do it ourselves, that is one of the points I asserted in the design document. And it's incredibly low priority that it'll probably be the last thing we do, and maybe by then we'll have someone knowledgeable on crypto who can help us out, if not we wrap a C library or we don't include it.

(What I'm saying is don't jump to a conclusion in 5 minutes)

Looks like everyone seems to agree, I'll close this for now and any issues relevant to this can go in the stdlib repository here


Added test for save image in utils

This looks good to me, but I have the impression that lint will fail due to an extra line. Can you wait until CI is finished and check if linting pass as well?
Thanks!

Yes. Okay.

@fmassa CI has passed. Is it okay now?


Fix ios safari autocomplete bug

The fix for Safari autocomplete did not apply to the iOS strategy.

👍


Support Distant Horizons LoD Terrain

Distant Horizons 2.0 was released a while ago, collaboratively with Iris adding support for shaders on LoD terrain. The effect is truly spectacular - having support for these new rendering features on this shader would greatly improve the visual quality in applicable contexts. I would be especially interested in seeing this shader support it, it being the prettiest minimalistic shader with reasonable performance which in addtion is also Free and Open Souce.

I second this, really want DH compat

Third!

I would love to see DH compatibility ✨

This is the most optimized shader pack that I know, but I also would like to use it with the Distant Horizons mod, it feels like it could work seamlessly with it. Please consider adding support in an update soon!

Since there's so many people interested in this, I'll say that I made a prototype with DH support. It's hard to explain it, but there's some issues with reflections that I think (but may be mistaken) are on DH's part, and I have no time right now to fix it, and it'll probably take a while until I do.

It would be amazing if possible, but that does sound like a lot of work unfortunately. Would it be possible for you to upload the prototype?


Optional Params

Some of the APIs have optional parameters and this should be reflected in the lta-rs as well.
Affected APIs:

Bus Arrival ( Optional service_no )
Passenger Volume By Origin Destination  ( Optional date )
Bicycle Parking ( Optional dist )

Implmentation
Just use Option<T>, types that require Date should use chrono types, which means chrono will be re-exported so that the user don't have to add chrono to their dep and prevent incompat.

Implementation of optional date for passenger volume by origin dest is postponed for 0.3.0-async-preview-4

Done


fix for sequencing error when BG intervenes between wizard and bolus

@jh-bate can you review?
The issue here is that the simulator expects events in exact sequence. When we bundle together wizard + bolus events, we pass them to the simulator at the same time, but in fact an event may have been sandwiched between them (and when it gets read next - uh oh! we choke on an out-of-sequence error). The fix is to apply the timestamp from the wizard (which is always earlier) to the bolus, so that they both get simulated before any event sandwiched between them. @HowardLook approved this general strategy, although I do want to ask him one more question (about a potential annotation) before this gets merged, but the substance is there and ready to review.

LGTM - nice work on the extra specific test

Merging, as @HowardLook does not think an annotation is necessary.


Replace storage version to pallet version

https://github.com/paritytech/substrate/blob/fb4f3ecb89ce4c3f144636a9ce9766325946dd58/frame/vesting/src/lib.rs#L202
https://github.com/paritytech/substrate/blob/fb4f3ecb89ce4c3f144636a9ce9766325946dd58/frame/scheduler/src/lib.rs#L275
https://github.com/paritytech/substrate/blob/fb4f3ecb89ce4c3f144636a9ce9766325946dd58/frame/democracy/src/lib.rs#L478
They should be migrated to use pallet version.
I guess no need to add another migration unless necessary, so the migration can happen on next migration.

This is more about moving over to StorageVersion, but no the custom defined one ;)
Like this one here:
https://github.com/paritytech/substrate/blob/master/frame/collective/src/lib.rs#L170-L176

Hello @bkchr and @xlc  can I take this on?

Yes you can! :)


auto generate references

We should use this: https://sphinxcontrib-bibtex.readthedocs.org/en/latest/quickstart.html in the docstrings to auto generate the reference page: http://martinos.org/mne/dev/references.html. It may need some hacking to get the cross-links working between the docstrings and this page. Thoughts?

+1 as discussed IRL
can you paste how a new docstring would look like?

Here you go. Instead of
 References
 ----------
    [1] Zoltan J. Koles. The quantitative extraction and topographic mapping
    of the abnormal components in the clinical EEG. Electroencephalography
    and Clinical Neurophysiology, 79(6):440--447, December 1991.

you would have
.. bibliography:: refs.bib
   :list: bullet
   :filter: author % "Koles"

and refs.bib contains among other entries, this one:
@article{koles1991quantitative,
  title={The quantitative extraction and topographic mapping of the abnormal components in the clinical EEG},
  author={Koles, Zoltan Joseph},
  journal={Electroencephalography and clinical Neurophysiology},
  volume={79},
  number={6},
  pages={440--447},
  year={1991},
  publisher={Elsevier}
}

On the one hand this is a bit nicer because we can keep our refs in one place, on the other hand it actually makes the plain-text documentation far less useful than it was before. So I'm -1 on this currently. Perhaps I'm missing the motivation that overcomes this drawback, though. Do we want/need all our refs in one place? Does it help to keep them in the standard .bib format? Do we repeat a lot of references and this will be more DRY?

woops. You need a slight modification I think.
:cite:`1991:koles1991quantitative`
.. bibliography:: refs.bib
   :filter: author % "Koles"

And in the references.rst page (this time no filters), you'll have:
:cite:`1991:koles1991quantitative`
.. bibliography:: refs.bib

This is closer to what we want. We'll get cross-refs then between function documentation and the references.html page. The current approach doesn't create cross-refs. Sorry, got buried in the details :)

I also don't like the fact that the plain ref is not readable in the text
anymore. Is the way around this to duplicate it with :cite: + plain text?

Indeed, that's bad if you're looking at the doc from ipython or so. Yes, you'll have to duplicate the plain text then. We need automatic parsers if you don't want to duplicate. Duecredit is going to work on similar lines.

I guess it should be done there.
ask @yarikoptic on what he would need help

indeed it would be awesome to get citations for mne-python functionality/methods in duecredit.  There are two ways to do it ATM:
https://github.com/duecredit/duecredit/#native-use-of-duecredit-recommended
If you are keen on adopting a "native way", I can initiate a PR.
So far though I have tried to stay from any "integration" although it could be done (e.g. duecredit enhancing docstrings with references from its own entries), but then it would demand strict dependency on duecredit, which might be a slight burden.  May be it somehow could be implemented at "build time" though (duecredit "maintaining" References within docstrings in one form or another and collating target .bib) and thus avoiding run-time dependency. It somewhat also relates to my own use-case of simplifying collection of "use" references for a toolkit: https://github.com/duecredit/duecredit/issues/7 since as a result it should generate e.g. the .rst to be included in the documentation (and replace manually built ones such as http://www.pymvpa.org/whoisusingit.html#studies-employing-pymvpa .
But that sounds like a good piece of work TODO.  On the other hand, we could make duecredit use references within your docstrings, but then we would need to enhance them with additional information since duecredit supports meta-information about every citation, such as a brief description of the functionality/purpose, tags (either it is a reference implementation of the method, or mere "educational" reference, etc).

@yarikoptic just to set up the context a bit. I'm exploring this area with
@agramfort to figure out if there's something useful and impactful that
could be done. This could potentially translate into one month of
full-time work spread over one year. Maybe we could team up :)
On Thu, Sep 3, 2015 at 4:08 PM, Yaroslav Halchenko<EMAIL_ADDRESS>
wrote:

indeed it would be awesome to get citations for mne-python
functionality/methods in duecredit. There are two ways to do it ATM:
https://github.com/duecredit/duecredit/#native-use-of-duecredit-recommended
If you are keen on adopting a "native way", I can initiate a PR.

I think @agramfort can comment on this. I'm curious to see how this is
supposed to be configured though. Just following the instructions on the
duecredit site didn't seem to work for me. I get this
https://gist.github.com/mainakjas/38b92b0c284242e91e72 error.

So far though I have tried to stay from any "integration" although it
could be done (e.g. duecredit enhancing docstrings with references from its
own entries), but then it would demand strict dependency on duecredit,
which might be a slight burden. May be it somehow could be implemented at
"build time" though (duecredit "maintaining" References within docstrings
in one form or another and collating target .bib) and thus avoiding
run-time dependency. It somewhat also relates to my own use-case of
simplifying collection of "use" references for a toolkit:
duecredit/duecredit#7 https://github.com/duecredit/duecredit/issues/7
since as a result it should generate e.g. the .rst to be included in the
documentation (and replace manually built ones such as http://www.pymvpa.org/whoisusingit.html#studies-employing-py
mvpa http://www.pymvpa.org/whoisusingit.html#studies-employing-pymvpa .

Indeed, this is exactly what we want. Auto-generate this page. But also
with cross-refs back to the functions which implement it. Consider it to be
an interactive alternative complementary to the command-line utility :)
Except I'm not sure if we want to add the references manually ("injection"
and "native" both appear manual to me). Automatic could scale better (of
course with caveats). You could another option called "automatic" to these
two existing approaches.

But that sounds like a good piece of work TODO.

That's indeed the idea ;)

On the other hand, we could make duecredit use references within your
docstrings,

Yep, that's what we want to do :)

but then we would need to enhance them with additional information since
duecredit supports meta-information about every citation, such as a brief
description of the functionality/purpose, tags (either it is a reference
implementation of the method, or mere "educational" reference, etc).

We could use the first line of the docstring for the brief description. And
the tag could be "unknown" or guessed from other available clues?

—
Reply to this email directly or view it on GitHub
https://github.com/mne-tools/mne-python/issues/2439#issuecomment-137461369
.

On Thu, 03 Sep 2015, mainakjas wrote:

... full-time work spread over one year. Maybe we could team up :)

"team up" sounds awesome!   Not sure if I would be able to contribute
as much of my time though ;)

indeed it would be awesome to get citations for mne-python
functionality/methods in duecredit. There are two ways to do it ATM:
https://github.com/duecredit/duecredit/#native-use-of-duecredit-recommended
If you are keen on adopting a "native way", I can initiate a PR.

I think @agramfort can comment on this. I'm curious to see how this is
supposed to be configured though. Just following the instructions on the
duecredit site didn't seem to work for me. I get this
https://gist.github.com/mainakjas/38b92b0c284242e91e72 error.

wow -- that is quite a blow!  I guess I do need to learn how to use anaconda
and to replicate this issue.  I believe Matteo (duecredit co-author) uses it
but we never saw such a crash.  duecredit is quite new and despite being
developed under linux and osx, there could still be surprises ;)
Just for completeness -- that 'report.py' -- is that something you
could share?  Any additional detail on how to replicate would be
appreciated!  (there is now 0.4.2 of duecredit, but I don't think it
resolved any related issue)

duecredit/duecredit#7 https://github.com/duecredit/duecredit/issues/7
since as a result it should generate e.g. the .rst to be included in the
documentation (and replace manually built ones such as http://www.pymvpa.org/
whoisusingit.html#studies-employing-py
mvpa http://www.pymvpa.org/whoisusingit.html#studies-employing-pymvpa .
Indeed, this is exactly what we want. Auto-generate this page. But also
with cross-refs back to the functions which implement it.

that page is just of the "users" of PyMVPA, so not exactly aiming to point to
functionality they have used, but eventually we want to provide such as
"service" ;)
In your case you want to collate references for all the functionality
implemented in MNE.  Indeed it is a nice use case, inline with the
"users" one (e.g.  just output list of citations with "implementation"
instead of "use" tag), and then back-references indeed would be meaningful.
Added a comment to that issue #7 of duecredit ;)

Consider it to be an interactive alternative complementary to the
command-line utility :) Except I'm not sure if we want to add the
references manually ("injection" and "native" both appear manual to
me).

well -- somewhere reference needs to be added, right? ;)  if you get a
centralized .bib, you could just
due.load('whatever.bib') somewhere e.g. in mne/init.py (would do nothing
unless duecredit is "Active")  and then use bibtex keys in due.dcite /
due.cite calls.

Automatic could scale better (of course with caveats). You
could another option called "automatic" to these two existing
approaches.

with 'automatic' you mean scraping of the docstrings?
With duecredit there is an additional feature/caveat.  The idea is to collect
references for functionality which is actually used.  So, if there is a
reference within class docstring, and someone might even initiate that object
but don't really use it (i.e. to call some "representative" method), we
would prefer not to cite that reference in the report.
Overall -- some 'manual' specification I guess would be necessary to
denote running of which functionality constitutes "using" the referenced
method/functionality.

On the other hand, we could make duecredit use references within your
docstrings,

Yep, that's what we want to do :)

so the simplest/non-ambiguous way I see is smth like
class CSP(TransformerMixin):
   """....
   :cite:`1991:koles1991quantitative`
   .. bibliography:: refs.bib
   """
   ...
   @due.dcite(due.USE_CLASS_DOC)
   def fit(...

where we would implement support for delayed (since at decorator creation time
there is no access to the class's doc AFAIK) parsing of
self.class.doc whenever that fit gets called.  "implementation" would
be assumed to be the default tag (otherwise could be specified in dcite call),
and description would come from the first line in the doc.
Or in injections approach we could support specifying from which docstring to
scrape the reference (if machine parseable like with :cite:)
Smth like that?

but then we would need to enhance them with additional information since
duecredit supports meta-information about every citation, such as a brief
description of the functionality/purpose, tags (either it is a reference
implementation of the method, or mere "educational" reference, etc).

We could use the first line of the docstring for the brief description. And
the tag could be "unknown" or guessed from other available clues?

description -- agreed.  tags -- we can only assume default (e.g.  "reference"),
not sure if could be somehow guessed, unless explicitly provided somewhere (as
an additional attribute in :cite: or in @due.dcite arguments)
--
Yaroslav O. Halchenko
Center for Open Neuroscience     http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1<PHONE_NUMBER>                       Fax: +1<PHONE_NUMBER>
WWW:   http://www.linkedin.com/in/yarik

Re
.. bibliography:: refs.bib
   :filter: author % "Koles"

gy -- finally was done properly? ;)  Since awhile for our lab we use my hack (https://github.com/matthew-brett/bibstuff/pull/7, never got to finish up) on top of Matthew's craft on top of abandoned bibstuff which looks very similar:
.. bibmatching:: ../_static/haxbylab.bib
    :style: haxby
    :filter:
     author: \bHalchenko\b
    :groupby: entry_type, subtype
    :sort:

which results in http://haxbylab.dartmouth.edu/ppl/yarik.html#publications

"team up" sounds awesome! Not sure if I would be able to contribute
as much of my time though ;)

let's see how things go ... :)

Just following the instructions on the

duecredit site didn't seem to work for me. I get this
https://gist.github.com/mainakjas/38b92b0c284242e91e72 error.

wow -- that is quite a blow! I guess I do need to learn how to use anaconda
and to replicate this issue. I believe Matteo (duecredit co-author) uses it
but we never saw such a crash. duecredit is quite new and despite being
developed under linux and osx, there could still be surprises ;)
Just for completeness -- that 'report.py' -- is that something you
could share? Any additional detail on how to replicate would be
appreciated! (there is now 0.4.2 of duecredit, but I don't think it
resolved any related issue)

report.py is in mne-python itself. To reproduce, just do the following:
$ git clone https://github.com/mne-tools/mne-python.git && cd
mne-python/mne/
$ wget -q -O ./due.py
https://raw.githubusercontent.com/duecredit/duecredit/master/duecredit/stub.py
$ easy_install duecredit # use the anaconda easy_install
$ python -m duecredit report.py
not sure if this is how it's supposed to be used though ... I didn't need
to insert any 'native' Due citations to get the error.

In your case you want to collate references for all the functionality
implemented in MNE. Indeed it is a nice use case, inline with the
"users" one (e.g. just output list of citations with "implementation"
instead of "use" tag), and then back-references indeed would be meaningful.
Added a comment to that issue #7 of duecredit ;)

I like that. Why not.

Consider it to be an interactive alternative complementary to the
command-line utility :) Except I'm not sure if we want to add the
references manually ("injection" and "native" both appear manual to
me).

well -- somewhere reference needs to be added, right? ;)

indeed, my only complain is that you are "changing habits". Imagine having
to convert all the existing plaintext references to bibtex ...

Automatic could scale better (of course with caveats). You
could another option called "automatic" to these two existing
approaches.

with 'automatic' you mean scraping of the docstrings?

yep

With duecredit there is an additional feature/caveat. The idea is to
collect
references for functionality which is actually used. So, if there is a
reference within class docstring, and someone might even initiate that
object
but don't really use it (i.e. to call some "representative" method), we
would prefer not to cite that reference in the report.

makes sense. I guess it's a complementary use case. In our case, we are
looking to generate a bibliography for all the functions in the package
without any filters in terms of usage. Maybe later (and I am digressing),
it would be neat to generate an "html report" which will list all the
references used (like in the command line utility) but also offer clickable
links to specific parts of the code.
Overall -- some 'manual' specification I guess would be necessary to

denote running of which functionality constitutes "using" the referenced
method/functionality.

On the other hand, we could make duecredit use references within your
docstrings,

Yep, that's what we want to do :)

so the simplest/non-ambiguous way I see is smth like
class CSP(TransformerMixin):
"""....
:cite:`1991:koles1991quantitative`
.. bibliography:: refs.bib
"""
...
@due.dcite(due.USE_CLASS_DOC)
def fit(...

where we would implement support for delayed (since at decorator creation
time
there is no access to the class's doc AFAIK) parsing of
self.class.doc whenever that fit gets called. "implementation"
would
be assumed to be the default tag (otherwise could be specified in dcite
call),
and description would come from the first line in the doc.

so you would see a plaintext documentation when you do csp.fit? in ipython?
Or in the html generated using sphinx? But you can do this only for methods
of a class, not the class itself? sounds a bit hackish but if it works, why
not.

Or in injections approach we could support specifying from which docstring
to
scrape the reference (if machine parseable like with :cite:)
Smth like that?

because you want to list only "some" of the references -- the ones that are
actually "used"? This brings me to another question. I understand that you
want to be able to cite the core libraries which are used. But I guess it
would clutter things mixing top-level references with say a numpy reference
(at least in the reference.html page that we want to generate) ... ? Also,
to what depth do you recurse? mne-python uses pysurfer which uses mayavi
which uses numpy etc etc. See what I mean?

re report.py  look on that gist  you posted with error - I   gave explanation there

changing  habits:  we can  support anything   non-ambiguously providing reference. eg  as long as text form  has identifiable  doi -  we could use that.  lazy me prefers doi  anyway f or specifying  citations for duecredit

@jasmainak just to catch up on this -- do we only need to add DOIs to our refs to get this working? I'd prefer to keep the plain text ones in the code if we can.

I think we can close this issue. @agramfort ?


Installing VC_redist old version.

Prerequisites

[ ] Verify that this is not a Windows issue;
[ ] Refer to the Before running.
[ ] Refer to the How to use.
[ ] If you issue concerns the Wrapper, please mention @BenchTweakGaming in issue

Steps to reproduce
Hello. I noticed that Sophia script is installing an old VC_redist version when I run it.
The version it's installing is 14.29 and the latest is 14.32 as you can see here: https://download.visualstudio.microsoft.com/download/pr/f359701c-0fda-414e-83c2-31d65ee7f308/4B2947448BF80CC987A440B43A1AA07152B9057915C68930061C74E0B40BA05B/VC_redist.x64.exe
It's not a big problem, but if you can update it will be nice.
Thanks in advance.

Hi. Yeah, I know. There is a wrong URL in https://github.com/farag2/Sophia-Script-for-Windows/blob/5318bf9c5574fbd12997aabb85d25db7bc6f8b92/Sophia Script/Sophia Script for Windows 10/Module/Sophia.psm1#L8213
Already fixed in 5.12.14/6.0.14. Actually, they're done. But today I had a cool idea for the script to improve. I may upload here for you the current latest version, if you wish.

Hey friend, don't worry.
I can wait for the next release, no problem. :)
Again, thank you.

Fixed in 6.0.14


Feedback button

Add a place/link to allow users to provide feedback or report an issue. We already have something in the <ErrorMsg /> component that renders a link but that's only available if there a serios error.
depends on #45

For the time being, lets add this to header after the buttons are moved.

After futher investigation, I'm not sure we have a good place to send people for feedback.
options:

If we send them here, they must have a GitHub account.
If we send them to RCRAInfo feeback/Report and Issue page then ther are required to have an account there and must log in.

Taking this off the current iteration. The value provided is minimal anyways since we only have a development deployment (which is just deployed to github pages without any custom domain).

Start by sending people to use the<EMAIL_ADDRESS>email address.


Game crashes once loading reaches 100%. Help required ASAP.

crash-2023-06-02_18.05.45-client.txt
issue problem.zip
Above is the crash file and the workspace sharable zip.

All I can suggest is splitting the animations into individual files, as it seems to not be able to read the file properly. Then you'll see which one causes it.

the files are already seperate.


Added back-end for configuring navigation menus

⚠ REBASED ON #340 ⚠
Pre-Flight checklist

[ ] Screenshots and design review for any changes that affect layout or styling

[ ] Desktop screenshots
[ ] Mobile width screenshots

[ ] Migrations

[ ] Migration is backwards-compatible with current production code

[ ] Testing

[ ] Code is tested
[ ] Changes have been manually tested

[ ] Settings

[ ] New settings are documented and present in app.json
[ ] New settings have reasonable development defaults, if applicable
[ ] Opened issue for DevOps regarding necessary configuration changes to deployed environments

What are the relevant tickets?
(Required)
What's this PR do?
(Required)
How should this be manually tested?
(Required)
Where should the reviewer start?
(Optional)
Any background context you want to provide?
(Optional)
Screenshots (if appropriate)
(Optional)
What GIF best describes this PR or how it makes you feel?
(Optional)

Codecov Report

Merging #364 (ce30305) into master (a4bca95) will increase coverage by 4.40%.
The diff coverage is 88.83%.

@@            Coverage Diff             @@
##           master     #364      +/-   ##
==========================================
+ Coverage   88.62%   93.03%   +4.40%
==========================================
  Files         123       62      -61
  Lines        3816     1579    -2237
  Branches      588      359     -229
==========================================
- Hits         3382     1469    -1913
+ Misses        394      109     -285
+ Partials       40        1      -39

Impacted Files
Coverage Δ

static/js/components/RepeatableContentListing.tsx
95.45% <ø> (ø)

static/js/components/forms/validation.ts
94.44% <0.00%> (-5.56%)
:arrow_down:

static/js/lib/site_content.ts
90.66% <33.33%> (-2.39%)
:arrow_down:

static/js/components/forms/MenuItemForm.tsx
83.87% <83.87%> (ø)

static/js/lib/util.ts
97.72% <91.66%> (-2.28%)
:arrow_down:

static/js/components/widgets/MenuField.tsx
92.42% <92.42%> (ø)

static/js/components/widgets/RelationField.tsx
96.72% <100.00%> (+4.26%)
:arrow_up:

static/js/query-configs/websites.ts
98.83% <100.00%> (+0.01%)
:arrow_up:

static/js/types/websites.ts
100.00% <100.00%> (ø)

... and 59 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a4bca95...ce30305. Read the comment docs.

@gsidebo can you rebase now that #340 is merged?

@noisecapella Ready for review


KickPlayerEvent does not register kick due to spam and is not cancellable

I am currently running

SpongeForge version: .12.2-2838-7.2.4-RC4054
Java version: 1.8.0_251-b08
Operating System: Windows 10

Issue Description
KickPlayerEvent does not register a player being kicked for spamming chat, and is not cancellable. I believe it should be cancellable to allow certain players the ability to bypass being kicked for various reasons.
One such example would be to prevent certain users from being kicked due to chat spamming. As it stands this does not seem possible to do.
    @Listener
    public void onPlayerKick(KickPlayerEvent event) {
        plugin.getLogger().info("Player kicked");
    }

KickPlayerEvent just isn't fired.
There are a couple of issues here:

If this event was cancelled, the Player#kick event returns a void so there is no way for a user of this event to know if the kick was successful. We'll need to introduce a new method.
The event *MessageChannel methods (from MessageChannelEvent) shouldn't exist, really. What use is a message channel on an event that sends a message to a disconnected client?

This can all be fixed properly in API 8, however there are challenges for API 7. We'd like to add this in 7.3, but we do need to consider how we work around the problems above - I'm noting them here so I can get some feedback from a couple of others.

PR merged


Use a dynamic map to handle visualisation

https://holoviews.org/reference/containers/bokeh/DynamicMap.html

[x] Autoscale
[x] Disable fixed step in slider
[x] Prevent divison by zero errors
[ ] Manage multiple plots
[ ] Add time parameter
[x] Layout
[x] See points and values on hover

Dynamic map can not yet handle multiple plots


fix: incorrect default port

@jcw a comment that bashes on open source maintainers not prioritizing documentation for software that they produce for free.
Even worse
Open Source takes time. Please respect that

Ok, CI did not because it ignores changes in docs.

Thank you for your patience.


Add favicon logo for website

Feature Request
Describe your problem
Add elevate-lab logo as favicon for website.

Hi! Can I contribute to this?

@Tlazypanda can I work on this?

The new logo, that Himanshu created??

Hey @kashc11 please go ahead :tada: You can find the relevant files in images/logo subdir :sweat_smile:

Closed via #27


Give helpful suggestion when url_for fails

Forgetting the exact name of endpoint or missing some values when using url_for is my pet sleeve. The goal of this pull request is to provide the developer with more helpful error message. Further discussion at #688

I did the modifications you suggested. Python 2.6 build in CI seems to fail in an unrelated manner.

Awesome, thanks!


Adds k8s detection

Codecov Report
Attention: 2 lines in your changes are missing coverage. Please review.

Comparison is base (398bb08) 60.15% compared to head (37e49ab) 59.84%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #345      +/-   ##
==========================================
- Coverage   60.15%   59.84%   -0.31%
==========================================
  Files           3        3
  Lines         128      132       +4
  Branches       30       30
==========================================
+ Hits           77       79       +2
- Misses         46       48       +2
  Partials        5        5

Files
Coverage Δ

src/arc-runner.ts
80.00% <50.00%> (-4.62%)
:arrow_down:

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


Browser Feature Detection

It's unfortunate that you need to turn off joystick for all browsers just because Safari doesn't have it. We should either provide a mechanism for checking that or fail gracefully when a feature is not supported (or both!)

With the compatibility release, checking if an SDL subsystem can be initialized should at least result in a catchable error.

From the previous comment, is that saying it is on the compatibility release or SHOULD be in compatibility release in the future?

It is in the compatibility release. This problem is one of the main reasons that the compatibility release exists.

Cool, thanks for the info. I will investigate the options on what that means for Mobile/Safari supporting my demos...


Support regular expressions as exclude(Files|Packages) configuration parameters

Hey!
I am currently experimenting with this plugin (read your Foojay blogpost 🙂 ) in some nested multi-module Maven projects with a structure along the lines of
project
├── component-a
│   ├── component-a-api
│   ├── component-a-logic
│   └── component-a-web
├── component-b
│   ├── component-b-api
│   ├── component-b-logic
│   └── component-b-web
└── component-c
    ├── component-c-api
    ├── component-c-logic
    └── component-c-web

and want to determine the project's next semantic version based on changes in the -api modules / .api packages only.
AFAIU the scope of what the plugin checks can only be limited by the excludePackages and excludeFiles configuration parameters. This makes it cumbersome to maintain the scope-to-check as new modules have to be added to these parameters.
Furthermore, the existing configuration parameters only support specifying prefixes, rather than, say, more flexible regular expressions.
Ideally, I could specify the scope as the inverse using a regex i.e.
<includePackages>
     <includePackage>.*.api$</includePackage>
</includePackages>

once for the entire project.
Thanks for your response!

Thanks for the feature request, I had the same idea, but due to time constraints, I haven't gotten around to it. I will implement this in the near future.

Now implemented with version 0.5.0

Thanks, will give this a try next week!


Reconsider is not → isnot mapping

The TwineScript desugarer currently maps an is not token sequence into the isnot token.
This mapping has been in the desugarer since time immemorial and was done in an attempt to help end users.  Code comment:

If the token is is, check to see if it's followed by not, if so, convert them into the isnot operator.
NOTE: This is a safety feature, since $a is not $b probably sounds reasonable to most users.

The mapping means that actual attempts in TwineScript to do is not are doomed to failure.  Though, I'm unsure how plausible it is that anyone would attempt something like that.
Still, the mapping needs to either be documented or removed.  I'm partial to the latter, because screw weird special cases.

Resolved by commit ea4142e.


Add import paths to SPM Plugin

Added an optional parameter to the config file so users can configure import paths for protoc.
Useful in a mono repo where the proto file is not in the target directory and requires imports that are defined relative to the proto.

@FranzBusch

@FranzBusch by the way theres a matching PR in https://github.com/grpc/grpc-swift/pull/1568 for the same thing and I made the same change there.

@samisuteria I am just coming back to this since I wanted to try this out myself and actually noticed that this behaves differently than I assumed during review. (I will get some tests in place here in another PR).
How are you using this property in your config? Because as far as I can see it only takes absolute paths which makes it very hard to use in general.

@FranzBusch I actually could not get it to work the way I expected it to. I wanted to reference a proto file that was outside the Sources directory and when running protoc manually with the flags it generated code correctly but I have not been able to get it to work with the plugin. I've resorted to soft linking the shared proto folder into each target that needs it.

@FranzBusch We have a monorepo with multiple iOS/macOS apps and Swift packages so copying files to the target source would mean copying them to many target sources and updating them would be a manual process. We use a git submodule for all proto files and soft link that folder into the targets that need it.
Correct, I am not using the new option I added. I have not had the time to come back and fix it to the behavior I was expecting.


chore(main): release sdk 7.1.0

:robot: I have created a release beep boop
7.1.0 (2024-11-04)
Features

sdk: Add support to Hydration > Ethereum transfer 🪄 (b6f4c81)
sdk: Allow to pass RPC url to create API client ✨ (6fb3af9)

Bug Fixes

sdk: Fix USDT transfer from Bifrost to AssetHub ✏ (68eb167)

Miscellaneous Chores

sdk: Update optional ws_url parameter (c6fb8ae)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

sdk-v7.1.0
:sunflower:


How to have dynamic lists with some different siblings

Hi.
Still struggling with Lists. I use tables and lists a lot and a common requirement is to have a first and/or last item that is different from the dataset. example:
el('tr', tdSelector, tdValues, tdSum)

Using lists for tdValues overwrites all children so it is not an option and wrapper elements are not always possible.
What would be the recommend pattern for this?

I'm using this kind of aproach: https://github.com/lhorie/frzr-dbmon/blob/gh-pages/frzr/app.js#L38:L50
You can use index value or figure out the data type.. Or custom render the List with setChildren(tr, [tdSelector, tdValues.views, tdSum]);..
The issue with having mixed views and lists is, that if the list is empty, you would need a placeholder for the list and I think it's a bit of a hack..

I think it might be simpler if you had a more generic Group type that would be the basis for different implementations (e.g. Group:()=>{views, update, parent}). The current List constructor is really designed to optimize arrays of objects and could be optional, making FRZR even smaller. Users could extend Group to define other implementations for Tuples, Arrays or Matrices. List would be an extension of Group, allowing all implementation to have the same mounting behaviour in mount.js where the parent and children would be set (ie. if (child instance of Group) or if (child.views && child.hasOwnProperty('parent'))).
Right now I have to do this in 2 steps:
myGroup = group(view1, new List(View2), view3)
this.el = el('tr', myGroup.views)
this.update = group.update.bind(group)

Wouldn't you be able to use setChildren for that? I've used setChildren for all my list type things so far and it has worked fine (haven't used List at all).

@talmobi is right, List is just an optional helper. But I will investigate the group suggestion..

Thanks again for great ideas! 👍

@talmobi great. Everything is obvious when you know the answer. Thanks.

Great that you found a solution! 😎 I will get back to this "group" idea – I'm on a small holiday right now..
I'm thrilled you've found FRZR useful, and am happy to help you out! You can also join Gitter (pakastin/frzr) if you want to just chat about FRZR. Or Koodiklinikka Slack channel #javascript (https://koodiklinikka.fi).


fix: resolve errors with closure

Also don't patch all "on" properties if a list of properties is being
passed in. Otherwise various global variables in window get clobbered.

Could you get this green?


Update pub revision

This should fix: https://github.com/dependabot/dependabot-core/issues/5199 again.

cc @mctofu

@mctofu  Oh - I see you already fixed this - thanks!

@sigurdm: Would it be worth bumping up to this version still? I only bumped it to the version that fixed the missing lockfile issue but would be happy to pull in this update too.

There is nothing new for dependabot, but it wouldn't hurt.


Test client registrar

Just additional tests which fully cover client registrar.
Signed-off-by: Pavol Loffay<EMAIL_ADDRESS>

@fmhwong @objectiser could you please review?


SQL contraints are not removed when field.Unique() is removed

If you define a field with a unique constraint it will properly set to the data-model
return []ent.Field{
   field.String("name").Unique(),
}

Now, remove the constraint:
return []ent.Field{
   field.String("name"),
}

That change will not be propagated to the database. You can still see the constraint defined:
CONSTRAINT users_name_key UNIQUE (name)

I observed this behavior with postgres. Not tested with Mysql.

Did you use the DropIndex option?
https://entgo.io/docs/migrate/#drop-resources

I have not tested it with DropIndex, since I have not defined the field as an index.

You can also use the “offline mode” to verify changes before dropping resources.
https://entgo.io/docs/migrate/#offline-mode

I have not tested it with DropIndex, since I have not defined the field as an index.

Postgres (or MySQL) automatically creates a unique index when a unique constraint is added to a column, and ent migration works by default on “append-only” mode. So, if you want to drop resources, you need to ask this explicitly.

I think I narrowed down the issue. Let's assume you create a new entity like:
type TestUser struct {
	ent.Schema
}

func (TestUser) Fields() []ent.Field {
	return []ent.Field{
		field.Int("age"),
		field.String("name"),
		field.String("nickname"),
	}
}

func (TestUser) Edges() []ent.Edge {
	return []ent.Edge{}
}

func (TestUser) Index() []ent.Index {
	return []ent.Index{
		index.Fields("age", "name").
			Unique(),
	}
}

This will generate the following correct SQL statement:
CREATE TABLE IF NOT EXISTS "test_users"("id" bigint GENERATED BY DEFAULT AS IDENTITY NOT NULL, "age" bigint NOT NULL, "name" varchar NOT NULL, "nickname" varchar NOT NULL, PRIMARY KEY("id"));

If we are going to add a Unique() statement:
func (TestUser) Fields() []ent.Field {
	return []ent.Field{
		field.Int("age"),
		field.String("name"),
		field.String("nickname").Unique(),
	}
}

a new index will be created via:
CREATE UNIQUE INDEX "test_users_nickname" ON "test_users"("nickname");

once we remove the uniqueness, a correct drop is generated:
DROP INDEX "test_users_nickname";

The issue occurs, when you generate the entity with the uniqueness for the first time directly:
type TestUser struct {
	ent.Schema
}

func (TestUser) Fields() []ent.Field {
	return []ent.Field{
		field.Int("age"),
		field.String("name"),
		field.String("nickname").Unique(),
	}
}

func (TestUser) Edges() []ent.Edge {
	return []ent.Edge{}
}

func (TestUser) Index() []ent.Index {
	return []ent.Index{
		index.Fields("age", "name").
			Unique(),
	}
}

Then ent will generate the following sql statement with an contraint instead of an index:
CREATE TABLE IF NOT EXISTS "test_users"("id" bigint GENERATED BY DEFAULT AS IDENTITY NOT NULL, "age" bigint NOT NULL, "name" varchar NOT NULL, "nickname" varchar UNIQUE NOT NULL, PRIMARY KEY("id"));

This leads to the following result in postgres:
CREATE TABLE nexus.test_users
(
    id bigint NOT NULL GENERATED BY DEFAULT AS IDENTITY ( INCREMENT 1 START 1 MINVALUE 1 MAXVALUE<PHONE_NUMBER>854775807 CACHE 1 ),
    age bigint NOT NULL,
    name character varying COLLATE pg_catalog."default" NOT NULL,
    nickname character varying COLLATE pg_catalog."default" NOT NULL,
    CONSTRAINT test_users_pkey PRIMARY KEY (id),
    CONSTRAINT test_users_nickname_key UNIQUE (nickname)
)

Then the drop index statement will not work, because a constraint had created for the table:
DROP INDEX "test_users_nickname_key";

will result in
ERROR:  cannot drop index test_users_nickname_key because constraint test_users_nickname_key on table test_users requires it
HINT:  You can drop constraint test_users_nickname_key on table nexus.test_users instead.

Thanks for this comment @chris-rock, I'll give it a look tomorrow morning.
What Postgres version are you using?

I used the postgres dialect to generate the SQL statements via ent's offline mode. I tested everything with the postgres:12-alpine container

Thanks for the report and the support @chris-rock
Please feel free to open if you still have troubles with the migration.

Thank you for your PR @a8m This fixes the issue that constraints are not properly deleted 🥇
I think there is still the question if ent should create an index for constraints:
changing
field.String("name").Unique(),

to
field.String("name")

will generate
ALTER TABLE users DROP CONSTRAINT "users_name_key";

once, we re-add the uniqueness, it will create an index instead of a constraint:
field.String("name").Unique(),

CREATE UNIQUE INDEX "users_mrn" ON "users"("mrn");

What do you think @a8m?

Hey @chris-rock,
Do you have any pros/cons about the 2 strategies? I like the current approach because the code looks the same for all dialects (but I don't mind to change it if it's incorrect).
I know that Postgres documentation suggests to use constraint because index is an "implementation details":

The use of indexes to enforce unique constraints could be considered an implementation detail that should not be accessed directly.

Also, I need to check the difference in table locking (if there's one) between the 2 commands.
Thanks and sorry for my delayed response.


Minor issues running README example

I tried running the examples in the README using Pytorch version 1.12.1 on a CUDA-enabled machine. I ran into two small issues at this point:
spec, w, z, ids, norm, zerr = SDSS.make_batch(data_path, ids)
with torch.no_grad():
    s, spec_rest, spec_reco = model._forward(spec, instrument=sdss, z=z)

This first was that the model.wave_rest tensor was on the GPU device while z was on the CPU, which triggered a RuntimeError here:
File ~/research/spender/spender/model.py:333, in SpectrumDecoder.transform(self, x, instrument, z)
    (...)
--> 333     wave_redshifted = (self.wave_rest.unsqueeze(1) * (1 + z)).T

This can be easily resolved with a self.wave_rest.unsqueeze(1).cpu() call.
Once that's fixed, we hit a second snag a few lines down (here I'm showing the entire error stack):
RuntimeError                              Traceback (most recent call last)
Cell In[4], line 2
      1 with torch.no_grad():
----> 2     s, spec_rest, spec_reco = model._forward(spec, instrument=sdss, z=z)

File ~/research/spender/spender/model.py:426, in BaseAutoencoder._forward(self, y, instrument, z, s, aux)
    423     instrument = self.encoder.instrument
    425 x = self.decode(s)
--> 426 y = self.decoder.transform(x, instrument=instrument, z=z)
    428 return s, x, y

File ~/research/spender/spender/model.py:340, in SpectrumDecoder.transform(self, x, instrument, z)
    337 else:
    338     wave_obs = instrument.wave_obs
--> 340 spectrum = Interp1d()(wave_redshifted, x, wave_obs)
    341
    342 # convolve with LSF
    343 if instrument.lsf is not None:

File ~/miniconda3/envs/pytorch/lib/python3.10/site-packages/torch/autograd/function.py:315, in Function.__call__(self, *args, **kwargs)
    314 def __call__(self, *args, **kwargs):
--> 315     raise RuntimeError(
    316         "Legacy autograd function with non-static forward method is deprecated. "
    317         "Please use new-style autograd function with static forward method. "
    318         "(Example: https://pytorch.org/docs/stable/autograd.html#torch.autograd.Function)")

RuntimeError: Legacy autograd function with non-static forward method is deprecated. Please use new-style autograd function with static forward method. (Example: https://pytorch.org/docs/stable/autograd.html#torch.autograd.Function)

In the updated syntax, we can simply replace line model.py:340 with:
spectrum = Interp1d.apply(wave_redshifted, x, wave_obs)

and it all works.
If I have time I'll make a PR, assuming you don't get to it first.

Hi John, thanks for the report. We're aware of both problems. For the second one, there's PR #35, I just haven't found the time to merge it yet. The the first one, we have a new branch new-aux, which will organize the input and output data in dicts, and load them all with the same method, so you wouldn't have z on a different device as the rest. If you can wait a little longer, both of these problem should be fixed.

Sounds great, and glad to hear you're on it! Will close this for now, then.

The latest main branch has the fix in for the RuntimeError. However, it looks like using dicts as input gives pretty poor performance for our data loader. Until we solve that, I recommend making sure to have all inputs to the spender functions reside on the same device. In your case, you want to make sure that z is on the GPU.


Go 1.18.8

Merge the Go 1.18.8 commits from the upstream dev.boringcrypto.go1.18 branch, currently at 94108e2.

It would be helpful if you could also add a tag for people who need that, thanks.

Merged and tagged, thanks!


Update inverter.yaml - Add pv_current

Add template sensor, deriving the PV Current from the pv_power and pv_voltage.

Thank you! I'll make a new release asap


Cannot paste in Files

Explain the bug
Cannot paste items in Files.
To reproduce

Cut or copy items in Files
Paste them in Files
Nothing happen
Paste them in File Explorer or on desktop
Successfully pasted
Can undo by Ctrl-z

Expected behavior
Just paste them in Files.
Logfile
debug.txt
debug_fulltrust.txt
System Information

OS Version:
版本	Windows 10 专业教育版
版本号	20H2
安装日期	2021-03-06
操作系统内部版本	19042.867
体验	Windows Feature Experience Pack 120.2212.551.0
Windows 10 20H2 19042.867
App version: <IP_ADDRESS>

Additional comment
I use NVMe RAID0, I'm not sure if this is a problem

Thanks for filing this issue.
Could you please test if paste does not work through the layout context menu option, through ctrl+v, or both?

Thanks for filing this issue.
Could you please test if paste does not work through the layout context menu option, through ctrl+v, or both?

both

Thanks for this additional info. This is likely a duplicate of #3615.


Publish module on Puppet Forge

Depends on #3.

All installers can now be obtained from via http://downloads.dynatracesaas.com/.


chore: Extra codes removed

Coverage remained the same at 92.308% when pulling abfa3f110175c224a1f10183e08bf89fdcd673ae on pnaik1:cleanup into 79878fd2bbe207ac3fe10e3066d5c06ce01cfd68 on nodeshift-starters:main.


Latest typeorm syntax added

unable to run the application in local my node server exit when ever i start that app


2.1.1 Constant sync loop diffs

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
After upgrading to kong 2.7.0 and kic 2.1.1 the kic update loop constantly detects changes to resources so it updates them on every loop. Previously, when no configuration would actually change it would log that it was in sync and not update anything that already exists.
Expected Behavior
Log that there was no changes detected and not update existing kong resources.
Steps To Reproduce
Below are example ingress and service resources.

Kong Ingress Controller version
2.1.1 with kong 2.7.0

Kubernetes version
1.20

Anything else?
Example of what currently happens on every sync loop.
updating <name>  {
   "algorithm": "round-robin",
   "hash_fallback": "none",
   "hash_on": "none",
   "hash_on_cookie_path": "/",
   "healthchecks": {
     "active": {
       "concurrency": 10,
       "healthy": {
         "http_statuses": [
           200,
           302
         ],
         "interval": 0,
         "successes": 0
       },
       "http_path": "/",
-      "https_verify_certificate": true,
       "timeout": 1,
       "type": "http",
       "unhealthy": {
         "http_failures": 0,
         "http_statuses": [
           429,
           404,
           500,
           501,
           502,
           503,
           504,
           505
         ],
         "interval": 0,
         "tcp_failures": 0,
         "timeouts": 0
       }
     },
     "passive": {
       "healthy": {
         "http_statuses": [
           200,
           201,
           202,
           203,
           204,
           205,
           206,
           207,
           208,
           226,
           300,
           301,
           302,
           303,
           304,
           305,
           306,
           307,
           308
         ],
         "successes": 0
       },
-      "type": "http",
       "unhealthy": {
         "http_failures": 0,
         "http_statuses": [
           429,
           500,
           503
         ],
         "tcp_failures": 0,
         "timeouts": 0
       }
     },
-    "threshold": 0
   },
   "host_header": "<name>",
   "id": "50e75021-c078-440f-ad72-0988e8b09535",
   "name": "<name>",
   "slots": 10000,
   "tags": [
     "managed-by-ingress-controller"
   ]
 }
...

creating certificate 9a9e1d9a-7eb1-43e8-bac8-de0f433eed33
updating <name>  {
   "certificate": {
-    "id": "35f22683-9119-47f3-a507-a60f282e1a30"
+    "id": "9a9e1d9a-7eb1-43e8-bac8-de0f433eed33"
   },
   "id": "8d35f194-2f80-4ddb-8b4a-3b43307e077d",
   "name": "<name>",
   "tags": [
     "managed-by-ingress-controller"
   ]
 }
...

{"level":"info","msg":"successfully synced configuration to kong.","subsystem":"proxy-cache-resolver","time":"2022-02-04T16:27:05Z"}

Example service
apiVersion: v1
kind: Service
metadata:
  annotations:
    ingress.kubernetes.io/service-upstream: "true"
    konghq.com/path: /
    konghq.com/protocol: http
    kubernetes.io/ingress.class: kong
  labels:
    app: docs-core-bank
    app.kubernetes.io/instance: "4074783313566591"
    fd: docs-core-bank
  name: docs-core-bank-kong
  namespace: core-banking
spec:
  clusterIP: <ip>
  clusterIPs:
  - <ip>
  ports:
  - name: http-docs-core-bank-80
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: docs-core-bank
  sessionAffinity: None
  type: ClusterIP

Example Ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    konghq.com/plugins: frontend-error-handling
    konghq.com/preserve-host: "true"
    konghq.com/protocols: http, https
    konghq.com/strip-path: "true"
    kubernetes.io/ingress.class: kong
  generation: 12
  labels:
    app.kubernetes.io/instance: "4074783313566591"
    fd: docs-core-bank
  name: docs-core-bank-kong
  namespace: core-banking
spec:
  rules:
  - host: <host>
    http:
      paths:
      - backend:
          service:
            name: docs-core-bank-kong
            port:
              number: 80
        path: /banking
        pathType: ImplementationSpecific
  tls:
  - hosts:
    - <host>
    secretName: <secret>
status:
  loadBalancer:
    ingress:
    - ip: <ip>

Thanks for the report. I would like to get some additional clarity on this, could you please take a look at https://docs.konghq.com/kubernetes-ingress-controller/2.1.x/troubleshooting/#dumping-generated-kong-configuration and enable config dumps and then capture a few with at least one sync before and after the problem occurs?

https://docs.konghq.com/kubernetes-ingress-controller/2.1.x/troubleshooting/#dumping-generated-kong-configuration

Before as in on KIC 1.x? Since being on KIC 2.1.1 all of the syncs are successful the only problem is that it finds those small diffs and results in unnecessary UPDATEs.
For instance here's the output from the bad syncs based on the troubleshooting doc.
cat last_bad.json | jq .
{}

The /failed endpoint is for diagnosing issues where the config does indeed not sync successfully; you can ignore it. You want to instead gather a series of configs from /successful and then diff them to determine what's actually changing from the controller's perspective. You may need to set CONTROLLER_DUMP_SENSITIVE_CONFIG=true since certificates are involved--if that's the case, describe the diff rather than uploading the complete dumps.
The controller actually performs two separate diffs during the course of an update:

The controller first generates the configuration it wishes to apply and diffs it against the previously-generated configuration. If the two are identical, the controller aborts the update.
If the two configs are not identical, the controller runs a diff between the desired state and the current state in Kong, and resolves it.

The second diff has some shortcomings that we're working to address where it handles defaults poorly: if Kong populates a default field and we didn't explicitly set the default value in the controller's expected object, the controller will attempt to clear the value (without effect, as Kong will re-populate the default). These discrepancies account for things like removing "https_verify_certificate": true from an upstream, because we haven't instructed the controller to set that by default. Future versions will populate default values based on a Kong endpoints that provides object schemas with defaults, so that we don't need to duplicate those defaults in the controller code.
Those differences, however, do not trigger updates: they exist only as differences between the desired controller state and Kong's state. In contrast, several iterations of the controller desired configuration will simply have the same value (unset) for upstream.https_verify_certificate. If some other change happens between successive desired states, however, you'll see an update, and that update will include both the actual desired changes and the unnecessary default changes.
Diffing successful configs from the diagnostic endpoint shows only the changes that actually triggered the update, not the unnecessary changes that result from default handling.

Thank you for all of that information! So here's what the diffs look like over time. All of the upstreams alternate between having targets with upstream references or not.
  "upstreams": [
    {
      "name": "web.linkerd-viz.8084.svc",
      "host_header": "web.linkerd-viz.svc",
      "algorithm": "round-robin",
      "targets": [
        {
          "target": "web.linkerd-viz.svc:8084"
        }
      ]
    },
    {
      "name": "service-core-bank-kong.core-banking.80.svc",
      "algorithm": "round-robin",
      "targets": [
        {
          "target": "service-core-bank-kong.core-banking.svc:80"
        }
      ]
    },
    {
      "name": "service-core-bank-gateway-kong.core-banking.80.svc",
      "algorithm": "round-robin",
      "targets": [
        {
          "target": "service-core-bank-gateway-kong.core-banking.svc:80"
        }
      ]
    },
    {
      "name": "https-mockbin-kong.core-banking.443.svc",
      "algorithm": "round-robin",
      "targets": [
        {
          "target": "mockbin.org:443"
        }
      ]
    },
    {
      "name": "docs-figurepay-partner-api-kong.figurepay.80.svc",
      "algorithm": "round-robin",
      "targets": [
        {
          "target": "docs-figurepay-partner-api-kong.figurepay.svc:80"
        }
      ]
    },
    {
      "name": "docs-core-bank-kong.core-banking.80.svc",
      "algorithm": "round-robin",
      "targets": [
        {
          "target": "docs-core-bank-kong.core-banking.svc:80"
        }
      ]
    }
  ]

  "upstreams": [
    {
      "name": "web.linkerd-viz.8084.svc",
      "host_header": "web.linkerd-viz.svc",
      "algorithm": "round-robin",
      "targets": [
        {
          "target": "web.linkerd-viz.svc:8084",
          "upstream": {
            "id": "1703351c-70c6-4b6f-86ac-73b7ac10b9f5"
          }
        }
      ]
    },
    {
      "name": "service-core-bank-kong.core-banking.80.svc",
      "algorithm": "round-robin",
      "targets": [
        {
          "target": "service-core-bank-kong.core-banking.svc:80",
          "upstream": {
            "id": "2753ffd1-e58d-4878-93e1-ae109b1cd8ca"
          }
        }
      ]
    },
    {
      "name": "service-core-bank-gateway-kong.core-banking.80.svc",
      "algorithm": "round-robin",
      "targets": [
        {
          "target": "service-core-bank-gateway-kong.core-banking.svc:80",
          "upstream": {
            "id": "3dcfdf91-e85a-46ab-9058-5fbf2ad6b7f9"
          }
        }
      ]
    },
    {
      "name": "https-mockbin-kong.core-banking.443.svc",
      "algorithm": "round-robin",
      "targets": [
        {
          "target": "mockbin.org:443",
          "upstream": {
            "id": "0cb635a3-f403-4235-bcd7-5d373ac478db"
          }
        }
      ]
    },
    {
      "name": "docs-figurepay-partner-api-kong.figurepay.80.svc",
      "algorithm": "round-robin",
      "targets": [
        {
          "target": "docs-figurepay-partner-api-kong.figurepay.svc:80",
          "upstream": {
            "id": "013c9998-5276-41cf-8f9e-c12cee22aeef"
          }
        }
      ]

Nothing else changes? That's quite odd. I can't replicate it myself, and can't really see how it would happen--there shouldn't be any way to set that field at all. Are you able to provide a complete Ingress/Service/Deployment and controller settings example that can replicate this reliably? I've tried to get as close to the earlier examples as possible, but there's still something I'm apparently missing.
To expand on why this shouldn't happen, the target controller state generally doesn't know about entity IDs (other than client certificates): they're dynamically resolved to existing or new IDs when comparing against the current Kong state.
There furthermore shouldn't be any way to insert the upstream reference there in the target state: the code omits that field entirely:
https://github.com/Kong/kubernetes-ingress-controller/blob/v2.2.0/internal/dataplane/parser/parser.go#L480-L492
and the upstream builder doesn't insert them after:
https://github.com/Kong/kubernetes-ingress-controller/blob/v2.2.0/internal/dataplane/parser/parser.go#L235-L247
nor do we manipulate them when composing the deck structs:
https://github.com/Kong/kubernetes-ingress-controller/blob/v2.2.0/internal/dataplane/deckgen/generate.go#L91-L94
grepping the codebase doesn't show anything that looks like it's setting target.Upstream:
$ git grep -r "\.Upstream" | grep -v Upstreams
internal/dataplane/deckgen/generate.go:		fillUpstream(&u.Upstream)
internal/dataplane/deckgen/generate.go:		upstream := file.FUpstream{Upstream: u.Upstream}
internal/dataplane/deckgen/generate.go:func fillUpstream(upstream *kong.Upstream) {
internal/dataplane/kongstate/upstream.go:	kong.Upstream
internal/dataplane/kongstate/upstream.go:	if kongIngress == nil || kongIngress.Upstream == nil {
internal/dataplane/kongstate/upstream.go:	k := kongIngress.Upstream
internal/dataplane/parser/parser.go:	log logrus.FieldLogger, s store.Storer, serviceMap map[string]kongstate.Service) []kongstate.Upstream {
internal/dataplane/parser/parser.go:	upstreams := make([]kongstate.Upstream, 0, len(serviceMap))
internal/dataplane/parser/parser.go:			upstream := kongstate.Upstream{
internal/dataplane/parser/parser.go:				Upstream: kong.Upstream{
pkg/apis/configuration/v1/kongingress_types.go://+ It contains the subset of go-kong.kong.Upstream fields supported by kongstate.Upstream.overrideByKongIngress

$ git grep -r "Upstream:"
internal/dataplane/deckgen/generate.go:         upstream := file.FUpstream{Upstream: u.Upstream}
internal/dataplane/parser/parser.go:                            Upstream: kong.Upstream{

or anything that looks like it could populate an upstream ID:
$ git grep -r "\.ID"
internal/dataplane/deckgen/deckgen.go:  if kongCert.ID != nil {
internal/dataplane/deckgen/deckgen.go:          res.ID = kong.String(*kongCert.ID)
internal/dataplane/deckgen/deckgen.go:  if plugin.Consumer != nil && plugin.Consumer.ID != nil {
internal/dataplane/deckgen/deckgen.go:          result += *plugin.Consumer.ID
internal/dataplane/deckgen/deckgen.go:  if plugin.Route != nil && plugin.Route.ID != nil {
internal/dataplane/deckgen/deckgen.go:          result += *plugin.Route.ID
internal/dataplane/deckgen/deckgen.go:  if plugin.Service != nil && plugin.Service.ID != nil {
internal/dataplane/deckgen/deckgen.go:          result += *plugin.Service.ID
internal/dataplane/kongstate/credentials.go:                    ID:        c.ID,
internal/dataplane/kongstate/credentials.go:                    ID:        c.ID,
internal/dataplane/kongstate/credentials.go:                    ID:           c.ID,
internal/dataplane/kongstate/credentials.go:                    ID:        c.ID,
internal/dataplane/kongstate/credentials.go:                    ID:           c.ID,
internal/dataplane/kongstate/types.go:                  ID:        c.ID,
internal/dataplane/parser/parser.go:                            kongCert.cert.ID = kong.String(string(secret.UID))
internal/util/reports.go:       serializedInfo = serializedInfo + "id=" + r.Info.ID + ";"

My next step would be to hook up a debugger and step through the code to see where these are getting injected, but I'd need a set of manifests and options that actually allow me to reproduce it.

Any debug or trace logging that would help me get more info?

Here's the full redacted contents and the diff. I verified for multiple change iterations that it always goes back and forth between these two. The summary of the changes are:

routes get service id references
targets get upstream id references
and the certificate id changes

{
  "_format_version": "1.1",
  "_info": {
    "select_tags": [
      "managed-by-ingress-controller"
    ],
    "defaults": {}
  },
  "services": [
    {
      "connect_timeout": 60000,
      "host": "web.linkerd-viz.8084.svc",
      "name": "linkerd-viz.web.pnum-8084",
      "path": "/",
      "port": 80,
      "protocol": "http",
      "read_timeout": 60000,
      "retries": 5,
      "write_timeout": 60000,
      "routes": [
        {
          "hosts": [
            "REDACTED"
          ],
          "name": "linkerd-viz.linkerd-dashboard.00",
          "paths": [
            "/"
          ],
          "path_handling": "v0",
          "preserve_host": false,
          "protocols": [
            "https"
          ],
          "regex_priority": 200,
          "service": {
            "id": "b4c5df29-0c9a-401c-b9d3-5f622c6ce6d4"
          },
          "strip_path": false,
          "https_redirect_status_code": 426,
          "request_buffering": true,
          "response_buffering": true
        }
      ]
    },
    {
      "connect_timeout": 60000,
      "host": "docs-comp-partner-api-kong.comp.80.svc",
      "name": "comp.docs-comp-partner-api-kong.pnum-80",
      "path": "/",
      "port": 80,
      "protocol": "http",
      "read_timeout": 60000,
      "retries": 5,
      "write_timeout": 60000,
      "routes": [
        {
          "hosts": [
            "REDACTED"
          ],
          "name": "comp.docs-comp-partner-api-kong.00",
          "paths": [
            "/partner"
          ],
          "path_handling": "v0",
          "preserve_host": true,
          "protocols": [
            "http",
            "https"
          ],
          "regex_priority": 100,
          "service": {
            "id": "05a21c2c-2b4f-4a2a-8b20-32064a53ab20"
          },
          "strip_path": true,
          "https_redirect_status_code": 426,
          "request_buffering": true,
          "response_buffering": true
        }
      ]
    },
    {
      "connect_timeout": 60000,
      "host": "service-core-bank-kong.core-banking.80.svc",
      "name": "core-banking.service-core-bank-kong.pnum-80",
      "path": "/service-core-bank/secure",
      "port": 80,
      "protocol": "http",
      "read_timeout": 60000,
      "retries": 5,
      "write_timeout": 60000,
      "routes": [
        {
          "hosts": [
            "REDACTED"
          ],
          "name": "core-banking.service-core-bank-kong.00",
          "paths": [
            "/"
          ],
          "path_handling": "v0",
          "preserve_host": true,
          "protocols": [
            "http",
            "https"
          ],
          "regex_priority": 100,
          "service": {
            "id": "1dfb680c-4483-479c-a851-dc4413c0d969"
          },
          "strip_path": true,
          "https_redirect_status_code": 426,
          "request_buffering": true,
          "response_buffering": true
        }
      ]
    },
    {
      "connect_timeout": 60000,
      "host": "service-core-bank-gateway-kong.core-banking.80.svc",
      "name": "core-banking.service-core-bank-gateway-kong.pnum-80",
      "path": "/service-core-bank-gateway",
      "port": 80,
      "protocol": "http",
      "read_timeout": 60000,
      "retries": 5,
      "write_timeout": 60000,
      "routes": [
        {
          "hosts": [
            "REDACTED"
          ],
          "name": "core-banking.service-core-bank-gateway-kong.00",
          "paths": [
            "/service-core-bank-gateway"
          ],
          "path_handling": "v0",
          "preserve_host": true,
          "protocols": [
            "http",
            "https"
          ],
          "regex_priority": 100,
          "service": {
            "id": "4c94ff76-9986-404c-9da9-882916de3eba"
          },
          "strip_path": true,
          "https_redirect_status_code": 426,
          "request_buffering": true,
          "response_buffering": true
        }
      ]
    },
    {
      "connect_timeout": 60000,
      "host": "https-mockbin-kong.core-banking.443.svc",
      "name": "core-banking.https-mockbin-kong.pnum-443",
      "path": "/",
      "port": 80,
      "protocol": "https",
      "read_timeout": 60000,
      "retries": 5,
      "write_timeout": 60000,
      "routes": [
        {
          "hosts": [
            "REDACTED"
          ],
          "name": "core-banking.https-mockbin-kong.00",
          "paths": [
            "/mockbin"
          ],
          "path_handling": "v0",
          "preserve_host": true,
          "protocols": [
            "http",
            "https"
          ],
          "regex_priority": 100,
          "service": {
            "id": "162baa90-7631-4dc6-9dc0-28a194c1a76b"
          },
          "strip_path": true,
          "https_redirect_status_code": 426,
          "request_buffering": true,
          "response_buffering": true
        }
      ]
    },
    {
      "connect_timeout": 60000,
      "host": "docs-core-bank-kong.core-banking.80.svc",
      "name": "core-banking.docs-core-bank-kong.pnum-80",
      "path": "/",
      "port": 80,
      "protocol": "http",
      "read_timeout": 60000,
      "retries": 5,
      "write_timeout": 60000,
      "routes": [
        {
          "hosts": [
            "REDACTED"
          ],
          "name": "core-banking.docs-core-bank-kong.00",
          "paths": [
            "/banking"
          ],
          "path_handling": "v0",
          "preserve_host": true,
          "protocols": [
            "http",
            "https"
          ],
          "regex_priority": 100,
          "service": {
            "id": "ede032d2-bf96-454b-b210-8a6e1a08618b"
          },
          "strip_path": true,
          "https_redirect_status_code": 426,
          "request_buffering": true,
          "response_buffering": true
        }
      ]
    }
  ],
  "plugins": [
    {
      "name": "ip-restriction",
      "config": {
        "allow": [
          "REDACTED"
        ],
        "deny": null,
        "message": null,
        "status": null
      },
      "route": "linkerd-viz.linkerd-dashboard.00",
      "enabled": true,
      "protocols": [
        "http",
        "https"
      ]
    },
    {
      "name": "ip-restriction",
      "config": {
        "allow": [
          "REDACTED"
        ],
        "deny": null,
        "message": null,
        "status": null
      },
      "route": "core-banking.service-core-bank-gateway-kong.00",
      "enabled": true,
      "protocols": [
        "http",
        "https"
      ]
    }
  ],
  "upstreams": [
    {
      "name": "web.linkerd-viz.8084.svc",
      "host_header": "web.linkerd-viz.svc",
      "algorithm": "round-robin",
      "targets": [
        {
          "target": "web.linkerd-viz.svc:8084",
          "upstream": {
            "id": "c2cac10d-1376-48bd-be7a-129325832095"
          }
        }
      ]
    },
    {
      "name": "service-core-bank-kong.core-banking.80.svc",
      "algorithm": "round-robin",
      "targets": [
        {
          "target": "service-core-bank-kong.core-banking.svc:80",
          "upstream": {
            "id": "d93c0562-3bc1-4c8e-92a4-2d66a9de4cfb"
          }
        }
      ]
    },
    {
      "name": "service-core-bank-gateway-kong.core-banking.80.svc",
      "algorithm": "round-robin",
      "targets": [
        {
          "target": "service-core-bank-gateway-kong.core-banking.svc:80",
          "upstream": {
            "id": "a45a6b08-276f-4ede-ac2e-19c89b51d1eb"
          }
        }
      ]
    },
    {
      "name": "https-mockbin-kong.core-banking.443.svc",
      "algorithm": "round-robin",
      "targets": [
        {
          "target": "mockbin.org:443",
          "upstream": {
            "id": "822f069e-852c-4d5e-97a7-59a404f48377"
          }
        }
      ]
    },
    {
      "name": "docs-comp-partner-api-kong.comp.80.svc",
      "algorithm": "round-robin",
      "targets": [
        {
          "target": "docs-comp-partner-api-kong.comp.svc:80",
          "upstream": {
            "id": "f124c3c2-1322-4fbb-8392-1e04ac9d4431"
          }
        }
      ]
    },
    {
      "name": "docs-core-bank-kong.core-banking.80.svc",
      "algorithm": "round-robin",
      "targets": [
        {
          "target": "docs-core-bank-kong.core-banking.svc:80",
          "upstream": {
            "id": "aec08583-d364-4113-954d-c0e8114ec3fa"
          }
        }
      ]
    }
  ],
  "certificates": [
    {
      "id": "9a9e1d9a-7eb1-43e8-bac8-de0f433eed33",
      "cert": "REDACTED",
      "key": "REDACTED",
      "snis": [
        {
          "name": "REDACTED"
        },
        {
          "name": "REDACTED"
        },
        {
          "name": "REDACTED"
        }
      ]
    }
  ]
}

  "_format_version": "1.1",
  "_info": {
    "select_tags": [
      "managed-by-ingress-controller"
    ],
    "defaults": {}
  },
  "services": [
    {
      "connect_timeout": 60000,
      "host": "web.linkerd-viz.8084.svc",
      "name": "linkerd-viz.web.pnum-8084",
      "path": "/",
      "port": 80,
      "protocol": "http",
      "read_timeout": 60000,
      "retries": 5,
      "write_timeout": 60000,
      "routes": [
        {
          "hosts": [
            "REDACTED"
          ],
          "name": "linkerd-viz.linkerd-dashboard.00",
          "paths": [
            "/"
          ],
          "path_handling": "v0",
          "preserve_host": false,
          "protocols": [
            "https"
          ],
          "regex_priority": 200,
          "strip_path": false,
          "https_redirect_status_code": 426,
          "request_buffering": true,
          "response_buffering": true
        }
      ]
    },
    {
      "connect_timeout": 60000,
      "host": "docs-comp-partner-api-kong.comp.80.svc",
      "name": "comp.docs-comp-partner-api-kong.pnum-80",
      "path": "/",
      "port": 80,
      "protocol": "http",
      "read_timeout": 60000,
      "retries": 5,
      "write_timeout": 60000,
      "routes": [
        {
          "hosts": [
            "REDACTED"
          ],
          "name": "comp.docs-comp-partner-api-kong.00",
          "paths": [
            "/partner"
          ],
          "path_handling": "v0",
          "preserve_host": true,
          "protocols": [
            "http",
            "https"
          ],
          "regex_priority": 100,
          "strip_path": true,
          "https_redirect_status_code": 426,
          "request_buffering": true,
          "response_buffering": true
        }
      ]
    },
    {
      "connect_timeout": 60000,
      "host": "service-core-bank-kong.core-banking.80.svc",
      "name": "core-banking.service-core-bank-kong.pnum-80",
      "path": "/service-core-bank/secure",
      "port": 80,
      "protocol": "http",
      "read_timeout": 60000,
      "retries": 5,
      "write_timeout": 60000,
      "routes": [
        {
          "hosts": [
            "REDACTED"
          ],
          "name": "core-banking.service-core-bank-kong.00",
          "paths": [
            "/"
          ],
          "path_handling": "v0",
          "preserve_host": true,
          "protocols": [
            "http",
            "https"
          ],
          "regex_priority": 100,
          "strip_path": true,
          "https_redirect_status_code": 426,
          "request_buffering": true,
          "response_buffering": true
        }
      ]
    },
    {
      "connect_timeout": 60000,
      "host": "service-core-bank-gateway-kong.core-banking.80.svc",
      "name": "core-banking.service-core-bank-gateway-kong.pnum-80",
      "path": "/service-core-bank-gateway",
      "port": 80,
      "protocol": "http",
      "read_timeout": 60000,
      "retries": 5,
      "write_timeout": 60000,
      "routes": [
        {
          "hosts": [
            "REDACTED"
          ],
          "name": "core-banking.service-core-bank-gateway-kong.00",
          "paths": [
            "/service-core-bank-gateway"
          ],
          "path_handling": "v0",
          "preserve_host": true,
          "protocols": [
            "http",
            "https"
          ],
          "regex_priority": 100,
          "strip_path": true,
          "https_redirect_status_code": 426,
          "request_buffering": true,
          "response_buffering": true
        }
      ]
    },
    {
      "connect_timeout": 60000,
      "host": "https-mockbin-kong.core-banking.443.svc",
      "name": "core-banking.https-mockbin-kong.pnum-443",
      "path": "/",
      "port": 80,
      "protocol": "https",
      "read_timeout": 60000,
      "retries": 5,
      "write_timeout": 60000,
      "routes": [
        {
          "hosts": [
            "REDACTED"
          ],
          "name": "core-banking.https-mockbin-kong.00",
          "paths": [
            "/mockbin"
          ],
          "path_handling": "v0",
          "preserve_host": true,
          "protocols": [
            "http",
            "https"
          ],
          "regex_priority": 100,
          "strip_path": true,
          "https_redirect_status_code": 426,
          "request_buffering": true,
          "response_buffering": true
        }
      ]
    },
    {
      "connect_timeout": 60000,
      "host": "docs-core-bank-kong.core-banking.80.svc",
      "name": "core-banking.docs-core-bank-kong.pnum-80",
      "path": "/",
      "port": 80,
      "protocol": "http",
      "read_timeout": 60000,
      "retries": 5,
      "write_timeout": 60000,
      "routes": [
        {
          "hosts": [
            "REDACTED"
          ],
          "name": "core-banking.docs-core-bank-kong.00",
          "paths": [
            "/banking"
          ],
          "path_handling": "v0",
          "preserve_host": true,
          "protocols": [
            "http",
            "https"
          ],
          "regex_priority": 100,
          "strip_path": true,
          "https_redirect_status_code": 426,
          "request_buffering": true,
          "response_buffering": true
        }
      ]
    }
  ],
  "plugins": [
    {
      "name": "ip-restriction",
      "config": {
        "allow": [
          "REDACTED"
        ],
        "deny": null,
        "message": null,
        "status": null
      },
      "route": "linkerd-viz.linkerd-dashboard.00",
      "enabled": true,
      "protocols": [
        "http",
        "https"
      ]
    },
    {
      "name": "ip-restriction",
      "config": {
        "allow": [
          "REDACTED"
        ],
        "deny": null,
        "message": null,
        "status": null
      },
      "route": "core-banking.service-core-bank-gateway-kong.00",
      "enabled": true,
      "protocols": [
        "http",
        "https"
      ]
    }
  ],
  "upstreams": [
    {
      "name": "web.linkerd-viz.8084.svc",
      "host_header": "web.linkerd-viz.svc",
      "algorithm": "round-robin",
      "targets": [
        {
          "target": "web.linkerd-viz.svc:8084"
        }
      ]
    },
    {
      "name": "service-core-bank-kong.core-banking.80.svc",
      "algorithm": "round-robin",
      "targets": [
        {
          "target": "service-core-bank-kong.core-banking.svc:80"
        }
      ]
    },
    {
      "name": "service-core-bank-gateway-kong.core-banking.80.svc",
      "algorithm": "round-robin",
      "targets": [
        {
          "target": "service-core-bank-gateway-kong.core-banking.svc:80"
        }
      ]
    },
    {
      "name": "https-mockbin-kong.core-banking.443.svc",
      "algorithm": "round-robin",
      "targets": [
        {
          "target": "mockbin.org:443"
        }
      ]
    },
    {
      "name": "docs-comp-partner-api-kong.comp.80.svc",
      "algorithm": "round-robin",
      "targets": [
        {
          "target": "docs-comp-partner-api-kong.comp.svc:80"
        }
      ]
    },
    {
      "name": "docs-core-bank-kong.core-banking.80.svc",
      "algorithm": "round-robin",
      "targets": [
        {
          "target": "docs-core-bank-kong.core-banking.svc:80"
        }
      ]
    }
  ],
  "certificates": [
    {
      "id": "35f22683-9119-47f3-a507-a60f282e1a30",
      "cert": "REDACTED",
      "key": "REDACTED",
      "snis": [
        {
          "name": "REDACTED"
        },
        {
          "name": "REDACTED"
        },
        {
          "name": "REDACTED"
        }
      ]
    }
  ]
}

1c1
< {
---
>
35,37d34
<           "service": {
<             "id": "b4c5df29-0c9a-401c-b9d3-5f622c6ce6d4"
<           },
71,73d67
<           "service": {
<             "id": "05a21c2c-2b4f-4a2a-8b20-32064a53ab20"
<           },
107,109d100
<           "service": {
<             "id": "1dfb680c-4483-479c-a851-dc4413c0d969"
<           },
143,145d133
<           "service": {
<             "id": "4c94ff76-9986-404c-9da9-882916de3eba"
<           },
179,181d166
<           "service": {
<             "id": "162baa90-7631-4dc6-9dc0-28a194c1a76b"
<           },
215,217d199
<           "service": {
<             "id": "ede032d2-bf96-454b-b210-8a6e1a08618b"
<           },
269,272c251
<           "target": "web.linkerd-viz.svc:8084",
<           "upstream": {
<             "id": "c2cac10d-1376-48bd-be7a-129325832095"
<           }
---
>           "target": "web.linkerd-viz.svc:8084"
281,284c260
<           "target": "service-core-bank-kong.core-banking.svc:80",
<           "upstream": {
<             "id": "d93c0562-3bc1-4c8e-92a4-2d66a9de4cfb"
<           }
---
>           "target": "service-core-bank-kong.core-banking.svc:80"
293,296c269
<           "target": "service-core-bank-gateway-kong.core-banking.svc:80",
<           "upstream": {
<             "id": "a45a6b08-276f-4ede-ac2e-19c89b51d1eb"
<           }
---
>           "target": "service-core-bank-gateway-kong.core-banking.svc:80"
305,308c278
<           "target": "mockbin.org:443",
<           "upstream": {
<             "id": "822f069e-852c-4d5e-97a7-59a404f48377"
<           }
---
>           "target": "mockbin.org:443"
317,320c287
<           "target": "docs-comp-partner-api-kong.comp.svc:80",
<           "upstream": {
<             "id": "f124c3c2-1322-4fbb-8392-1e04ac9d4431"
<           }
---
>           "target": "docs-comp-partner-api-kong.comp.svc:80"
329,332c296
<           "target": "docs-core-bank-kong.core-banking.svc:80",
<           "upstream": {
<             "id": "aec08583-d364-4113-954d-c0e8114ec3fa"
<           }
---
>           "target": "docs-core-bank-kong.core-banking.svc:80"
339c303
<       "id": "9a9e1d9a-7eb1-43e8-bac8-de0f433eed33",
---
>       "id": "35f22683-9119-47f3-a507-a60f282e1a30",

Small sampling to show the frequency of the updates

Any debug or trace logging that would help me get more info?

Not really--there's not much logging for the internal translation between different types of structs, and there's not an obvious place in the code where this should occur, so it's not clear where we'd actually want to log, so having some minimal set of Kubernetes resources that replicates it would be ideal, to allow us to interactively inspect state at arbitrary points in execution.
Are you able to run with a debug build? We do at least know the points where we convert between the different structs, so if nothing else I can add additional logs that dump JSON versions of those to try and narrow down exactly when the additional field is inserted.

A debug build would be helpful. I'm able to easily run that in this environment.

The traines/kic:2.1.1-target-debug image includes https://github.com/Kong/kubernetes-ingress-controller/commit/7af1706f267b8f00b743c2f9d37b76958e8f1018
Target generation will produce logs like these:
time="2022-02-11T13:35:46-08:00" level=debug msg="TRG targetsForEndpoints generated target set: [{\"target\":\"<IP_ADDRESS>:80\"}]" service_name=httpbin service_namespace=73677a42-4194-4211-b8b7-dfc2b5a684f2 service_port="&ServicePort{Name:,Protocol:TCP,Port:80,TargetPort:{0 80 },NodePort:31524,AppProtocol:nil,}" subsystem=proxy-cache-resolver
time="2022-02-11T13:35:46-08:00" level=debug msg="TRG getUpstreams upstream httpbin.73677a42-4194-4211-b8b7-dfc2b5a684f2.80.svc has target set: [{\"target\":\"<IP_ADDRESS>:80\"}]" subsystem=proxy-cache-resolver
time="2022-02-11T13:35:46-08:00" level=debug msg="TRG ToDeckContent upstream httpbin.73677a42-4194-4211-b8b7-dfc2b5a684f2.80.svc has target set: [{\"target\":\"<IP_ADDRESS>:80\"}]" subsystem=proxy-cache-resolver

Thank you!

@rainest is there a setting for turning on debug log level?


ARROW-4423: [WIP][C++] Upgrade vendored gmock to 1.8.1

Rebased.

I can try to look at the Windows build later if you can't figure it out. BTW you can get free Windows 10 ISO from Microsoft so setting up a windows dev environment isn't as hard as you might think

Thanks.  I think I should be able to handle everything.  My first step is
to figure out Trusty errors (I also have a Windows VM) setup so I can look
at that as well it might just take a little while.
On Saturday, February 9, 2019, Wes McKinney<EMAIL_ADDRESS>wrote:

I can try to look at the Windows build later if you can't figure it out.
BTW you can get free Windows 10 ISO from Microsoft so setting up a windows
dev environment isn't as hard as you might think
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/apache/arrow/pull/3589#issuecomment-462080141, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ARCsDuTgy7N3fiVIbWUZ_yD0AgTGqMFmks5vLzq4gaJpZM4at3v8
.

Codecov Report

Merging #3589 into master will increase coverage by 0.85%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #3589      +/-   ##
==========================================
+ Coverage   87.76%   88.62%   +0.85%
==========================================
  Files         673      544     -129
  Lines       82763    73796    -8967
  Branches     1069        0    -1069
==========================================
- Hits        72640    65400    -7240
+ Misses      10012     8396    -1616
+ Partials      111        0     -111

Impacted Files
Coverage Δ

cpp/src/arrow/csv/column-builder.cc
95.39% <0%> (-1.98%)
:arrow_down:

cpp/src/plasma/thirdparty/ae/ae.c
71.09% <0%> (-0.95%)
:arrow_down:

go/arrow/math/uint64_amd64.go

go/arrow/memory/memory_avx2_amd64.go

js/src/enum.ts

go/arrow/array/builder.go

js/src/Arrow.node.ts

js/src/schema.ts

go/arrow/type_traits_boolean.go

js/src/ipc/node/writer.ts

... and 121 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7f13b70...200dec7. Read the comment docs.


Shuffle samples, then batch, to make order independent of batch size

Currently a frozen_batches is kept during shuffling, which makes the samples ordering not independent of batch size, it also defies the purpose of shuffling as some batches will always be the same.
This might be smart if some batches are of smaller samples than others and the batch size can be dynamically adjusted, but outside that specific scenario, sample-based shuffling seems more correct and helpful during debugging, etc.
This PR introduces sample-based shuffling as default, and keeps batch-based shuffling as keyword arg to the EpochBatchIterator

Seems similar behaviour can be obtained by:

Adding to the unicore task

def disable_shuffling(self) -> bool:
        return True

including an EpochShuffleDataset as part of the task dataset, which uses the seed+epoch number to iteratively shuffle the data.
So I'm closing this PR.