Workaround GPU Hang on iPhone 6s (iOS 12.2) where setting the renderp…

…ass descriptor to a size smaller than the rendertarget is causing a GPU hang.  We render with offset renderArea/scissor and for reasons unclear this is inducing a GPU hang with no validation errors.  On iPad Air (3rd Gen) it works fine.
@billhollings I'm not sure what to do with this one - I think it may have some performance implications for cases where the renderArea is smaller than the render target, although it seems necessary for us not to hang.

I'm not sure what to do with this one - I think it may have some performance implications for cases where the renderArea is smaller than the render target, although it seems necessary for us not to hang.

If we think this is a GPU-specific bug...we could also combine your two mods (this one and #554) with a test for MTLFeatureSet_iOS_GPUFamily4_v1 and pick one of the two accordingly at runtime. That would provide for both options...efficient rendering for GPU's that can handle the setting of this parameter...and crash-avoidance for those that can't.
I'm curious though...
How should we interpret the Metal renderTargetWidth and renderTargetHeight properties as applied to layered rendering? The Apple docs are short on detail.

Is it meant to be a scissor-like mask that disallows rendering outside the boundaries...and if so...why is it just extent that is limited and not origin...and why doesn't it just use the scissor limits?

Or is it just meant to be a performance enhancement option...as you imply in your comment?

Or something else?

Is it meant to be a scissor-like mask that disallows rendering outside the boundaries...and if so...why is it just extent that is limited and not origin...and why doesn't it just use the scissor limits?

I'm not sure - I guessed the load/store ops would be contained by this boundary, but it's true subsequent drawing operations can be constrained by scissor.  I'm not familiar enough with Metal here to say.  The Vulkan renderArea lets the driver restrain the tile boundaries for the load/store ops, but as you say Metal doesn't have an offset so it seems like a lesser feature.
I'm fine with a test for  MTLFeatureSet_iOS_GPUFamily4_v1, although for what it's worth my test matrix included only three devices.  Two of them had a hang (iPhone 6s/A8 and iPad Air 1st Gen/A7) and the other did not (iPad Air 3rd gen/A12).

@cdavis5e Do you have any insights here? The setting of these properties were added by you in #274, and then reduced in size to render area in #287. Do you have use cases that motivated those two PR's?
The Apple docs clearly group renderTargetWidth and renderTargetHeight under the topic of Layered Rendering, right beside renderTargetArrayLength. But they give no description about what they are used for...other than to "constrain" the target dimensions...presumably in a way that is different than standard scissors.
Because of this grouping...to solve the issue @danginsburg has highlighted...I'm wondering if we can simply assume that renderTargetWidth and renderTargetHeight should only be set if layered rendering is supported? That would certainly fix the issue of older GPU's barfing on this value being anything other than the full frame buffer size.
Both renderTargetWidth and renderTargetHeight are only available on iOS devices.

@cdavis5e Ping re question above.

@cdavis5e Do you have any insights here? The setting of these properties were added by you in #274, and then reduced in size to render area in #287. Do you have use cases that motivated those two PR's?

I initially wrote those when I was working on #284. I was hoping that, when those properties were added on macOS, that rendering with no attachments would work.

The Apple docs clearly group renderTargetWidth and renderTargetHeight under the topic of Layered Rendering, right beside renderTargetArrayLength. But they give no description about what they are used for...other than to "constrain" the target dimensions...presumably in a way that is different than standard scissors.

That's what led me to take the renderArea into account in #287.

I initially wrote those when I was working on #284. I was hoping that, when those properties were added on macOS, that rendering with no attachments would work.
...
That's what led me to take the renderArea into account in #287.

Thanks.
Okay...so we need at least to fix the issue that triggered this PR. If we don't have any particular use case for renderTargetWidth and renderTargetHeight right now...and don't have a solid understanding of them...options include...

Simply ignore them and never set them (ie. pre PR #274).
Set them only to the framebuffer extent (as per this PR).
Set them only when layered rendering is supported...and to the min of framebuffer extent and render area offset + extent (ie. pre this PR but only with layered rendering).

@cdavis5e @danginsburg Thoughts? Left to my own devices...I'd probably opt for the option 3.

I think that any of those three options would fix it in our case.  So if option 3 works for @cdavis5e it's fine with me.
Thanks for the follow up.

Fine by me, since Mac doesn't support this yet anyway. I may want to revisit this later, though, depending on what the next version of Metal supports.

Replaced by PR #562.


NullReferenceException clicking on Pin

Hi,
also I am getting an error after displaying another Master-Detail page and than switching back to the Map page (like the MapPins-Clear() exception.
After switching back to the Map page and clicking on a Pin I am getting this error (again clicking on the Pin the first time, before using the Master/Detail page) there is NO problem clicking the Pin):
at TK.CustomMap.iOSUnified.TKCustomMapRenderer.SetSelectedPin () [0x0004c] in :0
at TK.CustomMap.iOSUnified.TKCustomMapRenderer.OnMapPropertyChanged (System.Object sender, System.ComponentModel.PropertyChangedEventArgs e) [0x00036] in :0
at (wrapper delegate-invoke) :invoke_void_object_PropertyChangedEventArgs (object,System.ComponentModel.PropertyChangedEventArgs)
at Xamarin.Forms.BindableObject.OnPropertyChanged (System.String propertyName) [0x00012] in :0
at TK.CustomMap.TKCustomMap.OnPropertyChanged (System.String propertyName) [0x00000] in :0
at Xamarin.Forms.BindableObject.SetValueActual (Xamarin.Forms.BindableProperty property, Xamarin.Forms.BindablePropertyContext context, System.Object value, Boolean currentlyApplying, SetValueFlags attributes, Boolean silent) [0x000fb] in :0
at Xamarin.Forms.BindableObject.SetValueCore (Xamarin.Forms.BindableProperty property, System.Object value, SetValueFlags attributes, SetValuePrivateFlags privateAttributes) [0x0014b] in :0
at Xamarin.Forms.BindableObject.SetValue (Xamarin.Forms.BindableProperty property, System.Object value, Boolean fromStyle, Boolean checkAccess) [0x0005f] in :0
at Xamarin.Forms.BindableObject.SetValue (Xamarin.Forms.BindableProperty property, System.Object value) [0x00000] in :0
at TK.CustomMap.TKCustomMap.set_SelectedPin (TK.CustomMap.TKCustomMapPin value) [0x00000] in :0
at TK.CustomMap.iOSUnified.TKCustomMapRenderer.OnDidSelectAnnotationView (System.Object sender, MapKit.MKAnnotationViewEventArgs e) [0x00032] in :0
at MapKit.MKMapView+_MKMapViewDelegate.DidSelectAnnotationView (MapKit.MKMapView mapView, MapKit.MKAnnotationView view) [0x00014] in /Users/builder/data/lanes/2689/962a0506/source/maccore/src/build/ios/native/MapKit/MKMapView.g.cs:1797
at (wrapper managed-to-native) UIKit.UIApplication:UIApplicationMain (int,string[],intptr,intptr)
at UIKit.UIApplication.Main (System.String[] args, IntPtr principal, IntPtr delegate) [0x00005] in /Users/builder/data/lanes/2689/962a0506/source/maccore/src/UIKit/UIApplication.cs:77
at UIKit.UIApplication.Main (System.String[] args, System.String principalClassName, System.String delegateClassName) [0x00038] in /Users/builder/data/lanes/2689/962a0506/source/maccore/src/UIKit/UIApplication.cs:61
at VagaBoo.iOS.Application.Main (System.String[] args) [0x00008] in /Users/marcoseraphin/Xamarin/Xamarin/Projekte/VagaBooMobileApp/VagaBooMobileApp (trunk)/iOS/Main.cs:17

What is the exception? I think you may have a pretty odd case here. The best thing would be if you create a small repro project

It is also a NullReferenceException (Object reference not set to an instance of an object) in SetSelectedPin() while clicking on the Pin after switching the Master Detail page back and forth.
Making a sample report is not that easy...it needs a MasterDetail page and some other stuff. TeamViewer session is possible if needed, but of course no debugging..;-(

Thankfully we are on GitHub, you can fork the code and debug yourself. Just add the projects directly on remove the nuget package.


Parse subprotocol from jdbc cnxn string directly, w/o URI

The connection string has query parameters, including Redshift login and password, which have illegal URI characters.  The query is only parsed as a URI in one instance: when the subprotocol is recovered - in other words, to recover 'postgres' from the following string:
jdbc:postgres://redshifthost:5439/database?user=username&password=pass
This could also be done by simply splitting, but that would make jdbc: non-optional (.stripPrefix will not fail if jdbc: is not present):
val subprotocol = url.split(":")(1)
Another option would be to enforce that all query parameters in the connection string should be URL-encoded.  This would make the connection string a correct URI, but would require other changes in the codebase, and would break existing applications.  It is not possible to have the encoding be automatically detected, as the escape characters are valid password characters.

Current coverage is 88.45%

Merging #134 into master will decrease coverage by -6.65% as of e3385de

@@            master    #134   diff @@
======================================
  Files           12      12
  Stmts          511     511
  Branches       124     124
  Methods          0       0
======================================
- Hit            486     452    -34
  Partial          0       0
- Missed          25      59    +34

Review entire Coverage Diff as of e3385de

Powered by Codecov. Updated on successful CI builds.

LGTM. Thanks for fixing this! I'm going to merge this now.


Combinations of collectors and storage techs

Hi,
I understand that Kafka has been the main collector so most docker cases focus on the storage. But since I am working on Azure Event Hubs collector, how should we set up the hierarchy and the project setup? Should each combination have their own folder?

Sorry, on second thought does not make sense, closing it.


Using CUDA without cuDNN

Is there a way to use cuda without using cuDNN in latest version of chainer (<IP_ADDRESS>)?
An error
 File "cupy/cuda/cudnn.pyx", line 171, in cupy.cuda.cudnn.create (cupy/cuda/cudnn.cpp:1487)
 File "cupy/cuda/cudnn.pyx", line 174, in cupy.cuda.cudnn.create (cupy/cuda/cudnn.cpp:1432)
 File "cupy/cuda/cudnn.pyx", line 164, in cupy.cuda.cudnn.check_status (cupy/cuda/cudnn.cpp:1308)
 cupy.cuda.cudnn.CuDNNError: CUDNN_STATUS_ARCH_MISMATCH: CUDNN_STATUS_ARCH_MISMATCH

are occured when we try to run the sample "train_mnist.py", probably because our GPU (NVDIA Tesla C2050/2075) doesn't support cuDNN (compute capability < 3.0).
Thank you

Please use chainer.cuda.cudnn_enabled  flag.
from chainer import cuda
cuda.cudnn_enable = False

The program is worked after cuda.cudnn_enabled = False is added.
Thank you.
*There is a typo in the answer, its writen cuda.cudnn_enable = False instead of  cuda.cudnn_enabled = False.


Relax bundler pin to allow use with bundler 2.0

The current bundler pin prevents usage of bundler 2.0 with this gem,
however the Gemfile is currently compatible and no Gemfile.lock is
checked in (as is best practice for gems) so relaxing the pin allows
usage of bundler 1 and bundler 2 without breaking.
my ldap is samphippen if you have any google internal questions.

Thank you for your pull request. Before we can look at your contribution, we need to ensure all contributors are covered by a Contributor License Agreement.
After the following items are addressed, please respond with a new comment here, and the automated system will re-verify.

User @samphippen isn't covered by a CLA. They will need to complete the form at https://identity.linuxfoundation.org/projects/cncf

Regards,
CLA GitHub bot

Sanity is failing on this because grpc.gemspec is updated without the template that generates  having been updated (templates/grpc.gemspec.template)

sorry for the delay on this - this was actually included in https://github.com/grpc/grpc/pull/21487, so I think this PR is obsolete


Selected text is not visible against headers

For example:

I have "Privacy Policy (WIP)".."Information we" selected.

But you can't see I have "Privacy Policy (WIP)" selected against the header.

This is a Firefox thing, but I'll invert it.


Parsing issue (I think)

This code is just what I need - but I’m having trouble parsing. I can get the sample 80k ultra csv to parse and load, but my own csv files give errors. I suspect this MAY be an issue with unix (actually Mac OS X) vs Windows newline / eol characters, but hoped you might be able to shed some light.
When trying to schedule the attached csv file Bike.zip
The error is 👍
Exception in thread "main" java.lang.IllegalArgumentException: Duration step type was expected, bike
at com.github.mgifos.workouts.model.Step$.parseDurationStep(Step.scala:76)
at com.github.mgifos.workouts.model.Step$.parse(Step.scala:66)
at com.github.mgifos.workouts.model.Workout$.loop$1(Workout.scala:42)
at com.github.mgifos.workouts.model.Workout$.parseDef(Workout.scala:48)
at com.github.mgifos.workouts.model.WeeklyPlan.$anonfun$processed$4(WeeklyPlan.scala:16)
at scala.Option.map(Option.scala:146)
at com.github.mgifos.workouts.model.WeeklyPlan.$anonfun$processed$1(WeeklyPlan.scala:15)
at com.github.mgifos.workouts.model.WeeklyPlan.$anonfun$processed$1$adapted(WeeklyPlan.scala:13)
at scala.collection.generic.GenTraversableFactory.tabulate(GenTraversableFactory.scala:148)
at com.github.mgifos.workouts.model.WeeklyPlan.weekPlan$1(WeeklyPlan.scala:13)
at com.github.mgifos.workouts.model.WeeklyPlan.loop$1(WeeklyPlan.scala:25)
at com.github.mgifos.workouts.model.WeeklyPlan.processed$lzycompute(WeeklyPlan.scala:28)
at com.github.mgifos.workouts.model.WeeklyPlan.processed(WeeklyPlan.scala:11)
at com.github.mgifos.workouts.model.WeeklyPlan.workouts(WeeklyPlan.scala:34)
at com.github.mgifos.workouts.Main$.run(Main.scala:117)
at com.github.mgifos.workouts.Main$.delayedEndpoint$com$github$mgifos$workouts$Main$1(Main.scala:43)
at com.github.mgifos.workouts.Main$delayedInit$body.apply(Main.scala:32)
at scala.Function0.apply$mcV$sp(Function0.scala:34)
at scala.Function0.apply$mcV$sp$(Function0.scala:34)
at scala.runtime.AbstractFunction0.apply$mcV$sp(AbstractFunction0.scala:12)
at scala.App.$anonfun$main$1$adapted(App.scala:76)
at scala.collection.immutable.List.foreach(List.scala:389)
at scala.App.main(App.scala:76)
at scala.App.main$(App.scala:74)
at com.github.mgifos.workouts.Main$.main(Main.scala:32)
at com.github.mgifos.workouts.Main.main(Main.scala)

I think the problem was colon character ":" in your workout name. I recently increased the number of characters that can be used in workout names. Can you try to import it again with the latest release 0.2.2?
https://github.com/mgifos/quick-plan/releases
Please let me know about your findings.

Sorry - I still get the same error.
I should have said, I've already tried without the ":" (I suspected that too)
I just tried importing after converting to DOS linefeeds (using perl command from https://stackoverflow.com/questions/6373888/converting-newline-formatting-from-mac-to-windows?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa) and I don't get the error any more.
I still don't get the workouts imported, but I'm getting closer

It was definitely the line feeds issue - now successfully imported my run schedule
Great tool!
I really the issue above was (at least partially) because I was trying to create a bike schedule and it doesn't recognise 'bike' as the step type!
Have to add that as a feature request now

That’s strange. I also use a Mac and successfully imported a file with LF line endings.

happy for you to close this issue - thanks


not exec event messageReceived when clic notification icon

When the notification arrives and one clicks on the notification opens the APP but when the messageReceived event is no longer running, the message received in the notification is displayed again it only shows the notification if the APP is open.

Hi @rgfpy,
Please provide more details about your platform (is it iOS or Android) and which version of plugin you use.
Also do I understand correctly that your issue is that notification is only shown if the app is open?

Hi,
The platform is Android and tested in version 7 and 6.
Yes it is only if the APP is open the event "messageReceived" is executed, but the notifications arrive correctly in notification area.

To narrow down the issue, please confirm:
If the app is not running, you can see notifications in the notification area. But "messageReceived" event is not delivered to the app if the app is being opened afterwards.

Yes the notification arrived correctly, but when opening the application from the notification area the event "messageReceived" is not ejecuted

@rgfpy thanks for reporting, we were able to track down this issue. We will post an update here when the issue will be resolved.

Good afternoon, do we have any news about the case?
best regards

@nestordavalos we are actively working on the fix now to close the issue with next release of the plugin.

The issue is fixed with 0.2.2 release.


replace java security provider

Attempted to build a working JAR from source but over the time compiling with Java 1.7 was not supported and com.sun.crypto.provider.SunJCE could not accessed anymore.


Rename SettingsLayout to BuildLayout

Rename SettingsLayout to BuildLayout

also remove FileSystemLayout

Issue: #16506
Reviewing cheatsheet
Before merging the PR, comments starting with

❌ ❓must be fixed
🤔 💅 should be fixed
💭 may be fixed
🎉 celebrate happy things

Your PR is queued. See the queue page for details.

@bot-gradle cancel

I've cancelled the pre-tested commit build.

@bot-gradle test and merge

Your PR is queued. See the queue page for details.

I've triggered a build for you. Click here to see all failures if there's any.

Pre-tested commit build failed. Click here to see all build failures.

@bot-gradle test and merge

Your PR is queued. See the queue page for details.

I've triggered a build for you. Click here to see all failures if there's any.


Adding multiple fonts

I'm facing an issue when using the font converter.
I created two fonts pokemon_font_8 and pokemon_font_12, but when I include it in my project:

#include "assets/fonts/pokemon_font_8.c"
#include "assets/fonts/pokemon_font_12.c"

I get a lot of errors:
In file included from lib/Pokegotchi/Pokegotchi.cpp:4:
lib/Pokegotchi/assets/fonts/pokemon_font_12.c:24:60: error: redefinition of 'const uint8_t glyph_bitmap []'
 static LV_ATTRIBUTE_LARGE_CONST const uint8_t glyph_bitmap[] = {
                                                            ^
In file included from lib/Pokegotchi/Pokegotchi.cpp:3:
lib/Pokegotchi/assets/fonts/pokemon_font_8.c:24:47: note: 'const uint8_t glyph_bitmap [2255]' previously defined here
 static LV_ATTRIBUTE_LARGE_CONST const uint8_t glyph_bitmap[] = {
                                               ^~~~~~~~~~~~
In file included from lib/Pokegotchi/Pokegotchi.cpp:4:
lib/Pokegotchi/assets/fonts/pokemon_font_12.c:1532:52: error: redefinition of 'const lv_font_fmt_txt_glyph_dsc_t glyph_dsc []'
 static const lv_font_fmt_txt_glyph_dsc_t glyph_dsc[] = {
                                                    ^
In file included from lib/Pokegotchi/Pokegotchi.cpp:3:
lib/Pokegotchi/assets/fonts/pokemon_font_8.c:1194:42: note: 'const lv_font_fmt_txt_glyph_dsc_t glyph_dsc [371]' previously defined here
 static const lv_font_fmt_txt_glyph_dsc_t glyph_dsc[] = {
                                          ^~~~~~~~~
In file included from lib/Pokegotchi/Pokegotchi.cpp:4:
lib/Pokegotchi/assets/fonts/pokemon_font_12.c:1910:42: error: redefinition of 'const uint8_t glyph_id_ofs_list_1 []'
 static const uint8_t glyph_id_ofs_list_1[] = {
                                          ^
In file included from lib/Pokegotchi/Pokegotchi.cpp:3:
lib/Pokegotchi/assets/fonts/pokemon_font_8.c:1572:22: note: 'const uint8_t glyph_id_ofs_list_1 [27]' previously defined here
 static const uint8_t glyph_id_ofs_list_1[] = {
                      ^~~~~~~~~~~~~~~~~~~
In file included from lib/Pokegotchi/Pokegotchi.cpp:4:
lib/Pokegotchi/assets/fonts/pokemon_font_12.c:1918:43: error: redefinition of 'const lv_font_fmt_txt_cmap_t cmaps []'
 static const lv_font_fmt_txt_cmap_t cmaps[] =
                                           ^
In file included from lib/Pokegotchi/Pokegotchi.cpp:3:
lib/Pokegotchi/assets/fonts/pokemon_font_8.c:1580:37: note: 'const lv_font_fmt_txt_cmap_t cmaps [5]' previously defined here
 static const lv_font_fmt_txt_cmap_t cmaps[] =
                                     ^~~~~
In file included from lib/Pokegotchi/Pokegotchi.cpp:4:
lib/Pokegotchi/assets/fonts/pokemon_font_12.c:1950:39: error: redefinition of 'lv_font_fmt_txt_glyph_cache_t cache'
 static  lv_font_fmt_txt_glyph_cache_t cache;
                                       ^~~~~
In file included from lib/Pokegotchi/Pokegotchi.cpp:3:
lib/Pokegotchi/assets/fonts/pokemon_font_8.c:1612:39: note: 'lv_font_fmt_txt_glyph_cache_t cache' previously declared here
 static  lv_font_fmt_txt_glyph_cache_t cache;
                                       ^~~~~
In file included from lib/Pokegotchi/Pokegotchi.cpp:4:
lib/Pokegotchi/assets/fonts/pokemon_font_12.c:1951:36: error: redefinition of 'const lv_font_fmt_txt_dsc_t font_dsc'
 static const lv_font_fmt_txt_dsc_t font_dsc = {
                                    ^~~~~~~~
In file included from lib/Pokegotchi/Pokegotchi.cpp:3:
lib/Pokegotchi/assets/fonts/pokemon_font_8.c:1613:36: note: 'const lv_font_fmt_txt_dsc_t font_dsc' previously defined here
 static const lv_font_fmt_txt_dsc_t font_dsc = {

As a workaround, I manually change static vars inside my fonts, but is it something normal, or did I miss something?
If you say me it's not normal, I can create a pull request to add the workaround I do (meaning prefixing all static vars with the font name).

.c files are NOT headers, you should not include those, build separate instead.

.c files are NOT headers, you should not include those, build separate instead.

Oh my bad, I'm new in the C ecosystem, really sorry for bothering you :pray:


Installing package "dotnet add package Azure.Security.KeyVault.Secrets" fails

Hello, Trying to following the quickstart to use the "Azure.Security.KeyVault.Secrets" but this package fails to installed on my machine with the following error :
"error: There are no versions available for the package 'Azure.Security.KeyVault.Secrets'.".
I believe to have all the pre-reqs installed. The current config of my machine is (running dotnet --info) is :
PS C:\Temp\KeyVault\key-vault-console-app> dotnet --info
.NET SDK (reflecting any global.json):
Version:   6.0.100
Commit:    9e8b04bbff
Runtime Environment:
OS Name:     Windows
OS Version:  10.0.19043
OS Platform: Windows
RID:         win10-x64
Base Path:   C:\Program Files\dotnet\sdk\6.0.100\
Host (useful for support):
Version: 6.0.0
Commit:  4822e3c3aa
.NET SDKs installed:
2.1.818 [C:\Program Files\dotnet\sdk]
3.1.302 [C:\Program Files\dotnet\sdk]
3.1.416 [C:\Program Files\dotnet\sdk]
6.0.100 [C:\Program Files\dotnet\sdk]
.NET runtimes installed:
Microsoft.AspNetCore.All 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.21 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.22 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.21 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.22 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.1.6 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 3.1.21 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 3.1.22 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 6.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
I have tried both Visual Studio Code and Visual Studio 2022 with no luck. Am I missing a pre-req ?
Thanks
Imran

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

ID: 456ee039-fa15-fe11-a002-2b96a43dd4df
Version Independent ID: d7af3367-f35d-a9b1-f0d4-b32f5355c288
Content: Quickstart - Azure Key Vault secrets client library for .NET (version 4)
Content Source: articles/key-vault/secrets/quick-create-net.md
Service: key-vault
Sub-service: secrets
GitHub Login: @msmbaldwin
Microsoft Alias: mbaldwin

@ImranKamaluddin
Thanks for your feedback! We will investigate and update as appropriate.

@ImranKamaluddin
Thanks for your time and patience!
From our documentation, you should be executing dotnet add package Azure.Security.KeyVault.Secrets, from the command shell and not Visual Studio. I was able to run this within my environment and didn't have any problems.

If you continue experiencing issues after running this within CLI/command shell, I'd recommend leveraging our Q&A forum by posting your issue there so our community, and MVPs can further assist you in troubleshooting this or finding potential workarounds.
Thank you for your time and patience throughout this issue.

@JamesTran-MSFT
Thanks for the reply. I found out what the issue was. The nuget source location was not configured. By using the following command fixed my issue :
dotnet nuget add source https://api.nuget.org/v3/index.json -n nuget.org
Above command was located from https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-nuget-add-source
I think it would be worth adding this requirement in the pre-req's section of the Quicksteps document to help users out.
Thanks for your help.
Imran


Use GOV.UK components and remove toolkit dependency

Upgrades calculators to use GOV.UK components and remove govuk_frontend_toolkit and govuk_elements dependencies.
Links:

Heroku: https://govuk-calculators-pr-721.herokuapp.com/child-benefit-tax-calculator/main
Live: https://www.gov.uk/child-benefit-tax-calculator/main

Thanks to @leenagupte for pairing brilliance.
Visual changes
Before:

After:

improved indentation
question 1 select width increase (the component only has two options - full width or use content, and using the content made it too narrow)
labels are visible on question 1 and in a few other places, see below (components have limited options for hiding labels, if any)
use hint text correctly for question 2

After (mobile):

Before:

After:

monetary inputs no longer have £ placeholder text. This is appended anyway if the value entered is correct but other errors prevent the form from being submitted

Before:

content for 'yes' is cloned from elsewhere on the page (outside of the form) using complex JS

After:

content for 'yes' is included as a partial inside the radio component's conditional option (some backend changes were needed to accommodate this, see commits)
select components used for dates, not enough room to fit them all on one line anymore so start/end are on separate lines
labels for dates are shown, not included as an option in the selects

Error states before:

Error states after:

Question 3 error states before:

Question 3 error states after:

errors are now specific to the date field(s) they represent

@kr8n3r Sorry! I didn't mean to request a re-review!


Python client subscribed connectivity_callback occasionally does not receive TRANSIENT_FAILURE

What version of gRPC and what language are you using?
Python, gRPC 1.0.4
What operating system (Linux, Windows, …) and version?
Linux, Ubuntu 14.04
What runtime / compiler are you using (e.g. python version or version of gcc)
Python 2.7.6
What did you do?
I have a need in my client to monitor the gRPC connection for connectivity issues, and I have attached a connectivity callback using the channel.subscribe() function. Each time the callback is called, I print the status to a log file.
What did you expect to see?
I expect to see a failure condition (TRANSIENT_FAILURE) in the client's connectivity callback whenever the connection is forcibly closed by the gRPC server. Most of the time, I do see this condition. For example, the following is what I see in my client log as correct behavior:
2018-02-22 01:47:04+0000 [-] 2018-02-22 01:47.04 XXX ChannelConnectivity.IDLE
2018-02-22 01:47:04+0000 [-] 2018-02-22 01:47.04 XXX ChannelConnectivity.READY
server is killed at 1:47:34
2018-02-22 01:47:34+0000 [-] 2018-02-22 01:48.19 XXX ChannelConnectivity.TRANSIENT_FAILURE
2018-02-22 01:47:34+0000 [-] 2018-02-22 01:47.34 XXX ChannelConnectivity.IDLE
What did you see instead?
Here is a client log from what I consider incorrect behavior:
2018-02-22 19:48:04+0000 [-] 2018-02-22 01:47.04 XXX ChannelConnectivity.IDLE
2018-02-22 19:48:04+0000 [-] 2018-02-22 01:47.04 XXX ChannelConnectivity.READY
server is killed at 19:50:22
2018-02-22 19:50:22+0000 [-] 2018-02-22 19:50.22 XXX ChannelConnectivity.IDLE
The connectivity callback reports IDLE, but there is no TRANSIENT_FAILURE received. I allowed the client to sit for approximately 20 minutes, and still did not observe any failure messages.

@kpayson64: does gRPC Core guarantee the kinds of behaviors on which @sbconsulting is wishing to rely? Do you see any holes in the story here?

I agree the connection state should be TRANSIENT_FAILURE, but I would consider it to be minor and cosmetic at this point.
A PR fixing this issue would be welcome.


$ne not working correctly when target field does not exist

Running queries with { xxx: { $ne: null } } does not match the functionality of mongo when the target field does not exists.
var result = sift({ a: { $ne: null }}, [{}])
// result == [{}]

In mongo this would not match any documents.
> db.test.insert([{}]);
> db.test.find({a: {$ne: null}}).count()
0

I'm afraid implementation here is not consistent.
  var result =  sift({ age: { $ne: 5 }}, [{}])
  //result == []

While in mongo it will act as follows
db.tests.insert([{}])
db.tests.find({'some.missing.path': {$ne: null}}).count()
0
db.tests.find({'some.missing.path': {$ne: true}}).count()
1


Add the Korean explanation to i18n.rst

There was no Korean explanation  about special configuration for database. So I added Korean guide for this request

Thanks @focusonmx for the pull request!
Per the CONTRIBUTING.md file displayed when you created this pull request, we need to add you to the list of approved contributors for the Mattermost project.
Please help complete the Mattermost contribution license agreement?
This is a standard procedure for many open source projects. Your form should be processed within 24 hours and reviewers for your pull request will be able to proceed.
Please let us know if you have any questions.
We are very happy to have you join our growing community! If you're not yet a member, please consider joining our Contributors community channel to meet other contributors and discuss new opportunities with the core team.

/check-cla

I'm not sure who would be the right person to review the text itself, so I'll approve this for now.


Use Shl and Shr traits for BigInteger s

Description

Uses Shl(Assign) and Shr(Assign) traits for big-integer shifting operations
While this is based on #96, I could rebase it on master. (I just forgot to switch branches before making changes lol)

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[x] Targeted PR against correct branch (main)
[x] Linked to Github issue with discussion and accepted design OR have an explanation in the PR that describes this work.
[x] Wrote unit tests (existing tests should catch breakage)
[x] Updated relevant documentation in the code
[ ] Added a relevant changelog entry to the Pending section in CHANGELOG.md
[x] Re-reviewed Files changed in the Github PR explorer

Hmm after doing some investigation, I've found that standard unsigned integers actually panic in debug mode if there's an overflow when left-shifting, or underflow when right-shifting. Our BigIntegers, on the other hand, do not, explicitly return zero in these cases.  The Rust standard library provides the core::num::Wrapping type which is supposed to provide this behaviour, but it's not clear to me whether this is necessary for us. Any thoughts? @kobigurk this relates to the findings in the audit commissioned by Celo.


< in script block breaks parsing in 2.1.0

The following example returns zero.
count((new Dom())->load('

', ['removeScripts' => false])->find('body'));

if I comment out the following lines in Dom.php
        if (trim($tag) == '')
        {
            // no tag found, invalid < found
            return $return;
        }

everything works as expected

Hey @gfeld ,
I found the issue but a proper solution is difficult to implement in version 2 of the module.
I will fix this as part of the update in version 3 but I will not implement a solution for version 2. If you would like, please feel free to create a PR with a fix for the current version.
Thank you,.


Remove backticks from sync function validation module

The backtick (`) is a reserved character in a Sync Gateway configuration file; it is used to denote the beginning and end of a multiline string as is commonly used for sync functions. Removed the errant backticks from the sync function validation module's comments to prevent the resulting syntax error ("Error reading config file config/synctos-test.json: invalid character 'p' after object key:value pair").
I have also manually verified that Sync Gateway once again launches successfully with sync functions generated by synctos.

Closing this workaround in favour of a proper solution to the bug described in issue #113.

Superseded by pull request #114.


snap_example returns RC=0 despite of errors

When I run snap_example -a2 -A , I get RC=0 and the msg
align: 1924 must be a multible of 64
In this case the RC must be non_zero
If I run snap_example_ddr -s0x1000 -e4324 -b228 -i1, I get RC=0 and the msgs
Error@: 0x00000000000010c0 Expect: 0x08edbdab79838cb2 Read: 0x0000000000000000
In this case the RC must be non_zero. If the -b needs to be a multiple of 64B, this has to be explained in the help screen.

I will fix this in "SW_rc_fix" branch

Fixed, merged into master

sorry, Jörg, please close this

working fine. Thx


Dashboard Recommendation System Integration

Integrate Trending Now and Discover New sections with ML

@wick3ds0ul just look into that 3rd section (based on your Interests) to display on the Dashboard. Then I'll collectively integrate it with ML


Python 2.7 code generator

In many enterprise environments there are restrictions on what agents can be written in… sometimes Node.js isn't allowed.

Agree. Do you think it's something you can help with? We don't know much about Python :)

Most probably. Customer's project I am on will be integrating AMQP soon, and the broader organisation is showing more and more interest in async APIs (how I discovered https://www.asyncapi.com via internal thread).
Another option is to leverage the Go initiative and support embedding aka https://docs.python.org/2/extending/extending.html.
Although my personal interests are Rust oriented, but I haven't absorbed the spec enough to see if a strongly typed approach is an advantage or a challenge.
All that said, many things on my plate…

Great. I can help you regarding the spec if you decide to contribute. Also if you want to chat join us on Slack https://async-apis-slack.herokuapp.com/

@marcb do you think this is something we can revive? I'll be glad to help as much as possible.

Python2 will be dead in 2020, I do not recomment "wasting time" into implementing a python2 generator. However a Python3 version would be extremely nice, as it is one of the most used IoT Languages.

Yeah, agree. I'd be very happy if someone can help with it. It doesn't need to be perfect. Think that most people use code generators just for prototyping ideas.


proposal: compress/lzw: add Resetter interface to allow encoders to be reused

compress/lzw encoders maintain a rather large table (64k) mapping uncompressed bytes to their compressed bits. Because the encoder requires a Close per stream they cannot be reused for multiple streams. This means that lzw creates 64k of garbage per use, which is especially apparent when encoding animation with image/gif.
While we can't easily change the API in go1 to support reuse, we can greatly reduce garbage by pooling the table parameter of encoders. I prototyped this behavior and got the following benchmarks:
name           old time/op    new time/op    delta
Encoder/1e4-8     108µs ± 1%     109µs ± 2%   +1.25%  (p=0.008 n=9+10)
Encoder/1e5-8    1.06ms ± 2%    1.11ms ± 2%   +4.15%  (p=0.000 n=10+9)
Encoder/1e6-8    10.5ms ± 2%    11.0ms ± 2%   +4.37%  (p=0.000 n=10+9)

name           old speed      new speed      delta
Encoder/1e4-8  93.0MB/s ± 1%  91.8MB/s ± 2%   -1.23%  (p=0.008 n=9+10)
Encoder/1e5-8  94.1MB/s ± 2%  90.4MB/s ± 2%   -3.98%  (p=0.000 n=10+9)
Encoder/1e6-8  95.2MB/s ± 2%  91.3MB/s ± 2%   -4.18%  (p=0.000 n=10+9)

name           old alloc/op   new alloc/op   delta
Encoder/1e4-8    77.9kB ± 0%     4.4kB ± 0%  -94.35%  (p=0.000 n=10+9)
Encoder/1e5-8    77.9kB ± 0%     4.4kB ± 0%  -94.33%  (p=0.000 n=10+10)
Encoder/1e6-8    77.9kB ± 0%     5.0kB ± 0%  -93.60%  (p=0.000 n=10+10)

name           old allocs/op  new allocs/op  delta
Encoder/1e4-8      3.00 ± 0%      4.00 ± 0%  +33.33%  (p=0.000 n=10+10)
Encoder/1e5-8      3.00 ± 0%      4.00 ± 0%  +33.33%  (p=0.000 n=10+10)
Encoder/1e6-8      3.00 ± 0%      4.00 ± 0%  +33.33%  (p=0.000 n=10+10)

(Note that these are on top of my existing CL https://go-review.googlesource.com/c/go/+/123478 that improves time/op significantly)
I don't see much use of pools in the standard library, is this not generally a good approach? Even if it is, is the memory overhead worth it for the 4% performance increase?

Pools have subtle properties that affect their performance (see #23199 and #22950). While #23199 isn't an issue here since the object is fixed size, #22950 can have adverse affect in all usages of pools in certain workloads.
That being said, why do you say:

While we can't easily change the API in go1 to support reuse

Is that because the API returns io.ReadCloser and io.WriteCloser? A similar problem existed for compress/flate and it was resolved by defining the flate.Resetter interface.

Thanks for the insight, a Resetter interface definitely seems like the way to go.
There's also the question of compress/lzw's main consumer, image/gif. As intended, this would reduce the allocation of multi-frame gif encoding significantly. (With a few internal modifications to persist the writer between calls to writeImageBlock. This wouldn't have any impact on the single-frame case, and wouldn't completely remove allocation from gif.EncodeAll.
One option would be for image/gif to have an lzw encoder Pool. Since all encoder use is internal there wouldn't be the same interface concerns as within lzw. Since there's no persistent encoder object there doesn't seem to be a good way to implement a Resetter interface like with lzw.
Maybe 64k garbage is okay for an image encoder, in which case the lzw change may be enough. (Personally I'd prefer that image/gif be near 0 quiescent allocation but that's for a niche use case)

Stumbled on this while looking at some heap profiles generated from using https://github.com/hashicorp/memberlist. Adding the Resetter interface works for the general use-case of the library. Will look into sending a CL.

We clearly did a bad job with all the compress APIs. We should not have returned interfaces from the constructors. For example we got zlib.NewWriter correct - it returns a *zlib.Writer. But we got zlib.Reader wrong - it returns an io.ReadCloser. When we wanted to add a Reset method to the underlying reader, we had no way to expose it, so we added the zlib.Resetter interface with a guarantee that the resulting io.ReadCloser also implemented zlib.Resetter.
That's being proposed here for lzw, but on the Writer side, not the Reader side. It bothers me a bit that flate.Resetter and zlib.Resetter are both Read-side Resetters while this would be a Write-side Resetter. What happens when we want to Reset the lzw reader as well?
An alternative to defining these new interfaces would be to define the actual concrete type structs - *lzw.Reader and *lzw.Writer - and then document that the results from lzw.NewReader and lzw.NewWriter are guaranteed to be type-assert-able to those actual concrete types. Then any new methods we need could be added there without any new interfaces, and in particular without a different interface for reading and writing and a different interface for each new method.
Any thoughts about that alternative (defining the Reader and Writer structs for the package and documenting that the interfaces can be type-asserted to them, and then adding Reset as struct methods)?

We clearly did a bad job with all the compress APIs. We should not have returned interfaces from the constructors. For example we got zlib.NewWriter correct - it returns a *zlib.Writer. But we got zlib.Reader wrong - it returns an io.ReadCloser. When we wanted to add a Reset method to the underlying reader, we had no way to expose it, so we added the zlib.Resetter interface with a guarantee that the resulting io.ReadCloser also implemented zlib.Resetter.
That's being proposed here for lzw, but on the Writer side, not the Reader side. It bothers me a bit that flate.Resetter and zlib.Resetter are both Read-side Resetters while this would be a Write-side Resetter. What happens when we want to Reset the lzw reader as well?
An alternative to defining these new interfaces would be to define the actual concrete type structs - *lzw.Reader and *lzw.Writer - and then document that the results from lzw.NewReader and lzw.NewWriter are guaranteed to be type-assert-able to those actual concrete types. Then any new methods we need could be added there without any new interfaces, and in particular without a different interface for reading and writing and a different interface for each new method.
Any thoughts about that alternative (defining the Reader and Writer structs for the package and documenting that the interfaces can be type-asserted to them, and then adding Reset as struct methods)?

/cc @nigeltao

/cc @nigeltao

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

For completeness, I can imagine two other (potentially poor) approaches:

Create new constructors that return the concrete structs directly. This has the advantage of no implicit type guarantees to be documented, though there is the obvious downside of an additional method.
Allow direct instantiation of the concrete structs (similar to bytes.Buffer). This removes the need for an additional method or type cast, but there is no way to allow setting fields at construction without making them mutable, which could lead to nonsensical states.

For completeness, I can imagine two other (potentially poor) approaches:

Create new constructors that return the concrete structs directly. This has the advantage of no implicit type guarantees to be documented, though there is the obvious downside of an additional method.
Allow direct instantiation of the concrete structs (similar to bytes.Buffer). This removes the need for an additional method or type cast, but there is no way to allow setting fields at construction without making them mutable, which could lead to nonsensical states.

It's true that if we have structs that can be declared and initialized (by the Reset method) they would stand alone.
It seems like we should probably still define that the functions also return those implementations.
So the proposal would be:
// guarantee to return a *Reader
func NewReader(r io.Reader, order Order, litWidth int) io.ReadCloser

// guarantee to return a *Writer
func NewWriter(w io.Writer, order Order, litWidth int) io.WriteCloser

type Reader struct { ... unexported ... }
func (r *Reader) Reset(input io.Reader, order Order, litWidth int)
func (r *Reader) Read([]byte) (int, error)
func (r *Reader) Close() error

type Writer struct { ... unexported ... }
func (w *Writer) Reset(output io.Writer, order Order, litWidth int)
func (w *Writer) Write([]byte) (int, error)
func (w *Writer) Close() error

Any objections to this approach?

It's true that if we have structs that can be declared and initialized (by the Reset method) they would stand alone.
It seems like we should probably still define that the functions also return those implementations.
So the proposal would be:
// guarantee to return a *Reader
func NewReader(r io.Reader, order Order, litWidth int) io.ReadCloser

// guarantee to return a *Writer
func NewWriter(w io.Writer, order Order, litWidth int) io.WriteCloser

type Reader struct { ... unexported ... }
func (r *Reader) Reset(input io.Reader, order Order, litWidth int)
func (r *Reader) Read([]byte) (int, error)
func (r *Reader) Close() error

type Writer struct { ... unexported ... }
func (w *Writer) Reset(output io.Writer, order Order, litWidth int)
func (w *Writer) Write([]byte) (int, error)
func (w *Writer) Close() error

Any objections to this approach?

The asymmetry with compress/flate is unfortunate, but it's better than defining WriterRestter and ReaderResetter interface types.

The asymmetry with compress/flate is unfortunate, but it's better than defining WriterRestter and ReaderResetter interface types.

@rsc why not return a *Writer and guarantee that it always fulfills WriteCloser? That would be compatible and usable without type assertion?

@rsc why not return a *Writer and guarantee that it always fulfills WriteCloser? That would be compatible and usable without type assertion?

@andig Would this technically violate the compatibility guarantee, since a function variable/argument typed for the current signature would no longer accept the new signature? E.g.:
var f func(r io.Reader, order lzw.Order, litWidth int) io.ReadCloser = lzw.NewReader
would break under this proposed type signature.

@andig Would this technically violate the compatibility guarantee, since a function variable/argument typed for the current signature would no longer accept the new signature? E.g.:
var f func(r io.Reader, order lzw.Order, litWidth int) io.ReadCloser = lzw.NewReader
would break under this proposed type signature.

Guess it would 😣

Guess it would 😣

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

While playing around with this I noticed that NewReader/NewWriter currently return a separate struct (errWriteCloser) on errors, which returns an error later when written/read. This doesn't necessarily require a change to the above APIs, but the separate struct will need to be incorporated into the Reader/Writer struct as an err struct member or similar, so that Reset can set errors on the struct (since it can't return this pseudo-reader/writer).

While playing around with this I noticed that NewReader/NewWriter currently return a separate struct (errWriteCloser) on errors, which returns an error later when written/read. This doesn't necessarily require a change to the above APIs, but the separate struct will need to be incorporated into the Reader/Writer struct as an err struct member or similar, so that Reset can set errors on the struct (since it can't return this pseudo-reader/writer).

@rsc - Just wanted to clarify a small detail on the Reset methods: do we want to pass the order and litWidth to Reset or just let them be whatever they were when the Reader/Writer was created?
It seems like there is some inconsistency amongst the various Reset APIs on this one.

gzip.(*Writer).Reset does not take the compression level.
flate.(*Writer).Reset does not take the compression level and dictionary.
But flate.Resetter interface does take the dictionary.

@rsc - Just wanted to clarify a small detail on the Reset methods: do we want to pass the order and litWidth to Reset or just let them be whatever they were when the Reader/Writer was created?
It seems like there is some inconsistency amongst the various Reset APIs on this one.

gzip.(*Writer).Reset does not take the compression level.
flate.(*Writer).Reset does not take the compression level and dictionary.
But flate.Resetter interface does take the dictionary.

In my opinion, it was a mistake for gzip and flate to not take in more options. There have been times where I needed to reset them with different settings and was unable to. I think we should avoid the same mistake when adding reset functionality to lzw.

In my opinion, it was a mistake for gzip and flate to not take in more options. There have been times where I needed to reset them with different settings and was unable to. I think we should avoid the same mistake when adding reset functionality to lzw.

To @dsnet's point, removing these parameters from Reset would also prohibit direct instantiation (then Reseting) the structs (unless these values had some default value)

To @dsnet's point, removing these parameters from Reset would also prohibit direct instantiation (then Reseting) the structs (unless these values had some default value)

Any objections to this approach?

LGTM.

To answer @agnivade's comment, it sounds like @dsnet and @nigeltao agree to include all the options in Reset, as in the comment above.

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group


Inherit link/button styles from outside the shadow dom

I have a component that renders either a link or a button that when clicked, displays a popup.
It would be useful if the link and button inherits the styling from higher up the DOM, outside of the component, so the link or button automatically uses the same styles as the page it is being added to.
Is this possible or does this go against the very idea of encapsulation and web components?

Yes this is possible! You can do this in a few ways. First, you can write a property called createRenderRoot within your component, and return this:
class LightDom extends LitElement {
  render() {
    return html`

This template renders without shadow DOM.

    `;
  }
  createRenderRoot() {
  /**
   * Render template without shadow DOM. Note that shadow DOM features like
   * encapsulated CSS and slots are unavailable.
   */
    return this;
  }
}

(Note that I stole this example from the lit website)
However, as you can see, you loose the ability to use slots and encapsulated css, which is not cool
An alternative method would be to import static css from outside the component, as
you can see here: https://lit.dev/docs/components/styles/#sharing-styles
However, that requires defining a css template, which is a pain to keep doing. What I would do is use css inheritance: https://lit.dev/docs/components/styles/#inheritance
What this means is that certain css properties, include all css custom variables, make it past the shadowdom. This makes it easy to change certain parts of your custom element easily. You can even assign variables to your individual component and interface with an exterior variable to maintain encapsulation. For example:

  <custom-component class="is-pressed"></custom-component>
</body