Make deployment match labels configurable everywhere

What this PR does / why we need it:
Very small PR that makes all the deployment match labels configurable. The default matchLabels remain untouched to ensure backwards compatibility. If someone is already using v1.0+ they will not notice the change. If someone is using an older cert-manager version where they configured the matchlabels, this makes it easier for them to update that deployment by passing in the matchLabels they want. If the matchlabels are changed, then a deployment update since they are considered an immutable field.
Which issue this PR fixes: fixes #3371
Added the ability to configure the deployment matchLabels dictionary of the Helm templates

/assign @munnerz

Thanks for this PR, can you also document this in the README file?
Where is this exactly used? Probably missing something but the labels it is matching are not configurable?

@meyskens to give you a bit more context, suppose that you are using the Helm templates from an old cert-manager version, (more than a year old) that ppl just forgot to update 😓. The deployments that were created had the following labels:
metadata:
  labels:
    app: cert-manager
    chart: cert-manager-v0.1.0
    release: cert-manager
    heritage: Helm
spec:
  selector:
    matchLabels:
      app: cert-manager
      release: cert-manager

On top of that we are using Kustomize to add some custom labels:
commonLabels:
  app: cert-manager
  project: something

Which converts the sections above into this:
metadata:
  labels:
    app: cert-manager
    chart: cert-manager-v0.1.0
    release: cert-manager
    heritage: Helm
    project: something
spec:
  selector:
    matchLabels:
      app: cert-manager
      release: cert-manager
      project: something

The differences in labels are of little consequence. The main issue is with the matchLabels. They are an immutable field, because they are used by the deployment controller to find which pods are under its supervision. So now that I have to update cert-manager to the latest version I have a problem, because the labels I am getting from the latest Helm templates are:
metadata:
  labels:
    app: cert-manager
    app.kubernetes.io/name: cert-manager
    app.kubernetes.io/instance: cert-manager
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/component: "controller"
    helm.sh/chart: cert-manager-v0.1.0
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: cert-manager
      app.kubernetes.io/instance: cert-manager
      app.kubernetes.io/component: "controller"

The kustomization that we are applying on top is giving us this:
metadata:
  labels:
    app: cert-manager
    app.kubernetes.io/component: controller
    app.kubernetes.io/instance: cert-manager
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: cert-manager
    helm.sh/chart: cert-manager-v0.1.0
    project: ...
spec:
  selector:
    matchLabels:
      app: cert-manager
      app.kubernetes.io/component: controller
      app.kubernetes.io/instance: cert-manager
      app.kubernetes.io/name: cert-manager
      project: ...

Since the matchLabels have changed the API master will reject this deployment.
One hacky way of fixing this would be to add a section in our kustomization that deletes the existing matchLabels, so that the commonLabels section can then take effect and set only the ones that we want. But that is not a good solution in my opinion, because we are adding an extra step and the success of this scheme starts depending on the sequence that these operations will take place.
So the simplest solution is to allow a user to define the matchLabels using either the Values or the CLI in a simple and straightforward way and not depend on kustomize implementation details. If the user doesn't set any value then the default matchLabels will be the ones that are already in place and nobody will notice.
PS: I forgot to update the README, I'm doing it now.
PS 2: I hope this describes the problem accurately.

I am a bit against adding this in and exposing it to our users for a very edge case that we didn't support. When changing these in the past we recommended to delete the deployments in our upgrade instuctions since cert-manager isn't a critical component to be 100% available we think it is a good compromise.

@meyskens I get your point but in this case it's really difficult for us, since we have way too many clusters under our supervision to fix things like that manually. When you have more than 10 clusters to update that is a lot of manual work and basically 100% guarantee that something will break because of a lack of automation. This is a small change that will make a big difference for us

@meyskens @munnerz can I get your thoughts on the status of this PR?

@meyskens @munnerz is there an update on whether this PR can be landed or not? We would find it really useful to avoid a manual fix on our end

We changed the set of labels and matchLabels in v0.14.0 (in https://github.com/jetstack/cert-manager/commit/b7fe6a72865311ad2f502cf22c4e86cd0803d859), and that prevents people from upgrading. I think we should do our best to make the upgrade process for people on v0.13 and below as easy as possible.
I am in favor of adding deploymentsMatchLabel. That said, it would be good to add more details in values.yaml as to why this field has been added, e.g.:
# Optional match labels for the cert-manager deployment. If no value is set
# the default labels will be used. This field has been added to help people
# upgrade from older versions of the cert-manager Helm chart (v0.13 and below)
# by working around immutable matchLabels on existing Deployments.
deploymentMatchLabels: {}

@lambchr @ptzianos Is it still an issue?

TL;DR: after more thinking, I changed my mind and I think deploymentMatchLabels is too specific and should not be added.

From what I can read, you are trying to upgrade from cert-manager v0.1.0 (Oct 13, 2017) to a version after v0.14.
We changed the matchLabels twice:

In v0.9.0 (https://github.com/jetstack/cert-manager/pull/1769/files), the release field was removed from the matchLabels, breaking the Helm upgrade. That forces people to manually remove the old Deployment before upgrading.
🔥 This breaking change was not documented in release-notes-0.9. The upgrading-0.8-0.9 document does mention that the Deployment must be deleted before upgrading due to the change from apps/v1beta1 to apps/v1, but it does not mention the matchLabels breaking change.
In v0.14.0 (https://github.com/jetstack/cert-manager/pull/2654/files), the app and app.kubernetes.io/managed-by labels were removed. Which also forces people to manually remove the old Deployment. This is detailed in both release-notes-0.14) and in upgrading-0.13-0.14).

AFAIK the deploymentMatchLabels workaround can only be used if you use a tool like kustomize to override the labels and matchLabels.
The deploymentMatchLabels workaround cannot work if you used the default labels, since keeping the old matchLabels would cause a mismatch between matchLabels and the actual Pod labels (one matchLabel would be missing from the new Pods).
Here are the changes in cert-manager from v0.8 to v0.9. They are breaking since the matchLabels was changed (requires deleting the Deployment):
 spec:
   selector:
     matchLabels:
       app: cert-manager
-      release: some-release-name
+      app.kubernetes.io/name: cert-manager
+      app.kubernetes.io/instance: cert-manager
+      app.kubernetes.io/managed-by: Helm

Let's imagine that we use deploymentMatchLabels to keep the old matchLabels and to avoid deleting the old Deployment:
# values.yaml
deploymentMatchLabels:
  app: cert-manager
  release: some-release-name

This new Deployment cannot be applied since the Pod labels are not a subset of the matchLabels ( due to release).
Similarly, with v0.14, the removal of matchLabels prevents you from using the deploymentMatchLabels workaround to keep the same matchLabels before/after:
 spec:
   selector:
     matchLabels:
-      app: cert-manager
       app.kubernetes.io/name: cert-manager
       app.kubernetes.io/instance: cert-manager
-      app.kubernetes.io/managed-by: Helm
+      app.kubernetes.io/component: controller

The only use for the deploymentMatchLabels workaround would be to add your own labels e.g. using some post-processing like kustomize. Taking your example above:
metadata:
  labels:
    app: cert-manager                    # Custom, overriden by kustomize.
    chart: cert-manager-v0.1.0
    release: cert-manager
    heritage: Helm
spec:
  selector:
    matchLabels:
      app: cert-manager                  # Custom, overriden by kustomize.
      release: cert-manager

Thanks to the fact that you work around the fact that app: cert-manager was removed in v0.14, deploymentMatchLabels allows you to do the trick:
# values.yaml
deploymentMatchLabels:
  app: cert-manager
  release: cert-manager

That works, but it seems to be a very convoluted way (i.e., re-adding the remove app: cert-manager) of "not" deleting the old Deployments.
I don't think I would like to see deploymentMatchLabels added since it does not work with the vanilla Helm chart.

I will be closing this PR for now. Please feel free to comment here if you feel I misunderstood the issue.
/close


Refactor remote store flow to support any path type

Description
This PR is a sub task of feature request https://github.com/opensearch-project/OpenSearch/issues/12567 and being tracked in meta issue - https://github.com/opensearch-project/OpenSearch/issues/12589.
In the prior PR https://github.com/opensearch-project/OpenSearch/pull/12607 & https://github.com/opensearch-project/OpenSearch/pull/12753, we have introduced remote store path type in the customData field in IndexMetadata and handled association of path types of indexes during snapshot restore. In this PR, we are refactoring existing remote store flows to add support for using any remote store path type with backward compatibility.
In brief, we are doing follow things -

We are replacing all places where we were deriving paths manually (like RemoteSegmentStoreDirectoryFactory.java, RemoteStoreLockManagerFactory.java, TranslogTransferManager & BlobStoreRepository.java - snapshots related) with deriving path using RemoteStorePathType.
We provide implementation for the existing fixed prefix patten, and handle the wiring also.
Write UTs for some new classes.

Related Issues
Resolves #12790

Check List

[x] New functionality includes testing.

[x] All tests pass

[x] New functionality has been documented.

[x] New functionality has javadoc added

[x] Failing checks are inspected and point to the corresponding known issue(s) (See: Troubleshooting Failing Builds)
[x] Commits are signed per the DCO using --signoff
~[ ] Commit changes are listed out in CHANGELOG.md file (See: Changelog)~
~[ ] Public documentation issue/PR created~

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

testConcurrentDecommissionAction

❕ Gradle check result for 21636af: UNSTABLE

TEST FAILURES:

      2 org.opensearch.cluster.coordination.AwarenessAttributeDecommissionIT.testConcurrentDecommissionAction

Please review all flaky tests that succeeded after retry and create an issue if one does not already exist to track the flaky failure.

Flaky test - https://github.com/opensearch-project/OpenSearch/issues/12197

❌ Gradle check result for e21ec8f: FAILURE
Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

Flaky test - https://github.com/opensearch-project/OpenSearch/issues/10558 and https://github.com/opensearch-project/OpenSearch/issues/12197

❕ Gradle check result for d9e12db: UNSTABLE

TEST FAILURES:

      2 org.opensearch.index.shard.RemoteStoreRefreshListenerTests.classMethod
      1 org.opensearch.smoketest.SmokeTestMultiNodeClientYamlTestSuiteIT.test {yaml=search.aggregation/20_terms/string profiler via global ordinals}
      1 org.opensearch.index.shard.RemoteStoreRefreshListenerTests.testRefreshSuccessAfterFailureInFirstAttemptAfterSnapshotAndMetadataUpload

Please review all flaky tests that succeeded after retry and create an issue if one does not already exist to track the flaky failure.

flaky tests - https://github.com/opensearch-project/OpenSearch/issues/8131 and https://github.com/opensearch-project/OpenSearch/issues/9332

Auto backport failed, raising manual backport.


Precise & Minimal Permissions for Service Providers in User Workspaces

This epic is concerned with API interactions between service providers and user workspaces. Service providers need to access instances of their resources and related resources in the workspaces of users that have bound their APIs. They may also need to limit the permissions of the user on instances of those resources. These permissions need to be minimal.
Tasks for this epic are tracked in this project view.

"user workspaces" is confusing. This is not about user home workspaces, but rather any kind of workspace with bindings.


Telltail doesn't detect auto hot key

I would need more info to resolve this for you. Have you installed AutoHotkey (AHK) or have you just unzipped its content somewhere? And if you have installed me, could you tell me what is the process you took (used installer from website, used scoop, chocolatey, winget or something else)?

Please delete the CLI you have downloaded on your PC and download from the webpage again. I've updated the CLI and it would now be able to detect AutoHotkey.

Closing the ticket for now. If the issue appears again, we can reopen it.


Clarify syntax of csv file containing search terms

It is not 100% clear from the provided example csv file what are the search terms, excluded terms and labels. A short description would not go amiss. Thanks.

Thanks for raising this issue.
This is true - I will extend the README to help new users...


Release 1.5.0

Codecov Report

Merging #65 (33f4872) into main (9b57680) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##              main     #65   +/-   ##
=======================================
  Coverage     9.62%   9.62%
  Complexity      14      14
=======================================
  Files           35      35
  Lines          686     686
  Branches        52      52
=======================================
  Hits            66      66
  Misses         618     618
  Partials         2       2

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


fix mvn soft link for integration tests

can you add some info on why this was needed?

its not needed for running the tests, when building jars outside container as we do in tests, it was there to run the tests from fetching the via git, I came across this broken link while doing some testing in container, have commented out the mvn installation by default and added comment

@nishantmonu51 the maven link works for me. If this is not needed for integration testing, let's just remove it from the docker image.

removed


org settings: Enforce unsigned integers on input elements.

There is no simple HTML way to achieve this so used the jQuery hack.
It also:
Reverts "org settings: Handle floating point durations better for
time limits."
This reverts commit ccd5581bcd88921b1be9934727cdc5109c03ca68.
Testing: Manual testing.

@rishig what are your thoughts on this?

I don't think this PR is required now.


Update calls to 3rd party modules for 3.1.7 compatibility

I.E.
if (class_exists('GridFieldBulkImageUpload')) {
			$config->addComponent(new GridFieldBulkUpload());
			$config->getComponentByType('GridFieldBulkUpload')->setConfig('folderName', 'Uploads/ProductImages');
		}

to
if (class_exists('GridFieldBulkImageUpload')) {
            $config->addComponent(new GridFieldBulkUpload());
            $config->getComponentByType('GridFieldBulkUpload')->setUfSetup('setFolderName', 'Uploads/ProductImages');
        }

closed via #175


question(service-worker): what percentage of mobile browsers support either SW or AppCache?

From the design doc:

but there are other mobile browsers that have high usage in specific markets which also don't support the API.

Is there data available to indicate what percentage of market will be supported by supporting both AppCache and SW?

http://caniuse.com/#feat=offline-apps
http://caniuse.com/#feat=serviceworkers
pretty decent coverage

According to their stats, Opera Mini is the largest holdout at 4.79% of global marketshare. Overall, looks like 91.8% of users can benefit from the design.


Suddenly unable to access /etc/firezone

Hi! It seems something happened with my file permissions and I'm unable to access the /etc/firezone directory. Anyone know what the default permissions for it are? Currently, it's showing up as:
drwx------   2 firezone firezone   4096 Nov 19 21:14 firezone
Thanks!

mine are 0755 root:root (docker)
0700 firezone:firezone on local install (fedora)
looks consistent


QUESTION - install packages into spyder.app (spyder-3.0.2-py3.5.dmg)

Description of your problem
In spyder.app accquired from spyder-3.0.2-py3.5.dmg, is it possible to install new packages, for example pandas? If yes, how to do it? Below are outputs when I tried executing command inside Ipython panel.
In[7]: !pip install pandas /bin/sh: /usr/local/bin/pip: /Applications/Spyder-Py2.app/Contents/MacOS/python: bad interpreter: No such file or directory
Thank you.
Versions and main components

Spyder Version: 3.0.2
Python Version: 3.5
Operating system: Mac
Mac DMG distribution

Some things about your question:

No, it's not possible to install new packages in our Mac app.
Pandas comes with the app.
You can use the app with packages installed in a different Python interpreter. You can select a new interpreter in Preferences > Main interpreter


[BUG] WithUpserts not updating, using sql server without unique key

Prerequisites

[X] Checked if your Laravel Excel version is still supported: https://docs.laravel-excel.com/3.1/getting-started/support.html#supported-versions
[X] Able to reproduce the behaviour outside of your code, the problem is isolated to Laravel Excel.
[X] Checked that your issue isn't already filed.
[?] Checked if no PR was submitted that fixes this problem.
[X] Filled in the entire issue template

Versions

PHP version: PHP 7.4.9 (cli) (built: Aug  7 2020 19:23:06) ( NTS )
Laravel version: Laravel Framework 8.19.0
Package version: * 3.1.26

Description
When trying to use With Upserts, it doesn't update the already existing rows in the model. The unique field is a regular text field, without unique/primary key. This database is being hosted on a mysql server. As stated in the documentation, this isn't required on sql servers.
Steps to Reproduce
I export only fields product_id, stock_sn & stock_mo as the others are being dynamicly updated by the site from this table (here's the migration):
        Schema::create('products___stock_stores', function(Blueprint $table){             $table->bigIncrements('id');             $table->text('product_id');             $table->integer('stock_sn')->default('0')->nullable();             $table->integer('stock_sn_reserved')->default('0')->nullable();             $table->integer('stock_mo')->default('0')->nullable();             $table->integer('stock_mo_reserved')->default('0')->nullable();             $table->timestamps();         });
This is the code I use to importing the excel file:
`
namespace App\Imports;
use App\ProductStockStores;
use Maatwebsite\Excel\Concerns\ToModel;
use Maatwebsite\Excel\Concerns\WithHeadingRow;
use Maatwebsite\Excel\Concerns\WithUpserts;
class ProductStockImport implements ToModel, WithHeadingRow, WithUpserts{
public function model(array $row){
return new ProductStockStores([
"product_id"        => $row['product_id'],
"stock_sn"          => $row['stock_sn'],
"stock_mo"          => $row['stock_mo']
]);
}
public function uniqueBy(){
    return 'product_id';
}

}
`
Expected behavior:
I expect the import to look for the table with the same product_id, update those. If the row doesn't exist, create a new one.
Actual behavior:
It just creates new rows. I get this query when I log all queries:
insert intoproducts___stock_stores (created_at, product_id, stock_mo, stock_sn, updated_at) values (?, ?, ?, ?, ?) on duplicate key update product_id = values(product_id), stock_sn = values(stock_sn), stock_mo = values(stock_mo), updated_at = values(updated_at) [2020-12-17 23:42:01, 999-900, 20, 10, 2020-12-17 23:42:01]
Additional Information

As there was no option to add an unique key to a text type column, I changed the column to a varchar.
This bug can be ignored as the issue is resolved.


Header disappears

Configuring a header as with other modules (example), the header disappears as soon as the data is loaded.
{
    module: 'MMM-json',
    header: 'JSON test',
    position: 'bottom_left',
    config: {
        url: "https://jsonplaceholder.typicode.com/users", // Path to your json api
    }
},

The header is showing while data is still loading though...

Ahh, thanks for the hint. This was my first module so I did not get it right the first time.
I implemented the header inside the config, but now I changed it so that the configuration by the framework will take precedence. So it should work now. Please report back, if it is resolved.

Thanks for your quick reply and fix!

:tada: This issue has been resolved in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


minor fixes

Harness Developer Pull Request
Thanks for helping us make the Developer Hub better. The PR will be looked at
by the CODEOWNERS.
What Type of PR is This?

[ ] Issue
[ ] Feature
[ ] Maintenance/Chore

If tied to an Issue, list the Issue(s) here:

Issue(s)

House Keeping
Some items to keep track of. Screen shots of changes are optional but would help the maintainers review quicker.

[ ] Tested Locally
[ ] Optional Screenshot.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://660d5afdcab358ed5ec10551--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://660d5bb4b3751fee728a09db--harness-developer.netlify.app


Add Image Access Chapter

closes https://github.com/KhronosGroup/SPIRV-Guide/issues/24

I recognize that this feedback is entirely unsolicited, but I thought you SPIR-V experts might appreciate the perspective of someone who is still learning this

wrong, the feedback is VERY well appreciated and this guide is quite literally designed for someone learning SPIR-V so seem like the perfect audience to me!

I've applied the various feedback, I think this has had enough time to acquire feedback and going to merge now, like all documentation, it is a living, breathing thing and feel what we have here is better then not having anything and always open for constant improvements to this topic


Now should use ES6,and update the parameters in the WebView

Thanks for your code. Now I update the Canvas.js using the grammar  of ES6 and update the parameter "html"(out of date) to "source"
I am a Chinese and my English is not very good. Umm, sorry.

I'm currently working on a whole revision of the source code. Your suggestions will be included


Enhancements31

Update the Keepalived installation.
Add the HEALTHCHECK.md.
Add configure_jdk_krbref.sh.
Update NTP installation.
Update install_clouderamanager*.sh to work with CM 6.3.3+.

Looks good.

All checks passed :)


investigation/testground: mustpublish/mustsubscribe

We need to create a simple test-plan that abuses must* commands in the sync client.
From time to time, we can not publish nor receive information from events properly

Now reflecting more, I think this is happening because of this #30


Add Sccache support + add restore-keys + don't save empty cache

Based on/includes #44
Closes #44
Closes #45
Closes #46

ping @hendrikmuhs

@jonashaag
Does this PR superseed the other one? Or do you ask for merging both?

Supersedes the other one.

:+1: I will have a look tomorrow.

As before it would be good to remove the compiled parts, I can compile it myself

Not sure I understand the rationale here. There is a dist folder in the repo, why no always keep it up to date with the source?

Not sure why CI doesn't run.

As before it would be good to remove the compiled parts, I can compile it myself

Not sure I understand the rationale here. There is a dist folder in the repo, why no always keep it up to date with the source?

This way, I don't need to review it and as I am responsible for this repo, it is better if I push the code myself. It is a question of security and trust. This doesn't mean that I am not trusting you. I am very thankful about your contribution!

Not sure why CI doesn't run.

I think this is a security mechanism. github doesn't run those changes so PR can't be abused to mine bitcoins or do other malicious stuff. There might be a magic command that I can use to trigger a CI, I run. I will check the docs.

This way, I don't need to review it

The CI code that I added makes sure that the dist/ folder is up-to-date with the .ts files.

This way, I don't need to review it

The CI code that I added makes sure that the dist/ folder is up-to-date with the .ts files.

Ok, so after merge the CI should fail. I think  that's ok. I can fix it by pushing the changes.
I could not find a way to approve you workflow to run it as part of the PR, so I would just merge it and fix it later on. The idea is great, I wonder if it is possible to fully automate it. In another project I am generating code and push it to a branch. I like to explore this idea, but this can be done later.

Here we go!

@jonashaag Thank you!
I merged it, uploaded the changes and created a (pre-)release. The worflow has some errors, so requires some tweaking, I only fixed a small issue. Maybe you want to look into it yourself.
I tagged it as v1.1.0 so it is possible to try and test it. Once we are fine I can release it as v1.2.0.


Create specs for running distributed training with/without GPUs.

Some timing measurements
2 Worker CPU: 45.934 sec/step
2 Worker GPU: 4.659 sec/step
@vishh  @foxish PTAL

LGTM. kubectl apply -R -f kubeflow would run these examples as well. May be we should move all the manifests into a single directory before merging this?

lgtm


New Bug of MqttBufferReader

Bug1
There are two logical problems here:

An error will occur when _offset is not 0
An error will occur in Big-Endian platform

 #if NETCOREAPP3_0_OR_GREATER
            var value = System.Runtime.InteropServices.MemoryMarshal.Read<ushort>(_buffer.AsSpan().Slice(Position));
            value = System.Buffers.Binary.BinaryPrimitives.ReverseEndianness(value);
#else
            var msb = _buffer[_offset + Position];
            var lsb = _buffer[_offset + Position + 1];

            var value = (ushort)((msb << 8) | lsb);
#endif

fix code:
 #if NETCOREAPP3_0_OR_GREATER
            var value = MemoryMarshal.Read<ushort>(_buffer.AsSpan(_offset + Position));
            if (BitConverter.IsLittleEndian)
            {
                value = System.Buffers.Binary.BinaryPrimitives.ReverseEndianness(value);
            }
#else
            var msb = _buffer[_offset + Position];
            var lsb = _buffer[_offset + Position + 1];

            var value = (ushort)((msb << 8) | lsb);
#endif

Bug2
_maxPosition  is incorrect when offset is not 0
        public void SetBuffer(byte[] buffer, int offset, int length)
        {
            _buffer = buffer ?? throw new ArgumentNullException(nameof(buffer));
            _offset = offset;

            Position = 0;
            _maxPosition = length;
        }

fix code:
        public void SetBuffer(byte[] buffer, int offset, int length)
        {
            _buffer = buffer ?? throw new ArgumentNullException(nameof(buffer));
            _offset = offset;

            Position = 0;
            _maxPosition = offset+ length;
        }

There is also the problem that _offset is ignored on ReadByte and other ReadXX methods. I want to be able to code the full unit test, covering the case where _offset is not 0.

This bug and https://github.com/dotnet/MQTTnet/issues/1592 has no direct relation.


Request::withUri does not respect the $preserveHost argument as per PSR7

From the PSR7 specification:
     * You can opt-in to preserving the original state of the Host header by
     * setting `$preserveHost` to `true`. When `$preserveHost` is set to
     * `true`, this method interacts with the Host header in the following ways:
     *
     * - If the Host header is missing or empty, and the new URI contains
     *   a host component, this method MUST update the Host header in the returned
     *   request.
     * - If the Host header is missing or empty, and the new URI does not contain a
     *   host component, this method MUST NOT update the Host header in the returned
     *   request.
     * - If a Host header is present and non-empty, this method MUST NOT update
     *   the Host header in the returned request.

tl;dr the Host header may be updated even if the$preserveHost parameter is true.
However, the implementation as per v1.4.2 does nothing to the Host header when $preserveHost is true. See: https://github.com/guzzle/psr7/blob/1.4.2/src/Request.php#L113

Is this issue for 1.5 also?

yes


[Feature Request] Allow deleting issues

Feature Description
I would like to be able to completely delete issues (other than through postgres). It can be limited to admin users.
This can be done on gitlab.
Example: spam posted as an issue report. I deleted the links and changed title, but it still stays in the repo.

Screenshots
No response

related #923


Update namespace handling

This updates and fixes the way namespacing is handled, particularly
with regard to aliasing. Previously a SymbolReference was being
created to represent the namespace, but that isn't right since a
namespace isn't an individually referenceable entity. Now the symbol
itself controls how its namespace should be referenced. This ends up
being much more concise to define as an added bonus.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

This will help a ton, I ran into some weird situations while implementing our document serializers.


using the /dashboard URL requires knowledge of the uuid

either allow use of the dashboard name or expose the uuid via the UI.
There is another issue/enhancement to expose a whole bunch of attributes for DB objects, so this could go with that.

Duplicate of #183


Experimental feature i2t

i2t is an optional feature that exposes a new function
in the wasi-nn crate API called convert_image. This
function utilizes the image2tensor crate to open an image
and convert it to a tensor of the desired size. Image
classification is a very common use case for wasi-nn,
this feature aims to make that easier and faster. In
addition, exposing this function in Wasmtime will allow
AssemblyScript WebAssembly code to image2tensor, even
though its written In Rust. Including it in Wasmtime also
results in roughly 50% faster conversion times vs including
image2tensor in the Rust WebAssembly code itself. When
built with the i2t feature, the convert_image function
is then available to be used by the wasi-nn Rust and
AssemblyScript bindings.
See PR for info:
https://github.com/bytecodealliance/wasi-nn/pull/58

Here's my PR for changes to the official proposal. https://github.com/WebAssembly/wasi-nn/pull/14

This is now handled by https://crates.io/crates/image2tensor so no need for this PR.


Unable to install unsloth on ubuntu, python 3.10

when trying to install with the command :  pip install "unsloth[colab-new] @ git+https://github.com/unslothai/unsloth.git"
I get the following error :
Defaulting to user installation because normal site-packages is not writeable
Collecting unsloth[colab-new]@ git+https://github.com/unslothai/unsloth.git
Cloning https://github.com/unslothai/unsloth.git to /tmp/pip-install-wfqafxrq/unsloth_24c4c2b574064d23b47f416e549cb79e
Running command git clone --filter=blob:none --quiet https://github.com/unslothai/unsloth.git /tmp/pip-install-wfqafxrq/unsloth_24c4c2b574064d23b47f416e549cb79e
Resolved https://github.com/unslothai/unsloth.git to commit 72aee4a3a128268c3d1e5cef249626897996645c
Installing build dependencies ... done
Getting requirements to build wheel ... done
Installing backend dependencies ... done
Preparing metadata (pyproject.toml) ... done
WARNING: Generating metadata for package unsloth produced metadata for project name unknown. Fix your #egg=unsloth fragments.
Discarding git+https://github.com/unslothai/unsloth.git: Requested unknown from git+https://github.com/unslothai/unsloth.git has inconsistent name: filename has 'unsloth', but metadata has 'unknown'
ERROR: Could not find a version that satisfies the requirement unsloth (unavailable) (from versions: none)
ERROR: No matching distribution found for unsloth (unavailable)

Ok that is weird unsure why its not working hmmm

Hi, any update on this error?
I'm facing a similar issue:

any update?

Hopefully it should work now - I made the installation process somewhat easier hopefully


yarn migrate fails due to version incompatibility of sequelize-cli

When locally reverted to commit 9b278dd603396af9c9ec678e2e9c4cbf2ed71893, it helped to pass yarn migrate execution.

Dup of https://github.com/near/near-contract-helper/issues/229


Add support for sorting in the /#streams pages (especially /#streams/all)

Now that we have #3989 done, we should add some UI for sorting the list of streams in the /#streams/all page by things like subscriber count, traffic level, etc.  I think the list_render.js library that I think we use on that page already has some basic support for sorting in more structured tables; what we will need is a UI for selecting how one wants it sorted (and also it's possible we need to tweak the sorting system for this).
I think this might be something where we start by doing the implementation with just a basic dropdown menu for selecting sort order (so that we can focus on making the actual sorting logic work).
https://github.com/zulip/zulip/issues/3458 has some specific details that align with this plan that we brainstormed like a year ago.
This is sorta a more specific replacement for the remaining ideas in https://github.com/zulip/zulip/issues/3780

@zulipbot claim

There is another bug with stream sorting that I can create a separate issue for if needed.
When creating a new stream from the mobile app the newly created stream is just appended to the end of the list. The stream list does not appear in the correct order on the webapp without refreshing the view.

Would it be possible to consider also more general sorting scheme? The most important would be to split the list in public/private. Another layer of separation could be created by global / local audience (so if we expect to have a channel with many or few participants).
To explain a bit the context, I have created a Zulip instance for researchers working on some topic, public channels are used for general discussions between everyone, and then collaborators can create a private stream for working on a given project. I think it would be very helpful to disentangle both types of streams.

The original issue as described here was implemented last year, so closing this issue.
@melsophos I think it'd be great to open a new issue to track the idea of supporting filters by public/private (Etc.) -- that's an independent feature.


SyntaxError: Unexpected token import

I'm using the latest node and running jasmine tests on my project only to be met with

jasmine-node spec
Exception loading: /usr/src/app/spec/playground/playground.spec.js
/usr/src/app/src/engine/playground.Soundcloud.js:1 (function (exports, require, module, __filename, __dirname) { import PLAYGROUND from 'playground.js'
SyntaxError: Unexpected token import

my package.json is
{
  "main": "index.js",
  "scripts": {
    "server-server": "nodemon index.js",
    "dev" : "",
    "test": "jasmine-node spec",
    "dev-browsersync": "webpack-browser-sync --webpack false --proxy http://<IP_ADDRESS>:8000/",
    "dev-webpack": "webpack-dev-server --progress --colors --host <IP_ADDRESS> --port 8000  & npm run debug-webpack",
    "start": "webpack --progress --watch",
    "debug-webpack": "node_modules/.bin/weinre --boundHost -all-",
    "postinstall" : "npm run server-server | npm run start"
  }
  "devDependencies": {
    "jasmine":"*",
    "browser-sync":"*",
    "jasmine-await":"*",
    "jasmine-node":"*",
    "request":"*",
    "webpack":"*",
    "nodemon-webpack-plugin":"*",
    "babel-core": "*",
    "babel-loader": "*",
    "babel-preset-env": "*",
    "babel-polyfill": "*",
    "babel-cli":"*",
    "jasmine-core":"*",
    "browser-sync-webpack-plugin":"*",
    "jasmine-expect":"*",
    "imports-loader":"*"
  }

What can be the problem here?

You get this kind of error because import is an ES6 feature and not available unless transpiled with something like babel.
To just start my app, I have something like "start": "babel-node index.js", which works fine. However I still get the error for my dev script (basically the same as your "server-server" script): "dev": "NODE_ENV=development nodemon index.js".
Anyone knows how to fix the "import" issue when using nodemon?


Fireworks for successful upload

There are no fireworks to congratulate users who successfully upload data, like qiime-db did. They don't need to be fireworks. Maybe a dancing cheetah? But there should be something. Nothing says a job well done quite like fireworks...

:+1:

:+1:

:fireworks:

:fireworks:

word

Gonna close for now.


Fix build failure when cross-compiling to Android 21

See https://github.com/rust-lang/time/issues/71 :
.../time/src/time_helpers.c:42:15: error: static declaration of 'timegm' follows non-static declaration
static time_t timegm(struct tm tm) {
^
In file included from .../time/src/time_helpers.c:12:0:
.../NdkStandalone/sysroot/usr/include/time.h:101:15: note: previous declaration of 'timegm' was here
extern time_t timegm(struct tm) LIBC_ABI_PUBLIC;
^

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see CONTRIBUTING.md for more information.

Thanks!


Polymer.mixin2

It seems that mixin2 isn't a Polymer method anymore, removing the lines that include Polymer.mixin2 fixes the issue, but im not sure if the removal produces side effects.

by the way im using vulcanize 0.7.9 and the latest polymer

mixin2 is not part of polymer, but something core-focusable adds to enable a certain mixin setup required by a few elements.
Which elements are you including that you see this error?

I am running into the same issue.  Pre-vulcanized it is fine.  After vulcanize, I receive:
TypeError: Polymer.mixin is not a function
TypeError: document._currentScript is undefined
ReferenceError: Platform is not defined
TypeError: document.registerElement is not a function
TypeError: element.init is not a function
ReferenceError: CustomElements is not defined

it was my fault, i had an unfinished import tag, something like <link rel="import"

While I know the OP's issue was resolved due to an unfinished import tag however I'm experiencing the same issue when including paper-button. Ultimately the vulcanized stuff fails unless I explicitly include scripts from within the paper-button-base object itself at the top of my html file.
<link rel="import" href="ext-lib/polymer/polymer.html">
<script src="ext-lib/core-focusable/polymer-mixin.js"></script>
<script src="ext-lib/core-focusable/core-focusable.js"></script>

I'm also getting a few other errors related to the usage of 'this' inside of other paper elements but I think that's a separate issue.

@KrisSiegel did you ever find a solution to your issue? I have a similar issue with paper-icon-button and iron-icons.

@rsORAU unfortunately no. Ultimately I moved away from Polymer because of it's immaturity and weight. I would assume it's much better by now but I haven't touched it in over a year at this point. Sorry.


Switch to "address-restricted" permission

Your environment.

Version: v0.0.6
Browser: n/a
Other Information: see pion/ice#46

What did you do?
See pion/ice#46
What did you expect?
TURN client's permission should allow inbound packets from a transport address for which the IP address is permitted but the port number can be any. ("address-restricted")
"Permission" should be per protocol+IP address only as RFC suggests. Otherwise, it can not detect a prflx candidate which would happen when the other end is behind a symmetric NAT.
From: https://tools.ietf.org/html/rfc5766#section-2.3
To ease concerns amongst enterprise IT administrators that TURN could be
used to bypass corporate firewall security, TURN includes the notion of permissions.
TURN permissions mimic the address-restricted filtering mechanism of NATs that
comply with [RFC4787].

.. meaning.. NOT "address-port-restricted"!
Also in the section 8 - Permissions:
   When a UDP datagram arrives at the relayed transport address for the
   allocation, the server extracts the source IP address from the IP
   header.  The server then compares this address with the IP address
   associated with each permission in the list of permissions for the
   allocation.  If no match is found, relaying is not permitted, and the
   server silently discards the UDP datagram.  If an exact match is
   found, then the permission check is considered to have succeeded and
   the server continues to process the UDP datagram as specified
   elsewhere (Section 10.3).  Note that only addresses are compared and
   port numbers are not considered.

What happened?
As the current pion/turnc discards a packet coming from an unseen transport address, it is not capable of detecting the peer-reflexive candidate.  This happens when one end uses TURN server but the other end is behind a symmtric NAT and not using TURN server.

I believe this is the case I am experiencing in the real world.

How to resolve this?
A rough idea...:

Rename current "Permission" to "Channel"
Introduce a new permission map (map[string]*permission)

the key would look like :, e.g. "udp:<IP_ADDRESS>"
the map is referenced by all channels to check permissions

When TURN server receives a packet from an unseen transport address, it will be forwarded to turnc.Client (remote IP has permission) using Data Indication. Then the client would unwraps the Data Indication to get the packet data.
The problem is, current implementation of turnc.Client tries to look for a corresponding channel for the data, the discard the data because there's no such remote address it has added to its channel list.  Correct implementation should forward the data to CandidateBase.handleInboundCandidateMsg().
Todo:

Add a callback (handleInbound(data []byte, src net.Addr) to turnc.Allocation to bypass peerR/peerL pipe.
Modify candidate_relay.go to handle the callback which would replace reading channel (peerR).

We are moving to pion/turn
@enobufs re-open if it is wrong to close this! Just moving through issues :)


Update to StickyElementController

Solve for jank in Safari. Now uses position absolute/fixed when appropriate. Can enable and disable a sticky element. Removed all transform stuff in sticky element (jank in Safari). Added Grunt task to distribute a minified morlock.

Awesome!
Mind squashing?


Julian calendar implementation

I created a simple implementation of a Julian calendar https://en.wikipedia.org/wiki/Julian_calendar based on the gregorian calendar implementation.
I checked it for some common dates (>45) in the test file and those seem to work. It does not deal with roman dates before 45 or the missing year 0.
It would be nice to have this as part of the official distribution.

Hi, thank you for the pull request, I will publish it on NPM soon.


Update list of lessons you're comfortable teaching

Current list of options:
dc/cloud
dc/python
dc/r
dc/shell
dc/spreadsheets
dc/sql
swc/git
swc/hg
swc/make
swc/matlab
swc/python
swc/r
swc/regexp
swc/shell
swc/sql
swc/svn
This includes lessons we don't maintain (like swc/regex, swc/svn).  It does not include lesson variations (like listing just swc/python even though there are two Python lessons in Software Carpentry's offerings).   This does not include any Library Carpentry options.  It also includes only  a limited number of Data Carpentry lessons.
How specific does this need list of options need to be? Listing every lesson across all lesson programs would mean listing about 50 options (and list will continue to grow).  Do we need to know just that they can teach Python, or do we need to know what Python lesson(s) across what lesson program(s)?
How much do we need to know to be able to recruit instructors to teach workshops?  Why else do we need to know this information?
This issue consolidates questions raised in #1211 and  #1409

@ErinBecker  and @fmichonneau  Your perspective from a curriculum development team would be much appreciated.  What reporting do we want to do, so we can do things like say X number of our Instructors are qualified to teach Y curriculum?    This also relates to #1338 -- how do we identify what lessons/curricula our Instructors are qualified to teach?
@sheraaronhurt  Your perspective from a workshop admin perspective will also be very useful.  What do you need to know to recruit instructors for a workshop?

I'm trying to categorize things to develop a timeline for working on AMY.  I think this is an option 3 issue - but please let me know if you have other thoughs @ErinBecker  @sheraaronhurt
Which of the following applies to when you want to see this fixed?

Would like to see this fixed as soon as possible, in the next 1-2 development cycles (i.e., by September 2019)
Would like to see this fixed later (by the end of 2019)
Would like to see this fixed, but possibly as part of a larger project that needs more planning
Not sure
No longer relevant - OK to close

Two more cents from me: I still like the idea of splitting lessons into two lists: technologies (e.g. Python basics, Python Data Visualization, Git, R, OpenRefine, SQL, etc.) and curricula (what we already have: "dc-ecology-python", "dc-ecology-r", etc.), see https://github.com/carpentries/amy/issues/1409#issuecomment-439128301
If at one point we are able to relate technologies with curricula, then for example we'd be able to find Python-teaching instructors in close proximity who could assist with DC-Ecology-Python workshop even though they didn't select DC-Ecology-Python on their list of curricula they feel comfortable teaching.
Additionally the list of technologies could be reused in workshops that use only part of DC/SWC/LC curriculum (the mix and match option), although I think in this case this list should be extensible.

Depending on how time intensive it is for @sheraaronhurt to do instructor recruitment, I would like to see this discussed as a possibility for the AMY automation project for this quarter or a similar project in a later quarter.

This isn't time sensitive for me. From the WAT perspective, we look at them having an understanding of Python as a whole, not the breakdown of the specific lessons.


First draft of paper.md for JOSS

I have started a draft of the paper for the Journal of Open Source Software. I have so far only included authors which I have confirmation for including and will add the additional authors as I get permission from each.

Consider also mentioning test coverage.

Consider also mentioning test coverage.

I think good test coverage is to be expected and doesn't need a callout? Happy to include it if you think it's worthwhile, just re-open the comment.

Also, something I didn't do, but was going back and forth on. There are unexplained abbreviations in the summary.
I understand not wanting to make it any longer, but normally the convention would be to use the full term in the first instance. Plus, the JOSS docs say they want the summary to be for a "non-specialist audience" and to "avoid jargon" in the summary.
So, on balance, should the first use of all acronyms be expanded to full terms? (Hope that makes sense).

(1) Categorical section of table currently does not include:

Frequency bias (bias score)
False alarm ratio
Specificity (true negative rate)

These should be added. (I am not sure which name should be used in the case of Frequency Bias and Specificity).
(2) Categorical section of table currently includes both: "Probability of Detection (POD), False Alarm Rate (FAR)". Should one be removed (and if so, which one)?

Follow up on comments made here: https://github.com/nci/scores/pull/398#issuecomment-2116725265

On 22/5/2024, Tennessee brought branch 51-joss-paper-draft back up to date with develop (as at that date).
Before doing so, he created branch 51-history-backup, and created a backup of the full commit history there. So, for the commit history prior to 22/5/2024, see branch 51-history-backup
Changes include updates to the Github workflow, updates to the paper, and updates to the bibliography

@nicholasloveday I think JOSS may follow the APA citation style (or otherwise a similar citation system). For in text citations with the same lead author and same year of publication, they have different rules for when the author list is identical (e.g. Smith and Peters (2020a); Smith and Peters (2020b)) and when the author list is not identical (e.g. Smith, Peters, et al. (2020); Smith, Jones, et al. (2020)).
https://apastyle.apa.org/style-grammar-guidelines/citations/basic-principles/same-year-author
https://apastyle.apa.org/style-grammar-guidelines/citations/basic-principles/same-year-first-author

I am closing this merge request. A new branch, 528-joss-paper-submission, has been created to track the JOSS submission process. I will leave the various branches intact for posterity (at least until the publication process is completed), but the merge request no longer needs to be open.


I am confused about gradient_scale in different context.

Hi,
I am pretty confused about this gradient scale parameter. In optimizer, there is such a parameter, and in softmaxoutput symbol, there is also such a parameter, I am wondering what those roles are. For example, I want to implement  a very simple 2 gpu data parallel program. I have a simple network on one gpu and a copy of it on another gpu. Now I have a batch size of 8 and I divide it into 2 batches of 4 for each gpu. Then I simple bind them and feed the corresponding data to each of them and forward and backward. Now it comes to the update step. Since I have two sets of gradients for the same weight variable, what am I supposed to do? sum up theses two copies and divide it by 2? or divide it by 8? or I use 1.0/16 as a gradient scale parameter and pass it to the optimize? I hope you could clarify this a little. I would really appreciate it.
@piiswrong @pluskid @tqchen

gradient scale in softmaxoutput is for weighting loss functions if you have multiple of them.
gradient scale in optimizer is for normalizing against batch_size.
They are in effect multiplied togather in the end.

@piiswrong Thanks for your reply, but I still got a little bit confused because in the document, SoftmaxOutput has a "normalization" argument. It says the default is "null", which means nothing will be done. "batch" means  "op will normalize gradient by dividing batch size", while "valid" means " op will normalize gradient by divide sample not ignored".
I have 2 questions:

Does this have the same effect if I set this to "null" and set an appropriate grad_scale?
Does "valid samples" mean all samples or only samples in a batch? For example, I have a multi-output softmax, say (2, 3, 100), which mean batch size=2, channel=3 and sample=100. If I set "batch", it divides by 2, right? If I use "valid" does it divide by 100? or (2x100)? If true, does it mean I dont need to change the gradient scale anymore and leave them to default 1.0?
I think this is really important to know if I want to make sure the training is under control. Thanks.

1.(normalization: null && grad_rescale：1.0/batch_size)  == (normalization:batch && grad_rescale=1.0）
2. Valid is for ignore label, for example, some samples is padding with label=-1, which will not contribute to grad in backward.


Unable to load the icon: 'd_winbtn_win_close' on Mac

First off, I love this package and its philosophy, I've only just begun using it but having a generic visualization/editor for graph based data is just amazing. Unity should have this built in. Thanks so much for sharing this with your fellow game devs 🙏
This is just a tiny bug that I'm seeing, it's also not affecting the workflow in any way, I think:
When opening a graph, an error is thrown because Unity can't find the icon d_winbtn_win_close.
Which makes sense, as I assume that's a windows only icon.
I normally wouldn't open an issue for mac specific issues, that just might not be a target platform for this package.
But I see you're beautifully handling some Mac specific stuff already! (e.g. showing the ⌘ char for the Command key) 💕
Below is the full stack trace:
(again, this occurs when opening a graph)
[Error] Unable to load the icon: 'd_winbtn_win_close'.
Note that either full project path should be used (with extension) or just the icon name if the icon is located in the following location: 'Assets/Editor Default Resources/Icons/' (without extension, since png is assumed)
EditorGUIUtility.IconContent()

NewGraph.EditableLabelElement..ctor() at ./Library/PackageCache/com.gentlymad.newgraph@d41b4e6e29/Editor/Views/Elements/EditableLabelElement.cs:32

NewGraph.ScriptableInspectorControllerGeneric`1<NewGraph.ScriptableGraphModel>.CreateRenameGraphUI() at ./Library/PackageCache/com.gentlymad.newgraph@d41b4e6e29/Editor/Controllers/ScriptableInspectorControllerGeneric.cs:113

InspectorControllerBase.Draw() at ./Library/PackageCache/com.gentlymad.newgraph@d41b4e6e29/Editor/Controllers/InspectorControllerBase.cs:218

GraphController.Draw() at ./Library/PackageCache/com.gentlymad.newgraph@d41b4e6e29/Editor/Controllers/GraphController.cs:534

GraphWindow.OnGUI() at ./Library/PackageCache/com.gentlymad.newgraph@d41b4e6e29/Editor/Views/GraphWindow.cs:123

GUIUtility.ProcessEvent() at /Users/bokken/build/output/unity/unity/Modules/IMGUI/GUIUtility.cs:206

Update: I think a fix could be as simple as the following line in EditableLabelElement.cs :

Hm okay another update:
I am actually not sure which "OS button icons" are still available in Unity 2023.
This list contains winbtn_win and winbtn_mac variants, but when I examine the icons in my (2023) Unity, using Internal Icon Browser, then I'm actually not seeing any winbtn icons.
Perhaps if you're looking to just show a simple cross, it's safer to just use d_clear ?

Also getting this issue in Unity Pro 2023.2.20f1 on Windows.


"Project maintainers" link in elections is broken

Going on https://voxpupuli.org/elections/, the link leads to a 404 error at https://github.com/orgs/voxpupuli/teams/project-maintainers:

The current list of PMC members can be found on GitHub.

See also "Project maintainers" link in COC is broken

I clicked all the links and could not duplicate this. Could you be more specific.

Am not able to confirm. Went through each link (and re-ordered them)
https://github.com/voxpupuli/voxpupuli.github.io/pull/198

That's probably because you're already logged-in into Github and you have access to the organization team details: https://github.com/orgs/voxpupuli/teams/project-maintainers
The above link is not public, nor somebody outside of the organization can access. The public link is: https://github.com/orgs/voxpupuli/people

@azbarcea as a short-term workaround, I created https://github.com/voxpupuli/voxpupuli.github.io/pull/201. Our original goal was to not duplicate the list of people. This is always annoying after elections because it needs to be updated at multiple places. I've no proper alternative at the moment, but the new text at least explains it.


上交大佬们，能给个安装和使用教程吗.....

弄不懂啊

Please see the installation guide at https://cityflow.readthedocs.io/en/latest/install.html#install


Execution failed for task ':data_usage:compileDebugKotlin'

Launching lib/main.dart on SM A205F in debug mode...
lib/main.dart:1
e: /home/chintank/.pub-cache/hosted/pub.dartlang.org/data_usage-1.0.3/android/src/main/kotlin/com/chizi/data_usage/DataUsagePlugin.kt: (40, 1): Class 'DataUsagePlugin' is not abstract and does not implement abstract member public abstract fun onRequestPermissionsResult(p0: Int, p1: Array<(out) String!>, p2: IntArray): Boolean defined in io.flutter.plugin.common.PluginRegistry.RequestPermissionsResultListener
e: /home/chintank/.pub-cache/hosted/pub.dartlang.org/data_usage-1.0.3/android/src/main/kotlin/com/chizi/data_usage/DataUsagePlugin.kt: (244, 5): 'onRequestPermissionsResult' overrides nothing
FAILURE: Build failed with an exception.

What went wrong:
Execution failed for task ':data_usage:compileDebugKotlin'.

Compilation error. See log for more details

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 18s
Exception: Gradle task assembleDebug failed with exit code 1
Exited (sigterm)

sama here. any fixes ?

you can use my patched fork
https://github.com/fullflash/data_usage_patched


 Will fix.

/cc @heyitsanthony @xiang90 Please review.
Now it doesn't complain https://travis-ci.org/coreos/etcd/jobs/138427905.
Thanks.

lgtm

Thanks. Merging in greens.

@xiang90 Just fixed.
And added more fixes for go lint issues. https://goreportcard.com/report/github.com/coreos/etcd#golint
/cc @heyitsanthony

lgtm

lgtm

thanks.


Fix run Expecto tests unquoted project file path bug.

Fixes #680.
Tested with core and classic .net framework projects with Expecto tests and previously failing path.
If we decide to merge it in this form then it would probably be better to change MSBuild.invokeMSBuild as it does the quoting thing on it's own.

@enricosada Thanks for feedback :) I've removed the extension and added the quote only if needed part. How do you like it after the changes?


Update version for release.

We're currently processing your upload.  This comment will be updated when the results are available.


[SymfonyEventDispatcher] deprecation in favor of contributte

Hey Guys,
I've got a question for you. Since Symfony 3.3, there have been added new EventDispatcher features, that
dropped added value of SymplifyEventDispatcher for Symfony.
Only usable case remains Nette. There is similar package by @f3l1x :
https://github.com/contributte/event-dispatcher
That does pretty much the same thing. Last few months I've realized I can invest to package that add more than just a few % of added value, instead of maintaining a 90% similar product.
1. So I would be happy to deprecate this package in favor of @f3l1x one. That means, it would be still available for years and current composer supported versions, just not developed.**
My question is - would you consider that a good way to continue or not? And why?
2. I asked @enumag on PM, and he would be ok, just missing ::class based event naming instead of string one.
$this->eventDispatcher(ApplicationRequestEvent::NAME);
// alows to open event right away

instead of
$this->eventDispatcher(ApplicationEvents::ON_STARTUP);
// contributte, string only

For me, that would a detail, since on my own events I can use ::class regardless the package.
What do you think? About 1. and 2.
/cc @f3l1x @enumag @Lexinek @fprochazka

👍

I like this whole thing. Don't split energy to more projects, rather focus on one. If it could be contributte/event-dispatcher I couldn't be happier.

I'm not sure what do you mean with $this->eventDispatcher(ApplicationRequestEvent::NAME);. It's just a name?

I though you'd be happy!

I'm not sure what do you mean with $this->eventDispatcher(ApplicationRequestEvent::NAME);. It's just a name?

The point is not the constant, but int the event class. You can click to the event class and see it's arguments and methods. I tried my gif skills :camera:

@TomasVotruba I get it now. It might be useful. I could add it to contributte/event-dispatcher too.

FYI I intent to drop the dispatcher integration from Kdyby/Events too, and probably gonna add suggest for contributte :)

@fprochazka That sounds great. Where does this intent came from? :)
Do you mean to drop Kdyby/Evens or just symfony events or only nette packages events?

@f3l1x https://github.com/Kdyby/Events/issues/97#issuecomment-301213842

@fprochazka I get it now. :) Thanks.

@fprochazka Another point for this. Thank you.
@Lexinek What do you think? I'd like to hear your opinion.

In this case, me as user i want always the newest version, with bug fixes, new features etc... it is always hard to deprecate package, for me it is sign of that i should not use it anymore. I am using for example symplify/symbiotic-controller that depends on symplify/symfony-event-dispatcher. Will you replace symplify/symfony-event-dispatcher implementation with the one from @f3l1x ?

If the answer is YES, i am happy and i will approve this instantly for you.
If the answer is NO, what can me, as user do about that deprecation warning in composer install/update? I want to use a package that depends on deprecated package and i feel like i am doomend.

I definitely agree, i am using events this way and it is really addictive!

Overall i think this is good way to go, focus on more important things that will bring more added value to community and developers, instead of bringing the wood into forest (maintaining package solving problem that is already solved by other maintained package)

Thank you so much for your complete and easy to read answer.

I say YES to this.

In that case, please create an issue at conttribute package and let talk go on there.

Bringing wood the forrest exactly describes my feeling. Nice one.

Resolved via https://github.com/Symplify/Symplify/pull/170
Thank you all for your words, ideas and opinions. It's much easier for me to decide upon many united voices.

It's all yours now @f3l1x  Enjoy :heart:

@f3l1x Bit late, but I've just noticed my app stopped working after switching to your bundle.
To me while to figure out only contributte interface are autoloaded, not Symfony\Component\EventDispatcher\EventSubscriberInterface. Not sure why, since it is empty.
This is a huge BC break, that would force all people using Symplify extension to change all their subscribers. Would you be open to use original interface?
/cc @Lexinek @enumag

Sure, I will change it. :)

@f3l1x That would be great :cake:
I'm sorry if my tone was too hursh, I had weird and tough night yesterday.

I definitely agree.
Btw i had similar bug in my application once and spent 2 hours finding out that in my use statement there is other EventSubscriberInterface than the one from Symfony :-)

Hehe, that must have hurt. Which one? :D
We might start some PHP Trollo package!

In my case it was JMS\Serializer\EventDispatcher\EventDispatcherInterface
TBH i dont know why they have their own interface for this (it is empty, probably same use case as in this repository).
I was writing class ... extends Dispatcher PHPStorm autocompleted for me the JMS namespace was on the first place and without checking i pressed enter and then i was doomed.
It was crazy like hell, wtf factor 9/10, i almost jumped out of the window, i was like "WTF this subscriber works and this just does not" :-)
Imho best practice is to support only symfony event dispatcher interface, as it leads to terrible use cases such as i described, but it would cause BC Break to this package.

 Is there some way to prevent PHPStorm from doing so?

@enumag i did not find any way to do it yet :-/

@enumag @Lexinek Could you try removing it?

@TomasVotruba No, we need the bundle where it is.

@enumag So maybe https://pehapkari.cz/blog/2017/01/20/jak-snadno-a-rychle-upravovat-soubory-ve-vendoru/

@enumag To bad. One of few first things I learnt in Symfony world, was that JMS Bundles are better to skip and manage by own code.

Possibly. I didn't personally add it to the codebase so I'll investigate why it's there. It's probably for FOSRestBundle though and I don't know any other good bundle for rest API. Can you recommend any?

I think guys might know good REST bundle (or approach in Symfony) /cc @fprochazka @vasekpurchart @mhujer

We've been using friendsofsymfony/rest-bundle + jms/serializer-bundle. And apart from often useless error messages from jms/serializer-bundle, I quite liked the setup. I didn't have to set it up tho, @VasekPurchart did it and I've just been using it, so I haven't really had a chance to hit the juicy stuff everyne is hating on.

Yes, our setup relied on JMS, which I agree is quite a pain to use sometimes, but I think this was caused mainly by the fact that the author was not actively developing them. We were using them because of their broad capabilities and quite good extension options and we had some custom made infrastructure set up on it :)
But anyway I didn't find any better combination of bundles to serve my purposes, so I wanted to implement my own, but of course, there was no time, so we were stuck with this. If my next project is a Symfony API though, I'll try to create it :)


Missing ReleaseEnumeratedSourceVideoModes

No equivalent free exists either. I'll PR this when I have time.

Nevermind found.


Fix variable-editor height

This height is should be 30px to match the 2px in vertical border, 14px in line height and 14px in vertical padding. It seems it used to be but was inexplicably changed quite a while ago (maybe not intentional?). Here's an example of the of the difference that fixes the annoying 1px overflow problem:

Looks nice 👍

Bump!

Thanks @caseywebdev! Sorry for the late merge!

Better late then never 😉


#1 gst_ios_init() errors/warnings

#if defined(GST_IOS_GIO_MODULE_GNUTLS)
#include <gio/gio.h>
G_IO_MODULE_DECLARE(gnutls);
#endif
Xcode is complaining about G_IO_MODULE_DECLARE(gnutls); with these errors/warnings..
ERRORS::
../deinonychus/gst_ios_init.m:453:3: Type specifier missing, defaults to 'int'
../deinonychus/gst_ios_init.m:453:23: A parameter list without types is only allowed in a function definition
and I believe this other issue is directly related...
#if defined(GST_IOS_GIO_MODULE_GNUTLS)
G_IO_MODULE_LOAD(gnutls);
#endif
For the line G_IO_MODULE_LOAD(gnutls)
ERRORS::
../deinonychus/gst_ios_init.m:935:3: Implicit declaration of function 'G_IO_MODULE_LOAD' is invalid in C99
../deinonychus/gst_ios_init.m:935:20: Use of undeclared identifier 'gnutls'
This might be an issue on my end but any clarification would be great

worked fine before, but start seeing the same issue with the new ios 1.4.5 sdk, any update on this issue?

Got the same errors with XCode 7.0.1 & gstreamer-1.0-devel-1.6.0-ios-universal.pkg.

Any idea why?

No idea, but got this tutorial running on iOS simulator:
http://cgit.freedesktop.org/~slomo/gst-sdk-tutorials/
I compiled the gstreamer iOS package from sources:
http://cgit.freedesktop.org/gstreamer/cerbero/
It took a while to figure out all the steps as beginner iOS developer, I should write a blog post or something.


latest version is 1.11-1

Short Description:
Fixes:

was using arch linux and no version matched error popped

Please PR to dev branch, thanks, close this one for now.


Magento <IP_ADDRESS>

Hello,
is the extension also working on Magento <IP_ADDRESS>.?
best regards,
Michel

hello,
It was tested on an earlier 1.9 version so it should work on <IP_ADDRESS>, yes
I'll try to test it tomorrow on a VM
regards

I can confirm that it absolutely works on <IP_ADDRESS>
regards


Add chunk-by-chunk downsampling

@niksirbi this is ready to test now (and has been for a week, but forgot to ping you 🤦 ). On a ~300 GB dataset the downsampling ran in ~minutes for me, reading and writing from an SSD. Any feedback/suggestions very welcome!

That sounds great, I'll try to run it on one of our datasets by the end of this week and let you know.

Hey @dstansby, sorry for the delay. I tried the downsampling on some of our data, and it was blazingly fast (the downsampling time was negligible compared to the time needed to create the 0-th level).


Windows devicelab tests aren't running

This is a common problem with windows agent running but not picking up tasks. Rebooting.

Windows is picking up tasks again.

Is there a way this can be detected so the infra team can be notified?  Otherwise it's up to someone to just notice a box of gray on the dashboard.

This kind of issues will be fixed as soon as those tasks get moved to LUCI bots.


Creating animationAsWidget in moving widget places animation in wrong position

I'm not sure if I'm doing something wrong, but whenever I place a widget created with Flame.util.animationAsWidget in a moving Widget such as a GridView or ListView, the animations are in the completely wrong position. For example, the skeleton sprite should be within the green container, but it is not at all. There is no problem with placing the animationAsWidgets in rows or columns, only when in moving components.

Hi, @BSChuang , thanks a lot for reporting this issue!
That is indeed a bug because I have not considered this possibility of moving widgets on the implementation of EmbeddedGame. The fix should relatively simple, we need to update the viewport position for the game whenever the parent changes us.
I can take a look at this later to fix, or, if you ware interested, you can contribute with a PR!
Thanks again for the report :)

Just opened a PR addressing this problem: #63

@BSChuang Since this problem has been tackled in #63, which was merged and released on 0.10.3, I will close this issue now. If you still face this problem or think it was not saved properly, consider reopening it and let's keep discussing.


Support job status and cancel API for yarn per-job execution mode

This PR is fixed issue #21 .

Hi @TsReaper
I have updated codes, please help me to review again thanks. BTW, I tested execute, status and cancel REST API on yarn-per-job and yarn-session mode.

Hi @godfreyhe @TsReaper
The primary modifications are:

It is no longer need to create new class YarnConfigOptions.java or depend on flink-yarn.
Move getJobStatus and  cancelJob logic to ClusterDescriptorAdapter.

And I tested execute, status and cancel REST API on yarn-per-job and yarn-session mode for select and insert statement. Please feel free to contact me if you have any questions.

Hi @godfreyhe @TsReaper
The primary modifications are:

Add  flink-yarn dependence.
Add some comments.

Hi @godfreyhe @TsReaper
The test of containsYarnApplicationNotFoundException method modification:
yarn-per-job

submit sql like INSERT INTO sink SELECT * FROM source

kill the yarn application via yarn app -kill

fetch result via /sessions/:sessionId/jobs/:jobId/result/1

the result is :
{
    "results": [
        {
            "columns": [
                {
                    "name": "affected_row_count",
                    "type": "BIGINT NOT NULL"
                }
            ],
            "data": [
                [
                    -2
                ]
            ]
        }
    ],
    "next_result_uri": "/v1/sessions/735fcb8853b6d20ea533fa3d932df841/jobs/9d7a7fc536b52282b0970460e72d7b98/result/2"
}

yarn-session

submit sql like INSERT INTO sink SELECT * FROM source

cancel job via flink dashboard

fetch result via /sessions/:sessionId/jobs/:jobId/result/0

the result is :
{
    "results": [
        {
            "columns": [
                {
                    "name": "affected_row_count",
                    "type": "BIGINT NOT NULL"
                }
            ],
            "data": [
                [
                    -2
                ]
            ]
        }
    ],
    "next_result_uri": "/v1/sessions/0148814b4e605adfb651505e500a051a/jobs/9fd3c1b960af1e7aff69a314b2cb339c/result/1"
}

Hi @godfreyhe @TsReaper
Formatted codes. Please feel free to contact me if you have any questions.

Thanks @wooplevip for this hard work. LGTM.

merged


Automatic PR from RestAPI-PR1981

Generated from RestAPI PR: https://github.com/Azure/azure-rest-api-specs/pull/1981

Codecov Report

Merging #1657 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1657   +/-   ##
=======================================
  Coverage   55.36%   55.36%
=======================================
  Files        4095     4095
  Lines       98359    98359
=======================================
  Hits        54459    54459
  Misses      43900    43900

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 3d7abfa...4551309. Read the comment docs.

Outdated PR, package is up to date


Add a /config dir

This is issue is vaguely described other places but is long over due. This description should be concrete enough to implement:

Add a configDir setting, default /config.
Add a --environment flag (and setting), which defaults to production for hugo and development  for hugo server
Configuration keys in /config will override keys in config.toml

A sample tree could look like this:
config
├── _default
│   ├── config.toml
│   ├── languages.toml
│   └── mediaTypes.toml
└── production
    ├── config.toml
    ├── mediaTypes.toml
    └── related.toml

config.toml allows top level keys (baseURL) etc. to be set per environment.
The other filenames maps to a configuration key, so languages.toml could look like this:

  [en]
    contentDir = "content/en"
    languageName = "English"
    weight = 1
  [zh]
    contentDir = "content/zh"
    languageName = "中文"
    weight = 2

There are no clever merging inside /config -- we pick the most specific file (for production and mediaTypes in the example above, we pick the file below /production).
This will (in its first iteration) be a project only thing.
/cc @regisphilibert @budparr @kaushalmodi

Was just thinking about it yesterday having to manage many menu items from the config.yaml. "Boy I wish there was a native way to isolate those menu items in their own file..."
I assume we can add as many files as we want in order to create a config objects. This is not limited to the one you mentioned?

There are no clever merging inside

What do you mean by clever ? I just wish the config/production/config.yaml could overwrite some values of config/production/config.yaml such as the baseURL or publishDir

Love this. Slightly uncomfortable with environment variable defaults, but I suppose that if one went to the trouble of using them at all, they'd be aware of the defaults.
Question (hopefully not too off topic). Would it be possible to do a build with no config at all? Right now I believe Hugo looks for a config file, no matter how minimal (even empty). Would be cool to be zero config with nothing required other than a minimal layouts/index.html file. Then Hugo could be "The world’s fastest ZERO CONFIG framework for building websites" :)

Slightly uncomfortable with environment variable defaults, but I suppose that if one went to the trouble of using them at all, they'd be aware of the defaults.

You mean the development/production logic?
Yes, it's strictly a little outside the scope of this issue, but doing it at the same time is considerably cheaper. And the number of overrides should be very small (my example is bad) -- and I think this makes it more explicit than the if production we have today.

Yes I suspect environment only key/value pair will be limited to baseURL, googleAnalytics and a few params. So most of the config settings will happen in _default.
This will be an awesome improvements on the way Hugo currently deals with config! 🤩

Yes, I meant that I explicitly set environment variables and that control is predictable to me. Not a big deal though.

An important addendum to the above, having thought about this a little. One of the big benefactors of this feature is sites with many languages (and with that really a long languages section with menu definitions etc.).
So, for the languages config I think we need to allow "one dot" in the filename, e.g.:
config
├── _default
│   ├── config.toml
│   ├── languages.en.toml
│   ├── languages.toml
│   └── mediaTypes.toml
└── production
    ├── config.toml
    ├── mediaTypes.toml
    └── related.toml

So in the above, languages.en.toml represents the English configuration and will replace any languages.en key in languages.toml.
/cc @regisphilibert @budparr

But could we still have "standalone file" config for each languages (menus.en.toml, menus.fr.toml) ?

But could we still have "standalone file" config for each languages (menus.en.toml, menus.fr.toml) ?

menus isn't a configuration key in Hugo, I thnk. This issue is getting scope creeped as it is, so we're not adding config options that isn't already there.

@regisphilibert I've dived into this issue now, and it does not look too hard. There is one issue that yoj can help me with. I will think out loud a little. It is related to your last comment; I think we need to be a little more clever when it comes to language handling.
Taken from the Hugo docs site:
languages.zh.menu.main  => array
languages.zh.params => map

(I have made a note to create menus (plural) as an alias -- to get it in line with the others)
I have put the above to wrap my head around and make sure we can represent this in all the config formats. So, only JSON allows arrays without a root, so we need to avoid (or work around) that.
With that, I was thinking that the 2 above examples could look like:
config/menus.zh.toml:
[[ldocs]]
  name = "函数"
  weight = 30
[[ldocs]]
 name = "变量"
  weight = 35
[[sidebar]]
 name = "变量"
  weight = 35

This means that if you have several menus, you need to put them in the same file for that language.
config/params.zh.toml:
description = "A description in that language"

The above makes sense to me ...?

This means that if you have several menus, you need to put them in the same file for that language.

Of course. The important part here is that multilingual project will not loose this "file isolation" feature by having to dump all their config objets into one "language config" file.

(I have made a note to create menus (plural) as an alias -- to get it in line with the others)

Agree! Current key is counter-intuitive (I always forget it's supposed to be singular).

There is one issue that you can help me with.

Not sure how I can help beside supporting this logic (config/menus.zh.toml) as it is exactly what I would wish as a user.

Not sure how I can help beside supporting this logic

That's the help I needed.

@budparr and @regisphilibert -- given the "config tree" below:
config
├── _default
│   ├── config.toml
│   ├── languages.toml
│   ├── menus
│   │   ├── menu.en.toml
│   │   └── menu.zh.toml
│   ├── params.1.toml
│   └── params.2.toml
└── development
    └── params.2.toml

Do you understand the meaning of params.1.toml etc or is it too clever?
The thing is, the main rule has to be that if languages etc. is set for development, we don't use the one in _default. I cannot now if the user wants to do some merging. There are, however, situations where you have a lot of common params, but where only some of them is different for a given environment.
Also note that the menus sub folder is only a way to organize your files, it can be named anything, and I will fix "menu vs menus".

Do you understand the meaning of params.1.toml etc or is it too clever?

I'm guessing this is a way of defining a group of params to be merged vs another group to be left as is.
Let me share a personal yet very common (I think) use case to make sure I'm following.
Using the CLI command  hugo --config config.yaml,config.prod.yaml, I have a config.yaml with a lot of settings common to both environement, and a config.prod.yaml with a distinct baseURL and params.api_url. Those will override the one present in config.yaml.
If a key present in config.yaml needs to be absent in production I suppose I could set it to false in config.prod.yaml.
By what I understand this is how I would replicate this behaviour using the new config directory feature:
config
├── _default
│   ├── config.toml (baseURL set here)
│   ├── params.1.toml (params common to both env. set here)
│   └── params.2.toml (api_url set here)
└── production
│   ├── config.toml (baseURL overriden here)
    └── params.2.toml (api_url overriden here)

Am I following?

Am I following?

Yes.
The main motivation here is that if you have 120 generic params + 1 environment specific param, you don't want to repeat the 121 params in every environment.
Also note that this is a general pattern; you could also do config.5.toml-- the number is a key element, but it also controls the order (params.2.toml is added after 1).

So still with the previous use case I could not do the following:
config
├── _default
│   ├── config.toml (baseURL set here)
│   └── params.toml (params common to both env. set here + default api_url)
└── production
│   ├── config.toml (baseURL overriden here)
    └── params.toml (default api_url overriden here with production api_url)

And expect the params common to both env to be set in the production env. as well.
If this is a technical decision then I'm happy to trade this very light complexification to be able to manage configuration with directories and filenames.
If this is a usability decision on the other hand, I'd like to understand the logic behind it as it presently escapes me.

Your last example will not work. This is merged on "file level": We pick the most specific file, e.g. production/param.toml.
Note that it would be technically possible to implement it so your particular example would work. But that would break other examples/use cases, examples being that I would want a default set of languages, output formats, whatever, in the different environments, so we cannot merge blindly.

But that would break other examples/use cases

But I think this could be solved differently by having Hugo merge blindly while having the user exercise a much expected discipline of never putting in _default something not shared by every environment, unless it can be overridden by a false value.
I would not add a "production only" Output Format in _default, and I don't expect any one would.
Again my suggestion may not be sustainable, but as I cannot think of a use case for which this basic discipline would not suffice, I must insist on asking you or other users if this "blind merging" could not be OK, providing it does not complicate your task of course.
This would avoid introducing and documenting the file numbering system and make the new config management all the more intuitive by matching the behaviour of hugo --config's blind merging logic even though I suspect it is currently underused.

Here's the use case I can think of to defend the numbering file implementation:
I have 5 environment, I need a certain output formats in all of them but one. This means with blind merging, I would have to copy and paste this output formats setting in the 4 environment needing it.
I'm suspecting this use case will be rare and I'm afraid we may complexify a feature for the vast majority of use cases only the benefit a very few.

@regisphilibert I have slept, and you are right. I was thinking too hard about this. If we for some really good reason need "my variant" we could add some naming standard for that case later. Thanks for the input, always appreciated.

Anytime, glad I could help.


ClientEngine.EnablePortForwardingAsync() does not forward DhtEngine udp port

Also, I would propose that EnablePortForwarding become an EngineSetting rather than the current Enable/Disable methods.

The DHT thing is definitely a bug, and it's mostly due to how Dht is unnecessarily exposed as a public extensibility point. I can move the Dht thing into an engine setting, along with the port forwarding setting, relatively easily.
https://github.com/alanmcgovern/monotorrent/tree/immutable-settings
My intention is to make EngineSettings immutable. You can modify them using an EngineSettingsBuilder. When you have a new instance configured correctly, you will call await ClientEngine.UpdateSettingsAsync (TorrentSettings).
Inside this method I'll be able to update any listeners to use the new ListenPort or DhtPort (if needed), forward any ports, or unforward the old ones, etc. It an also enable/disable port forwarding if i make it a setting too, like you suggest.
Would this approach work for you?

Sounds great!

This should be fixed in master. If you can build from source it would be great if you could give it a shot.
I won't release an update to nuget.org for a few days, at least, as I want to let this bake a bit more. It's a fairly large change overall!
Do let me know how you get on.

Hehe just trying this update I noticed the EngineSettingsBuilder is missing the setters on AllowLocalPeerDiscovery and AllowPortForwarding.  I'm curious about the design reasons for .ToSettings(), is that purely to convert the builder into the immutable Settings, or would you also use it to do settings validation? (e.g. if you had multiple settings that could clash).

Hehe just trying this update I noticed the EngineSettingsBuilder is missing the setters on AllowLocalPeerDiscovery and AllowPortForwarding

Well oops! Turns out copy/paste is a great way to introduce bugs :p  That's fixed now!

I'm curious about the design reasons for .ToSettings(), is that purely to convert the builder into the immutable Settings, or would you also use it to do settings validation?

It's currently intended purely as a means to create the immutable EngineSettings/TorrentSettings objects. Individual settings in the Builder have validations applied to them. If there is ever a case where individual properties are mutually exclusive then there'd have to be a choice made in how to support that. We may need:

An atomic way to set two, or more, properties such that things are always in a compatible/consistent state.
Add additional validations to the individual setters to ensure they throw immediately if anything is set in an incompatible way.
Additional validations to make 'ToSettings' throw if the values are set incompatibly.

It's a bridge we can cross if/when we get there though!

Also, just to address the point in EngineSettings.Equals() and EngineSettings.GetHashCode()  not matching - they're not intended to.
Two objects which are equal must generate the same hashcode, but two objects which are different may also generate the same hashcode.
A subset of the properties are used for the GetHashCode impl as attempting to combine everything into one hashcode is unlikely to yield a better hashcode. Every property is in the Equals impl as this must be accurate.

I just issued a release containing these changes. You can test it out using the latest alpha from nuget, or by using tip of master!


sysbuild: Functionality to pass variables from sysbuild directly to p…

Small change that gives a possibility to create list of variables that should be passed directly to projects cmakes. Such variables would be available before Zephyr project inclusion inside the project itself.
The list needs to have a form _USER_SHARED_VARS and needs to be defined before ExternalZephyrProject_Add.
When it is used to pass variables to main application it needs to defined before Sysbuild package (in sysbuild/CmakeLists.txt).
This is proof of concept that solves the issue presented in #76592.
It might require some discussion and polishing - but before that I wish to know what community thinks about it.

Little background why we may need this: I have a medium size project, where we are building for different products from one codebase (quite usual). The project selection is done by APPLICATION_CONFIG variable set in sample.yaml. This variable is used to select options that have to be selected before Zephyr package is included.
Such configuration works like a charm without sysbuild. Using sysbuild right now breaks it apart. This modification gives us a possibility to pass such variables directly to project cmake making it work with sysbuild without any modifications. Only sysbuild.cmake (or sysbuild/CMakeLists.txt in a case when main application needs such approach) needs to be added with _USER_SHARED_VARS set.


core: Update how COLUMNS is set

Using C:\Program Files\Git\bin\bash.exe from a vanilla Command Prompt window set to 161 columns, the default to 80 columns if tput fails test case kept failing because columns was getting computed as 161 instead of 80. Eventually I realized this wasn't because the test wasn't getting tput to fail—it was—but because mode.com was picking up the slack, as designed.
So the test has been updated to default to 80 columns if tput fails or use mode.com on Windows. Also streamlined the existing go-core.bash logic that handles tput and mode.com to use regular expressions and BASH_REMATCH, dispensing with shopt and multiple steps in the mode.com case.

Coverage increased (+0.2%) to 94.417% when pulling 5bdbd2cce8d366f551c36a4893980e9551bd7e00 on columns into 5fc49a56430ff71ff9d0252d7b4ac972d03b355e on master.


FR: Ignore code action

Would it maybe be possible to ignore certain code actions?

Hello! Does the action_kinds option do what you want? Pasting the relevant docs here:
-- Code action kinds to observe.
    -- To match all code actions, set to `nil`.
    -- Otherwise, set to a table of kinds.
    -- Example: { "quickfix", "refactor.rewrite" }
    -- See: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#codeActionKind
    action_kinds = nil,

Ah yes, that looks indeed looks je it could be it.
Do you know how I can tell which type a particular code action has?

Hello again. I just added a NvimLightbulb.debug() function, can you let me know if this helps? Among other debug information it should show code actions at the location along with their type.
Example output:

As said in https://github.com/kosayoda/nvim-lightbulb/issues/58#issuecomment-1870939846, allowing users to have a custom predicate or filter function fun(lsp.CodeAction|lsp.Command): boolean would be a better and general enough solution.

Hello! The filter feature is now implemented in 18c54dd.
Thank you very much for your patience.


build: repair pnpm lock file

set lock file to match lambdas/package.json

Thanks for catching and fixing it!

I looked to place is CI where this should be checked, but once it got to the docker stuff (where I guess there could be a check) I got lost.
All installs on CI should normally use pnpm i --frozen-lockfile.
If that is too complicated in normal steps, maybe we need a separate job to check just those things.?

Oh I missed this. Thank you for catching and fixing!


Does rhai support highlight editor.

There are extensions for VS Code and TextMate...
For others, you'll get good results with either Rust or JavaScript...

Has this issue been resolved?

Closing this for now.  Feel free to reopen if there are still issues.


API: idempotency vs side effects of recognizers

Should a recognizer be idempotent?
Recognizer v4 API proposes that a recognizer may have any side effects. E.g., trying to recognize a lexeme may produce read the input source.
This looseness reduces safety of using recognizers. Particularly, when a program or library uses the current recognizer that was not set by this program or library. Or when a lexeme is taken from an unsafe source (e.g., from the user).
On the other side, any recognizer can be implemented in an idempotent manner.
E.g., an implementation of string literals in such a way that the recognizer doesn't do additional parsing — see at the gist.
Also, recognizing is a generalization of finding definition names and conversion strings to numbers (FIND and NUMBER?). And these actions never have any side effects.
See also: Issue #8

Examples of programs that work incorrectly due to side effect of some recognizers — see in the message<EMAIL_ADDRESS>E.g., the following short correct program:
'!' parse "test passed"! rec-string cr .s cr .

produces "Invalid memory address" error in in Gforth 0.7.9_20200618  (see also the corresponding bug report).


client: add retryable client with default

Signed-off-by: Asra Ali<EMAIL_ADDRESS>This adds a retryable http client that has a default retry for use in other libraries. See https://github.com/sigstore/cosign/issues/2198

Summary

Release Note

Documentation

Codecov Report

Merging #859 (43d6adc) into main (29303cf) will increase coverage by 0.47%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #859      +/-   ##
==========================================
+ Coverage   55.29%   55.76%   +0.47%
==========================================
  Files          38       38
  Lines        2333     2340       +7
==========================================
+ Hits         1290     1305      +15
+ Misses        945      939       -6
+ Partials       98       96       -2

Impacted Files
Coverage Δ

pkg/api/client.go
39.65% <100.00%> (+3.87%)
:arrow_up:

pkg/ca/fileca/load.go
68.96% <0.00%> (+10.34%)
:arrow_up:

pkg/ca/fileca/watch.go
100.00% <0.00%> (+50.00%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

Correct, there's an open PR (https://github.com/sigstore/cosign/pull/1762) to switch off the legacy client to gRPC.

Do you mean post-grpc? Or was there something else that marked this as legacy?

The current "v2" API supports either gRPC or HTTP. We don't need to maintain a gRPC client. For HTTP, we could maintain one. Legacy was the "v1" API that doesn't support gRPC

For HTTP, we could maintain one. Legacy was the "v1" API that doesn't support gRPC

OOOH got it! Thanks: we can add it in that PR, no need to support an HTTP one


Chaining conditions with "or" and "and"

I didn't manage to implement following query.
select * from person p
where p.city = 'New York' and (p.name = 'Miller' or p.birthName = 'Miller')

data.select(Person.class)
.where(PersonEntity.CITY.eq("New York").and(PersonEntity.NAME.eq("Miller").or(PersonEntity.BIRTH_NAME.eq("Miller")))).get()

since I've put the OR expression inside one .and() call, I'd expected to generate the parentheses around the OR expression chain.

You have chained the and part of the query as part of where p.city = 'New York' hence there won't be any parentheses generated, instead you should add it after closing the where part (note the parentheses location)
e.g.
data.select(Person.class)                 .where(PersonEntity.CITY.eq("New York")).and(Person.NAME.eq("Miller").or(PersonEntity.BIRTH_NAME.eq("Miller"))).get()

Looks a bit odd, to write
data.select(Person.class).where(condition).and(condition2).orderBy....

I'd expected to have all where-conditions as one where function's parameter. Like in QueryDSL or JOOQ, where condition1.and(condition2).or(condition3) doesn't generate the same sql as condition1.and(condition2.or(condition3)), where the first would generate condition 1 AND condition 2 OR condition3, and the second would generate condition1 AND (condition2 OR condition3). The result would be totally different.
It get's messy when the where conditions are constructed in code (pseudo code, won't compile).
val whereClause = PersonEntity.CITY.eq("New York");
if (searchForName) {
   whereClause.and(PersonEntity.NAME.eq(searchTerm).or(PersonEntity.MAIDEN_NAME.eq(searchTerm))
}
val searchResult = data.select(Person.class).where(whereClause).get().toList()

so my query wouldn't be possible to create, which is quite a bummer.

1.0.2 contains this change


chore(Dependencies) : update jsoniter-scala-core, ... from 2.20.7 to 2.30.8

About this PR
📦 Updates

com.github.plokhotnyuk.jsoniter-scala:jsoniter-scala-core
com.github.plokhotnyuk.jsoniter-scala:jsoniter-scala-macros

from 2.20.7 to 2.30.8
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.github.plokhotnyuk.jsoniter-scala" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "com.github.plokhotnyuk.jsoniter-scala" }
}]

labels: library-update, early-semver-minor, semver-spec-minor, version-scheme:early-semver, commit-count:1

Superseded by #743.


Add GOLD treeviewer to GOLD term guidance

A link to https://gold.jgi.doe.gov/ecosystemtree would be helpful in the guidance text for these terms.

Ideally, this would be a see_also on the term, as defined in the NMDC schema
https://gold.jgi.doe.gov/help is already related in that way. Is it OK to expose that in DH too?
If so, we should work on adding see_alsos to the DH guidance. Guidance can already include lots of knowledge.
Damion has a branch of DH that can display the examples help (at least) with a bulleted list. I'll look into whether this could be applied to guidance, too. In that case, adding some see_alsos would be an improvement, especially if somebody can implement the URLs as hyperlinks.