CheckBox & RadioButton labels become off-center when text scaling >= ~150%.

Describe the bug
The built-in text labels for both the CheckBox and RadioButton controls gradually gets more and more off center as the system's text scaling % increases.
Steps to reproduce the bug

Set text scaling to 150% or higher
Open the XAML Controls Gallery
View any of the CheckBox or RadioButton controls

Expected behavior
The text labels should remain aligned.
Screenshots

Version Info
XAML Controls Gallery version <IP_ADDRESS>

Windows 10 version
Saw the problem?

Insider Build (xxxxx)

May 2019 Update (18362)
Yes

October 2018 Update (17763)

April 2018 Update (17134)

Fall Creators Update (16299)

Creators Update (15063)

Device form factor
Saw the problem?

Desktop
Yes/No?

Mobile

Xbox

Surface Hub

IoT

Additional context

Agree, we should try to make the layout handle the text getting bigger in a more reasonable fashion. We've had this problem across many controls so whoever picks this up don't feel limited to just fixing these two. :)

Is there a vertical center option in WinUI?
I feel something of the sort would fix stuff like this.

I couldn't replicate the scaling being off, but I changed some values within the project so that there is not any weird rounding

Is there a vertical center option in WinUI?

Yup! (VerticalAlignment) Agree it should be easy-ish to fix.

updated the ones that were shown in the image, pending PR, will go through and check for more

Okay, I've fixed all of them in the solution

@jevansaks @salmanmkc
This is a general issue with the CheckBox and RadioButton controls, rather than their specific usage in the XAML Controls Gallery.
As as with most issues, I just noticed that the problem is more complicated that I originally thought. Refer to checkbox usage in the Settings app:

Alignment for single-line labels is straightforward. However, for multi-line labels the 'best case' involves alignment with just the first line of text, as opposed to the entire text block.
Hello rabbit hole...

First line vertical center probably would be the best solution. Unless there is a way to measure how much the space is taken up by the text and centered off of that.

updated the ones that were shown in the image, pending PR, will go through and check for more

Very cool! Should I assign this issue to you, then? And did you submit a PR yet? I didn't see one come through.

updated the ones that were shown in the image, pending PR, will go through and check for more

Very cool! Should I assign this issue to you @salmanmkc, then? And did you submit a PR yet? I didn't see one come through.

I already submitted a PR for it in XAML-Controls-Gallery, although my PRs are very messy at the moment, watching some videos to improve

I already submitted a PR for it in XAML-Controls-Gallery

I see. I was expecting a PR to this repo since I expect the fixes to be in the platform control styles.

Similar to HorizontalContentAlignment/VerticalContentAlignment on other controls, it seems a new property is needed here to cover all cases including multi-line checkbox content. Something like Vertical<Check?>Alignment, etc.
This would mean it's up to the developer and their specific UI design to fix this. Otherwise, the control would have to make some difficult (and likely not general-purpose) calculations itself about it's overall text height and if the text it multi-line. That would then allow the control to decide if VerticalAlignment.Center or VerticalAlignment.Top with a margin should be used.

I would like to try to fix this issue :)

As @kmgallahan and @shaheedmalik already pointed out this is quite a difficult issue.
Supporting multi line text is really difficult, since we don't know if the text is multiline or not. For larger font sizes, the checkbox needs to center, for smaller font sizes, the text needs to center. This however is problematic with multiline text.
For text that is single line, finding a solution is quite easy, since we can simply center everything. However with multiline text, centering the checkbox may look weird:

Since CheckBox currently is a winrt component (AFAIK), adding new properties is not an option. However, according to the docs, a checkbox should not have more than two lines of text, which would look okayish:

The same problem also applies to RadioButtons, however we could introduce a custom property in this case.

@chingucoding
According to the CheckBox_themeresources.xaml, the label and checkbox are contained in columns of a Grid ("RootGrid").
If the checkbox here had a new outer container, then that container could have:

VerticalAlignment="Center"
Logic to set its Height equal to the label's LineHeight property

The Height = LineHeight logic would need to either use a binding or listen for TextScaleFactorChanged  events to stay in sync.
I'm not completely sure what the product of this would look like as the center of the LineHeight doesn't necessarily have to be the center of the text (see TextLineBounds, but it would probably produce a decent result.

While this is a very good idea, unfortunately, this (currently) does not work for two reasons:

The actual logic behind the control is currently not open source. This means we can not subscribe to events or do any calculations.
While testing your idea, I found out that, the LineHeight of both the TextBlock and the ContentPresenter are not the values you would exspect. The TextBlock has LineHeight=Auto and the ContentPresenter which renders the TextBlock has LineHeight=0, which are both not achieving the effect we need in this case.

What we could do, is introduce a new ThemeResource which defines the VerticalAlignment of the tickbox/radioindicator with default value set to "Center". If someone has text with multiple lines, they can choose to override it and deal with it the way that works best for them, while the default behavior works fine with text scaling.

The actual logic behind the control is currently not open source.

Is that going to change with WinUI 3 release? If yes and that is the main roadblock to a proper solution, then this issue could just be marked 'Needs WinUI 3' for now.

The TextBlock has LineHeight=Auto

The property is supposed to be a double - I guess 'Auto' interferes with getting the actual number?

If someone has text with multiple lines, they can choose to override it and deal with it the way that works best for them

Requiring a reskin isn't particularly optimal, especially considering display scaling, text scaling, and dynamic window/control sizing can all result in labels getting unexpectedly wrapped.

@jevansaks , @chigy : Any idea what would be the best solution for this? Should the radiobutton/checkbox center itself among multiple lines? Or would it better to center it with respect to the first line of text?

Being able to get a 'most likely' line height value as mentioned in these issues could help:

https://github.com/microsoft/microsoft-ui-xaml/issues/1255
https://github.com/microsoft/microsoft-ui-xaml/issues/1226

@chingucoding , the ideal design is to center it on the first line of text. This is a bit old comp but here's how it may look.

@chingucoding , the ideal design is to center it on the first line of text. This is a bit old comp but here's how it may look.

Okay, thank you for the clarification.
The next question is what would be a suitable solution to this. Is it acceptable to do calculations in the code behind for this issue? Would this even be a reliable way to deal with this?
If we need background calculations, this is only something we can completely fix with WinUI 3.0 :/

Seems like there needs to be a baseline alignment option, where you can have an object align to the text baseline of a Text Block/Box, with offsets if necessary.

Unassigning myself as this is something we should look at when we have WinUI 3 and we can actually fix this.

Does this happen with the ToggleSwitch too? I noticed the text seemed a bit low there too:

@michael-hawker , I expect the same issue to happen when the text has to be aligned with some other UI element.

@StephenLPeters I think the "good first issue" label is a bit missleading as this most likely requires WinUI 3 and probably deeper layout changes to center the labels with the first line of text.

I get this issue with Fluent UI for React (the website thing) 😩

Keep alive


fly execute has weird output when loading inputs

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 30720    0 30720    0     0  95544      0 --:--:-- --:--:-- --:--:-- 98146
100 6380k    0 6380k    0     0  1070k      0 --:--:--  0:00:05 --:--:--  706k
100 81920    0 81920    0     0  13426      0 --:--:--  0:00:06 --:--:-- 21059

Curl is really weird looking when uploading multiple inputs for fly execute

yea that'll be a tricky one to fix i think. barring ncurses. which no one wants or should want.
maybe i'll experiment with it

Moved to concourse/concourse#1079


Localized file check-in by OneLocBuild Task: Build definition ID 21368: Build ID 112863563

This is the pull request automatically created by the OneLocBuild task in the build process to check-in localized files generated based upon translation source files (.lcl files) handed-back from the downstream localization pipeline. If there are issues in translations, visit https://aka.ms/icxLocBug and log bugs for fixes. The OneLocBuild wiki is https://aka.ms/onelocbuild and the localization process in general is documented at https://aka.ms/AllAboutLoc.

closing as this is superseded by merged PR https://github.com/microsoft/responsible-ai-toolbox/pull/2460


--data-path-port parameter ignored while executing docker swarm init --force-new-cluster from backup

I've made a backup of docker swarm in version 18.09, on RHEL7 machines. I upgraded docker on each node and restored swarm from backup executing docker swarm init --force-new-cluster --data-path-port 5789 . But apparently --data-path-port hasn't been applied and it's still using 4789. I need to change it because of reasons mentioned in issue.
I expect docker to apply my changes or at least warn that they are ignored.
I tried also to amend /var/lib/docker/swarm/docker-state.json content before restoration, but it hasn't helped either.
I reproduced problem also on local VM-s setup.
$ docker info
Client:
 Debug Mode: false

Server:
 Containers: 131
  Running: 35
  Paused: 0
  Stopped: 96
 Images: 221
 Server Version: 19.03.4
 Storage Driver: devicemapper
  Pool Name: datavg-dockervol
  Pool Blocksize: 65.54kB
  Base Device Size: 21.47GB
  Backing Filesystem: xfs
  Udev Sync Supported: true
  Data Space Used: 30.25GB
  Data Space Total: 107.4GB
  Data Space Available: 77.12GB
  Metadata Space Used: 51.78MB
  Metadata Space Total: 536.9MB
  Metadata Space Available: 485.1MB
  Thin Pool Minimum Free Space: 10.74GB
  Deferred Removal Enabled: true
  Deferred Deletion Enabled: true
  Deferred Deleted Device Count: 0
  Library Version: 1.02.158-RHEL7 (2019-05-13)
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: active
  NodeID: q00hc0xkgzhfgnqb1v8w5uj4g
  Is Manager: true
  ClusterID: l4abckeb2fpe1tt9jqevrh5e0
  Managers: 3
  Nodes: 8
  Default Address Pool: <IP_ADDRESS>/8
  SubnetSize: 24
  Data Path Port: 4789
  Orchestration:
   Task History Retention Limit: 5
  Raft:
   Snapshot Interval: 10000
   Number of Old Snapshots to Retain: 0
   Heartbeat Tick: 1
   Election Tick: 3
  Dispatcher:
   Heartbeat Period: 5 seconds
  CA Configuration:
   Expiry Duration: 3 months
   Force Rotate: 0
  Autolock Managers: false
  Root Rotation In Progress: false
  Node Address: <IP_ADDRESS>
  Manager Addresses:
   <IP_ADDRESS>:2377
   <IP_ADDRESS>:2377
   <IP_ADDRESS>:2377
 Runtimes: runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 894b81a4b802e4eb2a91d1ce216b8817763c29fb
 runc version: 425e105d5a03fabd737a126ad93d62a9eeede87f
 init version: fec3683
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 3.10.0-957.12.1.el7.x86_64
 Operating System: Red Hat Enterprise Linux Server 7.7 (Maipo)
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 62.76GiB
 Name: ***
 ID: I5NS:YHAX:CDMZ:T3NF:CKUC:4236:QYU6:IIEN:TRHF:J343:LC2F:FV6T
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
  env=***
  node=***
  name=***
 Experimental: false
 Insecure Registries:
  <IP_ADDRESS>/8
 Live Restore Enabled: false

$ docker version
Client: Docker Engine - Community
 Version:           19.03.4
 API version:       1.40
 Go version:        go1.12.10
 Git commit:        9013bf583a
 Built:             Fri Oct 18 15:52:22 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.4
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.10
  Git commit:       9013bf583a
  Built:            Fri Oct 18 15:50:54 2019
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.2.6
  GitCommit:        894b81a4b802e4eb2a91d1ce216b8817763c29fb
 runc:
  Version:          1.0.0-rc8
  GitCommit:        425e105d5a03fabd737a126ad93d62a9eeede87f
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

Can anybody suggest at least some workaround?

Late but still relevant. I am facing the same problem, not only with data-path-port but also with advertise-addr and they seem to share the same problems : https://github.com/docker/for-linux/issues/523
Some people suggest to basically recreate the swarm, which is really time-consuming depending on what you have in there. Maybe there is a way to modify the RAFT consensus data of a backup but I'm not aware of.


Independent MC created with full starting liquidity per answer

Context: bounty.
Simple/minimal fix.
Previously: for higher tier markets, ante would be capped at unmodifiedAnte (i.e. numAnswers * 100 for MC).
Now: for independent MC, ante is allowed to scale with the full totalMarketCost. For other question types, functionality is unchanged.

I'm not convinced this is good actually. the drizzling is useful for new answers and especially if you want to initialize the probabilities right after creating the market. it is not entirely without purpose
I do see how this would make things simpler though...

@sipec The liquidity drizzle is broken for independent MC, and much of the mana you spend is burned with no benefit (because it does not use maniswap). If the liquidity drizzle was not broken, I would not have a strong opinion on whether the smooth functionality of a delayed drizzle is worth the added unintuitive complexity (that difference is trivial IMO compared to the bad feeling of "you just lost a bunch of the mana you spent").
Example in practice: https://manifold.markets/Moscow25/will-polymarket-clear-1b-in-betting. Creator bought mana and made a Premium market. They wondered where all that liquidity went. Some of it is drizzling in, but even after the drizzle some options have way less than they should. I had to explain that independent MC is broken, and much of the mana they spent was burned forever. This was a very bad user experience (or to quote the user who bought mana—"this sucks").
When possible, I try to warn creators that Premium+ independent MC are broken, and they should not be used. Personally, I would like to make these markets, but I can't do so until they no longer waste the mana you spend on them. Fixing the drizzle for independent MC is a tougher task, but if they can simply start with the full liquidity (like adding options), the market type will be at least be functional (and adding liquidity is a much less important bonus).

LGTM! Thanks @Ziddletwix!


Update xcode project template to 9.1

Verified that this causes xCode 9.1 to open cleanly without any warnings, yay!

Two remaining issues I see:

An icon warning: "/Users/mit/tmp/xp1/ios/Runner/Assets.xcassets: A 1024x1024 app store icon is required for iOS apps"
After running: "2017-11-24 09:22:08.376694+0100 Runner[7523:10781563] You've implemented -[ application:didReceiveRemoteNotification:fetchCompletionHandler:], but you still need to add "remote-notification" to the list of your supported UIBackgroundModes in your Info.plist."

Should we handle those as separate issues?

I'm fine with us following up with those two issues as followups. Thanks for doing this cleanup.
@xster can you file an issue for (1)? Looks like there's already related issue #9984 for (2).

https://github.com/flutter/flutter/issues/13237


Custom module styles no longer applying (v0.6.6)

Hi and first of all, thanks for your awesome work on waybar!
I just upgraded from 0.6.5 to 0.6.6 (0.6.6-6-gb673279) from the AUR and noticed that my CSS styles for custom modules are no longer being applied. If I switch back to 0.6.5 everything is fine again.
Did anything intentionally change in the syntax of applying styles to custom modules, or is this perhaps a bug?

Fixed with 755d38d4d6e382980e7ba9619b0226feec27f7d0


Support misbehaving promises in Promise.all

We currently break when Promise.all is given a Promise that "fulfills" twice.  This is not an issue with Promises/A+ compliant implementations, but it is still probably worth fixing.
I also took this opportunity to optimise our approach to Promise.all on promises that are already resolved and simplify how we do value promises in Promise.resolve.

This is great. Are you also considering to add a check for whether Promise.all was passed an iterable?

@cpojer Yes, I think we should do that, but we should do so at the same time as adding support for sub-classing since both will be breaking changes (we currently support any Array-like, e.g. arguments, NodeList etc.)


chore: switch to axios

Switching out request for axios, and making the API support callback and async styles.

@ofrobots all the tests are passing, this is ready for a pass.  Apologies for the size of the review, couldn't really find a way to split it up.

@ofrobots I think I covered all the feedback so far.  Ready for the next wave :)


jQuery no longer autoloaded by default despite docs stating otherwise

This is pretty self-explanatory but the 0.9.0 docs (specifically https://github.com/JeffreyWay/laravel-mix/blob/v0.9.0/docs/autoloading.md) state that

...jQuery autoloading is shipped out of the box...

However, it's been removed from the Mix.autoload config in https://github.com/JeffreyWay/laravel-mix/blob/v0.9.0/setup/webpack.config.js#L299

Well, you could've made a PR by yourself :wink: It isn't that much.

@manniL A PR for what, adding jQuery back into the autoloader or removing the reference from the documentation? Not so easy when you don't know the intention behind the change...

@deframe Obviously, documentation needs to be brought up to date. It was mentioned in release notes to 0.9. Also, the intention to remove implicit auto-loading has already been stated here by Jeffrey weeks before the change went live so no question here.

:thumbsup:


added possibility to use Fn as a modifier key

I lacked this modifier and didn't wanted to lose application-specific hotkeys
I barely had clear understanding of what i was doing but that was interesting :D

Sorry, I've missed koekeishiya/skhd#59


Error #1069

Starting in version  24.2, and continuing in the following versions including 24.5, adding a new vagina to a character causes saves not to load in game. The game gives Error #1069.  Removing the vagina frees up the save.
I think the issue is that the bugged vaginas have the "fullness" integer present. Removing that integer via  minerva allows the saves to load again.
Attached should be a bugged and unbugged version of a save (slot 2) made with 24.5. The unbugged version was edited by minerva only to remove the "fullness" entry.
TiTs Saves.zip

This should be fixed in 25.0

Can confirm. Very fixed.


[Suggestion] Add commands to get rid of bugs to wiki

Sometimes stuff in the game gets bugged. Glitch visual effects getting stuck, UI elements getting stuck, combat music loops getting stuck and so on. But many of these bugs can be solved with engine tweaks commands. Is the netrunner glitch effect stuck? Just run command Game.RemoveEffectPlayer("BaseStatusEffect.NetwatcherGeneral")
This is example when I got rid of glitch effect on my screen using this command. But there are surely other commands for example to get rid of the relic malfunction notification if it gets stuck on the screen which happened to me a lot but I never figured out command to get rid of it.
I think it would be cool to have section on the wiki that would help people fixing audio or visual bugs. I often find myself restarting the whole game just to get rid of stuck UI element even tho it should be possible to get rid of it with engine tweaks commands.
For example, today I met audio glitch when the combat music was always looping even when combat ended and I'm sure there is command to stop music completely which would probably fix it up.

Btw I really need help.  The only option is to rollback several missions back before the combat mix played.

Did you try to visit a Joytoy? Triggering a new cutscene could solve the music issue. At least it did as I had similiar problems.

This should be a standalone mod


Append the message subject, instead of replacing it

Status: :white_check_mark:
Connects to #218
Features:

Append the message subject, instead of replacing it

Testing:

git checkout append-subject

This change is

Reviewed 6 of 6 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


libxnd and libndypes: init at 0.2.0dev3

Motivation for this change
Wanted to experiment with xnd package in nix so created packaging description.
Things done
libxnd: init at 0.2.0dev3
libndtypes: init at 0.2.0dev3

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

[ ] NixOS
[ ] macOS
[X] other Linux distributions

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

Success on aarch64-linux (full log)
Attempted: libxnd
Partial log (click to expand)
/nix/store/k1vvnj94k17lcr04k1i8arslf2nd5lzv-coreutils-8.29/bin/install -c -d -m 755 /nix/store/89i1c8mfxj9z85izwpshmb7xmx5zi3rs-libxnd-0.2.0dev3/share/doc/xnd
cp -R doc/* /nix/store/89i1c8mfxj9z85izwpshmb7xmx5zi3rs-libxnd-0.2.0dev3/share/doc/xnd
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/89i1c8mfxj9z85izwpshmb7xmx5zi3rs-libxnd-0.2.0dev3
shrinking /nix/store/89i1c8mfxj9z85izwpshmb7xmx5zi3rs-libxnd-0.2.0dev3/lib/libxnd.so.0.2.0dev3
strip is /nix/store/4md2i310zklkkl5j41yw70gcwgn4kav5-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/89i1c8mfxj9z85izwpshmb7xmx5zi3rs-libxnd-0.2.0dev3/lib
patching script interpreter paths in /nix/store/89i1c8mfxj9z85izwpshmb7xmx5zi3rs-libxnd-0.2.0dev3
checking for references to /build in /nix/store/89i1c8mfxj9z85izwpshmb7xmx5zi3rs-libxnd-0.2.0dev3...
/nix/store/89i1c8mfxj9z85izwpshmb7xmx5zi3rs-libxnd-0.2.0dev3

The reason that it does not build on darwin is due to the weird structure of the cmake script. I had the override the makeFlags that the cmake script generates. Hopefully in the future it will be addressed by the devs. Otherwise it fully works on arm and x86_64.

It should be ready for merging now.


Can not upload file in an existing folder

I tried to upload index.html to my staging server,
Errno::ENOENT: No such file or directory @ rb_sysopen - //home/deploy/workspace/webApp/current/index.html
upload! "#{Dir.pwd}/src/index.html", "/#{current_path}/index.html"
However, //home/deploy/workspace/webApp/current did exist.
And if I try to /tmp/index.html it works perfect.
I thought Capistrano is matured to prevent this sort of freaky strange issue T_T

Can you make a simple example application to demonstrate the issue? For example, just create a Gemfile, include Capistrano, set up only enough deployment to replicate the issue, anonymize your username/hostname, and then push the whole thing to github?
Here's an example of a minimal test case: https://gist.github.com/will-in-wi/527327e31af30b3eae2068e2965be05b
Thanks!

Shouldn't it be upload! "#{Dir.pwd}/src/index.html", "#{current_path}/index.html"

My bad, because I put the statement in run_locally do block. Now it's fixed.
Thanks


Please End the Version Confusion

I just encountered a bug that appears to be fixed in 2.1 - I only wanted to verify what version of dotnet core I'm using and to check what's the latest version.
My dotnet --version says 2.1.4 but then I found your incredibly confusing release notes:
.NET Core 2.1
Release Date 	Description 	Release Notes
2018/02/27 	2.0.1-Preview1 with SDK 2.0.1-Preview1 	release notes 	download
.NET Core 2.0
Release Date 	Description 	Release Notes
2018/01/09 	2.0.5 with SDK 2.1.4 	release notes 	download

So 2.0.1-Preview1 comes after 2.0.5? And SDK 2.0.1-Preview1 comes after 2.1.4? So I probably have 2.0.5?
You said you wanted to simplify this (but that was a few months ago) - so here are some suggestions:

use semver
please drop the preview labels
use even/odd version numbers for release/beta versions
align core and sdk versions
make it easier to find out what's installed

Some of this is being changed for upcoming versions of .Net Core, see https://github.com/dotnet/designs/pull/29 and specifically this document.

We have done the alignment of SDK and Core and done work to enable enumeration of whats installed and in view of the SDK and runtime. @laktak, do you have any feedback based on the planned results here? If not, we can probably close this issue because this is already and area that is tracked in other issues.

@Petermarcu the document does not mention it but the preview labels are gone? How are beta's versioned?
Will dotnet --version give me both the SDK and Runtime version (or how do I find out the runtime version)?
Do you know when will this be implemented?

This is all being implemented in the .NET Core 2.1.300 SDK. dotnet --version will only give you the sdk version because thats why it was added initially and people use it expecting a single value that is the sdk version. There were discussions about deprecating that switch and providing things like dotnet --version sdk so you can request a specific version. I'm going to move this issue to the core-setup repo where @steveharter can comment more on exact details of the changes and when they will be merged in.

Issue moved to dotnet/core-setup #3816 via ZenHub


[STORY] As passport holder, I want to see the dashboard so that I know what kind of staking I can do

Acceptance
Background:
GIVEN I am signed in with my Passport on Identity Staking App
Scenario: grants round header
WHEN I want to know what Gitcoin Grants Round I am staking for
THEN I can see a header telling me what Round this staking is for
AND I can see the dates of the round
Scenario: staking options
WHEN I want to know about Self Staking options
THEN I can see an option with a header that says “Stake on yourself”
AND I can see a brief explanation of what it means to “stake on yourself”
AND I can see a total balance of GTC I have staked on myself
AND I can see a button that says “Stake”
WHEN I want to know about Community Staking options
THEN I can see an option with a header that says “Stake on other people”
AND I can see a brief explanation of what it means to “stake on other people”
AND I can see a total balance of GTC I have staked on other people
AND I can see a button that says “Stake”
Scenario: sidebar information
WHEN I read the side bar details about community staking
THEN I find out that someone(s) in the community has staked on me with a card that informs me
    to continue details acceptance on info about others staking on the user - #39
WHEN I should know more important details about Identity Staking
THEN I see a card on the side informing me of any important details I need to know
AND a link that directs them to somewhere to find out more about these important details
Notes
Knowing about community stakings on the user

what do we put here (if anything) when a user does not have any stakings on them?

For designs check out: https://www.figma.com/file/cpTUBYmCxRIjh5A4cV2RJl/🥩Staking-App?node-id=24%3A3185
What to look for:

@brentmartin  to provide "explanation"s for each Stake on yourself and Stake on other people

story points 2


Apply more idiomatic Rust to main app logic

Hi there! I found this tool via Cargo as I was looking for a quick and easy way to generate some lorem ipsum and I noticed some things weren't quite working as expected. I went ahead and fixed it up so I could use the tool locally and I figured I should share my changes with you should you want to incorporate them.
Here's a summary of my changes:

Make use of the Option type to set default arg values

This fixes the word count getting overridden to 5 no matter what number is passed

Replace chain of if statements with match block for command switching

By using a match statement we now will receive an error at compile-time warning us of non-exhaustive matches

Remove unnecessary panic!

Clap would panic before we reach this point for the case this statement intended to cover

Ensure stdin exits if too little input is received (< 3 words)

@ChrisRenfrow thank you for taking your time. Those changes seem to be quite good. I'm merging them as they are. Appreciate your work.


[Limiter plugin] "Uncaught TypeError: this.core.editor is not a function"

I was trying to use the limiter plugin and got a "Uncaught TypeError: this.core.editor is not a function" in the chrome console.
I figured the plugin was not up to date, and surely enough, the function "editor()" does not exist anymore and has been replaced by "getEditor()". Fixing this allows the plugin to work.
At the time of writing this, the code is :
(function($)
{
	$.Redactor.prototype.limiter = function()
	{
		return {
			init: function()
			{
				if (!this.opts.limiter)
				{
					return;
				}

				this.core.getEditor().on('keydown.redactor-plugin-limiter', $.proxy(function(e)
				{
					var key = e.which;
					var ctrl = e.ctrlKey || e.metaKey;

					if (key === this.keyCode.BACKSPACE
					   	|| key === this.keyCode.DELETE
					    || key === this.keyCode.ESC
					    || key === this.keyCode.SHIFT
					    || (ctrl && key === 65)
					    || (ctrl && key === 82)
					    || (ctrl && key === 116)
					)
					{
						return;
					}

					var text = this.core.getEditor().text();
					text = text.replace(/\u200B/g, '');

					var count = text.length;
					if (count >= this.opts.limiter)
					{
						return false;
					}

				}, this));

			}
		};
	};
})(jQuery);

Hi @Alphare, would you like to submit a pull request for this fix and get full credit?

I have never sumbitted a pull request before, but surely I'd like to if it is possible. How can I do that?
Is the plugin part of this repository?

This looks like a plugin for the Redactor editor itself - this repo merely provides convenience for integrating the editor w/ Django


feat: change from ChatGPT3.5 to 4.0 for PR review (#4438)

Description

Related links

Tests performed

Notes for reviewers

Interface changes

Effects on system behavior

Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[ ] I've confirmed the contribution guidelines.
[ ] The PR follows the pull request guidelines.

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.

[ ] The PR follows the pull request guidelines.
[ ] The PR has been properly tested.
[ ] The PR has been reviewed by the code owners.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.
[ ] The PR is ready for merge.

After all checkboxes are checked, anyone who has write access can merge the PR.

Closing:

https://github.com/autowarefoundation/autoware.universe/pull/7332#issuecomment-2152948408


6.x mailer markdown loses strikethrough support from 5.x

Laravel Version: 6.18.18
PHP Version: 7.4.6
Database Driver & Version: n/a

Description:
After upgrading my app from framework 5.7.29 to 6.18.18, I noticed my email templates that included markdown for strike-through no longer rendered as they did before. The strikethrough wrapper ~~ was passed as-is instead of causing strikethrough.
I believe the source of this issue is the switch to commonmark, and the solution would be as easy as including an option to instantiate commonmark using new GithubFlavoredMarkdownConverter() in place of  new CommonMarkConverter()
Steps To Reproduce:

Create or edit any markdown mail template to include strikethrough text: text
Render the mail template

It's indeed a feature of Github flavored markdown. But as this is more of a feature request I'm moving this to discussions instead. You can attempt a PR if you want.


[fix bug 1108340] Enable Ukrainian language in settings.

Coverage remained the same when pulling 7cc0c3a612c9ca9e03db1ff2ccf775eb8f3507c1 on akatsoulas:1108340 into 91ed5e3eeb1f926d7864ea75a3a8a4f562a659f7 on mozilla:master.

r+


feat: Adding a new variant for tap-strava built with the SDK

All Singer definitions are stored in /_data/taps/ or /_data/targets. The minimal requirement for adding a tap or target will match the following format:
description: General description of what the company behind the API does
entity_type: Review the JSON Schema for latest options. Currently api, file, database.
entity_url: URL of the developer documentation or website
label: Properly formatted label of the connector
name: The unique name of the connector
singer_name: The Singer specific name of the connector. Typically tap-<name> or target-<name>
type: tap or target
variants: # an array of variant types
- default: true or false
  maintenance_status: "Options: active, beta, development, inactive, unknown"
  meltano_sdk: true or false
  name: Name of the GitHub/GitLab namespace
  pip_url: git+<git_url>.git or pip instal name
  repo: repo URL
  capabilities:
    - catalog
    - discover
  settings:
    # Can be an empty array if unknown: []
    # Describe the list of supported settings, for example:
    - name: project_ids
      kind: array
      label: Project IDs
      description: Array of project IDs.
    - name: username
      label: Username
      description: Credentials used when for connecting to the source.
    - name: password
      kind: password
      label: Password
      description: Credentials used when for connecting to the source.

Checklist

[x] Add/update the file in the appropriate folder (/taps or /targets). The name of the file should match the name of the tap. If there is already one, add a descriptor to the name such as -search.
[x] Add/update the PNG logo image in /assets/logos/<taps or targets>. The image name must match the YAML file name.
[x] Tag @tayloramurphy or @pnadolny13 to flag it for review. Or post to the #hub channel on Meltano slack.

Reviewer Checklist

[ ] Validate file against JSON Schema. https://www.jsonschema.net/home is an option.
[ ] Build website locally and validate everything works.

I'm a Strata user and very excited about this. Thanks, @dluftspring !

/plugin-test name=tap-strava pip-url=git+https://github.com/dluftspring/tap-strava.git

/test-plugin name=tap-strava pip-url=git+https://github.com/dluftspring/tap-strava.git

/test-plugin name=tap-strava pip_url=git+https://github.com/dluftspring/tap-strava.git

This traceback looks like it's coming from the existing variant on Meltano Hub but the git url looks right to me so 🤷 no idea what's happening

@dluftspring - Typo on my side above ("pip-url" vs "pip_url" in my slash command.) 😄

@dluftspring - Updated checks above look good! ✅
Ignoring the first result, the second run gives the expected output and shows the discovered stream names:
https://github.com/meltano/hub/pull/1108#issuecomment-1369144817

@dluftspring this is great! I see the current default listed on the hub is stale, should we make yours the default? I would vote yes! If you agree can you just put your variant name in https://github.com/meltano/hub/blob/06a9b0c5f20eff1ac7c6bdc0da60c3d77cbea104/_data/default_variants.yml#L312 instead of briansloane?


Cleanup primenode header declarations

Moves all primenode variable declarations that don't need to be in main.h
somewhere more appropriate.
This makes finding some of these declarations a little less obvious but that's what grep or spot are for IMHO. Personally I'd rather have to search these variables than have everything in main.h (it's nasty!).

Need to be Fixed

Fixed


Add yarn package integration

For now in docs here https://shields.io/
I can't found any sample for getting data from yarn package (https://yarnpkg.com)
Like :

total download
version
etc

Thanks

Yarn uses the exact same package repository as npm, so you should just use the npm badges 😃


Allow to fill "organization name (optional)" in the settings

We have agreements with users from some humanitarian organizations that they will use this name when using the web frontend, which can help us to prepare fine-tuned translation models for their needs in future. It would be nice to have this option also in the Android app. It can be hidden in "advanced settings" if needed (most users don't need to fill it).

added in version 0.9.14


[BUG] Error when running AOAI function calling example

Describe the bug
I am running the example provided for function calling as-is on my local machine, not on Azure. There is an error when executing a funciton. I guess there is some issue with the jinja conversation:
pf.flow.test failed with UserErrorException: Exception: OpenAI API hits BadRequestError: Error code: 400 - {'error': {'message': "'##' does not match '^[a-zA-Z0-9_-]{1,64}$' - 'messages.6.name'", 'type': 'invalid_request_error', 'param': None, 'code': None}} [Error reference: https://platform.openai.com/docs/guides/error-codes/api-errors]
How To Reproduce the bug
Steps to reproduce the behavior, how frequent can you experience the bug:

Run examples/flows/chat/use_functions_with_chat_models in interactive chat mode.
User query: How about London next week? -> chatbot will ask for number of days
User query: 5
Failure

Running Information(please complete the following information):

Promptflow Package Version using pf -v:
{
"promptflow": "1.11.0",
"promptflow-core": "1.11.0",
"promptflow-devkit": "1.11.0",
"promptflow-tracing": "1.11.0"
}
Operating System: Windows 11
Python Version using python --version: Python 3.11.0

Hi @FlorianPydde , I have not reproduced this issue.

From the error message, it appears that this error is related to the message sent to LLM. Have you ever changed the source code?

Thanks for getting back. I found the error. I was using an AOAI model that was NOT supporting function calling. I did the test with two others supporting it and it works as expected.
Sorry for the inconvenience.

I had this issue too, it turns out the names of agents cannot have spaces in them.


Fix the wrong assignation of margins when the text is assigned

Fix the wrong assignation of margins when the text is assigned.
Description of Change

There were no consistent margins between when the Badge was at the top positions or at the bottom as I showed in the first part of the issue #535.
Bugs Fixed

Fixes #535

PR Checklist

[ ] Has tests (if omitted, state reason in description)
[ ] Has samples (if omitted, state reason in description)
[ ] Rebased on top of main at time of PR
[ ] Changes adhere to coding standard

[ ] Updated documentation

@Rabosa616 can you verify your CLA status?

I don't know why the @dnfadmin says that CLA is not signed if I go to site I see that is signed

@jfversluis, do you have any idea about this issue?

Hm it seems the GitHub checks thinks it's OK, so I guess all is in order. Maybe some kind of hiccup. Ignore it for now, we'll see what happens if you open a second PR :)


fix: fix unwrap error of inflight epoch write fail

I hereby agree to the terms of the Singularity Data, Inc. Contributor License Agreement.
What's changed and what's your intention?
As title, update_inflight_prev_epoch only updates the inflight prev epoch to meta store and not affects the main barrier command workflow. We can directly add a warning and go through.
Please explain IN DETAIL what the changes are in this PR and why they are needed:

Summarize your change (mandatory)
How does this PR work? Need a brief introduction for the changed logic (optional)
Describe clearly one logical change and avoid lazy messages (optional)
Describe any limitations of the current code (optional)

Checklist

[x] I have written necessary rustdoc comments
[x] I have added necessary unit tests and integration tests
[x] All checks passed in ./risedev check (or alias, ./risedev c)

Documentation
If your pull request contains user-facing changes, please specify the types of the changes, and create a release note. Otherwise, please feel free to remove this section.
Types of user-facing changes
Please keep the types that apply to your changes, and remove those that do not apply.

Installation and deployment
Connector (sources & sinks)
SQL commands, functions, and operators
RisingWave cluster configuration changes
Other (please specify in the release note below)

Release note
Please create a release note for your changes. In the release note, focus on the impact on users, and mention the environment or conditions where the impact may occur.
Refer to a related PR or issue link (optional)
Resolve #4919 Close #4923

So the inflight_prev_epoch is not necessary to be persisted?

Only when update in-flight epoch fails and time goes backwards after meta reboot will brings some problems. And time goes backwards at least more than 15 seconds, which is upper retry bound of write on etcd meta store. It's almost impossible.

So the inflight_prev_epoch is not necessary to be persisted?

For now yes, but we might have more meta info to be persisted in the future. After discussed with @BugenZhao , we decided to keep it.

Only when update in-flight epoch fails and time goes backwards after meta reboot will brings some problems. And time goes backwards at least more than 15 seconds, which is upper retry bound of write on etcd meta store. It's almost impossible.

Yeah. Thus, from my understanding, it's better to wait for retrying persistence, instead of ignore the error

So the inflight_prev_epoch is not necessary to be persisted?

For now yes, but we might have more meta info to be persisted in the future. After discussed with @BugenZhao , we decided to keep it.

Yes, it may be very tricky to handle the cases that some are persisted but some are not.
For example, if the inflight_prev_epoch says the latest epoch is 100 but the catalog info is for epoch 101, the system won't know how to continue.

So the inflight_prev_epoch is not necessary to be persisted?

For now yes, but we might have more meta info to be persisted in the future. After discussed with @BugenZhao , we decided to keep it.

Yes, it may be very tricky to handle the cases that some are persisted but some are not.
For example, if the inflight_prev_epoch says the latest epoch is 100 but the catalog info is for epoch 101, the system won't know how to continue.

In your scenario, if meta don't reboot, it will keep pushing the epoch number, like 101 =>102=>..=> 110. If get reboot, meta will try to recovery and init from a new epoch generated with current timestamp, like 11x. The pepose

After discussed with @fuyufjh , we decided to keep the unwrap here since retrying on meta store is already supported.


[Bug] Creating new entities

Describe the issue

Sometimes (usually after a restart of homeassistant) the list of entities will have duplicates. So I'll have two containers:

sensor.portainer_myserver_watchtower_2
sensor.portainer_myserver_watchtower_3

When I click into sensor.portainer_myserver_watchtower_2 it says the entity is no longer in use by the integration:

This means my list of entities keeps growing until I manually remove old entities.
How to reproduce the issue

Hard to reproduce, seems to happen randomly when I restart homeassistant or the machine itself.
Expected behavior

Container entities should always be the same and new ones should not be created:
There should only ever be one entity:

sensor.portainer_myserver_watchtower

hmm, that could happen if container Id in docker is changing. Not sure why that would happen

I don't really understand how entities work in homeassistant but can the integration automatically delete entities no longer managed by portainer?

its how entities work in docker, not HA.
Integration does not delete them automatically.

hmm, that could happen if container Id in docker is changing. Not sure why that would happen

The same thing happened to me: when a stack is stopped/restarted, the containers inside it are re-deployed with a new id, apparently, and a new entity is created every time.

not sure if their name is constant, specially with compose if name is not specified

If container_name is not passed in the compose config, portainer will deploy the container using stackname_servicename_1.
As long as neither the name of the stack or the name of the service(s) in the docker_compose change, the container name should stay the same.

Are you able to test it and confirm that it wont change? For me it looks ok, but its better if more people can perform this test.

I performed this test:

After stopping the stack and re-deploying, container names stayed the same.

thanks

would love to see this implemented as well!
in docker compose you can use:
version: '3'
services:
homeassistant:
container_name: homeassistant
This will give the container the same name everytime, i have this for all my containers, cause many of my containers connect via API and use the container name as connection point (DNS).
The name_2 / name_3 etc is spamming my homeassistant with new entitiy's on every image pull upgrade / recreate.
im on the waiting list for when this gets implemented, would love to see a quick overview in homeassistant on running containers, or crashed containers (not that this ever happens tho).

I have the same issue as described. I guess it is related to containers being recreated/updated/restarted with updated  container images - either by re-pulling the image manually or automatically e.g. by watchtower. I guess those container image updates result in a new container id (which doesn't seem to change when simply restarting a container).
I just looked really really quickly through the code, but is maybe that the location that uses the container id as unique id and then result in new entity:
https://github.com/tomaae/homeassistant-portainer/blob/master/custom_components/portainer/apiparser.py#L124

I wanted to see if it was a quick-fix that I could make a quick PR for because it's been bugging me, but I realise now that it's pretty fundamental change in how the integration is configured & currently-working, but wanted to continue the discussion.
I took some time tonight to try and track this back; hope my findings are helpful in diagnosing the source & proposing a solution.
Please let me know if anything below is unclear!

For context, here's a cut-down excerpt from my core.entity_registry for the container diun:
      {
            "aliases": [],
            "area_id": null,
            "categories": {},
            "capabilities": null,
            "config_entry_id": "8264ac4f59383c2af498c70f2320ddc6",
            "device_class": null,
            "device_id": "48d3d1e54469fa68a1c952ddb0fa7a03",
            "disabled_by": null,
            "entity_category": null,
            "entity_id": "sensor.portainer_local_diun_3",
            "hidden_by": null,
            "icon": null,
            "id": "5922f825c44547e9864c38d2ce0b585a",
            "has_entity_name": true,
            "labels": [],
            "name": null,
            "options": {
                  "conversation": {
                        "should_expose": false
                  }
            },
            "original_device_class": null,
            "original_icon": null,
            "original_name": "diun",
            "platform": "portainer",
            "supported_features": 0,
            "translation_key": null,
            "unique_id": "portainer-containers-11da9f5caeb19dcc3ec655b14f8dc51727084f5a3b9e51645457a0bff7caa9be",
            "previous_unique_id": null,
            "unit_of_measurement": null
      },
      {
            "config_entry_id": "8264ac4f59383c2af498c70f2320ddc6",
            "entity_id": "sensor.portainer_local_diun_2",
            "id": "86e55c48b07445c1cd206ccee48d80d2",
            "orphaned_timestamp": null,
            "platform": "portainer",
            "unique_id": "portainer-containers-415a5405cc3af21aec9360d24a4cfe72e455d3fae0459d23fb881107bd3f672c"
      },
      {
            "config_entry_id": "8264ac4f59383c2af498c70f2320ddc6",
            "entity_id": "sensor.portainer_local_diun",
            "id": "4acbf7b0aa23cc3bddb45b364e962d7b",
            "orphaned_timestamp": null,
            "platform": "portainer",
            "unique_id": "portainer-containers-2c1eb51417e5274fbe1a48cfdc2448a459faad902620c5cb7272aec8184de65c"
      },

Here's the (REDACTED) matching/latest context for the entry that gets pulled from the API call on L132 of apiparser.py:
{
    "Command": "diun serve",
    "Created":<PHONE_NUMBER>,
    "HostConfig": {
        "(REDACTED)"
    },
    "Id": "11da9f5caeb19dcc3ec655b14f8dc51727084f5a3b9e51645457a0bff7caa9be",
    "Image": "crazymax/diun:latest",
    "ImageID": "sha256:ecac071c00b8af8887c851a2fadf16054dcae0ec4876de19cd6acc5133fcae2f",
    "Labels": {
        "(REDACTED)"
    },
    "Mounts": [
        "(REDACTED)"
    ],
    "Names": [
        "/diun"
    ],
    "NetworkSettings": {
        "(REDACTED)"
    },
    "Ports": [],
    "State": "running",
    "Status": "Up 26 hours"
}

Here's the (REDACTED) version of my docker-compose for that Portainer stack:
version: "3.5"

services:
  diun:
    image: crazymax/diun:latest
    container_name: diun
    hostname: diun-portainer
    command: serve
    volumes:
      - data:/data
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - DIUN_NOTIF_SLACK_WEBHOOKURL=${DIUN_NOTIF_SLACK_WEBHOOKURL}
      - DIUN_PROVIDERS_DOCKER=${DIUN_PROVIDERS_DOCKER}
      - DIUN_PROVIDERS_DOCKER_WATCHBYDEFAULT=${DIUN_PROVIDERS_DOCKER_WATCHBYDEFAULT}
      - DIUN_PROVIDERS_DOCKER_WATCHSTOPPED=${DIUN_PROVIDERS_DOCKER_WATCHSTOPPED}
      - DIUN_WATCH_FIRSTCHECKNOTIF=${DIUN_WATCH_FIRSTCHECKNOTIF}
      - DIUN_WATCH_JITTER=30s
      - DIUN_WATCH_SCHEDULE=0 */6 * * *
      - DIUN_WATCH_WORKERS=20
      - TZ=${TZ}
    restart: unless-stopped

volumes:
  data:
    (REDACTED)

We can see from the above that the Portainer entry's Id value and the Integration entity's unique_id value line up, and that id value from Portainer is the running SHA of the current container, but it's being used as an immutable unique identifier for HomeAssistant for a long-running sensor.

FYI - I got a little lost in the middle figuring out where Names as an array was converted to name as a property inside the integration, but that's done by forcing the value on L178 of coordinator.py for anyone else trying to track this back.

This mapping from API response to HomeAssistant entity is mainly done as part of the PortainerSensorEntityDescription configuration, where we tell the code to use the Id value as the data_reference for entities keyed as "containers" at L83 of sensor_types.py which is then used when checking if the entity exists in the HomeAssistant entity registry at L52 of entity.py

Understandably, for people using this integration to monitor long-running single, specific container instances, this is helpful, so we shouldn't change this functionality without understanding the impact to that subset of users, but ... I would suggest that for most people that use containers as they were designed (immutable, short-lived, easily-replaced images, leveraging external sources for maintaining state) then this is not ideal.
I would suggest that we should leverage the Name value (similar to the current Portainer Environment Entity configuration), or fall-back to leveraging Id when Names is not provided by Portainer (in the case that someone hasn't leveraged container_name as a parameter in their docker-compose or stack-definition)
Alternatively, we could leverage the in-built migration functionality of HomeAssistant's Entity Registry (similar to other integrations) to specify the previous_unique_id value & update the new unique_id value so that the actual entity_id value doesn't have to be updated. This is not very well documented, but is visible in the core code on line 1073 of the current entity_registry.py implementation.
To my (current) understanding, this should only require a small change in one of the following places:

the logic of the sensor-type for containers should be changed to leverage id as the uid and name as the data_reference on Lines 82 & 83 in sensor_types.py
the composition of the "unique-id" value for HomeAssistant's Entity Registry should be updated to leverage the name instead of id on Lines 51 to 54 in entity.py
updating the integration to pass through the previous_unique_id value and call update_entity on the registry rather than add_entity on the platform -- but this would be a signficant refactor of the current entity.py implementation.

Please let me know what you think & how we should continue - I'd love to get this resolved ASAP (as some of my MANY containers are up to _54 and _97 and it's cluttering my entity registry in Home Assistant!)

In doing some follow-up research around the usage of that previous_unique_id value - I found a similar problem in the HomeKit integration, where the entities need to be maintained, but the identifiers are hashed (similar to a replaced container id for the same "instance" of container)
Their implementation is visible here, but as I mentioned above - it's going to need a pretty significant refactoring of the current entity.py and persisting the mapping inside this integration before handing it off to HA.
Let me know what you think?

I support the idea of using the Name value. The current id-based implementation is spamming me by creating properties (I am using Watchtower to automatically  update images).

I would suggest that we should leverage the Name value (similar to the current Portainer Environment Entity configuration), or fall-back to leveraging Id when Names is not provided by Portainer (in the case that someone hasn't leveraged container_name as a parameter in their docker-compose or stack-definition)

Hello,
I have the same kind of issue. I was playing with the docker starting and updating stacks and now I have httpd sensor up to version 5 (sensor.portainer_local_httpd_5).
But interesting is that sensor.portainer_local_httpd_4 and sensor.portainer_local_httpd_5 are both reported as running (rest of the sensors is marked as no longer being provided by the portainer integration). Only difference is image attribute. version 4 has sha256 as value. So it looks like portainer integration get list of containers while watchtower was updating container and did not remove the old one in the end.
How to reproduce it
I did test and hit recreate button on the container page in portainer UI and I got other set of 2 sensors in state running. Image attribute has the same value as I was not playing with watchtower or images on the server.
Reloading of the integration fix it and only last created sensor is active and the rest is mark as no longer being provided by portainer integration.
Summarize the issue (my POV)

The containerId is not stable and is different every time container is recreated and should not be used if we want to have persistent sensor names
The removed containers are not updated on time by the integration
Try to use different key for container identification can have various side effects. How it will be working on kubernetes or azure? Is this integration working with other vendors but docker?


Slider buttons missing accessible name

To do:

add a title
add an aria-label

The arrow image also miss an alt argument


Upgrade BoxViewController to use the size caching BoxViewController.

As per the implementation plan for size caching in #80, this is the third step.
It makes BoxViewController use the newly introduced SizeCachingTableView for all of its table views, so that everything gets size cached by default.
HeightCustomizing is still applicable since the adapter used by BoxViewController falls back to the default adapter behavior only when the HeightCustomizing conformance is absence. In any case, it is bound to be removed in the next PR, which is going to be the rebased #121.
P.S. We have to duplicate BentoTableView to BoxSizeCachingTableView, since otherwise all Forms screens would be broken due to instantiation requirement changes.

Tests are failing due to #147.

@andersio is the PR basically only about extending a BoxSizeCachingTableView from SizeCachingTableView? The rest is just copy-paste?

@TheAdamBorek Yes except https://github.com/Babylonpartners/Bento/pull/145/commits/8f06ec240d8d14bc212c4b729db7f84d4014f375 which makes an existing component to work correctly with AL.

@andersio Is it still blocked?


DOC: capitalization and formatting in lsmr

What does this implement/fix?
Fixes capitalization of the vector b.
Formats variables to be formatted as code. (Maybe these should be surrounded by single quotes instead of double in places.)

Artifact looks good. Thanks @dmmolitor !


CA work

Tracking item for platform work

Did not get a chance to work on this (and need Suwat's help) - bumping sprint

@mhoeger - please update if any progress has been made for this item.

Unfortunately, didn't get much time to invest in this item (on servicing first half of sprint) - will be syncing up with Suwat for latest

Moving to sprint 89

@mhoeger FYI, moving this back to triaged

@mhoeger FYI, moving this back to triaged

Closing this issue as it doesn't actually have any information


Pay someone - App crashes after paying someone and opening chat header in transaction thread

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 9.0.1-0
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Issue reported by: Applause - Internal Team
Action Performed:

Go to staging.new.expensify.com
Go to any chat
Go to + > Pay
Enter amount > Pay elsewhere
Immediately click on the expense preview and then the chat header after paying the money
Wait until the app crashes

Expected Result:
App will not crash
Actual Result:
App crashes after paying someone and opening chat header in transaction thread
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

Screenshots/Videos
Add any screenshot/video evidence

https://github.com/Expensify/App/assets/78819774/7aca81b2-792a-4676-99eb-a0f18b80514e
logs (2).txt
View all open jobs on GitHub

@dangrous  FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

cc @cdOut If this is indeed caused by our PR, looks like we missed adding the right fallback value there ^.

@ikevin127 @cdOut let us know when this is ready for a look!

@dangrous the PR is mentioned here and ready for review.

PR was ✅ Approved - ready for final review & merge!

Fixed in this PR.

As noted on the other PR ^, this should be fixed by https://github.com/Expensify/App/pull/44279

Closing this out since payment will be handled in the other regression issue.


Support configurable completion candidates

Firstly, thank you for an absolutely amazing piece of software!
In https://github.com/artempyanykh/marksman/pull/233, @narutohahahaha asked if it would be possible to add support for allowing users to configure the number of completion candidates in the .marksman.toml configuration file. Is this something you'd consider?
If somebody wanted to try and implement it, where would they have to start? Would it be a matter of updating https://github.com/artempyanykh/marksman/blob/main/Marksman/Config.fs with an additional field for completion candidates, and then update this line to read the value from the configuration file (and if not set, default to 50) instead, or is there more to it than that?

Hey @majjoha, thanks for the kind words!
Re: implementing a feature, I'd also add 'write a couple tests', but otherwise that'd be pretty much it.

Sounds good!
I've given it a go in https://github.com/artempyanykh/marksman/pull/316, but as I have close to no prior experience with F# or LSPs, I could use a few pointers on how to finish the feature. Currently, the implementation seems to not read the candidates field in the configuration file correctly, as it still uses the default value which is now set to 50. Similarly, in the tests, Marksman.ConfigTests.testDefault and Marksman.ConfigTests.testParse_7 in ConfigTests.fs, the expected value is not matched, as the result is null for both tests.
Is there anything obvious that I am doing wrong? :-)

Thanks for having a stab @majjoha ! I commented on the PR


Dropping message with invalid payload: 0x010900a80001050000bfe5

Is your problem within Home Assistant (Core or Z-Wave JS Integration)?
NO, my problem is NOT within Home Assistant or the ZWave JS integration
Is your problem within Z-Wave JS UI (formerly ZwaveJS2MQTT)?
NO, my problem is NOT within Z-Wave JS UI
Checklist

[X] I have checked the troubleshooting section and my problem is not described there.

[X] I have read the changelog and my problem was not mentioned there.

Describe the bug
What causes the bug?
N/A
What do you observe?
The logs occasionally log some packets that zwave-js was unable to decode.
What did you expect to happen?
N/A
Steps to reproduce the behavior:
N/A
Device information
Unsure which device. If any.
The controller is an Aeotec Z-Stick 7, firmware v7.18.1
How are you using node-zwave-js?

[ ] zwave-js-ui (formerly zwavejs2mqtt) Docker image (latest)
[ ] zwave-js-ui (formerly zwavejs2mqtt) Docker image (dev)
[ ] zwave-js-ui (formerly zwavejs2mqtt) Docker manually built (please specify branches)
[ ] ioBroker.zwave2 adapter (please specify version)
[ ] HomeAssistant zwave_js integration  (please specify version)
[ ] pkg
[ ] node-red-contrib-zwave-js (please specify version, double click node to find out)
[ ] Manually built from GitHub (please specify branch)
[X] Other (please describe)

Which branches or versions?
zwave-js-ui via Snap
zwave-js-ui: <IP_ADDRESS>d0208
zwave-js: 10.3.0
home id:<PHONE_NUMBER>
home hex: 0xe3722143
Did you change anything?
no
If yes, what did you change?
I have not looked at the logs for a long time, so I'm not sure when this started appearing.
Did this work before?
Don't know, this is a new device
If yes, where did it work?
No response
Attach Driver Logfile
zwave-js.txt
2022-10-22T19:54:15.965Z CNTRLR » [Node 005] Sending firmware fragment 54 / 2487
2022-10-22T19:54:15.983Z SERIAL » 0x013a00a901052e7a0600368420d21cfeadf080290eed33fd4007985006d5f0f22 (60 bytes)
                                  2c398fd202814ea22c2d5ec30e709b2d5e4c301072500000000858c
2022-10-22T19:54:15.984Z DRIVER » [Node 005] [REQ] [SendDataBridge]
                                  │ source node id:   1
                                  │ transmit options: 0x25
                                  │ callback id:      133
                                  └─[FirmwareUpdateMetaDataCCReport]
                                      report #: 54
                                      is last:  false
2022-10-22T19:54:15.994Z SERIAL « [ACK]                                                                   (0x06)
2022-10-22T19:54:15.997Z SERIAL « 0x010401a90152                                                       (6 bytes)
2022-10-22T19:54:15.997Z SERIAL » [ACK]                                                                   (0x06)
2022-10-22T19:54:15.999Z DRIVER « [RES] [SendDataBridge]
                                    was sent: true
2022-10-22T19:54:16.175Z SERIAL « 0x010e00a8140105057a0501003600a5a1                                  (16 bytes)
2022-10-22T19:54:16.176Z SERIAL » [ACK]                                                                   (0x06)
2022-10-22T19:54:16.178Z DRIVER « [Node 005] [REQ] [BridgeApplicationCommand]
                                  │ type:        broadcast
                                  │ target node: 255
                                  │ RSSI:        -91 dBm
                                  └─[FirmwareUpdateMetaDataCCGet]
                                      total # of reports: 1
                                      report number:      54
2022-10-22T19:54:16.213Z SERIAL « 0x011d00a98500001502b6cabc7f7f01010303020000020100007f7f7f7f7f67    (31 bytes)
2022-10-22T19:54:16.214Z SERIAL » [ACK]                                                                   (0x06)
2022-10-22T19:54:16.216Z DRIVER « [REQ] [SendDataBridge]
                                    callback id:            133
                                    transmit status:        OK, took 210 ms
                                    repeater node IDs:      3, 2
                                    routing attempts:       1
                                    protocol & route speed: Z-Wave, 40 kbit/s
                                    ACK RSSI:               -74 dBm
                                    ACK RSSI on repeaters:  -54 dBm, -68 dBm
                                    ACK channel no.:        1
                                    TX channel no.:         1
2022-10-22T19:54:16.223Z CNTRLR » [Node 005] Sending firmware fragment 54 / 2487
2022-10-22T19:54:16.236Z SERIAL » 0x013a00a901052e7a0600368420d21cfeadf080290eed33fd4007985006d5f0f22 (60 bytes)
                                  2c398fd202814ea22c2d5ec30e709b2d5e4c301072500000000868f
2022-10-22T19:54:16.237Z DRIVER » [Node 005] [REQ] [SendDataBridge]
                                  │ source node id:   1
                                  │ transmit options: 0x25
                                  │ callback id:      134
                                  └─[FirmwareUpdateMetaDataCCReport]
                                      report #: 54
                                      is last:  false
2022-10-22T19:54:16.248Z SERIAL « [ACK]                                                                   (0x06)
2022-10-22T19:54:16.250Z SERIAL « 0x010401a90152                                                       (6 bytes)
2022-10-22T19:54:16.251Z SERIAL » [ACK]                                                                   (0x06)
2022-10-22T19:54:16.252Z DRIVER « [RES] [SendDataBridge]
                                    was sent: true
2022-10-22T19:54:16.575Z SERIAL « 0x011700a80001150e320221640000958e003c0000958d00bdad                (25 bytes)
2022-10-22T19:54:16.577Z SERIAL » [ACK]                                                                   (0x06)
2022-10-22T19:54:16.581Z CNTRLR   [Node 021] [translateValueEvent: value updated]
                                    commandClass: Meter
                                    endpoint:     0
                                    property:     value
                                    propertyKey:  65537
                                    internal:     false
                                    secret:       false
                                    event source: undefined
2022-10-22T19:54:16.582Z CNTRLR   [Node 021] [~] [Meter] value[65537]: 38.286 => 38.286             [Endpoint 0]
2022-10-22T19:54:16.582Z CNTRLR   [Node 021] [translateValueEvent: value updated]
                                    is root endpoint:        true
                                    is application CC:       true
                                    should hide root values: true
2022-10-22T19:54:16.583Z CNTRLR   [Node 021] [translateValueEvent: value updated] found mirrored value ID on dif
                                  ferent endpoint, ignoring event:
                                    commandClass: Meter
                                    endpoint:     1
                                    property:     value
                                    propertyKey:  65537
2022-10-22T19:54:16.584Z DRIVER « [Node 021] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -67 dBm
                                  └─[MeterCCReport]
                                      type:        Electric
                                      scale:       kWh
                                      rate type:   Consumed
                                      value:       38.286
                                      time delta:  60 seconds
                                      prev. value: 38.285
2022-10-22T19:54:16.715Z SERIAL « 0x010e00a8140105057a0501003600989c                                  (16 bytes)
2022-10-22T19:54:16.716Z SERIAL » [ACK]                                                                   (0x06)
2022-10-22T19:54:16.718Z DRIVER « [Node 005] [REQ] [BridgeApplicationCommand]
                                  │ type:        broadcast
                                  │ target node: 255
                                  │ RSSI:        -104 dBm
                                  └─[FirmwareUpdateMetaDataCCGet]
                                      total # of reports: 1
                                      report number:      54
2022-10-22T19:54:21.616Z SERIAL « 0x010900a80001050000bfe5                                            (11 bytes)
2022-10-22T19:54:21.616Z DRIVER   Dropping message with invalid payload:
                                  0x010900a80001050000bfe5
2022-10-22T19:54:21.617Z SERIAL » [ACK]                                                                   (0x06)
2022-10-22T19:54:21.644Z SERIAL « 0x010900a80001050000bfe5                                            (11 bytes)
2022-10-22T19:54:21.645Z DRIVER   Dropping message with invalid payload:
                                  0x010900a80001050000bfe5
2022-10-22T19:54:21.645Z SERIAL » [ACK]                                                                   (0x06)
2022-10-22T19:54:21.694Z SERIAL « 0x010900a80001050000bee4                                            (11 bytes)
2022-10-22T19:54:21.695Z DRIVER   Dropping message with invalid payload:
                                  0x010900a80001050000bee4
2022-10-22T19:54:21.695Z SERIAL » [ACK]                                                                   (0x06)
2022-10-22T19:54:21.793Z SERIAL « 0x010900a80001050000bee4                                            (11 bytes)
2022-10-22T19:54:21.793Z DRIVER   Dropping message with invalid payload:
                                  0x010900a80001050000bee4
2022-10-22T19:54:21.794Z SERIAL » [ACK]                                                                   (0x06)
2022-10-22T19:54:22.054Z SERIAL « 0x010900a80001050000bfe5                                            (11 bytes)
2022-10-22T19:54:22.055Z DRIVER   Dropping message with invalid payload:
                                  0x010900a80001050000bfe5
2022-10-22T19:54:22.055Z SERIAL » [ACK]                                                                   (0x06)
2022-10-22T19:54:22.126Z SERIAL « 0x010900a80001050000bfe5                                            (11 bytes)
2022-10-22T19:54:22.127Z DRIVER   Dropping message with invalid payload:
                                  0x010900a80001050000bfe5
2022-10-22T19:54:22.128Z SERIAL » [ACK]                                                                   (0x06)
2022-10-22T19:54:22.352Z SERIAL « 0x011d00a98600025702b3c4bb7f7f00000503160000030e03027f7f7f7f7f35    (31 bytes)
2022-10-22T19:54:22.353Z SERIAL » [ACK]                                                                   (0x06)
2022-10-22T19:54:22.355Z DRIVER « [REQ] [SendDataBridge]
                                    callback id:            134
                                    transmit status:        OK, took 5990 ms
                                    repeater node IDs:      3, 22
                                    routing attempts:       14
                                    protocol & route speed: Z-Wave, 100 kbit/s
                                    ACK RSSI:               -77 dBm
                                    ACK RSSI on repeaters:  -60 dBm, -69 dBm
                                    ACK channel no.:        0
                                    TX channel no.:         0
                                    route failed here:      3 -> 2
2022-10-22T19:54:22.366Z CNTRLR » [Node 005] Sending firmware fragment 54 / 2487
2022-10-22T19:54:22.382Z SERIAL » 0x013a00a901052e7a0600368420d21cfeadf080290eed33fd4007985006d5f0f22 (60 bytes)
                                  2c398fd202814ea22c2d5ec30e709b2d5e4c301072500000000878e
2022-10-22T19:54:22.383Z DRIVER » [Node 005] [REQ] [SendDataBridge]
                                  │ source node id:   1
                                  │ transmit options: 0x25
                                  │ callback id:      135
                                  └─[FirmwareUpdateMetaDataCCReport]
                                      report #: 54
                                      is last:  false

What's the problem, here? If we're receiving an invalid payload that's what we're receiving so we can't do anything but drop it. This could be due to the packet being malformed over the air by interference. That's why we check and then drop them...

Ah - I was under the impression it might be a yet-to-be-supported packet.. I'm seeing these regularly, apparently, so I figured some device was sending something out.
If this is entirely normal (interference and whatnot), this is a non-issue.

In addition: Sometimes devices send invalid stuff, very rarely our parsing code has an incorrect check. I'll look at this after my parental leave, to know which it is

Thats an empty command from Node 5. I have no clue why it sends it, if it actually sends it, or if this is generated by the stick for some reason. In any case this should be discarded.


Here I Add Basic Projects Using Js and Html and CSS

This is  Basic Project Help to those students who are learning Javascript and css and Html. This is a Very fundamental level Project.
Please Review My Code.

Hey @Faizan-Alam-1 Put all your project in a single folder named "<project_name>_<github_username>" to get the project merged.

Please Check


Add Out of the Box Support for Some Tools

Right now, the tool has a few cool functions out of the box, but I believe it would be much better with many pre-installed tools already available as options.
An idea I had was to integrate this with some of my tools (WiFi-bf, build-a-Bn, ChromePE, CamView) in order to gain some potential users.
I would be happy to link this to each of my repos/tools I listed before granted that you gave credit through license and maybe in README - all are in Python except for one in NodeJS, and should be pretty easy to integrate.
Let me know what you think of this idea!

Awesome that sounds good, if you can link me ill have a look 👍🏼

Here's my tools I was talking about.
Wifi Brute-Forcer
Chrome Post-Exploitation
Build a Botnet
Security Camera Viewer
I think you should also include some major Python tools such as:
[Social Engineering Toolkit](https://github.com/trustedsec/social-engineer-toolkit）
If I think of any more I'll let you know!


Set resource limits for all applications

Kubernetes doesn't know how to size them to put them on nodes, so it doesn't know how to scale up. Along with that, when k8s scales down, applications should know how to gracefully shut themselves down so requests aren't dropped

Each deployment manifest we create should have a resource block specifying at least requests, like so:
requests:
  cpu: 100m
  mem: 128Mi

With docs here

Actual resource usage on a Sunday afternoon
operationcode-backend-3485932704-9kt5d           2m           435Mi
town-crier-1047233007-fgtxl                      0m           49Mi
operationcode-frontend-1058172611-4jhx2          0m           52Mi
operationcode-psql-postgresql-2918048348-8q0rk   4m           54Mi
operationcode-backend-3485932704-84vnn           2m           421Mi
operationcode-bot-1758919366-rvlww               0m           52Mi
operationcode-frontend-1058172611-75gf5          0m           65Mi
operationcode-bot-1758919366-qjsp9               0m           54Mi
cloudwatch-l44t7                                 7m           5Mi
operationcode-redis-redis-1146509343-dr3j9       3m           12Mi```

Let's do this post-migration.

I added some very generic resource limits to everything (with 2 different PRs, since one PR affects the location of some of the deployments).


Temporal Programming Support

Temporal Programming
Introduce time-based constructs that execute only at specific times or intervals.
Example:
@EVENT_TRIGGER every 5 seconds -> print("Hello");
@EVENT_TRIGGER at "2024-12-31 23:59:59" -> triggerEvent("Happy New Year");
Implementation: Requires a time scheduler and event-driven runtime engine.


Windows 10 - text rendering artifacts after adjusting DPI scaling in Windows settings

On Windows 10, if you adjust DPI scaling down in the OS, and then lower the font size in Alacritty, text will be rendered with artifacts:

If you keep hitting ctrl+= or ctrl--, there are certain sizes that don't have artifacts, but others that do. Eventually, after changing the size enough times, the artifacts disappear altogether.

This is built on the latest commit.

Eventually, after changing the size enough times, the artifacts disappear altogether.

Addendum: the artifacts returned again after a short while.

Does this only happen to active instances when changing the DPI while they're running or also for new instances when the DPI has been changed?

It only affects active instances.

I'll try and take a look at this this weekend since I added the DirectWrite backend - I never tested changing DPI and font size together.

it doesn't seem that we update the rasterizer on a DPI change

That's not correct, at least for the other backends. If you take a look at the rasterizer trait, there should be an update_dpr method or something similar:
https://github.com/jwilm/alacritty/blob/master/font/src/lib.rs#L267-L268

You are totally right and I'm updating it there.. Hm.
update_font_size is being called correctly - and we do clear the cache and get the metrics again. I'm certainly a little more confused.
It seems to me that something is going on beyond the font rasterizer:
I have added some logging to handle_resize as that's where we seem to capture resize/DPI change events, specially I have added the following - in addition to logging in the rasterizer's update_dpr function.
display.rs:348
// Take most recent resize event, if any
while let Ok(size) = self.rx.try_recv() {
    new_size = Some(size);

    println!("New size {} {}", size.width, size.height);
}

This gives the following output, comments to line up with events:
// Started at DPI 1
New size 1904 990
New size 1024 768
// Console is now visible
// Select 125% DPI
New size 817.6 608
DPI Changed to 1.25
New size 1282 962
// Console is now visible at 125% - no artifacts
// Now select 100%
New size 1280 960
DPI Changed to 1
// Reset to 100% DPI - still no artifacts
// Now select 125% DPI
New size 1025.6 769.6
DPI Changed to 1.25
// And broken

It seems to me that changing DPI to 125 and back to 100 should result in the same size.
Additionally the fractional size seen when we start seeing artifacts is suspicious.
@chrisduerr @zacps Any ideas?

In my experience these artifacting issues usually pop up when the projection doesn't quite match the rendered output. So stretching a 100x100 grid over 200x200 pixels for example.
Some of the reasons that could cause this would be incorrect font metrics, but it's also possible the projection isn't updated correctly.
As a first step I'd verify what the commit was that broke this, assuming that it worked previously. I wouldn't make assumptions that it was directwrite that broke this until it has actually been confirmed.
So my first step would be to bisect the exact commit that caused this issue (or to check if it always has been an issue).

Alright, I'll try and work through that - though I've quickly eliminate DirectWrite as the issue, at least exclusively, as 0.3.2 also reproduces the issue.

Okay I've investigated a little, it seems that removing the call to draw_rects stops us getting any artifacts. This makes me wonder if we're correctly resetting the OpenGL state after the rects are drawn but I can't put my finger on anything specifically.
We do still have a different issue with Windows - changing DPI results in the terminal getting offset.

FYI: On master removing this call fixes the artifacting too.

We should be correctly resetting things, especially since this issue doesn't exist on Linux or macOS. However additional steps might be necessary on Windows?

I've created a PR #2846 to fix the terminal offsetting above. As a side effect seems it seems to also no longer create these artifacts when changing the DPI scaling. Does someone else want to try with that patch and see whether that's solved it for them too?


Add a better Hash::Schema sub-type suitable for dry-v

Currently we use Types::Safe with Types::Hash::Schema::Symbolized for input-processors. Unfortunately its current behavior has a major issue - when applying value coercion results in a type error, the safe type will rescue from that and return original input. This is not acceptable in dry-v context since it results in getting the original input back so we cannot apply validation rules as basic key? checks fails since we don't even get symbolized keys back.
We need two things:

Symbolizing keys
Using Type#try for value coercion and setting original value in the resulting hash if result is a failure

Refs dry-rb/dry-validation#131

I shall add that this is super important to improve as right now it's easy to crash a validation schema by simply passing an array or a hash as the value when a string is the only accepted one.

Fixed via https://github.com/dry-rb/dry-types/commit/b5ae87e051e5bd5d291aa300b090bb4d2e0c6b3e


[VMware/NGC] Unmount interface lists same volume mutiple times

Is this a BUG REPORT or FEATURE REQUEST?:
/kind bug
What happened:
NGC Plugin UI lists same volume in mutiple rows when there are mutiple free volumes to mount.

What you expected to happen:
list mounted volume only once
How to reproduce it (as minimally and precisely as possible):
create and attach mutiple volumes and select unmount interface form NGC plugin UI.
Anything else we need to know?:
NA
Environment:

NBP version:v0.7.0
OS (e.g. from /etc/os-release):Windows
Kernel (e.g. uname -a):
Install tools:
Others:

Fix delivered in Hotpot https://github.com/opensds/opensds/pull/1142


set referencable's expiration timestamp from handles

@jasonwyatt addressed comments, PTAL

manual copybara passes cl/297526523
merging this now (before the entire universe changes underneath me... again), will address additional comments if any in a follow pr.


Single-machine multi-GPU training or inference

Thank you for contributing such a great job.
I want to use Metric3D for single-machine multi-GPU training or testing, but I found that it is missing some information, such as: dist_params in the configuration.
Do you have any suggestions on this?

Try to set cfg.dist_params with corresponding sub-variables like {'port': None, 'backend': 'nccl', 'dist_url': 'env://', 'nnodes': 8, 'node_rank': 0, 'num_gpus_per_node': 8, 'world_size': 64}

Try to set cfg.dist_params with corresponding sub-variables like {'port': None, 'backend': 'nccl', 'dist_url': 'env://', 'nnodes': 8, 'node_rank': 0, 'num_gpus_per_node': 8, 'world_size': 64}

Very helpful advice, thank you for your suggestions.


MdMenu, OverlayRef: Cannot read property 'removeChild' of null

Bug, feature request, or proposal:
Bug
What is the expected behavior?
Should not throw an exception.
What is the current behavior?
The first time a user navigates away (clicks on one of the items in the menu that leads to another page - via angular router) from a <md-menu> that is currently opened, it throws an exception:
TypeError: Cannot read property 'removeChild' of null
    at HTMLDivElement.eval (overlay-ref.js:86)
    at e.invokeTask (zone.min.js:1)
    at Object.onInvokeTask (core.umd.js:6197)
    at e.invokeTask (zone.min.js:1)
    at n.runTask (zone.min.js:1)
    at HTMLDivElement.invoke (zone.min.js:1)
ErrorHandler.handleError @ core.umd.js:3010
next @ core.umd.js:6654
schedulerFn @ core.umd.js:5952
SafeSubscriber.__tryOrUnsub @ Subscriber.ts:238
SafeSubscriber.next @ Subscriber.ts:190
Subscriber._next @ Subscriber.ts:135
Subscriber.next @ Subscriber.ts:95
Subject.next @ Subject.ts:61
EventEmitter.emit @ core.umd.js:5944
NgZone.triggerError @ core.umd.js:6248
onHandleError @ core.umd.js:6227
n.runTask @ zone.min.js:1
invoke @ zone.min.js:1

What are the steps to reproduce?
Providing a Plunker (or similar) is the best way to get the team to see your issue.
Plunker template: http://plnkr.co/edit/o077B6uEiiIgkC0S06dd
What is the use-case or motivation for changing an existing behavior?
Which versions of Angular, Material, OS, browsers are affected?
2.0.0-alpha.10
Is there anything else we should know?

https://github.com/angular/material2/pull/1716 might fix this.

Should be fixed by #1716


Update generated.json

I'm not sure, but maybe this will solve the issue #234

@AlexanderSaid It won't change as it's dynamically generated.


How can I plot a singular point?

I've tried many ways to plot a singular point with what Chart module returns, such as Custom Indicators with NaN's for everything else, accessing the axes, I can't get it to show, it defaults any singular Series point with values of NaN to a legend only.

Hi @syntaxsdev,
I am not sure what you are trying to achieve here. In anycase, you can always access the matplotlib figure as chart.figure but the module translates dates to positions so it would be difficult for you to add graphics without knowing the internals of the library...

Hi, @furechan, I was able to do it by directly modifying the chart.py to include a plot_points method. It allows you to plot singular points and labels (for example if you wanted to add a dot and an arrow to show where a specific indication is).  If you are okay with that, I can submit a PR on it and we can adjust to your liking.

Ok - no problem. I will keep the fork open as I am probably going to add more eventually.


amend: updated deps

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Narrator announces a % for indeterminate ProgressBar

Describe the bug

When Narrator focus is placed on an indeterminate ProgressBar, Narrator announces "0% progress bar", which is not distinguishable from an empty determinate ProgressBar. This announcement is the same for both WUX and the new MUX progress bars.
Steps to reproduce the bug

Steps to reproduce the behavior:

Go to the ProgressBar page in Xaml Controls Gallery
Turn on Narrator
Use items navigation to move focus to the indeterminate progress bar (Caps+Left)

Expected behavior

Narrator should announce "busy progress bar" (similar to ProgressRing's behavior)

We tried fixing the automation peer to not provide the appropriate pattern but unfortunately Narrator caches the patterns and changing from determinate to indeterminate at runtime does not pick up the change in the patterns. This issue is tracked by this internal bug.

Sounds good. Let's wait until the Narrator bug is fixed, then.

@YuliKl Turns out the bug mentioned above is not the case, so the changes are merged into master. Currently, it announces "Busy 0% [ProgressControlName]" for Indeterminate, and "x% [ProgressControlName]" for Determinate.

Closing stale external bug. If you are still seeing this issue, please open a new issue with updated repro steps and logs/diagnostics.


silkworm_capi_test: failure on macOS after decreasing execution batch size

After PR #2308, which decreased the batch size in block execution tests, some C API unit tests started to fail only on macOS.
It seems to be somewhat related to this, but in a different context so needs further investigation.
#2388 skips such tests to restore clean build

fixed by https://github.com/erigontech/silkworm/pull/2412


feat(JAQPOT-104): build and test jaqpotpy

Running:

build
lint with flake8
tests with pytest

on jaqpotpy on every commit and when merging to main, to ensure the code quality of our repo and that we're not breaking anything.

@alarv  I am done here, whenever you want check it out and merge it to main


There are no sources in pako 1.0.7

Please see https://lib.haxe.org/p/pako/1.0.7/files/src/
Would you reregister the package?

Well that's embarrassing. Fixed: https://lib.haxe.org/p/pako/1.0.8/files/src/

Thank you!


test: run system tests against the emulator

Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:

[x] Make sure to open an issue as a bug/issue before writing your code!  That way we can discuss the change, evaluate designs, and agree on the general idea
[ ] Ensure the tests and linter pass
[ ] Code coverage does not decrease (if any source code was changed)
[ ] Appropriate docs were updated (if necessary)

Fixes #965 🦕

@hengfengli do you have any ideas on how to get the presubmit section of a PR to run the tests against the emulator? I thought it was sufficient to add this config.

In Go, I have a shell script (https://github.com/googleapis/google-cloud-go/blob/master/spanner/emulator_test.sh) and it has been put in https://github.com/googleapis/google-cloud-go/blob/master/internal/kokoro/presubmit.sh#L59-L62.

@JustinBeckwith hope I can ask for your advice here. We want to also run the system tests against the emulator. We have two options:

Introduce another Kokoro step.
Modify the existing system-test.sh to also run the tests against the emulator.

Which one would you advice that we do?

Are you looking to modify the existing system tests to use the emulator instead of the backend service?  Or are you looking to run the same set of system tests against both, as separate checks?
A few options coming to mind:

If the code you're writing doesn't need access to service account credentials, you may be able to skip all of this and just drop a bonus github action.  You would create a copy of the .github/workflows/ci.yaml file, and trim it down to just what you need.  This would only work if you don't need service account keys.
You could keep everything like it is now, but piggy back on the existing npm run system-test command.
You could introduce a new kokoro job, like you're doing now.  I suspect you also need to do some work on the backend in google3 to accomplish that :) @bcoe knows how that all works.

Thanks @JustinBeckwith.
Our aim is to run the same set of system tests against both prod and the emulator, as separate checks.
(1) is a great idea. I didn't think of that. We don't need to set service account credentials but we do need to set an environment variable. From the discussion we had on the Java GitHub actions, this might not be possible? In any case, I'll look into it.
If (1) doesn't work then, I think we want to go with (3) just so that we can distinguish between the failures.

Hmmm I don't think GitHub Actions can run shell scripts or at least not in the way that we want.
We need steps to setup the emulator and tear it down. In order to do that and have the tests fail appropriately (when intermediate steps fail), we have to call set -eo pipefail. But this type of thing is not allowed in GitHub Actions.
Run sh .kokoro/system-test-against-emulator.sh
.kokoro/system-test-against-emulator.sh: 18: set: Illegal option -o pipefail
##[error]Process completed with exit code 2.

PTAL, I got it to work but the downside is that I can't get the script to exit and not try to run the systests if the emulator setup fails.
@JustinBeckwith hope this setup is acceptable. It's probably very weird compared to how other GH actions are setup in other repos.


How to close kubectl connection to old AKS instance after az group delete

I followed this tutorial then did an az group delete --name myResourceGroup --yes --no-wait. But kubectl get nodes  gives Unable to connect to the server: dial tcp: lookup myk8sclust-myresourcegroup-836c63-ccde7c6b.hcp.eastus.azmk8s.io on <IP_ADDRESS>:53: no such host which is preventing me from being able to use kubectl. What do I do?

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

ID: a172fdbe-fd3e-1ad5-d37e-fe393a241c5a
Version Independent ID: 516ee51f-d68c-685e-7f9d-8442bb977a6e
Content: Quickstart - Azure Kubernetes cluster for Linux
Content Source: articles/container-service/kubernetes/container-service-kubernetes-walkthrough.md
Service: container-service
GitHub Login: @neilpeterson
Microsoft Alias: nepeters

@zfrenchee If I understand correctly, you have deleted a cluster (az group delete) and would now like to use kubectl against a different cluster?
If I have this correct, when you run az aks get-credentials a config file is placed a ~/.kube which includes the pieces necessary to connect to the cluster. If you want to connect to a second AKS cluster you have two options.

Delete the ~/.kube/config file and then run az aks get-credentials again
Do not delete the file, but run az aks get-credentials again. This will add the context of the second cluster to the config file.

Does this help?

What is the output of kubectl config current-context
You can also see if the minikube context is configured:
kubectl config current-context

And the set the mini-kube context:
kubectl config use-context minikube

If you have Docker for Mac or Windows installed, you can also use it to view and switch between K8S clusters.

~ » kubectl config current-context
error: current-context is not set
------------------------------------------------------------
~ » kubectl config use-context minikube
error: no context exists with the name: "minikube".

Any my docker > Kubernetes isn't a dropdown just a button which doesn't seem to do anything.
I guess I really messed something up.

~ » kubectl config view
apiVersion: v1
clusters: []
contexts: []
current-context: ""
kind: Config
preferences: {}
users: []
------------------------------------------------------------
~ » kubectl get nodes
The connection to the server localhost:8080 was refused - did you specify the right host or port?

Unfortunately it seems like there's still some sort of state left behind here by az aks

Maybe try minikube update-context to reset the context?

Worked. thanks! Would recommend updating the az group delete --name myResourceGroup --yes --no-wait step to include some way to reset kubectl's state.


GPU accelerated rendering of protocol decode event bubbles

Right now any "complex" type waveform output is rendered in software with Cairo, which gets slow for realtime streaming or fast panning/zooming.

In ngscopeclient, we build the decode bubbles every frame in immediate mode, then submit a batch to the GPU.
Better, but still not as fast as it should be (vs a fully shader based retained mode design). More work needed.


Update-MarkdownHelpModule always adds [] to Syntax even when  [CmdletBinding()] is not there

I have following function (one of many). It doesn't have  [CmdletBinding()].
function New-HTMLAnchor {
    <#
    .SYNOPSIS
    Short description

    .DESCRIPTION
    Long description

    .PARAMETER Name
    Parameter description

    .PARAMETER Target
    Target options: "_blank|_self|_parent|_top|framename"

    .PARAMETER Class

    .PARAMETER HrefLink
    Parameter description

    .PARAMETER Text
    Parameter description

    .EXAMPLE
    New-HTMLAnchor -Target _parent

    Output:
    <a target = "_parent" />

    .NOTES
    General notes
    #>

    param(
        [alias('AnchorName')][string] $Name,
        [string] $Target,
        [string] $Class,
        [alias('Url', 'Link', 'UrlLink')][string] $HrefLink,
        [alias('AnchorText')][string] $Text
    )
    [System.Collections.IDictionary] $Anchor = [Ordered] @{
        Tag        = 'a'
        Attributes = [ordered]@{
            'name'   = $Name
            'class'  = $Class
            'target' = $Target
            'href'   = $HrefLink
        }
        Value      = $Text # if value is blank it will not be used
    }
    $HTML = Set-Tag -HtmlObject $Anchor
    return $HTML
}

Steps to reproduce

New-MarkdownHelp -Module $ProjectName -WithModulePage -OutputFolder $DocumentationPath -ModulePagePath $ReadMePath
Verify output - common parameters will not be there in Syntax and ### CommonParameters will not be there either
Update-MarkdownHelpModule $DocumentationPath -RefreshModulePage -ModulePagePath $ReadMePath
Verify output - common parameters are added in Syntax and whole section ###ComonParameters is added

Expected behavior
Update-MarkdownHelpModule should behave the same way as New-MarkdownHelp
Actual behavior
Adds common parameters regardless if those are there or not.
Environment data

v0.12.0
I saw this: https://github.com/PowerShell/platyPS/issues/223 but even thou I use the newest published version the problem occurs. So it's either incomplete or I am missing something.

I just encountered this as well, glad it's already logged.

@vors sorry missed this one. Let me have a look.

This is fixed in the data model used by Microsoft.PowerShell.PlatyPS v1.


Add guild_positions field to settings

probably gonna be the only one who uses this heh

Awesome, thanks @jonas747  :)