v1.7 backports 2020-09-17

#12675 -- fix(12664): initialize gops in RootCmd execution function (@fristonio)

Minor conflict due to cmdref not being present. Easily resolved.

#13120 -- logging_fix: Adding logs in a structured way (@chowmean)
#13141 -- operator: fix invocation with --help option (@tklauser)

Minor conflict due to cmdref not being present. Easily resolved.

#13044 -- contrib: Add release helper scripts for preparing micro releases (@joestringer)

Dropped docs / gh template changes from this commit.

#13190 -- service: Fix panic when restoring services with enable-health-check-nodeport: false (@gandro)

Minor conflict in the first patch as v1.7 didn't have backend filtering.
Second patch in pkg/service/service_test.go had several conflicts, reworked the tests against v1.7 APIs and dropped test code that attempts to reference variables or functions that don't exist

#12925 -- endpoint: Update proxy policy after adding redirects (@jrajahalme)

Skipped backporting commit a57e2aad56eedb69079f94c8e1829486623ff9ce as
there was some dependency on sql proxy tests which is not present in v1.7.

#13205 -- identity: Fix user-space security identity lookup in cluster mesh (@gandro)

Extra commit at end to fix the cmdref from previous backports breaking it.
Skipped:

#13101 -- docs: Document restart-ginkgo CI-trigger phrase (@pchaigno)

I'm not sure which things we're trying to document in the older branch
there, there's lots of changes to these phrases. Updating v1.8 makes
sense to me, but I'm less sure about v1.6/v1.7. Do backporters often
refer to these docs on the older branches?

#13159 -- docs/minikube: Update the step for minikube 1.12.1+ (@sayboras)

The doc doesn't exist in the v1.7 tree. Do we need to backport this PR
to v1.7?

Once this PR is merged, you can update the PR labels via:
$ for pr in 12675 13120 13141 13044 13190 12925 13205; do contrib/backporting/set-labels.py $pr done 1.7; done

never-tell-me-the-odds

#13159 -- docs/minikube: Update the step for minikube 1.12.1+ (@sayboras)
The doc doesn't exist in the v1.7 tree. Do we need to backport this PR to v1.7?

I think we can skip this one, as the related PR https://github.com/cilium/cilium/pull/12262 was backported to 1.8 branch only.

#13101 -- docs: Document restart-ginkgo CI-trigger phrase (@pchaigno)
I'm not sure which things we're trying to document in the older branch
there, there's lots of changes to these phrases. Updating v1.8 makes
sense to me, but I'm less sure about v1.6/v1.7. Do backporters often
refer to these docs on the older branches?

The goal of that PR is to document restart-ginkgo, which is useful in backport PRs in particular. I marked it for backport in v1.6 and v1.7 because I thought backporter may be looking into these versions of the documentation for the specific trigger phrases. v1.6 is clearly excessive; maybe v1.7 still makes sense?

@pchaigno Do you just intend to backport the line with restart-ginkgo? Because the docs at the moment already point to test-me-please towards the same jenkins job link. I wasn't sure if that's still correct. Due to the conflicts, I wasn't sure if I should just backport the whole set of commands or only the restart-ginkgo command, and whether to remove the current test-me-please command or not.
Either way I think this is not pressing so we can continue the discussion & figure out what makes sense for v1.7 backport, docs will be updated whenever we do that backport but I don't want to hold up real fixes on that.

Because the docs at the moment already point to test-me-please towards the same jenkins job link. I wasn't sure if that's still correct.

That doesn't look correct to me :thinking:

Either way I think this is not pressing so we can continue the discussion & figure out what makes sense for v1.7 backport, docs will be updated whenever we do that backport but I don't want to hold up real fixes on that.

Yep, makes sense. I've set a reminder to resolve this on Slack at a later time.


Plugin Tinker not work

Good day!
How can I use the Tinker plugin in Laravel with Devilbox?

Good day as well @morsergen,
DB_HOST should be mysql not <IP_ADDRESS>

/etc/hosts - <IP_ADDRESS> mysql

Good day  @morsergen,
If I'm inside the PHP container, it does find the mysql host without having to specify it in /etc/hosts:
resolving hostname (inside container)
<EMAIL_ADDRESS>in /shared/httpd $ ping mysql
PING mysql (<IP_ADDRESS>) 56(84) bytes of data.
64 bytes from devilbox2_mysql_1.devilbox2_app_net (<IP_ADDRESS>): icmp_seq=1 ttl=64 time=0.262 ms

/etc/hosts (inside container)
<EMAIL_ADDRESS>in /shared/httpd $ cat /etc/hosts
<IP_ADDRESS>       localhost
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
<IP_ADDRESS>    docker.for.lin.host.internal
<IP_ADDRESS>    docker.for.lin.localhost
<IP_ADDRESS>   php

If you think this is a bug, I would suggest to re-create the ticket with the bug report template and fill out all steps especially the "how to reproduce" description (which should also include your Tinker setup and the trigger that caused the error message), otherwise there is no real way to support you on this, except for guessing.

Good day @cytopia
Thanks for answers.
I did not quite understand...
I do not add anything to the hosts file inside the container.
Here are my screenshots:

Inside the container in the terminal, the tinker works without problems.

Outside the container, PHPStrom cannot connect to the database. It was outside that I was trying to add / etc / hosts - <IP_ADDRESS> mysql
But it doesn't work with this record and without it.
What am I doing wrong? And as far as I can see, the tinker has no settings.
Thank you

I can connect to the Devilbox DB from my host system just fine:
host> mysql -uroot --host=<IP_ADDRESS>

Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 4
Server version: 10.5.8-MariaDB-1:10.5.8+maria~focal-log mariadb.org binary distribution

If the above works for you (from your host) it is a tinker issue.
If the above does not work for you (you have a permission issue with the root user of the database)

the connection works from the container, there is no connection outside the container
I don't understand how to use tinker in PHPStorm
please, help

Follow the instructions from your second screenshot to test the DB from your host

Good day @cytopia
Thanks for answers.
I install mysql to my host

but when I put the settings DB_HOST in .env:
<IP_ADDRESS>

<IP_ADDRESS>

mysql

@morsergen So MySQL connectivity from Devilbox side of things works fine on your machine.
Now all that's left is to play around with Tinker and get it setup correctly. I'd suggest to ask in their Forum for further help.

OK thanks


helm repo add svc-cat - is not a valid chart repository or cannot be reached

Bug Report
What happened:
Running:
 helm repo add svc-cat https://svc-catalog-charts.storage.googleapis.com

looks like "https://svc-catalog-charts.storage.googleapis.com" is not a valid chart repository or cannot be reached: failed to fetch https://svc-catalog-charts.storage.googleapis.com/index.yaml : 403 Forbidden**

How to reproduce it (as minimally and precisely as possible):
helm repo add svc-cat https://svc-catalog-charts.storage.googleapis.com

Duplicate of #2869
Documentation fixed in #2875

Duplicate of #2869
Documentation fixed in #2875


Change DefaultTagHelperContent to be smart about single content entries.

Today TagHelperContents always allocate their underlying buffer even though they typically only ever have a single entry. Added a field to enable us to only allocate the backing buffer when we absolutely need to.
Removed IsEmpty from TagHelperContent since it was not used in any of our TagHelpers for simplification. Changed IsWhiteSpace naming to be IsEmptyOrWhiteSpace since it can be used to indicate either state.
Updated tests.

Before:

After:

Result: 4.1% overall reduction in allocations.
#621

/cc @rynowak

:watch:

:up: :date:

Will be getting this in tomorrow unless there are additional comments.

Will be getting this in tomorrow unless there are additional comments.

Huh? There's an API change in here that needs approval and a signed-off MVC reaction PR.

:watch: also waiting for https://github.com/aspnet/Razor/pull/728#discussion-diff-58301375 fix.

Talked with @DamianEdwards offline. He approved the public API surface change here and its approval for RC2.

:up: :date:

:shipit: once you've got the MVC reaction PR ready.


Add information to README.md to for building

It would be great if you could add some information on the procedure for building this package to the README.md
I tried various cmake and just commands but none seemed to be the correct.
thanks!

hey @timmaffett
You do not need to build it specially. just install the package, the rest is done via podspec and cmake commands
Just add the package as dependency and use it.

like shown in the example folder

@buehler  I was attempting to view/run the example.  The steps I followed did not allow me to view/run the example:
(using vscode environment, windows platform (although I could try mac), running on android emulator, and i am on the master branch of flutter)
(I just RE-did these steps to verify (fresh git clone, etc.) - the error still occurs)

I cloned the repo    git clone https://github.com/buehler/flutter_pdfium.git
flutter pub get       (in root or package)
select example\main.dart   (and select run without debugging)

And the build process goes and errors out because
../lib/flutter_pdfium.dart:6:8: Error: Error when reading '../lib/src/pdfium.dart': The system cannot find the path specified.
The lib/src/pdfium.dart is not found - so it did not get generated by podspec or cmake commands.
Full output of build in vscode:
Resolving dependencies...
Downloading packages...
  collection 1.18.0 (1.19.0 available)
  material_color_utilities 0.11.1 (0.12.0 available)
Got dependencies!
2 packages have newer versions incompatible with dependency constraints.
Try `flutter pub outdated` for more information.
Launching lib\main.dart on sdk gphone x86 in debug mode...
../lib/flutter_pdfium.dart:6:8: Error: Error when reading '../lib/src/pdfium.dart': The system cannot find the path specified.

import 'src/pdfium.dart';
       ^
../lib/flutter_pdfium.dart:8:1: Error: Error when reading '../lib/src/pdfium.dart': The system cannot find the path specified.

export 'src/pdfium.dart';
^
lib/main.dart:34:8: Error: Type 'Pdfium' not found.
  late Pdfium pdfium;
       ^^^^^^
lib/main.dart:35:3: Error: Type 'FPDF_DOCUMENT' not found.
  FPDF_DOCUMENT? document;
  ^^^^^^^^^^^^^
../lib/flutter_pdfium.dart:13:1: Error: Type 'Pdfium' not found.
Pdfium createInitializedLibrary() {
^^^^^^
lib/main.dart:34:8: Error: 'Pdfium' isn't a type.
  late Pdfium pdfium;
       ^^^^^^
lib/main.dart:35:3: Error: 'FPDF_DOCUMENT' isn't a type.
  FPDF_DOCUMENT? document;
  ^^^^^^^^^^^^^
lib/main.dart:120:33: Error: 'FS_SIZEF_' isn't a type.
      final sizePointer = arena<FS_SIZEF_>();
                                ^^^^^^^^^
lib/main.dart:123:31: Error: The property 'ref' is defined in multiple extensions for 'Pointer<invalid-type>' and neither is more specific.
 - 'Pointer' is from 'dart:ffi'.
Try using an explicit extension application of the wanted extension or hiding unwanted extensions from scope.
      return Size(sizePointer.ref.width, sizePointer.ref.height);
                              ^^^
org-dartlang-sdk:///flutter/third_party/dart/sdk/lib/_internal/vm/lib/ffi_patch.dart:1241:9: Context: This is one of the extension members.
  T get ref =>
        ^^^
org-dartlang-sdk:///flutter/third_party/dart/sdk/lib/_internal/vm/lib/ffi_patch.dart:1272:9: Context: This is one of the extension members.
  T get ref =>
        ^^^
lib/main.dart:123:54: Error: The property 'ref' is defined in multiple extensions for 'Pointer<invalid-type>' and neither is more specific.
 - 'Pointer' is from 'dart:ffi'.
Try using an explicit extension application of the wanted extension or hiding unwanted extensions from scope.
      return Size(sizePointer.ref.width, sizePointer.ref.height);
                                                     ^^^
org-dartlang-sdk:///flutter/third_party/dart/sdk/lib/_internal/vm/lib/ffi_patch.dart:1241:9: Context: This is one of the extension members.
  T get ref =>
        ^^^
org-dartlang-sdk:///flutter/third_party/dart/sdk/lib/_internal/vm/lib/ffi_patch.dart:1272:9: Context: This is one of the extension members.
  T get ref =>
        ^^^
../lib/flutter_pdfium.dart:22:15: Error: Undefined name 'Pdfium'.
  final lib = Pdfium.fromLookup(lookup);
              ^^^^^^
../lib/flutter_pdfium.dart:25:33: Error: 'FPDF_LIBRARY_CONFIG' isn't a type.
    final configPointer = arena<FPDF_LIBRARY_CONFIG>();
                                ^^^^^^^^^^^^^^^^^^^
../lib/flutter_pdfium.dart:26:19: Error: The property 'ref' is defined in multiple extensions for 'Pointer<invalid-type>' and neither is more specific.
 - 'Pointer' is from 'dart:ffi'.
Try using an explicit extension application of the wanted extension or hiding unwanted extensions from scope.
    configPointer.ref.version = 2;
                  ^^^
org-dartlang-sdk:///flutter/third_party/dart/sdk/lib/_internal/vm/lib/ffi_patch.dart:1241:9: Context: This is one of the extension members.
  T get ref =>
        ^^^
org-dartlang-sdk:///flutter/third_party/dart/sdk/lib/_internal/vm/lib/ffi_patch.dart:1272:9: Context: This is one of the extension members.
  T get ref =>
        ^^^
../lib/flutter_pdfium.dart:27:19: Error: The property 'ref' is defined in multiple extensions for 'Pointer<invalid-type>' and neither is more specific.
 - 'Pointer' is from 'dart:ffi'.
Try using an explicit extension application of the wanted extension or hiding unwanted extensions from scope.
    configPointer.ref.m_pUserFontPaths = ffi.nullptr;
                  ^^^
org-dartlang-sdk:///flutter/third_party/dart/sdk/lib/_internal/vm/lib/ffi_patch.dart:1241:9: Context: This is one of the extension members.
  T get ref =>
        ^^^
org-dartlang-sdk:///flutter/third_party/dart/sdk/lib/_internal/vm/lib/ffi_patch.dart:1272:9: Context: This is one of the extension members.
  T get ref =>
        ^^^
../lib/flutter_pdfium.dart:28:19: Error: The property 'ref' is defined in multiple extensions for 'Pointer<invalid-type>' and neither is more specific.
 - 'Pointer' is from 'dart:ffi'.
Try using an explicit extension application of the wanted extension or hiding unwanted extensions from scope.
    configPointer.ref.m_pIsolate = ffi.nullptr;
                  ^^^
org-dartlang-sdk:///flutter/third_party/dart/sdk/lib/_internal/vm/lib/ffi_patch.dart:1241:9: Context: This is one of the extension members.
  T get ref =>
        ^^^
org-dartlang-sdk:///flutter/third_party/dart/sdk/lib/_internal/vm/lib/ffi_patch.dart:1272:9: Context: This is one of the extension members.
  T get ref =>
        ^^^
../lib/flutter_pdfium.dart:29:19: Error: The property 'ref' is defined in multiple extensions for 'Pointer<invalid-type>' and neither is more specific.
 - 'Pointer' is from 'dart:ffi'.
Try using an explicit extension application of the wanted extension or hiding unwanted extensions from scope.
    configPointer.ref.m_v8EmbedderSlot = 0;
                  ^^^
org-dartlang-sdk:///flutter/third_party/dart/sdk/lib/_internal/vm/lib/ffi_patch.dart:1241:9: Context: This is one of the extension members.
  T get ref =>
        ^^^
org-dartlang-sdk:///flutter/third_party/dart/sdk/lib/_internal/vm/lib/ffi_patch.dart:1272:9: Context: This is one of the extension members.
  T get ref =>
        ^^^
../lib/flutter_pdfium.dart:25:32: Error: Expected type 'invalid-type' to be a valid and instantiated subtype of 'NativeType'.
    final configPointer = arena<FPDF_LIBRARY_CONFIG>();
                               ^
lib/main.dart:120:32: Error: Expected type 'invalid-type' to be a valid and instantiated subtype of 'NativeType'.
      final sizePointer = arena<FS_SIZEF_>();
                               ^
Target kernel_snapshot_program failed: Exception

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:compileFlutterBuildDebug'.
> Process 'command 'C:\src\flutter\bin\flutter.bat'' finished with non-zero exit value 1

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 1m 49s
Error: Gradle task assembleDebug failed with exit code 1

Exited (1).

I filed a new issue, with a more descriptive title, as this one is closed and I could not re-open it.


DEVELOPER GUIDE

Coverage remained the same at 92.233% when pulling 14f795b3a445ba74bc9dd00d3e14ae556c7f8f18 on Lenaldnwj:developerGuide into 9b71812b3f667acd95305101d35c96b951375556 on CS2103AUG2017-T16-B2:master.

Coverage remained the same at 92.233% when pulling 0fb03c2bf54c0fb4996edcf1ec19267a82d2571d on Lenaldnwj:developerGuide into 9b71812b3f667acd95305101d35c96b951375556 on CS2103AUG2017-T16-B2:master.

Coverage remained the same at 92.233% when pulling 0fb03c2bf54c0fb4996edcf1ec19267a82d2571d on Lenaldnwj:developerGuide into 9b71812b3f667acd95305101d35c96b951375556 on CS2103AUG2017-T16-B2:master.

Coverage remained the same at 92.233% when pulling f9967bb15d9901cb372dce547aec1aef144633e3 on Lenaldnwj:developerGuide into 9b71812b3f667acd95305101d35c96b951375556 on CS2103AUG2017-T16-B2:master.

Coverage remained the same at 92.233% when pulling 00e2cfdd47cdc6cba88e958100c0ab4a66e87981 on Lenaldnwj:developerGuide into 9b71812b3f667acd95305101d35c96b951375556 on CS2103AUG2017-T16-B2:master.

Coverage remained the same at 92.233% when pulling 4404a3ca304fa0f772aaddcedf53fe94ab50fbf4 on Lenaldnwj:developerGuide into 9b71812b3f667acd95305101d35c96b951375556 on CS2103AUG2017-T16-B2:master.

Coverage remained the same at 92.233% when pulling 4404a3ca304fa0f772aaddcedf53fe94ab50fbf4 on Lenaldnwj:developerGuide into 9b71812b3f667acd95305101d35c96b951375556 on CS2103AUG2017-T16-B2:master.

Coverage remained the same at 92.233% when pulling 63a46cae15887b546fe34fcd005135babe972db2 on Lenaldnwj:developerGuide into 9b71812b3f667acd95305101d35c96b951375556 on CS2103AUG2017-T16-B2:master.

Coverage remained the same at 92.233% when pulling 1be5065805966d5a3dcc8147f838fcf6a6ea040f on Lenaldnwj:developerGuide into 9b71812b3f667acd95305101d35c96b951375556 on CS2103AUG2017-T16-B2:master.

Coverage remained the same at 92.233% when pulling dff0e4403d68f70f843d412a3e8fd6b60d87f225 on Lenaldnwj:developerGuide into 9b71812b3f667acd95305101d35c96b951375556 on CS2103AUG2017-T16-B2:master.

Coverage remained the same at 92.233% when pulling 2cb923d21f1f80e824be89e754cb15a2261d5339 on Lenaldnwj:developerGuide into 9b71812b3f667acd95305101d35c96b951375556 on CS2103AUG2017-T16-B2:master.

Coverage remained the same at 92.233% when pulling ba702e301758e40058b12fb58af34d36bbfb70cd on Lenaldnwj:developerGuide into 9b71812b3f667acd95305101d35c96b951375556 on CS2103AUG2017-T16-B2:master.


mesoparticles2D.py has some weird artifacts

Looks like a copy/paste or search/replace gone wrong?
"""
This is the normal procedure, however, quickFill now automatesit!
This is the n
This is the n# insert grains until target volume fraction achieved
This is the nwhile volume_fraction <= 0.4:
This is the n    # insert randomly into a specified region as material 1 for now
This is the n    g.insertRandomly(m,2,ybounds=[1.e-3,3.e-3],nooverlap=True)
This is the n    # add Grain instance to Ensemble
This is the n    group.add(g)
This is the n    # calculate the new volume fraction in the new region
    prev_vfrac = volume_fraction
    volume_fraction = m.vfrac(ybounds=[1.e-3,3.e-3])
"""

Yes this does seem odd... Not sure how this has happened

I'll look into it when I have a chance


Hitting rate limit for "NicGet"

What happened:
We have ~150 node cluster running Kubernetes (the hard way). We are using Azure LB managed by Kubernetes controller manager. It works fine when we are only leveraging the public IP LB, but once we create a private IP LB Kubernetes service it creates extra queries for all the NICs of the nodes in the backend pool of the internal loadbalancer (~extra 150). This causes us to hit the rate limit on NicGet. Here is an example of an error message we get from kubernetes when it fails to create the LB:
rate limited(read) for operation:NicGet", ensure(namespace/haproxy-tcp): backendPoolID(/subscriptions/ID/resourceGroups/NAME/providers/Microsoft.Network/loadBalancers/NAME/backendAddressPools/NAME) - failed to ensure host inpool: "azure - cloud provider

The azure.json cloud provider config that we are using with Kubernetes is
  "cloudProviderBackoff": true,
  "cloudProviderBackoffDuration": 6,
  "cloudProviderBackoffExponent": 1.5,
  "cloudProviderBackoffJitter": 1,
  "cloudProviderBackoffRetries": 6,
  "cloudProviderRateLimit": true,
  "cloudProviderRateLimitBucket": 200,
  "cloudProviderRateLimitBucketWrite": 100,
  "cloudProviderRateLimitQPS": 25,
  "cloudProviderRateLimitQPSWrite": 10

We have plans to move to 400 nodes support in future, so we need to find a way around this limitation.
What you expected to happen:
Being able to use a private IP and public IP LB without hitting the rate limit
How to reproduce it:
Anything else we need to know?:
Environment:

Kubernetes version (use kubectl version): 1.13.5
OS (e.g. from /etc/os-release): CentOS 7.5
Kernel (e.g. uname -a): 3.10.0-862.14.4.el7.x86_64
Install tools: internal tools
Others:

The rate limit is taking effect for all ARM APIs: cloudProviderRateLimitQPS for read and cloudProviderRateLimitQPSWrite for write.
@lumi017  could you set up a bigger cloudProviderRateLimitQPS?

@feiskyer what would be your proposed configuration?

@feiskyer My questions would be: why are we asking the client (CCM) to set the throttle itself rather than letting the server (ARM) throttle the client (CCM)?
When we check the ARM throttling limits, we see that the throttling limit for 1 ARM instance is 12K reads and 1.2K writes per hour - however, most requests are received by different instances, so the upper limit would be much higher - as the documentation states: https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-manager-request-limits

@djsly I'd suggest setting it with number of nodes. Disable cloudProviderRateLimit is another option.
@MarcosMMartinez cloudProviderRateLimit is provided for client side rate limiting, and CCM also honors server side throttling by exponential backoff. cloudProviderRateLimit is needed because there're usually other components also interacting with ARM API, hence CCM should ensure it doesn't eat up all the rate limits.


Request: Invert color maps

Sometimes I'll want to use a color map (e.g. diverging) but I want the map reversed.  As a workaround I'm creating a new column with the values reversed or negated that I only use for the color attribute, but it'd be handy if something like color(c:diverging:reverse) were supported to avoid the need for this.  I don't see anything in the docs that lets one invert colors the way one can invert axes, sorts, etc.

Just figured out I can do color(c:[reds,blues]) as a workaround.

Yes, Brunel requires that if you don't like the default mappings, you must specify them pretty completely.


Use png for ade20k

Since we already have .png support, we can enable .png for ADE20k. Benefits of using .png

input data: with .png we can use lossless resized data instead of lossy .jpeg
label: with .png we can have small data size, previously, we used raw 512x512x1 data.

See #695 for related discussion.

@freedomtan to add corresponding description to the mobile_open repo

The CI tests failed because it still use the old raw groundtruth.
I uploaded the new PNG based groundtruth here: https://github.com/mlcommons/mobile_models/pull/59
Please update the link after https://github.com/mlcommons/mobile_models/pull/59 is merged.
https://github.com/mlcommons/mobile_app_open/blob/31647b7c5228b663376a547ea6d7e2a47ddb7e36/flutter/assets/tasks.pbtxt#L99


Keeping the source tidy, tested and documented

While it is most fun to dig in and develop new features it is equally, if not more, important to keep the code clean, the tests unforgiving and the documentation clear.
If you want to earn eternal fame and glory any help looking into

Module descriptions, i.e. what the current file / package does
Escalating file size, a file spanning hundreds of lines should likely be broken apart into several sub modules.
Method documentation should include parameter descriptions and a short overview of what its purpose is. Interactive style examples are great to have as well.
Documentation is rendered with Sphinx and can utilize a range of nice mark up features which can be used to make it easier to digest, i.e. code block highlighting and cross referencing.
Any PEP8 violations.
Lack of code coverage
Lack of edge case tests exercising input sizes and encodings
Messy imports. Should preferably be uniform and ordered alphabetically.
Widespead py 2/3 compatability clauses that should be moved into a new oauthlib.compat
And anything else you can think of to improve code and docs health

will be greatly appreciated =)

It may be best if a "contributors guide" was added so that these rules are explicitly spelled out in the code so there is no lack of clarity.
For example, its common to run a python linter tool such as flake8; Maybe that should be the official standard for the project?


Vision: Fixed defect when image is present multiple times during pred_proba

Issue #, if available:
Description of changes:

Fixed bug causing incorrect prediction rows to be output from predict_proba if the same image is present in multiple rows.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Job PR-1206-1 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-1206/1/index.html


Add Minio monitoring with Prometheus

Fixes https://github.com/minio/minio/issues/5914

It would be better to fix the doc on our server?. Are you fixing that as well ?

Are you fixing that as well ?

Basically here is how I am thinking .. monitoring is an integral feature of minio and cookbook is only meant to have documentation where we are talking about minio and it's usability with other applications. Since monitoring Minio might actually have multiple Solutions not just Prometheus it makes sense to actually keep it under minio documentation in my opinion. Will wait for @deekoder opinion as well.

it makes sense to actually keep it under minio documentation in my opinion.

I agree..

It feels like more of a recipe for me. If you can switch to any monitoring tool/product of the user's choice, its not a core minio thing. However @harshavardhana  is correct in that the section 'minio list of metrics exposed' and 'minio config.yaml' changes should be integrated into minio docs.

@nitisht  can you fix the doc on the server to be generic. We can called it Minio Monitoring Guide. And then link it how to use Prometheus to monitor minio, recipe.

okay, will do @deekoder .

This PR (https://github.com/minio/minio/pull/5923) is now updated with a top level doc @deekoder , PTAL


Figure out how to invite non-profits - Slick Sheet

Invite them to talk about their mission and challenges
Educate on their issue

Google doc shared on flowdock.


v0.9.2: Splitter/Vision: No indication of an error/exception in Async mode.

If the Document, Image or Images() objects are instantiated in async mode (ehandler=....), there is no indication (i.e., event handler) if an error occurs.
Recommendation is to either:

use polymorphism for ehandler and have optional second argument for exception handler, or
or polymorphism for target event handler and have optional second argument for the exception handling.

done in v0.9.3


A crash when using delay instruction with non-dt units

Information

Qiskit Terra version: master
Python version: 3.8
Operating system: Linux

What is the current behavior?
delay instruction won't work with units that are not dt. This happens in the master branch but not in the stable branch. The issue lies in the assemble function.
Steps to reproduce the problem
from qiskit import QuantumCircuit, execute
from qiskit.providers.aer import QasmSimulator

sim = QasmSimulator()

circ = QuantumCircuit(1)
circ.delay(10, 0, 'us')

execute(circ, sim)

Results in:
  File "/home/yaelbh/work/terra/System/qiskit/assembler/assemble_circuits.py", line 48, in _assemble_circuit
    raise QiskitError("Unable to assemble circuit with unit '{}', which must be 'dt'."
qiskit.exceptions.QiskitError: "Unable to assemble circuit with unit 's', which must be 'dt'."

Coming from:
    if circuit.unit != 'dt':
        raise QiskitError("Unable to assemble circuit with unit '{}', which must be 'dt'."
                          .format(circuit.unit))

What is the expected behavior?
Suggested solutions

A work around may be to run through the transpiled before execution on the simulator.


Enhance karate.info data and expose all of it when karate-config.js is processed

Enhance karate.info data and expose all of it when karate-config.js is processed.
Currently only "featureDir" and "featureFileName" are only available when karate-config.js is processed as ScenarioContext.executionUnit is null -->
https://github.com/intuit/karate/blob/develop/karate-core/src/main/java/com/intuit/karate/core/ScenarioContext.java#L238
I've created a fix to address this by adding an else clause when ScenarioContext.executionUnit is null to fall back on the available Scenario object which appears to have this data readily available.
@ptrthomas if I can get access to push a branch i'd be happy to provide the fix for this.  i get the following error right now.
C:\git\karate>git push origin issues/1246
remote: Permission to intuit/karate.git denied to kirksl.
fatal: unable to access 'https://github.com/intuit/karate.git/': The requested URL returned error: 403

@kirksl the process is create a PR against develop from your fork: https://github.com/intuit/karate/pulls?q=is%3Apr+is%3Aclosed

done
https://github.com/intuit/karate/pull/1247

0.9.6 released


Crash on my server

18:21:44 [INFOS] This server is running Glowstone++ version 1.9-SNAPSHOT-"d087be6" (MC: 1.9) (Implementing API version 1.9-R0.1-SNAPSHOT)
18:21:44 [INFOS] Creating default config: config\glowstone.yml
18:21:44 [INFOS] Recipes: 295 shaped, 63 shapeless, 26 furnace, 10 dynamic, 28 fuels.
18:21:44 [INFOS] Downloading sqlite-jdbc 3.7.2...
18:21:44 [INFOS] Downloading slf4j-jdk14 1.7.15...
18:21:44 [INFOS] Downloading mysql-connector-java 5.1.38...
18:21:45 [INFOS] Downloaded slf4j-jdk14 1.7.15.
18:21:49 [INFOS] Scanning plugins...
18:21:49 [INFOS] Created default config: config\help.yml
18:21:50 [INFOS] Preparing spawn for world...
18:21:51 [INFOS] Preparing spawn for world: 0%
18:21:52 [INFOS] Preparing spawn for world: 3%
18:21:53 [INFOS] Preparing spawn for world: 12%
18:21:54 [INFOS] dungeon generated: -123,3,291
18:21:54 [INFOS] Preparing spawn for world: 28%
18:21:55 [INFOS] Preparing spawn for world: 46%
18:21:56 [INFOS] Preparing spawn for world: 62%
18:21:57 [INFOS] Downloaded mysql-connector-java 5.1.38.
18:21:57 [INFOS] Preparing spawn for world: 88%
18:21:58 [INFOS] Preparing spawn for world: done
18:21:58 [INFOS] Preparing spawn for world_nether...
18:21:59 [INFOS] Preparing spawn for world_nether: 48%
18:22:00 [INFOS] Preparing spawn for world_nether: done
18:22:00 [INFOS] Preparing spawn for world_the_end...
18:22:00 [INFOS] Preparing spawn for world_the_end: done
18:22:00 [INFOS] Created default config: config\commands.yml
18:22:00 [INFOS] Created default config: config\permissions.yml
18:22:00 [INFOS] Binding to address: <IP_ADDRESS>/<IP_ADDRESS>:25565...
18:22:00 [INFOS] Successfully bound to: /0:0:0:0:0:0:0:0:25565
18:22:00 [INFOS] Ready for connections.
18:22:12 [INFOS] Downloaded sqlite-jdbc 3.7.2.
18:32:00 [GRAVE] Error while loading chunk (-14,22)
java.io.IOException: Invalid length:<PHONE_NUMBER> > 4096
at net.glowstone.io.anvil.RegionFile.getChunkDataInputStream(RegionFile.java:196)
at net.glowstone.io.anvil.AnvilChunkIoService.read(AnvilChunkIoService.java:63)
at net.glowstone.ChunkManager.loadChunk(ChunkManager.java:152)
at net.glowstone.GlowChunk.load(GlowChunk.java:187)
at net.glowstone.GlowChunk.load(GlowChunk.java:180)
at net.glowstone.GlowChunk.getSection(GlowChunk.java:281)
at net.glowstone.GlowChunk.getType(GlowChunk.java:321)
at net.glowstone.block.GlowBlock.getTypeIdNoCache(GlowBlock.java:201)
at net.glowstone.block.GlowBlock.getType(GlowBlock.java:182)
at net.glowstone.block.blocktype.BlockLiquid.calculateTarget(BlockLiquid.java:152)
at net.glowstone.block.blocktype.BlockLiquid.calculateFlow(BlockLiquid.java:133)
at net.glowstone.block.blocktype.BlockLiquid.updatePhysics(BlockLiquid.java:247)
at net.glowstone.block.blocktype.BlockLiquid.receivePulse(BlockLiquid.java:113)
at net.glowstone.GlowWorld.lambda$pulseTickMap$20(GlowWorld.java:1784)
at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(Unknown Source)
at java.util.stream.ReferencePipeline$2$1.accept(Unknown Source)
at java.util.concurrent.ConcurrentHashMap$EntrySpliterator.forEachRemaining(Unknown Source)
at java.util.stream.AbstractPipeline.copyInto(Unknown Source)
at java.util.stream.AbstractPipeline.wrapAndCopyInto(Unknown Source)
at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(Unknown Source)
at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(Unknown Source)
at java.util.stream.AbstractPipeline.evaluate(Unknown Source)
at java.util.stream.ReferencePipeline.forEach(Unknown Source)
at net.glowstone.GlowWorld.pulseTickMap(GlowWorld.java:1780)
at net.glowstone.GlowWorld.pulse(GlowWorld.java:356)
at net.glowstone.scheduler.WorldScheduler$WorldThread.run(WorldScheduler.java:139)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
18:37:45 [INFOS] Sephyroth234 [/<IP_ADDRESS>:56541] connected, UUID: 7d4b1f6e-2fab-4d4c-95e8-930b10e3c94f
18:37:45 [INFOS] Sephyroth234 joined the game
18:38:00 [INFOS] Sephyroth234 issued command: /time set day

op Sephyroth234
18:38:14 [INFOS] CONSOLE: Opped Sephyroth234
18:39:33 [INFOS] Sephyroth234 issued command: /time set day
18:39:33 [INFOS] Sephyroth234: Set time to 0
18:39:51 [INFOS] Sephyroth234 issued command: /gm 1
18:39:54 [INFOS] Sephyroth234 issued command: /gamemode 1
18:39:54 [INFOS] Sephyroth234: Set own game mode to CREATIVE mode
18:39:57 [INFOS] Sephyroth234 issued command: /help
18:40:01 [INFOS] Sephyroth234 issued command: /pl
18:41:42 [INFOS] Sephyroth234 has just earned the achievement [Taking Inventory]
18:46:40 [INFOS] Sephyroth234 issued command: /help
18:46:46 [INFOS] Sephyroth234 issued command: /help Bukkit
18:47:01 [GRAVE] Error while loading chunk (-12,28)
java.io.IOException: Invalid length:<PHONE_NUMBER> > 4096
at net.glowstone.io.anvil.RegionFile.getChunkDataInputStream(RegionFile.java:196)
at net.glowstone.io.anvil.AnvilChunkIoService.read(AnvilChunkIoService.java:63)
at net.glowstone.ChunkManager.loadChunk(ChunkManager.java:152)
at net.glowstone.GlowChunk.load(GlowChunk.java:187)
at net.glowstone.GlowChunk.load(GlowChunk.java:180)
at net.glowstone.GlowChunk.getSection(GlowChunk.java:281)
at net.glowstone.GlowChunk.getType(GlowChunk.java:321)
at net.glowstone.block.GlowBlock.getTypeIdNoCache(GlowBlock.java:201)
at net.glowstone.block.GlowBlock.getType(GlowBlock.java:182)
at net.glowstone.block.blocktype.BlockLiquid.calculateTarget(BlockLiquid.java:152)
at net.glowstone.block.blocktype.BlockLiquid.calculateFlow(BlockLiquid.java:133)
at net.glowstone.block.blocktype.BlockLiquid.updatePhysics(BlockLiquid.java:247)
at net.glowstone.block.blocktype.BlockLiquid.receivePulse(BlockLiquid.java:113)
at net.glowstone.GlowWorld.lambda$pulseTickMap$20(GlowWorld.java:1784)
at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(Unknown Source)
at java.util.stream.ReferencePipeline$2$1.accept(Unknown Source)
at java.util.concurrent.ConcurrentHashMap$EntrySpliterator.forEachRemaining(Unknown Source)
at java.util.stream.AbstractPipeline.copyInto(Unknown Source)
at java.util.stream.AbstractPipeline.wrapAndCopyInto(Unknown Source)
at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(Unknown Source)
at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(Unknown Source)
at java.util.stream.AbstractPipeline.evaluate(Unknown Source)
at java.util.stream.ReferencePipeline.forEach(Unknown Source)
at net.glowstone.GlowWorld.pulseTickMap(GlowWorld.java:1780)
at net.glowstone.GlowWorld.pulse(GlowWorld.java:356)
at net.glowstone.scheduler.WorldScheduler$WorldThread.run(WorldScheduler.java:139)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

Probably caused by the same bug as #256.

I'm considering this a dupe of #256.


Add kubectl module

This is to add kubectl module, which enables command suggestion for kubectl

This was added to the contrib repo as a part of a larger change in https://github.com/belak/prezto-contrib/commit/a2c460868ae81f730aa616ec2c7a9fc7b9dc4c37
Thanks for your contribution!

I'm going to close this for now since it was merged into the contrib repo. Thanks for your contribution!


Couldnt find  backpack

Windows + esp32 (fresh fw) + beta3 plugin
Start log:
v1.0.0-beta.3
Attempting to find backpack
Attempting to find backpack on COM6 - It detects port correctly
Could not find connected backpack. Ending connector thread.
I added extra logger to see if it detect a port
        for port in ports:
            s.port = port.device

            try:
                s.open()
                logger.info(f"Attempting to find backpack on {port.device}")
            except:
                continue

Tried to replug esp several times, didt  help
For some reason it didnt fall back to
                logger.warning('Failed to write to open serial device. Attempting to connect to new device...')
Only straight to closing port

What board(s) are you using again? Is it just the standard DevKitC?

What board(s) are you using again? Is it just the standard DevKitC?

Just a standart NodeMCU ESP32 boards, I dont think the problem is with boards because if flashes well and it worked well on previous versions.

What board(s) are you using again? Is it just the standard DevKitC?

Just a standart NodeMCU ESP32 boards, I dont think the problem is with boards because if flashes well and it worked well on previous versions.

The plugin has been primarily been developed on a Windows PC, so initially I don't think the code base is the issue right now. You've mentioned having issues with other beta versions in the past, especially on Windows, so I wonder it if could be a driver issue.
Drivers for the typical USB to serial converter chips that are used on the ESP32s can be found here

Another thing to try is to add a logging line here
It could be closing the port because it wasn't receiving the right message from the esp32

What board(s) are you using again? Is it just the standard DevKitC?

Just a standart NodeMCU ESP32 boards, I dont think the problem is with boards because if flashes well and it worked well on previous versions.

The plugin has been primarily been developed on a Windows PC, so initially I don't think the code base is the issue right now. You've mentioned having issues with other beta versions in the past, especially on Windows, so I wonder it if could be a driver issue.
Drivers for the typical USB to serial converter chips that are used on the ESP32s can be found here

I dont think its a driver issue, I cant flash esp any time no problem.
I can run pkendall64 test message code no problem too.
I allready tried to uninstall/install recomended drivers.

Does adding logger.info(list(response)) before what's currently in line 154 give you anything?

Does adding logger.info(response) before what's currently in line 154 give you anything?

Yes
Loaded plugin module VRxC_ELRS
v1.0.0-beta.3
Attempting to find backpack
Attempting to find backpack on COM7
[0, 248, 120, 120, 120, 120, 0, 128]
Could not find connected backpack. Ending connector thread.

Does adding logger.info(response) before what's currently in line 154 give you anything?

Yes
Loaded plugin module VRxC_ELRS v1.0.0-beta.3 Attempting to find backpack Attempting to find backpack on COM7 [0, 248, 120, 120, 120, 120, 0, 128] Could not find connected backpack. Ending connector thread.

So it looks like its an issue with the backpack. the proper response should be
[36, 88, 62, 0, 128, 3, 6, 0]

Does adding logger.info(response) before what's currently in line 154 give you anything?

Yes
Loaded plugin module VRxC_ELRS v1.0.0-beta.3 Attempting to find backpack Attempting to find backpack on COM7 [0, 248, 120, 120, 120, 120, 0, 128] Could not find connected backpack. Ending connector thread.

So it looks like its an issue with the backpack. the proper response should be [36, 88, 62, 0, 128, 3, 6, 0]

This is from another ESP module
Loaded plugin module VRxC_ELRS
v1.0.0-beta.3
Attempting to find backpack
Attempting to find backpack on COM1
[36, 88, 62, 0, 16, 0, 6, 0]
Could not find connected backpack. Ending connector thread.

If you change msptypes.MSP_ELRS_BACKPACK_SET_MODE to msptypes.MSP_ELRS_GET_BACKPACK_VERSION here, that should get the second ESP module to work.
I thought that the firmware in the beta 2 was suppose to support that, but it looks like I forgot about the changes I made for the elrs pull request. I'll just those update, thanks for the help!

Maybe you need to leave that extra loggers in code just for future user debugging :)

yup you are right, they are going to be pushed up to master fairly soon. If you wanted to test with the updated firmware, I did switch out the esp32 firmware that was included with the beta.3 release

Another ESP
Loaded plugin module VRxC_ELRS
v1.0.0-beta.3
Attempting to find backpack
Attempting to find backpack on COM7
[248, 120, 120, 120, 120, 0, 128, 120]
Could not find connected backpack. Ending connector thread.

Just had some new devkits show up, and they gave me the same issue where they wouldn't connect to Windows. it looks like adding in this sleep fixes it for some reason.


3.4.1 - Port 443 permission denied

Since version 3.4.1 I haven’t been able to run code-server without root permissions. Also, when using root my configuration file doesn’t seem to be used. For code-server to work I have to manually set my configuration as flags.
I’m on the Raspberry Pi 4 with Raspbian 64 bit.
pi@raspberrypi:~ $ cat ~/.config/code-server/config.yaml
bind-addr: <IP_ADDRESS>:443
auth: none
password: ***
cert: "/home/pi/raspberrypi.local.pem"
cert-key: "/home/pi/raspberrypi.local-key.pem"

pi@raspberrypi:~ $ code-server
info  Using config file ~/.config/code-server/config.yaml
info  Using user-data-dir ~/.local/share/code-server
info  code-server 3.4.1 48f7c2724827e526eeaa6c2c151c520f48a61259
error listen EACCES: permission denied <IP_ADDRESS>:443

pi@raspberrypi:~ $ sudo code-server
info  Using config file ~/.config/code-server/config.yaml
info  Using user-data-dir ~/.local/share/code-server
info  code-server 3.4.1 48f7c2724827e526eeaa6c2c151c520f48a61259
info  HTTP server listening on http://<IP_ADDRESS>:8080
info      - Using password from ~/.config/code-server/config.yaml
info      - To disable use `--auth none`
info    - Not serving HTTPS
^C
pi@raspberrypi:~ sudo lsof -i -P -n | grep LISTEN
sshd       520  root    3u  IPv4  15148      0t0  TCP *:22 (LISTEN)
sshd       520  root    4u  IPv6  15150      0t0  TCP *:22 (LISTEN)

pi@raspberrypi:~ $ sudo code-server --bind-addr <IP_ADDRESS>:443 --auth none --cert "/home/pi/raspberrypi.local.pem" --cert-key "/home/pi/raspberrypi.local-key.pem"
info  Using config file ~/.config/code-server/config.yaml
info  Using user-data-dir ~/.local/share/code-server
info  code-server 3.4.1 48f7c2724827e526eeaa6c2c151c520f48a61259
info  HTTP server listening on https://<IP_ADDRESS>:443
info    - No authentication
info    - Using provided certificate and key for HTTPS

EDIT: Readability.

@dinisbcoelho So to run on :443 root permissions are required. In your case, the problem is that sudo modifies $HOME to the root's home and your config file isn't being used.
sudo env HOME=$HOME code-server

will work as expected.

See https://unix.stackexchange.com/questions/91384/how-is-sudo-set-to-not-change-home-in-ubuntu-and-how-to-disable-this-behavior for more details


Roadmap

Is there a roadmap for the fork short term and long term?
Node 20
https://github.com/vercel/pkg-fetch/issues/302
ESM
https://github.com/vercel/pkg/issues/1291
https://github.com/vercel/pkg/discussions/1388
https://github.com/vercel/pkg/issues/1655
https://github.com/vercel/pkg/pull/1323
Multiple entry points
https://github.com/vercel/pkg/issues/481
XDG directory
https://github.com/vercel/pkg/issues/1225
Sharp
https://github.com/vercel/pkg/issues/1918

No roadmap here, I just started this to allow users contributing to the code and give the project a new life. Do you want to help?

We'd definitely like to help. Right now we used to use pkg without a pre-existing bundler, but I think it would be better to simply get users to always use a bundler first like esbuild, then use pkg. It would simplify pkg.

Yeah I think that including the pre-bundling inside pkg makes no sense, I would instead write better docs about that process and maybe add examples too

That will modify stack traces which makes hard to track errors in production. Stack traces with original file names and line numbers are critical and bundling shouldn't be expected by users.
Important thing is to see if someone has expertise to make native ESM support possible.

The lack of bundling results in pkg packaging everything include README.md, LICENSE.md files into the executable.

Important thing is to see if someone has expertise to make native ESM support possible.

The only one that has the ability to do it (that I know) was @jesec but I didn't heard him from a long time, I know he also had something working with ESM but never finished the implementation.
The future of packaged nodejs apps is Node SEA, Deno and/or Bun IMO once one of this 3 "native" methods become more usable. My goal in the meanwhile is to keep pkg as much updated as possible and give the possibility to the ones that would like to contribute to see their PR merged and not to stay there for years without any response...

The lack of bundling results in pkg packaging everything include README.md, LICENSE.md files into the executable.

pkg documentation says it can build the executable without sources.

The future of packaged nodejs apps is Node SEA, Deno and/or Bun IMO once one of this 3 "native" methods become more usable.

These methods will include sources.

@rightaway Node SEA compiles code in V8 bytecode like pkg does

I read will be possible to see source in SEA bundle. Documentation don't mention bytecode do you know where you read it?

pkg is deprecated and they said there were active forks does anyone know which are the most active?

seems this one is the most active for now

This one is the most active

I wish Node v20 to be supported 😢
SEA is still early beta, with just basic features, pkg seemed like more production-ready approach.

Lol it is from at least 2 months now 🤣

Thank you for your branch contribution. I really like and need it.
When I learned that the official pkg was no longer being maintained, I was saddened because SEA was not yet fully developed and convenient to use.


App crashes on adding food via Scan bar code for the first time

Launch the app and create a new user (not necessary though)
Scan a valid barcode and add a food
Observe

Actual:
App crash
Expected:
No crash

Crash Log
Archive.zip

fixed

Verified. No more crash.


Fix some lint error

As title.

Codecov Report

Merging #385 into master will increase coverage by 1.03%.
The diff coverage is 62.03%.

@@            Coverage Diff             @@
##           master     #385      +/-   ##
==========================================
+ Coverage   58.56%   59.59%   +1.03%
==========================================
  Files          52       52
  Lines        8683     8655      -28
==========================================
+ Hits         5085     5158      +73
+ Misses       2540     2535       -5
+ Partials     1058      962      -96

Impacted Files
Coverage Δ

ledis/scan.go
69.23% <ø> (ø)

ledis/t_set.go
72.09% <ø> (ø)

store/iterator.go
57.96% <ø> (ø)

store/snapshot.go
52.00% <0.00%> (+2.00%)
:arrow_up:

store/writebatch.go
67.27% <ø> (ø)

rpl/rpl.go
39.22% <25.00%> (ø)

store/db.go
55.42% <31.25%> (+2.01%)
:arrow_up:

server/info.go
28.02% <50.00%> (ø)

server/cmd_list.go
50.63% <54.54%> (+4.92%)
:arrow_up:

server/cmd_server.go
30.39% <54.54%> (+1.54%)
:arrow_up:

... and 11 more

Continue to review full report at Codecov.

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


User Enumeration

Hi guys, really enjoying the app so far. This isn't exactly stop press, but I thought it worth mentioning: it's possible to enumerate the users on the site by entering a target email address and a random password.

Ideally the error message should be non-specific regarding whether the email address or password were incorrect, to increase the difficulty of guessing credentials.

This also exists on the "Recover account" page

Hi folks -- Keybase sigchains are public documents, we don't try to keep user info private. If you want to see whether a given username exists you can just go to their public profile page..

I can understand making user list public, but does that extend to allowing you to guess which email address they use for credentials?

Thanks @rafaelh  and @davidwengier.  We're aware of the email enumeration list, but it's a UX/security tradeoff, and since we have pretty aggressive rate-limiting on these endpoints, we think it's worth it.

That makes sense. Thanks for taking the time to respond.

Thank you for the report!


Support for custom marks

Need to provide an API to record custom marks on the current transaction.
Consider capturing marks added by using performance.mark.
Add docs
Add example marks to opbeans

Fixed in https://github.com/elastic/apm-agent-js-base/commit/4d2b71b2a82e83c497976f4ea25bf22d7810f10f and https://github.com/elastic/apm-agent-js-core/commit/3de6b1048b810f2d2a76bd68a18c25da3eb3a477


Nested ref definition

When I reference a definition like
"$ref" : "#/definitions/systemCommand"

and my definition looks like this
"definitions" : {

		"systemCommand" : {
			"title" : "System Command",
			"type" : "object",
			"properties" : {
				"systemCommand" : {
					"type" : "string"
				},
				"anywayOnServiceError" : {
					"type" : "boolean"
				}
			}
		}

	}

everything is fine!
But when I try to reference a definition like this
"$ref" : "#/definitions/jobplansteps/systemCommand"

and my definition object looks like
"definitions" : {
		"jobplansteps" : {
			"systemCommand" : {
				"title" : "System Command",
				"type" : "object",
				"properties" : {
					"systemCommand" : {
						"type" : "string"
					},
					"anywayOnServiceError" : {
						"type" : "boolean"
					}
				}
			}
		}
	}

it doesn´t find the definition!
On Understanding JSON Schema I found

The pound symbol (#) refers to the current document, and then the slash (/) separated keys thereafter just traverse the keys in the objects in the document. Therefore, in our example "#/definitions/address" means:

go to the root of the document
find the value of the key "definitions"
within that object, find the value of the key "address"

So. Is this behavior "normal"?

Correct way to display property "SystemCommand" of "jobplansteps" here:
http://jeremydorn.com/json-editor/?schema=N4IgLglmA2CmIC4QAVYCcDOB7AdiANOAJ4AO8SWARgFawDGYBIAJGrAGaIgDEA9ACYcIOKBFwZe1KiWgBDHBjCwSGJoPbDR4xKCmUZ8xctUJQYUuRBVaDJiTRYyaSLBOgMRIwFsAwli9e8vw64FBwXADKnkpeAAR+AUFM5mRc1vSMhPaO6C5uIB7eCYE4wabEqUiKaMIA5iAAvoTyRADuskQA8jgR6ABuEHSwAKJoDmghKZaUWFhw8o0NS8tAA==&value=N4IgzgnmAuCmC2BhA9veBDAdgExALlEhgRTS1zxBABoQsIB3dCAeUwGVYAnANwEsAxrACiXLsi74AZugA2YWAF9FQAA=&theme=bootstrap2&iconlib=fontawesome4&object_layout=normal&show_errors=interaction

Also to explain your problem: "jobplansteps" is the "key" in this Example, but "systemCommand" is a property of the key "jobplansteps". You can't reference to properties as far as I know, only to whole keys

Of course :+1: I have to think more Schema-Style
Thanks!


[#422][Python] Replace custom SkillConversationIdFactory instance by SDK SkillConversationFactory

Fixes # 422
Description
This PR updates the use of the SkillConversationIdFactory class in the Python bots replacing the existing custom class with the one in BotBuilder SDK.

Note: This class was introduced in the PR botbuilder-python# 1691, therefore the current botbuilder 4.13.x version does not have this implementation`.

Specific Changes

Updates all SkillConversationIdFactory instances to use the BotBuilder SDK class for SimpleHostBot, WaterfallHostBot and WaterfallSkillBot.
Removes the SkillConversationIdFactory custom class and file from all Python bots.

Testing
The following image shows the pipeline continues to work after the changes.

Promoted to MS PR 468


Support 64bit inode environment in in_tail

For example, XFS uses 64bit integer for inode.
in_tail should work on these environments.
See this thread: https://groups.google.com/d/topic/fluentd/YYrshTNGQ8c/discussion

We need some testers for

test on XFS like 64bit inode environment
test existing pos_file updated to 64bit inode automatically

I tested latter and it seems to work.

Okay, some users tested and this patch doesn't break existing environment.
Ready to merge.

cherry-picked to v0.10 branch


Modify the default for --hf_model_id flag

Hi @yzhang93 @pashu123
This is for my understanding.
Why was this change required explicitly instead of directly updating hf_model_id during the run itself?

Hi @yzhang93 @pashu123
This is for my understanding. Why was this change required explicitly instead of directly updating hf_model_id during the run itself?

Just making it as the default model. If someone doesn't pass hf_model_id flag.

This should've been complemented with an update to README.md as well since it refers to CompVis/stable-diffusion-v1-4 as the default value of hf_model_id.
And it seems like majority of the models in variants.json are based on CompVis/stable-diffusion-v1-4.
Any specific reason to make stabilityai/stable-diffusion-2-1-base as the default one? @pashu123
Since majority of the models depend on the other one, it only makes sense for us to revert back to the v1_4.

This should've been complemented with an update to README.md as well since it refers to CompVis/stable-diffusion-v1-4 as the default value of hf_model_id.
And it seems like majority of the models in variants.json are based on CompVis/stable-diffusion-v1-4.
Any specific reason to make stabilityai/stable-diffusion-2-1-base as the default one? @pashu123
Since majority of the models depend on the other one, it only makes sense for us to revert back to the v1_4.

The only reason is v2-1base has the highest performance, and it's the model we used for our demos.


New package: PRIMA v0.1.0

Registering package: PRIMA
Repository: https://github.com/emmt/PRIMA.jl
Created by: @emmt
Version: v0.1.0
Commit: bb5eac1a4dd1b3ea3a41c8168fa1b7f4c4c830ec
Reviewed by: @emmt
Reference: https://github.com/emmt/PRIMA.jl/commit/bb5eac1a4dd1b3ea3a41c8168fa1b7f4c4c830ec#commitcomment-128901211
Description: a Julia interface to PRIMA, a Reference Implementation for Powell's methods with Modernization and Amelioration

[noblock]
I was aware of this similarity in package names. However:

I think that the difference between ARFIMA and PRIMA is quite obvious for a human.
PRIMA.jl  is intended to be the Julia interface to the PRIMA Library and makes use of the Julia artifact PRIMA_jll both spelled with PRIMA in capital letters. So the name of the proposed package seems more logical.

[noblock]
Sorry to bother you with that issue but is there any chance to have some answer soon?


Minor Bug Fixed to get PAS to work

Two minor fixes preventing PAS from working correctly

Jira ticket DMEERX-403 should address the longer term for the missing coverage resource


Rocket Bot Royale - Post-mortem discussion and engine diffs.

Godot version
3.4
System information
HTML5, Windows, Linux, MacOS, iOS, Android, Linux Server
Issue description
Post mortem for Rocket Bot Royale. A cross-platform, multiplayer, server-authoritative, battle-royale game.  https://rocketbotroyale.winterpixel.io
Steps to reproduce
N/A - see first comment.
Minimal reproduction project
N/A - see first comment.

Reserved -

Thanks hugely for the write up and taking the time and work of putting up the diff. I am personally happy that Godot was useful for developing and publishing Rocket Bot Royale and I'm sure that a lot of the changes you had to do will be invaluable in improving the code quality!
I think some of these issues have been significantly improved in master branch, but I am super curious to see what your solutions (and problems found) were in order to keep improving the codebase.

I randomly stumbled upon this when searching for another issue, and I just wanted to say the decode once for ogg vorbis is a brilliant idea.  Would love to see that in the core engine.  I wondered if anybody created a proposal for that and then I see Calinou linked to the one I created, which I completely forgot about.  Boy, my memory is terrible. 😅


Reintroduce the dApp browser

Probably best to base of the latest trust implementation for now.

Ok, on this.

Going to have to update some dependencies.

[ ] Implement
[ ] Localise for Chinese


make <pre> elements in docs scrollable

closes #8032

I checked the vercel preview deployment. Looks good to me. Nice docs btw 👌 and all the best for 1.0


Lifetime Capture Rules 2024

In Rust 2024 and later editions, return position impl Trait (RPIT) opaque types will automatically capture all in-scope type and lifetime parameters.  In preparation for this, new RPIT-like impl Trait features introduced into the Rust 2021 edition will also automatically capture all in-scope type and lifetime parameters.
Rendered

@rfcbot labels +T-lang

@rustbot labels +T-lang

@rustbot labels +I-lang-nominated

Non-blocking
The TAIT as the solution to overcapturing part looks a little bit weird. This implies following two code blocks are not always equivalent.
// block 1
type T = /* xxx */ ;
fn foo</*...*/>()  -> T { /*...*/ }

// block 2
fn foo</*...*/>()  -> /* xxx */ { /*...*/ }

This could be interpreted as an inconsistency. I think we need to guide users to realize the distinction in some way, or it will create much confusion. (I guess most common use cases would be on the happy path though.)

Thank you for writing this RFC about such a detailed and nuanced topic, @traviscross, and for your earlier work driving the design conversations around it.
I have left some feedback in comments above, but none of it is about the normative changes in the RFC itself. I feel confident that we have the right set of rules here.
What's more, I'm really excited to tell users (especially async users) that we just made all those niggling lifetime bounds in their RPITs, and the ensuing confusion described in this RFC, disappear. I believe this is really a case where, syntactically speaking, less is more.
@rfcbot reviewed

Thanks @tmandry for the review, for your collaboration, and for the acknowledgment and appreciation you expressed.  I too am excited by how these changes improve Rust for the better.

Very nicely written and thorough RFC, thanks @traviscross! 🙂

Note, however, that as long as https://github.com/rust-lang/rust/issues/42940 is a problem (i.e., unless https://github.com/rust-lang/rust/pull/116040 or some future equivalent (but sound) PR lands), then the only workaround for overcapturing as showcased in https://github.com/rust-lang/rust/issues/42940 would be usage of explicit TAIT{,IT} (and indeed, this RFC does mention being contingent on TAIT).

Illustration of the overcapturing problem
fn overcaptured<T>(_: T) -> impl Copy + 'static {}
                                   // + Captures<T>

fn demo() -> impl Copy + 'static {
    let local = ();
    let ret = overcaptured(&local);
    assert_static(ret); // OK: outlives bound is respected
    return ret;         // Error! `Captures<&'local ()>` at odds with `+ 'static`
                        // what #116040 wanted to do was to unify these two behaviors
}

fn assert_static<R : 'static>(_: R) {}

Playground

But I'm personally rather worried about the implications of this TAIT{,IT}-based workaround. The change mentioned in the RFC, at least for RPITs, requires an edition boundary, and since 2027 is rather far, 2024 seems to be the likely candidate. This would put TAIT{,IT} under a (tight?) clock, to at least be shipped in stable by then potentially at the risk of rough edges / UX.

an example
use parking_lot::Mutex;
use std::sync::Arc;

pub struct Foo<F> {
    value: Arc<Mutex<F>>,
    /* other non-cloneable-fields */
}

type Locked<F: FnMut()> = impl FnMut(); // <--+
                                           // |
impl<F: FnMut()> Foo<F> {                  // |
    fn locked(&self) -> Locked<F> { // -------+ to avoid over-capturing the lifetime in `&self` in 2024
 // fn locked(&self) -> impl FnMut() { // in 2021
        let mut f = self.value.clone().lock_arc();
        move || f()
    }
}

pub fn public_facing(foo: Foo<impl FnMut()>) -> impl FnMut() {
    foo.locked()
}

yields:
error: opaque type's hidden type cannot be another opaque type from the same scope
  --> src/main.rs:27:5
   |
27 |     foo.locked()
   |     ^^^^^^^^^^^^ one of the two opaque types used here has to be outside its defining scope
   |
note: opaque type whose hidden type is being assigned
  --> src/main.rs:26:49
   |
26 | pub fn public_facing(foo: Foo<impl FnMut()>) -> impl FnMut() {
   |                                                 ^^^^^^^^^^^^
note: opaque type being used as hidden type
  --> src/main.rs:17:27
   |
17 | type Locked<F: FnMut()> = impl FnMut(); // <--+
   |                           ^^^^^^^^^^^^

Playground

This error seems to imply that now an extra module boundary would be needed to properly define the defining scope of the TAIT. This is not a very nice UX, at least when we compare it to what is needed to tackle our current "undercaptured" lifetimes: a simple + Captures<...> bound.

(with Captures being something that could be exposed under the core::marker module).

and adding the bound being then something simple for the compiler/diagnostics to suggest.

as a matter of fact, fixing under-capturing is simple enough to be implementable with a macro.

What worries me, is that the best self-contained and consistent way (e.g., for a macro to feature it) to fix the 2024 edition over-capturing problem, with only TAIT{,IT} as a workaround, may be to skip the 2024 edition altogether. Or worse, this could become an edition deterrent altogether for certain codebases.

Now, people may not have run into https://github.com/rust-lang/rust/issues/42940, which is already an issue with our current editions, all that much, so maybe the belief is that once lifetimes are also captured, we may remain "as lucky" and not run into it that often either. But I'd like to point out that in API design, generic type parameters such as T often represent an owned or long-lived type, for which over-capturing will not be an issue.
But non-type-generic borrows/references such as metadata: &str or whatnot, on the contrary, can be short-lived quite often, which means running into https://github.com/rust-lang/rust/issues/42940 way more often.

Finally, the motivation for most of this is some consistency between async fn and fn ... -> impl Future... (even though it does so at the cost of some inconsistency of the meaning of existential impl Trait). That is, introducing an overcapturing-of-lifetimes problem for all usages of impl Trait to help the specific case of unsugared async fns.

Conclusion

The changes suggested in this RFC introduce an overcapturing-of-lifetimes problem, which will be more frequently run into than our current overcapturing-of-types-only situation.
Without #42940 (or equivalent), there won't be a solution for this (otherwise a properly-spelled out + 'usability, akin to what is needed for dyn Traits, would solve the issue).
The only suggested workaround, then, is using the currently unstable TAIT{,IT} functionality, requiring for it to be stabilizing in time (and in a hurry?) by the time the 2024 edition lands.
TAIT{,IT} involves a bunch of subtle questions and rough edges, such as scope of definition, behavior of higher-order binders, interaction with auto-traits, especially in the context of ...in_traits, all of which make this a bit unwise / do not make this be too appealing as the only solution (other than for users to bail out of the edition altogether).

So without https://github.com/rust-lang/rust/issues/42940 (or equivalent), I'd advise against going forward with this, unless there were some lang attribute precisely to opt out of it, à la #[rpit_capture_rules(legacy)].
However, I do share the general sentiment of this high quality RFC: should we have properly acknowledged + 'usability bounds, then the problem of overcapturing would simply disappear (or be trivial to fix), making over-capturing a strictly better situation, with a (only) then all-around simpler mental model (no need for users to ever know about "capturing").
So, even though currently https://github.com/rust-lang/rust/issues/42940 seems to be stuck on a soundness issue, I'd strongly encourage our brave compiler maintainers and heroes to keep pushing forward in that direction 🦸, for + 'usability to be properly enforced, even with RPIT, even in the case of liveness analysis / "local lifetime escapes" errors, precisely to let this RFC go forward without having everything hinge on the in-the-works RPIT{,IT} alone.

Should this be too much to undertake / end up being not feasible, I'd like to ask for there to at least be a #[rpit_capture_rules(legacy)] opt out mechanism, then.

@danielhenrymantilla:
Note that the RFC as drafted does not require that TAIT be stabilized.  It simply requires that we stabilize some solution that allows all existing code to continue to be expressed.  The relevant normative language is:

The stabilization of the 2024 lifetime capture rules in this RFC is contingent on the stabilization of TAIT or some other solution for precise capturing that will allow all code that is allowed under Rust 2021 to be expressed, in some cases with syntactic changes, in Rust 2024.

[Emphasis added.]
The document then describes one other complete solution in Appendix F.  It also, of course, describes the rust-lang/rust#116040 solution in Appendix G.
If we later decided to stabilize an #[rpit_capture_rules(legacy)] attribute as you propose, that would also satisfy the normative language of this RFC.
As we're discussing here, we already plan to deemphasize TAIT a bit in a revision of this draft.  But even as currently written, the draft does not require it.
Does this clarification satisfy your concern?

@zirconium-n:;

Non-blocking
The TAIT as the solution to overcapturing part looks a little bit weird. This implies following two code blocks are not always equivalent.
// block 1
type T = /* xxx */ ;
fn foo</*...*/>()  -> T { /*...*/ }

// block 2
fn foo</*...*/>()  -> /* xxx */ { /*...*/ }

Correct.  These are not equivalent.  This behavior was specified and accepted in RFC 2071 and in RFC 2515 and is not new behavior being added by this RFC.
Note also that this RFC does not require TAIT to be stabilized.  It simply requires that we stabilize some solution that allows all current code to continue to be expressed in some form.  TAIT is the only such solution that has an accepted RFC and which there is a consensus to stabilize in some form (independent of this RFC), but it's not the only conceivable solution.

@aliemjay:

This needs to specify the behavior of capturing the lifetimes of for<..> binders.... I would think it is essential for consistency.
#![feature(unboxed_closures)]
fn foo(s: &str) -> &str {
    s
}
fn bar() -> impl for<'a> Fn<(&'a str,), Output = impl Sized> {
    // should we allow `impl Sized` to capture `'a`?
    foo
}

Agreed it would be an essential consistency once higher kinded lifetime bounds on nested opaque types are supported.
Note that the current draft does specify this behavior.  We say:

Under this RFC, in the Rust 2024 edition, RPIT opaque types will automatically capture all lifetime parameters in scope...

The impl Sized in this example is an RPIT opaque type, and the 'a lifetime parameter is in scope for that opaque type, so under this RFC it would be captured.
(I'll add an example.)
@aliemjay:

The current implementation for TAIT/RPITIT does not allow it...

With RPIT, it currently fails due to the fact that the lifetime is not captured:
#![feature(unboxed_closures)]

// error[E0700]: hidden type for `impl Sized` captures lifetime that does not appear in bounds
fn bar() -> impl for<'a> Fn<(&'a (),), Output = impl Sized> {
    fn f(x: &()) -> &() { x }
    f
}

But note that with an explicit Captures, it fails for a different reason:
#![feature(unboxed_closures)]

trait Captures<T> {}
impl<T, U: ?Sized> Captures<T> for U {}

// error: higher kinded lifetime bounds on nested opaque types are not supported yet
fn bar() -> impl for<'a> Fn<(&'a (),), Output = impl Sized + Captures<&'a ()>> {
    fn f(x: &()) -> &() { x }
    f
}

RPITIT produces this same error:
#![feature(unboxed_closures)]
#![feature(return_position_impl_trait_in_trait)]

trait Trait {
    // error: higher kinded lifetime bounds on nested opaque types are not supported yet
    fn bar() -> impl for<'a> Fn<(&'a (),), Output = impl Sized>;
}

I feel there's still a lack of data round existing usage.
I don't have the resources or infrastructure that the project does, but I downloaded some popular crates and looked for RPITs that were both part of the public API and would presumably break because they:

Did not capture lifetimes though lifetimes were present, or
Implicitly or explicitly captured or bound a one lifetime out of many

Here's what I found:

clap_lex
cookie_store
exr (2, 3, 4)
h2
hyper (2, 3, 4)
object (2)
reqwest
select
tokio (2)

If I understand correctly how + 'static would work, tokio, request, and maybe hyper could possibly use + 'static to preserve existing behavior, but there's at least one example in the rest where either a generic type (without a 'static bound) or a non-'static lifetime (e.g. one specific one out of multiple) is captured, and thus a 'static bound would also be breaking.
This was just an informal grep-based survey.  The team(s) should do a more encompassing test to get a better feel for the impact.

@QuineDot:

I downloaded some popular crates and looked for RPITs...

Thanks for having a look and providing these examples.
@QuineDot:

The team(s) should do a more encompassing test to get a better feel for the impact.

A crater run of this change was performed here.
This shows breakage in 0.37% of crates.
This is a lower bound as it doesn't analyze potential problems between a library shipping an RPIT function as part of its API and a consumer of that library that calls that function.  Of course, shipping an RPIT function in an API has long been considered an anti-pattern, so that may act to reduce the number of such interactions.
Further analysis of crates.io showed that about 10% of crates use RPIT, and about 0.67% of function signatures use RPIT (about 62k).  We think it's likely that the total number of function signatures that would need to be updated across crates.io number in the hundreds or maybe low thousands.

@danielhenrymantilla

TAIT{,IT} involves a bunch of subtle questions and rough edges, such as scope of definition, behavior of higher-order binders, interaction with auto-traits, especially in the context of ...in_traits, all of which make this a bit unwise / do not make this be too appealing as the only solution (other than for users to bail out of the edition altogether).

We can, if necessary, simplify the scope of definition questions by stabilizing a more restricted subset (single definition in return position). I'm not aware of other questions that are all that subtle; can you link to more info?
Note that I do not want to use this thread to document subtle questions of TAIT, but consider links to them relevant to help address the question of whether we have a plausible strategy for solving overcaptures.

Of course, shipping an RPIT function in an API has long been considered an anti-pattern

It has? This is the first time I hear that.^^
The book doesn't contain any warning along these lines, so how would I have been expected to know that this is an anti-pattern?

@RalfJung:

Of course, shipping an RPIT function in an API has long been considered an anti-pattern

It has? This is the first time I hear that.^^
The book doesn't contain any warning along these lines, so how would I have been expected to know that this is an anti-pattern?

As background, the reason it is considered an anti-pattern to return an opaque type from an API is that without TAIT (or equivalently, "RTN Everywhere"), the user of the API cannot name the returned type, so that user cannot e.g. store that type in a struct unboxed. If the trait in the bounds of the opaque type is not object-safe, the effective limitation is even more severe.
The standard library currently follows this rule of returning named rather than opaque types (even when it would be simpler in the implementation to use RPIT), and many crate authors also follow this rule.  That this is an anti-pattern has come up in many discussions.
However, your request for a citation on this is entirely reasonable.  Here are some places it probably should be documented but is not currently:

In the section of The Rust Programming Language book that introduces RPIT (as you noted).
In the anti-patterns section of the unofficial Rust Design Patterns book.
In the "policies" section of the Standard Library Developer's Guide book.

I can't help but wonder if we're going to end up wanting an equivalent to RFC 66 related to precise capture here in the future, but in the meantime:
@rfcbot reviewed

@rustbot labels -I-lang-nominated
This is now in FCP.  Removing the nomination.

Nitpicking: can we make the RFC name a little clear by saying Lifetime Capture Rules 2024 in Return Position impl Trait (RPIT) or something.
Personally I was surprised at the concept of capturing lifetimes in PRIT the first time I saw it in this RFC, because the word capture is usually used in the contexts like closures and async blocks and I would think lfetime capture rules changed in those places.

https://doc.rust-lang.org/stable/book/ch13-01-closures.html?highlight=capture
https://rust-lang.github.io/async-book/03_async_await/01_chapter.html?highlight=capture#async-move
https://doc.rust-lang.org/reference/?search=capture

I only became aware of this via jonhoo's recent presentation on impl Trait in Copenhagen.  I understand the amount of work and analysis that has gone on to get this right, and I applaud the move to a single, consistent ruleset under 2024 Edition.
Am I the only one with the thought that we may be investing in the wrong direction here?  Rust has historically defaulted to explicitness as a principle, whereas this approach of capturing lifetimes and in-scope generic type is inherently implicit.  The fact that a change to a hidden type which does not violate the opaque type signature could break my public API is surprising and even a little alarming to me.
The fundamental problem to my eye is leaking the lifetime capture at all.  Leaky abstractions make it much, much harder to create correct, composable programs.  I understand we do not have the proper syntax today to express the correct lifetime constraints required to make this an explicit feature, but my vote would be to explore exactly that, in lieu of doubling-down on the leakage.
I have little doubt that there has been lots of discussion that I am unaware of, but I am concerned that this may be one of those features that, in hindsight, we might wish we had taken more time to stabilize.

Am I the only one with the thought that we may be investing in the wrong direction here? Rust has historically defaulted to explicitness as a principle, whereas this approach of capturing lifetimes and in-scope generic type is inherently implicit. The fact that a change to a hidden type which does not violate the opaque type signature could break my public API is surprising and even a little alarming to me.

Neither the old behavior nor the proposed new behavior has the property that a change to a hidden type that does not violate the opaque type signature can break your public API (with the sole exception of auto traits, which have always had this behavior and to some extent need to have this behavior in order to make adding a new auto trait not a breaking change). Before, the captures were calculated only based on the signature by one algorithm, now they are calculated only based on the signature by a different algorithm. The hidden type is not considered.

@digama0 is correct -- this RFC simply changes the set of lifetimes a hidden type of an opaque is allowed to mention.
There's no leakage involved, and I'm not certain how this RFC would make it possible for a change in hidden type to break public APIs, which can only happen when auto traits are involved.

Is there somewhere I can read more about the reasoning behind capturing any and all lifetime parameters in scope? As someone who only gets to use Rust occasionally, this feels excessively broad, and I don't really understand the reason for it.

I think Rust's explicitness and consistency is one of its strength as it makes it easy to reason about the behavior of a program.
Implicit captures go against this explicitness, and I am worried this is already a half-broken feature: it does what one want in some cases, but it has to be manually undone the rest of the time. C++ is full of these half-broken features, and it makes it unpleasant to work with. From experience it is very frustrating to find out that a tool has been doing some automagic behind one's back that now has to be manually undone.
These may be newbie questions but as a Rust user without full understanding of the issue (as most Rust users out there I suppose) I wonder if there are no other viable solutions:

is the -> Trait + Captures<...> explicit solution not good enough ? this could be made easier by providing Capture traits for various capture arities in the standard library
could the compiler infer the minimum capture lifetimes and types needed, and capture just these instead of capturing everything in the context? I suppose the compiler already has to know this information to typecheck / lifetime check the returned value

In any case, I think having implicit features that work only some of the time is not great.

@runiq:

Is there somewhere I can read more about the reasoning behind capturing any and all ~lifetime~ generic parameters in scope? As someone who only gets to use Rust occasionally, this feels excessively broad, and I don't really understand the reason for it.

For discussion of this, you would want to look to RFC 1951, RFC 2394, RFC 3425, and the "Capturing lifetimes in RPITIT" document linked in Appendix A of this RFC.
@azergante:

These may be newbie questions but as a Rust user without full understanding of the issue (as most Rust users out there I suppose) I wonder if there are no other viable solutions.... I think having implicit features that work only some of the time is not great.

The decision to make the captures automatic happened back in the RFCs mentioned above.  Here, we're simply reconciling some inconsistencies in a way that also allowed RPITIT to happen.  Those documents may answer some of your questions.  If you want to discuss further how or why we might want to rethink those earlier decisions, it'd probably be better to open that discussion separately on Zulip or IRLO.

We have merged this RFC and opened a tracking issue: https://github.com/rust-lang/rust/issues/117587
For further updates, you may want to subscribe to that.
Thanks to all of the members of T-lang for being courageous enough to answer "the big question", to @tmandry for his collaboration on the earlier design document for the 2024 lifetime capture rules, to @compiler-errors for helpful discussions and insights on this topic, and to all who reviewed this RFC and provided useful feedback and suggestions.  Thanks for working to make Rust better.


Change Suba 4 Cluster to Active from Completed

Field Regional Director accidentally marked project complete and needs administrator to revert to active.

@michaelmarshall I'm not sure who will own these, but the Field team needs an admin-level assistance here and I think Devs are currently the only ones able to do this.

Done.


Vulnerability roundup 85: antiword-0.37: 1 advisory

search, files

[ ] CVE-2014-8123 (nixos-20.03)

Scanned versions: nixos-20.03: a84b797b28e. May contain false positives.

Requires writing and applying a patch: http://www.winfield.demon.nl/ is not updating upstream.
Patch is here - need help verifying it's safe please.

Has anyone experience with antiword? Never used it...

20.03 is Frozen and EOL.
As such, issue is closed.


Can you use this project without the raspberry pi display?

@dauledk, sure! Any HDMI display will work just as well.


Twilio device ready is not giving any callbacks

Hi I am trying to implement twilio for voice calls in my react native project.
I have successfully installed the npm
and when i do initWithToken i am getting success
const success = await TwilioVoice.initWithToken("twilio token is sent here");
But i am not able to receive any call backs in the listners.
  TwilioVoice.addEventListener('deviceReady', () => {
      console.log('deviceReady ===========');
 });

I am not able to proceed further without getting any events for the listners.
My applicaiton is in foreground and i tries in both android and ios
Below are the verisons used
"react-native-twilio-programmable-voice": "^3.21.3
pod used   pod 'TwilioVoice', '~> 2.0.0' for ios
react-native-cli: 2.0.1
react-native: 0.62.2

Hi, since a long time has passed I will be closing this issue. Read our repository update in #158. I invite you to reopen this issue when you still have problems so we can debug the problems together.


feat: Reverse Horizontal Button Option Added

Version 2 is released with much better integration for this PR. I changed how it should have been implemented, please take a look:
https://github.com/WrathChaos/react-native-counter-input/releases/tag/2.0.0
Also, the whole library is converted to a modern functional component.
@deLTreeTech
@cyril36


Support installing dependencies from a secured PyPI repository

As of version 1.8.0, Habushu supports publishing to a secured PyPI repository.  At the same time, it does not support installing dependencies from a secured PyPI repository.  It would be nice if the same security mechanism used for publishing could also be leveraged for installing.  In fact, if seems like it as intended and we probably just missed this when we originally added this fucntionality:

If publishing packages to or consuming dependencies from a private PyPI repository that requires authentication, add your repository credentials to your Maven's settings.xml file, usually located under your ~/.m2 folder. See the Configuration section below on how to
   <server>
       <!-- ID of the PyPI repository - this ID will be used to reference this repository in
            the habushu-maven-plugin configuration -->
       <id>private-pypi-repo</id>

     <!-- Username of the account by which to access the PyPI repository -->
      <username>pypi-repo-username</username>

       <!-- Password of account by which to access the PyPI repository; should be encrypted as per Maven best practices  -->
       <password>{encrypted-pypi-repo-password}</password>
   </server>

This has been addressed in PR 73.


isComputedRef(any)

What problem does this feature solve?
There is already isRef utility to check variable is Ref.. but as I am using refs in my composable as readonly, so I am supporting also computedRefs as input... pattern taken from docs:
if (isRef(url)) {
    // setup reactive re-fetch if input URL is a ref
    watchEffect(doFetch)
  } else {
    // otherwise, just fetch once
    // and avoid the overhead of a watcher
    doFetch()
  }

So I want to augment that not only if (isRef(url)) but also if (isComputedRef(url))`
What does the proposed API look like?
It can be either separate util:
isComputedRef()
or it could be parameter of isRef(url, true)

Also I don't see limitation, why unref() could not return value of ComputedRef instance 🤔

computed properties are refs. Consequently, isRef and unref already work with computed properties.


Updated Grade Management into UserGuide.adoc

Pull Request Test Coverage Report for Build 39

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 92.811%

Totals

Change from base Build 35:
0.0%

Covered Lines:
1433

Relevant Lines:
1544

💛  - Coveralls


[ re #270 ] Make extra-args work more appropriately

PR #270 introduces --extra-args option enabling us to pass additional arguments to the compiler. But this options works in an unexpected way sometimes: e.g.

it is fully ignored in commands like build, cleanbuild and, I think, install;
extra args from local pack.tomls are stacked together, but only the last CLI option is taken into account.

What I propose is to pass extra-args to each call to the compiler (except for the very special internal calls of pack to the compiler using idrisExec function directly) so that any current and future command would respect this option. Also, I propose to take all passed extra arguments into account.
The only change that I made and I'm not certain about is the order: currently for the REPL options, where now --extra-args are used, those options are in the right of pack's own options, while I made them to be on the left. I personally think this is, actually, good, since we don't want user extra options to fiddle or override options that are important to pack itself. But this behaviour may break current behaviour is case of existing abuse of --extra-args option.

Also I propose to clean up types a little bit. Unlike rlwrap arguments, there is no need to distinguish between not set extra arguments and empty list of extra arguments, so there is no need to have a type isomorphic to Maybe CmdArgList, so let's clean code up and remove unneeded equivalent state representation. I made this a separate commit to (hopefully) make review easier.

Pinging @0xd34df00d as the original option's author. What do you think of the order change?


Support @clientName and @encodedName in dotnet CodeGen

As encodedName is introduced in 0.52 of TypeSpec.
model Widget {
  @key id: string;

  @encodedName("application/json", "WidgetWeight")
  weight: int32;

  color: "red" | "blue";
  @added(Versions.v2) name: string;
}

And @clientName is introduced in this PR https://github.com/Azure/typespec-azure/pull/127/files.
Please support them in the CodeGen.

Tcgc abstract that away from you and should have just worked. Call getLibraryName

The adoption of TCGC is still in progress.  https://github.com/Azure/autorest.csharp/pull/4185
We may implement that separately to unblock customer and then move to using TCGC.  cc @m-nash

any progress on this? are we still blocked on doing this migration?

any progress on this? are we still blocked on doing this migration?

I'm blocked by https://github.com/Azure/autorest.csharp/pull/4212


fix foundry reference link

What changed? Why?
Fixed a broken reference link to Foundry
Notes to reviewers
How has it been tested?

🟡 Heimdall Review Status

Requirement
Status
More Info

Reviews

🟡
0/1

Denominator calculation

Show calculation

1 if user is bot
0

1 if user is external
0

From .codeflow.yml

1

Additional review requirements

Show calculation

Max
0

0

From CODEOWNERS

0

Global minimum
0

Max

1

1

1 if commit is unverified
0

Sum
1


Problem with restarting

If I die and my time is greater than 25s (phase 2), when I restart the game I can't the triangle which indicate my position. So I can't play anymore (need to reload the page)

Otherwise, you did a great job ! :)

Ok I see ^^


Portals and Related Sets

What about portals and related records? When RESTfm will support  it?

Amanbolat,
We have no plans to support portals in RESTfm.  It doesn't really work well with a REST model unless you also have transactions, which the PHP API doesn't support.
You can still do multiple related data sets via different layouts, but they need to be done in different requests.  Alternatively you can script changes to related records.
Cheers,
Nick

On 10 May 2016, at 4:02 AM, Amanbolat Balabekov<EMAIL_ADDRESS>wrote:
What about portals and related records? When RESTfm will support it?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub https://github.com/GoyaPtyLtd/RESTfm/issues/6


HB-7694: Adapter configuration rework

Adopt new PartnerAdapterConfiguration protocol

Looks good but I think we banner size logic should be addressed separately (and I saw your comment in PR #53)

Oops, thanks for catching that. I had some local changes drafted to answer Alex's PR comments, and they got in by mistake. Backtracked now


Enhancement: Add SEO parameters to theme

Expected Behavior

I suggest an improvement to implement SEO code to websites.
The implementation is following the description in the following blog:
https://keithpblog.org/post/hugo-website-seo/
I've implemented the changes on my own site and they are working fine and easy to set.
I'll be happy to submit a PR if relevant to the general public
Current Behavior

The SEO parameter do not implemented today in theme and needed to be added manually.
Possible Solution

If not implemented on theme level, one could follow the instructions above to set it manually.
Steps to Reproduce or Template with Error (for bugs)

N/A
Context

I was trying to push my site via the search engines and was looking for the right way to do so on Hugo
Your Environment

Hugo Version:
0.35
Browser:
OSX/iOS Safari
Desktop or Mobile:
Both
Link to your project:
https://elv8.co

I do think that this is something that would be worthwhile for the theme. The majority of people will be looking for this (I assume). As long as its easy to customize for the user, I'd say go ahead and throw the PR up unless someone else has something on the topic.

@pacollins - sure I'll do it and add the relevant instructions and links to the readme file


Update gnosis sync url on consensus client

Changes:

Update Gnosis sync Url on Consensus Client

Types of changes

[x] New feature (non-breaking change which adds functionality)

Codecov Report
Base: 81.08% // Head: 81.08% // No change to project coverage :thumbsup:

Coverage data is based on head (a830bd4) compared to base (d34e8a5).
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff            @@
##           develop     #178   +/-   ##
========================================
  Coverage    81.08%   81.08%
========================================
  Files           40       40
  Lines         2517     2517
========================================
  Hits          2041     2041
  Misses         391      391
  Partials        85       85

Flag
Coverage Δ

unittests
81.08% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


when starting minecraft through prismlauncher screen flickers after loading screen

Describe the bug
Minecraft flickers red or black when starting through prismlauncher
Steps To Reproduce
Steps to reproduce the behavior:

Install latest prismlauncher
Run Minecraft
Wait for loading to finish

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
Video because screenshot wont work
out.webm
Additional context
When starting older versions, it complains about no glibc
Metadata
(I use flakes)
 - system: `"x86_64-linux"`
 - host os: `Linux 6.1.62, NixOS, 23.11 (Tapir), 23.11.20231119.e4ad989`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.1`
 - channels(root): `"home-manager, nixos"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Priorities
Add a :+1: reaction to issues you find important.

@TheBunnyMan123
I had glibc issues too that was caused by java being set to a nix store path, for example /nix/store/q6g0d4ay38ydn99z2n5249fma8267ym3-openjdk-19.0.2+7/lib/openjdk/bin/java which I assume causes issues after a system update.
To fix this, make sure your java (Prism Launcher -> Settings -> Java -> java path OR instance -> Edit -> Settings -> Java installation) is set to java  and you have the correct version of java installed.
For running old and new minecraft versions, I make symlinks to java 8 and 21 using Nix, and just put java-8 or java-21 to the java field for each instance:
environment.sessionVariables.PATH = [
  "$HOME/.local/bin"
];

home-manager.users.<user> = {
  home.file = with lib; with pkgs; {
    ".local/bin/java-8".source = getExe' jdk8 "java";
    ".local/bin/java-21".source = getExe' jdk21 "java";
  };
}

The flickering black screen is most likely a graphics driver issue, have you installed them correctly? Nvidia needs some extra tweeking.

This issue should be resolved. Feel free to reopen, if not.


cache/s3: replace deprecated S3 function

This replaces the deprecated session.New().
go doc github.com/aws/aws-sdk-go/aws/session.New

Deprecated: Use NewSession functions to create sessions instead. NewSession has the same functionality as New except an error can be returned when the func is called instead of waiting to receive an error until a request is made.

Pull Request Test Coverage Report for Build 91af08c66-PR-723

3 of 5 (60.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.02%) to 45.624%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

cache/s3/s3.go
3
5
60.0%

Totals

Change from base Build 765aa0eea:
0.02%

Covered Lines:
5385

Relevant Lines:
11803

💛  - Coveralls


Train Epoch: [0]  [     0/131135]  eta: 29 days, 13:55:04  lr: 0.000020  loss: 6.5415  time: 19.4891  data: 2.0020  max mem: 0

这个模型训练很慢吗？怎么可能29天呢？

In most scenarios, training on 8x3090 can be completed in less than a day. Could you provide the specific dataset and resources used?


Any chance to get a package compatible with net standard 2.x instead of NET5 only?

Ok I found the fork of this project in another repo

@arivera12 Can you share the link please? Thanks!

@jtsoya539
https://github.com/BlazorExtensions/Notifications


fix:fix swagger docs(#1941)

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Show the action to reopen closed repositories in Source Control Repositories view

Testing #203035
One has to use command pallette to reopen closed repositories. As we are providing the capability of closing a repository and other repositories in SCM Repositories view, it is expected to also have the action to reopen them from the same place.

Duplicate of https://github.com/microsoft/vscode/issues/197466


visibility of values with 0 occurrences

On the Utterance Search page, items with 0 occurrences are still visible.
e.g.

Fixed & confirmed


Markdownify post titles

Thank you very much for the beautiful theme.
I would like to make some of my blog post's titles have italics and/or code formatted text, but doing so gives me this error:

(I'm using Rstudio's blogdown to render the content, BTW)
Is there a way to modify the layouts documents to markdownify the titles? Where should we make such modifications?

You got it!


drag-and-drop packetization proof of concept

Build a POC of how to do packetization -- given how interactive this would be, I don't know if Figma is the best choice for designing this but @carolinemao feel free to correct me.
https://react-dnd.github.io/react-dnd/about looks like a reasonable library for doing this.

#22 adds a skeleton of this, will fill out with more functionality (swapping questions if there's already one in the slot, only allowing moves in packet or in category)


Restructure Navigation

Value Proposition
As a user
I want to I want to have all controls that affect a single podcast on this podcast's details page
So that I can easily find them.
Description

Acceptance Criteria

[ ] A new podcast details page replaces episodes view.
[ ] The podcast's ID is in the URL so that every podcast has its own detail page.
[ ] No "Edit Tags" button in the podcast list anymore.
[ ] No "Episodes" button in the header navigation anymore.

Tasks

[ ] Change mechanism for podcast selection from global state to routing.
[ ] Move buttons around.

Complexity
M

I first thought that the right side is an additional page that shows up, after clicking a button.
Is the left side the episodes view, which will be replaced by the right side? The title of the left side says "podcast list", so I'm a little confused.

A new podcast details page replaces episodes view.

As a reader I'd like to know what you mean by "episodes view". You know it, but I don't. Adding that one as additional screenshot would be helpful.

Move buttons around.

This sounds arbitrary.
Suggestion: Repositioning buttons.