Colors of Lenses added via MoreLenses integration can be configured

Ready for Review
What this is (short summary)

All of the colors of the lenses added by the More Lenses mod are now configurable in the CQUI settings menu

How best to Review This or Test this

Best thing to do: load up CQUI from this branch and give it a try
When reviewing: Hide Whitespace Changes (settings icon on the Files Changed tab of GitHub page)

More Details and Stuff

Edit text boxes only allow numbers and values between 0 and 255; the sliders update when values are changed
Sliding a slider updates the value in the edit text box
The actual lens colors settings are only updated when "Confirm" is pressed (otherwise it was very slow because values got updated with each change in the slider, etc.)
Once a lens color is changed in a save game, it'll stay that updated color on reload
A lot of files changed, which includes the localization files (strings generated by the Azure translation thing-a-ma-bob)
There is a little bit of refactoring of the ModLens files to make this work, but I think the changes are pretty straight forward
Normalizing the names of strings to make finding the localized strings easier was done (COLOR_FOO_LENS_BAR now can expect to find LOC_HUD_FOO_LENS_BAR)
I intend to implement these changes in MoreLenses mod itself and share with Astog
I did this because enough folks asked and I thought it interesting challenge

Settings menu (scrolled slightly and rest of the way)

Gifs taken before I added the rest of the lenses to the menu, but the behavior is still the same:
Sliders update the preview box; can just add values directly in the text boxes, and the default button returns that lens to the usual More Lenses color.  When the setting is changed, it shows as yellow.  When the gif restarts it reverts to pink.

Oy... this is turning into a monster but it works so far

Updated the title and the text on the first post.

This is an impressive update!
I have a question: how do a specify a 'neutral' color? For example, on the 'Resources' lens, I don't tend to care too much about bonus resources, so I might not want them colored at all. Would I just set the color to 'white' or 'black'? Or is this not possible the way the feature is currently written?
I'm not sure if some people are effectively asking for 'no coloring' for some things on some lenses? (I might be wrong).
I fully appreciate it would be a lot more work to implement - I am just asking the question!  ;-)

@RustyD thanks - at the moment the best way is probably just to set the "neutral" color to black, it's the least intrusive.  I was giving some thought to adding a "disable" button to go along with the default button in order to turn a color off
For example - this is setting Black for all resources when looking with the Builder lens - the Tobacco should be the only Resource not worked in the picture


Hybrid Azure AD join (on-premises AD) using Windows Autopilot user-driven mode

Hello,
I have read that it is now possible to hybrid Azure AD join (on-premises AD) using Windows Autopilot user-driven mode (https://techcommunity.microsoft.com/t5/Windows-IT-Pro-Blog/Windows-Autopilot-Hybrid-Azure-AD-join-and-automatic/ba-p/286126).
Thus "In the Windows out-of-box experience, joining an on-premises Active Directory (AD) domain is not supported" should reflect this change.
Thank you.

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

ID: 7a7a5351-21c0-946d-fdc0-5e1943aa0a01
Version Independent ID: acf0eb8d-109f-c3b4-b862-adb61ae8fdc7
Content: Join a new Windows 10 device with Azure AD during a first run
Content Source: articles/active-directory/devices/azuread-joined-devices-frx.md
Service: active-directory
GitHub Login: @MarkusVi
Microsoft Alias: markvi

@mchiri Thank you for your feedback . We will investigate and update this thread.

Thanks for the feedback, @mchiri . I have assigned this issue to the content author, @MarkusVi , to look into.

Sent follow-up email to product group for response

@mchiri, there's a nuance here. Autopilot supports hybrid join not domain join. Technically it's still true that on-premises domain join is not supported in Windows 10 OOBE . Autopilot implementation follows a different logic that it first requires Azure AD authentication and Intune enrollment before the device can be domain joined, so it does not indicate that on-premises domain join is supported in OOBE by default when there's no AAD and Autopilot.

#please-close


docs(readme): add contributors

Coverage remained the same at 74.205% when pulling 70611fab9412eb9bf0e4adc4336d8ad61fed6303 on add-contributors into c605b58b9acf279613c68c218dee2a8d7dffc3ce on master.

:tada: This PR is included in version 4.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Update README.md

I put 8th Light  and Thoughtbox in the Europe section to keep the country groupings consistent and added my name to the credits section.

✅ By submitting this PR, I have verified the following

[] Checked to see if a similar PR has already been opened 🤔
[] Reviewed the contributing guidelines 🔍
[] Added my name to the bottom of the list under the Credits section in the README.md with a link to my website or GitHub profile 👥

Lovely!! Thank you so much for your contributions 🎉 🎉 🎉

Also, just a heads up - I would add a profile pic to your GitHub profile so it looks nicer.

Yes, I'm starting to populate my GitHub account now and am working on getting a good headshot. Thanks! :)


Document what needs to be POAM'd if Firewall Standard is used instead of Premium

Benefit/Result/Outcome
As an MLZ user in MAG or an Air-Gapped cloud, I need to know which SCCA controls aren't implemented under Firewall Standard so that I can submit a POAM for air-cover while waiting for Firewall Premium to be deployed/approved.
Description
There is going to be a period in which FW Premium isn't available in some Azure environments, but the user of MLZ will still want to deploy.  They will need to understand the controls delta between Standard and Premium so they can add additional Azure resources to fill the gap or submit a POAM to bridge the roll-out/GA timeline.
Acceptance Criteria

A clear document of which SCCA controls are covered by FW Premium vs. FW Standard
A clear document on how to upgrade an existing MLZ FW from Standard to Premium when it becomes available in an Azure Cloud.

Premium is available in Fairfax and no need POAM.


Get-GSGroup Fields parameter cannot be found

Hey there,
I'm trying to use Get-GSGroup with just the Fields parameter to get all the groups in my org with certain fields. I've got version 2.7.0 of PSGSuite, and I'm running on Windows 10 x64 1803 17134.112, with Powershell version 5.1. This is what I'm trying to run:
$Fields = @("Aliases", "Description", "EMail", "Kind", "Name", "Members")
$Groups = Get-GSGroup -Fields $Fields

However, when I run this, Powershell throws an error:
Get-GSGroup : A parameter cannot be found that matches parameter name 'Fields'.
At C:\development\ITTools\Projects\Domain and USMT\ImportGroupsFromGSuite.ps1:4 char:11
+ $Groups = Get-GSGroup -Fields $Fields
+           ~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Get-GSGroup

I should note that I'm running this command using a debugging session in Visual Studio Code with the Powershell extension. I did confirm that this error is thrown in a normal Powershell session as well.
When stepping into the execution, I find that, in the Get-GSGroup definition, the error gets thrown on line 74, which is calling Get-GSGroupListPrivate, and that function doesn't have a Fields parameter. Because Get-GSGroups passes $PSBoundParameters to Get-GSGroupListPrivate, it throws the parameter cannot be found error.
If it's not feasible to have the fields be passed for retreiving all groups, perhaps a more descriptive error would be helpful, as well a note in the docs. Otherwise, I guess this may have been an oversight in the coding process?
Thanks for putting together such an amazing library!

@WToorenburghEasyMarkit thanks for the catch!! I'm on it!! Should 100% be supported so let me make sure that can happen (or figure out barriers at the very least!)

@WToorenburghEasyMarkit - alright did some digging and found some oddness. The List() request for Groups in the .NET SDK does have a Fields property, but any attempt to use it after applying the fix returns an invalid field error. Checking on the actual API explorer and it doesn't look like their List method allows specification of Fields like the Get method does
That being said, pushing up a fix in v2.8.1 that blocks use of Fields unless specifying a Group as well via parameter set inclusion to prevent further confusing errors, since Google doesn't appear to support it currently with the List method for Groups
Also worth noting: Fields for Google's API's are always mixed camel case, with the first letter always lower case. So your call would need to look something like this otherwise you'll get similar errors (additional corrections on field names):
$Fields = @("nonEditableAliases", "description", "email", "kind", "name", "directMembersCount")
$Groups = Get-GSGroup -Group mytestgroup -Fields $Fields

deployed!
Also worth noting that the speed difference between specifying a single field vs having it return all fields is negligible, sometimes even taking longer to return a group with a single field vs just returning all fields:
[I ♥ PS 6.0.2] >_ Measure-Command {Get-GSGroup $groupName -Fields 'description'}

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 511
Ticks             : 5116080
TotalDays         : 5.92138888888889E-06
TotalHours        : 0.000142113333333333
TotalMinutes      : 0.0085268
TotalSeconds      : 0.511608
TotalMilliseconds : 511.608

[8] [STATUS: SUCCESS IN 0:00:00.5163 AT 23:16:24 ON 2018-06-28]
~
[I ♥ PS 6.0.2] >_ Measure-Command {Get-GSGroup $groupName}

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 458
Ticks             : 4580480
TotalDays         : 5.30148148148148E-06
TotalHours        : 0.000127235555555556
TotalMinutes      : 0.00763413333333333
TotalSeconds      : 0.458048
TotalMilliseconds : 458.048

[9] [STATUS: SUCCESS IN 0:00:00.4619 AT 23:16:31 ON 2018-06-28]
~
[I ♥ PS 6.0.2] >_

VS
[I ♥ PS 6.0.2] >_ Measure-Command {Get-GSGroup $groupName -Fields 'description'}

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 477
Ticks             : 4777180
TotalDays         : 5.52914351851852E-06
TotalHours        : 0.000132699444444444
TotalMinutes      : 0.00796196666666667
TotalSeconds      : 0.477718
TotalMilliseconds : 477.718

[10] [STATUS: SUCCESS IN 0:00:00.4823 AT 23:19:11 ON 2018-06-28]
~
[I ♥ PS 6.0.2] >_ Measure-Command {Get-GSGroup $groupName}

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 511
Ticks             : 5111990
TotalDays         : 5.91665509259259E-06
TotalHours        : 0.000141999722222222
TotalMinutes      : 0.00851998333333333
TotalSeconds      : 0.511199
TotalMilliseconds : 511.199

[11] [STATUS: SUCCESS IN 0:00:00.5157 AT 23:19:14 ON 2018-06-28]
~
[I ♥ PS 6.0.2] >_

You are absolutely amazing. Thank you so much for such a quick response, and for making a fantastic PS module!

I'm glad you like it! Thanks again for submitting the issue to let me know about the bug!


Salvage Weapon Nerf

About the PR
Reels in the salvage weapons. The changes are as follows:

The Proto-Kinetic Accelerator now has a range of about 4~ tiles and does 10 damage per hit. You can 5-shot carp with it.
The crusher now does 15 damage when wielded. You can 2-shot carp with it.
The crusher dagger now only does 10 damage.

Why / Balance
The current salvage weapons are hilariously overtuned. There's currently almost never any reason to use any weapon for salvage outside of these. This should open up more design space for upgrades/sidegrades, & generally reel them in more to where these weapons probably should be. My thought process for each weapon is as follows:

The PKA is easily the worst offender of any of these. It's constantly used to basically just completely ignore enemy encounters & trivially break stuff due to its massive burst damage, range, & infinite ammo. Kiting weapons are interesting, but not when the kiting is literally free and comes at zero risk to the user. The significantly lower range should bring this weapon in-line a lot more to where it probably should be, and the mediocre damage should also hopefully reinforce the kiting aspect. In testing, the PKA still seems to be the safest salvage weapon.

Separate from the damage balancing, the lower structure damage also prevents it from breaking stuff it shouldn't (crates, walls, etc.) and encourages players to look for alternatives to mine instead of just having a weapon that can do everything (the PKA can still 3-shot rocks if need-be, but it's pretty slow.)

The crusher just generally had really weirdly high damage. I feel iffy on keeping the faster attack speed, but can recognize that it's probably to make up for the fact that the weapon has no wideswing. In testing against carp, the crusher was difficult to use, but very rewarding when I could land hits the enemy.

The crusher dagger had the same DPS as the energy sword. I don't think I really need to elaborate beyond that.

Media
N/A
Requirements

[X] I have read and I am following the Pull Request Guidelines. I understand that not doing so may get my pr closed at maintainer’s discretion
[X] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Changelog
:cl: Salvage Weapon Nerfer

tweak: Nerfed the Proto-Kinetic Accelerator, Crusher, Crusher Glaive, and Crusher Dagger.

4 tiles of range sounds a bit low, i'd suggest 6 or 7 instead, as lower ranges can troll you with ping (client shows you aren't in enemy's melee range whilist you actually are) and 4 tiles just seems plain short

So, I think the PKA nerf is a bit harsh. I agree with changing the structural damage, but like... 10 damage per hit, at 0.5 firerate? do we really want the weapon to do a measly 5 dps, coupled with the lower range? At that point there's literally no reason to not just use your knife. The PKA already currently does less damage than the Svallin. I agree with the heavy range nerf, to make it so that there is at least some risk involved in utilising it, but such a steep damage nerf is too much in my opinion. It shouldn't take 10 seconds to kill a single carp with a weapon like that, and the problem will only become more apparent when more difficult salvage mobs like the Goliath are added.
Crusher and Crusher dagger nerfs are fine. Latter especially needed wielding, 30 DPS was bonkers.

crusher dagger was stupidly op and was long overdue
pka being unfairly nerfed into the ground will just mean salv buys lasers or smgs roundstart so they can clear a wreck before it despawns

It seems to me that this is too harsh nerf of the PKA, it will lead to the fact that it will simply be abandoned, they will buy combat weapons. After all there is just no use for the PKA now, the range reduction is reasonable, but such low damage makes it useless.

It seems to me that this is too harsh nerf of the PKA, it will lead to the fact that it will simply be abandoned, they will buy combat weapons. After all there is just no use for the PKA now, the range reduction is reasonable, but such low damage makes it useless.

Not really, they'd still be important as starter weapons that don't need security authorisation or spesos (4 tile range is rather low

Starter weapons to what? Salvage doesn't really have an upgrade to go to other than just ordering weapons from cargo, which I'd honestly just prioritise doing ASAP if this was merged. If I couldn't get a laser crate from roundstart, I'd just get a melee weapon and some meds.

and yeah 10 damage on the PKA is very low, especially with the range limit, salv will just end up using melee or buying guns at that point as using the PKA would just be suicide

This kills the salvagers, 5 hits on a carp is a longer time to kill than carp will have on the salvagers, if you wanna do this leave the crushers untouched, and make the PKA 15 with no range nerf, also leave the structure damage on the PKA, its primary use isnt a weapon its a mining tool that just so happens to be used as a weapon. As it stands the PKA changes is just making it so salvagers will die more. And the crushers dont wideswing on wielding they shoot a blast that marks an enemy which is really important for salvage survivability. With prososed chamges most salvagers would straight up be better off just illegally buying a laser crate and getting told off, then never returning to station because theyll get arrested as soon as the do.

Upon a second reading of the commits i actually have found myself more confused, if you dont want these being used as weapons why nerf the structure damage? As it stands 30 is about whats required for them to be used to actually mine and thats being made obsolete, so what in your words is the new purpose of these items, because theyre no longer usable for any of their intended purposes.

I just want to ask that we at least have the DPS be on par with a disabler, which does 10 DPS, despite not being intended for fighting.

i honestly think the damage nerf is totally unecessary and that just keeping it to a 4 tile range nerf is fine. It was already a low damage weapon, sporting dps lower than the Svallin laser pistol and only barely higher than a disabler. Considering salvage mobs are gonna get stronger, too, I don't think the PKA will hold up.

KA really needs a nerf, because of how lethal it is on station. Other weapons getting nerfed are REALLY unnecessary

Do you want to finish off the salvage? RND will now be completely without resources.
This will make salvage weapons toys and absolutely useless

I am very curious as to what your round as a salvager looks like after these nerfs, because a crusher or a glaive arent like always gonna happen, and if they do theyre now kinda useless, because keep in mind these cant go in bags, they can no longer break rocks easily and they arent as useful as a weapon anymore. What is your proposed "this is how i forsee every salvage round going"?

I'm not bothered either way about the crusher changes, but the PKA nerf is way too much. 2 shotting basic carps is important to salvage gameplay flow. Maybe a small fire rate decrease and less structural damage is justified, but not this.
I also don't like the idea of a range nerf. As salv the main advantage you have is that you outrange enemies. If you're going to force salv to get closer, you're going to force more trips back to the station to heal or (more likely) more time spent looting health kits. Salv is already useless 50% of rounds, forcing them to spend less time salvaging will just make the problem even worse.

Ok I understand the PR... But would this not often make the pickaxe a preferable alternative to the PKA? Not just because of the wideswing but stats too? (I don't remember the stats exactly)

suggestion that came up in discord discussion after people calmed down from the initial idea of a PKA nerf:
could incorporate this into a moddable PKA weapon, base stats using the changes in this PR and "upgraded" stats using the version currently available in the game, if people want to add mid-tier upgrades to go between PR version and current game version i don't see why not but that definitely goes beyond the scope of this PR. have the final upgraded version require a part that either forces them back to the station at the very least, or forces them to go to science to have it installed (idk pick something gold-related).
would address cargo having an overused option right out of the gate by giving them something to work towards, either independently buying resources or bringing resources from early salvages to the station to be refined into upgrades for their shit. also obligatory science inclusion because upgraded tech coming from science just makes sense. also everyone hates science and i think it's funny forcing that player-to-player interaction with the two most antisocial departments on the station.

i think pka upgrades are good and would integrate well with a lot of the design for equipment and stuff for salvage. i would definitely want them in the game some point and was planning on adding them. of course, they're not really reasonable to have until the pka gets a bit of a nerf to not be quite so nutty.

i think pka upgrades are good and would integrate well with a lot of the design for equipment and stuff for salvage. i would definitely want them in the game some point and was planning on adding them. of course, they're not really reasonable to have until the pka gets a bit of a nerf to not be quite so nutty.

I think if we wanna still nerf the PKA theres a happy middle it can sit at somewhere between this PR and current, also i agree the crusher dagger needs a nerf but why not make its DPS equal to the survival knife? Its already an upgrade because it has a really good flashlight, and to compensate for nerfing crusher/glaive why not also make them fit in the suit slot?

My sides. Play salvage more, then retract those nerfs after realizing what you've proposing.

Also glaive description shouldn't mention user healing, not to mention it doesn't heal user "a lot more".

How many PRs do we need to kill salvage as a job? Three.
Simply nerfing doesn't fix things. In 13 there were PKA upgrade modules that you could install so that the PKA did not suck. Here?
Suggestion - try playing salvage.

As a baby Salv, I am barely able to take a single carp with the current kpa.
If you call that a skill issue, I am calling what you want to do a skill cliff.
We babies need a chance too!

🆕-Salvage removed from the game.

First, we are in SS14, not SS13, where the tile-based movement system doesn’t exist. Therefore, reducing the radius of the PCA seems like a wrong decision. In SS13, where hostile fauna moves tile by tile and doesn’t zigzag like NPCs do in SS14, reducing the firing range of the PKA to 4-5 tiles makes sense. However, in SS14, this is inappropriate, especially during expeditions where shooting small creatures like carps and xenomorphs would become extremely difficult. Let's break this down.
Carps are fish that can inflict serious damage and cause bleeding. The proposal suggests reducing PCA damage by 2.5 times and decreasing the firing range to 4 tiles. This is unacceptable because it would take two shots to kill a single carp, and with these changes, it would take five. Imagine a scenario where a scavenger on an expedition accidentally opens an airlock, releasing two or more carps, and becomes defenseless because the PCA's damage is too low. Additionally, the carps will almost certainly attack since the spacesuits slow down the scavengers by 10%.
Now, regarding xenomorphs. Take the Spitter as an example. It’s useless to shoot at it from afar with the PKA since it can attack from a long distance, forcing the scavenger to engage in close combat. The same goes for other types of xenomorphs; they’ll quickly catch up to the scavengers, practically guaranteeing their death.
Second, I see no reason to reduce the damage of the Crusher, whether it's a glaive or a regular one. The most that could be done is to decrease the attack speed, but nothing more. The Crusher, as the name implies, should deal significant damage, unlike a bridge fire axe, which can incapacitate a character in 5-6 hits.
Third, regarding the Crusher Dagger: there are two options. Either reduce the attack speed while keeping the damage at 15 units or lower the damage to 10-12 units but keep the current speed. Otherwise, it will just be a survival knife with a different name.

This is a brief overview of why I disagree with this proposal. It seems that the author of the proposal hasn’t fully experienced playing as a scavenger and is mainly trying to make the gameplay more difficult for those who do.

dont merge this bruh

i think pka upgrades are good and would integrate well with a lot of the design for equipment and stuff for salvage. i would definitely want them in the game some point and was planning on adding them. of course, they're not really reasonable to have until the pka gets a bit of a nerf to not be quite so nutty.

could just toss the current game version of the PKA behind the science research option for it, call it a Mk 2 so there's a differentiation between it and this PR's PKA and build a mod system later on. or y'know just drop the "proto" from "proto-kinetic" under the researched version to further emphasize it's not a prototype and in a more finished state.
it's not like constructing a PKA using current resource requirements are overly restrictive at the moment, and would allow the nerfed PKA to be playtested to see just how much of an actual difference there is rather than just have everyone argue over numbers. worst case scenario at that point we either dial back the nerfed version or revert entirely until a more fleshed out system can be looked into

i talked with flare about it and the plan is to remove pka changes from this PR and then have a separate pr that both nerfs the pka and introduces upgrades in sci / salv

@Flareguy Tbh, Post a video of you being cracked on Salvage somehow abusing current PKA, and I'll believe you, but you really need to include a way of upgrading PKA so that people that are newer have a way to NOT DIE. I understand what your wanting but just no.

I assure you, if this proposal is accepted, most scavenger players will abandon the PKA and start using weapons purchased from the cargo request console.

Сколько PR нам нужно, чтобы убить спасение как работу? Три. Простое ослабление ничего не исправит. В 13 году были модули модернизации ПКА, которые можно было установить, чтобы ПКА не было отстойным. Здесь? Простой нерф, ничего интересного, ничего веселого.

At station 13, the RND could improve the ore processor so much that that parody from our game rests

Я говорил об этом с Flare, и план состоит в том, чтобы убрать изменения PKA из этого PR, а затем создать отдельный PR, который одновременно нерфит PKA и вводит улучшения в SCI/Salv

While the RND is studying this, the shift will have time to end. And how do you propose to fight with such a wretched PKA?

Я говорил об этом с Flare, и план состоит в том, чтобы убрать изменения PKA из этого PR, а затем создать отдельный PR, который одновременно нерфит PKA и вводит улучшения в SCI/Salv

While the RND is studying this, the shift will have time to end. And how do you propose to fight with such a wretched PKA?

Nah, researching this won’t take long, and personally i’ll always get this for salv.

why's everyone hopping on the salv hate train

Я говорил об этом с Flare, и план состоит в том, чтобы убрать изменения PKA из этого PR, а затем создать отдельный PR, который одновременно нерфит PKA и вводит улучшения в SCI/Salv

Пока RND изучает это, сдвиг успеет закончиться. И как вы предлагаете воевать с таким убогим ПКА?

Нет, исследование этого не займет много времени, и лично я всегда найду это для Сальва.

Even if the RND is speedrun, it will be studied in about 40-60 minutes. By that time, the scraps will have time to get hold of larger guns and they will simply not ask the RND for improvements. But knowing the players on the RND, there is a high risk that they will not learn a even in 2 hours of shifting

Salv on LRP already fails to get ore the majority of rounds (entirely kneecapping sci), the recent changes trying to motivate them toward asteroids by nerfing other sources of ore are baffling combined with these changes.
100% chance this leads to Salv mining less, as every ore source has been made harder/less fruitful with no increased fun/reward.
Salv needs to be redone all at once, not these "for later content" nerfs that are just making it more painful in the meantime.

I assure you, if this proposal is accepted, most scavenger players will abandon the PKA and start using weapons purchased from the cargo request console.

I'm not sure why we are giving salv less incentive to mine and more incentive to get good weapons and go exped immediately.

I assure you, if this proposal is accepted, most scavenger players will abandon the PKA and start using weapons purchased from the cargo request console.

I'm not sure why we are giving salv less incentive to mine and more incentive to get good weapons and go exped immediately.

This would be highly inappropriate because it would turn scavengers into a nerfed version of Security 2.0. On Medium RP servers with strict rules, if scavengers request to purchase firearms for their work (due to the nerf of the protokinetic accelerator), they could receive an admin message or be denied by the Head of Security or Quartermaster.

The freakin cybersun pen does 15

The freakin cybersun pen does 15

... the traitor item?

Damage values of this PR won't even allow to break any metal structure, even when you two-hand it.
 Not to mention PKA nerf and yadda-yadda.
This PR is poorly designed for a balance tweak.
Design doc states that salvage weapons should never outDPS fireaxe (18.75) or cap sabre (25.5) [why is there such damage gap in a design doc in a first place?], but honestly, this whole salvage-cargo rework just feels like unnecessary slog to nuke progression toward 90 minute round duration.

The freakin cybersun pen does 15

His attack speed is several times less than the dagger-smasher

Crusher dagger 20 dps, can't damage structures.
Pen 15 dps, can damage structures.

Crusher dagger 20 dps, can't damage structures.
Pen 15 dps, can damage structures.

Nothing can be done

Could we hop off the Nerf Salv bandwagon for a while ? It may come as a shock to some, but salvagers DO need decent weapons in their line of work. They are the second most combat oriented role on the station, after security.

Salvage does not need huge nerfs. Also, if we nerf the weapons it becomes more common that all miners die and then you have to go through the process of hiring new ones, which will also probably end up in some deaths. Death is already nigh-permanent for a Salvager on a wreck anyway, and not having Salvagers is a giant hinderance to any station in any round. We don't need this.


fix a leak where compiled results lived too long

The original repro @levskaya showed us was essentially this OOM:
for i in range(40):
  f = jit(lambda: 1. * np.ones((300, 1024, 1024)))
  f().block_until_ready()

Even though f was being rebound on every iteration, the cache entries corresponding to the previous iterations of the loop were sticking around.
Instead, if the user drops all references to a function, we want to clear the corresponding compilation cache entries (since they can never be used).
The fix here is to use a two-level cache for compiled code: the first level is a WeakKeyDictionary keyed by the raw Python callable underlying the WrappedFun, and the second level is a regular dictionary keyed by (transforms, params, args). Because this logic is now present in  linear_util.py:cache, the implementations of WrappedFun.__eq__ and WrappedFun.__hash__ may be superfluous now.
One unintended consequence is that this implementation now avoids using fastcache.crlu_cache for the jit and pmap compilation caches. It was easier to implement this logic in pure Python. We might want to revise this for performance reasons. That means Travis might fail due to OOMs.
This change does not affect op-by-op execution; those caches use util.py:cache, which are still backed by fastcache.clru_cache. This change only affects jit and pmap caching because those are the only caches backed by linear_util.py:cache.
This commit also incidentally fixed #1600.

I also misread caches/cache on first look. Let's pick a different name for
one of them.
On Wed, Oct 30, 2019 at 8:31 PM Matthew Johnson<EMAIL_ADDRESS>wrote:

@mattjj commented on this pull request.
In jax/linear_util.py
https://github.com/google/jax/pull/1605#discussion_r340947467:

@@ -208,15 +196,16 @@ def wrap_init(f, params={}):
return WrappedFun(f, (), (), tuple(sorted(params.items())))

-def cache(call, max_size=4096):

@fastcache.clru_cache(maxsize=max_size)
def cached_fun_body(f, args):
return call(f, *args), f

def cached_fun(f, *args):
ans, f_prev = cached_fun_body(f, args)
if id(f_prev) != id(f):

 f.populate_stores(f_prev)

+def cache(call):

caches = weakref.WeakKeyDictionary()
def memoized_fun(f, *args):
cache = caches.setdefault(f.f, {})
key = (f.transforms, f.params, args)
if key in cache:

Great idea, thanks!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/google/jax/pull/1605?email_source=notifications&email_token=AAJJFVUH3XGKBROT5ARXP23QRJGPNA5CNFSM4JHA6RAKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCJ2J5GY#discussion_r340947467,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJJFVXDWEKSYNMUDDEEPXTQRJGPNANCNFSM4JHA6RAA
.

For posterity: @hawkinsp gave me the verbal LGTM, I swear.


'Connection Refused' when using DSMR template to integrate slimmelezer+

Describe the bug
I've used the template described here to integrate a Slimmelezer+ (wireless variant of the serial P1 reader)
i keep on getting a 'connection refused' error. in HA it's running fine, so my issue must be in evcc.yaml i think.
i'm using the latest version of EVCC. i've also read this thread which discusses the same issue but couldn't find an answer
I've shut down the HA integration when trying to connect from EVCC, same result. I've changed the port to the port that home assistant is talking to (6053) and then I get an IO timeout
Steps to reproduce

check if Slimmelezer+ is sending data to HA
2.add DSMR template to evcc.yaml
3.change IP number, comment out the port
4.start up evcc add-on from HA
...

Configuration details
sponsortoken: *************

network:
  # schema is the HTTP schema
  # setting to `https` does not enable https, it only changes the way URLs are generated
  schema: http
  # host is the hostname or IP address
  # if the host name contains a `.local` suffix, the name will be announced on MDNS
  # docker: MDNS announcements don't work. host must be set to the docker host's name.
  host: evcc.local
  # port is the listening port for UI and api
  # evcc will listen on all available interfaces
  port: 7070

interval: 10s # control cycle interval

# database configuration for persisting charge sessions and settings
# database:
#   type: sqlite
#   dsn: <path-to-db-file>

# sponsor token enables optional features (request at https://sponsor.evcc.io)
# sponsortoken:

# telemetry enables aggregated statistics
#
# Telemetry allows collecting usage data (grid and green energy, charge power).
# Data is aggregated, no individual charging sessions are tracked. The collected,
# anonymous data can be retrieved using https://api.evcc.io.
#
# See https://github.com/evcc-io/evcc/pull/4343 or details.
#
# For time being, this is only available to sponsors, hence data is associated with
# the sponsor token's identity.
#
# telemetry: true

# log settings
log: info
levels:
  site: debug
  lp-1: debug
  lp-2: debug
  cache: error
  db: error

meters:
  - name: slimmelezer
    type: template
    template: dsmr
    usage: grid
    host: <IP_ADDRESS> # IP-Adresse oder Hostname
#    port: 6053 # Port (Optional)

chargers:
  - name: alfeneve
    type: template # Wallbe charger
    template: alfen
    # Modbus TCP
    modbus: tcpip
    id: 1
    host: <IP_ADDRESS> # Hostname
    port: 502 # Port

site:
  title: VA35 # display name for UI
  meters:
    grid: slimmelezer # grid meter
    pv:
      - pv # list of pv inverters/ meters
  residualPower: 0 # additional household usage margin
  prioritySoc: 0 # give home battery priority up to this soc (empty to disable)
  bufferSoc: 0 # continue charging on battery above soc (0 to disable)
  bufferStartSoc: 0 # start charging on battery above soc (0 to disable)
  maxGridSupplyWhileBatteryCharging: 0 # ignore battery charging if AC consumption is above this value
  smartCostLimit: 0 # set cost limit for automatic charging in PV mode

loadpoints:
  - title: Oprit # display name for UI
    charger: alfeneve # charger
    meter: slimmelezer # charge meter
    mode: "off" # set default charge mode, use "off" to disable by default if charger is publicly available
    # vehicle: car1 # set default vehicle (disables vehicle detection)
    resetOnDisconnect: true # set defaults when vehicle disconnects
    phases: 3 # electrical connection (normal charger: default 3 for 3 phase, 1p3p charger: 0 for "auto" or 1/3 for fixed phases)
    minCurrent: 6 # minimum charge current (default 6A)
    maxCurrent: 32 # maximum charge current (default 16A)

Log details
sing config file: /config/evcc.yaml
starting evcc: 'EVCC_DATABASE_DSN=/data/evcc.db evcc --config /config/evcc.yaml'
[main  ] INFO 2023/06/20 20:48:57 evcc 0.118.1
[main  ] INFO 2023/06/20 20:48:57 using config file: /config/evcc.yaml
[main  ] INFO 2023/06/20 20:48:57 starting ui and api at :7070
[main  ] FATAL 2023/06/20 20:48:57 cannot create meter 'slimmelezer': cannot create meter 'template': cannot create meter 'dsmr': dial tcp <IP_ADDRESS>:1502: connect: connection refused
[main  ] FATAL 2023/06/20 20:48:57 will attempt restart in: 5m0s

What type of operating system are you running?
HomeAssistant Add-on
Version
0.118.1

dial tcp <IP_ADDRESS>:1502: connect: connection refused

Nothing we can do about that :/

I do not know your meter and without logfile can't say anything about the timeout.

Hi @andig ,
I might be incorrect but I don't think you need to worry about what type of meter I have exactly. you are talking to my P1 reader, Slimmelezer+. the address for the data you need is always on the same address (in this post you say which one) since it's the DSMR format. and in this post it is confirmed that the template you created works with the Slimmelezer P1 reader.
as for the logs, I changed the config again to get evcc to talk to 6053, this is the logs that I get:
Using config file: /config/evcc.yaml starting evcc: 'EVCC_DATABASE_DSN=/data/evcc.db evcc --config /config/evcc.yaml' [main  ] INFO 2023/06/20 22:24:15 evcc 0.118.1 [main  ] INFO 2023/06/20 22:24:15 using config file: /config/evcc.yaml [main  ] INFO 2023/06/20 22:24:15 starting ui and api at :7070 [main  ] FATAL 2023/06/20 22:24:33 cannot create meter 'slimmelezer': cannot create meter 'template': cannot create meter 'dsmr': i/o timeout [main  ] FATAL 2023/06/20 22:24:33 will attempt restart in: 5m0s
I'm running it as an HA add-on and because the container shuts down right after running into this error, it's hard to sh into it and run evcc in debug mode. any tips there?
thanks again
L

From the bug Formular:

NOTE if you're using HomeAssistant or Docker we ask you to reproduce the problem on plain Linux or Windows first.

So try if it works from you PC and turn debug level up.

i/o timeout

Is just that- device doesn't send data in expected time. Default is 15s, maybe try higher value?

From the bug Formular:

NOTE if you're using HomeAssistant or Docker we ask you to reproduce the problem on plain Linux or Windows first.

So try if it works from you PC and turn debug level up.

thanks for that, sorry i missed it

i/o timeout

Is just that- device doesn't send data in expected time. Default is 15s, maybe try higher value?

okay, where can i set the timeout value? it isn't mentioned here
and also, can anyone please confirm what the port is supposed to be? 1502 of 6053?

hi guys, I'm still stuck. is there anyone in here who has managed to get the slimmelezer+ to work with evcc?

Dear EVCC community, can anyone help me out here? I'm at the end of my wits and I'll I don't see any other option than abondoning this project entirely if I can get this to work

Looks like you are using a template that is no designed for this type of product.

I wouldn't say that but nobody knows why that meter doesn't answer or even which port it should answer on. Nothing we could do.

it looks like that, but this thread it says that the DSMR template was designed for Slimmelezer+
what can I do to use the date from the P1 slimmelezer+ into evcc if I can't use that template? I have the data in HA, can I publish them to mqtt and then read them again with evcc? is that the best option?

Maybe try other firmware? 🤷🏻♂
https://www.zuidwijk.com/using-esp-link/

can someone (andig?) just confirms what the DSMR template was tested on?

P1 Meter Ethernet

P1 Reader Ethernet
https://www.zuidwijk.com/product/p1-reader-ethernet/

thanks for confirming that. I have the wireless version, slimmelezer+
https://www.zuidwijk.com/product/slimmelezer-plus/
@andig should it work for that one too?

No, it's something different.

@andig can you add support for slimmelezer+ or do I need to find a different solution?

Probably if there is any api documentation.

do you mean this?
https://esphome.io/web-api/

there's also this
https://github.com/zuidwijk/dsmr/blob/main/slimmelezer.yaml

@andig do you have enough to work with? would you like to connect to my slimmelezer+ remotely to test?

Hi @andig this here seems to work, but I have 2 issues:

the current values are always positive. doesn't matter if I'm producing or consuming
I'm reading values correctly, but I'm getting a lot of IO timeouts. can I set the interval somehow? I think the slimmelezer just can't keep up. the average response time is 5 seconds.

`- name: slimmelezer
type: custom
power:
source: http
uri: http://slimmelezer.local/sensor/power_produced
method: GET
headers:
- content-type: application/json
jq: .value
scale: 1000
timeout: 15s
energy:
source: calc
add:
- source: http
uri: http://slimmelezer.local/sensor/energy_produced_tariff_1
method: GET
headers:
- content-type: application/json
jq: .value
scale: 1
timeout: 15s
- source: http
uri: http://slimmelezer.local/sensor/energy_produced_tariff_2
method: GET
headers:
- content-type: application/json
jq: .value
scale: 1
timeout: 15s
currents:

source: http
uri: http://slimmelezer.local/sensor/current_phase_1
method: GET
headers:

content-type: application/json
jq: .value
scale: 1
timeout: 15s

source: http
uri: http://slimmelezer.local/sensor/current_phase_2
method: GET
headers:

content-type: application/json
jq: .value
scale: 1
timeout: 15s

source: http
uri: http://slimmelezer.local/sensor/current_phase_3
method: GET
headers:

content-type: application/json
jq: .value
scale: 1
timeout: 15s`

the current values are always positive. doesn't matter if I'm producing or consuming

What does the api return? Is there any discriminator?

the average response time is 5 seconds.

That's horrible. Try cache: 3s to reduce the number of api requests.

the current values are always positive. doesn't matter if I'm producing or consuming

What does the api return? Is there any discriminator?

the average response time is 5 seconds.

That's horrible. Try cache: 3s to reduce the number of api requests.

I'm sorry.. what is a discriminator? here's a screenshot of the response in postman

the IO timeout is solved if I replace the mDNS name with the IP address.

another question:
there are 2 registers regarding power: power_produced and power_consumed. power_produced gives you the excess power, so power generated by the pv installation minus what the house is consuming. but the evcc code I think expects one register for both. see the screen: it takes what the pv generates and then adds the power I'm producing to get the total usage of power, where it should substract it. I think I need to take power_consumed and subtract power_produced from it to make the logic work. is that correct?


Implement tempering in leapfrog integrator

This PR

Removes some old comments
Resolves https://github.com/TuringLang/AdvancedHMC.jl/issues/52

Thanks, @xukai92. I'll take a look soon.

The code looks correct to me. Maybe we can refactor the implementation a bit, e.g. by adding some subtypes of AbstractIntegrator: JitteredLeapfrog, TemperedLeapfrog, Leapfrog. We can then overload the step function for these different Integrator types. This is helpful for readability and avoiding misuse since we can't really use the jittering trick together with tempering.

I also thought about this by I feel it's hard to achieve so without repeating many codes. I will give a try to see how it goes though.

It’s probably ok to repeat the code here, since the leapfrog function is quite short.

So the code will look something like below
####
#### Numerical methods for simulating Hamiltonian trajectory.
####

abstract type AbstractIntegrator end

struct Leapfrog{T<:AbstractFloat} <: AbstractIntegrator
    ϵ   ::  T
end
Base.show(io::IO, l::Leapfrog) = print(io, "Leapfrog(ϵ=$(round(l.ϵ; sigdigits=3)))")

function Leapfrog(ϵ::T; jitter::T=zero(T), α::T=one(T)) where {T<:AbstractFloat}
    if jitter == zero(T) && α == one(T)
        return Leapfrog(ϵ)
    elseif jitter != zero(T) && α == one(T)
        return JitteredLeapfrog(ϵ, jitter)
    elseif jitter == zero(T) && α != one(T)
        return TemperedLeapfrog(ϵ, α)
    else
        error("Leapfrog integrator with both jittering and tempering is not supported")
    end
end

function step(
    lf::Leapfrog{T},
    h::Hamiltonian,
    z::PhasePoint,
    n_steps::Int=1;
    fwd::Bool=n_steps > 0 # simulate hamiltonian backward when n_steps < 0,
) where {T<:AbstractFloat}
    ϵ = fwd ? lf.ϵ : -lf.ϵ
    n_steps = abs(n_steps)

    @unpack θ, r = z
    @unpack value, gradient = ∂H∂θ(h, θ)
    for i = 1:n_steps
        r = r - ϵ / 2 * gradient    # take a half leapfrog step for momentum variable
        ∇r = ∂H∂r(h, r)
        θ = θ + ϵ * ∇r  # take a full leapfrog step for position variable
        @unpack value, gradient = ∂H∂θ(h, θ)
        r = r - ϵ / 2 * gradient    # take a half leapfrog step for momentum variable
        # Create a new phase point by caching the logdensity and gradient
        z = phasepoint(h, θ, r; ℓπ=DualValue(value, gradient))
        !isfinite(z) && break
    end
    return z
end

struct JitteredLeapfrog{T<:AbstractFloat} <: AbstractIntegrator
    ϵ       ::  T
    jitter  ::  T
end
function Base.show(io::IO, l::JitteredLeapfrog)
    print(io, "JitteredLeapfrog(ϵ=$(round(l.ϵ; sigdigits=3)), jitter=$(round(l.jitter; sigdigits=3)))")
end

function step(
    lf::JitteredLeapfrog{T},
    h::Hamiltonian,
    z::PhasePoint,
    n_steps::Int=1;
    fwd::Bool=n_steps > 0 # simulate hamiltonian backward when n_steps < 0,
) where {T<:AbstractFloat}
    ϵ = fwd ? lf.ϵ : -lf.ϵ
    n_steps = abs(n_steps)

    # Jitter step size; ref: https://github.com/stan-dev/stan/blob/1bb054027b01326e66ec610e95ef9b2a60aa6bec/src/stan/mcmc/hmc/base_hmc.hpp#L177-L178
    !iszero(lf.jitter) && (ϵ *= (1 + lf.jitter * (2 * rand() - 1)))

    @unpack θ, r = z
    @unpack value, gradient = ∂H∂θ(h, θ)
    for i = 1:n_steps
        r = r - ϵ / 2 * gradient    # take a half leapfrog step for momentum variable
        ∇r = ∂H∂r(h, r)
        θ = θ + ϵ * ∇r  # take a full leapfrog step for position variable
        @unpack value, gradient = ∂H∂θ(h, θ)
        r = r - ϵ / 2 * gradient    # take a half leapfrog step for momentum variable
        # Create a new phase point by caching the logdensity and gradient
        z = phasepoint(h, θ, r; ℓπ=DualValue(value, gradient))
        !isfinite(z) && break
    end
    return z
end

struct TemperedLeapfrog{T<:AbstractFloat} <: AbstractIntegrator
    ϵ       ::  T
    α       ::  T
end
function Base.show(io::IO, l::TemperedLeapfrog)
    print(io, "TemperedLeapfrog(ϵ=$(round(l.ϵ; sigdigits=3)), α=$(round(l.α; sigdigits=3)))")
end

function step(
    lf::TemperedLeapfrog{T},
    h::Hamiltonian,
    z::PhasePoint,
    n_steps::Int=1;
    fwd::Bool=n_steps > 0 # simulate hamiltonian backward when n_steps < 0,
) where {T<:AbstractFloat}
    ϵ = fwd ? lf.ϵ : -lf.ϵ
    n_steps = abs(n_steps)

    @unpack θ, r = z
    @unpack value, gradient = ∂H∂θ(h, θ)
    for i = 1:n_steps
        # Tempering; `ceil` includes mid if `n_steps` is odd, e.g. `<= ceil(5 / 2)` => `<= 3`
        !isone(sqrt(lf.α)) && (r = i <= ceil(Int, n_steps / 2) ? r * sqrt(lf.α) : r / sqrt(lf.α))
        r = r - ϵ / 2 * gradient    # take a half leapfrog step for momentum variable
        ∇r = ∂H∂r(h, r)
        θ = θ + ϵ * ∇r  # take a full leapfrog step for position variable
        @unpack value, gradient = ∂H∂θ(h, θ)
        r = r - ϵ / 2 * gradient    # take a half leapfrog step for momentum variable
        # Tempering; `floor` excludes mid if `n_steps` is odd, e.g. `<= floor(5 / 2)` => `<= 2`
        !isone(sqrt(lf.α)) && (r = i <= floor(Int, n_steps / 2) ? r * sqrt(lf.α) : r / sqrt(lf.α))
        # Create a new phase point by caching the logdensity and gradient
        z = phasepoint(h, θ, r; ℓπ=DualValue(value, gradient))
        !isfinite(z) && break
    end
    return z
end

A lot of code repeating here:

Prepare stage

    ϵ = fwd ? lf.ϵ : -lf.ϵ
    n_steps = abs(n_steps)

    # Optionally jittering

    @unpack θ, r = z
    @unpack value, gradient = ∂H∂θ(h, θ)

The for loop

We cannot simply wrap the whole for loop into a function because the tempered version behaves differently.

the single leapfrog step

We can also extract the single leapfrog step out, i.e. define a function for
        r = r - ϵ / 2 * gradient    # take a half leapfrog step for momentum variable
        ∇r = ∂H∂r(h, r)
        θ = θ + ϵ * ∇r  # take a full leapfrog step for position variable
        @unpack value, gradient = ∂H∂θ(h, θ)
        r = r - ϵ / 2 * gradient    # take a half leapfrog step for momentum variable

But I feel this also reduce the readbility at this function need to return gradient to be used for the next iteration.
To be honest, I think it's less readble than the old version.
Another way to tackle this is to introduce two functions jitter and temper which might do nothing depends on their types.
```abstract type AbstractIntegrator end

struct Leapfrog{T<:AbstractFloat} <: AbstractIntegrator
    ϵ       ::  T
    jitter  ::  T
    α       ::  T
end
Base.show(io::IO, l::Leapfrog) = print(io, "Leapfrog(ϵ=$(round(l.ϵ; sigdigits=3)))")

Leapfrog(ϵ::T; jitter::T=zero(T), α::T=one(T)) where {T<:AbstractFloat} = Leapfrog{T}(ϵ, jitter, α)

function step(
    lf::Leapfrog{T},
    h::Hamiltonian,
    z::PhasePoint,
    n_steps::Int=1;
    fwd::Bool=n_steps > 0 # simulate hamiltonian backward when n_steps < 0,
) where {T<:AbstractFloat}
    @unpack θ, r = z
    ϵ = fwd ? lf.ϵ : -lf.ϵ
    sqrtα = sqrt(lf.α)
    n_steps = abs(n_steps)
    # Jitter step size; ref: https://github.com/stan-dev/stan/blob/1bb054027b01326e66ec610e95ef9b2a60aa6bec/src/stan/mcmc/hmc/base_hmc.hpp#L177-L178
    ϵ = jitter(lf, ϵ)

    @unpack value, gradient = ∂H∂θ(h, θ)
    for i = 1:n_steps
        r = temper1(lf, r, i, n_steps)
        r = r - ϵ / 2 * gradient    # take a half leapfrog step for momentum variable
        ∇r = ∂H∂r(h, r)
        θ = θ + ϵ * ∇r  # take a full leapfrog step for position variable
        @unpack value, gradient = ∂H∂θ(h, θ)
        r = r - ϵ / 2 * gradient    # take a half leapfrog step for momentum variable
        r = temper2(lf, i, n_steps)
        # Create a new phase point by caching the logdensity and gradient
        z = phasepoint(h, θ, r; ℓπ=DualValue(value, gradient))
        !isfinite(z) && break
    end
    return z
end

How do you think?

Introducing two new functions jittering and tempering sounds good. Also, you can try @generated functions - https://docs.julialang.org/en/v1/manual/metaprogramming/index.html#An-advanced-example-1.

Introducing two new functions jittering and tempering sounds good.

I will try this approach then.

Alternatively, you can try @generated functions - https://docs.julialang.org/en/v1/manual/metaprogramming/index.html#An-advanced-example-1.

I don't feel we need it here

If it's for stability, the original version doesn't meet any type stability issue.
If it's for avoid writing too many codes, I feel with @ generated the code actually becomes harder to read and harder to extend.

Hi Kai, the PR looks correct to me - I left some minor comments above.

Tests pass on my machine - the current Travis CI is failing due to weird issues with the test coverage package.


[BUG] I have given the album read/write permission on iOS 13.x and still cannot access the album

Describe the bug
When using on iOS 13.x devices, images cannot be selected.
How to reproduce
PermissionState result = await PhotoManager.requestPermissionExtend();

if (result.isAuth || (Platform.isIOS && result == PermissionState.limited)) {
    List<AssetEntity>? result = await AssetPicker.pickAssets(
      context,
    );
}

Steps to reproduce the behavior:

You need to prepare an iOS 13.4.1 device, (and users have reported problems with 13.6 devices)
Just execute the above simple code.

Expected behavior
Works fine like other iOS versions。
Screenshots (If contains)
https://user-images.githubusercontent.com/8766034/189784596-e5bf2c41-e921-47ef-9297-332f8b2fab7b.mov
Version information

Device: iPhone SE 2
OS: iOS 13.4.1
Package Version: 8.0.2
Flutter Version: 3.3.1

Additional context
Previously using version 7.3.2 it worked fine on all iOS devices. Later, because I upgraded the Flutter version, I just saw a new version of wechat_assets_picker, so I also upgraded.

Please verify if it's reproducible in the example, if yes, provide further screen records.

I just downgraded the version to 7.3.4 and re-tested it, and it works fine. Wait a minute I'll run the code in the example.

Please verify if it's reproducible in the example, if yes, provide further screen records.

I tried the code in the example and didn't reproduce my problem. It appears to be the problem with the code in my own project. Thanks for your quick response, I'll try to find out the cause of the problem myself.

https://user-images.githubusercontent.com/8766034/190042594-729b1a9c-a0b8-4abe-85f9-8ba2f8dbd5ad.mov
I tried again to reproduce the bug in the example, and I succeeded.

The name of the album selected by default by users who reported bug are different, but they have one thing in common: they are empty albums, then they can't change other albums.

+1

The real machine ios13.6.1 also has the same problem

I tried again to reproduce the bug in the example, and I succeeded.

Can you start to record from the first step, including permissions authorize.

https://user-images.githubusercontent.com/8766034/190061221-8b95253b-be03-4e10-83da-5fa7afff2285.mp4

Can you start to record from the first step? Including permissions authorize.


Sync ipaddresspool caps with upstream

Description of changes:
remove BFD due to no FRR
Remove format int32 for testing with ajv
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/approve
/lgtm

/cherry-pick release-0.12


Errors on start with many repos

I have a docusaurus config with 20+ instances of this plugin with a varying amount of documents for each.  On start it errors out.
Error
[ERROR] Error: read ECONNRESET
    at TLSWrap.onStreamRead (node:internal/stream_base_commons:217:20)

I'm using Constant Sync mode.
Sample of one of the configs:
'docusaurus-plugin-remote-content',
{
    // options here
    name: 'unique.name',
    sourceBaseUrl: 'github.enterprise.url', // some are public github urls
    outDir: 'docs/unique.name',
    documents: [
      'README.md',
      'docs/QuickStart.md',
    ], // most have one or two files and a couple have 15+ files
    modifyContent(filename, content) {
      // flattening the docs/ files and fixing some urls
    }
}

My guess is that this many connections isn't compatible with Constant Sync mode because of the number of connections.
My current work around is to use CLI Sync mode.

Uh oh, that's not good.  Didn't think this would ever be the case, as all documents are fetched at the same time, but I forgot about multiple instances of the plugin.  I'll try to add a queue system later this week.


Fix incorrect ownership of ~/.config/phoniebox

The chown command in line 61 changes the ownership of the gpio_settings.ini to the correct user. Because the script is run with sudo command root is the of ~/.config/phoniebox  which leads to an error in gpio_control.py. The altered chown command leads to the folder and the the .ini to be owned by the correct user.

Yes, tested.


local adapter: use submit instead of exec

Would it be possible for the local adapter to use submit instead of exec? This way, one could have the command:
"xenon scheduler $XENON_SCHEDULER --location local:// submit --working-directory . {threads} {mem} {walltime} {extra_args}"

and only change $XENON_SCHEDULER to select where to run it.
The local adapter also does not support the --location option. Are any plans to support it? This way it would be possible to run jobs "locally" on remote machines through (e.g.) SSH.

The local (and ssh) scheduler adaptor can not remember job states between different calls to xenon-cli. So you can not do submit and then later wait for it.
You can use the at scheduler adapter, to submit jobs locally.  The at adapter also support --location with local:// or ssh://host`.
You will need to install at on your operating system.

That seems to do the trick!
Getting an error about at adaptor: Unsupported maximum runtime: 600, but that is probably another issue.
Thanks!

It seems that the at adaptor does not support --max-run-time. To make it compatible with the other adaptors, would it be possible for the adaptor to just ignore this option (and maybe give a warning)?


Update Kubernetes version boundaries in deployment docs (#318)

This PR includes updating setup documentation to show appropriate Kubernetes versions that MLX currently supports as well as Troubleshooting section
/assign @ckadner
Related #318

Relates to issue #318

/lgtm


[Bug]: Method invocation failed because [System.Int32] does not contain a method named 'ToLower'.

Brief description of your issue
Just updated WinRAR Beta to 6.10.3 and got this error:
InvalidOperation: C:\Users\User\GitHub\winget-pkgs\Tools\YamlCreate.ps1:112
Line |
 112 |      [string]$_.ToLower()
     |      ~~~~~~~~~~~~~~~~~~~~
     | Method invocation failed because [System.Int32] does not contain a method named 'ToLower'.

This is most likely caused by WinRAR having a file extension 001 which got removed during the upgrade, i'm guessing ToLower fails when there is no letters
Steps to reproduce
Selection: 2

[Required] Enter the Package Identifier, in the following format <Publisher shortname.Application shortname>. For example: Microsoft.Excel
PackageIdentifier: RARLab.WinRAR.Beta

[Required] Enter the version. for example: 1.33.7
Version: 6.10.3

There may already be a PR for this change. Would you like to continue anyways?
RARLab.WinRAR.Beta version 6.10.3 - https://github.com/microsoft/winget-pkgs/pull/37513
  [Y] Yes
  [N] No

Enter Choice (default is 'N'): y
Found Existing Version: 6.10.2
Installer Entry #1:

        InstallerLocale: en-US
        Architecture: x64
        InstallerType: exe
        Scope: machine

[Required] Enter the download url to the installer.
Url: https://www.rarlab.com/rar/winrar-x64-610b3.exe
Installer Entry #2:

        InstallerLocale: en-US
        Architecture: x86
        InstallerType: exe
        Scope: machine

[Required] Enter the download url to the installer.
Url: https://www.rarlab.com/rar/winrar-x32-610b3.exe

Yaml file created: C:\Users\User\GitHub\winget-pkgs\manifests\r\RARLab\WinRAR\Beta\6.10.3\RARLab.WinRAR.Beta.locale.en-US.yaml
InvalidOperation: C:\Users\User\GitHub\winget-pkgs\Tools\YamlCreate.ps1:112
Line |
 112 |      [string]$_.ToLower()
     |      ~~~~~~~~~~~~~~~~~~~~
     | Method invocation failed because [System.Int32] does not contain a method named 'ToLower'.

Yaml file created: C:\Users\User\GitHub\winget-pkgs\manifests\r\RARLab\WinRAR\Beta\6.10.3\RARLab.WinRAR.Beta.installer.yaml

Yaml file created: C:\Users\User\GitHub\winget-pkgs\manifests\r\RARLab\WinRAR\Beta\6.10.3\RARLab.WinRAR.Beta.yaml
Manifest validation succeeded.

Do you want to submit your PR now?
  [Y] Yes
  [N] No

Expected behavior
No error 🤡
Actual behavior
Error 🤡
Environment
YamlCreate.ps1 version 2.0.4

Looks like it might just be a case of missing parens.
I’m not at my computer right now, but if you try
([string]$_).ToLower() I bet it will work

Yes and no, 001 turned into "1"

Yes and no, 001 turned into "1"

Interesting. What about (”$_”).ToLower(), same thing?

Yurp

Yurp

I’ll look at it more

Interesting. Seems like its some bug before it even gets to casting it as a string. Do you know which specific property its trying to cast and is failing?

I don't think this is a YamlCreate bug, I think it's a bug with the manifest. Because the yaml parser itself treats 001 as an integer, when the file is loaded into the script using powershell-yaml, it is seen as an integer there too and interpreted as 1 from the moment the file is read. In fact, VSCode even recognizes that it is an integer (note that it isn't orange like the strings) -

Because this is an inherent property of the yaml language that it should be treated as an integer, it needs to be wrapped with single quotes to be treated like a string. I don't have any way to validate it, but I would even be willing to bet that winget sees it as 1 since it isn't wrapped in the single quotes.
The proper manifest value for the extensions should be '001'

ooooooo, i was wondering why it was green instead of orange, so we'll be fixing at least 2 bugs with one stone then? 🤔

¯_(ツ)_/¯
I can't guarantee that putting it in quotes will fix anything on the client side, but it seems likely. I'd be curious to know how wingetcreate handles integers when creating/updating
Marking as resolved since this is a manifest issue.


RTC broken on SAMD51G

hey there,
i've been messing around with trying to get the RTC (and RTIC) working on a SAMD51G18A with (almost) no success. attempting to use atsamd-hal@master and<EMAIL_ADDRESS>possibly related to: #488.
i started with the setup from feather_m4/examples/sleeping_timer_rtc.rs which doesn't seem to actually kick off the RTC. looking at the datasheet the count32_mode function seems to be missing some steps, and there's a significant delta between Rtc::count32_mode and Rtc::into_count32_mode, in fact if one adds this line the RTC does start to function:
let rtc = Rtc::count32_mode(peripherals.RTC, 1024.hz(), &mut peripherals.MCLK);
let mut rtc = rtc.into_count32_mode();    // Adding this line starts the RTC ticking
rtc.enable_interrupt();

so it's possible that was just missed in a previous refactor.
from there i've been attempting to use the RTC as a Monotonic source for RTIC per feather_m0/examples/blinky_rtic.rs. one can observe that the RTC is running via increasing values from monotonics::now(), scheduling immediately (via ::spawn()) works so the dispatcher would seem to be okay, but ::spawn_after() does not. attaching a debugger i can see the first call, but can't seem to step into the scheduling to see what it thinks it's doing.

it's likely i've missed or misunderstood something, and some of this might be RTIC related, but, would definitely appreciate any advice y'all have ^_^

For both SAMD51 and SAMD21 I think one of the features of the OSCULP32K is that it is always on. At least on the SAMD51 it is only possible to mask the outputs, even though the oscillator is always on
From the datasheet for SAMD21, page 161:

I've recently encountered the exact same issue on the SAME51J20A. The RTC monotonic clock doesn't work, and similarly adding breakpoints allows it to run.
For anyone else that encounters this, one workaround is to add a delay in either set_compare or clear_compare_flag. For example:
    fn clear_compare_flag(&mut self) {
        self.mode0().intflag.write(|w| w.cmp0().set_bit());

        for i in 1..10000 {
            nop();
        }
    }

Obviously, this is far from ideal. However, with this above change, everything works fine, including going to deep sleep along with wfi.
My (uneducated) guess is that some weird synchronization issue is happening here. However, the datasheet makes no mention of needing synchronization for either intflag or comp0. I've found some places (here and here) that talk about similar issues. I've tried various things, such as calling dsb() and lsb(), without success. If anyone else has an idea what could be causing this, I would be more than happy to test.


Project restructure, python implementation and bug fixes

I took the time to work a bit on this packaging. I implemented/changed the following things:

most of the shell code was rewritten in python 3 to be easier to understand and hopefully robuster against changes (e.g. in versioning changes)
added some logging to show the build/download process. This was necessary since the around 2GB download can take a lot of time on slower networks during which nothing other than a blinking cursor in the console indicated that the program works correctly .
you can now select between the beta and stable versions using the --beta switch in the flatpack yaml configs. The latter is the default. Maybe this could be passed through to the command line so you can decide on-build if you want to use the beta version?
fixed #6
-> added resolve logo to the project together with the license notice (CC-BY-SA) as required.

this looks awesome. i haven't well tested this myself yet; but i'm going to merge this up and i'll deal with any issues once i rebuild my resolve in a few days.


Renaming process hacker exe will make the plugins not load.

Describe the bug
When renaming the process hacker exe to something else the plugins wont load.
To Reproduce
Steps to reproduce the behavior:

Rename process hacker
Run it in the same folder where the plugins are

Expected behavior
Process hacker will load the plugins while being renamed
Desktop (please complete the following information):

OS: Windows
Version: 10

Renaming binaries is only currently supported in the nightly builds:
https://processhacker.sourceforge.io/nightly.php


Revert apache#9481

This reverts commit 072bbe210f162228e85391b464f114da448df24a due to bug discovered during multi-master deployment.
See https://github.com/apache/druid/issues/9701

Not a clean revert; see: https://github.com/implydata/druid/pull/82/commits/35435f3c3bec84fcadbf2e0f4d5dcdf0af16e20d

Enough of the integration tests have now passed where this looks good to merge


Buttons outside of WindowDialog border does not allow pressing button

Operating system or device - Godot version:
v2.1.2.stable.official
Issue description:
Buttons that are outside of the WindowDialog border cannot be pressed/released.

Probably similar to this issue: https://github.com/godotengine/godot/issues/7622
Steps to reproduce:
Add a Button as a child of WindowDialog and try to press/release it (adding signals of course)

In 3.1.1, when clicking inside dialog it's ok. When clicking outside, the dialog disappears before the button is pressed (but maybe that's intended).

convenience MRP: 8295.zip
Can reproduce with 3.2.3.beta1.
@KoBeWi that's a feature you can turn off in the inspector (popup/exclusive -> enabled)

Is this relevant in 4.X/master?


Update people.json

Fixed topics for Scott Archer-Nicholls to be Wikipedia friendly

Hi!  Thanks for the update - please could you fix the conflicts?

Hi @ianhinder, is that ok now?


Corner Tiles Aren't Correct

Hi,
Thanks for making this plugin, it's quite amazing.
I noticed that inner corner tiles (e.g. L shape) with simpler tilesets (e.g. 3x3 set of tiles only) don't tile correctly. I see that this is the case in your intro video, too, with your 4x4 platformer tiles.
Is there an easy way to make corner tiles draw correctly, instead of using the center/fill tile?

With those tiles, that is the best fit. There isn't a different tile that would fit there better.
Adding in the tiles required to fill the inner corners, and expanding the peering bits to match them correctly, gives a good result:

However this tileset also has a lot of situations that aren't handled. A full tileset like this would typically have 47 tiles. Here's a template:

Of course, it's up to you if your game needs every tile.

Hi,
Thanks for the prompt response. If I understand correctly, that set of 9 outer + 4 inner tiles is sufficient?
May I recommend putting something like this in your readme? I found your plugin via assetlib, and even after watching the video, it's hard to get a simple example working.

Can you also show the terrain setup for the inner tiles please, like in my screenshot?

Thanks for the prompt response. If I understand correctly, that set of 9 outer + 4 inner tiles is sufficient? That's similar to what I needed with a different tool that I used for Godot 3.

It can only make terrain from the tiles it has. If the 9 + 4 works for your use case, then do that. It won't handle every possible way neighboring tiles can connect. For example, it can't handle these:

However, it depends on your game whether or not that is a problem. If you want to handle all possible cases, you'll need to make 47 tiles like in the template above. Every game is different, so there's not one correct answer for what the ideal tile setup is.

May I recommend putting something like this in your readme? I found your plugin via assetlib, and even after watching the video, it's hard to get a simple example working.

That's a good idea. I should work on updating the documentation with examples of different terrains.

Can you also show the terrain setup for the inner tiles please, like in my screenshot?

It's visible at the bottom of the image. The peering color is orange.

I am having a tough time getting the 47 tileset working.  My bit masking looks to match the template, but as you see my results don't work.  I am using 48x48 sized tiles.

Are you using tiles larger than the tileset tile size?

Using larger tiles is in Godot is a little odd. They might be larger graphically, but they still only take up one cell. If you want stuff to autotile well, ensure that your tiles match the tileset tile size.

My auto-tiles broke again today and the info in this thread wasn't enough to recover my work. So, attached is a sample tileset and map. I hope this will work as a reference for anyone else who stumbles on it.
Sample: sample.zip

The Space Station tileset has a wall (black with purple piping) and a floor (blue tiles)
Always draw walls as 2x2 thickness or greater, or it looks wrong (due to the use of minimal tiles)
The floor is a single 1x1 tile. You can wedge it within walls in whatever shapes you want.


Fix overflow issue on login screen

@techievivek Please review
cc @aimane-chnaif
Details
I don't believe we need this conditional here as the SignIn page content will always be narrow.
Fixed Issues
$ https://github.com/Expensify/App/issues/10419
Tests

Go to the sign in page of new Expensify
Enter your login details but not your password (use long login name)
Press Forgot? on the password page

@yuwenmemon Your solution LGTM! https://github.com/Expensify/App/pull/10425/files#diff-dd48053a4b4ca8a948af29c248e8fee97c8d962017338228d8bec523842df230R52
Another solution:
The issue was similar to this: https://stackoverflow.com/questions/35491851/alignitems-center-prevents-flex-row-text-wrapping-in-react-native
So we can also fix this by updating this line:
https://github.com/Expensify/App/blob/78bb1d5f9239e23ef1b6c21a0223e355c0155b1b/src/pages/signin/SignInPageLayout/SignInPageContent.js#L45
To:
            props.isSmallScreenWidth && styles.alignItemsCenter,

This fixes both issues: https://github.com/Expensify/App/issues/9817, https://github.com/Expensify/App/issues/10419
I think either solution is fine

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by @techievivek in version: 1.1.89-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Unify capitalization of plugin names / provide guidelines for plugin naming

🚀 Feature

Some start with lowercase some other do not, and plugins should provide a display language so that capitalization rules will change for different languages (if they apply)
Motivation
Provide a consiste UI
Pitch
The mix of lowercase and uppercase on plugin/hooks names makes the UI inconsistent.
Also it would be great to provide naming guideling for users and developers.

Pinging @liaprins-czi

The mix of lowercase and uppercase on plugin/hooks names makes the UI inconsistent.
Also it would be great to provide naming guideling for users and developers.

Yes I think we will be doing this as part of the hub's effort to have better plugin names shown. (@neuromusic for reference)
@goanpeca Do verify, are you referring to the actual name of the plugin, or to commands that the plugin includes and that subsequently appear in menubar when using it? (or both?)

Do verify, are you referring to the actual name of the plugin, or to commands that the plugin includes and that subsequently appear in menubar when using it? (or both?)

I meant the name of the plugin that will appear on the plugins menu, if they provide a dockwidget hookspec.

Okay great!

Hi all,
great to see this discussion here! I just renamed some of my plugins so that their name highlights more "What" the plugin is doing. I would recommend that to all plugin developers in general. We could than mid/long term have a menu that contains

Filtering
Segmentation
Mesurements

Instead of technical terms such as

clEsperanto
StarDist
Regionprops

From a users perspective, that might be very welcome.
Furthermore, I would like to add a technical aspect: Menu order in the plugins menu. Would it be possible to sort it alphabetically? At the moment it appears a bit random and a bit counter-alphabetically.

Cheers,
Robert

oof @haesleinhuepf 😝 this bit right here is definitely not what was intended by the entry_point mechanism.  I'd point you to #3035 for most of the conversation on this topic (I even proposed recently that we drop support for multiple entry_points per package).  An entry point is just that: a place for napari to "enter" your package to look for things.  It was never intended as a menu structure mechanism.
I recognize that we don't yet have an infrastructure that supports complex menu nesting... and I know you're itching to start exposing features... so I feel like the best we can probably suggest at this point is for you to create your own single QMenu that is dropped into the plugins menu.  (this too isn't "supported", and will likely break eventually... but we're just not "there" yet)

please don't? 😂

Well, the headline of this issue is "provide guidelines for plugin naming". And I think plugins should have meaningful names such as "AlgorithmX-Segmentation" or "Measurement: MethodY". Not sure why you oppose here.
At the moment, users have a hard time because the menu is full of "abcde-napari: abcde", "ThingStar" and "CellPlugin". In many cases it's not obvious from the menu entry name what the plugin does. That's why I also attempted to rename the entries of "clEsperanto" as it also doesn't tell much about what it's doing. I'm just trying to make it easier for users.

And I think plugins should have meaningful names such as "AlgorithmX-Segmentation" or "Measurement: MethodY". Not sure why you oppose here.

I oppose because Measurement: MethodY is not a plugin ... it's a command.  And while I get that "provide guidelines for plugin naming" is in the title of this post...  I think we mean more along the lines of https://github.com/napari/napari/issues/3035, (where the general desire was to go the other direction with entry points).

At the moment, users have a hard time because the menu is full of "abcde-napari: abcde", "ThingStar" and "CellPlugin". In many cases it's not obvious from the menu entry name what the plugin does.

Again, we completely and whole-heartedly agree here.  But the solution isn't to try to figure out what we can do with the system as is (for instance, by adding a lot of entry points in a single package), but rather to step back for a moment and decide what the "best" way to do this is, and make that a reality.  I know you're trying to make it more accessible for users... but you have to also recognize that plugins will just start mimicking other plugins.  and users will be ever more confused when the whole question of "what is a plugin in napari anyway?  is it a package?  is it a menu item"
We're routinely having conversations about how to expose menu items in a nestable and organized way.  Specifically with your sort of use case in mind... So, when I said "please don't", I meant please don't encourage people to make a handful of plugins in a single package, each with names like "1: segmentation", etc...  Really, that should be a single plugin, and we ask everyone to be patient while we build a more stable foundation for inner-plugin organization

I mentioned this in the image.sc thread, but coming from a neophyte PoV, I strongly feel the Plugins menu should remain sane and well organized, 1 item per plugin. What would be nice though is to be able to activate more robust plugins to enable have their own dedicated menu. Then it would be easy to access those features and know clearly what plugin they belong to. I prefer a menu to a panel in napari because of limited screen real estate and neigh unlimited menu bar space.

I strongly feel the Plugins menu should remain sane and well organized, 1 item per plugin.  What would be nice though is to be able to activate more robust plugins to enable have their own dedicated menu.

This is absolutely the goal.  work actively in progress.  We'll be putting out some more public proposals in the not too distant future.

Do verify, are you referring to the actual name of the plugin, or to commands that the plugin includes and that subsequently appear in menubar when using it? (or both?)

I meant the name of the plugin that will appear on the plugins menu, if they provide a dockwidget hookspec.

@neuromusic Is this something that is within the scope of the upcoming hub work for "Simplified plugin names"?

@liaprins-czi yes, I think so. in a convo w/ the Plugin Working Group (@nclack @tlambert03 & @Carreau), it was proposed that this would be a unicode field in the to-be-developed manifest file... then, either the napari hub or viewer could render it in the appropriate places


Goals For Classroom Mode

Hello,
I've spent some time today working on this which is awesome.
Reviewing: https://projects.invisionapp.com/share/J3C03W2SX#/screens/237080318 I can see maybe there is a integration with FreeCodeCamp and if I wanted to mentor 10 students I could become a teacher and do code reviews?

Hello @imcodingideas, thank you for your work and great question.
This project is intended to provide a visual presentation for teacher to keep track of their students' progress FreeCodeCamp. We noticed there are teachers assigning FreeCodeCamp coding exercise to their students but there isn't an easy way to keep track of students' progress.
@utsab and @udfood did some interviews and found out teachers would like to view data like student's day inactive data and student trial and error data to determine if students need help with a particular concept.
At this point we are trying to finish and refine the class table and get teacher feedback before moving forward with the potential FreeCodeCamp integration.

Awesome, something like this needs to be in the readme. I will continue today.


HAWQ-1208. Porting gpdb interconnect fix to hawq.

cc @liming01 @wengyanqing @huor

Given there are multiple fix in each of commit, it is better to merge Ming's port and your fix that span in several commit into single commit. The commit message need to contain all port and fix as well. Any better option from your mind?

It is better to keep them separate commit, so that we can easy tracing the problem. If you think they are too many commit, you can using merge instead of rebase.
+1.

+1

Merged to master.


Define and expose a results API interface for programmatic usage

Currently, results are returned in 2 forms:

The CLI stdout, as a fixed summary message
The full tree of FullyAnalyzedEntitys

Although the full tree can be used programmatically, it could be helpful to add a public API interface around this, so users can easily access some of the headlines from the output.

Relates to #38

Affects #39 - need this API added in order to easily get e.g. average complexity, most complex scores from a result
This API could also include a generateBadge() method that creates a badge .svg locally to the analyzed project, as per this suggestion
Actions to take

Design a new results interface that is in turn exposed by codehawk-cli. It could be used via CLI or programmatically. We want: access to summary information about the results (such as average complexity score (+median?), worst complexity score), generateBadge()
Consider providing new CLI options/commands to trigger actions that aren't the main processing (e.g. generate badge), this avoids the consuming project needing to script the same thing
Investigate a OpenMetrics reporter so that users can track complexity over time


Virtual field shows wrong value when a related column is hidden

Hello, am having some issues hiding a column that I use to calculate a virtual field. In summary if I hide the field then the virtual field shows a wrong value. This is the situation:
I have a resource named Zoo that have many Animals, currently in the index view I can see all the animals that belongs to that Zoo. Now, I don't want to show the list and instead only show the number of animals, in order to do so I created a virtual field as next:
myZoo := admin_app.AddResource(&Zoo{}, &admin.Config{Menu: []string{"Zoos"}})
myZoo.Meta(&admin.Meta{
		Name: "AnimalsCount",
		Type:"text",
		Valuer: func(record interface{}, context *qor.Context) interface{} {
			z := record.(*Zoo)
			return strconv.Itoa(len(z.Animals))
		},
		Setter: func(record interface{}, metaValue *resource.MetaValue, context *qor.Context) {
		},
		FormattedValuer: func(record interface{}, context *qor.Context) (result interface{}) {
			z := record.(*Zoo)
			return strconv.Itoa(len(z.Animals))
		},
})
myZoo.IndexAttrs(myZoo.IndexAttrs(),"AnimalsCount")

At this point everything goes well and the count displayed is correct. Now, when I hide the Animals column the count goes everytime to zero:
myZoo.ShowAttrs("-Animals")
Is there any workaround to this issue?

hi @sredxny
I don't have time to look into this issue right now. but a possible workaround would be
myZoo.Meta(&admin.Meta{Name: "Animals", Permission: roles.Deny(roles.Read, roles.Anyone)})

Hi, thanks for your answer.
Just for the records, the suggested workaround didn't work either.


CI is failing on master

cc: @chriselrod

Ah, I skipped a version with Gaius, so the release adding support never happened.


non utf 8 letters in StringData saving

when saving into the DB the string, need to exclude Korean letters so other people wont have this error -

not reproducing on local fresh env, i'm closing for now if i will see it reoccuring i will reopen the bug


[UI] Designs: Rearrange buttons on cards in grid view

Description
In the Designs page in Meshery UI, there are two changes desired. See screenshots.
Mockups
First Change:

Second Change:

Contributor Guides and Resources

🎨 Wireframes and designs for Meshery UI in Figma
🖥 Contributing to Meshery UI
🙋🏾🙋🏼 Questions: Layer5 Discussion Forum and Layer5 Community Slack

Can I work on it? @leecalcote

That’d be great, @subhamgcon. If you run into trouble or have questions: https://discuss.layer5.io.

@subhamgcon checking in... how's it coming along?

Let's get this timely item reassigned and @subhamgcon onto another item. Just signal when ready @subhamgcon.

Hi @leecalcote, thank you for giving me a chance to solve this issue. Actually I couldn't figure it out but I got a lot of help from the layer5 slack community and i would like to start off with a documentation issue if possible. Thanks again

@subhamgcon, no sweat at all. Some items are more timely than others. There's plenty more where this comes from. Great job on reaching out to the rest of the community for assistance. I encourage you to use discuss.layer5.io for both the benefit of others who come after you and so that your inquiries don't get lost in the noise.
Take your pick: https://github.com/issues?q=is%3Aopen+is%3Aissue+archived%3Afalse+org%3Alayer5io+org%3Ameshery+org%3Aservice-mesh-performance+org%3Aservice-mesh-patterns+label%3A"help+wanted"+
If you see one that's interesting, but someone else is assigned to it, then look to see how much time is transpired between when they were signed in now. Don't hesitate to comment on the issue and ask if they are actively working on it or if you can help.


Android: Keyboard modifier and arrow key support for text edit

Needed for https://github.com/godotengine/godot/pull/36776, also I think it's a welconiing change anyway
thinking changing InputEventScreenTouch and InputEventScreenDrag to inherit from InputEventWithModifiers instead so they could also get benefits from this PR
(if someone have better option for what I did on onKeyDown in GodotEditText I  would be glad to hear)
Tested on Android Editor and https://github.com/thebestnom/Android-Tester

Also I just saw that EditText didn't handle keyUp event, so I'm adding that

also tested with virtual keyboard and it doesn't seem to interfere

thinking changing InputEventScreenTouch and InputEventScreenDrag to inherit from InputEventWithModifiers instead so they could also get benefits from this PR

asking again, any comment on this?

thinking changing InputEventScreenTouch and InputEventScreenDrag to inherit from InputEventWithModifiers instead so they could also get benefits from this PR

It would be probably ok to change if needed, but is there an actual use case for an editor or game feature that could benefit from it? Pressing keyboard keys along with touch events doesn't seem user-friendly.

It would be probably ok to change if needed, but is there an actual use case for an editor or game feature that could benefit from it? Pressing keyboard keys along with touch events doesn't seem user-friendly.

I'm comming from the point of view of Android Editor where there it's pretty handy, but for other pojects most I can think of is testing your game on device/playing on chromeOS/playing on tablet without special touch control and in those cases a lot of time you can use drag or touch with one hand

I'm comming from the point of view of Android Editor where there it's pretty handy, but for other pojects most I can think of is testing your game on device/playing on chromeOS/playing on tablet without special touch control and in those cases a lot of time you can use drag or touch with one hand

I understand it's physically possible in some cases but I would be for adding support for it only when there's a specific use case scenario that requires it.

Needs a rebase to fix CI builds (at least Linux - not sure why macOS fail but a new build will likely let it pass).

@akien-mga rebased :)

Thanks!


HTTP-76 Allow enforcing the use of raw Authorization header

Description
Introduce configuration parameter allowing to use the Authorization header without b64 and prefixing for Basic Authentication.
Context:
As documented, the connector currently processes the value set for the Authorization header as follows: it encodes it to Base64 and it prefixes it with "Basic ". The only case when this is not done is if the value is already prefixed with "Basic ".
This is convenient for Basic Authentication, as it allows writing
'gid.connector.http.source.lookup.header.Authorization' = 'username:password'

without taking care of b64 and prefixing.
However, there is currently no way to enforce the use of the raw value of the Authorization header. This is necessary for use-cases where the called API needs the header to be set for other purposes than Basic Authentication, such as API key authentication.
Testing status:

The maven build succeeds locally (including unit tests and coverage).
Further manual testing ongoing.

Resolves #76
PR Checklist

[x] Tests added
[x] Changelog updated

the build failed on adding jacoco report to PR. This is caused by fact that this PR comes from Forked repo.
We would need to take a look at some point.

@kristoffSC Thanks a lot for the quick feedback!

the build failed on adding jacoco report to PR. This is caused by fact that this PR comes from Forked repo.
We would need to take a look at some point.

Just tell if I can do something about it. I don't have permissions to push the branch to the repo.

No, its all good. This was just a general info.
Seems that this is some repo setup issue not related with your pr.
I will leave the pr open for some time, maybe some one else will comment and I will merge it.


chore(deps): upgrade dependencies

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-1.x" workflow

⚪ Backport skipped
The pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually.
Manual backport
To create the backport manually run:
backport --pr 513

Questions ?
Please refer to the Backport tool documentation


'zabbix_short_version' is undefined

Hi!, I've downloaded the last release. Here is my playbook
- name: setup zabbix agent
  hosts: "{{ targets | default('zabbix-monitored') }}"
  remote_user: centos
  become: True
  gather_facts: True

  roles:
    - role: ansible-zabbix-agent
      zabbix_agent_server: zbx-it.domain.com
      zabbix_agent_serveractive: zbx-it.domain.com
      zabbix_version: 3.4
      zabbix_repo: epel
      zabbix_agent_tlspsk_secret: secret
      zabbix_host_groups:
         - Linux Servers
      zabbix_link_templates:
         - Template OS Linux

And my error
TASK [ansible-zabbix-agent : RedHat | Use EPEL package name] **********************************************************************************************************************************
fatal: [test-mysql-1]: FAILED! => {"failed": true, "msg": "The task includes an option with an undefined variable. The error was: 'zabbix_short_version' is undefined\n\nThe error appears to have been in '/home/nico/Documents/ansible_community_roles/ansible-zabbix-agent/tasks/RedHat.yml': line 4, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- name: \"RedHat | Use EPEL package name\"\n  ^ here\n\nexception type: <class 'ansible.errors.AnsibleUndefinedVariable'>\nexception: 'zabbix_short_version' is undefined"}

Did I miss something?

I've set the variable (which seems not documented) with "22". The playbook go now through this error but I get a new one.
TASK [ansible-zabbix-agent : RedHat | Installing zabbix-agent] ********************************************************************************************************************************
failed: [test-mysql-1] (item=zabbix-agent) => {"changed": false, "failed": true, "item": "zabbix-agent", "msg": "No package matching 'zabbix-agent' found available, installed or updated", "rc": 126, "results": ["No package matching 'zabbix-agent' found available, installed or updated"]}
failed: [test-mysql-1] (item=zabbix-sender) => {"changed": false, "failed": true, "item": "zabbix-sender", "msg": "No package matching 'zabbix-sender' found available, installed or updated", "rc": 126, "results": ["No package matching 'zabbix-sender' found available, installed or updated"]}
failed: [test-mysql-1] (item=zabbix-get) => {"changed": false, "failed": true, "item": "zabbix-get", "msg": "No package matching 'zabbix-get' found available, installed or updated", "rc": 126, "results": ["No package matching 'zabbix-get' found available, installed or updated"]}

But also the epel-packages are not installed, as it seems that it is always using the packages configured in the property zabbix_agent_packages.

I pushed some changes to Github, therefor I close this issue.


Received failed HTTP shipping result RequestEntityTooLarge: Maximum raw payload content length of 1048576 bytes exceeded

The following error is repeated every few seconds in my Serilog debug output file:
2016-02-01T10:14:27 Received failed HTTP shipping result RequestEntityTooLarge: Maximum raw payload content length of 1048576 bytes exceeded
No logs are sent to Seq while in this error condition.
Here's my app.config:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<appSettings>
  <add key="serilog:using:Seq" value="Serilog.Sinks.Seq" />
  <add key="serilog:write-to:Seq.serverUrl" value="http://ngen-spoc-01:5341" />
  <add key="serilog:write-to:Seq.bufferBaseFilename" value="%LOCALAPPDATA%\FLOWCAL\flowcal"/>
</appSettings>
</configuration>

Here are the files from %LOCALAPPDATA%\FLOWCAL
large-local-buffer.zip
This error is just on my dev box.  We don't have anything out in production yet, but we are trying hard to get there.  I can locally just delete the buffer files and move on, but I'm more so worried about getting this where it just works when we get it into production.  Thanks!

Hi Ben, thanks for the report.
Seq 2 sets this limit at 1 MB, which as you've found is often too small; if you go to Settings > System you can increase the Raw payload limit bytes setting. Seq 3 sets the default to 10 MB which should be much more adequate here.
Further, Serilog.Sinks.Seq version 2, in dev currently, adds a new eventPayloadLimitBytes parameter that is a per-event limit. Events above this threshold are dropped so that connectivity is not compromised. When it's available, setting this close to max payload / batch size will help here. It may be worth backporting to v1 - what's your timeframe?

Hi Nick.
Thanks for the explanation!  Glad you already have it worked out.  Our first release with Seq is planned for early April.  As long as there's a Serilog.Sinks.Seq v2 release sometime in March we should have time to integrate it in and we won't need to backport.
I noticed that it seems like the Seq setting "Raw event payload limit" is limiting the entire batch of events sent by HttpLogShipper, but the eventPayloadLimitBytes value is limiting individual event size.  Are there plans to chunk the batches in HttpLogShipper to fit into "Raw event payload limit"?
Example scenario would be if I'm offline for a few hours and 12MB of 1KB events are logged.  When I get back online and HttpLogShipper starts shipping that 12MB batch of small messages, what happens?  Likely if you generated 12,000 events, you really wouldn't want them all shipped anyway.  I just don't want it to get stuck and need intervention.  Feel free to correct me where I am wrong.  Thanks!

Thanks for the follow-up. When the app's been offline, the batchPostingLimit should keep size under control.
(Chunking the batch sounds like a worthwhile avenue to explore, will consider this further.)

Yes.  That should do it.  I hadn't seen batchPostingLimit before.  Thanks for pointing it out and thanks for the quick response!


What will happen is I not use IFormFile and also not disable FormValueProviderFactory?

Files uploaded using the IFormFile technique are buffered in memory or on disk on the web server before being processed.

what cause it ? Model binding  or any related to IFormFile like the Requst.Form.Files  ?  and why remove FormValueProviderFactory and JQueryFormValueProviderFactory make a difference?
and may be not related to this page, but I think the Stream upload code is too complex, and we can create a new public  class to make this step simple.
public class MultipartRequestHandle
{
    public MultipartRequestHandle(Func<IFileContentDisposition,Stream,Task> fileContenthandle){};
    public ValueTask<IFormCollection> HandleAsync(){} // this will return the FormCollection ,but the FormCollection.File.Body will be null,
}

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

ID: 9a5cfa38-0e6c-4346-dafc-84ea5c513fcf
Version Independent ID: c6787f0f-3e9a-6efb-0e6e-5ccb957d3f4a
Content: File uploads in ASP.NET Core
Content Source: aspnetcore/mvc/models/file-uploads.md
Product: aspnet-core
Technology: aspnetcore-mvc
GitHub Login: @ardalis
Microsoft Alias: riande

Hello @John0King ... AFAICT, that's actually just the way the framework handles requests. It seems to be the case for any request, but you'd need to research it more ... perhaps consult with engineers who know that code base much better than I.
https://github.com/aspnet/AspNetCore/blob/093df67c06297c20edb422fe6d3a555008e152a9/src/Http/WebUtilities/src/FileBufferingReadStream.cs
... so (if that's correct) I doubt that FormValueProviderFactory/JQueryFormValueProviderFactory affects the scenario.

Stream upload code is too complex

You'd have to take that up with engineering.
Note that we have a big update going in on https://github.com/aspnet/AspNetCore.Docs/pull/12344. It's in review now.

@John0King See remark at :point_right: https://github.com/aspnet/AspNetCore.Docs/pull/12344#issuecomment-495290221

@guardrex Ok