merge country and centre-id

As discussed at TT-WISMD 2023-09 face-to-face, as well as W2AT 2023-09-18
Proposal for adapting WTH to merge and country and centre-id
Overview
WTH levels 4/5 describe country and centre-id as follows:

country: Lower case representation of ISO3166 3-letter code. Includes extensions for partner organizations
centre-id: Acronym as specified by member and endorsed by the PR of the country and by WMO

Issues with country

ambiguous meaning/role

issuing centre?  PR representation/member? location of data?

ambiguous coupling / relationship of centres and countries (one to many)
can create numerous permutations of topics
increase the difficulty to find the datasets users are interested in as they first have to understand from which country and then centre it comes from. For instance, the country code for international organizations is really not obvious for non-knowledgeable users.

Proposal
Remove country and define the centre-id on reverse hostname notation (starting with TLD) into a single compound level.  In other words, the citation authority based on the Internet domain name of the issuing centre.
Examples:

ca.gc.ec.msc
uk.gov.metoffice
fr.meteo
int.eumetsat
de.dwd
gov.noaa
cn.gov.cma
test.wis2node1

Benefits

clearer attribution to the issuing centre
reduces WTH by one level
WTH validation becomes easier for runtime
Same notation and practice as in the WIS 1 and on the Web. Users are already familiar with it and know the centre ids for WIS1 users.

Implications

dotted notation may or may not be problematic for AMQP-based implementations

however, MQTT is the requirement for WIS2, so this is an implementation detail

Change management

Update to WIS2 Nodes, Global Brokers, and clients

Additional notes following discussion at W2AT:

related issues are #22, #33 and #51
convention:

dashes may be better than dots (so as not to confuse TLD)
we can also consult WMO 386 for nomenclature

Extract from WMO 386 :

It looks like fr-meteofrance-toulouse or xx-eumetsat-darmstadt
There must be a list of already approved "organization".  @efucile Are you aware of something ?
Then for "the production centre" (above toulouse or darmstadt) we may want to give a different production centre name per NC/DCPC operated by the organization.

If there is a list of organizations / production centres, we could refer to it. Otherwise I would be careful directly referencing publication 386 as that one is going to be obsolete. When it concerns dots vs dashes, well, dots are more "natural", but sure we can get used to dashes.

I don't know of such a list. Referring to 386 is not under discussion as it will be retired. We could adapt the text and insert it in the WIS Guide. Are we sure we want to go for the 2-letter code? I think that we have already decided to use the 3-letter code.

The idea is to reuse some of the wording of WMO 386 and not refer to WMO 386.
And if we merge country and centre-id, then going to 2-letter code has some "logic" for the merge country-centre-id to look like a reverse DNS name.

The Reverse DNS name is familiar to many people. I would go for it and avoid -
Is the new country-centre-id a unique identifier for a WIS2 node? Can we have two nodes with the same country-center-id?

We want to be on the safe side and avoid "." in the topic hierarchy (it may create with some MQP protocols). And, as GTS people have been really wise in defining in the file name convention almost like reverse DNS we propose to stick to this.
Then, as for the DNS, we can have multiple names in the same domain.
So, with this kind of reverse notation, we could have something like (using Météo-France as an exemple):
fr-meteofrance-vaac for our duty on Volcanic ashes
fr-meteofrance-nwp for our NWP products
...
There are two benefits in merging country and centre-id.

a minor one (for me) by removing one level in the topic hierarchy
an important one to be able to assess whether the topic is valid without any ambiguity. With country and centre-id at two levels, we didn't have that easily this feature.

There are two benefits in merging country and centre-id.

a minor one (for me) by removing one level in the topic hierarchy
an important one to be able to assess whether the topic is valid without any ambiguity. With country and centre-id at two levels, we didn't have that easily this feature.

I agree completely.

I support merging the country and centre-id by reusing the "location indicator" developed for the General File Naming Convention in 386. In addition to the good reasons given above, we can see that for many years this has proved to be an effective mechanism (especially once we sorted out the niggle with uppercase characters in 3166!). I don't believe that either the organization or the production centre com from a controlled list, but using the DCPC is a logical approach.

The purpose of the controlled list is to limit/avoid the creativity in naming the centre-id :) and to get a consistent approach.
See https://github.com/wmo-im/wis2-topic-hierarchy/issues/51
Typically, at the moment, we have no rule, and we have for example country_wis2node as centre-id.
Something like fr-france_wis2node should be avoided.

Do I understand correctly that if you go ahead and merge country and centre-id levels, it will require a bump of version to "b" ? it should be mentioned in the top level proposal.

Good point.  That is debatable given the current state/phase of the specifications.

At the moment, being in the pilot phase, I would stick to "a" for the version of the topic hierarchy.  Having some "agility" in the pilot phase is needed.
Also considering that Global Caches are subscribing to origin/a/wis2/# it won't break anything there.

TT-WISMD 2023-10-06:
Proposal being: xx-xxxxx
where:

dash separated
token 1:

options:

TLD (i.e. fr, de, ca, int, org, test)
reuse country-code as current (3166 alpha3)

token 2: centre name (can include dashes)

Using reverse DNS notation has the benefit of guaranteeing uniqueness. But if a centre wants to use a slightly modified version of it, e.g.:

us-noaa-... instead of gov-noaa-...; or
uk-metoffice-... instead of uk-gov-metoffice-...

there is no reason to disagree. There will still be a registration process for centre IDs to ensure uniqueness.
Most importantly, in my opinion, we should not force international organizations to use the prefix xx- or xxg- instead of the well-established and understandable int- or org-.

TT W2AT 2023-10-16:

TLDs are managed by IANA already, can reuse

W2AT prefers/suggests TLD

based on https://github.com/wmo-im/wis2-topic-hierarchy/issues/58#issuecomment-1750773301
tokens can be additionally added to further delineate

TT-WISMD will provide final proposal on 2023-10-23

Thanks @tomkralidis ... and confirming the ET-W2AT position. We noted the need to standardise on either option (a) or (b) for Token 1 in your comment above, rather than allow a user to choose from those options.
I think the proposal we have is:
<token1>-<token2>
where:
<token1> = TLD, as defined by IANA here
and
<token2> = centre name - which may be a - (dash) separated set of labels
Commonly, this may resemble the reverse DNS notation of the WIS Centre. Also note that larger organisations may host multiple WIS2 nodes, each of which can be given an alternative designation.
Examples:
fr-meteo-vaac
fr-meteo-nmc
etc.
More examples would be useful.

So in implementation one would, say:
centre_id = 'fr-meteo-vaac'
print(centre_id.split('-', 1)) # split only on the FIRST occurrence of dash
['fr', 'meteo-vaac']

@golfvert : let's say one wanted to enumerate or group all active topics based on TLD.  This is an unvalidated use case at the moment, but it will likely surface.
Regarding the NOAA use case, I would say that NOAA chooses what that is, as long as its based on a TLD.

OK. So, you want all to identify all French products ? Maybe...
Anna mentioned that having something consistent would be good.
So, keeping "gov" or not (which can be "gob" in other languages) should be clear a recommendation (a MUST ?) to be consistent.
Same for USA Centres. Shall we "move" them to us- ? Or each one will choose ?

Using reverse DNS notation has the benefit of guaranteeing uniqueness. But if a centre wants to use a slightly modified version of it, e.g.:

us-noaa-... instead of gov-noaa-...; or
uk-metoffice-... instead of uk-gov-metoffice-...

there is no reason to disagree. There will still be a registration process for centre IDs to ensure uniqueness. Most importantly, in my opinion, we should not force international organizations to use the prefix xx- or xxg- instead of the well-established and understandable int- or org-.

Not forcing international organizations into "xx" is a good idea. We have used "XX" from the General File Naming Convention in 386 for a long time (XX-EUMETSAT-Darmstadt) and "xxf" was not really an improvement. "int" would be much better.

@tomkralidis, @golfvert - can we conclude the discussion on this and update the proposal outlined at the top of this thread? I think the only outstanding issue is a recommendation on the use of "gov" (or "gob").

TT-WISMD 2023-10-23:

RE: 'gov', 'gob'

SHOULD put forth country, not 'gov', 'gob'
international organizations (like ECMWF, EUMETSAT) SHOULD use 'int', or 'org', as per what they are already using

Proposal:

bound to data publisher
single identifier
no dots/slashes/special characters
<token1>-<token2>, where:
token 1 = TLD
token 2 = centre name (which could include dashes)

That is actually an expanded token 2 (which itself can include dashes).  Regardless, will add text to the specification to articulate SHALL/SHOULD/MAY.

PR in #64

The examples in the topic hierarchy document use the iso3c country code (deu-dwd) instead of the TLD (de-dwd)

Good catch @kaiwirt; fixed in PR #58.

#58 merged.


Remove inactive_type(::Type{Function}) method

Does this break anything? Ref discussion in #2091

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 23.86%. Comparing base (037dfed) to head (94092fc).
Report is 222 commits behind head on main.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@             Coverage Diff             @@
##             main    #2093       +/-   ##
===========================================
- Coverage   67.50%   23.86%   -43.65%
===========================================
  Files          31        2       -29
  Lines       12668      176    -12492
===========================================
- Hits         8552       42     -8510
+ Misses       4116      134     -3982

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

Tests pass locally on Julia 1.10.6. However, I don't know if there's a test for the issue that motivated this method.

On further thought, since this method only handles the abstract type Function and none of its subtypes, it has never worked as desired for concrete literal function types, i.e., it can't ever have been responsible for any correct behavior (but it could have caused incorrect behavior as discussed in #2091). So it should be safe to remove?

Just checked that this redefinition also passes tests:
@inline EnzymeRules.inactive_type(v::Type{T}) where {T<:Function} = isconcretetype(T) && iszero(sizeof(T))

But per the above comment, it seems unnecessary.


[Feature Proposal] Media query for IE

Add an option to apply certain styles just for Internet Explorer.
There are a lot of cases when some site require css hacks only for IE, for example some extra padding or margin so it would be nice if we could have something like IE specific prefix for example
.ie:mt-2 .ie:pt-4
I was thinking to use it similar as you use any other media query for screen size, and even to combine it
.ie:sm:mt-2
It can be accomplished with the comment mentioned here https://stackoverflow.com/a/28419263/1421641
What do you think?

Would you not need a prefix for every version in this case?
Technically you can already do this if you use the @apply syntax just Incase that is of interest to you

Don't plan to build this into Tailwind directly but it's easily done with a variant plugin:
module.exports = {
  // ...
  plugins: [
    function ({ postcss, addVariant }) {
      addVariant('ie', ({ container, separator }) => {
        const ieRule = postcss.atRule({
          name: 'media',
          params: 'all and (-ms-high-contrast: none), (-ms-high-contrast: active)'
        })
        ieRule.nodes = container.nodes
        container.nodes = [ieRule]
        ieRule.walkRules(rule => {
          rule.selector = `.ie${separator}${rule.selector.slice(1)}`
        })
      })
    }
  ],
}

This creates classes like ie:mt-2, and responsive versions like sm:ie:mt-2.


Usage of angular-webpack2-starter for lib development

Is angular-webpack2-starter a good option for lib development (e.g. when I have to develop base functionality for other developers).
What has to adapted to be able to do this?
TIA

I'm not fully sure as I've only been working on apps, not libs, but from reading comments from devs it seems that rollup/gulp setup is supposed to be best option for libs and small apps, while webpack seems to be the best option for mid to large size apps.

Yeah, rollup is recommended tool for libs. Take a look at https://github.com/ngrx/store


added content in the pet news category.

I have successfully added my content to the pet news.
@akshitagupta15june Please approve this and merge it.
#507 resolve

Hey @akshitagupta15june can you please look into these and approve my work and merge it :(

update your codebase with recent changes

update your codebase with recent changes

okay I'll @akshitagupta15june


Is there a way to implement along with e2e tests using protractor?

Can we utilize the API to get it so that we can automatically check during e2e tests for any spikes in these counters?

I'm not sure... I haven't used this in quite a while now. And I only used protractor a little. But I expect you could make something work.
In any case, I'm not really maintaining this anymore. If any changes are needed (documentation or otherwise), please feel free to makeapullrequest.com :)


fixed vents pumping air into space

About the PR
Fixed vents pumping air into rooms which are actively spacing.
This is accomplished by keeping track of the changes in pressure, and causing a lockout if pressure is dropping.
Why / Balance
As far as I'm aware, vents should go into a lockout if the room gets spaced.
Because of this bug, a single hull breach may temporarily empty distro, or cause a constant strain on distro pressure until distro runs out, or the vent somehow gets fixed.
Because spacing speed was slowed down, vents pump out air fast enough to keep their immediate surroundings at high pressures, which doesn't allow the vents to go into a underpressureLockout.
Technical details
Added a new method in GasVentPumpSystem that keeps track of the air pressure, and skips pumping air for a tick if the pressure is dropping.
With the current values it seems to be working, though a underpressurelockout failure can still happen if you put 20 vents in the corner of some spacing room, and decrease underpressurelockouttreshold to under 10.
Also large rooms may repressurize slightly slower, since airflows can trigger the fix I added. The variable pressurizationLockout can be changed to somewhat mitigate this.
Assuming I did my profiling correctly, this fix should have negligible effect on atmospheresystem's usage.
There's probably other ways to fix this bug, like just saving the pressure from last tick and calculating a change in pressure over one tick, and using that instead of doing this averaging stuff I wrote.
Media

Some footage of the bug in question:
https://github.com/space-wizards/space-station-14/assets/62134478/d032088c-7514-43e2-830c-c10415155793
And here's my fix:
https://github.com/space-wizards/space-station-14/assets/62134478/893f2f97-b8e6-4507-a52e-b06cdeb3528c

[x] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Breaking changes

Changelog

Answered the parts of the review that I can at this time of day, I'll probably make a commit for the changes once I wake up, which should be a while before the next batch of changes goes live.

I'm happy to help you with the EWMA; please let me know if you'd like me to take a look.

Managed to get this to work with EWMA, it mostly works, though there's an edge case where opening a door/wall causes the atmos equalization to create temporary spike in pressure, causing the new pressurization lockout to temporarily fail.

I'll probably replace the current SMA one with EWMA-based solution after a bit more work.

If you push your work-in-progress code I'm happy to give it a quick look before you get too far.

Here's the current state, haven't stumbled upon failures yet.
I'm also adding some small timer based check, just in case something manages to break this implementation, like the Fill mode, which seems to work really well in breaking these pressure differential things. Didn't push the timer part yet, since haven't fully tested it yet.

Pushed the timer-based check, I guess it could be implemented a bit better, and placing it outside pressurizationLockout would probably be slightly more readable.
It seems to be working, though it has gone through relatively little testing.
With the current values it should move air for 5 seconds, and then stop for 1,
but the values for it probably don't matter that much as long there's at least one tick of lockout(should happen with any positive number), besides for trying to optimize pressurization speed and amount of lost distro.
The specific failure that made me implement it was discovered via Fill mode of atmos alarms, if you have it on for a while with the vent in a spaced room, the pressure differential can get rather low, the lowest I saw was in the order of E-12, and at some point exactly 0 over 1 second.
I think this can be used in figuring out at which pressure the vent output and spacing equalize.
As far as I'm aware, this system should be working properly now, assuming I didn't make any mistakes in choosing the values.

Thanks for your work on this. It sounds like the under-pressure detection heuristic isn't working as well as you expected and these other mechanics like overheating need to be added. How have you been investigating when under-pressure detection isn't working? I know you mentioned monstermos equalization as a reason why pressure can spike; but shouldn't the averaging remove instantaneous spikes?

In case you weren't aware, you can use the sensor monitor console to help debug this.

I tested this in a synthetic situation, that I sorta tried to optimize for causing this failure.
In my testing I had UnderPressureLockoutThreshold set to 2, in order to better see my system in action, and because high thresholds seem to be temporary crutches to keep atmos functional.
For testing I used a small chamber 1 tile wide, containing a vent a few tiles away from the wall which shall be spaced.
Limiting the width of the corridor causes the vent to experience pressure loss from only one side, making the failure more likely.
The room was intentionally made small, so the effect of monstermos equalization is minimal.
In the image below is the most common setup I used, the flesh tiles are used to highlight the spots where a wall with be placed/breached for testing.

Currently I think there are two situations where the pressure differential-based method fails.
Those being very fast increases in pressure, and when average pressure loss in near-zero.
The former is most commonly caused by monstermos, and the latter seems to be essentially random, or caused with atmos alarm Fill mode. Calling the latter random since so far I've seen it occur naturally only once.
The former is solved by the pressure spike handling, and the latter with the "overheating".
The reliability of pressure differential-based method starts to break down as we get to very low pressures, like 10kPa. At this point, the rate of pressure loss starts to be under 1kPa/s. If a door is opened, or a wall broken down with a pressurized room behind it, the monstermos equalization may cause very fast changes in pressure, like anywhere between 10kPa/tick to 60kPa/tick. Listed in ticks because monstermos seems to be tick-based. In kPa/s the values would be about double, since testing was done with dt = ~0.53s.
The averaging can't really handle changes this fast with EWMA set to it's current values. I did try clamping the differential, but I think that had some other problem. The old SMA dealt with failure by reacting very slow because of being averaged many times.
The overheating method is supposed to break the delicate balance between vents pumping air and the spacing.
If set up with Fill mode, this failure seems to be stable even with a vent surrounded by space tiles on all four sides, stabilizing at 27kPa.

You can also make the EWMA "react very slow" by increasing the tau. I noticed that you have the time constant set to around 1 second, which is only like 2 moving average samples. If you set it to something like 2.5 seconds, it will average more closely to your original 5-sample moving average. Does that seem to help?

Did some testing with higher tau, with 2.5s and 6.25s to be specific. (6.25s from 2.5 being applied twice, like it seems to be in passivegate).
It didn't seem to work for many aspects, I think the only one that it fixed was the vents triggering the sudden pressure checking.
Breaching rooms causes the vent to exit the lockout, and sealing breaches during depressurization takes a long time to exit lockout. Also the effect of equalization in big rooms during repressurization is highlighted, by entering lockout a few seconds.
Assuming we aren't throwing this pressure differential based system out the window, here's how I think it should work:
We need only 3 things to handle everything, those being:

EWMA for determining the trend/direction of pressurization
Sudden change detection, (SPS from SuddenPressureSpike), mainly used for Monstermos detection
Timer as a fallback for when everything fails

Whenever SPS is triggered, we want to know why there was a change, so we restart the averaging process. Now, if:

the room is breached, the pressure should instantly start to drop, so EWMA tells us to go into lockout.
the room isn't breached, the pressure will stay static, prompting us to continue pressurizing the room.

If everything fails and failure is somehow reached, timer will limit it to a few seconds.
I was going to list here all the common scenarios and how those 3 systems manage to handle all of them, but decided to cut them out cause not going to finish it this tired... Hopefully my ramblings made even a tiny bit of sense..

Here's my current changes, as far as I'm aware, there shouldn't be any common failures, and the few which can happen should be very rare and should resolve themselves after a moment.
Probably the most major inconveniences with this system is that with the current values, pressurization starts a few seconds after the spacing has been fixed, or UPLO is exited, though that is somewhat intentional.
Since the parameters aren't currently tuned perfectly, in some situations repressurization may be a bit slow.
Well, if we set UnderPressureLockoutThreshold to under 10kPa, there can happen some annoying bug where the vent outputs air for a single tick every 10 seconds or so, caused by extremely slow spacing speed. But we'll avoid that bug with UPLO over 10kPa.
Also discovered that this system breaks vents if monstermos.equalization is set to false. I guess this could be solved by either making this system check for that cvar, or creating a cvar for this system.
I've considered making this system output stuff to the adminlogs upon detecting a lockout failure, though I haven't figured yet how exactly/in what form the event should be logged.
I think that after addressing the cvar and logging points, this system is "ready". By that I mean that this solution works acceptably well, and getting better behaviour probably needs some slightly more thought out solution.


[WIP] Milestone emails

refs https://www.notion.so/ghost/Marketing-Milestone-email-campaigns-1d2c9dee3cfa4029863edb16092ad5c4

@allouis the first version of the package with basic API functionality is done. Not sure how I can get the test coverage for the index files up, but tomorrow I'll continue with work on the service itself within Ghost core 😅


better-log show NaN passing when test on mocha

When using mocha it show NaN

Does it show correct number with better-log being disabled?

When I disable like README, at the end, now it works fine.

require('better-log').uninstall();

Does it have any fix or else because It comes with unconvinient quite?

Please describe what you mean more precisely. I'm not following.

To avoid NaN I have to disable better-log each file test. It will better that We never worry about disabling.

I'll try to look into it as soon as I find time, but it would be very helpful if you could do that (basically, just look into the Mocha code and figure out what type of number it tries to submit that might cause this).

I think I've found and fixed potential cause of this, although not sure - please check out the new version and let me know whether it works now.

Now It can show number. Except a little change in color
Original

Use better-log

Well, yes - numbers have different color in output, that's the entire idea of better-log :)

However, need to think about this more. Not sure how to detect and in which cases is better to use originally formatted string than format on behalf of better-log.

Btw, for your case the easier might be to use better-log not as replacement for console.log but as module on its own (see example in README). In that case, you will be able to call betterLog(...) for whatever you need while Mocha will use built-in one.

yes. It's not easy to make it work totally well with other modules. A combine between mocha and better-log like above still be good to me.
And I also tried your guess with Manual usage as a regular function. But I meet another issue:

var log = require('better-log');
log({ x: 1, y: 'prop' }); // it shows: undefined
log.error('Something bad happened :(');

Ah right, that was broken by previous fix :) Thanks for reporting, should be fixed now and also added basic hook-based tests.

yes. I'm so happy


added several plan building speed improvements

Codecov Report

Merging #5 (f45c8e1) into main (fabb587) will increase coverage by 0.04%.
The diff coverage is 98.64%.

@@            Coverage Diff             @@
##             main       #5      +/-   ##
==========================================
+ Coverage   92.77%   92.81%   +0.04%
==========================================
  Files          44       44
  Lines        1619     1629      +10
  Branches      230      228       -2
==========================================
+ Hits         1502     1512      +10
+ Misses         94       93       -1
- Partials       23       24       +1

Impacted Files
Coverage Δ

src/uberjob/progress/__init__.py
100.00% <ø> (ø)

src/uberjob/progress/_html_progress_observer.py
98.18% <ø> (ø)

src/uberjob/_util/validation.py
85.71% <66.66%> (+1.09%)
:arrow_up:

src/uberjob/_plan.py
100.00% <100.00%> (ø)

src/uberjob/_run.py
100.00% <100.00%> (ø)

src/uberjob/_transformations/caching.py
98.91% <100.00%> (-0.03%)
:arrow_down:

src/uberjob/_transformations/pruning.py
100.00% <100.00%> (ø)

src/uberjob/_util/__init__.py
91.83% <100.00%> (+0.34%)
:arrow_up:

src/uberjob/progress/_console_progress_observer.py
97.50% <100.00%> (ø)

src/uberjob/progress/_ipython_progress_observer.py
18.57% <100.00%> (ø)

... and 5 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 623b9ac...f45c8e1. Read the comment docs.

Codecov Report

Merging #5 (f45c8e1) into main (fabb587) will increase coverage by 0.04%.
The diff coverage is 98.64%.

@@            Coverage Diff             @@
##             main       #5      +/-   ##
==========================================
+ Coverage   92.77%   92.81%   +0.04%
==========================================
  Files          44       44
  Lines        1619     1629      +10
  Branches      230      228       -2
==========================================
+ Hits         1502     1512      +10
+ Misses         94       93       -1
- Partials       23       24       +1

Impacted Files
Coverage Δ

src/uberjob/progress/__init__.py
100.00% <ø> (ø)

src/uberjob/progress/_html_progress_observer.py
98.18% <ø> (ø)

src/uberjob/_util/validation.py
85.71% <66.66%> (+1.09%)
:arrow_up:

src/uberjob/_plan.py
100.00% <100.00%> (ø)

src/uberjob/_run.py
100.00% <100.00%> (ø)

src/uberjob/_transformations/caching.py
98.91% <100.00%> (-0.03%)
:arrow_down:

src/uberjob/_transformations/pruning.py
100.00% <100.00%> (ø)

src/uberjob/_util/__init__.py
91.83% <100.00%> (+0.34%)
:arrow_up:

src/uberjob/progress/_console_progress_observer.py
97.50% <100.00%> (ø)

src/uberjob/progress/_ipython_progress_observer.py
18.57% <100.00%> (ø)

... and 5 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 623b9ac...f45c8e1. Read the comment docs.


Movement detection overheating ?

I know this is hard to reproduce and maybe I had bad luck but wanted to let you guys know that when having movement detection on I burned two tablets in a row (both lasted 2 days). Mind you they were cheap, but one was brand new and they where different models and brands. I just left them running plugged in with movement detection and screensaver. I used them to display TileBoard for Home Assistant.
I love the work you guys are doing and keep it up!  Do you suggest any hardware that wont quit on me ?

The application is not doing anything special, it's just using two different camera images to detect differences between them, it's not really intensive at all.  This should not be any more hardware intensive than just having the camera on  for long periods of time.   I don't think you can really say this is an issue with the application anymore than a video application.   It could be the power supply or the screen being on continuously that causes an issue on the tablets.   I don't have any hardware suggestions other than do not buy whatever you bought.  I run the software on cheap Amazon Fire tablets without issues, but I use the stock power adapters as well.

I can confirm this problem with overheating.
I was using old/crashed Yotaphone 2 (Android 5.0). Camera motion detection was enabled, phone was plugged to original charger (with battery).  I was always had an impression it is much hotter when motion detection is enabled, but I left it like that. Then some day battery exploded, fortunately nothing more has damaged.
Yesterday I plugged it again, on my desk, without battery at all, just using my lab power supply, with current monitoring.
my observations, with below environment -
fresh OS (lollipop), nothing else installed beside WallPanel, MQTT(60s reporting intervals), HTTP server, most time on screen saver(clock) :

motion detection with front camera enabled (15 FPS) -  it draws between 0.6-1.1 A
camera motion disabled - it draws from 0.22 to 0.4 A current, after some time phone is definitely cooler

I'm not sure whether it is related to maybe old Android (older, less effective API ? ), or this particular hardware. But definitely something have influence on power usage (thus overheating).

I noticed the same on various Sony devices. Devices are getting hot.
I assume, active camera consumes a lot of power. (App independent)
@voyo can you test power consumption with normal camera app too? (Live view and movie recording)
By the way: how do you power the phone without battery? Power supply connected to internal battery pins?

This is not an application problem, this is a hardware issue on certain devices.  Devices that experience overheating when running the camera all the time should not use the motion or streaming video features of the application.  There may be other hardware fixes as @allofmex has mentioned, but as for the application, this is not an issue I can address.

@allofmex, @thanksmister   - yeah, I confirmed - with wallpanel not started, and default camera app running (just video displayed from front camera) - my device is overheating as well after some time.
I thought it can be maybe old API problem, but this clearly proves it probably is not. Obviously some devices cannot have camera running all the time... (this is worth mentioning in wallpannel documentation or whatsoever).
how to run phone without battery - I was lucky, my device was ok to accept 3.6V power supply directly without battery, (android is just showing constantly 50% for battery) but if your is not - google for how to emulate the resistance for the BSI and BTEMP (thats the keywords)


Update multiplication-operator_1.cs

There are lots of example like this one that do not compile.
It would be better for users to only copy/paste the code samples right?
Instead, you have to modify the code for it to compile.
The example should either:

include a using System; directive
include fully qualified names (System.Console.WriteLine)
or include in some cases a comment: // using System;

Do you agree with this?
Should I create a PR each time I see an example like this (there's a lot)?

Ideally, I would run such snippets in a browser. So, let's use interactive snippets?
Furthermore, there is no need in class and Main method declaration:

interactive snippet runs without them
if I copy code (of such small examples), I want to copy only useful lines, as boilerplate code is usually already in place.

So, reducing those snippets only to useful lines (with optional output comments) and making them interactive would make articles neater and easier to grasp.
@johnnyagerard @BillWagner what do you think?

@pkulikov I only use Visual Studio to run my code.
Where can I use those interactive snippets?

@johnnyagerard for the docs example, check the following page:
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/for
and try to click Run! at the top right snippet corner.
As for Visual Studio, I also use it, but often playing in try.dot.net is enough.

@pkulikov Thanks. This is a nice tool.

@johnnyagerard To make any inline code use the interactive browser, use csharp-interactve as the language identifier instead of csharp. That's true for inline code in markdown, and includes from other samples.
In general, we'd want to use the interactive samples whenever it adds to the experience.

@BillWagner Roger that.

@johnnyagerard Are you going to update this PR to run interactively? Let me know if I should be waiting for more commits.

@BillWagner You said to use the interactive samples whenever it adds to the experience.
I don't know if this is the case here. I let you judge then.


 Either the server is overloaded or there is an error in the application.</p>

[2022-05-16 20:29:05,631] INFO in optimization: Perform optimization for the day-ahead
INFO:web_server:Perform optimization for the day-ahead
[2022-05-16 20:29:05,827] WARNING in optimization: Failed LP solve with PULP_CBC_CMD solver, falling back to default Pulp
WARNING:web_server:Failed LP solve with PULP_CBC_CMD solver, falling back to default Pulp
[2022-05-16 20:29:05,882] WARNING in optimization: Failed LP solve with default Pulp solver, falling back to GLPK_CMD
WARNING:web_server:Failed LP solve with default Pulp solver, falling back to GLPK_CMD
[2022-05-16 20:29:07,268] INFO in optimization: Status: Optimal
INFO:web_server:Status: Optimal
[2022-05-16 20:29:07,269] INFO in optimization: Total value of the Cost function = -15.61
INFO:web_server:Total value of the Cost function = -15.61
[2022-05-16 20:29:07,866] INFO in command_line: Setting up needed data
INFO:web_server:Setting up needed data
[2022-05-16 20:29:07,870] INFO in web_server:  >> Publishing data...
INFO:web_server: >> Publishing data...
[2022-05-16 20:29:07,871] INFO in command_line: Publishing data to HASS instance
INFO:web_server:Publishing data to HASS instance
[2022-05-16 20:29:07,919] INFO in retrieve_hass: Successfully posted value in existing entity_id
INFO:web_server:Successfully posted value in existing entity_id
[2022-05-16 20:29:07,952] INFO in retrieve_hass: Successfully posted value in existing entity_id
INFO:web_server:Successfully posted value in existing entity_id
[2022-05-16 20:29:07,984] INFO in retrieve_hass: Successfully posted value in existing entity_id
INFO:web_server:Successfully posted value in existing entity_id
[2022-05-16 20:29:08,020] INFO in retrieve_hass: Successfully posted value in existing entity_id
INFO:web_server:Successfully posted value in existing entity_id
[2022-05-16 20:29:08,058] INFO in retrieve_hass: Successfully posted value in existing entity_id
INFO:web_server:Successfully posted value in existing entity_id
[2022-05-16 20:29:08,092] INFO in retrieve_hass: Successfully posted value in existing entity_id
INFO:web_server:Successfully posted value in existing entity_id
[2022-05-16 20:29:08,116] INFO in retrieve_hass: Successfully posted value in existing entity_id
INFO:web_server:Successfully posted value in existing entity_id
[2022-05-16 20:29:16,077] INFO in command_line: Setting up needed data
INFO:web_server:Setting up needed data
[2022-05-16 20:29:16,089] INFO in forecast: Retrieving weather forecast data using method = scrapper
INFO:web_server:Retrieving weather forecast data using method = scrapper
[2022-05-16 20:29:19,304] INFO in forecast: Retrieving data from hass for load forecast using method = naive
INFO:web_server:Retrieving data from hass for load forecast using method = naive
[2022-05-16 20:29:19,305] INFO in retrieve_hass: Retrieve hass get data method initiated...
INFO:web_server:Retrieve hass get data method initiated...
[2022-05-16 20:29:22,205] INFO in web_server:  >> Performing naive MPC optimization...
INFO:web_server: >> Performing naive MPC optimization...
[2022-05-16 20:29:22,205] INFO in command_line: Performing naive MPC optimization
INFO:web_server:Performing naive MPC optimization
[2022-05-16 20:29:22,228] ERROR in app: Exception on /action/naive-mpc-optim [POST]
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/dist-packages/flask/app.py", line 2077, in wsgi_app
    response = self.full_dispatch_request()
  File "/usr/local/lib/python3.9/dist-packages/flask/app.py", line 1525, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/usr/local/lib/python3.9/dist-packages/flask/app.py", line 1523, in full_dispatch_request
    rv = self.dispatch_request()
  File "/usr/local/lib/python3.9/dist-packages/flask/app.py", line 1509, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**req.view_args)
  File "/usr/local/lib/python3.9/dist-packages/emhass/web_server.py", line 136, in action_call
    opt_res = naive_mpc_optim(input_data_dict, app.logger)
  File "/usr/local/lib/python3.9/dist-packages/emhass/command_line.py", line 185, in naive_mpc_optim
    prediction_horizon = input_data_dict['params']['passed_data']['prediction_horizon']
TypeError: string indices must be integers
ERROR:web_server:Exception on /action/naive-mpc-optim [POST]
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/dist-packages/flask/app.py", line 2077, in wsgi_app
    response = self.full_dispatch_request()
  File "/usr/local/lib/python3.9/dist-packages/flask/app.py", line 1525, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/usr/local/lib/python3.9/dist-packages/flask/app.py", line 1523, in full_dispatch_request
    rv = self.dispatch_request()
  File "/usr/local/lib/python3.9/dist-packages/flask/app.py", line 1509, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**req.view_args)
  File "/usr/local/lib/python3.9/dist-packages/emhass/web_server.py", line 136, in action_call
    opt_res = naive_mpc_optim(input_data_dict, app.logger)
  File "/usr/local/lib/python3.9/dist-packages/emhass/command_line.py", line 185, in naive_mpc_optim
    prediction_horizon = input_data_dict['params']['passed_data']['prediction_horizon']
TypeError: string indices must be integers

Hi, this specific issue was solved. Other issues arised in the mean time. They are now normally solved. I've tested the MPC on the add-on and is working fine on my side.
Also the prediction_horizon parameter is an integer with the number of time steps to use for the MPC iteration. I've set the default to 10 for this.
The following curl command is working fine for me:
curl -i -H "Content-Type: application/json" -X POST -d '{"pv_power_forecast":[0, 70, 141.22, 246.18, 513.5, 753.27, 1049.89, 1797.93, 1697.3, 3078.93], "prediction_horizon":10, "soc_init":0.5,"soc_final":0.6,"def_total_hours":[1,3]}' http://localhost:5000/action/naive-mpc-optim

Thanks, the prediction_horizon is working very well for me as I don't always have forecasts for the next 48 time steps.

The below scripts work for minutes 26-29 & minutes 46-59, due to the way emhass is rounding the forecasts to the nearest time block.  I'll raise a separate issue. Ideally emhass would always receive currentvalue & forecasts for each.
"soc_init":{{states('sensor.powerwall_charge')|float(0)/100}}
"prediction_horizon":{{(state_attr('sensor.amber_feed_in_forecast', 'forecasts')|map(attribute='per_kwh')|list|length)}}
"load_cost_forecast":{{(state_attr('sensor.amber_general_forecast', 'forecasts') |map(attribute='per_kwh')|list)}}
"prod_price_forecast":{{(state_attr('sensor.amber_feed_in_forecast', 'forecasts')|map(attribute='per_kwh')|list)}}

curl -i -H "Content-Type: application/json" -X POST -d '{"prod_price_forecast":{{(
             (state_attr('sensor.amber_feed_in_forecast', 'forecasts')|map(attribute='per_kwh')|list) )
          }},"load_cost_forecast":{{(
             (state_attr('sensor.amber_general_forecast', 'forecasts') |map(attribute='per_kwh')|list) )
          }},"prediction_horizon":{{(state_attr('sensor.amber_feed_in_forecast', 'forecasts')|map(attribute='per_kwh')|list|length)
          }},"soc_init":{{states('sensor.powerwall_charge')|float(0)/100
          }},"soc_final":0.01,"def_total_hours":[4,5,3,1]}' http://localhost:5000/action/naive-mpc-optim

"soc_init":0.49
"prediction_horizon":32
"load_cost_forecast":[0.25, 0.21, 0.22, 0.28, 0.28, 0.33, 0.42, 0.33, 0.33, 0.61, 1.49, 15.36, 1.49, 0.79, 0.72, 0.61, 0.47, 0.45, 0.45, 0.45, 0.45, 0.45, 0.44, 0.43, 0.44, 0.38, 0.37, 0.42, 0.38, 0.38, 0.37, 0.38]
"prod_price_forecast":[0.14, 0.1, 0.11, 0.16, 0.16, 0.21, 0.3, 0.21, 0.21, 0.47, 1.26, 13.88, 1.26, 0.63, 0.57, 0.47, 0.34, 0.33, 0.32, 0.32, 0.32, 0.32, 0.31, 0.31, 0.31, 0.26, 0.25, 0.29, 0.25, 0.25, 0.25, 0.26]

curl -i -H "Content-Type: application/json" -X POST -d '{"prod_price_forecast":[0.14, 0.1, 0.11, 0.16, 0.16, 0.21, 0.3, 0.21, 0.21, 0.47, 1.26, 13.88, 1.26, 0.63, 0.57, 0.47, 0.34, 0.33, 0.32, 0.32, 0.32, 0.32, 0.31, 0.31, 0.31, 0.26, 0.25, 0.29, 0.25, 0.25, 0.25, 0.26],"load_cost_forecast":[0.25, 0.21, 0.22, 0.28, 0.28, 0.33, 0.42, 0.33, 0.33, 0.61, 1.49, 15.36, 1.49, 0.79, 0.72, 0.61, 0.47, 0.45, 0.45, 0.45, 0.45, 0.45, 0.44, 0.43, 0.44, 0.38, 0.37, 0.42, 0.38, 0.38, 0.37, 0.38],"prediction_horizon":32,"soc_init":0.49,"soc_final":0.01,"def_total_hours":[4,5,3,1]}' http://localhost:5000/action/naive-mpc-optim


feat: create add preemptive functionality to the switchover agent

Looks good, for the env vars is the idea you would redeploy with helm setting the env vars when a preemptive failover is coming up?

Not quite, I just manually change the env var and redeploy


add unit test to verify the server online list

https://github.com/Storj/dataserv-client/issues/92

Please squash commits so I can review.


NavigationView header shows unnecessary indentation

Describe the bug
Current behavior

I'm not sure what exactly the problem is. The problem is either indentation or default vertical alignment. This showed up after updating to 3.11.0-dev.242 from about 3.10.0-dev.500
Expected behavior

Steps to reproduce the bug
xmlns:muxc="using:Microsoft.UI.Xaml.Controls"
<muxc:NavigationView
  IsSettingsVisible="False"
  AlwaysShowHeader="True"
  IsTabStop="False"
  IsPaneToggleButtonVisible="True"
  IsPaneOpen="True"
  IsPaneVisible="True"
  PaneDisplayMode="LeftCompact"
  >
  <muxc:NavigationView.Header>
    <TextBlock
        HorizontalAlignment="Center"
        VerticalAlignment="Center"
        Text="Test"
        />
  </muxc:NavigationView.Header>
</muxc:NavigationView>

Expected behavior
No response
Screenshots
No response
NuGet package version
Microsoft.UI.Xaml 2.7.0
Windows app type

[ ] UWP
[ ] Win32

Device form factor
Desktop
Windows version
May 2021 Update (19043)
Additional context
Package Version(s):
<PackageReference Include="Microsoft.NETCore.UniversalWindowsPlatform">
      <!--
			If, in the same solution, you are referencing a project that uses https://github.com/onovotny/MSBuildSdkExtras,
			you need to make sure that the version provided here matches https://github.com/onovotny/MSBuildSdkExtras/blob/master/Source/MSBuild.Sdk.Extras/DefaultItems/ImplicitPackages.targets#L11.
			This is not an issue when libraries are referenced through nuget packages. See https://github.com/nventive/Uno/issues/446 for more details.
			-->
      <Version>6.2.12</Version>
    </PackageReference>
    <PackageReference Include="Microsoft.Toolkit.Uwp.UI">
      <Version>7.1.0</Version>
    </PackageReference>
    <PackageReference Include="Microsoft.Toolkit.Uwp.UI.Controls.Core">
      <Version>7.1.0</Version>
    </PackageReference>
    <PackageReference Include="Microsoft.Toolkit.Uwp.UI.Controls.DataGrid">
      <Version>7.1.0</Version>
    </PackageReference>
    <PackageReference Include="Microsoft.Toolkit.Uwp.UI.Controls.Layout">
      <Version>7.1.0</Version>
    </PackageReference>
    <PackageReference Include="Microsoft.UI.Xaml">
      <Version>2.7.0</Version>
    </PackageReference>

Windows 10 Build Number:

[ ] Fall Creators Update (16299)
[ ] April 2018 Update (17134)
[ ] October 2018 Update (17763)
[ ] May 2019 Update (18362)
[ ] May 2020 Update (19041)
[ ] Insider Build ({build_number})
[x] 19043.985 21H1

App min and target version:

[ ] Fall Creators Update (16299)
[ ] April 2018 Update (17134)
[ ] October 2018 Update (17763)
[ ] May 2019 Update (18362)
[x] May 2020 Update (19041) Min And Target
[ ] Insider Build ({build_number})

Device form factor:

[x] Desktop
[ ] Xbox
[ ] Surface Hub
[ ] IoT

Visual Studio version:

[ ] 2017 (15.{minor_version})
[ ] 2019 (16.{minor_version})
[x] 2022 preview 4.1

Problems appears after upgrade Microsoft.UI.Xaml from 2.6.0-prerelease.210430001 to 2.6.0

It seems that this padding is intentional, the NavigationViewHeaderMargin resource which defines the margin around the header is set to 56,44,0,0 which would explain the gap at the top. I'm not sure if this is intentional or not but this was introduced with #4779. @karenbtlai maybe you can tell more about this and how to possibly resolve this?


Incorrect progress percent shown

$ haveibeenpwned-downloader pwnedpasswords -s false -o
Failed attempt #0 while fetching https://api.pwnedpasswords.com/range/3F6E7. Exception is HttpRequestException and message: Error while copying content to a stream..
Failed attempt #0 while fetching https://api.pwnedpasswords.com/range/3F6EA. Exception is HttpRequestException and message: Error while copying content to a stream..
Failed attempt #0 while fetching https://api.pwnedpasswords.com/range/41DF8. Exception is HttpRequestException and message: Error while copying content to a stream..
Failed attempt #0 while fetching https://api.pwnedpasswords.com/range/41DF9. Exception is HttpRequestException and message: Error while copying content to a stream..

Hash ranges downloaded ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━  39% 00:00:00

Finished downloading all hash ranges in 1,946,884ms (211.82 hashes per second).
We made 412,386 Cloudflare requests (avg response time: 284.26ms). Of those, Cloudflare had already cached 412,386 requests, and made 0 requests to the Have I Been Pwned origin server.

At 39% the download says that it finished downloading all hash ranges. Is this correct?

I was able to get a clean download this time
haveibeenpwned-downloader pwnedpasswords -s false

Hash ranges downloaded ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 00:00:00

Finished downloading all hash ranges in 3,135,526ms (334.42 hashes per second).
We made 1,048,576 Cloudflare requests (avg response time: 22.69ms). Of those, Cloudflare had already cached 1,048,576 requests, and made 0 requests to the Have I Been Pwned origin server.

Are the numbers shown above are correct?

@oyeaussie
Have the similar behavior with different numbers, but the tool in my case not throwing any HttpRequestException:
C:\hvibeenpwnd_tool\haveibeenpwned-downloader.exe C:\hashes -s false -p 64 Hash ranges downloaded: 0% Hash ranges downloaded: 0% Hash ranges downloaded: 0% Hash ranges downloaded: 0% Hash ranges downloaded: 1% Hash ranges downloaded: 1% Hash ranges downloaded: 1% Hash ranges downloaded: 1% Hash ranges downloaded: 1% Hash ranges downloaded: 2% Finished downloading all hash ranges in 289,921ms (84.33 hashes per second). We made 24,450 Cloudflare requests (avg response time: 745.07ms). Of those,  Cloudflare had already cached 24,450 requests, and made 0 requests to the Have I Been Pwned origin server.
May I ask you what is the total size of your pwd file?

@dlosyankov
🤣 I got a bit frustrated and wrote my own app in PHP yesterday. Try it and let me know if there are any issues
https://github.com/oyeaussie/PHPPwnedPasswordsDownloader


Sync building side screens (user menu on the right). E.g. selecting filtered item, setting production queue, setting battery levels, etc.

See for exhaustive list
https://docs.google.com/spreadsheets/d/1klx2C6pbsQOD0CR1RiFPcvWsTv19xBcj5wd-Q-nI4YA/edit#gid=1436570526
Important:
Add default clause to catch not handled side screens and log them, to be able to track desync errors.

Seems like we have to sync individual screens data, because a side screen is a singleton and has a selectable target. This implicates if there's a side screen opened and the target object is being changed the side screen should be updated as well. Maybe it's a subject to change, but I don't see any generalizing options since each side screen has its own data.

Most of the sidescreens (56 out of 69 ) are synced except few left overs (created #169 to cover them).


file-reader: rm duplicate declaration of Reader

In file-reader variable Reader declared twice.

Whoops! already landed this as 8ad92e5c8246ae707eba8d6101e0192eecccdcd7! Thanks for contributing this, and as this package is now using @feross's standard to enforce coding style, these sorts of issues shouldn't recur in the future!


Separate ASF-required and non-ASF-required checks in summary

@adriancole in #27:

probably it would help my brain a lot to classify what are actually ASF requirements from what are not. There's no requirement to have the files in the source dist match the repo. The first couple repos we've done matched so mentally we are anchored to this concept. Since we are testing things that are not requirements and not necessarily even valid. It would be cool to order the ones that are concrete at the top, then a line or something, then the extra checks we made up which may help, but are not actually requirements at the bottom.

Yep! what I meant is that there's no requirement for a match between the repo structure and the source distribution. Common problems in the last few releases are focus on what's in the repo vs what's actually required (ex NOTICE, DEPENDENCIES etc)

most obvious point for us is several hours of discussion on the zipkin-api repo which has an incidental deployment and files around that. Most of this time was lost due to the assumption and mental anchoring folks besides me have.
That would certainly not be the only case. I think if we spot checked a few apache projects, we'd find out quickly there's a certain amount of fuzz in the assumption what's in the repo must all be in the source dist.

also I would note that almost or perhaps exclusively, we have no IPMC folks verifying anything we do here is congruent. This lack of guidance is probably what leads to very quick anchoring to limited experience.

Gotcha. I think it's important to distinguish between:

the contents of the source files (and number of them) must match – I just checked, and this is not explicitly called out anywhere in the ASF policy that I can see, it seems implicit in everything. The trick here is that what constitutes a "source file" is not trivial, see zipkin-api.
the folder structure in which the source files live in the release should I guess bear some resemblance to the folder structure in the repo, but this seems to be totally not a requirement.

I'm unsure how to approach the first one (a band-aid for the second one will be #20). Maybe the most relevant part of the policy is https://www.apache.org/legal/release-policy.html#source-packages:

Every ASF release MUST contain one or more source packages, which MUST be sufficient for a user to build and test the release provided they have access to the appropriate platform and tools.

We can verify this by automatically running a build-and-test, when we know how, and when this is relevant. However, this won't tell us if, for example, a source file containing tests is missing from the source archive. If a source file containing tests is missing from the source archive, then I'd say we don't satisfy the above requirement, in that users can test something, but it's not the version of the software the release pretends to be.
Let's get some of our mentors involved?

maybe you can do next release then decide?

I think if you personally had to experience the impact of this tool, it would help shape it. Right now, there's a zipkin-reporter-java repo to release once zipkin is out. Sound fair?

that means you do the recutting of tags explanations etc when people get scared etc. it is this, and the hours lost on this thrashing, that have cost me the most unnecessary time.

alternatively you can defer first to your users about how the experience is, what is desired and not desired. The push to add more errors about source congruence is from you personally, and not a match to verification errors encountered recently, if except for adding scary messages which make getting people to vote a difficult nagging task that I've been doing in ways you can see and also not (ex direct messaging and begging)

Adrian, if you think using this tool is detrimental to Zipkin, then let's not use it. Re. thrashing, you're quite welcome to step out of this thrashing about the direction of the tool, and ask mentors to take over.
Re. user experience, let's not change the output based on what's convenient, but on actual ASF requirements, otherwise there's no point to this whole thing. All my comments are about making sure we understand what are the actual ASF requirements.
Overall, at this point I'm happy to step back and start doing release reviews manually, until someone else commits to arbitrating arguments like this. You don't have the bandwidth, and I believe they're crucial, so we're at an impasse.
(I'm about to head out, silence from here is not passive-aggressive, I'll just be not available to respond)

I think what's frustrating to me is that you ask for things to be ERROR
which are not in the docs, nor in recent problems in source verification
votes. In fact you are doubling down on a problem (linty files being now
error unless otherwise noted)
It would be less frustrating if you documented why you feel strongly about
this with something.. like an ASF requirement or a release failure on
account of something before trying to push it as mandatory.
Tools we have even without mentors includes the actual requirements,
http://www.apache.org/legal/release-policy.html#what-must-every-release-contain
and also advice we got for source verification votes ex.
<EMAIL_ADDRESS>Anything beyond that is simply not something we need to deal with. We had a
huge ordeal trying to get IPMC to be lenient and not interfere or cause
problems. I think it is draconian to suggest my way or highway on either
what you merge here is strict or we don't use the tool. I don't think you
mean that. I am just hoping you can add at least a temporary preference to
not introduce FUD (ex ERROR by default on things not ASF, or cite why they
are ASF with actual facts and email .. and if not.. figure that out BEFORE
assuming something)

I understand the desire to have no grey areas of concern but can we indeed only implement the checks that actually are based on the explicit requirements. If we have additional desires or grey areas let's discuss them but only if a proper case for why we want it is provided.
The worst thing to do is to get into a mindset where we try to think about what the ASF would want. It is either explicit already, there exists "jurisprudence" or it will be raised by IPMC. Until then I seriously opt for "no action required"

Thank you for the thoughtful comments! Bottom line, I agree with everything in these last two comments, so that must mean I'm not very clear about where my head is. I apologize for this, and the frustration it caused. Side-note: I don't intend this to be my project, I very intentionally created it under openzipkin-contrib. Worst case, I'm happy to step back and let others drive it forward, with zero bad feelings, if we can't align our thinking.
Which seems to be not the case, I think we're pretty much aligned on goals. Once again I apologize for causing frustration with my lack of clarity. Lemme try to summarize where my head is:

Everything we know and agreed that's ASF-required, if it has an automated check we trust fully, should probably be FAIL level. On false positives, let's downgrade these.
I agree stuff not required by ASF should definitely not be FAIL level. Depending on how confident we are about the check, and its importance, we can argue about whether they should be WARN or NOTE – for instance, currently the difference between repo and source archive is currently at WARN, and "I have no idea how to tests here maybe you want to tell me" is NOTE (#27).

On top of all this, and I think this is where things went south: when development on this tool reaches gray areas and edge cases, I tend to also bring in the additional idea of "release correctness", and catch mistakes with this automation. Having these in a single tool is convenient probably, but there must be a clear delineation between the two (which is what this very issue is tracking)
Finally, one learning for me here is to start discussions around better understanding ASF requirements on the dev list, or possibly the wider incubator list, looking for input, as opposed to handling them here on issues. For instance, I think that a content mismatch in a source file between the source archive and the tagged commit in the repo is an explicit violation of ASF requirements, but the right way to approach that is to get confirmation or correction from ASF people, and then put up a PR with appropriate context. This should eliminate time wastage on our end, and ensure we make the right calls. Starting such discussions on issues on this tool, I now understand, gives the impression that I already have a strong stance I'm unprepared to reconsider, which is not the case.
Sound good?
Love you all!


[Kafka-5996] JsonConverter generates "Mismatching schema" DataException

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-test-coverage/314/


FIX: Fix imsave

Closes #209.
@mwaskom I used your approach but left the figure-generation private for now. Feel free to make a follow-up PR to make it public with proper documentation, etc.

Haven't tested but LGTM

Codecov Report

Merging #221 into master will increase coverage by 0.08%.
The diff coverage is 71.42%.

@@            Coverage Diff             @@
##           master     #221      +/-   ##
==========================================
+ Coverage   66.81%   66.89%   +0.08%
==========================================
  Files           8        8
  Lines        2438     2444       +6
  Branches      473      473
==========================================
+ Hits         1629     1635       +6
  Misses        624      624
  Partials      185      185

Impacted Files
Coverage Δ

surfer/viz.py
62.56% <71.42%> (+0.13%)
:arrow_up:

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 9570efb...c303591. Read the comment docs.

Okay CIs are happy (except pending OSX but that usually takes forever). I added a 3.6 CI, fixed related errors, and fixed a couple of bare except:s we had. Ready for review/merge from my end.

(actually not sure about AppVeyor yet, either, but it passed last time I let it finish)

Is there an advantage over using Matplotlib's imsave (https://github.com/matplotlib/matplotlib/blob/5f63dd42ec6deec5c85ab975d7d879c7c81cb161/lib/matplotlib/image.py#L1305), which seems to be more efficient for PNG but do the same otherwise?

I assumed it was just an efficiency thing so I didn't include it to reduce complexity, but I don't know for sure

Oh, I didn't mean to include the special case, but whether it wouldn't be easier to just use matplotlib.image.imsave

This moves toward a use case @mwaskom wanted, see his comments toward the end of #209

Aah, makes sense

On Nov 27, 2017, at 9:21 PM, Eric Larson<EMAIL_ADDRESS>wrote:
This moves toward a use case @mwaskom https://github.com/mwaskom wanted, see his comments toward the end of #209 https://github.com/nipy/PySurfer/issues/209
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/nipy/PySurfer/pull/221#issuecomment-347392650, or mute the thread https://github.com/notifications/unsubscribe-auth/AAI5a5pmweM1CpgZiXtKpgzimeP7t1k6ks5s624igaJpZM4Qr8Mk.

Anybody else want to look (or @mwaskom want to look again now that everything passes)? If not I'll merge at the end of the week


Accesibility: the text inside p tags in light theme is barely legible

This is an issue even if this library is used for dead simple html demos.
It has contrast ratio of only 1.61.

Same with anchor tags - default setting does not work. What does work, is for example #006900.
By default, the contrast ratio is 1.75.

Can you provide a minimal example or a screenshot of what you're seeing? I'm unable to reproduce on the demo page.
Text inside a <p> tag is color #363636 with a background color of #FFFFFF, giving a ratio of 12.08.
Text inside a <a> tag is color #0076d1 with a background color of #FFFFFF, giving a ratio of 4.65.
What are you seeing on your end?

You've brought up great points about accessibility though - I'll do some research and see if this can be a test as part of our build pipeline.

My goodness...
Yes, I have added water.css to a sample project, however I have forgotten to comment out default styles of another framework. Silly me.
Okay, so with that silly mistake gone, you are totally right, text inside paragraphs is easily legible and so is inside anchor tags. What could be fixed however, is that everything could be styled to comply with the higher, AAA, standard.
Currently links are fine according to the AA standard, but not by the AAA. Just a small fix.

Hah, I know I've done the same thing before. No worries!
Great feedback on accessibility - I've opened up #56 and I'll close this issue.


feat(evm): solidity script support MVP

Motivation
Experimenting with Solidity as a scripting language for performing general-purpose tasks

Solution
Did quite a bit of rust generic black magic (super cursed) refactoring, so that implementing new EVMs is less tedious.

The new ExecutionHandler trait does all the delegation and the default functions can be overwritten when implementing the trait for a custom EVM.

We put this type into a wrapper struct ExecutionHandlerWrapper that then implements sputnik::Handler and SputnikExecutor, this wrapper type is necessary because we can't implement foreign traits on our traits.

the ExecutionHandler comes with callbacks that are then invoked by ExecutionHandlerWrapper as sputkink::Handler, so we can override calls, listen for specific address (like cheatcodes).

But if we need to run additional evm stuff in those callbacks we can turn the ExecutionHandler into a sputnik::Handler as well using .as_handler()

If you have a look at the code you'll see this is super cursed and bloated... because of all the different traits, their generics and lifetimes...
Now the actual useful part. I implemented a ScriptVm, that can run custom commands. I started with a basic Fs.sol interface that provides bindings to do some disk IO, see fs.rs test
interface Fs {

    // Opens a file in write-only mode.
    // This function will create a file if it does not exist, and will truncate it if it does.
    function create(string memory) external returns (File memory);

    // Attempts to write the content into the file
    function write(File memory, string memory) external;
}

Closing as this will be easy to integrate in Revm as a standalone inspector, and think we'll have trouble merging this as-is in the short term. In general something we should be thinking about in the context of interfacing with the host OS, is table tests. e.g maybe there's some nice way where we can expose HTTP requests or reading JSON / CSV files for running arbitrary tests against vectors


[Analytics] Update Telemetry Middleware with new attributes

Is your feature request related to a problem? Please describe.

Updates to Microsoft.Bot.Solutions Middleware for TelemetryLoggerMiddleware, TelemetryLuisRecognizer, and TelemetryQnAMaker.
Describe the solution you'd like

✅
Supported

🔃
New Property

⚠
Bug found

BotMessageReceived

Attribute
Status

UserId
✅

ConversationId
✅

ActivityId
✅

Channel
✅

ActivityType
✅

Text
✅   (LogOriginalMessage)

FromId
✅

FromName
✅   (LogUserName)

RecipientId
✅

RecipientName
✅

ConversationName
✅

Locale
✅

Speak
🔃

BotMessageSend

Attribute
Status

UserId
✅

ConversationId
✅

ActivityId
✅

Channel
✅

ActivityType
✅

ReplyToId
✅

RecipientId
✅

RecipientName
✅   (LogUserName)

Locale
✅

Text
✅   (LogOriginalMessage)

ConversationName
✅

Speak
🔃

LuisIntent.INTENTName -> rename to LuisResult

Attribute
Status

UserId
✅

ConversationId
✅

ActivityId
✅

Channel
✅

ActivityType
✅

Intent
✅

IntentScore
✅

Question
✅   (LogOriginalMessage)

SentimentLabel
✅

SentimentScore
✅

LUIS entities
⚠

DialogId
✅

ApplicationId
✅

FromId
🔃

Sub-intent
🔃 (in cases of dispatch, only the top-level LUIS intent is logged)

[x] Fix logging LUIS entities attribute

QnAMessage

Attribute
Status

UserId
✅

ConversationId
✅

ActivityId
✅

Channel
✅

ActivityType
✅

Username
✅   (LogUserName)

OriginalQuestion
✅

Question
✅   (LogOriginalMessage)

Answer
✅

Score
✅

ArticleFound
⚠

QuestionId
🔃

[x] Fix ArticleFound boolean

@ryanlengel This is marked as closed and resolves most of my telemetry issues.  However, there is always an however, :)
The "Question" property isn't really rational between LUIS and QnA.  It also appears to be tagged incorrectly in the above table.  OriginalQuestion should be tagged with LogOriginalMessage.
For QnA the Question property is the matched Question from QnA, not what the user typed in.  What the user typed is in "OriginalMessage".  For Luis, what the user typed is in Question.  Yes, confusing.
I believe this is true for the both the enterprise template and Virtual Assistant.
Possible Solution:
Question - Is what the user typed in both cases. (So Question replaces OriginalQuestion for QnA)
MatchedQuestion - Is the matching QnA question. - Only for QnA.

@mekinney I agree that that is confusing - the telemetry work is going to be added into the SDK, I will follow up with this feedback. Considering Activity.Text is applied for both QnA and LUIS, that is better as the default Question.

FYI see https://github.com/Microsoft/AI/blob/master/docs/analytics/telemetrylogging.md for our latest documentation on the telemetry logging


Lol - I got issue here man, kindly sugest how to resolve it.

import navigationDebouncer from 'react-navigation-redux-debouncer';
import { createStore, compose, applyMiddleware } from 'redux';
import thunk from 'redux-thunk';
import reducers from '../reducers';
const store = createStore(
reducers,
{},
compose (
applyMiddleware (navigationDebouncer( 600 )) (thunk)
)
);
export default store;

The applyMiddleware function wants an array of middlewares, like so:
applyMiddleware ([navigationDebouncer( 600 ), thunk])
https://redux.js.org/api-reference/applymiddleware
This can be closed since it has no relevance to this library @parakhod


Rhmap 12127 request body size

Description of problem:
Limit of request size not properly configured
Changes:
Pass maxRequestSize to bodyParser
Add a test method
Version bump
Link to JIRA ticket: https://issues.jboss.org/browse/RHMAP-12127

SonarQube analysis reported 1 issue:

 1 info

Watch the comments in this conversation to review them.
Note: the following issues could not be reported as comments because they are located on lines that are not displayed in this pull request:

 Move this trailing comment on the previous empty line.


dbeaver/dbeaver#21053 Display errors in the result tab

The state of error viewer is reseting (restore default state 50/50) in case of catching errors.

verified


Feature: Flexible antispammer settings

Antispammer is the essence of the file.d that makes a decision on the need to parse the input log. It can be useful when any application writes logs at speed faster than File.d can read it.
Let's support flexible antispammer settings. Currently, all events pass through it and we cannot make exceptions . We must begin to separate important logs from the rest and give API to manage this behavior.
The new config will look like this:
pipelines:
  k8s:
    settings:
      antispam_threshold: 1000
      antispam_except:
        - condition: 'prefix'
          value: '{"error":true'
          case_insensitive: true

        - condition: 'contains'
          value: '"error":true'

        - condition: 'suffix'
          value: '"error":true}'
          case_insensitive: false

After discussion with colleagues, they came up with a temporary solution before introducing their own language:
pipelines:
  k8s:
    settings:
      antispam_threshold: 1000
      antispam_except:
        - cond: 'and'
          value:
            - func: 'prefix'
              value: ['{"error":"debug"']
              case_insensitive: true
              invert: true
            - func: 'contains'
              value: ['{"service":"alerts-agent"']
              case_insensitive: false
        - cond: 'and'
          value:
            - func: 'prefix'
              value: ['{"error":"debug"']
              case_insensitive: true
              invert: true


generate-prs: bump revision with PRs

This ensures that these patches land with users on the formula's current version, not the next time they upgrade.
Closes #19.

NB: I'll give this a dry-run once the currently active PR workflow completes.

https://github.com/Homebrew/brew-pip-audit/actions/runs/5163858862/jobs/9302416846


[Slider] New Slider API

Closes https://github.com/mui/base-ui/issues/216
Closes https://github.com/mui/base-ui/issues/76
Demos:

basic/range: https://deploy-preview-373--base-ui.netlify.app/experiments/slider/
vertical: https://deploy-preview-373--base-ui.netlify.app/experiments/slider-vertical/
gradient (heavily customized): https://deploy-preview-373--base-ui.netlify.app/experiments/slider-gradient/

I had a quick look there and noticed the thumb still shifts to the right/left when you click the thumb.
https://github.com/mui/base-ui/assets/805073/bb0d917c-7ded-4acb-b090-ed8600e7a954

I pushed a commit to update the CSS to be simpler, fix a few bugs, and not rely on left, margin-bottom, or fixed values to position the thumb.
Additional notes:

Consider rendering the <input> as a sibling of the track rather than a child of the thumb, so we can avoid having to use focus-within? Let's chat about this before changing the code.
Change data-active to data-dragging?
Add the data-disabled attr to the track, fill, and thumb, so we can style those components directly without using :has or descendant selectors.
Root should have role="group", and then use aria-labelledby to connect the Output.
In vertical mode, when you press and hold the thumb, then move the pointer 1px up or down, the thumb jumps a large amount. Also, when you're dragging in vertical mode, the thumb becomes misaligned with the pointer.

After clicking a thumb it retains its focus, even after the mouse is released.

This is because the <input /> inside the Slider receives focus when you click the thumb, track, or tab to it. The demo uses :focus-within to apply the focus ring when the input is focused. We can't use focus-visible because the thumb is a <span> and can't receive focus directly. This is one reason I suggested having the input be a sibling of the track instead in my previous comment.

Clicking anywhere other than the left third of the thumb causes it to jump to the right.

I'm not seeing this in Chrome on Mac. Video attached. Which browser/platform are you using?
https://github.com/mui/base-ui/assets/805073/ed85a90e-dca0-4b9b-86a1-6773d8ea93d6
@mbrookes

In vertical mode, when you press and hold the thumb, then move the pointer 1px up or down, the thumb jumps a large amount. Also, when you're dragging in vertical mode, the thumb becomes misaligned with the pointer.

I will fix this - I think it's a side effect of fixing the thumb shift!

After clicking a thumb it retains its focus, even after the mouse is released.

@colmtuite Without changing the structure for now, I've updated it so the input is blurred on the Thumb's pointerup https://github.com/mui/base-ui/pull/373/commits/79ebc3271884f2c79aa66ceb2610c02e0ab7ba6a

Here's a new one. Vertical thumb alignment is broken in Chrome on Mac:

@mbrookes Fixed ~ it was just a stray css property in the demo!

Without changing the structure for now, I've updated it so the input is blurred on the Thumb's pointerup

@mj12albert Why did you do this? It's a major a11y flaw now.

Just wanted to make a quick fix to the demo... I have reverted it

Just wanted to make a quick fix to the demo... I have reverted it

Ok. Yeah when you click anywhere on the Slider, it should become focused. That's just how it works. Same if you tab to the Slider. I understood that comment to be referring to the focus style, which we could hide if we could use :focus-visible instead of :focus-within. We can't do that with the current set-up. But we can't prevent the Slider from receiving focus.

Root should have role="group", and then use aria-labelledby to connect the Output.

@colmtuite Did you mean input instead of output? I think aria-labelledby should connect Root<>Label and Input<>Label; and the output is connected to the input(s) using for, like in this example: https://deploy-preview-373--base-ui.netlify.app/experiments/slider-label/
(source: https://github.com/mui/base-ui/blob/2e5975b07beb3cb798d50cccc56551e20fa2c670/docs/pages/experiments/slider-label.tsx)

Bug: In the gradient slider demo, if you focus a thumb and then press ArrowLeft/ArrowRight, it creates new thumbs and undefined values appear.

Bug: when focusing a thumb in the basic range demo, once the thumb moves past the other one, its focus ring style disappears.

Bug: when focusing a thumb in the basic range demo, once the thumb moves past the other one, its focus ring style disappears.

This is tricky... when the thumbs "cross", the first thumb blurs and stops, and the second thumb gains focus and starts moving, even though it looks like the first thumb is being dragged past the second thumb (which never moves), so the :focus-visible state (and styles) doesn't get "transferred" to the second thumb
Because this causes the blur/focus handlers to fire on the Thumb, it could lead to strange and unpredictable behaviors when passing onBlur/onFocus to the Thumb. Maybe this could be worked around by using preventDefault somehow, but it wouldn't solve the issue with the :focus-visible state.
If I'm not mistaken, I don't think :focus-visible can be triggered with programmatic focus. The only idea I have right now is to override the internal sorting of useCompoundParent here and/or the slider, and separately track the order of the thumbs if that makes any sense.
The old implementation got around this by manually tracking a focusVisible state and using a class as a style hook. What do you think if we had to fall back to doing this but with a data attribute? @colmtuite

General

"The previous track component referred to the filled portion of the slider "bar". This component is dropped, but can be easily implemented using a new useSliderContext hook" We cannot drop this feature, it's important for the UX. How can we bring it back? Do we need to add a Slider.Range component?
The components are missing the data-orientation attr. Every component except the thumb should have this attr.
What is the “distance” in the minDistanceBetweenValues prop? Is it a step? If so, we should replace “Distance” with “Step” in the prop name. Otherwise, it’s confusing, you might think it’s px.
I think minDistanceBetweenValues should default to 0.
If you set minDistanceBetweenValues to 5. Then drag the first thumb to value 0, and drag the second thumb to value 5. Then edit the minDistanceBetweenValues value, weird things happen. Play around with this a bit and you should notice the weirdness? It’s not necessarily an issue, because the prop seems to work fine. Just wondering why the experience is weird?

a11y

When you focus the slider, VO announces “You are currently on a group”. I think it should announce “You are currently on a slider”?
The “role=group” element is better as a  rather than a ?
Any slider label should be a <label>. In the range slider examples, the label is a <span>.
When you focus the slider, the <label> content is not announced by the SR because the “role=group” element is not labelledby the <label>.
Adding aria-label=“start” and aria-label=“end” to the range slider inputs might help with SR announcements. We want to have the screenreader announce “start range” and “end range” when you focus a thumb in a range slider. This might cause issues if people add more than 2 thumbs, unless we get fancy? Not sure we should address this problem in this first version. Thoughts?

Docs

The vertical orientation demo in the docs is not much use without styling. We should add the styles to the code block.
Remove the disabled example from the hero demo to keep it simple and reduce the code.
In the “Overlapping values” section, it says “In the below example, the thumbs cannot be moved further towards each other” but there is no example below.
The CSS is dodgy in the vertical orientation example. Clicking to the left or right of the gray track doesn’t activate the slider, you must click exactly on the gray track. Also, when you set the value to 100, it looks like the centre of the thumb has gone beyond the end of the track.
We’re not currently demoing our hooks in other components, or demoing how to create custom components or build on top of our components. So I think the “Custom subcomponents” section is out of place. We should probably remove it for now, and document it later, when we get around to shipping a solution for marks.

When you focus the slider, VO announces “You are currently on a group”. I think it should announce “You are currently on a slider”?

I've done some more testing with VO, it announces the group first, then announces "...currently on a slider" when you arrow to the thumb which has the actual 'slider' role
https://github.com/mui/base-ui/assets/4997971/92e84915-2c58-4616-b9ea-944675a5b117

Adding aria-label=“start” and aria-label=“end” to the range slider inputs might help with SR announcements.

aria-label doesn't announce, but setting aria-valuetext does, currently there is a getAriaValueText prop on the thumb for this:
<Slider.Thumb getAriaValueText={(thumbValue) => `start range ${thumbValue}`} />

We could set this as the default if the user doesn't explicitly provide aria-valuetext, what do you think? @colmtuite

@mj12albert

When you focus a single thumb slider, VO announces “[label], group, [value], group”. I think it should announce “[label], slider, [value], group” or “[value], [label], slider, [label], group”?
In a range slider, when you move focus from the first thumb to the second thumb, VO announces “end range, [value], group”. I think it should announce “[value], end range, slider”.
What is the scale prop on Root?

In a range slider, when you move focus from the first thumb to the second thumb, VO announces “end range, [value], group”. I think it should announce “[value], end range, slider”.

I've updated this so it announces "value" before "start/end range", it's announcing correctly as "slider" for me and not group though, I think this is just a VO quirk:
https://github.com/mui/base-ui/assets/4997971/18e92f84-9c10-4638-bbe7-5f733236eec2

When you focus a single thumb slider, VO announces “[label], group, [value], group”. I think it should announce “[label], slider, [value], group” or “[value], [label], slider, [label], group”?

You mean when VO focuses on the Root and not the Thumb right? I don't think it's possible to get it to announce "slider" unless it explicitly has the slider role (which is obviously incorrect). It also doesn't announce "group" like that for me, it could also be a VO issue:
https://github.com/mui/base-ui/assets/4997971/0e13fea5-7d02-4d67-b5ff-36808d55c377

What is the scale prop on Root?

The scale prop enables a non-linear scale (a feature from Material UI): https://mui.com/material-ui/react-slider/#non-linear-scale
We could add a demo for this, unless you want to get rid of it? (Or are you just asking)
@colmtuite

Ok on the a11y stuff 👍
On scale, I was just asking what it was. I read the MUI docs just now and still not sure what it does? 😅

I read the MUI docs just now and still not sure what it does? 😅

Not sure if I can explain it better than the docs but let me try 😓 :
First set up a slider like this:
<Slider min={5} step={1} max={10} defaultValue={5} />

The possible values are: 5, 6, 7, 8,9, 10
Now we add the scale prop, which is a function that can transform the slider value.
<Slider min={5} step={1} max={10} defaultValue={5} scale={(value) => 2 ** value } />

So now the default value of 5 will become 2^5 = 32
And the possible values of the slider become 2^5, 2^6, 2^7... 2^10 instead.
Does this make sense? Maybe it's the name scale that is unclear 🤔 @colmtuite

@mj12albert I understand now, thanks for explaining. Let's remove this functionality+prop for now.

@mj12albert I understand now, thanks for explaining. Let's remove this functionality+prop for now.

OK I've removed it


PowerShell commandlets incorrect

Hello there,
In the section Delete with PowerShell, the commandlets are incorrect.
Commands Set-AzSiteRecoveryVaultSettings and Get-AzSiteRecoveryFabric are not part of the Az module. I thin these are meant to be Set-AzRecoveryServicesVaultContext and Get-AzRecoveryServicesAsrFabric, and potentially Get-AzRecoveryServicesVaultSettingsFile, but I am currently trying to figure that bit out.
Kindest Regards,
Dan Dimitrov

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: ce6ad6e7-d15f-5e98-57ef-cfa59f6dff78
Version Independent ID: 035bcb10-18f1-0831-99b7-f76a5ad21ddf
Content: Manage the configuration server for disaster recovery with Azure Site Recovery - Azure Site Recovery
Content Source: articles/site-recovery/vmware-azure-manage-configuration-server.md
Service: site-recovery
GitHub Login: @Sharmistha-Rai
Microsoft Alias: sharrai

Thanks for brining this to our attention. We will investigate it further and update you shortly.


Avoid ballerinai packages and injected observability packages getting added to dependency-graph.json

Description:
If a package is built with observabilityIncluded set to true, the bala file that gets created contains the observability packages in the generated dependency-graph.json file. We should avoid persisting observability packages and ballerinai packages in general in the dependency-graph.json.
But observability packages should be added to dependency-graph.json if they are coming as a transitive dependency.

Reverted this PR because of https://github.com/ballerina-platform/ballerina-lang/issues/31724
Need to add the fix again with the following changes:

observe package should be skipped if they are injected only.

After the new package resolution design, this has changed to add all the dependencies to the dependency-graph.json including ballerinai and injected observability packages. Hense closing this issue.


Circular Image Inside Other

Hey, I want to add a circular image inside other image, like to make a profile, this is the code I have at the moment.
But as you see there are two different files the user mask and the bienvenido.png, I want to add user mask instead of memberavatar function, but Im really new at jimp and no one could help me with this at the moment, then my question is, How can I add the first image to the second one¡

exports.run = async (client, message, args, Discord) => {
  var Jimp = require("jimp");

 const memberavatar = message.author.displayAvatarURL;
 var channel = client.channels.get("523550838501802004");

  var p1 = Jimp.read(memberavatar);
var p2 = Jimp.read("https://cloud.githubusercontent.com/assets/414918/11165709/051d10b0-8b0f-11e5-864a-20ef0bada8d6.png");

Promise.all([p1, p2]).then(function(images){
    var user = images[0];
    var mask = images[1];
 user.mask(mask, 0, 0).getBuffer(Jimp.MIME_PNG, (err, buffer) => {
message.channel.send(``,new Discord.Attachment(buffer ,`bienvenido.png`))
})

});

   var Jimp = require("jimp");
Jimp.read("https://cdn.discordapp.com/attachments/467439114837426196/523583438087782400/hylex.png", function (err, imgprecesada) {
imgprecesada.resize(1024, 450);
Jimp.read(`${memberavatar}`).then(function (memberavatar) {
memberavatar.resize(240, 240)
imgprecesada.composite(memberavatar, 400, 100)
Jimp.loadFont(Jimp.FONT_SANS_64_WHITE).then(function (fuentes) {
imgprecesada.print(fuentes, 320, 20,"BIENVENIDO")
imgprecesada.print(fuentes, 230, 330,`${message.member.user.tag}`)
Jimp.loadFont(Jimp.FONT_SANS_32_WHITE).then(function (fuentemenor) {
imgprecesada.print(fuentemenor, 400, 400,`${message.guild.name}`)
imgprecesada.getBuffer(Jimp.MIME_PNG, (err, buffer) => {
message.channel.send(``,new Discord.Attachment(buffer ,`bienvenido.png`))
})})})})});
};

I assume you can't just use css to round the images

some problems I see immediately

you need to await jimp.read and anything async
require jimp once at the top of the file. doing it inside the function is super weird. you should also not need to do it multiple times
you read the same image multiple times when its already in a const
unnecessary template string
you can chain image manipulation functions

here is your code cleaned up a little bit using my points above:
const Jimp = require("jimp");

exports.run = async (client, message, args, Discord) => {
  // Mask the user image with a circle
  const user = await Jimp.read(message.author.displayAvatarURL);
  const mask = await Jimp.read(
    "https://cloud.githubusercontent.com/assets/414918/11165709/051d10b0-8b0f-11e5-864a-20ef0bada8d6.png"
  );

  const masked = await user.mask(mask, 0, 0).getBufferAsync(Jimp.MIME_PNG);
  message.channel.send(``, new Discord.Attachment(masked, `bienvenido.png`));

  // Get background, place user image, and write name/guild
  const imgPrecesada = await Jimp.read(
    "https://cdn.discordapp.com/attachments/467439114837426196/523583438087782400/hylex.png"
  );
  const fuentes = await Jimp.loadFont(Jimp.FONT_SANS_64_WHITE);
  const fuentemenor = await Jimp.loadFont(Jimp.FONT_SANS_32_WHITE);

  user.resize(240, 240);

  const imgWithText = await imgPrecesada
    .resize(1024, 450)
    .composite(user, 400, 100)
    .print(fuentes, 320, 20, "BIENVENIDO")
    .print(fuentes, 230, 330, message.member.user.tag)
    .print(fuentemenor, 400, 400, message.guild.name)
    .getBufferAsync(Jimp.MIME_PNG);

  message.channel.send(
    ``,
    new Discord.Attachment(imgWithText, `bienvenido.png`)
  );
};

NOTE: I have not tried to actually make the masking work

I FKING LOVE YOU!!! <3

Did it work? I can take another look today if the masking is still off. (I've never used the mask function so it will take a little tinkering)