aws-exports.js not created by amplify push

Describe the bug
The following page states that aws-exports.js will be created by Amplify CLI when running amplify push command:
https://aws-amplify.github.io/docs/js/start?platform=react-native

How it Works: Rather than configuring each service through a constructor or constants file, Amplify supports configuration through a centralized file called aws-exports.js which defines all the regions and service endpoints to communicate. Whenever you run amplify push, this file is automatically created allowing you to focus on your application code. The Amplify CLI will place this file in the appropriate source directory configured with amplify init.

To Reproduce
Steps to reproduce the behavior:

Create a new Expo React Native project
Install Amplify CLI globally
Install Amplify and Amplify React Native packages into the project
Execute amplify init to configure the environment
Execute amplify configure to setup the AWS account, user credentials, and AWS CLI profile
Execute amplify push to create AWS objects
Execute amplify status observing that there are no more actions to take
Observe that aws-exports.js was not created in the project directory

Without this project, the application will not execute since all Amplify modules depend on this configuration being loaded at runtime.
Expected behavior
amplify push will create or update aws-exports.js when the command completes successfully
Desktop (please complete the following information):

OS: macOS High Sierra 10.13.6
Browser: Chrome
Version:

npm install -g @aws-amplify/cli

"aws-amplify": "^1.1.36",
"aws-amplify-react-native": "^2.1.16",

Smartphone (please complete the following information):

Device: iPhone Xs
OS: iOS 12.4

Sample code
The code from AWS Amplify readme:
import Amplify from 'aws-amplify';
import aws_exports from './aws-exports';

Amplify.configure(aws_exports);

@01binary Which version of the CLI are you using? During ampify init - what's the project type did you select - between javascript/android/iOS? Also could you please share your <project-root>/amplify/.config/project-config.json file?
I installed the latest version of the CLI with the following propmpts and it created an aws_exports.js file inside the src/ directory of my project.
f45c89966b0d:testexports kaustavg$ amplify init
Note: It is recommended to run this command from the root of your app directory
? Enter a name for the project testexports
? Enter a name for the environment dev
? Choose your default editor: Sublime Text
? Choose the type of app that you're building javascript
Please tell us about your project
? What javascript framework are you using none
? Source Directory Path:  src
? Distribution Directory Path: dist
? Build Command:  npm run-script build
? Start Command: npm run-script start
Using default provider  awscloudformation

For more information on AWS Profiles, see:
https://docs.aws.amazon.com/cli/latest/userguide/cli-multiple-profiles.html

? Do you want to use an AWS profile? Yes
? Please choose the profile you want to use default
⠴ Initializing project in the cloud...

CREATE_IN_PROGRESS DeploymentBucket               AWS::S3::Bucket            Tue Aug 13 2019 15:44:24 GMT-0700 (Pacific Daylight Time) Resource creation Initiated
CREATE_IN_PROGRESS UnauthRole                     AWS::IAM::Role             Tue Aug 13 2019 15:44:24 GMT-0700 (Pacific Daylight Time) Resource creation Initiated
CREATE_IN_PROGRESS AuthRole                       AWS::IAM::Role             Tue Aug 13 2019 15:44:24 GMT-0700 (Pacific Daylight Time) Resource creation Initiated
CREATE_IN_PROGRESS UnauthRole                     AWS::IAM::Role             Tue Aug 13 2019 15:44:23 GMT-0700 (Pacific Daylight Time)
CREATE_IN_PROGRESS DeploymentBucket               AWS::S3::Bucket            Tue Aug 13 2019 15:44:23 GMT-0700 (Pacific Daylight Time)
CREATE_IN_PROGRESS AuthRole                       AWS::IAM::Role             Tue Aug 13 2019 15:44:23 GMT-0700 (Pacific Daylight Time)
CREATE_IN_PROGRESS testexports-dev-20190813154419 AWS::CloudFormation::Stack Tue Aug 13 2019 15:44:20 GMT-0700 (Pacific Daylight Time) User Initiated
⠧ Initializing project in the cloud...

CREATE_COMPLETE UnauthRole AWS::IAM::Role Tue Aug 13 2019 15:44:38 GMT-0700 (Pacific Daylight Time)
CREATE_COMPLETE AuthRole   AWS::IAM::Role Tue Aug 13 2019 15:44:38 GMT-0700 (Pacific Daylight Time)
⠧ Initializing project in the cloud...

CREATE_COMPLETE DeploymentBucket AWS::S3::Bucket Tue Aug 13 2019 15:44:45 GMT-0700 (Pacific Daylight Time)
⠦ Initializing project in the cloud...

CREATE_COMPLETE testexports-dev-20190813154419 AWS::CloudFormation::Stack Tue Aug 13 2019 15:44:47 GMT-0700 (Pacific Daylight Time)
✔ Successfully created initial AWS cloud resources for deployments.
✔ Initialized provider successfully.
Initialized your environment successfully.

Your project has been successfully initialized and connected to the cloud!

Some next steps:
"amplify status" will show you what you've added already and if it's locally configured or deployed
"amplify <category> add" will allow you to add features like user login or a backend API
"amplify push" will build all your local backend resources and provision it in the cloud
"amplify publish" will build all your local backend and frontend resources (if you have hosting category added) and provision it in the cloud

Pro tip:
Try "amplify add api" to create a backend API and then "amplify publish" to deploy everything

f45c89966b0d:testexports kaustavg$ ls src/
aws-exports.js
f45c89966b0d:testexports kaustavg$ cat src/aws-exports.js
// WARNING: DO NOT EDIT. This file is automatically generated by AWS Amplify. It will be overwritten.

const awsmobile = {
    "aws_project_region": "us-east-1"
};

export default awsmobile;
f45c89966b0d:testexports kaustavg$

@01binary Please comment on this thread if you're still stuck on this issue.

Sorry to create a dead-on-arrival issue, but Amplify is impossible to get working for mobile development and I am giving up on it in that context.

I had the same issue, and I think I know what happened here. I am also trying to make a react-native app...for android.  TLDR; When building a react-native app, you need to tell Amplify that you're making a "javascript" app, not an "android" app.
If you say that you're building an "android" project when it asks "Choose the type of app that you're building", the next question ("Where is your Res directory?") has "app/src/main/res" as the default value. This builds a file called "awsconfiguration.json" in "app/src/main/res", which is NOT used by React-Native.
Instead, when it asks what type of app your are building, I needed to select "javascript". This then asks you which framework you are using, which will allow you to select "react-native" as one of the options. When amplify then asks for the source directory path (DIFFERENT QUESTION!), it defaults to "/", which is where we'd expect the program to build awsconfig.js.

My issue was when I do the "amplify init/push" I was in the directory above my app, so the src/aws-export.js is created outside my app.

Hi! Long time reader, first time commenter. This might be an obvious first check issue but I thought AWS was not generating an AWS-exports.js file as it wasn't coming up in my code editor (using ATOM), but it turns out it was definitely created in my app directory but because the aws-exports file is listed in the .gitIgnore file, it wasn't coming up in the code editor's project menu. I don't know if that helps...

HI everyone, I had a similar issue where I thought aws-exports.js wasn't generating since I was getting a fatal error but it turned out I was being amateur.
During (excerpts only included),
amplify init
Note: It is recommended to run this command from the root of your app directory
? Source Directory Path:  src

So it was being generated into my src file and not at the top directory in my app, oops! So modify the path to below,
import Amplify from 'aws-amplify';
import aws_exports from './src/aws-exports';
Amplify.configure(aws_exports);

@derekrsargent thanks for posting, that was my issues as well


tests: remove integration_tests folder

How to categorize this PR?

/kind cleanup
/area os
/os garden-linux
What this PR does / why we need it:
Since the whole testing franmework has been fully revamped by @gyptazy and @chrinorse and got subsequently adapted and integrated into GitHub actions, the stubs intended to execute the tests in the venerable Tekton pipeline are no longer required.
Release note:

tests: remove integration_tests folder

/ready


On Custom Finetuning :  RuntimeError: Input type (float) and bias type (c10::BFloat16) should be the same

Traceback (most recent call last):                                                                            | 0/8 [00:00<?, ?it/s]
File "/home/vitap/Desktop/Hotshot-XL/fine_tune.py", line 994, in
main()
File "/home/vitap/Desktop/Hotshot-XL/fine_tune.py", line 976, in main
process_batch(batch)
File "/home/vitap/Desktop/Hotshot-XL/fine_tune.py", line 922, in process_batch
run_validation(step=global_step, node_index=accelerator.process_index // 8)
File "/home/vitap/Desktop/Hotshot-XL/fine_tune.py", line 718, in run_validation
video = pipe(prompt,
File "/home/vitap/miniconda3/envs/hotshot/lib/python3.9/site-packages/torch/utils/_contextlib.py", line 115, in decorate_context
return func(*args, **kwargs)
File "/home/vitap/Desktop/Hotshot-XL/hotshot_xl/pipelines/hotshot_xl_pipeline.py", line 891, in call
video = self.decode_latents(latents)
File "/home/vitap/Desktop/Hotshot-XL/hotshot_xl/pipelines/hotshot_xl_pipeline.py", line 985, in decode_latents
video.append(self.vae.decode(
File "/home/vitap/miniconda3/envs/hotshot/lib/python3.9/site-packages/diffusers/utils/accelerate_utils.py", line 46, in wrapper
return method(self, *args, **kwargs)
File "/home/vitap/miniconda3/envs/hotshot/lib/python3.9/site-packages/diffusers/models/autoencoder_kl.py", line 288, in decode
decoded = self._decode(z).sample
File "/home/vitap/miniconda3/envs/hotshot/lib/python3.9/site-packages/diffusers/models/autoencoder_kl.py", line 274, in _decode
z = self.post_quant_conv(z)
File "/home/vitap/miniconda3/envs/hotshot/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1501, in _call_impl
return forward_call(*args, **kwargs)
File "/home/vitap/miniconda3/envs/hotshot/lib/python3.9/site-packages/torch/nn/modules/conv.py", line 463, in forward
return self._conv_forward(input, self.weight, self.bias)
File "/home/vitap/miniconda3/envs/hotshot/lib/python3.9/site-packages/torch/nn/modules/conv.py", line 459, in _conv_forward
return F.conv2d(input, weight, bias, self.stride,
RuntimeError: Input type (float) and bias type (c10::BFloat16) should be the same

Same promble. How to solve it?

I have the same problem as well

I fixed by changing the latents dtype to bfloat16 in the hotshot_xl_pipeline.py. Hope this helps everyone.

thanks , I do the same but in my hardware doesnt works for me


build: GA Release

release 1.0.0 on main branch

Are the failed cases code issue or test issue?

Are the failed cases code issue or test issue?

@formulahendry this is the e2e test failure on ubuntu, i'm considering to revert the ubuntu test on dev


regression in 1.8.0, relation "integer" does not exist

The following query to enumerate IP addresses compiles correctly on 1.7.0, but fails on 1.8.0 and tip:
-- name: Test180Regression :many
SELECT (@gw_address::inet) + i
FROM generate_series(0, @end_series::int) AS i
LIMIT 1;

db/query/ips.sql:1:1: relation "integer" does not exist

Duplicate of #1004


Use SSL options for authentication request

This change ensures that the SSL options passed to the request are also used for the authentication request (if it is needed) in addition to the actual resource request. This allows enforcement of an SSL version (eg. TLS v1.2) for increased security.
See also: #238

Looks super reasonable to me on the surface. I'll review properly tomorrow

thanks!
On Mon, 24 Apr 2017 at 21:49, Jaap van der Plas<EMAIL_ADDRESS>wrote:

This change ensures that the SSL options passed to the request are also
used for the authentication request (if it is needed) in addition to the
actual resource request. This allows enforcement of an SSL version (eg. TLS
v1.2) for increased security.
See also: #238 https://github.com/ejholmes/restforce/issues/238
You can view, comment on, or merge this pull request online at:
https://github.com/ejholmes/restforce/pull/299
Commit Summary

use SSL options for authentication request

File Changes

M lib/restforce/middleware/authentication.rb
https://github.com/ejholmes/restforce/pull/299/files#diff-0 (3)
M spec/unit/middleware/authentication_spec.rb
https://github.com/ejholmes/restforce/pull/299/files#diff-1 (7)

Patch Links:

https://github.com/ejholmes/restforce/pull/299.patch
https://github.com/ejholmes/restforce/pull/299.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ejholmes/restforce/pull/299, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHFps4FeML_ZpaOAimqWyEmq31ZcuTUks5rzQrDgaJpZM4NGsXW
.

Thanks for the fast merge and release! 👍

Hey @jvdp I'm curious what's the proper way to send the version, as a symbol :TLSv1_2 as a string 'TLSv1.1' or it does not matter?. Thanks.

@jcabasc I'm using config.ssl = { version: :TLSv1_2 }, not sure if it matters.


Update 1.9 Docker install guide for CentOS with Docker 1.13

Description
https://jira.mesosphere.com/browse/DOCS-1762
Urgency

[x] Blocker
[ ] High
[ ] Medium

Requirements

Test all commands and procedures.
Build content locally and test for formatting/links.
Add redirects to dcos-website/redirect-files.
Change all affected versions (e.g. 1.7, 1.8, and 1.9).
See the contribution guidelines.

Tested all commands against the official CentOS 7 AMI.


Error in hpo_bring_your_own_keras_container.ipynb when Pushing the container to ECR

Error message:
An error occurred (RepositoryAlreadyExistsException) when calling the CreateRepository operation: The repository with name 'test' already exists in the registry with id '109225375568'
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
WARNING! Your password will be stored unencrypted in /home/ec2-user/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store
Login Succeeded
The push refers to repository [109225375568.dkr.ecr.us-east-2.amazonaws.com/test]
67e8702c: Preparing
fb12a0f8: Preparing
cd656dad: Preparing
50f4ad51: Preparing
cbd51d4c: Preparing
2dba4224: Preparing
928d62e9: Preparing
5de15f9a: Preparing
d797a4b6: Preparing
590089c4: Preparing
2280c8c4: Preparing
2dba4224: Waiting g
d0000622: Preparing
5de15f9a: Waiting g
denied: User: arn:aws:sts::109225375568:assumed-role/AmazonSageMaker-ExecutionRole-20200213T151637/SageMaker is not authorized to perform: ecr:InitiateLayerUpload on resource: arn:aws:ecr:us-east-2:109225375568:repository/test
Tried using a new notebook and branch and changing the name of the algorithm that is the "test: part of the repo name. But this did not work.

Duplicate of https://github.com/awslabs/amazon-sagemaker-examples/issues/1443


[Bug] flink-cdc-3.0 Unable to apply SchemaChangeEvent for table "xxx" without existing schema

Search before asking

[X] I searched in the issues and found nothing similar.

Flink version
1.18
Flink CDC version
3.0
Database and its version
source: mysql 5.7.40
sink: starrocks 3.2.2
Minimal reproduce step

create yaml
source:
table: app_db.ord.*
...
sync table begin with ord to starrocks ,everything is ok
change source mysql table ,alter table app_db.ttt add column .... (not capture this table)
schema change is be send to starrocks, then error occured.

some log:
2024-01-19 17:53:14,206 INFO  com.ververica.cdc.runtime.operators.schema.coordinator.SchemaRegistryRequestHandler [] - Received schema change event request from table app_db.ttt. Start to buffer requests for others.
...
Caused by: java.util.concurrent.ExecutionException: java.lang.IllegalArgumentException: Unable to apply SchemaChangeEvent for table "app_db.ttt" without existing schema
at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:395) ~[?:?]
at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1999) ~[?:?]
at com.ververica.cdc.runtime.operators.schema.SchemaOperator.sendRequestToCoordinator(SchemaOperator.java:123) ~[?:?]
What did you expect to see?
should not capture table ttt
What did you see instead?
ttt table schema change is send to starrocks
Anything else?
No response
Are you willing to submit a PR?

[ ] I'm willing to submit a PR!

I have the same issue

fixed by https://github.com/ververica/flink-cdc-connectors/pull/2986.


tests issue about leading \0

I met a leading \0 string when running tests, is this normal?
There was 1 failure:

1) Tuupola\Base62\Base62Test::testShouldEncodeAndDecodeRandomBytes
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-Binary String: 0x00486eea2de87439fc081b892616a3b0f1f098df86e2cdd23e7d21f5f046a30a1a6662fff6c3c017b1d4853a1fdd7dc00975016d9c2801b9df659fadc6abe1109b1e1f3960367603e75bb9ddf9d8097af5948f74df585d05bbee61aff992f3d35577e31aafce7d4342d3a68da0d5ca8d46bde2f7e7f555cf6a1938c4f52bdd43
+Binary String: 0x486eea2de87439fc081b892616a3b0f1f098df86e2cdd23e7d21f5f046a30a1a6662fff6c3c017b1d4853a1fdd7dc00975016d9c2801b9df659fadc6abe1109b1e1f3960367603e75bb9ddf9d8097af5948f74df585d05bbee61aff992f3d35577e31aafce7d4342d3a68da0d5ca8d46bde2f7e7f555cf6a1938c4f52bdd43

/private/tmp/base62/tests/Base62Test.php:41

FAILURES!

base64_encode can handle this:
>>> $data = hex2bin("00313233");
=> "\0123"
>>> base64_encode($data)
=> "ADEyMw=="
>>> base64_decode("ADEyMw==")
=> "\0123"
>>> Tuupola\Base62Proxy::encode($data)
=> "DWjr"
>>> Tuupola\Base62Proxy::decode("DWjr")
=> "123"

This seems to be default gmp behaviour. Not sure why it does so though.
print $encoded = gmp_strval(gmp_init("0x00deadbeef", 16), 62);
print $decoded = gmp_strval(gmp_init($encoded, 62), 16);
/*
44pZgF
deadbeef
*/

PhpEncoder can not handle either.

All encoders have the same output.

Then just forget it 😆

I keep this open for a while to think about it. For numerical conversions losing leading zeros is ok. For binary data loosing leading 0x00 is kind of not ok.

Yes, that is why I opened this issue.
I have no idea how to fix it, and I have thought about it. If we clearly know the length of the original data, such as UUID, we can pad the leading, so maybe we can save the length in the encoded data. But we have to give a big enough room for the length, this will cause the encoded data too long.

@tuupola I'd like to tell you I released a new package that ships with your Base62 package yesterday, thanks for your great job! 👍
https://github.com/ElfSundae/laravel-hashid

Looks good!

I keep this open for a while to think about it. For numerical conversions losing leading zeros is ok. For binary data losing leading 0x00 is kind of not ok because that is something one would not expect.

FWIW I see it the same way, because decoding an encoded payload should always yield the exact original data. Hence losing leading zeroes on integers is fine, but on strings it is not.

Fixed in (0.11.0)[https://packagist.org/packages/tuupola/base62#0.11.0];


fix: improve connection handling

Description
Progress towards better connection handling. Until #13 subscriptions were kept around for the duration of the run even when no longer needed. As a consequence, a notable chunk of code never ran that affects ending and accepting connections, with quick re-connection being a pain point. This PR tries to improve connection handling, but I don't think this is the end of the issues.
Changes are:

we keep around the sender for the alternative connection. The alternative connection is that one with a different origin (whether we are or not the dialer). This seems to be original intent of keeping both connections, but dropping the sender to the alternative one effectively ends it because the connection loops has no longer a channel to read messages from for sending. This is bad because the that also means that if there were sent messages in that connection those might be never read.
We do not close the connection when the proto state machine indicates to disconnect the peer. The effect of doing this is that all the (per-topic) Disconnect messages were never sent to the peer. This is what made the other node not realize we were gone and instead rely on timeouts.
We close the connection only after all the stream data for sending messages has been ackd by the remote. This is not ideal, there isn't one single Disconnect message, but this leaves us in a far better place than before.
It's easy to miss but this change is a relatively important: Disconnection was being handled twice: Once when the proto state machine indicates the peer must be disconnected. Here we dropped the peer data and closed the connection before, and once again when the connection loop indicates it's ended, which again removes the peer and informs the state machine of the peer gone. This is problematic because between the state machine deciding the peer must be disconnected and the connection loop ending, messages can be queued, like Join, which were before the lost to the abyss

Breaking Changes
n/a
Notes & open questions
I believe this is better than before. I also believe there are more related issues lurking.
The connection loop currently ignores errors on the receiving side. This is "justified" by arguing errors on the receiving side should appear on the sender side as well. This is weak argument but at this point I'm unsure what to do with it. Incremental improvement I guess?
Change checklist

[x] Self-review.
[x] Documentation updates following the style guide, if relevant.
[x] Tests if relevant.
[x] All breaking changes documented.

tested using deltachat's full workflow in

https://github.com/deltachat/deltachat-core-rust/pull/6334


[Code release] When will the code be released?

Hi, thanks for nice work. When will the final code be uploaded in this github? Thank you.

Sorry for the delay. Just uploaded test code. Training code will be uploaded after completing the next work.


⚠ Forum - Ascentia has degraded performance

In 5c1dcee, Forum - Ascentia (https://community.ascentia.fr/) experienced degraded performance:

HTTP code: 200
Response time: 1751 ms

Resolved: Forum - Ascentia performance has improved in 6d68370 after 12 hours, 2 minutes.


V5.x - merge v5.7.3 and fix array_key_exists in getPerPage method

Merge v5.7.3 into 5.x branch and fix array_key_exists - this function has only 2 parameters, not 3.

I just change tag v5.7.3 position to the new commit with this fix (with -f param) ...

Actually, your MR removes a bit much of the original code. I fixed in in the v5.x branch. But thanks!

Actually, your MR removes a bit much of the original code. I fixed in in the v5.x branch. But thanks!

Yes I merged v5.7.3 before my changes ... it shouldn't be there?

There is still an issue - see https://github.com/contributte/datagrid/pull/858


Pin Dependencies

This Pull Request renovates the package group "Pin Dependencies".

unicode-10.0.0: from ^0.7.4 to 0.7.5
regenerator-runtime: from ^0.11.1 to 0.11.1
core-js: from ^2.5.3 to 2.5.3
default-require-extensions: from ^2.0.0 to 2.0.0
request: from ^2.83.0 to 2.83.0
electron-to-chromium: from ^1.3.27 to 1.3.34
mock-require: from ^2.0.2 to 2.0.2
v8flags: from ^3.0.0 to 3.0.2
output-file-sync: from ^2.0.0 to 2.0.1
lodash: from ^4.2.0 to 4.17.5
fs-readdir-recursive: from ^1.0.0 to 1.1.0
commander: from ^2.8.1 to 2.14.1
strip-ansi: from ^4.0.0 to 4.0.0
chalk: from ^2.0.0 to 2.3.2
source-map: from ^0.5.0 to 0.5.7
slash: from ^1.0.0 to 1.0.0
glob: from ^7.0.0 to 7.1.2
convert-source-map: from ^1.1.0 to 1.5.1
webpack-stream: from ^4.0.0 to 4.0.0
webpack-dependency-suite: from ^2.4.4 to 2.4.5
webpack: from ^3.4.1 to 3.10.0
vinyl-source-stream: from ^2.0.0 to 2.0.0
vinyl-buffer: from ^1.0.1 to 1.0.1
util.promisify: from ^1.0.0 to 1.0.0
uglify-js: from ^2.4.16 to 2.8.29
through2: from ^2.0.0 to 2.0.3
semver: from ^5.0.0 to 5.5.0
rollup-stream: from ^1.24.1 to 1.24.1
rollup-plugin-node-resolve: from ^3.0.2 to 3.0.2
rollup-plugin-babel: from ^4.0.0-beta.0 to 4.0.0-beta.0
rimraf: from ^2.4.3 to 2.6.2
pump: from ^1.0.2 to 1.0.3
nyc: from ^11.0.3 to 11.4.1
mocha: from ^3.0.0 to 3.5.3
merge-stream: from ^1.0.1 to 1.0.1
lint-staged: from ^6.0.1 to 6.0.1
lerna-changelog: from ^0.5.0 to 0.5.0
husky: from ^0.14.3 to 0.14.3
gulp-watch: from ^4.3.5 to 4.3.11
gulp-util: from ^3.0.7 to 3.0.8
gulp-uglify: from ^3.0.0 to 3.0.0
gulp-rename: from ^1.2.2 to 1.2.2
gulp-plumber: from ^1.0.1 to 1.2.0
gulp-newer: from ^1.0.0 to 1.4.0
gulp-filter: from ^5.1.0 to 5.1.0
gulp-babel: from ^8.0.0-beta.0 to 8.0.0-beta.0
gulp: from ^3.9.0 to 3.9.1
graceful-fs: from ^4.1.11 to 4.1.11
flow-bin: from ^0.59.0 to 0.59.0
eslint-plugin-prettier: from ^2.5.0 to 2.5.0
eslint-plugin-flowtype: from ^2.20.0 to 2.41.0
eslint-config-babel: from ^7.0.2 to 7.0.2
eslint: from ^4.5.0 to 4.15.0
derequire: from ^2.0.2 to 2.0.6
chai: from ^4.1.0 to 4.1.2
bundle-collapser: from ^1.2.1 to 1.3.0
browserify: from ^13.1.1 to 13.3.0
babel-plugin-istanbul: from ^4.1.4 to 4.1.5
babel-eslint: from ^8.0.1 to 8.2.1
async: from ^1.5.0 to 1.5.2

Important: Renovate will wait until you have merged this Pin request before creating PRs for any upgrades. If you do not wish to pin anything, please update your config accordingly instead of leaving this PR open.

This PR has been generated by Renovate Bot.

Lock file problem
Renovate failed when attempting to generate a lock file. This is usually happens when you have private modules but have not added configuration for private module support. It is strongly recommended that you do not merge this PR as-is.
Renovate will not retry generating a lockfile for this PR unless either (a) the package.json in this branch needs updating, or (b) you manually delete this PR so that it can be regenerated.
The output from stderr is included below:
yarn.lock
warning<EMAIL_ADDRESS>gulp-util is deprecated - replace it, following the guidelines at https://medium.com/gulpjs/gulp-util-ca3b1f9f9ac5
Process stalled
Active handles:
  - Socket
  - Socket
  - Socket
  - TLSSocket
  - TLSSocket
  - TLSSocket
  - TLSSocket
  - TLSSocket
  - TLSSocket
  - TLSSocket


Sample app response is slow like 10-20s sometimes

Describe the bug
Sample app response is slow like 10-20s sometimes. Even though I've used paid account with openAI, probably too many round trip.
  Request finished HTTP/2 POST https://localhost:40443/skills/ChatSkill/functions/Chat/invoke application/json 1132 - 200 - application/json;+charset=utf-8<PHONE_NUMBER>ms

To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: [e.g. Windows]
IDE: [e.g. Visual Studio, VS Code]
NuGet Package Version [e.g. 0.1.0]

Additional context
Add any other context about the problem here.

It looks like you're using the Copilot Chat sample - for the moment, to speed things up you can edit appsettings.json and set Planner:Enabled to false. While will disable plugins and some other interesting features, you will get a faster response.
We are continuing to explore strategies to improve the response and will likely add chat streaming in to copilot chat in the near future (#829 added streaming support to SK)

But with planner disabled, could we still invoke custom skill? Would we be able to select one skill from many? Looks like no?

We recently removed the planner:enabled setting and it now automatically disables if the user on the frontend has not enabled any plugins. https://github.com/microsoft/semantic-kernel/pull/1151

The lag in chat responses has to do with the chat app running 1-2 round trips with the AI (3 if a plugin/planner is enabled). We also use the AI /embeddings endpoints to create long-term memories which adds at least one more round trip. After the /Build conference we are taking a look at how we might be able to bring this response time down through parallelization and a different memories architecture.


Speeding up Hessian computation

Hello again. I have been happily using autograd in the pycalphad library for several months, and it has been working very well. I am at the point now where I am concerning myself with performance. Autograd still beats the competition for my use case, but I think there's room for improvement. By profiling, calls to the Hessian function constructed by autograd are about 60% of pycalphad's total execution time during a typical calculation.
I am interested to know if perhaps we can take advantage of symmetry to bring this down a bit. Here is a snippet of my code:
import autograd.numpy as anp
from autograd import elementwise_grad, jacobian
from sympy import lambdify
from pycalphad.core.utils import NumPyPrinter
from itertools import chain

def elementwise_hess(fun, argnum=0):
    """
    From https://github.com/HIPS/autograd/issues/60
    """
    def sum_latter_dims(x):
        return anp.sum(x.reshape(x.shape[0], -1), 1)

    def sum_grad_output(*args, **kwargs):
        return sum_latter_dims(elementwise_grad(fun)(*args, **kwargs))
    return jacobian(sum_grad_output, argnum)

def build_functions(sympy_graph, variables):
    logical_np = [{'And': anp.logical_and, 'Or': anp.logical_or}, anp]
    obj = lambdify(tuple(variables), sympy_graph, dummify=True,
                   modules=logical_np, printer=NumPyPrinter)

    def argwrapper(args):
        return obj(*args)

    def grad_func(*args):
        inp = anp.array(anp.broadcast_arrays(*args))
        result = anp.atleast_2d(elementwise_grad(argwrapper)(inp))
        # Put 'gradient' axis at end
        axes = list(range(len(result.shape)))
        result = result.transpose(*chain(axes[1:], [axes[0]]))
        return result

    def hess_func(*args):
        result = anp.atleast_3d(elementwise_hess(argwrapper)(anp.array(anp.broadcast_arrays(*args))))
        # Put 'hessian' axes at end
        axes = list(range(len(result.shape)))
        result = result.transpose(*chain(axes[2:], axes[0:2]))
        return result

    return obj, grad_func, hess_func

It looks to me like elementwise_hess is computing the entire Hessian. I was wondering if there were any suggestions to change the computation to only compute the  upper or lower triangular portion. I peaked at jacobian but I wasn't able to make much sense of it.

Hey Richard. I think I delayed responding to this in part because I don't have any ideas for how to help, other than speeding up autograd in general.
I don't think elementwise_hess is doing much unnecessary work. It might be possible to exploit symmetry as you suggest but I'm skeptical that would provide much of a speedup in most cases because it would only save a factor of 2 inside operations that are already vectorized and it wouldn't reduce the Python or autograd overhead at all.
Depending on the dimensions involved, it's possible that forward mode differentiation would compute the Jacobian faster. As you know, computing the Jacobian of a function f: R^n -> R^m is generally faster in reverse mode when m > n, and faster in forward mode when n > m (though forward mode might have a 2x advantage since it only makes one pass). Do you know the typical shape of the Jacobian being calculated there?
However, I think the big win would be a compilation strategy like in #47. If so, it might be better to track any progress in that issue.

Hi Matt,
I appreciate the response. For my use case the objective function n is roughly 10 and m is 1, but the Hessians are stacked in a multi-dimensional grid of thousands of points, so a typical Hessian array for a whole system might be (100, 100, 10, 10). I agree with you that the compilation strategy is probably best, because the real cause of the slowness (I think) is excessive temporary object creation starving the CPU -- like driving kids on a bus to school, one student at a time. If we could give the bus driver the whole passenger manifest ahead of time, the route to school could be optimized.

The strategy I'm pursuing now is simply to try to call hess() less by keeping track of which subsystems have converged, i.e., let converged be a boolean array of shape (100, 100) and let points be an input array of shape (100, 100, 10). Then you can do something like
hessian[np.nonzero(~converged) + np.index_exp[:, :]] = hess(*points[np.nonzero(~converged) + np.index_exp[:]])

and just update converged on every iteration according to some criteria. I haven't tested it yet but I expect I'll see a nice performance increase since the minimizer right now runs in lockstep -- i.e., if even one of the 100 * 100 subsystems hasn't converged, it recomputes the Hessian of all subsystems. It made prototyping easy but it definitely hurts performance.

If you make a runnable example we might be able to look for any possible speedups or vectorizations with the current elementwise_hess computation, though I can't say when we'll have a chance to look at it.


Installation: Click INITIALIZE. Half-way through list of boards I own, crash.

What kind of issue is this?

[ ] Question. This issue tracker is not the place for questions. If you want to ask how to do
something, or to understand why something isn't working the way you expect it to, use
our Community Forums https://community.platformio.org

[ ] Feature Request. Start by telling us what problem you’re trying to solve. Often a solution
already exists! Don’t send pull requests to implement new features without first getting our
support. Sometimes we leave features out on purpose to keep the project small.

[ ] PlatformIO IDE. All issues related to PlatformIO IDE should be reported to appropriate repository
https://github.com/platformio/platformio-atom-ide/issues

[x] Bug report. If you’ve found a bug, please provide information below.

You can erase any parts of this template not applicable to your Issue.

Configuration
Operating system:
Windows 7 64 bit
PlatformIO Version (platformio --version):
1.2.2, 2.9.1
Description of problem
New/first installation. Selected boards I own (about 10 different).Clicked INITIALIZE.
After several successes, This error:
PlatformIO: Failed to initialize PlatformIO project!
Error: The package 'toolchain-gccarmlinuxgnueabi' is not available for your system 'windows_amd64'
One of the boards led to the mistaken attempt to use the LInux form of GCC.
Could be ESP8266, could be Teensy ARM Cortex, don't know.
Steps to Reproduce
1.New install. Choose boards including ESP8266, Teensy 3.x boards, STM32F boards (3)
2. Choosing Raspberry Pi 2 or Raspberry Pi Zero causes the error reported in this issue.
3.
Actual Results
PlatformIO: Failed to initialize PlatformIO project!
Error: The package 'toolchain-gccarmlinuxgnueabi' is not available for your system 'windows_amd64'
Expected Results
Successful INITIALIZATION
If problems with PlatformIO Build System:
The content of platformio.ini:
Insert here...

Source file to reproduce issue:
Insert here...

Additional info

Choosing Raspberry Pi 2 or Raspberry Pi Zero causes the error reported in this usse.

Duplicate of https://github.com/platformio/platformio/issues/578
P.S: We don't have currently toolchain for cross compilation to RaspberryPi. Please use PlatformIO directly on RPi. PlatformIO CLI works very well on RPi.
Dorry for the inconveniences.


Move coreg.BiasCorr and coreg.Deramp to biascorr.py?

To better fit the names of the script files, these may fit better in biascorr.py.
I strongly suggest that they still inherit from the Coreg class, however, to be fully compatible with each other. I suggest the same for e.g. biascorr.AlongTrack().

Fixed by #158


🐛 [firestore-send-email] delete email documents on TTL expire

[READ] Step 1: Are you in the right place?
Issues filed here should be about bugs for a specific extension in this repository.
If you have a general question, need help debugging, or fall into some
other category use one of these other channels:

For general technical questions, post a question on StackOverflow
with the firebase tag.
For general Firebase discussion, use the firebase-talk
google group.
To file a bug against the Firebase Extensions platform, or for an issue affecting multiple extensions, please reach out to
Firebase support directly.

[REQUIRED] Step 2: Describe your configuration

Extension name: firestore-send-email
Extension version: 0.1.27
Configuration values (redact info where appropriate):

Cloud Functions location: us-central1
SMTP connection URI: redacted
SMTP password (Optional): redacted
Email documents collection: mail
Default FROM address: redacted
Firestore TTL type: day
Firestore TTL value: 5
remaining optional parameters are not set

[REQUIRED] Step 3: Describe the problem
Steps to reproduce:

Configure the plugin as described in the documentation, also set TTL type to day and TTL value to 5.
Send some emails with the plugin.
Note, that the emails are sent and received by the recipients as expected.
Wait until the specified TTL is elapsed (and some weeks more, just to be sure)

Expected result
The documents in the configured collection are expected to be deleted automatically.
Actual result
The documents are never deleted.
Please note, that it is not even possible to manually set up a TTL policy, because expireAt field is at 2nd level in the document created by the plugin, however, only 1st level fields can be configure as timestamp field when creating a TTL policy (see https://console.cloud.google.com/firestore/databases/-default-/ttl)
Example document:

I was wondering if it's possible to create a TTL Policy for a 2nd level field by specifying the timestamp field with dot notation, such as "delivery.expireAt". However, if setting the TTL manually is required, I believe it would be beneficial to include this information in the documentation. Unfortunately, I could not find any related instructions. Could you please clarify this?

its not much help but this works for us. using delivery.expireAt. extension 0.1.30

Indeed, a TTL policy with delivery.expireAt is working.
The documentation might be a bit more descriptive in this subject, it wasn't even clear for me that I have to create a TTL policy because it is not done automagically.

Documents updated explaining how to add the TTL policy properly. Apologies for the lack of information before. New documents will be merged shortly.


Create AAC tracks for multiple languages

I know the default settings will create an AAC track from the default language track, but is there a way to create a second AAC track for a secondary language track?
In other words
Source File
Track 1: AC-3 5.1 eng
Track 2: AC-3 5.1 spa
Transcode
Track 1: AC-3 5.1 eng
Track 2: AAC stereo eng
Track 3: AC-3 5.1 spa
Track 4: AAC stereo spa

@dashrealfar Yes, it's easy. To add the Spanish language audio tracks that way, use these options:
--add-audio spa --audio-width all=double

This is, BTW, all explained in the --help output.
Does that answer your question?

Yes, thank you, perfectly explained.
And apologies, I must've mis-read that part of the -help

@dashrealfar No problem! I'll close this now.


Save to the cloud

So far so good but ideally I would be able to create and save a site to Google Drive so that I can work on it from anywhere and on any device.

Like this?
https://ccbb5ebf7f4598224f50f0cce011b3fe4d8801b1.googledrive.com/host/0B1Duq5h3_Z-kRUdSVWxHTmcyam8/test/
I found the id of the folder and added it
https://googledrive.com/host/0B1Duq5h3_Z-kRUdSVWxHTmcyam8
then added the folder /test to the URL it gave me...
(as you see I have some more test folder you may try out ...)
but the URL is ... terrible ;-)


187091498 dataflow wait 2

This adds a set of "wait" functions to the existing "hold" node, as specified in PT-187091498

adds waitDuration to control node model
adds a wait duration input to control node
hide and show input based on function choice
if a wait time above 0 is entered ( and if the on signal is arriving at a node with an inactive gate), then the timer is set to the duration in the input
until timer expires, the gate will remain active, no matter what value arrives at switch

In draft until:

[x] adjust existing cypress tests
[x] address bug where disconnecting switch results in breakage
[x] remove animation during wait
[x] change ms in input to be s, allowing decimals

@bacalj after you update this to address the requested UI changes, please re-request my review so I know I need to look at it again.
I'd guess you don't need to re-request @johnTcrawford's review. You'll probably have to change the cypress tests, but I'd assume not in a way that is worth re-reviewing.

@scytacki can you have another look at this?
@johnTcrawford discovered that hold nodes were interacting with each other, and indeed, we were storing the timer,  gate and heldValue states as member vars of the factory - which I mistook for the the class that shaped a node instance.   I changed it so we store these properties on the individual nodes, in the node.data property...
...which is a type that lets you set any key value pair, and that makes for a lot of casting throughout the code
...which I tried to reduce (with co-pilot's help) by doing:
interface HoldNodeData {
  gateActive: boolean;
  heldValue: number | null;
  timerRunning: boolean;
}

//...
      node.data = {
        ...node.data,
        gateActive: false,
        heldValue: null,
        timerRunning: false,
      } as NodeData['data'] & HoldNodeData;

But I don't know if it just adds up to more noise because I ended up having to cast anyway.
Anyway, let me know what you think: https://github.com/concord-consortium/collaborative-learning/pull/2235/commits/764d7e752f969e377cd94f7da42d4c2652f801e9