Add Firewall Rules to Azure MySQL Single Server

This PR adds support for querying the firewall rules associated with
an Azure Single Server MySQL
It follows the pattern used to hydrate and parse server
configurations.

Integration test logs

Logs
Add passing integration test logs here

Example query results

Results
Add example SQL query results here (please include the input queries as well)

@ahirreddy thank you so much for the contribution 👍!!
Could you please add an example query wherein the values of the new column are populated?

Hello @misraved and @ahirreddy,
I wanted to share an important update regarding Azure MySQL Single Server. Azure Database for MySQL - Single Server is on the retirement path and is scheduled for retirement by September 16, 2024.
In light of this, I think it would be beneficial to add firewall details to the azure_mysql_flexible_server table. I also have a few suggestions for the current PR:

Instead of manually extracting properties, could we use the generic function structToMap? This function automatically extracts all properties under the struct, eliminating the need for manual checks as seen here.
The azure_mysql_server table does not return any rows, likely because this service is deprecated.
The Azure CLI behaves similarly to Steampipe. The az mysql server list command returns an empty result with a warning message: Azure Database for MySQL - Single Server is scheduled for retirement (https://go.microsoft.com/fwlink/?linkid=2216041) by September 16, 2024. Migrate (https://go.microsoft.com/fwlink/?linkid=2202255) to Azure Database for MySQL - Flexible Server now.

I've attached the code changes and query results for the azure_mysql_flexible_server table for your reference.
Table column:
{
    Name:        "firewall_rules",
    Description: "The firewall rules of the server.",
    Type:        proto.ColumnType_JSON,
    Hydrate:     listMySQLServersFirewallRules,
    Transform:   transform.FromValue(),
},

Hydrate function:
func listMySQLServersFirewallRules(ctx context.Context, d *plugin.QueryData, h *plugin.HydrateData) (interface{}, error) {
	plugin.Logger(ctx).Trace("listMySQLServersFirewallRules")

	server := h.Item.(mysqlflexibleservers.Server)
	resourceGroup := strings.Split(string(*server.ID), "/")[4]
	serverName := *server.Name

	session, err := GetNewSession(ctx, d, "MANAGEMENT")
	if err != nil {
		return nil, err
	}
	subscriptionID := session.SubscriptionID

	client := mysqlflexibleservers.NewFirewallRulesClient(subscriptionID)
	client.Authorizer = session.Authorizer

	op, err := client.ListByServer(ctx, resourceGroup, serverName)
	if err != nil {
		plugin.Logger(ctx).Error("listMySQLServersFirewallRules", "list", err)
		return nil, err
	}

	var mySQLServersFirewallRules []map[string]interface{}

	for _, i := range op.Values() {
		mySQLServersFirewallRules = append(mySQLServersFirewallRules, extractMySQLServersFirewallRules(i))
	}

	if op.NotDone() {
		err := op.NextWithContext(ctx)
		if err != nil {
			return nil, err
		}
		for _, i := range op.Values() {
			mySQLServersFirewallRules = append(mySQLServersFirewallRules, extractMySQLServersFirewallRules(i))
		}
	}

	return mySQLServersFirewallRules, nil
}

Utility function:
func extractMySQLServersFirewallRules(res mysqlflexibleservers.FirewallRule) map[string]interface{} {
	if res.ID != nil {
		return structToMap(reflect.ValueOf(res))
	}

	return nil
}

Result:
> select name, jsonb_pretty(firewall_rules) from azure_mysql_flexible_server;
+---------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| name    | jsonb_pretty                                                                                |
+---------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| terst53 | [                                                                                |
|         |     {                                                                                |
|         |         "ID": "/subscriptions/********-****-****-****-************/resourceGroups/new-rg/providers/Microsoft.DBforMySQL/flexibleServers/terst53/firewallRules/ClientIPAddress_2024-8-5_13-28-29", |
|         |         "Name": "ClientIPAddress_2024-8-5_13-28-29",                                                                                |
|         |         "Type": "Microsoft.DBforMySQL/flexibleServers/firewallRules",                                                                                |
|         |         "Response": null,                                                                                |
|         |         "SystemData": null,                                                                                |
|         |         "FirewallRuleProperties": {                                                                                |
|         |             "endIpAddress": "<IP_ADDRESS>",                                                                                |
|         |             "startIpAddress": "<IP_ADDRESS>"                                                                                |
|         |         }                                                                                |
|         |     }                                                                                |
|         | ]                                                                                |
+---------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

Thanks!

Closing the PR since the API is scheduled for retirement by September 16, 2024.


install_from_index should override PIP_EXTRA_INDEX_URL (#4776)

Pull request opened by the merge tool on behalf of #4776

Merged into branches iso5 in 32f30cfd1587dc27111de87284a912f549057277


A duplicate line seems to be deletable

Hi, thank you for providing this Pytorch implementation of your great work! I really found it helpful.
I just show here Line 196 to 199 in kmax_deeplab/transformer_decoder/kmax_transformer_decoder.py:
clustering_result = prediction_result['mask_logits'].flatten(2).detach() # line 196

    with torch.no_grad():
            clustering_result = prediction_result['mask_logits'].flatten(2).detach() # line 199

So, seems that Line 196 can be deleted? Because Line 199 is the same. Thanks in advance!

Thanks! You are correct that the two lines were duplicated by mistake. We will update the file accordingly per your suggestions. This should not affect the pre-trained weights and usage of this code repo, thanks!


Plan review not working due to 404

Expected behaviour:
As an admin, for the plans submitted for feedback, I expect to be able to click on a plan - click the write plan tab and provide feedback
Actual behaviour:
Example from TU Delft e.g. https://dmponline-test.dcc.ac.uk/plans/49413/edit?phase_id=7287 leads to a 404 error.
Related to mailing, trying to complete a review requests results in the following error " Error: Unable to notify user that you have finished providing feedback." - probably because mailing isn't set up yet.
Steps to reproduce:
Assign yourself TU Delft affiliation, go to Plans (https://dmponline-test.dcc.ac.uk/org_admin/plans) and click on any of the examples submitted for review and try to provide feedback.

Passing user object rather than user id in a couple of places
Fixed in:
https://github.com/DMPRoadmap/roadmap/tree/issue%232645

This looks good to me now. @pherterich do you want to verify?

Works as expected now 😄


weave setup fails with "docker: not found"

The latest snapshot fails in weave setup:
$ weave setup
latest: Pulling from weaveworks/weaveexec
90f4dba627d6: Already exists
c3a059070f8c: Already exists
be7f708e3d16: Already exists
c6f0654dab6f: Already exists
bc0afda9d37e: Already exists
4ef170add6a4: Already exists
4d11e653a953: Already exists
d4243b49cf87: Already exists
3aaf76f66a27: Already exists
d567fa3b867a: Already exists
Digest: sha256:17f92dc2b14535d6e99bb040ede5c816076e1df1ce0c96f53a8120bf864c9c3a
Status: Image is up to date for weaveworks/weaveexec:latest
Using default tag: latest
latest: Pulling from weaveworks/weavedb
Digest: sha256:98ddf536104922d1484571de2cd0464db2d00e8c0b7d186dca331a41f0f77b06
Status: Image is up to date for weaveworks/weavedb:latest
/home/weave/weave: line 246: docker: not found

The problem here is that setup has two halves, which need to execute at the client and server (inside weaveexec), respectively, but is missing a [ -z "$IS_LOCAL" ] guard, just like there is on the version branch. Hence the client part is executed at the server too, which is superfluous and fails since the docker exe was removed from weaveexec.
cc @dtshepherd

We really should add a weave setup test.

Ugh, I know I tested the docker pull change manually, but I'm guessing I did that test prior to removing the docker tgz logic in the Makefile.
I started a bugfix branch and commited this change: https://github.com/weaveworks/weave/commit/bc7dc7b71a9c424779a971761b78551a2f62c7ae
But I'm having issues testing it.  The docker pull locally actually breaks the test because it pulls the weaveexec:latest from Docker Hub which doens't have the fix!  I'll try to look at it more this weekend unless someone else has some ideas...

@rade @bboreham any thoughts on how to avoid the issue with docker pull overwriting the images that were just built when trying to test weave setup?  I could create some kind of testing flag to skip docker pull locally or alias it to be a no-op locally when testing (or set some test file or env variable that I can checked in the test).

One way to test weave setup would be to run a local registry which the build is pushed to, first.
Or push it to dockerhub under the git tag?
I'm not sure I see that work as worthwhile.

Yeah both of those seem painful. Maybe just push the fix without the test for now?

Done - b8d7af3822c0e37cef0b6cab8732e34c95f30b1f

That guard should really go outside the for loop.

That guard should really go outside the for loop.

Fixed in 89c7e6d33


Adds recursive LogBook query feature

WIP
Requires brooklyn-server#1316
Signed-off-by: Andrew Donald Kennedy<EMAIL_ADDRESS>

I suggest to pick a different icon for this, it is not clear which arrow means what as they are similar, besides, there is a styling clash.
https://user-images.githubusercontent.com/81319331/172804314-288b8354-8e1f-416f-8233-e85857dad7c1.mov

I suggest to pick a different icon for this, it is not clear which arrow means what as they are similar, besides, there is a styling clash.

Styling clash when both activated.

Merging this. I'll open a separate PR to address icons.

https://github.com/apache/brooklyn-ui/pull/331 with changed icons.

https://github.com/apache/brooklyn-ui/pull/331 with changed icons.


⚠ Bofrost.de has degraded performance

In f9b4824, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 979 ms

Resolved: Bofrost.de performance has improved in f982549 after 21 minutes.


Flattening a view directly outputs wrong elements

If xt::flatten is called with a xt::view argument, instead of flattening the elements defined by the view ranges, it will provide a flatten of consecutive elements.
For instance, consider the following 3d data:
xt::xarray<double> hsi = xt::linspace<double>(1.0, 100.0, 100);
hsi.reshape({2,5,10});
xt::xtensor<double, 3> spec3d = hsi;

If I want to flatten a small cube from the edge of this data, I need to copy a 3d view from the data and then flatten it, like:
xt::xtensor<double, 3>  data_view = xt::view(spec3d, xt::range(0,2),xt::range(0,3),xt::range(0, 3));
xt::xtensor<double, 1>  flat_data = xt::flatten(data_view);

Then my flat_data would be a 1d tensor with elements  {1,2,3,11,12,13,21,22,23,51,52,53,61,62,63,71,72,73}
If I call flatten with a view argument directly, it will consider elements from 0 to 18 as indices to be flattened:
xt::xtensor<double, 1>  flat_data2 = xt::flatten(xt::view(spec3d, xt::range(0,2),xt::range(0,3),xt::range(0, 3)));
flat_data2 = {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18}
I was told it was a bug, instead of an expected behaviour.

Update:
If I initialize the view with auto the flatten will also output 1d array with consecutive elements. The view must be initialized as xt::xtensor<double, 3> in order for it to work properly.

I've also been bitten by this. I was able to work around it using @tatatupi 's suggestion, but does assigning the result of xt::view() to a xt::xarray/xtensor mean a copy? I would like to avoid that.

Yes this implies a copy. I will investigate this problem this week.

After investigation, the problem is that flatten wrongly assumes that its argument is a contiguous container. Fixing it requires some development that will be done after the release. Since it will be a backward compatible change, we can hopefully release a version with a fix quickly after the 0.20 release.

Thanks Johan.


CAS-599: Use alpine image to run fio

nixery.dev isn't recommended for production use and alpine image is smaller

This is not meant for production. Do you know why we use nixery to begin with?

This is not meant for production. Do you know why we use nixery to begin with?

Would you enlighten me please?

This is not meant for production. Do you know why we use nixery to begin with?

Would you enlighten me please?

It allows us to create any container content by changing the URI itself. So if we want to have fio and, I don't know let us say, sysstat we can change it to nixery/bash/fio/sysstat.
With your change if have to (always) do apk update && apk install what-i-need and would always be stuck with older SW. With nixery we follow the most latest packages, which we need in a lot of cases because we use it during testing (which the YAML file is for)

nixery is really cool. The only downside is that it is unstable. Outages are frequent and long (a couple of hours is not an exception). So if you do an interactive experiment or testing it is a great choice. If you rely on nixery in ci/cd pipeline then it is not so great. IMHO the change as it is now introduces two problems (correct me if I'm wrong):

fio is installed after the container is created so if I exec fio before the installation is completed I will get an error
having to install fio every time container is started makes it more sensitive to network problems
when trying to terminate container with sleep it will take a very long time because sleep does not have a handler for sigterm (that's why tiny was used in previous version of the container).

Clearly we could create our own image with preinstalled fio and use it in ci/cd. We don't get the latest version of the fio then, but actually for the purpose of e2e tests I would argue that it is even desireable if fio version is not changing unexpectedly. But for the yaml file in deploy directory, I would probably continue to use the nixery as it's used interactively and the benefits outweigh the instability of nixery.

Yes, exactly. We should leave the YAML file as-is. The changes to the go code are fine with me. Also, if the deploy directory is assumed to be "part of ci-cd" then I'm not sure if that is a good idea because they were never intended for e2e tests. If we start doing that, then that's fine, but it somewhat changes the initial purpose of these files.

@jkryl:

nixery is really cool. The only downside is that it is unstable. Outages are frequent and long (a couple of hours is not an exception). So if you do an interactive experiment or testing it is a great choice. If you rely on nixery in ci/cd pipeline then it is not so great. IMHO the change as it is now introduces two problems (correct me if I'm wrong):

fio is installed after the container is created so if I exec fio before the installation is completed I will get an error
having to install fio every time container is started makes it more sensitive to network problems when trying to terminate container with sleep it will take a very long time because sleep does not have a handler for sigterm (that's why tiny was used in previous version of the container).

There's indeed a race which I didn't notice. CI-CD pipeline waits in a loop of 1s (IIRC) for the availability of the container so it will probably hit sooner or later. Even though alpine pkg install is really fast, networking issues might help the race to hit here. Good point. As for network problems in general, they can prevent pulling images as well, depends. But that's not something we could prevent and given the generic case I don't think it's clear what's better (pulling larger image vs installing small package - yes, images are often cached, but still I would dare to say which is better generally). As for tini I haven't realized that as well, good point, thanks.

Clearly we could create our own image with preinstalled fio and use it in ci/cd. We don't get the latest version of the fio then, but actually for the purpose of e2e tests I would argue that it is even desireable if fio version is not changing unexpectedly. But for the yaml file in deploy directory, I would probably continue to use the nixery as it's used interactively and the benefits outweigh the instability of nixery.

I will update the ticket. We might build our own image (we have own registry anyway), or just cache nixery's one there. As for versioning, I know too little about NixOS branches and nixery to comment on that but Alpine is pretty fresh (and also this bleeding-edge vs. stable is not a debate for this PR, but I don't agree that latest is always greatest and I agree that version stability and avoiding unintended upgrades makes stuff generally more stable and dependable).
@gila:

Yes, exactly. We should leave the YAML file as-is. The changes to the go code are fine with me. Also, if the deploy directory is assumed to be "part of ci-cd" then I'm not sure if that is a good idea because they were never intended for e2e tests. If we start doing that, then that's fine, but it somewhat changes the initial purpose of these files.

Again just re-iterating - fio.yaml is in our repo and it has a high chance to be used by users. And also high chance to fail due to nixery (clearly stated) not so good availability. Anyway I'm closing this issue due to @jkryl reported race condition which as all race conditions will hit sooner or later.

@jkryl:

nixery is really cool. The only downside is that it is unstable. Outages are frequent and long (a couple of hours is not an exception). So if you do an interactive experiment or testing it is a great choice. If you rely on nixery in ci/cd pipeline then it is not so great. IMHO the change as it is now introduces two problems (correct me if I'm wrong):

fio is installed after the container is created so if I exec fio before the installation is completed I will get an error
having to install fio every time container is started makes it more sensitive to network problems when trying to terminate container with sleep it will take a very long time because sleep does not have a handler for sigterm (that's why tiny was used in previous version of the container).

There's indeed a race which I didn't notice. CI-CD pipeline waits in a loop of 1s (IIRC) for the availability of the container so it will probably hit sooner or later. Even though alpine pkg install is really fast, networking issues might help the race to hit here. Good point. As for network problems in general, they can prevent pulling images as well, depends. But that's not something we could prevent and given the generic case I don't think it's clear what's better (pulling larger image vs installing small package - yes, images are often cached, but still I would dare to say which is better generally). As for tini I haven't realized that as well, good point, thanks.

Clearly we could create our own image with preinstalled fio and use it in ci/cd. We don't get the latest version of the fio then, but actually for the purpose of e2e tests I would argue that it is even desireable if fio version is not changing unexpectedly. But for the yaml file in deploy directory, I would probably continue to use the nixery as it's used interactively and the benefits outweigh the instability of nixery.

I will update the ticket. We might build our own image (we have own registry anyway), or just cache nixery's one there. As for versioning, I know too little about NixOS branches and nixery to comment on that but Alpine is pretty fresh (and also this bleeding-edge vs. stable is not a debate for this PR, but I don't agree that latest is always greatest and I agree that version stability and avoiding unintended upgrades makes stuff generally more stable and dependable).
@gila:

Yes, exactly. We should leave the YAML file as-is. The changes to the go code are fine with me. Also, if the deploy directory is assumed to be "part of ci-cd" then I'm not sure if that is a good idea because they were never intended for e2e tests. If we start doing that, then that's fine, but it somewhat changes the initial purpose of these files.

Again just re-iterating - fio.yaml is in our repo and it has a high chance to be used by users. And also high chance to fail due to nixery (clearly stated) not so good availability. Anyway I'm closing this issue due to @jkryl reported race condition which as all race conditions will hit sooner or later.


Add new feature : API boxes

Describe the feature you are requesting

Hello Sir,
I want to add some cool badges in this repo like

open issues
contributor
open PR
last commites
this type of cool API badges
It will be very helpful to showcase the stats of your Repo as well as will attract more contributors.
Additional context(if any)

Are you contributing under any open-source program ?

APERTRE'24

@AdityaSeth777 Please assign me this issue under APERTRE'24

Greetings and Thank you for submitting the issue ! This message is automated, in case you are wondering. I will get back to you on this.

Assigned under Apertre '24 @apu52

PR #14 merged under this issue and closed. Thank you for contributing.


Can't install - Request for package information failed

Latest version of Atom and Emmet.
Installing<EMAIL_ADDRESS>failed.Hide output… Request for package information failed: Not Found
Console:
Installing package emmet-atom failed Error: Installing<EMAIL_ADDRESS>failed.   at /Applications/Atom.app/Contents/Resources/app/node_modules/settings-view/lib/package-manager.js:280:21   at exit (/Applications/Atom.app/Contents/Resources/app/node_modules/settings-view/lib/package-manager.js:43:16)   at BufferedProcess.triggerExitCallback (/Applications/Atom.app/Contents/Resources/app/src/buffered-process.js:63:47)   at /Applications/Atom.app/Contents/Resources/app/src/buffered-process.js:70:18   at Socket.<anonymous> (/Applications/Atom.app/Contents/Resources/app/src/buffered-process.js:150:18)   at Socket.emit (events.js:129:20)   at Pipe.close (net.js:469:12)  Request for package information failed: Not Found

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/8177046-can-t-install-request-for-package-information-failed?utm_campaign=plugin&utm_content=tracker%2F535900&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F535900&utm_medium=issues&utm_source=github).

It looks like a temporary issue with package registry or Atom itself


Support for Zig version 0.13+

Considering that Zig has its own package management tooling now (managed by build.zig.zon files), and there's been some changes to the APIs used by build.zig, this package is now outdated and doesn't support the latest versions of Zig.

Thanks for pointing this out. I haven't kept up well with zig updates, but I will try to do so in a weekend and update the package.

Any updates regarding this?
A v0.13 refresh would be much appreciated!

Started work on it today, hopefully tomorrow or sometime this week ill get it done. Havent done zig in a bit so lots of changes. Will ask for feedback after I'm done. Also adding zon support.

Almost done, if you'd like to provide feedback or use it already before I merge into main check branch v1.1.0
I tested it with zon and it seems to work well. My only annoyance right now is that some stuff about the build system is unclear to me.


New server group button dissapears

Issue Type: Bug
Hi.
New server group button disappears, when Azure view is hidden from Connections panel.
Azure Data Studio version: azuredatastudio 1.43.0 (b790d700898b1095d83e62f0de14678a58222520, 2023-04-10T23:14:27.236Z)
OS version: Windows_NT x64 10.0.19045
Restricted Mode: No
Preview Features: Enabled

System Info

Item
Value

CPUs
11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz (8 x 1382)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_renderer: enabled_onvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: disabled_off

Load (avg)
undefined

Memory (System)
31.74GB (16.68GB free)

Process Argv

Screen Reader
no

VM
0%

Extensions (5)

Extension
Author (truncated)
Version

admin-pack
Mic
0.0.2

agent
Mic
0.49.0

dacpac
Mic
1.13.0

import
Mic
1.5.4

profiler
Mic
0.12.2

I haven't been able to reproduce this - @cmpl-giedriusk is there a particular sequence of events that leads to this behavior?
Can you consistently reproduce this?

May I know what Color theme are you using?
cc @aasimkhan30


StackOverflow tag/channel

Hello peeps,
thanks for your efforts to bring sanity in content editing on the web and I believe at the certain point, with more integrations & interest to the project, there will be a need for a support  place, like a StackOverflow "channel".
Personally, I don't use it that much to have enough points to  create a new tag, but if you agree with that idea I promise to contribute a first question there :)
Cheers!

@lessless Great idea. Will you create a StackOverflow question for the question you asked in Gitter? I'll add the mobiledoc-kit tag to it. :)

If you link to the SO question here I'll close this and add the tag.

Thank you! Here it is http://stackoverflow.com/questions/36854594/how-to-reproduce-medium-com-editors-embed-media-button-with-mobiledoc-kit
I think it'll be worthwhile to mention that channel in the project readme so people will know where to address questions not related to the project development.
Cheers!

@lessless thanks! I've answered the SO question and added the mobiledoc-kit tag to it. I'll add a pointer to this in the readme, too.


Example of how Scenarios are being used

Is this something for us to build? I'm closing now but re-open with comment if needed.

I don't remember. Fine to close.


Build problem - AWS CDI SDK Makefile looking for /aws-sdk-cpp/aws-cpp-sdk-core

$ make DEBUG=y AWS_SDK=../aws-sdk-cpp/
Makefile:309: *** AWS_SDK does not point to the root of the AWS SDK..  Stop.

$ ls ../aws-sdk-cpp
attribution     CODE_OF_CONDUCT.md  doc_crosslinks      LICENSE                     README.md   tools
CHANGELOG.md    CONTRIBUTING.md     doc_crosslinks_new  LICENSE.txt                 src
cmake           crt                 docs                NOTICE.txt                  tests
CMakeLists.txt  cspell.json         generated           prefetch_crt_dependency.sh  toolchains

In Makefile:
            ifeq (0,$(shell if [ -d $(AWS_SDK_ABS)/aws-cpp-sdk-core ]; then echo 1; else echo 0; fi))                 $(error AWS_SDK does not point to the root of the AWS SDK.)
The docs state:

AWS SDK C++ will be compiled during the build process of AWS CDI SDK, so it is only necessary to download it.

Instead of documented:
make DEBUG=y AWS_SDK=../aws-sdk-cpp/
I tried:
make DEBUG=y AWS_SDK=../aws-sdk-cpp/src/
which started the make process, but ended with:
make: *** No rule to make target `/home/ec2-user/cdi/aws-cdi-sdk/build/debug/include/aws/core/Aws.h', needed by `/home/ec2-user/cdi/aws-cdi-sdk/build/debug/obj/cloudwatch_sdk_metrics.o'.  Stop.

Thank you for identifying this issue. There were recent changes to the AWS SDK CPP that caused this problem to occur. See changes here. We will push changes to the developer_preview branch that resolve the problem for both Linux and Windows variants.

I found this same error today, trying to build on Rocky linux 8.7 with the latest mainline.  Switching to developer_preview branch fixed it.


Assert that the goldenFileComparator is a LocalFileComparator

This is part 9 of a broken down version of the https://github.com/flutter/flutter/pull/140101 refactor.
This is an assumption already silently made by a bunch of casts in this file.

test-exempt: adds an assert that is redundant with existing code (all this does is make the error message more informative)


The 'Install Docker 17.09.0-ce' task is failing

Required Information
The task to 'Install Docker 17.09.0-ce' is failing with the following error
2021-04-07T08:22:52.4385093Z ##[error]Error: Failed to download Docker from location https://download.docker.com/win/static/stable/x86_64/docker-17.09.0-ce.zip. Error Error: Unexpected HTTP response: 404
Question, Bug, or Feature?
Type: Bug
Enter Task Name: Docker CLI installer - DockerInstaller@0
list here (V# not needed):
https://github.com/Microsoft/azure-pipelines-tasks/tree/master/Tasks
Issue Description
When i run the task with the default option it fails. with the following error
Error: Failed to download Docker from location https://download.docker.com/win/static/stable/x86_64/docker-17.09.0-ce.zip. Error Error: Unexpected HTTP response: 404
Task logs
2021-04-07T08:22:51.6442086Z ##[section]Starting: Install Docker 17.09.0-ce
2021-04-07T08:22:51.6631308Z ==============================================================================
2021-04-07T08:22:51.6633087Z Task         : Docker CLI installer
2021-04-07T08:22:51.6634294Z Description  : Install Docker CLI on agent machine.
2021-04-07T08:22:51.6635109Z Version      : 0.181.0
2021-04-07T08:22:51.6635946Z Author       : Microsoft Corporation
2021-04-07T08:22:51.6636867Z Help         : https://aka.ms/azpipes-docker-installer-tsg
2021-04-07T08:22:51.6637565Z ==============================================================================
2021-04-07T08:22:52.1597187Z Downloading: https://download.docker.com/win/static/stable/x86_64/docker-17.09.0-ce.zip
2021-04-07T08:22:52.4385093Z ##[error]Error: Failed to download Docker from location https://download.docker.com/win/static/stable/x86_64/docker-17.09.0-ce.zip. Error Error: Unexpected HTTP response: 404
2021-04-07T08:22:52.4586176Z ##[section]Finishing: Install Docker 17.09.0-ce
Error logs
Error: Failed to download Docker from location https://download.docker.com/win/static/stable/x86_64/docker-17.09.0-ce.zip. Error Error: Unexpected HTTP response: 404

I'm also encountering the same.
Pool Details
Pool: Azure Pipelines
Image: windows-latest
Agent: Hosted Agent

Task
  - task: DockerInstaller@0
    displayName: Docker Installer
    inputs:
      dockerVersion: 17.09.0-ce
      releaseType: stable

Exception
Starting: Docker Installer
==============================================================================
Task         : Docker CLI installer
Description  : Install Docker CLI on agent machine.
Version      : 0.181.0
Author       : Microsoft Corporation
Help         : https://aka.ms/azpipes-docker-installer-tsg
==============================================================================
Downloading: https://download.docker.com/win/static/stable/x86_64/docker-17.09.0-ce.zip
##[error]Error: Failed to download Docker from location https://download.docker.com/win/static/stable/x86_64/docker-17.09.0-ce.zip. Error Error: Unexpected HTTP response: 404

Seems the root cause is windows packages is removed from https://download.docker.com
Is there any solution for it? thanks!

Seems the root cause is windows packages is removed from https://download.docker.com
Is there any solution for it? thanks!

At the moment I converted the pipeline to ubuntu-20.04 and it works.

Our pipeline need run with windows image, so change it to ubuntu doesn't helps.
By now I added a temporary task to download a docker CLI to replace the task DockerInstaller@0:
`
$repo = "StefanScherer/docker-cli-builder"
$tag = "20.10.5"
$file = "docker.exe"
$targetDir = "C:\hostedtoolcache\windows\docker-stable$tag\x64"
New-Item -ItemType Directory -Force -Path $targetDir
$targetFile = "$targetDir$file"
$downloadUrl = "https://github.com/$repo/releases/download/$tag/$file"
Write-Host Dowloading docker version $tag as $targetFile
Invoke-WebRequest $downloadUrl -Out "$targetFile"
Write-Host
& "$targetFile" --version
`
Not a perfect solution, but it fixed our production environment.

We found out that the agent that we are using is already equipped with docker so we skipped this step altgeather.
Stated here https://github.com/actions/virtual-environments/blob/main/images/win/Windows2019-Readme.md
We can close this issue.


Opportunity - detail page

Upon clicking Publish, the user should receive a pop-up message prompting them to post a comment on the issue that:

states that they will respond to questions
encourages readers to ask questions
encourages readers to subscribe to the issue to receive notifications when new comments are posted

Or, we could look at automations for posting this comment for the issue...(?)

[ ] reduce size of font that displays the Short Description

[ ] (after appropriate content pages are created) update boilerplate text that displays under Terms heading with hyperlinks to CWU info and terms.

Done


Removed engines from package.json to avoid dependency problems

Description
It seems there's not a lot of benefit for an essentially client-side dependency to specify a node version. It's not possible to consume the library as an npm dependency (for use with Browserify or Webpack) and use a node version lower than 7, but there's not a good reason for that to be prevented.
Code sample
$ yarn add milligram
yarn add v0.15.1
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
error<EMAIL_ADDRESS>The engine "node" is incompatible with this module. Expected version "^7.0.0".
error Found incompatible module
info Visit http://yarnpkg.com/en/docs/cli/add for documentation about this command.

Hey @michaek Thank you for reporting this issue.
I will not be able to remove this property from the package.json because I had problems with not setting the Node version. Let's find some solution to solve this problem.
I've just extended support for the older versions of Node.js. You can test, now it will work.
$ git clone git@github.com:milligram/milligram.git -b my-branch feature/yarn-support

That works for me. Thanks!


Angular: Prerendering does not work when app is published

The problem
Prerendering does not work when a web application (based on the default Angular template) is upgraded to Angular 5.
Disclaimer:
I'm not sure who can fix this problem. Maybe it's a problem of angular-cli.
Steps to reproduce:
Create new project using default Angular template of VS 2017
Create a new "ASP.NET Core Web Application" using the Angular template (Target ".NET Core" with ASP.NET Core 2.0).
I'm using VS 2017 in version 15.4.4

Upgrade to Angular 5
Now I upgraded to Angular 5 and updated all other packages. This results in the following package.json:
{
  "name": "WebApplication",
  "private": true,
  "version": "0.0.0",
  "scripts": {
    "test": "karma start ClientApp/test/karma.conf.js"
  },
  "devDependencies": {
    "@angular/animations": "^5.0.0",
    "@angular/common": "^5.0.0",
    "@angular/compiler": "^5.0.0",
    "@angular/compiler-cli": "^5.0.0",
    "@angular/core": "^5.0.0",
    "@angular/forms": "^5.0.0",
    "@angular/http": "^5.0.0",
    "@angular/platform-browser": "^5.0.0",
    "@angular/platform-browser-dynamic": "^5.0.0",
    "@angular/platform-server": "^5.0.0",
    "@angular/router": "^5.0.0",
    "@ngtools/webpack": "1.8.0",
    "@types/chai": "4.0.4",
    "@types/jasmine": "2.6.3",
    "@types/webpack-env": "1.13.2",
    "angular2-router-loader": "0.3.5",
    "angular2-template-loader": "0.6.2",
    "aspnet-prerendering": "^3.0.1",
    "aspnet-webpack": "^2.0.1",
    "awesome-typescript-loader": "3.3.0",
    "bootstrap": "3.3.7",
    "chai": "4.1.2",
    "css": "2.2.1",
    "css-loader": "0.28.7",
    "es6-shim": "0.35.3",
    "event-source-polyfill": "0.0.11",
    "expose-loader": "0.7.3",
    "extract-text-webpack-plugin": "3.0.2",
    "file-loader": "1.1.5",
    "html-loader": "0.5.1",
    "isomorphic-fetch": "2.2.1",
    "jasmine-core": "2.8.0",
    "jquery": "3.2.1",
    "json-loader": "0.5.7",
    "karma": "1.7.1",
    "karma-chai": "0.1.0",
    "karma-chrome-launcher": "2.2.0",
    "karma-cli": "1.0.1",
    "karma-jasmine": "1.1.0",
    "karma-webpack": "2.0.5",
    "preboot": "5.1.7",
    "raw-loader": "0.5.1",
    "reflect-metadata": "0.1.10",
    "rxjs": "^5.5.2",
    "style-loader": "0.19.0",
    "to-string-loader": "1.1.5",
    "typescript": "^2.4.2",
    "url-loader": "0.6.2",
    "webpack": "3.8.1",
    "webpack-hot-middleware": "2.20.0",
    "webpack-merge": "4.1.1",
    "zone.js": "0.8.18"
  }
}

Fix Webpack issue
If you publish the application now, you will get the the following error:
Please update @angular/cli. Angular 5+ requires at least Angular CLI 1.5+
This issue is documented here:
https://github.com/angular/angular-cli/issues/8333#issuecomment-341907713
https://github.com/angular/angular/issues/19913
It can be fixed by updating webpack.config.js.
The AotPlugin has to be replaced with the AngularCompilerPlugin.
Now publishing the app is possible without any errors.
Run the application
If you execute the published application with dotnet MyApplication.dll and visit the website you will see the following error in the browser:

The log shows the following error:
Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware[0]
An unhandled exception has occurred: No ResourceLoader implementation has been provided. Can't read the url "app.component.html"
Error: No ResourceLoader implementation has been provided. Can't read the url "app.component.html" at Object.get (bin\Release\PublishOutput\ClientApp\dist\vendor.js:98059:15)

Workaround
The problem can be "hidden" if prerendering is disabled. When Views\Home\Index.cshtml is changed from
<app asp-prerender-module="ClientApp/dist/main-server">Loading...</app>
to
<app>Loading...</app>
you are able to use the published app, but of course without server side prerendering.
Other ideas
If you look at the source code of AngularCompilerPlugin, you can find an option called platform (see angular_compiler_plugin.ts
Setting that option in webpack.config.js did not result in any improvements.
Source code
Here is the full source code of my demo application: Issue_Angular5_Publish.zip

I did the same for Angular 5.0.2 and experiencing same issue. please provide a solution or workaround for this.

me too, I don't know why that is doing.

+1

At the top of your webpack.js file do you have referenced?
Angular 5
const AngularCompilerPlugin = require('@ngtools/webpack').AngularCompilerPlugin;
or
Angular 4
const AotPlugin = require('@ngtools/webpack').AotPlugin;

@justin-ruffin
I'm using const AngularCompilerPlugin = require('@ngtools/webpack').AngularCompilerPlugin;
and<EMAIL_ADDRESS>Thanks for the hint for the additional plugin, but replacing one issue with another issue does not help in the end ;-)

@danielpalme
It's possible my secondary issue is being caused by a custom configuration.
Does adding "new webpack.ContextReplacementPlugin(/@angular(|/)core(|/)esm5/, path.join(__dirname, './ClientApp')),"
vendor.config.js resolve "No ResourceLoader implementation has been provided"?

@justin-ruffin
I will check that tomorrow!

Just tried it myself. I also get the error No NgModule metadata found for 'AppModule'.

Angular 5 includes breaking changes (versus Angular 4) meaning that the code for server-side rendering has to be very different. As such the existing template can't be upgraded to Angular 5 as simply as that, except if you turn off server-side rendering. We're working on an Angular 5 template here: https://github.com/aspnet/JavaScriptServices/issues/1288#issuecomment-346003334

Angular: Prerendering does not work when app is published on server, does not display dynamic data HTML tags on ViewSource page. On Local host It is working fine.   I've tried lot but didn't find anything.
you can check issue in below link.
https://github.com/aspnet/JavaScriptServices/issues/1710


[vfs_fat.c] is fat_drive too short ? (IDFGH-1011)

Development Kit:      [ESP32-Wrover-Kit]
Kit version : [v4.1]
Module or chip used:  [ESP32-WROVER-I]
IDF version a20d02b
Build System:         [Make|CMake]
Operating System:     [Windows|Linux]
Power Supply:         [USB|]

Problem Description
SD Cards with drive label longer than 8 chars may cause unexpected result.
https://github.com/espressif/esp-idf/blob/master/components/fatfs/src/vfs_fat.c#L28
char fat_drive[8]; /* FAT drive name */

as highilighted by @phillowcompiler, shouldn't it be 11 instead of 8 ?

I don't think so because the volume name is not actually used for that.
https://github.com/espressif/esp-idf/blob/a20d02b7f196c407bc9f39b781e31a0a4f665968/components/fatfs/src/vfs_fat_sdmmc.c#L97-L100

so this means even if my fat drive name has more than 8 chars it won't affect anything ?

Ooooh,I seee!
Thanks your research & information!(^^)
I'll resarch more,too...
----- Original Message -----

From: tobozo<EMAIL_ADDRESS>To: espressif/esp-idf<EMAIL_ADDRESS>Cc: phillowcompiler<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Date: 2019/4/21, Sun 17:21
Subject: Re: [espressif/esp-idf] [vfs_fat.c] is fat_drive too short ? (IDFGH-1011) (#3338)
so this means even if my fat drive name has more than 8 chars it won't affect anything ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

As correctly pointed out by negativekelvin, fat_drive only stores the volume name used by FatFS library (such as 0:), not the volume label.


I have some question , can i display data value?

i am using scrollable-graphview... so I think that is very beautiful chart
but i have to show data value... but scrollable graphview only show path...
how can i show data value each bar ... or each line datapoint ?

Same issue as #63


Provide verification example

I'm attempting to use this library to verify and request signed elsewhere, but struggling to get it working without an example.

@dhensby ah, didn't think to look at tests – will give that a try.

Are you using httpbis or cavage?

httpbis, but figuring out the import was a bit of a stuggle as well, as the signing example in the readme doesn't appear accurate…

wrong package name, http-message-signing
AFAIK, sign and createSigner were not exported together.

I suppose I should also ask – should it possible to use this in a browser-ish environment vs node? In my case, I'm a cloudflare worker, and am trying to verify a hmac-sha256 signature. Seems like this should be possible with my own verifier and SubtleCrypto, which is available.
FWIW, I've also tried this package, which has specific examples for verification in browser. While they have docs, they aren't updated, and I have also been unable to successfully verify using that.

I guess it's time for me to update the docs!
It should work in the browser, I think, as there isn't anything requiring specific node functionality.
As you say, if you provide your own signer/verifier then it can all work off of Subtle etc.
Of course, HMAC in the browser isn't a good idea because you'll need to expose the secret to the client (I know you are talking about cloudflare workers, but this is just an NB incase others come and read and miss that detail).

Here's what I have implemented, but cannot get it to verify:
Given secret: 123456789
Given request (generated via https://httpsig.org/):
HEAD / HTTP/1.1
Host: spoke-chain-redux-main-396d681a.preview.craftstaging.cloud
Signature-Input: sig=("host" "@method")
Signature: sig=:R5GjAqZ2KGJST6MSfpQg/EhM7LXaZafOKuZYhvTcBm8=:

Verifying here, but always coming back invalid. Any ideas what I'm missing
https://gist.github.com/timkelty/f4270294a3861cefcaf732a02cd17d79

@timkelty I've opened #157 which has some examples.
I think maybe the consistent use of Buffer objects in the library may mean that this can't actually compile in browsers, but it should run in environments that have a skeleton support for buffers (and it seems edge workers do: https://developers.cloudflare.com/workers/runtime-apis/nodejs/buffer/)

@timkelty here's an example that validates the example request you gave me:
const { httpbis: { verifyMessage }, createVerifier } = require('./lib');

(async () => {
    const keys = new Map();
    keys.set('test-key', {
        id: 'test-key',
        algs: ['hmac-sha256'],
        verify: createVerifier('123456789', 'hmac-sha256'),
    });
    // minimal verification
    const verified = await verifyMessage({
        // logic for finding a key based on the signature parameters
        async keyLookup(params) {
            const keyId = params.keyid;
            // lookup key somehow
            return keys.get(keyId);
        },
        tolerance: Infinity,
    }, {
        method: 'HEAD',
        url: 'https://spoke-chain-redux-main-396d681a.preview.craftstaging.cloud',
        headers: {
            'host': 'spoke-chain-redux-main-396d681a.preview.craftstaging.cloud',
            'content-type': 'application/json',
            'content-digest': 'sha-512=:YMAam51Jz/jOATT6/zvHrLVgOYTGFy1d6GJiOHTohq4yP+pgk4vf2aCsyRZOtw8MjkM7iw7yZ/WkppmM44T3qg==:',
            'content-length': '123',
            'signature': 'sig=:IrkNB32AXmg1bdgPh9QqzCZRe8hMX+73w/eUN0KWP2c=:',
            'signature-input': 'sig=("host" "@method");alg="hmac-sha256";keyid="test-key"',
        },
    });
    console.log(verified);
})().catch(console.error);

Raw JS, I know (sorry) but it does come out as valid. I'll look at your gist to see if there's anything obvious.

I think this is it!
import {Env} from './types';
import {
	httpbis,
	createVerifier,
} from 'http-message-signatures';
import {SignatureParameters} from "http-message-signatures/lib/types";

export default {
	async fetch(request: Request, env: Env, ctx: ExecutionContext): Promise<Response> {
		const verifier = createVerifier('123456789', 'hmac-sha256');
		const keyLookup = (parameters: SignatureParameters) => {
			return Promise.resolve({
				id: 'test-key',
				algs: ['hmac-sha256'],
-				verifier,
-				verify: verifier,
			});
		};

		const valid = await httpbis.verifyMessage({
			keyLookup,
		}, request);

		if (!valid) {
			return new Response('Invalid signature', {
				status: 403,
			});
		}

		return new Response(null, {
			status: 200,
		});
	},
};

doh! I wonder why TS wasn't yelling at me?! Or maybe I just missed it.
Thanks so much! ❤

@dhensby So, that still isn't verifying for me in the CF worker env at least…
Is there any option for just providing your own verify fn, similar to what this lib does? https://ltonetwork.github.io/http-message-signatures/verification/browser.html#verify-callback
Then, I could do my own crypto.subtle.verify logic to ensure it is compatible with my env.

@timkelty see #157

@dhensby getting closer – but even with a custom verifier, I still get ReferenceError: Buffer is not defined, so I suspect it is still being used somewhere behind the scenes?
Buffer is technically available in CF workers, but you have to import it, so I'll have to see if I can polyfill it in my Vite/rollup config. Ideally, though, bringing my own verifier wouldn't require Buffer in my env.

Buffers: Yes, the library does heavily rely on Buffer internally. I suppose I could replace that with Uint8Array, etc but that means also implementing custom base64 decode/encode which I don't currently have a desire to do.
crypot.subtle.verify - yes, good point that would be better and also means the examples are easier to adjust for RSA/ECDSA keys; I've updated the PR.
ft.verify is not a function - so that's happening because my example is confusing. I've named the custom verifier createMyVerifier() which implies it is a drop-in replacement for the internal createVerifier() function, but it isn't - it's just the verify function. I'll rework the example so it is a bit clearer.

Just to say, this change should work:

import {httpbis} from 'http-message-signatures';

function createMyVerifier() {
	return {
		id: 'test-key',
		algs: ['hmac-sha256'],
		async verify(data, signature, parameters) {
			const keyData = new TextEncoder().encode('123456789');
			const algorithm = { name: 'HMAC', hash: 'SHA-256' };
			const key = await crypto.subtle.importKey('raw', keyData, algorithm, false, ['verify']);
			const encodedData = new TextEncoder().encode(data);
			return await crypto.subtle.verify('HMAC', key, signature, encodedData);
		},
	};
}

(async () => {
	// an example keystore for looking up keys by ID
	const keys = new Map();
-	keys.set('test-key', {
-		id: 'test-key',
-		algs: ['hmac-sha256'],
-		// as with signing, you can provide your own verifier here instead of using the built-in helpers
-		verify: createMyVerifier(),
-	});
+	keys.set('test-key', createMyVerifier());
	// minimal verification
	const verified = await httpbis.verifyMessage({
		// logic for finding a key based on the signature parameters
		async keyLookup(params) {
			const keyId = params.keyid;
			// lookup and return key - note, we could also lookup using the alg too (`params.alg`)
			// if there is no key, `verifyMessage()` will throw an error
			return keys.get(keyId);
		},
	}, {
		method: 'HEAD',
		url: 'https://spoke-chain-redux-main-396d681a.preview.craftstaging.cloud/',
		headers: {
			'host': 'spoke-chain-redux-main-396d681a.preview.craftstaging.cloud',
			'signature': 'sig=:IrkNB32AXmg1bdgPh9QqzCZRe8hMX+73w/eUN0KWP2c=:',
			'signature-input': 'sig=("host" "@method");alg="hmac-sha256";keyid="test-key"',
		},
	});
})().catch(console.error);

because my example is confusing

Hah, that was my next question!

implementing custom base64 decode/encode

I've seen other libs use https://github.com/brianloveswords/base64url. That said, for my use, I've gotten around the Buffer requirement, so I'm all good.

Just to say, this change should work:

Indeed it did! 👯👯

Once I tried to replace the request object literal with the actual request, I discovered the request arg isn't compatible with Request or Headers, which is maybe expected, as those are web/browser APIs.
To address that:
{
  method: request.method,
  url: request.url,
  headers: Object.fromEntries(request.headers.entries()),
}

I'll post a full working Cloudflare workers example shortly in case you want to include it in your docs.
Thanks so much for all the help!


GameCaptureHD

Thank you for the contribution. It will be merged in the pull request referenced above due to some simple recommended alterations. Your contribution is still included (and still credited to you), with the appropriate modifications, when applicable.
Changes:

Facilitated future updates.

Thank you for the contribution. It will be merged in the pull request referenced above due to some simple recommended alterations. Your contribution is still included (and still credited to you), with the appropriate modifications, when applicable.
Changes:

Facilitated future updates.


Docs: Custom units

Made another educated guess start of documenting custom units. Would be great to know if this is anywhere close @somebee 🔍 The example can be made simpler, but not sure what the best selling points of custom units are yet.
Custom Units
You can define your own custom numerical unit that can be used for styling and calculations. You define a custom unit by using a css property starting with a number (measure) and then the unit name. For example 1t: . The unit can have modifiers like break points and you can use the units in the same way as native numerical units like px and em.
Here is an example defining t and w as units:
tag base-dialog
    css
        1t:5vmin @md:200px @lg:10% # define t to different variable sizes depending on the width of the screen
        1w:340px # define the w unit as a fixed size
        max-width:2w # basic use of custom unit
        max-height: calc(100vh - 1t) # calculate with custom unit
        position:absolute top:1t left:calc(50% - 0.5w) # Using fraction of units

tag larger-dialog < base-dialog
    css
        1t:10vmin @md:400px @lg:20% # re-defining the `t` unit - all inherited styles will use the new value
        1w:400px
        # will inherit max-width, max-height, top and left properties with overwritten w and t values.
        # max-width: 2w => 2 * 400px => 800px
        # max-height: calc(100vh - (10vmin @md:400px @lg:20%))
        # position:absolute top:(10vmin @md:400px @lg:20%) left:calc(50% - 0.5 * 400px) # Using fraction of units

Part of of #163

People often use a css variable to store a custom unit, and then multiply from it to have units relative to that. like padding: var(--global padding) * 2 instead of that, you just make your own custom unit like 1gp:0.2em and just double it like 1gp. I believe that's the selling point or idea behind why @somebee made custom units.
Sent with GitHawk

Thanks @ericvida  - I pushed a first draft based on your feedback.
Custom Units
You can define your own unit that can be used for styling and calculations. The unit can have modifiers like break points and you can use the units in the same way as other css units. The syntax to define a custom unit is <measure><name>: <value> e.g. 1col: calc(100vw / 12).
global css @root
    1pad: 25px
    1col: calc(100vw / 12)

tag app-dialog
    css
        width: 12col @md: 6col lg: 3col
        p: 1pad

@Pistus this is a great example. Very smart use of custom units. The only thing is that when I use 1col it doesn't work for me. If I use 1column it works. Not sure if there's some conflict going on.


onEndReached is not working

Hi I add your plugin in my project it was working fine but when I try to add onEndReached onEndReachedThreshold was not working can you please tell me how we can load data on scroll.
Thanks

Hey @anehkumar, see if this example helps: https://github.com/brh55/react-native-masonry/blob/v0.5.0/example/App/Container/app.js


remove secure storage

Motivation
Based on feedback, we have removed the secure storage page and replaced it with an under construction page.
This change also makes changes to allow all under construction pages to use the same single html page.
We also have updated the hex color values to match that of the ios and android app
Screenshot

@wei-lee I have made that update to use a single construct page, good catch

@pawelpaszki mind having another look, good catch with that :+1:

@ciaranRoche looks good to merge after the last update


Remove deprecated properties in GeocoderViewModel in 1.31

The GeocoderViewModel and related classes have been updated as part of #4723.
Its url and key properties will be deprecated from 1.30 and removed in 1.31.

Updated the release numbers here since the new wasn't merged before 1.29 was released.

@hpinkos can you change the label?


add ability to unlink social accounts (twitter, linkedin)

Pre-Submission Checklist

[x] Your pull request targets the staging branch of FreeCodeCamp.
[x] Branch starts with either fix/, feature/, or translate/ (e.g. fix/signin-issue)
[x] You have only one commit (if not, squash them into one commit).
[x] All new and existing tests pass the command npm run test-challenges. Use git commit --amend to amend any fixes.

Type of Change

[ ] Small bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds new functionality)
[ ] Breaking change (fix or feature that would change existing functionality)
[ ] Add new translation (feature adding new translations)

Checklist:

[ ] Tested changes locally.
[x] Closes currently open issue (replace XXXX with an issue no): Closes #10809

Description

only tested locally for Twitter as I can't get LinkedIn to work on my local
after unlink, user is redirected to /username, actually I expect it to be redirected to /settings but there is a bug when doing that, see #10879
I use user[social] = null; instead of user[social] = undefined; because rejected by js-lint: Unexpected use of undefined  no-undefined. Let me know your thought

cc @BerkeleyTrue

@iamrudra what's the status of this. Is it ready to QA?

@QuincyLarson did you mean to mention me? yes it is ready for QA

@ivantedja - I am sure he did
CC - @QuincyLarson

disregard my previous comment, I read person's name incorrectly 😆

Check out the docs on relationships here https://docs.strongloop.com/display/public/LB/HasMany+relations

@BerkeleyTrue thanks for the reference, has been updated

@BerkeleyTrue I can't test this locally because it seems Twitter linking functionality is broken (it's trying to link to http://localhost:3000/en/account instead of http://localhost:3000/account). I will create a separate issue and assign you to it.

@BerkeleyTrue New issues is here: https://github.com/FreeCodeCamp/FreeCodeCamp/issues/11301

@ivantedja is this now ready for a QA?

@Bouncey yes it is :)

@BerkeleyTrue are you able to QA this? I couldn't get Twitter account linking working locally.

I'll give it a go

Code works great. One last change and it is ready to merge! ✨

@ivantedja Nice work!
Happy Coding

@ivantedja Awesome job! Thank you for building out this feature! @BerkeleyTrue thank you for QAing this.

I can't use the remove or unlink function for Linkedin or Twitter. Seems this feature has been removed.

@timetxt this feature hasn't been deployed to production yet - it's still on beta.freecodecamp.com

Thanks Quincy. Looking forward to seeing this feature soon in the future.


Filter equality matchers on the dynamo side

Fixes #398

Created some extra tests for the aws storage client and started filtering by range key.
Added simple field to IndexEntry which is then used to add the filter condition to dynamo if it exists

Just a bunch of nits, LGTM otherwise.

@aaron7 Feel free to merge this if you've addressed all of @tomwilkie's points.


[FLINK-14631] Account for netty direct allocations in direct memory limit (Netty Shuffle)

What is the purpose of the change
At the moment after FLINK-13982, when we calculate JVM direct memory limit, we only account for memory segment network buffers but not for direct allocations from netty arenas in org.apache.flink.runtime.io.network.netty.NettyBufferPool. We should include netty arenas into shuffle memory calculations.
The arenas should not be used too much after adding credit based control. They should be immediately copied into network buffers. Therefore, having number of arenas equal to the number of slots by default seems to be redundant and we can have just one 16Mb arena by default. Eventually, arena usage should become almost zero after #7368 except sending task events etc.
Other off-heap memory uncontrollable usages in Flink dependencies can be addressed by framework off-heap memory config introduced in #10124.
Brief change log

Adjust default number of netty arenas to 1
Add netty arenas to shuffle memory calculations for legacy config
Add test and adjust others

Verifying this change
Unit tests.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (no)
The serializers: (no)
The runtime per-record code paths (performance sensitive): (no)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: (no)
The S3 file system connector: (no)

Documentation

Does this pull request introduce a new feature? (no)
If yes, how is the feature documented? (not applicable)

cc @xintongsong @StephanEwen @pnowojski

Thanks @azagrebin for this fixing.
Some background information to share from my side:
ATM the netty internal memory overhead should be small on output side.  After the zero-copy improvement for input side working well via 7368, the whole netty memory overhead should be very small, even ignored. I wished to make this thing happen in next release, but not guarantee it.  Based on the current situation, the netty memory overhead can reach even 1GB in large scale job sometimes.
The number of arenas was coupled with the number of slots before by default, because this concept is a bit complex for users. Unless netty experts, it is difficult for users to understand how many memory would be allocated within one arena. Actually the number of arenas should be related to the number of physical connections and netty threads.
Another option is to let users config this portion of memory size directly, which is somehow better understood, and the framework can make the transformation of arenas internally. My comment is not the blocker for this PR merging. :)

@zhijiangW
Really thanks for the good insight.
We were thinking about a reasonable default value for the number of arenas before we get the zero-copy PR in. It seems that allocating even one arena is too much in most of our testing scenarios. But the artificial tests might be not conclusive enough for that as you just mentioned it can reach even 1Gb. According tor your experience, what would be that reasonable default value for the number of arenas? Should we keep the previous one - number of slots?
When you say: let users config this portion of memory size directly, do you mean number of arenas? We keep the number of arenas configurable directly and account for them in shuffle memory size. Shuffle memory size is also configurable separately. We also check that the configured shuffle memory size is enough for the configured number of arenas. Did you mean something like this?
@pnowojski
sure, I will add the description to the commit

Thanks for the reply and confirmation @azagrebin !
I guess there are two issues above:

What is the proper default value of number of arenas?

It is a bit hard to give a proper default value here. In previous default setting, both the number of arenas/netty threads are referring the number of slots, because it is reasonable to keep the same between numThreads and numArenas to avoid thread contention.
In netty internal implementation, the number of arenas is calculated by maxDirectMemory/16MB/6, because in general one arena might keep six chunks for different usage ratio.
In a light-weight case I mean data are not accumulated in input/output queues and there are not many netty threads working concurrently, then the current value seems make sense as you mentioned in testing scenarios. The increased netty overhead is almost happening the large scale job with back pressure case.
In the past, the total container memory was not considered the number of arenas. So even though we set it as the number of slots, it would not increase the processor resource. But now it might waste cluster resources if that amount arenas are not used in practice. If we are not caring much about the netty memory overhead, I prefer to make one arena with 6 chunks by default, not only for one chunk now.

How to give the config for outside users?

There are two config options now, one is for shuffle memory which is used by Flink NetworkBufferPool and the other is for netty usages via numberOfArenas. We plus them together as one factor of container's max direct memory resource. My previous concern was that the config of numberOfArenas is too expert for users and we can not give a proper explanation to guide users how to adjust it accordingly. But we have the specific formula for calculating the NetworkBufferPool side. I think there might have three options:

Remove the numberOfArenas config for outside users, the framework can deduct this portion automatically from the config of shuffle memory size. But it might need to adjust the descriptions of current network memory setting.

Keep both config options, but adjust the numberOfArenas as nettyMemorySize, because the size seems more easy understood by users instead of arena concept. But it might seem a bit strange to have two setting for shuffle service itself.

Keep both config options as now in this PR, still uses the numberOfArenas, and it is based on the consumption that this config is rarely touched by outside users in most cases.

You can choose one way as you prefer finally. :)

Thanks for the further feedback @zhijiangW
I am adding a fixup to change the expected number of chunks per arena to 6 for accounting in shuffle memory size computation. It seems to be our best guess atm. We can later adjust it if some bigger scale jobs show us during release testing that it needs an increase.
Not sure, I fully understand the first option for configuration setup. It seems the number of really required arenas depend on actual job and cluster.
I also agree that yet another config nettyMemorySize is too confusing. We can keep the current way of configuration. I am adding more into docs and a wrapping exception in case of OutOfMemoryError for allocation from arenas explaining how to tackle it by increasing number of arenas.
@zhijiangW @xintongsong
would be nice if you have another look into the fixup.

Sorry for missing your last reply @azagrebin and I am also LGTM for the changes.
Just found another nit issue for the change of README ;)

Thanks for the reviews @xintongsong @zhijiangW
merging this
I also increased minimum shuffle memory to accommodate for the increased number of Netty arenas as discussed offline

After having a longer discussion, the conclusion is that we do not make this change but account for netty arenas in framework off memory config #10124. This should become even less problem after we merge #7368.


Confusing AuthorizationMessageHandler remark

[EDIT by guardrex to add the metadata. You can add the metadata when you open an issue using the This page feedback button at the bottom of any article.]
AuthorizationMessageHandler is a DelegatingHandler used to attach access tokens to outgoing HttpResponseMessage instances.
I was wondering if something is the matter with me or with your documents... Shouldn't outgoing HttpResponseMessage be outgoing HttpRequestMessage.  All the related documents use outgoing HttpResponseMessage I'm about to doubt my sanity.

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

ID: 53f3209c-2414-9b35-6245-383c9b7c6338
Version Independent ID: cc8dfcd6-8d93-5aa3-c381-2b613e88cdbe
Content: ASP.NET Core Blazor WebAssembly additional security scenarios
Content Source: aspnetcore/blazor/security/webassembly/additional-scenarios.md
Product: aspnet-core
Technology: aspnetcore-security
GitHub Login: @guardrex
Microsoft Alias: riande

Hello @enetstudio ... Yes, I agree ... it's confusing blurted out like that. We might make a change in the articles, and the product unit might want make a change to the API docs from which the article's remarks are derived.
The tokens are attached to HttpRequestMessage, as the following will show, but AuthorizationMessageHandler in the API docs explain the same thing as our Blazor article ("outgoing" for the HTTP response message) ...

A DelegatingHandler that attaches access tokens to outgoing HttpResponseMessage instances.

Reference: https://docs.microsoft.com/dotnet/api/microsoft.aspnetcore.components.webassembly.authentication.authorizationmessagehandler
... where the DelegatingHandler API doc defines ...

A type for HTTP handlers that delegate the processing of HTTP response messages to another handler ...

Reference: https://docs.microsoft.com/dotnet/api/system.net.http.delegatinghandler
Take a look at the reference source at ...
https://github.com/dotnet/aspnetcore/blob/main/src/Components/WebAssembly/WebAssembly.Authentication/src/Services/AuthorizationMessageHandler.cs#L47-L82
From the API docs again, AuthorizationMessageHandler.SendAsync ...

Sends an HTTP request to the inner handler to send to the server as an asynchronous operation.

Reference: https://docs.microsoft.com/dotnet/api/microsoft.aspnetcore.components.webassembly.authentication.authorizationmessagehandler.sendasync
The delegating handler attaches a token (existing or a new one that it obtains from the token provider) to the HttpRequestMessage (request) parameter and base.SendAsync() is called/awaited at the end with the method returning a Task<HttpResponseMessage>. This makes it so that API calls don't need to deal with the ceremony in developer code or have duplicated code to get access tokens on web API requests.
The confusing "outgoing" language is probably present because this is from the handler as an HttpResponseMessage and these handlers process both requests and responses and are chained, sort of like middleware.
We have some light coverage in the HTTP Requests article ...
https://docs.microsoft.com/aspnet/core/fundamentals/http-requests#outgoing-request-middleware
Now, I'm aware of Steve Gordon's (old but still valuable) article ...
https://www.stevejgordon.co.uk/httpclientfactory-aspnetcore-outgoing-request-middleware-pipeline-delegatinghandlers
His article probably explains similar things about delegating handlers that the .NET docs explain, noting that HttpClient and DelegatingHandler are actually over in System.Net.Http, not here ... not ASP.NET Core. Outside of that bit in the HTTP Requests article, you probably won't find further coverage in ASP.NET Core docs.
Shameless plug btw for @stevejgordon's PluralSight courses, which are highly regarded in the community ... and No! I'm not getting a kickback 💰 for mentioning that 😆. Indeed! Note that Steve wrote the initial HTTP Requests article, and I think it has been popular with our readers. You'll see the parallels in that Outgoing Request Middleware section to his blog post.
Perhaps, we should expand the explanations on this in the article seeking to avoid this confusion of an "outgoing" "response" for a token attached to a "request." I'd like to ping Javier later on this. I'd like to see if we can clear up the confusion. I can't reach out to him until after 7.0 ships later this year. The product unit is 🏃😅 under a heavy workload to get the next release out. I'll definitely touch base with Javier in either EOY or 23Q1.
... and please @stevejgordon if you receive this, correct me if I'm wrong about anything or if you have some additional color that would help here with "outgoing HttpResponseMessage instances."
When I worked on this language ... ei ei ei ... it may have been three years ago at this point ... I believe that I derived the language from the API docs thinking that external resources would fill in any detail on that. The cross-linked content leaves me unhappy with the current choice of words without further explanation, and that's assuming that their choice of words is sane. They may decide that that's a blown API description.
I'll get back to this as soon as I can, but expect work on it EOY or 23Q1. 🏃😅

@guardrex,
Thanks for your exhaustive response... The issue begins with the following:
A <see cref="DelegatingHandler"/> that attaches access tokens to outgoing <see cref="HttpResponseMessage"/> instances.
Source: https://github.com/dotnet/aspnetcore/blob/ce8419e91d84d42690da18d7af40e7ac086c11f4/src/Components/WebAssembly/WebAssembly.Authentication/src/Services/AuthorizationMessageHandler.cs#L11
And it is being cascaded to all the articles and documents that deal with DelegatingHandler. It simply should be HttpRequestMessage instead of HttpResponseMessage.

Perhaps, we should expand the explanations on this in the article seeking to avoid this confusion of an "outgoing" "response" for a token attached to a "request."

I don't think more explanations is needed. The issue is not the explanations, but the use of the wrong word. Just change AuthorizationMessageHandler is a DelegatingHandler used to attach access tokens to outgoing HttpResponseMessage instances. To AuthorizationMessageHandler is a DelegatingHandler used to attach access tokens to outgoing HttpRequestMessage instances
Good day...

FYI: The articles are under our control. The API docs are under the direct control of the product unit. The API docs are derived directly from their API comments in the framework code.

I don't think more explanations is needed ... the use of the wrong word

I don't think that's going to turn out to be the case. The product unit usually doesn't make mistakes like that. I think Javier wrote that code/text, and he almost never makes mistakes, especially something that obvious. Additionally, all of the framework code is reviewed by other TOP ✈ GUN devs on the team, and they would likely catch something like that. This code has been here a LONG time, too ... several years ... and likely would've been challenged by a dev along the way if it were wrong.
I can inquire with them, but it will need to wait until 7.0 releases later this year. They're just too busy to chat about something this minor at this time. Our best bet in the meantime is if @stevejgordon sees this and tells us what's what ... if my interpretation is correct/incorrect.

@guardrex,
Again, I do not suggest that the code is faulty. The code is perfectly fine... The issue is with the comments that are being cascaded to the documents, and express something that is not true. When you read in the documents: AuthorizationMessageHandler is a DelegatingHandler used to attach access tokens to outgoing HttpResponseMessage instances.
You read something completely wrong. An access token is added to an outgoing request message, not to a response message of which you can't speak in terms of outgoing...

I don't think that's going to turn out to be the case... challenged by a dev along the way if it were wrong.

I completely disagree with you. To prove that you're wrong I decided to peruse the Blazor source code, and of course started with ComponentBase class. Here's what I found: Override this method if you will perform an asynchronous operation https://github.com/dotnet/aspnetcore/blob/a4906cd3e44136bd210bd522ff61eadba3f84a86/src/Components/Components/src/ComponentBase.cs#L69
Now, this grammar mistake is being cascaded to the docs, a formal document of Microsoft. 13 contributors, and no one have noticed if you will perform? What say you ? OK, I won't be childish, and stop here.
A couple of years ago I posted in Github an issue which contained a list of problems related to the comments. There were two types of mistakes. As for instance, the code employs an HttpClient object, but in the comments the HttpClient becomes HttpContext, and such like. The other type of mistakes are related to the English language: grammar mistakes, incomplete sentences ( a whole sentence is a subject with no predicate, no object...), wrong use of the indefinite article an, not being aware that you apply the article to singular noun that begins with initial vowel SOUND, and such like. All these are being cascaded to the docs, which is your own domain, right. Anyhow, Steve Sanderson suggested that I would open new pull requests. Poor me, I didn't even know what is a pull request. I only wanted to attract the Blazor team's attention to the existence of these issues. Years after these  issues are still persisted. It's a pity I find it hard now to locate them.
Good day. Sorry for taking your time.

No, you don't understand what I'm telling you: The framework code contains the API remarks, and the API remarks are what generates the API documentation. That must be updated on the product unit's repository. Nothing is "cascaded," per se, directly from their API remarks to the ASP.NET Core documentation set of this repo. Yes, we use their remarks in articles, and we do seek to improve grammar and style of those remarks when we use them. To any extent that we've failed in this regard, we welcome issues and PRs for corrections. If there's an error in the API remarks, the product unit must make that update (or at least agree to an update if a community member submits the PR).
WRT poor grammar in API remarks, I do not disagree with you 😄, and I've raised that issue with management a few times over the years. It hasn't been a priority for them to take on a formal effort to improve it ... and not just API remarks ... framework error messages also use some ... er ... interesting English! 😆. They do allow community developers to submit changes to those remarks (and error messages) on their repo. It's always best to ask first tho in an issue. PRs without an issue are generally only welcome for true patches (e.g., a misspelled word).
... and btw ... WRT there being a simple grammar mistake or not in the framework's API remarks, that is undetermined at this time. You might be right. I'm just saying that we should get formal guidance from Javier before making any changes to the articles. I will return to this and get it sorted out as soon as I can. I don't want to disturb Javier at this time given the heavy workload over there for .NET 7.

I took another look at this, and I'm going to try and reach out (internally) to see if my hunch is correct. I'm pitching that we merely clean up the confusing language by changing the remark to ...

AuthorizationMessageHandler is a DelegatingHandler used to process access tokens.

However, the API docs probably won't change. I think what they say is correct given the way that these message handlers process the tokens and requests/responses internally. That's not too important for the doc tho. I think we can just say "process access tokens" and not get into the weeds on the underlying implementation and behavior.
If my guess is wrong tho, Javier will probably make a change to the API docs. There are two spots that he'd need to look at. The AuthorizationMessageHandler API remarks and the DelegatingHandler API remarks would probably need to be updated or expanded. Those are in the framework code and not under our control here.
I'll ping you on the PR when I get a response and create some kind of fix for this.


Bump nixpkgs rev from nix-shell to latest release-20.03 revision

Please note that cargo make currently fails with the following error:
    Finished test [unoptimized + debuginfo] target(s) in 0.08s
     Running /home/ma27/Projects/ratatosk/target/debug/deps/rask_wasm_graphics-4debfeb74d3fe2ac
error: test failed, to rerun pass '--lib'

Caused by:
  process didn't exit successfully: `/home/ma27/Projects/ratatosk/target/debug/deps/rask_wasm_graphics-4debfeb74d3fe2ac` (signal: 11, SIGSEGV: invalid memory reference)
[cargo-make] VERBOSE - Output: Ok(
    Output {
        status: ExitStatus(
            ExitStatus(
                25856,
            ),
        ),
        stdout: "",
        stderr: "",
    },
)
[cargo-make] ERROR - Error while executing command, exit code: 101
[cargo-make] WARN - Build Failed.
[cargo-make] ERROR - Error while executing command, exit code: 1
[cargo-make] WARN - Build Failed.

Will take a closer look at the issue tomorrow (@TrueDoctor do you have an idea what might've caused this? If not it's perfectly fine, there's still a chance that this is not rask-related and caused by Nix. In that case I'll hopefully find the cause at next weekend and provide a fix :))

seems to be working on ci


Support DataTree in xarray.concat

What is your issue?
Something like this works, but is a little awkward -- especially the skipping over dimensions that are only defined on some node levels:
def concat(*datasets, dim):
    if not all(dim in ds.dims for ds in datasets):
        return None
    return xarray.concat(*datasets, dim=dim)

xarray.map_over_datasets(concat, tree1, tree)

I agree - but I think this issue is a duplicate of #9106.

Gonna keep this open as a small sub-issue that's part of the checklist in https://github.com/pydata/xarray/issues/9106


Cancelling Dataset refresh

[Enter feedback here]

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

ID: ce280443-0aa3-da51-f71d-ff7c1704b268
Version Independent ID: 8122662c-44c4-317d-ef45-44bd3f204487
Content: Data refresh in Power BI - Power BI
Content Source: powerbi-docs/connect-data/refresh-data.md
Service: powerbi
Sub-service: pbi-data-sources
GitHub Login: @davidiseminger
Microsoft Alias: davidi

Dataset refresh cannot be cancelled in the middle, as of now right. Can we expect this feature?


[SR-12972] SourceLocationConverter initializer that accepts a SourceFileSyntax is slower than the String version

Previous ID
SR-12972

Radar
rdar://problem/64230275

Original Reporter
dylansturg (JIRA User)

Type
Bug

Attachment: Download

Additional Detail from JIRA

Votes
0

Component/s
SwiftSyntax

Labels
Bug

Assignee
None

Priority
Medium

md5: 4656fb002ec2b67ed48c8aa22d56eebf

Issue Description:
SourceLocationConverter has 2 initializers, one uses a String and the other uses a SourceFileSyntax. Based on my testing, the String based initializer is noticeably faster than using a SourceFileSyntax.
For a test case, I selected a relatively large file from swift-syntax (~ 10k LOC). The initializer that accepts a string takes ~ 2ms while the other initializer takes ~ 70 ms.

I was able to reproduce this to some degree with the following test:
import SwiftSyntax
import SwiftParser
import Foundation

let str = try! String(contentsOfFile: "/Users/alex/Downloads/SR-12972/SyntaxBuilders.swift")

let tree = try! Parser.parse(source: str)

// Warm up caches
for _ in 0..<10 {
  _ = SourceLocationConverter(file: "", source: str)
}
for _ in 0..<10 {
  _ = SourceLocationConverter(file: "", tree: tree)
}

do {
  let start = Date()
  for _ in 0..<100 {
    _ = SourceLocationConverter(file: "", source: str)
  }
  print("String based initializer took: \(Date().timeIntervalSince(start)/100 * 1000) ms")
}

do {
  let start = Date()
  for _ in 0..<100 {
    _ = SourceLocationConverter(file: "", tree: tree)
  }
  print("Tree-based initializer took: \(Date().timeIntervalSince(start)/100 * 1000) ms")
}

The output was as follows:
String based initializer took: 11.692179441452026 ms
Tree-based initializer took: 35.53478002548218 ms

This matches my expectations because the tree needs to first be converted into a source string before SourceLocationConverter can build up its line table. I suspect the original discrepancy was larger because the reporter was using a debug build of SwiftSyntax.
I’m closing this as correct behavior. If the performance of SourceLocationConverter is a bottleneck for someone in release builds, we can re-consider creating an optimized initializer for SourceLocationConverter that doesn’t convert the tree into a string first.


[All hosts](community call) Add September 2022 agenda

Adds agenda for September 14th, 2022.

Docs Build status updates of commit 987285d:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/overview/office-add-ins-community-call.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


NameError: name 'NonDynamicallyQuantizableLinear' is not defined

I am using torch1.8.1+cu111 with "NameError: name 'NonDynamicallyQuantizableLinear' is not defined" error.
What is the reason for this?

Could you try changing your pytorch version to 1.9.0 or 1.10.1?

I am using torch1.8.1+cu111 with "NameError: name 'NonDynamicallyQuantizableLinear' is not defined" error. What is the reason for this?

You can find the answer here: https://github.com/cv516Buaa/tph-yolov5/issues/19

What version of the timm library do you have installed? Whenever I try to install it, it always changes my torch version to torch 2.2_

I used timm==0.9.11 version.


Once Local Player Desyncs, it takes many position re-corrections to get back on course

closed by #17


The SPI host document is not consistant with the SPI HOST circuit.

The SPI host document is not consistant with the SPI HOST circuit.
Will the document be corrected ? or the deisgn will be updated ?
https://docs.opentitan.org/hw/ip/spi_host/doc/
// Register offsets
parameter logic [BlockAw-1:0] SPI_HOST_INTR_STATE_OFFSET = 6'h 0;
parameter logic [BlockAw-1:0] SPI_HOST_INTR_ENABLE_OFFSET = 6'h 4;
parameter logic [BlockAw-1:0] SPI_HOST_INTR_TEST_OFFSET = 6'h 8;
parameter logic [BlockAw-1:0] SPI_HOST_ALERT_TEST_OFFSET = 6'h c;
parameter logic [BlockAw-1:0] SPI_HOST_CONTROL_OFFSET = 6'h 10;
parameter logic [BlockAw-1:0] SPI_HOST_STATUS_OFFSET = 6'h 14;
parameter logic [BlockAw-1:0] SPI_HOST_CONFIGOPTS_OFFSET = 6'h 18;
parameter logic [BlockAw-1:0] SPI_HOST_CSID_OFFSET = 6'h 1c;
parameter logic [BlockAw-1:0] SPI_HOST_COMMAND_OFFSET = 6'h 20;
parameter logic [BlockAw-1:0] SPI_HOST_ERROR_ENABLE_OFFSET = 6'h 28;
parameter logic [BlockAw-1:0] SPI_HOST_ERROR_STATUS_OFFSET = 6'h 2c;
parameter logic [BlockAw-1:0] SPI_HOST_EVENT_ENABLE_OFFSET = 6'h 30;

Is there any comment or hint ?

Hi @nicolast0604,
Can you please be more specific about the inconsistency you are seeing?

In the SPI host documentation,
https://docs.opentitan.org/hw/ip/spi_host/doc/
The register address is :
spi_host.INTR_STATE @ 0x0
spi_host.INTR_ENABLE @ 0x4
spi_host.INTR_TEST @ 0x8
spi_host.ALERT_TEST @ 0xc
spi_host.CONTROL @ 0x10
spi_host.STATUS @ 0x14
spi_host.CONFIGOPTS @ 0x18
spi_host.CSID @ 0x1c
spi_host.COMMAND @ 0x20
spi_host.RXDATA @ + 0x24
spi_host.TXDATA @ + 0x28
spi_host.ERROR_ENABLE @ 0x2c
spi_host.ERROR_STATUS @ 0x30
spi_host.EVENT_ENABLE @ 0x34
However, if you check the
hw/ip/spi_host/rtl/spi_host_reg_pkg.sv
You will find the real address is as below, which is not consistent to the above documentation.
// Register offsets
parameter logic [BlockAw-1:0] SPI_HOST_INTR_STATE_OFFSET = 6'h 0;
parameter logic [BlockAw-1:0] SPI_HOST_INTR_ENABLE_OFFSET = 6'h 4;
parameter logic [BlockAw-1:0] SPI_HOST_INTR_TEST_OFFSET = 6'h 8;
parameter logic [BlockAw-1:0] SPI_HOST_ALERT_TEST_OFFSET = 6'h c;
parameter logic [BlockAw-1:0] SPI_HOST_CONTROL_OFFSET = 6'h 10;
parameter logic [BlockAw-1:0] SPI_HOST_STATUS_OFFSET = 6'h 14;
parameter logic [BlockAw-1:0] SPI_HOST_CONFIGOPTS_OFFSET = 6'h 18;
parameter logic [BlockAw-1:0] SPI_HOST_CSID_OFFSET = 6'h 1c;
parameter logic [BlockAw-1:0] SPI_HOST_COMMAND_OFFSET = 6'h 20;
parameter logic [BlockAw-1:0] SPI_HOST_ERROR_ENABLE_OFFSET = 6'h 28;
parameter logic [BlockAw-1:0] SPI_HOST_ERROR_STATUS_OFFSET = 6'h 2c;
parameter logic [BlockAw-1:0] SPI_HOST_EVENT_ENABLE_OFFSET = 6'h 30;

I see.  Many thanks for your careful scrutiny here!
The only difference between the two is that RXDATA and TXDATA are not included in the register map, which is to be expected as these two addresses are technically not registers. They are implemented as memory windows and mapped to the TX & RX FIFOs.  So not being registers, they technically don't have "register offsets".   However both the documentation and the register implementation are generated from the same hjson table.   So if they were different that would probably imply that we had broader problems in the other IP, so it's good to have lots of eyes looking out for this.
The DIF in #8872 has been tested in FPGA with some success, so you should be able to start with that.   Though please note that there have been some changes to the IP since the DIF PR was submitted.  For instance see #9858. You can also look at the complete history of changes to the register specification.  Most of the commits are minor, but #9958 is a pretty serious change, you won't be able to even turn on the outputs without activating the new OUTPUT_EN field.

@nicolast0604: Please let me know if there are any other concerns about the documentation.  Otherwise I will close this issue.


swt decomposition without all the coarse levels

In the current implementation of the swt, the function returns all the coarse levels (called here approximation). But I think we only need the last one theoretically.
Indeed, when looking at the code, you can see that the approximation coefficients are discarded and when only keep the detail coefficients for reconstruction. The last coarse level is safely saved here. I think it would be nice if there was an option to decompose/reconstruct without all these additional coefficients.

Agreed. This feature was recently proposed in #476 if you have any feedback to add there in terms of how you would like it to look.

No, I think from what I saw it was what I had in mind. Cool that you were working on this!


upgrade of dependency to fix vulnerability

upgrading org.json:json to remove CVE-2023-5072 from all services

pls share testing details.
i.e. how we are sure that it will not cause any incompatibility issues in any services

have we verified locally that by changing this version, mentioned cve will be eliminated ?

answers for the above questions

tested locally by creating kork snapshot and used it in all services to make sure the build is successful and does not break the code.
Verified through dependency Injection chart for modules to ensure the required version is only downloaded and used


Grammatical Error in D3

There is a grammatical error in D3, right underneath of the Yuur typo. It says make sure the TA and I are added as a collaborator, but it should say make sure the TA and I are added as collaborators

+0.1 EC


demo containers

Have demo containers with all dependencies pre-installed so no local dependencies are needed.  This would also help with the Java 11/17 issues many learners had.

Not sure what the reporter of this issue specifically meant


Post PR #4559: add back .dev1 to version numbers.

@jonparrott I would like to squeeze in a change to api_core/CHANGELOG.md to this PR as well with the updates based on the (currently not mentioned in notes) PRs #4339, #4336, #4367, #4399.

@jonparrott Ever seen a flaky failure for api_core like just happened?

Due to #4566 I'll hold off on merging this / will update Pub / Sub to 0.29.5.dev1.

Merging without CI since changes are only in 2 MD files and 2 setup.py files. (The api_core changes take over an hour to run, so it's prohibitive.)


Comments: Configure AWS Amplify

Link to chapter - https://serverless-stack.com/chapters/configure-aws-amplify.html

fyi (in case anyone else had this problem):  I was not able to upload a file to S3 due to permission error. Even though there was no difference in the policy, creating a new Cognito Identity Pool and it worked for me.

Small typo: "The name: "notes" is basically telling Amplify that we want to name our API. Amplify allows you to add multiple APIs that you your app is going to work with. In our case our entire backend is just one single API."

@viccooper142 Thanks. Fixed.

My question is behind the relationship between user pool and identity pool when performing signup and signin. Since signup and signin are primarily handled only my the Cognito User Pool, it confuses me why IdentityPoolId needs to be specified when configuring AWS Amplify? SignUp operation especially just creates user in the User Pool. What's identity pool's involvement here?

Does anyone have any recommendations for configuring multiple environments (dev and prod) with Amplify.configure? I've looked into the node package "configure", but that seems to be geared towards running a node server not a static website.

@kerly We cover the general idea based on the Create React App docs here - https://serverless-stack.com/chapters/environments-in-create-react-app.html

This issue was moved to https://discourse.serverless-stack.com/t/comments-configure-aws-amplify/20

This issue was moved to https://discourse.serverless-stack.com/t/comments-configure-aws-amplify/151

Getting Following exception whenever I am adding the below line
import Amplify from "aws-amplify";
Error: Cannot use undefined "Boolean" from another module or realm.

Ensure that there is only one instance of "graphql" in the node_modules
directory. If different versions of "graphql" are the dependencies of other
relied on modules, use "resolutions" to ensure only one version is installed.

https://yarnpkg.com/en/docs/selective-version-resolutions

Duplicate "graphql" modules cannot be used at the same time since different
versions may have different capabilities and behavior. The data from one
version used in the function from another could produce confusing and
spurious results.

Resolved : works on every browser except Internet Explorer where the following error occurs.
Refrence Link : https://stackoverflow.com/questions/50421838/ie-graphql-script5022-cannot-use-undefined-boolean-from-another-module-or

@vivekmittal24 So the issue happens when you load the page in IE?

Hi.. I am following your tutorial, Many thanks for it.
I am Getting Following exception whenever I am adding the below line
import Amplify from "aws-amplify";
Failed to compile.

Error in<EMAIL_ADDRESS>Module parse failed<EMAIL_ADDRESS>Unexpected token (13:20)
You may need an appropriate loader to handle this file type.
SyntaxError: Unexpected token (13:20)
<EMAIL_ADDRESS>4:21-53

Error in<EMAIL_ADDRESS>Module parse failed<EMAIL_ADDRESS>Unexpected token (22:28)
You may need an appropriate loader to handle this file type.
SyntaxError: Unexpected token (22:28)
<EMAIL_ADDRESS>5:21-57

Error in<EMAIL_ADDRESS>Module parse failed<EMAIL_ADDRESS>Unexpected token (4:6)
You may need an appropriate loader to handle this file type.
SyntaxError: Unexpected token (4:6)
<EMAIL_ADDRESS>3:22-57

Error in<EMAIL_ADDRESS>Module parse failed<EMAIL_ADDRESS>Unexpected token (5:6)
You may need an appropriate loader to handle this file type.
SyntaxError: Unexpected token (5:6)
<EMAIL_ADDRESS>3:26-65

Error in<EMAIL_ADDRESS>Module parse failed<EMAIL_ADDRESS>Unexpected token (5:6)
You may need an appropriate loader to handle this file type.
SyntaxError: Unexpected token (5:6)
<EMAIL_ADDRESS>3:26-65

Error in<EMAIL_ADDRESS>Module parse failed<EMAIL_ADDRESS>Unexpected token (4:6)
You may need an appropriate loader to handle this file type.
SyntaxError: Unexpected token (4:6)
<EMAIL_ADDRESS>3:22-57

Error in<EMAIL_ADDRESS>Module parse failed<EMAIL_ADDRESS>Unexpected token (4:6)
You may need an appropriate loader to handle this file type.
SyntaxError: Unexpected token (4:6)
<EMAIL_ADDRESS>3:22-57

Error in<EMAIL_ADDRESS>Module parse failed<EMAIL_ADDRESS>Unexpected token (5:6)
You may need an appropriate loader to handle this file type.
SyntaxError: Unexpected token (5:6)
<EMAIL_ADDRESS>3:26-65

Error in<EMAIL_ADDRESS>Module parse failed<EMAIL_ADDRESS>Unexpected token (7:6)
You may need an appropriate loader to handle this file type.
SyntaxError: Unexpected token (7:6)
<EMAIL_ADDRESS>3:22-57

Error in<EMAIL_ADDRESS>Module parse failed<EMAIL_ADDRESS>Unexpected token (36:10)
You may need an appropriate loader to handle this file type.
SyntaxError: Unexpected token (36:10)
<EMAIL_ADDRESS>5:21-45

Error in<EMAIL_ADDRESS>Module parse failed<EMAIL_ADDRESS>Unexpected token (5:6)
You may need an appropriate loader to handle this file type.
SyntaxError: Unexpected token (5:6)
<EMAIL_ADDRESS>3:22-57

Error in<EMAIL_ADDRESS>Module parse failed<EMAIL_ADDRESS>Unexpected token (5:6)
You may need an appropriate loader to handle this file type.
SyntaxError: Unexpected token (5:6)
<EMAIL_ADDRESS>3:26-65

Error in<EMAIL_ADDRESS>Module parse failed<EMAIL_ADDRESS>Unexpected token (5:6)
You may need an appropriate loader to handle this file type.
SyntaxError: Unexpected token (5:6)
<EMAIL_ADDRESS>3:22-57

Error in<EMAIL_ADDRESS>Module parse failed<EMAIL_ADDRESS>Unexpected token (5:6)
You may need an appropriate loader to handle this file type.
SyntaxError: Unexpected token (5:6)
<EMAIL_ADDRESS>3:22-57

Error in<EMAIL_ADDRESS>Module parse failed<EMAIL_ADDRESS>Unexpected token (5:6)
You may need an appropriate loader to handle this file type.
SyntaxError: Unexpected token (5:6)
<EMAIL_ADDRESS>3:22-57

Error in<EMAIL_ADDRESS>Module not found: 'child_process' in /home/ubuntu/myapp-client/node_modules/@aws-sdk/credential-provider-process/build

<EMAIL_ADDRESS>5:22-46

Error in<EMAIL_ADDRESS>Module not found: 'http2' in /home/ubuntu/myapp-client/node_modules/@aws-sdk/node-http-handler/build

<EMAIL_ADDRESS>3:16-32

Error in<EMAIL_ADDRESS>Module parse failed<EMAIL_ADDRESS>Unexpected token (39:18)
You may need an appropriate loader to handle this file type.
SyntaxError: Unexpected token (39:18)
<EMAIL_ADDRESS>3:32-66
```

Please post this over on the forums — https://discourse.serverless-stack.com


json/yaml ser/des functions in YAQL

Only json(str) which does "json string -> ojbect" is available for now.
Mistral supports several more functions:
https://github.com/StackStorm/st2mistral/blob/master/st2mistral/functions/data.py
I think it is good to have at least following:

json string to object: already implemented as json()
yaml string to object
object to json string
object to yaml string

Turns out that those are available in st2. They came from st2commom instead. You can check all available functions at here:
https://github.com/StackStorm/st2/blob/master/contrib/runners/orquesta_runner/setup.py


Removing redundant entries

Pull Request Test Coverage Report for Build 103

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

Totals

Change from base Build 102:
0.0%

Covered Lines:
9

Relevant Lines:
41

💛  - Coveralls


{Packaging} Bump cryptography to 41.0.1 and pyOpenSSL to 23.2.0

Description
Rework of https://github.com/Azure/azure-cli/pull/26596
As explained in https://github.com/Azure/azure-cli/pull/26596#issuecomment-1590590291, only bumping cryptography is not enough. pyOpenSSL should be bumped at the same time.

Packaging

Discussion: Should we silence the warning raised by cryptography on 32-bit Python (https://github.com/Azure/azure-cli/pull/25690)?
I did consider disabling the warning by calling warnings.filterwarnings or warnings.simplefilter:
import platform

if platform.system() == 'Windows' and platform.architecture()[0].startswith('32'):
    import warnings
    warnings.simplefilter("ignore", category=UserWarning)

but I think it is good to keep that warning to encourage people to upgrade to 64-bit Azure CLI once https://github.com/Azure/azure-cli/pull/26640 has been released.

We have decided to keep the warning, as it is printed to stderr and this is not considered a breaking change. If your pipelines have failOnStderr set to true and you encounter failure due to the warning message
UserWarning: You are using cryptography on a 32-bit Python on a 64-bit Windows Operating System. Cryptography
will be significantly faster if you switch to using a 64-bit Python.

please set failOnStderr to false. More information can be found at #18372.